Why the TLCTC Does Not Need the "Hazard"

If you come from safety engineering — IEC 61508, ISO 12100, occupational health and safety, process safety — you might look at the TLCTC Bow-Tie and immediately ask: Where is the hazard?

It's a fair question. In classical safety Bow-Ties, the hazard is foundational. It's the first thing you identify. Removing it would feel like building a house without a foundation.

And yet, TLCTC deliberately omits it. This isn't an oversight. It's a design decision rooted in the structural differences between safety engineering and cybersecurity — differences that, if ignored, reintroduce exactly the kind of semantic diffusion TLCTC was built to eliminate.

What "Hazard" Means in Safety Engineering

In safety disciplines, a hazard is a passive, inherent condition with the potential to cause harm. A tank of pressurized chlorine gas is a hazard. A cliff edge is a hazard. A high-voltage conductor is a hazard. The hazard exists whether or not anyone interacts with it, whether or not any release mechanism activates. It is a static property of the environment.

The classical safety Bow-Tie then models risk as:

The hazard sits above and to the left of everything else. It's the overarching dangerous condition. The threats are the specific activation mechanisms — the spark near the fuel, the valve failure, the procedural error — that transform the latent hazard into an actual event. Controls are then mapped to either prevent the release mechanisms (left side) or mitigate the consequences (right side).

This model works brilliantly for physical and process safety, because hazards in those domains have a critical structural property: they constrain which threats are relevant. Flammable material can only be activated by ignition-compatible mechanisms. You won't trigger a chemical fire through acoustic vibration. The hazard narrows the threat space, and that narrowing is analytically valuable.

Why the Direct Import Fails in Cyber

In cybersecurity, the natural candidate for a hazard equivalent is the threat actor: the nation-state group, the criminal syndicate, the insider, the hacktivist collective. Like a safety hazard, threat actors are persistent, pre-existing conditions. They exist in the environment whether or not they target your specific organization. They are the background fact that makes your cyber Bow-Tie relevant in the first place.

The structural analogy holds:

So far, so clean. But the analogy breaks at a critical point — and the break is fatal for classification purposes.

The Non-Constraining Nature of Cyber Threat Actors

In safety, the hazard constrains which release mechanisms are physically possible. In cyber, the threat actor does not constrain which clusters apply. Any sufficiently capable actor can employ any of the 10 TLCTC clusters in any combination and any sequence:

• A nation-state APT can execute #9 → #3 → #7 → #4 → #1
• A script kiddie can execute #9 → #3 → #7 → #4 → #1
• An insider can execute #9 → #3 → #7 → #4 → #1

The actor identity doesn't change which clusters are available. All ten generic vulnerabilities exist for all actors. What changes is the velocity, sophistication, and persistence with which clusters are chained together — which is precisely why TLCTC captures actor-relevant information through Attack Velocity (Δt) and Velocity Classes (VC-1 through VC-4) rather than through the cluster taxonomy itself.

In safety terms: it's as if every hazard could be activated by every conceivable release mechanism. At that point, modeling the hazard layer ceases to provide classificatory value. It becomes a universal constant rather than a discriminating variable. And a universal constant, while real, doesn't earn a place in a classification grammar. It has no analytical power.

Four Structural Reasons for the Omission

1. TLCTC Classifies Active Exploitation, Not Passive Conditions

Each of the 10 TLCTC clusters describes what an adversary does to exploit a generic vulnerability. Abusing a function (#1). Exploiting a server-side implementation flaw (#2). Manipulating human psychology (#9). These are active patterns requiring adversarial intent and action.

A "hazard" is passive by definition. Importing the term would either force it to mean something it doesn't mean in safety engineering (breaking cross-disciplinary coherence) or force the clusters to be described as passive conditions (breaking their operational precision). Neither is acceptable.

2. The Generic Vulnerability Already Serves the Structural Role

In the classical safety Bow-Tie, the hazard is the root condition that makes the entire model relevant. In TLCTC, that role is fulfilled by the generic vulnerability — the foundational exploitable condition that defines each cluster.

There is no conceptual gap that "hazard" would fill. Adding it above the generic vulnerabilities creates a redundant abstraction layer — and redundant layers in a taxonomy are not neutral. They are invitations for semantic drift, because people will inevitably debate whether the "hazard" is the vulnerability, the threat actor, the threat action, the asset exposure, or the outcome. That debate is precisely what TLCTC exists to end.

3. The Adversarial / Non-Adversarial Boundary Must Remain Clean

TLCTC's scope is explicitly adversarial cyber threats. The framework is already being extended toward non-adversarial IT risk events — Software Failure and Hardware Failure — which follow the same Bow-Tie methodology but address fundamentally different causal dynamics: bugs, wear-out, environmental damage, configuration errors without adversarial intent.

Those non-adversarial events are conceptually much closer to what safety engineering calls "hazards." A degrading hard drive is a passive dangerous condition. Aging firmware with known bugs is a latent hazard. Earthquake exposure for a data center is an environmental hazard.

If TLCTC used "hazard" for its adversarial threat clusters, the term would already be occupied when the framework extends into the domain where it naturally belongs. The deliberate terminological separation preserves future extensibility and keeps the adversarial/non-adversarial boundary architecturally clean.

4. Axiom V Already Handles the Control Failure Overlap

In some safety frameworks, "hazard" is broad enough to encompass control failures — "the fire suppression system failed" becomes part of the hazard scenario. TLCTC explicitly forbids this:

Axiom V — Control Failure Is Not a Threat
Control failure is control-risk (deviation from a control objective / lack of effectiveness) and must not be treated as a threat category.

Using "hazard" — with its safety-engineering baggage of potentially folding control failures into the causal picture — would create constant pressure to violate Axiom V. Every time someone says "the hazard is that our firewall might fail," they've collapsed control risk into threat classification. TLCTC's terminology is designed to make this category error structurally difficult to commit.

What TLCTC Does Instead

Rather than importing a term from a different discipline and hoping it survives the translation, TLCTC builds its Bow-Tie from concepts native to the cyber domain:

THREAT ACTORS          THREAT CLUSTERS              CENTRAL EVENT        DATA RISK EVENTS
(Background            (Active exploitation         (Loss of Control /   (Loss of C/I/A)
 radiation —            of generic                   System Compromise)
 acknowledged           vulnerabilities —
 but not                classified here)
 classified)
                       ← PREVENTIVE CONTROLS →    ← MITIGATING CONTROLS →

Threat actors are acknowledged (Axiom IV) and characterized through velocity analysis (Δt, VC-1 through VC-4), but they are not a classification axis. They are the background radiation — always present, never zero, but not the thing you classify by.

Generic vulnerabilities provide the structural anchoring that "hazard" would provide in safety engineering, but with two advantages: they directly define the clusters (one-to-one mapping per Axiom VI), and they naturally map to preventive controls without requiring an intermediate translation layer.

Attack Velocity (Δt) captures what actor characterization would capture — capability, automation level, response time pressure — but does so in a measurable, operational way rather than through attribution-dependent profiling.

The Pragmatic Takeaway

If you're a safety engineer encountering TLCTC for the first time, here's the honest mapping:

The absence of "hazard" is not a gap. It's a scar from a design decision — a place where the framework could have imported a familiar term and chose not to, because fidelity to the problem mattered more than familiarity to the reader.

In a field already plagued by terms meaning different things to different people, introducing a word that means something precise in a different discipline would be the opposite of solving the language problem. And solving the language problem is what TLCTC is here to do.