Reviewing Break-Glass Use
Break-glass without review is an override with paperwork. The review is the control.
Where to find it
Architect Panel → Security:
- Break-Glass Access — the events to review
Architect Panel → Activity:
- Record Read Log — what was read during each event
- Activity Log — anything that was changed
Review every event
Not a sample. Break-glass should be rare enough that reviewing all of it is easy, and if the volume makes that impractical, that is itself the finding — the underlying permissions need fixing.
What to check
- Is the reason specific? "Urgent" and "needed for work" are not reasons.
- Does it correspond to something real? An incident, a call, a request that exists elsewhere.
- Does the record match the reason? An event opened for one purpose that reached an unrelated record is the pattern that matters most.
- Was anything changed? Emergency access is usually read access in spirit; a change made under break-glass deserves a question.
- Who is using it repeatedly? Either their permissions are wrong or their behaviour is.
Cross-check against the read log
The break-glass event says access was opened. The read log says what was actually read. Comparing them is what catches an event opened for one record and used to browse.
This is why forcing read auditing at classified levels is worth doing — without it, the review can only see that access was granted, not what was done with it.
Tell people the review happens
Openly. A control that is known to be reviewed changes behaviour before anybody uses it; a control reviewed in secret only catches people afterwards.
The intent is not to discourage legitimate use — somebody who genuinely needs a record should open break-glass without hesitation. It is to make casual use feel like what it is.
Close the loop with the person
Where a reason is thin, ask. Usually it is a habit of writing terse notes rather than anything improper, and one conversation fixes the quality of every subsequent entry. A review that quietly records concerns without ever raising them improves nothing.
Watch the trend
Rising use means something changed — a reorganisation, a new team, a process that no longer fits the permissions. Falling use to zero can mean the control is working or that people have found another route; it is worth knowing which.
Worked example
A monthly review of eleven events finds ten matching recorded incidents. The eleventh has the reason "checking" and the read log shows four records opened, only one of which relates to anything the person was working on. The conversation establishes it was curiosity about a colleague's case. It becomes a training matter rather than a disciplinary one — and it was found because the review was routine.
Recommendations
- Review every event, monthly at least.
- Compare against the read log, not just the reason.
- Tell people reviews happen.
- Treat repeated use as a permissions problem until proven otherwise.