Most access reviews are rubber stamps, and everyone involved knows it.
A manager sent a list of group names they cannot interpret will approve all of it, because the alternative is guessing. That produces a completed review, an audit artefact, and no change in who can reach what. Making the review mean something is a design problem, not a compliance one.
- Approve-allThe outcome nobody admits to
- Translate itShow consequences, not group names
- Within 24 hoursWhat ADHICS requires on exit
- RecurringA cadence, not a project
Eight design decisions, and the first one is why most reviews fail.
Translate access into consequences the reviewer understands
A line reading FIN-GL-POST-PROD means nothing to a finance manager. The same line described as can post journal entries to the general ledger in the live system is something they can immediately judge, and they will remove people. This single change does more than any platform, and it is the step almost every review skips because producing the translation takes effort and exporting group names does not.
Give it to somebody who actually knows
The reviewer must be someone who knows what the person does day to day, which usually means the line manager rather than IT or a system owner. IT knows what the access is and not whether it is warranted. A system owner knows the system and not the individual. Sending the review to the wrong person is the second most common design error, and it guarantees approval by default.
Review what matters, not everything
A review covering every system and every permission produces fatigue and blanket approval. One covering privileged access, systems holding regulated or financial data, and anything an external party can reach produces genuine decisions. Scope narrowly enough that reviewers read it. An annual review of everything is worth less than a quarterly review of what matters.
Leavers, which is the specific test everyone fails
The recurring review is the safety net. The primary control is removal at exit, and that is where frameworks are explicit: ADHICS V2 requires access to systems, applications, information and secure areas to be revoked within 24 hours of exit or termination. If leaver removal works, the review finds little. If it does not, the review is doing a job that should have been done months earlier.
Movers, which nobody reviews at all
Someone who changes role keeps the old access and gains the new, and this accumulates for years without anybody noticing because nothing triggers a check. Leavers get attention because a process fires. Movers get none. In most organisations we assess, the people with the widest access are the longest-serving, and it is entirely a byproduct of internal promotions.
Privileged access, reviewed separately and more often
Administrative access deserves its own cycle rather than being buried inside a general review. Several frameworks address this directly. CBUAE Article 13 requires restricting the number of privileged users, prohibits sharing privileged accounts, and requires logging, preserving and monitoring privileged activity including peer review of activity logs. Those are testable requirements, not principles.
Measure removals, not completion
The metric almost every organisation reports is the percentage of reviews completed, which measures whether people clicked. The metric that tells you whether the control works is how much access was removed. A review cycle that completes at 100 percent and removes nothing is a rubber stamp with good statistics, and it is worth saying so to whoever receives the report.
Evidence that satisfies whoever asks
External auditors sample access reviews because ISA 315 names managing access to the IT environment as one of its three IT processes. What they need is the review, the reviewer, the date and what changed as a result. Recording the outcome is as important as performing it, and a review that happened but left no artefact is indistinguishable from one that did not.
A review that removes nothing has told you nothing.
This is worth confronting directly, because the failure is invisible in every metric organisations normally report and obvious the moment you ask a different question.
- Ask for the last completed access review and count how many entitlements were removed as a result. If the answer is none or nearly none across a large population, the review did not work. Access genuinely does accumulate, so a real review always finds something. A clean result across hundreds of users means the reviewers approved rather than assessed.
- This is not the reviewers being lazy. They were sent a list of technical group names, given no information about what those permissions allow, no context about what the person actually does, and a deadline. Under those conditions approving everything is the rational response, because the alternative is removing access on a guess and breaking somebody work.
- The fix is on the sending side, not the receiving side. Translate each entitlement into what it lets somebody do, show when it was last used where you can, flag anything that looks anomalous for that role, and pre-populate a recommendation the reviewer can accept or override. Reviewers engage with that. They cannot engage with a list of group names.
- Then measure removals rather than completion. Completion tells you whether people clicked a button. Removals tell you whether the control is doing anything. Reporting completion to a board or an audit committee, while removals sit at zero, is a more misleading statistic than reporting nothing at all.
Four things that separate a working review from a completed one.
We build the translation layer, which is the actual job
Mapping every reviewable entitlement to a plain description of what it lets somebody do. This is unglamorous, it takes real effort, and it is the reason most reviews fail, because exporting group names is easy and translating them is not. Once built it is reusable every cycle, so the cost is front-loaded and the benefit recurs.
We scope down until reviewers will actually read it
A shorter review that gets genuine attention beats a comprehensive one that gets blanket approval, and we will argue for that even when a framework appears to push toward completeness. Privileged access, systems holding regulated or financial data, and anything externally reachable first. The rest can be annual, or sampled, or reasoned about rather than certified line by line.
We report removals, and we say when the answer is zero
If a cycle completes and nothing is removed, we tell you that plainly rather than presenting a completion rate. Access accumulates, so a genuine review across a real population always finds something. A clean sheet means the reviewers approved rather than assessed, and reporting that honestly is more useful than a green dashboard.
We fix leavers and movers first, so the net is mostly empty
A recurring review is a safety net, not the primary control. If removal at exit works and role changes trigger a check, the review should find little, and finding little for the right reason is the goal. Where we find leaver access persisting for months, that is the more urgent problem and we deal with it before designing a review cadence.
Six situations where a real review is required rather than optional.
A company whose external auditor samples access
ISA 315 names managing access to the IT environment as one of its three IT processes, so auditors test it, and they sample individual users rather than reading your policy. What they need is the review, the reviewer, the date and the outcome. A review performed but not recorded is indistinguishable to them from one never performed, which is a frustrating way to earn a finding.
A healthcare entity under ADHICS in Abu Dhabi
Access Control is one of the eleven control domains, and the standard is specific: access must be revoked within 24 hours of exit or termination, and there must be a security administration function with formal procedures for allocating access rights and monitoring use for unusual or unauthorised activity. Shared clinical logins sit awkwardly against all of that and are the recurring finding.
A payment provider or financial firm under CBUAE requirements
Article 13 requires a security administration function and formal access procedures, and sets out ten named controls for privileged and emergency IDs including restricting the number of privileged users, prohibiting shared privileged accounts, and logging and peer-reviewing privileged activity. These are testable items, which makes a designed review considerably easier to evidence than an informal one.
An organisation with long-serving staff and internal promotions
The mover problem in its purest form. People who have been through three roles in eight years hold the union of all three, nobody ever removed anything, and they are frequently the most trusted people in the business, which makes it socially awkward to raise. A designed review handles this impersonally, which is precisely why it works better than a conversation.
A business with high turnover
Hospitality, retail, logistics and construction, where people join and leave constantly and offboarding is often informal. Here the review is doing real work rather than acting as a safety net, and the first cycle usually removes a great deal. The durable fix is leaver process rather than review frequency, but the review is what demonstrates the scale of the problem.
A firm answering client or insurer questions about access control
Questions about how access is granted, reviewed and removed appear on almost every security questionnaire and insurance proposal now. These are answered on documents somebody signs, which makes accuracy more than good practice. A review that exists and removes nothing is difficult to describe honestly, and the honest description is worse than fixing it.
Same activity, three entirely different outcomes.
| Feature | Designed to be answerable | Rubber stamp | No review at all |
|---|---|---|---|
Entitlements described in business terms | Not applicable | ||
Reviewer knows the person and their job | Sometimes | Not applicable | |
Last-used information shown | |||
Scope narrow enough to be read | Not applicable | ||
Access actually removed as a result | Regularly | Almost never | Never |
Privileged access on its own cycle | |||
Movers trigger a check | |||
Management time consumed | Moderate | Moderate | None |
Survives an auditor asking what changed | Awkwardly | ||
Reported metric | Removals | Completion | None |
The same entitlement, presented two ways.
| What is usually sent | What the reviewer can act on | |
|---|---|---|
| FIN-GL-POST-PROD | Can post journal entries to the live general ledger | |
| Domain Admins | Full control of every server, workstation and account | |
| HR-SYS-ALLEMP-RW | Can read and edit records for all employees, including salary | |
| SP-SITE-LEGAL-OWNER | Can manage and share the legal document library externally | |
| AP-VENDOR-MAINT | Can change supplier bank details, the invoice fraud path | |
| Global Reader | Can read everything in the tenant, including all mailboxes | |
| CRM-EXPORT-ALL | Can export the entire customer database to a file | |
| No usage information | Last used 14 months ago | |
| No peer context | Nobody else in this role has this access | |
| No recommendation | Suggested: remove. Accept or override with a reason |
Five steps, and the first cycle is the expensive one.
- 1
Establish what is actually worth reviewing
Privileged access first, then systems holding regulated, personal or financial data, then anything reachable by external parties. We scope down deliberately until the population is small enough that reviewers will read it, because a comprehensive review that gets blanket approval is worse than a narrow one that gets attention.
- 2
Build the translation layer
Every reviewable entitlement mapped to a plain description of what it permits, with last-used information where the system provides it and a note where an entitlement is unusual for that role. This is the substance of the engagement and it is reusable, so it is built once and maintained rather than recreated each cycle.
- 3
Fix leavers and movers before the first cycle
Check the last several leavers against removal dates, and establish whether anything triggers a review when somebody changes role. If leaver access is persisting, that is more urgent than any review design, and running a review over a population full of former employees wastes the reviewers first impression of the process.
- 4
Run the first cycle with support
Reviewers get a short briefing, a pre-populated recommendation they can accept or override with a reason, and someone available to answer questions during the window. Then removals are actioned promptly, because nothing teaches reviewers to disengage faster than marking access for removal and seeing it still there next quarter.
- 5
Set the cadence and report removals
Privileged access more frequently than general access, with the frequency set by risk rather than by convention. Reporting to leadership leads with entitlements removed rather than reviews completed, and where a cycle removes nothing we say so and look at why rather than presenting it as a clean result.
What organisations ask about access reviews.
Fifteen questions about the last access review you ran.
Was the last one real
- How many entitlements were removed as a result?The only question that matters. Zero means it did not work.
- How long did reviewers spend on it, on average?If it was minutes for hundreds of lines, it was not read.
- Did any reviewer ask a question during it?Silence across a whole cycle is a signal, not a success.
- Were reviewers shown what each permission actually allows?Or a list of technical group names.
- Can you produce the reviewer, date and outcome for each item?What an external auditor will sample.
Design of the next one
- Is the reviewer someone who knows what the person does?Usually the line manager, not IT or a system owner.
- Is the scope narrow enough that people will read it?Privileged, regulated and externally reachable access first.
- Can you show last-used dates for entitlements?The single most useful field a reviewer can be given.
- Do you pre-populate a recommendation to accept or override?Turns an open question into a decision.
- Does anything actually happen when access is marked for removal?Reviews that produce no action teach reviewers not to bother.
The surrounding process
- Is leaver access removed within 24 hours of exit?What ADHICS requires. Check your last ten leavers.
- Does anything trigger a check when somebody changes role?Movers are the accumulation nobody reviews.
- Is privileged access on a separate, more frequent cycle?It should not be buried in a general review.
- Are shared privileged accounts eliminated?CBUAE Article 13 prohibits sharing them outright.
- Do you report removals to leadership, or completion?Completion is the more misleading of the two.
The pages around this one.
Active Directory security audit
The one-off assessment of the directory itself, including privilege escalation paths and the service accounts a recurring review will not catch.
IT general controls
How your external financial auditor tests access under ISA 315, and the evidence they sample per user rather than per policy.
Third party risk audit
Supplier and external access, which needs its own treatment because the reviewer and the removal process are both different.
Take your last access review and count the removals.
That one number tells you whether you have a control or an artefact, and it costs nothing to find out. If the answer is zero across a large population, the problem is almost certainly what your reviewers were sent rather than who they are.
Related Services
Explore more solutions that work great with this service
Entra ID P1 vs P2
What P2 genuinely adds, and what quietly moved
Entra Conditional Access
The control that decides who reaches your data
Compliance as a Service
Keeping the position true between assessments
Active Directory Audit
Privilege paths, service accounts and local admin passwords
IT General Controls
What your external auditor tests, and the evidence they sample
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
Microsoft 365 Security Audit
Tenant review, and how far back your evidence really goes
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly