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 should it include?
The SOA is required to include:
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 include.
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:2013, the introduction to Annex A says: “The control objectives and controls listed in Table A.1 are directly derived from and aligned with those listed in ISO/IEC 27002:2013, Clauses 5 to 18 and are to be used in context with Clause 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:2013, 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. Moreover, if there are no excluded Annex A controls, the SOA need not contain a single Annex A control. 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 excluded Annex A controls? Do not forget, of course, to include the justification 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 you necessary controls as Annex A controls, make sure that you implement them exactly as specified in Annex A. 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 rationale. 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 will the impact of the new edition of ISO/IEC 27002?
The new edition of ISO/IEC 27002 redefines the reference control set. However, it will not have any impact on current IMS certifications until:
These changes are not that many months away, perhaps less than a year. Nevertheless, when these conditions are met, the requirement will be to compare your necessary controls with the new reference set not the old.
Will I need to update my SOA?
The safest option will be to review your necessary controls against the new control set. Whist there is a mapping between the current Annex A controls and those in the new edition of ISO/IEC 27002, there are some new controls, the control specifications have been revised and the guidance has been updated. You may also wish to change the layout of your SOA. Bookmark this page for more information as more becomes available.
you consent to that site setting authentication session cookies
|© IMS-Smart Limited, 2021|
|Page last updated: May 1, 2021|