Audit Evidence: What Compliance.tf Produces for Your Auditor

Compliance.tf modules generate three layers of compliance evidence: prevention (module enforcement makes non-compliant deployment impossible), pre-apply verification (IaC scans confirm plan compliance before deployment), and post-apply verification (infrastructure scans confirm deployed resources are compliant). The sections below cover each layer, how to generate its artifacts, and what SOC 2, PCI DSS, and HIPAA auditors expect to see.

Who this is for: Compliance managers and CISOs evaluating audit readiness, platform leads preparing evidence packages, and engineering leads automating evidence generation in CI/CD.

The Three Evidence Layers

Compliance.tf produces audit evidence at three stages of the infrastructure lifecycle. Each layer generates distinct artifacts with different levels of auditor trust.

Layer 1: Prevention (Module-Level Enforcement)

Compliance.tf modules enforce controls at the Terraform source level. Non-compliant configurations cannot be deployed because the module code prevents them at terraform plan time.

Evidence artifacts:

• Module source code showing hardcoded compliance settings
• Terraform plan output showing enforced values
• Registry source URL demonstrating framework-specific endpoint usage (e.g., soc2.compliance.tf/...)

Auditor narrative: "We use infrastructure-as-code modules that enforce compliance controls. Non-compliant configurations are rejected at plan time, before any resource is created."

Strength: This is a preventive control. Auditors typically weight preventive controls above detective ones — the misconfiguration never exists, so there is nothing to detect and remediate.

Limitation: Prevents only what the module covers. Resources deployed outside compliance.tf modules are not subject to these controls. See Why the evidence is trustworthy for ways to validate enforcement independently.

Layer 2: Pre-Apply Verification (IaC Scanning)

Static analysis of Terraform plans before terraform apply. Tools scan the plan JSON and report compliance status.

Tools: Checkov, Trivy

Evidence artifacts:

• CI pipeline scan reports (JSON/SARIF output, dated, with pass/fail per check)
• Git commit SHA linking the scan to a specific code version
• Pipeline run logs showing scan execution

Auditor narrative: "Every infrastructure change goes through an automated compliance scan in our CI pipeline before deployment. Failed scans block the deployment."

Strength: Provides a documented gate in the deployment process.

Layer 3: Post-Apply Verification (Infrastructure Scanning)

Scans of actual deployed AWS resources to verify compliance state.

Tools: AWS Config, AWS Audit Manager, Powerpipe (with Steampipe), AWS Security Hub, Prowler

Evidence artifacts:

• AWS Config compliance summaries
• AWS Audit Manager assessment reports
• Powerpipe benchmark JSON reports
• Scheduled scan outputs with timestamps

Auditor narrative: "We run continuous infrastructure compliance scans. Here are the results showing all resources in our environment meet the required controls."

Strength: AWS-native evidence (AWS Config, Audit Manager) is the highest-trust evidence source — when AWS reports a resource as compliant, the finding comes from a first-party AWS service.

Type II audits: scheduled Layer 3 scans combined with pinned, immutable module versions are what prove controls operated continuously across an observation period — see Type II Observation Period.

Evidence Artifacts by Framework

Each compliance framework has different auditor expectations, trust thresholds, and evidence requirements. The sections below map compliance.tf controls to framework criteria and explain what your auditor expects to see.

SOC 2 — What Your Auditor Expects

SOC 2 evaluates Trust Services Criteria (TSC). Infrastructure evidence maps primarily to the Common Criteria (CC series) and the Availability criterion (A series).

Control Mapping

For the full control list, see the SOC 2 framework page.

Evidence Package for SOC 2

Type II Observation Period

SOC 2 Type II covers an observation window your auditor agrees with you — commonly 3 to 12 months; no fixed minimum is prescribed. Like any observation-period audit, it needs proof that controls operated continuously — not just at a single point in time. Four mechanisms produce that proof:

1. Module version immutability. Once a compliance.tf module version is published, it cannot be changed. The enforcement configuration is fixed at the version level.

2. Explicit version pinning. An explicit version pin — the version argument in Registry format, or the ?version= query parameter in HTTPS format — plus the module source and version recorded in your version-controlled configuration (and in .terraform/modules/modules.json at init time) prove which version was in use at any given time. The .terraform.lock.hcl file locks provider versions (not module versions). Version history is tracked in your version control system.

3. Archived Terraform plan JSON. Each deployment's saved plan shows the enforced control values; pair it with the version-controlled configuration and .terraform/modules/modules.json, which record the exact module sources. Treat saved plans as sensitive: they contain resource values in plaintext (HashiCorp's own guidance). Archive them to encrypted, access-controlled storage, and prefer extracting the metadata your auditor needs over uploading raw plans to third-party platforms.

4. Scheduled scan consistency. Run post-apply scans (Layer 3) on a cadence agreed with your auditor — weekly is a common starting point — and store the results with timestamps in S3 or your artifact storage. A time series of scan reports showing all controls passing demonstrates continuous operation far more effectively than a single point-in-time snapshot.

The combination of "the module has not changed" (version pinning) and "scans are consistently clean" (scheduled results) addresses the continuous operation requirement.

Exception Documentation

When a control is disabled using the ?disable= parameter, the disabled control name appears in the module source URL:

module "s3_bucket" {
  source = "https://soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws?version=5.0.0&disable=s3_bucket_object_lock_enabled"
}

This URL is visible in:

• Terraform source code — tracked in version control with full commit history
• Module install metadata — .terraform/modules/modules.json records the full source URL, query parameters included

For SOC 2 auditors, document each exception with: (a) which control is disabled, (b) business justification, (c) compensating controls if any, and (d) approval record. The disable= parameter creates the auditable trail; your organization provides the justification documentation.

PCI DSS v4.0 — What Your QSA Expects

PCI DSS is mandatory for any entity that stores, processes, or transmits cardholder data. Compliance is validated by a Qualified Security Assessor (QSA) for Level 1 merchants and service providers.

Control Mapping

For the full control list, see the PCI DSS v4.0 framework page.

QSA-Specific Guidance

QSAs are typically stricter than SOC 2 auditors about evidence provenance. Key differences:

• Primary evidence must come from AWS-native sources. AWS Config compliance reports, Audit Manager assessments, and Security Hub findings carry the highest trust. QSAs generally accept these without additional validation.
• Open-source tool output is supporting evidence only. Checkov and Powerpipe reports are useful for internal engineering workflows but are unlikely to serve as primary evidence for a QSA assessment.
• Testing procedures are defined per requirement. Each PCI DSS requirement has specific testing procedures the QSA must follow. Your evidence package should map directly to these procedures.

CDE Scoping

Compliance.tf enforces controls on all resources deployed through its modules. Ensuring that every Cardholder Data Environment (CDE) resource is deployed that way is the customer's responsibility: resources created outside compliance.tf modules — via the AWS console, upstream terraform-aws-modules, or raw Terraform resources — are not subject to its preventive controls.

HIPAA — What Your Auditor Expects

HIPAA applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates handling Protected Health Information (PHI).

Control Mapping

For the full control list, see the HIPAA framework page.

BAA Considerations

Compliance.tf covers technical safeguards only. The HIPAA Security Rule also requires administrative safeguards (policies, risk assessments, workforce training) and physical safeguards (facility access, workstation security) — those are your organization's responsibility.

AWS has a Business Associate Agreement (BAA) covering eligible AWS services. This BAA is between your organization and AWS. Compliance.tf is an infrastructure tooling provider — it does not process, store, or transmit PHI directly, and it does not hold a BAA. Your BAA obligations are with AWS and any other entities that handle PHI on your behalf.

PHI-Specific Controls

For infrastructure handling PHI, prioritize these compliance.tf control categories:

• Encryption at rest — All storage services (S3, RDS, EBS, DynamoDB) must encrypt PHI. Compliance.tf enforces encryption by default.
• Access logging — Every access to PHI must be logged. Compliance.tf enforces logging on S3, CloudTrail, and other services.
• Data lifecycle — Versioning and retention policies protect against unauthorized modification or deletion of PHI.
• Network isolation — Public access blocking and endpoint restrictions prevent unauthorized exposure of PHI.

How to Generate Each Artifact

Powerpipe Benchmark Scans

Run Powerpipe benchmarks from the AWS Compliance mod against your deployed AWS infrastructure to generate post-apply verification evidence. (This is the mod that scans live AWS resources via Steampipe — not the Terraform-file scanning mod.)

One-time setup:

# Install the AWS plugin and compliance mod, prepare the output directory
steampipe plugin install aws
powerpipe mod init
powerpipe mod install github.com/turbot/steampipe-mod-aws-compliance
mkdir -p evidence
steampipe service start

Then run the benchmark for your framework:

powerpipe benchmark run aws_compliance.benchmark.soc_2 \
  --output json > evidence/powerpipe-soc2-$(date +%Y-%m-%d).json

powerpipe benchmark run aws_compliance.benchmark.pci_dss_v40 \
  --output json > evidence/powerpipe-pcidss-$(date +%Y-%m-%d).json

powerpipe benchmark run aws_compliance.benchmark.hipaa_final_omnibus_security_rule_2013 \
  --output json > evidence/powerpipe-hipaa-$(date +%Y-%m-%d).json

Schedule: Weekly is a common starting cadence for Type II evidence; agree the frequency with your auditor. Store results in S3 with versioning enabled for a durable history of scan results (add S3 Object Lock if your auditor expects immutability — versioned objects can still be permanently deleted).

Checkov CI Reports

Run Checkov against your Terraform plan to generate pre-apply verification evidence.

# Generate Terraform plan JSON
mkdir -p evidence
terraform plan -out=plan.out
terraform show -json plan.out > plan.json

# Run Checkov with SARIF output (for GitHub Security tab integration)
checkov -f plan.json -o sarif --output-file evidence/checkov-$(date +%Y-%m-%d).sarif

# Run Checkov with JSON output (for archival)
checkov -f plan.json -o json > evidence/checkov-$(date +%Y-%m-%d).json

Save scan results as CI artifacts. The SARIF format integrates with GitHub's Security tab for centralized finding management.

AWS Config Integration

Config rules continuously evaluate your AWS resources and produce first-party AWS findings — the highest-trust evidence source in your audit package.

Setup:

1. Enable AWS Config in every region where you deploy resources.
2. Deploy Config Conformance Packs aligned to your compliance framework. AWS provides managed conformance packs for SOC 2, PCI DSS, and HIPAA.
3. Export compliance data for your evidence package:

# Get compliance summary across all Config rules
aws configservice get-compliance-summary-by-config-rule

# Get detailed compliance for a specific rule
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-server-side-encryption-enabled

# Export compliance snapshot to S3
aws configservice deliver-config-snapshot \
  --delivery-channel-name default

GitHub Actions Workflow for Automated Evidence Generation

This workflow runs Checkov on every pull request and Powerpipe on a weekly schedule. Evidence is stored as GitHub Actions artifacts and optionally uploaded to S3.

name: Compliance Evidence

on:
  pull_request:
    paths: ['**/*.tf']
  schedule:
    - cron: '0 6 * * 1'  # Weekly on Monday at 06:00 UTC

permissions:
  contents: read
  id-token: write  # required for the OIDC role assumption in post-apply-scan
  security-events: write  # required for the SARIF upload

env:
  EVIDENCE_BUCKET: my-compliance-evidence  # Replace with your S3 bucket

jobs:
  pre-apply-scan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure Terraform Token
        run: |
          mkdir -p ~/.terraform.d
          echo '{"credentials":{"soc2.compliance.tf":{"token":"'"$CTF_TOKEN"'"}}}' > ~/.terraform.d/credentials.tfrc.json
        env:
          CTF_TOKEN: ${{ secrets.CTF_TOKEN }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init and Plan
        run: |
          terraform init
          terraform plan -out=plan.out
          terraform show -json plan.out > plan.json

      - name: Checkov Scan
        uses: bridgecrewio/checkov-action@v12
        with:
          file: plan.json
          output_format: sarif
          output_file_path: checkov-results.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov-results.sarif

      - name: Archive Evidence
        uses: actions/upload-artifact@v4
        with:
          name: pre-apply-evidence-${{ github.sha }}
          path: checkov-results.sarif

  post-apply-scan:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - name: Install Powerpipe and Steampipe
        # Production hardening: pin release versions and verify checksums
        # instead of piping the latest installer to a root shell, and scope
        # AWS_EVIDENCE_ROLE_ARN to read-only permissions.
        run: |
          sudo /bin/sh -c \
            "$(curl -fsSL https://powerpipe.io/install/powerpipe.sh)"
          sudo /bin/sh -c \
            "$(curl -fsSL https://steampipe.io/install/steampipe.sh)"
          steampipe plugin install aws

      - name: Install AWS Compliance Mod
        run: |
          powerpipe mod init
          powerpipe mod install github.com/turbot/steampipe-mod-aws-compliance

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_EVIDENCE_ROLE_ARN }}
          aws-region: us-east-1

      - name: Run Powerpipe Benchmark
        run: |
          steampipe service start
          powerpipe benchmark run \
            aws_compliance.benchmark.soc_2 \
            --output json > soc2-evidence.json

      - name: Upload to S3
        run: |
          DATE=$(date +%Y-%m-%d)
          aws s3 cp soc2-evidence.json \
            s3://$EVIDENCE_BUCKET/powerpipe/$DATE/soc2.json

      - name: Archive Evidence
        uses: actions/upload-artifact@v4
        with:
          name: post-apply-evidence-${{ github.run_id }}
          path: soc2-evidence.json

Adjust the framework benchmark name (soc_2, pci_dss_v40, hipaa_final_omnibus_security_rule_2013) to match your compliance requirements. For multi-framework environments, add parallel jobs for each framework.

Using compliance.tf Evidence with GRC Platforms

If your organization uses a GRC platform like Vanta, Drata, or Sprinto, you do not need a dedicated compliance.tf integration. The evidence that compliance.tf generates flows through standard channels that these platforms already support.

AWS Config Findings (Native Integration)

Most GRC platforms integrate directly with AWS Config and Security Hub. Once you connect your AWS account, the platform pulls compliance findings automatically. Because compliance.tf modules enforce controls at the infrastructure level, your AWS Config findings are clean — the GRC platform simply reflects that state.

No additional configuration is required on the compliance.tf side. The integration is between your AWS account and your GRC platform.

Powerpipe JSON Reports (Custom Evidence)

Powerpipe benchmark reports can be uploaded as custom evidence in any GRC platform that supports file-based evidence collection.

# Generate a dated report for upload
powerpipe benchmark run aws_compliance.benchmark.soc_2 \
  --output json > evidence/powerpipe-soc2-$(date +%Y-%m-%d).json

In your GRC platform, map these reports to the relevant controls:

Schedule uploads to match your scan cadence (weekly for Type II evidence). Some platforms support S3 bucket integration for automatic ingestion — point them at the same bucket your GitHub Actions workflow uploads to.

Terraform Plan Artifacts (Custom Evidence)

Terraform plan JSON showing enforced values, paired with the configuration files that record the module sources, can be uploaded as supporting evidence for preventive control attestations. These demonstrate that non-compliant configurations were rejected before deployment.

Upload the plan JSON alongside the corresponding CI scan report to show both the enforcement (Layer 1) and the verification (Layer 2) for the same deployment.

SOC 2 Preparation Timeline

A common target is SOC 2 Type II readiness within six months. Compliance.tf compresses the technical controls work into the first two months so your team can focus on organizational controls, policy writing, and auditor coordination for the remaining four.

The timeline below assumes you are starting from scratch with compliance.tf. If you already have modules deployed, skip to the month that matches your current state.

What to Tell Your Auditor About Compliance.tf

This section is written in plain language so you can share it directly with your auditor or link to it in your audit preparation materials.

What compliance.tf is

Compliance.tf provides Terraform modules with built-in compliance controls for AWS infrastructure. When your engineering team uses these modules, compliance configurations are enforced automatically — encryption, logging, access controls, and other security settings cannot be overridden or omitted by module consumers. Controls are validated at terraform plan time, before any resource is created or modified in AWS.

Compliance.tf builds on terraform-aws-modules, the most widely used open-source Terraform modules for AWS, with billions of provisions worldwide. The same module interfaces, the same arguments, the same outputs — with compliance controls enforced at the module level.

What compliance.tf does not replace

Compliance.tf covers infrastructure-level technical controls. Every compliance framework also requires organizational, procedural, and human controls alongside those — see What Compliance.tf Evidence Does NOT Cover for the full scope boundary.

Why the evidence is trustworthy

• Controls are embedded in module source code. They are verifiable by reading the Terraform source. There is no separate policy engine that could be misconfigured or bypassed.
• Module versions are immutable. Once published, a module version cannot be changed. The control configuration at version 5.0.0 is the same today as when it was published. See Type II Observation Period for how version pins turn that into observation-period evidence.
• Controls cannot be bypassed by module consumers. Values are hardcoded in the module source. Setting versioning = false in your Terraform configuration does not override the module's enforcement.
• Disabled controls are explicit and auditable. The ?disable=control_name parameter appears in the module source URL, which is tracked in version control and recorded in .terraform/modules/modules.json.
• Evidence comes from independent tools, not from compliance.tf itself. AWS Config, Audit Manager, Checkov, and Powerpipe independently verify that controls are in effect. Compliance.tf does not self-attest.

How exceptions work

Disabling a control puts its name in the module source URL (?disable=s3_bucket_object_lock_enabled), which is visible in Terraform source code (tracked in Git) and in .terraform/modules/modules.json. The exception is explicit, auditable, and traceable to a specific code change and author. Your organization is responsible for documenting the business justification for each exception and any compensating controls — see Exception Documentation.

What Compliance.tf Evidence Does NOT Cover

Compliance.tf is an infrastructure enforcement layer. It covers a specific and bounded scope. The following areas require separate controls, tools, and processes:

Organizational controls. Policies, procedures, employee training, and governance structures — information security policy, acceptable use, data classification. No infrastructure tool can enforce these.

HR controls. Background checks, security awareness training, onboarding and offboarding procedures.

Physical security. Data center access, workstation security, badge systems. AWS handles physical data center security under its shared responsibility model; your office and endpoint security is separate.

Incident response. Detection, triage, communication, and recovery procedures — runbooks, communication plans, breach notification. Compliance.tf prevents misconfigurations but does not monitor for active threats or intrusions.

Vendor management. Third-party risk assessments, vendor security questionnaires, due diligence, contract reviews.

Change management. Approval workflows, change advisory board processes.

Access management. SSO/MFA implementation, privilege access management, quarterly access reviews. Compliance.tf enforces resource-level configurations, not identity-level controls.

Resources not using compliance.tf modules. Any AWS resource deployed outside compliance.tf modules — via the AWS console, upstream terraform-aws-modules, raw Terraform resources, or CloudFormation — is not covered by compliance.tf's preventive controls. Your organization must ensure that in-scope resources are deployed through compliance.tf modules.

Detective controls for non-infrastructure issues. Compliance.tf does not monitor for suspicious user activity, unauthorized access attempts, data exfiltration, or operational anomalies. Those require SIEM, IDS/IPS, and runtime monitoring tools.

For framework-specific scope boundaries, see the "What Compliance.tf Covers vs. What You Handle" section on each framework page: SOC 2, PCI DSS v4.0, HIPAA.