Technische und organisatorische Maßnahmen (TOMs) sind kein fester DSGVO-Standardkatalog. Verantwortliche und Auftragsverarbeiter müssen Maßnahmen wählen, die dem konkreten Risiko angemessen sind. Art. 32 verlangt dabei, Stand der Technik, Implementierungskosten sowie Art, Umfang, Umstände und Zwecke der Verarbeitung und Eintrittswahrscheinlichkeit und Schwere möglicher Schäden zu berücksichtigen. Entscheidend sind deshalb nachvollziehbare Auswahl, tatsächliche Umsetzung und regelmäßige Wirksamkeitsprüfung.
Kerntatsachen
- Risikobasiert statt pauschal: Dieselbe Maßnahme kann für einen Prozess angemessen und für einen anderen unzureichend sein.
- Art. 32 nennt Beispiele: Pseudonymisierung und Verschlüsselung, dauerhafte Sicherheit und Belastbarkeit, Wiederherstellung sowie regelmäßige Tests – nicht eine abschließende Checkliste.
- Verantwortliche und Auftragsverarbeiter haben jeweils eigene Pflichten.
- Dokumentation braucht Bezug: Risiko, Maßnahme, Geltungsbereich, Verantwortliche, Umsetzungsstatus und Nachweis gehören zusammen.
- AVV-Anlagen müssen konkret sein: Allgemeine Schlagwörter belegen weder Umsetzung noch Angemessenheit.
- Prüfen und verbessern: Änderungen an Systemen, Bedrohungen oder Verarbeitung können eine Neubewertung auslösen.
Was sind TOMs nach Art. 32 DSGVO?
TOMs sind technische und organisatorische Vorkehrungen zum Schutz personenbezogener Daten. „Technisch“ und „organisatorisch“ sind keine getrennten Welten: Eine starke Zugriffskontrolle benötigt sowohl technische Durchsetzung als auch geregelte Rollen, Freigaben und Rezertifizierung.
Art. 32 Abs. 1 nennt – soweit dem Risiko angemessen – insbesondere:
- Pseudonymisierung und Verschlüsselung personenbezogener Daten;
- die Fähigkeit, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste dauerhaft sicherzustellen;
- die Fähigkeit, Verfügbarkeit und Zugang nach einem physischen oder technischen Zwischenfall rasch wiederherzustellen;
- ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen.
Die Risikoorientierung ist wichtig: Verschlüsselung wird ausdrücklich genannt, ist aber nicht in identischer Form für jede Verarbeitung vorgeschrieben. Umgekehrt darf eine Organisation eine geeignete Maßnahme nicht allein deshalb weglassen, weil sie nicht wörtlich im Artikel steht.
Wie wird das angemessene Schutzniveau bestimmt?
1. Verarbeitung abgrenzen
Beschreiben Sie Zweck, betroffene Personen, Datenkategorien, Systeme, Schnittstellen, Empfänger, Standorte, Auftragsverarbeiter und Speicherfristen. Ohne belastbaren Geltungsbereich ist eine TOM-Liste nicht prüfbar.
2. Risiken für Personen identifizieren
Art. 32 Abs. 2 hebt Risiken hervor, die insbesondere aus Vernichtung, Verlust, Veränderung oder unbefugter Offenlegung beziehungsweise unbefugtem Zugang entstehen können. Bewerten Sie nicht nur Schäden für das Unternehmen, sondern mögliche Folgen für betroffene Personen, etwa Identitätsmissbrauch, Diskriminierung, finanzielle Nachteile, Offenlegung vertraulicher Lebensumstände oder Verlust der Kontrolle über Daten.
3. Eintrittswahrscheinlichkeit und Schwere bewerten
Berücksichtigen Sie Bedrohungen, Schwachstellen, vorhandene Kontrollen und die möglichen Folgen. Eine einfache Farbstufe kann genügen, wenn Kriterien, Annahmen und Entscheidung nachvollziehbar sind.
4. Maßnahmen auswählen
Ordnen Sie jedem relevanten Risiko eine oder mehrere vorbeugende, erkennende, begrenzende oder wiederherstellende Maßnahmen zu. Begründen Sie auch, wenn eine naheliegende Maßnahme nicht geeignet oder unverhältnismäßig ist und welche Alternative das Risiko adressiert.
5. Restrisiko entscheiden
Dokumentieren Sie, wer das verbleibende Risiko auf welcher Grundlage akzeptiert oder weitere Maßnahmen anordnet. Der DSB kann beraten und überwachen; die Entscheidung bleibt beim Verantwortlichen beziehungsweise Auftragsverarbeiter.
Maßnahmenfelder mit Praxisbeispielen
Die folgenden Beispiele sind Ausgangspunkte. Sie werden erst durch Bezug auf System, Risiko und Konfiguration zu belastbaren TOMs.
Identitäten und Berechtigungen
- eindeutige Benutzerkonten und geregelter Joiner-Mover-Leaver-Prozess
- Mehrfaktor-Authentisierung für risikoreiche oder privilegierte Zugriffe
- Rollen- und Berechtigungskonzepte nach Erforderlichkeit
- regelmäßige Prüfung und Entzug nicht mehr benötigter Rechte
- getrennte Administrationskonten und kontrollierter Notfallzugang
Schutz von Übertragung und Speicherung
- geeignete Transport- und Speicherverschlüsselung
- dokumentiertes Schlüsselmanagement mit getrennten Berechtigungen
- sichere Übermittlungswege und Empfängerprüfung
- Pseudonymisierung, wenn Zweck und Reidentifikationsrisiko dies zulassen
- Datenminimierung und Löschung nicht mehr benötigter Daten
Eine Produkt- oder Algorithmusbezeichnung allein ist kein Nachweis. Relevant sind Konfiguration, Schlüssel, Endpunkte, Ausnahmen und Betrieb.
Verfügbarkeit und Wiederherstellung
- risikogerechte Sicherungskopien und getrennte Schutzbereiche
- definierte Wiederanlaufziele und Verantwortlichkeiten
- getestete Wiederherstellung von Daten und Diensten
- Redundanz, Kapazitäts- und Ausfallplanung
- Schutz der Backups gegen Veränderung und unbefugten Zugriff
Ein erfolgreicher Backup-Job beweist noch nicht, dass eine Wiederherstellung im benötigten Umfang funktioniert.
Protokollierung, Erkennung und Reaktion
- sicherheitsrelevante Protokolle mit festgelegtem Zweck und Zugriff
- Alarmierung für auffällige oder unbefugte Aktivitäten
- Verfahren für Triage, Eindämmung, Beweissicherung und Wiederherstellung
- Verbindung zum Prozess für Datenschutzverletzungen nach Art. 33 und 34
- dokumentierte Übungen und Auswertung realer Vorfälle
Auch Protokolldaten können personenbezogen sein. Umfang, Speicherdauer und Zugriffe müssen daher selbst datenschutzgerecht gestaltet werden.
Sichere Entwicklung und Änderungen
- Datenschutz- und Sicherheitsanforderungen vor Beschaffung oder Entwicklung
- getrennte Entwicklungs-, Test- und Produktivumgebungen
- Prüfung von Änderungen, Abhängigkeiten und Schwachstellen
- Freigabe- und Rückfallverfahren
- keine unkontrollierte Verwendung echter Produktivdaten in Tests
Organisation und Personal
- klare Rollen, Freigaben und Eskalationswege
- Vertraulichkeitsverpflichtung und zielgruppengerechte Sensibilisierung
- geregelter Umgang mit mobilen Geräten, Papier und Homeoffice
- physischer Zutrittsschutz nach Schutzbedarf
- dokumentierte Ausnahme- und Risikofreigaben
Lieferanten und Auftragsverarbeiter
- Sicherheitsanforderungen vor Auswahl und Vertrag
- Prüfung ausreichender Garantien nach Art. 28
- konkrete TOM-Anlage und geregelte Änderungen
- Nachweise und risikogerechte Kontrollrechte
- Steuerung von Unterauftragsverarbeitern und Datenstandorten
- Exit, Rückgabe und Löschung nach Leistungsende
Art. 32 und das Standard-Datenschutzmodell
Das Standard-Datenschutzmodell (SDM) der Datenschutzkonferenz ist eine behördliche Methode, um rechtliche Anforderungen systematisch in Maßnahmen zu überführen. Version 3.1 arbeitet mit den Gewährleistungszielen Datenminimierung, Verfügbarkeit, Integrität, Vertraulichkeit, Nichtverkettung, Transparenz und Intervenierbarkeit.
Diese Gewährleistungsziele sind nicht identisch mit einer angeblichen Liste von „acht Schutzzielen des Art. 32“. Art. 32 nennt seinen eigenen Sicherheitsmaßstab; das SDM betrachtet Datenschutzanforderungen breiter und kann bei Modellierung, Risikoanalyse und Nachweisführung helfen.
Auch BSI IT-Grundschutz kann technische und organisatorische Anforderungen strukturieren. Eine Umsetzung oder Zertifizierung nach einem Sicherheitsstandard ersetzt jedoch nicht die datenschutzbezogene Risikobewertung für konkrete Verarbeitungstätigkeiten.
TOM-Dokumentation, die einer Prüfung standhält
Eine verwendbare Maßnahmendokumentation beantwortet:
| Feld | Inhalt |
|---|---|
| Verarbeitung/System | Wo gilt die Maßnahme? |
| Risiko/Anforderung | Welches Risiko oder welche Pflicht adressiert sie? |
| Maßnahme | Was ist konkret eingerichtet und wie konfiguriert? |
| Verantwortung | Wer betreibt und wer kontrolliert sie? |
| Status | geplant, teilweise oder wirksam umgesetzt |
| Nachweis | Richtlinie, Konfiguration, Protokoll, Test- oder Auditbericht |
| Prüfauslöser | Termin, Systemänderung, Vorfall oder neue Bedrohung |
| Ergebnis | Feststellung, Restrisiko und Folgemaßnahme |
Vermeiden Sie öffentlich oder vertraglich unnötig detaillierte Sicherheitsinformationen. Der Nachweis muss konkret genug sein, ohne Angriffswege oder Geheimnisse offenzulegen.
TOMs im Auftragsverarbeitungsvertrag
Art. 28 Abs. 3 lit. c verpflichtet den Auftragsverarbeiter, alle nach Art. 32 erforderlichen Maßnahmen zu ergreifen. Der Vertrag muss mehr leisten als „angemessene TOMs gemäß DSGVO“:
- Geltungsbereich und relevante Dienste benennen
- wesentliche Maßnahmen verständlich beschreiben
- Verantwortlichkeiten an Schnittstellen klären
- Änderungen und gegebenenfalls Widerspruch oder Neubewertung regeln
- Nachweise, Audits und Unterstützung bei Vorfällen ermöglichen
Der Verantwortliche muss vor und während der Verarbeitung prüfen, ob der Auftragsverarbeiter ausreichende Garantien bietet. Eine Zertifizierung kann ein Nachweiselement sein, hebt die Prüf- und Steuerungspflicht aber nicht auf.
Wirksamkeit prüfen
Art. 32 schreibt keine pauschale Jahres-, Quartals- oder Monatsfrequenz für alle Tests vor. Legen Sie Häufigkeit und Methode risikobasiert fest. Mögliche Nachweise sind:
- technische Konfigurations- und Berechtigungsprüfungen
- Wiederherstellungstests
- Schwachstellenanalysen und geeignete Sicherheitstests
- interne oder externe Audits
- Übungen für Vorfall- und Krisenprozesse
- Auswertung von Kennzahlen, Ausnahmen und realen Ereignissen
Ein Test ist erst abgeschlossen, wenn Befunde priorisiert, Verantwortliche und Fristen festgelegt und die Behebung nachverfolgt wurden.
Häufige Fehler
- Pauschalkatalog ohne Verarbeitungskontext
- Verwechslung von Soll und Ist: geplante Maßnahmen werden als umgesetzt dargestellt
- Produktname statt Schutzwirkung und Konfiguration
- Unternehmensrisiko statt Risiko für betroffene Personen
- Backup ohne nachgewiesene Wiederherstellung
- Unklare Verantwortlichkeit zwischen Kunde und Dienstleister
- Keine Neubewertung nach wesentlichen Änderungen oder Vorfällen
- Starre Prüffrequenz ohne Bezug zu Risiko und Änderungsgeschwindigkeit
- Zertifikat als vermeintlicher Vollbeweis der DSGVO-Konformität
FAQ
Welche TOMs schreibt die DSGVO zwingend vor?
Sie schreibt ein dem Risiko angemessenes Schutzniveau vor und nennt in Art. 32 Abs. 1 mögliche Elemente. Welche konkrete Maßnahme erforderlich ist, folgt aus der dokumentierten Einzelfallbewertung.
Ist Verschlüsselung immer Pflicht?
Sie ist ausdrücklich als mögliche Maßnahme genannt und bei vielen Risiken zentral. Form und Umfang hängen aber von Verarbeitung, Bedrohung, Alternativen und Restrisiko ab. Ein Weglassen benötigt eine tragfähige Bewertung.
Wie oft müssen TOMs geprüft werden?
Regelmäßig und zusätzlich bei relevanten Änderungen. Die konkrete Frequenz ist risikobasiert zu begründen; Art. 32 nennt keinen einheitlichen Jahresrhythmus.
Reicht eine ISO-27001-Zertifizierung?
Nein. Sie kann ein wichtiger Nachweis für ein Informationssicherheitsmanagement sein. Die Angemessenheit der TOMs für die konkrete personenbezogene Verarbeitung und die DSGVO-Pflichten ist zusätzlich zu prüfen.
Müssen alle TOMs vollständig im AVV stehen?
Der Vertrag beziehungsweise seine Anlage muss die für die Auftragsverarbeitung relevanten Maßnahmen hinreichend konkret abbilden. Sicherheitskritische Details können kontrolliert in ergänzenden Nachweisen bereitgestellt werden; bloße Oberbegriffe reichen nicht.
Passende Unterstützung
Wir verbinden die risikobasierte TOM-Prüfung mit VVT, DSFA und Auftragsverarbeitung in unserer Datenschutz-Beratung. Für technische Vertiefung und belastbare Nachweise kann die Cyber-Security-Beratung ergänzen.
Quellen und Prüfung
Rechtsstand und Aussagen wurden am 8. August 2026 anhand dieser Primär- und Behördenquellen geprüft:
Robert Lozo, mag. iur., ist Partner bei Vision Compliance mit Schwerpunkt EU-Regulierung. Er berät Organisationen zu DSGVO, NIS2, EU AI Act und Finanzregulierung und liefert auditfähige Dokumentation und Compliance-Fahrpläne für regulierte Branchen.