Achieve ISO 27001
How to implement an ISMS using ISO 27001
What is an information security management system and how can you implement it using ISO 27001
In this article you’ll find out where to start in order to implement an Information Security Management System (ISMS) using ISO 27001 and what the steps are. At Digital Octopii we’ve developed a 12 step approach to certification that will make sure you get there as quickly as possible.
This article assumes you have no or little documented policies and procedures in place for ISO 27001. If that is not the case you can complete a gap analysis using our free requirements checklist.
Reading time: 7 minutes
Most people know that to implement any ISMS or standard, some level of documentation is required: policies, procedures, detailed work instructions, etc. ISO 27001 is no different in this regard: formal documentation is indeed required.
Where ISO 27001 is a slightly unusual standard is in its inclusion of a comprehensive list of “controls” an organisation must consider as part of their implementation. A “control” is a method for handling risks. A very common question is “should I start with writing the documentation or with implementing the controls?”. The answer is “neither”.
ISO 27001 is an information security management system which “…preserves the confidentiality, integrity and availability of information by applying a RISK MANAGEMENT process…” (direct quote from the second paragraph of the standard).
Therefore, writing documentation or applying controls to treat risks BEFORE identifying and scoring them is putting the cart before the horse. My advice is – especially for small businesses who don’t have information security experts or highly technical people in their team – start by agreeing the information you want to protect and understanding the risks to that information. Next, decide how to address those risks, implement any required technology solutions and write the necessary documentation.
With that in mind, we’ve devised a 12 step approach to implementing an ISMS with ISO 27001 based on Deming’s Plan-Do-Check-Act model. We have also included the video below to provide further insight on how to implement ISO 27001.
In this article we will cover the following steps:
- Define objectives
- Define your scope
- Make an inventory of assets
- Define your risk management framework
- Identify the risks and score them
- Risk treatment plan(s)
- Verify risk treatment plans against the Annex A controls
- Write documentation
- Implement technical risk mitigating solutions
- Manage the change
- Operate your ISMS
- Continuous improvement
Threat Protect Cybersecurity Glossary – ISO27001
12 Steps to implementing an ISMS with ISO 27001
Step 1 – Define objectives
Implementing an ISMS with ISO 27001 is a lot of work. Make sure everyone is clear about what you want to achieve with the implementation; and make sure there’s a champion at top level supporting those objectives.
Step 2 - Define your scope
What information are you trying to protect exactly? What information would your clients, shareholders, trustees or other interested parties like you to protect? It’s useful to start by considering all your business processes when determining the scope.
Very high-level process maps will make it clear where the information you want to protect is held, in which systems and networks it resides, who is responsible for it and who has access to it .
Step 3 – Make an inventory of assets
This is an inventory of the information you want to protect and the other assets associated with it (e.g. hardware, software, databases, physical locations). Again, it’s useful to do this using a process map for the business processes in scope.
Step 4 - Define your risk management framework
This standard is about managing the risks to the confidentiality, integrity and availability of the information. This is a crucial part of your implementation. While the framework isn’t prescribed explicitly, you do need to put in place a framework that includes a risk assessment process that produces consistent scores no matter who does the assessment. The framework also needs to produce risk treatment options that take into consideration the results of the risk assessment.
Step 5 - Identify the risks and score them
ISO 27001 is part of a “family” of standards, the ISO 27000 series. ISO 27005 is the part that provides guidelines for information security risk management. It proposes two approaches to identify and score risks:
- Scenario based approach: risks are identified by considering events and scored by assessing their consequences. In other words, you try and think of everything that could go wrong (events) and determine what impact (consequences) this would have on the confidentiality, integrity and availability of the information in your scope.
- Asset-threat-vulnerability approach: risks are identified using the inventory of assets as the starting point. For each category of assets (e.g. laptops, servers, networks) the threats (theft, human error, malware, etc) to those assets, their vulnerabilities (e.g. lack of relevant employee security training) and their value to the organisation (monetary or other) are considered and scored accordingly.
While in theory the scenario-based approach seems simpler and more attractive, in practice I have observed that unless the people doing the risk assessment are very knowledgeable about information security, they quickly run out of steam. It’s often a case of “you don’t know what you don’t know!”. For that reason I tend to prefer the Asset-Threat-Vulnerability approach.
Step 6 - Risk treatment plan(s)
For each risk identified, you need to decide on a treatment. The note to the definition of risk treatment in BS EN ISO/IEC 27000:2017 gives seven options:
- avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk
- taking or increasing the risk in order to pursue an opportunity
- removing the risk source
- changing the likelihood
- changing the consequences
- sharing the risk with another party or parties (including contracts and risk financing)
- retaining the risk by informed choice
Excepting option 2 and 7, all the other options imply that you either change the likelihood of a risk occurring and/or change the severity of the consequences if it does occur. In both cases, this is done through a “control”. For example, you might decide that to avoid the risk of losing a laptop that contains sensitive customer data, you will not allow that data to be on the laptop in the first place. To make sure people don’t store customer data on their laptop, there needs to be something that prevents loading the information or detects that it has been transferred so it can be removed. Those are the controls. Generally speaking, the combined controls become the Treatment Plan – but you could have multiple Treatment Plans. Personally, I like to call this the Risk Action Plan because it’s the basis for the actions you decide to take.
Step 7 – Verify risk treatment plan against the Annex A controls
To help make sure that no necessary controls are overlooked in your ISMS, ISO 27001 proposes a list of 114 controls, each of which must be considered, and their inclusion or exclusion justified. This list of what you include or not and the justifications form the Statement of Applicability.
This list of controls is where ISO 27001 is both very useful and potentially harmful to your project. I have seen organisations start with this list of controls, without first assessing their risks and using the result of this assessment to prioritise their action plan. They go down the list and find the best technology and procedures to implement each one of the controls. They inevitably end up with endless internal arguments, spending far more time and money than they anticipated and have no clear sense of priorities. If you take anything away from this article, please DON’T start with Annex A!
Step 8 - Write documentation
At this point you will have a clear view of what your risks are and what you need to do to manage them. This is when you will be most efficient at writing the documentation, i.e. the policies and procedures describing how you will operate your ISMS.
Note that it’s not a requirement for all procedures to be formally documented. However if it’s a process that isn’t done very frequently or if it’s complex with several steps, it’s probably best to document it to minimise human error.
Step 9 – (at same time as step 8) – Implement technical risk mitigating solutions
It is more than likely that you’ll need to implement technical solutions. Whether it’s tightening up security groups on your on-premise Active Directory, implementing a Directory-as-a-Service solution, changing the anti-malware software in place or implementing information classification and data retention functionality in your document management system, technology-based changes are afoot.
Step 10 - Manage the change
Although this comes in at step 10 – all good business analysts and change managers will tell you that changing the way people work needs to start at the very beginning of a project. Don’t forget that people will probably need to be trained on new procedures and/or systems. ISO 27001 impacts people – it is a business transformation project, not an IT project.
Step 11 – Operate your ISMS – internal audits, measures, monitoring and management reviews
You are now in the “Check” and “Act” sections of the PDCA diagram above. Regular internal audits, measurements (e.g. key performance indicators) and monitoring will help you verify whether the policies and procedures are indeed managing risks, if people are following them and if technology solutions are working.
Relevant people or groups in your governance structure will review the outcomes of audits, measures and monitoring and make decisions to keep the same controls in place or amend.
Step 12 - Continuous improvement
Steps 1 to 11 become a “business-as-usual” cycle and you have an ISMS!
Don’t forget that implementing an ISMS is a major business project which will likely change the way people work. It may even turn into a programme with multiple underpinning projects. The usual critical success factors for any project therefore apply: backing from the senior team is required, a budget must be approved and resources allocated, a senior executive appointed as accountable lead, a project manager appointed, etc. Although not an IT project, many components are IT based and therefore you might find our IT Project Processes article useful.