# Eure Auditoren ziehen mit in die Cloud.

> Klassifizierung, Data-Security-Policies und Detection: Wie ihr die Auditoren-Fragen aus Data Center in der Atlassian Cloud mit Guard Premium beantwortet.

Source: https://www.xalt.de/atlassian-guard-premium-compliance/

In Data Center habt ihr eure eigene Datensegregation gebaut: ein Dropdown auf jeder Seite, klassifiziert, zurückgemeldet an die Auditoren. In der Cloud müssen dieselben Fragen ab Tag eins beantwortet sein – mit Guard Premium statt Eigenbau.

[Compliance-Roadmap anfordern](https://www.xalt.de/kontakt/)

## Compliance bremst Migrationen – deshalb fangen wir dort an.

Dutzende Instanzen über Konzerngesellschaften hinweg, jede mit eigenen Admins und eigenen Regeln. Die technische Migration ist lösbar; die Auditoren zu überzeugen ist der schwierige Teil.

### Eigenbau-Segregation reist nicht mit

Das Data-Center-Dropdown, das jede Seite klassifiziert hat, und die Auswertung dahinter müssen auf Plattform-Fähigkeiten neu entstehen, nicht als Plugin-Code.

### Niemand weiß, wo die Daten liegen

Sensible Inhalte liegen selten sauber im dafür vorgesehenen Projekt. Sie sind überall – und genau das fragt der Auditor zuerst.

### Viele Admins, ein Standard

Ein Dutzend Jira-Admins, jeder macht es ein bisschen anders. Irgendwer öffnet anonymen Zugriff, um ein Ticket zu teilen – und die Frage wird, wer wirklich die Kontrolle hat.

## Labels allein tun nichts. Verheiratet mit Policies, tun sie alles.

Eine Klassifizierung ist ein Name und eine Farbe. Den Wert liefern Data-Security-Policies, die darauf reagieren – zentral gesteuert und außerhalb der Reichweite lokaler Admins.

### Ein Boden, kein Wunsch

Setzt den Organisations-Standard so, dass alles ab Tag eins mindestens intern ist – und klassifiziert dann in dem Tempo nach oben, das das Business trägt.

### Policies, die durchsetzen

Kein Anhang-Download oberhalb einer Klassifizierung. Kein anonymer Zugriff. Keine öffentlichen Links. Angewendet pro Space und Projekt, einmal entschieden.

### Marketplace-Apps im Geltungsbereich

Eine eigene Policy begrenzt, wohin Drittanbieter-Apps reichen dürfen. Jeder Anbieter ist eine Lieferketten-Frage; das ist die Antwort, die ihr einem Auditor zeigen könnt.

### Start bei null Risiko

Premium einschalten, ohne aktive Policies. Logs und Alerts beobachten, das Umfeld verstehen – dann handeln. Niemand verliert dabei den Zugriff.

## Ein Organisations-Admin. Policies, die ein Jira-Admin nicht umgehen kann.

\<!-- Ohne XALT --\>

SITE-ADMIN

Data-Security-Policies

Kein Zugriff – Policies laufen komplett außerhalb der Site-Admin-Rolle

Klassifizierungs-Katalog

Kein Zugriff – Stufen und Standard sind Organisationssache

Projekt- & Space-Workflows

Volle Verantwortung – Tagesgeschäft bleibt lokal

Ausnahme auf Space-Ebene

Beantragt, nicht entschieden – geht immer nach oben

\<!-- Mit XALT. Am Telefon steht diese Spalte UNTER „Ohne XALT" — sie stand mit \`max-md:order-first\` davor, und damit las die Seite die Antwort vor dem Problem (Abnahme 2026-09-02: „Ansicht NEU muss auf mobile unter Ansicht ALT angezeigt werden → ergibt vom prozess mehr sinn"). Rundung \`rounded-md\` wie Buttons und Karten; die Spalte hatte 18px und einen gruenen Verlauf als einzige Flaeche der Seite (Abnahme 2026-09-02). Akzent-Rahmen und Schein bleiben — sie sind die Hervorhebung, der Verlauf war nur Dekor. --\>

ORG-ADMIN

Data-Security-Policies

Ausschließlich hier entschieden, für alle Konzerngesellschaften zentral

Klassifizierungs-Katalog

Ausschließlich hier gepflegt, inklusive Organisations-Standard

Projekt- & Space-Workflows

Keine Rolle, solange keine Policy verletzt wird

Ausnahme auf Space-Ebene

Freigegeben und protokolliert, nachvollziehbar für jeden Audit

## Wenn eure Labels in Purview leben, muss jemand beide Seiten ehrlich halten.

Es gibt heute keinen fertigen Connector.

1

Schritt 1

### Die fünf Stufen nachbauen

Dieselben Vertraulichkeitsstufen wie in Purview, einmal in der Atlassian-Organisation angelegt. Schnell gemacht, ohne Integration aber für immer manuell.

2

Schritt 2

### Labels lesen, Logs zurückspielen

Eine Marketplace-App, die Vertraulichkeits-Labels aus Purview liest und die Audit-Spur zurückgibt – Auditoren bleiben in ihrem gewohnten Tool statt Jira lernen zu müssen.

3

Schritt 3

### Ihr steht nicht auf dem Trockenen

Bringt Atlassian den Connector später selbst, verliert ihr nichts – Klassifizierungen, Policies und Log-Routing stehen schon, die Integration zieht sich still zurück.

## Für heute bauen. Für das nächste Release planen.

Wir verfolgen die Roadmap, damit Ihre Architektur nicht neu gebaut werden muss.

1

Schritt 01

### Klassifizierungen, Policies, Detections, ausführliche Logs

Alles, um die Audit-Fragen zu beantworten, die ihr heute in Data Center beantwortet.

2

Schritt 02

### Policies auf Klassifizierungen · Rovo-Chat-Sicherheit · Anhang-Scan

In früher Vorschau und wenige Wochen entfernt – inklusive Detections für das, was Nutzer an die KI senden und von ihr abfragen.

3

Schritt 03

### Zugriff auf Basis der Klassifizierung

Zugriff gesteuert über die Klassifizierung statt allein über Berechtigungen – ohne festes Datum. Bis dahin lösen wir es über Berechtigungsgruppen, die den Wechsel überleben.

4

Schritt 04

### Policies in Klartext formuliert

Das Policy-Dokument übergeben statt reguläre Ausdrücke zu schreiben, und die Regeln daraus entwerfen lassen.

## Die Daten finden, automatisch klassifizieren, dann handeln.

Rund 70 Detections sind ab Werk dabei: Sozialversicherungsnummern, IBANs, Kreditkarten, Gesundheits- und Finanzentitäten, AWS-Keys – teils regional, alle einsatzbereit. Alles andere wird eine eigene Detection per regulärem Ausdruck. Findet Guard eine Kartennummer irgendwo, wird die Seite automatisch als vertraulich eingestuft – außer sie ist schon höher eingestuft. Genau das beruhigt Auditoren: Ihr wisst, wo sensible Daten liegen, auch außerhalb ihres vorgesehenen Zuhauses.

- ~70 Detections ab Werk, plus eigene Muster per Regex
- Automatische Klassifizierung, sobald ein Treffer irgendwo auftaucht
- Automation am Alert: einschränken, benachrichtigen, verzweigen
- Nutzeraktivität im Blick: verdächtige Suchen, Massen-Exporte, Logins aus Tor-Exit-Nodes

Jeder Content-Scan-Alert kann eine Automation auslösen: Seite einschränken, Owner benachrichtigen, nach Muster verzweigen. Zwei getrennte Streams tragen die Beweiskette – der unveränderliche Organisations-Audit-Log (Webhook oder REST-API) an das Plattform-Team, der Guard-Detect-Alert-Webhook an die Security.

## Beobachten, feinjustieren, dann automatisieren – nie umgekehrt.

Erst beobachten, dann eingreifen.

1

Schritt 01

### Einschalten, nichts ändern

Premium aktiv, keine Policy scharf. Logs und Alerts beobachten und lernen, wie das Umfeld wirklich aussieht.

2

Schritt 02

### Muster feinjustieren

Eine schlampige Detection trifft alles. Wir lassen eigene Detections Stunden laufen, bevor etwas Automatisches daran hängt.

3

Schritt 03

### Das Offensichtliche automatisieren

Einschränken und benachrichtigen, wo das Muster eindeutig ist; einen Menschen im Loop lassen, wo es das nicht ist. Niemand liest jeden Alert.

4

Schritt 04

### Den Auditoren die Beweise geben

Log-Routing ins SIEM, Policies dokumentiert, Ausnahmen protokolliert – der Migrationsfall ergibt sich von selbst.

## Was Auditoren und IT-Leitung als Erstes fragen.

Antworten, die den Migrationsentscheid beschleunigen.

Nicht als Code, aber als Ergebnis: Statt eines selbst gebauten Dropdowns mit eigener Reporting-Logik bekommt ihr fünf bis zehn Stufen, einen Organisations-Standard und Policies, die auf jeder Stufe greifen. Die Migration ist eine Übersetzung der Regeln, kein Rewrite der App.

Der Organisations-Standard setzt einen Boden – alles startet mindestens intern, ab dem Moment, in dem ihr Premium aktiviert. Bestehende Inhalte klassifiziert ihr im Tempo, das euer Team trägt; die automatische Klassifizierung durch Detection greift parallel, unabhängig vom manuellen Fortschritt.

Das hängt vom Umfeld ab, nicht von der Technik: Wir aktivieren Premium ohne Policies, beobachten Logs und Alerts einige Wochen, justieren eigene Detections nach und schalten erst dann automatische Restriktionen scharf. Das verhindert, dass eine zu breite Regel produktive Arbeit blockiert.

Guard Premium deckt die Atlassian-Seite vollständig ab. Ohne Integration bleiben Purview-Labels und Atlassian-Klassifizierung zwei getrennte Systeme, die von Hand synchron gehalten werden müssen – genau die Lücke, die wir mit einer Marketplace-App schließen, sobald sie gebraucht wird.

## Bringt die Fragen eurer Auditoren mit. Wir beantworten sie eine nach der anderen.

Ein Compliance-Review eures Data-Center-Setups gegen Guard Premium – was direkt passt, was einen Workaround braucht und worauf es sich zu warten lohnt. Ihr geht mit der Roadmap, nicht mit einem Pitch.

[Compliance-Review buchen](https://www.xalt.de/kontakt/)

---

*Diese Fassung ist für KI-Agenten. Jede Seite dieser Website gibt es als Markdown: `index.md` an den Pfad hängen. Übersicht aller Seiten: [llms.txt](https://www.xalt.de/llms.txt)*