The stuff that keeps away the ghouls of bad decisions
Alternative ideas lists
If the task of creating the OEPs and RTPs has been performed comprehensively, the organisation should have identified all the sprites and controls that it needs to fulfil its mission and achieve its business objectives, but what if it has inadvertently missed something out? As such an omission could have serious consequences, it is prudent to ask the question at the time the OEPs and RTPs are developed.
A simple response to this question is to enquire what other organisations do. Rather than actually talk to lots of people, a convenient way to answer this new question is to use published material such as international standards, codes of practice, reference books and other sources of reputable information. A useful document can be regarded as a list of good ideas.
Statement of applicability
Take each idea in turn, and decide whether it applies to the organisation or not.
If it does not apply, record that fact and the reason for its non-applicability, lest circumstances should change in the future and that sprite or control becomes applicable.
If it does apply, also record that fact and justify its applicability by reference to at least one OEP or RTP. If this cannot be done, an omission has been detected. Policy, OEPs and RTPs can then be reworked as appropriate. This is why an AIL acts as a safety net. In either case it is also useful to include a summary of the sprites and of how the idea is implemented.
We refer to the source documents that may be used in this process as Alternative Ideas Lists, or AIL for short. We refer to the output documents as Statements of Applicability. Annex A of ISO/IEC 27001 is an example of an AIL and this standard requires the application of this IMS-Smart approach. Another example in the related field of IT is the IT Governance Institute’s CobiT (Control Objectives for IT) document. Section 7 of ISO 9001 is a third example.
An example of SOA entry is shown in the figure below and relates to ISO/IEC 27001.
Why it is called an AIL?
We call the source documents AILs because AIL is the French word for garlic and where we come from garlic is used to ward off evil spirits. In the context of internal control, evil spirits are the ghouls that haunt people when they have made an error of judgment.
ISO/IEC 27001:2022 Clauses 6.1.3 c), d) and Annex A
ISO/IEC 27001:2022 Clauses 6.1.3 b), c) and d) form a perfect example of an AIL. Clause 6.1.3:
Clause b) says “determine”. Clause c), the safety net clause, says “compare”. Clause d) documents the results of the comparison.
ISO/IEC Directives, Part 2, Clause 20.2 states “the status of the annex (informative or normative) shall be made clear by the way in which it is referred to in the text and shall be stated under the heading of the annex.” Since ISO/IEC 27001, Clause 6.1.3 c) says “… shall … compare … with those in Annex A”, Annex A must be accorded normative status. This is why ISO/IEC 27001 Annex A is normative. It does not mean that the controls in Annex A are requirements. The requirement is the comparison, Clause 6.1.3 c). Indeed, the introduction to Annex A says: “The information security controls listed in Table A.1 are directly derived from and aligned with those listed in ISO/IEC 27002:2022[1], Clauses 5 to 8, and shall be used in context with 6.1.3.” Here, the underlined text highlights the purpose of Annex A, being the reference source for the verification requirement in Clause 6.1.3 c) described above. This is reinforced by the note to Clause 6.1.3 b) which points out that “Organizations can design controls as required, or identify them from any source”. Thus, the controls in Annex A are not requirements.
.jpg)
you consent to that site setting authentication session cookies
