Compliance as Code: From Audit Documents to Continuous Automated Evidence

Compliance as code turns regulatory requirements into version-controlled, machine-readable policies evaluated continuously. How it works, the tools, the frameworks it evidences, and the honest caveats for security leaders.

Every compliance programme eventually hits the same wall: the controls are documented, the policies are approved, but proving they actually hold — continuously, across a growing cloud estate — is manual, slow and full of gaps. Compliance as code (CaC) is the response. It treats regulatory and security requirements the same way infrastructure is treated under Infrastructure as Code (IaC): as version-controlled, machine-readable, testable code that is evaluated automatically and continuously.

What Compliance as Code Actually Is

Compliance as code is the practice of expressing security and compliance requirements as declarative, machine-readable policies — typically in a repository alongside the application and infrastructure code they govern — and then automatically testing infrastructure, configurations and workloads against those policies. Where a traditional audit produces a point-in-time snapshot assembled by hand, compliance as code produces a continuous, evidence-backed view that is updated with every code change.

It builds on two closely related practices. Policy as code encodes the rules themselves as software that can be evaluated programmatically. Continuous compliance is the operational goal: monitoring, validating and remediating against those rules on an ongoing basis rather than at an annual audit.

Why It Is Gaining Momentum Now

  • Cloud and IaC adoption — when infrastructure is defined in Terraform, CloudFormation or Kubernetes manifests, the configuration is already structured data that policies can evaluate. Auditing that same estate manually ignores the automation that built it.
  • Regulatory timelines — the EU AI Act (Regulation (EU) 2024/1689), the first comprehensive legal framework for AI, phases in obligations from February 2025 (prohibited practices), August 2025 (general-purpose AI), August 2026 (transparency rules) through to December 2027 (high-risk systems). Regulators increasingly expect continuous evidence, not annual spreadsheets.
  • Faster, more frequent change — CI/CD pipelines deploy continuously; a point-in-time control test is stale the moment it is written. Controls must be evaluated in the pipeline, at runtime, and on the deployed estate.

Core Concepts

ConceptWhat It Means
Policy as codeRules written in a declarative language (e.g. Rego, HCL) that a policy engine can evaluate against structured data.
Shift-left controlsPolicy checks run in CI/CD on every commit, blocking non-compliant infrastructure before it is deployed.
Continuous evidenceEvery evaluation, finding and remediation is logged and retained, forming an audit trail that is always current.
Drift detectionAutomated comparison of the intended configuration (the code) against what actually exists, flagging manual changes that break compliance.
GitOpsGit as the single source of truth; tools such as Argo CD and Flux (both CNCF-graduated) reconcile the live environment to the declared state.
Evidence as codeControl attestations, test results and evaluation output are treated as code artefacts, versioned and reproducible.

How It Works in Practice

A typical compliance-as-code pipeline has four layers:

  1. Policy definition — controls from frameworks such as NIST CSF 2.0 (published February 2024), NIST SP 800-53, CIS Benchmarks, SOC 2, ISO/IEC 27001:2022 or PCI DSS v4.0 are translated into machine-readable rules.
  2. Static and plan-time scanning — open-source IaC scanners such as Checkov, tfsec, Terrascan and KICS evaluate Terraform and CloudFormation before deployment; policy engines such as Open Policy Agent (OPA) can validate Terraform plans.
  3. Cloud-native enforcement — managed services evaluate the live estate: AWS Config and AWS Security Hub, Azure Policy, and Google Cloud's policy and security posture tooling. Open-source tools such as Prowler (CIS-based AWS assessments) and Cloud Custodian (a Capital One open-source project) add policy-driven remediation.
  4. Runtime and pipeline gates — OPA, a CNCF-graduated project whose policies are written in Rego, can enforce decisions in Kubernetes admission control, as an Envoy external authorizer, in API gateways and in CI/CD pipelines. HashiCorp Sentinel provides policy-as-code within Terraform Enterprise and Cloud.

What It Enables

  • Audit readiness on demand — evidence is collected continuously, so responding to an auditor is a report generation task, not a months-long exercise.
  • Consistency at scale — the same policy applies identically across accounts, regions and teams, eliminating the variance of manual review.
  • Faster change without risk — non-compliant configurations are caught in the pipeline, before they reach production.
  • Defensible, machine-generated evidence — evaluations and remediations are logged with timestamps and versions, reducing reliance on human attestation.
  • Lower cost of control — automation replaces recurring manual evidence gathering across hundreds of checks.

The Honest Caveats

Compliance as code is a powerful enabler, not a silver bullet. A policy only checks what it is written to check; automated evidence proves that a control was applied, not that every obligation in a regulation has been met. Teams can over-index on technical controls while neglecting governance, risk acceptance and human judgement. Tool sprawl is a real risk — policies spread across multiple engines become as hard to maintain as the spreadsheets they replaced. And like all code, policies themselves need review, testing and change management; a policy is only as trustworthy as its own test suite and review process.

Getting Started

  1. Start with the highest-risk, most-automatable controls — e.g. CIS benchmark items and cloud configuration baselines — rather than trying to encode an entire framework at once.
  2. Map controls to code — create an explicit traceability matrix linking each control to the policy that enforces and evidences it.
  3. Adopt a policy engine and scanner — begin with OPA/Rego or the managed policy service of your cloud, plus an IaC scanner in CI/CD.
  4. Build the pipeline gate — fail non-compliant plans in CI, then add runtime monitoring and drift detection.
  5. Treat policies as software — version them, test them, review them, and make their results visible to both engineering and audit.

Compliance as Code and the AI Agenda

For security leaders, the emerging frontier is AI governance. As the EU AI Act's obligations phase in through 2026 and 2027, organisations will need to evidence logging, transparency, human oversight and risk management for AI systems. The same pattern applies: encode AI governance requirements as policies, evaluate them against the AI stack, and collect evidence continuously. An AI gateway — the control plane between applications and model providers — is a natural enforcement and evidence point, generating the audit trail that compliance-as-code pipelines can consume. The principle is unchanged: turn requirements into code, and let the code prove itself continuously.

Source: DeyLabs Security Intelligence