Vertrauen & Recht

Technische und organisatorische Maßnahmen

Sicherheitsmaßnahmen zum Schutz personenbezogener Daten und Gesundheitsdaten.

Version 1.4 Stand: 17.06.2026 Gültig ab: 17.06.2026 Zielgruppe: Praxen, Datenschutzverantwortliche, Investoren und Partner Betreiber: Jan Jerusalem, handelnd unter "Flurin"

Technische und organisatorische Maßnahmen (TOM)

Dokument: Technische und organisatorische Maßnahmen – Anlage zum Vertrag zur Auftragsverarbeitung
Version: 1.4
Stand: 17.06.2026
Status: Produktion – Pilot
Anbieter: Jan Jerusalem, handelnd unter der Geschäftsbezeichnung „Flurin”, Freiburger Str. 25, 79853 Lenzkirch
Betriebsphase: Pilot- und Aufbauphase

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 Realistisches Sicherheitsmodell für ein kleines Team

Flurin wird in der Pilot- und Aufbauphase durch ein kleines agiles Team betrieben. Die TOM sind bewusst so ausgestaltet, dass sie im Alltag durch eine einzelne verantwortliche Person oder ein kleines Team tatsächlich umgesetzt werden können.

Dazu setzt Flurin auf wenige, klare und dokumentierte Sicherheitsroutinen statt auf umfangreiche formale Enterprise-Prozesse. Mehrere organisatorische Rollen können von derselben Person wahrgenommen werden, solange Verantwortlichkeit, Dokumentation und Zugriffsbeschränkung gewährleistet bleiben.

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 aktuelle technische Architektur in der Pilot- und Aufbauphase ist:

Komponente	Anbieter / Ort	Funktion	Verarbeitung personenbezogener Daten
Marketing-Frontend	Bunny.net	Auslieferung der Marketingseite	technische Zugriffsdaten, keine planmäßige Verarbeitung produktiver Patientendaten
App-Frontend	Bunny.net	Auslieferung statischer App-Oberfläche	technische Zugriffsdaten, keine Speicherung der Backend-Datenbankinhalte im Frontend-Hosting
DNS-Verwaltung	Bunny.net	Verwaltung der DNS-Einträge für Flurin-Domains	DNS-bezogene technische Anfragedaten, keine produktiven Patientendaten
Domainregistrierung	United-Domains	Registrierung und Verwaltung der Domain	Domain-, Vertrags-, Rechnungs- und Administrationsdaten von Flurin; keine produktiven Praxis- oder Patientendaten
Backend-Server	Hetzner, Deutschland	API, Geschäftslogik, Verarbeitung der Praxis- und Patientendaten	Praxisdaten, Patientendaten, Gesundheitsdaten, technische Logs
PostgreSQL-Datenbank	Hetzner, Deutschland	Speicherung produktiver Plattformdaten	Praxisdaten, Patientendaten, Gesundheitsdaten
Identity Management	Hanko	Login, Authentifizierung, Nutzerverwaltung	Nutzer-, Login- und Authentifizierungsdaten von Praxisnutzern
E-Mail-Versand	Brevo	transaktionale E-Mails und Patientenkommunikation im Auftrag der Praxis	Empfängeradressen, Namen, E-Mail-Inhalte, Versand- und Zustellmetadaten

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.

In der Pilot- und Aufbauphase können diese Rollen durch dieselbe Person wahrgenommen werden. Mindestens werden folgende Verantwortungsbereiche abgedeckt:

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

4.2 Schlanke Dokumentation

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

Ausreichend sind insbesondere:

Eintrag in einem internen Dokument,
Issue oder Ticket,
Changelog,
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.

Bei einem kleinen Team genügt eine dokumentierte interne Sensibilisierung, zum Beispiel anhand einer Datenschutz- und Sicherheitscheckliste.

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.

Bei einem kleinen Team wird Offboarding mindestens anhand einer kurzen 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.

In der Pilot- und Aufbauphase erfolgt mindestens quartalsweise 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 E-Mail-Kommunikation

E-Mail-Kommunikation mit Patientinnen und Patienten wird datensparsam gestaltet.

E-Mail-Betreffzeilen sollen keine sensiblen Gesundheitsdaten enthalten. Inhalte werden soweit möglich so formuliert, dass keine unnötigen Gesundheitsinformationen offengelegt werden.

Die Praxis bleibt für Inhalt und Rechtmäßigkeit der Patientenkommunikation verantwortlich, soweit Flurin Nachrichten im Auftrag der Praxis technisch versendet.

8.5 Versand über Brevo

Soweit Flurin E-Mails im Auftrag der Praxis versendet, erfolgt der Versand aktuell über Brevo.

Für die produktive Versanddomain werden angemessene technische Maßnahmen zur Absicherung des E-Mail-Versands eingesetzt. Hierzu gehören insbesondere:

SPF,
DKIM,
DMARC mit mindestens beobachtender oder restriktiver Konfiguration abhängig vom Umsetzungsstand,
TLS für Mailserver-Kommunikation, soweit empfangende Systeme dies unterstützen,
Versandprotokollierung,
Missbrauchsüberwachung.

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 Status im Pilotbetrieb

Datei-Uploads (z. B. hochgeladene Dokumente, Anhänge, Bilder oder sonstige Dateien mit möglichem Gesundheitsbezug) und ein dafür eingesetzter Object-Storage werden in der Pilot- und Aufbauphase nach aktuellem Betriebsmodell nicht als aktive Funktion bereitgestellt.

Die aktuell verarbeiteten personenbezogenen Daten werden über strukturierte Formular- und Datenbankfelder erfasst und in der PostgreSQL-Datenbank bei Hetzner in Deutschland gespeichert (§ 2.4, § 24.2). Ein gesonderter Object-Storage für Datei-Uploads ist im Pilot nicht im Einsatz.

Solange keine Upload-Funktion aktiv ist, entfallen die nachstehenden Maßnahmen mangels Anwendungsfall. Vor Aktivierung einer Upload-Funktion sind die Maßnahmen nach § 8.8.2 bis § 8.8.6 umzusetzen und diese TOM sowie das Lösch- und Aufbewahrungskonzept entsprechend zu aktualisieren.

8.8.2 Datensparsamkeit von Uploads

Wird eine Upload-Funktion eingeführt, gilt der Grundsatz der Datensparsamkeit (§ 3.5). Uploads werden auf das für den jeweiligen Zweck Erforderliche beschränkt; zulässige Dateitypen und Maximalgrößen werden eingeschränkt. Die Praxis bleibt für die Rechtmäßigkeit und Erforderlichkeit der hochgeladenen Inhalte verantwortlich. Patientinnen und Patienten bzw. die Praxis werden, soweit möglich, dazu angehalten, keine über den Zweck hinausgehenden sensiblen Inhalte hochzuladen.

8.8.3 Verschlüsselung von Uploads

Hochgeladene Dateien werden während der Übertragung durch Transportverschlüsselung (TLS, § 8.2) geschützt.

Bei Speicherung werden hochgeladene Dateien durch geeignete technische Maßnahmen geschützt. Soweit ein Object-Storage eingesetzt wird, werden ruhende Upload-Daten durch Verschlüsselung auf Speicher-, Bucket- oder Infrastrukturebene geschützt, soweit technisch möglich und angemessen (entsprechend § 8.3, § 13.4). Das konkrete Verschlüsselungsverfahren des Object-Storage wird vor Aktivierung der Upload-Funktion festgelegt und dokumentiert.

8.8.4 Zugriffsschutz von Uploads

Der Zugriff auf hochgeladene Dateien wird mandantenbezogen beschränkt (§ 3.3, § 7.3, § 12.2). Dateien einer Praxis sind nur berechtigten Nutzerinnen und Nutzern dieser Praxis sowie berechtigter Flurin-Administration aus berechtigtem Anlass (§ 7.4) zugänglich.

Object-Storage-Buckets oder vergleichbare Speicherbereiche werden nicht öffentlich zugänglich gemacht. Zugriffe erfolgen über autorisierte Backend-Anfragen oder zeitlich begrenzte, zugriffsgeschützte Download-Mechanismen (entsprechend § 8.6). Direkte, unauthentifizierte öffentliche Links auf Upload-Inhalte werden vermieden.

8.8.5 Schadsoftware-Prüfung von Uploads

Für hochgeladene Dateien wird eine Prüfung auf Schadsoftware vorgesehen, soweit dies bei Aktivierung der Upload-Funktion mit angemessenem Aufwand umsetzbar ist (z. B. Virenscan beim Upload, Beschränkung ausführbarer Dateitypen). Der konkrete Umfang einer Schadsoftware-Prüfung sowie die eingesetzte Virenscan-Lösung werden bei Aktivierung festgelegt und dokumentiert. Bis dahin ist diese Maßnahme als geplant einzustufen; sie ist nicht Voraussetzung des Pilotbetriebs, solange keine Uploads aktiv sind.

8.8.6 Protokollierung und Aufbewahrung von Uploads

Upload- und Download-Vorgänge können protokolliert werden, soweit dies technisch vorgesehen und für Sicherheit und Nachvollziehbarkeit erforderlich ist (§ 9.2). Patienteninhalte aus Uploads werden nicht planmäßig in technischen Logs gespeichert (§ 9.4).

Die Aufbewahrung und Löschung hochgeladener Dateien richtet sich nach dem Lösch- und Aufbewahrungskonzept (§ 20.1) und folgt grundsätzlich dem Lebenszyklus der zugehörigen Praxis- bzw. Patientendaten: Upload-Inhalte werden mit Löschung des zugehörigen Datensatzes bzw. nach Vertragsende im Rahmen des Lösch- und Aufbewahrungskonzepts (Exportfenster, danach Löschung/Anonymisierung aus produktiven Systemen) gelöscht; in Backups gilt § 20.3. Verwaiste Upload-Objekte ohne zugehörigen Datensatz werden im Rahmen der Löschroutinen entfernt. Vor Aktivierung der Upload-Funktion ist eine entsprechende Zeile im Lösch- und Aufbewahrungskonzept aufzunehmen (siehe § 20.4).

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

Technische Logs werden nur so lange gespeichert, wie dies für Sicherheits-, Nachweis- und Fehleranalysezwecke erforderlich ist.

Als Zielwert gilt in der Pilotphase:

technische Applikations- und Serverlogs: grundsätzlich bis zu 30 Tage,
sicherheitsrelevante Logs: grundsätzlich bis zu 90 Tage,
längere Speicherung nur bei konkretem Vorfall, Missbrauchsverdacht oder gesetzlichem Nachweisinteresse.

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.

Bei einem kleinen Team erfolgt diese Prüfung 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

Die aktuellen wesentlichen Unterauftragsverarbeiter sind:

Anbieter	Zweck	Wesentliche Maßnahmen
Hetzner	Backend-Server, PostgreSQL, Infrastruktur, Backups	Betrieb in Deutschland, Zugriffsbeschränkung, Anbieter-AVV/TOM
Bunny.net	Frontend-Auslieferung, CDN, DNS-Verwaltung, technische Zugriffsdaten	keine Speicherung produktiver Backend-Datenbankinhalte oder produktiver Patientendatensätze, datensparsame Konfiguration, Anbieter-DPA
Hanko	Identity Management, Login, Nutzerverwaltung	moderne Authentifizierung, Anbieter-DPA, Zugriffsbeschränkung
Brevo	E-Mail-Versand	Anbieter-DPA, datensparsame Inhalte, SPF/DKIM/DMARC

Weitere technische Anbieter ohne planmäßige Verarbeitung produktiver Praxis- oder Patientendaten werden ergänzend dokumentiert. Aktuell betrifft dies insbesondere United-Domains für Domainregistrierung und Domainverwaltung.

Weitere Dienste werden erst nach dokumentierter Prüfung eingesetzt, soweit sie personenbezogene Daten verarbeiten.

10.7 Drittlandübermittlungen

Übermittlungen personenbezogener Daten in Länder außerhalb der Europäischen Union, des Europäischen Wirtschaftsraums oder eines Staates mit Angemessenheitsbeschluss erfolgen nur, soweit hierfür eine zulässige Rechtsgrundlage besteht und angemessene Garantien umgesetzt werden.

Für produktive Gesundheitsdaten wird ein Hosting innerhalb Deutschlands oder der EU bevorzugt. Aktuell befinden sich Backend und PostgreSQL-Datenbank bei Hetzner in Deutschland.

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 unterhält ein Backup-Konzept für produktive Systeme.

Mindeststandard für den Pilotbetrieb:

regelmäßige automatisierte Sicherung der PostgreSQL-Datenbank,
Zugriffsbeschränkung auf Backups,
Speicherung von Backups getrennt von der produktiven Datenbank, soweit technisch und wirtschaftlich angemessen,
Schutz von Backups durch Verschlüsselung oder gleichwertige Zugriffsschutzmaßnahmen,
begrenzte Aufbewahrung nach definierten Backup-Zyklen.

Zielparameter für den Pilotbetrieb:

Datenbankbackup: mindestens täglich,
Backup-Aufbewahrung: grundsätzlich bis zu 14 Tage,
längere Aufbewahrung nur bei konkretem Anlass, rechtlicher Pflicht oder technischem Migrationsbedarf,
Backupzugriff: nur berechtigte technische Administration.

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 produktiven Pilotbetriebs,
danach mindestens halbjährlich oder nach wesentlichen Änderungen an Backup, Datenbank oder Infrastruktur,
Dokumentation des Ergebnisses in kurzer Form.

11.4 Monitoring

Flurin überwacht produktive Systeme angemessen auf Verfügbarkeit, Fehlerzustände und sicherheitsrelevante Ereignisse.

Hierzu können insbesondere gehören:

Applikationsmonitoring,
Infrastrukturmonitoring,
Fehlerprotokollierung,
Verfügbarkeitsprüfungen,
Alarmierungen bei kritischen Ereignissen.

Im kleinen Team kann Monitoring schlank erfolgen, solange kritische Ausfälle und Sicherheitsereignisse zeitnah erkannt werden können.

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 Pilotbetrieb:

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.

Da Flurin in der Pilotphase kein großes DevOps-Team betreibt, wird ein schlanker, aber nachvollziehbarer Entwicklungsprozess genutzt.

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 in Changelog, Issue oder 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.

Zielwert für den Pilotbetrieb:

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 ein schlanker 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

Patientenkommunikation wird möglichst datensparsam gestaltet.

Automatisierte Benachrichtigungen sollen keine unnötigen sensiblen Inhalte enthalten.

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 nach Vertragsende

Nach Vertragsende werden personenbezogene Daten nach Maßgabe des Vertrags zur Auftragsverarbeitung und des Lösch- und Aufbewahrungskonzepts gelöscht oder zurückgegeben, soweit keine gesetzlichen Aufbewahrungspflichten entgegenstehen.

20.3 Backups

Daten in Backups können technisch bedingt erst im Rahmen regulärer Backup-Zyklen gelöscht oder überschrieben werden.

Während dieser Zeit werden Backupdaten gegen produktiven Zugriff geschützt und nur für Wiederherstellungszwecke verwendet.

20.4 Praktische Löschroutinen im Pilotbetrieb

Für den Pilotbetrieb gelten folgende Zielwerte, soweit keine abweichende Vereinbarung oder rechtliche Pflicht besteht:

Datenbereich	Zielwert
Produktive Praxis- und Patientendaten nach Vertragsende	Exportfenster 30 Tage, danach Löschung/Anonymisierung aus produktiven Systemen
Datei-Uploads / Object-Storage	im Pilot nicht aktiv (§ 8.8.1); bei Aktivierung Lebenszyklus des zugehörigen Datensatzes, Löschung mit dem Datensatz bzw. nach Vertragsende analog zu produktiven Patientendaten (§ 8.8.6); bei Aktivierung im Lösch- und Aufbewahrungskonzept zu präzisieren
Technische Logs	grundsätzlich bis zu 30 Tage
Sicherheitslogs	grundsätzlich bis zu 90 Tage
Backups	grundsätzlich Überschreibung nach Backup-Zyklus, Zielwert bis zu 14 Tage
Supportdaten	grundsätzlich bis zu 12 Monate nach Abschluss, sensible Inhalte früher entfernen, soweit möglich
Abrechnungs- und Vertragsdaten von Praxen	nach gesetzlichen Aufbewahrungsfristen, soweit Flurin eigenständig verantwortlich ist

Die konkrete Ausgestaltung dieser Zielwerte erfolgt im gesonderten Lösch- und Aufbewahrungskonzept (§ 20.1, § 27.3).

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

In der Pilot- und Aufbauphase führt Flurin 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 berücksichtigt, dass Praxen als Leistungserbringer im Gesundheitswesen besonderen Anforderungen an Datenschutz, Informationssicherheit und Vertraulichkeit unterliegen können.

Dies gilt insbesondere, wenn personenbezogene Gesundheitsdaten im Wege des Cloud-Computings verarbeitet werden.

22.2 Sicherheitsnachweise von Cloud-Anbietern

Flurin prüft bei der Auswahl wesentlicher Cloud- und Hostinganbieter verfügbare Sicherheitsnachweise.

Hierzu können insbesondere gehören:

ISO/IEC 27001,
BSI C5-Testat,
SOC 2,
vergleichbare branchentypische Sicherheitsnachweise,
Datenschutz- und Auftragsverarbeitungsunterlagen,
Standort- und Subunternehmerinformationen.

Der dokumentierte Sicherheitsnachweis-Status der eingesetzten Anbieter wird in einem gesonderten Nachweisdossier zu § 393 SGB V / C5 geführt (Stand 17.06.2026). Nach diesem Dossier stellt sich der Status wie folgt dar:

Anbieter	Rolle / produktive Daten	Sicherheitsnachweis (Stand 17.06.2026)
Hetzner (DE)	Backend, PostgreSQL, Backups – alle produktiven Praxis-, Patienten- und Gesundheitsdaten	BSI-C5-Testat Typ 2 (Katalog C5:2020) liegt vor; der geprüfte Geltungsbereich deckt die genutzte Produktlinie und Region ab. Ergänzend ISO/IEC 27001:2022; PCI DSS 4.0. Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abgeschlossen.
Bunny.net (SI/EU)	Frontend-Auslieferung, CDN, DNS – nur technische Zugriffs-/DNS-Daten, keine produktiven Patientendaten	ISO/IEC 27001 zertifiziert; kein BSI-C5-Testat. DPA sowie Angaben zu Sub-Unterauftragnehmern und Drittlandbezug sind abzulegen.
Hanko (DE/EU)	Identity Management – Login-/Authentifizierungsdaten der Praxisnutzer, keine planmäßigen Patientendaten	moderne Authentifizierung; kein C5. DPA sowie Angaben zu Sub-Unterauftragnehmern und Drittlandbezug sind abzulegen.
Brevo (FR/EU)	E-Mail-Versand im Auftrag der Praxis	SPF/DKIM/DMARC; kein C5. DPA (DPF/SCC) sowie Angaben zu Sub-Unterauftragnehmern und Drittlandbezug sind abzulegen.

Maßgeblich für etwaige Cloud-Anforderungen im Gesundheitswesen (vgl. § 22.1) ist die Stelle, die die produktiven Gesundheitsdaten verarbeitet. Nach der dokumentierten Architektur (§ 2.4, § 2.5, § 24) ist dies Hetzner in Deutschland; die übrigen Anbieter verarbeiten planmäßig keine produktiven Gesundheitsdatensätze. Einzelheiten, Restrisiken und Verifikationspunkte ergeben sich aus dem Nachweisdossier § 393 SGB V / C5.

22.3 Angemessenheit statt Überversprechen

Flurin verpflichtet sich zu angemessenen technischen und organisatorischen Maßnahmen.

In der Pilot- und Aufbauphase wird kein eigener C5-, ISO-27001- oder SOC-2-zertifizierter Betrieb von Flurin behauptet; eine solche Zertifizierung von Flurin selbst liegt nicht vor.

Soweit für die produktive Verarbeitung von Gesundheitsdaten ein C5-Sicherheitsnachweis maßgeblich ist, wird dieser anbieterseitig durch den datenverarbeitenden Hostinganbieter (Hetzner) erbracht: Hetzner verfügt über ein BSI-C5-Testat des Typs 2 (Katalog C5:2020), das vorliegt. Der geprüfte Geltungsbereich deckt die konkret genutzte Hetzner-Produktlinie und den Standort (Region) ab.

Die Anwendbarkeit des § 393 SGB V auf die Pilotpraxen (GKV-zugelassene Heilmittelerbringer) ist anwaltlich noch nicht abschließend geklärt; sie wird im Nachweisdossier vorsorglich als anwendbar behandelt, bis die abschließende anwaltliche Klärung vorliegt.

Soweit eingesetzte Anbieter über weitere eigene Sicherheitsnachweise verfügen (z. B. ISO/IEC 27001 bei Bunny.net), können diese ergänzend herangezogen werden.

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	Aktuelle Konfiguration
Marketing-Frontend	Bunny.net
App-Frontend	Bunny.net
DNS-Verwaltung	Bunny.net
Domainregistrierung	United-Domains
Backend-Server	Hetzner, Deutschland
PostgreSQL-Datenbank	Hetzner, Deutschland
Produktive Patientendaten außerhalb Deutschland	nach aktuellem Betriebsmodell nicht geplant
Produktive Backend-Datenbank über CDN/DNS	nein, nicht geplant

24.2 Datenbank und Speicher

Bereich	Aktuelle Konfiguration / Zielwert
Datenbank	PostgreSQL bei Hetzner in Deutschland
Datenbankzugriff	nicht öffentlich aus dem Internet erreichbar, soweit technisch möglich
Datenbankzugang	beschränkt auf Backend / berechtigte Administration
Backups	mindestens tägliche Datenbanksicherung im Pilotbetrieb
Backup-Aufbewahrung	grundsätzlich bis zu 14 Tage
Backup-Schutz	Zugriffsbeschränkung, Verschlüsselung oder gleichwertige Schutzmaßnahme
Datei-Uploads / Object-Storage	im Pilotbetrieb nach aktuellem Betriebsmodell nicht aktiv (§ 8.8.1)
Upload-Verschlüsselung (bei Aktivierung)	TLS bei Übertragung; Verschlüsselung ruhender Upload-Daten auf Speicher-/Bucket-Ebene, soweit angemessen (§ 8.8.3)
Upload-Zugriffsschutz (bei Aktivierung)	mandantenbezogen, keine öffentlichen Buckets/Links, zugriffsgeschützte Downloads (§ 8.8.4)
Upload-Schadsoftwareprüfung (bei Aktivierung)	Virenscan / Beschränkung ausführbarer Dateitypen vorgesehen, Umfang bei Aktivierung festzulegen (§ 8.8.5)
Upload-Retention (bei Aktivierung)	nach Lösch- und Aufbewahrungskonzept, Lebenszyklus des zugehörigen Datensatzes (§ 8.8.6, § 20)

24.3 E-Mail-Versand

Bereich	Aktuelle Konfiguration / Zielwert
E-Mail-Dienstleister	Brevo
Versandart	transaktionale E-Mails im Auftrag der Praxis
Versanddomain	flurin.app oder dafür konfigurierte Subdomain
SPF	produktiv einzurichten / aufrechtzuerhalten
DKIM	produktiv einzurichten / aufrechtzuerhalten
DMARC	mindestens beobachtend, später restriktiver je nach Zustellbarkeit und Betriebsreife
Inhaltsschutz	keine unnötigen Gesundheitsdaten in Betreffzeilen, datensparsame Templates

24.4 Identity Management

Bereich	Aktuelle Konfiguration / Zielwert
Anbieter	Hanko
Zweck	Login, Registrierung, Authentifizierung, Nutzerverwaltung
Daten	Praxisnutzer, Login- und Authentifizierungsdaten
Patientendaten	keine planmäßige Verarbeitung von Patientendaten im Identity Management
Adminschutz	MFA / starke Authentifizierung für Administrationszugriffe, soweit verfügbar

24.5 Monitoring und Fehleranalyse

Bereich	Aktuelle Konfiguration / Zielwert
Monitoring	schlankes Verfügbarkeits- und Fehler-Monitoring für Produktivsysteme
Error Tracking	nur nach gesonderter Datenschutzprüfung, falls externer Anbieter eingesetzt wird
Personenbezogene Daten in Logs	minimieren; keine planmäßige Speicherung vollständiger Patientendaten in Logs
Speicherdauer Logs	technische Logs grundsätzlich bis zu 30 Tage; Sicherheitslogs bis zu 90 Tage

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 Lesart der Status-Spalte

Die Status-Spalte trennt den tatsächlichen Umsetzungsstand von Zielwerten. Verwendet werden ausschließlich drei Werte:

umgesetzt – Maßnahme ist eingerichtet und wird betrieben.
in Umsetzung – Maßnahme ist begonnen bzw. teilweise eingerichtet und wird bis zum produktiven Pilotstart fertiggestellt.
geplant – Maßnahme ist konzeptionell vorgesehen, aber noch nicht eingerichtet (z. B. weil der Anwendungsfall im Pilot noch nicht besteht).

Kernmaßnahmen: Die folgenden Kernmaßnahmen sind produktiv umgesetzt und aktiv: TLS-Transportverschlüsselung, Verschlüsselung ruhender Daten, MFA für administrative Zugriffe, Mandantentrennung zwischen Praxen, Backup-Konzept inkl. erfolgreichem Restore-Test sowie SPF/DKIM/DMARC für die produktive Versanddomain. Ihr fortlaufender Betrieb wird im Rahmen der regelmäßigen Kurzprüfung (§ 21.2) überwacht.

Der konkrete Stand der mit „in Umsetzung” / „geplant” markierten Maßnahmen wird im Rahmen der laufenden Aufbauarbeiten weitergeführt; eine Absenkung des Sicherheitsniveaus nach § 27.1 ist damit nicht verbunden.

25.2 Maßnahmen und Status

Bereich	Maßnahme	Status	Zielwert / Anmerkung Pilotbetrieb
Zutrittskontrolle	Betrieb produktiver Systeme in professionellen Rechenzentren	umgesetzt	Hetzner, Deutschland (§ 5.3)
Zugangskontrolle	Individuelle Benutzerkonten	umgesetzt	keine gemeinsamen Adminzugänge (§ 6.2)
Zugangskontrolle	MFA für administrative Zugriffe (Kernmaßnahme)	umgesetzt	verpflichtend für administrative Zugriffe, produktiv aktiv (§ 6.3, § 6.7)
Zugangskontrolle	SSH-Schlüssel statt Passwort-Login	umgesetzt	Standard für Serveradministration (§ 6.7, § 14.2)
Zugriffskontrolle	Rollen- und Berechtigungskonzept	umgesetzt	wird bei Änderungen geprüft (§ 7.2)
Zugriffskontrolle	Mandantentrennung zwischen Praxen (Kernmaßnahme)	umgesetzt	Kernanforderung der Plattform, produktiv aktiv (§ 3.3, § 7.3, § 12.2)
Weitergabekontrolle	TLS-Transportverschlüsselung (Kernmaßnahme)	umgesetzt	produktiv aktiv (§ 8.2)
Weitergabekontrolle	Verschlüsselung ruhender Daten (Kernmaßnahme)	umgesetzt	Verschlüsselung at rest auf Infrastruktur-, DB- und Backup-Ebene, produktiv aktiv (§ 8.3, § 13.4)
Weitergabekontrolle	SPF/DKIM/DMARC für Versanddomain (Kernmaßnahme)	umgesetzt	produktiv aktiv; DMARC zunächst beobachtend, später restriktiver (§ 8.5, § 24.3)
Eingabekontrolle	Audit-Logs für sicherheitsrelevante Ereignisse	in Umsetzung	risikobasiert, mindestens Admin-/Login-/Export-/Löschereignisse, soweit technisch verfügbar (§ 9.2)
Datei-Uploads	Verschlüsselung, Zugriffsschutz, Virenscan, Retention von Uploads	geplant	Upload-Funktion im Pilot nicht aktiv; Maßnahmen vor Aktivierung umzusetzen (§ 8.8)
Auftragskontrolle	AVV mit Praxen	in Umsetzung	vor produktiver Verarbeitung abzuschließen (§ 10.2)
Auftragskontrolle	Subprocessor-Liste	umgesetzt	Hetzner, Bunny.net, Hanko, Brevo enthalten; United-Domains ergänzend als Domainanbieter ohne produktive Patientendaten dokumentiert (§ 10.6)
Auftragskontrolle	Anbieter-DPAs / AVVs mit Subprozessoren	in Umsetzung	AVV mit Hetzner (Art. 28 DSGVO) abgeschlossen; DPAs sowie Angaben zu Sub-Unterauftragnehmern und Drittlandbezug von Brevo, Bunny.net und Hanko sind noch zu bestätigen und abzulegen (§ 10.5)
Verfügbarkeit	Backup-Konzept (Kernmaßnahme)	umgesetzt	mindestens tägliches DB-Backup, produktiv aktiv (§ 11.2, § 24.2)
Verfügbarkeit	Wiederherstellungstest (Kernmaßnahme)	umgesetzt	erfolgreicher Restore-Test durchgeführt und dokumentiert, danach mindestens halbjährlich (§ 11.3)
Trennungsgebot	Trennung von Produktion, Staging und Entwicklung	umgesetzt	keine Produktivdaten in Entwicklung/Test (§ 12.3)
Entwicklung	Code Reviews / Selbst-Reviews	in Umsetzung	risikobasiert, bei Solo-Arbeit mindestens dokumentierte Selbstprüfung (§ 14.3)
Entwicklung	Dependency- und Schwachstellenprüfung	in Umsetzung	regelmäßig und bei kritischen Hinweisen (§ 14.5)
Deployment	kontrollierte Deployments	in Umsetzung	Backup/Rückfallplan bei DB-Migrationen (§ 14.4)
Incident Response	Prozess für Sicherheitsvorfälle	umgesetzt	schlanker 7-Schritte-Prozess (§ 17.2); gesonderter Incident-Response-Prozess als Betriebsdokument (§ 27.3)
Datenschutz	Lösch- und Aufbewahrungskonzept	umgesetzt	als gesondertes internes Betriebsdokument geführt (§ 20.1, § 27.3)
Cloud-Sicherheit	Prüfung Anbieter-DPAs, TOM und C5-/Sicherheitsnachweise	in Umsetzung	Hetzner-AVV und C5-Testat (Scope geprüft) liegen vor; offene DPAs der übrigen Anbieter werden ergänzt; C5-Status siehe § 22.2 und Nachweisdossier § 393 SGB V / C5

26. Praktische Mindest-Checkliste für den Pilotbetrieb

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

26.1 Vor Start einer Pilotpraxis

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 in Issue, Changelog oder 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. Haftungs- und Statushinweis

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen von Flurin und ist Bestandteil des Vertrags zur Auftragsverarbeitung (Anlage 2). Es dokumentiert nur Maßnahmen, die tatsächlich umgesetzt oder in Umsetzung sind; ein über den dokumentierten Stand hinausgehendes Sicherheits- oder Zertifizierungsniveau wird nicht behauptet.

Die Kernmaßnahmen (TLS-Transportverschlüsselung, Verschlüsselung ruhender Daten, MFA für administrative Zugriffe, Mandantentrennung, Backup-Konzept inkl. erfolgreichem Restore-Test sowie SPF/DKIM/DMARC) sind produktiv umgesetzt. Das BSI-C5-Testat von Hetzner liegt vor; der geprüfte Geltungsbereich deckt die genutzte Produktlinie und Region ab. Noch offene Punkte – insbesondere die Ablage der DPAs sowie der Angaben zu Sub-Unterauftragnehmern und Drittlandbezug von Brevo, Bunny.net und Hanko, die abschließende anwaltliche Klärung der Anwendbarkeit des § 393 SGB V sowie das turnusmäßige Monitoring des EU-US-DPF – werden gesondert in einer Go-Live-Checkliste geführt. Angaben zu Sicherheitsnachweisen eingesetzter Anbieter haben den Stand 17.06.2026 (vgl. Nachweisdossier § 393 SGB V / C5).

Eine ergänzende anwaltliche Prüfung dieses Dokuments wird empfohlen. Dieses Dokument stellt keine Rechtsberatung dar.

Ende der Technischen und organisatorischen Maßnahmen