DPIA GDPR Guide: When and How to Carry Out an Impact Assessment
New technologies, new data sources and new ways of analysing people all bring new privacy risks. The GDPR expects organisations to spot those risks before processing starts, not after something goes wrong. The main tool for doing that is the data protection impact assessment, and understanding the DPIA GDPR rules is essential for any organisation launching new projects that involve personal data.
A DPIA helps you describe a processing operation, test whether it is necessary and proportionate, and identify measures to reduce risk to individuals. In some cases it is a legal requirement, and failing to carry one out can itself be an infringement.
This guide explains when a DPIA is mandatory under Article 35, the criteria regulators use to judge high risk, what a DPIA must contain, when you must consult your supervisory authority, and a practical step-by-step process.
What is a DPIA?
A data protection impact assessment is a structured process for assessing how a planned processing operation could affect the rights and freedoms of individuals, and how you will manage those risks. It is set out in Article 35 of the General Data Protection Regulation.
The obligation falls on the controller. Processors are expected to assist, and Article 28 requires processing agreements to include assistance with DPIAs and prior consultation. Where a data protection officer (DPO) has been designated, Article 35(2) requires the controller to seek the DPO’s advice when carrying out a DPIA.
A single DPIA can cover a set of similar processing operations that present similar high risks, which is useful when rolling out the same technology across several sites or products.
DPIA GDPR triggers: when an assessment is mandatory
Article 35(1) requires a DPIA where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, taking into account its nature, scope, context and purposes.
Article 35(3) then lists three cases where a DPIA is always required:
- a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect individuals;
- processing on a large scale of special categories of data under Article 9(1), or of personal data relating to criminal convictions and offences under Article 10;
- systematic monitoring of a publicly accessible area on a large scale.
This list is not exhaustive. Many other activities can be high risk, which is why regulators have published further criteria and lists.
The EDPB and WP29 criteria for high risk
The Article 29 Working Party’s guidelines on DPIAs (WP248 rev.01), endorsed by the European Data Protection Board (EDPB), set out nine criteria to consider:
- Evaluation or scoring, including profiling and predicting, such as credit scoring or behavioural analysis.
- Automated decision-making with legal or similarly significant effect.
- Systematic monitoring of individuals, including in publicly accessible areas.
- Sensitive data or data of a highly personal nature, such as special category data, criminal offence data, location or financial data.
- Data processed on a large scale, considering the number of people, volume of data, duration and geographical reach.
- Matching or combining datasets in ways individuals would not reasonably expect.
- Data concerning vulnerable data subjects, such as children, employees, patients or elderly people.
- Innovative use or application of new technological or organisational solutions.
- Processing that prevents individuals from exercising a right or using a service or contract.
As a rule of thumb, the guidelines say that in most cases processing meeting two of these criteria will require a DPIA. A single criterion can be enough in some situations. If you decide that processing meeting several criteria does not need a DPIA, document your reasoning.
National DPA lists
Under Article 35(4), each supervisory authority must publish a list of processing operations that require a DPIA. Article 35(5) allows authorities to publish a list of operations that do not. The EDPB reviewed the national lists through its consistency mechanism to promote a common approach.
These lists often name specific activities, such as large-scale employee monitoring, processing of biometric or genetic data, or tracking location. If you operate in several EU countries, check the list of each relevant authority, and of your lead supervisory authority in particular.
Changes on the horizon
The European Commission’s Digital Omnibus proposal of November 2025 would replace national lists with EU-wide lists and introduce a common DPIA template and methodology. Separately, the EDPB published a draft DPIA template for public consultation, which closed on 9 June 2026. As of mid-2026, the Omnibus changes are still proposals, so the current national lists remain the reference point.
What a DPIA must contain
Article 35(7) sets the minimum content. A DPIA must include:
- A systematic description of the envisaged processing operations and their purposes, including, where applicable, the legitimate interest pursued by the controller.
- An assessment of necessity and proportionality of the processing in relation to its purposes.
- An assessment of the risks to the rights and freedoms of data subjects.
- The measures envisaged to address the risks, including safeguards, security measures and mechanisms to protect personal data and demonstrate compliance.
Article 35(9) adds that, where appropriate, the controller should seek the views of data subjects or their representatives. Article 35(11) requires a review, where necessary, at least when the risk represented by the processing changes.
Prior consultation under Article 36
Sometimes a DPIA shows that high risk remains even after your planned measures. In that case, Article 36(1) requires you to consult the supervisory authority before processing begins.
When you consult, Article 36(3) requires you to provide:
- the respective responsibilities of the controller, any joint controllers and processors involved;
- the purposes and means of the intended processing;
- the measures and safeguards provided to protect individuals;
- the contact details of the DPO, where applicable;
- the DPIA itself; and
- any other information the authority requests.
Under Article 36(2), if the authority considers the processing would infringe the GDPR, it must give written advice within up to eight weeks of receiving the request. This can be extended by six weeks for complex processing, and the authority must tell you about any extension within one month. The clock can be paused while the authority waits for information it has requested.
Prior consultation should be the exception. In most cases, a well-run DPIA will identify measures that reduce the risk to an acceptable level.
How to carry out a DPIA step by step
- Screen the project. Use a short screening questionnaire based on Article 35(3), the nine criteria and your national DPA list to decide whether a full DPIA is needed. Record the outcome either way.
- Start early. Begin the DPIA at the design stage, before processing starts, so its findings can shape the project.
- Describe the processing. Capture the purposes, data categories, data subjects, systems, recipients, transfers and retention periods. Your record of processing activities is a good source.
- Consult stakeholders. Involve the DPO, IT security, the business owner, key processors and, where appropriate, data subjects or their representatives.
- Assess necessity and proportionality. Confirm the lawful basis, check data minimisation and retention, and consider how individuals will be informed and able to exercise their rights.
- Identify and assess risks. Consider risks to individuals, such as discrimination, loss of confidentiality, financial loss or loss of control over their data. Rate each by likelihood and severity.
- Identify mitigating measures. Define technical and organisational controls for each risk and evaluate the residual risk.
- Sign off and record decisions. Record the DPO’s advice, whether it was followed, and who approved the residual risk.
- Consult the authority if needed. If high residual risk remains, begin prior consultation under Article 36 before processing.
- Integrate and review. Feed agreed measures into the project plan and revisit the DPIA when the processing or its risks change.
Common DPIA mistakes
- Starting too late. A DPIA completed after launch cannot influence design and does not meet the requirement to assess before processing.
- Focusing only on organisational risk. A DPIA is about risks to individuals, not just to the business.
- Treating it as a security review. Security matters, but necessity, proportionality, fairness and transparency must be assessed too.
- Ignoring the DPO’s advice. If you decide not to follow it, record why.
- Never reviewing it. Processing evolves, and a DPIA should be kept under review.
How Enactia helps
Enactia is an AI-powered governance, risk and compliance (GRC) platform. It helps privacy teams run DPIAs in a consistent, auditable way.
- Structured DPIAs. The DPIA module supports screening, assessment, risk evaluation and sign-off in one workflow.
- Connected ROPA. The Record of Processing Activities (ROPA) module keeps processing details linked to the assessments that cover them.
- Risk and task follow-up. Enterprise risk management and ticketing and task management help you track mitigating measures to completion.
Frequently asked questions
Is a DPIA always required under GDPR?
No. It is required where processing is likely to result in a high risk to individuals, including the three cases in Article 35(3) and activities on your supervisory authority’s list. Many routine activities do not need one, but a screening record is good practice.
Who is responsible for carrying out a DPIA?
The controller. The DPO must be consulted where one is designated, and processors should assist, but accountability stays with the controller.
Do we have to publish our DPIA?
The GDPR does not require publication. The WP29 guidelines suggest publishing a summary can help build trust, but you must share the DPIA with the supervisory authority during prior consultation or on request.
What is the difference between a DPIA and a ROPA?
A ROPA records all your processing activities. A DPIA is a deeper assessment of specific high-risk processing. The ROPA often helps identify which activities need a DPIA.
What happens if we do not carry out a required DPIA?
Failing to carry out a required DPIA, or to consult the authority when needed, is an infringement. Under Article 83(4), fines can reach 10 million euros or 2% of worldwide annual turnover, whichever is higher.
Conclusion: build DPIAs into your projects
Getting the DPIA GDPR requirements right is less about paperwork and more about asking the right questions early. Screen new projects, assess high-risk processing thoroughly, document your decisions and review assessments as things change. That approach protects individuals and gives you clear evidence of accountability.
Want to see how Enactia can help you run consistent, well-documented DPIAs? Contact us or book a demo with our team.
