How do you write an ISO 27001 break-glass procedure?

An ISO 27001 break-glass procedure is a documented, restricted, and evidenced process for using emergency-only privileged credentials — and it sits squarely under Annex A control 8.2 (privileged access rights), which requires the allocation and use of privileged access to be restricted and managed. Certification auditors don't expect you to have no emergency access; they expect the opposite: an inventory of exactly which firecall accounts exist, proof that they're vaulted where no single person can quietly take them, defined criteria for when they may be used, an alert the moment they are used, and a written review after every use. This page walks through what auditors actually sample, then gives you a complete procedure template you can adapt today.

Where break-glass sits in ISO 27001:2022

The 2022 revision of Annex A consolidated the old A.9 access-control family. The controls a break-glass procedure now has to satisfy are:

• A 8.2 — Privileged access rights. The core control: privileged access must be allocated on a need-to-use basis, managed through an authorization process, and reviewed. A break-glass account is privileged access with the "need" deferred until an emergency — the authorization and review obligations don't go away, they concentrate.
• A 5.15 / A 5.18 — Access control and access rights. Whoever can release a break-glass credential is effectively part of the access path and must be identified and reviewed like any other access grant.
• A 8.15 — Logging. Use of the emergency path must produce logs that can't be edited by the person using it.
• A 5.24–A 5.27 — Incident management. Planning, assessment, response, and learning from incidents. Real break-glass activations almost always occur inside an incident, so the same evidence gets sampled here too.
• A 5.29 — Information security during disruption. Security controls must be maintained during a disruption — which is precisely when break-glass access is used. An emergency path that abandons approval and logging "because it's an emergency" fails this control by design.

What auditors actually look for

Across certification and surveillance audits, the sampling pattern for firecall procedures is consistent. Expect to evidence all five of these:

1. A documented account inventory. Which emergency credentials exist, for which systems, and who owns keeping each entry current. An undocumented root password in a drawer is the classic nonconformity.
2. Restricted, vaulted storage. Credentials sealed so that no single individual — including IT administrators and the vault operator itself — can retrieve them alone and unobserved.
3. Defined invocation criteria. What qualifies as an emergency, who may invoke, and what the fallback is if the primary approvers are unreachable.
4. Alert-on-use and time-bound access. Retrieval triggers immediate notification to people other than the retriever, and the access is bounded: credentials rotated after use, or the session time-boxed.
5. Post-use review, every time. A short written review of each activation — was it justified, was the procedure followed, what was accessed, was the credential rotated — plus periodic testing when there have been no real activations.

The single most common failure isn't a missing document; it's a gap between the document and reality. A procedure that says "two approvers required" backed by a shared spreadsheet password anyone can open is worse in an audit than a simpler procedure that is actually enforced.

A copy-pasteable break-glass procedure template

Adapt the bracketed fields; delete sections that genuinely don't apply and note why.

# Emergency (Break-Glass) Access Procedure

Document owner: [role]        Version: [x.y]        Last review: [date]
Aligned to: ISO/IEC 27001:2022 A 8.2, A 5.24–A 5.27, A 5.29, A 8.15

## 1. Purpose and scope
This procedure governs the storage, release, use, and review of
emergency-only privileged credentials ("break-glass accounts") for
[organization]. It applies to all credentials listed in Section 2 and to
all personnel who may invoke, approve, or review their use.

## 2. Break-glass account inventory
| ID   | System / scope        | Credential type   | Owner (role) | Last verified |
|------|-----------------------|-------------------|--------------|---------------|
| BG-1 | [cloud root account]  | [password + MFA]  | [role]       | [date]        |
| BG-2 | [domain admin]        | [password]        | [role]       | [date]        |
The owner verifies each entry is current and retrievable every [quarter].

## 3. Storage and access control
- Credentials are stored in [vault], encrypted end-to-end; no vault
  operator or administrator can read them unilaterally.
- Release requires approval by [M] of [N] named approvers (Section 5).
- No individual, including approvers, holds a complete copy outside
  the vault. Printed copies are prohibited / limited to [exception].

## 4. Invocation criteria
Break-glass access MAY be invoked when ALL of the following hold:
- A [Sev-1/critical] condition exists or is reasonably believed imminent;
- The normal access path (SSO/IdP, standard admin accounts) is
  unavailable, insufficient, or itself compromised;
- The invoker is on the authorized invoker list: [roles].
Invocation for convenience (avoiding normal approval latency) is a
policy violation and is reviewed as a security event.

## 5. Quorum / approval
- Release of any BG credential requires [M]-of-[N] approval from:
  [named roles, at least N total].
- Approvers must be reachable out-of-band; the approver list includes
  at least [2] people outside [the on-call team / one office / one
  timezone].
- If quorum cannot be reached within [15 minutes] during a declared
  Sev-1, the fallback is: [documented fallback, e.g. reduced quorum
  with mandatory post-hoc review by security leadership].

## 6. Notification (alert-on-use)
On any release request, approval, and retrieval, notifications are sent
immediately and automatically to: [security team channel, CISO, system
owner] via [channels]. Notification must not be suppressible by the
invoker.

## 7. Use and time-bounding
- Access is limited to the systems and actions required by the
  triggering incident.
- Credentials are rotated within [24 hours] of use; sessions are
  terminated when the incident is resolved or after [max duration],
  whichever is first.

## 8. Post-use review
Within [5 business days] of any activation, [security lead + system
owner] complete a written review covering: justification, procedure
adherence, systems and data accessed, rotation confirmation, and any
follow-up actions. Reviews are retained for [3 years].

## 9. Testing cadence
- Full invocation drill (request → quorum → retrieve → rotate):
  at least [annually].
- Inventory and retrievability verification: [quarterly].
- Re-test after material change: [new system, approver change,
  vault change].

## 10. Review log
| Date | Type (real/drill) | Invoker | Approvers | Systems | Review completed | Rotated |
|------|-------------------|---------|-----------|---------|------------------|---------|
|      |                   |         |           |         |                  |         |

Mapping the template to Glassbreak

Each section of that template corresponds to something the procedure has to enforce, not just describe — and that's the practical case for tooling. Here's how the template maps onto Glassbreak, an end-to-end-encrypted break-glass platform:

• Inventory (§2) — each firecall credential is a vault secret with an owner and audit history, so the inventory is the vault listing itself rather than a spreadsheet that drifts.
• Storage and access control (§3) — secrets are end-to-end encrypted client-side (Shamir secret sharing over an RSA-OAEP-4096 + ML-KEM-1024 hybrid), so neither Glassbreak nor any single administrator can read them; the vault runs on two independent cloud providers with continuous replication, which matters when the emergency is your primary cloud (see designing break-glass that survives a cloud outage).
• Quorum/approval (§5) — M-of-N approval to decrypt is enforced cryptographically, not by policy: below the threshold, the plaintext mathematically doesn't exist. See what is quorum-based secret sharing.
• Notification (§6) — approval requests and releases notify responders over voice, SMS, and email with acknowledgment tracking and escalation tiers, and the invoker can't suppress it.
• Post-use review and log (§§8, 10) — every request, approval, and decryption lands in the audit log, so the review log table fills itself; exportable evidence packs give the auditor the sampled trail directly.
• Testing (§9) — drill scheduling exercises the full request-approve-retrieve path on a cadence, producing test evidence for the years with no real activations.

The same evidence serves neighboring frameworks — see what break-glass evidence SOC 2 auditors expect, the DORA incident reporting checklist, and the NIS2 readiness guide — and if you're preparing for underwriting rather than certification, the cyber-insurance questionnaire guide covers how the same controls answer those questions. Glassbreak itself is not ISO 27001 certified and is not currently pursuing certification; its honest control-by-control alignment position is published at /trust/iso-27001, and plans (Free, Team, Business — priced per responder, recipients free) are on the pricing page.

This page is general guidance on what certification auditors typically expect; it isn't audit or legal advice, and your certification body's interpretation governs your specific audit.