SOC 2 — Service Organization Control 2 (AICPA TSC 2017)

Scope: service organizations that hold or process customer data. Issued by AICPA; the criteria are the Trust Services Criteria (TSC) 2017 with 2022 Points of Focus update.

SOC 2 is the most common AXON compliance tag — most adopter deployments carry compliance: [SOC2] as a baseline, layered with HIPAA / PCI_DSS / SOX / GDPR for the regulated subsystems.

The five TSC

TSC	Code	Mandatory?	Scope
Security	CC	✓	All engagements — Common Criteria CC1–CC9
Availability	A	optional	Uptime, capacity, resilience
Processing Integrity	PI	optional	Data is complete + valid + accurate
Confidentiality	C	optional	Information designated confidential is protected
Privacy	P	optional	Personal information per AICPA privacy principles

The Common Criteria (CC) are always included. An engagement opts into A / PI / C / P based on what the service offers.

Declaring SOC2

type CustomerProfile compliance [SOC2] {
    email: String,
    company: String,
    plan_tier: PlanTier
}

axonstore Customers
    compliance: [SOC2]
    backend: postgresql
    isolation: serializable
    encryption: at_rest
    retention: 7y

axonendpoint UpdateCustomer {
    flow: UpdateCustomerFlow
    method: PUT
    route: "/v1/customers/{id}"
    compliance: [SOC2]
}

What the compiler enforces statically

TSC	AXON enforcement
CC2.1 — communication of policies	Out of scope (process).
CC5.1–5.3 — control activities	A SOC2-tagged axonendpoint requires an auth: field; the type checker rejects SOC2-tagged endpoints with auth: anonymous.
CC6.1 — logical access	A SOC2-tagged axonstore requires an isolation: setting (read_committed / repeatable_read / serializable).
CC6.6 — transmission security	A SOC2-tagged socket rejects ws://; only wss:// is accepted.
CC6.7 — cryptographic protection	A SOC2-tagged axonstore requires encryption: at_rest.
CC7.2 — system monitoring	A SOC2-tagged deployment requires the v2.0.0 observability layer to be enabled (verified at deploy, not at parse).
PI1.4 — input validation	A SOC2-PI-tagged axonendpoint whose body type has where refinements gets the v2.0.0 D4 body schema validation; non-PI SOC2 endpoints get it too if they declare it.
C1.1 — confidentiality	A SOC2-C-tagged type cannot leak through an axonendpoint whose compliance: list omits SOC2-C, unless passed through a shield with strategy: pattern over confidentiality markers.

What the runtime enforces

TSC	AXON runtime enforcement
CC4.1 — monitoring	Every emission to a SOC2-tagged endpoint emits an audit row; uptime + error-rate metrics flow to the v2.0.0 observability layer.
CC6.2 — user authentication	The v2.0.0 auth layer enforces token signature + expiry + audience; SOC2 endpoints log every auth outcome.
CC7.1 — security events	The audit chain records every authentication failure, every authorisation denial, every shield breach with category: security_event.
CC7.4 — incident response	Structured incident records flow to the compliance event store; the IR playbook consumes them.
A1.1 — availability commitments	The runtime exposes axon_uptime_seconds + axon_inflight_requests; SLO breach triggers structured alerts.
PI1.3 — processing integrity	The v2.0.0 D4 body validation + D5 output validation + audit chain together provide the integrity evidence.
C1.2 — disposal of confidential information	Purge operations on SOC2-tagged stores emit session:disposal_evidence rows.

What you still attest manually

• Type I vs. Type II report — Type I is design at a point in time; Type II is operational effectiveness over 6+ months.
• Auditor selection + scope of the engagement.
• Trust Service criteria selection (CC always; A/PI/C/P optional).
• Vendor due diligence (CC9.2) for every subprocessor.
• Risk assessment (CC3.1–3.4).
• Security policy documentation.
• Disaster recovery + business continuity plans.
• Background checks + access reviews (CC1.4, CC6.3).

Common patterns

Pattern 1 — Baseline SOC2-CC

The only annotation: every customer-facing API + every internal data store carries compliance: [SOC2]. There is no per-criterion label — SOC2 is one class, and which of the five TSC your report covers is a property of the engagement, not of the program text.

What the label does is make the boundary-coverage rule apply: a type carrying compliance [SOC2] may not cross an axonendpoint unless that endpoint declares a shield: whose own compliance: covers SOC2 (axon-T957). The label is the claim; the shield is the control. It does not, by itself, require auth:, choose an isolation level, or turn on encryption — those are fields you declare, and the auditor reads them.

Pattern 2 — evidence for the Availability (A) criterion

There is no SOC2_A class. The Availability criterion is not a different framework — it is one of the five categories an AICPA engagement may include — so what you declare is SOC2, and the evidence for A is the commitment itself:

axonendpoint ServeContent {
    flow: ContentFlow
    method: GET
    route: "/v1/content/{id}"
    compliance: [SOC2]
    sla: { p99: 200ms, uptime: 99.9% }
}

The sla: field (an enterprise extension) declares the Availability commitment. The observability layer compares live measurements + emits structured breach events to the audit chain when the commitment is missed. That measured breach record is what an A engagement asks for; a label spelling would have asserted the same thing without producing it.

Pattern 3 — evidence for the Privacy (P) criterion

Likewise there is no SOC2_P. AICPA's privacy principles are a category of a SOC 2 engagement, and they are not the same obligation as GDPR — that one is a separate class, because it is a separate law with its own data subjects:

type CustomerProfile compliance [SOC2, GDPR] {
    email: String,
    consent_record: ConsentRef
}

Both classes must be covered: the shield on any boundary this type crosses lists SOC2 and GDPR. Coverage is reflexive — the compiler will not infer that one implies the other.

When NOT to use SOC2

• Public-facing static content with no customer data.
• Internal-only tooling that never touches customer data.
• One-off scripts outside the audited service.

For most production AXON programs, compliance: [SOC2] should be present as a baseline alongside any framework-specific tag (HIPAA, PCI_DSS, GDPR, SOX, …). The SOC2 audit consumes the evidence packager output.