The Architectural Problem With Compliance-as-a-Service

A major compliance automation platform was just exposed for allegedly fabricating audit evidence at scale. 493 of 494 SOC 2 reports contained the same typo. 259 Type II audits all claimed zero incidents. Pre-written conclusions were generated before any control was tested. If you’re an engineer at a company that relies on a compliance vendor, this should bother you — not just ethically, but architecturally. The separation-of-concerns problem In software engineering, we understand that the component producing data should not also be the component validating it. You don’t let a service write its own health checks and also be the only thing reading them. Compliance frameworks have the same requirement. AICPA AT-C Section 205 mandates that the entity helping you implement controls cannot also produce the audit conclusions about those controls. This isn’t bureaucratic overhead. It’s the same separation of concerns we apply to every distributed system. The platform in question broke this fun