Data Protection Impact Assessment (DPIA) – Practical Guide + Template Form

The text has been prepared on the basis of the EDPB guidelines (WP 248) „Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is likely to result in a high risk for the purposes of Regulation 2016/679”, as well as the guidance provided in the handbooks of the supervisory authorities of Ireland, the Netherlands, and France.

How does a DPIA fit into the risk management process

Risk analysis is one of the key elements of the GDPR. Risk is a specific scenario: an event that may occur and its consequences for the data subject. The GDPR imposes on the data controller the obligation to manage risk. It is not enough to analyse something once and then put the document on a shelf. Risk management is an ongoing process that includes identifying threats, assessing their impact, and then implementing remedial measures and conducting regular reviews of the analysis carried out.

A DPIA is required where data processing may result in a high risk to the rights or freedoms of natural persons. It should constitute a documented process that forms part of risk management within the organisation. A DPIA helps the data controller make informed decisions and demonstrate compliance with the GDPR under the accountability principle (you can read more about this principle in a separate article).

As part of the DPIA, the data controller determines the scope of the processing, identifies potential threats, and selects appropriate remedial measures (Recital 90 of the GDPR). Such actions overlap with the elements of risk management under ISO 31000. However, it should be noted that a DPIA focuses on the perspective of the individuals whose data are being processed, rather than on the organisation’s perspective. This distinguishes a DPIA from other areas of risk analysis, e.g. in the area of information security.

Who is responsible for the DPIA, who reviews it, and who supports this process

The data controller is responsible for carrying out the DPIA. It is the data controller who decides whether the assessment is necessary and how it should be performed. The data controller may commission a third party to carry out the DPIA, but remains responsible for the proper conduct of the entire process.

If the organisation has a Data Protection Officer (DPO), the data controller should consult the DPO on the DPIA (Article 35(2) of the GDPR). The data controller should also document the results of such consultations, including the decisions made.

The DPO’s duties include monitoring the proper performance of the DPIA and providing recommendations on this process at the request of the data controller (Article 39(1)(c) of the GDPR). According to the EDPB guidelines, the DPO’s tasks may include:

• identifying specific processes requiring a DPIA,
• assisting in developing the DPIA methodology,
• supporting the data controller in expanding their knowledge,
• assisting in assessing what level of risk can be accepted.

Internal stakeholders play an important role in the DPIA process – business process owners who know the processing operations best. They should be consulted on technical aspects, such as the manner in which data are collected, stored and processed, as well as how the individual elements of the business process fit together.

Data processors can also provide equally valuable information. The data controller should ensure in advance that the data processing agreement obliges the data processor to assist in carrying out the DPIA (Article 28(3)(f) of the GDPR).

Where appropriate, the data controller should consult the data subjects or their representatives (Article 35(9) GDPR). For example, if the process under review concerns employees, a trade union organisation may provide an opinion. If the process concerns contractors, their views may be obtained through appropriately designed surveys.

The data controller does not have to agree with the opinion of the data subjects. However, if it takes a decision contrary to that opinion or does not seek the views of those individuals at all, it should justify this within the DPIA process. It is also worth noting that consent to data processing does not in itself constitute an opinion within the meaning of Article 35(9) GDPR. The views of the data subjects should be obtained independently of any consent given.

When a DPIA is mandatory and what “high risk” means

Not every personal data processing operation requires a DPIA. Carrying one out is mandatory where it is likely that the processing may result in a high risk to the rights or freedoms of natural persons. In practice, this means that each processing activity should be assessed at least to determine whether such high risk may occur.

Article 35(3) GDPR identifies three examples of situations in which a DPIA is required. These are:

• carrying out a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the individual or similarly significantly affect the individual,
• processing on a large scale of special categories of data (Article 9 GDPR) or data relating to criminal convictions (Article 10 GDPR),
• systematic monitoring of publicly accessible areas on a large scale.

How to assess high risk according to the EDPB

The EDPB guidelines identify nine criteria that support the need to carry out a DPIA. According to these recommendations, a DPIA is:

• generally optional – if only one criterion is met,
• mandatory – if at least two criteria are met, as this indicates a high likelihood of high risk.

It should be remembered that the list of types of processing operations described in the EDPB guidelines is not exhaustive. This means that the data controller is not relieved of the obligation to assess, in each case, whether high risk to the rights or freedoms of natural persons may arise in the specific circumstances.

Criteria indicating high risk according to the EDPB guidelines:

1. Profiling, assessment and scoring

This criterion covers the assessment or scoring of individuals, including profiling and prediction, based on information about them, such as their health, work performance, economic situation, location and movements, personal preferences, behaviour and interests.

Examples:

• a bank verifying customers in a database,
• a biotechnology company offering genetic tests to assess the risk of disease,
• a company building behavioural and marketing profiles based on a person’s behaviour on a website.

2. Automated decision-making

This criterion applies where automated decisions are made – without human involvement, approval or meaningful intervention. For the criterion to be met, these decisions must produce legal effects concerning individuals or otherwise similarly affect them. If the impact is minor or non-existent, the criterion will not be met.

Example: systems analysing customer data in order to determine their purchasing preferences or to automatically tailor individual prices and promotions.

3. Systematic monitoring

This criterion applies where an organisation systematically observes, monitors or controls individuals, for example by means of CCTV cameras or through location tracking using GPS devices. High risk may arise from the fact that individuals are not informed that they are being observed, and consequently – from their inability to avoid the monitoring. 

4. Sensitive data

This criterion is met where the processing includes sensitive data. In a broad sense, “sensitive data” includes:

• special category data within the meaning of Article 9 GDPR,
• data relating to convictions within the meaning of Article 10 GDPR,
• other data that may be regarded as sensitive in a broader sense, because they concern, for example, a person’s location, finances or communications – due to the personal or domestic nature of such data, their processing may be considered intrusive and risky, especially on a large scale.

5. Large scale

This criterion should be assessed through the prism of both the specific number of data subjects or the percentage of the population, as well as the volume of data processed, the duration of processing and the geographical scope of the processing. By way of example, the Czech supervisory authority held that processing is on a large scale where it concerns:

• 10 001 data subjects or more than 0.01 % of the population of the Czech Republic or other countries, or
• more than 20 persons with access to the data, or
• more than 20 locations/branches where data processing takes place

– and at the same time the data subjects come from a region or reside in a region at NUTS 1 level (in Poland, these are seven macro-regions, e.g. the macro-region: the Mazowieckie Voivodeship).

More on the concept of large scale can be found in this article.

6. Matching or combining datasets

This criterion concerns the combination or matching of data originating from different processing operations. Such data aggregation may lead to the obtaining of new information by drawing inferences that may go beyond the reasonable expectations of the data subjects.

7. Processing data concerning persons requiring special protection

This criterion refers to persons who, due to their personal characteristics or an imbalance of power in their relationship with the data controller, may have greater difficulty in giving informed and freely given consent to the processing of their data, in objecting to processing, or in exercising their rights. This applies in particular to:

• children,
• employees in their relationship with the employer,
• vulnerable social groups: persons with mental illness, asylum seekers, elderly persons, patients.

8. Use of innovative technologies

This criterion applies when new technologies are used in the processing operation, in particular when they operate in combination, e.g. artificial intelligence systems, devices collecting various biometric data, or certain Internet of Things systems. Such solutions may have a significant impact on the privacy of data subjects.

If you would like to learn more about the „Internet of Things”, read this article.

9. Preventing access to a service or exercise of a right

This criterion concerns processing operations on which the ability to use a service, conclude a contract, or exercise the rights of an individual depends.

Example: a bank verifying customers in a reference database in order to decide whether to grant a loan.

The EDPB guidelines contain examples illustrating the correct method of analysing the criteria described above. Here are some of them:

• A hospital processing a patient's health data:
  • sensitive data: YES,
  • vulnerable individuals (patients): YES,
  • large scale: YES.

Summary: three criteria met – a DPIA must be carried out.

• An employer systematically monitoring employees, including their workplaces and Internet activity:
  • systematic monitoring: YES,
  • vulnerable individuals (employees): YES.

Summary: two criteria met – a DPIA must be carried out.

• A website controller sending a newsletter to a large list of subscribers:
  • large scale: YES.

Summary: one criterion met – a DPIA is generally optional.

To make it easier to check whether a given processing operation requires a DPIA, we have prepared a simple calculator that includes detailed explanations of each of the above criteria.

When is a DPIA required – the list of the President of the Polish DPA

The President of the Polish Data Protection Authority has established a list of cases subject to the DPIA requirement. As a rule, the obligation to carry out a DPIA arises where at least two criteria included in that list are met.

The list of the President of the Polish DPA supplements and specifies the nine criteria indicated in the EDPB guidelines. Like the guidelines, it does not relieve the data controller of the obligation to assess each case for the presence of a high risk to the rights or freedoms of natural persons.

By publishing the list, the President of the Polish DPA fulfilled the obligation of the supervisory authority under Article 35(4) of the GDPR. If you want to find out which cases are covered by the lists of supervisory authorities in other EU Member States, please see this article.

In which cases may a DPIA be omitted

A DPIA is not always mandatory. Pursuant to Article 35 of the GDPR and the EDPB guidelines, it may be omitted in several specific situations. Above all, a DPIA does not need to be carried out if, based on an analysis of the specific case, it follows that the processing operation is unlikely to result in a high risk to the rights and freedoms of natural persons. A DPIA is also not required if an assessment has previously been carried out for a very similar processing operation. In that case, the existing results may be used.

Another exception applies where processing is carried out on the basis of EU law or national law (e.g. pursuant to Article 6(1)(c) or (e) of the GDPR), and the DPIA has already been carried out at the stage of adopting that legal basis.

In addition, under Article 35(5) of the GDPR, the national supervisory authority may establish and make public a list of the types of processing operations that are not subject to the requirement to carry out a DPIA. In Poland, the President of the Polish DPA has not yet prepared such a list. In France, however, it has already been published by the CNIL (the French supervisory authority) – more on this topic can be found in this article.

When to start the DPIA process

From a legal perspective, the timing of performing a DPIA is clearly defined. Under Article 35(1) of the GDPR, it must be carried out before the processing of personal data begins. This follows from the principle of privacy by design (Article 25 of the GDPR), which requires data protection to be taken into account already at the stage of designing processes. Recitals 90 and 93 of the GDPR emphasize that a DPIA is intended to support decision-making and prevent risks before they materialise. It is therefore not justified to postpone a DPIA because the business process in which personal data are processed has not yet been fully developed. The law requires that the DPIA be initiated as early as possible.

The economic aspect is also important. Conducting a DPIA at an early stage can bring business benefits. The earlier risks are identified, the easier and less costly they will be to mitigate. Changes to an already operating business process launched without prior analyses may generate high and unnecessary costs – both financial and organisational. A DPIA is therefore a planning tool that helps avoid costly corrections at later stages.

In practice, a DPIA should be treated as a process rather than a one-off activity. An experienced manager knows that at the early stage of planning and developing a project, not all details are yet known. At that point, it is difficult to determine unequivocally what scope of data processing will be necessary to achieve the intended purpose. Nevertheless, the analysis should be started as early as possible and updated as the project develops.

Changes in the technology used and the clarification of the purpose of processing or the organisational context may affect the level of risk. For this reason, regular review of the DPIA is good practice and helps the data controller ensure compliance with the law and the accountability principle.

How to carry out a DPIA

The process should begin by checking whether a DPIA is required at all. This means determining whether the planned processing operations may result in a high risk to the rights and freedoms of data subjects. The Irish supervisory authority recommends that, from the outset, it be determined which resources and persons will be involved in the assessment process. It is good practice to establish a work schedule.

The next step is to define the scope of the project. It should be determined, as precisely as possible, what data will be processed, for what purpose, and which processing operations are planned, e.g. collection, storage, use, erasure. It is worth considering whether the processing of the collected data will lead to the creation of new data. For example, collected data concerning a particular individual may make it possible to create a psychological profile of that person. The findings from this stage will make it possible to better understand the manner and purpose of data use in the process under review.

The next stage is the identification of threats. At this stage, we determine what risks may arise for the data subjects. It is worth analysing, among other things, the possibility of causing stress, inconvenience, the risk of financial losses and physical harm. The Irish supervisory authority has identified the following examples of risks to individuals:

• accidental loss of electronic equipment, resulting in a risk of disclosure of personal data,
• a hacker attack causing a data breach,
• disclosure of personal data as a result of ineffective anonymisation techniques,
• use of personal data in a manner not anticipated by the data subject (due to the person not being informed or a change in the nature of the project),
• combining data sets that leads to the generation of new data, if the person did not expect such an outcome, or to the identification of a person despite prior anonymisation of the data.

Once the threats have been identified, remedial measures should be determined. These may include both technical measures (e.g. encryption, pseudonymisation, access control) and organisational measures (e.g. training, policies and procedures, limiting the scope of processing). It is important that the selected measures are proportionate to the level of risk and that they make it possible to demonstrate compliance with the GDPR.

The entire process should be properly documented. The GDPR does not impose an obligation to prepare a formal DPIA report, but its preparation and formal adoption by management is good practice and may constitute evidence of accountability.

To facilitate the documentation of the DPIA process, we have prepared a form that will generate a PDF of the completed process, as well as an editable version: DPIA document template together with an example DPIA .

Publication of the results of a DPIA is not mandatory, but it may help increase trust in a data controller that acts transparently and responsibly. In practice, full reports from a completed DPIA are not published. Instead, shortened versions or summaries are made available, in particular where the full report contains confidential information, such as details of the safeguards applied or trade secrets.

What to do when residual risk remains high despite remedial measures

In practice, despite the implementation of various safeguards, there may still be a risk of adverse effects for individuals. This is residual risk, also referred to as reidual risk. This risk remains even after all planned technical and organisational measures intended to reduce it have been implemented. The GDPR permits such risk, provided it has been appropriately reduced. Recital 84 of the GDPR explains that the purpose of a DPIA is to identify risk and minimise it to an acceptable level.

There are situations in which residual risk remains high. These are cases where the planned safeguards have not reduced the high level of risk. By way of example, individuals may still suffer significant or irreversible consequences, such as dismissal from employment or serious financial harm. Such a situation may also arise where it has not been possible to limit the number of persons with access to the data or to remedy security vulnerabilities.

If residual risk is high, the data controller may not decide on its own to commence processing – it is obliged to consult the supervisory authority (Article 36 of the GDPR). The purpose of such consultation is to obtain an opinion on whether the planned measures are sufficient or whether additional safeguards should be implemented. In some cases, the authority may even prohibit the processing. Failure to consult despite high residual risk may result in the imposition of an administrative fine предусмотрed for a breach of the GDPR.

Does the DPIA process have to be repeated

In the original version of the EDPB guidelines, it was suggested that a DPIA should be repeated every three years. After the document was revised, this recommendation was removed. At present, the EDPB guidelines do not indicate a fixed deadline by which a DPIA must be carried out again. The decision to review and update it should result from the data controller's individual assessment.

How can it be assessed whether there is a need to carry out a DPIA again? The key is to determine whether there have been changes in the processing operations that may affect the level of risk. The introduction of new technologies, the emergence of new threats, the expansion of the scope of data processed, or a change in the purpose of processing – these are examples of situations in which a DPIA must be carried out again.

A regular review of the DPIA is good practice, as it helps maintain an adequate level of data protection in a changing environment and properly implement the accountability principle under the GDPR. Particular attention should be paid to processing operations that existed before the GDPR began to apply, i.e. before May 2018. Initially, such operations were exempt from the obligation to carry out a DPIA. The data controller should verify whether the processing conditions have changed and whether there is now a high risk to the rights or freedoms of natural persons.

How to speed up and facilitate a DPIA

There is no need to carry out a separate DPIA for each processing operation if the individual operations are similar in terms of nature, scope, context, purpose and risk. Pursuant to Article 35(1) of the GDPR, one joint assessment may be carried out for such operations. This may apply both to operations carried out by a single data controller (e.g. an entity in the railway industry installs a CCTV system at all stations) and by different data controllers (e.g. several municipal offices install an analogous CCTV system). This means that it is permissible to create a reference assessment that is used by many entities. However, the use of such an assessment requires documented justification.

Another way to facilitate the DPIA process is to use a reference assessment prepared by the product provider. A data controller implementing a solution supplied by a provider (e.g. hardware or software) may carry out a DPIA from scratch or rely on the assessment prepared by the provider. Such a reference DPIA may also serve as a template or starting point to shorten the process of carrying out a DPIA independently.

Conducting a DPIA is made easier by good cooperation with the data processor. Therefore, in data processing agreements, it is worth properly securing the terms of the expected support from data processors. Moreover, Article 28(3)(f) of the GDPR expressly requires the data processing agreement to include an obligation on the data processor to assist the controller in fulfilling its obligations, including in conducting the DPIA. The scope of this assistance should take into account the nature of the processing and the information available to the data processor.

What are the biggest challenges in the DPIA process

One of the greatest challenges associated with properly conducting a DPIA is the ongoing monitoring of the organisation in order to identify processes requiring assessment. In practice, this means the need to continuously track changes in procedures and systems, which can be difficult, especially in larger structures.

The DPIA process is unquestionably complex. It requires an adequate level of knowledge and experience. Familiarity with the law, applicable procedures, as well as the characteristics of the safeguards used, is essential. Experience in these areas helps in selecting remedial measures that are effective and cost-efficient. That is why the EDPB guidelines recommend the involvement of experts from various fields in the DPIA process – lawyers, IT specialists, security professionals. However, this also means the need for effective coordination of information gathering from different departments. A lack of proper communication may prolong and complicate the entire process.

It is therefore advisable to establish a team to conduct the DPIA. This usually involves assigning selected employees additional, permanent responsibilities. Where the organisation's internal staff do not have the required qualifications, or where they do have such qualifications but key individuals are heavily involved in ongoing, urgent tasks, the optimal solution is to outsource the DPIA to an external company.

Outsourcing is a convenient alternative to building an internal team. Such a solution provides access to specialist expertise, helps avoid costly mistakes and facilitates the implementation of solutions aligned with best practices. Using the support of external companies is also usually attractive from an economic perspective, as it makes it possible to adjust the scale of the service provided to the size and needs of the organisation. This approach enables effective and cost-efficient management of the DPIA process – which is important, but not always at the top of the organisation's management priorities.

What is the penalty for failing to carry out a DPIA and have any fines already been imposed?

The failure to carry out a Data Protection Impact Assessment (DPIA) where one is required, or conducting it improperly, constitutes a breach of the GDPR. In such a situation, the supervisory authority may impose an administrative fine of up to EUR 20 million or 4% of the controller’s turnover. Fines for this type of infringement are in fact imposed.

On 18 December 2024, the President of the Polish DPA imposed an administrative fine of PLN 315 302 on Toyota Bank S.A. for omitting profiling in the records of processing activities and in the Data Protection Impact Assessment. The fine was imposed after the President of the Polish DPA established that the bank profiled numerous customer data in order to assess their creditworthiness. The profiling consisted of creating a point-based credit risk score and assigning the risk category defined by the bank (so-called scoring). The bank did not make credit-granting decisions in an automated manner, but in the authority’s view the nature of the profiling — due to the large scale of the operation, its scope, context and purposes — justified the obligation to carry out a DPIA for this process. The authority also pointed to the use of automated technical measures and the creation of new information about individuals, which, if disclosed, could lead to adverse consequences. Such consequences included, in particular, the risk of stigmatization and discrimination associated with the disclosure of information on the financial status of persons applying for credit. In its judgment of 18 September 2025, the Regional Administrative Court in Warsaw upheld the authority’s reasoning and dismissed the controller’s complaint.

In 2025, the Spanish supervisory authority AEPD imposed a fine of EUR 10 043 002 on AENA, the operator of airports in Spain, in connection with a breach of the GDPR in the implementation of facial recognition systems. These systems were piloted at three Spanish airports and were then planned to be rolled out to another eight airports. The scope of processing covered more than 62,000 individuals. In the authority’s assessment, AENA carried out the DPIA improperly, as the technical measures it selected, consisting of centralized storage of biometric templates, did not satisfy the principle of necessity and proportionality. The DPIA also failed to include a proper analysis of other solutions that could have been equally effective while being less intrusive. The alternatives were dismissed hastily, guided solely by operational convenience rather than privacy protection. The focus was placed on benefits instead of a genuine balancing of gains and losses for the rights and freedoms of passengers.

In 2025, the Spanish supervisory authority AEPD imposed a fine of 1 000 000 euro on Liga Nacional de Fútbol Profesional – a sports association known as LaLiga, which manages two professional football leagues in Spain (Primera and Segunda División). The reason for the fine was the failure to carry out a DPIA before implementing an access control system for spectators in football stadiums based on biometric data (facial recognition and fingerprints). The authority rejected LaLiga’s argument that it was not the data controller. It pointed out that LaLiga had designed the system and imposed it on the clubs. The authority further found that large-scale processing of biometric data, i.e. data relating to thousands of fans, involves a high risk to the rights and freedoms of individuals and absolutely requires a prior DPIA

 In 2023, the Dutch supervisory authority AP imposed a fine of 150 000 euro on International Card Services B.V. (ICS) for failing to carry out a DPIA. According to the authority’s findings, ICS processed the data of approximately 1.5 million customers, which indicated that the criterion of “large scale” had been met. In addition, ICS processed a broad range of information about individuals, which justified the conclusion that the criterion of “sensitive data” had been met. The scope of this data included: first and last name, date and place of birth, telephone number, email address, gender, BSN number (the equivalent of the Polish PESEL number), identity document number, image from the identity document, and the so-called liveness photo (such photos are used to confirm that we are dealing with a living, physically present person, and not, for example, a photograph, video recording or mask). ICS did not appeal the decision, and therefore the fine is final.

In 2020, the Norwegian supervisory authority Datatilsynet imposed a fine equivalent to 46 660 euro on the municipality of Rælingen, inter alia, for failing to carry out a DPIA before implementing the Showbie application used to communicate with pupils’ parents. The application made it possible to transmit information about the health condition of children with disabilities, medication administered to them and their diagnoses. The authority emphasised that children’s personal data require special protection. It also pointed out that, had the data controller carried out a DPIA, it might have discovered that the Showbie application did not provide an adequate level of security when processing medical data (for example, two-factor authentication was not used).