The Statement of Applicability (SOA) is an important document in ISO 27001. But it’s not just the auditor who would want to see the SOA. It can be asked for by any stakeholder who is looking at your ISMS (Information Security Management System), such as your clients or third-party companies you deal with.
What is the Statement of Applicability in ISO 27001?
The Statement of Applicability details the ISO 27001 security controls and policies you use in the organization to manage risks to confidential and sensitive information. These controls are benchmarked against the controls in ISO 27001 Annex A, which is a comprehensive list of 114 controls in 14 categories that need to be considered during ISO 27001 implementation. You can check the different categories here – What are the Annex A controls?
What are the mandatory elements of the SOA?
Not all companies need to consider the 114 controls as per the ISO 27001 Annex A. The SOA needs to document only the controls you use at the company. However, you still need to explain which controls are being used and why. The SOA is part of 6.1.3 of the requirements for ISO 27001.
Here’s what the SOA must contain.
- List of the security controls that the company will use to manage the identified security risks
- Justification for the security controls chosen
- Justification for the security controls that are not chosen
- Confirm which controls have been implemented
List of security controls outside the Annex A of ISO 27001 which will be used, if applicable (controls from sources such as ENISA guidelines, NIST publications, etc.)
The SOA will cover the company’s systems, processes, assets, users, products & services, and typically all channels of information exchange.
Why is the SOA important in ISO 27001?
The SOA is one of the core requirements of ISO 27001 compliance and is a mandatory requirement for ISO certification. In addition to the Scope and Risk Assessment Report, you need the SOA. Here’s why this document is necessary and important.
The Risk Assessment Report helps you identify the security risks. This in turn helps to decide which controls are needed to manage these risks. The SOA not only lists the controls as per the Risk Assessment Report but also includes controls that need to be used for reasons such as regulatory guidelines, laws, contractual requirements, mandatory processes, etc. Thus, the SOA is more comprehensive in terms of the use of security controls.
Since companies might sometimes need to use security controls outside of those listed in ISO 27001 Annex A, the SOA gives a more accurate view of the controls which are being/will be used by the company.
Since the Risk Assessment Report lists all potential risks, it is a rather long document with the list running into thousands of risks. The use of this document as a reference in day-to-day operations is not practical. On the other hand, the SOA is a shorter document. It is also quite handy to check controls since the format has each row dedicated to one control. It is easy to update, too, when new controls are added. Thus, the SOA can be conveniently used for reference by the management as well as the auditors.
The implementation status of each control is an important part of the SOA. It is one of the top things that the auditors will want to check. Also, with the SOA format, it becomes easy to reference the control in other document such as the security policy, technical manuals, etc. making it an extensive document.
What is the use of SOA during an ISO audit?
During an audit, the SOA is one document that the auditor will definitely ask for. Typically, the auditor will review the details of each risk and the security control listed against it. They will also check the implementation including the physical evidence of the implementation.
The SOA also serves as a checklist for the necessary security controls. It can help ascertain that all controls are in place to manage information security, thus preparing your company for an audit. The management and staff should be able to understand the controls listed in the SOA along with their use in risk management.
Having a well-written SOA can also decrease the number of other documents that would be required of you during an audit. For example, if the description of a certain control is short, it can be documented in the SOA and you won’t need to have a separate document for it. Additionally, a comprehensive SOA demonstrates that your company takes information security risks seriously.
Tips for writing the SOA
Many companies find that writing the SOA is time-consuming. This is somewhat true. Even though the document is not as long as a Risk Assessment Report, it is quite exhaustive. Thus, companies might find they are spending way too much time putting together the SOA.
Below are the tips for writing the SOA.
- Break down the process.
- You can break down the process of writing the SOA by delegating the task to a SPOC from each department to provide all necessary information for their department.
- Refer ISO 27002 or information about controls.
- While the ISO 27001 only has a line or two about each control, the ISO 27002 has more information. You can refer to this to come up with a detailed SOA.
- Bring together all previously written documents.
To ensure you are not missing out on any critical information, bring together all related documents such as the ISMS Scope, Risk Assessment Report, Inventory of Information Assets, Risk Treatment Plan, Policy documents, etc.
Even though time-consuming, writing an SOA is totally worth the time spent – both from the perspective of audit and information security goals. Writing the SOA also makes you approach information security in an organized, well-thought-out manner, which is beneficial in the long run. Read more about the ISO 27001 requirements in The Complete Guide to ISO 27001.
