Negotiating Data Processing Agreements: Customer And Vendor Perspectives

In a recent blog post, my colleague Mark Johnson examined how companies structure data protection obligations in vendor contracts, focusing on key provisions that allocate risk and define how personal data is handled in practice. One of the primary mechanisms used to address those obligations is the Data Processing Agreement (or Addendum) (DPA)

In some commercial relationships, a DPA is not simply good practice, but a specific legal requirement¹ when one party processes personal data on behalf of another under applicable privacy laws.

At the same time, DPAs have increasingly become a standard feature in many commercial agreements involving personal data, even when not strictly required by law. Their value extends beyond compliance, functioning as both operational frameworks and key risk-allocation tools to help define:

• how data is handled,
• which party is responsible for specific compliance obligations,
• what happens if a security incident occurs, and
• how those obligations align with each party’s actual operational capabilities.

Customer and Vendor Perspectives in DPA Negotiations

Typically, the customer acts as the “controller” and the vendor acts as the “processor,” handling personal data on the customer’s behalf and subject to the customer’s instructions. As a result, a standard DPA tends to focus mostly on the vendor’s obligations.

While both parties generally share an interest in protecting personal data, they often approach DPA negotiations from very different operational, commercial, and risk-management perspectives.

Customers may prioritize oversight, accountability, and downstream compliance obligations, while vendors often focus on scalability, operational flexibility, and aligning contractual commitments with existing infrastructure and internal processes.

The issues below are some of the most frequently negotiated provisions in a DPA and reflect common positions taken around operational responsibility, incident management, and risk allocation:

1. Is It the Right Template?

When reviewing a proposed DPA, parties often evaluate whether the agreement appropriately reflects the underlying relationship and the actual processing activities involved.

Customer Perspective

Customers frequently focus on whether the DPA adequately addresses the vendor’s obligations relating to the handling, security, and processing of personal data. If the template places a substantial emphasis on customer obligations (beyond mere representations regarding data-sharing rights), such as restrictions on the type of data uploaded, or customer data security obligations, it may not be a typical DPA.

Vendor Perspective

Vendors often focus on whether the DPA accurately reflects their role as processor and aligns with their existing compliance program, operational practices, and technical capabilities. Vendors may also evaluate whether the agreement introduces obligations beyond those required under applicable privacy laws, a sign that the template is more a generic security addendum or other risk-shifting document.

2. Scope

Scope provisions generally determine which data, processing activities, and jurisdictions are subject to the DPA; however, at a minimum, personal data is covered.

Customer Perspective

Customers often prefer broader applicability covering all relevant jurisdictions (not just the data of EU residents). This is particularly important as more U.S. states pass their own privacy legislation (e.g., CCPA in CA). A DPA that is subject to all applicable laws in all applicable jurisdictions helps to ensure that the agreement remains workable across multiple privacy-law frameworks. In addition, customers may prefer coverage not only for processing of personal data, but also, processing of more broadly defined confidential information.

Vendor Perspective

Vendors often seek to limit the DPA to processing activities involving “Personal Data,” as such is defined under applicable privacy laws, rather than broader categories of customer data or confidential information. That tends to keep the DPA focused only on data that triggers specific statutory obligations and avoids importing those heightened obligations beyond what is legally required. Vendors may also wish to ensure that only applicable laws are referenced in the DPA (e.g., GDPR or CCPA), as opposed to “all privacy laws in all jurisdictions.”

3. Notice & Timing

Incident notification provisions frequently receive significant attention during DPA negotiations. It is important to note that different laws set different minimum timelines and audiences for notification. For example, GDPR generally requires notice to the supervisory authority “without undue delay” and, where feasible, within 72 hours of becoming aware of a personal data breach, while U.S. state breach-notification laws and specify their own timeframes.

Customer Perspective

Customers prefer prompt notice of security incidents, and that “Security Incidents” are broadly defined to include both actual and suspected breaches or even attempted breaches. Early notice (e.g., within 24-48 hours of discovery) allows time to properly evaluate their own downstream legal, contractual, operational, and regulatory obligations. Customers may also wish to clarify that vendor obligations under the DPA are in addition to, not in lieu of, any applicable statutory notification duties they may have. Note that, if Vendor does not have to notify of merely “suspected” breaches, customers may wish to add a short timeframe (e.g., 1-2 days) for vendor’s diligence to determine whether or not it was an actual breach.

Vendor Perspective

Since vendors are obligated to provide notice of security breaches, it is important that the DPA clarify define “Security Incident.” Vendors prefer a tighter definition, only requiring notice of actual data breaches, not mere attempts nor suspected breaches that have not yet been confirmed. Vendors often focus on ensuring notification timelines align with their own internal incident-response processes. For example, do proposed timelines allow sufficient opportunity to assess scope, materiality, and whether an incident has actually occurred? Ideally, this obligation is limited to incidents that have been confirmed as meeting the applicable legal or contractual threshold.

4. Location

Data location and cross-border transfer provisions often affect operational and compliance considerations.

Customer Perspective

Knowing where personal data will be stored, accessed, and processed (e.g., in the U.S., EU/UK, or multiple regions) is often important for customers, to enable them to comply with their own legal obligations. Where GDPR (or UK GDPR) applies and data is transferred outside the EU/UK, additional cross-border transfer requirements and related compliance obligations may also be implicated. As a result, customers often seek to know and pre-approve the countries where data may be stored or processed at all during the relationship.

Vendor Perspective

Maintaining operational flexibility across existing infrastructure, data-center environments, and subprocessor ecosystems is usually a vendor priority. It is also important for vendors to ensure alignment between contractual obligations in a DPA and current operational practices. As a practical matter, when vendors are using third parties to host, such as AWS or GCP, the vendor might not always know all the locations of all the processing, or, at the very least, it may be more difficult logistically to get prior approval.

5. Data Use

Permitted-use provisions can be used to address how personal data may be used beyond core service delivery.

Customer Perspective

Customers usually seek to limit vendor use of their data to the processing activities associated with providing the contracted services. They may also wish to evaluate whether broader vendor rights could implicate vendor uses that are inconsistent with their own internal privacy expectations or customer commitments.

Vendor Perspective

Vendors typically seek to clarify the rights to use the data, not only as necessary to provide the services, but also as permitted in the Agreement, as instructed by the controller, plus the right to use aggregated, anonymized, or de-identified information for analytics, service improvement, benchmarking, product development, or related operational purposes where legally permissible.

6. Remediation

One of the most important provisions in a DPA, remediation addresses how the parties will respond to security incidents and related operational issues.

Customer Perspective

Customers commonly focus on clarifying the vendor’s responsibilities in the event of a security incident, including investigation, mitigation, remediation, and related obligations, Likewise, they prefer that vendors bear the cost of remediation, as well as the responsibility for ensuring ongoing corrective action is taken. Customers may prefer vendors go beyond the mere minimum remediation legally required, and also act in accordance with broader industry standard remediation efforts.

Vendor Perspective

Vendors typically focus on ensuring that a DPA’s remediation obligations align with their internal incident-response procedures, operational capabilities, insurance structures, and internal escalation processes. Vendors typically prefer their remediation obligations are only at their expense to the extent they were at fault, and that they only are obligated to remediate to the extent the law requires, without taking optional or voluntary steps desired by the customer — even if those steps might be industry best practices (such as credit monitoring for affected Data Subjects).

7. Subprocessors

The use of subprocessors is specifically addressed under GDPR, which requires a processor/vendor to obtain the controller/customer’s prior written authorization before engaging a subprocessor. That authorization can be either (i) specific where the controller approves each subprocessor individually in advance, or (ii) general, where the controller provides standing authorization subject to prior notice and an opportunity to object to proposed changes.

These requirements often shape negotiations around three practical sub-issues:

a) authorization structure: specific vs. general
b) definition and scope of “Subprocessor”
c) notice and objection procedures

Customer Perspective

Customers typically prefer:

a) specific authorization for critical or high-risk subprocessors, while in some cases accepting general authorization when coupled with advance notice, objection rights, and defined remedies where concerns arise;

b) broader definitions of “subprocessors” encompassing all entities that access or process personal data within the scope of services; and

c) where general authorization is permitted, meaningful notice and objection procedures, including advance written notice, reasonable objection periods, and clearly defined remedies (e.g., suspension, reconfiguration, termination).

Vendor Perspective

Vendors often seek:

a) general authorization supported by advance notice procedures and maintained lists of subprocessors;

b) definitions of “Subprocessor” tied to material processing standards, while excluding incidental or commodity providers (e.g. email, telecom or office software vendors); and

c) operationally scalable notice and objection procedures model under which customer consent may be deemed given absent a timely objection, coupled with defined consequences in the event of an objection.

8. Indemnity

Indemnity provisions address the allocation of responsibility for losses arising from security incidents or DPA-related claims. See also #6 (Remediation) above for more on what each party usually expects the vendor to pay for. Each party’s preferences for indemnity scope often tracks that same perspective.

Customer Perspective

Customers frequently seek broader indemnification provisions covering damages, costs or expenses arising from security incidents or alleged DPA breaches. These provisions may address mitigation and remediation expenses, notification obligations, and the costs associated with credit monitoring and other response measures.

Vendor Perspective

Where indemnification provisions already exist in the MSA or related commercial agreements, vendors often evaluate whether additional DPA-specific indemnities are necessary in the context of broader issues (e.g., contractual risk allocation, insurance coverage, and the scope of potential exposure from security and privacy incidents).

9. Limitation on Liability / Liability Caps

Liability-cap provisions often work in tandem with indemnification obligations and reflect broader commercial risk-allocation discussions between the parties.

Customer Perspective

Customers may seek uncapped liability or elevated “super caps” for privacy or security-related obligations, particularly where a significant incident could create exposures disproportionate to the value of the underlying deal. Discussions tend to focus on whether the negotiated cap appropriately reflects the potential operational, financial, and regulatory impact of a data breach.

Vendor Perspective

Vendors often focus on maintaining consistency with liability structures already negotiated in the MSA, including super caps or other negotiated risk-allocation mechanisms. At the risk of stating the obvious, vendors prefer lower super cap amounts for vendor’s liability for data breaches.

10. Definitions

Defined terms are not always standard. In many cases, they can shape the scope and operational impact of the DPA. Key definitions include “Security Incident,” and “Personal Data.”

Customer Perspective

As discussed in the context of other provisions, customers typically seek broadly defined terms, or at least language that provides operational clarity to otherwise vague legal descriptions. For example. Customers may try to use a term such as “Customer Data” instead of “Personal Data” throughout the DPA, inclusive of its confidential information.

Vendor Perspective

Vendors, on the other hand, prefer that a DPA’s definitions track closely with existing obligations under applicable law.

Why These Provisions Matter in Practice

As a practical matter, DPA obligations can directly affect:

• incident response workflows and escalation timelines
• vendor onboarding and subprocessor management
• customer commitments and downstream contractual obligations
• cross-border data transfers and infrastructure decisions
• product functionality, analytics, and service improvement practices
• regulatory exposure and allocation of remediation responsibilities

Ultimately, the most effective DPAs are not necessarily the most aggressive or the most restrictive. They are the agreements that realistically align legal obligations with operational capabilities, technical infrastructure, governance processes, and the practical realities of how services are delivered and supported over time.

Footnote

1 The EU/UK General Data Protection Regulation (GDPR), the California Consumer Privacy Act as amended by the California Privacy Rights Act (CPRA), the Virginia Consumer Data Protection Act (VCDPA) are among a growing list of comprehensive privacy laws requiring a DPA whenever personal data is being processed on another party’s behalf.

GC provides outside general counsel services to companies of all sizes, offering project-based support, subject-matter expertise, and day-to-day GC services through a team of partner-level business attorneys. For more information visit: Outside General Counsel Corporate Legal Services.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.