Contents
The fastest way to measure an approval process is not to look at what it approved. It is to look at what it rejected. What shows a control is really working is not what it let through but what it did not. This article is about one question and why it works so well.
A Question Auditors Like
"How many change requests were rejected last quarter? May I see the list?"
The question is one sentence and its answer is a number. Yet that number says more than an hour of process description. Without listening to a single approval flow diagram, it shows directly whether the control filters anything.
In most organisations the answer comes in one of two forms. First: "I do not think so, things generally get approved." Second: "There must be some, but there is no list, I would have to look." Both lead to the same place.
Why Zero Is Not an Achievement
"None of our requests were rejected" sounds like good news the first time you hear it. A disciplined team, quality requests, a smooth process. To an auditor's ear the same sentence lands differently: the control is filtering nothing.
An approval step means something because it can say no. If that possibility never materialises, the step is not a gate but a counter: it lets everyone through and only tallies them. There are three possibilities and they need to be told apart:
- Requests really are good and no rejection is needed. Possible, but then the number of rework rounds should be visible: how many requests were sent back and corrected?
- Rejections happen but are not recorded. This is the most common case.
- The approval has become a formality. The approver does not see what a decision needs, so they approve without reading.
The third possibility is known as approval fatigue, and it is a design flaw rather than a character flaw. If the approver's screen does not carry what a decision needs (the triggered rule, the affected objects, the risk rationale, the rollback plan) then approving without reading is the rational behaviour.
What the Frameworks Say
A rejection record is not a preference; frameworks ask for it explicitly. In the change management area of COBIT 2019 there is an expectation that a system tracks and reports the status of changes, and that this system also documents rejected changes. The word "also" is in the sentence: approved ones are documented anyway, what is additionally required is the rejected ones.
The reasoning is sound. A rejected request is the only direct evidence that the control works. And without a record of the rejection, this question cannot be answered: did a rejected request later reach production by another route?
Three Places a Rejection Disappears
1. In a conversation
This is the most common form. Before a request is formally opened it comes up in a chat window or a corridor, an experienced person says "let us not do it this way" and the matter closes. The control genuinely worked; a bad change did not reach production. But there is no trace anywhere. On audit day the organisation cannot show its own success.
2. In a deleted ticket
A request is opened, discussed and then closed or deleted. In ticketing systems the closure reason is often free text, and "cancelled" and "rejected" land in the same box. They are very different things: a cancellation is the requester's decision, a rejection is the approver's. Once they share a status code, neither can be counted.
3. In a request approved but never executed
This is the most insidious one. A request is approved and then never touched again. Its status stays "approved" and in the statistics it looks like a successful approval. What actually happened is unknown: abandoned, done another way, or simply forgotten? In any system that does not close dead requests with a distinct status, this backlog grows.
What a Rejection Record Should Carry
A "rejected" stamp on its own is not enough. The record should carry these five:
| Field | Why it is needed |
|---|---|
| The rejected text itself | So that the same script arriving later in another request can be noticed. |
| The stated reason | Even as free text, it carries why the decision was made. A rejection without a reason looks like a preference. |
| Who rejected it and in which role | Shows the decision came from an authorised party. |
| The rule set in force that day | So that months later "why was this rejected" is answered with the rule of that day, not today's. |
| The values the request asked for | For a rejected settings change, the requested value has to stay on the record; it was never written to the live record, so it exists nowhere else. |
The Grey Area: The Silent Rejection
To be honest, no system can capture a "let us not do this" said in a corridor. What can be captured is different: making the cost of entering a request so low that opening one becomes easier than having the conversation.
If opening a request takes ten minutes, people talk first and open the request only once they are sure, so the rejection never appears. If opening one takes two minutes, the discussion starts alongside the request and the rejection lands on the record. What raises the recording rate is not a stricter rule but lower friction.
Measure It With Four Numbers
Four numbers summarise the health of your approval process. None of them is the number of approval steps:
- Rejection rate. Requests rejected last quarter over total requests. If it is zero, find out why it is zero.
- Rework rounds. How many requests were sent back, corrected and then approved? If rejections are zero but this number is high, the process is actually working.
- Time from request to execution. Measure the elapsed time rather than the number of steps. When it grows, the work is done through another channel.
- Requests approved but never executed. If this grows, the process works on paper while something else happens in the field.
If you can produce these four numbers today, your process is measurable. If you cannot, everything said about the process is an estimate based on experience. Experience is valuable; it does not stand in for evidence at an audit.
Get to where the four numbers exist
Rejected requests, the time from request to execution and requests approved but not executed sit in built in reports; there is no built in report for rework rounds. Let us show what they look like with your own data.
Book a Demo →Frequently Asked Questions
None of our requests get rejected. Is that not a good sign?
To an auditor's ear that sentence means the control is not filtering anything. There are three possibilities and they need to be told apart: the requests really may be good quality (in which case the number of correction rounds should be visible), rejections may be happening without being recorded (the most common case), or approval may have degenerated into a formality. The third is approval fatigue and it is a design fault: if the approver's screen does not show the triggered rule, the affected objects, the risk justification and the rollback plan, approving without reading is rational behaviour.
Is recording rejected changes mandatory?
In COBIT 2019's change management area, a system that tracks and reports the status of changes is expected, and that system is expected to document rejected changes too. The reasoning is sound: a rejected request is the only direct evidence that the control operates. Without a rejection record this question also cannot be answered: did a rejected request later reach production by another route?
What should a rejection record contain?
A rejected stamp on its own is not enough. The record should carry five things: the rejected text itself (so the same script can be spotted if it arrives in another request), the rejection justification, the person who rejected it and their role, the rule set in force that day (so months later the question is answered against that day's rules rather than today's), and the values requested. For a rejected settings change the requested value is never written to the live record, so it can only be found in the rejection record.
How does a let us not do this said in the corridor get recorded?
No system can capture that directly. What can be captured is different: lowering the cost of entering a request into the system. If opening a request takes ten minutes, people talk first and only open one once they are sure; the rejection is never visible. If it takes two minutes, the discussion starts with the request and the rejection is recorded. What raises the recording rate is lower friction, not stricter rules.
Which numbers measure the health of an approval process?
Four are enough, and none of them is the number of approval steps. Rejection rate: rejected requests over total requests. Correction rounds: how many requests were sent back and approved after being fixed. Time from request to execution: measure the time rather than the step count, because as it grows the work moves to another channel. Number of requests approved but never executed: if this grows, the process works on paper while something else happens in the field.