Article 32 of GDPR requires controllers and processors to implement ‘appropriate technical and organisational measures’ (TOMs) to ensure a level of security appropriate to the risk of the processing. This is a risk-based standard, not a prescriptive checklist. There is no single set of measures that satisfies Article 32 for all organisations — the appropriate measures depend on the nature, scope, context, and purposes of the processing, and on the risks to individuals’ rights and freedoms.
The TOMs obligation is one of the most frequently referenced provisions in DPA enforcement decisions. Controllers that have suffered breaches are regularly found to have failed to implement measures appropriate to the sensitivity of the data they were processing. The pattern is consistent: data processing that was technically possible was implemented without a security assessment proportionate to the data at risk, and controls were not revisited as the processing scaled or as the threat landscape evolved.
The Risk-Proportionate Standard
Article 32(1) identifies four factors that must be taken into account when assessing what is ‘appropriate’: the state of the art; the costs of implementation; the nature, scope, context, and purposes of processing; and the varying likelihood and severity of risks to individuals’ rights and freedoms. This framework means that appropriate TOMs for a healthcare platform processing patient records will differ substantially from appropriate TOMs for a B2B service processing business contact details.
RISK-PROPORTIONATE TOM ASSESSMENT FRAMEWORK
| Assessment Factor | What It Means in Practice | Example Application |
|---|---|---|
| State of the art | Measures must reflect current best practice; security that was adequate five years ago may no longer be appropriate; organisation must stay current with threat landscape and security tooling | TLS 1.3 rather than TLS 1.0; AES-256 encryption; multi-factor authentication as standard; modern endpoint protection |
| Costs of implementation | Measures must be proportionate in cost to the risk; cost is not a complete defence against basic security failures; cost argument is much weaker for low-cost or commodity security controls | Full HSM encryption infrastructure may be disproportionate for low-risk B2B data; MFA (low cost) is expected regardless of organisation size |
| Nature and purpose of processing | Sensitive purposes (health, finance, HR, children) demand higher security standards than non-sensitive business data | Health app requires encryption at rest as a baseline; anonymous survey tool requires far less |
| Likelihood and severity of risk | Mass-scale processing with high exfiltration value demands stronger controls than low-volume, low-sensitivity processing | E-commerce platform storing payment data: high likelihood, high severity; B2B directory with company addresses: low likelihood, low severity |
Article 32’s Specific Measures
Article 32(1)(a)–(d) identifies four specific categories of measure that must be considered, though not all will apply in every context. These are: pseudonymisation and encryption of personal data; ongoing confidentiality, integrity, availability, and resilience of processing systems; the ability to restore availability and access to personal data in a timely manner after an incident; and a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures.
ARTICLE 32 — SPECIFIC MEASURES AND IMPLEMENTATION STANDARDS
| Measure Category | What Article 32 Requires | Implementation Standards |
|---|---|---|
| Pseudonymisation and encryption (Art. 32(1)(a)) | Personal data should be pseudonymised or encrypted where appropriate to the risk; reduces severity of a breach event | Encryption at rest for sensitive databases; encryption in transit (TLS 1.2+); field-level encryption for special category data; pseudonymisation for analytics and testing environments |
| Confidentiality, integrity, availability, resilience (Art. 32(1)(b)) | Systems must protect against unauthorised access (confidentiality); unintended modification (integrity); downtime (availability); must be resilient to disruption | Access controls and least privilege; change management and audit logging; redundancy and failover; business continuity planning; DDoS protection |
| Restore availability after incident (Art. 32(1)(c)) | Organisation must be able to recover personal data and restore processing after a physical or technical incident | Backup regime with tested recovery; disaster recovery plan; RTO and RPO defined; recovery testing at least annually |
| Regular testing and evaluation (Art. 32(1)(d)) | Security controls must be regularly tested, assessed, and evaluated to confirm they remain effective | Annual penetration testing; vulnerability scanning; security control audits; DAST/SAST for web applications; internal access reviews |
Organisational Measures: The Non-Technical Half
TOMs are not exclusively technical. The ‘organisational measures’ component of Article 32 requires governance, policy, and process controls that together create the human layer of data protection. Technical controls can be bypassed or undermined by inadequate organisational measures. The most sophisticated encryption implementation provides limited protection if staff can exfiltrate data through unsecured channels because there is no acceptable use policy or monitoring.
ORGANISATIONAL MEASURES — KEY CATEGORIES
| Category | Measures | Evidence for Accountability Record |
|---|---|---|
| Policies and procedures | Data protection policy; acceptable use policy; data handling procedures; incident response procedure; clean desk and clear screen policy | Approved policy documents; version history; distribution records; staff acknowledgement |
| Staff training and awareness | Data protection induction training; role-specific training for high-risk functions; annual refresher; phishing simulation | Training completion records; training content; test results; role-based training matrix |
| Access management | Role-based access control; least privilege principle; joiners/movers/leavers process; privileged access management; access reviews | Access control policy; access review records; joiners/movers/leavers procedure; PAM system evidence |
| Vendor management | Processor assessment; DPA execution; sub-processor monitoring; supplier security requirements | Processor register; executed DPAs; vendor assessment records |
| Physical security | Building access controls; screen locking; secure printing; physical document disposal; clean desk enforcement | Physical access log; CCTV policy; secure disposal records; physical security audit |
| Incident management | Incident detection and response procedure; escalation path; GDPR breach assessment SLA; DPA notification process | Incident response procedure; breach register; notification records; post-incident review reports |
Documenting TOMs: The Schedule of Measures
Documenting TOMs serves two purposes: it is evidence of the accountability principle in action, and it is the practical instrument used to respond to DPA investigations, enterprise client security questionnaires, and processor assessment requests from controllers. A TOM schedule that is specific, current, and evidenced is substantially more valuable than a generic list of security commitments that cannot be verified.
TOM DOCUMENTATION FRAMEWORK — MINIMUM FIELDS
| Field | Content |
|---|---|
| Processing activity or system scope | Which processing activities and systems the TOMs apply to; or confirmation of enterprise-wide application |
| Date of last review | When the TOM schedule was last reviewed and confirmed as current; review cadence |
| Technical measures — encryption | Encryption standards at rest and in transit; key management approach; field-level encryption for special categories |
| Technical measures — access control | Authentication requirements (MFA, password policy); RBAC implementation; privileged access controls; external access controls (VPN, zero trust) |
| Technical measures — availability and resilience | Backup frequency and retention; recovery point objective; recovery time objective; failover architecture; DDoS protection |
| Technical measures — testing | Penetration testing frequency and scope; vulnerability management programme; SAST/DAST for applications; security monitoring and alerting |
| Organisational measures — policies | Core policies in place; approval and review cycle; distribution and acknowledgement mechanism |
| Organisational measures — training | Training programme; completion rate; role-specific components; phishing simulation results |
| Organisational measures — access management | RBAC matrix; access review cadence; joiners/movers/leavers procedure; PAM controls |
| Organisational measures — incident response | IRP in place; DPO in breach response chain; 72-hour notification capability; post-incident review process |
| Certifications held | ISO 27001; SOC 2; sector-specific certifications; scope of each certification |
| BITLION INSIGHT | Enterprise clients — particularly in regulated sectors — increasingly require processors to complete detailed security questionnaires as a condition of contract. The most efficient approach is to maintain a current, evidence-backed TOM schedule as a master document that can be used to populate these questionnaires consistently. Organisations that respond to security questionnaires ad hoc, producing different answers each time depending on who prepares the response, create discrepancies in their documented compliance record that are difficult to defend in a dispute. A master TOM schedule, reviewed annually and maintained accurately, provides the single source of truth for all security representations. |