SOC 2 evidence catalog

This page lists the highest-traffic SOC 2 Common Criteria controls and the exact evidence Codex collects for each. Use it during audit prep to predict what your auditor will see.

CC6 — Logical and Physical Access Controls

CC6.1 — Logical access provisioning

Source	API call	Refresh cadence
Google Workspace	`admin.directory.users.list` (filter on `creationTime` since last sync)	Every 6 hours
Microsoft Entra ID	`/v1.0/users?$filter=createdDateTime ge {since}`	Every 6 hours
Okta	`/api/v1/logs?filter=eventType eq "user.lifecycle.create"`	Every 6 hours
BambooHR (HRIS)	`/api/gateway.php/{company}/v1/employees/directory` (correlate hire date)	Daily

When an HRIS connector is wired, Codex correlates the HRIS hire-date record to the IdP provisioning event so auditors see the full chain: HRIS hire → IdP provisioning → app assignments. Evidence shape per provisioning event:

{
  "user_id": "string",
  "email": "string",
  "created_at": "ISO timestamp",
  "created_by": "string (admin email)",
  "source": "google_workspace | microsoft_entra_id | okta | bamboohr_hris",
  "evidence_url": "deep link into the source admin console"
}

What auditors verify: every provisioning event has a documented business reason. Codex links to the corresponding HRIS new-hire record so the chain is “HRIS hire → IdP provisioning → app assignments” with timestamps showing each step happened in the right order.

CC6.2 — User access reviews

Codex generates a quarterly access-review snapshot:

Per user: list of apps assigned, role within each app, last activity date
Per app: list of users with access, broken down by role
Diff vs previous review: who was added, removed, or changed roles

Reviewers (typically managers) get a Codex link to approve or flag each user. The auditor sees the completed review with reviewer identity + timestamp + decisions.

CC6.3 — Role-based access enforcement

Source	Evidence	Refresh cadence
Okta	Per-app role assignments via SCIM	Every 6 hours
GitHub	Org admin + team membership inventory	Every 6 hours
Slack	Workspace admin + role inventory	Daily

Source data:

IdP role assignments per app (via SCIM or app-specific API)
Per-app admin/owner/member counts
Privileged-access reports (admin role count by app, with named users)

Auditors look for: separation of duties (e.g. the same person isn’t dev + ops + finance admin) and least privilege (e.g. fewer admins than members).

CC6.6 — Logical access removal on termination

The control most companies fail. Codex measures the gap between HRIS termination and IdP deactivation.

Source	Evidence	Refresh cadence
BambooHR (HRIS)	Termination event timestamp	Every 6 hours
Rippling (HRIS)	Termination event timestamp	Every 6 hours
Gusto (HRIS)	Termination event timestamp	Every 6 hours
Deel (HRIS)	Termination event timestamp	Every 6 hours
Okta	User deactivation timestamp (correlate to termination)	Every 6 hours
Google Workspace	User suspension timestamp	Every 6 hours
Microsoft Entra ID	`accountEnabled=false` timestamp	Every 6 hours

Termination event: 2026-04-15 17:00 UTC (HRIS: BambooHR)
IdP deactivation: 2026-04-15 17:08 UTC (Google Workspace)
Gap: 8 minutes ✓ (under 24h SLA)

For an auditor, this is the killer evidence: a real timestamp diff per terminated employee proving the SLA holds. Codex also flags any termination where IdP deactivation didn’t happen within 24h — those become exceptions you have to remediate before audit.

CC6.7 — Encryption at rest

Asset class	Source	Evidence
Endpoints	MDM (Jamf, Kandji, JumpCloud, Intune)	Per-device disk encryption status (FileVault for Mac, BitLocker for Windows)
Cloud storage	AWS	S3 bucket encryption configs (SSE-S3, SSE-KMS, or SSE-C)
Cloud storage	GCP	GCS bucket encryption config + CMEK keys
Cloud storage	Azure	Storage account encryption + CMK config
Databases	RDS / Cloud SQL / Cosmos DB	Per-instance encryption + KMS key reference

Codex polls these daily and flags any unencrypted resource as a material exception.

CC6.8 — Endpoint protection

Source	Evidence
MDM	EDR/antivirus install status, OS patch level vs latest, screen lock policy
CrowdStrike / SentinelOne	Per-host EDR coverage + last check-in time

CC7 — System Operations

CC7.1 — Vulnerability management

Vulnerability discovered: 2026-04-12 (GitHub Dependabot)
Severity: High (CVE-2024-XXXXX)
Affected repo: api-gateway
First triaged: 2026-04-12 (PR #2143 opened)
Resolved: 2026-04-13 (PR merged + deployed)
SLA window: <30 days for High ✓

Codex tracks:

All findings from Snyk, Wiz, CrowdStrike, Dependabot, GHAS
Time to triage + time to remediate per severity
SLA compliance rates (% of High findings resolved within 30d, etc.)

CC7.2 — Security event detection

Source data: SIEM connector events (Datadog, Splunk, Sumo, New Relic). Codex pulls:

Event volume per category (auth failures, anomalous logins, privilege escalations)
Alert rules configured + last fired
Coverage gaps (event sources NOT being collected)

CC7.3 — Incident response

Per-incident evidence:

Incident: PagerDuty #INC-2025-1234
Severity: SEV-2
Detected: 2026-04-15 03:14 UTC (alert: api-gateway p99 latency > 5s)
Acknowledged: 2026-04-15 03:16 UTC (oncall: alice@axiomancer.io)
Resolved: 2026-04-15 04:42 UTC
Post-mortem: linked to Notion page (auto-detected via incident note)

CC7.4 — Recovery from incidents

Source	Evidence
AWS Backup	Snapshot history per resource (RDS, EBS, EFS), retention config
GCP	Cloud Storage versioning + Cloud SQL backups
Azure	Recovery Services Vault snapshots
Manual	Restore-test results (you upload, Codex stores with timestamp + tester identity)

Auditors specifically want to see restore tests. Codex sends quarterly reminders to your backup owner to test a restore and upload the result.

CC8 — Change Management

CC8.1 — Change authorization

PR #2143 (api-gateway)
Author: bob@axiomancer.io
Reviewers: alice@axiomancer.io (approved), charlie@axiomancer.io (approved)
Merged: 2026-04-13 14:32 UTC
Required reviewers: 2 ✓
Branch protection: enforced on main ✓

Codex pulls every merged PR from connected code hosts (GitHub, GitLab) and verifies:

Required reviewers met
Branch protection rules enforced (no direct pushes to main)
CI passed before merge

What this catalog isn’t

This isn’t the complete list — it’s the controls that drive 80% of audit attention. Other CC controls (CC1-5 governance, CC9 risk mitigation) are mostly policy + process, not auto-evidenceable. See the SOC 2 framework guide for the full mapping.

Get started

Frameworks

Reference

CC6 — Logical and Physical Access Controls

CC6.1 — Logical access provisioning

CC6.2 — User access reviews

CC6.3 — Role-based access enforcement

CC6.6 — Logical access removal on termination

CC6.7 — Encryption at rest

CC6.8 — Endpoint protection

CC7 — System Operations

CC7.1 — Vulnerability management

CC7.2 — Security event detection

CC7.3 — Incident response

CC7.4 — Recovery from incidents

CC8 — Change Management

CC8.1 — Change authorization

What this catalog isn’t

​CC6 — Logical and Physical Access Controls

​CC6.1 — Logical access provisioning

​CC6.2 — User access reviews

​CC6.3 — Role-based access enforcement

​CC6.6 — Logical access removal on termination

​CC6.7 — Encryption at rest

​CC6.8 — Endpoint protection

​CC7 — System Operations

​CC7.1 — Vulnerability management

​CC7.2 — Security event detection

​CC7.3 — Incident response

​CC7.4 — Recovery from incidents

​CC8 — Change Management

​CC8.1 — Change authorization

​What this catalog isn’t

CC6 — Logical and Physical Access Controls

CC6.1 — Logical access provisioning

CC6.2 — User access reviews

CC6.3 — Role-based access enforcement

CC6.6 — Logical access removal on termination

CC6.7 — Encryption at rest

CC6.8 — Endpoint protection

CC7 — System Operations

CC7.1 — Vulnerability management

CC7.2 — Security event detection

CC7.3 — Incident response

CC7.4 — Recovery from incidents

CC8 — Change Management

CC8.1 — Change authorization

What this catalog isn’t