DPIA Best Practices and Automation: Running Data Protection Impact Assessments at Scale
When a DPIA is required, what Article 35 says it must contain, seven best practices from regulator guidance, and which DPIA steps can be automated.
DPIA automation screens every new processing activity, routes the ones that need an assessment to the right reviewers, and keeps the assessment linked to the data inventory, risks, controls and evidence. GDPR Article 35 sets the trigger and the four minimum contents; WP 248 rev.01 and the ICO add the criteria and the steps; the judgment on necessity, severity and residual risk stays with people.
- GDPR Article 35 requires a DPIA before processing likely to result in a high risk; WP 248 rev.01 gives nine criteria, and two usually mean a DPIA.
- Every DPIA needs the four elements in Article 35(7): description, necessity and proportionality, risks to individuals, and measures.
- Automate screening, pre-filling from the ROPA, routing, reminders, evidence capture and review triggers; keep necessity, severity and residual-risk decisions with people.
- Residual high risk means prior consultation with the supervisory authority under Article 36, which can take up to fourteen weeks.
DPIA automation means using workflow software to screen every new processing activity, route the ones that need a data protection impact assessment to the right reviewers, and keep each assessment linked to the data inventory, risks, controls and evidence it depends on. The judgment stays with people. The software removes the chasing, the copying between documents and the spreadsheet nobody can find at audit time.
Under Article 35 of the GDPR (Regulation (EU) 2016/679, applicable since 25 May 2018), a controller must carry out a DPIA before processing that is likely to result in a high risk to the rights and freedoms of natural persons. This article covers the legal floor, seven practices from the regulators' own guidance, and which steps a privacy team can automate without weakening the assessment.
When is a DPIA required?
A DPIA is required when processing, in particular with new technologies, is likely to result in a high risk to individuals, taking into account its nature, scope, context and purposes (Article 35(1)). Article 35(3) names three cases in particular: systematic and extensive evaluation based on automated processing, including profiling, with legal or similarly significant effects; large-scale processing of special categories of data under Article 9 or of criminal conviction data under Article 10; and systematic monitoring of a publicly accessible area on a large scale.
The Article 29 Working Party's Guidelines on Data Protection Impact Assessment (WP 248 rev.01, 2017) turn that test into nine criteria: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive data; large-scale processing; matching or combining datasets; vulnerable data subjects; innovative use of technology; and processing that prevents people from exercising a right or using a service. In most cases, the guidelines say, meeting two criteria requires a DPIA, and one can be enough.
In the United Kingdom, the ICO's guidance on when a DPIA is needed repeats the two-criteria rule of thumb and adds ten operation types of its own, including large-scale profiling, biometrics, genetic data, data matching, invisible processing and tracking. The ICO notes that the guidance is under review following the Data (Use and Access) Act.
What must a DPIA contain?
Article 35(7) sets four minimum elements: a systematic description of the processing and its purposes, including any legitimate interest pursued; an assessment of necessity and proportionality; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks, including safeguards and security measures.
Three further duties shape the process: seek the advice of the data protection officer where one is designated (Article 35(2)), seek the views of data subjects where appropriate (Article 35(9)), and review the assessment at least when the risk changes (Article 35(11)). If the assessment shows a high risk that the planned measures do not mitigate, Article 36 requires prior consultation with the supervisory authority, which has up to eight weeks to give written advice, extendable by six weeks. Article 83(4)(a) sets the fine ceiling for breaches of Articles 25 to 39, which include the DPIA duty, at EUR 10 million or 2 percent of total worldwide annual turnover, whichever is higher.
What are the best practices for a DPIA program?
These seven practices come from the GDPR text, WP 248 rev.01 and the ICO's step-by-step DPIA guidance.
- Screen everything, assess what qualifies. Put a short threshold questionnaire built on the nine criteria at project intake, vendor onboarding and AI use-case approval. Record the decision either way: the ICO expects a documented reason when you conclude that no DPIA is needed.
- Start before the design is fixed. Article 35(1) says prior to the processing. A DPIA opened after the contract is signed can only document risk, not reduce it. Make it a gate in the project method.
- Describe the processing from the record, not from memory. Purposes, data categories, recipients, transfers and retention periods already belong in the record of processing activities under Article 30. Pull them from that record so the DPIA and the ROPA never disagree.
- Treat necessity and proportionality as its own step. The ICO asks whether the processing achieves its purpose and whether a less intrusive option would do the same. Answer both in writing before scoring any risk.
- Score risk to individuals, not to the organization. Rate the likelihood and severity of harm to the people whose data is processed. The NIST Privacy Framework Version 1.0 (January 2020) frames privacy risk the same way, as problems individuals can experience from data processing.
- Record the decision on every risk. At conclusion the ICO expects each risk marked eliminated, reduced or accepted, the residual risk, whether consultation is needed, the DPO's advice and the reasons for any departure from it.
- Review on a trigger, not only on a calendar. Article 35(11) requires a review at least when the risk changes; WP 248 rev.01 adds that a DPIA should be continuously reviewed and regularly re-assessed. A change to the vendor, the data categories or the purpose should reopen the assessment.
Which DPIA steps can be automated?
Automation earns its place where the work is repetitive and the rule is explicit. It does not replace the assessment of necessity, the judgment on severity or the decision to accept residual risk.
| DPIA step | What to automate | What stays with people |
|---|---|---|
| Threshold screening | Intake form that scores the nine criteria and opens a DPIA when two apply | The DPO's call on borderline cases |
| Describing the processing | Pre-filling purposes, data categories, recipients and retention from the ROPA | Confirming the description with the process owner |
| Consultation | Routing to Legal, Security, Risk and the DPO, with reminders | The advice itself and the views of data subjects |
| Risk assessment | Scoring scales, risk register link, lookup of existing controls | The likelihood and severity judgment |
| Mitigation | Tasks with owners and due dates, status rolled up to the assessment | Choosing the measures |
| Sign-off and evidence | Approval workflow, version history, evidence capture | The decision to proceed or consult the authority |
| Review | A trigger when the processing record, vendor or data categories change | The re-assessment itself |
Two parts of the process should never be automated away: the Article 36 decision on whether residual risk is high enough to consult the supervisory authority, and consultation with data subjects under Article 35(9), which is a conversation, not a form.
Key facts
- Legal basis: GDPR Article 35, applicable since 25 May 2018 (Article 99).
- Triggers: three cases in Article 35(3); nine criteria in WP 248 rev.01; two criteria usually mean a DPIA.
- Prior consultation: Article 36; written advice within eight weeks, extendable by six.
- Fine ceiling for Article 35 breaches: EUR 10 million or 2 percent of worldwide annual turnover (Article 83(4)(a)).
- California: the CPPA regulations adopted on 24 July 2025 and approved by the Office of Administrative Law on 22 September 2025 took effect on 1 January 2026 and require certain businesses to conduct risk assessments.
How does SmartSuite run DPIAs?
The Privacy Risk Management product runs PIAs and DPIAs through guided forms that record risks and regulatory requirements, with every assessment linked to the system and the vendor it concerns, risks rated on impact, likelihood and regulatory exposure, and controls assigned on the same record. The Privacy Management suite adds assessment templates aligned to GDPR, CCPA, HIPAA and FERPA, automated routing to Legal, Security and Risk owners, version control and evidence capture, and dashboards that show the DPIA backlog. No-code automations route assessments, approvals and remediation, so the screening, routing, reminders and review triggers in the table are configuration rather than custom code. Enterprise and Signature customers choose a United States or a European Union data center, as stated on the security page.
Related links
- GRC Knowledge Center, the parent library
- DPIA vs PIA vs privacy risk assessment
- How to connect DPIAs, AI reviews and vendor reviews
- How to track privacy issues from assessment to remediation
- What is a DPIA? (glossary)
- EU GDPR framework page
Where should you start?
Start with the threshold questionnaire: one intake form, scored against the nine criteria and attached to every project, vendor and AI request. Connect it to the data inventory next, so the description step is pre-filled, and add the review trigger last. A team that does those three things has automated the repetitive parts of the DPIA and kept the judgment where Article 35 puts it.
Reviewed by Jon Darbyshire, Chief Executive Officer, SmartSuite.
Linked Articles
Learn the difference between DPIAs, PIAs, and privacy risk assessments, and how Connected GRC links privacy reviews to data, vendors, AI, controls, evidence, and remediation.
Learn how to connect DPIAs, AI reviews, and vendor reviews into one GRC workflow that links data, vendors, AI use cases, controls, evidence, issues, and approvals.
Learn how to track privacy issues from DPIAs, PIAs, vendor reviews, AI reviews, incidents, and audits through remediation, evidence, validation, and dashboards.
Frequently Asked Questions
Answers to the questions readers ask most about this topic.
No. A DPIA is required when processing is likely to result in a high risk to individuals, and in particular for the three cases in GDPR Article 35(3). Screen every project against the nine WP 248 rev.01 criteria at intake; two criteria usually mean a DPIA is needed, and the ICO expects a documented reason when you decide one is not.
The GDPR leaves the sign-off role to the controller. The ICO's guidance expects the DPO's advice to be sought and recorded, the outcome signed off by the organization, and the reasons noted wherever the organization departs from the DPO's advice or from the views of the individuals consulted. Many teams give the sign-off to the process owner with the DPO as a required approver.
Article 35(11) requires a review at least when the risk represented by the processing changes, and WP 248 rev.01 recommends that a DPIA be continuously reviewed and regularly re-assessed. In practice, tie the review to triggers such as a change of vendor, data categories or purpose, and add a scheduled re-assessment for long-running processing.
No. Threshold screening, pre-filling the description from the record of processing activities, routing to reviewers, reminders, evidence capture and review triggers can all be automated. The assessment of necessity and proportionality, the likelihood and severity judgment on each risk, consultation with data subjects and the decision on residual risk stay with people.
Article 36 requires the controller to consult the supervisory authority before processing when the DPIA shows a high risk that the planned measures do not mitigate. The authority has up to eight weeks to give written advice, extendable by six weeks for complex processing, and may use its corrective powers. Processing should not start until the consultation concludes.
Put Connected GRC into action with SmartSuite
Map controls, collect evidence, run assessments, manage remediation, and report readiness - all from a single connected system.