# Pflichtenkollision beim Datentransfer in die USA: Was Sabine Schmidt (DSB intern) jetzt wirklich entlastet
Sabine kennt die Situation: Die Fachbereiche wollen „endlich loslegen“ – mit Cloud‑Tools, Kollaboration, KI‑Features, Support aus dem Ausland. Und am Ende bleibt bei dir als Datenschutzmanagerin die Verantwortung hängen, **dass der Datentransfer in die USA rechtlich sauber, dokumentiert und prüffest** ist.
Das Problem dabei ist selten mangelnder Wille im Unternehmen – sondern eine ganz typische **Pflichtenkollision**: **DSGVO‑Pflichten** (insb. Art. 44 ff. DSGVO) treffen auf **US‑Rechtsrahmen**, der in bestimmten Konstellationen behördliche Zugriffe oder Herausgabepflichten gegenüber US‑Anbietern ermöglichen kann. Dieser Beitrag ist so aufgebaut, dass du ihn direkt für deine interne Abstimmung nutzen kannst – inkl. Checkliste, TIA‑Gliederung und Eskalationslogik.
---
## 1) Was bedeutet „Pflichtenkollision“ beim USA‑Transfer konkret?
**Pflichtenkollision** heißt im Datenschutzkontext: Du musst nachweisen, dass eine Drittlandübermittlung **nur mit gültiger Transfergrundlage und wirksamem Schutzniveau** erfolgt – gleichzeitig kann der Anbieter (oder ein relevanter Konzernteil) **US‑Recht unterliegen**, das Datenzugriffe nicht vollständig ausschließbar macht.
Typische Reibungspunkte:
- **Rechenschaftspflicht** (Art. 5 Abs. 2 DSGVO): Du musst zeigen können, *warum* der Transfer zulässig ist.
- **Sicherheits- und Schutzpflichten** (Art. 24, 32 DSGVO): Du musst geeignete technische/organisatorische Maßnahmen (TOM) implementieren.
- **Transparenz** (Art. 13/14 DSGVO) vs. mögliche **Geheimhaltungsanordnungen** („gag orders“).
Der Konflikt wird praktisch, wenn z. B. Cloud‑Adminzugriffe, Support‑Tickets, Logfiles oder Fernwartung *faktisch* Drittlandbezüge erzeugen.
---
## 2) DSGVO‑Rahmen in 3 Transfer‑Schienen (und wann welche realistisch ist)
### Schiene A: Angemessenheitsbeschluss – EU‑US Data Privacy Framework (DPF)
Seit **10.07.2023** gibt es für die USA wieder einen Angemessenheitsbeschluss – **aber nur für DPF‑zertifizierte US‑Unternehmen und nur im zertifizierten Umfang**.
**Praktischer Effekt:** Wenn der Anbieter DPF‑zertifiziert ist (und dein Use Case im Scope liegt), wird der Transfer deutlich leichter.
**Achtung für deine Risikoakte:** Viele Unternehmen planen bereits mit einem möglichen „Schrems III“-Szenario – das ist kein Grund zur Panik, aber ein Grund für **Monitoring und Exit‑Optionen**.
### Schiene B: Standardvertragsklauseln (SCC) + Transfer Impact Assessment (TIA) + Zusatzmaßnahmen
Wenn **kein DPF** greift, ist das in der Praxis meist der Standard:
- SCC (EU‑SCC 2021) als Transferinstrument
- **TIA** als dokumentierte Prüfung
- ggf. **zusätzliche Maßnahmen**, wenn das Schutzniveau sonst nicht „wesentlich gleichwertig“ ist
### Schiene C: Art. 49‑Ausnahmen
Art. 49 ist in der Regel **nur für echte Einzelfälle** geeignet (nicht als Dauerlösung für Standard‑Cloud‑Nutzung).
---
## 3) Warum „Schrems II“ die Pflichtenkollision verschärft hat
Der EuGH hat mit **Schrems II (C‑311/18, 16.07.2020)** klar gemacht: SCC sind nicht „Plug‑and‑Play“. Unternehmen müssen prüfen, ob im Empfängerland ein **im Wesentlichen gleichwertiges** Schutzniveau gewährleistet ist – und wenn nicht, müssen **zusätzliche Maßnahmen** her oder der Transfer ist auszusetzen.
Für deine Arbeit heißt das:
- Du brauchst eine **TIA‑Logik**, die du wiederholen kannst.
- Du brauchst **standardisierte Zusatzmaßnahmen**, die mit IT und Einkauf schnell vereinbar sind.
- Du brauchst eine **Eskalation**, wenn Anbieter keine ausreichenden Zusicherungen liefern.
---
## 4) US‑Recht als Konflikttreiber – welche Stichworte du kennen musst (ohne dich zu verzetteln)
In vielen TIAs tauchen immer wieder drei Themen auf:
- **FISA Section 702** (relevant v. a. für bestimmte Kommunikationsdienstleister)
- **Executive Order 12333** (nachrichtendienstlicher Rahmen)
- **CLOUD Act** (Herausgabe-/Zugriffsszenarien auch bei Speicherung außerhalb der USA)
Wichtig für Sabine‑Realität: Du musst nicht US‑Recht „durchprüfen wie eine Kanzlei“ – aber du brauchst eine **pragmatische Bewertung**, ob dein Anbieter/Use Case *typischerweise* in Risikokategorien fällt (z. B. Kommunikationsdienste, große Cloud‑Provider, Supportzugriffe) und welche **Gegenmaßnahmen** du implementierst.
---
## 5) Die 6 häufigsten Pflichtenkollision‑Szenarien (mit typischer Doku‑Spur)
1) **Cloud‑Nutzung mit Admin‑ oder Supportzugriff aus den USA**
- Doku: Datenflussdiagramm, Zugriffsrollen, Remote‑Access‑Protokolle
2) **Ticket‑Systeme & Supportfälle** (Anhänge, Screenshots, Logs)
- Doku: Ticket‑Richtlinie, „No‑PII“-Regeln, Redaktions-/Schwärzungsprozess
3) **Website‑Tracking/Analytics**
- Doku: CMP‑Konzept, Proxy-/Server‑Side‑Ansätze, Anbieterprüfung, Rechtsgrundlage
4) **HR‑Tools (Recruiting/Onboarding), CRM, Marketing‑Automatisierung**
- Doku: TOM‑Anhang, Rollen-/Berechtigungskonzept, Speicherfristen/Löschkonzept
5) **E‑Discovery / Litigation Hold**
- Doku: Legal‑Hold‑Policy, Abgrenzung zu Löschpflichten, Freigabeprozess
6) **Behördliche Anordnung + Geheimhaltung**
- Doku: Incident-/Eskalationsplan, Verantwortlichkeiten, Kommunikationsmatrix
---
## 6) Das Entlastungs‑Framework: So baust du eine prüffähige Standardlösung (TIA + Maßnahmenpaket)
### Schritt 1: Transfer sauber identifizieren (auch „versteckte“ Transfers)
Fragen, die du einmal standardisierst und dann überall wiederverwenden kannst:
- Wo werden Daten **gespeichert** (Region/Backups)?
- Gibt es **Fernzugriffe** aus Drittstaaten (Admin, Support, Monitoring)?
- Welche **Unterauftragsverarbeiter** sind beteiligt?
- Gibt es **Telemetrie/Diagnosedaten**, die „nebenbei“ übertragen werden?
**Output:** 1‑seitiges Datenfluss‑Sheet + Subprocessor‑Liste (Version/Datum).
### Schritt 2: Transfergrundlage festlegen (DPF zuerst prüfen)
- Ist der Anbieter **DPF‑zertifiziert**?
- Deckt die Zertifizierung **deinen Service** und die **Datenkategorien** ab?
- Wie sind **Weiterübermittlungen** geregelt (Subprocessor)?
Wenn nein: SCC + TIA.
### Schritt 3: TIA – eine Gliederung, die Aufsicht & Audit „versteht“
**TIA‑Kurzgliederung (copy/paste‑fähig):**
1. Beschreibung des Transfers (Parteien, Rollen, Länder, Zweck)
2. Datenkategorien & Betroffenengruppen (inkl. besondere Kategorien)
3. Zugriffsszenarien (Support, Admin, Behördenanfragen)
4. Bewertung Schutzniveau (Recht & Praxis – risikobasiert)
5. Zusatzmaßnahmen (technisch/organisatorisch/vertraglich)
6. Restrisiko + Entscheidung (go/conditional go/no go)
7. Monitoring‑Trigger (wann neu bewerten?)
### Schritt 4: Zusatzmaßnahmen priorisieren (technisch schlägt „Papier“)
Wenn du nur eine Sache aus Schrems II/EDPB mitnimmst: **Zusatzmaßnahmen sind oft nur dann wirksam, wenn sie technisch greifen.**
**Technische Maßnahmen (typisch wirksam):**
- **Starke Verschlüsselung** (at rest / in transit) mit **Schlüsselkontrolle in der EU** (BYOK/HYOK)
- **Client‑seitige Verschlüsselung**, wo möglich
- **Pseudonymisierung/Tokenisierung** (Zuordnungstabelle in der EU)
- **Datenminimierung & Segmentierung** (nur nötige Felder, getrennte Mandanten)
**Organisatorisch/vertraglich (als Paket):**
- Strenge Rollen-/Berechtigungsmodelle, MFA, Just‑in‑Time‑Admin
- Audit/Logging/Review‑Prozesse
- Verpflichtung zur **Benachrichtigung** und **Anfechtung** unverhältnismäßiger Anfragen (soweit zulässig)
- Subprocessor‑Kontrolle + Change‑Notification
### Schritt 5: Eskalationsplan bei US‑Anordnung (damit du nicht allein im Feuer stehst)
Definiere vorab:
- Wer bewertet rechtlich? (DSB/Legal)
- Wer bewertet technisch? (IT‑Security)
- Wer entscheidet geschäftlich? (CISO/CIO/Management)
- Welche Belege werden gesammelt (Anordnung, Umfang, Datenkategorien, Zeitraum)?
- Wie wird dokumentiert (Incident‑Record, TIA‑Update, ggf. Behördenkommunikation)?
### Schritt 6: Monitoring statt Dauer‑Panik
Lege „Trigger“ fest, bei denen du die Bewertung neu aufrollst:
- Anbieter verliert DPF‑Status / ändert Subprocessor
- Neue Features (z. B. KI‑Module) ändern Datenflüsse
- Neue Länderzugriffe (Supportzentrum, Admin‑Team)
- Neue behördliche Leitlinien oder relevante Rechtsprechung
---
## 7) Mini‑Checkliste für Sabine (für den nächsten Lenkungskreis)
**In 30 Minuten vorzeigbar:**
- [ ] Datenflüsse + Zugriffspfade (inkl. Remote‑Access) sind skizziert
- [ ] DPF‑Check durchgeführt (ja/nein + Scope)
- [ ] Transferinstrument festgelegt (DPF oder SCC)
- [ ] TIA‑Entwurf mit Restrisiko‑Statement liegt vor
- [ ] Maßnahmenpaket (Tech + Org + Contract) abgestimmt oder als „To‑Do“ mit Owner terminiert
- [ ] Eskalations- und Monitoring‑Trigger definiert
---
## 8) Fazit: DPF hilft – ersetzt aber nicht deine „Hausaufgaben“
Der Angemessenheitsbeschluss (DPF) kann vieles vereinfachen. Die Pflichtenkollision verschwindet aber nicht automatisch, weil die **operative Realität** (Supportzugriffe, Telemetrie, Subprocessor, neue Features) weiter dynamisch bleibt.
Wenn du das Thema **standardisierst** – mit TIA‑Vorlagen, Maßnahmenpaketen und klarer Eskalation – wird aus einer Sisyphusarbeit ein wiederholbarer Prozess. Genau das entlastet dich und dein Team.
---
## Optionaler Call‑to‑Action (neutral formuliert)
Wenn du willst, kann ich dir auf Basis eurer Tool‑Landschaft eine **TIA‑Vorlage (Word)**, ein **SCC‑Anhang‑Set (TOM + Subprocessor‑Kontrolle)** und eine **1‑seitige Eskalationsmatrix** als „Ready‑to‑Use“-Paket strukturieren – so, dass IT/Einkauf damit sofort arbeiten können.
---
## Quellen / Referenzen (zitierfähig)
- EuGH, Urteil **C‑311/18 („Schrems II“) vom 16.07.2020**
- EU‑Kommission: Angemessenheitsbeschluss zum **EU‑US Data Privacy Framework**, **10.07.2023**
- EU‑Kommission: Beschluss (EU) **2021/914** (Standardvertragsklauseln), **04.06.2021**
- EDPB: **Empfehlungen 01/2020** zu Maßnahmen zur Ergänzung von Übermittlungsinstrumenten (final **2021**)
