Retention Policy vs. Retention Label: der Unterschied, an dem alle scheitern

Der Anruf kam vom SharePoint-Administrator, und er klang ratlos: Die Site der Buchhaltung meldete seit Wochen „Speicherkontingent fast erschöpft", obwohl das Team gerade eine große Aufräumaktion hinter sich hatte und mehrere hundert Gigabyte alter Dateien gelöscht worden waren. Je mehr gelöscht wurde, desto voller wurde die Site. Der Grund lag zwei Klicks tiefer, in einer versteckten Bibliothek namens Preservation Hold Library: Eine Aufbewahrungsrichtlinie mit zehn Jahren, die vor zwei Jahren jemand „für alle Sites" angelegt hatte, fing jede gelöschte Datei auf und behielt sie – unsichtbar für den Anwender, aber sehr sichtbar im Kontingent. Die Buchhaltung hatte gelöscht. Purview hatte aufbewahrt. Beide hatten recht.

Aufbewahren und Löschen sind in Microsoft Purview zwei Seiten einer Medaille, und beide werden mit zwei Werkzeugen gesteuert, die ähnlich heißen, ähnlich aussehen und grundverschieden wirken: der Retention Policy (Aufbewahrungsrichtlinie), die breit auf Speicherorte wirkt, und dem Retention Label (Aufbewahrungsbezeichnung), das gezielt an einem einzelnen Element hängt. Wer den Unterschied nicht sauber hält, baut Richtlinien, die Labels widersprechen, wundert sich über Speicherwachstum trotz Löschung, kann bei der Betriebsprüfung nicht sagen, warum ein Beleg noch da ist – oder warum er es nicht mehr ist. Und mit den vier Konfliktregeln, nach denen Purview entscheidet, wenn mehrere Fristen um dasselbe Dokument streiten, kommt eine Logik hinzu, die einfach ist, aber fast niemand kennt.

Dieser Artikel zieht die Trennlinie zwischen Richtlinie und Label, erklärt statische und adaptive Bereiche, führt durch die vier Konfliktregeln in ihrer festen Reihenfolge und zeigt den Lebensweg einer gelöschten Datei durch Papierkorb, Preservation Hold Library und Recoverable Items – samt der Missverständnisse, die daraus entstehen. Die konkreten deutschen Fristen (GoBD), das Löschkonzept nach DSGVO und Records Management haben eigene Spokes; hier geht es um das Fundament, auf dem sie stehen. Wo Aufbewahren und Löschen im Gesamtbild von Purview sitzen, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

Gießkanne und Pinzette: zwei Werkzeuge für dieselbe Aufgabe

Ich erkläre den Unterschied in Workshops seit Jahren mit demselben Bild, weil es hält: Die Retention Policy ist die Gießkanne, das Retention Label die Pinzette. Die Gießkanne wässert das ganze Beet – jede SharePoint-Site, jedes Postfach, jeden Teams-Kanal, den du ihr zuweist – gleichmäßig und ohne Ansehen des einzelnen Halms. Die Pinzette greift eine Pflanze und behandelt sie anders als den Rest. Beide gehören in denselben Schuppen, beide braucht man, und wer versucht, mit der Pinzette zu gießen oder mit der Gießkanne einzelne Halme zu setzen, wundert sich über das Ergebnis.

Die Retention Policy: breit, automatisch, unsichtbar

Eine Retention Policy sagt: „Alles, was in diesen Speicherorten liegt, wird so lange aufbewahrt und danach gelöscht" – oder nur aufbewahrt, oder nur gelöscht. Sie wird im Purview-Portal unter Data Lifecycle Management angelegt, bekommt Speicherorte zugewiesen (Exchange, SharePoint, OneDrive, Teams, Gruppen, Viva Engage), eine Frist mit Startpunkt (Erstellung oder letzte Änderung) und eine Aktion. Dann wirkt sie: rückwirkend auf alles, was schon da ist, und automatisch auf alles, was hinzukommt. Der Anwender merkt davon nichts – kein Symbol, kein Hinweis, keine Frage. Genau das ist ihre Stärke: Sie ist das Grundrauschen der Compliance. „Nichts geht verloren, bevor sieben Jahre um sind" und „nichts bleibt ewig, weil niemand aufräumt" lassen sich mit zwei Richtlinien für den ganzen Tenant erledigen. Und sie ist der einzige Weg für Teams-Chats und Kanalnachrichten, denn dort gibt es keine Labels. Ihre Schwäche ist ihre Blindheit: Sie unterscheidet nicht zwischen dem Buchungsbeleg und der Einladung zum Sommerfest, sie kann kein Element als Record deklarieren, sie kennt keine Prüfung vor der Löschung, und sie hinterlässt keinen Nachweis je Element.

Das Retention Label: gezielt, sichtbar, nachweisbar

Ein Retention Label hängt an einem Element und sagt: „Dieses Dokument ist ein Buchungsbeleg, acht Jahre ab Jahresende, danach Prüfung, dann Löschung." Es wird über Label-Richtlinien an Anwender veröffentlicht, die es manuell setzen; es kann als Standard an einer Bibliothek oder einem Ordner hängen; es kann automatisch anhand von Sensitive Info Types oder Klassifizierern angewendet werden (E5); und es kann ereignisbasiert starten – die Frist beginnt nicht bei Erstellung, sondern beim Vertragsende, beim Austritt des Mitarbeiters, bei der Stilllegung der Anlage. Es kann das Element als Record oder regulatorischen Record deklarieren und damit gegen Änderung und Löschung sperren; es kann vor der endgültigen Löschung eine Disposition Review verlangen, in der ein Mensch entscheidet; und es ist am Element sichtbar und im Content Explorer nachweisbar. Seine Grenze: Ein Element trägt genau ein Retention Label, Labels wirken nicht auf Teams-Nachrichten, und wer Labels als Regelfall für alle Inhalte einführt, hat in drei Monaten eine Belegschaft, die keine mehr setzt. Wie sich Retention Labels von Sensitivity Labels unterscheiden – Lebensdauer versus Schutz –, steht im Spoke zur Einführung von Sensitivity Labels; beide können am selben Dokument hängen, ohne sich zu stören.

Skizze 1: Gießkanne und Pinzette – Retention Policy für Speicherorte, Retention Label für einzelne Elemente; das Label gewinnt, wenn beide reden.

Die Tabelle stellt beide Werkzeuge nebeneinander. Die letzte Zeile ist die Faustregel aus Projekten: Richtlinie für den Regelfall, Label für den Sonderfall mit Nachweispflicht.

Statisch oder adaptiv: wie eine Richtlinie ihre Speicherorte findet

Eine Retention Policy braucht Speicherorte, und dafür gibt es zwei Wege, die sich in Pflegeaufwand und Lizenz unterscheiden. Ein statischer Bereich ist eine Liste: diese zwanzig SharePoint-Sites, diese Postfächer, diese Gruppen – oder schlicht „alle" für eine tenantweite Richtlinie. Das ist schnell gebaut und für den Anfang richtig; es hat aber zwei Haken. Listen mit benannten Orten haben Obergrenzen, und Listen veralten: Die neue Site der Buchhaltung ist nicht drin, der ausgeschiedene Kollege ist noch drin, die umbenannte Abteilung passt nicht mehr. Wer statische Bereiche einsetzt, braucht einen Pflegeprozess – oder er nimmt tenantweite Richtlinien und regelt Abweichungen über Labels.

Ein adaptiver Bereich ist eine Abfrage statt einer Liste: alle Benutzer mit Abteilung „Finanzen", alle Sites mit einer bestimmten Eigenschaft, alle Gruppen mit einem Namensmuster. Purview wertet die Abfrage regelmäßig neu aus – die neue Site der Buchhaltung ist automatisch drin, der Kollege, der aus der Personalabteilung wechselt, fällt automatisch aus der Personal-Richtlinie. Adaptive Bereiche brauchen E5, saubere Attribute in Entra ID und SharePoint und etwas Geduld beim ersten Aufbau. Ihr größter Nutzen zeigt sich beim Offboarding: Eine adaptive Richtlinie für ausscheidende Mitarbeiter, gesteuert über ein Attribut, das die Personalabteilung setzt, ist der eleganteste Weg, Postfächer und OneDrives beim Austritt in die Aufbewahrung zu übernehmen – wie das im Detail funktioniert, beschreibt der Spoke zu ausscheidenden Mitarbeitern.

Ein Detail, das in Konzepten oft untergeht, ist der Startpunkt der Frist. Eine Richtlinie kann ab Erstellung oder ab letzter Änderung rechnen, und der Unterschied ist bei lebenden Dokumenten gewaltig: Eine Vorlage, die jedes Jahr einmal angefasst wird, ist unter „sieben Jahre ab letzter Änderung" praktisch unsterblich – die Frist beginnt mit jeder Änderung neu –, unter „sieben Jahre ab Erstellung" ist sie irgendwann weg, obwohl sie noch benutzt wird. Für Ablagen mit abgeschlossenen Vorgängen ist „ab Erstellung" richtig, für Arbeitsbereiche „ab Änderung", und für Belege, deren Frist erst mit dem Jahresende oder Vertragsende beginnt, gibt es nur das ereignisbasierte Label. Wer den Startpunkt nicht bewusst wählt, hat entweder unsterbliche Vorlagen oder verschwindende Arbeitsdateien.

Die vier Konfliktregeln: was passiert, wenn mehrere Fristen um ein Dokument streiten

Spätestens wenn eine tenantweite Richtlinie, eine Site-Richtlinie und ein Label dasselbe Dokument betreffen, stellt sich die Frage, wer gewinnt. Purview beantwortet sie mit vier Regeln in fester Reihenfolge, und die Reihenfolge ist keine Konfiguration, sondern eingebaut. Wer sie kennt, kann jede Kombination vorhersagen; wer sie nicht kennt, baut Richtlinien, die sich gegenseitig aushebeln, und wundert sich, warum die Sieben-Jahres-Löschung nie greift.

Regel eins: Aufbewahren schlägt Löschen. Solange irgendeine Richtlinie oder ein Label sagt „behalten", wird das Element nicht gelöscht – egal, wie viele andere Regeln löschen wollen, und egal, ob ein Anwender oder Administrator es löscht. Regel zwei: Die längste Aufbewahrungsfrist gewinnt. Treffen mehrere Aufbewahrungen zusammen, bleibt das Element bis zum Ende der längsten. Regel drei: Explizit vor implizit. Bei gleicher Länge entscheidet die Nähe – ein Label am Element schlägt eine Richtlinie, eine Richtlinie mit benannter Site schlägt die tenantweite. Regel vier: Die kürzeste Löschfrist gewinnt – aber erst, wenn Regel eins bis drei abgearbeitet sind, also alle Aufbewahrungen abgelaufen. Dann greift die früheste Löschregel, nicht die späteste. Aus diesen vier Sätzen folgt alles Weitere: Eine Richtlinie „nach drei Jahren löschen" auf einer Site mit Label „zehn Jahre behalten" löscht das gelabelte Dokument nach zehn Jahren, nicht nach drei. Eine Richtlinie „sieben Jahre behalten" ohne Löschaktion löscht nie – auch nicht nach sieben Jahren.

Ein Sonderfall verdient eigene Aufmerksamkeit: Holds. Legal Hold auf einem Postfach und eDiscovery-Holds auf Postfächern und Sites stehen außerhalb der vier Regeln. Sie halten alles, was sie umfassen, solange sie bestehen – unabhängig davon, ob eine Frist abgelaufen ist, ob eine Löschrichtlinie greift, ob ein Anwender löscht. Das ist gewollt, denn ein Hold dient der Beweissicherung, nicht der Aufbewahrungslogik. Es hat aber eine Nebenwirkung, die in Löschkonzepten regelmäßig übersehen wird: Ein vergessener Hold aus einem Rechtsstreit von vor fünf Jahren blockiert die DSGVO-Löschung für ein ganzes Postfach, und niemand merkt es, weil Holds in keiner Retention-Übersicht auftauchen. Wer Löschfristen verspricht, muss seine Holds kennen.

Skizze 2: Die Entscheidungslogik bei Konflikten – vier Regeln in fester Reihenfolge und das Ergebnis für ein Beispieldokument.

Als Umsetzungshilfe die häufigsten Konfliktfälle mit dem Ergebnis, das Purview liefert. Die Spalte „Warum" nennt die greifende Regel; wer die Tabelle einmal mit den eigenen Richtlinien durchspielt, findet erfahrungsgemäß mindestens eine Überraschung.

Preservation Hold Library, Recoverable Items und die Missverständnisse, die daraus folgen

Die zweite Quelle für Verwirrung ist der Ort, an dem aufbewahrte Inhalte landen, wenn jemand sie löscht. Aus Sicht des Anwenders ist die Datei weg: aus der Bibliothek, aus dem Papierkorb, aus dem Postfach. Aus Sicht von Purview ist sie umgezogen. In SharePoint und OneDrive heißt der Ort Preservation Hold Library – eine versteckte Bibliothek je Site, in die gelöschte oder geänderte Inhalte unter Aufbewahrung kopiert werden, unsichtbar für Anwender, aber durchsuchbar für eDiscovery und mitgezählt im Speicherkontingent der Site. In Exchange ist es der Bereich Recoverable Items mit seinem Ordner für endgültig gelöschte Elemente, der unter Hold auf bis zu hundert Gigabyte wachsen kann. Erst wenn alle Fristen abgelaufen sind und kein Hold mehr besteht, räumt ein Zeitgeberauftrag auf – dann ist der Inhalt wirklich weg, nicht wiederherstellbar, nicht auffindbar.

Aus dieser Mechanik entstehen die drei Missverständnisse, die ich in Standortbestimmungen am häufigsten sehe. Erstens: „Wir haben gelöscht, warum ist der Speicher voll?" – weil die Preservation Hold Library zählt, und Sites mit hoher Änderungsrate und langer Aufbewahrung wachsen dort unsichtbar; wer jede Version einer täglich geänderten Excel-Datei sieben Jahre aufbewahrt, füllt Kontingente schneller, als er löschen kann. Zweitens: „Der Anwender hat es gelöscht, jetzt ist es weg" – nein, eDiscovery findet es, der Legal Hold hält es, und der Wirtschaftsprüfer bekommt es; wie Holds und Fristen zusammenspielen, beschreibt der Spoke zu Legal Hold in Microsoft 365. Drittens: „Purview löscht in Microsoft 365, also ist das Löschkonzept erledigt" – Purview löscht in Exchange, SharePoint, OneDrive und Teams, aber nicht im ERP, nicht im DMS, nicht auf dem Dateiserver; wer ein DSGVO-Löschkonzept baut, braucht Purview als einen Baustein unter mehreren, wie der Spoke zum Löschkonzept nach DSGVO zeigt.

Skizze 3: Der Lebensweg einer gelöschten Datei – Papierkorb, Preservation Hold Library beziehungsweise Recoverable Items, Fristablauf, endgültige Löschung.

Der Deutschland-Winkel: GoBD, DSGVO und die Verfahrensdokumentation

In Deutschland stehen sich beim Thema Aufbewahren und Löschen zwei Pflichten gegenüber, und Purview muss beide abbilden. Auf der einen Seite die Aufbewahrungspflichten aus HGB und AO – zehn Jahre für Bücher und Jahresabschlüsse, acht Jahre für Buchungsbelege, sechs Jahre für Handelsbriefe – mit der GoBD-Anforderung an Unveränderbarkeit und Nachvollziehbarkeit; das ist die Domäne der Retention Labels mit Record-Deklaration, denn nur sie können ein Element gegen Änderung sperren und die Löschung nachweisen. Auf der anderen Seite die Löschpflicht aus Art. 17 DSGVO und der Grundsatz der Speicherbegrenzung aus Art. 5: Personenbezogene Daten dürfen nicht länger vorgehalten werden, als der Zweck es verlangt – das ist die Domäne der Retention Policies mit echter Löschaktion. Und genau hier greift Regel eins in ihrer rechtlichen Bedeutung: Aufbewahren schlägt Löschen ist keine Willkür von Purview, sondern die technische Abbildung dessen, dass eine gesetzliche Aufbewahrungspflicht die Rechtsgrundlage für die weitere Speicherung liefert. Wer beides sauber trennt – Richtlinie für die Speicherbegrenzung, Label für die Aufbewahrungspflicht –, hat gegenüber Datenschutzbeauftragtem und Betriebsprüfer eine Argumentation, die trägt. Die konkreten Fristen behandelt der Spoke zur GoBD-Aufbewahrung in Microsoft 365, die Records-Seite der Spoke zu Records Management und Disposition Review.

Was in beiden Fällen nicht fehlen darf, ist die Verfahrensdokumentation: Welche Richtlinien und Labels gibt es, mit welchen Fristen, für welche Datenarten, wer hat sie beschlossen, wie werden Konflikte aufgelöst, wo landen gelöschte Inhalte, wer kann sie dort noch sehen. Die GoBD verlangen diese Dokumentation ausdrücklich, die DSGVO über die Rechenschaftspflicht ebenso, und der Betriebsrat interessiert sich vor allem für einen Punkt: dass die Preservation Hold Library und Recoverable Items keine Hintertür für die Auswertung längst gelöschter Mitarbeiterdaten werden – wer dort per eDiscovery sucht, tut das nach den Regeln der Betriebsvereinbarung. Wie immer: keine Rechtsberatung, Stand 2026 – Steuerberater, Datenschutzbeauftragter und Betriebsrat gehören an den Tisch, bevor die erste Richtlinie tenantweit wirkt.

Stolperfallen aus der Praxis

„Nur aufbewahren" ohne Löschaktion als Löschkonzept. Die Richtlinie sagt „7 Jahre behalten", und alle glauben, danach sei es weg. Ist es nicht. Aufbewahren und dann löschen – oder eine separate Löschrichtlinie.

Labels als Regelfall für alle Inhalte. Zwanzig Labels, Pflicht in jeder Bibliothek, und nach drei Monaten setzt niemand mehr eines. Richtlinie für die 95 Prozent, Label für die 5 Prozent mit Nachweispflicht.

Preservation Hold Library nicht in der Speicherplanung. Die Site wird durch Löschen voller, und niemand versteht warum. Sites mit hoher Änderungsrate und langer Frist im Blick behalten; Frist ab letzter Änderung statt ab Erstellung prüfen.

Statische Listen ohne Pflege. Die neue Site der Buchhaltung ist in keiner Richtlinie, der ausgeschiedene Kollege in dreien. Tenantweit plus Labels – oder adaptive Bereiche mit sauberen Attributen.

Teams-Chats sollen ein Label bekommen. Geht nicht. Teams-Nachrichten kennen nur Richtlinien, und die sind eigene Richtlinien mit eigenen Speicherorten – nicht die Exchange-Richtlinie.

Konfliktregeln erst nach dem Rollout durchgespielt. Die Sieben-Jahres-Löschung greift nie, weil irgendwo ein zehnjähriges Label liegt – oder ein vergessener Hold. Konstellationen vorher auf Papier durchrechnen, Holds inventarisieren.

Fazit: Gießkanne für den Regelfall, Pinzette für den Nachweis – und die vier Regeln im Kopf

Retention Policy und Retention Label sind kein Entweder-oder, sondern zwei Werkzeuge mit klarer Arbeitsteilung: Die Richtlinie sichert das Grundrauschen für alle Speicherorte, unsichtbar und automatisch; das Label behandelt den Sonderfall mit Nachweispflicht, sichtbar und prüfbar. Wer dazu die vier Konfliktregeln kennt – Aufbewahren schlägt Löschen, längste Frist, explizit vor implizit, dann kürzeste Löschfrist – und weiß, dass gelöschte Inhalte in der Preservation Hold Library weiterleben, kann jede Konstellation vorhersagen und jedem Prüfer erklären. Wo Aufbewahren und Löschen im Gesamtbild aus Labels, DLP und Copilot-Absicherung stehen, zeigt der Purview-Überblick.

Wenn du wissen willst, welche Richtlinien und Labels in deinem Tenant heute wirken, wo sie sich widersprechen und wie groß deine Preservation Hold Libraries inzwischen sind: Die Purview-Standortbestimmung liefert genau diese Inventur – kompakt, zum Festpreis, mit Konfliktanalyse und Aktionsplan.

FAQ: Häufige Fragen zu Retention Policy und Retention Label

Was ist der Unterschied zwischen einer Retention Policy und einem Retention Label?

Eine Retention Policy wirkt breit auf ganze Speicherorte – Postfächer, SharePoint-Sites, OneDrives, Teams-Chats – und legt für alle Inhalte dort fest, wie lange sie aufbewahrt und ob sie danach gelöscht werden; sie ist für Anwender unsichtbar. Ein Retention Label hängt an einem einzelnen Element, kann manuell, als Standard, automatisch oder ereignisbasiert gesetzt werden, kann das Element als Record deklarieren und eine Prüfung vor der Löschung verlangen. Bei Konflikten gewinnt das Label als explizite Zuweisung.

Brauche ich für Retention Policies und Labels Microsoft 365 E5?

Nein, nicht für den Einstieg: Retention Policies mit statischen Bereichen und manuell oder als Standard angewendete Retention Labels sind ab Microsoft 365 E3 enthalten. E5 oder E5 Compliance brauchst du für adaptive Bereiche, automatisch angewendete Labels (Auto-Apply), Disposition Review und Records Management (Stand 2026).

Was passiert, wenn eine Retention Policy und ein Retention Label dasselbe Dokument betreffen?

Purview wendet vier Regeln in fester Reihenfolge an: Aufbewahren schlägt Löschen; die längste Aufbewahrungsfrist gewinnt; bei gleicher Länge gilt explizit vor implizit, also das Label vor der Richtlinie; und erst wenn alle Aufbewahrungen abgelaufen sind, greift die kürzeste Löschfrist. Ein Label „10 Jahre behalten" auf einer Site mit Richtlinie „nach 3 Jahren löschen" führt also zur Löschung nach 10 Jahren, nicht nach 3.

Warum wird meine SharePoint-Site voller, obwohl wir Dateien löschen?

Weil unter einer Aufbewahrungsrichtlinie gelöschte oder geänderte Dateien in die Preservation Hold Library kopiert werden – eine versteckte Bibliothek der Site, die zum Speicherkontingent zählt, für Anwender unsichtbar ist und für eDiscovery durchsuchbar bleibt. Sie leert sich erst, wenn alle Fristen abgelaufen sind und kein Hold besteht. Sites mit hoher Änderungsrate und langer Aufbewahrung wachsen dort besonders schnell.

Löscht eine Retention Policy „7 Jahre aufbewahren" die Daten nach 7 Jahren automatisch?

Nur, wenn die Richtlinie die Aktion „aufbewahren und dann löschen" hat und keine andere Regel länger aufbewahrt. Eine Richtlinie mit „nur aufbewahren" verhindert sieben Jahre lang die Löschung und tut danach nichts mehr – die Inhalte bleiben, bis jemand löscht. Wer löschen will, muss löschen sagen, und muss prüfen, ob irgendwo ein Label, eine andere Richtlinie oder ein Hold länger hält.

Können Teams-Chats ein Retention Label bekommen?

Nein. Für Teams-Chats und Kanalnachrichten gibt es ausschließlich Retention Policies, und zwar eigene Richtlinien mit den Speicherorten Chats, Kanalnachrichten und private Kanäle – getrennt von den Exchange-Richtlinien. Retention Labels wirken auf Dokumente, E-Mails und Listenelemente, nicht auf Teams-Nachrichten.

Wo fange ich mit Retention in Microsoft 365 an?

Mit einer Inventur der bestehenden Richtlinien, Labels und Holds und einem Fristenkatalog mit Steuerberater und Datenschutzbeauftragtem. Dann eine tenantweite Richtlinie „aufbewahren und dann löschen" mit der längsten allgemeinen Frist, eine kürzere Teams-Richtlinie für Chats und ein Retention Label für den Sonderfall mit Nachweispflicht – meist den Buchungsbeleg – als Standard an den passenden Bibliotheken. Die Konfliktregeln vorher auf Papier durchspielen und die Preservation Hold Library in die Speicherplanung aufnehmen.