Compliance

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.

​

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 chained-mode reasoning and, where applicable, voice (see 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

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.

​

Related docs

• Security overview: controls (RLS, encryption, rate limiting, SLOs)
• Data handling: what we collect + where it lives + how to delete
• Data retention: four-class taxonomy, ADR-locked per-class TTL windows, four architectural invariants
• Payments + PCI: SAQ-A scope details, vault-redirect UX, hard-forbidden builds
• Verticals → Clinic: the safety-critical vertical pack