Control applicability is one of the most misunderstood parts of ISO 27001.
Many teams assume applicable means “we should implement this control because it is listed.”
Others assume not applicable means “we do not want to do this control.”
Both views are too simple.
Short answer: in ISO 27001, control applicability means a control is relevant to your organization’s scope, risks, legal or contractual requirements, business context, and chosen risk treatment. If a control is excluded, the reason must be clear, defensible, and consistent with your risk assessment and Statement of Applicability.
Applicability is about relevance and justification.
It is not about convenience.
Why applicability matters
ISO 27001 is risk-based.
That means controls should not be selected randomly.
They should connect to:
- The scope of the information security management system.
- The risks you identified.
- The data and systems you protect.
- Legal, regulatory, and contractual requirements.
- Customer expectations.
- Business operations.
- Risk treatment decisions.
Applicability helps show why a control belongs in your security program.
It also helps explain why a control may not belong.
That explanation matters during audits, customer reviews, and internal governance.
Applicable does not always mean fully implemented
This is an important distinction.
A control can be applicable even if it is not fully implemented yet.
For example, supplier security may clearly apply because you rely on vendors that process customer data.
But your supplier review process may still be immature.
In that case, the right answer is not to mark the control as not applicable.
The better answer is:
- Applicable.
- Partially implemented.
- Gap recorded.
- Owner assigned.
- Completion task tracked.
Applicability answers whether the control is relevant.
Implementation status answers whether the control is already operating.
Do not mix those two questions.
Not applicable does not mean not important
A control may be not applicable because it genuinely does not fit the scope.
For example, if your ISO 27001 scope does not include physical office operations because your team is fully remote and uses managed cloud services, certain physical controls may need careful review.
But “not applicable” should never be used just because:
- The control is difficult.
- The team lacks budget.
- Nobody owns it yet.
- Evidence is not available.
- The company wants fewer tasks.
Those are implementation issues, not applicability reasons.
If a control reduces a real risk in scope, it is probably applicable even if implementation needs work.
The Statement of Applicability is where decisions become visible
For ISO 27001, applicability decisions are documented in the Statement of Applicability, often called the SoA.
The SoA should show:
- Which Annex A controls are applicable.
- Which controls are not applicable.
- Why each decision was made.
- Current implementation status.
- References to supporting controls, policies, or evidence.
This is why weak applicability decisions create problems later.
If your risk assessment says supplier risk matters, but supplier controls are excluded with a vague reason, the story does not hold together.
See What a Statement of Applicability Actually Does in ISO 27001 for more context.
What makes a control applicable?
A control is usually applicable when one or more of these are true:
- It treats an identified risk.
- It supports a legal, regulatory, or contractual requirement.
- It protects in-scope systems or data.
- It supports customer security expectations.
- It is needed for business continuity or resilience.
- It is part of the organization’s chosen risk treatment plan.
- It supports another control or policy commitment.
For example, access control is usually applicable when users access business systems or customer data.
Incident response is usually applicable when the business needs to identify, manage, and learn from security events.
Supplier security is usually applicable when third parties handle data, systems, support, hosting, or operational services.
What makes a control not applicable?
A control may be not applicable when it is genuinely outside the scope or irrelevant to the organization’s risk context.
Examples may include:
- A control relates to a technology the organization does not use.
- A control relates to a physical environment outside the defined scope.
- A control relates to an activity the organization does not perform.
- The risk is not present in the scoped environment.
- Another documented control or arrangement fully addresses the need in a different way.
The justification should be specific.
Avoid wording such as:
- Not relevant.
- Not needed.
- Too small.
- Not implemented.
- No budget.
Those statements do not explain the decision well.
Good applicability questions
Use these questions before marking a control applicable or not applicable:
- Is the related asset, process, system, supplier, or data in scope?
- Does the control reduce a risk we identified?
- Is the control expected by a customer, contract, law, or regulation?
- Would excluding the control create an unexplained gap?
- Can we explain the decision to an auditor or customer?
- Does the implementation status match the applicability decision?
- Is there evidence or a plan for applicable controls?
These questions slow the process down slightly, but they prevent much larger problems later.
Applicability examples
| Scenario | Applicability decision | Why |
|---|---|---|
| Company uses SaaS tools with employee accounts | Access control applicable | Access needs approval, review, and removal |
| Company has no internally managed servers | Some infrastructure controls may be not applicable | Scope and technology do not include those assets |
| Company relies on cloud hosting provider | Supplier security applicable | Vendor risk affects customer data and service availability |
| Company has no payment card processing in scope | Payment-specific controls may be not applicable | Activity is outside scope |
| Company handles incidents through ad hoc chat | Incident response applicable | Current process is weak, but risk exists |
The key is to separate relevance from maturity.
Common mistakes
The first mistake is marking every control applicable to look complete.
That creates unnecessary work and can make the SoA harder to defend.
The second mistake is marking difficult controls as not applicable.
That hides risk.
The third mistake is writing generic justifications that could apply to any company.
That makes the SoA look copied rather than risk-based.
The fourth mistake is failing to update applicability after scope changes.
New products, systems, suppliers, data types, and locations can change control relevance.
Where Framework Pro fits
Framework Pro uses questionnaire answers and business context to generate tailored ISO 27001 policy drafts and supporting readiness documents for review and implementation.
That is useful because applicability decisions should be structured, explainable, and tied to business context rather than copied from a template.
Quick FAQ
What does applicable mean in ISO 27001?
Applicable means a control is relevant to your scope, risks, requirements, business context, or risk treatment decisions.
Can a control be applicable but not implemented?
Yes. Applicability and implementation status are different. A control may apply even if it is planned or partially implemented.
Can we exclude an Annex A control?
Yes, if the exclusion is justified and consistent with scope, risks, and requirements. The reason should be documented in the Statement of Applicability.
Is “not enough budget” a valid reason for not applicable?
No. Budget may explain implementation delay, but it usually does not make a relevant control not applicable.
How often should applicability be reviewed?
Review applicability at least annually and after major changes to scope, systems, suppliers, services, data, customer requirements, or risk.
Final thought
Control applicability is not a checkbox exercise.
It is the reasoning behind your control set.
When applicability is clear, the Statement of Applicability becomes easier to defend, policies become more relevant, and implementation work becomes more focused.
That is exactly what a growing business needs.