TOMs under Art. 32 GDPR: 14 audit-proof measures for SMEs

1. What are TOMs?

Technical and organisational measures (TOMs) under Art. 32 GDPR are security measures protecting personal data. They cover technical means (encryption, MFA, backup) and organisational procedures (authorisations, training, four-eyes principle).

The TOM concept is a central document, not an annex to each processing activity. The record of processing activities under Art. 30(1) GDPR requires, as one of its mandatory entries, a general description of the technical and organisational measures — a reference to the central concept is sufficient for this. Copying TOM content into every line of the record creates duplicate maintenance and is one of the common documentation errors.

The reason for the documentation lies one level higher: accountability under Art. 5(2) GDPR requires demonstrating compliance. Only what exists in documented, dated and versioned form can be demonstrated — a practice that is lived but unwritten cannot be evidenced to a supervisory authority.

2. Risk-based: what 'appropriate' means

'Appropriate' means that the level of protection follows the risk of the specific processing, not a fixed list of devices. Art. 32(1) names 4 criteria for appropriateness:

• State of the art — the reference points in supervisory practice are BSI IT-Grundschutz, ISO 27002 and the ENISA recommendations; for cryptographic methods, the concept in this article additionally draws on BSI TR-02102 (see table row 10)
• Costs of implementation
• Nature, scope, context and purposes of the processing
• Likelihood of occurrence and severity of the risk to rights and freedoms

Two risk thresholds of the GDPR are regularly conflated in practice. For the exemption from the record, Art. 30(5) GDPR refers to 'a risk to the rights and freedoms of data subjects'. The 'high risk' threshold, by contrast, applies to the data protection impact assessment under Art. 35(1) GDPR.

A DPIA is required in particular for a systematic and extensive evaluation of personal aspects (profiling) producing legal effects, for processing on a large scale of special categories under Art. 9 GDPR and for systematic monitoring of publicly accessible areas on a large scale (Art. 35(3) GDPR). Where a DPIA is running, the TOM concept is measured against its risk outcome — not against the industry average.

3. 14 typical TOMs for SMEs

Short answer: Fourteen TOM measures form the practical standard for SMEs: MFA for admin accounts, VPN for remote access, full-disk encryption, daily backup following the 3-2-1 principle, need-to-know authorisation concept, annual training, patch management with a 30-day deadline for critical vulnerabilities, four-eyes principle, server room access control, TLS 1.3, pseudonymisation in test environments, document destruction to DIN 66399, an annual penetration test and an emergency plan with a half-yearly tabletop exercise.

The reference case for the following list is a business with around 30 employees, without its own IT department, without processing of special categories under Art. 9 GDPR and without processing subject to a DPIA under Art. 35 GDPR; where the risk situation differs, the scope and depth of review of the individual measures shift accordingly.

The 14 measures in detail: purpose and legal basis

Each point states what the measure serves and — where one exists — the provision from which the requirement follows. Cycles and deadlines without a statutory basis are expressly marked as practice recommendations. Individual measures are a statutory minimum for entities under the NIS2 regime — the Austrian NISG 2026 obligations only become applicable from 1 October 2026; which companies fall under them is set out in section 9.

1. MFA for all admin accounts. Administrative accounts are the lever: whoever takes them over bypasses every protective layer beneath. For entities under the NIS2 regime, multi-factor authentication forms part of the statutory minimum catalogue (§ 30(2) German BSI Act (BSIG) 2025; § 32(4) Austrian Network and Information Systems Security Act 2026 (NISG 2026)); under Art. 32 GDPR it is a risk-based decision that you must justify and document in accordance with Art. 5(2) GDPR.
2. VPN for remote access. Remote access runs over networks you do not control; without transport security, the confidentiality of the transmitted data cannot be verified. Access control and secured communication form part of the minimum catalogue for NIS2 entities (§ 30(2) BSIG 2025; § 32(4) NISG 2026).
3. Full-disk encryption. This measure determines the legal consequence of a breach: under Art. 34(3) GDPR, notification of the data subject is not required where appropriate technical and organisational protective measures — encryption in particular — have been applied and the key has not been compromised along with the data. In practice, a lost encrypted device is classified as a low risk, an unencrypted one as a high risk.
4. Daily backup. A loss of availability can also be notifiable: a hardware failure with data loss triggers the notification obligation under Art. 33(1) GDPR where there is a risk to the rights and freedoms of natural persons. Business continuity and backup also form part of the NIS2 minimum catalogue (§ 30(2) BSIG 2025; § 32(4) NISG 2026). The 3-2-1 principle in the table is a practice recommendation for three copies on two different media types, one of them off-site.
5. Need-to-know authorisation concept. It limits the damage that a single compromised or misused account can cause. In Austria, § 6 DSG flanks the concept: controllers, processors and their employees are bound to secrecy (data secrecy, Datengeheimnis).
6. Annual training. Awareness-raising and training of the staff involved form part of the monitoring task of the data protection officer (Art. 39(1)(b) GDPR). At NIS2 entities, the management bodies must additionally take part in cybersecurity training — in Germany on a regular basis (§ 38(3) BSIG 2025), in Austria in specifically designed training; there, appropriate training must also be offered to employees on a regular basis (§ 31(2) NISG 2026). The annual cycle itself is a practice recommendation.
7. Patch management. Secure acquisition, development and maintenance, including vulnerability management, form part of the NIS2 minimum catalogue (§ 30(2) BSIG 2025; § 32(4) NISG 2026). The 30-day and 90-day values are practice deadlines from your own concept, not statutory deadlines — record them in writing and log any deviations with reasons.
8. Four-eyes principle. A practice recommendation. It secures the protection objective of integrity where a single misstep releases data irreversibly to the outside. When awarding work to processors, it meets the selection duty under Art. 28(1) GDPR (section 7).
9. Server room access. Physical security is the layer that no software replaces; in the ISO mapping it corresponds to A.11. An access log makes it possible to evidence who had access and when in the event of a breach. The scope, level of detail and retention of the log are a practice recommendation.
10. SSL/TLS for web services. Cryptography and encryption form part of the minimum catalogue for NIS2 entities (§ 30(2) BSIG 2025; § 32(4) NISG 2026). Under Art. 32 GDPR, the choice of method is risk-based and is measured against the state of the art; the reference points for this are set out in section 2 and shift over time.
11. Pseudonymisation in the test environment. Art. 32(1)(a) GDPR expressly names pseudonymisation as a protective measure. It carries particular weight for special categories under Art. 9(1) GDPR — health data, biometric data for the purpose of unique identification, trade union membership and others — for which a general prohibition on processing with narrow exceptions applies.
12. Document destruction. Destruction physically implements what the record of processing activities documents as an erasure period; typical retention obligations are 10 years under the German Commercial Code (HGB) and the German Fiscal Code (AO) for accounting records. The security level under DIN 66399 is a practice determination that you align with the sensitivity of the documents.
13. Penetration test. It evidences effectiveness rather than intent; assessing effectiveness forms part of the NIS2 minimum catalogue. The evidence obligations differ: in Germany, operators of critical installations must demonstrate implementation at a point in time determined by the Federal Office for Information Security (BSI) — at the earliest three years after the first classification — and thereafter every three years by means of security audits, inspections or certifications (§ 39(1) BSIG 2025). In Austria, all essential and important entities submit a structured self-declaration within twelve months after the registration obligation arises (§ 33(1) NISG 2026); upon request, implementation must be evidenced by an independent body within two years (§ 33(2) NISG 2026). The annual test is a practice recommendation.
14. Emergency plan + tabletop. The 72-hour deadline in Art. 33(1) GDPR runs from becoming aware — not from completion of the internal assessment. Without a rehearsed procedure, the first half of the deadline is burnt clarifying responsibilities. NIS2 entities additionally report in three stages (24 hours, 72 hours, one month; section 6). The half-yearly tabletop exercise is a practice recommendation: the reporting path is talked through with everyone involved around the table, without technical simulation.

4. ISO 27001 mapping

Short answer: GDPR TOMs can be mapped directly onto ISO 27001 Annex A controls: access control corresponds to A.9, encryption to A.10, physical security to A.11, backup to A.12.3, training to A.7.2.2, incident management to A.16 and supplier management to A.15. Anyone certified to ISO 27001 thereby already covers most of the Art. 32 requirements.

The remaining gap has to be closed differently in Germany and Austria: in Germany via employee data protection under § 26 German Federal Data Protection Act (BDSG), in Austria via the construction set out in section 10 comprising Art. 6 and Art. 88 GDPR, the DSG and the Austrian Labour Constitution Act (ArbVG).

5. Review cycle + supervisory practice

The practical standard is an annual review plus an ad hoc review after incidents and after material IT changes — intervals that are practice recommendations, not statutory deadlines. Supervisory authorities, by contrast, rarely examine the concept in isolation; they usually do so prompted by a specific occasion, primarily in two constellations:

1. After a notified personal data breach (Art. 33): were the TOMs appropriate?
2. In a DPIA consultation (Art. 36): are the TOMs sufficient for the high risk?

In our practical experience, the order of examination is regularly the same: record of processing activities, then processing agreements, then the TOM concept, then the DPIA. The TOM concept is then measured against whether it fits the risk situation of the processing activities documented there. A concept that does not cover processing activities from the record is noticed at precisely this step.

Document the date, reviewer and outcome of each review so that the concept's currency remains demonstrable.

6. Adapting TOMs after an incident

After every personal data breach, TOMs must be reviewed: under the second sentence of Art. 24(1) GDPR, the measures are reviewed and updated where necessary. Documenting the adaptation is audit-relevant. Typical adaptations — the second half of each sentence is a practice recommendation for scope and documentation:

• MFA rollout after a phishing incident — admin accounts and external access (VPN, cloud) first, recorded with the implementation date for each account group
• Reduction of authorisations after an insider incident — recertification of all roles with access to the affected data holdings, with the outcome recorded together with date and reviewer
• Backup test after a ransomware incident — a restore test from the off-site copy, logged with date, scope restored and duration
• Training after a 'human error' incident — follow-up training for the affected department with an attendance list, instead of bringing forward the annual training for everyone

The adaptation belongs in the same file as the incident itself: under Art. 33(5) GDPR, every personal data breach must be documented — including those that are not notifiable — comprising the time, description, consequences, measures taken and the reasons where no notification was made.

As regards the deadline, the clock runs in parallel with other reporting paths. The NIS2 rows in the following overview apply exclusively to entities falling under the NIS2 regime (section 9); the Austrian NISG 2026 obligations only become applicable from 1 October 2026. The GDPR rows apply to every controller:

7. TOMs at the processor

Selecting a processor is itself an organisational measure: under Art. 28(1) GDPR, the controller may only work with processors providing sufficient guarantees for appropriate technical and organisational measures. The selection therefore presupposes an assessment of those guarantees before the processing begins; document it so that it remains demonstrable under Art. 5(2) GDPR.

Under Art. 28(3) GDPR, the contract must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller. On the other side, the processor maintains its own record with four mandatory entries; under Art. 30(2)(d) GDPR this includes, where possible, a general description of the technical and organisational measures referred to in Art. 32(1).

In practice: an annual assessment of the processor's TOMs using a questionnaire, documented with date and assessment outcome — a cycle you set yourself, not a statutory deadline. Possible evidence of the guarantees includes: the TOM annex to the processing agreement, an ISO 27001 certificate with a matching scope, a current audit report or the documented answers to your own questionnaire on access control, encryption, backup, sub-processors and the erasure concept; which of these you require is your own determination (practice recommendation). In Austria, no national special rule applies to processing on behalf of a controller; Art. 28(1) and (3) GDPR remain applicable, and data secrecy (Datengeheimnis) under § 6 DSG applies to employees in addition.

8. Sanction framework for TOM deficiencies

A TOM deficiency falls within the lower of the GDPR's two fine ranges. Art. 83(4) GDPR covers, among other things, infringements of Arts. 25 to 39 — including Art. 32 — whereas the higher range in paragraph 5 applies, among other things, to infringements of the processing principles, the conditions for consent and data subject rights. The figures in detail:

In Germany, the competent authority for non-public bodies is the authority designated under the law of the relevant federal state (§ 40(1) BDSG); the Federal Commissioner for Data Protection (BfDI) is competent for the federal public bodies and for certain providers of telecommunications services (§ 9(1) BDSG). In Austria it is solely the Austrian Data Protection Authority (Datenschutzbehörde), established under § 18(1) DSG as the national supervisory authority pursuant to Art. 51 GDPR.

9. Where NIS2 applies in addition: BSIG 2025 and NISG 2026

Whether your company must also meet the NIS2 regime alongside Art. 32 GDPR is usually determined by two features together: belonging to a type of entity under Annex 1 or Annex 2 and the size of the company (§ 28 BSIG 2025; §§ 24, 25 NISG 2026); certain groups, however, are covered by both acts regardless of size. The classification in detail is explained in the articles on NIS2 implementation in Germany and on the NISG 2026 in Austria. In Austria, the NISG 2026 becomes applicable on 1 October 2026. Registration must take place within three months of entry into force or of the conditions being met (§ 29(2) to (4) NISG 2026).

The catalogue of obligations largely overlaps with a TOM concept: § 30(2) BSIG 2025 and § 32(4) NISG 2026 require at least risk analysis, handling of security incidents, business continuity, supply chain security, cryptography, access control and multi-factor authentication. In addition, both acts expressly address the management level: in Germany, management bodies must implement the measures and supervise their implementation and are liable for culpable breaches of duty under the company law applicable to the legal form (§ 38(1) and (2) BSIG 2025); in Austria, the management bodies must ensure and supervise compliance (§ 31(1) NISG 2026). For infringements of the risk management and reporting obligations, the fine ranges are up to EUR 10 million for particularly important entities and EUR 7 million for important entities (§ 65(5) to (7) BSIG 2025); in Austria up to EUR 10 million or 2% and EUR 7 million or 1.4% respectively of worldwide annual turnover for administrative offences under § 45(1) (§ 45(2) and (3) NISG 2026).

10. Austria: TOM-relevant deviations

The GDPR applies directly in Austria — what differs is the national superstructure that the DSG puts in place via opening clauses. Three points bear directly on a TOM concept:

• Data secrecy (Datengeheimnis, § 6 DSG): controllers, processors and their employees are bound to secrecy. Committing staff to data secrecy is therefore a self-standing organisational building block of the TOM concept in Austria; you determine the form and documentation of that commitment yourself (practice recommendation).
• Image recording (Bildaufnahme, §§ 12, 13 DSG): video surveillance has its own lawfulness provision. § 13(5) DSG establishes a labelling obligation; retention lasting longer than 72 hours must be proportionate and must be logged and justified separately (§ 13(3) DSG). Among other things, image recording for the purpose of monitoring employees is unlawful (§ 12(4) no. 2 DSG).
• Employee data protection: the DSG contains no dedicated section corresponding to § 26 BDSG. What governs are Art. 6 and Art. 88 GDPR, supplemented by § 12(4) no. 2 DSG and § 96(1) no. 3 ArbVG — monitoring measures affecting human dignity only with the consent of the works council or a works agreement.

The obligation to designate a data protection officer also separates the two legal areas: in Germany, § 38(1) BDSG applies in addition from, as a rule, at least 20 persons constantly engaged in automated processing — and, irrespective of the number of persons, for processing subject to a DPIA under Art. 35 GDPR as well as for commercial transfer or for market and opinion research. Austria provides for no numerical designation threshold going beyond Art. 37 GDPR; there, the obligation follows directly from Art. 37 GDPR, while § 5 DSG only governs secrecy and — in the public sector — freedom from instructions.