How to Audit ISO 27001 Annex A 8.32 Change Management

Auditing ISO 27001 Annex A 8.32 is the verification process that ensures changes to information processing facilities and information systems are controlled, managed, and approved to maintain security. It requires auditors to confirm that a structured change management lifecycle is applied, from request to post-implementation review, ensuring production stability and data integrity are not compromised by unauthorised or untested modifications.

Auditing Annex A 8.32 requires a technical deep dive into the organisation’s change control workflows. An auditor must verify that changes are not merely documented but are risk-assessed, tested, and authorised by personnel with the appropriate technical competence. Use the following steps to evaluate the effectiveness of the change management process within the ISMS.

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.

Common SaaS and GRC Platform Audit Failures

Audit Failure Mode	The SaaS / GRC Platform Bias	The Auditor’s Perspective (Anti-SaaS Bias)
“Paper” Compliance Only	Platforms show “Green Ticks” because a policy file is uploaded, ignoring actual tech workflows.	The software says you have change management, but the production logs show unauthorised edits.
Disconnected Workflows	GRC tools often sit in a silo, separate from the actual Jira or GitHub environments.	Lack of traceability between the “compliance record” and the actual code deployment.
Automated Approval Gaps	Tools may auto-approve based on “logic” that fails to capture human security nuance.	Automation cannot replace the professional judgement required for high-risk infrastructure shifts.
Asset Register Stagnation	SaaS tools often rely on manual imports that become outdated within days of an audit.	The platform shows an “Audit Ready” register that misses 30% of your current cloud footprint.
False Sense of SoD	Software assumes SoD exists because roles are defined, but ignores “God Mode” admin bypasses.	Configuring a tool is not the same as enforcing a technical restriction on the production floor.
Opaque Impact Assessments	Platforms provide generic checkboxes for risk that don’t reflect the organisation’s specific threat landscape.	A “Low Risk” tick in a GRC tool is meaningless without technical justification.
Lack of Rollback Evidence	Automation tracks the “Change” but rarely captures the specific “Plan B” required for recovery.	The GRC tool records the success, but provides no evidence that the team was prepared for failure.
Emergency Bypass Abuse	Users often find it easier to use the “Emergency” tag in the software to bypass slow workflows.	Excessive use of emergency workflows indicates a broken process that the software is masking.
Ignoring Shadow IT	SaaS GRC tools only see what you connect to them, ignoring unmanaged dev environments.	You cannot audit a change management process for assets the software doesn’t know exist.
Vendor Lock-in Risk	The audit trail is trapped in a proprietary SaaS format that is difficult for an auditor to export or verify.	If the internet goes down or the SaaS vendor fails, your compliance history vanishes.

About the author