Laura Korn. OpEx w/ Microsoft Cloud

Der Freigabeprozess aus dem letzten Beitrag funktioniert jetzt.
Das Angebot wird in Dynamics 365 erstellt, sauber versioniert in SharePoint abgelegt und über Power Automate zur Freigabe geschickt. Entscheidungen sind dokumentiert, Verantwortlichkeiten klar.

Aus technischer Sicht könnte man an dieser Stelle sagen: Problem gelöst.
In der Praxis beginnt hier aber erst das nächste.

Denn die entscheidende Frage lautet nicht nur, wie ein Angebot freigegeben wird – sondern auch, welche Informationen darin enthalten sind und wie mit ihnen umgegangen werden darf.

Und genau hier kommt ein Thema ins Spiel, das oft falsch eingeordnet wird: Information Protection.

Das gleiche Beispiel – ein neuer Blickwinkel

Bleiben wir beim Angebot im Vertrieb.
Ein typisches Angebotsdokument enthält mehr als nur Preise. Es enthält:

• individuelle Rabattstrukturen
• interne Kalkulationen
• möglicherweise personenbezogene Daten
• strategische Informationen über Kunden

Im bisherigen Prozess wurde sichergestellt, dass das Dokument freigegeben wird.
Aber nicht, wie sensibel es ist – oder was danach damit passiert.

Wird das Dokument weitergeleitet?
Darf es extern geteilt werden?
Wie lange muss es aufbewahrt werden?
Wer darf es später noch einsehen?

Ohne klare Antworten auf diese Fragen ist der Prozess zwar sauber – aber nicht compliant.

Wo es im Alltag schiefgeht

In vielen Umgebungen sieht die Realität so aus:

Das Angebot liegt in einer SharePoint-Bibliothek, vielleicht sogar strukturiert.
Der Zugriff ist über Teams möglich.
Der Freigabeprozess läuft.

Aber:

• Das Dokument hat kein Label
• oder ein generisches wie „Allgemein“
• oder der User hat einfach irgendetwas ausgewählt, damit die Meldung verschwindet

Das Ergebnis ist ein System, das formal funktioniert – aber inhaltlich blind ist.

Für Copilot, für Audits und für Compliance gibt es keinen Unterschied zwischen einem öffentlichen Dokument und einem hochsensiblen Angebot, wenn beide gleich behandelt werden.

Warum das kein reines Security-Thema ist

An dieser Stelle wird Information Protection oft an Security oder Compliance delegiert.
Das führt fast immer zu Problemen.

Denn die Frage, ob ein Angebot sensibel ist, ist keine technische Frage, sondern eine fachliche Entscheidung.

• Der Vertrieb weiß, wie kritisch bestimmte Informationen sind
• das Management kennt strategische Bedeutung
• Legal kennt regulatorische Anforderungen

Wenn diese Perspektiven nicht zusammenkommen, entstehen Labels ohne Bedeutung und auch das sieht man häufig:
Eine saubere technische Implementierung von Microsoft Purview – ohne echte Verankerung im Prozess.

Wie Purview sinnvoll in den Prozess integriert wird

Wenn man das Angebotsbeispiel weiterdenkt, ergibt sich ein klarer Ansatz.

Das Label darf kein nachgelagerter Schritt sein, den der User „irgendwann“ auswählt. Es muss Teil des Prozesses werden.

Konkret bedeutet das:
Bereits beim Erstellen des Angebots – sei es direkt in Dynamics 365 oder beim Generieren des Dokuments – wird festgelegt, in welche Kategorie es fällt. Zum Beispiel:

• Öffentlich (Standardpreise, keine besonderen Rabatte, keine sensiblen Zusatzinfos)
• Vertraulich – Strategisch (individuelle Rabatte, Sonderkonditionen oder große Deals mit wettbewerbssensitiven Infos)

Diese Klassifizierung basiert nicht auf Bauchgefühl, sondern auf klar definierten Kriterien, etwa Rabattgrenzen, Kundentyp oder enthaltene Daten.

Im nächsten Schritt wird dieses Label technisch durchgesetzt.
Das kann automatisiert passieren, etwa über Metadaten aus dem CRM oder auch über Power Automate, das beim Erstellen oder Speichern des Dokuments das passende Sensitivity Label setzt.

Damit verändert sich der gesamte weitere Ablauf:

Ein als „Vertraulich – Strategisch“ klassifiziertes Angebot kann nicht mehr einfach extern geteilt werden, bzw. nur an einen bestimmten Personenkreis.
Bestimmte Aktionen werden eingeschränkt, protokolliert oder verhindert.

Gleichzeitig entsteht etwas, das vorher gefehlt hat: Kontext.

Was sich dadurch konkret verbessert

Plötzlich ist nicht nur der Prozess nachvollziehbar, sondern auch der Umgang mit den Daten darin.
Wenn später eine Frage auftaucht – etwa im Rahmen eines Audits oder eines Incidents – lässt sich nicht nur sagen, wer das Angebot freigegeben hat.

Man kann auch beantworten:

• Welche Klassifizierung hatte das Dokument?
• Wer hat darauf zugegriffen?
• Wurde es extern geteilt?
• Wurde es verändert?

Und genau hier zeigt sich die eigentliche Stärke von Microsoft Purview: nicht als isoliertes Compliance-Tool, sondern als Bestandteil eines funktionierenden Prozesses.

Kleiner Tipp am Rande: Natürlich kann man mit Purview hier auch noch die Aufbewahrung nach HGB und AO steuern über entsprechende Retention Label.

Konkrete Handlungsempfehlungen

Wenn du dieses Szenario in deiner Umgebung verbessern willst, helfen drei sehr konkrete Schritte:

1. Definiere eine kleine, verständliche Klassifizierungslogik.
   Drei bis fünf Labels reichen völlig aus – entscheidend ist, dass sie im Alltag angewendet werden können.
2. Verknüpfe die Klassifizierung mit bestehenden Prozessen. Im Beispiel: Das Angebot bekommt sein Label nicht manuell irgendwann, sondern automatisch oder verpflichtend im Freigabeprozess.
3. Nutze Purview nicht nur zur Einschränkung, sondern zur Transparenz. Audit Logs und Aktivitätsdaten sind kein „Nice to have“, sondern die Grundlage dafür, im Ernstfall belastbare Aussagen treffen zu können.

Fazit

Ein sauberer Prozess ohne Information Protection ist vollständig – aber nicht belastbar. Und das wird spätestens dann zum Problem, wenn Systeme wie Copilot beginnen, auf diese Daten zuzugreifen und sie neu zu kombinieren.

Denn ohne Kontext ist jede Information gleich.
Und ohne Klassifizierung gibt es keinen Kontext.