A Vendor Asked for Our DPA: What to Send

Q: Do we need a DPA if we only have US customers?

Often yes. CCPA and other US state privacy laws ( Virginia , Colorado , Texas , and more) require service provider or processor contracts, and HIPAA requires Business Associate Agreements. These obligations attach to the data you handle and the customers you serve, regardless of where your company is based.

Key takeaways

A Data Processing Agreement is a contract required under GDPR Article 28 between a controller and a processor (or a processor and a sub-processor) governing how personal data is processed.
Your first question is whether you are the controller or the processor in the relationship, because the DPA terms and obligations differ based on which role you are in.
When a customer sends you their DPA as a processor, read the whole document and counter problematic clauses on audit rights, sub-processor approval, breach notification timing, indemnification, and data return.
When a vendor sends you their DPA as a controller, verify it covers the Article 28(3) topics, sub-processor disclosure, breach notification, audit rights, and data return and deletion.
DPA review, drafting, and negotiation is a core part of our outsourced DPO services, and for non-clients with a single stuck negotiation we engage on a focused project basis.

What a DPA actually is

A Data Processing Agreement is a contract required under GDPR Article 28 between a controller and a processor (or between a processor and a sub-processor). It governs how personal data is processed in the relationship.

Article 28(3) requires the DPA to address:

The subject matter, duration, nature, and purpose of the processing
The type of personal data and categories of data subjects
The obligations and rights of the controller
The processor’s commitments on confidentiality, security, sub-processors, data subject rights assistance, processor support for controller obligations, return or deletion of data, and audit cooperation

Some jurisdictions and regulatory frameworks add their own DPA-equivalent requirements. CCPA and other US state privacy laws (Virginia, Colorado, Texas, and more) require service provider or processor contracts. HIPAA requires Business Associate Agreements. UK GDPR has its own variant, and comparable processor-contract rules appear in Brazil, Canada, China, and beyond. These requirements can reach you wherever your company is based if you process data for, or share data with, organizations serving people in the EU or UK, not only European companies.

Are you controller or processor

The first question is whether you are the controller or the processor in this relationship.

Controller. You determine the purposes and means of processing. If you collected the data and are using it for your own purposes, you are typically the controller.

Processor. You process personal data on behalf of a controller, following their instructions. SaaS vendors are typically processors for their customers’ data, even though they may be controllers for other data.

Joint controller. Two parties jointly determine purposes and means. Less common but real (often in advertising and analytics contexts).

The DPA terms differ based on which role you are in. A processor signing as processor accepts certain obligations. A controller signing as controller accepts different obligations.

What to do when a customer sends you their DPA

If you are the processor and a customer has sent you their DPA:

Read the whole document. Most DPAs follow a similar pattern but variations matter. Look for unusual terms in sections on liability, sub-processors, audit, data return, and breach notification.
Identify problematic clauses. Common issues:
- Unlimited audit rights. Customers sometimes demand the right to audit the processor at any time. Counter with reasonable audit frequency (typically annual or in response to specific incidents) and reasonable scope.
- Aggressive sub-processor approval. Customers sometimes demand prior written approval for every sub-processor change. Counter with notice-and-objection model (30 days notice, customer can object, you can decline to use that customer if they reject sub-processors you need).
- Unreasonable breach notification timing. Customers sometimes demand notification within 24 hours of any incident. Counter with notification without undue delay consistent with GDPR Article 33.
- Broad indemnification. Customers sometimes demand indemnification for any privacy issue. Counter with indemnification tied to your processor obligations specifically, capped at reasonable amounts.
- Unrealistic data return timing. Customers sometimes demand data return within 24 hours of contract termination. Counter with reasonable timing (typically 30 days) and clear data destruction obligations after that.
Decide what to push back on. Not every customer DPA term is worth fighting. Focus on terms that materially affect your operations, your liability, or your ability to serve other customers.
Propose your standard DPA or red-line theirs. The strongest position is having your own DPA template that you propose. The second-strongest is red-lining theirs with rationale for each change.

What to do when a vendor sends you their DPA

If you are the controller and your vendor sent you their DPA:

Verify it covers Article 28 requirements. The vendor’s DPA must address the Article 28(3) topics. If it does not, request additions.
Verify sub-processor disclosure. The vendor should disclose their sub-processors or commit to a process for disclosing them.
Verify breach notification commitments. The vendor should commit to notifying you of breaches affecting your data without undue delay with specific commitments about information provided.
Verify audit rights. You should have audit rights, either direct or via third-party attestations like SOC 2 reports.
Verify data return and deletion. The vendor should commit to data return or deletion at end of contract, with specific timing.
Identify red flags. Vendors sometimes try to add terms unfavorable to controllers including limitations on data subject rights assistance, broad processor discretion on sub-processors, or weak breach notification commitments.

When to engage your DPO

Most DPA negotiations can be handled by procurement or legal teams with a DPO providing review and guidance. Engage your DPO directly when:

The customer or vendor is large and the DPA terms will set precedent for future agreements.
The data involved is special category data (health, biometric, financial), increasing the stakes.
The other party is being aggressive on terms in a way that suggests they may not be operating in good faith.
The DPA includes specific terms you do not understand the implications of (Transfer Impact Assessment commitments, model clauses incorporation, jurisdiction-specific carve-outs).

How to be ready

Build a DPA template. Have your own template ready that you propose to customers. This puts you in the strongest negotiation position.

Have a sub-processor list ready. Publish your sub-processor list at a known URL so you can reference it in DPA discussions.

Standardize breach notification commitments. Have a standard breach notification SLA that you commit to consistently.

Document your security measures. Have a security overview document you can attach as a DPA exhibit.

How Engage Compliance helps

DPA review, drafting, and negotiation is a core part of outsourced DPO services. We provide:

DPA template drafting for clients without one.
DPA review when customers send theirs, with red-line recommendations.
DPA negotiation support during deal discussions.
Sub-processor list management.

For non-clients with a single stuck DPA negotiation, we engage on focused project basis.

Note: Outsourced DPO is also referred to as external DPO, virtual DPO, fractional DPO, or DPaaS. Local-language equivalents include externer Datenschutzbeauftragter (Germany), DPO externe (France), DPO esterno (Italy), DPD externo (Spain).

This page is general information, not legal advice.

Free risk assessment Book a free intro call

FAQ

Frequently asked questions

What is the first thing to figure out when asked for a DPA?

Whether you are the controller or the processor in the relationship, because the terms and obligations differ based on which role you are in. If you collected the data and use it for your own purposes you are typically the controller, while SaaS vendors are typically processors for their customers' data even if they are controllers for other data.

Should we just sign the customer's DPA?

Read the whole document first. Customer DPAs often contain unlimited audit rights, aggressive sub-processor approval, breach notification within 24 hours, broad indemnification, and unrealistic data return timing. Counter the clauses that materially affect your operations or liability, and the strongest position is proposing your own DPA template rather than red-lining theirs.

A customer wants breach notification within 24 hours. Is that standard?

It is aggressive. Counter with notification without undue delay, consistent with GDPR Article 33, rather than a fixed 24-hour commitment that may be operationally unrealistic. Focus your pushback on the terms that genuinely affect your liability or your ability to serve other customers.

What should we check in a vendor's DPA we receive?

Verify it covers the Article 28(3) topics, discloses sub-processors or commits to a disclosure process, commits to breach notification without undue delay, gives you audit rights either directly or via attestations like SOC 2 reports, and commits to data return or deletion at end of contract with specific timing.

Do we need a DPA if we only have US customers?

Often yes. CCPA and other US state privacy laws (Virginia, Colorado, Texas, and more) require service provider or processor contracts, and HIPAA requires Business Associate Agreements. These obligations attach to the data you handle and the customers you serve, regardless of where your company is based.