Datenschutz technisch umsetzen (TOM)

Datenschutz wird oft als juristisches Thema abgelegt und dann im Alltag ignoriert, bis das erste Audit oder ein Vorfall ansteht. Technische und organisatorische Maßnahmen, kurz TOMs, sind aber nichts Abstraktes. Es sind sehr konkrete Aufgaben: Welche Daten speicherst du wo, wer darf was sehen, wie wird gelöscht, wie wird protokolliert. In diesem Artikel übersetzen wir die typischen TOM-Bausteine in umsetzbare Technik und praktikable Prozesse.

Ausgangspunkt: Welche Daten, welche Risiken?

Bevor du TOMs bauen kannst, musst du wissen, was du schützt. Drei einfache Fragen helfen als Start:

1. Welche personenbezogenen Daten verarbeiten wir überhaupt?
2. Wo liegen diese Daten technisch?
3. Was wäre der Schaden, wenn sie verloren gehen, verändert oder offengelegt würden?

Du musst dafür kein komplettes DSGVO-Verzeichnis schreiben, aber du brauchst ein grobes Bild. Typische Datenquellen:

• CRM-System, ERP, Lohnabrechnung
• E-Mail-System, Ticketsystem, Kollaborationstools
• Dateiserver, Cloud-Speicher, Backups
• Fachanwendungen (z. B. Praxissoftware, Kanzleisoftware, Produktionssysteme)

Dokumentiere diese Systeme knapp, etwa in einer Tabelle:

System	Art der Daten	Speicherort	Verfügbarkeit kritisch?	Vertraulichkeit kritisch?
CRM	Kundendaten, Kontaktdaten	Cloud EU-Rechenzentrum	Mittel	Hoch
Lohnabrechnung	Gehaltsdaten, Bankdaten	On-Premises München	Hoch	Sehr hoch
Ticketsystem	Supportanfragen, Logs	Cloud	Hoch	Mittel

Aus dieser Übersicht leitest du ab, wo du mit TOMs zuerst ansetzen musst: dort, wo Vertraulichkeit und Verfügbarkeit besonders kritisch sind.

Verschlüsselung: sinnvoll einsetzen statt überall „Crypto“

Verschlüsselung ist einer der sichtbarsten TOM-Bausteine, wird aber oft entweder übertrieben oder halbherzig umgesetzt. Sinnvoll ist ein gestuftes Vorgehen:

Transportverschlüsselung

Alles, was über ein Netzwerk läuft, sollte verschlüsselt sein. Konkret:

• Webanwendungen nur per HTTPS, keine unverschlüsselten Admin-Interfaces im internen Netz
• E-Mail-Transport mit TLS zwischen Mailservern, plus MTA-STS/DMARC, wo möglich
• VPN für den Zugriff von außen auf interne Systeme (IPsec oder TLS-basierte VPNs)

Prüfe regelmäßig mit Tools wie Qualys SSL Labs, ob deine TLS-Konfiguration noch zeitgemäß ist (Protokolle, Cipher Suites, Zertifikatsketten).

Datenträgerverschlüsselung

Verlorene Laptops und externe Festplatten sind Klassiker bei Datenschutzvorfällen. Minimale Basis:

• Vollverschlüsselung auf Notebooks und mobilen Geräten (BitLocker, FileVault, LUKS etc.)
• Verschlüsselte Partitionen oder Container auf Servern mit sensiblen Daten
• Mobile Geräte nur mit aktivierter Gerätesperre und Verschlüsselung

Wichtig: Verschlüsselung ist nur so gut wie der Schlüssel. Also:

• Klare Regeln, wie Schlüssel gesichert und wer berechtigt ist, sie zu verwenden
• Keine gemeinsamen „Master-Passwörter“ in Excel-Listen
• Einsatz eines Passwortmanagers für Administratoren

Verschlüsselung auf Anwendungsebene

Für besonders kritische Daten (Gesundheitsdaten, Bankdaten, bestimmte Logdaten) reicht Festplattenverschlüsselung nicht. Hier brauchst du Verschlüsselung in der Anwendung:

• Daten werden vor dem Speichern in der Datenbank verschlüsselt
• Schlüsselverwaltung getrennt vom Datenbankserver
• Rollenbasierter Zugriff in der Anwendung entscheidet, wer entschlüsseln darf

Das ist aufwendiger, schützt aber auch dann noch, wenn jemand direkten Zugriff auf die Datenbank bekommt.

Zugriffskonzepte: Wer darf was, und warum?

„Alle haben Zugriff auf alles“ ist bequem, aber in Sachen Datenschutz unhaltbar. Ein gutes Zugriffskonzept ist keine Raketenwissenschaft, erfordert aber Disziplin.

Rollen und Prinzipien

Nutze zwei zentrale Prinzipien:

• Need-to-know: Mitarbeitende bekommen nur Zugriff auf Daten, die sie für ihre Aufgabe brauchen.
• Least privilege: Auch technische Konten haben nur die minimal nötigen Rechte.

Praktisch bedeutet das:

• Definiere Rollen pro System, z. B. „Vertrieb“, „Buchhaltung“, „Admin“, „Reporting“.
• Ordne Berechtigungen den Rollen zu, nicht einzelnen Personen.
• Weise Personen Rollen zu, nicht Einzelrechten.

So ein Rollenmodell sollte dokumentiert und von der Fachabteilung mitgetragen werden, nicht nur von der IT.

Onboarding, Wechsel, Offboarding

Viele Datenschutzprobleme entstehen bei Personalwechseln. Du brauchst einen einfachen Ablauf:

• Onboarding: Checkliste, welche Rollen eine neue Person bekommt, wer das freigibt.
• Rollenwechsel: Anpassung der Rollen bei Abteilungswechsel, inklusive Entzug nicht mehr benötigter Zugriffe.
• Offboarding: Sperrung aller Zugänge am Austrittsdatum, inklusive mobiler Geräte, VPN, SaaS-Accounts.

Automatisierung hilft: Anbindung der Berechtigungen an ein zentrales Identity-Management (z. B. Active Directory, Azure AD, LDAP) reduziert Fehlerquellen.

Administrativer Zugriff

Admins sehen oft mehr als ihnen eigentlich lieb ist. Trotzdem darf es kein „God-Mode“ ohne Kontrolle geben:

• Administrative Konten getrennt von persönlichen Konten
• Administrative Aktionen möglichst protokollieren
• Wo möglich, Just-in-Time-Adminrechte statt Dauer-Admin

Damit schützt du nicht nur Daten, sondern auch deine Admins vor dem Verdacht, etwas „gesehen“ oder verändert zu haben.

Löschkonzepte: Daten wirklich loswerden

„Löschen“ ist selten ein einzelner Knopf. Zwischen Produktivsystem, Backups, Testsystemen und Exporten verstreuen sich Daten leicht. Ein Löschkonzept beantwortet drei Fragen:

1. Wann müssen welche Daten weg?
2. Wo liegen diese Daten überall?
3. Wie stellst du technisch sicher, dass sie verschwinden?

Aufbewahrungsfristen und Löschregeln

Setze dich mit Fachabteilungen zusammen und definiere einfache Regeln, zum Beispiel:

• Bewerbungsunterlagen: Löschung 6 Monate nach Abschluss des Bewerbungsverfahrens, wenn keine Einwilligung zur längeren Aufbewahrung vorliegt.
• Kundendaten im CRM: Löschung oder Anonymisierung X Jahre nach letztem Kontakt, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen.
• Logdaten: Kürzere Aufbewahrungsfristen, z. B. 3 bis 12 Monate, abhängig von Zweck und Sensibilität.

Halte diese Regeln schriftlich fest und nutze, wo möglich, technische Unterstützung:

• Automatische Löschjobs in Anwendungen (Workflows, Retention Policies)
• Datenbankskripte, die in regelmäßigen Abständen alte Datensätze entfernen oder anonymisieren
• S3-Lifecycle-Regeln oder ähnliche Funktionen in Cloud-Speichern

Backups und Testsysteme

Backups sind für Verfügbarkeit wichtig, aber ein Problem für Datenschutz:

• Definiere, wie lange Backups aufbewahrt werden.
• Stelle sicher, dass Backups verschlüsselt sind.
• Akzeptiere, dass selektives Löschen in Backups oft nicht praktikabel ist, aber begrenze die Backup-Historie.

Für Test- und Entwicklungssysteme gilt:

• Möglichst keine echten personenbezogenen Daten verwenden.
• Wenn es nicht anders geht, Daten vor der Nutzung anonymisieren oder pseudonymisieren.
• Zugriff auf Testsysteme genauso regeln wie auf Produktivsysteme.

Protokollierung: Nachvollziehbarkeit ohne Überwachungsexzess

Protokollierung ist ein zentrales TOM-Thema: Du musst nachvollziehen können, wer was getan hat. Gleichzeitig dürfen Logs nicht zur Totalüberwachung der Mitarbeitenden werden.

Was protokollieren?

Sinnvolle Ereignisse sind:

• Anmeldeversuche (erfolgreich und fehlgeschlagen)
• Rollen- und Berechtigungsänderungen
• Anlage, Änderung und Löschung von Datensätzen mit Personenbezug
• Administrative Aktionen (z. B. Konfigurationsänderungen, Systemneustarts)

Wichtig ist die Zuordenbarkeit: Aktionen sollten einer Person oder Rolle zugeordnet werden können, nicht nur einem gemeinsamen „Admin“-Konto.

Wie protokollieren?

Praktische Punkte:

• Zeitstempel immer mit Zeitzone.
• Logs gegen Manipulation schützen, z. B. durch zentrale Logserver, Write-Once-Speicher oder Signaturen.
• Zugriff auf Logdaten selbst beschränken, denn auch Logs enthalten oft personenbezogene Daten.

Nutze zentrale Log-Management-Systeme oder SIEM-Lösungen, wenn du viele Systeme hast. Für kleinere Umgebungen reicht oft eine Kombination aus Syslog, zentraler Auswertung und regelmäßiger manueller Prüfung.

Aufbewahrungsdauer für Logs

Auch für Logs brauchst du Löschregeln:

• So lange wie nötig, um Sicherheitsvorfälle nachzuvollziehen.
• So kurz wie möglich, um Datenschutz zu wahren.

Typisch sind Zeiträume zwischen wenigen Monaten und zwei Jahren, je nach System und Risiko. Wichtig ist, dass du die Dauer begründest und dokumentierst.

Pseudonymisierung: Daten nutzbar halten, Risiko senken

Pseudonymisierung wird oft mit Anonymisierung verwechselt. Der Unterschied:

• Anonymisierung: Personenbezug ist dauerhaft und praktisch nicht mehr herstellbar.
• Pseudonymisierung: Personenbezug ist entfernt, kann aber mit Zusatzinformationen wiederhergestellt werden.

Für viele Szenarien reicht Pseudonymisierung, zum Beispiel für:

• Statistiken über Kundennutzung
• Auswertungen im Produktmanagement
• Fehleranalysen mit echten, aber pseudonymisierten IDs

Technische Umsetzung

Typische Varianten:

• Ersetzen einer Kundennummer durch eine zufällige ID.
• Hashen einer Kennung (z. B. E-Mail-Adresse) mit einem Salt.
• Nutzung von Tokenisierungslösungen, bei denen ein Token anstelle des Originalwertes verwendet wird.

Wichtig ist das Schlüssel- bzw. Mapping-Management:

• Die Zuordnung zwischen Pseudonym und Originalwert muss getrennt und besonders geschützt gespeichert werden.
• Zugriff auf diese Zuordnung sollte stark eingeschränkt und protokolliert sein.
• Für viele Auswertungen reicht es, wenn der direkte Personenbezug gar nicht mehr notwendig ist. Dann kannst du echte Anonymisierung anstreben.

Pseudonymisierung ist kein Allheilmittel, aber ein sehr wirksamer Baustein, um Daten nutzbar zu halten und das Risiko bei Datenpannen zu senken.

Organisatorische Basis: Prozesse, Schulung, Dokumentation

Technische Maßnahmen greifen nur, wenn auch die Organisation mitzieht. Drei Dinge sind unverzichtbar:

Klare Verantwortlichkeiten

• Benenne Systemeigentümerinnen und -eigentümer pro Anwendung.
• Lege fest, wer über neue TOMs entscheidet und wer sie umsetzt.
• Definiere, wer Datenschutzvorfälle entgegennimmt und koordiniert.

Diese Rollen müssen nicht alle Vollzeit besetzt sein, aber sie sollten benannt und kommuniziert werden.

Einfache, gelebte Prozesse

TOMs scheitern oft daran, dass sie den Alltag behindern. Halte Prozesse so schlank wie möglich:

• Kurze, verständliche Richtlinien statt seitenlanger Policies.
• Prozesse, die sich in bestehende Abläufe einfügen, z. B. Onboarding-Checklisten für HR, die gleich die IT-Zugriffe mit abdecken.
• Regelmäßige Überprüfung, ob Prozesse funktionieren, etwa im Rahmen von internen Audits oder Reviews.

Schulung und Sensibilisierung

Mitarbeitende müssen verstehen, warum sie bestimmte Dinge tun oder lassen sollen:

• Kurze, praxisnahe Schulungen, keine reinen Gesetzesvorträge.
• Konkrete Beispiele aus dem eigenen Unternehmen oder aus der eigenen Branche.
• Wiederholung in sinnvollen Abständen, vor allem bei neuen Tools oder Prozessen.

Gerade in München, mit vielen kleinen und mittleren Unternehmen, ist die Mischung aus pragmatischer Technik und verständlicher Schulung entscheidend. Wenn du TOMs tiefergehend und in strukturierter Form angehen willst, findest du passende Schulungen und Workshops bei cmt.de.

Schrittweise Umsetzung statt Big Bang

TOMs technisch und organisatorisch umzusetzen ist kein Einmal-Projekt, sondern ein laufender Prozess. Sinnvoll ist ein iteratives Vorgehen:

1. Bestandsaufnahme der wichtigsten Systeme und Daten.
2. Grobe Risikoabwägung: Wo ist Vertraulichkeit, Integrität, Verfügbarkeit am kritischsten?
3. Priorisierte Maßnahmenliste mit überschaubaren Schritten.
4. Umsetzung, Dokumentation, Schulung.
5. Regelmäßige Überprüfung und Anpassung.

Wenn du das Thema so angehst, wird aus „Datenschutz“ kein abstraktes Schreckgespenst, sondern ein konkretes Bündel an Technik und Prozessen, das du Schritt für Schritt verbessern kannst. Und genau darauf zielen TOMs letztlich ab: nachvollziehbar, angemessen und wirksam.