This is Veridenti's Business Continuity & Disaster Recovery plan, written for security reviewers: what we protect, how recovery actually works, the targets we hold ourselves to — and the one honest limit we disclose rather than paper over.
The framing that matters
Almost every "what if the cloud fails" question collapses into two very different risks. We answer them separately, because we solve them separately.
Vault ciphertext sits on 11-nines-class object storage, the control plane has point-in-time recovery, and — decisively — every user runs an offline-first client holding a complete local copy of their vault. Even a total loss of all server-side data leaves every user with a working vault to re-sync from. This is not tier-dependent.
A region or dependency going dark for a while is the real risk — and it is where our tier-specific machinery (drZone in-jurisdiction DR) lives. Everything below is organized around closing this gap without ever crossing a data-residency border.
Durability is a solved, universal guarantee. Availability is the thing we actively design for.
Definitions & targets
These are architectural targets — each maps to a concrete mechanism in this document, not a hopeful SLA.
| Objective | What it means | Target |
|---|---|---|
| RPO | Maximum acceptable data loss, measured in time | Near-zero |
| RTO — reads | Time to restore read access after an outage | Immediate |
| RTO — writes | Time to restore write / sync after a region outage | < 15 min |
| Sev-1 | Full outage of a customer-facing surface, or any confirmed data-integrity risk | Declared |
What lives where
| Component | Store | Redundancy model |
|---|---|---|
| Control plane | Cloudflare D1 | Single primary + read replicas; 30-day point-in-time recovery |
| Vault ciphertext | Cloudflare R2 (global) · regional S3 · customer-owned bucket | Global R2 is multi-region by default; a single-country bucket is durable but not region-redundant → pair with drZone |
| Application tier | Cloudflare Workers | Runs in 300+ locations — no single region to fail over |
| Client | User device | Offline-first — full local encrypted vault; buffers writes, reconciles on recovery |
Blast radius, stated plainly: a vault-storage outage degrades that organization's vault sync only. The console, provisioning, entitlements, audit log, and every user's local vault keep working. It is not a service-wide event.
Every tier · consumer + enterprise
A backend outage is never a lockout. Reads serve from the local vault; writes buffer locally and reconcile automatically when the backend returns — the backbone of immediate read RTO and near-zero RPO.
The control plane supports 30-day point-in-time restore — recovery from accidental deletion, a bad migration, or corruption with no manual backup-restore project.
Workers are globally distributed and the default global vault store is multi-region. For most organizations there is nothing extra to configure — redundancy is inherited.
In-jurisdiction DR Enterprise
Data residency lets an enterprise pin data to a single country. That bucket is durable but not region-redundant — and you cannot DR across a jurisdiction without breaking residency. drZone closes exactly that gap, per pinned zone:
Enabling drZone is a single in-jurisdiction DR replica per zone, configured by your operator during residency onboarding. Credentials and endpoints live only in the encrypted secret store — never in a document like this one.
Choosing primary + replica
The residency guard is on jurisdiction — not provider or datacenter — so you have real freedom within a jurisdiction. Strongest first:
Cross-provider — e.g. primary R2-EU + DR S3-EU — removes the provider itself as a single point of failure: you ride out a Cloudflare-wide R2 incident or an AWS-wide S3 incident. Add multi-datacenter in-jurisdiction (Frankfurt primary, Dublin DR) and an EU tenant is highly resilient without data ever leaving the jurisdiction.
Best achievable in-country: multi-AZ, or dual-provider (a hyperscaler + a local sovereign cloud) where one exists. A true country-wide event — a major cable cut or a legal compulsion — cannot be DR'd out without breaking residency. That is the customer's sovereignty-vs-availability trade-off, not a defect.
Even at that hard limit, two backstops hold: offline-first (local vaults keep working; only sync pauses) and zero-knowledge (any seizure or compulsion yields ciphertext, never readable data).
Failure-mode → response
| Scenario | Automatic response | RPO / RTO |
|---|---|---|
| Global vault-store blip | Bounded retry; multi-region store | ~0 / immediate |
| Pinned region down — DR configured | Read-failover + DR-authoritative writes; reconcile on recovery | ~0 / reads immediate · writes <15 min |
| Pinned region down — no DR | Fail-closed (never mis-jurisdiction); local vault keeps working | ~0 / reads immediate · writes wait |
| Primary + DR both down (same jurisdiction) | Fail-closed; monitor opens an incident; local vault keeps working | ~0 / writes wait |
| Control-plane primary-region outage | Managed regional recovery; reads via replicas; point-in-time restore if needed | see residual risk → |
| Accidental deletion / bad migration | Point-in-time restore (30-day window) | ≤ 30-day window |
| Total loss of all server-side vault data | Rebuild from clients' offline-first local vaults | 0 — client is source of truth |
The one honest limit
The enterprise control plane is single-primary with read replicas. A total outage of its primary region pauses control-plane writes — new provisioning, policy changes, audit appends. It does not stop local vault access, and where drZone is configured it does not stop vault sync.
Mitigations: managed regional recovery, read replicas for read continuity, and point-in-time restore for corruption. A named future hardening item is active multi-region control-plane writes.
We disclose this rather than overstate a multi-region write failover we don't yet have.
Detection & communication
status.veridenti.com reports our surfaces and the upstream providers we depend on.
Each bound residency zone is probed around the clock; a bound-but-unreachable zone is marked down, opening a status incident and an automatic ticket. A recovered primary auto-reconciles.
Per region: live status (healthy / failed over to DR / unreachable), whether a DR replica is configured and healthy, pending reconcile count, and the RTO/RPO targets.
During an incident: an incident lead owns communication and posts to the status page for broad events; affected enterprise admins receive direct notice with scope and expected recovery for a single-tenant or single-region event. Every Sev-1 gets a written post-mortem and a review of this plan within five business days.
Backups & exercise cadence
Three independent copies of every vault, and recovery paths we actually rehearse.
| Exercise | Cadence | Pass criteria |
|---|---|---|
| drZone read-failover + reconcile | Automated suite, every deploy | All pass |
| Zone-probe → incident → ticket path | Quarterly game day | Incident + ticket auto-open; recovery reconciles |
| Point-in-time restore drill | Semi-annually · non-prod | Control plane restored to a chosen point |
| Client offline → reconnect reconcile | Per release smoke test | Buffered writes reconcile · no loss |
Three copies of every vault: immutable-by-revision object keys, a live in-jurisdiction drZone replica, and the client's independent local vault.
The one-line answer
Consumer & any org on the global store: BC/DR is inherited — offline-first, platform redundancy, and point-in-time recovery. Nothing to configure. Enterprise with pinned residency: pair geographic pinning with an in-jurisdiction drZone replica for continuity that never crosses a border — surfaced and monitored in-console.
Resilience, verified — not asserted.
This planyou're reading it — self-serve and always current
Live statusstatus.veridenti.com — ours + upstream providers
Talk to ussales@veridenti.com — residency + DR design for your jurisdictions