Tools

Policy-as-Code — when security policy exists only on paper

Most organizations have security policies. Few have mechanisms that actually enforce them. The difference becomes apparent during an incident.

Szymon Mytych March 18, 2026 8 min read

Security policy as a Word document

A typical technology organization has a security policy. It describes what is allowed and what is not. Container configuration requirements — no root privileges, defined resource limits, no images with the latest tag. Network requirements — no open ports without justification, encryption in transit. Deployment requirements — approval by an authorized person, automated tests, change logs.

The problem with a document: nobody verifies it at every deployment. A developer configuring a container in a hurry doesn’t always reach for a 40-page policy document. A code reviewer focuses on business logic, not security configuration parameters. An auditor will spot the violation — but only at the next audit, which might be a year away.

The space between policy and enforcement

This space — between what the policy says and what actually reaches production — is where security incidents are born. Not because anyone has bad intentions. Because human verification processes don’t scale with the speed of software delivery.

An organization that deploys dozens of times a day cannot manually verify every deployment’s compliance with security policy. Either verification is automated — or it doesn’t exist.

Policy-as-Code as a model shift

Policy-as-Code is an approach of encoding security policies as executable code and automatically verifying them at every deploy, every configuration change, every resource created in infrastructure.

Open Policy Agent (OPA, a CNCF project) is one of the most widely used engines for this purpose. It allows defining a policy (“no container can run as root”) and automatically verifying every Kubernetes resource before it starts. A policy violation results in a rejection — with a message describing what needs to change.

The result: policy stops being a document. It becomes a property of the system — enforced automatically, at every operation, without exceptions and without the possibility of being skipped due to forgetfulness or haste.

Audit vs enforcementThere is a significant difference between tools that audit (report policy violations) and tools that enforce (block operations non-compliant with policy). Auditing alone without enforcement produces reports — not security. Enforcement without careful calibration produces blocks and team frustration. The balance between them requires a thoughtful implementation process.

Where policy-as-code makes the most sense

The greatest value appears with controls that are objectively verifiable and high-risk: container security context configuration, secret access, network policies, base image requirements. These are controls where automated verification is both possible and critical.

Policies that require context and judgment — e.g., whether a given architectural decision is appropriate — remain the domain of human code review. Policy-as-Code doesn’t replace engineering thinking. It replaces those verifications that are mechanical, repetitive, and too important to depend on someone’s attention at any given moment.

Read also:

Policy-as-CodeOPAKubernetesGovernance