The SOC 2 Posture We Ship With: Evidence Collection Before the Auditor Arrives

The standard enterprise approach to SOC 2 is: build the product, then build the compliance program before the audit. The result is a sprint to assemble documentation, retroactively map controls, and convince an auditor that normal operations match the policy you wrote last week.

25 Alpha is built the other way. Compliance posture is architectural, not procedural.

Every platform we operate runs on single-region AWS infrastructure — us-east-1 only. This is not a preference. It is a hard architectural constraint that eliminates an entire class of data residency and sovereignty risk before the first control is even evaluated.

Every secret — API keys, database credentials, signing tokens — lives in AWS Secrets Manager. No credential is ever hardcoded in source code, stored in a committed environment file, or manually entered into a third-party dashboard as a source of record. Rotation is automated. Access is governed by least-privilege IAM policy.

Every deployment passes a four-layer automated compliance scan before it reaches any production environment. The scan checks brand standards, infrastructure region, vendor integration discipline, and security posture. Any violation blocks deployment — this is an automated gate that cannot be bypassed without a logged exception.

The ARCEB append-only audit log runs continuously. Every agent action, every data access, every state change creates a record that cannot be modified or deleted. By the time an auditor arrives, there is a continuous, machine-generated evidence trail covering the full observation period.

SOC 2 Type II observation began on the platform's production launch date. The auditor does not build the program — the auditor verifies that the program that has been running continuously is real.

This is the difference between compliance as a posture and compliance as a sprint.