DPO common mistakes
DPO · Understand the traps and how to avoid them.
Treating 'personal data' as limited to names, emails, and account numbers, and concluding that aggregated, pseudonymised, or inferred data falls outside the definition.
Candidates carry over colloquial intuitions about 'personal information' and skip the definitional step, so they miss that pseudonymised data remains personal data when re-identification is possible and that indirect identifiers count.
What to do instead
Before answering, apply a two-part test explicitly: (1) is the information about an identified or identifiable natural person, directly or indirectly, by any means reasonably likely to be used; (2) does pseudonymisation remove identifiability or only reduce it? Write the test result in one sentence, then choose the option that matches it.
Selecting the strongest-sounding control (e.g., 'delete all data' or 'obtain fresh consent') as the answer to a scenario where a narrower lawful basis or a documented balancing test is the correct route.
Candidates confuse 'most protective' with 'most legally correct' and answer from instinct about privacy virtue rather than from the hierarchy of lawful bases and necessity/proportionality reasoning.
What to do instead
For every processing scenario, run the sequence: identify the purpose, test each lawful basis in order, then check necessity and proportionality. Eliminate options that change the processing purpose or impose measures beyond what the risk requires, even if they sound maximally cautious.
Answering data subject rights questions with a generic 'respond within a reasonable time' instead of applying the specific statutory deadline and the specific permitted extension and refusal conditions.
Candidates memorise the existence of rights but not the operational parameters (timeframes, extension triggers, fee rules, identity verification), and exam distractors are built precisely around plausible-sounding but wrong timeframes.
What to do instead
Build a one-page rights matrix: right, deadline, extension condition and length, grounds for refusal, and required notice to the requester. Drill it until each parameter is recalled without hesitation, and in scenarios check whether the clock has already run.
Approving a cross-border transfer because a contract clause exists, without confirming the transfer mechanism is valid for that destination and that a transfer impact assessment was done.
Candidates equate 'we have a signed agreement' with 'the transfer is lawful', collapsing the distinct steps of mechanism selection, supplementary measures, and ongoing monitoring into a single checkbox.
What to do instead
For transfer questions, verify four things in order: legal basis for the export, valid transfer mechanism for that jurisdiction, assessment of the destination's legal environment, and supplementary technical or organisational measures. If any element is missing, the transfer is not supportable.
Answering breach-notification questions by notifying every regulator and every data subject by default, or conversely by waiting for confirmed harm before notifying anyone.
Candidates either over-apply a single mental model ('always notify') or under-apply it ('notify only if damage occurs'), missing the risk-threshold test and the distinction between notifying the supervisory authority and notifying individuals.
What to do instead
Use a decision tree: is there a breach of security leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure? Then assess likelihood of risk to rights and freedoms, then assess high risk for individual notification, then check processor-to-controller duties and any sector-specific regimes. Answer the specific branch the scenario asks about.
Treating privacy by design and data protection impact assessments as documentation exercises to be completed after the system is built, and choosing options that place the DPIA at go-live.
Candidates read DPIA as a compliance artefact rather than a decision gate, so they accept timelines where design is already frozen and the assessment can only rubber-stamp it.
What to do instead
Anchor the principle: assessment happens before processing begins and before design decisions are locked, is reviewed when risk changes, and feeds residual-risk acceptance to the right accountable owner. Reject any option placing assessment after implementation or omitting the high-risk trigger test.
Confusing accountability evidence with activity: choosing 'we have a policy' over 'we can demonstrate the control operated and was tested', and treating records of processing as optional paperwork.
Candidates conflate having documentation with being able to demonstrate compliance, and underestimate how much of governance testing targets evidence of operation rather than existence of documents.
What to do instead
For every governance question, ask 'what evidence would a regulator or auditor accept?' Prefer answers that produce dated, attributable records - training completion, assessment sign-off, test results, issue remediation - over answers that only assert a document exists.
Assigning privacy roles by job title rather than by function, so the candidate names the IT manager or the lawyer as the data protection officer or makes the DPO the decision-maker on processing.
Candidates map familiar organisational charts onto statutory roles and forget the independence requirement, the conflict-of-interest rule, and the distinction between the controller's decision authority and the DPO's advisory and monitoring mandate.
What to do instead
State each role's function before selecting a person: controller decides purposes and means; processor acts on instructions; DPO informs, advises, monitors, and is consulted but does not decide, and must not hold a role that determines purposes or means. Test the proposed assignment against the conflict rule.
Performing a qualitative risk rating without linking it to the organisation's defined risk criteria, appetite, or treatment options, and then failing to record who accepted the residual risk.
Candidates treat risk assessment as a labelling task (high/medium/low) rather than a decision process, so they skip likelihood-times-impact calibration, control effectiveness testing, and formal acceptance.
What to do instead
Use the standard sequence in every risk question: identify asset and threat, assess inherent likelihood and impact against stated criteria, evaluate existing controls for design and operating effectiveness, calculate residual risk, select treatment (avoid, reduce, transfer, accept), and name the accountable acceptor with a review date.
Answering third-party and vendor questions with 'include privacy terms in the contract' only, omitting due diligence, ongoing monitoring, sub-processor controls, and audit or termination rights.
Candidates reduce vendor governance to a contractual clause and miss the lifecycle view, so they choose the option that looks complete but covers only one phase of the relationship.
What to do instead
Structure vendor answers across the full lifecycle: pre-contract due diligence and risk tiering, contractual allocation of controller/processor duties and sub-processor approval, technical and organisational measures, monitoring and audit rights, breach and assistance obligations, and exit with data return or deletion. Select the option that spans the phase the scenario actually concerns.