How to Conduct a DPIA Step by Step: A Practical Guide for Privacy Teams
Running a Data Protection Impact Assessment shouldn't require reinventing the process every time. Whether you're conducting your first DPIA or trying to standardize assessments across 15 subsidiaries in different jurisdictions, this guide breaks the process into 7 clear phases, with practical decision points, stakeholder checklists, and the exact questions supervisory authorities expect you to answer.
Built for DPOs, compliance leads, and legal teams managing privacy across complex, multi-entity organizations.
Why Most DPIAs Fail, and What Supervisory Authorities Actually Look For
These three structural problems explain why even well-intentioned privacy teams produce DPIAs that wouldn't survive a supervisory authority's scrutiny.
Problem 01
The Ad Hoc Assessment Trap
Most organizations treat each DPIA as a one-off exercise. There is no repeatable framework, so every assessment starts from scratch. Quality varies wildly between assessors. Institutional knowledge disappears when the person who led the last assessment changes roles, and the next team inherits a blank page instead of a methodology.
Problem 02
The Multi-Entity Blind Spot
For organizations with subsidiaries, joint controllers, or operations across jurisdictions, the challenge multiplies. Different entities interpret the DPIA threshold differently. One subsidiary conducts assessments that would satisfy the Irish DPC but not the French CNIL. And no one at group level has visibility into which processing activities have been assessed, and which haven't.
Problem 03
The Documentation Gap That Costs Millions
Supervisory authorities don't just want to see that you did a DPIA. They want to see how you did it. They expect evidence of systematic methodology, stakeholder consultation, documented risk mitigation decisions, and ongoing review. A DPIA living in a Word document on someone's desktop fails this test every time.
The good news: a well-structured DPIA process isn't complicated. It just needs to be systematic. Here's the 7-phase approach we recommend, built from real-world experience managing assessments across dozens of entities and jurisdictions.
200+
Hours saved on ROPA management
Medtec redirected 200+ hours from manual ROPA tracking to ISO 27001 preparation, within their first year on Priverion.
60%
Lower total cost vs. legacy platforms
Based on Priverion's entity-based pricing compared to per-user, per-module pricing from OneTrust and similar enterprise tools for multi-subsidiary deployments.
3 mo.
Ahead of schedule on ISO 27001 certification
Medtec accelerated their ISO 27001 readiness by three months using Priverion's audit-ready evidence packages and automated documentation.
Why mid-market teams are switching from OneTrust to Priverion
OneTrust was built for Fortune 500 compliance programs with Fortune 500 budgets. If you're managing privacy across 5–50 entities and don't need ESG modules or cookie consent, here's what the comparison actually looks like.
The typical enterprise platform experience
Pricing that expands on you
Per-user, per-module pricing means your costs grow every time you onboard a new subsidiary or add a team member. Budget surprises at renewal become the norm, not the exception.
Complexity you didn't ask for
200+ integrations sound impressive until you realize most are shallow connectors requiring constant maintenance. Meanwhile, the UX demands a dedicated admin team just to keep things running.
US-hosted data infrastructure
In a post-Schrems II landscape, hosting compliance data on US infrastructure creates exactly the kind of cross-border transfer risk your privacy program is supposed to mitigate.
Months to get operational
Multi-month implementation projects with dedicated consultants before you see any compliance output. Time-to-value is measured in quarters, not weeks.
The Priverion experience
Predictable pricing, no expansion traps
Priced by number of companies and organizational size, not per-user or per-module. Add team members across subsidiaries without watching the invoice climb. Your CFO will appreciate the predictability.
All-in-one platform, simpler UX
ROPA, DPIA, vendor assessments, DSR handling, incident management, and AI Act compliance in one platform. Deep integrations with HR, procurement, and IT asset management, the systems that actually matter for privacy workflows.
Swiss-built, Swiss-hosted, European data residency
All data processing within Swiss infrastructure. Not a data residency checkbox on a settings page. Our entire platform is engineered for European data sovereignty from the ground up. Your compliance data never leaves a jurisdiction you trust.
Operational in weeks, not months
Aircraft manufacturer went from onboarding to fully automated ROPA recertification across multiple subsidiaries. Medtec saved 200+ hours in ISO 27001 preparation alone. You'll be generating compliance output before a legacy vendor finishes scoping the project.
Aircraft manufacturer: first 6 months. Medtec: ISO 27001 prep cycle.
How to Conduct a DPIA: The Complete 7-Phase Guide
Each phase includes the key questions to answer, the stakeholders to involve, and the documentation supervisory authorities expect. This framework works whether you're assessing a single processing activity or rolling out a standardized DPIA program across 50 entities.
Phase 1
Screening & Threshold Analysis
Before investing hours in a full assessment, you need to determine whether a DPIA is actually required. Under GDPR Article 35, a DPIA is mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons." But that language is deliberately broad, and different supervisory authorities interpret it differently.
Key questions to answer:
- Does the processing involve systematic, extensive profiling with significant effects?
- Does it involve large-scale processing of special category data (Article 9) or criminal conviction data (Article 10)?
- Does it involve systematic monitoring of a publicly accessible area on a large scale?
- Does the processing appear on your local supervisory authority's mandatory DPIA list?
- Does the processing combine two or more criteria from the EDPB's guidelines (WP248)?
A common mistake: treating screening as a binary gate. Even when a DPIA isn't strictly required, conducting a lightweight assessment demonstrates accountability under Article 5(2) and gives you documented evidence that you considered the risks.
Multi-Entity Consideration
If your subsidiaries operate in different EU member states, each may have different mandatory DPIA lists. A centralized screening methodology needs to account for the strictest applicable threshold; otherwise you'll have entities inadvertently skipping required assessments. Priverion's AI-assisted screening maps processing activities against jurisdiction-specific DPIA triggers automatically.
Phase 2
Describe the Processing
This phase is where most DPIAs go wrong, not because teams skip it, but because they describe the processing at the wrong level of detail. Supervisory authorities expect a systematic description covering the nature, scope, context, and purposes of the processing.
Document these elements:
- What personal data is collected, and from which data subjects?
- What is the legal basis for processing (and how was it determined)?
- How does data flow through your systems, from collection to storage to deletion?
- Which third parties or processors receive the data?
- What are the retention periods, and how are they enforced?
- Are there cross-border transfers? If so, what transfer mechanisms are in place?
The critical detail here is data flow mapping. You need to trace personal data from the point of collection through every system, processor, and jurisdiction it touches. In group structures, this often reveals data flows that no single entity was fully aware of, including data shared between subsidiaries, centralized HR systems processing employee data across borders, or group-level analytics platforms aggregating customer data from multiple markets.
Practical Tip
Link your DPIA processing descriptions directly to your ROPA entries. If your ROPA is well-maintained, much of this documentation already exists. Priverion connects DPIA assessments to your existing ROPA records, so you're building on documented processing activities rather than describing them from scratch each time.
Phase 3
Assess Necessity & Proportionality
This is the phase supervisory authorities scrutinize most carefully. It's not enough to show that processing has a legal basis. You need to demonstrate that the processing is necessary for the stated purpose and proportionate to the privacy intrusion.
The necessity test asks:
- Could the same purpose be achieved with less data or less intrusive processing?
- Is every data element collected actually required for the stated purpose?
- Are retention periods the minimum necessary?
- Have you applied data minimization and purpose limitation effectively?
The proportionality test asks:
- Do the benefits of the processing justify the privacy impact on data subjects?
- Have you considered the reasonable expectations of data subjects?
- Are there adequate safeguards to balance the intrusion?
Document your reasoning explicitly. A common audit finding is DPIAs that state a legal basis but don't explain why the specific processing activities are necessary and proportionate. The CNIL has specifically flagged this as a frequent deficiency in their DPIA reviews.
Phase 4
Identify & Assess Risks
Risk assessment is the core of any DPIA. GDPR requires you to assess risks to the rights and freedoms of data subjects, not risks to your organization. This is a critical distinction that many teams get wrong, defaulting to information security risk frameworks that focus on organizational impact rather than impact on individuals.
Assess risks across three dimensions:
- Confidentiality risks: unauthorized access to personal data (e.g., data breach, insider threat)
- Integrity risks: unauthorized modification of personal data (e.g., data corruption, inaccurate profiling decisions)
- Availability risks: loss of access to personal data (e.g., ransomware, system failure preventing data subject access)
For each risk, document:
- The source of the risk (threat actor or system vulnerability)
- The likelihood of the risk materializing (with reasoning, not just a number)
- The severity of impact on data subjects if it occurs
- The overall risk level (before and after mitigation measures)
AI-Assisted Risk Scoring
Priverion's AI-assisted risk scoring analyzes the processing description and suggests applicable risks based on similar assessments across your organization, while keeping the final risk determination with your privacy team. This is especially valuable in group structures where one subsidiary's DPIA can inform risk identification for similar processing at another entity. AI assists, humans decide.
Phase 5
Define Mitigation Measures
For every risk identified above the acceptable threshold, you need to define specific, implementable mitigation measures. The EDPB emphasizes that measures should address the root cause of the risk, not just reduce its symptoms.
Categories of mitigation measures:
- Technical measures: encryption, pseudonymization, access controls, automated deletion, audit logging
- Organizational measures: staff training, access policies, data protection agreements, incident response procedures
- Legal measures: contractual clauses with processors, updated privacy notices, consent mechanisms where applicable
- Governance measures: regular audits, DPO oversight, recertification schedules
For each measure, document:
- Which specific risk(s) it addresses
- Who is responsible for implementation
- The implementation timeline
- How effectiveness will be verified
- The residual risk level after implementation
If residual risk remains high after all feasible mitigation measures, GDPR Article 36 requires you to consult with your supervisory authority before proceeding with the processing. Document this decision point clearly. It's one of the most scrutinized elements in regulatory audits.
Phase 6
Stakeholder Consultation & Sign-off
A DPIA is not a solo exercise for the DPO. GDPR Article 35(2) explicitly requires the controller to seek the DPO's advice, and Article 35(9) requires seeking the views of data subjects "where appropriate." Beyond regulatory requirements, effective DPIAs require input from the people who understand the processing best.
Stakeholders to involve:
- Data Protection Officer: mandatory consultation, documented advice
- Business process owner: detailed knowledge of how data is actually processed (vs. how it's supposed to be processed)
- IT/Security team: technical risk assessment and feasibility of technical measures
- Legal team: legal basis validation, cross-border transfer assessment, regulatory interpretation
- Data subjects or their representatives: where the processing significantly affects them (e.g., employee monitoring, patient data systems)
Document for each consultation:
- Who was consulted and when
- What input or advice they provided
- Whether their recommendations were accepted or rejected, and the reasoning for either
- Final sign-off from the data controller
Multi-Entity Consideration
In group structures, the sign-off process often involves local entity DPOs, a group-level privacy officer, and potentially local legal counsel in each jurisdiction. Without a centralized workflow, this becomes a months-long email chase. Priverion's workflow engine routes DPIA reviews to the right stakeholders across every entity with built-in escalation and deadline tracking.
Phase 7
Ongoing Review & Recertification
A DPIA is a living document, not a one-time compliance exercise. GDPR Article 35(11) requires controllers to carry out reviews "at least when there is a change in the risk represented by processing operations." In practice, this means your DPIAs need a recertification process, not just a reminder to "review annually."
Triggers for DPIA review:
- Changes to the processing scope, purpose, or technology
- New data categories or data subjects added
- Changes to third-party processors or sub
