DPAs, data residency and subprocessors
Didit processes in the EU by default, with in-country processing available on enterprise contracts. Here's how to get a DPA, the TOMs, and answers your procurement review will ask for.
EU processing by default. In-country processing is available on enterprise contracts, subject to availability. A DPA and the technical and organisational measures document are available on request - ask your Didit contact rather than inferring terms from a help page.
#Where data is processed
By default, verification data is processed and stored in the EU.
In-country processing - local data residency for a specific jurisdiction - is available for enterprise accounts, subject to availability and contract. If your requirement is a specific region, ask directly which regions are available today and get the answer in writing. Regional availability changes, and it's exactly the kind of commitment a procurement review will want evidenced rather than described.
"Where is the data processed?" and "where are the biometric calls processed?" can have different answers worth confirming separately. If your obligation covers the processing region for biometric operations specifically, ask about those specifically rather than accepting a general answer about storage.
#Getting a DPA
A data processing agreement is available on request - ask your Didit contact. The technical and organisational measures (TOMs) document that GDPR Article 32 expects is available the same way.
- Terms & Policies is where the DPA and the signed agreements are.
- Application settings are separate from organization-wide ones.
If your organization hasn't signed a separate DPA and believes it's covered by accepting standard terms, don't assume: ask for confirmation of exactly which version of which terms you accepted and where they live. That's a factual question with a factual answer, and it's the answer an auditor will ask you to produce.
Whether a DPA is available on your plan or requires an enterprise contract is a commercial question - raise it early rather than at the end of a procurement cycle.
#Subprocessors
Didit uses subprocessors to deliver some checks. The list, and the notification arrangements for changes to it, belong in your DPA rather than in a help article - which is deliberate, because that's the document your compliance team can rely on and this page isn't.
Ask for the current subprocessor list as part of the same request.
#Answering a security questionnaire
Most of what a security review asks for exists as a document. In roughly the order questionnaires ask:
| They'll ask for | What exists |
|---|---|
| Independent audit of controls | SOC 2 Type 2 report, available under NDA |
| Information security certification | ISO/IEC 27001, plus 27017 and 27018 for cloud |
| Encryption in transit and at rest | TLS 1.3 and AES-256 |
| Biometric anti-spoofing testing | iBeta Level 1 PAD under ISO/IEC 30107-3 |
| Penetration testing | Periodic third-party testing with tracked remediation |
| Data processing terms | DPA and TOMs |
| Retention and erasure | Configurable retention 1 month to 10 years; erasure via API |
| Audit trail | 365-day audit log of all API activity |
See certifications and compliance for the full credential list with dates.
#Commitments this page can't make for you
Some questions that come up in procurement are contractual, not technical, and the honest answer is that they belong in a negotiated agreement:
- Contractual warranties about deletion, backed by an inspectable audit trail or periodic certification.
- Breach notification timelines other than the GDPR clock - for instance Australia's Notifiable Data Breaches assessment window.
- Regional hosting roadmaps and the dates attached to them.
- Retention obligations you believe apply to you.
Bring each of those to your Didit contact and get the answer in the contract. A help page describing a commitment is not a commitment, and treating one as the other is a risk to you rather than to us.
#Erasure requests from your users
Your users are your data subjects, and an erasure request comes to you as the controller. You have the tools to act on it directly: delete the session from the console or the API, immediately and irreversibly. See deleting sessions and personal data.
If your process needs to be automated end to end - a request in your product triggering deletion here - that's the delete endpoint plus your own workflow, and it's a well-trodden pattern.