A quarterly SOC 2 access review is a repeatable process: export who has access to each in scope system, have the right owner confirm or challenge each entry, remove or reduce what is not needed, and file the dated evidence. In a Type 2 period, you must be able to show each review happened on schedule.
Which criteria does this serve?
CC6.2 covers registering and authorising users before access is granted and removing credentials when access is no longer authorised. CC6.3 covers authorising, changing and removing access based on roles and responsibilities, with least privilege and segregation of duties in mind. The AICPA criteria do not prescribe a quarterly cadence. Quarterly is a common choice because it is frequent enough to catch drift and light enough to sustain. Pick a cadence, write it in your policy and follow it, since an auditor tests against what you said you do.
A Type 2 report covers a period and includes tests of operating effectiveness, so every review in the period is a sample the auditor can request.
What is the five step process?
Step 1: Fix the scope. List in scope systems: identity provider, cloud console, source code host, production databases, CI and deployment tools, ticketing, customer data tools, finance and HR systems. Mark which hold the most sensitive access. Update the list every quarter.
Step 2: Export the access. For each system, export users, roles, group memberships, last login and account type (human, service, shared). Save the raw export unaltered. Include service accounts and API tokens, which are easy to miss.
Step 3: Assign reviewers. The reviewer should be the system owner or the user's manager, not the user and not the person who granted the access. Admin level access gets a second reviewer. This supports segregation of duties.
Step 4: Review and decide. For each row, the reviewer marks keep, reduce or remove, with a one line reason for anything privileged. Compare against HR records: any leaver still present is a finding. Check for dormant accounts, shared accounts and roles that no longer match the person's job.
Step 5: Act and close. Raise a ticket for every change. Make the change, record the date, then run a fresh export to prove it. Collect a sign off from the reviewer and from the compliance owner.
What evidence should you keep?
- The system list and review date.
- Raw exports with timestamps.
- The reviewed version with decisions, reviewer names and dates.
- Tickets for removals and reductions, with completion dates.
- A re-export showing the changes took effect.
- Exceptions: who, why, approver, expiry.
- A summary line for each quarter: systems reviewed, accounts reviewed, changes made.
Name files consistently, such as system, quarter and year, so you can find them in a minute during testing.
How do auditors sample this?
Expect requests such as: show the review for a named quarter on a named system, show the removals that came from it, show how you know the export was complete, and show leavers during the period with their removal dates. They compare your policy to your records. A missed quarter is hard to fix retroactively, because you cannot create contemporaneous evidence later.
Which mistakes are common?
- Reviewing the list the system owner remembers rather than an export.
- Reviewer is the person whose access is being reviewed.
- Rubber stamping: every row "keep" with no comments.
- No service accounts in the export.
- Removals requested but never confirmed.
- Late reviews with no explanation. If you slip, document why and complete it, and fix the cause.
- Terminated users removed from the identity provider but still active in tools with local accounts.
How should you handle joiners, movers and leavers between reviews?
The quarterly review is a safety net. The primary control is the access lifecycle: access requested and approved on joining, adjusted when someone changes role, and removed on leaving, each with a ticket. If those tickets are reliable, the quarterly review should find few surprises. Track the count of findings per quarter. A rising number points to a broken lifecycle.
What to do
- Write the review procedure in two pages, including cadence and reviewer rules.
- List in scope systems and owners.
- Schedule the next four reviews in calendars now.
- Build a repeatable export for each system, scripted where you can.
- Run the first review, file the evidence and fix what you find.
- Compare against HR leaver records every time.
- Report totals to management each quarter.
Quick check
Do SOC 2 criteria require quarterly access reviews?
No. The criteria require authorising, changing and removing access appropriately. Quarterly is a cadence you choose and document, then follow consistently.
Can you fix a missed review after the period ends?
You can still run it, but it will not count as a contemporaneous control for that quarter. Document the miss and the cause, and expect the auditor to note it.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems instead of by screenshot, and monitoring runs between quarterly reviews, which gives the team time for other work. Technical evidence for the wider program comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. The independent auditor forms the opinion. Book a call.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criteria CC6.2 and CC6.3, and the Type 2 description. Paraphrased, copyright AICPA.
Last reviewed: 18 October 2026.
