ICDL Data Protection (ICDL) common mistakes
ICDL Data Protection · Understand the traps and how to avoid them.
Confusing a data controller with a data processor and assigning controller obligations to a party that only acts on instructions.
Candidates memorise the two terms as synonyms for 'organisation handling data' and miss that the controller determines purposes and means while the processor acts only on the controller's documented instructions.
What to do instead
For every scenario, ask two questions in order: who decides why the data is processed (controller) and who processes it only on someone else's instructions (processor). Then attach obligations accordingly, e.g. the processor typically has no independent duty to obtain the lawful basis.
Treating pseudonymised data as equivalent to anonymised data and concluding data protection rules no longer apply.
Both look like scrambled identifiers, so candidates assume any transformation removes personal data status, overlooking that pseudonymised data can be re-linked to a person with additional information.
What to do instead
Test reversibility: if anyone holding extra key information could re-identify individuals, the data remains personal and in scope. Only irreversibly anonymised data falls outside the rules.
Selecting a lawful basis such as legitimate interests for a public authority or for a purpose where consent was actually the appropriate basis, without justifying the choice.
Candidates pick whichever basis sounds most flexible rather than matching the basis to the context, the type of organisation, and the reasonable expectations of the individual.
What to do instead
Build a short decision checklist: is the organisation a public authority (legitimate interests usually unavailable for its public tasks)? Is the processing unexpected or intrusive? Can the individual genuinely refuse? Choose and document the basis that survives these tests.
Relying on pre-ticked boxes, implied consent, or silence as valid consent.
Everyday web patterns make opt-out or passive consent feel normal, and candidates transfer that familiarity into exam answers.
What to do instead
Apply the consent test: freely given, specific, informed, unambiguous, by a clear affirmative action, and as easy to withdraw as to give. Reject any option where the individual did nothing active or cannot refuse without detriment.
Approving transfers of personal data to another country without checking whether a transfer mechanism exists.
Candidates focus on the domestic processing rules and forget that moving data across borders is a separate compliance step requiring an adequacy decision, safeguards, or a specific derogation.
What to do instead
Whenever a scenario mentions servers, staff, or service providers in another country, add a transfer check: is there an adequacy finding, or appropriate safeguards such as standard contractual clauses, or a narrow derogation?
Confusing a personal data breach with a security incident generally, and reporting every minor incident to the regulator.
Candidates equate 'security problem' with 'reportable breach' and skip the threshold analysis about likelihood of risk to individuals.
What to do instead
Classify first: is personal data affected (breach), and is there a risk to rights and freedoms? Report to the regulator only where the risk threshold is met, and inform affected individuals where the risk is high, while keeping an internal record of all breaches.
Missing or misstating the breach notification deadline and the direction of notification (regulator versus data subjects).
Two different audiences and timeframes are easy to blur, and candidates swap who must be told and when.
What to do instead
Memorise a simple pair: notify the supervisory authority without undue delay and generally within 72 hours of becoming aware where required; notify affected individuals without undue delay where there is a high risk. State both audience and timing explicitly in answers.
Ignoring the requirement to apply appropriate technical and organisational measures and instead naming a single product as the security solution.
Candidates reach for familiar tools (encryption, a firewall) and treat buying one control as full compliance, missing the risk-based, layered obligation.
What to do instead
Answer in terms of a risk assessment plus a combination of measures: access control, encryption, staff training, testing, and regular review. Name controls as examples of measures, not as the obligation itself.
Treating a subject access request as something that can be refused or delayed because the request seems inconvenient or vaguely worded.
Candidates apply customer-service instincts rather than the legal rule that requests must be facilitated and only narrow exceptions apply.
What to do instead
Default to fulfilling the request within the statutory period, clarifying only where genuinely needed, and reserve refusal for specific documented exemptions. Verify identity if there are doubts, but do not use that as a stalling tactic.
Confusing the right to erasure with a general right to have any data deleted on demand, and overlooking the other rights such as rectification, restriction, portability, and objection.
Erasure gets the most attention, so candidates overstate its scope and forget the surrounding rights and their limits.
What to do instead
Learn the rights as a set with their conditions: erasure applies subject to exceptions such as legal obligations or legal claims; rectification corrects inaccurate data; restriction and objection have their own triggers; portability applies to data provided by the individual processed by automated means. Match the right to the facts before answering.