ISO 27001 Clause 6.3 Audit Checklist

The ultimate audit guide to ISO 27001 Clause 6.3 Planning Of Changes

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.

About the author