Datenschutz-Folgenabschätzung (DSFA): wann sie für Sozialträger Pflicht ist

Neue Fachsoftware, KI-Funktionen, digitale Falldoku – und irgendwann sagt der Datenschutzbeauftragte den Satz: „Dafür braucht ihr eine DSFA." Viele Leitungen hören das zum ersten Mal und ahnen ein Bürokratie-Monster. Zu Unrecht: Eine Datenschutz-Folgenabschätzung ist ein strukturiertes Nachdenken über Risiken, auf zehn bis zwanzig Seiten. Hier steht, wann sie Pflicht ist und wie ihr sie ohne Drama hinbekommt.

Stand: Juli 2026. Grundlage: Art. 35, 36 DSGVO, Kriterienkatalog der europäischen Aufsichtsbehörden (WP 248) und die „Muss-Listen" der deutschen Aufsichtsbehörden. Fachliche Orientierung, keine Rechtsberatung – bezieht eure:n Datenschutzbeauftragte:n ein.

Warum gerade soziale Träger betroffen sind

Die DSFA nach Art. 35 DSGVO ist Pflicht, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Betroffenen mit sich bringt. Und jetzt die unbequeme Wahrheit: Falldaten sozialer Träger sind fast immer Gesundheits- und Sozialdaten, also besondere Kategorien nach Art. 9 DSGVO. Die Betroffenen sind Kinder, Jugendliche und Menschen in belastenden Lebenslagen – genau die „schutzbedürftigen Personen", die der Kriterienkatalog der Aufsichtsbehörden ausdrücklich nennt. Wo andere Branchen lange rechnen müssen, ob ein hohes Risiko vorliegt, seid ihr schnell mittendrin.

Wann ist die DSFA Pflicht?

Drei Wege führen zur Pflicht:

• Regelbeispiele des Gesetzes (Art. 35 Abs. 3): darunter die umfangreiche Verarbeitung besonderer Kategorien – bei einer Fachsoftware, die Falldaten vieler Klient:innen bündelt, liegt das nahe.
• Muss-Listen der Aufsichtsbehörden: Die deutschen Behörden veröffentlichen Listen von Verarbeitungen, für die eine DSFA verpflichtend ist. Umfangreiche Verarbeitung von Gesundheits- und Sozialdaten taucht dort auf.
• Kriterien-Check (WP 248): Neun Kriterien, darunter sensible Daten, schutzbedürftige Betroffene, große Datenmengen, Datenabgleich, neue Technologien. Faustregel der Behörden: Treffen zwei oder mehr Kriterien zu, ist in der Regel eine DSFA fällig. Sensible Daten plus schutzbedürftige Betroffene – bei euch sind zwei Kriterien fast immer erfüllt.

Typische Anlässe in der Praxis: die Einführung oder der Wechsel einer Fachsoftware für Klientenakte und Doku, der Einsatz von KI mit Personenbezug, neue umfangreiche Auswertungen über viele Fälle hinweg, oder der Umstieg von Papier auf ein digitales System.

Erst die Schwellwertanalyse – und zwar schriftlich

Vor der eigentlichen DSFA steht die Schwellwertanalyse: eine kurze, dokumentierte Prüfung, ob eine DSFA nötig ist. Der unterschätzte Punkt: Auch wenn das Ergebnis „keine DSFA erforderlich" lautet, muss die Begründung schriftlich vorliegen. „Haben wir uns nie gefragt" ist gegenüber der Aufsichtsbehörde die schlechteste aller Antworten. Eine Seite reicht.

Was in die DSFA gehört

Art. 35 Abs. 7 DSGVO gibt vier Pflichtbestandteile vor:

1. Systematische Beschreibung der Verarbeitung: Zwecke, Betroffene, Datenkategorien, Datenflüsse, Speicherfristen, eingesetzte Technik.
2. Bewertung von Notwendigkeit und Verhältnismäßigkeit: Warum braucht ihr diese Daten, gibt es mildere Mittel, was sind die Rechtsgrundlagen (DSGVO plus Sozialdatenschutz nach SGB I, VIII, X)?
3. Risikobewertung: Was kann schiefgehen – vom verlorenen Diensthandy über Fehlberechtigungen bis zum Ransomware-Angriff – und wie wahrscheinlich und wie schwer wäre das für die Betroffenen? Eine Risikomatrix (Eintrittswahrscheinlichkeit × Schwere) macht das handhabbar.
4. Abhilfemaßnahmen: die technischen und organisatorischen Maßnahmen, die jedes Risiko auf ein vertretbares Maß drücken – mit Verantwortlichkeit und Termin.

Der Ablauf in sechs Schritten

1. Anlass festhalten und Team klären: Die Verantwortung liegt beim Träger (der Leitung), nicht beim DSB. Der DSB berät – sein Rat ist nach Art. 35 Abs. 2 einzuholen und zu dokumentieren.
2. Verarbeitung beschreiben: Wer sich hier präzise macht, hat die halbe DSFA. Den technischen Teil (Hosting, Verschlüsselung, Subdienstleister) liefert der Software-Anbieter zu – danach fragen, das ist seine Pflicht aus dem Auftragsverarbeitungsvertrag.
3. Rechtsgrundlagen und Erforderlichkeit begründen.
4. Risiken bewerten: im Team, nicht allein am Schreibtisch – die Fachkräfte kennen die echten Schwachstellen des Alltags.
5. Maßnahmen festlegen und mit den Risiken verknüpfen – vieles davon habt ihr schon (Rollenkonzept, Backups, Schulungen), es war nur nie aufgeschrieben. Die Übersicht dazu liefert eure TOM-Dokumentation.
6. Restrisiko bewerten, freigeben, Review planen: Leitung und DSB zeichnen ab. Bleibt trotz Maßnahmen ein hohes Restrisiko, ist vor dem Start die Aufsichtsbehörde zu konsultieren (Art. 36 DSGVO) – bei einer sauber abgesicherten Fachsoftware-Einführung ist das die seltene Ausnahme, nicht der Normalfall.

Die drei häufigsten Fehler

• Zu spät: Die DSFA gehört vor den Produktivstart, nicht ein Jahr danach als Feigenblatt. Der beste Zeitpunkt: sobald die Software-Entscheidung konkret wird.
• Mit dem VVT verwechselt: Das Verzeichnis von Verarbeitungstätigkeiten ist die Inventarliste aller Verarbeitungen; die DSFA ist die Tiefenprüfung einer einzelnen riskanten Verarbeitung. Ihr braucht beides, und sie verweisen aufeinander.
• Einmal und nie wieder: Neue Module, neue KI-Funktionen, geänderte Datenflüsse – die DSFA hat Review-Anlässe und einen Turnus. Ein kurzer jährlicher Blick reicht oft, aber er muss stattfinden und dokumentiert sein.

Weiterlesen

• Verzeichnis von Verarbeitungstätigkeiten (VVT): das Muster für Träger
• TOM nach Art. 32 DSGVO: die Vorlage für soziale Träger
• KI & Datenschutz in der Sozialen Arbeit
• DSGVO-konforme Dokumentation & Löschkonzept

Stand: 15. Juli 2026. Dieser Artikel ist eine fachliche Orientierung und keine Rechtsberatung. Maßgeblich sind DSGVO, BDSG, die Sozialgesetzbücher und die Positionen eurer Aufsichtsbehörde; im Zweifel Datenschutzbeauftragte:n einbeziehen.