A data protection impact assessment tends to be requested at the worst possible moment: the design is finished, the sprint is booked, and someone asks whether the new feature can lawfully process health data. Done early, a DPIA is not paperwork. It is a short, structured argument — here is what we want to do with people's data, here is why it is justified, here is what could go wrong, and here is how we are reducing the harm.
When a DPIA Is Required — and When It Is Not
Under the GDPR, a DPIA is mandatory before processing likely to result in a high risk to people's rights and freedoms. In practice that means new, large-scale or intrusive processing. Most supervisory authorities publish lists of operations that always require one, so check your own regulator's list rather than relying on a summary.
Common triggers include:
- Systematic profiling with significant effects, such as automated eligibility or credit decisions.
- Large-scale handling of sensitive data: health records, biometrics, genetic data, political opinions.
- Systematic monitoring of a publicly accessible area at scale.
- Familiar technology used in a new way, such as biometric attendance systems.
- Combining datasets in ways people would not expect — loyalty purchases matched to location history.
- Data about children or other vulnerable groups, or data that could enable identity theft.
If you are unsure, run a short screening questionnaire and record the answer either way. A paragraph explaining why a DPIA was not needed beats silence. When the call is close, an hour with a lawyer who knows data protection is cheaper than redesigning a product later. This article is general guidance, not legal advice.
Before You Start: Scope, Owner, People
Decide what exactly is being assessed. A single feature? A vendor contract? A change to how long you keep support tickets? Vague scope produces a vague DPIA.
Then name one owner — the person accountable for the product or process, not whoever fills in the template. Bring in engineering, security, your privacy or legal contact, the people who will run the system daily, and ideally someone representing those affected. Support staff who field complaints routinely spot harms a process diagram hides. Set a deadline, too: a first draft within a week is realistic, and a draft you can argue with beats a perfect one that arrives after launch.
The Eight Steps
- Describe the processing. Purpose, data categories, sources, recipients, retention, systems, vendors, cross-border transfers. Draw it on one page; the diagram usually surfaces the awkward question you were avoiding.
- Test necessity and proportionality. Is this the least intrusive route to the goal? For each field, ask what breaks if you stop collecting it, halve retention, or store a birth year instead of a full date of birth.
- Identify risks to individuals. Not to your organisation — to the people in the data: discrimination, financial loss, reputational damage, distress, loss of control. Write concrete scenarios, such as a manager inferring a named colleague's mental health treatment from a leaked table.
- Confirm the lawful basis. Name the basis for each purpose and, for sensitive data, the additional condition. If consent is your basis, describe the mechanism people will actually see.
- Consult. Ask vendors, processors and internal teams who understand the system, and where appropriate seek the views of affected people or their representatives. Record what they said and what you changed.
- Apply mitigations. Encryption, access controls, pseudonymisation, shorter retention, clearer notices, human review of automated decisions, contractual limits on suppliers. Give each one an owner and a date.
- Sign off residual risk. Compare remaining risk against your threshold. If high risk persists, the law generally expects consultation with the supervisory authority first — confirm what applies to you. Sign-off should be a name, not a department.
- Record and review. Add the DPIA to a register, revisit it at defined milestones, and update it when the purpose, data, scale or suppliers change. A document nobody reopens is a snapshot, not an assessment.
What Good Documentation Looks Like
Keep the record findable, versioned, and short enough that a new colleague could follow it in two years. At minimum it should hold the purpose and lawful basis, a description of the processing and data flows, the risk assessment with likelihood and severity, mitigations with owners, the residual risk decision and sign-off, consultation responses, and the next review date.
Write in plain language. If you cannot explain a risk in one sentence, the risk is still fuzzy. Skip the acronym soup, and do not pad the document to look thorough — reviewers reward clarity, not length.
Mistakes That Undermine the Exercise
- Running it after launch, when it becomes an apology instead of a decision aid.
- Assessing harm to the business while ignoring harm to individuals.
- Copying the last DPIA and swapping the project name.
- Listing mitigations with no owner, date or way to verify them.
- Skipping consultation because "we know our users".
- Treating "no risk identified" as success. It usually means the scope was too narrow.
Making It Part of Normal Work
Teams that handle this well do three unglamorous things. They keep a reusable template with sensible defaults, so nobody starts from a blank page. They add one trigger question to project intake: does this involve new data, new groups of people, or a bigger scale than before? And they link the privacy assessment to the security review, so the two stop asking each other the same questions.
Most of all, they run it while the design is still soft. A DPIA finished before a team has committed emotionally to a feature shapes that feature; the same document finished afterwards only records regret. Take the eight steps to your next project that touches personal data, keep version one short, and refine it as you learn. Where legal obligations or sensitive categories are involved, bring in a qualified privacy professional early — that advice is worth more than any template.
Photo: Vitaly Gariev / Pexels
