The Statement of Applicability: ISO 27001’s Most Misunderstood Document

Illustration for: The Statement of Applicability: ISO 27001’s Most Misunderstood Document

The Statement of Applicability is a single document, usually one spreadsheet, and it is where most ISO 27001 certifications are won or lost. Teams treat it as a formality to be filled in at the end, when it is actually the load-bearing link between your risks and your controls. This article explains what the SoA is for, and how to produce one that survives an auditor’s first hour.

What the SoA actually is

Clause 6.1.3 d) of ISO 27001 requires a Statement of Applicability that contains the necessary controls, justification for their inclusion, whether they are implemented, and justification for excluding any Annex A controls. Under the 2022 edition of the standard, Annex A lists 93 controls across four themes, which are organisational, people, physical and technological.

Read that requirement carefully and the design intent is obvious. The SoA is not a checklist of Annex A. It is the documented outcome of your risk treatment, because you assessed risks, chose treatments, those treatments require controls, and the SoA records which controls you determined necessary and why. Annex A exists only as a reference list to check you have not forgotten anything. The direction of travel is risks first, controls second. Most organisations do it backwards, and it shows.

Document flow from risk assessment to Statement of Applicability, with Annex A as a completeness check and the backwards checklist route crossed out

The correct direction of travel is risks first, with Annex A used only as a completeness check.

Why auditors start there

Every certification audit I have been through, on either side of the table, opened with the SoA on the screen within the first hour. There are good reasons.

• It is the audit plan. The auditor samples from the controls you declared applicable, so the SoA literally defines the scope of stage 2 and every surveillance visit.
• It reveals maturity instantly. An SoA with all 93 controls marked applicable and “best practice” copied down the justification column tells the auditor the risk assessment and the control set are not connected. They will go looking for that disconnect, and find it.
• Exclusions are the easiest nonconformity in the book. An excluded control with a weak justification, or an applicable control marked “implemented” that plainly is not, gives the auditor a finding without leaving the document.
• The version and date tell their own story. An SoA last updated three days before the audit, or dated two years ago, each invite obvious questions.

Treat the document with the same seriousness the auditor will.

Deciding applicability honestly

The test for each control is simple to state. Does at least one of our risks, legal obligations or contractual commitments require this control? If yes, it is applicable and you should be able to point at the requirement. If no, exclude it and say why.

Exclusions are where teams lose their nerve, on the belief that excluding controls looks bad. The opposite is true, because a thoughtful exclusion demonstrates you understand your business. A fully remote software company can reasonably exclude parts of the physical monitoring controls if it genuinely has no premises within scope. The justification “the organisation occupies no premises, all infrastructure is cloud-hosted under contract, covered by controls 5.19 to 5.23” is credible. The justification “not relevant” is a finding waiting to happen.

Two honesty rules apply.

• Exclude on facts, not effort. “We do not develop software” excludes the secure development controls. “Secure development is hard and we have not got round to it” does not, because that is an applicable control that is not yet implemented, and the SoA has a column for exactly that state. Declaring a control applicable but partially implemented, with a plan, is fine. Hiding it as an exclusion is the thing auditors are trained to catch.
• Re-test exclusions when the business changes. The exclusion that was true before you acquired a company with an office and an on-premises data centre is false afterwards.

Link controls to risks, not to the list

The single biggest quality difference between a weak SoA and a strong one is traceability. For each applicable control, a strong SoA points to the specific risks it treats, so A.8.7 malware protection would be recorded as treating R-014 ransomware on endpoints and R-021 malicious mail attachment, or at minimum referencing the risk treatment plan entries. When an auditor asks “why is this control here?”, the answer is a lookup, not an improvisation.

Ticking all 93 controls to avoid this work is tempting and self-defeating. First, you have just volunteered to be audited against all 93, including ones you do not need and have not implemented. Second, you have severed the link the standard is built on, because clause 6.1.3 c) expects necessary controls to be determined from risk treatment, and an auditor who cannot trace any control to any risk will raise it against the risk assessment itself. Third, you have made every future review harder, because nobody can remember why anything is there.

Here is a practical structure that works as columns in one spreadsheet.

• Control reference and title, using Annex A numbering
• Applicable, yes or no
• Justification for inclusion, meaning risk IDs, legal or regulatory driver, or contractual clause
• Justification for exclusion, where applicable
• Implementation status, whether implemented, partial or planned, with a target date
• Evidence pointer, linking to the policy, system or record that demonstrates it
• Control owner by name or role
• Last reviewed date

Spreadsheet mock of a strong Statement of Applicability with two example rows showing justification, status, evidence, owner and review date

Two rows of a strong SoA, where every inclusion is traceable to named risks and every exclusion is grounded in fact.

Keeping it current between audits

The standard describes the SoA as a living document, and almost nobody treats it as one. The common pattern is a frantic update just before the surveillance visit, which means the SoA is wrong for eleven months of the year and useless as a management tool.

Two 12-month timelines contrasting an SoA left stale until a panic update with a living document reviewed quarterly and on trigger events

The same document, twelve months of being right versus one.

Four cheaper habits fix it.

• Put the SoA on the agenda of the existing quarterly security or ISMS review. Fifteen minutes is enough to ask whether there are new risks, retired systems, or status changes from planned to implemented.
• Trigger a review on defined events, such as a new product line, an acquisition, major outsourcing, an office move, or a change in law bringing new regulatory obligations. Write the trigger list down in the ISMS procedures.
• When a risk assessment changes, change the SoA in the same piece of work. They are two views of one decision, and separating their maintenance is how they drift.
• Version it properly, with a version number, a date, a change log and an approver on the front sheet. Auditors check this, and it costs nothing.

Ownership

One person should own the document, typically the ISMS manager or CISO, but the ownership that matters is per control. Every applicable control needs a named owner who can say whether it is operating and where the evidence is. An SoA whose owner column just says “IT” is a document nobody owns. Management approval matters too, because the SoA states what the organisation has decided is necessary, so it should carry sign-off from whoever holds that authority, not just from the person who typed it.

Getting yours into shape

Take an afternoon and audit your own SoA before someone else does. Pick ten applicable controls at random and try to name the risk or obligation behind each. Pick every exclusion and check the justification is still factually true. Check the date, the version history and the approver. If any of those checks fail, you have found the first hour of your next audit, so fix it now, while it is cheap.