ISO27K

Annex A control selector

A Statement of Applicability records a decision on all 93 Annex A controls. This works out which of them your scope makes arguable to exclude, and gives you the justification wording an auditor will accept.

Last reviewed 2026-08-31Written by Jacob Masse, TrazTech Inc.

Exclusion is legitimate and expected. What gets written up is an exclusion that follows from the budget rather than from the scope statement or the risk assessment. Six questions decide almost all of the arguable ones, because almost every defensible exclusion comes down to premises, software development, non-production data, or an availability commitment.

The answer appears on this page. Nothing is emailed anywhere unless you ask for it at the end.

What premises are inside the scope statement?

Inside the scope, not inside the company. A company with an office can still certify a scope that excludes it, as long as the scope statement says so and the work really happens elsewhere.

Do you develop software?

Infrastructure as code, deployment scripts and low-code applications count as development in an auditor's reading, even where nobody in the company has the word engineer in their title.

Where does production run?

Does production data ever reach a test environment?

This is the question behind the data masking control, and the honest answer is what matters. Auditors ask how you know.

What do your customer contracts commit you to?

Tick everything that appears in a signed agreement. A commitment in a contract closes off the matching exclusion.

How many people work there?

What the six questions are doing

Almost every arguable exclusion in Annex A comes from one of four facts about an organization, and the questions above establish all four. Everything else in the annex is written broadly enough that it applies to any company with staff, suppliers and software.

Where the defensible exclusions in ISO/IEC 27001:2022 Annex A come from
Fact about youControls it puts in playHow the argument is won or lost
No premises in scopePhysical perimeter, entry control, securing offices, physical monitoring, working in secure areas, utilities, cablingWon if the scope statement names no facility. Lost if a customer visits an office where in-scope work happens.
No software developmentThe secure development set, including secure coding, development life cycle, application security requirements, security testing, separation of environmentsLost the moment somebody mentions Terraform, a deployment script or a low-code app.
All development in-houseOutsourced developmentOne of the cleanest exclusions available. Lost if contract developers are used.
Production data never leaves productionData maskingWon only if something technical enforces it. A policy nobody checks is not evidence.
No availability commitmentRedundancy of information processing facilitiesLost by any signed uptime or recovery objective, which most software contracts now carry.

This is a first pass, not a Statement of Applicability

The output is a shortlist of controls your scope makes arguable to exclude and the wording that argument needs. It is not the document, because the document has to be written from your own risk assessment and no tool has seen that. Use it to skip the two days most projects spend arguing about the physical controls, then write the real thing in the order set out on the Statement of Applicability page.

Common questions

Do I have to give an email address to see the result?

No. The split, the reasoning and the control groups render on this page as soon as you finish the questions. The field underneath sends a written version with the justification wording set out control by control, which is useful for pasting into a document, and skipping it costs you nothing.

How many Annex A controls do most companies exclude?

Between zero and about a dozen of the 93. A cloud-hosted software company with no office in scope and no outsourced development is at the high end. A company with premises, contractors and an uptime commitment usually finds nothing it can defend excluding. There is no target, and a low exclusion count is not a worse answer.

Can we exclude a control because it is expensive?

No. Exclusion means the control is not necessary to treat your risks, and cost is not part of that test. The right move is to mark it applicable and not yet implemented, with an owner and a target date. That is a normal state for a management system and it survives an audit, which a cost-based exclusion does not.

Does this replace a gap assessment?

No. This decides which controls are in play. A gap assessment measures how far you are from operating the ones that are, across both Annex A and the clause requirements. Run this first, because scoping the control set is what makes the gap assessment cheaper.

Get the Statement of Applicability reviewed

Tell us your scope and where you are, and we will match you with Canadian firms that do ISO 27001 readiness work.

Get matched