The authoritative statements live on the Trust centre, the Security
policy and the Subprocessor list. This page summarises
them for readers who are in the documentation, and adds the concrete retention periods.
Isolation
Every record in Zudo belongs to exactly one organization, and every query is scoped to the organization of the requesting user or API key. That scoping is applied in middleware rather than per-route, so a route can’t forget it. Switching organizations changes what you can see immediately: a request for an account outside your current organization returns404, not a filtered-empty result, so the existence of another tenant’s records isn’t observable.
Access control
Data in transit and at rest
Traffic is encrypted in transit, and data is encrypted at rest. Integration credentials are encrypted separately from the records they unlock. The Trust centre is the canonical statement of both.Retention
Different kinds of data age out on different schedules. A nightly job enforces these:
Product events are also archived as gzipped JSONL in object storage so historic events can be replayed if you change which ones you roll up. Archive lifecycle is configured on the storage bucket rather than by the application.
Deleting and exporting
Disconnecting an integration stops the sync and revokes the stored credential. Accounts, contacts and related records can be deleted from the app, and exported through the API. See the Trust centre for how deletion requests are handled.Reporting a vulnerability
Report security issues through the Security policy page, which carries the current contact address and disclosure expectations.https://zudo.so/.well-known/security.txt is published per RFC 9116.
