An Access Review Isn't Complete Until Remediation Is Verified
Your quarterly access review can be 100% complete while leaving the underlying access risk unchanged. Here's why — and what to check instead.
The gap between "completed" and "effective"
NIS2 has pushed a lot of organizations across the EU to ask a simple question: are our access controls compliant?
It's the wrong first question.
The question that actually matters is: do they work?
I encounter the gap between those two questions as one of the most common patterns when assessing Identity Governance maturity — across industries, tenant sizes, and organizational structures. It tends to look almost identical every time.
There's a documented access review policy. The quarterly review happens on schedule. The report says Completed.
Then you check what happened after the review — and the access hasn't moved.
Rights that were flagged for removal are still active. A user who changed roles eight months ago still holds the old entitlements, stacked on top of the new ones. A contractor whose engagement ended is still in the identity system with standing access.
The access review file says Reviewed.
The identity system says something else.
That gap isn't a policy failure. It's a process failure — and it's exactly the kind of gap a properly scoped audit is designed to catch, not the kind documentation alone can hide.
Why "Approve / Deny" is not the finish line
Most access review programs are designed and measured around a single milestone: the decision.
Someone reviews the access list. Someone approves or denies each entitlement. The review is marked complete. The metric that gets reported upward is reviews completed — a workflow-completion number, not a risk-reduction number.
But a decision to remove access is not the same thing as access being removed.
An effective access review has five stages, not two:
Review — the current state of entitlements is examined against actual business need.
Decision — each entitlement is explicitly approved, modified, or flagged for removal.
Remediation — flagged access is actually revoked in the source system, not just logged as a decision.
Verification — someone confirms the removal took effect — that the account no longer has the entitlement, not just that a ticket was closed.
Closure — the review cycle is formally closed only once verification is complete, with an audit trail connecting decision to outcome.
This is where many access review programs break down: meaningful tracking stops after Decision. The workflow tool shows green. The control is not green — it's unverified.
This distinction matters more than it looks. A workflow that reaches "Decision" and stops is not a lesser version of an effective access review. It's a different thing entirely: a documentation exercise that happens to use the same policy and the same tooling as a real control.
If remediation isn't tracked as its own stage — with its own owner and verification — you don't have an effective end-to-end access review control. You have a completed review workflow.
A completed review report alone cannot demonstrate that the control was effective. The effective state of access can — and that's precisely what a rigorous audit, or a rigorous regulator, will ask to see. NIS2 Article 21(2)(f) requires organizations to maintain policies and procedures to assess the effectiveness of their cybersecurity risk-management measures — not merely evidence that a process exists. In Greece, Joint Ministerial Decision 1689/2025 goes further by requiring organizations to actually grant and revoke access rights according to principles such as least privilege, need-to-know, and separation of duties — moving the requirement beyond review documentation and into the effective state of access.
When the access review finds the problem, look one layer deeper
There's a second, less obvious failure pattern worth naming directly.
When a quarterly access review is the mechanism that discovers a former employee still has active access — or that an employee is still carrying entitlements from a role they left months ago — that's usually read as the access review doing its job. It caught the problem.
It did. But that finding is also evidence that a different control already failed.
Standing access for departed users and stale entitlements from role changes are exactly what a functioning Joiner-Mover-Leaver (JML) process is supposed to prevent through timely, event-driven access changes — not catch quarterly, well after the fact.
If your access review is regularly the control that surfaces leaver and mover exposure, your JML process isn't operating as a timely control. It's operating as a periodic one — and in between cycles, you're allowing stale access to persist until a periodic detective control eventually identifies it.
These are two separate governance failures that tend to get diagnosed as one:
Access review without remediation — decisions made, not executed.
JML without timely, event-driven access changes — role and departure events not reflected in access until the next audit cycle catches up.
Treating them as a single "access governance problem" and fixing only the review cadence leaves the second failure completely untouched. Organizations that tighten review frequency without addressing JML timing typically see the same leaver-access findings recur at the next cycle, just with different names attached.
What to measure instead
If your reporting on access governance currently answers "how many reviews were completed this quarter," that number tells you almost nothing about control effectiveness. It's an activity metric, not an outcome metric.
The question worth asking at your next review cycle is different:
Of the access rights we decided to remove, how many were actually removed — and verified as removed?
That ratio is more informative than a completion rate because it measures what actually changed in the environment, rather than only what was decided about it.
A secondary question worth tracking alongside it: how many of this cycle's findings are repeat findings from the prior cycle? A high repeat rate is a strong signal that remediation, not detection, is where the program is breaking down.
The practical takeaway
The weaker version of this argument is "compliance checks the paperwork, security checks reality." It's an easy distinction to reach for — and it undersells what current frameworks actually require.
The more accurate distinction is this: a control is not effective because it exists, was executed, or produced evidence. It's effective when it produces the security outcome it was designed to achieve — and that outcome can be verified. Documented, implemented, and effective are three different states. Weak governance programs often demonstrate the first while assuming the other two.
Before your next audit closes out a review cycle as complete, ask two questions instead of one:
Of the access flagged for removal, what percentage was actually revoked and verified?
How many of those findings are new versus repeat findings from last cycle?
Those two numbers will tell you more about the real state of your identity governance than any policy document or completed-workflow report.
Comments