To do an access review for SOC 2, export the list of users and permissions for each in-scope system, have the system owner or the person's manager confirm each line, remove anything wrong and ticket the change, then save the dated export, the sign-off and the removal proof. Repeat on a schedule your policy states, often quarterly.
Key takeaways
- Auditors most often flag reviews that happened once, or that lack detail showing permissions were actually looked at.
- Pick the schedule in your own policy and then keep it. A policy you do not follow is a finding.
- A revocation needs a closed ticket or log entry linked to the review record.
- Check the exact wording of the criteria and your auditor's expectations. Sources map CC6.2 and CC6.3 differently.
What is a SOC 2 access review?
A SOC 2 access review (also called a user access review or access recertification) is a periodic check that every account on an in-scope system still belongs there and holds only the access its job needs. It supports the logical access criteria in the AICPA Trust Services Criteria, usually discussed as the CC6 group.
The AICPA publishes the criteria in a downloadable document. We could not read the full text for this guide, so check the current wording there. Guides map CC6.2 and CC6.3 differently, with one splitting them as provisioning in CC6.2 and removal or modification in CC6.3. Ask your auditor which control they test.
How often should I run it?
As often as your access control policy says, and most guides describe quarterly as the usual cadence. Choose a cadence you can actually sustain, such as quarterly for production and admin access and twice a year for lower risk apps, and write it into the policy.
What are the steps?
- Define scope: production, cloud accounts, code hosting, identity provider, databases, support tools, and any system that holds customer data.
- Name an owner for each system. This is the person who can say whether access is right.
- Export users, roles, groups and last sign-in date from each system. Date the file.
- Send each owner their export. Ask for a decision on every line: keep, change or remove.
- Look for the usual problems: leavers, contractors past their end date, shared accounts, admin roles nobody can explain, and service accounts with no owner.
- Make the changes and ticket each one. Link the ticket to the review.
- Re-export to show the fix, or capture the audit log entry.
- Have the review owner sign off, with a date.
- Store everything in one folder per review period.
AWS's IAM guidance supports the same habit: regularly review and remove unused users, roles, permissions, policies and credentials, using last accessed information.
What evidence do auditors want?
Keep these items for each review:
| Evidence | What it shows |
|---|---|
| Dated export of users and roles | The population at the time of review |
| Reviewer name and decision per line | A real person evaluated the access |
| Tickets or log entries for removals | Revocations actually happened |
| Re-export or audit log after changes | The fix is effective |
| Sign-off with date | The review was completed on time |
Reports should include user identifiers, roles and last sign-in where available. Reviews should be attested by the manager or system owner and kept as evidence. If removal needs a ticket to another team, that ticket must be closed and linked.
What mistakes cause findings?
- Doing the review once and never again.
- Reviewing without detail, so nothing proves permissions were examined.
- Approving everything. One vendor reports reviewers approve over 95 percent of access in certification campaigns and treats that as a red flag. This is a single vendor claim, so treat it as a warning sign and not a benchmark.
- Missing service accounts and API keys. Our service account guide covers them.
- Forgetting leavers. See how to offboard an employee securely.
How can I make the review lighter?
Reduce the number of systems reviewed separately. Put apps behind SSO so one identity provider export covers many. Use groups instead of per-person grants, so reviewers confirm a few groups rather than hundreds of lines.
You can also automate the export and reminders. Try the demo below to see how gaps and evidence collection look in a readiness workflow.
Click through it at your own pace, or open it full screen.
Frequently asked questions
Is a quarterly access review required for SOC 2?
The criteria we could verify do not set a number in the text we read. Many auditors expect the cadence in your own policy, and quarterly is common. Confirm with your auditor.
Who should perform the review?
The system owner or the person's manager, not the person being reviewed and not only IT. The reviewer must know what the job needs.
Do I review service accounts too?
Yes. Include service accounts and API keys, with a named owner for each. Unowned machine identities are a common gap.
What if I find too much access?
Remove it, ticket it and keep proof. Finding and fixing is the point, and a documented fix looks better than a clean report that nobody believes.
Can a spreadsheet be enough?
For a small team, yes, if it is dated, signed off and backed by exports and tickets. Move to tooling when the system count grows.
Sources
- AICPA, 2017 Trust Services Criteria (landing page)
- AWS IAM security best practices
- Torii, SOC 2 access review requirements
- Iden, how to run a user access review
Last reviewed: 19 October 2026.
