> ## Documentation Index
> Fetch the complete documentation index at: https://docs.axiomancer.io/llms.txt
> Use this file to discover all available pages before exploring further.

# SOC 2 evidence catalog

> Per-control evidence Codex pulls for SOC 2 from your connected IdP, MDM, code host, and cloud, with the exact API call, cadence, and what auditors check.

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:

```json theme={null}
{
  "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](/codex/soc2) for the full mapping.