This infrastructure as code checklist has nine checks, each with a test and the evidence to show. Mark each check 2, 1 or 0 and add up the total. Then read it with the rebuild check to see whether the files can recreate your setup.
Last reviewed 2026-11-05 by Manish Sharma.
The list tests one practice: holding your setup as text that software applies, with no console clicks. The wider DevOps practice explains where it fits. It suits IT managers, infrastructure leads and CTOs in India or the GCC. Part of their estate already comes from files, perhaps by provisioning environments from code. This is a review of a setup that exists. It leaves out build order, cost, tool choice and security controls. For the tool choice, read a short trial plan for comparing two shortlisted tools.
How to Mark Each Check in This Infrastructure as Code Checklist
Give each check one of three marks, for a maximum of 18 across nine checks.
The marks, the maximum and the bands are Signisys suggestions. They are not a benchmark or a study result, so adjust them to your estate.
The three marks read as follows.
- Shown (2): the test holds for the whole scope, and you can show dated evidence now.
- Partly (1): the test holds for some of the scope, or the evidence is thin.
- Not yet (0): the test fails, or no one has looked.
Decide the scope before you mark anything, such as one environment or the whole estate. Anything outside the scope gets Not yet. The other route drops its 2 points from the 18 and states that next to the result.
Open the records and look at them, because memory is not evidence. Where a check asks for a sample, the size is our suggestion. Also change it to fit how much change your team makes. Show it; otherwise it does not count towards a 2.
To use this iac checklist, copy the three tables below into a spreadsheet. Add three columns for the owner, the date and your mark. Treat the result as a self-review, which is no audit and no certificate.
The Infrastructure as Code Checklist: Nine Checks, Tests and Evidence
First, the checks form three groups of three. Each table pairs a test with the proof you hold for it.
What the Files Hold, and Who Reads a Change Before It Applies
Checks 1 to 3 ask whether the files describe the setup. They also ask whether a person and a test stand in front of every change.
| No. | Check | Test | Evidence to show |
|---|---|---|---|
| 1 | Everything in scope is in files. | Yes if each of five live resources, picked at random, appears in the files. Five is our suggestion, so adjust it. | The five names, each with its file location. |
| 2 | A second person reviews every change. | Yes if each of the last 10 changes, our suggestion, has an approver who did not write it and a linked ticket with a way back. | The ten change records, with the approver’s name on each. |
| 3 | A change is tested before it applies. | Yes if automatic checks and a preview of what will change run first, and a failed check stops the apply. | One deliberately broken change that the checks stopped, and the preview from the latest change. |
In our view, a scanner does not settle every question, and a person confirms the design. We suggest running the tests in a separate, throwaway area that the team removes afterwards.
Where State, Secrets and Environments Live
Checks 4 to 6 cover the record of what exists, the secrets and the separation between environments.
| No. | Check | Test | Evidence to show |
|---|---|---|---|
| 4 | The record of what exists is shared and guarded. | Yes if one shared store holds it, one writer works at a time, named people may read or write it, and a dated copy exists. | The store location, the access list and the date of the latest copy. |
| 5 | No secret sits in the files. | Yes if a scan of the files and their history finds none, and a separate store holds the secrets with a named holder. | The scan output and the holder’s name. |
| 6 | Each environment has its own settings, record and access. | Yes if one set of files serves every environment, each has its own settings file, record and access list, and shared parts stay pinned to a version. | The settings file name for each environment, and one test change that did not reach production. |
The record in check 4 can hold sensitive values, so keep its access list short. Also, check 5 asks only whether a secret sits in the files. Encryption and access policy belong to a security review. Matching the environments to each other belongs to a separate use case.
Whether the Live Setup Matches, Rebuilds and Leaves a Trail
Checks 7 to 9 test the live setup against the files and prove them by use.
| No. | Check | Test | Evidence to show |
|---|---|---|---|
| 7 | The live setup is compared with the files on a schedule. | Yes if a scheduled comparison runs, and the team writes each difference into the files or removes it from the live setup. | The last comparison, and the decision on each difference. |
| 8 | A rebuild from the files alone has been tried. | Yes if someone created a clean copy of one environment from the files, with no manual step, inside your window, and wrote down the time. Our suggested window is the last six months. | The date, the person, the time taken and the list of manual steps. The pass is an empty list. |
| 9 | Every change leaves a trail, and the files have an owner. | Yes if you trace one live resource to its change, approver and reason in under 10 minutes, our suggestion, and one named person owns the files. | The traced example and the owner’s name. |
Check 7 catches drift, a live setup that has moved away from its files. Check 8 is the deciding check. When a component fails the rebuild, replace it from the files and do not patch it in place. For check 9, label each resource when you create it and remove it from the record when you retire it. The owner decides who may change the files.
Key Takeaway Check 8 decides the result, because only a rebuild from the files alone proves they are complete.
How to Collect the Evidence Without Touching Live Systems
Collect the evidence with read-only access, in one afternoon, and have someone who did not write the files do it. The file owner answers questions, but does not choose the marks. A slip in the review then leaves the live systems alone.
In practice, take a sample, not a full audit. Store each piece of evidence in the shared sheet with its date, so the next review starts from a record.
When two people disagree on a mark, use the lower one and note why.
The same nine checks work as an infrastructure as code implementation checklist during a rollout, to see how far each part has got.
Several checks line up with open community guidance on securing infrastructure code. It asks teams to track every change with enough detail to revert it, and to limit who may create, update or delete the scripts. It also asks them to label and log each resource when they deploy it. Checks 2 and 9 cover the first and the last, and the file owner in check 9 covers the second.
What Your Infrastructure as Code Checklist Total Says About a Rebuild
Add the nine marks and read the band. However, the bands are Signisys wording, so adjust the ranges to your own tolerance for risk.
| Total | Band | First action |
|---|---|---|
| 16 to 18 | Rebuild-ready | Keep the evidence and recheck on your own schedule. |
| 12 to 15 | Close to rebuild-ready | Close the named gaps, then mark again. |
| 7 to 11 | Rebuild uncertain | Close the gaps in the order below before any large change. |
| 0 to 6 | No safe rebuild yet | Write down what exists and who owns it. |
A mark below 2 on check 8 caps the result at Close to rebuild-ready. Only a tried rebuild shows the files are complete. A 0 on check 4 caps it at Rebuild uncertain, because without a guarded record no change is safe to apply.
Here is an invented illustration, not data. A setup marks 2 on seven checks and 1 on two, so 7 x 2 + 2 x 1 gives 16. Check 8 is one of the 1s, because the rebuild needed one manual step. The total says Rebuild-ready, but the rule caps it at Close to rebuild-ready. The first task is to remove that manual step.
The total shows infrastructure as code readiness. It matches the open principles for managing a wanted setup. They store that setup with its full history and keep comparing the live system with it.
Closing Gaps in the Order That Protects a Rebuild
Fix gaps in this order: 4, 5, 1, 2, 3, 6, 7 and 9, then retry 8. Each position protects the one after it, so a low total gives you a plan as well as a score.
- Checks 4 and 5 first. Without a guarded record no change is safe to apply, and a secret in the files reaches everyone who reads them.
- Checks 1, 2, 3 and 6 next. Files that miss resources, unreviewed changes and untested changes all weaken a rebuild, and shared environment settings let a test change reach production.
- Checks 7 and 9 after that, then retry check 8. A schedule and a trail keep the files honest, and the retry shows whether they now hold.
Then work through the gaps one at a time and mark again after each fix. In our view, a scanner may report a clean result while the design is wrong. We suggest keeping a person in the loop on checks 1 to 3.
Use the infrastructure as code checklist score to set the order of work, and leave deadlines to your own planning. For how to build a missing part, read the build order for each missing part. The release path of application code has its own list, with checks for the release path.
Limits of a Self-Marked Score, and When a Specialist Helps
The score is a self-review, and it says nothing about whether the design is right. A person has to confirm the design, and neither a scanner nor a sheet judges it.
The person who wrote the files can mark them for a first pass. However, a second reader can catch more. A specialist helps when no one has tried a rebuild, when the state record sits on one person’s machine, or when an auditor or customer asks for proof.
This list does not test the security controls on your setup. For those, read about testing the security controls themselves. For the cost of working without files, see what building by hand costs the business.
Key Takeaway The score is a self-review: use it to set the order of work, and have a person confirm the design.
Signisys provides this work, and you can score your setup without it. To mark the nine checks with a specialist, read about the Signisys infrastructure as code solution and the DevOps automation service behind it.
Infrastructure as Code Checklist FAQ: Questions on Marking
Does every check in the infrastructure as code checklist apply if only part of the estate is in files?
Can the person who wrote the files mark them?
Why does the rebuild check outweigh the other infrastructure as code checklist items?
What should you do about a manual change nobody can explain?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.