Data Retention & Deletion: GDPR Privacy Controls

Role and processing location

Aspect	Detail
Processor role	Didit acts as a data processor; you remain the data controller.
Processing region	Each application’s data location, chosen when the application is created: the European Union (Ireland) by default, with Australia (Sydney), Mexico, the United Arab Emirates and the United States (N. Virginia) coming soon. Enterprise accounts can enable in-country processing (local data residency) subject to availability and contract.
Regulatory posture	Designed to support GDPR and local data-protection regimes. Configure retention below to meet your obligations.

Need a DPA, TOMs, or other compliance attestations? Contact your Didit representative.

Retention controls

Configure retention in Business Console → App Settings → Data retention.

Open retention settings

Go to Business Console → App Settings → Data retention.

Choose a retention policy

Select a window from 1 month to 10 years. Unlimited and custom periods are available on Enterprise. A new application starts at the longest window its plan includes: 1 year on Free, 5 years on Growth, 10 years on Scale and unlimited on Enterprise.

Save

Click Save to apply the policy to all future and existing sessions.

The policy applies to verification inputs/outputs, derived results, and operational metadata stored by Didit. When a session reaches the end of the window it is deleted exactly as by Delete Session, including its face embedding unless you have enabled biometric-template retention.

Data retention settings in the Business Console

Manual deletion

Delete individual sessions from the Console when you need one-off removals.

Open User verifications (or Business verifications) in the sidebar.
Search or filter for the target session.
Click the Delete button (top-right) and confirm.

Delete a verification session from the Console

Programmatic deletion

Delete a session via the API at any time by calling the Delete Session endpoint.

curl --request DELETE \
  --url https://verification.didit.me/v3/session/{session_id}/delete/ \
  --header 'x-api-key: YOUR_API_KEY'

Response	Meaning
`200 OK`	Session deleted. The body reports what happened to the face biometric data (`face_retention_outcome`).
`404 Not Found`	Session already deleted or unknown `session_id`.

For a data-subject erasure request, send {"deletion_instruction": "privacy_erasure"} in the body so that any retained biometric template for that person is purged as well.

Biometric template retention

Every KYC session with a liveness selfie carries a face embedding that powers duplicate detection and Face Search 1:N. By default that embedding is deleted with the session, so a person whose session you deleted can verify again without being flagged as a duplicate. Workflows whose Liveness step has automatic Face Search switched off never store that embedding in the first place, so retention has nothing to keep for their sessions. If you delete sessions soon after approval but still need to catch repeat sign-ups, enable biometric-template retention. Didit then deletes the session and all of its data as usual and keeps one separately managed, image-free face biometric template anchored to the User.

A retained biometric template is biometric data. It is not anonymous, it is not transient, and it is not deleted with the session. It stays until its scheduled expiry, an earlier applicable-law deadline, User deletion, a privacy-erasure request, or an explicit purge. Enable retention only when your controller instruction and privacy notice cover it, and choose a retention period that satisfies the laws that apply to your users.

Enable it

Open retention settings

Go to Business Console → App Settings → Data retention.

Turn on Retain biometric template

Select Retain until scheduled expiry or earlier deletion. The setting reads: Keeps an image-free face biometric template for tenant-scoped duplicate detection after an operational session deletion. It remains biometric data and is deleted on its configured schedule, applicable-law deadline, User deletion, privacy-erasure request, or explicit purge.

Set a finite retention period

Enter the number of days (1 to 3650) a template may be kept. The setting cannot be saved without it. Didit applies the shorter of this period, your general retention window, and any deadline you send on a deletion call.

Save

The policy applies to deletions from now on. No existing template is created or purged by changing the setting.

Programmatically, set the same policy with PATCH /v3/webhook/:

curl -X PATCH https://verification.didit.me/v3/webhook/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"face_retention_policy": "retain_until_user_deleted", "face_retention_days": 365}'

Field	Values	Description
`face_retention_policy`	`delete_with_session` (default), `retain_until_user_deleted`	What happens to the face embedding when a session is deleted.
`face_retention_days`	integer 1-3650	Finite retention period for retained templates. Required when the policy is `retain_until_user_deleted`; the request is rejected with `400` without it.

Existing applications stay on delete_with_session until you change the policy. Nothing enables retention on your behalf.

What is retained and what is erased

Deleted with the session	Retained (opt-in only)
Decision, extracted data, and every feature record	The numeric face template used for matching
Document images, portraits, selfies, liveness video, POA documents, extra uploads	A new random template id and an opaque provenance reference
The session id, number, and its link to any media	The owning User, the retention dates, the instruction class and id, and the acting principal id

The retained template is tenant-scoped and used only on your instruction for duplicate-face and multi-account detection, biometric authentication, and your own face lists. It is never used for model training, analytics, cross-organization matching, or Didit’s own fraud processing.

Per-deletion control

Every deletion reports its outcome, and every delete call can override the policy:

Console: the delete confirmation shows whether each session’s template will be retained or deleted. The confirmation reads: This deletes the session and starts deletion of its session data. If biometric-template retention is enabled for this operational deletion, an image-free biometric template remains separately until its scheduled expiry or earlier purge. Privacy-erasure requests also purge the template. Sessions without a User cannot retain a template and are marked as such.
API: send retain_face_embeddings, face_retention_days, face_retention_deadline, deletion_instruction, and instruction_id on Delete Session or Batch Delete Sessions.

Two kinds of deletion instruction

Instruction	What it does
Operational session deletion (`operational_session_delete`, default)	Deletes the session and its data. A template is retained only when the policy or the request says so, and the response states the outcome.
Privacy erasure (`privacy_erasure`)	Deletes the session and purges every retained template for that person. The application policy cannot override it. Use it for data-subject requests.

When a template is purged

You purge it in Lists → Biometric templates or through the Biometric Templates API.
You delete the User with Batch Delete Users.
You delete any session of that User with deletion_instruction: "privacy_erasure".
Its retention period ends. Didit purges it automatically.

Switching the policy back to Delete with session stops new templates from being created but does not purge existing ones; purge them explicitly.

Where to see them

Lists → Biometric templates lists every template with its User, source, retained and expiry dates, and status, with single and bulk purge.
Users → [user] → Biometric templates shows the templates anchored to one User.
The Biometric Templates API exposes the same data and actions, and every retain and purge is recorded on the audit trail.

Retained templates are covered by the biometric-data terms of your DPA. Nothing in this page is legal advice: you remain responsible for the legal basis, notices, consent, and the retention period that applies to your users.

Process-and-purge pattern

For maximum data minimization, process verification data through Didit and purge it immediately after receiving results via webhooks.

Create a session

Your backend calls the Create Session API.

Didit runs checks

Identity, liveness, AML, and any other configured checks execute automatically.

Receive webhook

Didit sends a webhook with status, session_id, vendor_data, and full verification data.

Persist only what you need

Store the minimum fields required for your records (e.g., status, vendor_data).

Delete from Didit

Call the Delete Session API for that session_id to delete the session and its data from Didit. If you rely on duplicate detection across future sign-ups, enable biometric-template retention first; otherwise the face embedding is deleted too.

Security and assurance

ISO/IEC 27001

ISMS in place. Certificate and excerpts available on request.

Penetration testing

Periodic third-party penetration tests with tracked remediation.

No known breaches

No security breaches reported to date.

Internal security team

Dedicated cybersecurity team with least-privilege access and strict environment separation.

All API activity is recorded in Audit Logs for security, compliance, and troubleshooting. How far back you can read them depends on your plan: see Audit logs.

Privacy-minimized storage

You decide, feature by feature, which data a verification hands back, and how long Didit keeps a session. Both controls are available today in the Business Console and through the API.

Returned data. In the workflow editor, open a feature and go to its Returned data tab. Every field, image and score the feature can produce has its own switch. A data point you switch off is withheld: its value comes back as null in the session decision and the webhooks, and it is not shown in the Business Console or in exports. Through the API, set response_attributes on the workflow: see Create workflow.
Retention and deletion. Set a retention period so sessions are deleted automatically, or delete each session as soon as you have its result with the process-and-purge pattern.

FAQ

Can I set different retention per environment?

Yes. You can configure different retention policies for each application you have in Didit.

Can I export data before deletion?

Yes. Export session data via the Console or API, then call the Delete Session endpoint.

Will a deleted user still be caught as a duplicate?

Only if you enabled biometric-template retention before deleting their session. By default the face embedding is deleted with the session and the person can verify again without a duplicate flag. See Biometric template retention.

Where can I see who accessed what?

Use Audit log in the Console (Settings > Organization > Audit log). Filter by user, endpoint, or date range. How far back you can read depends on your plan: see Audit logs.

Implementation checklist

Configure retention

Set your retention policy in Console → App Settings → Data retention.

Subscribe to webhooks

Set up webhooks and verify signatures.

Persist minimal fields

Store only the fields your business requires.

Implement programmatic deletion

Call the Delete Session API if you use the process-and-purge pattern.

Confirm processing region

Check your application’s data location in Application settings > Data and privacy (the European Union by default, or in-country for enterprise).

Separate environments

Use separate Sandbox and Live API keys with independent retention policies. Rotate keys regularly.

Overview

Pricing

Workflows & Verification

Review & Operations

Entities (Users & Businesses)

Settings & Customization

Security & Compliance

Didit Academy

Resources

Data Retention & Deletion: GDPR Privacy Controls

Role and processing location

Retention controls

Manual deletion

Programmatic deletion

Biometric template retention

Enable it

What is retained and what is erased

Per-deletion control

Two kinds of deletion instruction

When a template is purged

Where to see them

Process-and-purge pattern

Security and assurance

ISO/IEC 27001

Penetration testing

No known breaches

Internal security team

Privacy-minimized storage

FAQ

Implementation checklist