Compliance as code means expressing your controls, policies and evidence collection as version-controlled artefacts that live beside the systems they govern, so compliance changes go through the same review, testing and deployment path as any other change. In practice that means three things: control definitions in a repository rather than a spreadsheet, evidence produced automatically by pipelines rather than gathered by hand before an audit, and drift detected by a scheduled check rather than discovered during fieldwork. What it does not mean is that the judgements go away — a machine can prove a control ran, but not that it was the right control.
What compliance as code actually means
The phrase borrows from infrastructure as code, and the analogy holds better than most. Before Terraform, infrastructure was a thing you configured by hand in a console, described in a wiki page that was wrong within a month, and rebuilt from memory when it broke. The fix was not better documentation. It was moving the source of truth into a repository, making changes go through review, and having the running system derive from the declared state rather than the other way round.
Compliance has the same shape of problem. The control set lives in a spreadsheet, the evidence lives in a folder of screenshots, and the relationship between them lives in someone's head until three weeks before an audit. Compliance as code moves the source of truth into version control and makes the artefacts derive from the systems they describe.
Concretely, that means control definitions expressed declaratively and reviewed through pull requests, evidence produced as a by-product of pipelines that already run, and a scheduled job that compares declared state against observed state and raises a finding when they diverge.
What you get that a spreadsheet cannot give you
A defensible history
Auditors ask when a control changed and who approved it. A spreadsheet answers with a modification timestamp and a filename. A repository answers with a commit, a diff, a reviewer and a date. That is not a marginal improvement in tidiness — it is the difference between asserting that a control was in place last March and demonstrating it.
Review that already exists
Changing a control becomes a pull request. The people who need to approve it are the people who already approve changes, using a mechanism they already trust. Compliance stops being a parallel process that competes for attention with shipping and becomes part of it.
Evidence with a timestamp
This is the part teams most often get wrong. A SOC 2 Type II examination tests whether controls operated throughout a period, which means the evidence has to have existed during that period. Screenshots assembled the week before fieldwork prove that the control works now. Evidence emitted by a pipeline, with a collection date, proves it worked in March — which is the actual question.
The three practices worth adopting first
- Declare controls in a repository, with an owner, the systems they apply to, and the signal that indicates conformance. Review changes through the normal path.
- Emit evidence from pipelines you already run — CI, deployment, access provisioning — rather than collecting it. If the control runs, the evidence exists.
- Schedule a conformance check per control and route failures to tracked work with an owner, so drift becomes a ticket rather than an audit finding.
None of these requires adopting a framework you do not already have. They are ways of running the frameworks you carry — ISO 27001, SOC 2, NIS2 — with less manual work and a better paper trail.
Where the analogy breaks
Infrastructure as code can be fully declarative because the target state is unambiguous: either the bucket has public access blocked or it does not. Compliance carries judgements that no declaration resolves. Whether a risk is acceptable, whether a lawful basis holds, whether a control is proportionate to the threat — these are decisions with legal weight, and a regulator will ask which person made them.
So the boundary is worth drawing explicitly. Automate discovery, collection and checking. Record judgement, with the person and the date attached. A system that quietly decides a control passes has not automated compliance; it has hidden the decision that mattered.
Where privacy fits
Privacy is where compliance as code pays off hardest, because privacy documentation describes software and software changes constantly. An Article 30 record of processing written by hand is accurate on the day it is written. If instead personal data is annotated where it is defined in code and the register is derived from those annotations, the record changes when the system changes — which is what Article 30 asks for and what manual maintenance structurally cannot deliver.
If you want to see what this looks like against your own repositories and cloud accounts, you can explore it at noru.tech.