What a DPA is — and when your business actually needs one

Most businesses first hear "data processing agreement" when an enterprise customer refuses to sign until they get one, or when a compliance review turns up a list of missing agreements. It sounds like a big-company problem. It isn't — the obligation applies to a sole trader who outsources their newsletter just as much as to a multinational. The confusion is understandable, because a DPA hides inside relationships you don't think of as "data processing." So let's make it concrete: what the thing actually is, the simple test for who needs one, and the parts that stay your responsibility no matter how many DPAs your vendors hand you.

What a DPA actually is

A data processing agreement is a legally binding contract between a data controller and a data processor. Those two roles are the whole key, so it's worth being precise about them:

The DPA formalises that relationship: it sets out that the processor acts only on your documented instructions, keeps the data confidential and secure, helps you handle data-subject requests and breaches, and deletes or returns the data when the work ends. In short, it's the document that turns "we use this vendor" into "we've contractually pinned down how this vendor handles our people's data." Under GDPR Article 28, it's mandatory — and the obligation kicks in before any data moves.

The one-question test for whether you need one

You can skip most of the complexity with a single question about any vendor:

The only real nuance is the phrase "on your instructions." A vendor that decides its own purposes for the data may be a separate controller rather than your processor (a different relationship). But for the everyday tools a business runs — the ones processing your data to deliver a service to you — the answer is almost always yes, you need a DPA.

Which vendors actually need a DPA

Here's where the abstraction becomes a checklist. These are the common categories where a DPA is required — and note the pattern: it's basically every tool that touches personal data.

Two of these deserve a flag. Email marketing platforms are, in practice, one of the most commonly missing DPAs — businesses set up a newsletter tool without ever thinking of it as data processing, even though it's handling a whole subscriber list of personal data. And IT/managed-service providers get overlooked because their data access is incidental to their real job — but incidental access to systems full of personal data still counts.

The DPAs you've probably already signed

Here's the reassuring half of the picture: you may already have more DPAs in place than you think. Large processors transact with thousands of controllers and can't negotiate a custom contract with each, so they publish a standard-form DPA — and they get it in front of you in one of two ways:

• Buried in the master service agreement. The DPA is a linked section or addendum inside the MSA you accepted when you signed up. You may have agreed to it without reading it as a separate thing.
• Accepted in your account settings. Providers like Stripe, Google and AWS have you accept their DPA digitally, through the legal or privacy area of your dashboard. Electronic acceptance is legally valid — as long as you keep a record of it.

So part of the job is simply finding the DPAs you already have: check each major vendor's legal/privacy settings and their site. The gaps you actually need to close are usually with the smaller vendors — the niche tool, the boutique agency, the specialist service — that don't offer a standard DPA at all. That's where you have to bring one.

The part that stays yours: due diligence

This is the honest catch that a lot of DPA guides gloss over. Because the big providers hand you a polished DPA, it's tempting to think your job is just to click "accept." It isn't. The GDPR puts the accountability on you, the controller — and that means two responsibilities no vendor discharges for you:

• You have to verify the DPA is actually adequate. Countersigning a processor's standard DPA without checking that it satisfies Article 28(3) in full doesn't meet your accountability obligation — even if the DPA happens to be compliant. You're responsible for having checked.
• You have to provide one where the vendor doesn't. For smaller vendors with no standard DPA, the drafting obligation falls to you. A missing DPA is itself a breach of Article 28 — even if the processor is perfectly careful with the data — because you can't demonstrate the contractual controls the law requires.

What to check when you review a vendor's DPA

If reviewing — not just accepting — is the controller's real job, it helps to know what you're actually looking for. You don't need to be a lawyer to run a sensible first pass over a vendor's standard DPA. Check that it clearly covers the Article 28 essentials:

• Processing on your instructions only. The vendor should commit to processing the data only as you direct, not for its own purposes.
• Confidentiality and security. Staff bound to confidentiality, and appropriate technical and organisational security measures described.
• Sub-processors. How the vendor uses its own sub-processors, whether you're notified of changes, and whether you can object (more on this below).
• Help with your obligations. That the vendor will assist you with data-subject requests and with breach notification.
• Deletion or return. What happens to the data when you stop using the service — it should be deleted or returned.
• International transfers. If the vendor moves data outside the EEA, that Standard Contractual Clauses or another valid transfer mechanism are included.

If a vendor's DPA is silent on one of these, that's the thing to raise — either ask for an amendment or reconsider the vendor. The point isn't perfection on the first read; it's that you looked, because "we countersigned whatever they sent" is precisely the posture the accountability principle is designed to rule out.

The sub-processor chain most people miss

Here's a wrinkle that catches even careful businesses. Your processors have their own processors. The email tool you use runs on a cloud host; the CRM you use relies on other services. Those are sub-processors, and Article 28 requires that a processor not bring in a new sub-processor without your authorisation, and that the same data-protection obligations flow down the chain by contract.

In practice, most standard DPAs handle this with "general authorisation": the vendor keeps a published list of its sub-processors and notifies you of changes, giving you a window to object. What that means for you is small but real — you're implicitly relying on a chain of processors you'll never contract with directly, and your only lever is the notification-and-objection mechanism in the DPA. It's worth knowing that lever exists, and glancing at a vendor's sub-processor list when data sensitivity warrants it, rather than assuming the chain ends at the vendor you signed with.

How to get your DPAs in order

Put together, a sane approach for a normal business looks like this:

• List your processors. Every third-party tool that touches personal data — start from your billing/subscriptions and the trackers on your site, since those reveal the vendors actually in play.
• Find the DPAs you already have. Check each major vendor's legal/privacy settings and accept or file their standard DPA, keeping a record.
• Review them, don't just accept them. Confirm each covers the Article 28 essentials rather than assuming it does.
• Fill the gaps. For vendors with no DPA, generate a solid Article 28 agreement, review it for your situation, and get it signed with that vendor.
• Keep a register. Maintain a simple list of each processor, its DPA status, and the date — so you can see the gaps at a glance and prove the controls exist.

Disclaimer: This article is general information, not legal advice, and does not create an attorney–client relationship. Whether and how data-protection law applies to your vendors depends on your specific circumstances and jurisdiction. ConsentPixel — Privacy · Verified is not a law firm, and generating a DPA does not by itself make you compliant with any law; a DPA must be reviewed for your situation and executed with each processor to have effect. Vendor names are used for illustration and are trademarks of their respective owners. Consult qualified counsel for your specific situation.