Statement of Applicability Blog

What is the Statement of Applicability in ISO 27001?

By Martin Frost - October 15th, 2019 Posted 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 are mandatory. This is because security threats vary depending on wide range of factors such as the type and scale of data you store and with whom you share it or grant access, also 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. For more on this topic, see our recent blog. 

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 onboard with your ISO 27001 project, you are unlikely to be empowered with the resource 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 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 motivation treatsstarting 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 if 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.  

Need help? 

If you are preparing for ISO 27001 accreditation and need advice and support on any of the documentation required, call us to find out how we can help    

ENQUIRE NOW