Are cloud configuration changes peer-reviewed and traceable to a ticket?
Demonstrate that all cloud infrastructure configuration changes are subject to peer review by a qualified individual and are traceable to an approved change ticket with documented business justification.
Description
What this control does
This control ensures that all configuration changes made to cloud infrastructure (such as IAM policies, network security groups, compute instances, storage permissions, and service configurations) undergo mandatory peer review by a second qualified individual before deployment, and that each change is documented in and traceable to an approved change ticket or work item. The peer review process verifies technical correctness, adherence to security standards, and alignment with business requirements. This control establishes accountability, reduces the likelihood of misconfigurations that lead to breaches or outages, and creates an auditable trail linking changes to business justification.
Control objective
What auditing this proves
Demonstrate that all cloud infrastructure configuration changes are subject to peer review by a qualified individual and are traceable to an approved change ticket with documented business justification.
Associated risks
Risks this control addresses
- Unauthorized or malicious configuration changes deployed by a single individual without oversight, enabling insider threats or account compromise escalation
- Accidental misconfiguration of security controls (e.g., overly permissive IAM policies, exposed storage buckets, disabled logging) due to lack of technical review
- Deployment of changes that violate compliance requirements or organizational security policies without detection
- Inability to correlate configuration changes with incidents or outages during forensic investigation due to missing or incomplete change records
- Privilege escalation or lateral movement opportunities created by improperly reviewed changes to network segmentation or access controls
- Configuration drift and inconsistency across environments when changes are made ad-hoc without standardized approval workflows
- Regulatory penalties and audit findings due to lack of demonstrable segregation of duties in infrastructure change management
Testing procedure
How an auditor verifies this control
- Obtain and review the organization's cloud change management policy, including defined roles, peer review requirements, approval workflows, and ticketing system integration procedures.
- Identify all cloud platforms in use (AWS, Azure, GCP, etc.) and enumerate the infrastructure-as-code repositories, change management tools, and ticketing systems used to manage configuration changes.
- Select a representative sample of 15-25 cloud configuration changes spanning the audit period, ensuring coverage across different platforms, change types (IAM, network, compute, storage), and personnel.
- For each sampled change, retrieve the corresponding change ticket and verify it contains business justification, change description, rollback plan, and approval evidence prior to implementation.
- Examine version control system logs (Git commits, pull requests, or equivalent) to confirm each sampled change has documented peer review comments, approvals by a second individual, and timestamp evidence predating deployment.
- Cross-reference change ticket identifiers with deployment logs, infrastructure-as-code pipeline execution records, or cloud provider audit logs (CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) to confirm traceability and timing.
- Interview cloud platform engineers and change approvers to validate understanding of peer review requirements, escalation procedures for emergency changes, and enforcement mechanisms.
- Test automated controls by reviewing CI/CD pipeline configurations for mandatory approval gates, branch protection rules requiring reviews, or policy-as-code enforcement blocking unapproved changes.