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:
- 01
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).
- 02
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.
- 03
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.
- 04
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.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.