Vertrauen & Recht

Technische und organisatorische Maßnahmen

Sicherheitsmaßnahmen zum Schutz personenbezogener Daten und Gesundheitsdaten.

Version 2.1 Stand: 26.08.2026 Gültig ab: 26.08.2026 Zielgruppe: Praxen, Datenschutzverantwortliche, Investoren und Partner Betreiber: Flurin UG (haftungsbeschränkt)

Technische und organisatorische Maßnahmen (TOM)

Dokument: Technische und organisatorische Maßnahmen – Anlage zum Vertrag zur Auftragsverarbeitung
Version: 2.1
Stand: 26.08.2026
Anbieter: Flurin UG (haftungsbeschränkt), Freiburger Straße 25, 79853 Lenzkirch, Amtsgericht Freiburg HRB 736327, vertreten durch den Geschäftsführer Jan Jerusalem
Datenschutzbeauftragter: heyData GmbH, Schützenstraße 5, 10117 Berlin, www.heydata.eu, datenschutz@heydata.eu

1. Zweck dieses Dokuments

1.1 Zweck der TOM

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen von Flurin zum Schutz personenbezogener Daten, insbesondere Patientendaten und Gesundheitsdaten, die über die Flurin-Plattform verarbeitet werden.

Die Maßnahmen dienen dazu, ein dem Risiko angemessenes Schutzniveau sicherzustellen und insbesondere Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung personenbezogener Daten zu gewährleisten.

1.2 Verhältnis zum Vertrag zur Auftragsverarbeitung

Diese TOM sind Bestandteil des Vertrags zur Auftragsverarbeitung zwischen Flurin und der jeweiligen Praxis.

Soweit in diesem Dokument Maßnahmen beschrieben werden, konkretisieren sie die Pflichten von Flurin als Auftragsverarbeiter im Sinne von Art. 28 und Art. 32 DSGVO.

1.3 Risikoorientiertes Sicherheitsmodell

Die TOM sind so ausgestaltet, dass sie wirksam umgesetzt, nachgewiesen und regelmäßig überprüft werden können. Zugriffe werden nach Need-to-know und Least-Privilege vergeben, kritische Vorgänge nachvollziehbar protokolliert und technische Schutzmechanismen soweit möglich systemisch erzwungen.

1.4 Aktualisierung der TOM

Flurin entwickelt diese TOM unter Berücksichtigung des Standes der Technik, der Implementierungskosten, der Art, des Umfangs, der Umstände und Zwecke der Verarbeitung sowie der Eintrittswahrscheinlichkeit und Schwere möglicher Risiken fortlaufend weiter.

Änderungen, die das Sicherheitsniveau nicht wesentlich unterschreiten, gelten als zulässige Weiterentwicklung. Wesentliche Änderungen werden der Praxis in geeigneter Weise mitgeteilt.

2. Geltungsbereich und Systemübersicht

2.1 Sachlicher Geltungsbereich

Diese TOM gelten für die Verarbeitung personenbezogener Daten über die Flurin-Plattform, insbesondere für:

digitale Aufnahmeformulare,
Wartelistenmanagement,
Terminlücken- und Springersystem-Funktionen,
Patientenkommunikation,
Nutzer- und Praxisverwaltung,
Protokollierungs- und Sicherheitsfunktionen,
Support- und Administrationsprozesse,
Datenexporte und Löschprozesse.

2.2 Personenbezogener Geltungsbereich

Diese TOM erfassen insbesondere personenbezogene Daten folgender Personengruppen:

Patientinnen und Patienten,
Praxisinhaberinnen und Praxisinhaber,
Mitarbeitende der Praxis,
administrative Nutzerinnen und Nutzer,
Kontaktpersonen,
Supportanfragende,
Flurin-Teammitglieder und beauftragte Dienstleister, soweit diese Zugriff auf Systeme oder Daten erhalten können.

2.3 Besondere Schutzbedürftigkeit von Gesundheitsdaten

Über die Flurin-Plattform können Gesundheitsdaten im Sinne der DSGVO verarbeitet werden.

Flurin berücksichtigt diese besondere Schutzbedürftigkeit durch erhöhte Anforderungen an Zugriffskontrolle, Verschlüsselung, Mandantentrennung, Protokollierung, Vertraulichkeit, Löschung, Subunternehmerauswahl und Sicherheitsprüfung.

2.4 Aktuelle technische Architektur

Die technische Produktivarchitektur ist wie folgt klassifiziert:

Komponente	Anbieter / Ort	Funktion	Daten-/Rollenhinweis
Marketing-Frontend, App-Frontend, CDN, DNS	Bunny.net / BunnyWay d.o.o.	statische Auslieferung und DNS	technische Zugriffsdaten; keine planmäßige Speicherung der produktiven Backend-Datenbank oder privaten Verordnungsobjekte
Domainregistrierung	United-Domains	Domainverwaltung	Flurin-Unternehmens-/Domain-Daten; keine Patientendaten im Auftrag
Backend/API	Hetzner, Deutschland	Geschäftslogik und geschützte Verarbeitung	Praxis-, Patienten-, Gesundheits- und technische Daten
PostgreSQL	Hetzner, Deutschland	produktive strukturierte Plattformdaten	Praxis-, Patienten- und Gesundheitsdaten
Private Dateiablage	Hetzner Object Storage, S3-kompatibel, Deutschland	Verordnungsbild-Uploads	private Gesundheits-/Patientendaten; kein öffentlicher Bucket
Datenbank-Backups	Hetzner Storage Box	verschlüsselte Sicherungen	verschlüsselte Kopien produktiver DB-Daten
Identity Management	Hanko GmbH	Authentifizierung von Praxisnutzern	Nutzer-/Login-/Authentifizierungsdaten; keine planmäßigen Patientendaten
E-Mail / SMS	Brevo	transaktionale Kommunikation	Empfänger-/Kontaktdaten, datensparsame Inhalte, Versand-/Zustellmetadaten; SMS praxisweise aktivierbar
WhatsApp Business	Meta Platforms Ireland Limited, optional	neutrale WhatsApp-Benachrichtigungen	nur bei Praxisaktivierung und WhatsApp-Einwilligung; keine sensiblen Detailinhalte im Nachrichtentext
Monitoring/Logs	Grafana, Loki, Alloy, Uptime Kuma self-hosted auf Hetzner	Betrieb/Sicherheit	minimierte technische IDs/Hashes; Prod-Logs 30 Tage, QA 14 Tage
Externe Verfügbarkeitsprüfung	Euronodes	unabhängige Endpoint-/Uptime-Prüfung	keine Patientendaten vorgesehen
Billing	Stripe	eigene Vertrags-/Zahlungsabwicklung Flurin ↔ Praxis	kein Praxis-Patientenprozess; eigener Verantwortungsbereich von Flurin
Signup-Attribution	Google BigQuery	eigene Produkt-/Vertriebsanalyse	keine Patientendaten; eigener Verantwortungsbereich von Flurin

Die konkrete Auftragsverarbeiter-/Verantwortlichenrolle wird im AVV, VVT und den Datenschutzerklärungen getrennt dokumentiert.

2.5 Architekturannahme für Bunny.net, DNS und Domainregistrierung

Bunny.net wird für die Auslieferung statischer Frontends und für die Verwaltung der DNS-Einträge genutzt. Produktive Patientendaten werden nach aktueller Architektur nicht in Bunny.net gespeichert. API-Aufrufe und Datenbankoperationen erfolgen über Backend-Systeme bei Hetzner.

DNS-Dienste können technische Anfragedaten verarbeiten, enthalten aber keine Inhalte aus der Flurin-App, keine Backend-Datenbankinhalte und keine Patientendatensätze.

Die Domainregistrierung erfolgt über United-Domains. United-Domains verarbeitet hierfür Domain-, Vertrags-, Rechnungs- und Administrationsdaten von Flurin, jedoch keine produktiven Praxis-, Patienten- oder Gesundheitsdaten.

Sollte Bunny.net künftig als Proxy für API-Anfragen, Uploads, Patienteninhalte oder andere Backend-Daten eingesetzt werden, wird die Datenschutz- und Sicherheitsbewertung aktualisiert.

3. Grundprinzipien der Informationssicherheit

3.1 Need-to-know-Prinzip

Zugriffe auf personenbezogene Daten werden nach dem Grundsatz der Erforderlichkeit vergeben.

Teammitglieder, Administratoren und Dienstleister erhalten nur Zugriff auf diejenigen Systeme und Daten, die sie zur Erfüllung ihrer Aufgaben benötigen.

3.2 Least-Privilege-Prinzip

Berechtigungen werden grundsätzlich mit dem geringstmöglichen erforderlichen Umfang vergeben.

Administrative Rechte werden nur an besonders autorisierte Personen vergeben und regelmäßig überprüft.

3.3 Mandantentrennung

Daten einzelner Praxen werden logisch voneinander getrennt verarbeitet.

Nutzerinnen und Nutzer einer Praxis erhalten keinen Zugriff auf Daten anderer Praxen, sofern hierfür keine ausdrückliche technische und rechtliche Grundlage besteht.

3.4 Privacy by Design und Privacy by Default

Flurin berücksichtigt Datenschutz und Datensicherheit bereits bei Konzeption, Entwicklung und Betrieb der Plattform.

Standardmäßig werden nur solche personenbezogenen Daten verarbeitet, die für den jeweiligen Zweck erforderlich sind.

3.5 Datenminimierung

Aufnahmeformulare, Wartelisteneinträge und Kommunikationsprozesse werden so gestaltet, dass nur erforderliche personenbezogene Daten abgefragt und verarbeitet werden.

Optionale Angaben werden, soweit möglich, entsprechend gekennzeichnet.

3.6 Vertraulichkeit

Alle Personen, die Zugriff auf personenbezogene Daten oder sicherheitsrelevante Systeme erhalten können, werden zur Vertraulichkeit verpflichtet.

Dies gilt insbesondere für Gründer, Mitarbeitende, freie Mitarbeitende, technische Dienstleister und sonstige beauftragte Personen.

3.7 Keine Produktivdaten in Entwicklung und Tests

Produktive Patientendaten werden grundsätzlich nicht in Entwicklungs-, Test- oder lokalen Umgebungen verwendet.

Für Entwicklung und Tests werden synthetische, anonymisierte oder stark pseudonymisierte Daten genutzt. Ausnahmen bedürfen einer dokumentierten Erforderlichkeit, zusätzlicher Schutzmaßnahmen und anschließender Löschung.

4. Organisation der Informationssicherheit

4.1 Verantwortlichkeiten

Flurin weist intern Verantwortlichkeiten für Datenschutz, Informationssicherheit und technische Plattform-Sicherheit zu. Mindestens werden folgende Verantwortungsbereiche abgedeckt:

Datenschutzkoordination,
Informationssicherheit,
technische Plattform- und Infrastruktur-Sicherheit,
Incident Response und Kundenkommunikation,
Anbieter- und Unterauftragsverarbeiterprüfung.

Personelle Mehrfachrollen sind zulässig, soweit erforderliche Kontrollen, Nachvollziehbarkeit und Berechtigungsgrenzen gewahrt bleiben.

4.2 Schlanke Dokumentation

Flurin dokumentiert datenschutz- und sicherheitsrelevante Entscheidungen in einer einfachen, nachvollziehbaren Form.

Ausreichend sind insbesondere:

Eintrag in einem internen Dokument,
Eintrag im internen Änderungs-/Ticketsystem,
kurzer Entscheidungsvermerk,
E-Mail- oder Protokollnotiz.

Dokumentiert werden insbesondere Entscheidungen zu:

neuen Unterauftragsverarbeitern,
Hosting-Regionen,
Zugriffen und Berechtigungen,
Datenlöschung,
Exportfunktionen,
Backup-Strategie,
Sicherheitsvorfällen,
neuen Produktfunktionen mit Datenschutzbezug.

4.3 Interne Mindestregeln

Flurin unterhält interne Mindestregeln zu:

Zugriffen und Berechtigungen,
sicherer Softwareentwicklung,
Nutzung von Produktivdaten,
Supportzugriffen,
Passwort- und MFA-Nutzung,
Endgerätesicherheit,
Umgang mit Sicherheitsvorfällen,
Umgang mit Unterauftragsverarbeitern,
Löschung und Aufbewahrung,
Dokumentation von Änderungen.

Diese Mindestregeln können als kurze Checklisten geführt werden.

4.4 Schulung und Sensibilisierung

Personen mit Zugriff auf personenbezogene Daten oder sicherheitsrelevante Systeme werden vor Zugriffsvergabe und danach regelmäßig zu Datenschutz, Informationssicherheit, Phishing-Risiken, sicherem Arbeiten und Vertraulichkeit sensibilisiert.

Eine dokumentierte interne Sensibilisierung erfolgt mindestens anhand einer Datenschutz- und Sicherheitscheckliste und wird bei relevanten Änderungen aktualisiert.

4.5 Regelmäßige Kurzprüfung

Flurin führt mindestens quartalsweise eine kurze dokumentierte Sicherheits- und Datenschutzprüfung durch.

Diese Kurzprüfung umfasst mindestens:

aktive Team- und Adminzugänge,
aktive Unterauftragsverarbeiter,
Backupstatus,
offene sicherheitsrelevante Updates,
wesentliche Änderungen an Datenflüssen,
offene Datenschutz- oder Sicherheitsvorfälle.

5. Zutrittskontrolle

5.1 Ziel der Zutrittskontrolle

Ziel der Zutrittskontrolle ist es, Unbefugten den physischen Zutritt zu Datenverarbeitungsanlagen zu verwehren, mit denen personenbezogene Daten verarbeitet werden.

5.2 Cloudbasierter Betrieb

Flurin betreibt die Plattform grundsätzlich cloudbasiert.

Produktivsysteme werden in Rechenzentren professioneller Hostinganbieter betrieben. Eigene Server in Büro- oder Privaträumen werden für produktive Patientendaten nicht eingesetzt.

5.3 Rechenzentrumsstandorte

Produktive Backend- und Datenbanksysteme werden aktuell bei Hetzner in Deutschland betrieben.

Produktive Patientendaten und Gesundheitsdaten werden nach aktuellem Betriebsmodell auf Backend- und Datenbanksystemen in Deutschland gespeichert.

5.4 Physische Sicherheit der Rechenzentren

Flurin wählt Hosting- und Infrastruktur-Anbieter aus, die geeignete Maßnahmen zur physischen Sicherheit ihrer Rechenzentren vorhalten.

Hierzu gehören typischerweise:

Zutrittskontrollsysteme,
Sicherheitsüberwachung,
Besuchermanagement,
Brandschutz,
Klimatisierung,
redundante Stromversorgung,
Notfallkonzepte.

Die konkrete Ausgestaltung richtet sich nach den Nachweisen des jeweiligen Anbieters.

5.5 Büro-, Homeoffice- und Arbeitsplatzsicherheit

Soweit Flurin-Teammitglieder oder beauftragte Personen in Büro-, Homeoffice- oder Co-Working-Umgebungen arbeiten, werden geeignete organisatorische Maßnahmen getroffen, um unbefugte Einsichtnahme oder Zugriffnahme zu verhindern.

Hierzu gehören insbesondere:

Bildschirmsperre bei Abwesenheit,
keine unbeaufsichtigten Ausdrucke mit personenbezogenen Daten,
Clean-Desk-Grundsätze für vertrauliche Informationen,
keine Speicherung produktiver Patientendaten auf privaten Datenträgern,
verschlüsselte Endgeräte für administrative Tätigkeiten,
keine Nutzung fremder oder öffentlicher Geräte für administrative Zugriffe.

6. Zugangskontrolle

6.1 Ziel der Zugangskontrolle

Ziel der Zugangskontrolle ist es, zu verhindern, dass Unbefugte Systeme nutzen können, mit denen personenbezogene Daten verarbeitet werden.

6.2 Individuelle Benutzerkonten

Zugriffe auf die Flurin-Plattform und interne Administrationssysteme erfolgen grundsätzlich über individuelle Benutzerkonten.

Gemeinsam genutzte Benutzerkonten sind für administrative Zugriffe unzulässig, soweit der jeweilige Dienst individuelle Zugänge unterstützt.

6.3 Authentifizierung

Flurin setzt angemessene Authentifizierungsverfahren ein.

Für administrative Zugriffe auf produktive Systeme ist Mehr-Faktor-Authentifizierung verpflichtend, soweit der jeweilige Dienst dies unterstützt.

Für Praxisnutzerinnen und Praxisnutzer stellt Flurin über das eingesetzte Identity-Management angemessene Authentifizierungsmechanismen bereit.

6.4 Passwort- und Secret-Management

Passwörter, API-Schlüssel, Datenbankzugänge, SSH-Schlüssel und sonstige Secrets werden nicht ungeschützt im Quellcode, in Tickets, in Messenger-Nachrichten oder in ungeschützten Dokumenten gespeichert.

Flurin verwendet geeignete Verfahren zur Verwaltung von Secrets, insbesondere einen Passwortmanager oder eine vergleichbare sichere Ablage.

Secrets werden bei Verdacht auf Kompromittierung unverzüglich rotiert.

6.5 Sitzungsmanagement

Die Plattform verwendet angemessene Maßnahmen zum Sitzungsmanagement.

Hierzu gehören insbesondere:

zeitliche Begrenzung von Sitzungen,
Schutz vor Session Hijacking,
Abmeldungsmöglichkeit,
sichere Cookie-Einstellungen, soweit Cookies eingesetzt werden,
Schutz administrativer Sitzungen durch zusätzliche Zugriffsbeschränkungen.

6.6 Onboarding und Offboarding

Zugänge werden nur für berechtigte Nutzerinnen und Nutzer eingerichtet.

Bei Wegfall der Berechtigung, insbesondere bei Ausscheiden von Teammitgliedern oder Dienstleistern, werden Zugänge unverzüglich deaktiviert oder entfernt.

Offboarding wird mindestens anhand einer dokumentierten Checkliste durchgeführt. Diese umfasst insbesondere App, Hanko, Hetzner, Bunny.net, United-Domains, Brevo, Repository, Serverzugänge, Passwortmanager und sonstige Produktivsysteme.

6.7 Schutz administrativer Zugänge

Administrative Zugänge werden besonders geschützt.

Hierzu gehören insbesondere:

beschränkter Personenkreis,
Mehr-Faktor-Authentifizierung,
SSH-Schlüssel statt Passwort-Login, soweit technisch möglich,
Deaktivierung nicht benötigter Zugänge,
regelmäßige Überprüfung bestehender Berechtigungen,
unverzügliche Entziehung nicht mehr benötigter Rechte.

7. Zugriffskontrolle

7.1 Ziel der Zugriffskontrolle

Ziel der Zugriffskontrolle ist es sicherzustellen, dass berechtigte Nutzerinnen und Nutzer ausschließlich auf diejenigen personenbezogenen Daten zugreifen können, für die sie eine Berechtigung besitzen.

7.2 Rollen- und Berechtigungskonzept

Flurin verwendet ein Rollen- und Berechtigungskonzept.

Typische Rollen können sein:

Praxisinhaberin oder Praxisinhaber,
Praxisadministration,
Praxismitarbeitende,
eingeschränkte Praxisnutzer,
Flurin-Administration,
Flurin-Support,
technische Systemadministration.

7.3 Mandantenbezogene Zugriffsbeschränkung

Daten einer Praxis werden innerhalb der Plattform logisch dem jeweiligen Praxiskonto zugeordnet.

Die Plattform verhindert, dass Nutzerinnen und Nutzer einer Praxis auf Daten anderer Praxen zugreifen, sofern hierfür keine ausdrückliche technische und rechtliche Grundlage besteht.

7.4 Interne Zugriffe auf Patientendaten

Interne Zugriffe auf produktive Patientendaten erfolgen nur aus berechtigtem Anlass.

Berechtigte Anlässe können insbesondere sein:

Bearbeitung einer konkreten Supportanfrage,
technische Fehleranalyse,
Sicherheitsvorfall,
Wiederherstellung von Daten,
Umsetzung einer Weisung der Praxis,
Erfüllung gesetzlicher oder vertraglicher Pflichten.

7.5 Supportzugriffe

Supportzugriffe werden datensparsam durchgeführt.

Soweit möglich, werden Probleme anhand von Metadaten, Screenshots ohne Patientendaten, anonymisierten Beispielen oder Testdaten gelöst.

Ein Zugriff auf produktive Inhalte erfolgt nur, wenn dies zur Bearbeitung erforderlich ist.

7.6 Berechtigungsprüfung

Flurin überprüft interne Berechtigungen regelmäßig und anlassbezogen.

Mindestens quartalsweise erfolgt eine kurze dokumentierte Prüfung der produktiven Zugänge.

8. Weitergabekontrolle

8.1 Ziel der Weitergabekontrolle

Ziel der Weitergabekontrolle ist es sicherzustellen, dass personenbezogene Daten bei elektronischer Übertragung, Transport oder Speicherung auf Datenträgern nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können.

8.2 Transportverschlüsselung

Die Kommunikation mit der Plattform erfolgt grundsätzlich verschlüsselt.

Flurin setzt hierfür marktübliche Transportverschlüsselung ein, insbesondere TLS. Unverschlüsselte Zugriffe auf produktive Plattformfunktionen werden, soweit technisch möglich, unterbunden oder auf sichere Verbindungen umgeleitet.

8.3 Verschlüsselung ruhender Daten

Personenbezogene Daten werden bei Speicherung in produktiven Systemen durch geeignete technische Maßnahmen geschützt.

Soweit technisch möglich und angemessen, werden ruhende Daten durch Verschlüsselung auf Datenbank-, Speicher-, Backup- oder Infrastrukturebene geschützt.

8.4 Patientenkommunikation über externe Kanäle

Patientenbezogene Kommunikation wird serverseitig nach Kanal, dokumentiertem Einwilligungsstatus, Praxis-Konfiguration, Kontaktpunkt und technischer Verfügbarkeit gesteuert.

E-Mail/SMS ohne gültige kanalspezifische Einwilligung: ausschließlich neutrale Benachrichtigung mit Verweis auf einen geschützten Flurin-Bereich; keine Terminzeit, Terminänderung, Absage, freie Terminoption oder sonstige konkrete Behandlungsinformation im externen Nachrichtentext.
E-Mail/SMS mit gültiger kanalspezifischer Einwilligung: organisatorische Angaben wie Termin, Datum/Uhrzeit, Terminänderung, Absage oder verfügbare Termine dürfen über den jeweiligen Kanal übermittelt werden.
Klinisch sensible Inhalte: Diagnose-, Verordnungs-, Behandlungs-, Dokumentinhalte und vergleichbare klinische Freitexte werden unabhängig von einer Einwilligung nicht über externe E-Mail-/SMS-/Messenger-Nachrichtentexte übermittelt, sondern in geschützten Flurin-Bereichen bereitgestellt.
WhatsApp Business: setzt eine eigene WhatsApp-Einwilligung und eine aktive Praxisverbindung voraus und bleibt bei Flurin stets neutral-only.

Die Praxis bleibt für Anlass und Rechtmäßigkeit der Kommunikation verantwortlich. Flurin setzt die dokumentierten Kanalregeln technisch fail-closed um.

8.5 Versand über Brevo

Brevo ist der eingesetzte Provider für transaktionale E-Mail und SMS.

Für E-Mail werden insbesondere eingesetzt:

TLS zum Versanddienst,
SPF, DKIM und DMARC für die Versanddomain,
serverseitige Inhaltsbegrenzung entsprechend § 8.4,
datensparsame Tracking- und Zustellmetadaten,
definierte Aufbewahrungsfristen für Providerereignisse.

Für SMS gelten zusätzlich normalisierte Telefonnummern, Praxisaktivierung, kanalbezogene Einwilligungs-/Berechtigungsprüfung, Provider-Preflight und ein praxisbezogenes Kosten-/Budgetlimit.

8.6 Datenexporte

Datenexporte werden nur berechtigten Nutzerinnen und Nutzern bereitgestellt.

Exportfunktionen werden protokolliert, soweit dies technisch vorgesehen ist.

Flurin kann Exporte zeitlich begrenzen, mit Zugriffsschutz versehen oder über sichere Downloadmechanismen bereitstellen.

8.7 Datenträger und lokale Speicherung

Produktive Patientendaten werden nicht planmäßig auf mobilen Datenträgern gespeichert.

Soweit eine temporäre lokale Verarbeitung ausnahmsweise erforderlich ist, sind geeignete Schutzmaßnahmen einzuhalten, insbesondere Verschlüsselung, Zugriffsbeschränkung und anschließende sichere Löschung.

8.8 Datei-Uploads und Object-Storage

8.8.1 Produktiver Einsatz

Verordnungsbilder können über die produktive Flurin-Funktion hochgeladen werden. In QA und Produktion ist lokale Dateiablage für geschützte Uploads nicht zulässig; verwendet wird privater S3-kompatibler Hetzner Object Storage.

8.8.2 Zulässige Formate und Größenbegrenzung

Der aktuelle Uploadpfad akzeptiert ausschließlich JPEG/JPG und PNG. Dateiendung, MIME-Type und Magic Bytes müssen zusammenpassen. Leere oder zu große Dateien sowie unplausible Bildabmessungen werden abgewiesen; Kanten- und Gesamtpixelzahl sind technisch begrenzt.

8.8.3 Sichere Bildverarbeitung

Akzeptierte Bilder werden serverseitig mit einer Bildbibliothek eingelesen, Metadaten/Format plausibilisiert, Rotation angewendet und als JPEG bzw. PNG neu kodiert. Dadurch wird nicht lediglich der vom Client gelieferte MIME-Type vertraut. Für das bereinigte Objekt wird ein SHA-256-Checksumwert gebildet. Ein klassischer Antivirus-/Malware-Scanner wird nicht als umgesetzt behauptet; das Risiko wird aktuell durch die enge Bild-Allowlist, Magic-Byte-Prüfung, Decode/Re-Encode und Größenlimits reduziert.

8.8.4 Transport und Speicherung

Uploads werden per TLS übertragen. Object-Storage-Buckets sind nicht öffentlich. Zugriff erfolgt nur über autorisierte Backendpfade bzw. zeitlich begrenzte Zugriffsausgaben; der Storage-Key wird nicht als dauerhaft öffentlicher Link verwendet.

8.8.5 Mandantentrennung und Zugriff

Objekte und Metadaten sind tenantgebunden. Abruf-/Prüfpfade müssen den Tenant und die fachliche Berechtigung prüfen. Normale technische Logs enthalten keine Bildinhalte.

8.8.6 Retention und physische Löschung

Upload-Anfragen laufen standardmäßig nach 14 Tagen ab. Angenommene Verordnungsbilddateien werden spätestens nach 60 Tagen aus dem aktiven Object Storage entfernt. Die Anwendung minimiert zunächst die zugehörigen Metadaten, stellt den Storage-Key in eine persistente Lösch-Queue und löscht das Objekt über den Storage-Provider; fehlgeschlagene Objektlöschungen bleiben retrybar und werden nicht als erfolgreich ausgegeben.

9. Eingabekontrolle und Protokollierung

9.1 Ziel der Eingabekontrolle

Ziel der Eingabekontrolle ist es, nachvollziehen zu können, ob und von wem personenbezogene Daten eingegeben, verändert, gelöscht oder eingesehen wurden, soweit dies technisch und organisatorisch erforderlich und angemessen ist.

9.2 Audit-Logs und Systemlogs

Flurin führt angemessene Protokolle über sicherheitsrelevante Ereignisse.

Hierzu können insbesondere gehören:

Anmeldungen und fehlgeschlagene Anmeldeversuche,
Änderungen von Berechtigungen,
administrative Zugriffe,
Exporte,
Löschvorgänge,
sicherheitsrelevante Konfigurationsänderungen,
technische Systemereignisse,
API-Fehler und ungewöhnliche Zugriffsmuster.

9.3 Schutz der Protokolldaten

Protokolldaten werden vor unbefugter Veränderung und unbefugtem Zugriff geschützt.

Zugriff auf Protokolldaten erhalten nur berechtigte Personen.

9.4 Datensparsame Logs

Patientendaten und Gesundheitsdaten werden nicht planmäßig in technischen Logs gespeichert.

Fehlermeldungen und Debug-Ausgaben werden so gestaltet, dass keine vollständigen Patienteninhalte, Diagnosen, Freitextfelder oder sonstigen sensiblen Inhalte unnötig protokolliert werden.

9.5 Zweckbindung der Protokollierung

Protokolldaten werden insbesondere zu folgenden Zwecken verarbeitet:

Systemsicherheit,
Missbrauchserkennung,
Fehleranalyse,
Nachvollziehbarkeit administrativer Maßnahmen,
Erfüllung gesetzlicher und vertraglicher Nachweispflichten.

9.6 Aufbewahrung von Protokolldaten

Die Produktivkonfiguration verwendet differenzierte Fristen:

Loki-/operative Applikationslogs: Produktion 30 Tage, QA 14 Tage;
Audit-Logs: 12 Monate, sofern kein konkreter Sicherheits-/Nachweisfall eine zulässige Verlängerung erfordert;
rohe E-Mail-Providerereignisse: 90 Tage;
E-Mail-Zustellzusammenfassungen: 12 Monate.

Normale Logs enthalten keine Request-Bodies, Tokens, Cookies, Roh-URLs, Klartext-IP-Adressen, Namen, Telefonnummern oder E-Mail-Adressen. Technische IDs und Hashes dürfen nur für Betriebs-/Sicherheitszwecke verwendet werden.

10. Auftragskontrolle

10.1 Ziel der Auftragskontrolle

Ziel der Auftragskontrolle ist es sicherzustellen, dass personenbezogene Daten, die im Auftrag verarbeitet werden, nur entsprechend den Weisungen der Praxis und den vertraglichen Vereinbarungen verarbeitet werden.

10.2 Vertrag zur Auftragsverarbeitung

Flurin schließt mit der Praxis einen Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO.

Dieser regelt insbesondere:

Gegenstand und Dauer der Verarbeitung,
Art und Zweck der Verarbeitung,
Kategorien personenbezogener Daten,
Kategorien betroffener Personen,
Rechte und Pflichten der Praxis,
Pflichten von Flurin,
Unterauftragsverarbeiter,
technische und organisatorische Maßnahmen,
Unterstützungspflichten,
Löschung und Rückgabe von Daten,
Nachweismöglichkeiten.

10.3 Weisungsmanagement

Flurin verarbeitet personenbezogene Daten im Auftrag der Praxis grundsätzlich nur auf dokumentierte Weisung der Praxis.

Weisungen können sich aus dem Vertrag, der Plattformnutzung, Konfigurationen innerhalb der Plattform oder gesonderten Mitteilungen der Praxis ergeben.

Offensichtlich rechtswidrige Weisungen kann Flurin zurückweisen oder bis zur Klärung aussetzen.

10.4 Auswahl von Unterauftragsverarbeitern

Unterauftragsverarbeiter werden sorgfältig ausgewählt.

Vor der Beauftragung prüft Flurin insbesondere:

Art der zu verarbeitenden Daten,
Sicherheitsniveau,
Datenschutz- und Sicherheitsnachweise,
Standort der Verarbeitung,
vertragliche Verpflichtungen,
Eignung für die Verarbeitung sensibler Daten,
Verfügbarkeit angemessener technischer und organisatorischer Maßnahmen.

Diese Prüfung erfolgt als dokumentierte Kurzprüfung anhand einer Anbieter-Checkliste.

10.5 Vertragliche Verpflichtung von Unterauftragsverarbeitern

Unterauftragsverarbeiter werden vertraglich auf Datenschutz, Vertraulichkeit und angemessene Sicherheitsmaßnahmen verpflichtet.

Soweit erforderlich, werden Vereinbarungen zur Auftragsverarbeitung oder vergleichbare Datenschutzvereinbarungen abgeschlossen.

10.6 Aktuelle Unterauftragsverarbeiter

Für die Praxis-Auftragsverarbeitung werden insbesondere eingesetzt:

Anbieter	Zweck	Status / Schutz
Hetzner	Backend, PostgreSQL, Storage Box Backups, privater Object Storage	Kernbetrieb in Deutschland; AVV/TOM und Sicherheitsnachweise dokumentiert
Bunny.net	statische Frontends/CDN/DNS und technische Zugriffsdaten	DPA und Subprozessorinformationen dokumentiert; keine planmäßige Backend-/Object-Storage-Ablage
Hanko	Identity Management für Praxisnutzer	DPA und Anbieterinformationen dokumentiert; keine planmäßigen Patientendaten
Brevo	E-Mail und optional SMS	DPA/Transfer-/Subprozessorinformationen dokumentiert; serverseitige Inhalts- und Einwilligungsregeln nach § 8.4
Meta Platforms Ireland Limited	optionales WhatsApp Business	DPA/Transfer-/Subprozessorinformationen dokumentiert; eigene WhatsApp-Einwilligung; stets neutral-only

Stripe, BigQuery, Telegram, United-Domains, GitHub und Euronodes sind nicht allein aufgrund ihrer Nutzung Unterauftragsverarbeiter für Patientendaten; ihre tatsächliche Rolle ist im AVV/VVT getrennt dokumentiert.

10.7 Drittlandübermittlungen

Die Kernspeicherung produktiver Praxis- und Gesundheitsdaten (Backend, PostgreSQL, privater Verordnungs-Object-Storage, verschlüsselte DB-Backups) erfolgt auf Hetzner-Infrastruktur in Deutschland.

Bei Anbietern mit globaler Infrastruktur oder Unterauftragnehmern werden die einschlägigen DPA-/Subprozessorinformationen und Übermittlungsinstrumente nach Art. 44 ff. DSGVO dokumentiert und fortlaufend überprüft. Soweit ein Drittlandtransfer stattfindet, nutzt Flurin ein zulässiges Übermittlungsinstrument einschließlich erforderlicher ergänzender Maßnahmen. Die Inhaltsbegrenzungen aus § 8.4 gelten unabhängig vom Übermittlungsinstrument.

11. Verfügbarkeitskontrolle

11.1 Ziel der Verfügbarkeitskontrolle

Ziel der Verfügbarkeitskontrolle ist es, personenbezogene Daten gegen zufällige Zerstörung, Verlust oder unbefugte Veränderung zu schützen und die Verfügbarkeit der Plattform angemessen sicherzustellen.

11.2 Backup-Konzept

Flurin erstellt automatisiert verschlüsselte PostgreSQL-Backups und legt sie getrennt von der produktiven Datenbank auf einer Hetzner Storage Box ab. Vor Upload wird der Dump auf enthaltene Drizzle-Migrationsmetadaten geprüft und symmetrisch mit AES-256 verschlüsselt.

Die aktuelle Rotation hält 14 tägliche und 4 wöchentliche Backup-Generationen. Zugriffe sind auf berechtigte technische Administration beschränkt. Restore-Drills werden anhand des Betriebsrunbooks wiederholt und dokumentiert.

11.3 Wiederherstellung

Flurin stellt Prozesse zur Wiederherstellung von Daten und Systemen bei technischen oder physischen Zwischenfällen bereit.

Wiederherstellungsprozesse werden angemessen dokumentiert und getestet.

Mindeststandard:

Restore-Test vor oder zu Beginn des Produktivbetriebs,
danach mindestens halbjährlich oder nach wesentlichen Änderungen an Backup, Datenbank oder Infrastruktur,
Dokumentation des Ergebnisses in kurzer Form.

11.4 Monitoring

Das primäre Monitoring ist self-hosted auf Hetzner:

Grafana für Visualisierung,
Loki für Logs,
Alloy für die lokale Logweiterleitung,
Uptime Kuma für interne Verfügbarkeitsprüfungen.

Zusätzlich dient eine unabhängige externe Uptime-Prüfung bei Euronodes der Erkennung von Ausfällen aus einem zweiten Infrastrukturkontext. Alarmierungen können per E-Mail und Telegram erfolgen; die Alarm-/Benachrichtigungspfade sind so zu konfigurieren, dass keine Patientendaten oder vollständigen sensiblen Payloads übertragen werden.

Loki verarbeitet nur die vorgesehenen API-Service-Logs; Flurin nutzt kein Grafana Cloud für die normalen Produktivlogs.

11.5 Schutz vor Überlastung und Angriffen

Flurin setzt angemessene Maßnahmen zum Schutz vor Überlastung, Missbrauch und Angriffen ein.

Hierzu können insbesondere gehören:

Rate Limiting,
Schutz vor automatisierten Massenzugriffen,
Firewall-Regeln,
DDoS-Schutz durch Infrastruktur- oder CDN-Anbieter,
Erkennung ungewöhnlicher Zugriffsmuster,
Beschränkung öffentlich erreichbarer Dienste auf erforderliche Ports und Endpunkte.

11.6 Notfallmanagement

Flurin unterhält ein Notfallmanagement für wesentliche Sicherheits- und Verfügbarkeitsereignisse.

Dieses umfasst insbesondere:

interne Eskalationswege,
Zuständigkeiten,
technische Analyse,
Kundenkommunikation,
Wiederherstellungsmaßnahmen,
Dokumentation des Vorfalls,
Nachbereitung und Verbesserungsmaßnahmen.

12. Trennungsgebot

12.1 Ziel des Trennungsgebots

Ziel des Trennungsgebots ist es sicherzustellen, dass Daten, die zu unterschiedlichen Zwecken erhoben wurden oder unterschiedlichen Verantwortlichen zugeordnet sind, getrennt verarbeitet werden können.

12.2 Mandantentrennung

Die Plattform trennt Daten einzelner Praxen logisch voneinander.

Die Zuordnung der Daten erfolgt über eindeutige Mandanten-, Praxis- oder Kontenstrukturen.

12.3 Trennung von Umgebungen

Produktions-, Test-, Entwicklungs- und Staging-Umgebungen werden voneinander getrennt.

Produktive Patientendaten werden grundsätzlich nicht in Entwicklungs- oder Testumgebungen verwendet.

Ausnahmen bedürfen einer dokumentierten Erforderlichkeit und geeigneter Schutzmaßnahmen, insbesondere Anonymisierung oder Pseudonymisierung.

12.4 Trennung von Zwecken

Flurin trennt Datenverarbeitungen für unterschiedliche Zwecke organisatorisch und technisch, soweit dies erforderlich ist.

Insbesondere werden Patientendaten, Praxisvertragsdaten, Abrechnungsdaten, Supportdaten und Sicherheitsprotokolle nicht zweckwidrig zusammengeführt.

13. Pseudonymisierung und Verschlüsselung

13.1 Pseudonymisierung

Soweit möglich und angemessen, werden personenbezogene Daten pseudonymisiert verarbeitet.

Dies gilt insbesondere für Analyse-, Test-, Fehlerdiagnose- oder Entwicklungszwecke.

13.2 Anonymisierung

Für Produktanalysen, statistische Auswertungen oder Verbesserungen der Plattform werden personenbezogene Daten nach Möglichkeit anonymisiert oder aggregiert verwendet.

Eine Verwendung produktiver Patientendaten zu eigenen Zwecken von Flurin erfolgt nur, soweit hierfür eine rechtliche Grundlage besteht.

13.3 Verschlüsselung während der Übertragung

Personenbezogene Daten werden während der Übertragung durch marktübliche Transportverschlüsselung geschützt.

13.4 Verschlüsselung bei Speicherung

Personenbezogene Daten werden bei Speicherung durch geeignete technische Maßnahmen geschützt.

Der Umfang der Verschlüsselung richtet sich nach Systemarchitektur, Schutzbedarf und technischer Umsetzbarkeit.

13.5 Schlüssel- und Geheimnisverwaltung

Zugangsgeheimnisse, API-Schlüssel, Datenbankzugänge und sonstige Secrets werden nicht im Quellcode gespeichert.

Flurin verwendet geeignete Verfahren zur Verwaltung und Rotation von Secrets.

Zugriff auf Secrets erhalten nur berechtigte Personen und Systeme.

14. Integrität und Belastbarkeit der Systeme

14.1 Sichere Systemarchitektur

Flurin gestaltet die Plattformarchitektur so, dass die Sicherheit, Stabilität und Wartbarkeit der Systeme angemessen unterstützt wird.

Hierzu gehören insbesondere:

Trennung von Frontend, Backend und Datenbank,
sichere Schnittstellen,
nachvollziehbare Datenflüsse,
Fehlerbehandlung,
sichere Standardkonfigurationen,
Schutz vor unautorisierten Zugriffen,
Datenvalidierung auf Backend-Ebene.

14.2 Serverhärtung und Netzwerkzugang

Produktive Server werden angemessen abgesichert.

Mindeststandard für den Produktivbetrieb:

Zugriff auf Serveradministration nur über berechtigte Personen,
SSH-Zugriff grundsätzlich über Schlüssel statt Passwort,
Einschränkung öffentlich erreichbarer Ports auf erforderliche Dienste,
Firewall oder vergleichbare Netzwerkregeln,
Datenbank nicht öffentlich aus dem Internet erreichbar, soweit technisch möglich,
regelmäßige Sicherheitsupdates des Betriebssystems und relevanter Pakete,
Entfernung oder Deaktivierung nicht benötigter Dienste.

14.3 Sichere Softwareentwicklung

Flurin berücksichtigt Sicherheitsaspekte im Entwicklungsprozess.

Flurin nutzt einen nachvollziehbaren Entwicklungsprozess mit dokumentierten Änderungen, risikobasierten Reviews und kontrollierten Deployments.

Mindeststandard:

Versionskontrolle für Quellcode,
nachvollziehbare Änderungen über Commits,
geschützter Hauptzweig oder bewusste Freigabe vor produktivem Deployment,
Selbst-Review oder Peer-Review risikorelevanter Änderungen,
besondere Vorsicht bei Datenbankmigrationen, Authentifizierung, Berechtigungen, Exporten und Löschfunktionen,
Test von kritischen Kernprozessen vor Deployment,
Dokumentation wesentlicher Änderungen im internen Änderungs-/Ticketsystem oder in der Commit-Historie.

14.4 Deployment-Prozess

Produktive Deployments erfolgen kontrolliert.

Mindeststandard:

keine ungeprüften Änderungen direkt auf Produktivsystemen, soweit vermeidbar,
kurzer Vorabcheck bei Änderungen an Datenbank, Authentifizierung, Berechtigungen, E-Mail-Versand oder Patientendatenverarbeitung,
Backup oder Wiederherstellungsplan vor riskanten Datenbankmigrationen,
Möglichkeit zur Rücknahme oder Korrektur fehlerhafter Deployments,
Dokumentation des Deployments in angemessener Form.

14.5 Schwachstellenmanagement

Flurin unterhält Prozesse zur Erkennung, Bewertung und Behebung von Schwachstellen.

Hierzu können insbesondere gehören:

Prüfung von Abhängigkeiten,
Sicherheitsupdates,
Bewertung gemeldeter Schwachstellen,
Priorisierung nach Kritikalität,
Dokumentation von Abhilfemaßnahmen.

Bei kritischen Schwachstellen in öffentlich erreichbaren Komponenten erfolgt eine priorisierte Bearbeitung.

14.6 Patch-Management

Sicherheitsrelevante Updates werden angemessen zeitnah eingespielt.

Die Priorisierung richtet sich nach Kritikalität, Ausnutzbarkeit, betroffenen Systemen und Schutzbedarf der verarbeiteten Daten.

14.7 Schutz vor Schadsoftware

Endgeräte und Systeme werden durch geeignete Maßnahmen vor Schadsoftware geschützt.

Hierzu können gehören:

aktuelle Betriebssysteme,
automatische Sicherheitsupdates,
Schutzsoftware,
eingeschränkte Administratorrechte,
sichere Download- und Installationsprozesse.

15. Endgeräte- und Arbeitsplatzsicherheit

15.1 Geschützte Endgeräte

Endgeräte, die für administrative Tätigkeiten oder Zugriff auf produktive Systeme verwendet werden, müssen angemessen geschützt sein.

Hierzu gehören insbesondere:

Geräteverschlüsselung,
Bildschirmsperre,
aktuelle Sicherheitsupdates,
Zugangsschutz,
keine gemeinsame Nutzung mit unbefugten Dritten,
Möglichkeit zur Sperrung oder Löschung bei Verlust, soweit technisch eingerichtet.

15.2 Trennung beruflicher und privater Nutzung

Berufliche Zugänge, Secrets und produktive Daten dürfen nicht ungeschützt in privaten Anwendungen, privaten Cloudspeichern oder unverschlüsselten lokalen Dateien abgelegt werden.

15.3 Mobile Arbeit

Bei mobiler Arbeit und Homeoffice sind angemessene Schutzmaßnahmen einzuhalten.

Hierzu gehören insbesondere:

geschützte Netzwerkverbindungen,
keine Einsichtnahme durch unbefugte Dritte,
sichere Aufbewahrung von Endgeräten,
Vermeidung öffentlicher oder unsicherer Geräte für administrative Tätigkeiten.

15.4 Verlust oder Diebstahl von Endgeräten

Der Verlust oder Diebstahl eines Endgeräts mit Zugriff auf Flurin-Systeme ist intern unverzüglich zu melden.

Danach werden mindestens folgende Schritte geprüft:

Sperrung betroffener Benutzerkonten,
Rotation betroffener Secrets,
Remote-Sperrung oder Löschung, soweit möglich,
Prüfung, ob personenbezogene Daten betroffen sind,
Dokumentation und ggf. Information betroffener Praxen.

16. Support und Kundenkommunikation

16.1 Datensparsame Supportprozesse

Supportprozesse werden datensparsam gestaltet.

Die Praxis soll Supportanfragen möglichst ohne unnötige Patientendaten stellen.

Flurin kann die Praxis bitten, personenbezogene Daten in Supportanfragen zu entfernen oder zu pseudonymisieren, soweit dies für die Bearbeitung möglich ist.

16.2 Zugriff im Supportfall

Ein Zugriff auf produktive Daten im Supportfall erfolgt nur, soweit dies zur Bearbeitung der konkreten Anfrage erforderlich ist.

Supportzugriffe werden auf berechtigte Personen beschränkt.

16.3 Dokumentation von Supportfällen

Supportfälle können dokumentiert werden, soweit dies zur Bearbeitung, Nachvollziehbarkeit, Qualitätssicherung oder Vertragserfüllung erforderlich ist.

Supportdaten werden nicht länger gespeichert als erforderlich.

Für Supportdaten gilt:

Supportvorgänge mit personenbezogenen Daten: Löschung oder Reduktion spätestens 12 Monate nach Abschluss, sofern kein rechtlicher oder vertraglicher Grund für längere Speicherung besteht,
besonders sensible Patientendaten in Supportkommunikation: nach Möglichkeit früher entfernen oder pseudonymisieren.

17. Sicherheitsvorfälle

17.1 Erkennung von Sicherheitsvorfällen

Flurin setzt angemessene organisatorische und technische Prozesse ein, um Sicherheitsvorfälle zu erkennen, zu bewerten und zu bearbeiten.

17.2 Praktischer Incident-Prozess

Bei Verdacht auf einen Sicherheits- oder Datenschutzvorfall wird der dokumentierte Incident-Prozess angewendet:

Erkennen: Hinweis, Alarm, Fehlermeldung oder Meldung aufnehmen.
Eindämmen: betroffene Zugänge, Systeme oder Funktionen soweit erforderlich sichern oder sperren.
Bewerten: betroffene Daten, betroffene Praxen, Risiko und Ursache einschätzen.
Dokumentieren: Zeitpunkt, Quelle, Maßnahmen, Beteiligte und Ergebnis festhalten.
Informieren: betroffene Praxis nach Maßgabe des AVV unverzüglich informieren.
Beheben: technische oder organisatorische Abhilfemaßnahmen umsetzen.
Nachbereiten: Ursache und mögliche Verbesserungen dokumentieren.

17.3 Interne Eskalation

Verdachtsfälle werden intern eskaliert.

Flurin bewertet insbesondere:

Art des Vorfalls,
betroffene Systeme,
betroffene Datenkategorien,
betroffene Praxen,
Risiko für betroffene Personen,
erforderliche Sofortmaßnahmen,
Melde- und Informationspflichten.

17.4 Information der Praxis

Soweit ein Sicherheitsvorfall personenbezogene Daten betrifft, die Flurin im Auftrag einer Praxis verarbeitet, informiert Flurin die betroffene Praxis unverzüglich nach Bekanntwerden des Vorfalls im Rahmen der gesetzlichen und vertraglichen Pflichten.

Die Information soll, soweit verfügbar, Angaben enthalten zu:

Art des Vorfalls,
betroffenen Daten,
betroffenen Personengruppen,
voraussichtlichen Folgen,
bereits ergriffenen Maßnahmen,
empfohlenen Maßnahmen der Praxis,
Kontaktstelle bei Flurin.

17.5 Unterstützung der Praxis

Flurin unterstützt die Praxis im Rahmen der gesetzlichen und vertraglichen Pflichten angemessen bei der Erfüllung ihrer Pflichten im Zusammenhang mit Datenschutzverletzungen.

Die Verantwortung für etwaige Meldungen an Aufsichtsbehörden oder Benachrichtigungen betroffener Personen verbleibt bei der Praxis, soweit die Praxis datenschutzrechtlich Verantwortliche ist.

17.6 Nachbereitung

Sicherheitsvorfälle werden nachbereitet.

Flurin prüft, ob zusätzliche technische oder organisatorische Maßnahmen erforderlich sind, um vergleichbare Vorfälle künftig zu vermeiden.

18. Datenschutz durch Technikgestaltung

18.1 Aufnahmeformulare

Aufnahmeformulare werden so gestaltet, dass nur erforderliche Daten abgefragt werden.

Die Praxis kann abhängig vom angebotenen Leistungsumfang bestimmte Informationen konfigurieren.

Flurin stellt technische Möglichkeiten bereit, um Datenschutzhinweise, Impressumsangaben und weitere Pflichtinformationen einzubinden.

18.2 Patientenkommunikation

Kommunikationskanäle werden getrennt nach Ereignis, Praxisfreigabe, Kontaktpunkt, Einwilligungs-/Berechtigungsstatus, Providerverfügbarkeit und – bei SMS – Budget bewertet. Ein fehlender oder nicht zulässiger Kanal darf nicht durch einen unkontrollierten Fallback sensible Inhalte offenlegen.

WhatsApp Business ist unabhängig von einer vorhandenen Einwilligung auf neutrale Benachrichtigungen beschränkt. Für konkrete patienten-/behandlungsbezogene Details wird auf eine geschützte Flurin-Seite verwiesen.

18.3 Löschfunktionen

Flurin stellt technische oder organisatorische Prozesse bereit, um Daten nach Maßgabe des Vertrags zur Auftragsverarbeitung, der Weisungen der Praxis und des Lösch- und Aufbewahrungskonzepts zu löschen.

18.4 Exportfunktionen

Flurin stellt der Praxis im Rahmen des vereinbarten Leistungsumfangs Exportmöglichkeiten bereit.

Der Export umfasst grundsätzlich nur Daten der jeweiligen Praxis und keine Betriebsgeheimnisse, Algorithmen, Systemdaten oder Daten anderer Praxen.

19. Automatisierte und KI-gestützte Funktionen

19.1 Unterstützende Funktion

Soweit Flurin automatisierte oder KI-gestützte Funktionen bereitstellt, dienen diese ausschließlich der technischen und organisatorischen Unterstützung der Praxis.

Sie ersetzen keine eigenverantwortliche Entscheidung der Praxis.

19.2 Keine eigenständige medizinische Bewertung

KI-gestützte oder automatisierte Funktionen dürfen nicht als medizinische Diagnose, Therapieempfehlung oder eigenständige medizinische Entscheidung verstanden werden.

19.3 Verarbeitung von Patientendaten durch KI-Dienstleister

Eine Verarbeitung produktiver Patientendaten durch KI-Dienstleister erfolgt nur, soweit hierfür eine vertragliche und datenschutzrechtliche Grundlage besteht.

KI-Dienstleister werden, soweit sie personenbezogene Daten im Auftrag verarbeiten, als Unterauftragsverarbeiter behandelt.

19.4 Kein Training ohne Rechtsgrundlage

Produktive Patientendaten werden nicht ohne geeignete Rechtsgrundlage und entsprechende vertragliche Regelung zum Training allgemeiner KI-Modelle von Flurin oder Dritten verwendet.

20. Löschung und Aufbewahrung

20.1 Löschkonzept

Flurin unterhält ein Lösch- und Aufbewahrungskonzept.

Dieses regelt insbesondere:

Löschung nach Vertragsende,
Löschung auf Weisung der Praxis,
Löschung von Protokolldaten,
Löschung von Supportdaten,
Umgang mit Backups,
gesetzliche Aufbewahrungspflichten,
Anonymisierung oder Aggregation.

20.2 Löschung und Rückgabe nach Vertragsende

Nach Vertragsende steht der Praxis für 30 Kalendertage ein kostenloser Standardexport ihrer Auftragsdaten zur Verfügung. Dieser Exportzugang bleibt unabhängig davon verfügbar, ob ein zahlungspflichtiges Abonnement aktiv ist oder eine neue AGB-/AVV-Version bereits bestätigt wurde. Die Praxis kann eine frühere Rückgabe oder Löschung anweisen, soweit keine gesetzlichen Pflichten entgegenstehen.

Nach Ablauf des 30-tägigen Rückgabe-/Exportfensters werden die im Auftrag verarbeiteten personenbezogenen Daten aus den produktiven Systemen gelöscht, soweit keine gesetzliche Pflicht zur weiteren Speicherung besteht. Eine darüber hinausgehende Verarbeitung zu eigenen Flurin-Zwecken findet nicht statt.

20.3 Backups

Daten in Sicherungskopien können technisch bedingt bis zum Ablauf der regulären Backup-Rotation vorhanden bleiben. Während dieser Zeit sind sie gegen produktiven Zugriff geschützt und werden ausschließlich für Wiederherstellungszwecke verarbeitet. Eine Rücksicherung darf bereits zur Löschung vorgesehene Daten nicht dauerhaft wieder in den Produktivbestand überführen.

20.4 Technische Lösch- und Aufbewahrungsroutinen während laufender Nutzung

Soweit keine speziellere gesetzliche Pflicht, dokumentierte Weisung oder zulässige Beweissicherung entgegensteht, gilt während eines laufenden Vertragsverhältnisses technisch insbesondere:

Datenbereich	Regel
fachliche Patienten-Datensätze nach Abmeldung/Beendigung eines Patientenprozesses	allgemeiner Retention-Zyklus bis 24 Monate; frühere Löschanforderungen werden gesondert behandelt
abgeschlossene/archivierte Patientenkommunikationsvorgänge	12 Monate
E-Mail-Providerereignisse	90 Tage
E-Mail-Zustellzusammenfassungen	12 Monate
Verordnungs-Upload-Anfragen	Link-/Anfragefrist 14 Tage
angenommene Verordnungsbilddateien	spätestens 60 Tage, anschließend physische Object-Storage-Löschung
Audit-Logs	12 Monate
Loki-/operative Logs	Produktion 30 Tage, QA 14 Tage
DB-Backups	14 tägliche + 4 wöchentliche Generationen
BigQuery Signup-Attribution (Flurin-eigener Zweck)	Rohdaten maximal 14 Monate
Vertrags-/Rechnungs-/Buchhaltungsdaten von Flurin	nach anwendbaren gesetzlichen Aufbewahrungspflichten; eigener Verantwortungsbereich von Flurin

Diese Fristen verlängern die Auftragsverarbeitung nach Vertragsende nicht; hierfür gilt § 20.2.

21. Prüfung, Bewertung und Evaluierung

21.1 Regelmäßige Überprüfung

Flurin überprüft die Wirksamkeit der TOM regelmäßig und anlassbezogen.

Anlässe können insbesondere sein:

wesentliche Produktänderungen,
neue Unterauftragsverarbeiter,
Sicherheitsvorfälle,
neue gesetzliche Anforderungen,
neue Risiken,
Ergebnisse interner oder externer Prüfungen.

21.2 Quartalsweise Kurzprüfung

Flurin führt mindestens quartalsweise eine kurze Prüfung der wichtigsten Sicherheitsmaßnahmen durch.

Diese umfasst mindestens:

Zugänge und Berechtigungen,
aktive Unterauftragsverarbeiter,
Backup- und Restore-Status,
kritische Updates,
offene Sicherheits- oder Datenschutzthemen,
Änderungen an Datenflüssen.

21.3 Dokumentierte Risikobewertung

Flurin bewertet Risiken für die Rechte und Freiheiten betroffener Personen angemessen.

Bei der Bewertung berücksichtigt Flurin insbesondere:

Art der Daten,
Umfang der Verarbeitung,
Anzahl der betroffenen Personen,
Schutzbedarf,
mögliche Schäden,
Eintrittswahrscheinlichkeit,
verfügbare Schutzmaßnahmen.

21.4 Datenschutz-Folgenabschätzung

Soweit die Praxis aufgrund ihrer Nutzung der Plattform eine Datenschutz-Folgenabschätzung durchführen muss, unterstützt Flurin die Praxis im Rahmen der gesetzlichen und vertraglichen Pflichten mit vorhandenen Informationen zur Plattform, zu Datenflüssen, TOM und Unterauftragsverarbeitern.

21.5 Nachweise

Flurin stellt der Praxis auf Anfrage angemessene Nachweise über die Umsetzung der TOM zur Verfügung, soweit dies gesetzlich oder vertraglich erforderlich ist und keine berechtigten Geheimhaltungs- oder Sicherheitsinteressen entgegenstehen.

Nachweise können insbesondere sein:

diese TOM,
Subprocessor-Liste,
Sicherheitsübersicht,
Zertifikate oder Testate eingesetzter Anbieter,
Ergebniszusammenfassungen interner Prüfungen,
externe Audit- oder Zertifizierungsnachweise, soweit vorhanden.

22. Cloud-Sicherheit und besondere Anforderungen im Gesundheitswesen

22.1 Cloud-Einsatz im Gesundheitswesen

Flurin behandelt die Anforderungen des § 393 SGB V für zugelassene Heilmittelerbringer und deren Auftragsdatenverarbeiter als einschlägige Vorgaben für die Verarbeitung von Gesundheits- und Sozialdaten mittels Cloud-Computing-Diensten.

Die Bewertung umfasst nicht nur die zentrale Hostingplattform, sondern die jeweils tatsächlich eingesetzte Cloud-Service-Kette und die konkreten Daten-/Payload-Kategorien.

22.2 Sicherheitsnachweise von Cloud-Anbietern

Flurin führt für die einschlägigen Cloud-Dienste ein gesondertes Nachweisdossier. Dort werden insbesondere dokumentiert:

der konkrete Anbieter und Dienst-/Systemscope,
der für § 393 SGB V erforderliche aktuelle C5-Typ-2-Nachweis oder ein gesetzlich zulässiger gleichwertiger Nachweis,
Datenstandort und einschlägige Niederlassungs-/Verarbeitungsanforderungen,
DPA/AVV und Unterauftragnehmer,
Drittland-/Transfermechanismen,
erforderliche kundenseitige Kontrollen.

Für die Kerninfrastruktur liegt für Hetzner ein BSI-C5-Testat Typ 2 vor, dessen dokumentierter Geltungsbereich die von Flurin genutzte Produktlinie und Region abdeckt. Für weitere Cloud-Dienste werden nur solche Provider-/Payload-Kombinationen produktiv freigegeben, für die die jeweils erforderlichen Nachweise und Schutzmaßnahmen dokumentiert sind.

Für externe Patientenkommunikation gelten zusätzlich die serverseitigen Inhaltsgrenzen nach § 8.4. WhatsApp bleibt unabhängig von der Einwilligung neutral-only.

22.3 Angemessenheit und Nachweisführung

Flurin behauptet keine eigene C5-, ISO-27001- oder SOC-2-Zertifizierung, soweit eine solche nicht tatsächlich besteht. Maßgeblich sind die dokumentierten technischen und organisatorischen Maßnahmen von Flurin sowie die einschlägigen Nachweise der eingesetzten Cloud-Anbieter. Das Nachweisdossier wird bei wesentlichen Anbieter-, Service- oder Datenflussänderungen aktualisiert.

22.4 Kundenseitige Mitwirkung

Die Praxis bleibt dafür verantwortlich, ihre eigenen gesetzlichen, berufsrechtlichen und organisatorischen Anforderungen an den Einsatz von Cloud-Diensten zu prüfen.

Flurin stellt hierfür im Rahmen der vertraglichen Vereinbarungen angemessene Informationen zur Verfügung.

23. Vertraulichkeit und Berufsgeheimnisse

23.1 Vertraulichkeitsverpflichtung

Flurin verpflichtet Personen mit Zugriff auf personenbezogene Daten oder vertrauliche Informationen zur Vertraulichkeit.

23.2 Besondere Sensibilität von Patientendaten

Flurin behandelt Patientendaten als besonders vertraulich.

Zugriffe auf Patientendaten werden organisatorisch beschränkt und dürfen nur aus berechtigtem Anlass erfolgen.

23.3 Berufsrechtliche Pflichten der Praxis

Die Praxis bleibt für die Einhaltung ihrer berufsrechtlichen Pflichten verantwortlich.

Soweit die Praxis berufsrechtlichen Verschwiegenheitspflichten unterliegt, unterstützt Flurin die Praxis durch geeignete vertragliche und organisatorische Maßnahmen.

24. Technische Konfigurationsübersicht

24.1 Hosting und Infrastruktur

Bereich	Produktivkonfiguration
Marketing-/App-Frontend	Bunny.net
CDN / DNS	Bunny.net
Domainregistrierung	United-Domains
Backend/API	Hetzner, Deutschland
PostgreSQL	Hetzner, Deutschland
Verordnungs-Object-Storage	Hetzner Object Storage, privat, S3-kompatibel
Datenbank-Backups	Hetzner Storage Box, verschlüsselt
Primäres Monitoring	Grafana/Loki/Alloy/Uptime Kuma self-hosted auf Hetzner
unabhängige Uptime-Prüfung	Euronodes
produktive Patienten-Kernspeicherung außerhalb Deutschlands	nicht vorgesehen

24.2 Datenbank und Speicher

Bereich	Produktivkonfiguration
Datenbank	PostgreSQL bei Hetzner in Deutschland
Datenbankzugriff	nur Backend/berechtigte Administration; keine direkte Client-Datenbankverbindung
Feldverschlüsselung sensibler Inhalte	AES-256-GCM für hierfür vorgesehene verschlüsselte Felder; versionierter Keyring
Backups	automatisierte verschlüsselte Dumps auf Hetzner Storage Box
Backup-Rotation	14 tägliche + 4 wöchentliche Generationen
Upload-Speicher	privater Hetzner Object Storage; lokale Speicherung in QA/Produktion verboten
Upload-Formate	JPEG/PNG, Magic-Byte/MIME/Extension-Prüfung, Decode/Re-Encode, Größen-/Pixelgrenzen, SHA-256-Checksum
Upload-Retention	Anfrage 14 Tage; angenommene Bildobjekte 60 Tage; physische Lösch-Queue
öffentlicher Dateiabruf	nicht vorgesehen; autorisierte bzw. zeitlich begrenzte Zugriffe

24.3 Kommunikationsprovider

Bereich	Produktivkonfiguration
E-Mail	Brevo; TLS; SPF/DKIM/DMARC; ohne kanalspezifische Einwilligung neutral-only, mit gültiger Einwilligung organisatorische Details zulässig
SMS	Brevo; praxisweise aktivierbar; ohne kanalspezifische Einwilligung neutral-only, mit gültiger Einwilligung organisatorische Details zulässig; Provider-Preflight und Kosten-/Budgetkontrolle
WhatsApp Business	Meta/WhatsApp Business Platform; praxisbezogene Verbindung; eigene WhatsApp-Einwilligung; stets neutral-only
klinisch sensible Inhalte	Diagnose-, Verordnungs-, Behandlungs-, Dokumentinhalte und vergleichbare klinische Freitexte verbleiben hinter geschützten Flurin-Links
Providerereignisse	minimiert und mit definierter Retention

24.4 Identity Management

Bereich	Produktivkonfiguration
Anbieter	Hanko GmbH / Hanko Cloud
Zweck	Registrierung, Login, Authentifizierung, Nutzerverwaltung
Daten	Praxisnutzer-, E-Mail-, Login- und Authentifizierungsdaten
Patientendaten	keine planmäßige Verarbeitung
MFA	für Praxisnutzer optional in der Standardkonfiguration; strikte MFA kann technisch erzwungen werden; privilegierte interne Zugänge werden gesondert abgesichert
Tokens	API validiert Hanko JWT/JWKS und verifizierte Identität; keine Flurin-eigenen Klartext-Passwortspeicher

24.5 Monitoring und Fehleranalyse

Bereich	Produktivkonfiguration
Logs	Loki self-hosted; Prod 30 Tage, QA 14 Tage
Visualisierung	Grafana self-hosted
Logagent	Alloy self-hosted
Verfügbarkeit	Uptime Kuma self-hosted + unabhängige externe Uptime-Prüfung bei Euronodes
Alarmierung	E-Mail/Telegram mit minimierten Betriebsdaten; keine Patientendetails
Logdaten	technische IDs/Rollen/Eventtypen/Fehlergründe und Hashes; keine Request-Bodies, Tokens, Cookies, Namen, Telefonnummern oder E-Mails im Normalbetrieb
Analytics	BigQuery nur für Flurin-eigene Signup-Attribution; keine Patientenanalyse; Rohdaten-TTL max. 14 Monate

24.6 Support

Bereich	Aktuelle Konfiguration / Zielwert
Supportkanäle	E-Mail, persönliche Kommunikation, ggf. später Ticketsystem
Patientendaten im Support	vermeiden; falls erforderlich, minimieren oder pseudonymisieren
Zugriff auf Produktivdaten	nur aus berechtigtem Anlass
Speicherdauer Supportdaten	grundsätzlich bis zu 12 Monate nach Abschluss, sensible Inhalte früher entfernen, soweit möglich

25. Maßnahmenübersicht

25.1 Umsetzungsstand

Die in dieser Fassung beschriebenen Maßnahmen bilden den produktiven Sicherheitsstandard von Flurin. Maßnahmen, die als Voraussetzung für einen Datenfluss genannt werden, müssen vor Aktivierung des betreffenden Datenflusses wirksam sein.

25.2 Maßnahmen und Status

Bereich	Maßnahme	Status	Anmerkung
Zutrittskontrolle	Betrieb produktiver Systeme in professionellen Rechenzentren	umgesetzt	Hetzner, Deutschland (§ 5.3)
Zugangskontrolle	Individuelle Benutzerkonten und MFA für administrative Zugriffe	umgesetzt	keine gemeinsamen Adminzugänge (§ 6.2, § 6.3, § 6.7)
Zugangskontrolle	SSH-Schlüssel statt Passwort-Login	umgesetzt	Standard für Serveradministration (§ 6.7, § 14.2)
Zugriffskontrolle	Rollen-/Berechtigungskonzept und Mandantentrennung	umgesetzt	tenantbezogene Zugriffskontrollen (§ 7, § 12)
Weitergabekontrolle	TLS-Transportverschlüsselung und Verschlüsselung ruhender Daten	umgesetzt	produktiv aktiv (§ 8, § 13)
Kommunikation	SPF/DKIM/DMARC und serverseitige Kanal-/Einwilligungspolicy	umgesetzt	§ 8.4, § 8.5, § 24.3
Eingabekontrolle	Audit-Logs für sicherheitsrelevante Ereignisse	umgesetzt	Admin-/Login-/Export-/Löschereignisse risikobasiert (§ 9.2)
Datei-Uploads	Formatvalidierung, Decode/Re-Encode, privater Object Storage, Zugriffsschutz und Retention	umgesetzt	§ 8.8
Auftragskontrolle	AVV, Subprozessorliste und Anbieter-DPAs/Transfernachweise	umgesetzt	§ 10; Nachweisregister wird fortlaufend gepflegt
Verfügbarkeit	Backup-Konzept und Wiederherstellungstest	umgesetzt	§ 11.2, § 11.3
Trennungsgebot	Trennung von Produktion, QA/Staging und Entwicklung	umgesetzt	keine Produktivdaten in Entwicklung/Test (§ 12.3)
Entwicklung	Review-, Dependency-, Schwachstellen- und kontrollierter Deployment-Prozess	umgesetzt	§ 14
Incident Response	Prozess für Sicherheitsvorfälle	umgesetzt	§ 17; gesonderter Incident-Response-Prozess
Datenschutz	Lösch- und Aufbewahrungskonzept	umgesetzt	§ 20
Cloud-Sicherheit	Anbieter-DPAs, TOM sowie §393-/C5-/gleichwertige Nachweise	umgesetzt	§ 22; gesondertes Nachweisdossier

26. Praktische Mindest-Checkliste für den Produktivbetrieb

Diese Checkliste konkretisiert die TOM für den Alltag. Sie kann intern als Betriebscheckliste verwendet werden.

26.1 Vor Start einer Praxis

AVV, AGB und Datenschutzdokumente bereitgestellt und akzeptiert.
Praxis im System als eigener Mandant eingerichtet.
Praxisnutzer mit individuellen Zugängen eingerichtet.
Keine gemeinsamen Praxis-Adminzugänge.
Aufnahmeformular datensparsam geprüft.
Praxislinks zu Impressum und Datenschutz hinterlegt oder als fehlend dokumentiert.
E-Mail-Templates ohne unnötige Gesundheitsdaten in Betreffzeilen geprüft.
Backup läuft.
Restore mindestens einmal getestet oder Test geplant und dokumentiert.

26.2 Monatliche Kurzroutine

Offene Sicherheitsupdates prüfen.
Fehlgeschlagene Backups prüfen.
Auffällige Logs oder Fehler prüfen.
Neue Anbieter oder Tools prüfen.
Offene Datenschutz-/Supportfälle prüfen.

26.3 Quartalsweise Kurzroutine

Alle produktiven Adminzugänge prüfen.
Alle Anbieter und Unterauftragsverarbeiter prüfen.
Backup-/Restore-Dokumentation prüfen.
Lösch- und Aufbewahrungsfristen prüfen.
Änderungen an Datenflüssen dokumentieren.
TOM bei Bedarf aktualisieren.

26.4 Bei Änderungen an kritischen Komponenten

Kritische Komponenten sind insbesondere Authentifizierung, Berechtigungen, Mandantentrennung, Datenbank, E-Mail-Versand, Export, Löschung und Aufnahmeformulare.

Vor produktiver Änderung:

Änderung im internen Änderungs-/Ticketsystem oder in einer nachvollziehbaren Notiz dokumentieren.
Datenschutz- und Sicherheitsauswirkung kurz prüfen.
Test mit Testdaten durchführen.
Bei Datenbankmigration Backup oder Rückfallplan sicherstellen.
Nach Deployment Kernfunktion prüfen.

27. Schlussbestimmungen

27.1 Keine Absenkung des Sicherheitsniveaus

Änderungen dieser TOM dürfen das vereinbarte Sicherheitsniveau nicht wesentlich unterschreiten, sofern nicht eine gleichwertige oder bessere Maßnahme eingeführt wird.

27.2 Vorrang individueller Vereinbarungen

Individuelle Vereinbarungen zwischen Flurin und der Praxis gehen diesen TOM vor, soweit sie ausdrücklich abweichende oder ergänzende Sicherheitsmaßnahmen regeln.

27.3 Verhältnis zu weiteren Dokumenten

Diese TOM sind gemeinsam mit folgenden Dokumenten zu lesen:

Allgemeine Geschäftsbedingungen für Praxen,
Vertrag zur Auftragsverarbeitung (diese TOM sind dessen Anlage 2),
Datenschutzerklärung Flurin,
Datenschutzhinweise für Patientinnen und Patienten,
Unterauftragsverarbeiterliste,
Lösch- und Aufbewahrungskonzept (gesondertes internes Betriebsdokument; konkretisiert die Lösch- und Aufbewahrungsregeln aus § 20 dieser TOM, einschließlich der Upload-Retention nach § 8.8.6),
Incident-Response-Prozess (gesondertes internes Betriebsdokument; konkretisiert den Incident-Prozess aus § 17 dieser TOM),
Nachweisdossier § 393 SGB V / C5 (Sicherheitsnachweis-Status der Cloud-Anbieter; Bezug § 22.2/§ 22.3).

Das Lösch- und Aufbewahrungskonzept und der Incident-Response-Prozess liegen als gesonderte Betriebsdokumente vor und konkretisieren die einschlägigen Regelungen dieser TOM (§ 17, § 20).

28. Nachweis- und Zertifizierungshinweis

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen von Flurin und ist Bestandteil des Vertrags zur Auftragsverarbeitung (Anlage 2). Es dokumentiert den für die produktive Verarbeitung geltenden Sicherheitsstandard.

Flurin behauptet kein eigenes Sicherheits- oder Zertifizierungsniveau, das nicht tatsächlich besteht. Sicherheitsnachweise eingesetzter Anbieter, insbesondere C5-/gleichwertige Nachweise, DPA/AVV, Subprozessor- und Transferinformationen, werden in den dafür vorgesehenen internen Nachweisregistern geführt und regelmäßig überprüft.

Ende der Technischen und organisatorischen Maßnahmen