How Verif-ID stores and protects forensic data
Enterprise deployments depend on knowing exactly where evidence lives, how long it stays, and how it is secured. This page lays out our storage policies, retention windows, and encryption methods in plain language.
Encryption in transit & at rest
All traffic to and from Verif-ID is encrypted in transit over TLS 1.2+. Submitted content and certificate records are persisted in the Base44-managed data layer, which encrypts data at rest through its hosting provider. File objects (uploaded media and liveness frames) are stored in the platform's managed object storage with the same at-rest protections.
Cryptographic attestation
Every submission is fingerprinted with a client-computed SHA-256 hash before it leaves the browser. That hash becomes the tamper-evident anchor of the certificate — the exact bytes can be re-verified later without re-sending the source. Public verification trusts the hash alone; the underlying content is never exposed on the public lookup endpoint.
What we store, and what we don't
We persist the certificate record: content type, the SHA-256 hash, the forensic verdict (AI probability, findings, markers), issuer attribution, and liveness status. For text we store the submitted body truncated to 5,000 characters. For image, audio, and video we store the uploaded file reference and filename. We do not enroll biometric templates into any face-recognition system and never sell or share data for advertising.
Retention periods
Certificate records and their referenced files are retained for the life of your account unless you delete them. Enterprise tenants may request scheduled retention windows and automated purge cadences. Account deletion purges your issued certificates, your plan records, and your authentication record — deleted data cannot be recovered.
Tenant isolation
Enterprise data is scoped by a client identifier carried on the user, certificate, and plan records. Access is enforced by row-level security: a reader sees only their own records, records belonging to their organization, or — for admins — the full tenant scope. Public verification runs through a service-role function that returns only the public attestation fields.
Where your data routes
Analysis is performed by the Base44 Core LLM integration: text and image references are sent to the model for forensic assessment, while audio and video share only metadata (filename, type, size) — not the media bytes. If you connect Slack, notification messages (issuer name, hash, verdict) route to your workspace; otherwise nothing leaves the app. Billing is handled by Wix (Base44 Payments), which collects payment details directly.
Retention & deletion schedule
| Data category | Retention | User-removable |
|---|---|---|
| Certificate record (hash, verdict, metadata) | Lifetime of account | Yes — per certificate or on account deletion |
| Submitted text (≤ 5,000 chars) | Lifetime of certificate | Yes — deleted with the certificate |
| Uploaded media file (image / audio / video) | Lifetime of certificate | Yes — deleted with the certificate |
| Liveness frame | Lifetime of certificate | Yes — deleted with the certificate |
| Subscription & plan record | Lifetime of account | Yes — on account deletion |
| Authentication record | Lifetime of account | Yes — on account deletion (platform-managed) |
Enterprise tenants may negotiate custom retention windows, automated purge cadences, and data-residency requirements as part of an enterprise agreement.
Self-serve deletion
Delete any certificate or your entire account from the Profile page at any time.
No biometric enrollment
Liveness frames verify presence — they are never enrolled into a face database.
Hash-anchored trust
Public lookups rely on the SHA-256 fingerprint, never the source content itself.
Need a tailored data agreement?
Enterprise clients can request custom retention windows, residency commitments, and a reviewed data-processing addendum.