Datenpanne im sozialen Träger: was in den 72 Stunden zu tun ist

Nils Rieter · Gründer von Lotsana, IT-Unternehmer aus dem Raum Köln. Baut Fachsoftware für ambulante soziale Dienste und schreibt hier über die Praxis dahinter.

Freitag, 16:40 Uhr: Eine Fachkraft ruft an – das Diensthandy mit der Falldoku-App liegt nicht mehr in der Jackentasche, zuletzt gesehen in der Bahn. Ab jetzt läuft eine Uhr, von der viele Träger nicht wissen, dass es sie gibt: 72 Stunden bis zur Meldung an die Aufsichtsbehörde. Auch übers Wochenende. Wer den Ablauf einmal durchdacht hat, bleibt handlungsfähig statt kopflos.

Stand: Juli 2026. Grundlage: Art. 4 Nr. 12, Art. 33, 34 DSGVO. Fachliche Orientierung, keine Rechtsberatung – im Ernstfall Datenschutzbeauftragte:n einbeziehen.

Was überhaupt eine „Datenpanne" ist

Juristisch: eine „Verletzung des Schutzes personenbezogener Daten" – wenn Daten unbefugt offengelegt, verändert, vernichtet werden oder verloren gehen. Wichtig: Auch der Verlust des Zugriffs zählt (etwa nach einem Ransomware-Angriff), nicht nur das Abfließen von Daten. Die Klassiker aus dem Träger-Alltag:

Diensthandy oder Laptop verloren oder gestohlen
Entwicklungsbericht an den falschen Empfänger gemailt oder gefaxt
Rundmail an Familien mit allen Adressen im offenen CC
Einbruch ins Büro, Papierakten weg
Ransomware oder gehacktes E-Mail-Konto
Ex-Mitarbeiter:in hat noch Zugriff aufs System
Papiermappe im Auto oder in der Bahn liegen geblieben

Die Drei-Stufen-Logik: dokumentieren, melden, benachrichtigen

Immer: intern dokumentieren (Art. 33 Abs. 5). Jede Verletzung kommt ins interne Verzeichnis – auch die, die ihr nicht meldet, samt Begründung. Diese Liste ist eure Absicherung: Sie beweist, dass ihr den Fall geprüft habt.
Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33 Abs. 1) – außer die Verletzung führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Ehrlich gesagt: Bei Sozial- und Gesundheitsdaten von Kindern und Klient:innen ist „kein Risiko" selten begründbar. Für euch gilt daher praktisch: im Zweifel melden.
Benachrichtigung der Betroffenen (Art. 34) – nur bei hohem Risiko, unverzüglich und in klarer Sprache. Entfallen kann sie insbesondere, wenn die Daten für Dritte unbrauchbar waren – Stichwort Verschlüsselung (dazu gleich).

Die 72 Stunden richtig verstehen

Die Frist läuft ab Kenntnis – ab dem Moment, in dem irgendjemand bei euch die Panne bemerkt. Deshalb muss jede Fachkraft wissen, dass sie Vorfälle sofort intern melden muss, nicht erst am Montag im Team.
Wochenenden und Feiertage zählen mit.
Ihr müsst nach 72 Stunden nicht alles wissen: Die DSGVO erlaubt ausdrücklich eine Meldung in Etappen – erst das Grobe, Details nachreichen. Eine verspätete Meldung braucht eine Begründung.
Gemeldet wird bei der Aufsichtsbehörde eures Bundeslands, praktisch immer über deren Online-Formular. Inhalt: Art der Verletzung, betroffene Personen- und Datenkategorien mit ungefährer Zahl, Kontakt (DSB), voraussichtliche Folgen, ergriffene Maßnahmen.
Euer Software-Anbieter ist als Auftragsverarbeiter verpflichtet, Vorfälle unverzüglich euch zu melden – die Meldung an die Behörde bleibt eure Aufgabe. Das steht (hoffentlich) in eurem AVV.

Warum Verschlüsselung euch den Abend rettet

Zurück zum verlorenen Handy: Ist das Gerät verschlüsselt, mit Bildschirmsperre gesichert, liegen die Falldaten nicht lokal, sondern in der Cloud-Anwendung, und könnt ihr den Zugang aus der Ferne sperren – dann sinkt das Risiko für die Betroffenen drastisch. Aus „Katastrophe" wird „beherrschbarer Vorfall", unter Umständen entfällt die Benachrichtigung der Familien, und die Meldung an die Behörde fällt unaufgeregt aus. Genau diese Maßnahmen gehören in eure TOM-Dokumentation – vor dem Vorfall, nicht danach.

Der 5-Schritte-Notfallplan (heute aufschreiben, nie brauchen)

Interner Meldeweg: Jede:r meldet Vorfälle sofort an eine benannte Stelle (Leitung + DSB), auch abends, auch am Wochenende. Telefonnummern ins Team-Board.
Eindämmen: Zugang sperren, Passwörter ändern, Gerät fernlöschen, Empfänger der Fehl-Mail um Löschung bitten (und das dokumentieren).
Bewerten: Welche Daten, wie viele Betroffene, welches Risiko? Mit DSB, kurz und schriftlich.
Melden: Behörden-Formular ausfüllen (72h!), bei hohem Risiko Betroffene klar und ehrlich informieren.
Nacharbeiten: Vorfall ins Verzeichnis, Ursache abstellen, TOM und Schulung anpassen. Eine Panne, aus der man lernt, ist der Aufsichtsbehörde lieber als ein makelloses Papier-Deckblatt.

Und die wichtigste Botschaft an euer Team: Wer eine Panne meldet, wird nicht bestraft. Vertuschte Vorfälle sind das eigentliche Risiko – rechtlich (die unterlassene Meldung ist bußgeldbewehrt) und menschlich. Eine offene Fehlerkultur ist hier keine Sozialromantik, sondern Compliance.

Das beste Pannen-Management ist das, das seltener gebraucht wird: keine lokalen Falldaten auf Geräten, Zwei-Faktor-Anmeldung, Rollen & Rechte, Audit-Log und sofort entziehbare Zugänge – bei Lotsana Standard, Hosting in Deutschland. Für die Risiko-Vorarbeit: das kostenlose DSFA-Muster mit Risikomatrix.

Weiterlesen

Stand: 15. Juli 2026. Dieser Artikel ist eine fachliche Orientierung und keine Rechtsberatung. Ob und wie zu melden ist, entscheidet sich am Einzelfall – bezieht eure:n Datenschutzbeauftragte:n ein.