Policy as code is the practice of expressing security, compliance and operational rules as machine-readable code, stored and managed like software, so systems can check and enforce them automatically. Instead of a document saying “storage must not be publicly accessible” and a person checking it once a quarter, the rule is written in a policy language or tool, version-controlled, tested, and evaluated automatically when someone creates or changes a resource, or when existing resources are scanned.
At a glance
- Rules live in version control, with review, history and testing, just like application code.
- Policies can block a non-compliant change before it is deployed, flag it after the fact, or both.
- It pairs naturally with infrastructure as code but can also govern Kubernetes, identity, network and application settings.
- It covers the rules a machine can check; many governance requirements still need people and documents.
What problem it solves
Cloud and automation let teams create infrastructure in minutes. Manual review can’t keep up, so misconfigurations slip through: public storage, overly broad permissions, unencrypted databases or resources in regions you aren’t allowed to use. Written standards in a wiki don’t enforce themselves, and different teams read them differently.
Policy as code gives one authoritative, testable version of each rule and applies it the same way every time. Violations are caught when they are cheapest to fix, often before deployment. The policy files, their change history and the evaluation logs also give auditors evidence that controls are applied consistently, rather than a sample of screenshots.
How it works
Write the rule. A policy is written in a policy language or a tool’s rule format. Open-source policy engines such as Open Policy Agent, cloud providers’ built-in policy services and many security tools each have their own format. A rule might say every storage bucket must block public access, or every resource must carry a cost-center tag.
Store and review it. Policies live in a code repository. Changes go through pull requests, peer review and automated tests, so you know who changed a rule, when and why.
Enforce it at one or more points.
- In the pipeline. Infrastructure as code (IaC) templates are checked during CI/CD before they are applied, so a bad change fails the build.
- At admission. A platform such as a cloud account or Kubernetes cluster evaluates each create or change request and denies ones that break policy.
- Continuously. Scans of what is already running flag drift and manual changes, which is the territory of cloud security posture management (CSPM) tools, many of which use policy-as-code engines underneath.
Handle exceptions. Real environments need approved exceptions. Mature setups record them in code too, with an owner, a reason and an expiry date, rather than switching a rule off.
When it matters for buyers
- When you run significant cloud workloads. The pace of change makes automated guardrails one of the few practical ways to keep configuration consistent.
- When preparing for audits. Frameworks such as SOC 2, ISO/IEC 27001 and PCI DSS expect controls to operate consistently; policy logs can be strong evidence.
- When several teams or providers build in your environment. Shared rules in code reduce argument over what the standard means.
- When evaluating managed cloud or security providers. Ask whether they enforce your policies or only their own, and who can change the rules.
Our governance, risk and compliance advisors can help you find tools and partners that turn written controls into automated checks.
Questions to ask vendors
- Which policy language or format does your product use, and can we write our own rules?
- Do you ship a library of policies mapped to frameworks we care about, and how often is it updated?
- Can policies block changes before deployment, or only report them afterwards?
- How are exceptions requested, approved, recorded and expired?
- Can we export policy evaluation results as audit evidence?
- If we leave, can we take our policies with us in a portable format?
How it differs from infrastructure as code
Infrastructure as code (IaC) defines the infrastructure itself: the servers, networks, permissions and settings to create. Policy as code defines the rules that infrastructure must satisfy and evaluates proposed or existing configurations against them. They are usually used together, with IaC templates checked against policies before deployment, but either can exist without the other: policies can scan resources built by hand, and IaC can be used with no automated policy checks at all. Policy as code also differs from a written information security policy, which states intent for people; policy as code makes the machine-checkable parts of that intent enforceable.