Building an Effective Statement of Applicability (SoA)

Clause 6.1.3 of ISO 27001 states that ‘the organisation shall define an information security risk treatment process to:

b) determine all the controls that are necessary to implement the information security risk treatment option(s) chosen;

c) compare the controls determined in 6.1.3b with those in Annex A and verify that no necessary controls have been omitted;

d) produce a Statement of Applicability that contains;

- the necessary controls determined in 6.1.3b &c

- justification for their inclusion;

- whether the necessary controls are implemented or not;

- the justification for excluding any of the Annex A controls’.

So, how do you create an SoA that meets these requirements while also adding value to the organisation and its information security management system (ISMS)?

Most of the SoAs we encounter are maintained in spreadsheets.  In our experience, this is usually a practical approach because the organisation needs to record information against all 93 Annex A controls.  A spreadsheet also provides the flexibility required to review and refine the SoA as the ISMS evolves.  The tool itself, however, is less important than the quality of the decisions and explanations it records.

‍

We have noted several core components of an effective SoA that can form the column headings used in the document.

Control number

Reference number for the control.

Control title

The title of the control.

Control description

The description of the control as set out in Annex A of the Standard.

Implementation status

Indicates whether the control is fully implemented, partially implemented or not implemented.  The concept of partial implementation is particularly important, as many Annex A controls comprise multiple requirements rather than a single activity.  For example, Control 8.13 (Backups) requires that backups are maintained and regularly tested in line with a subject-specific policy.  We have often encountered situations where an organisation may have approved a backup policy and implemented backups but may not yet have established or completed regular restoration testing.  Recording the control as partially implemented makes that position transparent and allows the remaining action to be managed.

Selected yes/no

Shows whether the control has been selected.

Justification  

This column is important because it records the rationale for including or excluding a control, which should be driven by your risk treatment plan.  For example, a control may be required to meet a legal, regulatory or contractual obligation.  Where this is the case, it is useful to reference the specific legislation, regulation or contractual obligation, as this allows readers to refer to the underlying requirement if further detail is needed.

Meanwhile, if a control has been deemed not applicable, this should be clearly justified.  For example, you may classify Control 8.30 (Outsourced development) as not applicable if all development activities are carried out in-house and no third parties are involved. Documenting the reasoning in the SoA makes it clear that the control has been considered as part of the risk treatment process and intentionally excluded, reducing the likelihood of challenges or nonconformities during an audit.

A useful test is to ask whether someone who was not involved in creating the SoA could understand why the control was included or excluded.  If the answer is no, the justification probably needs more context.

Supporting documentation

Although this column is not required by the Standard, we recommend including it as a matter of good practice.  A supporting documentation column links the control directly to internal policies, technical configurations, or operational procedures, demonstrating your organisation’s documented intent to manage the relevant control.  You can then support this by indicating how the control can be evidenced during an internal or external ISO 27001 audit, such as by linking to associated records or referencing the system where the evidence can be obtained.

‍

One of the most common weaknesses we encounter is a control being included or excluded without a clear connection to the organisation’s risk assessment and risk treatment process.  A reader should be able to understand why a control was selected, such as the particular risk it helps to treat, or why it was excluded, such as the relevant activity not being performed by the organisation.

Another common issue is treating the SoA as a one-off certification document.  We recommend reviewing it at least annually and whenever a material change affects the ISMS.  This might include the introduction of a new technology, a significant change to services or suppliers, an acquisition, or a change to legal or contractual obligations.

We have also seen SoAs become dependent on the knowledge of one individual.  An effective SoA should instead reflect input from relevant stakeholders across information technology, legal, human resources and senior management.  This helps ensure that the document reflects how controls actually operate across the organisation.

Finally, avoid generic explanations such as ‘not applicable’.  For example, if your organisation excludes a physical access control because it operates entirely remotely and has no corporate office, record that context.  A specific explanation demonstrates that the control was consciously considered rather than overlooked.

As demonstrated above, Clause 6.1.3 of ISO 27001 makes clear that the information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.  Some organisations we work with choose to go beyond the requirements of ISO 27001 by implementing more advanced controls than the 93 listed in Annex A.  

It is also important to remember that ISO 27001 is only updated periodically, while threats, technologies and business practices can change much more rapidly.  In practice, organisations sometimes need controls that reflect emerging technologies, sector-specific risks or contractual requirements that are not expressly described in Annex A.  The SoA provides a useful place to record those controls, explain why they are needed and identify the supporting evidence.

1. Keep exclusion justifications proportionate.  They should contain enough detail to demonstrate that the control was properly considered, but they do not need to become lengthy essays.  The person responsible for presenting the SoA should understand the rationale and be able to support it with evidence.
2. Where a control has been included following a risk assessment, link it to the relevant entry in the risk register or other risk assessment record.  Avoid relying solely on a generic phrase such as “result of risk assessment”.
3. When changing the SoA, check the certification body’s notification requirements. If your organisation’s ISO 27001 certificate refers to a particular SoA version, confirm whether the certificate or associated records also need to be updated.