User Access Review Checklist (SOC 2 / ISO 27001)
A user access review checklist for SOC 2 and ISO 27001: pull user lists, confirm owners, revoke stale accounts and keep evidence an auditor will accept.
- Typical schedule quarterly
- The checklist 5 sections, 22 items
- Variables
{{quarter}}
Run this review every quarter, and also after a reorganisation, an acquisition or a security incident. It checks that every person and service account with access to your important systems still needs it, at the level it has. Auditors for SOC 2 and ISO 27001 usually ask for evidence that this happens on a regular schedule, so the record matters as much as the clean-up.
Who owns it
A security or IT lead coordinates the review. The decisions belong to system owners and line managers, because they know who needs what. The coordinator collects the lists, chases answers and files the evidence. Adapt this to your jurisdiction and your audit scope; it is a practical checklist, not legal advice.
Common pitfalls
- Reviewing a list nobody can trust. Export user lists directly from each system on the review date. A spreadsheet maintained by hand drifts quickly.
- Rubber-stamping. Managers approve long lists without reading them. Send each reviewer only their own people, and ask for an explicit "keep" or "remove" per line.
- Forgetting non-human accounts. Service accounts, API tokens and shared admin logins often have the most power and no owner.
- No proof that removals happened. Auditors check that revoked access was actually removed. Take a second export after the changes.
- Ignoring the identity provider bypass. Local accounts in tools that also support SSO survive offboarding.
Schedule the run in Runbook for the first week of each quarter. The audit trail then shows who confirmed each step and when.
The checklist: User access review {{quarter}}
Scope and preparation
-
Confirm the list of in-scope systems for
{{quarter}}Start with your identity provider (e.g. Okta, Google Workspace, Entra ID), production cloud accounts, code hosting, databases, finance and HR tools, and anything holding customer data.
-
Confirm a named owner for each in-scope system
-
Export the current HR or staff list as the source of truth for active people
-
Export user and role lists from every in-scope system on the same day
Save the raw exports with the date in the file name. They are your "before" evidence.
Reconcile accounts
-
Match every account to an active person in the HR list
Flag accounts with no match, including former staff, contractors whose contract ended and test accounts.
-
List accounts that exist locally in a tool but not in the identity provider
-
List all admin and privileged roles separately for a closer look
-
List service accounts, API tokens and shared logins with a named owner for each
An account without an owner is a finding in itself. Assign one or plan to remove it.
-
Flag accounts with no login in the last 90 days optional
Pick a threshold that fits your systems and use it consistently.
Reviewer decisions
-
Send each manager or system owner only the accounts they are responsible for
-
Collect an explicit keep, change or remove decision for every account
-
Confirm that every privileged role is still needed and justified in writing
-
Check that no one approves their own access
-
Chase reviewers who have not answered and escalate after the agreed deadline
Apply changes
-
Remove or disable accounts marked for removal in each system
-
Reduce roles marked for change to the agreed level
-
Rotate credentials for shared accounts where a holder lost access
-
Take a second export of each system after the changes
Compare it to the decisions. This "after" export proves the removals happened.
Evidence and follow-up
-
Store the before exports, decisions and after exports in the audit evidence folder for
{{quarter}} -
Record exceptions with the approver and an expiry date
-
Raise tickets for root causes, such as an offboarding step that missed a tool
-
Report the summary to the security lead or management optional
Checklist as Markdown
Frequently asked questions
How often should user access reviews be done for SOC 2?
SOC 2 does not prescribe a fixed interval. Your own policy defines it, and the auditor tests that you follow it. Quarterly reviews are a common choice for critical systems, with a lighter review for lower-risk tools. Pick a schedule you can actually keep, because a missed review is a finding.
What evidence does an auditor expect from an access review?
Typically the user list as it was at the review date, the reviewer and their decision for each account, and proof that removals were carried out. Dated exports, a signed-off list and a second export after the changes cover most requests. Keep them together per review period so you can find them quickly.
Should service accounts be part of the access review?
Yes. Service accounts and API tokens often have broad permissions and are easy to forget. Give each one a named owner, confirm it is still used, and rotate or remove credentials that nobody can account for.
Updated