An infrastructure as code change is done when it has been peer reviewed, scanned for misconfiguration and secrets, shown in a plan that a human read, applied to a lower environment first, and has a known rollback. Add these lines to your team's definition of done so infrastructure follows the same rules as application code.
Why infrastructure needs its own lines
Infrastructure code changes who can reach what. A one-line change can open a network port or widen a permission. The Scrum Guide says an item that does not meet the definition of done cannot be released. If your definition of done was written for application code, infrastructure changes can pass without the checks that matter to them.
NIST's Secure Software Development Framework covers this too. Practice PW.9.1 asks organizations to define a secure baseline for software settings, and PW.9.2 asks them to implement the default settings. Infrastructure code is where many of those settings live.
A definition of done for IaC
| Line | What it means |
|---|---|
| Peer review | A second person read the diff, not only the plan output |
| Misconfiguration scan | An IaC scanner ran with no unresolved blocking findings |
| Secret check | No credentials or keys in code, variables or state output |
| Plan read | A human read the plan and confirmed what will change and what will be destroyed |
| Least privilege | New roles and policies grant only what is needed, with no wildcard unless justified |
| Lower environment first | Applied to a test or staging environment before production |
| Rollback known | The team knows how to revert, and what cannot be reverted |
| Image checks | New container images were scanned and come from an approved source |
Notes on key lines
Plan read
Many incidents begin with an unread plan. Make the plan a required artifact in the pull request. A reviewer should be able to see resources to be created, changed and destroyed.
Least privilege
Wildcard permissions are the most common shortcut. Ask for a reason in the pull request whenever one appears, and record the answer.
State and secrets
State files can contain secret values. Treat them as sensitive, store them in access-controlled backends and exclude them from logs and artifacts.
Rollback
Not every change reverses cleanly. A deleted database cannot be restored by reapplying code. Note which changes are one-way, and require extra review for them.
How to adopt it
- Draft the list with the people who run the infrastructure.
- Decide which lines are automated and which are human.
- Add automated lines to the pipeline so failed checks block the merge.
- Add the human lines to the pull request template.
- Review the list after any infrastructure incident, and add or sharpen a line.
Keep it proportionate
Do not add 20 lines. Aim for eight or fewer. If a line is ticked every time without discussion, it should be automated or removed.
Where application and infrastructure meet
A container image links the two. The image's base, packages and configuration are part of both. Include an image scan in the definition of done for any change that builds or updates an image, and keep the software bill of materials with the build.
Safeguard offers container image scanning, SBOM generation and policy gates, which can run on infrastructure and container changes. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an image scan lists packages and findings, which is the evidence for the image check line.
Quick check
Should IaC have a separate definition of done?
It can share one list with application code, but add infrastructure lines such as plan review, least privilege and rollback so they are not missed.
Is a scan enough for infrastructure changes?
No. Scans find known misconfigurations, but a human must read the plan and confirm that the change does what was intended.
Sources
Last reviewed: 19 October 2026.
