DSGVO und IT-Sicherheit: Technische Maßnahmen nach Art. 32

“Angemessene technische und organisatorische Maßnahmen” — Art. 32 DSGVO klingt abstrakt. Die Aufsichtsbehörden haben jedoch klare Vorstellungen davon, was das in der Praxis bedeutet. Unternehmen, die bei Datenpannen keine dokumentierten TOMs vorweisen können, riskieren empfindliche Bußgelder — unabhängig davon, ob die Maßnahmen technisch vorhanden waren oder nicht. Entscheidend ist die Nachweisbarkeit.

Die rechtlichen Grundlagen und organisatorischen Pflichten — AVV, 72-Stunden-Meldepflicht, DSFA, Bußgeldpraxis — sind im Schwesterartikel DSGVO-Compliance für Unternehmen behandelt. Dieser Artikel fokussiert auf die technische Seite.

Was Art. 32 DSGVO konkret verlangt

Artikel 32 DSGVO formuliert die Anforderungen risikobasiert:

“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… treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein: a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten; b) die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme sicherzustellen; c) die Fähigkeit, die Verfügbarkeit und den Zugang zu personenbezogenen Daten bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen; d) ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der TOMs.”

Die vier Schutzziele:

Schutzziel	Bedeutung
Vertraulichkeit	Nur Berechtigte können Daten einsehen
Integrität	Daten sind vollständig und unverändert
Verfügbarkeit	Daten sind zugänglich wenn benötigt
Belastbarkeit	Systeme bleiben bei Angriffen/Ausfällen resilient

“Angemessen” bedeutet risikobasiert — kein absolutes Niveau:

Risikoniveau	Beispiele	Anforderungen
Niedriges Risiko	Kundenliste B2B	Basis-Maßnahmen: MFA, Verschlüsselung at rest, Backup
Mittleres Risiko	Mitarbeiterdaten, normale Kundendaten	Standard-TOMs, DSFA ab bestimmten Verarbeitungen
Hohes Risiko	Art. 9 Daten: Gesundheit, Biometrie, Bankdaten	Erhöhte TOMs, Pseudonymisierung, DSFA obligatorisch, regelmäßige Penetrationstests

TOM-Katalog: Konkrete technische Maßnahmen

Bereich 1: Zugangs- und Zugriffskontrolle

Zutrittskontrolle (physisch):

• Serverräume: Schlüsselkarte + PIN oder Biometrie
• Besucherprotokoll: wer, wann, Begleitung
• Kein “Tailgating” in Serverräume
• Kameraüberwachung an Zugangspunkten (DSGVO-konform dokumentiert)

Zugangskontrolle (logisch):

• Passwort-Policy: mindestens 12 Zeichen, keine Wiederverwendung
• MFA für alle Mitarbeiter: Pflicht — nicht optional
• Inaktive Accounts: automatisch sperren nach 30 Tagen
• Offboarding: sofortige Account-Deaktivierung am letzten Arbeitstag

Zugriffskontrolle (Berechtigungen):

• Need-to-Know-Prinzip: nur auf Daten zugreifen, die für die Aufgabe nötig sind
• Role-Based Access Control (RBAC): Berechtigungsrollen statt einzelner Rechte
• Quartalsweise Access Reviews: wer hat noch welche Berechtigung?
• Keine Shared Accounts: jeder Nutzer hat einen eigenen Account
• Admin-Accounts: separate Accounts, nicht für die tägliche Arbeit

Konkrete Implementierung in Microsoft 365 via Conditional Access Policy: MFA für alle (Users=All, Grant=Require MFA), Legacy Auth blockieren, Managed-Device-Anforderung, Risky Sign-in blockieren.

Bereich 2: Verschlüsselung

Transport-Verschlüsselung:

• TLS 1.2+ auf allen Web-Anwendungen (TLS 1.0/1.1 deaktiviert)
• E-Mail: STARTTLS für SMTP, S/MIME für sensitive Kommunikation
• VPN: IKEv2 oder WireGuard (nicht PPTP/L2TP)
• HTTPS-Redirect: HTTP → HTTPS überall ohne Ausnahme

At-Rest-Verschlüsselung:

• Windows: BitLocker auf allen Laptops/Workstations (GPO: Require BitLocker, min. AES-256)
• Linux: dm-crypt/LUKS auf Server-Partitionen
• Backups: immer verschlüsselt vor dem Transport
• Datenbanken: Transparent Data Encryption (SQL Server, Oracle, PostgreSQL)
• Cloud-Speicher: AES-256 (S3 SSE, Azure Storage Encryption)

Schlüsselmanagement:

• Verschlüsselungsschlüssel getrennt von verschlüsselten Daten aufbewahren
• Key Management Service: AWS KMS, Azure Key Vault, HashiCorp Vault
• Schlüssel-Rotation: mindestens jährlich
• HSM (Hardware Security Module) für Hochsicherheitsumgebungen

Pseudonymisierung:

• PII in Analytics: Namen → Hash-IDs (nicht rückführbar)
• Logs: PII maskieren (E-Mail → ****@domain.de)
• Test-Daten: Produktions-PII pseudonymisiert — nie echte Daten in Test-Systemen

Bereich 3: Verfügbarkeit und Integrität

Backup nach der 3-2-1-Regel:

• 3 Kopien, 2 unterschiedliche Medien, 1 Kopie offsite
• Backup-Tests: monatliche Wiederherstellungstests (dokumentieren!)
• RPO: max. 24h Datenverlust (für die meisten Unternehmen)
• RTO: max. 4h bis Wiederherstellung
• Ransomware-Schutz: Backups immutable (WORM) oder air-gapped
• Backups immer verschlüsselt

Hochverfügbarkeit:

• Kritische Systeme: redundant (Load Balancer, Failover)
• Monitoring: Benachrichtigung bei Ausfall innerhalb 5 Minuten
• Disaster Recovery Plan: mindestens jährlich getestet und dokumentiert

Integritätssicherung:

• Datenbank-Integrität: referenzielle Integritätsprüfungen
• Audit Logs: unveränderlich (WORM, separate Logging-Infrastruktur)
• Hash-Prüfung: kritische Dokumente signiert
• Versionskontrolle: Dateiänderungen nachvollziehbar

Bereich 4: Löschung und Datenminimierung

Definierte Aufbewahrungsfristen pro Datenkategorie:

Datenkategorie	Frist
Rechnungen	10 Jahre (§ 257 HGB)
Personalakten	5 Jahre nach Ausscheiden
Bewerbungsunterlagen	6 Monate (dann löschen)
E-Mails geschäftlich	6–10 Jahre (je nach Inhalt)
Log-Dateien	max. 6 Monate (BSI-Empfehlung)
Website-Kontaktdaten	bis Anfrage bearbeitet + 3 Monate

Sicheres Löschen:

• HDD: DoD 5220.22-M (7-faches Überschreiben) oder Degaussing
• SSD: Hersteller-Secure-Erase (TRIM reicht nicht aus)
• Cloud: Löschbestätigung einholen (AWS S3: Object Lock löschen, dann Delete)
• AVV-Klausel: Auftragnehmer müssen Löschung auf Anfrage bestätigen

Bereich 5: Monitoring und Incident Response

Logging:

• Authentifizierungs-Events: Erfolg und Fehlschlag
• Admin-Aktivitäten: alle privilegierten Aktionen
• Datenbankzugriffe: auf sensitive Tabellen (PII-Zugriff)
• Export-Aktionen: Massendaten-Downloads
• Log-Aufbewahrung: 12 Monate (ISO 27001 + NIS2)
• Logs unveränderlich aufbewahren (WORM)

Incident Response:

• Datenpannen-Verfahren schriftlich dokumentiert
• DSGVO-72h-Meldepflicht: Prozess definiert, Verantwortlichkeiten klar, Templates bereit
• Forensik: Logs für Untersuchung dauerhaft verfügbar

Privacy by Design: Art. 25 DSGVO

Privacy by Design ist seit 2018 EU-Recht. Artikel 25 DSGVO verpflichtet Verantwortliche, Datenschutz schon bei der Systementwicklung einzubauen — nicht als nachträgliches Add-on.

Die sieben Grundprinzipien

1. Proaktiv statt reaktiv (Preventative): Datenschutz vor der Datenserhebung — Threat Modeling für Datenschutz in der Design-Phase.

2. Datenschutz als Standard (Privacy as the Default): Ohne aktive Nutzerwahl gilt maximaler Datenschutz. Cookies: Standard = keine nicht-essenziellen. Tracking: Standard = deaktiviert.

3. In die Systemgestaltung eingebettet (Privacy Embedded): Datenschutz strukturell im Datenbankschema, API-Design und Logging-Konzept — kein “Plugin-Datenschutz”.

4. Positive Summe (Full Functionality): Datenschutz und Usability schließen sich nicht aus. Differenzial-Privacy und Privacy-Preserving Analytics sind möglich.

5. End-to-End-Sicherheit (Lifecycle Protection): Löschkonzept: wenn Zweck erfüllt → Daten löschen. Retention-Policies technisch durchsetzen.

6. Sichtbarkeit und Transparenz (Visibility): Audit-Trails, Privacy-Dashboard für Nutzer, Data Subject Access Request (DSAR) automatisiert.

7. Nutzer-Zentrierung (Respect for User Privacy): Granulare Einwilligungen statt “All-or-Nothing”, Preference Center, Portability-API.

Datensparsamkeit technisch umsetzen

Datensparsamkeit (Art. 5(1)(c) — Data Minimization) bedeutet: “Brauchen wir dieses Feld wirklich für den Zweck? Können wir mit weniger Genauigkeit auskommen?”

Konkrete Maßnahmen:

• Formulare und APIs: Nur Pflichtfelder erheben. Für eine Registrierung reichen E-Mail und Passwort — weitere Felder erst wenn konkret benötigt.
• Altersverifikation statt Geburtsdatum: is_adult = verify_age(birthday) — nur das Ja/Nein speichern, nicht das Datum.
• IP-Adressen: Letztes Oktet abschneiden (192.168.1.123 → 192.168.1.0 für Analytics). IP-Adressen sind in der EU personenbezogene Daten (EuGH-Urteile).
• Aggregation statt Einzeldaten: Aggregierte Metriken statt User-Clicks mit Session-ID und Timestamp.

Pseudonymisierung vs. Anonymisierung

Konzept	Beschreibung	DSGVO-Status
Pseudonymisierung (Art. 4 Nr. 5)	Identifizierendes Merkmal durch Pseudonym ersetzt, Rückschluss nur mit zusätzlichen Informationen möglich	Bleibt personenbezogene Daten — DSGVO gilt weiterhin
Anonymisierung (Art. 11)	Rückschluss auf Person unmöglich	Kein Personenbezug mehr — DSGVO gilt nicht mehr

Wichtig: Echte Anonymisierung ist schwerer zu erreichen als oft angenommen. Schon PLZ + Geburtsdatum + Geschlecht reichen aus, um 87 % aller US-Personen eindeutig zu identifizieren. Scheinbar anonyme Daten sind oft re-identifizierbar.

Consent-Management technisch umsetzen

DSGVO-konforme Einwilligungen nach Art. 7 müssen freiwillig, spezifisch, informiert, eindeutig (aktive Handlung, kein Pre-Check) und widerrufbar sein.

Cookie-Kategorien:

Kategorie	Consent erforderlich?
Notwendig (Session, CSRF, Authentifizierung)	Nein
Präferenzen (Sprache, Dark-Mode)	Empfehlenswert
Statistiken (Analytics)	Ja
Marketing (Remarketing-Pixel, Tracking)	Immer explizit

Technische Umsetzung des Widerrufs: alle Marketing-Cookies sofort löschen, Opt-out in Analytics-System senden, Nachweis im Audit-Trail speichern.

DSGVO-konformes Logging

Logs sind oft das größte Datenschutzrisiko. Kein PII in Log-Level INFO oder DEBUG:

Gefährlich: log.info("User alice@firma.de logged in with password Password123!")

DSGVO-konform: log.info("User ID=47a2 authenticated successfully")

Retention-Policy für Logs: max. 6–12 Monate (je nach Anforderung). Keine Passwörter, E-Mail-Adressen oder IBANs in Logs.

DSAR-Automatisierung (Data Subject Access Requests)

Jede DSGVO-Auskunftsanfrage (Art. 15) erfordert den Export aller Daten zu einer Person. Technisch notwendig:

• User-ID-basierter Export-Mechanismus für alle Tabellen
• Soft-Delete vs. Hard-Delete: rechtliche Aufbewahrungsfristen beachten
• Automatisierter DSAR-Export reduziert Bearbeitungsaufwand erheblich

Penetrationstest als DSGVO-Nachweis

Art. 32 Abs. 1 lit. d verlangt ausdrücklich “ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit” der technischen und organisatorischen Maßnahmen. Ein Penetrationstest ist die konkreteste Form dieser Überprüfung.

Was ein Penetrationstest als DSGVO-Maßnahme leistet

Ein professioneller Penetrationstest:

• Testet die Wirksamkeit bestehender TOMs — nicht nur ob sie auf dem Papier existieren, sondern ob sie tatsächlich schützen
• Identifiziert Datenpfade — welche Angriffsvektoren führen zu personenbezogenen Daten
• Liefert dokumentierten Nachweis — bei einer Datenpanne kann nachgewiesen werden, dass die Schwachstelle zum Testzeitpunkt nicht bekannt war
• Erfüllt Art. 32 Abs. 1 lit. d — regelmäßige Überprüfung der TOM-Wirksamkeit ist Pflicht, nicht Empfehlung

Bei Datenpannen ist einer der ersten Fragen der Aufsichtsbehörden: “Wann haben Sie das letzte Mal Ihre Systeme auf Schwachstellen getestet?” Ein aktueller Penetrationstestbericht ist das stärkste Argument gegen ein Bußgeld.

Welche Systeme sollten bei DSGVO-relevantem Pentest geprüft werden?

Für die DSGVO besonders relevant sind Systeme, die personenbezogene Daten verarbeiten oder speichern:

• Web-Anwendungen mit Kundendaten — Login-Systeme, CRM-Oberflächen, Portale
• Datenbanken — direkte Zugänglichkeit, SQL-Injection-Anfälligkeit, Zugriffskontrolle
• APIs — oft unterschätzte Angriffsfläche bei personenbezogenen Daten
• Interne Netzwerke mit PII-Systemen — Lateral Movement zu Datenspeichern
• Cloud-Umgebungen — Fehlkonfigurationen in S3-Buckets, Azure-Blob-Storage

Pentest-Frequenz für DSGVO-Compliance

“Regelmäßig” ist nicht definiert, aber die Praxis orientiert sich an:

• Hochrisiko-Systeme (Art. 9 Daten, Gesundheit, Biometrie): Jährlich, zusätzlich nach wesentlichen Änderungen
• Standard-Systeme mit Kundendaten: Jährlich oder alle zwei Jahre
• Nach größeren Systemänderungen: Penetrationstest vor Go-Live
• Nach Sicherheitsvorfällen: Unmittelbar zur Lage-Bewertung

Pentest-Ergebnisse im TOM-Katalog dokumentieren

Der Penetrationstest ist nur dann ein DSGVO-Nachweis, wenn er dokumentiert ist:

• Datum des Tests
• Umfang (Scope): welche Systeme wurden getestet?
• Prüfer: externes Unternehmen (mit Qualifikation), internes Team oder kombiniert?
• Ergebnisse: gefundene Schwachstellen, Schweregrad, Behebungsstatus
• Nachprüfung: wurden identifizierte Schwachstellen behoben und nachgetestet?

Dokumentation für Audits: Der TOM-Katalog

Der TOM-Katalog ist das zentrale Dokument für DSGVO-Audits und als Anhang zum AVV obligatorisch.

Format pro Maßnahme

Feld	Inhalt
TOM-007	Verschlüsselung von Endgeräten
Beschreibung	Alle Laptops verschlüsselt mit BitLocker
Details	AES-256, TPM 2.0, Recovery Keys in Azure AD
Verantwortlich	IT-Abteilung
Überprüfung	Monatlicher Compliance-Report in Intune
Status	Implementiert (98 % Compliance, 2 % in Bearbeitung)
Nachweis	Intune-Report 2026-03-01

Bußgeldschutz durch Dokumentation

Der Datenschutzbeauftragte Hamburg verhängte ein Bußgeld von 35.000 € gegen ein Unternehmen mit der Begründung “Keine nachweisbaren TOMs zum Schutz der Bewerberdaten”. Mit dokumentierten TOMs wäre das Bußgeld erheblich geringer ausgefallen oder ganz entfallen — Art. 83 berücksichtigt die “Einhaltung der Verpflichtungen” bei der Bußgeldbemessung ausdrücklich.

Regelmäßige TOM-Review

• Jährliche Review durch CISO und Datenschutzbeauftragten
• Nach Incidents: TOMs auf Wirksamkeit prüfen
• Nach wesentlichen Systemänderungen: TOMs aktualisieren
• Dokumentation der Reviews: Datum, Ergebnis, Anpassungen

Die DSGVO-relevante Schnittmenge mit NIS2

Die technischen Anforderungen der DSGVO überschneiden sich erheblich mit NIS2. Beide verlangen:

• Risikobasierte Sicherheitsmaßnahmen
• Incident Response und Meldepflichten
• Verschlüsselung und Zugangskontrollen
• Regelmäßige Überprüfung der Maßnahmen
• Dokumentation und Nachweispflicht

Der Unterschied: DSGVO fokussiert auf personenbezogene Daten, NIS2 auf Betriebskontinuität und kritische Infrastrukturen. In der Praxis lassen sich die Compliance-Aktivitäten für beide Regelwerke effizient zusammenführen.

Mehr dazu: NIS2: Was Unternehmen wissen müssen

Fazit: TOMs sind kein Papierkram

Die wichtigste Erkenntnis aus der Bußgeldpraxis: Es geht nicht darum, perfekte Sicherheit zu erreichen — die gibt es nicht. Es geht darum, nachweisbar risikobasierte Maßnahmen getroffen zu haben, deren Wirksamkeit regelmäßig überprüft wird.

Unternehmen, die das ernst nehmen, profitieren mehrfach: Sie sind besser gegen Angriffe geschützt, können bei Vorfällen nachweisen, dass sie ihrer Sorgfaltspflicht nachgekommen sind, und reduzieren damit das Bußgeldrisiko erheblich.

Weiterführende Artikel

• DSGVO-Compliance für Unternehmen — Rechtsgrundlagen, Bußgelder, AVV, Meldepflicht und DSFA
• NIS2: Was Unternehmen wissen müssen — parallele EU-Regulierung mit erheblichen Überschneidungen
• Datenschutz-Folgenabschätzung im Detail — vollständiger Guide zur DSFA nach Art. 35

AWARE7 unterstützt bei technischer DSGVO-Compliance

AWARE7 unterstützt bei der Erstellung und Überprüfung von TOM-Katalogen, der technischen Umsetzung datenschutzkonformer IT-Infrastruktur und der Durchführung von Penetrationstests als DSGVO-Compliance-Nachweis.

Penetrationstest anfragen | ISMS und ISO 27001