Sensitivity Labels in Microsoft 365: Der Praxisleitfaden

Was sind Built-in Labels und warum ist das wichtig?

Microsoft unterscheidet zwischen Built-in Labels und Nicht-Built-in Labels — der Unterschied entscheidet, welche Funktionen mit gelabelten Dokumenten noch funktionieren.

Ein Label ist "built-in", wenn Microsoft 365 (SharePoint Online, OneDrive, Office for the Web) das Label nativ verstehen und damit arbeiten kann. Das bedeutet: Co-Authoring, SharePoint-Suche, Vorschau, AutoSave und das Setzen des Labels direkt in Office for the Web funktionieren wie gewohnt.

Ein Label wird zu einem Nicht-Built-in Label, sobald eine der folgenden Bedingungen zutrifft:

• Der Dateityp ist nicht unterstützt (z.B. CAD-Dateien, XML, Bilder, ältere Office-Formate wie .doc)
• Die Label-Konfiguration enthält bestimmte Einschränkungen wie "Offline Access: Never" oder "Content Expiration"
• Double Key Encryption ist aktiviert

Bei Dateien ohne native Unterstützung für Built-in Labeling entfallen je nach Dateityp und Label-Konfiguration zentrale Microsoft-365-Funktionen wie SharePoint-Indexierung, Co-Authoring, Vorschau oder OCR für gelabelte Bilder. Labels und Schutz müssen in solchen Fällen häufig über den Microsoft Purview Information Protection Client bzw. entsprechende Client- oder SDK-basierte Werkzeuge angewendet werden. Bei generischer Schutzanwendung erhalten Dateien die Endung .pfile; bei nativ unterstützter Schutzanwendung können dateitypspezifische geschützte Endungen verwendet werden, etwa .pjpg für JPEG-Dateien.

PDF-Dateien sind ein Sonderfall: Sie werden als Built-in Labels unterstützt, müssen aber auf Tenant-Ebene separat per PowerShell aktiviert werden.

Praktische Konsequenz: Wenn Ihr Unternehmen viele Nicht-Office-Dateien (technische Zeichnungen, Bilder, Legacy-Formate) mit Labels versehen will, verlieren Sie für diese Dateitypen die komfortable SharePoint-Integration. Planen Sie diesen Punkt frühzeitig in die Dateitypen-Strategie ein.

Wie funktionieren Publishing Policies und Default Labels?

Ein konfiguriertes Sensitivity Label ist für Endnutzer zunächst unsichtbar. Erst die Publishing Policy stellt das Label den definierten Benutzergruppen zur Verfügung und steuert das Verhalten rund um das Label.

In einer Publishing Policy definieren Sie:

• Berechtigte Nutzergruppen: Welche Personen oder Gruppen sehen dieses Label in ihren Clients?
• Required Labeling: Müssen Nutzer vor dem Speichern oder Versenden zwingend ein Label wählen?
• Justification: Muss ein Nutzer beim Entfernen oder Herabstufen eines Labels eine Begründung eingeben? Diese Aktion wird auditiert.
• Default Label für Dokumente: Welches Label wird beim Erstellen eines neuen Office-Dokuments automatisch gesetzt?
• Default Label für E-Mails: Welches Label wird bei neuen E-Mails vorbelegt?
• E-Mail-Anhänge erben das Label: Sollen angehängte Dokumente das Label der E-Mail übernehmen?

Wichtig bei Default Labels: Das Default Label aus der Publishing Policy greift nur in Office-Clients (Word, Excel, Outlook). Sobald ein Dokument direkt in SharePoint angelegt wird — etwa per "Neues Dokument" auf einer SharePoint-Seite oder per Upload — greift dieses Default Label nicht.

Für SharePoint-Bibliotheken gibt es eine separate Einstellung: Pro Bibliothek kann ein Default Sensitivity Label konfiguriert werden. Alle neuen oder hochgeladenen Dokumente in dieser Bibliothek erhalten dann automatisch das hinterlegte Label. Microsoft bietet allerdings keinen nativen Mechanismus, um diese Einstellung regelbasiert und automatisiert pro Team-Typ oder Site-Typ zu setzen — ein Punkt, der bei großflächiger Einführung schnell zum Problem wird.

Wie führe ich Sensitivity Labels richtig ein?

Eine erfolgreiche Einführung folgt einer klaren Phasenreihenfolge. Wer zu viel auf einmal will, landet mit inkonsistent gelabelten Dokumenten, frustrierten Endnutzern und Berechtigungskonflikten.

Phase 1: Label-Definition mit kleinem Kreis

Der erste Schritt ist die Festlegung der Labels selbst — und hier gilt: möglichst wenige Personen einbeziehen. Empfohlen sind jeweils ein Vertreter aus IT, Datenschutz und dem CISO-Bereich sowie ein bis zwei Fachbereichsvertreter. Mit 15 Stakeholdern kommen Sie nicht zu einer tragbaren Label-Struktur.

Phase 2: Klassifizierung ohne Verschlüsselung

Starten Sie ausschließlich mit der Klassifizierungsstufe. Keine Verschlüsselung, keine Berechtigungen — nur sichtbare Labels mit optionalem Header, Footer und Wasserzeichen. Das reduziert die technische Komplexität drastisch und liefert trotzdem einen großen Teil des Nutzens: Endnutzer sehen sofort, wie vertraulich ein Dokument ist, und ändern ihr Teilungsverhalten entsprechend.

Phase 3: Entfernungs- und Eskalationsprozess definieren

Bevor Labels produktiv gehen, klären Sie: Wer darf Labels entfernen oder herabstufen? Wie läuft der Prozess, wenn ein verschlüsseltes Dokument zugänglich gemacht werden muss, weil der Eigentümer das Unternehmen verlassen hat? Ohne diesen Prozess entstehen später operative Engpässe.

Phase 4: Pilot-Rollout mit Testgruppe

Rollen Sie Labels zuerst an eine kleine Testgruppe aus — 10 bis 30 Personen in verschiedenen Rollen. Publishing Policies erlauben sehr granulare Steuerung, mit welchen Benutzern Labels ausgerollt werden. Sammeln Sie Feedback zu Label-Namen, Default-Verhalten und Usability, bevor Sie breiter ausrollen.

Phase 5: Globaler Rollout und schrittweise Erweiterung

Nach erfolgreichem Pilot: globaler Rollout der Klassifizierungs-Labels. Erst danach Erweiterung um Verschlüsselung, Data Loss Prevention Policies, eDiscovery-Integration und — wenn überhaupt — Auto-Labeling.

Was sind die wichtigsten Best Practices für Sensitivity Labels?

Wenig Labels, klare Hierarchie

Mehr als fünf bis sechs Labels überfordern Endnutzer. Wenn ein Nutzer vor 20 Labels steht, wählt er das falsche oder keines. Eine typische, funktionierende Struktur: Public, Internal, Confidential, Highly Confidential und ein Sonderlabel wie "No AI" oder "Restricted".

Keine Einstellungen auf Label-Containern

Label-Container gruppieren Labels visuell in der Benutzeroberfläche. Setzen Sie auf diesen Containern keine Einstellungen — weil der Container für Nutzer wie ein Label aussieht und nicht klar ist, ob er angewendet werden soll oder nur Gruppierungscharakter hat. Alle Einstellungen gehören auf die Einzel-Labels innerhalb des Containers.

Mit Klassifizierung starten, nicht mit Verschlüsselung

Die Verschlüsselung ist technisch und organisatorisch die anspruchsvollere Stufe. Sie erfordert klare Berechtigungsmodelle, Schlüsselverwaltung, Lizenzprüfung und Eskalationsprozesse. Reine Klassifizierung ist in Tagen einsatzfähig und erzeugt bereits messbaren Effekt.

Auto-Labeling ans Ende der Projektphase stellen

Auto-Labeling klingt verlockend, birgt aber erhebliches Risiko. False Positives können dazu führen, dass Dokumente falsch klassifiziert und im schlimmsten Fall falsch verschlüsselt werden — mit hohem manuellen Aufräumaufwand. Führen Sie Auto-Labeling erst ein, wenn manuelle Labels etabliert sind und Ihr Team Erfahrung mit Classifiers hat.

Downgrade-Regeln und Label-Priorität explizit durchdenken

Jedes Label hat eine Priorität. Die Priorität bestimmt nicht nur die Reihenfolge in der Oberfläche, sondern auch, wann ein Downgrade als solches gilt und eine Begründung erfordert. Klären Sie im Voraus: Dürfen Nutzer von Confidential auf Internal herabstufen? Welcher Prozess läuft im Hintergrund?

Regulatory Records mit Bedacht einsetzen 

Microsoft bietet im Records Management sogenannte Regulatory Records. Diese werden über Retention Labels bzw. Compliance Tags umgesetzt und können parallel zu Sensitivity Labels verwendet werden. Die Option ist standardmäßig ausgeblendet und muss zunächst per PowerShell aktiviert werden.

Ist ein solches Retention Label einmal auf ein Dokument oder eine E-Mail angewendet, kann es niemand mehr entfernen — nicht einmal ein globaler Administrator. Setzen Sie Regulatory Records deshalb nur ein, wenn Sie diese Unwiderruflichkeit bewusst benötigen, etwa für revisions-, audit- oder regulatorisch kritische Inhalte. Der Begriff „regulatory“ beschreibt dabei eine technische Microsoft-Funktion.

Wie setze ich Default Sensitivity Labels auf SharePoint-Bibliotheken automatisiert?

Microsoft bietet im Standard keinen Mechanismus, um pro Team-Typ oder SharePoint-Site-Typ regelbasiert ein Default Sensitivity Label auf die zugehörigen Dokumentenbibliotheken zu setzen. Admins müssen nach jeder Team- oder Site-Erstellung die Einstellung manuell pro Bibliothek konfigurieren — oder akzeptieren, dass neu erstellte Container ohne Default Label starten.

Genau an dieser Stelle schließt Valprovia Governance die Lücke. Bei der Provisionierung eines neuen Teams oder einer neuen SharePoint-Seite wird das definierte Default Sensitivity Label automatisch auf die zugehörige Dokumentenbibliothek gesetzt. Die Regel gilt pro Team-Typ oder Site-Typ: Ein "Projektteam Intern" erhält ein anderes Default Label als ein "Projektteam mit externer Beteiligung" — ohne manuelle Nacharbeit, konsistent über den gesamten Tenant hinweg.

Zusätzlich wird das Container-Label (für die Teams-Einstellungen wie Gast-Zugriff oder Privacy) bei der Erstellung direkt mit angewendet. Der Administrator definiert einmal die Regeln pro Team-Typ, und jede neue Provisionierung startet mit korrekter Klassifizierung auf beiden Ebenen — Container und Daten.

Welche Einschränkungen und Lizenzen sollten Sie kennen?

Lizenzanforderungen

Manuelles Labeling inklusive Verschlüsselung ist in nahezu allen Microsoft 365 Lizenzen enthalten (ab Business Premium aufwärts). Folgende Features erfordern Microsoft 365 E5 oder das Compliance Add-on:

• Auto-Labeling (Server-side und Client-side)
• Content Explorer und Activity Explorer
• Audit-Reporting für Label-Aktivitäten
• Data Loss Prevention mit Label-Bedingungen

Double Key Encryption: maximale Absicherung mit Funktionsverlust

Double Key Encryption (DKE) verschlüsselt Dokumente mit zwei Schlüsseln — einem von Microsoft und einem, der ausschließlich beim Kunden liegt. Microsoft kann DKE-geschützte Dokumente nicht entschlüsseln, auch nicht auf Anfrage von Behörden. Der Preis: Sämtliche Cloud-Services, die den Inhalt entschlüsseln müssten, funktionieren nicht mehr — keine SharePoint-Suche, kein Co-Authoring, keine KI-gestützten Zusammenfassungen. DKE setzt zudem Microsoft 365 E5 und lokale Hardware für die Schlüsselverwaltung voraus.

Performance und Kompatibilität

Gelabelte und verschlüsselte Dokumente laden im Office-Client messbar langsamer. OneDrive-Sync-Konflikte durch AutoSave treten seltener als früher auf, kommen aber vor. Microsoft Loop synchronisiert Tasks nicht, wenn das übergeordnete Meeting oder Dokument ein internes Verschlüsselungslabel trägt.

Mobile Clients

Mobile Apps (iOS, Android) unterstützen Sensitivity Labels, benötigen aber aktuelle Office-App-Versionen. Bei älteren Versionen verhindert das Label unter Umständen das Öffnen auf dem Mobilgerät. Planen Sie die Mindest-Office-Version im Rollout mit ein.

Häufig gestellte Fragen zu Sensitivity Labels

Was ist der Unterschied zwischen Klassifizierung und Verschlüsselung bei Sensitivity Labels?

Klassifizierung kennzeichnet Dokumente sichtbar mit einer Vertraulichkeitsstufe, zum Beispiel per Header, Footer oder Wasserzeichen, ändert aber nichts am Zugriff. Verschlüsselung schützt das Dokument technisch und definiert separate Berechtigungen. Die Label-Verschlüsselung ergänzt SharePoint-Berechtigungen um eine zusätzliche Schutzschicht: SharePoint kann den Zugriff erlauben, das Dokument bleibt aber trotzdem unlesbar, wenn die erforderliche Label-Berechtigung fehlt.

Brauche ich eine Microsoft 365 E5-Lizenz für Sensitivity Labels?

Nein. Manuelles Labeling inklusive Verschlüsselung ist ab Microsoft 365 Business Premium verfügbar. Microsoft 365 E5 oder das Compliance Add-on benötigen Sie erst für Auto-Labeling, Content Explorer, Activity-Reporting und DLP-Integration mit Label-Bedingungen.

Was passiert, wenn ich ein Container-Label von einem Team entferne?

Die durch das Label gesetzten Einstellungen (Gast-Zugriff, Privacy-Status, Unmanaged-Device-Regeln) bleiben bestehen. Microsoft rollt sie nicht automatisch zurück. Um zum Ursprungszustand zurückzukehren, müssen Sie die Einstellungen manuell oder per Skript zurücksetzen. Beim Wechsel auf ein anderes Label werden die Einstellungen des neuen Labels allerdings synchronisiert.

Sollte ich Auto-Labeling sofort nutzen?

Nein. Auto-Labeling ist das letzte Feature, das Sie einführen sollten. False Positives können dazu führen, dass Dokumente falsch klassifiziert oder sogar falsch verschlüsselt werden — mit erheblichem manuellen Aufräumaufwand. Führen Sie zuerst manuelle Labels und Verschlüsselung produktiv ein, sammeln Sie Erfahrung mit Classifiers und aktivieren Sie Auto-Labeling erst, wenn Sie False-Positive-Management und Bulk-Update-Prozesse etabliert haben.

Wie viele Sensitivity Labels sollte ein Unternehmen maximal definieren?

In der Praxis haben sich fünf bis sechs Labels bewährt. Mehr Labels überfordern Endnutzer, die dann das falsche oder gar kein Label wählen. Eine typische Struktur: Public, Internal, Confidential, Highly Confidential und optional ein Sonderlabel wie "No AI" oder "Restricted". Die genaue Zahl hängt von Unternehmensgröße und Datenarten ab, aber weniger ist hier fast immer mehr.

Kann ein regulatorisches Sensitivity Label wieder entfernt werden?

Nein — und genau das ist der Zweck. Ein regulatorisches Label ist nach der Anwendung nicht mehr entfernbar, auch nicht durch einen globalen Administrator. Es lässt sich nur löschen, indem die Label-Definition komplett aus dem Tenant entfernt wird. Setzen Sie regulatorische Labels ausschließlich für Audit-kritische Inhalte ein, bei denen Sie die Unwiderruflichkeit bewusst wollen.