Privacy and security

For your compliance and security teams: where identity data goes, what digid stores, and how the pieces are protected.

This page describes how digid handles data, so your compliance, risk and security teams can assess it. It states facts about the product; it is not legal advice, and your own obligations as the organisation verifying people are yours to assess.

In one paragraph

digid's SDK runs inside your app, on your customer's phone or in their browser. The card photo, the selfie and the fingerprints are processed there and never sent to digid. The result goes from the SDK to your app, and from your app to your own backend. digid's cloud service stores your organisation's account, your licences and daily usage counts, and nothing about the people you verify.

Where identity data goes

Data	Where it is processed	Where it goes	Kept by digid
Camera frames of the card	On the device, in memory	Nowhere	No
Selfie frames	On the device, in memory	Nowhere	No
Fingerprint images	On the device, in memory	Into the result document, to your app	No
Card fields (NIN, names, dates)	On the device	Into the result document, to your app	No
The result document (`digid.kyc/1`)	Built on the device	To your app, then to your backend over your connection	No
Usage counts	Counted on the device	To digid's cloud, when your app sends them	Yes: counts only

The SDK writes no files and keeps nothing after the verification: the result exists in your app's memory until your app sends it. The SDK makes no network calls of its own; on the web it fetches only its own files and models, from your origin.

What digid's cloud stores

Your organisation's account: organisation details, your team's user accounts (names, email addresses, phone numbers), their roles and sign-in records, and an audit trail of actions in the portal.
Licences: each product's licence, the apps it covers (package names, bundle ids, web origins, certificate fingerprints) and its features and dates. Licence keys are issued on request and are not stored.
Usage counts: per licence, app, day and phone counter, the number of completed verifications. The phone counter is a random id the SDK creates; it identifies neither the device nor the person.
Billing: invoices, payments and, for pay as you go, the credit balance.

digid's cloud does not store, and never receives: card images, selfies, fingerprints, NINs, names or any other detail of the people you verify, or any verification result.

What usage reports contain

A usage report carries your licence id, your app's id, a day, the phone's random counter id and a count. It contains no NIN, name, image or result. To count the same person only once in a week on the same phone, the SDK compares people in memory during the app run; nothing that identifies the person is written down or sent.

How it is protected

Licence keys are checked on the device, offline, against keys built into the SDK. A key is bound to your apps: package name and signing certificate on Android, bundle id on iOS, the origin on the web. A key copied into another app does not apply.
Evaluation results are marked. Without a valid licence, every result is watermarked, marked evaluation: true and never better than review, so it cannot pass for a production result.
The result document carries a tamper check. Your backend can detect a document that changed after the SDK built it. It does not prove who built the document, so send it over your own authenticated TLS connection and verify it on the server; see Verify on your backend.
In the cloud: traffic is over TLS; the portal supports passwords, one-time codes and authenticator apps; access is by role, with an audit trail.
Limits, stated plainly. Checks that run on a device can, in principle, be bypassed by someone who modifies the app. Treat device results as evidence to verify on your server, and keep a person in the loop for high-value decisions.

Data protection in Tanzania

Tanzania's Personal Data Protection Act, 2022 applies to the personal data you collect when you verify people. In the setup digid is built for:

You decide why and how identity data is processed, and your backend holds the result. You are responsible for your lawful basis, your notice to the person, consent where you rely on it, retention and the person's rights.
digid does not receive the personal data of the people you verify, so it does not hold it for you. digid processes the personal data of your own staff who use the customer portal, to run your account.
Sensitive data. The result can include biometric data (the face match, fingerprint images). Collect only the steps your process needs: leave out the selfie or fingerprints if you do not need them.

What this means for your registration, notices and contracts is for your own legal advisers to confirm.

Helping your process

Consent. screens.consent shows a checkbox with your text and a link to your notice before the camera opens.
Minimise. Leave out steps you do not need (flow.steps), and fingerprints you do not need (send only the one NIDA needs).
Keep the result off the device. Turn off screens.result.download in production, so the document goes only to your backend.
Retention. The SDK keeps nothing. Your backend sets how long the document is kept; keep it only as long as you need it, and never log it.

Retention at digid

Usage counts and billing records are kept for as long as your account needs them and as accounting rules require.
Your team's accounts are kept while your organisation is a customer. A user can ask to delete their account at /delete-account.

Questions

For a security questionnaire, a data processing discussion or anything this page does not answer, contact us.