Escalation factors are the most misunderstood element of the bowtie method — and the most frequently abused. Used well, they answer the question every auditor eventually asks: "You've listed this barrier. What could stop it working?" Used badly, they turn a clean diagram into a hairball.
This guide defines the concept precisely, shows where escalation factors belong on the diagram, and gives worked examples across safety, security and operational domains.
What an escalation factor is
An escalation factor (also called a degradation factor or defeating factor in some methodologies) is a condition that defeats or degrades a specific barrier. It does not cause the top event. It makes one of your defences against the top event less likely to work.
The distinction from a threat is the whole concept:
- A threat is a pathway to the top event. "Corroded pipework" can release the inventory: threat.
- An escalation factor attacks a barrier, not the top event. "Inspectors can't access pipework behind cladding" doesn't release anything — it degrades the inspection programme barrier: escalation factor.
The practical test: if the condition would still matter with the barrier removed from the diagram, it is a threat. If it only matters because the barrier exists, it is an escalation factor.
Where it sits on the diagram
Escalation factors hang off the barrier they defeat, not on the main threat or consequence line. Most notations draw them below the barrier, connected by a dashed line, so the main left-to-right story stays readable. Each escalation factor can carry its own escalation factor barriers — controls that protect the main barrier.
A classic chain, fully worded:
- Threat: loss of containment during road-tanker transfer
- Barrier: high-level alarm with operator response
- Escalation factor: alarm flooding during upsets means the operator misses the alarm
- Escalation factor barrier: alarm rationalisation programme; alarm-rate KPI reviewed monthly
Notice the escalation factor barrier does not stop the tank overfilling. It keeps the alarm barrier credible.
Worked examples
Process safety. Barrier: pressure relief valve. Escalation factors: blocked relief line after maintenance, valve set pressure drift between test intervals. Escalation factor barriers: locked-open valve register with independent verification; proof-test schedule based on drift history.
Work at height. Barrier: harness and lanyard worn and clipped. Escalation factors: anchor points missing on older structures, harness inspection lapsed. Escalation factor barriers: anchor-point survey and installation programme; pre-use check plus quarterly recorded inspection.
Cyber / ISO 27001. Barrier: multi-factor authentication everywhere. Escalation factors: legacy protocols that bypass MFA, MFA-fatigue push bombing. Escalation factor barriers: legacy protocol blocking at the identity provider; number-matching prompts and rate limiting.
Business continuity. Barrier: immutable off-site backups. Escalation factor: backup jobs failing silently for weeks. Escalation factor barrier: restore test from the immutable copy on a fixed cadence, with failure alerting to a named owner.
The pattern in every domain is the same: escalation factors are where assurance enters the picture. Most escalation factor barriers turn out to be inspections, tests, reviews and competence checks — the keep-alive activities that barrier management exists to run.
The two classic mistakes
1. Promoting every threat into an escalation factor. If your diagram shows "human error" as an escalation factor on eight different barriers, you have stopped analysing and started decorating. Ask the removal test above, and name the specific mechanism: not "human error", but "night-shift handover omits the override status".
2. Chasing completeness. Every barrier on earth can be defeated by something; listing three escalation factors per barrier doubles the size of the diagram while halving its impact. The convention most experienced facilitators use: only record an escalation factor when it is credible, specific, and you intend to manage it — that is, when it will carry at least one escalation factor barrier or a monitoring task. A bowtie workshop that surfaces thirty escalation factors should expect to keep perhaps eight.
Escalation factors and barrier health
A static diagram treats an escalation factor as a permanent caption. In reality, escalation factors are live conditions: the change-freeze that delays patching is active in December and gone in January; the lapsed harness inspection is a fact until someone does it.
This is where living-bowtie software earns its keep: in SolidBowtie, escalation factors hang on their barriers on the canvas (dashed and amber, where they belong), and the assurance activities that answer them carry due dates — when one slips, the barrier's health degrades automatically instead of waiting for the next annual review to notice.
For the wider picture of how escalation factors fit the method — threats, top events, consequences and the rest of the anatomy — see What is the bowtie method?, or compare how bowtie relates to HAZOP and LOPA, where the same "what defeats the safeguard" question appears as conditional modifiers in a LOPA study.