Article 35 GDPR: Difference between revisions

From GDPRhub
 
(6 intermediate revisions by one other user not shown)
Line 307: Line 307:
As per Article 35(1), the responsibility for conducting a DPIA lies with the controller, rather than the DPO. However, the DPO can play a crucial and valuable role in supporting the controller. In line with the principle of data protection by design, Article 35(2) explicitly states that the controller "''shall seek advice''" from the DPO when performing a DPIA.<ref>In fact, where an obligation to carry out a DPIA exists, the designated DPO ''has to be'' involved in the procedure, and the controller should consult them for their advice. ''Jandt'', in Kühling, Buchner, DS-GVO BDSG, Article 35 GDPR, margin number 18 (C.H. Beck 2020, 3rd Edition). Furthermore, Article 39(1)(c) assigns the duty to the DPO to "p''rovide advice where requested regarding the [DPIA] and monitor its performance pursuant to Article 35.''"</ref> This includes but is not limited to<ref>Article 39(1) mentions the tasks of the DPO and indicates that the DPO shall have ‘at least’ the following tasks. Therefore, nothing prevents the controller from assigning the DPO other tasks than those explicitly mentioned in Article 39(1), or specifying those tasks in more detail.</ref> determining whether a DPIA is necessary, selecting the appropriate methodology for conducting the assessment, deciding whether to perform it internally or outsource it, identifying safeguards to mitigate risks to data subjects' rights and interests, and ensuring the correct execution of the DPIA in compliance with the GDPR. The DPO's input is valuable in ensuring the effectiveness and accuracy of the DPIA process.<ref>WP29, ‘Guidelines on Data Protection Officers (‘DPOs’)’, 16/EN WP 243 rev.01, 5 April 2017, p. 8 (available [https://ec.europa.eu/newsroom/article29/items/612048 here]).</ref> The DPO involvement should be documented in writing in order to demonstrate that the advice has been sought. Although the controller is not obliged to follow the DPO’s opinion it should motivate and document its reasons if it chooses not to.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 23 (C.H. Beck 2021, 39th edition).</ref>   
As per Article 35(1), the responsibility for conducting a DPIA lies with the controller, rather than the DPO. However, the DPO can play a crucial and valuable role in supporting the controller. In line with the principle of data protection by design, Article 35(2) explicitly states that the controller "''shall seek advice''" from the DPO when performing a DPIA.<ref>In fact, where an obligation to carry out a DPIA exists, the designated DPO ''has to be'' involved in the procedure, and the controller should consult them for their advice. ''Jandt'', in Kühling, Buchner, DS-GVO BDSG, Article 35 GDPR, margin number 18 (C.H. Beck 2020, 3rd Edition). Furthermore, Article 39(1)(c) assigns the duty to the DPO to "p''rovide advice where requested regarding the [DPIA] and monitor its performance pursuant to Article 35.''"</ref> This includes but is not limited to<ref>Article 39(1) mentions the tasks of the DPO and indicates that the DPO shall have ‘at least’ the following tasks. Therefore, nothing prevents the controller from assigning the DPO other tasks than those explicitly mentioned in Article 39(1), or specifying those tasks in more detail.</ref> determining whether a DPIA is necessary, selecting the appropriate methodology for conducting the assessment, deciding whether to perform it internally or outsource it, identifying safeguards to mitigate risks to data subjects' rights and interests, and ensuring the correct execution of the DPIA in compliance with the GDPR. The DPO's input is valuable in ensuring the effectiveness and accuracy of the DPIA process.<ref>WP29, ‘Guidelines on Data Protection Officers (‘DPOs’)’, 16/EN WP 243 rev.01, 5 April 2017, p. 8 (available [https://ec.europa.eu/newsroom/article29/items/612048 here]).</ref> The DPO involvement should be documented in writing in order to demonstrate that the advice has been sought. Although the controller is not obliged to follow the DPO’s opinion it should motivate and document its reasons if it chooses not to.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 23 (C.H. Beck 2021, 39th edition).</ref>   


=== (3) Likely to Result in a High Risk ===
=== (3) Likely to result in a high risk ===
The structure of Article 35 may not provide clear guidance on its own. As previously discussed, paragraph 1 states that a DPIA is always required when processing operations are likely to pose a high risk to data subjects. Based on these general indications, the WP29 has developed a list of criteria to assess such likelyhood of risks (see above, ''If the processing is likely to result in a high risk for the rights and freedoms of natural persons'') and provided guidance for conducting the impact assessment in the absence of specific instructions (see above, ''Shall carry out a DPIA''). The three cases for which a DPIA is always required include: (a) conducting a systematic and extensive evaluation of personal aspects<ref>Evaluation or scoring, including profiling and predicting, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (recitals 71 and 91). Examples of this could include a financial institution that screens its customers against a credit reference database or against an anti-money laundering and counter-terrorist financing (AML/CTF) or fraud database, or a biotechnology company offering genetic tests directly to consumers in order to assess and predict the disease/health risks, or a company building behavioural or marketing profiles based on usage or navigation on its website.</ref> through automated processing, which leads to legal effects or significantly impacts individuals;<ref>Automated-decision making with legal or similar significant effect: processing that aims at taking decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person” (Article 35(3)(a)). For example, the processing may lead to the exclusion or discrimination against individuals. Processing with little or no effect on individuals does not match this specific criterion. </ref> (b) processing special categories of data or personal data related to criminal convictions and offenses<ref>Sensitive data or data of a highly personal nature: this includes special categories of personal data as defined in Article 9 (for example information about individuals’ political opinions), as well as personal data relating to criminal convictions or offences as defined in Article 10. An example would be a general hospital keeping patients’ medical records or a private investigator keeping offenders’ details. Beyond these provisions of the GDPR, some categories of data can be considered as increasing the possible risk to the rights and freedoms of individuals. These personal data are considered as sensitive (as this term is commonly understood) because they are linked to household and private activities (such as electronic communications whose confidentiality should be protected), or because they impact the exercise of a fundamental right (such as location data whose collection questions the freedom of movement) or because their violation clearly involves serious impacts in the data subject’s daily life (such as financial data that might be used for payment fraud). In this regard, whether the data has already been made publicly available by the data subject or by third parties may be relevant. The fact that personal data is publicly available may be considered as a factor in the assessment if the data was expected to be further used for certain purposes. This criterion may also include data such as personal documents, emails, diaries, notes from e-readers equipped with note-taking features, and very personal information contained in life-logging applications.</ref> on a large scale;<ref>Data processed on a large scale: the GDPR does not define what constitutes large-scale, though recital 91 provides some guidance. In any event, the WP29 recommends that the following factors, in particular, be considered when determining whether the processing is carried out on a large scale: a. the number of data subjects concerned, either as a specific number or as a proportion of the relevant population; b. the volume of data and/or the range of different data items being processed; c. the duration, or permanence, of the data processing activity; d. the geographical extent of the processing activity.</ref> and (c) systematically monitoring a publicly accessible area on a large scale.<ref>Systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through networks or “a systematic monitoring of a publicly accessible area” (Article 35(3)(c))15. This type of monitoring is a criterion because the personal data may be collected in circumstances where data subjects may not be aware of who is collecting their data and how they will be used. Additionally, it may be impossible for individuals to avoid being subject to such processing in public (or publicly accessible) space(s).</ref> In these situations, a DPIA is necessary to assess and mitigate the potential risks to individuals' rights and freedoms. As evident, many of the typical elements of processing mentioned in Article 35(3) (such as extensive evaluation of personal data, automated decision-making, special categories of data, large-scale processing) are also utilized by the WP29 as risk assessment criteria mentioned in paragraph 1. In other words, the examples provided in paragraph 3 are helpful in understanding the relevant risk indicators for the GDPR, which are broader.
The structure of Article 35 may not provide clear guidance on its own. As previously discussed, paragraph 1 states that a DPIA is always required when processing operations are likely to pose a high risk to data subjects. Based on these general indications, the WP29 has developed a list of criteria to assess such likelyhood of risks (see above, ''If the processing is likely to result in a high risk for the rights and freedoms of natural persons'') and provided guidance for conducting the impact assessment in the absence of specific instructions (see above, ''Shall carry out a DPIA''). The three cases for which a DPIA is always required include: (a) conducting a systematic and extensive evaluation of personal aspects<ref>Evaluation or scoring, including profiling and predicting, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (recitals 71 and 91). Examples of this could include a financial institution that screens its customers against a credit reference database or against an anti-money laundering and counter-terrorist financing (AML/CTF) or fraud database, or a biotechnology company offering genetic tests directly to consumers in order to assess and predict the disease/health risks, or a company building behavioural or marketing profiles based on usage or navigation on its website.</ref> through automated processing, which leads to legal effects or significantly impacts individuals;<ref>Automated-decision making with legal or similar significant effect: processing that aims at taking decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person” (Article 35(3)(a)). For example, the processing may lead to the exclusion or discrimination against individuals. Processing with little or no effect on individuals does not match this specific criterion. </ref> (b) processing special categories of data or personal data related to criminal convictions and offenses<ref>Sensitive data or data of a highly personal nature: this includes special categories of personal data as defined in Article 9 (for example information about individuals’ political opinions), as well as personal data relating to criminal convictions or offences as defined in Article 10. An example would be a general hospital keeping patients’ medical records or a private investigator keeping offenders’ details. Beyond these provisions of the GDPR, some categories of data can be considered as increasing the possible risk to the rights and freedoms of individuals. These personal data are considered as sensitive (as this term is commonly understood) because they are linked to household and private activities (such as electronic communications whose confidentiality should be protected), or because they impact the exercise of a fundamental right (such as location data whose collection questions the freedom of movement) or because their violation clearly involves serious impacts in the data subject’s daily life (such as financial data that might be used for payment fraud). In this regard, whether the data has already been made publicly available by the data subject or by third parties may be relevant. The fact that personal data is publicly available may be considered as a factor in the assessment if the data was expected to be further used for certain purposes. This criterion may also include data such as personal documents, emails, diaries, notes from e-readers equipped with note-taking features, and very personal information contained in life-logging applications.</ref> on a large scale;<ref>Data processed on a large scale: the GDPR does not define what constitutes large-scale, though recital 91 provides some guidance. In any event, the WP29 recommends that the following factors, in particular, be considered when determining whether the processing is carried out on a large scale: a. the number of data subjects concerned, either as a specific number or as a proportion of the relevant population; b. the volume of data and/or the range of different data items being processed; c. the duration, or permanence, of the data processing activity; d. the geographical extent of the processing activity.</ref> and (c) systematically monitoring a publicly accessible area on a large scale.<ref>Systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through networks or “a systematic monitoring of a publicly accessible area” (Article 35(3)(c))15. This type of monitoring is a criterion because the personal data may be collected in circumstances where data subjects may not be aware of who is collecting their data and how they will be used. Additionally, it may be impossible for individuals to avoid being subject to such processing in public (or publicly accessible) space(s).</ref> In these situations, a DPIA is necessary to assess and mitigate the potential risks to individuals' rights and freedoms. As evident, many of the typical elements of processing mentioned in Article 35(3) (such as extensive evaluation of personal data, automated decision-making, special categories of data, large-scale processing) are also utilized by the WP29 as risk assessment criteria mentioned in paragraph 1. In other words, the examples provided in paragraph 3 are helpful in understanding the relevant risk indicators for the GDPR, which are broader.


Line 316: Line 316:
Where the lists referred to in paragraphs 4 and 5 involve processing activities which on the one hand are related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or on the other hand may substantially affect the free movement of personal data within the Union, the competent DPA shall communicate them to the EDPB and apply the consistency mechanism referred to in [[Article 63 GDPR]].   
Where the lists referred to in paragraphs 4 and 5 involve processing activities which on the one hand are related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or on the other hand may substantially affect the free movement of personal data within the Union, the competent DPA shall communicate them to the EDPB and apply the consistency mechanism referred to in [[Article 63 GDPR]].   


=== (7) DPIA Minimum Requirements ===
=== (7) DPIA minimum requirements ===
Article 35(7) GDPR sets out a list of minimum requirements which shall be dealt with in the DPIA. To begin with, under Article 35(7)(a) GDPR, the assessment must provide a systematic description of the envisaged processing operations and its purposes. In practice, this first step includes the description of the data flow and the systematic indication of the legal basis of the processing, including any legitimate interests pursued by the controller. In accordance with Article 35(7)(b) GDPR, the assessment will then have to ponder and explain the necessity and proportionality of each processing with regard to each purpose pursued. The controller shall explain for which reason a processing, or a set of processing activities, is necessary to pursue a specific purpose. In doing so, it also has to justify why other less intrusive processing is not suitable for the purpose.   
Article 35(7) GDPR sets out a list of minimum requirements which shall be dealt with in the DPIA. To begin with, under Article 35(7)(a) GDPR, the assessment must provide a systematic description of the envisaged processing operations and its purposes. In practice, this first step includes the description of the data flow and the systematic indication of the legal basis of the processing, including any legitimate interests pursued by the controller. In accordance with Article 35(7)(b) GDPR, the assessment will then have to ponder and explain the necessity and proportionality of each processing with regard to each purpose pursued. The controller shall explain for which reason a processing, or a set of processing activities, is necessary to pursue a specific purpose. In doing so, it also has to justify why other less intrusive processing is not suitable for the purpose.   


Line 323: Line 323:
Under Article 35(7)(d) GDPR, the DPIA must include the appropriate measures the controller has adopted to mitigate potential risks. These measures may be technical or organisational in nature, including legal safeguards arising from contracts or other legal sources. The controller shall then apply these measures to the previously identified risks and verify the extent to which they contribute to risk reduction. This makes it possible to calculate the aforementioned 'residual risk'.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 49 (C.H. Beck 2021, 39th edition).</ref> The DPIA must be documented, otherwise the controller would not be able to "systematically describe" the envisaged processing (Article 35(7)(a) GDPR) or share the assessment with the data protection authority under [[Article 36 GDPR]]. In general, the written form is the only way to provide proof of compliance. The GDPR does not explicitly require the publication of the assessment. However, in the interest of transparency towards data subjects, the essential parts of the DPIA can and should be published, or at least made available to the interested parties.<ref>WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 18 (available [https://www.pdpjournals.com/docs/887932.pdf here]).</ref>  
Under Article 35(7)(d) GDPR, the DPIA must include the appropriate measures the controller has adopted to mitigate potential risks. These measures may be technical or organisational in nature, including legal safeguards arising from contracts or other legal sources. The controller shall then apply these measures to the previously identified risks and verify the extent to which they contribute to risk reduction. This makes it possible to calculate the aforementioned 'residual risk'.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 49 (C.H. Beck 2021, 39th edition).</ref> The DPIA must be documented, otherwise the controller would not be able to "systematically describe" the envisaged processing (Article 35(7)(a) GDPR) or share the assessment with the data protection authority under [[Article 36 GDPR]]. In general, the written form is the only way to provide proof of compliance. The GDPR does not explicitly require the publication of the assessment. However, in the interest of transparency towards data subjects, the essential parts of the DPIA can and should be published, or at least made available to the interested parties.<ref>WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 18 (available [https://www.pdpjournals.com/docs/887932.pdf here]).</ref>  


Finally, Article 35(7) GDPR does not provide specific guidance on the structure, content and methodology the DPIA should follow. Nevertheless, in order to facilitate the controller's task, some DPAs have provided DPIA templates.<ref>The French DPA (CNIL) provides specific guidance as well as a software for carrying out an impact assessment ([https://www.cnil.fr/en/privacy-impact-assessment-pia here]). The Belgian DPA (APD/GBA) provides a recommendation on data protection impact assessment ([https://www.autoriteprotectiondonnees.be/publications/recommandation-n-01-2018.pdf here]). The Spanish DPA (AEPD) has also published similar guidance on its website ([https://www.aepd.es/es/documento/gestion-riesgo-y-evaluacion-impacto-en-tratamientos-datos-personales.pdf here]).</ref> Although there is no obligation to use any of these models, they may serve as useful methodological or content related guides.
Finally, Article 35(7) GDPR does not provide specific guidance on the structure, content and methodology the DPIA should follow. Nevertheless, in order to facilitate the controller's task, some DPAs have provided DPIA templates.<ref>The French DPA (CNIL) provides specific guidance as well as a software for carrying out an impact assessment ([https://www.cnil.fr/en/privacy-impact-assessment-pia here]). The Belgian DPA (APD/GBA) provides a recommendation on data protection impact assessment ([https://www.autoriteprotectiondonnees.be/publications/recommandation-n-01-2018.pdf here]). The Spanish DPA (AEPD) has also published similar guidance on its website ([https://www.aepd.es/es/documento/gestion-riesgo-y-evaluacion-impacto-en-tratamientos-datos-personales.pdf here]).</ref> Although there is no obligation to use any of these models, they may serve as useful methodological or content related guides. It is worth noticing that the choice of measures mitigating risks could in practice lead the controller to change the nature of the processing operations. In this case, it is reasonable to argue that the controller should perform all the steps described in paragraph (7) again, as the new processing is substantially different from the one originally envisaged.
=== (8) Codes of conduct ===
=== (8) Codes of conduct ===
Compliance with approved codes of conduct referred to in [[Article 40 GDPR]] shall be taken into due account in assessing the impact of the processing operations performed by the relevant controllers or processors, in particular for the purposes of a DPIA. Although adhering to an approved code of conduct does not automatically guarantee sufficient risk reduction for processing activities in specific cases, it does, however, make it significantly easier to conduct a DPIA and demonstrate compliance with GDPR.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 59 (C.H. Beck 2021, 39th edition).</ref>   
Compliance with approved codes of conduct referred to in [[Article 40 GDPR]] shall be taken into due account in assessing the impact of the processing operations performed by the relevant controllers or processors, in particular for the purposes of a DPIA. Although adhering to an approved code of conduct does not automatically guarantee sufficient risk reduction for processing activities in specific cases, it does, however, make it significantly easier to conduct a DPIA and demonstrate compliance with GDPR.<ref>''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 59 (C.H. Beck 2021, 39th edition).</ref>   


=== (9) Data subjects involvement in the drafting of the DPIA ===
=== (9) Data subjects involvement in the drafting of the DPIA ===
Under Article 35(9) GDPR, the controller, “''where appropriate''” may “''seek the views of data subjects or their representatives on the intended processing''”.<ref>These can be, for example, works and staff councils, trade unions, consumer protection associations or civil society groups. Unless there is an obligation to participate due to other legal norms, it is left to the controller to take care of the data subjects' views. See, ''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 61 (C.H. Beck 2021, 39th edition).</ref> This will be instrumental in order to increase the transparency of the processing and the involvement of (potential) data subjects in the assessment of of the processing. Whether this is an obligatory or voluntary step is not entirely clear. Some authors focus on one part of the text ('<nowiki/>''where appropriate''<nowiki/>') and conclude that it is merely an option.<ref>''Baumgartner'' in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 35 GDPR, margin numbers 70-71 (C.H. Beck 2018, 2nd Edition).</ref> This view, however, does not seem conclusive. The case, in fact, provides that '<nowiki/>''where appropriate''<nowiki/>' the controller '''shall''<nowiki/>' seek the data subject's advice. Unlike ‘''may''’ or ‘''can''’, ‘''shall''’ implies an obligation Accordingly, the controller must give precise reasons as to whether the consultation is appropriate or not. The same effort seems to be required in case the controller does involve the data subjects, but then decides to override their input.
Under Article 35(9) GDPR, the controller, “''where appropriate''” may “''seek the views of data subjects or their representatives on the intended processing''”.<ref>These can be, for example, works and staff councils, trade unions, consumer protection associations or civil society groups. Unless there is an obligation to participate due to other legal norms, it is left to the controller to take care of the data subjects' views. See, ''Hansen,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 61 (C.H. Beck 2021, 39th edition).</ref> This will be instrumental in order to increase the transparency of the processing and the involvement of (potential) data subjects in the assessment of of the processing. Whether this is an obligatory or voluntary step is not entirely clear. Some authors focus on one part of the text ("''where appropriate")'' and conclude that it is merely an option.<ref>''Baumgartner'' in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 35 GDPR, margin numbers 70-71 (C.H. Beck 2018, 2nd Edition).</ref> This view, however, does not seem conclusive. The case, in fact, provides that where appropriate' the controller '''shall''<nowiki/>' seek the data subject's advice. Unlike ‘''may''’ or ‘''can''’, ‘''shall''’ implies an obligation Accordingly, the controller must give precise reasons as to whether the consultation is appropriate or not. The same effort seems to be required in case the controller does involve the data subjects, but then decides not to follow their input. Practical examples of implementation of pargraph (9) are the involvement of a works council or the sending of a survey to customers.


=== (10) National exemptions ===
=== (10) National exemptions ===

Latest revision as of 08:05, 18 July 2023

← Article 35 - Data protection impact assessment →
Gdpricon.png
Chapter 1: General provisions

Article 1: Subject-matter and objectives
Article 2: Material scope
Article 3: Territorial scope
Article 4: Definitions

Chapter 2: Principles

Article 5: Principles relating to processing of personal data
Article 6: Lawfulness of processing
Article 7: Conditions for consent
Article 8: Conditions applicable to child’s consent in relation to information society services
Article 9: Processing of special categories of personal data
Article 10: Processing of personal data relating to criminal convictions and offences
Article 11: Processing which does not require identification

Chapter 3: Rights of the data subject

Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject
Article 13: Information to be provided where personal data are collected from the data subject
Article 14: Information to be provided where personal data have not been obtained from the data subject
Article 15: Right of access by the data subject
Article 16: Right to rectification
Article 17: Right to erasure (‘right to be forgotten’)
Article 18: Right to restriction of processing
Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing
Article 20: Right to data portability
Article 21: Right to object
Article 22: Automated individual decision-making, including profiling
Article 23: Restrictions

Chapter 4: Controller and processor

Article 24: Responsibility of the controller
Article 25: Data protection by design and by default
Article 26: Joint controllers
Article 27: Representatives of controllers or processors not established in the Union
Article 28: Processor
Article 29: Processing under the authority of the controller or processor
Article 30: Records of processing activities
Article 31: Cooperation with the supervisory authority
Article 32: Security of processing
Article 33: Notification of a personal data breach to the supervisory authority
Article 34: Communication of a personal data breach to the data subject
Article 35: Data protection impact assessment
Article 36: Prior consultation
Article 37: Designation of the data protection officer
Article 38: Position of the data protection officer
Article 39: Tasks of the data protection officer
Article 40: Codes of conduct
Article 41: Monitoring of approved codes of conduct
Article 42: Certification
Article 43: Certification bodies

Chapter 5: Transfers of personal data

Article 44: General principle for transfers
Article 45: Transfers on the basis of an adequacy decision
Article 46: Transfers subject to appropriate safeguards
Article 47: Binding corporate rules
Article 48: Transfers or disclosures not authorised by Union law
Article 49: Derogations for specific situations
Article 50: International cooperation for the protection of personal data

Chapter 6: Supervisory authorities

Article 51: Supervisory authority
Article 52: Independence
Article 53: General conditions for the members of the supervisory authority
Article 54: Rules on the establishment of the supervisory authority
Article 55: Competence
Article 56: Competence of the lead supervisory authority
Article 57: Tasks
Article 58: Powers
Article 59: Activity reports

Chapter 7: Cooperation and consistency

Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned
Article 61: Mutual assistance
Article 62: Joint operations of supervisory authorities
Article 63: Consistency mechanism
Article 64: Opinion of the Board
Article 65: Dispute resolution by the Board
Article 66: Urgency procedure
Article 67: Exchange of information
Article 68: European Data Protection Board
Article 69: Independence
Article 70: Tasks of the Board
Article 71: Reports
Article 72: Procedure
Article 73: Chair
Article 74: Tasks of the Chair
Article 75: Secretariat
Article 76: Confidentiality

Chapter 8: Remedies, liability and penalties

Article 77: Right to lodge a complaint with a supervisory authority
Article 78: Right to an effective judicial remedy against a supervisory authority
Article 79: Right to an effective judicial remedy against a controller or processor
Article 80: Representation of data subjects
Article 81: Suspension of proceedings
Article 82: Right to compensation and liability
Article 83: General conditions for imposing administrative fines
Article 84: Penalties

Chapter 9: Specific processing situations

Article 85: Processing and freedom of expression and information
Article 86: Processing and public access to official documents
Article 87: Processing of the national identification number
Article 88: Processing in the context of employment
Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes
Article 90: Obligations of secrecy
Article 91: Existing data protection rules of churches and religious associations

Chapter 10: Delegated and implementing acts

Article 92: Exercise of the delegation
Article 93: Committee procedure

Chapter 11: Final provisions

Article 94: Repeal of Directive 95: /46: /EC
Article 95: Relationship with Directive 20: 02: /58: /EC
Article 96: Relationship with previously concluded Agreements
Article 97: Commission reports
Article 98: Review of other Union legal acts on data protection
Article 99: Entry into force and application

Legal Text


Article 35 - Data protection impact assessment

1. Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.

2. The controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment.

3. A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of:

(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person;
(b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or
(c) a systematic monitoring of a publicly accessible area on a large scale.

4. The supervisory authority shall establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment pursuant to paragraph 1. The supervisory authority shall communicate those lists to the Board referred to in Article 68.

5. The supervisory authority may also establish and make public a list of the kind of processing operations for which no data protection impact assessment is required. The supervisory authority shall communicate those lists to the Board.

6. Prior to the adoption of the lists referred to in paragraphs 4 and 5, the competent supervisory authority shall apply the consistency mechanism referred to in Article 63 where such lists involve processing activities which are related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or may substantially affect the free movement of personal data within the Union.

7. The assessment shall contain at least:

(a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
(c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; and
(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.

8. Compliance with approved codes of conduct referred to in Article 40 by the relevant controllers or processors shall be taken into due account in assessing the impact of the processing operations performed by such controllers or processors, in particular for the purposes of a data protection impact assessment.

9. Where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of processing operations.

10. Where processing pursuant to point (c) or (e) of Article 6(1) has a legal basis in Union law or in the law of the Member State to which the controller is subject, that law regulates the specific processing operation or set of operations in question, and a data protection impact assessment has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis, paragraphs 1 to 7 shall not apply unless Member States deem it to be necessary to carry out such an assessment prior to processing activities.

11. Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.

Relevant Recitals

Recital 75: Risks to the Rights and Freedoms of Natural Persons
The risk to the rights and freedoms of natural persons, of varying likelihood and severity, may result from personal data processing which could lead to physical, material or non-material damage, in particular: where the processing may give rise to discrimination, identity theft or fraud, financial loss, damage to the reputation, loss of confidentiality of personal data protected by professional secrecy, unauthorised reversal of pseudonymisation, or any other significant economic or social disadvantage; where data subjects might be deprived of their rights and freedoms or prevented from exercising control over their personal data; where personal data are processed which reveal racial or ethnic origin, political opinions, religion or philosophical beliefs, trade union membership, and the processing of genetic data, data concerning health or data concerning sex life or criminal convictions and offences or related security measures; where personal aspects are evaluated, in particular analysing or predicting aspects concerning performance at work, economic situation, health, personal preferences or interests, reliability or behaviour, location or movements, in order to create or use personal profiles; where personal data of vulnerable natural persons, in particular of children, are processed; or where processing involves a large amount of personal data and affects a large number of data subjects.

Recital 84: Data Protection Impact Assessment
In order to enhance compliance with this Regulation where processing operations are likely to result in a high risk to the rights and freedoms of natural persons, the controller should be responsible for the carrying-out of a data protection impact assessment to evaluate, in particular, the origin, nature, particularity and severity of that risk. The outcome of the assessment should be taken into account when determining the appropriate measures to be taken in order to demonstrate that the processing of personal data complies with this Regulation. Where a data-protection impact assessment indicates that processing operations involve a high risk which the controller cannot mitigate by appropriate measures in terms of available technology and costs of implementation, a consultation of the supervisory authority should take place prior to the processing.

Recital 89: Abolishment of Indiscriminate General Notification
Directive 95/46/EC provided for a general obligation to notify the processing of personal data to the supervisory authorities. While that obligation produces administrative and financial burdens, it did not in all cases contribute to improving the protection of personal data. Such indiscriminate general notification obligations should therefore be abolished, and replaced by effective procedures and mechanisms which focus instead on those types of processing operations which are likely to result in a high risk to the rights and freedoms of natural persons by virtue of their nature, scope, context and purposes. Such types of processing operations may be those which in, particular, involve using new technologies, or are of a new kind and where no data protection impact assessment has been carried out before by the controller, or where they become necessary in the light of the time that has elapsed since the initial processing.

Recital 90: Impact Assessment Modalities and Scope
In such cases, a data protection impact assessment should be carried out by the controller prior to the processing in order to assess the particular likelihood and severity of the high risk, taking into account the nature, scope, context and purposes of the processing and the sources of the risk. That impact assessment should include, in particular, the measures, safeguards and mechanisms envisaged for mitigating that risk, ensuring the protection of personal data and demonstrating compliance with this Regulation.

Recital 91: Conditions Necessitating an Impact Assessment
This should in particular apply to large-scale processing operations which aim to process a considerable amount of personal data at regional, national or supranational level and which could affect a large number of data subjects and which are likely to result in a high risk, for example, on account of their sensitivity, where in accordance with the achieved state of technological knowledge a new technology is used on a large scale as well as to other processing operations which result in a high risk to the rights and freedoms of data subjects, in particular where those operations render it more difficult for data subjects to exercise their rights. A data protection impact assessment should also be made where personal data are processed for taking decisions regarding specific natural persons following any systematic and extensive evaluation of personal aspects relating to natural persons based on profiling those data or following the processing of special categories of personal data, biometric data, or data on criminal convictions and offences or related security measures. A data protection impact assessment is equally required for monitoring publicly accessible areas on a large scale, especially when using optic-electronic devices or for any other operations where the competent supervisory authority considers that the processing is likely to result in a high risk to the rights and freedoms of data subjects, in particular because they prevent data subjects from exercising a right or using a service or a contract, or because they are carried out systematically on a large scale. The processing of personal data should not be considered to be on a large scale if the processing concerns personal data from patients or clients by an individual physician, other health care professional or lawyer. In such cases, a data protection impact assessment should not be mandatory.

Recital 92: Broader Data Protection Impact Assessments
There are circumstances under which it may be reasonable and economical for the subject of a data protection impact assessment to be broader than a single project, for example where public authorities or bodies intend to establish a common application or processing platform or where several controllers plan to introduce a common application or processing environment across an industry sector or segment or for a widely used horizontal activity.

Recital 93: Data Protection Impact at Public Authorties and Bodies
In the context of the adoption of the Member State law on which the performance of the tasks of the public authority or public body is based and which regulates the specific processing operation or set of operations in question, Member States may deem it necessary to carry out such assessment prior to the processing activities.

Commentary

Article 35 requires the controller to carry out a Data Protection Impact Assessment (DPIA) when a certain processing operation (or a set of operations with similar characteristics) presents a high risk to the rights and freedoms of natural persons. The DPIA is one of the most innovative elements in the GDPR related to the accountability principle (see Articles 5(2) and 24 GDPR). This provision regulates the cases in which a DPIA is mandatory, what its minimum content is, and other procedural aspects related to carrying out the analysis it entails.

EDPB Guidelines: on this Article, please see Data Protection Impact Assessments High-Risk Processing

(1) Mandatory DPIA

A data protection impact assessment is necessary whenever controllers intend to conduct processing activities that are likely to result in a high risk to the rights and freedoms of data subjects. This requirement becomes particularly relevant in situations involving the use of new or innovative technologies, for which no previous data protection impact assessment has been conducted or when the existing assessment was performed some time ago, necessitating a fresh evaluation (Recital 89 of the GDPR).

The controller

It is the controller’s responsibility to perform a DPIA. Processors and device manufacturers are therefore not responsible for carrying out this analysis.[1] However, under Article 28(3)(f) GDPR, the processor shall assist the controller by providing any information available to them. The Data Protection Officer (DPO) must also be involved in the drafting of the DPIA under Article 35(2) GDPR and Article 39(1)(c) GDPR, and their advice should be recorded by the controller. Data subjects can also be involved in the preparation of the document, as stipulated by Article 35(9) GDPR.

If the processing is likely to result in a high risk for the rights and freedoms of natural persons

Performing a DPIA is not obligatory for every processing operation that may pose risks to the rights and freedoms of individuals. The requirement for a DPIA arises only when the processing is expected to lead to a "high risk"[2] to the "rights and freedoms of individuals"[3], as stated in Article 35(1) and further elucidated in Article 35(3)[4] and Article 35(4) GDPR. The WP29 developed a list of criteria for assessing the high risk involved in certain types of processing, including, among others:

  • the existence of assessment or scoring operations,
  • the presence of automated decision-making,
  • systematic monitoring,
  • the use of special categories of data,
  • the existence of large-scale data processing,
  • matching operations between different databases,
  • personal data relating to vulnerable individuals,
  • the use of new technologies,
  • the fact that the processing may inhibit the data subject from either exercising their rights, or using a particular service.

In the WP29’s view, regardless of the mitigating measures which a controller may adopt, as more of these criteria are met, it will be more likely that the processing will present a high risk for data subjects’ rights and freedoms, and thus require a DPIA. However, "in some cases, a data controller can consider that a processing meeting only one of these criteria requires a DPIA". Conversely, a processing operation may correspond to the aforementioned cases and still be considered by the controller not to be “likely to result in a high risk”. In such cases "the controller should justify and document the reasons for not carrying out a DPIA". However, according to the WP29, in most cases, the meeting of two criteria would suffice to justify a DPIA requirement.[5]

Shall carry out a DPIA

The purpose of a DPIA is to systematically analyze novel[6] situations that may entail high risks to the rights and freedoms of individuals. Therefore, there is no need to conduct a separate DPIA for processing operations that have already been examined within a specific context and for a specific purpose.[7]

WP29: For instance, a group of municipal authorities implementing similar closed-circuit television (CCTV) systems can perform a single DPIA to cover the processing activities conducted by these individual controllers. Similarly, a railway operator acting as a single controller can carry out a DPIA to cover video surveillance in all its train stations. This approach can also be applicable to similar processing operations carried out by different data controllers. In such cases, it is necessary to share or make the reference DPIA publicly accessible, implement the measures described in the DPIA, and provide justification for conducting a single DPIA.[8]

A DPIA may concern a single data processing operation. However, Article 35(1) states that “a single assessment may address a set of similar processing operations that present similar high risks”. Hence, a single DPIA can be utilized to evaluate multiple processing operations that share similarities in terms of their nature, scope, context, purpose, and risks.

Conceptually, a DPIA is a tool through which the controller, potentially supported by a DPO, processor, and other experts, (i) establishes the context of observation ("taking into account the nature, scope, context, and purposes of the processing and the sources of the risk"), (ii) assesses the risks of the processing activity ("assess the particular likelihood and severity of the high risk"), and (iii) identifies ways to manage that risk ("mitigating that risk"). All of this is done in order to (iv) ensure the protection of personal data and demonstrate GDPR compliance.[9]

Apart from what is stipulated in paragraph 7 in terms of content (to which the commentary refers), the GDPR provides data controllers with "flexibility to determine the precise structure and form of the DPIA in order to allow for this to fit with existing working practices."[10] However, whatever its form, "a DPIA must be a genuine assessment of risks, allowing controllers to take measures to address them." In this view, and in order to ensure consistency, the WP29 has identified a list of "common criteria" which "clarify the basic requirements of the Regulation, but provide enough scope for different forms of implementation."[11] These "Criteria for an acceptable DPIA" are as follows:

  • a systematic description of the processing is provided (Article 35(7)(a) GDPR):
    • nature, scope, context and purposes of the processing are taken into account (recital 90);
    • personal data, recipients and period for which the personal data will be stored are recorded;
    • a functional description of the processing operation is provided;
    • the assets on which personal data rely (hardware, software, networks, people, paper or paper transmission channels) are identified;
    • compliance with approved codes of conduct is taken into account (Article 35(8));
  • necessity and proportionality are assessed (Article 35(7)(b) GDPR):
    • measures envisaged to comply with the Regulation are determined (Article 35(7)(d) and recital 90), taking into account:
      • measures contributing to the proportionality and the necessity of the processing on the basis of:
        • specified, explicit and legitimate purpose(s) (Article 5(1)(b));
        • lawfulness of processing (Article 6);
        • adequate, relevant and limited to what is necessary data (Article 5(1)(c));
        • limited storage duration (Article 5(1)(e));
      • measures contributing to the rights of the data subjects:
        • information provided to the data subject (Articles 12, 13 and 14);
        • right of access and to data portability (Articles 15 and 20);
        • right to rectification and to erasure (Articles 16, 17 and 19);
        • right to object and to restriction of processing (Article 18, 19 and 21);
        • relationships with processors (Article 28);
        • safeguards surrounding international transfer(s) (Chapter V);
        • prior consultation (Article 36).
  • risks to the rights and freedoms of data subjects are managed (Article 35(7)(c);
    • origin, nature, particularity and severity of the risks are appreciated (cf. recital 84) or, more specifically, for each risk (illegitimate access, undesired modification, and disappearance of data) from the perspective of the data subjects:
      • risks sources are taken into account (recital 90);
      • potential impacts to the rights and freedoms of data subjects are identified in case of events including illegitimate access, undesired modification and disappearance of data;
      • threats that could lead to illegitimate access, undesired modification and disappearance of data are identified;
      • likelihood and severity are estimated (recital 90);
    • measures envisaged to treat those risks are determined (Article 35(7)(d) and recital 90)
  • interested parties are involved:
    • the advice of the DPO is sought (Article 35(2));
    • the views of data subjects or their representatives are sought, where appropriate (Article 35(9)).[12]

Finally, as a matter of good practice, a DPIA should be continuously reviewed and regularly re-assessed. Therefore, even if a DPIA is not required on 25 May 2018, it will be necessary, at the appropriate time, for the controller to conduct such a DPIA as part of its general accountability obligations.[13]

Prior to the processing

The DPIA should be conducted "prior to the processing" in accordance with Articles 35(1) and 35(10), as well as recitals 90 and 93 of the GDPR. This requirement is in line with the principles of data protection by design and by default, as outlined in Article 25 and recital 78. The DPIA serves as a valuable tool to assist in decision-making regarding the processing of personal data. By conducting a DPIA at an early stage, organizations can proactively identify and address any potential risks or privacy concerns associated with the processing activities. If the processing began before the GDPR came into force there is logically no possibility of a prior impact assessment.[14] However, DPIAs should be seen as a continuous process rather than as a one-time exercise.[15] For these reasons, it would be advisable to carry out a new DPIA in such circumstances.

Unless some exemptions apply

Hence, controllers must carry out a DPIA only if the processing “is likely to result in a high risk to the rights and freedoms of natural persons”. Accordingly, a DPIA is not required[16] when: (i) the processing is not "likely to result in a high risk to the rights and freedoms of natural persons"; (ii) the nature, scope, context and purposes of the processing are very similar to the processing for which a DPIA has been carried out;[17] (iii) the processing operations have been checked by a Data Protection Authority (DPA) before May 2018 and the specific conditions have not changed (recital 171);[18] (iv) a processing operation pursuant to Article 6(1)(c) or (e) has a legal basis in EU or Member State law, where the law regulates the specific processing operation, and a DPIA has already been carried out as part of the establishment of that legal basis (Article 35(10) GDPR);[19] (v) the processing is included on an optional list (established by a DPA) of processing operations for which no DPIA is required (Article 35(5) GDPR).[20]

(2) Involvement of the data protection officer

As per Article 35(1), the responsibility for conducting a DPIA lies with the controller, rather than the DPO. However, the DPO can play a crucial and valuable role in supporting the controller. In line with the principle of data protection by design, Article 35(2) explicitly states that the controller "shall seek advice" from the DPO when performing a DPIA.[21] This includes but is not limited to[22] determining whether a DPIA is necessary, selecting the appropriate methodology for conducting the assessment, deciding whether to perform it internally or outsource it, identifying safeguards to mitigate risks to data subjects' rights and interests, and ensuring the correct execution of the DPIA in compliance with the GDPR. The DPO's input is valuable in ensuring the effectiveness and accuracy of the DPIA process.[23] The DPO involvement should be documented in writing in order to demonstrate that the advice has been sought. Although the controller is not obliged to follow the DPO’s opinion it should motivate and document its reasons if it chooses not to.[24]

(3) Likely to result in a high risk

The structure of Article 35 may not provide clear guidance on its own. As previously discussed, paragraph 1 states that a DPIA is always required when processing operations are likely to pose a high risk to data subjects. Based on these general indications, the WP29 has developed a list of criteria to assess such likelyhood of risks (see above, If the processing is likely to result in a high risk for the rights and freedoms of natural persons) and provided guidance for conducting the impact assessment in the absence of specific instructions (see above, Shall carry out a DPIA). The three cases for which a DPIA is always required include: (a) conducting a systematic and extensive evaluation of personal aspects[25] through automated processing, which leads to legal effects or significantly impacts individuals;[26] (b) processing special categories of data or personal data related to criminal convictions and offenses[27] on a large scale;[28] and (c) systematically monitoring a publicly accessible area on a large scale.[29] In these situations, a DPIA is necessary to assess and mitigate the potential risks to individuals' rights and freedoms. As evident, many of the typical elements of processing mentioned in Article 35(3) (such as extensive evaluation of personal data, automated decision-making, special categories of data, large-scale processing) are also utilized by the WP29 as risk assessment criteria mentioned in paragraph 1. In other words, the examples provided in paragraph 3 are helpful in understanding the relevant risk indicators for the GDPR, which are broader.

(4)(5) Specifications through DPAs

As previously mentioned, every DPA shall establish a list of processing operations for which a DPIA is always required ("positive" or "black" list) under Article 35(1) GDPR. At the same time, the DPAs may draft a list of processing operations which do not require a DPIA ("negative" or "white" list).[30] In both cases, the national DPAs are obliged to communicate the lists to the EDPB according to Article 68 GDPR. The lists are available online on the EDPB's website.[31]

(6) Consistency mechanism is required in certain cases

Where the lists referred to in paragraphs 4 and 5 involve processing activities which on the one hand are related to the offering of goods or services to data subjects or to the monitoring of their behaviour in several Member States, or on the other hand may substantially affect the free movement of personal data within the Union, the competent DPA shall communicate them to the EDPB and apply the consistency mechanism referred to in Article 63 GDPR.

(7) DPIA minimum requirements

Article 35(7) GDPR sets out a list of minimum requirements which shall be dealt with in the DPIA. To begin with, under Article 35(7)(a) GDPR, the assessment must provide a systematic description of the envisaged processing operations and its purposes. In practice, this first step includes the description of the data flow and the systematic indication of the legal basis of the processing, including any legitimate interests pursued by the controller. In accordance with Article 35(7)(b) GDPR, the assessment will then have to ponder and explain the necessity and proportionality of each processing with regard to each purpose pursued. The controller shall explain for which reason a processing, or a set of processing activities, is necessary to pursue a specific purpose. In doing so, it also has to justify why other less intrusive processing is not suitable for the purpose.

Article 35(7)(c) GDPR requires the controller to include an assessment of the risks to the data subjects’ rights and freedoms. A “risk” is a scenario describing an event and its consequences, estimated in terms of severity and likelihood.[32] Risks can exist both within the controller's organization (e.g. employees, trainees, consultants) as well as externally (e.g. hackers, suppliers), and do not have to be caused exclusively by humans (e.g. harmful computer code, animals, fire, natural disasters). An individual risk is calculated by comparing the potential damage with the probability of its occurrence.[33] It is generally possible to distinguish between “implied risk” and “residual risk”. The former refers to the probability of detrimental consequences if no preventive measures are taken by the controller. The latter , on the contrary, is related to the negative impacts which may still occur despite the fact that certain mitigation measures may have been adopted.[34]

Under Article 35(7)(d) GDPR, the DPIA must include the appropriate measures the controller has adopted to mitigate potential risks. These measures may be technical or organisational in nature, including legal safeguards arising from contracts or other legal sources. The controller shall then apply these measures to the previously identified risks and verify the extent to which they contribute to risk reduction. This makes it possible to calculate the aforementioned 'residual risk'.[35] The DPIA must be documented, otherwise the controller would not be able to "systematically describe" the envisaged processing (Article 35(7)(a) GDPR) or share the assessment with the data protection authority under Article 36 GDPR. In general, the written form is the only way to provide proof of compliance. The GDPR does not explicitly require the publication of the assessment. However, in the interest of transparency towards data subjects, the essential parts of the DPIA can and should be published, or at least made available to the interested parties.[36]

Finally, Article 35(7) GDPR does not provide specific guidance on the structure, content and methodology the DPIA should follow. Nevertheless, in order to facilitate the controller's task, some DPAs have provided DPIA templates.[37] Although there is no obligation to use any of these models, they may serve as useful methodological or content related guides. It is worth noticing that the choice of measures mitigating risks could in practice lead the controller to change the nature of the processing operations. In this case, it is reasonable to argue that the controller should perform all the steps described in paragraph (7) again, as the new processing is substantially different from the one originally envisaged.

(8) Codes of conduct

Compliance with approved codes of conduct referred to in Article 40 GDPR shall be taken into due account in assessing the impact of the processing operations performed by the relevant controllers or processors, in particular for the purposes of a DPIA. Although adhering to an approved code of conduct does not automatically guarantee sufficient risk reduction for processing activities in specific cases, it does, however, make it significantly easier to conduct a DPIA and demonstrate compliance with GDPR.[38]

(9) Data subjects involvement in the drafting of the DPIA

Under Article 35(9) GDPR, the controller, “where appropriate” may “seek the views of data subjects or their representatives on the intended processing”.[39] This will be instrumental in order to increase the transparency of the processing and the involvement of (potential) data subjects in the assessment of of the processing. Whether this is an obligatory or voluntary step is not entirely clear. Some authors focus on one part of the text ("where appropriate") and conclude that it is merely an option.[40] This view, however, does not seem conclusive. The case, in fact, provides that where appropriate' the controller 'shall' seek the data subject's advice. Unlike ‘may’ or ‘can’, ‘shall’ implies an obligation Accordingly, the controller must give precise reasons as to whether the consultation is appropriate or not. The same effort seems to be required in case the controller does involve the data subjects, but then decides not to follow their input. Practical examples of implementation of pargraph (9) are the involvement of a works council or the sending of a survey to customers.

(10) National exemptions

There is no obligation to conduct a DPIA when the processing relies on Article 6(1)(c) or (e) GDPR as a legal basis, which in turn is based on European or Member State law for which the lawmaker has already conducted a general impact assessment (see also Recital 93 GDPR). In this regard, the lawmaker can effectively shift the DPIA to the law-making process, in order to reduce the resulting bureaucracy for public institutions relying on these laws to carry out their processing activities.[41] However, the lawmaker is not obliged to do so, and can still require controllers to carry out their own DPIA despite having already conducted one during the law-making process.

(11) Review of processing and updates

Article 35(11) GDPR requires the controller to reassess if the processing is performed in accordance with the DPIA. However, the fact that the DPIA may need to be updated once the processing has actually started is not a valid reason for postponing or not carrying out a DPIA. Carrying out a DPIA is an continual ongoing process and not a one-time exercise, especially where a processing operation and the risks it might imply are dynamic and subject to ongoing change.[42]

Decisions

→ You can find all related decisions in Category:Article 35 GDPR

References

  1. ↑ Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 10 (C.H. Beck 2021, 39th ed.).
  2. ↑ A "risk" can be defined as a scenario that describes an event and its potential consequences, taking into account both severity and likelihood. "Risk management" refers to the coordinated actions taken to direct and control an organization in relation to such risks.
  3. ↑ The reference to the "rights and freedoms" of data subjects primarily encompasses the rights to data protection and privacy. However, it may also involve other fundamental rights, such as freedom of speech, freedom of thought, freedom of movement, prohibition of discrimination, right to liberty, conscience, and religion. See, WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, pp. 6 (available here).
  4. ↑ Article 35(3) GDPR provides a list of “inherently” risky processing operations which always require a previous DPIA. This is the case when processing involves (a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person; (b) processing on a large scale of special categories of data referred to in Article 9(1) GDPR, or of personal data relating to criminal convictions and offences referred to in Article 10 GDPR; or (c) a systematic monitoring of a publicly accessible area on a large scale. The use of the phrase "in particular" in this provision means that the above-mentioned circumstances, however, do not constitute an exhaustive list and a DPIA may also be required for other types of processing which are not mentioned in it. See, Karg, in Simitis, Hornung, Spieker gen. Döhmann, Datenschutzrecht, Article 35 GDPR, margin number 36 (C.H. Beck 2019).
  5. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, pp. 9-12 (available here).
  6. ↑ The requirement to carry out a DPIA "applies to existing processing operations likely to result in a high risk to the rights and freedoms of natural persons and for which there has been a change of the risks, taking into account the nature, scope, context and purposes of the processing." See, WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, pp. 13 (available here).
  7. ↑ Recital 92 adds that “there are circumstances under which it may be reasonable and economical for the subject of a data protection impact assessment to be broader than a single project, for example where public authorities or bodies intend to establish a common application or processing platform or where several controllers plan to introduce a common application or processing environment across an industry sector or segment or for a widely used horizontal activity”.
  8. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 7 (available here).
  9. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 17 (available here).
  10. ↑ It is always advisable to consult specific guidelines issued by data protection authorities at the national level or to adopt or draw inspiration from standards developed for specific sectors.
  11. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 17 (available here).
  12. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, Annex 2, p. 22 (available here).
  13. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 14 (available here).
  14. ↑ Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 19 (C.H. Beck 2021, 39th edition).
  15. ↑ Kosta, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 35 GDPR, p. 675 (Oxford University Press 2020).
  16. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, pp. 12-13 (available here).
  17. ↑ In such cases, the controller may use the results of a DPIA already carried out for similar processing (Article 35(1), last sentence GDPR).
  18. ↑ "Commission decisions adopted and authorisations by supervisory authorities based on Directive 95/46/EC remain in force until amended, replaced or repealed" (Recital 171).
  19. ↑ Except if Member state law states it to be necessary to carry out a DPIA prior processing activities.
  20. ↑ Such a list may contain processing activities that comply with the conditions specified by this authority, in particular through guidelines, specific decisions or authorisations, compliance rules, etc. (e.g. in France, authorisations, exemptions, simplified rules, compliance packs…). In such cases, and subject to re-assessment by the competent supervisory authority, a DPIA is not required, but only if the processing falls strictly within the scope of the relevant procedure mentioned in the list and continues to comply fully with all the relevant requirements of the GDPR.
  21. ↑ In fact, where an obligation to carry out a DPIA exists, the designated DPO has to be involved in the procedure, and the controller should consult them for their advice. Jandt, in Kühling, Buchner, DS-GVO BDSG, Article 35 GDPR, margin number 18 (C.H. Beck 2020, 3rd Edition). Furthermore, Article 39(1)(c) assigns the duty to the DPO to "provide advice where requested regarding the [DPIA] and monitor its performance pursuant to Article 35."
  22. ↑ Article 39(1) mentions the tasks of the DPO and indicates that the DPO shall have ‘at least’ the following tasks. Therefore, nothing prevents the controller from assigning the DPO other tasks than those explicitly mentioned in Article 39(1), or specifying those tasks in more detail.
  23. ↑ WP29, ‘Guidelines on Data Protection Officers (‘DPOs’)’, 16/EN WP 243 rev.01, 5 April 2017, p. 8 (available here).
  24. ↑ Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 23 (C.H. Beck 2021, 39th edition).
  25. ↑ Evaluation or scoring, including profiling and predicting, especially from “aspects concerning the data subject's performance at work, economic situation, health, personal preferences or interests, reliability or behavior, location or movements” (recitals 71 and 91). Examples of this could include a financial institution that screens its customers against a credit reference database or against an anti-money laundering and counter-terrorist financing (AML/CTF) or fraud database, or a biotechnology company offering genetic tests directly to consumers in order to assess and predict the disease/health risks, or a company building behavioural or marketing profiles based on usage or navigation on its website.
  26. ↑ Automated-decision making with legal or similar significant effect: processing that aims at taking decisions on data subjects producing “legal effects concerning the natural person” or which “similarly significantly affects the natural person” (Article 35(3)(a)). For example, the processing may lead to the exclusion or discrimination against individuals. Processing with little or no effect on individuals does not match this specific criterion.
  27. ↑ Sensitive data or data of a highly personal nature: this includes special categories of personal data as defined in Article 9 (for example information about individuals’ political opinions), as well as personal data relating to criminal convictions or offences as defined in Article 10. An example would be a general hospital keeping patients’ medical records or a private investigator keeping offenders’ details. Beyond these provisions of the GDPR, some categories of data can be considered as increasing the possible risk to the rights and freedoms of individuals. These personal data are considered as sensitive (as this term is commonly understood) because they are linked to household and private activities (such as electronic communications whose confidentiality should be protected), or because they impact the exercise of a fundamental right (such as location data whose collection questions the freedom of movement) or because their violation clearly involves serious impacts in the data subject’s daily life (such as financial data that might be used for payment fraud). In this regard, whether the data has already been made publicly available by the data subject or by third parties may be relevant. The fact that personal data is publicly available may be considered as a factor in the assessment if the data was expected to be further used for certain purposes. This criterion may also include data such as personal documents, emails, diaries, notes from e-readers equipped with note-taking features, and very personal information contained in life-logging applications.
  28. ↑ Data processed on a large scale: the GDPR does not define what constitutes large-scale, though recital 91 provides some guidance. In any event, the WP29 recommends that the following factors, in particular, be considered when determining whether the processing is carried out on a large scale: a. the number of data subjects concerned, either as a specific number or as a proportion of the relevant population; b. the volume of data and/or the range of different data items being processed; c. the duration, or permanence, of the data processing activity; d. the geographical extent of the processing activity.
  29. ↑ Systematic monitoring: processing used to observe, monitor or control data subjects, including data collected through networks or “a systematic monitoring of a publicly accessible area” (Article 35(3)(c))15. This type of monitoring is a criterion because the personal data may be collected in circumstances where data subjects may not be aware of who is collecting their data and how they will be used. Additionally, it may be impossible for individuals to avoid being subject to such processing in public (or publicly accessible) space(s).
  30. ↑ Where a supervisory authority draws up such a negative list, attention must be paid to the detailed description of the processing operations so that the controller does not run the risk of misunderstanding the entries and thus refrains from carrying out the data protection impact assessment and possibly also taking the necessary remedial measures despite a likely high risk. See, Hansen, in BeckOK DatenschutzR, Article 35 GDPR, margin number 36 (Beck 2020, 36th ed.) (accessed 25 February 2022).
  31. ↑ Available here: https://edpb.europa.eu/our-work-tools/consistency-findings/register-for-decisions_el?f%5B0%5D=register_decisions_topic%3A138
  32. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 6 (available here).
  33. ↑ Schwendemann, in Sydow, Europäische Datenschutzgrundverordnung, Article 35 GDPR, margin number 27 (C.H. Beck 2018, 2nd Edition.
  34. ↑ Under Article 35(8) GDPR, compliance with approved codes of conduct referred to in Article 40 GDPR by the relevant controllers or processors “shall be taken into due account in assessing the impact of the processing operations performed by such controllers or processors, in particular for the purposes of a data protection impact assessment.”
  35. ↑ Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 49 (C.H. Beck 2021, 39th edition).
  36. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 18 (available here).
  37. ↑ The French DPA (CNIL) provides specific guidance as well as a software for carrying out an impact assessment (here). The Belgian DPA (APD/GBA) provides a recommendation on data protection impact assessment (here). The Spanish DPA (AEPD) has also published similar guidance on its website (here).
  38. ↑ Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 59 (C.H. Beck 2021, 39th edition).
  39. ↑ These can be, for example, works and staff councils, trade unions, consumer protection associations or civil society groups. Unless there is an obligation to participate due to other legal norms, it is left to the controller to take care of the data subjects' views. See, Hansen, in Wolff, Brink, BeckOK Datenschutzrecht, Article 35 GDPR, margin number 61 (C.H. Beck 2021, 39th edition).
  40. ↑ Baumgartner in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 35 GDPR, margin numbers 70-71 (C.H. Beck 2018, 2nd Edition).
  41. ↑ Karg, in Simitis, Hornung, Spieker gen. Döhmann, Datenschutzrecht, Article 35 GDPR, margin number 58 (C.H. Beck 2019).
  42. ↑ WP29, ‘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’, 17/EN WP248 rev.01, 4 October 2017, p. 14 (available here).
Retrieved from "https://gdprhub.eu/index.php?title=Article_35_GDPR&oldid=34063"
Creative Commons Attribution-NonCommercial-ShareAlike
Powered by MediaWiki