Periodic Review Checklist of IaC Practices
This checklist applies to all Infrastructure as Code (IaC) projects developed or maintained internally. It serves as an instrument of binary and auditable verification of the practical adoption of the prescriptions of Chapter 08, enabling:
- Objective control of the application of requirements
IAC-001toIAC-013; - Integration with PR, release, audit and onboarding processes;
- Generation of operational and compliance indicators.
🗓️ Review is recommended at each new release, relevant PR or change to a critical environment.
📋 Verification Items
| Item | Verified? |
|---|---|
Is the remote backend configured with authentication and locking, with lock logs available? (IAC-001) | ☐ |
Are the dev/staging/prod environments segregated and versioned in distinct directories or workspaces? (IAC-002) | ☐ |
Does the pipeline run blocking validations (lint/syntax, security scanner and policy) whose failure prevents the apply? (IAC-003) | ☐ |
Do modules use a fixed version or hash (no latest/main), from allowlisted sources, with verified provenance/integrity? (IAC-004) | ☐ |
Is there a versioned history with semantic tags and notes per release? (IAC-005) | ☐ |
Are naming/tagging/layout conventions validated automatically, and are resources without mandatory tags rejected? (IAC-006) | ☐ |
Does each apply occur only after recorded human approval of the plan attached to the PR, with no manual apply outside the pipeline? (IAC-007) | ☐ |
Is it possible to trace, for any resource, the originating IaC file, environment and pipeline? (IAC-008) | ☐ |
Is policy-as-code enforcement blocking at pre-merge and pre-apply, with versioned policy and blocking logs? (IAC-009) | ☐ |
Are plan/manifest artefacts versioned with a hash, with integrity confirmed before the apply and without reuse across environments? (IAC-010) | ☐ |
Is there automated secret scanning and a prohibition of secrets in code, with vault integration (Vault/KMS/OIDC) and short-lived ephemeral credentials? (IAC-011) | ☐ |
Is there automated detection of drift between the IaC and the real state, with alerts, treated as a security failure corrected via PR? (IAC-012) | ☐ |
Is there a formal periodic review of modules/templates with records (date, owner, findings) and removal of obsolete or vulnerable ones? (IAC-013) | ☐ |
| Is all proposed IaC treated as untrusted input by origin (human, template, generator or assisted tool)? | ☐ |
Are exceptions managed in a versioned format with a blocking TTL, and is there a rollback/kill-switch procedure for destroy in production? | ☐ |
🔄 Operational Integration
-
This checklist may be applied manually (e.g. PR review) or integrated into CI/CD as a gate.
-
It may be used in formal architecture reviews, releases or the onboarding of new repositories.
-
Each item must be validated with objective evidence:
backend.tffiles,tfseclogs, CI screenshots, hashes in releases, etc.
⚠️ Negative answers require a formal, approved and documented exception (see governance model).
📊 Compliance and KPI
- Validation of this checklist makes it possible to declare compliance with Chapter 08 - Infrastructure as Code.
- The count of verified items may be used for operational KPIs of adoption and maturity.
- It may be included as evidence in audits, exception processes or release gates.
📌 This mechanism is aligned with the model of continuous control and traceability defined in SbD-ToE.