Security & data protection in Zendesk: the basics, seen through a Swiss lens
Security in Zendesk isn’t a feature you switch on, it’s a set of decisions: who may do what, how long data stays, where the servers sit. For a regulated Swiss operation these aren’t nice-to-haves, they’re the questions the auditor asks first. This blueprint lays out the basics without the brochure tone. It’s orientation, not legal advice.
Where to start? Since 2025, Zendesk gives you a starting point: the security-posture dashboard under Admin Center → Account → Security → Security overview. It shows a health score and concrete recommendations for which settings are still open. From there you work through the three axes: access, data, location.
Access: roles, 2FA, SSO
The first lever is the principle «as much access as needed, as little as possible». Zendesk has the standard roles Admin, Agent and End-User; on top of those, Light Agents, who write internal comments only and can’t edit anything. If you want finer control you need Custom Roles, which start at the Enterprise plans (up to 197 roles). That’s where least privilege lives: support people see tickets, but not the account settings.
2FA applies only to Zendesk’s own login (email/password), not to SSO, SAML, JWT or Google login. You enforce it under Admin Center → Account → Security → Advanced (Authentication tab). Separately, Zendesk is rolling out a mandatory two-step verification (2SV). It isn’t identical to app-based 2FA and applies to accounts using Zendesk authentication. A first phase ran between 27 October and 5 November 2025, a follow-up rollout between 23 February and 5 March 2026.
If you want a central identity, you use SSO/SAML: login, MFA, conditional access and de-provisioning then run in your own identity provider (Entra ID, for instance). Important and easy to miss: with SSO, Zendesk’s own 2FA no longer applies. The MFA requirement has to be enforced by the IdP.
Zendesk is also modernizing authentication for the APIs. API tokens and password login as a method for API requests are being deprecated (deprecation 2025/2026); the path leads to OAuth. If you hang integrations or scripts off Zendesk, plan the switch early, otherwise token-based calls break after the cutoff date.
You keep this traceable through two logs you shouldn’t confuse: the audit log (Enterprise and up, Admin Center → Account → Logs) records changes to the account and, according to Zendesk, is kept indefinitely. The access log shows which data an agent viewed (last 90 days). But it belongs to the paid Advanced Data Privacy and Protection (ADPP) add-on.
public/werkstatt/bauplaene/sicherheit-datenschutz/authentication.png
Data: storage, deletion, location
By default, Zendesk deletes nothing on its own. Closed tickets are archived after 120 days, and only archived tickets are picked up by automatic deletion. That runs through deletion schedules: for inactive end-users, archived tickets, attachments, bot-only conversations (Flow Builder / Answer Bot) and custom-object records. Without the add-on, exactly one schedule per type is active; with ADPP, up to ten. The bot conversations are the part people easily forget: PII lands there fast and unstructured.
Encryption is there out of the box: encryption at rest (primary and DR data stores, attachments) and in transit (TLS); the data centers are ISO-27001 and SOC-2 certified. If you want to manage your own keys, you need ADPP. Its advanced encryption ties in your own KMS (AWS KMS, Azure Key Vault, Google Cloud KMS or Thales CipherTrust Manager).
The location is central for the Swiss lens: Zendesk runs on AWS, and the default region isn’t necessarily Europe. EU hosting is available only through the Data Center Location add-on; a Swiss region doesn’t exist. The add-on is free from Suite Professional upwards, but has to be actively chosen, ideally already when the account is created. On top of that, ADPP covers redaction: manual redacting (of credit-card numbers, say) works natively, but automatic redaction, data masking and redaction suggestions are ADPP features.
The Swiss lens: revDSG
The revised Data Protection Act (revDSG) has applied since 1 September 2023. For a Zendesk operation that means three concrete things: a record of processing activities, a data processing agreement (DPA) with Zendesk as processor, and clean rules for disclosure abroad. The last point is the touchy one: if data goes to the US, you need safeguards; for Switzerland there’s the Swiss-U.S. Data Privacy Framework. Whether Zendesk is certified and whether that holds for your case belongs with the legal review.
On top of that come the data-subject rights. If someone requests access or deletion, you have to be able to remove or redact a specific person together with their tickets. Zendesk deletes an individual end-user along with their tickets, redacts PII in individual tickets, and lets you automate both through the API. Without this process, the right to erasure stays theory.
In practice, EU hosting eases the cross-border question, and ADPP supplies the tools (access log, deletion plans, redaction, your own keys). But tools aren’t governance: who may see what, how long it stays, who reviews the logs, that stays your job, not the product’s.
And to be clear once more: this is orientation, not legal advice. For a binding assessment you bring in data-protection or legal counsel: DPIA, DPA wording, adequacy of the transfer.