BLOG

Worum geht’s in diesem Post?

Wenn du neu in der Welt von Microsoft Purview Retention Policies bist, bist du hier genau richtig. In diesem Beitrag gebe ich dir einen kompakten Überblick darüber, was Retention Policies sind, warum sie wichtig sind, und wie du deine erste Policy einrichtest.
Ich gehe bewusst nicht auf jede technische Option im Detail ein – das würde den Rahmen sprengen. Stattdessen ist dieser Post als Einstieg gedacht. Ich plane weitere Beiträge, in denen ich einzelne Aspekte wie Adaptive Scopes, oder Retention für Copilot Interaktionen vertiefe.

Warum Retention Policies heute wichtiger sind denn je

Daten sind das neue Fundament digitaler Arbeit, und mit wachsender Geschwindigkeit nimmt die Datenflut in Microsoft 365 kontinuierlich zu. Gleichzeitig steigen die Anforderungen von Datenschutz, Informationssicherheit und Compliance.

Retention Policies in Microsoft Purview helfen dabei, strukturiert zu entscheiden, wie lange bestimmte Inhalte aufbewahrt und wann sie gelöscht werden sollen. Ziel ist es, regulatorische Anforderungen zu erfüllen, Datenverlust zu vermeiden und gleichzeitig unnötige Altlasten zu minimieren.

Besonders wichtig: Retention Policies wirken nicht nur präventiv – sie sind ein strategisches Werkzeug, um Transparenz über Informationslebenszyklen zu schaffen und Kontrollmechanismen zu etablieren. Ob es um DSGVO, GoBD oder unternehmensinterne Vorgaben geht; wer seine Datenflüsse versteht, kann Risiken gezielter steuern.

Dieser Beitrag richtet sich an alle, die mit Microsoft Purview den Einstieg wagen wollen; verständlich erklärt, mit konkreten Tipps und vermeidbaren Stolperfallen im Gepäck.

Was genau machen Retention Policies?

Retention Policies in Microsoft Purview helfen dabei, Lebenszyklen von Daten zu definieren. Sie bestimmen:

• wie lange Inhalte aufbewahrt werden sollen (Retention)
• wann Inhalte automatisch gelöscht werden dürfen (Deletion)
• ob Inhalte nach einer gewissen Zeit überprüft werden müssen

Beides kann kombiniert werden: Inhalte können z. B. für 5 Jahre aufbewahrt und danach automatisch gelöscht werden.

Retention Policies wirken auf Speicherorte

Wird ein Element an einen anderen Speicherort verschoben, der nicht von der ursprünglichen Policy abgedeckt ist, verliert es den Schutz der Policy.

Wo kommen Retention Policies zum Einsatz?

Typische Anwendungsfälle sind:

• Aufbewahrung von E-Mails zur Nachvollziehbarkeit
• Verhinderung von Datengräbern in SharePoint
• Einhaltung notwendiger Speicherfristen für Geschäftsdaten
• Umsetzung von Löschpflichten nach DSGVO (z. B. Bewerbungen)

Je nach Branche und Region unterscheiden sich regulatorische Spielräume. Was hier gilt, kann dort bereits ein Risiko sein. Retention Policies helfen, diese Anforderungen konkret umzusetzen – und das mit möglichst geringem manuellem Aufwand.

Planung von Retention Policies

Bevor du mit der Einrichtung loslegst, solltest du dir ein paar Fragen stellen:

• Welche Daten sind kritisch?
• Wo liegen diese Daten?
• Welche regulatorischen Vorgaben gelten?
• Wer ist für die Einhaltung verantwortlich?

Erstelle am besten eine Policy-Matrix, die Speicherorte, Fristen und Verantwortlichkeiten verknüpft.

Falls du zum Sammeln der Anforderungen einen Startpunkt brauchst, findest du meistens in den Abteilungen HR, Legal oder Finance die richtigen Ansprechpartner

So wirken Retention Policies technisch

Wenn eine Retention Policy aktiv ist, passiert folgendes:

• Bei „Retain“-Einstellungen: Gelöschte Inhalte werden in versteckten Bereichen gehalten (z.B. Preservation Hold Library in SharePoint/OneDrive oder Recoverable Items Folder in Exchange). Für die User sind diese Inhalte nicht mehr sichtbar, aber Admins und eDiscovery können weiterhin darauf zugreifen.

• Bei „Delete Only“-Einstellungen: Inhalte können durch User gelöscht werden, werden aber am Ende des definierten Zeitraums automatisch gelöscht, falls sie noch existieren.
• Bei „Retain and Delete“-Einstellungen: Inhalte werden während der Aufbewahrungsfrist geschützt und danach automatisch entfernt.

Retention Policies ersetzen kein Backup!

Retention Policies sorgen für Compliance-gerechte Aufbewahrung oder Löschung. Sie bieten aber keinen Schutz vor Datenverlust durch technische Fehler oder Benutzerfehler. Ein vollständiges Backup bleibt unverzichtbar.

Optionen für das Scoping von Retention Policies

Nicht jede Policy wirkt für alle gleich. Du kannst definieren, ob sie für bestimmte User, Gruppen oder Speicherorte gelten soll. Hier unterscheidet Microsoft zwischen zwei Scoping-Typen:

Static Scopes

Bei Static Scopes gibst du genau an, für wen oder was die Richtlinie gilt:

• Bestimmte User oder Gruppen (z.B. für Emails in persönlichen Postfächern, Inhalte in Teams oder Dateien in OneDrive-Accounts)
• Einzelne Speicherorte (z. B. für Dokumente in SharePoint-Sites oder Viva Engage Communities)
• Alle Speicherorte eines Typs (z.B. alle SharePoint Sites), optional mit einzelnen Ausnahmen

Adaptive Scopes

Adaptive Scopes arbeiten regelbasiert. Sie setzen Filter ein, um Richtlinien automatisch z. B. auf alle User mit der Abteilung „Vertrieb“ oder alle SharePoint-Sites eines Standortes anzuwenden, ohne dass man diese manuell zuweisen muss.

Wie immer, wenn es um Automatisierung oder dynamische Scoping geht, braucht man hierfür allerdings E5 oder ein equivalentes Lizensierungslevel.

So richtest du eine Retention Policy richtig ein

1. Melde dich im Microsoft Purview Portal an: purview.microsoft.com
2. Navigiere zu Solutions > Data Lifecycle Management > Policies > Retention Policies.
3. Klicke auf „New retention policy“ und vergebe einen Namen sowie eine Beschreibung. (Namen und Beschreibung bekommen die User übrigens nirgendwo zu Gesicht, sie dienen den Admins als Orientierung.)
4. Wähle eine passende Admin Unit für die Policy aus (falls du keine Admin Units verwendest, oder die Policy global zur Verfügung stehen soll, kannst diesen Punkt überspringen..
5. Lege fest, ob du die Policy mit Static Scope oder Adaptive Scope erstellen möchtest.

• Wenn du hier „Adaptive“ auswählst, kannst du eines der Adaptive Scope wählen, die für denen Tenant konfiguriert sind, oder eines erstellen.
• Wenn du „Static“ auswählst, kannst du die konkreten Sites, Mailboxen, etc. auswählen, auf die die Policy gelten soll.

• Standardmäßig sind hier alle Mailboxen, Sites, OneDrives und Groups ausgewählt. Wähle zwischen „alle einschließen mit Ausnahmen“ und „nur bestimmte Speicherorte einschließen“, je nach Szenario.
• Wenn du SharePoint Sites oder OneDrives auswählen möchtest, braucht du die komplette Adresse der jeweiligen Site.
• Manche locations kann man nicht kombinieren. Teams Chats z.B. können nicht in der gleichen Policy konfiguriert werden, wie SharePoint Sites. Das merkt man aber sehr schnell, wenn die SharePoint Sites einfach rausfliegen, sobald man Teams auswählt…

6. Definiere die Einstellungen der Policy

• Du kannst zwischen Retention (für eine bestimmte Zeit oder für immer) und Deletion wählen.
• Bei Retention kannst du wählen, was am Ende des Aufbewahrungszeitraums passieren soll (löschen oder nichs weiter).
• Wichtige Konfiguration hier: Wann läuft die Uhr los? Ab Erstellung des Elements oder ab der letzen Änderung?

7. Zum Schluss bekommst du noch mal eine Übersicht über deine Konfiguration und kannst die Policy erstellen.

Gut Ding will Weile haben.

Bei den Compliance Features braucht man eines immer: Kaffee Geduld
Ab der Erstellung der Policy kann es bis zu einer Woche dauern, bis sie auf die Elemente wirkt. Wenn deine Compliance Abteilung also morgen eine wirksame Policy sehen möchte, wirst du sie enttäuschen müssen.

Entscheidungslogik bei mehreren Policies

Du kannst mehrere Policies erstellen, die auf den gleichen Speicherort gescoped sind, so, dass z.B. eine SharePoint Site oder eine Exchange Mailbox in verschiedenen Policies als Ziel konfiguriert sind. In diesem Fall wirken alle aktiven Retention Policies auf die Elemente im Speicherort.

Damit es nicht zur Verwirrung kommt, wenn mehrere Retention Policies ein Objekt wirken, greift eine feste Entscheidungslogik. Diese 4 Schritte werden immer in genau dieser Reihenfolge ausgewertet:

1. Retention gewinnt vor Deletion: Wenn eine Policy Retention vorschreibt, kann eine andere Policy nicht das frühere Löschen des Elements erzwingen.
2. Längere Retention gewinnt: Wenn mehrere Retention Policies gelten, bleibt das Element so lange erhalten, wie es die längste Frist vorschreibt.
3. Kürze Löschfrist gewinnt: Wenn mehrere Löschfristen gelten, wird die kürzeste durchgesetzt.
4. Explizite Löschung gewinnt über implizite Löschung: Wenn explizit ein Ablaufdatum definiert ist, wird es vor allgemeinen Regeln angewendet.

Wichtige Hinweise und Stolperfallen

• Keine Retention ohne Planung: unbedacht gesetzte Policies können Inhalte unnötig lange speichern oder zu früh löschen
• Granularität planen: Lieber mehrere gezielte Policies als eine „One-size-fits-all“-Policy.
• Klein anfangen: Policies zuerst im kleinen Rahmen testen, bevor sie global wirken. Policies mit langen Aufbewahrungszeiträumen wie „löschen nach 7 Jahren“ lassen sich naturgemäß schwer kurzfristig testen. Hier hilft es, ähnliche Policies mit sehr kurzen Fristen (z.B. in Tagen statt Jahren) zu erstellen, um das Verhalten zu überprüfen.
• Vorsicht bei der Migration in Speicherorte mit aktiver Retention Policy: Beim Verschieben oder Importieren alter Daten kann es passieren, dass Dokumente sofort als löschreif erkannt und entfernt werden. Hier ist besondere Vorsicht geboten.
• Vermeide es, einfach alle Daten pauschal für x Jahre aufzubewahren: Das verursacht unnötige Kosten und Risiken.

Fazit: Retention als strategisches Werkzeug

Retention Policies sind weit mehr als nur ein Compliance-Korsett. Richtig eingesetzt helfen sie dabei, Datenbestände effizient zu verwalten, regulatorische Anforderungen zu erfüllen und Risiken zu minimieren. Wer frühzeitig plant und regelmäßig überprüft, behält die Kontrolle

Am Ball bleiben!

Überprüfe regelmäßig, ob deine Retention Policies noch zu den aktuellen regulatorischen Anforderungen, Geschäftsprozessen und Speicherorten passen. Systeme, Nutzer und gesetzliche Vorgaben ändern sich – deine Richtlinien sollten es auch.

Best Practices für Einsteiger

• Starte klein und iterativ
• Dokumentiere alle Richtlinien sauber
• Erstelle eine Scoping-Matrix als visuelle Hilfe
• Plane Policies in enger Abstimmung mit den Fachabteilungen
• Nutze Test-User und -Sites für erste Gehversuche
• Plane die Migration in Speicherorte mit aktiver Retention Policy sorgfältig, um unerwartete Löschungen zu vermeiden
• Vermeide pauschale Langzeitaufbewahrungen ohne klaren Bedarf.

Lizenzen

Zum Abschluss noch, wie könnte es anders sein, ein kurzer Block zum Thema Lizensierung:

• Retention Policies sind im Allgemeinen in E3 oder Business Premium enthalten
• Für Adaptive Scopes braucht man E5 Lizenzen
• Will man Retention auf Copilot-Interaktionen konfigurieren, braucht man natürlich die entsprechenden Copilot Lizenzen (zusätzlich zur E5)
• Mehr Details findest du hier: Microsoft 365 guidance for security & compliance

Dieser Post wurde initial hier veröffentlich: consideritman.com