Type I vs Type II
| Type I | Type II | |
|---|---|---|
| What it proves | Controls are designed correctly as of a point in time | Controls operated effectively over a period (typically 6-12 months) |
| Audit timeline | 4-8 weeks | 6-12 months observation window + 4-8 weeks audit |
| Customer demand | Acceptable for first-time vendors | Required by most enterprise procurement |
| Codex effort | A few weeks of setup | Same setup, then continuous monitoring during the observation window |
How Codex maps the Common Criteria (CC) controls
The 2017 (TSC 2017) and 2022 update (Trust Services Criteria 2017 — Revised May 2022) define ~60 Common Criteria controls. Codex auto-evidences the majority:CC6 — Logical and Physical Access Controls (the heavy lifting)
| Control | Evidence Codex pulls |
|---|---|
| CC6.1 — Logical access provisioning | IdP user creation logs (Google Workspace, Okta, Entra ID), MDM device assignment records |
| CC6.2 — User access review | Quarterly diff of who has access to what, exported from IdP + per-app assignments |
| CC6.3 — Role-based access | App-level role assignments from connected SaaS (Slack admin role, GitHub team membership, etc.) |
| CC6.6 — Logical access removal on termination | HRIS termination event → IdP deactivation timestamp diff (proves <24h SLA) |
| CC6.7 — Encryption at rest | MDM disk encryption status (FileVault for Mac, BitLocker for Windows), cloud-storage encryption config |
| CC6.8 — Endpoint protection | MDM-reported antivirus/EDR status, OS patch level, screen lock policy |
CC7 — System Operations
| Control | Evidence |
|---|---|
| CC7.1 — Vulnerability management | GitHub Dependabot alerts + Snyk/Wiz/CrowdStrike findings + remediation timelines |
| CC7.2 — Security event detection | SIEM connector events (Datadog, Splunk, Sumo Logic), suspicious-login alerts from IdP |
| CC7.3 — Incident response | Incident tickets from PagerDuty/Linear/Jira with start/end timestamps, severity, post-mortem links |
| CC7.4 — Recovery from incidents | Backup snapshots from cloud connectors (AWS Backup, GCP, Azure), restore-test logs |
CC8 — Change Management
| Control | Evidence |
|---|---|
| CC8.1 — Change authorization | GitHub/GitLab PR review records + approver identity + merge timestamps |
CC1-CC5 — Governance, risk assessment, communication
These are mostly policy + training + role definitions — Codex links to your Notion/Confluence pages and tracks training completion via the LMS connector.What Codex can’t auto-evidence (you assign humans)
- CC1.1 — Code of conduct: link to your published code of conduct
- CC2.2 — Internal/external communication: link to your security page + customer comms templates
- CC3.1 — Risk identification process: link to your risk register and quarterly review minutes
- CC9 — Risk mitigation: vendor due diligence questionnaires (Codex stores them; humans complete them)
- A1.1 — Availability commitments: SLAs and uptime monitoring contracts
Recommended setup order
- Day 1: Sign up, pick SOC 2 (Common Criteria), connect Google Workspace or M365 (covers ~30% of CC6 controls instantly)
- Day 1-3: Connect MDM (Jamf/Kandji/Intune). Covers CC6.7, CC6.8 — disk encryption, endpoint protection. ~20% more.
- Day 3-7: Connect GitHub or GitLab. Covers CC8.1 (change management). ~10% more.
- Week 2: Connect ticketing (Jira/Linear) and on-call (PagerDuty). Covers CC7.3, CC7.4. ~15% more.
- Week 2: Connect cloud (AWS/GCP/Azure). Covers CC7.1 partial (infrastructure CVEs), CC6.7 cloud encryption. ~10% more.
- Week 3-4: Assign humans to the remaining 15-20% (policy, risk, training, vendor mgmt).
When you’re ready for the auditor
Reports → SOC 2 evidence package generates a single PDF + folder of CSVs with:- Every CC control, status, evidence sources, last-verified timestamp
- Per-control evidence snapshots (with API call timestamps)
- Exception list (controls marked “exception” with documented justification)
- Ownership matrix (who is responsible for each non-auto-evidenced control)