Incident Response and Breach Notification
This domain tests the clock, the threshold and the audience. You must distinguish an incident from a notifiable breach, calculate the 72-hour window from awareness, and know what each notification must contain.
Core rules
- Breach definition (GDPR Article 4(12)): a security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
- Controller to supervisory authority (Article 33): notify within 72 hours of becoming aware unless unlikely to result in a risk to rights and freedoms. Content: nature of the breach including categories and approximate numbers, DPO contact, likely consequences, and measures taken. Where full information is unavailable, notify in phases.
- Processor to controller (Article 33(2)): without undue delay; the processor's notification does not discharge the controller's duty.
- Individuals (Article 34): notify without undue delay where the breach is likely to result in high risk; exceptions apply where data was protected by effective encryption, or where individual notification would involve disproportionate effort (public communication instead).
- Documentation (Article 33(5)): record all breaches, including those not notified.
- CCPA: notify affected California residents in the most expedient time possible and without unreasonable delay, using the prescribed format; notify the Attorney General if more than 500 California residents are affected.
- Playbook phases: prepare, detect, triage and contain, assess risk, notify, remediate, lessons learned.
Worked example
An employee emails a spreadsheet of 300 patients to the wrong external address. The data includes names, diagnoses and appointment dates. This is unauthorised disclosure of special category data. Risk to individuals is likely high (sensitive health data, no encryption), so notify the supervisory authority within 72 hours of awareness and inform affected individuals without undue delay. Ask the recipient to delete and confirm; document the incident even though containment succeeded.
Traps that cost marks
- Starting the 72-hour clock only after the investigation is complete.
- Believing the processor's notification satisfies the controller's duty.
- Notifying individuals when risk is not high, or failing to notify when it is.
- Forgetting documentation for non-notifiable breaches.
- Missing sectoral overlays (NIS2, DORA, SEC, state breach laws) that add separate deadlines.
Third-Party, Cross-Border, and Emerging Technology Risk
This domain tests the outer edge of the program: how data moves to vendors and across borders, and how new technologies change the risk assessment. Expect scenario questions on processor contracts, transfer mechanisms post-Schrems II, and AI or profiling risk.
Core rules
- Vendor lifecycle: risk-tiering before onboarding, due diligence (security certifications, sub-processor lists, breach history), a written Article 28 contract (subject matter, duration, nature and purpose, instructions, confidentiality, security, sub-processor rules, assistance with DSRs and DPIAs, deletion or return, audit rights), ongoing monitoring, and exit planning.
- Cross-border transfers (GDPR Chapter V): adequacy decisions (Article 45); appropriate safeguards such as the 2021/914 Standard Contractual Clauses or Binding Corporate Rules (Article 46); derogations (Article 49) for occasional, non-repetitive transfers. Following Schrems II, SCCs require a transfer impact assessment covering local law, public authority access and supplementary measures. The EU-US Data Privacy Framework (2023) provides an adequacy route for certified US organisations.
- Other regimes: China PIPL requires CAC security assessment, certification or a standard contract; Brazil LGPD uses adequacy, clauses or BCRs; CCPA requires service provider contracts with specific restrictions on selling and sharing.
- Emerging technology: GDPR Article 22 on solely automated decisions with legal or similarly significant effects; profiling; AI training data; the EU AI Act's risk tiers (unacceptable, high-risk, limited-risk transparency, minimal) and general-purpose AI obligations; biometrics and IoT.
Worked example
A French retailer wants a US-based HR analytics vendor processing EU employee data. Confirm the vendor is a processor and sign SCCs plus an Article 28 contract; run a transfer impact assessment on US surveillance law and the vendor's ability to resist access requests; check whether the vendor is certified under the Data Privacy Framework, which would supply an adequacy route. If the assessment shows unresolved risk, add supplementary measures or reconsider the vendor.
Traps that cost marks
- Assuming SCCs alone satisfy Schrems II.
- Missing sub-processor authorisation and flow-down clauses.
- Treating a vendor's certification as covering every processing activity it performs.
- Allowing an AI vendor to train models on customer data without a lawful basis or contractual prohibition.
- Forgetting that controller-to-processor and processor-to-processor transfers both need a mechanism.