Home › Guides › Statement of Applicability

ISO 27001 Statement of Applicability: what goes in it, with an example

The Statement of Applicability (SoA) is the document auditors open first: every Annex A control, whether it applies, why, and how far it is implemented. This guide shows the required content, a filled-in example and the mistakes that cost findings.

See the example Statement of Applicability in Dazr

At a glance

  • Requirement: ISO/IEC 27001:2022, clause 6.1.3 d).
  • Scope: all 93 Annex A controls, in four themes.
  • Per control: applicable or not, justification, implementation status.
  • In Dazr: built from your controls, approved and exported as PDF, CSV or Excel (Pro).

On this page

  1. What is a Statement of Applicability?
  2. What goes in it
  3. Example: a 60-person SaaS company
  4. Common mistakes auditors note
  5. Building the SoA in Dazr
  6. Frequently asked questions

What is a Statement of Applicability?

Clause 6.1.3 d) of ISO/IEC 27001:2022 asks you to produce a Statement of Applicability that contains the necessary controls, the justification for including them, whether they are implemented, and the justification for excluding any Annex A control. It links your risk treatment to Annex A: every control you need follows from a risk, a legal or contractual requirement, or a business decision.

37Organisational controls (5.1 to 5.37)
8People controls (6.1 to 6.8)
14Physical controls (7.1 to 7.14)
34Technological controls (8.1 to 8.34)

What goes in it

  • Control: the Annex A number and title, for example 5.15 Access control.
  • Applicable: yes or no, for each of the 93 controls.
  • Justification: why it is included (risk, legal or contractual requirement, business need, good practice) or excluded (activity not performed, risk not present, outside the scope).
  • Implementation status: implemented, partially implemented, planned or not implemented.
  • Evidence and owner: where an auditor can see it working, and who answers for it.
  • Version and approval: date, version and who approved the SoA; an auditor checks it matches the current risk treatment plan.

Example: a 60-person SaaS company

A fully remote software company that hosts its product at an ISO 27001-certified cloud provider and develops in-house. Eight rows from its SoA:

5.1 Policies for information securityApplicable. Required by clause 5.2 and by customer contracts. Implemented: information security policy v4, approved by the board in March.
5.15 Access controlApplicable. Risk R-03 (unauthorised access to customer data). Implemented: access policy, quarterly access review.
5.23 Information security for use of cloud servicesApplicable. Business: the product runs on a public cloud. Partially implemented: exit plan still to be written.
6.3 Information security awareness, education and trainingApplicable. Legal: NIS2 Article 20 and customer requirements. Implemented: onboarding training and yearly refresher, attendance records.
7.4 Physical security monitoringExcluded. No own office or data centre; the hosting provider covers its sites (certificate on file). Not applicable; reviewed yearly.
8.13 Information backupApplicable. Risk R-07 (data loss). Implemented: daily backups, restore test every quarter.
8.24 Use of cryptographyApplicable. Risk R-03 and contractual encryption clause. Planned: key management procedure due in Q1.
8.25 Secure development life cycleApplicable. Business: in-house product development. Implemented: secure development policy, code review on every merge.

Common mistakes auditors note

  • Excluding a control without a reason, or with "not relevant" as the only reason.
  • An SoA that does not match the risk treatment plan, or still lists the 114 controls of ISO 27001:2013.
  • Status "implemented" without evidence an auditor can see.
  • No version, date or approval, so nobody knows which SoA is current.
  • Excluding a control the scope clearly needs, for example cloud security when everything runs in the cloud.

Building the SoA in Dazr

  • From your controls: every Annex A control in the ISO 27001 framework gets an applicable or excluded decision, with reasons and a justification.
  • Status from the work itself: implementation status, evidence and the review date come from the control, so the SoA stays current.
  • Filter and approve: filter on applicable or excluded, approve a version and see when the SoA changed after the last approval.
  • Export: PDF for the auditor, CSV or Excel to work on; the auditor can also read it in a read-only view.
  • Plan: the Statement of Applicability is part of Pro, €99 a month, with a 14-day free trial.

Dazr helps you build and evidence your SoA; it does not certify you. Certification is done by an accredited certification body.

Source: ISO/IEC 27001:2022, clause 6.1.3 and Annex A (93 controls). Last checked 19 October 2026.

Frequently asked questions

Do all 93 controls have to be in the SoA?

Yes. Every Annex A control has to appear, with a decision. Controls you exclude stay in the document with the reason for excluding them.

Can we exclude a control?

Yes, with a justification, for example because the activity is not performed, the risk does not exist or it is outside the scope. "Not relevant" alone is not a justification.

Is there an official template?

No. ISO/IEC 27001 prescribes the content, not a format. A table with control, applicability, justification, status and evidence is the usual form.

Does Dazr make us ISO 27001 certified?

No. Dazr keeps your controls, evidence and SoA in order for the audit; the certificate comes from an accredited certification body.

An SoA that matches your controls.

Start on Free with ISO 27001 for one user; the Statement of Applicability, policies and auditor access come with Pro, €99 a month.

Start free Pricing

This page contains general information. The binding text is the ISO/IEC 27001:2022 standard.