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.

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:

• Every organisation that has an ISO/IEC 27001 conformant ISMS will have compared their necessary controls to those in the same reference set.
• The SOA acts as a comprehensive catalogue of an organisation’s information security controls.
• The ISO/IEC 27001 Annex A reference set is a robust mix of organisational, people, physical and technological controls.
• ISO/IEC 27002 gives guidance and supporting information for each reference control.
• The controls and guidance in this reference set are drawn from generally accepted good information security practice.
• ISO/IEC 27001 Annex A and ISO/IEC 27002 provide a common language that is recognised internationally.
• For organisations new to information security, the controls in this reference provide a good starting point.

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:

• the necessary controls;
• justification for their inclusion;
• whether the necessary controls are implemented or not; and
• the justification for any excluded Annex A controls.

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.

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.