Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Compromise vs access vs exfiltration vs confirmed data breach
Last verifiedCompromise, access, exfiltration, and a confirmed data breach are four different claims. A NIST incident is not a legal breach. GDPR Article 4(12) is an EU legal definition. Counsel maps YOUR statute. This page is not legal advice.
Operational guidance, last verified 7 September 2026 against Regulation (EU) 2016/679 Article 4(12) (the GDPR legal definition of a personal data breach — an EU legal term of art, not a universal English word), NIST SP 800-61 Revision 3 (April 2025 current final; it superseded Revision 2) (Computer Security Incident Handling Guide — guidance that works in incidents, not a statute that defines a notifiable breach), ENISA's Recommendations for a methodology of the assessment of severity of personal data breaches (working methodology for DPAs and controllers — not a statute and not a notification determination), and the FTC Data Breach Response guide (US regulator guidance noting state-and-territory security-breach notification laws; not a US federal data-breach statute). This page does not start a notification clock, does not classify YOUR incident, and is not a substitute for counsel, your insurer, or a retained DFIR firm. The incident-timeline page on this site is the UTC template, timezone and clock-skew notes, dwell markers, and evidence-citation discipline. Not legal advice.
Four terms — definition, evidence, typical obligations
Audience: the leader who has to decide what to call the incident in an internal note, a board pack, or an external statement, and counsel directing that language. The we've-been-breached page on this site is the first-moves hub. The first-72-hours page on this site is the clock-mapping checklist. The contact-breach-counsel page on this site is the privilege-and-engagement checklist. This page is the taxonomy: four claims that English collapses into 'breach', why the distinction drives notification analysis and public statements, and what evidence each claim needs. It does not rank DFIR firms, does not name any, and does not start a notification clock.
Use the four terms as operational claims, not as a finding that any statute applies. Compromise and exfiltration are technical states. Access is both a technical observation and, in some statutes, a legal trigger. Confirmed data breach is a legal determination under a named statute. Last verified 7 September 2026. Not legal advice.
| Term | Definition | Evidence needed | Typical obligations (examples only) | What this page is not saying |
|---|---|---|---|---|
| Compromise | A technical state: a host, identity, control, or environment is no longer trustworthy — violated, or reasonably believed to be. NIST SP 800-61r2's working unit is an incident: a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. That is guidance, not a statute. | Detection, scoped affected systems and identities, UTC timeline of first-seen and containment, and the evidence hold. You do not need a copy of data leaving the estate to call a system compromised. | Run the incident process: isolate, preserve, brief counsel and the insurer. Mapping which notification clocks MAY apply is a counsel question. Compromise alone is not automatically individual notice. | Not saying a legal 'breach' has occurred. Not saying you must notify. Not saying NIST's incident definition is a notification statute. |
| Access | A technical (and sometimes legal) claim: an unauthorised party could see, retrieve, or use data. GDPR Article 4(12) includes unauthorised access to personal data in the legal definition of a personal data breach — when GDPR applies. Some US state and sector rules trigger on unauthorised acquisition or access rather than proven theft. Those are legal terms of art. Counsel maps YOUR statute. | Auth, cloud, object, mailbox, or database logs showing a sign-in, GetObject, SELECT, file open, or equivalent. Access is not exfiltration. The was-data-stolen page on this site is the evidence-to-conclusion map. | Some regimes treat unauthorised access or acquisition as enough to start a notification analysis even without a proven copy leaving. Others do not. Mapping is not filing. This page does not start a clock. | Not saying GDPR Article 4(12) applies to you. Not saying access equals theft. Not saying English 'they accessed it' is a legal finding. |
| Exfiltration | A technical claim: a copy of data left a named boundary you can point to — an egress path, a cloud-to-cloud copy, media, or an attacker-controlled store. It is an evidence conclusion, not a legal status. | Egress or network logs, cloud copy or cross-account events, staging artifacts plus a later leave, or DLP on a channel it actually watches. Missing egress logs do not prove no theft. Access is not exfiltration. | Often material to whether a notification duty MAY apply, and to what you may say externally. Still not automatic. Counsel maps the statute. A technical 'left' is not a legal 'breach' by itself. | Not saying exfiltration is automatically a notifiable data breach. Not saying absence of egress logs is proof of no theft. Not starting a clock. |
| Confirmed data breach | A legal determination under a named statute that a notifiable 'breach', 'personal data breach', or equivalent has occurred. GDPR Article 4(12) is the EU legal definition of a personal data breach. US state and sector rules each define their own trigger. 'Breach' is often a legal term of art — verify per statute. There is no general US federal data-breach statute covering all personal data. | Counsel's application of YOUR facts to YOUR statute: what the law treats as the trigger (access, acquisition, compromise of confidentiality, unauthorised disclosure, a risk threshold), plus the technical record. This page does not make that call. | Duties that MAY apply once counsel says the legal trigger is met: GDPR Articles 33 and 34, CRA Article 14 (a different statute — product security, not personal data), US state-and-territory security-breach notification laws, sector rules such as HIPAA or the FTC Health Breach Notification Rule. Recipients, clocks, and content differ. Mapping is not filing. | Not saying this page, this product, or English usage has confirmed a breach. Not saying any listed duty is yours. Not legal advice. Not a US federal 'data breach' statute — none of general application exists. |
Legal definition versus technical state
A NIST incident is a technical and operational state. A 'data breach' in a press release is English. A 'personal data breach' in GDPR Article 4(12) is a legal definition that applies only when GDPR applies. Do not treat those three as the same word. Last verified 7 September 2026. Not legal advice.
GDPR Article 4(12): 'personal data breach' means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. That sentence is an EU legal definition. It includes unauthorised access, destruction, loss, and alteration — not only exfiltration. It is not a universal English dictionary entry and it is not a US statute. Whether it applies to you is counsel's call.
NIST SP 800-61r2 does not define a notifiable 'data breach'. It defines an incident as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices, and it tells responders to seek legal guidance when an incident may have legal ramifications. That is guidance, not a notification law. ENISA's 2013 severity methodology is a working assessment aid for DPAs and controllers (data nature, ease of identification, circumstances of the breach). It is not GDPR Article 4(12), not Article 33, and not a ruling that a duty has started.
In the United States there is no general federal 'data breach' statute covering all personal data. The FTC Data Breach Response guide (regulator guidance, not a statute) notes that every US state plus the District of Columbia, Puerto Rico, and the Virgin Islands has a security-breach notification law. Sector rules such as HIPAA and the FTC Health Breach Notification Rule have their own definitions. CIRCIA is a critical-infrastructure incident-reporting statute, not a general data-breach law, and its reporting rule is not in effect. Do not import a federal 'data breach' duty from English. Counsel maps YOUR facts to YOUR statutes.
- Write the technical state you can evidence (compromise, access, exfiltration) separately from the legal label you have not yet earned.
- Do not say 'we were breached' in an external statement because a host was compromised. Do not say 'it was only a compromise' to avoid a statute that triggers on access. Both sentences mix terms.
- 'Breach' is often a legal term of art. Verify the definition in the statute you are about to cite. This page does not verify it for you.
- The incident-timeline page on this site is the UTC template, timezone and clock-skew notes, dwell markers, and evidence-citation discipline. Keep UTC. Corrections are new lines.
- This page does not start a notification clock, does not classify YOUR incident, and is not legal advice.
Why the distinction drives notice and public statements
Notification obligations and public statements fail in both directions: calling a compromise a 'data breach' can over-notify and create a record you cannot defend; calling a legal breach a 'security incident' can under-notify. The distinction is why counsel owns the legal label and the incident lead owns the technical facts. Last verified 7 September 2026. Not legal advice.
- Internal: the UTC timeline records technical claims (compromised host, access event, egress evidence, unknowns). It does not need the word 'breach' to be useful.
- Counsel: maps those facts onto named statutes. GDPR Article 4(12) plus Article 33, a US state acquisition test, HIPAA, CRA Article 14 — different triggers, different recipients, different clocks. Mapping is not filing. The first-72-hours page on this site walks two 72-hour bands that MAY apply.
- External: a public statement, customer email, or status page is evidence. CISA: do not tip the actor. Need-to-know remains the default until counsel says a duty to communicate has started.
- The was-data-stolen page on this site is the evidence-to-conclusion map. Do not collapse access into exfiltration in any of those three places.
Where this shows up in ShipReady Metrics
The signed-in app does not classify an incident as a 'breach', apply GDPR Article 4(12), decide that a US state or sector notification law has been triggered, or start a notification clock. It does ingest security findings (Dependabot, SAST / code scanning, secret scanning, and DAST). If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a breach classification, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. The obligation map (frameworks you have marked in-scope) is under Compliance. The cyber risk register lives under Security. None of those surfaces decides that a compromise, an access event, an exfiltration, or a confirmed data breach has occurred.
Primary sources (last verified 7 September 2026)
Every definitional and regulatory claim on this page is taken from one of these. If a later revision of a source changes the text, the date above is how you can see we have not re-checked yet.
Regulation (EU) 2016/679 Article 4(12) is the GDPR legal definition of a personal data breach — a legal requirement's vocabulary only when GDPR applies, not a universal English word. NIST SP 800-61 Revision 3 (April 2025) is the current final Incident Response Recommendations and Considerations for Cybersecurity Risk Management: a CSF 2.0 Community Profile; it supersedes NIST SP 800-61r2 (August 2012), Computer Security Incident Handling Guide — guidance that defines an incident, not a statute that defines a notifiable breach. ENISA's Recommendations for a methodology of the assessment of severity of personal data breaches (20 December 2013) is a working methodology developed with the Greek and German DPAs for use by DPAs and controllers; it is not a statute, not Article 4(12), and not a notification determination. The FTC Data Breach Response guide is US regulator guidance for businesses; it points at state-and-territory security-breach notification laws and sector rules. It is not a US federal data-breach statute. There is no general US federal data-breach statute covering all personal data. Last verified 7 September 2026.