Bowtie side versus defensive function

Two classifications appear in cyber risk discussions:

• the side of the bowtieAZBowtieA visual model connecting causes, loss of control, barriers and consequences.Select term to see glossary where a barrier acts; and
• the defensive function the capability performs.

They answer different questions. Treating them as the same creates misplaced barriers and weak risk pathsAZRisk pathOne threat-to-consequence route through the bowtie.Select term to see glossary .

Side asks when the barrier acts

A preventive barrierAZPreventive barrierA capability that acts before the top event.Select term to see glossary acts before the top eventAZTop eventThe precise moment control over the hazard is lost.Select term to see glossary . It reduces the chance that the threat causes loss of control.

A recovery barrierAZRecovery barrierA capability that limits harm after the top event.Select term to see glossary acts after the top event but before the stated consequence. It detects, contains, restores or otherwise limits the outcome.

The top event is the dividing line. The same technology can sit on different sides in different scenarios because the timing and stated loss of control differ.

Function asks what the capability does

Functions such as Govern, Identify, Protect, Detect, Respond and Recover describe the nature of a cybersecurity outcome. They do not establish its position on a particular risk path.

For example:

• an access-approval capability is usually preventive when the top event is unauthorized access;
• application allowlisting is Protect-oriented, but it may be a recovery barrier when the top event is already “workstation compromised” and the consequence is malicious code executing in operations;
• backup is Recover-oriented and usually sits on a consequence path;
• monitoring may be preventive for one top event and recovery-oriented for another, depending on whether action occurs before or after control is lost.

Use the path, not the label

Place a barrier by completing one of two sentences:

This capability stops the threat from causing the top event by…

or

After the top event, this capability stops or reduces the consequence by…

If the team cannot complete either sentence, the top event may be vague or the capability may not belong on that path.

Detection needs a response window

An alert is not automatically a recovery barrier. Ask whether the detection is timely, interpreted and connected to an action that changes the scenario before the consequence occurs.

For a fast operational event, an alert reviewed the next morning offers little recovery value. For a slow data-exfiltration scenario, the same detection and response process may be highly effective.

Record the assumed response window. It makes the placement and effectiveness assessment testable.

Common placement errors

• Putting every Protect control on the left, regardless of the top event.
• Calling every right-side control “recovery” without describing the action.
• Crediting logging as a barrier when nobody reviews or responds in time.
• Moving a barrier to make the diagram look balanced.
• Using a consequence such as “loss of availability” as the top event without defining the earlier loss-of-control moment.

A two-axis view

It is often useful to retain both classifications:

The bowtie position explains the causal path. The function mapping helps teams find the related program, framework and owner. Neither replaces the other.