How to Audit ISO 27001 Annex A 8.32 Change Management

The ultimate audit guide to ISO 27001 Annex A 8.32 Change Management

1. Provision a Formalised Change Management Policy

Verify the existence of a documented policy that defines the scope, roles, and responsibilities for change management. This ensures that all stakeholders understand the mandatory requirements for modifying information systems.

• Inspect the policy for clear definitions of “standard,” “normal,” and “emergency” changes.
• Confirm that the policy has been approved by senior management and communicated to the technical teams.
• Check that the policy includes requirements for impact assessments and security reviews.

2. Audit the Logical Separation of Environments

Evaluate the technical separation between development, testing, and production environments. Strict isolation prevents untested code or configuration errors from impacting live services and protects production data from unauthorised access.

• Inspect network diagrams or cloud VPC configurations to confirm environment isolation.
• Verify that distinct IAM roles are used for each environment to prevent “privilege creep.”
• Confirm that production data is not used in test environments without formal anonymisation or masking.

3. Inspect IAM Roles for Segregation of Duties

Assess the assignment of Identity and Access Management roles to ensure that the individual who develops a change is not the same person who authorises its deployment to production. This prevents accidental or malicious unauthorised changes.

• Review the IAM role matrix for Segregation of Duties (SoD) conflicts.
• Check the CI/CD pipeline configurations to ensure that “Push to Production” requires a second-person approval.
• Verify that administrative access to production is restricted to a limited number of authorised personnel.

4. Evaluate Technical Impact Assessments

Examine a sample of change requests to verify that a security impact assessment was performed. This ensures that potential risks to the confidentiality, integrity, and availability of the system were considered before the change was implemented.

• Inspect change tickets for documented security risk reviews.
• Confirm that the assessment includes the potential impact on existing security controls and compliance obligations.
• Verify that high-risk changes triggered a deeper review, such as a vulnerability scan or penetration test.

5. Validate Formal Authorisation Records

Confirm that all changes in the production environment possess a verifiable audit trail of approval. Unauthorised changes are a primary source of security incidents and operational instability.

• Sample recent production deployments and trace them back to an approved Change Request (CR).
• Verify that the approver has the appropriate level of authority for the risk level of the change.
• Check that emergency changes were retrospectively reviewed and approved as per the policy.

6. Verify Technical Testing and UAT Results

Inspect evidence that changes were subjected to rigorous testing, including User Acceptance Testing (UAT), before being promoted to production. This ensures that the change performs as expected without introducing regressions.

• Review test plans and result logs for a sample of implemented changes.
• Confirm that security-specific tests, such as input validation or access control checks, were performed.
• Verify that the asset owner signed off on the test results prior to deployment.

7. Audit Fallback and Rollback Procedures

Assess the existence and adequacy of rollback plans for every change. This ensures that the organisation can quickly restore services to a known good state if a change causes an unforeseen incident.

• Check change records for documented fallback steps and “back-out” scripts.
• Verify that the criteria for invoking a rollback are clearly defined.
• Confirm that rollback procedures are tested periodically to ensure they remain functional.

8. Inspect the Technical Asset Register Update Process

Verify that the Asset Register is updated following changes that introduce new hardware, software, or cloud instances. Maintaining visibility of the attack surface is essential for effective vulnerability management.

• Sample changes involving new assets and check for corresponding entries in the Asset Register.
• Confirm that asset metadata, such as ownership and sensitivity, was correctly assigned.
• Verify that decommissioned assets were removed from the register and securely disposed of.

9. Formalise the Emergency Change Control Workflow

Audit the process for handling urgent changes required to resolve major incidents or security vulnerabilities. While speed is essential, control must be maintained to prevent secondary incidents.

• Verify that emergency changes follow a distinct, accelerated workflow with documented justification.
• Confirm that a post-implementation review is conducted for all emergency changes.
• Check that temporary access granted for emergency fixes was revoked immediately after completion.

10. Audit Post-Implementation Reviews for Security Incidents

Evaluate the records of post-implementation reviews (PIR) to ensure that changes did not lead to security incidents or performance degradation. This supports the continual improvement of the change management process.

• Review PIR documents for evidence of lessons learned and corrective actions.
• Confirm that incident logs are cross-referenced with the change log to identify “failed” changes.
• Verify that the Change Advisory Board (CAB) reviews PIR results to refine the change framework.

Annex A 8.32 Audit Checklist and Evidence Guide

Audit Step	How to Audit	Common Examples of Evidence
1. Policy Review	Verify that the policy is current and includes all necessary security criteria for changes.	Signed Change Management Policy; Approval meeting minutes.
2. Environment Isolation	Perform a technical walkthrough of cloud or physical infrastructure to prove separation.	VPC Peering diagrams; Firewall rule sets (Deny All between Test/Prod).
3. Segregation of Duties	Cross-reference developers in GitHub/GitLab with production deployers in CI/CD logs.	IAM Policy reports; Pipeline approval logs; SoD matrix.
4. Risk Assessment	Select a sample of “Major” changes and review the security analysis performed.	Completed Risk Assessment forms; Vulnerability scan reports for new code.
5. Approval Audit	Trace an implemented change back to the original request and authorisation.	Jira/ServiceNow tickets showing timestamps and authorised approver.
6. Testing Validation	Check that UAT was performed by someone other than the developer.	UAT sign-off emails; Bug tracking logs; Test case results.
7. Rollback Readiness	Ask a system administrator to explain the recovery steps for a specific recent change.	Documented Rollback Procedure; Infrastructure-as-Code (IaC) version history.
8. Asset Tracking	Verify if a newly provisioned server appears in the latest Asset Register.	Updated Asset Register; CMDB (Configuration Management Database) logs.
9. Emergency Changes	Confirm that emergency fixes were not used to bypass standard controls for non-urgent tasks.	Incident ticket linking to emergency change; Retrospective approval records.
10. PIR Analysis	Ensure that incidents caused by changes were documented as failures in the ISMS.	Post-Implementation Review reports; Root Cause Analysis (RCA) logs.

About the author