This guide treats the review as decisions for a person, whether the work sits in a sheet or in a tool. In plain terms, the work means asking, for each person’s access, whether it should stay or go, then acting on the answer and keeping a record. It shows how to conduct a user access review in eight steps. A companion article on why access builds up takes up the definition and the causes. This guide is for an IT manager or owner at a firm of roughly 100 to 2,000 people in India or the GCC. The eight steps, their order and the yes or no check on each are Signisys’ own method, not a standard. It sets no review interval and gives no audit checklist.
Last reviewed 2026-11-01 by Manish Sharma.
How to Conduct a User Access Review in Eight Steps
These eight steps are the short answer to how to conduct a user access review. A step counts as not done if it has no recorded yes, which is a rule of this method.
Name the applications and people. Check: is the scope written down?
A line per person and application, in plain words. Check: can a reviewer read it unaided?
Send each reviewer only people they can judge. Check: does each line name one reviewer?
Each line gets an answer and reason. Check: does each line hold both?
One person follows up late answers. Check: does the request name both?
Each remove answer becomes a task. Check: does each task name a person?
Look in the application. Check: does a fresh list show the access gone?
Put each decision where a reader finds it. Check: does each entry hold six fields?
Where This Method Comes From, and What Is Our Own
The two documents read for this guide give advice rather than a numbered method for how to conduct a user access review. The CISA and NSA best-practices guide for administrators is US guidance. In the copy read, the guide shows no publication date. Its disclaimer calls it advisory and not compliance or legal advice, and it also warns that it may be out of date. In a passage on identity governance systems, it says an inventory of accounts and privileges enables application and data owners to periodically review and reconcile them. It gives no interval.
NCSC’s 10 Steps to Cyber Security page (UK; reviewed 11 May 2021; written for cyber security professionals) puts its advice on reviewing accounts for unnecessary privileges in its section on privileged accounts. It gives that advice in general terms and also sets no interval. Our glossary also explains privileged accounts.
In the passages read, neither document says how to split the list between reviewers, how to hand it out, what an answer must hold or how to confirm a removal. Those parts are our own working choices, and we label each as ours when it appears. The earlier identity set-up guide leaves the full review method for a later article; this guide is that method.
Steps 1-2 to Conduct a User Access Review: Scope and a Readable List
Anyone who has to conduct the review starts with these two steps, which settle what is in scope and which user access appears in the list. Both come before anyone has to answer a question.
Step 1: Choose What the Review Covers
Write down which applications and which groups of people this review covers. Choose first the applications where an unauthorised sign-in would do serious harm, as well as the ones staff in several teams use. Contractors, shared accounts and service accounts are in scope only if you list them. Write down any you leave out, such as a contractor group.
Decision: which applications go first, and whether any people or accounts stay out for now.
Leave until later: the applications you have no list for yet.
Is the list of applications and people in scope written down?
Step 2: Build One List a Reviewer Can Read
Make one list with a line for each person and application, showing the level of access in words, the person’s job and the manager. Ask each application’s administrator for the data, or export it yourself if you have the rights. Write each level in words a reviewer would recognise, such as “can edit customer records”, rather than an internal code.
Decision: how much detail a line needs when a reviewer has to decide without asking IT.
Leave until later: hunting for accounts that have no owner, which is a different job.
Can a reviewer read a line and say what the person can do, without asking IT?
Steps 3-4 to Conduct a User Access Review: Each Reviewer’s Share and a Real Answer
Steps 3 and 4 hand the list to the people who answer it. A reviewer who has to conduct the review needs to know, before answering, what to judge in each line of user access and what a usable answer looks like.
Step 3: Give Each Reviewer Only Their Share
Split the list so each reviewer sees only the people they can judge. In our view, a manager can say whether the job still needs the access, and an application owner can say what each level allows. If a line is the reviewer’s own, name someone else to sign it off. Send each reviewer their lines and a short note, as well as the due date.
Decision: manager, application owner or both for each application, and who stands in when a reviewer is absent.
Leave until later: a second sign-off for sensitive applications.
Does each line have one named reviewer who is not the account holder?
Step 4: Ask for Keep or Remove, With a Reason
Ask for one of two answers on each line, keep or remove, and a short reason either way. When a reviewer leaves a line blank, writes “approve all” or keeps with no reason, it counts as no answer and goes back to the reviewer. A reason can be a phrase, such as “still runs the team’s month-end reports”. If a reviewer is unsure, they mark the line “ask” and name who they will ask.
Decision: what counts as a usable reason, written once before the first request goes out.
Leave until later: scoring or rating the reasons.
Does each line hold keep or remove and a reason in the reviewer’s own words?
Key Takeaway A line has an answer only when it holds keep or remove and a reason.
Steps 5-6 to Conduct a User Access Review: A Chaser and the Removals
Whoever has to conduct the review also needs a plan for late answers and unfinished removals that leave user access in place. In our method, each needs a named person before the request goes out.
Step 5: Set a Due Date and Name a Chaser
Put a due date and the name of one person who chases late answers in the request itself. A chaser is the person who follows up when answers have not come in. The firm sets the date and writes the reason beside it. The chaser is a person, not a mailbox, and also needs the standing to raise a late answer with the reviewer’s own manager. Write down, before the request goes out, what happens to a line still unanswered at the due date.
Decision: the due date, the chaser, and the rule for lines still unanswered when the date passes.
Leave until later: reminder wording.
Are the due date, the chaser’s name and the rule for unanswered lines written in the request?
Step 6: Make the Removals
Turn each remove answer into a task with a named person and a place to do it. Group the remove answers by application and give each group to whoever can change that application. Say whether a removal is a deletion, a lower level or a switch-off, so the person acting does not guess. NCSC’s advice on revoking privileged access covers privileged accounts only; for other accounts, this step is our own.
Decision: who acts on each application, and who decides when a removal could stop work.
Leave until later: undoing a removal that turns out to be wrong.
Does each remove answer have a named person who will act on it?
Steps 7-8 to Conduct a User Access Review: Confirm Removals and Keep the Record
The last two steps close out how to conduct a user access review. They show the team did the work, and they also keep the evidence.
Step 7: Confirm Each Removal Happened
Check the application itself, not the request, to see whether the access has gone. Pull a fresh list after the removals, then set it against the lines marked remove. Where the firm has enough people, someone other than the person who made the change does the check.
Decision: who confirms, and what proof to keep, such as an export or a note by the checker.
Leave until later: audit-style tests of the review itself.
Does a fresh list from the application show each removed access gone?
Key Takeaway A removal counts when the application shows the access gone, not when a request says someone made it.
Step 8: Keep a Record With Six Fields
Keep one entry for each decision, with the six fields below. Store the entries next to the list, where the next reviewer can find them. The firm also sets how long it keeps records.
Decision: where records live, and whether anyone may change them.
Leave until later: reports for senior people.
Could someone not involved read an entry and see who decided what, and why?
Steps to Conduct a User Access Review: A Worked Example, Illustrative
To conduct the review, this example follows a small firm’s user access in one application. It is illustrative only and not a Signisys client. It names no figures and no time spans.
A small firm reviews its customer-records application. One reviewer returns a line marked keep with no reason, which fails Step 4’s check, so the line goes back. Later, the reviewer adds the reason and the check passes.
A second reviewer has not answered by the due date, and the chaser raises it with that reviewer’s manager, as the request said it would. A reviewer marks two lines remove, while the rest stay. The administrator makes the changes, but the fresh list from the application still shows one of them. Step 7’s check fails. The administrator repeats that removal, a new list is pulled, and the check passes. The firm then enters each decision in the record. A failed check means that step is run again.
Key Takeaway What Done Looks Like: the firm has written the scope, each line has a named reviewer and an answer with a reason, the application shows each removal, and the firm keeps six-field entries.
What This Guide Leaves Out, and When to Ask for Help
This guide covers one review of user access, run once by whoever has to conduct it. It does not set an interval; the firm sets it and writes down the reason. The guide gives no audit checklist or scoring, but a checklist is a separate topic. It does not choose between a sheet and software, and it does not argue a switch; for that decision, see this separate article on the sheet-or-software question. It does not cover conflicting duties, third-party contracts or anything a law or regulator requires, and none of the steps is legal advice.
A yes shows a check passed on the day someone ran it, but it does not show the firm’s access is correct. Ask for outside help when you have no way to list who has what in an application, when removing an account could stop work, or when nobody in the firm can judge the reviewers’ answers. For how Signisys approaches these reviews, see how Signisys handles access reviews; for the wider subject, see the glossary on identity and access management.
Signisys delivers identity and access management through its Cybersecurity and Digital Trust services, and agrees the scope for each engagement. See our solution, Identity and Access Management (IAM), and our service, Cybersecurity Services.
How to Conduct a User Access Review: FAQ
What if all I have is a sheet?
What should a reviewer’s answer look like?
Who chases a reviewer who has not answered?
How do I know a removal really happened?
What interval applies when you conduct a user access review?
Is this order an official standard?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.