Change is a constant part of running a business. You update software, you modify access rights, and you switch cloud providers. However, in the world of information security, every change brings a new risk. If you change a firewall rule without checking it first, you might accidentally leave a door open for hackers. This is where Annex A 8.32 comes in.
As a certification body, we see many companies struggle here. They either do too little or complicate things too much. The goal of this control is simple. You must ensure that changes to information processing facilities and information systems are controlled. We are here to guide you on how to do this simply and effectively.
Table of contents
Understanding the Basics of Change Management
The core idea of Annex A 8.32 is that you should not make changes blindly. You need a standard way to request, assess, approve, and implement changes. This applies to your technology, your physical offices, and your business processes.
You do not need to buy expensive software to do this. For smaller setups, a simple spreadsheet or a document template is enough. The key is consistency. You must treat every significant change with the same level of care.
Step 1: Define Your Change Management Process
Your first step is to write down how change happens in your company. This is your policy. It does not need to be long. It just needs to state that all changes go through a set of checks before they go live. You can find excellent templates for this on ISO27001.com if you do not want to start from scratch.
You should define different types of changes. A minor software patch does not need the same scrutiny as moving your entire database to a new server. Categorise them into low, medium, and high impact. This helps you move fast without breaking the rules.
Step 2: The Request and Risk Assessment
When someone wants to change something, they must record it. This is the “Change Request.” It should include details on what is changing and why. Once the request is made, you must look at the risks.
Ask yourself simple questions. What happens if this goes wrong? Will it stop the sales team from working? Could it delete data? If the risk is high, you need more people to review it. If the risk is low, a quick check might be enough.
Step 3: Approval and Testing
Before you press the button to make the change, someone must say yes. This is the approval stage. For high-risk changes, this might be a group of people or a “Change Advisory Board.” For smaller changes, it might just be the IT manager.
Once approved, you must test the change. Never test in your live environment if you can avoid it. Use a test area. Check that the new update works and that it has not broken anything else. We will look for proof of this testing during your audit.
Step 4: The Fallback Plan
Even the best plans can fail. You need a safety net. This is called a “fallback plan” or a “back-out plan.” If you install a new update and the system crashes, how do you go back to how it was before? You must document this before you start the work. Knowing you can undo a mistake gives you confidence.
What We Expect During Your Audit
When we visit you for your certification audit, we look for evidence. We do not just take your word for it. We will ask to see your log of changes for the last few months. Then we will pick a random sample to investigate.
For the sample we pick, we expect to see the full story. We want to see the initial request. We want to see that someone assessed the risk. We want to see an email or a digital stamp showing approval. Finally, we want to see the test results and the fallback plan. If you have these records, you will satisfy the auditor.
Common Pitfalls to Avoid
The biggest mistake we see is people bypassing the process for “emergency” changes. Emergencies happen, but you still need to record them. You might do the paperwork after the fix is applied, but the paperwork must exist. If we find changes in your system that do not match your logs, it creates a problem.
Another issue is lack of detail. “Fixed server” is not a good description. You need to be specific about what was changed so that anyone looking back can understand the history.
Summary
Implementing Annex A 8.32 does not have to be painful. It is about creating a safety habit. You identify the change, you check the risk, you get permission, and you test it. If you follow this flow and keep records, you will protect your business and pass your ISO 27001 audit with ease. If you need more resources or templates to help you structure this, ISO27001.com is a great place to look.