Retention Policies in Microsoft 365 – was sie tun, nicht tun und wo gelöschte Daten landen

Retention Policies bzw. Aufbewahrungsrichtlinien in Microsoft 365 werden oft mit Archivierung, Revisionssicherheit oder „automatischer Compliance“ gleichgesetzt. Genau darin liegt eines der größten Missverständnisse.

Eine Retention Policy ist kein klassisches Archiv, kein Dokumentenmanagementsystem und auch keine magische Schicht, die Daten automatisch fachlich richtig einordnet. Sie ist vor allem ein technischer Mechanismus, der verhindert, dass Inhalte vor Ablauf einer definierten Frist endgültig verschwinden.

Das klingt zunächst simpel. In der Praxis ist die Wirkung aber weitreichend: Benutzer können weiter ganz normal löschen, im Frontend sieht alles wie gewohnt aus, und dennoch bleiben Inhalte im Hintergrund in versteckten Speicherorten erhalten. Erst dort zeigt sich, wie Microsoft 365 Retention tatsächlich versteht: als Mindestaufbewahrung auf Plattformebene, nicht als sichtbares Benutzerarchiv.

Wer Retention Policies einführt, sollte deshalb genau wissen, was technisch passiert, wo die Inhalte landen, wie man später wieder auf sie zugreift und welche operativen Nebenwirkungen entstehen können. Denn Retention schützt zuverlässig vor vorzeitiger Löschung – sie schützt aber nicht automatisch vor schlechter Informationsarchitektur, wachsenden Speicherbereichen, unsauberen Löschkonzepten oder falschen Erwartungen im Prüfungsfall.

Merke: Retention verhindert endgültige digitale Vernichtung, nicht das reguläre Löschen im Frontend

Der vielleicht wichtigste Satz lautet: Eine Retention Policy verhindert nicht, dass Nutzer Inhalte löschen. Sie verhindert nur, dass diese Inhalte innerhalb der Aufbewahrungsfrist endgültig vernichtet werden.

Das ist ein entscheidender Unterschied. Aus Sicht eines Anwenders verschwindet eine gelöschte E-Mail, Datei oder Teams-Nachricht durchaus ganz normal aus der Oberfläche. Aus Sicht der Plattform wird dieses Objekt aber – sofern eine passende Retention greift – in geschützten Bereichen weiter vorgehalten. Der Benutzer erlebt also einen regulären Löschvorgang, Microsoft 365 führt intern jedoch nur einen kontrollierten Sichtbarkeitswechsel durch.

Gerade deshalb kommt es so oft zu Fehlannahmen. Fachbereiche sagen dann, ein Benutzer habe etwas „endgültig gelöscht“, obwohl das aus Compliance-Sicht gar nicht stimmt. Umgekehrt wird Retention manchmal als aktives Archiv missverstanden, obwohl der Benutzer die so geschützten Daten im Alltag meist gerade nicht mehr sieht.

Was Retention Policies tatsächlich leisten

Eine Retention Policy legt fest, dass Inhalte in einem bestimmten Scope – etwa Exchange, SharePoint, OneDrive oder Teams – für eine definierte Dauer aufbewahrt werden müssen. Je nach Konfiguration kann nach Ablauf der Frist zusätzlich eine Löschung ausgelöst werden oder eben gerade nicht.

Das klingt robust – und ist es auch. Aber es ist nur eine Seite der Medaille.

Was Retention Policies nicht leisten

Viele Probleme entstehen nicht durch die Funktion selbst, sondern durch falsche Erwartungen an sie. Retention ist nicht gleich Archivierung, nicht gleich Klassifikation, nicht gleich Unveränderbarkeit und schon gar nicht automatisch gleich GoBD-konformes Gesamtkonzept.

Genau deshalb sollte man eine Retention Policy nie isoliert betrachten. Sie ist ein Baustein in einer Governance- und Compliance-Architektur, aber nicht deren vollständiger Ersatz.

Wie sich Löschen ohne aktive Retention verhält

Um die Wirkung einer aktiven Policy zu verstehen, lohnt sich zuerst der Blick auf den Normalfall ohne Retention. Denn nur dann wird sichtbar, an welchen Stellen Microsoft 365 Inhalte tatsächlich vernichten würde.

Nehmen wir zunächst Exchange. Wird eine E-Mail gelöscht, landet sie normalerweise im Ordner „Gelöschte Elemente“. Wird sie dort entfernt oder per Soft Delete gelöscht (typisch: Shift+Entf in Outlook), wird sie in den Bereich Recoverable Items verschoben. Ein Hard Delete bzw. ein Purge ist davon zu unterscheiden: Das sind aggressivere Löschoperationen, die Elemente auch aus Wiederherstellungsbereichen entfernen sollen. Ohne Hold oder Retention ist Recoverable Items letztlich nur eine zeitlich begrenzte Wiederherstellungsschicht. Nach Ablauf der regulären Fristen oder nach administrativem Purge wird die Nachricht tatsächlich entfernt.

Bei SharePoint und OneDrive ist die Logik ähnlich gestuft. Eine Datei landet zunächst im Papierkorb der Site oder des OneDrive. Danach in den Second-Stage Recycle Bin der Site Collection. Ist auch diese Stufe geleert und keine Retention greift, wird die Datei endgültig entfernt.

Bei Teams hängt es davon ab, über welchen Inhaltstyp gesprochen wird. Dateien liegen ohnehin in SharePoint oder OneDrive. Nachrichten wiederum haben für Compliance-Zwecke zusätzliche Kopien, die in Exchange-nahen Speicherorten verarbeitet werden. Ohne passende Aufbewahrung verschwinden auch diese Daten nach den normalen dienstspezifischen Löschpfaden endgültig.

Wie sich Löschen mit aktiver Retention verhält

Sobald eine passende Retention Policy greift, verändert sich genau dieser letzte Schritt. Das Objekt darf jetzt zwar für den Benutzer gelöscht aussehen, aber es darf nicht endgültig vernichtet werden. Microsoft 365 fängt den Vernichtungsvorgang ab und hält den Inhalt in geschützten, für normale Endanwender nicht zugänglichen Speicherorten vor.

Das Entscheidende ist also nicht, ob Benutzer löschen dürfen – das dürfen sie meist weiterhin. Entscheidend ist, dass der Plattform-Back-End-Prozess die endgültige Entfernung verhindert und stattdessen eine retention-konforme Erhaltung organisiert.

Exchange im Detail: von „Gelöschte Elemente“ bis „Recoverable Items“

Exchange ist der Bereich, in dem sich die Wirkung von Retention am anschaulichsten erklären lässt. Gleichzeitig ist er operativ besonders relevant, weil dort auch die versteckten Speicherquoten schnell zum Thema werden können.

Der Löschpfad in Exchange sieht vereinfacht so aus:

• E-Mail liegt zunächst im normalen Ordner des Benutzers
• Benutzer löscht sie – sie landet in Deleted Items
• Benutzer entfernt sie dort oder nutzt Soft Delete – sie landet in Recoverable Items (typisch: Deletions)
• Ohne aktive Retention/Hold kann sie nach Ablauf der Wiederherstellungsfristen endgültig entfernt werden
• Mit aktiver Retention/Hold wird sie in Hold-bezogenen Unterstrukturen weiter aufbewahrt, auch wenn Anwender oder Admins aggressivere Löschpfade (Hard Delete/Purge) auslösen

Der Bereich Recoverable Items ist dabei kein einzelner Papierkorb, sondern ein interner Container mit mehreren Unterordnern. Zu den wichtigsten zählen:

Für Administratoren ist wichtig: Der Benutzer sieht diese Struktur in Outlook nicht als normales Arbeitsarchiv. Selbst wenn er die Nachricht nicht mehr sieht, kann sie im Hintergrund noch über Jahre in einem dieser Bereiche erhalten bleiben.

Genau dort liegt auch ein operativer Fallstrick. Wird massenhaft irrelevante Kommunikation – etwa Newsletter, Benachrichtigungen oder andere „Rauschdaten“ – vor Ablauf der Frist gelöscht, dann wandern diese Inhalte nicht ins Nichts, sondern in die versteckten Aufbewahrungsbereiche. Sie zählen dort gegen die entsprechenden Quoten. In kleinen Umgebungen fällt das oft lange nicht auf. In Postfächern mit hohem Volumen oder ungünstigem Nutzerverhalten kann das aber Jahre später sehr spürbar werden.

SharePoint und OneDrive im Detail: Papierkörbe und Preservation Hold Library

Bei Dateien in SharePoint und OneDrive ist die Logik anders aufgebaut, aber nicht weniger wichtig. Auch hier unterscheidet Microsoft strikt zwischen dem sichtbaren Löschvorgang des Benutzers und der technischen Endvernichtung.

Der sichtbare Teil sieht zunächst harmlos aus:

• Datei oder Ordner wird gelöscht
• landet im normalen Papierkorb der Site bzw. des OneDrive
• wird dort entfernt
• landet im Second-Stage Recycle Bin der Site Collection
• wird auch dort gelöscht

Ohne aktive Retention ist die Datei danach tatsächlich weg. Mit aktiver Retention endet die Geschichte aber nicht dort: Sobald Retention für den Inhalt greift, stellt SharePoint/OneDrive eine aufbewahrungspflichtige Kopie in der Preservation Hold Library sicher – typischerweise ausgelöst durch Löschen oder durch relevante Änderungen am Inhalt. Die Papierkorb-Stufen bleiben weiterhin der sichtbare Nutzerpfad, die Retention arbeitet parallel als technische Sicherungsschicht. Diese Bibliothek ist ein Aufbewahrungsort, den normale Endanwender nicht als regulären Arbeitsbereich verwenden. Dort landen nicht nur ursprünglich gelöschte Dateien, sondern abhängig vom Szenario auch frühere Versionen geänderter Inhalte.

Das führt in der Praxis zu einem häufigen Irrtum: Wenn ein Anwender oder sogar ein Site Owner einen Ordner nicht mehr sieht, wird schnell angenommen, er sei „weg“. Tatsächlich kann sein Inhalt weiterhin in der Preservation Hold Library vorhanden und über eDiscovery auffindbar sein.

Ein zweiter wichtiger Punkt: Ob eine Retention-Frist bei Änderungen neu berechnet wird, hängt von der konkreten Regelbasis ab – etwa ob sie am Erstellungsdatum, am letzten Änderungsdatum, an einem Retention Label oder an einem Ereignis ausgerichtet ist. Metadatenänderungen oder neue Versionen können deshalb je nach Konfiguration und Dienstlogik dazu führen, dass Inhalte länger aufbewahrungspflichtig bleiben als erwartet. Wer Inhalte irgendwann wirklich endgültig entfernen will, muss also nicht nur auf den Löschzeitpunkt achten, sondern auch darauf, ob zwischenzeitlich Änderungen stattgefunden haben, die im gewählten Regelmodell relevant sind.

Teams im Detail: Chats, Kanalnachrichten und die Rolle von Exchange

Teams sorgt regelmäßig für Verwirrung, weil viele intuitiv davon ausgehen, Teams-Nachrichten seien ausschließlich „in Teams“ gespeichert. Für Compliance-Zwecke stimmt das so nicht. Fachlich ist Teams ein eigener Dienst. Für Aufbewahrung und eDiscovery werden aber Compliance-Kopien an Stellen gespeichert, die eng mit Exchange zusammenhängen.

Vereinfacht gilt:

• Private Chats und Gruppenchats erzeugen Compliance-Kopien im Benutzerkontext (Exchange-Mailboxen der beteiligten Nutzer)
• Kanalnachrichten werden im Kontext des Teams bzw. der Microsoft-365-Gruppe verarbeitet (Group Mailbox / gruppenbezogene Exchange-Strukturen)
• Dateien aus Teams liegen ohnehin in SharePoint oder OneDrive

Das bedeutet in der Praxis: Wird eine Teams-Nachricht im Frontend gelöscht, kann sie für den Benutzer verschwunden sein, im Hintergrund aber weiterhin als Compliance-relevante Kopie vorhanden bleiben. Diese Kopie ist nicht einfach ein normaler Chatverlauf im Benutzerinterface, sondern ein für Purview und eDiscovery nutzbarer Datenbestand.

Gerade deshalb entscheiden sich viele Organisationen bei Teams für andere Retention-Regeln als bei Exchange oder SharePoint. Chats und Kanalnachrichten erzeugen oft hohe Datenmengen bei geringer langfristiger Relevanz. Deshalb ist es durchaus üblich, hier „retain for x years, then delete“ zu wählen, während man bei E-Mails und Dokumenten vorsichtiger vorgeht.

Was passiert bei Hard Delete, Purge und „endgültigem Löschen“?

In Diskussionen mit Administratoren oder Fachbereichen taucht oft die Annahme auf, ein Hard Delete oder Purge müsse doch „wirklich endgültig“ sein. Das ist ohne aktive Retention oft korrekt. Mit aktiver Retention aber gerade nicht.

Hard Delete bedeutet zunächst, dass ein Objekt nicht nur „verschoben“, sondern so entfernt wird, dass es nicht mehr über die üblichen Benutzerfunktionen zur Wiederherstellung erreichbar ist. Purge steht typischerweise für den Versuch, ein Objekt auch aus Wiederherstellungsbereichen zu beseitigen. Solange aber eine wirksame Aufbewahrungslogik greift, wird dieser Vernichtungspfad von Microsoft 365 abgefangen. Das Objekt wird nicht endgültig vernichtet, sondern in den relevanten Hold-Mechanismus übernommen.

Das ist in der Praxis einer der wichtigsten Punkte überhaupt: Retention schützt nicht dadurch, dass niemand löschen darf, sondern dadurch, dass die Plattform den letzten Vernichtungsschritt blockiert.

Wie Administratoren auf diese „gelöschten“ Inhalte zugreifen

Die Tatsache, dass Inhalte im Hintergrund erhalten bleiben, nützt natürlich nur dann etwas, wenn man sie später wieder finden kann. Genau dafür ist Microsoft Purview mit seinen eDiscovery- und Search-Funktionen gedacht. Siehe letzter Absatz.

Wichtig ist dabei: In der Praxis arbeiten Unternehmen nicht direkt auf den versteckten Speicherorten. Niemand öffnet etwa per Benutzeroberfläche die Ordnerstruktur „Recoverable Items\DiscoveryHolds“, um dort E-Mails manuell zu durchsuchen. Stattdessen wird über Purview ein Such- und Exportprozess über die zugrundeliegenden Workloads gelegt.

Der typische Praxisweg: Case, Search, Scope, Review, Export

Wenn Inhalte etwa für eine Steuerprüfung, interne Untersuchung oder einen Rechtsfall benötigt werden, läuft der Zugriff in der Regel in mehreren Stufen ab.

• Es wird ein eDiscovery Case in Microsoft Purview angelegt
• Innerhalb des Cases werden Mitglieder und Berechtigungen definiert
• Dann wird eine Suche bzw. Collection mit einem klaren Scope eingerichtet
• Der Scope definiert, welche Postfächer, Sites, OneDrives oder Teams-relevanten Datenquellen einbezogen werden
• Auf Basis von Suchbegriffen, Zeiträumen, Personen oder anderen Filtern werden Treffer ermittelt
• Treffer können geprüft, verfeinert und anschließend exportiert werden

Entscheidend ist dabei das Scope-Konzept. Purview soll gerade nicht bedeuten, dass jemand „einfach mal kreuz und quer wühlt“. In professionellen Szenarien wird präzise festgelegt, welche Quellen, welche Zeiträume und welche Suchbegriffe relevant sind. Gerade bei sensiblen Prüfungen ist diese Eingrenzung fachlich, rechtlich und organisatorisch zentral.

Auch hier gibt es eine häufige Fehlannahme: Purview gibt nicht „den Papierkorb“ aus. Es gibt Inhalte aus, die über die Suchlogik im betreffenden Scope gefunden werden – einschließlich solcher Inhalte, die für Benutzer längst gelöscht aussehen, aber retention-bedingt noch vorhanden sind.

Warum viele Unternehmen Retention mit Archivierung verwechseln

Die Verwechslung liegt nahe, weil Retention dafür sorgt, dass Daten erhalten bleiben. Archivierung im fachlich sinnvollen Sinn bedeutet aber mehr: strukturierter Zugriff, sinnvolle Ordnung, direkte Sichtbarkeit, Nutzbarkeit im Tagesgeschäft, kontrollierte Auslagerung älterer Inhalte und ein klarer Lebenszyklus.

Eine E-Mail, die nur deshalb noch existiert, weil sie im Hintergrund in einem Hold-Bereich aufgehoben wird, ist nicht automatisch „gut archiviert“. Für den Benutzer ist sie ja gerade nicht regulär sichtbar. Wer Mails im Alltag wiederfinden und bearbeiten will, braucht sichtbare Ablagestrukturen – etwa Ordnerhierarchien und bei Exchange zusätzlich ein Online-Archiv. Retention ist dann das Sicherheitsnetz darunter, nicht das eigentliche Organisationsmodell.

Der größte operative Vorteil: Schutz vor vorzeitiger Vernichtung

Trotz aller Einschränkungen haben Retention Policies einen enormen Wert. Ihr größter Vorteil ist ihre Zuverlässigkeit auf Plattformebene. Sie entkoppeln die Mindestaufbewahrung vom Verhalten einzelner Benutzer. Ob jemand versehentlich einen Ordner löscht, einen ganzen Mandantenbestand aus OneDrive entfernt oder Nachrichten in Teams bereinigt: Solange die Policy greift, ist die endgültige Vernichtung blockiert.

Gerade in Organisationen, in denen man keine verlässliche manuelle Klassifikation im Alltag erwarten kann, ist dieser systemische Schutz sehr viel wert. Er nimmt Druck aus dem Tagesgeschäft und reduziert die Gefahr, dass wichtige Informationen durch Fehlbedienung oder falsches Löschen komplett verschwinden.

Die typischen Fallstricke: Speicherwachstum, Blindheit und falsche Sicherheit

Retention Policies bringen aber auch eine Reihe von Nebenwirkungen mit sich, die in Projekten oft zu spät erkannt werden.

Das erste Problem ist das unsichtbare Speicherwachstum. Gerade bei Exchange können Recoverable Items, DiscoveryHolds und verwandte Bereiche stark anwachsen. Der Benutzer sieht davon im Tagesgeschäft nichts. Das Problem taucht oft erst dann auf, wenn Quoten, Performance oder Supportfälle sichtbar werden.

Das zweite Problem ist psychologisch: Weil gelöscht im Frontend oft wie endgültig gelöscht aussieht, entsteht leicht eine trügerische Blindheit für den tatsächlichen Datenbestand. Organisationen glauben dann, Daten seien weg, obwohl sie im Hintergrund noch viele Jahre vorhanden sind. Umgekehrt glauben manche, alles sei schon revisionssicher gelöst, obwohl in Wirklichkeit nur eine Mindestaufbewahrung existiert.

Das dritte Problem ist das Fehlen eines echten Löschkonzepts. Wer „retain only“ konfiguriert, stellt sicher, dass innerhalb der Frist nichts verschwindet. Nach Ablauf der Frist passiert aber bei dieser Konfiguration erst einmal gar nichts. Inhalte dürfen dann zwar gelöscht werden, werden aber nicht automatisch gelöscht. Ohne nachgelagerte Lifecycle-Strategie entstehen so über Jahre große Bestände an Altlasten und Karteileichen.

Ein besonders relevantes Missverständnis: „Nach zehn Jahren ist es automatisch weg“

Diese Annahme ist so weit verbreitet, dass sie gesondert betont werden muss. Eine Policy „keep for 10 years“ bedeutet nicht, dass Inhalte nach zehn Jahren automatisch gelöscht werden. Sie bedeutet nur, dass Inhalte mindestens zehn Jahre lang nicht endgültig gelöscht werden dürfen.

Ob danach automatisch gelöscht wird, hängt ausschließlich von der zweiten Hälfte der Regel ab. Bei „retain and then delete“ ist eine automatische Löschung vorgesehen. Bei „retain only“ oder „keep“ nicht. Genau hier entstehen später oft Überraschungen.

Warum nicht jeder Datenbestand gleich behandelt werden sollte

In der Theorie ist eine tenantweite pauschale Regel attraktiv: einfach, schnell, wenig Abstimmung. In der Praxis unterscheiden sich Datenbestände aber oft massiv. Mandantenkorrespondenz, Projektdokumente, Vertragsunterlagen, Teams-Kurzkommunikation, Newsletter-Postfächer und technische Benachrichtigungen haben nicht dieselbe Wertigkeit. Wer alles gleich behandelt, erkauft sich Einfachheit oft mit unnötigen Nebeneffekten.

Deshalb ist es sinnvoll, zumindest perspektivisch darüber nachzudenken, bestimmte Spezialpostfächer oder besonders rauschintensive Datenquellen anders zu behandeln – etwa mit kürzeren Retention-Zeiten oder gezielten Ausnahmen. Gerade Sammelpostfächer für öffentliche Registrierungen oder automatischen Benachrichtigungsverkehr sind klassische Kandidaten für eine abweichende Behandlung.

Was in der Praxis meist besser funktioniert als „alles nur über Retention lösen“

Retention funktioniert am besten, wenn sie nicht als alleinige Informationsarchitektur missverstanden wird. Praktisch bewährt hat sich ein zweistufiges Modell:

• sichtbare, benutzernahe Archivierung im regulären Arbeitskontext
• Retention als unsichtbares Auffangnetz im Hintergrund

Für Exchange bedeutet das oft: saubere Ordnerstrukturen, nachvollziehbare Jahres- oder Mandantenlogik und zusätzlich ein Online-Archiv für ältere, aber weiterhin sichtbar benötigte Bestände. Wird ein solcher Bestand später nach Ablauf der relevanten Frist gelöscht, ist er dann tatsächlich löschbar. Wird er hingegen vorzeitig gelöscht, greift die Retention als Sicherungsmechanismus.

Wie man im Ernstfall mit Purview arbeitet

Sauber wird eDiscovery erst dann, wenn der Zugriff über einen Case gesteuert ist. Der Einstieg erfolgt im Microsoft-Purview-Portal unter https://purview.microsoft.com: In der linken Navigation führt der Pfad Lösungen > eDiscovery zu Fälle/Cases (in manchen Tenants als „Cases (preview)“ bezeichnet).

Dort wird ein neuer Fall erstellt oder ein bestehender geöffnet. Für die Praxis entscheidend ist die Case-Mitgliedschaft – selbst für Admins. Denn: Globale Administratorrechte bedeuten nicht automatisch Zugriff auf einen konkreten Case.

Wer im Case nicht explizit als Mitglied geführt wird, kann weder kontrolliert im Fall arbeiten noch Exporte sauber auslösen. Deshalb wird im geöffneten Case unter Case settings > Access and permissions festgelegt, welche Personen bzw. Rollengruppen als Case Members berechtigt sind. Erst danach folgt die belastbare Eingrenzung des Scope: Unter Data sources werden die relevanten Datenquellen definiert – etwa konkrete Exchange-Mailboxen, SharePoint-Sites, OneDrive-Accounts sowie gruppen- bzw. teamsbezogene Kontexte.

Auf dieser Grundlage werden Searches/Collections so formuliert, dass Ergebnisse später nachvollziehbar und prüfbar bleiben: klare Zeitfenster, definierte Beteiligte (z. B. Sender/Empfänger bzw. Benutzer), präzise Begriffskombinationen inklusive Ausschlüssen und – wo möglich – eng gefasste Locations statt tenantweiter Vollsuche. Operativ ergibt sich daraus eine klare Kette: Suche/Collection liefert Treffer → Treffer werden in ein Review set übernommen (Sichtung, Tagging, Deduplizierung, iterative Präzisierung) → die eigentliche Datenanforderung und Nachweisabgabe erfolgt kontrolliert über Export aus dem Review Set, inklusive Exportreport/Protokoll zur Dokumentation.

• Portal öffnen: https://purview.microsoft.com > Lösungen > eDiscovery > Fälle/Cases (ggf. Cases (preview))
• Case öffnen/erstellen: gewünschten Fall auswählen oder Create case anlegen
• Case-Mitglieder setzen: im Case Case settings > Access and permissions > Case Members hinzufügen (auch Konten mit Global-Admin-Rechten müssen hier explizit aufgenommen werden)
• Scope definieren: Data sources > relevante Mailboxen, Sites, OneDrives, Gruppen-/Teams-Kontexte auswählen und dokumentieren
• Suchlogik formulieren: Zeitfenster, Beteiligte, Keywords/Operatoren, Ausschlüsse; zuerst Scope so eng wie möglich setzen, erst danach Suchbegriffe erweitern
• Review sauber durchführen: Treffer in Review sets übernehmen, prüfen, taggen, deduplizieren und iterativ nachschärfen
• Datenanforderung/Abgabe: im Review Set Actions > Export auslösen, Exportreport/Protokoll sichern und Übergabe nach internem Freigabeprozess durchführen

In belastbaren Szenarien ist der Case so zu führen, dass ein Dritter später ohne Kontext nachvollziehen kann, warum genau diese Data Sources im Scope waren, wie die Suchlogik (inklusive Zeitfenstern und Ausschlüssen) lautete und welcher Export mit welchem Trefferstand erzeugt wurde. Genau diese Nachvollziehbarkeit trennt eDiscovery als kontrollierten Nachweisprozess von einer unstrukturierten Volltextsuche.