
SaaS and Cloud Services
Structuring SaaS agreements for vendors and regulated customers
Every SaaS agreement that handles personal data is a data protection arrangement, whether the customer operates in a regulated sector or not. We act for SaaS vendors and regulated customers in equal measure. For vendors, the challenge is structuring standard terms, data protection addenda and security schedules that satisfy the regulatory requirements of customers in telecoms, payments and financial services, without creating unmanageable operational obligations. For customers, the challenge is ensuring that the vendor’s terms meet UK GDPR controller and processor obligations, international transfer mechanisms and sector-specific requirements under the Telecommunications (Security) Act 2021 and FSMA 2023. Both sides need the contract to work commercially and comply with the law.
Why SaaS regulatory compliance matters now
Three regulatory shifts have made this critical. First, the FCA’s operational resilience regime treats SaaS vendors as critical third parties. You must assess whether your organisation can maintain core functions if the vendor fails, and demonstrate that assessment to the regulator. Second, Ofcom’s application of the TSA 2021 has moved from theoretical guidance to active enforcement. Operators must identify and manage supply chain security risk, and that means contractual controls over the vendors that touch your infrastructure. Third, the ICO’s enforcement activity on international data transfers has raised the cost of getting the mechanics wrong.
Exit risk has become acute. Most SaaS agreements allow vendors to delete data 30-90 days after termination. For regulated businesses, this timeline may conflict with statutory retention obligations: telecoms operators must retain call detail records for 12 months in some cases; payment services providers must keep transaction records for 6 years under PSRs 2017. A data wipe clause triggered automatically at termination can put you in breach of your own regulatory obligations.
Where clients get it wrong
Three recurring mistakes. The first is treating the SaaS agreement as standard procurement. Clients accept the vendor’s master service agreement without checking that the data protection addendum specifies the lawful basis for processing, defines the controller/processor relationship, and addresses data subject request obligations. Under UK GDPR Article 28, a processor must assist the controller in meeting its obligations to data subjects. If the contract does not say how, you cannot discharge your duties.
The second is underestimating international transfer risk. Many SaaS vendors use tiered architecture: data is processed in the nominated region but may be backed up, analysed or logged elsewhere. The contract should explicitly prohibit transfers outside approved jurisdictions and require notification if the vendor plans to change its infrastructure.
The third is failing to address exit mechanics. Clients assume data will be available for migration at termination. The contract often does not specify the format, timeline or conditions. When termination is triggered, the vendor may require payment for extended retention, export data in a proprietary format, or apply its standard deletion clause. For a payment processor or telecoms operator, this is operationally catastrophic and potentially unlawful.
| Common issue | Better approach |
|---|---|
| Standard procurement without controller/processor analysis | Precise roles defined under UK GDPR Article 28 |
| International transfers not investigated | Transfer mechanisms verified for backup, analytics and logging locations |
| Exit assumed to mean data portability | Format, timeline and conditions for data return specified contractually |
| Sector-specific retention obligations overlooked | Retention aligned with telecoms, financial services or payments requirements |
| Vendor and customer risks not balanced | Terms satisfying regulated customers without unreasonable vendor exposure |
What good looks like
A well-drafted SaaS agreement works for both parties. For the vendor, standard terms must be robust enough to satisfy regulated customers without creating bespoke obligations for every deal. For the customer, the agreement must address the lawful basis for processing, define controller/processor roles with precision, handle international transfers, address data subject requests, set out deletion and data portability at termination, and meet sector-specific security requirements.
Bratby Law advises on both sides of SaaS transactions. For vendors, we structure standard terms and regulatory schedules that accelerate sales into regulated sectors. For customers, we identify the specific regulatory requirements that apply and negotiate amendments to vendor terms that meet those requirements. On both sides, we build in exit mechanics that work commercially and comply with retention obligations.
How Bratby Law helps
- SaaS agreement review and negotiation: for customers, reviewing vendor master service agreements, data protection addenda and security schedules against sector-specific regulatory obligations, identifying gaps and negotiating amendments; for vendors, reviewing customer markup and advising on which amendments are commercially acceptable
- Data protection addendum drafting: drafting or negotiating DPAs that meet UK GDPR Article 28 requirements, specifying lawful basis, controller/processor roles, data subject request obligations, sub-processor management and breach notification timelines
- International transfer mechanisms: advising on the legal basis for cross-border data transfers, including adequacy decisions, Standard Contractual Clauses, and transfer impact assessments for vendors with multi-country infrastructure
- Security schedules for regulated customers: drafting security schedules that reflect TSA 2021 supply chain security requirements for telecoms operators and FCA operational resilience standards under FSMA 2023 for payments and financial services customers
- Exit mechanics and data portability: negotiating data export terms (format, timeline, conditions), retention obligations that align with sector-specific statutory requirements, and transition support provisions that protect the customer during migration
- Vendor-side terms structuring: for SaaS providers, structuring standard terms, DPAs and security schedules that satisfy the regulatory requirements of customers in telecoms, payments and financial services from the outset, reducing negotiation friction, shortening sales cycles and avoiding bespoke terms for every regulated customer
Rob Bratby advises SaaS vendors and regulated customers in equal measure on data protection and regulatory compliance for cloud services agreements, bringing experience from General Counsel roles at regulated telecoms and payments businesses. Bratby Law is recognised as a Lexology Global Elite Thought Leader for data protection.
Frequently asked questions
Should we negotiate the vendor's standard terms or draft our own?
It depends on which side you are on. For customers, negotiating amendments to the vendor’s standard terms is usually more practical than drafting bespoke agreements. Focus negotiation effort on the data protection addendum, security schedule, exit mechanics and sector-specific regulatory requirements. For vendors selling into regulated sectors, investing in standard terms that already address telecoms, payments and financial services requirements avoids protracted negotiation on every deal. For high-value or high-risk procurements, a bespoke agreement may be justified on either side.
Does a SaaS agreement need a separate data protection addendum?
Yes. UK GDPR Article 28 requires processor obligations to be set out in a contract. The DPA should specify scope, nature, purpose and duration of processing, types of personal data, categories of data subjects, and the parties’ obligations. A vendor that does not provide a DPA as standard is a red flag.
What if the SaaS vendor is US-based?
US-based vendors can comply with UK GDPR. The key is ensuring transfers outside the UK are covered by an adequacy decision or Standard Contractual Clauses. If the vendor uses sub-processors in multiple countries, require confirmation of the legal basis for each transfer. Many US vendors now offer UK data residency options.
Can we rely on anonymisation to avoid GDPR obligations?
Only if anonymisation is genuinely irreversible. Most “anonymised” datasets are only pseudonymised, which remains personal data under UK GDPR. If in doubt, assume the data is personal and apply GDPR controls. The ICO provides guidance on anonymisation.
What happens if the SaaS vendor suffers a data breach?
The vendor must notify you without undue delay. You then have 72 hours to decide whether to notify the ICO. The contract should require vendor cooperation with your breach response, evidence preservation, and assistance with regulator notification.
How do we ensure data is available for migration at termination?
Specify that data must be exported in a standard, machine-readable format (CSV, JSON, XML) within 30 days. Do not accept proprietary formats. Require a test export during procurement. If you have large data volumes, negotiate a 60-day export window.
Related transactions pages
See also our other transactions pages:
- Mergers and Acquisitions
- Private Equity
- Subsea Cables
- MVNOs and MVNEs
- Interconnection, Peering and Access Agreements
- Network Sharing and Co-location Agreements
- Digital Infrastructure Projects
- Data Commercialisation and Licensing
- NSIA Clearances
Independent directory rankings
Our specialist expertise is recognised in major independent legal directories:
- Chambers & Partners: Rob Bratby is ranked as a band 2 lawyer in the UK Guide 2026 in the “Telecommunications” category: Chambers
- The Legal 500: Rob Bratby is listed as a “Leading Partner – Telecoms” in London (TMT – IT & Telecoms): The Legal 500
- Lexology: Rob Bratby is featured on Lexology’s expert profiles as a Global Elite Thought Leader for data: Lexology



