If a vendor touches personal data — an email address, an employee ID, an IP address logged in a server file — a Data Processing Agreement isn't optional paperwork. It's a GDPR requirement under Article 28, and signing an MSA without one is a compliance gap that regulators have fined companies millions of euros for missing. Here's what actually triggers the requirement, what the DPA has to cover, and how it should sit alongside your master agreement.
What a DPA actually is
A Data Processing Agreement is the contract that governs how a vendor (the "processor") handles personal data on behalf of your company (the "controller"). It's a separate legal instrument from your commercial terms — it doesn't set price, term, or liability caps. It sets the rules for what the vendor can do with the data, who else can touch it, and what happens when something goes wrong. Under GDPR, Article 28(3), this isn't a nice-to-have: it's a mandatory contract wherever processing happens on your instructions.
The trigger: when you actually need one
The test is simple: does the vendor process personal data on your behalf? That covers more vendors than most teams assume — not just the HR platform or the CRM, but:
- Any SaaS tool with user accounts (names, emails, login IPs)
- Support or ticketing platforms that log customer conversations
- Analytics or logging tools capturing IP addresses or device identifiers
- Payroll, benefits, or recruiting vendors
- Any AI tool that ingests documents containing employee or customer names
- Cloud infrastructure and backup providers storing any of the above
Rule of thumb: if you can't say with certainty "no personal data will ever pass through this vendor," assume you need a DPA and ask for one at the RFP stage — not after signature. Chasing a DPA six months into a contract, once the vendor's legal team has deprioritized you, routinely takes 4-8 weeks and stalls onboarding.
DPA vs MSA: two documents, one relationship
The Master Service Agreement governs the commercial relationship — scope, price, term, liability, IP, termination. The DPA governs one slice of that relationship: personal data processing. They're kept as separate documents for a practical reason — the DPA needs to survive changes to the commercial terms, and it needs standard language legal can reuse across vendors without re-drafting from scratch.
In practice, most DPAs attach as an addendum to the MSA, referenced in a single clause: "Processing of personal data under this Agreement shall be governed by the Data Processing Agreement attached as Exhibit B." Two things to check every time:
- The DPA is actually attached, not just referenced by URL. A link to a webpage the vendor can edit unilaterally isn't a binding contract term — and it's the single most common gap we see in vendor paperwork.
- The DPA and MSA don't conflict. If the MSA caps liability at 12 months of fees but the DPA has no carve-out for data breach costs, you may have accidentally capped your breach remediation recovery too. This is exactly the kind of cross-document inconsistency that's easy to miss reading each file separately — it's why redlining the MSA and reviewing the DPA need to happen as one pass, not two.
The clauses that have to be there
Article 28(3) of GDPR lists eight specific commitments the processor must make. Vendor-drafted DPAs often gesture at these without actually committing to them. Check line by line:
- Processing only on documented instructions — the vendor can't use your data for its own purposes (model training, product analytics, resale) without an explicit, separate basis.
- Confidentiality commitment for personnel with access to the data — not "our staff are professional," but a contractual obligation.
- Sub-processor list and approval rights. Every downstream vendor touching the data (hosting, email delivery, support tooling) must be named, with prior written consent or at least 30 days' notice before a new one is added. "Vendor may use sub-processors as it sees fit" is not compliant.
- Security measures matching the risk — encryption at rest and in transit, access controls, ideally a current SOC2 Type II or ISO 27001 certificate, not just a promise.
- Breach notification SLA. GDPR requires controllers to notify regulators within 72 hours of becoming aware of a breach — so your processor's contractual notification window has to be meaningfully shorter, typically 24-48 hours, or you can't meet your own deadline.
- Data location and international transfers. If data leaves the EU/EEA, the DPA needs Standard Contractual Clauses (SCCs) or another valid transfer mechanism — not "we take privacy seriously."
- Assistance with data subject requests (access, deletion, portability) and with your own DPIAs and regulator inquiries.
- Deletion or return of data on a defined timeline at the end of the engagement — 30 days is standard, 90+ days is a red flag.
Where vendor-drafted DPAs typically fall short
The same gaps recur often enough across vendor paperwork to be worth flagging by default:
- Sub-processor lists that are out of date, incomplete, or absent from the signed document.
- Breach notification language softened to "without undue delay" instead of a hard number of hours.
- Data residency commitments covering primary storage but excluding logs, backups, and support tickets — the metadata footprint is usually bigger than the primary dataset.
- Audit rights limited to "vendor will provide its SOC2 report annually," with no right to an ad hoc audit after an incident.
- A DPA referencing GDPR but clearly templated for a different jurisdiction — check the transfer mechanism actually names SCCs, not just "applicable safeguards."
These are the same category of gap our DORA/NIS2 compliance checklist covers for financial services and critical-infrastructure buyers — if you're in a regulated industry, the DPA is one input into a larger compliance picture that also includes incident reporting cooperation and concentration-risk assessment.
A working checklist before you sign
- Confirm whether the vendor processes personal data — if unclear, ask directly in the RFP.
- Request the DPA as a signed exhibit, not a webpage link.
- Check all eight Article 28(3) elements are present, not just referenced.
- Cross-check the DPA's liability and breach clauses against the MSA for conflicts.
- Verify the sub-processor list is current and the change-notice period is acceptable.
- Confirm the breach notification SLA leaves enough runway for your own 72-hour regulator deadline.
- Log the DPA with the MSA in your contract calendar so a renewal doesn't silently drop the data protection terms.
Where AI review actually helps
Manually cross-referencing a DPA against Article 28(3), then against the MSA's liability clause, is exactly the multi-document, checklist-driven work that eats an afternoon of legal time per vendor. POCsheet's Red Flag Detection flags the gaps above automatically — missing sub-processor terms, soft breach notification language, liability caps that don't carve out data incidents — across scanned or OCR'd PDFs as easily as native text. Paired with the AI contract chat, legal can ask "does this DPA name a breach notification window under 48 hours?" and get a cited answer in seconds instead of re-reading the exhibit. It doesn't replace legal judgment on where to push back — it makes sure nothing gets missed because the reviewer was on their fourth contract of the day.
For the underlying legal text, GDPR Article 28 is the authoritative source for what a processor contract must contain — worth bookmarking for your own reference: Article 28 GDPR — Processor.