Zendesk removed its DPA: what to check before your next client review

What changed

On 27 September 2026, three changes to Zendesk's public legal documentation were detected in close succession. [src:vendor_change/03f979a1-fa21-44d6-9ff7-44d8a94a1d26]

The DPA was removed from its published URL. The document that previously sat at the Zendesk data processing agreement page is no longer accessible. That document covered three transfer mechanisms for international data transfers: standard contractual clauses, the EU-US Data Privacy Framework, and adequacy decisions. With the document gone, it is not clear which legal basis Zendesk now relies on for cross-border personal data transfers, nor whether the terms that were in the removed agreement remain operative. [src:vendor_change/03f979a1-fa21-44d6-9ff7-44d8a94a1d26]

The contracting legal entity is no longer visible. The same DPA named Zendesk, Inc. as the contracting entity. That entity is no longer identified in any currently accessible version of Zendesk's legal documents page. Any records that name a counterparty for data processing obligations now point to an entity whose current role is unconfirmed. [src:vendor_change/202628c2-bdbf-4115-a65c-3f60c1922b30]

The trust page became temporarily inaccessible. At the same time, Zendesk's trust centre returned a Cloudflare security verification screen rather than its usual content, making it impossible to review subprocessor information, data processing details, or agreement terms via that route. [src:vendor_change/6f542c4d-c6f8-472c-abb4-34efd854f4de] This was classified as minor severity and may be transient, but it compounded the difficulty of verifying anything on the day the other two changes were detected. [src:vendor_change/6f542c4d-c6f8-472c-abb4-34efd854f4de]

The DPA removal and the legal entity disappearance are both classified as critical severity. [src:vendor_change/03f979a1-fa21-44d6-9ff7-44d8a94a1d26] [src:vendor_change/202628c2-bdbf-4115-a65c-3f60c1922b30] The vendor profile was last verified on 16 September 2026 and updated on 27 September 2026. [src:vendor/zendesk]

It is worth noting what the profile previously recorded: the transfer mechanism was the EU-US Data Privacy Framework, and Zendesk operates data regions in the US, EU, and APAC. [src:vendor/zendesk] That combination matters because EU and APAC-sourced personal data flowing to US infrastructure requires a documented legal basis. With the DPA gone, that basis is currently unconfirmed in the public documentation.

---

Who it affects

Any client that processes personal data through Zendesk and is subject to a regime that requires a documented transfer mechanism should treat this as an open gap until the position is clarified. [src:vendor/zendesk]

The most immediate exposure is for clients in the EU or handling EU residents' data. GDPR Article 46 requires that a transfer to a third country rests on a documented mechanism — SCCs, DPF participation, or an adequacy decision. If the DPA that contained those commitments has been withdrawn, your client's record of the legal basis for the transfer is now unsupported by a live document. That is a gap in the records a supervisory authority would inspect. [src:vendor_change/03f979a1-fa21-44d6-9ff7-44d8a94a1d26]

The legal entity issue is a separate but connected problem. If your client signed a DPA with Zendesk, Inc. and that entity is no longer identifiable as the contracting party in current documentation, the question of who the counterparty actually is becomes live. This is not a theoretical point — see The brand is not the counterparty and A vendor changed its entity: which documents are now wrong for the practical consequences when this kind of shift goes unnoticed. [src:vendor_change/202628c2-bdbf-4115-a65c-3f60c1922b30]

Clients with significant customer-facing ticket volumes through Zendesk — where support interactions contain special category data, payment references, or data belonging to minors — face higher exposure from an unresolved transfer gap than those running lower-sensitivity support workflows. [src:vendor/zendesk] That is a judgement you need to apply client by client.

Clients under NIS2 who list Zendesk as a supplier in their ICT supply chain documentation should also note the entity uncertainty. Supply chain security documentation under NIS2 typically names the contracted entity; if that entity is now in question, the record may need correction. See Subprocessor lists: what changes when a vendor updates its DPA for the broader pattern.

---

What to do about it

Step one: attempt to retrieve the current DPA directly. Go to the Zendesk data processing agreement URL and record what you find. If the page is inaccessible or redirects, note the date and the response. Then check the Zendesk trust centre — the Cloudflare screen that was present on 27 September 2026 may have cleared. [src:vendor_change/6f542c4d-c6f8-472c-abb4-34efd854f4de] Document what you find either way.

Step two: check whether your client's existing signed DPA is self-standing. If your client executed a DPA directly with Zendesk rather than relying on the online click-through version, that executed document may still be valid. The question is whether it names a transfer mechanism and a legal entity that remain accurate. If the executed agreement incorporates the online terms by reference, the removal of the online document creates a gap regardless of the signature. [src:vendor_change/03f979a1-fa21-44d6-9ff7-44d8a94a1d26]

Step three: confirm the legal entity. Check what entity name appears in your client's records — purchase orders, the signed DPA, or the subscription agreement. The previously visible entity was Zendesk, Inc. [src:vendor_change/202628c2-bdbf-4115-a65c-3f60c1922b30] If a different entity is now counterparty, your client's records need to reflect that. See When a vendor has no public data processing agreement for how to approach the gap where documentation is absent.

Step four: contact Zendesk directly. If the public documentation remains inaccessible, raise a written request to Zendesk's privacy or legal team for the current DPA and confirmation of the contracting entity. Keep a record of the request and any response. That record is useful if a supervisory authority asks what steps were taken once the gap was identified.

Step five: update your client's records and ROPA entries. If your client maintains a record of processing activities, the entry for Zendesk should be flagged as pending confirmation of transfer mechanism and counterparty until the position is resolved. Do not leave the previous values in place as if they were still verified. The subprocessor list that Zendesk publishes separately may still be accessible and should be checked for currency. [src:vendor/zendesk]

Step six: consider whether interim measures are appropriate. Where the data involved is high-risk — health data, financial data, children's data — and the transfer basis is genuinely unresolved, your client may need to consider whether continued transfer to Zendesk's US infrastructure is supportable until a documented basis is restored. That is a proportionality assessment for the client and their legal advisers, not a decision this note can make for them.

---

For the broader skill of managing vendor documentation gaps as they arise, Answering vendor security questionnaires at scale covers the process of maintaining verified records across a large vendor portfolio — which is the only reliable way to catch a change like this before a client review or an audit surfaces it first.