Guide · GDPR Art. 32
Status: 4 October 2026
TOMs under Art. 32 GDPR: Template, Checklist and Examples
Technical and organisational measures (TOMs) are the core of data security under the GDPR – and the annex every customer asks for in a data processing agreement. Here you will find the Art. 32 structure as a table, AI-specific measures, an interactive TOM checklist that writes an overview from your answers, and a free Word template for the TOM annex.
- Structured along Art. 32(1)(a)–(d)
- Free Word template for the TOM annex
- AI measures: prompts, logs, training
- Checklist writes your draft
TOM catalogue
Demo Organisation Ltd · Art. 32 GDPR
Implementation by protection goal
- Encryption4/5
- Confidentiality5/6
- Availability3/5
- Testing1/4
Recently edited
- Multi-factor authenticationEvidence stored
- Restore testTest due
- Prompt logs AI assistantNo retention set
Sample data · 13 of 20 measures implemented
In short
TOMs are all technical and organisational safeguards that controllers and processors use to protect personal data under Art. 32 GDPR – such as encryption, permission concepts, backups and training. There is no fixed mandatory list: the measures must be appropriate to the risk, reviewed regularly and documented so that they can be demonstrated.
Basics
What TOMs are – and what Art. 32 GDPR actually requires
Art. 32 GDPR requires both the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. “Technical” means everything implemented in systems – encryption, access protection, logging, backups. “Organisational” means rules and processes – responsibilities, policies, training, contracts, review procedures. Only the two together make a security concept: the best encryption helps little if nobody removes access rights when someone leaves the company.
The GDPR deliberately does not specify which measures are “appropriate”. Art. 32(1) names the criteria: the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the likelihood and severity of the risk for the people concerned. Paragraph 2 adds what matters in the risk assessment: destruction, loss, alteration, unauthorised disclosure of or access to personal data – whether accidental or unlawful. A small trade business with a customer list therefore needs different TOMs from a hospital processing health data.
Art. 32(1) becomes more concrete with four points that the measures include “inter alia as appropriate”: (a) pseudonymisation and encryption, (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services, (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident, and (d) a process for regularly testing, assessing and evaluating the effectiveness of the measures. Paragraph 4 adds an organisational duty: people with access to personal data may only process it on instructions from the controller. These points are the natural structure of any TOM documentation – including our template.
TOMs are documented in several places. The record of processing activities contains, “where possible”, a general description (Art. 30(1)(g) for controllers, Art. 30(2)(d) for processors). In the data processing agreement, the processor commits to taking all measures required under Art. 32 (Art. 28(3)(c)) – in practice as a “TOM annex”. And because the controller must be able to demonstrate compliance under Art. 5(2) and Art. 24(1), the measures need evidence as well. Art. 24(1) also states expressly that the measures are reviewed and updated where necessary.
Closely related is Art. 25 GDPR: data protection by design and by default. While Art. 32 concerns the security of processing, Art. 25 requires that data protection principles such as data minimisation are built in when the processing is designed, and that default settings only process the data that is necessary. Many TOM annexes cover both. A data protection impact assessment also describes the measures envisaged to address the risks, including safeguards and security measures (Art. 35(7)(d)) – the TOM documentation is the basis for that.
Infringements of Art. 32 fall under Art. 83(4)(a) GDPR: fines of up to €10 million or 2% of worldwide annual turnover, whichever is higher. In practice something else often matters more: after a data breach, the supervisory authority asks which measures were in place. Being able to present current, evidenced TOM documentation puts you in a far better position than a five-year-old list of good intentions.
- points in Art. 32(1)(a)–(d) – the basic structure of every TOM annex
- 4
- points in Art. 32(1)(a)–(d) – the basic structure of every TOM annex
- fixed mandatory lists: what counts is what is appropriate to the risk
- 0
- fixed mandatory lists: what counts is what is appropriate to the risk
- or 2% of turnover: fine ceiling for infringements of Art. 32 (Art. 83(4))
- €10m
- or 2% of turnover: fine ceiling for infringements of Art. 32 (Art. 83(4))
Structure
TOM list under Art. 32 GDPR: protection goals, examples and evidence
The table follows Art. 32(1)(a)–(d) and Art. 32(4) and adds the points that are common in an annex to a DPA. The example measures are suggestions, not an exhaustive or binding list – what matters is what is appropriate for your processing. The right-hand column shows how you can evidence implementation.
Scroll the table sideways →
| Protection goal / area | Reference | Example measures | Possible evidence |
|---|---|---|---|
| Pseudonymisation | Art. 32(1)(a) | Store identifiers separately from payload data; pseudonymise test and analytics data; protect mapping tables separately. | Data flow description, pseudonymisation concept, access list for mapping tables. |
| Encryption | Art. 32(1)(a) | Encryption in transit for all connections; encryption of databases, disks, backups and mobile devices; managed keys. | Configuration excerpt, cryptography policy, list of encrypted devices. |
| Confidentiality – physical and system access | Art. 32(1)(b) | Access rules for offices and server rooms; password policy; multi-factor authentication for remote and admin access; automatic screen lock. | Physical access concept, identity configuration excerpt, policy. |
| Confidentiality – data access and separation | Art. 32(1)(b) | Role and permission concept on a need-to-know basis; regular recertification; removal on leaving; separation by tenant or purpose. | Permission concept, record of the last recertification, offboarding checklist. |
| Integrity | Art. 32(1)(b) | Logging of input, changes and deletions; tamper-protected logs; defined transfer channels; malware protection; patch management. | Logging concept, sample excerpt, patch report. |
| Availability and resilience | Art. 32(1)(b) | Backup concept with separate storage; redundancy; monitoring with alerting; protection against overload; capacity planning. | Backup concept, monitoring overview, data centre operator’s details. |
| Timely restoration | Art. 32(1)(c) | Documented restore procedure; targets for recovery time and maximum data loss; regular restore tests; contingency plan. | Contingency manual, record of the last restore test. |
| Testing and evaluation | Art. 32(1)(d) | Defined review cycle; vulnerability scans or penetration tests; internal audits; change management for new systems and vendors. | Test plan, test reports, audit findings with status. |
| Instructions and staff confidentiality | Art. 32(4), Art. 28(3)(b) | Confidentiality commitments; documented instructions; training and awareness; named responsibilities. | Signed commitments, training records, organisation chart. |
| Processor control | Art. 28(1), (2), (4) | Vet vendors before engagement; DPA with all mandatory contents; list of sub-processors; regular checks. | DPA overview, review notes, current sub-processor list. |
| Data protection by design and by default | Art. 25 | Only necessary mandatory fields; restrictive default visibility; retention periods configured in the system; data minimisation in feature design. | Design decisions in tickets, screenshot of defaults, retention schedule. |
| Handling personal data breaches | Art. 33, 34 | Notification process with responsibilities; incident detection; processors notify the controller without undue delay (Art. 33(2)). | Incident process, contact list, incident register. |
Art. 32 requires “appropriate” measures based on risk, state of the art and cost – not every row is needed for every processing activity, and some processing needs more. The evidence items are examples.
Structures compared
Art. 32, Section 64 BDSG or the Standard Data Protection Model: how to structure your TOMs
TOM annexes come in three structures. None is legally mandatory for everyone – what matters is that the annex is complete, understandable and verifiable. For most organisations, the Art. 32 structure is the best starting point.
Scroll the table sideways →
| Structure | Origin | Layout | When it makes sense |
|---|---|---|---|
| Along Art. 32 GDPR | Art. 32(1)(a)–(d), Art. 32(4) GDPR | Pseudonymisation and encryption · confidentiality, integrity, availability, resilience · restoration · testing · instructions | Standard for DPA annexes and the record of processing. Follows the legal text directly, so customers and authorities can follow it easily. Basis of our template. |
| Control objectives under Section 64(3) BDSG | German Federal Data Protection Act, Part 3 | 14 objectives, including access, media, storage, user, data access, transfer, input, transport, processor and availability control, recoverability, reliability, data integrity, separability | Applies directly only to German authorities processing data to prosecute criminal and administrative offences (Section 45 BDSG). Often used in practice as a detailed checklist – as a supplement, not an obligation. |
| Standard Data Protection Model (SDM) | Conference of German data protection authorities (DSK) | Six protection goals – availability, integrity, confidentiality, transparency, intervenability, unlinkability – plus data minimisation as an overarching requirement | The authorities’ method for deriving and reviewing TOMs from Art. 5 GDPR. Useful for data protection impact assessments and larger organisations that model data protection systematically. |
Many older German templates still use control terms such as physical access, system access or transfer control. That is not wrong, but it does not automatically cover resilience, restoration and regular testing from Art. 32. Check such templates for these gaps.
AI-specific measures
TOMs for AI services: what LLMs, prompts and logs add
As soon as an AI service processes personal data – a chat assistant, a transcription tool, a document search – Art. 32 applies to it too. Some of the risks are new: inputs end up in logs, models can reproduce data in answers, document searches bypass permissions. These points belong in your TOMs and in your review of AI vendors. They are recommendations, not additional legal obligations.
No training on your data
Make sure by contract and in the settings that the provider does not use inputs and outputs to train its own models. If it does, it is no longer acting solely on your instructions in that respect.
Document the training opt-out in the contract and the admin console
Prompt and response logs
Many services store conversations and technical logs, sometimes for abuse monitoring. Define how long, where and who has access – at the provider and in your own systems.
Set a retention period and access rights for logs
Data minimisation before the prompt
What never reaches the model cannot leak. Names, customer numbers or health details can often be removed or pseudonymised beforehand without hurting the result.
Filter or rule: no unnecessary personal data in prompts
Permissions in document search
AI searches across drives, wikis or mailboxes (retrieval) can surface content a person would otherwise not be allowed to see. The search must inherit the permissions of the sources.
Permission check in the index; test with a restricted account
Business accounts instead of private ones
Private accounts are subject to different terms and sit outside your administration. With company accounts you control settings, access and deletion centrally.
AI usage policy; only approved services with company accounts
Manipulation and faulty output
Crafted inputs (prompt injection) can make a system disclose data or ignore instructions. For high-risk AI, Art. 15(5) of the AI Act requires providers to take measures against such attacks; for everyone else it is good practice.
Review outputs before passing them on; test with crafted inputs
Sub-processors and third countries
Behind an AI service there are often model, hosting and monitoring providers, some outside the EU. The sub-processor list and the transfer mechanism belong in the DPA.
Check the sub-processor list and location for each AI service
Approval of new AI features
AI features often arrive in existing software through an update. Change management makes sure they are assessed before being switched on – otherwise they bypass your TOMs.
Activate AI features only after review; add them to the AI inventory
Deployers of high-risk AI systems have additional duties under the AI Act, such as keeping automatically generated logs for at least six months (Art. 26(6) AI Act). Following the Digital Omnibus, these deployer duties apply to Annex III systems from 2 December 2027. The German data protection conference (DSK) has published guidance on recommended TOMs for developing and operating AI systems (see sources).
Interactive TOM checklist
TOM checklist: check your status and fill in the overview automatically
Go through the measures and mark what is in place. On the right you see the status per protection goal and the open points – and below that a draft of your TOM overview that fills itself in from your answers. Copy it into the Word template and add details and evidence. Your input stays in your browser.
Your TOM status
0 of 18 answered
- Pseudonymisation and encryption0/3
- Confidentiality0/4
- Integrity0/2
- Availability and restoration0/3
- Testing0/2
- Organisation0/4
No answers yet – start on the left with the first measure.
Guidance, not legal advice. The list is not exhaustive; which measures are appropriate depends on the risk of your processing.
Free template
Word template “TOM annex to the DPA” – free, no sign-up
The template is structured along Art. 32(1)(a)–(d) and Art. 32(4) GDPR and contains example measures for each area, tick boxes for the status and a column for implementation and evidence. It suits processors that supply a TOM annex to their customers and controllers that document their own measures.
- Cover block with parties, agreement, version and next review
- Eleven sections from encryption to change history
- Optional section for AI services (training, prompt logs, data minimisation)
- Editable .docx – works in Word, LibreOffice and Google Docs
SimpleAct_TOM_Annex_Template_EN.docx
Word document · 17 KB · status 4 October 2026
The pre-filled measures are examples. Delete what does not apply and describe what is actually in place.
Approach
Creating TOMs in six steps
How to get from an empty template to TOM documentation that stands up to scrutiny. The process is a recommendation; scope and depth depend on the size and risk of your processing.
- 1
Capture processing and systems
The starting point is the record of processing activities: which systems, locations and vendors are involved? Without this overview, TOMs remain abstract.
- 2
Assess risk and protection needs
Which data, how many people, what consequences if it is lost or disclosed? Special categories under Art. 9 GDPR and large volumes call for stronger measures.
- 3
Record existing measures
Usually more is in place than documented: firewall, backups, permissions, training. The checklist above helps you not to miss anything.
- 4
Close gaps and prioritise
Rank missing measures by risk and give them a date and an owner. Mark planned measures as “planned”, not as implemented.
- 5
Store evidence
One piece of proof per measure: policy, configuration excerpt, test record, data centre certificate. A claim without proof helps little in an audit.
- 6
Review and update
Art. 32(1)(d) requires a process for regular testing. A fixed date (e.g. annually) plus triggers such as new systems, new vendors or a security incident has proven itself.
Common mistakes
Where TOM documentation fails in practice
Intentions instead of measures
“Data is adequately protected” is not a measure. Describe concretely what is in place – which encryption, which procedure, which responsibility.
Written once, never reviewed
A TOM annex from five years ago often describes systems that no longer exist. Art. 32(1)(d) and Art. 24(1) require review and updates.
Copied sample TOMs
Adopting someone else’s template unchanged leads to measures that do not exist. In an audit or after a breach, that shows immediately.
Restore never tested
Many have backups, few have ever rehearsed a restore. Only a test shows whether the data comes back “in a timely manner”, as point (c) requires.
Vendors forgotten
TOMs do not end at your own firewall. Cloud, AI and support vendors are part of it through processor control and their own TOM annexes.
AI services not covered
Staff often use AI tools before IT knows about them. Without a policy and an approval process, prompts containing customer data bypass your TOMs.
With SimpleAct
TOMs as a living catalogue instead of a Word file on a drive
In SimpleAct’s GDPR module (from the Professional plan) you manage your TOMs as a catalogue of measures. A starting skeleton with nine categories along Art. 32 is created with one click – then you describe your actual measures, set the implementation status and store evidence.
The skeleton is a start, not a result: you enter the measures and evidence yourself.
- Nine categories as a skeleton, existing entries are kept
- Four statuses: not started, in progress, implemented, evidenced
- Evidence links for each measure
- Links to processing activities in the record and to vendors
- Date of the last review for each measure
- In the same system as the AI inventory, DPAs and retention schedule
FAQ
Frequently asked questions about TOMs under the GDPR
More questions? We're happy to help. Send email · Try 7 days (credit card required)
Sources and status
Last reviewed on · SimpleAct editorial team
- Regulation (EU) 2016/679 (GDPR), EUR-Lex
- Art. 32 GDPR – Security of processing (German)
- Art. 28 GDPR – Processor (German)
- Art. 30 GDPR – Records of processing activities (German)
- Art. 25 GDPR – Data protection by design and by default (German)
- Art. 24 GDPR – Responsibility of the controller (German)
- Art. 83 GDPR – Administrative fines (German)
- Section 64 BDSG – Security of data processing (German)
- Standard Data Protection Model (ULD Schleswig-Holstein, German)
- Standard Data Protection Model (BfDI, German)
- DSK guidance on recommended TOMs for developing and operating AI systems (PDF, German)
- Art. 15 AI Act – Accuracy, robustness and cybersecurity (German)
This page, the checklist and the Word template are for guidance and do not constitute legal advice. The text of the GDPR in the Official Journal of the EU is authoritative. Example measures, AI measures, review intervals and the approach are recommendations.
Changes to this page
- 4 October 2026 – Rebuilt: Art. 32 structure as a table with evidence, structures compared (Art. 32, Section 64 BDSG, SDM), AI-specific measures, interactive TOM checklist with draft, free Word template for the TOM annex.
- 14 June 2026 – First version with protection goals and checklist.
Maintain your TOMs without starting from zero every year
Measures, status and evidence in one place – linked to processing activities, vendors and AI systems.