Vendor DPA Review: Common Gaps
Spot and fix four DPA gaps—deletion, data use, transfers, breach notice—to speed vendor reviews and meet GDPR timelines.
Most vendor DPAs break down in the same four places: deletion, data use, transfers, and breach notice. If I’m doing a first-pass review, I can usually spot the main risk in 20 to 30 minutes by checking whether the contract sets a clear deletion deadline, limits data use to the paid service, names the cross-border transfer method, and gives a breach notice window of 24 to 48 hours.
Here’s the short version:
- Deletion: I want a fixed deadline, coverage for backups and logs, and written proof.
- Data use: I want use limited to service delivery only, under my instructions.
- Transfers: I want the DPA to name the legal transfer method and the countries involved.
- Breach notice: I want a firm notice window in hours, not vague terms like “promptly.”
A weak DPA often sounds fine on first read. But if it says access ends without saying when data is deleted, or lets the vendor use data for analytics, research, or model training, I’m left with less control than I may expect. Under GDPR Article 28(3)(g), end-of-service deletion or return is not optional language. And with GDPR’s 72-hour breach reporting clock in the background, a vendor notice window of 24 to 48 hours gives me time to react.
4 Common Vendor DPA Gaps: Weak vs. Usable Contract Language
The Hidden Risk in Vendor Contracts | Data Processing Agreements Made Simple | Avoid GDPR Penalties
sbb-itb-ce93587
Quick comparison
| Area | What I look for | Red flag |
|---|---|---|
| Deletion | Clear delete/return duty, set deadline, backups covered, written confirmation | Access ends, but data handling is not stated |
| Data use | Service-only use under documented instructions | Internal use, product improvement, research, AI training |
| Transfers | Named mechanism, listed regions, subprocessor alignment | No legal method named |
| Breach notice | Fixed timeline in hours and minimum notice contents | Promptly or without undue delay |
If I start with these four checks, I can cut through most of the noise and focus on the clauses that need changes before signing.
What are the most common gaps in vendor DPA contracts?
Start with these four clauses: weak deletion language, broad data use rights, missing transfer terms, and vague breach notice timing. They’re usually the fastest places to tighten a vendor DPA.
Weak deletion language
A weak DPA may say the vendor loses access to the service when the contract ends. That sounds fine at first glance, but it leaves the hard part unanswered: what happens to the data?
A usable DPA should state:
- the deletion deadline
- whether data is deleted or returned on request
- how backups are handled
- whether the vendor must give written deletion certification
If those points are missing, you don’t have much to lean on later.
Broad data use rights
Watch for clauses that let the vendor use data for product improvement, analytics, research, internal use, or AI/model training. That kind of wording can be far too open-ended.
A tighter version should limit data use to only providing the contracted service and only under your documented instructions.
Missing transfer and breach terms
Transfers and breach notice often get lumped together, but they should be checked as two separate issues.
For cross-border transfers, the DPA should name the transfer mechanism, list approved destinations, and state who handles transfer compliance.
For breach notice, don’t settle for “promptly” or “without undue delay.” Ask for a fixed deadline of 24–48 hours and require the first notice to include the key facts. That 24–48-hour window matters because it gives you time for your own downstream reporting.
Across all four gaps, the pattern is pretty simple: weak wording leaves room for delay or misuse, while usable wording gives you terms you can act on.
| Gap | Weak wording | Usable wording |
|---|---|---|
| Deletion | Access ends when the contract ends | Delete or return data within a fixed number of days, including backups, with written confirmation |
| Data use | For internal use or product improvement | Only to provide the contracted service, per documented instructions |
| Transfers | No cross-border mechanism named | Named transfer tool or legal basis, with transfer responsibility clearly assigned |
| Breach notice | Promptly or without undue delay | Specific deadline and required content for the initial notice |
Why is weak deletion language a problem?
When a contract ends, the key question is simple: does the vendor delete the data it still has, or does it keep it? For Shopify app teams that handle merchant and customer data, this is a direct compliance and security issue, not some obscure legal footnote.
Under GDPR Article 28(3)(g), a processor must, at the controller's choice, delete or return all personal data at the end of the services and delete existing copies unless the law requires storage. So if a clause only says access ends at termination, that doesn't do the job. It deals with the controller's access, but says nothing about the vendor's duty to remove the data from its own systems.
What deletion terms should a DPA clearly state?
A usable DPA should spell out five basics that a reviewer can check fast.
- Delete or return, with a deadline? The clause should say whether the data must be deleted or returned, and it should set a clear deadline tied to termination, expiration, or a valid deletion request.
- What about backups and logs? Backups are where weak language often slips through. The DPA should explain how backups, logs, and archives are handled, including retention limits and when those copies are purged.
- Are legal retention exceptions narrow? A DPA may let the vendor keep data when the law requires it, such as for tax rules or a litigation hold. But that carveout should point to a specific legal duty, not a loose phrase like business purposes.
- Will the vendor confirm in writing? A written certificate or attestation after deletion gives the app team an audit trail and an easy way to document compliance.
How to tell weak deletion language from usable language
You can usually spot weak language by checking three things: who deletes what, by when, and how the deletion is proven.
| Element | Weak language | Usable language |
|---|---|---|
| Timing | Vendor will delete data upon termination of the agreement. | Vendor will delete or return all personal data within a clear deadline after termination or a verified request. |
| Backups | Backups are cleared according to our standard rotation policy. | Backup copies will be purged on a defined schedule and are not accessible for normal operations in the interim. |
| Scope | We will delete your account information. | Deletion covers all personal data across primary systems, archives, logs, and subprocessor systems. |
| Legal exceptions | We may retain data as necessary for business purposes. | Data is retained only when required by law, access is restricted, and deletion follows once the obligation ends. |
| Confirmation | No mention of proof. | Vendor will provide written certification of deletion, including which systems were cleared and when. |
Watch for phrases like when feasible, may delete, as appropriate, and as long as needed. Those phrases give the vendor room to decide for itself instead of setting a duty it must follow.
A quick way to score the clause is to look for four signals:
- Trigger
- Deadline
- Scope
- Proof
Once deletion language is locked down, the next step is to check whether the vendor can use the data for anything beyond service delivery.
What makes data use rights too broad?
Deletion language covers what happens to data after the relationship ends. Data use rights deal with what a vendor can do with that data during the contract.
That distinction matters.
A vendor’s processing rights should line up with the service you paid for - nothing extra. So the first check is simple: does the contract limit the vendor’s use of your data to the service you actually bought?
Which data use clauses need a closer look?
Pay close attention to language around service improvement, research, analytics, or phrases like “operate, improve, and enhance the Service” when that wording isn’t clearly tied to your account or the service in your contract.
Aggregation language is another warning sign. If a clause lets the vendor combine your data with data from other users to create benchmarks, insights, or platform-wide intelligence, your data is doing more than powering your own service. It’s helping the vendor build value across its whole customer base.
Some vendors go a step further and claim exclusive ownership of aggregated and derived data products created from your raw inputs. Put plainly, that can let the vendor claim ownership over outputs built from your data.
Use the table below to spot broad wording fast.
| Clause type | Broad language (red flag) | Tighter alternative |
|---|---|---|
| Permitted purpose | Open-ended language like service improvement or a right to operate, improve, and enhance the Service | Processing limited to the specific service described in the agreement |
| Aggregation rights | Combine your data with data from other users to produce benchmarks, insights, or platform-wide intelligence | Aggregation permitted only within the customer's own account data |
| Derived data ownership | Aggregated and derived data products belong to the vendor | Customer retains rights to insights derived from their own data |
| Secondary use | Business purposes or research | Explicitly prohibited unless separately negotiated in writing |
| Confidentiality | Not addressed | Vendor must maintain strict confidentiality and cannot sell raw data |
What limits should the DPA place on data use?
A well-scoped DPA should limit processing to the exact service described in the agreement and to the customer’s documented instructions. It should also block secondary uses - like product development, model training, or market intelligence - unless those rights are separately negotiated in writing.
If the vendor wants rights to aggregated or de-identified data, the DPA should clearly define anonymized data and state that it cannot reasonably be tied back to your app or account. If that standard is vague, that’s a gap.
Once use rights are scoped, the next step is to review where data goes and how fast the vendor has to report a breach.
What transfer terms and breach timelines should a DPA include?
Next, look at where data goes and how fast the vendor has to tell you about a breach.
What transfer language should the DPA include?
A solid DPA should spell out where personal data is stored, processed, and backed up. It should also name the countries or regions involved. Just as important, it should state the transfer mechanism in use - such as SCCs, BCRs, or an adequacy decision - and require subprocessors to follow that same mechanism.
Vague wording like "the vendor will transfer data under a named legal mechanism" leaves too much in the dark. It doesn't tell you which mechanism is being used, whether it has been updated to match current EU transfer rules, or how it applies across specific regions.
If the transfer terms are clear, the next thing to check is breach timing.
What breach notice timeline works in practice?
"Without undue delay" is too vague to work as a breach deadline. The European Data Protection Board recommends setting breach notice in hours, not "without undue delay."
In practice, a 24- to 48-hour window is a common contract standard for vendor-to-app-team breach notice. That gives app teams time to investigate and still meet GDPR's 72-hour controller reporting deadline. A two-step setup tends to work well: an initial notice within 24 to 48 hours with the facts known at that point, followed by updates as the investigation moves forward. The first notice should cover the nature of the breach, the data categories and approximate number of affected records, the suspected root cause, and the first containment steps. The clause should also require the vendor to cooperate on merchant notices and follow-up questions.
How to review these clauses quickly
Use the table below as a quick triage tool. Each row links a clause area to the risk behind it and the wording you should confirm.
| Clause area | Risk it addresses | Wording to verify |
|---|---|---|
| Deletion | Data kept after the contract ends | Specific timeline, deletion method, and written confirmation |
| Data use | Vendor using data beyond the agreed purpose | Use limited to services in the agreement; secondary use barred unless separately negotiated in writing |
| Transfers | Unlawful or unclear cross-border data flows | Named jurisdictions, explicit mechanism (SCCs, BCRs, adequacy), subprocessor alignment |
| Breach notice | Late or partial incident details | Defined window in hours, minimum notice contents, ongoing update duty, cooperation language |
Conclusion: The 4 DPA gaps to fix first
After you review deletion, data use, transfers, and breach notice, start with these four gaps. Weak deletion language, broad data use rights, missing transfer terms, and vague breach notice timing all add risk that Shopify app teams can avoid.
What should you push for?
- Fixed deletion deadlines
- Service-only data use
- Named transfer mechanisms with listed sub-processors
- Breach notice within a defined window of 24 to 48 hours from awareness
Keep a short checklist for every vendor DPA. In most cases, a 20- to 30-minute scan across these four areas is enough to spot the clauses that need negotiation before you sign.
Then use that same four-point scan every time a new vendor DPA lands on your desk.
FAQs
What should I negotiate first in a weak vendor DPA?
Start with broad data use rights and missing transfer terms. Those two issues often create the highest compliance risk.
Next, tighten the deletion language so data is purged promptly when the contract ends. Also spell out breach notice timelines more clearly, so you get actionable information within a reasonable window.
How do I verify that backups and logs are actually deleted?
The search results don’t explain how to verify deletion of backups and logs.
In your Data Processing Agreement, require the vendor to provide:
- Written certification of deletion
- Audit logs that confirm the purge process
- A documented retention policy that explains how data is overwritten or destroyed in backups and secondary storage
What breach details should a vendor include in the first notice?
The first breach notice should spell out what happened, what kind of data was involved, and the approximate number of affected records.
It should also explain the immediate steps taken to contain the incident and give people a clear point of contact for follow-up questions.