Data Loss Prevention in Microsoft Purview ist eines der wirkungsvollsten Werkzeuge gegen Datenverlust. Aber es ist auch eines der Werkzeuge, bei dem die häufigsten Konfigurationsfehler den größten Schaden anrichten — nicht im Sinne von Datenverlust, sondern im Sinne von Produktivitätsverlust und Nutzerakzeptanz. Ein schlecht konfiguriertes DLP-System wird zum Feind der Belegschaft statt zum Schutzschild.
In diesem Artikel beschreiben wir die zehn häufigsten Fehler, die wir in unseren Projekten sehen — und wie Sie sie vermeiden.
Fehler 1: Alle Richtlinien gleichzeitig im Enforcement-Modus starten
Der Klassiker. Ein Unternehmen definiert zehn DLP-Richtlinien und schaltet alle am selben Tag auf Blockierung. Am nächsten Morgen stehen 200 Support-Tickets in der Queue, weil Mitarbeitende keine E-Mails mehr versenden können, die Rechnungen mit IBANs enthalten.
Besser: Jede neue Richtlinie durchläuft drei Phasen: mindestens zwei Wochen im Testmodus (Audit Only, keine Nutzerinteraktion), dann zwei Wochen im Warn-Modus (Nutzer wird informiert, kann fortfahren), und erst dann Blockierung mit Override-Möglichkeit. Harte Blockierung ohne Override nur für die höchste Vertraulichkeitsstufe.
Fehler 2: Der 1-Treffer-Schwellenwert
Eine DLP-Richtlinie, die bei einem einzelnen Fund einer IBAN blockiert, legt den E-Mail-Verkehr lahm. Jede Rechnung, jede Bestellbestätigung, jeder Zahlungshinweis enthält mindestens eine IBAN. Das ist kein Sicherheitsvorfall — das ist Geschäftsalltag.
Besser: Unterscheiden Sie zwischen einzelnen Treffern und Massenabfluss. Einzelne IBANs in einer E-Mail erhalten eine Warnung. Fünf oder mehr IBANs in einem Anhang werden blockiert (mit Override). Zehn oder mehr IBANs werden hart blockiert — weil das ein starkes Signal für eine Kundenliste oder Datenbankexport ist.
Die genauen Schwellenwerte hängen von Ihrem Geschäftsmodell ab. Ein Lohnbüro arbeitet naturgemäß mit vielen IBANs — dort müssen die Schwellenwerte höher sein als in einer Marketing-Abteilung.
Fehler 3: Keine Ausnahmen für legitime Prozesse
DLP kennt keine Geschäftsprozesse. Die Richtlinie weiß nicht, dass die Personalabteilung jeden Monat eine Datei mit Sozialversicherungsnummern an die Lohnbuchhaltung schickt — und dass das völlig in Ordnung ist.
Besser: Identifizieren Sie vor der DLP-Einführung die fünf bis zehn wichtigsten Geschäftsprozesse, die regelmäßig sensible Daten enthalten. Definieren Sie Ausnahmen für diese Prozesse: Allowlists für bekannte Empfänger-Adressen, Ausnahmen für bestimmte SharePoint-Bibliotheken oder Ausnahmen für bestimmte Benutzergruppen (z.B. die Lohnbuchhaltung).
Fehler 4: DLP und Sensitivity Labels gleichzeitig einführen
Sensitivity Labels und DLP sind zwei verschiedene Systeme, die zusammenwirken. Wenn Sie beide gleichzeitig einführen und Probleme auftreten, wissen Sie nicht, welches System das Problem verursacht. Ist die E-Mail blockiert wegen der DLP-Richtlinie oder wegen des Sensitivity Labels? Liegt es am Informationstyp oder an der Verschlüsselung?
Besser: Erst Sensitivity Labels einführen und stabilisieren (vier bis acht Wochen). Dann DLP-Richtlinien aufbauend auf den Labels konfigurieren. Die Reihenfolge ist wichtig: Labels sind die Grundlage, DLP ist der Durchsetzungsmechanismus.
Fehler 5: Benutzerdefinierte Informationstypen ohne ausreichende Tests
Microsoft bietet über 300 vordefinierte sensible Informationstypen. Diese sind gut getestet und liefern akzeptable Erkennungsraten. Benutzerdefinierte Informationstypen — etwa für interne Projektnummern, Kundennummern oder Vertragskennungen — sind deutlich anfälliger für False Positives, weil die Muster oft nicht eindeutig genug sind.
Besser: Benutzerdefinierte Informationstypen immer zuerst im Testmodus über mindestens vier Wochen laufen lassen. Prüfen Sie die Trefferqualität im Activity Explorer. Eine False-Positive-Rate über 10 Prozent bedeutet, dass das Muster zu unspezifisch ist und nachgeschärft werden muss. Ergänzen Sie Kontextwörter, um die Erkennung zu verbessern — etwa "Projektnummer:" vor dem eigentlichen Muster.
Fehler 6: DLP-Benachrichtigungen ohne Kontext
Die Standard-Benachrichtigung in Purview DLP lautet sinngemäß: "Diese Aktion wurde aufgrund einer Organisationsrichtlinie blockiert." Das ist technisch korrekt und kommunikativ eine Katastrophe. Der Nutzer weiß nicht, was erkannt wurde, warum es blockiert ist und was er stattdessen tun kann.
Besser: Konfigurieren Sie aussagekräftige Benachrichtigungstexte für jede Richtlinie. Ein guter Text erklärt, welcher Inhalt erkannt wurde ("Ihr Dokument enthält Kreditkartennummern"), warum die Aktion blockiert ist ("Unsere Unternehmensrichtlinie verhindert den Versand von Zahlungsinformationen an externe Empfänger") und was der Nutzer tun kann ("Entfernen Sie die sensiblen Daten oder wenden Sie sich an Ihre Führungskraft für einen Override").
Fehler 7: Keine regelmäßige Auswertung der DLP-Berichte
DLP-Richtlinien erzeugen kontinuierlich Daten: Matches, Warnungen, Blockierungen, Overrides. Wenn niemand diese Daten auswertet, verpassen Sie zwei Dinge: echte Sicherheitsvorfälle, die aufgedeckt wurden, aber keine Aufmerksamkeit bekommen, und Richtlinien, die nachjustiert werden müssen, weil sich Geschäftsprozesse geändert haben.
Besser: Definieren Sie einen DLP-Review-Rhythmus. In den ersten vier Wochen wöchentlich, danach monatlich. Prüfen Sie die Anzahl der Matches pro Richtlinie, das Verhältnis von True Positives zu False Positives, die Anzahl der Overrides und deren Begründungen und ob neue Geschäftsprozesse Ausnahmen erfordern.
Fehler 8: Endpoint DLP ohne Gerätemanagement
Endpoint DLP erweitert den Schutz auf Endgeräte — USB-Kopien, lokale Dateiaktionen, Uploads in nicht genehmigte Cloud-Dienste. Aber Endpoint DLP setzt voraus, dass die Geräte in Microsoft Defender for Endpoint eingebunden sind. Ohne Gerätemanagement gibt es keine Endpoint-DLP-Durchsetzung.
Besser: Stellen Sie sicher, dass alle relevanten Geräte in Intune und Defender for Endpoint eingebunden sind, bevor Sie Endpoint DLP aktivieren. Starten Sie mit einer Pilotgruppe und definieren Sie klare Richtlinien für BYOD-Geräte — Endpoint DLP auf privaten Geräten ist datenschutzrechtlich heikel und erfordert eine explizite Regelung.
Fehler 9: Teams vergessen
Viele DLP-Konfigurationen konzentrieren sich auf E-Mail und SharePoint — und vergessen Microsoft Teams. Dabei ist Teams in vielen Unternehmen der Kanal, über den am meisten kommuniziert wird, auch sensible Informationen. Ein Mitarbeiter, der eine Kreditkartennummer nicht per E-Mail versenden kann, tippt sie einfach in den Teams-Chat.
Besser: Konfigurieren Sie DLP-Richtlinien explizit für Teams-Chat und Teams-Kanalnachrichten. Beachten Sie: DLP für Teams erfordert eine E5-Lizenz oder das E5-Compliance-Add-on. Wenn Sie E3 haben, ist Teams ein blinder Fleck — ein Argument für das gezielte E5-Upgrade.
Fehler 10: Den Betriebsrat nicht einbinden
Ja, dieser Punkt kommt in jedem unserer Artikel vor. Und ja, das ist Absicht. DLP protokolliert, wer wann versucht hat, sensible Daten zu versenden. Das kann als Leistungs- oder Verhaltensüberwachung interpretiert werden. Ohne Betriebsvereinbarung riskieren Sie nicht nur einen Konflikt mit dem Betriebsrat, sondern auch die rechtliche Verwertbarkeit der DLP-Daten im Ernstfall.
Besser: Binden Sie den Betriebsrat von Anfang an ein. Erklären Sie, was DLP tut und was nicht. Definieren Sie gemeinsam, welche Daten wie lange gespeichert werden und wer Zugriff hat. Eine Betriebsvereinbarung schafft Rechtssicherheit — für das Unternehmen und für die Mitarbeitenden.
Bonus: Der Fehler, den fast jeder macht
Es gibt einen Fehler, der so häufig vorkommt, dass er fast universell ist: DLP als IT-Projekt behandeln. DLP ist kein IT-Projekt. Es ist ein Business-Projekt mit technischer Umsetzung. Die IT konfiguriert die Richtlinien, aber die Entscheidung, welche Daten geschützt werden müssen und wie strikt, muss vom Business kommen.
Wenn die IT allein entscheidet, was "sensibel" ist, entstehen Richtlinien, die entweder zu lasch sind (weil die IT die geschäftliche Bedeutung bestimmter Daten nicht kennt) oder zu strikt (weil die IT auf Nummer sicher geht und alles blockiert). Beides führt zu Problemen.
Die Lösung: Ein DLP-Steering-Committee mit Vertretern aus IT, Compliance, Recht, HR und den wichtigsten Fachabteilungen. Das klingt nach Overhead, spart aber Iterationsschleifen und Nacharbeit.
Fazit
DLP in Microsoft Purview funktioniert — wenn es richtig konfiguriert ist. Die Technik ist ausgereift, die Erkennungsraten sind gut, und die Integration in Microsoft 365 ist nahtlos. Die meisten Probleme entstehen nicht durch technische Limitierungen, sondern durch organisatorische und kommunikative Fehler.
Die wichtigste Regel: Schrittweise einführen, kontinuierlich optimieren und immer die Nutzer im Blick behalten. Ein DLP-System, das die Produktivität nicht einschränkt und das von den Mitarbeitenden verstanden wird, ist ein DLP-System, das funktioniert.