Bowtie methodology · 30 terms

The language of bowtie risk analysis.

Plain-language definitions for the established bowtie method, extended with the barrier, risk, architecture and quantitative concepts used to apply it in cybersecurity.

B

Barrier

An independent capability that interrupts a specific risk path.

A barrier either prevents a threat from causing the top event or limits a consequence after control has been lost. A useful barrier is specific, assessable and sufficiently independent from the other barriers credited on the same path.

Read: Barriers are capabilities, not framework controls

Barrier effectiveness

The estimated chance that a barrier interrupts its stated path.

Effectiveness is path-specific and depends on what a capability could withstand and how reliably it is implemented and operated. It is an assessment for comparison and challenge, not a guarantee that the barrier will work.

Read: How the risk numbers work

Bowtie

A visual model connecting causes, loss of control, barriers and consequences.

A bowtie places a central loss-of-control event between its possible causes and outcomes. Preventive barriers appear before that event and recovery barriers afterwards, making the complete risk story visible in one model.

Read: Reading a bowtie

C

Chained bowtie

A bowtie whose outcome feeds a risk path in another bowtie.

A chain connects a consequence or pivot in one model to a threat in another. It helps teams represent risk propagation across systems without forcing an entire multi-system scenario into one unreadable diagram.

Read: Chained bowties and the portfolio

Conduit

A communication path connecting zones through a less-trusted environment.

In an architecture view, a conduit represents a communication channel whose exposure can introduce distinct threats. It is more than a line between neighbouring components: it records a meaningful trust crossing or external path.

Read: Zones, conduits and the Purdue model

Consequence

A concrete operational or business outcome after control is lost.

Consequences sit on the right of the bowtie. They describe harm that matters to a risk owner—such as unsafe operation, service interruption or loss of trustworthy data—not the threat or top event itself.

Read: Reading a bowtie

E

Escalation factor

A persistent condition that weakens a specific barrier.

An escalation factor belongs beneath the barrier it degrades. In cybersecurity it may be a technical or organizational weakness, but routine short-lived findings should normally remain in operational vulnerability management.

Read: Escalation factors (vulnerabilities)

F

FAIR

Factor Analysis of Information Risk, a quantitative cyber-risk model.

FAIR expresses risk through the frequency and magnitude of loss. Cyberkit uses a FAIR-informed optional layer to combine bowtie path frequency with ranges of financial loss without treating uncertain estimates as accounting facts.

Read: Quantitative risk (FAIR-informed)

Framework control

A requirement or expected outcome in a control catalogue or framework.

Framework controls help organizations implement and assure security. They do not automatically become bowtie barriers: several control requirements may support one real-world capability that interrupts a particular path.

Read: Barriers are capabilities, not framework controls

H

Hazard

Something valuable or necessary that must remain under control.

In a cyber bowtie, the hazard is commonly a supporting asset together with the function the organization needs from it. Harm becomes possible when control over that asset or function is lost.

Read: Reading a bowtie

I

Inherent strength

What a barrier could withstand when functioning as designed.

Inherent strength describes technical capability under intended conditions. It is assessed separately from maturity, which describes how consistently the organization implements, governs and tests that capability.

Read: Maturity: the honest half of effectiveness

L

LOPA

Layers of Protection Analysis: risk reduction through independent layers.

LOPA estimates how independent protection layers reduce the likelihood of a path. Cyberkit uses a LOPA-style calculation in which threat frequency is multiplied by the chance of passing each credited barrier.

Read: How the risk numbers work

M

Maturity

How consistently a capability is implemented, governed and tested.

Maturity describes the real operational condition of a measure rather than its theoretical design. A technically strong capability may still be an unreliable barrier when ownership, process, testing or evidence is weak.

Read: Maturity: the honest half of effectiveness

Measure

A real-world security capability that can support one or more barriers.

Cyberkit stores a measure once at project level and can place it as a barrier on several paths. Its name, maturity, strength, references and escalation factors then remain connected wherever that same capability is used.

Read: Barriers are capabilities, not framework controls

Mitigated risk

The assessed risk after currently credited barriers are applied.

Mitigated risk reflects the present model and the effectiveness assigned to its barriers. It should be compared with tolerable risk and read alongside the assumptions and uncertainty that produced it.

Read: How the risk numbers work

P

Preventive barrier

A capability that acts before the top event.

A preventive barrier reduces the likelihood that a stated threat causes loss of control. Its bowtie position is determined by when it acts in this scenario, not by the framework function or technology category assigned to it.

Read: Bowtie side versus defensive function

Q

Quantitative risk

Risk expressed using numerical frequency and loss estimates.

Quantitative analysis can compare expected exposure and loss ranges, but the result inherits uncertainty from every input. It is most useful for sensitivity and comparison rather than prediction of the next incident.

Read: Quantitative risk (FAIR-informed)

R

Recovery barrier

A capability that limits harm after the top event.

A recovery barrier acts after control has been lost but before the stated consequence occurs. Depending on the scenario, it may detect, contain, restore or otherwise keep the loss of control from becoming harm.

Read: Bowtie side versus defensive function

Reference architecture

A simplified view used to scope systems, interfaces and dependencies.

The reference architecture supports risk scoping; it is not intended to replace an asset inventory or detailed engineering network diagram. It identifies the supporting assets and trust crossings that deserve assessment.

Read: Zones, conduits and the Purdue model

Residual gap

The difference between mitigated risk and the tolerable level.

The residual gap shows whether the currently assessed barriers bring a path within the organization’s acceptance threshold. It points to a decision need; it does not decide whether the remaining risk should be accepted.

Read: How the risk numbers work

Risk matrix

A configured scheme combining likelihood and impact into a risk level.

A risk matrix makes assessments comparable within an organization. Its bands and labels are governance choices, not universal constants, so the methodology owner should record and review the configuration in use.

Read: How the risk numbers work

Risk path

One threat-to-consequence route through the bowtie.

A risk path follows one credible threat through preventive barriers, the top event and recovery barriers to one consequence. Path-level reasoning keeps calculations and improvement choices tied to a specific scenario.

Read: Reading a bowtie

S

Security level

A scale used to describe the inherent strength expected of a capability.

Cyberkit uses security-level information as one input to barrier effectiveness. It describes what a capability could withstand under intended conditions and must still be combined with its assessed maturity.

Read: Maturity: the honest half of effectiveness

Shared measure

One capability reused and kept synchronized across several paths.

A shared measure represents the same real-world capability wherever it appears. Changing its maturity or persistent weaknesses updates every linked placement and reveals improvements with effects beyond one bowtie.

Read: Chained bowties and the portfolio

Supporting asset

A system, location, team or supplier enabling an important function.

Supporting assets give cyber-risk assessments a practical scope. A bowtie can describe how control over one such asset might be lost and how that loss could affect the business or operational process it supports.

Read: Zones, conduits and the Purdue model

T

Threat

A credible direct cause of the top event.

Threats sit on the left of the bowtie and describe how control could be lost. They can include malicious actions, insider behavior, technical or supplier failures, and environmental events.

Read: Reading a bowtie

Threat frequency

An estimate of how often an initiating threat event occurs.

Threat frequency is normally expressed as events per year and should be supported by the best available evidence and rationale. It remains an estimate that must be revisited when exposure or threat conditions change.

Read: How the risk numbers work

Tolerable risk

The acceptance threshold set by the organization.

Tolerable risk expresses the level against which current exposure is evaluated. The software can compare a path with that threshold, but the appropriate risk owner remains responsible for acceptance or further treatment.

Read: How the risk numbers work

Top event

The precise moment control over the hazard is lost.

The top event is the knot of the bowtie. It is neither the initiating cause nor the eventual harm: it describes the changed system state that allows threats on the left to develop into consequences on the right.

Read: Reading a bowtie

Z

Zone

A group of assets that share relevant security conditions.

A zone groups assets with similar threats, consequences, users and security requirements. It is an analytical boundary and is not automatically the same as a subnet or physical location.

Read: Zones, conduits and the Purdue model