Conflict of duties in data transfers to the USA: How to remain operational between the GDPR and US access powers
Digital projects now scale across cloud services, global support teams and international corporate structures – and this is precisely where a classic conflict of objectives arises: The GDPR requires an "essentially equivalent" level of protection for transfers to third countries, while certain US access regimes (e.g. under national security powers or production orders) can, in some circumstances, enable extensive access. This conflict of duties is not an academic issue – it determines whether your transformation proceeds quickly, cleanly and audit‑ready.
This article shows how to structure the subject pragmatically: without a marathon of expert opinions, but with an approach that holds up in board discussions, before the supervisory authority and in an incident.
1) What "conflict of duties" really means in practice
We speak of a conflict of duties when two requirements effectively collide:
- EU perspective (GDPR, Chapter V): Transfers to the USA are only permissible via an adequacy decision (Art. 45), appropriate safeguards such as SCCs (Art. 46) or narrowly defined derogations (Art. 49).
- US perspective: Under certain conditions, authority access or production orders against US providers or US‑connected entities can arise – sometimes accompanied by gag/ secrecy obligations.
Typical triggers where this suddenly becomes relevant:
- US cloud/SaaS services (even when "EU hosting" has been purchased)
- Remote support / admin access from the USA
- Corporate parent in the USA, central IT governance
- E‑Discovery and litigation holds in US proceedings
The key point: A third‑country transfer under the GDPR is not a routine processing step – it is an additional area for review and safeguards.
2) What Schrems II changed: SCCs are a starting point, not the end point
The CJEU with Schrems II (C‑311/18, 16.07.2020) struck down the previous EU‑US mechanism (Privacy Shield) and raised the bar clearly:
- Standard contractual clauses (SCCs) can in principle still be used.
- But: They only work if, in the concrete case, a level of protection is achieved that is essentially equivalent.
- If the third‑country law (e.g. US access powers) runs counter to that, supplementary measures are required – otherwise the transfer must be suspended.
Practical translation for your projects: "SCC signed" is not a go‑live criterion. Go‑live requires a robust risk assessment (TIA) plus a package of measures.
3) DPF (since 10.07.2023): Relief – but not a free pass
With the EU‑US Data Privacy Framework (DPF) there has been, since 2023, an adequacy decision again for transfers to DPF‑certified US companies. That can significantly reduce the effort.
Three practical questions determine whether the DPF really helps:
- Is the specific recipient (and the specific service) DPF‑certified? Not just "the group".
- How do onward transfers look? Subprocessors without DPF coverage quickly pull SCC/TIA back into scope.
- Do you need resilience? Adequacy decisions can come under political and judicial pressure – past iterations (Safe Harbor, Privacy Shield) show: an exit plan is not overengineering.
Best practice is therefore: use DPF where it fits – and at the same time build technical/organizational guardrails so that a switch (back to SCC + measures) does not cause a transformation halt.
4) Three common misconceptions that cost time and nerves in projects
Misconception 1: "We use SCCs, so everything is done."
SCCs without a TIA and without supplementary measures are often not sufficient after Schrems II – especially in scenarios with potential authority access.
Misconception 2: "EU hosting solves the problem."
Not necessarily. Remote access, admin rights, key management, support chains and US legal nexus can keep the transfer/access conflict alive.
Misconception 3: "DPF makes TIAs unnecessary."
DPF can facilitate transfers, but scope checks, subprocessors and special cases (e.g. e‑discovery) remain matters that need review and governance in practice.
5) An approach model that combines speed and legal certainty
If you want to make the topic manageable in a group, you need a standard process that is repeatable.
Step 1: Transfer mapping (without the full‑inventory trap)
Determine per use case:
- Data categories (including special categories?)
- Recipients & roles (controller/processor, subprocessors)
- Transfer paths (storage, support access, telemetry, backups)
Goal: A reliable "data‑flow sheet" per product/service – not a months‑long mega‑register.
Step 2: Determine the transfer mechanism
- DPF, if recipient/service is covered
- otherwise SCCs (appropriate module)
- Art. 49 only as an exception (not a permanent architecture)
Step 3: TIA (Transfer Impact Assessment) as a management briefing
A good TIA answers concisely and with decision‑making value:
- Which US access rules could be relevant?
- How likely is access in the concrete setup?
- Which groups of data subjects, what data criticality?
- Which safeguards reduce the residual risk to a sustainable level?
Step 4: Supplementary measures – the leverage is usually technical
From the EDPB logic (Recommendations 01/2020) technical measures are often most effective, in particular:
- Strong encryption with key control in the EU
- Client‑side encryption so the provider does not see plaintext
- Pseudonymization/tokenization (re‑identification remains in the EU)
- Zero‑trust access models, strict permissions, logging
Additionally:
- Contractually: challenge obligations on authority requests, transparency (as far as permissible), audit and subprocessor control
- Organizationally: government‑request playbook, escalation paths, training, minimization of US remote support
Step 5: Re‑assessment & "change triggers"
The matter is dynamic: new subprocessors, new features, new support channels. Define clear triggers for when the TIA must be updated.
6) When it gets serious: What to do in the event of a US production order?
Here paper compliance separates from operational control. A practical workflow:
- Request triage: formal validity, jurisdiction, scope
- Data minimization: only required data, filtering/redaction
- Legal challenge: consider narrowing/contesting
- Transparency: inform controllers/affected persons, as far as permissible
- Documentation: decision, balancing, legal basis, communications
- Follow‑up: adjust TIA/measures, if necessary stop the transfer
Important: These procedures must be in place beforehand (roles, responsibilities, decision thresholds). In a real case there is no time for fundamental discussions.
7) Mini‑checklist for your next 30 days
If you want quick clarity without launching a huge programme:
- [ ] For your top‑5 cloud/SaaS services: data flows + subprocessors consolidated?
- [ ] Per service clarified: DPF possible? (certification and scope) – otherwise SCCs
- [ ] For SCC transfers: TIA template defined and executed for the top use cases?
- [ ] Key management and encryption architecture designed so that "EU key control" is real?
- [ ] Government‑request playbook and escalation chain (Legal/DPO/IT/Security) defined?
- [ ] Exit options (provider switch, data portability, architecture fallback) anchored as part of vendor governance?
Conclusion: Conflict of duties is manageable – if you manage it like a product
The central management logic is: transfer compliance is not a one‑off legal artefact, but a repeatable process of mapping, mechanism selection, TIA, measures and change control.
If you set the topic up this way, you gain both: speed in projects and robustness against supervisory authorities, audits and incident situations.
Call‑to‑Action
If you like, I can produce a C‑level transfer briefing (2–3 pages) from this plus a TIA starter kit (template, evaluation logic, measures catalogue) for your most important US touchpoints (cloud, support, corporate access, e‑discovery) – so that business units can quickly reach a reliable "go/no‑go with conditions".
Disclaimer: This article is general information and does not replace legal advice in individual cases.
Sources (selection): CJEU, C‑311/18 ("Schrems II", 16.07.2020); EDPB Recommendations 01/2020 (Supplementary Measures, final 18.06.2021); European Commission, adequacy decision on the EU‑US Data Privacy Framework (10.07.2023).
Pflichtenkollision beim Datentransfer in die USA: So bleiben Sie handlungsfähig zwischen DSGVO und US‑Zugriffsbefugnissen
Digitale Projekte skalieren heute über Cloud, globale Support-Teams und internationale Konzernstrukturen – und genau dort entsteht ein klassischer Zielkonflikt: Die DSGVO verlangt für Drittlandtransfers ein „im Wesentlichen gleichwertiges“ Schutzniveau, während bestimmte US‑Zugriffsregime (z. B. im Rahmen nationaler Sicherheitsbefugnisse oder Herausgabeverlangen) unter Umständen weitreichende Zugriffe ermöglichen. Diese Pflichtenkollision ist kein akademisches Thema – sie entscheidet darüber, ob Ihre Transformation schnell, sauber und auditfest durchläuft.
Dieser Beitrag zeigt, wie Sie das Thema pragmatisch strukturieren: ohne Gutachten-Marathon, aber mit einem Vorgehen, das in Board‑Diskussionen, gegenüber Aufsicht und im Incident‑Fall trägt.
1) Was „Pflichtenkollision“ in der Praxis wirklich heißt
Von einer Pflichtenkollision sprechen wir, wenn sich zwei Anforderungen faktisch reiben:
- EU‑Perspektive (DSGVO, Kapitel V): Übermittlungen in die USA sind nur zulässig über Angemessenheitsbeschluss (Art. 45), geeignete Garantien wie SCC (Art. 46) oder eng begrenzte Ausnahmen (Art. 49).
- US‑Perspektive: Unter bestimmten Voraussetzungen können Behördenzugriffe oder Herausgabeverlangen gegenüber US‑Anbietern bzw. US‑verbundenen Unternehmen entstehen – teils mit Geheimhaltungspflichten.
Typische Trigger, bei denen das plötzlich relevant wird:
- US‑Cloud-/SaaS‑Dienste (auch wenn „EU‑Hosting“ gebucht ist)
- Remote‑Support / Admin‑Zugriffe aus den USA
- Konzernmutter in den USA, zentrale IT‑Governance
- E‑Discovery und Litigation Holds in US‑Verfahren
Der springende Punkt: Ein Drittlandtransfer ist nach DSGVO kein normaler Verarbeitungsschritt – er ist ein zusätzlicher Prüf- und Absicherungsbereich.
2) Was Schrems II verändert hat: SCC sind Startpunkt, nicht Endpunkt
Der EuGH hat mit Schrems II (C‑311/18, 16.07.2020) den früheren EU‑US‑Mechanismus (Privacy Shield) gekippt und die Messlatte klargezogen:
- Standardvertragsklauseln (SCC) können grundsätzlich weiter genutzt werden.
- Aber: Sie funktionieren nur, wenn im konkreten Fall ein Schutzniveau erreicht wird, das im Wesentlichen gleichwertig ist.
- Wenn das Drittlandsrecht (z. B. US‑Zugriffsbefugnisse) dem entgegensteht, braucht es zusätzliche Maßnahmen – sonst muss der Transfer ausgesetzt werden.
Praktische Übersetzung für Ihre Projekte: „SCC unterschrieben“ ist kein Go‑Live‑Kriterium. Go‑Live erfordert eine belastbare Risikobewertung (TIA) plus Maßnahmenpaket.
3) DPF (seit 10.07.2023): Entlastung – aber nicht der Freifahrtschein
Mit dem EU‑US Data Privacy Framework (DPF) gibt es seit 2023 wieder einen Angemessenheitsbeschluss für Transfers an DPF‑zertifizierte US‑Unternehmen. Das kann den Aufwand deutlich senken.
Drei Praxisfragen entscheiden, ob DPF wirklich hilft:
- Ist der konkrete Empfänger (und der konkrete Service) DPF‑zertifiziert? Nicht nur „der Konzern“.
- Wie sehen Weiterübermittlungen aus? Subprozessoren ohne DPF‑Abdeckung ziehen schnell wieder SCC/TIA nach sich.
- Brauchen Sie Resilienz? Angemessenheitsbeschlüsse können politisch und juristisch unter Druck geraten – die vergangenen Iterationen (Safe Harbor, Privacy Shield) zeigen: Ein Exit‑Plan ist kein Overengineering.
Best practice ist daher: DPF nutzen, wo es passt – und gleichzeitig technische/organisatorische Leitplanken bauen, damit ein Wechsel (zurück auf SCC + Maßnahmen) nicht zum Transformationsstopp führt.
4) Drei häufige Irrtümer, die in Projekten Zeit und Nerven kosten
Irrtum 1: „Wir nutzen SCC, damit ist alles erledigt.“
SCC ohne TIA und ohne Zusatzmaßnahmen sind nach Schrems II häufig nicht ausreichend – insbesondere bei Szenarien mit möglichem Behördenzugriff.
Irrtum 2: „EU‑Hosting löst das Problem.“
Nicht unbedingt. Remote‑Zugriff, Admin‑Rechte, Schlüsselmanagement, Support‑Ketten und US‑Rechtsbezug können den Transfer‑ bzw. Zugriffskonflikt fortbestehen lassen.
Irrtum 3: „DPF macht TIAs überflüssig.“
DPF kann Transfers erleichtern, aber Scope‑Prüfung, Subprozessoren und Sonderfälle (z. B. E‑Discovery) bleiben in der Praxis prüf- und steuerungsbedürftig.
5) Ein Vorgehensmodell, das Geschwindigkeit und Rechtssicherheit verbindet
Wenn Sie das Thema in einem Konzern handhabbar machen wollen, brauchen Sie einen Standardprozess, der wiederholbar ist.
Schritt 1: Transfer‑Mapping (ohne Vollinventur-Falle)
Ermitteln Sie pro Use Case:
- Datenkategorien (inkl. besonderer Kategorien?)
- Empfänger & Rollen (Controller/Processor, Subprozessoren)
- Transferwege (Speicherung, Support‑Zugriff, Telemetrie, Backups)
Ziel: Ein belastbares „Data‑Flow‑Sheet“ pro Produkt/Service – nicht ein monatelanges Mega‑Register.
Schritt 2: Transfermechanismus festlegen
- DPF, wenn Empfänger/Service abgedeckt
- sonst SCC (passendes Modul)
- Art. 49 nur als Ausnahme (keine Dauerarchitektur)
Schritt 3: TIA (Transfer Impact Assessment) als Management‑Briefing
Ein gutes TIA beantwortet knapp und entscheidungsfähig:
- Welche US‑Zugriffsnormen könnten relevant sein?
- Wie wahrscheinlich ist Zugriff im konkreten Setup?
- Welche Betroffenengruppen, welche Datenkritikalität?
- Welche Schutzmaßnahmen reduzieren das Restrisiko auf ein tragfähiges Niveau?
Schritt 4: Zusatzmaßnahmen – der Hebel liegt meist in der Technik
Aus der EDPB‑Logik (Recommendations 01/2020) sind technische Maßnahmen oft am wirksamsten, insbesondere:
- Starke Verschlüsselung mit Schlüsselhoheit in der EU
- Client‑seitige Verschlüsselung, sodass der Provider keine Klartexte sieht
- Pseudonymisierung/Tokenisierung (Re‑Identifizierung bleibt in der EU)
- Zero‑Trust‑Zugriffsmodelle, strikte Berechtigungen, Protokollierung
Ergänzend:
- Vertraglich: Challenge‑Pflichten bei Behördenanfragen, Transparenz (soweit zulässig), Audit‑ und Subprozessor‑Kontrolle
- Organisatorisch: Government‑Request‑Playbook, Eskalationswege, Schulung, Minimierung von US‑Remote‑Support
Schritt 5: Re‑Assessment & „Change Trigger“
Das Thema ist dynamisch: neue Subprozessoren, neue Features, neue Support‑Wege. Definieren Sie klare Trigger, wann das TIA aktualisiert wird.
6) Wenn es ernst wird: Was tun bei einem US‑Herausgabeverlangen?
Hier trennt sich Papier‑Compliance von operativer Steuerung. Ein praxistauglicher Ablauf:
- Request‑Triage: formelle Gültigkeit, Zuständigkeit, Umfang
- Datenminimierung: nur erforderliche Daten, Filter/Schwärzung
- Legal Challenge: Einengung/Anfechtung prüfen
- Transparenz: Information an Verantwortliche/Betroffene, soweit zulässig
- Dokumentation: Entscheidung, Abwägung, Rechtsgrundlage, Kommunikation
- Nachbereitung: TIA/Maßnahmen anpassen, ggf. Transfer stoppen
Wichtig: Diese Abläufe müssen vorher stehen (Rollen, Verantwortlichkeiten, Entscheidungsschwellen). Im Ernstfall gibt es keinen Raum für Grundsatzdiskussionen.
7) Mini‑Checkliste für Ihre nächsten 30 Tage
Wenn Sie schnell Klarheit wollen, ohne ein Riesenprogramm aufzusetzen:
- [ ] Für Ihre Top‑5 Cloud/SaaS‑Services: Data‑Flows + Subprozessoren konsolidiert?
- [ ] Pro Service geklärt: DPF möglich? (Zertifizierung und Scope) – sonst SCC
- [ ] Für SCC‑Transfers: TIA‑Template festgelegt und für die Top‑Use‑Cases durchgeführt?
- [ ] Schlüsselmanagement und Verschlüsselungsarchitektur so gestaltet, dass „EU‑Schlüsselhoheit“ real ist?
- [ ] Government‑Request‑Playbook und Eskalationskette (Legal/DSB/IT/Security) definiert?
- [ ] Exit‑Optionen (Provider‑Wechsel, Datenportabilität, Architektur‑Fallback) als Teil der Vendor‑Governance verankert?
Fazit: Pflichtenkollision ist steuerbar – wenn Sie sie wie ein Produkt managen
Die zentrale Management‑Logik lautet: Transfer‑Compliance ist kein einmaliges Legal‑Artefakt, sondern ein wiederholbarer Prozess aus Mapping, Mechanismuswahl, TIA, Maßnahmen und Change‑Kontrolle.
Wenn Sie das Thema so aufsetzen, gewinnen Sie beides: Tempo in Projekten und Robustheit gegenüber Aufsicht, Audit und Incident‑Situationen.
Call‑to‑Action
Wenn Sie möchten, erstelle ich daraus ein C‑Level‑fähiges Transfer‑Briefing (2–3 Seiten) plus ein TIA‑Starterpaket (Template, Bewertungslogik, Maßnahmenkatalog) für Ihre wichtigsten US‑Bezüge (Cloud, Support, Konzernzugriff, E‑Discovery) – so, dass Fachbereiche schnell zu einem belastbaren „Go/No‑Go mit Bedingungen“ kommen.
Disclaimer: Dieser Beitrag ist eine allgemeine Information und ersetzt keine Rechtsberatung im Einzelfall.
Quellen (Auswahl): EuGH, C‑311/18 („Schrems II“, 16.07.2020); EDPB Recommendations 01/2020 (Supplementary Measures, final 18.06.2021); Europäische Kommission, Angemessenheitsbeschluss zum EU‑US Data Privacy Framework (10.07.2023).
