Internes Arbeitsdokument. Dieses Dokument ist eine Zuarbeit zur Datenschutz-Folgenabschätzung und kein freigegebenes Ergebnis. Es kann Zwischenstände, offene Fragen und Formulierungen enthalten, die so nicht in die DSFA übernommen werden. Lokale Dateipfade des Autors wurden vor der Veröffentlichung entfernt.
Quelle: [lokaler Pfad entfernt] Ablagen/dreambau.com/03 - ORISO CC/2026-01-29_DSFA_BlendedCounseling_DCV.pdf (37 Seiten, vollständig gelesen)
Zweck dieser Analyse: Vorlage für eine dynamisch generierte, versionierte HTML-DSFA im ORISO-Docs-Repo (mit PDF-Download), bei der Stammdaten aus den Global Settings des Admin-Panels des jeweiligen Plattformbetreibers kommen.
| Nr. | Kapitel | Seite(n) | Inhalt (1–2 Sätze) | Typ |
|---|---|---|---|---|
| — | Titelseite | 1 | Titel „Datenschutz-Folgenabschätzung zur Online-Beratung Blended Counseling", Caritas-Logo rechts oben, Herausgeberblock unten links (DCV e.V., Referat Online-Beratung, Dirk Markfort als Referatsleiter), Datum rechts unten: 29.01.2026. | Deckblatt (Logo + Formularfelder) |
| 1 | Einleitung und Scope | 2 | Plattform ist Angebot der Caritas; Verarbeitung in gemeinsamer Verantwortlichkeit mit Kooperationsmitgliedern und Trägern. Scope der DSFA ist NUR die Verarbeitung durch den DCV (Bereitstellung + technischer Betrieb). | Fließtext |
| 1.1 | Verantwortlicher | 2 | Vier Zeilen: Verantwortlicher (DCV e.V.), Adresse (Karlstraße 40, 79104 Freiburg), Kontaktdaten (info@caritas.de, 0761 200-0), Name des DSB (Dr. Sebastian Ertel, datenschutz nord GmbH). | Tabelle (Key-Value) |
| 1.2 | Anlagen bzw. Verweise | 2 | Anlage 1 = Risikoanalyse, Anlage 2 = Löschkonzept. | Tabelle (Nummer/Bezeichnung) |
| 1.3 | Wiederholung | 2 | Erneute Prüfung zum bestimmten Zeitpunkt; nächste routinemäßige Überprüfung: 31.01.2027. Darunter eine LEERE Tabelle für künftige Überprüfungen (Datum / wesentliche Ergebnisse / [Spalte ohne Kopf] / Bearbeiter). | Fließtext + leere Verlaufs-Tabelle (Formularfeld) |
| 2 | Schwellwertanalyse | 2–4 | Prüfung der DSFA-Pflicht gemäß § 35 KDG: black list (Nein), Sachverhalte § 35 Abs. 4 KDG (Ja), 10 Prüffragen mit Checkboxen (3× Ja), Ergebnis-Absatz. | Checkliste (☒/☐) + Fließtext |
| 2 | — Ergebnis | 4 | DSFA ist durchzuführen: besondere Kategorien nach § 11 KDG zu erwarten, ~137.000 registrierte Ratsuchende (Stand Feb 2024), mehrere Verantwortliche → hohes Risiko. | Fließtext |
| 3 | Hintergrund | 5 | Blended-Counseling-Konzept (online + vor Ort, „sowohl als auch"); Leistungsspektrum (Nachrichten/Dokumente, Gruppenchats, Peer-Beratung, Video-Call, Live-1:1-Chat); Kennzahlen: ~20 Fachbereiche, 1.582 Beratungsstellen, 3.420 aktive Beratende (Ende 2025), ~137.000 Ratsuchende (Feb 2024); Zugang browserbasiert. | Fließtext |
| 4 | Akteure und betroffene Personen | 5 | Überschrift, Einstieg in die Akteursbeschreibung. | Fließtext |
| 4.1 | Kooperation Blended Counseling | 5–6 | Gründung März 2019, nicht rechtsfähige Kooperation, Kooperationsvertrag, Neufassung 12.10.2023; Zusammensetzung als Grafik (27 Diözesan-CV, 7 Fachverbände, 1 Landesverband Oldenburg, DCV); jährliche Partnerversammlung. | Fließtext + eingebettete Grafik (einzige Abbildung des Dokuments) |
| 4.2 | Der Lenkungsausschuss | 6–7 | Zentrales Steuerungsgremium (§§ 5 ff. Kooperationsvereinbarung); Zusammensetzung 2+4+2+4 Vertreter:innen; Entsendungsprinzip bindet Träger ein. | Fließtext + Aufzählung |
| 4.3 | Deutscher Caritasverband | 7 | DCV = Spitzenverband, Geschäftsführung der Kooperation, zentrale Bereitstellung/(Weiter-)Entwicklung/Betrieb nach Weisung des Lenkungsausschusses. | Fließtext |
| 4.4 | Diözesan- und Ortscaritasverbände | 7 | Rechtlich selbstständige Vereine/Körperschaften, teils selbst Träger von Beratungsstellen. | Fließtext |
| 4.5 | Beratungsstellen und Beratende | 7 | Träger/Beratungsstellen sind eigenständige Organisationen; Beratung je Fachbereich getrennt; jeder Fachbereich einer Beratungsstelle = eigene Online-Beratungsstelle. Beratende i. d. R. hauptamtlich; Ausnahmen: [U25]-Peer-Beratung, Kreuzbund, Trauerbegleitung (ehrenamtlich). | Fließtext |
| 4.6 | Ratsuchende | 8 | Anonyme Nutzung möglich, Benutzername frei wählbar; Pflichtangaben nur PLZ bzw. bei [U25] Bundesland + Alter (unverifiziert); weitere Daten optional. | Fließtext |
| 4.7 | Fachverbände | 8 | Bundesweit tätige Fachverbände; Nutzung der Plattform je nach Verbandsstruktur (eigene Angebote oder Koordination). | Fließtext |
| 4.8 | Fachbeiräte, Steuerkreis, Arbeits-/Begleitgruppe | 8–9 | Fachbeirat Datenschutz als beratendes Expertisegremium; Fachbeirat IT-Entwicklung existiert aktuell nicht — stattdessen „Steuerkreis Technische Entwicklung" (Hintergrund: laufendes Refactoring-Projekt Anfang 2026); Arbeits-/Begleitgruppe mit Aufgaben-Aufzählung. | Fließtext + Aufzählung |
| 5 | Verantwortlichkeit | 9 | Gemeinsame Verantwortlichkeit nach § 28 Abs. 1 S. 1 KDG: Partner + Träger + DCV entscheiden gemeinsam via Lenkungsausschuss über Zwecke und Mittel. | Fließtext |
| 5.1 | Rolle und Aufgabe des Lenkungsausschusses | 9 | Zentrales Entscheidungsorgan; Budget, Grundsatzentscheidungen; Bevollmächtigung durch Kooperationspartner; überwacht den DCV; DCV berichtet mindestens halbjährlich. | Fließtext |
| 5.2 | Rolle des DCV | 10 | Geschäftsführung, operative Umsetzung, Beauftragung von Dienstleistern, Budgetkontrolle, Fachreferat übernimmt laufenden Betrieb. | Fließtext |
| 5.3 | Rolle der Beratungsstellen / Träger | 10 | Träger bleiben verantwortlich für die fachliche Beratung insgesamt, inkl. Dokumentation außerhalb der Plattform. | Fließtext |
| 5.4 | Zuteilung und Festlegung bei der Erfüllung der KDG-Pflichten | 10–11 | Vereinbarung über gemeinsame Verantwortlichkeit nach § 28 Abs. 1 S. 2 KDG; Zwecke/Mittel/Zuteilung in Anlagen 2–4 der Vereinbarung; enthaltener AV-Vertrag greift derzeit nicht (keine Auswertung der Beratungsdaten durch DCV). | Fließtext |
| 5.5 | Auftragsverarbeiter/Weitere Akteure | 11 | Zwei Auftragsverarbeiter: neusta integrate GmbH (ehemals Open 4 Business GmbH; Server-Hosting) und Virtual Identity AG (Entwickler, Support, Wartung, Verwaltung Beratenden-Accounts). Kein Zugriff auf Inhaltsdaten dank E2EE. | Fließtext |
| 6 | Verfahren | 11 | Kapitelauftakt. | Fließtext |
| 6.1 | Zweck | 11 | Bereitstellung + Betrieb einer Online-Beratungsplattform nach den Leitbildern der Caritas. | Fließtext (1 Absatz) |
| 6.2 | Beratungsarten | 11 | Auswahl Beratungsbereich → Registrierung → Erstanfrage; Antwortfrist 48 h Mo–Fr, Schwangerschaftsberatung 24 h; Profil/Passwort selbst änderbar. | Fließtext |
| 6.2.1 | 1:1 Chat | 11–13 | Synchron + asynchron für Registrierte; Erstnachricht-Flow mit Info-E-Mail (enthält nur PLZ); zwei Beratungsstellentypen: Standard/Regel (feste 1:1-Zuordnung, Übertragung nur mit Pop-up-Zustimmung des Ratsuchenden) und Teamberatungsstelle (n:1, alle Beratenden sehen Fälle, Ordner „Meine/Team Beratungen"); Datei-Austausch verschlüsselt; „Archivieren" = nur Ordner, keine echte Archivierung. | Fließtext + 2-Punkte-Aufzählung |
| 6.2.2 | Live-1:1 Chat für nicht registrierte Ratsuchende | 13 | Ohne Registrierung (Stand Jan 2026 nur Schwangerschaftsberatung); Datenschutz-Einstiegsseite, virtueller Warteraum, generierter Benutzername („Ratsuchende_r 01"); nach Verlassen für Ratsuchende zu, Beratende sehen Inhalte noch bis 6 h, dann Label „done" (Löschfristberechnung). | Fließtext |
| 6.2.3 | Gruppenchat (n:n Beratung) | 13–14 | Exklusiv Kreuzbund e.V. (Selbsthilfe); Registrierungspflicht; Moderatorenrollen (dürfen Teilnehmende entfernen, Chatangebote erstellen: Thema, Datum, Uhrzeit, einmalig/Turnus); nach Chat-Ende werden sämtliche Daten gelöscht. | Fließtext |
| 6.2.4 | Video-Call (n:n Beratung) | 14 | Jitsi; Start nur durch Beratende; Teilnahme ohne Registrierung per Link möglich (Dolmetscher, Angehörige); vorgeschalteter Warteraum + aktives Einlassen; Mikro/Kamera-Vorschaltseite; keine Aufzeichnung/Speicherung/Protokollierung; Raum wird dauerhaft gelöscht, wenn alle gehen; Ablehnungs-Hinweisnachricht im Verlauf. | Fließtext |
| 6.3 | Beschreibung der Datenverarbeitung | 14 | Kapitelauftakt. | Fließtext |
| 6.3.1 | Datenverarbeitung im Rahmen der Beratung | 14 | DCV + Auftragsverarbeiter können Inhaltsdaten nicht kennen (E2EE); inhaltliche Dokumentation findet ausschließlich außerhalb der Plattform bei den Beratungsstellen statt. | Fließtext |
| 6.3.2 | Datenverarbeitung im Rahmen des Betriebs | 15 | Auftakt: DCV sorgt mit Dienstleistern für sicheren Betrieb. | Fließtext |
| 6.3.2.1 | Registrierung der Ratsuchenden | 15 | Beratungsart + PLZ + Benutzername + Passwort ([U25]: Alter + Bundesland statt PLZ); optionale E-Mail (~10 % Nutzung, für Beratende nicht einsehbar); optionale 2FA (E-Mail oder Authenticator-App); individuelle ID für fortlaufende Beratung. | Fließtext |
| 6.3.2.2 | Registrierung der Beratenden | 15 | Accounts durch Support von Virtual Identity; Beantragung via Administrations-/Serviceportal durch „Service-Admins" der Träger; Angaben: voller Name, E-Mail, Beratungsstelle, Teamberater:in ja/nein. | Fließtext |
| 6.3.2.3 | Passwortsicherheit bei Registrierung und Anmeldung | 15–16 | Keycloak; BCrypt + individueller Salt (Standard ab Keycloak 17, aktuell 22+); Passwort-Policy (Groß/Klein, Zahl, Sonderzeichen, min. 9 Zeichen); Rate-Limiting; Beratende: 2FA obligatorisch. | Fließtext + Aufzählung |
| 6.3.2.4 | Verarbeitung der IP-Adresse, Load Balancer, Sitzungssteuerung | 16 | Load Balancer speichert/protokolliert keine IPs, gibt sie nicht ans Back End weiter → „faktische Anonymisierung im Übertragungsprozess"; Back End arbeitet mit pseudonymen Tokens und IDs (Keycloak). | Fließtext |
| 6.3.2.5 | Benutzergruppen, Authentifizierung und Zugriffskontrolle (Keycloak/IAM) | 16–17 | Zwei operative Benutzergruppen (Ratsuchende, Beratende), rollenbasiertes Modell; systeminterne Admin-Rollen organisatorisch getrennt, ohne Zugriff auf Beratungsinhalte; OAuth 2.0 / OpenID Connect, signierte JWTs, HTTPS, begrenzte Gültigkeit, „Multi-Layer-Security" (App-seitige Token-Validierung, z. B. Rocket.Chat). | Fließtext |
| 6.3.2.6 | Cookies und Websitenutzungsdaten | 17–18 | Vollständiger Verzicht auf Tracking/Analyse/Drittanbieter-Skripte; nur essenzielle Session-Cookies; danach Cookie-Tabelle mit 10 Einträgen (Name / Zweck / Speicherdauer): CSRF-Token, KEYCLOAK_LOCALE, keycloak, lang, private_key, public_key, rc_token, rc_uid, refreshToken, useInformal. | Fließtext + Tabelle |
| 6.3.2.7 | Nutzung auf verschiedenen Endgeräten | 18–19 | Verarbeitung ausschließlich serverseitig; auf Endgeräten nur temporäre Sitzungsdaten/verschlüsselte Schlüsselmaterialien; Gerätesicherheit in Verantwortung der Nutzer:innen; Beratende: organisatorische Vorgabe dienstlicher/freigegebener Geräte. | Fließtext |
| 6.3.2.8 | Ende-zu-Ende-verschlüsselter Chat | 19–20 | E2EE in allen Beratungsformen (Chat + Dateien); Rocket.Chat hinter Keycloak; asymmetrisches Schlüsselkonzept: Master Key (aus Login-Passwort generiert, verbleibt im Browser Local Storage, nie an Server), Public Key + Private Key (Private Key mit Master Key lokal verschlüsselt, nur verschlüsselt auf Rocket.Chat-Server); pro Chat ein Group Key, individuell pro Teilnehmer mit dessen Public Key verschlüsselt verteilt; Plattformbetreiber/IT-Dienstleister können Inhalte nicht einsehen; auch Live-Chat E2EE. | Fließtext + nummerierte Liste (3 Schlüssel) |
| 6.3.2.9 | Video-Call | 20 | Jitsi auf Infrastruktur des Hostinganbieters GridScale; browserbasiert, E2E-verschlüsselt „sofern ein vom System unterstützter Browser verwendet wird"; keine Speicherung/Aufzeichnung; Jitsi-interner Chat deaktiviert; Calls nur durch Beratende initiierbar; Session ohne beratende Person wird automatisch beendet. | Fließtext |
| 6.3.3 | Statistische Auswertung | 21 | Nur anonym, losgelöst von Beratungsfällen: Anzahl Erstanfragen, versendete Nachrichten, Video-Calls (ermittelt durch Dienstleister VI), Neuregistrierungen, aktive Beratende/Ratsuchende; Aufschlüsselung pro Fachbereich und Diözese. | Fließtext |
| 6.3.4 | Löschung | 21 | Ein Satz: „Siehe Löschkonzept in der Anlage." | Verweis |
| 6.4 | Kategorien Betroffene, Quellen, Datenkategorien | 22–23 | Querformat-Tabelle (Betroffene / Quelle / Datenkategorien / Datenschutzklasse): Ratsuchende mit Registrierung (10 Kategorien, Klasse I–III je nach Bereich und freiwilligen Angaben), Ratsuchende ohne Registrierung/Live-Chat (4 Kategorien, I–III), Beratende (11 Kategorien, Klasse I). Löschfristen → Löschkonzept. | Tabelle (Querformat!) |
| 6.5 | Empfänger der Daten | 24 | Querformat-Tabelle (Name / Tätigkeit / Standort / Gemeinsam Verantwortliche ja/nein / Auftragsverarbeiter ja/nein / AVV?): Beratungsstellen bzw. Träger (Ja/Nein/Nein), Virtual Identity AG (Nein/Ja/Ja), neusta integrate GmbH (Nein/Ja/Ja) — alle Standort Deutschland. | Tabelle (Querformat!) |
| 7 | Rechtsgrundlagen | 25 | Kapitelauftakt. | Fließtext |
| 7.1 | Daten der Ratsuchenden | 25 | Nummerierte 4er-Liste je Verarbeitungsschritt: (1) technische Nutzungsdaten → § 6 Abs. 1 lit. g KDG (berechtigtes Interesse); (2) Registrierungsdaten → lit. b (Einwilligung); (3) Profilangaben/E-Mail/2FA → lit. b; (4) Beratungsinhalte inkl. besonderer Kategorien → lit. b, mit Hinweis auf E2EE. | Nummerierte Liste |
| 7.2 | Daten der Beratende [sic] | 25–26 | § 6 Abs. 1 lit. g KDG (berechtigtes Interesse) und lit. f KDG (kirchliches Interesse: einheitliche Plattform für alle Caritasverbände). | Fließtext |
| 8 | Schutz der Betroffenen | 26 | Betroffenenrechte §§ 14 ff. KDG; interne Zuteilung in Anlage 4 der JC-Vereinbarung; Träger primär zuständig; auskunftsfähige Daten beim DCV wegen Datenminimierung + E2EE stark begrenzt (Aufzählung der Felder). | Fließtext |
| 8.1 | Identitätsüberprüfung | 26–27 | Identitätsprüfung vor Bearbeitung; direkt beim DCV „beinahe unmöglich" (nur Benutzername/E-Mail als Merkmale) → DCV ermittelt Beratungsstelle und bittet diese um Prüfung; Verfahren: Abgleich Kontaktdaten, Rückmeldung über Plattform-Kanäle, ggf. zusätzliche Legitimation. | Fließtext |
| 8.2 | Besonderheiten bei anonymer Nutzung | 27 | Beim Live-Chat ohne Daten ist der Anwendungsbereich des KDG nicht eröffnet → Betroffenenrechte §§ 17 ff. nicht geltend machbar; bei registrierter Nutzung anwendbar, sobald freiwillig Daten angegeben. | Fließtext |
| 8.3 | Datenschutzhinweise (§ 15 f. KDG) | 28 | Datenschutzerklärung auf Registrierungsseite + nach Login verlinkt; Beratungsstellen müssen über IHRE Verarbeitung selbst informieren (im Chat oder per Dokument-Upload). | Fließtext |
| 8.4 | Recht auf Auskunft (§ 17 KDG) | 28 | Auskunft bei jedem gemeinsam Verantwortlichen möglich; DCV-Auskunft begrenzt auf Registrierungs-/Systemdaten (Aufzählung); Beratungsinhalte technisch nicht zugänglich → keine Auskunft darüber durch Plattformbetreiber. | Fließtext |
| 8.5 | Recht auf Berichtigung (§ 18 KDG) | 28–29 | Praktisch nur E-Mail-Adresse berichtigbar (durch Ratsuchende selbst); übrige = Systemdaten (Dokumentation der Systemnutzung); eigene Chatinhalte können Nutzer selbst löschen und neu senden; Beratende: Änderungen via Service-Admins/Support. | Fließtext |
| 8.6 | Recht auf Löschung (§ 19 KDG) | 29–30 | Ratsuchende können einzelne Nachrichten oder das gesamte Konto selbstständig und unmittelbar löschen (inkl. aller Chatdaten) — „besonders datenschutzfreundliche Umsetzung"; Dienstleister kann einzelne Nachrichten wegen E2EE nicht identifizieren, komplette Chatverläufe je Beratungsstelle schon; Protokoll-/Logdaten ausgenommen (automatisierte Fristlöschung); Beratenden-Daten während aktiver Tätigkeit nicht löschbar. | Fließtext |
| 8.7 | Recht auf Einschränkung der Verarbeitung (§ 20 KDG) | 30–31 | Echte Einschränkung technisch nicht umsetzbar; nur Sperrung oder Löschung des Accounts (via DCV/Dienstleister); Ratsuchende können selbst nicht sperren, nur löschen; für Beratende alternativ temporäre Deaktivierung. | Fließtext |
| 8.8 | Recht auf Datenübertragbarkeit (§ 22 KDG) | 31 | DCV kann Registrierungsdaten digital bereitstellen; E2EE-Chatinhalte nicht maschinenlesbar exportierbar — Ratsuchende können Inhalte einsehen und z. B. Screenshots machen; für Beratende regelmäßig nicht anwendbar (keine Einwilligung/Vertrag als Grundlage). | Fließtext |
| 8.9 | Recht auf Widerspruch (§ 23 KDG) | 31 | Praktisch kein Anwendungsbereich (IT-Nutzungsdaten zwingend erforderlich); Widerspruch würde Nutzung unmöglich machen; bei Beratenden überwiegen regelmäßig zwingende Gründe. | Fließtext |
| 8.10 | Recht auf Widerruf (§ 8 Abs. 6 KDG) | 32 | Widerruf gegenüber Beratungsstellen oder DCV, Umsetzung unmittelbar; bei Beratenden nicht anwendbar (keine Einwilligungsgrundlage). | Fließtext |
| 8.11 | Datenweitergabe an Ermittlungsbehörden | 32–33 | „Worst-Case-Fall" (angekündigte anzeigepflichtige Straftaten): gemeinsam erarbeitete Handlungsempfehlung; 4-stufige Verantwortungskette (Leitung informieren → fachliche Gefährdungsanalyse → bei § 138 StGB/Kindeswohl Weiterleitung an Polizei/Jugendamt → parallel Info an DCV-Referatsleitung + Diözesanreferent:in); an Polizei gehen: Nachrichteninhalt, systemnotierte Uhrzeit/Datum, Adresse des Auftragsverarbeiters; IP-Adresse wird nie mitgeschrieben und kann nicht herausgegeben werden. | Fließtext + nummerierte Liste + Aufzählung |
| 9 | Verhältnismäßigkeitsprüfung | 33 | Vier-Schritt-Prüfung: legitimer Zweck, geeignet, erforderlich, angemessen. | Fließtext |
| 9.1 | Legitimer Zweck | 33 | Niedrigschwellige, vertrauliche, ortsunabhängige Beratung; Barriereabbau; Digitalisierung. | Fließtext |
| 9.2 | Geeignetheit | 33 | Zentrale Plattform erreicht Personen, die sonst keine Hilfe suchen; Effizienz, Standardisierung, sichere Kommunikation. | Fließtext |
| 9.3 | Erforderlichkeit | 33–34 | Kein milderes gleich geeignetes Mittel: dezentrale Lösungen fragmentieren, überfordern kleine Verbände, schwächen Auffindbarkeit („Online Beratung Caritas" als Suchbegriff); Verzicht auf Accounts würde kontinuierliche Beratung/Vertrauensaufbau zerstören; Erwähnung des Mehrwerts realer Beratender gegenüber KI. | Fließtext |
| 9.4 | Angemessenheit | 35–36 | Interessenabwägung: Freiwilligkeit, Datenminimierung, anonym nutzbar, Video-Calls nur mit aktiver Annahme; 4 Begründungs-Bullets (Anmeldedaten minimal, freiwillige Zusatzangaben, begrenzte Verarbeitungstätigkeiten, umfangreiche TOM inkl. E2EE); Verweis auf die „Risikotabelle" (= Anlage 1). | Fließtext + Aufzählung |
| 9.5 | Fazit | 36–37 | Zusammenfassung der Verhältnismäßigkeit: legitim, geeignet, erforderlich, angemessen; keine Profilbildung, kein Marketing. | Fließtext |
| 10 | Ergebnis der DSFA | 37 | Ein Absatz: Verarbeitungstätigkeit kann wie beschrieben „unter Beachtung der Maßnahmen aus der Risikoanalyse (Anlage 1)" umgesetzt werden. | Fließtext (Schluss) |
Layout-Besonderheiten: - Kopfzeile jeder Seite: Caritas-Logo + „Deutscher Caritasverband e.V." rechts oben. - Fußzeile jeder Seite: „Deutscher Caritasverband e.V. · Datenschutz-Folgenabschätzung zur Online-Beratung Blended Counseling · 29.01.2026" links, Seitenzahl rechts. - S. 22–24 sind Querformat-Seiten (breite Tabellen) — im HTML als horizontal scrollbare bzw. volle Breite nutzende Tabellen umsetzen. - Interne Querverweise als Hyperlinks formatiert (z. B. „siehe 6.3.2.8.", „siehe 8.6.", „8. Schutz der Betroffenen") — das Original arbeitet mit klickbaren Kapitel-Ankern.
| # | Feldname (Vorschlag) | Typ | Beispielwert aus dem PDF | Vorkommen im Dokument |
|---|---|---|---|---|
| 1 | operator.logo |
Bild | Caritas-Flammenkreuz + „Deutscher Caritasverband e.V." | Titelseite, Kopfzeile jeder Seite |
| 2 | operator.legalName |
Text | „Deutscher Caritasverband e.V." | Titelseite, 1.1, Fußzeile, durchgängig als „DCV" |
| 3 | operator.shortName |
Text | „DCV" | Erstdefinition S. 2/5 („nachfolgend DCV"), dann überall |
| 4 | operator.address |
Text | „Karlstraße 40, 79104 Freiburg" | 1.1 (S. 2) |
| 5 | operator.contact |
Text (E-Mail + Telefon) | „info@caritas.de, 0761 200-0" | 1.1 (S. 2) |
| 6 | operator.dpoName |
Text | „Dr. Sebastian Ertel, datenschutz nord GmbH" | 1.1 (S. 2) |
| 7 | operator.department |
Text | „Referat Online-Beratung" | Titelseite |
| 8 | operator.responsiblePerson |
Text | „Dirk Markfort (Referatsleiter)" | Titelseite; als Rolle auch in 8.11 („Referatsleitung Online-Beratungsplattform im DCV") |
| 9 | document.date |
Datum | 29.01.2026 | Titelseite, Fußzeile |
| 10 | document.nextReviewDate |
Datum | 31.01.2027 | 1.3 (S. 2) |
| 11 | document.reviewHistory |
Tabelle (Datum, Ergebnisse, Bearbeiter) | leer | 1.3 (S. 2) |
| 12 | document.attachments |
Liste (Nummer, Bezeichnung, opt. Link) | Anlage 1 Risikoanalyse, Anlage 2 Löschkonzept | 1.2 (S. 2), 6.3.4, 6.4, 9.4, 10 |
| 13 | platform.name |
Text | „Online-Beratungsplattform" / „Blended Counseling" | Titel + durchgängig |
| 14 | stats.registeredClients |
Zahl + Stichtag | „ca. 137.000 registrierte Ratsuchende (Stand Februar 2024)" | S. 4 (Ergebnis Schwellwert), S. 5 |
| 15 | stats.counsellingCentres |
Zahl + Stichtag | „1.582 Beratungsstellen" (Stand Ende 2025) | S. 5 |
| 16 | stats.activeCounsellors |
Zahl + Stichtag | „3.420 registrierten aktiven Beratenden (Stand Ende 2025)" | S. 5 |
| 17 | stats.topicAreas |
Zahl | „rund 20 Beratungsbereiche (Fachbereiche)" | S. 5 |
| 18 | stats.emailOptInRate |
Zahl (%) | „ca. 10 % der Ratsuchenden" (E-Mail hinterlegt) | 6.3.2.1 (S. 15) |
| 19 | governance.cooperationName |
Text | „Kooperation Blended Counseling" | 4.1 ff. |
| 20 | governance.cooperationHistory |
Rich-Text | Gründung März 2019, Neufassung 12.10.2023 | 4.1 (S. 5) |
| 21 | governance.structureDiagram |
Bild | Kooperations-Grafik (27 DiCV, 7 Fachverbände, 1 Landesverband, DCV) | 4.1 (S. 6) |
| 22 | governance.steeringCommittee |
Rich-Text (Zusammensetzung) | 2 DCV + 4 DiCV + 2 Fachverbände + 4 OCV | 4.2 (S. 6–7) |
| 23 | governance.boards |
Rich-Text | Fachbeirat Datenschutz, Steuerkreis Technische Entwicklung, Arbeits-/Begleitgruppe | 4.8 (S. 8–9) |
| 24 | processors[] |
Wiederholgruppe: Name, Tätigkeit, Standort, jointController (bool), processor (bool), avvExists (bool) | neusta integrate GmbH (Hosting), Virtual Identity AG (Entwicklung/Support) | 5.5 (S. 11), 6.5 (S. 24) |
| 25 | legal.framework |
Enum (KDG / DSGVO) | KDG (§§ 6, 8, 11, 14 ff., 28, 35) | durchgängig — steuert ALLE Normzitate |
| 26 | legal.jointControllerAgreement |
Rich-Text/Verweis | Vereinbarung gem. § 28 Abs. 1 S. 2 KDG mit Anlagen 2–4 | 5.4 (S. 10–11), 8 (S. 26) |
| 27 | sla.firstResponseTime |
Text/Zahl | „innerhalb von 48 Stunden (Mo–Fr) bzw. Schwangerschaftsberatung innerhalb von 24 Stunden" | 6.2 (S. 11) |
| 28 | thresholdAnalysis.answers |
Checkbox-Set (10 Fragen + 2 Vorfragen) | black list: Nein; § 35 Abs. 4: Ja; 3 von 10 Prüffragen: Ja | Kap. 2 (S. 3) |
| 29 | thresholdAnalysis.resultText |
Rich-Text | Ergebnis-Absatz S. 4 | Kap. 2 |
| 30 | special.u25Rules |
Rich-Text/Flag | [U25]: Alter + Bundesland statt PLZ; Peer-Beratung ehrenamtlich | 4.5, 4.6, 6.3.2.1, 7.1, 8.4 u. a. |
| 31 | special.liveChatScope |
Text | „Stand Januar 2026 … Bereich Schwangerschaftsberatung" | 6.2.2 (S. 13) |
| 32 | special.groupChatScope |
Text | „Exklusiv durch den Kreuzbund e.V." | 6.2.3 (S. 13) |
Beobachtung zur ORISO-Übertragung: Felder 1–12 sind klassische Global-Settings-Stammdaten (1:1 Admin-Panel). Felder 13–18 sind Kennzahlen mit Stichtag — ideal als Zahl+Datum-Paare, evtl. automatisch aus Plattform-Statistiken befüllbar. Felder 19–23 und 26 sind Governance-Freitext (Rich-Text-Editoren, analog zu den Legal-Editoren). Feld 24 ist eine wiederholbare Untertabelle. Feld 25 ist das Compliance-Preset (KDG/DSGVO) und muss die Normzitate im gesamten Dokumenttext umschalten.
Diese Abschnitte beschreiben, was die Software tut — bei ORISO aus dem Code/den ADRs neu zu schreiben, aber strukturell identisch wiederverwendbar:
Tonalität und Satzbau: - Sachlich-juristisches Behördendeutsch, durchgehend Präsens, überwiegend Passiv oder unpersönliche Konstruktionen („Es erfolgt…", „Die Verarbeitung erfolgt…", „Es ist zu beachten, dass…"). - Lange, aber grammatisch saubere Schachtelsätze; Definitionen werden beim ersten Auftreten geklammert eingeführt: „(nachfolgend DSFA)", „(im Folgenden ‚DCV')", „(im Folgenden ‚Partner' oder ‚Kooperationspartner')". Dieses Abkürzungs-Einführungsmuster konsequent kopieren. - Gendersprache mit Doppelpunkt: „Nutzer:innen", „Vertreter:innen", „Berater:in" — aber „Ratsuchende" und „Beratende" als geschlechtsneutrale Partizipien als Hauptbegriffe. - Zahlen: Tausenderpunkt („1.582", „137.000"), Stichtage in Klammern („Stand Februar 2024", „Stand Ende 2025", „Stand Januar 2026").
Fachterminologie (Glossar-würdig): Ratsuchende, Beratende, Beratungsstelle, Träger, Fachbereich, Erstanfrage/Erstnachricht, Beratungsfall, Standard-/Regelberatungsstelle vs. Teamberatungsstelle, Service-Admins, Verantwortungskette, Worst-Case-Fall, Datenschutzklasse I–III, gemeinsame Verantwortlichkeit, Auftragsverarbeiter, TOM. Normzitate immer im Format „§ 6 Abs. 1 lit. g KDG" bzw. „§§ 14 ff. KDG".
Risiko-Formulierungen: Risiken werden nicht dramatisiert, sondern als Abwägung formuliert: „Allein die große Zahl an Ratsuchenden spricht bereits für ein erhöhtes Risiko" (S. 4); „Ohne eine verifizierbare Identität besteht das Risiko, dass Daten unbefugt offengelegt oder verändert werden" (S. 27). Muster: Risiko benennen → sofort die kompensierende Maßnahme oder die technische Unmöglichkeit des Schadens nachschieben („Der DCV hat technisch keinen Zugriff…"). Grenzen werden ehrlich benannt („beinahe unmöglich", „nur eingeschränkt einschlägig und möglich") — diese Ehrlichkeit ist Teil der Glaubwürdigkeit des Dokuments und sollte kopiert werden.
Tabellen-Konventionen: - Key-Value-Tabellen (1.1): linke Spalte Label mit Doppelpunkt, rechte Spalte Wert. - Datentabellen (6.4, 6.5, Cookies): Kopfzeile fett, Zellen mit Bullet-Listen innerhalb der Zellen (6.4), ja/nein-Spalten als ausgeschriebenes „Ja"/„Nein" (6.5) — KEINE Checkboxen in Datentabellen. - Checkboxen NUR in der Schwellwertanalyse (Kap. 2): dunkelblaue schmale Checkbox-Spalte links, ☒ (angekreuzt) / ☐ (leer), Antworttext rechts daneben. Ja/Nein-Fragen als zwei Zeilen (☐ Ja / ☒ Nein). Prüffragen als eine Zeile pro Frage mit Checkbox davor. Entscheidungsregel fett hervorgehoben: „Sollten zwei oder mehr Fragen bejaht werden, ist die Durchführung einer DSFA erforderlich." - Leere Formulartabellen für Zukunftspflege (1.3 Wiederholungs-Historie).
Nummerierung: Dezimalklassifikation bis maximal Ebene 4 (6.3.2.8); Hauptkapitel 1–10; Überschriften in Caritas-Rot/dunklem Blauton abgesetzt, Fließtext schwarz. Anhänge als „Anlage 1/2" extern.
Kopf-/Fußzeile: Kopf = Logo rechts; Fuß = „
Empfehlung: eine Seite mit Sticky-Sidebar-Navigation (nummerierte Kapitel), 8 Top-Level-Sektionen. Kapitel-Nummerierung des Originals beibehalten (Zitierfähigkeit!), aber navigatorisch gruppieren:
overflow-x: auto) / 6.5 Empfänger. Die E2EE-Beschreibung 6.3.2.8 verdient ein kleines Diagramm (Master Key → Private Key → Group Key).Zusätzlich: Versionierungs-Leiste (Review-Historie aus 1.3 als Changelog), Anlagen 1+2 als eigene verlinkte Dokumente derselben Machart, Print-Stylesheet das Kopf-/Fußzeilen des Originals reproduziert.
Das Dokument ist durchgehend auf dem KDG (Gesetz über den Kirchlichen Datenschutz der katholischen Kirche) aufgebaut. Das KDG ist die für die katholische Kirche geltende eigenständige Datenschutzregelung nach Art. 91 DSGVO (bestehende umfassende kirchliche Regelung, die im Einklang mit der DSGVO gehalten wird). Struktur und Pflichten sind bewusst DSGVO-parallel — die DSFA-Struktur ist daher fast 1:1 übertragbar, nur die Normanker und einige Details wechseln.
| Gegenstand | KDG (im Dokument) | DSGVO-Äquivalent |
|---|---|---|
| DSFA-Pflicht | § 35 KDG | Art. 35 DSGVO |
| Black list (Muss-Liste der Aufsicht) | § 35 Abs. 5 KDG (Liste der Datenschutzaufsicht) | Art. 35 Abs. 4 DSGVO (Listen der Landes-/Bundesaufsicht, abgestimmt im DSK-Kurzpapier) |
| Regelbeispiele DSFA-Pflicht | § 35 Abs. 4 KDG | Art. 35 Abs. 3 DSGVO |
| Rechtsgrundlagen | § 6 Abs. 1 lit. b (Einwilligung), lit. f (kirchliches Interesse), lit. g (berechtigtes Interesse) KDG | Art. 6 Abs. 1 lit. a (Einwilligung), lit. e (öffentliches Interesse — kein direktes Pendant zu „kirchlichem Interesse"), lit. f (berechtigtes Interesse) DSGVO |
| Besondere Kategorien | § 11 KDG | Art. 9 DSGVO |
| Gemeinsame Verantwortlichkeit | § 28 KDG | Art. 26 DSGVO |
| Auftragsverarbeitung | § 29 KDG | Art. 28 DSGVO |
| Informationspflichten | §§ 15, 16 KDG | Art. 13, 14 DSGVO |
| Auskunft | § 17 KDG | Art. 15 DSGVO |
| Berichtigung | § 18 KDG | Art. 16 DSGVO |
| Löschung | § 19 KDG | Art. 17 DSGVO |
| Einschränkung | § 20 KDG | Art. 18 DSGVO |
| Datenübertragbarkeit | § 22 KDG | Art. 20 DSGVO |
| Widerspruch | § 23 KDG | Art. 21 DSGVO |
| Widerruf der Einwilligung | § 8 Abs. 6 KDG | Art. 7 Abs. 3 DSGVO |
| Betroffenenrechte gesamt | §§ 14 ff. / 17 ff. KDG | Art. 12 ff. DSGVO |
legal.supervisoryAuthority (Name + Adresse) und muss die Konsultations-Passage austauschen.ORISO-Konsequenz: Ein Enum compliancePreset: KDG | DSGVO (passt zu den bestehenden KDG/DSGVO-Compliance-Presets im Admin-Panel) steuert: (a) alle Normzitate via Mapping-Tabelle, (b) die Vorfragen der Schwellwertanalyse, (c) den Abschnitt Rechtsgrundlage Beratende, (d) den Aufsichtsbehörden-Block, (e) Terminologie („Diözesandatenschutzbeauftragter" vs. „Landesbeauftragte:r für Datenschutz"). Der gesamte Rest des Dokuments ist preset-neutral.
Technische/organisatorische Behauptungen des Dokuments, präzise mit Seite:
Verschlüsselung: - „Chat-Nachrichten und im Chat geteilte Dateien sind in allen Beratungsformen Ende-zu-Ende-verschlüsselt (E2EE)… Der DCV hat technisch keinen Zugriff auf die Inhalte der Chat-Nachrichten." (S. 19, 6.3.2.8) - Chatdienst ist Rocket.Chat, Authentifizierung davor via Keycloak (S. 19). - Schlüsselkonzept: Master Key aus Login-Passwort generiert, verbleibt ausschließlich im Browser (Local Storage), wird nie an den Server übermittelt; Private Key lokal mit Master Key verschlüsselt, nur verschlüsselt + Public Key auf dem Rocket.Chat-Server; pro Chat ein Group Key, je Teilnehmer mit dessen Public Key verschlüsselt verteilt (S. 19–20). Folge: Betreiber kann Private Key nicht wiederherstellen, Inhalte nie im Klartext auf dem Server (S. 19–20). - Passwörter: BCrypt mit individuellem Salt in Keycloak (Standard ab v17, „aktuell Version 22+"), Policy min. 9 Zeichen + Groß/Klein + Zahl + Sonderzeichen, Rate-Limiting (S. 16). 2FA für Beratende obligatorisch, für Ratsuchende optional (E-Mail oder Authenticator-App) (S. 15–16).
Hosting & Auftragsverarbeiter: - Auftragsverarbeiter: neusta integrate GmbH (ehemals Open 4 Business GmbH) für Server-Hosting; Virtual Identity AG als Entwickler, Supportdienstleister, Wartung, Verwaltung der Beratenden-Accounts (S. 11, 5.5; Tabelle S. 24, 6.5). Standort der Datenverarbeitung: Deutschland; AVV besteht mit beiden (S. 24). - Jitsi-Komponenten laufen „auf der Infrastruktur des Hostinganbieters GridScale" (S. 20, 6.3.2.9) — dritter Infrastrukturakteur, der in der Empfänger-Tabelle 6.5 auffälligerweise NICHT auftaucht. - Beratungsstellen/Träger: gemeinsam Verantwortliche, kein AVV (S. 24).
IP-Adressen / Anonymisierung: - „Der Loadbalancer speichert oder protokolliert keine eingehenden IP-Adressen. Sie werden auch nicht an das Back End weitergegeben. Damit erfolgt bereits beim Load Balancer eine faktische Anonymisierung" (S. 16, 6.3.2.4). Back End arbeitet nur mit pseudonymen Tokens/IDs (Keycloak). - „Die IP-Adresse der Ratsuchenden wird zu keiner Zeit vom System mitgeschrieben und kann … weder eingesehen noch an Polizei oder Staatsanwaltschaft weitergegeben werden." (S. 32–33, 8.11) - Kein Tracking, keine Analysedienste, keine Drittanbieter-Skripte; ausschließlich essenzielle Session-Cookies (S. 17, 6.3.2.6; Tabelle S. 18).
Rollen & Zugriff: - Zwei operative Benutzergruppen: Ratsuchende und Beratende; rollenbasierte Zugriffskontrolle via Keycloak; systeminterne Administratorrollen organisatorisch von der Beratung getrennt, ohne Zugriff auf Beratungsinhalte (S. 16–17, 6.3.2.5). OAuth 2.0/OIDC, signierte JWTs, Multi-Layer-Token-Validierung (S. 17). - Beratenden-Accounts werden vom VI-Support angelegt; Beantragung über „Service-Admins" der Träger (Deaktivierung/Löschung ebenso) (S. 15, 6.3.2.2). - Zwei Beratungsstellentypen: Standard/Regel (strikte 1:1-Sichtbarkeit; Weitergabe nur durch ursprünglichen Beratenden UND nach Pop-up-Zustimmung des Ratsuchenden) vs. Teamberatungsstelle (alle Beratenden der Stelle sehen alle Fälle; für Ratsuchende bei Registrierung transparent) (S. 12, 6.2.1).
Anonyme Nutzung: - Registrierung ohne personenbezogene Daten möglich: frei wählbarer Benutzername + Passwort; Pflicht nur PLZ (bzw. [U25]: Bundesland + Alter), Richtigkeit wird nicht geprüft (S. 8, 4.6; S. 15, 6.3.2.1). - E-Mail optional, nur ~10 % hinterlegen sie; für Beratende nicht einsehbar (S. 15). - Live-1:1-Chat ganz ohne Registrierung (Stand Jan 2026 nur Schwangerschaftsberatung); auto-generierter Name „Ratsuchende_r 01"; nach Verlassen für Ratsuchende unwiederbringlich zu, Beratende sehen noch bis 6 h, dann Label „done" (S. 13, 6.2.2). - Bei vollständig anonymer Nutzung ist der KDG-Anwendungsbereich nicht eröffnet (S. 27, 8.2).
Videoberatung: - Jitsi; browserbasiert; „E2E-verschlüsselt, sofern ein vom System unterstützter Browser verwendet wird" (bemerkenswerte Einschränkung!) (S. 20, 6.3.2.9). - Keine Speicherung/Aufzeichnung/automatische Protokollierung (S. 14, 6.2.4; S. 20). Jitsi-interner Chat deaktiviert (S. 20). Calls nur durch Beratende startbar; Warteraum + aktives Einlassen; Teilnahme externer Personen (Dolmetscher, Angehörige) per Link ohne Registrierung; Raum wird nach Verlassen aller dauerhaft gelöscht; Call ohne beratende Person wird automatisch beendet (S. 14, 20).
Terminverwaltung: - Eine echte Terminverwaltung beschreibt das Dokument NICHT. Am nächsten kommen: geplante Video-Calls („Beratende können … einen Video-Call planen und Teilnehmende über einen Link einladen", S. 14) und Gruppenchat-Angebote mit „Thema, Datum, Uhrzeit und ob … einmaliges … oder wiederkehrendes Angebot nach einem festen Turnus (z. B. wöchentlich)" (S. 13, 6.2.3). → Für ORISO (Terminverwaltung vorhanden) ist das ein NEUER Abschnitt ohne Alt-Pendant.
Löschfristen / Löschung: - Konkrete Fristen stehen NICHT im Hauptdokument — durchgängig Verweis auf das Löschkonzept (Anlage 2): „Siehe Löschkonzept in der Anlage" (S. 21, 6.3.4); „Die Löschfristen zu den jeweiligen Datenkategorien befinden sich im Löschkonzept (siehe Anlage)" (S. 22, 6.4). - Ratsuchende können einzelne Nachrichten und ihr gesamtes Konto jederzeit selbstständig löschen; Kontolöschung löscht sämtliche personenbezogenen Daten inkl. Chatdaten (S. 29, 8.6). Beratende werden in Schulungen darauf hingewiesen, dass Daten jederzeit ohne Ankündigung verschwinden können (S. 29–30). - Dienstleister kann wegen E2EE einzelne Nachrichten nicht identifizieren, komplette Chatverläufe mit einer Beratungsstelle aber schon löschen (S. 29). - Log-/Protokolldaten: automatisierte Löschung nach Fristablauf, von Löschanträgen ausgenommen (S. 30). - Gruppenchat: „Nach Beenden eines Chats werden sämtliche Daten gelöscht." (S. 14) - Keine inhaltliche Dokumentation auf der Plattform; Falldokumentation ausschließlich in den Systemen der Beratungsstellen (S. 5, 14, 30).
Statistik: - Nur anonym: Anzahl Erstanfragen, versendete Nachrichten, Video-Calls (durch Dienstleister VI ermittelt), Neuregistrierungen, aktive Beratende/Ratsuchende; Aufschlüsselung pro Fachbereich und Diözese (S. 21, 6.3.3). Beratende: „Anzahl der Videocalls und angenommenen Erstanfragen" als Datenkategorie (S. 23) — Achtung, das berührt die ORISO-Message-Stats-Privacy-Diskussion.
Worst Case / Strafverfolgung: - 4-stufige Verantwortungskette bei angekündigten Straftaten (§ 138 StGB, Kindeswohl, rechtfertigender Notstand); Beratungsstelle (nicht der Betreiber!) leitet an Polizei/Jugendamt weiter; an die Polizei gehen Nachrichteninhalt + Systemzeitstempel + Adresse des Auftragsverarbeiters (S. 32, 8.11).
Sonstiges Vergleichsrelevantes: - Erstanfrage-SLA: 48 h Mo–Fr, Schwangerschaftsberatung 24 h (S. 11). - Info-E-Mail an Beratende bei neuer Erstanfrage enthält nur die PLZ, keine weiteren Daten (S. 12). - „Archivieren" ist nur ein Ordner im Postfach des Beratenden, keine eigene Aufbewahrung (S. 13). - Datenschutzklassen I–III als Klassifikationsschema in 6.4 (S. 22–23) — Herkunft des Schemas wird nicht erklärt (vermutlich KDG-Durchführungsverordnung/KDR-OG); für ORISO klären, ob übernehmen.