Security and trust
Your customers trust you. Here is why you can trust us.
What we do to keep support data safe, where it lives, and how to report a vulnerability. Everything not in place yet is marked as planned.
Animated demo of ChaosDesk security settings: the admin enforces single sign-on through Okta and requires two-factor sign-in for staff; each change, a passkey sign-in and a sign-in blocked by the IP allowlist appear in the live audit log.
How we protect it
Six things every workspace gets
On every plan, the free one included.
Data stays in the EU
Every workspace is hosted in the EU, on every plan. Backups stay in the same region.
Workspace isolation
Every record, search index, file, cache key and realtime channel is scoped to its workspace, and the database enforces it with row-level security. Cross-workspace access is the first thing our tests and reviews look for.
Encryption
TLS for every connection. Integration secrets are encrypted with a key that belongs to your workspace alone, so deleting that key makes them unreadable everywhere, backups included.
Append-only audit trail
Ticket history cannot be edited or deleted, the database enforces it. Admin changes and ticket access are logged.
Hardened by default
Sanitised rich text and help-centre themes, protection against server-side request forgery on every outbound call, and static, dependency and secret scanning on every change.
AI with privacy
Personal data is redacted before text goes to an AI provider, your data is never used to train models, and admins can switch AI off completely.
Controls for your team
Sign-in, access and audit, set by your admins
- Two-factor sign-in with an authenticator app, passkeys and security keys
- Agent single sign-on with SAML or OpenID Connect, SCIM provisioning
- Password rules, required two-factor and session length per workspace
- IP allowlists, audit log export and SIEM streaming (Enterprise)
- A customer-managed encryption key (Enterprise)
Compliance
Where we stand, without rounding up
| Topic | Status | Details |
|---|---|---|
| GDPR | Built for it | Data processing agreement, EU hosting, erasure requests with four-eyes approval, retention policies and redaction rules. |
| Data processing agreement | Draft, final before launch | Our standard DPA, with the EU Standard Contractual Clauses where needed. |
| External penetration test | Planned before launch | An independent test of the app, API, help centre and messenger. The summary will be available on request. |
| SOC 2 Type I and II | Planned | The compliance programme starts before launch; we will publish the timeline on the trust centre. |
Legal documents: DPA, subprocessors, privacy policy. Full status: trust centre.
Responsible disclosure
Found a problem? Tell us privately.
Write to [email protected] with the URL or endpoint, steps to reproduce and the impact you see. Our security.txt has the same contact.
3
Business days to acknowledge
10
Business days to assess
90
Days until public disclosure at the latest
- We fix critical issues as a priority (typically within 30 days), keep you informed, and credit you if you wish.
- Good-faith research within these rules is welcome and we will not take legal action against it.
In scope
The web app and API, hosted help centres and portals (custom domains included), the messenger widget and its API, and this website. We care most about access across workspaces, account takeover, SSRF, stored XSS and authentication bypass.
Rules
- Test only against workspaces you own. Stop at the first sign of another customer's data and tell us.
- No denial of service, spam, social engineering or physical attacks. Keep request rates low.
- Disclose publicly after the fix, or after 90 days, whichever comes first.
Out of scope
Content our customers publish, header or cookie best practice without a demonstrated impact, clickjacking without a sensitive action, self-XSS, scanner output without a proof of concept, and third-party services.
Thanks
Researchers who reported valid issues will be listed here, with their permission.