TOMs nach Art. 32 DSGVO

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:

1. Pseudonymisierung und Verschlüsselung personenbezogener Daten;
2. die Fähigkeit, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste dauerhaft sicherzustellen;
3. die Fähigkeit, Verfügbarkeit und Zugang nach einem physischen oder technischen Zwischenfall rasch wiederherzustellen;
4. 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:

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:

• DSGVO, insbesondere Art. 24, Art. 28 und Art. 32 (EUR-Lex)
• Standard-Datenschutzmodell, Version 3.1 (DSK)
• IT-Grundschutz-Kompendium (BSI)