Compliance as Code: Automating What Auditors Want

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 five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Each criterion includes multiple control points. 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 the most common compliance framework for SaaS companies. 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 the areas auditors spend the most time on.

ISO 27001

ISO 27001 is more structured than SOC 2, with a specific set of controls in Annex A. 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 are specific enough to map directly to automated rules: access controls, audit controls, integrity controls, 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.