What is the Statement of Applicability in ISO 27001?

October 15th, 2019 Posted in ISO Standards

What is the Statement of Applicability in ISO 27001?

The Statement of Applicability (SoA) is one of the mandatory documents that you will need to complete when implementing your ISO 27001 Information Security Management System (ISMS).  

It sits at the heart of your ISMS and identifies the ‘controls’ or risk mitigation safeguards that are applicable to risks you will have identified in your risk assessments. Most organisations use the 114 controls listed at Annex A to ISO 27001 to create their SOA.  

This isn’t mandatory (you can use other control frameworks), but we’d recommend Annex A.

It is comprehensive (the 114 controls break out across 14 categories), and you can supplement Annex A with other controls applicable to your organisation, including those suggested in codes of practice within the ISO 27001 family, including ISO 27017 (relating to cloud security) and ISO 27018 (relating to security of personal data in cloud environments). 

What should you include in a Statement of Applicability?

Assuming your SoA is based on Annex A, the starting point is to identify which controls are applicable to your organisation by reference to your risk assessment.  

None of the Annex A controls is mandatory. This is because security threats vary depending on a wide range of factors, such as the type and scale of data you store and with whom you share it or grant access, and whether you develop software or are office-based or work remotely.  

Your industry vertical dictates, to a certain degree, the type of security threat and the origin of the threat (the ‘threat actor’) that you are likely to be attacked by. 

Risk assessments are a critical requirement of ISO 27001. The standard doesn’t mandate how you carry out risk assessments and define your risk acceptance criteria but does provide guidance in ISO 27005. This is further expanded in ISO 31000, which is the internal standard for risk management. 

The 14 categories covered by Annex A and typically included in a SoA are: 

  • Information security policies 
  • Organisation of information security 
  • Human resources security 
  • Asset management
  • Access control
  • Cryptography 
  • Physical and environmental security 
  • Operations security
  • Communications security
  • System acquisition, development and maintenance
  • Supplier relationships
  • Incident management 
  • Business continuity management 
  • Compliance 

As you can see, the SoA covers far more than just IT security. This is because ISO 27001 is a standard for an information (not just IT) security management system. As a management system, the standard is focused on planning, implementing, reviewing and continually improving security management.  

How to create a Statement of Applicability (SoA)

Before you start, don’t think you can do this alone; put a team together covering all the relevant departments. These should be the same stakeholders who carried out the risk assessments ideally. 

Make sure you have the support of your senior management to ensure you have leadership commitment.  I say it time and again, but it doesn’t hurt to reiterate it here: if your execs are not on board with your ISO 27001 project, you are unlikely to be empowered with the resources and clout to push this through. You will also fail to meet a key requirement of the standard and your auditor is likely to identify this. 

First, as a team, conduct a risk assessment covering each of the likely security threats to your business. Create a master document which lists each of the 114 controls under the relevant categories, then systematically review each control and ask yourselves: 

  1. If the control applies or not to how your organisation operates. 
  2. If it does apply, what information will make it easier to identify the risk mitigation in place for that control? 
  3. If it doesn’t apply, what information must you include to justify excluding it? 

The third point above is as important as the first two, because even if you conclude that a threat has a low probability, you must document why you have come to that conclusion in the SoA.  

Remember, the auditor will use the SoA to carry out the audit. They will go through each control in turn and will want to see proof that what is written in the SoA is reflected in your working practices.   

We recommend that you reference your ‘Risk Treatment Plan’ for each identified risk in a column in the SoA, as it will quickly show that a risk has been identified and is being treated, and facilitate the audit process.  

We also recommend that you provide your team with motivational treats, starting with good-quality biscuits and posh coffee! This can be a laborious process, and anything you can do to keep your team motivated is endorsed by us – within reason of course! 

When to update the Statement of Applicability

I’m afraid to say an SoA is never complete. It’s a living document, and to keep it alive, it needs to be fed and watered. This is because the information security landscape is always evolving, and whether changes occur internally or externally, they must be updated in the SoA to ensure it reflects the current situation.  

So, should any circumstances change, such as the way you handle or store data, or if new threats emerge, the SoA must be updated to reflect these.  

Support with ISO 27001

Evalian supports organisations through every stage of ISO 27001, from gap analysis and implementation to support during certification and ongoing improvement. Get in touch to discuss your ISO requirements and take a confident, proportionate approach to information security.

 

 

Evalian Icon PNG

Written by Evalian