The dreaded Statement of Applicability (LONG)
a) select appropriate information security risk treatment options, taking account of the risk assessment results;
b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
NOTE Organizations can design controls as required, or identify them from any source.
This requirement clearly specifies the need to determine all the controls that the organisation deems necessary to mitigate unacceptable information risks. Note, however, that it doesn't actually demand they are fully implemented: see point d) below.
c) compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted;
NOTE 1 Annex A contains a comprehensive list of control objectives and controls. Users of this International Standard are directed to Annex A to ensure that no necessary controls are overlooked.
NOTE 2 Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and controls may be needed.
Annex A constitutes a generic suite of controls used as a reference, a completeness test or checklist forcing users to consider the full variety of information security controls in the annex. However, the two notes to point c) are somewhat contradictory: if Annex A is truly 'comprehensive', it cannot also be 'not exhaustive', and indeed there are other, unlisted controls that may be worthwhile in various circumstances.
d) produce a Statement of Applicability that contains:
- The necessary controls (see 6.1.3b) and c));
- justification for their inclusion;
- whether the controls are implemented or not; and
- the justification for excluding any of the Annex A controls.
Point d) is the only reference to the Statement of Applicability in ISO/IEC 27001:2013 - a very succinct specification for such an important document, hence the reason for this blog piece.
e) formulate an information security risk treatment plan; and
f) obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.
The Risk Treatment Plan is again very succinctly specified in the standard, with those two mentions plus two more in clauses 8.3 and 9.3.
ISO/IEC 27003:2017 provides helpful guidance, expanding on ISO/IEC 27001's rather curt requirements for the SoA and RTP with about two pages of explanation and advice including an example (concerning the risk of theft of a mobile phone) plus a reference to ISO/IEC 27005 and ISO 31000 for further information on risk treatment. I don't plan to quote and critique the two pages in detail here, although I do have some comments ...
Justification for including a control is its effect on modifying information security risk. A reference to information security risk assessment results and information security risk treatment plan should be sufficient, along with the information security risk modification expected by the implementation of necessary controls.
The second sentence is quite vague. What form should the 'reference' take? Would a general statement along the lines of "All the selected controls mitigate unacceptable information risks" be sufficient, or does it anticipate explicit linkages between the identified, unacceptable information risks, the corresponding controls, and the associated entries in the RTP?
Also, '27003 repeats the apparently contradictory description of Annex A being both 'comprehensive' and 'not exhaustive'. Given a vast array of possible controls (including myriad variants, permutations and combinations), it cannot possibly be totally exhaustive, so the word 'comprehensive' is misleading in that sense. The 2022 release of ISO/IEC 27001 is expected to remove the word 'comprehensive', rephrasing it:
Annex A contains a list of possible information security controls ...
ISO/IEC 27005:2018 does not even mention the SoA (!). The draft third edition of the standard, due to be published this September, has a section on producing an SoA, including the following pragmatic implementation guidance:
The SOA can easily be produced by examining the risk assessment to identify the necessary controls and risk treatment plan to identify those that are planned to be implemented. Only controls identified in the risk assessment can be included in the SOA. Controls cannot be added to the SOA independent of the risk assessment. There should be consistency between the controls necessary to realize selected risk treatment options and the SOA. The SOA can state that the justification for the inclusion of a control is the same for all controls and is that they have been identified in the risk assessment as necessary to treat one or more risks to an acceptable level. No further justification for the inclusion of a control is needed for any of the controls. The implementation status of all of the controls contained in the SOA can be stated as “implemented”, “partially implemented" or “not implemented”. This can be either individually against each control or as an overall statement.
EXAMPLE The SOA contains the statement: “All the controls have been implemented” No additional analysis or information is required to complete the SOA.
The SoA, then, is not so much an integral part of the information risk management process (as some claim) but an additional piece of supplementary evidence that can be produced after the information risks have been identified and evaluated, the risk treatments have been decided, and mitigating controls have been selected.
ISO/IEC 27007 says of the SoA:
The SOA should contain all necessary controls, i.e. the controls that the organization has, as a result of its risk treatment process [ISO/IEC 27001:2013, 6.1.3 c)], determined as being necessary for the modification of information security risk in order to meet its risk acceptance criteria ... In some cases, the organization uses a control that is a variation of an ISO/IEC 27001:2013, Annex A control and excludes the original Annex A, control, the rationale for exclusion being that it has been replaced by the organization’s variation of the control. Alternatively, the variation can incorporate the Annex A control and hence, it would not be excluded.
I believe that means if management determines the need to mitigate information risks using an ISO/IEC 27001 Annex A control (precisely as stated in the standard), then that control should be identified as 'applicable' in the SoA. If instead management decides to adopt a 'variation' to an Annex A control, it is unclear whether the Annex A control is supposed to be marked 'applicable' or not, but the variant control/s should be documented in the SoA. Likewise, if an Annex A control is to be supplemented by one or more additional controls, those additions should be documented in the SoA.
So, there we have 4 slightly different requirements/guidelines for the SoA in 4 ISO27k standards.
.ooOOOOOoo.
Stepping back for a moment, it's worth exploring why organisations are even required to do this. What is the real purpose of the SoA? Why bother?
Superficially, an SoA is required because ISO/IEC 27001 says so, and the certification auditors will want to see it. But why is that? Digging deeper ...
Certified/certifiable organisations generate and selectively disclose their SoA primarily to:
- Assure certain third parties (including the certification auditors) that they have explored their in-scope information risks in sufficient detail to identify the information security controls necessary to mitigate the unacceptable ones.
- Not neglected or overlooked entire categories of information risk and security controls (such as the physical security or joiners-movers-leavers HR controls that are important even in an organisation myopically obsessed with "cyber").
- Demonstrate their diligence, competence and conformity in respect of information risk management.
- Reassure third parties that, with management support, the organisation is committed to, and has invested in, proactively managing its in-scope information risks.
General managers of certified/certifiable organisations, plus risk and IT managers, internal auditors, ISMS management reviewers, owners and other interested parties, may use the SoA to:
- Orient themselves in this space with a reasonably succinct overview of the information security controls within the ISMS.
- Identify, explore and hopefully understand the rationale or reasoning behind the adoption or exclusion of various information security controls.
- Check that information risks which may impact their interests have been recognised and are being treated appropriately within the ISMS - if not, casting doubt on the adequacy and suitability of the ISMS and the competence/diligence of those involved, and suggesting the need for compensating controls (such as incident and business continuity management) in other areas.
Certification auditors use the SoA to:
- Confirm that the organisation has indeed produced one, in conformity with ISO/IEC 27001 (!).
- Confirm that the organisation has explicitly identified and evaluated its information risks, and has selected appropriate information security controls to mitigate unacceptable information risks, suggesting that they are operating the risk-driven approach required by the standard.
- Confirm that the organisation has not selected any other information security controls that do not address its information risks (although I'm not convinced that's a genuine issue, and even if it is, I feel it would be an internal business matter of concern to management).
- Confirm that the organisation clearly intends to mitigate its unacceptable information risks with specific controls, whether it has fully implemented those controls at the time of the audit or not.
- Select a sample of the applicable, allegedly fully implemented information security controls that can be audited to prove that the ISMS is, in fact, operating correctly (i.e. it is not just a paper tiger).
- Confirm that the certified organisation is reasonably diligent and competent in its management of information risks (at least, those within the scope of the ISMS).
- Confirm that the certified organisation's management are patently aware of information risks that may affect the third parties, and ideally have fully implemented the anticipated information security controls.
- Claim due diligence in relying on the certified organisation's assertions confirmed by the certification audtors, thereby denying liability if information risks eventuate to cause incidents affecting third parties.