What Article 32 actually requires
GDPR Article 32(1) sets the baseline for security of processing: controllers and processors must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.
The word "appropriate" is doing a lot of work in that sentence. Article 32 deliberately avoids prescribing specific controls because what is appropriate varies by:
- The state of the art (what's reasonably available right now)
- The costs of implementation (proportionality for the organisation)
- The nature, scope, context, and purposes of processing
- The risk of varying likelihood and severity for the rights and freedoms of natural persons
This is the 4-factor risk test. Every TOMs decision should be defensible by reference to these four factors.
The four specific measures named in Article 32(1)(a)–(d)
While the standard is risk-based, Article 32(1) names four specific measures that should be considered:
- Pseudonymisation and encryption of personal data (Art. 32(1)(a)).
- Ongoing confidentiality, integrity, availability, and resilience of processing systems and services (Art. 32(1)(b)).
- The ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident (Art. 32(1)(c)).
- A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures (Art. 32(1)(d)).
These aren't optional considerations — they're explicit baselines. Failure on any of these has been the basis of multiple major fines.
22 specific TOMs for SaaS
Here's a comprehensive TOMs checklist mapped to GDPR Art. 32 sub-paragraphs and the most common audit frameworks. This is the kind of table that goes into a DPA Annex, an InfoSec Policy, and a security questionnaire response.
| Measure | Category | Art. 32 Basis | SOC 2 / ISO 27001 Mapping |
|---|---|---|---|
| Encryption in transit (TLS 1.2+) | Technical | 32(1)(a) | CC6.7 / A.8.24 |
| Encryption at rest (AES-256) | Technical | 32(1)(a) | CC6.7 / A.8.24 |
| Pseudonymisation of PII in non-prod / analytics | Technical | 32(1)(a) | A.8.11 |
| Role-based access control (RBAC), least privilege | Technical | 32(1)(b) | CC6.1–6.3 / A.5.15, A.5.18 |
| Multi-factor authentication (MFA) for all admin access | Technical | 32(1)(b) | CC6.1 / A.5.17 |
| Centralised audit logging + integrity protection | Technical | 32(1)(b) + 32(1)(d) | CC7.2 / A.8.15, A.8.16 |
| Anti-malware and endpoint detection | Technical | 32(1)(b) | CC6.8 / A.8.7 |
| Network segmentation (prod / non-prod / corporate) | Technical | 32(1)(b) | CC6.6 / A.8.22 |
| Vulnerability management (scanning + SLA-driven patching) | Technical | 32(1)(d) | CC7.1 / A.8.8 |
| Penetration testing (annual, third-party) | Technical | 32(1)(d) | CC4.1 / A.8.8 |
| Automated backups with off-region replication | Technical | 32(1)(c) | A1.2 / A.8.13 |
| Tested restore + documented RTO/RPO | Technical | 32(1)(c) | A1.3 / A.5.30, A.8.14 |
| Information security policy (approved + reviewed) | Organisational | 32(1)(b) | CC1.1 / A.5.1 |
| Incident response plan + tested annually | Organisational | 32(1)(d) | CC7.3–7.5 / A.5.24–5.28 |
| Security awareness training (incl. phishing simulation) | Organisational | 32(4) | CC1.4 / A.6.3 |
| Background screening (where lawful) | Organisational | 32(4) | CC1.4 / A.6.1 |
| Confidentiality obligations on personnel | Organisational | 32(4) + Art. 28(3)(b) | CC1.4 / A.6.2 |
| Joiner-Mover-Leaver process + quarterly access reviews | Organisational | 32(1)(b) | CC6.2–6.3 / A.5.16, A.5.18 |
| Vendor risk management with security review | Organisational | 32(1)(b) + Art. 28 | CC9.2 / A.5.19–5.23 |
| Data Processing Agreement (DPA) with sub-processors | Contractual | Art. 28 | CC9.2 / A.5.20 |
| Confidentiality clauses in contracts | Contractual | 32(4) | A.5.20 |
| SCCs / DPF / IDTA for international transfers | Contractual | Art. 44–49 | A.5.34 |
This is the TOMs Annex that goes into your DPA — customers will ask for this verbatim.
The "state of the art" standard explained
EDPB Guidelines 1/2021 and 9/2022 clarify that "state of the art" does not mean "gold standard" or "most expensive available". It means: what a reasonably competent organisation in your sector would implement, given current threats and current technology.
For SaaS in 2026, the "state of the art" baseline is roughly:
- TLS 1.2+ everywhere (TLS 1.3 strongly preferred)
- AES-256 at rest, with KMS-managed keys
- MFA for all administrative access (phishing-resistant MFA increasingly expected)
- SSO for workforce identity
- Centralised logging with at least 90 days hot retention
- Automated dependency scanning in CI/CD
- Annual third-party penetration test
- Documented and tested incident response plan
- Documented security awareness programme with phishing simulations
- Encryption of backups and offsite replication
If you're substantially behind this baseline and you suffer a breach, your DPA will likely find that you didn't implement appropriate measures — even if your customer agreed to your security posture in the DPA. Article 32 is a direct controller/processor obligation, not just a contractual matter.
Processor TOMs obligations under Article 28
If you are a processor (which most SaaS are, for customer data), Article 28(1) requires you to provide sufficient guarantees to controllers that you implement appropriate TOMs. Article 28(3)(c) requires the DPA to specify the security measures.
In practice this means:
- Your DPA must include a TOMs annex listing the measures above (or equivalent).
- You must be prepared to evidence those measures — SOC 2 Type II, ISO 27001 certificate, pen test summary, etc.
- Your sub-processors must offer equivalent guarantees; you must flow down obligations.
- You must notify controllers of security incidents "without undue delay" (Art. 33(2)) — typically interpreted as 24–48 hours.
Use the ComplyKit DPA Generator for a DPA template with a complete TOMs annex.
Where to document TOMs
TOMs documentation lives in several places, intentionally:
- Information Security Policy — the master document. Internal-facing. References all the controls and procedures.
- DPA Annex (TOMs) — customer-facing summary of measures. Shared in B2B contracts.
- Privacy Policy — high-level user-facing summary ("we use encryption, access controls, regular testing").
- DPIA — risk-by-risk justification of selected measures.
- RoPA — per-processing-activity summary of measures (Art. 30(1)(g)).
- Trust Centre — public-facing summary for enterprise prospects. Use the Trust Centre Generator.
Consistency across these documents matters. Auditors and regulators compare them, and inconsistencies are a red flag.
Article 32 and breach enforcement
Article 32 has been the legal basis for many of the largest GDPR fines. The pattern is consistent: a breach occurs; the DPA investigates and finds that the technical and organisational measures were not appropriate to the risk; the fine reflects both the breach impact and the underlying control failure.
| Case | Year | Fine | Art. 32 finding |
|---|---|---|---|
| British Airways (ICO) | 2020 | £20M | Inadequate security — lack of MFA, segregation, logging, allowed credential-stuffing attack |
| Marriott (ICO) | 2020 | £18.4M | Inadequate security around acquired infrastructure; failure to detect attacker presence for years |
| H&M (Hamburg DPA) | 2020 | €35.3M | Excessive employee profiling — inadequate access controls and minimisation |
| Twitter (Irish DPC) | 2020 | €450K | Failed to notify within 72 hours — Art. 33 (closely tied to Art. 32(1)(d) detection) |
| Uber (Dutch DPA) | 2018 | €600K | 2016 breach — inadequate security and delayed notification |
The lesson: Article 32 is not abstract. It's the most enforced provision after breach notification (Art. 33–34), and it directly drives fine quantum.
Practical Article 32 TOMs checklist for SaaS startups
If you're early-stage and need a defensible TOMs baseline, the minimum 15-item starter pack:
- TLS 1.2+ on all customer-facing endpoints (Cloudflare or equivalent makes this trivial)
- AES-256 at rest via cloud-managed encryption (S3 default, RDS encryption, etc.)
- MFA enforced for all admin and engineering access (Google Workspace / Microsoft 365 setting)
- SSO for workforce access where possible (free with Google Workspace; paid for Slack/Notion/GitHub)
- Centralised logging — at minimum CloudTrail + GitHub audit logs + auth provider logs, retained 1 year
- Automated dependency scanning (GitHub Dependabot, Snyk free tier)
- Backup automation with off-region replication (AWS RDS automated backups + cross-region snapshots)
- Documented and tested incident response plan (use the IRP Generator)
- Annual third-party penetration test (budget €8–20K)
- Documented Information Security Policy (use the InfoSec Policy Generator)
- Security awareness training programme with phishing simulations (use the Security Awareness Training Policy)
- Documented data retention with automated deletion where possible (use the Data Retention Policy Generator)
- DPA in place with all sub-processors and customers (use the DPA Generator)
- Sub-processor list public and notification process (use the Sub-Processor List Generator)
- Vendor risk assessment for critical vendors (use the Vendor Risk Assessment)
Related guides
- GDPR Breach Notification: The 72-Hour Rule for SaaS
- Privacy by Design under GDPR Art. 25
- ISO 27701 PIMS: The Privacy Extension to ISO 27001 for SaaS
- Security Awareness Training for SaaS
Generate your Information Security Policy with TOMs → /generate/information-security-policy
⚠️ This guide is for informational purposes only and does not constitute legal advice. The appropriate technical and organisational measures for your organisation depend on your specific processing activities, risk profile, and applicable supervisory authority interpretation. Engage qualified privacy and security counsel.