When one is likely needed
A data protection impact assessment is required where processing is likely to result in high risk to individuals. Machine learning projects frequently land in that category without anyone noticing, because the processing looks like ordinary analytics.
- Systematic and extensive evaluation of people, including profiling and scoring
- Automated decisions producing legal or similarly significant effects
- Large-scale processing of special category data
- Systematic monitoring, including of employees
- Combining datasets in ways individuals would not expect
- Using personal data for a purpose different from the one it was collected for
That last point catches many internal projects. Data collected to fulfil orders, repurposed to predict customer behaviour, is a change of purpose and needs thinking about. We are describing general practice here rather than giving legal advice - take proper advice for your situation.
Do it while the design can still change
An assessment written after the system is built becomes a documentation exercise, and any problem it finds is expensive. Written during design, it is genuinely useful and frequently improves the system.
Questions like 'do we need this field at all', 'could this work on aggregated data' and 'how long should we keep this' are design questions. Answering them early usually produces a simpler system with less to protect.
What it should actually contain
- What the processing is, in plain language a non-specialist can follow.
- Why it is necessary, and whether a less intrusive approach would achieve the same purpose.
- The lawful basis, and where relying on legitimate interests, the balancing assessment.
- What data, from where, retained how long, and who can access it.
- The risks to individuals - not to the business - and their likelihood and severity.
- The mitigations, and the residual risk after them.
- Whether decisions are automated, and what human involvement exists.
The distinction in point five is the one most often got wrong. A DPIA assesses risk to people, not commercial or reputational risk to you.
Questions specific to machine learning
| Question | Why it matters |
|---|---|
| Can training data be minimised or aggregated? | Often the model needs less than was assumed |
| Could the model infer special category data? | Inferred health or ethnicity carries the same protections |
| Can an individual be identified from outputs? | Models can leak training data in some circumstances |
| How is accuracy monitored across groups? | Uneven performance is a fairness risk |
| What is the route to challenge a decision? | Often required, and usually not designed |
The second row surprises people. A model predicting something innocuous from behaviour may effectively infer a protected characteristic, and inferences attract the same protections as collected data.
Keep it alive
A DPIA is not a launch artefact. Retraining on new data, adding a feature, extending to a new customer group or changing what the output drives can all alter the risk profile.
Reviewing it when the model materially changes keeps it accurate and demonstrates the ongoing accountability regulators look for. Attaching the review to your existing model release process is the practical way to make that happen rather than relying on memory.
An assessment written after the build measures a decision you already made.