An infrastructure as code pull request checklist for reviewers

Review an infrastructure change by asking six questions: who can do what, what can reach what, where does data live, where do secrets come from, what new dependencies arrive, and what will the plan destroy or replace. This checklist turns those into concrete checks you can apply in about ten minutes.

The six checks

1. Identity

• Any new or changed IAM policy: is it scoped to named actions and resources, or does it use wildcards?
• Can the role create or modify other roles or policies?
• Do trust policies name specific principals and, for CI, specific repositories and environments?
• Are long-lived access keys being created? Prefer roles with temporary credentials.

2. Network

• Any ingress from an open CIDR: which port, and is it a public web endpoint by design?
• Do databases accept traffic from application security groups rather than address ranges?
• Is default allow-all outbound still in place on sensitive workloads?

3. Data

• Is encryption at rest on for new storage, with a key you control where needed?
• For S3, are all four Block Public Access settings on?
• Do stateful resources have a deletion policy, backups or prevent_destroy?
• Do retained snapshots or buckets have an owner?

4. Secrets

• No literal credentials in templates, variable files or defaults.
• Terraform: is a secret passing through state? Look for ephemeral or write-only options.
• CloudFormation: dynamic references instead of embedded values.
• Are saved plans stored with restricted access and short retention?

5. Dependencies

• New or bumped providers: did the lock file change, and is the version expected?
• New modules: pinned to a version or commit, from a source you recognize?
• Provider and module upgrades arrive in their own change, not buried in a large diff.

6. What the plan will do

• Read the plan summary: counts of add, change and destroy.
• Any destroy or replace on a stateful resource needs a named approver.
• Removed resource blocks hide in large diffs. Search for deletions.
• Is ignore_changes newly added? Ask which attribute and why.
• Is the workspace or backend the one you expect? Workspaces share credentials, so a wrong selection can hit production.

Make the checklist cheaper

Automate what a machine can decide: open CIDRs, missing encryption, wildcard actions, unpinned modules, literal secrets. Leave humans the judgment calls on intent, blast radius and architecture. Keep a short list of approved patterns, such as public web ports on a load balancer, so reviewers do not reargue them.

Keep a record

A review is only evidence if it is recorded. Keep the pull request, the approver, the plan summary and the gate result together. Safeguard's compliance and evidence automation can collect this kind of trail, and its policies and gates can enforce the automated half of the checklist.

Quick check

Sources

• Dependency lock file (HashiCorp Terraform)
• Security best practices in IAM (AWS)
• Blocking public access to your Amazon S3 storage (AWS documentation)

Last reviewed: 19 October 2026.