ISO 27001 A.8.32: Change management

Define a change management policy and process covering all changes to information processing systems. Categorise changes: standard (pre-approved, low-risk, repeatable), normal (require assessment and approval), and emergency (urgent fixes with expedited approval and retrospective review). For each change, capture: a description and purpose, risk assessment covering security and availability impact, testing plan and results, step-by-step implementation plan, rollback plan, affected systems and stakeholders, required approvals, and scheduled implementation window. Set up a Change Advisory Board (CAB) or equivalent approval process for non-standard changes. The CAB reviews risk, testing results, and implementation readiness. Make sure security has a seat at the table to assess implications. For automated CI/CD deployments, embed these principles as automated gates rather than manual reviews. Test changes before they touch production. Use your separated test and staging environments. Include security testing in the validation. Confirm the change does not introduce vulnerabilities or break existing security controls. Log every change. Record the description, date, who implemented it, who approved it, test results, and the outcome. This log serves auditors and is invaluable during incident investigation since many incidents trace back to a recent change. For significant changes, run a post-implementation review. Verify the change achieved its goal. Confirm no unintended side effects. Assess whether the process worked well. Update documentation to reflect the new state. For emergencies, have an expedited process that allows fast action while keeping essential controls in place. Emergency changes still get documented, tested where possible, and reviewed after the fact. If you are using the emergency path too often, that is a sign your standard process needs fixing.