Detailed Process Page

SOC 2 User Access Review Process

A practical guide to the quarterly access review workflow used to validate user permissions, identify stale access, collect approvals, and produce audit-ready evidence for SOC 2 controls CC6.1 and CC6.2.

Updated • Control family: access control • Core owner: Security Lead

Use this page to understand the access review workflow end to end: what inputs are needed, how the review should run, what evidence auditors expect, and which related processes should be linked into the same control system.

SOC 2 Processes
SOC 2 User Access Review Process
Use this process diagram as a starting point. Customize it for your team, tools, and compliance needs.

Overview

User Access Review is the formal process of periodically validating that user access to systems and data is appropriate, authorized, and aligned with job responsibilities. This quarterly review supports SOC 2 CC6.1 and CC6.2 by ensuring excess, terminated, or inappropriate access is identified and remediated.

Step-by-Step Process

  1. Define review scope

    The Security Lead defines which systems, applications, and user populations are included in the quarterly access review. This includes in-scope identity providers, cloud platforms, and any systems containing customer or sensitive data. The output is a documented review scope for the quarter.

    Role: Security Lead

  2. Generate current access reports

    The Security Lead or delegated Security Analyst exports current user and role/group membership reports from each in-scope system. Reports must reflect access as of the review date and include user identifiers, roles, and last login where available. The output is a set of dated access reports.

    Role: Security Analyst

  3. Distribute access lists to reviewers

    Access reports are distributed to system owners or department managers responsible for approving access. Reviewers are given clear instructions and a deadline to confirm, modify, or revoke access. The output is reviewer acknowledgment and annotated access lists.

    Role: Security Lead

  4. Validate access appropriateness

    Reviewers assess whether each user’s access aligns with current job responsibilities and least privilege principles. Any inappropriate, excessive, or unknown access is flagged for removal or adjustment. The output is a completed review with explicit approval or change requests.

    Role: System Owner

  5. Remediate identified issues

    The Security Lead ensures all approved access changes are implemented, including removing terminated users and reducing excessive privileges. Changes are completed in the relevant systems and tracked to completion. The output is updated system access reflecting approved decisions.

    Role: Security Lead

  6. Document review completion

    The Security Lead documents the review date, participants, findings, and remediation status in a centralized record. Evidence is saved in the compliance repository with clear timestamps. The output is a completed quarterly access review record.

    Role: Security Lead

  7. Retain evidence for audit

    All access reports, approvals, and remediation proof are retained according to the evidence retention policy. Files are labeled with the review period and stored in an audit-ready location. The output is an organized evidence package for SOC 2 audits.

    Role: Security Lead

What You Need Before Starting

  • List of in-scope systems and applications
  • Administrative or read-only audit access to Okta, Google Workspace, AWS IAM, and Azure AD
  • Current employee roster or HR termination report
  • Prior quarter access review record

Evidence Your Auditor Expects

  • Dated Okta user and group export showing access as of the review date
  • Manager-approved access review spreadsheet with signatures or email approvals and timestamps
  • Screenshots or logs showing removal of access for at least one flagged user with date/time
  • Quarterly access review summary document signed by the Security Lead and dated

How This Looks In Your Tools

Okta

Log in to the Okta Admin Console and navigate to Directory > People to export the full user list, then Directory > Groups to capture group memberships. Use the “More Actions > Export” option and ensure the export date is visible in the file metadata.

For role validation, go to Security > Administrators to review assigned admin roles. Save CSV exports and provide them to system owners for review, then implement approved removals directly from the user or group management screens.

Google Workspace

Access the Google Admin console and navigate to Directory > Users to export the current user list using the “Download users” option. Then go to Directory > Groups to capture group memberships tied to application or data access.

For privileged access, review Admin roles under Account > Admin roles. Apply approved changes by removing users from groups or roles and retain screenshots showing the change confirmation and timestamp.

AWS IAM

Log in to the AWS Management Console and navigate to IAM > Users to export user details, including attached policies and groups. Also review IAM > Roles for roles that can be assumed by users or services.

Use IAM Access Analyzer or the “Generate credential report” feature to support the review. Apply approved removals by detaching policies or deleting users, and retain CloudTrail logs or screenshots as evidence.

Azure AD

Sign in to the Azure portal and go to Azure Active Directory > Users to export the user list using “Download users.” Navigate to Azure Active Directory > Groups to capture group-based access assignments.

Review privileged roles under Azure Active Directory > Roles and administrators. Implement approved changes by removing users from roles or groups and save audit log screenshots showing the modification date and actor.

Common Audit Findings

Access reviews not performed quarterly
This occurs when reviews are ad hoc or not tracked against a schedule. Prevent this by maintaining a quarterly compliance calendar and assigning a clear owner responsible for initiation and completion.
Lack of documented reviewer approval
Auditors often find access lists without evidence of manager sign-off. Require explicit approval via signed documents or email responses and store them with timestamps.
Excessive or orphaned access not removed
Findings arise when identified issues are not remediated promptly. Track remediation actions to closure and retain proof of access removal.
Incomplete system coverage
Organizations sometimes exclude key systems like cloud consoles or admin roles. Maintain and review an in-scope system list each quarter to ensure full coverage.

Frequently Asked Questions

What is the goal of a SOC 2 access review?

The goal is to confirm that access rights still match job responsibilities and that stale or excessive permissions are removed on a defined review cadence.

What evidence do auditors expect from access review?

Auditors typically expect the completed review file, dated approvals, screenshots or logs showing access changes, and proof that remediation was completed.

What often goes wrong in this process?

Common problems include missed service accounts, incomplete scope, approvals without evidence trails, privilege creep, and unresolved remediation items.

Related Processes

Key Roles

Security LeadSecurity AnalystSystem Owner
Ready to implement this process? Open the template in Creately and customize it for your team.