Data Protection Impact Assessment (DPIA): Duty, Process and Examples

What Is a Data Protection Impact Assessment?

A data protection impact assessment is a risk check for personal data. You do it before a new use of data starts, such as new software, a camera system or an AI system.

The focus is not on risks to the company, but on risks to the people whose data it is. The question is: what could go wrong for customers, staff or patients, and how do we prevent it?

In German, the short form DSFA is used. In English, it is called DPIA. Both mean the same thing.

Legal Basis: Article 35 GDPR

The DPIA is set out in Article 35 of the General Data Protection Regulation (GDPR). A DPIA is mandatory if a processing is "likely to result in a high risk to the rights and freedoms of natural persons". This is true above all for new technology.

Article 35(3) names three cases in which a DPIA is always needed:

• Rating people: a broad, systematic rating of people, for example through profiling, that leads to decisions with legal or similar major effects.
• Special data: large-scale use of special types of data, such as health data, or of data on crimes.
• Monitoring: large-scale, systematic monitoring of public areas.

Breaking this duty can lead to a fine of up to 10 million euros or 2 % of yearly turnover worldwide.

When Is a DPIA Needed?

Besides the law, two tools help with the decision:

• Must lists: the German data protection authorities have published a list of cases in which a DPIA is always required. Examples are combining large data sets from different sources and scoring.
• Nine criteria: the European data protection authorities name nine signs, such as sensitive data, large amounts of data, people in need of special care and new technology. If two or more apply, a DPIA is usually needed.

Typical examples from practice:

• Video surveillance in shops or car parks
• Systems that monitor the performance or behavior of staff
• Health apps and telemedicine
• Credit checks and scoring
• AI systems that make decisions about people. See DPIA for AI.

If no DPIA is needed, briefly explain why and document it. That way, you can prove your decision later.

What a DPIA Must Contain at a Minimum

Article 35(7) GDPR sets out the minimum content:

1. a systematic description of the processing and its purposes
2. a check of whether the processing is needed and in proportion to its goal
3. a rating of the risks to the people concerned
4. the planned measures to address these risks

The Process in Seven Steps

1. Check whether a DPIA is needed: using the must list and the nine criteria.
2. Build the team: the business unit, IT, information security and the data protection officer. Their advice is mandatory.
3. Describe the processing: which data, from whom, for what purpose, with which systems, shared with whom and stored for how long?
4. Check necessity: could it be done with less data? Is there a legal basis?
5. Rate the risks: what harm could the people concerned suffer, such as unfair treatment, identity theft or exposure? How likely and how bad is it?
6. Set measures: technical and organizational steps such as encryption, pseudonyms, access rights, deletion periods or training.
7. Record and review the result: if a high risk remains, ask the data protection authority. If the processing changes, update the DPIA.

A good method is the standard data protection model (SDM) of the German data protection conference. It links measures to the goals of data protection. Internationally, there is also the ISO/IEC 29134 standard.

An Example from Practice

A logistics company wants to track its drivers' vehicles by GPS to plan routes better. The tracking is broad, affects staff and reveals how they behave. So a DPIA is needed.

The DPIA shows that tracking every minute in real time would go too far. The company decides on measures: tracking only during working hours, storage for a few weeks, access only for dispatch and no use of the data to rate single drivers. The works council is involved. The remaining risk is now acceptable.

DPIA and Information Security

The DPIA and risk management for information security work hand in hand. Many safeguards are the same, such as encryption, access control and logging. If you run an ISMS, you can use its risk analysis and list of measures for the DPIA.

The point of view is what matters. The ISMS asks about risks to the company, the DPIA about risks to people. A good approach combines both. The principles of privacy by design and privacy by default help with this.

Common Mistakes

• Too late: the DPIA must take place before the start, not after rollout.
• Just a form: a filled-in template without a real risk check protects no one.
• Wrong point of view: it is about the people concerned, not the company.
• One-off: a DPIA is not a project with an end date. It is reviewed when things change.
• Data protection officer not involved: their advice is required by law.

Software Support

A DPIA is closely linked to other data protection records. The data protection module of SecTepe.Core covers records of processing (RoPA), technical and organisational measures (TOMs), impact assessments (DPIA), the rights of data subjects, data breaches and processors.

Conclusion

The data protection impact assessment checks before the start whether a processing puts the people whose data is processed at risk. It is mandatory where the risk is high and follows a clear process. If you start early, involve the data protection officer and update the DPIA when things change, you protect the people concerned and yourself.