The controls in ISO/IEC 27001, Annex A are not requirements
The statement of applicability
What is it?
The “statement of applicability” (SOA) is management system requirement only found in ISO/IEC 27001. In contrast to other management system standards, the SOA requirements (ISO/IEC 27001, Clauses 6.1.3 c) and d)) provide organisations with a common information security control framework, rather than specifying specific controls. In this way, ISO/IEC 27001 provides an elegant way to specify discipline-specific control requirements whilst providing organisations with the flexibility to determine precisely how they should manage their information security risks. The standard thus recognises that all organisations are different, and the best people to manage an organisation’s affairs is the responsibility of the organisation concerned, not ISO.
Why is it called “statement of applicability”?
British Standard (BS) BS 7799:1995, the forerunner of ISO/IEC 27002, was a Code of Practice for Information Security Management. In responding to a market demand for certification, it was recognised that not all BS7799 controls were applicable to all organisations. A new standard, BS 7799‑2:1998, was therefore created to act as bridge between the Code of Practice and certification. The BS 7799 control specifications were recast as requirements (should became shall) and included in BS 7799‑2:1998, Clause 3. Since some of these might not be applicable, BS 7799‑2 required organisations to select controls from Clause 3 and produce a “statement of applicability” (SOA) to record which ones applied, and which did not. Hence the term “statement of applicability” – a statement of all applicable controls.
Nevertheless, whilst the purpose of the SOA has changed over time, the name has not.
Table reproduced from “ISO/IEC 27001 — Mastering risk assessment and the statement of applicability” by kind permission of the author
What is it for?
ISO/IEC 27001, Clause 6.1.3 c) requires organisations to compare the controls they determined through the process of risk treatment with those in Annex A to confirm that no necessary control has been overlooked. This is an application of a general principle known as an Alternative Ideas List (AIL).
The benefits of this approach are:
Nevertheless, despite these qualities, if a necessary control has been overlooked, but that missing control is not in Annex A, the comparison process will not find it. This is a weakness of any AIL. It can be overcome by expanding the reference control set and by keeping the set up-to-date.
What is it not for?
The controls in ISO/IEC 27001 Annex A are not requirements. Neither is there any requirement in ISO/IEC 27001 to implement any information security controlJust open your copy of ISO/IEC 27001:2002 and search for “implemen”😮. The requirement (Clause 8.3) is to implement your risk treatment plan. This is your plan to modify information security risk so that the residual risk is acceptable. It is highly likely that this plan will require implementation of the controls that you determined as being necessary to implement your chosen information security risk treatment option(s) (Clause 6.1.3 b)). Conformance assessment therefore requires assessors to look for evidence that the risk treatment plan has been implemented. The SOA can help, but it should not be the focus of the assessor’s attention when looking for conformance to Clause 8.3. It is only relevant to Clause 6.1.3 d) and that has nothing to do with the implementation of information security controls.
What should it include?
The SOA is required to contain:
What should it look like?
ISO/IEC 27001 does not require the SOA to be laid out in any particular way. ISO/IEC 27001 only specifies what it is to contain.
Traditionally, organisations use the same structure as ISO/IEC 27001, Annex A. However, since necessary controls are determined through the process of risk treatment and are not selected from Annex A, necessary controls need not be Annex A controls. ISO/IEC 27003 (ISMS guidance), which explains the ISO/IEC 27001 requirements and offers guidance on their fulfilment, refers to necessary controls that are not in Annex A as custom controls. It also points out that custom controls can cause the exclusion of Annex A controls, and refers to such exclusions as obviated Annex A controls. Some organisations also use the concept of a variant, which, as explained in ISO/IEC 27007 is an Annex A-obviating custom control with a similar specification to the Annex A control which it obviates. This is a powerful concept and allows organisations to accurately specify their necessary controls.
It is important to understand that the controls in ISO/IEC 27001, Annex A are not requirements.
The controls in ISO/IEC 27001, Annex A are not requirements.
The requirement (ISO/IEC 27001, Clause 6.1.3 c)) is that organisation “… shall … compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted”.
ISO/IEC Directives, Part 2, Clause 20.2 states that “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. If the ISO/IEC 27001 requirement had been to “… compare with a reference list of controls, such as those listed in Annex A”, then ISO/IEC 27001, Annex A would have been an informative annex.
In ISO/IEC 27001:2022, 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, 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.
2 Corollary 1
The SOA requirement is for documented information that contains “the necessary controls (see 6.1.3 b) and c))”, i.e. those determined through the process of risk treatment.
As implied by the note to ISO/IEC 27001, Clause 6.1.3 b): “organisations can design controls as required, or identify them from any source”; the necessary controls that are determined by an organisation need not have the same names or specifications as Annex A controls.
ISO/IEC 27003:2017 (page 17) introduces the concepts of a custom control (i.e., “a control not included in ISO/IEC 27001, Annex A.”) and obviated controls (i.e., an Annex A control that is excluded because of the presence of a custom control).
A variation, as explained in ISO/IEC 27007 is a custom control with a similar purpose to the Annex A control that it obviates. The specification of such custom control is a variation of the Annex A control specification.
Thus, in principle, if the mapping between necessary controls and Annex A controls (ISO/IEC 27001, Clause 6.1.3 c)) concludes that “no necessary controls have been omitted”, the SOA will not contain a single Annex A control; all necessary controls being custom controls and there being no excluded Annex A controls. In general, however, a SOA can be a mix of custom controls, variations, necessary Annex A controls and excluded Annex A controls; the reason for exclusion being obviated controls and nonapplicable controls.
3 Corollary 2
There is no requirement for the layout of the SOA. ISO/IEC 27001, Clause 6.1.3 d) only specifies what it shall contain. Thus, the Annex A control headings do not have to be used.
4 Implications for certification auditors
ISO/IEC 27006:2015 (Clause D.1) states: “The implementation of controls that were determined as necessary by the client for the ISMS (as per the Statement of Applicability) shall be reviewed …”. Thus, the drawing up of audit plans using the headings of ISO/IEC 27001, Annex A is a useful starting point, but audit plans should be based on the content of the SOA. Moreover, failure to audit custom controls could lull the organisation into a false sense of security and renders the Certification Body nonconformant with ISO/IEC 27006.
The requirement is the comparison specified in ISO/IEC 27001, Clause 6.1.3 c). Thus, all necessary controls could be custom controls. This means that the SOA need not contain a single Annex A control (even if there are excluded Annex A controls, the SOA does not need to contain the control, only the justification for exclusion). Since one is not obliged to use the structure of Annex A, why not simply list all the necessary controls (as Annex A variants and pure custom controls) followed by the justification for the excluded Annex A controls? Do not forget, of course, to include the justification for inclusion and implementation status, and, if you do use this approach, it is prudent to include the mapping of your necessary controls to Annex A controls are evidence of your conformance to ISO/IEC 27001, Clause 6.1.3 c).
How should it be produced?
Organisations are not required to produce their SOA in any particular way, although the Internet is full of guidance on how it can be done. Be careful, though. If you specify your necessary controls using the Annex A control text, make sure that you implement them exactly as you specify them. The Annex A controls are not requirements, but the necessary controls as specified in your SOA are — they are organisational requirements, and if you do not do what you say you do, you have only yourself to blame if a certification auditor gives you a nonconformity. This where the power of variants comes in handy: compare what you do with each Annex A control in turn. Write down what you do in the SOA and declare it as a variant, mapped to the Annex A control that you were using for the comparison. Then deal with unused Annex A controls. Are they excluded? In which case write down your justification. If not, rework your risk treatment plan, and start over. Continue until you have disposed of all the Annex A controls.
For some controls, their Annex A specifications do not capture the full nuances of the control guidance in their ISO/IEC 27002 counterparts. In such cases, it is worth studying the ISO/IEC 27002 guidance and using that information to supplement your decision making process.
What is the impact of the new edition of ISO/IEC 27001?
The controls in Annex A of the new edition of ISO/IEC 27001 are aligned with those in ISO/IEC 27002:2022. The previous edition of ISO/IEC 27001 has been withdrawn and the transition period for organisations that have been certified by an accredited certifcation body has started. The major transition activity will be for organisations to compare their necessary controls with the new reference Annex A controls.
Will I need to update my SOA?
Most likely, the answer will be yes, but if in recomparing your necessary controls with those in Annex A 2022 you find missing necessary controls, you will have to do far more than update your SOA. You will need to rework your risk assessment and risk treatment plans to include the new controls, and implement them. This is why the transition period for this organisations will be three years. Nevertheless, since the recomparision exercise can reveal exposure to unacceptable information security risks, the advice is to start sooner rather than later. Do not put off this important task.
When you update your SOA, you may also wish to change its layout to demonstrate that you understand that the controls in ISO/IEC 27001 Annex are not requirements and that the SOA is not a conformance matrix. Bookmark this page for more information as more becomes available.
you consent to that site setting authentication session cookies
|© IMS-Smart Limited, 2023|
|Page last updated: August 24, 2023|