User Access Review: Process, Frequency and Controls

2026-10-03 · Tommaso Maria Ricci

Most breaches do not start with a genius hacker. They start with an account that should not exist anymore, or a permission nobody remembers granting. A user access review is the control that catches both, and it is also the control auditors test first when they look at your IT general controls. Yet in most mid-market companies it is a spreadsheet emailed to managers twice a year, approved in bulk on a Friday afternoon, and filed away until the next audit.

The numbers say that approach is no longer enough. The Verizon 2026 Data Breach Investigations Report, built on more than 22,000 confirmed breaches in 145 countries, found that credential abuse appears at some point in 39% of breaches, and that a third party is involved in 48% of them, up from 30% a year earlier. Every one of those third parties, contractors and service accounts is a line in your access review, or should be.

This guide covers what a user access review is, what each framework actually requires, how often to run it, the step by step process, the roles, the evidence auditors want, the mistakes that make reviews worthless, a scorecard to assess where you stand, and a 90 day plan to fix it. No tool list: the right tool depends on the process, and the process comes first.

What a user access review is (and what it is not)

A user access review is a periodic, documented check that every account in a system belongs to someone who still needs it, with permissions that still match their job. The output is a decision for each account and each permission: keep, modify or revoke. Then the changes are made, and the evidence is kept.

Three things it is not:

It is not provisioning. Provisioning grants access when someone joins or changes role. The review checks, after the fact, that provisioning and deprovisioning worked.
It is not a password audit. Passwords, MFA and session settings are authentication controls. The review is about authorization: who can do what.
It is not a one-time cleanup. A cleanup fixes the current state. A review is a recurring control with an owner, a frequency and evidence.

The review exists because access drifts. People change roles and keep the old permissions. Projects end and temporary access stays. Contractors finish their engagement and their account keeps working. Service accounts get created for an integration and nobody owns them after the engineer who built it leaves. Each of these is small. Together they create the gap that attackers and fraudsters use.

Why it matters beyond security

The review is also a financial control. If a person can create a vendor and approve a payment to that vendor, the problem is not technical, it is segregation of duties. We covered how to build that matrix in our guide to segregation of duties for small teams. The access review is the mechanism that checks, every cycle, that the matrix you designed is the one actually configured in your systems.

What the frameworks actually require

Most companies run access reviews because an auditor, a customer or a certification asks for them. The requirements differ more than people think, and knowing exactly what each one says avoids both under-doing and over-doing the work.

PCI DSS v4.0.1

If you store, process or transmit card data, PCI DSS is the most prescriptive. Requirement 7.2.4 asks that all user accounts and related access privileges, including third-party and vendor accounts, be reviewed at least once every six months, that inappropriate access be addressed, and that management acknowledge the access remains appropriate. Requirement 7.2.5.1 covers application and system accounts, with a frequency set by your own targeted risk analysis. Both became mandatory on March 31, 2025, as the PCI Security Standards Council confirmed when it published v4.0.1 and retired v4.0 at the end of 2024.

The point people miss: service accounts are now explicitly in scope. If your review only covers human users, it does not meet the standard.

NIST SP 800-53 Rev. 5

NIST SP 800-53 is the reference catalog for US federal systems and for many companies that sell to government or follow NIST voluntarily. Control AC-2, Account Management, requires reviewing accounts for compliance with account management requirements at a frequency the organization defines. Enhancement AC-6(7) requires reviewing the privileges assigned to roles or users, again at an organization-defined frequency, and reassigning or removing privileges when needed.

NIST does not set a number. It asks you to set one, justify it and follow it. That is harder than it sounds, because an auditor will test whether you actually ran the review at the frequency you wrote down.

ISO/IEC 27001:2022

In ISO 27001:2022 the relevant control is 5.18, Access rights. As summaries of the control explain, access rights must be reviewed at regular intervals and when someone changes role or leaves. ISO does not prescribe a frequency either. The common practice of quarterly reviews for privileged accounts and annual reviews for everyone else is consultant convention, not ISO text. It is reasonable, but write it in your policy as your choice, based on your risk.

SOC 2

The AICPA Trust Services Criteria behind SOC 2 address logical access in CC6.1 to CC6.3. CC6.2 covers removing credentials when access is no longer authorized; CC6.3 includes periodic review of access roles and rules. For a SaaS company selling to enterprises, the SOC 2 report is often what the customer reads before signing, and the access review is one of the controls most often tested with sample evidence.

SOX and IT general controls

For public companies, and for private companies that want to look like one before an exit, access reviews are a core IT general control under SOX 404. The audit logic is simple: if the wrong people can post journal entries, change vendor bank details or modify the revenue system, the auditor cannot rely on the controls that sit inside those systems. A KPMG analysis of IT controls in financial reporting names late removal of access after people leave or change jobs, and weak administrator access controls, among the causes of material weaknesses.

SOX compliance is not cheap. In the Protiviti 2023 SOX compliance survey, covering fiscal 2022 with 564 respondents, 58% reported that SOX hours increased, and average internal costs were about $1.36 million for large accelerated filers and $651,000 for companies under $500 million in revenue. A clean, repeatable access review is one of the few places where good design cuts that cost every single year.

HIPAA

For healthcare organizations and their business associates, the HIPAA Security Rule at 45 CFR 164.308(a)(4) requires policies to establish, document, review and modify a user's right of access. A proposed update to the Security Rule, published on January 6, 2025, would require terminating a departing workforce member's access within one hour. It is still a proposal, with a final rule targeted for 2027 on the federal agenda, but the direction is clear: regulators expect access to follow people in near real time.

What this means in practice

| Framework | Frequency | Scope that people forget |

|---|---|---|

| PCI DSS v4.0.1 | At least every 6 months | Vendor accounts, application and system accounts |

| NIST SP 800-53 | Organization-defined | Privileges, not only accounts |

| ISO 27001:2022 | Regular intervals and on role change | Movers, not only leavers |

| SOC 2 | Periodic, tested by sample | Evidence of removal, not only approval |

| SOX ITGC | Typically quarterly for financial systems | Admin and database access |

| HIPAA | Periodic, documented | Access to ePHI across all systems |

If you are subject to more than one, design one review that meets the strictest requirement for each system, instead of running parallel reviews for each auditor.

How often to run a user access review

The honest answer is: as often as your risk requires and your process can sustain. A quarterly review done badly is worse than a semi-annual review done well, because it produces evidence that looks fine and controls nothing.

A practical tiering that holds up with most auditors:

Privileged and administrator accounts: quarterly. Domain admins, cloud root and owner roles, database administrators, ERP super users, anyone who can change other people's access.
Financial and regulated systems: quarterly or semi-annually. ERP, payroll, banking portals, payment systems, anything in SOX or PCI scope.
Systems with sensitive personal data: semi-annually. HR, CRM with customer data, medical records, support tools with access to customer accounts.
Everything else: annually. Collaboration tools, project management, low-risk SaaS.
Event-driven reviews: always. Every leaver and every role change triggers an immediate check, independent of the calendar.

The event-driven part is where most risk sits. A quarterly review that finds a leaver who kept access for 80 days is a finding, not a success. The joiner, mover and leaver process is the real first line of defense; the periodic review verifies it. If your leaver process depends on someone remembering to email IT, start there. Our guide to the hire to retire process shows how to give each step an owner and a deadline.

How to run a user access review: the process step by step

This is the process that works for companies with a few dozen to a few thousand employees, with or without a dedicated identity tool.

Step 1. Build the system inventory

You cannot review what you have not listed. Start with every system that holds sensitive data or can move money, and record for each one:

the business owner (the person accountable for the data and the process, not IT);
the technical owner (who administers it);
how users authenticate (single sign-on or local accounts);
the roles and permission levels available;
the risk tier, which drives the review frequency.

Expect surprises. Most companies discover SaaS tools bought on a credit card, local admin accounts on systems that were supposed to be behind single sign-on, and integrations with their own service accounts.

Step 2. Extract access data from the source

Pull the user list and the permissions directly from each system, on a defined date, and keep the raw extract. Do not use a list maintained by hand, and do not let the reviewer edit the extract. Auditors will ask how you know the list is complete and accurate; the answer is a system-generated report, with a timestamp, plus a note of who ran it and how.

Then match every account to an identity from your HR system. This is the step that finds the real problems:

Orphaned accounts: accounts with no matching active employee or contractor.
Generic or shared accounts: "admin", "finance", "test", with no single owner.
Service accounts: used by integrations and scripts, each needing a named human owner.
External accounts: vendors, contractors, consultants, with an end date that should exist.

Step 3. Assign the right reviewer

The reviewer must be able to judge whether the access is needed. Usually that means the person's manager for role-based access, and the system owner for privileged roles. Two rules matter:

Nobody reviews their own access. Sounds obvious; it is broken in many reviews where a department head reviews a list that includes themselves.
IT does not approve business access. IT can tell you an account exists. Only the business can tell you whether that person should be able to approve purchase orders.

Step 4. Give reviewers context, not just names

A list of usernames and cryptic role codes produces rubber-stamping. A reviewer can only make a real decision if they see:

the person's name, job title and department from HR;
the permission in plain language ("can approve payments up to $50,000", not "APAPPRL3");
the last login date;
whether the permission conflicts with another one the same person holds;
whether it was already flagged in a previous review.

Highlight the exceptions: dormant accounts, privileged roles, segregation of duties conflicts, external users. Reviewers should spend their time on the 5% that matter, not scrolling through the 95% that are fine.

Step 5. Decide: keep, modify or revoke

Every line needs an explicit decision. "No response" is not approval. Set a deadline, escalate at the deadline, and define what happens when a reviewer does not respond: in a mature process, unreviewed privileged access is suspended, not kept.

Watch for bulk approval. If a reviewer approves 400 lines in four minutes, the evidence will show it. Some companies require a comment for every privileged access approved, which slows things down exactly where slowing down is useful.

Step 6. Remediate and verify

The review is not complete when the reviewer clicks "revoke". It is complete when the access is actually removed, and someone has verified it with a new extract. This closed loop is what auditors test most often, and where reviews most often fail: the decision was made, the ticket was opened, the ticket sat in a queue for two months.

Set a remediation deadline (for example, five business days for revocations, one business day for privileged access), track it, and re-extract to prove it.

Step 7. Keep the evidence

For each review cycle, keep:

the raw extracts with date and source;
the list of reviewers and what they were asked to review;
every decision with timestamp and reviewer;
the remediation tickets and their closure;
the post-remediation extract showing the change;
exceptions approved by management, with reasons and expiry dates.

How long to keep it depends on your audit and regulatory cycle. If you need a policy for that, our guide on how to write a data retention policy covers the logic.

Roles and responsibilities

A review without clear owners turns into an IT chore nobody prioritizes. This is a split that works:

| Role | Responsibility |

|---|---|

| Control owner (often CFO, CISO or Head of IT) | Owns the policy, frequency and results; signs off each cycle |

| System owner | Defines roles, reviews privileged access, approves exceptions |

| Line manager | Reviews their team's access, decides keep, modify or revoke |

| IT or identity team | Extracts data, runs the campaign, executes revocations |

| HR | Provides the authoritative list of employees, contractors and changes |

| Internal audit or compliance | Tests the control, independently, on a sample |

The most important line is HR. Every access review depends on a reliable source of truth about who works here, in what role, and since when. If HR data is late or incomplete, the review inherits every error.

The accounts everybody forgets

Most review programs handle employees reasonably well. The risk concentrates elsewhere.

Service and machine accounts

Integrations, scripts, bots and automation all run on accounts. They often hold broad permissions because "it was easier to make it admin", they rarely have MFA, and they almost never have an owner after the person who created them leaves. PCI DSS now names them explicitly. Give each one a named owner, a documented purpose and a review at the same frequency as privileged human accounts.

The issue is growing with AI agents and automation platforms, which act inside your systems with credentials of their own. If you are introducing them, the access question belongs in the governance discussion from day one, as we argue in our guide to AI governance for business.

Third parties

Verizon's 2026 data put third-party involvement at 48% of breaches. Vendors, outsourced IT, consultants, agencies and auditors all receive access, usually with an implicit end date that never gets written in the system. The fix starts at onboarding: no external access without a sponsor, a purpose and an expiry date. We described that gate in our guide to the vendor onboarding process.

Former employees in SaaS

Single sign-on helps, but only for applications connected to it. A 2023 survey by DoControls, a SaaS security vendor reported by Security Magazine, found that 31% of former employees still had access to company SaaS applications. Treat the figure as directional, since it comes from a vendor, but the pattern is familiar to anyone who has run a first review: the sales tool, the design tool, the file sharing account created with a personal email.

Excess privilege

Microsoft's 2023 State of Cloud Permissions Risks report, summarized by Infosecurity Magazine, found that identities used only 1% of the permissions granted to them, and that more than half of identities were super identities with full access. Again, vendor data, but it points at the most common outcome of a first serious review: the problem is less about who has access and more about how much.

The cost of getting it wrong

IBM's Cost of a Data Breach Report 2026, released on July 29, 2026 and based on 602 organizations, put the global average cost of a breach at $4.99 million. For a mid-market company, the direct cost of a breach is only part of the bill. The rest is the audit finding that delays a financing round, the enterprise customer that pauses a contract until you can show a SOC 2 report, the insurance renewal with a higher premium and new exclusions.

Against that, a well designed access review costs a few days of work per quarter. The math is not close. What makes it expensive is a bad design: reviews that take weeks because data is messy, reviewers who do not understand what they approve, remediation that never closes, and evidence assembled in a panic the week before the audit.

Design roles so the review gets easier every cycle

Most of the pain in an access review comes from the way permissions were granted in the first place. When every user has a custom set of rights, every line in the review is a judgment call. When access is granted through well defined roles, the reviewer only has to answer two questions: is this the right role for this person, and does the role itself still make sense?

A few principles make a large difference:

Build roles around jobs, not people. "Accounts payable clerk" and "accounts payable approver" are roles. "What Mark had before he left" is not.
Keep conflicting permissions in separate roles. If creating a vendor and approving a payment are in different roles, a conflict becomes visible the moment one person holds both.
Limit direct grants. Every permission assigned outside a role should be an exception, with a reason and an expiry date.
Separate everyday and administrator identities. People who need admin rights should use a separate account for admin tasks, so privileged activity is easy to isolate and review.
Review the roles themselves once a year. The system owner checks that each role still contains only what the job requires. This is the review of the template, and it makes every user review that follows faster.

Role design is also where the review connects with your financial controls. The controller should be in the room when ERP roles are defined, because they know which combinations create fraud or reporting risk. IT knows what the system can do; finance knows what it should not allow.

The result is measurable. In the first cycle a reviewer might face hundreds of individual permissions. After a role redesign, the same reviewer confirms a few dozen role assignments and looks closely only at exceptions. That is the difference between a review that takes a manager two hours of careful attention and one that takes two minutes of clicking.

Common mistakes that make reviews worthless

After years of working with companies on their processes, I see the same patterns across sectors. These are the ones that turn an access review into theater.

Reviewing accounts, not permissions. Confirming that Jane still works here is not the review. Confirming that Jane still needs to approve payments is.
Using a list that is not system-generated. If the list was copied, filtered or edited by hand, the auditor cannot rely on it, and neither can you.
Letting IT approve. IT knows the system, not the business need.
Silence as approval. If no response means "keep", every overloaded manager will keep everything.
No remediation tracking. Decisions without verified removal are worth nothing.
Ignoring non-human accounts. Service accounts, API keys and integrations are where the broadest permissions hide.
One giant campaign a year. A single annual review of everything creates fatigue. Tiered frequencies spread the work and focus attention on risk.
No link to segregation of duties. Reviewing each permission in isolation misses the combinations that create fraud risk.
Same reviewers, same blind spots. Rotate or add a second reviewer for privileged access every few cycles.
Treating the audit as the goal. Passing the audit is a consequence. The goal is that nobody holds access they should not have.

If you recognize three or more of these, your current review probably produces evidence without producing control. A structured look at your process is usually faster than buying a tool: you can request a consultation through the site and we can start from your real systems and your last audit findings.

Manual, spreadsheet or tool: how to choose

There are three ways to run a review, and the right one depends on scale and complexity, not on what vendors say.

Spreadsheets. Workable for up to a few hundred users and a handful of critical systems. The weaknesses are completeness (how do you prove the extract was not edited?), reviewer experience and evidence. If you use spreadsheets, lock the extracts, use a shared tracker for decisions and keep the email trail.

Features of your existing platforms. Many identity providers, cloud platforms and ERP systems include basic access review functions. Use them for the systems they cover, but check how they handle applications outside single sign-on and local accounts.

Identity governance tools. Worth evaluating when you have many systems, frequent role changes, several frameworks to satisfy, or a review that already takes weeks. The value is in automated extraction, matching to HR, context for reviewers and closed-loop remediation. The risk is buying a tool before cleaning up roles and ownership: the tool will automate the mess.

A useful test before buying anything: can you, today, produce for one critical system a complete list of users, their permissions in plain language, their manager and their last login, in under one hour? If not, the problem is data and ownership, and that is where to start.

Where automation and AI help

Automation is useful in the parts of the review that are mechanical: extracting data, matching accounts to HR, flagging dormant accounts and conflicts, chasing reviewers, opening and closing tickets. Machine learning can also highlight unusual access compared with peers in the same role, which helps reviewers focus.

What automation cannot do is make the business decision. "Does this person still need to approve credit notes?" is a question for their manager. The pattern I recommend is the same I use in other processes: let the system propose and prioritize, and keep a human accountable for every decision that changes who can do what. In the work I have done with companies, from the medical center that increased capacity by 20% to the hotel that grew revenue from 9 to 10 million, the gains came from clearer processes first, and from tools that amplified them second.

A worked example: the first quarterly review

Consider a company with about 250 employees, an ERP, a payroll system, a CRM, a cloud environment and around 40 SaaS applications. It has never run a structured review; the auditor flagged access as a deficiency last year.

Scope of the first cycle. Not all 45 systems. The ERP, payroll, banking portal and the cloud console, plus all administrator accounts in the identity provider. That covers most of the financial and security risk.

What the first extract typically shows. Accounts that match no active person in HR. Generic accounts used by several people. Service accounts with administrator rights and no owner. Former contractors still active. Users with both vendor creation and payment approval. None of this is unusual; it is the normal state of a company that grew faster than its controls.

How the cycle runs. IT extracts on day one. The controller and system owners clean up role descriptions in plain language during the first week. Managers receive only their team's access, with exceptions highlighted, and have ten business days. Escalation goes to the CFO on day eleven. Revocations are executed within five days and verified with a second extract.

What changes in the second cycle. Fewer exceptions, faster decisions, and a list of structural fixes: roles redesigned so that conflicting permissions cannot be combined, a leaver process connected to HR, an expiry date on every external account. The second cycle is where the review starts to pay for itself, because the volume of problems drops and the remaining work is genuinely about risk.

Self-assessment: how mature is your access review?

Score each statement from 0 to 2: 0 = no, 1 = partly, 2 = yes.

Scope and inventory

We have a list of all systems with sensitive data or financial impact, each with a business owner.
Each system has a risk tier and a defined review frequency.
Service accounts, API keys and integrations are inventoried, each with a named owner.
External users have a sponsor and an expiry date.

Process

Access lists are extracted directly from systems, with date and method recorded.
Accounts are matched to HR data to find orphaned and generic accounts.
Reviewers see permissions in plain language, with last login and conflicts.
Non-response is escalated and does not count as approval.

Remediation and evidence

Revocations have a deadline and are verified with a new extract.
Evidence for each cycle is complete and retrievable in under a day.
Segregation of duties conflicts are checked as part of the review.
Leavers lose access within one business day, independent of the review calendar.

How to read the score:

0 to 10: control at risk. Start with inventory, ownership and the leaver process. A tool will not help yet.
11 to 18: control exists but is fragile. Focus on reviewer context, remediation tracking and evidence quality.
19 to 24: mature. Look at automation, risk-based frequencies and integrating the review with your segregation of duties matrix.

A 30, 60, 90 day roadmap

Days 1 to 30: foundations

Write or update the access review policy: scope, tiers, frequencies, roles, deadlines, evidence.
Build the inventory of critical systems with business and technical owners.
Inventory service accounts and external users; assign an owner to each.
Fix the leaver process: HR notification to IT on the same day, revocation within one business day.
Agree with your auditor, before the first cycle, what evidence they will expect.

Days 31 to 60: first cycle

Run the first review on the highest-risk systems only.
Translate role codes into plain language for reviewers.
Match every account to HR and flag orphaned, generic and dormant accounts.
Track every decision and every revocation to closure.
Run a short retrospective: what slowed reviewers down, what data was missing.

Days 61 to 90: make it repeatable

Redesign the roles that produced the most exceptions or conflicts.
Add segregation of duties checks to the review.
Extend the scope to the next tier of systems.
Decide, with data from the first cycle, whether a tool is justified.
Schedule the next cycles in the calendar, with owners, so the review does not depend on memory.

At the end of 90 days the goal is not a perfect program. It is a control that runs on its own, with clean evidence, and that gets better every cycle. If you want a second pair of eyes on your design before the next audit, you can request a consultation from the dedicated page on the site and we can work through your systems together.

FAQ

What is a user access review?

A user access review is a periodic, documented check that every account in a system belongs to a person or process that still needs it, with permissions that match their current role. For each account and permission the reviewer decides to keep, modify or revoke it, the changes are made and verified, and the evidence is retained for auditors. It complements, but does not replace, the joiner, mover and leaver process.

How often should a user access review be performed?

It depends on risk and on the frameworks you follow. PCI DSS v4.0.1 requires reviewing all user accounts at least every six months. NIST SP 800-53 and ISO 27001 let the organization define the frequency. A common, defensible tiering is quarterly for privileged accounts and financial systems, semi-annually for systems with sensitive personal data, annually for low-risk applications, plus an immediate check whenever someone leaves or changes role.

How do you run a user access review step by step?

Build an inventory of critical systems with owners, extract users and permissions directly from each system, and match accounts to HR records to find orphaned and generic accounts. Assign reviewers who understand the business need, give them permissions in plain language with last login dates, and require an explicit keep, modify or revoke decision. Then execute revocations, verify them with a new extract and keep all evidence.

Who should perform user access reviews?

The business, not IT. Line managers review their team's access, system owners review privileged roles and approve exceptions, and IT extracts data and executes changes. HR provides the authoritative list of active people and role changes. Nobody should review their own access, and internal audit or compliance should test the control independently on a sample.

What evidence do auditors expect from a user access review?

Auditors typically want a system-generated access list with date and source, proof of who reviewed what, each decision with a timestamp, remediation tickets for revoked access, and a follow-up extract showing the access was actually removed. They will also check that the review ran at the frequency stated in your policy and that exceptions were approved by management with a reason and an expiry date.

Do service accounts need to be included in access reviews?

Yes. Service accounts, API keys and integration users often hold broad permissions and rarely have an owner once their creator leaves. PCI DSS v4.0.1 explicitly requires reviewing application and system accounts, with a frequency set by a targeted risk analysis. Each non-human account should have a named human owner, a documented purpose and a review at the same frequency as privileged human accounts.

Do we need an identity governance tool for user access reviews?

Not necessarily. With a few hundred users and a handful of critical systems, a disciplined process with locked extracts and a decision tracker can satisfy auditors. A dedicated tool becomes worth evaluating with many systems, frequent role changes, multiple frameworks or reviews that already take weeks. Clean up roles, ownership and HR data first, otherwise the tool will only automate the mess.