A practical guide to implementing compliance as code

Why is it that the most automated organizations still scramble during audits? Pipelines run without supervision, infrastructure updates itself, and every change is captured somewhere inside the system. Yet the moment an auditor asks for evidence, teams fall back to screenshot folders, exported logs, and improvised documentation.

Engineering has automated compute, identity, configuration, and delivery, but it has not automated trust. Compliance still sits outside the system in static reports, stale attachments, and point-in-time summaries that misrepresent environments that change hundreds of times a day.

Evidence loses accuracy the moment it is collected, which is why audit preparation feels endless even in teams with mature DevOps practices.
There is no shortage of content about "compliance as code," but most of it stays at the surface. Some examples show policy engines, while others offer templates. Few acknowledge that different teams define the term differently, real examples are rare, and auditors still struggle to trust machine-generated evidence.

Without a shared model, compliance work stays fragmented across compliance dashboards, security scanners, developer pipelines, and after-the-fact documentation.

TLDR

This guide takes a more practical path. It treats compliance as part of the software lifecycle, built from versioned policy, continuous checks, and observable evidence. When those elements live in code and run automatically, compliance stops being a parallel process and becomes an attribute of the system itself.

Defining what compliance as code really means

Slow, siloed compliance stems from how stakeholders view compliance as code (CaC). Each group interprets it through its own tunnel vision.

1. The GRC team

Governance, risk, and compliance teams focus on final control status. Their work is centered on producing verified outcomes, not on the underlying technical systems that generate those results.

2. Security engineers

Security teams view CaC as a way to reduce vulnerabilities. Their focus is on reducing the risk of data breaches by embedding scanners, configuration checks, and security tools into the software development lifecycle. In practice, this technical output still needs to be mapped into formal controls and a risk context that the GRC team can act on.

3. Developers

Developers tend to see it as pipeline enforcement. If the pipeline passes and the code deploys, their part is considered complete. The challenge is that compliance rules also need to live in versioned code, embedded into the same workflow so issues surface long before production.

4. Auditors

Auditors rely on traditional documentation formats such as PDFs and spreadsheets because most regulatory frameworks still require them. These formats represent summarized points in time, even though modern systems generate continuous logs and evolving policies.

Each stakeholder sees Compliance as Code through a narrow lens. Without shared standards, the entire system breaks.

The truth is, CaC struggles because each group treats it as an isolated responsibility. As RegScale’s 2025 guide notes, most CaC efforts fall somewhere between scripts and templates because there is no shared framework for how it should work. Policy code, security tools, dashboards, and reports should speak the same language and follow the same standards.

When that alignment exists, you achieve the real meaning of Compliance as Code: governance expressed as executable, versioned policy that can be tested, observed, and trusted like any other part of the stack.

Now that we understand what CaC truly represents, we can explore why traditional compliance efforts fail on modern workloads and why these failures make CaC necessary.

Why compliance collapses in modern systems

The simple reason traditional compliance fails is that it was designed for static systems, but modern systems are dynamic.

In the old approach, compliance tasks rely on manual evidence collection. Meanwhile, cloud environments are managed through IaC templates and automated pipelines that continuously scale workloads and redeploy changes without human intervention.

You might have a record of 10 changes, while the infrastructure has changed a hundred times. This mismatch in event frequency and evidence collection frequency is the audit drift that SentinelOne’s 2025 report highlighted as a major enterprise risk in multi-cloud environments, including AWS, Azure, and Kubernetes.

In these environments, secrets are spread across multiple layers and must still be rotated every 90 days under controls such as SOC 2. The older compliance model wasn’t built to follow secrets that move, expire, and regenerate across distributed systems. It was designed for monolithic environments where secrets live in one place and are rarely changed.

Traditional compliance is static. Modern systems are not. The gap between them creates audit drift.

Why traditional compliance cannot keep up

The ephemeral nature of modern systems widens the gap even more. AI agents, pods, jobs, and serverless functions run for a single task, then disappear. These workloads generate short-lived identities faster than legacy compliance models can track them, turning evidence collection into guesswork. Traditional compliance depends on static assets, providing zero visibility into what these short-lived workloads do.

A compliance team using the older model ends up in a cycle of continuous audit preparation: endless spreadsheets, constant screenshots, pasted evidence, and documentation that becomes outdated the moment it is created. Modern systems need an approach that records, audits, and displays changes as they occur. An approach that is proven through practice, not described only in theory.

Moving from theory to building automated compliance checks

CaC, at its core, means taking the intent of a compliance officer and expressing it as logic that the system can evaluate on its own. A small example captures this clearly:

Each line represents a layer of the compliance workflow.

The governance layer defines the requirement. A control, such as SOC2-CC6.6, sets expectations defined by its regulatory compliance standards. In this case, it's that all secrets rotate every 90 days.

The policy layer converts the requirement into code using rules and checks. The rule sets the expectation, and the check defines the logic for a policy engine such as OPA or Regula to evaluate.

The execution layer runs the policy. A CI job or scheduled scanner evaluates the check against data pulled from the audit logs of secrets managers. The output is a clear PASS or FAIL.

The evidence layer records the result. SIEM tools such as Splunk or Datadog store this output as part of continuous monitoring and audit trail, similar to how platforms like Teleport treat audit logs as a real-time source of truth rather than a single report.

Put together, this creates a model where compliance verifies itself. The controls are written as code, evaluated automatically, and stored as evidence. Now let’s look at how to implement this model in practice.

How to implement compliance requirements as code

Here is a 6-step system for implementing compliance effectively in standard software development processes and environments.

Step 1: Map your controls

Start by translating requirements from SOC2, ISO27001, or your internal security controls and risk policies into logical units that can be evaluated. A clear mapping creates the foundation for your CaC workflow.

Here is what a mapped control can look like:

This gives your developers, security engineers, and GRC teams a shared view of what the control means, how it is checked, who owns it, and how often it is evaluated.

Step 2: Codify and version your policies

Here, convert the mapped requirement into code and have it managed through Git. Using Git means you can update the logic over time while keeping older versions for reference and review. These policies are usually stored as YAML, Rego, or Sentinel files and tracked just like any other artifact in your workflow.

Below is an example Rego policy that evaluates Doppler audit log events and checks whether a secret has rotated within the last 90 days:

This policy looks for Doppler rotation events and considers a secret compliant only if one occurred within the last 90 days.

Step 3: Automate your checks

Integrate compliance checks into your CI/CD pipelines using the policies you codified. Since OPA was used in the previous step, you can run an OPA evaluation job in your pipeline to verify configurations or audit data before deployment proceeds. You can achieve the same result with tools like Regula or custom scripts, depending on your stack.

Step 4: Stream your evidence

Once your checks run automatically, the next step is to store their results in a central place. Source audit logs from your secrets manager and forward them to a SIEM or central monitoring platform. If you use Doppler, you can connect your workspace directly to services like Datadog, Splunk, Sumo Logic, or any HTTPS endpoint to receive audit events.

Step 5: Review, remediate, and repeat

Finally, manage your compliance code as a continuous process. When there is evidence that a rule fails, trigger an automated response: open a ticket, revoke credentials, rotate secrets, or block a deployment. The goal is to react immediately when the control and evidence layers show a violation, so the system continually maintains compliance without manual intervention.

You can wire a remediation script into the OPA step from earlier to automatically rotate any secrets that fail the 90-day rotation check:

Doppler can forward audit activity directly to standard SIEM tools, providing a continuous feed of events.

This provides your SIEM with a continuous stream of events that can be queried and stored as part of your compliance evidence.

Step 6: Review, remediate, and repeat

Finally, manage your compliance code as a continuous process. When there is evidence that a rule fails, trigger an automated response: open a ticket, revoke credentials, rotate secrets, or block a deployment. The goal is to react immediately when the control and evidence layers show a violation, so the system continually maintains compliance without manual intervention.

You can wire a remediation script into the OPA step from earlier to automatically rotate any secrets that fail the 90-day rotation check:

Here is what a simple remediation script could look like:

This script reads the list of stale secrets, generates fresh values, and updates each one through the Doppler API.

Enforcing continuous compliance

The takeaway from this discussion is that compliance is a living part of your stack, and implementing CaC is the most effective way to achieve it today. Start by applying the five-step system outline above. Once these compliance rules and audit evidence live in your code, audits become constant visual validation rather than something you need to dig through your stack to find.

A key part of this system is having a central, reliable place where all your secrets are managed and activities easily streamed. Doppler provides that exact structure, enabling you to plug those events directly into policy checks, CI workflows, and SIEM systems.