How to Run a Breach-Notification Assessment
When data is exposed, the pressure is to act fast — but notification is a sequence of deliberate, documented decisions about whether a reportable breach occurred, who must be told, and by when. This guide structures that assessment as a planning aid you take into your legal review. It is not legal advice, and the conclusions here are determinations for qualified counsel.
In plain words
Running a breach-notification assessment means working out whether an incident is a reportable breach and, if so, who must be notified and by when — and PlayCISO has a free, browser-based breach-notification tool to structure the assessment. Confirm the facts, determine whether the threshold is met, inventory the data types, map the jurisdictions, track every regulator clock, and document the whole thing.
This is a planning aid, not legal advice: whether a breach is notifiable and what the deadlines are depend on your facts and laws, so confirm every conclusion with qualified legal counsel.
Step by step
- 1
Confirm the facts and contain first
Before you can assess notification, you need a clear, documented picture of what happened. Establish what systems and data were involved, when the exposure began and ended, whether it is contained, and how you know. Capture and preserve the evidence (logs, timelines, scope of access) early, because retention windows are short and the assessment, and any later regulator or legal review, all rest on these facts. Contain the incident in parallel — notification planning does not pause response.
- 2
Determine whether a reportable breach occurred
Not every security incident is a notifiable breach. Work through whether personal or regulated data was actually accessed, acquired or lost (versus merely at risk), and whether it meets the threshold for harm or risk that the applicable rules use. Many regimes hinge on a risk-of-harm assessment, and some provide safe harbours (for example, where the data was strongly encrypted and the keys were not exposed). This is a legal determination — use this step to gather the facts, and confirm the conclusion with counsel.
- 3
Inventory the data types involved
The category of data drives almost everything downstream — which laws apply, which thresholds, and which notification obligations. Separate out identifiers, financial data, health data, government ID numbers, authentication secrets and any special-category/sensitive data, and quantify how many records and individuals are affected. Sector-specific data (health, payment card, children's data) often triggers additional, stricter rules on top of general privacy law, so flag it explicitly.
- 4
Map the jurisdictions in scope
Obligations follow the affected individuals and the regulated entity, not just where your servers sit, so a single breach can engage several overlapping regimes at once (for example, multiple national or state laws, plus a sector regulator and contractual duties to partners). List every jurisdiction where affected individuals reside and every regime your organisation is subject to, because each can set its own threshold, timeline and recipient. Treat this map as the backbone of the whole assessment.
- 5
Track every clock and recipient
Notification regimes impose deadlines that often start from the moment of awareness, and they differ widely — the EU GDPR, for example, requires notifying the supervisory authority without undue delay and generally within 72 hours of becoming aware, with affected individuals told when the risk to them is high. Others set their own windows and triggers. Build a timeline per jurisdiction listing who must be told (regulators, affected individuals, sometimes partners or the public), by when, and with what information, so no clock is missed. Verify each specific deadline with counsel.
- 6
Draft notifications and remediation, then document the whole assessment
Prepare the content each recipient needs — what happened, what data was involved, what the organisation is doing, and what individuals can do to protect themselves — with legal review before anything goes out, since inaccurate or premature notice carries its own risk. Pair it with a remediation plan that addresses the root cause, not just the symptom. Finally, document the assessment itself: the facts, the reasoning, the decisions and who made them. Regulators frequently expect to see that a defensible process was followed, and that record is also your input to lessons learned.
Walk the data-type, jurisdiction and timeline questions in a free browser tool that organises the assessment — a planning aid to take into your legal review, not a substitute for it.
Related
When payment-card data is in scope, PCI DSS brings its own obligations on top of privacy law.
IR Playbook LabBuild the incident-response playbook that feeds a breach assessment with clean facts and a timeline.
Security LabsHands-on browser labs across incident response, compliance and security operations.
All PlayCISO toolsThe full free toolkit for security, compliance and leadership practice.
Frequently asked questions
Is this guide legal advice?
No. This is a planning aid to help you organise the facts and the questions a breach-notification assessment involves. Whether a breach is reportable, which laws apply and what the exact deadlines are, are legal determinations that depend on your specific facts and jurisdictions. Work with qualified legal counsel and your privacy officer to reach and confirm those conclusions.
Does every security incident have to be reported?
No. Many incidents do not meet the threshold for a notifiable breach — for example where no personal or regulated data was actually accessed or acquired, or where an applicable safe harbour applies, such as strongly encrypted data whose keys were not exposed. Several regimes turn on a risk-of-harm assessment. The point of the assessment is to make, and document, that determination deliberately rather than by default, with legal input.
What is the GDPR 72-hour rule?
Under the EU GDPR, a controller that experiences a personal-data breach must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Affected individuals must also be informed when the breach is likely to result in a high risk to them. Other jurisdictions set their own, different deadlines, so confirm the specific rule that applies with counsel.
Why do data types matter so much in the assessment?
Because the category of data drives which laws apply and how strict the obligations are. Health data, payment-card data, government identifiers, authentication secrets and children's data frequently trigger sector-specific or heightened rules on top of general privacy law. Inventorying exactly what was involved, and how many individuals, is what lets you map the right regimes and thresholds instead of guessing.
We only operate in one country — can we ignore other jurisdictions?
Not necessarily. Notification obligations often follow where the affected individuals reside and which regimes your organisation is subject to, not just where your infrastructure is located, so a breach can engage laws beyond your home jurisdiction. Map every jurisdiction where affected people live and every regime you fall under, then confirm scope with counsel rather than assuming a single-country footprint limits your duties.
Why document the assessment if we decide not to notify?
Because a defensible decision not to notify still needs a record of how you reached it. Regulators frequently expect to see that you assessed the facts, applied the relevant threshold and documented the reasoning and who approved it. That record protects the organisation if the decision is later questioned, and it feeds your lessons-learned and remediation work regardless of the notification outcome.