If you have been keeping up with the world of information security, you’ve likely noticed that the ISO 27001 standard recently underwent its first major refresh in nearly a decade. For those managing compliance, the transition from the 2013 version to the ISO 27001:2022 update felt like a significant shift, particularly regarding how the Annex A controls were restructured. One of the most critical areas for any operational business is change management, now found under Annex A 8.32.
But what actually changed? If you were comfortable with the 2013 requirements, do you need to tear up your handbook and start again? Let’s dive into the nuances of Annex A 8.32 and how it differs from its predecessor.
Table of contents
The Shift from Control 12.1.2 to 8.32
In the ISO 27001:2013 version, change management was primarily addressed under Control 12.1.2. It sat within the “Operations Security” domain and was largely focused on the process of making changes to information processing facilities and systems. In the 2022 update, this has been reclassified as a “Technological Control” and renumbered to 8.32.
The rename to “Change Management” from the previous “Change Management” might seem redundant, but the context has expanded. The 2022 version is designed to be more holistic, acknowledging that changes today happen faster and across more complex infrastructures than they did in 2013.
What Are the Key Differences?
The primary difference between the 2013 and 2022 versions is the level of integration required. While the old standard often treated change management as a checklist for IT updates, Annex A 8.32 in the 2022 version demands a more rigorous, risk-based approach that spans the entire lifecycle of an information system.
According to the experts at Hightable.io, the 2022 version places a much stronger emphasis on the security impact of changes. It’s no longer just about documenting that a change happened; it’s about proving that the security implications of that change were assessed before the “go” button was pressed. This means your change management process must now be inextricably linked to your risk management process.
Focusing on Modern Development Cycles
Back in 2013, many organisations were still working with “Waterfall” project management. Today, we live in a world of Agile, DevOps, and CI/CD pipelines. The ISO 27001:2022 update reflects this evolution. Annex A 8.32 is more “tool-agnostic” and flexible, making it easier to apply to automated environments.
The updated control explicitly requires that any change, whether it’s a software update, a hardware replacement, or a configuration tweak in the cloud, follows a formal procedure. This includes:
- Planning and testing changes before implementation.
- Assessing the potential impact on security controls.
- An approval process that ensures accountability.
- Procedures for “rolling back” if a change goes wrong.
The Introduction of Attributes
One of the biggest changes in the 2022 version across all controls, including 8.32, is the introduction of “Attributes.” These are metadata tags that help you categorise and sort your controls. For Annex A 8.32, these attributes identify the control as “Preventative,” “Corrective,” and “Detective.”
This is a major step up from the 2013 version. It helps security teams understand the purpose of the change management process. For instance, testing a patch before deployment is “Preventative,” while having an audit log of who made a change is “Detective.” This structured approach makes it significantly easier to report on your security posture to stakeholders and auditors.

How to Align with the 2022 Requirements
If you are transitioning from the 2013 version, you don’t necessarily need to start from scratch. However, you should review your existing change management policy to ensure it covers the broader scope of 8.32. Hightable.io suggests that organisations should look closely at their “emergency change” procedures, as these are often a point of failure during audits under the new standard.
You’ll also want to ensure that your documentation reflects the “security by design” philosophy. Every change request should ideally have a checkbox or a section dedicated to “Information Security Impact Assessment.” If you can show an auditor that you considered security before making a configuration change in your cloud environment, you are well on your way to compliance.
Conclusion
The move from ISO 27001:2013 to the 2022 version for change management represents a shift from a reactive IT task to a proactive security strategy. Annex A 8.32 is more comprehensive, more integrated with risk management, and better suited for the high-speed digital landscape we operate in today. By focusing on the intent of the control, minimising the risk of unauthorised or harmful changes, you can ensure your organisation remains both compliant and secure.
