> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Compliance
> Vorel's compliance posture: PDPL, GDPR, SOC 2 trajectory, HIPAA caveats. DPA template + region model + sub-processor disclosure.
This page is the regulator-facing companion to [Security overview](/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:
| Region | Sub-processor category | In-region? | Note |
| ------ | ---------------------- | -------------- | ----------------------------------------------------------------------------- |
| `us` | Database / cache | ✓ | US managed hosting (single-region today) |
| `us` | Voice orchestration | ✓ | US-hosted |
| `us` | WhatsApp ingest | ✗ | EU-hosted per the messaging partner's policy; US-tenant data transits EU |
| `eu` | Database / cache | ✓ (planned v1) | EU managed hosting on first signed EU customer |
| `eu` | Voice orchestration | ✗ | US-only orchestration; voice metadata transits US |
| `eu` | WhatsApp ingest | ✓ | EU ingest, native fit |
| `me` | Database / cache | ✓ (planned v1) | ME managed hosting on first signed ME customer |
| `me` | Voice orchestration | ✗ | US-hosted; a UAE telephony point of presence covers DID; metadata transits US |
| `me` | LLM inference | ✗ | Closest regional model endpoint is extra-region |
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:
| Requirement | Status |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **PII inventory** | Documented internally (every column / file / log line that holds end-customer or operator PII). |
| **Data flow diagram** | Documented internally. |
| **DPA template** | Pre-counsel draft maintained internally. Per-region appendices read from the canonical region registry. **Counsel review required before sending to a customer.** |
| **Right-to-access endpoint** | `POST /api/tenant/export` (operator-gated). Returns a ZIP of `conversations + messages + leads + appointments + offerings + knowledge_base + audit_log` for a single tenant. Default redacts customer email + phone; opt-out via `include_full_pii=true` (audit-logged). Includes a chain-of-custody README. |
| **Right-to-erasure endpoint** | `POST /api/tenant/forget` (operator-gated, dry-run-by-default). Runs a 7-step scrub for a single customer phone within a single tenant: tombstones conversations, redacts message content, nulls leads/appointments PII, scrubs audit-log JSONB references. Wrapped in a Postgres transaction for atomicity. |
| **Audit-log integrity** | The `audit_log` table rejects UPDATE + DELETE at the database level via triggers. Forensic trail survives platform-level scrubs. |
| **Salted-hash audit references** | The forget endpoint replaces customer phone in audit log JSONB with `sha256(salt + phone)`; deletion event is provable without re-introducing the PII. The salt is supplied by a required environment variable; production refuses to compute the hash if the salt is unset. |
| **72-hour breach notification** | Documented in the incident-response playbook (PDPL Art. 17, GDPR Art. 33). |
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
| Standard | Status |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SOC 2 Type 1** | **Not yet certified; targeted for Q4 2026.** Foundational evidence is shipped (PII inventory, data-flow diagram, incident-response playbook, control matrix, SLOs). The target date is contingent on selecting and onboarding a compliance-automation platform; that decision is still pending. |
| **SOC 2 Type 2** | A Type 2 follow-on (covering a multi-month operational observation window) may follow Type 1 for enterprise customers. No observation window is open today. |
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
| Standard | Status |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PCI SAQ-A** | **Live.** Vorel's PCI merchant scope is **SAQ-A**: outsourced payment processing with no electronic storage, processing, or transmission of cardholder data on Vorel systems. Implemented architecturally via a vault-redirect to a PCI-compliant payment provider. PAN/CVC/expiry never touch Vorel infrastructure. A CI lint gate refuses to merge a pull request that introduces DTMF card capture, PAN/CVC/expiry storage, or persistent tokens outside the provider's vault. See [Payments + PCI](/security/payments). |
| **PCI Level 1** | Not the path. An internal, audited policy documents the reopener conditions (enterprise customer ≥\$100K ACV, conditional contract, policy amendment, \~3 months engineering + \~6mo certification) under which Vorel-as-PCI-L1 would be re-litigated. Until then, vault-redirect is the architectural commitment. |
## 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 chained-mode reasoning and, where
applicable, voice (see [Voice pipelines](/product/voice-pipelines)).
* **Auth + observability:** an authentication provider, an error-monitoring provider, and a
distributed-tracing provider.
* **CRM (per-tenant):** the configured driver vendor for each tenant: HubSpot, Salesforce,
Zoho, Mindbody, Athenahealth, Tekmetric, Odoo, Toast.
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](/security/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
| Vorel-side row | Platform-default retention |
| ------------------------------------------- | ----------------------------------------------------------- |
| `messages` (per-turn transcript) | **7 days** post-insert AND post CRM-write success |
| `conversations` | **30 days** post-close AND post CRM-write success |
| `customers` + `customer_profiles` + `leads` | **30 days** post-update AND post CRM-write success |
| `appointments` | **60 days** post-scheduled-end AND post CRM-write success |
| `cases` + case child tables | **90 days** post-close AND post CRM-write success |
| `qa_evaluations` (aggregate) | **365 days** post-insert AND post CRM-write success |
| `resolution_events` | **365 days** post-classification AND post CRM-write success |
### Class (b): operational telemetry (selected entries)
| Vorel-side row | Platform-default retention | Purpose |
| -------------------------------------- | -------------------------- | ---------------------------------- |
| `voice_call_cost` | **365 days** | Billing reconciliation |
| `voice_call_cost.payment_resolution` | **365 days** | PCI reconciliation |
| `voice_turn_latency` | **90 days** | Latency regression window |
| `llm_calls` | **90 days** | LLM usage analytics |
| `webhook_deliveries` | **30 days** | Forensic-only after delivery |
| `shadow_dispatch_comparisons` | **30 days** | Pipeline cutover research artifact |
| `quality_signals` + `quality_failures` | **365 days** | Quality dashboards |
### 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](/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](https://vorel.ai/changelog) (with consent) once fixed.
## Related docs
* [Security overview](/security/overview): controls (RLS, encryption, rate limiting, SLOs)
* [Data handling](/security/data-handling): what we collect + where it lives + how to delete
* [Data retention](/security/data-retention): four-class taxonomy, ADR-locked per-class TTL windows, four architectural invariants
* [Payments + PCI](/security/payments): SAQ-A scope details, vault-redirect UX, hard-forbidden builds
* [Verticals → Clinic](/verticals/clinic): the safety-critical vertical pack
{/* verified-against: handoff/docs/security/DPA-TEMPLATE.md (region pinning at creation, sub-processor disclosure, 30-day notice, 72-hour breach notification) */}
{/* verified-against: handoff/docs/security/DATA-FLOW.md + INCIDENT-RESPONSE.md */}
{/* verified-against: apps/web/src/lib/security/forget.ts hashCustomerIdentifier (salted SHA-256, env-var salt, prod refuses dev fallback) */}