GDPR Article 32: Security of Processing Requirements (2026)

GDPR Article 32: Security of Processing

GDPR Article 32 requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." It is a risk-based, outcome-focused obligation — not a fixed checklist — but it names four measures explicitly: pseudonymisation and encryption; the ongoing confidentiality, integrity, availability, and resilience of systems; the ability to restore availability after an incident; and a process for regularly testing the effectiveness of those measures. "Appropriate" is judged against the state of the art, the cost of implementation, and the nature, scope, context, purposes, and risk of the processing.

Article 32 is the article a security review, an auditor, or a supervisory authority actually tests you against. "Insufficient technical and organisational measures to ensure information security" is one of the most frequently fined GDPR categories — 418 fines at an average of EUR 2.0 million, according to the CMS GDPR Enforcement Tracker — and the number of such fines rose more than 40% between 2024 and 2025. For B2B companies, the hard part is not knowing that security is required; it is proving your measures were "appropriate" both before and after an incident.

Key Takeaways

• The standard is "appropriate," not "maximum." Security must be proportionate to the risk — assessed against the state of the art, cost, and the nature, scope, context, and purposes of processing (Article 32(1)).
• It binds processors directly. Article 32 applies to both controllers and processors — so as a B2B SaaS vendor, it is your legal obligation, not just your customer's.
• Encryption and pseudonymisation are named explicitly (Article 32(1)(a)). They are not the only measures, but their absence for sensitive data is a recurring finding in enforcement.
• "Regularly testing" is a requirement, not a nice-to-have (Article 32(1)(d)) — a one-time control set does not satisfy the article.
• The measures must be demonstrable. The accountability principle (Article 5(2)) means an undocumented control, for enforcement purposes, is a control that does not exist.
• Fines are real and large: Meta EUR 91M (Sept 2024, plaintext passwords — Art 32(1)); Capita GBP 14M (UK ICO, 2025 — Art 32); Vodafone Germany EUR 45M (2025).

Jump to:

• What Article 32 Requires
• The Risk-Based Balancing Test
• The Four Named Measures
• Is Encryption Mandatory?
• How to Demonstrate Article 32 Compliance
• ISO 27001 Annex A ↔ Article 32 Mapping
• Article 32 Compliance Checklist
• Fines and Enforcement
• The UK and Norway Position
• Operationalising Article 32

---

What Article 32 Requires

Article 32(1) of Regulation (EU) 2016/679 sets the core obligation:

"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."

Two features make Article 32 different from a prescriptive security standard. First, the obligation is shared: it falls on the controller and the processor. For a B2B SaaS company that processes customer data, Article 32 is a direct legal duty — you cannot delegate it to your customer or hide behind their instructions. Second, it is risk-based and technology-neutral: the article deliberately avoids a fixed list of controls, because "appropriate" security in 2016 is not "appropriate" security today. What is expected of you scales with the sensitivity and scale of what you process.

Article 32(2) sharpens the risk lens, requiring account to 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." Article 32(4) adds a personnel dimension: anyone acting under your authority must process personal data only on instructions, not at their own discretion.

---

The Risk-Based Balancing Test

The phrase that does the most work in Article 32 is "appropriate to the risk." Appropriateness is decided by balancing four inputs, spelled out in the article itself:

Factor	What it means in practice
State of the art	Measures must keep pace with current, widely adopted security practice. Yesterday's baseline (e.g. unencrypted transport, SHA-1 hashing) is no longer "appropriate."
Costs of implementation	Cost is a legitimate factor — but it is weighed against risk, not used to excuse cheap-and-inadequate controls where the data is sensitive.
Nature, scope, context and purposes	Processing special-category data, or data at large scale, raises the bar. A payroll platform is held to a higher standard than a low-risk marketing list.
Risk to rights and freedoms	The likelihood and severity of harm to individuals — identity theft, financial loss, discrimination — set the target level of security.

The EDPB One-Stop-Shop case digest on security and breach notification shows how supervisory authorities apply this in real decisions: authorities have found that where a service handles data "about a large number of users, higher requirements must be imposed on the controller." The digest also confirms a crucial nuance from the Court of Justice — the mere existence of a breach does not, by itself, prove the measures were inappropriate. The question is always whether the measures were appropriate given the risk, judged at the time.

That is the double-edged nature of Article 32: it gives you flexibility, but it also means "we had a firewall" is not a defence. You must be able to reconstruct the risk assessment that justified your control choices.

---

The Four Named Measures (Article 32(1)(a)–(d))

Article 32(1) lists four illustrative measures "as appropriate." They are not an exhaustive list, but they are the anchors every assessment starts from:

• (a) Pseudonymisation and encryption of personal data — reducing the identifiability of data and rendering it unintelligible to unauthorised parties.
• (b) Confidentiality, integrity, availability, and resilience — the classic CIA triad plus resilience: the ongoing ability of systems and services to withstand and recover from adverse events. This maps to access control, MFA, network security, and high-availability architecture.
• (c) Restore availability and access in a timely manner after a physical or technical incident — in practice, tested backups and a disaster-recovery / business-continuity capability.
• (d) A process for regularly testing, assessing, and evaluating the effectiveness of measures — penetration testing, vulnerability management, and periodic control review. In the EDPB case digest, one authority specifically noted that Article 32(1)(d) requires testing "all likely outcomes" during development of software that processes personal data.

The inclusion of (d) is the reason Article 32 is a continuous obligation. A control set that was appropriate at launch decays: certificates expire, dependencies gain CVEs, and the state of the art moves. Article 32 requires a process that keeps proving the controls still work.

---

Is Encryption Mandatory?

Strictly, no single measure is mandatory in every case — Article 32 is risk-based. But encryption is one of only two measures named in Article 32(1)(a), and in practice supervisory authorities treat it as a default expectation for personal data at rest and in transit. The EDPB case digest records authorities finding an Article 32 violation where a company used HTTPS for its website generally but not on contact-form pages that transmitted names, email addresses, and free text — the missing encryption alone constituted the breach.

The most consequential single enforcement example is Meta's EUR 91 million fine from Ireland's DPC (September 2024) for storing user passwords in plaintext. The DPC found breaches of Articles 5(1)(f), 32(1), 33(1), and 33(5) — the plaintext storage was, at its core, an Article 32 failure.

Encryption also has a decisive downstream benefit: under Article 34(3), effective encryption that renders breached data unintelligible removes the obligation to communicate the breach to affected individuals. Strong Article 32 measures are therefore not only a compliance requirement in their own right — they are the fact that most often keeps a breach from becoming a public, customer-facing event.

---

How to Demonstrate Article 32 Compliance

Article 32 is only half the obligation. The accountability principle (Article 5(2)) requires you to demonstrate compliance — which means every measure needs evidence a customer, auditor, or supervisory authority can inspect. This is where most B2B companies fall short: the controls exist, but the proof is scattered across screenshots, spreadsheets, and tribal knowledge.

The practical model is to map each limb of Article 32(1) to a concrete TOM and then to a place that TOM is evidenced — ideally a public or gated Trust Center where prospects and auditors can self-serve:

Article 32 requirement	Concrete technical/organisational measure	Where it lives (the evidence)
32(1)(a) — Encryption & pseudonymisation	TLS 1.2+ in transit; AES-256 at rest; tokenised identifiers	Security whitepaper / TOMs document in the Trust Center
32(1)(b) — Confidentiality & access control	RBAC, SSO/SAML, enforced MFA, least-privilege reviews	Access-control policy + access-review logs
32(1)(b) — Integrity & resilience	Change management, tamper-evident logging, multi-AZ deployment	Architecture overview + logging/monitoring evidence
32(1)(c) — Restore availability	Automated encrypted backups, tested DR runbook, defined RTO/RPO	Backup & business-continuity policy + last DR-test date
32(1)(d) — Regular testing	Annual penetration test, continuous vulnerability scanning, control reviews	Pen-test summary + vulnerability-management evidence
Cross-cutting — organisational	Security policies, staff training, incident-response plan, vendor due diligence	Policy pack + training records + subprocessor list

The pattern that distinguishes companies that pass procurement from those that stall is not stronger controls — it is current, retrievable proof. When a prospect's security team asks "how do you meet Article 32(1)(d)?", the answer should be a link to a dated penetration-test summary, not a three-week email thread.

---

ISO 27001 Annex A ↔ Article 32 Mapping

The most efficient way to operationalise Article 32 is to run an ISO/IEC 27001 Information Security Management System (ISMS). ISO 27001 is not legally required by the GDPR, but Article 32(3) explicitly allows adherence to an approved certification mechanism to be used as an element to demonstrate compliance — and the ISO 27001:2022 Annex A controls map cleanly onto the four Article 32 limbs:

Article 32 requirement	ISO/IEC 27001:2022 Annex A controls
32(1)(a) Encryption / pseudonymisation	A.8.24 Use of cryptography
32(1)(b) Confidentiality & access control	A.5.15 Access control; A.8.2 Privileged access rights; A.8.3 Information access restriction; A.8.5 Secure authentication
32(1)(b) Integrity & resilience	A.8.16 Monitoring activities; A.8.32 Change management; A.8.6 Capacity management
32(1)(c) Restore availability	A.8.13 Information backup; A.5.29 Security during disruption; A.5.30 ICT readiness for business continuity
32(1)(d) Regular testing	A.8.8 Management of technical vulnerabilities; A.8.29 Security testing in development and acceptance; A.5.35 Independent review of information security

This mapping is the heart of the ISMS-plus-Trust-Center approach: the ISMS gives you the internal governance that produces appropriate measures, and the Trust Center gives you the external demonstration that Article 5(2) demands. An ISO 27001 certificate and Statement of Applicability become a shorthand your customers already trust — which is why "ISO 27001 certified" is one of the first things a European procurement team looks for.

---

Article 32 Compliance Checklist

Use this as a fast self-assessment. Each item should be evidenced, not just implemented:

• Risk assessment documenting why your measures are appropriate to the risk of your processing
• Encryption of personal data in transit (TLS 1.2+) and at rest (e.g. AES-256)
• Pseudonymisation where it reduces risk without defeating the purpose
• Access control — RBAC, SSO, enforced MFA, and periodic least-privilege reviews
• Logging and monitoring sufficient to detect and reconstruct security events
• Tested backups and a documented, exercised disaster-recovery / business-continuity plan (RTO/RPO defined)
• A regular testing programme — at least an annual penetration test plus continuous vulnerability scanning
• Security policies and evidence of staff security-awareness training
• A tested incident-response plan wired to your Article 33 breach-notification workflow
• Vendor / subprocessor due diligence so your suppliers meet an equivalent standard
• Current, retrievable evidence for every item above, hosted where customers and auditors can find it

---

Fines and Enforcement

Violations of Article 32 fall in the lower fine tier under Article 83(4): up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. But "lower tier" is deceptive — security fines are among the most frequent in the GDPR:

• Meta — EUR 91 million (Ireland DPC, September 2024): for storing user passwords in plaintext — expressly a breach of Article 32(1) (alongside Articles 5(1)(f), 33(1), and 33(5)).
• Capita plc — GBP 14 million (UK ICO, October 2025): following a 2023 cyber-attack that exfiltrated data on around 6.6 million people; the ICO found infringements of Articles 5(1)(f), 32(1), and 32(2) UK GDPR (an initially proposed GBP 45 million, reduced on settlement).
• Vodafone Germany — EUR 45 million (BfDI, 2025): including penalties for security flaws and inadequate oversight of data processors.
• Meta — EUR 251 million (Ireland DPC, December 2024): for the 2018 Facebook breach affecting ~29 million users — imposed for data-protection-by-design and by-default failures (Article 25) and breach-notification failures (Article 33), a reminder that weak security engineering is penalised across several articles, not only Article 32.

The category matters more than any single case. "Insufficient technical and organisational measures to ensure information security" accounts for 418 fines at an average of EUR 2.0 million according to the CMS Enforcement Tracker, and the number of such fines rose more than 40% between 2024 and 2025 (from 69 to 97 cases per Surfshark's analysis). Cumulative GDPR fines reached EUR 7.1 billion by January 2026, with roughly EUR 1.2 billion issued in 2025 alone, per the DLA Piper GDPR Fines and Data Breach Survey (January 2026).

---

The UK and Norway Position

Article 32 is a pan-European standard, and the security-of-processing obligation is remarkably consistent across the wider European compliance landscape.

United Kingdom. UK GDPR retains the Article 32 security obligation in identical substance, enforced by the Information Commissioner's Office (ICO). The ICO has issued some of Europe's largest security-related penalties — including British Airways (GBP 20 million) and Marriott (GBP 18.4 million), both centred on inadequate security — and its 2025 Capita fine confirms the appetite has not cooled. The Data (Use and Access) Act 2025 (Royal Assent 19 June 2025) reformed parts of UK data protection but did not weaken the security obligation, and the European Commission moved to renew the UK's adequacy decision after reviewing the reforms, so EU–UK data flows continue.

Norway and the EEA. Norway applies the GDPR through the EEA Agreement (in force since July 2018), so Article 32 binds Norwegian controllers and processors in identical terms, supervised by Datatilsynet. The practical conclusion for any company operating across the EU, EEA, and UK is that you should design one security baseline to the "appropriate measures" standard — it does not get lower by crossing a border, and the ICO's enforcement record shows it can get more expensive.

---

Operationalising Article 32 in a Trust Center

Article 32 is where security engineering meets legal accountability. The controls are the security team's job; proving them — before a deal, during an audit, and after a breach — is where the article is won or lost. Three capabilities turn Article 32 from a periodic scramble into a standing asset:

1. A living TOMs document mapped to Article 32(1)(a)–(d), kept current rather than rewritten before each audit — so "what are your technical and organisational measures?" has a single, authoritative answer.
2. Evidence that refreshes itself. Continuous monitoring keeps proof of encryption, access reviews, backups, and testing current, satisfying the Article 32(1)(d) "regular testing" limb and the Article 5(2) accountability duty at the same time.
3. A self-serve surface for buyers and auditors. A Trust Center lets a prospect's security team confirm your Article 32 posture without a questionnaire cycle — the same evidence that answers a due-diligence review is the evidence a supervisory authority asks for after an incident.

This is the ISMS-and-Trust-Center model in practice: an ISMS produces appropriate measures; a Trust Center makes them demonstrable. Orbiq's Trust Center platform keeps the TOMs, certifications, subprocessor list, and testing evidence in one always-current place, so your Article 32 story is ready before anyone asks — for a prospect, an auditor, or Datatilsynet.

Article 32 rewards the same discipline as the rest of the GDPR's security regime: do the unglamorous work in advance, keep the proof current, and the article stops being a liability and becomes something you can point a customer to.

Prove your Article 32 compliance with Trust Center evidence. See how Orbiq's Trust Center platform works →

---

Sources & References

1. Regulation (EU) 2016/679 (GDPR) — Full Text (EUR-Lex ELI) — Official Journal of the European Union; Article 32 in context.
2. gdpr-info.eu — Article 32 (Security of Processing) — Article text and recitals.
3. EDPB — One-Stop-Shop Case Digest: Security of Processing and Data Breach Notification — How supervisory authorities assess "appropriate" TOMs in practice.
4. CMS GDPR Enforcement Tracker Report 2025/2026 — Numbers and Figures — Fine categories and the EUR 251M Meta security fine.
5. DLA Piper GDPR Fines and Data Breach Survey: January 2026 — EUR 7.1 billion cumulative; EUR 1.2 billion in 2025.
6. Surfshark Research: GDPR fines 2025 — Article 32 fines up 40%+ (69 → 97 cases); Meta EUR 251M + EUR 91M.
7. ICO — A guide to data security (UK GDPR) — UK security-of-processing guidance.
8. Datatilsynet — Norwegian Data Protection Authority — Security guidance (Norway / EEA).

---

Related Reading

• GDPR Compliance in 2026: Principles, Rights & How to Prove It
• GDPR Compliance for B2B SaaS: Articles 28–34 Explained
• GDPR Article 28: Processor Obligations & DPA Requirements
• GDPR Article 33: The 72-Hour Breach Notification Rule
• GDPR Article 34: Communicating a Breach to Data Subjects
• Best ISMS Software for European Companies
• Continuous Monitoring