ISO 27001 exclusions: a statement of applicability example

Published 22 October 2026. Updated 9 November 2026 by GRCompliance.

“Not applicable” is a conclusion. It is not the reasoning that gets you there.

If you are checking your organisation's control decisions before an audit, the uncomfortable rows are often the exclusions. Someone chose a status months ago, the supporting conversation has disappeared, and now you need to explain what the decision actually meant.

The information security management standard published by the International Organization for Standardization and the International Electrotechnical Commission is commonly called ISO 27001. Its statement of applicability connects the controls your management system needs with the reasons for selecting them, their implementation state and the reasons for excluding reference controls.

This ISO 27001 statement of applicability exclusion example is a practical way to review that connection. It is not a list of exclusions you can copy into your own organisation.

What matters this week, and what can wait

This week, select one exclusion affecting an important service. Find the scope statement, risk assessment and evidence behind it. Ask the service owner whether the underlying facts still hold.

If you cannot explain the decision, mark it for review rather than quietly renewing it. If the control is necessary but missing, record a treatment gap with an owner and next action.

Reformatting the entire statement, adding a new colour scheme and writing longer justifications for sound decisions can safely wait. An unsupported exclusion that hides a real weakness cannot. Your useful result today is one decision another competent person can reconstruct without relying on your memory.

Understand what the statement is for

An information security management system is the organisation's structured approach to managing information security risks and improving how they are handled. A control is a measure used to manage a risk or meet a relevant obligation.

Clause 6.1.3 links risk treatment, control selection, comparison with Annex A and the statement of applicability. In practical terms, you determine necessary controls, check the reference set for omissions, and document the resulting decisions. Necessary controls can come from other sources or be designed for your own circumstances.

The statement is therefore not simply a checklist saying how many reference controls you have installed. Its purpose is to make the chosen security approach explainable.

Excluding an Annex A reference control is also different from excluding a management-system requirement. The statement does not let you switch off the requirements in clauses 4–10 because they are inconvenient.

Use your licensed copy for the complete requirements. This article paraphrases the approach and gives clause and control references without reproducing the standard's text.

Separate applicability from implementation

Applicability asks whether the control is necessary in your context. Implementation asks what you have actually put in place and how you know it works.

Situation	Appropriate treatment	What to avoid
Necessary control not yet operating	Keep applicable; record the gap, owner and treatment plan	Excluding it to improve the completion figure
Necessary control delivered by a supplier	Explain shared responsibilities and assurance	Assuming outsourcing removes the need
Reference control not necessary on reviewed facts	Record a specific exclusion rationale and evidence	Using a bare “not applicable” label
Facts are unclear or have changed	Reassess; record uncertainty and action	Carrying an old conclusion forward automatically
Custom control addresses a necessary outcome	Document the control and reference mapping	Treating an empty reference row as proof nothing is needed

Budget constraints may explain why an action is delayed. They do not by themselves establish that a control is unnecessary. Similarly, “we have never had an incident” does not demonstrate that the relevant risk is absent.

Keep the business decision and current implementation state visible. A truthful gap is easier to manage than a reassuring but misleading exclusion.

A fictional exclusion: weak wording versus reasoned wording

The following is a wholly hypothetical teaching example. It describes no client, real assessment or certification decision.

Assume a narrowly defined service uses purchased, standard applications. The assessment team has checked whether any software development is commissioned within the management-system scope, including supplier customisations, integration scripts and work performed by another group company. On the invented facts, none is commissioned.

The team is reviewing Annex A reference A.8.30, concerning outsourced development.

Weak justification

Not applicable. We use cloud services.

That tells the reviewer almost nothing. A business can use cloud services and still commission software development. It does not identify the service, scope, evidence or person who checked the assumption.

More useful hypothetical justification

Excluded for the currently defined service scope. The reviewed service inventory and supplier agreements identify purchased standard applications and no commissioned software development, including supplier customisation or integration work. The service owner confirmed these facts in the recorded review. Reassess before commissioning development or changing the service boundary. Supplier and cloud-service risks remain addressed through separate applicable controls.

This is example wording, not an approved exclusion. The decision still depends on accurate facts, relevant obligations and the overall control design. If a supplier is actually building a custom integration, the assumed basis may fail.

Notice what the wording does not claim: it does not exclude all supplier security, access management or software acquisition responsibilities. One reasoned exclusion is not a blanket exemption from related risks.

Assemble the decision trail

Keep the reasoning close to the record, with references to protected supporting material. You do not need to paste whole contracts into a public-facing statement.

Download the blank applicability decision worksheet, read the fictional example, or use the workbook. The worksheet is an internal review aid, not an official standard form. No registration is required.

For each decision, capture:

The service, legal entity and management-system scope version.
The reference control and any necessary custom control.
The relevant risks and contractual or legal questions considered.
The reason for inclusion or exclusion, in plain language.
The implementation state, separately from applicability.
Source records and the dates on which facts were checked.
The accountable decision owner and reviewer.
Review date and events that would invalidate the reasoning.

If an obligation is uncertain, record the question and obtain qualified advice. Software cannot make legal determinations about whether a contract or law permits a particular approach.

Challenge common exclusions before accepting them

“We are entirely in the cloud”

Ask which physical assets and work locations still exist, who administers the service and how responsibilities are shared. Laptops, paper records, home working and provider dependencies may remain relevant. Do not use hosting location as a universal exclusion rule.

“Our provider handles it”

Distinguish performance from accountability. Obtain evidence of what the provider actually does, what the contract covers and which responsibilities remain with your organisation. Outsourced work can still support a necessary control within your management system.

“The control is not implemented”

That describes a gap, not a reason for exclusion. Link it to the treatment plan and record interim measures and the business decision. Do not change a control's applicability to conceal unfinished work.

“The auditor accepted it last year”

Find the reasoning rather than relying on recollection. Scope, services, obligations and supplier arrangements can change. An earlier audit does not prove today's facts are the same or guarantee the next conclusion.

Review consistency across risks, controls and evidence

Choose a risk in the risk-register guide and follow it to the treatment decision. Then check the corresponding controls, applicability reasoning and operating evidence.

If the risk assessment calls supplier dependence significant but the statement excludes all relevant supplier controls, investigate the disagreement. If an entry says implemented but nobody can locate proof, review the implementation claim rather than merely adding a filename.

The controls management guide helps place decisions alongside the measures they describe. Keep a versioned record of material changes so you can explain what was decided at the time, not just what the current table says.

Set review triggers such as commissioned development, a new supplier arrangement, a changed service boundary or a revised obligation. A calendar review is useful; a known material change should not wait for it.

Use software to organise the decision, not make it

GRCompliance Core's documentation confirms a control library, implementation status, risks and evidence linked to controls. Those are useful building blocks for keeping the reasoning and supporting records together.

GRCompliance controls table for the fictional Latore LTD workspace, with applicability, justification and implementation status — The controls table in the public demo, with applicability and justification beside status. The Latore LTD workspace is fictional sample data.

Practise with one fictional decision. Check how your chosen edition represents control status and how an authorised reviewer retrieves the justification and evidence. Where the exact fields differ, keep the full decision in a controlled supporting record. No automatic worksheet import or legally validated exclusion is promised.

Try the live demo with fictional information only, or inspect the free open-source Core. A complete-looking register is not a certification guarantee. The quality of the underlying decision still matters.

Frequently asked questions

Can I exclude a control because it is unfinished?

No. If it is necessary, keep it applicable and describe the implementation gap and treatment. Applicability and implementation answer different questions.

Does outsourcing make a control unnecessary?

Not automatically. A supplier may perform a necessary activity while your organisation retains responsibilities for selecting, overseeing and obtaining assurance about it. Review the actual arrangement.

Must my statement use the same layout as Annex A?

The important point is to document necessary controls and reasons, implementation state and justified reference-control exclusions, with a traceable comparison. A readable table can help, but layout does not replace the reasoning.

Can I reuse the example exclusion unchanged?

No. The example relies on invented facts and a narrow assumed scope. Verify your own services, development arrangements, risks and obligations before reaching a decision.

Sources

Reviewed 7 November 2026. Standard requirements are paraphrased; consult your licensed edition. The educational practice note is not an endorsed interpretation or a substitute for the standard.

International Organization for Standardization: information security management standard overview; clause references 6.1.3 and 7.5.
Auditing Practices Note on the statement of applicability, September 2022: necessary controls, reference mapping, exclusions and externally performed activities; see its endorsement disclaimer.
Information security controls guidance overview; example reference A.8.30.
GRCompliance Core documentation: verified control, risk and evidence capabilities.