Do you need a DPIA before launch?

By Weapp · Updated 2026-01-25

A DPIA, data protection impact assessment, is required under GDPR when a data processing activity is likely to result in high risk to people's rights – for example with sensitive data, profiling, or large-scale monitoring. The assessment maps the risks and how they're handled before the service is built. Done early, it shapes design decisions instead of becoming an afterthought.

Before a new digital service launches, the question often comes up too late: do we need to do a DPIA? A data protection impact assessment is GDPR’s tool for catching privacy risks before they get built in, and for some services it’s a legal requirement. Done in time, it’s a support that shapes a better service; done too late, it becomes a stressful formality. This guide helps you determine whether your service triggers the requirement and how to carry out the assessment so it delivers real value.

The criteria that trigger the requirement

The basic rule under GDPR is that a DPIA is required when a processing of personal data is likely to result in a high risk to people’s rights and freedoms. That sounds abstract, but in practice there are a number of concrete criteria that carry weight, and the more that apply, the clearer the requirement.

Sensitive data. Processing of health, ethnicity, religion, sexual orientation, or similarly protected categories.
Mapping and profiling. Systematic evaluation of people, such as scoring, behavioral analysis, or automated decision-making.
Large-scale processing. Large volumes of data or a large number of data subjects.
Monitoring. Systematic surveillance of public or semi-public spaces.
Vulnerable groups. Data about children, patients, or others in a dependent position.
New technology. Solutions whose privacy impact is hard to foresee in advance.

If just one of these applies slightly, a simpler assessment may suffice. If several combine – an app that profiles users at scale, or a service with sensitive data about children – a DPIA is almost always necessary. If you’re unsure, the basic approach is simple: do a preliminary risk assessment, and if it lands high, do a full DPIA.

The process step by step and who should be involved

A DPIA isn’t a single form but a review in several steps. The goal is to understand the processing, weigh its risks, and decide how to reduce them – before anything is built.

Describe the processing. What data is collected, why, how does it flow, and how long is it kept?
Assess necessity and proportionality. Is all the data really needed for the purpose, or can less be collected?
Identify the risks. What could go wrong for the individuals involved – leakage, misuse, unwanted profiling?
Decide on measures. How are the risks reduced: less data, shorter retention, encryption, tighter permissions?
Consult if high risk remains. If the risk stays high despite measures, the supervisory authority should be consulted before starting.

Just as important as the steps is who takes part. Whoever is responsible for the processing leads the work, the data protection officer advises and reviews, the business explains the purpose, and those technically responsible describe how the data is actually handled. Without the technical perspective, the assessment easily becomes a desk exercise that doesn’t reflect reality. Nor is a DPIA a one-off document – if the service changes significantly, it needs to be updated.

How the result shapes design decisions

What separates a meaningful DPIA from a shelf-warmer is when it’s done. Carried out early, while the service is still being designed, it becomes a design tool. Carried out after the system is built, it becomes at best a confirmation of problems that are now expensive to fix.

An early DPIA often leads to concrete choices: maybe you don’t need to collect a certain field at all, maybe pseudonymized data is enough for the purpose, maybe the retention period should be shortened or access restricted more tightly. Such decisions are trivial to make on the drawing board but costly to rebuild afterward. That’s the whole idea behind privacy by design – shaping privacy into the service from the start instead of patching it on at the end. A common misconception is that a DPIA is just legal paperwork. In reality, it’s one of the best opportunities to make smarter technical decisions, precisely because it forces the question “do we really need this data?” before any code is written.

A concrete scenario

An organization was planning a service that would track user activity over time to provide personalized recommendations. The processing involved profiling at some scale, and a preliminary risk assessment landed high – a full DPIA was warranted, and it was done before development kicked off.

The assessment led to several design changes. Some data originally meant to be collected turned out to be unnecessary for the purpose and was dropped. What was needed was pseudonymized, the retention period was shortened, and access was restricted to a handful of roles. The changes were made on the drawing board, at no cost to rebuild. Had the DPIA only been done after launch, the same insights would instead have meant rebuilding a finished service – more expensive, slower, and with a period of unnecessary risk in between.

Do the assessment in time

A DPIA is nothing to put off until just before launch. Decide early whether the service triggers the requirement, involve legal, business, and technology alike, and let the conclusions shape the design while it’s still cheap. Then the assessment isn’t a brake but a support that delivers both better privacy and smarter technical choices.

At Weapp, we build with privacy by design as a starting point and are happy to contribute the technical perspective to a DPIA, as part of our services. Planning a service that handles personal data? Get in touch and we’ll think through whether a DPIA is needed and how best to weave it in early in the project.

Frequently asked questions

What is a DPIA?

A data protection impact assessment is a structured review of how a planned processing of personal data affects people's privacy, and what measures reduce the risks. It's required under GDPR when the processing is likely to result in high risk. The purpose is to spot and address data protection problems before they get built into a service, while it's still easy and cheap to do something about them.

What criteria trigger the requirement for a DPIA?

Processing likely to result in high risk. Typical triggers are sensitive data such as health or ethnicity, systematic mapping or profiling of people, large-scale processing, and monitoring of public spaces. New technology and processing involving children or vulnerable groups also weigh heavily. If several criteria apply at once, a DPIA is almost always warranted, and often a legal requirement.

How does a DPIA work?

You describe the processing, assess whether it's necessary and proportionate, identify the risks to the individuals concerned, and decide on measures that reduce them. The data protection officer is involved, as are those who understand the technology and the business. If high risk remains despite the measures, the supervisory authority must be consulted before processing starts. The result is documented and kept up to date.

Who should be involved in a DPIA?

Whoever is responsible for the processing leads the work, but several perspectives are needed. The data protection officer advises and reviews, the business describes the purpose, and those technically responsible explain how the data is actually handled. Sometimes the views of the data subjects themselves should be weighed in too. The point is that the assessment doesn't become a legal desk exercise but reflects how the service actually works.

How does a DPIA influence design decisions in a project?

A DPIA done early becomes a design tool. It can show that you should collect less data, anonymize or pseudonymize, shorten the retention period, or tighten permissions – choices that are easy to make on the drawing board but expensive to rebuild later. If the assessment happens only after the system is built, it easily becomes a formality that confirms problems instead of preventing them.