Technical and organisational measures (TOM): What Art. 32 GDPR requires and how small businesses implement it

In brief

• TOM are mandatory for everyone who processes personal data. Art. 32 GDPR requires a “level of security appropriate to the risk”, regardless of company size.
• Appropriate means: matched to the risk, not maximal. A trade business with customer addresses needs different measures than a medical practice with health data. Rating the protection needs is the first step.
• Technology alone is not enough. Most data breaches are caused by people: wrong email recipient, phishing, former employees with active accounts. Organisational measures such as an access control concept, training and offboarding are at least as important as encryption.
• TOM must be documented and reviewed regularly. The document is a mandatory component of the record of processing activities and an annex to every data processing agreement. Without evidence, the authority treats the measure as non-existent.

What TOM are and where the obligation comes from

Technical and organisational measures are all the precautions you take to protect personal data against loss, destruction, alteration and unauthorised access. Technical measures are encryption, firewalls, backups, access rights. Organisational measures are policies, training, deputy arrangements, the process when an employee leaves. The dividing line is blurred and, in practice, unimportant. What matters is that both levels work together.

The obligation appears in several places in the GDPR. Art. 5(1)(f) names “integrity and confidentiality” as a principle of every processing operation. Art. 24 makes the controller responsible for implementing appropriate measures and being able to demonstrate them. Art. 25 requires data protection by design and by default. Art. 32 is the central provision on the security of processing. Art. 28(3)(c) obliges processors to take the same measures, and Art. 30(1)(g) requires a general description of the TOM in the record of processing activities.

What Art. 32 GDPR specifically requires

Art. 32(1) GDPR names four points that are to be considered “inter alia”. This is not an exhaustive list, but it is the benchmark every supervisory authority applies:

1. 1Pseudonymisation and encryption of personal data (point (a)). Encryption in transit (TLS) and at rest (full-disk encryption, encrypted backups) is standard today, not an optional extra.
2. 2Ensuring the ongoing confidentiality, integrity, availability and resilience of the systems (point (b)). These are the classic protection goals of information security, supplemented by the ability to withstand disruptions.
3. 3Restoring availability and access rapidly after an incident (point (c)). This means backups that have been tested, and an emergency plan that works without the admin who happens to be on holiday.
4. 4A process for regularly testing, assessing and evaluating effectiveness (point (d)). Setting things up once and forgetting about them is not enough. The measures must be reviewed and adjusted periodically.

Which level of security is “appropriate” is determined under Art. 32(1) by the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the likelihood and severity of the risk for the data subjects. Paragraph 2 specifies the risks: destruction, loss, alteration, unauthorised disclosure or unauthorised access. In practical terms: you must be able to justify why your measures match your risk. No more, but also no less.

Protection goals: The yardstick for every measure

Every measure serves at least one protection goal. Mapping them helps you spot gaps: if all your measures target confidentiality and none target availability, the backup is missing.

The Standard Data Protection Model (SDM) of the German supervisory authorities adds data minimisation, unlinkability, transparency and intervenability to these goals. It is the methodology the authorities themselves use when they audit, and therefore a good reference framework if you want to build a TOM document that holds up in front of an authority.

The TOM catalogue: Control areas with examples

In Germany, a catalogue of control areas has become established that goes back to the annex to the old § 9 of the German Federal Data Protection Act (BDSG) and lives on today in § 64(3) BDSG for public bodies. It is not binding for companies, but it is the structure that clients, supervisory authorities and auditors expect. If you build your TOM document along these areas, you will be understood.

Rating protection needs: How much is enough?

Before you select measures, you need to know how high the risk is. The three-tier classification used by the BSI, Germany’s Federal Office for Information Security, into normal, high and very high protection needs has proven itself. The question behind it: what happens to the data subjects if the data falls into the wrong hands, is altered or is lost?

• Normal: business contact details, order data without payment information, newsletter addresses. The damage to data subjects would be limited and manageable. Baseline protection is sufficient.
• High: employee data with salary and performance reviews, applicant data, credit data, customer data with bank details, location data. The damage would be considerable. Additional measures such as strict allocation of rights, encryption and logging are mandatory.
• Very high: health data, data on religion, trade union membership, sex life, biometric data (Art. 9 GDPR), children’s data, data from advisory or counselling relationships. The damage could be existential. Here encryption, two-factor authentication and complete logging are the minimum, and a data protection impact assessment is often required.

The rating belongs in the TOM document. It is the justification you use to explain to the supervisory authority why your package of measures is appropriate.

Baseline protection for a company of ten people

Most TOM lists on the internet describe data centres. For a small company with normal to high protection needs, realistic baseline protection looks like this. All of it can be implemented with standard tools and at manageable cost:

• Two-factor authentication for email, cloud storage, CRM and all systems holding customer data. The most effective single measure against phishing.
• Password manager for the whole team, no passwords in Excel lists or on sticky notes, no shared group logins.
• Automatic updates for operating systems, browsers and applications. Unpatched software is the most common point of entry.
• Encrypted devices: full-disk encryption on all laptops (BitLocker, FileVault) and smartphones, remote wipe in case of loss.
• Backups following the 3-2-1 rule: three copies, two different media, one off-site or in the cloud. And test a restore once a quarter.
• Access control concept: who is allowed to do what, set down in writing. Access only as far as the task requires.
• Onboarding and offboarding checklist: when someone leaves, block all accounts on the last working day, collect devices, check email forwarding. Forgotten accounts of former employees are a classic cause of data breaches.
• Confidentiality obligation for all employees, documented and signed (Art. 29, Art. 32(4) GDPR).
• Annual data protection training with evidence of attendance, supplemented by notes on current phishing scams.
• Rules for working from home and mobile working: no working over open Wi-Fi without a VPN, no private devices without approval, lock the screen, do not leave paper on the train.
• Clean desk rule and document shredding in line with DIN 66399 (at least security level P-4 for personal data), lockable cabinets for personnel files.
• Data breach process: who reports what to whom, how it is documented, who decides on notifying the supervisory authority within the 72-hour deadline (Art. 33 GDPR).
• One-page emergency plan: key contacts, service providers, access credentials for the backup, order of recovery. Printed out, not just on the server that has just been encrypted.

Organisational measures that are almost always missing

Technology can be bought. Organisation has to be lived, and that is exactly where most TOM documents fail in practice. Three examples from audits:

• The access control concept exists but is never reviewed. After three years, trainees have admin rights and the former bookkeeper can still access payroll. Solution: a six-monthly review of rights, signed off by the line manager.
• Service providers are not managed. The DPA is in the folder, but nobody knows which sub-processors the hosting provider now uses or whether the ticketing system is still running in the EU after the change of vendor. Solution: a list of service providers with an annual review, linked to the record of processing activities.
• Training without evidence. Staff were trained in 2022, and four people have joined since. Solution: training on joining and annually, with attendance documented. After a data breach, the training records are the first thing the authority wants to see.

Testing effectiveness: Art. 32(1)(d) in practice

The obligation to review regularly is the part of Art. 32 that is ignored most often. Yet it is easy to implement if you put it in the calendar:

If you want more: an external penetration test of the website and the externally reachable systems every one to two years makes sense for companies with high protection needs. For baseline protection, a free website scan that shows whether TLS is configured correctly and which third-party providers are loaded is enough.

The TOM document: Structure and use

The TOM document is the description of your measures that you present to three audiences: the supervisory authority during an audit or after a data breach, your clients as an annex to the DPA if you are a processor yourself, and your own record of processing activities, which under Art. 30(1)(g) requires a “general description” of the TOM. A proven structure:

1. 1Cover page: controller, scope (which sites, systems, processing operations), version, date, contact person, data protection officer.
2. 2Protection needs: which categories of data you process and how you rate them. The justification for the level of measures.
3. 3Measures per control area: the structure from the catalogue above, with the specific measures implemented for each area. Specific means: “two-factor authentication for Microsoft 365 and the CRM”, not “appropriate authentication”.
4. 4Review procedure: the review schedule from the previous section.
5. 5Change history: what was changed and when. It shows the authority that the document is alive.

TOM, DPA and data protection impact assessment: telling them apart

Three documents that are often confused. The TOM describe your security measures for all processing operations. The data processing agreement governs the relationship with a single service provider and contains that provider’s TOM as an annex. The data protection impact assessment under Art. 35 GDPR is the risk analysis for a single processing operation that is likely to result in a high risk, and in it the TOM are listed as mitigating measures. All three draw on the same list of measures, which is why it pays to maintain it centrally, in one place.

The most common mistakes

• A copied template list with measures that do not exist in the company (“biometric access control to the server room” for an office with a NAS under the desk). In an audit this is spotted immediately and costs credibility for everything else.
• No rating of protection needs. Without it, you cannot justify why the measures are appropriate.
• TOM thought of purely as technology. Offboarding, training and deputy arrangements are missing.
• No review. The document from 2020 is unchanged, even though everything has since moved to the cloud.
• Backup without a test. The backup ran, but nobody has ever tried a restore.
• Confusion with the record of processing activities. The RoPA describes what you process, the TOM describe how you protect it. The two refer to each other but are separate documents.

What happens without TOM?

Infringements of Art. 32 GDPR fall within the fine bracket of up to 10 million euros or 2 percent of worldwide annual turnover (Art. 83(4)(a) GDPR). In practice, a fine rarely comes for missing TOM alone, but after a data breach: an unencrypted laptop is stolen, a ransomware attack encrypts customer data, a former employee still had access. The authority then examines whether the measures were appropriate, and the absence of a TOM document already answers that question. On top of that come compensation claims by data subjects (Art. 82 GDPR), the costs of recovery and the loss of trust among customers.

Creating TOM with Dieter

Dieter guides you through the control areas with yes/no questions and generates a TOM document from your answers, including an access control concept, which you can use as an annex to your DPAs and your record of processing activities. If something changes, you adjust your answers and the document is regenerated, with a version history. The page Create TOM with Dieter shows how it works.

Conclusion

TOM are not an IT project but the answer to a simple question: what do you do to make sure the data of your customers, employees and partners is not lost and does not fall into the wrong hands? If you rate your protection needs honestly, implement baseline protection consistently, take the organisational side seriously and review once a year, you meet Art. 32 GDPR and sleep more soundly after the next wave of phishing.