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, on AWS in Ireland. In-country processing is available on enterprise contracts, subject to availability. The DPA and SLA are published and already part of the terms you accepted; a countersigned DPA, SLA or MSA on your own paper comes with a prepaid credit agreement. The TOMs document is available on request.
#Where data is processed
By default, verification data is processed and stored in the EU, on AWS infrastructure in Ireland (eu-west-1). Biometric operations run in the same region.
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. One region worth stating outright because it is asked often: there is no processing region in Russia, on any plan, so a requirement to keep data inside the Russian Federation cannot be met.
If your obligation is local storage rather than local processing, the pattern most customers use is process and purge: run the verification through Didit, receive the result by webhook, store what you need on your own infrastructure in your country, and delete the session from Didit right after. See deleting sessions and personal data.
"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
You already have one. The Data Processing Addendum is Annex 2 of the Business Terms and Conditions your organization accepted at sign-up, and the Service Level Agreement is Annex 1. Both are published standalone as well - Business Terms, Data Processing Addendum, Service Level Agreement - and they are the Article 28 agreement between you and Didit on the free and pay-as-you-go plans. The technical and organisational measures (TOMs) document that GDPR Article 32 expects is available on request from your Didit contact, without an NDA.
What does not exist on pay-as-you-go is a countersigned copy: the contract is the published terms as accepted, and support can confirm the acceptance date for your organization if an auditor asks. If your compliance file needs a signed MSA, a DPA on your own paper or a negotiated SLA, that comes with a prepaid credit agreement, which starts at $2,000 USD and converts into credits that never expire. Ask your Didit contact and have your legal name, the signer's email and your country of incorporation ready.
- Terms & Policies is where the DPA and the signed agreements are.
- Application settings are separate from organization-wide ones.
If your organization relies on the accepted terms rather than a signed copy, ask support to confirm exactly which version you accepted and when. That's a factual question with a factual answer, and it's the answer an auditor will ask you to produce.
#Subprocessors
Didit has two subprocessors:
| Subprocessor | Role | Receives |
|---|---|---|
| AWS EMEA SARL (eu-west-1, Ireland) | Cloud infrastructure | All processing runs here |
| Google Maps Platform (Google Cloud EMEA Ltd) | Geocoding for Proof of Address only | The address text being verified. It is not involved in ID verification, liveness or face match, and never receives biometric or document data |
No data leaves the EEA through either. The binding list, and the notification arrangements for changes to it, are in the DPA - this table is the current answer, the DPA is the document your compliance team relies on.
#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.