PECB CDPO common mistakes
PECB CDPO · Understand the traps and how to avoid them.
Answering scenario questions by quoting the GDPR article number and stopping there, without stating what the controller must actually do next in the described situation.
Candidates memorise article numbers during revision and treat recall as the goal, but CDPO scenario items are written to test application: the article number alone does not resolve the tension the scenario sets up (for example a lawful basis that exists but is incompatible with a new purpose).
What to do instead
For every scenario item, draft a two-part answer in notes: the principle or obligation engaged, then the concrete action or decision. Practise rewriting each article you revise as 'this means the organisation must...' and check that your chosen option contains an action, not just a citation.
Treating 'consent' as the default lawful basis for every processing activity described in a question, including HR, payroll, and public-authority tasks.
Consent feels intuitive and is the most rehearsed basis, so it becomes a reflex. Candidates miss the tests of freely given consent in employment relationships and the prohibition on consent as a basis for public authorities acting in their public task.
What to do instead
Build a one-page decision table mapping typical processing activities (employment contract performance, legal obligation for tax records, legitimate interests for fraud prevention, public task, vital interests) to the basis that actually fits, and rehearse the 'freely given' indicators: imbalance of power, detriment on refusal, bundling, granularity.
Confusing the roles of controller, joint controller, and processor when an external service provider is involved, and assigning accountability to the vendor.
Outsourcing language ('our payroll provider handles it') suggests the vendor owns the obligation, and the joint-controller test (common determination of purposes and means) is subtle. Candidates also forget that a processor becomes a controller for its own purposes, such as service improvement.
What to do instead
For each third party in a scenario, ask two questions in order: who determines the purpose, and who determines the essential means? Then check whether the contract reflects that answer. Practise classifying borderline cases: cloud hosting with the customer choosing categories of data, analytics added by the vendor, and shared marketing campaigns.
Describing the DPO as personally liable for compliance failures or as the decision-maker who signs off processing activities.
The DPO title suggests ownership, and candidates conflate the monitoring and advisory role with executive accountability, which sits with the controller's senior management. This produces wrong answers on escalation, independence, and conflict-of-interest items.
What to do instead
Memorise the DPO's task list as monitor, advise, inform, train, and liaise with the supervisory authority, and pair it with the statement that the controller remains accountable. Rehearse conflict-of-interest scenarios (a DPO also holding the role of head of IT or marketing) and state clearly that the DPO does not decide, but advises and monitors.
Skipping or superficially performing the accountability documentation in answers, treating records of processing, policies, and training evidence as optional paperwork.
Accountability is often read as a principle to be described rather than demonstrated, so candidates omit the evidence layer. Items that ask how an organisation proves compliance are then answered with intentions rather than artefacts.
What to do instead
Prepare a list of accountability artefacts with their purpose: records of processing activities, retention schedule, DPIA register, processor contract clauses, training logs, breach log, and complaint log. In answers, name the artefact and say what it evidences and who reviews it.
Running a DPIA only after the processing is designed and live, or treating it as a one-off document rather than a process with review triggers.
Candidates associate impact assessment with project approval gates and forget that the assessment must inform the design, and must be revisited when the risk changes. Questions describing a system already in production are then answered as if assessment were still possible only at the start.
What to do instead
Learn the DPIA lifecycle as screening, description of processing, necessity and proportionality assessment, risk identification and evaluation, mitigation, sign-off, and review. For each scenario, state the trigger (new technology, large-scale special category data, systematic monitoring, high-risk combination) and the review condition.
Assessing risk by listing threats only, without stating likelihood, severity, and impact on individuals, and without connecting mitigations to specific risks.
Risk registers in many organisations are threat lists, and candidates copy that pattern. Data protection risk is about harm to individuals, not only harm to the organisation, and exam items reward the distinction between the two and the link from each risk to a named control.
What to do instead
Use a fixed structure for every risk answer: source of risk, potential impact on data subjects, likelihood, severity, existing controls, residual risk, and owner. Practise converting organisational risks (fine, reputational damage) into individual harms (discrimination, identity theft, financial loss, distress) and back.
Designing a privacy programme as a policy document only, with no governance structure, roles, metrics, or reporting line described.
Candidates equate programme implementation with drafting policies and privacy notices, because those are the visible outputs. They then miss items on operating models, steering committees, RACI, and key performance or risk indicators.
What to do instead
Learn the programme as a set of interlocking components: governance and accountability, policies and standards, records and inventories, risk and DPIA process, training and awareness, incident management, third-party management, and monitoring. For any implementation question, name the component, the owner, the artefact, and the measure of success.
Handling breach scenarios by focusing only on the 72-hour notification clock and ignoring the risk assessment, the processor-to-controller flow, and the record-keeping duty.
The 72-hour figure is the most memorable number in the field and dominates revision. Candidates then skip the threshold question (is there a risk to rights and freedoms?), the processor's obligation to notify without undue delay, and the internal breach register.
What to do instead
Rehearse a breach as a sequence: detect and contain, assess risk to individuals, decide whether notification to the supervisory authority is required and whether data subjects must be informed, notify the processor's controller without undue delay where applicable, document the incident regardless of notification outcome, and review lessons learned.
Treating monitoring and improvement as a final audit step rather than a continuous cycle, and answering 'review annually' without defining indicators, owners, or escalation paths.
Audit and review are taught as end-of-year activities, so candidates produce vague periodic statements. Items that test maturity, continuous improvement, or management review then receive answers with no measurable content.
What to do instead
Describe monitoring with named indicators (training completion, DPIA closure rate, breach response time, subject request turnaround, vendor assessment coverage), a review cadence tied to risk, and an escalation route to senior management. Frame improvement as plan-do-check-act with documented corrective actions and follow-up verification.