The Statement of Applicability (SoA) is one of the key documents that you will need to produce for your ISO 27001 information security management system (ISMS).
What is the Statement of Applicability?
The SoA is a crucial, mandatory report for ISO 27001 certification. It’s also an essential report for the management and control of your ISMS.
ISO/IEC 27001:2013 states that, as part of the risk assessment process, organisations must produce an SoA that contains:
- The necessary controls;
- Justifications for their inclusion;
- Whether the necessary controls have been implemented or not; and
- Justifications for excluding any of the Annex A controls.
ISO 27001 requires an ISMS to take into account and document your organisation’s legal, statutory, regulatory and contractual requirements for information security, and your approach to meeting them. The SoA will record the controls that you select to meet these requirements and whether they were implemented for reasons other than the risk assessment.
How to develop your Statement of Applicability
The process of developing the SoA can be mapped to five steps:
- Identify and analyse risks
You need to identify all the events that might compromise the confidentiality, integrity and/or availability of an asset that is within the scope of your ISMS. You also need to analyse how the risk might occur, which usually requires you to identify a vulnerability in your asset and a threat that might exploit that vulnerability.
- Select controls to treat risks
As part of your risk assessment you will need to mitigate the risks to reduce them to an agreed, acceptable level.
ISO 27001 suggests four ways to treat risks: retain (tolerate), avoid (terminate), share (transfer) or modify (treat). Modifying the risk means that you will apply security controls to reduce the impact and/or likelihood of that risk. These controls can be drawn from Annex A of ISO 27001, as well as those contained in other frameworks, such as the Payment Card Industry Data Security Standard (PCI DSS) or NIST SP 800-53.
- Plan your risk treatment
The risk treatment plan (RTP) needs to be produced as part of a certified ISO 27001 ISMS. This provides a summary of each of the identified risks, the responses that have been determined for each risk, the risk owners and the target date for applying the risk treatment.
Our free white paper 5 critical steps to successful ISO 27001 risk assessments looks at steps 1–3 in more detail and outlines the five key steps to a successful ISO 27001 risk assessment.
- Implement controls
Your SoA should set out a list of all controls recommended by Annex A, together with a statement of whether the control has been applied or not, along with a justification for its inclusion or exclusion. Implementing your selected controls can be a time-consuming task, depending on the gap between your organisation’s actual security level and your risk appetite.
- Maintain the SoA
ISO 27001 requires the organisation to continually review, update and improve the ISMS to make sure it is functioning effectively, and that it adjusts to the constantly changing threat environment.
Clause 8.2 in ISO 27001 states that risk assessments should be performed at planned intervals or when significant changes occur.
As part of this, you may find that your organisation reduces its risk appetite and plans to reduce the impact and likelihood of identified risks by identifying new controls. You will need to produce a new SoA each time your organisation carries out a risk assessment. However, the SoA should be maintained between risk assessments so that you have an accurate record of the controls you have selected and whether or not they have been implemented.
Produce an SoA with vsRisk
Fully aligned with ISO 27001, vsRisk streamlines the information risk assessment process and helps you produce consistent, robust and reliable risk assessments year after year.
vsRisk can generate six audit-ready reports, including the SoA and RTP. Export, edit and share these reports with ease across your organisation and with auditors.
This is a Security Bloggers Network syndicated blog post authored by Chloe Biscoe. Read the original post at: Vigilant Software Blog