„Unsere Daten liegen in Deutschland.“ – Reicht das?
Eine Compliance-Checkliste für alle, die SharePoint oder Atlassian einsetzen
Die meisten Unternehmen beantworten die Datenschutzfrage zu ihren Cloud-Tools mit einem Satz: „Unsere Daten liegen in einem Rechenzentrum in Frankfurt.“ Das klingt beruhigend. Es ist aber keine Antwort auf die Frage, die zählt.
Die richtige Frage lautet nicht: Wo liegen die Daten? Sondern: Wer kann gezwungen werden, sie herauszugeben — ohne dass Sie oder die Betroffenen davon erfahren?
Wer SharePoint (Microsoft 365), Jira oder Confluence (Atlassian) einsetzt, betreibt produktiv US-Software. Beide Anbieter haben in den letzten Jahren erheblich nachgebessert. Beide lassen sich heute datenschutzkonform betreiben. Aber „konform“ ist kein Zustand, der sich von selbst einstellt — es ist das Ergebnis aus Vertrag, Konfiguration, Dokumentation und einer ehrlichen Risikoabwägung. Dieser Beitrag zeigt, was dafür konkret zu tun ist.
Warum der Server-Standort nur eine von drei Ebenen ist
Drei Dinge entscheiden über die datenschutzrechtliche Sauberkeit eines Cloud-Dienstes:
- Der physische Speicherort der Daten (Server-Region).
- Die juristische Eigentumsstruktur des Anbieters (welchem Recht unterliegt er?).
- Die Sub-Auftragsverarbeiter (an wen reicht der Anbieter Daten weiter?).
Die deutsche Datenresidenz von Atlassian und die EU Data Boundary von Microsoft adressieren ausschließlich Ebene 1. Ebene 2 bleibt unberührt: Microsoft und Atlassian sind US-Gesellschaften.
Und damit greift der US CLOUD Act (18 U.S.C. § 2713): Ein US-Unternehmen muss Daten, die seiner Kontrolle unterliegen, auf rechtmäßige Anordnung US-amerikanischer Behörden herausgeben — unabhängig davon, wo die Server stehen. Der EuGH hat in Schrems II (2020) genau deshalb festgestellt, dass die USA kein der EU gleichwertiges Schutzniveau bieten: US-Geheimdienste können nach FISA Section 702 ohne richterliche Einzelanordnung auf Daten zugreifen, und Betroffene haben kaum wirksamen Rechtsschutz.
Das ist kein theoretisches Risiko. Im Juni 2025 wurde der Justiziar von Microsoft Frankreich im französischen Senat gefragt, ob er garantieren könne, dass Daten europäischer Bürger nicht an US-Behörden gelangen. Seine Antwort: „Non, je ne peux pas le garantir.“ Microsoft selbst bestätigt unter Eid: Bei einer formell korrekten CLOUD-Act-Anordnung gibt es kein Verweigerungsrecht.
Konsequenz: Der CLOUD-Act-Restrisiko lässt sich durch Konfiguration mindern, aber nicht eliminieren. Vollständig aus der Gleichung nehmen kann man ihn nur durch einen Verantwortlichen außerhalb der US-Jurisdiktion. Alles andere ist Risikomanagement — und genau das verlangt die DSGVO von Ihnen.
Wie sicher ist die Rechtsgrundlage gerade?
Der Transfer in die USA stützt sich auf zwei Mechanismen:
- EU-US Data Privacy Framework (DPF): Angemessenheitsbeschluss seit Juli 2023. Das Gericht der EU hat ihn am 3. September 2025 in der Sache Latombe (T-553/23) bestätigt. Aber: Es läuft ein Rechtsmittel zum EuGH (C-703/25 P), und der politische Unterbau (US-Executive-Order 14086, Kontrollgremium PCLOB) ist fragil. Ein „Schrems III“ ist nicht ausgeschlossen.
- Standardvertragsklauseln (SCC): Die robustere Rückfalloption. Greifen auch dann, wenn das DPF fallen sollte.
Pragmatischer Standard 2026: Beide Mechanismen parallel halten — DPF als Grundlage, SCC als Fallback. Wer sich allein auf das DPF stützt, steht bei einem EuGH-Urteil über Nacht ohne Transfergrundlage da.
Die Checkliste: Was Sie konkret tun müssen
Drucken Sie das aus. Jeder Punkt, der nicht abgehakt ist, ist eine offene Flanke.
A — Vertrag
- Auftragsverarbeitungsvertrag (AVV/DPA) abgeschlossen und auf Ihre konkreten Dienste, Datenkategorien und Vertragstyp geprüft. (Bei Microsoft über die Produktbedingungen + Datenschutzaddendum, bei Atlassian über das Data Processing Addendum.)
- Standardvertragsklauseln (SCC) als Bestandteil des AVV verifiziert und gegengezeichnet.
- DPF-Zertifizierung des Anbieters auf
dataprivacyframework.govgeprüft — inklusive der Frage, ob die für Sie relevante Datenkategorie abgedeckt ist.
B — Technik & Konfiguration
- Datenresidenz / EU Data Boundary aktiviert und der Vollzug dokumentiert (nicht nur „eingestellt“ — auch nachgewiesen, dass die Migration abgeschlossen ist).
- Geprüft, welche Daten trotzdem die EU verlassen: Telemetrie, Diagnose-, Analyse- und bestimmte globale Dienste fallen oft nicht unter die Residency. Diese Ausnahmen kennen und benennen.
- Multi-Geo / Sonderfunktionen geprüft: Microsoft-365-Mandanten mit Multi-Geo fallen nicht unter die EU Data Boundary.
- KI-Funktionen separat bewertet: Microsoft 365 Copilot nutzt seit 2026 „Flex Routing“ (Verarbeitung außerhalb der EU bei Lastspitzen möglich) — abschaltbar im Admin Center, aber bewusst zu entscheiden und zu dokumentieren.
- Verschlüsselung at rest und in transit aktiv; wo verfügbar, eigene Schlüssel (BYOK / Customer Key) in Betracht gezogen.
C — Organisation & Mitbestimmung
- Rechtsgrundlage nach Art. 6 DSGVO festgelegt (betrieblich meist lit. b oder lit. f).
- Datenschutz-Folgenabschätzung (DSFA) durchgeführt, wo umfangreiche oder eingriffsintensive Verarbeitung stattfindet — insbesondere bei Beschäftigtendaten.
- Transfer Impact Assessment (TIA) je Datenkategorie: Reicht das Schutzniveau im konkreten Fall trotz CLOUD Act? (Schrems II verlangt diese Einzelfallprüfung zusätzlich zum DPF.)
- Betriebsvereinbarung mit dem Betriebsrat vor dem Einsatz von Monitoring-Funktionen (Teams-Monitoring, Viva Insights, Jira-Aktivitätslogs). § 87 Abs. 1 Nr. 6 BetrVG ist nicht verhandelbar, wenn die Systeme zur Verhaltens- oder Leistungskontrolle geeignet sind — und das sind sie.
D — Dokumentation & Betroffenenrechte
- Sub-Auftragsverarbeiter-Liste abonniert (RSS-Feed beider Anbieter) und Änderungen werden tatsächlich ausgewertet.
- Datenschutzhinweise angepasst: Transfer in die USA, Rechtsgrundlage und Restrisiko gegenüber Betroffenen offengelegt.
- Lösch- und Export-Prozesse etabliert (Recht auf Löschung / Datenportabilität nach Art. 17 / Art. 20 DSGVO).
- Aufbewahrungsfristen (Retention Policies) konfiguriert — unnötiger Datenbestand ist vermeidbares Risiko.
- Rechenschaftsdokumentation (Art. 5 Abs. 2 DSGVO): Sie können jederzeit darlegen, was Sie warum und wie entschieden haben. Diese Mappe ist im Prüfungsfall Ihr wichtigstes Asset.
Sind sie also konform?
Die ehrliche Antwort: Ja — aber nur konditional, und nie automatisch.
Die deutschen Aufsichtsbehörden haben den Weg geebnet. Die LfD Niedersachsen hat 2025 bestätigt, dass private Unternehmen Microsoft 365 datenschutzkonform betreiben können; der Hessische Datenschutzbeauftragte ist 2026 nachgezogen. Für Atlassian gilt mit AVV, SCC und EU-Residency dieselbe Logik. Konformität ist erreichbar.
Was Sie aber nicht wegkonfigurieren können, ist die letzte Zeile auf Ebene 2: Solange der Verantwortliche ein US-Unternehmen ist, bleibt ein Restrisiko, das weder technisch noch vertraglich vollständig verschwindet. Die DSGVO verlangt nicht, dass dieses Risiko null ist — sie verlangt, dass Sie es kennen, bewerten und dokumentieren. Wer die Checkliste oben abarbeitet, tut genau das. Wer sich auf „liegt ja in Frankfurt“ verlässt, hat im Zweifel gar keine Risikoabwägung — und das ist der eigentliche Verstoß.
Die saubere Alternative — wenn Sie sie brauchen
Für die meisten Workloads ist der dokumentierte Betrieb von SharePoint oder Atlassian vertretbar. Für besonders sensible Daten — Beschäftigtendaten in der Tiefe, regulierte Branchen, Geschäftsgeheimnisse mit hoher Eingriffsintensität — kann die richtige Antwort ein Wechsel zu einem Verantwortlichen außerhalb der US-Jurisdiktion sein: self-hosted auf EU-Infrastruktur oder EU-native Werkzeuge. Damit verschwindet die zweite Ebene aus dem Risikobild.
Die Faustregel bleibt dieselbe wie am Anfang: Fragen Sie nicht, wo die Daten liegen. Fragen Sie, wer sie herausgeben muss, wenn es darauf ankommt. Und ob Sie darauf eine dokumentierte Antwort haben.
Schon mal drüber nachgedacht?
Dieser Beitrag ist eine fachliche Einordnung, keine Rechtsberatung. Für die verbindliche Bewertung Ihres konkreten Setups ziehen Sie Ihren Datenschutzbeauftragten oder eine spezialisierte Kanzlei hinzu.