Guide

User Access Review Checklist: Before, During, After

A 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.

Part of the guide User Access Review: How to Run One, Step by Step

4 min readLast updated

Use this list for each review. It prints: use your browser’s Print command, and the menu, footer and buttons stay off the page. Each item is numbered, so you can refer to it (“item 12”), and has a box to tick. The user access review guide explains the reason behind each one.

Before you start

  1. Name one owner for the review, a person who answers for it being finished.
  2. List the systems in scope, with every environment and every realm, organization or account in each. Write down the reason for any you leave out.
  3. Check your policy says how often you review, and who reviews what. (PCI DSS asks for user accounts to be reviewed at least once every six months. SOC 2 and ISO 27001 leave the interval to your policy.)
  4. Name a system owner for each system in scope.
  5. Get a current list of employees and contractors from HR, with each person’s manager.
  6. Refresh the manager data first: check that each person’s manager on that list is still their manager.
  7. Name a default reviewer for lines that have no manager, such as contractors and service accounts.
  8. Set the deadline for reviewers, and a later date for carrying out the changes.
  9. Ask your auditor, if you have one, what they want to see.
  10. Choose one folder for this review’s records and name it with the date.

Take the list

  1. Export the full list of accounts and access from each system in scope, using the system’s own export, for every environment and every realm, organization or account.
  2. Keep the raw file untouched and work on a copy.
  3. Write down the date and time of the export, who ran it, and any filter used.
  4. Count the rows and compare them with the number on the system’s own screen.
  5. Include disabled accounts, shared accounts, vendor accounts, service accounts and API keys.
  6. Check for access that comes through groups, groups inside groups, roles that contain other roles, and default roles.
  7. Compare the accounts with the HR list. Look at accounts with no matching person, and at people who left.
  8. Give every account a named person who looks after it.
  9. Add to each line: the person, their manager, how they got the access, and when the account was last used.
  10. Write “Unknown”, not “Never”, when the system does not record last use.
  11. Freeze the list. Changes after this go to the next review. Put the export date next to every decision.

Send it out

  1. Give each line to a reviewer: the manager first, then the system owner for sensitive systems.
  2. Check that no line goes to the person who holds the access.
  3. Check that each manager’s own access goes to their manager.
  4. Check that the administrator who makes access changes is not the only person who reviews them.
  5. Send each reviewer only their own lines, with the deadline.
  6. Ask one question: does this person still need this access to do their job?
  7. Explain the three answers: Keep, Remove or Change. Remove and Change need a reason.

During the review

  1. Check progress half-way to the deadline, and again two days before it.
  2. Chase the reviewers who have not started.
  3. Spot-check a fixed share of the lines each reviewer kept, such as one in ten, and record which. Look harder at any reviewer who kept every line.
  4. Answer questions about unfamiliar roles in one plain sentence, and share the answer with the other reviewers.
  5. Leave the list alone. Note any change for the next review.

Close the review

  1. After the deadline, send the open lines to the reviewer’s manager.
  2. Record every line with no decision as open, with an owner and a date.
  3. Count the lines kept, changed, removed and open.
  4. Have management read the summary and acknowledge it, with a name and a date.

After the review

  1. Turn each Remove and Change into a ticket, with the line and the reason in it.
  2. Have an administrator carry out each one in the system, and record who did it and when.
  3. Have the administrator look at the account after the change.
  4. Escalate anything that is past its deadline.
  5. At the next export, check that removed access is gone and that changed access shows the new level.
  6. Set the date of the next review.

The evidence folder

  1. The raw export, with its date and who ran it.
  2. The working list, with the context added.
  3. Every decision, with the reviewer, the date and the reason.
  4. The list of lines left open, with owners.
  5. The management acknowledgement.
  6. The tickets for every removal and change, and the check at the next export.
  7. The policy that sets how often you review.

Who acknowledged it

Role Name Date
Review owner
Management acknowledgement

Keep the records in the free user access review template, or in your own sheet. For the full method, read the user access review guide.

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

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