IAPPCIPT82 concepts

CIPT Cheat Sheet

Quick reference for the IAPP Certified Information Privacy Technologist exam.

Quick Navigation

Privacy by Design — Seven Principles LINDDUN Privacy Threat Model NIST Privacy Engineering Objectives De-identification Techniques (PETs)Notice and Consent Mechanisms Dark Patterns in Consent Interfaces Privacy Risk Assessment (PIA and DPIA)Data Lifecycle Controls Automatic Data Collection Technologies Privacy Engineering in the SDLC Biometrics and Workplace Technologies Regulatory Frameworks Reference

Privacy by Design — Seven Principles

Principle 1: Proactive not Reactive: Anticipate and prevent privacy-invasive events BEFORE they occur. Privacy protections are built in before systems go live, not bolted on after an incident or regulatory action.
Principle 2: Privacy as the Default Setting: The strictest privacy-protective settings apply WITHOUT any action required by the individual. Users must actively OPT OUT to share more. Pre-ticked boxes and public-by-default profiles violate this principle. Codified in GDPR Article 25.
Principle 3: Privacy Embedded into Design: Privacy is an integral component of the system, not an add-on feature. Privacy requirements enter the functional spec, architecture review, code review, and testing — not just the legal review.
Principle 4: Full Functionality — Positive-Sum: Privacy AND functionality, not privacy OR functionality. The assumption that privacy requires functional trade-offs is rejected. A system can be fully featured and fully privacy-protective simultaneously.
Principle 5: End-to-End Security — Full Lifecycle: Strong security protects data from collection through to secure deletion. Privacy protection does not end at storage — it includes secure transmission, processing controls, and NIST SP 800-88 compliant destruction at end of life.
Principle 6: Visibility and Transparency: All stakeholders can verify that the system operates as promised. Processing practices are openly communicated. Privacy policies are accurate and understandable, not boilerplate.
Principle 7: Respect for User Privacy: Individual interests are protected through strong privacy-protective defaults, appropriate notice, and empowering options for individuals to exercise control over their data.

LINDDUN Privacy Threat Model

L — Linkability: Linking two or more items of data about the same individual across contexts reveals more than intended. Example: combining purchase history with browsing data to infer health conditions. Control: data minimization, pseudonymization, differential privacy.
I — Identifiability: Identifying a specific individual from available data, directly (name, SSN) or indirectly (ZIP + age + gender quasi-identifiers). Control: k-anonymity, generalization, suppression, aggregation.
N — Non-repudiation: PRIVACY THREAT (opposite of security non-repudiation): individuals CANNOT DENY that actions occurred, enabling surveillance. Example: immutable action logs reveal behavioral patterns. Control: log minimization, purpose limitation for audit logs.
D — Detectability: Detecting whether data about a person EXISTS, even without accessing the content. Example: traffic analysis revealing that a user messaged a specific person. Control: traffic padding, cover traffic, access controls.
D — Disclosure of Information: Exposure of personal data to unauthorized parties. Example: insecure API returning more user data than the requesting party is entitled to. Control: access controls, field-level encryption, data minimization in API responses.
U — Unawareness: Individuals are unaware that their data is being collected or processed. Control: just-in-time notices, layered privacy notices, transparency reports, meaningful consent interfaces.
N — Non-compliance: Processing violates applicable laws, regulations, or the organization's own privacy policies. Control: privacy governance program, DPIA process, ROPA maintenance, privacy legal review.
Applying LINDDUN: 1) Build a data flow diagram. 2) Identify personal data flows. 3) Apply each LINDDUN category to each flow. 4) Document threats. 5) Identify controls. LINDDUN is applied from the designer perspective; MITRE PANOPTIC from the attacker perspective.

NIST Privacy Engineering Objectives

Predictability: Enable reliable assumptions by individuals, owners, and operators about how personal data and systems behave. Example: users can accurately predict what data is collected at checkout. Achieved through: accurate privacy notices, consistent data use aligned with stated purposes.
Manageability: Provide individuals and organizations with granular ability to manage personal data processing, including granting, modifying, and revoking processing permissions. Example: user dashboard to download data (GDPR Article 20), request deletion (Article 17), manage consents. Achieved through: preference management systems, data portability tools, consent withdrawal mechanisms.
Disassociability: Enable the processing of data with decreasing levels of association between individuals and their data. NOT a specific technique — an objective served by: pseudonymization, k-anonymity, differential privacy, aggregation, data minimization. Example: analytics pipeline replaces user IDs with tokens before aggregating to daily totals.
Objective vs. Technique: Disassociability is the OBJECTIVE. K-anonymity, differential privacy, pseudonymization, and tokenization are TECHNIQUES that serve it. Exam questions may ask which objective is served by a technique — the answer is usually Disassociability.
NIST Privacy Framework Core: Five functions: Identify-P (catalog and understand data processing), Govern-P (establish governance structure and risk priorities), Control-P (enable organizations and individuals to manage data with sufficient granularity), Communicate-P (enable reliable understanding and dialogue about data processing), Protect-P (develop and implement appropriate data processing safeguards). Complements the NIST Cybersecurity Framework.
Privacy Goals Framework (PbD-derived): Five engineering goals translating PbD principles into technical requirements: Unlinkability (prevent linking data across contexts beyond intended use), Transparency (all stakeholders can verify processing), Intervenability (individuals can intervene in processing), Confidentiality (data protected from unauthorized access), Availability (data accessible to authorized parties). Used in privacy threat modeling and requirements engineering.
Value-Sensitive Design (VSD): Design methodology explicitly accounting for human values in technology. Three investigation types: Conceptual (identify values and ALL stakeholders, including indirect parties affected by a system who never interact with it), Empirical (study how users and affected parties respond), Technical (analyze how design decisions embody or undermine values). Applies PbD Principle 7 operationally.

De-identification Techniques (PETs)

K-anonymity: Each record is indistinguishable from at least k-1 other records on quasi-identifier attributes (age + ZIP + gender). Prevents singling out. DOES NOT prevent attribute disclosure — all k records may share the same sensitive attribute (homogeneity attack).
L-diversity: Extends k-anonymity: requires at least l distinct sensitive attribute values within each equivalence class. Prevents homogeneity attack on k-anonymous datasets. Does NOT protect against skewness (one value dominates the group).
T-closeness: Extends l-diversity: requires the distribution of sensitive attributes within each equivalence class to be close to the overall dataset distribution. Defeats skewness and similarity attacks on l-diverse datasets.
Differential Privacy: Adds calibrated random noise to query outputs. Privacy budget (epsilon ε): low ε = more noise = stronger privacy = less accurate output. Guarantees that an individual's inclusion or exclusion cannot be reliably inferred. Does NOT protect individual records — protects aggregate statistics.
Pseudonymization: Replace direct identifiers with pseudonyms (tokens, hashes, IDs) while retaining re-linkage capability via a separate key. Still PERSONAL DATA under GDPR. Reversible by design. Reduces breach impact but does not remove from privacy law scope.
Anonymization: Remove all direct and indirect identifiers such that re-identification is not reasonably possible. Truly anonymized data falls OUTSIDE GDPR scope. Requires statistical disclosure controls — most real datasets are pseudonymized, not anonymized.
Tokenization: Replace sensitive values (e.g., credit card numbers) with randomly assigned tokens. A secure vault maps tokens to original values. Unlike encryption, no mathematical relationship between token and original. Security depends entirely on vault protection.
Synthetic Data: Algorithmically generated data with statistical properties of real data but no actual personal information. Generated via GANs or rule-based methods. Risk: models trained on real data may memorize individual records (model inversion attack). Pair with differential privacy for stronger guarantees.

Notice and Consent Mechanisms

Valid GDPR Consent Requirements: Freely given (no coercion, no bundling with service unless necessary), Specific (separate consent per distinct purpose), Informed (clear description of what consent covers), Unambiguous (affirmative act — pre-ticked boxes are INVALID, silence is INVALID).
Layered Privacy Notice: Short-form notice (key facts at point of collection) + link to full-length privacy policy. Balances comprehensibility with completeness. Short notice must accurately represent the full policy.
Just-in-Time Notice: Notice provided at the exact moment data is collected, rather than in a general privacy policy. Most effective for specific, contextual data collection (e.g., location notice when an app first requests GPS access).
Opt-in vs. Opt-out: Opt-in: user must take affirmative action to agree. Required for GDPR consent and ePrivacy non-essential cookies. Opt-out: user is assumed to consent unless they object. NOT valid as GDPR consent mechanism. Pre-ticked boxes = opt-out = INVALID for consent.
Strictly Necessary Cookie Exemption: Cookies that are strictly necessary for a service explicitly requested by the user are exempt from consent under the ePrivacy Directive. Narrow definition: session cookies, authentication cookies. Analytics cookies and advertising cookies are NEVER strictly necessary.
Preference Management Center: A user-facing interface allowing individuals to view, adjust, and withdraw consents and preferences at any time. Required to be as easy to withdraw consent as to give it (GDPR Article 7(3)). Must be persistent and accessible, not buried in settings.

Dark Patterns in Consent Interfaces

Nagging: Repeatedly requesting consent after the user has declined, wearing down resistance. Example: daily prompts for location access after the user dismissed it. Makes consent 'non-freely-given' through persistence.
Obstruction: Making it unreasonably difficult to exercise a privacy right or decline consent. Example: account deletion requiring 12 steps through unclear menus. Undermines the requirement that withdrawal of consent be as easy as giving it.
Sneaking: Collecting or processing data without clear disclosure. Example: activating microphone access in the background, adding user data to a marketing list without disclosure in the consent flow.
Interface Interference: Using visual design to manipulate choices. Example: 'Accept All' in large green button, 'Reject All' in small grey text below the fold. Makes the privacy-protective option harder to choose.
Forced Action: Requiring users to consent to non-essential processing to access a service or feature. Example: forcing users to accept marketing cookies to use a free service (violates 'freely given' unless service is conditional on necessary processing).
Trick Questions: Ambiguous or double-negative wording in consent dialogs that produces unexpected consent. Example: 'Uncheck this box to not receive marketing emails' (double negative). Results in consent the user did not intend to give.
Disguising: Hiding or masking the commercial or tracking nature of an action. Example: a loyalty program enrollment form that does not disclose it also signs users up for cross-company data sharing, or a 'personalization' feature that is actually behavioral profiling for ad targeting. Users consent to something they did not understand they were agreeing to.
Dark Pattern Legal Status: Consent obtained through dark patterns is NOT valid consent under GDPR. The EDPB (European Data Protection Board) issued specific guidelines on dark patterns in social media (EDPB Guidelines 3/2022). Many jurisdictions now explicitly prohibit dark patterns in consent interfaces.

Privacy Risk Assessment (PIA and DPIA)

PIA vs. DPIA: PIA (Privacy Impact Assessment): general privacy risk assessment applicable in any jurisdiction or by policy. DPIA (Data Protection Impact Assessment): GDPR-specific, legally required under Article 35 for high-risk processing. All DPIAs are PIAs; not all PIAs are DPIAs.
DPIA Triggers (GDPR Article 35): Required when processing is 'likely to result in a high risk': (1) systematic and extensive profiling with significant legal effects, (2) large-scale processing of special category data, (3) systematic monitoring of publicly accessible areas. EDPB lists additional triggers.
DPIA Required Contents: Description of processing and purposes, assessment of necessity and proportionality, assessment of risks to data subjects, measures to address risks (technical and organizational controls), residual risk after controls.
DPIA Timing: DPIA must be completed BEFORE high-risk processing begins (GDPR Article 35(1)). A retroactive DPIA is a compliance failure, not a cure. When DPIA identifies high residual risk that cannot be mitigated, controller MUST consult the supervisory authority before proceeding.
High Residual Risk → Prior Consultation: If DPIA concludes that residual risk is high after all controls are applied, GDPR Article 36 requires prior consultation with the supervisory authority. The SA has 8 weeks to respond (extendable to 14 weeks). Processing may not begin during consultation.
PIA Process Steps: 1) Identify data flows and processing activities. 2) Assess privacy risks to data subjects. 3) Identify legal basis and necessity/proportionality. 4) Evaluate data minimization compliance. 5) Recommend mitigations. 6) Document residual risk. 7) Obtain sign-off from DPO or privacy counsel.
Intrusion and Decisional Interference: Intrusion: unreasonable interference with a person's solitude, seclusion, or private affairs (e.g., ambient monitoring in personal spaces). Decisional interference: influencing a person's personal decisions through surveillance or targeted information use. Both are privacy harms independent of whether personal data is disclosed to third parties.
MITRE PANOPTIC (2025-2026 BoK): Privacy-specific threat framework cataloging adversarial TTPs structured analogously to MITRE ATT&CK. Core tactics: Data Collection, Aggregation, Inference, Unauthorized Disclosure. Attacker-perspective complement to LINDDUN: LINDDUN identifies threats in system design; PANOPTIC describes how adversaries exploit those threats to harm privacy.

Data Lifecycle Controls

Retention Schedule: Defined periods specifying how long personal data may be retained for each processing purpose. Data must be deleted or anonymized when the retention period expires. Retention schedule must be documented in the ROPA.
Secure Deletion (NIST SP 800-88): Clear: software overwrite (defeats casual recovery, not lab forensics). Purge: ATA Secure Erase, degaussing, or firmware techniques (defeats lab forensic recovery — required for sensitive personal data on HDDs/SSDs). Destroy: physical shredding (required for classified or extremely sensitive data leaving organizational control).
Cryptographic Erasure: Destroy the encryption key so encrypted data becomes unreadable without physical destruction of the media. Effective for cloud storage and full-disk encrypted devices. ALL copies of the key must be destroyed, including key backups. If any key copy survives, the data is theoretically recoverable.
Storage Limitation Principle: GDPR Article 5(1)(e): personal data kept in identifiable form no longer than necessary for the purpose. Technical implementation: automated retention enforcement via scheduled deletion jobs, retention flags in databases, periodic data audits.
Purpose Limitation: GDPR Article 5(1)(b): personal data collected for specified, explicit, and legitimate purposes must not be processed in a manner incompatible with those purposes. Technical control: separate data stores per purpose with access controls preventing cross-purpose data use.
Data Classification: Categorize personal data by sensitivity level (public, internal, confidential, sensitive/special category). Classification drives retention periods, encryption requirements, access controls, and destruction methods. Higher classification = stricter controls at all lifecycle stages.

Automatic Data Collection Technologies

HTTP Cookies: Session cookies: expire when browser closes. Persistent cookies: survive browser close, have an expiry date. First-party: set by visited domain. Third-party: set by external domain (e.g., ad network). Strictly necessary cookies: exempt from ePrivacy consent. Analytics and advertising cookies: ALWAYS require prior consent.
Tracking Pixels / Web Beacons: 1x1 transparent images embedded in emails or web pages. When loaded, confirm the email was opened or page was visited, along with IP address, browser, and timestamp. Used for email open tracking and cross-site user tracking.
Browser Fingerprinting: Collecting browser/device attributes (user-agent, screen resolution, installed plugins, fonts, canvas rendering) to create a unique identifier. Stores NOTHING on the user's device. Clearing cookies does NOT defeat fingerprinting. Requires different controls: attribute randomization or browser standardization.
Supercookies / Evercookies: Tracking identifiers stored outside the browser's standard cookie storage (ETags, localStorage, IndexedDB, Flash cookies). Persist after standard cookie clearing. Re-create standard cookies when they are deleted. Must be addressed in the consent mechanism.
Cross-Device Tracking: Correlating a user's activity across multiple devices (phone, laptop, tablet, TV). Techniques: deterministic (same login), probabilistic (IP, location, behavioral patterns). Privacy risk: circumvents device-specific privacy controls.
Location Tracking: GPS (precise, requires explicit permission), cell tower (approximate, carrier-level), Wi-Fi positioning (building-level precision), Bluetooth beacons (room-level precision). Each method has different precision, consent requirements, and retention risk.

Privacy Engineering in the SDLC

Privacy Requirements Phase: Translate legal privacy obligations and PbD principles into technical requirements. Define: what data will be collected (minimization), legal bases, retention periods, data subject rights to implement, encryption requirements, and consent flows. Input to all subsequent phases.
Privacy in Design Phase: Build data flow diagrams (DFDs) annotated with data categories and legal bases. Apply LINDDUN threat modeling to DFDs. Design privacy controls for each identified threat. Document privacy goals (unlinkability, transparency, intervenability, confidentiality).
Privacy Code Review: Check for: over-collection (collecting fields not in requirements), insecure logging (personal data in plaintext logs), missing field-level encryption for sensitive attributes, hardcoded secrets, insecure deletion, overly broad API responses, and missing input validation.
Privacy Testing: Test: consent mechanisms function correctly (opt-in, opt-out, withdrawal), data subject rights requests work (access, deletion, portability), retention enforcement triggers deletion at the correct time, access controls prevent unauthorized cross-purpose data access.
Records of Processing Activities (ROPA): GDPR Article 30 requirement for controllers AND processors (250+ employees OR high-risk processing). Contents: controller identity, purposes, data subject and data categories, recipients, international transfers, retention periods, security measures. Internal document — not a public notice.
Data Inventory: Comprehensive catalog of all personal data held: data categories, storage locations, systems holding the data, legal bases, retention periods, access controls, and third-party sharing. Foundation for ROPA, PIA/DPIA, and data subject rights fulfillment.
Privacy Monitoring: Ongoing: monitor for privacy incidents (including authorized but inappropriate processing), review data processing activities for purpose creep, track data subject rights request fulfilment times, audit access to sensitive data, review third-party processor compliance.
AI/Automated Decision-Making — Privacy Risks: Algorithmic bias can arise from biased training data, biased feature selection, or biased objective functions. Privacy-specific risks: proxy discrimination (ZIP code correlating with protected class membership), model inversion attacks exposing training data, and inference attacks reconstructing personal data from model outputs. GDPR Article 22 governs automated individual decision-making with significant legal effects.

Biometrics and Workplace Technologies

Why Biometrics Are High-Risk: Immutable: cannot be changed after a breach (unlike passwords). Inherently identifying: by definition links data to a specific person. Enables persistent re-identification across contexts and databases. Special category data under GDPR Article 9 when used for identification purposes.
Biometric Technical Safeguards: Store processed templates (not raw biometric images or scans). Hash templates with a secure, salted one-way function. Store templates in an isolated vault with strict access controls. Implement template aging (periodic re-enrollment). Provide a non-biometric alternative authentication method. Apply purpose limitation (enrollment purpose cannot be repurposed).
Workplace Monitoring Types: Keystroke logging (records all keystrokes including passwords if not excluded). Screen capture (periodic or continuous screenshots). Email content monitoring. Network traffic inspection. Location tracking on company devices. Productivity scoring software. Each requires proportionality analysis and clear employee notice.
Workplace Monitoring Controls: Conduct DPIA before deployment (systematic employee monitoring triggers DPIA). Notify employees clearly BEFORE monitoring begins. Implement technical scope limitations (exclude password fields from keylogging, limit monitoring to work hours). Restrict access to monitoring data. Establish defined retention period for monitoring data.
IoT Privacy Risks: Continuous ambient data collection (audio, video, location, environmental). Limited user interfaces make consent difficult. Long device lifespans with short software support windows create security gaps. Data aggregation: individually innocuous data points (TV on/off times, thermostat, lights) together reveal sensitive behavioral patterns.

Regulatory Frameworks Reference

GDPR Key Articles for CIPT: Article 5: data principles (minimization, purpose limitation, storage limitation, accuracy, integrity/confidentiality, accountability). Article 6: lawful bases. Article 9: special categories. Article 17: right to erasure. Article 20: data portability. Article 25: data protection by design and by default. Article 30: ROPA. Article 35: DPIA.
GDPR Article 5 — Seven Data Principles: All seven: (1) Lawfulness/fairness/transparency, (2) Purpose limitation, (3) Data minimisation (adequate, relevant, limited to what is necessary), (4) Accuracy, (5) Storage limitation, (6) Integrity and confidentiality, (7) Accountability. Exam tip: data minimisation (Art 5(1)(c)) is a standalone principle, not merely a component of storage limitation.
GDPR Special Categories (Article 9): Health data, racial/ethnic origin, political opinions, religious/philosophical beliefs, trade union membership, genetic data, biometric data used for identification, sex life or sexual orientation. Require explicit consent or another Article 9(2) basis to process. Criminal convictions and offences are Article 10 (separate provision) — NOT Article 9 special categories.
ePrivacy Directive (Cookie Law): Requires prior informed consent for non-essential cookies and tracking technologies. Strictly necessary cookies exempt. Applies regardless of GDPR lawful basis. Being replaced by ePrivacy Regulation (proposed but not yet adopted as of 2025-2026 BoK).
ANAB Accreditation (CIPT): The CIPT is accredited by ANAB under ISO/IEC 17024:2012 (General requirements for bodies operating certification of persons). This means the exam meets internationally recognized standards for personnel certification — relevant for professional recognition.

Ready to test yourself?

Start a timed CIPT mock exam or review practice questions by domain.