Implementing ISO 27001 Annex A 8.32 is the process of establishing a formal change management lifecycle to ensure that all modifications to information processing facilities are controlled, documented, and authorized. This requires defining strict change categories and enforcing technical rollback plans for every deployment. The primary benefit is preventing unauthorized system alterations and minimizing the risk of operational disruption and security incidents.
ISO 27001 Annex A Change Management Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.32. This control demands that all changes to information processing facilities and systems are controlled, documented, and tested to prevent disruption.
1. Define Change Categories
Control Requirement: Changes must be categorised to determine the level of authorisation required.
Required Implementation Step: Create a formal document defining three distinct categories: ‘Standard’ (pre-authorised, low risk), ‘Normal’ (requires CAB approval), and ‘Emergency’ (critical fixes requiring retrospective sign-off). Hard-code these categories into your ticketing system.
Minimum Requirement: A documented definition of what constitutes a ‘Standard’ vs ‘Normal’ change.
2. Establish a Change Advisory Board (CAB)
Control Requirement: High-risk changes must be reviewed by a competent authority before execution.
Required Implementation Step: Appoint a cross-functional CAB comprising Technical Leads, Security, and Operations. Schedule a weekly ‘Stand-up’ to review pending ‘Normal’ changes, rejecting any that lack sufficient testing evidence.
Minimum Requirement: A recurring calendar invite for CAB reviews with defined members.
3. Implement Ticket-Based Change Requests
Control Requirement: All changes must be formally requested and recorded.
Required Implementation Step: Configure your ITSM tool (e.g., Jira, ServiceNow) to enforce mandatory fields for every change request: Description, Reason, Impact, and Rollback Plan. Disable the ability to merge code or deploy without a linked ticket reference.
Minimum Requirement: No change occurs without a unique reference ID.
4. Mandate Security Impact Assessments
Control Requirement: The potential security impact of every change must be assessed prior to authorisation.
Required Implementation Step: Add a mandatory ‘Security Assessment’ section to the change request form. Developers must explicitly state if the change touches PII, authentication mechanisms, or firewall rules.
Minimum Requirement: A specific ‘Yes/No’ check for security implications on every ticket.
5. Enforce Pre-Production Testing
Control Requirement: Changes must be verified in a controlled environment before being applied to production.
Required Implementation Step: Require evidence of successful testing (logs, screenshots, or automated test results) attached to the change ticket. The environment used must mirror production configurations.
Minimum Requirement: Testing evidence is attached to the ticket before CAB review.
6. Create Detailed Rollback Plans
Control Requirement: Procedures to abort and recover from failed changes must be defined.
Required Implementation Step: For every ‘Normal’ or ‘Emergency’ change, write a specific, step-by-step technical script to reverse the change. Generic statements like “We will restore from backup” are unacceptable; provide the exact commands.
Minimum Requirement: A tested script or command list to revert the specific change.
7. Secure Formal Authorisation
Control Requirement: Changes must not be implemented without explicit approval from the relevant authority.
Required Implementation Step: Implement a digital signature or ‘Approve’ button workflow that locks the ticket once approved. Ensure the approver is never the same person as the implementer (Segregation of Duties).
Minimum Requirement: A timestamped audit log of who clicked ‘Approve’.
8. Control Emergency Changes
Control Requirement: Emergency changes must remain controlled despite the urgency.
Required Implementation Step: Create a ‘Break Glass’ procedure where emergency changes can be deployed immediately but must be reviewed and documented retrospectively by the CAB within 24 hours. Monitor this channel closely to prevent abuse for deadline-dodging.
Minimum Requirement: Retrospective tickets filed within one business day of an emergency fix.
9. Notify Affected Parties
Control Requirement: Users and stakeholders must be aware of changes that affect them.
Required Implementation Step: Automate notifications to the Service Desk and relevant department heads when a change is scheduled. Include expected downtime duration and specific services at risk.
Minimum Requirement: An email or Slack notification sent prior to deployment.
10. Conduct Post-Implementation Reviews (PIR)
Control Requirement: The success or failure of changes must be reviewed to improve future processes.
Required Implementation Step: For failed changes or those that caused incidents, hold a mandatory PIR meeting. Analyse the root cause, update the risk register, and adjust the change policy if necessary to prevent recurrence.
Minimum Requirement: A ‘Lessons Learned’ record for every failed change.
ISO 27001 Annex A 8.32 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Risk Assessment | SaaS tool offers a “Low/Med/High” dropdown menu. | Developer selects “Low” to bypass the CAB meeting, despite the code modifying core authentication logic. |
| Authorisation | SaaS tool shows a green “Approved” tick. | The ‘Approver’ was the same person as the ‘Requester’, just using a different browser session. |
| Rollback Plan | SaaS tool accepts any text in the “Backout” field. | The field contains “Revert if broken”, which is useless when the database schema has already been dropped. |
| Testing Evidence | SaaS tool stores a screenshot named “test.jpg”. | The screenshot shows the code running on the developer’s local laptop, not the staging environment. |
| Emergency Changes | SaaS tool tracks “Emergency” tickets. | “Emergency” status is habitually used to bypass process deadlines rather than for genuine critical incidents. |
| Segregation of Duties | SaaS tool links to an organisational chart. | The Senior Dev has full Admin rights to both the ticketing system and the production server, bypassing all gates. |
| Post-Change Review | SaaS tool asks “Was it successful?” (Yes/No). | Users click “Yes” immediately after deployment, ignoring the slow memory leak that crashes the server 48 hours later. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
