ICS CDPP common mistakes
ICS CDPP · Understand the traps and how to avoid them.
Treating 'consent' as the default lawful basis for every processing activity and answering scenario questions as if consent were required before any other basis can be considered.
Consent is the most familiar and most heavily publicized basis, so candidates anchor on it and overlook that public task, legal obligation, contract, vital interests, and legitimate interests may fit better and are sometimes mandatory (e.g., public authorities cannot rely on legitimate interests for their public tasks).
What to do instead
Before answering, list all six lawful bases and eliminate them one by one against the facts given (who the controller is, whether processing is necessary, whether a public authority is acting in its public capacity). Choose consent only when the facts show genuine optionality and the question hinges on withdrawal or granularity.
Applying one jurisdiction's rules to a scenario governed by another, for example importing GDPR-style requirements into a US state-law question or assuming a single federal US privacy statute exists.
Most study material is GDPR-centric, and candidates generalize from it. US law is sectoral and state-by-state (e.g., HIPAA, GLBA, COPPA, CCPA/CPRA and other state statutes), so a general 'privacy law' instinct produces wrong answers.
What to do instead
For each scenario, first identify the governing instrument named or implied (statute, regulation, or framework), then recall that instrument's specific thresholds, definitions, and exemptions. Build a one-page comparison sheet of scope triggers per regime and rehearse it.
Confusing controller and processor roles, or missing joint controllership, when answering questions about who owes a duty (notice, DSAR handling, breach notification, appointing a DPO).
Candidates focus on the data flow rather than on who determines purposes and means. Outsourcing language ('our vendor processes it') is read as transferring responsibility, when the controller usually retains accountability.
What to do instead
For every scenario, write two lines: who decides why (purpose) and who decides how (means). Assign duties from that determination, and remember a processor acting outside instructions becomes a controller for that processing.
Answering data subject rights questions with a generic 'respond promptly' instead of the specific statutory deadline, extension conditions, and permitted grounds for refusal.
Deadlines and exceptions differ across regimes and are easy to blur (e.g., one month with a possible two-month extension under GDPR versus 45 days under CPRA with an extension). Candidates rely on the gist rather than the exact rule.
What to do instead
Memorize a small table of deadlines, extension triggers, and refusal grounds for each regime on the exam, and practice identifying which specific right (access, erasure, portability, objection) the scenario actually invokes before selecting a timeline.
Treating a DPIA as a paperwork step to be completed after processing begins, or recommending one only when a breach has already occurred.
Candidates conflate DPIA with incident response or with generic risk assessment, and forget it is a pre-processing obligation triggered by high-risk indicators (e.g., large-scale special category data, systematic monitoring, new technology).
What to do instead
Learn the trigger list and the required DPIA content, and in scenarios check timing first: if processing has not started and risk indicators are present, the answer is 'conduct a DPIA before processing,' not 'document afterwards.'
Treating every security incident as a notifiable personal data breach, or conversely waiting for confirmed harm before notifying.
Candidates either over-notify out of caution or under-notify because they equate 'breach' with 'confirmed misuse.' The regulatory test is risk to individuals, not proof of harm, and availability/alteration incidents count alongside disclosure.
What to do instead
Apply a fixed three-step test in order: (1) is it a personal data breach (confidentiality, integrity, or availability)? (2) does it pose a risk to rights and freedoms? (3) does it meet the high-risk threshold for notifying individuals? Answer each step explicitly before choosing a notification action.
Assuming any transfer of data outside the organization's country is prohibited, or that a single mechanism (such as standard contractual clauses alone) resolves all transfer compliance questions.
Candidates memorize mechanism names without understanding that transfers require a lawful basis plus a transfer tool plus, in many regimes, an assessment of the destination's legal environment and supplementary measures.
What to do instead
Use a layered checklist for transfer questions: is there a transfer at all (including remote access)? Is there an adequacy finding? If not, which safeguard applies, and what supplementary measures and transfer impact assessment are needed? Answer each layer.
Choosing 'obtain consent' as the fix for every weak-notice or weak-transparency scenario, rather than distinguishing notice obligations from consent validity requirements.
Notice and consent are taught together, so candidates merge them. They then miss that consent must be freely given, specific, informed, unambiguous, and withdrawable, and that bundling or pre-ticked boxes invalidate it regardless of how good the notice is.
What to do instead
Separate the two questions: does the regime require transparency here (notice), and separately, is consent a valid basis (choice)? Test consent against the validity elements explicitly and reject answers that rely on silence, inactivity, or bundled terms.
Describing accountability as 'having a privacy policy' rather than as demonstrable operational controls such as records of processing, training, vendor management, and audit.
Policy documents are visible and easy to cite, while program mechanics are abstract. Candidates therefore pick the policy option in questions that ask how accountability is demonstrated.
What to do instead
Memorize the accountability evidence set (records of processing, DPO or privacy lead, training records, DPIA register, vendor contracts, incident log, monitoring and audit results) and, in scenario questions, select the control that produces evidence rather than the document that states intent.
Ignoring the territorial and material scope question and jumping straight to obligations, so answers are given for organizations or data the law does not actually cover.
Candidates assume privacy law applies universally, missing scope tests such as establishment, targeting of individuals, thresholds, and exemptions (e.g., household, law enforcement, or employment-context carve-outs).
What to do instead
Make scope the first analytical step for every scenario: identify the data subjects, the organization's nexus to the jurisdiction, the type of data, and any exemption. Only after scope is confirmed should you evaluate obligations.