How to implement an ISMS 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. 

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 not any different in this regard:  formal documentation is indeed required. 

Where ISO 27001 is a slightly unusual standard is in its inclusion of a very comprehensive list of “controls” an organisation must consider as part of their implementation, where a control is a method for treating risks.  Probably as a result of this, 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 risks and scoring them is very much a case of 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 what information you want to protect exactly and understanding the risks to that information. Then decide how to address those risksimplement any required technology solutions and write the necessary documentation.  

With that in mind, we’ve devised a 12 steps to approach to implementing an ISMS with ISO 27001 based on Deming’s Plan-Do-Check-Act model. We have also included the following video to provide further insight on how to implement ISO 27001.

Threat Protect Cybersecurity Glossary – ISO27001

12 Steps to implementing an ISMS with ISO 27001

PDCA ISO 27001 12 step implementation approach

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 therefore 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 actually 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: 

  1. 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. 
  2. 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:
  1. avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
  2. taking or increasing the risk in order to pursue an opportunity;
  3. removing the risk source;
  4. changing the likelihood;
  5. changing the consequences;
  6. sharing the risk with another party or parties (including contracts and risk financing); and
  7. 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, all the controls taken together amount to 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.

“The knowledge transfer between Elisabeth and Jorge and I was easy, starting each meeting with questions so we could get a better understanding of that particular step in the process. Elisabeth also helped us become independent by providing us with templates we could use to write our documentation.”

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/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 – 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 if the policies and procedures are indeed managing risks, if people are following them and if technology solutions are working.

Relevant people or group(s) 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. 

Elisabeth Belisle

Elisabeth Belisle

Elisabeth is an Associate Consultant of the British Standards Institute (BSI), a BSI qualified ISO 27001 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.

Use our free health check tool to assess your software project