How to run a user access review: process, cadence, and evidence

what a user access review is

A user access review is a time-bound process where the people responsible for a system or dataset confirm that each account with access to it should still have it. For every account in scope, the reviewer makes one of three decisions: confirm, modify, or revoke.

The review is not a one-time exercise. It runs on a defined cycle. It produces a written record. And it includes a follow-through step where revocation decisions are actually executed within a defined window.

This is distinct from the joiner-mover-leaver (JML) process, which handles access changes triggered by specific events such as hiring, role change, or departure. A review covers access that the JML process may have missed and access that has drifted over time without a triggering event. The two processes complement each other. Neither replaces the other.

why permissions only accumulate without one

Access is almost always granted in response to a request. Someone needs access to a system. They ask. IT provisions it. That event is typically logged and the request is closed.

Removal does not happen the same way. There is no equivalent request generated when the reason for access ends. The analyst who moved to a different team still has the database access they requested eight months ago. The contractor whose project wrapped in Q1 still appears in the project management tool. The developer with temporary admin rights for a migration still has those rights.

83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). That figure covers the most obvious case. The drift inside active employees' permission sets is harder to measure and, in most environments, never measured at all.

The structural issue is that removing access requires someone to know it should be removed. Role change is one of the primary sources. Someone moves between teams, receives the access their new role requires, and retains everything from their previous role. After two or three role changes, the gap between what someone has and what they need is significant. Access reviews are the mechanism that closes this loop. They create a structured moment for the people who actually know who should have access to apply that knowledge.

what to review

Not every system needs the same review frequency, but every system that holds sensitive data, provides admin capabilities, or touches regulated processes needs to be in scope.

Standard user accounts. The full list of employees and contractors with access to each system. Review focuses on whether the access level is appropriate for the person's current role, and whether the person is still in a role that justifies access at all.

Privileged and admin accounts. Admin rights to infrastructure, cloud consoles, identity providers, and SaaS applications. These carry the highest risk if compromised. They should be reviewed more frequently than standard accounts, and the reviewer population should include senior IT or security ownership.

Service accounts and non-human identities. Technical accounts used by applications, scripts, and integrations. These are consistently underrepresented in access reviews. They often hold broad access granted at setup, they rarely have a named owner, and they do not appear in standard HR-driven reviews because they are not tied to a person. Without a specific inventory and review process for service accounts, they accumulate indefinitely.

External users and contractors. Vendor accounts, consultant logins, partner portals. These are especially prone to outliving their intended duration. The review should confirm that the relationship is still active and that the access level matches the current scope of work.

SaaS application access. Each SaaS application has its own user list, its own role model, and its own admin panel. The central directory handles deprovisioning only for apps connected via SCIM or managed offboarding. Apps outside that scope persist independently. A complete access review covers SaaS, not just the directory.

Shared and generic accounts. Login credentials shared between multiple people. These should be flagged for elimination, not just reviewed, because they make attribution and revocation both impossible.

who owns a review

IT does not run access reviews in isolation. IT coordinates the process, maintains the review schedule, and executes any revocations. The people who make the access decisions are the resource owners.

A resource owner is the person accountable for a system, dataset, or application. They know who actually uses it and for what purpose. They are the right person to confirm whether a specific account should exist. IT knows the directory. Resource owners know the teams.

In practice, resource owners are usually team leads, department heads, or application owners. For a CRM, that is the head of sales or a designated sales ops owner. For a data warehouse, it is the head of data or the analytics lead. For a financial system, it is the CFO or controller.

Assigning resource ownership before the review cycle starts is one of the most important steps in building a functional review program. Reviews that route all decisions to IT bypass the people with the knowledge to make those decisions accurately. The result is either rubber-stamping or delays.

cadence: how often to review

There is no single correct answer, but there are defensible starting points.

Quarterly for high-privilege accounts, admin access, access to sensitive or regulated data, and any system where a breach would have significant operational or regulatory consequences.

Half-yearly for standard user access across business applications. This is the most common cadence in mid-market environments and is generally accepted by SOC 2 auditors and ISO 27001 certification bodies.

Annually for low-risk systems with stable, small user populations. This is the minimum for systems that are in scope at all.

Triggered reviews supplement the calendar cycle. A triggered review should happen when a significant role change occurs, when a department is restructured, when a key contractor engagement ends, or when an incident raises questions about access.

The right cadence depends on how quickly your environment changes. A company with high turnover, frequent contractor use, or rapid SaaS adoption will see faster accumulation and should review more frequently.

how to run an access review: step by step

This is the process. Each step has a defined owner and output.

Step 1: Define scope. Produce a list of every system, application, and dataset that requires review in this cycle. For each one, record the resource owner, the review frequency, and the date of the last completed review. This is your review schedule. Without it, access reviews happen ad hoc when someone remembers, not on a cycle. Output: review schedule with system inventory, owner assignments, and cadence.

Step 2: Pull current access state. For each system in scope, export the current user list with roles and permission levels. The export should include account name, account type (human, service, shared), current access level or role, date of last activity where available, and any known departures or role changes since the last review. If you cannot export a user list from a given system, that is a visibility gap to address separately. Output: access export per system.

Step 3: Assign reviewers and communicate. Send each resource owner their system's access list with clear instructions. Specify what decision is required for each account, the deadline for responses, and what happens if no response is received. Treat non-response as an escalation point, not a default approval. Output: review assignments sent, deadline documented.

Step 4: Collect decisions. Reviewers go through their lists and return a decision on each account: confirm (access is appropriate and should remain), modify (access level should be changed, specifying the new level), or revoke (access should be removed entirely). A review cycle that produces zero revocations across all systems is a signal. It may mean the environment is genuinely clean. More often it means reviewers confirmed everything without applying real scrutiny. Output: completed decision sheets from all reviewers.

Step 5: Execute changes. All revocations and modifications must be executed within a defined window. Thirty days is a common and defensible maximum, and some frameworks expect faster action for high-risk findings. Execution means the access is actually removed, not added to a backlog. An access review finding that is not acted on is treated by auditors the same as no finding. Output: change log documenting every revocation and modification, with completion timestamps.

Step 6: Document and close. Compile the full record of the review: the date, the systems covered, the reviewer for each system, the decisions made, and the evidence that revocations were completed. Store this in a durable, auditable location. The question an auditor asks is not "do you run access reviews?" but "show me the last review." The record answers that question. Output: completed review record, stored and dated.

evidence and audit trail

Evidence is what converts a review process into something demonstrable. Without it, you ran a review but cannot prove it. A complete audit trail includes the date the review was initiated, the systems covered and the reviewer assigned to each, the timestamped access export used as the basis for review, the decisions returned by each reviewer for each account, evidence that revocations and modifications were executed (change tickets, system screenshots, export comparison, or access management system logs), and the date the review was closed.

The level of documentation expected scales with the framework you are aligning with. SOC 2 Type II auditors typically want to see review records across the audit period, including evidence of execution. ISO 27001 certification requires documented procedures and records of reviews. DORA and NIS2 expect demonstrable access management controls, and access review records serve as direct evidence. If your review process produces decisions but no execution records, you have half the evidence. Auditors regularly find that organizations can show the review happened but cannot show that the revocations were completed.

how access reviews map to SOC 2, ISO 27001, NIS2, and DORA

Access reviews appear across all four major frameworks, though each addresses them differently. The common thread is that they expect evidence of periodic review, not a statement that reviews happen.

SOC 2. The Trust Services Criteria include logical access controls as a core requirement. The relevant criteria (CC6.1, CC6.2, CC6.3) address provisioning, modification, and removal of access. Auditors checking Type II certification will look for evidence that access is reviewed at a defined cadence and that the results are acted on. Reviews that happened but were not documented, or where revocations were not completed, create exceptions.

ISO 27001. Annex A, Control 5.18 of ISO 27001:2022 covers access rights management, including the requirement to review access rights at regular intervals. The control expects that rights are reviewed, adjusted, and revoked when no longer needed. An ISMS certification audit checks for documented procedures and records of completed reviews.

NIS2. NIS2 requires covered entities to implement access control policies as part of their cybersecurity risk management measures (Article 21). This includes ensuring that access to sensitive systems is based on need-to-know and subject to review. Access review records serve as direct evidence.

DORA. DORA's ICT security requirements for financial entities (Article 9) include access control as a mandatory domain. This extends to periodic review of user access rights, with particular attention to privileged access. Access review records aligned to a defined cadence and covering privileged accounts in detail are the expected deliverable.

All four frameworks expect periodic, documented, actioned reviews. None of them are satisfied by a verbal confirmation that reviews occur.

common failure modes

Most access review programs fail in one of four ways.

Rubber-stamping. Reviewers approve everything without scrutiny. This happens when reviewers receive a long list, have no guidance, face a short deadline, and have no accountability for inaccurate approvals. The fix is smaller reviewer loads, better context per account (last activity, role history), and accountability for the output.

No revocation follow-through. The review identifies accounts to remove, but the removals are not completed, or are completed months later. Partial execution is a common audit exception. The fix is a defined execution window with a named owner and a close record that confirms completion before the review is closed.

Missing systems. The review covers the directory and the main business applications but misses SaaS apps, contractor portals, shared drives, and cloud consoles. This typically happens when the system inventory is incomplete. A review is only as good as its scope.

No evidence. The review happened but the records do not exist, were stored informally, or cannot be located when needed. Decisions made verbally in a meeting, or approvals sent by instant message with no archive, do not constitute audit evidence. The fix is a defined review record format and a durable storage location, established before the review cycle begins.

Annual-only cadence for privileged access. Running an annual review for admin and privileged accounts is below the threshold most frameworks expect. Privileged access changes more quickly and carries more risk. Quarterly or risk-triggered reviews are the defensible minimum for this population.

tooling: what to look for

Access reviews can be run manually, with spreadsheets and email-based approvals. At small scale, this works. As the number of systems, reviewers, and accounts grows, manual processes produce the failure modes described above.

The functional requirements for access review support are consistent across most tools: automated access export from connected systems, reviewer assignment and notification, a structured decision interface rather than a spreadsheet forwarded by email, automated execution of revocations through system integrations, and evidence export that meets audit standards.

Many IdP platforms (Okta, Microsoft Entra, Google Workspace) include basic access certification features. These work for the systems they manage directly, but do not cover unmanaged SaaS, shadow apps, or systems outside SCIM scope. Dedicated IGA tools (SailPoint, Saviynt, Omada and others) offer broader coverage and more structured workflow. They require integration work and are typically adopted as organizations mature beyond what IdP-native features cover. For organizations that have not yet run a formal review cycle, the right starting point is usually a manual process with a defined template, focused on the highest-risk systems. Build the habit and the evidence record before adding tooling complexity.

worked cadence example

This is an example cadence for a company with a mid-size identity environment. Adapt to your systems and risk profile.

Quarterly (January, April, July, October): all IdP admin roles, cloud console root and admin, privileged access to financial and data systems; all service accounts with access to production systems; all external contractor accounts active in the quarter.

Half-yearly (January, July): standard user access across all business applications (CRM, ERP, HR system, project management, collaboration tools); a SaaS inventory check for any applications added outside the SCIM-managed list since the last review.

Annual (January): low-risk tools such as marketing analytics, internal wikis, and read-only reporting tools with minimal sensitive data; an API key inventory of all active keys with access to production systems, flagging long-lived keys for rotation.

Triggered reviews (as events occur): any significant role change, contractor engagement end, incident or suspected unauthorized access, or any system added that is not covered by the quarterly or half-yearly cycle.