Article 32 GDPR

← Article 32 - Security of processing →
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 32 - Security of processing

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

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 76: Evaluating the Risks to Natural Persons

The likelihood and severity of the risk to the rights and freedoms of the data subject should be determined by reference to the nature, scope, context and purposes of the processing. Risk should be evaluated on the basis of an objective assessment, by which it is established whether data processing operations involve a risk or a high risk.

Recital 77: Guidance on Evaluating Risks

Guidance on the implementation of appropriate measures and on the demonstration of compliance by the controller or the processor, especially as regards the identification of the risk related to the processing, their assessment in terms of origin, nature, likelihood and severity, and the identification of best practices to mitigate the risk, could be provided in particular by means of approved codes of conduct, approved certifications, guidelines provided by the Board or indications provided by a data protection officer. The Board may also issue guidelines on processing operations that are considered to be unlikely to result in a high risk to the rights and freedoms of natural persons and indicate what measures may be sufficient in such cases to address such risk.

Recital 78: Appropriate Technical and Organisational Measures

The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.

Recital 79: Clear Allocation of Responsibilities

The protection of the rights and freedoms of data subjects as well as the responsibility and liability of controllers and processors, also in relation to the monitoring by and measures of supervisory authorities, requires a clear allocation of the responsibilities under this Regulation, including where a controller determines the purposes and means of the processing jointly with other controllers or where a processing operation is carried out on behalf of a controller.

Recital 83: Assessing and Mitigating Processing Risks

In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.

Commentary

Article 32 GDPR provides for an obligation to implement technical and organisational measures ("TOMs") ensuring the security of processing, which is an integral part of the right to data protection under Article 8 of the Charter of Fundamental Rights of the European Union ("CFR"). Therefore, this provision reflects the principle of integrity and confidentiality enshrined in Article 5(1)(f) GDPR. Any breach of the security of personal data demanded by this provision leads to a 'personal data breach' as defined in Article 4(12) GDPR and might be subject to a notice to the supervisory authority ("SA") or to the data subject (see Articles 33 and 34 GDPR respectively).

Since this provision deals with the implementation of appropriate TOMs, it is closely related to Articles 24 (Responsibility of the controller) and 25 (Data protection by design and by default) GDPR which similarly demand the implementation of appropriate TOMs. However, other than these provisions, Article 32 GDPR addresses controllers as well as processors.

Article 32(1) GDPR obliges the controller and the processor to implement appropriate TOMs 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.

Article 32(2) GDPR lists some specific risks that should be considered in the assessment of the appropriate level of security, such as risks from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

Article 32(3) GDPR provides for the possibility to use adherence to approved codes of conduct (Article 40 GDPR) or an approved certification mechanism (Article 42 GDPR) as an element to demonstrate compliance with the obligation to implement appropriate security measures.

Article 32(4) GDPR obliges controllers and processors to ensure than all persons under their authority with access to personal data do not process them except on instructions from the controller or when it is required by law.

EDPB and WP29 Guidelines:

• EDPB, 'Guidelines 01/2021 on Examples regarding Personal Data Breach Notification', 14 December 2021 (Version 2.0) (available here).
• EDPB, 'Guidelines 07/2020 on the concepts of controller and processor in the GDPR', 7 July 2021 (Version 2.1) (available here),
• WP29, 'Opinion 3/2010 on the principle of accountability', 00062/10/EN WP173, 13 July 2010 (available here),
• 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 April 2017 (available here).

(1) Obligation to implement appropriate TOMs

Article 32(1) GDPR requires controllers and processors to implement TOMs that ensure an appropriate level of security. The security of personal data is a requirement and core principle (Article 5(1)(f) GDPR - integrity and confidentiality) relating to the processing of personal data. It is noteworthy that this provision not only provides for the confidentiality or secrecy of personal data, but also requires availability and integrity. Therefore, this provision is characterised by its intersection with information security. In practice, this means that the implementation of appropriate TOMs by the controller and processor should be closely coordinated with the controller's or processor's information security department.

The obligation to implement appropriate TOMs is closely connected to other provisions stipulating the implementation of TOMs (i.e. Article 24 and 25 GDPR). However, while these provisions relate more generally to compliance with the GDPR as a whole, Article 32 GDPR is directed specifically at ensuring an appropriate level of security of personal data.

While this provision obliges the controller and processor to implement appropriate TOMs, it is subject to debate whether it is possible for a data subject to voluntarily waive specific TOMs and therefore accept a higher risk.

The controller and the processor

Article 32 GDPR addresses both the controller (Article 4(7) GDPR) and processor (Article 4(8) GDPR). Hence, in contrast to the general principle that the controller is responsible for GDPR compliance (e.g. for the lawfulness under Article 6(1) GDPR), this provision sets out an additional and direct responsibility of the processor for ensuring security.

It is noteworthy that according to Article 28(3)(c) GDPR, the processing agreement between a controller and a processor must also provide for an obligation of the processor to take all measures required pursuant to Article 32 GDPR. Additionally, Article 28(3)(f) GDPR requires the processor to assists the controller in ensuring compliance with the obligations pursuant to Articles 32 GDPR. The processor is therefore obliged to implement security measures by various norms.

The provision does not, however, directly apply to software and device manufacturers (see also commentary on Article 25 GDPR). Nonetheless, Article 32 GDPR holds immense practical significance when it comes to the controller or processor's 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. Software and device manufacturers are therefore indirectly affected by this provision.

Taking into account

Article 32(1) GDPR outlines the factors that the controller and processor must consider when conducting the assessment on which measures are "appropriate" to contain the risks. These factors are 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.

It should be noted that these factors include the state of the art and the cost of implementation which are not specifically mentioned in the more general obligation of the controller to implement appropriate TOMs under Article 24 GDPR.

State of the art

Article 32(1) GDPR makes use of the same concept - "state of the art" - that was already used in Article 25(1) GDPR (notably, not in Article 24(1) GDPR). Therefore, see comment on Article 25(1) GDPR for more information.

Costs of implementation

Another criterion for selecting appropriate TOMs are the implementation costs. Also this factor was already subject to consideration in the parallel assessment under Article 25(1) GDPR (but not under Article 24(1) GDPR). Therefore, see comment on Article 25(1) GDPR for more information.

Nature, scope, context and purpose of processing

the controller has to take into account the nature, scope, context and purpose of the processing. For these terms, see commentary on Article 24 GDPR which also includes this factors as a necessary consideration.

Risks of varying likelihood and severity for rights and freedoms of natural persons

Finally, controllers and processors have to consider the the risk of varying likelihood and severity for the rights and freedoms of natural persons when deciding on appropriate TOMs. In other words, they should complete a risk assessment before carrying out a processing operation. Since such an assessment is also necessary under other provisions, it is recommended to perform one holistic risk assessment, covering all the requirements. See Article 24 GDPR for more information.

It should be noted, however, that Article 32(2) GDPR requires specific attention on 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. However, the risk should always be considered with the potential harm (i.e. damage); therefore it could be argued that a potential risk of e.g. “destruction” will not be (very) relevant if it causes no tangible harm to a data subject.

For further elements, see commentary under Article 32(2) GDPR below.

Shall implement appropriate TOMs to ensure a level of security appropriate to the risk

Appropriate

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. In other words, the appropriateness refers to the aim of ensuring the security of the personal data by reducing risks connected to the processing activity.

While the level of security must not be less than what is appropriate, it is completely valid to implement measures that go even further than what would normally be considered appropriate. However, it should be noted that a complete certainty of security will in most cases be impossible to achieve and it would in any case be not proportionate to demand such a level of security.

Reference to appropriateness follows from the principle of proportionality under Article 52(1) CFR. See commentary on Article 24(1) GDPR for more information.

Technical and organisational measures

Article 32 GDPR is one of various provisions in the GDPR (e.g. Articles 24 and 25 GDPR) that obliges controllers (and in this case also processors) to implement technical and organisational measures. In the implementation of these measures, these provisions should be read and applied together.

More information on TOMs, see commentary on Article 24(1) GDPR.

Article 32 GDPR provides a list of examples of TOMs which are supposed to increase the level of security of the processing of personal data (see below for more information on these examples). But an appropriate level of security will never be realised by just one isolated security measures; rather, the combination of all TOMs should ensure an appropriate level of security.

Since the security of processing has to be ensured at all times when personal data is processed, the respective TOMs should be chosen and implemented before the processing takes place. The controller and the processor are required to implement suitable TOMs within their respective domains. They must document the rationale behind their selection of these measures and how they evaluated the mentioned criteria.

level of security appropriate to the risk

The aim of the implementation of TOMs is to achieve a level of security which is appropriate to the risk. In other words, the TOMs under this provisions should improve and ensure the security of the personal data processed by the controller or processor.

As mentioned above, the appropriate level of security demanded by this provision stems from the general principle of 'integrity and confidentiality’ under Article 5(1)(f) GDPR. And it should be noted that this principle should be interpreted in the context of the other principles in order to strike a balance between these goals, e.g. the having of redundant storage as a security measure needing to be balanced with the data minimisation principle.

Including inter alia as appropriate

Article 32(1) GDPR enumerates four examples of technical security measures that controllers and processors should implement "as appropriate". These include pseudonymisation and encryption of personal data; the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems; the ability to restore the availability and access to personal data in a timely manner in case of an incident; and a process for regularly testing, assessing and evaluating the effectiveness of security measures.

As this list is purely exemplary, it does not provide for any certainty on the side of the processor or controller. Even implementing all measures stated in the list does not guarantee that the requirements outlined Article 32(1) GDPR could be considered fulfilled. This provision functions as an incomplete catalogue of measures, serving only as guidance for the controller or processor.

(a) Pseudonymisation and encryption

According to Article 4(5) GDPR, "pseudonymisation" means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person. See commentary on Article 4(5) GDPR for more information on pseudonymisation.

"Pseudonymisation may lower the severity of the consequences of unauthorised access to data."

EDPB, ‘Guidelines 1/2025 on Pseudonymisation’, 16 January 2025 (Version for public consultation), margin number 59.

For example: A controller's marketing department runs an analysis of the efficiency of different advertisements sent out to different customer segments. Therefore, the department receives the new sales numbers following the ad campaign. However, in order to reduce the risk for data subjects the department receives only pseudonymised numbers without any means to identify specific data subjects. Only with additional information, it would be possible to attribute the numbers to data subjects.

Although the GDPR does not explicitly define the concept of encryption, it is described in Article 34(3)(a) GDPR according to which encryption is an effective method for rendering personal data inaccessible to unauthorised individuals. The cryptographic techniques employed for encryption, in accordance with the current state of the art, play a vital role in ensuring information security in line with the provisions of Article 32 GDPR.

Symmetric encryption methods, such as AES, Blowfish, IDEA, RC6, and Twofish, employ the same parameter (key) for both encryption and decryption. They are well-suited for tasks like disk or file encryption. On the other hand, asymmetric cryptographic methods, like ECC, ElGamal, and RSA, rely on a key pair consisting of a public key and a private key. The private key is known only to the authorized person. When sending a message to that person, the public key is used to encrypt it, and only the authorized person can decrypt the message using the corresponding private key. Asymmetric cryptographic methods can also be used for electronic signing, ensuring the integrity and authenticity of data.

(b) Ongoing confidentiality, integrity, availability and resilience of processing systems and services

Controllers and processors must implement measures which are able to ensure ongoing confidentiality, integrity, availability, and resilience of the processing systems and services used. The objective is to continuously maintain security requirements over the entire duration of processing ("ongoing..."). This ensures that security measures are consistently applied in a dynamic and ongoing manner.

The term "systems" should be interpreted broadly, encompassing not only technical systems for automated processing but also systems supporting paper-based processing. Similarly, the concept of "services" falls under the same understanding. The individuals involved in handling these systems and services play a role in the processing of personal data. Regular training to maintain an ongoing awareness of risks and the importance of adhering to established rules for data protection are also essential and must not be bypassed.

"Confidentiality" is not only a technical notion but a GDPR principle established in Article 5(1)(f) GDPR. It entails safeguarding information from unauthorized disclosure, allowing access to confidential data and information solely by authorized individuals through approved means. Measures implemented to ensure or facilitate confidentiality include data encryption, access control systems, permissions, and authentication based on one or multiple factors.

"Integrity" is also referred to as a principle in Article 5(1)(f) GDPR. Various references to integrity can be found in different contexts, such as the completeness or authenticity of data (Recital 49) and the right to rectification (Article 16 GDPR). Integrity encompasses both the integrity of data and the proper functioning of systems. Unauthorised modifications constitute a breach of information integrity, impacting not only the actual content but also meta-data such as the author, sender, and creation timestamp. To protect integrity, measures such as electronic signatures or check digits, input controls (logging) to track who accessed, modified, or deleted personal data and when, as well as authorization systems for managing access, are employed. One big risk factor comes from computer viruses which could be reduced by the implementation of firewalls, antivirus software or email filters.

The term "availability" refers to the likelihood that a technical system will fulfill specific requests within an agreed-upon time-frame. Systems and services are considered available if they can be used at any given time. When systems and services are unavailable, controllers and processors are unable to maintain control over the personal data processed through them. Impairments to availability can range from minor delays in usability to complete system failures that last for an extended period. Various factors can contribute to such impairments, including defective hardware, faulty software, power supply issues, or disrupted network connections. To ensure availability, diverse security measures may need to be implemented, such as providing complete replacement systems or individual backup systems, emergency power supplies, and conducting regular functional tests.

Companies will also have to ensure the "resilience" of the systems and services related to processing. The GDPR does not describe which measures contribute positively to resilience. In IT, resilience is the ability of an information system to continue to: (i) operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities; and (ii) recover to an effective operational posture in a time frame consistent with mission needs. In other words, it is about the tolerance and compensatory ability of a system against disturbances.

For example: Suppose there is a network consisting of multiple nodes. If one of the network nodes is targeted and disrupted by an attack, the system demonstrates resilience if the overall functionality of the network remains unaffected because another network node seamlessly takes over its function. In this scenario, the system's resilience is evaluated based on its ability to withstand a certain number of attacks without experiencing significant functional limitations. This measurement, known as "k-resilience," quantifies the system's capability to handle multiple attacks while maintaining its operational integrity.

Resilience measures involve minimising attack possibilities, such as by implementing essential functionality and promptly installing security updates to improve systems security. Additionally, detecting attacks or disruptions and responding appropriately is crucial. Training employees to identify issues and learn from mistakes is also important. Processing should be designed to minimise damage during incidents, such as by transitioning to a fail-safe mode or automatically disconnecting from the Internet in given cases. Creating opportunities for intervention, including human intervention, can further enhance resilience.

(c) Ability to restore availability and access to personal data in a timely manner

Article 32(1)(c) GDPR requires that systems and services be capable of restoring the availability and access to personal data in the event of a physical or technical incident. Unlike in the preceding provision (Article 32(1)(b) GDPR), in this case the incident has occurred (and it must have a technical or physical nature). For example, one can consider scenarios such as physical destruction or loss of storage devices, unauthorised data encryption resulting from a ransomware attack (technical incident), or the destruction of system components due to fire, flooding, or devastation (physical incident). In such cases, controllers and processors must be able to restore availability and access to personal data.

In practice, this security measures have to be implemented before the incident occurred to be effective. Examples of measures include regular backups or even the necessity to store data on multiple in different locations.

The expression "in a timely manner" does not establish a specific deadline, as the timeline depends on the factual circumstances and the seriousness of the issues the controller is dealing with. However, this wording must be understood as indicating that the controller shall restore availability and access as soon as possible.

(d) Regularly testing, assessing and evaluating

Article 30(1)(d) GDPR mentions, as an example of a security measure, the implementation of a process for regularly testing, assessing and evaluating the effectiveness of TOMs for ensuring the security of the processing. This example is related to the accountability principle stipulated in Article 5(2) GDPR.

As the wording of this provision suggests, these are not measures that directly protect data and systems security. These are instead "meta-measures" aiming at guaranteeing that security systems continue to be effective from a dynamic perspective, namely through time. Typical example here is a test where IT experts simulate an external attack, in order to evaluate the response of pre-existing security mechanisms. The GDPR does not specify a time framework for such testing operations. However, frequency in checks mainly depends on the type of risks that a given system must face and the ongoing technological developments in the field concerned.

(2) Certain risks must always be taken into account

Article 32(2) GDPR stipulates that the assessment of the appropriate level of security, as described in Article 32(1) GDPR, has to take into account the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to the processed personal data. The second paragraph therefore builds on Article 32(1) GDPR in the sense that it provides examples of the risks that are most likely to occur, and/or the most severe. Notably, the risks mentioned here are the risks described in case of a personal data breach under Article 4(12) GDPR. These risks are further somewhat similar to the criteria that need to be considered when a Data Protection Impact Assessment ("DPIA") is carried out in accordance with Article 35 GDPR.

Accidental or unlawful

The risks refer to failures that happen either per accident or unlawful. See commentary on Article 4(12) GDPR for more information.

For example: The purposeful deletion of personal data when it is no longer necessary for the processing is not a risk that has to be considered under this provision.

destruction, loss, alteration, unauthorised disclosure, or access

The specific risks mentioned in this provision are identical to those listed in the definition of a personal data breach under Article 4(12) GDPR. Therefore, see commentary on Article 4(12) GDPR for more information.

(3) Codes of conduct and certification mechanisms

Article 32(3) GDPR stipulates that adherence to codes of conduct or certification mechanisms (Articles 40 and 42 GDPR respectively) can be used as an element to demonstrate compliance with the controller's or processor's obligation to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. This provision is supposed to support compliance with the accountability principle established in Article 5(2) GDPR and Article 24(1) GDPR.

It should be noted that neither of these options reduce the controller or processor’s responsibility. However, if asked to prove they took all possible measures to avoid the violation, adherence to these would undoubtedly play an important role.

This provision is basically identical to Article 24(3) GDPR, therefore see commentary on this provision for more information. See also commentary on Article 42(4) GDPR.

(4) Natural persons acting under the authority of the controller or the processor

Most processing operations involve the use of human resources (i.e. the involvement of a natural person in the processing activity). Whenever a person is authorised to access personal data, a data security issue 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, with the only exception of those individual operations that are imposed by EU or national law. 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 (see commentary on Article 29 GDPR). 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".

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.

For example: Potential measures include the selection of trustworthy employees who will reliable follow the controller's or processor's instructions as well as implementing clear internal procedures and instructions and regular training for employees.

Decisions

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