Change management
Purpose
Subject changes to information processing facilities and systems to formal change management procedures.
How to meet this control
In short: Subject changes to information processing facilities to change management.
- Step 01Operate a formal change management process covering documentation, impact assessment, testing, approval and implementation for ICT and software
- Step 02For software teams, use pull requests, required reviews and a change record (ticket plus merge history) to satisfy the process
- Step 03Assess each change for impact and dependencies and obtain authorisation before implementation
- Step 04Test changes and accept the results first, with a documented deployment and rollback plan
- Step 05Communicate changes to affected parties and update operating and user documentation
- Step 06Update continuity, response and recovery plans where the change affects them, and keep records
Tip: PRs, approvals and a change record satisfy this for most software teams.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Follow a formal process of documentation, specification, testing, quality control and implementation
- ›Integrate change control procedures for ICT infrastructure and software
- ›Plan and assess the potential impact of each change, accounting for dependencies
- ›Require authorisation of changes and communicate them to relevant interested parties
- ›Test changes and accept those results before implementation, including deployment plans
- ›Plan emergency and contingency steps with fall-back procedures and keep records
- ›Update operating documentation and user procedures as needed
- ›Update ICT continuity, response and recovery plans after the change
Audit evidence to keep
- - Change management policy or procedure
- - Sample change record with impact assessment and approval
- - Pull request showing review and merge for a software change
- - Rollback or back-out plan attached to a change
- - Evidence documentation was updated after a change
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.32. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.