Start with a three-part scope check: confirm whether the organisation operates in an essential or important sector, verify whether it meets the relevant size thresholds, and then assess whether customers or national authorities create indirect or designated exposure. NIS2 is implemented locally, so jurisdiction and transposition also matter. For borderline cases, legal review is prudent before concluding out of scope.
How to scope NIS2 without overcalling or undercalling it
NIS2 scope is not a single yes-or-no test, because it combines sectoral eligibility, entity size, and special cases where the formal customer or regulatory relationship can pull an organisation into scope. The practical question is whether you are an essential or important entity, whether you cross the relevant thresholds, and whether local law or contractual designation changes the result.
That means security teams should treat scoping as a governance exercise with legal input, not as a quick technical label. The main failure mode is assuming that being a supplier, contractor, subsidiary, or service provider automatically excludes you, when the legal structure or customer obligations may say otherwise.
Sector and size are the first filters, but not the whole test
NIS2 is built around sector coverage first. Organisations in essential and important sectors need to check whether their actual activities fall within the directive’s listed categories, because corporate structure alone does not settle scope. A group can contain both in-scope and out-of-scope business lines, so the assessment should follow the regulated activity, not just the brand or holding company.
Size is the second filter for many entities, but it is not a universal shield. Thresholds and exemptions vary by sector and by national implementation, so security teams should confirm the applicable local rules rather than rely on a generic medium-sized business assumption. For EU NIS2 Directive, the sector list and the legal definition of essential and important entities are the starting point, not the conclusion.
Where organisations operate across multiple countries, size tests can also become fragmented in practice. One jurisdiction may transpose the directive with slightly different thresholds, supervisory expectations, or sector interpretations, so the same group may be in scope in one member state and outside it in another. That is why scoping should be documented per legal entity and per jurisdiction, not only at the enterprise level.
Customer obligations and local transposition can still create exposure
Even if a security team believes its own organisation is below the formal threshold, customer contracts, regulated procurement, or national designations may still impose NIS2-aligned duties indirectly. That is especially common for managed service providers, critical suppliers, and companies embedded in a regulated customer’s operating model, where incident reporting, assurance, logging, or access control obligations are passed down contractually.
Local transposition matters because NIS2 is implemented through national law, and those laws may define notifications, supervision, and sector scope with different operational detail. A team should therefore review both the directive and the local implementation text before concluding that no action is needed. If you need a broader view of the threat environment behind those obligations, ENISA’s recurring analysis of critical infrastructure risk is a useful companion to the legal text and helps explain why supply chains and cross-sector dependencies are central to the directive.
For teams that manage multiple regulated relationships, the important distinction is between formal legal scope and practical obligation. A company may not be a directly supervised NIS2 entity, yet still need controls, evidence, and incident coordination to satisfy customer flow-down clauses or to remain a viable supplier to in-scope organisations.
Risk and Threat Considerations
The main risk in NIS2 scoping is false confidence. Organisations either miss an in-scope entity because they focus only on headcount, or they overestimate exclusion because they ignore sector-specific rules, group structure, and customer-driven obligations. That creates compliance exposure, weak incident readiness, and gaps in accountability when a real event occurs.
Failure mechanism: Scope is misread at the legal-entity level, so the organisation does not build the reporting, governance, or evidence trail required by the transposed national rules.
Impact: The organisation can face regulatory action, delayed incident response, and avoidable contractual disputes, especially where a customer or authority expected NIS2-aligned controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while NIS2, ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Scope and entity obligations | NIS2 directly governs sector, size, and indirect obligations for essential and important entities. |
| Recommendation — Map each legal entity to sector, size, and transposed national scope before declaring it out of scope. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | NIS2 scoping affects reporting readiness and incident-response obligations under regulated customer and authority expectations. |
| Recommendation — Align incident reporting and coordination procedures to the obligations that apply in each jurisdiction. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Scoping depends on understanding the organisation's regulated role, services, and stakeholders. |
| Recommendation — Document the regulated context of each entity before assigning cybersecurity obligations. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | NIS2 scoping turns on legal transposition and customer-driven contractual obligations. |
| Recommendation — Track applicable legal, regulatory, and contractual requirements per entity and jurisdiction. | ||
| SOC 2 (AICPA) | CC1.2 — Communicates internal control responsibilities | Customer obligations can impose assurance expectations and evidence responsibilities beyond formal scope. |
| Recommendation — Clarify responsibility for compliance evidence and customer commitments across legal entities. | ||
Practitioner Guidance
What to verify: Map each legal entity to its sector, size, and country of operation, then confirm whether the national transposition text changes the default NIS2 position. Do not rely on enterprise-wide assumptions when subsidiaries or service lines operate differently.
Decision rule: If the organisation sits near a threshold, serves a regulated customer, or provides critical outsourced services, treat the case as a scoped legal review rather than an internal policy decision. The cost of a short legal check is usually lower than remediating a missed in-scope obligation later.
Practitioner takeaway: The right question is not “Are we a cyber company that cares about NIS2?”, but “Which of our entities, services, and customer relationships make us legally or operationally responsible under local NIS2 implementation?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
