The ultimate audit guide to ISO 27001 Annex A 8.32 Change Management
Table of contents
- 1. Verify the Change Management Policy
- 2. Ensure Technical Change Log Completeness
- 3. Evidence Peer Review and Technical Authorisation
- 4. Check for Impact Assessment and Risk Analysis
- 5. Evidence Rollback and Back-out Plan Integrity
- 6. Get UAT and Security Testing Evidence
- 7. Ensure Operational Documentation Alignment
- 8. Ensure Emergency Change Procedure Enforcement
- 9. Review Access Control Segregation During Changes
- 10. Evidence that Post-Implementation Review (PIR) Effectiveness is Recorded
1. Verify the Change Management Policy
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. Ensure Technical Change Log Completeness
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. Evidence Peer Review and Technical Authorisation
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.
DO IT YOURSELF
ISO 27001
All the templates, tools, support and knowledge you need to do it yourself.
4. Check for Impact Assessment and Risk Analysis
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. Evidence Rollback and Back-out Plan Integrity
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. Get UAT and Security Testing Evidence
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. Ensure Operational Documentation Alignment
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. Ensure Emergency Change Procedure Enforcement
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. Review Access Control Segregation During Changes
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. Evidence that Post-Implementation Review (PIR) Effectiveness is 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.
About the author
