Compliance as Code: Automating SOC 2, ISO 27001, and HIPAA for Cloud Infrastructure Without the Audit Fire Drill

Around 2017 I watched a company lose a $3 million enterprise deal because they couldn’t produce a SOC 2 Type II report in time. The security team knew their controls were solid. The AWS environment was locked down, least-privilege IAM everywhere, encryption at rest and in transit, MFA enforced. But none of it was documented in a way an auditor could verify, and when the procurement team at the target customer asked for the report, the answer was “we’re working on it.” The deal went to a competitor who had their paperwork in order.

What followed was the compliance fire drill I have seen dozens of times since: six months of engineers pulled off product work to gather screenshots, export CloudTrail logs, fill out spreadsheets about who had access to what, and chase down evidence for controls they were already implementing but had never documented. The audit firm billed $80,000. Engineers complained for a year.

Compliance does not have to work that way. When you treat compliance controls as code rather than as paperwork, the audit becomes a formality. This article is about how to build that system.

What Compliance Frameworks Actually Want From You

Before writing a line of code or buying any tooling, understand what SOC 2, ISO 27001, and HIPAA are actually asking for. They are not lists of specific technologies to implement. They are control frameworks.

SOC 2 is built around five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. Most companies only need the security criterion for a Type II report. That criterion maps to things like: logical access controls, change management, risk assessment, incident response, and monitoring for anomalous activity. The auditor’s job is to verify that those controls exist and operated continuously over the audit period (typically six to twelve months).

ISO 27001 is similar but organized around an Information Security Management System (ISMS). The 2022 revision added explicit controls for cloud security, secure coding practices, and data masking that directly overlap with what you’re already doing with IaC and container hardening.

HIPAA adds a healthcare twist: the Security Rule requires administrative, physical, and technical safeguards for electronic Protected Health Information (ePHI). Technical safeguards map cleanly to encryption, access controls, audit logging, and transmission security, all of which you can express as infrastructure code and verify automatically.

The key insight is that the auditor does not care whether you achieved your controls via Checkov CI gates or a manual policy document. They care whether the controls were in place and effective across the entire audit period. That is exactly what continuous, automated compliance monitoring can prove.

The Three-Layer Architecture

I build compliance automation in three layers that stack on each other. Each layer catches a different class of control failure.

Layer one is IaC scanning: catching misconfigurations before they deploy. Layer two is cloud resource monitoring: continuously verifying your actual cloud state matches your intended state. Layer three is a compliance platform that pulls evidence from layers one and two and maps it to framework control objectives automatically.

You can start with any layer, but I usually recommend starting at layer one because it catches problems cheapest, prevents drift from accumulating, and immediately produces audit artifacts.

Layer One: IaC Scanning With Checkov and Terrascan

Checkov from Bridgecrew (now Prisma Cloud) is the tool I reach for first. It understands Terraform, CloudFormation, ARM templates, Kubernetes manifests, Helm charts, and Dockerfiles. It ships with 750+ built-in checks mapped to CIS benchmarks, NIST, HIPAA, PCI DSS, and SOC 2.

A Checkov scan in CI looks like this:

checkov -d . --framework terraform \
  --check CKV_AWS_18,CKV_AWS_67,CKV_AWS_86 \
  --output junitxml > checkov-results.xml

The --output junitxml flag produces XML that CI systems like GitHub Actions, GitLab, and Jenkins can ingest as test results. That XML is also audit evidence. Every CI run produces a timestamped record of which controls passed and which failed before any Terraform was applied.

For the framework mapping, Checkov ships with a --compliance flag:

checkov -d . --compliance hipaa

This runs only the checks mapped to HIPAA technical safeguards. The output tells you which resource types failed which HIPAA controls. When the auditor asks for evidence of encryption at rest across your S3 buckets and RDS instances, you hand them six months of CI logs showing that check ran and passed on every deployment.

Terrascan from Tenable is a good complement. It uses OPA policies under the hood, which means you can write custom compliance checks in Rego when your organization has controls that do not map to a built-in check. For example, if your tagging policy requires a data-classification tag on every resource containing PII, you can write that as a Rego policy and enforce it in CI with zero additional tooling.

For Kubernetes specifically, run kube-bench as part of your node provisioning pipeline to verify CIS benchmark compliance, and add Trivy to your container image scanning. Both produce machine-readable output that feeds into your evidence store. The Kubernetes security hardening article covers the full CIS benchmark implementation in detail.

The infrastructure-as-code fundamentals that make this all work are covered in the Terraform, Pulumi, and CloudFormation guide. If you are still doing point-and-click in the console, you need to solve that before compliance automation will help you.

Layer Two: Cloud Configuration Monitoring

IaC scanning catches drift before it ships, but it does not catch manual console changes, API calls that bypass Terraform, or inherited resources from acquisitions. Layer two monitors the actual state of your cloud.

AWS Security Hub is the right starting point on AWS. Enable it with the CIS AWS Foundations Benchmark standard and the AWS Foundational Security Best Practices standard. Security Hub aggregates findings from GuardDuty, Amazon Inspector, Macie, and Config Rules into a single interface with severity scoring and compliance status by control.

The Config Rules component is what makes this useful for audits. AWS Config continuously records resource configuration changes. Rules evaluate those configurations against your controls in real time. When the rule restricted-ssh fires because someone opened port 22 to 0.0.0.0/0 in a security group, you have a timestamped finding with the resource ID, the offending change, and who made it via CloudTrail. That is exactly what an auditor wants to see for the change management and access control criteria.

For GCP, the equivalent is Security Command Center. For Azure, it is Microsoft Defender for Cloud. All three expose APIs that layer three platforms can query automatically.

The relationship between Security Hub and CNAPP tools like Wiz and Prisma Cloud is worth understanding. CNAPP tools build on top of native cloud controls and add cross-account visibility, attack path analysis, and framework-specific compliance dashboards. For a single-account startup, Security Hub alone may be sufficient. For a multi-account enterprise, a CNAPP is worth the cost because it normalizes findings across accounts and cloud providers into a single compliance view.

Layer Three: Continuous Compliance Platforms

Checkov and Security Hub are tools that engineers interact with. The compliance platform is what the compliance team and auditors interact with. It translates engineering evidence into framework control language.

Vanta is the market leader for startups. It integrates with AWS, GCP, Azure, GitHub, Jira, Okta, and about 200 other tools. It automatically pulls your cloud configuration data, maps it to SOC 2 trust service criteria and ISO 27001 Annex A controls, and maintains a continuously updated compliance score. When an S3 bucket is publicly accessible, Vanta flags it as a failure against the specific SOC 2 criterion and creates a linked task for your team to remediate.

The key value is not the dashboard. It is the evidence library. Vanta stores timestamped evidence of every control check automatically. When audit time comes, instead of chasing screenshots for three months, you grant the auditor read access to your evidence library. I have seen Type II SOC 2 audits go from 180 hours of engineering time to fewer than 30 hours when a company had Vanta configured for the full twelve-month audit period.

Drata and Sprinto are strong Vanta alternatives. Drata has deeper developer workflow integrations and tends to work better for engineering-led security teams. Sprinto is more cost-competitive for seed-stage companies or those pursuing ISO 27001 and SOC 2 simultaneously. Secureframe is worth considering if you need FedRAMP or DoD frameworks.

What these platforms do not replace is your obligation to implement the controls in the first place. A compliance platform with a green dashboard but a misconfigured AWS account is just expensive window dressing. The value chain is: Checkov in CI catches misconfigs before they ship, Security Hub monitors what does ship, and Vanta/Drata/Sprinto prove to auditors that your controls worked continuously.

Wiring It Into CI/CD

A practical implementation for a Terraform-managed AWS environment looks like this:

Pre-commit: Run checkov -d . --soft-fail locally so engineers see findings before they push. Soft fail means the commit is not blocked, but the output is visible. Hard block controversial in most teams; soft block with a required PR comment is a reasonable middle ground.

Pull request gate: A GitHub Actions step that runs Checkov with --hard-fail-on HIGH prevents high-severity findings from merging. Map your hardcoded thresholds to the frameworks you are certifying against. For SOC 2, at minimum you want to block: public S3 buckets, unencrypted EBS volumes, security groups open to the world, IAM policies with *:* permissions.

Post-apply monitoring: After terraform apply, a Lambda function triggered by CloudTrail events can run Config Rules evaluations and push results to Security Hub. This closes the gap between the IaC scan and the live environment verification.

Evidence export: Weekly or monthly, export Security Hub findings to S3 in JSON format. This creates a durable, queryable evidence archive independent of any compliance platform. Your audit evidence should live somewhere you own, not just in a SaaS vendor’s database that you lose access to if you cancel the subscription.

The GitOps with ArgoCD and Flux workflow fits cleanly here: if every infrastructure change flows through a Git pull request, you automatically have a change log with author, approver, and timestamp for every modification. Change management evidence is one of the most tedious controls to document manually and one of the most automatic to produce when you have GitOps.

Secrets Management as a Compliance Control

A control that trips up almost every first SOC 2 audit is credential management. The auditor will ask for evidence that your application secrets are not stored in plaintext in source code, environment variables, or configuration files. They will also ask for evidence of periodic credential rotation.

The secret management with Vault and AWS Secrets Manager article covers the technical implementation. From a compliance perspective, the key capabilities you need to document are: secrets stored in a dedicated secrets manager (not in .env files or SSM Parameter Store as plain strings), access to secrets controlled by IAM/RBAC policies, and rotation policies configured for credentials with rotation periods the framework requires (HIPAA’s requirements vary by credential type).

Dynamic secrets from Vault, where database credentials are generated per-request with a short TTL and never stored, are the gold standard for compliance because there is no static credential to rotate or compromise. But even moving from .env files to AWS Secrets Manager is a major compliance win that most auditors will accept.

What Does Not Automate

I want to be honest about the limits of compliance as code, because teams sometimes deploy all of this tooling and then discover they still have a manual compliance problem.

Vendor risk management does not automate well. SOC 2 requires you to assess the security posture of your significant vendors (cloud providers, SaaS tools you use, subprocessors). You need a process for reviewing vendor SOC 2 reports, assessing risk, and documenting your decisions. Some of this is spreadsheet work.

Employee security training requires a human attestation. Tools like Vanta integrate with training platforms and track completion, but someone has to design the training curriculum and verify that it is appropriate for your risk profile.

Access reviews are partly automated (Vanta and Okta can generate access reports showing who has access to what) but still require a human to review and attest that each person’s access is appropriate. Quarterly access reviews are a SOC 2 requirement that cannot be fully automated.

Incident response documentation requires a human narrative. You can automate detection (GuardDuty, Falco, Security Hub) and notification (PagerDuty, incident.io), but the post-incident review, root cause analysis, and corrective action documentation is human work. See the article on incident management for how to build a structure that makes this easier.

Risk assessment is the most underappreciated manual process. SOC 2 and ISO 27001 both require an annual risk assessment that identifies threats to your systems, evaluates likelihood and impact, and documents your risk treatment decisions. This is a structured thinking exercise that tooling supports but cannot replace.

Framework-Specific Nuances

If you are pursuing multiple frameworks simultaneously, understanding their overlaps saves duplication.

SOC 2 and ISO 27001 have roughly 80% control overlap. The main difference is that ISO 27001 requires a formal ISMS with documented scope, policy documents, internal audit program, and management review. SOC 2 is more flexible about documentation format but stricter about the evidence of operational effectiveness during the audit period. If you are going for both, ISO 27001’s ISMS documentation actually helps with the SOC 2 audit because it provides the written policies the auditors ask for.

HIPAA adds the concept of a Business Associate Agreement (BAA) with every vendor that handles ePHI. Your AWS account (if you use it for ePHI) needs a BAA with AWS, which means using HIPAA-eligible services only. The full list is published by AWS. Checkov has HIPAA-specific policies that flag use of non-HIPAA-eligible services.

PCI DSS is the hardest to automate because it requires network segmentation verification (your cardholder data environment must be provably isolated from the rest of your infrastructure) and penetration testing. If you are in scope for PCI, invest in a CNAPP with PCI-specific compliance views and budget for annual pen testing.

For GDPR and data residency requirements, the cloud sovereignty and data residency article covers the architectural controls. GDPR is not an audit framework in the same sense as SOC 2, but demonstrating data residency and encryption controls to enterprise customers who ask is essentially the same exercise.

Connecting Policy Enforcement to Compliance Evidence

One integration that is underused is connecting your Kubernetes admission control layer to your compliance evidence. If you are using OPA and Kyverno for Kubernetes policy enforcement, those policy decisions are logged. Every time a pod is rejected for running as root or using a privileged container, that is evidence that your access control and container security controls are working.

Export OPA audit logs and Kyverno policy violation logs to your SIEM or directly to S3. Timestamp-stamped policy enforcement logs are exactly the kind of operational evidence that makes auditors comfortable with your access control and secure configuration controls. It is far more convincing than a screenshot of a dashboard.

My Recommendations by Stage

For a seed-stage startup preparing for first SOC 2: Start Checkov in CI immediately, even before you care about compliance. Get Vanta or Sprinto running six months before your audit start date so the evidence period is covered. Enable AWS Security Hub on day one. Budget around $25,000 total for the first year including the audit firm.

For a Series B company adding ISO 27001: You probably have Vanta or Drata already. The additional work is the ISMS documentation, internal audit program, and management review cycle. ISO 27001 is worth doing if you are selling into European enterprise, government, or regulated industries. Many large enterprise buyers require it.

For an enterprise engineering team: Move to a CNAPP (Wiz, Prisma Cloud, Lacework) for multi-account visibility, add Terrascan with custom Rego policies for organization-specific controls, and consider building an internal compliance evidence pipeline into S3 or your data platform rather than depending entirely on a SaaS compliance tool. Continuous compliance at enterprise scale is an engineering product, not a vendor subscription.

The company that lost that $3 million deal in 2017 eventually got their SOC 2 Type II report. It took eighteen months from the point when they started and cost more than the compliance platform and audit combined in engineering time. The next time they went through the audit cycle, with Checkov in CI and a continuous monitoring platform running, the engineering team spent about twenty hours total and the audit was done in six weeks. That delta is what compliance as code buys you: not just the certificate, but the return of your engineering team’s time to building product.

Related reading: CNAPP and Cloud-Native Application Protection covers the security tooling layer. Policy as Code with OPA and Kyverno covers Kubernetes-layer enforcement. Cloud Sovereignty and Data Residency covers the cross-border data requirements that layer on top of these frameworks.