IAPPCIPM68 concepts

CIPM Cheat Sheet

Quick reference for the IAPP Certified Information Privacy Manager exam.

Quick Navigation

Privacy Program Governance — Organizational Structure Privacy Program Governance — Metrics and KPIs Privacy Program Framework — Foundations Privacy Operational Lifecycle — Assess Phase Privacy Operational Lifecycle — Protect Phase Privacy Operational Lifecycle — Sustain Phase Privacy Operational Lifecycle — Respond Phase Privacy Legislation and Regulation Controller, Processor, and DPO Roles Key Exam Distinctions and Traps

Privacy Program Governance — Organizational Structure

DPO Mandatory Triggers (GDPR Article 37): A DPO must be appointed when: (1) a public authority processes personal data, (2) core activities involve regular and systematic monitoring of data subjects at large scale, or (3) core activities involve large-scale processing of special category or criminal conviction data.
DPO Independence Requirements: The DPO must report to the highest management level, cannot receive instructions on how to exercise their tasks, and cannot be penalized for performing their duties — the DPO advises and monitors but the controller bears ultimate compliance responsibility.
Privacy Committee / Steering Group: Cross-functional body including representatives from IT, Legal, HR, Marketing, Security, and Operations that embeds privacy considerations into business decisions rather than leaving privacy as an isolated function.
Accountability Principle (GDPR Article 5(2)): The controller must not only comply with GDPR but be able to DEMONSTRATE compliance through documentation, training records, DPIA records, audit trails, governance structures, and measurable metrics — a privacy policy alone is insufficient.
Role-Based Privacy Training Design: Effective programs combine general awareness for all employees with specialized modules per function: consent management for Marketing, special category data handling for HR, security controls and access management for IT, and DSAR handling for Customer Service.
Privacy Program Budget Justification: Justify investment using: risk reduction quantification, regulatory penalty avoidance (GDPR fines up to 4% global turnover), competitive trust advantage, and cost-of-breach vs. cost-of-prevention analysis.
Executive Reporting Approach: Effective board-level reporting combines operational metrics, program maturity scores, risk reduction achieved, and a cost-benefit comparison of privacy investment vs. potential regulatory penalty exposure.

Privacy Program Governance — Metrics and KPIs

DSAR Response Time: Track average days to respond to Data Subject Access Requests — GDPR Article 12 requires response within 30 days; breaching this deadline is a compliance failure that must appear in leadership reporting.
Breach Notification Compliance Rate: Percentage of personal data breaches reported to the supervisory authority within the 72-hour GDPR Article 33 deadline — a key KPI demonstrating incident response program effectiveness.
Training Completion Rate: Percentage of employees who have completed required privacy training within the defined period, segmented by role-based module — a primary accountability metric for governance programs.
DPIA Completion Before Processing: Track whether DPIAs are completed BEFORE high-risk processing begins (Article 35(1)) — retroactive DPIAs indicate a governance failure and should be reported as a corrective action item.
Audit Finding Remediation Rate: Percentage of audit findings closed within committed timelines; unresolved findings that age beyond deadlines indicate program gaps and must be escalated with root cause analysis.
Privacy Metrics vs. Privacy Maturity: Metrics measure specific operational outputs (DSAR response time, training completion); maturity measures the overall capability level of the program across governance, processes, and culture — high metric scores in one area do not guarantee overall program maturity.

Privacy Program Framework — Foundations

Fair Information Practice Principles (FIPPs): Five foundational privacy principles (1973 HEW Advisory Committee) underlying all modern privacy law: Notice/Awareness, Choice/Consent, Access/Participation, Integrity/Security, Enforcement/Redress.
OECD Privacy Guidelines — Eight Principles: Internationally adopted (1980, updated 2013): Collection Limitation, Data Quality, Purpose Specification, Use Limitation, Security Safeguards, Openness, Individual Participation, Accountability — foundation for GDPR and most national privacy laws.
GAPP — Ten Principles (AICPA/CICA): Generally Accepted Privacy Principles: Management, Notice, Choice and Consent, Collection, Use/Retention/Disposal, Access, Disclosure to Third Parties, Security for Privacy, Quality, Monitoring and Enforcement.
NIST Privacy Framework — Five Core Functions: Identify-P (understand organizational context and data), Govern-P (establish governance and risk priorities), Control-P (manage data processing with granularity), Communicate-P (maintain reliable dialogue about processing), Protect-P (manage data processing ecosystem risks).
NIST Privacy vs. Cybersecurity Framework: The NIST Privacy Framework was designed to complement the NIST Cybersecurity Framework — the P suffix (Identify-P, Govern-P, etc.) distinguishes privacy functions from CSF functions; organizations using CSF should adopt the Privacy Framework for alignment.
Privacy Program Scope Definition: Scope must cover: what data categories are processed, which jurisdictions' data subjects are affected, which business units and processing activities are in scope, and which laws apply — scope must match the actual data processing footprint.
Regulatory Landscape Monitoring: An ongoing privacy program function: track new legislation, regulatory guidance, enforcement decisions, and court rulings that affect organizational privacy obligations, then conduct gap analysis and implement changes before effective dates.

Privacy Operational Lifecycle — Assess Phase

Privacy Operational Lifecycle — Four Phases: Assess (identify data and risks) → Protect (implement safeguards) → Sustain (measure, audit, improve) → Respond (handle requests, breaches, complaints) — a continuous improvement loop structuring CIPM Domains III–VI.
Data Inventory vs. ROPA: Data inventory is the broader operational catalog (all personal data, storage locations, access controls, data flows); ROPA is the formal legal document required by GDPR Article 30 with specific mandatory fields — the inventory feeds the ROPA but contains more operational detail.
ROPA Required Contents (GDPR Article 30): Controller name and contact, DPO contact, processing purposes, data subject categories, personal data categories, recipient categories, international transfer details, retention periods, and security measures — both controllers AND processors must maintain a ROPA.
DPIA Triggers (GDPR Article 35): A DPIA is mandatory when processing is likely to result in high risk: (1) systematic extensive profiling with significant legal effects, (2) large-scale special category data processing, (3) systematic monitoring of publicly accessible areas — must be completed BEFORE processing begins.
DPIA Required Contents: Description of processing and purposes, assessment of necessity and proportionality, identification of risks to data subjects, technical and organizational measures to mitigate risks, and residual risk after controls — DPO consultation is required during the DPIA.
High Residual Risk → Prior Consultation (Article 36): If a DPIA concludes residual risk remains high after all mitigations, the controller must consult the supervisory authority before proceeding — the SA has 8 weeks to respond (extendable to 14 weeks), and processing cannot begin during this period.
M&A Privacy Due Diligence: Assess: target company's compliance posture, data assets and liabilities, pending regulatory actions, consent bases that may not survive the transaction (consent given to Company A may not automatically transfer to Company B), and data integration risks.
Vendor / Processor Assessment: Evaluate processor security practices, data handling procedures, breach notification capabilities, subprocessor management, data return and deletion on contract termination, and audit rights — document requirements in a Data Processing Agreement (DPA) per Article 28.

Privacy Operational Lifecycle — Protect Phase

Privacy by Design — GDPR Article 25: Controllers must implement appropriate technical and organizational measures both at the time of determining processing means and at the time of processing itself — privacy is embedded proactively, not retrofitted after deployment.
Privacy by Design vs. Privacy by Default: Privacy by Design is the overarching framework of embedding privacy into system architecture from inception; Privacy by Default means the most privacy-protective settings apply automatically without user action and users must actively choose to share more — both required by Article 25.
Privacy by Design in the SDLC: Privacy requirements in specification phase → DPIA and data flow diagrams in design → privacy code review and testing → DPIA completion before deployment → ongoing privacy monitoring in operations.
Data Processing Agreement (DPA) — Article 28 Requirements: Must specify: processing subject matter and duration, nature and purpose, type of data and data subject categories, controller obligations and rights, security measures, subprocessor restrictions, data return or deletion, audit rights, and breach notification obligations.
Information Security Controls for Privacy: Encryption at rest and in transit, access controls based on least privilege, pseudonymization, data loss prevention (DLP), audit logging, and secure destruction — security is necessary but NOT sufficient for privacy, which also requires purpose limitation and lawful processing.
Data Classification for Protection Controls: Categorize personal data by sensitivity (public, internal, confidential, special category/sensitive) to apply proportionate controls — classification drives retention schedules, encryption requirements, access controls, and destruction methods.

Privacy Operational Lifecycle — Sustain Phase

Privacy Auditing Scope: Evaluate: policy compliance, procedural adherence, technical control effectiveness, DSAR response timeliness, breach notification compliance, training completion, vendor management practices, and DPIA completion before high-risk processing.
Internal vs. External vs. Regulatory Audit: Internal audits are conducted by the privacy team or internal audit function; external audits by independent third parties; regulatory audits by supervisory authorities — all audit types generate findings that must drive tracked corrective actions.
Privacy Program Maturity Levels: Five-level scale: Level 1 Ad Hoc/Reactive → Level 2 Defined → Level 3 Managed → Level 4 Measured → Level 5 Optimized — used to benchmark current state, set improvement targets, and justify budget requests to leadership.
Maturity vs. Metrics (Exam Distinction): Metrics measure specific operational outputs right now (DSAR response time, training completion rate); maturity measures the holistic capability level of the program overall — a program with strong individual metrics may still be at a low maturity level.
Continuous Improvement Process: Audit findings drive corrective actions with defined owners and deadlines; lessons learned from incidents are documented and applied to program improvements; maturity assessments set the next improvement target — privacy programs must continuously evolve.
Ongoing Vendor Monitoring: Vendor / processor management is not a one-time due diligence exercise — processors must be continuously evaluated for compliance with DPA requirements, subprocessor changes, security practices, and breach notification capability.

Privacy Operational Lifecycle — Respond Phase

Breach Notification to Supervisory Authority (Article 33): Notify within 72 hours of becoming aware unless the breach is unlikely to result in a risk to individuals — notification must include breach nature, approximate number of affected records and data subjects, likely consequences, and remedial measures taken.
Breach Notification to Data Subjects (Article 34): Notify affected data subjects without undue delay only when the breach is likely to result in HIGH risk to their rights and freedoms — no 72-hour deadline applies, and notification can be avoided if data was encrypted, risk was eliminated, or individual notification requires disproportionate effort.
Authority vs. Data Subject Notification Threshold: Authority notification threshold is lower: any risk to individuals triggers reporting; data subject notification threshold is higher: only HIGH risk triggers direct communication — a breach can require authority notification without requiring data subject notification.
Incident Response Plan Components: Detection and classification, initial containment, investigation and root cause analysis, notification decision framework, remediation actions, internal and external communication plan, post-incident review with documented lessons learned, and periodic plan testing.
DSAR Workflow Steps: Request receipt and acknowledgment → identity verification → data retrieval across all systems → response preparation → delivery within 30 days (GDPR Article 12) → documentation of the complete process for accountability.
GDPR Data Subject Rights Overview: Access (Art 15), Rectification (Art 16), Erasure/Right to Be Forgotten (Art 17), Restriction of Processing (Art 18), Data Portability (Art 20), Objection (Art 21), Rights in Automated Decision-Making (Art 22) — operational workflows must handle each within legal timeframes.
Breach Response Sequence: Detect → contain → investigate (determine scope, nature, affected individuals) → assess notification obligations (72-hour rule, high-risk threshold) → notify → remediate → post-incident review → update program controls to prevent recurrence.

Privacy Legislation and Regulation

GDPR Lawful Bases (Article 6) — Six Bases: Consent, Contract (performance or pre-contractual steps), Legal obligation, Vital interests, Public task, Legitimate interests — organizations must identify the lawful basis BEFORE processing begins and document it in the ROPA.
GDPR Special Category Data (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; criminal conviction data is Article 10 (separate provision).
GDPR vs. CCPA/CPRA — Fundamental Difference: GDPR requires a lawful basis (including consent) BEFORE any processing begins (opt-in approach); CCPA/CPRA operates on an opt-out model — businesses may process personal information but must honor consumer rights to opt out of sale/sharing and limit use of sensitive PI.
Cross-Border Transfer Mechanisms (GDPR Chapter V): Adequacy decision (Commission determines third country provides adequate protection), Standard Contractual Clauses (SCCs, pre-approved, fastest), Binding Corporate Rules (BCRs, intra-group only, requires SA approval, slowest), and Article 49 derogations.
SCCs vs. BCRs (Key Distinction): SCCs are for transfers to external third parties (or quick intra-group use) and are pre-approved by the European Commission; BCRs are exclusively for intra-group transfers within a corporate family and require supervisory authority approval — both require a Transfer Impact Assessment post-Schrems II.
Transfer Impact Assessment (TIA) — Post-Schrems II: Required when using SCCs or BCRs to assess whether the destination country's legal framework (surveillance laws, government access rights) provides essentially equivalent protection — supplementary measures must be implemented if the TIA reveals gaps.
GDPR Maximum Fines: Up to 20 million EUR or 4% of annual global turnover for the most serious violations (whichever is greater); up to 10 million EUR or 2% for less serious violations — used as business justification for privacy program investment, not as a compliance target.
Multi-Jurisdiction Compliance: GDPR compliance does not automatically satisfy CCPA, LGPD (Brazil), PIPEDA (Canada), HIPAA, or GLBA requirements — each law has unique obligations; the privacy program must maintain a jurisdiction inventory and track each law's specific requirements.

Controller, Processor, and DPO Roles

Controller Definition: The entity that determines the purposes and means of personal data processing — bears primary responsibility for compliance: lawful basis, data subject rights fulfillment, DPIAs, breach notification to supervisory authorities, and ROPA maintenance.
Processor Definition: The entity that processes personal data on behalf of the controller, following documented controller instructions — must maintain a processor ROPA, implement appropriate security, notify the controller of breaches without undue delay, and not engage subprocessors without controller authorization.
Joint Controllers: When two or more entities jointly determine the purposes and means of processing, they are joint controllers and must define their respective responsibilities in a transparent arrangement — each remains liable to data subjects for the full processing.
Cloud Provider Role (Common Exam Trap): A cloud provider hosting personal data is typically a processor (following client instructions) — but if the provider determines its own purposes for using the data beyond the controller's instructions (e.g., training its own models), it becomes a controller for that processing.
DPO Role vs. Controller Responsibility: The DPO advises on and monitors compliance but does NOT bear responsibility for compliance — the controller is responsible and accountable under Article 5(2); treating the DPO as the 'owner' of compliance is a common governance error.
DPO Tasks (GDPR Article 39): Inform and advise the controller and employees of obligations, monitor compliance with GDPR and internal policies, provide advice on DPIAs (Article 35(4)), cooperate with the supervisory authority, and act as the contact point for the SA and for data subjects.

Key Exam Distinctions and Traps

PIA vs. DPIA: PIA is a general privacy risk assessment applicable in any jurisdiction or by organizational policy; DPIA is the GDPR-specific version legally required under Article 35 for high-risk processing with specific mandatory content — all DPIAs are PIAs, not all PIAs are DPIAs.
Data Inventory vs. ROPA (Exam Distinction): The data inventory is broader and more detailed (includes storage locations, access controls, data flow diagrams); the ROPA is a formal legal compliance document with specific required fields under Article 30 — organizations need both.
Privacy by Design vs. Privacy by Default (Exam Distinction): Privacy by Design is the overarching framework (embed privacy in architecture from inception); Privacy by Default is a specific requirement within it (most privacy-protective settings apply by default) — a system can implement Privacy by Design yet fail Privacy by Default if its defaults are not maximally protective.
Consent Basis Survival in M&A: Consent given to the acquired organization may not automatically survive an acquisition — if the original consent or privacy policy limited data use to the acquired company's purposes, using the data for the acquirer's purposes requires new consent or a different lawful basis.
CIPM vs. CIPP: CIPP focuses on privacy LAW (what does the law require?); CIPM focuses on privacy MANAGEMENT (how do you build a program to meet those requirements?) — the CIPM tests application of program management skills in scenario-based questions, not memorization of legal text.
Adequacy Decision vs. SCCs: An adequacy decision means the destination country's law provides adequate protection and no additional transfer mechanism is needed; SCCs are contractual safeguards used when there is NO adequacy decision — they are not interchangeable.
AI Governance for Privacy Managers: Privacy managers must assess AI-related risks including: automated decision-making transparency (GDPR Article 22), profiling risks, bias and discrimination, data minimization challenges with large training datasets, and governance controls for AI systems that process personal data.

Ready to test yourself?

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