← All guides

Foundations · Guide 01

Reading a bowtie

What the diagram shows, how to follow one cyber-risk path, and what to question when a layer looks too reassuring.

Begin reading

A bowtie puts the factors of one risk into a single picture. Its value is not the shape by itself; it is the conversation the shape forces. Causes sit on one side, consequences on the other, and the exact moment control is lost sits between them.

The center: hazard and top event

The hazard is something the organization needs but must keep under control. In cyber risk this is usually a supporting asset and its function: grid monitoring through a SCADA platform, remote maintenance of a water facility, or identity services for an operational team.

The top event is the moment that control is lost, before the negative business outcome occurs. Examples include:

  • unauthorized access to the control environment;
  • loss of integrity of operational commands;
  • loss of availability of a supporting system; or
  • disclosure of information needed for safe operation.

This distinction matters. “Power outage” is usually a consequence, not a top event. “Malicious actor” is a threat source, not a top event. A useful top event describes the change of state at the knot of the bowtie.

The left: how control can be lost

Threats are credible causes of the top event. They may be actions by an external actor, intentional or unintentional insider behavior, or environmental events.

Each line from a threat to the top event is a threat path. Preventive barriers cross that line. Every barrier represents an independent capability that must fail or be bypassed before the threat reaches the top event.

Read a left-hand path as a sentence:

Stolen remote-access credentials could lead to unauthorized access, unless identity verification, access approval and network segmentation stop the path.

The sentence is useful because it exposes vague modelling. If a barrier cannot complete the sentence—“this capability stops this threat by…”—it may be a framework label rather than a real barrier.

The right: how loss of control becomes harm

Consequences are concrete effects on business objectives: an extended service outage, unsafe switching, loss of trustworthy operational data, recovery cost or regulatory exposure.

Recovery barriers sit between the top event and each consequence. They do not prevent control from being lost; they detect, contain, restore or otherwise stop that loss from becoming the stated consequence.

Read a complete path from left to right:

Credential theft passes the preventive layers, unauthorized access is gained, recovery controls fail, and manipulated commands interrupt service.

Every threat can potentially connect to every consequence. These threat–consequence pairs are the individual scenarios used by the risk analysis.

What hangs below a barrier

An escalation factor is a persistent condition that weakens a specific barrier. It hangs below that barrier because the relationship must be explicit. Weak key management may reduce the effectiveness of encrypted communications; an untested recovery plan may reduce the effectiveness of continuity arrangements.

Not every vulnerability belongs in the bowtie. Include one when it measurably changes the barrier and persists long enough to matter to the assessment. A short-lived, routinely patched software finding usually belongs in vulnerability management rather than in an annual risk model.

The visual signals in Cyberkit Bowtie

The application adds analysis without replacing the basic shape:

  • barrier color and labels communicate assessed maturity;
  • security-level badges communicate inherent strength;
  • risk chips summarize calculated threat–consequence paths;
  • shared measures connect the same real-world capability across many paths; and
  • completeness warnings expose unprotected or unassessed paths.

Color is a shortcut, never the only carrier of meaning. Read the labels, the path and the underlying values.

Review the picture together

A bowtie becomes more useful when people with different responsibilities question the same path. The aim is not to approve a finished diagram. It is to discover where experience, assumptions and evidence do not yet agree.

  • System and operations specialists test whether the threats and consequences are credible.
  • Engineers explain how each barrier interrupts the path and where apparently separate layers could fail together.
  • Capability owners show how a barrier is operated, tested and evidenced.
  • Risk owners judge impact, tolerance and which uncertainty could change the decision.
  • Decision-makers assign responsibility and choose which improvement should move forward.

For every credited barrier, identify its owner, the evidence supporting its assessment and how its performance is checked. For every proposed improvement, state which path it should change and what reduction is expected. The result is a reviewable decision record, not merely a workshop diagram.

A quick reading checklist

When reviewing a bowtie, ask:

  1. Is the hazard a valuable function or asset that genuinely needs control?
  2. Is the top event a loss-of-control moment rather than a cause or outcome?
  3. Are threats specific enough to imply different barriers?
  4. Does each barrier describe an independent, testable capability?
  5. Are consequences concrete enough for an owner to assess impact?
  6. Does every consequence have a meaningful recovery path?
  7. Are escalation factors persistent and barrier-specific?
  8. Can the team explain the weakest full path in one sentence?

The finished diagram is not proof that risk is acceptable. It is a structured model of the scenarios, controls and assumptions that the organization must assess and maintain.

Go to the source

Sources and further reading

Apply the method

Want to discuss this in your own risk model?

Keep the details high-level. We can start with scope, terminology and evaluation approach.

Ask about your use case