Approval That Is Not Theatre
An approval always granted is a delay wearing a control's clothing. Designing one that carries information, and knowing when to skip it.
Analysis
Approval steps are added because they feel like control. Whether they are depends entirely on whether a request is ever declined.
When approval adds value
The approver knows something the system does not — that this person is on leave, that this change is not scheduled, that this system is mid-incident.
The consequence is high enough to justify a second person's attention.
The request is unusual, so the approver has a basis for judgement.
Rarity makes it meaningful. An approver who sees three requests a week reads them; one who sees three an hour does not.
When it does not
Routine work, where the answer is always yes and everyone knows it.
High volume, which guarantees rubber-stamping.
An approver with no context, who cannot distinguish a reasonable request from an unreasonable one.
Out of hours, where the approver is asleep and the work is urgent.
In these cases approval adds delay and a false sense of control, and the false sense is the more damaging part.
The alternative to approval
Automatic grant with strong recording and post-hoc review.
Faster, so people use the sanctioned path.
Auditable, because everything is recorded.
Reviewable, by sampling rather than by universal inspection.
Frequently the better trade for routine privileged work, and it is rarely offered because it sounds weaker.
Designing the request
What system, specifically.
What is being done, in a sentence a reviewer could evaluate.
Why, ideally a ticket reference.
For how long.
Four fields. More produces boilerplate; fewer produces requests nobody can assess.
Pre-fill from the ticket system where integration allows, which removes most of the friction.
Measuring whether it is real
Decline rate. A rate of zero over a year means the step is not a control.
Time to approval, by hour of day.
Proportion approved within a minute, which indicates reflex rather than consideration.
Requests submitted out of hours and what happened to them.
Report the decline rate to whoever mandated the approval. It is the number that determines whether the design should change.
The escalation path
Every approval needs a route when the approver is unavailable, or the control becomes an outage.
A named deputy, not a group inbox.
A time-based escalation to a wider group.
A documented emergency route with post-hoc review, which is the honest version of what will otherwise happen informally.
Reviewing after the fact
Where automatic grant is used, the review is the control.
Sample rather than inspect everything, at a rate matched to the tier.
Review the reason against what the session actually shows, which requires recording.
Look for patterns: the same person requesting unusual access repeatedly, requests clustering outside hours, grants that were never used.
Report what the review found, including nothing, because a review that never reports is not happening.
Pre-authorised change
The integration that removes most of the friction argument.
A request matching an approved change record is auto-approved.
The change already went through review, so a second approval adds nothing.
Scope the grant to the change window and the systems named.
Record the change reference on the session, which gives the later review its context.
Requires the ticketing integration, which is the highest-value join in the whole programme for exactly this reason.
Reviewing the approvers
An approval process depends on the approvers being able to judge, which is worth checking.
Ask a sample of approvers what they check before approving.
Ask what would cause them to decline.
Look at their median time to approve, which indicates whether they read.
Look at the decline rate per approver.
Where an approver has never declined and approves within seconds, the design is wrong rather than the person. Either give them context, or replace the step with automatic grant and post-hoc review.