When you need a DPIA, and how to tell before you need one

Article 35 requires an assessment where processing is likely to result in a high risk. Here's what triggers it, and why the screening question is the one worth building into your process.

Article 35(1) requires a data protection impact assessment where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. The assessment has to happen prior to the processing.

Two words in that sentence do most of the work. "Likely" means you assess the risk before you know the outcome. "Prior" means a DPIA written after launch has failed at its purpose, whatever its quality.

The three cases Article 35(3) names

The article gives three situations where a DPIA is required in particular:

1. 1Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person.
2. 2Processing on a large scale of special categories of data under Article 9, or of data relating to criminal convictions and offences under Article 10.
3. 3Systematic monitoring of a publicly accessible area on a large scale.

That list is not exhaustive. It names three clear cases; the general test in 35(1) still applies to everything else, and supervisory authorities publish their own lists of operations requiring a DPIA.

The screening habit that prevents the problem

Most DPIA failures are not bad assessments. They are assessments that never got started, because nobody asked the question at the point a decision was being made.

The fix is procedural rather than legal: put a short screening question into whatever process approves new work. New system, new supplier, new data source, new use of data you already hold. Five questions is enough to catch the cases that need the full assessment.

• Does this involve special category data, criminal offence data, or data about children?
• Does it evaluate or score people, or make automated decisions about them?
• Does it monitor people systematically, or combine data from sources they gave separately?
• Is it a scale or a use the people concerned would not expect?
• Does it use a technology or an approach we have not used before on personal data?

Any yes means run the screening properly against Article 35(3) and the ICO's guidance. The point of the short list is that a project manager can apply it without training.

Where a DPIA indicates high residual risk that you cannot mitigate, Article 36 requires you to consult the supervisory authority before processing. That is a reason to run the assessment early, when the design can still change.

What a DPIA has to contain

Article 35(7) sets the minimum: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects, and the measures you intend to use to address those risks.

The necessity and proportionality limb is the one with teeth. It asks whether the processing achieves the purpose and whether it could achieve it with less, which is the same question the legitimate interests test asks and is answered the same way: against the data you actually hold.

How EmberHound fits

Two of the four required elements depend on knowing what data is in play. The systematic description needs the real categories, and the necessity assessment needs to test them against the purpose.

EmberHound scans enrolled company devices and reports personal data by category and location, which grounds both. It does not tell you whether a DPIA is required, and it does not perform one.

This article is general information, not legal advice. Confirm the obligations that apply to your organisation before acting on it.