How to Update Saas, Cloud and Data Processing Agreements for the Uk's 2026 Data Law Changes, Practical Contract Checklist

Every SaaS data processing agreement in the UK now needs updating. The Data Use and Access Act (DUAA) came into force on 5 February 2026, restructuring data-access obligations and controller-processor responsibilities under the UK GDPR framework. A second wave of obligations, including complaint-handling duties, took practical effect on 19 June 2026, creating immediate operational and contractual requirements for vendors and buyers alike. Any organisation that processes personal data through cloud or SaaS platforms and has not yet amended its data processing agreement clauses is exposed to enforcement risk, contractual liability gaps, and commercial disputes that could have been avoided with timely redrafting.

TL;DR, three contract actions to take now:

1. Insert DUAA-specific definitions, data-access cooperation obligations, and updated lawful-basis mapping into every active DPA.
2. Add a complaint-handling process clause with SLA timelines, escalation triggers, and cost-allocation language reflecting the 19 June 2026 requirements.
3. Review and reallocate PECR/cookie liability between vendor and buyer, update indemnity and insurance provisions accordingly.

Quick Compliance Decision, Who Needs to Update SaaS Data Processing Agreements in the UK?

Not every contract clause requires the same level of revision. The scope of your update depends on your role in the processing chain and the nature of the services provided. Use the decision framework below to identify your priority clauses.

• You are a controller (buyer/customer). Update clauses covering lawful-basis allocation, complaint-handling cooperation, data-access response obligations, and vendor audit rights. You bear primary regulatory liability and must ensure your DPA reflects the DUAA’s expanded data-access regime.
• You are a processor (SaaS vendor). Update clauses covering processing scope and instructions, complaint-handling assistance timelines, sub-processor appointment procedures, breach-notification windows, and liability caps. You face direct obligations under the UK GDPR and must contractually delineate your cooperation duties.
• You are a sub-processor. Ensure your upstream DPA mirrors the controller-processor obligations, particularly on data-access requests, complaint escalation, and security standards. Back-to-back contractual alignment is essential to avoid gaps in the processing chain.
• You operate across both UK and EU jurisdictions. Consider whether a single DPA can serve both regimes or whether jurisdiction-specific addenda are needed, given that the DUAA introduces UK-specific obligations that diverge from the EU GDPR baseline.

Clause-by-Clause SaaS Contract Checklist, The Practical Redline Map

This section provides the model DPA clauses that buyers and vendors should negotiate, redline, or insert into existing SaaS and cloud agreements. Each clause includes the buyer’s preferred position, the vendor’s typical counter-position, and sample contractual wording that can be adapted.

Processing Scope and Lawful Basis

The DUAA reinforces the requirement that controllers and processors clearly define the subject matter, duration, nature, and purpose of processing. Under the UK GDPR (as retained and amended), Article 28(3) mandates that the contract sets out the type of personal data and categories of data subjects. The DUAA’s data-access obligations make it critical that the lawful basis for each processing activity is expressly mapped in the DPA schedule.

Buyer position: The DPA schedule must list every processing activity with its corresponding lawful basis. The vendor must not process data for any purpose outside the schedule without prior written instruction.

Vendor position: Processing activities should be described at a level of generality that accommodates product updates. The customer is solely responsible for determining lawful basis.

Model clause:

Schedule 1 shall set out the subject matter, duration, nature and purpose of processing, the type of personal data processed, and the categories of data subjects.  The Controller shall identify the lawful basis for each processing activity.  The Processor shall process personal data only on documented instructions from the Controller, including with regard to transfers, unless required to do so by UK law, in which case the Processor shall inform the Controller before processing unless that law prohibits such notification.  Data Access and DUAA Requests The DUAA introduces specific data-access and data-sharing obligations that may require processors to assist controllers in responding to requests from data subjects or from third parties exercising statutory access rights.

Your SaaS data processing agreement must now address how these requests are routed, who bears the cost of compliance, and the response timeline.


Buyer position: The vendor must notify the buyer of any data-access request within 24 hours and provide full cooperation (including technical extraction) at no additional cost.

Vendor position: The vendor will notify the buyer within 48 hours and provide reasonable assistance. Complex extraction or bespoke reporting is chargeable at agreed professional-services rates.

Model clause:
The Processor shall, without undue delay and in any event within [24/48] hours, notify the Controller of any request received from a data subject or third party exercising rights under UK data protection legislation (including the Data Use and Access Act).  The Processor shall provide such technical and organisational assistance as is reasonably necessary to enable the Controller to respond within statutory timescales.  [Costs for bespoke data extraction beyond standard reporting shall be borne by the Controller at rates specified in Schedule [X] / shall be included in the service fees. ] Complaint Handling and Escalation The complaint-handling process obligations that took effect on 19 June 2026 require organisations to maintain accessible, transparent procedures for handling data-protection complaints.

In a SaaS context, both vendor and buyer must address how complaints received by either party are escalated, investigated, and resolved, and how regulatory cooperation costs are shared.


Buyer position: The vendor must operate a complaint-handling procedure that meets ICO standards and escalate any complaint to the buyer within 24 hours. The vendor must cooperate with any ICO investigation at its own cost.

Vendor position: The vendor will maintain a reasonable complaint-handling procedure. Complaints relating to the customer's data will be forwarded to the customer, who retains primary responsibility. Regulatory cooperation beyond routine enquiries is chargeable.

Model clause:
Each party shall maintain a complaint-handling process in accordance with applicable UK data protection legislation.  Where the Processor receives a complaint relating to the Controller's personal data, the Processor shall (a) acknowledge receipt to the complainant within [2 business days], (b) notify the Controller within [24/48] hours, and (c) provide reasonable cooperation in the investigation and resolution of the complaint.  Costs of regulatory cooperation arising from the Processor's act or omission shall be borne by the Processor; costs arising from the Controller's instructions or data shall be borne by the Controller.

Security and Breach Timelines Under the UK GDPR, processors must implement appropriate technical and organisational measures and notify the controller without undue delay upon becoming aware of a personal data breach.  The ICO's guidance specifies that controllers must then notify the ICO within 72 hours where the breach is likely to result in a risk to individuals' rights and freedoms.


Model clause:
The Processor shall notify the Controller of any personal data breach without undue delay, and in any event within [24] hours of becoming aware of the breach.  Such notification shall include: (i) the nature of the breach, (ii) the categories and approximate number of data subjects and records concerned, (iii) the likely consequences, and (iv) the measures taken or proposed to address the breach.  The Processor shall cooperate with the Controller to enable notification to the ICO within 72 hours.  Sub-Processors and Audits Article 28 of the UK GDPR requires that the processor does not engage a sub-processor without the controller's prior specific or general written authorisation.

The practical effect of the 2026 changes is that controllers are now more likely to insist on enhanced audit rights and faster sub-processor change notification windows.


Buyer position: Prior specific written consent for each sub-processor. Audit rights exercisable with 30 days' notice, including on-site inspection.

Vendor position: General authorisation with an obligation to notify the buyer of sub-processor changes 30 days in advance. Audits limited to annual third-party certification reports (e.g., SOC 2 Type II).

Model clause:
The Processor shall not engage any sub-processor without the Controller's prior [specific written / general] authorisation.  The Processor shall notify the Controller of any intended addition or replacement of a sub-processor at least [30] days in advance.  The Controller may object on reasonable grounds, and where no resolution is reached, the Controller may terminate the affected processing on [30] days' written notice.  Audit rights shall be exercised [via annual provision of SOC 2 Type II reports and, upon reasonable cause, on-site inspection with [30] days' notice].  Liability, Fines and Indemnities This is typically the most heavily negotiated provision in any SaaS data processing agreement.

UK data law 2026 has not altered the principle that regulatory fines are imposed on the party at fault, but the practical question of how contractual risk allocation, indemnification, and insurance interact with enforcement outcomes demands careful drafting.


Buyer position: Uncapped indemnity from the vendor for fines, penalties, and costs arising from the vendor's breach of the DPA or applicable law. Data-protection liabilities carved out of any general liability cap.

Vendor position: Liability for data-protection claims subject to the general contractual cap (typically 100–200% of annual fees). No indemnity for regulatory fines, which may not be insurable. Each party bears its own regulatory fines.

Negotiation lever: Industry observers expect that a common middle ground will involve a separate, higher sub-cap for data-protection liabilities (e.g., 300% of annual fees), with mutual indemnities for breach caused by each party's acts or omissions, and an obligation for both parties to maintain appropriate cyber-insurance.
Data Retention, Return and Deletion
Your SaaS contract checklist should include precise obligations on what happens to personal data at the end of the contract. Under Article 28(3)(g) of the UK GDPR, the processor must delete or return all personal data after the end of the provision of services and delete existing copies unless UK law requires storage.

Model clause:
Upon termination or expiry of the Agreement, the Processor shall, at the Controller's election, return or securely delete all personal data processed under this DPA within [30/60/90] days, and certify such deletion in writing.  The Processor may retain personal data only to the extent required by applicable UK law, and shall notify the Controller of any such retention, specifying the legal basis and the expected retention period.  International Transfers and Model Clauses Where a SaaS vendor or its sub-processors transfer personal data outside the UK, the DPA must address the applicable transfer mechanism, whether the UK's International Data Transfer Agreement (IDTA), an adequacy decision, or another safeguard.

The DUAA does not fundamentally alter the transfer framework, but it reinforces the requirement that transfers be documented and that the controller retains oversight.


Model clause:
The Processor shall not transfer personal data outside the United Kingdom unless (a) the transfer is to a country subject to an adequacy decision, or (b) appropriate safeguards are in place (including the UK International Data Transfer Agreement or UK Addendum to EU SCCs), or (c) a derogation under Article 49 of the UK GDPR applies.  The Processor shall maintain a current register of all sub-processors and transfer destinations, available to the Controller on request.

Complaint-Handling and Operational Obligations, What to Include in SaaS Data Processing Agreements (UK) The complaint handling process requirements that became effective on 19 June 2026 require organisations to provide clear, accessible routes for individuals to raise data-protection complaints and to ensure those complaints are investigated and resolved within reasonable timescales.  For SaaS deployments, this creates a dual obligation: the buyer (as controller) must maintain a front-facing complaints procedure, and the vendor (as processor) must support the buyer's ability to investigate and respond.

Contractually, this means the DPA should specify:

First-response obligations. Which party acknowledges the complaint, and within what timeframe? The ICO expects acknowledgement without undue delay.
Investigation cooperation. The vendor must provide logs, access records, and technical information necessary for the buyer to investigate the substance of the complaint.
Escalation triggers. Define when a complaint must be escalated, for example, where it involves a potential data breach, a subject-access request, or a regulatory enquiry.
Cost allocation. Routine cooperation should be included in the service fee. Complex investigations or regulatory responses should be addressed in a separate cost schedule.
Record-keeping. Both parties should maintain logs of complaints received, actions taken, and outcomes, these records are essential for demonstrating accountability to the ICO.

The likely practical effect of these requirements is that SaaS vendors will need to build complaint-handling workflows into their platforms or operational procedures, rather than treating data-protection complaints as ad hoc escalations. Buyers should insist on contractual SLAs for complaint-related cooperation, mirroring the approach already used for uptime and incident-response commitments.
Cookies, PECR and Consent, Allocating Risk in SaaS Data Processing Agreements (UK)
The Privacy and Electronic Communications Regulations (PECR) impose specific obligations on the use of cookies and similar tracking technologies. For SaaS platforms that embed analytics, advertising pixels, or session-management cookies in the buyer's customer-facing services, the question of who bears PECR liability is both commercially significant and frequently under-negotiated.
Cookie consent changes in 2026 reflect a continuing trend of increased ICO enforcement attention. PECR fines in the UK can be substantial, and the ICO has demonstrated willingness to take action against both controllers and the entities that deploy tracking technologies on their behalf.
Key contractual provisions to include:

Consent tooling. Specify which party is responsible for deploying and maintaining the consent management platform (CMP). If the vendor operates the CMP, the vendor should warrant that it meets ICO standards.
Evidence retention. The vendor should retain auditable records of consent (including timestamps, consent text, and user choices) for a minimum period aligned with the applicable limitation period.
Cookie inventory. The vendor should maintain and update a register of all cookies and similar technologies deployed through the platform, and notify the buyer of any changes before deployment.
PECR indemnity. Allocate liability for PECR breaches based on fault: where the vendor deploys tracking technologies without adequate consent mechanisms, the vendor should indemnify the buyer against resulting fines, costs, and claims.

Model clause (shared responsibility):
The Processor shall maintain a consent management platform that meets ICO guidance on cookie consent.  The Processor shall not deploy cookies or similar technologies through the Service beyond those specified in Schedule [X] without the Controller's prior written approval.  Each party shall indemnify the other against losses arising from its own breach of PECR, including regulatory fines, to the extent permitted by law.  Penalties, Regulatory Cooperation and Indemnity Mechanics Regulatory fines under the UK GDPR can reach up to £17. 5 million or 4% of annual worldwide turnover, whichever is higher.  PECR fines are subject to separate limits.

The ICO has the power to impose fines on both controllers and processors directly, which means that contractual indemnities do not eliminate regulatory exposure, they only allocate the economic burden between the parties after the fact.

When drafting indemnity provisions in SaaS data processing agreements, parties should consider:

Regulatory fines may not be insurable. Industry observers note that many cyber-insurance policies exclude regulatory penalties from coverage. Parties should verify insurability before relying on insurance as a contractual backstop.
Carve-outs from general caps. Data-protection liabilities are frequently carved out of the general limitation of liability clause, or subject to a separate, higher sub-cap (commonly 200–400% of annual fees).
Mitigation obligations. Both parties should be required to take reasonable steps to mitigate losses, cooperate with regulatory investigations, and preserve evidence.
Criminal liability. Certain offences under the Data Protection Act 2018 carry criminal penalties. These cannot be indemnified by contract and should be addressed through operational compliance rather than contractual allocation.

The strongest commercial position for buyers is to insist on a mutual obligation to maintain minimum cyber-insurance cover (specifying a floor amount) and to require vendors to provide evidence of coverage annually. This does not eliminate risk, but it provides a practical recovery mechanism that supplements contractual indemnities.
Transition Checklist and Negotiation Playbook
Use this SaaS contract checklist to coordinate your internal update programme and prepare for counterparty negotiations.

Audit all active DPAs and identify those that pre-date 5 February 2026, prioritise these for immediate review.
Map each DPA against the clause-by-clause checklist above and flag gaps (missing complaint-handling provisions, outdated lawful-basis schedules, absent PECR allocation).
Prepare redline amendments for each DPA. Use the model DPA clauses provided as starting points, adjusting for commercial context.
Engage internal stakeholders, information security, procurement, privacy, and commercial teams, and assign clause ownership.
Issue amendment proposals to counterparties with a clear cover note explaining the legal basis for each change (cite the DUAA and ICO guidance).
Negotiate disputed provisions using the buyer/vendor positions outlined above. Identify your walk-away thresholds on liability caps, indemnities, and sub-processor controls.
Where a vendor refuses material amendments, assess commercial alternatives: parallel vendor evaluation, insurance mitigation, or exit/transition triggers.
Update privacy notices and complaint-handling procedures in parallel, contractual updates alone are insufficient if operational processes do not reflect the new obligations.
Train customer-facing teams on the complaint-handling process and data-access request procedures.
Implement a review schedule, revisit DPAs at least annually and whenever the ICO issues new guidance or enforcement decisions relevant to SaaS processing.
Maintain a central register of all DPA versions, amendment dates, and counterparty responses for accountability and audit purposes.
Report completion status to the board or data protection officer, document the organisation's position on any residual risks where vendor negotiations are ongoing.

Timeline of Key UK Data Law 2026 Compliance Dates



Date
Legislative Event
Contract Action Required




5 February 2026
Data Use and Access Act (DUAA) came into force
Insert DUAA-specific definitions and data-access response obligations in DPAs; confirm and document lawful-basis allocation for each processing activity.


19 June 2026
Complaint-handling provisions took practical effect
Add complaint-handling process clauses with SLA timelines, escalation triggers, and cost-allocation provisions to all active DPAs.


Ongoing (2026+)
ICO guidance updates, PECR enforcement activity
Include a flexible "regulatory update" clause requiring vendor cooperation with evolving ICO guidance; review cookie/PECR allocation annually.



Sector Examples, Special Considerations for SaaS Data Processing Agreements
Fintech and Payment Platforms
Fintech SaaS vendors process high volumes of sensitive financial and identity data. Data-access requests under the DUAA may intersect with Financial Conduct Authority (FCA) regulatory obligations and open-banking data-sharing requirements. DPAs in this sector should include express provisions addressing multi-regulator cooperation, ring-fenced processing environments, and accelerated breach-notification timescales reflecting the FCA's own reporting expectations alongside the ICO's 72-hour window.
Healthcare and Life Sciences
Cloud-based electronic health record systems and clinical-trial platforms process special-category data subject to enhanced protections under the UK GDPR. Complaint-handling procedures must accommodate NHS-specific governance frameworks, Caldicott Guardian oversight, and the Data Security and Protection Toolkit. DPAs should include explicit data-minimisation obligations, purpose-limitation schedules tied to specific research protocols, and provisions addressing patient-access requests that may be channelled through NHS trusts rather than directly to the SaaS vendor.
Multi-Tenant SaaS (General Commercial)
Standard multi-tenant SaaS platforms face unique challenges in isolating complaint-handling and data-access obligations across customers. Early indications suggest that vendors in this space are moving towards standardised DPA addenda that provide a baseline level of DUAA compliance, supplemented by customer-specific schedules for processing scope, sub-processor lists, and liability thresholds. Buyers should resist "take-it-or-leave-it" addenda and negotiate material provisions, particularly on liability caps and sub-processor oversight, before acceptance.
Conclusion, Updating Your SaaS Data Processing Agreements for UK Compliance
The UK's 2026 data law changes are not a distant compliance horizon, they are in effect now.  Every SaaS data processing agreement in the UK that was drafted before 5 February 2026 requires review, and those that do not yet address the complaint-handling obligations effective since 19 June 2026 are immediately non-compliant.  The three priority actions remain the same: update lawful-basis mapping and DUAA cooperation clauses, insert complaint-handling process provisions with enforceable SLAs, and reallocate PECR and cookie liability with appropriate indemnity mechanics.  Organisations that complete these updates now will be better positioned to satisfy ICO accountability expectations, manage vendor relationships effectively, and avoid the contractual disputes that inevitably follow regulatory enforcement.
A qualified data privacy lawyer can provide bespoke redlines tailored to your specific SaaS architecture and commercial position, the model clauses in this article provide a starting framework, but sector-specific and transaction-specific advice is essential for full compliance.

Need Legal Advice?
This article was produced by Global Law Experts. For specialist advice on this topic, contact Nigel Miller at Fox Williams LLP, a member of the Global Law Experts network.


Sources

Data Use and Access Act, legislation.gov.uk
Data Protection Act 2018 / UK GDPR, legislation.gov.uk
ICO, What needs to be included in the contract between controllers and processors
Information Commissioner's Office, guidance on complaints and data subject rights
ICO, Guide to PECR (cookies and electronic communications)
ICO, Enforcement and fines: action taken