NIS2 applies directly to organizations operating in a wide range of critical and important sectors across the EU.
But its impact extends beyond the companies that fall within its scope.
NIS2 requires regulated entities to address cybersecurity risks in their supply chains, including risks arising from their relationships with direct suppliers and service providers.
As a result, international SaaS, cloud and technology providers may encounter NIS2 requirements in customer contracts even when they are not themselves subject to NIS2.
Organizations subject to NIS2 must implement appropriate and proportionate technical, operational and organizational measures to manage cybersecurity risks.
Supply-chain security is expressly part of those requirements.
This means that regulated customers need to consider the security of the suppliers and service providers on which their systems and operations depend.
In practice, this can affect supplier selection, security assessments and contract negotiations.
Providers may therefore be asked to complete detailed security questionnaires and accept commitments relating to security measures, vulnerability management, incidents, business continuity, subcontracting or audit.
Unlike the GDPR, NIS2 does not prescribe a standard set of contractual provisions that every technology provider must accept.
The GDPR, for example, specifies the provisions that must be included in a data processing agreement between a controller and a processor. NIS2 takes a different approach: it requires regulated entities to manage supply-chain risks, including risks arising from their relationships with direct suppliers and service providers.
How those requirements are translated into the contract will therefore depend on the service, the risks involved and the customer’s own cybersecurity framework.
A customer may also combine its NIS2 requirements with internal security policies, group standards or other regulatory requirements.
So when a clause is presented as “required by NIS2,” the provider should identify the underlying requirement before accepting the proposed wording.
The customer may need the protection. That does not necessarily mean it needs that exact clause.
NIS2 requires regulated entities to follow a staged reporting process for significant incidents, starting with an early warning within 24 hours of becoming aware of the incident, followed by an incident notification within 72 hours.
For technology providers, the important point is that the customer’s regulatory clock is not necessarily the provider’s contractual clock.
If the customer needs time to assess the impact of an incident, determine whether it is significant and prepare its own notification, a contractual obligation requiring the provider to notify within the same 24-hour period may leave the customer with very little time to act.
The parties should therefore consider when the provider must notify, what triggers the obligation and what information needs to be available at each stage.
In some cases, an initial alert followed by more detailed information as the investigation progresses may be more workable than a single notification obligation requiring a complete incident report within a very short deadline.
Customers need appropriate ways to assess the security of their suppliers.
Depending on the service, this may involve security questionnaires, certifications, independent audit reports or contractual audit rights.
For SaaS and cloud providers operating shared environments, however, unrestricted audit rights can create security, confidentiality and operational issues.
The negotiation should therefore address matters such as scope, frequency, notice, confidentiality and the use of existing certifications or independent reports.
The customer needs appropriate assurance; the provider needs a control mechanism that works with the service it actually delivers.
Customers may also want greater visibility over the provider’s own supply chain.
A SaaS service may rely on cloud infrastructure, hosting providers, support services, software components and other technical suppliers.
This can lead to contractual requirements concerning subcontractors, security obligations imposed on them and notification of material changes.
Again, the appropriate mechanism depends on the service.
A standardized SaaS provider operating a complex shared infrastructure may need more flexibility than a supplier delivering a dedicated outsourced service.
Security questionnaires and contractual schedules can create binding commitments.
Providers should therefore check that statements made during customer due diligence accurately reflect their security practices and that contractual obligations can actually be implemented.
This is particularly important for commitments concerning incident reporting, audit, vulnerability management, business continuity and subcontracting.
Where a customer requirement goes beyond the provider’s existing framework, the issue should be identified and negotiated before it becomes a contractual obligation.
NIS2 gives regulated customers good reasons to pay closer attention to their technology suppliers.
It does not make every security requirement presented during a contract negotiation automatically mandatory.
For international providers, the useful distinction is between: what NIS2 requires the customer to achieve, what the customer has chosen to require from its suppliers, and what the provider can reasonably commit to.
That distinction makes the negotiation much easier to structure.
Withlaw assists international SaaS, cloud and technology providers dealing with NIS2-related requirements from French and European customers, including:
Our objective is to help providers address legitimate NIS2-related customer requirements without unnecessarily extending their contractual commitments.