Data Protection Impact Assessment (DPIA)

Effective Date: May 20, 2026 Version: 1.0 Controller: VEREID, a product of AIARCO Pty Ltd, ABN [TBD: counsel review], NSW, Australia. Owner: DPO — privacy@vereid.com. Statutory basis: GDPR Art. 35; UK GDPR Art. 35; analogous DPIA expectations under the Australian Privacy Act 1988 (good practice, OAIC guidance), and the Illinois BIPA (risk assessment recommended). Status: v1.0 — pre-live. Live EU /v1/verify traffic is BLOCKED until this DPIA is signed off by counsel (Hard Gate 6).

1. Why a DPIA is required

A DPIA is mandatory under GDPR Art. 35(3) because the processing involves:

• (a) systematic and extensive evaluation of natural persons based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects (sanctions screening; tier assignment; access to a B2B Customer's service);
• (b) processing on a large scale of special-category data under Art. 9 — biometric face templates used to uniquely identify a person; and
• (c) systematic monitoring of a publicly accessible area is not in scope, but large-scale processing of identity documents is.

The ICO's published DPIA-required list and the EDPB Guidelines on DPIAs (WP248 rev.01) both flag identity-verification + biometrics as warranting DPIA. Australian OAIC privacy-impact-assessment guidance treats biometric and government-record processing as high-risk.

2. Description of the processing

2.1 Nature

• Inbound API call from a B2B Customer (POST /v1/verify) or in-product flow on vereid.com.
• Optional collection of selfie / liveness video → face template extraction → match against the document portrait.
• Optional OCR + MRZ parse + NFC chip Passive Authentication.
• Optional sanctions / PEP screen against US, EU, UK, UN, AU consolidated lists.
• Result returned to caller with a tier label and a per-component confidence + a single "passed / failed / inconclusive" verdict.
• Persistence in PII-VAULT, encrypted with the pii-vault-and-audit KMS CMK.
• Audit event appended (WORM, 7 years).

2.2 Scope

• Categories of data: identity (name, DOB, address, document number, document images), biometric (face template + liveness frames), telemetry (IP, device, timestamps), B2B Customer metadata.
• Geographic scope at v1: AU, NZ, US, UK; EU activation gated on counsel sign-off.
• Data subjects: end-users being verified; B2B Customer principals.

2.3 Context

• Verification is initiated by the data subject in most flows (they scan their own document and take their own selfie). For some B2B flows the subject is invited via email/SMS link.
• Subjects expect verification will be required to access regulated services; expectation of biometric processing is established through explicit consent before camera activation.

2.4 Purposes

1. Allow B2B Customers to satisfy their own CDD / KYC / KYB obligations.
2. Allow VEREID Social to maintain a verified-only commenting / messaging surface.
3. Sanctions and fraud prevention.
4. Audit and dispute defence.

3. Necessity and proportionality

4. Risk identification and mitigation

We use a likelihood × severity matrix scored Low / Medium / High.

Risk 1 — Biometric template breach

• Likelihood: Medium (sustained attacker interest).
• Severity: High (irrevocable identifier).
• Mitigations:
  • Face template is a vector; not directly re-identifiable to a face image.
  • Encrypted with pii-vault-and-audit KMS CMK; CMK access policy restricts decrypt to two named roles.
  • 30-day post-match purge — limits blast radius.
  • PII-VAULT schema split from PRIMARY DB; in V2, separate Aurora cluster with no shared compute role.
  • S3 bucket object-level encryption + bucket-level Object Lock for audit copies.
  • Quarterly red-team exercise on the vault path.
• Residual risk: Medium — accepted, monitored.

Risk 2 — False reject (legitimate user blocked)

• Likelihood: Medium (1–5% expected per face-match operating point).
• Severity: Medium (loss of access to B2B Customer's service; possible reputational harm to user).
• Mitigations:
  • Manual review pathway with 4-hour SLA for paid plans.
  • Subject can re-attempt with different lighting / angle; we log the failure but do not penalise.
  • Demographic-fairness bench run quarterly; if any subgroup exceeds median FRR by > 2x, retrain or change vendor.
• Residual: Low–Medium.

Risk 3 — False accept (impersonation passes)

• Likelihood: Low at the operating point chosen.
• Severity: High (downstream account takeover or sanctions evasion).
• Mitigations:
  • Liveness + tamper-detection signals combined.
  • Manual review on borderline scores.
  • B2B Customer always sees the per-component score, not just verdict.
  • Suspicious clusters flagged into the AML monitoring stream.
• Residual: Low.

Risk 4 — Over-collection / scope creep

• Likelihood: Medium.
• Severity: Medium.
• Mitigations: Hardcoded payload schema; product principle that tier ladder is the only knob the Customer can adjust; quarterly DPO review of new fields.

Risk 5 — Discriminatory outcomes

• Likelihood: Medium (well-documented industry concern).
• Severity: High.
• Mitigations:
  • Vendor evaluation includes NIST FRVT demographic performance data.
  • We do not collect "ethnicity" as a feature.
  • Public bias-bench published annually.
  • Manual-review pathway is mandatory.

Risk 6 — Function creep into surveillance

• Likelihood: Low.
• Severity: High.
• Mitigations: ToS Schedule 1 excluded-uses; sales DD on B2B Customer use-case; ability to suspend Customer for breach.

Risk 7 — Sanctions list false-match leading to wrongful denial

• Likelihood: Medium (common-name issue).
• Severity: Medium.
• Mitigations: Two-stage screen (algorithmic + analyst), with subject-facing reason if denial is final and law permits notification.

Risk 8 — Government-record lookup (T6) leaking the fact-of-query

• Likelihood: Medium.
• Severity: Medium–High depending on country.
• Mitigations: T6 disabled until per-country counsel sign-off; each country independently risk-assessed before enabling. Audit log shows every issuing-authority call.

Risk 9 — Cross-border transfer / sub-processor risk

• Likelihood: Low.
• Severity: Medium.
• Mitigations: EU data localised to eu-central-1 (when enabled); AU data in ap-southeast-2; SCCs + IDTA; sub-processor due-diligence (see SUB_PROCESSORS.md).

Risk 10 — DSR fraud (impostor asks for export / deletion)

• Likelihood: Medium.
• Severity: High.
• Mitigations: DSR endpoints require strong identity proof (MFA + re-verification for high-risk); see DSR_ENDPOINTS.md.

5. Consultation

• Data Protection Officer. Designed the matrix above.
• External counsel. [TBD: counsel review and sign-off] — required to lift the Hard Gate 6 EU geo-block on /v1/verify.
• Data subjects. Public consultation via a published draft of this DPIA on the trust page; we will accept comments at privacy@vereid.com for 30 days post-publication.
• Information Commissioner consultation. Not currently required — risk levels post-mitigation are not "high" residual. If post-mitigation residual rises to High, we will consult the lead supervisory authority under Art. 36 GDPR before processing.

6. Sign-off

7. EU AI Act alignment

Although not yet binding for all provisions at the date of this DPIA, we have proactively assessed VEREID against the EU AI Act framework:

We will reassess on each substantive AI Act delegated act publication.

8. Engineering controls mapped to risks

9. Review schedule

• Annually, or sooner on material change (new tier, new geography, new sub-processor, new product, regulatory change, material incident).
• Logged change history in this file under git history at VEREID_MASTER/legal/DPIA.md.

[TBD: counsel review — confirm that biometric processing under explicit consent is the right Art. 9 lever for the Customer flow and not Art. 9(2)(g); confirm that T6 disablement also covers our development-environment mock services; confirm we have no need to consult the OAIC under Australian guidance; confirm the 1:1 verification vs 1:N identification distinction holds under the AI Act final text.]