What is compliance as code?
Compliance as code is the practice of encoding your controls as machine-readable, testable rules that run automatically. A control like "production databases must be encrypted at rest" stops being a sentence in a policy document and becomes a rule a machine evaluates against your actual configuration. If the configuration matches, the control passes. If it does not, the control fails, and you find out immediately instead of during an audit.
The shift is the same one software went through with infrastructure as code. We stopped clicking through consoles to build servers and started declaring the desired state in files we could review, version, and replay. Compliance as code does that for controls. You declare what compliant looks like, store it in Git next to the systems it governs, and let your pipeline check it on every change.
The point is not to replace your judgment about which controls matter. It is to make the controls you have chosen enforce themselves, consistently, without a human re-checking a spreadsheet every quarter. If you are new to this way of working, start with GRC automation for the broader picture, then come back here for the policy layer.
What is policy as code?
Policy as code is the mechanism that makes compliance as code work. A policy is a specific rule, "all storage buckets must be encrypted" or "no security group may allow inbound traffic from 0.0.0.0/0 on port 22." Policy as code means you write that rule in a language a policy engine understands, and the engine evaluates real configuration against it and returns a decision: allow or deny.
Compliance as code is the goal. Policy as code is how you get there. You can think of compliance as code as the program and policy as code as the individual rules that make up that program. A single control often becomes one policy. A framework becomes a library of policies you maintain like any other codebase.
The reason this matters is consistency. A human reviewing buckets for encryption will miss one eventually. A policy engine checks every bucket the same way every time, and it does it in milliseconds. That reliability is what lets you move enforcement from a periodic audit to a continuous gate.
The tools that make it real
This is not a future technology. The ecosystem is mature, and most of it is open source. Here are the tools you will actually encounter.
Open Policy Agent (OPA)
A general-purpose policy engine that evaluates rules written in the Rego language. Used for Kubernetes admission control, API authorization, and configuration checks across many systems.
Rego
The declarative query language OPA uses. You write rules that describe what is allowed or denied, and OPA evaluates structured data, like JSON, against them.
AWS Config rules
Continuously evaluates the configuration of AWS resources against rules and flags anything non-compliant. Ships managed rules and supports custom ones.
HashiCorp Sentinel
A policy-as-code framework that evaluates Terraform plans before they apply, so non-compliant infrastructure is blocked at the planning stage.
Cedar
An open-source policy language from AWS focused on authorization. You write who can do what to which resource as explicit, reviewable policies.
Checkov
An open-source static analysis scanner for infrastructure as code. It checks Terraform, CloudFormation, Kubernetes manifests, and more against hundreds of built-in policies.
You do not need all of these. Most programs pick one engine for cloud resource state, like AWS Config, one for infrastructure as code, like Checkov or Sentinel, and reach for OPA and Rego when they need general-purpose policy evaluation that the others do not cover. For a closer look at the scanning side, read infrastructure as code compliance scanning.
How policy as code differs from a GRC platform
A traditional GRC platform is a system of record. You log in, you see a list of controls, you attach evidence, and you track audit status. It is good at organizing what your controls are. It is not where the controls run. Policy as code is the opposite: the control is the code, and it runs where your systems run.
| Dimension | Traditional GRC Platform | Policy as Code |
|---|---|---|
| Where the control lives | A description in a database | A rule in your Git repository |
| Version control | Change logs inside the platform | Full Git history, diffs, and pull requests |
| Testability | Reviewed manually | Unit-testable against sample inputs |
| When it runs | Point-in-time, at audit | At deploy time, in CI/CD, on every change |
| Outcome of a failure | A note for the next audit | A blocked deploy before the gap ships |
These are not competitors. A platform that catalogs your controls and a pipeline that enforces them solve different problems. The most effective programs use the platform as the system of record and policy as code as the enforcement layer, with continuous integration and continuous delivery, CI/CD, as the place the two meet. The platform says what should be true. Policy as code proves it is.
A control expressed as a policy
Take a control most programs have: server-side encryption must be enabled on all object storage. In a SOC 2 program this maps to a confidentiality criterion under CC6, and in NIST 800-53 Rev 5 it maps to SC-28, protection of information at rest. In a spreadsheet, that control is a row someone checks off. As policy as code, it is a rule the pipeline runs.
Here is the same control written in Rego, the language OPA evaluates. The rule denies any storage bucket whose encryption is not enabled:
package compliance.encryption
# Control: SC-28 / SOC 2 CC6 - data at rest must be encrypted
# Deny any bucket that does not have encryption enabled.
deny[msg] {
bucket := input.resources[_]
bucket.type == "storage_bucket"
not bucket.encryption.enabled
msg := sprintf(
"Bucket '%s' violates SC-28: encryption at rest is not enabled",
[bucket.name],
)
}Feed your infrastructure configuration into OPA and the engine returns a deny message for every bucket that fails. Wire that into your pipeline and a non-compliant bucket never reaches production, because the deploy is blocked before it does. The same logic expressed as a Checkov check or an AWS Config rule would behave the same way, just scoped to where that tool runs.
The detail worth noticing is the comment that ties the rule to SC-28 and SOC 2 CC6. One policy, two frameworks satisfied, and an auditor can read the exact logic that enforces the control rather than taking your word for it. That traceability is what makes compliance as code hold up under scrutiny.
Getting from control to policy faster
The honest friction with policy as code is the first draft. Translating a control objective into correct Rego or a Sentinel policy takes fluency that GRC teams are still building. That gap is closing.
The open-source claude-grc-engineering toolkit includes a /grc-engineer:generate-policy command that drafts policy as code from a control objective, so you start from a reviewable rule instead of a blank file. You still own the review. Treat the generated policy the way you treat any pull request: read it, test it against known-good and known-bad inputs, and sign off before it gates a deploy. For evidence that already exists in your environment, see AI for compliance evidence.
Frequently Asked Questions
What is compliance as code?
Compliance as code is the practice of expressing compliance controls as machine-readable, testable rules that run automatically in a pipeline. Instead of tracking control status in a spreadsheet, you write the requirement as code, version it in Git, and let it pass or fail every time infrastructure or configuration changes.
What is policy as code?
Policy as code is the technique that makes compliance as code work. You write a policy, like "all storage buckets must be encrypted," as a rule in a language such as Rego or HashiCorp Sentinel. A policy engine evaluates real configuration against that rule and returns allow or deny, so the policy is enforced consistently rather than reviewed by hand.
What tools are used for compliance as code?
Common tools include Open Policy Agent (OPA) with the Rego language for general policy evaluation, HashiCorp Sentinel for Terraform plans, Cedar for authorization policies, AWS Config rules for cloud resource state, and Checkov for scanning infrastructure as code like Terraform and CloudFormation. Most programs combine a few of these depending on where they need enforcement.
How is compliance as code different from a GRC platform?
A traditional GRC platform stores control descriptions, evidence, and audit status in a database you log into. Compliance as code lives in your repository: the controls are code, they are version-controlled, they are testable, and they run at deploy time inside CI/CD. The platform tells you what a control should be. Compliance as code proves the control is actually enforced, on every change.