SOC 2 User Access Reviews: Cadence, Evidence and What Auditors Check

Does SOC 2 require user access reviews?

SOC 2 user access reviews are how you show an auditor that access stays correct between a joiner and a leaver. A SOC 2 report tests your controls against the AICPA's Trust Services Criteria. Two of the security criteria cover who holds access. CC6.2 deals with granting credentials and removing them when access is no longer authorized. CC6.3 says the entity "authorizes, modifies, or removes access" based on roles and responsibilities.

Each criterion comes with points of focus. Under both CC6.2 and CC6.3, one point of focus is a periodic review of access. The AICPA treats points of focus as guidance. You do not have to show that each one is addressed.

So the review is not a line item you must tick. In practice it is the usual way to meet these criteria. Without one, you need another control that catches access nobody needs any more.

Which SOC 2 criteria cover access reviews?

Three criteria in the CC6 series shape what a review must cover.

Your auditor reads these alongside the control description you wrote. That description says what you review, who reviews it and how often.

How often should you run SOC 2 access reviews?

Run them as often as your own control says. The criteria ask for a review on a periodic basis and give no number. You write the frequency into your control description, and the auditor tests you against it.

Common practice is quarterly for privileged access and for production systems that hold customer data. Many teams review lower-risk applications every six or twelve months. That is a convention you choose, and the criteria do not set it.

Pick a cadence you can keep. A quarterly review you miss once becomes a finding. A six-month review you run on time does not. A customer contract or another framework may set its own number, and then that number applies.

How does a Type I audit differ from a Type II?

The two reports test different things. A Type II report covers how controls were designed and how they operated across a period of months. A Type I report covers the design at one date, with no opinion on how the controls operated.

For access reviews, that difference decides what the auditor asks for.

• Type I. The auditor checks the design at one date. Is there a written control, a defined scope, a named reviewer for each system, and a way to remove access?
• Type II. The auditor checks operation across the period. Each review that fell inside the period must have happened, on time, with evidence.

The first Type II is where gaps in a review process show. A review planned for the third quarter and run in the fourth is a finding, even if it was thorough.

What evidence do auditors sample?

For a Type II, the auditor picks a sample of review runs and a sample of decisions inside them. For each one, expect to show six things.

1. The population. The list of accounts for each system, pulled at review time, with how you pulled it: the system, the date and the report or query.
2. The reviewer. Who decided, and why that person was the right one. The auditor checks that nobody reviewed their own access.
3. The decision. Keep or remove, for each account. One approval for a whole list of two hundred users is weak evidence.
4. The date. When the review opened and when it closed, inside the window your control states.
5. The follow-through. For each removal, proof that the access is gone, with the date it ended.
6. The sign-off. A named person confirming the review is complete.

The follow-through is where samples fail. Say a manager marks David Kim's Salesforce access for removal in March. The auditor picks that row and asks for the Salesforce record showing his access ended, and when. A ticket closed as done is weaker proof than the system's own log.

Which exceptions do auditors write up?

An exception is a sampled item where the control did not work as described. These are the ones that recur.

• A missed or late review. The control said quarterly and one quarter had no review.
• An incomplete population. A system was left out, service accounts were excluded, or the list came from a spreadsheet with no source.
• Self-review. An admin certified their own admin role.
• Removals that did not happen. Access marked for removal was still there weeks later.
• No record of the decision. A reviewer answered "looks fine" in chat and nothing else exists.
• A leaver still active. Testing for CC6.2 finds an account that worked after the person's last day.

A review where every row was kept, finished in a few minutes, also draws questions. The auditor may ask how the reviewer judged each account.

How do you prepare for a SOC 2 access review audit?

Start before the audit period opens. Then work through these steps in order.

1. List the systems in scope: your identity provider, production cloud accounts, code repositories and each application that holds customer data.
2. Write the control. Name the scope, the frequency, the reviewer for each system, the deadline and how fast removals must land.
3. Pull each population from the system itself, and keep a record of how you pulled it.
4. Give reviewers what they need to decide: the role, what it grants, and the last sign-in.
5. Assign reviewers who are not reviewing themselves, and name a fallback for each one.
6. Remove what was denied, and keep the system's own confirmation.
7. Get a sign-off, then file the evidence for each run in one place.
8. Run one full review before the period starts, as a rehearsal.

Include non-human identities such as service accounts and app registrations. They hold access too, and they are easy to leave off the list. An orphaned account with no owner is often the first row an auditor questions.

How EnscureX runs the review and keeps the record

Govern runs access reviews as campaigns over tags, groups, applications or roles. Each reviewer sees the last sign-in and usage beside every decision. A campaign can have ordered reviewer stages, with a fallback reviewer. Items can be reassigned, and reminders go out as the deadline approaches. A campaign is configured once and recurs on the schedule your control states.

Each decision is approved or denied. When the campaign completes, each denial is revoked in the directory, and a failed revoke is reported per account. Revocations run through the connection's write-back tasks, which you switch on per connection. The closed campaign holds the decisions, the sign-off and each revocation result. The evidence exports as a CSV of every decision. The survive the audit page shows that closed campaign.