Ask a security team when they last reviewed access, and you'll get a date, probably within the quarter. Ask them when they last audited the rules that grant that access, the birthright policies, the automation triggers, the offboarding logic, and you'll usually get a pause. Most organizations review their access constantly and have never once audited the system producing it. That asymmetry has a cost, and it compounds every quarter.
There's a specific kind of diligence that looks like rigor and functions as a treadmill.
The access review program runs like clockwork. Certifications go out on schedule, managers work through their queues, stale access gets flagged and revoked, the reports get signed and filed. The auditors are satisfied. By every visible measure, access is under control.
And every quarter, the same findings come back. The same over-broad role on the same category of hire. The same license nobody in that department uses. The same contractor account, alive months after the engagement ended. The review catches them, corrects them, closes them. Next quarter, they're back.
Nobody asks why, because the answer lives in a place nobody's auditing: the rules.
Reviews Check the Output. Nothing Checks the Generator.
A user access management audit and an access review audit are different exercises, and almost every organization runs only the second.
The review is a zoomed-in check on the access itself: does each person still need what they hold? It's the equivalent of counting the keys in the kitchen drawer and asking whether everyone holding one still lives here. Necessary, genuinely, and mandated by name in SOC 2, ISO 27001, HIPAA, and PCI DSS, which is exactly why it happens on schedule.
The management audit is the big-picture exercise: it evaluates the system that hands out the keys in the first place. The policies, the provisioning rules, the lifecycle triggers, the templates, the logic. Not "does this person have the right access" but "is the machinery that decides who gets what is actually correct."
Management audit
Review audit
Scope
Broad: policies, rules, and workflows
Narrow: evaluating access and past review campaigns
Goal
Ensure the process of managing access is secure and compliant
Ensure the specific access granted is correct and removed when stale
Frequency
Usually annually, or during major system changes
Routine: monthly, quarterly, or semi-annually
The reason the first one almost never happens is structural, not negligence. Reviews are named in frameworks, so they get calendared, staffed, and evidenced. The rules audit is implied by those same frameworks (they all require access to be managed correctly, which presupposes the machinery works) but named by none of them, so it has no calendar, no owner, and no artifact anyone asks for. And rules are invisible infrastructure: they run silently, they log success, and nothing about a wrong rule looks wrong from the outside.
Wrong Access, Granted Correctly
Here's the mechanism that makes this expensive, and it's worth sitting with because it's counterintuitive.
Say a birthright policy for a Sales role includes an application the role shouldn't get, a tool from a workflow the team abandoned two years ago that nobody removed from the template. Every Sales hire since then has received that access. Not through error, not through an admin's bad judgment, not through anything a control would flag. Through the rule, working perfectly. Wrong access, granted correctly, per policy, at scale.
Now watch what the review program does with this. The quarterly certification flags the access, a manager confirms it's unnecessary, it gets revoked, the finding closes. Rigorous. Then the next hire joins, the rule fires, and the access is back. The review will catch it again next cycle, and the one after, indefinitely, because reviews evaluate the access, not the rule that produced it.
The review program isn't failing here. It's succeeding, endlessly, at correcting the output of a defect it structurally cannot see. That's the treadmill: a checking process compensating forever for a generating process nobody examines.
The Tell Is Already in Your Review History
The diagnostic for this is sitting in data you already have.
Pull your access review history and look for findings of the same shape recurring across cycles: the same license, the same over-broad role, the same population, flagged and corrected repeatedly, traceable to the same onboarding rule or template each time. Most teams read a recurring finding as evidence the organization is sloppy, or that the review needs to be stricter.
It means neither. A recurring finding of the same shape is the single clearest signal that your review control is working and your rules are broken. The review keeps catching it because the rule keeps generating it. Stricter reviews will catch it faster; only a rules audit will make it stop.
What Auditing the System Actually Looks Like
If the review asks "is this access right," the management audit asks a different set of questions, aimed at the machinery. In practice it means examining things like:
Whether the rule inventory itself is clean: every active provisioning and deprovisioning rule accounted for, no rule running that nobody remembers building, no rule silently depending on a template that was never finished.
Whether trigger conditions still match the organization that exists today, because a rule scoped to a department that has since split doesn't announce it's gone stale; it just quietly stops applying to the population it was built for.
What each provisioning template actually grants, opens and reads action by action, against what the role actually uses now, which is precisely where the drifted birthright policy hides, because a template's name tells you nothing about whether its contents are still right.
Whether mover rules remove as well as add, since a transfer rule that only ever grants is half a rule, and the missing half is the one that prevents accumulation. It fires, it logs success, and it produces sprawl one role change at a time.
Whether offboarding coverage extends past employees, because contractors and external users rarely have a termination event syncing from anywhere, and a rule set covering only employees means an entire category of departures never triggers deprovisioning at all.
And whether any of it has actually been executed, because a rule can be configured perfectly and has been failing silently for months, producing exactly the same outcome as no rule, with the added danger that everyone believes it's working.
The full step-by-step process, rule inventory through execution evidence, is its own discipline, and the point here isn't the checklist. It's the shift in the unit of examination: from the grant to the rule that generated it, because a wrong rule corrected at the grant level regenerates the same wrong grants with every hire.
One honest scope note: this audit works on the known rules governing the known estate. Applications adopted entirely outside IT sit outside every rule by definition; that's a discovery problem upstream of this audit. What this audit catches is the complementary and at least equally common failure: rules that exist, run, and are wrong.
Two Audits, One Loop
None of this argues for fewer reviews. It argues for closing a loop that's currently open on one side.
Reviews are the checking side: they catch drift, they produce the evidence frameworks demand, and, run properly, they generate the exact signal (recurring findings) that tells you where the rules are broken. The management audit is what acts on that signal: it fixes the rule, so the review stops re-litigating the same defect and starts catching genuinely new drift, which is what it was built for.
The cadence follows from the nature of each. Reviews recur routinely, monthly, quarterly, semi-annually, because access drifts continuously. The management audit runs annually, or when the organization changes shape: a reorganization, a new HRMS, a major shift in the application portfolio, because rules go stale exactly as fast as the organization changes around them, and no faster.
The organizations that run both stop finding the same things twice. The organizations that run only reviews get very, very good at correcting the same mistake forever.
Where Zluri Fits
The practical barrier to auditing the rules has always been that, in most environments, the rules aren't visible objects anywhere: they're tribal knowledge spread across admin consoles, scripts, and the memory of whoever set things up.
Zluri removes that barrier structurally. Every automation rule sits in one table with its status, run history, and metadata; every playbook's grants are readable action by action; peer group usage data provides the honest benchmark for whether a birthright rule matches what a role actually uses; and run logs separate configured-correctly from actually-working-correctly over any lookback period. Access Reviews run in the same IGA product, so the recurring-finding signal and the rule it points at live in one system, and fixing the rule is an edit with a run log confirming it held, not a memo hoping admins behave differently. Per KuppingerCole's analysis, Zluri's automated access reviews cut audit preparation from months to weeks, and the rules audit on top of it becomes reading screens instead of conducting archaeology.
Frequently Asked Questions
Is a user access management audit the same thing as running an access review?
No. An access review evaluates whether specific, currently granted access is still appropriate. A management audit evaluates the rules, workflows, and controls that generate that access in the first place, including whether the review process itself is actually running as designed. They're complementary, and they nest: the management audit tests, among other things, whether the review control works.
How often should the management audit happen?
Typically annually, or triggered by a major change: a reorganization, a new HRMS, a significant shift in the application portfolio. Rules go stale exactly as fast as the organization changes around them, so structural change matters more than the calendar. Reviews run on their own, much more frequent cadence.
What's the clearest sign that a rule, not an individual grant, is the actual problem?
Recurring access review findings of the same shape: the same category of excess access flagged and corrected repeatedly across cycles, tied back to the same underlying rule or template each time. That pattern means the review is working correctly and the rule generating the problem has never been fixed at its source.
Does this audit cover shadow IT?
No, by definition. It examines the rules that grant and revoke access, and applications adopted entirely outside IT sit outside every rule. Shadow IT is a discovery problem that lives upstream of this audit. What this audit catches is the complementary failure: rules that exist, run, and are wrong.
.svg)
