Ticket Merger

The Zendesk DPA

The Zendesk DPA is the contract that says what a vendor may and may not do with data you're responsible for. Most teams sign it and never read it.

Start free trialAll guides

What the Zendesk DPA is for

Under GDPR, a controller has to have a written agreement with any processor handling personal data on its behalf. The DPA is that agreement. It is an addendum because it bolts onto your subscription contract instead of replacing it.

The point of it is enforceability. A security page is a promise. A DPA is a promise with a remedy attached, which is why procurement asks for it and why your own customers ask you for one in turn.

Equivalent addenda exist for other regimes: UK, Swiss, and a growing pile of US state privacy laws. Vendors usually fold them into one document with jurisdiction-specific schedules. Read which regimes yours actually names, because assuming coverage is how gaps happen.

What it typically covers

Scope and instructions. What may be processed, for what, and the commitment to act only on your documented instructions.
Confidentiality. Personnel with access are bound to confidentiality.
Security measures, usually referenced to an annex or to the trust centre rather than written out inline. That means they can change, so check how changes are notified.
Sub-processor terms, covered below because they matter more than people expect.
Assistance. Help with data subject requests, impact assessments and regulator questions.
Breach notification, with a timeframe. Read the timeframe. It's one of the few numbers in the document that will matter at two in the morning.
Deletion or return of data when the contract ends, and how long that takes.
International transfers, typically standard contractual clauses attached as an annex.

Sub-processors, and why the list matters

A sub-processor is a company your processor uses to help deliver the service: hosting, mail delivery, analytics, their own support tooling. They touch some of your data and you never chose them. That's normal, and it's also the part of the chain most organisations have the least visibility into.

The DPA should tell you how new sub-processors are notified and what you can do about one you object to. Read that clause properly. The remedy is often narrower than people assume, and it frequently amounts to a right to leave rather than a right to have that vendor excluded.

Practical advice: subscribe to the vendor's sub-processor change notifications if they offer them, and send them somewhere that isn't one person's inbox. Then pull the current list from Zendesk's own legal pages on the day you need it. Never copy a sub-processor list out of an article, including this one. It changes.

Where to find it and how to sign it

Vendors at this scale generally publish a standard DPA on their legal pages, and it's often either incorporated into the main agreement by reference or available to accept electronically. Sometimes there is nothing to sign and you simply need a copy for the file.

Ask your account team or check Zendesk's legal and trust pages for the current route, rather than assuming you're covered because somebody said so in 2021.

Then store the executed copy with its version and date somewhere your auditor can find it in under a minute. Half the pain of a security review is document archaeology, and it is entirely avoidable.

One more habit worth building: put a recurring reminder against renewal to check whether the published version has moved on from the one in your file. Vendors revise these documents, sometimes for good reasons like a new transfer framework, and the copy you signed three years ago doesn't update itself. Ten minutes a year, and it's the difference between a clean answer and a fortnight of email.

What the DPA doesn't cover

It doesn't make you compliant. It covers one relationship. Your lawful basis, your retention, your internal access control and your other twelve vendors are all still yours. See Zendesk and GDPR.
It doesn't govern your agents. An agent pasting customer details somewhere they shouldn't is your incident, not the processor's.
It stops at the boundary. Data you push into a warehouse, a BI tool or a Slack channel is a separate flow needing separate agreements.
It rarely covers marketplace apps. Those are third parties with their own terms. Installing one is your decision and your data sharing.
It isn't legal advice, and neither is this article. Your counsel reads the actual document, ideally before renewal rather than during an incident.
FAQ

Frequently asked questions

Where do you find and sign the DPA?

In the Zendesk legal centre. The Zendesk data processing agreement, formally the Zendesk data processing addendum, is signed there and includes the Zendesk standard contractual clauses for transfers. The Zendesk sub-processors list is published alongside it and worth subscribing to.

Do we need a DPA with Zendesk?

If personal data subject to GDPR or a similar law is processed on your behalf, a written processing agreement is required. Most teams using a helpdesk are in that position.

Is the DPA the same as the terms of service?

No. The main agreement is commercial. The DPA is the data protection layer on top of it, and it usually incorporates transfer clauses as annexes.

Where do I get a copy of the Zendesk DPA?

Zendesk's legal and trust pages, or your account team. Get the current version rather than reusing whatever was filed at signup, because these documents get revised.

What happens if we object to a new sub-processor?

Read the objection clause. There is normally a defined notification window and a defined remedy, and the remedy is often termination rather than exclusion of that sub-processor from the service.

Does the DPA cover apps we install from the marketplace?

Usually not. Those vendors have their own terms and their own processing. If an app reads ticket data, it belongs in your own record of processing activities.

One fewer processor to paper

Every tool touching your queue is another agreement to keep current. Ticket Merger reads tickets to compare them and keeps no conversation content beyond that comparison.

Start free trial

14-day free trial. No credit card required.

Keep reading

Zendesk and GDPR: What Your Support Team Must Do
Controller or processor, handling data subject requests, deletion versus redaction, retention that's actually enforced, and the GDPR checklist for a Zendesk team.
Zendesk Security and Compliance: What to Check
The Zendesk security settings worth auditing, what the trust centre covers, data residency and retention, and the questions procurement will ask.
Ticket Merger Security: How Your Data Is Handled
Ticket Merger security in detail: what it reads, what it stores, what it never touches, with native API access, least privilege and no retained ticket content.