The compliance-as-code pitch is clean. Stop chasing screenshots, encode the rules in machine-readable policy, run them in CI/CD, and let the policy engine produce the audit artefact as a side effect of the build. Every cloud-security vendor with a marketing team has sold this since at least 2023. The Wiz Academy explainer from April 2026 is a representative version of the genre — definitional, benefit-focused, light on what the engineering actually looks like.
The engineering reality is less tidy. Most organisations claiming compliance-as-code are running Open Policy Agent in advisory mode, surface a Rego library on GitHub, and still produce the audit evidence by hand. The library exists. It is not enforced at deploy. The auditor still asks for a screenshot. The differentiator between organisations that have shipped compliance-as-code and organisations that have bought the marketing is not the policy library. It is the evidence pipeline.
Key takeaways
- Compliance-as-code claims fail in four predictable places: policies run in audit-only mode, drift alerts fire into a queue nobody reads, the CI override is two clicks and engineers click it weekly, and the auditor still wants screenshots because the policy run output is not in a form they can query.
- Enforcement has to land at five layers — pre-commit, CI gate, admission control, runtime, and evidence generation. Most programmes cover one or two.
- Four tool stacks ship in production: OPA + Rego (most flexible, steepest curve), Kyverno (Kubernetes-native, lightest syntax), Cedar (AWS-aligned, authorisation-shaped), and cloud-native admission (AWS Config + SCPs, Azure Policy, GCP Org Policy — free, less expressive). Each has a clear best-fit layer.
- The hard part is the evidence pipeline, not the policy library. Auditors accept compliance-as-code in place of screenshots when output is structured, queryable, tamper-evident, and queryable by audit period — the pattern that ships is S3 partitioned by date and control, indexed in Lake Formation, queried through Athena.
- Override discipline is the second hard part. Every override is a ticket with a sunset date and a named owner. Override volume is the leading indicator of policy quality — high counts mean the policy is wrong, not that engineers are reckless.
The Pitch and the Reality
The compliance-as-code promise fits on a slide. Pick your controls — SOC 2 CC6.1, ISO 27001 A.8.9, the relevant Article 9 paragraphs of the EU AI Act, the NIS2 risk-management measures — express them as policy code, run them in your pipeline, and produce machine-readable evidence the controls operated. Replace the screenshot. Replace the quarter where two engineers stop building product and write evidence narratives.
What most teams ship is narrower. A Rego library lives in a repository called policy. CI runs it in audit-only mode and posts a comment on the PR. The library never blocks a deploy because nobody is confident enough in policy quality to make it blocking. When the audit arrives, the team produces a slide deck summarising what the policy would have caught if it had been enforced. This is not policy-as-code. It is a library. The gap between the two is where every honest compliance-as-code conversation lives.
The Five Layers Where Enforcement Actually Has to Land
Compliance-as-code is a chain of controls, each at a different layer, each with a different blast radius if it misses. Programmes that work cover all five. Programmes that fail cover one or two and call the rest "future scope."
Pre-commit is the first layer. Conftest runs against the developer's local Terraform plan output, Helm values, or raw YAML. The point is not to block — hooks are easy to skip — but to surface the violation in the editor, not in PR review three days later.
The CI gate is where blocking happens. Checkov against Terraform and Kubernetes manifests with a published rule library. Trivy IaC across the same surfaces with a different library. Conftest running your custom Rego against any structured input. The gate fires before merge. If it is advisory-only, you do not have compliance-as-code at this layer — you have a comment generator.
Admission control intercepts every apply before it lands in etcd. The mature options are Kyverno, OPA Gatekeeper, and Kubernetes' native Validating Admission Policy (stable from 1.31). Admission control catches the deploy that bypassed CI through a manual kubectl apply. It is the only layer that observes actual cluster state, not proposed state. Programmes that skip it discover at the worst possible moment that the CI gate did not cover the operations team's emergency-fix workflow.
Runtime catches the drift between policy and reality. Configuration the admission controller approved last week may have drifted. A pod that started compliant may have been exec'd into and modified. Falco watches the syscall stream. CSPM tools — Wiz, Prisma Cloud, Defender for Cloud, the open-source alternatives — continuously evaluate the cloud resources, not the manifests that produced them.
Evidence generation is the fifth layer and the one that fails silently. Each of the other four emits a result. The result has to land somewhere structured, queryable, and tamper-evident. If the auditor cannot self-serve queries against the policy run history, the history is not evidence — it is data that needs a person to convert into evidence, which is the screenshot economy by another name.
Most programmes we audit cover CI well and the others poorly. The pattern that works covers all five with one source-of-truth policy at each layer. Pre-commit runs the same Rego as CI. CI's pass becomes a precondition for the admission controller's allow. The admission decision lands in the same evidence store as the runtime monitor's alerts. One source of policy, five enforcement surfaces, one evidence pipeline.
The Four Tool Stacks That Actually Work
Vendor pitches make every tool sound interchangeable. They are not.
OPA with Rego is the most flexible and the steepest learning curve. It fits anywhere the input is structured JSON and the decision is allow/deny/require-approval: Kubernetes admission through Gatekeeper, microservice authorisation through the OPA sidecar, agent action approval, Conftest-driven IaC checks, Envoy external authz. The downside is real — Rego policies that survive the first month and fail the third are usually written by an engineer who treated it as Python.
Kyverno is the Kubernetes-native option. The syntax is YAML, the same shape operators already think in. Policies look like the resources they govern; the learning curve is hours, not weeks; Kyverno does mutation as well as validation, which Gatekeeper does not. It fits Kubernetes-only enforcement surfaces. Outside the cluster it does not — teams that adopt Kyverno for admission usually adopt OPA separately for the rest.
Cedar, open-sourced from AWS in 2023, is the policy language behind AWS Verified Permissions. It is designed around authorisation specifically — principals, actions, resources, conditions — narrower than Rego but easier to reason about for the use case it targets. It fits application-layer authorisation in AWS-aligned stacks. It does not yet fit the broader compliance-as-code surface; the IaC-scanning ecosystem is still Rego-shaped.
Cloud-native admission is the option people forget to evaluate. AWS Config rules, Service Control Policies, GCP Organisation Policy, Azure Policy — every major cloud has a built-in engine that runs against the control plane and is free with the cloud. Less expressive than OPA or Kyverno, in proprietary languages with their own quirks, and they do not extend to Kubernetes cleanly. For organisation-wide invariants — "no public S3 buckets in this organisation, ever" — they are sometimes the right answer because they cannot be bypassed by anyone with console access.
Pick the tool that fits the layer. Cloud-native admission for organisation-level guardrails. OPA for cross-cutting policy. Kyverno for Kubernetes cluster policy. Cedar for application-layer authorisation in AWS-native stacks. Pretending one tool fits every layer is the failure mode that produces the marketing-grade library.
The Honest Failure Modes
Four patterns recur in audits of organisations that claim compliance-as-code.
"We have a Rego policy library" usually means the library was written for a conference talk and never made the transition into the CI gate as a blocking control. It runs in audit-only mode and the team has learned to scroll past the comments. The library is real. The enforcement is not.
"Compliance evidence is automated" usually means the policy enforces configuration but the auditor still asks for a screenshot, because the policy run output is in a structured-log format the auditor cannot query. The screenshot economy persists because the team built a library and not a pipeline.
"Drift detection is in place" usually means a CSPM tool fires alerts into the same queue as 50 other cloud findings. On-call marks low-severity items acknowledged, and drift in non-production ages out at 30 days. Detection works. Response does not.
"Policy as code is in CI" sometimes means the override is two clicks — a PR label, an environment variable, a Slack-bot approval. Engineers click it weekly because the policy is wrong often enough that working around it is faster than waiting for a fix. High override volume is the leading indicator that policy quality is the problem. The closed-loop fix is to count overrides, treat them as bug reports against the policy, and require a sunset date on every accepted one.
A clean library with these gaps still produces the failing audit. The maturity of compliance-as-code is how the organisation closes these gaps, not the policy language it adopted.
The Pattern That Actually Delivers
The version that works in production has four properties.
Single source of policy truth. A git repository holds the Rego (or Cedar, or Kyverno YAML — pick one per layer) with tests, change-management metadata, and signed tags. Every enforcement point pulls from this repository. When the policy changes, it changes once, and the change reaches every layer through signed bundle distribution.
Layered enforcement. The same policy is enforced at every meaningful layer. "Production databases must have encryption at rest" runs as a Terraform plan check at pre-commit, a Checkov rule in CI, an admission controller rule when the CRD is applied, and a CSPM evaluation against the running RDS instance. One layer is one bypass away from a violation; four layers is meaningfully harder.
Evidence pipeline. Every policy run, at every layer, emits a structured record into an evidence store. The default we ship is S3 — partitioned by date and control ID, with object-lock enabled — fed into Lake Formation for schema management and exposed through Athena. The auditor receives a workgroup, saved queries against the audit period, and the ability to self-serve evidence for every sampled control.
Override discipline. Overrides happen. The mature pattern is not to forbid them; it is to make them visible, accountable, and time-bound. Every override is a ticket with a named owner, a justification, and a sunset date. Override count per policy is a metric. A policy with high override count is a candidate for revision, not stricter enforcement. Without it, layered enforcement rots within three months.
The Regulatory Tailwind
The reason this matters in 2026 is that the regulators are leaning into it. SOC 2 auditors are increasingly willing to accept compliance-as-code output as evidence in place of screenshots, provided the output is structured, queryable, and tamper-evident — which is what the evidence pipeline above produces. The EU AI Act's Article 11 documentation requirements for high-risk systems effectively demand machine-readable evidence of conformity. NIS2's risk-management and incident-reporting obligations are easier to evidence with policy-as-code output than with manual records.
The regulator is not asking for OPA by name. The regulator is asking for evidence you can produce reliably, repeatedly, from a system that has not been edited since the audit period ended. The compliance-as-code stack we have just described produces evidence in that shape as a side effect of operating. The screenshot stack does not. A 200-line Rego library that produces queryable, tamper-evident evidence over the full audit period is worth more than a 2,000-line library that emits log lines into CloudWatch and nothing else.
What Most Teams Are Missing
Teams that have invested in the policy library typically have the right tools — OPA or Kyverno in the stack, Checkov in CI, Falco in the cluster — and the wrong outputs. The policy fires. The decision is logged. The log lands in CloudWatch or Datadog or the SIEM, in a form designed for security operations, not audit response. When the audit arrives, the team builds a one-off query, exports to a spreadsheet, screenshots it, and sends it to the auditor. The compliance-as-code programme is, at audit time, a screenshot factory with extra steps.
The pattern that closes the gap: policy run output, at every layer, archived in S3 under a key scheme that maps to the control framework. SOC 2 CC6.1 evidence under evidence/soc2/cc6.1/year=2026/month=06/day=22/. ISO 27001 A.8.9 under evidence/iso27001/a.8.9/.... The Glue catalogue indexes the schemas. Athena queries the partition. Lake Formation governs access. The auditor receives an Athena workgroup and a query template per sampled control. Sixty minutes, not three weeks.
This is the part that does not show up in vendor pitches because nobody is selling it as a product. It is integration work — the engagement where the compliance team and the data team sit in the same room for two days and design the evidence schemas together. It is also the part that determines whether the audit is a query exercise or a reconstruction exercise.
What This Teaches Us About Enterprise Scaling
Compliance-as-code is one of the few practices where the engineering investment and the compliance investment are the same investment. Done correctly, the policy engineer produces the audit evidence; the CI gate engineer produces the change-control record; the CSPM analyst produces the continuous-monitoring evidence. Same people, same systems, same outputs, repurposed for two audiences without the duplication screenshot-driven compliance produces.
Done incorrectly, the programme is an extra system on top of the screenshot stack. The library exists. The screenshots still happen. The engineering investment was wasted because it did not displace the manual evidence work.
The differentiator is not the language, the engine, or the framework. It is whether the auditor sees structured, queryable evidence in sixty minutes or waits three weeks for someone to reconstruct it. The policy library is the table stake. The evidence pipeline is the moat. Most claims of compliance-as-code stop at the table stake.
FAQs
What is the honest test for "do we actually have compliance-as-code"?
Four questions. Does at least one policy block a deploy in CI, not just comment on it? Does an admission controller catch the deploy that bypasses CI? Is the policy run output in a structured store the auditor can query without a person in the middle? Are overrides tracked as tickets with sunset dates and named owners? Two or fewer yeses means the programme is a library, not policy-as-code in production.
OPA or Kyverno?
Kyverno if the enforcement surface is exclusively Kubernetes and the team thinks in YAML. OPA if there are policy surfaces outside Kubernetes — microservice authorisation, IaC scanning through Conftest, agent action approval, Envoy external authz. Most mature programmes run both, because they target different layers and the integration cost of running both is lower than the expressiveness cost of forcing one to do both jobs.
Where does Cedar fit in 2026?
Application-layer authorisation, particularly in AWS-aligned stacks where AWS Verified Permissions handles the heavy lifting. Cedar is purpose-built for principals, actions, resources, and conditions. It does not yet have the ecosystem reach to displace OPA at the IaC-scanning or Kubernetes-admission layers. Use Cedar where you would otherwise hand-roll an authorisation service. Do not use it as a general-purpose compliance-as-code engine yet.
Why is the evidence pipeline harder than the policy library?
The library is one team, one repository, a finite set of rules. The pipeline crosses team boundaries: the control framework (compliance), evidence schemas (audit), storage layer and access controls (data), integration at each enforcement layer (security engineering). Each policy run has to land in the right partition with the right schema, and the access control has to satisfy both engineering and audit reviewers. The library is built by one engineer in a quarter. The pipeline is a cross-functional programme.
Will auditors actually accept Athena queries as evidence?
Increasingly yes. The criterion auditors apply is whether evidence is structured, attributable to a control, dated, and tamper-evident. S3 with object-lock covers tamper-evidence; partitioning by date and control ID covers attribution and dating; Athena covers structured-and-queryable. The auditor still wants the methodology documented — what the policy says, how it runs, where output lands, how access to the evidence store is governed. With that document, queryable evidence has replaced the screenshot at every audit we have closed in 2026.
Companion Content
- OPA for AI Agent Action Approval — the policy-as-code primitive applied to the agent surface
- SOC 2 for AI Deployments: The Trust Service Criteria Reread for the Model Era — the compliance framing this article extends
- SLSA Levels in Practice: What Organisations Actually Enforce — the supply-chain analogue: what reaches production versus what stays on the slide
- The AI Act's August 2026 Enforcement Deadline — the regulatory tailwind for machine-readable conformity evidence
- AI Bill of Materials: SBOM for AI Systems — the evidence shape for the AI surface specifically
How to engage
If your compliance-as-code programme is a policy library and the audit still produces three weeks of screenshots, the gap is the evidence pipeline, not the library. We design and ship the S3-and-Athena evidence stack that turns audit response into a query exercise, integrate it with the enforcement layers you already run, and leave behind the schemas, the queries, and the runbooks that make it sustainable. Talk to us at creativeminds.dev/contact.