Privacy Policy

1. Who this policy covers

This policy describes the personal data Identiwise processes when a customer uses our identity verification service, and the personal data we process about our own customers and about visitors to this website. It is written for two audiences: the businesses that integrate Identiwise, and the people whose identity those businesses verify (we call them subjects).

2. Data we process on behalf of a customer

When a customer runs a verification, we process:

• Document images — the photograph of an identity document that the subject uploads or captures.
• Selfie images — a photograph of the subject's face, captured in our hosted verification page or supplied through the API.
• Results derived from facial images — face detection results, the outcome and score of a face comparison between the document photograph and the selfie, and, where the customer asks for it, an estimated age. These are results derived from facial images rather than an enrolled facial template; we do not build a searchable database of faces and we never compare a subject against anyone but their own images.
• Text extracted from documents (OCR) — the machine-read text of the uploaded document, which is scored against the subject details on file.
• Subject details — for example a name, date of birth, e-mail address, document number, issuing state and document expiry, or a postal address, provided by the customer or entered by the subject where the customer's configuration allows it.
• Messages — any correspondence between the customer's reviewers and the subject inside the verification interface.
• Technical data — IP addresses recorded in our security and audit logs, and API usage records (endpoint, method, timestamp, size) used for metering and troubleshooting.

Facial images processed to confirm that a person is who they claim to be are biometric data and a special category of personal data under GDPR Article 9(1). We process them only on the customer's instruction and only to compare a subject against their own images — we do not enrol facial templates into a searchable gallery and never compare a subject against anyone else.

We do not ask for, and the service has no field for, payment card numbers, health data or government identifiers beyond what appears on the document the subject presents.

3. Why we process it

• To perform the verification the customer instructed — running the document check, the face comparison, the OCR scoring and, if requested, the age estimate, and returning the result to the customer.
• To secure the service — rate limiting, attempt lockouts, IP allow-lists and abuse investigation.
• To keep an audit trail — recording who viewed a document, exported data, decided a review, changed a role or erased a record, so that the customer can account for how identity data was handled.
• To meter usage against the customer's plan.

The lawful basis for processing subject data is the customer's, not ours: they instruct us and are responsible for having a basis and for obtaining any consent their local law requires. We do not sell, rent or trade personal data, we do not use verification data to train models for other customers, and we do not use it for advertising.

Because facial images fall under Article 9, the customer must also have an Article 9(2) condition — normally the subject's explicit consent under Article 9(2)(a), or substantial public interest under Article 9(2)(g) where a legal identity-verification duty applies. Obtaining and recording that condition is the customer's responsibility, not ours, and the Data Processing Agreement we will offer before launch will say so.

4. Automated processing and human review

Verification results are produced by machine-learning models and are probabilistic. A result is either approved automatically, rejected, or parked for a human reviewer with a stated reason — including when a component of the pipeline is unavailable, in which case the outcome is recorded as an infrastructure failure and never as a verdict about the person. The decision that follows a result — whether to open an account, grant access or decline — is always the customer's, not ours.

5. How long we keep it

Verification records and images are kept until they are erased on the customer's instruction, or following a subject's erasure request that the customer approves.

We want to be exact about this: there is no automated retention clock today. Automated retention limits — a per-customer period after which images and records are purged without anyone asking — are planned, and this section will state the period and the mechanism before launch. Until then, retention is controlled by the customer through deletion, and by us on their instruction.

When a record is erased, the stored images are deleted from object storage and the associated database rows are removed in the same operation. Two records survive an erasure by design: an audit-log entry recording that the erasure took place and when, and the erasure request itself in the customer's privacy queue, detached from the deleted subject and marked completed so that the request can be shown to have been made and carried out. Neither holds images or document contents. The request may carry a short free-text note written by whoever asked for it or by the customer's staff, so customers should not put personal data in that note.

6. Where it is processed, and who else touches it

All processing and storage takes place on IONOS Cloud in Germany — compute in Frankfurt, and object storage in an IONOS region in Germany.

Sub-processors that touch verification data — today this list has one entry:

• IONOS SE (IONOS Cloud, Germany) — hosting, compute, managed databases and object storage. The IONOS data centres we use hold ISO 27001 certification; that is IONOS's certification, not ours.

Billing, from launch. Subscriptions will be sold through a third-party payment provider acting as Merchant of Record. That provider will be the seller of record and an independent controller of your billing data rather than our sub-processor, and it will process no verification data. Its name, its buyer terms, its tax handling and its place of establishment will be published here before launch. We never see or store card data; payment details are entered with the provider, not with us.

We use no analytics, advertising or session-recording services, and no third-party processor of verification data other than IONOS.

International transfers: verification data is processed only in Germany and is not transferred outside the European Union. Website-visitor data is the one exception: this site loads stylesheets, icons and fonts from public content delivery networks — jsDelivr, Cloudflare cdnjs and Google Fonts — which receive your IP address in order to serve those files and may be operated from outside the EU. See section 10.

7. Your rights, and how erasure actually works

Subjects have the rights the GDPR gives them — access, rectification, erasure, restriction, objection and portability. Because we are the processor, those rights are exercised against the controller: the business that asked you to verify.

• Erasure (Article 17). A member of the customer's staff can lodge a deletion request on a subject's behalf, and the API offers a route (POST /subject/request-deletion) that a customer's own verification page can call so that subjects can lodge one themselves — the hosted verification page does not render that control today. The request is recorded in the customer's privacy queue. Where a request for the same person is already open, a further request is joined to the existing one rather than duplicated, and the erasure proceeds on that request. You can also write to privacy@identiwise.com and we will pass the request to the controller.
• The customer decides. As controller they assess the request against their own retention and legal obligations.
• We execute it. On their instruction we delete the stored images and the associated records, as described in section 5.
• Correction. Where the customer's configuration permits it, a subject can view and correct the details held about them from the same verification page.

You also have the right to complain to your local data protection supervisory authority.

8. How we protect it

The measures in place today:

• TLS on every hostname for data in transit.
• Private object storage. Images are never publicly served; a reviewer receives a time-limited pre-signed link (15 minutes) rather than a durable URL.
• Two-factor authentication (TOTP, with recovery codes) for staff accounts, which a customer can enforce for its whole team.
• Rate limiting and lockouts on authentication — per-IP limits on login attempts and a per-user lockout on second-factor attempts.
• Per-tenant IP allow-list that a customer can apply to its own API access.
• Role-based access — superuser, admin and view-only roles, checked at the router, before any handler for the request runs.
• An append-only audit log — no application code path updates or deletes an entry, and a regression test keeps it that way — covering document views, raw exports, review decisions, erasures, logins, authorisation refusals, two-factor changes, token issuance, role and staff changes, password changes and subject record changes. Shipping the trail off-host, and restricting writes to it at the database level as well, are planned.
• Tenant separation enforced in every query — each tenant's operational data is assigned to one of several database clusters in the EU, and every query against tenant-owned data carries a bound tenant identifier, which is checked mechanically by a lint in our build pipeline.
• Least-privilege database and deployment identities, separated from the credentials used by the application itself.

We describe only measures that are in place. No security programme removes risk entirely; section 9 sets out what we do if something goes wrong.

9. If something goes wrong

If we become aware of a personal data breach affecting data we process for a customer, we will notify that customer without undue delay — with what we know at the time and what we are doing about it — so that they can meet their own notification duties as controller. The audit log described in section 8 is what lets us scope which records and which documents were reached. We do not notify data subjects directly: as processor that is the customer's decision and their obligation.

Report a suspected vulnerability or incident to security@identiwise.com.

10. This website

This site is static and carries no analytics, advertising or tracking cookies. It loads stylesheets, icons and fonts from three public content delivery networks — jsDelivr, Cloudflare cdnjs and Google Fonts — which necessarily receive your IP address in order to serve those files, and which may serve them from outside the European Union. Nothing on this site can be purchased and there is no account to create.

11. Changes to this policy

This is a draft. It will be revised before launch and thereafter when our processing changes; the date at the top of the page always reflects the current version. Material changes affecting customers will be notified to them directly.

12. Contact

Data protection enquiries: privacy@identiwise.com.

We have not appointed a Data Protection Officer, and this policy does not claim one — we have no customers and process no live personal data yet. We will appoint a Data Protection Officer, and an EU representative if one is required, before we begin processing at scale, and will name them here. In the meantime privacy@identiwise.com is our data protection contact. The legal entity responsible for Identiwise, its registered address and the supervisory authority for it will be published on this page before launch.