Is cloud infrastructure managed via IaC (Terraform, CloudFormation, Bicep, Pulumi)?
Demonstrate that cloud infrastructure is provisioned and modified exclusively through version-controlled Infrastructure as Code tooling, with evidence of change management processes and minimal manual configuration drift.
Description
What this control does
Infrastructure as Code (IaC) management requires that cloud infrastructure provisioning, configuration, and lifecycle changes are defined in version-controlled declarative or imperative code using tools such as Terraform, AWS CloudFormation, Azure Bicep, or Pulumi. This approach replaces manual console-based changes with automated, repeatable deployments that undergo peer review, testing, and approval workflows. IaC enables configuration drift detection, audit trails of infrastructure changes, and the ability to restore or replicate environments consistently, reducing the attack surface introduced by ad-hoc modifications and undocumented shadow infrastructure.
Control objective
What auditing this proves
Demonstrate that cloud infrastructure is provisioned and modified exclusively through version-controlled Infrastructure as Code tooling, with evidence of change management processes and minimal manual configuration drift.
Associated risks
Risks this control addresses
- Unauthorized or unapproved infrastructure changes bypass change control processes, introducing misconfigurations or backdoors without audit trails
- Configuration drift between environments creates inconsistent security postures, allowing vulnerabilities in production that were not present in tested staging environments
- Manual provisioning errors lead to overly permissive IAM policies, exposed storage buckets, or improperly configured network security groups
- Lack of version control for infrastructure prevents rollback after security incidents or failed deployments, extending outage windows and attacker dwell time
- Shadow IT infrastructure provisioned outside IaC tooling evades security scanning, compliance checks, and vulnerability management
- Inability to reproduce disaster recovery environments accurately due to undocumented manual changes made directly in cloud consoles
- Insufficient peer review of infrastructure changes allows insecure configurations to reach production without security team visibility
Testing procedure
How an auditor verifies this control
- Obtain a complete inventory of cloud accounts, subscriptions, or projects in scope across AWS, Azure, GCP, or other cloud providers.
- Review the organization's IaC repository structure and identify all active Terraform workspaces, CloudFormation stacks, Bicep deployments, or Pulumi projects managing production infrastructure.
- Select a representative sample of 10-15 cloud resources (compute instances, storage buckets, databases, network components) from production environments using cloud provider APIs or console queries.
- For each sampled resource, trace its provisioning history by examining resource tags, CloudTrail/Activity Log events, or deployment metadata to determine whether it was created via IaC or manual console operations.
- Review git commit history for the IaC repositories over the past 90 days to verify that infrastructure changes undergo pull request workflows with documented approvals.
- Execute IaC drift detection commands (terraform plan, CloudFormation drift detection, or equivalent) against production environments to identify resources modified outside of IaC workflows.
- Interview DevOps and infrastructure engineers to document the process for emergency or break-glass scenarios where manual changes might be permitted and how such changes are reconciled into IaC.
- Examine CI/CD pipeline configurations to confirm that IaC deployments include automated security scanning (tfsec, Checkov, CloudFormation Guard) and that failed scans block deployments.