Carrying out a DPIA: when it is required and how (AVG and ISO 27701)
A DPIA (data protection impact assessment) is a risk assessment that you carry out in advance for processing of personal data that is likely to pose a high privacy risk. The duty is set out in article 35 of the AVG (Algemene Verordening Gegevensbescherming, General Data Protection Regulation) . The Autoriteit Persoonsgegevens (Dutch Data Protection Authority, AP) has a list of 17 types of processing for which a DPIA is always required.
If you work with ISO 27701, a DPIA is not a separate project. The standard requires a privacy risk assessment as a fixed part of your PIMS (privacy information management system). A good DPIA is evidence that this assessment works. Below you can read when you must carry out a DPIA, what it must contain, and what a completed DPIA looks like.
When is a DPIA required?
You must carry out a DPIA if processing is “likely to result in a high risk” for the people whose data you process. You assess that yourself. Three sources help you with that assessment.
| Source | What it says | Example |
|---|---|---|
| AVG article 35(3) | Three situations in which a DPIA is always required | Processing health data on a large scale |
| AP list (2019) | 17 types of processing that require a DPIA | Monitoring employees, camera surveillance, biometrics |
| 9 criteria from the European Data Protection Board (EDPB) | Rule of thumb: 2 or more criteria means a DPIA | Sensitive data and vulnerable people |
The AP list is also published as a decision on wetten.overheid.nl . If your processing is not on it, use the nine criteria. The AP stresses that you must also be able to justify why you do not carry out a DPIA. That is part of your duty to account.
The 9 criteria in brief
- Evaluating people based on personal characteristics (profiling, scoring).
- Automated decisions with significant effects.
- Systematic and large-scale monitoring.
- Sensitive data, such as health or criminal data.
- Large-scale processing.
- Matching or combining data sets.
- Data about vulnerable people: employees, children, patients.
- New technology, for example AI or the internet of things.
- People are excluded from a right, service or contract.
When do you not need a DPIA?
No DPIA is needed if the risk is unlikely to be high, or if your processing closely resembles processing for which a DPIA has already been carried out. If a law regulates the processing and a DPIA was already carried out for that law, the duty usually lapses too.
Healthcare has a special exception. Individual doctors and healthcare professionals do not need to carry out a DPIA for their patients’ data (recital 91 AVG). According to AP guidance on large-scale processing in healthcare , this changes above 10,000 patients in one information system. Then the processing is large-scale, and a DPIA and a functionaris gegevensbescherming (data protection officer, FG) are required.
What must a DPIA contain?
The AVG does not prescribe a fixed method. You may use your own template, as long as these four parts are included (article 35(7)).
| Part | Question it answers |
|---|---|
| Systematic description | What will you process, about whom, for what purpose, and with which systems? |
| Necessity and proportionality | Is the purpose justified, and do you process no more than necessary? |
| Risks to data subjects | What can go wrong for the people themselves, and how serious is that? |
| Measures | How do you reduce those risks, and how do you show compliance? |
If you have an FG, you must ask for their advice and record in the report what you did with it. A processor must help you with information, for example on security and sub-processors.
How to carry out a DPIA in 5 steps
Describe the processing
Write down in plain language which data you collect, from which group of people, for which purpose, and which systems and suppliers are involved. Take the basis from your processing register.
Test necessity and proportionality
Record the lawful basis and ask whether the purpose can be achieved with less data. Choose retention periods and decide who gets access.
Map the risks
Think from the perspective of the data subject, not your company. What happens if data leaks, is no longer correct, or wrongly leads to a decision? Score likelihood and impact, for example with a risk matrix.
Choose measures and determine the residual risk
Link a measure and an owner to each risk. Then assess what risk remains.
Decide, record and plan a reassessment
Have the owner of the processing sign off. If a high residual risk remains, you must first consult the AP through prior consultation (article 36).
Example: DPIA for an absence module in HR software
Fictional example. A SaaS company with 60 staff supplies HR software to 300 clients. It adds an absence module in which clients record sick notifications and recovery dates. The company is a processor for this; the clients are the controllers. The clients must carry out the DPIA, but the company supplies a ready-made DPIA section.
Criteria check: sensitive data (4), large scale (5), vulnerable people: employees (7). Three criteria, so a DPIA is needed.
| Risk for the employee | Likelihood | Impact | Measure | Residual risk |
|---|---|---|---|---|
| A line manager sees a diagnosis that only the company doctor (bedrijfsarts, occupational health doctor) may see | Medium | High | No free-text field for complaints; role-based access | Low |
| Data breach at the hosting provider | Low | High | Encryption, sub-processor within the EU, annual penetration test | Low |
| Absence history stays on record for years | High | Medium | Automatic deletion after the agreed period | Low |
| Client uses the module to profile “frequent absentees” | Medium | High | No ranking function; instruction in the processing agreement | Medium |
The company does not simply accept the “medium” residual risk for profiling. It agrees in the processing agreement that the client will not use the module for profiling, and it monitors exports. The FG gives positive advice, provided the retention period can be set per client.
The DPIA is not a one-off document. If a new feature is added, such as AI predictions of absence, you review the DPIA. New technology is itself a criterion.
How does the DPIA link to ISO 27701?
ISO 27701 requires you to assess privacy risks systematically, both for your organisation and for the data subjects. The DPIA under the AVG is the most demanding form of this, for high-risk processing. Annex D of the standard links controls to AVG articles, including article 35.
| AVG requirement | Where it appears in your PIMS |
|---|---|
| DPIA for high risk (art. 35) | Privacy risk assessment and the requirements of ISO 27701 |
| Advice from the FG | Roles and responsibilities in the PIMS |
| Assistance from the processor | Measures for processors on supporting the controller |
| Periodic reassessment | Internal audit and management review |
The auditor checks in the ISO 27701 audit whether you have carried out a criteria check, whether DPIAs are up to date, and whether the measures have actually been put in place. A DPIA that sits in a drawer leads to a nonconformity.
Common mistakes with a DPIA
- Doing the DPIA only after go-live. Start in the design phase, even if not everything is settled yet.
- Describing only IT risks. A DPIA is about the consequences for people, not about your server going down.
- The processor leaves the DPIA to the client without information. The processor must cooperate.
- No justification for “no DPIA needed”. Write down briefly which criteria you checked.
Further reading
- Processing register with example: the basis for every DPIA
- ISO 27701 step-by-step plan: where the DPIA fits in your implementation
- AVG and ISO 27701: how the standard connects to the law
- AP on the DPIA : explanation from the supervisor