Compliance Controls as Code: What It Actually Means

The full executive answer

It means the control and its evidence are the same artefact. Take our most important control, tenant isolation: the policy ("every customer table must have Row Level Security") isn't a paragraph in a policy binder — it's a test file in the repository that scans every database migration and fails the entire build if the policy is violated. The evidence that the control operated isn't a screenshot collected quarterly for an auditor; it's the green CI run on every one of hundreds of commits, timestamped and retained by GitHub. Your compliance team could verify it by reading one test file and one CI history page.

We've organised this deliberately for audit: a control-evidence framework lists each control with its SOC 2 criteria references (CC6.1, CC6.3, C1.1 and so on), its ISO 27001 Annex A references, the implementing code path, and the evidence source. The same pattern covers access control (a declarative role-permission matrix with a test that enforces privilege ordering), change management (nothing reaches production without passing the lint/typecheck/test/build gate — 344 test suites, over 3,500 tests), data retention (a declarative retention policy module that the pruning job reads from, so policy and enforcement can't drift apart), and audit logging (append-only, hash-chained).

Where honesty is due: code can't prove organisational controls — background checks, security training, vendor review cadences are people-processes, and ours are early-stage-thin and being formalised through the SOC 2 readiness engagement starting this quarter. The claim isn't "everything is automated"; it's that the technical control layer produces its own evidence continuously, which typically shortens an audit rather than replacing it.