Data Protection Impact Assessment (DPIA): GDPR Guide

A Data Protection Impact Assessment is a structured process for identifying and minimizing privacy risks before they materialize. Article 35 of the GDPR makes DPIAs mandatory for processing that is “likely to result in a high risk to the rights and freedoms of natural persons.” But even when not legally required, a DPIA is one of the most practical tools you have for building privacy into your product from the ground up.

For SaaS companies, the trigger for a DPIA often arrives with a new feature launch, a new data integration, or a shift in how you use existing data. The product team wants to add behavioral analytics. The machine learning team wants to train a model on user data. The sales team wants to enrich lead profiles with third-party data. Each of these scenarios may require a DPIA — and the assessment should happen during planning, not after launch.

When Is a DPIA Mandatory?

The General Rule

Article 35(1) requires a DPIA when processing is “likely to result in a high risk” to individuals. The regulation provides specific examples and criteria, but the fundamental question is: does this processing create a meaningful chance of harming someone’s privacy, autonomy, or rights?

Mandatory Scenarios — Article 35(3)

The GDPR explicitly requires a DPIA in three situations:

Systematic and extensive profiling with significant effects. If you make automated assessments about individuals that produce legal or similarly significant effects — automated credit decisions, algorithmic eligibility determinations, risk scoring that affects service access — a DPIA is mandatory.

Large-scale processing of special category data. Processing health data, biometric data, genetic data, data about racial or ethnic origin, political opinions, religious beliefs, trade union membership, or sexual orientation at scale triggers a mandatory DPIA.

Systematic monitoring of publicly accessible areas at large scale. This primarily applies to CCTV and surveillance, but could extend to SaaS scenarios involving public-facing monitoring tools.

The Article 29 Working Party Criteria

The Article 29 Working Party (now the European Data Protection Board) identified nine criteria that indicate high-risk processing. If your processing meets two or more of these criteria, a DPIA is generally required:

1. Evaluation or scoring — Profiling, predicting performance, behavior, preferences, or interests
2. Automated decision-making with legal or significant effect — Processing that results in decisions that meaningfully affect individuals
3. Systematic monitoring — Observing, tracking, or controlling data subjects systematically
4. Sensitive data or data of a highly personal nature — Special category data, financial data, location data, communication content
5. Large-scale processing — Affecting a large number of data subjects or involving a large volume of data
6. Matching or combining datasets — Combining data from multiple sources in ways data subjects wouldn’t reasonably expect
7. Data concerning vulnerable individuals — Processing data about children, employees, patients, elderly individuals
8. Innovative use of technology — Applying new technological solutions (AI, IoT, biometrics) where the privacy impact is not yet well understood
9. Processing that prevents data subjects from exercising rights — Blocking access to a service or a contract based on data processing

SaaS-Specific Triggers

For a typical SaaS company, common triggers for a DPIA include:

• Launching an AI or machine learning feature that processes user data
• Implementing behavioral analytics that tracks individual user journeys
• Adding automated fraud detection or risk scoring
• Integrating third-party data enrichment into user profiles
• Expanding to process health, financial, or children’s data
• Deploying biometric authentication
• Building features that involve cross-border data processing at new scale
• Introducing location tracking or geofencing capabilities

National DPA Lists

Each EU member state’s Data Protection Authority publishes a list of processing operations that require a DPIA in their jurisdiction. These lists add country-specific requirements on top of the GDPR’s general criteria. Check the list published by the DPA where your processing takes place.

How to Conduct a DPIA: Step by Step

Step 1: Describe the Processing

Start with a clear, complete description of the proposed processing:

What data is involved? List every category of personal data: names, email addresses, behavioral data, payment information, device identifiers, location data, user-generated content.

Who are the data subjects? Customers, end-users, employees, website visitors, minors, vulnerable individuals.

What is the purpose? Be specific. “Improve the product” is not a purpose description. “Analyze individual user interaction patterns to identify usability bottlenecks and prioritize feature development” is.

What is the scope? How many data subjects are affected? How much data is processed? Over what geographic area? For how long?

What technology is used? Describe the systems, algorithms, and third-party services involved. If machine learning is used, describe the model type, training data sources, and decision logic.

Who has access? Internal teams, processors, sub-processors, partner organizations.

What is the data flow? Trace data from collection through storage, processing, sharing, and eventual deletion. Identify every system the data passes through and every border it crosses.

Step 2: Assess Necessity and Proportionality

Before evaluating risks, confirm that the processing is necessary and proportionate:

Is the processing necessary for its stated purpose? Could you achieve the same goal with less data or less invasive processing? The data minimization principle requires that you don’t process more data than needed.

What is the lawful basis? Identify which of the six lawful bases applies and verify that it’s appropriate for this type of processing.

Is the data accurate and kept up to date? Inaccurate data in automated decision-making can lead to unjust outcomes.

What are the retention periods? How long will data from this processing be kept? Is the period justified by the purpose?

How are data subject rights supported? Can individuals access, correct, or delete their data? Can they object to the processing? If the processing involves automated decision-making, can they request human intervention?

Step 3: Identify and Assess Risks

For each risk, evaluate:

• Likelihood: How probable is it that this risk will materialize? (Remote, possible, likely, almost certain)
• Severity: If the risk materializes, how significant is the impact on data subjects? (Minimal, limited, significant, maximum)

Common risk categories for SaaS processing:

Unauthorized access. Could a breach or misconfiguration expose the processed data? What would the impact be — embarrassment, financial loss, identity theft, discrimination?

Function creep. Could the data collected for one purpose be repurposed for something the data subjects didn’t expect? Product analytics data used for individual performance monitoring, for example.

Inaccuracy and bias. If the processing involves automated decisions, could inaccurate data or biased algorithms lead to unfair outcomes?

Excessive data collection. Are you collecting more data than the purpose requires? Could the same goal be achieved with aggregated or anonymized data?

Lack of transparency. Do data subjects understand what’s happening with their data? Can they meaningfully exercise their rights?

Vendor risk. If processors are involved, what risks do their security practices, sub-processors, and data locations introduce?

Cross-border risk. If data is transferred internationally, are the transfer mechanisms adequate? What happens if a transfer mechanism is invalidated?

Step 4: Identify Mitigation Measures

For each identified risk, document specific measures to reduce the risk to an acceptable level:

Technical measures:

• Encryption at rest and in transit
• Pseudonymization or anonymization
• Access controls and role-based permissions
• Audit logging
• Automated data deletion at retention period expiry
• Data minimization in collection and storage

Organizational measures:

• Staff training on data protection
• Clear policies and procedures
• Regular reviews and audits
• Incident response plans
• Vendor due diligence

Contractual measures:

• Data Processing Agreements with all processors
• Confidentiality obligations
• Sub-processor controls

Design measures:

• Privacy by design (building privacy protections into the architecture)
• Privacy by default (ensuring the most privacy-protective settings are the default)
• User controls (giving data subjects meaningful choices)

Step 5: Document the Assessment

Article 35(7) specifies the minimum content of a DPIA:

1. A systematic description of the processing and its purposes, including the legitimate interest pursued (if applicable)
2. An assessment of the necessity and proportionality of the processing
3. An assessment of the risks to data subjects’ rights and freedoms
4. The measures envisaged to address the risks

Beyond the minimum, document:

• The date of the assessment and who conducted it
• The DPO’s advice (if you have a DPO)
• The stakeholders consulted (product, engineering, legal, security)
• The decision (proceed as planned, proceed with modifications, don’t proceed)
• The review schedule

Step 6: Consult Your DPO

If you have a Data Protection Officer, Article 35(2) requires you to seek their advice when conducting a DPIA. The DPO’s role is advisory — they don’t approve or reject the DPIA, but their assessment should be documented and taken seriously.

Step 7: Prior Consultation (If Needed)

If your DPIA identifies high risks that you cannot mitigate to an acceptable level through the measures you’ve identified, Article 36 requires you to consult your supervisory authority before proceeding. This is called “prior consultation” and is relatively rare — it signals that the processing is inherently high-risk and the DPA should weigh in before you proceed.

DPIA Template for SaaS Companies

Here’s a practical structure for documenting a DPIA:

Section 1: Processing Overview

• Processing name/description
• Business owner and project lead
• Date of assessment
• Review date

Section 2: Processing Details

• Purpose and scope
• Categories of data subjects
• Categories of personal data
• Data sources
• Data flows (diagram)
• Technology and systems
• Processors and sub-processors
• International transfers
• Retention periods

Section 3: Necessity and Proportionality

• Lawful basis and justification
• Data minimization assessment
• Purpose limitation assessment
• Data quality measures
• Data subject rights mechanisms

Section 4: Risk Assessment

• Risk register (risk description, likelihood, severity, overall risk level)
• Grouped by: confidentiality, integrity, availability, rights and freedoms

Section 5: Mitigation Measures

• For each risk: measure, responsible party, implementation timeline, residual risk

Section 6: Conclusions and Decision

• Overall risk level after mitigation
• Decision (proceed / proceed with conditions / don’t proceed)
• DPO advice
• Approval sign-off

Section 7: Review Schedule

• Review triggers (new features, new data types, incident, regulatory change)
• Scheduled review dates

How GRCTrail Supports DPIAs

GRCTrail integrates DPIAs into your broader risk management and compliance program:

Structured DPIA workflow. Follow a guided process from processing description through risk assessment to decision, ensuring no required elements are missed.

Connected to your ROPA. Link DPIA assessments to the relevant processing activities in your Record of Processing Activities. When processing changes, the linked DPIA is flagged for review.

Risk register. Track identified risks, their mitigations, and residual risk levels over time. Demonstrate to supervisory authorities that you actively manage privacy risks, not just document them.

Audit trail. Every DPIA action — creation, review, update, approval — is timestamped and attributed. Your accountability evidence is built automatically.

Streamline your DPIA process →

Related Guides

• GDPR Compliance Checklist — The full compliance framework
• Data Breach Notification — When risks become incidents
• Records of Processing Activities (ROPA) — Documenting your processing
• The Six Lawful Bases — Legal grounds for processing

Get started with GRCTrail →