You Have 72 Hours: Breach Notification Readiness Before You Need It
Table of Contents
- The Clock Starts Before You Understand
- What Regulators Actually Ask
- Why Scope Determination Takes Too Long
- Evidence You Must Already Have
- Deciding Whether It Is Notifiable
- The Multi-Jurisdiction Problem
- Preparing Before the Incident
- Communication Under Uncertainty
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: Notification deadlines are measured from awareness of the incident, not from completion of the investigation. The determining factor in whether you can comply is whether logging and data inventory already existed — neither can be created after the fact.
The Clock Starts Before You Understand
A regulatory deadline of 72 hours sounds workable until you examine what it measures.
The clock starts when you become aware that a personal data breach may have occurred. Not when you confirm it. Not when you complete forensic analysis. Not when you determine which records were affected. Awareness of a likely breach starts it.
At that moment you typically know very little. An alert fired. A server behaved oddly. A researcher emailed. What you do not know is what was accessed, whose data it was, how many people, when it started, whether the attacker is still present, or whether data left the environment.
Determining those facts is the investigation. Investigations of any complexity take weeks. The notification deadline is measured in days.
This is the structural problem, and it is why notification readiness is an engineering matter rather than a legal one. Regulators accept phased notification — an initial report with what is known, supplemented as facts emerge — and the initial report must still contain substantive information. Producing it requires evidence that either already exists or does not.
What Regulators Actually Ask
Notification requirements vary by jurisdiction and consistently include a similar set of questions:
What happened, and when? The nature of the incident, when it began, when it was discovered, and whether it is contained.
What categories of data were involved? Not the specific records necessarily, but the types — contact details, financial information, health data, credentials, identifiers.
How many individuals are affected? Approximate is acceptable. “We do not know” is not, past the initial report.
What are the likely consequences? An assessment of harm to the affected individuals.
What have you done about it? Containment measures, remediation, and steps to mitigate harm to individuals.
Who is the contact point? A named person who can answer follow-up questions.
The second and third questions are where organisations fail, and they fail for the same reason: answering requires knowing what data was where. An organisation without a data inventory cannot say which categories were in the affected system, and cannot estimate how many people are represented.
That inventory is either maintained continuously or unavailable during the incident. There is no third option, and its absence is what turns a manageable notification into a compliance failure layered on top of a security failure.
Why Scope Determination Takes Too Long
The forensic question — what did the attacker actually access — is genuinely difficult, and understanding why prevents unrealistic planning.
Access is not logged at the row level. You may know an attacker held valid database credentials for eleven days. Determining which queries they ran requires query logging that most systems do not enable by default because of its performance cost.
Exfiltration is hard to confirm. Network flow records may show a large outbound transfer to cloud storage. They rarely show what the transfer contained. Absent full packet capture, which almost nobody retains, the contents are inferred rather than known.
Logs have expired. If the intrusion began four months ago and log retention is 30 days, the initial access and much of the activity are unrecoverable. This is common and it caps what any investigation can conclude.
Attackers clear evidence. Log deletion and timestamp manipulation are standard practice, particularly around the initial access point.
Lateral movement is hard to bound. Determining every system reached requires correlating authentication records across the environment, which requires centralised authentication logging.
The consequence is that many investigations conclude with a scope that is bounded by what cannot be excluded rather than by what is confirmed. Notifying based on “all data in this system may have been accessed” is the honest position and it is broader — and more damaging — than a precise finding would have been.
Better logging narrows the notification. That is a direct, measurable business benefit of log retention that is rarely used to justify it.
Evidence You Must Already Have
The evidence that determines investigation speed and scope precision:
| Evidence | Enables | Typical retention needed |
|---|---|---|
| Authentication logs, centralised | Bounding lateral movement | 12 months minimum |
| Database query logs | Determining what was read | 90 days if feasible |
| Network flow records | Detecting exfiltration volume | 90 days |
| Cloud audit logs | Configuration and access changes | 12 months |
| Endpoint telemetry | Process execution, initial access | 90 days |
| Data inventory | Answering what categories, how many | Current, maintained |
| Asset inventory | Knowing what exists to investigate | Current, maintained |
The two inventory rows are the ones that cannot be reconstructed under time pressure and the ones most frequently absent. Log data at least exists if retained. An inventory that was never built cannot be assembled during an incident, and every subsequent question depends on it.
Database query logging deserves specific comment because it is commonly disabled for performance reasons, and that decision has a direct consequence: without it, “an attacker held valid credentials for eleven days” cannot be narrowed to what they actually accessed. The notification therefore covers everything reachable with those credentials. Whether the performance cost is worth the scope precision is a real trade-off, and it should be a deliberate decision rather than a default.
Deciding Whether It Is Notifiable
Not every incident requires notification, and the assessment is a judgement that should be documented regardless of the outcome.
Factors that typically drive the decision: whether personal data was involved at all; the sensitivity of the categories; whether the data was encrypted and whether the keys were also compromised; the number of individuals; the likelihood of harm — identity theft, financial loss, discrimination, reputational damage; and whether the data has been recovered or the risk mitigated.
Encryption is worth understanding precisely, because it is frequently misapplied as a blanket exemption. Properly encrypted data with keys that were not compromised may not require notification in some jurisdictions, because the data is not accessible. Encrypted data where the attacker also obtained the keys, or where the application decrypted it in the course of normal operation the attacker was able to invoke, provides no such relief.
Two procedural points matter more than they appear. Document the assessment even when the conclusion is that notification is not required — the reasoning is what you will need to defend. And note that the threshold for notifying individuals is typically higher than for notifying the regulator, so the two decisions are separate.
The Multi-Jurisdiction Problem
An incident affecting users in several countries triggers several regimes simultaneously, with different deadlines, thresholds, and recipients.
Deadlines vary from as little as 24 hours in some sectoral rules to 72 hours in several general frameworks to “without unreasonable delay” in others. Thresholds differ — some require notification of any personal data breach, others only where harm is likely. Some jurisdictions require notifying a central authority, others a state-level one, and sectoral regulators may apply in addition. Contractual obligations to enterprise customers frequently impose shorter deadlines than any law.
This is genuinely difficult to navigate under time pressure, which is why it should be worked out in advance. A prepared matrix mapping the jurisdictions where you hold data, the applicable regimes, the deadline for each, the threshold, and the recipient converts a research problem during an incident into a lookup.
The pragmatic approach many organisations adopt is to work to the shortest applicable deadline and the lowest applicable threshold, which avoids reasoning through the variations while the clock runs.
Preparing Before the Incident
The work that determines whether notification is manageable:
Maintain a data inventory. Which systems hold which categories of personal data, for how many individuals, in which jurisdictions. This is the single most important artefact and it must be current.
Set log retention deliberately, with notification in mind. Twelve months for authentication and cloud audit logs. Enable database query logging where performance permits. Frame the cost as scope precision rather than as storage.
Build the jurisdiction matrix. Regimes, deadlines, thresholds, and recipients, prepared in advance.
Prepare notification templates. Regulator submissions and individual notices, drafted and reviewed before they are needed. Writing them during an incident produces worse documents slowly.
Identify external counsel and forensic support in advance. Retainers in place, contacts known. Procuring specialist help during an incident wastes days.
Define the decision authority. Who decides whether to notify, who approves the content, who speaks publicly. Ambiguity here costs more time than any technical step.
Run an exercise that includes notification. Most tabletop exercises stop at containment. Continue through the notification decision and the drafting, because that is where the gaps appear.
That final item is the highest-value preparation available. Teams that exercise the notification path discover which questions they cannot answer while there is still time to build the capability to answer them.
Communication Under Uncertainty
The communication challenge is describing an incident you do not yet fully understand, accurately.
Principles that hold up:
State what is known, what is not, and what you are doing. Uncertainty communicated clearly is more credible than false precision.
Never speculate downward. “We believe no data was accessed” followed two weeks later by evidence of substantial access is considerably worse than initial uncertainty. The correction is the story rather than the incident.
Distinguish confirmed from possible explicitly. “We have confirmed X. We cannot yet exclude Y.”
Tell affected individuals what to do. Specific protective actions, not general reassurance. This is the part that helps people and it is frequently the thinnest section.
Commit to update timing and meet it. “We will provide an update by Friday” builds credibility only if Friday’s update arrives.
Coordinate with legal before publishing. Statements have legal consequences and may be used in subsequent proceedings.
The recurring failure is premature reassurance driven by a desire to limit reputational damage. It reliably produces worse outcomes than initial honesty, because the retraction attracts more attention than the original disclosure would have.
Common Pitfalls
No data inventory. Makes the categories and volume questions unanswerable, and they are mandatory.
Log retention shorter than typical dwell time. Caps investigation scope at what cannot be excluded.
Treating the deadline as starting after investigation. It starts at awareness of a likely breach.
Premature reassurance. The correction becomes the story.
No prepared jurisdiction matrix. Research under time pressure produces errors and delay.
Exercises that stop at containment. The notification path is where the gaps are.
Undocumented no-notification decisions. The reasoning is what you need to defend later.
Conclusion
Breach notification is an engineering readiness problem wearing legal clothing. The deadline starts at awareness, the mandatory questions concern data categories and affected volumes, and answering them depends on inventory and logs that either already exist or do not.
The preparation that matters: a current data inventory mapping systems to data categories and jurisdictions, log retention long enough to cover realistic dwell times, a prepared jurisdiction matrix, drafted templates, identified external support, and unambiguous decision authority.
Then exercise the notification path specifically, past containment, to the point of drafting a submission. That exercise reveals which of the required questions you cannot currently answer, which is precisely the information you need before an incident rather than during one.
And when it happens, communicate uncertainty honestly. The organisations that handle breaches well are not the ones that avoid them — they are the ones that can say what happened, to whom, and what they are doing, within days rather than months.
Frequently Asked Questions
When exactly does the notification clock start? When you become aware that a personal data breach has likely occurred — not when it is confirmed, and not when the investigation concludes. A credible alert or report starts it.
What if the scope is unknown at the deadline? Submit an initial notification with what is established, state explicitly what remains under investigation, and supplement as facts emerge. Phased notification is anticipated by most frameworks.
Does encryption remove the obligation? Sometimes, where the data was properly encrypted and the keys were not compromised. If the attacker obtained keys, or the application decrypted data in operations they could invoke, it provides no relief.
Do individuals always need to be notified? Generally only where harm is likely, which is a higher threshold than regulator notification. The two decisions are separate and should be documented separately.
How long should logs be retained for this purpose? Twelve months for authentication and cloud audit logs, given that intrusions are frequently discovered months after they begin. Shorter retention caps what any investigation can determine.
Should a breach be disclosed publicly before notifying the regulator? Coordinate with legal counsel. Public disclosure ahead of regulatory notification can complicate the regulatory relationship, and there are situations where prompt public warning is appropriate.
What is the most common readiness gap? The data inventory. Log retention is a close second. Both are unrecoverable during an incident and both are the foundation for every mandatory question.
