Access Reviews That Catch Permission Drift Before It Becomes an Incident

Every access review I have sat through has the same moment in it. Someone reads out a name, and a permission attached to it, and the room goes quiet. Nobody knows why it is there. Nobody wants to be the person who removes it.

A four-stage timeline showing access granted for a project, the project ending, a team change, and a review fourteen months later where nobody can explain the permission. — Drift is not an event. It is the absence of one.

How it accumulates

Drift does not come from bad decisions. It comes from good decisions that were never revisited. A contractor joins for a migration and needs access to a system. The migration ends. The contractor stays on for something else. The access stays because removing it would mean understanding what depends on it, and nobody has time to find out.

Repeat that across a few hundred people for a few years and the permission set stops describing what anyone does. It describes the history of what they have ever done.

Why reviews struggle to fix it

The usual answer is a quarterly review, and reviews do find things. But they ask the wrong person at the wrong time. A manager approving a list of forty entitlements, none of which they granted, mostly named after internal systems, will approve the list. Not out of negligence — out of the entirely rational judgment that rejecting something they do not understand is more likely to break a colleague’s week than to prevent a breach.

The review is being asked to reconstruct a decision whose context was never recorded. That context existed once, at the moment the access was requested, and it was thrown away.

Keep the reason, not just the grant

If the original request — what it was for, who approved it, what it was expected to last — travels with the grant, the review changes character. It stops being "do you recognise this?" and becomes "this was for the Atlas migration, which closed in March; is it still needed?" Most people can answer the second question in seconds.

Better still is access that never needed the review. A grant with an end date removes itself. A grant tied to the state of the work — an open ticket, an active incident, an unfinished project — ends when the work does. What remains for the review is the small set of permissions that were genuinely meant to be permanent, and that is a list a human can actually think about.

What we would look at first

Pick ten entitlements at random from your largest system and try to find out why each one exists. Not who has it — why. If you cannot answer for more than half of them within an hour, your next review will approve them all, and so will the one after that.

Implementation guide

Build a review that ends with a verified access state

An access review often begins as a spreadsheet: principal, role, owner, approve or revoke. That is useful inventory, but it is not yet governance. A meaningful review also needs to answer why the access exists, which resource it reaches, who can accept the risk, and whether a decision was actually carried out.

Use a closed-loop process

Access review lifecycle

Collect effective access
Ask an accountable reviewer
Apply the decision
Verify and retain evidence

Make the assignment source visible. Direct grants, group-derived grants, role inheritance, tenant-wide memberships and application-side permissions can look similar in a user interface but have different owners and removal paths. If a reviewer selects “revoke” for a group-derived entitlement, the workflow must identify whether to remove the group membership, alter the role, or submit a downstream deprovisioning request.

Capture a reason that survives the review

A grant without a business reason is difficult to validate months later. Record the purpose, sponsor, resource boundary, start date, end date if temporary, and the trigger for review. The exact data model depends on the application, but it should support a human deciding whether the assignment remains necessary.

{
  "assignmentId": "ent_demo_882",
  "principal": "user_demo_204",
  "resource": "tenant:acme/reports:export",
  "source": "group:finance-analysts",
  "businessReason": "Month-end reporting",
  "owner": "finance-manager",
  "expiresAt": "2026-11-30",
  "reviewDecision": "revoke",
  "executionStatus": "pending"
}

This is a sample review record, not a product API schema. Notice the separation between the reviewer’s decision and the execution status. A review process is not complete just because the decision was submitted.

Operational checklist

Before closing a review cycle

✓Every in-scope assignment has an identifiable owner or documented exception path.
✓Reviewers can see resource, assignment source, business reason and last meaningful activity where available.
✓Approvals and revocations are recorded with actor, timestamp, rationale and target.
✓Downstream changes are executed, retried or escalated when the target system is unavailable.
✓Exceptions have an owner, scope, expiry or review date, and compensating controls where needed.
✓A sample of “revoked” entries is checked against effective permissions, not just the ticket status.

Make cadence risk-based

Not every permission needs the same review frequency. Platform administrator roles, access to sensitive exports, production secrets and cross-tenant administration usually deserve more scrutiny than low-impact read access. The cadence should come from the risk, applicable obligations and evidence of how the access is used—not an arbitrary calendar copied from another organisation.

WebFrolic documents access request, review and approval workflows alongside groups, roles, entitlements and audit capabilities. A technical evaluation should verify that a decision can be traced through the actual enforcement point and into the target system.