Data Protection Impact Assessment (DPIA) Template
A structured, 7-step DPIA template aligned with UK Information Commissioner's Office (ICO) guidelines and EU GDPR Article 35 for organizations deploying LKP zero-knowledge verification.
Step 1: Identify the Need for a DPIA#
Under Article 35(3) of the UK and EU GDPR, a Data Protection Impact Assessment is legally required when processing is likely to result in a high risk to the rights and freedoms of individuals. Age assurance and identity verification engage high-risk triggers:
- Biometric Data Processing (Special Category): Utilizing facial estimation or document inspection to evaluate age or authenticate identity.
- Vulnerable Data Subjects (Children): Age gating services to protect minors under the UK Online Safety Act 2023, the ICO Children's Code, and the EU Digital Services Act (DSA).
- Automated Decision-Making: Granting or restricting access based on automated verification outcomes.
- Access Barriers: Preventing data subjects from accessing content, goods, or services without successful verification.
Core Assessment Objective: Demonstrate that using LKP replaces high-risk centralized PII storage with cryptographic zero-knowledge proofs, reducing controller liability to near zero.
Step 2: Describe the Processing#
LKP employs zero-knowledge cryptography (Groth16 zk-SNARKs over the BN254 curve and BabyJubJub elliptic curve signatures) to cleanly separate identity credential issuance from credential verification. The processing operates across four segregated boundaries:
Holder Client Device (User Vault)
The end user stores an envelope-encrypted credential vault in local browser storage (IndexedDB). All zero-knowledge proofs are generated entirely client-side using WebAssembly (Wasm). Identity secrets and private keys never leave the user device.
First-Time Issuance Provider (Didit)
First-time users undergo either passive facial age estimation or government ID inspection. Immediately upon credential minting, LKP issues an automated privacy deletion instruction to Didit to purge captured camera frames. Didit maintains only statutory fraud prevention telemetry under its privacy terms.
LKP Confidential Enclave Signer
The enclave signer operates in an isolated hardware execution environment (AWS Nitro Enclave or GCP Confidential Space). It validates the provider response, commits the credential to an indexed Sparse Merkle Tree (SMT), issues an EdDSA signature, and immediately purges personal attributes from memory.
Relying Party (Your Application)
Your application receives only a boolean outcome (isOver18: true) and a pairwise pseudonymous nullifier. Your servers never receive names, birth dates, document scans, or facial images.
Step 3: Consultation Process#
Internal Stakeholders: The Data Protection Officer, Chief Information Security Officer, and Engineering Leads have reviewed this data flow to confirm the absence of raw PII ingestion.
User Transparency Notice: Under Articles 13 and 14 GDPR, controllers must provide concise, transparent information. Display this notice at your verification entry point:
Step 4: Assess Necessity and Proportionality#
Lawful Basis (Article 6 GDPR):
- Article 6(1)(c) (Legal Obligation): Compliance with statutory child protection and age verification mandates, including the UK Online Safety Act 2023 and EU Digital Services Act.
- Article 6(1)(f) (Legitimate Interests): Ensuring platform integrity and protecting minors from adult or restricted content.
Special Category Data (Article 9 GDPR): Where biometric signals are processed during first-time estimation, processing is justified under Article 9(2)(g) (Reasons of substantial public interest under statutory law) or Article 9(2)(a) (Explicit consent).
Compliance with Article 5 Principles
- Data Minimization (Article 5(1)(c)): Rather than collecting passport photos and birth dates, the controller receives only mathematical confirmation of the specific eligibility condition.
- Purpose Limitation (Article 5(1)(b)): Credentials remain in the user local device vault and cannot be inspected without explicit per-session user consent.
- Storage Limitation (Article 5(1)(e)): Zero PII is retained in controller databases. Challenge nonces expire automatically within minutes via single-use Redis GETDEL calls.
- Unlinkability: Nullifiers are generated as
Poseidon(identity_secret, app_id). Two independent services receive completely uncorrelated identifiers, preventing cross-merchant profiling.
Step 5: Identify and Assess Risks#
The following risk matrix evaluates potential privacy risks before technical safeguards are applied:
| Risk Description | Likelihood | Impact | Initial Risk |
|---|---|---|---|
| Data breach at Relying Party exposing user identity documents or biometric scans. | Medium | Critical | High |
| Replay of stolen proofs to impersonate legitimate users on other websites. | Medium | High | Medium |
| Biometric estimation error allowing a minor to pass an age gate (false accept). | Low | Critical | Medium |
| Cross-service user tracking and behavioral profiling across multiple merchants. | High | High | High |
| Compromise of end-user client device exposing locally stored credential vault. | Low | Medium | Low |
Step 6: Identify Measures to Reduce Risk#
Technical and architectural controls deployed to mitigate the identified risks:
| Risk Area | Technical Control Applied | Residual Risk |
|---|---|---|
| Relying Party Data Breach | Zero PII ingestion architecture. No documents, photos, or birth dates touch relying party servers. Database breaches reveal only boolean flags and pseudonyms. | Negligible |
| Proof Replay Attacks | Ephemeral challenge nonces with automatic Redis GETDEL single-use consumption, cryptographic entropy, and per-relying-party domain binding. | Negligible |
| Age Estimation Boundary Error | Enforced 3-year safety buffer in enclave logic. If facial estimation is under 21 for an 18+ gate, estimation issuance is denied and government document inspection is mandated. | Low |
| Cross-Site Tracking | Pairwise nullifiers calculated via Poseidon hash over identity secret and relying party app ID. Cryptographically unlinkable across different platforms. | Negligible |
| Device Compromise | Client-side AES-256-GCM envelope encryption unlocked exclusively through hardware-backed WebAuthn biometric passkeys. | Low |
Step 7: Sign-Off and Record Outcomes#
Formal sign-off by the Data Protection Officer and senior management records the decision to proceed with the zero-knowledge verification architecture:
The integration of LKP zero-knowledge verification satisfies the principles of data minimization and privacy by design under Article 25 GDPR. Raw personal data is not collected or retained by our organization. Residual privacy risks to data subjects are evaluated as Negligible to Low.
Third-Party References#
Review Didit's statutory data processing and retention policy at Didit Privacy Policy.