A developer pushes a change at 4:47 PM on Friday.
The application works. The tests pass. The container builds successfully.
But the change would route customer data through a region the organization has marked as restricted.
In a traditional environment, that problem might surface weeks later. A security review catches it. An auditor notices it. Or worse, nobody notices until after deployment.
In a compliance-as-code environment, the pipeline rejects the change before it reaches production.
That is the practical shift happening around modern DevSecOps. Compliance is slowly moving away from spreadsheets, periodic reviews, and approval chains toward something engineering teams can version, test, and enforce automatically.
The idea is simple: if a technical requirement can be expressed as a rule, software should be able to check it repeatedly.
That doesn't mean GDPR, HIPAA, or NIS2 can be reduced to a few YAML files. They can't. But a growing portion of the technical controls required to support compliance can be embedded directly into the software delivery lifecycle.
And that changes compliance from something that happens after development into something the platform checks while development is happening.
The old Compliance model was built for a slower software world
For years, compliance followed a familiar pattern.
Engineering built the system. Security reviewed it. Compliance documented it. Auditors eventually inspected the evidence.
That sequence made more sense when infrastructure changed slowly.
It breaks down when a cloud environment can change hundreds of times a day.
A Kubernetes deployment might introduce a new service account. An Infrastructure-as-Code change might expose a storage bucket. A developer could add a third-party data processor through a single configuration update. An API change could quietly expand the information being collected or transmitted.
The problem isn't that compliance teams aren't working hard enough.
The problem is that manual review does not scale at the speed of automated delivery.
Take GDPR. The regulation's principles include data minimisation, purpose limitation, storage limitation, integrity, confidentiality, and accountability. Organizations must also be able to demonstrate compliance when required.
Those principles are broader than infrastructure configuration. But some supporting controls can absolutely be checked automatically.
For example, a platform can verify whether a deployment is pointing to an approved region, whether sensitive storage is encrypted, whether a new service is using an approved data classification, or whether a workload is attempting to connect to a prohibited destination.
The same logic applies to HIPAA.
The HIPAA Security Rule requires appropriate administrative, physical, and technical safeguards for electronic protected health information. It also requires regulated entities to assess risks and vulnerabilities and review the effectiveness of their security measures.
Again, software cannot automate the entire regulatory obligation.
But it can continuously verify technical controls that would otherwise depend on someone remembering to check them.
That distinction is where compliance-as-code becomes useful.
Compliance-as-Code is not about automating the regulation
This is where many conversations around the topic become misleading.
You cannot upload GDPR into Open Policy Agent and suddenly become GDPR compliant.
Compliance involves legal interpretation, organizational processes, human accountability, risk decisions, vendor relationships, and operational behavior. Some requirements are deliberately flexible because regulators expect organizations to account for their own size, systems, and risks.
What compliance-as-code does is narrower and more practical.
It takes a compliance requirement and translates the technical controls supporting that requirement into rules that machines can evaluate.
Suppose an organization has a policy stating that workloads handling sensitive data must:
- use approved regions
- encrypt storage
- avoid public network exposure
- use managed identities rather than static credentials
- maintain specific logging controls
Those expectations can become executable policies.
The policies live alongside the infrastructure and application code. They can be reviewed in pull requests. They can be tested before enforcement changes. And most importantly, they can run automatically whenever the environment changes.
That creates a very different operating model.
Instead of asking:
"Was this system compliant when we reviewed it three months ago?"
The platform can continuously ask:
"Does this change violate a control right now?"
Why CI/CD is becoming the natural place for compliance
The CI/CD pipeline already acts as a decision point.
Code enters. Tests run. Builds happen. Security scans execute. Artifacts are created. Deployments are either approved or blocked.
Compliance policies can use the same mechanism.
Open Policy Agent, commonly known as OPA, is one of the best-known examples. OPA is a general-purpose policy engine designed to separate policy decision-making from the systems enforcing those decisions. It can be used across microservices, Kubernetes, APIs, and CI/CD pipelines.
OPA's CI/CD guidance specifically describes using policy-as-code to verify configurations, validate outputs, and enforce organizational requirements before code reaches production.
Kyverno takes a similar idea into the Kubernetes ecosystem.
Its policies can validate, mutate, generate, or manage Kubernetes resources. Kyverno can also run in delivery pipelines to evaluate resource manifests before they are committed or applied to a cluster.
This creates multiple enforcement points.
A developer can receive feedback locally.
A pull request can fail policy checks before merging.
The CI pipeline can reject non-compliant Infrastructure-as-Code.
The cluster itself can reject a deployment that somehow bypasses earlier checks.
That layered approach matters because compliance failures aren't always introduced in the same place.
A developer might create the problem. A pipeline might miss it. An infrastructure tool might generate something unexpected. Runtime admission controls provide another line of defense.
The goal isn't one giant compliance gate. It's to make policy enforcement part of the system architecture.
What an Automated Compliance Gate actually looks like
Consider a healthcare platform deploying a new service to Kubernetes.
The engineering team adds a deployment manifest. Before the workload reaches production, the pipeline evaluates a set of policies.
The first checks whether the container image comes from an approved registry.
The next verifies that the workload isn't using a privileged container.
Another checks whether secrets are being passed through an approved mechanism instead of hardcoded into environment variables.
A policy verifies network restrictions. Another checks whether required labels for data classification and ownership exist.
If the service handles protected health information, additional controls may apply.
The pipeline doesn't tell the developer, "You have violated HIPAA."
That would be an oversimplification.
Instead, it says something more concrete:
This deployment violates the organization's approved technical control for workloads in this data classification.
That distinction is important.
The regulation sits at one level. Organizational policy interprets the relevant requirements. Technical controls implement parts of that policy. Automated checks verify those controls.
Compliance-as-code connects those layers.
GDPR is a good example of why this matters
GDPR is often discussed as a privacy problem rather than an engineering problem.
But modern data systems turn many privacy decisions into architecture decisions.
Where does data go?
Which service can access it?
How long is it retained?
Which processor receives it?
Can a new environment duplicate production data?
Is personal data appearing in logs?
Not every one of these questions can be answered with a policy engine. But many can.
A platform team could define rules around approved data regions. Infrastructure pipelines could reject unencrypted storage configurations. Deployment policies could require services handling personal data to carry specific ownership and classification metadata.
Data retention can also become more systematic when infrastructure and storage lifecycle configurations are managed as code.
This doesn't eliminate the need for privacy professionals.
It gives them something much better than periodic promises from engineering teams.
It gives them repeatable controls with version history.
That history matters because GDPR's accountability principle requires organizations not only to comply, but to be able to demonstrate compliance when required.
Version-controlled policy creates useful evidence.
You can see when a rule was introduced. You can review why it changed. You can identify which environments were evaluated against it.
The policy itself becomes part of the compliance record.
NIS2 makes continuous controls even more relevant
NIS2 provides another reason organizations are looking more closely at automation.
The directive establishes cybersecurity risk-management and reporting requirements across a broad range of critical sectors in the EU. It covers areas including incident handling, business continuity, supply-chain security, secure development and maintenance, vulnerability management, access control, cryptography, and security training.
Look closely at that list.
Several of those areas are directly connected to software delivery.
Supply-chain security can influence which dependencies or container images are allowed into production.
Secure development requirements can influence pipeline checks.
Vulnerability handling can connect scanners to deployment policies.
Access control can be enforced through Infrastructure-as-Code and identity rules.
The European Commission also adopted technical and methodological requirements under NIS2 for several critical digital and ICT service sectors.
NIS2 doesn't prescribe a single policy engine or tell companies to use OPA.
That isn't the point.
The opportunity is architectural: organizations can take relevant technical controls and make them continuously verifiable rather than relying entirely on periodic assessments.
The Commission proposed targeted NIS2 amendments in January 2026 aimed partly at increasing legal clarity and simplifying compliance requirements for businesses.
Simplification at the regulatory level won't remove the operational challenge, though.
Companies still need to know whether their actual systems are following the controls they've defined.
Automation is one of the few realistic ways to do that continuously.
The real shift is from evidence collection to continuous evidence.
This may be the biggest benefit of compliance-as-code.
Traditional compliance processes often involve collecting evidence after the fact.
Someone asks whether encryption was enabled.
The team takes screenshots.
Someone exports configuration data.
A spreadsheet gets updated.
The evidence describes a point in time.
Policy-driven delivery can produce something more useful: continuous evidence.
Every pipeline run can record whether a configuration passed or failed.
Every policy can have a version.
Every exception can be documented.
Every enforcement change can move through review like application code.
That doesn't make audits disappear. Auditors still need to understand the control environment.
But it changes the evidence model from:
"Trust us, we checked."
to:
"Here is the policy. Here is its version history. Here are the environments it evaluated. Here are the exceptions and failures."
That is a much stronger foundation for both security and compliance.
Where teams usually get this wrong
The first mistake is trying to automate everything immediately.
Organizations often start with a massive compliance framework and attempt to translate hundreds of requirements into policies.
That usually creates an unmaintainable rulebook.
A better starting point is to identify controls that are both important and objectively testable.
Can the system automatically determine whether this configuration violates the rule?
If yes, automate it.
If the answer depends on business context, legal interpretation, or a human risk decision, keep a human in the loop.
The second mistake is creating policies without ownership.
A policy engine can reject a deployment, but someone needs to decide whether the policy is correct when the business changes.
Policy code is still code. It needs maintainers, tests, reviews, versioning, and a clear change process.
The third mistake is turning the pipeline into a bureaucratic obstacle.
If every policy failure sends developers searching through a 40-page compliance document, they will eventually work around the system.
The feedback needs to be actionable.
Don't just say:
Policy violation.
Say:
Public storage is not permitted for workloads classified as restricted. Use the approved private storage configuration or request a documented exception.
That is the difference between enforcement and friction.
Compliance needs an architecture, not another dashboard
The strongest teams are starting to treat compliance as an architecture problem.
They are asking where controls belong.
Some checks happen before code is merged. Others happen when infrastructure plans are generated. Some belong in artifact registries. Others need runtime enforcement inside Kubernetes.
There is no single "compliance stage."
That old model is exactly what compliance-as-code is replacing.
The better approach looks more like this:
A policy is defined once.
It is tested.
It runs at the earliest useful point in development.
It runs again where bypasses are possible.
Its results are recorded.
Exceptions are explicit rather than hidden.
The architecture itself starts making non-compliant states harder to create.
That's a much more useful objective than asking developers to remember every requirement in a regulatory framework.
Compliance is moving into the Engineering system
The future of compliance isn't a security team standing between developers and production.
It is not a legal department writing requirements that engineering translates six months later.
And it is definitely not a quarterly audit trying to reconstruct what happened inside a system that changes every hour.
The more practical model is to turn stable technical controls into executable rules and place those rules directly inside the systems responsible for delivering software.
OPA can evaluate policy decisions across the stack. Kyverno can enforce policies around Kubernetes resources and delivery pipelines. CI/CD systems can block changes before they become production problems.
The regulations still require human judgment.
The risk decisions still belong to people.
But developers should not have to manually remember every approved configuration, security requirement, data restriction, and organizational policy every time they push code.
That is what the platform is for.
Compliance-as-code doesn't automate compliance away. It automates the parts of compliance that software is better at checking than humans are.
And for organizations shipping software continuously, that may be the only way compliance can keep up with development without becoming the thing that slows it down.
