Skip to main content
Privacy Track
Category: Security & Breach Notification

Article 32

Simply put

The evidence provided for this entry does not describe Article 32 of the GDPR. Instead, the sources refer to unrelated legal instruments that each contain an "Article 32": a preliminary hearing under the United States Uniform Code of Military Justice, a provision of the United Nations Charter, and a fundamental-rights provision of the Constitution of India. Because none of the supplied sources concern EU data protection law, no reliable GDPR definition can be drawn from this evidence packet.

Formal definition

The reference "Article 32" is ambiguous across the supplied evidence, which spans three unrelated bodies of law: (1) an Article 32 hearing/investigation under the U.S. Uniform Code of Military Justice, functioning as a preliminary hearing to assess whether probable cause exists before referral to a court-martial (Sources 1, 4, 5); (2) Article 32 of the Charter of the United Nations, addressing participation of non-Security-Council members in disputes before the Council (Source 2); and (3) Article 32 of the Constitution of India, providing the right to move the Supreme Court for enforcement of fundamental rights (Source 3). None of these sources address Article 32 of the EU General Data Protection Regulation (security of processing) or any data protection instrument; accordingly, a data-privacy definition cannot be substantiated from this packet, and readers requiring the GDPR provision should verify against the current official Regulation text and appropriate GDPR-specific sources.

Why it matters

The evidence packet supplied for this entry does not support a definition of Article 32 of the GDPR. The sources instead describe three unrelated legal instruments that each happen to contain an "Article 32": a preliminary hearing under the United States Uniform Code of Military Justice, a provision of the Charter of the United Nations concerning participation of non-Security-Council members in disputes, and a provision of the Constitution of India granting the right to move the Supreme Court for enforcement of fundamental rights. None of these concern EU data protection law.

For a privacy and GDPR audience, this matters primarily as a caution about term ambiguity. "Article 32" is a generic citation form that appears across many legal codes, and search evidence keyed only to the phrase can return material from entirely different fields. Relying on such material to describe a data protection obligation would be inaccurate and potentially misleading in a compliance context.

Because the digest contains no EU data protection content, no GDPR definition of Article 32 can be substantiated from this evidence. Readers who require the GDPR provision commonly cited as Article 32 (which concerns security of processing) should consult the current official text of the Regulation and GDPR-specific authoritative sources rather than relying on this packet.

Who it's relevant to

Data protection officers and compliance leads
Practitioners searching for the GDPR obligation typically cited as Article 32 should be aware that this evidence packet does not contain it. Verify the provision against the current official text of the Regulation and appropriate GDPR-specific sources before relying on it in a compliance program.
Legal researchers and editors
This entry illustrates why a bare citation such as "Article 32" is ambiguous across legal systems, appearing in the U.S. Uniform Code of Military Justice, the UN Charter, and the Constitution of India. Always confirm that source material actually concerns the instrument under discussion before drafting.
Anyone relying on search-derived evidence
The digest here returned non-GDPR material, showing that keyword matches on an article number can surface unrelated bodies of law. Where evidence does not support a claimed definition, the limitation should be stated rather than filled with assumed content.

Inside Article 32

Security of processing obligation
Article 32 of the GDPR requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk presented by the processing of personal data.
Risk-based standard
The appropriate level of security is determined by reference to the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, weighed against the risk to the rights and freedoms of natural persons. There is no single fixed security standard; the assessment is contextual.
Illustrative measures
The Article lists measures that may be appropriate as examples rather than mandatory requirements, including, where relevant, pseudonymisation and encryption of personal data; the ability to ensure ongoing confidentiality, integrity, availability and resilience of processing systems and services; the ability to restore availability and access to personal data in a timely manner after an incident; and a process for regularly testing, assessing and evaluating the effectiveness of security measures.
Application to both controllers and processors
The security obligation applies to both controllers and processors. This complements the Article 28 requirement that a processor be engaged under a contract obliging it to assist with, and implement, appropriate security measures.
Consideration of specific risks
The assessment should account in particular for the risks presented by processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.
Instructed processing and adherence to authorised access
The Article addresses ensuring that persons acting under the authority of the controller or processor who have access to personal data process it only on instructions, unless required to do otherwise by Union or Member State law. Adherence to approved codes of conduct or certification may be used as an element to demonstrate compliance.

Common questions

Answers to the questions practitioners most commonly ask about Article 32.

Does Article 32 require encryption of all personal data?
No. Article 32 lists encryption as one example of a measure that may be appropriate, alongside others such as pseudonymisation, but it does not mandate encryption in every case. The Article adopts a risk-based approach: the controller and processor must implement measures appropriate to the risk, taking into account the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing. Whether encryption is required in a given scenario is subject to assessment rather than being an absolute obligation.
Is Article 32 only the controller's responsibility?
No. Article 32 imposes security-of-processing obligations on both controllers and processors. This is one of the provisions that places direct obligations on processors, not solely on controllers. The precise allocation of responsibilities between the parties is typically addressed in the contract required under the separate provisions governing processor arrangements, but the statutory duty to implement appropriate security measures applies to each in its own capacity.
How should an organisation decide which security measures are 'appropriate' under Article 32?
Article 32 frames appropriateness by reference to several factors: the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, weighed against the risk to the rights and freedoms of individuals. In practice this generally involves a documented risk assessment that maps the likelihood and severity of potential harm and then selects technical and organisational measures proportionate to that risk. Because appropriateness is context-dependent, measures that suffice for one processing activity may be inadequate for another, and expectations can evolve as technology and regulator guidance develop.
What kinds of measures can help demonstrate compliance with Article 32?
Article 32 refers, as examples, to pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems and services; the ability to restore availability and access to personal data in a timely manner after an incident; and a process for regularly testing, assessing, and evaluating the effectiveness of the measures. These are illustrative rather than exhaustive, and the appropriate combination is subject to assessment for each processing context.
How does Article 32 relate to accountability and record-keeping?
Article 32 requires that measures be appropriate and, through its testing-and-evaluation element, that their effectiveness be reviewed on an ongoing basis. Under the GDPR's broader accountability framework, organisations are generally expected to be able to evidence the decisions behind their chosen measures. Maintaining documentation of the risk assessment, the measures selected, and the results of periodic testing typically supports the ability to demonstrate compliance, though the specific form of documentation is not prescribed by Article 32 itself.
How do Article 32 obligations feature in controller-processor arrangements?
Both controllers and processors carry security obligations under Article 32 in their own right. In practice, security requirements are also reflected contractually, and a controller generally needs to satisfy itself that any processor it engages can provide sufficient guarantees regarding appropriate technical and organisational measures. The detailed contractual requirements for engaging a processor sit in a separate provision of the GDPR, so Article 32 should be read together with those obligations rather than in isolation. Readers should verify the precise contractual terms against the current text and applicable guidance.

Common misconceptions

Article 32 prescribes a specific checklist of security controls that, if followed, guarantees compliance.
Article 32 sets a risk-based standard of appropriateness rather than a fixed technical checklist. The measures listed (such as encryption and pseudonymisation) are illustrative examples, and their suitability is subject to assessment against the risk and context of the specific processing. Compliance is context and risk dependent and cannot generally be treated as fully achieved by any single measure.
Encryption or pseudonymisation is always mandatory under Article 32.
The Article references pseudonymisation and encryption as measures that may be appropriate, introduced with qualifying language, not as universal mandatory requirements. Whether they are required in a given case typically depends on the risk assessment and the nature of the processing.
Only the controller is responsible for security under Article 32.
Article 32 applies to both controllers and processors. Processor obligations are also reinforced through the Article 28 contractual arrangements, so responsibility for appropriate security is generally shared according to the respective roles.

Best practices

Document a risk assessment that identifies the risks to the rights and freedoms of natural persons and maps chosen technical and organisational measures to those risks, so the appropriateness required by Article 32 can be demonstrated.
Evaluate, and record the reasoning behind, whether measures such as pseudonymisation and encryption are appropriate for each processing activity rather than assuming they are always required or never needed.
Establish and document processes to ensure ongoing confidentiality, integrity, availability and resilience, including the ability to restore access to personal data in a timely manner after an incident.
Implement a routine for regularly testing, assessing and evaluating the effectiveness of security measures, and keep evidence of those reviews, updating measures as risks and the state of the art change.
Address both controller and processor responsibilities, ensuring that Article 28 processing contracts require processors to implement appropriate security and to restrict access to authorised, instructed personnel.
Where available, consider using adherence to approved codes of conduct or certification mechanisms as one element to help demonstrate compliance, while verifying current requirements against the official text and applicable regulator guidance.