When You Need a Data Processing Agreement With a Supplier

TL;DR — A data processing agreement (DPA) is the contract you put in place when a supplier handles personal data for you on your instructions. The most likely rule of thumb is: if the supplier can store, view, send, analyze, back up, or otherwise touch personal data on your behalf, ask for a DPA before go-live. Reading time: ~7 min

What it is and where it sits

A data processing agreement is a contract between two parties:

• Controller (the party deciding why and how personal data is used)
• Processor (the supplier handling that data for the controller)

In plain English: if your business decides to collect customer names, emails, support messages, or employee records, and a supplier helps host, store, send, analyze, or support that data, the supplier is often your processor. The DPA is the document that says what they are allowed to do, what security they must apply, whether they can use subprocessors (their own suppliers), how they help with deletion requests, breach notices, audits, and international transfers.

It does not replace the main commercial contract. It usually sits beside:

• the master services agreement (the main services contract)
• the terms of service
• the privacy policy
• any international transfer terms, such as standard contractual clauses if needed

Think of it as the privacy-and-handling layer of the supplier relationship.

Where it lives in a typical data flow

A DPA is not a technical component like a database or API gateway. It sits over the top of the technical flow and governs what each supplier in that flow may do with personal data.

For example, a typical web app might use:

• a hosting provider for the app and database
• an email provider for transactional emails
• a helpdesk tool for support tickets
• an analytics tool
• a backup provider

If those suppliers handle personal data on your behalf, the DPA attaches to those relationships.

[Customer Browser] ---- 1. submit form ----> [Your App]
[Your App] ---- 2. save profile ----> [Database/Hosting]
[Your App] ---- 3. send welcome email ----> [Email Supplier]
[Customer] ---- 4. open support ticket ----> [Helpdesk Supplier]

[DPA with Hosting] ^
|
[DPA with Email Supplier] ^
|
[DPA with Helpdesk Supplier] ^

The important architectural point is this: the DPA follows the data path, not just the invoice list. If a supplier can access personal data anywhere in the request, storage, support, logging, backup, or deletion flow, they may need a DPA.

How it actually works

A DPA works by turning privacy obligations into concrete contract terms. It usually covers:

• subject matter and duration — what processing happens and for how long
• nature and purpose — for example, hosting customer accounts or sending invoices
• types of personal data — names, emails, IP addresses, support messages
• categories of data subjects — customers, staff, prospects
• security measures — encryption (data scrambled so only authorized parties can read it), access controls, backups, incident handling
• subprocessors — whether the supplier can use other vendors
• assistance duties — helping with access, deletion, correction, and breach response
• return or deletion — what happens to data when the contract ends
• audit and information rights — how you can verify compliance

One realistic example: your agency uses a cloud email service

Let’s walk through a common case end to end.

You run an online service. When a customer signs up, your app sends a welcome email and password reset emails through a third-party email delivery supplier.

Step 1: You map the personal data involved

The app sends these fields to the email supplier:

• email address
• first name
• account ID
• message content such as reset links
• delivery metadata such as IP address, timestamp, and bounce status

That is personal data because it relates to identifiable people.

Step 2: You decide the roles

You decide why the emails are sent and what data is included. The supplier sends and logs the emails on your behalf. In that setup, you are usually the controller and the email supplier is the processor.

Step 3: You put the DPA in place before production use

In the supplier’s dashboard, look for a legal or privacy section. Common paths vary, but often resemble:

• Settings → Legal → Data Processing Addendum
• Account → Security & Compliance → DPA
• Organization Settings → Privacy → Agreements

If there is no self-serve option, email your supplier contact or support team with a direct request such as:

Subject: Request for Data Processing Agreement

We plan to use your service to process personal data on our behalf, including customer email addresses and message delivery data. Please send your current Data Processing Agreement / Data Processing Addendum for review and signature, including your current subprocessor list and transfer mechanism details.

Step 4: You review the parts that matter operationally

You are not just checking whether a PDF exists. You are checking whether the terms match reality.

Look for:

• Does it describe the service you are actually buying?
• Does it allow subprocessors, and is there a list?
• Does it say how they notify you of new subprocessors?
• Does it say when they notify you of a personal data breach?
• Does it explain deletion after termination?
• Does it mention where data is processed and what transfer mechanism is used if data crosses borders?

Step 5: You record it in your supplier register

In whatever system you use — spreadsheet, procurement tool, contract folder — record:

• supplier name
• service used
• whether personal data is involved
• role: processor or independent controller
• DPA signed date
• renewal or review date
• subprocessor link or attachment
• transfer mechanism, if relevant

Step 6: Data starts flowing under that contract

Now when your app calls the email API, the technical flow happens as normal, but the DPA governs the supplier’s legal obligations around that processing.

For example, if a customer asks you to delete their account, your deletion workflow should include the email supplier if they store personal data beyond short-lived delivery logs.

Step 7: You use the DPA when something goes wrong

If the supplier has a breach, the DPA should tell you how quickly they notify you and what information they provide. If you need to answer a customer access request, the DPA should require reasonable assistance.

That is the practical value: the DPA is what turns “our vendor handles data” into enforceable duties you can rely on.

When to use it (and when not to)

The key question is not “Is this supplier in our stack?” It is “Does this supplier process personal data for us, on our instructions?”

You probably do need one if...

• the supplier hosts your production systems
• the supplier can log into systems containing personal data
• the supplier stores backups containing personal data
• the supplier sends communications to your users
• the supplier provides support and can view tickets, screenshots, or databases
• the supplier uses AI or analytics on your customer data on your behalf

You probably do not need one if...

• the supplier never receives personal data at all
• the data is truly anonymized, not just “we removed names”
• the supplier acts as its own controller, deciding purposes independently
• the relationship is purely about goods, with no access to your personal data

If you are unsure, ask two simple questions in writing:

1. “Will you process any personal data on our behalf?”
2. “If yes, please send your DPA and subprocessor list.”

Trade-offs

A DPA is usually the right move when a supplier processes personal data, but it is not free of cost.

Two honest realities:

• A signed DPA does not mean the supplier is secure. It gives you rights and commitments, but you still need sensible supplier selection.
• The smallest suppliers may not have mature DPA processes. That can be a warning sign if they will handle sensitive personal data.

In practice

Below are two practical examples you can adapt today: one for your supplier intake checklist, and one for contract metadata you can track internally.

Example 1: Supplier intake checklist

Use this in a form, ticket template, or spreadsheet when a team wants to buy a new tool.

supplier_name: "Example Email Service"
service_description: "Transactional email delivery for account emails"
personal_data_involved: true
personal_data_types:
  - "email address"
  - "name"
  - "account ID"
  - "message metadata"
access_to_production_systems: false
stores_data_outside_our_system: true
supplier_role_assessment: "processor"
dpa_required: true
subprocessors_reviewed: false
international_transfers_involved: true
security_review_status: "pending"
owner: "operations@example.com"
go_live_blocker: "DPA must be signed before production use"

This gives your team a repeatable intake record before a purchase is approved. The gotcha: do not let “security review pending” or “subprocessors reviewed: false” sit there while the tool quietly goes live anyway; add a real approval gate in your procurement process.

Example 2: Internal supplier register entry in JSON

This is a simple structure your agency can store in a document system, spreadsheet export, or internal admin tool.

{
  "supplier": "Example Hosting Provider",
  "service": "Application hosting and managed database",
  "business_owner": "Head of Product",
  "contains_personal_data": true,
  "role": "processor",
  "dpa_status": "signed",
  "dpa_signed_on": "2026-03-12",
  "review_due_on": "2027-03-12",
  "subprocessor_list_location": "Contract folder / Suppliers / Example Hosting / subprocessors.pdf",
  "data_location_notes": "Primary region in EU; support access may be global",
  "deletion_commitment": "30 days after termination unless law requires retention",
  "breach_notification_clause": "Without undue delay",
  "contract_owner": "privacy@example.com"
}

This helps you answer customer questionnaires and internal audits without hunting through inboxes. The gotcha: phrases like “without undue delay” are common, but they are not the same as a fixed 24-hour or 72-hour promise, so record exact wording rather than paraphrasing it as stronger than it is.

⚠️ Do not start sending production personal data to a new supplier before the contract position is clear. If the supplier later refuses a DPA, you may have to stop using the service, migrate data, or explain an avoidable compliance gap to customers or regulators.

A practical approval flow you can use

1. Ask the requesting team what data the supplier will touch.
2. If the answer includes customer, employee, prospect, or user data, ask the supplier for its DPA.
3. Review the subprocessor list and deletion terms.
4. Store the signed DPA in your contract folder.
5. Record the supplier in your register.
6. Only then approve production use.

If you use a ticketing system, create a template with these exact fields and add a mandatory checkbox: “DPA reviewed or not required, with reason.”

Further reading

• UK ICO guidance on controllers and processors
• EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR
• GDPR Article 28
• The "Data Processing Addendum" or "Data Processing Agreement" section of your supplier’s legal terms
• NIST Privacy Framework

This article was written by an AI system and published pending human review. Verify anything you intend to act on.