Policy-as-code as the control plane your auditors will actually read

A control framework written in English and a Conftest policy that fails a deployment are the same idea expressed in two different registers. The English version goes in the policy library and gets read by the auditor on engagement. The code version runs every time someone tries to deploy and produces evidence by existing. Most regulated organisations have the first and not the second, and most of their audit cost is the consequence of that gap.

Policy-as-code is not a new idea — Open Policy Agent has been around for the better part of a decade — but the case for it is stronger now because three things have converged. Cloud-native deployments are uniformly Kubernetes-shaped, which has a native admission controller integration point. CI/CD pipelines have stable hook surfaces. And generative AI is making the cost of authoring policies measurably lower, which removes the historical objection that “we cannot find someone to write Rego.”

The pragmatic adoption pattern looks like this.

Start with the deployment gate, not the network policy. Most teams begin with the most ambitious application — service mesh policy enforcement — and stall in implementation complexity. The much higher-leverage starting point is the deployment pipeline. A Conftest step in the pipeline that checks the manifest against a small set of policies — no privileged containers, no host network, no latest tag, resource limits set, allowed image registries only — catches a meaningful fraction of operational risk and produces a pipeline log that is the audit evidence. Five policies in a week, no admission controller, no production change.

Phrase policies as control objectives, not as implementation rules. The policy file should read like the control register. “All container images deployed to production must come from the approved registry” is a control objective. The Rego implementation that checks the registry hostname is the mechanism. When the framework changes — and it will — you change the mechanism, not the control. This separation is what makes policy-as-code maintainable across team turnover.

Tier the policies by enforcement level. Some policies should fail the build, some should warn, some should annotate. Treat this as part of the policy itself, not as a runtime configuration. A tag of enforce: hard in the policy file means deployment cannot proceed without exception. enforce: soft means a warning is logged and the deployment proceeds. enforce: audit means the violation is recorded but no action is taken. This gives platform engineering a smooth glide path for new policies — introduce as audit, promote to soft after a sprint, promote to hard after a month — without surprising the developer audience.

Wire the violations to the security data lake. Every policy decision — pass, fail, warning — should flow to your SIEM or equivalent. Two reasons: the audit reconstruction question (“show me every production deployment in the last quarter and which policies it satisfied”) becomes a query rather than a manual search, and the security team gains visibility into which policies are catching what, which informs what to add next. The most useful conversation we have with platform engineering teams is reviewing the previous quarter’s policy violations and deciding which to upgrade, retire, or add.

The audit conversation transforms from “show me the evidence that this control was applied” to “show me the policy that enforces this control, the deployment log that ran it, and the SIEM record of any exceptions.” Three artefacts, each machine-generated, each unambiguous. We have walked auditors through this conversation in three engagements and the response has uniformly been delight, which is not a word I expected to use about audit interactions.

The objection most CISOs raise is that policy-as-code requires platform engineering capability they do not have. In practice, the technical bar is lower than feared — Rego is a few weeks of investment, the tooling is mature, and AI assistance has made the policy authoring round-trip faster. The harder problem is organisational: getting platform engineering to own the control plane and getting the security function to express requirements as testable policies rather than English statements. That is a quarter of conversation, but it is a quarter that pays back permanently.