Skip to main content
← All controls
CM-3 / CM-3(2) / CM-4 / AC-2(4) NIST SP 800-53 Rev 5

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

  1. Obtain and review the organization's cloud change management policy, including defined roles, peer review requirements, approval workflows, and ticketing system integration procedures.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Interview cloud platform engineers and change approvers to validate understanding of peer review requirements, escalation procedures for emergency changes, and enforcement mechanisms.
  8. 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.
Evidence required Collect change management policy documentation, screenshots or exports of ticketing system records showing change requests with approvals, version control system logs demonstrating peer review activity (pull request approvals, review comments), cloud provider audit logs correlating changes to ticket identifiers, CI/CD pipeline configuration files showing approval gate enforcement, and interview notes or attestations from change approvers. Include configuration exports or screenshots demonstrating technical controls such as branch protection rules or required reviewer settings.
Pass criteria All sampled cloud configuration changes are traceable to an approved change ticket with documented business justification and demonstrate evidence of technical peer review by a qualified individual other than the change author, with no exceptions for non-emergency changes and documented post-implementation review for emergency changes.