Trust center
The public /trust page every brand gets — honest certification status, security controls, the no-training statement, sub-processors, and a DPA request form.
Every brand has a public /trust page. It needs no login, it is crawlable, and it is the page you point a prospect's security or procurement reviewer at when they ask "how do you handle our data?" — so it is written to be answered honestly rather than to close a sale.
What the page shows
| Section | What it states |
|---|---|
| Certifications | Each with an honest status — nothing is listed before it is attained. GDPR is shown as Supported, covering export/erasure, retention windows, and a signed DPA on request. |
| Security | Encryption in transit and at rest, strict per-workspace tenant isolation, two-factor authentication with step-up on destructive actions, an append-only audit trail, the SSRF guard on outbound bot actions, and signature-verified webhooks. |
| No training | A plain statement that customer data — conversations, knowledge bases, contact details — goes to AI providers for inference only and is never used to train models, by us or by them under the API terms we operate on. |
| Retention & residency | Per-workspace retention windows, automatic purge of finished conversations, the 90-day tombstone on deleted accounts, immediate GDPR erasure, and where data is hosted (a major cloud provider, in the deployment's primary region). |
| Sub-processors | Each processor category and what it is used for — hosting, AI inference, payments, and the messaging providers, some of which appear only when that channel is connected. The named vendor list travels with a signed DPA on request. |
It renders under your brand — but says the same thing everywhere
On a reseller's own domain the trust page carries your name, logo, colour, and contact. That is the only thing that is per-brand. The substance — certifications, their statuses, the security list, the no-training statement, and the sub-processor list — is centrally authored and identical for every brand on the platform.
That is deliberate, not a limitation. Every tenant runs on the same infrastructure and the same sub-processors, so a per-brand processor list would be a false one.
A reseller cannot publish a different sub-processor list, add a certification, or upgrade "in progress" to "certified" under their own brand. The list a client's reviewer reads is the real one, whichever brand's domain they read it on.
Request a DPA
The trust page carries a Request a DPA form. A reviewer submits their email (required), and optionally a company name and a message. It is unauthenticated by design, so it is tightly rate-limited per IP (up to 5 requests an hour) and always answers the same way — the response never reveals who the request was routed to, so there is nothing to enumerate.
Where the request lands depends on whose domain it was submitted from:
- On a reseller's live custom domain, it goes to that owning agency, so the agency handles its own client's DPA directly.
- Anywhere else — the platform's own trust page, or a brand not yet on a live custom domain — it goes to Evoriqa.
Either way the requester sees the same confirmation. There is no queue to check in the dashboard; the request arrives by email at the right destination.
Where to go next
- GDPR export and erasure — the data-subject flows the DPA commits you to
- Data retention — the windows the trust page describes
- AI disclosure — telling visitors they are talking to an AI
- Branding and domain — putting the trust page on your own hostname
Last updated