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 (Rechtspflicht)         ISO 27001 (Best Practice)
         ↓                               ↓
Art. 32: TOMs             ←→    ISMS-Kontrollen
Art. 33: 72h-Meldung      ←→    Incident Response
Art. 5: Rechenschaft      ←→    Dokumentation + Audits
Art. 25: Privacy by Design ←→   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:

• Stand der Technik
• Implementierungskosten
• Art, Umfang, Kontext und Zweck der Verarbeitung
• 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: externe 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

Pseudonymisierung und Verschlüsselung:
  Datenbank: AES-256 Verschlüsselung at rest
  Transport: TLS 1.3 für alle Verbindungen
  E-Mail: S/MIME oder PGP für sensitive Inhalte
  Endgeräte: BitLocker (Windows) / FileVault (macOS) aktiviert
  Backups: Verschlüsselte Backup-Medien (kein Klartext auf USB)

Vertraulichkeit, Integrität, Verfügbarkeit:
  Vertraulichkeit: MFA, Least Privilege, Netzwerksegmentierung
  Integrität:      Audit Logs, Hashing von Daten, Versionierung
  Verfügbarkeit:   BCM/DRP, redundante Systeme, regelmäßige Tests

Belastbarkeit der Systeme:
  DDoS-Schutz (Cloudflare/AWS Shield)
  Redundante Internetanbindung
  Automatisches Failover für kritische Systeme
  Penetrationstests + Schwachstellenscans (regelmäßig)

Wiederherstellbarkeit nach Vorfällen:
  Backup-Strategie: 3-2-1-Regel
  Restore-Tests: quartalsweise
  Recovery Time Objective (RTO) definiert
  Recovery Point Objective (RPO) definiert
  Disaster Recovery Plan dokumentiert

Verfahren zur Wirksamkeitsprüfung:
  Regelmäßige Penetrationstests (extern)
  Schwachstellenscans (intern, quartalsweise)
  ISO 27001 Interne Audits
  DSGVO-Datenschutz-Audit

TOM-Dokumentation - Rechtliche Anforderungen

Wer muss TOMs dokumentieren?
  → Jeder Verantwortliche (alle die personenbezogene Daten verarbeiten)
  → Jeder Auftragsverarbeiter (Art. 28 AVV enthält TOMs!)
  → Unternehmensgröße: spielt keine Rolle (auch 1-Personen-GmbH!)

Wann werden TOMs benötigt?
  1. Art. 30 DSGVO: Verarbeitungsverzeichnis (VVT) → TOMs verweisen
  2. Art. 28: Auftragsverarbeitungsvertrag (AVV) → TOMs des AV
  3. Art. 35 DSFA: Datenschutz-Folgenabschätzung → TOM-Bewertung
  4. Aufsichtsbehörde prüft: Nachweis der Maßnahmen
  5. Datenpanne: "Wurden geeignete Maßnahmen ergriffen?" → Bußgeld?

Form der Dokumentation:
  → Kein vorgeschriebenes Format (DSK-Muster verfügbar)
  → Wichtig: konkret und nachvollziehbar
  → "Wir nutzen Verschlüsselung" → zu vage
  → "AES-256-GCM für Daten at rest, TLS 1.3 für Transport" → gut
  → Versioniert: wann wurden TOMs zuletzt aktualisiert?

TOM-Checkliste nach den 8 Schutzbereichen

1. Zugangskontrolle (Physische Sicherheit):
   □ Serverräume: Schlüssel/Badge-Zugang, nur berechtigte Personen
   □ Besucherregister für Rechenzentrum/Serverraum
   □ Videoüberwachung (wenn verhältnismäßig)
   □ Bildschirmschutz/Sichtschutz an sensiblen Arbeitsplätzen
   □ Verbot von privaten Speichermedien in Hochsicherheitsbereichen
   □ Clear-Desk-Policy: sensible Unterlagen nicht offen lassen
   Dokumentation: Berechtigungsmatrix, Besucherlog, Fotos Serverraum-Zugang

2. Zugriffssteuerung (Logical Access):
   □ Rollenbasierte Zugriffskontrolle (RBAC)
   □ Least-Privilege: nur notwendige Rechte
   □ Starke Passwörter (Mindestlänge, Komplexität)
   □ Passwort-Manager für Mitarbeiter
   □ MFA für Remote-Zugänge und sensitive Systeme
   □ Automatische Session-Sperre nach Inaktivität
   □ Privilegierte Konten: separate Admin-Accounts
   Dokumentation: Berechtigungsmatrix, IAM-Policy, Password Policy

3. Zugriffskontrolle / Protokollierung:
   □ Zugriffslogs auf Systemen mit personenbezogenen Daten
   □ Protokollierung von Zugriffen auf sensitive Daten
   □ Logs mindestens 90 Tage aufbewahren
   □ Regelmäßige Überprüfung der Zugriffslogs
   □ Alarme bei ungewöhnlichen Zugriffsmustern
   Dokumentation: Log-Konzept, SIEM-Konfiguration, Review-Protokolle

4. Weitergabekontrolle:
   □ Verschlüsselter Transport (TLS 1.2+, bevorzugt TLS 1.3)
   □ Sichere E-Mail für sensitive Kommunikation (PGP, S/MIME)
   □ VPN für Remote-Zugriff auf interne Systeme
   □ Sichere Dateiübertragung (SFTP statt FTP)
   □ Sendegerät/Empfänger bei Datenübertragungen dokumentieren
   Dokumentation: Verschlüsselungskonzept, VPN-Policy

5. Eingabekontrolle:
   □ Protokollierung: wer hat welche Daten eingegeben/geändert/gelöscht?
   □ Audit-Trail in Anwendungen (wer hat was wann gemacht?)
   □ Vier-Augen-Prinzip für kritische Änderungen
   □ Change Management für Systemänderungen
   Dokumentation: Audit-Trail-Konfiguration, Change-Log

6. Auftragskontrolle:
   □ Auftragsverarbeitungsvertrag (AVV) mit allen Dienstleistern
   □ Prüfung der AVV-Partner (zertifiziert? Geeignete TOMs?)
   □ Dienstleister-Verzeichnis mit Datenkategorien
   □ Weisungsbefugnis dokumentiert
   Dokumentation: Alle AVVs, Dienstleister-Liste

7. Verfügbarkeitskontrolle:
   □ Regelmäßige Backups (mindestens täglich für Produktionsdaten)
   □ Backup-Tests (mindestens quartalsweise)
   □ Disaster Recovery Plan
   □ RTO und RPO definiert
   □ Redundante Systeme für kritische Prozesse
   □ Business Continuity Plan
   Dokumentation: Backup-Konzept, Restore-Test-Protokolle, BCP

8. Pseudonymisierung/Verschlüsselung:
   □ Verschlüsselung von Daten at rest (Festplatten, Backups)
   □ TLS für alle Datenübertragungen
   □ Pseudonymisierung wo möglich (Test-Systeme!)
   □ Keine Produktion-Dumps in Entwicklungsumgebung!
   Dokumentation: Verschlüsselungskonzept, Algorithmen und Schlüssellängen

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

[Ausschnitt eines realen TOM-Dokuments]

System: CRM-Lösung (Salesforce)
Stand: 2026-03-08
Verantwortlich: Max Muster, IT-Leiter

---

1. Zugangskontrolle:
   - Physisch: Serverzentrum von Salesforce Inc. (SOC 2 Typ II zertifiziert)
     Nachweis: Salesforce SOC 2 Report (aktuell)
   - Logisch: SSO via Microsoft Entra ID (SAML 2.0)
     MFA: Pflicht für alle Nutzer (Conditional Access Policy)
   - Berechtigungsmatrix: Anlage A (Rollen: User, Manager, Admin, Read-Only)

2. Verschlüsselung:
   - Transport: TLS 1.3 (Salesforce-Standard, verifiziert via SSL Labs)
   - At Rest: AES-256 (Salesforce-Standard, laut Sicherheitswhitepaper)
   - Key Management: Salesforce Shield (Customer-managed Keys, optional)

3. Logging und Monitoring:
   - Alle Login-Ereignisse werden in Salesforce Event Log gespeichert
   - Aufbewahrung: 30 Tage (Standard), 1 Jahr (Salesforce Shield)
   - Anomalie-Alerting: aktiviert für: außergewöhnliche Datenmenge, Login-Fails
   - Review: monatlich durch IT-Leiter

4. Zugriffskontrolle:
   - Least Privilege: Nutzer erhalten nur Zugriff auf eigene Accounts
   - Admin-Accounts: separate Accounts, MFA mit Hardware-Key
   - Quartalweise Review der Berechtigungen
   - Inaktive Accounts (>90 Tage): automatisch deaktiviert

5. Verfügbarkeit:
   - SLA Salesforce: 99.9% Uptime
   - Backup: Salesforce Weekly Data Export (aktiviert)
   - Eigene Exports: monatlich via Salesforce API → S3 (verschlüsselt)

6. Pseudonymisierung/Testdaten:
   - Keine Produktionsdaten in Entwicklungs-/Testinstanzen
   - Testdaten: Synthetisch generiert (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.

Sonntag 22:00 Uhr: Ransomware wird auf System entdeckt
                    ↓
Montag 22:00 Uhr: 24 Stunden vergangen
                    ↓
Dienstag 22:00 Uhr: 72-Stunden-Frist ENDET

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 melden (Art. 33): Alle Verletzungen des Schutzes personenbezogener Daten
  - Ransomware auf Systemen mit Kundendaten
  - Gestohlener/verlorener Laptop ohne Verschlüsselung
  - Zugriff durch unbefugte Dritte auf Kundendatenbank
  - Unbefugte E-Mail-Weiterleitung (BEC-Incident)

ZUSÄTZLICH Betroffene informieren (Art. 34): Wenn hohes Risiko für Betroffene
  - Gesundheitsdaten, Finanzdaten, besondere Kategorien
  - Großer Datensatz (z.B. alle Kunden)
  - Angreifer könnte Daten für Identitätsdiebstahl nutzen

NICHT meldepflichtig:
  - Angriff abgewehrt, keine Daten betroffen
  - Vollverschlüsselte Daten verloren (Schlüssel nicht kompromittiert)
  - Interne Kommunikationsfehler ohne externe Auswirkung

Notfall-Meldeformular vorbereiten

DSGVO-Meldungen müssen enthalten:

1. Art der Verletzung (Ransomware, Diebstahl, unbefugter Zugriff)
2. Kategorien und Anzahl betroffener Personen
3. Kategorien und Anzahl betroffener Datensätze
4. Kontaktdaten des DSB
5. Wahrscheinliche Folgen der Verletzung
6. Getroffene oder geplante Abhilfemaßnahmen

Tipp: Vorlage für Meldung im Voraus erstellen und im Notfallplan hinterlegen.

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:

• Systematische und umfassende Bewertung persönlicher Aspekte (inkl. Profiling)
• Umfangreiche Verarbeitung besonderer Datenkategorien (Gesundheit, biometrisch)
• Systematische Überwachung öffentlicher Bereiche (CCTV, Tracking)
• Neue Technologien (KI-gestützte Entscheidungen, IoT mit Personenbezug)

DSFA-Prozess:

1. Beschreibung der Verarbeitung (Was, Warum, Wer, Wie)
2. Notwendigkeit und Verhältnismäßigkeit prüfen
3. Risiken für Betroffene identifizieren und bewerten
4. Maßnahmen zur Risikoreduzierung planen
5. Dokumentation + ggf. Konsultation der Aufsichtsbehörde
6. DSFA regelmäßig aktualisieren (bei Änderungen)

Privacy by Design und Default (Art. 25)

Datenschutz muss in technische Systeme eingebaut werden - nicht nachträglich “draufgesetzt”:

Privacy by Design:
❌ Anti-Pattern:
   System entwickelt → "Wie bauen wir jetzt Datenschutz ein?"

✅ Privacy by Design:
   Anforderungsphase: Datenschutz-Anforderungen definieren
   Architektur: Datenflüsse, Datensparsamkeit, Pseudonymisierung einplanen
   Entwicklung: Sicheres Coding, Input Validation, Logging ohne Personenbezug
   Test: Datenschutz-Test (keine unnötigen Daten in Test-Datenbanken)

Privacy by Default:
  Datenmenge: Standardmäßig nur Mindestdaten erheben
  Speicherdauer: Kürzeste sinnvolle Dauer als Standard
  Zugänglichkeit: Daten standardmäßig nur für Befugte

TOMs und ISO 27001

ISO 27001:2022 deckt Art. 32-Anforderungen ab:

Control A.8.2: Privileged Access Rights → Zugriffssteuerung
Control A.8.5: Secure Authentication    → MFA, Passwörter
Control A.8.24: Use of Cryptography     → Verschlüsselung
Control A.8.13: Information Backup      → Verfügbarkeit
Control A.8.15: Logging                 → Protokollierung
Control A.7.9: Physical Security        → Zugangskontrolle
Control A.8.11: Data Masking            → Pseudonymisierung

ISO 27001-Zertifizierung als TOM-Nachweis:
  → Zertifikat zeigt: externe Prüfung hat ISMS validiert
  → Datenschutzbehörden akzeptieren ISO 27001 oft als starkes Indiz
  → Noch besser: ISO 27001 + ISO 27701 (Privacy Extension)

  ISO 27701 = ISO 27001 um Privacy-Anforderungen erweitert:
  → Spezifisch auf DSGVO ausgerichtet
  → Gilt als "Stand der Technik" für TOMs

DSGVO-Compliance in der IT-Praxis

Checkliste IT-System (Datenschutzprüfung)

□ 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: automatische Löschung nach Ablauf
□ Betroffenenrechte implementiert (Auskunft, Löschung, Export)
□ Backup und Wiederherstellbarkeit
□ Datenpannen-Prozess: 72h-Meldung vorbereitet

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

• Zu lange Speicherung: Logs/Daten werden nie gelöscht - mangelndes Löschkonzept
• Test-Daten: Echte Kundendaten in Entwicklungs-/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 Datenpanne: TOMs sofort überprüfen (Gap-Analyse)
• Penetrationstests: Technische TOMs validieren

Wie man prüft ob TOMs wirksam sind:

1. Penetrationstest: können wir trotz TOMs eindringen?
2. Tabletop Exercise: funktionieren Notfallmaßnahmen?
3. Backup-Test: können wir Daten tatsächlich wiederherstellen?
4. Phishing-Simulation: greifen die Awareness-Maßnahmen?
5. Vulnerability-Scan: werden Patches eingespielt?
6. 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.