CDPSE Certified Data Privacy Solutions Engineer Exam Topics and Questions

Privacy Governance sets the foundation for everything else on this exam. Before you can engineer a solution or assess a risk, you need to know what personal information is, which principles govern how it must be treated, and who in an organisation is accountable when things go wrong. This topic rewards breadth over depth: you are expected to recognise how governance components connect, not to recite a single regulation verbatim.

– Principles, law, and documentation

Personal information is the currency of privacy law, and the exam tests whether you can identify what qualifies, including the less obvious categories such as inferred or derived data. Privacy by Design, consent, and transparency are not interchangeable: each imposes a distinct obligation at a distinct point in the data lifecycle, and the exam will place them in scenarios where only one fits. Privacy laws and regulations appear in context, meaning you need to know what a given regime requires of a controller or processor, not just which country enacted it. Documentation, including policies and guidelines, is tested on fitness for purpose: a policy that cannot be operationalised is as problematic as no policy at all.

– Operations, third parties, and data subject rights

Organisational culture and structure questions ask you to assign responsibilities correctly. A Data Protection Officer, a privacy champion embedded in an engineering team, and a legal counsel each have different remits, and the exam places them in conflict to see whether you know the boundary. Vendor and supply chain management is tested on what due diligence looks like before a contract is signed and what contractual clauses must survive it. Incident management in a privacy context is distinct from a security incident response: notification timelines, regulatory reporting thresholds, and internal escalation paths are all fair game. Data subject rights questions, covering access, erasure, portability, and objection, require you to know both what the right entitles the individual to and what a reasonable organisational response looks like within the required timeframe.

How PRIVACY GOVERNANCE is tested

At 20% of the exam, this topic appears frequently enough that gaps in it will cost you marks across the paper, not just in the questions you identify as governance questions. Items tend to be scenario-based: a DPO receives a data subject erasure request on the same day a regulator opens an investigation into the same data, and you are asked what the organisation must do first. That ordering question is the template. Items reward knowing which obligation takes precedence when two legitimate requirements collide. Candidates lose marks by defaulting to the most protective-sounding option without checking whether it is legally required or merely best practice. The distinction between a policy (what the organisation commits to) and a guideline (how staff are expected to meet that commitment) appears in documentation questions, and conflating the two is a common error. Vendor management questions punish candidates who treat a signed contract as the end of due diligence rather than the beginning of an ongoing monitoring obligation.

Where governance defines what the organisation commits to, risk management and compliance tests whether those commitments hold under pressure. This topic asks you to move between two registers: the analytical register of assessing and responding to privacy risk, and the evidential register of proving to an auditor or regulator that controls are working. Candidates who treat these as separate disciplines tend to struggle with the integrated scenario items that make up most of this weight.

– Risk identification, assessment, and response

The risk management process in a privacy context follows the same broad arc as enterprise risk management, but the exam tests the privacy-specific adaptations. A Privacy Impact Assessment is the centrepiece here: you need to know when one is triggered, what it must cover, and what happens when its findings recommend a change that the business resists. Privacy training and awareness is not a soft topic; items ask whether a given training intervention would actually reduce the identified risk, which requires you to connect threat and control. Threats and vulnerabilities in this context include both technical exposures and process failures, such as a consent mechanism that captures agreement without meeting the legal standard. Risk response options, avoid, mitigate, transfer, accept, are tested on proportionality: the exam rewards the response that is appropriate to the residual risk, not the most aggressive one available.

– Frameworks, evidence, and monitoring

Privacy frameworks appear as reference architectures rather than as objects of study in their own right. The exam asks you to select or apply a framework element to a described situation, which means you need to know what each framework is designed to achieve and where its scope ends. Evidence and artifacts questions are practical: what documentation would demonstrate to a regulator that a control was operating effectively at the time of an incident? Candidates who confuse a policy document with evidence of its implementation consistently choose the wrong option here. Program monitoring and metrics items ask you to distinguish a metric that measures activity, number of training sessions completed, from one that measures outcome, percentage of staff who can correctly identify a reportable incident. The outcome metric is almost always what the item rewards.

How PRIVACY RISK MANAGEMENT AND COMPLIANCE is tested

At 18%, this topic delivers a steady stream of items throughout the exam. Many of them are integrative: a scenario will describe a risk finding from a PIA and then ask what the compliance team should produce as evidence that the finding was addressed. That two-step structure, assess then evidence, is the dominant pattern. Items reward candidates who can close the loop between a risk decision and its audit trail. The trap that costs the most marks is selecting a response that is thorough but disproportionate: accepting a minor residual risk is a legitimate choice, and the exam penalises candidates who escalate every finding to a full remediation project. Training and awareness questions punish the assumption that delivering training equals reducing risk; the item will describe a training programme and ask whether it addresses the specific threat, and the answer turns on the match between threat type and training content, not on whether training happened at all.

At 23%, Data Life Cycle Management is the second-heaviest topic on the exam. It follows risk management logically: once you know what risks personal data creates, you need to control that data from the moment it is collected to the moment it is verifiably destroyed. The topic splits cleanly into what happens to data while it is active and what happens when its purpose is exhausted, and both halves carry real exam weight.

– Collection, classification, and processing

A data inventory is the starting point for most privacy engineering decisions, and the exam tests whether you understand what a complete inventory must capture: data type, owner, location, processing purpose, and legal basis. Dataflow diagrams are tested on their function as a decision support tool, not as a drawing exercise. If a diagram cannot show where personal data crosses a jurisdictional boundary, it is not fit for purpose. Data quality, specifically accuracy, is examined in the context of harm: inaccurate personal data used in an automated decision creates a different category of risk than inaccurate inventory data, and items will ask you to distinguish them. Data use limitation is the principle that data collected for one purpose may not be repurposed without a fresh legal basis, and the exam places it in scenarios involving analytics projects that want to reuse existing datasets. Data analytics, including aggregation, AI applications, and data warehouse architectures, is tested on the privacy risks each introduces rather than on how the technology works.

– Retention, transfer, disclosure, and destruction

Data minimisation is tested as a design constraint, not a cleanup activity: the exam asks you to identify where minimisation should have been applied at collection, not after the fact. Data disclosure and transfer questions focus on cross-border transfers and the mechanisms that make them lawful, such as adequacy decisions, standard contractual clauses, and binding corporate rules. You do not need to recite treaty text, but you do need to know which mechanism applies in which scenario and what its conditions are. Data storage and retention questions ask you to match a retention period to its legal or business justification and to identify when retention becomes a liability rather than a safeguard. Data destruction is tested on verifiability: the exam rewards destruction methods that produce evidence of completion and penalises candidates who treat deletion from a primary system as equivalent to destruction across all storage locations, including backups and archives.

How DATA LIFE CYCLE MANAGEMENT is tested

The weight here means you will see more items from this topic than from any other except Privacy Engineering. Many items describe a specific point in the data lifecycle and ask what control should apply at that point. The structure rewards candidates who think in lifecycle terms: what is the legal basis, what is the retention limit, who is authorised to access it, and how is destruction confirmed? Candidates lose marks most often on destruction and transfer questions. On destruction, the trap is equating deletion with destruction; the exam consistently rewards answers that account for all copies, including those held by processors and in backup systems. On transfer, the trap is selecting a transfer mechanism without checking whether its conditions are satisfied in the described scenario. Analytics items are a growing source of difficulty because they require you to apply use limitation and minimisation principles to technologies that are designed to aggregate and infer, which creates tension that the item is specifically testing.

Privacy Engineering carries 39% of the exam. That weight means your result on this topic alone will largely determine whether you pass. The topic is technical in character: it expects you to reason about infrastructure, security controls, and privacy-specific technologies as an engineer would, connecting a privacy requirement to a concrete implementation choice. Candidates with a governance background who have not worked with technical controls will feel this gap most acutely here.

– Technology stacks and development practices

Infrastructure and platform questions cover both legacy environments, where privacy controls may be retrofitted, and cloud computing, where the shared responsibility model changes what the organisation controls directly. The exam tests whether you can identify which privacy risks are introduced by a given infrastructure choice, not whether you can configure the infrastructure itself. Devices and endpoints are tested on the privacy risks of data at rest and in transit on hardware that the organisation may not fully control, including employee-owned devices and IoT endpoints. Connectivity questions address the risks introduced by network architecture choices. The Secure Development Life Cycle is tested on where privacy requirements must be embedded: the exam rewards candidates who place privacy controls at the design and requirements stage rather than as a post-development review. APIs and cloud-native services introduce their own data exposure risks, particularly around what data is logged by default and what third-party services receive through API calls.

– Security controls with privacy implications

Asset management in a privacy context means knowing where personal data lives, which assets process it, and who is responsible for each. Identity and access management is tested on least privilege and on the controls that prevent authorised users from accessing more personal data than their role requires. Patch management and hardening questions ask you to connect an unpatched vulnerability to a specific category of privacy risk rather than to treat patching as a generic security hygiene task. Communication and transport protocols are examined on what data they expose in transit and under what conditions that exposure becomes a privacy incident. Encryption and hashing are tested on fitness for purpose: symmetric versus asymmetric encryption, hashing as a one-way function, and the conditions under which hashed data still qualifies as personal information under major regulatory frameworks. Monitoring and logging sit at the intersection of security and privacy because logs themselves contain personal data, and the exam tests whether your logging strategy creates new privacy obligations.

– Privacy-specific controls and emerging technologies

Consent tagging is tested as an engineering problem: how does a system record, store, and honour a consent decision across all downstream processing, and what happens when consent is withdrawn? Tracking technologies, including cookie management and device fingerprinting, are examined on the technical mechanisms that implement or circumvent consent, not just on the regulatory requirement to obtain it. Anonymisation and pseudonymisation are the most technically demanding sub-topics in this group. The exam tests the distinction precisely: pseudonymised data remains personal data under most frameworks because re-identification is possible, and items reward candidates who apply the correct legal classification to a described technique. Privacy Enhancing Technologies cover a range of approaches, from differential privacy to synthetic data generation, and items ask you to match a PET to the privacy problem it solves. AI and machine learning considerations focus on the privacy risks that arise from training data, model outputs, and inference, particularly where a model can surface personal information that was not explicitly included in its inputs.

How PRIVACY ENGINEERING is tested

The 39% weight means this topic is not a specialism; it is the core of the exam. Items are predominantly scenario-based and technical: a described system architecture, a development decision, or a deployed control, followed by a question about what privacy risk it introduces or what control should be applied. Items reward candidates who can move from a technical description to a privacy consequence without an intermediate step. The most common source of lost marks is treating security controls and privacy controls as synonymous. Encryption protects confidentiality but does not by itself satisfy a data minimisation requirement. Logging provides accountability but creates a new dataset of personal data. The exam is specifically designed to test whether you see that distinction. On anonymisation and pseudonymisation, items reward the candidate who applies the correct regulatory classification to the technique described, not the candidate who knows the technique in the abstract. AI and ML items are the area where candidates with no engineering background are most exposed, because the privacy risks of inference and model inversion require you to reason about what a system can produce, not just what data it was given.