# Pflichtenkollision beim Datentransfer in die USA: Was Sabine Schmidt *wirklich* braucht – belastbare Doku, tragfähige Maßnahmen, schnelle Entlastung Sabine kennt das Dilemma: Fachbereiche wollen „einfach loslegen“ – die neue Cloud‑Plattform, das Kollaborationstool, der US‑basierte Support. Und am Ende landet die Verantwortung für **Risikoabwägung, Dokumentation und Audit‑Festigkeit** bei dir. Genau hier taucht ein Klassiker auf, der in der Praxis schnell unangenehm wird: **Pflichtenkollisionen beim Datentransfer in die USA**. Dieser Beitrag ist für Datenschutz‑Managerinnen im Gesundheitswesen/MedTech gedacht, die **keine Debatte über Grundsatzfragen**, sondern **klare Schritte, Vorlagenlogik und Entscheidungsfähigkeit** brauchen. --- ## 1) Was bedeutet „Pflichtenkollision“ im USA‑Kontext? Eine Pflichtenkollision entsteht, wenn du gleichzeitig: - **DSGVO‑Pflichten** erfüllen musst (insb. rechtmäßige Drittlandübermittlung nach Art. 44 ff. DSGVO, Rechenschaftspflicht, TOMs, Risikomanagement), - aber der eingesetzte US‑Anbieter (oder ein EU‑Anbieter mit US‑Anbindung) **unter US‑Recht** stehen kann, das **Behördenzugriffe oder Herausgabeanordnungen** ermöglicht. Der praktische Konflikt ist nicht theoretisch, sondern operativ: - Du sollst **wirksame Garantien** gegen unzulässige Zugriffe nachweisen. - Gleichzeitig kann ein Provider rechtlich verpflichtet sein, Daten herauszugeben – teilweise ohne dich informieren zu dürfen. --- ## 2) Warum ist das für Gesundheitswesen/MedTech besonders heikel? Weil hier typischerweise (mindestens) eines zusammenkommt: - **besondere Kategorien personenbezogener Daten** (Gesundheitsdaten), - **hohe Regulatorik-/Auditdichte** (z. B. Kunden‑Audits, ISO‑Umfelder, MDR‑Nähe, KRITIS‑Nähe je nach Setup), - **hohe Schadenswirkung** bei Datenabfluss oder unklarer Rechtslage. Ergebnis: Du brauchst nicht nur „SCC unterschrieben“, sondern eine **belastbare Argumentation + technische Realität**, die das Schutzniveau wirklich trägt. --- ## 3) Der DSGVO‑Rahmen in 5 Sätzen (damit du intern schnell einordnen kannst) 1. **USA = Drittland** → Transfers sind nur zulässig über Art. 45, 46 oder (selten) 49 DSGVO. 2. Seit **10.07.2023** gibt es wieder einen Angemessenheitsbeschluss: **EU‑US Data Privacy Framework (DPF)** – aber nur für **zertifizierte US‑Unternehmen** und nur im zertifizierten Umfang. 3. Wenn kein DPF greift: meist **SCC (EU‑SCC 2021/914)**. 4. Seit **Schrems II (EuGH, 16.07.2020, C‑311/18)** reicht „SCC unterschrieben“ allein nicht: Du brauchst eine **Transfer‑Risiko-/Schutzniveauprüfung (TIA)** und ggf. **zusätzliche Maßnahmen**. 5. Der EDPB gibt mit **Empfehlungen 01/2020** einen etablierten Praxisrahmen (Transfers finden → Instrument → TIA → Zusatzmaßnahmen → Dokumentation → Monitoring). --- ## 4) Typische „Pflichtenkollision“-Szenarien, die in Audits auffallen ### Szenario A: Cloud‑Nutzung mit Admin-/Supportzugriff aus den USA - Microsoft 365, Azure‑Services, Collaboration‑Tools, Ticketing. - Risiko: **Remote‑Zugriffe**, Logfiles, Diagnosedaten, Support‑Tickets → schnell Drittlandtransfer. ### Szenario B: „Nur kurz Support“ – und plötzlich ist es ein Transfer - Ad‑hoc‑Screen‑Sharing, Remote‑Desktop, Upload von Protokollen oder Datenbank‑Auszügen. - Typischer Audit‑Killer: **kein klarer Prozess**, wann Support auf welche Daten zugreifen darf. ### Szenario C: E‑Discovery / Litigation Hold - US‑Prozessrecht kann **Aufbewahrung/Offenlegung** verlangen. - Kollision mit **Löschkonzepten, Speicherbegrenzung, Zweckbindung**. ### Szenario D: Auskunftsanordnung + mögliche Geheimhaltung - Kollision von **Transparenzpflichten** (Betroffene informieren) vs. **gag orders** (Provider darf nicht informieren). --- ## 5) „DPF oder SCC?“ – eine pragmatische Entscheidungslogik ### Schritt 1: Prüfe DPF – aber richtig Wenn der US‑Anbieter **DPF‑zertifiziert** ist und dein konkreter Dienst/Scope umfasst ist: - Transfer kann über **Art. 45 DSGVO** abgesichert sein. - **Trotzdem**: Dokumentiere die Prüfung (Zertifizierung, Scope, Weiterübermittlungen/Subprocessor, Datenarten). Wenn **kein DPF** oder unklarer Scope: - **SCC + TIA + Zusatzmaßnahmen**. ### Merksatz für interne Abstimmungen - **DPF reduziert Aufwand**, ersetzt aber nicht deine Pflicht, die **Datenflüsse, Zugriffe und Konfiguration** zu verstehen. --- ## 6) Das TIA, das dich wirklich entlastet (statt Papier zu produzieren) Ein gutes TIA ist für dich nicht „80 Seiten Juristerei“, sondern eine **prüfbare Begründung**, die du bei Audit/DPA‑Rückfragen schnell verteidigen kannst. ### Minimal‑Inhalte, die in der Praxis tragen 1. **Transfer‑Landkarte** (welche Systeme, welche Datenkategorien, welche Betroffenen, welche Zwecke). 2. **Zugriffsmatrix** (wer *kann* zugreifen: Admin, Support, Subprocessor – inkl. Länder). 3. **Rechtsinstrument** (DPF oder SCC; bei SCC: Module, Rollen, Subprocessor‑Kette). 4. **Risikoargumentation** (Wahrscheinlichkeit/Schwere *für diesen Use Case*). 5. **Zusatzmaßnahmen** (technisch/organisatorisch/vertraglich) + Restrestrisiko. 6. **Entscheidung & Freigabe** (wer hat wann was entschieden; inkl. Eskalationsweg). ### Typischer Fehler Das TIA abstrahiert, aber die Realität (z. B. Support‑Prozesse, Telemetrie, Logs) ist nicht im Dokument abgebildet. --- ## 7) Zusatzmaßnahmen: Was Aufsichtsbehörden typischerweise überzeugt In vielen Konstellationen sind **technische Maßnahmen** der entscheidende Hebel. ### Technische Maßnahmen (meist „Game Changer“) - **Starke Verschlüsselung** (at rest / in transit) mit **Schlüsselhoheit in der EU** (BYOK/HYOK – je nach Plattform realistisch). - **Pseudonymisierung/Tokenisierung**: US‑Dienste sehen nur Ersatzwerte; Zuordnung bleibt EU‑kontrolliert. - **Datenminimierung & Segmentierung**: weniger Daten, weniger Systeme, weniger Zugriffspunkte. - **Client‑seitige Verschlüsselung / Split‑Processing** (wo umsetzbar). ### Organisatorisch/vertraglich (als Stabilisierung) - Zugriff nur über **break‑glass‑Prozess**, protokolliert, genehmigt. - **Transparenzberichte**, Benachrichtigungspflichten, Verpflichtung zur Anfechtung unzulässiger Anordnungen (soweit möglich). - Strenge **Subprocessor‑Kontrolle** (Liste, Genehmigungsprozess, Change‑Monitoring). --- ## 8) Der Part, der in Stresssituationen Gold wert ist: Eskalations- & „US‑Request“-Playbook Wenn wirklich eine Anfrage/Anordnung im Raum steht, brauchst du keine Diskussion – du brauchst ein **vorgefertigtes Vorgehen**. ### Playbook‑Bausteine (1 Seite reicht) - **Kontaktkette**: Datenschutz ↔ IT/Sec ↔ Legal ↔ Management. - **Entscheidungsmatrix**: Herausgabe/Anfechtung/Teilherausgabe – wer entscheidet. - **Dokumentationspflichten**: was wird wo dokumentiert (Ticket, Incident‑Akte, Transfer‑Register). - **Kommunikationsregeln**: intern/extern, Betroffeneninfo (falls zulässig), Aufsichtsbehörde (falls meldepflichtig). --- ## 9) Sofort nutzbare Checkliste für Sabine (Copy/Paste in dein Projektboard) **A. Datenfluss klären** - [ ] Systeme/Dienste identifiziert (inkl. Logs/Telemetrie) - [ ] Zugriffsrollen + Support‑Prozesse dokumentiert - [ ] Subprocessor‑Kette inkl. Länderzugriffen erfasst **B. Transfergrundlage** - [ ] DPF‑Status geprüft + Scope dokumentiert - [ ] Falls kein DPF: SCC (2021/914) abgeschlossen + Module korrekt **C. TIA** - [ ] Datenarten/Betroffenengruppen/Zwecke beschrieben - [ ] Risiko (Wahrscheinlichkeit/Schwere) bewertet - [ ] Zusatzmaßnahmen festgelegt + Restrestrisiko begründet - [ ] Entscheidung/Freigabe mit Datum und Verantwortlichen dokumentiert **D. Maßnahmenbetrieb** - [ ] Verschlüsselung + Schlüsselmanagement (EU‑Kontrolle) umgesetzt/prüfbar - [ ] Zugriffskontrollen, Logging, regelmäßige Reviews - [ ] Incident/US‑Request‑Playbook freigegeben - [ ] Monitoring (DPF‑Status, Subprocessor‑Changes, Feature‑Änderungen) --- ## 10) Fazit: DPF hilft – aber die Pflichtenkollision löst du mit Governance + Technik Wenn du nur ein Learning mitnehmen willst: - **DPF kann Transfers vereinfachen**, aber löst die operativen Fragen (Zugriffe, Support, Logs, Schlüsselhoheit) nicht automatisch. - Ein **TIA mit Zugriffsmatrix + technischen Zusatzmaßnahmen** macht dich handlungsfähig – und auditfest. - Am meisten entlastet dich ein Setup, das nicht jedes Mal neu „erfunden“ wird: **Vorlagen, Standardprozesse, Playbooks**. --- ## Call‑to‑Action (für Sabines Realität) Wenn du willst, kann ich dir aus den obigen Bausteinen ein **„Rundum‑Sorglos“-Paket** als sofort nutzbare Arbeitsunterlagen strukturieren (ohne Marketing‑Blabla): 1) **TIA‑Template** (inkl. Zugriffsmatrix, Risikologik, Freigabe‑Block) 2) **SCC‑Prüfcheck** (DPF‑Scope, Subprocessor‑Kette, Support‑Szenarien) 3) **US‑Request‑Playbook** (1–2 Seiten, eskalationsfähig) 4) Optional: **M365‑Spezial** (Support‑Zugriffe/Telemetrie/Schlüsselmodelle) als Guided Content Wenn du mir in 3 Stichpunkten sagst, welche Services bei euch am häufigsten betroffen sind (z. B. **M365/Azure**, **AWS**, **HR‑Tool**, **CRM**, **Website‑Tracking**), kann ich die Checkliste und Vorlagen passgenau auf eure typische Transfer‑Landschaft zuschneiden. --- ## Quellen (zitierfähig) - EuGH, Urteil **C‑311/18 („Schrems II“) vom 16.07.2020**. - Europäische Kommission: **Angemessenheitsbeschluss EU‑US Data Privacy Framework** vom **10.07.2023**. - Europäische Kommission: **Durchführungsbeschluss (EU) 2021/914** (Standardvertragsklauseln, **04.06.2021**). - EDPB: **Empfehlungen 01/2020** zu ergänzenden Maßnahmen bei Drittlandtransfers (finale Fassung **2021**).