Data retention policy

What Zoza Verify stores. What we never see. How long we keep metadata. The sub-processor list. The DPA template.

✓ Zero-message-content guarantee

Zoza Verify never sees the content of the SMS, email, push, or RCS messages a business sends after signing. The business calls POST /v1/sign with a message, we return a signature, and the business sends the signed message via their own SMS gateway. We do not log message content past the sign call, do not record who it was sent to, and do not see whether the recipient ever received or read it.

✓ Zero-consumer-side-tracking guarantee

The consumer-side verification path is designed to run offline against a cached public-key registry. When a consumer verifies a signed message this way, Verify's servers never see the call. The only consumer-side data we might see is if a consumer opts into server-side verify (POST /v1/verify), in which case we see the business_id, the message_id, and the signature bytes — never the identity of the consumer and never the message content tied to them.

What we store

Data class	Purpose	Retention
Business metadata id, name, domain, api_key_hash, public_key, channels, verified flag, active flag, created_at, message_count	Authenticate API calls; rate-limit; serve public-key lookups to consumers	For the life of the account + 90 days after deletion request
Private signing keys Ed25519 private key, encrypted at rest with the per-business KDF derivative of the root key	Sign messages on behalf of the business when they call `POST /v1/sign`	Until key rotation; old keys destroyed 30 days after rotation so any in-flight signed messages can still be verified
Public-key registry id, business name, domain, public_key, channels, verified flag, active flag	Exported via `GET /v1/registry` for offline consumer verification	Active businesses: live. Revoked: marked inactive in the registry for 365 days so old signed messages remain verifiable with context
Application queue company, email, website, use_case, use_case_details, volume_tier, plan_requested, status, submitter_ip, created_at	B2B apply workflow; admin approve/reject; abuse rate-limiting	12 months after approval/rejection decision
Request logs timestamp, business_id, endpoint, status code, bytes in/out, response time, Fly-Client-IP	Incident response, billing usage metering, abuse detection	30 days rolling; aggregated metrics retained indefinitely
Audit log (planned v0.2) hash-chained entries: business register/rotate/revoke/verify-domain, application approve/reject, admin token use, daily registry-snapshot Merkle-roots	Transparency; tamper-evident record of registry mutations	Indefinite — append-only, cannot be deleted

What we never store

Message content beyond the sign call. The content bytes passed to POST /v1/sign are hashed into the Ed25519 signature and discarded from memory. They are never persisted, logged, or backed up.
Who the message was sent to. Verify has no concept of recipient addresses — that's entirely the business's SMS gateway's domain.
Consumer verification calls against cached registry. These never touch our servers. We have no way of knowing which signed messages a consumer checked.
Consumer identity on server-side verify. If a consumer hits POST /v1/verify, we never ask for or receive any identifier tying the call to a person.
Sentry / Datadog / New Relic captures. We've disabled request-body capture in every APM we run.

Private signing key rotation

Businesses can rotate their Ed25519 keypair at any time via an authenticated call to POST /v1/businesses/{id}/rotate (planned v0.2 — today requires admin assist). On rotation:

A fresh keypair is generated server-side with crypto/rand.
The old public key stays in the registry marked superseded_at for 30 days, so messages signed before rotation remain verifiable.
The old private key is wiped from memory and the DB (over-written with zeroes, then dropped from the row).
The new public-key fingerprint is appended to the audit log as business_rotate.
A signed JSON rotation notice is pushed to the customer's webhook URL (if configured).

Data deletion

Customers can delete their business account at any time via hello@zoza.world. Within 7 business days:

Business metadata is marked inactive, then purged from our production DB.
The private signing key is cryptographically shredded (over-written + DB-row deleted).
All applications tied to the account are purged from verify_applications.
Access log entries for the account are anonymized (IP removed, business_id nulled).
The public key remains in the registry marked deleted_at for 365 days so old signed messages remain context-verifiable ("yes, this was a real SBI signature, but SBI has since withdrawn from Verify").
Backups containing the deletion-date range continue to exist until their normal 7-day rotation expires.
Audit-log entries referencing the account stay — the log is append-only and tamper-evident. They reference the business_id only, not any PII.

Sub-processors

We route traffic and store data through the minimum number of third parties. Each is listed with its function and jurisdiction. We notify customers 30 days in advance of any change.

Processor	Function	Jurisdiction
Fly.io	Application hosting (Singapore + Ashburn VA), managed Postgres	USA (Delaware)
Cloudflare	DNS for zoza.world zone (no proxy; DNS-only for verify-api)	USA (California)
Immunefi	Bug bounty platform (scope docs only, no customer data)	Netherlands

That's it — we don't use third-party analytics, APM, email marketing platforms, or CRM for Verify customers. Billing uses Stripe (when activated); Stripe sees your billing info, not your Verify usage. SMS gateway connections (MSG91, Gupshup, Twilio, Kaleyra) are your integrations — we never broker the SMS itself.

Regulatory alignment

Framework	Zoza's role	Status
DPDP 2023 (India)	Data Processor / Data Fiduciary (tbd by customer)	Grievance officer designated; consent integration on roadmap
TRAI UCC / DLT (India)	Optional trust layer above DLT — not a DLT replacement	Aligns with TRAI 2023 amendments on sender-verified messaging; not DLT-mandated
RBI circular on fraud (India)	Supporting tool for regulated entities' fraud-prevention obligations	Non-mandated; offered as a fraud-reduction control
eIDAS / ETSI TS 119 312 (EU)	Advanced electronic signature provider	Ed25519 recognised; QES-level certification on roadmap (needs Qualified Trust Service Provider accreditation)
NIST FIPS 186-5 (US)	Approved Ed25519 signature scheme	Ed25519 approval finalized Feb 2023; Verify's scheme aligns
GDPR (EU)	Data Processor	DPA template available; sub-processor list above
CCPA / CPRA (California)	Service Provider	Service-provider agreement template aligned with §1798.140(v)
CERT-In empanelment (India)	For regulated BFSI customers — audit conformance	Engagement planned Q3 2026

Data Processing Agreement template

Our standard DPA (GDPR Art. 28 + CCPA Service-Provider clauses + DPDP processor provisions) is available as a PDF on request. Non-standard terms require Enterprise contracts — email hello@zoza.world. Key provisions:

Subject matter: Ed25519 signing services on messages the customer supplies, and public-key-registry exposure to consumer verifiers.
Processor obligations: confidentiality, security (encryption in transit + at rest), audit cooperation, breach notification within 72 hours.
Customer rights: list of sub-processors, right to object to new sub-processors, deletion on termination, portable key-export (rotation-compatible).
International transfers: Standard Contractual Clauses (SCCs) with EU customers; UK IDTA addendum for UK customers; DPDP-aligned cross-border provisions for India customers.
Liability: capped at 12 months of fees paid; uncapped for deliberate breach, gross negligence, or inserting a rogue business into the registry.

Changes to this policy

Changes to this policy are committed to frontend-web/public/about/verify-retention.html in the Zoza source-code repository. Customers can git log the file for a full history. Material changes trigger email notification to all active customer contacts 30 days in advance.

ℹ Contact

Questions about this policy: hello@zoza.world

Data deletion requests: hello@zoza.world

GDPR / DPDP rights (access, portability, erasure): your end-users should contact you, since you're the controller; we route requests you make to us about your business account.