In meinen Azure- und Microsoft-365-Kursen stoßen wir regelmäßig auf dasselbe Muster: Unternehmen haben Microsoft 365 im Einsatz, zahlen für Lizenzen, die Compliance-Funktionen einschließen und nutzen davon schlicht nichts. DLP (Data Loss Prevention), bzw. „Verhinderung von Datenverlust“ und „Retention Policies“ (Aufbewahrungsrichtlinien) schlummern ungenutzt im Microsoft Purview Compliance Portal. Das ist kein Nischenthema: Wer personenbezogene Daten verarbeitet, DSGVO-konform arbeiten muss oder in einer regulierten Branche tätig ist, kommt an diesen beiden Werkzeugen nicht vorbei.
Microsoft hat unter dem Markennamen „Microsoft Purview“ mehrere früher getrennte Produkte zusammengeführt: das ehemalige „Microsoft 365 Compliance Center“, „Azure Purview“ (Datenkatalog) und Teile von „Azure Information Protection“. Für den Alltag in kleinen und mittelständischen Unternehmen war/ist vor allem das Purview Compliance Portal relevant, erreichbar unter compliance.microsoft.com. Der Link ist zwar noch live, leitet aber automatisch auf das neue vereinheitlichte Purview-Portal purview.microsoft.com um. Ein Rückwechsel zum alten Compliance-Portal ist derzeit noch möglich.
Bedenken Sie aber, dass einige Purview Features, wie z. B. „Data Map“ und „Data Catalog“ über die entsprechende Azure-Nutzung bezahlt werden, weshalb hierzu eine entsprechende Azure Subscription und ein Purview-Account erforderlich sind, während die hier skizzierten Funktionen aus dem Compliance Bereich über den zugehörigen M365-Plan lizenziert werden (z. B. E3 für „Datenlebenszyklus Verwaltung“ oder E5 für „Datensatzverwaltung“).
Was ist das Purview Compliance?
Im ehemaligen Compliance-Portal finden Sie ausschließen für M365 relevante Compliance-Funktionen. Diese sind aber selbstverständlich auch im Purview-Portal zu finden:
- Data Loss Prevention (DLP): Richtlinien, die das unbeabsichtigte oder unautorisierte Teilen sensibler Daten verhindern.
- Retention Policies & Retention Labels: Regeln, wie lange Daten aufbewahrt oder wann sie gelöscht werden müssen.
- Sensitivity Labels: Klassifizierungs- und Schutzbezeichnungen für Dokumente und E-Mails.
- Compliance Manager: Dashboards für Compliance-Bewertungen gegenüber Standards wie ISO 27001 oder DSGVO.
Für diesen Artikel konzentrieren wir uns auf DLP und Retention , die beiden Bereiche, bei denen in der Praxis der größte Nachholbedarf besteht.
Das Purview Compliance Portal fasst Compliance-Werkzeuge unter einer einheitlichen Oberfläche zusammen.
Sie können aber übrigens zur Zeit noch mit den Schiebe-Regler „Neues Microsoft Purview Portal“ zum alten klassischen Compliance-Portal zurück wechseln.
Data Loss Prevention (DLP): Grundprinzip und Einstieg
Eine DLP-Richtlinie überwacht Inhalte in definierten Microsoft-365-Diensten, wie Exchange Online, SharePoint Online, OneDrive, Teams, Endpoint-Geräte und greift ein, wenn bestimmte „sensitive information types“ (vordefinierte Erkennungsmuster für z. B. IBAN, Sozialversicherungsnummern, Kreditkartennummern) erkannt werden.
Ich hatte mich in diesem Zusammenhang einmal mit einem Kunden aus dem Gesundheitswesen auseinandergesetzt, bei dem Patientendaten per Teams-Chat an externe Empfänger weitergeleitet wurden. Dies geschah völlig unbeabsichtigt, weil der betreffende Mitarbeiter nicht wusste, dass sein Chat-Kontakt extern war. Genau solche Szenarien adressiert DLP.
Praxistipp: Starten Sie keine DLP-Richtlinie sofort im Enforce-Modus (erzwingen). Beginnen Sie immer mit dem Modus Simulate (Simulation) oder Audit, um zuerst zu verstehen, wie viele Treffer Ihre Richtlinie in der realen Umgebung erzeugt – bevor Sie produktiven Betrieb blockieren.
Der Aufbau einer DLP-Richtlinie folgt immer demselben Schema:
- Locations: Wo soll die Richtlinie greifen? (Exchange, SharePoint, OneDrive, Teams, Endpoints)
- Conditions: Was soll erkannt werden? (sensitive information types, Sensitivity Labels, Schlüsselwörter)
- Actions: Was passiert bei einem Treffer? (Blockieren, Benachrichtigung, Policy Tip für den Endnutzer)
Für den Einstieg empfehle ich, mit einem der mitgelieferten Templates zu beginnen, etwa „Germany Financial Data“ oder „General Data Protection Regulation“ (GDPR). Diese decken die häufigsten regulatorischen Anforderungen ab, ohne dass Sie Erkennungsmuster von Grund auf selbst definieren müssen. In meinen Azure-Kursen mit Microsoft-365-Compliance-Fokus passen wir solche Templates auch auf reale Unternehmensszenarien an.
Retention Policies: Aufbewahren und Löschen nach Plan
Retention Policies regeln, was mit Inhalten passiert, wenn eine definierte Zeitspanne abgelaufen ist. Das klingt simpel, ist aber in der Tiefe komplex – weil sich zwei Grundrichtungen unterscheiden:
| Szenario | Retention Action | Typischer Anwendungsfall |
|---|---|---|
| Daten müssen mindestens X Jahre aufbewahrt werden | Retain (aufbewahren) | Steuerrelevante Unterlagen (GoBD: 10 Jahre), HR-Akten |
| Daten dürfen maximal X Jahre gespeichert bleiben | Delete (löschen) | DSGVO-Anforderungen, Bewerbungsunterlagen (6 Monate) |
| Daten aufbewahren, dann automatisch löschen | Retain then Delete | E-Mail-Kommunikation mit Kunden (3 Jahre, dann Löschung) |
Technisch gibt es zwei Wege, Retention-Regeln durchzusetzen:
- Retention Policy: Wirkt automatisch und breit auf ganze Dienste oder Postfächer – ohne dass Endnutzer etwas tun müssen.
- Retention Labels: Werden manuell oder automatisch auf einzelne Dokumente oder E-Mails angewendet und können feingranularere Regeln tragen.
Merksatz: Eine Retention Policy wirkt wie ein Netz, das alles auffängt. Ein Retention Label ist wie ein Etikett auf dem einzelnen Dokument und gewinnt im Konfliktfall gegenüber der Policy, wenn es eine längere Aufbewahrungsdauer vorschreibt.
Ein wichtiger Punkt, den viele übersehen: Inhalte, die einer Retention Policy unterliegen, werden nicht sofort gelöscht. Sie – sie landen zunächst in einem versteckten Container (im Fall von SharePoint: der Preservation Hold Library, bei Exchange: dem Recoverable Items-Ordner). Das schützt vor versehentlichem oder mutwilligem Löschen während der Aufbewahrungsphase.
DLP vs. Retention: Abgrenzung und Zusammenspiel
| Kriterium | DLP | Retention Policy |
|---|---|---|
| Primäres Ziel | Verhindern, dass Daten das Unternehmen (unkontrolliert) verlassen | Sicherstellen, dass Daten lang genug vorhanden – oder rechtzeitig weg – sind |
| Auslöser | Aktion eines Nutzers (Senden, Teilen, Hochladen) | Zeitablauf (seit Erstellung, Änderung oder Bezeichnung) |
| Sichtbar für Endnutzer? | Ja – Policy Tips erscheinen direkt im Client | Nein – wirkt im Hintergrund (außer bei manuellen Labels) |
| Lizenzanforderung (Minimum) | Microsoft 365 E3 / Business Premium | Microsoft 365 E3 / Business Premium |
| Typische Compliance-Norm | DSGVO, HIPAA, PCI-DSS | GoBD, DSGVO, branchenspezifische Archivierungspflichten |
Beide Werkzeuge ergänzen sich: DLP schützt Daten im Bewegungszustand, Retention Policies regeln den Lebenszyklus ruhender Daten. Erst zusammen entsteht ein durchgängiges Compliance-Fundament.
Praxisempfehlung: KMU-taugliche Startstruktur
Schritt 1 – Bestandsaufnahme: Welche Daten verarbeiten Sie? Personenbezogene Daten, Finanzdaten, Gesundheitsdaten? Daraus leitet sich ab, welche DLP-Templates und welche Aufbewahrungsfristen relevant sind.
Schritt 2 – DLP im Audit-Modus: Aktivieren Sie die DSGVO-DLP-Vorlage für Exchange, SharePoint und Teams zunächst im Simulationsmodus. Werten Sie nach zwei Wochen den Aktivitäten-Explorer aus.
Schritt 3 – Retention Policy für E-Mail: Erstellen Sie eine einfache Policy für Exchange Online: E-Mails 3 Jahre aufbewahren, dann löschen. Das deckt einen großen Teil alltäglicher Compliance-Anforderungen ab.
Schritt 4 – Retention Label für kritische Dokumente: Erstellen Sie ein Label „GoBD-pflichtig“ mit 10-jähriger Aufbewahrung und publizieren Sie es für SharePoint-Bibliotheken, in denen steuerrelevante Dokumente liegen.
Schritt 5 – Review-Zyklus: Planen Sie halbjährliche Reviews im Compliance Manager, um Drifteffekte (neue Dienste, neue Datentypen) zu erkennen.
Das ist kein Hexenwerk – aber es erfordert, dass jemand im Unternehmen die Verantwortung übernimmt und die Werkzeuge kennt. Wenn Sie das fundiert aufbauen wollen, finden Sie strukturierte Kursinhalte zu Microsoft 365 Compliance und Purview in meinen Azure-Kursen. Der erste sinnvolle Schritt ist oft: einfach das Portal öffnen, eine Simulation starten – und schauen, was die eigene Umgebung produziert.
Achtung: In Microsoft Purview gibt es einen klaren grundsätzlichen Unterschied zwischen den Funktionen „Datenlebenszyklusverwaltung“ (Data Lifecycle Management, DLM) und „Datensatzverwaltung“ (Records Management, RM). Die Datenlebenszyklusverwaltung (DLM) hat wie Wie beschrieben zunächst das grundsätzliche Ziel, Daten die man braucht zu behalten und Daten zu löschen, die man nicht braucht. Die Funktion dient einer breiten, automatisierten Governance von Inhalten in Microsoft 365 (Exchange, SharePoint, OneDrive, Teams etc.). Die Hauptinstrumente hier sind : Typische Anwendungsfälle sind Allgemeine Compliance, Reduzierung von ROT (Redundant, Obsolete, Trivial) oder Risikominderung durch Löschung unnötiger Daten. Allerdings gibt es hier keine strengen Unveränderlichkeits-Regeln für die Inhalte (außer der eigentlichen Aufbewahrungs-/Löschlogik). Die Datensatzverwaltung (Records Management, RM) hat das Ziel, der Verwaltung hochwertiger, geschäftskritischer, rechtlich oder regulatorisch relevanter Datensätze mit Nachweisbarkeit („Prove It“). Sie baut zwar auf DLM auf, geht aber deutlich weiter und bringt folgende zusätzliche Funktionen mit:
Simulation-Modus
Den skizzierten Simulationsmodus gibt es übrigens nicht nur für DLP, sondern zum Beispiel auch für Auto-Labeling-Policies und zwar sowohl für „Sensitivity Labels“ als auch für „Retention Labels“ in der Datenlebenszyklusverwaltung / Datensatzverwaltung).
Beim Erstellen oder Bearbeiten einer solchen Policy gibt es am Ende immer den Schritt „Simulate or turn on the policy“ (bzw. „Richtlinie im Simulationsmodus ausführen“). Hier konfigurieren Sie dann, welche Inhalte (z. B. basierend auf SITs, Keywords, Eigenschaften) mit welchem Label versehen werden sollen. Die Simulation „scannt“ dann Ihre Umgebung (SharePoint, OneDrive, Exchange etc.), ohne tatsächlich Labels anzuwenden.
Sie erhalten aber danach ein Dashboard mit „Übersicht“, welche Inhalte getroffen worden wären. Das ist extrem nützlich, um den Impact abzuschätzen, bevor Sie die Policy scharf schalten
💡 Tipp: Sie möchten SC-400 professionell lernen? Ich biete den offiziellen Microsoft-Kurs SC-400 (Microsoft Information Protection Administrator) als Online- oder Präsenz-Training an. → Zum Kurs SC-400