Löschkonzept nach DSGVO in Microsoft 365: von DIN 66398 zur Purview-Umsetzung

Die Aufsichtsbehörde hatte eine einfache Frage gestellt, und sie stand am Ende eines langen Fragebogens: „Legen Sie Ihr Löschkonzept vor." Der Datenschutzbeauftragte des Unternehmens – ein Mittelständler aus dem Ruhrgebiet, gut aufgestellt, mit sauberem Verzeichnis der Verarbeitungstätigkeiten – hatte eines. Zwölf Seiten, ordentlich gegliedert, mit Löschfristen für jede Datenart. Nur stand nirgends, welches System die Löschung tatsächlich ausführte. Für die Postfächer stand da „Löschung nach 3 Jahren", und in Exchange Online gab es keine einzige Aufbewahrungsrichtlinie. Die Fristen waren beschlossen. Umgesetzt hatte sie niemand. Das Konzept war Papier, und die Behörde wusste das nach zwei Rückfragen.

Ein Löschkonzept nach DSGVO ist die Antwort auf zwei Artikel: Art. 5 verlangt Speicherbegrenzung – personenbezogene Daten dürfen nicht länger vorgehalten werden, als der Zweck es erfordert –, und Art. 17 gibt Betroffenen das Recht auf Löschung. Die DIN 66398 liefert seit Jahren die Struktur, wie man daraus ein Dokument macht: Datenarten, Löschklassen, Löschregeln, Umsetzungsvorgaben, Verantwortliche. Was der Norm fehlt und was den meisten Konzepten fehlt, ist der letzte Meter: die Übersetzung der Löschklassen in Systeme, die tatsächlich löschen. Für alles, was in Exchange, SharePoint, OneDrive und Teams liegt, ist Microsoft Purview dieses System – mit Retention Policies für die Breite und Retention Labels für den gezielten Fall, mit Startzeitpunkten, die den Fristbeginn abbilden, und mit einer Nachweiskette, die man einer Behörde zeigen kann. Und mit klaren Grenzen: Purview löscht in Microsoft 365. Nicht im ERP, nicht im Backup, nicht in Planner, nicht auf dem Fileserver.

Dieser Artikel zeigt, wie aus einem Löschkonzept nach DIN 66398 eine Purview-Landkarte wird, wie Löschklassen in Richtlinien und Labels übersetzt werden, wie die Nachweisbarkeit funktioniert und wo Purview aufhört. Die Grundlagen von Retention Policy und Label setzt der Spoke Retention Policy vs. Retention Label voraus; die andere Seite der Medaille – Aufbewahrungspflichten nach GoBD – behandelt der Spoke zur GoBD-Aufbewahrung. Wo Löschen im Gesamtbild von Purview sitzt, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

Vom Löschkonzept zur Purview-Landkarte

Ein Löschkonzept entsteht nicht in Purview, und es sollte auch nicht dort beginnen. Es beginnt beim Datenschutzbeauftragten und den Fachbereichen mit der Frage, welche Datenarten es gibt und wie lange sie gebraucht werden. Purview kommt erst ins Spiel, wenn diese Frage beantwortet ist – dann aber mit einer eigenen Übersetzungsleistung, die jemand machen muss, der beide Sprachen spricht: die des Konzepts und die des Portals. In Projekten ist das der Moment, in dem sich zeigt, ob das Konzept mehr ist als Papier.

DIN 66398 in fünf Sätzen

Die Norm ist unspektakulär und genau deshalb brauchbar. Erstens: Datenarten – welche Kategorien personenbezogener Daten gibt es im Unternehmen, von Bewerberunterlagen über Kundenkorrespondenz und Beschäftigtendaten bis zu Protokollen und Chats. Zweitens: Löschklassen – eine Löschklasse ist die Kombination aus einer Regelfrist und einem Startzeitpunkt, etwa „sechs Monate nach Absage", „drei Jahre nach Vertragsende", „ein Jahr nach Erstellung"; die Norm empfiehlt, mit wenigen Klassen auszukommen, weil jede zusätzliche Klasse eine zusätzliche Regel ist, die jemand pflegen muss. Drittens: Löschregeln – die Zuordnung jeder Datenart zu einer Klasse, mit Ausnahmen für gesetzliche Aufbewahrungspflichten und laufende Verfahren. Viertens: Umsetzungsvorgaben – in welchem System liegt die Datenart, welches System löscht, wie wird die Löschung ausgelöst und geprüft. Fünftens: Verantwortliche und Nachweis – wer entscheidet, wer dokumentiert, wer prüft. Punkt vier ist der, an dem die meisten Konzepte enden und Purview beginnt.

Was Purview davon abbildet – und was nicht

Purview ist die Umsetzungsvorgabe für alles, was in Microsoft 365 liegt. Eine breite Löschklasse – „Teams-Chats ein Jahr nach Erstellung", „OneDrive-Inhalte fünf Jahre nach letzter Änderung", „Postfächer drei Jahre" – wird eine Retention Policy: tenantweit oder je Workload, statisch oder adaptiv, mit der Aktion „nur löschen" oder „aufbewahren und dann löschen". Eine gezielte Löschklasse – „Bewerbungsunterlagen sechs Monate nach Absage", „Kundenakte drei Jahre nach Vertragsende" – wird ein Retention Label, als Standard an der Bibliothek, in der diese Datenart liegt, oder per Auto-Apply anhand von Klassifizierern, mit einem Startzeitpunkt, der den Fristbeginn abbildet. Der Startzeitpunkt ist der Übersetzungsfehler Nummer eins: Die Norm denkt in „nach Absage", „nach Vertragsende", „nach Austritt"; Purview kennt Erstellung, letzte Änderung, Labeling und Ereignis. Für „nach Absage" braucht es entweder ein ereignisbasiertes Label mit einem Ereignis aus dem Bewerbermanagement oder die Vereinfachung „ab Erstellung plus Bearbeitungsdauer". Und die Ausnahmen der Norm – Aufbewahrungspflichten, laufende Verfahren – sind in Purview eingebaut: Aufbewahren schlägt Löschen, Holds stehen außerhalb jeder Frist. Das ist gewollt, es muss aber im Konzept stehen, sonst wundert sich der Datenschutzbeauftragte, warum die Drei-Jahres-Löschung ein Postfach nicht leert.

Skizze 1: Vom Löschkonzept zur Purview-Umsetzung – Struktur nach DIN 66398, Übersetzung in Richtlinien und Labels, Ablauf im Betrieb.

Die Tabelle zeigt typische Löschklassen aus deutschen Projekten mit ihrer Purview-Umsetzung. Fristen und Startzeitpunkte sind Beispiele aus der Praxis, keine Rechtsberatung – die Festlegung trifft der Datenschutzbeauftragte mit den Fachbereichen.

Löschklassen in Richtlinien und Labels übersetzen: Standardfristen und Sonderfälle

Die wichtigste Zeile jedes Löschkonzepts ist die letzte: „alles andere". Kein Konzept erfasst jede Datenart, und die meisten personenbezogenen Daten in Microsoft 365 liegen nicht in ordentlich beschrifteten Bibliotheken, sondern in Postfächern, OneDrives und Chats, in denen Kundendaten, Kollegendaten und Kantinenpläne durcheinanderliegen. Für diesen Rest braucht es eine Standardfrist – eine Tenant-Richtlinie mit „aufbewahren und dann löschen", die als Sicherheitsnetz alles erfasst, was keine eigene Klasse hat. Sieben Jahre ab letzter Änderung sind ein häufiger Kompromiss, weil sie die längste allgemeine Aufbewahrungspflicht abdecken und trotzdem irgendwann löschen. Ohne diese Zeile ist jedes Löschkonzept eine Sammlung von Ausnahmen ohne Regel.

Darüber liegen die Sonderfälle mit eigenen Klassen, und für sie gilt: erst der Ort, dann das Werkzeug. Teams-Chats bekommen zwingend eine eigene Richtlinie – kürzer als Postfächer, weil Chats informeller sind und der Betriebsrat sie besonders im Blick hat; ein Jahr ist in vielen Betriebsvereinbarungen der Rahmen. Postfächer bekommen eine Richtlinie mit einer Frist, die zwischen Datenschutz und Handelsbrief-Aufbewahrung vermittelt – meist gestuft nach Bereichen über adaptive Bereiche. Bewerberdaten, Personalakten und Kundenakten bekommen Labels, weil dort der Startzeitpunkt vom Ereignis abhängt und die Löschung nachweisbar sein soll. Und wo Aufbewahrungspflichten gelten – Handelsbriefe, Belege, Verträge –, gewinnt das GoBD-Label gegen die Löschklasse; das ist kein Fehler, sondern die technische Abbildung dessen, dass die Aufbewahrungspflicht die Rechtsgrundlage für die weitere Speicherung liefert. Wie das für ausscheidende Mitarbeiter im Detail aussieht – Postfach, OneDrive, Chats beim Austritt –, beschreibt der Spoke zu ausscheidenden Mitarbeitern.

Ein Wort zur Zahl der Löschklassen. Die Norm empfiehlt Sparsamkeit, und Purview bestraft Verschwendung: Jede Löschklasse wird eine Richtlinie oder ein Label, jede Richtlinie kann mit jeder anderen in Konflikt geraten, und jedes Label muss irgendjemand zuweisen oder per Auto-Apply treffen. In Projekten haben sich fünf bis acht Klassen als Obergrenze bewährt – eine Standardfrist, eine kurze für Chats und Protokolle, eine für Postfächer, zwei bis drei ereignisbasierte für Bewerber, Beschäftigte und Kunden, und die Aufbewahrungsklassen aus dem GoBD-Katalog. Wer zwanzig Löschklassen hat, hat ein Konzept, dessen Konflikte niemand mehr vorhersagen kann, und ein Portal, dessen Richtlinien niemand mehr überblickt. Weniger Klassen mit klaren Ausnahmen schlagen viele Klassen mit unklarer Wirkung – bei der Behörde und im Betrieb.

Nachweisbarkeit: wie du belegst, dass gelöscht wird

Die Rechenschaftspflicht aus Art. 5 Abs. 2 DSGVO heißt: Es reicht nicht, ein Löschkonzept zu haben und Richtlinien zu konfigurieren – man muss zeigen können, dass die Löschung stattfindet. Und hier gibt es eine unbequeme Wahrheit über Purview: Retention Policies löschen im Hintergrund, per Zeitgeberauftrag, ohne einen Einzelnachweis je Element. Es gibt keinen Bericht „am 3. Mai wurden 4.812 Mails aus dem Postfach Müller gelöscht". Wer das erwartet, wird enttäuscht – und wer es dem Datenschutzbeauftragten versprochen hat, hat ein Problem. Die Nachweiskette muss deshalb anders gebaut werden, aus fünf Gliedern, von denen drei aus Purview kommen.

Das erste Glied ist das Konzept selbst mit der Zuordnung jeder Löschklasse zu einer konkreten Richtlinie oder einem Label. Das zweite ist die Konfiguration: der Export aller Retention Policies und Labels per PowerShell mit Bereichen, Fristen, Startpunkten und Aktionen, versioniert und datiert – das ist der Beweis, dass die Regel seit wann gilt. Das dritte ist das Audit-Log: Jede Änderung an Richtlinien und Labels, jeder gesetzte oder aufgehobene Hold ist ein Ereignis, das zeigt, dass niemand die Regel zwischendurch ausgeschaltet hat. Das vierte ist die Stichprobe: eine Content-Suche mit Datumsfilter, die zeigt, dass es in den betroffenen Speicherorten keine Elemente mehr gibt, die älter sind als die Löschfrist – oder, wenn es sie gibt, warum (Hold, Aufbewahrung, Ausnahme). Das fünfte gibt es nur für Labels mit Disposition Review: das Einzelprotokoll, wer wann was freigegeben und gelöscht hat. Meine Empfehlung aus Projekten: Für Löschklassen mit hohem Risiko – Bewerber, Beschäftigte, Gesundheitsdaten – Labels mit Review, damit der Einzelnachweis existiert; für den Rest reicht Konfiguration plus vierteljährliche Stichprobe, dokumentiert in einem Nachweisprotokoll, das der Datenschutzbeauftragte abzeichnet.

Skizze 2: Die Nachweiskette – Konzept, Konfiguration, Audit-Log, Stichprobe, Disposition; und was Purview nicht liefert.

Als Umsetzungshilfe die Nachweisartefakte mit Quelle und Rhythmus. Zusammen ergeben sie das, was eine Aufsichtsbehörde unter „Legen Sie Ihr Löschkonzept vor" tatsächlich sehen will: nicht das Dokument allein, sondern den Beleg, dass es wirkt.

Die Grenzen: Purview löscht in Microsoft 365 – und sonst nirgends

Der gefährlichste Satz in einem Purview-Projekt lautet: „Das Löschkonzept ist jetzt umgesetzt." Er ist richtig für Exchange, SharePoint, OneDrive und Teams – und falsch für alles andere, und das andere ist in den meisten Unternehmen die Mehrheit der personenbezogenen Daten. Das ERP mit den Kundenstammdaten, das CRM mit der Kontakthistorie, das HR-System mit den Personalakten, das DMS mit den Verträgen, der Fileserver, der seit 2004 wächst: Purview sieht davon nichts und löscht davon nichts. Ein Löschkonzept, das Purview für „umgesetzt" erklärt, hat für diese Systeme keine Zeile – und die Behörde wird genau danach fragen.

Innerhalb von Microsoft 365 gibt es eine zweite Grenze, die weniger bekannt ist: Nicht jeder Microsoft-365-Dienst wird von Retention Policies erfasst. Planner-Pläne, Forms-Antworten, Bookings, To Do, Whiteboard, die Power Platform mit Dataverse und den Verläufen von Power Automate, die Benutzerobjekte und Anmeldeprotokolle in Entra ID, die Daten von Defender und Intune – für all das gibt es eigene Löschwege über Admin-Center, Graph oder Dienstkonfiguration, aber keine Purview-Richtlinie. Und dann die dritte Grenze, die in jedem zweiten Projekt übersehen wird: Backups von Drittanbietern. Wer Microsoft 365 mit einem externen Backup-Werkzeug sichert, hat Kopien, die die Purview-Löschung überleben – manchmal jahrelang, mit eigener Aufbewahrung, außerhalb jeder Retention Policy. Das Backup gehört ins Löschkonzept mit eigener Frist, sonst ist die Löschung in Microsoft 365 eine Löschung mit Hintertür. Dazu kommen lokale Outlook-Datendateien, Sync-Kopien auf Laptops, mobile Geräte, Ausdrucke und Auftragsverarbeiter mit eigenen Kopien. Und die individuelle Löschung nach Art. 17 auf Antrag eines Betroffenen ist ohnehin kein Retention-Thema, sondern ein Suchthema – wie sie über eDiscovery läuft, beschreibt der Spoke zum Auskunftsersuchen nach Art. 15 DSGVO, dessen Suchmechanik dieselbe ist. Wie Holds die Löschung blockieren und wann sie aufzuheben sind, steht im Spoke zu Legal Hold in Microsoft 365.

Was in der Praxis dagegen hilft, ist eine Denkregel: Purview ist eine Zeile in der Umsetzungsvorgabe des Löschkonzepts – nicht das Löschkonzept. Für jede Datenart fragt man: Wo liegt sie? Und für jeden Ort: Welches System löscht dort? Für Exchange, SharePoint, OneDrive und Teams heißt die Antwort Purview. Für das ERP heißt sie ERP-Löschlauf, für das Backup heißt sie Backup-Aufbewahrung, für den Fileserver heißt sie Skript oder Migration, für Planner heißt sie Admin-Center oder Graph. Und für die Ausdrucke im Aktenschrank heißt sie Schredder. Ein Löschkonzept, das für jede dieser Antworten eine Zeile hat, ist vollständig; eines, das nur die Purview-Zeile hat, ist ein Purview-Konzept mit falschem Titel.

Skizze 3: Die Reichweiten-Landkarte – wo Purview löscht, wo Microsoft 365 eigene Löschwege braucht und wo Purview nichts sieht.

Der Deutschland-Winkel: Aufsichtsbehörden, Betriebsrat und der Datenschutzbeauftragte

Das Löschkonzept ist in Deutschland ein Prüfungsklassiker der Landesdatenschutzbehörden – Bußgeldverfahren wegen fehlender oder nicht umgesetzter Löschkonzepte sind seit Jahren dokumentiert, und die Frage „Legen Sie Ihr Löschkonzept vor" gehört zum Standardrepertoire jeder anlasslosen Prüfung. Was die Behörden sehen wollen, ist genau die Kette aus diesem Artikel: nicht nur das Dokument nach DIN 66398, sondern die Systemzuordnung, die Konfiguration, den Nachweis. Der Datenschutzbeauftragte ist dabei Autor und Prüfer zugleich – er legt Datenarten und Klassen fest, und er zeichnet das vierteljährliche Nachweisprotokoll ab. Was er nicht tun sollte, ist Purview selbst konfigurieren; das ist Sache der IT, und die Trennung zwischen „wer entscheidet" und „wer umsetzt" ist selbst Teil des Nachweises.

Der Betriebsrat interessiert sich beim Löschkonzept für zwei Dinge. Erstens für die Fristen, die Beschäftigtendaten betreffen: Wie lange bleiben Chats, Mails, OneDrives, DLP-Alarme, Audit-Einträge – und das gehört in die Betriebsvereinbarung, weil kurze Löschfristen für Protokolle das wirksamste Mittel gegen den Verdacht der Verhaltenskontrolle sind. Zweitens für die Ausnahmen: Welche Holds und Aufbewahrungen halten Beschäftigtendaten länger, warum, und wer darf dort suchen. Was in die Vereinbarung gehört, beschreibt der Spoke zur Betriebsvereinbarung für Purview. Für NIS2-pflichtige Unternehmen kommt hinzu, dass Löschkonzept und Aufbewahrungsregeln Teil des Risikomanagements sind – Datenminimierung ist Angriffsflächenreduktion. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist gehören an den Tisch, bevor die erste Löschrichtlinie scharf geht.

Stolperfallen aus der Praxis

Das Löschkonzept hat keine Systemzuordnung. Zwölf Seiten Fristen, keine Zeile, welches System löscht. Die Tabelle mit fünf Spalten – Datenart, Klasse, Ort, Werkzeug, Nachweis – ist der Unterschied zwischen Konzept und Papier.

Löschrichtlinie neben vergessener Aufbewahrung oder Hold. Die Drei-Jahres-Löschung ist Dekoration, weil eine Zehn-Jahres-Aufbewahrung oder ein alter Legal Hold darüber steht. Erst Holds und Aufbewahrungen inventarisieren, dann löschen.

Startzeitpunkt nicht bedacht. „Ab Erstellung" löscht die täglich benutzte Vorlage, „ab Änderung" macht sie unsterblich. Je Datenart entscheiden, nicht tenantweit raten.

Backup vergessen. Purview löscht, das Drittanbieter-Backup behält Kopien für fünf Jahre. Backup-Aufbewahrung ins Löschkonzept, sonst hat die Löschung eine Hintertür.

„Purview löscht ja jetzt" – für alles. Planner, Forms, Power Platform, ERP, Fileserver bleiben außen vor. Jedes System eine eigene Zeile, oder eine Begründung, warum dort nichts liegt.

Kein Nachweisrhythmus. Konfiguriert, dokumentiert, nie wieder angeschaut. Vierteljährlich Konfigurationsexport, Audit-Auszug, Stichprobe – mit Unterschrift des Datenschutzbeauftragten.

Fazit: Ein Löschkonzept braucht eine Adresse – für Microsoft 365 heißt sie Purview

Ein Löschkonzept nach DSGVO wird erst durch die Übersetzung in Systeme wirksam, und für alles, was in Exchange, SharePoint, OneDrive und Teams liegt, ist Purview diese Übersetzung: breite Löschklassen als Retention Policies mit Löschaktion, gezielte Klassen als Labels mit dem richtigen Startzeitpunkt, „alles andere" als Sicherheitsnetz, Aufbewahrungspflichten und Holds als bewusste Ausnahmen – und eine Nachweiskette aus Konfiguration, Audit, Stichprobe und Disposition, die eine Behörde überzeugt. Wer dazu die Grenzen kennt – ERP, Backup, Planner, Fileserver –, hat ein Löschkonzept mit Adresse statt eines Dokuments mit Absicht. Wo Löschen im Gesamtbild aus Aufbewahrung, DLP und Copilot-Absicherung sitzt, zeigt der Purview-Überblick.

Wenn du wissen willst, welche Datenarten aus deinem Löschkonzept in Microsoft 365 liegen, welche Richtlinien und Holds heute wirklich wirken und wie die Nachweiskette für deinen Tenant aussähe: Die Purview-Standortbestimmung liefert genau diese Zuordnung – kompakt, zum Festpreis, mit der Fünf-Spalten-Tabelle als Ergebnis.

FAQ: Häufige Fragen zum Löschkonzept nach DSGVO in Microsoft 365

Was ist ein Löschkonzept nach DSGVO und was hat DIN 66398 damit zu tun?

Ein Löschkonzept legt dokumentiert fest, welche personenbezogenen Daten wie lange gespeichert und wann und wie sie gelöscht werden – gefordert durch Speicherbegrenzung und Rechenschaftspflicht (Art. 5 DSGVO) und das Recht auf Löschung (Art. 17). Die DIN 66398 ist die Leitlinie, die dafür eine Struktur vorgibt: Datenarten, Löschklassen aus Regelfrist und Startzeitpunkt, Löschregeln, Umsetzungsvorgaben je System und Verantwortliche. Sie ist keine Pflicht, aber der anerkannte Standard, an dem sich Behörden orientieren.

Kann Microsoft Purview ein DSGVO-Löschkonzept umsetzen?

Für die Inhalte in Exchange Online, SharePoint Online, OneDrive, Teams, Microsoft-365-Gruppen und Viva Engage: ja – über Retention Policies für breite Löschklassen und Retention Labels für gezielte, mit Startzeitpunkten ab Erstellung, Änderung, Labeling oder Ereignis. Nicht für ERP, CRM, DMS, Fileserver, Drittanbieter-Backups und einige Microsoft-365-Dienste wie Planner, Forms oder die Power Platform – die brauchen eigene Zeilen im Löschkonzept mit eigenen Löschwegen.

Wie weise ich nach, dass Purview tatsächlich löscht?

Retention Policies liefern keinen Einzelnachweis je gelöschtem Element. Der Nachweis besteht aus einer Kette: dem Löschkonzept mit Purview-Zuordnung, dem datierten Konfigurationsexport der Richtlinien und Labels, dem Audit-Log für Änderungen an Richtlinien und Holds, einer regelmäßigen Stichprobe per Content-Suche mit Datumsfilter und – bei Labels mit Disposition Review – dem Einzelprotokoll. Für Löschklassen mit hohem Risiko empfiehlt sich deshalb ein Label mit Review, für den Rest Konfiguration plus vierteljährliche Stichprobe.

Warum löscht meine Löschrichtlinie nichts?

Meistens, weil eine andere Regel länger aufbewahrt: Aufbewahren schlägt Löschen, und Legal Holds oder eDiscovery-Holds stehen außerhalb jeder Frist. Eine vergessene Zehn-Jahres-Aufbewahrung oder ein alter Hold auf dem Postfach machen jede Drei-Jahres-Löschung wirkungslos. Erst Aufbewahrungen und Holds inventarisieren, dann prüfen, ob der Startzeitpunkt (Erstellung oder Änderung) zur Datenart passt.

Löscht Purview auch Daten in Backups?

Nein. Backups von Drittanbietern für Microsoft 365 halten eigene Kopien mit eigener Aufbewahrung, die eine Purview-Löschung überleben können. Sie gehören mit eigener Frist ins Löschkonzept – sonst ist die Löschung in Microsoft 365 eine Löschung mit Hintertür. Auch lokale Outlook-Datendateien, Sync-Kopien auf Geräten und Auftragsverarbeiter mit eigenen Kopien liegen außerhalb der Purview-Reichweite.

Brauche ich für ein Löschkonzept mit Purview Microsoft 365 E5?

Nein, nicht für den Kern: Retention Policies mit Löschaktion und manuell oder als Standard angewendete Retention Labels sind ab Microsoft 365 E3 enthalten. E5 oder E5 Compliance brauchst du für ereignisbasierte Labels mit Auto-Apply, adaptive Bereiche und die Disposition Review mit Einzelnachweis – also dort, wo der Startzeitpunkt vom Ereignis abhängt oder ein Einzelprotokoll je Element gefordert ist (Stand 2026).

Wo fange ich mit dem Löschkonzept in Microsoft 365 an?

Mit einer Tabelle aus fünf Spalten – Datenart, Löschklasse, Ort in Microsoft 365, Purview-Werkzeug, Nachweis –, gefüllt gemeinsam mit Datenschutzbeauftragtem, Fachbereichen und IT. Dann eine Inventur der bestehenden Aufbewahrungen und Holds, danach die Zeile „alles andere" als Tenant-Richtlinie mit Löschaktion, eine Teams-Richtlinie, gestufte Postfach-Richtlinien und Labels für Bewerber und Personalakte. Und ein vierteljährlicher Nachweistermin, bevor die Behörde fragt.