What is Terraform audit evidence?
Terraform audit evidence means the records that demonstrate Terraform-defined infrastructure satisfied a control requirement, including pinned module sources, plan output, scan reports, pipeline logs and configuration history after deployment.
Three layers of evidence
| Layer | What it shows | Examples |
|---|---|---|
| Prevention | The control sat in the code path | Module source and version in Git, plan output, .terraform/modules/modules.json |
| Pre-apply | The change was verified before release | Checkov or Trivy JSON or SARIF output, commit SHA, pipeline logs |
| Post-apply | The deployed resource matches | AWS Config, AWS Audit Manager, Security Hub, Powerpipe, Prowler |
Post-apply evidence reports what landed in the account, while prevention records the intent and enforcement carried in code.
Evidence over time
A point-in-time audit checks whether a control was in place. A period audit, such as SOC 2 Type II, checks whether it remained in place across the interval. Four records back that up:
- Immutable module versions. With a framework endpoint, one version number always points to identical code; with an organization endpoint, save the config snapshot used for the download too, since that snapshot is not part of the version number.
- Explicit version pins in Git, together with
.terraform/modules/modules.jsonfor every run. - Archived plan JSON for each change. Handle it as sensitive material, since plans may include secrets.
- Repeated scans of the deployed account on a schedule.
Exceptions
If a module has a control switched off, its record should be no harder to locate than the control itself. In compliance.tf, a control override sits inside the module source URL, so Git history and modules.json both show it. The organization still writes down the reason, any compensating control and the approval.
Limits
- compliance.tf does not self-attest. Your code, your plans and your AWS account are the evidence.
- Settle with your auditor or assessor which records they will accept for each requirement. Scanner reports and AWS-native records such as AWS Config history can each play a part; acceptance depends on the requirement and on the way those records are maintained.
- Console and CLI changes bypass module controls. Importing an existing resource does not show it was compliant before that import, and moving a resource out of a compliance.tf module ends the module's enforcement for that resource.
- A version pin does not establish that every deployment stayed inside compliance.tf modules.
- Operational Rules are standards for operations. Do not describe them to an auditor as regulatory controls.