Compliance as Code

Compliance as Code (CaC) is the practice of representing regulatory and security policy requirements as machine-executable code — automated tests, policy rules, configuration schemas, and infrastructure templates — stored in version control alongside the application and infrastructure code they govern. The core insight is that a compliance requirement is structurally analogous to a software requirement: it describes desired system behavior, it can be expressed as a testable assertion, and it should be version-controlled, peer-reviewed, and continuously validated. Tools enabling CaC include Open Policy Agent (OPA) with Rego policy language for access control and configuration policies; HashiCorp Sentinel for infrastructure provisioning guardrails; Checkov, KICS, and Terrascan for infrastructure-as-code security scanning; InSpec for compliance profile testing against running systems; and AWS Config Rules and Azure Policy for cloud-native policy enforcement. Each expresses compliance requirements as code that executes in the pipeline or at runtime.

A CaC implementation typically layers policies at multiple control points. At the infrastructure provisioning layer, IaC templates (Terraform, CloudFormation, Pulumi) are scanned before apply by CaC tools that enforce naming conventions, tagging requirements, encryption configurations, and network security rules. At the deployment layer, admission controllers in Kubernetes (using OPA/Gatekeeper or Kyverno) enforce pod security standards, image provenance requirements, and resource quota policies. At the configuration drift detection layer, tools like InSpec or AWS Config evaluate running system state against compliance profiles on a scheduled or event-triggered basis. These layers collectively implement a defense-in-depth compliance enforcement model where policy violations are blocked, detected, or alerted at the earliest possible control point — reducing both the probability of non-compliant systems reaching production and the cost of remediation.

The most important nuance of Compliance as Code is the governance of the compliance code itself. Policy code that is incorrect, incomplete, or outdated is more dangerous than no policy code — it creates false assurance that controls are in place when they are not. CaC policies must themselves be tested: unit tests for policy logic (does this OPA policy correctly deny the non-compliant case and allow the compliant case?), integration tests against representative infrastructure configurations, and regression tests when policy code changes. The policy repository must have a defined ownership model, a change approval process separate from (but integrated with) the application development workflow, and a process for ingesting regulatory changes and updating policy code accordingly. Organizations that treat compliance code as second-class infrastructure — without tests, without review gates, without ownership — accumulate compliance technical debt as rapidly as they accumulate software technical debt.

We build CaC policy libraries mapped to your specific compliance frameworks — authoring OPA policies, Checkov custom checks, and InSpec profiles with full test suites that validate both denial of non-compliant configurations and allowance of compliant ones. Policy repositories follow the same review, approval, and deployment workflow as application code, with required review by both engineering and compliance stakeholders for any policy change. We maintain an update process that translates regulatory change notifications into policy code change tickets with defined SLAs, ensuring compliance code stays current with framework revisions.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.