GDPR Article 32: A Practical Guide to Security of Processing for SaaS and HealthTech

Short answer: GDPR Article 32 requires controllers and processors to implement appropriate technical and organisational measures that keep personal data secure in proportion to the risk. It names encryption and pseudonymisation, resilient systems, timely restoration after incidents, and regular testing of controls, and expects you to document why your chosen measures fit your risks.

Related guides:

• GDPR Article 30: records of processing activities
• GDPR special category data: Article 9 guide for SaaS and HealthTech teams
• What are the GDPR data breach notification requirements?

Key takeaways

• Article 32 is risk-based. It does not prescribe a fixed control list. You choose measures based on the state of the art, cost, the nature and context of your processing, and the risk to people.
• The four named examples are encryption and pseudonymisation, confidentiality, integrity, availability and resilience, timely restoration after an incident, and regular testing of your measures.
• It applies to both controllers and processors, so a SaaS vendor processing customer data has its own direct obligation.
• Regulators look for evidence: a documented risk assessment, a mapping of risks to controls, and proof those controls actually operate.
• ISO 27001 and SOC 2 help you demonstrate Article 32, but neither one equals GDPR compliance on its own.

---

What does GDPR Article 32 require?

Article 32 requires a level of security appropriate to the risk, achieved through technical and organisational measures (TOMs) that you can explain and evidence. The article has four paragraphs, and each one adds a distinct obligation.

Paragraph	What it says, in plain terms
32(1)	Implement appropriate TOMs, taking into account the state of the art, costs of implementation, the nature, scope, context and purposes of processing, and the risks to individuals. Includes, as appropriate, examples (a) to (d) below.
32(1)(a)	Pseudonymisation and encryption of personal data.
32(1)(b)	Ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.
32(1)(c)	Ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident.
32(1)(d)	A process for regularly testing, assessing and evaluating the effectiveness of your measures.
32(2)	When assessing the right level of security, consider in particular the risks of accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
32(3)	Adherence to an approved code of conduct or approved certification mechanism can be used as an element to demonstrate compliance.
32(4)	Take steps so that anyone acting under your authority with access to personal data only processes it on instructions, unless law requires otherwise.

"Appropriate" means proportionate, not maximal. "Ongoing" and "regularly" mean security is a continuing program, not a one-time project. Paragraph 32(4) is often overlooked: it calls for role-based access, confidentiality commitments and training so staff only use personal data as instructed.

Does Article 32 apply to controllers or processors?

It applies to both. Article 32 names "the controller and the processor," so a SaaS company processing personal data on behalf of its customers carries its own security obligation, separate from whatever its contracts say.

As a processor, expect customers to ask for a detailed description of your TOMs, usually as a contract annex. As a controller of your own employee and account data, Article 28(1) separately requires you to use only processors that provide sufficient guarantees of appropriate measures. Article 32 sets the security standard, and the data processing agreement is where that standard gets written down between the parties.

How do you decide what is "appropriate" under Article 32?

You decide through a documented risk assessment that weighs the likelihood and severity of harm to individuals against the cost and maturity of available controls. Note the focus on risk to people, not only risk to your business.

A practical method:

1. Inventory your processing. List the systems, data categories and data flows involved. Your records of processing activities are a natural starting point.
2. Identify threats using 32(2). For each system, ask how personal data could be destroyed, lost, altered, disclosed or accessed without authorization, whether accidentally or deliberately.
3. Rate likelihood and severity for individuals. Health data, children's data, financial data and large volumes raise severity. Public-facing APIs and broad internal access raise likelihood.
4. Select controls. Weigh the state of the art and implementation cost. Cost can shape how you implement a control, but it is not a reason to leave a high risk untreated.
5. Record your reasoning. Write down why each measure is appropriate and which residual risks you accept.
6. Review on change. Revisit the assessment when you launch features, add vendors or have an incident.

HealthTech teams processing health data should expect a higher bar, and high-risk processing may also need a data protection impact assessment whose findings feed into your controls.

Which controls and evidence satisfy Article 32?

There is no official checklist, but the controls below map cleanly to each element of Article 32 and produce the evidence auditors and regulators typically expect.

Article 32 element	Example controls	Evidence to keep
32(1)(a) Encryption	TLS for data in transit, encryption at rest for databases, storage and backups, managed key storage with restricted access	Cloud configuration exports, encryption policy, key management procedure, TLS scan results
32(1)(a) Pseudonymisation	Tokenized identifiers in analytics, separate storage of re-identification keys, masked data in non-production environments	Data flow diagrams, environment data handling standard, test data procedure
32(1)(b) Confidentiality	SSO with MFA, role-based access, least privilege, quarterly access reviews, prompt offboarding	Access review records, MFA enforcement settings, offboarding tickets
32(1)(b) Integrity	Change management with peer review, audit logging, database constraints, file integrity monitoring where relevant	Pull request approvals, change tickets, log retention configuration
32(1)(b) Availability and resilience	Redundant infrastructure, monitoring and alerting, capacity planning, DDoS protection	Architecture diagrams, uptime reports, alerting runbooks
32(1)(c) Timely restoration	Automated backups, defined recovery objectives, documented disaster recovery plan, incident response plan	Backup job logs, restore test results, DR exercise reports
32(1)(d) Regular testing	Vulnerability scanning, penetration tests, control self-assessments, internal audits, tabletop exercises	Scan reports, pentest reports with remediation tracking, audit findings
32(2) Risk assessment	Information security risk register focused on harm to individuals	Risk register, risk treatment decisions, review dates
32(4) Acting on instructions	Confidentiality agreements, acceptable use policy, security and privacy training, access scoped by role	Signed agreements, training completion records, role definitions

A few points that teams often miss:

• Restoration has to be tested. A backup policy alone does not show you can restore "in a timely manner." Keep records of actual restore tests and how long they took.
• Testing includes organisational measures. Check that training and access reviews actually happen, not just that scanners run.
• Logs and backups contain personal data too. Restrict, encrypt and retain them accordingly.

Is encryption mandatory under GDPR?

Encryption is not mandatory in every case, but it is named in Article 32 as an example of an appropriate measure, and for most SaaS and HealthTech processing it would be hard to justify leaving it out. In our reading, the practical approach is to treat encryption as the default and document your reasoning in the risk assessment if you decide not to use it for some processing.

A typical cloud baseline is encryption in transit for all traffic carrying personal data, encryption at rest for databases, storage, backups and laptops, key management that separates key access from data access, and field-level encryption or tokenization for the most sensitive values.

Encryption also pays off when things go wrong. Under Article 34(3)(a), if breached data was unintelligible to unauthorized parties, for example because it was encrypted, you may not have to notify the affected individuals. You still assess whether to notify the supervisory authority under Article 33, which applies unless the breach is unlikely to result in a risk to individuals. Pseudonymised data, by contrast, is still personal data.

Do ISO 27001 or SOC 2 prove Article 32 compliance?

They help you demonstrate it, but neither one is proof of GDPR compliance on its own. Both produce the evidence Article 32 calls for: a risk-based program, defined controls and independent testing.

• ISO 27001 requires risk assessment, risk treatment and a Statement of Applicability, with Annex A controls for access, cryptography, backup, logging, suppliers and incidents. Internal audits support 32(1)(d).
• SOC 2 Type 2 reports test controls over a period of time, which is strong evidence for "ongoing" security.

Know the limits. Your certification scope may not cover every system holding personal data. These frameworks assess risk to the organization, while Article 32 asks about risk to individuals. And neither is a code of conduct or certification mechanism approved under GDPR, as referred to in 32(3), although they remain valuable supporting evidence.

For a deeper comparison, read how GDPR and ISO 27001 work together.

What happens if you get Article 32 wrong?

Infringements of Article 32 fall under the lower tier of administrative fines in Article 83(4): up to EUR 10 million or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. Supervisory authorities can also use corrective powers, such as orders to bring processing into compliance.

For SMBs the bigger risk is often commercial, since weak or undocumented TOMs slow enterprise deals. See our guide to GDPR fines for how fines are calculated.

How SecureSlate helps

SecureSlate helps SaaS and HealthTech teams turn Article 32 into a working program. You can adopt security policies, map your controls across GDPR, ISO 27001, SOC 2 and HIPAA, track risks in a risk register, assess vendors and keep evidence for each control in one place.

Keeping that evidence current between audits supports the "ongoing" and "regularly testing" parts of Article 32, and makes it easier to answer customer security questionnaires and describe your TOMs in processor contracts.

Start your free SecureSlate trial

FAQ

What are technical and organisational measures under GDPR?

Technical measures are system-level protections such as encryption, access controls, logging and backups. Organisational measures are policies, procedures, training, confidentiality agreements and governance that shape how people handle personal data. Article 32 expects both, chosen in proportion to the risk.

Does Article 32 list specific mandatory controls?

No. It gives four examples, including encryption and regular testing, and applies them "as appropriate." You decide which measures fit your processing through a documented risk assessment, and you should be able to explain that decision.

How often should we test our Article 32 measures?

The GDPR says "regularly" without setting a frequency, so set and document your own schedule based on risk. Examples teams use include continuous vulnerability scanning, quarterly access reviews, at least annual penetration testing and restore tests, and additional reviews after significant changes or incidents.

Is a SaaS vendor responsible for Article 32 if the customer is the controller?

Yes. Article 32 applies directly to processors as well as controllers. Your customer's contract will also set out security expectations, but your legal obligation to maintain appropriate security exists independently.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.