Privileged User Access Review: How to Run One

Admin accounts are where one mistake costs most, so they deserve a closer look than the rest. This guide shows what to include, who should review it, how often, what the frameworks ask, and how to run one with a spreadsheet.

A privileged user access review is a check of every account that can change settings, read everything, or grant access to others. For each one, a reviewer who knows the work confirms that the person or program still needs that power. Your admins remove it if not, and you keep a record of the list, the decisions and the removals.

What counts as privileged access

Privileged access is access that lets an account do what ordinary accounts cannot. NIST’s glossary defines a privileged user as a user that is authorized (allowed), and therefore trusted, to perform security-relevant functions that ordinary users are not authorized to perform.

The test is what the access lets someone do, not what the role is called. Include:

Anyone who can change other people’s access. This is the most important group, because they can give themselves anything else. In your identity provider (the system people sign in through, such as Keycloak), it is the admin roles.
Owners and admins of code and cloud. A GitHub organization owner, an admin on a repository, an AWS user or role with a policy that allows every action.
Accounts that software uses. Service accounts, deploy keys, API tokens and the roles your build pipeline runs as. Some of them hold more access than any person does.
Emergency and shared logins. A “break-glass” account kept for when single sign-on fails, or one admin login shared by a team.
Admins of the tools that watch the others. Whoever runs your logging or security tools can often hide what happened elsewhere.
Access to sensitive data. Anyone who can read all customer records or payment data, even without admin settings.

How it differs from a regular user access review

A user access review asks one question of every line: does this person still need this access? A privileged review asks the same question, but of fewer lines, with a reviewer who understands what the access allows.

A regular user access review and a privileged user access review side by side
Aspect	Regular review	Privileged review
Scope	Every account and its access, across the systems in scope.	Only the accounts that can change settings, read everything or grant access.
Who reviews	Mostly managers, who know what each person does now.	The system owner, who knows what the access allows, with the manager.
Accounts that software uses	Often an afterthought.	Central. Some of them hold admin rights.
Questions asked	Is this access still needed?	Is it still needed, does it need to be there all the time, and is it tied to one named person?
How often	What your policy sets.	What your policy sets. Often a shorter gap than for the rest.

You can run it as its own round, or as the first part of your regular review. Either way, keep its records apart so an auditor can find them.

What SOC 2, ISO 27001, PCI DSS and NIST say

None of these frameworks names a “privileged user access review” as a separate exercise with its own deadline. Each one asks you to control and review access, and some name privileged access in particular.

What each framework says about privileged access, and how often to review it
Framework	What it says	How often
NIST SP 800-53 Rev. 5, AC-6(7) and AC-2(7)	Review the privileges assigned to the roles or classes of users you choose, to confirm they are still needed, and reassign or remove them if not. Monitor privileged role assignments and revoke them when they are no longer appropriate.	A frequency you define.
PCI DSS v4.0.1, requirement 7.2.4	Review all user accounts in PCI DSS scope and their access privileges, vendors included. Administrators are user accounts, so they are in it.	At least once every six months.
ISO/IEC 27001:2022, Annex A controls 8.2 and 5.18	Control 8.2 is Privileged access rights: their allocation and use is restricted and managed. Control 5.18, Access rights, covers reviewing access under your access control policy.	No interval. Your policy sets it.
SOC 2 trust services criteria, CC6.3	Access is authorized, changed and removed by role, with least privilege and segregation of duties in mind.	No interval. Your policy sets it.

NIST SP 800-53 Rev. 5 is the control catalog US federal agencies use, and many other teams borrow from it. Besides AC-6(7) and AC-2(7), control AC-6(5) restricts privileged accounts to the people or roles you name, and AC-6(2) says people with privileged accounts use a non-privileged account or role when they do work that is not security work. AC-6(9) asks you to log the use of privileged functions.

PCI DSS is the security standard for organizations that handle payment card data. Requirement 7.2.4 also asks that management acknowledge that the access that remains is appropriate. Accounts that software uses fall under requirement 7.2.5.1, where the interval comes from your own targeted risk analysis.

For SOC 2, the AICPA’s trust services criteria set no review interval, and neither does ISO 27001. Your policy sets it, and the auditor checks that you did what it says. One setup that works: privileged access every quarter, the rest every six months, and a person’s access at once when they change role or leave. That is a choice, not a framework rule. The user access review guide covers each framework in more depth.

How to run a privileged user access review, step by step

Write down where privilege lives. For each system in scope, list the roles, groups and policies that count as privileged under the test above. Ask the system owner to confirm the list. This list is the scope of the review, so keep it with the records.
Export everyone who holds them. Use the system’s own export, and keep the raw file. Ask for people who get the access through a group, a group inside a group, or a role that contains other roles, not only those assigned it directly. Include service accounts, tokens and disabled accounts.
Add the context a reviewer needs. For each line: the person or program, the system, the role, one plain sentence on what the role allows, how the account got it, and when it was last used. Write “Unknown” if the system does not record use.
Give a named person to every account that software uses. If nobody can say who looks after a service account or token, that is a finding in itself. Record it and decide what to do with the account.
Assign reviewers. The person’s manager reviews each line, and the system owner checks what the access allows. An account that software uses goes to the person who looks after it. Nobody reviews their own access. Do not leave the admins of a system to review only each other.
Ask the harder questions. Beyond “is it still needed”, ask the questions in the next section, and ask for a reason with every answer.
Carry out the removals. Your administrators remove or reduce each access a reviewer rejects, one ticket per line. Record lines with no decision as open, never as approved.
Export again and compare. Check that each removed access is gone from the system. Then file the export, the decisions, the tickets and the second export together, with the date and who ran the review.

The user access review checklist has the same steps for a full review, on one page you can print. The free user access review template has most of the columns for steps 2 to 6. Add two: what the role allows, and who looks after each account that software uses.

Tip: Check what the admin role contains

In Keycloak, realm-admin is a bundle of every management role of the realm, and manage-users on its own lets a person change other people’s access. A review of “who holds realm-admin” misses the people who hold only one part. List every role that grants admin power, not only the one called admin.

Questions to ask about each privileged account

Does the job need it now? Not “did it once” or “might one day”.
Does it need to be there all the time? Someone who needs admin rights twice a year may not need to hold them every day. Some teams grant admin access only for the time a task takes. This is often called just-in-time access.
Is it tied to one named person? A shared admin login means the review cannot say who used it.
Is it a separate admin account? If a person does daily work, such as email, with the same account that holds admin rights, ask whether they should have two. NIST control AC-6(2) asks for a non-privileged account or role for that kind of work.
When was it last used? An admin role nobody used since the last review is a strong candidate for removal. If the system does not record use, say so rather than guess.
How did they get it? Access that came through a group someone joined for another reason is easy to miss. Removing it may mean changing the group, not the person.

Where privileged access hides in Keycloak, GitHub and AWS

A list of people called “admin” misses most of it. In the three systems many teams start with:

Where privileged access sits in Keycloak, GitHub and AWS
System	Look for	Easy to miss
Keycloak	The roles of the realm-management client, such as realm-admin, manage-users, manage-clients and manage-realm. Each one gives admin power on its own. The admin role in the master realm.	The impersonation role, which lets its holder sign in as another user. In the master realm, the client for each other realm, named after it, whose roles manage that realm. Roles that arrive through a parent group or a composite role.
GitHub	Organization owners, who have complete administrative access to the organization. The Admin role on each repository.	Admin rights that come through a team rather than to the person directly. Outside collaborators with Admin on a repository. Installed GitHub Apps with broad permissions, deploy keys with write access, and personal access tokens.
AWS	Users, groups and roles with the AdministratorAccess policy, which gives full access to AWS services and resources. The root user. Each AWS account needs its own review.	A policy that lets someone change IAM itself, and so give themselves anything. Your own policies that allow every action. Admin given through IAM Identity Center permission sets. Long-lived access keys on IAM users. Roles that other accounts or services may assume.

Each system’s own documentation explains these roles: GitHub’s roles in an organization and repository roles, and AWS’s pages on the root user and the AdministratorAccess policy. GitHub recommends limiting the owner role, but to no fewer than two people. AWS recommends not using the root user for everyday tasks.

In IAM Identity Center, a permission set becomes an IAM role in each account it is assigned to, so admin access granted there shows up as roles, not as named users. Keycloak’s Server Administration Guide describes its admin roles.

For “when was it last used”, AWS IAM keeps last accessed information for users, groups, roles and policies, so you can see which services each one has tried to use. For Keycloak, the Keycloak access review guide shows how to list every holder of an admin role, including those who get it through groups and composite roles.

When to review outside the schedule

Do not wait for the next round when one of these happens. Review the person’s or the account’s privileged access at once:

Someone changes role or leaves. Admin rights from the old job are easy to leave behind.
Someone joins an admin group or gets an admin role. Check that the grant was approved and is still needed.
An emergency account was used. Find out who used it and why, then change its password or keys.
An incident, a merger or a new vendor. Review the admin access of the systems involved.
A service account’s keeper leaves. Name a new keeper, or turn the account off.

Common mistakes

Reviewing only the people called admins. Service accounts, tokens and inherited roles hold as much.
Letting admins approve each other. A reviewer who holds the same access has a reason to keep it.
One “approve all” for the whole list. Ask for a reason on every line of a privileged review.
Counting silence as approval. A line with no decision stays open until someone decides.
Not checking the removal. A rejected access that nobody confirms gone may still be there.

Where Acciew fits

Acciew runs user access reviews for Keycloak, GitHub and AWS. It reads who holds each role, group and policy, shows how each person got it, such as through a group inside another group, and in AWS when each user and role was last used. Managers decide from an email link, and at the end you get an evidence pack for your auditor. It only reads: your admins make every change.

Have an access review coming up?

Acciew is in early access. We are looking for design partners: teams with a user access review ahead of them.

Apply as a design partner

Questions and answers

How often should privileged access be reviewed?

If PCI DSS applies to you, requirement 7.2.4 of v4.0.1 asks for the user accounts in its scope, administrators included, to be reviewed at least once every six months. SOC 2 and ISO 27001 set no interval, and NIST SP 800-53 control AC-6(7) leaves it to you. One setup that works: privileged access every quarter, the rest every six months. That is a choice your policy writes down, not a framework rule.

Who should review privileged user access?

The person's manager, with the owner of the system checking what the access allows. Never the holder, and not only the other administrators of the same system. For the administrators of your identity provider, pick someone who is not in that admin group, such as a co-founder or a head of security who is not an admin.

Do service accounts count as privileged access?

Yes, when they hold admin roles or broad policies. No person signs in with them, so nobody notices them. Give each one a named person who looks after it and answers for it in the review. PCI DSS covers accounts that software uses in requirement 7.2.5.1, with the interval set by your targeted risk analysis.

What is the difference between privileged access management and a privileged access review?

Privileged access management, or PAM, is a kind of tool that controls how admin access is used, for example by keeping admin passwords in a vault or granting admin rights for an hour at a time. A privileged access review is a check of who holds that access and whether they still need it. You can run the review with or without a PAM tool.

What is a privileged user?

NIST defines a privileged user as a user that is authorized, and therefore trusted, to perform security-relevant functions that ordinary users are not authorized to perform. Authorized means allowed. In practice that means anyone who can change settings, see everything, or give access to other people.

This guide is part of User Access Review: How to Run One, Step by Step. Read the whole guide there.