Microsoft 365 Offboarding korrekt durchführen: Zugriffe entziehen, Daten sichern, Compliance einhalten

Organisatorischer Austritt vs. technisches Offboarding: Verantwortlichkeiten, Trigger und Risikoquellen in Microsoft 365

Ein Austritt endet arbeitsrechtlich mit dem letzten Beschäftigungstag, technisch jedoch erst dann, wenn Identitäten, Sitzungen, Berechtigungen und automatisierte Zugriffe in Microsoft 365 nachvollziehbar entzogen oder kontrolliert übergeben wurden. Diese Entkopplung ist gewollt: HR-Prozesse orientieren sich an Vertragsdaten, während Microsoft-365-Identitäten in Echtzeit Zugriff auf E-Mail, Dateien, Teams, Drittanwendungen und Schnittstellen erhalten. Wird das technische Offboarding nur als „Konto deaktivieren“ verstanden, bleiben häufig Restzugänge bestehen, die erst später auffallen: wiederverwendbare Refresh-Tokens, Delegationen, Besitzrollen oder Hintergrundprozesse, die weiterhin Daten bewegen.

Organisatorischer Austritt beschreibt deshalb primär den formalen Statuswechsel (Ende der Zugehörigkeit, Rückgabe von Geräten, Übergabe von Aufgaben). Technisches Offboarding ist eine kontrollierte Änderung der digitalen Identität und ihrer Beziehungen: Authentifizierung, Autorisierung, Datenverbleib, Aufbewahrung und Auditierbarkeit. Beide Prozesse müssen zeitlich synchronisiert, aber fachlich getrennt gesteuert werden, weil die Trigger unterschiedlich sind und die Risiken nicht linear mit dem Enddatum korrelieren.

Verantwortlichkeiten und RACI: wer initiiert, wer entscheidet, wer dokumentiert

In Microsoft 365 verteilen sich Offboarding-Aufgaben typischerweise auf HR, Fachbereich, IT-Betrieb, Identity-&-Access-Management (IAM) sowie Informationssicherheit/Compliance. Kritisch ist, dass fachliche Entscheidungen (z. B. wer erhält Zugriff auf Postfach oder OneDrive) nicht im Admin-Portal „nebenbei“ getroffen werden, sondern als freigegebene Anforderung mit eindeutigem Owner vorliegen. IT setzt um, darf aber nicht stillschweigend definieren, welche Daten an wen übergehen oder wie lange Inhalte aufbewahrt werden.

Für revisionssicheres Arbeiten braucht jede Offboarding-Aktion einen dokumentierten Auslöser, eine verantwortliche Rolle und ein Ergebnis (z. B. Ticket-ID, Änderungslog, Exportnachweis). Das ist besonders relevant, wenn Identitäten später für eDiscovery, interne Untersuchungen oder externe Auskunftsanfragen benötigt werden. Ohne klare Zuständigkeiten entsteht der typische Schattenprozess: ein Konto bleibt „zur Sicherheit“ aktiv, Delegationen bleiben bestehen, oder Lizenzen werden entzogen, bevor Datenübergaben technisch möglich sind.

Typische Trigger in Microsoft 365: Leaver ist nicht gleich Leaver

Nicht jeder Austritt erlaubt denselben Ablauf. Bei regulärem Ende des Arbeitsverhältnisses kann das Offboarding vorgeplant und zeitgesteuert erfolgen (z. B. Sperre zum Stichtag). Bei sofortiger Freistellung oder Verdachtsfällen verschiebt sich der Schwerpunkt: Sitzungen müssen unmittelbar beendet, Sign-in-Sessions widerrufen und Zugriffe auf Daten sowie Admin-Pfade schneller eingeschränkt werden. Auch „Mover“-Fälle (Abteilungswechsel, Wechsel zu externer Gesellschaft) wirken wie ein Offboarding, weil Berechtigungen, Teams-Rollen oder Applikationszugriffe neu bewertet werden müssen.

Aus technischer Sicht sind drei Triggerklassen relevant: (1) Identität verliert Anspruch auf Zugriff (Leaver), (2) Identität ändert Sicherheitskontext (Mover), (3) Identität bleibt, aber der Zugriffspfad ändert sich (z. B. Umstellung auf Shared Mailbox oder Entfernen interaktiver Anmeldung). Ein sauberer Prozess differenziert diese Fälle, weil sonst entweder zu früh Datenzugriff gekappt wird (Betriebsstörung) oder zu spät (Sicherheitsrisiko).

• Regulärer Leaver: zeitgesteuerte Sperre der interaktiven Anmeldung, danach kontrollierte Übergabe von Ressourcen; technische Trigger häufig über HR-System/ITSM mit festem Stichtag.
• Sofortmaßnahmen (Freistellung/Incident): unmittelbarer Widerruf von Sign-in-Sessions/Refresh-Tokens, Prüfung privilegierter Rollen und App-Zugriffe; Umsetzung typischerweise über Entra ID, z. B. Revoke-MgUserSignInSession -UserId <GUID> zusätzlich zur Kontosperre.
• Mover/Role Change: Zugriff bleibt grundsätzlich legitim, aber Berechtigungen müssen neu zugeschnitten werden; Trigger ist nicht das Offboarding-Datum, sondern die Rollenänderung im IAM.
• Externe Umstellung: internes Konto endet, aber Daten müssen für Übergabe oder Aufbewahrung bleiben; häufige Folge ist die Umwandlung in eine Shared Mailbox und das Entfernen von Lizenzen, nachdem Postfachzugriffe geregelt sind.

Risikoquellen: wo organisatorische Klarheit oft fehlt – und technische Reste bleiben

Die größten Offboarding-Risiken entstehen an Schnittstellen: zwischen Benutzerkonto und „nicht-menschlichen“ Zugriffsarten. Moderne Microsoft-365-Umgebungen sind geprägt von Single Sign-On, Conditional Access, OAuth-Zustimmungen, Teams-Integrationen und Automatisierung. Ein deaktiviertes Kennwort oder eine Kontosperre adressiert nur die interaktive Anmeldung, nicht automatisch alle zuvor erteilten Autorisierungen in Anwendungen oder Workflows. Deshalb muss der organisatorische Austritt zwingend als Signal verstanden werden, sämtliche Zugriffspfade zu inventarisieren und zu bewerten.

Typische blinde Flecken sind delegierte Rechte (Mailbox- oder Kalenderdelegation), Besitzrollen in Microsoft Teams oder M365-Gruppen, persönliche OneDrive-Freigaben sowie Zugriffe auf SaaS-Anwendungen über Enterprise Applications. Hinzu kommen Entwicklungskontexte: App-Registrierungen, persönliche Zertifikate, Secrets, oder Zustimmungen zu Microsoft Graph-Berechtigungen. Selbst wenn diese Artefakte formal nicht „dem Konto gehören“, hängen sie praktisch an der Identität und können nach dem Austritt weiterwirken, wenn sie nicht überprüft werden.

• Privilegierte Rollen und Admin-Pfade: Zuweisungen in Entra ID (permanent oder PIM-aktivierbar) müssen vor dem Austritt geprüft und entzogen werden; relevante Kontrollen umfassen z. B. Rollenzuweisungen und PIM-Aktivitäten im Entra-Portal sowie Audit Logs.
• Aktive Sitzungen und Refresh-Tokens: ohne explizites Widerrufen können Apps weiterarbeiten, obwohl die interaktive Anmeldung gesperrt ist; typische Maßnahme ist Revoke-MgUserSignInSession -UserId <GUID> kombiniert mit einer Kontosperre in Entra ID.
• OAuth-Consent und Drittanbieter-Apps: Benutzerzustimmungen zu Enterprise Apps (delegierte Berechtigungen) bleiben bestehen, bis sie entfernt werden; Prüfung erfolgt in Entra ID unter Enterprise Applications, insbesondere bei Apps mit Mail- oder Filescope.
• Automatisierung/Workflows: Power Automate Flows, Logic-Apps-Verbindungen oder Run-as-Konnektoren können an der Identität hängen; organisatorisch muss geklärt sein, ob diese Workflows abgeschaltet, auf Service Accounts umgestellt oder an Nachfolger übergeben werden.
• Datenverantwortung und Freigaben: OneDrive- und SharePoint-Freigaben, die „im Auftrag“ erteilt wurden, wirken über Links und Berechtigungen; ohne definierte Owner-Entscheidung bleibt unklar, ob Inhalte gelöscht, übertragen oder durch Retention gehalten werden sollen.

Planung und Nachvollziehbarkeit: Zeitpunkte, Sperrlogik und Auditspur als Mindeststandard

Für ein belastbares Offboarding müssen Zeitpunkte präzise definiert werden: „letzter Arbeitstag“ ist ein organisatorischer Termin, „letzte zulässige Anmeldung“ ein technischer. Häufig liegt dazwischen ein Fenster für Übergaben, in dem Zugriff eingeschränkt, aber nicht komplett entzogen wird, etwa durch Entfernen bestimmter App-Zugriffe oder durch kontrollierte Delegation. Bei Hochrisiko-Austritten entfällt dieses Fenster; stattdessen wird zuerst gesperrt und anschließend anhand von Auditdaten geklärt, welche Übergaben zulässig sind.

Nachvollziehbarkeit entsteht nicht durch einzelne Screenshots, sondern durch konsistente Belege: Offboarding-Ticket mit Genehmigungen, Export- oder Übergabeprotokolle, sowie prüfbare Einträge in Unified Audit Log und Entra ID Audit Logs. Zusätzlich muss die Quelle der Wahrheit feststehen: HR liefert Status und Stichtage, IAM liefert Identitätsattribute (z. B. Leaver-Flag), ITSM steuert die Umsetzung. Sobald mehrere Stellen parallel in Admin-Portalen Änderungen vornehmen, steigt das Risiko widersprüchlicher Zustände – etwa wenn Lizenzen entfernt werden, bevor eDiscovery- oder Aufbewahrungsanforderungen organisatorisch bestätigt sind.

Schritt-für-Schritt-Offboarding in Microsoft 365: Konto sperren, Sitzungen beenden, Lizenzen entziehen, Daten und Berechtigungen übergeben

Ein belastbares Offboarding folgt einer festen Reihenfolge: Zuerst werden Zugriffe technisch unterbunden, danach laufende Sitzungen und Sign-in-Sessions widerrufen, anschließend werden Lizenzen und privilegierte Berechtigungen bereinigt. Erst wenn der Zugriff zuverlässig entzogen ist, werden Daten übergeben, Archivierungs- und Aufbewahrungsanforderungen geprüft und schließlich Abhängigkeiten in Teams, Postfächern, Anwendungen und Automationen aufgelöst. Diese Reihenfolge reduziert das Risiko, dass ein Konto trotz „Deaktivierung“ weiterhin über aktive Sessions, Refresh Tokens oder Applikationsberechtigungen Zugriff behält.

1) Anmeldung blockieren und Identität absichern

Der erste technische Schritt ist das Sperren der interaktiven Anmeldung in Entra ID. In der Praxis genügt es nicht, nur das Kennwort zu ändern oder das Konto zu löschen, solange Tokens gültig sind oder alternative Anmeldewege (z. B. Legacy-Auth, App-Kennwörter, registrierte Geräte) bestehen. Parallel sollte geprüft werden, ob der Benutzer privilegierte Rollen hält (z. B. Entra ID Rollen, Exchange Admin-Rollen) oder Mitglied in kritischen Gruppen ist. Bei privilegierten Konten empfiehlt sich zusätzlich eine unmittelbare Trennung von administrativen Rechten, bevor die Anmeldung blockiert wird, um Race-Conditions zu vermeiden.

• Sign-in blockieren: Entra ID Benutzer auf AccountEnabled = false setzen (Portal: „Anmeldung blockieren“; API/PowerShell je nach Standard im Tenant).
• Passwort zurücksetzen und Anmeldewege reduzieren: Passwort-Reset erzwingen und ggf. vorhandene App-Kennwörter entfernen; bei hybriden Umgebungen den Zustand in Active Directory und im Cloudobjekt konsistent halten.
• Privilegien entziehen: Rollen- und Gruppenmitgliedschaften prüfen und administrative Zuweisungen entfernen, insbesondere bei Rollen wie Global Administrator, Privileged Role Administrator, Exchange-/SharePoint-Adminrollen.

2) Laufende Sitzungen beenden und Tokens invalidieren

Nach der Sperre der Anmeldung müssen bestehende Authentifizierungen aktiv beendet werden. Andernfalls bleiben Browser-Sessions, Desktop-Clients und mobile Apps häufig weiterhin funktionsfähig, bis Tokens auslaufen oder Refresh Tokens erneut eingelöst werden. Microsoft 365 kennt mehrere Token- und Session-Ebenen: Entra ID Sign-in Sessions, Exchange Online Sessions (OWA/MAPI/ActiveSync), SharePoint/OneDrive Sessions sowie Tokens von Drittanbieter-Apps. Praktisch bedeutet das: Sign-in-Sessions werden widerrufen, Geräte-Sessions abgemeldet und – falls vorhanden – auch anwendungsbezogene Tokens (z. B. Graph-basierte Integrationen) müssen neu authentifiziert oder deaktiviert werden.

• Entra ID Sessions widerrufen: „Revoke sign-in sessions“ im Entra-Portal auslösen; programmgesteuert über Microsoft Graph mit POST /users/{id}/revokeSignInSessions.
• Exchange-Sitzungen beenden: Für Mailbox-Zugriffe (OWA/MAPI/ActiveSync) Sitzungen abmelden; ergänzend mobile Gerätebeziehungen prüfen und ggf. entfernen, um persistente Verbindungen zu verhindern.
• Geräte und Registrierungen prüfen: Zugeordnete Geräteobjekte und Registrierungen (Windows, macOS, Mobile) im Entra-/Intune-Kontext kontrollieren und bei Bedarf Wipe, Retire oder Entfernen auslösen, abhängig vom Gerätestatus und Datenklassifizierung.

3) Lizenzen entziehen, aber Datenverlust kontrollieren

Das Entfernen von Lizenzen ist kein rein kaufmännischer Schritt, sondern beeinflusst unmittelbar Datenzugriff und Datenverfügbarkeit. Für Exchange Online, OneDrive und Teams gelten unterschiedliche Effekte: Ohne Exchange-Lizenz wird die Mailbox nach einer Karenzzeit zur Löschung vorgesehen, sofern keine Aufbewahrung (z. B. Retention/Hold) greift; OneDrive kann nach einer definierten Aufbewahrungszeit zur Löschung anstehen, und Teams-Funktionen hängen an zugewiesenen Serviceplänen. Deshalb sollte vor dem Lizenzentzug feststehen, ob Daten übergeben, archiviert oder über Aufbewahrungsrichtlinien gehalten werden.

4) OneDrive und Exchange-Daten übergeben oder sichern

Für OneDrive und Exchange sollten Übergabe- oder Sicherungswege vorab festgelegt werden: fachliche Übergabe (Owner/Vertretung), rechtliche Aufbewahrung (eDiscovery/Retention) oder technische Archivierung. In OneDrive ist die wichtigste Stellschraube der administrative Zugriff auf die persönliche Site (z. B. über Site-Collection-Admin), da Berechtigungen sonst nach Kontosperre und späterer Löschung verloren gehen können. Bei Exchange entscheidet der Zielzustand: Shared Mailbox, Inactive Mailbox (bei Retention/Hold) oder Export/Archivierung über eDiscovery. PST-Exporte sollten nur in begründeten Ausnahmefällen genutzt werden, weil Integrität, Zugriffskontrolle und Nachvollziehbarkeit außerhalb von M365 schwerer sicherzustellen sind.

• OneDrive-Zugriff für Übergabe setzen: OneDrive-Site des Benutzers identifizieren (z. B. https://<tenant>-my.sharepoint.com/personal/<upn>) und einen Verantwortlichen als Site Collection Admin bzw. Besitzer hinterlegen; anschließend Daten in eine Zielbibliothek migrieren oder dokumentiert übergeben.
• Mailbox-Strategie wählen: Umwandlung in Shared Mailbox, sofern operative Nutzung notwendig ist; alternativ Aufbewahrung über Purview Retention/eDiscovery sicherstellen und Zugriff über berechtigte Rollen kontrollieren.
• Weiterleitungen und automatische Antworten bereinigen: Exchange-Regeln, Weiterleitungen und OOF prüfen und gezielt setzen oder entfernen, damit keine unkontrollierten Datenabflüsse über ForwardingSmtpAddress oder Inbox-Regeln entstehen.

5) Berechtigungen, Delegationen und Teams-Abhängigkeiten auflösen

Viele Offboarding-Fehler liegen nicht im Benutzerkonto, sondern in delegierten Zugriffsrechten und Ownerships: Vollzugriff auf Postfächer, Send-As/Send-on-behalf, Zugriff auf SharePoint-Sites, Besitzerrollen in Teams/M365-Gruppen sowie Planner, Loop-Komponenten oder OneNote. Besonders relevant ist die Owner-Rolle in Teams: Wird ein Benutzer als einziger Besitzer belassen, kann eine spätere Bereinigung scheitern oder Governance-Regeln greifen nicht. Deshalb sollten Gruppen- und Team-Ownerships aktiv umgehängt werden, bevor das Konto endgültig entfernt oder gelöscht wird.

• Mailbox-Delegationen prüfen: Berechtigungen wie FullAccess, SendAs und SendOnBehalf entfernen oder dokumentiert an Nachfolger übertragen; Shared Mailboxes auf unerwünschte Delegationen kontrollieren.
• Teams und M365-Gruppen: Besitzerrolle in Teams/M365-Gruppen auf mindestens zwei aktive Personen übertragen; Mitgliedschaften bereinigen und Gastzugriffe (falls betroffen) separat prüfen.
• SharePoint/OneDrive-Freigaben: Direkte Freigaben und Site-Berechtigungen identifizieren; kritische Sites auf „verwaiste“ Berechtigungen prüfen, die nur über das offboardete Konto funktionierten.

6) Applikationszugriffe, Tokens und Automationen konsequent entfernen

Häufig übersehen: Das Benutzerkonto kann in nicht-interaktiven Pfaden weiterwirken, etwa über delegierte OAuth-Consents, gespeicherte Verbindungen in Power Automate, persönliche Zugriffe in Drittanbieter-Tools oder Besitz an App-Registrierungen. Zwar sind App-Registrierungen typischerweise Tenant-Objekte, aber Owner-Zuweisungen, Zertifikats-/Secret-Rotation oder die Nutzung von „User context“ in Flows führen zu echten Betriebsrisiken, sobald das Konto blockiert ist. Offboarding muss daher auch den Applikations- und Automations-Layer erfassen: Owner ersetzen, Verbindungen neu authentifizieren, Service Principals prüfen, und persönliche Tokens in externen Systemen widerrufen.

• Power Automate/Logic Apps Verbindungen: Flows mit benutzergebundenen Verbindungen identifizieren und auf Servicekonten oder verwaltete Identitäten umstellen; betroffene Connector-Verbindungen neu autorisieren, bevor das Konto gelöscht wird.
• OAuth-Consents und App-Zugriffe: Zustimmungen und App-Zugriffe des Benutzers prüfen; bei sensiblen Apps Sign-in-Sessions widerrufen und Berechtigungen entfernen, insbesondere wenn Apps Microsoft Graph mit delegierten Rechten nutzen.
• App-Registrierungen und Besitz: Owner-Listen in Entra ID kontrollieren und das Offboarding-Konto als Besitzer entfernen; Secrets/Zertifikate rotieren, wenn der Benutzer Zugriff auf Client secrets oder Schlüsselmaterial hatte.

Erst wenn diese Kette vollständig abgearbeitet ist, entsteht ein Offboarding-Zustand, der sowohl sicherheitstechnisch als auch betrieblich stabil ist: Keine Anmeldung, keine aktiven Sessions, keine verbliebenen Delegationen, keine verwaisten Besitzerrollen und keine stillen Hintergrundzugriffe über Automationen oder Drittanbieter-Integrationen. Der verbleibende Schritt ist dann nicht mehr „Zugriff entziehen“, sondern kontrolliert „Lebenszyklus beenden“ gemäß Aufbewahrung, Nachweispflichten und interner Dokumentation.

Aufbewahrung, Löschung und Revision: Retention, Legal Hold, Shared Mailbox-Entscheidung und belastbare Dokumentation

Technisches Offboarding endet nicht mit dem Entzug von Zugriffsrechten. Entscheidend ist, ob und wie lange Inhalte für rechtliche, regulatorische oder interne Nachweiszwecke verfügbar bleiben müssen. In Microsoft 365 entsteht daraus ein Spannungsfeld zwischen Datenminimierung (Löschung, Lizenzreduktion), Geschäftsfortführung (Übergabe) und Compliance (Retention, eDiscovery, Audit). Fehler in dieser Phase fallen oft erst auf, wenn ein Audit ansteht oder eine Auskunftspflicht erfüllt werden muss.

Retention vs. Backup vs. Wiederherstellung: Begriffe und Zuständigkeiten trennen

Retention in Microsoft Purview dient der regelbasierten Aufbewahrung und – je nach Konfiguration – der anschließenden Löschung. Das ist kein Backup im klassischen Sinn, weil Retention nicht die Systemzustände oder tenantweite Konfigurationen sichert, sondern Inhalte gegen Löschung schützt und sie für Such- und Nachweisprozesse verfügbar hält. Backup- oder Drittanbieter-Archivlösungen können ergänzend sinnvoll sein, ersetzen aber weder Aufbewahrungsrichtlinien noch gerichtsfeste Prozesse zur Beweissicherung.

Für Offboarding heißt das: Daten dürfen nicht „gerettet“ werden, indem sie nur irgendwohin kopiert werden. Revisionssicherheit entsteht durch nachvollziehbare Policies, definierte Verantwortlichkeiten, konsistente Löschfristen und eine lückenlose Dokumentation, die belegt, welche Inhalte aus welchem Grund wie lange erhalten bleiben.

Aufbewahrungsmechanismen in Microsoft 365: Was beim Offboarding tatsächlich wirkt

Beim Entfernen von Lizenzen, Deaktivieren des Kontos oder Löschen des Benutzers greifen unterschiedliche Mechanismen. Exchange Online, OneDrive und SharePoint haben jeweils eigene Lebenszyklen und Wiederherstellungsfenster; zusätzlich können Purview-Retention, Litigation Hold/Legal Hold oder eDiscovery-Holds Inhalte unabhängig vom Kontostatus bewahren. Diese Unabhängigkeit ist der zentrale Punkt: Ein gelöschter Benutzer kann weiterhin Daten „hinterlassen“, wenn ein Hold aktiv ist, während umgekehrt ohne Hold auch bei deaktiviertem Benutzer Inhalte nach Ablauf von Standardfristen verschwinden können.

Für Compliance-relevante Fälle sollte vor Lizenzentzug oder Löschung geprüft werden, ob für Postfach, OneDrive oder SharePoint-Inhalte eine Aufbewahrungsrichtlinie, ein Hold oder ein Fall in eDiscovery aktiv sein muss. Ohne diesen Schritt kann eine spätere Beweisführung scheitern, selbst wenn Dateien zuvor übergeben wurden, weil Metadaten, Versionen oder Löschprotokolle fehlen.

Shared Mailbox oder löschen: Entscheidungskriterien mit Nebenwirkungen

Die Umwandlung in eine Shared Mailbox ist ein gängiger Weg, um eingehende E-Mails weiter zu verarbeiten und historische Kommunikation zugreifbar zu halten, ohne eine Benutzerlizenz zu verbrauchen. Technisch ist das jedoch kein Ersatz für Retention: Eine Shared Mailbox bleibt ein Exchange-Objekt mit denselben Anforderungen an Aufbewahrung, Zugriffskontrolle und Nachvollziehbarkeit. Außerdem kann sie zum Schattenarchiv werden, wenn Berechtigungen dauerhaft zu breit vergeben werden oder wenn keine Lösch- und Aufbewahrungsfristen definiert sind.

Die Löschung des Benutzers reduziert Angriffsfläche und Verwaltungsaufwand, erschwert aber operative Übergaben (z. B. direkte Delegation, automatische Antworten, Zugriff über Outlook). Bei klarer Aktenlage und wirksamer Retention ist Löschen oft die sauberste Linie. Für Übergangszeiträume kann eine Shared Mailbox sinnvoll sein, sofern eine End-of-Life-Planung existiert und Zugriffe eng begrenzt werden.

• Shared Mailbox wählen, wenn: eingehende Kommunikation für einen definierten Zeitraum weiterlaufen muss und Zuständigkeiten klar sind (Berechtigungen per Add-MailboxPermission und Add-RecipientPermission restriktiv setzen; ggf. automatische Antworten über Set-MailboxAutoReplyConfiguration).
• Löschen bevorzugen, wenn: keine operative Notwendigkeit für Posteingangsbetrieb besteht und Aufbewahrung über Purview gesichert ist (Retention Policy/Label; bei rechtlicher Relevanz Hold im Purview-Portal bzw. eDiscovery-Workflow).
• Hybrid-/Langzeitfälle absichern: bei laufenden Untersuchungen oder Streitfällen Inhalte vor Änderungen schützen (Exchange: Set-Mailbox -LitigationHoldEnabled $true nur, wenn organisatorisch freigegeben und die Funktion im Tenant verfügbar ist; alternativ eDiscovery Hold verwenden, um die Bindung an einzelne Postfachkonfigurationen zu reduzieren).
• OneDrive-Nachlauf planen: OneDrive-Zugriff für Nachfolger zeitlich befristen und Löschdatum dokumentieren; Zugriff und Besitzerwechsel erfolgen administrativ über die OneDrive-Adminoberfläche (SharePoint Admin Center) oder entsprechende Microsoft Graph/SharePoint-Adminprozesse.

Legal Hold und eDiscovery: Beweissicherung ohne operative Nebenwege

Legal Hold (Litigation Hold) und eDiscovery-Holds haben unterschiedliche Einsatzprofile. Litigation Hold wirkt direkt auf das Exchange-Postfach und bewahrt Inhalte, inklusive gelöschter Elemente, für eDiscovery. eDiscovery-Holds (Microsoft Purview) sind fallbezogen und können mehrere Orte und Benutzer umfassen. Für Offboarding ist fallbezogenes Arbeiten meist robuster, weil die Anforderungen (Scope, Zeitraum, Suchkriterien) nachvollziehbar dokumentiert werden und der Hold nicht „vergessen“ im Postfach verbleibt.

Wichtig ist die Prozessreihenfolge: Hold/Retention zuerst festlegen, dann erst Lizenzen entziehen oder Konten löschen. In Umgebungen mit automatisierten Löschprozessen (z. B. Identitäts-Lifecycle) sollte eine technische Sperre existieren, die Löschung blockiert, solange ein Hold aktiv ist oder ein Compliance-Freigabeschritt fehlt.

Belastbare Dokumentation: Was revisionsfest festgehalten werden muss

Revisionssicherheit entsteht nicht durch Screenshots, sondern durch reproduzierbare Fakten: Identität, Zeitpunkt, Entscheidung, genehmigende Stelle, angewendete Policies und technische Umsetzung. Dokumentation sollte sowohl organisatorische Freigaben (HR/Legal/IT) als auch technische Nachweise enthalten. Dazu gehören mindestens Tenant- und Objekt-IDs, Änderungen an Aufbewahrung, der Zeitpunkt des Lizenzentzugs sowie die Information, ob Postfach/OneDrive übergeben, konvertiert oder gelöscht wurde. Für spätere Audits ist außerdem relevant, wer Zugriff auf verbleibende Inhalte erhielt und wann diese Berechtigungen wieder entzogen werden.

• Identitätsnachweis: Benutzerprinzipalname und IDs erfassen, z. B. Get-MgUser -UserId user@domain.tld | Select-Object Id,UserPrincipalName,AccountEnabled.
• Retention/Hold-Status belegen: Exchange-Hold prüfen, z. B. Get-Mailbox user@domain.tld | Select-Object LitigationHoldEnabled,LitigationHoldDate,LitigationHoldOwner; fallbezogene Holds im Purview-Fall dokumentieren (Fallname, Scope, Start-/Enddatum, Kriterien).
• Lösch- und Wiederherstellungsentscheidungen: Datum der Kontolöschung, geplante Aufbewahrungsdauer und verantwortliche Freigabeinstanz festhalten; bei Soft-Delete/Restore-Fenstern den Zeitpunkt für „Point of no Return“ dokumentieren (workloadabhängig).
• Zugriffskontrolle nach Offboarding: Delegationen und Berechtigungen mit Zeitbezug dokumentieren, z. B. Get-MailboxPermission sharedmailbox@domain.tld
Get-RecipientPermission sharedmailbox@domain.tld.

Wenn Audit-Logs und Change-Historien genutzt werden, sollten sie als Quelle referenziert werden, nicht als Ersatz für eine Offboarding-Akte. Entscheidender ist, dass die Dokumentation die Kette von der Anforderung (Austritt) über die Compliance-Entscheidung (Retention/Hold) bis zur technischen Ausführung (Konvertierung/Löschung, Berechtigungen, Zeitpunkte) ohne Interpretationsspielraum nachvollziehbar macht.