Ein gesperrtes Benutzerkonto ist noch kein vollständiges Offboarding

Am letzten Arbeitstag wird das Microsoft-365-Konto gesperrt. Damit ist ein wichtiger Zugriff beendet – aber noch nicht zwingend das Offboarding. Die Person kann weiterhin alleiniger Owner eines Teams sein, einen automatisierten Ablauf betreiben, als Kontakt in einem Kundenprozess stehen oder Daten besitzen, die niemand übernommen hat.

Ein Benutzerkonto verbindet nicht nur eine Person mit Anwendungen. Es trägt Berechtigungen, Eigentum, Kommunikationswege, Gerätebeziehungen, Lizenzen und technische Abhängigkeiten. Offboarding muss diese Verbindungen kontrolliert lösen oder übertragen.

Das Ziel ist deshalb zweigeteilt: Nicht mehr benötigte Zugriffe werden zum richtigen Zeitpunkt wirksam beendet, während notwendige Geschäftsinformationen und Verantwortungen rechtmäßig und nachvollziehbar weitergeführt werden.

Der Austritt ist ein fachliches Ereignis

Die IT kann ein Offboarding nur rechtzeitig ausführen, wenn ein verlässlicher Auslöser vorhanden ist. Maßgeblich sind nicht Gerüchte oder ein verspätetes Ticket, sondern ein bestätigtes Ereignis mit eindeutigen Angaben:

• betroffene Person und Identität,
• Art des Austritts oder Rollenwechsels,
• wirksamer Zeitpunkt und Zeitzone,
• besondere Dringlichkeit,
• zuständige Führungskraft,
• notwendige Übergaben und Ausnahmen,
• Ansprechpartner für rechtliche oder personalbezogene Entscheidungen.

HR oder eine andere personalverantwortliche Stelle bestätigt das Ereignis. Die Führungskraft entscheidet, welche Aufgaben, Daten und fachlichen Verantwortungen übergehen. Die IT setzt Zugriff und technische Übergaben um. Datenschutz, Recht oder Compliance entscheiden über besondere Aufbewahrungs- und Zugriffsfälle.

Diese Trennung verhindert, dass Administratoren unter Zeitdruck über Personalstatus, Einsicht in Inhalte oder Aufbewahrungszwecke entscheiden müssen.

Vier Phasen statt eines Löschknopfs

Ein belastbarer Ablauf unterscheidet vier Phasen.

1. Zugriff zum wirksamen Zeitpunkt beenden

Die unmittelbare Sicherheitsaufgabe umfasst je nach Umgebung:

• Anmeldung blockieren und aktive Sitzungen oder Tokens widerrufen,
• privilegierte Rollen und Notfallzugänge entfernen,
• Zugriffe auf lokale Verzeichnisse, VPN und Fachanwendungen beenden,
• Geräte sperren, zurücknehmen oder Unternehmensdaten entfernen,
• API-Schlüssel, persönliche Zertifikate und an die Person gebundene Geheimnisse behandeln,
• externe SaaS- und Lieferantenzugänge einbeziehen.

Das Passwort nur zu ändern, reicht nicht in jeder Architektur. Bestehende Sitzungen, App-Kennwörter, Zertifikate oder externe Konten können anderen Regeln folgen.

2. Verantwortung und laufende Arbeit übergeben

Danach geht es um Betriebsfähigkeit:

• Wer übernimmt Teams, Gruppen, SharePoint-Sites und Funktionspostfächer?
• Welche Flows, Skripte, Integrationen oder Zeitpläne liefen unter der persönlichen Identität?
• Wer übernimmt offene Freigaben, Tickets, Projekte und Lieferantenkontakte?
• Welche Kalender, Verteiler oder Rufgruppen müssen angepasst werden?
• Welche extern geteilten Inhalte bleiben notwendig?

Ein deaktiviertes Konto darf nicht zum dauerhaften technischen Anker werden. Wo ein Prozess von einer persönlichen Identität abhängt, sollte er auf eine geeignete Rolle, Gruppe oder verwaltete technische Identität umgestellt werden.

3. Daten bewusst aufbewahren, übertragen oder löschen

Geschäftliche Daten dürfen nicht pauschal „für alle Fälle“ kopiert werden. Vor einer Übergabe sind Zweck, Berechtigung, Umfang und Frist zu klären. Persönliche oder besonders schützenswerte Inhalte können zusätzliche Grenzen erzeugen.

Die aktuelle Microsoft-Anleitung zum Entfernen ehemaliger Beschäftigter zeigt produktspezifische Schritte für Postfach, OneDrive, mobile Geräte, Weiterleitung, Lizenz und Kontolöschung. Die dokumentierten Aufbewahrungsfristen und Produktverhalten sind keine allgemeine Archivierungsstrategie. Sie müssen zum Rechts- und Aufbewahrungskonzept der Organisation passen und können sich mit Produktänderungen ändern.

4. Ausführung und Restabhängigkeiten verifizieren

Der Prozess endet nicht mit dem letzten Administrationsklick. Ein Abschlussnachweis prüft:

• Ist die Anmeldung tatsächlich blockiert?
• Sind privilegierte und externe Zugänge entfernt?
• Haben übernommene Owner ihre Verantwortung bestätigt?
• Funktionieren kritische Abläufe ohne das alte Konto?
• Sind Geräte und Lizenzen korrekt behandelt?
• Besitzen befristete Aufbewahrungen einen Lösch- oder Prüftermin?
• Sind Fehler und manuelle Ausnahmen sichtbar nachverfolgt?

Konstruiertes Beispiel: Der Zugang ist weg, der Prozess bleibt hängen

Das folgende Beispiel ist konstruiert.

Ein Projektleiter verlässt das Unternehmen. Sein Konto wird pünktlich gesperrt und die Microsoft-365-Lizenz wird für einen neuen Mitarbeiter frei. Einige Tage später fällt auf, dass er alleiniger Owner eines Teams war. Ein wichtiger Freigabe-Flow läuft mit seiner Verbindung, und mehrere externe Partner greifen über persönlich erteilte Freigaben auf Projektunterlagen zu.

Das Sicherheitstor hat funktioniert: Die Person kann sich nicht mehr anmelden. Die betriebliche Übergabe hat nicht funktioniert: Zuständigkeit, Automatisierung und Informationszugriff waren an die Identität gekoppelt und wurden nicht neu entschieden.

Die Lösung ist nicht, das Konto dauerhaft lizenziert und aktiv zu halten. Der Prozess braucht eine Bestandsaufnahme der Abhängigkeiten, neue Owner, geeignete technische Identitäten und eine bewusste Entscheidung über externe Zugriffe und aufzubewahrende Daten.

Ownership ist ein eigenes Offboarding-Objekt

Mitgliedschaft und Eigentum sind nicht dasselbe. Ein Team kann andere Mitglieder besitzen und trotzdem keinen handlungsfähigen Owner mehr haben. Eine Anwendung kann von mehreren Personen genutzt werden, während nur eine Person Token, Abrechnung oder Herstellerkontakt kontrolliert.

Vor dem Austritt sollten daher mindestens geprüft werden:

• Microsoft-365-Gruppen und Teams mit Owner-Rolle,
• SharePoint-Sites und freigegebene Inhalte,
• Power-Automate-Flows und andere Automatisierungen,
• geteilte Postfächer, Verteiler und Kalender,
• Azure- oder Cloud-Ressourcen mit persönlicher Zuständigkeit,
• Fachanwendungen, Anbieterportale und Domainkonten,
• Dokumentationen, Schlüssel und Wiederherstellungscodes,
• offene Service-, Change- und Projektverantwortungen.

Der Beitrag „Ein Funktionspostfach braucht einen Process Owner“ vertieft, warum gemeinsamer Zugriff allein keine fachliche Verantwortung erzeugt. Beim Offboarding wird dieselbe Trennung besonders sichtbar.

Automatisierung beginnt mit verlässlichen Personaldaten

Microsoft Entra Lifecycle Workflows können Joiner-, Mover- und Leaver-Aufgaben anhand von Bedingungen und Auslösern automatisieren, Ausführungen protokollieren und Zugriffe entziehen. Die Funktion setzt laut aktueller Microsoft-Dokumentation passende Entra-ID-Governance- oder Entra-Suite-Lizenzen voraus.

Das Werkzeug löst jedoch keine unklaren Eingangsdaten. Eine Automatisierung benötigt:

• eine maßgebliche Quelle für Beschäftigungsstatus und Austrittszeitpunkt,
• eindeutige Identitätszuordnung,
• ausreichend frühe und vollständige Meldung,
• Regeln für geplante und sofortige Austritte,
• getestete Aufgaben und Fehlerbehandlung,
• einen manuellen Notweg,
• verantwortliche Personen für fehlgeschlagene Ausführungen.

Für kleine Umgebungen kann eine manuelle Checkliste mit Vier-Augen-Prüfung wirtschaftlicher sein. Entscheidend ist nicht der Automatisierungsgrad, sondern rechtzeitige, vollständige und nachweisbare Ausführung.

Geplantes und sofortiges Offboarding brauchen Varianten

Bei einem planmäßigen Austritt können Übergaben vor dem letzten Arbeitstag vorbereitet werden. Owner lassen sich ersetzen, Geräte termingerecht zurücknehmen und Daten mit der Führungskraft ordnen.

Ein sofortiger Austritt verlangt eine andere Reihenfolge:

1. bestätigte Anweisung und genauer Sperrzeitpunkt,
2. priorisierte Beendigung kritischer Zugriffe und Sitzungen,
3. Sicherung notwendiger Nachweise,
4. kontrollierte Behandlung von Geräten und externen Konten,
5. anschließende fachliche Übergabe und Bereinigung.

Die schnelle Variante darf nicht im freien Zuruf improvisiert werden. Sie benötigt vorab bekannte Entscheider, erreichbare Administratoren und einen dokumentierten Minimalablauf.

Die Offboarding-Karte

Eine Karte pro Austritt verbindet fachliche Anweisung und technische Ausführung.

Feld	Inhalt
Ereignis	bestätigte Person, Austrittsart, Zeitpunkt und meldende Stelle
Entscheider	HR, Führungskraft sowie Datenschutz oder Recht bei Bedarf
Identitäten	Cloud, lokales Verzeichnis, Fachanwendungen und externe Dienste
privilegierter Zugriff	Adminrollen, Notfallwege, Schlüssel, Zertifikate und Tokens
Geräte	Rückgabe, Sperre, Unternehmensdaten und lokale Zugänge
Ownership	Teams, Gruppen, Sites, Flows, Projekte und technische Ressourcen
Kommunikation	Postfach, Weiterleitung, Rufgruppen und externe Ansprechpartner
Daten	Übergabezweck, Empfänger, Umfang, Aufbewahrung und Löschtermin
Lizenzen und Verträge	Entzug, Wiederverwendung, Kündigung und Abhängigkeiten
Verifikation	technische Sperre, bestätigte Übernahme und offene Ausnahmen

Nicht jedes Feld trifft auf jede Person zu. Die Karte verhindert aber, dass das Konto zum einzigen betrachteten Objekt wird.

Die richtige Kennzahl ist nicht nur die freie Lizenz

Eine zurückgewonnene Lizenz zeigt einen wirtschaftlichen Effekt, aber nicht die Qualität des Offboardings. Aussagekräftiger sind:

• Zeit zwischen wirksamem Austritt und bestätigter Zugriffssperre,
• Anteil vollständig abgeschlossener Offboardings ohne überfällige Aufgabe,
• Zahl verwaister Owner- oder Automatisierungsabhängigkeiten,
• fehlgeschlagene technische Schritte und Zeit bis zur Korrektur,
• befristete Datenaufbewahrungen ohne verantwortlichen Prüftermin,
• nachträglich entdeckte externe oder privilegierte Zugänge.

Ein Prozess wirkt, wenn Zugriffe rechtzeitig enden und das Unternehmen gleichzeitig handlungsfähig bleibt. Offboarding ist damit weder reine HR-Administration noch ein Microsoft-365-Klickpfad. Es ist der kontrollierte Abschluss einer Identität samt ihrer technischen und organisatorischen Beziehungen.