top of page

Compliance as Code: Automating What Auditors Want

S. West
Jun 14, 2025
7 min read

Updated: 4 days ago

Corrected, 4 October 2026. We checked this post's framework details against the source standards. The HIPAA safeguard list had left out person or entity authentication, and two claims about SOC 2 are now qualified.

Compliance in most organizations looks like this: once a year, someone from the security team sends a spreadsheet to every engineering team asking them to document their controls. The engineering teams fill in the spreadsheet based on what they think is true. The security team compiles the responses into a report. An auditor reviews the report, asks some follow-up questions, and issues a finding. Everyone goes back to work until next year.


This process is expensive, inaccurate, and adversarial. Engineering teams view it as overhead. Security teams view it as insufficient. Auditors view it as the best they can get. And the actual security posture of the organization is only loosely correlated with what ends up in the report.


There is a better way: encode your compliance requirements as code, evaluate them continuously, and generate evidence automatically. This is compliance as code, and it changes compliance from a periodic burden into a continuous property of your system.


What Compliance as Code Means


Compliance as code is the practice of expressing regulatory requirements, security policies, and organizational standards as machine-readable rules that can be automatically evaluated against your actual infrastructure, code, and processes.


Instead of a policy document that says "all S3 buckets must be encrypted at rest," you write a rule that queries your AWS account and checks whether each S3 bucket has server-side encryption enabled. Instead of a manual review of access controls, you write a rule that verifies IAM policies conform to least-privilege requirements. Instead of asking teams to self-report their logging practices, you write a rule that verifies logging is configured correctly in each service.


The output is not a filled-in spreadsheet. It is a continuously updated record of which controls are passing and which are failing, with evidence that can be presented directly to auditors.


The Tools


Open Policy Agent (OPA)


OPA is the most widely used policy-as-code engine. It uses a declarative language called Rego to express policies, and it can evaluate those policies against arbitrary JSON data — infrastructure configurations, API requests, Kubernetes manifests, Terraform plans, or any other structured data.


OPA is commonly used for Kubernetes admission control (ensuring that pods meet security requirements before they are deployed), Terraform plan validation (catching misconfigurations before they are applied), API authorization (making fine-grained access control decisions), and data filtering (ensuring that query results comply with data access policies).


The learning curve for Rego is real but manageable. The language is purpose-built for policy evaluation, and once you understand the evaluation model, writing rules is straightforward.


HashiCorp Sentinel


Sentinel is HashiCorp's policy-as-code framework, tightly integrated with Terraform, Vault, Consul, and Nomad. If your infrastructure stack is HashiCorp-centric, Sentinel provides a natural way to enforce policies on infrastructure changes.


Sentinel policies can enforce requirements like "no security group may allow ingress from 0.0.0.0/0," "all resources must be tagged with a cost center," and "Vault secrets must be rotated every 90 days." Policies are evaluated as part of the Terraform plan-and-apply workflow, preventing non-compliant changes from being applied.


Cloud-Native Tools


Each major cloud provider offers policy and compliance tooling:


AWS Config Rules evaluate whether your AWS resources comply with desired configurations. AWS provides managed rules for common compliance requirements and supports custom rules written in Lambda functions. Combined with AWS Config's configuration history, this provides a continuous audit trail.


Azure Policy evaluates Azure resources against organizational standards. Policies can audit, deny, or automatically remediate non-compliant resources. Azure Blueprints combine policies, role assignments, and resource templates into repeatable compliance packages.


Google Cloud Organization Policies define constraints on resource configurations across a GCP organization. Combined with Security Health Analytics and the Security Command Center, this provides visibility into compliance posture.


Mapping Controls to Code


The hardest part of compliance as code is not writing the rules. It is mapping regulatory requirements to specific, testable assertions.


Take SOC 2, for example. SOC 2 is organized around the AICPA's five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is required in every SOC 2 report; the other four are included when they're relevant to the service. Each criterion includes multiple control points, and each control point needs to be translated into one or more automated checks.


The control "The entity uses encryption to protect data in transit" might map to several rules: TLS is required on all load balancers, database connections use SSL, API endpoints reject HTTP requests, and internal service-to-service communication uses mutual TLS.


The mapping process requires understanding both the regulatory framework and your technical architecture. It is not purely a technical exercise — it requires judgment about what constitutes adequate evidence for each control.


A Practical Approach


Start with your most recent audit findings. For each control that was manually verified, ask: can this be automatically checked? If yes, write a rule. If no, can you get closer to automation by improving instrumentation or logging?


Focus on the controls that are most expensive to verify manually and most likely to drift over time. Encryption settings, access controls, logging configurations, and network segmentation are good starting points because they are both important and testable.


Continuous Compliance vs. Point-in-Time Audits


Traditional compliance is point-in-time: an auditor checks your controls on a specific date and issues a report that covers a specific period. Between audits, you could be non-compliant and nobody would know.


Continuous compliance changes this dynamic. When policies are evaluated automatically on every change, non-compliance is detected immediately. You do not discover during the annual audit that someone disabled encryption on a storage bucket six months ago — you discover it the minute it happens.


This has several benefits. It reduces audit preparation time because evidence is generated continuously. It reduces the blast radius of compliance failures because they are caught early. It improves actual security because controls are enforced in real time. And it changes the relationship with auditors from adversarial (prove you are compliant) to collaborative (here is our continuous evidence stream).


Building Compliance Into CI/CD


The most effective place to enforce compliance is in the deployment pipeline — before non-compliant changes reach production.


Pre-Commit and Pre-Merge


Static analysis tools can catch compliance issues in code before it is merged. Secret scanning (no credentials in code), dependency vulnerability scanning (no known-vulnerable dependencies), and configuration linting (no insecure defaults) should run on every pull request.


Plan-Time Validation


For infrastructure changes, evaluate compliance during the plan phase — after Terraform generates a plan but before it is applied. This catches issues like public storage buckets, overly permissive security groups, and unencrypted resources before they exist.


Deployment Gates


Automated checks that must pass before a deployment proceeds. These can include compliance rule evaluations, security scan results, and approval workflows for changes that affect compliance-sensitive systems.


Post-Deployment Verification


After deployment, verify that the actual state matches the expected state. Configuration drift — where the running system diverges from the declared configuration — is a common source of compliance failures.


SOC 2, ISO 27001, and HIPAA: Practical Considerations


SOC 2


SOC 2 is one of the attestations SaaS customers ask for most often, particularly in the US market. It is principles-based rather than prescriptive, which means there is flexibility in how you implement controls. This flexibility is both an advantage (you can tailor controls to your architecture) and a challenge (you need to justify your choices to auditors).


For SOC 2, focus on automating evidence for access controls, change management, monitoring and alerting, incident response, and data protection. These are areas auditors commonly scrutinize, and they generate evidence continuously.


ISO 27001


ISO 27001 is more structured than SOC 2, with a defined control set in Annex A (93 controls in the 2022 revision). The mapping from controls to automated checks is more direct. Many organizations pursue both SOC 2 and ISO 27001, and the overlap is significant — automating controls for one framework provides substantial coverage for the other.


HIPAA


HIPAA's technical safeguards (45 CFR 164.312) are specific enough to map directly to automated rules: access control, audit controls, integrity, person or entity authentication, and transmission security. The challenge with HIPAA is that it also includes administrative safeguards (policies, training, risk assessments) that are harder to automate.


For HIPAA, focus on automating what you can — encryption verification, access logging, transmission security — and use automated evidence generation to support the administrative controls that require human judgment.


Getting Started


You do not need to automate everything at once. Start with the controls that cause the most pain during audits. Write rules for those controls. Generate evidence automatically. Present that evidence to your auditor during the next review cycle.


Most auditors are receptive to automated evidence — it is more reliable than self-reported spreadsheets and easier to verify. Some auditors are unfamiliar with the approach and may need education. Show them the rules, explain how they work, and demonstrate that the evidence is generated from actual system state rather than manual reporting.


Over time, expand coverage. Each audit cycle, convert more manual controls to automated checks. Within a few cycles, the majority of your compliance evidence can be generated automatically, the audit preparation burden drops dramatically, and your actual compliance posture improves because controls are enforced continuously rather than checked annually.


Compliance as code is not about making compliance easy. It is about making compliance accurate, continuous, and embedded in the engineering workflow where it belongs.



Sources



Related reading


bottom of page