The previous three entries in this series attacked terms that miscategorize on the cause side of the Bow-Tie — a precondition treated as a category, a transition treated as a threat, a sequence treated as a phenomenon. "Data breach" is a different shape of error entirely. It lives on the consequence side of the Bow-Tie, where its proper home is as a Data Risk Event annotation. When the term gets transplanted from regulatory communication into threat classification, it commits a category error that the framework's normative text — §6.2 of the v2.1 whitepaper — addresses by name.
A TLCTC cluster MUST NOT be used to classify outcomes such as "data breach", "outage", "fraud", "data destruction", or "ransomware impact".— TLCTC v2.1 §6.2, Rule 1 (Cause-Side Classification)
This entry walks the rule. The post-foothold cause side of every chain still classifies under the ten clusters; the data-layer consequence side classifies under DREs; the business-level consequence side classifies under BREs. "Data breach" is what the public reads in the press; the framework writes it as a DRE annotation on the cluster step that produced it.
§ 1The term in the wild
The term carries different precise meanings across the contexts in which it operates, and the slippage between those meanings is where the trouble starts.
GDPR Article 4(12) gives the most-cited legal definition: 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.
Read carefully, that sentence does not describe a single event type. It enumerates four — destruction, loss, alteration, and unauthorised disclosure or access — bundled under one regulatory label for the purposes of notification. The four map to four distinct DRE codes, as §3 below shows.
NIS2 (Directive 2022/2555) uses "significant incident" with similar bundling and adds availability impact as a first-class trigger alongside confidentiality. DORA (Regulation 2022/2554) defines "major ICT-related incident" with explicit thresholds for impact across confidentiality, integrity, and availability. SEC 17 CFR §229.106 (Item 1.05 of Form 8-K) uses "cybersecurity incident" with the trigger being material effect on the registrant's operations or financial condition. HIPAA distinguishes "breach" (unauthorized acquisition, access, use, or disclosure of PHI) from broader "security incident." US state breach-notification laws vary, but most centre on unauthorized acquisition of personal information — i.e., confidentiality loss specifically.
The Verizon DBIR keeps the most analytically careful distinction: an incident is a security event that compromises the integrity, confidentiality, or availability of an information asset
; a breach is an incident that results in the confirmed disclosure — not just potential exposure — of data to an unauthorized party.
The DBIR's "breach" maps almost exactly to [DRE: C]. That is unusual precision; most usages are looser.
The press and risk-register usage is looser still. There, "data breach" tends to mean any cyberattack with a data outcome, with the specific outcome left implicit. This is the usage the entry is fixing.
§ 2Why it fails the TLCTC test
Three layered structural failures.
First, consequence-side, not cause-side. The Bow-Tie model places threats (causes) on the left of the central System Risk Event (SRE) knot and outcomes on the right. "Data breach" describes an outcome — what happened to the data after compromise. It cannot occupy a slot on the cause side without making the entire model incoherent. §6.2 Rule 1 is normative on exactly this point and names the term explicitly. SG-4 reinforces the same principle for the cause-side mid-chain effects covered in Entries 02 and 03.
Second, DRE conflation. Even when a reader correctly places "data breach" on the consequence side, the term still hides analytically distinct events behind one label. GDPR's four-verb definition is the textbook case of this — destruction, loss, alteration, and unauthorised disclosure are different DREs with different defensive surfaces, different detection mechanisms, and different recovery paths. The framework keeps them separate because they are separate.
Third, layer confusion between DRE and BRE. In casual usage, "the breach" frequently refers not to the technical data event at all, but to the regulatory notification, the public disclosure, the customer-churn event, or the fine. These are Business Risk Events — discrete downstream consequences cascading from the DRE. They belong in the BRE chain, not at the DRE node. Conflating them lets organisations report on "the breach" without ever specifying whether their containment problem was a DRE that did not need to become a BRE, or a DRE → BRE chain that they failed to break.
§ 3The framework's positive answer: the SRE → DRE → BRE chain
The framework gives every concept that hides inside "data breach" its own structurally distinct home. The Bow-Tie's right-hand side is not a single outcome bucket; it is a chain of risk events, each with its own detection window and its own controls.
"Data breach" in colloquial usage straddles the two highlighted nodes. Press and risk-register usage typically refers to some unspecified DRE plus some downstream BRE — most often [DRE: C] plus GDPR/NIS2 notification. The framework writes this explicitly so the reader can see which technical event happened and which business event followed, instead of collapsing both into a single label.
The DRE codes are precise. C is Loss of Confidentiality — data disclosed to an unauthorised party. I is Loss of Integrity — data altered or fabricated. A is the general code for Availability/Accessibility loss, which v2.1 refines into two operationally distinct sub-codes: Av for data that is gone or unreachable (deletion, wipers, storage failure), and Ac for data that exists and is reachable but unusable (ransomware encryption, corruption, permission lockout). Per the v2.1 normative rule, DREs are annotations on cluster steps via + [DRE: ...]; they are never standalone path nodes connected by →.
The GDPR mapping is exact:
| GDPR Art. 4(12) verb | Plain reading | DRE code |
|---|---|---|
| "unauthorised disclosure of, or access to" | Attacker reads / exfiltrates data | [DRE: C] |
| "alteration" | Attacker modifies / fabricates data | [DRE: I] |
| "destruction" / "loss" | Data deleted, wiped, irrecoverably gone | [DRE: Av] |
| (not separately named, but covered in practice) | Data exists but unusable (ransomware) | [DRE: Ac] |
Three points fall out of this mapping. First, GDPR's "breach" is the disjunction of all DREs, not any single one. Second, "destruction" and "loss" both map cleanly to Av; the Av/Ac refinement is what lets analysts separate destructive wipers from ransomware-style lockouts, which GDPR's binary "breach / no breach" trigger does not distinguish. Third, the regulatory definition is structurally fine for its own purpose — triggering notification — and structurally inadequate for threat classification or control design. The framework keeps both purposes available by separating them.
§ 4The four DRE decompositions
Each DRE has its own causal patterns. Every TLCTC cluster can in principle produce each DRE — the framework places no artificial restriction on which cluster contributes to which outcome — but in practice some pairings dominate. The decomposition blocks below name the dominant ones.
Data disclosed to an unauthorised party
The default meaning of "data breach" in 80% of usages. The attacker reads or exfiltrates data they were not authorised to access. Disclosure may happen at the moment of cause (SQL injection returning the dump immediately) or with arbitrary delay after the SRE (a foothold today, exfiltration weeks later). Detection windows therefore vary by orders of magnitude.
Dominant cause patterns #2 SQL injection or API enumeration disclosing records · #4 stolen credentials used to query a database · #5 on-path interception of cleartext traffic · #1 privileged-user abuse of designed read capability · #10 compromised SaaS connector reading customer data
Data altered or fabricated without authorisation
The data still exists and is still accessible, but it no longer represents what it should. Often the hardest DRE to detect because the visible system continues to operate normally. Increasingly important in AI training pipelines, financial reconciliation flows, and clinical systems where the data drives downstream decisions.
Dominant cause patterns #1 privileged-user abuse of designed write capability (insider risk) · #4 stolen credentials used to modify records · #2 integrity-bypass via parameter tampering or stored XSS · #10 compromised software updates altering downstream behaviour · #7 malware modifying files in place
Data gone, deleted, wiped, or unreachable
The data no longer exists or cannot be reached at all. Distinguished from [DRE: Ac] by the fact that recovery requires restoration from backup, not decryption. Destructive wipers (NotPetya, Shamoon family) and DoS-driven unavailability both sit here.
Dominant cause patterns #7 destructive wiper malware · #6 volumetric DoS rendering data unreachable · #1 abuse of designed delete capability · #8 physical destruction of storage hardware · #4 stolen privileged credentials used to delete
Data present and reachable, but unusable
The data is still there on disk and the system can still read the bytes, but the bytes are no longer in a usable form. Ransomware encryption is the canonical case. Distinguished from [DRE: Av] because the recovery path is different — decryption keys or rollback, not restoration from offline backup.
Dominant cause patterns #7 ransomware encryption payload · #1 abuse of designed permission/ACL capability to lock out · #2 exploit causing data corruption (rare, usually unintentional consequence)
A real-world chain often combines DREs. The contemporary "double extortion" ransomware pattern produces [DRE: C] (exfiltration before encryption) and [DRE: Ac] (encryption of the production data) in the same incident, sometimes separated by hours and sometimes by months. Multiple-DRE notation handles this directly: + [DRE: C, Ac]. The framework's notation is built to express this distinction so that incident reporting and control mapping can reflect it.
§ 5The full chain in action: a credential-based "breach"
The whitepaper's §1.4.3 walks one example of the SRE → DRE → BRE chain for what the press would call a credential-based data breach.
Setting it out in cluster notation makes both the cause-side discipline and the consequence-side decomposition visible at once.
→ on this side is also a detection/intervention window where controls can break the chain.
The press headline for this incident reads: Acme Corp. suffers data breach affecting 4 million customers.
That sentence is operationally fine for public communication, but it hides the four-step cause-side path (with four different control surfaces), the two distinct DREs (each with its own technical impact and recovery procedure), and the five-stage BRE chain (each with its own legal and business obligation). The framework writes down what the press elides. Both representations have their place; the framework just refuses to let the elided version stand in for analytical work.
§ 6Why this matters: one label, many different controls and obligations
A control programme that lists "data breach" as a threat in its risk register makes three classes of mistake at once, and each one costs money in a different way.
First, cause-side under-investment. Without the ten clusters distinguishing the causes that lead to the data outcome, the programme cannot tell whether its [DRE: C] exposure comes mostly from #2 (in which case patch and input-validation discipline matter most), #4 (in which case MFA, conditional access, and credential hygiene matter most), or #1 (in which case least-privilege design and DLP-on-designed-channels matter most). All three feed the same "data breach" bucket. The defensive investments are not interchangeable.
Second, data-layer under-specification. The control programme cannot tell whether its priority is preventing C outcomes (data egress controls, encryption at rest), I outcomes (write-channel monitoring, audit trails, signing), Av outcomes (offline backups, immutable storage), or Ac outcomes (decryption-resistant backup strategies, isolated recovery environments). Each DRE has its own technology stack. A programme that buys "anti-breach" tooling without specifying the DRE buys the wrong stack as often as not.
Third, BRE-layer mis-prioritisation. The regulatory and business obligations differ sharply by DRE. C-class personal-data incidents trigger GDPR Art. 33/34 notifications. Av-class operational disruptions trigger DORA and NIS2 reporting thresholds. Ac-class ransomware cases trigger sectoral guidance and, increasingly, sanctions-regime considerations on ransom payment. I-class incidents in financial reporting trigger Sarbanes-Oxley implications. A programme that prepares one "breach response plan" for all of these is preparing for the wrong incident four times out of four.
This entry brings the framework's normative §6.2 Rule 1 to the fore. The same rule is what drove the construction of Entry 02's SG-4 case against "privilege escalation" as a threat — both terms are effect-side labels promoted into the wrong slot. Entry 03's technique-exclusion argument is the cause-side mirror of this one. Together the four entries cover the SG-4 / §6.2 boundary from every side.
The Bow-Tie chain shown here is also what the TLCTC+ companion framework formalises further — the BRE catalogue and its mapping to NIS2 / DORA / GDPR / Basel reporting triggers is the work that bridges TLCTC's technical taxonomy to regulatory obligations.
§ 7The fix
Keep "data breach" for the contexts where it has legal meaning. GDPR Art. 33 notifications, SEC 8-K filings, DORA major-incident reports, contractual notification clauses — all use the word in defined statutory or contractual senses, and there is no benefit to fighting the term in those settings. When the term appears in those contexts, it is doing legitimate work as a regulatory trigger label.
When the work is threat classification, control design, or analytical reporting on the cause side, write the chain. Name the cluster, name the SRE, attach the DRE annotation, and — if business-layer consequences are in scope — set out the BRE chain. The framework's §6.2 Rule 1 is normative on the cluster side: a cluster MUST NOT be used to classify "data breach" as an outcome label. The notation provides the proper homes for everything the colloquial term collapses: the cluster carries the cause, the DRE carries the data-layer effect, the BRE carries the business-layer effect, and the sequence operator carries the chain that connects them.◆