IAM TechAlmost every organisation running identity governance can produce a completed certification campaign. Far fewer can point at an entitlement that was removed because of one. The campaign finished, the evidence pack went to the auditor, and the access landscape looks identical to how it looked three months earlier.
When that happens, the instinct is usually to blame the platform or the reviewers. In our experience it is neither. It is that the campaign asked people a question they had no way of answering.
The reviewer cannot answer the question being asked
A line manager receives 400 items to certify. Each one reads something like CN=FIN_GL_POST_02. They do not know what it grants, they cannot tell what would break if they removed it, and they have a day job. The rational response — the one almost everyone makes — is to clear the queue in bulk and move on. Usually that means approving everything. Sometimes, particularly where a reviewer has been told to be diligent, it means rejecting everything instead. Neither is a decision, and the second is the more expensive of the two: access is withdrawn from people who needed it, the service desk absorbs the fallout, and the next campaign arrives with reviewers who have learned that engaging with it causes them trouble.
This is not negligence. It is a design failure. The campaign has transferred a decision requiring application-level knowledge to someone who does not have it, and given them no basis on which to decide.
If a reviewer cannot tell you what an entitlement does, their decision is not a control. It is a signature — and it is no better when they sign it as a rejection.
Three things that actually change the outcome
1. Translate entitlements into business language
Before the first campaign runs, every in-scope entitlement needs a plain description of what it permits, written by the application owner rather than derived from the directory. "Can post journal entries to the general ledger" is reviewable. FIN_GL_POST_02 is not. This is the single highest-value piece of preparation, and it is almost always the step that gets skipped because it is unglamorous and slow.
2. Send the review to whoever can actually judge it
Line-manager review works for broad, role-based access where the manager genuinely knows what their team does. It works poorly for privileged, technical, or cross-functional entitlements. Those belong with the application or data owner. Most failing campaigns route everything to line managers because it is the platform default, not because it reflects who holds the knowledge.
3. Reduce the volume before you increase the frequency
A campaign covering every entitlement quarterly produces bulk decisions in one direction or the other. A campaign covering privileged access, toxic-combination roles, and anything touching regulated data — small enough that someone can actually read it — produces decisions a reviewer could defend if asked. Scope by risk first; expand only once reviewers are engaging with the decisions rather than clearing a queue.
Be careful with revocation rate as a measure. There is no universal figure to aim at, and treating one as a target does more harm than good. A first campaign over a population nobody has reviewed should surface real removals. A mature programme running monthly over that same population will legitimately revoke very little, because the previous cycle already did the work — there a low rate is evidence the control is working, not failing. Rate only means something read against cadence and scope — and a high rate is no safer to read than a low one. A reviewer working through 400 unexplained entitlements and rejecting the lot produces an excellent revocation rate and a week of broken access.
What travels better is behaviour. How long did reviewers spend per decision? Did anyone escalate, or ask what an entitlement actually granted? On a population being certified for the first time, did anything come back at all? A campaign where several thousand items were cleared in one sitting, with no questions and no escalations, is telling you something regardless of the percentage it reports.
What good looks like
A healthy campaign has decisions that vary — some access kept, some removed, some queried — rather than a single answer applied to everything. It has escalations that get resolved rather than expiring, and reviewers who occasionally push back and ask what something is. It takes longer to design and produces more friction in the first cycle. It is also the only version that survives contact with an auditor who asks what changed as a result.
The uncomfortable part is that fixing this is mostly not a platform exercise. Every leading access governance platform will run whatever campaign you configure. The work is in the entitlement descriptions, the ownership model, and the scoping decisions — which is exactly why it tends to be deferred.