How to Write an ISO 27001 Statement of Applicability That Survives Audit

The Statement of Applicability is the document ISO/IEC 27001:2022 clause 6.1.3 d makes mandatory: it must contain the controls you have determined are necessary, the justification for including each one, whether each is implemented, and the justification for excluding any of the 93 controls in Annex A. You are not required to implement all 93; you are required to be able to explain, from your risk assessment, why each one is in or out. The failure that produces most SoA findings is a sequencing failure, not a drafting one: an SoA written before the risk assessment is finished has nothing for its justifications to trace back to, and an auditor finds that in minutes.

This guide builds the document column by column, then covers which exclusions auditors accept, which they challenge, and which they never take.

Key takeaways

• The SoA is mandatory documented information under clause 6.1.3 d, and it is the artifact Stage 1 auditors reach for first.
• All 93 Annex A controls appear in it. Applicability is a decision you record, not a filter that removes rows.
• Every justification has to trace to a risk-assessment entry or to a legal, regulatory or contractual requirement. Boilerplate that could apply to any company is the tell.
• Annex A:2022 organizes the controls into four themes: 37 organizational, 8 people, 14 physical, 34 technological, numbered A.5.1 through A.8.34.
• Do the risk assessment first. An SoA drafted ahead of it is the most common structural finding in the whole document set.

What the standard actually requires

Strip away template marketing and clause 6.1.3 asks for four things in the SoA. The necessary controls, meaning the ones your risk treatment determined you need. The justification for including each of them. Whether each is implemented or not. And the justification for excluding any Annex A control you left out.

Two things follow from that wording, and both are commonly missed.

First, Annex A is a reference set, not the source of your controls. Clause 6.1.3 has you determine the controls necessary to implement your chosen risk treatment options, and then compare that set against Annex A to verify you have not overlooked anything. The direction of travel is risk to control, then a check against Annex A. Template-first SoAs invert this, which is why their justifications read like they were written by someone who had not seen the risk register.

Second, "whether each is implemented" is a status field with real consequences. An SoA that marks a control implemented when it is partially implemented is a documented statement that will be tested at Stage 2, and the auditor compares it to what they find. Under-claiming costs you nothing. Over-claiming turns a gap into a nonconformity against your own document.

The columns that survive an audit

A workable SoA has six columns. Anything beyond these is for your convenience, not the auditor's.

Control reference and title. All 93, A.5.1 through A.8.34, in order. Use the 2022 numbering. If your document still carries the 114 controls of the 2013 Annex A, that is a bigger problem than the SoA: the transition to ISO/IEC 27001:2022 closed on 31 October 2025 under the accreditation deadline, so as of August 2026 a 2013-structured ISMS is not certifiable.

Applicable: yes or no. A binary. Resist "partially".

Justification. The reason, tied to something. Good justifications name a risk register entry, a contractual obligation, or a regulation. Bad justifications restate the control title.

Implementation status. Implemented, partially implemented, or planned with a date. Partial and planned are legitimate at Stage 1 and awkward at Stage 2; be honest either way, because the auditor is going to look.

How it is implemented. One or two sentences naming the actual mechanism and, ideally, the document or system that carries it. "Access reviews performed quarterly per the Access Management Policy, evidenced in the ticketing system" is useful. "Controls are in place" is not.

Owner. A named role. Auditors ask who owns a control far more often than teams expect, and an unowned control is a control nobody will notice has stopped.

Which exclusions auditors accept

Exclusions are legitimate and the standard plainly contemplates them. The ones that go through unchallenged share a property: the reason is a fact about your organization, not a preference.

A fully cloud-hosted company with no owned facility can exclude several of the physical controls in the A.7 theme, because the physical perimeter it would secure does not exist and the relevant risk transfers to the cloud provider, which is then handled under the supplier controls in A.5. A company that does no software development can exclude the development-specific controls in A.8 on the same basis. A company with no operational technology, no bespoke hardware and no on-premises data center can exclude what genuinely does not apply.

Notice what makes these work. In each case the auditor can verify the underlying fact independently in about a minute, and the excluded risk has visibly gone somewhere else rather than nowhere.

Which exclusions they challenge, and which they never take

Challenged: anything where the fact is arguable. "We have no physical offices" from a company with a registered office and a room full of laptops. "We do not develop software" from a company that maintains scripts and infrastructure as code. "Remote working controls are not applicable" from a company with a distributed team. You may win these arguments, but you will have them, and each one costs audit time.

Never taken, in our experience of reviewing SoAs before certification audits, are exclusions of the controls that support the management system itself. Policies, roles and responsibilities, contact with authorities, information security in project management, the supplier controls, incident management, logging and monitoring, and business continuity. These are not excludable by scope, because they describe how you run the ISMS rather than a technology you might not own.

And a category that is not an exclusion at all: cost. "Not applicable because it is too expensive" is a risk acceptance, not an exclusion. Record it as an accepted risk with an owner and a review date, mark the control applicable and not yet implemented, and let it be visible. Auditors are reasonable about accepted risks that are documented and owned. They are unforgiving about risks disguised as scope decisions.

The sequencing failure, and how to avoid it

Here is the order that works, and it is not the order most templates imply.

Define the scope under clause 4.3. Identify risks under 6.1.2, with a documented methodology, named risk owners and a repeatable process. Decide treatment options under 6.1.3 a and determine the controls necessary to implement them under 6.1.3 b. Then compare that determined set against Annex A under 6.1.3 c to confirm nothing necessary was overlooked. Only then produce the SoA under 6.1.3 d.

Do it in that order and the justification column writes itself, because every entry already has a risk behind it. Do it backwards, starting from a 93-row template, and you will spend a week inventing reasons and an auditor will spend an hour finding the ones that do not hold.

There is a practical shortcut that is not a shortcut in disguise: while you are determining controls, record the risk register identifier next to each one. That single habit converts the hardest column in the SoA into a lookup.

Keeping it alive after certification

The SoA is not a project deliverable. It is a living document that has to be revisited when the risk assessment changes, when scope changes, when a control changes, and at your management review. Surveillance auditors compare this year's SoA to last year's and to what they observe, and an SoA that has not changed in two years while the company doubled in size is a signal in itself. Our piece on surveillance and recertification audits covers what years two and three actually look at.

When you do not need help with this

We write and review these documents, so treat this section accordingly. Two cases where you should do it yourself.

You have a security lead who knows your environment and can write. The SoA is not intellectually hard; it is tedious and it demands honesty about your own gaps. Someone internal who knows which controls actually run will produce a better document than an outside reviewer working from interviews, and they will own it afterward, which matters more than the first draft.

Your risk assessment is not finished. Hiring anyone to write an SoA before the risk assessment exists buys you a document with invented justifications, which is precisely the defect this article is about. Finish the risk assessment first, even if it takes another month. A consultancy that will write your SoA first is selling you a Stage 1 finding.

Where Top Floor fits

The two places outside help earns its cost are the risk-assessment methodology that makes justifications traceable, and an adversarial pre-audit read of the finished SoA against the risk register. Both sit in our ISO 27001 work, with the independent read closer to audit and assurance. If the underlying problem is that nobody owns this document quarter after quarter, that is a program-ownership problem rather than a drafting one, and compliance-as-a-service is the honest framing for it.

How to decide this week

1. Open your risk register and your SoA side by side. Pick five applicable controls and find the risk entry behind each. If fewer than four have one, stop and fix the sequencing before drafting anything.

2. Search the justification column for repeated sentences. Identical text across many rows is the boilerplate pattern auditors look for.

3. Reclassify every "not applicable because it is not worth it" as an accepted risk with an owner and a review date.

4. Confirm your control set uses the 2022 numbering, A.5.1 through A.8.34, and not the 2013 Annex A.

5. Give every applicable control a named owner role. Unowned controls are the ones that quietly stop.

Frequently asked questions

Do you have to implement all 93 ISO 27001 Annex A controls?

No. ISO/IEC 27001:2022 requires you to determine the controls necessary to implement your risk treatment, compare that set against Annex A so nothing necessary is overlooked, and then justify every inclusion and exclusion in the Statement of Applicability. Annex A is a reference catalogue, not a mandatory checklist. What is mandatory is that all 93 controls appear in the SoA with a decision recorded against each, and that the decision traces back to your risk assessment or to a legal, regulatory or contractual requirement.

What is the difference between the Statement of Applicability and the risk treatment plan?

They answer different questions and auditors expect both. The risk treatment plan is forward-looking and operational: which risks you are treating, how, who owns each action and by when. The Statement of Applicability is a control-by-control statement of position: for each Annex A control, whether it applies, why, and whether it is implemented. The SoA is derived from the risk treatment work; it does not replace it, and a project that produces only one of the two has a documented-information gap under clause 6.1.3.

Can you exclude physical security controls if you are fully remote?

Often yes, and it is one of the exclusions certification auditors accept most readily, because the fact is easy to verify. The condition is that the risk genuinely moved rather than disappeared: if your systems live with a cloud provider, the physical protection of those facilities is now a supplier-management question and has to be visibly handled by the supplier controls in your SoA. Blanket-excluding the whole physical theme while holding company laptops, or while a registered office holds equipment, is the version that gets challenged.

How often should the Statement of Applicability be updated?

Whenever the thing behind it moves: a change to the ISMS scope, a new or materially changed risk, a control that has been implemented or retired, or a new contractual or regulatory obligation. At minimum it should be reviewed as part of the management review under clause 9.3 and refreshed alongside the periodic risk assessment. Surveillance auditors compare the current SoA against the previous version and against what they observe, so a document that has not changed while the organization has is a question you will be asked to answer.