The Statement of Applicability: the document auditors read first

The Statement of Applicability is where you declare, control by control, what applies to you and why. It is the connective tissue between your risk assessment and your controls - and because it is a declaration you make about yourself, it is the first place an auditor looks for inconsistency.

What it must contain

ISO 27001 requires the SoA to include, for every Annex A control:

• Whether the control is applicable or not.
• Justification for inclusion - why it applies.
• Justification for exclusion - why it does not.
• Whether it is implemented.

It must also reference the necessary controls determined by your risk treatment - so the SoA and the risk treatment plan have to agree. Auditors check that alignment directly.

Why it carries so much weight

Most audit evidence shows what you did. The SoA shows what you decided. That makes it uniquely testable: an auditor can pick any line and ask to see the risk that drove it, the control that implements it, and the evidence it operates. Three artefacts, one claim, and any mismatch is visible immediately.

The fastest way to fail a Stage 1 audit is an SoA copied from a template. It will justify controls against risks you never assessed and mark things implemented that nobody operates - and every line is checkable.

Writing justifications that hold up

Vague justifications are the most common weakness. Compare:

• Weak inclusion: "Best practice."
  Strong: "Addresses risk R-014 (unauthorised access to customer data via shared credentials); required by customer contract clause 8.2."
• Weak exclusion: "Not applicable."
  Strong: "We operate no physical data centres; all infrastructure is cloud-hosted with the provider responsible under the shared responsibility model. No organisational premises host in-scope systems."

A good justification references something checkable - a risk ID, a scope boundary, a contractual obligation, a legal requirement.

Exclusions you can defend, and ones you cannot

Defensible exclusions rest on a fact about your organisation or scope:

• No physical premises hosting in-scope systems.
• No software development in scope, so secure development controls do not apply.
• No industrial control systems.

Not defensible:

• "We have not implemented it yet." That is applicable and not implemented - a legitimate state with a treatment plan, not an exclusion.
• "Too expensive." Cost informs risk treatment; it does not make a control inapplicable.
• "The cloud provider handles it." Often partially true, which makes it applicable with shared responsibility - not excluded.

That last one is the most common error. Provider responsibility narrows your scope for a control; it rarely eliminates it, because you still own configuration and oversight.

Keeping it alive

An SoA is a living document, and staleness is a finding. Update it when:

• The risk assessment changes.
• Scope changes - a new system, product, site or acquisition.
• A control moves from planned to implemented.
• The standard is revised.

Version it, date it, and record who approved it. Superseded versions should be retained, because past audits were conducted against them.

Common findings

• Controls marked implemented with no supporting evidence.
• Exclusions with no justification, or justification that contradicts the scope statement.
• SoA and risk treatment plan disagreeing about which controls are necessary.
• Last updated long before the audit, despite scope changes.
• Template language referencing an organisation type that is not yours.

Key takeaways

• The SoA records applicability, justification and implementation for every Annex A control.
• It must agree with your risk assessment and treatment plan - auditors check the join.
• "Not yet implemented" is a status, never an exclusion.
• Cloud provider responsibility narrows a control; it rarely removes it.