Vereli Trust & Security

v0.1, 17 August 2026, published 24 August 2026 at /security. Drafted by Claude, cross-checked against Volume 4 §9.3, §14.1–§14.4, and Vereli_PrivacyPolicy_v0.1.md for factual accuracy. This is a drafting aid, not legal or security-certification advice — have a lawyer review anything that reads as a contractual commitment.

Data retention and sub-processor regions verified 24 August 2026 (see each section) — six of seven sub-processor rows are confirmed; n8n Cloud's region remains genuinely open. The incident-response targets below and the status page question are real founder decisions still open, not missing research — see those sections for what's actually undecided.

Raised by the upper-ICP merchant persona in the merchant feedback backlog: procurement at that tier would not engage without a security overview, subprocessor list, and residency/retention statement they can hand to their own compliance function. This is the merchant-facing page that answers those questions in one place — near-zero cost to produce, real cost (a stalled sales conversation) to leave missing.

Where your data lives

Australia. Vereli's database (Supabase) runs in the Sydney region. Personal information about your customers is not moved to a different region as part of normal operation. Some sub-processors below operate outside Australia as part of providing their service to Vereli — see the table for which.

How your data is protected

Encryption in transit and at rest. All connections use TLS. Database-level encryption at rest is managed by Supabase.
Per-merchant data isolation, enforced at the database layer. Row-level security policies ensure one merchant's data is never visible to another — this isn't just an application-code convention, it's enforced by Postgres itself, and a dedicated cross-tenant isolation test runs in CI on every schema or access-policy change before it can ship.
No merchant secret is ever exposed. Shopify access tokens and SMS provider credentials are stored as vault references, never as plaintext in application code, log output, or anything sent to a browser.
A single, non-bypassable checkpoint for every outbound message. Before any SMS is sent, it passes one compliance gate that checks consent status, opt-out history, quiet hours, subscription/billing status, and rate limits. There is no code path that sends a message around this check.
AI output is validated before it can reach a customer, independent of what the model itself decided to say — no invented discount codes, no invented delivery or refund claims, no therapeutic or medical claims. Failing validation triggers a safe fallback, never a blocked send that silently disappears.
Your data is never used to train AI models. The AI provider (Anthropic) is configured accordingly.

Sub-processors

Every third party that processes any of your or your customers' data in the course of providing Vereli, and what they're used for. This is the same list Vereli_DPA_v0.1.md §7 incorporates by reference — maintained here, in one place, rather than duplicated in the DPA and left to drift.

Sub-processor	Purpose	Data involved	Location
Shopify	The commerce platform Vereli integrates with	Checkout, order, and customer data your store already holds	Determined by your own Shopify plan and region settings, not a Vereli choice — Shopify is a global platform and stores its merchants' data according to each merchant's own configuration.
Supabase	Database and backend infrastructure	All Vereli-held data	Sydney, Australia
Twilio	SMS delivery (your own Twilio account, or Vereli's managed pool)	Phone numbers, message content, delivery status	Depends on which delivery model you use — corrected 26 August 2026. Under Managed, Vereli owns the account and chooses Ireland over the US default as the more privacy-protective option available. Under BYO, the account is yours: the region is set in your own Twilio account and defaults to the United States unless you change it. Vereli cannot set it for you and does not claim to. Vereli does, however, detect which region your account uses when you connect it, and routes your sends to that region — so if you have moved your Twilio account to Ireland for your own data-residency reasons, Vereli honours that without you having to tell us, and without you having to trust us to have configured it correctly. No Australian region exists for SMS under either model.
Anthropic	AI-generated message text and reply classification	Cart context, message content sent to the model per-call; not retained by Anthropic for training, and no persistent Anthropic-side storage of your customers' data beyond the call itself	US-headquartered. Anthropic automatically deletes API inputs/outputs within 30 days (verified against their published terms, 20 August 2026) unless a zero-retention arrangement is in place — Vereli does not currently hold one.
Vercel	Application hosting	Application traffic; no persistent customer data storage	US (confirmed 24 August 2026 via the deployment's own `x-vercel-id` response header — Vercel's default function region, `iad1`/Washington D.C., since no region override is configured). Lower stakes than the other rows: Vercel holds no persistent customer data, only traffic in transit.
n8n Cloud	Workflow orchestration between Vereli's own services	Trigger payloads (IDs and references, not full message content) — see Volume 4 §11 for what actually crosses this boundary	Not yet confirmed. n8n Cloud's hosting region is an account-level setting, not visible from the deployed application — needs checking directly in n8n Cloud's own account settings before this row can be marked resolved.
Resend	Email delivery — both merchant transactional email (handoff alerts, weekly reports, data-request notifications) and, from Sprint 9, recovery email sent to your customers	Merchant contact email and alert/report content; and your customers' email addresses and the recovery message content sent to them	Ireland, chosen for the same reason as Twilio's — no Australian region exists for email delivery either.

Sending information to a provider outside Australia is a cross-border disclosure under Australian privacy law, and Vereli remains accountable for how those providers handle it. Where a provider offers a choice of region, Vereli chooses the more privacy-protective one rather than the default — that choice is recorded per-row above rather than asserted in general terms.

One row genuinely still open: n8n Cloud's region needs confirming in the account's own settings before this table is fully resolved. Recorded as open rather than guessed at — the rest of this table is now verified, not assumed.

Data retention

Corrected 24 August 2026. This table previously stated "12 months" for transcripts and "30 days" for an uninstall purge — neither matched any mechanism that exists. Restated here to match Vereli_PrivacyPolicy_v0.1.md and the DPA exactly, per the founder's 18 August decision that the 90-day purge is the actual intended policy, not a placeholder for something faster:

What	Retained	Then
Customer personal information, including message content	90 days after conversation close	Purged automatically. Aggregate statistics (a message was sent, when, whether it converted) are kept for reporting; the personal information behind them is not.
Webhook delivery records	90 days	Purged — kept for fraud and reliability purposes only

This 90-day purge applies whether or not you've uninstalled Vereli. Uninstalling stops any further messages and marks the store inactive, but does not itself trigger a separate, faster purge. If that changes, this table and the Privacy Policy change together, the same day.

Incident and breach response

[This section describes the intended process. It has not yet been exercised against a real incident, and should be treated as a draft commitment until it has — recorded honestly rather than presented as a tested procedure.]

Detection. Vereli's observability stack (structured logging, correlation IDs across every workflow hop, and alerting on the computable failure signals in Volume 4 §16) is the first line of detection for a service-level incident. A data breach specifically may also be reported by a merchant, a customer, or a sub-processor.
Triage. Severity assessed within [target: 1 hour of detection during business hours] — is personal information actually exposed, to whom, and how much.
Containment. The specific access path or defect is closed first; root-cause analysis follows, not the other way around.
Notification. Affected merchants notified within [target: 72 hours of confirmation, matching the Privacy Act's Notifiable Data Breaches scheme trigger] with what happened, what data was involved, and what Vereli is doing about it. Where the scale or nature of a breach meets the Notifiable Data Breaches scheme's threshold, the Office of the Australian Information Commissioner is notified per that scheme's requirements.
Post-incident. A written postmortem for any incident that reached containment, covering root cause, what was affected, and what changed to prevent recurrence.

Service availability

Vereli targets ≥99.5% monthly dashboard availability (PRD §14), excluding outages at Shopify, Twilio, or Anthropic, which Vereli depends on and does not control.

Open item, not yet built: a public status page showing this figure over time. This needs a real decision (which status-page provider — several have a workable free tier for a service at Vereli's current scale — and whether to self-host a minimal status endpoint instead) rather than being written into existence here. Flagged for a founder call rather than built unasked; see the Sprint 6 issue tracker (S6-07, #95).

Questions

support@vereliapp.com

Published. Still open: n8n Cloud's sub-processor region (needs checking in its own account settings), the incident-response targets (aspirational until a real incident tests them — stated as drafts, not commitments), and the status page decision. Keep in sync with Vereli_DPA_v0.1.md and Vereli_PrivacyPolicy_v0.1.md — cross-reference rather than restate, per this project's own one-fact-one-home rule.