Darf eine DiGA Daten außerhalb der EU verarbeiten?

Nur sehr eingeschränkt. § 4 Abs. 3 DiGAV erlaubt die Verarbeitung personenbezogener Daten für DiGA-Zwecke ausschließlich in Deutschland, einem EU-Mitgliedstaat, einem über § 35 Abs. 7 SGB I gleichgestellten EWR-Staat oder einem Drittland mit einem EU-Angemessenheitsbeschluss nach Art. 45 DSGVO. Außerhalb dieser Staatengruppe ist die Verarbeitung für eine DiGA unzulässig — und das gilt für die DiGA selbst genauso wie für jeden Auftragsverarbeiter, der in ihrem Auftrag Daten verarbeitet. Die USA sind nicht pauschal abgedeckt, sondern nur über das EU-US Data Privacy Framework und nur, wenn die konkrete US-Stelle selbst DPF-zertifiziert ist. Im Einzelfall rechtlich prüfen.

Reicht eine EU-Region eines US-Anbieters für eine DiGA?

Nein, allein nicht. Eine 'EU-Region (Frankfurt)' ändert nur den Serverstandort, nicht die Jurisdiktion der betreibenden Rechtsperson. Ist diese ein US-Unternehmen oder eine EU-Tochter eines nicht-DPF-zertifizierten US-Mutterkonzerns, folgt die CLOUD-Act-Reichweite dem Unternehmen, nicht dem Server. Die BfArM-Datenschutz-Prüfkriterien greifen das in Kriterium AV_1.3 ausdrücklich auf und verweisen auf das Schrems-II-Urteil: Töchter US-amerikanischer Unternehmen seien faktisch nicht ohne Weiteres in der Lage, gegebene Zusagen einzuhalten. Eine generische EU-Region liefert keinen Angemessenheitsbeschluss nach Art. 45 — und genau den verlangt das BfArM.

Sind Standardvertragsklauseln für eine DiGA ausreichend?

Nein. Laut der BfArM-Handreichung zur Datenverarbeitung außerhalb Deutschlands (Stand 11.10.2023) sind Standardvertragsklauseln nach Art. 46 DSGVO und Binding Corporate Rules nach Art. 47 für DiGA nicht ausreichend, und auch eine Einwilligung nach Art. 49 wird nicht akzeptiert. Für DiGA-Zwecke gilt ausschließlich der Angemessenheitsbeschluss nach Art. 45 DSGVO. SCC und BCR sind in anderen DSGVO-Kontexten legitime Transfermechanismen — für die Verarbeitungsort-Regel einer DiGA aber gerade nicht. Im Einzelfall rechtlich prüfen.

Ist FoundersDeck als Sub-Processor für eine DiGA geeignet?

FoundersDeck ist ein zulässig einbindbarer Sub-Processor, weil die Verarbeitung ausschließlich in der EU stattfindet. FoundersDeck ist ein inhabergeführtes deutsches Unternehmen, hostet ausschließlich bei der Netcup GmbH in Nürnberg, keine Daten verlassen die EU, und es ist nicht dem US CLOUD Act oder FISA 702 unterworfen — der Verarbeitungsort liegt also vollständig im Rahmen von § 4 Abs. 3 DiGAV (Inland). Wichtig zur Abgrenzung: FoundersDeck verarbeitet keine Patientendaten, sondern überwacht Endpunkte, Antwortzeiten und Statuscodes. Es macht deine DiGA nicht konform, sondern unterstützt deine Pflichten und liefert die technischen Verfügbarkeitsnachweise. Ein Sofort-AVV nach Art. 28 DSGVO steht bereit.

DiGA-Datenverarbeitung außerhalb Deutschlands: Was § 4 DiGAV wirklich verlangt

„Darf meine DiGA ihre Daten außerhalb Deutschlands verarbeiten?” ist eine der ersten Fragen, die im Prüfverfahren des BfArM verlässlich auftaucht — und eine der Fragen, bei der die größte Verwirrung herrscht. Die kurze Antwort: nur innerhalb einer eng definierten Staatengruppe, und mit Mechanismen, die enger gefasst sind als das, was die DSGVO sonst erlaubt.

Dieser Artikel ordnet ein, was § 4 Abs. 3 DiGAV konkret verlangt, warum Standardvertragsklauseln hier nicht genügen und warum eine „EU-Region” eines US-Anbieters die Anforderung nicht erfüllt. Er ersetzt keine Rechtsberatung — die Bewertung deiner konkreten Verarbeitungskette ist im Einzelfall zu prüfen. Eine Übersicht aller DiGA-relevanten Themen findest du in unserem DiGA-Hub.

Was schreibt § 4 Abs. 3 DiGAV genau vor?

Die DiGAV zieht eine harte geografische Grenze: Personenbezogene Daten dürfen für die Zwecke einer Digitalen Gesundheitsanwendung ausschließlich an bestimmten Orten verarbeitet werden. Nach § 4 Abs. 3 DiGAV sind das:

Deutschland (Inland),
ein Mitgliedstaat der Europäischen Union,
ein über § 35 Abs. 7 SGB I gleichgestellter EWR-Staat,
oder ein Drittland mit einem EU-Angemessenheitsbeschluss nach Art. 45 DSGVO.

Entscheidend sind zwei Details, die in der Praxis oft untergehen. Erstens: Die Regel gilt nicht nur für die DiGA selbst, sondern für jeden Auftragsverarbeiter, der im Auftrag der DiGA Daten verarbeitet. Ein nachgelagerter Sub-Processor mit Verarbeitung außerhalb dieser Staatengruppe reißt die Anforderung also genauso, wie es die DiGA selbst täte. Zweitens: Die Rechtsgrundlage des gesamten BfArM-DiGA-Verzeichnisses (Fast-Track) ist § 139e SGB V — die Verarbeitungsort-Regel ist damit Teil dessen, was im Prüfverfahren tatsächlich geprüft und durchgesetzt wird.

Hinweis zur Zitierung: Die Verarbeitungsort-Regel steht in § 4 Abs. 3 DiGAV. Ältere Materialien aus 2024 verweisen teils noch auf „Abs. 5” — das ist veraltete Nummerierung. Maßgeblich ist Abs. 3.

Welche Transfermechanismen erkennt das BfArM an — und welche nicht?

Hier liegt die wichtigste und am häufigsten missverstandene Einschränkung: Für DiGA gilt ausschließlich der Angemessenheitsbeschluss nach Art. 45 DSGVO. Die sonst üblichen Transfermechanismen der DSGVO sind nach der BfArM-Handreichung „Informationen zur Zulässigkeit der Datenverarbeitung außerhalb Deutschlands im Zusammenhang mit dem Prüfverfahren des BfArM gemäß § 139e SGB V” (Stand 11.10.2023) für DiGA nicht ausreichend.

Mechanismus	DSGVO-Grundlage	Für eine DiGA ausreichend?
Angemessenheitsbeschluss	Art. 45	Ja — der einzige akzeptierte Weg
Standardvertragsklauseln (SCC)	Art. 46	Nein — laut BfArM nicht ausreichend
Binding Corporate Rules (BCR)	Art. 47	Nein — laut BfArM nicht ausreichend
Einwilligung / Ausnahmen	Art. 49	Nein — wird nicht akzeptiert

Das ist eine bewusste Verschärfung gegenüber dem allgemeinen Datenschutzrecht. SCC und BCR sind in vielen anderen Kontexten völlig legitime Werkzeuge für Drittlandtransfers — für die Verarbeitungsort-Regel einer DiGA aber gerade nicht. Wer also seine Drittland-Verarbeitung „mit Standardvertragsklauseln abgesichert” hat, hat das DiGA-Problem damit nicht gelöst.

Die Anforderung ist in den BfArM-Datenschutz-Prüfkriterien (Version 1.0, 24.04.2024) auch konkret operationalisiert: Kriterium AV_1.1 bildet die Verarbeitungsort-Regel ab (ausschließlich Inland / EU / gleichgestellt / Art. 45). Kriterium AV_1.3 verlangt darüber hinaus zusätzliche Garantien, wenn ein Auftragsverarbeiter einen Mutterkonzern in einem nicht-konformen Drittland hat — und benennt das Problem ausdrücklich mit Bezug auf Schrems II: „Töchter US-amerikanischer Unternehmen sind faktisch nicht ohne Weiteres in der Lage, die gegebenen Zusagen … einzuhalten (siehe … Schrems-II-Urteil).”

Was ist mit den USA und dem Data Privacy Framework?

Die USA haben keinen länderweiten Angemessenheitsbeschluss. Abgedeckt sind sie ausschließlich über das EU-US Data Privacy Framework (DPF) — den Angemessenheitsbeschluss der EU-Kommission für in den USA niedergelassene, DPF-zertifizierte Organisationen (Durchführungsbeschluss (EU) 2023/1795 vom 10. Juli 2023).

Daraus folgt eine Bedingung, die in der DiGA-Praxis fast immer übersehen wird: Der DPF hilft nur dann, wenn die konkrete US-Stelle, die Daten verarbeitet, selbst DPF-zertifiziert ist — und zwar für genau diese Verarbeitung. Eine EU-Tochter, deren US-Mutterkonzern nicht DPF-zertifiziert ist, ist damit gerade nicht abgedeckt: Die EU-Niederlassung allein genügt nicht.

Zur ehrlichen Einordnung des DPF-Status: Der Beschluss ist derzeit in Kraft, aber gerichtlich angefochten. Im Verfahren Latombe hat das Gericht der EU die Klage T-553/23 am 3. September 2025 abgewiesen; ein Rechtsmittel ist anhängig (eingelegt am 31. Oktober 2025). Wer den DPF heute nutzt, baut also auf eine Rechtsgrundlage, die gültig, aber nicht abschließend bestätigt ist. Für eine DiGA, die über Jahre im Verzeichnis stehen soll, ist das ein Risiko, das man bewusst bewerten und im Einzelfall rechtlich prüfen sollte.

Beispiel: Warum eine „EU-Region (Frankfurt)” eines US-Tools trotzdem scheitert

Nehmen wir ein konkretes, alltägliches Szenario. Du betreibst eine DiGA und willst ein bekanntes Monitoring- oder SaaS-Tool einsetzen, das mit einer „EU-Region (Frankfurt)” wirbt. Die Server stehen in Deutschland — also alles in Ordnung? Gehen wir es entlang der Prüfkriterien durch:

Wer ist die betreibende Rechtsperson? Im Impressum oder in den AGB steht eine US-Gesellschaft — oder eine EU-Tochter eines US-Mutterkonzerns. Genau hier setzt AV_1.3 an.
Ist diese Stelle DPF-zertifiziert für diese Verarbeitung? Ist sie es nicht, greift der einzige USA-Pfad (das DPF) von vornherein nicht.
Folgt die Jurisdiktion dem Server oder dem Unternehmen? Dem Unternehmen. Der US CLOUD Act verpflichtet US-eingetragene Anbieter zur Datenherausgabe — unabhängig davon, wo die Server stehen. Eine Frankfurter Region ändert daran nichts.
Helfen Standardvertragsklauseln? Für eine DiGA nicht — siehe Tabelle oben. SCC heilen den Mangel hier nicht.
Was verlangt das BfArM stattdessen? Einen Angemessenheitsbeschluss nach Art. 45 — und den liefert eine generische „EU-Region” nicht.

Das Ergebnis: Die EU-Region besteht die Prüfung nicht. Der Merksatz, der diesen ganzen Abschnitt zusammenfasst, lautet: Serverstandort ≠ Jurisdiktion. Wo die Daten physisch liegen, ist nachrangig gegenüber der Frage, welcher Staat ihre Herausgabe erzwingen kann. Wir haben diese Lücke quantifiziert: In unserer EU Jurisdiction Database (eigene Erhebung, zuletzt verifiziert am 9. Juni 2026) sind von 57 erfassten Tools 29 US-eingetragen, davon 25 direkt dem CLOUD Act ausgesetzt; nur 16 von 57 garantieren echte EU-Datenresidenz, und nur 7 von 57 bieten einen Self-Service-AVV.

Wo passt FoundersDeck in diese Anforderung?

FoundersDeck ist ein zulässig einbindbarer Sub-Processor für eine DiGA, weil die Verarbeitung den Verarbeitungsort-Anforderungen von § 4 Abs. 3 DiGAV entspricht — und zwar über den engsten verfügbaren Pfad: Inland.

Inhabergeführtes deutsches Unternehmen. Die betreibende Rechtsperson sitzt in Deutschland — die Jurisdiktion folgt also dem Inland, nicht einem Drittland.
Hosting ausschließlich bei der Netcup GmbH in Nürnberg. Keine Monitoring-Daten verlassen die EU.
Nicht dem US CLOUD Act oder FISA 702 unterworfen. Damit entfällt genau die Exposition, die AV_1.3 bei US-Töchtern problematisiert.
Sofort-AVV nach Art. 28 DSGVO. Der Auftragsverarbeitungsvertrag ist sofort verfügbar — relevant, weil er für jeden Sub-Processor einer DiGA ohnehin Pflicht ist.

Zwei Klarstellungen, die uns wichtig sind. Erstens zum Datenumfang: FoundersDeck verarbeitet keine Patientendaten. Das Tool überwacht Endpunkte, Antwortzeiten und Statuscodes — es liefert Verfügbarkeits- und Vorfallsnachweise, nicht Gesundheitsdaten. Zweitens zur Reichweite: FoundersDeck macht deine DiGA nicht konform. Konformität ist eine Gesamtleistung deines Unternehmens. Was FoundersDeck tut, ist deine Pflichten zu unterstützen und die technischen Nachweise zu liefern, die du für Verfügbarkeit und Vorfallbearbeitung brauchst.

Wie ein DiGA-tauglicher Sub-Processor vertraglich sauber eingebunden wird — von der Subprozessoren-Liste bis zum AVV-Wortlaut — vertiefen wir in Sub-Processor & AVV für DiGA. Den Einstieg in alle weiteren DiGA-Themen bietet der DiGA-Hub.

Die wichtigsten Punkte auf einen Blick

§ 4 Abs. 3 DiGAV erlaubt DiGA-Datenverarbeitung nur in Deutschland, der EU, gleichgestellten EWR-Staaten oder Drittländern mit Angemessenheitsbeschluss nach Art. 45 — für die DiGA und ihre Auftragsverarbeiter.
SCC (Art. 46), BCR (Art. 47) und Einwilligung (Art. 49) reichen für eine DiGA nicht — anders als im allgemeinen DSGVO-Kontext.
Die USA sind nur über das DPF und nur bei konkreter DPF-Zertifizierung der verarbeitenden Stelle abgedeckt; das DPF ist derzeit in Kraft, aber gerichtlich angefochten.
Eine „EU-Region” eines US-Anbieters genügt nicht (AV_1.3): Serverstandort ≠ Jurisdiktion.
Jede über die verifizierten Fakten hinausgehende Aussage ist allgemeine Orientierung — im Einzelfall rechtlich prüfen.

Dieser Artikel gibt den Rechtsstand zum Stand: Juni 2026 wieder und dient der Orientierung, nicht der Rechtsberatung. Quellen: § 4 DiGAV, § 139e SGB V, BfArM-Handreichung zur Datenverarbeitung außerhalb Deutschlands (Stand 11.10.2023), BfArM-Datenschutz-Prüfkriterien (Version 1.0, 24.04.2024), Durchführungsbeschluss (EU) 2023/1795 (EU-US Data Privacy Framework). Alle Fakten sind gegen die Primärquellen geprüft — Korrekturen sind ausdrücklich willkommen.