Compliance-as-Code: Policies That Validate Themselves Against Your Infrastructure

A defense industrial base contractor passed their CMMC Level 2 assessment in March. By June, their assessor findings were already stale --- three new cloud services had spun up outside the boundary, two firewall rules had been modified during an emergency change window, and an intern had provisioned an S3 bucket without encryption. The SSP, locked in a SharePoint library with 47 signatures, described a system that no longer existed.

This is not a discipline failure. It is a structural one --- static documents cannot keep pace with dynamic infrastructure. Compliance-as-code offers a fundamentally different model: security policies expressed as versioned, machine-readable assertions that validate themselves against live systems and generate evidence as a byproduct.

The timing matters. FedRAMP 20x is moving toward OSCAL-native authorization packages. CMMC assessors are starting to ask for machine-readable evidence. DoD cATO (continuous Authority to Operate) explicitly depends on automated compliance validation. Organizations still running on Word documents and annual assessments are building technical debt that compounds with every deployment.

The Document Decay Problem

The traditional compliance lifecycle has a fatal flaw: the moment documentation is signed, it begins decaying. Infrastructure changes daily --- new services deploy, configurations drift, access control lists evolve --- but the SSP sits frozen, a snapshot of an environment that existed for perhaps 48 hours after final signatures.

The consequences cascade predictably. Auditors find discrepancies between documented and actual configurations. Remediation timelines slip because nobody noticed the drift until assessment prep. POA&Ms accumulate not because controls failed, but because documentation failed to track controls that were working fine.

Security teams end up spending more time updating Word documents than improving actual security posture. The compliance program becomes a documentation program, disconnected from the infrastructure it supposedly describes.

Here is the contrarian take that most compliance consultants will not say: annual assessments against static documentation are compliance theater. They measure your ability to produce documents, not your ability to maintain security. A system that was compliant during the assessment window and non-compliant for the other 50 weeks of the year is not meaningfully compliant --- it is meaningfully lucky.

What Compliance-as-Code Actually Means

Compliance-as-code is not a product you buy. It is a set of practices borrowed from software engineering and applied to compliance management. Five characteristics define it:

Policies defined in structured, machine-readable formats. Instead of prose buried in a Word document, control implementations are expressed in YAML, JSON, or OSCAL. Machines can parse them. Humans can still read them. But critically, they can be validated programmatically against your actual environment.

Control implementations expressed as testable assertions. "We encrypt data at rest" is a narrative. An assertion like storage_account.encryption.enabled == true is testable. The first requires a human to verify during an audit. The second runs automatically every hour and alerts you the moment it fails.

Validation against live infrastructure. Compliance checks query your actual cloud provider, your actual network configuration, your actual IAM policies --- not documentation about those things. No screenshots. No manual evidence collection.

Version control tracks every change. Policies live in a git repository. Every modification has an author, a timestamp, a commit message explaining why, and a complete history. You can diff any two versions of any policy to see exactly what changed, when, and who approved it.

Pull request reviews for policy changes. Policy modifications go through the same peer review process as code changes --- reviewers examine the diff, ask questions, request modifications, approve. The review trail becomes part of the compliance record automatically.

OSCAL: The Standard That Makes This Practical

NIST Open Security Controls Assessment Language (OSCAL) is what makes compliance-as-code viable at enterprise scale. Without a shared standard, every tool invents its own schema and interoperability dies. OSCAL provides structured, machine-readable formats for the artifacts compliance programs depend on:

System Security Plans as structured data. An OSCAL SSP is not a 200-page Word document --- it is a structured data file where each control implementation is a discrete, addressable element. You can query it, validate it, diff it, and generate human-readable documents from it. The source of truth is the data, not the rendered PDF.

Assessment results in machine-readable format. Assessment findings become structured data that can be compared across time periods, aggregated across boundaries, fed into dashboards, and tracked longitudinally --- without manual data entry or spreadsheet wrangling.

POA&Ms as structured records. Plans of Action and Milestones become trackable data records with defined schemas, linked to specific findings and remediation evidence. Not rows in a spreadsheet someone forgot to update three months ago.

Component definitions as reusable modules. Deploy the same database configuration across ten boundaries? Define its compliance posture once as an OSCAL component. Update the component, and every system referencing it inherits the change. This is inheritance done right.

FedRAMP 20x initiative is accelerating OSCAL adoption. eMASS is expanding its OSCAL ingestion. Organizations adopting OSCAL now position themselves for a future where machine-readable compliance is table stakes, not competitive advantage.

Infrastructure-as-Code Integration

Compliance-as-code becomes exponentially more powerful when it integrates with infrastructure-as-code. If your infrastructure is defined in Terraform, CloudFormation, or Pulumi, you can validate compliance before anything deploys --- shifting compliance left, into the pipeline where problems are cheapest to fix.

Pre-deploy compliance gates. Before a Terraform plan applies, compliance rules evaluate proposed changes. A deployment that would create an unencrypted storage account, open a prohibited port, or provision resources in a non-FedRAMP region fails the check and never reaches production. Compliance violations die in the pipeline, not during the next assessment.

Post-deploy drift detection. Even with IaC, infrastructure drifts. Someone makes an emergency console change. A vendor support session modifies a configuration. Compliance-as-code detects drift by continuously comparing the live environment against declared policy. Divergence triggers immediate alerting --- not discovery months later during assessment prep.

Guardrails, not gates. The goal is not to slow deployment. It is to make compliant deployment the path of least resistance. When compliance checks are automated, fast, and provide clear remediation guidance, they become guardrails that guide teams toward correct configuration rather than gates that block progress and breed workaround culture.

The Compliance Pipeline

Mature compliance-as-code implementations operate as a continuous pipeline --- analogous to CI/CD, but for compliance artifacts:

Code commit. An engineer commits a change --- a new Terraform module, a modified configuration, an updated policy definition.
Policy validation. Automated checks evaluate the change against compliance rules. Does this configuration satisfy NIST 800-53 AC-6? Does it meet CMMC Level 2 practice requirements?
Infrastructure verification. The live environment is validated against declared policy. Encryption confirmed. Network segmentation verified. Access controls tested against least-privilege assertions.
Evidence generation. Validation results are captured as structured evidence --- timestamped, cryptographically signed, linked to specific control requirements.
Multi-framework mapping. Evidence automatically maps to relevant controls across every applicable framework. One encryption check satisfies NIST 800-53 SC-28, CMMC SC.L2-3.13.16, FedRAMP SC-28, and ISO 27001 A.8.24 simultaneously.

This pipeline runs continuously. Every change triggers validation. Every validation produces evidence. Every piece of evidence maps to controls across 500+ frameworks. The compliance posture is always current, always documented, always auditable.

Continuous Validation Changes the Economics

Traditional compliance operates on a point-in-time model: prepare for assessment, demonstrate compliance during the window, operate with diminishing assurance until the next cycle. The real problem is not "audit fatigue" --- it is that point-in-time assessments provide point-in-time assurance in a continuous-threat environment.

Compliance-as-code enables continuous validation. Check encryption policy enforcement hourly, not annually. Monitor access control configurations constantly, not during audits. Generate evidence automatically as checks run, not on demand when an assessor asks.

This does not eliminate assessments. Assessors still evaluate control design, not just operation. But it transforms assessments from scrambles into walkthroughs. You enter with a continuously updated evidence package, a dashboard showing real-time compliance status, and a Git history proving every policy change was reviewed and approved.

The economic shift is significant. When you only check quarterly, a misconfiguration persists for months and the blast radius compounds. When you check continuously, mean time to detect compliance drift drops from months to minutes. Remediation cost drops proportionally --- a configuration caught in the pipeline costs five minutes of engineer time. The same configuration caught during an assessment costs weeks of POA&M management.

Versioned Rollout and Natural Audit Trails

One underappreciated benefit of compliance-as-code: the audit trail it creates is a byproduct of the workflow, not an additional burden.

Every policy change is tracked. Git provides a complete, tamper-evident history. Who changed it. When. What the previous version said. What the new version says. Why. This is not metadata you remember to capture --- it is inherent to version control.

Diff views show exactly what changed. When an auditor asks "what changed in your access control policy since the last assessment," you run a diff. Changes highlighted line by line, with full context. No comparing two Word documents side by side.

Rollback capability. If a policy change introduces problems, revert instantly. The rollback itself is tracked --- creating a record that shows the change was made, identified as problematic, and reversed, with the complete timeline.

Approval records are built in. Pull request reviews create documented approval chains. Reviewer comments, requested changes, final approvals --- all preserved. This is exactly the evidence auditors want, and it exists because the workflow produces it naturally, not because someone remembered to screenshot an email thread.

Where This Is Heading

DoD continuous Authorization to Operate (cATO) explicitly depends on automated compliance validation. FedRAMP 20x is restructuring around OSCAL-native packages. DISA is investing in automated STIG validation. The direction is unambiguous: machine-readable compliance is becoming the baseline expectation, not the aspirational target.

For defense contractors pursuing CMMC certification, organizations maintaining FedRAMP authorizations, and anyone operating under NIST 800-171 --- the window to adopt compliance-as-code while it is still differentiating is closing. The organizations treating compliance artifacts as code today will demonstrate compliance continuously, respond to audits in hours, and scale their compliance programs without proportional headcount growth.

Key Takeaways

Static compliance documents begin decaying the moment they are signed --- compliance-as-code keeps policies synchronized with live infrastructure

OSCAL is the machine-readable standard that makes interoperable compliance-as-code practical at scale

Pre-deploy validation catches compliance violations in the pipeline, where fixes cost minutes instead of weeks

Continuous validation reduces mean-time-to-detect compliance drift from months to minutes

Git-native workflows produce audit trails as a byproduct --- version history, diffs, and approval records come free

FedRAMP 20x and DoD cATO are making machine-readable compliance the baseline, not the exception

Frequently Asked Questions

Do I need to rewrite my entire SSP to adopt compliance-as-code?

No. Most organizations start by expressing their highest-risk controls as testable assertions while keeping the narrative SSP as the system of record. Over time, the machine-readable version becomes primary and the narrative document becomes a generated artifact. The migration is incremental, not big-bang.

Is OSCAL mature enough for production use?

Yes, with caveats. OSCAL 1.1.x is stable for SSPs, assessment results, and POA&Ms. Tooling is still maturing --- expect to write some custom transformation logic. But FedRAMP is already accepting OSCAL-native packages, which means the standard is production-grade for organizations willing to invest in adoption.

How does compliance-as-code handle controls that cannot be automated?

Not every control is automatable. Personnel security (PS family), physical security (PE family), and some policy-level controls require human attestation. Compliance-as-code handles these through scheduled attestation workflows --- reminders to confirm, evidence upload prompts, and expiration tracking --- while automating the technical controls that represent the bulk of the control catalog.

What is the difference between compliance-as-code and policy-as-code?

Policy-as-code is a subset. It focuses on expressing authorization and configuration policies in code (e.g., OPA/Rego rules). Compliance-as-code is broader --- it encompasses policy-as-code but adds evidence generation, multi-framework mapping, assessment automation, and continuous monitoring. Think of policy-as-code as the enforcement layer and compliance-as-code as the full lifecycle.

Does this replace the need for a C3PAO or assessor?

No. Assessors evaluate control design adequacy, organizational risk context, and systemic issues that automated checks cannot catch. Compliance-as-code makes assessments faster and more productive --- assessors spend time on judgment calls rather than evidence collection --- but it does not eliminate the need for human assessment.

How Advisedly Helps

Advisedly builds compliance-as-code into the platform architecture --- structured control implementations validated against live infrastructure, automated evidence generation mapped across 500+ frameworks, continuous drift detection, and OSCAL-native artifact production. The compliance pipeline runs 80+ enterprise tool integrations through automated validation, producing cryptographically signed evidence that satisfies assessors without the documentation treadmill. If your compliance program is still running on Word documents and annual assessment cycles, reach out at begin@advisedly.ai