What is a Data Protection Impact Assessment and how to carry out one under GDPR?

DPIA (also known as Data Protection Impact Assessment) is an operation that helps determine whether processing creates a risk for the data subject and how serious that risk is. In this article, we provide more details about this procedure and how to conduct it in accordance with GDPR (General Data Protection Regulation).

What is DPIA?

DPIA (Data Protection Impact Assessment) is a process that describes how personal data is processed, verifies the necessity and legitimacy of such personal data processing, and identifies risks to people’s rights and freedoms. It helps assess these risks and determine measures to mitigate them.

A data protection impact assessment can concern either a single processing operation or a set of similar operations that present approximately equal high risks.

DPIA is one of the accountability tools that helps controllers comply with the Regulation’s requirements and demonstrate that they are taking appropriate measures to ensure compliance.

An Impact Assessment must be conducted before processing begins. This stage becomes part of the Privacy by Design system — protecting personal data at the design stage. But this doesn’t mean that conducting a DPIA once will be enough. It is an ongoing process, not a one-time event, especially when the processing operation is dynamic and constantly changing. Regular review of results and corresponding security measures is necessary.

Overall, DPIA is not just a document, but a procedure that can trigger significant internal process redesign, reveal shortcomings and critical risks. It is a tool that allows companies to protect themselves from problems with supervisory authorities, partners, and clients.

Who should carry out a DPIA?

The impact assessment is conducted by the data controller, who bears ultimate responsibility for its execution. Although the controller is responsible, the procedure itself may be performed by other persons both within and outside the organization.

The following parties participate in the assessment process:

Controller: is the main person responsible for the process.

Article: How to Manage a Chain of Processors Under GDPR: Expert Guide for Controllers

Discover the most common mistakes companies make when managing processors and how to avoid them.

Data Protection Officer: the controller must consult with the DPO if one has been appointed. The DPO’s advice and the decisions made by the controller must be documented. The DPO must also monitor how the assessment is conducted.

Processor: if processing is carried out wholly or partially by a processor, they must assist the controller in conducting the assessment and provide all necessary information.

Data subjects or their representatives — the controller should seek their views if appropriate. This can be done through surveys or consultations with staff representatives. If the controller’s final decision differs from the subjects’ opinion, this must be documented. If the subjects’ opinion was not sought, the reason for this must be documented.

Internal teams and departments: may provide input. In particular, it is recommended to involve:

- IT and information security departments (including CISO — Chief Information Security Officer).
- Product team (developers, analysts, UX designers): their participation is important for considering the actual technical capabilities and limitations of the product and assessing the impact on user experience.
- Business units: for assessing business constraints and creating new business processes.

Independent experts — it is recommended to seek advice from independent experts: lawyers, IT specialists, security specialists, sociologists, and ethicists.

The involvement of various stakeholders helps ensure a comprehensive approach and gather complete information for a fair assessment.

When a DPIA is required?

The assessment procedure is mandatory when data processing is likely to result in a high risk to the rights and freedoms of individuals.

Although an assessment is not required for every individual processing activity, the Regulation (Article 35(3)) provides an incomplete list of scenarios where the risk may be high:

1. Automated evaluation of personal characteristics of an individual (including profiling), based on which decisions are made with legal consequences or other significant impact on them. For example, an HR system that automatically analyzes employee performance and decides who to promote or terminate. Or an algorithm for assessing a client’s creditworthiness and making a decision on granting a loan.
2. Large-scale processing of special categories of data (for example, health data, biometric, genetic, racial or ethnic origin, political views, religious or philosophical beliefs, trade union membership) or personal data concerning criminal convictions and offenses.
3. Systematic monitoring of publicly accessible areas on a large scale.

The list in Article 35(3) is not exhaustive. The Article 29 Working Party (WP29), whose guidelines were endorsed by the European Data Protection Board, developed nine criteria that help determine when data processing may result in high risk:

Evaluation or scoring, including profiling and prediction, especially of work performance, economic situation, health, personal preferences or interests, reliability or behavior, location or movements.
Automated decision-making with significant consequences for the data subject, for example, leading to exclusion or discrimination.
Systematic monitoring: processing used to observe, track, or control subjects, including data collected through networks or systematic monitoring of publicly accessible areas. In such cases, subjects may not be aware of the collection and use of their data, and it may be impossible for them to avoid such processing.
Processing of sensitive data, such as information about health, racial origin, criminal convictions or offenses, as well as data concerning private life (for example, location or financial information) that may violate fundamental human rights.
Large-scale data processing: although the GDPR does not provide a clear definition of “large-scale” processing, WP29 recommends considering the following factors:
- - The number of data subjects affected (specific number or proportion of the relevant population).
  - The volume of data and/or the range of different types of data being processed.
  - The duration or permanence of the activity.
  - The geographical scope of the activity.
Combining data from different sources or for different purposes in a way that may exceed the expectations of the person whose data is being used.
Data concerning vulnerable subjects: in such cases, there may be an increased imbalance between subjects and the controller. Vulnerable subjects may include children, employees, mentally ill persons, asylum seekers, elderly people, or patients.
Innovative use or application of new solutions, for example, combining fingerprints and facial recognition for physical access control.
When processing prevents subjects from exercising a right or using a service or contract. For example, a bank that checks clients against a credit history database to make a decision on granting a loan.

In most cases, if processing meets two or more of these criteria, a DPIA is considered mandatory. However, even if processing meets only one of these criteria, a DPIA may be required.

Supervisory authorities are also required to publish lists of operations that require a DPIA (so-called “blacklists”). Controllers must refer to such lists and also independently assess risks.

A DPIA may also be mandatory for existing operations if there has been a change in risks related to their nature, scope, context, or purposes.

When can you avoid conducting an assessment?

🔹 When processing is unlikely to result in a high risk to the rights and freedoms of individuals.

🔹 When the nature, scope, context, and purposes of processing are very similar to processing for which a DPIA has already been conducted, and its results can be used.

🔹 When processing operations were reviewed by a supervisory authority before May 2018 under certain conditions that have not changed.

🔹 When a processing operation has a legal basis in EU or Member State law, where that legislation regulates the specific operation, and a DPIA was already conducted as part of establishing that legal basis.

🔹 When processing is included in a list of operations for which a DPIA is not required, compiled by a supervisory authority.

How to conduct an Impact Assessment under GDPR?

Steps for conducting a DPIA:

WP29 proposes a general assessment framework:

1. Defining the purpose of processing.

- Describe the nature, scope, context, and purposes of processing.
- Specify what data is collected (for example, names, addresses, medical records), how it is processed (stored, analyzed, transmitted), and who has access to it (employees, third-party vendors).
- Record personal data, recipients, and retention period.
- Provide a functional description of the processing operation.
- Identify the assets on which personal data relies (hardware and software, networks, people, paper or paper transmission channels).
- Specify the legal basis for processing. One legal basis must be defined for each processing purpose.
- Identify the departments involved in processing and the location of data processing centers to assess cross-border transfer requirements and distribution of roles (controller/processor).

2. Assessment of necessity and proportionality.

- Determine whether processing is necessary to achieve the intended purpose and proportionate to the risks.
- Ask questions: Can the purpose be achieved by means less “harmful” to the user? Is data collection limited to what is actually necessary? Are retention periods justified?
- Assess the measures the company is already taking to process data based on the proportionality and necessity of processing.

3. Identification and assessment of risks to the rights and freedoms of data subjects.

- Assess the origin, nature, characteristics, and severity of risks. These may be risks of unlawful access, unwanted alteration, and loss of data.
- Identify sources of risks, potential consequences, and threats.
- Assess the likelihood and severity of each risk. This can be done using a specialized matrix.
- Consider risks such as unauthorized access (data breach), discrimination (bias in automated decision-making), loss of control (inability to exercise rights), and reputational damage. This stage may require considerable imagination and experience, as you need to envision as many potential negative scenarios as possible. You can simplify this task by studying supervisory authority penalty reports and high-profile incidents.

4. Identifying measures to mitigate risks and demonstrate compliance.

- Propose measures to reduce or eliminate each identified risk.

Examples of measures: encryption and pseudonymization, access controls, transparent privacy notices, regular audits.

Include measures that help users understand and exercise their rights: providing information, right of access and data portability, right to rectification and erasure, right to object and restrict processing, and others.
Recommendations should be clear, specific, and actionable. They should not be limited to information security measures only, but may include creating separate policies, involving the DPO, and changes to business processes.

5. Consultation with stakeholders.

- Mandatory: seek the advice of the DPO.
- Where necessary, seek the views of data subjects or their representatives.
- Involve IT teams, lawyers, developers, analysts, and UX designers.
- If high residual risks remain after implementing risk mitigation measures, consult with the supervisory authority before commencing processing.
- Discuss recommendations with the product team and other stakeholders to ensure they are realistic and feasible, and to avoid conflicts.

6. Documentation and review.

- Document all findings, decisions, and actions in a detailed report.
- The DPIA is a “living” document. It must be reviewed regularly or when processing changes.
- Develop a detailed Action Plan with clearly assigned responsible persons and deadlines.
- A DPIA is considered fully complete only after the company has implemented corrective measures.
- Ensure ongoing monitoring of measure implementation and record all actions taken in the Record of Processing Activities (RoPA).
- While publishing the full DPIA is not mandatory, publishing a summary or findings can help build trust with users and partners. The full report must be provided to the supervisory authority in case of prior consultation or upon request.

What knowledge and skills are required to carry out a DPIA?

In addition to complete information about processing operations and assistance from colleagues in other departments, certain skills are needed for risk assessment:

🔹 Legal knowledge

Understanding data privacy laws is necessary to accurately formulate processing purposes, determine legal bases, and develop consent mechanisms and required documentation.

🔹 Technical knowledge

Personal data protection is closely linked to information security. To understand how data is processed and protected, you need to understand their lifecycle, information systems, and assets (hardware, software).

🔹 Risk identification and assessment skills

To conduct the procedure, a specialist must model scenarios, anticipate potential threats, and analyze breaches.

🔹 Communication and negotiation skills

Beyond conducting a formal procedure, a specialist must be able to engage with stakeholders, reach compromises on measures, and demonstrate to teams why implementing the recommendations is necessary.

🔹 Monitoring and control skills

After conducting a DPIA, it is important to track how recommendations are being implemented.

Want to learn all of this?

In the GDPR Data Privacy Professional course, we provide fundamental knowledge of laws and principles of personal data protection needed to conduct assessments and develop documents under GDPR.

Challenges in developing a Data Protection Impact Assessment and ways to overcome them

In practice, developing a data protection impact assessment can be associated with a number of challenges and mistakes.

1. Becoming a “paper formality”

Challenge: DPIAs are often performed as a checkbox exercise, as a document to demonstrate compliance rather than as a tool for real risk management. Recommendations remain on paper, and corrective measures are not implemented. This means the procedure is effectively (and legally) not completed.

How to address this?

- It is important to view the DPIA not just as a document, but as a procedure that initiates internal process transformation and identifies critical risks.
- It is necessary to develop a detailed Action Plan with clearly assigned responsibilities and deadlines, as well as ensure ongoing monitoring of measure implementation.

2. Focus on mitigating consequences instead of preventing threats

Challenge: DPIAs are often criticized for being focused on mitigating the consequences of risks rather than preventing them. The procedure can be used to “justify” problems that have already occurred rather than eliminating them at early stages.

How to address this?

- Incorporate the DPIA into the Privacy by Design concept. This allows risks to be prevented at the earliest stages of process design.

3. Late DPIA conduct and limited design space

Challenge: DPIAs are often conducted too late, when the decision about data processing has already been made and the possibilities for changing the system design are limited. For example, when it is already known what information the system will process.

How to address this?

- Begin assessing risks as early as possible in the process design, even if some details are still unknown.
- The DPIA is not a one-time event, but a continuous process. Develop and update it as the project develops or risks change.

4. Vague and generic recommendations

Challenge: Recommendations formulated in the DPIA may be too abstract, making them difficult to implement by executors who do not have deep knowledge in data protection. This can lead to incorrect implementation or even inaction.

Ways to overcome:

- Specific and technically feasible recommendations: Recommendations should be clear, specific, and technically implementable.
- Discussion of constraints: Conduct discussions of technical and business constraints with the product team and other stakeholders to create practically applicable recommendations.

5. Bias toward information security and ignoring a broad spectrum of threats

Challenge: A common mistake is to view the DPIA only as a tool for analyzing technical information security risks. However, the spectrum of risks to users includes discrimination, manipulation, loss of control over data, reputational harm, and other ethical aspects.

How to address this?

- A comprehensive assessment should include a wide spectrum of risks to data subjects and rely not only on technical measures but on GDPR requirements. Measures adopted should promote proportionality and necessity of processing based on clearly defined, explicit, and lawful purposes (Art. 5(1)(b) GDPR) and be limited to adequate, relevant, and necessary data (Art. 5(1)(c) GDPR). The report should also include measures that help respect data subjects’ rights, including the right to information (Art. 12, 13, 14 GDPR), access and data portability (Art. 15, 20 GDPR), rectification and erasure (Art. 16, 17, 19 GDPR), objection and restriction of processing (Art. 18, 19, 21 GDPR).

6. Resource constraints

Challenge: Especially for small enterprises, preparing a DPIA may seem too time and resource-intensive.

How to address this?

- Use ready-made resources: Supervisory authorities, such as CNIL or ICO, often publish free templates and guidance. To verify how effectively the developed measures are being implemented, you can also rely on international standards, such as ISO 27001, ISO 27701.

7. Difficulties in identifying and risk assessment

Challenge: To conduct a data protection impact assessment, extensive experience in this field is needed. Without it, a specialist will find it difficult to model various scenarios and anticipate threats.

How to address this?

- Use Daniel Solove’s privacy taxonomy. The taxonomy is developed based on analysis of court cases and categorizes possible privacy violations. Hoepman’s strategies also help expand the list of possible ways to minimize practices dangerous to users.

Conducting a DPIA in accordance with the General Data Protection Regulation (GDPR) independently is quite feasible. The main thing is to consider these points:

1. The process should be continuous and flexible. The DPIA is not limited to a one-time document; it should be part of the Privacy by Design approach. The assessment should be conducted before data processing begins, and then regularly reviewed to account for changes in risks and processes.
2. Risks need to be thoroughly examined. It is important not only to document potential threats but also to assess their severity and likelihood. You need to anticipate all possible scenarios, such as unauthorized access or loss of control over data, and develop specific measures to minimize them.
3. Engaging stakeholders. For a comprehensive risk assessment, it is important to involve diverse specialists: lawyers, developers, and even the data subjects themselves. This will ensure a comprehensive approach to analysis and help develop effective recommendations for risk mitigation.

Proper execution of a DPIA requires attention, engagement, and constant monitoring, but this will help minimize risks and achieve the desired GDPR compliance.