Category: DevSecOps

Compliance as Code

Also known as: CaC, ComplianceAsCode, Compliance-as-Code

Simply put

Compliance as Code is the practice of expressing regulatory and policy requirements as machine-readable code so that compliance checks can be automated rather than performed manually. This approach allows organizations to continuously and consistently verify that their systems, infrastructure, and software meet required standards. By embedding compliance rules directly into development and deployment workflows, teams can detect violations earlier and reduce the effort needed for audits.

Formal definition

Compliance as Code refers to the codification of regulatory, organizational, and security compliance requirements into executable policy definitions that can be evaluated automatically against infrastructure configurations, application code, and deployment artifacts. Unlike Policy as Code, which focuses on encoding and enforcing individual policies, Compliance as Code typically takes a broader perspective, mapping codified checks to specific regulatory frameworks or standards and generating evidence of adherence. These checks may operate at the static or configuration level (for example, validating Infrastructure as Code templates or source code against known compliance violations) but may not detect all compliance issues that require runtime or deployment context, such as actual network behavior or data flow patterns observable only in a live environment. Tooling in this space, such as the ComplianceAsCode/content project, provides reusable compliance content that can be integrated into CI/CD pipelines to automatically demonstrate that new code and configurations comply with relevant policies and regulations.

Why it matters

In regulated industries such as finance, healthcare, and government, organizations must continuously demonstrate adherence to frameworks like PCI DSS, HIPAA, FedRAMP, and SOC 2. Traditionally, compliance verification has been a labor-intensive, periodic process involving manual documentation reviews and audits that can take weeks or months. During these gaps between assessments, configuration drift and newly introduced code changes may silently violate compliance requirements, leaving organizations exposed to both security risk and regulatory penalties. Compliance as Code addresses this by shifting compliance verification into the development and deployment lifecycle, enabling teams to catch violations closer to the point of introduction rather than discovering them during an audit cycle.

By codifying compliance checks, organizations also gain consistency and repeatability. Manual compliance reviews are prone to human error and subjective interpretation, which can lead to inconsistent enforcement across teams or environments. When compliance requirements are expressed as executable code, every system and artifact is evaluated against the same rule set every time, reducing variance. This approach can also significantly reduce audit preparation effort, since the automated checks themselves serve as continuously generated evidence of adherence. However, it is important to recognize that not all compliance requirements can be fully verified through static or configuration-level checks alone. Requirements that depend on runtime behavior, actual network traffic patterns, or data flow observations in live environments may still require supplementary verification methods beyond what Compliance as Code tooling typically provides.

Who it's relevant to

DevSecOps Engineers

DevSecOps engineers are responsible for embedding compliance checks into CI/CD pipelines and ensuring that automated gates enforce policy before code reaches production. They select and configure the tooling, write or customize compliance rules, and maintain the integration between compliance content libraries and build systems.

Compliance and GRC Teams

Governance, Risk, and Compliance professionals benefit from Compliance as Code because it provides continuously generated, machine-verifiable evidence of adherence to regulatory frameworks. This reduces the manual effort required for audit preparation and enables near-real-time visibility into compliance posture across the organization.

Platform and Infrastructure Engineers

Teams responsible for cloud infrastructure and platform configuration use Compliance as Code to validate that Infrastructure as Code templates, container images, and deployment configurations meet security and regulatory baselines before provisioning resources.

Security Architects

Security architects define the compliance requirements that must be codified and ensure that the scope of automated checks aligns with the organization's regulatory obligations. They also identify which requirements can be verified at the static or configuration level and which require supplementary runtime verification.

Software Development Teams

Developers encounter Compliance as Code as automated feedback within their normal workflows. When compliance checks are integrated into pull request reviews or build pipelines, developers receive early notification of violations, enabling them to remediate issues before code progresses further through the delivery process.

Auditors and Regulators

Internal and external auditors benefit from the structured, repeatable evidence that Compliance as Code generates. Machine-readable audit trails and mapped control reports can streamline the audit process, although auditors should still evaluate whether the codified checks adequately cover all aspects of the applicable regulatory requirements.

Inside CaC

Policy Definitions in Code

Machine-readable representations of regulatory, organizational, or security policies expressed in domain-specific languages or general-purpose programming languages, enabling automated interpretation and enforcement.

Automated Compliance Checks

Test suites or rule sets that validate infrastructure configurations, application settings, and deployment artifacts against codified policies, typically integrated into CI/CD pipelines.

Compliance Frameworks and DSLs

Tools and domain-specific languages such as Open Policy Agent (OPA) with Rego, Chef InSpec, and HashiCorp Sentinel that provide structured syntax for expressing and evaluating compliance rules.

Version-Controlled Policy Repositories

Storage of compliance rules in version control systems (e.g., Git), providing an auditable history of policy changes, approvals, and the ability to review policy evolution over time.

Continuous Compliance Monitoring

Ongoing, automated evaluation of systems against codified policies, often running as part of deployment pipelines or scheduled scans, to detect configuration drift or newly introduced violations.

Audit Evidence Generation

Automated production of compliance reports, test results, and attestation artifacts that can be presented to auditors, reducing manual evidence-gathering effort.

Common questions

Answers to the questions practitioners most commonly ask about CaC.

Does Compliance as Code mean my organization is automatically compliant with regulations?

No. Compliance as Code automates the checking and enforcement of compliance rules, but it does not guarantee full regulatory compliance on its own. It codifies specific technical controls and policies that can be validated programmatically, but regulatory compliance typically also requires organizational processes, documentation, human review, and controls that cannot be fully expressed or verified through code alone.

Is Compliance as Code the same as security scanning or static analysis?

No. Security scanning and static analysis tools focus on identifying vulnerabilities and code-level defects. Compliance as Code focuses on codifying and verifying adherence to policy requirements, regulatory mandates, and organizational standards. While there may be overlap (for example, a compliance policy might require that certain vulnerability checks pass), Compliance as Code is broader in scope, encompassing infrastructure configuration, access controls, data handling policies, and other non-code concerns.

What tools are commonly used to implement Compliance as Code?

Common tools include Open Policy Agent (OPA) for policy evaluation across various systems, Chef InSpec for infrastructure compliance testing, HashiCorp Sentinel for policy enforcement within the Terraform ecosystem, and AWS Config Rules or Azure Policy for cloud-specific compliance checks. The choice of tool typically depends on the target environment, the policy language preferred by the team, and integration requirements with existing CI/CD pipelines.

How do you integrate Compliance as Code checks into a CI/CD pipeline?

Compliance as Code checks are typically added as pipeline stages that run alongside or after build and test steps. Policies are stored in version control and evaluated against infrastructure definitions, configuration files, or deployment artifacts during the pipeline run. Failures can be configured to block deployments or raise alerts depending on the severity. It is important to consider that some compliance checks may require runtime or deployment context that is not available at the pipeline stage, so a layered approach with both pre-deployment and post-deployment checks is common.

How do you handle policies that cannot be fully expressed or verified in code?

Not all compliance requirements are amenable to codification. Policies involving subjective judgment, manual review processes, or organizational procedures that exist outside of technical systems may need to be tracked through complementary mechanisms such as audit logs, attestation workflows, or governance platforms. A practical approach is to codify what can be technically verified and clearly document which requirements require supplementary manual or procedural controls.

How do you manage policy drift and keep Compliance as Code definitions current?

Policy definitions should be version-controlled and subject to review processes similar to application code. When regulatory requirements or organizational standards change, the corresponding policy code must be updated, tested, and deployed. Periodic reviews comparing codified policies against current regulatory texts help identify drift. Automated reporting on policy evaluation results over time can also surface cases where previously passing resources begin to fail, indicating environmental drift rather than policy drift.

Common misconceptions

Compliance as Code eliminates the need for human auditors or compliance professionals.

Compliance as Code automates the evaluation and enforcement of codified rules, but human judgment is still required to interpret regulatory requirements, handle ambiguous scenarios, map regulations to technical controls, and validate that codified policies accurately reflect organizational obligations.

If compliance checks pass in the pipeline, the system is fully compliant.

Automated compliance checks can only validate what has been explicitly codified. They may miss runtime behaviors, business logic violations, or newly published regulatory requirements that have not yet been translated into code. Coverage depends entirely on the completeness and accuracy of the codified rules.

Compliance as Code is only relevant to infrastructure and does not apply to application security.

While commonly associated with infrastructure configuration (e.g., cloud resource policies), Compliance as Code also applies to application-level concerns such as dependency licensing checks, secrets management policies, secure coding standards enforcement, and software supply chain attestation requirements.

Best practices

Store all compliance policies in version-controlled repositories with mandatory code review and approval workflows, ensuring an auditable trail of every policy change.

Integrate compliance checks into CI/CD pipelines so that policy violations are detected early, ideally before code or infrastructure changes reach production environments.

Use established compliance-as-code frameworks (e.g., OPA/Rego, Chef InSpec, HashiCorp Sentinel) rather than writing ad-hoc scripts, to benefit from community-maintained rule libraries and consistent evaluation semantics.

Maintain a clear mapping between regulatory or organizational requirements and their corresponding codified rules, so auditors and practitioners can trace each automated check back to a specific compliance obligation.

Regularly review and update codified policies to reflect changes in regulatory requirements, threat landscape, and organizational risk posture, treating compliance code with the same maintenance rigor as production application code.

Acknowledge the scope boundaries of automated checks by supplementing Compliance as Code with periodic manual reviews, penetration testing, and runtime monitoring to address areas that static policy evaluation may not cover.