M365 Entropie

Die meisten CIOs in Schweizer KMU gehen davon aus, dass ihre Microsoft-365-Umgebung unter Kontrolle ist. Lizenzen sind zugewiesen. Sicherheitsrichtlinien existieren. Offboarding ist dokumentiert, automatisiert und umgesetzt. Die Rechnung ist stabil. Nichts wirkt ausser Kontrolle.

Und doch zeigen sich in fast jedem Tenant, der seit zwei oder drei Jahren im Betrieb ist, immer wieder dieselben Muster:

• Lizenzen, die die tatsächlichen Arbeitsmuster nicht mehr widerspiegeln.
• Konten ohne klaren Verantwortlichen.
• Sicherheitsfunktionen, die lizenziert, aber nicht durchgesetzt werden.
• Zugriff auf Strukturen, die eher die Geschichte der Organisation widerspiegeln als die aktuelle Realität.
  
• Der Zugriff entspricht nicht mehr der Rolle.
  
• Die Lizenz entspricht nicht mehr dem Arbeitsmuster.
• Das Sicherheitsniveau passt nicht mehr zur tatsächlichen Risikosituation.
  

Das ist keine Inkompetenz. Das ist Entropie. Und Entropie in digitalen Systemen ist strukturell bedingt.

Drift ist ein Merkmal des Wandels.

Organisationen verändern sich ständig. Rollen entwickeln sich weiter. Abteilungen werden umstrukturiert. Projekte beginnen und enden. Lieferanten kommen und gehen. Die Sicherheitsanforderungen steigen. Preismodelle ändern sich.

Microsoft 365 passt sich jedoch nicht automatisch an organisatorische Veränderungen an.
Eine im Jahr 2022 zugewiesene Lizenz überprüft sich im Jahr 2026 nicht selbst. Eine Conditional-Access-Richtlinie passt sich nicht automatisch an, wenn sich das Risikomodell verändert. Eine während einer Migration erstellte Zugriffsgruppe verschwindet nicht einfach, wenn das Projekt abgeschlossen ist.

Das System sammelt Entscheidungen. Mit der Zeit wird der Mandant zu einer Art historischer Schicht der Organisatio, statt ein klares Abbild der aktuellen Betriebsstruktur zu sein. Diese Akkumulation nennen wir Identity Entropy.

Wie Entropie in der Praxis aussieht

Entropie in Microsoft 365 zeigt sich selten dramatisch. Sie entsteht schrittweise im Alltag. Einige typische Beispiele aus Schweizer KMU-Umgebungen:

Eine Finanzanalystin wechselt in die regulatorische Berichterstattung, behält aber eine Business-Standard-Lizenz ohne erweiterte Data-Loss-Prevention-Funktionen.
Ein Projektadministrator wird Linienvorgesetzter, behält jedoch eine E3-Lizenz mit breitem SharePoint-Zugriff, den er nicht mehr benötigt. Nach einer Vorstandssitzung wird ein Security-Add-on gekauft, aber nur teilweise implementiert, weil die Einführung komplex ist.
Ein Konto für einen externen Berater bleibt lange nach Projektende aktiv.

Keines dieser Ereignisse erzeugt einen Alarm. Für sich genommen wirkt jedes nachvollziehbar. Zusammen erzeugen sie Drift.

Das System funktioniert weiterhin. Aber es spiegelt das beabsichtigte Design nicht mehr wider. In dieser Lücke zwischen Funktion und Design sammelt sich das Governance-Risiko an.

Warum Kompetenz nicht ausreicht

Viele KMU gehen davon aus, dass Drift entsteht, weil IT-Teams unterbesetzt oder nachlässig sind. In Wirklichkeit entsteht sie selbst in gut geführten Umgebungen. Der Grund ist einfach: Organisationen verändern sich schneller, als Governance-Prozesse überprüfen können.

In vielen KMU erfolgt das Offboarding noch manuell. Lizenzen werden einmal pro Jahr oder bei Bedarf überprüft. Sicherheitsfunktionen werden schrittweise eingeführt. Eine regelmässige Überprüfung der Zuordnung von Rollen und Zugriffsrechten existiert oft nicht.

Gleichzeitig wechseln Mitarbeitende Rollen, Projekte entstehen und enden, regulatorische Anforderungen steigen, und Microsoft verändert kontinuierlich Lizenzmodelle und Funktionsgrenzen.

Der Tenant entwickelt sich dadurch schneller als das Governance-Modell. Das ist kein Versagen der IT. Es ist ein strukturelles Problem.

Wer diesen Unterschied erkennt, beginnt Governance bewusst zu steuer, statt Drift nur zu korrigieren, wenn sie sichtbar wird.

Lizenzen sind eine Kontrollschicht – keine Rechnungsposition.

Ein Grund, warum Entropie lange unbemerkt bleibt, liegt in der Wahrnehmung von Lizenzierung. In vielen Organisationen wird sie als kommerzielles Thema betrachtet, etwas zwischen IT und Einkauf, überprüft, wenn sich Rechnungen ändern.

In Microsoft 365 erfüllen Lizenzen jedoch eine andere Funktion. Sie bestimmen, welche Sicherheitsfunktionen verfügbar sind: Conditional Access, Data Loss Prevention, Privileged Identity Management oder Defender-Schutz. Lizenzierung ist damit eine zentrale Kontrollschicht des Betriebsmodells.

Wenn sich Rollen verändern, die Lizenzzuweisungen jedoch nicht, entsteht eine Lücke zwischen Organisation und Kontrolle. Aus Governance-Sicht ist das kein Kostenproblem, sondern eine Fehlanpassung der Sicherheits- und Zugriffskontrollen.

Kostenabweichungen fallen auf, wenn Rechnungen steigen. Fehlende Sicherheitsdurchsetzung bleibt oft jahrelang unbemerkt.

Wie sich diese Lücke konkret durch Rollendrift entwickelt, betrachten wir in Blog 3.

Die stille Wirkung von Entropie

Entropie entsteht selten durch einen einzelnen Fehler. Sie wächst langsam. Eine leicht überdimensionierte Lizenz hier. Ein ruhendes Konto dort. Eine Sicherheitsfunktion, die zwar lizenziert, aber nie vollständig aktiviert wurde.

Für sich genommen wirkt jedes dieser Details harmlos. Über Jahre hinweg summieren sie sich jedoch: Kosten steigen, Governance-Schulden wachsen, Audit-Risiken nehmen zu, und ähnliche Rollen erhalten unterschiedliche Sicherheitsniveaus. Gleichzeitig sinkt die Transparenz. Mit der Zeit wird es schwierig zu erkennen, welche Architektur bewusst gestaltet wurde und was nur historischer Rest ist.

Für CIOs entsteht so eine gefährliche Illusion: Die Rechnungen sind stabil, grössere Incidents bleiben aus, und nichts wirkt offensichtlich falsch. Doch operative Systeme können lange stabil erscheinen, obwohl ihre Governance bereits deutlich vom ursprünglichen Design abweicht.

Ruhekonten, die in Blog 2 ausführlich behandelt werden, sind einer der konkretesten Ausdrucksformen dieses Zinseszinseffekts. Sie sind der ungenutzte Raum, der entsteht, wenn die Personalabgänge hinter den organisatorischen Veränderungen zurückbleiben, und sie veranschaulichen, wie einzeln harmlos erscheinende Lücken im Laufe der Zeit insgesamt an Bedeutung gewinnen.

Entropie ist vorhersehbar, was bedeutet, dass sie kontrollierbar ist.

Hier ist die entscheidende Erkenntnis:

Jede Microsoft-365-Umgebung mit Rollenwechseln, organisatorischem Wachstum und mehrjährigem Betrieb entwickelt Drift. Die Frage ist nicht, ob Entropie entsteht, sondern ob sie aktiv gemanagt wird.

In anderen Bereichen ist diese Logik selbstverständlich. Produktionssysteme werden regelmässig neu kalibriert. Finanzkontrollen werden abgestimmt. Qualitätsmanagement folgt festen Review-Zyklen.

Digitale Identitäten und Lizenzen erhalten diese Disziplin selten, obwohl sie definieren, wer in der Organisation auf welche Systeme und Daten zugreifen kann.

Vom Aufräumen zum Re-Baselining

Die meisten Organisationen reagieren auf Drift erst, wenn sie sichtbar wird. Eine steigende Rechnung löst eine Lizenzanalyse aus. Ein Audit führt zu einem Access-Cleanup. Ein Security-Incident zu einer Konfigurationsprüfung.

Das ist ereignisgetriebene Governance: Probleme werden nach ihrer Sichtbarwerden behoben.

Operative Reife erfordert etwas anderes: strukturiertes Re-Baselining. Dazu gehört, Lizenzzuweisungen regelmässig mit der tatsächlichen Nutzung abzugleichen, Rollen mit Zugriffsrechten zu überprüfen, ruhende Identitäten systematisch zu identifizieren und Sicherheitskonfigurationen an die aktuelle Bedrohungslage anzupassen.

Nicht weil etwas kaputt ist, sondern weil Drift unvermeidlich ist und Korrekturen früh günstiger sind als später. Dieser Übergang von reaktivem Cleanup zu strukturiertem Re-Baselining ist der rote Faden dieser Blogserie.  Blog 4 beleuchtet einen besonders risikoreichen Bereich: externe Identitäten und privilegierten Zugriff.
Blog 5 fasst die Erkenntnisse in einem praktischen Governance-Reifegradmodell für Schweizer KMU zusammen.

Eine Führungsaufgabe, keine IT-Aufgabe

Für CIOs in KMU ist Identitätsentropie keine Frage von Teamgrösse oder technischer Raffinesse. Es ist eine Frage der Perspektive.

Wird Microsoft 365 als statische Infrastruktur betrachtet, etwas, das im Hintergrund läuft und nur bei Rechnungen oder Incidents Aufmerksamkeit erhält, sammelt sich Entropie, bis sie als Kostenanstieg, Audit-Finding oder Security-Problem sichtbar wird.

Wird es hingegen als dynamisches Betriebssystem verstanden, das regelmässig neu kalibriert werden muss, werden Korrekturen zur Routine statt zur Krise. Operative Exzellenz bedeutet nicht Perfektion. Sie bedeutet, zu akzeptieren, dass Systeme ohne strukturierte Aufmerksamkeit drift erzeugen – und Governance-Rhythmen zu etablieren, die diese Realität berücksichtigen.

Identitätsentropie ist nicht dramatisch. Sie kündigt sich nicht an. Sie löst keine dringenden Warnmeldungen aus. Aber sie verändert still und leise die Beziehung zwischen Rollen, Zugriff und Kontrolle – und in einem digital abhängigen KMU definiert diese Beziehung die operative Widerstandsfähigkeit.

Die entscheidende Frage lautet daher nicht, ob Entropie in Ihrem Tenant existiert.
Sie existiert mit hoher Wahrscheinlichkeit.

Die entscheidende Frage ist: Behandeln Sie Microsoft 365 als lebendes Betriebssystem, das regelmässiges Re-Baselining benötigt oder als Toolset, das erst Aufmerksamkeit bekommt, wenn Rechnungen oder Incidents es erzwingen?

Diese Entscheidung bestimmt die Reife Ihres Governance-Modells. In dynamischen Umgebungen zeigt sich Reife nicht durch Stabilität – sondern dadurch, wie bewusst Drift korrigiert wird, bevor sie sich verstärkt.

Im Blog2, der in Kürze veröffentlicht wird (melden Sie sich hier an, um benachrichtigt zu werden), werden wir uns mit einer der häufigsten und am meisten unterschätzten Ausdrucksformen von Identitätsentropie befassen: ruhende Konten und die Governance-Schulden, die sie im Laufe der Zeit still und leise anhäufen.