> ## 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 1

> When SaaS handling financial data needs SOC 1 in addition to or instead of SOC 2 — and how Codex evidences ICFR controls for financial reporting.

SOC 1 is the AICPA report focused on **internal controls over financial reporting (ICFR)** at a service organization. It's distinct from SOC 2 (security) and applies when your SaaS is part of your customers' financial reporting chain.

## Do you need SOC 1?

You probably need SOC 1 if your customers ask for it during procurement OR if any of these apply:

* **Payroll processing** — your SaaS issues paychecks, W-2s, 1099s
* **Billing and invoicing** — your SaaS generates invoices customers post to GL
* **Payment processing** — your SaaS settles payments to customer bank accounts
* **Accounting / GL automation** — your SaaS posts journal entries
* **Inventory / supply chain valuation** — your SaaS assigns costs that flow into inventory accounts
* **Time-and-attendance** — your SaaS produces timesheet data that drives payroll calc

Pure data tools (analytics, monitoring, internal collaboration) typically don't need SOC 1. Layer doesn't need SOC 1 — Codex doesn't either. But if you sell to F500 finance teams, expect to be asked.

## SOC 1 Type I vs Type II

|                     | Type I                                     | Type II                                                               |
| ------------------- | ------------------------------------------ | --------------------------------------------------------------------- |
| **What it covers**  | Controls designed correctly *as of a date* | Controls operated effectively *over a period* (typically 6-12 months) |
| **Customer demand** | Acceptable for first-time engagement       | Required by SOX-regulated customers (almost everyone)                 |
| **Effort**          | 6-8 weeks                                  | 6-12 months observation + 6-8 weeks audit                             |

SOX 404 (the public-company internal-controls regime) makes Type II non-negotiable for serving public-company customers. Public customers need to rely on your SOC 1 Type II to satisfy their own SOX 404 obligations.

## SOC 1 vs SOC 2 — overlap and distinction

|                              | SOC 1                                                                                    | SOC 2                                                                  |
| ---------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Focus**                    | Financial reporting accuracy                                                             | Security, availability, confidentiality, processing integrity, privacy |
| **Audience**                 | Customer's CFO + external auditor (for SOX 404 reliance)                                 | Customer's CISO + procurement                                          |
| **Common controls**          | Access management, change management, computer operations                                | Access management, change management, system operations                |
| **Differentiating controls** | Transaction processing accuracy, completeness, timing; data integrity in financial flows | Encryption, EDR, vulnerability management, incident response           |

There's significant overlap — about 40% of controls map directly. Codex tracks both frameworks in parallel without duplicate work.

## Codex's role for SOC 1

Codex doesn't perform the audit (your CPA firm does that), but it provides the evidence the auditor will request for IT General Controls (ITGCs) — the five-question framework auditors use to evaluate the IT environment supporting your application:

### 1. Logical access (most evidence here)

| Question                                      | Codex evidence                                                        |
| --------------------------------------------- | --------------------------------------------------------------------- |
| Who has access to the system?                 | IdP user list with last activity                                      |
| What can they do?                             | Per-user role + permission set                                        |
| Were users provisioned with manager approval? | Provisioning event logs with approver identity                        |
| Are terminated users removed timely?          | HRIS termination → IdP deactivation timestamp diff                    |
| Are access reviews conducted?                 | Quarterly access review snapshots with reviewer + approval timestamps |

### 2. Change management

| Question                                    | Codex evidence                                                           |
| ------------------------------------------- | ------------------------------------------------------------------------ |
| Are code changes reviewed?                  | GitHub/GitLab PR review records with reviewer, comments, merge timestamp |
| Are changes tested before production?       | CI status records (tests passed) per merge                               |
| Is there a separation between dev and prod? | Cloud account/project isolation evidence                                 |
| Are emergency changes documented?           | Hotfix branch records + retroactive review evidence                      |

### 3. Computer operations

| Question                            | Codex evidence                                      |
| ----------------------------------- | --------------------------------------------------- |
| Are jobs scheduled and monitored?   | Cron + workflow execution logs from cloud connector |
| Are failures detected and resolved? | PagerDuty / on-call ticket history with MTTR        |
| Are backups taken and tested?       | Backup snapshot history + restore-test logs         |

### 4. Data integrity

| Question                                  | Codex evidence (largely manual at SOC 1 level)       |
| ----------------------------------------- | ---------------------------------------------------- |
| Are interfaces between systems validated? | Mostly manual — reconciliation reports, error queues |
| Are exception reports reviewed?           | Linked dashboards / log queries + review records     |

### 5. Information security

Mirrors SOC 2 CC6/CC7 controls. Codex's SOC 2 evidence covers this.

## What auditors specifically look for in SOC 1

* **Population completeness** — when the auditor samples a control (e.g. "show me 25 PR review records"), Codex's audit log must demonstrate the sample is from the complete population, not cherry-picked.
* **Control owner identification** — every control needs a named owner. Codex tracks the assignee per control.
* **Independent review** — controls performed by the same person who created the work being controlled don't satisfy ITGCs. Codex flags self-approving PRs and similar self-reviews as exceptions.
* **Period coverage** — the Type II observation window must show every control operated continuously. Codex's continuous evidence collection makes this trivial; the gap is documented in the SOC 1 if a control was added partway through the period.

## When you're ready

**Reports → SOC 1 evidence package** outputs:

* ITGC evidence per category with timestamps
* Population completeness samples (random samples auditor can verify against full data)
* Exception register (controls that didn't operate; documented justification)
* Bridge letter template (used between Type II audit periods to extend reliance)

Most SOC 1 auditors accept Codex packages directly; some require evidence in their own portal — Codex CSV export covers that.