Vendor Data Processing Agreements: What to Review

A vendor DPA can cost you far more than legal review time. In the U.S., the average data breach hit $10.22 million in 2025, and vendor-related incidents averaged close to $5 million.

If I were reviewing a DPA before signature, I’d focus on seven points right away:

• Scope: what data, systems, and services the deal covers
• Use limits: whether the vendor can use data only for the service
• Security: what controls the vendor must keep in place
• Subprocessors: who else can access the data
• Transfers: where data is stored, processed, and backed up
• Breach terms: when the vendor must notify me and what it must share
• Deletion and liability: when data must be returned or erased, and who pays if things go wrong

I’d also make sure legal, security, and finance each review their part before anyone signs. That matters because a weak DPA can slow enterprise deals, leave breach costs on my side, and create uncapped privacy or confidentiality exposure.

Here’s the short version: I should not sign a vendor DPA unless it clearly limits data use, names subprocessors and transfer terms, sets fixed breach and deletion deadlines, and aligns liability with the actual risk.

That’s the lens I’d use for the rest of this review.

The Hidden Risk in Vendor Contracts | Data Processing Agreements Made Simple | Avoid GDPR Penalties

sbb-itb-e766981

What data and services does the DPA actually cover?

Start by checking whether the DPA lines up with the way data moves in real life: what gets sent, where it goes, why it's processed, and how long it's kept. Broad wording like “process data to provide services” leaves too much room. The agreement should match your actual data flows. Once that scope is nailed down, review the limits on use, sharing, and retention.

How to verify service scope, processing purpose, and duration

The DPA should name the exact service you bought, plus any add-ons that are in scope. It should tie back to the order form, statement of work, or service schedule that spells out what your company signed. It also needs to list the processing activities involved, such as collection, storage, analysis, or transfer.

Just as important, it should say which environments are covered: production, staging, test, backup, and disaster recovery systems. If the vendor has optional modules, the DPA should make clear which ones are covered today and how later additions get pulled in.

Purpose language is where a lot of DPAs drift into fuzzy territory. A solid clause keeps the vendor's use narrow, like delivering and maintaining the subscribed service. Then look hard at any secondary uses, including product improvement, benchmarking, or AI model training. For each one, the DPA should spell out whether personal data is used directly or only in aggregated, anonymized form, and whether you can opt out.

Retention deserves the same level of detail. Push for data to be deleted within specific written timelines for both active systems and backups. Open-ended phrasing like “retained as long as necessary” sounds fine until you try to enforce it.

Which data categories and data subjects should be listed

A well-built DPA usually includes an annex or schedule that lists both the data types and the groups of people involved. Data categories often include names, email addresses, phone numbers, account credentials, usage data, financial identifiers, and HR data. Data subjects should be named just as clearly: customers, employees, contractors, end users, or website visitors. Not just “users.”

A simple gut check helps here: can you match each listed data category to the system or workflow that creates it? If not, the schedule may be too vague.

If the vendor handles children's, health, biometric, or payment data, the DPA should say so directly and require the matching safeguard or a separate agreement.

What documented instructions and prohibited uses should say

The DPA should say in plain terms that the vendor processes data only under your documented instructions. Not outside them. Not based on its own reading of what's convenient. In practice, that instruction set usually includes the DPA, the services agreement, the order form, and implementation documents. If the vendor believes one of your instructions is unlawful, it should notify you promptly.

The agreement should also bar a few things outright:

• selling personal data
• combining your data with other clients' datasets to build commercial products
• re-identifying anonymized records
• using personal data to train general-purpose AI models

Each of those bans closes off a real risk: regulatory action, brand damage, or downstream liability that can pop up during a funding round or acquisition review. If this language is missing, soft, or vague, stop there and get the clause fixed before signing.

After scope and instructions are settled, move to the security, subprocessors, and transfer terms.

Which limits, safeguards, and transfer terms matter most?

The goal is simple: turn privacy promises into controls you can check for yourself.

How to review security controls and confidentiality obligations

Generic security language doesn't do much. A DPA should spell out the controls the vendor must keep in place, including encryption, access controls, logging, backup testing, and an incident response plan. And those controls shouldn't live on paper alone. You should be able to verify them through a SOC 2 report, a penetration test summary, a security questionnaire, or an audit right.^[6][7][8]

It's also smart to attach the vendor's technical and organizational measures as an annex. Then add a requirement that the vendor must notify you before it weakens any material control. That way, the list isn't just a snapshot. It becomes a live promise.

Confidentiality needs the same level of detail. Anyone who can access your data should be bound by written confidentiality duties. Access should be limited to people who need it to do their job, and the vendor should revoke access and notify you promptly if confidentiality is breached.^[9][2]

Once you know the vendor's own controls are in place, the next step is simple: find out who else may get near the data.

What to check in subprocessor and international transfer clauses

The DPA should include a current subprocessor list, prior notice before changes, and a 30-day window to object if you have documented security or compliance concerns.^[3][1] Each subprocessor agreement should also carry the same duties around security, confidentiality, breach notice, and deletion or return of data at the end of the contract.^[9][10]

Then look at where the data can go.

For international transfers, the DPA should name the countries or locations where data is stored and processed. "Global cloud" language is too vague. If the processing touches the EU or UK, the agreement should identify the transfer tool in use: adequacy, the EU-U.S. Data Privacy Framework, Standard Contractual Clauses, or a UK addendum. The EDPB has also said that when transfers happen between subprocessors outside the EEA, the processor acting as data exporter should document the legal basis, complete a transfer impact assessment, and keep supplementary safeguards in place.^{[11][10][12][5]}

If a vendor says your data stays in the U.S. only, get that promise in writing. And make sure it covers backups and support access too.

Clause comparison table: security, subprocessors, transfers, and confidentiality

Use the checklist below to compare clauses fast.

How should breach, deletion, audit, and liability terms be reviewed?

These clauses decide who pays, who acts, and what happens when things go wrong or the relationship ends. After scope, security, and transfer terms, move to the parts that govern incident response, offboarding, and legal exposure.

What breach notice and cooperation language should include

Start with the notice trigger. A weak clause waits until a breach is confirmed or deemed material. That gives the vendor too much room to wait. Instead, require notice for suspected or confirmed unauthorized access, disclosure, or loss within 24–48 hours of the vendor becoming aware of it, using the same data categories and systems listed in the DPA schedule.

For GDPR-covered processing, processors must notify controllers without undue delay after becoming aware of a breach, and controllers must notify regulators within 72 hours. That shorter internal deadline matters because it gives your team time to investigate before your own reporting clock starts. ^[17][19][21]

Timing alone isn't enough. The clause should also say what the vendor has to include in the first notice. At a minimum, that notice should cover:

• A description of the incident
• The data types, scope, and affected subjects
• The systems involved
• The known or suspected root cause
• Current containment status
• Likely consequences
• Immediate remediation steps
• The name of a specific incident contact ^[16][17][18]

Cooperation language is another spot where many DPAs come up short. A vendor shouldn't be able to send a short summary and disappear. The DPA should require timely updates as facts change, preservation of logs, configurations, and access records, access to technical staff for incident calls, help with regulator inquiries, and coordination on customer communications without slowing or blocking your legal duties. ^[17][20][21]

How to check deletion or return duties at termination

When the contract ends, the data should not drift around in limbo. Require return or deletion on a fixed timeline. The DPA should say that, at your written instruction, the vendor must either return all personal and confidential data in a common format such as CSV or JSON, or securely delete it within 30–60 days of termination or expiration. ^[1] “Within a reasonable time” sounds harmless, but in practice it can drag on for months.

Backups are where many founders get blindsided. The clause should clearly say that data must also be removed from backups, test systems, disaster-recovery systems, and third-party storage, including copies held by subprocessors. It should also include a documented retention schedule and a firm promise not to restore or use that data except for disaster recovery. ^[13][14][15]

Retention exceptions should stay narrow. Legal holds, tax records, and accounting rules are fair reasons to keep some data for a period of time. But retained data should be off-limits for analytics, product improvement, or any other secondary use. Once deletion is done, the vendor should provide written certification.

What audit rights, liability caps, and indemnity carve-outs should cover

After breach and deletion terms, look at how you verify compliance and how you get paid back if the vendor fails. Audit rights are your proof mechanism. At a minimum, the DPA should give you automatic access to annual security evidence, along with compliance attestations for frameworks tied to your risk, such as GDPR and CCPA. For higher-risk vendors, you may also want the right to ask for deeper review through document requests, interviews, or, in serious cases, on-site audits with advance notice and an agreed scope. Check who pays for those audits too. Many DPAs push the cost to the customer unless the audit finds material noncompliance.

Then look hard at the liability cap. A common cap is 12 months of fees, and that may be far below the actual cost of a breach once you add forensics, notices, regulator response, possible class actions, and cleanup. ^[4] If the vendor is mission-critical, it often makes sense to negotiate a higher cap - or a separate cap - for data breaches, confidentiality failures, or gross negligence, while keeping a lower general cap for other claims. Also watch for carveouts that remove liability for data loss or business interruption. Those can gut the protection on paper.

Indemnity carve-outs help close that gap. The vendor should indemnify you for third-party claims tied to its breach of confidentiality or security duties, unauthorized data use outside documented instructions, and privacy law violations caused by its processing. ^[4] Those carve-outs should sit outside the general liability cap, or under a higher separate cap, and they should not get swept into consequential-damages exclusions.

To make those promises worth something, the DPA should also confirm that the vendor carries cyber liability insurance at a level that fits the risk and that the indemnity language lines up with that coverage.

Who should review the DPA internally before approval?

Once the DPA terms are set, give each internal team a clear owner before anyone signs. For growth-stage companies, the split is usually legal, security, and finance. Each group should review its own piece of the deal before the contract moves forward.

When legal, security, and finance each need to be involved

Legal should make sure the DPA lines up with the MSA and includes the privacy terms you need. If the language in those two documents conflicts, you can end up with enforceability issues.

Security should check whether the vendor’s actual controls match what the DPA says. That means looking for independent proof, not just taking the vendor’s word for it. If the vendor handles sensitive, regulated, or high-volume data, use the full review.

Finance should look at the total cost of risk. That includes liability cap terms, indemnity exposure, audit fees, breach response cost allocation, and any termination or transition costs.

How founders can build a simple review workflow before signature

Use the same review order for every vendor. That keeps the process clean and makes less room for missed issues.

• Map data, confirm scope, and flag restricted uses: Identify data categories, subjects, and jurisdictions. Make sure the DPA’s processing purpose matches how the vendor will actually use the data. Redline any vendor rights that go beyond service delivery.
• Validate evidence, check transfers and subprocessors, and review liability: Ask for independent security certifications or audit reports. Confirm that international transfer safeguards and subprocessor disclosures work for your setup. Review caps, indemnity structure, and insurance alignment with finance.
• Store the final DPA and approval notes in the vendor risk file.

Good records make vendor oversight much easier to show during diligence, security reviews, financing rounds, or M&A.

For higher-risk vendors, it helps to assign a formal approval owner for each step. A tiered model usually works well. Low-risk vendors with limited data access can move through a short checklist. Vendors handling sensitive or regulated data should go through full legal, security, and finance review.

Conclusion: Key DPA clauses to confirm before you sign

The approval call should be simple: sign only after legal, security, and finance clear the DPA. Third-party access was involved in 35.5% of all data breaches in 2024 ^{[22][23][24][25]}. A structured internal sign-off model won’t remove vendor risk, but it can stop a lot of avoidable surprises before they turn into actual problems.

FAQs

What should I redline first in a vendor DPA?

Start with data ownership. The DPA should say, in plain terms, that your company owns all data you provide, along with service-generated data such as logs, reports, and metadata.

Then tighten permitted use. The vendor should be allowed to use data only to deliver and support the service. Any secondary use should require prior written consent.

You should also confirm the exit terms. They need to require data return within 30 days and a certification of deletion.

When is a vendor’s liability cap too low?

A vendor’s liability cap is too low when it doesn’t match the damage a breach or service failure could cause.

For example, a standard cap like 1x annual fees can fall short in cases involving:

• data breaches
• intellectual property disputes
• regulatory non-compliance

That kind of cap can also be too low when it’s tied only to fees already paid. This is a common problem at the start of a new contract, when payments may still be small but the downside is not.

A better move is to negotiate carve-outs for high-risk claims, such as security breaches, indemnification, fraud, and gross negligence. You can also push for a higher super-cap for those claims. And if the vendor is taking on those duties, cyber liability insurance can help back them up.

Who should approve a DPA before signing?

Before signing a Data Processing Agreement (DPA), have legal, compliance, and security teams review it. That step helps confirm the agreement covers regulatory, privacy, and information security needs.

You’ll also want input from IT leadership and the executive sponsor. They can check key terms such as data ownership, liability, and audit rights. Then document every sign-off in a formal go-live checklist with named owners so nothing slips through the cracks.

Related Blog Posts

• M&A Risks: Data Breach Compliance in Cross-Border Deals
• GDPR Risks in Cross-Border M&A Deals
• Top 5 GDPR Risks in Business Transfers
• GDPR vs CCPA in Vendor M&A Review