The ISO 27001 Statement of Applicability

An SoA is a register, not a policy. Nothing in it is prose you have to phrase well - it is 93 decisions, each with a reason, each pointing at the document that carries it. These are the 11 parts it has to have, and what an auditor is actually checking in each.

11

sections the document needs

3

wordings people reliably get wrong

7

things an auditor asks to see

7

ways it usually fails

1. 1

   Document control and approval

   What it must contain

   Document reference, version, owner, effective date and next review, plus who approved this version and when.

   What the auditor checks

   That the copy in front of them is the current, approved one. An SoA circulating as an undated spreadsheet cannot be shown to be the version the decisions were made against.

2. 2

   Scope statement, or a reference to it

   What it must contain

   The boundary the applicability decisions were made inside - the same scope your certificate will carry, not a restatement of it.

   What the auditor checks

   That your exclusions follow from the scope. Almost every defensible exclusion traces back to a boundary: no data centre, no in-house development, no cardholder data.

   Scope: the design, hosting and support of the [product] platform and the corporate systems supporting it, delivered from [location] and cloud infrastructure in [region].

   It names what is in, where it runs and who runs it - so a physical-security exclusion later in the register is already justified by this sentence.

3. 3

   The full control inventory

   What it must contain

   Every one of the 93 Annex A controls of the 2022 edition, listed whether or not it applies to you.

   What the auditor checks

   Completeness, first and fastest. A register that lists only the controls you implement is not a Statement of Applicability - the excluded ones are precisely what it exists to record.

4. 4

   The applicability decision

   What it must contain

   Included or excluded, for each control, decided from your risk assessment and scope rather than from what you happen to have already written.

   What the auditor checks

   Whether the decision was made or inherited. A register where every control is included reads as a decision nobody took, and invites them to test several at random.

5. 5

   Justification for inclusion

   What it must contain

   The reason the control applies - normally the risk it treats or the obligation that requires it.

   What the auditor checks

   That the reason is about your business. 'Best practice' and 'required by ISO 27001' are the two answers that tell an auditor nothing, because they would be true for any organization.

   Included: all customer records are held in cloud systems accessed by role, so access rights are a primary control over the confidentiality risk in the register (R-04).

   It names the asset, the mechanism and the risk it traces to, so the row survives being read on its own.

6. 6

   Justification for exclusion

   What it must contain

   Why the control does not apply, stated as a fact about your organisation and traceable to the scope or the risk assessment.

   What the auditor checks

   This is the single most-tested field in the document. An exclusion with a blank reason, or the words 'not applicable' repeated, is one of the most common findings raised against an SoA.

   Excluded: [Organization] operates no owned data centre or server room, and the [location] office holds no production systems, so physical monitoring of such facilities does not apply.

   It states the fact, names where that fact holds, and ties back to the scope - which is what makes it defensible rather than an assertion.

7. 7

   Implementation reference

   What it must contain

   For every included control, the policy, procedure or record that implements it, named well enough to be retrieved.

   What the auditor checks

   They will pick two or three rows and ask for exactly those documents. This column is how the SoA becomes the index an auditor navigates your ISMS by.

8. 8

   Control owner

   What it must contain

   The role accountable for each included control - a role, not a person, so it survives someone leaving.

   What the auditor checks

   That the owner is plausible and reachable. A register where one name owns all 93 controls does not describe a management system anyone operates.

9. 9

   Implementation status

   What it must contain

   Whether the control is implemented, partially implemented or planned, with a date where it is not yet done.

   What the auditor checks

   Honesty, and that planned work has an owner and a date. Partial implementation stated plainly is normal at a first audit; partial implementation presented as complete is a finding.

10. 10

    Link to the risk assessment and treatment plan

    What it must contain

    A reference tying decisions back to the risks that drove them, so the SoA and the risk treatment plan tell the same story.

    What the auditor checks

    That the two documents agree. Clause 6.1.3 expects the SoA to follow from risk treatment, so a control treated in the plan but excluded in the register is a direct contradiction.

11. 11

    Version history and review cadence

    What it must contain

    What changed, when and why - and the commitment to review the register at least annually and whenever scope, risk or controls change.

    What the auditor checks

    Whether it is maintained or was written once for the certificate. A register whose last change predates a restructure, a migration or a new product line has stopped describing the organisation.

The SoA is usually the first document requested and the one most sampled from, because every other document in the set is reachable through it. These 7 questions cover most of what it is put through.

? Show me your Statement of Applicability.

Satisfies A single current version, approved, dated and covering every Annex A control - produced without assembling it from several spreadsheets.

Fails Several partial copies, or one nobody can say is the approved version.

? Why is this control excluded?

Satisfies A reason that is a fact about your organisation and follows from the scope, phrased so it stands up without you in the room.

Fails 'Not applicable', a blank cell, or a reason that would be equally true of any company.

? Show me the document that implements this control.

Satisfies The document named in the row, saying what the row claims it says, at the version the register cites.

Fails A document that does not exist yet, or one that turns out to cover something else.

? Does this match your risk treatment plan?

Satisfies The same decisions in both, with the register referencing the risks that drove them.

Fails A control treated in the plan and excluded in the register, or the reverse.

? Who approved this, and when?

Satisfies A named approver with a role and a date, on the current version, at a level with authority over the scope.

Fails An approval on an old version, or none at all.

? When did you last review it, and what changed?

Satisfies A version history showing review at least annually, plus changes made after scope, risk or control changes.

Fails A register unchanged since certification while the business demonstrably moved.

? You have marked this implemented - show me.

Satisfies The evidence that control produces: a ticket, a completed review, a configuration, a record.

Fails A policy that says the control happens, with nothing showing that it did.

Almost none of these are about the controls. They are about decisions nobody recorded the reason for, and a register that stopped tracking the business.

• ! Marking every control applicable to avoid having to justify anything

  It looks safe and does the opposite: you now owe evidence for all 93. Auditors read a fully-included register as a decision nobody made, and test it. Excluding a control properly is less work than implementing one you do not need.

• ! Writing 'not applicable' as the justification for exclusion

  That restates the decision instead of supporting it, and it is the most common finding raised against an SoA. Give the fact underneath it - no owned facility, no in-house development, no card data - and tie it to the scope.

• ! Letting the SoA and the risk treatment plan disagree

  They are checked against each other. A control treated in the plan but excluded in the register, or vice versa, shows the two were maintained separately. Update both from the same review or generate them together.

• ! Citing documents that do not exist yet

  The implementation column is the one an auditor samples. Naming a policy you intend to write turns a paperwork question into a credibility one. Mark the control planned, with an owner and a date, until the document is real.

• ! Inheriting a toolkit's justifications wholesale

  Generic justifications are recognisable on sight, and they are the fastest way to convert a document review into a deep audit. The reason has to name your systems, your data or your obligations.

• ! Still working from the 2013 control set

  The 2013 edition had 114 controls in 14 clauses; the 2022 edition has 93 across four themes. A register with the old structure signals the whole set was never migrated, and every mapping downstream is then suspect.

• ! Treating it as a certification artefact rather than a live register

  The SoA is the one document that should change when the business does - a new product, a migration, an acquired team. Reviewed only before an audit, it stops being the index of your ISMS and becomes a snapshot of the year you were certified.

The register above, assembled from your scope and risk profile: every control listed, each decision justified against your business rather than best practice, each included control citing the document in your set that satisfies it, and anything it cannot know flagged instead of invented. It carries your branding and exports to Word, PDF or Excel. The cover in the hero and the control table below are exactly that output, generated for an example company.

Both routes end with the same register. What differs is how many of the 93 decisions inside it you make alone, and whether anything checks them before an auditor does.

Scroll the table sideways to compare both routes.