DSGVO für die IT: Grundsätze, Fristen und technische Umsetzung

DSGVO-Grundlagen für die IT: Was zählt, was nicht, und welche technischen Maßnahmen sich daraus ergeben. Die Verordnung ist keine Bürokratieübung – sie beschreibt zu großen Teilen genau das, was gute IT-Sicherheit ohnehin tut.

Die wichtigsten Begriffe

PERSONENBEZOGENE DATEN\n  Alle Informationen, die sich auf eine identifizierte\n  oder identifizierbare natuerliche Person beziehen.\n  Auch: IP-Adresse, Geraetekennung, Standortdaten,\n  Beschaeftigtendaten, Protokolle mit Nutzerbezug.\n  NICHT personenbezogen: echte Anonymisierung\n  (Aggregate, Statistik). Pseudonymisierung ist WEITER\n  personenbezogen - nur schwerer zuzuordnen!\n\nBESONDERE KATEGORIEN (Art. 9 - erhoehter Schutz)\n  Gesundheit, Herkunft, Religion, Gewerkschaft,\n  politische Meinung, Sexualleben, biometrische und\n  genetische Daten.\n  -> Fuer die Verarbeitung braucht es eine\n     ausdrueckliche Rechtsgrundlage (meist Einwilligung).\n\nVERANTWORTLICHER (Art. 4 Nr. 7)\n  Wer ueber Zwecke und Mittel entscheidet. In der Regel\n  das eigene Unternehmen.\n\nAUFTRAGSVERARBEITER (Art. 28)\n  Wer personenbezogene Daten im Auftrag verarbeitet:\n  Cloud-Anbieter, E-Mail-Versender, Wartungspartner.\n  -> SCHRIFTLICHER Vertrag nach Art. 28 PFLICHT.\n\nBETROFFENENRECHTE\n  Auskunft (Art. 15), Berichtigung (16), Loeschung (17),\n  Einschraenkung (18), Datenuebertragbarkeit (20),\n  Widerspruch (21).\n  -> Technisch heisst das: Daten muessen auffindbar,\n     zuordenbar, aenderbar und loeschbar sein.\n     Wer in funfzig Systemen verstreut speichert,\n     kann Auskunft und Loeschung nicht erfuellen.

Die sechs Grundsätze (Art. 5)

1) RECHTMAESSIGKEIT, TREU UND GLAUBEN, TRANSPARENZ\n   Es muss eine Rechtsgrundlage geben (Vertrag,\n   Einwilligung, berechtigtes Interesse, gesetzliche\n   Pflicht), und die Betroffenen muessen informiert sein.\n\n2) ZWECKBINDUNG\n   Daten nur fuer den angegebenen Zweck.\n   "Wir koennten die Daten spaeter auch fuer X nutzen"\n   ist genau das, was verboten ist.\n\n3) DATENMINIMIERUNG\n   Nur, was fuer den Zweck erforderlich ist.\n   Technisch: keine Abfrage-Protokolle mit voller\n   Adresse, wenn eine gekuerzte reicht. Kein Geburtsdatum,\n   wenn Alter genuegt.\n   # Dies ist die wirksamste Massnahme ueberhaupt.\n   # Was nicht gespeichert wird, kann nicht abfliessen.\n\n4) RICHTIGKEIT\n   Daten aktuell halten, Fehler korrigieren koennen.\n\n5) SPEICHERBEGRENZUNG\n   Loeschfristen definieren UND DURCHSETZEN.\n   # Die Falle: Eine zugesagte Frist im Datenschutztext\n   # ohne Code, der sie umsetzt, ist eine unwahre Aussage.\n   # Fristen gehoeren in die Anwendung (geplante Aufgabe),\n   # nicht in ein Dokument.\n\n6) INTEGRITAET UND VERTRAULICHKEIT\n   Angemessene Sicherheit: Verschluesselung,\n   Zugriffsbeschraenkung, Belastbarkeit, Wiederherstellbarkeit.\n   # Hier treffen sich Datenschutz und IT-Sicherheit vollstaendig.

Technische Maßnahmen in der Praxis

# 1) LOESCHFRISTEN IM CODE DURCHSETZEN\n#    Der haeufigste Mangel: Im Datenschutztext steht\n#    "Protokolle werden nach 90 Tagen geloescht" -\n#    im Code gibt es nichts, was das tut.\n\ndef log_schreiben(eintrag):\n    '''Schreibt ein Protokoll und raeumt Altdaten auf.'''\n    db.insert("logins", eintrag)\n    # Beim Schreiben aufraeumen - kein Zeitgeber noetig\n    try:\n        db.delete_where("logins",\n                        "created_at < %s",\n                        [zeitpunkt_vor_tagen(90)])\n    except Exception as fehler:\n        # Aufraeumen darf das Schreiben nicht verhindern,\n        # aber der Fehler muss sichtbar werden!\n        melde(f"Aufraeumen fehlgeschlagen: {fehler}")\n\n#   WICHTIG: Bei MEHREREN zugesagten Fristen jede einzeln\n#   umsetzen und einmal mit eingefuegten Alt-Zeilen nachweisen.\n\n# 2) DATENMINIMIERUNG IN PROTOKOLLEN\n#    IP-Adressen: letzte Stelle abschneiden, wenn der\n#    genaue Wert nicht gebraucht wird\ndef kuerze_ip(ip):\n    if "." in ip:\n        return ".".join(ip.split(".")[:3] + ["0"])   # IPv4\n    return ":".join(ip.split(":")[:4] + ["0"] * 4)    # IPv6\n#   Immer vorher fragen: Brauchen wir die genaue Adresse\n#   (Fehlersuche, Missbrauchsabwehr) oder genuegt das Netz?\n#   Fuer die Missbrauchsabwehr gibt es die Rechtsgrundlage\n#   (Art. 6 Abs. 1 lit. f) - aber dann mit Frist!\n\n# 3) VERSCHLUESSELUNG\n#    - Uebertragung: TLS 1.2+, ueberall (auch intern!)\n#    - Speicher: Festplattenverschluesselung, bei\n#      personenbezogenen Daten in der Datenbank auch\n#      spaltenweise (z. B. Kontaktdaten)\n#    - Schluesselverwaltung: Wo liegen die Schluessel?\n#      Wenn sie neben den Daten liegen, ist die\n#      Verschluesselung wirkungslos.\n\n# 4) ZUGRIFF NACH ROLLEN (nicht "alle duerfen alles")\n#    Technisch: Datenbankbenutzer je Anwendung (nicht je\n#    Entwickler!), minimale Rechte je Tabelle.\n#    Kein Zugriff auf Produktionsdaten aus dem\n#    Entwicklungsnetz.\n\n# 5) NACHWEIS DER EINWILLIGUNG (Art. 7 Abs. 1)\n#    Zeitstempel + Textfassung in der Datenbank:\n#      dsgvo_akzeptiert_at, dsgvo_version\n#    Checkbox-Feldname passend waehlen (dsgvo, nicht agb),\n#    serverseitig pruefen (nicht nur im Browser!).\n#    Der Versionsstring zentral in einer Funktion - sonst\n#    laufen Anzeige und gespeicherter Nachweis auseinander.\n\n# 6) AUFTRAGSVERARBEITUNG NACHWEISEN\n#    Liste ALLER Dienstleister mit Zugriff auf\n#    personenbezogene Daten:\n#      Cloud-Anbieter, Mailversender, Statistik,\n#      Ticketsystem, Buchhaltung, Wartung\n#    Je Dienstleister: Vertrag nach Art. 28 vorhanden?\n#    Wo werden die Daten verarbeitet (Land)?\n#    # Ein fehlender Vertrag ist einer der haeufigsten\n#    # und einfachsten Befunde bei Pruefungen.\n\n# 7) AUSKUNFT UND LOESCHUNG TECHNISCH ERMOEGLICHEN\n#    Zentrale Zuordnung: Welche Daten gehoeren zu\n#    welcher Person? Ueber alle Systeme hinweg.\n#    # Ohne das ist eine Auskunft nach Art. 15 ein\n#    # mehrtaegiges Handprojekt - und wird deshalb\n#    # unvollstaendig beantwortet.

Meldepflicht bei Datenschutzverletzungen

Frist: 72 STUNDEN nach Bekanntwerden.\n\nWann melden?\n  - Wenn personenbezogene Daten abgeflossen, verloren,\n    veraendert oder unerlaubt offengelegt wurden\n  - Meldung an die Aufsichtsbehoerde (Art. 33)\n  - ZUSAETZLICH an die Betroffenen bei hohem Risiko (Art. 34)\n\nAusnahmen (Art. 33 Abs. 1): Wenn kein Risiko entstehen\n  kann - zum Beispiel bei einem verschluesselten\n  Datentraeger, dessen Schluessel nicht betroffen ist.\n  # Aber: Die Verletzung muss INTERN dokumentiert werden\n  # (Art. 33 Abs. 5) - auch wenn nicht gemeldet wird!\n\nWichtig fuer den Ernstfall:\n  1) Die Meldung braucht KEINE vollstaendige Aufklaerung.\n     Eine Erstmeldung mit dem bekannten Stand genuegt\n     und kann ergaenzt werden.\n  2) Die Frist ist hart. Eine verspaetete Meldung ist\n     ein eigenes Vergehen.\n  3) Vorlage vorbereiten, damit im Stress nur noch\n     eingesetzt werden muss.\n  4) Nachweis, WER wann was wusste (Dokumentation!).\n\nTypische Datenschutzverletzungen im IT-Betrieb:\n  - Fehlkonfigurierter Speicher (S3-Bucket, Backup-Verzeichnis)\n  - Offene Datenbank im Internet\n  - Protokolle mit Kennwoertern und personenbezogenen Daten\n  - Verlorener Laptop ohne Festplattenverschluesselung\n  - Mail an den falschen Empfaenger (BCC-Fehler)\n  - Falsch gesetzte Berechtigungen (jeder darf alles)\n  - Zugangsdaten im Git-Repository (oeffentlich!)\n  # Diese Liste ist die Pruefliste: Alle Punkte\n  # durchgehen und abhaken. Kein aufwaendiges Audit noetig.

Prüfliste

Gibt es eine Liste aller Verarbeitungen (Zweck, Rechtsgrundlage, Frist, Empfänger)?
Sind alle Dienstleister mit Datenzugriff erfasst – und Verträge nach Art. 28 vorhanden?
Sind Löschfristen definiert und im Code umgesetzt?
Ist die Einwilligung mit Zeitstempel und Textfassung nachweisbar?
Ist die Übertragung überall verschlüsselt (auch intern)?
Sind Datenbank-Konten auf minimale Rechte beschränkt?
Werden IP-Adressen in Protokollen gekürzt, wenn nicht nötig?
Ist eine Auskunft technisch in kurzer Zeit möglich?
Gibt es eine vorbereitete Meldung für den Ernstfall (72 Stunden)?
Sind Checks auf offene Speicher und Datenbanken automatisiert?
Sind Zugangsdaten nachweislich nicht in Repositories?

Häufige Fehler

Fristen als Text ohne Code. Eine zugesagte Löschfrist, die nicht durchgesetzt wird, ist eine unwahre Aussage gegenüber Betroffenen.
Fehlende Auftragsverarbeitungsverträge. Der häufigste und einfachste Befund. Jeder Dienstleister mit Datenzugriff braucht einen.
Einwilligung nur im Browser geprüft. Serverseitig erzwingen, sonst Konto ohne Einwilligung.
IP-Adressen vollständig und unbegrenzt. Protokolle wachsen ohne Frist; wer die genaue Adresse nutzt, braucht Rechtsgrundlage und Löschfrist.
Produktionsdaten in Entwicklung oder Test. Personenbezug fehlt dort fast immer. Anonymisieren oder synthetische Daten.
„Anonymisiert“ statt pseudonymisiert. Eine Kennnummer plus Zuordnungstabelle ist weiterhin personenbezogen – mit allen Pflichten.
Meldung zu spät. 72 Stunden sind hart und brauchen keine vollständige Aufklärung, nur eine Erstmeldung.
Kein internes Verzeichnis der Verletzungen. Auch nicht gemeldete Vorfälle müssen dokumentiert werden.
Zugangsdaten in Repositories. Auch wenn sie später entfernt werden: Der Verlauf bleibt. Sofort wechseln, nicht nur löschen.

Verwandte Grundlagen: ISO 27001, NIS2, Threat Modeling, Vorfallbehandlung.