This document describes the security measures behind the LiveVerify Service, referenced from the Terms & Conditions and forming Annex 2 of the Data Processing Agreement.
1. Scope and design principle
The overriding design principle is that the most sensitive data — the identity document image and the selfie — should exist for as short a time and in as few places as technically possible. Concretely: those images are held in memory only, for the life of a single verification request, and are never written to disk, never stored in a database, and never sent to a third-party machine-learning vendor.
2. Infrastructure and data residency
The table below lists the deployed components of the Service and shows which are live and which are in testing ahead of general availability.
| Component | Host / region | Status | What it holds |
|---|---|---|---|
| Capture page | Vercel · Frankfurt (fra1) | Live | Static assets only — nothing to secure at rest. |
| Verification function | Vercel · Frankfurt (fra1) | Live | Document image, selfie frames, and derived face templates — in memory, for the life of one request. Never written to disk. |
| Interim session record | Cloudflare Durable Object · EU jurisdiction | Live | Session status, attempt count, and the name read from the document. Self-deletes after 30 minutes. |
| Verification database | Supabase · Ireland | Live | Durable verification record: status, date and outcome metadata (see Annex 1 of the DPA). No images, name, date of birth or document number. |
| LiveVerify API | Vercel · Frankfurt (fra1) | Live | Interface for customers to create Sessions and retrieve results. No identity image ever crosses it. |
| B2B customer database | Supabase · Ireland | Live | Customer accounts, Account Contact details, and API credentials (stored only as hashes). |
| Session metering | Supabase · Ireland | Live | Per-session usage counts for billing. No identity data. |
| Passport chip check (optional) | Android app · Vercel · Frankfurt (fra1) | In testing | Data read from the identity document’s chip, in memory for the life of one request. Only the check verdict and issuing country are kept. |
All server-side components are hosted in EU regions.
3. No third-party ML vendor
Document OCR, face detection, and face matching all run on open-source models operated inside LiveVerify's own infrastructure — not sent to an external ML API. The models in use, their licenses, and the license-attribution audit performed on them are documented separately and available on request.
4. Encryption
- In transit: TLS on every connection between the End User's device, the verification function, and any downstream store or API.
- At rest: managed by each infrastructure provider's own storage-encryption controls (Vercel, Cloudflare, Supabase all encrypt data at rest by default).
API keys, kiosk staff PINs, and document numbers that a customer places on its document blocklist are stored only as one-way cryptographic hashes, never in readable form.
5. Access control
- API access to Customer data is scoped per account via credentials issued through the B2B customer database, and is logically separated between customers.
- Production database tables are protected by row-level security and are accessed only by LiveVerify’s server-side code.
- Internal access to production systems is limited to authorised personnel on a least-privilege basis.
- Administrative access to LiveVerify's infrastructure, payment, code-hosting, domain and email accounts is protected by multi-factor authentication.
- No LiveVerify staff interface renders a raw document image or selfie; there is nothing to view because nothing is stored.
6. Sub-processor security posture
LiveVerify’s infrastructure providers each maintain independent third-party security attestations, available through their own trust centres: Vercel and Cloudflare each publish SOC 2 Type II and ISO 27001 attestations, and Supabase documents its SOC 2 compliance programme. LiveVerify will provide current copies of these attestations to Customer on request.
7. Incident response and breach notification
LiveVerify will notify affected customers without undue delay, and in any event within 24 hours of becoming aware, of a personal data breach affecting their data, consistent with the notification commitment in the DPA.
LiveVerify’s incident response covers identification and containment of the incident, escalation, notification of affected customers, and a post-incident review with remediation.
8. Vulnerability management and testing
LiveVerify's source code repositories are continuously scanned for dependencies with known vulnerabilities, and fixes are proposed automatically. Code changes are reviewed and tested before they are deployed, and identified vulnerabilities are remediated according to their severity, prioritising critical and high-severity issues. Security researchers can report vulnerabilities under Section 10.
9. Business continuity
Because the most sensitive data is never persisted, there is no identity-image backup to protect or lose. The durable verification record and the B2B customer database rely on Supabase's own backup and availability practices.
10. Reporting a security issue
Security reports can be sent to security@liveverify.me.