← Concepts & Glossary
Policy, Gates & Enforcement

Break-Glass Workflow

An audited bypass for legitimately urgent situations that would otherwise be blocked.

What is a break-glass workflow?

A break-glass workflow is the deliberate, auditable way for engineers to bypass a policy gate during a genuine emergency — a live incident, a critical customer escalation, a regulatory hotfix — when waiting for normal remediation would be worse than accepting the risk.

The name comes from the red emergency handles on factory floors: you can pull them, but you leave behind a physical record that everyone on the shift will see. A well-designed break-glass is the same idea in software — fast, clearly-marked, always-visible, and never silent.

How it works

A defensible break-glass has four moving parts:

  1. Multi-party approval. The engineer requesting bypass cannot approve their own request. Approval requires at least one — usually two — other named humans from a pre-authorised list (on-call SRE lead, security duty officer).
  2. Time-boxed grant. The bypass is valid for a short, explicit window (30 minutes, 4 hours, 24 hours at most). When it expires, enforcement snaps back automatically — no manual re-tightening required.
  3. Reason capture. The requester writes a one-sentence justification and links an incident ID. This becomes part of the permanent audit record and the post-incident review.
  4. Mandatory incident review. Every break-glass event, even successful ones, triggers a lightweight review within (say) 5 working days. Review is fast, blameless, and asks: "would we change the policy so next time this did not need a bypass?"

Why it matters

Policy gates without a break-glass path get routed around during real incidents — someone disables the gate, forgets to re-enable it, and the control silently becomes theatre. Policy gates with a break-glass path survive contact with production. Engineers trust them because they know the escape hatch exists; security trusts them because every use leaves a record.

Break-glass data is also one of the richest sources of policy feedback you have. A rule that gets broken open three times a month is telling you something useful about itself.

What value it adds

  • Keeps strict policy credible in real incidents

    Engineers do not learn to disable gates permanently because the authorised bypass is always faster and safer.

  • Every bypass is auditable

    Requester, approvers, reason, incident link, and expiry are persisted — a dream for SOC 2 auditors and post-mortem teams.

  • Time-boxing prevents "forgotten" bypasses

    Enforcement snaps back automatically. No one discovers a rule disabled for 18 months during the next audit.

  • Multi-party approval stops unilateral overrides

    A single stressed engineer cannot grant themselves a waiver — the workflow requires a second set of eyes by design.

  • Break-glass telemetry drives policy improvement

    Frequent bypasses on one rule is a signal: either the rule is wrong or the underlying process is broken. Either way, you learn.

How Safeguard uses it

Safeguard ships a first-class break-glass flow on every policy gate: requesters, approver groups, expiry, reason capture, and incident-review triggers are all part of the same record. Break-glass events feed the same audit export that carries normal policy verdicts. See the full guardrails and enforcement use case for the end-to-end flow.

A bypass path that does not undermine the policy.

Strict-by-default enforcement, with an auditable release valve engineers actually use in incidents — not around them.