DPIA (Data Protection Impact Assessment): When Required and How to Conduct One

What is a Data Protection Impact Assessment?

The Data Protection Impact Assessment (DPIA) is a structured procedure for identifying, assessing, and mitigating the risks of a planned data processing activity to the data subjects. Art. 35 DSGVO (GDPR) mandates this procedure when processing is "likely to result in a high risk to the rights and freedoms of natural persons."

The crucial shift in perspective: A DPIA is not about the risks to your organization. It is about the risks to the people whose data you process. The focus is not on a potential fine, but on the question of whether an employee is being unjustifiably monitored, whether a customer could be discriminated against through profiling, or whether a data breach could have existential consequences for a data subject.

This shift in perspective is not a philosophical detail. It determines the entire assessment methodology: severity of harm and likelihood of occurrence are measured from the data subject's situation, not from your organization's situation.

When is a DPIA mandatory?

Art. 35(1) GDPR deliberately formulates the trigger broadly: "likely high risk." Paragraphs 3 and 4 specify this open-ended concept through three mechanisms.

The three examples from Art. 35(3)

The GDPR names three cases where a DPIA is typically required:

Systematic and extensive evaluation of personal aspects. This covers profiling activities where personal aspects are evaluated automatically and decisions are made that have legal effect or significantly affect the data subject. Examples: credit scoring, automated applicant pre-screening, employee performance evaluation by algorithms.

Extensive processing of special categories. When you process health data, biometric data, data on political opinion, trade union membership, or sexual orientation on a large scale, a DPIA is regularly required. "Large scale" is relative: a single family doctor processes health data but not on a large scale within the meaning of the regulation. A hospital with 500 beds, however, does.

Systematic extensive monitoring of publicly accessible areas. Large-scale video surveillance, Wi-Fi tracking in shopping centers, or the systematic collection of license plates in public parking lots fall into this category.

Blacklists from supervisory authorities

Art. 35(4) GDPR empowers supervisory authorities to publish lists of processing activities for which a DPIA is mandatory. In Germany, the Data Protection Conference (DSK) has published such a list, the so-called must-list. It includes, among others:

• Extensive processing of employee data suitable for behavioral or performance monitoring
• Use of telematics systems to analyze driving behavior
• Creation of comprehensive profiles of a person's interests, network, and location
• Merging personal data from different sources
• Use of AI systems to process personal data to control interactions with data subjects
• Anonymization of special categories of personal data

If your planned processing appears on this list, there is no discussion: you must conduct a DPIA. Period.

The two-out-of-nine rule from the Article 29 Working Party

For cases that do not clearly fall under the examples or blacklists, the Article 29 Working Party (now the European Data Protection Board, EDPB) has defined nine criteria. If at least two of them apply, you should conduct a DPIA:

1. Evaluation or scoring (including profiling and predictions)
2. Automated decision-making with legal or similar effect
3. Systematic monitoring
4. Processing of confidential or highly personal data
5. Data processing on a large scale
6. Matching or combining data sets
7. Data of vulnerable data subjects (children, employees, mentally ill, asylum seekers)
8. Innovative use or application of new technological or organizational solutions
9. The processing prevents data subjects from exercising a right or using a service

This nine-criteria check is your most important tool for the threshold analysis.

The threshold analysis: DPIA needed or not?

Before you start the full DPIA process, you conduct a threshold analysis (also threshold check). It answers exactly one question: Do I need to conduct a DPIA for this processing activity?

You document the threshold analysis in writing. A negative result ("No DPIA required") must also be justified in a traceable manner. If a supervisory authority asks why you did not conduct a DPIA, a shrug is not sufficient.

The process in practice:

Step 1: Check against the blacklist. Is the processing on the must-list of the competent supervisory authority? If yes, the threshold analysis is complete: DPIA required.

Step 2: Check against the examples. Does the processing fall under one of the three examples from Art. 35(3) GDPR? If yes: DPIA required.

Step 3: Two-out-of-nine check. Do at least two of the nine criteria from the Article 29 Working Party apply? If yes: DPIA recommended (in practice this means: do it).

Step 4: Document the result. Record which criteria you checked, why they apply or not, and whether a DPIA will be conducted.

A practical example: Your organization plans to introduce a time-tracking system with biometric authentication via fingerprint. The threshold analysis shows: processing of biometric data (criterion 4), data of employees as vulnerable data subjects due to the dependency relationship (criterion 7), innovative technology in the organizational context (criterion 8). Three out of nine criteria apply. Result: DPIA required.

The DPIA process in nine steps

When the threshold analysis concludes that a DPIA is needed, you follow a structured process. The following nine steps are based on the EDPB guidelines and the recommendations of the Bavarian State Office for Data Protection Supervision.

Step 1: Systematically describe the processing

Describe the planned processing in enough detail that a qualified third party can fully understand it. This includes:

• Purpose of processing: What is to be achieved? What business objective lies behind it?
• Legal basis: On what basis are you processing the data? Art. 6(1)(a) (consent), (b) (contract performance), (f) (legitimate interest)?
• Data categories: What personal data is collected? Master data, behavioral data, health data, biometric data?
• Data subject groups: Employees, customers, applicants, minors?
• Recipients: Who receives the data? Internal departments, processors, third countries?
• Retention period and deletion deadlines: How long is the data stored?
• Technical infrastructure: Which systems, software, and interfaces are involved?
• Data flows: How does the data move through the systems? From collection through processing to deletion.

Step 2: Assess necessity and proportionality

Here you ask the fundamental question: Is the planned processing actually necessary and proportionate? Specifically you check:

• Purpose limitation: Is the collected data actually necessary for the stated purpose?
• Data minimization: Is only the data collected that is strictly necessary for the purpose? Could you achieve the purpose with less or less sensitive data?
• Storage limitation: Is the retention period limited to the necessary minimum?
• Legal basis: Is the chosen legal basis sound? Is consent truly voluntary, or does a dependency relationship exist?

If you find here that the processing is not necessary or not proportionate, you must adjust the planning before continuing.

Step 3: Adopt the data subject perspective

This step is most frequently omitted in practice but is central. You put yourself in the position of the data subjects and ask:

• What negative consequences could the processing have for the data subjects?
• Could the processing lead to discrimination, financial loss, reputational damage, or loss of control?
• Are the data subjects in a position to understand the processing and effectively exercise their rights?
• Is there a power imbalance between the controller and the data subjects (e.g., employer and employee)?

Art. 35(9) GDPR provides that you should seek the views of the data subjects "where appropriate." This could be an employee survey, a customer survey, or obtaining a statement from the works council.

Step 4: Identify risks

Now you systematically go through the risks. For each data processing activity you ask: What can go wrong? Typical risk categories:

• Unauthorized access: Who could access the data without authorization? Hackers, curious employees, processors with overly broad permissions?
• Unauthorized modification: Could data be manipulated with negative consequences for data subjects?
• Data loss: What happens if data is lost? Can it be restored?
• Unlawful disclosure: Could data reach unauthorized third parties?
• Purpose deviation: Could the data be used for purposes other than those originally intended?
• Linkage risk: Could combining with other data sets yield new, sensitive insights?
• Automation errors: Could algorithmic decisions be systematically incorrect or discriminatory?

Step 5: Assess risks

For each identified risk, you assess two dimensions: the severity of the potential harm to data subjects and the likelihood of occurrence.

Severity can be divided into four levels:

Likelihood is also assessed in four levels: negligible, limited, significant, maximum. The combination of both dimensions yields the risk level. Tools like ISMS Lite directly map this risk matrix and automatically calculate the risk level, allowing you to document the assessment in a structured and audit-ready manner.

Step 6: Define remedial measures

For each risk above the acceptance threshold, you define specific measures to reduce it to an acceptable level. Measures can be technical or organizational:

Technical measures:

• Encryption of data at rest and in transit
• Pseudonymization or anonymization where possible
• Access controls with role-based concepts
• Logging and monitoring of data access
• Automated deletion after retention periods expire
• Data backup and recovery procedures

Organizational measures:

• Employee training and awareness
• Four-eyes principle for critical processing
• Processes for exercising Data Subject Rights
• Contractual binding of processors
• Regular review of access rights
• Documentation and versioning of processing procedures

Each measure must include: a responsible person, an implementation timeline, and a criterion for determining whether the measure is effective.

Step 7: Assess residual risk

After defining the remedial measures, you assess the remaining residual risk. Have the measures reduced the risk level to an acceptable degree? If yes, you document this assessment with justification. If not, you have two options: define additional measures or consult the supervisory authority (Step 9).

Important: Zero residual risk does not exist. The goal is not to eliminate all risks but to reduce them to a level that is acceptable given the processing purpose and the interests of the data subjects.

Step 8: Involve the Data Protection Officer (DPO)

Art. 35(2) GDPR requires that the advice of the Data Protection Officer be sought. This means: the DPO is not merely informed but actively involved in the process. Their opinion and your response to it are documented in the DPIA.

In practice, it has proven effective to involve the DPO from the very beginning — not as a rubber stamp at the end. They can support the threshold analysis and know the supervisory authority's expectations.

Step 9: Consult the supervisory authority (if necessary)

If the residual risk remains high despite all measures, you must consult the competent supervisory authority under Art. 36 GDPR before beginning the processing. The authority then has up to eight weeks for a response (extendable by six weeks). In practice, prior consultation rarely occurs because most organizations find measures that sufficiently reduce the residual risk.

Practical example: DPIA for an employee monitoring system

Let's take a concrete example. A mid-market company with 200 employees plans to introduce software that measures employee productivity while working from home. The software captures active screen time, applications used, keyboard activity, and automatically generates productivity scores.

Threshold analysis: Systematic monitoring (criterion 3), evaluation/scoring (criterion 1), vulnerable data subjects/employees (criterion 7), innovative use (criterion 8). Four criteria apply. DPIA is mandatory.

Processing description: The purpose is performance optimization and resource planning. Legal basis: legitimate interest under Art. 6(1)(f) (questionable whether it is sound given the level of intrusion). Data categories: activity data, application usage, timestamps, aggregated performance evaluations. Data subjects: all employees working from home. Recipients: team leaders and HR department. Retention period: 12 months.

Necessity and proportionality: This is where it gets critical. Is capturing keyboard activity truly necessary for resource planning? Can the goal be achieved with less invasive means, such as results-based monitoring instead of behavior surveillance? The DPIA could conclude here that the processing in this form is not proportionate.

Risk assessment: High risks arise from the permanent monitoring of work behavior (psychological pressure, feeling of total surveillance), automated evaluation (erroneous scores could lead to employment consequences), linking activity data (creating detailed behavioral profiles), and the power imbalance (employees cannot effectively resist).

Result of the example DPIA: In most cases, a DPIA for such a system will conclude that the scope of monitoring must be drastically reduced. Instead of individual keyboard monitoring, perhaps only aggregated team statistics; instead of real-time monitoring, only weekly summaries; instead of automated productivity scores, only anonymized trend analyses.

Common mistakes in DPIAs

Conducting the DPIA too late

The DPIA must be conducted before processing begins, not after. If the system is already running and processing data, the DPIA is a retroactive formality with no real protective effect. In practice, this means: the DPIA belongs in the planning phase of a project, not the closing phase.

Ignoring the data subject perspective

Many DPIAs read like internal risk analyses of the organization. Risks are assessed from the company's perspective: "What does a data breach cost us?" instead of "What does a data breach mean for the data subject?" This mistake distorts the entire assessment because the severity of harm from the data subject's perspective can be entirely different from the organization's perspective.

Involving the DPO only pro forma

Presenting the finished DPIA to the DPO for signature is not involvement within the meaning of Art. 35(2) GDPR. The DPO must be able to give their professional assessment before decisions have been made. Their opinion must be documented, as must your response if you deviate from their recommendation.

Failing to quantify risks

"There is a risk of unauthorized access" is not a risk assessment. A risk assessment assigns each risk a severity and a likelihood and assesses whether the defined measures sufficiently reduce the risk. Without this quantification, the DPIA is a prose text with no analytical value.

No updates when changes occur

A DPIA is not an archive document. When the processing changes — when new data categories are collected, when a new processor enters the picture, when the technical infrastructure changes — the DPIA must be reviewed and, if necessary, updated. Art. 35(11) GDPR explicitly requires this.

Residual risk not documented

Every DPIA must conclude with a clear statement on residual risk. Either: "The residual risk is acceptable after implementing the measures because ..." or: "The residual risk remains high, therefore we will consult the supervisory authority." No statement on residual risk means: the DPIA is incomplete.

DPIA and ISMS: Leveraging synergies

If you already operate an ISMS according to ISO 27001, you have a significant head start with the DPIA. The risk identification and assessment from the ISMS can serve as a foundation for the DPIA — with the important difference in perspective: the ISMS assesses risks to the organization, while the DPIA assesses risks to data subjects.

In practice, it pays to align both processes:

• The ISMS asset inventory (from IT asset management) provides the technical infrastructure for the DPIA processing description
• The existing technical and organizational measures (TOMs) flow directly into the DPIA remedial measures
• The risk assessment methodology from the ISMS can be adapted but must be supplemented with the data subject perspective
• The ISMS audit process can be extended to include DPIA reviews

Documentation requirements

Art. 35(7) GDPR defines the minimum content of a DPIA:

1. A systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued
2. An assessment of the necessity and proportionality of the processing operations in relation to the purposes
3. An assessment of the risks to the rights and freedoms of data subjects
4. The measures envisaged to address the risks, including safeguards, security measures, and mechanisms

In addition, you should document:

• Date of completion and persons involved
• Result of the threshold analysis
• Opinion of the Data Protection Officer
• Result of any consultation with data subjects
• Assessment of residual risk after implementing the measures
• Decision on consulting the supervisory authority
• Date of the next scheduled review

When is no DPIA needed?

Not every processing of personal data requires a DPIA. Alongside blacklists, supervisory authorities also publish whitelist recommendations for processing activities where a DPIA is typically not required. These include:

• Processing customer contact data for contract execution
• Payroll processing (unless special categories are involved)
• Bookkeeping and tax-related retention
• Standard membership management in associations
• Operating a company website without tracking or profiling

But caution: even for these processing activities, a DPIA may become necessary if special circumstances arise — such as combining with other data sets, using innovative technologies, or processing in a third country without an adequacy decision.

Frequently asked practical questions

Must the DPIA be completed before processing begins? Yes. Art. 35(1) GDPR says "prior to." You must not start processing before the DPIA is completed and, if required, the supervisory authority has been consulted.

Who is responsible for conducting it? The controller within the meaning of the GDPR — i.e., the management. In practice, they delegate the operational execution to the DPO, the IT department, or a project team. Responsibility remains with management.

Must I submit the DPIA to the supervisory authority? Not proactively. But the authority can request it during an audit. You must therefore keep it available. And in the case of prior consultation under Art. 36, you naturally submit it.

Can I conduct a single DPIA for multiple similar processing activities? Yes, if the processing activities have similar nature, scope, circumstances, purposes, and risks. A single DPIA for all locations with identical video surveillance is more practical than ten separate DPIAs with identical content.

What happens if I fail to conduct a DPIA when required? Art. 83(4)(a) GDPR provides for fines of up to 10 million euros or 2% of worldwide annual turnover. In practice, supervisory authorities are increasingly imposing fines for missing DPIAs, particularly for video surveillance and employee monitoring.

Next steps

Start with an inventory of your processing activities. Take your records of processing activities and check each processing activity against the blacklist of the competent supervisory authority and the nine-criteria checklist. For each processing activity that requires a DPIA, start the nine-step process. And for each processing activity that does not require a DPIA, document the threshold analysis with justification.

The DPIA is not a bureaucratic end in itself. It is a tool that forces you to consider a processing activity from the data subject's perspective before you begin implementation. When properly conducted, it uncovers weaknesses that would otherwise only become apparent after an incident, and it gives you robust documentation that is invaluable during a supervisory authority audit.

Further reading

• Records of processing activities (RoPA) under Art. 30 GDPR
• Documenting technical and organizational measures (TOMs)
• GDPR data breach notification: When, how, and to whom
• Deletion concept under GDPR: Retention periods, deletion rules, and implementation
• Implementing Data Subject Rights: Access, erasure, and data portability

The DPIA is one of the most demanding yet one of the most valuable processes in data protection. It requires expertise, diligence, and the willingness to critically question a planned processing activity. That is exactly what makes it so effective.