Data Processing Agreements and Subprocessors

Every tool that touches your customer conversations — your CRM, your hosting provider, the AI service drafting replies — is handling that data on your behalf. A data processing agreement, or DPA, is the contract that writes down what it is allowed to do with it. If you serve customers in Europe you are expected to have one with each vendor; Gulf frameworks increasingly ask the same. This article sits inside The In-Depth Guide to Data Privacy and Compliance on WhatsApp, and it is operational guidance rather than legal advice — confirm what your specific business needs with your own legal counsel.

What a DPA is, in plain language

A DPA is a written agreement between the business that decides why customer data is collected and the company that handles it on those instructions. It sets out what the data may be used for, how long it is kept, what security measures apply, what happens when something goes wrong, and what happens to the data once you leave. Without one, a vendor holds your customers' phone numbers and chat history with no documented limits on what it may do with them.

Controller and processor: which one are you

In most cases you are the controller: you decided to collect the phone number, you chose to message the customer, you set the purpose. Your CRM, hosting provider and analytics tool are processors acting on your instructions. The distinction matters because complaints and access requests land on the controller — when a customer asks what you hold about them, "our vendor has it" is not an answer. Occasionally a vendor is also a controller for a narrow slice of data, such as usage telemetry, and a good agreement says so explicitly.

What to actually read

Most vendors publish a standard DPA and ask you to accept it with the terms of service, so this is rarely a negotiation. Nobody reads one end to end either, and you do not need to — five sections carry most of the weight:

1. Purpose limits — the vendor should handle your data only to deliver the service and on your documented instructions, not to train models or build separate products unless you have agreed to that on its own terms.
2. Security commitments — concrete measures such as encryption in transit and at rest, access controls and staff confidentiality obligations, plus any certifications and when they were last reviewed.
3. Breach notification — a stated timeframe for telling you about an incident. You have your own reporting deadline to meet, so an open-ended promise with no hours attached is worth questioning.
4. Deletion on termination — whether your data is deleted or returned when you leave, in what format, and how long backup copies persist afterwards.
5. Audit rights — whether you can ask for evidence that these commitments are real, and whether that means a questionnaire, an independent report, or an actual audit.

The subprocessor list is the part people skip

Your vendor has vendors. The CRM you bought runs on someone's cloud infrastructure, sends email through a delivery service, takes payments through a processor, and may route text through an AI model hosted by a third party. Each of those is a subprocessor with some level of access to your customers' data. A serious vendor publishes the list openly, names what each one does and says where it operates; hesitation on that question is a signal. The list is also where you find out which countries are in play, which leads straight into Data Residency: Where Your Customer Data Lives.

“

If a vendor can't tell you who its own vendors are, it can't tell you where your customers' data goes.

— be digital ai team

Keep a simple register of who processes what

You do not need compliance software for this. One spreadsheet, reviewed twice a year, covers most small and mid-sized businesses. For each tool that touches customer data, record:

• The vendor name and what the tool is actually used for.
• Which categories of customer data it sees — phone numbers, chat content, payment details, uploaded files.
• Whether a DPA is in place and where the accepted copy lives.
• Where the vendor stores the data and which subprocessors are involved.
• Who internally owns the relationship, so the review has a name attached to it.

Re-check when a vendor changes its list

These lists are not static. Vendors switch cloud regions, add an AI provider, or replace a payment processor. Most agreements commit the vendor to giving notice before a new subprocessor goes live, often with a window for raising an objection. That notice usually arrives by email or through a change page you can subscribe to — so subscribe, and route it somewhere a person actually reads. When a change lands, update your register and ask whether it affects anything you have already told customers. The same discipline applies to your records of what customers agreed to, which is why Keeping Consent Records That Survive an Audit pairs well with this one.

None of this makes for an exciting afternoon. But when a customer or a regulator asks who has access to their conversations, a current register is the difference between a two-minute answer and a two-week scramble.