DAPLE (C1) common mistakes
DAPLE (C1) · Understand the traps and how to avoid them.
Treating the GDPR's 'without undue delay' breach-notification clock as a fixed 72 hours for every notification, and stating 72 hours for notices to data subjects.
Candidates memorise the 72-hour headline figure and collapse the two separate obligations into one, forgetting that the 72 hours applies specifically to notifying the supervisory authority and that data-subject notification follows a different, non-numeric standard.
What to do instead
Build a one-page decision table before exam day: controller-to-supervisory-authority notification is within 72 hours of becoming aware unless unlikely to result in a risk; controller-to-data-subject notification is without undue delay when there is a high risk; processor-to-controller is without undue delay. Practise phrasing each obligation separately so the 72-hour figure is never attached to the wrong recipient.
Answering cross-border transfer questions by choosing 'standard contractual clauses' for every scenario, including cases involving a public authority recipient or an intragroup transfer where an adequacy decision already covers the destination.
SCCs are the most familiar transfer tool, so candidates reach for them reflexively without first checking whether a transfer is occurring at all, whether an adequacy decision removes the need for additional safeguards, or whether the recipient type triggers a different instrument.
What to do instead
Apply a fixed three-step sequence to every transfer question: (1) is there a transfer to a third country or international organisation; (2) is there an adequacy decision covering that destination and that data type; (3) only then select an Article 46 tool, checking recipient type and whether the data is sensitive. Drill scenarios where the correct answer is 'no additional safeguard needed because adequacy applies'.
Confusing the roles of controller and processor when analysing a multi-party scenario, and assigning obligations such as responding to data-subject access requests or determining the lawful basis to the processor.
Candidates focus on who physically holds the data rather than who determines the purposes and means, and vendors that store data are intuitively assumed to carry the main compliance burden.
What to do instead
For each party in a scenario, ask two questions explicitly: who decides why the processing happens, and who decides how. The party answering 'why' is the controller and carries lawful-basis, notice, and rights-handling duties; the party answering only 'how' is the processor and carries instruction-following, security, and assistance duties. Write the role next to each party's name before reading the answer options.
Selecting encryption as the answer to every 'which control best mitigates this risk' question, including risks that encryption does not address, such as unauthorised access by a privileged insider who already holds the keys.
Encryption is the most salient technical control in the syllabus, and candidates treat it as a universal safeguard without mapping the control to the specific threat model in the stem.
What to do instead
Before choosing a control, name the threat actor and the attack path in one sentence. If the actor already has legitimate key access, encryption at rest does not mitigate the risk; look instead at access control, segregation of duties, key custody separation, or logging and monitoring. Keep a short control-to-threat mapping table and test each candidate control against the named actor.
Treating pseudonymisation and anonymisation as interchangeable, and concluding that pseudonymised data falls outside the scope of data protection law.
Both techniques reduce identifiability, and the surface similarity leads candidates to assume both remove data from scope, when only anonymisation does, and only if re-identification is genuinely impossible considering all means reasonably likely to be used.
What to do instead
Memorise the distinction as a single test: can the data be re-linked to an individual using additional information that is kept separately? If yes, it is pseudonymised and remains personal data, with the separate key itself subject to safeguards. If re-identification is not reasonably likely by anyone, it is anonymised and out of scope. Apply the test to the facts in the stem rather than to the label used.
Designing or evaluating a privacy-by-design scenario by listing privacy notice and consent as the primary controls, rather than addressing data minimisation, purpose limitation, and default settings at the design stage.
Consent and notice are the most visible privacy touchpoints, so candidates default to transparency controls even when the question asks about embedding protections into the design of a system or process.
What to do instead
When a question mentions design, architecture, or defaults, answer with the seven foundational principles: proactive not reactive, privacy as the default, embedded into design, full functionality, end-to-end security, visibility and transparency, and respect for user privacy. Choose options that reduce data collection or tighten defaults over options that merely disclose processing after the fact.
Classifying data by its format or system of origin rather than by sensitivity and harm, and omitting derived or inferred data from the inventory.
Candidates map what they can see in a data flow diagram, such as databases and applications, and overlook that classification should follow the potential harm from disclosure, plus data generated by inference, aggregation, or profiling.
What to do instead
Classify each data element by asking what harm follows from unauthorised disclosure, alteration, or loss, then assign the tier. Explicitly list inferred and derived attributes, such as risk scores or behavioural segments, as separate inventory items, because they often carry higher sensitivity than their source fields. Cross-check the inventory against the processing purposes recorded in the mapping exercise.
Analysing vendor risk by reviewing only the contract terms, and concluding that contractual clauses alone adequately mitigate the risk of a poorly secured supplier.
Contracts are concrete and easy to evaluate, so candidates treat the presence of a data processing agreement as proof of adequate control, skipping the assurance activities that verify the supplier's actual practices.
What to do instead
Separate contractual controls from assurance controls and require both. Contractual items include processing terms, audit rights, breach-notification timelines, and sub-processor approval. Assurance items include security questionnaires, independent certifications or audit reports, penetration-test evidence, and ongoing monitoring. On any vendor question, check whether the answer option describes verification of practice rather than only a promise.
Responding to incident scenarios by jumping straight to containment and notification, without first establishing scope, preserving evidence, and determining whether a personal data breach has actually occurred.
Notification deadlines create pressure, and candidates prioritise the visible deadline over the investigative steps that determine whether notification is even required and what must be reported.
What to do instead
Use a fixed incident sequence: detect and validate, contain, assess scope and data involved, preserve forensic evidence with a documented chain of custody, then decide on notification based on risk. Note that containment actions such as deleting malware or rebuilding systems can destroy evidence, so capture volatile data first. State in your answer where in the sequence the scenario sits before selecting an action.
Treating authentication factors as interchangeable and recommending multi-factor authentication as a complete answer, without checking whether the factors are independent or whether the scenario requires phishing-resistant credentials.
MFA is a familiar and generally correct control, so candidates stop at naming it rather than evaluating factor independence and resistance to interception in high-risk contexts such as administrator or remote access.
What to do instead
When MFA appears in an answer option, verify that the factors come from different categories (knowledge, possession, inherence) and that they are not both defeatable by the same attack, such as two knowledge-based or SMS-delivered factors against phishing. For privileged or remote access, prefer phishing-resistant authenticators such as hardware security keys or passkeys, and pair authentication with least-privilege authorisation and session controls.