Category: Security & Breach Notification

Security of Processing

Also known as: Data Security, Article 32 Security

Simply put

Security of processing is the requirement to protect personal data by putting in place suitable technical and organisational measures. In practice this means steps such as securing systems and workstations to keep data confidential and available, so that personal data is not lost, altered, or accessed by people who should not see it. The exact measures expected depend on the circumstances and are assessed against the level of risk involved.

Formal definition

Security of processing refers to the obligation, addressed in Article 32 of the GDPR (and correspondingly under the UK GDPR), to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The obligation applies to both controllers and processors and is risk-based rather than prescriptive: measures should reflect the state of the art, costs of implementation, and the nature, scope, context, and purposes of processing, as well as the varying likelihood and severity of risks to individuals. Recognised objectives include ensuring the ongoing confidentiality, integrity, availability, and resilience of processing systems and services, and the ability to restore access to personal data in a timely manner following an incident. Practical examples cited in regulatory guidance include measures such as firewalls, anti-virus software, and tools to block access to malicious sites, though appropriate measures must be determined case by case through assessment. This entry describes the general framework; specific expectations may evolve with guidance and technology, and readers should verify requirements against the current official text and applicable national implementing law.

Why it matters

Security of processing sits at the heart of data protection compliance because it operationalises the principle that personal data must be handled securely. Without appropriate technical and organisational measures, other obligations, such as lawfulness of processing or respecting individual rights, can be undermined by unauthorised access, loss, or alteration of data. The obligation applies to both controllers and processors, meaning responsibility for security is shared across the processing chain and cannot simply be delegated away.

Because the requirement is risk-based rather than prescriptive, organisations must actively assess what is appropriate in their own context. This matters for accountability: a measure that is adequate for a low-risk, small-scale processing activity may fall short where processing involves large volumes of data or heightened risks to individuals. Regulators generally expect organisations to be able to demonstrate the reasoning behind the measures they have chosen, rather than to point to a fixed checklist.

The standard is also dynamic. Because appropriate measures reflect the state of the art and evolving threats, what is considered sufficient can change over time and may diverge as guidance and technology develop. Organisations should therefore treat security of processing as an ongoing obligation subject to periodic review, and verify their approach against the current official text and applicable national implementing law rather than relying on a single snapshot.

Who it's relevant to

Data controllers

Controllers determine the purposes and means of processing and carry the primary responsibility for ensuring security measures are appropriate to the risk. They typically need to document their risk assessment and be able to demonstrate why the chosen technical and organisational measures are suitable in their specific context.

Data processors

The obligation under Article 32 applies directly to processors as well as controllers. Processors handling personal data on behalf of a controller are generally expected to implement appropriate security measures and to reflect these commitments within their contractual arrangements, though the precise allocation of responsibilities should be confirmed against the governing agreement.

Security and IT engineers

Technical teams translate the risk-based standard into operational controls, such as securing systems and workstations to protect confidentiality, integrity, availability, and resilience. Because appropriate measures reflect the state of the art and evolving threats, engineers generally need to keep controls under review rather than treating them as fixed.

Data protection officers and compliance leads

DPOs and compliance functions help assess whether measures are appropriate to the risk, maintain the documentation supporting those decisions, and monitor for divergence in regulatory guidance. They typically verify that the organisation's approach aligns with the current official text and any applicable national implementing law.

Inside Security of Processing

Appropriate technical and organisational measures (TOMs)

Security of processing under Article 32 GDPR requires controllers and processors to implement measures appropriate to the risk. These span technical controls (for example, access controls, network security) and organisational controls (for example, policies, staff training, governance). The Regulation does not prescribe a fixed checklist; appropriateness is assessed against the specific processing and its risks.

Risk-based calibration

The required level of security is determined by weighing the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing against the risks to the rights and freedoms of natural persons. This means security expectations scale with risk rather than being uniform across all processing.

Illustrative measures cited in Article 32

Article 32 names examples that may be appropriate, including the pseudonymisation and encryption of personal data. These are illustrative options to consider following a risk assessment, not mandatory in every case; their suitability is subject to assessment for the specific processing.

Confidentiality, integrity, availability and resilience

The Regulation refers to ensuring the ongoing confidentiality, integrity, availability and resilience of processing systems and services. This frames security as protecting data against unauthorised access, unauthorised alteration, and loss of access, and maintaining service continuity.

Restoration and testing

Article 32 refers to the ability to restore availability and access to personal data in a timely manner following a physical or technical incident, and to a process for regularly testing, assessing and evaluating the effectiveness of measures. Security is treated as an ongoing, reviewable obligation rather than a one-time deployment.

Shared but distinct obligations of controllers and processors

Security of processing obligations apply to both controllers and processors. These are distinct roles, and the allocation of specific security responsibilities is typically addressed in the arrangement between them, including the security-related content required in a processor contract under Article 28. Article 32 should not be conflated with Article 28.

Common questions

Answers to the questions practitioners most commonly ask about Security of Processing.

Does Article 32 require encryption of all personal data?

No. Article 32 references encryption and pseudonymisation as examples of possible measures, but it does not mandate encryption in all cases. The Regulation adopts a risk-based approach: controllers and processors 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. Encryption may be appropriate for certain processing but is not a universal legal requirement, and the appropriateness of any measure is subject to assessment.

Is security of processing solely the controller's responsibility?

No. Article 32 places obligations on both the controller and the processor. Each must implement appropriate technical and organisational measures for the processing they carry out. This is distinct from the arrangement between them under a data processing agreement (Article 28), which allocates responsibilities contractually. In most cases, both parties have direct statutory security obligations that exist independently of their contract.

How do we determine which security measures are 'appropriate' for our processing?

Appropriateness is generally assessed by weighing the risks presented by the processing against the factors named in Article 32, including the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing. The assessment typically considers the likelihood and severity of risk to the rights and freedoms of individuals. Because this is context-dependent, the same measure may be appropriate for one processing activity and insufficient for another, and the analysis should be documented and revisited over time.

What role do the specific measures listed in Article 32(1) play in practice?

Article 32(1) lists examples such as pseudonymisation and encryption; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems and services; the ability to restore availability and access to personal data in a timely manner following an incident; and a process for regularly testing, assessing, and evaluating the effectiveness of measures. These are illustrative considerations rather than a mandatory checklist, and which ones apply typically depends on the risk assessment for the processing in question.

How can adherence to a code of conduct or certification support demonstrating compliance with Article 32?

Article 32 indicates that adherence to an approved code of conduct or an approved certification mechanism may be used as an element to demonstrate compliance with the security requirements. Such adherence is generally treated as evidence rather than as conclusive proof of compliance, and it does not remove the need to assess and maintain appropriate measures. Availability and scope of relevant codes and certifications can vary, so readers should verify current options.

How does security of processing relate to breach notification obligations?

Security of processing under Article 32 concerns the preventive and ongoing measures protecting personal data, while breach notification obligations are addressed separately (notification to the supervisory authority and, where relevant, communication to affected individuals). The measures in place can affect both the likelihood of a breach and the assessment of risk to individuals if one occurs. The two areas are related but distinct, and each should be addressed on its own terms and verified against the current text.

Common misconceptions

GDPR mandates encryption of all personal data.

Encryption is cited in Article 32 as an example of a measure that may be appropriate, not as a universal requirement. Whether encryption (or pseudonymisation) is required in a given case is subject to a risk-based assessment considering factors such as the state of the art, costs, and the risks to individuals.

Implementing a defined set of security controls makes processing fully compliant and secure.

Compliance with security of processing is context and risk dependent, and Article 32 contemplates regularly testing, assessing and evaluating effectiveness. There is no fixed checklist that guarantees compliance, and measures generally need to be reviewed and updated as risks and the state of the art change.

Security of processing is solely the controller's responsibility.

Both controllers and processors have security obligations. The controller and processor roles are distinct, and the specific security responsibilities are typically allocated through their contractual arrangement; the reader should verify the precise obligations against the current official text.

Best practices

Conduct and document a risk assessment that weighs the nature, scope, context and purposes of the processing against the risks to individuals, and use it to justify the security measures selected.

Consider the illustrative measures referenced in Article 32, such as pseudonymisation and encryption, and record the reasoning for adopting or not adopting each based on the assessed risk.

Address confidentiality, integrity, availability and resilience together, including maintaining an ability to restore availability and access to personal data in a timely manner after an incident.

Establish a process to regularly test, assess and evaluate the effectiveness of technical and organisational measures, and update them as risks and the state of the art evolve.

Clearly allocate security responsibilities between controller and processor in their contractual arrangement, keeping in mind the distinct requirements of processor contracts and avoiding conflation with other obligations.

Verify the specific security requirements against the current official text of the applicable Regulation and any relevant national or UK GDPR provisions, as member state or regulator positions may vary.