learn-gdpr-with-phoebe / Practitioner session 7 of 8
Learn GDPR with Phoebe · Practitioner track · Session 7 of 8

Breach response against the clock

Everything else in this track is preparation; this is the day it is tested. A breach happens, and the 72-hour clock starts the moment you become aware. This session builds the response: contain, assess whether it is notifiable, notify the authority within 72 hours and individuals if the risk is high, then close the gap that let it happen. A plan you have never timed is a plan you do not have.

🔴 Practitioner track DPOs · security · ops No jargon Hardest
0-3 · Welcome 3-18 · Concepts 18-40 · Build-along 40-45 · Q&A
Part 0

The clock starts before you are ready

A breach never arrives at a convenient time, and the GDPR does not care. The 72-hour clock (Article 33) starts when you become aware a breach has occurred - not when you finish investigating, not on Monday morning. That single fact reshapes incident response: you cannot afford a plan where the first hours are lost to "who owns this?". This session makes the response concrete and, crucially, timed.

Read this first Educational, not legal advice. Verify against the Regulation text and have real incident-response advice in place before you need it.
Live - presented in session Self-study - full depth after class ★ Try it now Sources covered at the end
★ What you build today The notifiable test, the 72-hour authority clock and the high-risk individual notice, the contain-assess-notify-remediate arc, and Lumina's timed response to a real incident.
Part 1 · covers Articles 33 & 34

Assess, then notify 7 min live

Two thresholds decide who you tell. Any breach that risks people's rights goes to the authority within 72 hours. A breach that risks them badly also goes to the affected individuals.

Become awareclock starts Containstop the bleed Assessis it notifiable? Authority: 72hany risk Individualsif HIGH risk Remediateclose the gap 72 hours runs from "aware", and it does not pause for weekends. Pre-decide who assesses and who notifies.
🔍 Click to zoom - the breach-response arc and the two thresholds
LiveThe notifiable test + the two clocks3 min▶
  • To the authority (Art 33): notify without undue delay and, where feasible, within 72 hours of becoming aware - unless the breach is unlikely to result in a risk to people's rights. Late means you must explain the delay.
  • To individuals (Art 34): when the breach is likely to result in a high risk to them, tell them too, without undue delay. Exceptions include data that was strongly encrypted (a payoff for session b6's measures).
  • If you are a processor: a processor that detects a breach must notify the controller it works for, without undue delay - you are a link in someone else's 72 hours.
★ Try it now (any chat AI)Walk me through GDPR breach response: when the 72-hour clock starts, how to decide if a breach is notifiable, the difference between notifying the authority and notifying individuals, and what a processor must do. Then give me a one-page incident checklist.
Livevs the PDPA clock, for a dual-regime breach3 min▶

A breach at a Singapore company with EU customers triggers both regimes, and the clocks differ:

  • GDPR: one 72-hour clock from awareness, risk-based, no headcount threshold for the authority.
  • PDPA: assess (the PDPC expects the cycle within about 30 days), then notify the PDPC within 3 calendar days of determining it notifiable, gated by significant harm or 500+ individuals.
  • The binding constraint is the GDPR. Build your response to hit 72 hours and you comfortably meet the PDPA timeline on the same incident.
Real world

Lumina's exposed backup. Lumina discovers a misconfigured backup exposed 3,000 records - EU and Singapore. It becomes aware Friday 4pm. The GDPR clock is now running through the weekend. Because Lumina had a named incident owner with authority to notify, it contained the exposure, assessed the risk, and filed with the EU authority within 72 hours - and met the PDPA process on the same facts. The encryption from b6 meant individual notice was not required for the encrypted portion.

Part 2 · the response, run well

Contain, notify, learn 8 min live

A good breach response is not just fast notification; it is a loop that ends with the gap closed. What you notify, and what you fix, both matter.

Contain Assess Notify Remediate Feed back The response is not done at "notified". It ends when the gap that caused it is closed.
🔍 Click to zoom - the response loop
LiveWhat to include, and when to consult first3 min▶
  • The notification tells the authority: the nature of the breach, the categories and rough number of individuals and records affected, the likely consequences, and the measures taken or proposed. You can provide information in phases if you do not have it all in 72 hours.
  • The individual notice (when required) is in clear language: what happened, likely consequences, what you are doing, and what they can do (change a password, watch for fraud).
  • Consult the authority first for breaches likely to attract widespread attention - it is better to be seen managing it than reacting.
  • Close the loop: the incident should upgrade a control (the Protection Obligation gap from the leader track) so the same breach cannot recur.
Self-studyThe response plan is the deliverable, not the response2 min read▶

You cannot write a good breach response in the 72 hours you have to deliver one - the plan has to exist beforehand. The real work of this session is not "know the rules"; it is "have a plan, with named roles, that you have timed". A plan names who becomes the incident owner, who can authorise a regulator notification without waiting for a committee, how the security team escalates to them out of hours, and where the notification templates live. Then you rehearse it - a tabletop exercise where you start the clock on a Friday afternoon and see whether you would actually make 72 hours. Most teams discover their bottleneck is not the technical investigation but the approval step: nobody is sure they are allowed to notify. Fixing that - a single owner with pre-granted authority - is worth more than any amount of policy text. Build the plan, time it, and keep the templates ready.

Build-along · take it further

Run Lumina's breach clock ★ 10 min · pen and paper

Time a real incident against 72 hours.

The trigger. Lumina's on-call engineer spots the exposed backup at 4pm Friday. Write who they tell, and how fast the incident owner is reached.

Assess. Who decides whether it is notifiable, and against what test (risk to rights; EU individuals affected)? Estimate the hours.

Notify. Who drafts and who has authority to submit to the EU authority - over a weekend? Put the clock on it. Does it clear 72 hours?

Learn. Name the control that would have prevented it (backup access review) and who owns closing it.

★ Lumina after b7 Lumina has a timed, owned breach plan that clears 72 hours even on a weekend, and it closes the gap afterwards. Only one thing remains: making all of this a standing programme rather than seven separate efforts. Session b8 assembles it - and harmonises it with the PDPA.
Homework

Before session b8 ◐ 40 min total

Source material

Official sources covered

Taught from the GDPR text. This page covers ~80% of the working content on breach response.

✓GDPR Article 33 (notification to the authority)Part 1 · 72 hours from awareness + phased info + processor duty
✓GDPR Article 34 (notification to individuals)Part 1-2 · high-risk threshold + the encryption exception
◐PDPA breach contrastPart 1 · ~30-day assess, 3-day notify, 500 threshold
Check yourself

Three questions before you go 🎯 ◐ 90 seconds

1 · The 72-hour breach clock starts...

Article 33: notify within 72 hours of becoming aware. The clock runs through weekends and does not wait for the investigation to conclude - which is why a pre-agreed owner matters.

2 · You must notify affected individuals (not just the authority) when the breach...

Article 34: individuals are told when the risk to them is high. Strong encryption of the affected data can remove that duty - the payoff of good supplementary measures.

3 · The most common real-world bottleneck in hitting 72 hours is...

Teams usually find the technical work is manageable; the delay is organisational. A single incident owner with pre-granted authority to notify is the fix.

Practitioner session 7 cheat sheet · pin this

72 hours from "aware"Notify the authority within 72h of becoming aware (Art 33), unless unlikely to risk rights.
Two thresholdsAny risk → authority. High risk → also individuals (Art 34).
Encryption exceptionStrong encryption of affected data can remove the duty to notify individuals.
Processor dutyA processor tells the controller without undue delay - a link in their 72 hours.
Phased info OKYou can notify with what you have and follow up as the investigation develops.
The loopContain → assess → notify → remediate → feed back. Done at "gap closed", not "notified".
The real bottleneckApproval authority. A named owner who can notify, out of hours, is the fix.
vs PDPAPDPA: ~30-day assess, 3-day notify, 500 threshold. Hit GDPR's 72h and PDPA follows.