When should a company assume it is in scope of NIS2 even if it is not a large enterprise?

A company should assume possible NIS2 scope when it operates in a high criticality or other critical sector and meets the relevant size thresholds, or when sector-specific exceptions apply. Some entities are in scope regardless of size, and national authorities can also designate additional entities if service disruption could affect public safety, security, or health.

Why This Matters for Security Teams

NIS2 scope is not a simple headcount test. A small or midsize company can still be in scope if it supports a covered sector, provides a critical service, or is designated by a national authority because disruption would affect public safety, security, or health. The practical risk is underestimating regulatory exposure until procurement, legal review, or an incident response exercise surfaces it late.

That matters because scope decisions drive security governance, incident reporting, supplier oversight, and board accountability. The legal text of the NIS2 Directive is intentionally broader than many organisations expect, and ENISA’s threat work continues to show that service disruption and supply chain exposure are not limited to large enterprises. NHI management is relevant here too: NHI Mgmt Group notes that properly managing NHIs is essential for a successful zero-trust implementation, which becomes harder when regulatory obligations are discovered late.

In practice, many security teams encounter NIS2 obligations only after legal counsel, an acquirer, or a regulator asks for proof of sector classification rather than through intentional compliance planning.

How It Works in Practice

The first step is to map the company to NIS2’s sector logic, then test whether size thresholds apply and whether any exceptions override them. The question is not only “Are we large enough?” but also “Do we operate in a listed critical or important sector, provide a service that authorities treat as sensitive, or sit inside a supply chain that changes the answer?” Current guidance suggests treating this as a legal and operational classification exercise, not a pure IT decision.

For security teams, that means building a scope file with three inputs: business activity, jurisdiction, and dependency chain. A provider may be small yet still be in scope if it delivers services that are essential to a covered entity or if national implementation rules pull it in. The official EU legal text is the anchor, but it should be read alongside national transposition and sector guidance. The ENISA Threat Landscape is useful for understanding why regulators focus on systemic disruption, not just firm size.

• Confirm the sector classification for each legal entity and service line.
• Check whether the entity meets size thresholds, including any employee, turnover, or balance-sheet tests used locally.
• Review whether the service is covered regardless of size, especially in critical infrastructure or digital supply chains.
• Document whether national authorities can designate the entity based on public safety or health impact.
• Trace key suppliers and outsourced operators, because scope can expand through dependency relationships.

This is also where NHI governance becomes relevant. If a small provider supports regulated customers, weaknesses like exposed service accounts or leaked API keys can create reportable operational risk; NHI Mgmt Group’s Key Challenges and Risks research shows how often identity sprawl and credential exposure undermine control. These controls tend to break down when a company operates across multiple member states because national transposition and sector interpretations differ.

Common Variations and Edge Cases

Tighter scope screening often increases legal review and monitoring overhead, requiring organisations to balance faster go-to-market decisions against the risk of missed regulatory obligations. There is no universal standard for this yet, especially for subsidiaries, managed service providers, and software vendors whose customers are in covered sectors.

One edge case is a small company that never serves the public directly but provides critical tooling to an in-scope operator. Another is a group structure where one entity is small on paper but operationally central to a regulated service. In those situations, best practice is evolving toward conservative triage: assume potential scope until counsel confirms otherwise, then maintain evidence of why the entity is or is not covered. That posture is especially important when NHI exposure is material, because identity failures in suppliers can cascade quickly across regulated environments. NHI Mgmt Group’s Regulatory and Audit Perspectives research is useful when scope discussions turn into audit readiness.

For practitioners, the safest assumption is that size alone does not remove NIS2 exposure. In practice, many organisations only learn they were likely in scope after a customer due diligence request or an incident forces a formal legal review.

Related resources from NHI Mgmt Group

• How should organisations in scope of NIS2 structure accountability for cybersecurity governance and incident reporting?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?
• Why is single-provider AI agent governance not enough for enterprise security?