Rutledge & Associates - Prime Ready SubcontractorsVisit Website →
← Back to blog

Compliance as Code: A Practical Guide for DevSecOps Teams

August 28, 2026
Compliance as Code: A Practical Guide for DevSecOps Teams

Compliance as code is the practice of expressing regulatory and organizational controls as machine-readable, testable code so systems remain continuously audit-ready. It replaces static spreadsheets and point-in-time assessments with policies that run in CI/CD pipelines and production environments alike. Regulated and cloud-native organizations adopt it to shrink audit prep from weeks to days and to catch violations before they ship, not after an assessor finds them.

TL;DR:

  • Automated compliance checks can run on every code commit, reducing audit preparation time from weeks to days and surfacing configuration drift within hours.
  • OSCAL, OCSF, and SBOM standards are essential for creating consistent, machine-readable control documentation, telemetry normalization, and supply-chain verification.
  • Tools like Open Policy Agent and Trestle enable policy validation and OSCAL content management within CI/CD pipelines, supporting systematic automation.
  • Implementing compliance as code should start with a narrow pilot focused on a single system and control set, then expand gradually to avoid delays due to legacy document conversion.
  • Effective automation combines detection, tiered remediation, and audit-ready evidence packages, with organizational collaboration between security, DevOps, and compliance teams being crucial.

Table of Contents

What Compliance as Code Actually Covers

Compliance as code translates a control requirement, say, "encrypt data at rest," into an executable check that runs against infrastructure, application configuration, or runtime telemetry. It differs from policy as code in scope rather than mechanism: policy as code focuses narrowly on access, authorization, and resource guardrails (who can do what, and under which conditions), while compliance as code wraps that same automation around a full regulatory framework, mapping each control to a test, an owner, and a piece of evidence. Policy as code is a building block; compliance as code is the assembled structure that satisfies an auditor.

Inside a DevSecOps pipeline, compliance as code sits alongside infrastructure as code (IaC) rather than replacing it. Terraform or CloudFormation defines what gets built; compliance as code verifies that what got built matches an approved baseline, whether that baseline comes from NIST 800-53, CIS Benchmarks, or a program-specific overlay.

The practical payoffs show up quickly once teams stop treating compliance as a quarterly event:

  • Controls get tested on every commit instead of once a year
  • Evidence accumulates automatically instead of getting assembled under deadline pressure
  • Drift between documented and actual configuration surfaces within hours, not during the next audit cycle
  • Security and compliance teams work from the same source of truth as engineering, instead of a parallel spreadsheet

How Do OSCAL, OCSF, and SBOM Fit Together?

None of this works without a shared, machine-readable vocabulary for controls, findings, and software components. Three standards do most of the heavy lifting.

OSCAL (Open Security Controls Assessment Language) is NIST's format for documenting control catalogs, profiles, system security plans, assessment plans and results, and plans of action and milestones (POA&Ms), all expressed in JSON, XML, or YAML. It gives compliance data the same version control and diffing discipline that engineers already apply to code.

  • Catalogs and profiles define what controls exist and which subset applies to a given system
  • SSPs describe how those controls are implemented
  • SAP/SAR documents capture the assessment plan and its results
  • Assessment Results artifacts are the machine-readable output auditors can ingest directly

OCSF (Open Cybersecurity Schema Framework) normalizes runtime telemetry, scanner output, and SIEM logs into a consistent schema, which is what lets a firewall alert and a vulnerability scan feed the same compliance pipeline. OCSF and OSCAL together convert live telemetry into structured compliance outputs, closing the gap between "what the system is doing right now" and "what the paperwork says it should be doing."

SBOM (Software Bill of Materials) supplies the supply-chain layer: a component inventory that crosswalks into vulnerability and licensing evidence, increasingly expected in federal procurement and referenced directly inside OSCAL assessment artifacts.

Which Tools Actually Run Compliance as Code?

The tooling landscape splits into four functional layers, and most mature pipelines use tools from each.

  1. Policy engines and validators. Open Policy Agent (Rego) is the most widely adopted general-purpose policy engine, paired frequently with Conftest for testing Kubernetes manifests and Terraform plans against Rego rules. Chef InSpec handles host and OS-level compliance checks. Terraform Compliance validates plan output against business rules before an apply ever runs. HashiCorp Sentinel serves a similar role inside HashiCorp's own ecosystem, particularly Terraform Cloud and Vault, and teams often ask "Sentinel vs. OPA" when standardizing on one engine. Sentinel integrates tightly with HashiCorp products but stays proprietary to that stack, while OPA works across any system that can call its API, which is why most multi-cloud shops default to OPA and reserve Sentinel for pure HashiCorp workflows.
  2. OSCAL orchestration tooling. Trestle provides an SDK and command-line utilities for authoring, validating, and fragmenting OSCAL content, including converting legacy Word and spreadsheet SSPs into structured OSCAL. It's the tool most teams reach for once hand-editing raw OSCAL JSON becomes unmanageable.
  3. Evidence collectors and integrity tools. Sigstore-based signing, cryptographic attestations, and OCSF-formatted SIEM exports establish that evidence came from the system it claims to and wasn't altered after collection.
  4. Integration patterns. GitOps workflows, pre-merge policy gates, and Kubernetes admission controllers are where all of the above actually executes, catching violations at the moment code or configuration changes rather than during a periodic scan.

How Do You Implement Compliance as Code Step by Step?

Most successful rollouts follow the same sequence, whether the target is a single application or an entire authorization boundary.

  1. Inventory and baseline selection. Pick one system and one framework (a specific NIST 800-53 baseline, a CIS Benchmark level, or a program-specific control set) rather than trying to codify every requirement across every system simultaneously.
  2. Author machine-readable controls and profiles. Convert the chosen baseline into an OSCAL profile and write the corresponding Rego, InSpec, or Terraform Compliance rules that test each control.
  3. Integrate into CI/CD. Add policy checks as pipeline gates, ideally at plan time for infrastructure changes and at build time for application configuration, so failures block a merge instead of surfacing weeks later.
  4. Collect runtime evidence. Wire scanners, SIEM exports, and telemetry into OCSF-normalized outputs so findings from disparate tools land in one consistent evidence stream.
  5. Automate reporting. Generate OSCAL Assessment Results and POA&M entries directly from pipeline and runtime data instead of manually transcribing findings into a tracking spreadsheet.

Start with the checklist approach outlined for public-sector IT programs if you're scoping your first baseline. It maps cleanly onto the same five-step sequence above.

Pro Tip: Pilot on the system with the smallest control set first, even if it's not the most urgent. A narrow, fully automated pilot builds the credibility you'll need before compliance and security teams trust automated gates on a higher-stakes system.

Success criteria at each stage should be concrete: percentage of controls with an automated test, mean time from code change to compliance verdict, and number of findings resolved before merge versus after deployment.

Where Should Checks Run in the CI/CD Pipeline?

Placement determines both how effective a check is and how much friction it adds to a developer's day. Three timing patterns cover almost every case.

  • Plan-time checks evaluate Terraform or CloudFormation plans before anything is provisioned, catching a misconfigured security group before it ever becomes a live resource.
  • Build-time checks run against container images, application manifests, and dependency trees during the build stage, where Conftest and OPA policies typically live.
  • Deploy-time checks happen at admission control, when Kubernetes or a cloud provider's policy service either allows or rejects a resource as it's created.

Each stage should emit a standard artifact rather than a proprietary log format. SARIF works well for static analysis findings, OSCAL Assessment Results for control-level pass/fail data, and OCSF for anything coming off a runtime scanner or SIEM. Feeding all three into the same evidence store means an auditor's request for "show me every control that failed in the last quarter" is a query, not a project.

Fast pipelines depend on triage and caching more than raw compute. Cache policy evaluation results for unchanged resources, gate only the controls tied to what actually changed in a given pull request, and reserve full-baseline scans for scheduled runs rather than every commit. A DevOps automation playbook built for delivery pipelines covers this selective-gating approach in more depth for teams building it from scratch.

What Does an Audit-Ready Evidence Package Look Like?

Assessors don't want a narrative; they want artifacts they can independently verify. A complete package typically includes:

  • OSCAL Assessment Results documenting which controls were tested, when, and with what outcome
  • System Security Plans (SSPs) describing implementation details for every applicable control
  • POA&Ms for any control not yet fully satisfied, with remediation timelines attached
  • Signed evidence bundles, using Sigstore or comparable cryptographic attestation so the assessor can confirm evidence wasn't altered after collection

Evidence integrity matters as much as evidence completeness. Append-only logs and cryptographic signing establish a chain of custody that a spreadsheet simply cannot. Platforms built natively on OSCAL can ingest these artifacts and generate audit-ready exports directly from live systems, which is a meaningfully different workflow than exporting a PDF the week before an assessment.

Practitioner reporting backs the time savings this produces: one municipal IT program cited an 81% reduction in patching time after adopting compliance automation, alongside a measurable drop in audit prep workload. For agencies preparing a third-party assessor package, the contract compliance guidance for public-sector programs covers what assessors typically request beyond the technical artifacts themselves.

What Slows Down Compliance-as-Code Adoption?

Every rollout hits some version of the same four obstacles.

  • Legacy document conversion. Converting years of Word-document SSPs into structured OSCAL is often the single most labor-intensive phase of a project. Treat it as its own engineering effort with dedicated validation gates, using Trestle or an equivalent conversion SDK, rather than a quick pre-step before the "real" work begins.
  • Scale and drift. As the number of monitored resources grows, full-baseline scans on every change become impractical. Sampling strategies and telemetry-driven selective enforcement keep pipelines fast without losing coverage.
  • Governance gaps. Exception handling, change control, and approval workflows need to be defined before automated gates go live, or teams will route around blocked merges instead of fixing the underlying issue.
  • Developer friction. Policies written without engineering input tend to fail loudly and unhelpfully. Clear error messages and documented remediation paths cut resistance far more than mandates do.

How Do You Automate Remediation for Compliance Violations?

Detecting a violation is only half the job. Automated remediation closes the loop by acting on what the policy engine finds, and it works best when tiered by risk rather than applied uniformly.

Hands connecting hardware device for remediation

Low-risk, high-confidence violations, like a missing resource tag or an unencrypted storage bucket, can be auto-remediated immediately: a pipeline step or a serverless function applies the fix and logs the change as evidence in the same OCSF-normalized stream used for detection. Medium-risk violations, such as an overly permissive security group, usually warrant an automated pull request with the fix pre-written, requiring a human approval before merge. High-risk violations, anything touching authentication, encryption keys, or production data access, should trigger an alert and a POA&M entry rather than an automatic change, since the blast radius of an incorrect auto-fix can exceed the risk of the original violation.

The key design decision is where remediation logic lives. Embedding fixes directly in the policy engine (a Rego rule that also generates a patch) keeps detection and remediation tightly coupled but makes the policy harder to audit. Separating detection from remediation into distinct pipeline stages, with the violation logged as a discrete OCSF finding before any fix runs, keeps the audit trail cleaner and lets compliance teams review remediation logic independently from the detection rules. Most mature programs land on the second pattern once they've moved past their first few pilots, because assessors specifically ask for evidence that a fix was reviewed, not just applied.

How Should Teams Measure Compliance Effectiveness?

Compliance dashboards fail when they report activity instead of outcomes. Counting the number of policy checks that ran tells a stakeholder nothing about whether the organization is actually more compliant than it was last quarter.

Compliance effectiveness metrics comparison diagram

The metrics worth reporting upward fall into a handful of categories: percentage of controls with an automated test versus a manual one, mean time between a violation's introduction and its detection, mean time to remediation once detected, and the ratio of findings caught before deployment versus after. A rising percentage of pre-deployment catches is the clearest signal that compliance as code is doing its job, since it means fewer violations are reaching production in the first place.

Audit-specific metrics matter separately from operational ones. Time spent assembling evidence for an assessor, number of controls requiring manual evidence gathering versus automatic export, and the count of open POA&Ms by age all speak directly to audit readiness in a way engineering-focused metrics don't. Reporting both sets side by side, operational health and audit posture, gives compliance officers and program managers a shared view instead of two disconnected narratives. A government IT compliance checklist offers a starting point for which control-level metrics tend to matter most to federal and state assessors specifically.

How Do DevOps, Security, and Compliance Teams Work Together on This?

Compliance as code fails as often from organizational friction as from technical gaps. The teams involved have different incentives, and pretending otherwise slows every rollout.

Security teams want to preserve the intent of the underlying framework. DevOps teams want checks that don't add latency to deployment. Compliance teams want defensible, auditable evidence they can hand to an assessor without translation. All three get what they need only when policy authoring happens as a shared exercise rather than a handoff.

Start with a joint control triage, review the baseline together and agree on which controls justify automated enforcement versus manual attestation, before anyone writes a single Rego rule. Give compliance teams read access to the policy repository so they can verify a rule actually implements the control it claims to, not just trust an engineering summary. Route policy exceptions through a shared approval workflow that both security and compliance can see, instead of letting exceptions live in Slack threads or private tickets. The automation-for-primes guidance for government contracts makes a similar case for cross-team ownership models, specifically in the context of contractor and subcontractor accountability on regulated programs.

What Public-Sector Programs Get Wrong About This

Most compliance as code guidance gets written from a pure engineering angle, as if the hardest part is choosing between OPA and Sentinel. In defined-scope engagements for state agencies, the harder problem is almost always the legacy SSP conversion and the governance workflow around exceptions, not the policy engine itself.

Rutledge & Associates builds compliance automation as an owned deliverable rather than staff augmentation, which changes the incentive structure in a way that matters more than most articles acknowledge. When a contractor is paid for hours, there's little pressure to finish the OSCAL conversion quickly. When the deliverable is a defined, audit-ready artifact set, the incentive flips toward shipping something usable fast, then refining it.

The pattern that works best on public-sector programs is a narrow pilot: one system, one baseline, full automation end to end, before expanding scope. Agencies that try to codify an entire authorization boundary in one pass tend to stall on legacy document conversion for months. Agencies that pilot narrow and expand see measurable results faster, echoing the 81% patching-time reduction reported in municipal IT programs once automation replaced manual tracking.

The advice that matters most for agencies starting out: own the artifacts you produce, not just the process you follow. An assessor doesn't care how elegant your Rego policies are. They care whether your OSCAL Assessment Results and POA&Ms hold up under scrutiny.

— Randy

Where to Learn More About OSCAL and Compliance Automation

The NIST OSCAL project is the primary reference for schema definitions, examples, and the current state of catalogs, profiles, and assessment models. The Cloud Security Alliance's explainer on compliance as code covers OCSF's role in more depth than fits here. RegScale's writeup on continuous controls monitoring shows what an OSCAL-native platform looks like in practice, and StateTech Magazine's coverage of state and local implementations documents measured outcomes from real government programs rather than vendor claims.

Get Compliance as Code Delivered as a Defined, Owned Work Package

Reading about OSCAL profiles and OPA policies is one thing. Getting a legacy SSP converted, a pipeline gated, and an audit-ready evidence stream running is another, and it's exactly the kind of scoped deliverable Primereadysub takes on instead of staffing your team with more hours to manage. Primereadysub owns the outcome: a defined compliance automation package, with clear artifacts and a fixed scope, rather than an open-ended engagement that drags on without accountability for the audit-readiness result. For agencies and prime contractors carrying compliance-heavy programs in states like Maryland, New York, and Florida, that ownership model means less oversight burden on your side and a faster path from legacy documentation to a working, continuously monitored control set. If your team also needs governance help around policy-to-automation mapping, Total Cyber Solutions' policy compliance services cover that adjacent layer well. To scope your first compliance automation work package, reach out through Primereadysub and describe the system and baseline you want piloted first.

Sources