What happens when a company assumes it is outside NIS2 scope but its customers are in scope?

The company can still be pulled into compliance work through contractual and security obligations. In practice, customers may require regular security assessments, adequate cybersecurity measures, and agreements that bind the supplier to NIS2-aligned controls. That means supplier risk management becomes part of the compliance picture, even for businesses that are not directly regulated under the directive.

Why NIS2 Spillover Reaches Suppliers That Are Not Directly In Scope

A supplier outside the formal scope can still become operationally bound to NIS2 expectations because customers must manage third-party risk across their own regulated environment. That usually turns into contractual security clauses, evidence requests, security questionnaires, assurance reviews, and control expectations that the supplier must meet to keep the business relationship viable.

The important distinction is between legal scope and commercial scope. A company may not owe direct reporting or regulatory duties under NIS2, yet it can still be required to demonstrate cybersecurity practices that help a customer satisfy supplier oversight, incident resilience, and supply chain security obligations.

In practice, this means the supplier is often asked to prove things like secure access handling, change control, patching discipline, incident notification processes, and the ability to support customer audits or assessments. The burden comes through the customer relationship, not because the supplier has become a regulated entity by default.

How Customer Contracts Turn Compliance Expectations Into Supplier Work

Once a customer is in scope, supplier security becomes part of the customer’s own control environment. That usually affects procurement, onboarding, renewal, and incident handling, because the customer needs assurance that outsourced services will not create avoidable exposure in its regulated operations.

The practical result is that suppliers may be evaluated against NIS2-aligned expectations even when the contract does not name the directive explicitly. Those expectations often include minimum security measures, cooperation during assessments, timely notification of incidents, and support for due diligence or remediation activities.

This is why “out of scope” is not the same as “unaffected.” The company may still have to adapt its baseline controls, produce evidence on request, and accept customer-driven obligations that shape how its systems, processes, and support teams operate.

That pattern is consistent with the broader supply chain security logic behind the directive, as reflected in the EU NIS2 Directive and ENISA’s discussion of sector and supply chain threat exposure in the ENISA Threat Landscape.

What Suppliers Should Expect to Be Asked For

The most common pressure points are not abstract policy statements, but concrete proof. Customers usually want evidence that the supplier can maintain acceptable cybersecurity hygiene, handle access securely, and respond predictably if an incident affects the service chain.

Security questionnaires and recurring assurance reviews
Contract clauses for incident notification and cooperation
Evidence of access controls, logging, and remediation discipline
Security testing, audit support, or independent assurance reports
Commitments that flow down into subcontractors and service providers

For a supplier, the key issue is not whether every customer asks for the same artefacts, but whether the organisation can answer consistently and defend its claims. Weak documentation, unclear ownership, and inconsistent control execution usually create more friction than the underlying technology stack does.

Readers looking for a control lens can also compare the problem to established identity and supplier-risk patterns described in Ultimate Guide to NHIs, Regulatory and Audit Perspectives and the broader risk discussion in Ultimate Guide to NHIs, Key Challenges and Risks, especially where supplier access, unmanaged credentials, and over-privilege affect customer assurance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC-01 — Cybersecurity Supply Chain Risk Management	Supplier assurance and contract flow-down are central to NIS2 spillover.
	GV.SC-02 — Cybersecurity Supply Chain Risk Management	Customers rely on supplier evidence, assessments, and monitoring to manage risk.
	PR.AA-05 — Identity Management, Authentication, and Access Control	Customer assessments commonly scrutinize access handling and privileged exposure at suppliers.
Recommendation — Define supplier security requirements and review them during onboarding and renewal. Maintain current supplier evidence and reassess it on a fixed cadence. Limit supplier access to the minimum necessary and review it regularly.
NIST SP 800-53 Rev 5	SA-9 — External System Services	Outsourced services and customer dependencies require enforceable security terms.
	SR-6 — Supplier Assessments and Reviews	Supplier risk management depends on recurring assessments and review evidence.
Recommendation — Bind external service providers to explicit security and incident obligations. Assess suppliers periodically and retain documented results for assurance.

Practitioner Guidance

What to prioritise: Treat customer security requirements as a commercial and operational input, not just a legal review. If your services support regulated customers, assume you will need a repeatable evidence package for controls, incident handling, and third-party dependencies.

What to verify: Confirm which controls are contractual promises versus internal practice, then verify that the evidence you provide matches actual operations. Gaps between policy wording and day-to-day control execution are what usually fail customer assessments.

Decision rule: If a customer can materially rely on your service in its regulated environment, build your baseline to withstand supplier scrutiny even if you are not directly regulated. If your controls cannot survive audit-style questions, they are not yet stable enough for that customer segment.

Practitioner takeaway: The real question is not whether you are formally inside NIS2, but whether your customers need your controls to behave as if you were part of their compliance boundary.