GDPR and Software Licensing:
Data Processing Terms to Negotiate

Why GDPR Data Terms in Software Contracts Require Dedicated Negotiation

Enterprise software contracts are simultaneously commercial agreements and data processing arrangements. Every SaaS platform that processes personal data — employee records in Workday, customer data in Salesforce, support tickets in ServiceNow, HR files in SAP SuccessFactors — operates under a data controller/data processor relationship that GDPR regulates. The commercial procurement team negotiates the licence terms; the Data Protection Officer or legal team negotiates the Data Processing Agreement (DPA). In most organisations, these two processes happen sequentially and independently — and the disconnection creates risk. A contract negotiated on commercial terms may contain data processing provisions that are incompatible with GDPR requirements, or that grant the vendor rights over your data that the DPO would never have approved.

The intersection of GDPR and software licensing data processing terms has become significantly more complex in 2025–2026 due to one factor: AI. Virtually every major enterprise software vendor has introduced generative AI capabilities — Salesforce Einstein, ServiceNow Now Assist, Microsoft Copilot, SAP Joule, Oracle AI — and the training and improvement of these models requires data. The vendors' legal teams have, in many cases, updated their standard terms to grant broad AI training rights over customer data, often buried in DPA schedules or product-specific terms. The 83% figure — the proportion of enterprise SaaS agreements containing such provisions — reflects how quickly and broadly this change has propagated. For broader context on contract red lines across all term categories, our enterprise software contract red lines guide identifies the 20 terms most frequently subject to dispute.

Data Processing Agreements: What a GDPR-Compliant DPA Must Contain

Under Article 28 of GDPR, processing by a processor must be governed by a contract that sets out specific mandatory elements. These are not optional in vendor-provided DPAs — they are legal requirements. Any DPA that is missing one of these elements creates direct GDPR non-compliance risk for the data controller (the enterprise), regardless of whether the vendor is to blame. The mandatory elements include: the subject matter, duration, nature, and purpose of processing; the type of personal data and categories of data subjects; the obligations and rights of the controller; and provisions covering sub-processing, data subject rights assistance, security measures, deletion or return of data, and audit rights.

In practice, vendors routinely provide DPA templates that are GDPR-compliant in structure but commercially favourable to the vendor in specifics. The most common deviations are broad sub-processor lists (allowing the vendor to use any sub-processor without prior notice), weak deletion commitments (data retained for vendor operational purposes after termination), and audit rights limited to questionnaires rather than genuine on-site audits. None of these deviations make the DPA non-compliant on its face — but they do reduce the enterprise's practical ability to enforce its data protection obligations. For the enterprise's commercial and legal team working together, the DPA negotiation should be a joint exercise: the commercial terms and the data terms create a single risk profile that should be evaluated holistically.

AI Training Rights: The Clause Your Legal Team Must Review Before Signing

The most commercially significant new data term in enterprise software contracts is the AI training rights clause. These clauses typically appear in one of three forms. The broadest form grants the vendor the right to use customer data to train, improve, and develop AI and machine learning models — full stop. The middle form excludes identifiable personal data but permits use of aggregated or anonymised data. The narrowest form restricts use to improving the specific customer's experience within their own instance, prohibiting cross-customer model training.

From a GDPR perspective, the first form is generally incompatible with the data controller's obligations. If an enterprise's HR data is being used to train a vendor's general-purpose AI model, the lawful basis for that processing must be identified, data subjects must be informed, and the purpose must be compatible with the original processing purpose for which the data was collected. In most cases, none of these conditions are met — which means the enterprise is operating outside the scope of its own privacy notice and potentially in breach of GDPR. Salesforce's 2024 DPA update and Microsoft's Copilot data governance terms are two examples where enterprise customers have needed to negotiate AI training restrictions specifically. Redress has assisted 18 clients in negotiating explicit AI training opt-outs from SaaS agreements in 2025.

The practical negotiation position is straightforward: insist on the narrowest form of AI training rights as the default, with a documented opt-in mechanism if the enterprise chooses to contribute data to broader model training. This is negotiable with all major vendors — Salesforce, ServiceNow, Microsoft, and Workday all have contractual provisions for this. The leverage is GDPR compliance: the vendor cannot force the enterprise to process data unlawfully. For a broader view of what should be non-negotiable in any enterprise software agreement, see the FinOps enterprise software governance framework, which covers data governance as part of the broader software management discipline.

Data Portability on Termination: What You Can — and Cannot — Extract

Data portability — the right to receive your data in a machine-readable format when you terminate a software contract — is both a GDPR right (under Article 20, for data subjects) and a commercial provision (typically in the DPA or order form) that governs the enterprise's ability to extract its own operational data. These two concepts are often conflated, and the distinction matters. Article 20 GDPR gives data subjects (your employees, customers, users) the right to receive their personal data in a structured, commonly used, machine-readable format. This is a data subject right, not a customer right — the enterprise cannot waive it on behalf of data subjects.

The commercial data portability provision governs what the enterprise can export from the vendor's platform: configuration data, transaction records, custom-developed content, analytical outputs, and historical records. Vendors with high lock-in strategies — Salesforce and ServiceNow are the most prominent examples — limit this provision in standard contracts. Salesforce's standard agreement allows data export but limits the format to CSV for most objects; complex relational data, metadata configurations, and custom app logic cannot be exported in a format usable on another platform without significant re-engineering cost. ServiceNow's data model is similarly proprietary. Our analysis in the software licensing M&A due diligence guide covers how these portability limitations create exit cost in acquisition scenarios.

The negotiation objective is a data portability provision that guarantees: export in an open, structured format (not only vendor-proprietary); export of all data categories including configuration, metadata, and custom objects; a transition assistance period (typically 90–180 days post-termination) during which the vendor provides the former customer with read access to assist migration; and prohibition on data deletion during the transition period. These terms are negotiable — but not from standard contracts. They must be explicitly requested and added via an Order Form or supplemental agreement at time of initial contract or renewal. Book a confidential call to discuss your specific vendor situation with our contract advisory team.

EU-US Data Transfer Mechanisms: What Changed and What You Must Update

The legal basis for transferring personal data from the EU to the US — and for enterprise software this is relevant for every US-headquartered SaaS vendor — has been revised multiple times since the original Safe Harbour was invalidated in 2015. The current framework as of 2025 is the EU-US Data Privacy Framework (DPF), adopted in July 2023. Standard Contractual Clauses (SCCs) remain valid as an alternative basis and are the mechanism most commonly used in enterprise software DPAs.

The risk is not which mechanism is used — both DPF and SCCs are currently valid — but whether the enterprise has conducted a Transfer Impact Assessment (TIA) to verify that the mechanism provides adequate protection for the specific type of data transferred to the specific vendor. Data Protection Authorities in Germany, France, and the Netherlands have issued guidance requiring TIAs for all major US SaaS vendors, and enforcement actions citing inadequate transfer documentation are increasing. The enterprise's DPA with each vendor should explicitly identify the transfer mechanism and include a current, completed TIA addendum. Most vendor standard DPAs do not include a TIA — this must be requested and documented separately. For organisations that process sensitive data categories (health, financial, HR), the TIA obligation is particularly acute.