Data Breach Tabletop Exercise: GDPR 72 Hour Drill

Most personal data breach notifications go wrong not in the technical response but in the room where someone has to decide, against a 72 hour clock, whether this is a breach, who must be told and what to say. This template is a ready privacy-led tabletop exercise built around that decision: when the organisation became aware, whether the risk to individuals is likely or high, which supervisory authority to notify, whether to tell data subjects, and how to record the reasoning. It is written for Data Protection Officers, privacy and legal teams, CISOs and incident managers who want to rehearse the GDPR and UK GDPR Article 33 and 34 decisions rather than the forensics. For how to plan and run tabletops in general, see the Tabletop Exercise Guide; for the full set of notification clocks and content, use the Data Breach Notification Checklist as the reference document in the room.

How to use this template

Replace text in square brackets, such as [Organisation], [DPO] and [lead supervisory authority], with your own terms. Bracketed values are suggestions, not legal requirements.
The exercise runs in [3 hours] of real time and covers 96 hours of scenario time in five phases. Each phase has injects, the decisions players must make, and what a facilitator should listen for.
Choose one variant in section 5.2 to fit your organisation (EU controller, UK controller, controller outside the EU with a representative, or processor). Do not run all of them in one session.
Bring your real documents: incident response plan, breach register, records of processing, data processing agreements with the supplier in the scenario, and contact details for your supervisory authority. Testing whether people can find these is part of the exercise.
This template supports a discussion exercise. It summarises GDPR and UK GDPR notification duties for practice and is not legal advice; have counsel confirm the decisions in your own plan.

1. Purpose

This exercise tests whether [Organisation] can make and document lawful, timely notification decisions after a personal data breach. Specifically it tests that the team can: establish the moment of awareness; assess risk to individuals using a consistent method; notify the right supervisory authority within 72 hours where required, in phases if facts are incomplete; decide on communication to data subjects; coordinate with a processor; and record every decision, including decisions not to notify, as Article 33(5) requires.

2. Scope

In scope: breach identification, awareness, risk assessment, supervisory authority notification, data subject communication, processor and controller coordination, the breach register, and internal escalation to executives.
Out of scope: technical containment and forensics detail (run the technical track from the Tabletop Exercise Scenario Pack separately), media handling beyond the decision to make a public statement, and litigation strategy.
Jurisdictions: EU GDPR and UK GDPR by default. Teams with US exposure should add the state law clocks from the notification checklist as an extra inject in phase 4.

3. Roles and exercise rules

Role	Who	Exercise responsibility
Facilitator	[Privacy or IR lead not in the decision chain]	Delivers injects, keeps time, asks probing questions, does not answer for players.
Timekeeper and scribe	[Named person]	Records scenario time of each decision, who made it and the stated reason; this record becomes the mock breach register entry.
Decision owner	[DPO or Head of Privacy]	Recommends whether to notify the authority and data subjects.
Accountable executive	[General Counsel or COO]	Approves notifications and public statements.
Incident manager	[IR lead]	Brings technical facts as injects reveal them; owns containment status.
Supplier manager	[Procurement or vendor owner]	Represents the processor relationship and the contract terms.
Communications	[Head of Communications]	Drafts data subject and public messages.
Observer	[Internal audit or second line]	Scores the evaluation criteria in section 7.

Rules: it is a no-fault exercise; players work from what they know at each phase, not from what they suspect the next inject holds; the facilitator may "stop the clock" to discuss a decision, but scenario time keeps its recorded value.

4. Scenario summary

[Organisation] uses a SaaS customer support platform run by [Supplier], a processor under Article 28. The platform holds support tickets for [about 180,000] customers in [Ireland, France, Germany and the UK], including names, email addresses, phone numbers, order history and free-text messages. Some tickets contain attachments such as identity document scans uploaded for account recovery, and a small number contain health information volunteered by customers. A support integration uses a long-lived API token. That token is exposed and used to export ticket data. Facts emerge slowly and in the wrong order, as they do in real incidents. Containment of exposed data stores is covered in the Cloud Storage Exposure Playbook; this exercise stays on the privacy decisions.

5. Exercise script

5.1 Phases, injects and decisions

Phase (scenario time)	Inject	Decisions required	Facilitator listens for
1. Alert (Friday 16:30, T+0)	The SOC sees an unusual volume of API calls from the support integration to [Supplier] over the past six hours. No confirmation of data access yet.	Is this a security incident? Who is told now? Is the DPO informed? Start a short investigation?	DPO informed within the plan's target; recognition that the clock has probably not started, but a short investigation must start at once.
2. Confirmation (Saturday 10:00, T+17.5h)	Logs show the token exported [42,000] tickets to an unknown IP address. [Supplier] has not replied to the out-of-hours contact.	Are we now aware? Record the awareness time and reason. Revoke the token? Escalate to [Supplier] through the contract escalation path.	A clear awareness time recorded with its basis; no waiting for Monday; token revocation and rotation of other integration credentials.
3. Scoping (Saturday 18:00, T+25.5h)	Sampling shows tickets include identity document scans and some health information. Affected customers are in four countries. Total affected is unknown.	Risk assessment: likely risk, high risk or neither? Which authority is the lead? Draft the initial notification with known facts.	Use of a consistent risk method; special category and ID data raising severity; plan for phased notification.
4. Notification (Monday 09:00, T+64.5h)	[Supplier] confirms the exposure and says the count may rise to [180,000]. A journalist emails asking about "a data leak at your support desk".	Submit the authority notification now? Notify data subjects? What does the message say? Respond to the journalist?	Notification submitted before T+72h with a statement that more information will follow; data subject decision recorded with reasons.
5. Follow-up (Tuesday 15:00, T+94.5h)	Forensics finds an earlier export three weeks ago using the same token. The authority asks for an update and a timeline.	Update the notification in phases; does the earlier export change the awareness date or the risk? Is the delay since then explainable?	Honest update; recognition that late notification needs reasons; register updated.

5.2 Variants

EU controller with a main establishment: notify the lead supervisory authority under the one-stop-shop. Test whether the team knows which authority that is and has its online form bookmarked.
UK controller: UK GDPR Article 33 applies the same 72 hour standard. The ICO says to report as soon as possible and where feasible within 72 hours, and not to delay an initial report because information is incomplete. Since 30 September 2026, UK GDPR Article 33 has named the Information Commission (“the Commission”) as the body to notify. If EU residents are also affected, test whether the team also notifies EU authorities.
Controller outside the EU with an Article 27 representative: EDPB Guidelines 9/2022 state that having a representative does not trigger the one-stop-shop, so the breach must be notified to every supervisory authority where affected data subjects live. Test whether the team plans four notifications, not one.
[Organisation] as processor: swap roles. The team must notify each controller customer without undue delay; it does not decide on authority notification itself. Test the contract clauses and the customer notification list.

5.3 Key questions for the decision owner

At what moment did we have a reasonable degree of certainty that personal data was compromised, and what evidence shows it?
Which categories of data and individuals are involved, and roughly how many?
What are the likely consequences for individuals (identity fraud from ID scans, distress from health information, phishing from contact details)?
Is the risk unlikely, likely or high, and who agreed that rating?
Does any Article 34(3) condition apply, such as data rendered unintelligible by encryption, so that individual communication is not required?
What will we tell the authority now, and what will follow in later phases?
Are other clocks running in parallel, for example NIS2 incident reporting if [Organisation] is an essential or important entity, or sector rules? See the Breach Notification Laws by Country Guide.

6. Reference: the legal decision points being practised

Decision	Rule	What the exercise checks
Is it a personal data breach?	GDPR Article 4(12): a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data	Confidentiality breach recognised even before the count is known
When does the clock start?	Article 33(1): within 72 hours of becoming aware. EDPB Guidelines 9/2022: aware means a reasonable degree of certainty; a short investigation may come first but must start promptly	Awareness time recorded with evidence; weekend does not pause it
Notify the authority?	Article 33(1): required unless the breach is unlikely to result in a risk to rights and freedoms; reasons needed if later than 72 hours	Risk rating documented; late notice explained
What goes in it?	Article 33(3): nature of the breach, categories and approximate numbers of individuals and records, DPO contact, likely consequences, measures taken or proposed	Draft covers each element, marked as provisional where needed
Incomplete facts?	Article 33(4): information may be provided in phases without undue further delay	Initial notice not held back for a final count
Processor role	Article 33(2): processor notifies the controller without undue delay. EDPB: the controller is generally aware once informed by the processor	Contract escalation path used; controller does not wait passively
Tell data subjects?	Article 34(1): without undue delay where high risk is likely; Article 34(3) exemptions (encryption, later measures, disproportionate effort with public communication)	Decision and exemption reasoning recorded
Record it	Article 33(5): document all breaches, facts, effects and remedial action. EDPB recommends recording the reasoning, including for not notifying	Scribe's record usable as the register entry

7. Evaluation

Criterion	Met	Partly met	Not met
DPO informed within [1 hour] of the phase 1 alert	Yes, with time recorded	Informed late but same day	Not informed until phase 3 or later
Awareness time agreed and justified	Recorded with evidence in phase 2	Recorded without reasons	Not agreed
Risk assessment method used	Documented method applied, special category data weighed	Informal discussion only	No assessment
Authority notification before T+72h	Submitted with phased follow-up plan	Drafted but not approved in time	Not drafted
Right authority or authorities identified	Correct for the chosen variant	Identified after prompting	Incorrect
Data subject decision recorded	Decision, reasons and draft message ready	Decision without reasons	Deferred indefinitely
Processor coordination	Contract escalation path used; supplier timeline obtained	Ad hoc contact	No contact plan
Register entry complete	All Article 33(5) elements	Partial	None

8. After the exercise

Hold a hot wash immediately, then write the after action report within [10 working days] using the Tabletop Exercise After Action Report Template.
Assign an owner and due date to every gap, for example a missing out-of-hours supplier contact or an unclear awareness rule in the plan.
Update the incident response plan, the breach register template and supplier contracts where the exercise showed gaps.
Re-test the weakest decision within [6 months].

Implementation guidance

Preparing the exercise

Agree objectives with the DPO and General Counsel: pick two or three decisions to stress, such as awareness timing and the data subject decision.
Tailor the data: replace the support platform with a real processor that holds your most sensitive personal data, and use realistic record counts from your records of processing.
Pre-brief the facilitator: agree the "right" answers for the chosen variant with counsel in advance, so feedback in the room is consistent.
Prepare injects as cards or slides: include the scenario day and time on each, and a printed copy of the authority's notification form fields.
Run, record, report: the scribe's decision log is the main output; keep it as evidence of testing.

Choosing the format

Option	Best when	Trade-off
Privacy-only session (this template)	Notification decisions have never been rehearsed, or after a change of DPO	Technical facts are simplified
Combined with a technical tabletop	Mature IR team; you want to test the hand-off from SOC to privacy	Longer; privacy decisions can be crowded out
Executive short version ([60 minutes], phases 3 and 4 only)	Board or executive committee awareness	Little time to test documentation
Supplier joint exercise	Critical processors with large personal data volumes	Needs contract and NDA arrangements

Small organisations: run phases 2 to 4 in [90 minutes] with the owner, the person who handles data protection and the IT provider; the decisions are the same even where no DPO is mandatory. Large or multi-country organisations: run the controller-outside-the-EU or multi-authority variant at least once, as notifying several authorities in parallel is where timelines slip.

Where identity fits

The scenario turns on a long-lived integration token, a non-human identity that was never rotated and had broad export rights. Ask in the hot wash who owned it, whether it was in an inventory, and whether its scope matched its use. Fix the credential through your rotation process; see the Secrets Rotation Runbook Template and the NHI Governance Maturity Model.

Measures that show it is working

Scenario time from awareness to authority notification decision, compared across exercises.
Percentage of evaluation criteria met, tracked per exercise.
Number of after action items closed by their due date.
Time to reach the processor's security contact out of hours in the exercise.
In real incidents: share of notifiable breaches reported within 72 hours, and share of register entries that record reasons.

Common failure patterns

Waiting for certainty: teams hold the notification for the final count; Article 33(4) allows phased notification.
Weekend blind spot: the clock runs through Saturday and Sunday, but the out-of-hours path reaches only IT, not the DPO.
Waiting for the supplier: the controller treats the processor's silence as a reason to wait; it remains responsible for its own decision.
One authority by habit: controllers outside the EU assume their representative's authority covers all, contrary to EDPB guidance.
No record of "not notified": decisions not to notify are made verbally and never written into the register.

Framework mapping

Framework	Reference	Exercise sections
GDPR and UK GDPR	Articles 4(12), 28, 33, 34	5, 6
NIST SP 800-53 Rev. 5	IR-3 Incident Response Testing; IR-6 Incident Reporting; IR-8 Incident Response Plan	Whole exercise
NIST CSF 2.0	RS.CO-02 (stakeholders notified of incidents); RS.CO-03 (information shared with designated stakeholders); ID.IM-02 (improvements from tests and exercises)	5, 8
ISO/IEC 27001:2022	Annex A 5.24 to 5.28 (incident management planning to collection of evidence); 5.34 (privacy and protection of PII)	5, 8

Sources

This guide summarises GDPR and UK GDPR breach notification duties for exercise purposes and is not legal advice. Related NHI Mgmt Group resources: Tabletop Exercise Guide · Tabletop Exercise Scenario Pack · Privacy Programme Guide for Security Teams · Customer Breach Notification Letter Template · GDPR Compliance Guide for Security Teams

Data Breach Tabletop Exercise: Practise the 72 Hour GDPR Notification Decision