The Data Protection Impact Assessment (DPIA) is one of the most important mechanisms under the GDPR, enabling organizations to proactively identify and minimize risks to the rights of individuals whose data is being processed. Although this obligation has been in effect since May 2018, many organizations still make serious mistakes in its execution — or skip it entirely. In this comprehensive guide, we explain what a DPIA is, when it is required, how to conduct one step by step, and what pitfalls to avoid.
What Is a DPIA and Why Does It Matter?
A DPIA is a formal, documented process for assessing the impact of planned personal data processing operations on the rights and freedoms of natural persons. It was introduced in Article 35 of the GDPR (General Data Protection Regulation) and constitutes one of the key tools for implementing the principle of privacy by design — data protection by design and by default.
The primary purpose of a DPIA is not to protect the organization from fines (though that is an important side effect), but to protect the individuals whose data is being processed. A DPIA forces the data controller to think systematically about how planned processing will affect the privacy and other fundamental rights of individuals.
DPIA in the European Context
At the European level, the Article 29 Working Party (now the European Data Protection Board — EDPB) issued guidelines on DPIAs in document WP 248 rev.01. These guidelines identify nine criteria, of which meeting at least two indicates the need for a DPIA:
- Evaluation or scoring, including profiling and predicting
- Automated decision-making with significant legal effects
- Systematic monitoring
- Processing of sensitive data or data of a highly personal nature
- Large-scale data processing
- Matching or combining datasets
- Data concerning vulnerable individuals (e.g., employees, children, patients)
- Innovative use or application of new technological solutions
- Processing that in itself prevents individuals from exercising a right, using a service, or fulfilling a contract
Each EU member state’s supervisory authority has published its own list of processing operations requiring a DPIA, supplementing these criteria with country-specific considerations.
When Is a DPIA Mandatory? Three Categories Under Article 35(3)
Article 35(3) GDPR explicitly identifies three situations where a DPIA is required:
1. Systematic and Extensive Evaluation of Personal Aspects
This concerns automated processing, including profiling, based on which decisions are made that produce legal effects concerning a natural person or similarly significantly affect them. Typical examples include:
- Credit scoring systems in banks (creditworthiness assessment)
- Automated recruitment systems filtering CVs
- Algorithms setting insurance premiums based on customer profiles
- Fraud detection systems analyzing behavioral patterns
2. Large-Scale Processing of Special Categories of Data
This covers processing of sensitive data as defined in Article 9 GDPR (racial/ethnic data, political opinions, religious beliefs, genetic data, biometric data, health data, data concerning sex life) and data on criminal convictions (Article 10 GDPR) — when conducted on a large scale. Examples:
- Hospitals and clinic networks processing medical data of thousands of patients
- Large-scale biometric access control systems
- Research platforms collecting genetic data
- Employee health monitoring systems
3. Large-Scale Systematic Monitoring of Publicly Accessible Areas
This primarily concerns video surveillance (CCTV) systems, but also:
- Wi-Fi monitoring tracking movements in shopping centers
- Facial recognition systems in public spaces
- Vehicle movement monitoring (ANPR cameras)
- People counting systems with identification capabilities
EDPB Criteria for Determining DPIA Necessity
Beyond the three explicit categories in Article 35(3), the EDPB guidelines provide additional criteria to help determine whether a DPIA is needed. Organizations should consider the following factors:
| Criterion | Description | Example |
|---|---|---|
| Evaluation/scoring | Profiling using data from public registers | Insurance risk assessment systems |
| Automated decisions | Decisions with legal effects without human involvement | Automatic credit denial |
| Biometric data | Processing for identification purposes | Facial recognition systems |
| Genetic data | Processing genetic data (outside healthcare) | Commercial DNA testing |
| Location data | Large-scale location tracking | Fleet management applications |
| Employee monitoring | Systematic observation of employee activities | DLP systems, email monitoring |
| Sensitive data profiling | Combining sensitive data with profiling | Health-tech recommendation systems |
| Innovative technologies | New data processing technologies | IoT solutions collecting personal data |
| Cross-border transfer | Large-scale data transfers outside EEA | Global HR systems |
| Children’s data | Processing data of persons under 16 | Educational platforms, online games |
It is important to note that these criteria are not exhaustive — even if a processing operation is not explicitly listed, if it meets the criteria of Article 35(1), a DPIA is still required.
Step-by-Step DPIA Methodology
Conducting a DPIA is a multi-stage process. Below is a proven methodology based on EDPB guidelines (WP 248) and supervisory practice.
Step 1: Description of Processing Operations (Context)
At this stage, provide a detailed description of:
Nature of processing:
- What personal data is being processed (data categories)
- Who are the data subjects (employees, clients, users)
- How data is collected (directly from individuals, from third parties, from public registers)
- What operations are performed on data (collection, storage, analysis, profiling, transfer)
- Where data is stored (on-premise infrastructure, cloud, data centers)
- How long data is retained (retention periods)
- Who has access to data (roles, processors, recipients)
Scope of processing:
- Scale (number of data subjects; data volume)
- Geographic reach
- Frequency of processing
- Duration of processing
Context of processing:
- Relationship between controller and data subjects
- Degree of data subjects’ control over their data
- Data subjects’ expectations (is processing obvious to them?)
- Sensitivity of data in the given context
- Current state of technological knowledge
Purposes of processing:
- What business and legal purposes does processing serve
- Whether purposes are clearly defined and limited
Step 2: Assessment of Necessity and Proportionality
This stage focuses on evaluating whether processing is necessary and proportionate to the purposes pursued. The following questions must be addressed:
- Legal basis: What is the legal basis for processing (consent, contract, legitimate interest, legal obligation)?
- Necessity: Is processing truly necessary to achieve the purpose? Are there less invasive alternatives?
- Proportionality: Is the scope of collected data adequate for the purpose? Is more data collected than needed (data minimization principle)?
- Data quality: How is accuracy and currency of data ensured?
- Retention period: Is data stored no longer than necessary?
- Information: How are data subjects informed about processing?
- Data subject rights: How are rights exercised (access, rectification, erasure, portability, objection)?
- Processors: Do processor agreements ensure adequate protection?
- International transfer: If data is transferred outside the EEA — what safeguards are in place?
Step 3: Risk Identification and Assessment
This is the central element of a DPIA. Risk is assessed from the perspective of the data subject — not the organization. The following must be identified:
Risk sources:
- Internal (employees, processors, infrastructure)
- External (cyberattacks, surveillance, leaks)
- Accidental (human errors, technical failures)
Potential threatening events:
- Unauthorized access to data (confidentiality)
- Unauthorized modification of data (integrity)
- Loss of access to data (availability)
Impact on individuals:
- Physical (health or safety threats)
- Material (financial losses, loss of employment)
- Non-material (discrimination, reputational damage, psychological distress)
- Loss of control over personal data
- Restriction of rights
Risk assessment matrix:
| Likelihood \ Impact | Minimal | Limited | Significant | Maximum |
|---|---|---|---|---|
| Unlikely | Low | Low | Medium | Medium |
| Likely | Low | Medium | High | High |
| Very likely | Medium | High | High | Very high |
Step 4: Mitigation Measures
Based on identified risks, mitigation measures must be planned across several categories:
Organizational measures:
- Security policies and data protection procedures
- Employee data protection training
- Breach notification procedures
- DPO appointment with clearly defined competencies
- Regular audits and compliance reviews
- Processor agreements with appropriate clauses
Technical measures:
- Encryption of data at rest and in transit
- Role-based access control (RBAC)
- Multi-factor authentication (MFA)
- Pseudonymization and anonymization of data
- Access logging and monitoring
- Regular backups
- Network segmentation and privileged access management
Legal measures:
- Updated privacy notices
- Review and update of records of processing activities
- Verification of legal bases for processing
Step 5: Documentation and Approval
DPIA results must be documented. The DPIA document should contain at minimum:
- Description of processing — purposes, nature, scope, context
- Necessity and proportionality assessment — justification that processing is necessary
- Risk assessment — identified risks with likelihood and impact evaluation
- Mitigation measures — planned or implemented safeguards
- Residual risk — risk level after applying mitigation measures
- DPO opinion — Data Protection Officer’s position
- Controller’s decision — acceptance of residual risk or decision on further actions
If residual risk remains high after applying mitigation measures, the controller is obligated — under Article 36 GDPR — to consult the supervisory authority before commencing processing. This is known as prior consultation.
DPIA vs. General Risk Assessment — Key Differences
Many organizations confuse DPIA with general IT risk assessment or information security risk assessment (e.g., under ISO 27001). While these processes may complement each other, they have fundamental differences:
| Aspect | DPIA (GDPR) | IT Risk Assessment / ISO 27001 |
|---|---|---|
| Perspective | Data subject | Organization |
| Purpose | Protect rights and freedoms of individuals | Protect organizational information assets |
| Scope | Specific personal data processing operation | Entire IT systems or ISMS |
| Legal basis | Article 35 GDPR | ISO 27005, NIST SP 800-30 |
| Impact | Effect on individual (discrimination, material losses) | Effect on organization (downtime, financial losses) |
| Mandatory | Legally required in specific situations | Voluntary (unless required by standard/regulation) |
| Consultation | With DPO (mandatory) and supervisory authority (conditional) | With risk owners |
In practice, integrating both processes yields the best results — IT risk assessment data can feed into the DPIA, and DPIA results can influence IT risk management priorities.
The Role of the DPO in the DPIA Process
The Data Protection Officer (DPO) serves an advisory, not executive, role in the DPIA process. Under Article 35(2) GDPR, the controller seeks the DPO’s advice when carrying out a DPIA.
DPO responsibilities in the DPIA process include:
- Advisory — whether a DPIA is required for a given processing operation
- Methodology — advice on the methodology for conducting the DPIA
- Review — assessment of whether the DPIA was conducted properly
- Mitigation measures — advice on selecting appropriate safeguards
- Monitoring — ongoing monitoring of DPIA implementation and updates
- Authority consultation — support in any prior consultation with the supervisory authority
Important: The DPO is not responsible for conducting the DPIA — that is the controller’s obligation. The DPO is not liable for the DPIA’s content, but their opinion should be documented. If the controller does not follow the DPO’s recommendations, this should be recorded along with justification.
Common Mistakes in Conducting DPIAs
Based on experience from GDPR audits and DPIA documentation reviews, we identify the most common mistakes organizations make:
1. Conducting the DPIA After System Implementation
A DPIA should be conducted before processing begins — it is a design tool (privacy by design), not a validation tool. Conducting a DPIA post factum does not meet Article 35 requirements and drastically limits the ability to genuinely influence the design of processing.
2. Assessing Risk from the Organization’s Perspective
The most common substantive error. Organizations assess the risk of data loss from the perspective of their own financial or reputational losses, instead of evaluating the impact on natural persons. A DPIA must answer the question: “What will happen to John Smith if his data leaks?” — not “What will happen to our company?“
3. Overly Generic Description of Processing
A description limited to “we process customer data in a CRM system” is insufficient. A DPIA requires a detailed description: what specific data, from how many individuals, for what purpose, who has access, what operations are performed, where data is stored, for how long, and to whom it is disclosed.
4. Failure to Consult the DPO
Article 35(2) GDPR explicitly requires seeking the DPO’s advice. Failure to do so is a formal regulatory violation. The DPO’s opinion should be documented and attached to the DPIA documentation.
5. Treating the DPIA as a One-Time Exercise
A DPIA is not a one-time document. It should be reviewed and updated whenever there is a significant change in processing and periodically — at least once a year. Technology changes, new processors, expanded data scope — all require DPIA updates.
6. Lack of Concrete Mitigation Measures
Some DPIAs end at risk identification without specifying concrete mitigation measures or with vague statements like “appropriate safeguards will be implemented.” A DPIA must contain specific, measurable actions with deadlines and responsible persons.
7. Ignoring Residual Risk
After applying mitigation measures, the risk level must be reassessed (residual risk). If it remains high, the controller must consult the supervisory authority — many organizations skip this assessment or artificially understate the residual risk level.
Real-World Scenarios Requiring a DPIA
Below are typical scenarios where a DPIA is essential, with justification:
Scenario 1: Biometric Access Control System Deployment
A manufacturing company plans to implement fingerprint readers for time tracking and room access control. A DPIA is required because:
- Biometric data is processed (Article 9 GDPR — special category)
- Processing concerns employees (individuals in a dependent relationship)
- The system operates systematically and continuously
Scenario 2: E-Learning Platform with Analytics
A training company deploys a platform that tracks participant progress, analyzes their behavior (time spent on materials, test results, learning patterns), and personalizes learning paths accordingly. A DPIA is required due to:
- User profiling (result scoring)
- Behavioral monitoring
- Potential career implications (e.g., results may be shared with the employer)
Scenario 3: Video Surveillance in an Office Building
A building owner installs 200 CCTV cameras with license plate recognition and motion detection. A DPIA is required because:
- Monitoring covers publicly accessible areas (parking lot, reception)
- Processing is systematic and large-scale
- ANPR processes personal data (license plates = identifying data)
Scenario 4: AI-Powered CV Analysis System
A recruitment firm deploys an AI tool that automatically analyzes CVs, evaluates candidates, and generates a ranking. A DPIA is absolutely required because:
- The system automatically makes decisions affecting individuals’ professional situation
- Profiling using ML algorithms is employed
- There is a risk of algorithmic discrimination
- Decisions may have a significant impact on individuals (denial of employment)
Scenario 5: IoT in Healthcare
A hospital deploys an IoT wristband system monitoring patients’ vital signs in real time, with automatic alerts and health deterioration prediction. A DPIA is required for multiple reasons:
- Health data (special category)
- Innovative technology (IoT + prediction)
- Vulnerable individuals (patients)
- Large-scale, continuous processing
- Potentially serious consequences of incorrect predictions
Enforcement and Fines — European Realities
Supervisory authorities across Europe actively enforce the DPIA obligation. Here are examples of fines:
Notable enforcement cases:
- H&M Germany (2020): EUR 35.3 million — employee monitoring without adequate DPIA
- Clearview AI Italy (2022): EUR 20 million — no DPIA for mass biometric data processing
- Criteo France (2023): EUR 40 million — user profiling without adequate impact assessment
- Polish DPA (Morele.net, 2019): PLN 2.83 million — insufficient risk analysis and technical safeguards
- Polish DPA (Surveyor General, 2020): PLN 100,000 — no DPIA before launching an application processing national ID data
EDPB statistics indicate that between 2018 and 2025, over EUR 4.5 billion in fines were imposed across the EU, with missing DPIAs being one of the most frequently cited violations in decisions imposing the highest penalties.
How to Document DPIA Results — Template
A properly documented DPIA should have a clear structure. Below is a recommended template:
1. Information Card
- Project/processing operation name
- Process owner (controller)
- DPIA date
- Document version
- Status (initial / approved / requires update)
2. Description of Processing
- Purpose of processing
- Legal basis
- Categories of personal data
- Categories of data subjects
- Data recipients
- Retention period
- Data flows (diagram)
- Supporting IT systems
3. Necessity and Proportionality Assessment
- Justification of necessity
- Proportionality analysis
- Data subject rights implementation
- Information mechanisms
4. Risk Assessment
- Identified threats (table)
- Likelihood and impact assessment
- Risk matrix
5. Mitigation Measures
- Technical measures (table: measure, status, deadline, responsible person)
- Organizational measures
- Legal measures
6. Residual Risk
- Reassessment of risk after applying measures
- Decision: accept risk / further action / consult supervisory authority
7. DPO Opinion
- DPO’s position
- Any reservations
- Recommendations
8. Approval
- Controller’s signature
- Approval date
- Review plan
Integrating DPIA with Other Organizational Processes
A DPIA should not operate in isolation. The best results are achieved when it is integrated with other processes:
- Project management: DPIA as a mandatory gate review element — every project processing personal data should undergo a DPIA screening at the initiation stage.
- Risk management: DPIA results should feed into the corporate risk register, and decisions on residual risk acceptance should be made at the appropriate management level.
- Change management: Any change in systems processing personal data should trigger a review of existing DPIAs for potential updates.
- Incident management: Security incidents involving DPIA-covered processes should result in a risk assessment review and update.
- Security audits: Regular audits should verify that DPIA mitigation measures have been implemented and are functioning effectively.
Tools Supporting DPIA
Several tools on the market support the DPIA process:
- Open-source tools: PIA Software (CNIL), DPIA Template (ICO) — free templates and tools from European supervisory authorities
- GRC platforms: OneTrust, TrustArc, BigID — comprehensive platforms with DPIA modules integrated with records of processing activities
- Custom tools: Many organizations build their own templates using spreadsheets or document management systems
Tool selection should depend on the organization’s scale and the number of DPIAs conducted. For smaller companies, a document template may suffice; for larger ones, a dedicated GRC platform is recommended.
Summary — DPIA as an Element of Data Protection Culture
A DPIA is not a bureaucratic obligation but a genuine tool for protecting the rights of natural persons and managing organizational risk. A properly conducted DPIA allows organizations to:
- Identify privacy threats before a breach occurs
- Implement adequate safeguards at the design stage
- Demonstrate accountability to the supervisory authority
- Build trust with clients and business partners
- Avoid costly administrative fines
The key to an effective DPIA is treating it as a living process — regularly updated, integrated with other organizational processes, and conducted with genuine concern for the rights of the individuals whose data we process.
Related Terms
- GDPR — the regulation in which DPIA is defined
- Data Protection — the broader legal and organizational context
- Risk Assessment — the methodology on which DPIA partially relies
- Risk Management — the corporate process integrating DPIA results
- Security Audit — verification of DPIA measure implementation
- Security Policy — one of the mitigation measures in DPIA
Learn More
- What Is GDPR — Data Protection in the EU — a complete GDPR guide for businesses
- Data Protection Challenges — practical aspects of organizational data protection
- Cybersecurity in the Company — Effective Data Protection Strategies — data protection strategies in a cybersecurity context
Explore Our Services
- Comprehensive GDPR Review and Advisory — professional GDPR compliance audit, including DPIA verification
- Data Protection Officer Outsourcing — an external DPO who will conduct and oversee DPIAs in your organization
- Security Policy Development — creating documentation supporting the DPIA process
Need expert support? nFlo team can help secure your organization:
