General Exam Tips
- 1.Read ALL four answer choices before selecting — ISACA almost always includes one plausible-sounding distractor that uses correct vocabulary in the wrong context.
- 2.When a question asks 'FIRST' or 'MOST important', think process order: identify/assess before acting, and legal/regulatory foundation before technical implementation.
- 3.The 'ISACA way' for governance scenarios: assess the full scope of a problem before taking any corrective action. Never terminate, escalate, or fix before you understand the situation.
- 4.Domain 4 (Privacy Engineering) is 39% of the exam — roughly 47 questions. If you are weak there, you will not pass regardless of how well you know the other three domains.
- 5.120 questions in 210 minutes gives you 1 minute 45 seconds per question. Flag uncertain questions and return — don't spend more than 2 minutes on any one question.
- 6.There is no penalty for wrong answers. Never leave a question blank — your last resort guess should always be the option you can least eliminate.
- 7.ISACA exam questions are scenario-based. Ignore the 'noise' in the scenario and identify: what is the exact problem being solved, and what stage of the process are we in.
- 8.When two answers both look correct, ask: which answer is more comprehensive or foundational? ISACA favors the answer that enables or underpins the other.
- 9.Organizational standards do NOT supersede local regulations. When a global policy conflicts with local law in a scenario, local law wins.
- 10.The exam reflects real practitioner judgment, not academic definitions. Pick the answer that a prudent, experienced privacy engineer would do in practice.
Quick Navigation
Privacy Governance
Must-Know Facts
- DPO mandatory under GDPR for: public authorities, organizations conducting large-scale systematic monitoring, and organizations processing special category data at large scale — not every organization needs one.
- DPO must have functional independence — cannot receive instructions about how to perform tasks, and cannot be dismissed or penalized for performing duties.
- Privacy by Design has 7 principles: (1) proactive not reactive, (2) privacy as default, (3) embedded into design, (4) full functionality (positive-sum, not zero-sum), (5) end-to-end security, (6) visibility and transparency, (7) respect for user privacy.
- Privacy notice (external, for data subjects) is distinct from privacy policy (internal, governs employee/operational behavior).
- Vendor management moved under Privacy Governance in the 2025 CDPSE exam restructure. Data Processing Agreements (DPAs) are a governance control, not just a legal contract.
- Records of Processing Activities (ROPA) under GDPR Article 30: the 250-employee exemption is extremely narrow — applies only if processing is occasional, low-risk, AND does not involve special category data. In practice, almost all organizations must maintain ROPA.
- Privacy program components: strategy, policies and procedures, roles and responsibilities, awareness and training, monitoring and auditing, incident response, vendor management, and continuous improvement. On the exam, when asked what is MISSING from an incomplete program description, check for continuous improvement and monitoring — these are the most commonly omitted components in distractor answer choices.
- Privacy governance is cross-functional — IT, security, legal, HR, marketing, and business units all have roles. A privacy committee provides cross-functional oversight.
Common Traps
Confusing Pairs
Scenario Tips
An organization is expanding globally and needs to align its privacy program with multiple jurisdictions
Identify all applicable local regulations first, then design the program to the highest common standard. Organizational policies must accommodate local law — global policies do not supersede local regulations.
Applying one global standard uniformly is wrong because a country with stricter requirements than the global policy would result in non-compliance.
A question asks what to do FIRST when starting a privacy program from scratch
Identify applicable laws, regulations, and privacy requirements relevant to the organization's operations and data processing activities. You cannot build a governance program without knowing what you are required to comply with.
Developing policies, hiring a DPO, or implementing technical controls are all subsequent steps. They cannot be done correctly without first identifying the regulatory landscape.
When a question involves vendor/third-party risk, what is the MOST important ongoing control?
Ongoing monitoring, periodic re-assessment, and contractual audit rights — not just the initial due diligence. The controller remains responsible for third-party processing throughout the relationship.
Performing a one-time due diligence assessment and executing a DPA is the beginning, not the end, of vendor privacy management.
Last-Minute Facts
Privacy Risk Management and Compliance
Must-Know Facts
- DPIA is mandatory BEFORE high-risk processing begins, not after. High-risk triggers under GDPR Article 35: systematic large-scale monitoring, large-scale processing of special categories, and automated decision-making with legal effects.
- When a DPIA reveals unmitigatable high residual risk, GDPR Article 36 requires prior consultation with the supervisory authority before processing can begin — you cannot simply accept the risk and proceed.
- PIA vs DPIA: PIA is a broader organizational best practice for any project. DPIA is a specific GDPR legal requirement triggered by high-risk processing. They overlap but are not interchangeable.
- Breach notification under GDPR: notify supervisory authority within 72 hours of becoming aware. Individual notification is only required when breach is likely to result in HIGH RISK to rights and freedoms — encrypted data breach may not require individual notification.
- ROPA (Records of Processing Activities) under Article 30 must contain: controller identity, processing purposes, categories of data and data subjects, recipients, cross-border transfers, retention periods, and security measures. The exam trap: processors must ALSO maintain their own (narrower) ROPA — not just controllers. Many candidates assume only the controller has this obligation.
- Privacy audit types: internal audits (first-party), external/third-party audits, and regulatory audits. Continuous monitoring complements periodic audits to provide ongoing assurance.
- Vendor risk management is ongoing — initial due diligence plus periodic re-assessment plus contractual audit rights. The controller remains responsible even when processing is outsourced.
- Privacy risk assessment must consider risks to DATA SUBJECTS (harm, discrimination, financial loss) not just organizational risks (fines, reputation). These are different risk categories.
Common Traps
Confusing Pairs
Scenario Tips
A DPIA reveals that residual risk cannot be reduced to an acceptable level with available controls
Consult the supervisory authority under GDPR Article 36 before starting processing. This is a mandatory step, not optional.
Accepting the risk with compensating controls or canceling the project entirely are wrong — the required step is supervisory authority consultation, not unilateral decision-making.
An organization suffers a breach of encrypted personal data. What must they do regarding notification?
Assess whether the breach is likely to result in high risk to data subjects (considering the encryption strength and key management). Notify the supervisory authority within 72 hours if the breach meets the notification threshold. Individual notification may not be required if the data was effectively encrypted.
Automatically notifying all data subjects is wrong — the threshold for individual notification is 'likely high risk,' not simply that a breach occurred.
Which approach provides the MOST comprehensive privacy compliance assurance?
Combining periodic audits with continuous automated monitoring of key privacy controls. This provides both point-in-time verification and real-time visibility.
Annual audits alone, employee self-certification, or policy review without control testing are all insufficient — they have coverage gaps or lack independence.
Last-Minute Facts
Data Life Cycle Management
Must-Know Facts
- Data lifecycle stages: collection, storage, use/processing, sharing/disclosure, archival, destruction — privacy controls apply at EVERY stage, not just collection.
- Purpose limitation: data collected for one purpose cannot be reused for an incompatible purpose without either a compatibility assessment (Article 6(4)) or a new lawful basis. Marketing use of data collected for order fulfillment requires separate legal basis.
- True erasure under the right to be forgotten requires removing data from ALL locations: production databases, backups, replicas, caches, logs, and data held by third-party processors. Deleting from production is insufficient.
- Data portability (Article 20) requires providing data in a structured, commonly used, MACHINE-READABLE format — a PDF is not sufficient. Applies only to data the subject actively provided and where processing is based on consent or contract.
- Data retention schedules must account for legal hold requirements. Scheduled-for-deletion data must be preserved if subject to litigation or regulatory investigation — deletion during legal hold is spoliation.
- Data classification drives control requirements: personal data, sensitive personal data (special categories under GDPR), PII, PHI, financial data each require different protection levels.
- Consent management platforms must support: granular consent collection, withdrawal, preference changes, audit trails, and age verification for children's data. Pre-ticked boxes and bundled consent are invalid under GDPR.
- Data quality management: personal data must be accurate, complete, and kept up to date. Organizations must correct or delete inaccurate data when notified by data subjects.
Common Traps
Confusing Pairs
Scenario Tips
An organization wants to use customer email addresses (collected for transactional emails) for a new marketing campaign
This requires either a compatibility assessment under Article 6(4) or a new lawful basis (typically explicit consent for marketing purposes). The existing consent/contractual basis for transactional emails does not extend to marketing.
'The data was already lawfully collected' is a trap — lawful collection does not authorize all subsequent uses. Purpose limitation is a separate requirement.
A user invokes their right to data portability — what format must you provide?
Structured, commonly used, machine-readable format (e.g., CSV, JSON, XML). The right to portability is designed to allow data to be imported into another service — a PDF cannot be machine-processed.
Any readable format is not sufficient. A human-readable PDF printout does not satisfy the portability requirement even though it is technically a document containing the data.
Disposing of a decommissioned physical hard drive containing personal data — which method provides MOST reliable assurance?
Physical destruction or degaussing with documented verification. For physical media, this is the gold standard because it eliminates any possibility of data recovery regardless of encryption history.
Reformatting or deleting files is insufficient — forensic tools can recover data. Cryptographic erasure is valid but depends on the encryption having been properly applied throughout the drive's lifecycle, making physical destruction more reliable for legacy/uncertain cases.
Last-Minute Facts
Privacy Engineering
Must-Know Facts
- Privacy Engineering is 39% of the exam — approximately 47 of 120 questions. This is the make-or-break domain.
- Anonymization = irreversible, data is NO LONGER personal data under GDPR. Pseudonymization = reversible with key, data IS STILL personal data and subject to all GDPR obligations.
- k-anonymity ensures each record is indistinguishable from k-1 others on quasi-identifiers. Vulnerable to homogeneity attack (all k records share same sensitive value) and background knowledge attack.
- l-diversity extends k-anonymity by requiring at least l well-represented values for sensitive attributes in each equivalence class — fixes the homogeneity attack.
- t-closeness extends l-diversity by requiring the distribution of sensitive attributes within each group to be close to the overall distribution — fixes the skewness attack.
- Encryption states: at rest (symmetric AES-256, stored data), in transit (TLS 1.2/1.3, data moving across networks), in use (homomorphic encryption or secure enclaves, data being processed). Each state requires a different control.
- Hashing is ONE-WAY and irreversible. Encryption is TWO-WAY and reversible with the key. Never use hashing where you need to recover the original value.
- Cloud shared responsibility: cloud provider secures infrastructure. CUSTOMER is responsible for data privacy, access controls, encryption key management, and configuration.
- BYOK (Bring Your Own Key) in cloud: customer manages encryption keys, not the cloud provider. Prevents cloud provider from accessing customer data even in privileged contexts.
- Pseudonymization keys must be stored SEPARATELY from the pseudonymized data. Storing the key in the same database or adjacent system defeats the purpose.
- ABAC (Attribute-Based Access Control) enforces more granular privacy rules than RBAC alone — can implement purpose-based access (time-limited, context-specific, purpose-declared).
- Differential privacy: adds calibrated mathematical noise to query results. Protects individuals in aggregate queries. Does NOT encrypt or anonymize individual records.
- Homomorphic encryption: enables computation on encrypted data without decrypting. High performance overhead — not suitable for all use cases.
- Federated learning: keeps raw data local, only shares model updates (gradients). Reduces privacy risk but gradient leakage can still expose some training data information.
- LINDDUN is the privacy-specific threat modeling framework: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.
Common Traps
Confusing Pairs
Scenario Tips
A healthcare organization wants to share patient data with researchers while preventing re-identification. The dataset contains age, zip code, and diagnosis
Apply k-anonymity by generalizing quasi-identifiers (age ranges, zip code generalization) to ensure each combination of quasi-identifiers matches at least k individuals. Then consider l-diversity to ensure diverse diagnosis values within each group to prevent homogeneity attacks.
Encrypting the dataset (AES) prevents researchers from using the data at all. Hashing patient IDs does not address quasi-identifier re-identification. RBAC restricts who sees it but does not de-identify it.
An organization needs privacy-preserving aggregate analytics — queries over personal data to generate statistics without exposing individual records
Differential privacy. It adds calibrated noise to query results so individual records cannot be inferred from the statistical output while preserving aggregate accuracy.
Tokenization replaces individual identifiers but does not protect aggregate queries. Homomorphic encryption protects data during computation but is about the computation environment, not about the output leaking individual information.
A development team is implementing cookie consent for a GDPR-regulated EU application
Block all non-essential cookies until the user provides affirmative, granular consent through a consent banner. Only strictly necessary cookies may be set without consent. Consent must be as easy to withdraw as to give.
Setting cookies by default with an opt-out link violates GDPR's opt-in requirement. Auto-dismissing banners that assume consent from continued browsing do not constitute valid consent. Pre-ticked boxes are explicitly invalid.
An organization is building an AI model trained on personal data. What must be addressed FIRST?
Establish the appropriate legal basis for processing the personal data used for training. Documentation of the lawful basis and processing purpose must precede technical implementation.
Implementing encryption or differential privacy are technical controls that come after legal basis is established. Collecting more data to improve model performance violates data minimization without first having lawful basis.
A system processes highly sensitive personal data in a cloud environment. What control addresses the risk that the cloud provider could access the data?
Bring Your Own Key (BYOK) encryption, where the customer manages encryption keys outside the cloud provider's control. The provider can access encrypted storage but cannot decrypt without the customer's keys.
Standard cloud provider encryption (provider-managed keys) means the provider CAN access data. Network-level controls like VPC isolation protect against external attackers but not provider administrative access.
A system needs to enforce that a nurse can only access a patient's records for the specific purpose of treatment, not for administrative review
Attribute-Based Access Control (ABAC) with purpose as an attribute. RBAC alone cannot enforce this because the nurse role would have access regardless of the purpose of the access request.
RBAC is insufficient for purpose-based restrictions. Just-in-time access helps reduce standing access but does not itself enforce purpose limitation without an ABAC policy layer.