Statement of Applicability: ISO 27001 SoA Example

The Statement of Applicability (SoA) is the ISO 27001 document that lists all 93 Annex A controls and records, for each one, whether it applies to you, why, and whether it is implemented. It is required by clause 6.1.3(d), it is the first thing most certification auditors open, and it is the bridge between your risk assessment and the controls the auditor is about to test.

What is a Statement of Applicability in ISO 27001?

A Statement of Applicability is a controlled document that takes every control in Annex A of ISO/IEC 27001:2022, all 93 of them, and records four things per control: whether it is applicable, the justification for that decision, the implementation status, and a pointer to how it is implemented. Clause 6.1.3(d) makes it mandatory. No SoA, no certificate.

The reason it carries so much weight is structural. ISO 27001 does not tell you which controls to run. You scope an ISMS, assess risk, choose treatments, and then check your treatment plan against Annex A to catch anything you missed. The SoA is where that reasoning becomes visible to somebody else. An auditor reading it can see, in one document, what you decided and why, and can then go test whether reality matches.

That is also why a weak SoA is such a reliable predictor of a difficult Stage 2 audit. If the justifications are one word long, the auditor has no thread to follow and will start pulling on everything.

What must a Statement of Applicability contain?

Clause 6.1.3(d) asks for four elements, and everything else you add is your own choice:

• The necessary controls. Every control you determined is needed to treat your risks, whether or not it came from Annex A. Controls you designed yourself belong here too.
• Justification for inclusion. Why the control is needed. Usually a reference to the risk or the legal or contractual obligation that drives it.
• Implementation status. Whether the control is implemented, partially implemented, or planned with a date.
• Justification for exclusion. For every Annex A control you decided not to apply, the reason. This is the column auditors read most carefully.

In practice, most teams add a few more columns because they make the document usable rather than ceremonial: the control owner, the risk IDs it treats, the linked policy or procedure, the evidence location, and a last-reviewed date. Those are not required, but a SoA without an owner column tends to be a document nobody maintains.

Statement of Applicability example

Here is what a handful of rows look like for a 40-person SaaS company running on AWS, remote-first, with no office of its own. The point of the example is the shape of the justifications, not the specific decisions, which are yours to make.

Notice what the exclusions do. Each one names the reason, and where the risk still exists it points at the control that actually handles it. "Not applicable, remote company" on its own is the version that generates findings. The version above tells the auditor where to go look instead.

If you want the underlying reference while you build this, the full ISO 27001 controls list sets out all 93 Annex A controls by theme with what each one asks for.

How do you justify excluding a control?

A good exclusion justification answers one question: why does this control not reduce a risk you actually carry? There are only a few honest shapes that answer takes.

• The asset does not exist. No premises, so no perimeter to secure. No cabling, so no cabling to protect. No outsourced development, so nothing to oversee.
• The risk is treated elsewhere. The activity happens, but a different control covers it, and you name that control.
• A third party carries it, and you manage them. Physical controls at a cloud provider are the standard case. This one is only credible if your supplier controls (A.5.19 to A.5.22) are real, and the auditor will check.
• Risk accepted at an appropriate level. Legitimate, but the rarest and the most scrutinized. It needs a documented acceptance by someone with the authority to accept it.

What does not work: excluding a control because it is expensive, because you have not got to it yet, or because it is inconvenient. Those are not exclusions, they are unimplemented controls, and the honest entry is applicable with a status of planned and a date. Auditors see that distinction constantly and treat an honest gap far better than a dressed-up one.

How many controls can you exclude?

There is no limit in the standard, and no target you should be aiming at. A remote-first software company routinely excludes a good share of the physical theme, which is entirely defensible. A company with a warehouse and a server room excludes almost none. What matters is whether each individual justification holds, not the count.

Be wary of the opposite failure, which is more common than over-exclusion: marking everything applicable to look thorough. Now you have committed to implementing and evidencing 93 controls, and the auditor will sample the ones you quietly did nothing about. Claiming a control you do not run is worse than excluding one you do not need.

Who writes and approves the Statement of Applicability?

Whoever owns the ISMS writes it, which in a company of 5 to 200 people is usually a founder, a head of engineering, or an ops lead doing compliance alongside another job. Top management approves it, because clause 5.1 puts accountability for the ISMS on leadership and the SoA is where the risk decisions become commitments.

Treat the approval as a real control, not a formality. The SoA is a controlled document: it needs a version, an approval date, an approver, and a change history the auditor can follow. Plenty of small teams handle that by circulating the approved version for signature the same way they handle policy sign-off, and if you already send documents out for signature elsewhere in the business, the SoA belongs in the same routine rather than in an email thread nobody can find later.

When do you update the SoA?

Any time the answer to one of its four columns changes. In practice that means:

• After the risk assessment is revised, which for most companies is annually plus after any significant change.
• When scope changes: a new product, a new office, a new region, a new class of data.
• When a planned control goes live, so the status column stops lying.
• When a supplier relationship that carried an exclusion changes, for instance moving off a provider whose certification you leaned on.
• Ahead of every surveillance audit, because it is the document the auditor uses to plan what to sample.

The failure mode is not forgetting to update it. It is updating it in a separate spreadsheet that gradually stops matching the controls people actually run. Six months in, the SoA says a control is implemented, the control owner left in March, and nobody noticed. Generating the SoA from the live control set instead of maintaining it alongside one is the only version of this that holds up over a three-year certification cycle.

Is the Statement of Applicability the same as the risk treatment plan?

No, and auditors ask about the difference. The risk treatment plan says what you are going to do about each identified risk, who is doing it, and by when. The Statement of Applicability says which controls are in scope and why, with their status. The treatment plan is forward-looking and project-shaped; the SoA is a standing register of decisions.

They are tightly coupled, which is why the justification column usually cites risk IDs. Reading them together, an auditor should be able to trace: this risk, therefore this treatment, therefore this control, therefore this evidence. If that chain breaks anywhere, both documents lose credibility at once.

Do you need a SoA for SOC 2?

No. SOC 2 has no equivalent document. The AICPA Trust Services Criteria define outcomes and you design controls to meet them, with the system description written by management under the 2018 description criteria. There is no required artifact that enumerates a fixed control set and justifies exclusions, because there is no fixed control set to exclude from.

That difference catches teams doing both. Work carried over from SOC 2 still counts heavily toward ISO 27001, and the two compared side by side overlap substantially on access control, change management, logging and vendor management. What SOC 2 will not give you is the SoA itself or the management system layer behind it, both of which are ISO-specific work you have to do fresh. The mapping exercise between them is worth doing deliberately rather than ad hoc, which is what control mapping across frameworks covers.

Common mistakes that cost teams at Stage 2

• Copying somebody else's SoA. The justifications will not match your risks, and the auditor is reading the justifications.
• Blank or one-word exclusion reasons. "N/A" is not a justification. It reads as a decision nobody made.
• Status columns nobody maintains. Every "implemented" is a claim you will be asked to evidence.
• Listing 2013 controls. If your SoA has 114 controls in 14 domains, it is built on the withdrawn edition. ISO 27001:2013 stopped being certifiable when the transition period closed on 31 October 2025.
• Forgetting non-Annex A controls. Clause 6.1.3 asks for the necessary controls, not only the Annex A ones. Controls you designed yourself belong in the document.
• No version control. An undated, unapproved SoA is not a controlled document, and controlled documents are themselves a requirement.

Turning the SoA into something that stays true

The SoA is a snapshot of decisions, and snapshots go stale. What keeps it accurate is the layer underneath: every applicable control carrying a named owner, a review frequency, and the evidence that proves it ran. When those exist and are current, the SoA is a report you generate. When they do not, it is a document you rewrite in a panic before every audit.

That is the job control mapping software is built for: one control library, mapped once across SOC 2, ISO 27001, GDPR, HIPAA and PCI DSS, with evidence collected on a schedule from AWS, GitHub, Google Workspace and Okta, and a risk register the justifications can actually cite. Complies publishes its prices, from $79 a month, and you can connect your stack and see a readiness score the same day. If you are still deciding on tooling, the honest comparison is on the best ISO 27001 software, and the wider cost picture, including the certification body fees that sit outside any software budget, is in ISO 27001 certification cost.

The usual caveat stands: a complete SoA prepares you for certification, it does not deliver it. An accredited certification body runs Stage 1 and Stage 2 and decides what your certificate says. No document and no platform can promise that outcome.