How Didit protects your users' data

TLS 1.3 in transit, AES-256 at rest, EU processing by default, independently audited controls, and retention you configure - plus what stays your responsibility as the controller.

Written by Didit Support · Updated 19 August 2026

Didit encrypts verification data at every stage and is independently certified against major security and privacy standards, so you can point to concrete evidence rather than take our word for it.

#Encryption and infrastructure

All data is encrypted in transit using TLS 1.3 and at rest using AES-256. By default, data is processed and stored in the EU. Enterprise accounts can request in-country processing with local data residency, subject to availability and contract - see DPAs, data residency and subprocessors.

#Processor and controller

Didit acts as your data processor. You remain the data controller, which means:

• You decide what is collected, by configuring the workflow.
• You decide how long it's kept, by configuring retention.
• You are responsible for the lawful basis and the notice given to your users.

That division matters practically, not just legally: it's why Didit cannot explain, change, or overturn a verification decision for one of your customers, and why a person asking about their own result has to be sent to you.

#Independent certifications

Didit's security and compliance posture is verified by outside auditors and regulators, not self-declared:

• SOC 2 Type 2 - an independent audit confirming the controls operated effectively over an observation period, not just that they exist on paper.
• ISO/IEC 27001 - certified information security management covering the platform end to end.
• ISO/IEC 27017 and 27018 - cloud-specific security and cloud privacy extensions.
• GDPR - processor role, with Article 32 technical and organisational measures.
• iBeta Level 1 (ISO/IEC 30107-3) - independently lab-tested biometric anti-spoofing.

Full list with dates and how to request each report: certifications and compliance.

#Access controls and monitoring

Access to verification data is role-based, so only authorised people on your team and ours can reach it. Every API action is logged with a timestamp, the acting user or application, and the source IP, and kept for 365 days. Infrastructure is monitored continuously, with periodic third-party penetration testing and tracked remediation.

On your side, access control is your configuration: see inviting team members and setting roles, and rotate API keys when someone leaves.

#You control storage and deletion

You decide how long data is kept. Set a retention window from one month up to ten years, or leave it unlimited, per application, from App Settings → Data. You can also delete an individual session at any time from the console or the API, immediately and irreversibly.

See deleting sessions and personal data for exactly what deletion covers, including the process-and-purge pattern if you'd rather not have the data sit here at all.

#What stays your responsibility

Using Didit doesn't transfer your obligations to your users. You're still expected to:

• Tell people what's happening - that your company is requesting the verification, and that a provider performs it.
• Provide your own privacy notice alongside Didit's.
• Collect the consent your legal team requires before document, selfie, or biometric capture. Biometric data attracts stricter treatment in most regimes than ordinary personal data.
• Handle your users' data-subject requests. A person asking you to erase their data is asking their controller - you - and you have the deletion tools to act on it.

White-labelling the flow changes where those disclosures live, not whether you need them. See customizing branding.

#Writing about Didit in your own privacy policy

Describing a processor in your own policy is a drafting decision your legal team should make, but two facts they'll want are: Didit acts as a processor on your instructions, and data is processed in the EU by default with configurable retention and erasure via API.

If you need specific wording, ask for the DPA and the technical and organisational measures document and let your counsel draft from those rather than from a help page.