The 2am Test: Auditing Your Emergency Access

The 2am test is a single question, asked honestly: if a real emergency happened right now, at the worst possible hour, with the people who'd normally handle it half-awake and stressed, would your break-glass process actually work — and would it leave the evidence an auditor, a regulator, or your own post-mortem would need afterward? Most teams have a break-glass policy document. Far fewer have run it end-to-end recently enough to know it still matches reality. This is a runnable checklist to close that gap yourself, before an outage or an audit does it for you.

Why "we have a policy" isn't the same as passing

SOC 2 Type II and similar audits don't evaluate whether a policy document reads well — they evaluate operating effectiveness over an observation window, typically by sampling actual events and tracing each one through the control. A policy that exists on paper but has no evidenced, consistent real use during that window is one of the most common ways break-glass and emergency-access controls fail sampling, and it's entirely avoidable: the gap is usually that nobody actually ran the process, not that the process was badly designed.

The self-audit checklist

Run through these 12 checks against your actual current setup — not the setup you intended to build, the one that's live today. Each one should take a few minutes; the whole checklist is a half-day exercise including any fixes it surfaces.

1. List everyone who can trigger emergency access, right now. Pull the actual list from your system, not from memory or an onboarding doc. Cross-check it against your current team roster — anyone who's left, changed roles, or never should have been added?

2. Confirm the trigger list is smaller than your full admin list. If everyone with admin rights can also trigger break-glass, you don't have an emergency-access control — you have a second name for standing access.

3. Verify approval requires more than one person for anything high-value. Check the actual threshold configured for your most sensitive credential (production database, root cloud account, signing key), not the threshold you remember setting.

4. Confirm the requester cannot also approve their own request. This is the single most common way a "quorum" control turns out to be a single point of failure with extra steps. Test it directly if your tool allows a dry run.

5. Trigger a real (or simulated) request and time how long approval actually takes. If your documented SLA is 15 minutes and the real answer is "however long it takes an approver to notice a Slack ping," you have a gap between policy and practice.

6. Confirm the grant is time-boxed and expires automatically. Manual revocation that depends on someone remembering is not the same control as automatic expiry — check whether your system actually enforces an end time or just recommends one.

7. Pull the audit log for that test event and check what it actually captured. Who triggered it, who approved, what was accessed, when it started, and when it ended should all be present without you having to reconstruct any of it from memory or a separate system.

8. Check whether denied or abandoned requests are logged too. A pattern of failed attempts is itself a signal auditors and your own security team should be able to see — confirm it isn't silently dropped.

9. Ask whether the underlying credential could be read by a single party, including whoever operates the tool. If the answer is yes, you've built quorum approval on top of a single point of failure, and it's worth confirming exactly who that single party is.

10. Confirm the process was reviewed after the last real (non-test) use. A legitimate break-glass event should end with a review — what was accessed, why, and whether the credential should rotate — not just a closed ticket.

11. Check that the runbook still matches the actual system. Renamed services, retired accounts, and expired approver credentials are the quiet, common way a procedure that worked at design time breaks silently by the time it's needed.

12. Confirm this checklist itself is scheduled to run again. A one-time audit is a snapshot; the value here comes from catching drift, which only shows up if you repeat it.

What auditors are actually sampling

If you're specifically preparing for a SOC 2 review, the questions above map closely to what auditors sample under the logical-access Common Criteria — who could trigger access, what approval was obtained, what was reached, and when it ended, checked against real events rather than the written procedure. The full breakdown of what SOC 2 auditors typically expect for break-glass evidence specifically, including the common gaps that come up in reviews, is at SOC 2 break-glass evidence.

Making the evidence automatic

The checklist above is easiest to pass consistently when the evidence is a structural byproduct of the system rather than a manual step. A quorum enforced by a database constraint produces its own approval record every time; a grant that expires on a timer produces its own end-time evidence without anyone remembering to revoke it. Glassbreak's break-glass access management is built around that principle — hardware-bound approver identity, time-boxed grants, and a full exportable audit trail that's a record of what actually happened, not a summary someone wrote afterward. Run the checklist against your current setup first; if it surfaces gaps a policy document can't close on its own, start for free with a single team to see the structural version in practice.