Skip to main content
This page is the regulator-facing companion to Security overview. The overview covers controls; this page covers the paperwork posture: what we sign, what we disclose, what’s roadmap.

​
Region model

Each tenant is pinned to one region at creation time, set by the Vorel operator. Three regions ship today (us / eu / me). Region governs:
  1. Primary data storage location.
  2. Sub-processor selection where regional alternatives exist (e.g. a vendor’s US ingest endpoint vs. its EU ingest endpoint).
  3. Which DPA appendix applies.
Region is set at tenant creation and not editable post-creation in v1. Changing region is a data-movement engagement (separate scope). Today, a single US deployment on managed cloud infrastructure serves all tenants; eu and me regions are declared posture for DPA purposes, with per-region routing landing in v1 once a paying customer in that region triggers the provisioning. Until then, eu/me tenant data is hosted in our US region and disclosed to tenants via the DPA appendix for their region.

​
Per-region vendor reconciliation

The DPA appendix discloses, per region, which sub-processors are inside the region versus which transit other regions. Selected entries: Voice is the hardest residency story across all regions. The DPA discloses this explicitly rather than burying it. The full per-region reconciliation matrix is maintained from a single canonical region registry that the DPA appendices read from, so sub-processor regions stay in sync.

​
PDPL (UAE) + GDPR (EU)

Vorel’s data-protection paperwork posture is documented: The DPA template is the artifact tenants ask for. It’s pre-counsel; we’re not sending it to customers without legal review of the per-customer fill-in (entity name, region, scope).

​
SOC 2

We can share the underlying foundational documents (PII inventory excerpt, DPA template, SLO doc) under NDA today for a buyer’s due-diligence pass. We do not hold a SOC 2 report today; any report will publish on completion of its audit.

​
PCI DSS

​
HIPAA

Per-customer engagement only. The clinic vertical pack ships safety guards (forbidden_phrases='diagnose' etc.) but HIPAA is not turn-key. Running a HIPAA-grade workflow requires Business Associate Agreements (BAAs) with every PHI-touching sub-processor in the chain (telephony, voice transcription, speech synthesis, and LLM inference). If you need HIPAA: talk to your Vorel operator before the kickoff call. We can sign per-customer BAAs with the relevant sub-processors but the timeline + cost is real.

​
Sub-processor disclosure

The DPA template lists every sub-processor by region. Operators maintain the live list at the URL the DPA points to (TBD, counsel-approved location). Adding a new sub-processor or changing an existing sub-processor’s processing scope: 30 days notice to customers via the operator- configured contact email, with a chance to object. Today’s sub-processor set covers the following categories. The DPA names each specific vendor; the public summary describes them by function:
  • Cloud + transport: managed cloud hosting and edge/CDN providers (the KMS envelope path is dormant today; it reactivates with EU/ME hosting).
  • Telephony + voice: telephony/DID providers, a voice-orchestration provider, a speech-to-text transcription provider, and a text-to-speech provider.
  • Messaging: a WhatsApp Cloud business-messaging provider.
  • Payments: a PCI-compliant payment provider operating the vault-redirect and acting as merchant of record for payment collection on restaurant / salon / auto_service packs. PAN/CVC/expiry never touch Vorel infrastructure.
  • LLM: large-language-model inference providers for reasoning and, where applicable, voice.
  • Auth + observability: an authentication provider, an error-monitoring provider, and a distributed-tracing provider.
  • CRM (per-tenant): the CRM you choose to connect, and any other apps you connect yourself. See CRM and Apps.
The canonical region registry is the reference for the per-region in/out matrix.

​
Data retention + deletion

Retention windows are policy-locked: changing them requires a code change + a git-history-visible policy amendment, not a UI toggle. Per-tenant overrides exist for narrowing retention below the platform default; widening past the platform default requires an amendment to the internal, audited retention policy. See Data retention for the full four-class taxonomy and architectural invariants.
The architectural commitment is “your conversation transcripts live in your CRM, not in Vorel.” Vorel-side rows that hold transcript content or PII (class-(c)) are cached only until a successful CRM mirror, then purged on the ADR-frozen schedule.

​
Class (c): transcripts + PII

​
Class (b): operational telemetry (selected entries)

​
Class (d): audit-only (long-lived)

audit_log, billing_events, tenants, users, voice_cutover_event, lora_adapters, offerings, knowledge_base_entries, webhooks, voice_numbers, incidents, api_keys, and the configuration / prompt-management surfaces. Audit log retention is governed by the existing N-3 retention regime; the rest are long-lived by structural design with per-table rationale documented.

​
Subscription-term context

  • Customer Data, subscription term. Vorel retains tenant-scoped data for the duration of the subscription plus a 30-day grace period to allow final export, subject to the per-class TTL windows above (the class-(c) post-CRM-write purges run continuously during the subscription).
  • On termination. Deleted or returned within 60 days, except as required by law.
  • Audit log. Append-only; survives application-layer right-to-erasure scrubs. Salted-hash references replace raw PII so a deletion is provable without re-introducing the PII.
The right-to-erasure path runs against subset specifically (a single customer phone within a single tenant) with operator-side dry-run-by-default. Mass-erasure (entire tenant) runs at termination via the same primitives.

​
What we explicitly do NOT do

  • We don’t use customer-collected data to train third-party AI models. No tenant conversations or PII are shipped to model-training pipelines (ours or vendor-side).
  • We don’t sell, share, or analyse customer data across tenants. RLS enforces per-tenant isolation at the DB level (see Security overview).
  • We don’t repurpose tenant data for analytics outside their tenant. Per-tenant analytics surfaces only that tenant’s data; cross-tenant operator views (operator-side) are audit-logged.

​
Bug bounty + responsible disclosure

We don’t run a formal bug bounty program today. Email security@vorel.ai to report a vulnerability. We acknowledge within 48 hours, triage within 5 business days, and credit reporters in the changelog (with consent) once fixed.