User Access Review: How to Run One, Step by Step

What a user access review is

A user access review is a check, done on a schedule, of who can get into what. For each account, someone who knows the person and the system decides: keep the access (some tools say approve), change it, or remove it (some say reject). The decision is written down with a reason. Then the changes are made, and the record is kept.

An account is a login in one system. Access is what that account can do there, usually through a role (a named set of permissions) or a group (people who share a role). Many tools call one such item an entitlement.

Why do it? Access piles up. People change teams, finish projects and leave, and few moves take any access away. This slow build-up is called privilege creep. The review is when you take it away. Customers and auditors, the outside people who check that you do what you say you do, ask for it for that reason.

The same job is also called access certification or access recertification. The access certification guide explains the names.

Who reviews what

Two kinds of people can answer “should this person have this access?” They know different things.

• The manager knows the person: the job they do now, the project they moved to, whether they still need the billing role.
• The system owner knows the system: what a role really allows and which accounts are sensitive. It is the person who answers for that system, such as the head of engineering for your production cloud account.

One step is enough for a small company: the manager decides. For sensitive systems, add the system owner as a second step, after the managers, so the owner sees each manager’s answer and reason.

Nobody reviews their own access

This rule matters most. A person has little reason to give up their own access, so a review where people confirm their own access is not independent. Set the rule on purpose:

• The reviewer of a line is never the person who holds the access.
• A manager’s own access goes to their manager. The access of top people and administrators goes to someone else, such as a co-founder or the security lead.
• The person who makes access changes should not be the only person who reviews them. ISO/IEC 27002:2022, which explains the access rights control in ISO 27001, lists “segregating the roles of approval and implementation of the access rights” in its guidance.

Two ideas sit behind this. Least privilege means a person has the access their job needs, and no more. Segregation of duties means no one person can do something risky alone, such as granting access and approving it. SOC 2 criterion CC6.3 names both.

How often to review

The frameworks (published rules that auditors check you against) do not agree, and most give no number.

PCI DSS

PCI DSS is the rulebook for organizations that handle payment card data. Requirement 7.2.4 covers all user accounts, vendors’ included. Review them at least every six months, check that access fits the job, deal with what does not, and have management acknowledge that the access that remains is appropriate. It was a best practice until 31 March 2025 and has been required since. Accounts that software uses fall under requirement 7.2.5.1, where the interval comes from your targeted risk analysis (requirement 12.3.1).

Every six months

ISO/IEC 27001

ISO/IEC 27001:2022 is the standard companies get certified against. Control 5.18 in its Annex A, the list of controls, is called Access rights. The companion standard, ISO/IEC 27002:2022, says regular reviews should look at access after any change of job, promotion, demotion or leaving, and at privileged access (access that lets a person change systems or see everything). It sets no number of months.

SOC 2

A SOC 2 report is an auditor’s report on your controls, based on the trust services criteria of the AICPA, the American Institute of CPAs. Criteria CC6.2 and CC6.3 cover authorizing, changing and removing access, and set no interval. Their “points of focus”, notes on what matters, mention reviewing access “on a periodic basis”. The AICPA says using the criteria does not require checking every point of focus. So you choose the interval, write it in your policy, and the auditor tests whether you did what you wrote. A Type 2 report covers a stretch of time, not one day, so expect to show each review that fell inside it.

HIPAA and NIST

HIPAA, the US health data law, asks covered entities and business associates to “establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process” (45 CFR 164.308). It sets no schedule. It marks the item “addressable”: you assess it, then either do it, or write down why it is not reasonable and appropriate for you and put an equal alternative in place if a reasonable one exists (45 CFR 164.306(d)(3)). Ask your adviser how it applies to you.

NIST’s SP 800-53 Rev. 5 is the control catalog US federal agencies use. Control AC-2, item j, covers reviewing accounts, and control AC-6(7) covers reviewing privileges. Both leave the frequency to the organization.

Choosing your interval

If PCI DSS applies to you, six months is the ceiling for user accounts. Otherwise you choose. One setup that works: administrator and production access every quarter, the rest every six months, and a person’s access at once when they change role or leave. Write it in your policy and follow it.

There are three kinds of review, and most teams run all three:

• Scheduled. Everything in scope, at the interval your policy sets.
• On a change. One person’s access, when they change role or leave.
• Privileged only. Administrators and anyone who can change other people’s access, more often than the rest.

The access certification guide says more about these rounds.

Scope the population, and make sure it is whole

The population is the full list of accounts and access that the review covers. Auditors look at it first, because a review of a partial list is a partial review. The AICPA standard for examinations like SOC 2 (AT-C section 205) tells the auditor to evaluate whether information produced by the company is reliable, including evidence that it is accurate and complete. Expect the question: how do you know this list is everyone?

1. Decide which systems are in scope. Start with the ones that matter most: your identity provider (the system that handles logins), cloud accounts, source code hosting, production databases, and tools that hold finance or customer data. For PCI DSS, every system that touches card payment data is in. Write down a reason for anything you leave out. Count every environment (production, staging, test) and every realm, organization or account inside a system as its own part of the list.
2. Take the list from the system itself. Export it. Do not retype it or rebuild it from memory. Keep the raw file untouched and work on a copy. Write down the date and time, who ran it, and any filter. The template’s where to get the data table says where to look in common systems.
3. Include every kind of account. People, contractors and vendors. Disabled accounts someone could switch back on. Shared accounts. Service accounts and API keys, which are accounts that software uses; the AICPA’s 2022 points of focus name system and service accounts. Each needs a person who looks after it.
4. Count the rows. Compare them with the number on the system’s own screen. If they differ, find out why. Many systems return only the first page of results.
5. Match the accounts to your employee list. An account with no matching person is an orphaned account: nobody owns it. A person who left and still has an account is worse.
6. Look for inherited access. This is access nobody assigned to the person directly. It comes through a group. Groups can sit inside groups. A role can contain other roles. Some systems give every user a default role. An export of direct assignments leaves all this out. Ask for effective access, which is what a person can really do, and test it: pick three people and compare the export with what the system says they can do. For Keycloak, how to run a user access review in Keycloak has a script that lists effective access.
7. Freeze the list. Once reviewers start, the list does not change. Changes go into the next review. Keep the export date next to every decision.

What auditors ask for

Auditors differ, so ask for their request list early. These are the usual requests:

• The full list of accounts and access, with the date and how it was taken (the raw export), and how you know it is whole.
• Who was asked to review, and who did, with dates.
• A decision for each line and the reason, especially for change and remove.
• Evidence that nobody reviewed their own access.
• Management’s acknowledgement that the result is appropriate. PCI DSS 7.2.4 asks for it in those words.
• For every remove and change, the ticket or log showing it was done, and when.
• Your policy on how often you review, and a record of each review in the period.
• Anything left undecided, with an owner and a date.

The user access review process, step by step

Follow along with the user access review checklist and keep the records in the free user access review template.

Numbers to report

When the review closes, write down a few counts from your own review. Management acknowledges the result from them:

• How many lines were in the review.
• How many were decided by the deadline.
• How many reviewers kept every line they were given.
• How many orphaned accounts you found.
• How many removals were done by their due date.

What happens after a Reject

Rejecting a line removes nothing by itself. It is a decision, and someone with administrator rights has to carry it out.

1. Turn each remove and change into a ticket. A ticket is a tracked piece of work. Put the line and the reviewer’s reason in it.
2. The administrator changes it in the system, within the deadline your policy sets, and records who did it and when. A Change works the same way, for example cutting full access down to read-only.
3. Check that it is gone, twice. Right after the change, the administrator looks at the account. At the next export, the line should no longer appear. The second check catches the usual slips: the change was made in the wrong place, it was undone, or another group gives the access back.
4. Escalate what is not done. A remove that sits open past its deadline is the first thing an auditor will find.

If an administrator disagrees with a decision, send it back to the reviewer and record a new decision. Do not overwrite the old one. The history is part of the evidence.

Common failures

Rubber-stamping. The reviewer approves everything without looking. Give them context, keep each list short, ask for a reason on every remove and change (a remove with no reason leaves the administrator guessing), and spot-check a few lines they kept.

A partial export. The list leaves out inherited access, service accounts, disabled accounts or a second environment. The scoping steps are the fix.

No record of the removal. The review says remove, and nothing shows it happened. Use one ticket per line.

The wrong reviewer. The manager changed jobs or the reviewer left, so the lines went to someone who does not know the person. Refresh your manager data first.

A list that moves. If it changes while people decide, the decisions no longer match the export. Freeze it, and keep one folder for each review.

A spreadsheet, or software

You can do all of this with a spreadsheet, email and a ticket tracker. Start with the free template and the checklist. It hurts in four places: getting data out of each system, finding inherited access, chasing reviewers, and assembling the evidence.

Acciew is built for that work. Its collectors are small, open-source programs that only read. They collect accounts, groups and roles from Keycloak, GitHub and AWS IAM, including access that comes through a group or a nested role. Each manager gets a short list by email link and chooses Approve, Reject or Change, with a note. At the end you download an evidence pack: a spreadsheet with a row for every access and decision, a PDF and Word report, logs and a manifest.

Acciew never removes access. Your administrators do that in your own systems. A check at the next collection that removed access is gone is coming soon.

Related guides

• Access Certification: What It Is and How to Run ItAccess certification, user access certification and recertification are one job. Who certifies, what a campaign is, and how to run one without an IGA suite.
• How to run a user access review in KeycloakRun a user access review when your identity provider is Keycloak: what to collect, where access hides, and a tested script that lists who holds a role.
• User Access Review Checklist: Before, During, AfterA checklist for a user access review in three parts, before, during and after, with the evidence to keep. Print it and tick the boxes as you go.
• Privileged User Access Review: How to Run OneHow to review admin and other privileged access step by step, who should review it, how often, and where it hides in Keycloak, GitHub and AWS.

Questions and answers

Is a user access review the same as an audit?

No. A user access review is a check you run yourself, on a schedule. An audit is when an outside person, an auditor, checks that you do what you say you do.

How often should we run a user access review?

PCI DSS says at least once every six months for user accounts. SOC 2, ISO 27001 and HIPAA set no number, so your own policy sets it.

Who should review, the manager or the system owner?

The manager knows what the person does now. The system owner knows what the access allows. A manager alone is enough for a small team. Add the owner for sensitive systems. Nobody reviews their own access.

Do service accounts and API keys need a review?

Yes. They are access too, and they pile up unnoticed. Give each one a named person who looks after it. PCI DSS has its own requirement for accounts that software uses, 7.2.5.1, with the interval set by your targeted risk analysis (requirement 12.3.1).

What if a reviewer does not answer?

Chase them, then send the line to their manager once the deadline passes. Record it as open. Never count silence as approval.

Do we need special software?

No. A spreadsheet, email and a ticket tracker are enough for a few systems.