CPPA common mistakes
CPPA · Understand the traps and how to avoid them.
Treating 'personal data' as synonymous with names, emails, and government IDs, so scenarios involving device identifiers, IP addresses, pseudonymous records, or inferred profiles get classified as non-personal and exempted from the program.
Candidates memorize example lists of identifiers instead of the underlying test (identifiability of a natural person, directly or indirectly, alone or in combination). Scenario questions deliberately use pseudonymous or indirectly identifiable data to test the definition rather than recall.
What to do instead
Apply a two-step test to every data element: can it single out an individual, and can it be linked back to one using means reasonably likely to be used? Practice classifying cookies, hashed IDs, and aggregate datasets as identifiable, pseudonymous, or anonymous, and note that pseudonymized data remains personal data while anonymized data does not.
Answering legal-basis questions by defaulting to consent for every processing activity, including HR payroll, fraud prevention, or security monitoring, rather than evaluating contract, legal obligation, or legitimate interests first.
Consent is the most familiar and most discussed basis, and candidates conflate 'lawful' with 'permissioned'. Many real programs lead with consent banners, reinforcing the habit.
What to do instead
Before selecting a basis, ask what the processing is necessary for and whether a non-consent basis fits better. Memorize the practical consequences: consent must be freely given and withdrawable (problematic in employment), contract requires necessity, legal obligation requires a specific legal duty, and legitimate interests requires a documented balancing test.
Describing data subject access requests as answered by handing over a raw database export, and missing the requirement to explain purposes, categories, recipients, retention, and rights, plus the one-month timeline and extension conditions.
Candidates focus on the 'give them their data' headline and overlook the accompanying transparency content and procedural deadlines that the exam tests in scenario form.
What to do instead
Build a mental checklist for every access request: confirmation of processing, copy of data, purposes, categories, recipients, retention period or criteria, rights, source of data, and automated decision-making logic, delivered within one month (extendable by two for complex cases with notice). Rehearse the exceptions, such as trade secrets and third-party rights.
Confusing controller and processor roles in a vendor scenario, then assigning the wrong obligations, such as telling the processor it must obtain consent or handle access requests directly.
Candidates read the vendor's technical role (hosting, analytics) instead of the decisional role (who determines purposes and means). Sub-processor chains and joint controllership add ambiguity that the exam exploits.
What to do instead
Ask who decides why and how the processing happens. The controller answers to regulators and data subjects; the processor acts on documented instructions, assists with requests, notifies breaches, and flows obligations down to sub-processors. Practice mapping a three-party chain and identifying joint controllers where purposes are jointly determined.
Treating a security incident as automatically a notifiable personal data breach, or conversely waiting for confirmed harm before notifying, instead of applying the risk-based threshold and the 72-hour regulator clock.
Candidates conflate incident response with breach notification, and conflate the regulator notification test (risk to rights and freedoms) with the data subject notification test (high risk).
What to do instead
Separate the three decisions: is it a personal data breach, is it notifiable to the regulator (risk threshold, without undue delay and where feasible within 72 hours), and is it notifiable to individuals (high risk). Practice writing a short decision record for a lost encrypted laptop, a ransomware event, and a misdirected email.
Assuming an adequacy decision is the only transfer mechanism, or assuming standard contractual clauses alone complete a transfer without a transfer impact assessment and supplementary measures.
Candidates learn one mechanism well and stop there, and they treat clauses as a paperwork step rather than a legal instrument whose effectiveness depends on the destination's legal environment.
What to do instead
Memorize the mechanism families: adequacy, appropriate safeguards (SCCs, BCRs, approved codes or certifications), and narrow derogations. For SCCs, remember the steps in order: map the transfer, select the module, conduct the transfer impact assessment, add supplementary measures if needed, and document the conclusion.
Answering accountability questions by citing policies and privacy notices as proof of compliance, without describing records of processing, DPIAs, training evidence, or monitoring.
Candidates equate documented intent with demonstrated accountability, and notices are the most visible artifact they have seen.
What to do instead
For any accountability question, list the operational evidence: a maintained record of processing activities, DPIA outcomes and sign-off, documented legitimate interest assessments, training completion data, vendor due diligence files, and audit or monitoring results. Frame answers as 'demonstrate and evidence', not 'state and publish'.
Applying one jurisdiction's rules globally, such as assuming GDPR-level consent standards, data subject rights, or breach deadlines apply identically in the US state laws or other regions.
Candidates study the most prominent framework first and anchor on it, and many state laws share vocabulary (sale, consent) while differing in thresholds, exemptions, and remedies.
What to do instead
Build a comparison grid across the frameworks you are tested on: scope thresholds, covered data and entity exemptions, consumer rights, opt-in versus opt-out consent, sensitive data rules, cure periods, and enforcement. For each scenario, first identify the jurisdiction and entity threshold, then apply that regime's specific rule.
Ignoring purpose limitation and retention in design questions, approving secondary uses and indefinite storage because the data was lawfully collected and adequately secured.
Candidates weight collection and security controls heavily and treat purpose and retention as administrative formalities, missing that compatibility assessment and storage limitation are substantive requirements.
What to do instead
For every new use, ask whether it is compatible with the original purpose or requires a new basis, and for every dataset, define a retention period or criteria and a deletion or anonymization trigger. Practice reviewing a marketing-reuse or analytics scenario and stating the compatibility reasoning explicitly.
Treating emerging technology risk as a general ethics discussion, giving no specific obligations for automated decision-making, profiling, AI training data, or cross-border model deployment.
Candidates lack concrete anchors for fast-moving topics and retreat to principles, while exam items ask for specific transparency, human review, impact assessment, and data minimization requirements.
What to do instead
Anchor each technology to concrete duties: notice and meaningful information about automated logic, human intervention and contest rights for significant decisions, DPIAs or algorithmic impact assessments before high-risk deployment, lawful basis and minimization for training data, and transfer analysis for model hosting. Memorize one worked example per technology.