How to write a Statement of Applicability

A Statement of Applicability (SoA) is built from your risk treatment, not from a template. List every control your treatments need, check the list against all of Annex A, give each included control a reason and each excluded one a fact an auditor can check, record whether each is implemented today, then version and approve it.

When you need this

ISO 27001:2022 6.1.3 b) has you determine every control your risk treatment needs, from any source, and 6.1.3 c) has you compare that list with Annex A so nothing necessary is missed. ISO 27001:2022 6.1.3 d) then requires the SoA: the necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A control. ISO 42001:2023 6.1.3 asks for the same document against its own Annex A of AI controls.

You write the first version once your risk treatment plan is drafted, before a stage 1 audit. You revise it after every risk reassessment, a change of scope, a new customer contract, or an audit finding. The security lead usually writes it; risk owners and top management approve it.

This is guidance to help you understand the requirement, not legal advice.

Before you start

Have the risk register and treatment plan, your scope statement, the contracts and laws that impose security requirements, and a list of the 93 Annex A controls of the 2022 edition with their titles. Know which services your suppliers run for you, and what assurance you hold for each.

A first SoA for a firm of 20 to 50 people takes two to three days: a day to work through Annex A, a day on justifications and statuses, and a review with the approver. Later revisions take an hour or two.

Steps

Start from the approved risk treatment plan. List every control each treatment needs, wherever it comes from. Done when every control carries at least one risk identifier.
Compare the list with all 93 Annex A controls. Add any necessary control the treatment missed, with the risk it addresses. Done when every Annex A control is marked applicable or excluded.
Add controls from outside Annex A as rows of their own, such as a control a customer contract imposes. Done when every contractual and legal security requirement maps to a row.
Write the inclusion justification for each applicable control: the risk identifier, contract clause or law behind it. Done when no inclusion reads only “applicable”.
Write the exclusion justification for each excluded control, based on scope or on risk. Done when every exclusion names a fact an auditor can check on site.
Record each decision. In Sted, open Summary, select Decide on the control’s row, choose a reason in Exclusion, write the Justification, choose an Implementation status and select Save. Done when every control shows a decision.

You can exclude a control with a coded reason and justification and record its implementation status.
An excluded control needs one of nine coded reasons, Other needs a written justification, and an excluded control counts as decided for audit readiness; a document’s controls cannot be decided while a newer draft of it is in progress.

Record the implementation status as it is on the day you write it. Done when every control marked implemented has evidence you could show tomorrow.
Trace both ways. Pick five risks and find their controls; pick five controls and find their risks. Done when every sample traces.
Version and approve the SoA. Give it a version number, an approval date and the approver’s name. Done when the approved version is the one you will show the auditor.
Tell your certification body when a new version changes a decision, and review the SoA at every risk reassessment and management review (ISO 27001:2022 8.2 and 9.3). Done when the next review date is set.

Exclusions that hold up

An exclusion holds when it rests on a fact about your scope or your risks that the auditor can verify. It fails when it rests on cost, effort or priority.

Reason	Example	Why it holds or fails
Scope fact	No software is developed in-house or commissioned; excludes 8.30	Holds: the auditor can check contracts and staff roles
Risk-based	Risk accepted by its owner after assessment, with the score	Holds if the register shows the assessment and the owner’s sign-off
Covered elsewhere	Met by another control, named	Holds if the named control really covers it
Provider runs it	“Outsourced” with no assurance on file	Fails: you still assure the provider’s part
Priority	“Not a priority for us in 2026”	Fails: priority belongs in the treatment plan, not the SoA

The fine print on “not applicable”

A reason must cover every control it is used for. “We do not write software” covers secure coding (ISO 27001:2022 Annex A 8.28) but not application security requirements (ISO 27001:2022 Annex A 8.26), which also apply when you buy or configure an application. Check each control’s scope before you reuse a reason.

What the auditor tests

The certification auditor reads the SoA first and uses it as the audit map. They sample applicable controls and ask for evidence; a control marked implemented with nothing behind it is a finding. They test exclusions against what they see: an excluded control that the business plainly needs is a nonconformity. They check that the version on file matches the version the certificate will reference, and that each change was approved.

Worked examples

ISO 27001, a recruitment agency that writes no code

Harbour Lane Recruitment has 30 staff, an office, and runs everything on bought software. Its SoA version 1.0, approved by the managing director on 12 May 2026, has 93 Annex A rows and one row of its own: a client contract requiring candidate data to be deleted within 30 days of a request. It excludes secure development life cycle (ISO 27001:2022 Annex A 8.25), secure coding, security testing in development (ISO 27001:2022 Annex A 8.29) and outsourced development (ISO 27001:2022 Annex A 8.30), each with the reason “no software developed in-house or commissioned; confirmed in supplier list and job descriptions”. It keeps 8.26, because it configures its applicant tracking system. Because it has an office, all 14 physical controls stay applicable, with the lease, the door access list and the visitor log as their evidence.

It also excluded the cloud services control (ISO 27001:2022 Annex A 5.23) as “handled by our providers”. At the stage 2 audit on 9 June 2026 the auditor raises a minor nonconformity: the agency’s candidate data lives in three cloud services and nobody reviews their assurance. The agency marks 5.23 applicable, links it to risk R-14 (a breach at the tracking system’s provider), sets the status to in progress with a review due by 31 July, approves version 1.1 on 23 June and sends it to the certification body.

In September the agency commissions a contractor to build a careers-site plug-in. The risk reassessment makes 8.30 applicable, and version 1.2 records why.

ISO 42001, the same steps for AI controls

ISO 42001:2023 6.1.3 follows the Harbour Lane example against ISO 42001’s own Annex A: an exclusion needs a scope or risk fact behind it, such as a role you do not play in the AI system’s life cycle.

Checklist

How Sted helps

Sted keeps a Statement of Applicability for each adopted standard with a control catalogue.
Only standards with a control catalogue get a Statement of Applicability card.
Each Statement of Applicability card on the Summary lists the standard’s controls by theme as Applicable, Excluded or Not addressed, with any exclusion reason, the implementation status and when each was last verified; below administrator it is marked as a partial view, and its PDF needs a paid plan.
Only administrators can export the SoA as a PDF, because only their view is complete.
Readiness counts four kinds of item per adopted standard (each linked document approved; its requirements for that standard adopted or excluded with a reason; at least one closed record per record template; each assigned person’s training completed), counts an item shared by two standards once overall, and reads 0% for a standard with nothing linked.

Sted does not decide which controls apply to you or certify the SoA. Your risk owners decide, and the certification auditor judges the result.

ISO 27001 Statement of Applicability: what clause 6.1.3 d) requires, and the common mistakes.
ISO 27001 risk assessment and treatment: the decisions the SoA records.
How to run a risk assessment: producing the treatment plan the SoA starts from.
Statement of Applicability: the term in one paragraph.
The Statement of Applicability in Sted: reading the card, deciding a control and exporting the PDF.

Frequently asked questions

What columns should an ISO 27001 SoA template have?

Six work well: the control and its title, applicable or excluded, the justification, the implementation status, the owner and where the evidence lives. Clause 6.1.3 d) requires four of those; owner and evidence are what make the auditor’s sampling quick. Put a version number and approval date at the top.

Can I exclude a whole Annex A theme?

Almost never. Even a fully remote company keeps physical controls that follow its laptops, such as equipment off site, storage media and secure disposal. Exclude control by control, each with a reason that covers that control.

Who should approve the Statement of Applicability?

Usually the ISMS owner or a member of top management. ISO 27001:2022 7.5.2 asks for documented information to be reviewed and approved, and the auditor will look for a name and date on each version.

Do I update the SoA after certification?

Yes, whenever a risk reassessment changes a treatment decision, and at least once a year at management review. Tell your certification body about significant changes, because the certificate usually refers to the SoA version it was issued against.