Yes, a saved Terraform plan is strong evidence of what a change would do, and applying that same file proves the approved change is what ran. Treat the plan file as sensitive, store it with the pull request, and link it to the approval and the apply log.
What a saved plan gives you
When you run the plan command with the out option, Terraform writes the generated plan to a file. HashiCorp's documentation says you can pass that file to the apply command to execute exactly those planned changes, and describes this two-step flow as intended for automation. For an auditor, that sequence answers the awkward question of whether what was reviewed is what was deployed.
Without a saved plan, a reviewer approves a plan shown in a pull request, and a later apply recalculates against whatever the state is by then. The two can differ.
The evidence chain
| Step | Record | Where it lives |
|---|---|---|
| Change requested | Ticket or PR description | Issue tracker or source control |
| Plan generated | Plan output text and saved plan file | CI artifact store |
| Change approved | Approving review on the PR | Source control |
| Plan applied | Apply log naming the same plan file | CI logs |
| Result | State version and timestamp | State backend |
Steps to set it up
- In CI, run the plan on every pull request and save the file as a build artifact.
- Post the human-readable summary as a PR comment so the reviewer sees it.
- Use the detailed exit code option so the pipeline can tell empty plans from non-empty ones. Per the documentation, exit code 0 means no changes, 1 means error and 2 means changes are present.
- On merge, apply the saved file rather than re-planning. If the plan is stale, the apply should fail and require a new plan and review.
- Keep the plan summary, apply log and approval together, indexed by commit hash.
Handle the file as sensitive
HashiCorp warns that saved plan files contain your full configuration and planned values, and that sensitive values are stored in cleartext. So:
- Restrict who can download CI artifacts.
- Set a short artifact retention for the raw file, and keep a redacted text summary for evidence.
- Never attach the raw file to a public ticket.
Remember to check retention limits in your CI system. If artifacts expire after a short window, your audit period may outlast them. Export the summary and apply log to your evidence store.
What to tell the auditor
Describe the flow in your control narrative: plan on PR, review, apply the same plan on merge, log retained. Then show one sample end to end. Be ready to explain what happens for emergency changes made directly in the console, because drift is where auditors look next.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how ongoing checks surface differences after a change, the same idea as watching for drift after apply.
Quick check
Is the plan text enough, or do I need the file?
The text is useful for review. The file is what proves the applied change matched. Keep a redacted summary and, if policy allows, the file for a limited time.
What if someone changes infrastructure in the console?
Detect it with drift checks, record it as an exception, and bring the code back in line.
Safeguard offers policies, gates and guardrails for pull requests, plus compliance and evidence automation to keep the records. Run a free scan.
Sources
Last reviewed: 19 October 2026.
