Article 32 GDPR: Difference between revisions
| Line 215: | Line 215: | ||
=== (1) Level of security appropriate to the risk === | === (1) Level of security appropriate to the risk === | ||
Article 32 GDPR requires controllers and processors to implement measures that ensure an appropriate level of security. The word 'appropriate' appears not less than three times in Article 32(1): "''the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate"''. | Article 32 GDPR requires controllers and processors to implement measures that ensure an appropriate level of security. The word 'appropriate' appears not less than three times in Article 32(1): "''the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate"''. This indicates that controllers and processors must identify the situation specific risks, assess their potential impact having regard to the particular circumstances of the processing and implement measures to mitigate (at least) those risks which are the most likely to materialise and those whose impact would be the most severe. <ref>References to "appropriateness" "''can be seen as a way of expressing the importance of the principle of proportionality, which is a general principle of EU law, in determining how to ensure data security. A proportionality analysis generally inquires whether the means used to achieve an aim corresponds to the importance of the aim and whether it is necessary for its achievement''". ''Burton'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 635 (Oxford University Press 2020).</ref> In doing so, they must take into account eight criteria: state of the art, implementation costs, nature, scope, circumstances and purposes of the processing, as well as the likelihood and severity of risks to the rights and freedoms of natural persons. | ||
This indicates that controllers and processors must identify the situation specific risks, assess their potential impact having regard to the particular circumstances of the processing and implement measures to mitigate (at least) those risks which are the most likely to materialise and those whose impact would be the most severe. References to "appropriateness" "''can be seen as a way of expressing the importance of the principle of proportionality, which is a general principle of EU law, in determining how to ensure data security. A proportionality analysis generally inquires whether the means used to achieve an aim corresponds to the importance of the aim and whether it is necessary for its achievement''". | |||
In doing so, they must take into account eight criteria: state of the art, implementation costs, nature, scope, circumstances and purposes of the processing, as well as the likelihood and severity of risks to the rights and freedoms of natural persons. | |||
==== The controller and the processor ==== | ==== The controller and the processor ==== | ||
Article 32 directly addresses the controller and processor. Unlike the general responsibility for data processing, the processor bears direct responsibility for ensuring security. This creates an additional obligation | Article 32 directly addresses both the controller and processor. In contrast to the general controller's GDPR responsibility, the provision sets out an additional and direct responsibility of the processor for ensuring security<ref>Unlike the general responsibility for data processing under Articles 24 and 25, which lies on the controller, under Article 32 the processor bears direct responsibility for ensuring security. This creates an additional obligation beyond the one derived from the contract with the controller under Article 28(3)(c) of the GDPR. The underlying rationale for this choice is practical. While the controller theoretically has the ability to assess the processor's security standards (Article 28(3)(h) GDPR), in practice, it is the processor who possesses direct knowledge and control over the (portion of) processing operations it is entrusted with. The legislative decision is therefore sensible and logical. ''Jandt'', in Kühling, Buchner, DS-GVO BDSG, Article 32 GDPR, margin number 4 (C.H. Beck 2020, 3rd Edition).</ref> | ||
The | The provision does not directly apply to software and device manufacturers. However, similarly to what happens under Article 25, Article 32 GDPR holds practical significance when it comes to the selection of software and hardware, which must meet the required security standard. In situations of uncertainty, products that do not enable data protection-compliant usage should not be employed by the data controller. <blockquote><u>Case-law</u>: The Finnish DPA held that four cities in Finland had, among others, unlawfully transferred personal data to the US by using Google Analytics and Google Tag Manager on their public library online services, among the others in breach of Article 32 GDPR. The DPA ordered them to delete the data collected through these tools.<ref>Tietosuojavaltuutetun toimisto (Finland) - 4672/161/2022 (available [[Tietosuojavaltuutetun toimisto (Finland) - 4672/161/2022|here]]).</ref></blockquote> | ||
==== Taking into account ==== | ==== Taking into account ==== | ||
Article 32(1) outlines the factors that the controller and processor must consider when conducting th assessment on which measures are appropriate to contain the risks. These factors include the state of the art, the implementation costs, the nature, scope, context, and purposes of the processing, as well as the varying likelihood and severity of risks to the rights and freedoms of individuals. | |||
===== State of the art ===== | ===== State of the art ===== | ||
Article 32(1) of the GDPR introduces the concept of the "state of the art" which should be considered when determining the appropriate measures to be implemented. It is important to note that this term is interpreted independently within the framework of the GDPR. A key practical question is whether it encompasses the latest technological advancements or if adherence to industry standards and practices is sufficient. Scholars suggest that "state of the art" does not necessarily refer to the absolute best or most advanced technologies. Rather, it encompasses well-established, proven, and effective measures that are currently available in the market.<ref>When determining the available technology, it is essential to consider various factors, including market conditions. The assessment should take into account the prevailing market situation and the practices followed by competitors. Furthermore, it is important to consider information and recommendations provided by government agencies. For example, guidance from authorities like the Federal Office for Information Security (BSI) and their IT baseline protection catalogs can provide valuable insights and should be taken into consideration. ''Piltz'', in Gola, Datenschutz-Grund-verordnung, Article 32 GDPR, margin number 19 (C. H. Beck 2018, 2nd edition).</ref><blockquote><u>Case-law</u>: Sending an e-mail containing sensitive data with enforced TLS-encryption instead of end-to-end encryption was deemed insufficiently secured under Article 32(1) GDPR. The controller received a reprimand instead of a fine as it had increased the security of its communication solutions.<ref>IMY (Sweden) - DI-2021-4355 (available [[IMY (Sweden) - DI-2021-4355|here]]).</ref></blockquote> | |||
===== Costs of implementation ===== | ===== Costs of implementation ===== | ||
The second criterion for selecting appropriate technical measures and organisation are the implementation costs. When calculating costs, all necessary expenses related to the implementation of the measures should be considered, including acquisition and installation costs prior to processing initiation, as well as operational and maintenance costs during the ongoing processing. An economic analysis should be conducted to assess the relationship between costs and risks. The higher the level of risk associated with the data processing, the more economically justifiable it is for the controller to invest in implementing the necessary technical measures. Cost-intensive measures that offer minimal additional risk reduction may not be required.<ref>''Jandt'', in Kühling, Buchner, DS-GVO BDSG, Article 32 GDPR, margin number 11 (C.H. Beck 2020, 3rd Edition).</ref> | |||
===== Nature, scope, context and purpose of processing ===== | ===== Nature, scope, context and purpose of processing ===== | ||
This includes the ''nature'' of the processing (manual or automated), the ''scope'' of the processing (amount of data subjects affected, amount of data collected, bulk or individual processing, sensitivity of the data), the ''context'' of the processing (how many parties are involved, which systems are used, etc.), and the ''purposes'' of the processing. | |||
===== Risks of varying likelihood and severity for rights and freedoms of natural persons ===== | ===== Risks of varying likelihood and severity for rights and freedoms of natural persons ===== | ||
Finally, controllers and processors should complete a risk assessment before carrying out a processing operation. Although the provision applies to all types of risks, Article 32(2) GDPR indicates that specific attention should be paid to certain categories of risk, such as the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed. Recital 83 GDPR also suggests that not all of these are actually relevant. Indeed, the risk should also “''lead to physical, material or non-material damage''”. It can therefore be argued that a potential risk of e.g. “''destruction''” will not be relevant if it is no tangible harm is caused to data subjects. | |||
==== Shall implement appropriate technical and organisational measures ==== | ==== Shall implement appropriate technical and organisational measures ==== | ||
| Line 243: | Line 243: | ||
Additionally, organisational measures should also be implemented. For example, controllers and processors should: allocate responsibility between themselves; require each person authorised to process personal data to participate in training activities of; draft and follow internal policies, disciplinary measures, and internal guidelines; and adhere to codes of conduct or certification mechanisms. | Additionally, organisational measures should also be implemented. For example, controllers and processors should: allocate responsibility between themselves; require each person authorised to process personal data to participate in training activities of; draft and follow internal policies, disciplinary measures, and internal guidelines; and adhere to codes of conduct or certification mechanisms. | ||
After having identified a list of theoretically applicable measures, controllers and processors must choose and implement measures which can ensure an “''appropriate''” level of security. This indicates that they must implement measures that can mitigate at least those risks which are the most likely to materialise and whose impact would be the most severe.<ref>''Burton'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 636 (Oxford University Press 2020).</ref> | After having identified a list of theoretically applicable measures, controllers and processors must choose and implement measures which can ensure an “''appropriate''” level of security. This indicates that they must implement measures that can mitigate at least those risks which are the most likely to materialise and whose impact would be the most severe.<ref>''Burton'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 636 (Oxford University Press 2020).</ref> | ||
=== (2) Certain | === (2) Certain risks must always be taken into account === | ||
The second paragraph builds on Article 32(1) in the sense that it provides examples (accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to processed personal data) | The second paragraph builds on Article 32(1) in the sense that it provides examples of the risks that are most likely to occur, and/or the most severe (accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to processed personal data). ''Burton'' notes that these risks are somewhat similar to the criteria that need to be considered when a DPIA is carried out.<ref>''Burton'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 636 (Oxford University Press 2020).</ref> | ||
=== (3) Codes of | === (3) Codes of conduct and certification Mechanisms === | ||
In line with the accountability principle, Article 32(3) GDPR stipulates that adherence to codes of conduct or certification mechanisms can be used as an element to demonstrate compliance with the Regulation, although neither of these reduce the controller or processor’s responsibility ([[Article 42 GDPR|Article 42(4) GDPR]]). However, if asked to prove they took all possible measures to avoid the violation, adherence to these would undoubtedly be acknowledged.<ref>''Riccio'', ''Scorza'', ''Belisario'', GDPR e normativa privacy, p. 299 (Wolters Kluwer 2018).</ref> | In line with the accountability principle, Article 32(3) GDPR stipulates that adherence to codes of conduct or certification mechanisms can be used as an element to demonstrate compliance with the Regulation, although neither of these reduce the controller or processor’s responsibility ([[Article 42 GDPR|Article 42(4) GDPR]]). However, if asked to prove they took all possible measures to avoid the violation, adherence to these would undoubtedly be acknowledged.<ref>''Riccio'', ''Scorza'', ''Belisario'', GDPR e normativa privacy, p. 299 (Wolters Kluwer 2018).</ref> | ||
=== (4) Natural | === (4) Natural persons acting under the authority of the controller or the processor === | ||
Most processing operations involve the use of human resources. Whenever a person is authorised to access personal data, a data security issue obviously arises. For these reasons, Article 32(4) GDPR requires the controller and processor to ensure that such persons act solely and exclusively on the instructions of the controller. The verb 'ensure' indicates that controllers and processors must provide some form of guarantee with respect to the result. | Most processing operations involve the use of human resources. Whenever a person is authorised to access personal data, a data security issue obviously arises. For these reasons, Article 32(4) GDPR requires the controller and processor to ensure that such persons act solely and exclusively on the instructions of the controller. The verb 'ensure' indicates that controllers and processors must provide some form of guarantee with respect to the result. | ||
The provision also speaks of "''any'' ''natural person'' [...] ''who has access to personal data''". This includes employees, freelancers, interns, external consultants or employees of service companies, insofar as they have access to personal data. In contrast, other third parties, including visitors or customers who access the data unlawfully, are not included in the definition, as they do not act "''under the authority of the controller or processor''".<ref>''Martini'', in Paal, Pauly, DS-GVO Article 32, margin number 65 (C.H.Beck 2021, 3rd Edition).</ref> | The provision also speaks of "''any'' ''natural person'' [...] ''who has access to personal data''". This includes employees, freelancers, interns, external consultants or employees of service companies, insofar as they have access to personal data. In contrast, other third parties, including visitors or customers who access the data unlawfully, are not included in the definition, as they do not act "''under the authority of the controller or processor''".<ref>''Martini'', in Paal, Pauly, DS-GVO Article 32, margin number 65 (C.H.Beck 2021, 3rd Edition).</ref> | ||
To comply with this obligation, controllers and processors should establish clear rules of conduct, internal instructions and sanctioning procedures. Technical measures that prevent unauthorised access are also essential in certain cases. Controllers and processors must also regularly check whether these measures are effective and actually followed. | To comply with this obligation, controllers and processors should establish clear rules of conduct, internal instructions and sanctioning procedures. Technical measures that prevent unauthorised access are also essential in certain cases. Controllers and processors must also regularly check whether these measures are effective and actually followed.<ref>''Martini'', in Paal, Pauly, DS-GVO Article 32, margin number 66 (C.H.Beck 2021, 3rd Edition).</ref> | ||
==Decisions== | ==Decisions== | ||
Revision as of 13:23, 9 June 2023
Legal Text
1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
- (a) the pseudonymisation and encryption of personal data;
- (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
- (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
- (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.
3. Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1 of this Article.
4. The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.
Relevant Recitals
Commentary
Article 32(1) GDPR reflects the principle of integrity and confidentiality enshrined in Article 5(1)(f) GDPR. The controller and the processor must implement appropriate technical and organizational measures in order to realise an appropriate level of security, taking into account the state of the art, the implementation costs as well as the nature, scope, context and purposes of processing. Consideration must also be given to the processing operation’s impact on the rights and freedoms of natural persons.[1]
(1) Level of security appropriate to the risk
Article 32 GDPR requires controllers and processors to implement measures that ensure an appropriate level of security. The word 'appropriate' appears not less than three times in Article 32(1): "the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate". This indicates that controllers and processors must identify the situation specific risks, assess their potential impact having regard to the particular circumstances of the processing and implement measures to mitigate (at least) those risks which are the most likely to materialise and those whose impact would be the most severe. [2] In doing so, they must take into account eight criteria: state of the art, implementation costs, nature, scope, circumstances and purposes of the processing, as well as the likelihood and severity of risks to the rights and freedoms of natural persons.
The controller and the processor
Article 32 directly addresses both the controller and processor. In contrast to the general controller's GDPR responsibility, the provision sets out an additional and direct responsibility of the processor for ensuring security[3]
The provision does not directly apply to software and device manufacturers. However, similarly to what happens under Article 25, Article 32 GDPR holds practical significance when it comes to the selection of software and hardware, which must meet the required security standard. In situations of uncertainty, products that do not enable data protection-compliant usage should not be employed by the data controller.
Case-law: The Finnish DPA held that four cities in Finland had, among others, unlawfully transferred personal data to the US by using Google Analytics and Google Tag Manager on their public library online services, among the others in breach of Article 32 GDPR. The DPA ordered them to delete the data collected through these tools.[4]
Taking into account
Article 32(1) outlines the factors that the controller and processor must consider when conducting th assessment on which measures are appropriate to contain the risks. These factors include the state of the art, the implementation costs, the nature, scope, context, and purposes of the processing, as well as the varying likelihood and severity of risks to the rights and freedoms of individuals.
State of the art
Article 32(1) of the GDPR introduces the concept of the "state of the art" which should be considered when determining the appropriate measures to be implemented. It is important to note that this term is interpreted independently within the framework of the GDPR. A key practical question is whether it encompasses the latest technological advancements or if adherence to industry standards and practices is sufficient. Scholars suggest that "state of the art" does not necessarily refer to the absolute best or most advanced technologies. Rather, it encompasses well-established, proven, and effective measures that are currently available in the market.[5]
Case-law: Sending an e-mail containing sensitive data with enforced TLS-encryption instead of end-to-end encryption was deemed insufficiently secured under Article 32(1) GDPR. The controller received a reprimand instead of a fine as it had increased the security of its communication solutions.[6]
Costs of implementation
The second criterion for selecting appropriate technical measures and organisation are the implementation costs. When calculating costs, all necessary expenses related to the implementation of the measures should be considered, including acquisition and installation costs prior to processing initiation, as well as operational and maintenance costs during the ongoing processing. An economic analysis should be conducted to assess the relationship between costs and risks. The higher the level of risk associated with the data processing, the more economically justifiable it is for the controller to invest in implementing the necessary technical measures. Cost-intensive measures that offer minimal additional risk reduction may not be required.[7]
Nature, scope, context and purpose of processing
This includes the nature of the processing (manual or automated), the scope of the processing (amount of data subjects affected, amount of data collected, bulk or individual processing, sensitivity of the data), the context of the processing (how many parties are involved, which systems are used, etc.), and the purposes of the processing.
Risks of varying likelihood and severity for rights and freedoms of natural persons
Finally, controllers and processors should complete a risk assessment before carrying out a processing operation. Although the provision applies to all types of risks, Article 32(2) GDPR indicates that specific attention should be paid to certain categories of risk, such as the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed. Recital 83 GDPR also suggests that not all of these are actually relevant. Indeed, the risk should also “lead to physical, material or non-material damage”. It can therefore be argued that a potential risk of e.g. “destruction” will not be relevant if it is no tangible harm is caused to data subjects.
Shall implement appropriate technical and organisational measures
Controllers and processors should identify security measures that can mitigate identified risks. The GDPR does not require the use of any particular technology or technical standard with regard to data security. Indeed, Recital 15 stipulates that "the protection of natural persons should be technologically neutral and should not depend on the techniques used".
However, Article 32(1) GDPR enumerates four examples of technical security measures[8] that controllers and processors should implement "as appropriate".[9] These include pseudonymisation and encryption of personal data (Article 32(1)(a) GDPR); the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems (Article 32(1)(b) GDPR); the ability to restore the availability and access to personal data in a timely manner in case of an incident (Article 32(1)(c) GDPR) and a process for regularly testing, assessing and evaluating the effectiveness of security measures (Article 32(1)(d) GDPR).
Additionally, organisational measures should also be implemented. For example, controllers and processors should: allocate responsibility between themselves; require each person authorised to process personal data to participate in training activities of; draft and follow internal policies, disciplinary measures, and internal guidelines; and adhere to codes of conduct or certification mechanisms.
After having identified a list of theoretically applicable measures, controllers and processors must choose and implement measures which can ensure an “appropriate” level of security. This indicates that they must implement measures that can mitigate at least those risks which are the most likely to materialise and whose impact would be the most severe.[10]
(2) Certain risks must always be taken into account
The second paragraph builds on Article 32(1) in the sense that it provides examples of the risks that are most likely to occur, and/or the most severe (accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to processed personal data). Burton notes that these risks are somewhat similar to the criteria that need to be considered when a DPIA is carried out.[11]
(3) Codes of conduct and certification Mechanisms
In line with the accountability principle, Article 32(3) GDPR stipulates that adherence to codes of conduct or certification mechanisms can be used as an element to demonstrate compliance with the Regulation, although neither of these reduce the controller or processor’s responsibility (Article 42(4) GDPR). However, if asked to prove they took all possible measures to avoid the violation, adherence to these would undoubtedly be acknowledged.[12]
(4) Natural persons acting under the authority of the controller or the processor
Most processing operations involve the use of human resources. Whenever a person is authorised to access personal data, a data security issue obviously arises. For these reasons, Article 32(4) GDPR requires the controller and processor to ensure that such persons act solely and exclusively on the instructions of the controller. The verb 'ensure' indicates that controllers and processors must provide some form of guarantee with respect to the result.
The provision also speaks of "any natural person [...] who has access to personal data". This includes employees, freelancers, interns, external consultants or employees of service companies, insofar as they have access to personal data. In contrast, other third parties, including visitors or customers who access the data unlawfully, are not included in the definition, as they do not act "under the authority of the controller or processor".[13]
To comply with this obligation, controllers and processors should establish clear rules of conduct, internal instructions and sanctioning procedures. Technical measures that prevent unauthorised access are also essential in certain cases. Controllers and processors must also regularly check whether these measures are effective and actually followed.[14]
Decisions
→ You can find all related decisions in Category:Article 32 GDPR
References
- ↑ The CJEU has consequently recognised data security as an integral part of the right to data protection in Article 8 of the Charter of Fundamental Rights of the European Union. See, CJEU, Joined Cases C‑293/12 and C‑594/12, Digital Rights Ireland Ltd, 8 April 2014, margin number 29 (available here).
- ↑ References to "appropriateness" "can be seen as a way of expressing the importance of the principle of proportionality, which is a general principle of EU law, in determining how to ensure data security. A proportionality analysis generally inquires whether the means used to achieve an aim corresponds to the importance of the aim and whether it is necessary for its achievement". Burton, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 635 (Oxford University Press 2020).
- ↑ Unlike the general responsibility for data processing under Articles 24 and 25, which lies on the controller, under Article 32 the processor bears direct responsibility for ensuring security. This creates an additional obligation beyond the one derived from the contract with the controller under Article 28(3)(c) of the GDPR. The underlying rationale for this choice is practical. While the controller theoretically has the ability to assess the processor's security standards (Article 28(3)(h) GDPR), in practice, it is the processor who possesses direct knowledge and control over the (portion of) processing operations it is entrusted with. The legislative decision is therefore sensible and logical. Jandt, in Kühling, Buchner, DS-GVO BDSG, Article 32 GDPR, margin number 4 (C.H. Beck 2020, 3rd Edition).
- ↑ Tietosuojavaltuutetun toimisto (Finland) - 4672/161/2022 (available here).
- ↑ When determining the available technology, it is essential to consider various factors, including market conditions. The assessment should take into account the prevailing market situation and the practices followed by competitors. Furthermore, it is important to consider information and recommendations provided by government agencies. For example, guidance from authorities like the Federal Office for Information Security (BSI) and their IT baseline protection catalogs can provide valuable insights and should be taken into consideration. Piltz, in Gola, Datenschutz-Grund-verordnung, Article 32 GDPR, margin number 19 (C. H. Beck 2018, 2nd edition).
- ↑ IMY (Sweden) - DI-2021-4355 (available here).
- ↑ Jandt, in Kühling, Buchner, DS-GVO BDSG, Article 32 GDPR, margin number 11 (C.H. Beck 2020, 3rd Edition).
- ↑ Hence, this list is non-exhaustive, see Hladjk, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 32 GDPR, margin number 6 (C.H. Beck 2018, 2nd Edition).
- ↑ Piltz correctly points out that the German version of the GDPR contains a translation error according to which the measures listed could be considered mandatory. The other language versions, however, clearly suggest that the measures contained in the list are merely illustrative. The English version, for example, uses the expression 'as appropriate'. Piltz, in Gola, Datenschutz-Grundverordnung, Article 32 GDPR, margin number 24 (C.H. Beck 2018, 2nd Edition).
- ↑ Burton, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 636 (Oxford University Press 2020).
- ↑ Burton, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 32 GDPR, p. 636 (Oxford University Press 2020).
- ↑ Riccio, Scorza, Belisario, GDPR e normativa privacy, p. 299 (Wolters Kluwer 2018).
- ↑ Martini, in Paal, Pauly, DS-GVO Article 32, margin number 65 (C.H.Beck 2021, 3rd Edition).
- ↑ Martini, in Paal, Pauly, DS-GVO Article 32, margin number 66 (C.H.Beck 2021, 3rd Edition).
