SoA without fear and unnecessary bureaucracy: how to make Annex A a working tool

The Statement of Applicability often scares people even before they read the first line. Some perceive it as a formality “for the auditor,” others as an endless Excel spreadsheet with checkboxes. In reality, SoA ISO 27001 is not a magical document or a budget trap. It is a logical map of decisions: what exactly the company protects, why it chooses specific controls, and why it consciously rejects others. If you approach it humanely, Annex A ceases to be a pain.

Why SoA is not a checklist and what it really is

SoA is not a list of “yes/no” checkboxes, but a summary of the company’s decisions regarding risk management in ISMS: it shows which ISO 27001 Annex A controls are applied, which are deliberately excluded, why this decision was made, and at what stage implementation is at, with clear references to real policies and processes, rather than abstract wording from the standard.

How to choose controls and not inflate the scope of work

It is worth starting not with ISO 27001 Annex, but with real business processes. Controls should enhance the company’s work, not create new complications. So, here is a sequence that will help you choose the right controls for your work:

1. First, identify the key processes and risks that are truly relevant to them.
2. Choose ISO 27001 Annex A controls only where they directly reduce a specific risk.
3. Avoid strong dependencies between controls so that one does not drag along a dozen others.
4. Record simple selection and exclusion logic without unnecessary technical details.

This approach maintains focus and control over the scope of work. As a result, the SoA remains a manageable document rather than an endless list of obligations.

A practical approach adopted by auditors

Auditors view the SoA as a logical history of decisions rather than a formal file. It is important for them that the ISO 27001 SoA clearly reflects the relationship between risks and the selected measures from ISO 27001 Annex. For example:

1. Each control must be linked to a specific risk, not to an abstract requirement of the standard.
2. Each exception must have a clear and concise justification.
3. The status of control implementation should reflect actual practice, not plans for the future.
4. References in the SoA should lead to live processes, not formal documents.

This approach eliminates unnecessary questions before the audit even begins. As a result, the SoA is perceived as a working tool, and ISO 27001 Annex as a framework, rather than a source of unnecessary bureaucracy.