Data Protection Impact Assessment (DPIA)

When one is required

Article 35(1) of the UK GDPR sets the general test: a DPIA is required where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of individuals. Article 35(3) then names three cases where it is always required:

• systematic and extensive automated evaluation of personal aspects, including profiling, on which decisions with legal or similarly significant effects are based;
• processing on a large scale of special category data, or of personal data relating to criminal convictions and offences;
• systematic monitoring of a publicly accessible area on a large scale.

The ICO publishes its own list of processing operations that require a DPIA and a screening checklist that is worth running even when you are fairly sure the answer is no — the assessment has to happen before processing begins, and retrofitting one after launch is both harder and less useful.

What has to be in it

Article 35(7) sets the minimum contents. A DPIA must contain at least:

1. a systematic description of the processing and its purposes, including any legitimate interests pursued;
2. an assessment of the necessity and proportionality of the processing;
3. an assessment of the risks to the rights and freedoms of individuals; and
4. the measures envisaged to address those risks, including safeguards, security measures and mechanisms that demonstrate compliance.

Two further points people forget. Where a data protection officer has been designated, their advice must be sought. And where the DPIA indicates a high residual risk that you cannot mitigate, you must consult the ICO before starting — which is a good reason to do the assessment early enough that "change the design" is still an option.

A worked example: is a survey high risk?

Usually not. A satisfaction survey collecting a free-text comment and a postcode district is unlikely to meet the high-risk threshold on its own, and a screening note explaining why is often the appropriate output.

It changes when the survey collects health, ethnicity, sexual orientation, religion or trade union membership — special category data — at any scale that could be called large; when responses are linked to identifiable individuals and used in decisions about them; or when it covers children. A staff wellbeing survey that asks about mental health and carries a staff number in a hidden field is a much heavier assessment than the same questionnaire run anonymously. Genuinely anonymous data is not personal data at all, which is the cheapest risk mitigation available to you and the first one to consider.

Common mistakes

• Writing it after go-live. The obligation is prior. A DPIA produced to satisfy an audit is a document, not an assessment.
• Describing the tool rather than the processing. The assessment is about what you are doing to people, not about a supplier's architecture. The supplier's controls belong in the measures section.
• Skipping necessity and proportionality. "Could we achieve the same result with less data?" is the question most likely to change the design, and the one most often left as a paragraph of assurance.
• Treating it as one-and-done. A DPIA should be revisited when the processing changes — new questions, a new audience, a new distribution channel.
• Assuming a supplier's certification does the work. It does not, and anyone who tells you it does is selling something.

What we can give you

The controller of a survey's responses is you, so the DPIA is yours to write. What a supplier can reasonably be expected to supply is the raw material for the description and measures sections: where the data sits, who processes it, and what protects it. That is data residency (London, eu-west-2), the published sub-processor list, the controls described on the security page, and the UK GDPR page. We will answer a DPIA questionnaire rather than disappear for three weeks, and we will not answer it with certifications we do not hold.