Art. 32 DSGVO: technische und organisatorische Maßnahmen, die einer Prüfung standhalten

Art. 32 DSGVO ist der einzige Artikel der Verordnung, der Ergebnisse verlangt statt Papier, und der einzige, den fast jedes Unternehmen mit einer Checkliste beantwortet. Der Text enthält keine Produktliste. Er enthält vier Beispiele, einen Risikotest und die Pflicht, regelmäßig zu prüfen, ob irgendetwas davon noch wirkt. Genau daran scheitert die übliche Dokumentation: zwölf Punkte, seit 2018 unverändert kopiert, ohne Systemnamen, ohne Datum, ohne Messergebnis. Geprüft wird aber nicht, ob Sie eine Maßnahme behaupten, sondern ob Sie sie belegen können — und der Europäische Gerichtshof hat 2023 entschieden, dass diese Beweislast bei Ihnen liegt. Dieser Leitfaden beschreibt das Entscheidungsverfahren, das Art. 32 tatsächlich fordert, die Nachweise, die ein Prüfer anfordert und die Sie heute wahrscheinlich nicht vorlegen können, die Teile der Verschlüsselung, an denen Auditoren zuerst ziehen, die Arithmetik hinter Ihrer Log-Aufbewahrung und die Fristen, die seit dem 6. Dezember 2025 in Deutschland zusätzlich gelten.

Was in Art. 32 DSGVO tatsächlich steht, bevor es jemand paraphrasiert

Absatz 1 verpflichtet Verantwortlichen und Auftragsverarbeiter, geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Zu berücksichtigen sind dabei vier Faktoren: der Stand der Technik, die Implementierungskosten, die Art, der Umfang, die Umstände und die Zwecke der Verarbeitung sowie die unterschiedliche Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen. Der Text nennt dann — ausdrücklich „unter anderem“ — vier Maßnahmen:

• lit. a die Pseudonymisierung und Verschlüsselung personenbezogener Daten;
• lit. b die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen;
• lit. c die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen;
• lit. d ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen.

Vier Wörter in diesem Absatz tragen die gesamte Pflicht. Unter anderem heißt: Die Liste ist nicht abschließend, „wir haben alle vier Punkte erfüllt“ ist keine Verteidigung. Geeignete heißt: Jede Maßnahme wird an der Risikobeurteilung gemessen, nicht am Katalog. Auf Dauer in lit. b schließt ein Projekt mit Enddatum aus. Und regelmäßig in lit. d schließt den einen Penetrationstest aus, der 2023 für einen Kundenfragebogen bestellt wurde.

Absatz 2 benennt die Bedrohungen, die die Beurteilung abdecken muss: Vernichtung, Verlust, Veränderung, unbefugte Offenlegung von und unbefugten Zugang zu personenbezogenen Daten, die übermittelt, gespeichert oder auf andere Weise verarbeitet werden — unbeabsichtigt oder unrechtmäßig. Auffällig ist, was dort fehlt: kein Wort über Angreifer. Ein falsch konfigurierter Backup-Job, der eine Tabelle überschreibt, fällt genauso darunter wie ein Ransomware-Vorfall. Wer seine TOM ausschließlich gegen Angreifer dimensioniert, deckt die Hälfte des Absatzes nicht ab.

Absatz 3 stellt klar, dass die Einhaltung genehmigter Verhaltensregeln nach Art. 40 oder eines Zertifizierungsverfahrens nach Art. 42 als Nachweiselement dienen kann — als Element, nicht als Ersatz. Ein ISO-27001-Zertifikat belegt, dass Sie ein Managementsystem betreiben. Es belegt nicht, dass eine bestimmte Maßnahme für eine bestimmte Verarbeitung angemessen ist, und es sagt nichts über die Wirksamkeit am Tag der Prüfung. Absatz 4 bindet jede Person, die im Auftrag Zugang zu personenbezogenen Daten hat, an die Weisung des Verantwortlichen. Das ist der Absatz, an dem interne Zugriffe scheitern: Ein Administrator, der aus Neugier in Kundendaten sieht, ist ein Art.-32-Fall, kein Personalthema.

Der Zweischritt, den der Europäische Gerichtshof verbindlich gemacht hat

Das Urteil vom 14. Dezember 2023 in der Rechtssache C-340/21 (Hackerangriff auf die bulgarische Steuerverwaltung) ist der wichtigste europäische Anker für die Auslegung von Art. 32, weil es vier Punkte klarstellt, die in fast keiner TOM-Dokumentation auftauchen. Erstens: Ein erfolgreicher Angriff belegt für sich genommen nicht, dass die getroffenen Maßnahmen ungeeignet waren. Das klingt nach Entlastung, ist aber keine — denn zweitens muss die Geeignetheit konkret geprüft werden, und zwar in zwei Schritten. Zuerst sind die von der Verarbeitung ausgehenden Risiken einer Verletzung und ihre möglichen Folgen für die Rechte und Freiheiten zu ermitteln, mit Eintrittswahrscheinlichkeit und Schwere. Danach ist zu prüfen, ob Art, Inhalt und Umsetzung der Maßnahmen diesen Risiken unter Berücksichtigung von Stand der Technik, Implementierungskosten sowie Art, Umfang, Umständen und Zwecken der Verarbeitung angemessen sind.

Drittens trägt der Verantwortliche im Schadensersatzprozess nach Art. 82 die Beweislast dafür, dass seine Sicherheitsmaßnahmen geeignet waren. Wer nach einem Vorfall nicht erklären kann, welches Risiko erkannt und welche Maßnahme dagegen mit welchem Ergebnis ergriffen wurde, verliert diesen Punkt nicht wegen des Angriffs, sondern wegen fehlender Dokumentation. Viertens kann ein gerichtliches Sachverständigengutachten weder als generell notwendiges noch als generell ausreichendes Beweismittel gelten. Ein teures Gutachten ersetzt also keine Betriebsaufzeichnung, und ein fehlendes Gutachten entlastet niemanden.

Für die Praxis heißt das: Ihre Unterlagen müssen den Zweischritt sichtbar enthalten, und zwar für jede Verarbeitungstätigkeit, nicht für das Unternehmen als Ganzes. Die Aufsichtsbehörde liest Ihre Dokumentation wie ein Gericht. Sie sucht nicht die Maßnahmenliste, sondern die Begründung, warum diese Maßnahme für dieses Risiko ausreicht, und den Beleg, dass sie zum Prüfzeitpunkt tatsächlich in Betrieb war.

Risiko zuerst: die Skala, mit der Sie arbeiten müssen

Der häufigste Strukturfehler ist eine Risikobeurteilung pro Unternehmen statt pro Verarbeitungstätigkeit. „Unser Risiko ist mittel“ ist keine Aussage, die man prüfen kann, und sie führt zwangsläufig zu Maßnahmen, die für die eine Verarbeitung zu schwach und für die andere unnötig teuer sind. Was ein Prüfer sehen will, ist eine Zuordnung: diese Verarbeitung, diese Datenkategorie, diese Betroffenengruppe, diese Eintrittswahrscheinlichkeit, diese Schadensschwere, daraus diese Risikoklasse — und an der Risikoklasse hängt ein Mindestmaßnahmenpaket, das Sie vorher festgelegt haben.

Eine Matrix mit drei Stufen pro Achse reicht dafür aus, wenn die Achsen definiert sind. Die Eintrittswahrscheinlichkeit lässt sich an drei Fragen festmachen: Ist der Dienst aus dem Internet erreichbar? Verarbeitet er Daten, die auf einem Markt gehandelt werden, also Zugangsdaten, Kartendaten oder Gesundheitsdaten? Hat es in den letzten 24 Monaten bereits einen Vorfall, einen kritischen Schwachstellenbefund oder eine behördliche Nachfrage gegeben? Die Schadensschwere hat mehr Dimensionen als Geld: Zahl der betroffenen Personen, Dauer der möglichen Beeinträchtigung, Unumkehrbarkeit (ein zurückgesetztes Passwort ist umkehrbar, eine veröffentlichte Diagnose nicht), Diskriminierungspotenzial und die Frage, ob besondere Kategorien nach Art. 9 oder Daten nach Art. 10 betroffen sind.

Der Nutzen dieser Übung liegt nicht in der Matrix, sondern in der Zuordnung, die daraus entsteht. Ein Bewerbermanagement mit Kontaktdaten und Lebensläufen landet regelmäßig bei mittel, ein Pflegeheim-Informationssystem mit Diagnosedaten bei hoch, eine Marketingliste mit E-Mail-Adressen bei niedrig. An hoch hängen dann Mindestmaßnahmen, die sich nicht mehr wegdiskutieren lassen: Verschlüsselung mit getrennter Schlüsselverwaltung, Mehrfaktor-Authentifizierung für alle Zugänge, vierteljährliche Berechtigungsprüfung, dokumentierter Restore-Test mit RTO, Weiterleitung der Protokolle an einen Speicher außerhalb des Systems. Genau das ist der Zweck. Ohne diese Vorabfestlegung diskutiert man nach einem Vorfall darüber, ob eine Maßnahme angemessen gewesen wäre, und verliert die Diskussion, weil es keinen Maßstab gibt.

„Stand der Technik“ ist kein Gefühl, sondern ein Nachweis

Der Begriff ist in der Verordnung nicht definiert, und die Aufsichtsbehörden füllen ihn über die Normen. Das BfDI verweist auf die Definition des Handbuchs der Rechtsförmlichkeit: der Entwicklungsstand fortschrittlicher Verfahren, Einrichtungen und Betriebsweisen, der nach herrschender Auffassung führender Fachleute das Erreichen des gesetzlich vorgegebenen Zieles gesichert erscheinen lässt. Der Stand der Technik liegt damit zwischen den allgemein anerkannten Regeln der Technik und dem Stand von Wissenschaft und Technik — nicht das Minimum, das alle machen, aber auch nicht das Laborverfahren von übermorgen.

Praktisch heißt das: Sie müssen benennen können, welche Norm oder welches Regelwerk Sie angewendet haben, und warum eine Abweichung gerechtfertigt war. Die üblichen Bezugspunkte im deutschen Markt sind ISO/IEC 27001:2022 mit den Maßnahmen in Anhang A (unter anderem A 8.24 Kryptografie, A 8.15 Protokollierung, A 8.13 Sicherung von Informationen, A 5.24 bis A 5.28 Vorfallsmanagement), das BSI IT-Grundschutz-Kompendium mit seinen Bausteinen und die Technischen Richtlinien des BSI dort, wo sie einschlägig sind. Ein Satz wie „wir orientieren uns am Stand der Technik“ ist keine Aussage. Ein Satz wie „für die Verarbeitung X gilt Anhang A 8.24, umgesetzt durch AES-256 mit Schlüsseln in einem separaten KMS, Rotation alle zwölf Monate, Nachweis vom 12. September 2026“ ist eine.

Der Stand der Technik ist außerdem keine Einbahnstraße nach oben. Das Oberverwaltungsgericht Nordrhein-Westfalen hat mit Beschluss vom 20. Februar 2025 (16 B 288/23) entschieden, dass Betroffene keinen Anspruch auf eine bestimmte Verschlüsselungstechnik haben: Eine BSI-zertifizierte TLS-Verschlüsselung wurde als dem Risiko angemessen und dem Stand der Technik entsprechend bewertet, weil der Antragsteller kein besonderes Risiko dargelegt hatte, das eine Ende-zu-Ende-Verschlüsselung zwingend erforderlich gemacht hätte. Wer mit Augenmaß dimensioniert und die Abweichung begründet, ist also nicht schlechter dran als der, der maximal aufrüstet und es nicht erklären kann. Die Begründung ist der Unterschied.

Pseudonymisierung und Verschlüsselung: wo Prüfer zuerst ziehen

Art. 32 Abs. 1 lit. a nennt Pseudonymisierung und Verschlüsselung in einem Atemzug, und in fast jeder Dokumentation steht dazu ein Satz, der mit „Daten werden verschlüsselt übertragen und gespeichert“ beginnt und dort endet. Die Frage, an der eine Prüfung hängt, ist eine andere: Wo liegt der Schlüssel im Verhältnis zum Chiffrat? Liegt er im selben Account, im selben Backup-Set oder im selben Repository, dann liefert eine einzige Kompromittierung beides, und die Verschlüsselung schützt nur noch gegen den physischen Verlust eines Datenträgers — also gegen den unwahrscheinlichsten Fall.

Was ein Prüfer deshalb sehen will, sind zwei Artefakte. Erstens ein Kryptokonzept: welche Datenklasse mit welchem Verfahren geschützt wird, auf welchem Weg (Transport, Speicher, einzelnes Feld), mit welcher Schlüssellänge, wo die Schlüssel liegen, wer Zugriff hat, wie rotiert wird und was bei Schlüsselverlust passiert. Zweitens ein Schlüsselinventar: pro System der Schlüsseltyp, der Aufbewahrungsort, der Verantwortliche, das Rotationsdatum und das Datum der letzten Prüfung der Zugriffsrechte auf den Schlüsselspeicher. Ohne diese beiden Listen ist verschlüsselt eine Behauptung über eine Konfiguration, die niemand nachvollziehen kann.

Drei Details entscheiden in der Praxis. Erstens die Trennung von Chiffrat und Schlüssel über Kontogrenzen hinweg, mit eigenen Rollen für Schlüsselverwaltung und Datenzugriff — wer die Datenbank administriert, darf den Schlüssel nicht exportieren können. Zweitens die Feldverschlüsselung für die Kennungen, die einen Datensatz personenbezogen machen: nationale Identifikationsnummer, Kartentoken, Gesundheitsmerkmal, Kontonummer. Eine vollständig verschlüsselte Datenbank ist nach einer Anwendungslücke im Klartext lesbar, weil die Anwendung den Schlüssel hat; ein separat verschlüsseltes Feld bleibt auch dann unlesbar, wenn eine Abfrage fremde Zeilen zurückgibt. Drittens die Frage, was ein Backup schützt: Ein verschlüsseltes Backup, dessen Schlüssel im selben Bandkatalog oder Objektspeicher liegt, ist kein verschlüsseltes Backup. Ergänzend gehört zur Wahrheit, dass Pseudonymisierung die Daten nicht aus dem Anwendungsbereich der Verordnung nimmt — der Bezug zur Person existiert weiter und ist wiederherstellbar, weshalb Art. 32 sie als Schutzmaßnahme nennt und nicht als Anonymisierung.

Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit: „auf Dauer“ schließt das Projekt aus

lit. b verlangt die Fähigkeit, diese vier Eigenschaften dauerhaft sicherzustellen. Das ist die Stelle, an der Dokumentationen regelmäßig zu einer Projektliste werden, obwohl der Artikel einen Betriebszustand meint. Der Unterschied zeigt sich in den Nachweisen: Ein Projektnachweis ist die Einführungsurkunde eines Systems, ein Betriebsnachweis ist die letzte vierteljährliche Berechtigungsprüfung mit Datum, Prüfer, Stichprobe und entfernten Konten.

Für die Vertraulichkeit sind vier Nachweise üblich, und keiner davon ist eine Richtlinie: die Berechtigungsprüfung mit benannter Stichprobe und Ergebnis, die Liste der Konten mit erhöhten Rechten samt Begründung, der Nachweis der Mehrfaktor-Authentifizierung für alle administrativen und alle von außen erreichbaren Zugänge — als Export, nicht als Screenshot eines Telefons — und ein Protokoll für Eintritte, Wechsel und Austritte, aus dem hervorgeht, wie lange ein ausgeschiedener Mitarbeiter nach dem letzten Arbeitstag noch Zugriff hatte. Für die Integrität zählen Aufzeichnungen des Änderungsmanagements, Prüfsummen oder Signaturen für ausgelieferte Artefakte, Schreibschutz und Vier-Augen-Prinzip für Produktionsdatenbanken. Für die Verfügbarkeit zählen gemessene statt zugesagter Verfügbarkeit, die Redundanz der kritischen Pfade und ein Patch-Prozess mit einer Zahl: mediane Zeit von der Veröffentlichung eines kritischen Updates bis zur Behebung, quartalsweise gemessen. „Wir patchen zeitnah“ ist keine Zahl.

Belastbarkeit ist der Teil, den fast alle auslassen, weil er sich nicht als Haken abbilden lässt. Gemeint ist die Fähigkeit, unter Last und unter Teilausfall weiterzuarbeiten: Was passiert, wenn ein Rechenzentrum wegfällt, wenn ein einzelner Dienst in einer Schleife läuft, wenn ein Angriff mit Last auf die Anmeldung kommt? Ein dokumentierter Lasttest, ein Failover-Test mit Datum und ein Notfallhandbuch, das jemand nachweislich einmal durchgearbeitet hat, sind hier mehr wert als jede weitere Richtlinie.

Wiederherstellung: der Test, den fast niemand vorlegt

lit. c verlangt die Fähigkeit, Verfügbarkeit und Zugang bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen. Rasch wird erst zu einer Anforderung, wenn Sie für jede Systemklasse zwei Zahlen festgelegt haben: RTO (wie lange darf die Wiederherstellung dauern) und RPO (wie viel Datenverlust ist akzeptabel). Danach wird gemessen, nicht geschätzt.

Das Artefakt, das eine Prüfung übersteht, ist ein datiertes Wiederherstellungsprotokoll mit sechs Angaben: System, Datenstand (Datum der Sicherung), Start- und Endzeit der Wiederherstellung, tatsächliche Dauer, Ergebnis einschließlich Prüfung der Datenintegrität und Name der Person, die es durchgeführt hat. Ein grüner Backup-Job ist kein Nachweis; er belegt, dass Daten kopiert wurden, nicht dass sie zurückkommen. Der klassische Befund lautet: letzter erfolgreicher Restore-Test 2022, oder ein Restore, der nie versucht wurde, weil die Sicherung ja läuft.

Drei Regeln gehören in die Dokumentation, weil sie den Unterschied zwischen einem Vorfall und einem Ausfall machen. Erstens die 3-2-1-1-0-Regel: drei Kopien, zwei Medien, eine ausgelagert, eine unveränderlich oder offline, null Fehler bei der Verifikation. Zweitens die Trennung der Anmeldedaten: Die Zugangsdaten für das Backup-System dürfen nicht an derselben Domäne hängen wie die Produktion, sonst ist der Ransomware-Fall der Fall, in dem beides gleichzeitig verschwindet. Drittens die Frequenz: einmal im Quartal für Systeme mit hoher Risikoklasse, mindestens einmal im Jahr für alle anderen — und nach jeder wesentlichen Änderung an der Infrastruktur erneut, weil ein Restore-Test von vor drei Monaten eine andere Umgebung geprüft hat.

Regelmäßige Überprüfung: fünf Testarten und was jede beweist

lit. d ist die einzige Stelle im Artikel, die eine Tätigkeit statt einer Eigenschaft verlangt, und sie ist die, die am häufigsten mit einem Zertifikat verwechselt wird. Fünf Testarten sind üblich, und jede beantwortet eine andere Frage. Ein Penetrationstest beantwortet: Lässt sich in einem definierten Umfang in einem definierten Zeitfenster eine Ausnutzung nachweisen? Er ist eine Momentaufnahme und veraltet mit dem nächsten Deployment. Ein Schwachstellenscan beantwortet: Welcher Anteil unseres Inventars wurde geprüft, und welche offenen Befunde gibt es pro System? Der Wert liegt in der Abdeckung, nicht in der Befundzahl. Eine Kontrollprüfung, also ein Konfigurations- und Stichprobenaudit, beantwortet: Existieren die Maßnahmen, und werden sie durchgesetzt? Eine Stichprobe von 25 Konten auf Mehrfaktor-Authentifizierung ist ein stärkerer Nachweis als ein Richtliniendokument. Ein Red-Team- oder Assumed-Breach-Test beantwortet: Erkennen und reagieren wir, wenn die Prävention versagt? Er prüft Detektion und Reaktion, nicht die Mauer. Und eine Tabletop-Übung beantwortet: Weiß die Organisation, wer im Ernstfall entscheidet, und wie lange dauert es bis zur Meldung?

Die Prüffrequenz gehört an die Risikoklasse, nicht an den Kalender eines Dienstleisters: hohe Klasse mindestens jährlich mit externem Test und Retest der kritischen Befunde, mittlere Klasse alle zwei Jahre, niedrige Klasse eine Kontrollprüfung im Jahr. Der Nachweis, der zählt, ist der Retest: ein Befund, der im gleichen Aufbau erneut getestet und als behoben bestätigt wurde, mit Datum. Ein Bericht ohne Retest dokumentiert ein Problem, nicht eine Maßnahme.

Das Nachweisartefakt: sechs Felder, die aus einer Behauptung einen Beweis machen

Der praktische Test für Ihre gesamte TOM-Dokumentation ist einfach. Jeder Punkt muss sich auf eines von vier Dingen auflösen lassen: einen Konfigurationsexport, ein Protokoll, einen Bericht oder ein Ticket mit Ergebnis. Lässt er sich nicht auflösen, ist er eine Behauptung, und Behauptungen verlieren im Zweifel. Ein brauchbares Artefakt trägt sechs Felder: System oder Verarbeitung, Datum, verantwortliche Person, Umfang (welche Konten, welche Daten, welche Systeme), Ergebnis in Zahlen und den Nachweis der Behebung.

Zwei Dinge fehlen in fast allen Dokumentationen und entscheiden im Nachhinein. Erstens die Gültigkeitsdauer: Führen Sie jede Fassung der TOM-Dokumentation mit „gültig von“ und „gültig bis“. Nach einem Vorfall wird bewertet, welche Maßnahmen zum Zeitpunkt der Verarbeitung galten — nicht die Fassung, die Sie drei Wochen später verbessert haben. Wer nur die aktuelle Version aufbewahrt, kann im Nachhinein nicht zeigen, was damals in Betrieb war, und das wirkt wie eine nachträgliche Anpassung, auch wenn es keine war. Zweitens die Aufbewahrungsdauer der Nachweise. Die regelmäßige Verjährung nach § 195 BGB beträgt drei Jahre ab dem Schluss des Jahres der Kenntnis, und bei Schadensersatzansprüchen ist der relevante Zeitraum in der Praxis häufig länger; für Nachweise zu Sicherheitsmaßnahmen sind fünf Jahre eine vernünftige Untergrenze, für Systeme mit besonderen Datenkategorien eher zehn. Diese Aufbewahrung ist kein Verstoß gegen die Speicherbegrenzung nach Art. 5 Abs. 1 lit. e: Sicherheitsprotokolle werden zu einem anderen Zweck verarbeitet als die Geschäftsdaten und brauchen eine eigene Rechtsgrundlage und eine eigene Löschfrist, beides dokumentiert.

Die 72-Stunden-Uhr aus Art. 33 und was sie über Ihre Log-Aufbewahrung sagt

Art. 33 beginnt die Frist mit der Kenntnisnahme, nicht mit dem Vorfall — und genau hier wird die Log-Aufbewahrung zu einem Art.-32-Thema. Eine Meldung nach Art. 33 Abs. 3 muss die Art der Verletzung, die Kategorien und die ungefähre Zahl der betroffenen Personen und Datensätze, den Kontakt des Datenschutzbeauftragten, die wahrscheinlichen Folgen und die ergriffenen Maßnahmen enthalten. Jeder dieser Punkte ist eine Abfrage an Ihre Protokolle. Die ungefähre Zahl der betroffenen Datensätze beantwortet man nicht mit einer Schätzung aus dem Kopf, sondern mit einem Zugriffsprotokoll, das den Zeitraum abdeckt, in dem der Zugang bestand.

Daraus folgt eine Rechnung, die selten gemacht wird. Die Aufbewahrung muss Ihre realistische Erkennungszeit übersteigen, nicht den Plattform-Standard. Die Erhebung von IBM beziffert für 2025 die mittlere Zeit bis zur Identifikation einer Kompromittierung mit etwa 172 Tagen und bis zur Eindämmung mit 241 Tagen. Die Standardwerte der großen Plattformen liegen deutlich darunter: Die Ereignishistorie in AWS CloudTrail reicht 90 Tage zurück, das Systemlog von Okta 90 Tage, die Anmeldeprotokolle in Microsoft Entra ID 30 Tage in den Bezahlstufen und 7 Tage in der kostenlosen Variante, das einheitliche Auditlog in Microsoft 365 im Standard 180 Tage. Wer nur auf diese Standards schaut, kann einen Angriff, der vor acht Monaten begann, nicht mehr rekonstruieren — und kann damit auch nicht belegen, dass die Maßnahmen nach lit. d wirksam waren.

Die Lösung ist unspektakulär: Weiterleiten der sicherheitsrelevanten Ereignisse in einen Speicher, den Sie kontrollieren (Anmeldungen, Rechteänderungen, Datenexporte, Schlüsselzugriffe, Änderungen an Sicherheitskonfigurationen), dort eine Aufbewahrung, die an der gemessenen Erkennungszeit ausgerichtet ist, und ein Zugriffstest, der einmal im Quartal eine Abfrage über den gesamten Zeitraum stellt. Dieser Test ist gleichzeitig der Nachweis für lit. d, weil er zeigt, dass die Protokollierung nicht nur konfiguriert, sondern abfragbar ist.

Auftragsverarbeitung: Art. 28 trägt Art. 32 in fremde Systeme weiter

Art. 28 Abs. 3 lit. c verlangt, dass der Auftragsverarbeiter alle nach Art. 32 erforderlichen Maßnahmen ergreift, und die Vereinbarung zur Auftragsverarbeitung muss diese Maßnahmen benennen. Der typische Defekt ist ein Anhang, der seit 2018 dieselben zwölf Punkte enthält: Zugangskontrolle, Weitergabekontrolle, Eingabekontrolle, Verfügbarkeitskontrolle — ohne ein einziges Verfahren, ohne eine Frist, ohne eine Zahl. Ein solcher Anhang beschreibt eine Absicht, nicht einen Zustand, und er verschiebt das Problem nicht: Der Verantwortliche bleibt für Auswahl und Überwachung verantwortlich.

Der brauchbare Test ist der Nachweis-Test. Fragen Sie den Dienstleister nach drei Dingen: dem letzten Wiederherstellungsprotokoll mit Datum und Dauer, der letzten Berechtigungsprüfung mit Stichprobe und Ergebnis und der Aufbewahrungsdauer der sicherheitsrelevanten Protokolle einschließlich der Frist, innerhalb derer er einen Vorfall meldet. Wer diese drei nicht in einer Woche liefern kann, hat keinen Prozess, sondern eine Vertragsseite. Ergänzend gehören in die Vereinbarung: die Liste der Unterauftragsverarbeiter mit Änderungsanzeige, das Recht auf Prüfung oder die Anerkennung eines geeigneten Zertifikats nach Art. 42 als Nachweisform, die Pflicht zur Meldung von Vorfällen ohne schuldhafte Verzögerung und eine Rückgabe- und Löschregelung am Ende der Laufzeit mit Nachweis.

Verzeichnis von Verarbeitungstätigkeiten und TOM-Dokumentation: was gehört wohin

Art. 30 Abs. 1 Nr. 7 verlangt im Verzeichnis von Verarbeitungstätigkeiten, wenn möglich eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen gemäß Artikel 32 Absatz 1. Das Wort allgemein ist der Grund für ein verbreitetes Missverständnis: Viele Unternehmen behandeln das Verzeichnis als ihre Sicherheitsdokumentation und hören dort auf. Die Musterhinweise des BfDI unterscheiden ausdrücklich zwischen den allgemeinen TOM im Vorblatt, die für alle Verarbeitungen gelten, und den zusätzlichen Maßnahmen, die bei der einzelnen Verarbeitung über das allgemeine Niveau hinausgehen. Beides ist zu führen, und beides ist zu verknüpfen.

Sauber ist die Struktur in drei Ebenen: eine unternehmensweite TOM-Liste mit Maßnahmenkennungen, je Verarbeitungstätigkeit ein Verweis auf die anwendbaren Kennungen plus die zusätzlichen Maßnahmen, und je Maßnahme ein Ablageort für das Nachweisartefakt. Ohne Kennungen entsteht bei jeder Prüfung eine Übersetzungsrunde, und Übersetzungsrunden sind der Ort, an dem Widersprüche entstehen. Ein Hinweis zur Reichweite: Die Ausnahme in Art. 30 Abs. 5 für Unternehmen mit weniger als 250 Beschäftigten gilt nicht, wenn die Verarbeitung nicht nur gelegentlich erfolgt, besondere Kategorien nach Art. 9 oder Daten über strafrechtliche Verurteilungen und Straftaten betrifft oder ein Risiko für die Rechte und Freiheiten besteht. Für die meisten Dienstleister mit Kundenverwaltung greift sie damit nicht.

Datenschutz-Folgenabschätzung und Art. 32 müssen zusammenpassen

Die Datenschutz-Folgenabschätzung nach Art. 35 beschreibt die Risiken und die Maßnahmen zu ihrer Bewältigung, einschließlich der nach Art. 32 vorgesehenen Maßnahmen. Wenn die Folgenabschätzung für eine Verarbeitung ein hohes Risiko feststellt und die TOM-Dokumentation für dieselbe Verarbeitung Firewall vorhanden, tägliche Sicherung nennt, dann haben Sie nicht zwei Dokumente, sondern einen Widerspruch, den eine Aufsichtsbehörde zuerst liest. Der Abgleich ist einfach, wenn dieselben Maßnahmenkennungen in beiden Dokumenten stehen und die Restrisikobewertung sich auf die Wirksamkeitsnachweise stützt, statt sie zu behaupten.

Praktisch verbindet man die Dokumente über drei Sätze: Welches Risiko wurde identifiziert, welche Maßnahme adressiert es, und welcher Nachweis zeigt, dass die Maßnahme wirkt. Bleibt nach den Maßnahmen ein hohes Risiko bestehen, ist die vorherige Konsultation nach Art. 36 der nächste Schritt — und auch das ist ein Art.-32-Thema, weil die Behörde dann genau die Angemessenheit der Maßnahmen prüft. Die Folgenabschätzung ist zudem der Ort, an dem sich die Frage nach dem Stand der Technik konkret beantworten lässt, weil sie die Verarbeitung beschreibt; eine TOM-Liste ohne diesen Bezug bleibt eine Sammlung von Produktnamen.

Seit dem 6. Dezember 2025 gilt in Deutschland ein zweites Regime

Für viele Unternehmen kommt zu Art. 32 DSGVO seit Kurzem eine zweite, unabhängige Pflichtenschicht. Das NIS-2-Umsetzungsgesetz wurde am 13. November 2025 im Bundestag und am 21. November 2025 im Bundesrat beschlossen, am 5. Dezember 2025 verkündet und trat am 6. Dezember 2025 ohne Übergangsfristen in Kraft. Es schafft kein eigenständiges NIS-2-Gesetz, sondern reformiert das BSI-Gesetz und passt sektorspezifische Regelwerke an. Betroffene Einrichtungen müssen sich beim BSI registrieren; das Registrierungsportal steht seit dem 6. Januar 2026 bereit, die ursprünglich bis Ende März 2026 laufende Frist wurde bis Ende Juli 2026 verlängert.

Die Meldepflichten laufen auf drei Stufen: Frühwarnung innerhalb von 24 Stunden ab Kenntnis des Vorfalls, Meldung innerhalb von 72 Stunden mit einer ersten Bewertung, Abschlussbericht nach einem Monat. Dazu kommen Pflichten zum Risikomanagement mit technischen und organisatorischen Maßnahmen, eine Haftung der Geschäftsleitung, die bei Verstößen bis zum Privatvermögen reichen kann, Bußgelder bis 10 Millionen Euro oder 2 Prozent des Gesamtumsatzes und ein Nachweiszyklus, der sich von zwei auf drei Jahre verlängert. Für die Praxis bedeutet das keine zweite Dokumentation, sondern eine Zuordnung: Bauen Sie einen Maßnahmenkatalog und mappen Sie ihn auf beide Regelwerke. Die 24-Stunden-Frühwarnung ist dabei die härteste Anforderung und der Grund, den internen Ablauf am kürzeren der beiden Zeitfenster zu dimensionieren — wer 72 Stunden lang ermittelt, bevor jemand die Frühwarnung abschickt, hat den Fall bereits verloren.

Bußgeld: 10 Millionen Euro oder 2 Prozent — und warum Art. 32 selten allein kommt

Art. 32 liegt nicht in der obersten Bußgeldstufe. Art. 83 Abs. 4 lit. a erfasst Verstöße gegen die Pflichten der Verantwortlichen und Auftragsverarbeiter nach den Artikeln 8, 11, 25 bis 39, 42 und 43 — und damit Art. 32 — mit einem Rahmen bis 10 Millionen Euro oder 2 Prozent des gesamten weltweit erzielten Jahresumsatzes des Vorjahres, je nachdem, welcher Betrag höher ist. Die 20 Millionen Euro oder 4 Prozent aus Art. 83 Abs. 5 gelten für die Grundsätze einschließlich der Bedingungen für die Einwilligung nach Art. 5, 6, 7 und 9, für die Betroffenenrechte nach Art. 12 bis 22 und für Übermittlungen nach Art. 44 bis 49.

In der Praxis bleibt es selten bei der unteren Stufe, und das hat zwei Gründe. Erstens berührt ein Sicherheitsvorfall fast immer Art. 5 Abs. 1 lit. f, also die Integrität und Vertraulichkeit als Grundsatz — und der liegt in der oberen Stufe. Zweitens begrenzt Art. 83 Abs. 3 bei mehreren Verstößen aus demselben oder miteinander verbundenen Verarbeitungsvorgängen den Gesamtbetrag auf den Betrag für den schwerwiegendsten Verstoß, was die untere Stufe nur dann relevant macht, wenn kein Grundsatzverstoß hinzukommt. Umgekehrt wirkt Art. 83 Abs. 2 lit. d ausdrücklich zugunsten des Verantwortlichen: die Maßnahmen nach Art. 25 und 32 sind ein gesetzlich benannter mildernder Umstand. Dokumentierte, getestete Maßnahmen senken also nicht nur das Risiko, sondern auch die Bemessung.

Die veröffentlichte Vollzugspraxis zeigt, wo es weh tut. Die kroatische Aufsichtsbehörde belegte ein Vergleichsportal mit 320.000 Euro, weil Zugangsdaten und Passwörter im Klartext gespeichert und vergessene Passwörter per E-Mail im Klartext versandt wurden — ein Fall, in dem kein ausgeklügelter Angriff nötig war. Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit verhängte gegen die Vodafone GmbH Geldbußen in Höhe von insgesamt 45 Millionen Euro, unter anderem wegen unzureichender Prüfung und Überwachung von Partneragenturen nach Art. 28 Abs. 1, und rügte im selben Zusammenhang Verstöße gegen Art. 32 Abs. 1 wegen Schwachstellen in Vertriebssystemen; hinzu kamen 30 Millionen Euro wegen Mängeln im Authentifizierungsprozess eines Kundenportals. Das Muster ist überall dasselbe: nicht der fehlende High-End-Schutz wird sanktioniert, sondern die fehlende Grundhygiene und die fehlende Aufsicht über Dienstleister.

Das eigentliche finanzielle Risiko liegt ohnehin nicht beim Bußgeld. Art. 82 gibt jeder betroffenen Person einen eigenen Anspruch, und nach C-340/21 müssen Sie die Geeignetheit Ihrer Maßnahmen beweisen. Bei einem Vorfall mit 50.000 betroffenen Datensätzen ist die Summe aus vielen kleinen Ansprüchen und Verfahrenskosten regelmäßig größer als die Geldbuße — und die Beweislast liegt auf Ihrer Seite.

Der 90-Tage-Plan: von der Checkliste zum Nachweis

Die Reihenfolge der Arbeit entscheidet darüber, ob am Ende Nachweise existieren oder nur ein weiteres Dokument. Bewährt ist der Weg vom Billigen und Sofortigen zum Teuren und Externen. In den ersten zwei Wochen: Inventar der Verarbeitungstätigkeiten mit Datenkategorie, Betroffenengruppe und Systembezug, dann die Risikoklasse je Verarbeitung, dann die Vorabfestlegung, welche Maßnahmen an welche Klasse gebunden sind. In den Wochen drei bis fünf entstehen die sechs Nachweise, die jede Prüfung zuerst anfordert: Schlüsselinventar, Berechtigungsprüfung mit Stichprobe, Wiederherstellungsprotokoll mit RTO-Messung, Patch-Kennzahl, Aufbewahrungsregel für sicherheitsrelevante Protokolle und ein Testbericht mit Retest. In den Wochen sechs bis acht folgt die Konsolidierung: Maßnahmenkennungen einführen, Verzeichnis und Folgenabschätzung darauf verweisen lassen, den Anhang zur Auftragsverarbeitung bei den drei wichtigsten Dienstleistern durch die Nachweisliste ersetzen, das Mapping auf die Pflichten aus dem reformierten BSI-Gesetz ergänzen. In den Wochen neun bis zwölf wird der Zyklus kalendriert: wer prüft was in welchem Quartal, und ein erster externer Test mit klarem Umfang.

Wer nicht alles in 90 Tagen schafft, sollte eines nicht tun: den offenen Punkt aus der Dokumentation herauslassen. Ein datierter Sanierungsplan mit Verantwortlichem, Zwischenziel und Nachweis ist selbst ein Nachweis für die Ernsthaftigkeit der Maßnahmen und fällt unter Art. 83 Abs. 2 lit. d. Ein geschönter Zustand, der bei der ersten Stichprobe auffällt, zerstört dagegen die Glaubwürdigkeit der gesamten Dokumentation — und dann wird jede andere Angabe mitgeprüft.

Wann eine externe Prüfung sinnvoll ist und wie Sie sie einkaufen

Ein externer Test ist sinnvoll, wenn Sie eine Aussage über Ausnutzbarkeit brauchen, die Sie selbst nicht glaubwürdig treffen können — gegenüber Kunden, Versicherern oder einer Behörde —, und wenn Sie die Kapazität haben, die Befunde abzuarbeiten. Er ist nicht sinnvoll als Ersatz für die Nachweise aus lit. b bis d: Ein Penetrationstest zeigt keine Berechtigungsprüfung, kein Wiederherstellungsprotokoll und keine Aufbewahrungsregel.

Für den Einkauf zählen fünf Punkte. Erstens ein schriftlich definierter Umfang mit Systemen, Rollen und ausgeschlossenen Bereichen. Zweitens eine schriftliche Beauftragung und ein Regelwerk, das ausschließlich Systeme erfasst, deren Eigentümer Sie sind oder für die Sie nachweislich schriftlich autorisiert wurden; alles andere ist kein Test, sondern ein Rechtsrisiko. Drittens die Zusage eines Retests für die kritischen Befunde im Preis. Viertens ein Lieferformat, das sich in Ihre Dokumentation einfügt: Befunde geordnet nach den vier Buchstaben aus Art. 32 Abs. 1, jeweils mit System, Datum, Umfang, Ergebnis und Behebungshinweis. Fünftens die Wahrheit über die Grenzen des Berichts: Eine Aufzählung von CVSS-Werten ohne Bezug zur Verarbeitung sagt nichts über Angemessenheit, und ein 400-Seiten-Bericht, den niemand liest, ist kein Nachweis, sondern ein Regal.

Wenn Sie eine solche Prüfung beauftragen, sollte sie an einer Verarbeitung mit hoher Risikoklasse ansetzen und nicht an der Anwendung, die am einfachsten erreichbar ist. Der Nutzen entsteht dort, wo ein Befund eine Aussage über Ihre Risikobeurteilung erlaubt — und damit den Zweischritt aus C-340/21 schließt, den keine Aufsichtsbehörde mehr überspringt.