IaC Plan Approval Policy
1. Objective
This policy defines the formal process for reviewing and approving Infrastructure as Code (IaC) execution plans - terraform plan, pulumi preview, cdk diff or equivalent - before any apply operation in staging or production environments.
apply is the highest-impact operation in IaC: it creates, changes or destroys real infrastructure resources. An unreviewed apply can delete databases, expose resources to the internet, remove security groups or reconfigure access policies in a way that is irreversible in the short term. Formal plan approval is not bureaucracy - it is the control mechanism that separates efficient automation from uncontrolled automation.
The objective of this policy is to ensure that:
- No apply is executed in staging/production without the plan having been reviewed and approved
- The plan is generated in the pipeline (not locally), ensuring reproducibility and traceability
- Segregation of duties prevents the same individual from writing, reviewing and executing the apply
- At L3, plans are signed to ensure that the apply uses exactly the approved plan
2. Scope and applicability
| Environment | L1 | L2 | L3 |
|---|---|---|---|
| Development | Recommended | Recommended | Mandatory (minimum record) |
| Staging | Recommended | Mandatory | Mandatory + dual approval |
| Production | Mandatory | Mandatory + formal approval | Mandatory + dual approval + signature |
3. Plan generation
3.1 Origin of the plan
The plan must be generated exclusively by the CI/CD pipeline - not by manual local execution:
- Plan job run from the commit reviewed in the PR
- Provider access credentials injected by the pipeline (OIDC/workload identity)
- Plan output exported as a pipeline artefact, with timestamp and reference to the commit SHA
Local generation of plans for preliminary review is accepted during development, but the plan that underpins the formal approval and the subsequent apply must always be generated by the pipeline.
3.2 Content of the plan output
The plan output must be presented readably in the PR (automatic comment or link to the artefact), including:
- Resources to be created, changed and destroyed - with count and identification
- Details of changes to security resources (security groups, IAM, policies, encryption)
- Alerts for destructive changes (resources to be deleted or replaced)
- Metadata: timestamp, PR author, commit SHA, target environment
4. Plan review
4.1 Review checklist
Before approving a plan, the reviewer must check:
- The changes match the scope of the PR - no unplanned changes
- No critical resource is unexpectedly destroyed or replaced
- No changes to security groups, IAM roles or policies not documented in the PR
- No resources exposed externally without justification
- No hardcoded secrets in the plan values
- Encryption changes or backup configurations not inadvertently removed
- Mandatory tags present on new resources
4.2 Mandatory reviewers
| Environment | L1 | L2 | L3 |
|---|---|---|---|
| Staging | Tech Lead | DevOps/SRE | DevOps/SRE + AppSec Engineer |
| Production | Tech Lead + DevOps/SRE | DevOps/SRE + AppSec Engineer | DevOps/SRE + AppSec Engineer (dual approval) |
Self-approval (the same individual who submitted the PR approves the plan) is prohibited in any environment.
5. Segregation of duties (SoD)
At L2/L3, the apply process must implement segregation of duties:
| Function | Responsible | Cannot be combined with |
|---|---|---|
| Writing and submitting the IaC (PR author) | Developer / DevOps | Approving their own plan |
| Reviewing and approving the plan | Senior DevOps/SRE + AppSec | Being the PR author |
| Executing the apply in production | Pipeline (automated) | Being the same person who approved |
At L3, no individual may have permission to unilaterally execute an apply in production - execution must be performed by the pipeline, conditional on the recorded approval of at least two distinct roles.
6. Plan signing (L3)
At L3, the approved plan must be signed before it is used by the apply job:
- Plan serialised and signed with a key managed by the pipeline (e.g. Cosign, GPG)
- Pipeline attestation associated with the plan (provenance: who generated it, when, from which commit)
- The apply job verifies the signature before executing - it rejects plans without a valid signature or with the signature of a plan other than the approved one
- Signature verification logs archived as evidence
7. Apply execution windows
At L3, the apply in production must be executed within a defined change window:
- Change window communicated and recorded before execution
- Apply not executed outside the window without explicit emergency approval
- Emergency approvals recorded with justification and notification to the security owner
8. Apply traceability
Every apply operation must produce traceable evidence:
- Complete apply logs archived as a pipeline artefact
- Log includes: start and end timestamp, affected resources, result (success/failure), pipeline identity
- Reference to the PR and to the approved plan
- Reference to the formal approvals (identity and timestamp of the approvers)
At L3, apply logs must be immutable (WORM) and retained in accordance with the Traceability Policy.
9. Emergency apply
In incident situations with an impact on production, it may be necessary to execute an apply outside the normal process. In this case:
- Emergency approval recorded with identity, justification and timestamp (before execution whenever possible)
- Apply executed by the pipeline with the minimum changes needed to mitigate the incident
- Post-mortem carried out after resolution, with analysis of the deviation from the process and corrective measures
A direct manual apply to the provider (outside the pipeline) in production is prohibited at L2/L3, including in emergency situations. The exception must be documented and reported to the security owner.
10. Responsibilities
| Role | Responsibility |
|---|---|
| Developer / DevOps (author) | Submit a PR with a clear description of the impact; do not execute an apply before approval |
| DevOps/SRE (reviewer) | Review the plan output with the checklist; approve only when the criteria are met |
| AppSec Engineer | Review plans with security impact; approve at L2/L3; define signing criteria |
| GRC / Compliance | Audit approval records; verify segregation of duties; validate change windows |
11. Review and audit of this policy
This policy must be reviewed annually or after any of the following events:
- An incident originating from an unreviewed or unapproved apply
- A change to the IaC tools with an impact on the plan generation and signing process
- A change to the organisation's change window policy
12. Normative and technical references
| Reference | Relevance |
|---|---|
| SbD-ToE Ch. 08 - IaC and Infrastructure | US-06 (formal plan review), US-09 (signing), US-15 (SoD) |
Secure IaC Policy (21_policy-iac-seguro.md) | General requirements for secure IaC |
Secrets Management Policy (18_policy-gestao-segredos.md) | Pipeline credentials for apply |
Traceability Policy (06_policy-rastreabilidade.md) | Archiving of apply logs |
| ITIL Change Management | Framework for change management and execution windows |
| SLSA Framework | Provenance and integrity of IaC artefacts |
| Cosign | Artefact signing (including IaC plans) |