Event vs Incident vs Breach: Definitions and Legal Duties

Calling something an incident or a breach is not a matter of style: each word starts different clocks, different notification duties and different evidence obligations, and the definitions change from one law to the next. A single ransomware intrusion can be a NIST "cybersecurity incident" on day one, a GDPR "personal data breach" by day two, a NIS2 "significant incident" with a 24 hour early warning, and a matter the SEC expects you to assess for materiality without unreasonable delay. This guide sets the three terms side by side across NIST, GDPR, NIS2, HIPAA and the SEC rules, shows where the escalation thresholds sit, explains how legal privilege interacts with the labels, and lists the failure modes that turn a well handled response into a regulatory finding. It is written for incident response leads, privacy and legal teams, and the security managers who write the classification rules everyone else follows.

Key takeaways

An event is anything observable; an incident is an event that jeopardises confidentiality, integrity or availability or breaks policy; a breach is a legally defined subset of incidents, and each law draws its own boundary.
Clocks start on awareness or determination, not on certainty: GDPR counts 72 hours from becoming aware, NIS2 counts 24 and 72 hours from becoming aware of a significant incident, and the SEC counts four business days from the materiality determination.
"Breach" is not limited to theft: GDPR covers loss of availability and unauthorised alteration, and HIPAA presumes an impermissible disclosure is a breach unless a documented four factor assessment shows low probability of compromise.
Declaration criteria belong in the plan, not in the moment: NIST CSF 2.0 DE.AE-08 expects incidents to be declared when adverse events meet defined criteria, so write those criteria before you need them.
Labels are discoverable: a ticket titled "data breach" before counsel has assessed it can become evidence, so use neutral working terms and route legal conclusions through counsel.

The short answer

Every data breach is an incident, and every incident starts as one or more events, but most events are never incidents and most incidents are never reportable breaches. The working distinction is about consequence and obligation:

Event: any observable occurrence in a system or network: a failed logon, a firewall deny, a new process, an expired certificate. Events are raw material for detection. NIST CSF 2.0 uses the narrower term "adverse event" for events that may have a negative effect and are worth analysis (DE.AE-02).
Incident: an occurrence that actually or imminently jeopardises the confidentiality, integrity or availability of information or systems, or violates law, security policy or acceptable use. This is the NIST and FISMA lineage that SP 800-61 Rev. 3 carries forward. Declaring an incident activates your response plan.
Breach: a term each regime defines for its own purpose, usually tied to a category of data (personal data, protected health information) or a level of harm. A breach determination is a legal conclusion that triggers notification analysis.

The trap is that "significant incident" (NIS2) and "material cybersecurity incident" (SEC) are reportable without any personal data being involved, so the old shortcut "breach means personal data was stolen" misses half of today's duties. For the risk vocabulary that sits underneath (threat, vulnerability and risk), see the Threat vs Vulnerability vs Risk Guide.

Dimension	Event	Incident	Breach (regime specific)
What it is	Any observable occurrence	Occurrence that jeopardises CIA or violates policy or law	Incident meeting a statutory definition, usually involving a protected data type or harm threshold
Who decides	Tooling and analysts (automatic)	Incident commander or SOC lead against written criteria	Privacy officer, DPO or counsel, on facts from the response team
Typical volume	Millions per day	Tens to hundreds per year	A handful per year
Triggers	Logging, correlation, alert rules	Response plan, containment, evidence handling	Notification analysis, regulator and individual notices, record keeping
Main record	Log store, SIEM	Incident ticket and timeline	Breach register and notification file
Error that hurts most	Not collected, so no evidence later	Declared late, so containment and clocks slip	Under or over called, so missed deadline or needless disclosure

Definitions by framework

The table below uses the definitions as published. Where the source wording is long it is paraphrased with the key phrase kept. Check the current text before relying on it in a notification decision: rules are amended, and the EU Digital Omnibus proposal would change some EU reporting mechanics if adopted.

Source	Term	Definition (key wording)	Personal data needed?
NIST glossary (FIPS 200 lineage)	Incident	An occurrence that actually or potentially jeopardises the confidentiality, integrity or availability of a system or its information, or violates security policies, procedures or acceptable use policies	No
FISMA, 44 U.S.C. 3552 (used by SP 800-61 Rev. 3)	(Cybersecurity) incident	An occurrence that actually or imminently jeopardises, without lawful authority, information or a system, or constitutes a violation or imminent threat of violation of law, security policies or procedures	No
NIST CSF 2.0	Adverse event / incident	Adverse events are analysed (DE.AE-02) and incidents declared when adverse events meet defined criteria (DE.AE-08)	No
GDPR Art. 4(12)	Personal data breach	A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data	Yes
NIS2 Art. 6(5)	Near miss	An event that could have compromised availability, authenticity, integrity or confidentiality but was prevented or did not materialise	No
NIS2 Art. 6(6)	Incident	An event compromising the availability, authenticity, integrity or confidentiality of data or of the services offered by or accessible via network and information systems	No
NIS2 Art. 23(3)	Significant incident	Has caused or can cause severe operational disruption or financial loss to the entity, or considerable material or non-material damage to others	No
SEC, Regulation S-K Item 106(a)	Cybersecurity incident	An unauthorised occurrence, or a series of related unauthorised occurrences, on or through a registrant's information systems that jeopardises their confidentiality, integrity or availability or the information in them	No
HIPAA, 45 CFR 164.402	Breach	Acquisition, access, use or disclosure of protected health information in a manner not permitted, which compromises its security or privacy; presumed unless a risk assessment shows low probability of compromise	Yes (PHI)

Three details in these definitions catch teams out. First, NIS2 adds authenticity to the usual triad, so a forged signing key or spoofed service identity can be an incident even with no data read. Second, the SEC definition explicitly covers a series of related occurrences, so several individually minor events tied to one actor or campaign can add up to one incident for materiality purposes. Third, GDPR counts availability: the ICO lists data becoming unavailable in a way that significantly harms individuals as a personal data breach, so a ransomware outage of an HR system is in scope even if nothing was copied.

Escalation thresholds and the clocks they start

The moment a label changes is the moment a deadline starts. Write down, for each regime that applies to you, what starts the clock and who is allowed to stop or start it.

Regime	Threshold	Clock start	Deadline	Recipient
GDPR Art. 33	Personal data breach unless unlikely to result in a risk to individuals	Controller becomes aware	Without undue delay and, where feasible, within 72 hours; reasons given if later; phased reporting allowed	Lead supervisory authority
GDPR Art. 34	Likely high risk to individuals' rights and freedoms	Same awareness point	Without undue delay (no fixed hours)	Affected individuals
UK GDPR (ICO)	Same risk test	Becoming aware	No later than 72 hours; reasons if late	ICO, then individuals for high risk
NIS2 Art. 23	Significant incident	Becoming aware of the significant incident	Early warning 24 hours; notification 72 hours; final report one month after notification (trust service providers: 24 hour notification)	CSIRT or competent authority; recipients of services where appropriate
SEC Form 8-K Item 1.05	Material cybersecurity incident	Materiality determination, which must be made without unreasonable delay after discovery	Four business days after the determination; delay only on written Attorney General notice of substantial national security or public safety risk	Investors via EDGAR (foreign private issuers use Form 6-K)
HIPAA Breach Notification Rule	Breach of unsecured PHI	Discovery	See the HIPAA guide for individual, HHS and media timelines	Individuals, HHS, media for large breaches

Two practical consequences follow. GDPR and NIS2 run from awareness, which the regulators read as reasonable certainty that a qualifying event happened, not completed forensics, so a team that waits for the full root cause report before "becoming aware" has already missed the window. The SEC runs from a determination, but requires that determination without unreasonable delay, so stalling the materiality meeting is itself a compliance risk. Deep detail on each regime lives in the NIS2 Directive Guide, the SEC Cybersecurity Disclosure Rules Guide, the HIPAA Breach Notification Rule Guide and the Breach Notification Laws by Country Guide.

Event to incident: building declaration criteria

Threat model: the risk at this boundary is under declaration. Analysts close alerts as benign because the ticket queue rewards closure, and a slow credential stuffing campaign or a misused service account token stays an "event" for weeks. The opposite failure, declaring everything, burns the response team and dilutes the word.

How it works: events are collected and correlated (DE.AE-03), triaged as potentially adverse (DE.AE-02), scoped for estimated impact (DE.AE-04), and declared as incidents when they meet written criteria (DE.AE-08). Response then follows RS.MA-02 (triage and validation), RS.MA-03 (categorisation and prioritisation) and RS.MA-04 (escalation). NIST SP 800-61 Rev. 3, published April 2025 as a CSF 2.0 Community Profile, replaces the 2012 Rev. 2 lifecycle with this CSF based structure.

Declaration criteria that work in practice:

Confirmed unauthorised access: any successful authentication or token use by a party not entitled to it, including non-human identities such as service accounts, API keys and OAuth grants.
Integrity change without authorisation: unexpected changes to production code, configuration, identity provider settings or audit policy.
Availability loss beyond a set threshold: for example any security caused outage of a tier 1 service, or any encryption of data by an unknown process.
Policy or legal violation: data sent to an unapproved destination, insider misuse, or a third party notifying you of a compromise that affects your data.
Protected data in scope: any of the above touching personal data, PHI, payment data or regulated operational systems, which also starts the breach assessment in parallel.

Pair the criteria with a severity scale so that "incident" does not imply "crisis". The Incident Severity Classification Matrix Template gives a ready structure, and the Alert Triage Guide covers the analyst workflow before declaration.

Failure modes: criteria written only for malware, so identity abuse is never declared; and declaration authority held by one person who is on leave.

Incident to breach: the legal assessment

Threat model: the risk here is a wrong call in either direction. Under calling misses a deadline and invites enforcement: the ICO states that failing to notify a notifiable breach can bring a fine of up to £8.7 million or 2% of global turnover. Over calling discloses an event that never needed disclosure, with reputational and litigation cost.

How it works: the response team supplies facts; privacy and legal apply each regime's test. Run the assessments in parallel, not in series, because the questions differ:

GDPR: is personal data involved, and what is the likelihood and severity of risk to individuals? The ICO focuses on potential harm such as identity fraud, financial loss or distress. Record the decision either way: Art. 33(5) and the ICO require documentation of all personal data breaches, reported or not, so a decision not to notify must be justifiable on file.
HIPAA: the burden is reversed. An impermissible use or disclosure of PHI is presumed a breach unless a documented assessment of four factors (nature and extent of the PHI, who received it, whether it was actually acquired or viewed, and the extent of mitigation) shows a low probability of compromise. Three narrow exceptions apply, such as unintentional good faith access by a workforce member.
NIS2: no data type test at all. The question is operational and financial impact, or damage to others. Implementing Regulation (EU) 2024/2690 adds specific thresholds for digital infrastructure and digital service providers; see the NIS2 Implementing Regulation 2024/2690 Guide.
SEC: would a reasonable investor consider the incident important, taking qualitative factors such as reputation, customer relationships and litigation exposure into account alongside financial impact? The 8-K must describe the material aspects of nature, scope and timing, and the actual or reasonably likely material impact.

Failure modes: treating encryption as an automatic exemption without checking whether keys were also exposed; assuming "no exfiltration evidence" means "no breach" when logging was too thin to tell; and letting each regime's owner work alone, so the GDPR file and the 8-K describe the same event inconsistently.

Legal privilege and the language you use

The labels discussed above are not only operational; they end up in tickets, chat channels and board papers that can be disclosed in litigation or regulatory inquiry. Privilege rules differ by jurisdiction and are narrower than many teams assume, so treat the following as practice points to agree with counsel, and read the Legal Privilege in Incident Response Guide for the detail.

Use neutral working terms: "security event under investigation" or "incident INC-1234" until counsel has made the breach determination. A ticket titled "customer data breach" written at 02:00 by an analyst is a conclusion nobody has reached.
Separate the facts record from the legal analysis: the incident timeline (what happened, when, what was done) is usually discoverable; the assessment of whether it meets a statutory definition is where counsel's involvement matters.
Engage forensic firms through counsel where that is your legal position, and keep their scope tied to legal advice rather than routine remediation, which courts in some jurisdictions have treated as ordinary business work.
Do not let privilege slow notification: privilege protects analysis, not deadlines. The 72 hour and 24 hour clocks still run.

Worked scenario: one intrusion, four labels

A European subsidiary of a US listed company finds an unfamiliar OAuth application with read access to its customer relationship management tenant. The timeline below shows how the labels change.

Day 0, 09:00, event: a cloud security tool alerts on a new third party OAuth grant with broad scopes. An analyst triages it as a potentially adverse event.
Day 0, 13:00, incident declared: the grant was made by a compromised integration account and audit logs show bulk export API calls. Declaration criterion 1 (unauthorised access by a non-human identity) is met. The response plan starts, tokens are revoked and the integration secret rotated. See the Salesloft Drift breach for a real case of stolen OAuth tokens used against customer CRM data.
Day 1, 10:00, awareness for GDPR and NIS2: logs confirm customer contact records were exported. The DPO records awareness; the 72 hour GDPR clock is running. Because the subsidiary is an essential entity and customer services were disrupted while access was cut, the NIS2 owner assesses significance and files a 24 hour early warning.
Day 2, materiality meeting: the disclosure committee considers customer volume, contract exposure and likely regulatory action. It documents the analysis and concludes the incident is not currently material, scheduling a re-review as facts develop.
Day 3, notifications: the supervisory authority is notified with the facts known and a promise of phased updates. Individuals are not notified because the exported fields carry limited risk, and that reasoning is recorded in the breach register.

One set of facts, four labels, four owners, one timeline.

Where identity fits

Many incidents now begin with an identity rather than malware: a leaked API key, an over scoped OAuth grant, a stolen session token, or a service account used outside its normal pattern. These are easy to leave at "event" level because nothing looks broken. Add explicit declaration criteria for non-human identity misuse, log token issuance and use, and make "which identities were used and what could they reach" a standard scoping question, because it drives the "access to personal data" element of the GDPR test. The Incident Response Guide covers the wider response process.

Common failure patterns

Waiting for certainty: treating "aware" as "forensics complete", so the 72 hour window closes before anyone considers notification.
One definition for everything: an internal policy that defines "breach" only as theft of personal data, so NIS2 and SEC duties are never triggered by an outage or a ransomware event.
No near miss record: blocked intrusions are closed without a note, losing the pattern evidence that justifies control investment and that NIS2 vocabulary expects you to recognise.
Undocumented "no notify" decisions: the risk assessment happened in a call and was never written down, so the decision cannot be defended later.
Uncoordinated filings: GDPR, NIS2, SEC and customer communications drafted by different teams, with different numbers and different timelines.
Loaded labels in tickets: premature "breach" language in records that later go to a regulator or court.

Detection and measurement

Event to declaration time: median hours from first related alert to incident declaration, by severity.
Declaration to breach decision time: median hours from declaration to documented breach determination for incidents involving protected data; target well inside 72 hours.
Deadline compliance: percentage of regulatory notifications filed within the applicable window over the last 12 months.
Documentation completeness: percentage of incidents with protected data in scope that have a written notify or not notify rationale.
Reclassification rate: share of closed events later reopened as incidents, a direct signal of under declaration.
Near miss capture: number of prevented incidents recorded per quarter, which should rise as the culture improves.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.AE-02, DE.AE-03, DE.AE-04, DE.AE-08	Analyse adverse events, correlate, estimate impact, declare incidents against criteria
NIST CSF 2.0	RS.MA-02, RS.MA-03, RS.MA-04, RS.CO-02	Triage, categorise, escalate and notify stakeholders
NIST SP 800-53 Rev. 5	IR-4, IR-5, IR-6, IR-8, AU-6	Incident handling, monitoring, reporting, response plan, audit review
NIST SP 800-61 Rev. 3	Whole document	Incident response recommendations organised by CSF 2.0
ISO/IEC 27001:2022 Annex A	5.24 to 5.28, 6.8	Incident management planning, assessment of events, response, learning, evidence, and event reporting
GDPR	Art. 4(12), 33, 34	Breach definition, authority and individual notification, documentation
NIS2	Art. 6, 23	Incident and near miss definitions, significant incident reporting

Practitioner checklist

Publish one glossary for event, adverse event, incident, near miss and each regime's breach term, and use it in tooling and tickets.
Write declaration criteria that include non-human identity misuse, integrity changes and availability loss, not just malware.
List every notification regime that applies to each legal entity, with clock start, deadline and owner.
Define who records "awareness" and how, so the GDPR and NIS2 start time is evidenced.
Run GDPR, HIPAA, NIS2 and SEC assessments in parallel from one fact record.
Document every notify or not notify decision with its reasoning in a breach register.
Agree neutral working language and a privilege protocol with counsel before an incident.
Record near misses and review them quarterly.
Exercise the full chain from alert to filing at least once a year, including a weekend start.

Standards and references

Related NHI Mgmt Group resources: Incident Response Guide, Threat vs Vulnerability vs Risk Guide, Data Breach Notification Checklist, Security Incident Report Form Template. This guide summarises the definitions and notification thresholds in the laws and frameworks named and is not legal advice.

Event vs Incident vs Breach: Definitions That Trigger Legal Duties