How to run a user access review for SOC 2

What a user access review is, and why SOC 2 asks for one

A user access review is a periodic check that every account on your important systems still belongs to someone who needs it, with no more access than their job requires. Someone who understands each system goes through the list of accounts and roles, decides what stays and what goes, and the changes are made and confirmed.

In a SOC 2 audit, the review supports the logical access criteria in the Common Criteria, chiefly CC6.2 (granting and removing access) and CC6.3 (role-based access, changes and least privilege). The review is the safety net that catches what onboarding and offboarding missed: the contractor whose account was never closed, the engineer who kept admin rights after changing teams, the shared login nobody remembers creating.

For a Type 2 report, the auditor will want to see that the review happened every time your policy says it should during the observation period, and that the problems it found were fixed. That is why the evidence matters as much as the review itself.

Step 1: Decide which systems are in scope

Start with the systems that hold or control access to customer data and production, because those are what your SOC 2 report is about. A typical first list for a small software company:

• Identity provider (your single sign-on directory). It is the front door to most other systems, so review it first.
• Cloud console accounts and roles for production, including any separate root or owner accounts.
• Code hosting, especially who can merge to the main branch or change deployment pipelines.
• Production data stores: database users, data warehouse access, backup storage.
• Support and admin tools that can see or change customer data.

Write the list down and keep it in one place, with an owner for each system. Agree it with your auditor before the observation period starts if you can: scope is their call as much as yours.

Step 2: Pull the user and role lists

For each in-scope system, export the current list of accounts with their roles or permission levels. Take it from the system itself, not a hand-maintained spreadsheet, and save it with the date. A useful export shows, at minimum:

• the account name or email,
• the role, group or permission level,
• whether the account is active,
• the last sign-in date, if the system records it.

Then pull a current list of employees and contractors from HR or whoever owns that record, including recent leavers and people who changed roles since the last review. You will compare the two.

Step 3: Assign the reviewers

The reviewer should be someone who knows whether each person needs the access: the system owner, or the people's managers. What matters most is that nobody reviews their own access. If the head of engineering is the only admin on the cloud console, someone else should confirm that their admin role is still appropriate.

For a small team, a common pattern is: the system owner reviews everyone else's access, and a second person (often the CTO or a founder) reviews the system owner's access and signs off on the whole review. Record who reviewed what.

Step 4: Review each account

Go through the export line by line. These are the questions that find real problems:

Leavers and inactive people

Does every active account belong to someone who still works for you? Compare against the leaver list. Accounts with no sign-in for months often point to access nobody needs.

Role creep

People collect access as they move between projects and teams, and rarely give it back. For each person, ask whether their current role still needs this permission level. Admin rights granted "just for the migration" are a classic finding.

Shared and service accounts

Every shared or service account needs a named owner and a reason to exist. Shared logins for people are hard to justify in an audit because they break accountability: nobody can tell who did what. Service accounts used by applications should have only the permissions they need, and their credentials should be under someone's control.

Privileged access

Give admin, owner and root-level accounts extra attention. Keep the list short, confirm each one by name, and check that privileged accounts use multi-factor authentication if your access control policy requires it.

Accounts you can't explain

Any account nobody recognizes is a finding in itself. Disable it first and ask questions afterwards, unless it is clearly a system account someone can vouch for.

Step 5: Record every decision

Each account gets an explicit decision: keep, change or remove. "Looked fine" is not evidence. A simple table per system is enough. Here is a template you can copy:

Add the reviewer's name and the date the review was completed at the top of each system's table.

Step 6: Remediate, then verify

Raise a ticket for every removal or change, so there is a record of the request, who made the change and when. Then check that it actually happened: re-export the user list or take a screenshot showing the account gone or the role changed. Reviews that list removals but never confirm them are a common reason auditors raise an exception.

Do the changes promptly. If your access control policy sets a deadline for removing access, meet it, and note any exceptions with a reason.

Evidence to keep for your access review

For each review, keep these together in one place so you can hand them over without searching:

• the list of systems in scope for that review;
• the dated user and role exports from each system;
• the completed review table, with each decision and its reason;
• who reviewed each system, and the overall sign-off with a date;
• the tickets for every change or removal;
• proof that the changes were made (a later export or screenshot).

The dates matter. Auditors check that the review happened within the period it covers and that remediation followed. Exactly which items and formats they accept is up to them, so ask early. For how to organize evidence like this across all your controls, see SOC 2 evidence collection: an audit-ready library.

How often: the quarterly access review

Quarterly is the most common cadence for user access reviews in SOC 2 programs, and it is the default in the SOC 2 content Compliance in a Box provides. Some teams review their highest-risk systems more often, or lower-risk systems less often. There is no single rule: your access control policy sets the cadence, and your auditor tests you against what your policy says. Pick something you will actually keep up with for the whole observation period, because a missed quarter is easy for an auditor to spot.

To see how the access review fits around your other recurring controls, see The SOC 2 compliance calendar.

Common access review mistakes

• Self-review. The only admin approves their own admin access. Get a second person to sign off.
• Rubber-stamping. Every account marked "keep" with no reasons, quarter after quarter. Auditors notice when nothing ever changes.
• No proof of removal. The review says an account should go, but nothing shows it went.
• Stale exports. Exports taken weeks before the review, or a hand-maintained spreadsheet instead of the system's own list.
• Forgotten systems. Local admin accounts, database users and service accounts that sit outside single sign-on.
• Missed periods. One quarter skipped during a busy launch, with nothing recorded about why.

User access review checklist

1. Confirm the list of in-scope systems and their owners.
2. Export accounts and roles from each system, dated.
3. Get the current employee and contractor list, including leavers and role changes.
4. Assign reviewers, making sure nobody reviews their own access.
5. Check every account for leavers, role creep, shared and service accounts, privileged access and unknown accounts.
6. Record a decision and reason for every account.
7. Raise tickets for all changes and removals.
8. Verify each change with a fresh export or screenshot.
9. Collect the evidence in one place and get a dated sign-off.

Running access reviews in Confluence with Compliance in a Box

If your team already works in Confluence, Compliance in a Box runs the user access review as a recurring activity, quarterly by default and mapped to CC6.2 and CC6.3 in the app's controls matrix. Here is what that looks like in practice:

• An evidence page each period. Before each quarter is due, the app creates an evidence page for that period under the User Access Review activity page in your compliance space (14 days ahead by default). The page starts with a checklist and headings for the systems in scope, the reviewer, the users removed or changed, and the exports attached. You attach your exports and fill in the review table there.
• An owner and a due date. The activity has an owner who does the work, and each period is due on its last day, following your fiscal year. Periods that pass their due date without approval show as overdue.
• Approval bound to the page version. The owner submits the evidence page for approval, and every approver must approve. The approval is tied to the exact version submitted: editing the page before it is approved cancels the submission. If the owner approves their own evidence, it is flagged as a self-approval, which helps with the separation of duties point above.
• Gaps stay visible. A Compliance Admin can skip a period that genuinely didn't need doing, but only with a written reason that is kept for auditors.
• Reminders and reports. Owners and approvers see the work in My Tasks and get reminders as Confluence tasks. The generated Activity Completion Report links to exactly the evidence page version that was approved for each period.

The app makes sure the review happens on time, the evidence lands in the right place, and the sign-off is recorded. The evidence pages and review and approval sections of the guide explain each step, and the SOC 2 audit readiness checklist shows where access reviews fit in your wider preparation.

FAQ

Who should perform a user access review?

The owner of each system, or the managers of the people with access, because they know who needs what. Someone other than the account holder must review privileged accounts, and a second person should sign off on the overall review.

Is a quarterly access review required for SOC 2?

SOC 2 doesn't set one fixed frequency. Your access control policy defines the cadence, and the auditor tests whether you followed it. Quarterly is a common choice for production and customer data systems.

Does single sign-on remove the need for access reviews?

No. You still need to check who is assigned to which applications, the roles inside each one, and local or service accounts outside single sign-on.

What if we find nothing to change?

That is a valid outcome. Record it: the exports, the reviewer, the date and a note that every account was confirmed. An empty change list is still evidence that the review took place.

← All articles