ICS ECDPO common mistakes
ICS ECDPO · Understand the traps and how to avoid them.
Treating the lawful basis for processing as a single choice made once at project kickoff and never revisiting it when the purpose or data flows change.
Candidates learn the six lawful bases as a list to memorise and pick one, missing that basis selection is purpose-specific and must be reassessed when processing changes.
What to do instead
For each scenario, state the purpose, map it to a basis, and explicitly note when a change in purpose, recipients, or retention would require re-evaluating the basis.
Accepting consent as valid whenever the data subject ticked a box, without checking that it was freely given, specific, informed, unambiguous, and withdrawable as easily as given.
Candidates conflate 'consent was obtained' with 'consent is valid' and skip the validity conditions when the facts look superficially compliant.
What to do instead
Run every consent scenario through the validity conditions one by one and flag any imbalance of power, bundling, pre-ticked boxes, or difficult withdrawal as invalidating.
Confusing the controller/processor roles when assessing responsibility, then assigning breach notification or DSAR duties to the wrong party.
Candidates focus on who physically holds the data rather than who determines the purposes and means, so hosting or outsourcing arrangements mislead them.
What to do instead
Determine the role first by asking who decides the purpose and essential means, then apply the duties that attach to that role before analysing any other issue.
Responding to a data subject request by describing internal process steps rather than applying the statutory clock, extension conditions, and permitted exemptions to the facts given.
Candidates know the rights exist but not the operational rules (verification, timeframes, extension triggers, fee limits), so they answer generically.
What to do instead
For each request, state the start date, the applicable deadline, whether an extension is lawfully available and why, and which specific exemption applies.
Skipping a DPIA because the processing is small in scale or uses familiar technology, instead of checking it against the defined high-risk triggers.
Candidates substitute gut feel about risk for the structured screening criteria and miss that systematic monitoring, special category data, or innovative technology can trigger a DPIA regardless of size.
What to do instead
Always run the screening criteria explicitly and record the outcome either way, including the reasoning when concluding a DPIA is not required.
Treating a DPIA as a one-off document completed before launch rather than a living assessment that is reviewed and updated when risks or processing change.
Candidates treat DPIAs as a compliance artefact to produce rather than a risk-management process with monitoring and review obligations.
What to do instead
In any DPIA answer, include the review trigger, the owner, and how residual risk will be monitored after implementation.
Reporting every security incident as a personal data breach, or conversely waiting for confirmed harm before notifying, instead of applying the breach definition and risk threshold.
Candidates collapse 'incident' and 'notifiable breach' into one concept and skip the assessment of likelihood and severity of risk to individuals.
What to do instead
Classify the event as a security incident first, then test it against the personal data breach definition, then assess risk to rights and freedoms before deciding on notification.
Notifying the supervisory authority without also assessing the separate duty to inform affected data subjects when the breach is likely to result in high risk.
Candidates learn the regulator notification duty as the primary obligation and overlook that individual notification is a distinct test with its own threshold.
What to do instead
For every breach scenario, answer three separate questions: is it a personal data breach, is it notifiable to the authority, and is individual notification required, with reasoning for each.
Assuming a transfer mechanism alone makes an international transfer lawful, without checking that a transfer restriction applies and that supplementary safeguards and transfer risk assessment are in place.
Candidates memorise mechanisms such as adequacy, SCCs, and BCRs as a checklist and treat selecting one as the complete answer.
What to do instead
Work through three steps in order: does a transfer restriction apply, which transfer mechanism is valid for this destination and relationship, and what supplementary measures address residual risk.
Omitting accountability evidence such as records of processing, training logs, DPO involvement, and vendor due diligence when answering governance scenarios.
Candidates treat accountability as a principle to state rather than a set of demonstrable artefacts, so answers assert compliance without showing how it is evidenced.
What to do instead
For governance questions, name the specific record, policy, or log that would demonstrate compliance and who owns maintaining it.