Skip to main content
Back to InsightsCybersecurity

Compliance as Code: Automating SOC 2, HIPAA, and GDPR Readiness

JNV.AI Team·December 19, 2025·5 min read

The Spreadsheet Problem

Every enterprise that has been through a compliance audit knows the drill. Weeks before the audit, teams scramble to gather evidence. Screenshots get taken. Spreadsheets get filled out. People dig through logs trying to prove that a control was in place six months ago.

It's painful, repetitive, and inefficient. Worse, it only gives you a snapshot. The day after the audit, a configuration could drift out of compliance and nobody would know until the next audit cycle.

The NIST Cybersecurity Framework 2.0 (released February 2024) emphasizes continuous monitoring and automated assessment for exactly this reason. Compliance that's only verified once or twice a year is compliance theater.

What Compliance as Code Means

Compliance as code is the practice of expressing compliance controls as machine-readable policies that are automatically and continuously enforced against your infrastructure.

Instead of a spreadsheet saying "all S3 buckets must have encryption enabled," you write a policy rule that checks every S3 bucket in your account and flags or remediates any that don't have encryption configured. That rule runs continuously, not just before an audit.

The result is a shift from periodic, manual compliance verification to real-time, automated compliance enforcement.

The Technology Stack

Several tools have matured enough to make this practical for enterprises.

Open Policy Agent (OPA) is the most widely adopted general-purpose policy engine. You write policies in Rego (OPA's declarative language) and evaluate them against any structured data: Terraform plans, Kubernetes admission requests, API authorization decisions. OPA is cloud-agnostic and integrates with most infrastructure tooling.

Cloud-native policy services like AWS Config Rules, Azure Policy, and GCP Organization Policy Controller provide built-in compliance checking within each cloud provider. They're easier to set up than OPA for provider-specific rules but don't work across clouds.

Infrastructure as Code scanners like Checkov, tfsec, and Bridgecrew analyze your Terraform, CloudFormation, or Kubernetes manifests before deployment. They catch compliance violations at the pull request stage, before misconfigured resources ever reach production.

Compliance platforms like Vanta, Drata, and Lacework automate evidence collection and map your controls to specific compliance frameworks. They sit on top of the technical enforcement layer and generate the documentation auditors need.

Mapping Controls to Automation

The practical work of compliance as code is mapping each control requirement to an automated check. Here's how that looks for three common frameworks.

SOC 2

SOC 2's trust service criteria (security, availability, processing integrity, confidentiality, privacy) translate well to automated checks.

  • CC6.1 (Logical Access): Automated IAM policy checks. No overly permissive roles. MFA required for all human users. Service accounts scoped to minimum necessary permissions.
  • CC6.6 (System Boundaries): Network policy enforcement. Security groups and firewall rules continuously validated. No open 0.0.0.0/0 ingress rules on sensitive services.
  • CC7.2 (Monitoring): Automated checks that logging is enabled on all critical services, log retention meets requirements, and alerting is configured for security events.

HIPAA

HIPAA's technical safeguards have direct infrastructure parallels.

  • Access Control (164.312(a)): Automated validation of role-based access controls on systems handling PHI. Regular access reviews surfaced automatically.
  • Encryption (164.312(a)(2)(iv)): Policy rules that enforce encryption at rest and in transit for all databases, storage systems, and API endpoints handling protected health information.
  • Audit Controls (164.312(b)): Continuous verification that audit logging is active and complete for systems in scope. Automated alerts when logging gaps are detected.

GDPR

GDPR's technical requirements around data protection map to enforceable policies.

  • Data Minimization (Art. 5(1)(c)): Automated scanning for sensitive data fields in databases and object stores to ensure data collection aligns with stated purposes.
  • Encryption (Art. 32): Same encryption-at-rest and in-transit checks as HIPAA, applied to systems handling EU personal data.
  • Data Residency (Art. 44-49): Policy rules that prevent provisioning of resources in regions outside approved data processing jurisdictions.

Compliance as Code implementation path: Visibility, Prevention, Enforcement, and Evidence

The Implementation Path

Rolling out compliance as code doesn't require a big-bang transformation. A phased approach works best.

Phase 1: Visibility. Deploy cloud-native config rules or a compliance platform to scan your existing infrastructure. Don't enforce anything yet. Just see where you stand. This alone is usually eye-opening.

Phase 2: Prevention. Add pre-deployment checks to your CI/CD pipeline using IaC scanners. Catch violations before they reach production. Start with the highest-risk controls and expand over time.

Phase 3: Enforcement. Turn on admission controllers (for Kubernetes) and real-time remediation (for cloud resources) that automatically block or fix non-compliant configurations. This is the final step and requires confidence in your policies.

Phase 4: Evidence. Connect your automated checks to a compliance platform that generates audit-ready evidence. When the auditor arrives, you hand them a dashboard, not a stack of spreadsheets.

The ROI

Organizations that adopt compliance as code consistently report 60 to 80 percent reductions in audit preparation time. But the bigger win is the shift from reactive to proactive compliance. You catch misconfigurations in minutes, not months. Audits become a formality because you have continuous evidence rather than point-in-time snapshots.

And because compliance checks run in your deployment pipeline, developers get immediate feedback when they write something non-compliant. Over time, teams internalize the requirements and produce compliant code by default.

Getting Started

Pick one framework (SOC 2 is usually the most accessible starting point). Map its controls to your infrastructure. Deploy a scanning tool in observation mode. Fix the most critical findings. Then start shifting enforcement left into your deployment pipeline.

The goal isn't perfect compliance on day one. It's a system that gets better automatically and gives you confidence that your controls are working right now, not just the last time someone checked.

Want to discuss this topic?

Book a free consultation with our team to explore how these insights apply to your organization.