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). This guide explains each layer, shows how to generate evidence artifacts, and provides framework-specific guidance for SOC 2, PCI DSS, and HIPAA audits.

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.

flowchart TD
    L1["<b>Layer 1: Prevention</b><br/>Module-level enforcement<br/>Controls enforced at terraform plan"]
    L2["<b>Layer 2: Pre-Apply Verification</b><br/>IaC scanning (Checkov, Trivy)<br/>CI pipeline gate before deployment"]
    L3["<b>Layer 3: Post-Apply Verification</b><br/>Infrastructure scanning<br/>(AWS Config, Powerpipe, Audit Manager)"]

    L1 -->|"Plan passes"| L2
    L2 -->|"Scan passes"| L3

    L1 --- A1["<b>Artifacts:</b> Module source, plan output, registry URL<br/><b>Control type:</b> Preventive"]
    L2 --- A2["<b>Artifacts:</b> CI scan reports (SARIF/JSON), commit SHA<br/><b>Trust tier:</b> Supporting evidence"]
    L3 --- A3["<b>Artifacts:</b> AWS Config findings, Powerpipe reports<br/><b>Trust tier:</b> Primary evidence (AWS-native)"]

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 — the strongest form of control in any audit framework. Prevention is always more trusted than detection.

Limitation: Prevents only what the module covers. Resources deployed outside compliance.tf modules are not subject to these controls. See Verifying compliance.tf Modules for a detailed walkthrough of how 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, a SOC 2-certified company worth trillions is attesting to that finding.

Proving Continuous Operation for Type II Audits

SOC 2 Type II and other observation-period audits require evidence that controls operated continuously — not just at a single point in time. Compliance.tf supports this through three mechanisms:

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. Version pinning. Explicit version arguments in module blocks and the module source recorded in Terraform state 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. Scheduled scan consistency. Weekly or daily post-apply scans (Layer 3) produce a time series of compliance results. Consistent clean results over the observation period demonstrate that controls operated effectively throughout.

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

SOC 2 Preparation Timeline

Most organizations target 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.

Evidence Artifacts by Framework

Each compliance framework has different auditor expectations, trust thresholds, and evidence requirements. The sections below map compliance.tf controls to specific 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 requires evidence over a minimum 3-month observation window (6-12 months is typical). To demonstrate continuous operation:

1. Run scheduled scans weekly at minimum. Store results with timestamps in S3 or your artifact storage.
2. Archive Terraform plan outputs. Each deployment's plan output shows the compliance.tf module version and enforced control values.
3. Maintain explicit version constraints in module blocks. The version argument in each module block and the module source in Terraform state prove the enforcement mechanism has not changed. (The .terraform.lock.hcl file locks provider versions, not module versions.)
4. Show consistent results over time. A time series of weekly scan reports showing all controls passing demonstrates continuous operation more effectively than a single point-in-time snapshot.

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
• Terraform state — recorded in the state file with the module source
• Terraform plan output — shown during terraform plan

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. However, the customer is responsible for ensuring that all Cardholder Data Environment (CDE) resources are deployed using compliance.tf modules. Resources deployed outside compliance.tf modules — via the AWS console, upstream terraform-aws-modules, or raw Terraform resources — are not subject to compliance.tf's 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 against your deployed infrastructure to generate post-apply verification evidence.

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

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

powerpipe benchmark run terraform_aws_compliance.benchmark.hipaa \
  --tag hipaa=true \
  --output json > evidence/powerpipe-hipaa-$(date +%Y-%m-%d).json

Schedule: Run weekly at minimum for Type II evidence. Store results in S3 with versioning enabled so you have an immutable archive of scan results over time.

Checkov CI Reports

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

# Generate Terraform plan JSON
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

AWS Config provides the highest-trust evidence for auditors. Config rules continuously evaluate your AWS resources and produce findings that carry AWS's own SOC 2 attestation.

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

AWS Config is the evidence source that matters most in your audit package. Compliance.tf modules are designed to keep that evidence clean for the resources they cover.

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

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
        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: 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: |
          powerpipe benchmark run \
            terraform_aws_compliance.benchmark.soc_2 \
            --tag soc_2=true \
            --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) 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 terraform_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 outputs showing compliance.tf module sources and enforced values 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.

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 over two billion 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. It does not replace:

• Organizational policies — Information security policies, acceptable use policies, data classification
• HR processes — Background checks, security awareness training, onboarding and offboarding
• Incident response — Runbooks, communication plans, breach notification procedures
• Physical security — Data center access controls, workstation security
• Vendor management — Third-party risk assessments, vendor due diligence
• Access management — IAM policy design, SSO/MFA configuration, role-based access reviews
• Change management — Approval workflows, change advisory board processes

Every compliance framework requires organizational, procedural, and human controls alongside technical controls. Compliance.tf handles the technical infrastructure layer.

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.
• 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, Terraform state, and plan output.
• 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

When a control is disabled, the disabled control name appears in the module source URL:

source = "https://soc2.compliance.tf/.../s3-bucket/aws?disable=s3_bucket_object_lock_enabled"

This is visible in Terraform source code (tracked in Git), Terraform state, and terraform plan output. 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.

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. 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. Compliance.tf prevents misconfigurations but does not monitor for active threats or intrusions.

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

Access management. IAM policies, 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.