Logo
TLCTC
Blog / Framework & Concepts

The Cyber Bow-Tie: From One Pivot to Layered Bow-Ties

Seven applications of one shape — from a single pivot to layered bow-ties with typed edges.

BK
Bernhard Kreinz
• • ~16 min read • TLCTC v2.6

One shape carries most of TLCTC's risk logic: a cause side, a pivot, a consequence side. Read it once and you have the bow-tie. Chain it, split it, stack it and type its edges, and the same shape organizes control placement, attack velocity, governance and compliance.

This post brings together what three earlier posts said about the bow-tie — Beyond the Breach (August 2025), The Power of Causality (December 2025) and the bow-tie part of The Two-Layer Framework (October 2025) — and restates it against the TLCTC v2.6 canon. The first two posts now redirect here. It climbs a ladder of seven applications, from the single bow-tie to layered bow-ties with typed edges. Each rung adds one idea to the one below it.

1 The single bow-tie 2 Controls by position 3 The consequence chain 4 A chain of bow-ties 5 Two altitudes 6 Stacked bow-ties 7 Typed edges

1 · The single bow-tie: one pivot, two sides

A risk event is a deviation from a strategic goal. At the IT-strategy level the goal is to operate IT systems securely, and the risk event is the compromise of a system. TLCTC builds its whole cause/outcome separation on that event (core §3.4). The ten clusters sit on the cause side, on the left. Outcomes sit on the consequence side, on the right. Between them is the pivot, the System Risk Event (SRE). The SRE the framework defines is System Compromise — Loss of Control: the behavior, privileges, data, or trust relationships of a system — or of a communication relationship it takes part in — are brought outside what their owner controls, in service of an attacker's objective.

A risk event is a deviation from a strategic goal. IT Goal: "Operate securely" • Risk Event: "Compromise of System" CAUSE SIDE Threat Clusters RISK EVENT / INCIDENT Asset Compromise CONSEQUENCES CONTROL PROTECT IDENTIFY (indirectly) CONTROL DETECT CONTROL RESPOND CONTROL RECOVER Preventive controls affect the likelihood of an event occurring Detective and reactive controls influence the consequences "A control failure is a control risk — it is a deviation from the control objective" GOVERN — Risk Appetite, Responsibilities, Metrics (Cross-cutting)
Figure 1. The mechanics of a risk event. Controls (diamonds) act as barriers between the cause, the event and its consequences: preventive controls change the likelihood, detective and reactive controls the consequences. GOVERN spans the whole.

The shape enforces an order. A cluster step comes before the compromise, the compromise before any data risk event, the data risk event before any business consequence. That order is what keeps outcomes out of the threat register. Axiom III states it as a rule: threats are on the cause side; outcomes and events are not threats.

The ransomware test makes the point concrete. "Ransomware" names no cause. The deployment that encrypts the data is a designed function used to push a payload (#1) followed by the payload's execution (#7); the encryption itself is an outcome recorded on the data, [DRE: Ac] — the data is still there but unusable:

#1  →  #7 + [DRE: Ac]

The reverse also holds: one outcome can come from many causes. Exposed data, [DRE: C], follows from #2 (an SQL injection reading a table), from #5 (interception on the path), or from #9 → #4 → #1 (a phished credential, then its use, then a designed export). Each needs a different control. Classifying by outcome hides exactly that difference.

The Cyber Bow-Tie: ten threat clusters on the cause side, System Risk Events at the centre, Data Risk Events and Business Risk Events on the consequence side Cyber Threat Clusters IT Risk Events Business Risk Events PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT PREVENT Prevent from lateral movement (#1-#10) REACT REACT REACT PREVENT (ONLINE FRAUD/SCAM) #1Abuse of Functions #2Exploiting Server #3Exploiting Client #4Identity Theft #5Man in the Middle #6Flooding Attack #7Malware #8Physical Attack #9Social Engineering #10Supply Chain Attack System Risk Event System Compromise "Loss of Control" Asset: IT system System Risk Event System Compromise Data Risk Event Loss of Confidentiality Data Risk Event Loss of Integrity Data Risk Event Loss of Availability / Accessibility Business Risk Events: Consequences = e.g. Databreach PID Business Risk Events: Consequences = e.g. Money Out Business Risk Events: Consequences = e.g. payment interruption Consequence 1 Consequence 2 Consequence 3 Consequence 1 Consequence 2 Consequence 3 Consequence 1 Consequence 2 Consequence 3
Figure 2. The Cyber Bow-Tie. The ten clusters act on the cause side; the System Risk Event (System Compromise, Loss of Control) is the pivot; Data Risk Events and cascading Business Risk Events sit on the consequence side.

2 · Controls are placed by position, not by outcome

The bow-tie's first practical use is control placement. The application companion puts it in one sentence: controls are placed by their position relative to the central event, not by the outcome they are imagined to prevent (application §7).

  • Preventive controls act on the left. They lower the probability that a cluster step reaches the SRE: input validation against #2, phishing-resistant authentication against #4, application allowlisting against #7. They map to IDENTIFY and PROTECT.
  • Mitigating controls act on the right, after the SRE. They no longer stop the step; they compress the consequence chain — detect the loss of control, contain it, restore. They map to DETECT, RESPOND and RECOVER.
  • GOVERN spans the whole chain: risk appetite, ownership, metrics.

A failed control is not a threat. Axiom V: control failure is control risk — a deviation from the control objective — and the risk itself stays structured as threat → event → consequences.

Crossing the ten clusters with the six CSF functions turns this into a structure you can audit: ten causes × six functions = 60 named control objectives, each realized as a local and an umbrella control (application §8.1). A gap is a named, empty cell. One refinement keeps the matrix honest: safeguards that act at the data layer — encryption at rest, backups, retention, data-loss prevention — do not stop a cluster step. They keep a compromise from becoming a data risk event, so they go into a separate DRE matrix, one row per DRE code, same six columns.

The TLCTC x NIST CSF Control Matrix Ten threat-cluster rows crossed with six NIST CSF function columns, each cell split into a local control bar and an umbrella control bar, with the GOVERN umbrella band highlighted as the cross-cutting integration layer to enterprise risk management. The TLCTC × NIST CSF Control Matrix 10 causes (nouns) × 6 functions (verbs) = 60 named control objectives GOVERN IDENTIFY PROTECT DETECT RESPOND RECOVER #1 Abuse of Functions #2 Exploiting Server #3 Exploiting Client #4 Identity Theft #5 Man in the Middle #6 Flooding Attack #7 Malware #8 Physical Attack #9 Social Engineering #10 Supply Chain Attack Local control — asset / system specific Umbrella control — enterprise-wide / shared GOV-Umbrella — cross-cutting ERM layer Each cell is one control objective: a NIST verb applied to a TLCTC noun — e.g. DETECT × #7 Malware Control coverage becomes falsifiable: a gap is not a worry, it is a named, empty cell
Figure 3. The TLCTC × CSF control matrix. Ten clusters × six functions = 60 control objectives, each realized at two scopes: a local control (upper bar) and an umbrella control (lower bar).

3 · The consequence side is a chain

Unfold the right wing and it becomes a chain of events, each a risk event in its own right:

SRE  →  DRE  →  BRE₁  →  …  →  BREₙ
The consequence chain SRE to DRE to BRE* Diagram showing the threat clusters leading to the System Risk Event, then the Data Risk Event, then a cascade of Business Risk Events — the first of which always hits an enterprise process or function — whose terminal member is designated Business Impact by risk appetite. Every transition carries its own delta-t detection window. Δt Δt Δt Δt ··· Threat Clusters #1–#10 SRE Loss of Control DRE C / I / Av / Ac BRE₁ process / function BREₙ terminal = BI
Figure 4. The consequence chain. Every node is a risk event; the first Business Risk Event hits a process or function, and the organization's risk appetite designates the terminal BRE as its Business Impact.
  • SRE — System Compromise, Loss of Control: the pivot.
  • DRE — a Data Risk Event, recorded as a tag on the step that changed the data: C (disclosed), I with its refinements Ii (incorrect state) and If (misattributed state), and A with Av (unavailable — the data is gone or unreachable) and Ac (inaccessible — present but unusable). A flood removes availability; ransomware encryption removes accessibility. Restoring from backup addresses one, capacity engineering the other.
  • BRE — Business Risk Events. They cascade, and how many there are depends on the organization and the incident. The first one always hits an enterprise process or function — a payment run fails, customer data is published. Compliance and legal events sit on top of it, never first.
  • Business Impact is not a separate event type. It is a role a BRE holds: the organization's risk appetite designates which BRE is terminal. The framework supplies the chain; appetite supplies the cut.

The chain can break at every link: not every SRE leads to a DRE, and not every DRE to a BRE. Under v2.6 each transition is a Δt detection-and-intervention window (core §3.4). Rung 7 refines which of them really carry a duration.

How a single breach topples a business

The deep dive from Beyond the Breach, restated. An attacker phishes a developer's password, logs on with it and, days later, uses designed export functions to take the customer list:

#9 + [DRE: C]  →[Δt=hours]  #4  →[Δt=days]  #1 + [DRE: C]

The first [DRE: C] is the password itself; under Axiom X its acquisition belongs to the cluster that obtained it, here #9. The logon is #4 and carries no DRE — authenticating discloses nothing; it opens a door. The second [DRE: C], on the #1 step, is the customer data. From there the consequence chain runs:

  1. BRE₁ — customer data published (process / function). Control point: dark-web monitoring buys a head start.
  2. BRE₂ — reputation: the press reports it within hours. Control point: rapid, transparent crisis communication.
  3. BRE₃ — compliance: personal data was published, so GDPR Art. 33 starts a 72-hour clock from awareness. Miss it and a binding rule is broken. Control point: a rehearsed notification process with decision rights settled in advance.
  4. BRE₄ — legal: proceedings and claims follow the broken rule. Control point: early counsel, legal hold, a documented decision trail.
  5. BRE₅ — reputation, again, now with the regulator's findings attached.
  6. BRE₆ — financial: customers leave; the damage becomes quantifiable.
  7. BRE₇ — disruption: the business model no longer carries. For this organization BRE₇ is terminal, so it holds the role of Business Impact. A firm with a lower appetite would have drawn the line at BRE₃ or even BRE₁.

The business did not fail because of a single hack. It failed because nothing interrupted the chain that followed.

4 · An attack path is a chain of bow-ties

The left wing unfolds too. v2.6 makes it explicit: every cluster step records its own SRE. A path of n cluster steps is a chain of n pivots, and each one opens its own Δt window. The bow-tie is a structure applied at an SRE, not a claim that an incident has only one. Two corollaries follow from the core (§3.4): only steps that succeeded are classified, and an attempted or blocked step records no SRE — it is evidence about the control that stopped it, not a step of the path.

The first cluster sets the tempo of everything after it. The two classic contrasts:

  • The slow burn. #9 + [DRE: C] →[Δt=hours] #4 →[Δt=days] #1 + [DRE: C]. The SRE at #4 and the exfiltration at #1 are days apart. That gap is the detection window the bow-tie exists to expose.
  • The flash fire. #6 + [DRE: Av]. A flood takes the capacity out of the owner's control and the data out of reach in the same moment; Δt is effectively zero. No detect-and-respond loop is fast enough; prevention has to be architectural.

Δt is a time, so it can be set against the defender's own time. The core groups transitions into four velocity classes (core §7.2):

ClassΔt scalePrimary defense mode
VC-1 Strategicdays → monthslog retention, threat hunting
VC-2 TacticalhoursSIEM alerting, analyst triage
VC-3 Operationalminutesautomation (SOAR/EDR), rapid containment
VC-4 Real-Timeseconds → msarchitecture, rate limits, automatic isolation

The Detection Coverage Score makes the comparison per edge, on distributions rather than means: DCS_d = TTD_P90 / Δt for detection and DCS_c = TTC_P90 / Δt for containment. Below 1.0 the defender acts before the step completes; only DCS_c < 1 actually stops it. The same four-hour detection time is excellent against #4 →[Δt=14d] #1 and useless against #4 →[Δt=10m] #1. A ten-minute transition is VC-3: no amount of analyst headcount closes that gap; only automation or architecture does.

5 · Two altitudes: the dual-layer bow-tie

The same bow-tie exists twice, at two altitudes. Axiom VIII separates a stable Strategic Management Layer (clusters and their generic vulnerabilities) from an Operational Security Layer (specific vulnerabilities, techniques and procedures). On the strategic layer the bow-tie reads in clusters, generic vulnerabilities of asset types and risk appetite. On the operational layer it reads in sub-threats, TTPs, CVEs and the DRE tags of specific assets. The pivot is the same event in both readings.

TLCTC Dual-Layer Bow-Tie Model A bow-tie diagram: the ten threat clusters on the cause side, the System Risk Event as central pivot, and the DRE to BRE consequence chain on the effect side, each split between a strategic and an operational layer. CAUSE EVENT CONSEQUENCES STRATEGIC OPERATIONAL System Risk Event SRE Loss of Control System Compromise Threat Clusters #1–#10 Generic vulnerabilities of asset-types Sub-threats · TTPs · CVEs Specific vulnerabilities of specific assets Risk Appetite & Tolerance designates the terminal BRE as Business Impact (BI) Consequence Chain SRE → DRE → BRE* Loss of C / I / A → business events Axiom VIII — the same cause–event–consequence structure exists on both layers
Figure 5. The dual-layer bow-tie (Axiom VIII). The same pivot read on the strategic layer — clusters, generic vulnerabilities of asset types, risk appetite — and on the operational layer — sub-threats, TTPs, CVEs and the consequence chain of specific assets.

What joins the two layers is strict semantic equivalence: #4 and TLCTC-04.00 mean the same cluster. That is what lets one classification travel intact from the board's risk register to the SOC's detection rule to a developer's backlog. The full treatment — the communication gap, programmer versus coder, KRIs that count near misses, one path for many regulators — stays in The Two-Layer Framework.

6 · Stacked bow-ties: turn it ninety degrees

Turn the bow-tie upright and apply it at every layer. Events are layered and chained: a lost system leads to lost data, lost data to a business-process event, with compliance, legal and financial events on top. Each transition upward is a gate. A System Risk Event escalates only if data is affected; a Data Risk Event escalates only if the business is affected. Root causes act horizontally at each altitude; the chain rises vertically.

Film (3:53): Events Are Layered. The bow-tie turned ninety degrees and applied at every layer: a chain of lost systems leads to lost data, then to a business-process event, with compliance, legal and financial events on top — and every link is a window to break the chain. English captions. More films in the media gallery.
The vertically layered risk-event model Three stacked layers. At the bottom, the System Risk Event layer holds two events: System Failure, which occurs as either a software failure (from a code defect) or a hardware failure (from material wear or environmental conditions), with error in use and abuse of rights modelled on both kinds; and System Compromise, fed by the ten TLCTC clusters: abuse of functions, exploiting server, exploiting client, identity theft, man in the middle, flooding attack, malware, physical attack, social engineering and supply chain attack. Both feed one escalation chain that rises through a gate labelled "only if data is affected" into the Data Risk Event layer, typed as loss of confidentiality, loss of integrity (incorrect), loss of integrity (fraud), loss of availability and loss of accessibility, and then through a second gate labelled "only if the business is affected" into the Business Risk Event layer, whose consequences are financial loss, regulatory consequences, customer harm, reputational impact and further business risk events. BRE Business RISK EVENT LAYER ORG. CONSEQUENCE DRE Data RISK EVENT LAYER C · Ii · If Av · Ac SRE System RISK EVENT LAYER TWO PATHS ONE ALTITUDE TECHNICAL PATH Code Defect Supply Chain Event Error in Use Abuse of Rights Software Failure Material / Wear Environmental Error in Use Abuse of Rights Hardware Failure CYBER-SPECIFIC PATH #1 Abuse of Functions #2 Exploiting Server #3 Exploiting Client #4 Identity Theft #5 Man in the Middle #6 Flooding Attack #7 Malware #8 Physical Attack #9 Social Engineering #10 Supply Chain Attack EACH STEP CARRIES EXACTLY ONE CLUSTER System Failure SYSTEM RISK EVENT (SRE) System Compromise SYSTEM RISK EVENT (SRE) ROOT CAUSES · INFLUENCE Abuse of Rights Error in Use Supply Chain Event Data Risk Event e.g. payment data no longer accessible cause: ransomware encryption DRE TYPES · EVENT → STATE Loss of Confidentiality LoC · [DRE: C] Loss of Integrity LoI · [DRE: I] Incorrect State LoIi · [DRE: Ii] Misattributed State LoIf · [DRE: If] formerly “fraudulent state” Loss of Availability / Accessibility [DRE: A] Unavailable State LoA · [DRE: Av] Inaccessible State LoAc · [DRE: Ac] ROOT CAUSES · INFLUENCE Lack of Skills people Error in Action people Abuse of Position people Supply Chain Event bridge External Event external Business Risk Event e.g. payment service outage e.g. fraudulent payments executed e.g. § notification unmet 72h after awareness § REACHED BY A NORMATIVE EDGE, NOT THROUGH THIS GATE CONSEQUENCES Financial Loss § Regulatory Consequences Customer Harm Reputational Impact Further Business Risk Events ONLY IF DATA IS AFFECTED 0 < Δt · function-related · can be interrupted ONLY IF THE BUSINESS IS AFFECTED 0 < Δt · function-related · can be interrupted ROOT CAUSES ACT HORIZONTALLY RISK EVENTS ESCALATE VERTICALLY ESCALATION IS CONDITIONAL Validated core: the ten TLCTC clusters, bottom right. The rest is the author’s view of the world in August 2026.
Figure 6. The vertically layered risk-event model. System Failure (no attacker) and System Compromise (a cluster behind it) meet at the system altitude; each gate upward opens only if the next layer is affected. Naming note: the second Integrity refinement is the misattributed state (If: provenance or attribution fails; the content may be accurate) since TLCTC v2.5; earlier editions called it the “fraudulent state”. The state is told apart on the record, never by the intent behind it.

Two provenances meet at the system altitude. A System Compromise has one of the ten clusters behind it. A System Failure — a software or hardware failure, a misconfiguration, capacity exhausted without an attacker — has none; it is operational risk and carries no cluster. From the gate upward the two chains are identical, which is why the same data and business controls serve both. A third entry point sits one floor higher: Abuse of Rights. When an entitled person acts inside the grant an accountable grantor conferred, there is no cluster and no SRE (R-SCOPE); the chain starts at the DRE.

7 · Typed edges: what the arrows mean

The top rung asks what kind of link each arrow is. Layered Event Modelling (v1.0, working version) types every edge. A causal edge carries a Δt you can act inside. Detection is an evidential edge: it observes, it does not mitigate. A reporting duty attaches by a normative edge, which has no duration of its own.

One incident across S2, S4 and S5, with typed edges Five lanes over time. In S2, a system compromise of the payment process leads by a causal edge with a positive duration to false payment instructions, a data risk event, and by a second causal edge, which payment screening can interrupt, to funds being transferred, a business risk event. The transfer is classified as an external-fraud loss event by a classificatory edge. In S4, an evidential edge from the data risk event yields an observation: the moment of awareness. From awareness, a causal response process leads to the authority being notified; a bracket marks the 72-hour bound that the norm sets on that process. In S5, the notification duty applies under its scope, and a normative edge without duration links the notification to the duty being fulfilled or violated. S5 · NORMATIVE norms S2 · BRE business S2 · DRE data S2 · SRE system S4 · EPISTEMIC observation Notification duty E.G. GDPR ART. 33 APPLIES UNDER ITS SCOPE · META-LAYER § Duty fulfilled OR VIOLATED Payment process altered COMPROMISE · IN S1 False instructions [DRE: I] · IN S3 Funds transferred SETTLEMENT FINAL Δt₁ > 0 Δt₂ > 0 · BREAKER: PAYMENT SCREENING External fraud LOSS EVENT TYPE EVIDENTIAL OBSERVES, NEVER ACTS Anomaly observed AWARENESS · ta RESPONSE · Δt₃ (CAUSAL) Authority notified ta + Δt₃ ≤ 72 H FROM AWARENESS — A BOUND THE NORM SETS § NORMATIVE · NO Δt TIME CAUSAL Δt > 0 · CAN BE CUT EVIDENTIAL OBSERVES · NEVER ACTS § NORMATIVE UNDER A NORM · NO Δt CLASSIFICATORY UNDER A SCHEME · NO Δt BOUND SET BY A NORM
Figure 7. One incident, typed edges (from Layered Event Modelling v1.0, Fig. 2). Causal edges (red) carry a Δt you can act inside; detection only observes; the reporting duty attaches by a normative edge with no duration of its own, and the 72 hours bound the response from awareness.

The GDPR deadline from rung 3 is the instructive case. The 72 hours look like a Δt on the edge from the data breach to the notification duty. They are not. The duty attaches without any delay; the norm then bounds a separate, causal response process whose clock starts at awareness, not at the breach. Under v2.6, every transition of the consequence chain is treated as a Δt window (core §3.4). The forthcoming TLCTC v2.7, aligned with Layered Event Modelling, restricts Δt to causal transitions and lets a business risk event be reached by a normative edge — that part is v2.7 working text, not yet released canon.

Putting the ladder to work

  1. Map your top three chains. For each, write the path from the first cluster through the DREs to the BRE your appetite treats as terminal.
  2. Mark the control points. For every pivot and every link, name the earliest place the chain can be broken, and whether the control acts on the cluster step (cluster matrix) or on the data (DRE matrix).
  3. Measure Δt, not just detection time. Compare TTD and TTC at the P90 with the attacker's Δt per edge. Where a transition is VC-3 or faster, plan automation or architecture, not headcount.
  4. Wargame by first cluster. A chain that starts with #6 needs a different playbook from one that starts with #9. The DRE tag tells you which recovery capability is on the hook: Ac calls for restore, Av for capacity and resilience.
The bow-tie is one shape read seven ways. At every rung the rule stays the same: causes on the left, consequences on the right, and a pivot in between where control is lost — once per step, at every layer.

References & Notes

  1. TLCTC core paper v2.6 — §3.4 The Cause–Event–Consequence Model (SRE, one per cluster step; consequence chain; Business Impact), §5 The Ten Axioms (III, V, VIII, X), §6 Classification Rules (R-CRED, R-SCOPE), §7.2 attack velocity, velocity classes and DCS.
  2. TLCTC application paper v2.6 — §4 Recording Outcomes in Practice, §7 The Bow-Tie in Governance, §8.1 The TLCTC × CSF Control Matrix, §10 Indicators, §11 Risk Appetite and Business Impact.
  3. Kreinz, B. Layered Event Modelling: Semantic Separation as a Precondition for Explicit Causal Analysis, v1.0 (working version), §6 and Fig. 2. Aligned with the forthcoming TLCTC v2.7.
  4. TLCTC glossary — Cyber Bow-Tie, System Risk Event, Data Risk Event, R-CRED, Abuse of Rights.
  5. Tools — Control Matrix Manager, DRE Matrix.
  6. Related posts — The Two-Layer Framework, Data Breach Is Not One Thing, CIIA-Based BIA, The Consequence Amplifier, No “Hazard” Needed, Propagated Controls.
  7. GDPR, Regulation (EU) 2016/679, Art. 33 (notification within 72 hours of becoming aware).

About this post. Published 16 October 2026. It consolidates and replaces Beyond the Breach: SRE, DRE, and the Business Risk Event Chain (20 August 2025) and The Power of Causality: Why the Bow-Tie Model Transforms Cyber Risk Management (5 December 2025); both URLs redirect here. Their figures and the deep dive are carried over and corrected to v2.6 (SRE per cluster step, DCS on P90, ransomware as #1 → #7 + [DRE: Ac], no DRE on #4). Rungs 5–7 bring in the dual-layer and layered figures that used to sit on the tlctc.net landing page.

TLCTC Framework · v2.6 · CC BY 4.0