Enterprise customers' legal teams send you their standard DPA — heavily negotiated, often one-sided, and written as if you are a potential liability rather than a trusted technology partner. Navigating these negotiations efficiently, without giving away more than required and without losing the deal, is a skill that compounds over time. This article explains how to approach the most common GDPR negotiation points.
The Negotiation Dynamic
Enterprise customers have leverage: they are the controller, they set the regulatory standard, and your DPA must satisfy their compliance obligations. But enterprise legal teams are often working from a template that overreaches what GDPR actually requires. Many of the positions in a standard enterprise DPA are negotiating positions, not regulatory requirements.
Your goal: agree on genuinely required provisions quickly, push back efficiently on provisions that exceed GDPR requirements or are operationally unworkable, and avoid making every clause a protracted argument.
The Standard Enterprise DPA Positions and How to Respond
Liability Position
What they send: Unlimited liability for data breaches, or a liability cap that applies to the main contract but with data protection liability carved out entirely and uncapped.
What GDPR requires: Nothing specific on contractual liability. Article 82 creates a GDPR liability framework for data subjects, not a specific controller-processor liability structure.
How to respond: Propose a cap tied to a multiple of fees paid in the preceding 12 months — typically 2× to 5× depending on deal size and data sensitivity. Agree to a carve-out for breaches caused by your wilful misconduct or gross negligence. Push back on unlimited liability for ordinary data incidents.
Sub-Processor Approval
What they send: Specific authorisation required for each sub-processor. Customer has absolute right to object to any sub-processor and veto use.
What GDPR requires: General or specific authorisation from the controller (Article 28(2)). If general authorisation is used, the processor must inform the controller of changes and allow an opportunity to object.
How to respond: Propose general authorisation for your current sub-processor list (attached as a Schedule), with 30-day advance notice of changes and a right for the customer to object with reasonable cause. Distinguish between changes to core infrastructure sub-processors (AWS, Google) — where objection rights are commercially impractical — and changes to sub-processors who access the customer's specific data.
Audit Rights
What they send: Unlimited right to audit at any time, no notice required, customer can bring any number of third-party auditors.
What GDPR requires: Audit rights must exist. The DPA must allow the controller to conduct audits (Article 28(3)(h)).
How to respond: Accept audit rights with 30-day advance notice, limited to once per calendar year (except following a material security incident), with scope limited to the services and data relevant to the customer's processing. Offer ISO 27001 certificate and SOC 2 report as an alternative to on-site audit for standard reviews, with on-site audit available for cause.
Data Deletion
What they send: Deletion within 7 days of contract termination, with certification. Deletion applies to all copies including backups. Audit logs and records must be deleted immediately.
What GDPR requires: Delete or return all personal data at the end of the services and delete existing copies (Article 28(3)(g)), unless retention is required by Union or member state law.
How to respond: Accept deletion within 30 days of contract termination. For backups: accept deletion of backups within the backup retention cycle (typically 30–90 days for standard backup systems). Accept certification of deletion on request. Flag where statutory retention obligations (tax records, legal holds) may require retention of certain data — and propose a carve-out for data subject to legal hold.
International Transfers
What they send: No transfers outside the EEA without prior written consent. Or: EU SCCs required for all transfers, any transfer not covered by an adequacy decision must be pre-approved.
What GDPR requires: Appropriate safeguards for transfers outside the EEA (Article 46). SCCs, DPF certification, or other mechanisms satisfy this.
How to respond: Accept the SCCs as the primary mechanism. Confirm your DPF certification where applicable for US sub-processors. Provide a Transfer Impact Assessment (TIA) for major non-EEA sub-processors. Push back on pre-approval requirements — this is operationally unworkable for sub-processors serving global infrastructure.
Provisions That Are Genuinely Non-Negotiable
Some enterprise positions are not negotiating stances — they reflect actual GDPR requirements or sector-specific regulatory obligations:
DORA Article 30 clauses for financial services customers: These are legally mandated. Do not attempt to negotiate away audit rights, incident notification timelines, or exit assistance provisions for financial services customers.
UK GDPR addendum: For customers with UK operations, the UK GDPR addendum or IDTA is a genuine legal requirement, not a preference.
Transfer mechanism documentation: If your service involves cross-border transfers, providing the appropriate mechanism (2021 SCCs, current DPF certificate) is not optional.
Accelerating Negotiations: The Mutual DPA Approach
If you have your own compliant DPA that covers all Article 28 requirements, propose using it as the base document rather than the customer's template. This approach:
- Starts negotiation from a compliant baseline
- Gives you home-field advantage on the structure
- Reduces the number of items to negotiate (your template should not include the overreaching positions that enterprise templates routinely include)
Customers' legal teams are often willing to work from a vendor template if it is clearly professional and comprehensive. Have your DPA ready in a clean, well-structured format before the negotiation starts.