Author: Nikol Sochor
On October 20, 2026, a power failure in Google Cloud’s London region disrupted services for hours. Some Revolut customers couldn't make card payments or withdraw cash, and Lloyds and HSBC customers also reported problems. None of these companies caused the outage, but their customers felt it.
The lesson for every SaaS company: when your customers run their business on your platform, your problem quickly becomes theirs. That's changed what customers expect from your contract, and what you need to be able to deliver.
SaaS contracts used to be primarily about access to a service: what the product does, what it costs and how long the subscription lasts. Today, customers want the contract to say what happens when something goes wrong. In the EU, regulation increasingly shapes these requirements, particularly for customers in regulated sectors.
Customers ask for service-level agreements (SLAs) with real remedies, business continuity and disaster recovery commitments, and clear incident communication. This is often driven by DORA (EU digital resilience rules for the financial sector) and NIS2 (EU cybersecurity rules), where applicable to the customer and the services concerned.
Customers want named security standards, a fixed deadline for telling them about a breach, and higher liability for data breaches. Under the GDPR, a customer acting as controller must report a notifiable personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it (Art. 33(1)). As its processor, you must notify the customer ”without undue delay” (Art. 33(2)). That’s why customers want a fixed, short deadline in the contract.
Customers want clear limits on how you can use their data, including for analytics and product improvement. Under the GDPR, when acting as a processor, you can generally only process personal data on the customer's documented instructions (Art. 28). Any use for your own purposes requires a separate assessment of your role and legal basis.
Customers ask for a list of your subprocessors (the vendors that process personal data on your customer’s behalf), advance notice of changes, and a right to object. This comes from the GDPR (Art. 28), while NIS2 or DORA (for financial-sector customers) separately address broader supply-chain security risks.
Customers want to know which AI features and AI providers you use, and a commitment not to train models on their data. This is driven mainly by customers’ own data and confidentiality policies and the GDPR, with potential additional obligations under the EU AI Act, under which customers need to understand the AI systems they use.
Customers need data export in a usable format, time to retrieve their data, and help with migration. Since September 12, 2025, the EU Data Act has required contracts for in-scope services to allow customers to initiate switching on no more than two months' notice, followed by a transition of up to 30 calendar days (subject to permitted extensions) and at least 30 calendar days for data retrieval after the transition. Switching charges are banned from January 12, 2027. Until then, they must not exceed costs directly linked to switching. The ban does not automatically remove standard service fees or valid early termination charges.
In short, the contract now covers the whole business relationship, not just the access to the service.
Your sales team closed the deal. Now the customer's procurement team has sent back your contract with a long list of changes.
The problem is that you run one product for many customers. A commitment that works for one large customer, like a custom incident-notification deadline, an on-site audit or unlimited liability for data breaches, can become expensive or impossible to deliver across hundreds or thousands of them. But push back on everything and you'll find enterprise deals harder to win.
The question is how to give customers confidence without taking on risks you can't manage. Most common requests have a standard alternative that works at scale:
Offer an ISO 27001 certificate or a SOC 2 Type II report as a first step, while preserving further on-site audits and inspection rights where required by law or appropriate to the circumstances.
Offer a separate, higher contractual liability cap for data breaches (often called a super-cap) instead of unlimited liability.
Obtain customers' general written authorisation to use subprocessors, with advance notice of changes and a right to object, instead of asking for their approval each time.
Offer standard SLAs that differ by subscription plan instead of negotiating a custom SLA for each customer. Customers who need more can move to a higher plan, and your team only has to run and report on a few service levels.
A good SaaS contract gives customers real protection and only promises what you can deliver. It:
Before you say yes to a customer's change, ask:
Your service is now part of the infrastructure your customers rely on every day. That makes your SaaS contract part of your commercial strategy and risk management, not just a legal formality. The goal isn't a longer or more protective contract. It's one that helps you win and keep customers, with commitments you can actually keep.
Need SaaS contracts that can stand up to enterprise procurement? Eldison Legal can help you prepare them.