Understanding ISO 27001

The ISO 27001 Standard is written using a standardised ISO glossary of terms. These apply across the whole breadth of ISO Standards, so if you are implementing multiple standards, you can quickly understand what is required and get on with it.

Unfortunately, if this is your first exposure to ISO standard speak, it is a little bit incomprehensible. Lots of terms are used with very little explanation for what is required, and the reader has to go away and figure things out for themselves.

A lot of other advice on ISO 27001 simply regurgitates these terms as though they are apparent and they don’t spend any time explaining what the terms mean. More importantly, they do not explain why they are there and what they are seeking to achieve.

In this post, I will try to explain what the ISO 27001 Standard is trying to achieve. I will try to explain how the Standard attempts to steer you along a particular implementation path without being prescriptive.

And maybe explode a few myths along the way.

What is an ISMS?

ISMS stands for Information Security Management System. While that sounds like a bit of a mouthful, it actually explains itself very well. It is a management system for the management of Information Security.

Myth 1: An ISMS is a set of controls

WRONG. I’ve seen this a lot in various texts and it is just plain wrong. The ISMS is the system you use to manage your security controls. It is the system that allows you to decide which security controls you need, how you will implement them, how you will check they are working. The ISMS is a framework that allows security controls to be managed. The ISMS is the box that you put your controls into. It is a management system for controls. In this case, Information Security Controls.

A management system allows you to effectively manage something. In this case, it is Information Security.

A lot of people have a problem understanding what on Earth clause 4 (Context of the Organisation) is all about.

Clause 4.4 is the easiest to understand as we have just explained that one. It says you need to have an ISMS. You can argue that it is a little bit weird to define something within itself, as the entire scope of the standard is to establish an ISMS, but I will leave that to one side. Tick box, move on.

Clause 4.3 Determining the scope of the ISMS

I know I’m going out of order, but this is a little bit the fault of the standard because to understand 4.1 and 4.2, you have to have already understood scope (4.3) and that you need an ISMS (4.4).

Not getting these in the right order may contribute to an initial lack of clarity and understanding.  So what do we mean by scope? If the ISMS is a box where you put controls and manage them, how big is the box?

Is it big enough for everything that the organisation does, or does the box only apply to some subset of the organisation? Everything that a company does is an easy concept to grasp. In this case, your boundary is everything that is controlled and influenced by the company.

Don’t confuse this with what happens inside the company and outside the company.

Time for an example:

Your company produces widgets. It supplies widgets to wholesalers and buys steel with which to make the widgets. Here we can draw the distinction between what the company is, and what the company does.

The company influences and controls its supply chain through requirements it makes in its commercial contracts. Therefore, the scope of what the company does is bigger than just the company, its employees and the work it conducts. It includes all of the activities and processes the company undertakes including commercial contracts with customers and third parties.

So in defining a scope, you should look at this from a process perspective and not a physical asset perspective. The company is more than just a set of buildings and people. It is what the company does that is important here, not what it is physically.

But I want a subset, not everything?

There are times when it is sensible just to take a subset of processes to be within your scope. The obvious example here is if you are an IT Outsourcer and a client has requested that as part of a contract, the work you do for them must be covered by an ISO 27001 certification.

You can then easily draw your scope boundary around all of the processes that are required for that specific contract, rather than all the work that you do as a business.

But surely it must be easier to just do everything? There are sensible reasons why you may want to restrict scope if you are dealing with client contractual requirements.

Your client may wish to see the audit reports. Your client may wish to see any non-conformities that result from your internal and external audits of the ISMS.

If you restrict your scope to only the processes impacting that particular client, you will not have to have interesting conversations about not being able to share data on an audit, due to it exposing work you do for another client.

Generally speaking, it is easier to place everything within scope, but as indicated above, there are exceptions to this that should be reviewed.

Clause 4.3 wants you to define this scope for your ISMS. What is inside, what is outside and what forms the boundary.

The boundary definition is important. If you cannot explain what separates what is on the inside of your scope, from what is on the outside, then it is not just the boundary that is ill-defined. Both inside and outside are ill-defined as well by definition.

Clause 4.1 Understanding the organisation and its context

This clause has the most complicated two lines of the standard to understand. If you understand this clause, then you are half-way to implementing the standard already.

This is the actual sentence.

The organisation shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcomes of its Information Security Management System.

Wow. Ok. Let’s break this down and re-assemble in English.

Let’s look at the last bit of the sentence first. To achieve the intended outcomes of the ISMS.

You are putting in place an ISMS for a reason. This is usually because someone else has told you that you need one of these. Maybe a customer has said you can’t land that big contract without one of these. Most of the ISO 27001 certification push has been from large clients wanting to ensure that their third parties can evidence appropriate security controls, by enforcing ISO 27001 compliance as part of commercial contractual negotiations.

Intended outcomes are what you want to achieve by implementing the ISMS. This relates to your scope as your outcomes will be within the bounds of your scope. Essentially this means ensuring that you can manage information security effectively within the risk appetite of the company, for the scope in question.

In order to do this, we need to know what internal and external factors influence our ability to do that.  

So re-written, the sentence says something like:

You will figure out what internal and external factors will get in the way of the organisation achieving the things that it wants to achieve and ensure that the ISMS can support the organisation in that achievement, by avoiding security landmines that may get in the way, within the defined scope of the ISMS.

If the scope of the ISMS is the whole company, then the achievement is for the whole company. If the scope is an outsourced contract, then it is the achievements against that outsourced contract. The achievement is relative to the scope.

Clause 4.2 Understanding the needs and expectations of interested parties

In essence, this clause says “figure out which entities should be interested in what you are doing with security, and then ensure that their requirements are covered by your ISMS”. This doesn’t mean you have to do all those things that everyone wants. It means you have to take them into consideration as part of your risk-based approach.

You can actually red-pen a lot of this in the risk assessments if you need to, but the point is you have to consider everything that other interested parties might expect or want you to do. The title of the clause says “Understand the needs and expectations”. It does not say “Deliver to the needs and expectations”.

Understanding Clause 4 is a massive step to understanding how to implement the ISMS. It gives you a structure with boundaries that all the other 4-10 clauses will drop into.