Set a published response time that scales with severity and release urgency, measure it, and escalate when it is missed. Fast, honest answers matter more than easy ones: a slow queue teaches teams to skip the process, and a quick rubber stamp teaches them nothing.
Why response time is a security control
If the exception queue takes weeks, engineers find other routes. They disable the check, lower a threshold, or ask a friend to approve. Each of those is worse than a proper exception. Reviewer speed is therefore part of the control's effectiveness.
Choosing targets
These are example shapes, not benchmarks. Pick numbers your team can actually meet, then tighten them.
| Request type | Target shape |
|---|---|
| Release is blocked right now | Same working day |
| Normal request, medium severity | A few working days |
| Complex, needs evidence review | A week, with an interim acknowledgement |
| Renewal with unchanged evidence | Short, mostly a check |
Separate acknowledgement from decision. An immediate "received, owner assigned, decision by Thursday" removes most anxiety.
What slows reviewers down
- Incomplete requests that need three rounds of questions
- No single queue, so requests hide in chat
- Reviewers with no context on the service
- Only one approver, see who approves when the approver is away
- Unclear severity rules, so every request becomes a debate
A good request form fixes half of this. See what to put in a security exception request.
Measuring it
Track time to first response, time to decision and the share of requests decided within target. Look at the distribution, not just the average, because a few stuck items hurt the most. Pair it with quality checks: how many approvals were later reversed, and how many denied requests came back stronger.
Beware Goodhart effects. If reviewers are judged only on speed, they approve faster. Pair response time with a review of a sample of decisions.
Escalation
When a target is missed, the request moves up one level automatically, and the requester sees that. Do not auto-approve on timeout. Silence is not consent, and an auto-approve clock rewards requesters who submit late.
Reduce the volume
Shorten the queue by:
- Pre-approving narrow standard cases, with limits written down
- Auto-closing exceptions when a fix lands
- Giving requesters a checklist so requests arrive complete
- Fixing the recurring causes upstream
A weekly rhythm
A fifteen minute weekly review of open requests, oldest first, usually beats ad hoc pings. Owners attend, reviewers decide, and anything stuck gets a reason recorded.
Safeguard's policies and gates define what blocks a build, and its reachability analysis can narrow the evidence reviewers need to read, which keeps requests shorter and decisions faster.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and prioritised, which is the context a reviewer needs.
Quick check
Should critical requests be reviewed faster?
Usually yes when they block a release, but they also deserve closer scrutiny. Fast does not mean lighter.
Is auto-approval after a timeout acceptable?
No. Escalate instead, so a missed deadline never becomes a yes.
Last reviewed: 19 October 2026.
