Before you sign a support tool, get three things in writing: the exact regions your data is stored and processed in, the full sub-processor list, and how per-tenant isolation is enforced and tested. Residency is only real if it covers backups, search indexes, logs, and email infrastructure — not just the primary database. Treat vague answers like “hosted in the US” as a red flag, not a reassurance.
Where does the data live?
Ask for specific regions, and whether residency is enforced at write time — including backups and search indexes, the places it usually leaks. “US or EU” should be a setting, not a sales promise. Get the answer per data class, because a tool rarely keeps everything in one place:
- Primary store. Tickets, contacts, and messages — usually the easy part to pin down.
- Backups and snapshots. Often replicated to a second region for durability. Ask whether that second region is inside your residency boundary.
- Search indexes. Full-text search frequently runs on a separate service that holds a copy of your message bodies.
- Attachments and object storage. Files are commonly stored in a bucket that may have its own region setting.
- Logs and analytics. Request logs and product analytics can carry email addresses and message snippets to a third region entirely.
- Email transit. Outbound mail leaves through an SMTP provider. With BYODKIM through your own AWS SES account, you choose that region yourself.
The honest test: ask the vendor to name the region for each row above. If they can only answer for the database, residency isn't actually enforced end to end.
What counts as “your data”
“Customer data” is broader than the ticket table. Personal data hides in metadata most buyers forget to scope:
- Email headers and routing info, including Return-Path and original sender addresses.
- Contact records and any custom fields you sync from a CRM or billing system.
- Chat transcripts and any presence or typing signals captured by a live-chat widget.
- Audit logs that record which agent viewed or edited which ticket — useful, but themselves sensitive.
- AI features: if drafts, summaries, or translations are generated, ask where prompts and outputs are processed and whether anything is retained. Cherryrise's AI assist is admin-gated and opt-in, so this is a decision you make, not a default you inherit.
Who else touches it?
Get the sub-processor list and how you’re notified of changes. Every vendor in the chain is part of your compliance posture. A usable list names each sub-processor, what they do, and which region they operate in — hosting, email, search, error tracking, and any AI provider. Then ask the operational questions:
- How much advance notice do you get before a new sub-processor is added, and can you object?
- Is the list versioned and dated, or just a paragraph in a policy that changes silently?
- For AI features, is there a sub-processor at all, and is your data excluded from model training?
If you need the shortest possible chain, that is one of the strongest arguments for self-hosting: the sub-processor list collapses to the infrastructure you already run.
How is it isolated?
In a multi-tenant platform, confirm isolation fails closed and is verified by tests, and that RBAC is enforced server-side. The questions that separate real isolation from a marketing claim:
- Fails closed. If a tenant identifier is missing from a query, does the request error out, or does it return rows? It should error.
- Server-side enforcement. Authorization decisions live on the server, never in the client. A hidden button is not access control.
- Tested, not asserted. Ask whether isolation is covered by automated tests that try to read across tenants and expect to fail.
- Least privilege for staff. Vendor support engineers should need explicit, logged, time-boxed access — not standing admin on every workspace.
Self-hosting, covered in when self-hosting is worth it, sidesteps the multi-tenant question entirely by giving you a single tenant: your own deployment.
Cross-border transfers
Residency at rest is not the whole picture. Data can still cross a border in transit or during support operations. Map those paths explicitly:
- Does support tooling let staff in another region view ticket contents during troubleshooting?
- Are there read replicas or CDN edges that cache content outside your chosen region?
- For email, where does the outbound provider route mail, and where are bounce and complaint events processed? Your DMARC reports and feedback loops carry recipient data too.
The goal isn't zero transfers — it's knowing exactly which ones happen so you can document them for your own compliance review.
Deletion, export, and retention
You should be able to leave cleanly. Confirm the lifecycle before you depend on it:
| Action | Ask for |
|---|---|
| Export | A full, machine-readable export of tickets, contacts, and attachments — not a CSV of subject lines. |
| Deletion | Whether deletes propagate to backups and search indexes, and the maximum window until they're purged. |
| Retention | Configurable retention windows per data class, and what happens to data after you cancel. |
| Logs | How long audit and access logs are kept, since they contain personal data too. |
If you ever migrate in, the same export quality matters going out — see the practical notes in migrating from Zendesk and migrating from Freshdesk.
The questions to put in writing
Turn the above into a short list you send before signing, and keep the answers with the contract:
- Name the storage and processing region for each data class: database, backups, search, attachments, logs, email.
- Provide the dated sub-processor list and your notice-and-objection process for changes.
- Describe how tenant isolation fails closed and how it's tested.
- List every path by which data crosses a region boundary, including staff access.
- Document export format, deletion propagation to backups, and retention windows.
- State whether self-hosting or a regional deployment is available if requirements tighten — see the security page for how Cherryrise handles this, plus RBAC for support teams for the access-control side.
Frequently asked questions
Is data residency the same as GDPR compliance?
No. Residency is about where data is stored and processed; GDPR compliance is a broader legal obligation that includes lawful basis, data-subject rights, and transfer mechanisms. Choosing an EU region can support a compliance story, but it does not by itself make you compliant.
Does residency cover backups and search indexes?
It should, but it often doesn't by default. Backups are frequently replicated to a second region for durability, and search runs on a separate service holding a copy of your message bodies. Ask the vendor to confirm the region for each, in writing.
Can self-hosting replace a residency guarantee?
For many teams, yes. Running the platform on your own infrastructure keeps data inside your environment and collapses the sub-processor list to services you already control. The trade-off is that you own deploys, backups, and upgrades instead of the vendor.
What should I ask about AI features and data residency?
Ask whether AI features are on by default, where prompts and outputs are processed, whether any data is retained, and whether your data is excluded from model training. In Cherryrise, AI assist is opt-in and admin-gated, so it is off until you deliberately enable it.
See how Cherryrise handles residency, sub-processors and isolation on the security page.