The GDPR’s DPIA Requirement: Identifying, Assessing, and Mitigating High-Risk Processing
A practical guide to GDPR Data Protection Impact Assessments (DPIAs), explaining when they are required, the nine high-risk criteria, how to assess and mitigate risks, conduct a DPIA, document decisions, and determine when prior consultation is required.
Key Points: (1) DPIAs are required for likely high-risk processing. Under Article 35 GDPR, controllers must conduct a DPIA where processing is likely to result in a high risk to individuals’ rights and freedoms. (2) Assess high risk early. The WP29/EDPB nine criteria provide a practical framework; as a rule of thumb, meeting two or more criteria generally indicates that a DPIA is likely required. (3) Start before processing begins. A DPIA should begin early enough to meaningfully influence the design of the project and the safeguards implemented. (4) Describe and justify the processing. Assess its nature, scope, context and purposes, as well as its necessity and proportionality. (5) Assess risks from the individual’s perspective. Identify potential impacts on rights and freedoms and evaluate both their likelihood and severity. (6) Identify and implement mitigation measures. Document the technical and organizational safeguards designed to reduce identified risks and consider less risky alternatives. (7) Consult relevant stakeholders. Seek the advice of the DPO, where designated, and, where appropriate, the views of data subjects or their representatives. (8) Document the analysis and decisions. A good DPIA should demonstrate what risks were identified, how they were addressed, what residual risks remain, and why those risks are acceptable. (9) Treat the DPIA as an ongoing process. Review and update it when the processing or the risks change; it is not a one-time compliance exercise. (10) Consult the Supervisory Authority when necessary. If high residual risks cannot be sufficiently mitigated, the controller must undertake prior consultation before beginning the processing.
European data protection law requires organizations to identify and address data protection risks before they materialize. This obligation forms part of the GDPR’s broader framework of data protection by design and by default, risk-based compliance, and accountability.
Under Article 25 GDPR, controllers must integrate appropriate technical and organizational safeguards into the design and operation of their processing activities. These safeguards must reflect the nature, scope, context, and purposes of the processing, as well as the likelihood and severity of the risks that the processing may create for individuals’ rights and freedoms. See: Data Protection by Design and by Default Under the GDPR: What Article 25 Requires
Controllers are expected to consider data protection when deciding how a processing activity will operate and throughout its lifecycle.
A Data Protection Impact Assessment (DPIA) is one of the GDPR’s most important tools for putting this risk-based approach into practice.
While data protection by design and by default applies broadly to the design and operation of processing activities, a DPIA provides a structured process for evaluating processing that is likely to result in a high risk to individuals’ rights and freedoms.
Under Article 35 GDPR, where a type of processing—particularly processing involving new technologies—is likely to result in a high risk, the controller must conduct a DPIA before the processing begins.
A DPIA therefore helps a controller:
- understand the proposed processing and its purposes;
- assess whether the processing is necessary and proportionate;
- identify risks to the rights and freedoms of individuals;
- determine the measures and safeguards needed to address those risks; and
- document the analysis as part of the controller’s accountability obligations.
The DPIA should not be viewed simply as a compliance form or checklist completed at the end of a project. Properly used, it is a decision-making and risk-management process that should influence the design of the processing itself.
This connection is important: Article 25 establishes the obligation to build data protection into processing, while Article 35 provides a formal risk-assessment mechanism for processing likely to present high risks. Together, these provisions help translate the GDPR’s principles of accountability and risk-based data protection into practical organizational processes.
A DPIA asks organizations to identify potential impacts on individuals early enough that the processing can still be redesigned, safeguards strengthened, unnecessary data eliminated, or—in some cases—the proposed processing reconsidered altogether.
A DPIA should begin early in the life of a project, before processing begins, parallel to the planning and development process.
NOTE: DPIAs conducted by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offenses or execution of criminal penalties are regulated by Article 27 of Directive (EU) 2016/680 and the requirements may vary according to member state law.
What Is a DPIA?
A DPIA is a structured tool for systematically and comprehensively assessing a processing activity in order to identify and reduce data protection risks. It is not limited to checking whether an organization technically complies with the GDPR. A DPIA should also consider the broader consequences that processing may have for the rights and freedoms of individuals, including the possibility of significant social or economic disadvantage.

The assessment focuses on the potential for harm arising from the processing. That harm may be physical, material, or non-material and may affect particular individuals, groups of individuals, or, in some circumstances, society more broadly. Determining the level of risk requires considering two elements together: how likely the harm is to occur and how serious its consequences could be.
When Is a DPIA Required?
Under Article 35 GDPR, a DPIA must be carried out before processing begins when the proposed processing is likely to result in a high risk to the rights and freedoms of individuals.
The GDPR specifically identifies three circumstances in which a DPIA is required:
- Systematic and extensive evaluation of individuals, including profiling, where decisions based on that evaluation produce legal effects or similarly significantly affect individuals;
- Large-scale processing of special categories of personal data or personal data relating to criminal convictions and offenses; or
- Systematic monitoring of a publicly accessible area on a large scale.
These examples are not exhaustive. Supervisory Authorities have adopted lists identifying additional types of processing that require a DPIA, as contemplated by Article 35(4) GDPR.
How Do You Determine Whether Processing Is “Likely to Result in a High Risk”?
European guidance provides a practical framework for making this determination. The Article 29 Working Party (WP29) originally developed—and the European Data Protection Board (EDPB) subsequently endorsed—guidelines on DPIAs and determining whether processing is “likely to result in a high risk.”
The Nine Criteria
The WP29 Guidelines identify nine criteria that controllers should consider when determining whether processing is likely to result in a high risk and therefore require a DPIA:
- Evaluation or scoring. Processing used to evaluate, score, profile, or predict aspects of an individual, such as their work performance, economic situation, health, preferences, interests, reliability, behavior, location, or movements. Examples include credit scoring, fraud screening, health-risk predictions, and behavioral or marketing profiles.
- Automated decision-making with legal or similarly significant effects. Processing used to make automated decisions that produce legal effects or otherwise significantly affect individuals, such as decisions that may exclude a person from an opportunity or result in discrimination.
- Systematic monitoring. Processing used to observe, monitor, or control individuals, including monitoring through networks or in publicly accessible spaces. This presents particular concerns where individuals may not know who is collecting their information, how it will be used, or may have little practical ability to avoid the monitoring.
- Sensitive or highly personal data. Processing involving special categories of personal data, criminal-conviction or offense data, or other information of a highly personal nature. The Guidelines extend this concept beyond Article 9 (special category data) and Article 10 (criminal convictions) data to information such as financial data, location data, private communications, personal documents, emails, diaries, and other intimate information where its use or misuse could significantly affect an individual.
- Large-scale processing. Processing involving personal data on a sufficiently large scale. Relevant factors include the number or proportion of individuals affected, the volume and variety of data, the duration or permanence of the processing, and its geographical extent.
- Matching or combining datasets. Combining personal data obtained from different processing activities or different controllers, particularly where the resulting use of the information would go beyond what individuals could reasonably expect.
- Data concerning vulnerable individuals. Processing involving people who may be less able to consent to, object to, or otherwise exercise control over the processing because of a power imbalance or particular vulnerability. Examples identified by WP29 include children, employees, patients, elderly persons, asylum seekers, and other individuals requiring special protection.
- Innovative uses or new technological or organizational solutions. Processing involving new technologies or novel uses of existing technologies where the privacy and social consequences may not yet be fully understood. The Guidelines give examples such as combining fingerprint and facial recognition technologies and certain Internet of Things (IoT) applications. The use of Artificial Intelligence (AI) should qualify as new technology for the purpose of this criteria (it was not mentioned in the guidelines because they predate the technological developments that lead to modern day AI).
- Processing that prevents individuals from exercising a right or accessing a service or contract. This includes processing used to allow, modify, or deny access to a service or entry into a contract. A common example is using credit-reference information to determine whether an individual will be offered a loan.
The guidelines identify nine criteria that may indicate high-risk processing. As a general rule, processing that meets two or more of these criteria is more likely to require a DPIA. However, this is not a mechanical test: depending on the circumstances, processing meeting only one criterion may still present a sufficiently high risk to require an assessment.
The “Two-Criteria” Rule of Thumb
Importantly, these nine criteria are indicators of high risk rather than a mechanical checklist. WP29 states that, in most cases, processing that meets two of the nine criteria should be considered likely to require a DPIA. As more criteria apply, the likelihood that the processing presents a high risk—and therefore requires a DPIA—increases.
However, two criteria are not an absolute threshold. Depending on the nature of the processing and the risks involved, a controller may determine that processing satisfying only one criterion is sufficiently high risk to require a DPIA. Conversely, if a controller concludes that processing meeting relevant criteria is nevertheless not likely to result in a high risk, the Guidelines state that the controller should justify and document that decision and include or record the DPO’s views.

The DPIA Process: From Initial Assessment to Ongoing Review
The DPIA process should be flexible and scalable and should demonstrate that the controller has assessed the risks associated with the processing, considered its necessity and proportionality, and identified appropriate measures to address those risks. A DPIA does not need to show that every risk has been eliminated; it should document any residual risks and assess whether they are acceptable.
DPIAs can identify problems early, strengthen compliance, reduce financial and reputational risks, demonstrate accountability, and help build trust.
Where a Data Protection Officer (DPO) has been appointed, the controller must seek the DPO’s advice. Where appropriate, the controller must also seek the views of data subjects or their representatives. A DPIA may cover a single processing activity or a group of similar processing operations presenting similar risks.
Importantly, a DPIA is not a one-time compliance exercise. Its findings should be incorporated into the organization’s processes, and the assessment should be reviewed as the processing or its risks change. Although publication is not required, publishing a DPIA or summary can demonstrate transparency and help build trust.
Finally, where the DPIA identifies a high residual risk that cannot be sufficiently reduced, the controller must consult the competent Supervisory Authority before beginning the processing.
The graphic below summarizes this lifecycle in nine practical steps, from determining whether a DPIA is needed through implementation and ongoing review.

Have You Written a Good DPIA? A Practical Quality Checklist
A good DPIA should provide a clear and documented explanation of the processing, why it is necessary, the risks it creates for individuals, and how those risks will be addressed. It should also provide evidence that the assessment has genuinely influenced the design and governance of the processing.
As a practical quality check, ask whether your DPIA:
- Explains why the DPIA is needed and clearly identifies the processing activity, its purposes, scope, and relevant timeline.
- Describes the processing clearly and systematically, using plain language and explaining technical terminology where necessary.
- Maps the data flows and participants, including the relationships among controllers, processors, data subjects, systems, organizations, and countries. Data-flow diagrams can be particularly useful.
- Addresses GDPR compliance, including the applicable lawful basis, relevant special-category conditions, compliance with the data protection principles, and how individuals' rights will be supported.
- Identifies risks to individuals' rights and freedoms and assesses both their likelihood and severity.
- Identifies appropriate mitigation measures and explains how each measure reduces the relevant risk.
- Considers less risky alternatives and documents why they were or were not selected.
- Documents consultation, including relevant stakeholder input and the advice and recommendations of the DPO, where applicable.
- Records the outcome and appropriate sign-off, together with relevant supporting documentation, such as privacy notices or consent materials.
- Establishes a review process, including when the DPIA will be revisited because of changes to the nature, scope, context, purposes, or risks of the processing.
In short, a good DPIA should clearly document the risks identified, the measures taken to address them, any residual risks, and why those risks are considered acceptable. If residual risks remain high and cannot be sufficiently mitigated, the controller must consult the competent Supervisory Authority before processing begins.
Additional Resources
Legal Authorities
- GDPR Articles 35 -Article 35 establishes the requirements for Data Protection Impact Assessments
- GDPR Article 36 — Article 36 governs prior consultation with the Supervisory Authority where high residual risks cannot be sufficiently mitigated.
- GDPR Recitals 74 - Responsibility and Liability of the Controller
- GDPR Recital 75 - Risks to the Rights and Freedoms of Natural Persons*
- GDPR Recital 77 - Risk Assessment Guidelines*
- GDPR Recital 84 - Risk Evaluation and Impact Assessment*
- GDPR Recital 89 - Elimination of the General Reporting Requirement*
- GDPR Recital 90 - Data Protection Impact Assessement*
- GDPR Recital 91 - Necessity of a Data Protection Impact Assessment*
- GDPR Recital 92 - Broader Data Protection Impact Assessment*
- GDPR Recital 93 - Data Protection Impact Assessment at Authorities*
- GDPR Recital 94 - Consultation of the Supervisory Authority*
- GDPR Recital 95 - Support by the Processor*
- GDPR Recital 96 — Consultation of the Supervisory Authority in the Course of a Legislative Process*
European Regulatory Guidance
Article 29 Working Party (WP29) — Guidelines on Data Protection Impact Assessment (DPIA) and Determining Whether Processing Is “Likely to Result in a High Risk” (WP248 rev.01) — The principal European guidance for determining when a DPIA is required and how it should be conducted. The Guidelines identify the nine criteria for high-risk processing discussed in this article and have been endorsed by the EDPB.
- CNIL — Guidelines on DPIAs — Guidance from the French Data Protection Authority on determining when and how to conduct a DPIA.
- CNIL — Open-Source PIA Software — A free tool, available in English, designed to assist organizations in carrying out and documenting privacy and data protection impact assessments.
- ICO — Data Protection Impact Assessments Guidance — Detailed practical guidance covering when DPIAs are required, how to conduct them, consultation, risk assessment, and ongoing review.
Related Concept: Privacy Impact Assessments (PIAs)
A Privacy Impact Assessment (PIA) is a broader process for identifying, assessing, and mitigating privacy risks associated with a particular product, service, program, or system. Although terminology and legal requirements vary by jurisdiction, PIAs are widely used as a privacy-risk-management tool.
PIAs in the US
In the United States, PIAs are required in certain circumstances in the federal public sector and are routinely published by agencies such as the U.S. Department of Homeland Security (DHS). They are also commonly used as a privacy best practice in the private sector. Examples of publicly available U.S. government PIAs include:
- DHS — Privacy Impact Assessment for the Systematic Alien Verification for Entitlements (SAVE) Program(2011).
- DHS — Privacy Impact Assessment for the Verification Information System Supporting Verification Programs (2007).
Additionally, privacy impact assessments or similar risk assessments are increasingly required under state comprehensive privacy laws, particularly for processing activities that present heightened risks to consumers, such as targeted advertising, profiling, processing sensitive data, or selling personal data. Although these assessments may be called data protection assessments rather than PIAs or DPIAs, they serve a similar function: identifying and evaluating risks to individuals and documenting safeguards designed to address those risks.
- See: Colorado Privacy Act Data Protection Assessments: Understanding the Requirements
- See: What Is a Risk Assessment Under the CCPA?
Further Reading
- Dr. Kuan Hon — “When to Conduct a DPIA Under GDPR: EDPB and the Consistency Mechanism at Work” — Discussion of the EDPB consistency mechanism and national Supervisory Authority lists identifying processing activities requiring DPIAs.
- Fieldfisher — National DPIA Blacklists — Comparative resource compiling national Supervisory Authority lists of processing operations subject to mandatory DPIAs.
