From Chaos to Conformance: 4 Context of the organisation

Information security is all about context!

In my previous two articles in this series focused on developing an Information Security Management System (ISMS) based on ISO 27001:2013, I presented the common myths associated with the standard. In this article, I am going to provide an overview of the standard and section 4 Context of the organisation.

As discussed, the ISO 27001 standard sets out the things that an organisation must be able to demonstrate conformance with to be able to gain certification of its ISMS against the requirements. Figure 1 provides an overview of each section within the standard, which defines the requirements for each in a succinct manner (after all it is only 30 pages long with just 9 pages dedicated to specifying the requirements for an ISMS).

ISO27001:2013 Overview
Figure 1 – Overview of ISO 27001:2013

As you can see in Figure 1 (click on the image for the full size version), Section 4 Context of the organisation is divided into 4 subsections. Let’s take a look at each:

4.1 Understanding the organisation and its context

This requirement is designed to ensure that your ISMS actually supports and enables your organisation to achieve its business objectives. This means you need to identify and consider the internal and external factors that may affect the ability of the ISMS to successfully achieve the organisation’s desired outcomes. For some this can be quite challenging as they treat information security as a technical or compliance discipline, rather than a business risk management discipline.

To help identify the factors that may influence your ISMS, ISO 27001 refers to Clause 5.3 of the ISO 31000:2009 Risk Management standard, which provides guidelines for what could be included when seeking to identify internal and external issues. It is important to understand that the term ‘issues’ covers more than just the problems that require your organisation to take preventive action, it includes any important areas that must be addressed by the ISMS. So, what might this include? The internal context may include the organisational structure, roles and responsibilities, the business strategy, etc. Whereas, the external context could include the political, economic, financial, legal and regulatory environments, etc.

The real takeaway here is that the standard is trying to highlight that you need to understand your organisation and the context in which it operates to develop and implement an ISMS that is fit for its purpose. This is critical as it will ensure that information security supports and enables the business to achieve its objectives, rather than hinder or prevent it from doing so.

4.2 Understanding the needs and expectations of the interested parties

When you know what your organisation does and the context in which it operates you need to identify all of the internal and external parties that have an interest in your ISMS, together with their requirements for information security.

The first thing you need to do is identify and document all of the organisations and individuals that have an interest in or can influence the security of the information you collect, create, store, use, share, archive or destroy. This includes organisations or people that would be affected if the security of the information was compromised. Interested parties may include shareholders, government agencies, regulators, employees, clients, partners, suppliers, etc.

After you’ve identified the interested parties you need to ascertain what each of them wants or needs from you in regard to information security. For example, a regulator may require you to be able to demonstrate compliance with a specific piece of legislation, a business partner may require you to comply with a set of clauses in a contract, and a client might expect you to comply with the privacy act.

When identifying and capturing the interested parties and their requirements for information security you should aim to be as specific as possible to ensure that they are appropriately considered when establishing the ISMS. For example, by documenting the exact clauses in each of the laws, regulations and contracts your organisation needs to comply with.

4.3 Determining the scope of the information security management system

Once you have identified both the internal and external issues, together with the requirements of all interested parties you can define and document the scope of the ISMS. As discussed in the first article, an ISMS can cover the whole organisation or you can choose to limit the scope to a specific business capability, process, service, product, information system or physical location.

The scope is important as it defines what information you want to protect. It also defines what will be in scope for the certification audit should you choose to certify your ISMS against the ISO 27001 standard. There are numerous factors that you need to consider when determining the scope of your ISMS, these include but may not be limited to the context of your organisation, the requirements of interested parties, the size of your organisation, the locations it operates within, the budget you have available and if there is a deadline for completion.

I believe that if you have the resources and time available you should establish an ISMS that covers your entire organisation. However, if this is not possible, implementing an ISMS with a smaller scope can still be worthwhile, as it enables you to demonstrate business value in a limited budget and shorter timeframe. In addition to this, it provides you real-world experience of establishing and implementing an ISMS and enables you to learn and gain confidence before requesting additional funding to expand the scope.

Finally, when determining the scope of your ISMS you must consider the interfaces and dependencies that exist between the business capabilities, processes, services, products, information systems and/or physical locations you have decided are in-scope and those that are not, including any external dependencies. One of the easiest ways to determine the interfaces and dependencies is to hold a workshop with the relevant subject matter experts and create a Data Flow Diagram, in exactly the same way as you would if you were threat modelling. This will help you identify any interfaces and dependencies that may have been missed. If you discover additional interfaces and dependencies then you should carefully assess whether the scope should be expanded to include them.

Note: the scope of the ISMS is the only mandatory documentation required to conform with the requirements defined in section 4 Context of the organisation of ISO 27001:2013. However, I recommend that your scope clearly identifies the objective of the ISMS, your organisational context and the interested parties and their requirements for security.

4.4. information security management system

This section really doesn’t need any explanation or discussion as it simply states that the organisation will establish, implement, maintain and continually improve an ISMS in accordance with the requirements in the standard. The other sections of the standard set out what is required to achieve this.

In the next article in the series, we will look at the requirements for section 5 Leadership.