do we need a DPA" decision guide

"do we need a DPA" decision guide

TL;DR

If you process personal data on behalf of a customer, you almost certainly need a Data Processing Agreement. The test is simple: whose data is it, and who decides what to do with it. If the customer decides and you just process, you are the processor and the DPA is how you both write that down.

"do we need a DPA" decision guide

Use this when

• A customer sends you a DPA to sign and you are not sure you need one
• You are launching a product that handles customer or end-user personal data
• Legal is asking which vendors need DPAs from you
• You are not sure whether you are a controller or a processor

Not for this skill when

• You need the actual legal text of a DPA (get a lawyer or a vetted template)
• The data is not personal data at all (no personal data, no DPA question)
• You are deciding about a different contract like an NDA or MSA (related, not the same)

Steps

1. Ask: are we processing personal data for someone else?

If your product touches your customer's end users, employees, or customers, and the customer decides why and how that data is processed, you are the processor. Analytics, hosting, support tools, and CRMs are the classic cases. If you decide the purposes yourself, you are likely a controller and the analysis is different.

Expected: a one-sentence verdict per product line: processor, controller, or not personal data.

2. Check which privacy laws apply.

GDPR and UK GDPR require a written processing agreement whenever a processor handles personal data for a controller. Several US state laws have similar contract requirements. If any customer is in those jurisdictions, the answer is yes.

Expected: a list of the laws your customer base triggers, even if it is just "GDPR, because we have EU customers."

3. Look at what the deal requires.

Enterprise customers ask for DPAs as a matter of course; it is often a checkbox in procurement. Even when the law is ambiguous, signing a reasonable DPA unblocks revenue. Refusing on principle costs more than the paperwork.

Expected: a policy like "we sign DPAs for any customer who asks, using our standard terms."

4. Confirm the DPA covers the essentials.

Subprocessors listed (or a notification process), security measures described, breach notification timelines, data deletion at contract end, audit rights, and international transfer terms if data crosses borders. If a customer sends you theirs, check these sections instead of reading every word.

Expected: a checklist with each essential marked present or missing before anyone signs.

5. Sign it, file it, and calendar the obligations.

Breach notification windows and subprocessor change notices are the obligations that bite. File the signed DPA where the team can find it and put the recurring duties on someone's calendar.

Expected: every signed DPA filed with its key dates and duties visible.

6. Flow the duties down to your subprocessors.

Your vendors who touch the same personal data need DPAs with you, with matching commitments. Your DPA promises to the customer are only as good as your vendors' promises to you.

vendorctl list --handles-personal-data

Expected: the subprocessor list you disclose in your own DPA exhibit, with signed DPAs behind each name.

Variant: when is a DPA required

Whenever you are a processor under GDPR or UK GDPR, which is most B2B SaaS handling customer data. US state laws increasingly require written contracts with processors too. When in doubt, sign one.

Variant: DPA vs MSA

The MSA covers the commercial relationship; the DPA covers personal data handling duties. They are companions, not substitutes, and most companies attach the DPA as an exhibit to the MSA.

Variant: do startups need DPAs

Startups need them the moment they process personal data for customers, which is usually day one of having customers. Being small does not exempt you; it just means you use a standard template instead of negotiating.

Variant: data processing agreement checklist

Subprocessors, security measures, breach notification, deletion on exit, audit rights, transfer mechanisms, liability. If those seven are covered, you have the substance.

Why this happens

Privacy law puts duties on the controller but makes them enforceable through the processor contract. The DPA is the chain that connects "the customer is responsible for this data" to "and here is what we actually do with it." Without it, both sides are guessing about duties that carry real fines.

Edge cases and pitfalls

• You are both controller and processor: common for SaaS (processor for customer data, controller for your own marketing data). The DPA covers the processor part; do not let it confuse the controller part.
• Subprocessor changes: most DPAs require notice before adding subprocessors. Build that notification into vendor onboarding so it is not a fire drill.
• Customer sends a one-sided DPA: push back on unlimited liability and audit-anytime clauses, but do not die on every hill. Standardize what you accept and escalate the rest.
• DPA signed and forgotten: the breach notification clock starts at awareness, not at finding the filed PDF. Make sure the on-call team knows the timelines.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_P2hpjecbJBBSNFLpvwZp-w