Skip to main content
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

SourceAPI callRefresh cadence
Google Workspaceadmin.directory.users.list (filter on creationTime since last sync)Every 6 hours
Microsoft 365/v1.0/users?$filter=createdDateTime ge {since}Every 6 hours
Okta/api/v1/logs?filter=eventType eq "user.lifecycle.create"Every 6 hours
Evidence shape per provisioning event: 
{
  "user_id": "string",
  "email": "string",
  "created_at": "ISO timestamp",
  "created_by": "string (admin email)",
  "source": "google_workspace | microsoft_365 | okta",
  "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 (when an HRIS connector is wired) 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 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: 
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 classSourceEvidence
EndpointsMDM (Jamf, Kandji, Intune)Per-device disk encryption status (FileVault for Mac, BitLocker for Windows)
Cloud storageAWSS3 bucket encryption configs (SSE-S3, SSE-KMS, or SSE-C)
Cloud storageGCPGCS bucket encryption config + CMEK keys
Cloud storageAzureStorage account encryption + CMK config
DatabasesRDS / Cloud SQL / Cosmos DBPer-instance encryption + KMS key reference
Codex polls these daily and flags any unencrypted resource as a material exception.

​
CC6.8 — Endpoint protection

SourceEvidence
MDMEDR/antivirus install status, OS patch level vs latest, screen lock policy
CrowdStrike / SentinelOnePer-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

SourceEvidence
AWS BackupSnapshot history per resource (RDS, EBS, EFS), retention config
GCPCloud Storage versioning + Cloud SQL backups
AzureRecovery Services Vault snapshots
ManualRestore-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.