As the saying goes “Nothing endures but change.”  Meaning that ‘change’ is something that is the only constant thing in life.  And that’s what ISO 27001 – A8.32  is focusing our attention on.  The purpose being to preserve information security when executing changes in your processing facilities and systems. 

Change can be small and insignificant, to large and dramatic. It will be down to you to decide what level of change management you need. But keep in mind that it relates to everything from physical locations to network devices or applications, change needs to be managed.  

What does the standard require?

The standard states that “Changes to information processing facilities and information systems shall be subject to change management procedures.” (A8.32 – Change management) 

Note that although this control sits with the list of ISO27001 Annex A technical controls, it’s focus is on information processing facilities and information systems. Therefore, if you’re changing offices, or suppliers who process data (e.g. Cloud providers) then this should be subject to the same level of rigour as any change to your technical infrastructure or software. 

Why is this required?

Changes can cause all manner of problems for you and your business if they are uncontrolled. 

Uncontrolled changes could lead to compliance issues, data breaches and vulnerabilities being introduced into your organisation that place you at risk from cyberattack.  Change management ensures that changes are implemented in a structured way, in order to eliminate these risks. 

Imagine for example a situation where anyone can make a change to the application you’re developing. There would be no control over the testing process, and changes could have a negative impact on other aspects of the application or service which the change maker is unaware of. 

Change management ensures that any change happens with everyone fully in the picture of what is happening, why, and what impact the change might have. 

What the auditor is looking for

For this ISO27001 control, the auditor will expect to see a variety of security measures that might include; 

• Changes in relation to projects (A5.8 – Information security in project management)
• Software development lifecycle (A8.27 – Secure system architecture and engineering principles)
• Management Review Team (MRT) meeting minutes.
• Risk Register.

 The auditor will look for evidence of controlled changes, therefore you should be able to show them completed Change Request Forms (CRF), or minutes from meetings where you assessed and discussed changes. Depending on the size of your business, the formality of the process will vary, and you may need to show different levels of evidence. This could range from displaying emails where changes are discussed to involving a formal “Change Advisory Board” (CAB) that discusses and approves all changes. 

What do you need to do?

Establish how your business currently manages change at the various levels. Remembering that this isn’t just about development means you need to speak to the business leaders, so start with the Management Review Team (MRT). Ask what would happen if they moved offices? What about moving Cloud provider? How about changing the finance or HR system? 

Dependent on the size of the change, a full project initiation document (PID) might be created with timelines and full risk assessment.  Other changes might be controlled informally with evidence coming from email conversations about the change and the sign-off process. 

You might find it useful to develop a Change Request Form (CRF), to manage requests for change. But if this is the case, keep it simple.  The CRF should outline; 

• What the change is.
• What the benefits are.
• Who is involved in the change.
• What the timeline for the change is.
• Risks associated to the change (focusing on Confidentiality, Integrity, Availability and Privacy)
• What contingency arrangements (if any) are required.

Although it is not specifically stated within this control, it’s worth keeping in mind that the General Data Protection Regulation (GDPR) expects organisations to complete Data Processing Impact Assessment (DPIA). A DPIA is a process designed to help you systematically analyse, identify and minimise the data protection risks of a project or change. For example, if you are changing the location of your Cloud provider, where you process data, then a DPIA should be completed and any risks identified and treated appropriately.  

Speak to your Data Protection Lead or Officer about how DPIAs are completed and see if you can become part of that process. 

Difficulty rating

We rate this a 2 out of 5 difficulty rating. The difficulty in this control is that you may need to introduce a level of formality which others find restrictive and controlling. This requires careful negotiation and a balance between what is practical and what is necessary.  Don’t go over board here. Keep it simple and appropriate to the business you’re working in.  Keep in mind that the more difficult you make this process, the more likely people will find work around or simply ignore the process altogether. 

For example, we worked with a client who had been told by another consultant (NOT a Consultant Like Us), that they must complete a CRF for every change in the business. The form the consultant provided was 5 pages long, and the business was developing changes to systems on a weekly basis!

 The consultant was more interested in Quality Management, but the quality of the completed forms was poor, and the client was sinking in a sea of paperwork!! 

It caused frustration and annoyance in the business and was totally unnecessary. 

We streamlined the form down to a single page and made a rule that only significant changes affecting client facing systems would require the completion of the CRF. 

Life is hard enough. Don’t make it harder for yourself! 

Q&A

Do I need a documented procedure?

This control mentions the word procedures, but it doesn’t specifically state that they need to be documented.  However you need to consider how you are going to have confidence that changes are being fully assessed for risks to confidentiality, integrity and availability.  Therefore having a documented process is advisable.  At the very least you should have a ‘Change Management Form’, which is completed for any significant change that takes place. 

Just don’t over complicate this process. Many organisations (especially those involved in development) will say that they are an ‘agile’ business, and therefore changes happen continually.  Go back to your software development lifecycle and see how change is managed there (i.e. when systems are updated).

 Also ensure that changes are discussed within the Management Review Team (MRT) Meetings to fully assess impact of the change on information security.

More questions?