Eine gute Anwendung für Online-Beratung sollte eine klar strukturierte und leicht zugängliche Übersicht aller Datenschutz- und Verschlüsselungsmaßnahmen bereitstellen. Dazu gehören insbesondere Informationen zu:
 

• eingesetzten Verschlüsselungsverfahren (z. B. Ende-zu-Ende- oder Transportverschlüsselung),
• Speicherorten und Hosting der Daten,
• Zugriffs- und Rollenrechten innerhalb des Systems,
• Authentifizierungsverfahren (z. B. Zwei-Faktor-Authentifizierung),
• Lösch- und Aufbewahrungsfristen,
• Protokollierung sicherheitsrelevanter Vorgänge,
• Maßnahmen zur DSGVO-Konformität.
   

Diese Übersicht sollte transparent dokumentiert sein – idealerweise in Form eines eigenen Sicherheits- oder Datenschutzkonzepts –, damit Träger, Beratungsstellen und Administrator*innen nachvollziehen können, wie sensible Beratungsdaten geschützt werden.

⚠️ Warum das wichtig ist: Gerade im Bereich Online-Beratung ist Transparenz beim Datenschutz ein zentrales Qualitätsmerkmal und schafft Vertrauen bei Fachkräften wie Ratsuchenden. Eine solche Übersicht erleichtert außerdem den direkten Vergleich zwischen Anbietern, statt einzelne Sicherheitsversprechen nur isoliert bewerten zu können.

Anbieter sollten transparent offenlegen können, ob es in den letzten fünf Jahren Datenschutzvorfälle, Datenlecks oder Verfahren durch Datenschutzaufsichtsbehörden gab. Dazu zählen auch Informationen über Art und Umfang des Vorfalls, betroffene Datenkategorien, eingeleitete Gegenmaßnahmen und gegebenenfalls behördliche Konsequenzen.

Ein dokumentierter Vorfall ist nicht automatisch ein Ausschlusskriterium. Entscheidend ist, wie professionell und nachvollziehbar damit umgegangen wurde:

• Wurde der Vorfall fristgerecht gemeldet?
• Wurden Betroffene informiert?
• Gab es technische und organisatorische Verbesserungen im Anschluss?
• Liegt ein dokumentiertes Incident-Response-Verfahren vor?

⚠️ Warum das wichtig ist: Problematisch ist es, wenn Anbieter hierzu keine klaren Angaben machen, Vorfälle verschweigen oder nur unpräzise antworten. Transparenz im Umgang mit Sicherheitsvorfällen ist ein wichtiger Indikator für Verantwortungsbewusstsein und Datenschutzreife – nicht die Abwesenheit von Vorfällen an sich.

Gängige Security Header sollten in einer Webanwendung implementiert sein, weil sie zusätzliche Sicherheitsregeln direkt im Browser durchsetzen. Dazu gehören insbesondere:
 

• Schutz vor Einschleusen von fremdem Code (z. B. durch restriktive Vorgaben, welche Inhalte überhaupt geladen werden dürfen),
• Schutz vor Clickjacking: Verhindert, dass die Anwendung unbemerkt in fremde Webseiten eingebettet wird,
• Erzwingen von HTTPS: Verschlüsselte Verbindungen werden konsequent durchgesetzt,
• Schutz vor Fehlinterpretation von Dateitypen: Verhindert, dass der Browser Dateien "falsch" interpretiert und dadurch Angriffe ermöglicht,
• Einschränkung von Browser-Funktionen (z. B. Kamera, Standort): Regelt, welche Funktionen unter welchen Bedingungen genutzt werden dürfen.
   

Entscheidend ist nicht nur, dass diese Header vorhanden sind, sondern dass sie konsequent und restriktiv konfiguriert sowie regelmäßig überprüft werden. Fehlen sie oder sind sie zu locker gesetzt, entstehen vermeidbare Sicherheitsrisiken im Webkontext.

💡 Dieser Punkt lässt sich mit wenig Aufwand selbst prüfen – etwa mit dem Mozilla Observatory oder dem Security Headers Test. Beide Tools zeigen für jede beliebige Website, welche Header gesetzt sind und wie restriktiv sie konfiguriert wurden.

⚠️ Warum das wichtig ist: Fehlende oder schwach konfigurierte Security Header lassen sich technisch leicht ausnutzen. Da sich der Header-Status öffentlich und kostenlos nachprüfen lässt, ist das ein Kriterium, bei dem sich Transparenz besonders einfach objektiv verifizieren lässt – statt sich auf reine Zusagen des Anbieters verlassen zu müssen.

In der Regel werden in Webanwendungen Cookies gesetzt. Entscheidend ist jedoch, welche Cookies das sind und wofür sie verwendet werden. Typischerweise gibt es drei Kategorien:
 

• Notwendige Cookies: Für den Betrieb der Anwendung erforderlich, z. B. für Anmeldung, Sitzungsverwaltung oder Sicherheit. Ohne sie würde die Anwendung nicht funktionieren.
• Funktionale Cookies: Speichern Einstellungen der Nutzer*innen, z. B. Sprache, Oberfläche oder bestimmte Komfortfunktionen.
• Optionale Cookies (z. B. Analyse oder Tracking): Werden genutzt, um die Nutzung der Anwendung auszuwerten oder statistisch zu erfassen.

⚠️ In einer sensiblen Umgebung wie Online-Beratung sollten solche optionalen Cookies entweder gar nicht eingesetzt oder nur nach expliziter Einwilligung aktiviert werden.

Wichtig ist außerdem:
 

• Cookies sollten nur das speichern, was technisch notwendig oder ausdrücklich erlaubt ist.
• Sie sollten eine klare Ablaufzeit haben – keine unnötig langen Speicherungen. Man unterscheidet hier zwischen Session-Cookies, die mit Schließen des Browsers automatisch gelöscht werden, und persistenten Cookies, die über einen festgelegten Zeitraum bestehen bleiben.
• Sie dürfen keine sensiblen Beratungsinhalte enthalten.
• Nutzer*innen müssen transparent darüber informiert werden, welche Cookies gesetzt werden und warum – über klare Datenschutzhinweise und, bei nicht notwendigen Cookies, über eine echte Einwilligungsmöglichkeit (Consent-Banner), wie es das TTDSG in Deutschland vorschreibt.

⚠️ Warum das wichtig ist: Cookies können unbemerkt Rückschlüsse auf das Nutzungsverhalten zulassen. Gerade bei einer Plattform, die von Menschen in vertraulichen, teils belastenden Lebenssituationen genutzt wird, sollte die Cookie-Nutzung so zurückhaltend wie möglich gestaltet und vollständig transparent gemacht werden.

Das hängt von der konkreten Anwendung ab, sollte aber klar und transparent beantwortet werden können.

Grundsätzlich gilt:

• In sensiblen Anwendungen wie Online-Beratung sollte kein Tracking im Sinne von Nutzer*innenprofilen oder übergreifender Verhaltensverfolgung stattfinden.
• Wenn überhaupt Analyse eingesetzt wird, dann nur in stark reduzierter Form und anonymisiert – etwa um die technische Stabilität zu prüfen (Fehlerhäufigkeit, Ladezeiten, Systemausfälle).

Wichtig ist dabei die Abgrenzung zwischen zwei sehr unterschiedlichen Dingen:

• Tracking im engeren Sinne – also wiedererkennbare Nutzer*innenverfolgung über Sitzungen oder Geräte hinweg – ist kritisch zu sehen und in der Regel nicht ohne ausdrückliche Einwilligung zulässig.
• Reine technische Statistikdaten (z. B. Anzahl aktiver Sitzungen, ohne Inhalts- oder Personenbezug) sind eher unproblematisch, wenn sie wirklich anonymisiert sind und keine Rückverfolgung auf einzelne Personen erlauben.

Zentral ist in jedem Fall Transparenz: Wenn Analyse stattfindet, muss klar sein,

• welche Daten erhoben werden,
• ob sie personenbezogen oder anonymisiert sind,
• zu welchem Zweck sie genutzt werden,
• und ob dafür eine Einwilligung erforderlich ist.

⚠️ Warum das wichtig ist: Gerade bei einer Plattform, die von Menschen in vertraulichen, teils belastenden Situationen genutzt wird, kann schon das Wissen um mögliches Tracking eine Hürde sein, sich zu öffnen. Wo Analyse eingesetzt wird, sollte sie so zurückhaltend und transparent wie möglich gestaltet sein.

Bei Anwendungen, die personenbezogene oder besonders sensible Daten verarbeiten, ist der Serverstandort ein zentraler Datenschutzfaktor. Idealerweise befinden sich die Server ausschließlich in der EU, weil dort die DSGVO gilt und ein einheitlich hohes Datenschutzniveau besteht. Das reduziert rechtliche Unsicherheiten und vereinfacht die Kontrolle über Datenflüsse.

Wichtig ist dabei:
 

• Reine EU-Hosting-Strategie: Alle produktiven Systeme (Datenbank, Anwendung, Backups) liegen in Rechenzentren innerhalb der EU.
• Keine unkontrollierten Drittlandzugriffe: Es darf keine regelmäßige Verarbeitung oder Wartung durch Anbieter in Drittstaaten ohne passende Schutzmechanismen (z. B. Standardvertragsklauseln) erfolgen.
• Klare Transparenz: Der genaue Standort (Land oder sogar Rechenzentrum) sollte benannt werden können.
• Unterauftragnehmer prüfen: Auch Cloud- oder Infrastruktur-Dienstleister müssen EU-Standorte einhalten oder gleichwertige Garantien bieten.

⚠️ Warum das wichtig ist: Wenn Server teilweise außerhalb der EU betrieben werden, ist das nicht automatisch unzulässig, aber deutlich komplexer zu bewerten und erfordert zusätzliche vertragliche und technische Absicherungen. Wer bei einem Anbieter keine klare Antwort auf die Frage nach dem Serverstandort bekommt, sollte das als Warnsignal werten.

Diese Information sollte bei einer Anwendung transparent und vollständig vorliegen, idealerweise in einer Liste der eingesetzten Subdienstleister (auch „Auftragsverarbeiter" oder „Subprozessoren" genannt).

Darin wird typischerweise angegeben:

• Welche Dienstleister eingesetzt werden (z. B. Hosting, E-Mail-Versand, Support-Systeme, Monitoring, Cloud-Infrastruktur),
• welche Funktion sie übernehmen,
• und wo sie ansässig sind bzw. wo Daten verarbeitet werden.

Wichtig ist dabei:
 

• Subdienstleister müssen vertraglich im Rahmen der DSGVO als Auftragsverarbeiter eingebunden sein.
• Für jeden Dienstleister sollte klar sein, ob Daten innerhalb der EU oder auch außerhalb der EU verarbeitet werden.
• Bei Drittlandbezug (z. B. USA) müssen zusätzliche Schutzmechanismen bestehen, etwa Standardvertragsklauseln und gegebenenfalls zusätzliche technische Maßnahmen.
• Die Liste sollte aktuell gehalten und öffentlich oder zumindest auf Anfrage verfügbar sein.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn keine vollständige Übersicht existiert oder Änderungen an Subdienstleistern nicht transparent kommuniziert werden. Nur mit einer aktuellen, vollständigen Liste lässt sich wirklich nachvollziehen, wem sensible Beratungsdaten am Ende tatsächlich anvertraut werden – auch indirekt, über die Kette der eingebundenen Dienstleister.

Subdienstleister sollten nur auf die Daten und Systeme Zugriff haben, die sie zur Erfüllung ihrer konkreten Aufgabe zwingend benötigen. Grundsätzlich gilt hier das Prinzip der Datenminimierung und Zweckbindung:
 

• Hosting- und Cloud-Dienstleister haben in der Regel Zugriff auf die technische Infrastruktur (z. B. Serverbetrieb, Datenbanken, Backups), aber nicht auf Inhalte im Sinne einer aktiven, operativen Nutzung.
• Support- oder Wartungsdienstleister sollten nur dann Zugriff erhalten, wenn es erforderlich ist – idealerweise zeitlich begrenzt und protokolliert, etwa bei Fehleranalysen.
• Monitoring- und Sicherheitsdienste sehen typischerweise System- und Logdaten, aber keine Beratungsinhalte oder personenbezogenen Kommunikationsinhalte im Detail.
• Kommunikations- oder Versanddienste (z. B. E-Mail oder Benachrichtigungen) verarbeiten nur die dafür notwendigen Kontakt- und Nachrichtendaten.

Wichtig ist außerdem:
 

• Zugriffe sollten rollenbasiert und streng eingeschränkt sein (Least-Privilege-Prinzip).
• Bei sensiblen Anwendungen sollte es keinen dauerhaften Vollzugriff durch Subdienstleister auf Inhaltsdaten geben.
• Jeder Zugriff sollte protokolliert und nachvollziehbar sein.
• Es sollte klar dokumentiert sein, ob Subdienstleister nur technische Daten oder auch Inhaltsdaten verarbeiten.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn Subdienstleister „generellen Zugriff" auf produktive Datenbestände haben oder wenn nicht klar abgegrenzt wird, welche Daten genau betroffen sind. Je länger die Kette der eingebundenen Dienstleister, desto wichtiger wird es, an jeder einzelnen Stelle genau zu wissen, wer worauf zugreifen kann.

In vielen Webanwendungen werden Ressourcen Dritter eingebunden oder Verbindungen zu externen Diensten aufgebaut. Entscheidend ist jedoch, welche das sind, wofür sie genutzt werden und wie stark sie kontrolliert werden.

Typischerweise kann das folgende Bereiche betreffen:
 

• Technische Infrastruktur: z. B. Cloud-Hosting, Datenbanken oder Content-Delivery-Netzwerke (CDN), die für die Auslieferung der Anwendung genutzt werden.
• Analyse- oder Monitoring-Dienste: zur Messung von Systemstabilität oder Fehlermeldungen – idealerweise ohne personenbezogene Inhalte.
• Kommunikationsdienste: z. B. für E-Mail-Versand oder Benachrichtigungen.
• Schriftarten, Skripte oder Bibliotheken, die von externen Servern geladen werden, etwa für Design oder Funktionalität.

Der Unterschied zur vorherigen Frage: Dort ging es um Dienstleister, die im Hintergrund Daten verarbeiten. Hier geht es zusätzlich um technische Einbindungen, die oft direkt im Browser der Nutzer*innen stattfinden – etwa wenn eine Schriftart live von einem externen Server geladen wird und dabei unbemerkt die IP-Adresse an diesen Drittanbieter übertragen wird.

Wichtig ist dabei:

• Jede externe Verbindung sollte klar dokumentiert und begründet sein.
• Es sollte geprüft werden, ob externe Inhalte überhaupt notwendig sind oder lokal betrieben werden können (z. B. Schriftarten selbst hosten statt extern laden).
• Externe Dienste sollten keine unkontrollierte Übertragung personenbezogener Daten ermöglichen.
• Idealerweise werden externe Ressourcen minimiert, um Datenschutz- und Sicherheitsrisiken zu reduzieren.
• Wenn externe Anbieter eingebunden sind, müssen sie DSGVO-konform eingebunden sein, inklusive Verträgen zur Auftragsverarbeitung.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn unbekannte oder nicht dokumentierte Drittverbindungen bestehen oder wenn Daten ohne klare Kontrolle an externe Dienste übertragen werden. Gerade unscheinbare Elemente wie eine extern geladene Schriftart werden bei der Sicherheitsbewertung leicht übersehen, obwohl auch sie technisch eine Datenübertragung an Dritte auslösen.

Solche Rückmeldungen oder Bewertungen können vorliegen und sind ein zusätzliches Qualitäts- und Transparenzmerkmal. Wenn Datenschutzbeauftragte anderer Kund*innen eine Anwendung geprüft haben, können daraus z. B. folgende Informationen stammen:
 

• Einschätzungen zur DSGVO-Konformität der Anwendung,
• Hinweise zu Risiken oder Verbesserungsbedarf,
• Bestätigungen zur Eignung für bestimmte Einsatzbereiche (z. B. Sozialarbeit, Beratung, Gesundheitswesen),
• Erfahrungen aus Praxisprüfungen oder Datenschutz-Folgenabschätzungen.

Wichtig ist dabei:

• Diese Rückmeldungen sollten nachvollziehbar und idealerweise schriftlich dokumentiert sein.
• Es sollte klar sein, in welchem Kontext die Bewertung erfolgt ist – etwa welche Organisation, welches Einsatzszenario, welche Version der Anwendung geprüft wurde.
• Positive Bewertungen ersetzen keine eigene Prüfung durch die jeweilige Organisation, sondern können diese nur ergänzen.
• Datenschutzrechtlich verbindlich bleibt immer die eigene Verantwortung der jeweiligen Einrichtung, etwa durch die eigenen Datenschutzbeauftragten.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn nur pauschale Aussagen wie „datenschutzkonform bestätigt" gemacht werden, ohne Kontext oder nachvollziehbare Grundlage. Eine konkrete, nachvollziehbare Rückmeldung ist deutlich aussagekräftiger als ein bloßes Gütesiegel-Versprechen ohne erkennbare Substanz dahinter.

Relevante Zertifizierungen können vorhanden sein. Sie sind kein zwingender Nachweis für Datenschutzkonformität, bieten aber eine zusätzliche unabhängige Orientierung über Sicherheits- und Qualitätsstandards.
 

Typische Zertifizierungen in diesem Kontext sind:

• ISO 27001 (Informationssicherheitsmanagement): Bestätigt, dass ein strukturiertes Informationssicherheitsmanagementsystem etabliert ist. Das umfasst Prozesse für Risikomanagement, Zugriffskontrollen, Incident-Management und kontinuierliche Verbesserung.
• BSI C5 (Cloud Computing Compliance Controls Catalogue): Besonders relevant für Cloud-Dienste. Prüft unter anderem Sicherheitsmaßnahmen, Datenstandorte, Transparenz und Kontrollmechanismen bei Cloud-Anbietern.
• TÜV- oder vergleichbare Datenschutz-/IT-Sicherheitszertifizierungen: Diese können je nach Prüfstandard verschiedene Schwerpunkte haben, etwa technische Sicherheit, Prozessqualität oder DSGVO-nahe Anforderungen.

Der konkrete Mehrwert solcher Zertifizierungen liegt darin, dass:

• externe, unabhängige Prüfstellen Sicherheits- und Datenschutzmaßnahmen regelmäßig überprüfen,
• Mindeststandards systematisch nachgewiesen werden müssen,
• und Risiken strukturiert identifiziert und adressiert werden.

Wichtig ist jedoch:

• Eine Zertifizierung ersetzt keine eigene Datenschutzprüfung durch die jeweilige Organisation.
• Der genaue Geltungsbereich ist entscheidend – gilt sie nur für Teile der Infrastruktur, oder für das gesamte Produkt?
• Zertifikate müssen aktuell sein und regelmäßig erneuert werden.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn Zertifizierungen nur allgemein genannt werden, ohne Prüfbereich, Gültigkeit oder Zertifizierungsstelle zu benennen. Ein Zertifikat ist nur so aussagekräftig wie die Angaben, die es konkret belegen – „ISO-zertifiziert" ohne weitere Details lässt offen, was genau geprüft wurde und wie aktuell das Ergebnis ist.

Externe Sicherheitsaudits sollten bei solchen Anwendungen regelmäßig durchgeführt werden, idealerweise durch unabhängige, spezialisierte Prüfstellen. Dabei sind drei Punkte entscheidend:

1. Durch wen wird geprüft?
Externe Audits werden typischerweise von unabhängigen IT-Sicherheitsunternehmen oder Zertifizierungsstellen durchgeführt, z. B. im Rahmen von ISO-27001-Zertifizierungen oder durch spezialisierte Penetration-Testing-Anbieter.

2. Wann fand das letzte Audit statt?
Es sollte klar dokumentiert sein, wann die letzte externe Sicherheitsprüfung durchgeführt wurde. Aktuelle Audits sind wichtig, da sich Systeme und Bedrohungslagen schnell verändern.

3. In welchen Abständen finden Audits statt?
Üblich sind regelmäßige Prüfzyklen, zum Beispiel jährlich oder im Rahmen kontinuierlicher Zertifizierungsprozesse. Zusätzlich sollten bei größeren Systemänderungen oder neuen Funktionen außerplanmäßige Prüfungen erfolgen.

Wichtig ist außerdem:

• Audits sollten sowohl technische Sicherheitsprüfungen (z. B. Penetrationstests) als auch organisatorische Aspekte umfassen.
• Ergebnisse sollten zumindest in zusammengefasster Form nachvollziehbar dokumentiert sein.
• Es sollte klar sein, ob nur Teile des Systems oder die gesamte Anwendung geprüft wurden.

⚠️ Warum das wichtig ist: Problematisch ist es, wenn externe Audits nur einmalig oder gar nicht stattfinden oder wenn keine klaren Angaben zu Umfang, Zeitpunkt und Prüfinstitution gemacht werden. Ein einzelner bestandener Pentest aus der Vergangenheit sagt wenig über die aktuelle Sicherheitslage aus – erst regelmäßig wiederholte Prüfungen zeigen, dass ein System auch mit neuen Bedrohungen und Weiterentwicklungen Schritt hält.

Eine datenschutzkonforme Lösung legt genau fest, wer auf welche Inhalte zugreifen oder diese verändern darf – und wer eben nicht. Zwei Rollen verdienen dabei besondere Aufmerksamkeit:
 

• Administrator*innen: Sie benötigen Zugriff auf technische Einstellungen (z. B. Nutzerverwaltung, Konfiguration), um das System zu betreiben. Im Idealfall haben sie aber keinen inhaltlichen Zugriff auf Beratungsgespräche – ihre Rolle ist technisch, nicht inhaltlich.
• Der Dienstleister selbst: Auch das Unternehmen, das die Software betreibt, sollte im Regelfall keinen Zugriff auf Beratungsinhalte haben. Wartung und Support sollten so gestaltet sein, dass sie ohne Einblick in vertrauliche Gesprächsinhalte auskommen.
   

Diese Trennung folgt dem sogenannten Need-to-Know-Prinzip: Zugriff erhält nur, wer ihn für seine konkrete Aufgabe tatsächlich benötigt – technischer Betrieb ist dabei etwas anderes als inhaltliche Beratungsarbeit.
 

⚠️ Warum das wichtig ist: Unkontrollierte Zugriffe – etwa wenn Admin-Rechte automatisch auch Leserechte auf Inhalte einschließen – können zu Datenschutzverstößen führen. Mindestens genauso schwer wiegt der Vertrauensverlust: Beratung lebt von der Gewissheit, dass das Gesagte wirklich vertraulich bleibt. Wo unklar ist, wer mitlesen könnte, leidet dieses Vertrauensverhältnis zwischen Ratsuchenden und Beratenden.

Ein gutes System arbeitet mit klar definierten Rollen – etwa Beratung, Administration oder Supervision. Jede Rolle bekommt genau die Rechte, die sie für ihre Aufgabe braucht. Nicht mehr.
 

Dieses Prinzip nennt sich rollenbasierte Zugriffskontrolle (RBAC): Statt jeder einzelnen Person individuell Rechte zuzuweisen, werden Berechtigungen an Rollen geknüpft. Wird eine Person einer Rolle zugeordnet, erhält sie automatisch genau die dazugehörigen Rechte – nicht mehr und nicht weniger. Das hat zwei Vorteile: Es ist übersichtlicher zu verwalten, und es reduziert das Risiko, dass aus Versehen zu weitreichende Rechte vergeben werden.
 

Konkret lohnt es sich zu fragen:
 

• Welche Rollen gibt es im System, und wie unterscheiden sie sich (z. B. Beraterin, Administratorin, Supervisor*in)?
• Was genau darf jede Rolle sehen oder bearbeiten – nur lesen, oder auch verändern?
• Lässt sich das granular einstellen, oder gibt es nur grobe, feste Berechtigungsstufen?
   

⚠️ Warum das wichtig ist: Klar abgegrenzte Rollen verhindern, dass sensible Informationen unnötig vielen Personen zugänglich sind. Je genauer die Rechte auf die tatsächliche Aufgabe zugeschnitten sind, desto kleiner ist der Kreis derer, die im Zweifel Zugriff auf vertrauliche Beratungsinhalte hätten.

Das Need-to-Know-Prinzip geht noch einen Schritt weiter als das Rollenkonzept aus der vorherigen Frage: Nutzer*innen erhalten nur Zugriff auf genau die Informationen, die sie für ihre konkrete Aufgabe benötigen – nicht nur grob passend zu ihrer Rolle, sondern möglichst fallbezogen.
 

Der Unterschied zum reinen Rollenkonzept lässt sich an einem Beispiel zeigen: Eine Rolle wie "Beratung" regelt zunächst nur, dass jemand grundsätzlich Beratungsinhalte einsehen darf. Das Need-to-Know-Prinzip schränkt das zusätzlich ein – etwa so, dass Berater*innen nur auf die ihnen zugeteilten Beratungsfälle zugreifen können, nicht automatisch auf alle Fälle im System.
 

Wichtig für die Umsetzung:

• Zugriffe sind an konkrete Zuständigkeiten geknüpft, nicht nur an eine grobe Rollenzugehörigkeit.
• Zugriffsrechte werden regelmäßig überprüft und angepasst, etwa wenn sich Zuständigkeiten ändern.
• Ein Negativbeispiel wäre die Vergabe von Rechten allein nach Hierarchiestufe – etwa wenn eine Leitungsposition automatisch auf alle Inhalte zugreifen kann, unabhängig davon, ob das für die Aufgabe wirklich nötig ist.
   

⚠️ Warum das wichtig ist: Das Need-to-Know-Prinzip reduziert das Risiko von Datenmissbrauch und ist ein zentraler Grundsatz der DSGVO. Es sorgt dafür, dass selbst innerhalb einer berechtigten Gruppe (z. B. "alle Berater*innen") nicht automatisch jede Person Zugriff auf alle Inhalte hat.

Auswertungen wie Statistiken oder Evaluationsergebnisse wirken harmlos, da es meist nur um Zahlen geht. Trotzdem können auch sie Rückschlüsse auf einzelne Personen zulassen – etwa bei kleinen Gruppen oder sehr spezifischen Merkmalskombinationen.
 

Zwei Schutzverfahren machen hier den entscheidenden Unterschied:

• Pseudonymisierung: Namen werden durch Kennungen ersetzt, der Personenbezug bleibt aber grundsätzlich herstellbar – mit Zugriff auf die passende Zuordnungstabelle. Gilt weiterhin als personenbezogene Daten.
• Anonymisierung: Der Personenbezug wird unwiderruflich entfernt, eine Rückverfolgung ist nicht mehr möglich – nur echte Anonymisierung nimmt Daten aus dem Anwendungsbereich der DSGVO heraus.
   

Noch besser als eine nachträgliche Anonymisierung ist es, wenn bestimmte Auswertungen von vornherein ganz ohne Personenbezug konzipiert sind – etwa reine Nutzungsstatistiken (Anzahl Nachrichten, Termine o. Ä.), die gar keine identifizierenden Daten erfassen. Bei individuell konfigurierbaren Auswertungen wie Umfragen oder Evaluationen hängt der Schutzgrad dagegen von der jeweiligen Einstellung ab und sollte gezielt geprüft werden.
 

Auch hier gilt: Der Zugriff auf Auswertungen sollte eingeschränkt sein, nicht automatisch jeder Rolle offenstehen.
 

⚠️ Warum das wichtig ist: Auch scheinbar anonyme Auswertungen können bei kleinen Gruppen Rückschlüsse auf einzelne Personen zulassen. Der Unterschied zwischen "pseudonymisiert" und "wirklich anonymisiert" – und ob Personenbezug von Anfang an vermieden wird – entscheidet, wie geschützt die Daten tatsächlich sind.

Im Idealfall ist das technisch ausgeschlossen – nicht nur organisatorisch untersagt, sondern durch die Systemarchitektur selbst verhindert. Das betrifft drei unterschiedliche Zugriffsarten, die man einzeln betrachten sollte:
 

• Einsehen: Kann der Dienstleister Beratungsinhalte im Klartext lesen? Bei konsequenter Verschlüsselung (siehe vorherige Fragen) sollte das technisch nicht möglich sein – der Anbieter hätte schlicht keinen Schlüssel dazu.
• Exportieren: Selbst wenn ein direktes Einsehen ausgeschlossen ist, stellt sich die Frage, ob verschlüsselte Inhalte kopiert oder exportiert werden könnten. Auch das sollte technisch unterbunden oder zumindest streng kontrolliert und protokolliert sein.
• Verändern: Über die reine Vertraulichkeit hinaus geht es auch um Integrität – also darum, dass Inhalte nicht unbemerkt manipuliert werden können. Dafür helfen etwa Prüfsummen oder digitale Signaturen, mit denen sich nachträgliche Veränderungen erkennen lassen, sowie Audit-Logs, die protokollieren, wer wann auf was zugegriffen oder etwas verändert hat.
   

⚠️ Warum das wichtig ist: Vertraulichkeit ist die Grundlage jeder Beratung und muss technisch sichergestellt sein – nicht nur vertraglich zugesichert. Ein Zugriff durch Dritte, ob lesend oder verändernd, wäre ein erheblicher Datenschutzverstoß und würde das Vertrauen in die Beratung grundsätzlich infrage stellen.

Anders als bei den eigentlichen Beratungsinhalten (siehe vorherige Frage) sind bei reinen Nutzerdaten – etwa Name, Kontaktdaten oder E-Mail-Adresse – gewisse Zugriffe durch den Dienstleister oft technisch notwendig, etwa um bei Problemen mit dem Konto zu helfen. Entscheidend ist aber: Wenn überhaupt, dann nur sehr eingeschränkt und im Rahmen klar geregelter Support-Prozesse.
 

Ein solcher Prozess sollte typischerweise so aussehen:

• Anlassbezogen: Zugriff nur bei einem konkreten Anliegen (z. B. einer Support-Anfrage), nicht routinemäßig oder pauschal.
• Zeitlich begrenzt: Der Zugriff endet mit der Bearbeitung des jeweiligen Falls, statt dauerhaft bestehen zu bleiben.
• Protokolliert: Es ist nachvollziehbar, wer wann auf welche Daten zugegriffen hat.
• Auf das Nötigste beschränkt: Der Support sieht nur, was für die Problemlösung wirklich gebraucht wird – nicht automatisch den vollen Datensatz.
   

⚠️ Warum das wichtig ist: Personenbezogene Daten müssen besonders geschützt werden. Unnötige oder dauerhafte Zugriffe erhöhen das Risiko von Datenmissbrauch, selbst wenn sie zunächst nur mit guten Absichten (z. B. für den Support) eingerichtet wurden.

Auf den ersten Blick mag es überraschend klingen: Auch die Beratungsstelle selbst – also die eigene Organisation – sollte nicht automatisch Zugriff auf die E-Mail-Adressen ihrer Ratsuchenden haben. Der Zugriff sollte bewusst eingeschränkt bleiben, um die Anonymität zu schützen.
 

Der Grund dahinter liegt im Wesen guter Online-Beratung: Viele Ratsuchende nutzen solche Angebote gerade deshalb, weil sie anonym bleiben können – etwa bei sensiblen oder gesellschaftlich tabuisierten Themen. Eine Registrierung erfolgt oft bewusst nur mit einem frei wählbaren Nutzernamen, ganz ohne Klarnamen. Die Angabe einer E-Mail-Adresse ist dabei häufig freiwillig und dient nur einem technischen Zweck, etwa um über neue Nachrichten benachrichtigt zu werden oder Passworte zurücksetzen zu können – nicht dazu, die Person zu identifizieren.
 

⚠️ Warum das wichtig ist: Weniger sichtbare Daten bedeuten mehr Schutz für die Privatsphäre der Ratsuchenden. Gerade bei schambesetzten oder heiklen Themen kann schon das Wissen, dass die eigene Organisation die E-Mail-Adresse einsehen könnte, eine Hürde sein, sich überhaupt zu öffnen – die Anonymität ist hier also kein Nebeneffekt, sondern Teil der eigentlichen Schutzwirkung des Angebots.

Ein gutes System bietet ein Rollenkonzept, das sich an die jeweilige Organisationsstruktur der Beratungsstelle anpassen lässt – statt ein starres Schema für alle vorzugeben. Das ist deshalb relevant, weil sich Organisationen stark unterscheiden können: eine kleine Einzelberatungsstelle braucht andere Rollen als eine große Beratungsstelle mit mehreren Teams, Supervision oder verschiedenen Standorten.
 

Mandantenindividuell bedeutet dabei: Jede Beratungsstelle kann ihr eigenes Rollenkonzept einrichten, unabhängig von anderen Beratungsstellen auf derselben Plattform. Konkret lohnt es sich zu fragen:
 

• Können eigene Rollen definiert werden, oder gibt es nur ein festes, unveränderliches Set?
• Lassen sich Berechtigungen granular anpassen (z. B. lesen vs. bearbeiten), oder nur grob (alles oder nichts)?
• Bleiben die Einstellungen einer Beratungsstelle unabhängig von denen anderer Mandanten auf derselben Plattform?
   

⚠️ Warum das wichtig ist: Nur ein flexibles Rollenkonzept lässt sich sinnvoll mit den tatsächlichen Datenschutzanforderungen und Abläufen der eigenen Organisation verbinden. Ein zu starres System zwingt Beratungsstellen entweder dazu, mit unpassenden Rollen zu arbeiten, oder Rechte großzügiger zu vergeben, als es das Need-to-Know-Prinzip eigentlich vorsieht.

Datenminimierung bedeutet: Es werden nur die Daten erhoben, die für den jeweiligen Zweck wirklich notwendig sind – alles andere wird vermieden. Das lässt sich sowohl technisch als auch organisatorisch umsetzen:
 

• Technisch: Formulare fragen nur echte Pflichtfelder ab; alles Weitere ist klar erkennbar optional. Die Grundeinstellung des Systems erfasst standardmäßig nur das Nötigste – wer darüber hinaus mehr Daten teilen möchte, muss das aktiv einstellen, statt dass mehr Daten voreingestellt sind und man dem aktiv widersprechen müsste.
• Organisatorisch: Es gibt klare Regeln, welche Daten für welchen Zweck überhaupt erhoben werden dürfen, sowie ein Löschkonzept, das festlegt, wie lange Daten aufbewahrt und wann sie automatisch gelöscht werden.
   

⚠️ Warum das wichtig ist: Weniger Daten bedeuten weniger Risiko – ein zentraler Grundsatz der DSGVO. Was gar nicht erst erhoben oder rechtzeitig gelöscht wird, kann bei einem Datenleck auch nicht in falsche Hände geraten.

Diese beiden Begriffe beschreiben zwei unterschiedliche Zeitpunkte, an denen Datenschutz berücksichtigt wird:
 

• Datenschutz by Design ("Datenschutz durch Technikgestaltung"): Datenschutz wird schon bei der Entwicklung eines Systems mitgedacht – nicht erst nachträglich ergänzt. Verschlüsselung, Zugriffskontrollen oder Löschroutinen sind von Anfang an Teil der Architektur, nicht ein Add-on, das später aufgesetzt wird.
• Datenschutz by Default ("datenschutzfreundliche Voreinstellungen"): Die Grundeinstellungen eines Systems bieten von sich aus den größtmöglichen Datenschutz. Betroffen sind dabei insbesondere die Menge der erhobenen Daten, wie lange sie gespeichert werden und wer Zugriff darauf hat.
   

Der Unterschied lässt sich so zusammenfassen: By Design betrifft die Systemarchitektur als Ganzes, by Default die konkrete Werkseinstellung, mit der Nutzer*innen das System zum ersten Mal vorfinden.
 

⚠️ Warum das wichtig ist: Nutzer*innen müssen nicht selbst aktiv werden, um ihre Daten zu schützen – der Schutz ist bereits voreingestellt, statt von individuellem Fachwissen oder aktivem Handeln abzuhängen. Das kommt besonders jenen zugute, die sich mit Datenschutzeinstellungen nicht im Detail auskennen oder auskennen möchten.

Werden mehrere Organisationen (z. B. verschiedene Beratungsstellen) auf derselben Plattform bedient, spricht man von Mandantenfähigkeit. Entscheidend ist dabei: Die Daten der einen Organisation dürfen technisch niemals mit denen einer anderen vermischt oder versehentlich sichtbar werden.
 

Für die technische Umsetzung gibt es unterschiedliche Ansätze mit unterschiedlichem Schutzniveau:
 

• Gemeinsame Datenbank mit Mandanten-Kennung: Alle Organisationen teilen sich dieselbe Datenbank; jeder Datensatz ist mit einer Kennung versehen, welcher Organisation er gehört. Die Trennung erfolgt dann auf Software-Ebene bei jeder Abfrage – kostengünstig, aber fehleranfälliger, falls diese Kennung einmal übersehen wird.
• Eigene Tabellen oder eigenes Datenbank-Schema je Organisation: Etwas stärkere Trennung innerhalb derselben Datenbank.
• Vollständig eigene Datenbank je Organisation: Das höchste Schutzniveau – ein technischer Fehler in einer Abfrage kann dann grundsätzlich nicht dazu führen, dass Daten einer anderen Organisation sichtbar werden, weil physisch getrennte Datenbestände vorliegen.
   

Je sensibler die verarbeiteten Daten, desto anspruchsvoller sollte die gewählte Trennung ausfallen.
 

⚠️ Warum das wichtig ist: So wird verhindert, dass Daten zwischen Organisationen vermischt oder versehentlich eingesehen werden. Gerade bei einer gemeinsamen Datenbank mit reiner Software-Trennung hängt die Sicherheit stark davon ab, dass jede einzelne Abfrage im System korrekt implementiert ist – ein einziger Programmierfehler kann sonst die Trennung durchbrechen.

Benutzerkonten sind eines der beliebtesten Angriffsziele – meist nicht durch komplexe Hacking-Methoden, sondern durch erratene, wiederverwendete oder gestohlene Passwörter. Ein gutes System schützt Konten deshalb über mehrere Ebenen hinweg:
 

• Mehr-Faktor-Authentifizierung (MFA): Neben dem Passwort ist ein zweiter Nachweis nötig, z. B. ein Code per App oder E-Mail. Das ist mit Abstand die wirksamste Einzelmaßnahme – laut Auswertungen großer Anbieter werden dadurch über 99 % automatisierter Angriffsversuche verhindert, da ein gestohlenes Passwort allein nicht mehr ausreicht.
• Sichere Passwort-Anforderungen: Mindestlänge, Komplexität und ein Abgleich mit Listen bekannter, häufig geknackter Passwörter verhindern besonders leicht zu erratende Kennwörter.
• Kontosperrung nach Fehlversuchen: Nach einer bestimmten Anzahl falscher Login-Versuche wird ein Konto vorübergehend gesperrt – das bremst automatisierte Angriffe, bei denen viele Passwörter am Stück ausprobiert werden.
• Sitzungs-Timeout: Inaktive Sitzungen werden automatisch beendet, sodass ein offen gelassenes, eingeloggtes Gerät nicht dauerhaft angreifbar bleibt.
   

⚠️ Warum das wichtig ist: Benutzerkonten sind ein häufiger Angriffspunkt. Ein unbefugter Zugriff kann weitreichende Folgen haben – von eingesehenen Beratungsinhalten bis zur missbräuchlichen Nutzung des Kontos selbst. Da die einzelnen Maßnahmen unterschiedliche Angriffswege abdecken, bietet erst ihr Zusammenspiel einen verlässlichen Schutz.

Sichere Systeme lassen solche sensiblen Vorgänge nicht einfach automatisch durchlaufen, sondern definieren klare Abläufe mit Prüfungen und Protokollierung. Typischerweise gehört dazu:
 

• Freigabe durch eine übergeordnete Rolle: Kritische Änderungen – etwa das Anlegen eines neuen Accounts, eine Rechteänderung oder die Wiederherstellung nach einem Passwort-Reset – erfordern die Bestätigung einer dafür zuständigen Person, statt automatisch wirksam zu werden.
• Benachrichtigung Beteiligter: Werden Nutzerdaten geändert oder Accounts gelöscht, sollten alle zuständigen Verantwortlichen automatisch informiert werden. So bleiben Änderungen nachvollziehbar, statt unbemerkt zu geschehen.
• Nachvollziehbarkeit: Wer eine Änderung wann vorgenommen hat, sollte protokolliert und im Zweifel überprüfbar sein.
   

⚠️ Warum das wichtig ist: Gerade hier – bei Passwort-Resets, neuen Accounts oder Rechteänderungen – besteht ein erhöhtes Missbrauchsrisiko: Wer sich unbefugt Zugriff auf einen dieser Prozesse verschafft, könnte sich selbst weitreichende Rechte einräumen. Klare Freigabe- und Prüfprozesse verhindern, dass solche Änderungen unbemerkt oder ohne Kontrolle erfolgen.

Wichtig ist hier die Unterscheidung zwischen zwei verschiedenen Dingen: der Mailberatung als Funktion innerhalb der Plattform (dort gelten die in einer früheren Frage beschriebenen Verschlüsselungsmechanismen) und dem Versand über reguläre E-Mail – etwa Benachrichtigungsmails an das private E-Mail-Postfach einer Person, wenn eine neue Nachricht eingegangen ist.
 

Bei regulärer E-Mail gilt: Wenn überhaupt, dann nur eingeschränkt und abgesichert. Sensible Beratungsinhalte sollten dort gar nicht erst landen. Der Grund liegt in der Funktionsweise von E-Mail selbst:
 

• Transportverschlüsselung ist nicht automatisch Inhaltsverschlüsselung: Auch wenn eine E-Mail beim Versand verschlüsselt übertragen wird (TLS), heißt das nicht, dass der Inhalt durchgehend geschützt ist – auf den Mailservern unterwegs liegt er oft unverschlüsselt vor.
• Metadaten bleiben immer sichtbar: Absender, Empfänger und Betreff lassen sich technisch kaum verschlüsseln, selbst bei inhaltsverschlüsselten E-Mails. Schon ein Betreff wie "Ihre Beratungsanfrage zu [Thema]" könnte mehr preisgeben, als beabsichtigt.
• Datenschutzkonforme Alternative: Statt Inhalte direkt per E-Mail zu verschicken, sollte eine E-Mail höchstens ein neutraler Hinweis sein ("Sie haben eine neue Nachricht") mit einem Link zur gesicherten Plattform – die eigentlichen Inhalte bleiben dort, wo sie durch die stärkeren Schutzmechanismen abgesichert sind.
   

⚠️ Warum das wichtig ist: E-Mail ist oft kein sicherer Kanal und kann leicht abgefangen werden – ein unverschlüsselter E-Mail-Versand lässt sich mit einer Postkarte vergleichen, deren Inhalt für jeden lesbar ist, der sie auf dem Weg in die Hände bekommt.

Solche Eingriffe sollten – wenn überhaupt – stark eingeschränkt und klar geregelt sein. Bei einem konsequent verschlüsselten System ist das ohnehin nur begrenzt möglich, denn Passwort und Schlüssel hängen technisch eng zusammen: Wird ein Schlüssel mit einem Wert verschlüsselt, der aus dem persönlichen Passwort abgeleitet ist (wie in früheren Fragen beschrieben), kann ein Anbieter das Passwort nicht einfach "zurücksetzen", ohne dass der zugehörige Schlüssel unbrauchbar wird – und damit auch alle bisherigen, damit verschlüsselten Inhalte.
 

Ein datenschutzfreundliches System zeichnet sich entsprechend dadurch aus, dass:
 

• Passwörter grundsätzlich nur von der Person selbst gesetzt werden – nicht vom Support oder von Administrator*innen.
• Ein Passwort-Reset durch den Dienstleister, falls überhaupt möglich, technisch zu einer Neuerzeugung des Schlüssels führt und alte Inhalte damit nicht mehr lesbar sind – statt dass der Anbieter einfach Zugriff auf die alten, verschlüsselten Daten erhält.
• Solche Eingriffe protokolliert sind und nachvollziehbar bleiben.
   

⚠️ Warum das wichtig ist: Unkontrollierte Änderungen könnten Sicherheitsmechanismen aushebeln – etwa wenn ein Anbieter Passwörter beliebig setzen und sich damit selbst Zugriff auf Konten verschaffen könnte. Die technische Unmöglichkeit eines "sauberen" Resets ist hier kein Komfort-Nachteil, sondern ein Zeichen dafür, dass die Verschlüsselung tatsächlich wirksam ist.

Manche Software-Systeme bieten bewusst eine sogenannte Impersonation-Funktion: Support-Mitarbeitende können sich damit ohne Passwort als eine bestimmte Nutzer*in anmelden, um z. B. bei einem Problem direkt zu sehen, was diese Person sieht. Was für den technischen Support praktisch klingt, ist bei einer vertraulichen Beratungsplattform hochkritisch – ein sicheres System verhindert das durch technische Maßnahmen und Protokollierung.
 

Worauf es ankommt:

• Technisch ausgeschlossen statt nur organisatorisch untersagt: Im Idealfall gibt es gar keine solche Funktion im System – nicht nur eine interne Regel, die sie verbietet. Bei konsequenter Verschlüsselung (siehe frühere Fragen) wäre ein "Anmelden als" ohnehin nutzlos, da ohne den passwortabhängigen persönlichen Schlüssel keine Inhalte lesbar wären.
• Falls doch vorhanden, dann stark eingeschränkt: Manche Systeme erlauben solche Funktionen nur zeitlich begrenzt, nur für bestimmte Rollen und mit vorheriger Zustimmung der betroffenen Person.
• Lückenlose Protokollierung: Jeder Zugriffsversuch dieser Art sollte nachvollziehbar dokumentiert sein.
   

⚠️ Warum das wichtig ist: Imitation würde das Vertrauen in die Beratung grundlegend zerstören und ist datenschutzrechtlich hochproblematisch. Wenn ein Anbieter sich als Nutzer*in ausgeben könnte, wäre die gesamte Vertraulichkeit der Beratung – unabhängig von allen anderen Sicherheitsmaßnahmen – nur noch eine Frage des Vertrauens in diesen einen Anbieter, statt technisch abgesichert.