Compliance as Code: Automating SOC 2 and HIPAA Controls

SOC 2 and HIPAA audits both ask the same fundamental question: do your controls actually do what you say they do? The traditional answer is "trust me, here is a screenshot." The compliance-as-code answer is "here is the automated test that proves it, and here is its CI history."

Compliance as code is the practice of expressing security and operational controls as version-controlled, executable code that runs continuously. Done well, it shrinks audit prep from weeks to days and catches drift between policy and reality before an auditor does.

The Old World

Traditional compliance proof is documentary:

• A wiki page describing the access review process
• Screenshots taken once per quarter showing access lists
• A spreadsheet of who has admin access
• An email chain confirming "yes, we did the review"

The auditor reads the documents. They might spot-check. The whole exercise is point-in-time evidence that the controls were followed at the moment of capture.

This works, after a fashion. It also produces three predictable failures:

• Audit prep takes weeks because the evidence is scattered
• Reality drifts from policy between audits (no continuous enforcement)
• An entire person's job becomes "collect evidence for the auditor"

The New World

Compliance as code expresses controls as code that runs against the actual production environment.

# A SOC 2 control as code
control_id: CC6.1
description: "Logical and physical access controls"
checks:
  - id: prod_ssh_keys_rotated
    description: "All production SSH keys rotated within 90 days"
    schedule: daily
    implementation: |
      aws iam list-users --query 'Users[*].UserName' --output json \
        | jq -r '.[]' | while read user; do
            last_rotation=$(aws iam list-access-keys --user-name "$user" \
              --query 'AccessKeyMetadata[0].CreateDate' --output text)
            # Check is older than 90 days, fail if so
          done

The control is automated. It runs every day. The output is the evidence — when the auditor asks "did you rotate keys?", the answer is "yes, here is the report from every day of the audit period."

What to Codify

Not every control fits this model. Good candidates:

• Access reviews. Who has access to what, queried directly from IAM, SCIM, or the application's own access tables.
• Encryption checks. Are S3 buckets encrypted? Are RDS instances encrypted at rest?
• Network segmentation. Are security groups doing what they should?
• Backup verification. Are backups actually running and restorable?
• Logging completeness. Are required logs being collected?
• Vulnerability scanning. Are dependency and container scans running and passing?
• MFA enforcement. Are admin accounts using MFA?

Controls that resist codification:

• Vendor management (mostly contracts and processes)
• Incident response process adherence (the test of the process is the incident itself)
• Training completion (typically integrates with a learning management system, not the platform)
• Physical security (yes, that is still in SOC 2)

A good rule of thumb: if the control can be expressed as "X should be true of Y," it can probably be codified.

Implementation Patterns

Three patterns dominate.

Cloud-Native Scanners

AWS Config, GCP Security Command Center, Azure Policy. These tools continuously evaluate cloud resources against rules.

{
  "ConfigRuleName": "encrypted-volumes",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "ENCRYPTED_VOLUMES"
  }
}

Out-of-the-box rules cover most cloud-resource checks. Custom rules in Lambda extend the coverage.

Open Source Frameworks

• Steampipe — query cloud configuration as SQL.
• CloudQuery — similar, with broader plugin coverage.
• Cloud Custodian — policy engine for cloud resources.
• OpenSCAP — for OS-level compliance (CIS benchmarks).
• Prowler — security assessment for AWS, GCP, Azure.

These tools query cloud and infrastructure state, evaluate against rules, and produce reports. Most run as scheduled jobs in CI.

Custom Policy Code

For controls specific to your application:

# Custom check — every customer has data residency in their declared region
def check_data_residency():
    customers = db.query("SELECT id, region, primary_db_region FROM customers")
    violations = [c for c in customers if c.region != c.primary_db_region]
    return ComplianceResult(
        control_id="dr.1",
        passed=len(violations) == 0,
        violations=violations,
    )

Custom checks are where the unique parts of your environment get codified. They are also the ones most likely to rot if not maintained.

The Evidence Layer

Codified controls produce evidence — logs, reports, structured data. The evidence has to be:

• Retained for the audit period (usually 1 year for SOC 2)
• Tamper-evident (the auditor wants to trust the records)
• Indexable (so finding "did this check pass on date X?" is fast)
• Linkable to the control (each piece of evidence is tied to the control it supports)

A typical stack: control checks run on schedule → results to a database or object store → dashboards on top.

For SOC 2 specifically, services like Vanta, Drata, and Tugboat Logic productize the evidence layer. They run the checks, store results, and produce audit reports. For most teams, buying this layer is more cost-effective than building.

Audit Preparation Becomes Boring

The transformation when compliance as code works well:

Before: auditor asks for evidence of quarterly access reviews. Team scrambles to assemble proof from emails, screenshots, and Slack threads.

After: auditor asks for evidence. Team runs compliance-evidence --control=access-reviews --period=2026-Q1. Report is generated, signed, delivered.

The work has shifted from "evidence collection" to "control maintenance." When a control breaks (a check starts failing), it gets fixed; the evidence then shows continuous compliance.

What Compliance as Code Does Not Replace

Some things still need humans:

• Policy interpretation. Whether a control covers a specific scenario is a judgment call.
• Risk assessment. Codified controls do not say what risks they mitigate.
• Auditor relationship. The auditor still walks through evidence with the team.
• Continuous improvement. Reviewing whether the controls are the right controls.

Compliance as code is a tool. A team can have great automation and bad security if the controls themselves are inadequate.

Getting Started

For an organization adopting compliance as code:

1. Pick one framework first. SOC 2 is the most common starting point. HIPAA, ISO 27001, PCI DSS overlap heavily.
2. Inventory existing controls. List them with their current evidence collection process.
3. Codify the easy ones first. Access lists, encryption, backups, logging — all low-hanging fruit.
4. Buy the evidence layer. Vanta, Drata, or similar. Building this layer is months of work.
5. Iterate on the hard ones. Custom application controls, vendor management. These are slower.

Year one is usually heavy investment with modest return. Year two is when the boring-audit-prep payoff arrives.

Common Mistakes

• Treating compliance as a binary state. Reality is that some controls drift, get fixed, drift again. The continuous tracking is the point.
• Codifying controls that do not actually exist. Writing a check for "we have an incident response plan" without actually having one is theater.
• Forgetting the audit period. Evidence from yesterday does not prove last year's compliance. Retain everything for at least the audit period plus six months.
• Building tooling for things vendors already do well. Compliance vendors solved this; build only what is specific to your platform.

The Strategic Win

Compliance as code is most valuable not for the audit itself, but for the day-to-day operational hygiene it produces. Continuous evidence collection means continuous control verification — drift gets caught in real time, not at audit prep.

Teams that adopt compliance as code seriously stop dreading audits. The auditor visit becomes routine. The continuous health of controls becomes a normal engineering metric.

That shift — from compliance as project to compliance as infrastructure — is the actual benefit. The faster audits are the visible artifact; the continuous improvement is the real value.

Looking at a SOC 2 or HIPAA audit preparation cycle that has gotten expensive? We help teams codify controls and build evidence pipelines that survive audits without consuming a quarter of engineering time. scopeforged.com