Jira Service Management EU Alternative 2026: Atlassian Delaware-ITSM unter US-Jurisdiktion

Post #1215 in der sota.io EU Cyber Compliance Series

Jira Service Management (JSM) ist die ITSM-Plattform von Atlassian — 2021 umbenannt von "Jira Service Desk" — und verwaltet Helpdesk-Tickets, Incidents, Change Requests und Employee Service Requests in Millionen von Unternehmen weltweit. Was viele EU-IT-Teams nicht auf dem Radar haben: Atlassian hat im Juni 2022 seinen Unternehmenssitz von einer britischen Public Limited Company (Atlassian Corporation Plc) in eine US-amerikanische C-Corporation nach Delaware verlegt und ist seitdem als "Atlassian Corporation" (NASDAQ: TEAM) an der US-Börse gelistet.

Diese Redomizilierung hat weitreichende Konsequenzen für den CLOUD Act-Status: Atlassian ist nicht länger ein australisch-britisches Unternehmen mit US-Börsennotiz, sondern eine vollständige US Delaware Corporation — mit allen CLOUD Act-Pflichten, die das impliziert. ITSM-Daten in Jira Service Management fallen damit unter US-Bundesjurisdiktion, unabhängig davon, ob EU-Datenresidenz gewählt wird.

Dieser Post analysiert das CLOUD Act-Risiko von Atlassian JSM (18/25) und zeigt EU-native ITSM-Alternativen, die Incident-Management und Service-Desk-Workflows ohne US-Jurisdiktionsrisiko abbilden können.

Atlassian Corporation — CLOUD Act Risiko: 18/25

Unternehmensstruktur nach Redomizilierung 2022

Warum die 2022 Redomizilierung CLOUD Act-kritisch ist

Vor der Redomizilierung konnte Atlassian argumentieren, dass die operative Muttergesellschaft eine australische Pty Ltd war — mit US-Börsennotiz, aber nicht zwingend einem US-Unternehmen. Seit Juni 2022 gibt es dieses Argument nicht mehr:

Atlassian Corporation (Delaware) ist die rechtliche Muttergesellschaft aller Atlassian-Produkte, einschließlich Jira Service Management. US-Bundesbehörden können Legal-Process direkt an Atlassian Corporation richten, ohne den Umweg über MLATs (Mutual Legal Assistance Treaties) oder australische Gerichte. Die australische Atlassian Pty Ltd ist jetzt eine Tochtergesellschaft einer US-Delaware-Corp.

CLOUD Act Analyse 18/25

CLOUD Act Score: 18/25 — Erhöhtes Risiko für EU-ITSM-Daten

Zum Vergleich innerhalb der EU-ITSM-Serie:

• ServiceNow #1213: 19/25 (FedRAMP High, DoD IL5, IC ATO)
• Jira Service Management #1215: 18/25 (FedRAMP Moderate, Atlassian Intelligence)
• BMC Helix #1214: 17/25 (Private/KKR, FedRAMP High, keine PRISM-Bestätigung)

Fünf GDPR-kritische Risiken bei Jira Service Management

Risiko 1: Atlassian Intelligence — KI auf AWS Bedrock verarbeitet alle Ticketdaten

Problem: Atlassian Intelligence ist die seit 2023 ausgerollte KI-Funktion, die in Jira Service Management tief integriert ist:

• Ticket-Summarization: JSM fasst Incident-Beschreibungen automatisch zusammen
• Similar Incidents: KI sucht in historischen Tickets nach ähnlichen Vorfällen
• Virtual Service Agent: KI-Chatbot beantwortet Self-Service-Anfragen aus Ticketdaten
• Suggested Responders: KI empfiehlt Bearbeiter basierend auf historischen Zuweisungen
• Auto-Fill: KI füllt Felder aus bestehenden Ticketdaten automatisch aus

CLOUD Act-Problem: Atlassian Intelligence wird auf AWS Bedrock (Amazon Titan, Claude API) ausgeführt — US-Cloud-Infrastruktur. Alle Ticketdaten, die KI-Features nutzen, werden durch US-Infrastruktur verarbeitet:

1. Ticket-PII (Endnutzer-Name, Email, Abteilung, Standort)
2. Incident-Beschreibungen (können Sicherheits-Schwachstellen, interne Systemnamen enthalten)
3. Employee-Service-Requests (HR-Daten, IT-Zugangsanfragen)
4. Change-Records (Systemkonfigurationen, Infrastruktur-Details)

GDPR Art.22(1) verbietet vollständig automatisierte Entscheidungen mit rechtlicher Wirkung. Die "Suggested Responders"-Funktion kann als automatisierte Entscheidung im Sinne von Art.22 qualifiziert werden — ohne explizite DPIA und technische Garantien.

NIS2-Relevanz: NIS2 Art.21(2)(e) ("Sicherheit in der Lieferkette") umfasst AI-Infrastruktur als Sub-Processor. Atlassian Intelligence auf AWS Bedrock ist ein weiterer US-Anbieter in der Sub-Processor-Kette.

Risiko 2: JSM Cloud auf AWS — US Sub-Processor auch in EU-Regionen

Problem: Jira Service Management Cloud läuft auf Amazon Web Services. Atlassian bietet Datenresidenz in der EU (Ireland, Frankfurt) — aber der Sub-Processor ist immer noch Amazon Web Services, Inc. (Wilmington, Delaware, USA).

Sub-Processor-Kette:

EU-Organisation
  → Atlassian Corporation (Delaware)           ← CLOUD Act-pflichtig
    → Amazon Web Services, Inc. (Delaware)     ← CLOUD Act-pflichtig
      → AWS eu-west-1 (Dublin, Ireland)        ← physischer Speicher

Selbst wenn Daten physisch in EU-Rechenzentren gespeichert sind: Der Data Controller (Atlassian) und der Infrastruktur-Sub-Processor (AWS Inc.) sind beide US Delaware Corporations. US-Behörden können über CLOUD Act auf Daten zugreifen, ohne auf europäische Datenschutzbehörden angewiesen zu sein.

EuGH C-311/18 (Schrems II, Rn. 126): "Standardvertragsklauseln können keine Beschränkungen auferlegen, die in den nationalen Rechtsordnungen der Drittländer nicht bestehen." — SCCs schließen CLOUD Act-Zugriff nicht aus.

Atlassian Data Residency: Atlassian bietet "Data Residency" als Premium-Feature an (€/Monat-Aufschlag). Diese Funktion garantiert, dass Kernanwendungsdaten in EU-Regionen gespeichert werden. Wichtige Ausnahmen laut Atlassian-Dokumentation:

• Atlassian Intelligence: Nicht von Data Residency abgedeckt (läuft auf US-Bedrock)
• Atlassian Marketplace Apps: Drittanbieter-Apps oft ohne Data Residency
• Log-Daten: Operational Logs können außerhalb der Residency-Region gespeichert werden
• Atlassian Support-Zugriff: Support-Mitarbeiter können auf Daten zugreifen (US-basiertes Support-Personal)

Risiko 3: Employee Service Requests — HR-Daten und GDPR Art.9-Sonderkategorien

Problem: Jira Service Management wird häufig für Employee Service Requests genutzt:

• IT-Zugangsverwaltung (Onboarding/Offboarding)
• HR-Anfragen (Gehaltsabrechnungen, Urlaubsanträge, Krankmeldungen)
• Facility-Management (Homeoffice-Equipment, Umzüge)
• Datenschutz-Anfragen (DSAR — Data Subject Access Requests)

GDPR-Problem: HR-Kategorien in JSM-Tickets können GDPR Art.9-Sonderkategorien enthalten:

Bei Übermittlung dieser Daten an Atlassian (US-Corp.) greift GDPR Art.49(1) — Ausnahmen für bestimmte Situationen. Ohne explizite Einwilligung der betroffenen Person ist die Übermittlung von Art.9-Daten an US-Dienstleister rechtlich heikel.

Risiko 4: Atlassian Marketplace Apps — Unkontrollierte Datenflüsse

Problem: Das Atlassian Marketplace hat über 5.000 Apps für Jira Service Management. Viele EU-Organisationen nutzen Marketplace-Apps für:

• ITSM-Erweiterungen (Advanced Reporting, SLA-Management)
• Integration mit Monitoring-Tools (PagerDuty US, OpsGenie Atlassian US)
• AI-Add-ons (AI-basierte Ticket-Klassifizierung von Drittanbietern)
• ServiceNow-Migration-Tools
• Customer Satisfaction Surveys

CLOUD Act-Problem: Jede Marketplace-App ist ein eigener Datenverarbeiter. Laut GDPR Art.28 muss die Organisation für jeden Sub-Processor einen DPA abschließen. Die Atlassian Marketplace App Policy erlaubt es Drittanbietern, eigene Sub-Processor-Ketten aufzubauen — ohne dass die Endorganisation immer vollständige Transparenz hat.

Konkrete Gefahr: Eine US-basierte Marketplace-App, die Ticket-Zusammenfassungen generiert, schafft eine weitere CLOUD Act-pflichtige Stelle in der Verarbeitungskette.

DORA Art.28(2): Kritische IKT-Drittdienstleister müssen vertraglich auditierbar sein. Atlassian Marketplace Apps erfüllen diese Auditierbarkeit oft nicht.

Risiko 5: OpsGenie-Integration — US-Bereitschafts- und Incident-Daten

Problem: Atlassian hat 2018 OpsGenie (Istanbul/San Francisco, USA) für $295 Mio. akquiriert. OpsGenie ist tief in Jira Service Management integriert — für Alerting, On-Call-Schedules und Major Incident Management.

Datentypen in OpsGenie:

• On-Call-Schedules (Mitarbeitername, Telefonnummer, Schichtpläne)
• Incident-Alerts (mit Systemnamen, IP-Adressen, Fehlercodes)
• Eskalationspfade (Organigramm-Daten, Verantwortlichkeiten)
• SMS/Push/Telefon-Benachrichtigungen (erfordern Mobilnummern unter US-Jurisdiction)

OpsGenie wird als SaaS auf AWS us-east-1 betrieben. Obwohl es EU-Kunden gibt, läuft der primäre OpsGenie-Dienst auf US-Infrastruktur. Mitarbeiternummern und Bereitschaftspläne in einer US-Cloud sind ein klares GDPR Art.6(1)(f)-Problem (berechtigtes Interesse reicht nicht für US-Cloud-Übermittlung aus).

NIS2 Art.21 und DORA Art.17 — ITSM-Compliance-Mapping

NIS2 Anforderungen für ITSM-Systeme

DORA Anforderungen für Finanzinstitute mit JSM

DORA Art.17(3) verlangt, dass Finanzunternehmen einen "ICT-related incident management process" implementieren, der "dokumentierte Klassifizierungs- und Eskalationsverfahren" enthält. JSM ist ein verbreitetes Incident-Management-Tool in Finanzinstituten.

DORA Art.28(2): "Finanzunternehmen [...] können kritische oder wichtige Funktionen nur an IKT-Drittdienstleister auslagern, wenn [...] die Dienstleistungsvereinbarungen angemessene Leistungsstandards enthalten."

Atlassian ist für viele Finanzinstitute ein IKT-Drittdienstleister im Sinne von DORA. Die Kombination aus CLOUD Act-Exposition und Marketplace-App-Komplexität macht es schwierig, DORA-konforme Auditsicherheit herzustellen.

EU-native Alternativen zu Jira Service Management

OTRS / ((OTRS)) — Zülpich, Deutschland (0/25 CLOUD Act)

((OTRS)) Community Edition ist die kostenlose, quelloffene Version — ideal für EU-Organisationen, die eine vollständig kontrollierbare ITSM-Plattform benötigen. OTRS Business Solution bietet ITIL-zertifizierte Module für Enterprise-Anforderungen.

Stärken gegenüber JSM: Vollständige Datensouveränität (On-Premise möglich), keine US-Sub-Processor, GDPR-nativ aus Deutschland, kein Atlassian-Intelligence-Equivalent das Daten nach US exfiltriert.

Zammad GmbH — Berlin, Deutschland (0/25 CLOUD Act)

Zammad ist stärker im Customer-Support-Bereich als im Enterprise-ITSM. Für Organisationen, die primär Helpdesk und Tier-1-Support benötigen (ohne komplexes Change-Management), ist Zammad eine solide, rein deutsche Alternative.

iTop — Combodo SAS, Belgien (0/25 CLOUD Act)

iTop ist besonders stark im Configuration Management Database (CMDB) Bereich — eine Stärke gegenüber Zammad, das kein CMDB hat. Für Organisationen mit komplexem IT-Asset-Management eine gute Wahl.

GLPI — Teclib' SAS, Frankreich (1/25 CLOUD Act)

GLPI ist eines der beliebtesten Open-Source ITSM-Tools in Europa, besonders in öffentlichen Einrichtungen (Schulen, Universitäten, Behörden) in Frankreich, Spanien und anderen EU-Ländern.

Znuny GmbH — Berlin, Deutschland (0/25 CLOUD Act)

Znuny ist ein aktiver Fork von OTRS Community Edition, der von den Kernentwicklern nach der Kommerzialisierung von OTRS gegründet wurde. Ideal für Organisationen, die OTRS kennen und einen vollständig community-getriebenen Nachfolger suchen.

CLOUD Act Vergleichstabelle — EU-ITSM-SERIE (Posts #1213-#1215)

Fünf-Schritte Migration von JSM zu EU-nativer ITSM-Plattform

Schritt 1: Datenmapping und DPIA (Woche 1-2)

Erstelle ein vollständiges Inventar der in JSM verarbeiteten Personendaten:

JSM-Datenkategorien:
├── Ticket-Daten
│   ├── Requester: Name, Email, Abteilung, Telefon
│   ├── Assignee: Name, Email, Arbeitszeiten
│   ├── Incident-Beschreibung: freier Text (PII möglich)
│   └── Anhänge: Screenshots, Logs (ggf. Passwörter, IPs)
├── Employee-Service-Requests
│   ├── HR-Kategorien (GDPR Art.9-Risiko prüfen!)
│   └── IT-Zugangsdaten (Benutzerkonten, Berechtigungen)
├── CMDB/Assets
│   ├── IT-Inventar (Systemnamen, IPs, Konfigurationen)
│   └── Software-Lizenzen
└── OpsGenie-Integration
    ├── On-Call-Pläne (Mitarbeiterdaten)
    └── Mobilnummern (besonders sensibel)

Schritt 2: Atlassian Data Export (Woche 2-3)

JSM bietet einen Datenexport via Atlassian Admin Console:

• Ticket-Export: CSV/XML-Export aus Jira Service Management
• Confluence-Wissensbasis: Separate Export-Funktion in Confluence
• OpsGenie-Daten: OpsGenie hat eigenen Export (Alert-Historie, On-Call-Daten)
• Marketplace-App-Daten: Separat von jedem App-Anbieter anfordern (DSAR-Prozess)

Wichtig: Marketplace-App-Daten sind nicht im Atlassian-Standard-Export enthalten. Du musst aktiv DSARs bei allen genutzten Marketplace-App-Anbietern stellen.

Schritt 3: OTRS/Zammad Import (Woche 3-6)

OTRS bietet Import-Scripts für gängige Formate:

# OTRS Import aus CSV (Beispiel)
otrs.Console.pl Maint::Ticket::Import::CSV \
  --file /path/to/jira-export.csv \
  --mapping jira-to-otrs-fieldmap.yml

Zammad bietet ähnliche Import-Mechanismen für Zendesk, Freshdesk — JSM-spezifische Importer existieren als Community-Plugins.

Schritt 4: Atlassian Intelligence deaktivieren (Sofortmaßnahme)

Während der Migration (als Sofortmaßnahme für Datenschutz):

1. Atlassian Admin Console → Products → Atlassian Intelligence → Disable
2. Virtual Service Agent deaktivieren (Tickets fließen dann nicht mehr in US-KI)
3. Similar Incidents AI deaktivieren in JSM-Settings
4. Data Residency aktivieren (Notfall-Maßnahme bis Migration abgeschlossen)

Diese Maßnahmen reduzieren das CLOUD Act-Risiko während der Übergangsphase.

Schritt 5: Atlassian-Vertrag kündigen und Daten löschen (Woche 8-12)

Nach vollständiger Migration:

1. Atlassian-Account-Daten löschen via Atlassian Admin Console → Site deletion
2. OpsGenie-Account separat kündigen und Daten anfordern
3. Atlassian Marketplace — DPA-Kündigung mit allen App-Anbietern
4. Löschnachweis anfordern (für GDPR Art.17 Dokumentation)
5. DPO-Dokumentation: Löschung in den GDPR-Records (Art.30 Verarbeitungsverzeichnis)

Empfehlung

Jira Service Management ist nach der 2022-Redomizilierung nach Delaware und der Integration von Atlassian Intelligence in eine vollständige US-Delaware-Corporation mit CLOUD Act Score 18/25 übergegangen. Für EU-Organisationen mit NIS2-Pflichten (ab 250 MA oder kritische Infrastruktur) oder DORA-Regulierung (Finanzsektor) stellt JSM Cloud ein messbares Compliance-Risiko dar — insbesondere durch Atlassian Intelligence (AWS Bedrock), OpsGenie (US-Infrastruktur) und die unkontrollierte Datenflüsse durch Marketplace-Apps.

OTRS AG (Zülpich, Deutschland, 0/25) bietet die stärkste Enterprise-ITSM-Alternative mit ITIL v4-Zertifizierung und On-Premise-Deployment-Option. Zammad ist ideal für Helpdesk-fokussierte Anwendungsfälle mit einfacherer Migration. iTop/Combodo (Belgien, 0/25) empfiehlt sich wenn CMDB-Funktionalität kritisch ist.

Wer JSM Data Center (On-Premise) nutzt, hat weiterhin mehr Datenkontrolle — aber Atlassian (Delaware) bleibt dennoch der Vertragspartner, und Support-Zugriff durch US-Personal bleibt ein Restrisiko.

Analyse basiert auf öffentlich verfügbaren Informationen: Atlassian SEC-Filings (TEAM, 10-K 2023/2024), Atlassian Trust Center, FedRAMP Marketplace, Tech Transparency Project. Kein Rechtsrat — bitte konsultiere einen auf EU-Datenschutzrecht spezialisierten Anwalt für deine spezifische Situation.

Teil der sota.io EU-ITSM-SERIE: ServiceNow #1213 | BMC Helix #1214 | Jira Service Management #1215 | Freshservice #1216 | EU ITSM Comparison Finale #1217