DPIA step by step. When it is required and how to do one.
Half of firms do DPIAs on everything just in case, the other half never do them at all. Both groups have a problem; just a different one.
Let’s sort out DPIAs once and for all. A Data Protection Impact Assessment, the DPIA from Art. 35 GDPR, is not a “just to be safe” document. You do one when processing is likely to result in a high risk to the rights and freedoms of individuals. The problem is that “high risk” sounds soft, but the criteria are firm.
TL;DR
- DPIA required when processing is likely to result in high risk (Art. 35)
- Practical test: 10 EDPB criteria (WP248), threshold of 2 or more = you do it
- In Poland the Polish DPA catalogue (M.P. 2019 item 666) adds a mandatory list on top
- A DPIA is a process with a decision and residual risk; not a form you file away
When a DPIA is required
First, the bad news: there is no single simple yes/no. What there is, is a practical test from the EDPB guidance (WP248) listing 10 criteria. Profiling and scoring, large-scale processing, sensitive data, monitoring of public spaces, data on vulnerable individuals, and several more.
The EDPB rule of thumb: if you meet two or more criteria, you do a DPIA. If just one, you assess individually and document your decision.
The Polish DPA catalogue; the local shortcut
In Poland there is also a simpler route in one direction. The Polish DPA published a list of processing types that require a DPIA outright (M.P. 2019 item 666). If your process is on that list, there is no debate about criteria… you do the DPIA, full stop.
How to do a DPIA step by step
In order. Describe the processing operation: purpose, scope, data categories, legal basis, recipients, retention. Assess necessity and proportionality. Identify risks to individuals and estimate them. Plan mitigation measures. Calculate residual risk after controls are applied. If the risk is still high after all that… you consult the Polish DPA before you start.
And here is the crux that most firms miss: a DPIA is not a signed Word file sitting in a drawer. It is a decision with a rationale and a status as of a specific date. Process changed? DPIA is out of date.
Why DPIAs cannot be done from scratch in isolation
Because a DPIA inherits from the Records of Processing Activities. Data categories, legal basis, systems, retention… you described all of that in your RoPA already. Retyping it manually into a separate form is asking for inconsistency.
In the GDPR module (Iodynka) the DPIA runs the WP248 and Polish DPA catalogue checks automatically, and 15 fields prefill from the process record. The decision is stored, the residual risk is calculated, and the Polish DPA gets a consistent document instead of a patchwork.
And if you want a concrete reason not to put this off: the absence of a DPIA for a high-risk process is one of the classic GDPR fine triggers. Better to have it sorted early.
Written by someone on the RealSec team. Want to talk specifics ; get in touch.