ISO 27001 Annex A 8.32 Audit Checklist

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

1. Change Management Policy Formally Defined

• Verification Criteria: A documented procedure exists defining the lifecycle of a change (Request, Assess, Approve, Implement, Review) for all information processing facilities.
• Required Evidence: The “Change Management Policy” or “SDLC Standard” (Version controlled and approved).

Pass/Fail Test: If the organisation relies on “ad-hoc” Slack messages or verbal agreements to deploy changes to production, mark as Non-Compliant.

2. Formal Change Requests (RFC) Verified

• Verification Criteria: Every change to production systems originates from a formal Record of Change (RFC) or Ticket that captures the scope and reason.
• Required Evidence: A sample of 5 recent Jira/ServiceNow tickets showing the initial request details and business justification.

Pass/Fail Test: If changes appear in the system logs (e.g., git commit history) that cannot be linked back to a specific Change Ticket, mark as Non-Compliant.

3. Security Impact Assessment Confirmed

• Verification Criteria: Each change request includes a mandatory assessment of its potential impact on information security before approval.
• Required Evidence: The “Risk Assessment” or “Security Review” field within the change ticket (populated, not blank).

Pass/Fail Test: If a major firewall rule change was processed as a “Standard Change” with zero security impact analysis, mark as Non-Compliant.

4. Approval Authorisation Verified

• Verification Criteria: Changes are formally authorized by a designated individual (Change Advisory Board or System Owner) prior to implementation.
• Required Evidence: Timestamped approval logs within the ticketing system showing who approved the change and when.

Pass/Fail Test: If the developer who wrote the code also approved their own deployment to production (lack of segregation), mark as Non-Compliant.

5. Pre-Implementation Testing Validated

• Verification Criteria: Changes are verified in a non-production (staging/test) environment before being applied to live systems.
• Required Evidence: Test results attached to the Change Ticket or CI/CD pipeline logs showing successful test execution (Green build).

Pass/Fail Test: If evidence shows “Hotfixes” applied directly to production without a prior test run in a staging environment, mark as Non-Compliant.

6. Back-Out (Rollback) Procedures Documented

• Verification Criteria: Every approved change includes a specific, documented plan to reverse the change if it causes failure.
• Required Evidence: The “Rollback Plan” field in the change ticket (e.g., “Restore DB snapshot ID: xyz” or “Revert to Git Commit: abc”).

Pass/Fail Test: If the rollback plan is listed as “We will fix it forward” or is left blank for a high-risk change, mark as Non-Compliant.

7. Emergency Change Protocol Verified

• Verification Criteria: A distinct process exists for “Emergency Changes” that allows for rapid deployment but requires retrospective documentation and authorization.
• Required Evidence: An “Emergency Change” log showing post-incident review and retroactive approval within a defined timeframe (e.g., 24 hours).

Pass/Fail Test: If emergency changes are treated as “free passes” to bypass documentation entirely rather than just delaying it, mark as Non-Compliant.

8. Segregation of Duties Enforced

• Verification Criteria: The person requesting/developing the change is different from the person authorizing/deploying the change (where proportionate).
• Required Evidence: Access control lists (ACLs) for the production environment or workflow rules preventing self-approval.

Pass/Fail Test: If a single user has full Admin rights to Request, Approve, and Deploy changes without oversight, mark as Non-Compliant.

9. Stakeholder Communication Verified

• Verification Criteria: Affected users and stakeholders are notified of planned changes and potential downtime.
• Required Evidence: “Maintenance Window” emails or status page updates linked to specific Change Tickets.

Pass/Fail Test: If a critical system update caused downtime and the Service Desk was unaware (no notification sent), mark as Non-Compliant.

10. Post-Implementation Review (PIR) Confirmed

• Verification Criteria: Major or failed changes undergo a review to verify success or analyze the root cause of failure.
• Required Evidence: PIR meeting minutes or “Closure Codes” (e.g., Successful, Failed, Withdrawn) in the change log.

Pass/Fail Test: If failed changes are simply closed and forgotten without a documented review of why they failed, mark as Non-Compliant.

About the author