When must a DPIA be carried out?

What Article 35 GDPR decides

Who carries out a DPIA

The obligation rests with the controller (Article 35(1)). The controller seeks the advice of the data protection officer, where designated (Article 35(2)). The officer provides advice where requested and monitors the performance of the assessment (Article 39(1)(c)). UODO stresses that the controller cannot hand the obligation over to the officer.

According to the guidelines, the assessment may be carried out by someone else, inside or outside the organisation. The controller nevertheless remains ultimately accountable. A processor is not the addressee of the obligation in Article 35(1). The data processing agreement obliges it to assist with the obligations in Articles 32 to 36, taking into account the nature of processing and the information available to it (Article 28(3)(f)). According to the guidelines, an impact assessment for a product such as hardware or software may be prepared by its provider. The controller deploying the product still carries out its own assessment for its specific implementation and may draw on the provider’s assessment.

Where joint controllers carry out the processing, according to the guidelines they should set out in the assessment which of them is responsible for the various measures. Where appropriate, the controller also seeks the views of data subjects or their representatives (Article 35(9)). This is without prejudice to the protection of commercial or public interests or the security of processing operations. According to the guidelines, the controller should document its justification for not seeking those views.

At what stage of a project

The assessment precedes the processing (Article 35(1)). The Article 29 Working Party guidelines (WP 248) endorsed by the European Data Protection Board (EDPB) state that the assessment should be started as early as is practicable in the design. According to the guidelines, the possibility of a later update does not justify postponing the assessment. Carrying out the assessment is a continual process, not a one-time exercise. Where necessary, the controller also carries out a review to assess whether the processing is performed in accordance with the assessment. The review is required at least when there is a change of the risk (Article 35(11)).

What weight the list and the guidelines carry

Article 35 GDPR is a legal provision. The list under Article 35(4) is established by the President of UODO. The list in force was published by a communication of 17 June 2019 in Monitor Polski (item 666). The list itself states that it does not release the controller from the analysis under Article 35(1) and that its examples are purely illustrative. The WP 248 guidelines do not create an obligation. They do, however, show how the EDPB and the supervisory authorities read the high-risk condition.

What has to be established before deciding on a DPIA

Whether the processing is new or changed

The first question concerns timing. New processing is assessed before it is launched. According to UODO, in practice the controller must always carry out a preliminary assessment of whether the planned operations are likely to result in a high risk.

According to the guidelines, an assessment may be required after a change of the risks of processing already under way. According to the guidelines, continuous review and regular re-assessment are good practice, so a controller whose processing did not require an assessment on 25 May 2018 will have to carry one out at the appropriate time as part of accountability. The guidelines give examples of a change of the risks. They include a new technology, use of data for a different purpose and a change in the organisational or societal context. Among other things, the change may concern functionalities, recipients and data combinations. It may also cover security measures and international transfers. A change may also reduce the risk. Where decisions are no longer automated, a review may show that an assessment is no longer required. Launching processing likely to result in a high risk without an assessment infringes Article 35(1). The assessment then has to be carried out. A later assessment does not remove the infringement, but it may end its duration. The supervisory authority takes the duration of the infringement into account when deciding on a fine and its amount (Article 83(2)(a)).

Whether a case under Article 35(3) applies

The three cases in Article 35(3) are preceded by the words “in particular”. Where one of them applies, an assessment is required. Where none applies, the obligation may still follow from Article 35(1) or from a specific provision. The UODO list under Article 35(4) specifies paragraph 1.

The first case is an evaluation of personal aspects which is systematic and extensive. The evaluation is based on automated processing, including profiling. Decisions that produce legal effects concerning the person or similarly significantly affect them are also based on it. However, the provision does not require the decision itself to be based solely on automated processing, as Article 22(1) does.

The non-final decision of the President of UODO DKN.5112.14.2022 of 18 December 2024 concerns a bank whose impact assessment for the credit assessment process did not single out the profiling of customers. According to the authority, Article 35(3)(a) did not directly oblige the bank to carry out an assessment, because the bank did not take decisions on granting credit in an automated way. The authority cited the WP 251 guidelines in this context, according to which the provision also covers decisions that are not fully automated. According to the authority, the catalogue in Article 35(3) is not closed, so the obligation to carry out an assessment may also follow from Article 35(1). In the authority’s view, profiling should be covered by an assessment if only because of its large scale and its scope, context and purposes. The authority found the lack of an impact assessment for profiling to be an infringement of Article 35(1) and (7). It added that a combined assessment of the whole process may as a rule be correct. This does not apply, however, to a process that includes such profiling. The authority also found that profiling was missing from the record of processing activities (Article 30(1)).

The second case concerns data referred to in Article 9(1) or data referred to in Article 10. Examples of the former are data concerning health, biometric data for the purpose of uniquely identifying a person and data revealing religious or philosophical beliefs. The latter relate to criminal convictions and offences. Scale is decisive. The GDPR does not define processing on a large scale. The guidelines point in particular to four factors — the number of data subjects, the volume of data, the duration of the processing and its geographical extent. For a hospital information system processing patients’ genetic and health data, the guidelines indicate a likely obligation to carry out an assessment. The criteria they list include large-scale processing. According to the guidelines, an assessment is not likely to be required for processing of personal data from patients or clients by an individual physician, other health care professional or lawyer. The guidelines nevertheless indicate two possible criteria for that processing. They do not assign the large-scale criterion to it.

The third case is systematic monitoring of a publicly accessible area on a large scale. The guidelines understand such areas as places open to any member of the public, such as a street, a shopping centre or a train station. According to the guidelines, the meanings of “systematic” include occurring according to a system, being pre-arranged and being carried out as part of a strategy.

How many criteria from the UODO list the processing meets

The list of the President of UODO sets out 12 criteria and types of operations.

1. Evaluation or assessment (including profiling and prediction) for purposes producing negative legal, physical or financial effects or other inconvenience for individuals.
2. Automated decision-making with legal, financial or similarly significant effects.
3. Systematic large-scale monitoring of publicly accessible areas with elements of recognising features or properties of objects.
4. Processing of special categories of data and data relating to criminal convictions and offences (sensitive data within the meaning of the Article 29 Working Party opinion).
5. Processing of biometric data solely for the purpose of identifying a person or for access control.
6. Processing of genetic data.
7. Processing of data on a large scale.
8. Comparing, evaluating or drawing inferences on the basis of data from different sources.
9. Processing data of persons whose assessment and services depend on entities with supervisory or evaluative powers.
10. Innovative use of technological or organisational solutions.
11. Processing which in itself prevents individuals from exercising a right or using a service or a contract.
12. Processing of location data.

According to the list, processing meeting at least two criteria as a rule requires a DPIA. In some cases the controller may consider that one is enough. The more criteria the processing meets, the more likely it is to present a high risk and therefore to require an assessment regardless of the planned measures.

For HR departments, healthcare providers and public administration, the guidelines’ criterion concerning vulnerable data subjects is important. According to the guidelines, vulnerable data subjects may include children, employees and patients because of the power imbalance between them and the controller. According to the guidelines, vulnerable data subjects may also include persons in any case where an imbalance between their position and that of the controller can be identified. In processing employees’ data this criterion may therefore be met. Where a second one applies, for example systematic monitoring or evaluation, according to the guidelines a DPIA is as a rule needed.

Criterion 3 has a reservation. It does not cover video surveillance in which footage is recorded and used only where incidents of infringement of the law need to be analysed. The reservation concerns the list criterion and does not change Article 35(3)(c). Systematic monitoring of a publicly accessible area on a large scale requires an assessment even where the footage is used only to analyse incidents of infringement of the law. UODO also recalls the EDPB position that it is reasonable to presume that an assessment is needed in many cases of video surveillance. The result therefore depends on the scale, systematic nature and purpose of the monitoring, not on the mere absence of image recognition.

Examples from the list, the UODO guide and the guidelines show how to count the criteria. The result in each row is an indication, and the decisive factor is the assessment of the specific processing under Article 35(1).

Processing	Criteria	Is a DPIA required?	Exceptions and limitations
Monitoring working time and employees’ use of e-mail and the internet	3 and 9 from the UODO list	yes — UODO example	the list mentions workplaces under criterion 3
Creditworthiness assessment using artificial intelligence algorithms and covered by an obligation of secrecy	1, 2, 4, 8, 9 and 11 from the UODO list	yes — UODO example	—
An artificial intelligence tool supporting diagnostic imaging in a hospital	4, 7 and 10 from the UODO list	yes — UODO example	—
Gathering public social media data to generate profiles	evaluation or scoring, large scale, matching or combining datasets and sensitive data or data of a highly personal nature (WP 248)	yes — example from the guidelines	—
Traffic management monitoring allowing detailed surveillance of a driver, for example with automatic vehicle identification	3 and 10 according to the UODO guide	yes — UODO example	—
A whistleblowing system in which employees’ data are processed	9 from the UODO list	depends on a second criterion	a second one may be criterion 4 where reports concern offences
A generic daily digest of an online magazine sent to subscribers	large scale (WP 248)	not likely — example from the guidelines	one criterion; the controller may nevertheless consider an assessment necessary

Whether the processing involves artificial intelligence

UODO indicates the criteria that a deployer of an artificial intelligence system should in particular take into account. They include criteria 1–3 and 7 and 8. Criteria 10 and 11 are added (the guide labels criterion 11 with the number 9). UODO also indicates that an assessment may be needed at different stages of developing and deploying the system. According to UODO, it may as a rule be assumed that processing data when developing and deploying high-risk artificial intelligence systems requires a DPIA. These are high-risk systems within the meaning of the Artificial Intelligence Act (Regulation 2024/1689). This is the authority’s position, not the wording of the provision. UODO also points out that the obligation to carry out an assessment may follow directly from separate provisions. As an example it gives Directive 2024/2831 on platform work, with a transposition deadline of 2 December 2026.

When a DPIA is not required

The first exception follows from Article 35(10). Paragraphs 1 to 7 do not apply where processing under Article 6(1)(c) or (e) has a legal basis in Union or Member State law. That law must regulate the specific processing operation or set of operations, and a data protection impact assessment must already have been carried out as part of a general impact assessment in the context of the adoption of that legal basis. The conditions must be met together, so the legal basis for processing alone is not enough. Even where the conditions are met, a Member State may deem an assessment prior to processing to be necessary. According to the guidelines, an assessment made at the legislative stage is likely to require a review before the processing starts. This is because the adopted provisions may differ from the proposal. In the context of Article 35(11), the guidelines note that Article 35(10) excludes only paragraphs 1 to 7. The review under paragraph 11 therefore also applies in this case.

The second case concerns similar operations. The obligation remains, but a single assessment may address similar processing operations that present similar high risks (Article 35(1)). According to the guidelines, a group of municipal authorities that are each setting up a similar CCTV system may carry out a single joint assessment. The guidelines allow the results of such an assessment to be used for other processing whose nature, scope, context and purposes are very similar. According to the guidelines, a joint assessment may cover several controllers. They then share or publish a reference assessment, implement the measures it describes and justify the choice of a single assessment.

Article 35(5) allows a supervisory authority to establish a list of operations for which no assessment is required, but does not oblige it to do so. The President of UODO has published only a list of operations requiring an assessment. No Polish list of exempt operations appears in the EDPB register either (as at 7 November 2026).

The UODO list and the guidelines recall that the controller still assesses risk and selects protective measures.

How to record a decision not to carry out a DPIA

The guidelines describe processing that meets the criteria although the controller does not see a high risk. The controller should then justify and document the reasons for not carrying out an assessment and record the views of the data protection officer. According to the guidelines, the controller assesses the likelihood of a high risk even where it ultimately does not carry out an assessment. Where there is doubt, the guidelines recommend carrying out an assessment.

What if a DPIA shows a high risk

The assessment contains at least a systematic description of the envisaged processing operations and purposes and an assessment of necessity and proportionality (Article 35(7)). It also includes an assessment of the risks to the rights and freedoms of data subjects and the measures envisaged to address the risks. Where the assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk, the controller consults the supervisory authority prior to processing (Article 36(1)). The guidelines read this provision as a situation in which the residual risk remains high despite the planned measures. They give examples of such risk. These include, among others, significant or irreversible consequences for individuals and a well-known vulnerability that is not patched.

Where the authority is of the opinion that the processing would infringe the GDPR, it provides written advice within up to eight weeks of receipt of the request. The period may be extended by six weeks, taking into account the complexity of the processing. The periods may also be suspended until the requested information has been obtained. The authority may also use any of its powers under Article 58 (Article 36(2)). Notwithstanding Article 36(1), Member State law may require controllers to consult the supervisory authority and obtain its prior authorisation for processing for the performance of a task carried out in the public interest (Article 36(5)).

How to build DPIA into projects and procurement

The obligation in Article 35(1) is easy to overlook because new processing is rarely called processing in an organisation. It is usually an IT project, the purchase of a cloud service, a new form or a change to an HR process. It may also be a service bought by a business unit without IT involvement or a new feature switched on in a tool the organisation already uses. I recommend building the preliminary assessment into the project, procurement and process-change workflow before the organisation chooses a provider or approves the project.

A short form completed by the process owner works well. It describes the data, the persons, the purpose and the technology. It also indicates the provider and the place of processing. It records the cases in Article 35(3), the criteria from the UODO list and the event that will trigger a review. The data protection officer gives an opinion on it. The person responsible for the process decides on behalf of the controller whether a full assessment is needed. According to the guidelines, the officer’s advice and the decisions taken by the controller should be documented within the impact assessment. It is worth linking the form to the record of processing activities (Article 30(1)). In a request for proposals it is worth requiring the provider to hand over its product assessment if it has one.

A full assessment involves the process owner, the officer and the IT security team. Its cost is mainly their time to describe data flows, analyse risk and select measures. Prior consultation adds the authority’s period under Article 36(2). It is worth making a completed assessment and any prior consultation a milestone before the first use of real data, including in tests.

Conclusions and next steps

The DPIA obligation follows from the likelihood of a high risk or from a specific provision, not from the type or size of the organisation alone.

1. Add a preliminary assessment step to the project, procurement and process-change workflow before choosing a provider or approving a project.
2. Check the cases in Article 35(3) and count the criteria from the UODO list.
3. Where in doubt, carry out an assessment.
4. Single out in the assessment every operation that triggers the obligation, including profiling.
5. Set the events after which the assessment is reviewed — a new technology, a new purpose and a change of context. Check assessments periodically when reviewing the record of processing activities.
6. Where according to the assessment the residual risk remains high, plan prior consultation with the supervisory authority before launch.

Related materials

• How to approve an AI assistant for work in an organisation? — impact assessment for artificial intelligence tools.
• What must a personal data processing agreement contain? — the processor’s assistance with impact assessments.
• What information should the board expect from the DPO? — division of roles between the controller and the officer.
• Is the AI tool we use a high-risk system? — classifying an AI use case and profiling.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), consolidated version — Article 6(1)(c) and (e), Article 9(1), Article 10, Article 22(1), Article 28(3)(f), Article 30(1), Article 35, Article 36(1), (2) and (5), Article 39(1)(c), Article 58 (including paragraph 2(f)) and Article 83(2)(a) and (4)(a) — eur-lex.europa.eu.
• Communication of the President of the Personal Data Protection Office of 17 June 2019 on the list of kinds of processing operations requiring a data protection impact assessment (Monitor Polski 2019, item 666) (in Polish) — monitorpolski.gov.pl.
• Article 29 Working Party, 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 (WP 248 rev.01), endorsed by the EDPB — ec.europa.eu.
• Personal Data Protection Office (UODO), “When must a data protection impact assessment be carried out?”, guide of 31 March 2025 (in Polish) — uodo.gov.pl.
• Decision of the President of the Personal Data Protection Office DKN.5112.14.2022 of 18 December 2024 (not final) — UODO case-law database (in Polish) — orzeczenia.uodo.gov.pl.
• European Data Protection Board, register of lists of processing operations for data protection impact assessments (Article 35(4) and (5) GDPR) — edpb.europa.eu.