CDPSE Exam Domains and Outline

Current CDPSE domain weights

The current structure took effect in 2025. Earlier materials may show three domains, with privacy architecture as a separate area. The updated outline has four domains and a distinct Privacy Risk Management and Compliance section. Use the version aligned with your exam date and ensure study materials cover the current task statements.

Domain 1: Privacy Governance

Privacy Governance accounts for 20 percent. The outline includes personal information, privacy principles such as privacy by design, consent, and transparency, laws and regulations, policies and guidelines, organizational culture and responsibilities, vendors, incident management, and data subject rights and notification.

This domain asks how an organization sets direction and accountability. A privacy professional may map requirements to policies, clarify who owns a processing purpose, review vendor controls, or support a response to a rights request. Memorizing a principle is only the first step; the exam may ask how it changes a design or operational decision.

For example, a company changes the purpose for using account data. Governance work identifies who approves that purpose, which obligations and expectations apply, how notice and choice are handled, and what documentation should be retained. A technical team can implement the change only after those questions are resolved.

Domain 2: Privacy Risk Management and Compliance

This domain is 18 percent. Risk topics include policies and process, privacy-focused assessments such as a PIA, training, threats and vulnerabilities, and risk response. Compliance topics include frameworks, evidence and artifacts, program monitoring, and metrics.

A useful assessment connects processing to possible harm. Identify the information, purpose, people affected, recipients, systems, and retention. Consider threats and vulnerabilities, then evaluate the likely impact and existing measures. A PIA should inform choices while the product can still change, not become a form completed after launch.

Compliance evidence should demonstrate operation. A signed policy states an expectation; access-review records or sampled configuration evidence can show what happened. Metrics need definitions and owners. A count of completed assessments is not proof that the assessments found or reduced privacy risk.

Domain 3: Data Life Cycle Management

Data Life Cycle Management contributes 23 percent. Collection and processing tasks include inventory, flow diagrams, classification, quality, use limitation, and analytics such as aggregation, AI, or a data warehouse. Persistence and destruction tasks include minimization, disclosures and transfers, storage, retention, archiving, and destruction.

Think in terms of a data path. Where did information originate? Which systems copy it? Who receives it? What derived data are created? When does the original purpose end? What legal or operational reason supports continued retention? These questions reveal places where policies and system behavior diverge.

Suppose an organization deletes an account from its main application but retains exports in an analytics warehouse and vendor backup. The deletion procedure is incomplete unless the organization understands those copies, determines applicable retention limits, restricts use while data are retained, and arranges deletion or expiry across systems. A single database command does not establish life cycle control.

Domain 4: Privacy Engineering

Privacy Engineering is 39 percent, the largest domain. Technology stacks cover infrastructure, platforms, endpoints, connectivity, secure development, APIs, and cloud-native services. Related security controls include asset management, identity and access management, patching, hardening, protocols, encryption, hashing, monitoring, and logging. Privacy controls include consent tagging, tracking technologies, anonymization, pseudonymization, PETs, and AI/ML considerations.

The exam does not reduce engineering to a list of products. A good control fits the architecture, data, threat, and purpose. Least privilege can reduce unnecessary access; encryption can protect data under specified conditions; logs can support detection and accountability. Each needs configuration, ownership, testing, and monitoring.

Distinguish anonymization from pseudonymization. Replacing names with tokens may reduce direct identification, but linkage remains possible if a key or auxiliary information exists. Anonymization aims to prevent identification, which requires considering realistic data combinations and access. Do not label a dataset anonymous merely because direct identifiers have been removed.

For AI and analytics, examine data provenance and permission, training and inference use, sensitive attributes, output exposure, retention, and monitoring. Aggregation can still expose people in small groups. A model can produce unfair outcomes or reveal patterns from its inputs. Controls depend on the scenario, but privacy review should include technical design and operational accountability.

How to read the task statements

The outline also contains supporting tasks that cut across domains: identify requirements, align programs with laws and expectations, advise on life cycle practice, assess privacy impact, integrate privacy by design, work with stakeholders, evaluate suppliers, support incident response, maintain inventories, classify data, report metrics, and promote accountability, fairness, and transparency.

Use these tasks to practise action verbs. “Identify” may call for gathering requirements or data flows. “Evaluate” requires criteria and evidence. “Design” means translating requirements into a workable control. “Monitor” requires ongoing measurement and response. An exam answer that jumps to implementation before establishing the requirement or risk may be out of sequence.

Worked cross-domain example

A retailer wants to use customer support transcripts to train a product recommendation model. Governance clarifies the purpose, transparency, and accountability. Risk assessment examines sensitive content, unexpected inferences, vendor access, and potential effects on customers. Life cycle work maps transcript sources, derived data, retention, and deletion. Engineering constrains access, removes or transforms unnecessary fields, records consent or other permitted state where applicable, tests outputs, and monitors misuse.

If the question asks what to do first, the best response depends on what is already known. If the processing is not mapped, establish data flows and purpose before choosing controls. If the model is already exposing transcripts, contain access and address the incident while the assessment continues. Domain labels help organize thought, but the question’s facts determine sequence.

Study by weight and weakness

Give Privacy Engineering substantial time because it is 39 percent, but do not neglect Governance, Risk and Compliance, or Data Life Cycle Management. A candidate who works in engineering daily may still need practice with governance and rights processes. A privacy lawyer may need more study of identity controls, secure development, and data architecture.

1. Read each official task and explain what work product or decision it implies.
2. Map the task to an example system and the data moving through it.
3. Identify which people make decisions and which teams operate controls.
4. Practise linking requirements, risk, data handling, technical design, and evidence.
5. Revisit weak tasks with new scenarios rather than memorizing one answer pattern.

Apply the four domains to one product change Suppose a service wants to reuse support-chat transcripts to train an internal classifier. Governance asks who approves the new purpose and who owns the policy decision. Risk and compliance ask what privacy risks, commitments, and applicable obligations arise from the secondary use. Lifecycle management identifies transcripts, backups, derived labels, access, retention and deletion. Privacy Engineering asks what controls can limit fields, separate training data, restrict access and validate outputs. The domains are connected but not interchangeable. A technical filter may remove account numbers, but it does not approve a new purpose. A policy approval does not prove production pipelines remove the fields. A retention rule does not show that model artifacts follow it. Strong analysis traces the decision through ownership, risk, data handling and implementation evidence. When a question presents several plausible controls, identify what has already been decided. If it asks which technical control implements an approved retention rule, governance approval is no longer the answer. If it asks whether a new data use may proceed, a code change is premature. The sequence of work is often the clue. A useful revision method is to take one outline task per session and create a short case that requires it. Write the fact that triggers the task, the person or team responsible, the action, and the evidence that would show completion. Then connect the case to a second domain. This keeps study anchored in official tasks while building cross-domain reasoning.

Apply the four domains to one product change Suppose a service wants to reuse support-chat transcripts to train an internal classifier. Governance asks who approves the new purpose and who owns the policy decision. Risk and compliance ask what privacy risks, commitments, and applicable obligations arise from the secondary use. Lifecycle management identifies transcripts, backups, derived labels, access, retention and deletion. Privacy Engineering asks what controls can limit fields, separate training data, restrict access and validate outputs. The domains are connected but not interchangeable. A technical filter may remove account numbers, but it does not approve a new purpose. A policy approval does not prove production pipelines remove the fields. A retention rule does not show that model artifacts follow it. Strong analysis traces the decision through ownership, risk, data handling and implementation evidence. When a question presents several plausible controls, identify what has already been decided. If it asks which technical control implements an approved retention rule, governance approval is no longer the answer. If it asks whether a new data use may proceed, a code change is premature. The sequence of work is often the clue. A useful revision method is to take one outline task per session and create a short case that requires it. Write the fact that triggers the task, the person or team responsible, the action, and the evidence that would show completion. Then connect the case to a second domain. This keeps study anchored in official tasks while building cross-domain reasoning.