DSGVO, Schrems II und Atlassian Cloud — ein praxisnaher Leitfaden für Teams

EU-Organisationen mit Jira und Confluence müssen AVV, Drittlandübermittlungen, Residency und App-Architektur zusammenführen. Dieser Artikel erläutert die Bausteine — keine Rechtsberatung.

Hinweis. Dieser Artikel ist eine allgemeine Information für IT- und Compliance-Teams, keine Rechtsberatung. Rechtsprechung, Behördenleitlinien und Anbieterunterlagen ändern sich — bindet eure Datenschutzbeauftragten und Juristen ein.

Warum das nach Schrems II relevant ist

Das Urteil Schrems II (EuGH, 2020) erklärte das EU-US-Privacy-Shield für ungültig. Unternehmen müssen prüfen, ob US-Überwachungsrecht und staatlicher Zugriff ein unvertretbares Risiko für personenbezogene Daten darstellen, wenn US-Anbieter oder Standorte ins Spiel kommen, und ob ergänzende Maßnahmen (EDPB-Empfehlungen) ausreichen. Atlassian stellt Unterlagen zu Übermittlungen, SCCs und Garantien bereit — das ist Input für eure Transfer-Folgenabschätzung (TIA), kein Ersatz für die eigene Dokumentation.

Rollen: Verantwortlicher vs. Auftragsverarbeiter

In der Regel ist euer Unternehmen Verantwortlicher für personenbezogene Daten in Jira/Confluence (Mitarbeitende, Kunden, Vorgänge). Atlassian agiert bei Atlassian Cloud typischerweise als Auftragsverarbeiter nach Art. 28 DSGVO. Marketplace-Anbieter sind je nach Architektur Sub-Auftragsverarbeiter (Forge/Connect) oder eigene Verantwortliche — jeweilige AVV-Anlagen und Privacy Policies lesen.

Datenresidenz

Atlassian bietet Data Residency für bestimmte Produkte/Regionen. Residenz adressiert u. a. Daten at rest, löst aber nicht automatisch Themen wie Support-Zugriff, Subprozessoren oder Backups in anderen Regionen. In der Admin-Dokumentation prüfen, welche Datenklassen abgedeckt sind.

Auftragsverarbeitungsvertrag (AVV)

Atlassian-AVV herunterladen und in eure Verzeichnisse von Verarbeitungstätigkeiten (Art. 30 DSGVO) einbinden. Verarbeitungszwecke (Ticketing, HR, Kundenprojekte) den Rechtsgrundlagen (Art. 6 DSGVO) zuordnen und Löschfristen dokumentieren. Der AVV regelt Pflichten des Auftragsverarbeiters — die Verantwortung für Rechtmäßigkeit, Transparenz und Betroffenenrechte bleibt bei euch.

Drittlandübermittlungen

Verlassen Daten den EWR, braucht ihr ein Kapitel-V-Mechanismus (z. B. SCC) und ggf. eine TIA plus ergänzende technische/organisatorische Maßnahmen. Atlassians Trust-Material ist in eure TIA-Narrative einzubetten und bei Änderungen zu aktualisieren.

Marketplace-Apps — typische Stolperstellen

Risiken entstehen oft durch Apps, die Issue-Daten nach extern spiegeln, Tracking-Pixel nutzen oder Nutzer-Code außerhalb der Atlassian-Infrastruktur ausführen. Jede Variante kann neue Übermittlungen oder eigene Verarbeitungsbeziehungen eröffnen. Bevorzugt Apps, deren Datenpfad klar in der Atlassian-kontrollierten Plattform bleibt und deren Privacy Policy Subprozessoren und Zwecke transparent benennt.

Technische Einordnung MOY= Apps

Unsere öffentliche Marketing-Website verarbeitet keine Inhalte aus eurer Jira-/Confluence-Instanz. Unsere Forge-basierten Apps sind darauf ausgelegt, innerhalb der von Atlassian beschriebenen Plattformgrenzen zu laufen; wir betreiben für den App-Laufzeitdatenpfad kein separates Datenlager außerhalb von Atlassian, wie in Marketplace-Listings und Privacy-Hinweisen beschrieben. Eure Organisation muss dennoch eigene DSFA/TIA führen, weil Instanzkonfiguration, Felder und Integrationen individuell sind.

Checkliste fürs Verarbeitungsverzeichnis

Produkt/URL, Zwecke, Personengruppen und Datenkategorien.
Rechtsgrundlagen und Löschfristen je Kategorie.
Sub-Auftragsverarbeiter: Atlassian, Marketplace-Anbieter, Support-Tools, Website-Analytics.
Übermittlungsmechanismen und TIAs wo nötig.
Verfahren für Auskunft, Löschung, Datenportabilität und Meldung von Vorfällen.

Weiterführend (offiziell / maßgeblich)

Atlassian Trust & Security und AVV-Downloads (trust.atlassian.com).
EDPB-Empfehlungen zu ergänzenden Maßnahmen (nach Schrems II).
Leitlinien eurer Landesdatenschutzbehörde zu Cloud und Arbeitgeberüberwachung.