TOM Template under Art. 32 GDPR: Structure, Mandatory Fields, Audit-Readiness

Art. 32 GDPR obliges controllers and processors to take appropriate technical and organisational measures to ensure a level of protection appropriate to the risk. A TOM template (technical and organisational measures) is the form in which this evidence is kept. It is not an end in itself but the central annex to data processing agreements under Art. 28(3) GDPR and the first document a supervisory authority requests in the event of a data breach.

In practice, TOM lists rarely fail on content. They fail on a lack of reference to risk, outdated version states and blanket wording that does not stand up to the protection-class differentiation under Art. 32(1)(b) GDPR. This article describes the verifiable structure of a TOM template, the mandatory fields, the typical gaps in audits and the handover rules towards processors. What matters is not the length of the document but the traceability of each individual measure.

Art. 32 GDPR requires a level of protection appropriate to the risk and names four protection objectives: confidentiality, integrity, availability and resilience. A TOM template must show that each measure taken is assigned to one of these protection objectives and that the selection is based on a risk assessment. The federal and state supervisory authorities additionally expect a reference to Art. 25 GDPR, that is, to data protection by design and by default.

The TOM list is at the same time an annex to the data processing agreement under Art. 28(3)(c) GDPR. Processors must document their measures in such a way that the controller can review them independently. Blanket wording such as 'the state of the art is observed' is not sufficient. A concrete, verifiable description is required. An external data protection officer regularly checks precisely this annex as a first step, because it forms the bridge between the contract and lived practice.

From the supervisory authority's perspective, the TOM template is therefore less a checklist than a steering document. It makes risks, decisions and responsibilities visible. Anyone who takes this documentation seriously simultaneously fulfils the accountability obligation under Art. 5(2) GDPR.

A verifiable TOM template contains at least ten fields per measure. First, the sequential number for unambiguous referencing. Second, the protection objective under Art. 32(1) GDPR. Third, the category, such as physical access control, system access control, data access control, transfer control, input control, instruction control, availability control and separation control. These eight types of control derive from the former annex to Section 9 of the old BDSG and are still accepted by supervisory authorities as a structural grid.

Fourth, the concrete measure in plain text. Fifth, the responsible party with role, not just department. Sixth, the system or procedure used. Seventh, the effectiveness check, that is, how and by whom the measure is reviewed. Eighth, the review interval in months. Ninth, the date of the last review. Tenth, the version number of the measure itself.

These ten fields allow a supervisory authority to determine in under two minutes whether the TOM list is lived or merely exists formally. Others run compliance like a filing cabinet. We run it like software. A sensible addition is a field for the reference to the processing activity under Art. 30 GDPR, so that in the event of a change in the record it immediately becomes visible which measures are affected.

Without a documented risk assessment, a TOM template is formally incomplete. Art. 32(1) GDPR requires that account be taken of the state of the art, the costs of implementation and the nature, scope, circumstances and purposes of processing, as well as the varying likelihood and severity of the risk to the rights and freedoms of natural persons.

In practice, this means a two-stage logic. At the first stage, a protection-needs assessment is carried out per processing activity, usually in the grades normal, high and very high. At the second stage, measures are derived that match the respective protection needs. A login system with a password plus a second factor suffices for normal protection needs. For special categories of personal data under Art. 9 GDPR, more far-reaching measures such as hardware-bound tokens or role-based authorisation separation are required.

The documentation of the risk assessment can be integrated as a separate field in the TOM list or kept as a separate protection-needs register. What is important is the linkage. A TOM list that does not match the risk assessment arouses the suspicion of sham compliance in an audit. The deadline runs from awareness, including when measures are adjusted following identified changes in risk.

Physical access control comprises all measures that prevent physical access to data processing facilities. These include locking systems, visitor logs, video surveillance and server room access under the four-eyes principle. System access control governs logical access to systems, that is, authentication, multi-factor procedures and locking mechanisms. Data access control determines which roles may read, write or delete which data.

Transfer control documents how personal data is protected during transport or transmission, for example through transport encryption under TLS 1.2 or higher. Input control enables subsequent determination of who entered, changed or removed which data and when. Instruction control ensures that processors only act in accordance with instructions, including sub-contractor arrangements.

Availability control protects against accidental destruction or loss, for example through a backup strategy with the 3-2-1 rule and a documented recovery time. Separation control ensures that data collected for different purposes is processed separately, multi-tenant-capable or by logical separation. These eight categories structure the TOM list and avoid overlaps. Each concrete measure is assigned to exactly one category, which facilitates examination in an audit and prevents duplication.

Art. 32(1)(d) GDPR requires a procedure for regularly testing, assessing and evaluating effectiveness. This point is the one most frequently overlooked in practice. A measure without a documented effectiveness check is, in an audit, equivalent to a missing measure. Auditors do not ask whether a backup exists, but when the last restore test was carried out and what its result was.

The effectiveness check is defined per measure. For physical access control, an annual spot-check of the locking system and a documented evaluation run of the access log are sufficient in many cases. For data access control, a quarterly authorisation review is required, comparing the assigned roles with the actual tasks. For backup procedures, a half-yearly recovery test is the minimum standard, documented with date, responsible party and result.

The results of these checks are kept in an effectiveness register that is linked to the TOM list. In the event of a data breach under Art. 33 GDPR, this register determines the supervisory authority's assessment. The auditor calls, the evidence is ready. The FAQ collection on compliance evidence shows typical forms of proof and log structures for the effectiveness check.

A TOM template without versioning loses its evidential value. In the event of a data breach, the supervisory authority does not ask for the current TOM list but for the version that applied at the time of the incident. Versioning must therefore document every change of measure with date, author and justification. Decimal version numbers are customary, where an increase in the major version marks a fundamental change and an increase in the minor version a detailed adjustment.

The retention period is based on the general limitation period of three years under Section 195 BGB and, in the context of tax-relevant data, on Section 147 AO with ten years. A retention period of ten years for the TOM list itself and for the associated effectiveness evidence is the safe choice. Retention in an audit-proof system is not mandatory but facilitates proof of immutability.

Triggers for changes are clearly defined. A new processing activity, a new processor, a change in legal basis, an identified security incident or an indication from a data protection impact assessment under Art. 35 GDPR. Each of these triggers prompts a review of the TOM list. The documentation of the review itself, even where it leads to no change, is part of the accountability evidence.

Art. 28(3) GDPR obliges processors to make available to the controller all information necessary to demonstrate compliance with the contractual obligations. The TOM list is the primary tool for this. Processors must describe their measures in enough detail for the controller to be able to review them independently. Blanket references to certificates are not sufficient; they do not replace a concrete description.

On the controller's side, there is an obligation to review the processor's TOM list initially and at regular intervals. An annual review is customary, half-yearly for critical processing. The review itself must be documented, at least with date, reviewing person and result. Irregularities trigger follow-up queries, audit rights under Art. 28(3)(h) GDPR or, where appropriate, a change of supplier.

For multi-stage processing chains with sub-contractors, the TOM list becomes more complex. Each sub-contractor needs its own TOM list, which the main processor presents to the controller. Responsibility for the risk assessment remains with the controller. The deed of appointment, signed, filed, demonstrable. This logic applies analogously to every TOM annex to a data processing agreement.

The most common gap is a TOM list whose last update is more than twelve months ago. Supervisory authorities interpret this as an indication of a lack of maintenance. The second most common gap is the use of a template from the internet without company-specific adaptation. Such templates contain measures that do not exist in the specific company and, conversely, lack relevant measures. In an audit, this discrepancy is visible within a few minutes.

Third gap: a missing effectiveness check. Measures are listed but no one reviews them. Fourth gap: authorisations that have not been reviewed for years, with departed employees who would formally still have access. Fifth gap: backup strategies without a documented recovery test. Sixth gap: data processing agreements without a current TOM annex from the service provider.

Seventh gap: no separation between production and test environment, with real personal data in test databases. Eighth gap: missing encryption of mobile devices. Ninth gap: no regulated procedure when an employee leaves, with handover of authorisations. Tenth gap: missing linkage to the data protection impact assessment for high-risk processing. Each of these gaps can be structurally addressed in a maintained TOM template if the ten mandatory fields are consistently filled in.

A TOM list is only as good as the system in which it is kept. Excel-based templates work for small controllers with a manageable processing landscape. As soon as several sites, several processors and several protection-needs grades come into play, the spreadsheet form reaches its limits. Versioning, authorisations and linkage to the record of processing activities under Art. 30 GDPR become a daily task.

CIVAC is a compliance platform and Officer-as-a-Service. In the workspace you keep the TOM list with the ten mandatory fields, link it to the record of processing activities and steer effectiveness checks via due tasks. 37 ready-to-use audit templates cover authorisation review, backup test, processor audit and protection-needs assessment. Data is held in EU data residency, the ISMS is certified under ISO/IEC 27001:2022. License the workspace for your internal officers or have our officers appointed. In the second model the deed of appointment is issued within two working days, the external data protection officer takes over the maintenance of the TOM list, the effectiveness checks and the annual adjustment.

Turn reading into a mandate. Write to info@civac.de or use the contact form at civac.de. You will receive a structural proposal for your TOM template and an assessment of which model suits your processing landscape.