Policies as code compliance automates the evaluation and enforcement of governance rules by encoding them into versioned, testable artefacts that run inside your existing pipelines. Instead of manual sign-offs and after-the-fact audits, teams get earlier feedback, less approval friction, and evidence trails that hold up under scrutiny. Done properly, it lets developers self-serve infrastructure without waiting on a compliance team to bless every change.
TL;DR:
- Policy as code enables early feedback and automated enforcement, reducing manual reviews and manual errors in governance processes.
- Teams should start with simple, high-impact policies like blocking public buckets and encrypting data before expanding to more complex rules.
- Using a clear rollout process, including a dry-run period and defined ownership, helps avoid misconfiguration and unwanted enforcement friction.
- Choice of policy engine depends on workload environment, with options including Open Policy Agent for multi-cloud, Kyverno for Kubernetes, and native cloud services for single-cloud setups.
- Maintaining governance discipline, proper documentation, and continuous review is essential for long-term compliance success beyond initial policy implementation.
Table of Contents
- What is policy as code and how does it differ from compliance as code?
- How does policy enforcement actually work?
- How do you implement policy as code from first policy to production?
- Which policy engine should you choose?
- Best practices and the pitfalls that derail most rollouts
- What are real-world use cases for policy as code?
- How AITHEA thinks about policy as code in regulated compliance
- Why policy as code alone won't satisfy your regulator
- Where AITHEA fits alongside your policy-as-code rollout
- Sources
- FAQ
What is policy as code and how does it differ from compliance as code?
Policy as code means writing governance rules (who can create a public storage bucket, which regions are permitted, which encryption standards apply) as executable code rather than as PDF policy documents or spreadsheet checklists. That code lives in a repository, gets reviewed through pull requests, and runs automatically against infrastructure definitions or live resources. HashiCorp's explanation of policy as code frames it as a mechanism that lets teams check compliance in minutes rather than days, cutting the human error that creeps into manual reviews.
It overlaps with infrastructure as code (IaC) but isn't the same thing. IaC (Terraform, Pulumi, CloudFormation) defines what infrastructure should exist. Policy as code defines what's allowed to exist, and it typically evaluates IaC plans before they ever apply. Compliance as code is the broader umbrella: it includes policy as code but also covers control testing, evidence generation, and mapping technical controls back to named frameworks like PCI-DSS or GDPR articles.
Common representation patterns you'll encounter:
- Rego policies evaluated by Open Policy Agent, often against JSON input from Terraform plans or Kubernetes manifests
- Kubernetes-native YAML policies authored for Kyverno or Gatekeeper
- JSON policy definitions for Azure Policy, assigned at subscription or management-group scope
- Sentinel or custom DSLs tied to specific platform vendors
All of these sit in source control alongside the infrastructure they govern, which is the point: a policy change goes through the same review, versioning, and rollback discipline as any application code.
How does policy enforcement actually work?
Every policy-as-code system separates two concerns: the decision point, where a policy engine evaluates input against rules and returns an outcome, and the enforcement point, where that outcome is actually applied. Confusing the two is the most common architectural mistake platform teams make when they first adopt this model.
The decision layer is usually one of a small set of engines. Open Policy Agent uses the Rego language and is genuinely general-purpose. It evaluates almost any structured input, supports offline testing, and integrates cleanly into CI pipelines that need a pass or fail before deployment continues. Kyverno takes a more Kubernetes-native path, expressing policies as YAML rather than a separate language, which lowers the learning curve for teams already fluent in Kubernetes manifests. Azure Policy uses JSON policy definitions with built-in effects (deny, audit, modify, deployIfNotExists) that map directly onto Azure Resource Manager operations.
Inputs vary by enforcement point:
- Plan-time evaluation feeds a Terraform plan (in JSON) to the policy engine before anything is provisioned, catching violations while they're still cheap to fix.
- PR/CI gating runs the same checks automatically on every pull request, blocking a merge rather than a deployment.
- Admission control intercepts requests to a Kubernetes API server or cloud control plane at creation time, rejecting or mutating non-compliant resources on the spot.
- Runtime auditing evaluates resources that already exist, flagging drift or generating remediation tasks rather than blocking anything live.
Outputs mirror this range: a hard deny, a soft audit-only warning, an automatic modification (adding a missing tag, say), or a remediation task queued for follow-up. Which combination you choose determines how much friction developers feel and how much risk you're willing to carry between violation and fix.
How do you implement policy as code from first policy to production?
Rolling out policy as code badly is worse than not rolling it out at all. A policy that blocks a deployment at 2am with no dry-run history and no owner to call generates exactly the kind of shadow-IT workaround compliance teams are trying to eliminate. Here's a rollout sequence that avoids that outcome.
- Inventory your assets and standardise metadata first. Policies rely on consistent tags, labels, and environment identifiers to distinguish production from sandbox resources. Skip this step and policies either over-block legitimate work or silently miss non-compliant resources, because the engine can't tell what it's looking at.
- Pick one high-value, low-complexity policy to start. Denying public storage buckets, requiring encryption at rest, or blocking wide-open security group rules are the classic first candidates: they carry real risk, they're easy to explain to developers, and they rarely generate legitimate exceptions.
- Author the policy in source control, reviewed through the same pull-request process as application code, following the pattern Azure Policy's own concepts guide recommends: definitions live in a repository, changes are tested with enforcement disabled in non-production first.
- Run it in dry-run or advisory mode for at least 30 days. Practitioner guidance on compliance as code is specific on this point: a 30-day advisory window surfaces false positives and edge cases before anyone's deployment gets blocked, and it gives you real data to show sceptical teams.
- Test remediation, not just detection. Confirm that whatever remediation task or auto-fix the policy triggers actually resolves the violation, using environment-level tests rather than assuming the happy path.
- Move through dev, staging, then production, flipping the enforcement toggle progressively rather than everywhere at once, so a bad rule affects the smallest possible blast radius.
- Assign clear deployment permissions and write a rollback playbook before you enable hard enforcement anywhere near production. Someone needs the authority (and the runbook) to disable a policy within minutes if it misfires.
Pro Tip: Treat your first policy as a pilot for your process, not just for the rule itself. If the review, dry-run, and rollback steps work smoothly for one storage-encryption policy, you've built a repeatable path for the next fifty.
Which policy engine should you choose?
The honest answer is: it depends on where your workloads live and how much cross-cloud consistency you need, not which tool has the most GitHub stars.
- Open Policy Agent (OPA) with Rego suits teams that need one engine across multiple clouds, Kubernetes, and CI pipelines. It's genuinely general-purpose, supports offline unit testing, and integrates with tools like Conftest to validate Terraform plan JSON directly inside a pull request, exactly the pattern DoorDash's platform team uses to comment policy violations back on the PR before anything merges.
- Kyverno or Gatekeeper make more sense if your governance surface is almost entirely Kubernetes. Kyverno's YAML-based policies avoid asking application teams to learn a new language, which matters when adoption speed is the bottleneck.
- Azure Policy (or the equivalent native service on another cloud) is the pragmatic default when you're single-cloud and want enforcement wired directly into the platform's own resource manager, with built-in remediation tasks and no separate engine to operate.
Beyond the core engine, a few auxiliary tools decide whether the programme scales:
- Static IaC scanners that catch obvious misconfigurations before a plan is even generated
- Conftest-style plan testing wired into CI/CD, so violations surface as PR comments rather than deployment failures
- Compliance reporting frameworks: Compliance-to-Policy (C2P) bridges OSCAL-format compliance artefacts to native policy engine formats and aggregates results back into OSCAL Assessment Results, which is genuinely useful when auditors want machine-readable evidence rather than a screenshot folder.
Before committing, run through a short selection checklist: can the engine be tested offline without hitting a live cluster, does it produce reporting output your compliance team can actually consume, does it support every cloud you run, and is the policy language something your team can maintain without becoming a bottleneck around one person.
Best practices and the pitfalls that derail most rollouts
Most failed policy-as-code programmes fail for the same handful of reasons, and none of them are technical.
- Coding everything at once. Teams that try to encode fifty policies in month one create fifty sources of developer friction simultaneously, with no way to isolate which rule caused which complaint.
- Skipping metadata standardisation. Pulumi's guidance on policy practice is blunt about this: without consistent tags and labels, policies generate false positives that erode trust faster than any technical failure would.
- No clear ownership. A policy with no named owner drifts out of date with the regulation or architecture it was meant to enforce, and nobody notices until an audit does.
- Enforcing before evidencing. Skipping the advisory period means you enable a hard block with no data on how many legitimate deployments it would have stopped.
Pro Tip: Keep a lightweight policy register, one line per rule, that records the owner, the review cadence, and the date it moved from advisory to enforced. It's the single artefact auditors ask for first, and it costs almost nothing to maintain.
Governance matters as much as the code itself: a defined PR workflow for policy changes, a regular review cadence, and proactive communication with developer teams before a new rule goes live. None of that shows up in a demo, but all of it decides whether the programme survives contact with a real engineering organisation.
What are real-world use cases for policy as code?
Two examples cover most of what platform teams actually encounter.
- Access control: a policy denying public storage buckets runs at plan-time against Terraform JSON, blocking the merge before anything provisions; if a bucket somehow goes public later, a runtime audit policy flags it and queues a remediation task rather than deleting data blind.
- Cost governance: tag enforcement policies reject untagged resources at admission time, while instance-size limit policies stop a developer accidentally provisioning a workload ten times the intended size.
Mapping results to named frameworks turns these checks into audit evidence rather than just guardrails. Community reporting frameworks built on OPA and Rego generate compliance reports mapped to SOX, PCI-DSS, FFIEC and GLBA controls, turning a pass/fail policy result into a line item an auditor can trace back to a specific control requirement.
How AITHEA thinks about policy as code in regulated compliance
In financial crime compliance, evidence quality decides whether a control survives an audit or a regulator's review. Policy as code strengthens that evidence chain by generating timestamped, machine-readable records of what was checked and when, rather than a manual attestation written after the fact.
AI increasingly assists at the layers around the policy itself: mapping regulatory text to technical controls, shortlisting vendors whose platforms can actually enforce those controls, and triaging which evidence gaps matter most before an RFP goes out. Aithea works with compliance teams at exactly this intersection, helping structure the technology procurement and pilot design that determines whether a policy-as-code investment ever reaches production.
Why policy as code alone won't satisfy your regulator
Policy as code is necessary infrastructure, not a finished compliance programme. It has to sit alongside governance discipline, developer training, and incident playbooks, because a well-written Rego rule with no owner and no escalation path is just a landmine with good intentions. Regulations and platforms both keep moving, so expect policy maintenance to become a permanent line item, not a one-off project. When you're choosing tooling or a vendor, weight evidence-generation and AI-assisted mapping capability as heavily as raw enforcement features. Enforcement without evidence just moves the audit pain somewhere else.
— Aneta
Where AITHEA fits alongside your policy-as-code rollout
There are alternatives to hiring a generalist systems integrator for compliance technology decisions that offer focused support on the procurement and selection questions determining whether a policy-as-code investment survives past the pilot stage. Such support can include technology selection, RFP structuring, pilot design, and building evidence and audit-readiness artifacts regulators expect to see.
The Heliolus navigator exists specifically for the vendor shortlisting problem: instead of running fifty vendor calls to work out which policy engine or compliance platform actually fits your stack, it structures the comparison and helps you draft an RFP that asks vendors the right questions from the start. For a sense of how AI is reshaping the compliance vendor landscape more broadly, Aithea's analysis of cybersecurity, AI, and financial crime's new frontline is worth reading before you shortlist anyone. Teams outside financial services running similar vendor decisions may also find Aidventure's SaaS tax-platform decision guide a useful model for structuring that comparison.
If you're weighing a policy-as-code pilot against a full procurement cycle, get in touch and Aithea will help you scope which one fits your timeline.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
- Azure Policy concepts: policy as code
- Open Policy Agent documentation
- Compliance as code — practitioner guidance
- Compliance-to-Policy (C2P)
- Policy as code, explained
FAQ
What is meant by policy as code?
Policy as code means writing governance and compliance rules as versioned, executable code that a policy engine evaluates automatically, rather than relying on manual review or static documentation.
Can you give an example of policy as code?
A common example is a Rego policy in Open Policy Agent that denies any Terraform plan attempting to create a publicly accessible storage bucket, blocking the change at the pull-request stage before it ever provisions.
Can you give an example of a compliance policy?
A compliance policy might require that all customer data at rest is encrypted using an approved algorithm, mapped in reporting to a specific PCI-DSS or GDPR control so auditors can trace the technical check back to the regulatory requirement.
What are the three main types of security policies?
Definitions vary across organisations, but a common grouping covers access-control policies (who or what can reach a resource), data-protection policies (encryption and handling rules), and network-security policies (segmentation and traffic rules). Many teams add a fourth category for incident response.
How does Aithea support policy-as-code adoption?
Aithea helps compliance teams structure vendor selection and RFPs for policy engines and compliance tooling through the Heliolus navigator, alongside pilot design and audit-evidence readiness support.