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
Rejection rate, rework rounds, elapsed time and requests approved but never executed all sit in built in reports. Let us show what they look like with your own data.
Book a Demo →