# Pflichtenkollision beim Datentransfer in die USA: Was Sie *wirklich* dokumentieren und entscheiden müssen (DSGVO vs. US-Recht)

US-Tools sind im Gesundheitswesen und in der Medizintechnik längst Alltag: Cloud-Hosting, Collaboration, Ticketing, HR-Plattformen, Monitoring – und sehr häufig auch Microsoft-Ökosysteme. Gleichzeitig steigen Auditdruck und Erwartungshaltung: *„Zeigen Sie uns bitte nachvollziehbar, warum dieser Transfer zulässig ist – und welche Maßnahmen den Zugriff Dritter verhindern oder zumindest wirksam begrenzen.“*

Genau hier entsteht die **Pflichtenkollision**: EU-Recht verlangt ein Schutzniveau „im Wesentlichen gleichwertig“ zur DSGVO – während US-Recht in bestimmten Konstellationen **Zugriffe oder Herausgaben** an US-Behörden ermöglichen bzw. verpflichtend machen kann.

Dieser Beitrag ist als **Arbeitsanleitung** gedacht: Was steckt hinter dem Konflikt, welche Standardpfade gibt es (DPF vs. SCC), und welche **Dokumente/Entscheidungen** Sie brauchen, um intern und gegenüber Aufsichtsbehörden handlungsfähig zu bleiben.

---

## 1) Was bedeutet „Pflichtenkollision“ beim USA-Transfer konkret?

Von Pflichtenkollision sprechen wir, wenn zwei Rechtsordnungen gleichzeitig „ziehen“:

- **DSGVO (Art. 44 ff.)**: Ein Drittlandtransfer ist nur zulässig, wenn das Schutzniveau der DSGVO gewahrt bleibt.
- **US-Rechtliche Zugriffsrisiken**: Bestimmte US-Anbieter können unter Umständen verpflichtet sein, Daten herauszugeben oder Zugriffe zu ermöglichen – teils mit **Vertraulichkeitsanordnungen (Gag Orders)**.

Praktisch relevant wird das nicht nur bei „klassischer Überwachung“, sondern schon im Alltag:

- US-Cloud mit US-Support/Administrationszugriff
- konzerninterne Transfers an eine US-Mutter
- Collaboration/HR-Systeme mit personenbezogenen Beschäftigtendaten
- Web-Analytics/Marketing-Tools (auch wenn „nur“ Online-Kennungen fließen)

Die Kernfrage lautet dann nicht mehr „Dürfen wir das Tool nutzen?“, sondern: **Welcher Transfermechanismus greift, welches Restrisiko bleibt – und wie belegen wir das sauber?**

---

## 2) Der EU-Rechtsrahmen in 3 Bausteinen (Art. 44–49 DSGVO)

### a) Art. 44 DSGVO: Grundsatz
Jeder Drittlandtransfer muss ein DSGVO-konformes Schutzniveau „mitnehmen“. Das ist der rote Faden durch alle Prüfungen.

### b) Art. 45 DSGVO: Angemessenheitsbeschluss (USA: DPF)
Für die USA gibt es mit dem **EU–US Data Privacy Framework (DPF)** einen Angemessenheitsbeschluss der EU-Kommission. Wenn der US-Empfänger **DPF-zertifiziert** ist und der konkrete Transfer in den Scope fällt, ist das rechtlich der **einfachste** Pfad.

Wichtig für die Praxis: *„DPF vorhanden“* ist keine pauschale Entwarnung. Sie müssen weiterhin u. a. **Scope/Empfängerkreis**, Datenkategorien, Zweck und Auftragsverarbeitung sauber vertraglich und im Verzeichnis abbilden.

### c) Art. 46 DSGVO: SCC & Co. (Standardfall, wenn kein DPF)
Wenn kein DPF greift, landen Sie meist bei:
- **Standardvertragsklauseln (SCC)** und
- einer **Drittlandtransferprüfung / Transfer Impact Assessment (TIA)** sowie
- ggf. **Zusatzmaßnahmen** (technisch/organisatorisch/vertraglich).

### d) Art. 49 DSGVO: Ausnahmen (nur eng)
Art. 49 ist **kein** Rettungsanker für dauerhafte Massentransfers („wir machen das halt so“), sondern für eng begrenzte, gelegentliche Sonderfälle.

---

## 3) Warum die USA aus EU-Sicht besonders „heikel“ sind (ohne US-Recht zu überfrachten)

Die Konfliktlage wurde in Europa vor allem durch zwei EuGH-Urteile geprägt:

- **Schrems I (06.10.2015)**: „Safe Harbor“ gekippt.
- **Schrems II (16.07.2020)**: „Privacy Shield“ gekippt; SCC bleiben möglich, aber nur mit Einzelfallprüfung und ggf. Zusatzmaßnahmen.

Was steht dahinter? Stark vereinfacht:

- **FISA 702**: Kann bestimmte US-Anbieter in die Pflicht nehmen, Datenzugriffe zu ermöglichen.
- **Executive Order 12333**: Wird in der EU-Diskussion als weiterer Risikofaktor für nachrichtendienstliche Aktivitäten genannt.
- **CLOUD Act**: Kann Herausgabeanforderungen auch dann ermöglichen, wenn Daten physisch außerhalb der USA liegen.

Für Ihre Dokumentation bedeutet das: **„EU-Hosting“ allein** ist kein Automatismus. Entscheidend ist, *wer* tatsächlich Zugriff auf Klartext oder Schlüssel haben kann – und wie belastbar Ihre technischen und organisatorischen Maßnahmen sind.

---

## 4) DPF oder SCC? Ein praxistaugliches Entscheidungsraster

### Schritt 1: Prüfen, ob DPF wirklich greift
Fragen, die Sie klar beantworten und dokumentieren sollten:

1. **Ist der Empfänger DPF-zertifiziert?** (inkl. aktueller Zertifizierung, richtiger Rechtsträger)
2. **Welche Rolle hat der Empfänger?** Auftragsverarbeiter oder (Mit‑)Verantwortlicher?
3. **Welche Datenkategorien und Zwecke** umfasst der Transfer (auch Beschäftigtendaten)?
4. **Welche Unterauftragsverarbeiter** sind beteiligt?

Wenn DPF greift: Der Transfer ist auf Angemessenheitsniveau möglich – aber Governance, AVV, TOMs, Informationspflichten und Lösch-/Aufbewahrungskonzepte bleiben trotzdem Pflicht.

### Schritt 2: Wenn kein DPF: SCC + TIA + Zusatzmaßnahmen als Standardprozess
Hier hilft ein „immer gleiches“ Vorgehen (Audit-fest, delegierbar):

- **Datenfluss-Mapping** (welche Systeme, welche Daten, wohin, wer hat Zugriff?)
- **Transferinstrument** festlegen (SCC, ggf. BCR)
- **TIA**: Bewertung der Zugriffsrisiken und der Wirksamkeit der Maßnahmen
- **Zusatzmaßnahmen** (wenn SCC allein nicht reichen)
- **Re-Evaluation**: Regelmäßige Neubewertung (z. B. jährlich oder bei Provider-/Scope-Änderungen)

Die EDPB-Empfehlungen geben hierfür ein systematisches Vorgehen vor.

---

## 5) Zusatzmaßnahmen: Was Aufsichten in der Praxis sehen wollen

Wenn ein US-Anbieter (oder ein Anbieter unter US-Reichweite) **potenziell** Zugriff auf Klartextdaten hat, wird es oft eng. Typische belastbare Stellschrauben:

### Technische Maßnahmen (meist am wirksamsten)
- **Starke Verschlüsselung** (Transport *und* Ruhe), idealerweise so, dass der Anbieter **keinen Zugriff auf die Schlüssel** hat (Customer Managed Keys / Hold‑Your‑Own‑Key).
- **Ende‑zu‑Ende‑Verschlüsselung**, wo fachlich möglich.
- **Pseudonymisierung vor Transfer**, Re-Identifizierung nur in der EU.
- **Minimierung**: so wenig Daten wie möglich, so kurz wie möglich.

### Organisatorische Maßnahmen
- Striktes **Berechtigungs- und Admin-Konzept**, getrennte Rollen, Protokollierung.
- **Incident-/Government-Request-Prozess**: Wer entscheidet, wer dokumentiert, wer kommuniziert?
- Schulungen, damit Fachabteilungen nicht „mal schnell“ neue US-Tools einkaufen.

### Vertragliche Maßnahmen (unterstützend, selten allein ausreichend)
- Verpflichtung zur **Anfechtung/Challenge** von Behördenanfragen, soweit rechtlich zulässig.
- Transparenzberichte, Informationspflichten, Subprocessor-Kontrolle.

Wichtig: Zusatzmaßnahmen sind nur dann überzeugend, wenn sie *konkret* auf Ihre Datenflüsse passen. „Wir haben SCC unterschrieben“ ist seit Schrems II regelmäßig zu dünn.

---

## 6) Zwei typische „Trigger“-Szenarien – und was Sie dann sofort brauchen

### Szenario A: Anstehendes Audit / Kundenfragebogen (2 Wochen Frist)
**Lieferfähig sein** heißt: nicht neu denken, sondern abrufen.

Minimal-Set an Unterlagen:
- Auszug aus dem **Verzeichnis von Verarbeitungstätigkeiten** (inkl. Drittlandtransfer)
- **Transfermechanismus** (DPF-Nachweis oder SCC-Version inkl. Annexes)
- **TIA** (kurz, aber vollständig: Daten, Empfänger, Zugriffsrisiko, Maßnahmen, Ergebnis)
- TOM-Übersicht + ggf. Architektur-Skizze (Schlüsselmanagement, Admin-Zugriffe)
- Prozessbeschreibung „Government Requests“ und Incident-Handling

### Szenario B: Security-/Datenschutzvorfall oder behördliche Nachfrage
Dann zählt: **Zeitleiste + Entscheidungsspur**.

Unverzichtbar:
- Wer wusste wann was? Welche Systeme/Daten betroffen?
- Welche Transfergrundlage greift (DPF/SCC/Art. 49)?
- Wurden Zusatzmaßnahmen tatsächlich umgesetzt (nicht nur „geplant“)?
- Welche Sofortmaßnahmen wurden ergriffen (Zugriffe, Schlüsselrotation, Abschaltungen, Scope-Reduktion)?

---

## 7) Quick Wins: So reduzieren Sie Dokumentationslast, ohne Risiko zu erhöhen

1. **Ein TIA-Template als Standard** (mit festem Fragenkatalog): Datenarten, Zugriffspfade, Schlüsselhoheit, Subprocessor, Ergebnislogik.
2. **„Drittlandtransfer‑Check“ als Pflichtfeld** im Einkaufs-/IT‑Freigabeprozess (Ampellogik: DPF / SCC+TIA / Stop).
3. **Vordefinierte Maßnahmenpakete** je Use Case (z. B. „SaaS mit Supportzugriff“, „HR-Daten“, „Tracking“).
4. **Zentrales Evidence-Repository**: SCC, DPF-Nachweise, TOMs, Auditberichte, Architekturdiagramme – versioniert.
5. **Re‑Evaluation-Takt** festlegen (z. B. jährlich oder bei Anbieterwechsel, neuen Features, neuen Datenkategorien).

Damit wird aus „Sisyphus-Doku“ ein wiederholbarer Prozess, der auch dann funktioniert, wenn Fachabteilungen Druck machen.

---

## 8) Fazit: Pflichtenkollision ist beherrschbar – wenn Sie den Prozess standardisieren

Datentransfers in die USA sind nicht per se verboten, aber sie sind **prozess- und nachweispflichtig**. Ihre größte Entlastung entsteht, wenn Sie die Entscheidung wiederholbar machen:

- **DPF prüfen** (wenn möglich: nutzen, aber sauber scoped)
- sonst **SCC + TIA + passende Zusatzmaßnahmen**
- Dokumentation so aufsetzen, dass sie auditfähig ist – und nicht jedes Mal neu erfunden wird

Wenn Sie möchten, kann ich aus Ihrer Tool-Landschaft (z. B. M365, HR, CRM, Support, Analytics) ein **TIA-Muster inkl. Maßnahmenbibliothek** ableiten – so, dass Ihr Team beim nächsten Audit nur noch „Baukasten + Evidenzen“ zusammenzieht.

---

## Quellen & Orientierung (Auswahl)
- EuGH, C‑362/14 („Schrems I“), Urteil vom 06.10.2015
- EuGH, C‑311/18 („Schrems II“), Urteil vom 16.07.2020
- EU‑Kommission, Durchführungsbeschluss (EU) 2023/1795 (Angemessenheit EU–US Data Privacy Framework)
- EDPB, Empfehlungen 01/2020 (Supplementary Measures; final 2021)
- EDPB, Empfehlungen 02/2020 (European Essential Guarantees)

*Hinweis: Dieser Beitrag ersetzt keine Rechtsberatung im Einzelfall; insbesondere hängt die Bewertung stark von konkreten Datenflüssen, Zugriffspfaden und technischen Maßnahmen ab.*