Auditing ISO 27001 Annex A 8.32 Change Management is the technical verification of formal processes governing modifications to information systems. The Primary Implementation Requirement is the enforcement of gated approval workflows and risk-based impact assessments, providing the Business Benefit of system stability and prevention of unauthorized production outages.
ISO 27001 Annex A 8.32 Change Management Audit Checklist
This technical verification tool is designed for lead auditors to establish the integrity of the operational environment through controlled modifications. Use this checklist to validate compliance with ISO 27001 Annex A 8.32.
1. Change Management Policy Formalisation Verified
Verification Criteria: A documented policy defines the roles, responsibilities, and mandatory steps for identifying, logging, and reviewing changes to information processing facilities.
Required Evidence: Approved Change Management Policy or Standard Operating Procedure (SOP) with defined change categories (Standard, Normal, Emergency).
Pass/Fail Test: If the organisation cannot produce a formal document specifying the mandatory workflow for technical changes, mark as Non-Compliant.
2. Technical Change Log Completeness Confirmed
Verification Criteria: A centralised register or ITSM tool contains a comprehensive history of all requested, rejected, and implemented changes.
Required Evidence: Change log exports from tools like Jira, ServiceNow, or Azure DevOps showing unique IDs and timestamps.
Pass/Fail Test: If significant infrastructure modifications (e.g. firewall rule updates) are missing from the central change register, mark as Non-Compliant.
3. Peer Review and Technical Authorisation Validated
Verification Criteria: Technical changes require review and authorisation by an independent party (not the requester) before being scheduled for production.
Required Evidence: Change Request (CR) records showing digital sign-off from a technical lead or the Change Advisory Board (CAB).
Pass/Fail Test: If a developer or system administrator can approve and implement their own production changes without a second-party sign-off, mark as Non-Compliant.
4. Impact Assessment and Risk Analysis Confirmed
Verification Criteria: Every change request includes a documented assessment of potential impacts on information security and business continuity.
Required Evidence: Risk assessment section within CR tickets identifying affected assets, dependencies, and security control impacts.
Pass/Fail Test: If changes are approved with “N/A” or blank entries in the impact assessment field for critical systems, mark as Non-Compliant.
5. Rollback and Back-out Plan Integrity Verified
Verification Criteria: Documented procedures exist for every change to revert the system to its previous known-good state in the event of failure.
Required Evidence: “Back-out Plan” or “Rollback Procedure” attached to sampled Change Request tickets.
Pass/Fail Test: If a major production change fails and no technical plan exists to restore service immediately, mark as Non-Compliant.
6. UAT and Security Testing Evidence Validated
Verification Criteria: Technical changes undergo successful User Acceptance Testing (UAT) and security verification in a non-production environment before approval.
Required Evidence: Signed UAT reports, vulnerability scan results, or “Staging” environment test logs linked to the CR.
Pass/Fail Test: If code or configurations are promoted to production without documented evidence of testing in a segregated environment, mark as Non-Compliant.
7. Operational Documentation Alignment Confirmed
Verification Criteria: Systems documentation, network diagrams, and recovery procedures are updated as an integral part of the change closure process.
Required Evidence: Version history logs of network diagrams or Wiki/Confluence pages showing updates corresponding to implemented changes.
Pass/Fail Test: If the production environment differs significantly from the current architectural documentation following a change, mark as Non-Compliant.
8. Emergency Change Procedure Enforcement Verified
Verification Criteria: A specific, accelerated process exists for emergency changes, ensuring they are documented and retrospectively reviewed within the policy timeline.
Required Evidence: Emergency Change logs showing retrospective CAB approval and post-implementation review notes.
Pass/Fail Test: If an emergency change was implemented but never documented or formally reviewed after the incident, mark as Non-Compliant.
9. Access Control Segregation During Changes Validated
Verification Criteria: Temporary elevated privileges required for changes are granted only for the duration of the change and revoked immediately thereafter.
Required Evidence: PAM (Privileged Access Management) logs or JIT (Just-in-Time) access records showing account expiration.
Pass/Fail Test: If an administrator retains permanent “Owner” or “Domain Admin” rights following the completion of a specific change, mark as Non-Compliant.
10. Post-Implementation Review (PIR) Effectiveness Recorded
Verification Criteria: Completed changes are reviewed to ensure the desired outcome was achieved without introducing new security vulnerabilities.
Required Evidence: Completed PIR reports for major or failed changes showing lessons learned and technical outcomes.
Pass/Fail Test: If recurring service outages occur due to the same change-related failures without evidence of a PIR, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Impact Assessment | Tool records that a ticket has a “Category” selected. | Verify Quality. An auditor must read the ticket. A category of “High” with no text describing the risk is a failure. |
| Segregation of Duties | Platform identifies that “Change Management is Active”. | Test Autonomy. Can a senior admin push a script to all servers via MDM without any secondary approval? GRC tools miss these backdoors. |
| Rollback Planning | Tool checks for the existence of an “Attachment”. | Validate Feasibility. If the “Back-out Plan” is just the word “Backup,” the control is a technical fiction. |
| Environment Isolation | GRC tool assumes Dev/Prod are separate accounts. | Check Cross-Account Access. If the same service account token works in both, the ‘Change’ between environments is unprotected. |
| Documentation Updates | Tool confirms a “Wiki Link” is present in the ticket. | Verify Accuracy. Open the link. If the diagram is from 2023 but the change is from 2026, the control has failed. |
| Emergency Audit | Platform identifies an “Emergency” checkbox. | Review Abuse. If 50% of changes are “Emergency,” the standard control is being bypassed and the GRC status is a lie. |
| Unauthorized Changes | Tool only monitors changes inside the ITSM tool. | Perform Drift Analysis. Compare the firewall config to the change log. Config changes with no ticket are a critical failure. |
Stop Guessing. Start Passing.
AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt
About the author
