Technical and organisational measures (TOMs): what they are
Kort antwoord
Technical and organisational measures, usually shortened to TOMs, is a GDPR-derived term for the concrete safeguards a data processor has in place to protect personal data, things like access controls, encryption practices, staff training and incident response procedures. A provider's TOMs are typically documented and shared with customers, or required as part of a data processing agreement, so a customer can assess whether the provider's actual practices meet their own compliance needs.
Anyone processing personal data on behalf of an EU organisation runs into the term TOMs sooner or later, usually while working through a data processing agreement (DPA) with a supplier. It's worth understanding clearly what it does and doesn't mean, because it gets confused with two other things suppliers commonly point to: an SLA and a certification.
What TOMs actually means
Technical and organisational measures is the GDPR's own phrase for the safeguards a data processor puts in place to protect the personal data it handles. "Technical" covers the mechanisms themselves, things like access controls, encryption of data at rest and in transit, logging, and network segmentation. "Organisational" covers the human and procedural side, staff training, defined roles and responsibilities, incident response procedures, and how access to data is granted and reviewed. Together, they're meant to describe, concretely, how a processor actually protects the data it's trusted with, not just that it has a policy saying it does.
In practice, a provider's TOMs are usually written down as a specific document, or a specific section of a data processing agreement, that a customer can read and assess. That's the whole point of the concept: it gives a customer something concrete to evaluate, rather than a general assurance.
What's typically documented
Exactly what appears in a TOMs document varies by provider and by the data being processed, but common categories include:
- Access control: who can reach personal data, how access is granted, and how it's reviewed or revoked.
- Encryption: whether and how data is encrypted at rest and in transit.
- Staff training and confidentiality: how employees who might handle personal data are trained and bound to confidentiality.
- Incident response: how a data breach or security incident is detected, escalated, and reported.
- Physical security: controls over the physical environment where data-processing infrastructure lives.
- Backup and resilience: how data is protected against loss, separate from how it's protected against unauthorised access.
TOMs vs. an SLA
An SLA (service level agreement) is a commitment about service performance, typically availability or support response. TOMs is a different kind of document entirely: it's specifically about how personal data is protected, and it belongs to the compliance and legal side of a relationship rather than the performance side. A provider can meet every figure in its SLA and still have weak TOMs, or the reverse, they answer different questions. If you're assessing a supplier for GDPR purposes, the SLA tells you almost nothing about whether their data protection practices meet your requirements, that's what the TOMs document is for.
TOMs vs. a certification
A certification is proof, audited by an independent third party, that a provider meets a specific named standard. TOMs, by contrast, is typically the provider's own documented description of its practices, it may or may not have been independently audited. That doesn't make TOMs less useful, a detailed, specific TOMs document is often exactly what a DPA requires, but it's a different kind of evidence than a certification. When you're evaluating a provider, it's worth being clear on which one you're actually looking at: a provider's own account of its practices, versus a third party's confirmation that those practices meet a defined standard.