Auditing ISO 27001 Annex A 8.32 Change Management is the rigorous verification of organizational and technical modifications to ensure security compliance. This process validates the Primary Implementation Requirement of formalizing a documented lifecycle for requests, testing, and authorization. The Business Benefit ensures stability by preventing unauthorized changes, thereby mitigating operational disruption and security risks.
This professional audit tool is designed for the rigorous verification of organisational and technical modifications. Use this checklist to validate compliance with ISO 27001 Annex A 8.32 (Change Management), ensuring that information security requirements are integrated into the entire lifecycle of any change.
1. Change Management Policy Formalisation Verified
Verification Criteria: A documented policy exists that defines the scope of changes (significant vs. minor), roles, responsibilities, and the mandatory stages of the change lifecycle.
Required Evidence: Approved Change Management Policy with version control and evidence of communication to relevant technical staff.
Pass/Fail Test: If the policy does not explicitly define what constitutes a “significant change” requiring security impact assessment, mark as Non-Compliant.
2. Change Request Documentation Integrity Confirmed
Verification Criteria: Every modification to the ISMS scope or technical environment is preceded by a formal record containing the description, justification, and proposed implementation date.
Required Evidence: A sample of 10 recent tickets from the Change Management System (e.g., Jira, ServiceNow) showing complete header data.
Pass/Fail Test: If any “Closed” change record is found without an initial justification or description of the original state, mark as Non-Compliant.
3. Security Impact Assessment Completion Validated
Verification Criteria: Each proposed change undergoes a specific review to identify potential risks to confidentiality, integrity, and availability prior to approval.
Required Evidence: Risk assessment logs or “Security Impact” fields within the change records for all high-priority modifications.
Pass/Fail Test: If the security impact assessment is treated as a generic “Yes/No” checkbox without a descriptive risk analysis for high-risk changes, mark as Non-Compliant.
4. Technical Change Authorisation Records Verified
Verification Criteria: Authorisation is granted by designated personnel (e.g., Change Advisory Board or System Owner) who are independent of the person requesting the change.
Required Evidence: Digital signatures, approval timestamps, or CAB meeting minutes linked directly to specific change IDs.
Pass/Fail Test: If changes are approved by the same individual who initiated the request (outside of documented emergency procedures), mark as Non-Compliant.
5. Back-out and Recovery Planning Documentation Present
Verification Criteria: All high-risk or infrastructure-level changes include a documented procedure to revert to the previous stable state if the implementation fails.
Required Evidence: The “Back-out Plan” or “Rollback Strategy” section within the technical change plan for the current audit period.
Pass/Fail Test: If a change was implemented without a documented rollback strategy, regardless of its success, mark as Non-Compliant.
6. Post-Implementation Review (PIR) Execution Confirmed
Verification Criteria: Changes are reviewed following implementation to confirm that the objectives were met and no security vulnerabilities were introduced.
Required Evidence: PIR records or “Resolution Code” verification notes indicating that the change was tested in the live environment post-deployment.
Pass/Fail Test: If the “Success” status of a change is updated without a recorded verification step or test result, mark as Non-Compliant.
7. Segregation of Duties in Change Lifecycle Validated
Verification Criteria: The environment prevents the same individual from developing, testing, and approving the same change into production.
Required Evidence: Access control lists for the CI/CD pipeline or change management tool showing distinct roles for “Developer” and “Approver.”
Pass/Fail Test: If an individual possesses “Owner” or “Admin” rights that allow them to bypass the approval workflow in the production environment, mark as Non-Compliant.
8. Emergency Change Procedure Activation Logs Verified
Verification Criteria: An expedited process exists for urgent security patches or service restoration, including retrospective review and documentation.
Required Evidence: Emergency Change (e-Change) logs and evidence of retrospective CAB approval within 48 hours of the event.
Pass/Fail Test: If an emergency change was performed without a subsequent formal review and documentation update, mark as Non-Compliant.
9. Stakeholder Communication and Notification Records Present
Verification Criteria: Users and relevant stakeholders are notified of planned changes, potential downtimes, or modifications to security protocols.
Required Evidence: Email archives, Slack/Teams channel announcements, or intranet maintenance notices corresponding to scheduled change windows.
Pass/Fail Test: If a significant system change occurred without a record of user notification prior to implementation, mark as Non-Compliant.
10. Change Window and Resource Planning Evidence Confirmed
Verification Criteria: Changes are scheduled to minimise operational disruption and ensure that support resources are available during the transition.
Required Evidence: A Master Change Schedule or Calendar showing assigned windows and resource allocation for the implementation phase.
Pass/Fail Test: If changes are implemented during peak business hours without specific management authorisation or resource contingency, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Impact Assessment | GRC tool identifies that a Jira ticket exists and marks it as “Passed”. | The auditor must verify that the *content* of the assessment actually addresses security risks, not just functional ones. |
| Authorisation | Tool checks if an “Approved” status exists in the metadata. | Verify that the approver has the technical competence and authority for that specific asset class. |
| Segregation of Duties | SaaS tool verifies that two different names appear on the ticket. | Inspect the IAM policy to ensure the Developer *physically could not* push the code themselves without the second person. |
| Back-out Plans | The platform confirms a “Rollback Plan” field is populated with text. | Read the rollback plan; verify it is a technical procedure and not just the words “We will restore from backup.” |
| Emergency Changes | Tool ignores any ticket tagged as “Emergency” to avoid SLA alerts. | Demand the retrospective audit trail for emergency changes; these are the highest risk events. |
| PIR Review | SaaS tool assumes “Closed” means “Reviewed”. | Verify evidence of testing in production to ensure the change didn’t break existing security controls (Regression testing). |
| Documentation Update | Tool checks if a policy document exists in the folder. | Verify that technical documentation (network diagrams, etc.) was updated to reflect the change. |
About the author
