GDPR Article 32: Security of Processing

Analysis for Advanced Privacy and Security Practitioners

Introduction

General Data Protection Regulation (GDPR) Article 32 is the principal cybersecurity and information security provision within the GDPR framework. It establishes a legal obligation for both controllers and processors to implement "appropriate technical and organisational measures" (TOMs) to ensure a level of security appropriate to the risk posed by processing activities. Unlike prescriptive security regulations, Article 32 adopts a risk-based and technology-neutral approach, requiring organisations to continuously evaluate threats, vulnerabilities, business context, and impacts on data subjects.

Article 32 Core Concerns

  • Confidentiality of personal data
  • Integrity of personal data
  • Availability of personal data
  • Resilience of systems and services
  • Continuous assurance through testing and evaluation
  • Risk-based governance of security controls

Beyond Unauthorised Access

Unlike many cybersecurity frameworks, GDPR security obligations are not limited to preventing unauthorised access. They also address:

  • Accidental loss and unlawful destruction
  • Availability failures and operational resilience
  • Human error and insider misuse
  • Supply-chain risks

The Legal Structure of Article 32

Article 32(1)

Appropriate Technical and Organisational Measures

Article 32(1) requires organisations to consider a comprehensive set of factors when determining the appropriate level of security. The provision is deliberately flexible, demanding contextual judgement rather than prescriptive compliance.

State of the Art

Adopting security measures reasonably expected from a competent organisation facing comparable risks — not necessarily the most expensive technology.

Cost of Implementation

Proportionality between investment and risk reduction is a recognised factor in supervisory authority assessments.

Nature, Scope & Context

The character of processing activities, volume of data subjects, and operational environment all inform control selection.

Risk Likelihood & Severity

Controls must be calibrated to the probability and magnitude of harm to the rights and freedoms of natural persons.

Supervisory authorities increasingly interpret state-of-the-art security as requiring multi-factor authentication, strong encryption, continuous monitoring, secure development practices, and timely vulnerability management.

✓ Appropriate Example

A financial institution encrypts databases, deploys privileged access management, performs penetration testing, and maintains security monitoring.

✗ Potentially Inappropriate

The same institution relies solely on passwords and annual security reviews despite processing large volumes of sensitive financial data.

Article 32(1)(a): Pseudonymisation and Encryption

Article 32 specifically identifies pseudonymisation and encryption as examples of measures that may be appropriate. These are not mandatory requirements but are strongly indicative of sound security practice.

Pseudonymisation

Reduces identifiability by replacing direct identifiers with substitutes. Instead of storing Name, National ID, and Email — the system stores Subject ID: A12849 with identifiers held separately.

Appropriate Use Cases
  • Clinical research
  • Analytics platforms
  • Testing environments
  • Machine learning development

Encryption

Protects data at rest, in transit, in backups, and on portable devices.

Appropriate
  • AES-256 database encryption
  • TLS 1.3 communications
  • Hardware Security Module (HSM) key management
Inappropriate
  • Legacy SSL protocols
  • Shared encryption keys
  • Unencrypted backup tapes

Article 32(1)(b): Confidentiality, Integrity, Availability and Resilience

This provision effectively incorporates modern information security principles — the classic CIA triad extended with a fourth pillar of operational resilience that is often misunderstood in practice.

Confidentiality

Ensures only authorised parties access personal data.

  • Role-based access control
  • Multi-factor authentication
  • Data loss prevention
  • Network segmentation

Integrity

Protects against unauthorised modification of personal data.

  • Checksums and immutable logging
  • Digital signatures
  • Change management controls

Availability

Ensures systems remain accessible when required.

  • High-availability architecture
  • Redundant infrastructure
  • Disaster recovery capability

Resilience

The capability to continue operations during disruption, recover rapidly, and adapt to changing threat conditions.

  • Active-active data centres
  • Ransomware recovery environments
  • Business continuity exercises

Article 32(1)(c) & (d): Restoration and Testing

Article 32(1)(c)

Timely Restoration

Organisations must be able to restore access and availability after incidents. This extends well beyond simple backups and requires structured recovery planning.

Recovery Time Objectives (RTO)

Maximum tolerable downtime before restoration must be achieved.

Recovery Point Objectives (RPO)

Maximum acceptable data loss measured in time.

Backup Integrity Verification

Backups must be validated — not merely created.

Recovery Testing

Quarterly exercises and documented recovery procedures are expected.

Article 32(1)(d)

Testing and Evaluation

Security measures must be continuously evaluated. This creates an ongoing compliance obligation — not a one-time implementation exercise.

Vulnerability Scanning

Regular automated scanning of the attack surface.

Penetration Testing

Annual or more frequent adversarial simulation.

Red Team Exercises

Advanced threat simulation for mature programmes.

Control Effectiveness Reviews

Security audits and metrics programmes to validate ongoing adequacy.

Article 32(2), (3) & (4): Risk, Certification and Personnel

Article 32(2) — Risk Assessment

Organisations must evaluate risks including destruction, loss, alteration, unauthorised disclosure, and unauthorised access. Article 32 implicitly requires:

  • Threat modelling
  • Risk analysis
  • Asset classification
  • Impact assessment

Organisations that cannot demonstrate risk assessment frequently struggle to justify why controls were selected.

Article 32(3) — Codes of Conduct & Certification

Compliance may be demonstrated through approved mechanisms:

  • Article 40 Codes of Conduct
  • Article 42 Certification Mechanisms
  • Europrivacy certifications
  • National GDPR certification frameworks
  • Sector-specific assurance schemes

Article 32(4) — Personnel Controls

Human factors are explicitly addressed. Personnel must only process data according to instructions. Required safeguards include:

  • Security awareness training
  • Confidentiality agreements
  • Access authorisation procedures
  • Privileged user monitoring
  • Joiner-Mover-Leaver processes

GDPR Articles that Intersect with Article 32

Article 32 does not operate in isolation. It forms part of an interconnected web of GDPR obligations that together constitute a comprehensive data protection regime.

Art. 5(1)(f)

Establishes security as a core processing principle; Article 32 operationalises it.

Art. 25

Security architecture integrated into system design; frequently assessed alongside Article 32.

Art. 33 & 34

Security failures trigger notification obligations; encryption can reduce Article 34 requirements.

Art. 35 & 36

DPIAs inform Article 32 controls; high residual risks may require supervisory authority engagement.

Art. 40 & 42

Codes of conduct and certification provide evidentiary support for security adequacy.

Twenty Cross-Cutting Controls: Part I

Controls 1–5

Advanced Article 32 compliance requires a comprehensive programme of technical and organisational measures. The following twenty controls represent the core architecture of a defensible security framework.

1

Enterprise Risk Management Programme

  • Risk identification and threat assessment
  • Risk treatment planning
  • Residual risk acceptance
2

Data Classification Framework

  • Public / Internal / Confidential
  • Restricted and special-category personal data
3

Identity and Access Management

  • RBAC and least privilege
  • Access reviews and segregation of duties
4

Multi-Factor Authentication

  • Administrative accounts
  • Remote access
  • High-risk processing systems
5

Encryption Strategy

  • Data at rest and in transit
  • Key lifecycle management
1

Pseudonymisation Programme

  • Research datasets
  • Analytics platforms
  • Testing environments
2

Secure Software Development Lifecycle

  • Threat modelling
  • Secure coding standards
  • Security testing integration
3

Vulnerability Management

  • Asset discovery
  • Patch governance
  • Remediation tracking
4

Penetration Testing Programme

  • External and internal testing
  • Application-layer testing
5

Security Monitoring and Logging

  • SIEM deployment
  • Log correlation and anomaly detection

Twenty Cross-Cutting Controls: Part II

Controls 11–15

Incident Response Capability

  • Detection and containment
  • Eradication and recovery

Backup and Recovery Programme

  • Immutable backups
  • Offline storage
  • Recovery testing

Business Continuity Management

  • Continuity planning
  • Operational resilience
  • Crisis management

Third-Party Security Governance

  • Vendor due diligence
  • Security assessments
  • Contractual safeguards

Security Awareness Training

  • Phishing resilience
  • Insider threat awareness
  • Privacy obligations

Twenty Cross-Cutting Controls: Part III

Controls 16–20

Privileged Access Management

  • Session monitoring
  • Credential vaulting
  • Just-in-time access

Data Loss Prevention Controls

  • Endpoint protection
  • Email monitoring
  • Cloud monitoring

Physical Security Controls

  • Badge access systems
  • CCTV surveillance
  • Secure server facilities

Continuous Assurance Programme

  • Audits and control testing
  • Maturity assessments

Governance, Metrics and Reporting

  • Board oversight
  • Security KPIs and risk dashboards
  • Compliance reporting

Common Article 32 Enforcement Failures

Advanced practitioners should recognise recurring supervisory authority findings. These failures appear consistently across enforcement actions from data protection authorities across the EU and EEA.

Authentication Failures

  • Lack of multi-factor authentication
  • Weak password policies

Data Protection Gaps

  • Unencrypted databases
  • Excessive access privileges
  • Missing logging

Operational Failures

  • Untested backups
  • Inadequate processor oversight
  • Poor vulnerability management

Governance Deficiencies

  • Incomplete incident response capability
  • Absence of risk assessment documentation

Strategic Lessons for Advanced Practitioners

Article 32 is not a checklist requirement; it is a continuous risk-management obligation.

Compliance is Demonstrated, Not Assumed

Compliance is measured not merely by implemented controls but by the organisation's ability to demonstrate why those controls are appropriate. Evidence is as important as implementation.

"Appropriate Security" is a Moving Target

The concept of appropriate security evolves with technology, threat intelligence, supervisory authority expectations, and industry practice. Organisations must maintain continuous awareness of the changing landscape.

Evidence Must Cover the Full Lifecycle

Organisations must be able to demonstrate: risk assessment, control selection rationale, operational effectiveness, continuous monitoring, and ongoing improvement — not merely point-in-time snapshots.

Convergence with Modern Frameworks

Mature Article 32 compliance increasingly converges with NIST Cybersecurity Framework, ISO/IEC 27001, and zero-trust architectures — but remains uniquely focused on protecting the fundamental rights and freedoms of data subjects rather than merely protecting information assets.

Article 32 as the Operational Security Backbone

In advanced GDPR practice, Article 32 should be understood as the operational security backbone of the entire GDPR regime — linking accountability, privacy-by-design, breach management, processor governance, risk management, and data-subject protection into a single defensible security framework.

32

GDPR Articles

Intersecting obligations that Article 32 operationalises across the regulation.

20

Core Controls

Cross-cutting technical and organisational measures for a defensible compliance programme.

4

Security Pillars

Confidentiality, Integrity, Availability, and Resilience — the foundations of Article 32(1)(b).

Datari Home