SOC 2 Access Control Evidence Checklist for Engineering Teams

Why Access Control Evidence Is the Hardest Part of SOC 2

SOC 2 Type II audits examine controls over a period — typically 6 to 12 months. For access control, the auditor is not asking whether your policy document says the right things. They are asking whether you can prove, with timestamped artifacts, that access was granted appropriately, reviewed periodically, revoked when no longer needed, and monitored during use. This is the CC6 family of Common Criteria controls, and it is where most engineering teams struggle.

The problem is rarely a lack of controls. Teams have SSO, MFA, RBAC policies, and access request workflows. The problem is that the evidence of those controls operating correctly is scattered across five or six different systems, none of which produce the export format an auditor expects. The result is a quarterly scramble: screenshots of Okta group memberships, spreadsheets of who accessed what, manual reconciliation of active users against HR records, and a prayer that nothing was missed.

The CC6 Control Family: What Auditors Actually Evaluate

The CC6 family covers logical and physical access controls. For engineering teams, the relevant controls focus on logical access. Each control maps to a specific evidence expectation. Understanding this mapping is the first step toward automating your evidence collection.

Evidence Categories: What You Need for Each Control

1. Identity Evidence (CC6.1, CC6.2)

Auditors want to see a complete, current inventory of every identity that can access your systems. This means a list of users with their authentication method, MFA status, last login date, and the IdP group they belong to. They also want proof that credentials are managed properly: password policies, certificate rotation, and token expiration settings.

• Complete user inventory with IdP sync status
• MFA enrollment percentage and enforcement policy
• SSO configuration showing IdP integration
• Credential lifecycle: issuance, rotation, expiration rules
• Service account inventory with last-used dates

2. Authorization Evidence (CC6.3)

This is where most teams fail. Auditors ask for a role-to-user mapping that shows the principle of least privilege in practice. They want to see that engineers have access only to what their role requires, that production access is restricted, and that privileged roles (admin, root, cluster-admin) are limited to a documented set of people with a business justification.

3. Provisioning and Revocation Evidence (CC6.4)

Auditors test both ends of the access lifecycle. They pick a sample of new hires and verify that access was granted through an approved process. They pick a sample of terminated employees and verify that all access was removed within a defined time window. The clock matters: if your policy says access is revoked within 24 hours but the audit log shows a 72-hour gap, that is a finding.

4. Session Monitoring Evidence (CC6.5)

CC6.5 requires accountability — evidence that credential usage is tracked. For infrastructure access, this means session logs that show who connected, to which resource, when, for how long, and what they did. Session recordings are the gold standard: they provide immutable, replayable proof that ties every action to an identity.

• SSH session recordings with command transcripts
• Database query logs tied to human identities
• Kubernetes exec session recordings
• RDP/VNC visual recordings for Windows administration
• Immutable storage with tamper-proof retention

5. Access Review Evidence (CC6.3, CC6.4)

Periodic access reviews are a SOC 2 staple. Auditors expect to see that someone with appropriate authority reviewed who has access to what, certified or revoked each assignment, and documented exceptions. The review must happen at a defined frequency (quarterly is standard for most organizations) and must cover all systems in scope.

For a deeper treatment of access review evidence, see our dedicated guide: What Auditors Actually Ask For in User Access Reviews.

What Auditors Request vs. What Teams Usually Have

Building Continuous Evidence vs. Quarterly Scramble

The difference between teams that breeze through audits and teams that dread them is not the strength of their controls — it is whether evidence collection is continuous or periodic. Continuous evidence means that every access event, every session, every approval, and every revocation is logged as it happens and stored in a queryable, exportable format. When the auditor asks a question, the answer is a report that takes seconds to generate.

The quarterly scramble happens when evidence lives in multiple systems and nobody owns the aggregation. Someone has to log into Okta, export the user list, cross-reference it with the HR system, check AWS IAM for direct access, verify Kubernetes RBAC bindings, and merge it all into a spreadsheet. This process takes 40+ hours per audit cycle and is inherently error-prone.

Session Recording as Proof

Session recordings are the single most powerful evidence artifact for CC6.5 compliance. They provide an immutable, replayable record of exactly what happened during a privileged session. When an auditor asks “how do you monitor privileged access,” a session recording demo is worth more than any policy document.

Recordings also serve as proof during incident response. If a production database was modified during a specific time window, the recording shows exactly which commands were executed, by whom, and whether the change was authorized. This is evidence that log analysis alone cannot provide with the same level of fidelity.

JIT Approval as Justification Proof

Just-in-Time access creates a natural evidence trail for CC6.3 (authorization). Every JIT request includes a reason, a time window, and an approval record. The auditor can see that production access was not standing — it was requested with a business justification, approved by an authorized person, and expired automatically after the stated purpose was fulfilled.

This is significantly stronger evidence than static role assignments, which only show that access exists but not why. JIT records answer the “why” question that auditors increasingly ask, especially for production and database access.

Automated Access Reviews

Manual access reviews are error-prone, time-consuming, and tend to produce rubber-stamped approvals. Automated reviews improve both the quality and the evidence. OnePAM’s access review builder generates review campaigns that assign reviewers automatically based on resource ownership, present the current user-role mapping, and require explicit decisions (certify, revoke, or flag for exception) with documented rationale.

The completed review produces a timestamped report showing every decision, every reviewer, and every remediation action. This is exactly the artifact auditors want, and it takes minutes to generate instead of days.

Evidence Checklist by CC6 Control

Getting Started

The best time to start collecting evidence is before the audit window opens. Review the OnePAM Trust Center for our own SOC 2 report and a walkthrough of how we map our platform to CC6 controls. Use the compliance mapper to identify your current evidence gaps, and the access review builder to automate your first review campaign.