SOC 2 CC6.1 Evidence Examples: What Auditors Actually Accept

TL;DR

• CC6.1 is the core logical access control in SOC 2. Audit evidence: provisioning tickets, MFA config, access lists, quarterly reviews, termination logs.
• Enterprise-grade auditors sample 25–40 provisioning + 25–40 termination events in a 12-month Type II.
• #1 finding: access review approvals without documented rationale. #2: late termination revocation.

CC6.1 is the single most evidence-heavy control in a SOC 2 audit. Auditors sample more artifacts against CC6.1 than any other Common Criterion, and most audit delays trace back to CC6.1 findings. This guide walks through the specific evidence that clears CC6.1 without follow-up requests, with examples of what passes and what fails.

What CC6.1 Actually Says

The AICPA Trust Services Criteria for CC6.1 (2017, updated 2022) require:

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.

The related points of focus clarify what this means in practice: identify and authenticate users, restrict user access to authorized resources, manage points of access, restrict mobile device access, and identify credentials for infrastructure and software.

In operational terms, CC6.1 asks: who can access what, how do you authenticate them, and how do you prove it?

For the wider context on SOC 2 Common Criteria, see our SOC 2 Type II requirements guide.

The 6 Evidence Categories Auditors Sample

Every Type II auditor works through CC6.1 in roughly the same sequence. The six categories below cover more than 90 percent of evidence requests.

1. User Provisioning Evidence

What auditors want: For each sampled new user, documentation of the provisioning request, approval, and execution.

Passing evidence example:

Jira ticket IT-4873
  Requester: mike.sales@company.com
  Subject: New hire access – Sarah Chen, Sales Development Rep
  Approved by: jen.vp-sales@company.com (manager) on 2026-01-15 10:23 UTC
  Approved by: it-admin@company.com on 2026-01-15 14:05 UTC
  Access granted:
    - Okta group: SDR-Standard
    - Google Workspace: sarah.chen@company.com
    - Salesforce profile: SDR (License: Sales Cloud)
    - Gong license: Yes
    - Production database: No (confirmed by SDR role)
  Executed: 2026-01-15 14:12 UTC by it-admin@company.com

Failing evidence example:

"Sarah was added per standard onboarding." (Slack message)

The second example fails because it lacks approval chain, role-based justification, and executable traceability. Auditors cannot reconcile that Sarah received only the access appropriate to her role.

2. Authentication Configuration

What auditors want: Evidence that authentication mechanisms (password policy, MFA enforcement) are configured in line with your policies.

Passing evidence example:

Screenshot of Okta administrative console showing:

• MFA enforcement policy: "All users, all applications, no exceptions"
• Password policy: minimum 12 characters, complexity required, 90-day rotation, 10-generation history
• Session timeout: 8 hours
• Risk-based authentication: enabled for new devices
• Screenshot dated within the observation period

Supplementary evidence:

A CSV export of user MFA enrollment status showing 100 percent enrollment across all active accounts. Flag any exception (break-glass admin accounts are common legitimate exceptions) with a compensating control description.

3. Access Lists (Current Snapshot)

What auditors want: A current user access list for each in-scope system, mapped to roles.

Passing evidence example:

For each in-scope system (production AWS, Okta, GitHub, Salesforce, the customer database):

• CSV export of users, roles, and access levels
• Timestamp and extraction method (manual export, API query, GRC platform pull)
• Validation that every active user is a current employee or approved contractor

Common gotcha: Service accounts and API credentials. Auditors ask about non-human accounts. Maintain a documented inventory of service accounts with their purpose, owner, credential rotation schedule, and privilege scope.

4. Role-Based Access Control Implementation

What auditors want: Evidence that access is granted based on documented roles, not ad-hoc individual grants.

Passing evidence example:

A role matrix document mapping each job function to its standard access:

Role	Okta Group	AWS Access	GitHub Teams
Software Engineer (L3)	Eng-Standard	dev-account: PowerUser; prod: ReadOnly	engineering
Senior Engineer (L4+)	Eng-Senior	dev-account: PowerUser; prod: Deployer	engineering, oncall
SRE	Eng-SRE	dev-account: AdminAccess; prod: Admin	engineering, sre
Sales Rep	Sales-Standard	None	None

Plus evidence that new hires were added to the role-appropriate group, not manually granted individual permissions.

5. Periodic Access Reviews

What auditors want: Evidence of quarterly (or more frequent) access reviews with documented decisions.

Passing evidence example:

• Review cadence documented in policy (e.g., "Quarterly access reviews for all production systems and customer data stores")
• Review execution record for each quarter in scope:
  • Date review was initiated
  • Reviewer (manager, data owner)
  • System reviewed
  • List of accounts examined
  • Decision per account: Approved / Revoked / Modified
  • Rationale for revocations and modifications
  • Evidence of actual revocation (ticket ID, log entry)

Failing evidence example:

"All access reviewed and approved by managers in Q1." (Email from compliance manager)

This fails because there is no per-account decision, no reviewer attestation, and no evidence of revocations that the review identified.

Passing evidence format (quarterly report):

Access Review — Q1 2026
Review Period: 2026-01-01 through 2026-03-31
Systems Reviewed: AWS (prod), Okta, GitHub, Customer DB
Total Accounts Reviewed: 287
Decisions:
  - Approved: 269
  - Revoked: 14
  - Modified: 4
Revocations (with rationale):
  - user1@company.com: Terminated 2026-01-18; access should have been revoked at termination. Revoked 2026-03-22 (90-day gap identified). Incident logged as IR-2026-008.
  - user2@company.com: Role change 2026-02-04; legacy access no longer required. Revoked 2026-03-22.
  [...additional entries...]
Corrective Actions:
  - IR-2026-008 opened to investigate gap in termination workflow.
Approved by: CTO / CISO
Date: 2026-04-05

6. Termination Evidence

What auditors want: For each sampled termination, documentation that access was revoked within the required window (typically 24 hours for production; 48 hours for internal tools).

Passing evidence example:

HR notification: 2026-02-10 09:00 UTC – Employee X termination effective 2026-02-10
Offboarding ticket: IT-5421
  Automated workflow triggered by BambooHR → Okta deprovisioning
  Okta: All app access revoked at 2026-02-10 09:04 UTC
  AWS IAM user: deleted 2026-02-10 09:06 UTC
  GitHub: removed from all organizations at 2026-02-10 09:08 UTC
  Laptop retrieval: ticketed, completed 2026-02-12
Close-out: 2026-02-12 15:00 UTC, confirmed by IT manager
Elapsed time from HR notification to full revocation: 8 minutes

Common CC6.1 Findings

From dozens of SOC 2 engagements, here are the findings that recur.

Late termination revocation. Terminated employees with production access revoked more than 24 hours after termination notice. This is a material finding if it happened more than twice in the observation period.

Access review without documented decisions. Reviewer "approved all" without per-account analysis. Re-run the review with per-account rationale before Stage 2 if possible.

Missing MFA for break-glass accounts. Legitimate break-glass accounts exist but lack compensating controls (offline token in safe, two-person rule, monitored alerting on use).

Service accounts without owners. Auditor asks who owns a service account and no one can answer. Build a service account inventory with owners before the audit.

Role drift. An engineer transfers from product to data engineering but retains old product access. Access reviews should catch role-change drift quarterly.

Shadow access via shared accounts. Multiple users sharing a single credential. This almost always fails CC6.1 — auditors require individually attributable access.

Evidence Collection Cadence

CC6.1 evidence collection should be continuous, not pre-audit. Recommended cadence:

Evidence	Cadence	Owner
Provisioning tickets	Real-time	IT / Engineering
MFA configuration screenshots	Monthly	Security
Access list exports	Monthly or automated	Security / Platform
Access reviews	Quarterly	Data owners
Termination workflow logs	Real-time	HR → IT
Service account inventory	Quarterly audit	Platform team

For the full set of SOC 2 evidence requirements by control family, see our SOC 2 evidence checklist.

Automating CC6.1 Evidence

Most of CC6.1 can be automated with the right platform stack:

• GRC platforms (Vanta, Drata, Secureframe) pull MFA status, access lists, and provisioning events from integrations.
• Okta / Google Workspace / Microsoft Entra provide authentication configuration evidence via API.
• HRIS integrations (BambooHR, Rippling, Gusto) trigger deprovisioning workflows that produce termination timeline evidence.
• Access review platforms (Opal, Sym, native in GRC tools) generate per-account review records.

What remains manual: the rationale for revocation decisions, the service account owner tagging, and the root-cause analysis when the review identifies late termination or role drift.

For a broader view of what to automate vs. what requires human judgment, see our compliance automation guide.

Preparing for CC6.1 Audit Testing

Two weeks before Stage 2 fieldwork, pull a CC6.1 evidence index:

1. List every in-scope system with its access control mechanism (SSO app, local auth, API keys)
2. For each system, note the MFA enforcement status and capture a screenshot
3. Export current access lists
4. Compile the last four quarters of access reviews into a single binder
5. Pull the last 50 provisioning events and last 50 terminations from HRIS/ITSM
6. Cross-reference terminations against access lists to confirm no orphan accounts
7. Document service accounts with owners

Auditors measure operational maturity by how quickly you retrieve this evidence. Teams that can produce the index within 2 hours typically clear CC6.1 testing in the first fieldwork session. Teams that scramble lose 3 to 5 days of audit timeline.

Getting Started

CC6.1 is not optional and not automatable end-to-end. It requires both technical controls (authentication, role-based access) and operational discipline (reviews, terminations, documentation).

For teams that want CC6.1 evidence engineered into their workflow from day one — with automation where it pays off and human judgment where it matters — CertifyOps delivers SOC 2 programs that close CC6.1 without findings.