Von der Grundlage zur KI – der Reifegradpfad vom MVP zur KI-bereiten Datensicherheit

Wo der MVP endet, beginnt der Reifegradpfad

Die Artikel eins und zwei haben die Lücke und das Fundament beschrieben. Dieser dritte Artikel behandelt den Weg: wie eine Organisation von einem funktionierenden MVP zu der KI-bereiten Datensicherheitslage gelangt, die der Data Security Index 2026 vor Augen hat. Der Weg hat klar abgegrenzte Stufen, eine eindeutige Reihenfolge und – das ist wichtig – eine Reihe von Grenzfällen, die unterwegs auftauchen und über die kein Marketing-Dokument freiwillig spricht.

Eine Organisation, die den MVP abgeschlossen hat, verfügt über einen klassifizierten Datenbestand mit dem Standardlabel Gelb, drei labelbasierte DLP-Richtlinien für die wichtigsten M365-Workloads sowie drei IRM-Richtlinien für Sicherheitsverstöße, Datenlecks und Diebstahl durch ausscheidende Mitarbeitende. Das ist die Ausgangsposition. Was folgt, ist eine bewusste Abfolge, keine Einkaufsliste.

Stufe 1: Vertiefung des Klassifizierungsschemas

Drei Labels reichen für den Start. Sie reichen nicht aus, um langfristig die Anforderungen der DSGVO, von NIS-2, BaFin oder TISAX zu erfüllen. Nach drei bis sechs Monaten produktivem MVP-Betrieb erweitern wir das Schema um Unterlabels unterhalb von Gelb und Rot.

Das entscheidende Designprinzip: Unterlabels wirken auf der Schutzebene, nicht auf der Auswahlebene. Der Nutzer wählt weiterhin nur zwischen Grün, Gelb oder Rot. Das System leitet die feinere Klassifizierung ab, indem es die Nutzerwahl mit automatisierter Erkennung von Sensitive Information Types (SIT) kombiniert und die entsprechende Schutzmaßnahme anwendet. Konfiguriert wird das in Purview Information Protection über Auto-Labeling-Bedingungen auf den Unterlabels.

Das Ergebnis: regulatorische Granularität ohne zusätzliche kognitive Last für den Nutzer.

Stufe 2: Aktivierung von Data Security Posture Management

DSPM in Microsoft Purview erreichte Mitte Juni 2026 die allgemeine Verfügbarkeit (General Availability). Es liefert zentralisierte Einblicke, Empfehlungen und Behebungsmaßnahmen zur Verbesserung der Datensicherheitslage über Microsoft 365, Azure, Fabric und SaaS-Plattformen von Drittanbietern hinweg. Statt sich auf Endpunkte oder Infrastruktur zu konzentrieren, stellt DSPM die Daten selbst in den Mittelpunkt: wo sie liegen, wer darauf zugreifen kann, wie sie genutzt werden und ob sie angemessen geschützt sind.

Hier der entscheidende Punkt, den auch die Microsoft-Security-Workshop-Dokumentation explizit festhält: Der Wert von DSPM hängt davon ab, dass die Grundlagen bereits vorhanden sind – konkret SITs, Sensitivity Labels, DLP und Insider Risk Management. Ohne Labels gibt es keinen aussagekräftigen Posture Score. Ohne DLP-Richtlinien gibt es keine messbare Schutzabdeckung. Ohne IRM-Signale gibt es keine kontextualisierten Risikonarrative.

Eine Organisation, die den MVP aufgebaut hat, kann DSPM aktivieren und sofort verwertbare Daten sehen:

• wie viele sensible Assets gelabelt sind
• wie viele durch mindestens eine DLP-Richtlinie geschützt sind
• wie viele Nutzer als potenziell risikobehaftet markiert sind
• welche Empfehlungen priorisiert werden sollten

DSPM generiert Empfehlungen auf Basis der Nutzeraktivität der letzten 30 Tage und des Zustands ungeschützter sensibler Assets, und jede Empfehlung lässt sich mit einem Klick in eine DLP- oder IRM-Richtlinie umwandeln. Eine Organisation, die DSPM ohne den MVP aktiviert, sieht leere Kacheln und generische Vorschläge.

Stufe 3: SOC-Integration über Defender XDR und Sentinel

Datensicherheitssignale müssen in den größeren Workflow für Bedrohungserkennung und -reaktion einfließen. Im Microsoft-Stack bedeutet das: IRM-Alarme, DLP-Alarme und DSPM-Empfehlungen werden in die Defender-XDR-Plattform und Microsoft Sentinel integriert, für eine einheitliche SOC-Triage. Playbooks legen fest, wie ein Analyst mit einem hochprioren IRM-Alarm umgeht, wann eine Eskalation an HR oder Rechtsabteilung erfolgt und wie die forensische Spur dokumentiert wird.

Diese Integration ergibt Sinn, sobald der MVP verlässliche Signale liefert. Davor ist sie zwecklos – das SOC hat nichts, worauf es reagieren könnte.

Stufe 4: Absicherung der GenAI-Nutzung durch Mitarbeitende

Der erste der beiden KI-Stränge, die der Index beschreibt, ist der Schutz vor unerwünschter GenAI-Nutzung durch Mitarbeitende. Die Zahlen sind eindeutig: 47 Prozent der befragten Organisationen implementieren mittlerweile spezifische GenAI-Kontrollen, gegenüber 39 Prozent im Vorjahr. Oberste Priorität, genannt von 42 Prozent, ist es, zu verhindern, dass sensible Daten in GenAI-Tools hochgeladen werden.

Die Umsetzung beginnt mit Sichtbarkeit. Microsoft Defender for Cloud Apps liefert das erste verlässliche Inventar der tatsächlich in der Organisation genutzten GenAI-Dienste. Regelmäßig entdecken wir dabei Dutzende einzelne KI-Dienste, von denen die IT nichts wusste. Der nächste Schritt: Einteilung in freigegeben, toleriert und gesperrt.

Die wichtigste Erkenntnis aus unserer Praxis: reines Blockieren scheitert. Mitarbeitende finden Workarounds – und zwar umso entschlossener, je nützlicher der gesperrte Dienst ist. Die wirksame Strategie ist immer zweigleisig: das Schädliche blockieren UND eine attraktive, freigegebene Alternative bereitstellen. In den meisten Fällen ist diese Alternative Microsoft 365 Copilot, ergänzt durch ein internes Enterprise-LLM-Angebot über Azure OpenAI.

Seit Ende 2024 umfasst Purview Insider Risk Management außerdem eine Richtlinienvorlage „Risky AI usage“, die erkennt, wenn Nutzer sensible Informationen in generative KI-Tools eingeben oder wenn KI-generierte Antworten vertrauliche Daten enthalten. Diese Vorlage wird erst nutzbar, wenn die Klassifizierungsgrundlage des MVP steht – sie benötigt Labels und SITs, um zu bestimmen, was als sensibel gilt.

Grenzfall 1: Copilot trifft auf übermäßig freigegebenes SharePoint

Microsoft 365 Copilot greift auf alle Inhalte zu, für die der anfragende Nutzer berechtigt ist. Das entspricht dem etablierten Berechtigungsmodell und ist technisch korrekt. In der Praxis ist es problematisch, weil Berechtigungen in den meisten SharePoint-Umgebungen nicht so restriktiv sind, wie sie sein sollten. Websites mit der Berechtigung „Everyone except external users“ sind die Regel, nicht die Ausnahme. Websites, die vor Jahren für ein Projekt angelegt und nie aufgeräumt wurden, enthalten sensible Informationen, auf die jeder Mitarbeitende zugreifen kann. Solange niemand aktiv danach sucht, fällt das nicht auf. Sobald Copilot ausgerollt wird, kommt es sofort zutage – aggregiert und in einer flüssigen Antwort präsentiert.

Die Lösung ist mehrschichtig:

Sensitivity Labels mit Container-Geltungsbereich:

Wird ein Sensitivity Label auf „Groups & sites“ ausgeweitet, steuert das Label websiteweite Einstellungen, darunter externes Teilen, Datenschutzstufe und Zugriff von nicht verwalteten Geräten. Neue Websites übernehmen ihr Container-Label und erzwingen so eine einheitliche Basis.

Restricted Content Discovery (RCD):

RCD ist Teil von SharePoint Advanced Management und seit Mai 2025 allgemein verfügbar. Es verhindert, dass bestimmte Websites in organisationsweiten Suchergebnissen und Copilot-Antworten erscheinen, sofern ein Nutzer nicht Eigentümer ist oder kürzlich mit Inhalten auf diesen Websites interagiert hat. Es ersetzt die ältere Restricted SharePoint Search (RSS), die Microsoft einstellt: Die Neuaktivierung von RSS wird ab dem 31. Juli 2026 blockiert, die vollständige Einstellung erfolgt am 31. Januar 2027. Organisationen, die RSS noch nutzen, müssen zu RCD migrieren oder die zugrunde liegenden Berechtigungen bereinigen, bevor RSS die Durchsetzung einstellt. RCD ist der richtige Mechanismus für die Übergangszeit, während Berechtigungen bereinigt werden.

DLP für Microsoft 365 Copilot:

Microsoft Purview unterstützt inzwischen einen eigenen Copilot-DLP-Standort. Damit lassen sich DLP-Richtlinien erstellen, die sensible Inhalte in Copilot-Interaktionen erkennen und blockieren. Wichtige technische Einschränkung: Innerhalb des Copilot-Standorts lassen sich SIT-Bedingungen und Sensitivity-Label-Bedingungen nicht in derselben Regel kombinieren. Es lassen sich jedoch separate Regeln für jede innerhalb derselben Richtlinie anlegen.

Bereinigung der Berechtigungen:

Der unangenehmste, aber notwendigste Schritt. Der Purview Data Security Posture Agent (GA Mitte Juni 2026) und die wöchentlichen Datenbewertungen von DSPM for AI für die Top-100-SharePoint-Websites, die von Copilot genutzt werden, helfen dabei, die Websites mit dem höchsten Overshare-Risiko zu identifizieren. Aber die Berechtigungen muss trotzdem jemand bereinigen. Das dauert typischerweise Monate und ist ohne Tool-Unterstützung durch SharePoint Advanced Management oder Governance-Tools von Drittanbietern kaum zu leisten.

Grenzfall 2: Autonome Agenten und Berechtigungsgrenzen

Der zweite Grenzfall geht über Copilot als Assistent hinaus, hin zu agentischen Systemen, die längere Aufgabenketten im Namen eines Nutzers ausführen: Meetings koordinieren, Dokumente zusammenstellen, E-Mails entwerfen, Tickets anlegen. Diese Agenten operieren im Sicherheitskontext des delegierenden Nutzers, handeln aber asynchron und können Hunderte Aktionen in Sekunden auslösen.

Die klassische Architektur der Datensicherheit setzt synchrone, nutzergesteuerte Aktionen voraus: Ein Mensch öffnet ein Dokument, eine DLP-Prüfung läuft, eine Entscheidung wird getroffen. Bei agentischen Systemen bricht diese Annahme zusammen. Ein Agent kann Daten kombinieren, die einzeln betrachtet unbedenklich sind, in Summe aber sensibel. Er kann Aktionen in einer Abfolge ausführen, die nicht unmittelbar nachvollziehbar ist. Und er kann innerhalb eines Berechtigungsumfangs handeln, den der delegierende Nutzer zwar technisch besitzt, im normalen Arbeitsalltag aber nie ausgeschöpft hätte.

Microsoft begegnet dem mit eigenständigen Agenten-Identitäten, die separat von Nutzerkonten verwaltet werden, fein granularen Berechtigungsumfängen je Aufgabe und Laufzeit-Richtlinien, die Agentenaktionen vor der Ausführung bewerten. Organisationen, die schon heute mit agentischen Systemen arbeiten, sollten diese Mechanismen aktiv einsetzen und akzeptieren, dass Agentensicherheit eine junge Disziplin ist, die sich in den kommenden zwei Jahren noch erheblich weiterentwickeln wird.

Stufe 5: KI innerhalb der Sicherheitsfunktion einsetzen

Der zweite KI-Strang ist der Einsatz von GenAI innerhalb der Datensicherheits-Operationen. Der Index berichtet, dass 82 Prozent der Organisationen dafür Pläne entwickelt haben – ein Anstieg um 18 Prozentpunkte gegenüber 64 Prozent. Die wichtigsten Einsatzbereiche sind das Auffinden sensibler Daten (44 %), das Erkennen kritischer Risiken (43 %), die Untersuchung von Vorfällen (43 %), die Bewertung der Sicherheitslage (42 %), die Absicherung der Umgebung (41 %) und die Feinabstimmung von Richtlinien (38 %).

Seit November 2025 ist Security Copilot in Microsoft 365 E5-Lizenzen enthalten, was für viele Organisationen die Lizenzierungshürde beseitigt. Drei spezialisierte Purview-Agenten stehen inzwischen zur Verfügung:

Triage Agent for DLP

Bewertet DLP-Alarme risikobasiert und ordnet sie Prioritätskategorien zu, was die Triage-Zeit für Analysten reduziert.

Triage Agent for IRM

Priorisiert Insider-Risk-Management-Alarme und hebt diejenigen hervor, die menschliche Aufmerksamkeit erfordern.

Data Security Posture Agent

Ermöglicht Abfragen in natürlicher Sprache über Dateien, E-Mails und Copilot-Interaktionen hinweg, direkt innerhalb der DSPM-Oberfläche.

Jeder dieser Agenten beschleunigt einen Workflow, den erst das Fundament des MVP ermöglicht. Der Triage Agent for DLP braucht DLP-Richtlinien, damit es überhaupt Alarme zu triagieren gibt. Der IRM Triage Agent braucht IRM-Richtlinien, damit es Risiken zu priorisieren gibt. Der DSPM-Agent braucht gelabelte Inhalte und Klassifizierungssignale, um aussagekräftige Antworten zu liefern. Ohne den MVP haben diese Agenten nichts, womit sie arbeiten können.

Grenzfall 3: Unterstützende KI vs. entscheidende KI

Der Index berichtet, dass 39 Prozent der Organisationen bereits GenAI-Agenten für die Datensicherheit einsetzen. Die wichtigsten Anwendungsfälle decken eine große Bandbreite an Autonomie ab: das Erkennen kritischer Risiken (40 %), das automatische Schützen und Klassifizieren von Daten (36 %), die Untersuchung von Vorfällen (35 %), das Aussprechen von Empfehlungen (35 %), die Reduzierung von Fehlalarmen (35 %). Gleichzeitig äußern 38 Prozent der Entscheidungsträger Bedenken gegenüber Agenten, die ohne ordnungsgemäße Freigabe oder menschliche Aufsicht eingesetzt werden.

Diese Spannung prägt die nächste Phase. Unsere Empfehlung: eine klare Trennlinie zwischen unterstützender KI und entscheidender KI ziehen.

Unterstützende KI:

Fasst Alarme zusammen, entwirft Untersuchungsberichte, schlägt Richtlinienanpassungen vor. Der menschliche Analyst bleibt der Entscheider. Security Copilot und die Purview Triage Agents fallen in diese Kategorie. Früh einsetzen, breit einsetzen – das Risiko ist begrenzt.

Entscheidende KI:

Trifft Durchsetzungsentscheidungen: eine Freigabe blockieren, eine Berechtigung entziehen, an HR eskalieren. Diese Kategorie erfordert ein eigenes Governance-Framework, einen eigenen Freigabeprozess und eine eigene Audit-Spur. Adaptive Protection ist das prominenteste Beispiel – es passt die DLP-Durchsetzung automatisch anhand der IRM-Risikostufen an. Es ist leistungsstark und gut konzipiert, bleibt aber eine automatisierte Durchsetzungsaktion, weshalb Organisationen es mit klaren Eskalationspfaden und regelmäßigen Überprüfungen der Risikostufen-Zuweisungen einsetzen sollten.

Die Trennlinie zwischen unterstützender und entscheidender KI ist die neue Grenze, die jede datensicherheitsorientierte Organisation definieren muss. Der Index erkennt das an, wenn er berichtet, dass Verantwortliche die Bedeutung betonen, den Menschen in der Entscheidungsschleife zu behalten (Human in the Loop).

Das Zwölf-bis-achtzehn-Monats-Ziel

Was sollte eine Organisation, die heute mit dem MVP startet, in zwölf bis achtzehn Monaten erreichen können? Die Antwort:

• Einen klassifizierten Datenbestand, in dem mindestens 80 Prozent der aktiv genutzten Inhalte ein Label tragen
• DLP-Richtlinien über die drei MVP-Richtlinien hinaus, die branchenspezifische SITs abdecken
• Ein IRM-Programm mit aktivierten Analytics für Mustererkennung über einzelne Auslöser hinaus, plus die Vorlage „Risky AI usage“
• DSPM im produktiven Betrieb mit regelmäßigen Posture-Reviews
• Copilot ausgerollt, mit RCD und DLP für Copilot bereits im Einsatz
• Erste unterstützende KI-Anwendungsfälle im produktiven Einsatz, mit klarer Trennung von entscheidender KI
• Eine datengestützte, messbare Antwort auf die Frage: Wo stehen wir im Verhältnis zum Data Security Index – nicht als Selbsteinschätzung in einer Umfrage, sondern als überprüfbare Kennzahlen im eigenen Tenant

Eine Organisation, die diesen Weg geht, kommt dort an, wo der Index die Vorreiter verortet. Nicht, weil sie am ersten Tag einen Marathon versucht hat, sondern weil sie mit drei Labels, drei Richtlinien und der Disziplin begonnen hat, von dort aus weiterzubauen.

Wo man anfängt

Der Data Security Index 2026 endet mit dem Aufruf, zu integrieren, zu konsolidieren und KI einzuführen. Der Richtung stimmen wir zu. Dem implizierten Ausgangspunkt stimmen wir nicht zu. Für die überwiegende Mehrheit der Organisationen ist der erste Schritt nicht DSPM, nicht Security Copilot und kein KI-Agent. Der erste Schritt ist ein Label, eine Standardeinstellung und eine Richtlinie. Drei Farben. Ein Fundament. Alles Weitere folgt von dort aus.

Wer diesen Weg starten möchte, meldet sich bei uns. Wir begleiten die MVP-Einführung, wir begleiten den Reifegradpfad, und wenn die Zeit reif ist, gehen wir die KI-Themen an, die heute noch nach Zukunftsmusik klingen, aber im nächsten Data Security Index als gelebte Realität erscheinen werden.