Datenverlust vermeiden: DLP und Vertraulichkeitslabels in Microsoft 365

Vertrauliche Daten verlassen ein Unternehmen selten durch spektakuläre Hacks – viel häufiger landen Angebote, Personalakten oder Kundendaten versehentlich im falschen Postfach, einer offenen SharePoint-Freigabe oder einem privaten USB-Stick. Mit DLP und Vertraulichkeitslabels in Microsoft 365 baust du in Microsoft Purview einen zweistufigen Schutz auf: Labels klassifizieren und verschlüsseln Inhalte, Data Loss Prevention (DLP) erkennt sensible Informationen wie Kreditkarten oder IBAN und blockiert oder warnt beim Versand. Diese Anleitung zeigt dir die genauen Klickpfade im Purview-Portal, die wichtigsten PowerShell-Befehle und wie du alles erst gefahrlos im Simulationsmodus testest, bevor es scharf geschaltet wird.

Voraussetzungen

Bevor du loslegst, kläre Lizenzen, Rollen und den Portalzugang. Beides – Labels und DLP – steuerst du zentral im Microsoft-Purview-Portal unter purview.microsoft.com.

• Lizenzen: Manuelles Labeling sowie DLP für Exchange Online, SharePoint und OneDrive sind bereits in Microsoft 365 E3 enthalten. Auto-Labeling, Endpoint-DLP (Geräte), DLP für Teams, erweiterte Outlook-Richtlinientipps sowie Content Explorer und Activity Explorer benötigen Microsoft 365 E5 bzw. das Add-on Information Protection and Governance.
• Rollen für DLP: Du brauchst eine der Rollen Compliance Administrator, Compliance Data Administrator, Information Protection, Information Protection Admin oder Security Administrator. Für Labels reichen die Information-Protection-Rollen.
• Portale: Purview unter purview.microsoft.com (Labels + DLP), Entra unter entra.microsoft.com (Gruppen für die Veröffentlichung), Intune unter intune.microsoft.com (Geräte-Onboarding für Endpoint-DLP). Apple-Geräte verwaltest du bei Bedarf über den Apple Business Manager unter business.apple.com.
• Endpoint-DLP: setzt onboardete Geräte voraus (Windows 10/11 und macOS 10.15+). Das Onboarding ist mit Microsoft Defender for Endpoint geteilt und läuft über Intune bzw. MDM.
• PowerShell: Für skriptbares Label-Management installierst du das Exchange-Online-Modul und verbindest dich mit Connect-IPPSSession zur Security & Compliance PowerShell.

Wichtig zur Replikation: Änderungen an Labels und Richtlinien brauchen Zeit – rechne mit bis zu 24 Stunden, bis sie in den Apps sichtbar sind, und mit 48–72 Stunden bei Containern (Gruppen/Sites). Beginne erst danach mit dem Troubleshooting.

Schritt 1: Label-Konzept festlegen

Bevor du klickst, lege die Klassifizierungsstufen fest. Halte das Set bewusst klein – vier Stufen reichen den meisten Mittelständlern. Eine bewährte Struktur:

Label	Bedeutung	Verschlüsselung	Inhaltsmarkierung
Öffentlich	Für die Veröffentlichung freigegeben	nein	optional Fußzeile
Intern	Nur für Mitarbeitende	nein	Fußzeile „Intern“
Vertraulich	Begrenzter Personenkreis, sensible Daten	ja (RMS)	Kopf-/Fußzeile + Wasserzeichen
Streng vertraulich	Höchste Stufe, z. B. Verträge, M&A	ja (RMS, eng begrenzt)	Kopf-/Fußzeile + Wasserzeichen

Zwei Punkte zur Architektur, die du gleich am Anfang verstehen solltest:

• Label-Priorität: In der Liste steht das Label am weitesten unten für die höchste Vertraulichkeit. Über Move up / Move down ordnest du die Reihenfolge.
• Modern label scheme: Tenants, die ab dem 1. Oktober 2025 erstellt wurden, nutzen das moderne Schema mit Label-Gruppen statt Sublabels. Im klassischen Schema veröffentlichst du Sublabels immer zusammen mit ihrem Parent-Label.

Schritt 2: Vertraulichkeitslabel erstellen

Jetzt legst du die Labels an. Das geschieht in zwei getrennten Phasen: erst das Label erstellen (Schritt 2), dann per Richtlinie veröffentlichen (Schritt 4). Solange ein Label nicht in einer veröffentlichten Richtlinie steckt, sieht es niemand.

Klickpfad im Purview-Portal:

purview.microsoft.com
  > Solutions > Information Protection
    > Sensitivity labels
      > + Create a label   (klassisch)
        bzw. + Create > Label   (modern label scheme)

Ablauf im Assistenten:
  1. Name & Tooltip   -> z. B. "Vertraulich"
  2. Define the scope -> Files and other data assets,
                         Emails, Meetings, Groups and sites,
                         Data Map (preview)
  3. Konfiguration je nach Scope:
     - Encryption (RMS)  -> Verschluesselung
     - Content marking   -> Header/Footer/Wasserzeichen
     - Auto-labeling     -> nur E5 / IPG
     - Container-Schutz  -> Gruppen & Sites
  4. Save the label

Hinweise zum Scope: Meetings lassen sich nur konfigurieren, wenn auch Files und Emails aktiviert sind. Die Inhaltsmarkierung (Kopf-/Fußzeile, Wasserzeichen) und die Verschlüsselung greifen für Files und Emails; der Container-Schutz steuert Gruppen und SharePoint-Sites.

Lege auf diese Weise alle vier Stufen an. Bei Öffentlich und Intern lässt du die Verschlüsselung aus; bei Vertraulich und Streng vertraulich aktivierst du RMS-Verschlüsselung und Inhaltsmarkierung.

Schritt 3: Verschlüsselung und Markierung konfigurieren

Die eigentliche Schutzwirkung der höheren Labels steckt in zwei Fähigkeiten:

• Verschlüsselung (RMS): Im Abschnitt Encryption legst du fest, wer mit dem Inhalt was darf (Lesen, Bearbeiten, Drucken, Kopieren). Die Berechtigung reist im Dokument mit – auch wenn die Datei das Unternehmen verlässt, bleibt sie geschützt. Das macht Labels stärker als reine Freigabe-Einstellungen.
• Inhaltsmarkierung: Unter Content marking definierst du Kopfzeile, Fußzeile und Wasserzeichen. So ist im Ausdruck erkennbar, dass ein Dokument vertraulich ist.
• Auto-Labeling: Optional weist du ein Label automatisch zu, wenn Inhalte bestimmte Muster enthalten. Das benötigt aber E5 bzw. das IPG-Add-on und wird hier nur als Möglichkeit genannt.

Lösche ein bereits angewendetes Label nicht. Die Schutzvorlage wird archiviert, ein Label gleichen Namens lässt sich nicht neu erstellen, und im Activity Explorer erscheint dann nur noch die GUID statt des Klarnamens. Willst du ein Label loswerden, entferne es stattdessen aus der Richtlinie.

Schritt 4: Labels per Richtlinie veröffentlichen

Erst die Veröffentlichung bringt die Labels zu den Nutzern. Achte darauf, im Assistenten den Punkt Publish label zu wählen – nicht versehentlich Create a label.

purview.microsoft.com
  > Information Protection > Publishing policies
    > Publish label
      1. Choose sensitivity labels to publish
         -> alle vier Labels auswaehlen
      2. Admin units    -> Standard: Full directory
      3. Nutzer/Gruppen -> z. B. "Alle Mitarbeiter"
      4. Policy settings:
         - Standardlabel setzen (z. B. "Intern")
         - Begruendung bei Herabstufung verlangen
         - Pflicht-Labeling erzwingen (optional)
      5. Name der Richtlinie
      6. Submit  -> wird automatisch veroeffentlicht

Empfehlung: Komme mit möglichst wenigen Label-Richtlinien aus, oft genügt eine einzige für alle Mitarbeitenden. Mehrere Richtlinien brauchst du nur, wenn Abteilungen unterschiedliche Standardlabels oder Pflichtvorgaben benötigen. Die Gruppen dafür legst du im Entra-Portal unter entra.microsoft.com an.

Schritt 5: DLP-Richtlinie planen – Scope, State, Actions

Damit steht die Klassifizierung. Jetzt kommt die Data Loss Prevention dazu. Jede DLP-Richtlinie ruht auf drei Achsen, die du der Reihe nach festlegst:

Achse	Frage	Optionen
Scope (Speicherorte)	Wo soll geschützt werden?	Exchange, SharePoint, OneDrive, Teams, Geräte (Endpoint), Fabric/Power BI, Copilot, Browser/Netzwerk
State (Status)	Wie aktiv ist die Richtlinie?	Keep it off; Run in simulation mode; Simulation mode + show policy tips; Turn it on right away
Actions (Aktionen)	Was passiert bei einem Treffer?	Allow (nur Geräte); Audit only; Block with override; Block

Die goldene Regel für den Rollout: Klein anfangen, dann ausweiten. Starte mit der geringsten Eingriffsstufe – Status Run in simulation mode und Aktion Audit only – und eskaliere erst, wenn die Treffer sauber aussehen. Standardmäßig deckt eine Richtlinie alle Instanzen eines Speicherorts ab; über Include/Exclude grenzt du auf bestimmte Postfächer, Sites oder Gruppen ein.

Schritt 6: DLP-Richtlinie für Kreditkarten und IBAN erstellen

Jetzt baust du die konkrete Richtlinie. Als Bedingung dienen die Sensitive Information Types (SITs) – fertige Erkennungsmuster von Microsoft. Wichtig: Die eingebauten SITs lassen sich nur kopieren, nicht direkt bearbeiten.

purview.microsoft.com
  > Data Loss Prevention > Policies
    > + Create policy
      1. Vorlage / Custom waehlen
      2. Name & Beschreibung
      3. Locations -> Exchange, SharePoint, OneDrive,
                      Teams, Devices (Endpoint)
                      Standard: alle Instanzen,
                      Verfeinerung via Include/Exclude
      4. Conditions (Sensitive Information Types):
         - Credit Card Number
         - IBAN
         - Gesundheitsdaten via Named Entity SITs
      5. Actions:
         - Audit only          (Start, geringste Stufe)
         - Block with override (spaeter, Pilot)
         - Block               (scharf)
         - Allow               (nur Devices)
      6. User notifications + Overrides
      7. State: Run in simulation mode
      8. Submit

Hintergrund zu den SITs: Die Credit Card Number nutzt die Funktion Func_credit_card und meldet einen High-Confidence-Treffer, wenn die Stützmerkmale innerhalb von 300 Zeichen liegen. IBAN erkennt internationale Kontonummern; Gesundheitsdaten deckst du über die Named Entity SITs ab (E5/IPG-Funktion).

Die Overrides – also die Möglichkeit für Nutzer, eine Blockade mit Begründung zu übergehen – konfigurierst du im Abschnitt User notifications / Benutzerbenachrichtigung. Das ist genau der Mechanismus hinter der Aktion Block with override.

Schritt 7: Im Simulationsmodus testen und Treffer auswerten

Der Simulationsmodus ist das wichtigste Sicherheitsnetz – er ersetzt die früheren Test-Modi und zeigt dir, was die Richtlinie tun würde, ohne tatsächlich zu blockieren. Plane für die Beobachtung Zeit ein:

• Laufzeit: Die Simulation läuft bis zu 15 Tage und ist kein einmaliger Snapshot, sondern beobachtet laufend.
• Abdeckung je Speicherort: SharePoint und OneDrive prüfen vorhandene plus neue Inhalte; Exchange, Teams und Geräte erfassen nur neue Vorgänge. Die Wirkung auf Endpoints wird dadurch leicht unterschätzt – plane hier eigene Testaktionen ein.
• Datenaufbewahrung: Die Simulationsdaten bleiben 30 Tage erhalten.
• Alerts: Simulations-Warnungen erscheinen nur im Simulations-Tab der Richtlinie – nicht in der DLP-Alerts-Konsole und nicht im Defender-Portal. Suche sie also an der richtigen Stelle.

Der empfohlene, stufenweise Rollout sieht so aus:

Rollout-Stufen (State):
  1. Keep it off + Review          -> Konfiguration pruefen
  2. Run in simulation mode        -> breit, ohne Eingriff
  3. Simulation mode + policy tips -> Pilotgruppe sieht Tipps
  4. Turn it on right away         -> scharf schalten

Aktions-Eskalation parallel:
  Audit only -> Block with override -> Block

Werte im Simulations-Tab aus, welche Vorgänge getroffen würden. Sehr viele Treffer deuten meist auf zu breite Bedingungen oder Fehlalarme hin – verfeinere dann die SITs, bevor du eskalierst.

Schritt 8: Endpoint-DLP-Geräte onboarden (E5)

Damit DLP auch Aktionen am Endgerät erfasst – etwa Kopieren auf USB, Drucken oder Upload in Cloud-Apps – müssen die Geräte onboardet sein. Ohne Onboarding bleibt eine Endpoint-Regel wirkungslos.

purview.microsoft.com
  > Settings > Device onboarding
    > Devices
      -> Onboarding aktivieren
      -> geteilt mit Defender for Endpoint
      -> Verteilung via Intune (intune.microsoft.com) / MDM

Unterstuetzt: Windows 10/11, macOS 10.15+

Das Onboarding teilt sich die Konfiguration mit Microsoft Defender for Endpoint: Sind Geräte bereits für Defender onboardet, erscheinen sie auch hier. Die Verteilung der Onboarding-Pakete erledigst du am komfortabelsten über Intune.

Schritt 9: Labels per PowerShell verwalten (optional)

Für wiederholbare Konfigurationen oder mehrsprachige Labels ist PowerShell schneller als das Portal. Verbinde dich zuerst mit der Security & Compliance PowerShell:

Connect-IPPSSession

# Bestehende Labels samt GUID auflisten
Get-Label | Format-Table DisplayName, Name, Guid, ContentType

# Neues Label anlegen
New-Label -DisplayName "Vertraulich" -Name "Confidential" `
  -Tooltip "Nur fuer einen begrenzten Personenkreis" `
  -ContentType "File, Email"

# Label aendern (per GUID oder Name ansprechen)
Set-Label -Identity "Confidential" -DisplayName "Vertraulich"

# Label-Richtlinie erstellen und Nutzer/Gruppen zuweisen
New-LabelPolicy -Name "Standard-Labels" -Labels "Confidential"
Set-LabelPolicy -Identity "Standard-Labels" `
  -AddLabelGroup "Confidential"

Mehrsprachige Anzeigenamen und Tooltips setzt du über LocaleSettings als JSON. So sieht ein deutscher Nutzer „Öffentlich“, ein französischer die lokalisierte Variante:

$locale = [PSCustomObject]@{
  LocaleKey = "DisplayName"
  Settings  = @(
    @{ Key = "de-de"; Value = "Oeffentlich" },
    @{ Key = "fr-fr"; Value = "Public" },
    @{ Key = "it-it"; Value = "Pubblico" }
  )
}
Set-Label -Identity "Public" `
  -LocaleSettings ($locale | ConvertTo-Json -Depth 3)

Zum Aufräumen gibt es Remove-Label – beachte aber die Warnung weiter oben: Ein bereits angewendetes Label entfernst du besser aus der Richtlinie, statt es zu löschen.

Troubleshooting / Typische Fehler

• Label taucht nicht in den Apps auf: Labels werden erst sichtbar, nachdem sie einer veröffentlichten Richtlinie hinzugefügt wurden. Prüfe, ob das Label wirklich in der Richtlinie steckt – und nicht nur erstellt wurde. Verwechsle Publish label nicht mit Create a label.
• Änderung greift nicht sofort: Die Replikation dauert bis zu 24 Stunden, bei Containern (Gruppen/Sites) sogar 48–72 Stunden. Warte diese Frist ab, bevor du Fehlersuche betreibst.
• Gelöschtes Label hinterlässt GUIDs: Lösche niemals ein angewendetes Label. Die Schutzvorlage wird archiviert, der Name ist blockiert, und im Activity Explorer erscheint nur noch die GUID. Sicherer ist, das Label aus der Richtlinie zu entfernen.
• Simulation zeigt zu wenige Treffer: Die Simulation ist kein Snapshot. SharePoint/OneDrive erfassen vorhandene plus neue Inhalte, Exchange/Teams/Geräte nur neue Vorgänge. Endpoint-Effekte werden so leicht unterschätzt – teste sie aktiv durch echte Aktionen.
• Simulations-Alerts nicht auffindbar: Sie erscheinen ausschließlich im Simulations-Tab der jeweiligen Richtlinie, nicht in der DLP-Alerts-Konsole und nicht im Defender-Portal.
• Endpoint-Regel wirkt nicht: Endpoint-DLP greift nur auf onboardeten Geräten. Ohne Onboarding über Intune/Defender for Endpoint passiert nichts.
• Teams-DLP fehlt: DLP für Teams musst du gegebenenfalls über die Microsoft-Communications-DLP gesondert aktivieren. Bedenke außerdem: Allow gibt es nur für Geräte – als geringste Eingriffsstufe für andere Orte nutzt du Audit only.
• Lizenz-Falle: Auto-Labeling, Endpoint-DLP, Teams-DLP sowie Content und Activity Explorer sind nicht in E3 enthalten. Sie brauchen E5 oder das Add-on Information Protection and Governance.

Häufige Fragen

Was ist der Unterschied zwischen Vertraulichkeitslabels und DLP?

Labels klassifizieren und schützen einzelne Inhalte: Sie kennzeichnen ein Dokument als vertraulich, markieren es und verschlüsseln es mit mitreisenden Berechtigungen. DLP überwacht den Datenfluss: Sie erkennt sensible Informationen anhand von Mustern (etwa Kreditkarten oder IBAN) und blockiert oder warnt, wenn solche Daten den erlaubten Rahmen verlassen. Am stärksten ist die Kombination – DLP kann sogar auf gesetzte Labels reagieren.

Reicht eine Microsoft 365 E3 Lizenz für DLP und Labels?

Für den Einstieg ja: Manuelles Labeling und DLP für Exchange, SharePoint und OneDrive sind in E3 enthalten. Sobald du aber Auto-Labeling, Endpoint-DLP (Geräte), DLP für Teams oder die Auswertung über Content und Activity Explorer brauchst, ist E5 oder das Add-on Information Protection and Governance nötig.

Was macht der Simulationsmodus genau?

Er zeigt dir bis zu 15 Tage lang, welche Vorgänge eine DLP-Richtlinie treffen würde, ohne tatsächlich zu blockieren. So erkennst du Fehlalarme und falsch zugeschnittene Bedingungen, bevor Nutzer beeinträchtigt werden. Achtung: Die Abdeckung unterscheidet sich je Speicherort, und die Treffer siehst du nur im Simulations-Tab der Richtlinie.

In welcher Reihenfolge sollte ich eine DLP-Richtlinie scharf schalten?

Stufenweise: Erst Keep it off zum Prüfen, dann Run in simulation mode breit, anschließend Simulation mode plus policy tips für eine Pilotgruppe und zuletzt Turn it on right away. Die Aktionen eskalierst du parallel von Audit only über Block with override bis Block.

Wie hängen DLP und Labels mit Defender und SharePoint-Freigaben zusammen?

Sie ergänzen sich. Defender for Office 365 schützt vor Phishing und Schadsoftware von außen, die SharePoint- und OneDrive-Freigaben steuern, wer überhaupt Zugriff erhält. DLP und Labels setzen eine Ebene tiefer an: Sie verhindern, dass sensible Inhalte unkontrolliert abfließen, selbst wenn Zugriff besteht. Erst zusammen ergibt sich ein durchgängiger Schutz.

Wo finde ich Berichte zu Labels und DLP?

Berichte zu Vertraulichkeitslabels liegen im Purview-Portal unter Information Protection Reports, die DLP-Auswertungen unter Data Loss Prevention Reports. Detaillierte Aktivitäten siehst du im Activity Explorer und Content Explorer – diese beiden setzen allerdings E5 bzw. das IPG-Add-on voraus.

Fazit

Datenverlust in Microsoft 365 vermeidest du am wirksamsten mit der Kombination aus Vertraulichkeitslabels und DLP in Microsoft Purview. Labels klassifizieren, markieren und verschlüsseln Inhalte – der Schutz greift aber erst, nachdem du sie per Richtlinie veröffentlicht hast. DLP überwacht den Abfluss über Exchange, SharePoint, OneDrive, Teams und Endgeräte mit abgestuften Aktionen vom reinen Audit bis zur Blockade. Der Schlüssel zum reibungslosen Rollout ist der Simulationsmodus: erst beobachten, Treffer auswerten, dann stufenweise scharf schalten. Behalte die Lizenzgrenzen im Blick – manuelles Labeling und Basis-DLP gibt es in E3, Auto-Labeling, Endpoint und Teams brauchen E5. Wer so vorgeht, schützt vertrauliche Daten, ohne den Arbeitsalltag auszubremsen.

Weiterführende Anleitungen und Quellen

• SharePoint- und OneDrive-Freigaben für externe Gäste richtig steuern – DLP ergänzt die Freigabe-Einstellungen; beides zusammen verhindert ungewollten Datenabfluss.
• Defender for Office 365: Phishing-Schutz einrichten – schützt vor Angriffen von außen, während DLP und Labels den Abfluss von innen absichern.
• Microsoft 365: MFA und Conditional Access in Entra ID – die Zugriffsabsicherung als Fundament, auf dem Klassifizierung und DLP aufsetzen.
• Weitere Anleitungen in der Kategorie Microsoft 365

Quellen: Microsoft Learn – „Create and publish sensitivity labels“, „Create and deploy a data loss prevention policy“, „Learn about data loss prevention simulation mode“ sowie die „Microsoft Purview service description (Licensing)“.