Zendesk and GDPR
Zendesk GDPR obligations don't care that support is busy. They care who decided to collect the data, and what happens when somebody asks for all of it back.
Controller, processor, and why it decides everything
In almost every support setup, your company decides why the data is collected and what it's used for. That makes you the controller. Zendesk runs the software and processes that data on your instructions, which makes it the processor. Confirm the roles against your own agreement rather than against an article, because what you signed decides this, not what feels right.
The split matters because the obligations follow it. The controller answers to the person whose data it is. The controller decides retention, decides lawful basis, and is the one a regulator writes to. The processor has to keep the data secure, tell you about breaches, and act only on documented instructions. That last obligation is the entire reason a data processing addendum exists.
If you run Zendesk on behalf of somebody else, as an outsourced support provider does, your role may be different and possibly both. Get that checked properly. Nothing here is legal advice, and the shape of your contract matters more than the shape of your helpdesk.
Data subject requests, the version that actually arrives
Build the search path once, write it down, and time it. Requests come with a deadline, and finding out how long yours takes on the day you're already late isn't a plan.
Deletion and redaction are different jobs
People use the words interchangeably and then do the wrong one.
Deleting an end user removes the profile, and depending on how you do it, their tickets with it. Zendesk separates a soft delete from a permanent one, and only the permanent path genuinely satisfies an erasure request. It cannot be reversed.
Redaction removes a specific string from a specific comment: a card number, a password, an address somebody typed by accident. It leaves the person and the ticket in place. There is more detail in the redaction guide.
The trap is everything downstream. Exports sitting in a warehouse, a CSV somebody pulled last quarter, Slack notifications, a linked Jira issue, the mail server the message arrived through. Erasure inside Zendesk doesn't chase the data into any of those, and your obligation covers all of them. Older archived tickets are also more restricted in what you can do to them, which is a decent argument for handling requests promptly rather than in a batch.
Retention, the policy nobody enforces
GDPR doesn't hand you a number of months. It says don't keep personal data longer than you need it for the purpose you collected it for. That's your judgement, it has to be written down, and then it has to actually happen.
Pick a period per data type. Support conversations, call recordings, chat transcripts, satisfaction comments. Then check what your plan can enforce automatically, because a retention policy the software cannot apply becomes a manual clean-up that nobody does. Some of the automated retention capability sits in a paid add-on rather than in the base product, so confirm what you have before you promise a regulator anything.
The practical Zendesk GDPR checklist
That's the operational half and it's the half you control. The legal half belongs to your own counsel, who should read your actual contract rather than a summary of it.
Frequently asked questions
How do you handle a data subject request?
A Zendesk data subject request means finding every ticket, user and identity for that person, then deciding between redaction and deletion. The Zendesk right to be forgotten workflow uses the deletion endpoints, and GDPR help desk compliance rests on your retention policy as much as on the tooling. Zendesk GDPR compliance is shared: they provide the controls, you decide what to keep.
Is Zendesk GDPR compliant?
That question has no clean answer, because compliance is a property of your processing rather than of a product. Zendesk provides the processor side: contractual commitments, security controls and the tooling for deletion and export. Lawful basis, retention, request handling and configuration stay yours. Ask Zendesk for current documentation rather than relying on a third-party claim.
Who is the data controller when we use Zendesk?
Normally your company, because you decide why the data is collected and what happens to it. Confirm it against your agreement, especially if you handle support on behalf of another business.
Does deleting a ticket satisfy a right to erasure request?
Not on its own. Erasure usually means removing the end user record permanently, and it still doesn't touch exports, warehouses or connected systems holding copies. Map those before you confirm anything to the requester.
How long can we keep support tickets?
There's no fixed period in the regulation. You choose a period you can justify for the purpose, document it, and then enforce it. Legal or tax obligations may set a floor.
Do we need a signed DPA with Zendesk?
If personal data covered by GDPR is processed on your behalf, a written agreement is required. Get the current one from Zendesk and store the executed copy where an auditor can find it.
Every duplicate is a second copy
A duplicate ticket holds the same personal data twice, and the second copy is the one that gets missed on a deletion request. Ticket Merger removes it before it becomes a problem.
Start free trial14-day free trial. No credit card required.