A Data Processing Agreement (DPA) is a contract between a company (the "controller," who decides why and how personal data is used) and a vendor (the "processor," who handles that data on the controller's behalf) that sets the terms under which the processor is allowed to touch personal data. It sounds like purely legal/procurement territory, but marketing ops is usually the function that actually knows which vendors touch customer personal data, how, and how often new ones get added — a new ESP, a new attribution tool, a new chatbot vendor. Legal can't request a DPA for a vendor it doesn't know marketing has started sending data to, which makes marketing ops the practical first line of defense here even though it doesn't own the legal relationship.

What a DPA actually covers

A typical DPA specifies the categories of personal data the vendor will process and for what purpose (scope should match what's actually happening, not a vague blanket description), the duration of processing and what happens to the data when the relationship ends (deletion or return, on what timeline), the vendor's security obligations (encryption, access controls, breach notification timelines), audit rights (the controller's ability to verify the vendor's compliance), and — critically for martech stacks — terms governing sub-processors, since most martech vendors don't just use their own infrastructure.

What belongs in a DPA vs. a standard commercial contract

Term	Covered in DPA	Covered in commercial/MSA
Pricing, SLAs, support terms	No	Yes
What data categories the vendor may process	Yes	No
Sub-processor disclosure and approval rights	Yes	No
Data breach notification timeline	Yes	Sometimes referenced
Data return/deletion on contract termination	Yes	Sometimes referenced
Cross-border transfer mechanism (e.g. standard contractual clauses)	Yes	No

Sub-processor disclosure: the part most teams skip

Almost no martech vendor runs entirely on its own infrastructure. An ESP might run on a cloud hosting provider, use a separate deliverability/analytics vendor, and route SMS through a telecom API partner — each of those is a sub-processor, meaning personal data flows to them too. A DPA worth signing requires the primary vendor to disclose its sub-processors (usually via a public sub-processor list the vendor maintains and updates) and to flow down equivalent data protection obligations to each one. This matters practically because under most privacy regimes, the controller (the company collecting the data in the first place) remains accountable for how that data is handled all the way down the chain — "our vendor's sub-processor leaked it" is not a defense that eliminates the controller's own exposure.

A signed DPA with an unreviewed sub-processor list is a false sense of security

It's common for teams to treat "we have a DPA with this vendor" as the end of the diligence, without ever checking which sub-processors that vendor actually uses or whether that list has changed since signing. Vendors generally notify customers of new sub-processors through a notice period and an objection right, but that mechanism only protects the company if someone is actually watching for those notices — in practice, that's usually marketing ops, not legal, because legal isn't subscribed to a martech vendor's product changelog.

vendor_dpa_tracking_template.txt

text

MARTECH VENDOR DPA TRACKER (one row per vendor)

Vendor name:            [e.g. ESP, CDP, chatbot, attribution tool]
Data categories shared:  [e.g. email, name, behavioral events, IP]
DPA signed:              [Y/N + date]
Sub-processor list URL:  [link -- check quarterly for changes]
Cross-border mechanism:  [e.g. SCCs, adequacy decision, N/A]
Deletion on offboarding: [confirmed Y/N + how verified]
Renewal/review date:     [set a recurring reminder, not "someday"]
Last reviewed by:        [name + date]

Why marketing ops should maintain its own vendor DPA tracker

Relying on legal or procurement's contract repository as the sole system of record for DPA status creates a blind spot: those teams often don't know when marketing has started actively sending new categories of data to an existing vendor (e.g., starting to sync phone numbers into a tool that previously only received email addresses), which can change whether the existing DPA's scope is even still accurate. A lightweight tracker maintained by marketing ops — vendor, data categories shared, DPA status, sub-processor review date — closes that gap and gives ops a fast answer when legal, security, or a customer asks "which vendors have access to this data." This tracker is also usually the fastest way to answer a Right to Know or data mapping request under most privacy regimes without reconstructing the vendor list from memory.

New vendor onboarding should trigger a DPA check by default

The cheapest point to catch a missing DPA is before a new martech tool goes live, not after an audit. Building a DPA-check step into whatever process approves new marketing tools — even a simple checklist item — prevents the far more common failure mode of a vendor being in production for months before anyone asks whether the paperwork exists.

What's next

DPAs are one piece of the compliance surface marketing ops is accountable for; the GDPR vs. Global Privacy Laws module maps the broader legal landscape these agreements have to satisfy across jurisdictions.

Next: GDPR vs. Global Privacy Laws →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →