Access reviews for SOC 2: how to run and record them

Why this matters

An access review is one of the few SOC 2 controls that produces a record you can hold in your hand. The auditor wants to see that someone looked at who has access to each in-scope system, decided whether that access still fits the person's job, and acted when it did not. The review is not a policy statement. It is a dated list with decisions.

Reviews catch the access that piles up. A contractor who left in March still has a repo token. A finance manager changed teams but kept billing admin. A shared admin login has no named owner. SOC 2 auditors test the control across the report period, so a single clean-up before the audit does not prove the control ran. Type II reports need repeated reviews with evidence for each cycle. Type I reports need one review at the point in time.

The record matters as much as the clean-up. If you removed the account but cannot show who reviewed it, when, and what they decided, the evidence is thin. A good access review file lets an auditor pick any account and follow it from the raw system export to the reviewer's decision to the change ticket to the final state.

Before you start

List every system in scope and where its access lives. Start with your identity provider, then add cloud consoles, code repositories, databases, ticketing, logging, finance, HR, and any app that holds customer data. For each system, name the source of truth for accounts and the person who owns it. Do this before you pick a tool, because the tool cannot review systems you never connected.

Set the cadence in your access control policy and match it in practice. Quarterly is common for general access, monthly for privileged access. Pick a schedule you can keep, with a named backup reviewer. The auditor will ask for every cycle in the period, so a cadence you miss creates a gap.

Build one review sheet with fixed columns: account, display name, system, role or group, manager, employment status, last login, reviewer, decision, reason, ticket, date. Add a column for account type so privileged, service, and shared accounts stand out. Decide where the evidence lives, such as a ticket per system or a folder per quarter with controlled access. Keep raw exports unchanged and store the signed review beside them.

How to do it

Run the review as a short project, not a lunch break task. Give each system owner a filtered list and a due date. The reviewer should be able to approve or reject access, not just forward the list. Track completion by system, not by email replies.

For each account, force a decision. Keep, change, or remove. A blank cell is not a decision. If the reviewer wants to keep admin access for a person who does not need it, write the reason. Auditors do not expect zero access. They expect a review that shows judgment.

When the review ends, close the loop. Removals and role changes need tickets, and the system needs a fresh export that shows the change. Store the final package with the raw list, signed decisions, tickets, and the after-change export. Add a short memo that says which systems were reviewed, who reviewed them, the date range, and any exceptions with owners.

1. Lock the review population. Export the full account list from each in-scope system on the first day of the cycle. Save the raw file, note the export time, and record the system owner. Do not edit the raw file.
2. Reconcile people with HR. Match each account to an active employee or contractor. Flag accounts with no match, duplicate names, generic logins, and people on leave.
3. Split out privileged and service accounts. Pull admin, root, billing, break-glass, and shared service accounts into their own review. Record the owner, purpose, and whether the credential still needs to exist.
4. Assign the right reviewer. Route each system's list to its owner or a manager with authority over the access. Keep the person who holds the access out of approving their own row.
5. Record a decision per account. Use keep, change, or remove for every row. Add a reason when access is unusual, temporary, or tied to a role change.
6. Execute changes in the source system. Open a ticket for each removal or role change and complete it in the system. Capture the before and after state, not just the request.
7. Export again and close the cycle. Pull a fresh account list and confirm removals are gone and changes landed. Attach the signed review, tickets, and after export in one evidence folder.

How to check it worked

Pick a few accounts at random, including one privileged account and one contractor. Follow each from the raw export to the reviewer's decision to the ticket to the after-change export. If you cannot complete the chain without asking someone, the file is not ready.

Check the review window against the dates on the evidence. The export, reviewer sign-off, and ticket dates should fall inside the cycle. A review dated after the quarter ends and a ticket dated before the export is a red flag. Check that the reviewer is not the account holder and that every row has a decision.

Look for population gaps. Compare the systems on your scope list with the systems in the evidence folder. Confirm that mid-cycle joiners and leavers were handled, not only the people who were on the list on day one. If you use a compliance tool, export the review report and the raw CSV. A screenshot of a dashboard is a weak substitute for the underlying list.

Test the outcome in the system. Search for a removed account and confirm it is disabled or deleted. Check that a role change actually reduced access. If the review says remove and the account still works, the control failed even if the form is signed.

Mistakes to avoid

Reviewing a screenshot of a user list instead of the full export. Screenshots hide rows, cut off columns, and do not show the account count. An auditor cannot sample from a cropped image.

Letting the system admin approve their own access or the access of the team they manage. Independence is part of the control. If your team is small, have a founder or another leader review the admin's rows.

Marking every account as keep with no notes. That looks like a rubber stamp and gives the auditor nothing to test. Decisions should change something or explain why nothing changed.

Forgetting service accounts, shared logins, and access granted through groups. These are common paths to in-scope data. Review the group membership and the service account owner, not only the named user list. Keep the evidence out of personal drives and email threads. A controlled folder or ticket with a clear audit trail is easier to defend.

Frequently asked questions