Data Protection Impact Assessment (Template & Guidance)
Version 1.0 — DRAFT for review · Effective date: [EFFECTIVE DATE]
⚠ TEMPLATE, NOT LEGAL ADVICE. A DPIA is mandatory before you deploy facial recognition. This template helps you structure yours; it does not complete your DPIA or constitute advice. Have it reviewed by your data‑protection adviser. As the controller, the completed DPIA is yours.
A DPIA is legally required for facial recognition because it is large‑scale processing of special‑category biometric data using innovative technology — squarely within the ICO's "likely high risk" criteria. Complete this before going live and keep it under review.
1. Describe the processing
- Controller: [your organisation]
- Processor: [Pariah Ltd] (the Platform)
- What: capture of facial images, generation of biometric templates, matching against watchlists, alerting, and incident logging.
- Where/when: [sites, camera locations, hours of operation]
- Scale: [approx. individuals captured per day; watchlist size]
- Data flows: continuous detection processed locally on the NVR; manual mobile searches use cloud facial search (AWS Rekognition); storage of media/assets via Cloudflare R2.
- Retention: [your configured retention for detections, search logs, incidents]
2. Consultation
Record who you consulted — data subjects or their representatives (where appropriate), staff, your DPO, and any processors.
3. Necessity and proportionality
- Purpose: [the specific security problem you are solving]
- Lawful basis (Art. 6) and condition (Art. 9): [see /legal/legal-basis]
- Why facial recognition is necessary: [evidence; why less intrusive measures are insufficient]
- Data minimisation: [who is enrolled and why; how you avoid capturing more than needed]
- Transparency: [signage, privacy notice, how individuals are informed]
- Data‑subject rights: [how you handle access, erasure — including for listed individuals]
4. Identify and assess risks
For each risk, record likelihood, severity, and overall risk:
| Risk to individuals | Likelihood | Severity | Overall |
|---|---|---|---|
| Misidentification (false positive) leading to wrongful treatment | |||
| Bias/discrimination across demographics | |||
| Excessive or indefinite retention | |||
| Lack of awareness (no effective notice) | |||
| Unauthorised access / data breach | |||
| Function creep beyond the security purpose | |||
| Chilling effect / disproportionate surveillance |
5. Measures to reduce risk
| Risk | Measure | Effect on risk | Residual risk |
|---|---|---|---|
| Misidentification | Human review before action; confidence thresholds | ||
| Bias | Monitoring, testing, fair‑treatment procedures | ||
| Retention | Short, enforced retention periods | ||
| Transparency | Signage + privacy notice | ||
| Security | Encryption, RBAC, audit logging (see DPA Annex B) | ||
| Function creep | Documented purpose limitation; access controls |
6. Sign‑off and review
- DPO advice: [record]
- Residual risk accepted by: [name, role, date]
- If high residual risk remains and cannot be mitigated: consult the ICO before processing.
- Review date: [date] — review at least annually and on any material change.
Use this alongside the ICO's DPIA guidance (ico.org.uk). Questions: [email protected]