How to Run a SOC 2 Access Review: Step-by-Step

Why Access Reviews Matter for SOC 2

SOC 2 CC6.2 requires that access to information assets is restricted to authorised users, processes, and devices. CC6.3 requires that access is removed or modified in a timely manner when employees change roles or leave. Periodic access reviews are the mechanism for ensuring these criteria are met.

Access reviews are one of the most commonly tested controls in SOC 2 Type II audits. Auditors will select samples from throughout the observation period and verify that reviews were completed on schedule, changes were made as documented, and terminated employees were removed promptly.

What Systems to Review

At minimum, your access review should cover: AWS IAM (user accounts, role assignments, access keys), GitHub (repository access, team memberships, admin roles), Okta or your SSO provider (active users, group memberships, admin access), production databases (user accounts and permissions), and any SaaS tools with access to sensitive customer data.

Prioritise systems based on sensitivity: production infrastructure and databases first, then customer-facing systems, then internal tools. A tiered approach is acceptable — quarterly reviews for high-sensitivity systems, semi-annual for lower-sensitivity tools.

Step-by-Step Process

Step 1: Export user lists. Pull current user lists from each system in scope. For AWS: use the IAM credential report. For GitHub: export members via the admin UI. For Okta: export active users from the admin console.

Step 2: Cross-reference against HR. Compare the active user list against your current employee list. Flag: former employees (should have been removed), contractors whose engagements ended, and users with excessive privileges.

Step 3: Make decisions and act. For each flagged user: confirm the appropriate access level, remove or modify access as needed, and document the decision.

Step 4: Document completion. Record: review date, reviewer name, systems reviewed, number of users reviewed, changes made (if any), and sign-off by the reviewer. Store this as SOC 2 evidence.

Automating Evidence Collection

Compliance automation tools like AuditPath can pull user lists from AWS, GitHub, and Okta automatically and flag discrepancies — reducing the data collection phase from hours to minutes. The human review and decision-making step cannot be automated, but the data gathering can.

For AWS: configure AWS Config to record IAM changes. Set up CloudWatch Events to alert when IAM users are created or when admin policies are attached. Use Security Hub to flag users without MFA — these should appear in your access review.

Handling Terminated Employees

Terminated employee access removal is almost universally tested by SOC 2 auditors. They will select 2–5 terminated employees from your HR system and check whether access was removed from all systems within your documented timeframe.

Best practice: revoke access on the last day of employment or at the time of termination notice. Use SSO (Okta, Google Workspace) to centralise this — disabling an SSO account should cascade access removal to connected applications.

Document each termination: employee name (or anonymised ID), termination date, access revocation date, systems from which access was removed, and who performed the removal.

Documentation for Auditors

Auditors will request: your access review policy (defining frequency and scope), completed access review records for the observation period, and evidence of any access changes made as a result of reviews.

A simple spreadsheet with columns: Review Date, Reviewer, System, Users Reviewed, Changes Made, and Sign-Off is sufficient. Upload each quarterly review to your compliance tool as evidence against CC6.2 and CC6.3.

Do not combine multiple access reviews into one document — keep each review period separate. Auditors need to see a consistent pattern of reviews throughout the observation period, not a single comprehensive review done right before the audit.