ICDL Data Protection (ICDL) common mistakes
ICDL Data Protection · Understand the traps and how to avoid them.
Treating any information about a person as personal data without checking whether it actually relates to an identified or identifiable individual (e.g., classifying an anonymous, aggregated sales total as personal data).
Candidates memorise 'personal data = data about people' and skip the identifiability test, especially for indirect identification via combinations of data.
What to do instead
For each data item, ask two questions in order: does it relate to a person, and can that person be identified directly or indirectly from it (alone or combined with other data)? Only then classify it as personal data.
Confusing a data controller with a data processor, for example labelling an external payroll bureau as the controller of employee salary data.
Candidates focus on who physically holds or operates on the data rather than who decides the purpose and means of processing.
What to do instead
Identify the decision-maker for 'why and how' the data is processed; that entity is the controller. An entity that only acts on the controller's documented instructions is a processor. Apply this test to the scenario, not to who runs the system.
Assuming consent is the default or only lawful basis, and treating a scenario as compliant simply because a consent box was ticked, even where consent was bundled, non-specific, or withdrawn.
Consent is the most familiar concept from everyday web browsing, so candidates over-apply it and overlook the alternatives (contract, legal obligation, vital interests, public task, legitimate interests).
What to do instead
Before accepting consent, check it is freely given, specific, informed, unambiguous, and withdrawable. If another basis fits better (e.g., processing necessary to perform a contract), select that basis instead and justify it in one sentence.
Missing purpose limitation and minimisation errors in a scenario, such as approving reuse of customer data for a new marketing purpose or collecting extra fields 'just in case'.
Candidates evaluate whether data is sensitive or secured but not whether the amount and use match the stated purpose.
What to do instead
For each processing activity, state the original purpose, then check every field and every new use against it. Flag any field that is not necessary for that purpose and any reuse without a compatible purpose or fresh lawful basis.
Treating a subject access request as something that can be refused or delayed because the request seems inconvenient, or requiring the requester to use a specific form or give a reason.
Candidates import customer-service instincts (verify, redirect, deprioritise) and forget access is a right that generally must be honoured within a fixed period.
What to do instead
Recognise any request from a data subject for their own data as valid regardless of form or stated reason. Apply the statutory response deadline (typically one month, extendable in limited cases) and only refuse on a recognised legal ground, with reasons given.
Confusing the right to erasure with a blanket obligation to delete on request, failing to spot exceptions such as legal retention duties or data needed for a legal claim.
Candidates learn erasure as an absolute-sounding right and do not pair it with the exceptions list.
What to do instead
When erasure is requested, first check whether a legal obligation, contract, or legal-claim exception applies. If yes, explain the retention and delete only the data not covered; if no, erase and confirm to the data subject.
Overlooking the requirement to notify a personal data breach to the supervisory authority within the deadline when the breach is likely to risk individuals' rights, or conversely notifying every trivial incident.
Candidates conflate 'any breach' with 'reportable breach' and are unsure of the risk threshold and timing.
What to do instead
Use a two-step test: does the breach risk individuals' rights and freedoms? If yes, notify the authority without undue delay and generally within 72 hours of becoming aware. Separately assess whether high risk requires informing affected individuals.
Approving a transfer of personal data to a third country without identifying a valid transfer mechanism, simply because the recipient is a reputable company.
Candidates focus on the recipient's trustworthiness and miss that location determines the legal transfer route.
What to do instead
Check the destination's adequacy status first. If not adequate, require a recognised safeguard (e.g., standard contractual clauses or binding corporate rules) before approving the transfer, and record which mechanism applies.
Applying data protection rules to purely personal or household activity, or to data about deceased persons, as if they were fully in scope.
Candidates apply the rules uniformly to every scenario without checking the household exemption or the fact that data protection typically concerns living individuals.
What to do instead
Screen the scenario first: is the processing purely personal/household with no professional or commercial link? If so, it is generally outside scope. Otherwise proceed with the full analysis.
Assuming a privacy notice or policy alone makes processing lawful, without checking that the actual practice matches what was disclosed and that a lawful basis exists.
Candidates equate documentation with compliance and stop at 'they published a notice'.
What to do instead
Cross-check the notice against actual practice: purpose, basis, recipients, and retention must match what happens. Flag any gap between stated and actual processing as a compliance failure, then verify the lawful basis independently.