Reason for inclusion of ISO 27001 controls

In ISO 27001, organisations need to justify the inclusion or exclusion of the 93 controls defined in Annex A. When you build your Statement of Applicability (SoA), every control you apply must have a documented "Reason for inclusion" — a short justification explaining WHY the control is relevant to your organisation.

Auditors look for this justification directly, so getting it right saves time during certification. This article explains what the field is, why it matters, and how to choose the right reason for each control.

What is "Reason for inclusion"?

The Statement of Applicability lists all Annex A controls and records, for each one, whether it is:

- Included (applicable) — the control is relevant and you will implement it, or
- Excluded (not applicable) — the control does not apply to your organisation.

For every control you include, ISO 27001 (clause 6.1.3 D) requires you to state the reason. The "Reason for inclusion" is that justification. It links the control back to the driver that makes it necessary.

Why the field matters

It is mandatory. The SoA is one of the core documents an ISO 27001 auditor will always request, and the justification is a required element.

It shows traceability. A good reason connects the control to your risk assessment, a legal or contractual obligation, or a business need — proving your ISMS is driven by real requirements, not guesswork.

It speeds up audits. Clear reasons mean fewer follow-up questions and less back-and-forth with your auditor.

The four reasons for inclusion you can select in the Adoptech portal:

• Risk Assessment — the control has been selected as a result of the risk assessment process to mitigate an identified risk to an acceptable level.
• Regulatory — a law or regulation requires it.
• Contractual — a contract requires it.
• Best practice — the organisation has chosen to adopt it as good practice or an internal policy requirement, even where no specific risk has been identified.

Which reason should you choose?

In practice, most auditors expect the primary reason to be Risk Assessment, with the SoA cross-referencing the risk register to show the link between each identified risk and the control(s) selected to address it.

Controls included purely on best-practice grounds without a risk justification can attract questions during audit, so use Best practice sparingly and only where it genuinely applies.

Some controls, such as A.5.31 Legal, statutory, regulatory and contractual requirements, would typically have a reason of Regulatory.

Examples

Control A.5.15 Access control
Reason: Risk Assessment — selected to treat the risk of unauthorised access to customer data identified in the risk register.

Control A.8.24 Use of cryptography
Reason: Contractual — customer contracts require encryption of data at rest and in transit.

Control A.5.31 Legal, statutory, regulatory and contractual requirements
Reason: Regulatory — required to meet UK GDPR and other applicable obligations.

How to set a reason for inclusion

1. Find the control you want to update. Make sure the control is marked as Included and has the yellow banner.
2. Click Edit at the top right hand corner.

3. Select the appropriate reason from the dropdown (Risk Assessment, Regulatory, Contractual, or Best practice).

4. Click Save at the top right hand corner.

Tips

• Default to Risk Assessment where a control treats an identified risk, and cross-reference the relevant risk in your register.

• Use Best practice sparingly — expect auditor questions if a control has no risk justification.

• Review your reasons whenever your risk assessment changes.

• Revisit the SoA at each management review to keep justifications current.