SOC 2 CC6.2 Evidence Guide: User Provisioning, Deprovisioning, and Access Reviews

SOC 2 Control CC6.2 is notoriously difficult because it requires continuous evidence collection throughout the audit period, not just a one-time check. While many GRC tools automate evidence for Identity Providers (IdPs) like Okta or Google Workspace, they often fail to capture the necessary screenshots and documentation for internal admin panels, legacy applications, and tools that don't support SCIM provisioning. To pass CC6.2, you need verifiable evidence that users are authorized, removed promptly upon termination, and reviewed quarterly. Automating SOC 2 evidence collection for these manual workflows is the only way to scale compliance without drowning in administrative work.

What Does SOC 2 CC6.2 Actually Require?

At its core, Common Criteria 6.2 states: "Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized."

In practice, auditors break this down into three distinct evidence buckets:

1. Provisioning (New Hires): Proving that access was requested and approved before it was granted.
2. Deprovisioning (Terminations): Proving that access was revoked within your SLA window (usually 24 hours) after an employee left.
3. User Access Reviews (UAR): Proving that you periodically checked user lists to ensure access remains appropriate.

If you miss evidence in any of these three areas, you risk a rigorous exception in your report.

What Evidence Do Auditors Need for User Provisioning?

For new user access, auditors look for a "ticket-to-system" match. They will select a sample of new hires from your population list and ask for the following evidence pack for each:

1. The Access Request Ticket: A screenshot or PDF of the Jira, Linear, or ServiceNow ticket showing the request.
2. The Approval: Visual proof that a manager or system owner explicitly approved the request (e.g., a comment, a "thumbs up" on Slack if policy allows, or a formal approval workflow status).
3. The System Creation Timestamp: A screenshot from the application showing when the user account was created.

The Auditor's Test: They compare the Approval Date on the ticket with the Creation Date in the system. If the account was created before the approval, you fail the control.

How Do You Prove Access Revocation for Terminated Employees?

Deprovisioning is the most common source of SOC 2 exceptions. Auditors will pull a list of all employees terminated during the audit period and select a sample (often 5-25 depending on population size).

For every sampled termination, you must provide:

1. HR Termination Record: Evidence showing the official termination date and time.
2. Revocation Ticket: The IT ticket requesting access removal.
3. System Evidence of Inactivity: This is where most teams struggle. You need a screenshot from the specific application (not just Okta) showing:
   • The user's status is "Inactive" or "Suspended."
   • OR: The user is no longer in the active user list.
   • OR: A "Last Login" timestamp that is before the termination date.

How Do You Perform a User Access Review (UAR) for Non-SSO Apps?

User access reviews (UARs) are the heavy lift of CC6.2. Quarterly or semi-annually, you must validate that every user with access to sensitive systems still requires that access.

For systems integrated with your IdP (like AWS via Okta), this is easy. But for systems that don't support SSO—like custom back-office dashboards, database direct access, or legacy finance tools—you must perform a manual review.

The Manual UAR Checklist for Compliance

To achieve UAR compliance for these standalone systems, follow this workflow:

1. Generate the Population: Take a screenshot of the full user list from the application settings page. Ensure the screenshot includes the URL, date, and visible permissions (e.g., "Admin" vs. "Read-Only").
2. External Review: Export this list to a spreadsheet or review tool.
3. The Review Action: A manager must mark each user as "Keep" or "Revoke."
4. The Evidence Artifact: You must save the final reviewed sheet and the original screenshot. The screenshot proves the spreadsheet wasn't doctored.

If you only provide a spreadsheet, a strict auditor may reject it as "Information Provided by the Entity" (IPE) without source validation. The screenshot acts as your source validation.

Where Traditional SOC 2 Automation Stops

Most GRC platforms claim to automate user access reviews, but there is a significant gap between what they promise and what they deliver for non-standard applications.

Feature	GRC Platform (Drata/Vanta)	Real-World Requirement
IdP Integration	Automates UARs for Okta/Google Workspace apps.	Great for SaaS, useless for internal tools.
Custom Apps	Requires you to manually upload a CSV.	You still have to log in, scrape the data, and format it.
Evidence Validation	Trusts the CSV you upload.	Auditors require a screenshot to validate the CSV data (IPE).
Deprovisioning	Checks if the Okta account is suspended.	Doesn't verify if the local account on the admin panel was removed.

The reality is that traditional automation stops at the API. If your "God Mode" admin panel doesn't have a SCIM API, GRC tools can't see it. You are left manually taking screenshots of user lists every quarter.

How Can You Automate Evidence for Internal Tools?

For applications without APIs, modern compliance teams use browser-based automation agents to capture evidence. Instead of assigning an engineer to "log in and screenshot the user list" every quarter, an automated workflow can:

1. Log in to the internal admin panel using a read-only service account.
2. Navigate to the user management page.
3. Capture a full-page screenshot, ensuring the URL and system time are visible.
4. Extract the text (via OCR or DOM parsing) to create the user list CSV for the review.
5. Package the screenshot and CSV into a timestamped evidence pack.

This approach satisfies the rigorous "Completeness and Accuracy" requirements of SOC 2 because the evidence is generated by a system, not manually curated by a human who could alter the data.

Common CC6.2 Audit Failures to Avoid

Even with good intentions, teams fail CC6.2 due to specific evidence gaps. Watch out for these common pitfalls:

• The "Ghost" Account: An employee is terminated in HR and Okta, but their account remains active in a developer tool (like Sentry or a production database) for weeks.
• Missing Approval Tickets: You have the screenshot of the user created, but you can't find the Slack message or Jira ticket approving it.
• Role Change Evidence: An employee moves from Sales to Engineering. They get new access, but their old sales access isn't revoked. This violates the principle of least privilege.
• Cropped Screenshots: Submitting a screenshot of a user list that cuts off the URL bar or the date. Auditors cannot accept evidence without context.

Learn More About SOC 2 Compliance Automation

For a complete guide to automating SOC 2 compliance, including how to handle complex application-level controls and screenshot requirements, see our guide on automating SOC 2 evidence collection in 2025. You may also find these relevant:

• Do You Actually Need a vCISO for SOC 2? - Why AI is replacing the $10k/month consultant
• The Bootstrapped Founder's Guide to SOC 2 - How to get SOC 2 done without a massive budget