Role & Processing Location

Processor role
Didit acts as a data processor of your verification data; you are the controller.
Processing region
By default, we process and store data in the EU. For enterprise accounts, we can enable in-country processing (local data residency) subject to availability and contract.
Regulatory posture
Didit is designed to support GDPR and local data-protection regimes. Configure retention to meet your obligations (see below).

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

🔧 Retention Controls (Console)

Configure retention in Business Console → App Settings → Data:

Default: unlimited (no time-bound policy until you set one)
Custom window: 1 month → 10 years
Scope: verification inputs/outputs, derived results, and operational/audit metadata kept by Didit

How to set it

Go to Business Console → App Settings → Data
Choose Retention policy (e.g., 1 month, 10 years, unlimited, etc.)
Save

🗑️ Manual Deletion (Console)

From Dashboard → Verifications:

Search/filter the target session
Click Delete (top-right red button) → confirm

This is ideal for one-off removals or operational triage.

🔌 Programmatic Deletion (API)

Delete a verification session via API any time:

cURL

curl --request DELETE \
     --url https://verification.didit.me/v1/session/sessionId/delete/ \
     --header 'accept: application/json'

Expected responses

204 No Content --- deleted
404 Not Found --- already deleted or unknown session_id

⚡ Process-and-Purge Pattern (Webhooks)

Some customers let Didit process the data, then immediately purge it after receiving results through webhooks:

Your backend creates a session
Didit runs checks (ID, liveness, AML, etc.)
Didit sends a webhook with status, identifiers (session_id, vendor_data), and verification data.
Your backend persists only what you need (e.g., status, vendor_data)
Your backend calls the DELETE session API for that session_id to remove data from Didit

🛡️ Security & Assurance

ISO/IEC 27001 ISMS in place (certificate/excerpts available on request)
Periodic penetration testing with tracked remediation
No known security breaches to date
Dedicated internal cybersecurity team; least-privilege access; strict env separation.

All API activity is recorded in Audit Logs, aiding security, compliance, and troubleshooting. Logs are retained 1 year (365 days) and then auto-deleted.

🔐 Privacy-Minimized Storage

We're adding features to let you retain only selected processing data --- for example, keep status and an identifier (vendor_data) while auto-purging heavier artifacts. This gives stricter control for teams operating under minimization principles.

Want early access or artifact-level retention rules? Contact us.

📚 FAQ

Can I set different retention per environment?
Yes --- you can setup different retention for each application you have in Didit.

Can I export before deletion?
Yes --- export via Console/API, then run the DELETE call.

Where can I see who accessed what?
Use Audit Logs --- filter by user, endpoint, date range; logs retained for 365 days.

🔏 Implementation Checklist

Configure retention in Console → App Settings → Data
Subscribe to webhooks; verify signatures
Persist minimal fields needed for your records
Implement DELETE endpoint if needed
Confirm processing region (EU vs in-country)
Separate Sandbox/Live keys & policies; rotate keys regularly