GDPR Data Protection Impact Assessment: Step-by-Step Guide

A Data Protection Impact Assessment (DPIA) is one of GDPR's most practical tools — yet it remains one of the most misunderstood. Many organizations treat it as a bureaucratic checkbox rather than what it actually is: a structured process for identifying and reducing privacy risks before they become incidents, fines, or headlines.

This guide walks you through DPIAs step by step, from determining when one is needed to producing a compliant assessment document.

When is a DPIA required?

GDPR Article 35(1) requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) then lists three cases where a DPIA is always mandatory:

Systematic and extensive profiling with significant effects — automated evaluation of personal aspects used to make decisions that produce legal effects or similarly significant effects. Examples include automated credit decisions, insurance risk scoring that sets the terms offered, and automated rejection of job applicants.

Large-scale processing of special category data — health records, biometric data, genetic data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation, or criminal offence data processed at scale. A hospital's patient record system, a genetic testing service, or a large-scale employee health monitoring programme would all trigger this criterion.

Systematic monitoring of publicly accessible areas — large-scale CCTV surveillance, Wi-Fi tracking in public spaces, or facial recognition systems deployed in public areas.

The nine criteria for "likely high risk"

Outside those three cases, you decide whether processing is likely to be high risk. The DPIA guidelines (WP248 rev.01, adopted by the Article 29 Working Party and endorsed by the EDPB) give nine criteria to check:

Criterion	What it covers (WP248 examples)
1. Evaluation or scoring	Profiling and predicting, for example a bank screening customers against a credit reference or fraud database, or a company building behavioural or marketing profiles from use of its website
2. Automated decisions with legal or similarly significant effect	Decisions that can lead to the exclusion of, or discrimination against, individuals. Processing with little or no effect on people does not count
3. Systematic monitoring	Observing or controlling people, including through networks, or monitoring a publicly accessible area
4. Sensitive or highly personal data	Article 9 and 10 data, plus data such as location, financial data, private communications and personal documents
5. Large scale	Judged by the number of people (or share of the population), the volume and range of data, how long the processing lasts and its geographic reach
6. Matching or combining datasets	Combining data from different operations or controllers in a way people would not reasonably expect
7. Vulnerable data subjects	Children, employees, patients, the elderly, asylum seekers, or anyone in an unequal position towards the controller
8. Innovative technology	New technological or organisational solutions, for example combining fingerprint and face recognition for access control, or some Internet of Things applications
9. Processing that blocks a right, service or contract	Processing that decides whether people get access to a service or a contract, for example a bank screening loan applicants against a credit database

Two criteria usually mean a DPIA. The guidelines say that in most cases processing that meets two criteria requires a DPIA, and that the more criteria it meets, the more likely it is to be high risk. In some cases one criterion is enough. If your processing meets criteria but you conclude it is not likely to be high risk, write down why and record the views of your DPO.

The guidelines give worked examples:

Processing	Criteria met	DPIA likely required?
A hospital processing its patients' genetic and health data	Sensitive data; vulnerable data subjects; large scale	Yes
A company systematically monitoring its employees' work stations and internet activity	Systematic monitoring; vulnerable data subjects	Yes
Gathering public social media data to generate profiles	Evaluation or scoring; large scale; matching or combining datasets; sensitive or highly personal data	Yes
An individual physician or lawyer processing patient or client data (recital 91)	Sensitive data; vulnerable data subjects	No
An online magazine sending a generic daily digest to its mailing list	Large scale	No
An e-commerce site showing adverts based on items viewed or bought on its own site	Evaluation or scoring (limited profiling)	No

When a DPIA is not required

WP248 lists the cases where you do not need one:

The processing is not likely to result in a high risk (Article 35(1)). Keep your screening as evidence.
The processing is very similar to processing you have already assessed. A single DPIA may cover a set of similar operations with similar high risks (Article 35(1)).
The processing is based on Article 6(1)(c) or (e), has a specific legal basis in EU or national law, and a DPIA was carried out when that law was made (Article 35(10)), unless the Member State requires one anyway.
The processing is on your authority's list of operations that need no DPIA (Article 35(5)), and stays strictly within that list's conditions.

Processing that has been running since before May 2018 still needs a DPIA if it is likely to be high risk and its risks have changed, for example because of new technology or a new purpose.

Each national data protection authority also publishes its own list of processing operations that always require a DPIA (Article 35(4)), and some publish lists of operations that don't (Article 35(5)). Check the list of the authority in each country where you operate: national lists often add cases such as employee monitoring or large-scale location tracking.

Check if you need a DPIA: Our free DPIA Helper starts with a screening step that checks your processing against all mandatory and EDPB criteria.

What a DPIA must contain

GDPR Article 35(7) specifies four minimum requirements:

1. A systematic description of the processing. What data is collected, from whom, how it is used, which systems are involved, who has access, and where the data goes. Include the purposes and legal basis. This is essentially a detailed data flow map for the specific processing activity.

2. An assessment of necessity and proportionality. Is this processing actually necessary to achieve the stated purpose? Could you achieve the same goal with less data, less intrusive methods, or shorter retention? If you are relying on consent, is it truly free and informed? If on legitimate interest, have you conducted a balancing test?

3. An assessment of risks to individuals. What could go wrong, and how would it affect the people whose data you process? Think beyond data breaches — risks include unauthorized access, purpose limitation violations, inaccurate data leading to wrong decisions, excessive collection, lack of transparency, discrimination, financial loss, reputational harm, and loss of autonomy.

4. Measures to address the risks. For each identified risk, what safeguards do you have in place or plan to implement? This includes technical measures (encryption, access control, pseudonymization), organizational measures (policies, training, audits), and contractual measures (DPAs with processors, data sharing agreements).

Step-by-step DPIA process

Step 1: Screen for DPIA requirement

Before investing time in a full DPIA, determine whether one is actually needed. Check the three Article 35(3) cases, your authority's list and the nine criteria above. If none applies, document your reasoning (the screening itself is evidence of good practice) and move on. If two or more criteria apply, or a mandatory case or list entry does, carry out a full DPIA.

Step 2: Describe the processing

Document the what, why, who, and how of the processing. Be specific — "we collect customer data" is not enough. Specify exactly which data fields, from which sources, through which systems, for which purposes, under which legal basis, with what retention period, and shared with which parties. Our Data Flow Mapping Tool can help you structure this information.

Step 3: Assess necessity and proportionality

Challenge your own processing. Ask hard questions: Do you really need all this data? Could you achieve the purpose with anonymized or aggregated data instead? Is your retention period the minimum necessary? Are you processing data for the purpose you told people about, or has scope crept? This is where DPIAs deliver the most practical value — they force you to justify your data practices.

Step 4: Identify and assess risks

For each potential risk, assess both the likelihood (how probable is this?) and the severity (how bad would it be for affected individuals?). Consider risks from the perspective of data subjects, not just your organization. A data breach that is a minor PR issue for you could be devastating for the individuals whose health records or financial data were exposed.

Use a fixed scale so that different people rate risks the same way. Many DPIAs use four levels for both severity and likelihood, as in the CNIL's PIA method:

Level	Severity for the people affected	Likelihood
1. Negligible	Minor inconvenience they will overcome easily (re-entering data, irritation)	Seems very unlikely to happen with the measures in place
2. Limited	Significant inconvenience they can overcome with some effort (extra costs, stress, denied access to a service)	Possible, but hard for the risk sources to exploit
3. Significant	Serious consequences they can overcome only with real difficulty (financial loss, damaged reputation, health effects)	Possible and fairly easy to exploit
4. Maximum	Serious or irreversible consequences (debt they cannot repay, lasting harm, loss of a job)	Easy to exploit, or seems likely to happen

Rate each risk twice: before your measures (inherent risk) and after them (residual risk). Severity is about the impact on people, so it rarely drops much; good measures mostly reduce likelihood. A residual risk that is still high in severity and likelihood (3 or 4 on both) is the signal for prior consultation in step 7.

Step 5: Identify and evaluate mitigation measures

For each risk, document what controls are already in place and what additional measures are needed. Common mitigation measures include encryption (at rest and in transit), pseudonymization, access controls (role-based, least privilege), data minimization (collect only what is necessary), automated deletion at end of retention, staff training, regular audits, incident response procedures, and DPAs with all processors.

Step 6: Consult the DPO

GDPR Article 35(2) requires the controller to seek the advice of the Data Protection Officer when carrying out a DPIA. If you have a DPO (mandatory for public bodies, large-scale monitoring, and large-scale special category processing), they must be consulted. The DPO reviews the DPIA and provides recommendations but does not need to conduct it personally.

Step 7: Document and decide

If the DPIA shows that risks can be sufficiently mitigated, document the DPIA and proceed with the processing (implementing all identified measures). If residual risks remain high despite mitigation, you must consult the supervisory authority under Article 36 before proceeding. The authority has up to 8 weeks to give written advice, which it can extend by a further 6 weeks for complex processing (Article 36(2)).

Worked example: employee device monitoring

A 300-person company wants to roll out endpoint monitoring software that logs which websites and applications employees use, to detect malware and data leaks. Screening finds two criteria, systematic monitoring and vulnerable data subjects (employees), so a DPIA is needed. This is one of WP248's own examples, and many national lists name employee monitoring explicitly.

The description and necessity steps lead to an early design change: the purpose is security, so the tool does not need to capture message content, keystrokes or screenshots. That single decision removes the most severe risks before the risk assessment starts. The remaining risks look like this:

Risk to employees	Before measures (severity / likelihood)	Measures	Residual (severity / likelihood)
Excessive monitoring: managers read private messages or browsing history	3 / 3	Monitor only security events and blocked categories, not content; no keystroke logging or screenshots; written policy on who may access logs and why	3 / 1
Use of monitoring data for performance decisions it was not collected for	3 / 3	Purpose limitation in the policy; access limited to the security team; any disciplinary use needs HR and DPO review	3 / 2
Employees not knowing what is monitored (lack of transparency)	2 / 4	Employee privacy notice, briefing at rollout, intranet page; works council or staff representatives consulted (Article 35(9))	2 / 1
Breach of the monitoring logs	3 / 2	Encryption, role-based access, access logging, 90-day retention with automated deletion	3 / 1

Outcome. No residual risk is high on both scales, so the company can proceed without prior consultation, after implementing the measures and recording the DPO's advice. The legal basis is legitimate interest (Article 6(1)(f)), supported by a documented legitimate interest assessment. National employment law may add rules, such as consulting a works council, so check those as well. The DPIA is reviewed in 12 months or earlier if the tool's features change.

DPIA best practices

Start early. A DPIA should be conducted before processing begins — not as an afterthought. Ideally, it is part of the project design phase, when changes are still cheap and easy.

Involve the right people. A DPIA is not a solo exercise for the DPO. Include the project team, IT security, legal, and business stakeholders who understand the processing from different angles.

Be honest about risks. The DPIA is an internal document — understating risks to make the assessment look better defeats its purpose. Regulators are far more critical of organizations that failed to identify obvious risks than those that identified risks and implemented reasonable mitigations.

Keep it alive. A DPIA is not a one-time document. Review and update it when the processing changes, when new risks emerge, when technology evolves, or when the regulatory landscape shifts. Note the review date and trigger conditions for re-assessment.

Consider data subject views. Article 35(9) requires you to seek the views of data subjects or their representatives "where appropriate". It is not needed for every DPIA, but for processing that significantly affects individuals (such as employee monitoring), consulting affected parties can improve both the DPIA and the processing design.

What happens if you skip the DPIA?

Failure to conduct a required DPIA is itself a GDPR violation, subject to fines of up to €10 million or 2% of annual turnover (Article 83(4)). A missing DPIA is also easy for an authority to establish: it asks for the document, and you either have it or you do not.

Beyond fines, skipping a DPIA means you may be processing data with unidentified and unmitigated risks. When those risks materialize as breaches or complaints, the absence of a DPIA becomes an aggravating factor in any enforcement action.

Common questions

Who is responsible for the DPIA: controller or processor?

The controller. Article 35(1) puts the duty on the controller, who must seek the DPO's advice. A processor must help, for example by giving information about its systems and security, and that duty belongs in the data processing agreement (Article 28(3)(f)). Our DPA checklist covers that clause.

Do I have to publish my DPIA?

No. The GDPR does not require publication, but the authority can ask for it at any time. WP248 encourages publishing at least a summary or the conclusion to build trust, especially for processing that affects the public. A summary can leave out security details and commercially sensitive information.

How is a DPIA different from an LIA or a TIA?

They answer different questions and are often done together. A DPIA asks whether processing is high risk for people and how to reduce that risk. A legitimate interest assessment asks whether you can rely on Article 6(1)(f) as the legal basis. A transfer impact assessment asks whether data sent outside the EEA under SCCs stays adequately protected in the destination country. A project that monitors staff using a US cloud tool may need all three.

Do AI tools need a DPIA?

Often. AI systems that process personal data frequently meet the "innovative technology" and "evaluation or scoring" criteria, and those that influence decisions about people may also meet "automated decisions". Under the EU AI Act, some deployers of high-risk AI systems must also carry out a fundamental rights impact assessment (Article 27 of the AI Act), which complements the DPIA rather than replacing it. See our guide on AI agents and the GDPR.

How long does a DPIA take?

For a well-understood processing activity at a small or medium-sized company, a few days of work spread over one or two weeks is typical, most of it spent gathering facts for the description. Complex or novel processing takes longer. Starting from an up-to-date record of processing activities saves the most time.