Applicability has five scopes — and "tenant-wide" is usually the wrong first answer

The question every framework asks first

Before controls, before evidence, before any posture number, every framework asks the same thing about every requirement: does this apply to you? DORA asks it through proportionality and the “critical or important function” test; NIS2 through “appropriate and proportionate”; ISO/IEC 27001 explicitly, in the Statement of Applicability. And most organisations answer it once, for the whole company, in a column with two values.

That answer is almost always wrong in one of two directions. Either it says “applicable” for a requirement that only touches three systems out of two hundred — and the team spends a year proving something for the other 197 — or it says “not applicable” for a requirement that does apply, just not everywhere, and an auditor finds the exception in the first hour.

“Applicable” and “not applicable” are not properties of a requirement. They are properties of a requirement and a scope.

Five scopes, in the order they get more specific

The honest applicability decision names what it is about. In practice there are five kinds of “what”:

1. Tenant-wide. The requirement applies to the organisation as such — the management body approves the ICT risk framework (DORA Art. 5), the management body approves the risk-management measures (NIS2 Art. 20). There is no narrower unit; the decision is genuinely global.
2. A business solution. The requirement applies to a function the business runs — the payments platform, the customer portal — and, through it, to everything the function depends on. Criticality lives here: DORA’s critical or important functions are business solutions, not servers.
3. An IT service. The requirement applies to a service that composes assets — the payment gateway API, the identity provider. Third-party obligations usually attach here, because that is what a provider delivers.
4. An asset. The requirement applies to a specific system — a database, a cluster, an endpoint fleet. Backup and restore, encryption at rest, patching: their evidence is per asset, so their applicability is too.
5. A process. The requirement applies to how work is done — the incident process, the change process, the joiner/mover/leaver process — regardless of which system runs it.

The order matters. A decision made at the wrong level is either too coarse to prove or too fine to maintain. “Encryption at rest applies tenant-wide” is unprovable — some assets hold nothing worth encrypting and the auditor knows it. “Encryption at rest applies to these eleven data stores” is a claim with eleven pieces of evidence behind it and a reason for every store that is not on the list.

What changes when scope is a field

“Not applicable” gets a reason and a boundary. “TLPT does not apply — entity below the significance threshold” is a tenant-wide decision with a reason. “Secure coding does not apply — we do not develop software” is a tenant-wide decision until the first developer is hired, so it carries a review date. “Cryptography does not apply to the internal wiki” is an asset-scoped decision that leaves the requirement applicable everywhere else. Three different shapes; one column cannot hold them.

Coverage becomes countable. If a requirement applies to eleven data stores, “covered” means eleven links from controls to those stores with a status, and posture can say 9 of 11 rather than “in progress”. If it applies tenant-wide, coverage is one control with one piece of evidence — also fine, also countable.

Undecided stops hiding. A requirement that nobody has decided on is neither applicable nor not — it is undecided, and it should show up as such. When applicability is a decision record rather than a default, the absence of the record is visible.

Framework updates become a diff. When a framework pack publishes a new version, most requirements carry over unchanged; a few change materially. Scoped decisions can be carried across with a “needs review” flag on exactly the changed ones, instead of a spreadsheet being re-typed.

A worked example

Take DORA Article 8 — identify, classify and document ICT-supported business functions, assets and dependencies. Tenant-wide, it applies: every financial entity must do this. But the proof is scoped: the classification exists per business solution (which ones are critical or important), the dependency map exists per IT service, and the “documented” part exists per asset. So the decision is “applicable — tenant-wide”, and the coverage below it is scoped to solutions, services and assets. When one new IT service is added under a critical function, the requirement does not change; the coverage gap appears on that service.

Now take ISO/IEC 27001 Annex A 8.28, secure coding. If the organisation runs one internally developed application, the honest decision is “applicable — scoped to the web-shop IT service”, with “not applicable” implicit for the purchased systems and no reason needed for each of them individually. If it later builds a second application, one more scoped decision — not a rewrite of the SoA.

In Secantra

An applicability decision is a record per requirement per adoption with a status — applicable, not applicable, deferred, waived, exception approved — a reason, and a scope: tenant-wide, or a specific asset, IT service, business solution or process from the CMDB. Controls map to requirements; asset compliance links carry the per-object status; evidence carries dates. Posture is computed from those, so a scoped decision changes exactly the numbers it should. Nothing here invents a taxonomy: the five scopes are the four CMDB object kinds the product already has, plus “all of it”.

Checklist

• Every requirement has a decision, and every decision names its scope
• “Not applicable” always carries a reason; conditional exclusions carry a review date
• Requirements whose evidence is per system are decided per system (or per service), not tenant-wide
• Coverage is counted against the scope, so posture says “9 of 11”, not “in progress”
• Undecided requirements are listed as undecided — never defaulted to either value