TTX-07 · Scenario card
Data Breach Notification Tabletop: Racing Regulatory Clocks
A breach notification tabletop exercise: confirmed exfiltration of customer data with GDPR, NIS2, SEC and HIPAA deadlines running in parallel. 9 injects.
A data breach becomes a legal and regulatory event the moment personal data is involved. Security teams focus on scope and containment; lawyers, privacy officers and communications teams face deadlines that start running long before the investigation is complete. In many organisations, those clocks run in parallel under different laws, and nobody owns the overall timeline.
This scenario tests exactly that. A web application vulnerability leads to confirmed exfiltration of customer personal data, affecting customers in several jurisdictions. It is designed for legal, privacy, security leadership, communications and executives.
Note: This scenario is for training. Summaries of legal requirements are simplified and are not legal advice. Confirm obligations with qualified counsel for your jurisdiction and sector.
Scenario at a glance
| Threat | Exploitation of a public-facing application leading to exfiltration of customer personal data |
| Difficulty | Advanced |
| Duration | 3 hours including a 30-minute hotwash |
| Audience | Legal, privacy/DPO, executive team, communications, security leadership |
| Recommended participants | General counsel, DPO/privacy lead, CISO, IR lead, communications, customer service lead, CEO or COO, investor relations or company secretary (if listed), outside counsel (optional) |
| Prerequisites | Breach response plan, notification matrix by jurisdiction, data inventory for the affected system, crisis communication plan |
| MITRE ATT&CK techniques | T1190 Exploit Public-Facing Application, T1041 Exfiltration Over C2 Channel |
Exercise objectives
- Determine when the organisation "became aware" of a personal-data breach and document the reasoning, since several deadlines depend on it.
- Build a single notification timeline covering all applicable regimes and assign an owner for each clock.
- Assess risk to individuals and decide whether, when and how to notify them.
- Test the materiality determination process for disclosure obligations, if the company is publicly listed.
- Coordinate consistent messaging across regulators, customers, employees, media and investors.
- Confirm how legal privilege is handled for investigation reports, where applicable.
Starting situation
Read this aloud to players:
Your organisation is a subscription services company with customers in the EU, the United Kingdom and the United States. A customer portal lets customers manage their accounts, payment methods and support tickets. The company is listed on a US stock exchange. Its EU subsidiary provides services considered important under national NIS2 implementation.
It is Monday, 08:30. Over the weekend, a security researcher emailed the security mailbox about a vulnerability in the customer portal. The email was read this morning.
Injects timeline
| # | Time | Inject | Delivered to | What players should address |
|---|---|---|---|---|
| 1 | T+00:00 | Researcher report: a vulnerability allows retrieving other customers' account data via the portal API | Security lead | Triage, validation, who is informed |
| 2 | T+04:00 | Engineers confirm the vulnerability and find signs of large-scale automated requests over the past ten days | IR lead → CISO | Incident declaration, "awareness" |
| 3 | T+08:00 | Log analysis indicates records for roughly 180,000 customers were retrieved: names, emails, addresses, partial payment details | IR lead → legal / DPO | Data categories, jurisdictions, notification clocks |
| 4 | T+20:00 | A dataset matching your customer records is offered for sale on a criminal forum | Threat intel → IR lead | Confirmation, risk to individuals |
| 5 | T+30:00 | Outside counsel asks how the IR firm was engaged and whether investigation reports are privileged | Legal | Privilege, report handling |
| 6 | T+40:00 | Finance and the company secretary ask whether the incident is material for securities-disclosure purposes | CEO / CFO / GC | Materiality process, disclosure |
| 7 | T+60:00 | The lead supervisory authority acknowledges your notification and asks follow-up questions | DPO | Regulator engagement, phased information |
| 8 | T+72:00 | A consumer journalist publishes a story citing the forum post; customer calls surge | Comms / customer service | Public statement, call-centre scripts |
| 9 | T+120:00 | The notification letter to customers is ready; marketing wants to add a retention offer | DPO / comms / legal | Content of notices, tone, remediation offers |
Module 1 — From report to awareness (T+00:00 to T+08:00)
Inject 1. A security researcher reports that changing an account identifier in a portal API request returns another customer's profile. They include a harmless proof using two test accounts they created, and they ask about your disclosure policy.
Inject 2. Engineers reproduce the flaw and, reviewing API logs, find a pattern of automated sequential requests from a small set of IP addresses over the last ten days, far beyond the researcher's two requests.
Inject 3. Log analysis estimates that records for roughly 180,000 customers were retrieved, including names, email and postal addresses, phone numbers, and the last four digits and expiry dates of payment cards. Customers are in the EU, UK and US.
Discussion questions:
- When did the organisation become "aware" of a personal-data breach: at the researcher's email, at confirmation of abuse, or at scoping? Who decides, and is the reasoning recorded?
- Which regimes might apply? Build the timeline on a whiteboard now. Who owns each clock?
- Who fixes the vulnerability, and how quickly? Does the fix affect evidence?
- How do you respond to the researcher?
Module 2 — Clocks, privilege and materiality (T+20:00 to T+40:00)
Inject 4. Threat intelligence finds a forum post offering a dataset matching your customer data format, with a sample of 20 records. Several match real customers.
Inject 5. Outside counsel asks how the incident-response firm was engaged and who has received its preliminary findings. They advise on how to structure the investigation and reports.
Inject 6. The CFO and company secretary ask whether the incident must be assessed for materiality under securities rules and who is responsible for that determination.
Discussion questions:
- What does the forum sample change about risk to individuals and about notification decisions?
- Does your engagement structure support privilege where it exists in your jurisdictions? Who can see which reports?
- Who conducts the materiality assessment, and what information do they need? How do you document it?
- Can you notify the supervisory authority before the investigation is finished? What do you include?
Module 3 — Notification and public response (T+60:00 to T+120:00)
Inject 7. The lead supervisory authority acknowledges your notification and asks for the number of affected individuals by country, the measures taken, and when you will inform the individuals.
Inject 8. A consumer journalist publishes an article citing the forum post. Customer contact volume rises sharply; agents have no script.
Inject 9. The draft notification letter is ready. Marketing proposes adding a discount offer to reduce churn; legal is concerned about tone.
Discussion questions:
- Are your answers to the regulator consistent with your public statements and customer notices?
- What do customer-service agents say? Who approves the script? Do you offer a dedicated contact line?
- What must a notice to individuals contain in each jurisdiction, and in which languages?
- Is offering support (such as identity-protection services or clear guidance about phishing risk) appropriate? How do you avoid a notice that reads like marketing?
A simplified notification matrix
Use this as a starting point for the exercise whiteboard, not as legal advice.
| Regime | Who / when it applies | Key deadline (simplified) |
|---|---|---|
| GDPR Art. 33 | Controllers of personal data of individuals in the EU (UK GDPR is similar) | Supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless unlikely to result in a risk |
| GDPR Art. 34 | Same, when the breach is likely to result in a high risk to individuals | Data subjects without undue delay |
| NIS2 Art. 23 | Essential and important entities under national NIS2 laws, for significant incidents | Early warning within 24 h; incident notification within 72 h; final report within one month |
| SEC Form 8-K Item 1.05 | US-listed companies, for material cybersecurity incidents | Within four business days after determining the incident is material |
| HIPAA Breach Notification Rule | US covered entities and business associates, for unsecured protected health information | Individuals without unreasonable delay and no later than 60 calendar days after discovery |
| US state breach laws | Vary by state; based on residence of affected individuals | Vary; many require notice "without unreasonable delay" and some set specific deadlines |
| Contracts | Customers, partners, card brands, insurers | As defined in each contract or policy |
HIPAA does not apply in this scenario (no health data), which is itself a useful discussion point: part of the exercise is confirming which regimes do not apply and documenting why.
Discussion questions
- Ownership: Who owns the consolidated notification timeline? Is it the DPO, general counsel or the incident commander?
- Awareness: Is your definition of "awareness" documented? Would the regulator agree with it?
- Consistency: How do you keep statements to regulators, customers, investors and media consistent?
- Data inventory: Did you know what data the portal held and where customers live? How long did it take to find out?
- Vulnerability disclosure: Is there a process for handling reports from security researchers?
Curveballs / optional injects
- A second supervisory authority contacts you directly after receiving customer complaints.
- The researcher threatens to publish details if you do not respond within 48 hours.
- The scope estimate doubles after further log analysis, after notifications have been sent.
Facilitator notes
Expected decisions. A strong team records the awareness decision and its reasoning, builds a single consolidated timeline with named owners, notifies authorities within the deadlines even with incomplete information (using phased notification where permitted), makes a documented risk assessment for individual notification, runs a structured materiality assessment and keeps all external messages consistent.
Common pitfalls.
- Waiting for the forensic report before starting any notification clock.
- Each function tracking "its" regulation, with no consolidated view.
- Customer notices drafted by marketing without legal review, or by legal in language customers cannot understand.
- Forgetting employees, who will be asked questions by friends and customers.
- Treating the researcher as an adversary instead of a source.
Adapting the audience. For a board-level session, focus on injects 3, 6 and 8 and the consolidated timeline. For a privacy team, expand Module 3 with drafting the notice and the regulator's follow-up questions in detail.
Evaluating the exercise
| Capability | What good looks like | Red flags |
|---|---|---|
| Awareness determination | Recorded decision with rationale and timestamp | No one can say when the clock started |
| Consolidated timeline | All applicable regimes mapped with owners and deadlines | Parallel, uncoordinated tracking |
| Regulator notification | Filed on time; phased updates planned | Delayed until investigation "complete" |
| Individual notification | Documented risk assessment; clear, plain-language notice | Notice delayed or confusing |
| Materiality process | Defined owners, inputs and documentation | Ad hoc discussion, undocumented |
| Communications consistency | One fact base for all audiences | Contradictions between regulator and public statements |
Related
Frequently asked questions
When does the GDPR 72-hour notification clock start?
Article 33 GDPR requires notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after the controller becomes aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Guidance from European regulators treats awareness as having a reasonable degree of certainty that a security incident has compromised personal data. If full information is not available, notification can be provided in phases.
Do we notify affected individuals at the same time as the regulator?
Not necessarily. Under GDPR Article 34, individuals must be informed without undue delay when the breach is likely to result in a high risk to their rights and freedoms, subject to exceptions. Other laws have their own rules and timelines. The exercise should test who assesses risk to individuals and how that decision is documented.
Is this scenario legal advice?
No. The deadlines summarized in this scenario are simplified for training purposes. Notification obligations depend on your jurisdiction, sector, contracts and the specific facts. Confirm your obligations with qualified legal counsel and keep your own jurisdiction-specific notification matrix up to date.