How to write your ISO 27001 statement of applicability (with gap analysis checklist!)

Modern ISO standards all have flexibility in common.

They recognise that individual context has a strong effect on the risks and opportunities your business faces, and how you deal with them.

ISO 27001 is no different.

You don't necessarily need to apply all 114 information security controls laid out in ISO 27001 Annex A - but you do need to explain which you are implementing, and why.

That's where your statement of applicability comes in.

Here's how to get started writing one.

What is a statement of applicability?

Your statement of applicability (SOA) is the bridge between your risk assessment and your risk treatment plan for your information security management system.

Applying all 114 Annex A controls could be unnecessary and expensive overkill for your business - so considering applicability is an important step to accreditation.

Your SOA is essentially a document summarising what information security means for your specific business context and set-up - and what you're going to do to manage your security accordingly.

In short your SOA, in tandem with your other key documents, should tell your auditor: 

Our business performs this service from this site(s) in this industry, with these information assets and these interested parties - so here are the policies and controls we're applying to protect our information security based on this context.

You'll need to make clear:

• What controls are necessary for your information security
• Whether you've implemented them or not (if not, you could be willing to tolerate the risk at its current level, or a control could be earmarked as a future improvement)
• Why each control is applicable or not

Your SOA is the overview document listing, justifying and describing what you'll be doing to secure your information, why you're doing it, and how you're doing it. So it needs to be done properly!

For a 27001 surveillance audit, your auditors will ask to see your statement of applicability, legislation register, manual and risk assessment as an absolute minimum (amongst other documents, procedures and policies!)

                                                                      - Kate Armitage, Compliance Director, Qualsys

Start by looking at the controls

The 14 categories of ISO 27001 controls in Annex A are as follows:

A.5 Information security policies
A.6 Organisation of information security
A.7 Human resource security
A.8 Asset management
A.9 Access control
A.10 Cryptography
A.11 Physical and environmental security
A.12 Operations security
A.13 Communications security
A.14 System acquisition, development, and maintenance
A.15 Supplier relationships
A.16 Information security incident management
A.17 Information security aspects of business continuity management
A.18 Compliance

These are useful outlines of the types of controls you'll be referencing in your SOA - but you'll need a more detailed overview of specific controls and how to apply them.

For that, the supplementary guidance in ISO 27002 is invaluable, so we recommend getting a copy along with ISO 27001 as you work through your SOA.

This process will allow you to start thinking of the tangible changes you're going to make for your information security management system. That could be hiring a new employee, changing a process, or investing in new hardware, for example.

Determine which controls are relevant to you

This is the heart of the statement of applicability, and it requires a thorough, top-down approach to determine:

1. Organisational scope and context

The size and make-up of your business operation and your information security management system.

Your scope statement is agreed with your auditor to briefly summarise your scope.

For example, Qualsys' is:

"The supply of IT consultancy services, development, configuration and supply of software, specialising in quality system support."

You may be based solely in the UK - but do you process data for individuals and organisations in the EU, US and beyond?

How does your industry affect the types of data you process, and how you process it?

Your applicable controls must be an accurate reflection of your operational scope.

2. Interested parties

Anyone with a stake or interest in how information is managed by your organisation.

Think about:

• Legislators
• Regulators
• Business leadership
• Customers
• Shareholders
• Industry bodies
• Employees
• External auditors

3. Resources & assets

The tools and resources your business uses each day.

A large organisation with a remote teleworking team using a variety of tools and systems will probably require more applicable controls than a small, office-based unit using a handful of resources.

Think about:

• Hardware and software systems
• Email
• Servers and data centres
• Paper filing and storage
• Mobiles

4. Issues and risks

What's the first thing people think of along with 'information security'?

Breaches. Data breaches and leaks make great headlines and should always be considered as you're thinking about which controls to apply for your information security management system.

But your auditor will want to see you've considered other aspects of your information risk as well.

'CIA' is a useful reminder here:

• Confidentiality
• Integrity
• Availability

Risks like losing some or all of a data set or confidentiality being violated can be just as serious as a potential breach, so keep that in mind.

ALCOA+ principles are a useful benchmark of data integrity which you could consider as you think about potential issues affecting your information system.

5. Legal and contractual requirements

Section A.18.11 within Annex A, "identification of applicable legislation and contractual requirements", will always be applicable to your business. 

Even if your customers have no specific contractual requirements from you regarding information security (which is unlikely, especially with larger organisations), there are still legal demands such as the GDPR which you will need to consider as you pick which controls to implement in your business.

Start your statement - but not on its own

You can't write your SOA in a vacuum. Your SOA should pull together and summarise all the other work you're doing as part of your ISO 27001 preparation.

By now, you should have identified the contextual 'picture' of your business: its scope, interested parties, applied resources and so on.

Your separate risk assessment report is where you document the risks which your business faces as a result.

As you analyse and evaluate those risks and move on to treating them, your work will naturally dovetail with your SOA as you think about the controls available to you and how you can apply them to minimise each risk to an acceptable level.

Top tips

1. Don't forget to document whether each applicable control is already implemented and applied in your business.

Linking from your SOA to a separate policy, work instruction or procedure detailing how the control has been applied is a good way to demonstrate to your auditor you've taken the necessary action.

2. You don't necessarily need to apply only the controls in Annex A.

If you can justifiably exclude a control from Annex A from your information security system and include an effective control from another source, go ahead.

3.  Stick to a simple structure

Your SOA should follow a 'control - adopted Y/N - justification - description' structure.

The SOA is designed to be a relatively concise summary document. You may have thousands of risks and a dozen legislative requirements sitting behind your controls, but they are detailed in your risk assessment report and legislation register, not your SOA.

Next steps

We put together a control-by-control gap analysis checklist template to help you with your ISO 27001 preparations.

Access it by downloading our toolkit below: