Technische und organisatorische Maßnahmen (TOM) DSGVO: Die Checkliste für 2026

Die Technischen und organisatorischen Maßnahmen (TOM) nach Art. 32 DSGVO sind die operative Seite des Datenschutzes — und werden bei praktisch jedem Audit geprüft. TOMs sind nicht nur eine Pflicht für Verantwortliche, sondern auch für Auftragsverarbeiter und müssen als Anlage zum AVV dokumentiert werden.

Dieser Artikel liefert die vollständige Checkliste, konkrete Beispiele und eine TOM-Matrix als Vorlage — plus die Integration in ISO 27001 und NIS2.

1. Was fordert Art. 32 DSGVO?

Art. 32 verlangt, dass der Verantwortliche geeignete technische und organisatorische Maßnahmen trifft, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Das ist risikobasiert — ein Krankenhaus braucht stärkere Maßnahmen als ein kleiner Online-Shop.

Die Norm nennt vier Schutzziele:

1. Pseudonymisierung und Verschlüsselung
2. Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit
3. Wiederherstellung der Verfügbarkeit bei physischen/technischen Zwischenfällen
4. Regelmäßige Überprüfung und Bewertung der Wirksamkeit

Diese Schutzziele werden in der Praxis in acht Kategorien operationalisiert.

2. Die acht TOM-Kategorien

2.1 Zutrittskontrolle

Was: Verhinderung des physischen Zugangs Unbefugter zu Datenverarbeitungsanlagen.

Beispiele:

• Zutrittskontrolle zum Gebäude (Chipkarte, Video)
• Besucherregelung mit Dokumentation
• Serverraum mit eigener Zutrittsbeschränkung
• Clean-Desk-Policy

2.2 Zugangskontrolle

Was: Verhinderung der Nutzung von DV-Systemen durch Unbefugte.

Beispiele:

• Starke Passwörter (Password-Policy)
• Mehrfaktor-Authentifizierung (MFA) — Pflicht für administrative Zugänge
• Automatische Sperre nach Inaktivität
• Identity-Provider mit SSO (Okta, Azure AD)

2.3 Zugriffskontrolle

Was: Beschränkung auf die für den Nutzer relevanten Daten (Least Privilege).

Beispiele:

• Rollenbasierte Berechtigungen
• Regelmäßige Access-Reviews (mindestens jährlich)
• Berechtigungsentzug bei Austritten (SLA 24-48h)
• Protokollierung der Zugriffe

2.4 Weitergabekontrolle

Was: Sicherung der Daten bei Übermittlung und Transport.

Beispiele:

• TLS 1.3 für alle Datenübertragungen im Internet
• Verschlüsselte E-Mails für sensible Daten (S/MIME, PGP)
• Sichere Dateitransfers (SFTP, verschlüsselte Links)
• Transport-Richtlinie für Hardware

2.5 Eingabekontrolle

Was: Nachvollziehbarkeit, wer was eingegeben, geändert oder gelöscht hat.

Beispiele:

• Audit-Logs in zentralen Systemen
• Änderungshistorie in Datenbanken
• Unveränderbare Logs (Write-Once)
• Zeitstempel und Nutzerzuordnung

2.6 Auftragskontrolle

Was: Sicherstellung, dass Auftragsverarbeiter nur nach Weisung handeln.

Beispiele:

• AVV nach Art. 28 mit allen Auftragsverarbeitern
• Dokumentation der Weisungslage
• Regelmäßige Dienstleister-Audits
• Abschaltung bei Vertragsende

2.7 Verfügbarkeitskontrolle

Was: Schutz gegen Verlust, Zerstörung, Beschädigung.

Beispiele:

• Redundante Systeme
• Backup-Konzept 3-2-1 (3 Kopien, 2 Medien, 1 offsite)
• Wiederherstellungstests (mindestens halbjährlich)
• USV, Brandschutz, Klimatisierung

2.8 Trennungskontrolle

Was: Trennung der Daten verschiedener Zwecke und Kunden.

Beispiele:

• Mandantenfähige Architekturen
• Getrennte Produktiv- und Testumgebungen
• Logische Trennung durch Zugriffsrechte
• Datenbankschemata pro Zweck

3. Die TOM-Matrix als Vorlage

Die praxistauglichste Darstellung ist eine Tabelle mit vier Spalten:

Diese Matrix muss gepflegt werden — veraltete TOMs sind das häufigste Audit-Finding.

4. Risikoangemessenheit: Wie viel ist genug?

Art. 32 fordert "angemessene" Maßnahmen — keine Maximal-Sicherheit. Faktoren:

• Stand der Technik — MFA ist 2026 Standard, nicht optional
• Implementierungskosten — aber nicht als Ausrede für Untätigkeit
• Art, Umfang, Zweck der Verarbeitung
• Risiko für Rechte und Freiheiten — Gesundheitsdaten = höchster Maßstab
• Eintrittswahrscheinlichkeit und Schwere

Praktisch: Eine Schutzbedarfsfeststellung pro Verarbeitungstätigkeit ist der richtige Startpunkt. Aus ihr leitet sich das TOM-Niveau ab.

5. Integration mit ISO 27001

Die TOM-Kategorien der DSGVO überlappen zu 80-90 Prozent mit ISO 27001 Annex A:

Ein Nachweis erfüllt beide Frameworks. Das ist der zentrale Vorteil einer Multi-Framework-Plattform: TOMs und ISMS-Controls werden einmal gepflegt, mehrfach verwendet.

6. Integration mit NIS2

NIS2 Art. 21 verlangt im Kern dieselben Maßnahmen wie Art. 32 DSGVO:

Ein sauber aufgebautes TOM-System ist der halbe Weg zur NIS2-Umsetzung.

7. TOM-Pflege als Dauerprozess

TOMs sind kein einmaliges Dokument. Pflegepflichten:

• Bei jeder wesentlichen Änderung (neue Systeme, neue Prozesse, Re-Organisation)
• Bei jedem Sicherheitsvorfall (Lernen aus Ereignissen)
• Mindestens jährlich — Review und Aktualisierung
• Bei AVV-Abschluss — passend zur jeweiligen Verarbeitung

Matproof pflegt TOMs zentral: ein Master-Katalog, aus dem AVV-Anlagen automatisch generiert werden. Bei Änderungen (z.B. MFA-Rollout abgeschlossen) wird der Eintrag aktualisiert — und alle 30 bestehenden AVVs beziehen automatisch die neue Version.

8. Häufige Fehler

1. TOMs aus der AVV-Vorlage kopiert ohne Abgleich mit der Realität
2. Keine Pflege — TOMs von 2019 in 2026er Audits
3. Zu allgemein — "hohe Sicherheit" reicht nicht, es muss konkret sein
4. Zu technisch — nur IT-Maßnahmen, keine organisatorischen
5. Keine Verantwortlichkeiten — wer ist für welche TOM zuständig

Fazit

TOMs sind das operative Rückgrat des Datenschutzes. Ein lückenhaftes TOM-System führt zu DSGVO-Bußgeldern, scheiternder ISO-27001-Zertifizierung und NIS2-Findings gleichzeitig. Umgekehrt: Ein sauberes TOM-System ist die Basis für alle drei Compliance-Bereiche.

Moderne ISMS-/GRC-Tools machen die TOM-Pflege zum Nebenprodukt der normalen IT-Arbeit statt zum Compliance-Overhead. Das ist der eigentliche ROI.

Weiterführend:

• AVV DSGVO Muster
• ChatGPT Datenschutz
• NIS2-Umsetzung
• Compliance Management Software