Skip to main content

Breach Determination & Notification

In one line: Not every security incident is a legally-reportable breach — the determination hinges on whether the evidence shows that regulated/sensitive data was actually accessed or stolen — and once it is a breach, a regulatory clock starts (often as tight as 72 hours), making this the phase where forensic findings collide with law, and where preparation and honesty matter more than technical skill.

In plain English

You've contained, investigated, and built the timeline. Now comes a different kind of hard question — not technical, but legal and ethical: do we have to tell people? There's a critical distinction the law cares about. A security incident is anything bad that happened. A breach is the specific, regulated subset where sensitive personal data was actually exposed or stolen — and that triggers legal obligations to notify regulators and often the affected individuals, frequently on a brutally short deadline (the EU's GDPR gives you 72 hours). This is where your forensic work becomes high-stakes: the timeline and scope you reconstructed are exactly the evidence that decides whether (and what) you must report. Getting it wrong is dangerous in both directions — over-report and you cause needless alarm and cost; under-report (or cover up) and you face escalating legal penalties and destroyed trust. This lesson is that judgment call and the clock around it.

These words are used loosely in conversation but mean very different things to a regulator:

  • Security incident — any event that compromises security: a malware infection, a phishing attempt that's caught, a DoS, an attacker who got in but reached nothing sensitive. Most incidents are not breaches.
  • (Data) breach — the subset where protected/sensitive data was actually accessed, acquired, or disclosed to an unauthorized party. This is what typically triggers legal notification duties.

The line between them is what the attacker actually reached. An attacker who got a foothold on a web server but never accessed the customer database caused an incident; one who exfiltrated that database caused a breach. The whole point of the forensic investigation and timeline is, in part, to answer this question with evidence.

Terms, defined once
  • Security incident — any compromise of security; the broad category.
  • Data breach — an incident where sensitive/regulated data was actually accessed, acquired, or disclosed without authorization; the reportable subset.
  • PII / sensitive data — Personally Identifiable Information (names, SSNs, financials) and other regulated categories (health data, payment cards) whose exposure triggers obligations.
  • Notification obligation — the legal duty to inform regulators and/or affected individuals within a set timeframe after a breach.
  • GDPR 72-hour rule — the EU requirement to notify the supervisory authority of a personal-data breach within 72 hours of becoming aware of it.
  • Materiality — whether an incident is significant enough to require disclosure (a concept in several regulatory regimes).
  • Confidence level — whether the evidence confirms data was taken vs. merely can't rule it out, which shapes the determination.

What the evidence has to show​

The determination is an evidence question, and it's where your investigation's rigor pays off. You're trying to establish, defensibly:

  • Was sensitive data in the attacker's reach? Did the timeline show access to systems/stores holding PII or regulated data?
  • Was it actually accessed or exfiltrated — or just reachable? There's a meaningful difference between "the attacker was on a server that had the database" and "the attacker queried and exfiltrated the database." Network exfiltration evidence and access logs are what distinguish them.
  • What data, and whose? Scope (which records, which individuals, which jurisdictions) determines who must be notified and under which laws.
Why "we can't prove they didn't" often forces disclosure

Here's the uncomfortable reality that makes logging so consequential. Regulators frequently expect notification when you cannot rule out that data was accessed — not only when you can prove it was. So if an attacker reached a database server but you have no logs showing what they did there, you often can't demonstrate that data wasn't taken — and must treat it as a breach. Conversely, an organization with thorough access logging might prove the attacker never actually queried the sensitive table, and avoid a needless notification. This is a direct, expensive payoff of good logging from Chapter 6: the difference between "we can show exactly what they touched" and "we have to assume the worst" can be millions in notification costs and reputational damage. Your logging decisions, made calmly in advance, determine your options during the worst week.

The regulatory clock​

Once an incident is determined to be a breach, the clock is already running — and it's short. Notification timeframes are tight and vary by jurisdiction and data type, but the direction is universally toward fast disclosure:

  • GDPR (EU personal data): notify the supervisory authority within 72 hours of becoming aware, and affected individuals "without undue delay" if there's high risk to them.
  • US: a patchwork — state breach-notification laws (all 50 states), sector rules (health data, financial), and newer SEC rules requiring public companies to disclose material cybersecurity incidents promptly.
  • Sector/contract obligations — payment-card rules, and contractual duties to business customers, often add their own timelines.

The crucial implication: 72 hours is not enough time to start figuring out your process. You must know in advance who decides, who notifies whom, and what your obligations are — which is why breach determination is part of IR preparation, not something you improvise mid-crisis. (The legal frameworks themselves are Chapter 10: Compliance.)

Honesty beats the cover-up — always​

The strongest temptation in this phase is to minimize — to under-report, quietly fix it, and hope no one finds out. It is also the most catastrophic mistake, repeatedly proven by real cases:

Why cover-ups multiply the damage

Organizations that concealed breaches — hid them from regulators, paid attackers to stay quiet, or delayed disclosure — have consistently fared far worse than those that disclosed promptly. The cover-up, when discovered (and it usually is), converts a defensible "we were attacked and responded responsibly" into "we were attacked and then deceived everyone." That triggers:

  • Escalated legal penalties — regulators punish concealment far more harshly than the breach itself.
  • Destroyed trust — customers forgive being breached; they don't forgive being lied to.
  • Personal liability — executives have faced personal legal consequences specifically for covering up, not for the breach.

The professional, and self-interested, path is the same: honest, timely disclosure per your obligations. Breaches happen to everyone; how you handle them is what defines you. This mirrors the blameless, truth-seeking culture of good incident response — secrecy corrupts both.

Why it matters​

  • It's where security meets the law and the public. The determination decides legal exposure, notification costs, and reputational impact — often the largest costs of a breach, dwarfing the technical cleanup.
  • It makes logging's value concrete and financial. The ability to prove what was and wasn't accessed — a direct product of telemetry decisions — can be the difference between a contained event and a mass-notification crisis.
  • It demands preparation and integrity, not just skill. A 72-hour clock and the pull toward cover-ups mean this phase rewards organizations that planned and chose honesty — a fitting capstone to the incident-response discipline.

Common pitfalls​

Where people commonly trip up
  • Conflating incident and breach. Not every incident is a reportable breach — the line is whether sensitive data was actually accessed/exfiltrated. Determine it on evidence, not assumption.
  • No logs to prove what was accessed. Without access/exfiltration evidence, you often can't rule out data theft and must assume the worst (and notify). Good logging is what gives you a defensible, narrower determination.
  • Improvising the process during the 72-hour clock. The deadline is far too short to invent your notification process mid-crisis. Decide roles, obligations, and decision-makers during IR preparation.
  • Under-reporting or covering up. Concealment escalates penalties, destroys trust, and creates personal liability — consistently worse than the breach itself. Disclose honestly and on time.
  • Ignoring jurisdictional scope. Different data, individuals, and jurisdictions trigger different laws and timelines. Establish whose data and which regimes apply.
  • Treating it as purely technical. Breach determination is a legal/business call informed by forensics — loop in legal and leadership early, not after the technical work.

Page checkpoint​

Required checkpoint

Did breach determination click?

Pass to unlock the Next button below

What's next​

→ Take the Chapter 7 checkpoint to lock in the incident-response and forensics toolkit, then continue to Chapter 8: Network Security — back to building defenses, starting with the network layer that so many of these attacks traverse.

→ Going deeper: the laws and frameworks behind notification are Chapter 10: Compliance; the logging that determines your evidence is Chapter 6; the preparation that makes a 72-hour response possible is the IR lifecycle.