Compliance as Code for SOC2 / PCI-DSS Pipelines

The Challenge

The traditional compliance approach — manual evidence collection, quarterly reviews, spreadsheet-driven control tracking — is slow, error-prone, and creates a perverse incentive: teams focus on looking compliant during audit windows rather than being compliant continuously. The audit becomes a scramble rather than a snapshot of ongoing practice.

The result is drift. Between audits, resources get misconfigured, access controls loosen, logging lapses. An S3 bucket gets made public for a quick demo and nobody changes it back. An IAM policy gets broadened to debug an issue and the tighter version never gets restored. When the auditor returns, you're playing catch-up — and the evidence you collect doesn't reflect actual control operation, because the controls haven't actually been operating.

Compliance as Code replaces that cycle with automated enforcement and continuous evidence collection. The OPA policy that prevents non-encrypted S3 buckets from being created doesn't care whether it's the week before the audit or the week after. Controls are either passing continuously or failing with an alert — there's no "compliant during audit season" gray zone.

Signs You Need This

• Your SOC2 or PCI-DSS evidence collection is a manual, multi-week effort before each audit
• Compliance controls are documented in policies but not technically enforced — they rely on engineers following process
• Infrastructure drift is discovered during audits rather than caught in real-time
• You have no automated way to verify that a newly created resource meets your compliance requirements
• Your auditor has flagged the same control deficiencies in consecutive audits
• You're expanding into enterprise sales where prospects ask for SOC2 Type II reports and you don't have one

How We Approach It

# OPA Rego — block S3 buckets without server-side encryption (PCI-DSS 3.5)
package terraform.aws.s3

import future.keywords.if

deny[msg] if {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_s3_bucket"
    not has_encryption(resource)
    msg := sprintf(
        "S3 bucket '%s' must have server-side encryption enabled (PCI-DSS 3.5 / SOC2 CC6.7)",
        [resource.name]
    )
}

has_encryption(resource) if {
    resource.values.server_side_encryption_configuration[_].rule[_].apply_server_side_encryption_by_default[_].sse_algorithm
}

# Block public RDS instances (SOC2 CC6.1)
deny[msg] if {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_db_instance"
    resource.values.publicly_accessible == true
    msg := sprintf("RDS instance '%s' must not be publicly accessible", [resource.name])
}

# Block SSH open to the world (CIS AWS 4.1)
deny[msg] if {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_security_group_rule"
    resource.values.type == "ingress"
    resource.values.from_port <= 22
    resource.values.to_port >= 22
    resource.values.cidr_blocks[_] == "0.0.0.0/0"
    msg := sprintf("Security group '%s' must not allow SSH from 0.0.0.0/0", [resource.name])
}

---
# GitHub Actions — OPA + Checkov gate in Terraform CI
- name: Run Checkov IaC Scan
  uses: bridgecrewio/checkov-action@master
  with:
    directory: infra/
    framework: terraform
    check: CKV_AWS_*         # All AWS-specific Checkov policies
    soft_fail: false          # Fail the pipeline on any violation
    output_format: sarif
    output_file_path: checkov-results.sarif

- name: Run OPA Policy Gate
  run: |
    terraform show -json tfplan.binary > tfplan.json
    opa eval --input tfplan.json \
             --data policies/ \
             --format pretty \
             "data.terraform.aws.s3.deny" | tee opa-results.json
    # Fail CI if any OPA deny rules fired
    jq -e '. | length == 0' opa-results.json

Tools We Use

These tools form a layered defense — policy enforcement at deploy time, continuous monitoring at runtime, and automated evidence collection for audit.

Common Mistakes We Prevent

• Writing compliance controls as documentation and checklists rather than code — a policy document doesn't stop anyone from creating a public S3 bucket
• Enabling AWS Config rules but not routing findings to actionable alerts — Config rules that nobody watches don't prevent drift, they just detect it passively
• Scoping compliance controls too broadly, including resources that aren't actually in-scope for the audit framework, which creates unnecessary remediation work
• Building evidence collection as a manual process that depends on a specific person — one turnover event and your evidence continuity is broken

What You Get

• Policy-as-code repository with OPA/Checkov rules mapped to your compliance framework controls
• Terraform CI gate that blocks non-compliant infrastructure changes from reaching any environment
• AWS Config rules for continuous drift detection across all critical controls
• EventBridge + SNS alert routing for compliance violations to your security channel
• Automated evidence collection pipeline with structured S3 archive organized by control ID
• Security Hub compliance dashboard configured for your target standard (CIS, PCI-DSS, SOC2)
• Control mapping document formatted for auditor handover with evidence pointers

Timeline & What to Expect

After handover, the controls run autonomously. You'll receive weekly compliance score summaries and immediate alerts for any violations. We recommend a quarterly review of the control mapping as your architecture evolves to ensure new services are brought into scope correctly.

Frequently Asked Questions

When This Is the Right Fit

This engagement is right for companies pursuing SOC2 Type II certification, preparing for PCI-DSS assessment, or responding to enterprise customer security requirements. It's particularly valuable when you have an audit date within the next 6–12 months and need to close the gap between your documented policies and your actual technical controls. Teams that have been through a manual audit cycle and want to automate the next one get immediate and obvious value.

This is not the right fit if you're at a very early stage and have no compliance requirements yet — the overhead of maintaining compliance controls before you need them isn't worth it. Start with the basics (GuardDuty, CloudTrail, encryption) and engage us for the compliance framework overlay when you have a specific audit target or an enterprise customer making it a requirement.