Cybersecurity requirements are taking an increasingly important place in IT, SaaS and cloud contracts.
Security questionnaires, detailed security schedules, incident notification requirements, audit rights, business continuity commitments and restrictions on subcontracting are now common in negotiations with European customers.
Some of these requirements simply reflect the customer’s own approach to security.
Others have a different origin: the customer is subject to cybersecurity regulation and needs its providers to support its own compliance.
NIS2 and DORA are two important examples.
For international technology providers, understanding why a requirement is being requested is often the first step in determining what needs to be accepted — and what can still be negotiated.
Customers are entitled to protect their systems, data and operations when relying on an external technology provider.
Depending on the service and the risks involved, they may legitimately require commitments relating to security measures, vulnerability management, incident notification, business continuity, subcontracting or evidence of compliance.
But those requirements should remain consistent with the service being provided and the provider’s actual security framework.
A standardized SaaS service, for example, cannot necessarily accommodate security requirements designed for a fully outsourced or dedicated IT environment.
For the provider, the first question should therefore be: what risk is this requirement intended to address?
The analysis changes when the customer itself is regulated.
European cybersecurity and sector-specific regulations increasingly require organizations to manage risks arising from their technology providers and supply chains.
This means that some regulatory obligations inevitably find their way into customer contracts.
Under NIS2, for example, regulated entities must address supply-chain security, including security-related aspects of their relationships with direct suppliers and service providers.
Under DORA, financial entities are subject to much more detailed requirements concerning their contracts with ICT service providers.
A provider may therefore face contractual requirements arising from legislation even where the provider itself is not directly subject to that legislation.
When a customer says that a security requirement is “mandatory,” it is worth understanding what that means.
The requirement may come from:
The distinction matters.
If the customer needs a particular contractual mechanism to comply with DORA, removing it altogether may not be realistic.
But its scope and implementation may still be negotiable.
An audit right may be justified without providing unrestricted access to the provider’s systems.
An incident notification requirement may be necessary without requiring every minor security event to be reported immediately.
A security requirement may be mandatory in principle without requiring the exact technical solution initially proposed by the customer.
One of the main risks for technology providers is accepting security commitments that do not match their actual practices.
This can happen when a customer’s standard security schedule is accepted without sufficient review, or when responses to a security questionnaire become incorporated into the contract.
Security, legal and technical teams therefore need to be aligned.
If the contract requires a particular incident response time, audit mechanism, security measure or subcontracting process, the provider should verify before signing that the commitment reflects its actual practices — and negotiate it where it does not.
Security provisions are no longer confined to a technical appendix reviewed at the end of the contracting process.
They can affect the cost of the service, the provider’s operating model, its use of subcontractors, its ability to change infrastructure and the allocation of liability between the parties.
For international providers using global contract templates, the challenge is therefore to identify which European customer requirements genuinely require adaptation and which can be addressed within the provider’s existing contractual and security framework.
This is particularly important where the customer relies on NIS2 or DORA to support its requests.
For more:
And cybersecurity regulation can also apply directly to the provider or its products:
When faced with a demanding cybersecurity schedule, international providers should not assume either that “the customer is regulated, so everything is mandatory” or that the requirements are simply excessive.
The useful questions are more specific:
Where does the requirement come from? What risk or regulatory obligation does it address? Does the proposed clause accurately reflect that requirement? And can the provider actually comply with it?
Those questions usually provide a much better basis for negotiation.
Withlaw assists international SaaS, cloud and technology providers in reviewing and negotiating cybersecurity requirements in contracts with French and European customers, including:
Our objective is to help providers meet legitimate European customer requirements without accepting unnecessary or operationally unrealistic commitments.