DSFA — Entwicklerteil

Stand: 2026-08-17 · Sprache: Deutsch · Stil: sachlich-juristisches Präsens/Passiv nach der Stilanalyse in dsfa-analyse-dokument.md, Abschnitt 3.

Dieses Verzeichnis enthält die Kapitel der Datenschutz-Folgenabschätzung (DSFA), die wir als Entwicklungsteam verantworten können, weil sie aus Quellcode, Konfiguration und Architekturentscheidungen ableitbar sind. Die organisatorischen und juristischen Kapitel des Betreibers sind nicht ausformuliert, sondern als vorausgefüllte Entwürfe beigelegt.

Kapitelnummerierung folgt dem Original (DCV-DSFA vom 29.01.2026), damit Querverweise und Zitierfähigkeit erhalten bleiben.

Was hier liegt

Was hier bewusst NICHT liegt

Kapitel 1 (Stammdaten), 3 (Kennzahlen), 4 (Akteure/Governance), 5 (Verantwortlichkeit), 8.1 (Identitätsprüfung), 8.2 (anonyme Nutzung), 8.3 (Informationswege), 8.11 (Eskalationskette), 9 (Verhältnismäßigkeit) sowie die Anlagen 1 (Risikoanalyse) und 2 (Löschkonzept). Kapitel 1 und 3 kommen aus den Global Settings bzw. aus aggregierten Statistiken; die übrigen sind betreiberspezifisch — für sechs von ihnen liegen Entwürfe in vorlagen-betreiber.md.

Drei Regeln, nach denen diese Texte geschrieben sind

1. Was nicht live ist, wird nicht als vorhanden beschrieben. Der Medien-Prüf-Proxy ist Zielarchitektur, kein Ist-Zustand. Die Terminverwaltung ist eine Architekturentscheidung, kein Feature. Statistik-Ereignisse, Push-Benachrichtigungen und das geparkte Gerät sind im Auslieferungsstand abgeschaltet. Der status-Schlüssel in evidence-map.yaml trägt diese Unterscheidung maschinenlesbar.
2. Risiko benennen, Kompensation sofort nachschieben. Jede offen benannte Schwäche steht zusammen mit der vorhandenen Gegenmaßnahme oder mit der Feststellung, dass eine solche fehlt und als Maßnahme geführt wird.
3. Grenzen ehrlich benennen. Die Formulierungen „beinahe unmöglich", „nicht haltbar", „darf nicht behauptet werden" sind Absicht, kein Versehen. Eine DSFA, die eine unvollständige Löschung als vollständig beschreibt oder ein bedingtes Verschlüsselungsversprechen als unbedingtes, verliert ihren Zweck.

Quellenzuordnung — welcher Abschnitt stützt sich worauf

Alle Quellen liegen in 0 - Docs/artifacts/dsfa-2026-08-13/.

Bewusst nicht geschriebene Aussagen

Diese Behauptungen ließen sich aus der Faktenbasis nicht belegen und wurden deshalb weggelassen oder ausdrücklich als offen markiert:

• Passwort-Hashverfahren und Passwortrichtlinie. Das Original nannte BCrypt und eine Mindestlänge von neun Zeichen. Für ORISO ist beides aus den Repositorien nicht belegbar; die Realm-Dateien sind nachweislich nicht autoritativ. Formuliert wurde nur „gesalzene Hashwerte" plus ausdrücklicher Nachweisvorbehalt.
• Rate-Limiting am Anmeldevorgang. Nicht behauptet — der versionierte Realm-Stand zeigt deaktivierten Brute-Force-Schutz.
• „IP-Adressen werden zu keiner Zeit mitgeschrieben". Diese Aussage des Originals ist für ORISO nachweislich unzutreffend und wird nicht übernommen (Abschnitt 6.6).
• Externes Audit der Krypto-Implementierung. Kursiert in älteren Entwürfen; in der Faktenbasis nicht belegt, daher gestrichen.
• Konkrete Kennzahlen (Anzahl Ratsuchender, Beratungsstellen, Beratende, E-Mail-Opt-in-Quote) — betreiberseitig aus aggregierten Statistiken zu ergänzen, Kapitel 3.
• Konkrete Löschfristen je Datenkategorie — gehören ins Löschkonzept (Anlage 2), das noch nicht existiert. Kapitel 6 und 8 verweisen darauf, statt Fristen zu erfinden.
• Datenschutzklassen I–III. Das Klassifikationsschema des Originals wurde nicht übernommen, weil seine Herkunft und Definition in der Faktenbasis nicht dokumentiert sind.
• Antwortfristen (SLA) für Erstanfragen. Betreiber- bzw. trägerspezifisch, nicht technisch.

Offene Punkte für die juristische Prüfung

Vier Einordnungen sollten von der Datenschutzbeauftragung bestätigt oder korrigiert werden, bevor das Dokument freigegeben wird:

1. Rechtsgrundlage der Team-Besprechung (Abschnitt 7.1 Nr. 8): Hier wird über eine ratsuchende Person gesprochen, ohne dass sie es erfährt und ohne Widerspruchsmöglichkeit. Der Entwurf stützt das auf berechtigtes Interesse — vertretbar, aber begründungsbedürftig, weil Beratungsinhalte betroffen sein können.
2. Anonyme Nutzung und Anwendungsbereich (Abschnitt 7.2 Absatz 5): Die Übernahme der Original-Argumentation („Anwendungsbereich nicht eröffnet") setzt voraus, dass wirklich keine personenbezogenen Daten anfallen. Metadaten wie Sitzungsdauer und Zeitpunkt fallen jedoch an.
3. Beschäftigtendatenschutz (Abschnitt 7.3): Nachrichtenzähler und der Übergabegrund „Fachkraft erkrankt" berühren Leistungs- und Gesundheitsdaten Beschäftigter; die Mitbestimmungspflicht ist zu klären.
4. Statistikereignisse mit Quasi-Identifikator-Set (Abschnitt 6.15): Die Bewertung „im Auslieferungsstand abgeschaltet, daher nicht Ist-Zustand" ist technisch korrekt; ob das ausreicht oder ob der Code-Pfad zu entfernen ist, ist eine juristische Bewertung.