DSGVO und IT-Sicherheit: Technische Anforderungen, TOMs und Umsetzung

Die Datenschutz-Grundverordnung (DSGVO) ist kein reines Rechtsthema - Art. 32 DSGVO verpflichtet explizit zur Umsetzung technischer Sicherheitsmaßnahmen. IT-Sicherheit und Datenschutz sind untrennbar verknüpft. Ein Datenschutzverletzungsvorfall (Security Breach) ist immer auch ein DSGVO-Problem. Und DSGVO-Compliance ohne funktionierendes ISMS ist ein Papiertiger.

Das Verhältnis DSGVO - ISO 27001 - IT-Sicherheit

DSGVO und ISO 27001 adressieren dieselben technischen Anforderungen aus unterschiedlichen Perspektiven: Art. 32 (TOMs) entspricht ISMS-Kontrollen, Art. 33 (72h-Meldung) entspricht Incident Response, Art. 5 (Rechenschaft) entspricht Dokumentation und Audits, und Art. 25 (Privacy by Design) entspricht Security by Design.

ISO 27001-Zertifizierung ist kein formaler DSGVO-Nachweis - aber ein starkes Indiz für die Einhaltung der technischen Anforderungen. Datenschutzbehörden akzeptieren ISO 27001 als Nachweis für Art. 32-Maßnahmen.

Was Art. 32 DSGVO fordert

"Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen [...]"

Art. 32 Abs. 1 - Explizit genannte Maßnahmen:

a) Pseudonymisierung und Verschlüsselung personenbezogener Daten
b) Dauerhafter Gewährleistung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Verarbeitungssysteme
c) Möglichkeit der raschen Wiederherstellung der Verfügbarkeit und des Zugangs zu den Daten (Disaster Recovery!)
d) Regelmäßige Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen

Schlüsselbegriffe:

"Stand der Technik" - nicht state-of-the-art Research, sondern bewährte und verfügbare Sicherheitstechnik
"Risikobasiert" - Maßnahmen proportional zum Risiko
"Geeignet" - keine absolute Sicherheit, aber angemessen

Art. 32 DSGVO: Technische und Organisatorische Maßnahmen (TOMs)

Art. 32 DSGVO verlangt "geeignete technische und organisatorische Maßnahmen" unter Berücksichtigung von Stand der Technik, Implementierungskosten, Art und Zweck der Verarbeitung sowie Eintrittswahrscheinlichkeit und Schwere von Risiken.

Beispiel: TOM-Matrix für E-Mail-Verarbeitung

Risiko	Maßnahme (Technisch)	Maßnahme (Org.)
Unbefugter Zugriff	MFA für E-Mail-Accounts, Conditional Access	Rollenkonzept, Need-to-know
Datenverlust	M365-Backup (täglich), Redundanz	Backup-Richtlinie, RTO/RPO definiert
Abfangen	TLS 1.3 für Transport, S/MIME-Verschlüsselung	Sensible Daten nie unverschlüsselt per Mail
Weiterleitung	Exchange-Richtlinie: externes Forwarding blockiert	Schulung: keine Firmendaten an privat
BEC-Angriff	DMARC p=reject, DKIM, SPF	Security Awareness Training, 4-Augen bei Überweisungen

Konkrete Technische TOMs nach Art. 32

Für Pseudonymisierung und Verschlüsselung gelten: AES-256-Verschlüsselung at rest für Datenbanken, TLS 1.3 für alle Verbindungen, S/MIME oder PGP für sensitive E-Mail-Inhalte, BitLocker (Windows) / FileVault (macOS) auf Endgeräten und verschlüsselte Backup-Medien.

Für Vertraulichkeit, Integrität, Verfügbarkeit gelten: MFA, Least Privilege und Netzwerksegmentierung (Vertraulichkeit), Audit Logs, Hashing und Versionierung (Integrität) sowie BCM/DRP, redundante Systeme und regelmäßige Tests (Verfügbarkeit).

Belastbarkeit erfordert: DDoS-Schutz (Cloudflare/AWS Shield), redundante Internetanbindung, automatisches Failover für kritische Systeme und regelmäßige Penetrationstests.

Wiederherstellbarkeit erfordert: Backup-Strategie nach der 3-2-1-Regel, quartalsweise Restore-Tests, definiertes Recovery Time Objective (RTO), definiertes Recovery Point Objective (RPO) und einen dokumentierten Disaster Recovery Plan.

TOM-Dokumentation - Rechtliche Anforderungen

TOMs müssen von jedem Verantwortlichen und Auftragsverarbeiter dokumentiert werden - unabhängig von der Unternehmensgröße. Sie werden in folgenden Kontexten benötigt: Verarbeitungsverzeichnis nach Art. 30, Auftragsverarbeitungsverträge nach Art. 28, Datenschutz-Folgenabschätzungen nach Art. 35, bei Aufsichtsbehörden-Prüfungen und nach Datenpannen.

Die Form der Dokumentation ist nicht vorgeschrieben (DSK-Muster verfügbar), aber sie muss konkret und nachvollziehbar sein. "Wir nutzen Verschlüsselung" ist zu vage. "AES-256-GCM für Daten at rest, TLS 1.3 für Transport" ist gut. Die Dokumentation sollte versioniert sein.

TOM-Checkliste nach den 8 Schutzbereichen

1. Zugangskontrolle (Physische Sicherheit): Serverräume mit Schlüssel/Badge-Zugang, Besucherregister, Videoüberwachung wenn verhältnismäßig, Bildschirmschutz an sensiblen Arbeitsplätzen, Verbot privater Speichermedien in Hochsicherheitsbereichen, Clear-Desk-Policy. Dokumentation: Berechtigungsmatrix, Besucherlog, Fotos Serverraum-Zugang.

2. Zugriffssteuerung (Logical Access): RBAC, Least Privilege, starke Passwörter, Passwort-Manager, MFA für Remote-Zugänge und sensitive Systeme, automatische Session-Sperre, separate Admin-Accounts. Dokumentation: Berechtigungsmatrix, IAM-Policy, Password Policy.

3. Zugriffskontrolle / Protokollierung: Zugriffslogs auf Systemen mit personenbezogenen Daten, mindestens 90 Tage Aufbewahrung, regelmäßige Überprüfung, Alarme bei ungewöhnlichen Zugriffsmustern. Dokumentation: Log-Konzept, SIEM-Konfiguration.

4. Weitergabekontrolle: TLS 1.2+ (bevorzugt 1.3), sichere E-Mail für sensitive Kommunikation, VPN für Remote-Zugriff, SFTP statt FTP. Dokumentation: Verschlüsselungskonzept, VPN-Policy.

5. Eingabekontrolle: Protokollierung von Dateneingaben und -änderungen, Audit-Trail in Anwendungen, Vier-Augen-Prinzip für kritische Änderungen, Change Management. Dokumentation: Audit-Trail-Konfiguration, Change-Log.

6. Auftragskontrolle: AVV mit allen Dienstleistern, Prüfung der AVV-Partner, Dienstleister-Verzeichnis, Weisungsbefugnis dokumentiert. Dokumentation: Alle AVVs, Dienstleister-Liste.

7. Verfügbarkeitskontrolle: Mindestens tägliche Backups für Produktionsdaten, quartalsweise Backup-Tests, Disaster Recovery Plan, definierte RTO/RPO, redundante Systeme, Business Continuity Plan. Dokumentation: Backup-Konzept, Restore-Test-Protokolle, BCP.

8. Pseudonymisierung/Verschlüsselung: Verschlüsselung at rest, TLS für Datenübertragungen, Pseudonymisierung wo möglich (insbesondere Test-Systeme!), keine Produktionsdaten in Entwicklungsumgebungen. Dokumentation: Verschlüsselungskonzept mit Algorithmen und Schlüssellängen.

Beispiel: TOM-Dokument für ein CRM-System

Ein TOM-Dokument für ein SaaS-CRM (Salesforce) enthält für jeden Schutzbereich konkrete Nachweise:

Zugangskontrolle: SOC-2-Typ-II-Zertifikat des Anbieters als Nachweis für physische Sicherheit; SSO via Microsoft Entra ID (SAML 2.0) mit MFA-Pflicht für alle Nutzer.
Verschlüsselung: TLS 1.3 für Transport (verifiziert via SSL Labs), AES-256 at rest (Anbieter-Standard, laut Sicherheitswhitepaper).
Logging: Alle Login-Ereignisse im Salesforce Event Log, 30 Tage Aufbewahrung, Anomalie-Alerting für außergewöhnliche Datenmengen und Login-Fehler.
Zugriffskontrolle: Least Privilege, separate Admin-Accounts mit Hardware-Key, quartalsweises Berechtigungs-Review, automatische Deaktivierung nach 90 Tagen Inaktivität.
Verfügbarkeit: 99,9% SLA, wöchentlicher Data Export aktiviert, monatliche eigene Exports via API auf verschlüsselte S3-Buckets.
Testdaten: Keine Produktionsdaten in Test-Instanzen, synthetisch generierte Testdaten (Faker.js).

Art. 33/34 DSGVO: Meldepflichten nach Security Incidents

72-Stunden-Uhr startet bei Entdeckung

Der Countdown läuft ab dem Moment der Entdeckung - nicht ab dem tatsächlichen Vorfall. Wird Ransomware am Sonntagabend um 22:00 Uhr entdeckt, endet die 72-Stunden-Frist am Dienstagabend um 22:00 Uhr.

Vorsicht: Wenn Security-Incident-Prozesse nicht 24/7 erkennen können (kein SOC, kein EDR, kein On-Call), beginnt die Uhr erst wenn jemand es bemerkt - aber Behörden können fragen "Hätten Sie es früher erkennen müssen?"

Was ist meldepflichtig?

Immer meldepflichtig nach Art. 33 sind alle Verletzungen des Schutzes personenbezogener Daten: Ransomware auf Systemen mit Kundendaten, gestohlene oder verlorene Laptops ohne Verschlüsselung, unbefugter Zugriff auf Kundendatenbanken und unbefugte E-Mail-Weiterleitungen (BEC-Incident).

Zusätzlich müssen nach Art. 34 die Betroffenen informiert werden wenn ein hohes Risiko für sie besteht: bei Gesundheitsdaten, Finanzdaten, besonderen Kategorien, bei großen Datensätzen (z. B. alle Kunden) oder wenn Angreifer die Daten für Identitätsdiebstahl nutzen könnten.

Nicht meldepflichtig: abgewehrte Angriffe ohne Datenbeteiligung, vollverschlüsselte Daten ohne Schlüsselkompromittierung und interne Kommunikationsfehler ohne externe Auswirkung.

Notfall-Meldeformular vorbereiten

DSGVO-Meldungen müssen enthalten: Art der Verletzung, Kategorien und Anzahl betroffener Personen, Kategorien und Anzahl betroffener Datensätze, Kontaktdaten des DSB, wahrscheinliche Folgen sowie getroffene oder geplante Abhilfemaßnahmen. Die Vorlage sollte im Voraus erstellt und im Notfallplan hinterlegt werden.

Art. 35 DSGVO: Datenschutz-Folgenabschätzung (DSFA / DPIA)

Eine DSFA ist Pflicht wenn eine Verarbeitung "voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen" hat. DSFA-Trigger sind systematische Bewertung persönlicher Aspekte (inkl. Profiling), umfangreiche Verarbeitung besonderer Datenkategorien (Gesundheit, biometrisch), systematische Überwachung öffentlicher Bereiche sowie neue Technologien (KI-gestützte Entscheidungen, IoT mit Personenbezug).

Der DSFA-Prozess umfasst: Beschreibung der Verarbeitung, Notwendigkeits- und Verhältnismäßigkeitsprüfung, Risikoidentifikation und -bewertung, Maßnahmenplanung, Dokumentation und ggf. Konsultation der Aufsichtsbehörde sowie regelmäßige Aktualisierung.

Privacy by Design und Default (Art. 25)

Datenschutz muss in technische Systeme eingebaut werden - nicht nachträglich aufgesetzt. Das Anti-Pattern ist, ein System fertig zu entwickeln und dann zu fragen "Wie bauen wir jetzt Datenschutz ein?"

Privacy by Design bedeutet: In der Anforderungsphase werden Datenschutzanforderungen definiert. In der Architekturphase werden Datenflüsse, Datensparsamkeit und Pseudonymisierung eingeplant. In der Entwicklung kommen sicheres Coding, Input Validation und Logging ohne Personenbezug zum Einsatz. Im Test werden keine unnötigen Daten in Test-Datenbanken verwendet.

Privacy by Default bedeutet: Standardmäßig nur Mindestdaten erheben, kürzeste sinnvolle Speicherdauer als Standard und Daten standardmäßig nur für Befugte zugänglich.

TOMs und ISO 27001

ISO 27001:2022 deckt die Art.-32-Anforderungen direkt ab: A.8.2 (Privileged Access Rights) entspricht Zugriffssteuerung, A.8.5 (Secure Authentication) entspricht MFA und Passwörtern, A.8.24 (Use of Cryptography) entspricht Verschlüsselung, A.8.13 (Information Backup) entspricht Verfügbarkeit, A.8.15 (Logging) entspricht Protokollierung, A.7.9 (Physical Security) entspricht Zugangskontrolle und A.8.11 (Data Masking) entspricht Pseudonymisierung.

ISO 27701 erweitert ISO 27001 um Privacy-Anforderungen, ist spezifisch auf die DSGVO ausgerichtet und gilt als "Stand der Technik" für TOMs.

DSGVO-Compliance in der IT-Praxis

Checkliste für jedes neue IT-System:

Rechtsgrundlage für Datenverarbeitung definiert (Art. 6)
Datenschutzinformation erstellt (Art. 13/14)
Auftragsverarbeitungsvertrag mit Cloud-Anbietern (Art. 28)
Verarbeitungsverzeichnis-Eintrag (Art. 30)
DSFA durchgeführt wenn erforderlich (Art. 35)
TOMs dokumentiert und implementiert (Art. 32)
Löschkonzept mit automatischer Löschung nach Ablauf
Betroffenenrechte implementiert (Auskunft, Löschung, Export)
Backup und Wiederherstellbarkeit
Datenpannen-Prozess mit 72h-Meldung vorbereitet

Häufige DSGVO-Verstöße in der IT:

Zu lange Speicherung: Logs und Daten werden nie gelöscht - mangelndes Löschkonzept
Test-Daten: Echte Kundendaten in Entwicklungs- und Testumgebungen
Fehlende AVVs: Cloud-Dienste ohne Auftragsverarbeitungsvertrag genutzt
Nicht-EU-Transfers: Daten in US-Cloud ohne geeignete Garantien (SCCs)
Fehlende Meldung: Ransomware-Vorfall nicht der Aufsichtsbehörde gemeldet

TOM-Review und kontinuierliche Verbesserung

Art. 32 Abs. 1 lit. d fordert ausdrücklich: "Regelmäßige Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen"

Empfohlener Review-Rhythmus: Jährlich vollständige TOM-Überprüfung, bei Systemänderungen TOMs aktualisieren, nach einer Datenpanne sofort Gap-Analyse, Penetrationstests zur Validierung technischer TOMs.

Wie man prüft ob TOMs wirksam sind: Penetrationstest (können wir trotz TOMs eindringen?), Tabletop Exercise (funktionieren Notfallmaßnahmen?), Backup-Test (können wir Daten tatsächlich wiederherstellen?), Phishing-Simulation (greifen die Awareness-Maßnahmen?), Vulnerability-Scan (werden Patches eingespielt?) und Access Review (sind Berechtigungen noch minimal?).

Bußgelder: Was droht bei IT-Sicherheitsmängeln?

Art. 32-Verstöße (fehlende TOMs) können mit bis zu 10 Mio. € oder 2% des weltweiten Jahresumsatzes bestraft werden. Art. 33-Verstöße (fehlende Meldung) ebenso.

Deutsche Beispiele:

Berliner Jobcenter: 215.000 € - unverschlüsselte E-Mail mit Sozialdaten
Hamburger Krankenhausgesellschaft: 105.000 € - mangelnde Sicherheitsmaßnahmen

Wichtig: DSGVO-Bußgelder kommen oft nach einem Security Incident. Die eigentliche Gefahr: Incident erzwingt Behördenkontakt, der Mängel in den TOMs aufdeckt.