Nothing is More Critical Than an ISO 27001 Statement of Applicability

When it comes to all the different documents, scopes, procedures, and implementations that are required for your ISO 27001 certification, none are more important than your statement of applicability. In fact, most companies downplay the importance of the statement, much to their detriment, thinking that it’s a duplication of their efforts in previous steps and documents, but this is not so. It’s far more than that. Technically, to be fair, all of the steps in the audit and certification process are equally important, but this step of defining the applicability of your choice in security controls is the connective process between planning and implementation. 

Your Statement of Applicability (SoA, for short) is the critical document that defines how you will implement a large portion of your information security plan. As the main link between the risk assessment methodology & treatment plan that you’ve already defined and the actual implementation of your information security, your SoA defines which controls from the ISO Annex A suits your ISMS.

How Does Your Statement of Applicability Fit in?

As a refresher, the purpose of going through the key steps of getting your ISO 27001 certification is to ensure that you’re protecting 3 key touch points about the information in your possession. They are:

• Ensuring the Confidentiality of information so that only authorized persons can have access rights to the data.
• Ensuring the Integrity of the information so that only authorized persons can change any data.
• Ensuring the Availability of information so that it remains accessible to the authorized persons whenever they need it. 

By the time you’ve defined the scope of your ISO project, established an ISMS policy, a security policy, and sorted out your risk assessments and risk treatments, you’re technically ready to clearly outline your plan by:

• Listing and defining all the controls from Annex A that are applicable.
• Outlining the reasons why you’ve chosen these specific controls.
• Defining the objectives to be achieved with the controls.
• Giving a description of how these controls are to be implemented in your organisation.

If you’ve been keeping up with the previous blogs we’ve shared regarding your ISO 27001 certification, then none of this should be new information.

But something that hasn’t been explored in previous blogs is that while the controls listed in Annex A seem to be fairly comprehensive, they’re not exhaustive by any means. Hence, you may need to consider other sources for controls as well. Which is where breaking down the importance of this statement comes into play.

Why You Need Your SoA

Given that you’ve already developed your mandatory Risk Assessment Report, which outlines which controls you’ll be utilizing moving forward to mitigate said risks, why is this document even necessary? It’s necessary, because being ISO certified is more than just about being protected from and prepared for risk. Your ISO certification should be a holistic plan for not only protection, but for compliance and governance, accounting for every facet of your organization’s ISMS, from endpoint to endpoint. There are also several other key reasons why you need your SoA: 

• On one hand, your risk treatment aims to outline the controls that are necessary to decrease any risks you’ve identified. The SoA also identities the controls that are required for other reasons - such as legal reasons, contractual requirements, other processes, etc…
• Secondly, the SoA justifies the inclusion and exclusion of your chosen controls from Annex A, and the inclusion of controls from other sources as you see fit. The linear relationship between your list controls and the reasons for choosing them, makes this statement a practical checklist for operational use.
• Thirdly, your Risk Assessment Report could be a hefty document, filled with a few thousand or so risks that your organization has identified, if not more. This makes the document less than ideal for everyday operational use. The SoA, on the other hand, is meant to be short. It has a row for each of the 114 controls from Annex A, as well as a row for any other external inclusions. This makes it more manageable to present to management and update it regularly.
• Finally, and most importantly, the SoA must document whether each applicable control has been implemented or not. A good practice would be to describe how each applicable control has been implemented. This could be via a reference to a specific document that outlines the policy, procedure, or working instruction, or by shortly describing the procedure in use, or outline which equipment is used. Auditors will be looking for this.

When it comes time for your certification audit, the auditor will take your SoA and walk around the company to ensure that you’ve implemented the controls the way that was described in your SoA. This is their key guiding document during their on-site audit.

An additional key consideration is that if you develop the time to generate a thorough Statement, it could decrease the number of other documents. For example, if you want to document a certain control, but the description of the procedure for that control is relatively short, it can live in your SoA, rather than in a separate document. 

How This Helps Your ISO Certification Audit

Consider this document an exercise in putting together an action plan that has real world connections. It’s one thing to generate volumes of documents on what the potential risks and dangers are, and how your organization can mitigate those risks and protect the sensitive data. But that’s just an exercise in hypotheticals. It needs real-world practically. Your SoA takes those esoteric ideas and puts them into tangible actions, procedures, and accountabilities. 

Hence, when putting this together, you’ll find that you’ll spend more time on implementing your ISMS according to ISO 27001 and writing this document, than you’ll anticipate. Once you’re going down the list of applicable controls, you need to actually think about how you will put it into practice. For example:

• Will you need new equipment?
• Change long-standing procedures and protocols?
• Re-evaluate your remote working policy?
• Will you need to hire more trained staff, or reduce your workforce?
• Will you have to crack down on who has god-mode privileges in your IT department?
  
  

These are important and potentially expensive decisions that must be made. This is why it takes a long time to reach a definitive decision. The good element is that your SoA forces you and your organization to do this job in a systematic way, thus ensuring that all the conditions and controls are addressed, and nothing is missed.

Therefore, this isn’t one of those documents you need to generate just to make the auditor happy, and mark it off on your ISO 27001 checklist. This is a practical exercise that has real world implications. By defining what you want to do with your organization’s information security, and how you’ll do it, you’ll walk away with the perfect overview of your information security procedures - a detailed document that lists what controls you’re adhering to, a justification for your choice of controls, and a description of how it’s being done. 

By answering the basic questions of what, why, and how, you’re boosting your organization's information security capacity, and overcoming the largest hurdle in your ISO 27110 audit.