The dreaded Statement of Applicability (LONG)

















Subclause 6.1.3 of ISO/IEC 27001:2013 requires organisations to define and apply an information security risk treatment process to:
a) select appropriate information security risk treatment options, taking account of the risk assessment results;

The 'risk treatment options' (including the information security controls) must be 'appropriate' and must 'take account of ' (clearly relate to) the 'risk assessment results'. The organisation cannot adopt a generic suite of information security controls simply on the basis that they have been recommended or suggested by someone - not even if they are noted in Annex A.

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.
That first sentence implies that all the information security controls being managed through the ISMS must 'modify' (mitigate or maintain) information risks that are of concern and are unacceptable to the organisation. There is no justification for including other controls in the SoA that do not 'modify' such information risks: if they do not contribute directly to the ISMS objectives, they are irrelevant. Fair enough.

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).
Third parties such as customers and regulators use the SoA to:
  • 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.

Popular posts from this blog

Pragmatic ISMS implementation guide (FREE!)

Image
Early this morning ( very  early!) I remotely attended an ISO/IEC JTC 1/SC 27/WG 1 editing meeting in London discussing the planned revision of ISO/IEC 27003:2017 . Overall, the meeting was very productive in that we got through a  long  list of expert comments on the preliminary draft standard, debated the objectives of the project and the standard and reached consensus on most points. In summary: 27003 is to be revised to align with the current 2022 releases of ISO/IEC 27001 , 27002 and 27005 : These changes are  mostly  minor aside from the new section 6.3 on ISMS changes.
Read more

Two dozen information risks that ISO forgot

Image
Selecting the wrong controls - controls that are inappropriate, ineffective, too costly, impracticable, fragile, unnecessary, counterproductive or whatever, often as a result of blind faith in fads and fashions of the day and FOMO e.g. MFA, AI, cyber Failing to select the right controls - controls that are ideal for the particular situation, both now and in perpetuity, for whatever reason - mostly ignorance and prejudice Selecting and implementing controls at the wrong time or in the wrong way (where 'wrong' includes ineffective, inappropriate, sub-optimal e.g. bolting on controls rather than designing and building them in) Inept and inaccurate identification, analysis and quantification of risk, including reliance on p oor quality (incomplete, inaccurate, out of date, misleading, unreliable ...) information about actual risks, particularly subtle and emerging risks plus those involving deliberate concealment and misdirection e.g. fraud, misinformation, disinformation, propagan
Read more

Philosophical phriday - compliance risk

Image
According to a vendor's promotional video interview I saw recently, the 'cybersecurity compliance burden' has allegedly become so significant that [customer] organisations are eagerly buying [their] software tools and services to help them manage and fulfil their obligations. The vendor's argument goes that, instead of accumulating a ragtag bunch of policies and other controls relating to user Identification and Authentication (I&A), for instance, it makes sense to:  Identify all the cybersecurity-related laws, regulations and standards that apply to the organisation; Examine them for any security control requirements relating to, say, I&A; Rationalise the I&A controls down to the smallest set that satisfies all the requirements - the lowest common denominator; Design, implement, use, manage and maintain those I&A controls; Have the I&A controls checked or audited to gain assurance that the compliance requirements are met.  OK so far? Sounds reasonab
Read more

ISMS internal audit priorities

Image
A thread on the ISO27k Forum sparked my imagination over coffee this morning. Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan.  Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements. ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the stan
Read more

Reading between the lines of ISO27001 [L O N G]

Image
ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons: It is deliberately generic, being applicable to all manner of organisations regardless of difference in location/s, size, industry, maturity, structure, information risk and security status ... and so on. In effect, it specifies the lowest common denominator - the things that ALL organisations should be doing to manage their information security controls, as a minimum. The hurdle is set low enough that every organisation ought to find value in designing, implementing and operating an I nformation S ecurity M anagement S ystem as laid out in the standard. It is a certifiable standard, explicitly specifying the characteristics that every certified organisation's ISMS is expected to have. Again, it is a minimal specification with no concept of typical, average or maximum security: that is entirely down to the organisations themselves to determine, following the information risk management processes minimally de
Read more

Passionate dispassion

Image
Someone who is actively involved in, or is managing, an activity is patently not independent of it. They may well make a conscious, rational and determined effort to be objective, dispassionately reviewing evidence etc ., but their subconscious/emotional biases/prejudices and beliefs/value-systems will inevitably influence what they do. With the best will in the world, they will struggle to challenge and assess their past decisions and activities, especially if they were "certain" or "determined" or genuinely believed they were "doing the right thing". Furthermore, it is very hard for anyone to review the things they did not do, decisions they did not make or options they did not even consider. Mostly, they remain out of sight or out of the question.
Read more

45 ISO Management Systems Standards

Image
The ISO website  currently lists 45 published M anagement S ystems S tandards: 1. ISO 7101:2023 Healthcare organization management — Management systems for quality in healthcare organizations — Requirements 2. ISO 9001:2015 Quality management systems — Requirements 3. ISO 10012:2003 Measurement management systems — Requirements for measurement processes and measuring equipment 4. ISO 13485:2016 Medical devices — Quality management systems — Requirements for regulatory purposes 5. ISO 14001:2015 Environmental management systems — Requirements with guidance for use 6. ISO 14298:2021 Graphic technology — Management of security printing processes
Read more

Philosophical phriday - a noncompliance ramble

Image
In a previous philosophical phriday post , I moaned about vendors of security compliance support/management tools and services over-promising and under-delivering - an admittedly biased, even cynical opinion piece about the compliance imperative . A recent article in Corporate Compliance Insights notes that "CISOs are not just defenders against cyber threats but also champions of compliance and operational resilience". Hmmm, are CISOs 'compliance champs', really? Today, I'm discussing alternatives to being compliance-driven. How else can organisations drive their information risk, security and related concerns in a positive direction?
Read more

Adaptive SME security Crowdstrike special

Image
As if on cue, along comes a golden opportunity to consider what the Adaptive SME security  approach has to say regarding the Crowdstrike incident: That's not 20/20 hindsight but foresight: I've picked out the most relevant rows from the security controls table published in the guide 24 hours before the incident.  Although Crowdstrike primarily supplies much larger enterprises than SMEs, the incident could equally have afflicted other security software, or indeed operating systems such as Windows and assorted cloud apps commonly used by SMEs. Regardless of the details, it is a wake-up call, an opportunity to consider and respond to the information risks ... and to adapt , accordingly.
Read more