GDPR Article 32 Decoded: Security of Processing for IT Teams

Article 32 is the part of the GDPR that security teams are most often asked to "own", yet it contains almost no technical detail. It does not mention firewalls, MFA, EDR or patch windows. Instead, it sets a standard: controllers and processors must implement technical and organisational measures that deliver "a level of security appropriate to the risk". That makes Article 32 less of a checklist and more of a method. This guide decodes what the article actually says, how to translate it into a control set your auditors and your DPO can follow, and what evidence you need to show that your measures are appropriate and working.

What Article 32 actually says

Article 32 has four paragraphs. Paragraph 1 is the one everyone quotes, but paragraphs 2 to 4 matter just as much in practice.

Article 32(1): the risk-based obligation

The controller and the processor must implement appropriate technical and organisational measures, taking into account:

• the state of the art;
• the costs of implementation;
• the nature, scope, context and purposes of the processing;
• the risk of varying likelihood and severity for the rights and freedoms of natural persons.

It then lists, "inter alia as appropriate", four families of measures:

Two words deserve attention. "Including" means the list is not exhaustive. "As appropriate" means none of the four items is automatically mandatory in every context, but in practice it is hard to justify the absence of any of them for systems holding meaningful volumes of personal data.

Article 32(2): what the risk assessment must cover

When assessing the appropriate level of security, you must account in particular for the risks from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. This wording mirrors the definition of a personal data breach in Article 4(12). The practical reading: your Article 32 risk assessment is the preventive side of the same coin as your breach response.

Article 32(3): codes of conduct and certification

Adherence to an approved code of conduct (Article 40) or an approved certification mechanism (Article 42) may be used as an element to demonstrate compliance. Note what this does not say: an ISO/IEC 27001 certificate is not a GDPR certification under Article 42, and no certificate is an automatic proof of compliance. It is supporting evidence.

Article 32(4): people act only on instructions

Anyone acting under the authority of the controller or processor who has access to personal data must process it only on instructions. For IT, that translates into role-based access, least privilege, confidentiality commitments for administrators and contractors, and controls on privileged use.

The risk that matters: data subjects, not the company

The most common mistake when security teams approach Article 32 is to reuse a corporate risk register unchanged. Corporate registers usually score impact in terms of revenue, downtime and reputation. Article 32 asks for the risk to the rights and freedoms of natural persons: identity theft, financial loss, discrimination, loss of confidentiality of health or other sensitive data, physical harm, loss of control over their data.

You do not need a separate methodology. Add a "data subject impact" dimension to your existing scoring and make sure it can drive the result. A low-revenue system holding HR disciplinary records or health data can carry a high privacy risk even if the business impact of an outage is minor.

# Example: extending an asset risk entry with a data subject dimension
asset: hr-case-management
owner: people-ops
personal_data:
  categories: [identity, employment, disciplinary, health_notes]
  special_categories: true        # Art. 9 data present
  volume: "~4,000 employees and former employees"
threats:
  - unauthorised_access_by_insider
  - credential_stuffing_on_sso
  - ransomware_on_file_share
business_impact: medium
data_subject_impact: high         # discrimination, distress, loss of confidentiality
overall_risk: high                # driven by data_subject_impact
required_measures:
  - mfa_enforced
  - field_level_encryption_for_health_notes
  - quarterly_access_review
  - immutable_backups_tested_twice_a_year

Mapping Article 32 to a control framework

Article 32 does not replace an information security management system; it tells you what that system must achieve for personal data. Most organisations map it onto an existing framework. ISO/IEC 27001:2022 Annex A contains 93 controls grouped into four themes (organisational, people, physical and technological), and ISO/IEC 27701 extends it with privacy-specific requirements. CIS-style control families are an equally valid starting point.

The mapping is only half the job. For each control, record why its strength is appropriate for the risk. "We use AES-256 at rest" is a fact; "we encrypt the claims database at rest with keys in a separate KMS account because it contains health data on 200,000 customers" is an Article 32 justification.

State of the art and cost: how to argue both

"State of the art" is not "the most advanced product on the market". It means measures that are established and available, and that a reasonable, well-informed organisation would use today. Examples most practitioners would consider state of the art for internet-facing systems handling personal data: current TLS versions, MFA for remote and privileged access, timely patching of known exploited vulnerabilities, encrypted and tested backups, centralised logging.

Cost is a legitimate factor, but it works in one direction only: it can help justify choosing one adequate measure over a more expensive one of similar effect. It cannot justify leaving a high risk unaddressed. If the only affordable option leaves residual risk high, that is a signal to reconsider the processing itself, or to run a DPIA.

The state of the art also moves. A measure that was appropriate five years ago may no longer be. Article 24 requires controllers to review and update their measures where necessary, so build a periodic review into the process rather than treating Article 32 as a one-off project.

Testing, assessing, evaluating: point (d) in practice

Point (d) is the one auditors ask about most, because it is where claims meet reality. A workable programme covers:

1. Technical testing: authenticated vulnerability scans, penetration tests on internet-facing and high-risk systems, configuration compliance checks.
2. Recovery testing: actual restores from backup into an isolated environment, timed against your RTO and RPO, including at least one scenario where the primary environment is assumed compromised.
3. Process testing: tabletop exercises for breach response, access review completion rates, joiner-mover-leaver sampling.
4. Evaluation: a documented review of results, a remediation plan with owners and dates, and verification that fixes were applied.

# Example: evidence record for a backup restore test (Art. 32(1)(c) and (d))
test_id: RST-2026-Q3-04
system: customer-crm-db
date: "2026-09-12"
scenario: "Primary region unavailable, restore from immutable backup"
rto_target: "8h"
rto_achieved: "5h40m"
rpo_target: "24h"
rpo_achieved: "11h"
data_integrity_check: "row counts and checksums matched source snapshot"
issues:
  - "runbook step 7 referenced a decommissioned bastion host"
remediation:
  owner: "platform-team"
  due: "2026-10-15"
approved_by: "Head of Infrastructure"

How Article 32 connects to the rest of the GDPR

Article 32 does not stand alone:

• Article 5(1)(f) sets integrity and confidentiality as a core principle. Article 32 is its operational expression.
• Article 5(2) (accountability) requires the controller to be able to demonstrate compliance. Without documentation, appropriate measures are hard to prove.
• Article 24 makes the controller responsible for implementing appropriate measures and reviewing them.
• Article 25 (data protection by design and by default) pushes security and minimisation into the design phase, before a system reaches production.
• Article 28(3)(c) requires processors to take all Article 32 measures, so your vendor due diligence is an Article 32 activity too.
• Article 30(1)(g) asks for, where possible, a general description of your Article 32 measures in the records of processing activities.
• Articles 33 and 34 apply when measures fail. Encryption that renders data unintelligible can remove the obligation to notify individuals under Article 34(3)(a). See our guide on breach notification within 72 hours.

Fines and enforcement exposure

Infringements of Article 32 sit in the Article 83(4) tier: up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Supervisory authorities can also treat a serious security failure as an infringement of Article 5(1)(f), which falls under the Article 83(5) tier of up to EUR 20 million or 4%. Enforcement practice varies between authorities, so check your national supervisory authority's published decisions and guidance for the level of detail they expect.

Article 32 checklist for security teams

• Every system processing personal data is in the asset inventory with its data categories.
• Risk scoring includes impact on data subjects, not only on the business.
• Each of 32(1)(a) to (d) is mapped to named controls with owners.
• Each control has a written justification of why it is appropriate to the risk.
• Encryption and key management cover data in transit, at rest and in backups.
• Restore tests are performed and timed against RTO and RPO.
• Testing results feed a tracked remediation plan.
• Processors are assessed against Article 32 before onboarding and periodically after.
• Measures are reviewed at least annually and after significant changes or incidents.

Scope of this guide

This article is technical guidance for security and IT teams on implementing GDPR Article 32. It is not legal advice. Confirm your risk decisions, control choices and documentation approach with your data protection officer or legal counsel.