User access review template for SOC 2
A free access review workbook in Excel format: one row per system for the quarterly user access review, and a service account inventory for the non-human identities. Name your systems below or start from a generic list. It is the same pair of sheets that ships in the Policyseed Audit Kit.
What a user access review is
A user access review is a periodic check, system by system, that everyone who has an account still needs it and has no more access than their role requires. The owner of each system exports the current list of accounts and roles, compares it with who works at the company and what they do, asks for anything wrong to be removed, and signs off. For SOC 2, the record of that check is evidence that access controls keep working after the day access was granted.
The workbook has two sheets:
- Access Review. One row per in-scope system, with columns for the export, the counts, the changes requested and completed, and the owner’s sign-off. Copy the rows for each new quarter, or keep one file per quarter.
- Service Accounts. The inventory of non-human identities: service accounts, API keys, deploy keys and integration tokens, each with an owner and a rotation date.
If you leave the systems field blank, the template starts with this generic list:
- Identity provider / single sign-on
- Cloud provider (console and IAM)
- Source control
- CI/CD pipeline
- Production database(s)
- Email and collaboration suite
The Audit Kit’s version is pre-filled from your stack: it lists your identity provider, each cloud provider’s console and IAM, your source control, your CI/CD tool, production databases and every vendor you named.
How to fill it in
The Access Control Policy describes the procedure in section 5: export the user and role lists, reconcile them against the personnel list, send each owner their list for attestation, and complete removals promptly. The Access Review columns, in order:
| Column | What goes in it |
|---|---|
| Quarter | The review period, for example 2026-Q3. |
| System | One in-scope system per row: identity provider, cloud console, source control, production database, key SaaS tools. |
| System owner | The person who decides who should have access and signs off the list. |
| User list exported (date) | When the account and role list was exported from the system. Export it; do not retype it. |
| Accounts reviewed | How many accounts were on the exported list. |
| Privileged accounts reviewed | How many of those hold admin or production roles, reviewed individually. |
| Removals or changes requested | Accounts to remove or roles to reduce, with the reason (left, changed role, unused). |
| Removals completed (date) | When the requested changes were made. Keep the ticket or the system log. |
| Owner attestation (name, date) | The owner confirming the remaining access is appropriate. |
| Evidence location | Where the export, the ticket and the sign-off are stored. |
The Service Accounts columns:
| Column | What goes in it |
|---|---|
| Identity | The service account, API key, deploy key or bot user. |
| System | Where the identity exists. |
| Owner | The person responsible for it. An identity with no owner is a candidate for removal. |
| Purpose | What uses it and why. |
| Permissions | The roles or scopes it holds. |
| Secret location | Where its key or token is stored, for example a secrets manager path. Never the secret itself. |
| Last rotated | When the key or token was last replaced. |
| Next rotation due | When it is next due for rotation. |
| Still needed? (reviewed quarterly) | Confirmed at each access review; unused identities are removed. |
Keep the exports themselves, not just the counts. Save each one with the date and system in the file name and put its location in the evidence column.
How an auditor uses it
Access reviews are tested under the logical access criteria in the CC6 series. The auditor reads what your policy commits to, usually in its policy statements, then asks for the review records for each quarter in the period and checks that the removals you requested were actually made.
| Criterion | What the review has to show |
|---|---|
| CC6.1 Logical access security | That logical access is restricted to the right people. The list of in-scope systems shows what the access controls cover. |
| CC6.2 User registration and deprovisioning | That accounts are removed when people leave. The review is the backstop that catches leavers offboarding missed, so auditors compare active accounts against the personnel list. |
| CC6.3 Role-based access and least privilege | That access matches each person's role. Removals and reduced roles recorded in the review, with dates and an owner sign-off, show least privilege is maintained, not just granted once. |
| CC4.1 Ongoing and separate evaluations | That controls are evaluated on an ongoing basis. A review run every quarter, with dated evidence, is one of the clearest examples. |
A common follow-up is to take a leaver from the personnel list and check that their accounts were gone by the time of the next review, or to pick a removal from your sheet and ask for the ticket or log that shows it happened.
Common mistakes
- Reviewing a list nobody exported. A review typed from memory cannot show which accounts existed. Export from the system and record the date.
- Sign-off with no decisions. If every quarter says “no changes” at a company that hired and lost people, the auditor will ask how the review was done.
- Removals requested but never completed. The completed date, and the ticket behind it, is what shows the control worked.
- Missing systems. Reviewing the identity provider but not the cloud console, the database or the SaaS tools that hold customer data, especially those not connected to single sign-on.
- Skipping service accounts. API keys and deploy tokens with no owner outlive the people who created them.
- Reviewing late. A quarter’s review done in the following quarter, or all four done just before the audit, does not show the control operated on the cadence your policy states.
For the risk side of the same audit, see the risk register template. For the evidence auditors collect across all criteria, see the SOC 2 evidence checklist.
Frequently asked questions
- How often does SOC 2 require access reviews?
- SOC 2 does not set a frequency. Your policy does, and the auditor tests against it. Quarterly is a common choice for production, source code and identity administration; the Policyseed Access Control Policy commits to quarterly for those systems. Whatever you write, every review in the period has to have happened.
- Which systems should be in the access review?
- At least the systems that hold customer data or can change production: the identity provider, the cloud console and IAM, source control, the deployment pipeline and production databases, plus any SaaS tool that stores customer data. If your policy names a system, it belongs in the review.
- Who should do the review?
- The owner of each system, who knows who should have access, with one person coordinating. The coordinator should not be the only reviewer of their own access; have someone else attest to the administrators' accounts.
- What evidence does the auditor want from an access review?
- Typically the exported user list with its date, the reviewer's decisions, the tickets or logs showing removals were made, and the sign-off. A spreadsheet that says 'reviewed, no changes' with no export behind it is weak evidence.
- Why does the template include service accounts?
- Service accounts, API keys and deploy tokens are access too, and they are easy to forget because no person leaves when they stop being needed. Reviewing the inventory at each access review is how orphaned keys get found and removed.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.