Menu
Create relevant treatment plans and map controls for a successful Information Security Management System (ISMS)
Due to the information security nature of ISO 27001, it’s crucial to have relevant and workable treatment plans and controls in place. In this article, we’ll talk you through different risk treatment plans, options, and controls and also touch on the Statement of Applicability and ISO 27017 for cloud organisations:
Reading time: 7 minutes
A risk treatment plan in the context of ISO 27001 is a documented plan that outlines how an organisation will respond to identified risks that are identified in the risk assessment process. The risk treatment plan is a key part of the risk management process and is designed to ensure that the organisation’s risks are effectively managed and mitigated.
Requirements relating to risk treatment and controls are found in clause 6.1.3. Unfortunately, it’s full of jargon, and a few definitions are required if you don’t want to get flustered when the external auditor asks for your risk treatment plan.
Risk Treatment (as exactly defined by ISO 27000): process to modify risk
When approaching this stage of your journey to certification, its not only important to understand what risk treatment in ISO 27001 is, but it is also important to understand other terms relevant to it. Below are some definitions:
In plain English, a risk treatment plan (a requirement in 6.1.3 e)) refers to your decision about which risk treatment option you choose to implement for each risk, and a control is the measure you will put in place to implement that plan.
For example:
You might have heard of the 4Ts in risk management. They refer to how you decide to handle risks, i.e. they are your Risk Treatment Options in ISO language. They are Tolerate, Treat, Transfer and Terminate. If we compare those with the definition of Risk Treatment on the previous page, you’ll see they match perfectly with the options given in the ISO 27000 definition:
We prefer to use the 4Ts because they are easy to understand, and their use is widespread outside of information security.
A control is a measure that modifies risk and controls, including any process, policy, device, practice, or other actions which modify risk.
It follows, therefore, that where you’ve decided to Treat or Transfer a risk, you have a control to implement. Where you’ve decided to Tolerate a risk, you might already have a control in place.
ISO 27001 is quite a unique standard in that it provides a list of 93 controls categorised into four themes for you to choose from. In theory, according to clause 6.1.3 you’re supposed to determine what your controls should be, and then compare them with the list in Annex A to see if you’ve missed any.
In practice, the Annex A list is so comprehensive that you might as well just start with it. To make this easier for you, we’ve already identified in the risk catalogue which Annex A control(s) each risk could be treated by.
Note that you might also choose to implement controls that are not listed in Annex A. Unlikely, given how comprehensive the list is, but possible. That’s perfectly fine. Just document, in the Risk Register against the relevant risk, what that control is.
A Statement of Applicability (SoA) is a document that is prepared as part of the ISO 27001 certification process. The purpose of the SoA is to identify which information security controls from Annex A of the ISO 27001 standard are applicable to the organisation’s information security management system (ISMS).
Clause 6.1.3 d) asks you to produce a Statement of Applicability, often referred to as the SoA. It also asks that you justify why you’ve included a control, whether it is implemented, and why not if you’ve decided not to implement an Annex A control.
The easiest and most common way to produce an SoA is to have a list of all the Annex A controls in a spreadsheet with 4 columns to indicate:
In our example template we’ve provided a drop down with the most common justifications for implementing a control.
Those are:
If you are a cloud-based organisation or provide cloud services, you might have heard of ISO 27017, and you might be wondering if you should, or must, include this in your ISMS.
ISO 27017 (Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services) provides additional controls for organisations that use cloud services (cloud service customer) and/or provide cloud services (cloud service provider). ISO 27017 provides specific guidelines for cloud service providers (CSPs) and cloud customers to ensure that the confidentiality, integrity, and availability of information is maintained in a cloud environment.
Note that you don’t need to provide cloud infrastructure to be classed as a provider. Any organisation that provides a cloud-based service or product using a 3rd party platform (such as Azure, AWS or Google, for example) is considered a cloud service provider. In fact, such an organisation would be considered both a customer and a provider.
In order to obtain certification to ISO 27001, it is NOT a requirement to include ISO 27017 controls in your ISMS, even if your organisation is a cloud service customer and/or provider.
In most cases, our recommendation would be, therefore, to keep things simple initially and not include 27017 in your list of controls to implement (i.e. your Statement of Applicability). Start by implementing what you HAVE TO implement for ISO 27001, then improve by selecting relevant controls from ISO 27017.
Elisabeth is an Associate Consultant of the British Standards Institute (BSI), a BSI qualified ISO Lead Auditor and member of the Standard Committee responsible for the publication of the BS 10008 Standard.
Elisabeth can help you decide if ISO 27001 is for you and support you through its implementation, all the way to certification.