GDPR TOMs: technical and organisational measures under Art. 32

What does Art. 32 GDPR require?

Controllers and processors implement appropriate technical and organisational measures “to ensure a level of security appropriate to the risk” (Art. 32(1)). They take into account the state of the art, the costs, the nature, scope, context and purposes of processing, and the likelihood and severity of the risk for the rights and freedoms of people.

The measures include “inter alia as appropriate”: pseudonymisation and encryption (point (a)), the ongoing confidentiality, integrity, availability and resilience of systems (b), timely restoration after an incident (c), and a process for regularly testing the effectiveness (d). In the German text, the word “gegebenenfalls” (as appropriate) was added by a correction in 2018.

In the assessment, destruction, loss, alteration, unauthorised disclosure and unauthorised access weigh in particular (para. 2). Para. 4 also requires steps to ensure that staff with access to personal data process it only on instructions.

Art. 32(1), (2) and (4) GDPR

How do you choose appropriate measures?

The yardstick is the risk to the people whose data you process. The DSK is the conference of Germany's data protection authorities. In its Kurzpapier Nr. 18 it describes the risk with two dimensions: the severity of possible harm, such as damage to reputation or financial loss, and the likelihood that it occurs.

The DSK sorts the result into low risk, risk and high risk. Where a high risk is likely, its notes on the record of processing say you determine the measures as part of a data protection impact assessment under Art. 35.

For choosing measures, the same notes refer to the DSK's Standard Data Protection Model (SDM), to the BSI's IT-Grundschutz and to ISO standards. SDM version 3.1 of 2024 maps measures to seven protection goals, from data minimisation to intervenability, meaning that data subjects can exercise their rights. It reads these goals from the data subject's point of view.

Art. 32(1) · Art. 35 GDPR

Where and how to describe your TOMs

Art. 32 prescribes no separate document. The record of processing activities should, however, contain a general description of the measures where possible (Art. 30(1)(g)), and in the DSK's view that description is the rule despite “where possible”.

It should be concrete enough for the supervisory authority to make a first assessment of lawfulness (DSK, Kurzpapier Nr. 1). You may refer to existing documents, such as a security concept from your information security work, and then add what applies to a particular processing.

Art. 32 applies to processors too, and your company uses only processors that provide sufficient guarantees (Art. 28(1)). The contract binds them to all measures required under Art. 32 and to giving you the information needed to demonstrate compliance (Art. 28(3)(c) and (h)). Ask for their description before you engage them.

Art. 28(1) and (3) · Art. 30(1)(g) GDPR

Example: the TOMs of a company with 80 employees

Muster Metall GmbH, a made-up company, describes its TOMs along the points of Art. 32(1). A weak sentence would be: “We protect data in line with the state of the art.” It says nothing about what actually happens.

Its description says instead: the disks of all laptops are encrypted, and the recovery key is kept apart from the device (a). Rights are assigned through roles, and email and remote access require a second factor (b). The server is backed up daily, and the date of the last restore that worked is recorded (c).

For point (d) it states who reviews the measures and when: management together with the external data protection officer. The company does not use pseudonymisation so far and records why.

Which mistakes to avoid with TOMs

Do not copy a template unchanged. It describes measures that may not apply in your business, and your company must be able to demonstrate what it actually does (Art. 5(2)).

Do not list only technology. Organisational measures include binding staff to confidentiality, instructions to staff under Art. 32(4) and a concept for roles and access rights.

Do not forget point (d). Without a process that tests effectiveness, the description is a snapshot of one day. Art. 24(1) requires measures to be reviewed and updated where necessary.

Do not take over NIS 2 measures unchecked. They protect your systems, while Art. 32 asks about the risk to the people whose data you process.

With an AI assistant: what it can draft for your TOMs

An AI assistant such as Claude, ChatGPT or Copilot can draft a description along points (a) to (d) from your documents and flag gaps, such as missing information on pseudonymisation. Through MCP (Model Context Protocol), an open standard, it can also read your NIS 2 walkthrough. Our article on drafting TOMs with AI from your NIS 2 records shows how.

Whether a measure is appropriate to the risk is for your company to decide as controller (Art. 32(1)). Check every sentence of the draft against what is actually set up in your business.

If you give the assistant documents containing personal data, its vendor processes them too. Where the vendor acts as a processor, a contract under Art. 28(3) GDPR is required. A GDPR walkthrough on nisd2.eu is in the works, with the same MCP server as the NIS 2 walkthrough.