What break-glass evidence do SOC 2 auditors expect?

SOC 2 auditors typically expect break-glass evidence that answers four questions for every sampled event, not just as a matter of policy: who was authorized to trigger it, what approval (if any) was actually obtained, what system or data was reached, and when the access ended — with logs or records to back each answer, not a description of how the process is supposed to work. This falls mainly under the Common Criteria for logical access (the CC6 series in the AICPA framework), and because SOC 2 Type II measures operating effectiveness over an observation window, a policy that exists on paper but has no evidenced, consistent use during that window is one of the more common ways this control area doesn't hold up to sampling.

Why break-glass gets specific auditor attention

Most access controls are designed to be restrictive by default — the whole point of least-privilege access is that people can't reach things they don't need. A break-glass path is, by design, an exception to that: a way to reach something when the normal restriction would otherwise block a legitimate emergency need. Auditors pay closer attention to exceptions than to the default rule, because an exception path that's poorly controlled undermines the access model built around it. A break-glass account any single administrator can use unilaterally — no approval, no time limit, no distinct logging — is functionally an unrestricted admin backdoor with a reassuring name, and it's a recognizable pattern auditors are trained to probe for.

What auditors typically sample

For a Type II report, auditors don't just review the written procedure; they select a sample of actual events from the observation period (or confirm and test that none occurred, where relevant) and trace each one through the control. For break-glass access, that sampling typically looks for:

• Who triggered it, and whether that person was on the authorized list at the time.
• What approval was obtained, and whether it matches the documented requirement (a single approver, or a quorum, depending on your design).
• What was accessed, scoped narrowly enough to match what the triggering incident actually required.
• When access ended, and whether it was time-bound automatically or required a manual, verifiable revocation step.
• Whether the event was reviewed afterward, even when it was entirely legitimate — a post-use review is itself a control, not an optional extra.

Common gaps auditors flag

A few patterns come up repeatedly in this control area: a break-glass credential that's shared informally (a password in a document rather than a controlled account) with no way to attribute individual use; approval that's documented as required but not actually evidenced for real events; access that's technically revocable but wasn't actually revoked promptly after use; and — the deepest version of the problem — a system where the vendor or a support team could grant or read the credential themselves, which undermines any access-control story built on top of it.

How to build evidence, not just policy

The most durable fix is architectural rather than procedural: design the break-glass path so the evidence is a byproduct of how it works, not a separate logging step someone has to remember. Quorum approval that the system itself enforces (rather than a policy that says "get two approvals") produces its own audit trail. Time-boxed access that expires automatically produces evidence of an end time without anyone remembering to revoke it. For the general design principles this rests on, see break-glass account best practices; the enterprise-specific controls auditors respond well to — quorum approval enforced by a database constraint, hardware-bound approver identity, and an exportable audit trail — are described on the break-glass access management page.

Glassbreak's own SOC 2 posture

It's worth being direct here: Glassbreak has not completed a SOC 2 audit and does not hold a SOC 2 report today. Rather than imply otherwise, the platform publishes its own honest gap assessment against the AICPA Trust Service Criteria — including logical access control status — at /trust/soc-2, alongside the platform's broader cryptographic architecture on the security page. If you're evaluating Glassbreak specifically for a break-glass control that needs to satisfy your own SOC 2 scope, that page is the accurate current status, not this general explainer.

This page describes what SOC 2 auditors typically expect at a general level; it isn't audit or legal advice, and your specific control requirements should be confirmed with your own auditor or compliance counsel.