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.

4. Approval Authorization 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.

**ISO 27001 Annex A 8.32 SaaS / GRC Platform Failure Checklist**
Control Requirement	The “Checkbox Compliance” Trap	The Reality Check
Approval Workflows	Tool allows anyone to click “Approve.”	Auditor must verify permissions gating. Can the Requestor approve their own ticket? If the tool doesn’t block self-approval, it fails Segregation of Duties.
Automated Documentation	“Agile” teams claim Git Logs are the documentation.	Auditor must look for the Risk Link. A Git commit shows code changes, but does it record the Security Impact Assessment? If not, code logs are insufficient.
Rollback Fields	Tool has a free-text field for “Backout Plan.”	Auditor must check for Empty/Junk data. Do users just type “N/A” or “Restore backup”? The tool should force specific, actionable rollback steps for High Risk changes.
SaaS Configuration Changes	Change Management applies only to “Code.”	Auditor must check Admin Audit Logs. If an admin changes a global setting in Salesforce/M365, is there a corresponding Change Ticket? Tools often miss Config changes.
Emergency Mode Abuse	Tool has a fast-track “Emergency” button.	Auditor must audit the ratio. If 50% of changes are “Emergency” to skip the queue, the process is broken. The tool should flag frequent emergency use.
Test Evidence	User ticks a box saying “Tested.”	Auditor must check for attachments. Does the tool require a screenshot or log file of the successful test? A simple tick-box is not evidence.
Audit Trail Immutability	Admins can edit closed tickets.	Auditor must check if history can be rewritten. Can an admin go back and change the “Approver” name after the audit starts? The log must be read-only.

About the author

Stuart Barker

ISO 27001 Ninja

Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigor with extensive operational experience, including a decade leading Data Governance for General Electric (GE).

As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.