SOC 221 April 2026 7 min read

SOC 2 Access Review: How to Run Quarterly User Reviews

SOC 2 requires periodic access reviews under CC6. Here's how to run quarterly reviews efficiently, what to document, and how to avoid the most common CC6 exception.

Key Takeaways

CC6.2, CC6.3, and CC6.5 collectively require periodic review of all user access to in-scope systems.
Quarterly access reviews are the standard expectation — missing even one review cycle during the observation period produces an exception.
Reviews must produce a retrievable record: who reviewed, when, which users were approved or revoked, and evidence of any access removal.
Automated access review workflows dramatically reduce manager burden and eliminate the manual spreadsheet export problem.
Off-cycle reviews are required when employees change roles or leave — these must be documented regardless of the quarterly schedule.

In this guide

What SOC 2 Access Review Actually Means
Which Systems Must Be Reviewed
How to Run a Quarterly Access Review
Documenting the Review for Auditors
Off-Cycle Reviews: Onboarding, Offboarding, Role Changes
Automating Access Reviews with Compliance Tools

What SOC 2 Access Review Actually Means

A SOC 2 access review is a formal process where system owners or managers review the list of users with access to each in-scope system and confirm that every user's access is still appropriate and necessary. Users whose roles have changed or who no longer need access should have their access modified or revoked as a result of the review.

Access reviews address three Common Criteria: CC6.2 (access provisioning and de-provisioning — ensuring access is removed when no longer needed), CC6.3 (access is consistent with roles and segregation of duties), and CC6.5 (access is authorized). The review is the periodic verification that the access state matches the authorized state.

The quarterly frequency (four reviews per 12-month observation period) is the standard expectation. Some auditors will accept semi-annual reviews for lower-risk systems, but quarterly is the default. For privileged access (production database admin, cloud console admin), monthly reviews are considered better practice and are viewed more favorably.

Which Systems Must Be Reviewed

Every system in your SOC 2 scope must have a periodic access review. At minimum: your production cloud account (AWS IAM users, roles, and group memberships), your identity provider (Okta or Google Workspace — all user accounts and application assignments), your source code management system (GitHub organization members and repository access), your production databases (all database users and their permissions), and any other systems with access to customer data.

Privileged access deserves extra attention. Production database admin credentials, AWS root account access, Okta admin roles, and any service accounts with elevated permissions should be reviewed separately and more frequently. Many companies do a combined quarterly review that covers all users but applies extra scrutiny to the privileged subset.

Third-party access is frequently overlooked. If external consultants, contractors, or vendor support personnel have access to in-scope systems, they must be included in access reviews and their access must be time-limited. Permanent access for "just in case we need the vendor" is a CC6.2 violation.

How to Run a Quarterly Access Review

Step 1: Export user access lists from each in-scope system. From Okta: export all active users and their assigned applications. From AWS IAM: export all users, groups, roles, and their attached policies. From GitHub: export all organization members and their repository permissions. From your database: export all database users and their grant levels.

Step 2: Cross-reference the access lists against your current employee directory. Flag any users who have left the company, changed roles, or whose access appears inconsistent with their current responsibilities. Step 3: Route the flagged items to the appropriate manager for review and decision: approve (access is appropriate), modify (access needs to change), or revoke (access should be removed).

Step 4: Execute approved changes. Remove or downgrade access for all users flagged for revocation or modification. Step 5: Document the review completion — record the date, the reviewer, the systems covered, the number of users reviewed, the changes made, and attach the user access export as supporting evidence.

Documenting the Review for Auditors

The documentation standard for an access review: (1) the date the review was initiated and completed, (2) who conducted the review and who approved the results, (3) the list of systems reviewed, (4) the user access export from each system at the time of review, (5) any users whose access was modified or revoked as a result, and (6) a completion attestation confirming all required actions were taken.

Auditors will sample access reviews during the observation period and test specific items. A sample test might look like: "You said User X's access was revoked on October 15. Show me the access list from September 15 showing they had access, the revocation ticket, and the access list from October 15 showing they no longer have access." Having all three components is required to demonstrate the review was effective, not just conducted.

Store all access review records in a centralized, retrievable location — not in individual managers' email inboxes or unsaved browser exports. Compliance platforms provide structured access review workflows where all decisions and supporting documents are automatically archived.

Off-Cycle Reviews: Onboarding, Offboarding, Role Changes

The quarterly access review covers the steady state. Off-cycle events require immediate access changes that must be documented separately. Employee termination: all access must be removed within your stated SLA (typically 24 hours for immediate terminations, same-day for involuntary departures). The offboarding checklist must document every access revocation with timestamps.

Role changes: when an employee moves from Engineering to Product Management, their access to production systems may need to change. This isn't caught until the next quarterly review unless you have a process for triggering an access review when role changes are recorded in HR. CC6.2 requires "timely" de-provisioning — waiting 3 months for the quarterly review to catch a role change may not satisfy "timely."

New employee provisioning is also an access review concern — CC6.2 requires that access provisioning is authorized. The onboarding checklist must include access provisioning steps with manager approval evidence. Provisioning access without an authorization record is a CC6.2 gap.

Automating Access Reviews with Compliance Tools

Manual access reviews are the single most common operational bottleneck in SOC 2 programs. Quarterly reviews using exported spreadsheets require: exporting user lists from multiple systems (30–60 minutes), combining and cross-referencing lists (60–120 minutes), routing to managers for approval (days of waiting), collecting approvals (another round of emails/Slack messages), executing changes (30–60 minutes), and archiving documentation (30 minutes). Total: 5–15 hours per review cycle, every quarter.

Automated access review tools reduce this to: the platform pulls user lists automatically, generates a review interface for each manager showing their direct reports' access, routes approval requests via email or Slack, records every decision with a timestamp, and archives the completed review automatically. Manager time per review cycle: 15–30 minutes per manager. Admin time: 1–2 hours to monitor completion and handle escalations.

AuditPath and similar platforms include access review functionality integrated with your identity provider (Okta, Google Workspace). The quarterly review trigger fires automatically, all decisions are logged in the compliance evidence library, and the completed review is immediately available for auditor access through the audit portal. This eliminates CC6.5 exceptions almost entirely for companies that use the workflow consistently.

Frequently Asked Questions

What happens if we miss a quarterly access review?

Missing a quarterly access review produces an exception on CC6.5 in your SOC 2 report. Depending on the auditor's assessment, it may be a minor noted exception or a more significant finding. The management response should explain why the review was missed and what compensating control or remediation was applied. For first-time audits, one missed review cycle with a credible explanation is unlikely to result in a qualified opinion.

Do service accounts need to be included in access reviews?

Yes — service accounts with access to in-scope systems must be included in access reviews. Service accounts are often overlooked because they're not associated with a named employee. Each service account should have a documented owner, a documented business purpose, and a periodic review confirming it is still needed and its access is still appropriate. Unowned service accounts with persistent access to production systems are a common audit finding.

Can managers approve their own access during a review?

No — self-approval violates the segregation of duties principle. Each user's access must be reviewed and approved by someone other than the user themselves. Typically, access is reviewed by the user's direct manager. For the CEO or CTO (who may have no direct manager to review their access), the board or another designated executive should perform the review.

How far back should access review records go?

You need records for every access review cycle within the observation period being audited. For a 12-month observation period with quarterly reviews, you need four complete review records. For a 6-month first Type II, you need two complete records. Auditors will specifically request access review records from multiple points in the observation period to verify consistent execution.

Is an access review the same as access certification?

The terms are used interchangeably in practice. "Access review" and "access certification" refer to the same process: periodic formal verification that user access is appropriate. Some IAM vendors use "access certification" in their product terminology (SailPoint, Saviynt). The SOC 2 criteria use language about periodic review of access — the specific term you use doesn't matter to auditors.