If you have ever seen a software update crash a critical server on a Friday afternoon, you already know why ISO 27001 Annex A 8.32 exists. In the world of information security, “change” is often a synonym for “risk.” Whether it is patching a vulnerability, upgrading a database, or even changing a physical lock on a server room door, every modification carries the potential to break something.
ISO 27001 Annex A 8.32, titled simply “Change management,” is designed to stop these self-inflicted wounds. It does not mean you cannot change things; it just means you need a referee on the field to make sure the game is played safely. Here is how you can implement this control effectively without drowning in red tape.
Table of contents
Understanding the Core Requirement
The objective of this control is ensuring that changes to information processing facilities and information systems are subject to change management procedures. In plain English, you need a standard way to handle updates so that you don’t accidentally expose data or take your business offline. This applies to everything from your IT infrastructure and software to your operational processes.
Step 1: Define Your Change Types
Not all changes are created equal. Implementing a massive server migration is very different from fixing a typo on your website. To keep your process agile, you should categorise changes. Common categories include:
- Standard Changes: Low-risk, pre-authorised tasks that happen frequently (e.g., patching a laptop).
- Normal Changes: Significant changes that require review and approval (e.g., upgrading a firewall).
- Emergency Changes: Critical fixes that need to happen now to resolve an incident (e.g., stopping an active cyber attack).
Step 2: The Change Request Process
You need a formal way to request a change. This doesn’t have to be a complicated paper form; a ticket in your project management tool works perfectly. The key is capturing the “who, what, when, and why.” You need to know exactly what is changing and why it is necessary.
According to the experts at Hightable.io, documentation is often where companies trip up. They note that while change management isn’t overly complex, it can become a “documentation overhead.” Their advice is to keep it simple but rigorous: ensure every request has a clear trail so an auditor can see the lifecycle of the change from idea to execution.
Step 3: Risk Assessment and Impact Analysis
Before you approve a change, you need to ask: “What could go wrong?” This is the heart of Annex A 8.32. You must assess the potential impact on security. Will this update reset permission settings? Will the new hardware require a port to be opened to the internet?
If you skip this step, you are flying blind. A simple risk assessment checklist attached to your change request can save you from a disaster later.
Step 4: Approval and Authorization
Who says “yes”? For small changes, this might be a team lead. For major architectural shifts, you might need a Change Advisory Board (CAB). The standard requires that changes are authorised by the right people. Ensure that the person pressing the button has the authority—and the knowledge—to do so.
Step 5: Testing and the Fallback Plan
Never deploy a change to production without testing it first. Ideally, you should have a staging environment that mirrors your live setup. If the change works there, it is likely safe for the real world.
However, even the best-laid plans can fail. This is why you need a “rollback plan.” If you deploy the update and the system crashes, how do you go back to the way things were five minutes ago? If you cannot answer that question, you are not ready to make the change.
Step 6: Post-Change Review
Once the dust has settled, take a moment to review. Did the change achieve its goal? Did it cause any unexpected side effects? This “closing the loop” ensures that your process improves over time and that you are learning from both your successes and your near-misses.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Why This Matters for Your Audit
Auditors love change management because it is a clear indicator of maturity. If you can show a log of changes, complete with approvals, risk assessments, and test results, you prove that you are in control of your environment. It moves you from a chaotic “fix-it-when-it-breaks” culture to a proactive, secure operation.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
