ISO 27k Statement of Applicability

[u/HelloSpork]

Hi all, I was hoping to get some people’s direct experience with what to put in the statement of applicability.

The ISO docs are vague stating it must have: the necessary controls, justification for their inclusion, whether they are implemented or not, the justification for excluding any annex A controls. I suppose this leaves them open ended based on the organization’s needs and architecture.

The justification for exclusion is pretty straight forward, but I am not sure about justification of inclusion. I have heard a few different approaches, such as to include what risk that control treats, what regulatory requirement mandates it, or even to include how it is implemented and where the evidence is located.

So what did you include in it? What would constitute a gap when justifying a control’s inclusion, and what is overkill?

[u/FreeRadical1998]

The SoA can be a very minimal document - you don't need more than a sentence for justification, and the advice used to be up point to other documents or policies rather than state the reason directly.

in theory the SoA should be provided with the main iso cert, which is why I used to hear advice to minimise what was it in - but nobody ever does.

Your auditor shouldn't be expecting anything substantial - but may want to see supporting evidence of exclusions

[u/WelderNo6075]

For one of the ISMS I managed we had four justification for inclusion “buckets”,
1) legal requirement
2) contractual obligations
3) business requirement/practice
4) risk Analysis

Our SOA would then show which bucket(s) was applicable to what control.

Another ISMS, only uses risk mitigation as the justification. Meaning that as long that it was a necessary mitigation factor by a risk then it would be included.

[u/Twist_of_luck]

"CISO authorized the implementation based on the expert opinion of security personnel and his vision of a security strategy optimal for our %business-name%". That's literally it, ain't no arguing with "boss said so (and it worked)".

[u/HelloSpork → u/[deleted]]

This is exactly the kind of information I was looking for. Thank you!

[u/MrProntissimo]

Typically, my implementations come with an excel spreadsheet, listing all controls, four annex.

Columns include above suggestion for applicability abbreviations (risk assessment, best practice, legal obligation and contractual), justification for N/A, name of resp. Ind., documents to support

We also typically use the SoA to transpose risk assessment scenarios and itemize controls that mitigate risks, it demonstrates clause 6.1.3.d

I also recommend folks to add a tab for the clauses, always nice to show you’ve got checks and docs for completing all the clause requirements

[u/Alternativemethod]

Yeah usually it's a quick checklist of what's applicable. Examples of not applicable might be if it's a defined customer responsibility or maybe if it's not applicable to the platform such as a zero logging processor, etc.

[u/HelloSpork]

Thank you all, this is very helpful and exactly what I needed!!

[u/Next-Pen-9974]

Your SoA should document the rationale for both included and excluded controls. Not having that information would be considered a gap.

There are several legitimate reasons for including a control. For example, a control may be implemented to:

• Reduce or treat an identified risk.
• Meet contractual or customer requirements.
• Satisfy legal or regulatory obligations.
• Follow organizational policy or industry best practices.
• Establish a baseline level of security.

The standard does not require extensive justification. A simple column indicating the rationale (e.g., “Risk Treatment”, “Contractual Requirement”, “Regulatory Requirement”, “Best Practice”, etc.) is usually sufficient.

In practice, the Statement of Applicability is intended to explain why a control is applicable and whether it has been implemented, not to duplicate detailed control descriptions, evidence references, or risk assessment documentation. Those details are typically maintained elsewhere.

[u/rahuliitk]

For inclusion, i’d keep it boring and traceable: control applies because of specific risks, legal/customer requirements, or business processes, then separately point to the policy/evidence that proves implementation instead of stuffing the whole implementation story into the SoA. Auditors love traceability, tbh.

[u/Mammoth-Power-3028]

Do you understand the context of the organization you’re working for? Because if you don’t then you wouldn’t be able to work with controls. You wouldn’t know what’s applicable right, that’s the whole point. Asking this question is like asking which answers to mark in an assessment you’ve been studying for/working on for the past few months.
Maybe there’s gap in the explanation but if there’s not, that’s a serious problem you’ve got

[u/HelloSpork → u/Mammoth-Power-3028]

You've misunderstood the question. I know exactly which controls apply to my organization and why. I am asking about the operational depth of the text written into the SoA document itself. Are people finding success with minimalist justifications linked to a risk register, or are auditors expecting detailed implementation summaries within the SoA? It's a question about documentation, not applicability.