ISO 27001 Annex A 8.32 Audit Checklist

In this ultimate how to audit guide to ISO 27001 Annex A 8.32 Change Management, you will learn directly from an ISO 27001 Lead Auditor:

• 10 Key Audit Steps
• Verification Criteria
• Required Evidence
• The Pass / Fail Test

I am Stuart Barker, the ISO 27001 Lead Auditor and author of the Ultimate ISO 27001 Toolkit.

Using over 30 years of industry experience across hundreds of audits, I’m giving you the exact templates, walkthroughs, and practical examples you need to achieve ISO 27001 certification.

Auditing ISO 27001 Annex A.8.32 ensures that changes to information processing facilities and systems are controlled to minimize disruption and security risks. The audit confirms the Primary Implementation Requirement of a formalized Change Management process involving assessment, authorization, and review. The Business Benefit is operational stability and the prevention of unauthorized or untested modifications.

Use this pass/fail checklist to strictly validate compliance with ISO 27001 Annex A 8.32 (Change management). For a detailed methodology on how to conduct the interviews and system tests required to generate this evidence, refer to our Annex A 8.32 Audit Guide.

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.