Neues Jahr, neue Compliance-Funktionen – Microsoft 365 Compliance-Highlights Q1 2026

Management Summary

Microsoft 365 Compliance legt im Q1 2026 kräftig nach: Im ersten Quartal 2026 hat Microsoft zahlreiche neue Funktionen und Updates im Compliance-Umfeld (Microsoft Purview) veröffentlicht. Darunter fallen Verbesserungen beim Data Loss Prevention (DLP) (z. B. E-Mail-Zurückhaltung „Wait on Send“, DLP-Hinweise in Outlook für Mac, dynamische DLP-Geltungsbereiche für SharePoint) ebenso wie Insider Risk Management (vereinheitlichte Benutzeranalysen, OCR-Bilderkennung, erweiterte Grenzwerte) und Communication Compliance (feinere Alert-Konfiguration). Sensitivity Labels erhalten ein modernes Label-Gruppen-Modell zur einfacheren Verwaltung. Im Records Management heißt es Abschied nehmen von alten SharePoint-Compliance-Funktionen – Purview übernimmt nun vollständig die Archivierung und Aufbewahrung. Selbst Microsoft 365 Copilot lässt sich jetzt mit Purview-Tools sicherer steuern. Kurz: Viele sinnvolle Erweiterungen, um Daten noch besser zu schützen und Compliance einfacher zu machen – von verbesserten Warnungen bis zur automatisierten Datenlöschung.

Sofortmaßnahmen: Admins und Compliance-Verantwortliche sollten zügig prüfen, welche Neuerungen für ihr Unternehmen relevant sind. Einige Features (z. B. DLP-Purge/Delete-Funktion in Purview) sind standardmäßig aktiviert – informieren Sie Ihr Security-Team, damit es diese effektiv nutzt. Andere wie “Wait on Send” in Outlook erfordern Konfiguration (Mailbox-Parameter setzen). Überprüfen Sie Ihre aktuellen Compliance-Policies: Müssen sie angepasst werden, um neue Optionen (z. B. Adaptive Scope für DLP) auszuschöpfen? Wo alte SharePoint-Mechanismen im Einsatz sind, planen Sie die Migration zu Purview-Lösungen jetzt. Legen Sie ein kleines bereichsübergreifendes Team (IT, Compliance, Security) auf, um einen 90-Tage-Plan zu erstellen (siehe Aktionsplan weiter unten).

Risiken: Werden die Neuerungen ignoriert, drohen verpasste Chancen und Blind Spots in Ihrer Compliance-Strategie. Beispielsweise bleibt ohne „Wait on Send“ das Risiko bestehen, dass vertrauliche Daten per E-Mail versehentlich versendet werden, bevor DLP greift. Ohne Migration der alten SharePoint-Aufbewahrung verlieren Sie ab April 2026 Support – ein Ernstfall für regulierte Branchen. Auch neue Tools wie die Purge-Funktion wollen verantwortungsvoll eingesetzt werden, sonst droht Datenverlust trotz Aufbewahrungsrichtlinien (zum Glück respektiert Purview DLP-Purge bestehende Retention-Policies automatisch). Fazit: Nutzen Sie die nächsten Wochen, um die wichtigsten Compliance-Neuerungen zu evaluieren und in Ihre Prozesse zu integrieren. Ein strukturierter 30/60/90-Tage-Plan hilft, nichts zu übersehen. Bei Bedarf ziehen Sie erfahrene Expertise hinzu – die meisten Änderungen lassen sich mit etwas Praxis-Know-how reibungslos umsetzen. (Siehe auch Abschnitt „Unterstützung aus der Praxis“ am Ende.)

Einordnung: Was zählt als M365 Compliance?

Unter Microsoft 365 Compliance verstehen wir sämtliche Funktionen und Lösungen, mit denen Organisationen rechtliche, regulatorische und interne Vorgaben im M365-Umfeld umsetzen. Microsoft hat diese Tools unter dem Namen Microsoft Purview zusammengefasst. Dazu gehören im Wesentlichen:

• Data Security & Loss Prevention (DLP): Verhindert Datenabfluss, z. B. Schutz vor dem Versenden vertraulicher Inhalte per E-Mail, Teams oder am Endpunkt. Inkl. Endpoint DLP (Windows, Mac) und DLP für Cloud-Services (Exchange, SharePoint, Teams etc.).
• Information Protection & Labels: Klassifizierung und Schutz von Daten durch Sensitivity Labels (manuell oder automatisiert), inkl. Verschlüsselung, Content-Markings und Scoping von Berechtigungen.
• Data Lifecycle Management & Records: Aufbewahrungsrichtlinien und -labels, Archivierung, Records Management (um z. B. geschäftsrelevante Daten als „Datensatz“ zu deklarieren und geregelte Aufbewahrung/Disposition durchzuführen).
• Auditing & eDiscovery: Überwachung von Benutzer- und Admin-Aktivitäten (Audit Logs, Standard 90 Tage, E5 bis 1 Jahr) und Werkzeuge zur eDiscovery (juristische Suche, Beweissicherung) in Standard- und Premium-Variante (Letztere mit erweiterten Funktionen wie Hold, Analytics, Reviewer-Workflows).
• Insider Risk Management & Communication Compliance: Erkennung von riskantem Benutzerverhalten (z. B. Datendiebstahl durch Mitarbeiter) und Überwachung von Kommunikation auf Verstöße (z. B. Belästigung, Compliance-Schlagwörter) – inklusive Privacy-Schutz (Pseudonymisierung) bis zur Eskalation.
• Privacy Management (Priva): Verwaltung von Datenschutzrisiken, Datenzugriffsanfragen (DSR/SRR) und internen Privacy-Richtlinien.
• Compliance im KI-Kontext: Neuerdings Integration von Purview mit Microsoft 365 Copilot zur Durchsetzung von Datenschutz und Richtlinien auch bei KI-gestützten Assistenten (z. B. DLP-Regeln für KI-Abfragen).

Für die meisten erweiterten Funktionen ist eine höherwertige Lizenz (M365 E5 Compliance bzw. Purview Suite) erforderlich. Im folgenden Hauptteil betrachten wir die wichtigsten Neuerungen aus Q1 2026 in diesen Bereichen. Jedes Feature wird praxisnah erläutert – mit dem Fokus darauf, warum es eingeführt wurde, wie es in der Praxis hilft, und was Admins und Anwender konkret beachten müssen.

(Tipp: Wenn Ihnen die Fülle an Neuerungen überwältigend erscheint – keine Sorge. Priorisieren Sie anhand Ihrer Compliance-Schwerpunkte. Und denken Sie daran, dass externe Unterstützung verfügbar ist, um z. B. Ihre DLP-Policies oder IRM-Einstellungen optimal zu konfigurieren.)

Purview DLP: Datenlöschung direkt in Data Security Investigations

Was ist neu? Eine neue Purge-Maßnahme in Microsoft Purview Data Security Investigations (DSI) ermöglicht es Administratoren, sensible oder überfreigebene Inhalte direkt während einer Untersuchung zu löschen. Früher konnte man in solch einer Situation lediglich den Vorfall analysieren und dann außerhalb von DLP/DSI manuell löschen. Jetzt bietet DSI einen „Purge“-/Lösch-Button, mit dem Suchergebnisse – z. B. Dateien in SharePoint, E-Mails in Exchange – unmittelbar entfernt werden können. Wichtig: Das Löschen erfolgt im Einklang mit bestehenden DLP- und Retention-Richtlinien. Die Funktion ging Anfang Januar 2026 in Preview und ist seit März 2026 global allgemein verfügbar (GA).

Warum kommt das jetzt? Unternehmen stehen zunehmend vor der Herausforderung, Datenlecks schnell einzudämmen. Wenn etwa vertrauliche Dokumente versehentlich im falschen Team geteilt wurden oder sensible Mails an Externe gingen, zählt jede Minute, um den Schaden zu begrenzen. Bisher war der Prozess oft umständlich: Incidents im DLP-Portal identifizieren, dann über eDiscovery oder Admin-Center die Inhalte löschen lassen. Mit der neuen Purge-Funktion reagiert Microsoft auf den Bedarf nach einer schnellen, integrierten Bereinigungs-Option direkt im Compliance-Portal. Auch regulatorisch (Stichwort DSGVO/Privacy Incidents) verlangen Behörden, dass Unternehmen bei Datenschutzvorfällen “unverzüglich” handeln – das wird mit einem eingebauten Lösch-Tool deutlich erleichtert.

Praxisbeispiel: Ein Mitarbeiter lädt versehentlich eine Liste mit HR-Personalnummern und Gehältern in einen frei zugänglichen SharePoint-Ordner hoch. Die Compliance-Abteilung erhält über DLP einen Incident. Bislang hätte man die Datei manuell suchen und löschen müssen. Jetzt kann der Compliance-Analyst im Purview-Portal die Data Security Investigation öffnen, den Vorfall samt Datei finden und per Klick sofort löschen. Ergebnis: Die Datei wird entfernt (und bspw. in SharePoint in den Papierkorb verschoben), wodurch unautorisierter Zugriff unterbunden wird – und das ohne langes Hin- und Herwechseln zwischen Tools.

Auswirkung für Anwender: Im Idealfall merken Endanwender von dieser Löschaktion wenig bis nichts. Die Maßnahme zielt darauf ab, Oversharing schnell zu korrigieren. Benutzer könnten allenfalls bemerken, dass eine von ihnen geteilte Datei plötzlich nicht mehr verfügbar ist oder eine Mail vom Admin zurückgerufen/gelöscht wurde. In vielen Fällen wird die IT oder Compliance-Abteilung den betroffenen Nutzer aber separat informieren (z. B. „Wir haben Dokument X entfernt, da es vertrauliche Daten enthielt.“). Insgesamt erhöht die Funktion die Datensicherheit ohne direktes Zutun der Anwender, kann aber das Vertrauen stärken: Nutzer wissen, dass Fehler schnell „rückgängig“ gemacht werden können, bevor größerer Schaden entsteht.

Auswirkung für Admins: Für Administratoren – konkret für Security/Compliance-Analysten – bedeutet dies einen effizienteren Incident-Response-Workflow. Sie können direkt im DLP/DSI-Prozess tätig werden, statt ein separates eDiscovery-Löschverfahren (Content Search mit Purge via PowerShell) anzustoßen. Wichtig ist, dass Admins intern abgestimmte Prozesse haben: Wer darf die Purge-Funktion nutzen? In Purview wird dies über Rollen (z. B. Compliance-Administrator oder spezielle DLP-Rollen) gesteuert. Da die Funktion per Default aktiviert ist, sollten Admins ihre Security-Operations-Runbooks anpassen: Beim nächsten Datenleck-Vorfall kann man direkt in DSI „aufräumen“. Admins müssen auch die Protokollierung im Auge behalten – alle Löschaktionen werden geloggt (Audit-Events), um nachvollziehbar zu bleiben. Zudem gilt es, Schnittstellen zu anderen Teams (Legal, Datenschutzbeauftragter) festzulegen: Eine solche Löschung kann datenschutzrechtlich relevant sein (Nachweis, dass z. B. personenbezogene Daten entfernt wurden).

Was müssen wir tun? (Checkliste Minimum/Besser/Sehr gut)
– Minimum: Sicherstellen, dass zuständige Compliance-Admins Zugriff auf Purview Data Security Investigations haben und über die neue Purge-Option informiert sind. Keine speziellen Einstellungen nötig, aber Awareness schaffen.
– Besser: Interne Prozesse anpassen: Definieren, bei welchen Incidents die Purge-Funktion genutzt werden soll. z. B. schwere Datenschutzverstöße sofort löschen, kleinere Vorfälle erst rückfragen. Schulung der Analysten, um Fehlbedienungen (z. B. versehentliches Löschen falscher Inhalte) zu vermeiden.
– Sehr gut: Simulationen durchführen – z. B. einen Test-Incident erzeugen und den Löschablauf durchspielen. Dadurch prüfen, ob alle Berechtigungen stimmen und die Kommunikation an Beteiligte (z. B. betroffener Nutzer, Datenschutz) klappt. Außerdem in Policies festhalten, wer final freigibt, dass etwas per Purge gelöscht wird (Vier-Augen-Prinzip erwägen).

Risiken & Nebenwirkungen: Obwohl Purview das Löschen „im Einklang mit Aufbewahrungspflichten“ vornimmt (Inhalt unter Litigation Hold würde z. B. nicht unwiederbringlich gelöscht), besteht das Risiko, dass etwas vorschnell entfernt wird. Eine gelöschte Datei ist zwar in SharePoint/OneDrive noch im Recycling Bin, aber in Exchange wäre eine gepurgte Mail z. B. sofort Hard-Deleted. Tipp: Setzen Sie Purge deshalb mit Bedacht ein – z. B. erst veranlassen, wenn die Situation bewertet ist. Ein weiteres Risiko ist die „Komfortzone“: Da es so einfach geworden ist, könnten Admins versucht sein, vermehrt Inhalte zu löschen, wo vielleicht Schulung der Mitarbeiter der bessere Weg wäre. Und schließlich: Stellen Sie sicher, dass Audit-Logs für Purge-Aktionen aktiviert sind (in E5 ist Advanced Audit empfehlenswert). Sollte jemals geprüft werden, wer welche Daten gelöscht hat, brauchen Sie diese Nachvollziehbarkeit. Insgesamt aber bietet die Neuerung mehr Chancen als Risiken – schnellere Reaktion senkt die Verweildauer von Datenpannen deutlich.

Quellen: Microsoft 365 Message Center MC1199763, Purview DSI DLP-Purge Doku

Purview DLP: “Wait on Send” – E-Mail zurückhalten bei DLP-Prüfung

Was ist neu? Outlook (das neue Outlook für Windows) unterstützt nun das Feature “Wait on Send” für DLP, auch bekannt als Oversharing-Schleuse. Wird eine E-Mail verfasst, die unter eine DLP-Richtlinie fällt (z. B. enthält vertrauliche Informationen oder ein sensibles Label), kann Outlook den Versand kurz verzögern, bis die DLP-Prüfung abgeschlossen ist. Praktisch bedeutet das: Anstatt die Mail sofort rauszusenden, bleibt sie für einige Sekunden im „Wartestatus“. Je nach Ergebnis der DLP-Prüfung bekommt der Nutzer ggf. eine Policy Tip oder Block-Warnung und – falls erlaubt – die Option „Send anyway“ (Dennoch senden). Admins können die maximale Wartezeit konfigurieren (Standard: bis zu ~9999 Sekunden ≈ 2.7 Stunden) oder das Feature abschalten. Standardmäßig ist “Wait on Send” deaktiviert und muss pro Mailbox/Benutzer aktiviert werden (Exchange Online Mailbox-Parameter DLPWaitOnSendEnabled = true setzen). Die Funktion ging im Januar 2026 in GA für weltweite Tenants.

Warum kommt das jetzt? Jeder kennt das ungute Gefühl, eine Mail abgeschickt zu haben und danach festzustellen, dass vertrauliche Daten womöglich an falsche Empfänger gingen. Bisher wirkte DLP zwar im Backend, konnte aber einen schnellen Mitarbeiter am Outlook-Client nur begrenzt bremsen – vor allem im neuen, schnellen Outlook-Client. „Wait on Send“ adressiert dieses Problem und folgt einem Trend zu proaktiver Data Loss Prevention: Das Feature entstand, weil Kunden Oversharing-Schäden vermeiden wollen, bevor die Mail das Haus verlässt, statt im Nachhinein über “Recall” oder Löschaktionen zu stolpern. Gerade mit immer strengeren Datenschutzauflagen (Stichwort: kein Versand von Gesundheitsdaten unverschlüsselt etc.) ist eine eingebaute Nachdenksekunde sinnvoll. Microsoft reagiert damit auch auf Feedback, dass Policy Tips in Outlook manchmal zu spät oder gar nicht erschienen – jetzt wird der Versand so lange aufgehalten, bis die Richtlinie greift und dem User angezeigt wird.

Praxisbeispiel: Ein Vertriebsmitarbeiter möchte eilig eine Angebotstabelle an einen externen Partner schicken. Er vergisst, dass das Excel-Sheet interne Margen enthält, die laut Unternehmensrichtlinie nicht rausgehen dürfen. Beim Klicken auf „Senden“ in Outlook passiert scheinbar nichts – außer einem kleinen Hinweis oben, dass die Mail noch geprüft wird. Nach einigen Sekunden erscheint ein DLP-Hinweis: „Diese E-Mail enthält vertrauliche Inhalte (Wort ‚Intern‘) und wurde daher zurückgehalten.“ Der Mitarbeiter kann nun entweder den externen Empfänger entfernen oder, falls die Policy es zulässt, auf „Dennoch senden“ klicken (was geloggt wird). Ohne Wait on Send wäre die Mail vermutlich sofort gesendet worden und ggf. vom Exchange-Transport regelbasiert blockiert – allerdings wäre sie dann schon aus dem Postausgang ‘raus’ gewesen. Mit Wait on Send wird der „Moment of Risk“ direkt im Client abgefedert.

Auswirkung für Anwender: Für Endanwender ist dies zunächst eine kleine Verhaltensänderung: Eine Mail könnte 5–10 Sekunden im Postausgang hängen bleiben, bevor sie tatsächlich versendet wird. Das neue Outlook zeigt das dezent an. Anstatt dass Mails „sofort weg“ sind, bemerkt der Nutzer evtl., dass Outlook noch sendet – das könnte zu Anfang irritieren („Warum dauert das Senden länger als gewohnt?“). Aber durch entsprechende Kommunikation und Policy Tip-Text können Nutzer verstehen, dass dies dem Schutz vertraulicher Daten dient. Positiv: Es passiert alles innerhalb von Outlook, der Nutzer bekommt im besten Fall sofort Feedback („Mail wird geprüft… ok, jetzt gesendet“ oder eben eine Richtlinienmeldung zum Handeln). Für viele Anwender kann das sogar lehrreich sein: Sie sehen, dass das System aufpasst, und überlegen in Zukunft zweimal, bevor sie sensitives Material verschicken. Wichtig ist, dass Performance und Produktivität nicht zu sehr leiden – Admins sollten die Timeout-Werte so setzen, dass übliche Mails (ohne DLP-Befund) nur sehr kurz verzögert werden. Microsoft erlaubt ja z. B. 25 Sekunden Wartezeit: In den meisten Fällen merkt der Anwender davon nichts, außer einer kurzen Verzögerung, die er als Netzwerklatenz abtun könnte.

Auswirkung für Admins: Administratoren (insbesondere Exchange- und Compliance-Admins) erhalten mit „Wait on Send“ ein neues Werkzeug im DLP-Baukasten. Allerdings ist es kein globaler Schalter, sondern muss via PowerShell pro Postfach oder Postfachplan konfiguriert werden. Das bedeutet etwas Aufwand: Admins müssen bestimmen, für wen Wait on Send aktiviert werden sollte – vermutlich für alle, die potenziell sensible Daten versenden (in vielen E5-Umgebungen: einfach für alle User, da DLP ja eh greifen soll). Möglicherweise testet man erst mit einer Pilot-Gruppe. Auch die Timeout-Einstellung (DLPWaitOnSendTimeout) will überlegt sein: Standard ~9999 Sekunden bedeutet faktisch unendliches Warten (kein Auto-Override) – das ist nicht praxistauglich. Realistischer sind Werte 30 Sekunden oder 60 Sekunden, nach deren Ablauf der Nutzer ein „Dennoch senden“ klicken kann. Admins sollten außerdem kommunikative Begleitmaßnahmen einplanen: Ankündigung an Benutzer („Neues Sicherheitsfeature: Mails warten kurz bei sensiblen Inhalten“). Technisch sollte geprüft werden, ob alle Clients die Anforderungen erfüllen: Es funktioniert nur im neuen Outlook für Windows (nicht im alten „Legacy“ Outlook), und auch nur bei aktivem Cloud-DLP. Also: Office-Versionen, Channels usw. sicherstellen, ggf. Updates forcieren. Monitoring: Admins können via Audit Logs sehen, wie oft Wait on Send triggered – ggf. Kennzahl zur Bewertung der Policy-Effektivität.

Was müssen wir tun?
– Minimum: Feature evaluieren und bei Bedarf aktivieren. Per PowerShell Set-OrganizationConfig bzw. pro Mailbox Set-Mailbox den Parameter DLPWaitOnSendEnabled setzen (Standard false). Mindestens für hochriskante Nutzer/Gruppen einschalten (z. B. Abteilungsleiter, Finance) und Timeout-Wert definieren (z. B. 30 Sek.).
– Besser: Rollout geplant durchführen: Pilot mit IT-Team, Feedback einholen (ob Hinweise verständlich, ob Wartezeit passt). Dann gestaffelt ausrollen. Policy Tips überprüfen bzw. anpassen, damit Nutzer klare Anweisungen bekommen während des Wait-on-Send.
– Sehr gut: Awareness schärfen: Trainings oder Info-Mails an Mitarbeiter, warum Mails evtl. verzögert senden – verbunden mit praktischen Tipps (z. B. „Wenn Sie sehen, dass Outlook noch sendet – nicht panisch erneut auf Senden klicken.“). Zusätzlich das Feature in die Compliance-Score/KPI aufnehmen: Messen, ob dadurch weniger Verstöße auftreten (z. B. Zahl der „Send Anyway“-Overrides tracken und auswerten). Wenn Kapazitäten: “Phasenweise aktivieren” – zuerst Hinweis-Mode (Timeout kurz, damit Hinweis nur blinkt?), dann strengere Settings, um Nutzer Schritt für Schritt zu gewöhnen.

Risiken & Nebenwirkungen: Ein offensichtliches Risiko ist Frustration oder Verwirrung bei den Usern, wenn sie nicht wissen, warum ihre E-Mail gerade zögert. Daher ist Change Management hier wichtig – sonst klicken manche Nutzer möglicherweise wild rum oder schicken Mails doppelt, weil sie denken, Outlook hing. Ein anderes Risiko ist Konfigurationsfehler: Setzt man den Timeout z. B. versehentlich auf 0 Sekunden, erscheint sofort „Send anyway“ – das hebelt den Sinn aus. Oder auf 9999, dann gehen Mails mit Verstößen gar nicht mehr raus, bis jemand manuell eingreift – das wäre quasi Hard-Block. Deshalb die Werte sinnvoll wählen. Außerdem: Das Feature gilt (derzeit) nur im neuen Outlook-Client auf Windows. Nutzer von Outlook Mobile, Mac (noch kein Support außer eventuell später) oder gar anderen Mailclients merken nichts davon – hier greift nach wie vor der klassische DLP-Transport. Also kein falsches Sicherheitsgefühl: Wait on Send ist super, aber kein Allheilmittel über alle Plattformen. Und zu guter Letzt muss man bedenken: DLP selbst muss richtig konfiguriert sein – Wait on Send verzögert nur. Wenn DLP-Regeln zu lax sind, verhindert auch dieses Feature keine Datenlecks. Insgesamt aber sind die Nebenwirkungen gering und die Datenverluste dürften spürbar sinken, wenn man es richtig einführt.

Quellen: Microsoft 365 Roadmap ID 498920, Message Center MC1198702

Purview DLP: Policy Tips jetzt auch für Outlook auf Mac

Was ist neu? DLP Policy Tips – die bekannten Hinweise in Outlook, wenn eine E-Mail gegen Richtlinien verstößt – funktionieren nun auch in Outlook für Mac. Bisher war dies auf Outlook für Windows und Web beschränkt. Mit dem Update erhalten Mac-Nutzer Echtzeit-Benachrichtigungen direkt im Mail-Editor, wenn sie z. B. vertrauliche Daten im Anhang oder Text haben, die eine DLP-Regel triggern. Die Funktionsweise entspricht der auf Windows: Ein gelber Warnbalken („Ihre Nachricht enthält vertrauliche Informationen…“) erscheint, gegebenenfalls mit Optionen wie Empfänger entfernen (z. B. externe) oder Override (Begründung eingeben und dennoch senden), je nach Richtlinienkonfiguration. Dieses Feature wurde Ende 2025 fertiggestellt und war im Januar 2026 global verfügbar (in Govt-Clouds geringfügig später). Es ist standardmäßig aktiv, sobald der User die unterstützte Outlook-Version nutzt.

Warum kommt das jetzt? Mit immer mehr Unternehmen, die Cross-Platform arbeiten, war es ein Pain Point, dass Mac-User beim Mailversand weniger Schutzfeedback erhielten. Microsoft hat in den letzten Jahren viel in Parität investiert – Mac-Outlook war hier überfällig. Zugleich steigt die Nutzung von macOS im Unternehmensumfeld (vor allem Führungskräfte, Entwickler). Da DLP ein zentrales Compliance-Instrument ist, musste diese Lücke geschlossen werden, um konsistente Sicherheit zu gewährleisten. Vermutlich gab es auch Kundenbeschwerden („Warum hat Mitarbeiter A auf Windows den Hinweis gesehen und Mitarbeiter B auf Mac nicht?“), insbesondere in sensiblen Branchen. Kurz: Es kommt jetzt, weil Zeit war, Mac gleichzuziehen und Lücken im Schutzschild zu beseitigen. Außerdem passt es in Microsofts Strategie “Compliance by default” – egal auf welcher Plattform, die User sollen Richtlinien-feedback bekommen.

Praxisbeispiel: Ein Anwalt in der Rechtsabteilung arbeitet auf einem MacBook und möchte eine Datei mit internen Fallinformationen an einen externen Gutachter mailen. Ohne dieses Feature würde Outlook für Mac die Mail einfach senden – der DLP-Service im Hintergrund hätte zwar die Mail blocken können, aber der Anwalt würde erst durch eine Quarantäne-Benachrichtigung im Nachhinein davon erfahren. Jetzt aber sieht er beim Klick auf Senden sofort den Hinweis: „Diese Nachricht enthält vertrauliche Inhalte (Kundendaten) und darf nicht extern versendet werden.“ Der Balken empfiehlt ihm, den externen Empfänger zu entfernen. Der Anwalt merkt: Oh, besser den Anhang nur intern teilen oder freizugeben via sicheres Portal. Er entfernt den externen Empfänger und schickt die Mail nur an interne Kollegen – Problem entschärft. Dieses Beispiel zeigt, wie DLP-Hinweise auf Mac das gleiche Schutzniveau bieten wie auf Windows, was gerade in heterogenen Umgebungen wichtig ist.

Auswirkung für Anwender: Für Mac-Anwender ist dies ein großer Gewinn an Transparenz. Sie bekommen nun die gleiche “Guardrail”-Unterstützung wie ihre Windows-Kollegen. Anfangs mag es überraschend sein („Seit wann gibt mir mein Mac Outlook solche Warnungen?“), aber es erhöht die Sicherheit im Arbeitsalltag. Nutzer können durch die Tipps Fehler vor dem Absenden korrigieren (z. B. entfernen eines externen Empfängers, Verschlüsseln eines Dokuments etc.). Wichtig ist, dass Unternehmen die Override-Option wohldefiniert haben: Wenn Nutzer auf Mac nun auch „Senden trotz Verstoß“ klicken können, sollte klar kommuniziert sein, in welchen Fällen das zulässig ist (z. B. bei Geschäftsführung eventuell erlaubt mit Begründung, bei anderen nicht). Unterm Strich fühlen sich Anwender hoffentlich besser unterstützt und nicht gegängelt – die Erfahrung zeigt auf Windows schon, dass gut formulierte Policy Tip-Texte („Achtung, diese Datei enthält Kundendaten. Löschen Sie vertrauliche Infos oder holen Sie Freigabe ein.“) sehr hilfreich sein können. Erfreulich: Die Mac-App hat in den letzten Jahren Performance- und UI-mäßig aufgeholt, sodass das Einblenden der Hinweisleisten flüssig vonstattengeht.

Auswirkung für Admins: Für Admins bedeutet dies weniger Inkonsistenz in DLP-Vorfällen. Bisher tauchten Mails von Mac-Nutzern u. U. häufiger als Policy-Verstöße in Logs auf, weil die Nutzer erst nachträglich vom System (Exchange) aufgehalten wurden. Nun können Admins verstärkt auf Benutzer-Selbstkorrektur setzen – was hoffentlich die Zahl tatsächlicher Policy-Verstöße reduziert. Technisch müssen Admins sicherstellen, dass die Mac-Clients auf dem neuesten Stand sind (Outlook für Mac unterstützt diese Funktion ab Version 16.103+). Evtl. sollte man einen Nachrichtencenter-Hinweis an Mac-User senden: „Bitte aktualisieren Sie Ihr Outlook, um neue Sicherheitsfeatures zu erhalten.“ Lizenzseitig braucht es keine Änderungen: DLP ist ohnehin zentral konfiguriert. Admins sollten aber prüfen, ob bestehende DLP-Regeln Mac einschließen (Purview DLP Policies haben meist Locations wie Exchange – Mac-Client fällt darunter, da er ja über Exchange sendet). Kurzum: Kein großer Mehraufwand, aber Admins können jetzt Policy-Templates vereinheitlichen – man muss keine Sonderlocken für Mac definieren. Zudem sollte man die Kommunikation/Schulung an Mac-User angleichen, z. B. in Benutzerhandbüchern ergänzen: „So sehen DLP-Warnungen in Outlook (Windows und macOS) aus.“

Was müssen wir tun?
– Minimum: Sicherstellen, dass Outlook für Mac Version aktuell (mind. v16.103) ausgerollt ist. Ggf. über Intune/Update-Kanäle pushen. Nichts extra konfigurieren – Feature ist default an.
– Besser: Kommunikation an Mac-User: Informieren, dass nun auch auf dem Mac DLP-Hinweise kommen. Beispiel-Screenshot mitschicken, damit niemand überrascht wird. Zudem interne DLP-Dokumentation updaten („Policy Tips erscheinen auf Win, Web und Mac“).
– Sehr gut: Feedback-Schleife einrichten: Gerade in den ersten Wochen Mac-Poweruser fragen, ob die Hinweise passen oder ob es False Positives gibt. So kann man DLP-Regeln ggf. feinjustieren. Außerdem: Einheitliche Override-Richtlinien prüfen – bisher ging man evtl. davon aus, Mac-User können gar nicht override klicken. Nun schon, daher sicherstellen, dass Audit-Logging für Overrides aktiv und Prozedere klar (z. B. wöchentlicher Report an Compliance-Team). Mac-Admins einbeziehen, damit Support Bescheid weiß für den Fall von Fragen.

Risiken & Nebenwirkungen: Eigentlich überwiegen die Vorteile eindeutig. Nebenwirkung könnte sein, dass manche Mac-User verunsichert reagieren („Huch, warum werde ich jetzt überwacht?“). Hier muss man kommunikativ abholen: Es ist nichts Neues, sondern angleichen an existierende Policies. Ein technisch denkbarer Nebeneffekt: Wenn der Mac-Client doch mal offline ist oder keine Richtlinien abrufen kann, könnte es zu unterschiedlichem Verhalten kommen – aber in der Regel cached der Client die relevanten DLP-InfoTypes. Ein Risiko wäre, wenn Admins bisher Mac vom DLP ausgenommen hatten aus Angst vor FPs – das ist nun obsolet. Testen Sie neue oder komplexe DLP-Regeln daher auch mit Outlook Mac, um sicher zu sein, dass alles wie erwartet läuft. Es gab vereinzelt Berichte, dass Mac-Outlook bei bestimmten Konstellationen etwas länger braucht, um den Policy Tip zu zeigen – das könnte hektische User dazu verleiten, die Mail zu früh nochmal zu senden. Also: Schultern Sie Mac-User, einen Moment zu warten, wenn sensible Inhalte drin sind. Performance insgesamt scheint aber gut. Summa summarum geringe Risiken – endlich gilt „DLP für alle“ auch auf dem Desktop.

Quellen: Microsoft 365 Roadmap ID 484851, TechCommunity-Blog

Purview DLP: Erweiterte Dateitypen-Erkennung auf Mac Endpoints

Was ist neu? Microsoft hat den Umfang der unterstützten Dateiformate für Endpoint-DLP auf macOS drastisch erhöht. Bislang konnten DLP-Richtlinien auf Mac-Clients nur ca. 40 Dateitypen zuverlässig untersuchen und klassifizieren. Mit dem Q1 2026 Update sind es über 100 Formate, was Mac-DLP nahezu auf Augenhöhe mit Windows bringt. Außerdem wurden die Inhaltextraktion und -inspektion auf Mac verbessert (Stichwort: Texterkennung in komplexen Formaten). Administratoren können somit nun deutlich breiter gefächerte Dateiarten in die DLP-Kontrolle einbeziehen – seien es CAD-Zeichnungen, spezielle Archivformate oder proprietäre Doku-Formate. Die Erweiterung befand sich Anfang Januar noch „in Entwicklung“, rollte dann aber im Laufe des Januars 2026 weltweit aus. Für Admins sichtbar ist sie vor allem daran, dass DLP-Policies auf Mac plötzlich Auslöser in Dateien erkennen, die vorher „unbeachtet“ blieben.

Warum kommt das jetzt? Mac-Endpoints werden häufiger in kreativen/entwicklungsnahen Bereichen genutzt, wo Dateiformate jenseits von Office-DOCs an der Tagesordnung sind (z. B. Adobe Photoshop .psd, Sketch-Dateien, Quellcode-Dateien). Bisher hatte Mac-DLP hier klare Lücken – eine Lücke, die Insider-Risk-Szenarien ausnutzen könnten (ein Entwickler könnte z. B. Code in einer .py-Datei exfiltrieren, ohne dass DLP es merkt, wenn .py nicht unterstützt wurde). Microsoft reagiert auf Kundenforderungen nach Gleichstand: Windows DLP erkennt 100+ Dateitypen, Mac sollte das auch. Zudem wächst generell die Mac-Quote in Unternehmen; Compliance kann nicht sagen „Auf Mac geht halt weniger Schutz“. Schließlich hat Microsoft 2025 auch OCR für Mac (Texterkennung in Bildern) eingeführt – es passt ins Bild, Mac-DLP allumfassender zu machen. Und wahrscheinlich hat der Konkurrent im DLP-Markt (z. B. Symantec, Forcepoint) hier nicht geschlafen – MS will mit Purview DLP in E5 den vollen Wert bieten.

Praxisbeispiel: In einer Design-Agentur nutzt das Team Macs und erstellt allerlei Formate: .pdf, .ai (Adobe Illustrator), .indd (InDesign) etc. Das Unternehmen hat strikte DLP-Regeln, dass Entwürfe nicht auf USB-Sticks kopiert oder per Teams nach außen gesharet werden dürfen. Früher: Einige Formate wurden vom Purview-DLP-Agent gar nicht geprüft – steckte ein Entwurf in einem nicht erkannten Format, konnte er womöglich kopiert werden, ohne Alarm. Jetzt: Mit den neuen 100+ Formaten ist auch .INDD und .AI abgedeckt. Ein Grafiker versucht, eine .INDD-Datei (enthält Kundendaten im Layout) auf einen privaten USB-Stick zu ziehen. Der Mac-DLP-Agent springt an, erkennt den sensiblen Dateityp und blockiert den Kopiervorgang. Gleichzeitig erscheint eine Popup-Benachrichtigung: „Unternehmensrichtlinie: Das Kopieren von vertraulichen Dateien auf Wechseldatenträger ist untersagt“. Der Grafiker staunt (bisher ging das doch manchmal), aber der Schutz hat gegriffen. Dieses Beispiel verdeutlicht: Mehr Dateitypen = mehr Schutz, v. a. in Branchen mit Spezialformaten.

Auswirkung für Anwender: Idealerweise merken Anwender gar nichts – bis sie etwas Unerlaubtes tun. Sprich: Ein normaler Mac-User wird im Alltag keinen Unterschied feststellen, bis auf den Fall, dass er eine Aktion mit bislang „unüberwachten“ Dateiformaten versucht, die nun blockiert wird oder einen Warn-Popup zeigt. Das kann zu Aha-Effekten führen („Früher konnte ich diese CAD-Datei noch auf den USB ziehen, jetzt nicht mehr.“). Kurzfristig könnte Unmut entstehen, falls Benutzer an bestimmte Workarounds gewohnt waren („Nehm halt .7z Archiv, das checkt DLP nicht“ – das zieht nun nicht mehr). Insgesamt erhöht es aber die Sicherheit ohne aktives Zutun der Nutzer. Möglicherweise sehen sie nun etwas häufiger den DLP-Banner oder Block-Seiten, aber das Ziel – Schutz unserer Daten – rechtfertigt das. Wichtig für die Nutzerkommunikation: Sollte proaktiv klargestellt werden, dass kein „Misstrauen“ gegen Mac-User bestand, sondern dass nun die gleiche Policy für alle gilt. Wenn ein Nutzer technisch versiert war und wusste, Format X war bisher safe, könnte er sich nun „ertappt“ fühlen – hier hilft Aufklärung, dass es um generelle Risiko-Minimierung geht.

Auswirkung für Admins: Admins dürfen sich freuen: Weniger Schlupflöcher. In der Purview-DLP-Konsole müssen sie nichts Grundlegendes ändern; die Policies gelten automatisch für die neuen Typen, sofern Inhaltsklassifizierung greift. Allerdings sollte man die DLP-Berichte im Auge behalten: Durch die neu erkannten Dateitypen könnte es einen Anstieg an DLP-Alerts geben, gerade in der Anfangsphase. Dateien, die gestern ignoriert wurden, lösen heute vielleicht ein Event aus. Admins sollten daher ggf. Richtlinien anpassen: Sind gewisse Formate fälschlich geblockt? Z. B. kann es sinnvoll sein, bestimmte ungefährliche Formate auszunehmen, falls es Business-Impact gibt. Auch die Device Onboarding sollte gecheckt werden: Der Mac-DLP-Agent muss aktuell sein (via Microsoft Defender for Endpoint integriert). Administrativ lohnt ein Blick auf SITs (Sensitive Information Types) und Definitionsdateien: manche Dateitypen erfordern ggf. angepasste Patterns. Insgesamt aber eher wenig Mehraufwand – es ist ein Backend-Update. Für den Rollout: Info an Mac-IT-Support, dass fortan DLP „mehr sieht“, damit Helpdesk vorbereitet ist, falls User nachfragen („Wieso geht das nicht mehr?“).

Was müssen wir tun?
– Minimum: Prüfen, ob alle Mac-Geräte den MDE/DLP-Client aktuell haben – neue Dateitypen wurden via Cloud-Konfig verteilt, aber aktuelle Sensorversion schadet nicht. Wenn E5-Lizenz und Geräte onboarded, kein weiterer Schritt – Gains sind automatisch da.
– Besser: Analyse Phase: Nach Deployment ein Auge auf DLP-Vorfälle werfen speziell nach Dateityp. Checken, ob plötzlich neue Incident-Spitzen auftreten (z. B. viele Blockierungen von .zip oder .rar, falls als neu erkanntes Format). Falls nötig, Policiys nachjustieren oder User informieren, warum das nun geblockt wird.
– Sehr gut: Nutzer proaktiv informieren, insbesondere Teams, die mit exotischen Formaten arbeiten (Design, Engineering). Ihnen erklären, dass nun DLP auch diese Formate umfasst und was die Alternativen sind, wenn legitime Transfers nötig sind (z. B. Freigabe via Unternehmens-OneDrive statt USB-Stick etc.). Außerdem könnte man eine interne Liste der jetzt neu abgedeckten Dateitypen verbreiten, damit IT und Anwender wissen, was Sache ist. Und natürlich: Policies auditieren – vlt. können nun strengere Regeln gesetzt werden (weil man sich vorher zurückgehalten hat aufgrund Mac-Lücken).

Risiken & Nebenwirkungen: Ein mögliches „Risiko“ ist, dass Admins anfangs von der Flut neuer Alerts überrascht werden. So nach dem Motto: „Oh, wir hatten ja so wenige Vorfälle auf Mac – jetzt plötzlich zig, war das immer schon so?“. Ja, war es, nur jetzt sieht man es. Man sollte das intern gut kommunizieren, damit niemand glaubt, Mac-User hätten plötzlich mehr Unsinn im Kopf – es wird nur transparenter. Eine Nebenwirkung könnte sein, dass Systemlast auf älteren Macs minimal steigt, da mehr Dateien inspiziert werden. Allerdings ist der DLP-Endpoint-Agent recht schlank und arbeitet event-basiert – keine größeren Performanceprobleme wurden bekannt. Risiko: Falls Unternehmen bisher Mac etwas „vernachlässigt“ hat in Policies, tauchen nun evtl. Unstimmigkeiten auf (z. B. Windows-Regel existiert, Mac-Regel war aus – jetzt greift Windows-Regel auch Mac). Daher config angleichen. Abschließend sei erwähnt: Mit mehr Formaterkennung steigt auch die Komplexität – sollten Fehlalarme auftreten, muss man sie analysieren. Insgesamt aber deutlich mehr Sicherheit, kaum Downsides. Wer es sehr streng sieht, könnte argumentieren: Mitarbeiter finden eventuell andere Wege, die (noch) nicht abgedeckt sind – aber bei 100+ Formaten wird es schwer, Purview auszutricksen.

Quellen: Microsoft 365 Roadmap ID 543714, Planet Weekly Update (Jan 8 2026)

Purview DLP: Adaptive Scope – dynamische Zielgruppenauswahl für SharePoint

Was ist neu? Adaptive Scopes für DLP-Policies in SharePoint Online ermöglichen es, dynamisch festzulegen, welche SharePoint-Sites eine DLP-Richtlinie abdecken soll. Statt manuell eine fixe Liste von z. B. 50 Site-URLs in der Policy zu pflegen, kann der Admin jetzt Regeln definieren – etwa „alle Sites, deren Titel das Wort Vertraulich enthält“ oder „Sites mit spezifischem Tag/Attribut XY“. Purview ermittelt dann automatisch die passenden Sites und hält die Zuordnung aktuell. Das hebt die bisherige starre Grenze von max. 100 Sites pro Policy auf. Die Funktion ging im Feb 2026 in Preview und soll ab März 2026 GA sein. Aktuell bezieht sie sich auf SharePoint als Location (andere Workloads könnten folgen). Konfigurieren lässt sich das im Purview-Portal unter Data Loss Prevention > Adaptive Scopes (dort erstellt man zunächst einen dynamischen Scope, den man dann in einer Policy nutzt).

Warum kommt das jetzt? Unternehmen strukturieren ihre Daten zunehmend dynamisch und nach Metadaten. Starre Zuordnungen (“Policy X gilt für Sites A, B, C…”) sind schwer skalierbar – insbesondere wenn Teams und Sites wie Pilze aus dem Boden schießen (Stichwort: Selbst-Services, Teams-Workspaces). Microsoft reagiert auf den Wunsch nach Automatisierung und Skalierung bei Compliance-Einstellungen: Adaptive Scopes gab es schon länger für Retention, jetzt endlich auch für DLP. Außerdem haben Kunden sicherlich das Limit von 100 Sites als hinderlich gemeldet, wenn sie große Tenants mit hunderten Sites haben, die unter eine Regel fallen sollten. Trends wie Datensatzklassifizierung per Site Metadata machten diese Entwicklung ebenfalls nötig – so kann man z. B. ein Site-Attribut “DataCategory=HR” setzen und dann eine DLP-Regel automatisch auf alle HR-Sites anwenden. Es spart Zeit, reduziert Fehler (vergessene Sites) und passt zum Zero-Trust-Ansatz: Automatisierte Policy-Zuweisung minimiert menschliches Versäumnis.

Praxisbeispiel: Nehmen wir eine Bank, die alle Projekt-Dokumentbibliotheken mit Kundendaten besonders schützen will (z. B. keine externen Freigaben zulassen via DLP). Früher müsste der Admin jede neue Projekt-Site, sobald bekannt, manuell der DLP-Policy hinzufügen – riskant, denn vergisst er eine, wäre diese ungeschützt. Mit Adaptive Scope richtet er einmalig folgendes ein: Er definiert einen Scope “Projekt-Kundendaten-Sites” mit Kriterium Site Name enthält “Kunde” oder Site-SensitivityLabel = Kundendaten (vorausgesetzt, solche Labels/Tags werden gesetzt). Die DLP-Policy verweist nun auf diesen Scope. Wenn jetzt ein neues Projekt “AlphaKunde” als Site erstellt wird und die Namens-/Label-Kriterien erfüllt, wird automatisch die DLP-Policy angewendet. Der Admin muss nichts tun; die Policy gilt ohne seine manuelle Eingriffe. So ist gewährleistet, dass keine neue Kundendaten-Site durchrutscht. Gleichzeitig kann man alte statische Auflistungen auflösen und Fehlerminimierung betreiben.

Auswirkung für Anwender: Im Idealfall merken Endanwender hiervon nichts bewusst. Was sie vielleicht spüren: Konsistente Richtlinien auch auf neuen Sites vom ersten Tag an. Sie müssen nicht mehr erleben, dass auf der frischen Team-Site manche Dinge erlaubt sind, die eigentlich gegen die Compliance verstoßen (nur weil der Admin sie noch nicht in die Policy aufgenommen hatte). Für Anwender in sensiblen Bereichen kann das initial überraschend sein – z. B. gründen Mitarbeiter eine neue “Vertraulich-Projekt” Site, laden Daten hoch und stellen fest, dass DLP-Regeln (wie Wasserzeichen oder Blockieren externer Shares) sofort aktiv sind. Das zeigt aber nur, dass das Unternehmen hier stringent agiert. Im Grunde erhöht es für Anwender das Vertrauen: Es gibt keine “Policy-Lücken” zwischen älteren und neueren Arbeitsbereichen. Einziger Punkt: Anwender, die Sites erstellen, sollten die Relevanz der Metadaten kennen – wenn ein Site-Admin weiß, “Wenn ich das interne Attribut ‘HighRisk’ setze, zieht eine strenge DLP nach”, kann er bewusster handeln. Schulungen könnten das erwähnen, damit Nutzer die Magie im Hintergrund verstehen und nicht versuchen, Policies zu umgehen durch kreative Schreibweisen (– wobei Purview z. B. auch Wildcards etc. unterstützt, um sowas abzufangen).

Auswirkung für Admins: Für Compliance-Admins bedeutet Adaptive Scopes erheblich weniger Verwaltungsaufwand und potentielle Fehlerreduktion. Sie können sich einmal vernünftige Kriterien überlegen, anstatt ständig Listen zu aktualisieren. Natürlich gibt es eine Lernkurve: Admins müssen sich mit den Filtermöglichkeiten vertraut machen (z. B. Filter nach URL, nach Site-Eigenschaften wie Templates oder Labels). Sie sollten auch eng mit dem SharePoint-Admin oder Information-Architecture-Team zusammenarbeiten, da gute Metadaten/Benennungs-Konventionen die Basis für diese Dynamik sind. Zudem wird der Admin den Scope regelmäßig überprüfen wollen: Es gibt in Purview die Option, sich die aufgelösten Mitglieder eines Adaptive Scope anzeigen zu lassen. Vor Deploy einer Policy testet man besser (“Welche Sites würden aktuell reinfallen?”). Auch muss man neue Scope-Arten monitoren: Derzeit eben nur SharePoint. Wenn das Konzept ausgebaut wird (z. B. adaptive Benutzergruppen etc.), kämen weitere hinzu. Insgesamt aber sehr positiv: In großen Umgebungen (z. B. 500+ Sites im Tenant) spart Adaptive Scope unheimlich Zeit. Admins haben zudem nun kein Problem mehr mit dem 100-Standorte-Limit – sie können riesige Mengen an Sites abdecken, ohne Workarounds (früher half man sich evtl. mit mehreren Policies und dadurch Komplexität). Wichtig: Dokumentation anpassen – die DLP-Policy-Beschreibungen sollten festhalten, wenn sie über dynamische Scopes wirken, damit bei Personalwechsel klar ist, dass hier „Automatik“ im Spiel ist.

Was müssen wir tun?
– Minimum: Feature bewusst machen – im Purview-Portal unter Locations > Adaptive Scope neuen Scope konfigurieren. Dazu ggf. Absprache mit SharePoint-Team, welche Kriterien sinnvoll sind (Name, Metadata etc.). Testen, dann DLP-Policy auf diesen Scope umstellen.
– Besser: Bestehende Policies analysieren: Wo verwalten wir bislang händisch Site-Listen? Diese bevorzugt auf Adaptive Scopes migrieren. Naming-/Tagging-Konzept bereitstellen, falls noch nicht vorhanden: z. B. jeder sensiblen Site einen Indikator geben, damit der Scope greift.
– Sehr gut: Governance-Plan für Adaptive Scopes erstellen: z. B. “Bei neuen M&A-Projekten vergibt IT immer Tag XY an die Site, dadurch greifen autom. alle relevanten Policies.” Schulung der IT-Helpdesk/Berater, damit sie beim Erstellen neuer Sites an diese Parameter denken. Zusätzlich Monitoring: Ein Script könnte z. B. wöchentlich melden, wie viele Sites in den Scope fallen – ob das dem Erwartungswert entspricht. Das erhöht Vertrauen in die Automatismen.

Risiken & Nebenwirkungen: Ein Risiko besteht, wenn die Filterkriterien ungenau sind – dann könnten versehentlich zu viele oder zu wenige Sites einbezogen werden. Beispiel: Filter “URL enthält ‘HR’” könnte auch “Project-HR-Migration” Site fassen, die vielleicht gar keine Personaldaten hat. Daher sollte man die Queries präzise gestalten oder mehrere kombinieren. Nebenwirkung: Ein adaptiver Scope kann komplex sein, was die Transparenz erschwert. Wer nicht tief im Thema ist, wundert sich evtl., warum eine bestimmte Site jetzt der Policy unterliegt (“Wo kommt das her?”). Deshalb dokumentieren! Außerdem: Timing – die Evaluierung der Scopes erfolgt regelmäßig, aber nicht instant. Es kann minimal zeitverzögert sein, bis eine brandneue Site erkannt wird (typisch ist Minuten bis wenige Stunden). In der Zwischenzeit gilt die Policy eventuell noch nicht. Das Restrisiko ist aber im Vergleich zum manuellen Nachtragen gering. Performance: Microsoft verspricht, dass dynamische Scoping keine spürbare Auswirkung auf Policy-Enforcement hat. Dennoch, Admins sollten große Änderungen beobachten. Ach ja, und: Adaptive Scopes sind aktuell Preview – also sollte man Produktion vorsichtig migrieren und wachsam sein, falls noch Bugs auftreten. Wenn es GA ist, dann natürlich voll supportet. Unterm Strich überwiegt klar der Nutzen: Weniger manuelle Lücken, weniger Limit-Probleme, mehr Automation = mehr Compliance.

Quellen: Microsoft 365 Roadmap ID 549288

Communication Compliance: Flexiblere Policy-Alerts

Was ist neu? Microsoft Purview Communication Compliance bietet jetzt erweiterte Einstellungsmöglichkeiten für Benachrichtigungen (Alerts) bei Policy-Verstößen. Konkret können Admins pro Richtlinie festlegen, wie häufig und an wen Alerts gehen. Bisher waren Alert-E-Mails recht starr (z. B. sofortige Mails ab bestimmtem Schwellenwert an vordefinierte Empfänger). Nun lässt sich z. B. einstellen: „Sende maximal eine Alert-Mail pro Tag/Woche“ oder „Sende Alerts dieser Policy nur an diese spezielle Reviewer-Gruppe“. Diese Optionen sind direkt im Policy-Erstellungsassistenten unter einem neuen „Alerts“-Konfigurationsschritt verfügbar. Zusätzlich wurden Hintergrundfunktionen verbessert (Pseudonymisierung bleibt Standard; Audit-Logs für Alert-Änderungen etc. sind vorhanden). Die Preview lief seit Mitte 2025, im Januar 2026 wurde das Feature allgemein verfügbar.

Warum kommt das jetzt? Große Organisationen haben oft viele Communication Compliance-Treffer – ohne abgestufte Alerts führte das zu „Alarmmüdigkeit“. Microsoft reagiert auf Kundenfeedback, die Alert-Flut besser kontrollieren zu können. Beispiel: In einer globalen Bank will man bei leichten Verstößen (z. B. einzelne Schimpfwörter im Chat) nicht jedes Mal eine E-Mail an den Compliance Officer schicken, sondern vielleicht als Wochenzusammenfassung. Umgekehrt, für gravierende Dinge (z. B. Insider Trading Hinweise) möchte man sofort, aber vielleicht direkt an ein Security-Team statt an generischen Empfänger. Diese Flexibilität war überfällig, um Compliance-Workflows effizienter zu gestalten. Außerdem harmonisiert es mit anderen Purview-Tools – z. B. Insider Risk erlaubt schon länger feinere Steuerung der Notifications. Der Bedarf kommt auch daher, dass mehr Firmen Communication Compliance ausrollen (Stichwort: Regulierte Kommunikation in Teams, Zoom etc.), und ohne flexible Alerts schnell im Mail-Tsunami untergehen würden. Kurz: Jetzt gibt Microsoft den Admins das Ruder in die Hand, damit Alerts adressatengerecht & batchweise versendet werden können.

Praxisbeispiel: Ein Unternehmen überwacht Mitarbeiterkommunikation auf Belästigungen und unangemessene Sprache (z. B. rassistische Ausdrücke) via Communication Compliance. Früher bekam der Compliance-Manager jedes Mal eine E-Mail, sobald 5 potenzielle Verstöße passiert waren – teilweise mehrere pro Tag, viele Fehlalarme. Mit den neuen Einstellungen richtet er die Policy so ein: „Schicke Alert-Mails wöchentlich jeden Montag 9 Uhr“ mit einer Zusammenfassung aller Fälle der Woche, und adressiere sie an HR + Compliance-Team statt nur an ihn alleine. Gleichzeitig konfiguriert er eine zweite Policy für kritischere Vorfälle (etwa Drohungen), bei der Alerts weiterhin sofort, aber nur ans Sicherheitsmanagement gehen. Ergebnis: Statt 50 E-Mails pro Woche erhält das Team jetzt eine strukturierte Mail, kann gesammelt analysieren und priorisieren. Die IT-Security erhält in derselben Woche vielleicht 1-2 kritische Alerts separat. Dieses Beispiel zeigt, wie man durch die neue Granularität Rauschen reduzieren und Verantwortlichkeiten schärfen kann. Das Team ist dankbar, nicht mehr von E-Mails überflutet zu werden, und kann die echten Probleme gezielter angehen.

Auswirkung für Anwender: Idealerweise hat dies keine direkte Auswirkung auf Endanwender – es sei denn, Ihr Unternehmen informiert Mitarbeiter über Communication Compliance-Vorfälle (das passiert in manchen Fällen, z. B. Coaching-Hinweise an den Mitarbeiter). Die Neuerung betrifft aber den Back-End-Teil der Alerts an die Compliance-Verantwortlichen. Indirekt könnten Anwender profitieren, wenn z. B. weniger Fehlalarm-Eskalationen passieren – z. B. bisher wurde vielleicht bei jedem kleinen Verstoß gleich ermittelt, jetzt evtl. erst, wenn es gehäuft auftritt, je nach Alerting. Wichtig aus Anwendersicht: die Privacy bleibt gewahrt (Benutzernamen pseudonymisiert in der Review-Phase, bis ein Fall zur Untersuchung geöffnet wird). Das Feature selbst könnte man den Anwendern höchstens transparent machen in Richtlinientexten (“Kommunikation wird überwacht, potentielle Verstöße werden wöchentlich ausgewertet”). Aber in Summe: Keine unmittelbare Änderung für den normalen Mitarbeiter – er chattet/emailed wie zuvor, und wenn er Mist baut, liegt es am internen Process, wann wer es bemerkt.

Auswirkung für Admins: Für Compliance-Admins und Reviewer-Teams ist dies eine Willkommene Erleichterung und Kontrollmöglichkeit. Sie können nun Alert-Strategien definieren: z. B. weniger dringliche Policies bündeln, dringliche separieren. Das dürfte die Effektivität steigern, weil man sich besser auf die wirklich wichtigen Fälle konzentrieren kann. In der Praxis heißt es für Admins: Bestehende Communication Compliance-Policies überprüfen und anpassen. Das kann bedeuten: Alerts von “Standard (sofort)” auf “Daily/Weekly Digest” umstellen für manche Policies, und Empfängerkreise ergänzen (z. B. HR einbeziehen für HR-relevante Policy). Es ist nun auch leichter, unterschiedliche Stakeholder zu bedienen – etwa IT bekommt Tech-Compliance Alerts, HR bekommt HR-bezogene. Admins sollten zudem ihre Protokolle checken: Mit dem Update hat MS auch Audit-Logs rund um Alerts verbessert, sodass jede Änderung in der Policy und jeder versandte Alert protokolliert ist. Möglicherweise will man in den ersten Wochen nach Umstellung verfolgen: “Kommen die Mails wie gewünscht? Fehlen uns Infos, weil wir Intervall erhöht haben?”. Feinjustierung ist eingeplant. Insgesamt wird der Operations-Aufwand sinken, da weniger Zeit mit dem Sichten irrelevanter Einzelbenachrichtigungen draufgeht. Außerdem: Administratoren müssen ihre internen SOPs (Standard Operating Procedures) für Incident-Response anpassen – z. B. statt täglich E-Mails abzuarbeiten, richtet man jetzt vielleicht einen Wochen-Review-Call ein, in dem man die gesammelten Alerts der Woche durchgeht. Tools wie Teams oder Planner könnten genutzt werden, um Alerts dort zentral zu tracken statt via E-Mail-Chaos.

Was müssen wir tun?
– Minimum: Im Purview-Portal jede Communication Compliance-Richtlinie öffnen und den neuen “Alerts”-Tab konfigurieren. Entscheiden, ob sofortige oder geplante Alerts sinnvoller sind. Bei geplanter Zustellung Tag/Uhrzeit wählen. Empfänger überprüfen: Standard ist evt. nur Ersteller – hier ggf. eine Verteileradresse eintragen.
– Besser: Policy-übergreifendes Alert-Konzept entwickeln: z. B. definieren, dass kritische Policies (Bedrohungen, Betrug) Alerts sofort an Security Operations geben, moderate Policies (Unangemessene Sprache) wöchentlich an HR+Compliance. Diese Logik im Team abstimmen und konsequent umsetzen.
– Sehr gut: Testläufe durchführen: Simulieren Sie einen Verstoß und prüfen, ob der Alert wie gewünscht ankommt (ggf. Dummy-Nutzer mit Pseudonymisierung). Stellen Sie sicher, dass Alert-Empfänger geschult sind: Sie sollten wissen, wie sie mit den Alert-Mails und dem enthaltenen Link ins Purview-Portal umgehen. Richten Sie eventuell eine zentrale Queue ein (z. B. via Microsoft 365 Gruppe/Postfach, wo alle Alerts zusammenlaufen), um nichts zu übersehen. Dokumentation aktualisieren (Wer erhält wann welche Meldungen?). Und last but not least: KPIs definieren, z. B. “Durchschnittliche Zeit bis Untersuchung eines Alerts” – erwarten Sie Verbesserungen durch die Bündelung und messen Sie das.

Risiken & Nebenwirkungen: Ein offensichtliches Risiko: Wichtige Vorfälle könnten verzögert bemerkt werden, wenn man zu großzügig bündelt. Beispiel: Man stellt auf wöchentliche Alerts um und überliest, dass in der Zwischenzeit ein gravierender Fall im Sumpf war. Dem sollte entgegengewirkt werden, indem man wirklich nur moderate Policies verzögert und kritische weiterhin sofort eskaliert. Ein anderes Risiko: Falsche Empfänger – wenn man nicht sauber trennt, könnten Personen Alerts sehen, die sie nicht sehen sollten (daher stets pseudonymisiert, aber trotzdem). Daher gut festlegen, wer welche Policy administriert. Nebenwirkung könnte sein, dass Reviewer sich an den neuen Rhythmus gewöhnen müssen – Disziplin ist gefragt, den Weekly Report auch wirklich gründlich durchzugehen. Außerdem besteht die Gefahr, dass bei längeren Intervallen mehr Einzelvorfälle pro Mail drinstehen und man etwas übersieht. Hier hilft es, die Alerts in Portal-Ansicht zu prüfen, wo man sortieren kann. Insgesamt sind die Nebenwirkungen aber kontrollierbar, wenn man es bewusst einsetzt. Positiv zu erwähnen: Microsoft hat weiterhin Privacy-Guardrails drin (Pseudonyme, RBAC), die Änderungen betreffen hauptsächlich den Workflow, nicht die inhaltliche Prüfung. Also Datenschutz bleibt unverändert hoch. Alles in allem erhöht diese Neuerung die Effizienz im Compliance-Team erheblich – solange man klug konfiguriert, sollte kein wesentliches Risiko neu entstehen.

Quellen: Microsoft 365 Message Center MC920304, Roadmap ID 181825

Insider Risk Management: Analytics – 360°-Benutzerüberblick

Was ist neu? Insider Risk Management (IRM) User Analytics liefert nun vereinheitlichte Benutzer-Übersichten über verschiedene Risikoindikatoren hinweg. Konkret können berechtigte Analysten im Purview-Portal für einen gegebenen Benutzer ein Dashboard sehen, das DLP-Events, Defender-Alerts und Communication Compliance Hinweise zu dieser Person zusammenfasst. Früher waren solche Daten über verschiedene Tools verteilt – jetzt gibt es eine konsolidierte Sicht pro User. Diese Funktion wurde im Laufe 2025 vorbereitet (Preview) und ist seit Ende Januar 2026 GA für alle Umgebungen. Voraussetzung: IRM Analytics muss in den Einstellungen aktiviert sein (kann aber auch opt-out erfolgen). Standardmäßig wurde es initial bei allen Tenants mit IRM eingeschaltet, mit Option für Admins, es zu deaktivieren.

Warum kommt das jetzt? Insider-Risiken zeichnen sich oft ab, indem verschiedene Puzzleteile ein Bild ergeben. Beispielsweise ein Mitarbeiter, der zuerst ungewöhnlich viele Dateien herunterlädt (Defender/UEBA Info), dann vielleicht versucht, sie extern zu senden (DLP), und gleichzeitig auffällig negative Kommunikation zeigt (Comm Compliance). Bisher musste ein Analyst in jedem Tool separat nachsehen. Microsoft reagiert hier auf den Ruf nach Holistischer Sicht: IRM verspricht ja, Kontext herzustellen. Mit KI und Analytics lässt sich aus den isolierten Signalen viel besser eine Risk-Story erkennen. Zudem wächst das Datenvolumen – man braucht smarte Zusammenfassungen. Nicht zuletzt hat Microsoft in 2025 das Programm „Insider Risk für SMB“ und allgemein breitere Nutzung gepusht; es muss also einfacher bedienbar werden. Ein einheitlicher Analytics-Bereich pro User spart Zeit und ermöglicht schnellere, fundiertere Entscheidungen, ob ein Vorfall wirklich eskaliert werden muss. Die Integration verschiedenster Signals (Defender, DLP, etc.) zeigt auch Microsofts Plattform-Vorteil – etwas, das Third-Party-Lösungen so nicht bieten können.

Praxisbeispiel: Ein IT-Admin fällt auf: Innerhalb einer Woche lädt er 100 GB an Daten aus SharePoint herunter, einschließlich sensibler Dateien, was DLP-Alarme generiert. Gleichzeitig beobachtet Defender for Cloud Apps, dass er eine ungewöhnliche Anzahl von Dateien in seinen privaten Cloud-Speicher hochlädt (Shadow IT Alarm). Kurz darauf meldet Communication Compliance, dass er in Teams einem Kollegen gegenüber Unmut über die Firma äußert („bin eh bald weg, klaue noch ein paar Scripts“ – pseudonymisiert erfasst). Vor IRM Analytics: Der Insider Risk Analyst hätte drei unterschiedliche Systeme bemühen müssen und eventuell nicht erkannt, dass alle Signale denselben Benutzer betreffen. Jetzt sieht er im User Analytics Dashboard für diesen Admin alle diese Risk Factors aufgelistet: DLP: 5 Rule-Matches (Mass download), Defender: Cloud uploads flagged, CommComp: Toxic language flagged. In Summe ergibt das ein klares Bild eines potenziell abwandernden, Daten exfiltrierenden Mitarbeiters. Der Analyst kann sofort ein IRM-Fall eröffnen mit diesen Infos. Dieses Beispiel demonstriert, dass die Gesamtsicht die Dringlichkeit offenbart, die einzelne Events für sich vielleicht nicht hatten.

Auswirkung für Anwender: Die Benutzer, um die es geht, merken davon natürlich nichts Gutes – denn sie stehen ja unter Verdacht. Insgesamt ist IRM so konzipiert, dass Privacy gewahrt bleibt für Unbeteiligte (Benutzernamen pseudonymisiert bis zur Notwendigkeit). Für die allermeisten Mitarbeiter hat es also keine spürbare Auswirkung, außer dass vielleicht Insider Risk insgesamt besser greift, was präventiv das Sicherheitsgefühl steigern kann. Ein fairer Punkt: Wenn User wissen, dass solche Analytics existieren, könnte es das Abschreckungsgefühl erhöhen („Die Firma würde merken, wenn ich Dummheiten mache, weil sie ja verschiedene Signale zusammenführt.“). Es liegt am Unternehmen, ob und wie es solche Mechanismen transparent macht. Oft bleibt IRM intern vertraulich. Wichtig: Solange jemand nichts falsch macht, passiert auch nichts – IRM Analytics rummt nicht unnötig in Daten herum, sondern aggregiert nur bei Risikoindikatoren. Für einen „normalen“ Anwender ändert sich nichts im digitalen Alltag.

Auswirkung für Admins: Für das Insider Risk Team ein Game-Changer in der täglichen Arbeit. Analysten können viel schneller priorisieren: Das Dashboard zeigt relative Risikowerte, Trends und alle relevanten Alerts mit Zeitachse. Admins müssen zunächst sicherstellen, dass Analytics aktiviert ist (Purview-Einstellungen > Insider Risk > Analytics toggeln). Standard war im Rollout: An, mit Opt-out möglich. Falls Bedenken (z. B. Betriebsrat in Deutschland) existieren, hätte man opt-out gemacht – aber dann entginge einem der Nutzen. Aus Admin-Sicht muss man noch prüfen, ob alle Datenquellen eingebunden sind: Die Integration zieht ja aus Defender, DLP etc. Dafür muss z. B. M365 Defender-Lizenz vorhanden sein oder entsprechende APIs verbunden. Wenn IRM schon Cases generiert, sollten Admins nun ihre Workflows anpassen: Möglicherweise sieht man in Analytics Auffälligkeiten, bevor ein offizieller „Alarm“ triggert, und kann proaktiv handeln. Admins sollten auch Schulung erhalten im Umgang: Das Dashboard bedient sich etwas anders als traditionelle Listen. Thema Berechtigungen: Nur IRM-Role-Group Mitglieder können diese Personensichten einsehen – Admins müssen also prüfen, wer alles diese sensitive Rundumsicht hat (entsprechend nur engster berechtigter Personenkreis). Bei der Einführung solcher Analytics sollte man intern auch immer rechtliche Aspekte im Blick haben (gerade in DACH mit Mitbestimmung): Aber da IRM ja pseudonymisiert startet und freigegebene Lösung ist, ist das meist geklärt. Alles in allem erlaubt es Admins, Trends zu erkennen (“Warum häufen sich bei Abt. X die DLP & Defender Hits?”) und gezielte Prävention zu machen.

Was müssen wir tun?
– Minimum: IRM Analytics aktivieren (falls nicht bereits aktiv) in den Tenant-Einstellungen. Die Standardeinstellung Ende Jan 2026 war aktiviert für alle mit IRM, aber ein Check schadet nicht.
– Besser: Integration prüfen: Sind alle relevanten Quellen mit IRM verbunden (Defender alerts, DLP events, CommComp)? Falls das Feature anzeigt “keine Daten”, obwohl es sollte, ggf. die Konfigurationen (z. B. Data Sharing toggle im IRM-Settings) sicherstellen. Dann erste Analysen durchführen: Risikonutzer identifizieren, Dashboards sichten, Team damit vertraut machen.
– Sehr gut: Use-Case-Playbooks anpassen: Definieren, ab welchem kombinierten Risk-Level Schritte eingeleitet werden (z. B. HR informieren, Gerätemonitoring intensivieren etc.). Eventuell Alarmierungsregeln: IRM bietet Score-Berechnungen – man könnte z. B. Power Automate nutzen, um ab Score X eine Nachricht ans SecOps zu senden. Außerdem: Trainings für das Insider Risk Response Team, um sicher mit dem neuen All-in-One-View umzugehen und Bias zu vermeiden (nicht nur weil jemand viele Alerts hat, gleich Schuld zuweisen – immer noch Kontext prüfen). Auch sinnvoll: Erfolg messen – z. B. tracken, ob man dank Analytics Vorfälle früher entdeckt hat (Vorher/Nachher-Vergleich).

Risiken & Nebenwirkungen: Ein offensichtlicher Punkt: Datenschutz und Mitarbeiterkontrolle. IRM ist immer ein Balanceakt – kombiniert man nun alles über einen Mitarbeiter an einer Stelle, könnte es kritisch gesehen werden hinsichtlich Persönlichkeitsrechten. Unternehmen müssen die Einsatzgrenzen wahren (z. B. wirklich nur bei berechtigtem Interesse und definierten Triggern Personen de-pseudonymisieren). Technisch bietet Microsoft die Pseudonymisierung per default, also ist dieser Aspekt mitigiert, solange man sauber arbeitet. Ein anderes Risiko: False Positives in Summe – mehrere ungefährliche Einzelaktionen könnten zusammen fälschlich gefährlich aussehen. Das Team muss daher weiterhin menschlich bewerten und darf nicht blind dem Score vertrauen. Auch gilt: Wenn Daten aus einer Quelle fehlen oder fehlerhaft sind, könnte das Gesamtbild verzerren. Daher Data Sharing und Konnektoren stets checken. Nebenwirkung könnte sein, dass das IRM-Team anfangs mit zu vielen “interessanten Fällen” konfrontiert wird, weil nun mehr auffällt. Man sollte ggf. die internen Schwellen behutsam nachjustieren, damit nicht plötzlich jeder kleine Regelverstoß einen „User at Risk“ zeigt. Zusammengefasst: Mit großer Macht kommt große Verantwortung – das gilt hier. Wird es richtig gehandhabt, überwiegen die Vorteile (frühzeitige, umfassende Einblicke in riskante Aktivitäten) deutlich die Risiken.

Quellen: Microsoft 365 Message Center MC1045212, Microsoft Learn – Enable Analytics

Insider Risk Management: OCR – Erkennung von Text in Bildern

Was ist neu? Insider Risk Management (IRM) nutzt jetzt Optical Character Recognition (OCR), um Text in Bildern und Grafiken zu identifizieren, die auf riskantes Verhalten hindeuten könnten. Beispielsweise wenn ein Nutzer sensible Informationen als Screenshot (Bilddatei) über Teams teilt oder in ein Dokument einbettet, kann IRM diesen Textinhalt nun auslesen und bewerten. Diese Erweiterung gilt für Bilder in SharePoint, Teams-Chats und auf Endgeräten. Praktisch bedeutet das, IRM kann z. B. das Vorhandensein von vertraulichen Wörtern oder Datentypen (wie Kundennummern) in PNG/JPG-Dateien erkennen – etwas, das zuvor ein blinder Fleck war. Das Feature war für Januar 2026 angekündigt und sollte zu diesem Zeitpunkt auch ausgerollt worden sein (vermutlich GA im Jan 2026). Es ergänzt IRM’s Katalog an Detektoren (bisher vor allem auf Dateioperationen, Sequenzen etc.).

Warum kommt das jetzt? Immer mehr Kommunikation passiert über Bilder, Screenshots, Grafiken – sei es das Foto eines Whiteboards, ein abfotografiertes Dokument oder ein Meme mit eingebettetem Text. Insider mit Vorhaben, DLP zu umgehen, nutzen gerne Screenshots (z. B. Abfotografieren statt Kopieren von Text). Um nicht hinterherzuhinken, erweitert Microsoft IRM um diese Fähigkeit, denn Informationen in Bildern können genauso zum Datenleck werden. Technologisch hat Microsoft sicher an verbesserten OCR-Modellen gearbeitet, teils auch beflügelt durch KI-Entwicklungen. Außerdem: Die Konkurrenz schläft nicht – man will Purview als “alles aus einer Hand”-Lösung anpreisen, die sogar Bilder scannt, anstatt separate Lösungen kaufen zu müssen. Regulatorisch gesehen verlangen manche Branchen (Verteidigung, Finanz) genau solche Fähigkeiten, um z. B. keinen Weg offen zu lassen für Datendiebstahl. Und intern: Das DLP-Team hat OCR schon länger (z. B. AIP Scanner OCR für Bilder), also war es naheliegend, IRM diesen Input auch zu geben.

Praxisbeispiel: Ein Mitarbeiter der F&E macht heimlich Handyfotos von vertraulichen Konstruktionsplänen auf dem Bildschirm oder erstellt Screenshots als PNG-Datei und lädt sie in seinen persönlichen OneDrive hoch. Früher: IRM hätte vielleicht bemerkt „Es wurden 10 PNGs hochgeladen“, aber nicht gewusst, was drauf ist – könnte harmlos sein (Urlaubsfotos) oder kritisch. Jetzt: IRM (bzw. die zugrundeliegenden Sensoren in Defender/DLP) erkennt, dass diese Bilder Text enthalten, der z. B. Projektcodes oder Begriffe wie „Prototyp“ enthält. Das fließt als Signal ein: User hat Bilder mit potentiell sensiblen Textteilen exfiltriert. Kombiniert mit anderen Indikatoren (Nutzer kündigt vielleicht bald, etc.) ergibt das ein volleres Risikobild (siehe IRM Analytics oben). Durch OCR kann der Analyst im IRM-Fall sich sogar einen Ausschnitt des erkannten Texts anzeigen lassen, um zu beurteilen, wie brisant das ist (sofern entpseudonymisiert im Fall). Im Ergebnis konnte ein möglicher Datenabfluss über Bilder erkannt werden, der ohne diese Funktion komplett unbemerkt geblieben wäre.

Auswirkung für Anwender: Für den normalen Mitarbeiter hat dies keine spürbaren Auswirkungen – es sei denn, er versucht gezielt, über Bilder Informationen zu teilen, die er eigentlich nicht sollte. In dem Fall steigt die Wahrscheinlichkeit, dass er doch erwischt wird. Die meisten Mitarbeiter werden aber kaum bemerken, dass da im Hintergrund OCR mitläuft. Vielleicht interessant: Wenn ein Mitarbeiter mal erlaubt etwas wie „vertraulich“ auf eine Grafik schreibt, könnte es theoretisch IRM’s Aufmerksamkeit erregen – aber das wäre ja auch gewollt, wenn es vertraulich ist. Datenschutztechnisch ändert sich am Endpunkt oder in der Cloud wenig, da dieselben Richtlinien wie für Text greifen, nur dass eben mehr Content analysiert wird. Wer bisher dachte, er könne per Screenshot sensible Daten „verstecken“, wird sich umstellen müssen – aber aus legitimer User-Sicht sehe ich keine negativen Effekte. Wichtig ist transparenzhalber intern: In den Compliance-Schulungen eventuell erwähnen, dass auch Bildinhalte unter die Schutzmechanismen fallen, damit es fair bleibt.

Auswirkung für Admins: Admins sollten diese Verbesserung begrüßen, da sie Insider Risk Coverage deutlich erhöht. Technisch ist es ziemlich automatisch – im Purview-Portal gibt es nicht unbedingt separate Einstellungen; es ist Teil der IRM-Engine. Allerdings sollten Admins prüfen, ob Policies/Security Tools die OCR-Daten auch liefern: Beispielsweise muss der Defender Endpoint Sensor OCR für DLP aktiviert haben (meist Standard). In Purview IRM selbst könnte es neue Policy-Indikatoren geben, wie “Text im Bild erkannt” – Admins sollten die Indikator-Liste durchgehen und anpassen, falls nötig. Außerdem kann die Zahl der Inzidente steigen, weil Dinge aufgegriffen werden, die früher ignoriert wurden. Admins sollten also Berichte neu kalibrieren: „Wieso haben wir auf einmal 5 neue Alerts in IRM? Ach, das sind Bild-Screenshots, die wir früher nicht hatten.“ Ggf. heißt es, Nutzer darauf hinzuweisen oder weitere Controls einzubauen (z. B. Screenshot-Logging). Performance/Kosten: OCR kann rechenintensiv sein – aber das läuft cloud-seitig; Admins sollten nur im Auge behalten, ob Audit oder Log-Speicher dadurch deutlich anwächst. Alles in allem erfordert es wenig Admin-Intervention – mehr ein Bewusstseins-Update, dass man nun noch genauer hinschauen kann. Ein Test wäre sinnvoll: Einen Testuser mit einem Bild mit bekanntem verbotenem Wort durch das System schicken und gucken, ob IRM anschlägt, um Vertrauen zu haben, dass es funktioniert.

Was müssen wir tun?
– Minimum: Sicherstellen, dass die Insider Risk Policies relevanten Typs (z. B. Datendiebstahl) aktiv sind – das OCR-Feature greift automatisch, solange IRM läuft. Keine separate Aktivierung nötig, aber Release Notes lesen um Details zu kennen (z. B. welche Sprachen OCR erkennt – vermutlich viele, aber Fokus auf englisch).
– Besser: Test und Monitoring: Bewusst ein paar Szenarien durchspielen (Screenshot mit „vertraulich“ in Text speichern – gucken ob IRM-Score steigt). Logs beobachten. Falls nötig, Policy-Indikatoren ergänzen: vielleicht neuen Indikator “Bild mit sensiblen Inhalten exfiltriert” in die Score-Berechnung aufnehmen, falls MS das nicht automatisch tat.
– Sehr gut: Kommunikation & Schulung im Team: Das Insider Risk Response Team sollte wissen, dass ab jetzt auch Bilder kritisch sein können. Eventuell muss man Forensik-Prozesse anpassen: Wenn IRM sagt „in Bild Text erkannt“, wie validiert man das? Wer fordert ggf. Originalbild an? Zudem präventiv in Awareness-Schulungen für Mitarbeiter erwähnen (ohne zu sehr auf Interna einzugehen), dass „Screenshots kein sicherer Umgehungsweg sind, auch diese fallen unter Richtlinien“. Das erhöht die Abschreckung. Schließlich: Policy-Tuning – falls zu viele harmlose OCR-Erkennungen stattfinden (z. B. Firmenlogo mit Wort „Geheim“ triggert ständig), diese Ausnahmen definieren.

Risiken & Nebenwirkungen: Das größte Risiko ist vielleicht Overblocking oder Overalerting, falls OCR mal Text findet, der gar nicht kritisch ist, aber wie ein Trigger aussieht. Beispiel: Ein Urlaubsfoto mit irgendwo einem Schild „Restricted Area“ – könnte theoretisch als Wort „Restricted“ anschlagen. Aber da IRM erst ab cumulierter Risiken handelt, ist das gering. Dennoch: false positives müssen beobachtet werden. Ein anderes Thema: Spracherkennung – OCR kann z. B. deutsche Umlaute oder andere Sprachen evtl. nicht 100% – in multinationalen Firmen sollte man prüfen, ob relevant. Falls z. B. nur englische Patterns erkannt werden, müsste man drauf achten bei deutschen Dokumenten. Nebenwirkung könnte sein, dass IRM-Fälle jetzt umfangreicher werden, weil text from images dabei ist – Analysten brauchen eventuell etwas längerer pro Fall. Performance: minimal höherer CPU in Cloud, adminseitig egal, aber evtl. kleine Kostenfaktoren (Advanced Audit entlasten? Aber nein, das läuft in Purview). Ein Risiko wäre auch, dass Mitarbeiter das als “weitere Überwachung” empfinden, falls transparent – daher gilt wie immer: im rechtlichen Rahmen bleiben, Staff Council etc. Insgesamt ist OCR aber in vielen anderen Tools längst Standard (z. B. DLP beim Scannen von Files) – es war eher riskant, es bisher nicht in IRM zu haben. Jetzt ist diese Lücke weg, was das Gesamtrisiko deutlich senkt, bei minimalen Nebenwirkungen.

Quellen: Microsoft 365 Roadmap ID 410247, RyanTech Update (OCR in IRM)

Insider Risk Management: höhere Grenzwerte für Varianten & Gruppen

Was ist neu? Microsoft hat die Kapazitätsgrenzen für IRM-Richtlinien deutlich erhöht. Bisher konnte man max. 3 Varianten pro Indikator definieren, insgesamt bis zu 100 Varianten über alle Indikatoren, und in einer Detection Group (z. B. Liste überwachter Nutzer oder Devices) max. 200 Einträge. Mit dem Update steigt dies auf 10 Varianten pro Indikator, bis zu 100 Varianten gesamt, und Detection Groups bis 500 Elemente. Diese Änderungen wurden ab Dezember 2025 Preview und im Januar 2026 GA ausgerollt. “Varianten” sind unterschiedliche Schwellen oder Parameter für einen Indikator (z. B. Indikator „Mass Download“ könnte Varianten für >100 Dateien, >500 MB etc. haben). Detection Group Items sind z. B. Benutzer oder Abteilungen, die man einer Policy zuweist – hier ist das Limit nun höher.

Warum kommt das jetzt? Kunden mit größeren Umgebungen oder komplexeren Risikomodellen stießen an Grenzen. Z. B. eine Policy, die verschiedene Abstufungen eines Verhaltens tracken will (3 Varianten waren da zu wenig). Oder Unternehmen mit mehr als 200 sensiblen Nutzern/Regionen – sie mussten mehrere Policies erstellen, um alle abzudecken, was unübersichtlich ist. Microsoft möchte IRM in großen Enterprises skalierbarer machen und zugleich feiner justierbar. Das Feedback floss ein: „Give us more flexibility – 3 variants aren’t enough!“ Zudem entwickelt sich IRM weiter, mehr Indikatoren kamen hinzu, also auch mehr Kombinationsbedarf. Die Erhöhung auf 10 bzw. 100 mag klingen wie willkürliche Zahl, ist aber vermutlich nach Analyse gängiger Bedürfnisse gewählt. Im Kontext Q1 2026: MS hat gleichzeitig das AI-gestützte ‚adaptive protection‘ angekündigt, wo auch mehrere Varianten/Parameter relevant sind. Insgesamt passt es zur Reifephase: Jetzt wo viele initiale IRM-Deployments laufen, geht es ans Fine-Tuning – und dafür braucht man größere Limits.

Praxisbeispiel: Ein multinationaler Konzern nutzt IRM mit einer “Datendiebstahl”-Policy. Sie wollen differenzieren: Massendownload klein (<500 Dateien) vs. groß (>2000 Dateien) vs. sehr groß, jeweils mit unterschiedlichen Scores. Bisher konnten sie nur 3 Stufen abbilden – das hat für 2 Standorte gereicht, aber nicht global. Jetzt können sie bis zu 10 Varianten definieren: z. B. je Region unterschiedliche Schwellen (da in großen Standorten andere Norm ist als in kleinen). Gleichzeitig haben sie ca. 300 Benutzer in kritischen Rollen, die sie in der Policy überwachen – bisher mussten sie 2 Policies machen (200+100), jetzt können alle 300 in einer Policy abgedeckt werden. Das spart Arbeit und vermeidet Lücken. In der Praxis richten sie nun in einer einzigen IRM-Policy für “Datendiebstahl global” alle relevanten Nutzer und bis zu 10 abgestufte Varianten ein. Ergebnis: Weniger Policies, bessere Übersicht, feinere Differenzierung. Der Analyst sieht dann z. B. sofort, ob ein Vorfall „Level 1“ oder „Level 5“ war, je nachdem welche Variante gefeuert hat.

Auswirkung für Anwender: Für die überwachten Benutzer ändert sich dadurch unmittelbar nichts – diese Limits betreffen die interne Konfiguration. Indirekt könnte es bedeuten, dass weniger false positives (weil man feiner steuern kann) generiert werden, was ja auch im Interesse der Mitarbeiter ist, die fälschlich verdächtigt werden könnten. Außerdem kann man nun mehr Personen in eine Policy packen statt Aufsplitten – aber das merkt der Anwender nicht; er weiß ja idR nicht, ob er in 2 Policies drin war oder einer. Falls manche wegen Limit nicht drin waren und nun aufgenommen werden, könnte man sagen: es werden mehr Mitarbeiter als zuvor unter IRM-Monitoring stehen. Aber realistisch: Große Firmen mit >200 sensiblen Nutzern hatten wahrscheinlich eh mehrere Policies genutzt. Insgesamt also keine spürbare Änderung aus Anwendersicht, außer dass IRM-Prozesse geschmeidiger laufen und bei Bedarf mehr Leute abdecken können (was Sicherheitsniveau erhöht).

Auswirkung für Admins: Großer Vorteil für IRM-Admins und -Analysten. Sie können nun komplexe Policies in weniger Regeln zusammenfassen, was Management erleichtert. Konkrete To-dos: Bestehende IRM-Policies überprüfen – gibt es welche, die nur wegen alter Limits aufgesplittet waren? Diese ggf. zusammenführen, um es übersichtlicher zu machen. Oder Policies, bei denen man gern mehr Varianten hätte (z. B. different file types thresholds) – nun hinzufügen, statt separate Indikatoren zu basteln. Admins sollten auch die Konfigurations-UI nach den Updates checken: In der Policy-Settings wird nun z. B. erlaubt sein bis 10 Varianten anzugeben (früher war UI auf 3 Felder begrenzt). Ggf. gibt es anfangs noch kleine GUI-Bugs (Preview-Phase), aber das meiste sollte in GA behoben sein. Wichtig: Diese Änderung verführt dazu, sehr komplexe Policies zu bauen – Admins sollten aber achten, es nicht zu übertreiben, sonst wird es unverständlich. Trotzdem, endlich können sie realistischer z. B. Abteilungen differenzieren. Speziell Security-Teams in großen Firmen (mit hunderten “Watchlist”-Personen) werden aufatmen – 500er Limit erspart Workarounds mit gruppenbasierten Einstellungen. Allerdings muss man dort auch Performance im Auge behalten: Eine Policy mit 500 Nutzern und 10 Varianten wird evtl. mehr Alerts generieren. Admins sollten Monitoren, ob Systemlast oder Latenzen zunehmen; MS hat aber im Message Center klargemacht, es ändert an Privacy und Mechanik sonst nichts, nur Limits. Admins könnten nun geneigt sein: “Wenn 10 Varianten gehen, nutzen wir auch alle 10!” – Empfehlung: nur nutzen, wenn sinnvoll. Ansonsten alles gut.

Was müssen wir tun?
– Minimum: Überprüfen Sie IRM-Policies mit früherem Limit-Druck. Wenn Sie z. B. zwei Policies “Privileged Users 1” und “2” hatten wegen 200er Limit, erwägen Sie, sie zusammenzulegen. Das geht aber nicht automatisch – also Plan machen.
– Besser: Neue Varianten definieren: Nutzen Sie die Chance, um Policies feinzujustieren. Evtl. Indikatoren, bei denen Sie Kompromisse eingehen mussten („Wir tracken Download >1000, alles darunter ignorieren“), können nun in Stufen aufgeteilt werden (500, 1000, 5000 etc.), was eine bessere Risikoabstufung erlaubt. Testen Sie die Policy danach gründlich (Simulationsmodus falls vorhanden).
– Sehr gut: Dokumentation & Training: Wenn Ihr Team bisher z. B. 3-Schwellwerte-Logik verinnerlicht hat, updaten Sie interne Dokus: “Jetzt bis zu 10 möglich.” Schulen Sie an einem Beispiel, wie man Varianten vs. separate Indikatoren sinnvoll nutzt – damit nicht Chaos entsteht. Auch das Lizenz- und Kostenmodell im Blick behalten: Mehr überwachte Nutzer bedeuten evtl. mehr Logs, aber Purview Suite deckt das ab. Und: Feedback an Microsoft geben, falls neue Limits noch nicht reichen – sie haben offen diese per Roadmap adressiert, also sind sie auf Feedback angewiesen.

Risiken & Nebenwirkungen: Komplexität vs. Verständlichkeit: Mehr Varianten = potentielle Überkonfiguration. Gefahr, dass Policies so komplex werden, dass Analysten den Überblick verlieren (“Variante 7 triggered – was hatte das noch mal bedeutet?”). Hiergegen hilft gute Benennung und Dokumentation innerhalb der Policy (z. B. Beschreibungsfeld nutzen). Ein weiteres Risiko: Fehler beim Zusammenführen: Wenn Admins mehrere Policies zu einer konsolidieren, könnten Einstellungen verloren gehen oder es schleichen sich Lücken ein. Daher sorgfältig migrieren (ggf. parallel laufen lassen zum Abgleich). Technisch hat Microsoft versichert, keine Privacy- oder Compliance-Auswirkungen – also keine neuen Daten gesammelt, nur wie man sie konfigurieren kann. Nebenwirkung könnte sein, dass Reporting und Alerts kurzzeitig ansteigen oder unübersichtlich werden, wenn man viele Varianten nutzt – aber darin liegt ja auch die Stärke (differenzierte Alerts). Performance sollte i. d. R. kein Problem sein; falls doch, MS Support einbinden. Insgesamt sind dies “Soft Limit”-Erhöhungen, die nur Vorteile bringen, wenn man sie bewusst nutzt, und wenig Nachteil, wenn man so weiter macht wie bisher (man muss ja nicht mehr Varianten nutzen). Ein kleiner Nebeneffekt: IRM ist E5 – manch einer im Unternehmen könnte fragen: “Wenn wir jetzt 500 Leute überwachen können, nutzen wir das?” – da muss man gut begründen, wen man ins Monitoring nimmt, um nicht Overreach in der Belegschaft zu betreiben. Mit Fingerspitzengefühl eingesetzt, hilft die Neuerung aber primär dem Admin-Team, skaliert Schritt zu halten mit Organisationsgröße.

Quellen: Microsoft 365 Message Center MC1194606

Information Protection: Sensitivity Labels – von Eltern/Kind zu Label-Gruppen

Was ist neu? Microsoft vereinfacht die Struktur der Sensitivity Labels: Anstelle des alten Parent/Child-Label-Modells (übergeordnete Labels mit Sublabels) werden Labels nun in Label-Gruppen organisiert. Für Admins ändert sich optisch im Purview-Portal wenig, aber im Hintergrund wird die Label-Hierarchie migriert. Tenants, die keine verschachtelten Labels hatten, wurden automatisch umgestellt; wer Parent Labels benutzt, bekommt ein Guided Upgrade. Das neue Schema bietet mehr Flexibilität und verringert Komplexität, aber ohne dass Endnutzer etwas davon sehen – es ist eher eine Backend-Verbesserung. Der Rollout der automatischen Migration startete Januar 2026 (GA) und war für die nächsten Monate geplant. Ein grüner Hinweis-Banner informiert Admins, sobald die Umstellung im Tenant erfolgte.

Warum kommt das jetzt? Das bisherige Modell mit „Parent Label“ (Kategorie) und “Child Labels” (die eigentlichen Labelstufen) stammte aus der Anfangszeit von Azure Information Protection. Es zeigte sich als unflexibel, z. B. konnte ein Sublabel nicht zwei Parent-Kategorien angehören; es gab oft Verwirrung bei mehrstufigen Klassifizierungen. Zudem werden Labels mittlerweile vielfältiger verwendet (u.a. für Schematags, Copilot Prompts etc.), was flachere Strukturen braucht. Label-Gruppen erlauben es, Labels frei zu gruppieren (auch mehrere Ebenen, aber logischer gruppiert). Vermutlich hat Microsoft auch unter der Haube das Label-Storage refaktoriert, um künftige Funktionen (z. B. dynamischere Label Zuweisung oder Copilot-Integration mit Labels) zu erleichtern. Angekündigt wurde diese Modernisierung schon 2025; Q1 2026 markiert nun den GA-Rollout, weil man jetzt genug getestet hat. Es ist ein Schritt zu mehr Übersicht im Admin-Center und „weniger Legacy-Ballast“. Zudem entfallen einige Alt-Einschränkungen – das kommt bei Kunden mit vielen Labels (teils >100) gut an.

Praxisbeispiel: Ein Unternehmen hatte bisher ein Parent Label „Vertraulich“ mit 3 Sublabels („Öffentlich“, „Intern“, „Streng Vertraulich“ – wobei streng vertraulich komischerweise unter „Vertraulich“ hing). Benutzer sahen im Office nur die 3 Sublabels (was okay war). Im Portal aber war das Parent Label ein Extra-Eintrag, der selbst kein Tagging war. Nach der Migration zu Label-Gruppen gibt es schlicht eine Gruppe „Vertraulichkeit“ und darunter die 3 Label als gleichwertige Einträge. Für die Anwender bleibt das Drop-down gleich. Für Admins aber fällt die mögliche Verwirrung weg, warum z. B. Parent-Label keine Einstellungen hat (Gruppen haben auch keine Einstellungen außer Namen) – nun ist klar: Gruppe ist Container, Label ist das, was angewendet wird. Ein anderes Beispiel: Früher konnte man eine Sublabel nicht außerhalb seines Parent verschieben. Nun könnte man flexibel Labels in andere Gruppen packen, ohne neu erstellen zu müssen. Insgesamt merkte der Admin nach dem Umstieg: Die Label-Verwaltung ist übersichtlicher, keine „Wurzel-Labels“ mehr, und neue Labels können besser strukturiert werden z. B. nach Zweck („Datenschutz-Labels“, „Retention-Labels“ separate Gruppen). Im täglichen Betrieb ändert sich für User so gut wie nichts – aber für Admins wird zukünftig Planung erleichtert (keine tiefen Hierarchien).

Auswirkung für Anwender: Für Endanwender wurde laut Microsoft “kein sichtbarer Change” eingeführt. Ihre Office-Apps zeigen die gleichen Labelnamen und Strukturen an wie zuvor. Das war vermutlich auch Microsofts Priorität – keine Disruption am Frontend. Es kann allerdings zu minimalen Terminologie-Änderungen kommen, wenn das Unternehmen intern bisher von „Kategorie“ vs. „Label“ sprach – künftig spricht man eher von „Label-Gruppen“ vs. „Labels“. Wenn überhaupt, könnte es den Anwender entlasten, dass man keine Parent-Label-Auswahlen mehr sieht, die selbst kein Label darstellen. Manche hatten sich gewundert, warum es klickbare Kategorien gab, die nichts taten. Jetzt sieht man nur noch echte Label als Auswahl (es sei denn, Gruppen werden im UX noch angezeigt, mal abwarten – vermutlich nicht auswählbar). Insgesamt bleibt der Anwenderimpact minimal. Wichtig ist: All ihre bereits klassifizierten Dokumente behalten natürlich ihre Labels (die GUIDs etc. ändern sich nicht fundamental, es ist eine logische Neuordnung im Backend). Also keine Sorge – kein Re-Labeling notwendig auf User-Seite.

Auswirkung für Admins: Für Admins bringt es Vereinfachung und Potenzial für bessere Organisation. Kurzfristig heißt das: Sie sollten den Migrationsstatus prüfen. Wenn Banner anzeigt, dass umgestellt wurde, kann man in Information Protection > Labels nun Gruppen sehen. Alle bisherigen Parent-Labels sind jetzt Gruppen, Sublabels sind reguläre Labels in der Gruppe. Admins sollten kontrollieren, ob alle Einstellungen korrekt übernommen wurden – MS verspricht ja, es ändert sich nichts in der Wirkung. Trotzdem: Double-Check z. B. Schutz-Einstellungen, Scope etc. Falls man Scripts oder Automatisierungen hat, die Parent/Child-Struktur annahmen (PowerShell Get-Label früher gab ParentId etc.), müssen die evtl. angepasst werden auf das neue Modell. Künftige Label-Planung kann man nun überdenken: Man ist freier, z. B. kann man neue Gruppen anlegen, um Labels logisch zu bündeln (z. B. separate Gruppe für Verschlussgrade vs. Abteilungstags). Admins sollten aber beachten: Ein Dokument kann nach wie vor nur ein Sensitivity-Label tragen. Gruppen sind nur zur Orga. Mögliche Fallstricke: Client-Software älterer Versionen – aber in 2026 sollten die meisten auf unterstütztem Stand sein. Testing: Einmal einen kompletten Label-Publish-Zyklus prüfen (alle Labels veröffentlicht wie erwartet?). Lizenz: Labeling generell E3 (P1), aber was relevant sein könnte: Sublabel-Limit war mal 1 Stufe – ob Gruppen mehrstufige Hierarchie zulassen, ist eine Info, die man nachlesen sollte. Evtl. kann man jetzt auch Hierarchien >1 machen, aber official heißt es „reduziert complexity“, also wohl flachere Struktur. Admins sollten jetzt schrittweise die interne Terminologie anpassen (Dokus, Schulungen auf „Gruppen“ ändern). Außerdem: Falls man Third-Party-Tools hatte, die Label-Parent zum etwas nutzten, updaten. Summa summarum: Der Admin-Aufwand ist moderat (Primär Verifizieren der Migration und leichte Dokuanpassungen), aber der Nutzen ist langfristig spürbar in besserer Übersicht.

Was müssen wir tun?
– Minimum: Migration verfolgen: Prüfen, ob im Tenant schon umgestellt (Banner im Purview Portal). Falls nicht und man hat Parent/Sublabel im Einsatz, Migrations-Doku lesen und vorbereiten. Falls schon um, dann kontrollieren, ob alle Labels in richtigen Gruppen gelandet sind.
– Besser: Dokumentation & Scripts updaten: Alle internen Handbücher, die von „Übergeordnetes Label“ sprechen, anpassen auf neues Wording. PowerShell-Skripte, die ParentName oder -ParentLabel Parameter genutzt haben, gegen neue Cmdlets prüfen (Microsoft stellt sicher Doku bereit). Mitarbeiter, die Label-Admin sind, auf kurze Schulung schicken was neu ist.
– Sehr gut: Aufräumen & Neuordnen: Jetzt wäre ein guter Zeitpunkt, die gesamte Label-Taxonomie zu überprüfen. Vielleicht kann man dank Gruppen neue sinnvolle Strukturen schaffen (z. B. separate Gruppen für Geschäftsgeheimnisse vs. Öffentliche Klassifikationen), ohne Auswirkungen auf User-Fluss. Nutzen Sie diese Chance, um Label-Sprawl einzudämmen oder konsolidieren (manche hatten durch Parent-Child Workarounds doppelte Labels). Führen Sie in dem Zuge gleich ein Label-Policy Review durch: Welche Labels sind in welchen Office-Publishing-Policies? Können wir das verschlanken?

Risiken & Nebenwirkungen: Ein Risiko wäre Migration Pannen – wenn z. B. ein Sublabel nicht richtig zugeordnet wird. Daher testet nach der Umstellung z. B. an einem Dokument alle wichtigen Labels, ob die Policy-Effekte (Schutz, Header, etc.) stimmen. Microsoft hat sicher gründlich getestet, trotzdem Vorsicht. Nebenwirkung in älteren Clients: Sofern jemand noch Office 2016 mit AIP-Plugin nutzt (nicht mehr offiziell, aber manche tun’s) – dort könnte evtl. eine Inkompatibilität auftauchen. Also modern clients sind Voraussetzung. Eine unbeabsichtigte Nebenwirkung könnte sein, dass Admins anfänglich verwirrt sind, wo früher “Parent Label” stand, ist jetzt “Group” – aber das ist rein begrifflich. Leistungs-/Performanceauswirkungen sind keine zu erwarten, es ist ein reines Strukturthema. Die größte “Nebenwirkung” ist positiv: Weniger Limitierungen, also kann es sein, dass Admins nun sehr viele Gruppen und Labels anlegen und es wieder unübersichtlich machen. Hier interne Governance nicht vergessen: Label-Lifecycle definieren (wer darf neue Label-Gruppen erstellen, wer genehmigt?). Noch ein potenzieller Haken: Wenn man mit Unified Labeling SDK oder Graph API für Labels arbeitet, sollte man die Doku checken, wie Gruppen repräsentiert sind, damit Integrationen nicht brechen. Insgesamt aber überwiegt der Vorteil der geringeren Komplexität. Endlich muss man nicht mehr das Konzept “Parent Label (not assignable)” erklären – es heißt jetzt einfach Gruppe und gut. Fazit: Geringe Risiken, mittelfristig administrativer Segen.

Quellen: Microsoft Learn – Purview Sensitivity Labels Update

Weitere Neuerungen im Bereich Information Protection (Q1 2026):
– Labels & SharePoint-Berechtigungen: Microsoft verbesserte die Clients dahingehend, dass Sensitivity Labels mit Benutzerdefinierten Berechtigungen aus SharePoint (Co-Authoring-Szenario) besser funktionieren. Insbesondere wird jetzt „Speichern unter“ in Office korrekt unterstützt für solche Label-geschützten Dateien, auf allen Plattformen (Win ab Version Current Channel Preview Jan, Mac ab Version 16.103, iOS ab 2.103, Android ab 16.0.19426). Das bedeutet, wenn ein Dokument ein Label trägt, das z. B. nur bestimmten Personen Zugriff gibt (über SharePoint-Berechtigungstoken), bleibt diese Kontrolle erhalten, auch wenn der Benutzer das Dokument als neue Datei speichert. Früher konnte es sein, dass Save As das Label verlor oder Rechte falsch übernahm. Jetzt ist das Nutzererlebnis konsistenter und sicherer. Für Admins heißt das: Weniger Supportfälle à la „Ich habe das Dokument neu gespeichert und plötzlich konnte es jeder öffnen“. Einfach darauf achten, dass Clients aktuell sind.

– Double Key Encryption (DKE) Verbesserungen: (Keine größeren Updates in Q1 2026 vermeldet; DKE bleibt ein Nischenfeature für Top-Secret, keine GA-Neuerung in diesem Quartal.)

Records Management & Data Lifecycle: Legacy-Features raus, Purview übernimmt

Was ist neu? Microsoft kündigte an, vier alte SharePoint-Compliance-Funktionen zum April 2026 einzustellen. Konkret betroffen: Information Management Policies, In-Place Records Management in SharePoint, Dokumentlöschrichtlinien (im klassischen SPO Compliance Center) und Site-Schließungs-/Lösch-Policies. Diese „Legacy“-Mechanismen stammen aus der Vor-Purview-Ära (teils SharePoint 2010). Ab April erhalten sie keinen Support mehr und Microsoft entfernt schrittweise die UI-Optionen dafür. Purview Data Lifecycle Management und Records Management sollen diese vollständig ersetzen. Microsoft stellt Migrationsleitfäden bereit, aber keine automatische Migration – Admins müssen manuell umstellen. Parallel gab es in Q1 auch neue Purview-Funktionen für Aufbewahrung: z. B. die Möglichkeit, Retention auf Microsoft Planner-Inhalte anzuwenden (Beta Ende 2025, GA Anfang 2026) und Ankündigungen wie „Retention basierend auf letztem Zugriff“ (Preview ab Mai 2026).

Warum kommt das jetzt? Purview (ehemals Office 365 Retention) ist seit Jahren die empfohlene Lösung, doch viele Kunden hatten noch Alt-Konfigurationen in SharePoint aus älteren Migrationen. Microsoft möchte diese Altlasten loswerden, um einheitliche Compliance über Purview bereitzustellen (und auch, um nicht zig legacy Codepfade pflegen zu müssen). Die Features waren redundant: z. B. In-Place Records vs. Purview Records. Außerdem passten sie oft nicht zur Cloud – z. B. Info Management Policies waren in SPO eingeschränkt. Der Zeitpunkt Q1 2026 scheint gewählt, weil Purview inzwischen so weit gereift ist, dass es funktional alles Wichtige abdecken kann. Zudem erhöht MS damit den Druck, auf (lizenzpflichtige) Purview-Lösungen umzusteigen – gerade Records Management ist E5-only, was natürlich Umsatz bedeutet (aber auch Mehrwert). Trends: Datenwachstum und strengere Regulatorik (z. B. FINRA will einheitliche Retention, FedRAMP etc.), was Purview besser adressiert. Und man will sicherlich die User Experience vereinfachen: Weniger parallel laufende Systeme. Letztlich: 2026 jährt sich 25 Jahre SharePoint – Zeit, alten Zopf abzuschneiden.

Praxisbeispiel: Ein Unternehmen hat bisher in SharePoint eine „Information Management Policy“ genutzt, die Dokumente nach 5 Jahren auto-löschte, und teils „In-Place Records“ gesetzt, um wichtige Dateien zu schützen. Diese Mechanismen laufen autark neben Purview. Nun kommt die Nachricht: Ab April werden diese Optionen verschwinden. Der SharePoint-Admin stellt fest, dass z. B. in einer DMS-Bibliothek der Ablaufdatum-Job (Infomanagement Policy) bis April noch geht, aber dann wohl nicht mehr. Er muss also rasch migrieren: Er nutzt Purview Data Lifecycle, erstellt dort eine Retention Label oder Policy “DMS-5Jahre-Löschen” und veröffentlicht sie auf die entsprechenden Sites. Ebenso statt In-Place Records nutzt er künftig Purview Records Management (Records Labels, die z. B. einen „Record“ deklarieren und Sperren verhindern). Er plant die Umstellung so, dass idealerweise vor April alle Items entsprechend neu gelabelt sind. Microsofts Doku hilft ihm dabei, aber es bleibt manuelle Arbeit. Im Projektverlauf merkt er positiv: Purview bietet z. B. mehr Möglichkeiten (detailliertes Audit, ein zentrales Dashboard aller Aufbewahrungsregeln). Nach der Migration laufen die Löschungen und Archivierungen über Purview, und die alten SP-Optionen sind obsolet. Dadurch hat das Unternehmen jetzt eine zentrale Stelle für Retention und kann in Zukunft z. B. auch Inhalte in Exchange/Teams konsistent einbeziehen.

Auswirkung für Anwender: Im besten Fall bemerken Endnutzer davon nichts – die Policies wirken einfach weiter, nur über anderen Unterbau. Allerdings könnten sich UI-Änderungen ergeben: Früher sah der Site-Owner evtl. im Library Setting eine “Information Management Policy” Sektion – die wird verschwinden. Stattdessen greifen Purview-Labels, die Enduser evtl. als Spalte oder Tag wahrnehmen (“Retention Label: 5 Jahre”). Das könnte Fragen aufwerfen, daher sollte man Nutzer entsprechend informieren, dass nun neue Compliance-Tags genutzt werden. Für Records Management: Nutzer, die bisher via Ribbon “Declare as Record” in SharePoint klickten, müssen evtl. umlernen – Purview Records hapert etwas bei Enduser-Interaktion (Records meist auto per Label oder via Manager, nicht durch User im UI deklariert, außer man bringt Sensitivity Label mit Record = ja). Es kann also sein, dass Workflows minimal angepasst werden müssen: z. B. Anwender markieren keine Records mehr manuell, sondern der Content Type hat ein Label, das es automatisch tut. Im Einzelfall könnte es kurz Verwirrung geben (“Wo ist der Button hin?”). Kommunikation ist hier Schlüssel. Insgesamt führt es aber zu mehr Konsistenz: für Nutzer heißt es egal ob in Outlook, Teams oder SharePoint – dieselben Retention-Konzepte (Labels) gelten, was gut ist.

Auswirkung für Admins: Für Administratoren (insb. SharePoint- und Compliance-Admins) entsteht kurzfristig Handlungsdruck. Sie müssen: 1. Bestandsaufnahme aller Nutzung der Legacy-Features (Admin Center Reports, Powershell oder schlicht Inventur). Microsoft hat Migrationsdokus, aber keine Tools – Admins müssen eigenhändig entscheiden, wie welche alte Policy in Purview nachgebaut wird. 2. Lizenz-Check: Viele der alten Features waren in allen Plänen vorhanden; Purview DLM ist ab Business Premium/E3 (manuelle Labels) bzw. E5 (auto). Records Management ist E5. Admins müssen klären, ob Lizenzen für Purview-Records nötig sind für das was man will. Das könnte Budgetthema sein – notfalls bleibt man bei Purview DLM (ohne offizielle „Record“ Deklaration, nur retention). 3. Migration durchführen: Für Info Mgt Policies: in Purview entsprechende Site-scope Retention Policies. Für In-Place Records: in Purview Retention Labels mit “Mark as Record=true”, und Items entsprechend labeln (evtl. per Script). Das ist einiges an Arbeit, je nach Umfang. Admins sollten Prioritätensetzen: Business-kritische zuerst. Langfristig haben Admins dann weniger Orte zu administrieren – positiv. Und sie profitieren von Purview-Funktionen: z. B. einheitliche Audits, central disposition review etc. Aber der Migrationszeitraum ist sportlich (Jan bis Apr). Auf Admin kommt auch zu: User informieren über Änderungen, Policies anpassen (z. B. Link auf neue Doku). Außerdem neu im Q1: Retention für Planner – Admins der Compliance-Ecke sollten jetzt Planner in die Aufbewahrung aufnehmen (z. B. wenn sie „alle M365-Inhalte 3 Jahre“ Policy haben, Planner nun einschließen). Das Beta-Feature lies sich über PowerShell aktivieren, GA Q1 bedeutet normal konfigurierbar. Retention nach letztem Zugriff – Admins können sich drauf vorbereiten: in Q1 kam Updated timeline (Mid-2026 GA). Sie könnten schon analysieren, wo das nützlich wäre (OneDrive Cleanup etc.). Summa summarum: Admins sind in Q1 stark gefordert, Alt->Neu Transition und neue Purview-Funktionen in Einsatz bringen.

Was müssen wir tun?
– Minimum: Legacy-Check jetzt! Per März 2026 allerspätestens: Liste aller aktiven SharePoint Infomanagement-Policies, In-Place Records Libraries, etc. erstellen. Dann Übergangsweise Purview-Equivalents erstellen – mind. so, dass ab April nichts ungeregelt bleibt (lieber strengere retention als gar keine). Microsofts Guidance nutzen.
– Besser: Geordnete Migration vor April: Stakeholder (Records Manager, DPO, Abteilungsleiter) einbeziehen, Migrationsplan mit Testphase aufstellen. Alte Policies in SP ggf. parallel belassen bis Purview läuft, dann abschalten. Benutzer und Site Owner informieren, falls Änderungen im Handling (z. B. neu Label-Spalte statt altem Mechanismus). Lizenz-Upgrade veranlassen falls Purview Records benötigt und noch nicht vorhanden – E5 Compliance Trials ggf. anstoßen, Business Case einreichen.
– Sehr gut: Holistische Aufbewahrungsstrategie erneuern: Diese Abschaltung ist auch Chance, die Aufbewahrungsrichtlinien upzudaten und vereinheitlichen. Möglicherweise existierten parallele Welten – nun alles via Purview: Gelegenheit, Policies zu konsolidieren, unsinnige Regeln zu streichen, überall dieselben Retentionsfristen geltend zu machen. 30/60/90-Plan (siehe unten) sollte dieses Thema prominent haben. Einrichten eines “Records Management Board” falls noch nicht vorhanden, um neue Purview-basierte Prozesse (Disposition Reviews, Proof of Record etc.) zu steuern. Und natürlich: Backup-Plan überlegen – falls etwas nicht rechtzeitig migriert, wie gehen wir mit Lücke um (z. B. vorübergehend per Admin-Script Dateien schützen).

Risiken & Nebenwirkungen: Risiko Nummer eins: Zeitverzug/Migrationsfehler – Wenn man bis April nicht fertig wird, laufen alte Policies möglicherweise einfach aus bzw. funktionieren nicht mehr. Das kann bedeuten: Dokumente werden nicht gelöscht wie sie sollten (Compliance-Verstoß: hält Daten zu lang) oder schlimmer, es wird etwas gelöscht weil Purview was falsch auslegt (eher unwahrscheinlich; Purview löscht nicht ohne config). Daher absolute Priorität dem Thema geben! Ein weiteres Risiko: Kostenfalle – kleine Firmen, die bisher SharePoint Löschrichtlinien hatten (inkl. in E3), bräuchten Purview Records (E5) für identische Funktion (z. B. ‚declare record‘). Muss man intern argumentieren – oder man lebt ohne offizielle „Record“ (d.h. nur Aufbewahrung, ohne WORM-Schutz, falls das reicht). Für Endnutzer ist ein Risiko, dass man Kommunikation verpasst: Wenn plötzlich Knöpfe fehlen, fragen sie nach. Daher proaktiv informieren, um Vertrauen zu halten (“Das ist bewusst, neue Lösung im Hintergrund übernimmt – kein Datenverlust”). Technisch: Purview Retention hat paar Unterschiede – z. B. In-Place Records konnte einzelne List Items als Record, Purview kann das über Label pro Item (gut), aber eventuell fehlen trivial scheinende Features (z. B. Record Declaration reasons). Generell: Nebenwirkung ist mehr Abhängigkeit von Purview – aber das will Microsoft ja. Positiv: Reduziert Schatten-IT in Compliance. In Summe müssen Admins insbesondere Auditieren, dass Migration vollständig: Nichts schlimmer als z.B. ein regulatorisches Archiv war in SP Info Mgmt und man vergisst es nach Purview zu bringen – nach April werden die Jobs evtl. gestoppt und man läuft ins offene Messer bei Prüfung. Doch mit richtigem Plan sind Risiken handhabbar. Auch die neuen Purview-Features (Planner retention, last accessed) haben minimal Invasivität – Planner retention füllt Lücke (kein Risk, nur Gains). Last accessed retention künftiges Feature – etwas vorsicht: funktioniert erst ab dem genannten Preview, nicht vorwegnehmen. Fazit: Unbedingt Legacy-Exit ernstnehmen, auf Purview bauen, dann ist man für Zukunft gerüstet.

Quellen: Microsoft Message Center MC1211579, Learn-Migration Guidance

Compliance im Copilot-Kontext: Purview-Integration für sicheren KI-Einsatz

Was ist neu? Microsoft 365 Copilot erhält im Admin Center einen Security & Governance Bereich, der eng mit Purview verzahnt ist. Admins können nun auf der Copilot-Übersichtsseite im Microsoft 365 Admin Center (MAC) unter dem Tab „Security“ Einblicke sehen und Einstellungen vornehmen, die speziell den sicheren Einsatz von Copilot betreffen. Dazu gehören: Oversharing-Risiko-Übersicht (zeigt, ob Copilot vielleicht Inhalte aus sensiblen Quellen zieht), Hinweise zur Nutzung sensibler Daten in Copilot-Abfragen, sowie – ganz wichtig – die Möglichkeit, eine DLP-Richtlinie für Copilot zu aktivieren. Das heißt, man kann explizit festlegen, dass Copilot keine durch DLP geschützten Daten ausgeben darf (bzw. entsprechend handeln wie blockieren oder maskieren). Zudem gibt es dort empfohlene Compliance-Schritte, um KI-Einsatz konform zu gestalten (AI compliance checklist). Dieses Feature wurde im Januar 2026 ausgerollt, parallel zum Copilot GA für Enterprise.

Warum kommt das jetzt? Copilot war 2025 in Pilotphasen – 2026 beginnt die breite Nutzung. Viele Unternehmen zögerten aus Compliance-Bedenken (“Gibt Copilot vertrauliche Infos preis? Hält es Richtlinien ein?”). Microsoft adressiert diese Bedenken jetzt proaktiv: Ein KI-System darf kein Wildwest sein, sondern muss ins Compliance-Framework eingebettet werden. Purview ist die logische Wahl, um Datenschutz und Governance auch für KI-Ausgaben sicherzustellen. Zudem will Microsoft Vertrauen schaffen, damit Kunden Copilot lizenzieren – eine sichere Adoption durch Kontrollmöglichkeiten (“Copilot Readiness”) ist da verkaufsfördernd. Trends wie EU AI Act oder allgemein KI-Governance rücken an – MS zeigt, dass man Mechanismen bietet. Intern war sicher auch Feedback der Testkunden: “Wir brauchen oversight im Admin Center, um KI usage zu überwachen.” So bekommt der Admin nun ein Toolset an die Hand, inkl. Berichte und dem Copilot Readiness Report im Admin Center, um Lücken zu schließen. Kurz: Der Schritt ist nötig, um KI vom Spielzeug zum Enterprise-Tool zu machen, das mit denselben Compliance-Standards arbeitet wie der Rest.

Praxisbeispiel: Ein Unternehmen hat Microsoft 365 Copilot in Einsatz. Ein Benutzer fragt Copilot in Teams: “Summiere die Inhalte aller als Vertraulich markierten Dateien im Projekt X”. Ohne Reglement könnte Copilot theoretisch daraus sensitive Info generieren. Mit der neuen Integration hat der Admin jedoch im Copilot Security Tab die Policy „Copilot DLP Policy“ aktiviert und konfiguriert. Diese Policy greift ähnlich wie bei einem normalen DLP: Wenn eine Copilot-Abfrage Daten berührt, die gem. Purview DLP als z. B. personenbezogen klassifiziert sind, wird Copilot diese nicht im Klartext ausgeben – entweder warnt es oder maskiert die Antwort (je nach Policy). Im Admin Dashboard sieht der Admin außerdem, dass z. B. in letzter Woche 5 Copilot-Abfragen blockiert wurden wegen DLP (Oversharing Risk). Gleichzeitig werden ihm dort Empfehlungen angezeigt, z. B. “Aktiviere Sensitivity Labels mit Copilot-Sicht” oder “Schule Benutzer in sichere Nutzung”. Der Admin folgt den Vorschlägen (z. B. weist allen Top-Secret-Dokumenten ein Label zu, das Copilot ausschließt). Ergebnis: Copilot wird nur innerhalb definierter Grenzen agieren, Unternehmensdaten bleiben geschützt gemäß Compliance. Ohne diese Integration hätte man quasi Copilot separat managen müssen – nun ist es Teil der Governance wie jeder andere Service.

Auswirkung für Anwender: Für Endnutzer bedeutet dies, dass Copilot ein paar mehr Regeln befolgt. Sie könnten feststellen, dass Copilot auf bestimmte Fragen antwortet: “Sorry, kann ich nicht helfen, die Infos sind vertraulich.” Anfangs mag das frustrierend sein, aber es verhindert Datenlecks. Im Optimalfall hat der Nutzer davon proaktiv nichts gemerkt, außer dass Copilot “vernünftig” agiert. Möglicherweise werden Nutzer durch IT informiert: “Copilot ist jetzt datenschutzkonform eingestellt; bitte wundern Sie sich nicht, wenn er gewisse Inhalte nicht preisgibt.” Insgesamt steigert es das Vertrauen der Nutzer in Copilot, weil es zeigt, dass Sicherheitsregeln eingehalten werden (gerade für skeptische Mitarbeiter wichtig). Ein Nebeneffekt: Die Copilot Readiness Reports im Admin Center werden eventuell auch mit dem Business geteilt (“Schaut, wir haben KI usage im Griff”). Anwender selbst spüren davon primär, dass Copilot weniger Risiko eingeht – was tendenziell gut ist. Ein aufgeklärter Nutzer wird verstehen, dass “KI halluziniert keine Geheimnisse, wir haben Schranken drin”. In manchen Fällen kann es aber auch zu mehr Authentifizierungsfragen kommen (“Du versuchst etwas aus HR-Daten zu ziehen, bestätige erst Berechtigung”), aber das müsste noch kommen.

Auswirkung für Admins: Admins (v.a. M365-Admins und Compliance-Admins) erhalten einen zentralen Ort, um Copilot Governance zu steuern. Das erspart potenziell separate Tools oder blindes Vertrauen. Konkrete Aufgaben: Als erstes im MAC unter Copilot Overview den Readiness-Report checken – dort werden evtl. Lücken aufgedeckt (z. B. “Kein DLP für Copilot definiert” oder “XYZ Setting fehlt”). Admin folgt den geführten Aktionen – so erreicht er “Copilot ready” Status. Dann im Security Tab die Übersichtsmetriken verstehen: Oversharing Risk etc. Hier ggf. definieren, welche Kennzahlen man dauerhaft tracken will (vielleicht als KPI: “0 Copilot data leaks”). Hauptarbeit: Copilot-spezifische DLP Policy anlegen – Microsoft wird wahrscheinlich eine vordefinierte Regel anbieten, die man modifizieren kann. Diese gilt es auf die firmenspezifischen SITs/Sensitivity-Labels einzustellen (z. B. “Wenn Daten mit Label Geheim angefordert, block antwort”). Admin muss auch klären: Welche Personen/Gruppen sollen evtl. gar kein Copilot nutzen, bis Compliance ready? Im Dashboard kann man Copilot Usage nach lizenziert/unlizenziert sehen und Agents etc. (neue Reports). Das hilft Admin, Zugriffskontrollen zu planen (z. B. bestimmten Abteilungen Copilot erst geben, wenn deren Datenklassifizierung up-to-date). Admins werden auch das Reporting an ihre Security/Compliance-Kollegen neu abstimmen: Möglicherweise regelmäßig Info, wie viele pot. Versuche Copilot geblockt hat. Lizenz: Nur verfügbar falls Copilot lizenziert, aber die Purview-Seite erfordert E5 Compliance für DLP an sich. Admins sollten sicherstellen, dass Purview-Funktionen da sind. In Summe bedeutet es etwas mehr Konfigurationsarbeit in Setup-Phase, aber hinterher weniger unbekanntes Risiko – Admin hat Copilot “an der Leine”. Auch gut: Admins können ab Jan 2026 belegen, dass KI-Einführung kontrolliert läuft – wichtig ggü. Vorstand / Revision.

Was müssen wir tun?
– Minimum: Copilot Admin Center besuchen: Im MAC unter Copilot den Security-Tab prüfen. Falls Copilot schon aktiviert: dort DLP for Copilot einschalten und mit existierenden DLP-Policies verknüpfen oder neue erstellen, die speziell für KI gelten (Testrun machen mit sensiblen Prompt).
– Besser: Copilot Readiness Plan abschließen: Den Readiness-Report nutzen, um alle empfohlenen Security-Einstellungen umzusetzen – z. B. Sensitivity Labels definieren falls bisher versäumt, Audit Logging an, richtige RBAC für Copilot Admin etc. Dann Policies fine-tunen: Welche Daten darf Copilot nie ausgeben? (In DLP festlegen). Abnahmen mit Datenschutzbeauftragtem/Compliance Officer einholen, damit KI-Einsatz konform dokumentiert ist.
– Sehr gut: Monitoring und KPIs etablieren: in den ersten 30 Tagen nach Aktivierung wöchentlich die Copilot Security Dashboard Stats auswerten – ermitteln, ob z. B. viele Versuche unberechtigt stattfinden (schult Nutzer anhand der Insights). Langfristig Kennzahlen definieren wie “Anzahl blockierter KI-Antworten” als Indikator, ob Policies nachgeschärft werden müssen. Notfallprozess definieren für den Fall, dass Copilot doch mal etwas Unzulässiges ausgibt – z. B. sofort melden an MS Support und interner IR-Prozess. Außerdem: Zusammenarbeit mit Purview-Team – sicherstellen, dass neue Sensitivity Labels oder DLP-Änderungen auch immer Copilot berücksichtigt wird (z. B. falls neue SIT für geistiges Eigentum eingeführt, direkt in Copilot-DLP policy aufnehmen).

Risiken & Nebenwirkungen: Ein mögliches Risiko ist Überblocken: Wenn die DLP-Policy zu strikt ist, könnte Copilot viele legitime Anfragen ablehnen, was Nutzer frustriert und ggf. die Copilot-Akzeptanz mindert. Hier muss man das Gleichgewicht finden – eventuell gestufte Policies (Audit vs Block). Ein anderes Risiko: Scheinsicherheit – Admins könnten sich in falscher Sicherheit wiegen (“Wir haben DLP an, passt schon”), obwohl DLP nicht jeden KI-Output bewerten kann. Manche Info kann als nicht sensibel klassifiziert sein, aber im Kontext brisant wirken. Daher trotz Tools weiter menschliches Monitoring. Nebenwirkung: Mehr Aufgaben für Compliance-Team, da KI nun Teil ihres Zuständigkeitsbereichs wird – aber das ist unvermeidlich, und wenigstens hat man Tools. Technisch: Die Integration ist neu; Kinderkrankheiten möglich. Etwa Reporting-Bugs oder anfangs begrenzte Metriken. Admins sollten Feedback an MS geben. Auch sollte man aufpassen: Nicht alles lässt sich DLP-regeln – z. B. Copilot könnte aus öffentlich zugänglichen Infos was generieren, was trotzdem intern heikel ist. Dafür gibts (noch) keine Policy – Risk of the unknown. Rechtlich: Firmen sollten die Nutzungsrichtlinie für Copilot anpassen – aber das ist unabhängig von Tools. Fazit: Diese Neuerung ist ein großer Schritt, KI beherrschbar zu machen. Mit umsichtigem Einsatz der Policies und Berichte lassen sich die Risiken minimieren. Der größte Fail wäre, es nicht zu nutzen – dann würde Copilot unkontrolliert bleiben. So hat man wenigstens die Zügel in der Hand und kann laufend nachjustieren.

Quellen: Microsoft TechCommunity (What’s New in M365 Copilot Jan 2026)

Governance & Betrieb: Purview Service Health Dashboard & Reporting

Was ist neu? Im Microsoft Purview Compliance Portal gibt es jetzt ein integriertes Service Health Dashboard. Dort werden Störungen, Wartungen und Advisories angezeigt, die Purview-Services betreffen – kombiniert sowohl für Purview-spezifische Dienste als auch relevante Microsoft 365 und Azure Services. Bisher mussten Admins für solche Infos das Microsoft 365 Service Health im Admin Center bemühen oder E-Mails. Nun ist es direkt im Purview-Portal zentral einsehbar. Außerdem neu: Diverse Reports und Usage-Analytics-Verbesserungen: z. B. ein Agents Usage Report im M365 Admin Center (für Copilot Agents) und Pay-as-you-go Dashboards für Backup/Copilot (im Azure Portal) – aber fokussieren wir auf Purview-spezifische. Das Purview Health Dashboard (Roadmap 497944) kam im März 2026 GA.

Warum kommt das jetzt? Mit immer mehr Purview-Diensten (DLP, eDiscovery, InfoProtection etc.) ist es wichtig, deren Betriebszustand im Blick zu haben. Admins hatten den Wunsch nach einer einheitlichen Übersicht: Statt in drei Portalen zu suchen, direkt in Purview sehen, ob z. B. das eDiscovery-Tool gerade eine bekannte Störung hat. Microsoft reagiert darauf – sicherlich auch, weil in kritischen Fällen (z. B. Audit-Log war mal gestört) Kunden monierten, sie hätten es früher wissen müssen. Zudem strebt man generell nach transparenterem Service Monitoring. Das Dashboard trägt zur Operationalisierung bei: Compliance-Teams können innerhalb ihres Tools alles prüfen, ohne Ticket an Helpdesk. Und nicht zuletzt entlastet es den Support, wenn Kunden schnell sehen “Ah, da ist schon ein Advisory, muss kein eigenes Ticket öffnen”. Im Zuge der Professionalisierung von Purview als Suite war das der nächste logische Schritt. Außerdem im Admin Center Reports-Bereich kommen immer mehr Feinreports (Agents usage etc.), da MS verstanden hat: Kunden wollen Nutzung messen, ROI sehen. Speziell Purview-Health war aber lange überfällig – gut, dass es jetzt da ist.

Praxisbeispiel: Ein Compliance-Admin startet morgens ins eDiscovery-Projekt, aber die Suchabfragen im Purview-Portal schlagen fehl. Früher hätte er vielleicht stundenlang vermutet, seine Query ist schuld. Jetzt öffnet er das Purview Health Dashboard im Portal und sieht sofort: “Advisory: eDiscovery Search Performance Issues – Under Investigation” seit 7:30 Uhr, mit Updates von Microsoft. Er informiert das interne Legal-Team, dass aktuell eine Störung vorliegt und man später erneut versucht. Das spart allen Zeit und Nerven. Ebenso sieht er evtl. auf einen Blick, dass z. B. ein Azure AD Problem vorliegt, das Purview-Berechtigungen tangieren könnte – steht alles im selben Dashboard. So kann er auch gegenüber Management belegen, dass ein Problem extern ist und in Bearbeitung, statt in Panik Troubleshooting zu betreiben. Dieses Beispiel zeigt, wie das Health Dashboard Transparenz und Effizienz steigert.

Auswirkung für Anwender: Endanwender haben indirekt Nutzen: Wenn z. B. DLP gerade eine Störung hat (sagen wir Policy Tips werden nicht angezeigt), sehen nur Admins die Info. Aber diese können dann proaktiv die Support-Teams informieren oder Workarounds kommunizieren (“Zurzeit werden Policy Tips verzögert, bitte manuell aufpassen”). Das heißt, Störungen treffen die Anwender weniger überraschend, weil Admins informiert sind und reagieren. Insofern besserer Service für Endnutzer. Aber direkt bemerken tun es nur Admins. Schlimmstenfalls würde ein Anwender gar nicht merken, dass Auditing down war – gut, dass Admin es aber weiß und vorsorglich ggf. interne Policies (z. B. “Momentan kann es Lücken in Log-Daten geben”) anpasst. Also Vorteil eher indirekt.

Auswirkung für Admins: Für Admins (bes. Compliance-Admins) ist es eine Erleichterung im Alltag. Jetzt gehört es zum Morgen-Check, einmal ins Health Dashboard zu schauen, ob alles grün ist. Das spart potenziell viel Troubleshooting-Zeit. Admins sollten sich gleich Alerts/Notifications einrichten, sofern möglich – eventuell kann man das Dashboard auch per API auslesen und intern per Teams melden lassen, wenn Status rot. In der Praxis wird das bedeuten: Weniger Abhängigkeit vom globalen Tenant-Admin (früher hatten nur globale Admins vollen Service Health Zugriff; jetzt im Purview-Portal dürften auch Compliance-Role-Admins die relevanten sehen dürfen). Admins können so autarker arbeiten. Zudem ermöglicht es RCA (Root Cause Analysis) im Nachhinein: wenn jemand fragt “Warum hat eDiscovery letzten Mittwoch gehangen?” – Admin öffnet Dashboard History und sieht, es gab eine Advisory. So hat er Fakten. Es ist wichtig, dass Purview-Team und Operations/Helpdesk die Info auch austauschen: Das Health Dashboard sollte in den NOC/SOC-Prozess integriert werden. Admins erhalten sozusagen eine Single Pane of Glass für Compliance-Betrieb. Auch der Agents Usage Report (neuer Bericht) kann Admins interessieren, aber eher Copilot Admin. Purview-spezifisch sei noch erwähnt: Q1 sah ggf. Launch von Backup & Archive Reports und so. Generell: Admins sollten das Dashboard wohlwollend aufnehmen und können an Microsoft Feedback geben, wenn z. B. noch Infos fehlen (aktuell deckt es Purview, M365 und Azure Combined – was super ist). Eventuell benötigt man noch Berechtigungsprüfungen: Wer im Purview-Portal darf es sehen? Vermutlich Compliance Admins etc. Das muss intern kommuniziert werden, falls z. B. nur Tenant Admin bisher Service Health sah, nun aber auch Compliance Officers auf dem Laufenden sind. Das ist eigentlich gut (keine Bottlenecks). In Summe erhöht es Professionalität und Vertrauen (Admin muss dem MS Service Health nicht nebenbei auf second screen folgen; es ist in seinem Workflow drin).

Was müssen wir tun?
– Minimum: Purview-Portal updaten (falls Bookmarks): Das Health Dashboard ist neu im Menü (vermutlich unter “Health” oder ähnlich). Admins sollten es regelmäßig prüfen und ihr Team darauf hinweisen, es zu nutzen statt direkt Panik zu schieben bei Problemen.
– Besser: Integrations & Alerts: Schauen, ob das Dashboard Benachrichtigungsfunktionen hat (z. B. MS 365 admin mobile App push?). Ggf. Script/Graph API basteln, das die Health Status polled und ins Monitoring einspeist. Team-übergreifend bekannt machen, dass es das gibt – damit z. B. der Helpdesk bei Incidents erst dort nachschaut (“Ist ein bekanntes Problem?”).
– Sehr gut: Operative Prozesse anpassen: Den existence des Purview Health Boards im Incident Response Plan aufnehmen (“Step1: check Purview health for known issues”). Schulung für On-Call Engineers und Compliance-Team, was die verschiedenen Status bedeuten und wo man Details findet (oft sind ja Links auf Issue ID). Zusätzlich kann man archivieren, wann es Störungen gab, um ggf. SLA-Auswirkungen mit Microsoft zu diskutieren. Und man sollte sicherstellen, dass Compliance Admins ausreichende Rechte haben, um das Board zu sehen – falls es an irgendwelchen RBAC hängt, notfalls Rights erweitern.

Risiken & Nebenwirkungen: Kaum Risiken – eher nur, falls Admins sich zu sehr darauf verlassen. In seltenen Fällen kann es sein, dass ein Problem noch nicht im Dashboard steht (z. B. ganz frisch, MS hat noch nicht gepostet). Also sollte man weiterhin kritische Augen offen halten – aber das gilt immer. Nebenwirkung: Mehr Transparenz kann auch Alarmismus schüren – z. B. wenn Permanent „Advisory: Minor Performance“ drin steht, könnte ein Admin nerveus werden obwohl es ihn kaum betrifft. Man muss also lernen, die Infos richtig zu interpretieren. Ein mögliches Problem: Zugriffsberechtigung – wenn das Dashboard an Tenant Admin Rechte hängt und normale Compliance Admins es doch nicht sehen könnten, wäre das hinderlich. Aber Roadmap spricht von Purview Portal, also vermutlich greift Purview RBAC. Ansonsten wenig: es ist read-only Info. Performance oder Security Impact hat es nicht, außer dass es Verschwörungstheoretiker in der Firma eventuell beunruhigt „da sind so viele Meldungen“ – aber intern. Nein, es sind fast nur Vorteile. Insgesamt unterstreicht es den Trend: Compliance ist ein kontinuierlicher Betriebsprozess (run), nicht einmal einrichten und fertig. Mit dem Health Dashboard und robusten Reports hat man die Mittel, Purview genauso zu betreiben wie Exchange oder SharePoint – professionell mit Monitoring. Das minimiert Ausfallzeiten und Überraschungen, was ultimativ Compliance verlässlich macht.

Quellen: Microsoft 365 Roadmap ID 497944, Planet Blog (Roadmap Updates)

Nach diesen detaillierten Neuerungen schauen wir nun, welche Lizenzen erforderlich sind und wie Sie die Einführung all dieser Funktionen strukturiert angehen können.

Lizenz- und Voraussetzungen-Check

Ein Großteil der beschriebenen Funktionen setzt Microsoft 365 E5 Compliance oder entsprechende Add-Ons voraus – prüfen Sie daher unbedingt Ihre Lizenzsituation:

• Microsoft Purview DLP: Grundlegende DLP (E-Mails, SharePoint, OneDrive, Teams-Chats) ist ab Office 365/M365 E3 enthalten. Endpoint DLP (Windows, Mac), sowie erweiterte DLP-Features wie „Wait on Send“ erfordern E5 Compliance bzw. das Purview Data Risk Add-On. „DLP für Copilot“ ist neu – hier benötigt man DLP (also E3/E5 wie gehabt) und natürlich eine Copilot-Lizenz für den User.
• Sensitivity Labels / Information Protection: Die Erstellung und manuelle Anwendung von Sensitivity Labels (inkl. Verschlüsselung) ist bereits in E3/Office 365 E3 (AIP P1) enthalten. Automatisches Labeling, OCR in Scanner, etc. braucht E5 (AIP P2). Das neue Label-Group-Feature kommt für alle, die Labels nutzen – kein spezieller Lizenzimpact. Double Key Encryption falls genutzt ist Add-On. Faustregel: Für volle Label-Power inkl. Auto und Schematags = E5.
• Records Management / Retention: Aufbewahrungsrichtlinien und -labels zur einfachen Retention/Löschung sind in E3 verfügbar (Purview Data Lifecycle Mgmt). Records Management (erklärte Records mit Immuntät gegen Löschen, Dispositionsprüfung, Proof of Disposal) ist E5 Compliance vorbehalten. Nach Abschaltung der Legacy-SP-Features muss man ggf. E5-Lizenzen einplanen, wenn man bisher kostenlose In-Place Records nutzte. Für viele wird aber die E3-Retention genügen, wenn “Records” formal nicht benötigt.
• Audit / Advanced Audit: Audit Standard (90 Tage Log-Aufbewahrung, Basisevents) ist in allen Plänen ab E3 inklusive. Advanced Audit (365 Tage Aufbewahrung und spez. Events wie MailItemsAccessed) ist E5. (Standard-Aufbewahrung wurde zwar auf 180 Tage verlängert, aber das geschah bereits 2023, sollten Sie inzwischen haben). Für in Q1 neuere Audit-Features gab es kaum Lizenzänderungen – Copilot-Interaktionen Logging ist vermutlich E5, aber hier nicht 100% klar; im Zweifel E5.
• eDiscovery: eDiscovery (Standard) ist Teil von E3 (ermöglicht Content Search, Holds, Export). eDiscovery (Premium) inkl. Tiefenanalyse, Reviewer-Plattform etc. erfordert E5 (früher eDiscovery G). In Q1 neu z. B. Advanced Review Algorithmen – die werden nur in Premium sein.
• Insider Risk Management & Comm. Compliance: Beide sind E5 Compliance Funktionen (nicht in E3 enthalten). Für OCR, Analytics etc. brauchen Sie also E5-Lizenzen für die Nutzer, die Sie überwachen möchten. Kommunikation Compliance oft auch nur für E5/User mit E5-Compliance AddOn. (Priva ebenfalls separat lizenzierbar, E5 oder Priva add-on).
• Microsoft 365 Copilot Compliance: Hier gibt es zwei Aspekte: Sie brauchen die Copilot-Lizenz (kostenpflichtig pro User) sowie die zugehörigen Compliance-Fundamente. DLP für Copilot erfordert, dass Sie sowieso Purview DLP lizenziert haben (also E3/E5 wie oben). Das Copilot Admin Dashboard selbst ist Teil der Copilot-Service, also kein extra. Aber z. B. Copilot Audit-Logs (wer hat was gefragt etc.) sind wahrscheinlich nur bei E5 Audit vollständig. Copilot’s Wirkung hängt an Ihren Purview Policies – wenn Sie E5 haben, ideal, ansonsten nutzen Sie was geht (E3 DLP etc.). Microsoft hat in Q1 eine Promo gefahren: 50% Rabatt auf Purview Suite für Kunden mit Copilot-Lizenzen – ein Indiz, dass E5 Compliance empfohlen ist im KI-Zeitalter.

Voraussetzungen allgemein: Stellen Sie sicher, dass entsprechende Dienste aktiviert sind: z. B. für DLP Endpoint auf Mac muss der Defender for Endpoint Client laufen und Sensoren aktiviert sein; für Insider Risk Analytics müssen Telemetry & Data Sharing aktiviert sein. Viele Preview-Features (Adaptive Scope, Retention nach Zugriff) erfordern ggf. Targeted Release oder Powershell-Enablement – checken Sie die Doku und aktivieren Sie diese nur in Absprache/testweise.

RBAC & Rollenmodell: Überprüfen Sie Ihr Purview Rollenmodell. Mit neuen Tools wie dem Purview Health Dashboard oder Copilot-Compliance-Controls könnten Berechtigungen erforderlich sein. Gewähren Sie dem Compliance-Team die notwendigen Rollen (z. B. Compliance Administrator, Insider Risk Management Admin, Records Management, eDiscovery Manager etc.), damit es eigenständig arbeiten kann. Und entziehen Sie legacy Admin Centers die Rollen, die weggefallen sind (z. B. klassische SPO Compliance Admin – alles Purview jetzt). Rollenupdates Q1: z. B. könnte es neue Copilot Service Admin Rollen geben; im Zweifel dem Global Admin vorbehalten oder gezielt delegieren.

Client-Updates: Viele Funktionen verlangen aktuelle Clients: Sensitivity Labels SaveAs fix erfordert Office-Versionen v16.0.16216+ (Win) / 16.103 (Mac), Outlook “Wait on Send” nur im New Outlook Client (Schulung der User + rollout dieses Clients). Planen Sie also Deployments der benötigten Softwareversionen im Voraus ein. Für Mobilgeräte analog (wie erwähnt iOS Outlook 2.103+ für Label Perm Fix).

Zusammenfassung: Um Q1-Features voll zu nutzen, ist E5 Compliance quasi der Standard – speziell für Insider Risk, Comm Compliance, Records, Premium eDiscovery etc. Wenn Sie nur E3 haben, können Sie dennoch profitieren (z. B. DLP Outlook Mac Tips erhalten Sie, Retention Planner teils nutzbar), aber die richtig spannenden Sachen (OCR, Analytics, Purview Suite) sind E5-Domäne. Überlegen Sie gegebenenfalls, Lizenz-Addons zu erwerben oder Tests mit E5 Trial durchzuführen, um den Mehrwert zu demonstrieren. Und passen Sie Ihre technische Umgebung (Clients, Agents, Settings) an, damit Sie zum Rollout der Funktionen nicht ausgebremst werden.

(Lizenzierungsfragen sind komplex – im Zweifel konsultieren Sie Ihren Microsoft-Partner. Nutzen Sie ggf. Promotions: Microsoft hat z. B. E5 Compliance Trials oder Rabatte kombiniert mit Copilot im Angebot gehabt in diesem Quartal.)

30/60/90-Tage-Aktionsplan

Die Fülle an Neuerungen schreit nach einem geordneten Umsetzungsplan. Hier ein Vorschlag für die nächsten 90 Tage, um die wichtigsten Punkte in die Praxis zu überführen:

In den nächsten 30 Tagen (Monat 1): “Bestandsaufnahme & Quick Wins”

• 🔍 Analyse & Priorisierung: Überprüfen Sie alle oben genannten Bereiche in Ihrem Tenant. Welche der Neuerungen treffen auf Ihre Umgebung zu? (z. B. nutzen Sie Insider Risk bereits? Haben Sie Copilot lizenziert? Gibt es Legacy-SP-Compliance im Einsatz?). Priorisieren Sie nach Risiko: z. B. Legacy-Records Migration = sehr dringend, Mac DLP Erweiterung = mittelfristig nutzen.
• 👥 Team-Briefing: Versammeln Sie Ihr Compliance-, Security- und M365-Admin-Team. Stellen Sie die Neuerungen vor (gern mit Auszügen dieses Artikels 😉) und verteilen Sie Verantwortung. Etablieren Sie ggf. eine kleine Task Force für Copilot-Compliance und eine für die SharePoint-Compliance-Migration.
• 📜 Legacy-Abkündigungen angehen: Wenn Sie die SharePoint-Features (Information Management Policies, In-Place Records etc.) nutzen: Sofort Migrationsplan entwerfen. Alle betroffenen Sites/Librarys identifizieren, Purview-Äquivalente definieren. Kick-off für Umsetzung starten (ggf. Testmigration in einer Site).
• 🔐 DLP & Labels Quick Wins: Aktivieren Sie „Outlook Wait on Send“ für eine Testgruppe (z. B. IT und Compliance Team), um Erfahrung zu sammeln. Rollen Sie den Outlook für Mac Update zügig aus, damit Policy Tips überall ankommen. Weisen Sie Mac-User auf das Update hin.
• 💻 Endpoint DLP & OCR: Prüfen Sie Mac-Geräte: Sind alle im Defender Portal onboarded? Falls nein, jetzt nachholen, damit die erweiterte File-Typ und OCR-Fähigkeit zum Tragen kommt. Machen Sie einen Test auf Mac: Legen Sie eine neu unterstützte Datei (z. B. .zip mit sensiblen Inhalt) auf USB und vergewissern Sie sich, dass DLP anschlägt.
• ⚙️ Copilot Security Setup (falls Copilot vorhanden): Navigieren Sie im M365 Admin Center zum Copilot-Bereich. Arbeiten Sie den Readiness-Report durch: Aktivieren Sie fehlende Settings, insbesondere Purview DLP for Copilot. Richten Sie eine Basis-DLP-Regel ein (“Blocke offensichtliche sensible Daten via Copilot”). Kommunizieren Sie dem Pilotanwenderkreis, dass Copilot nun mit Sicherheitsnetz aktiv ist.
• 📈 Purview Health Dashboard integrieren: Fügen Sie das neue Health Dashboard zu Ihren täglichen Admin-Checks hinzu. Informieren Sie Ihr Operations Center/Helpdesk, dass Compliance-Probleme nun dort ersichtlich sind – erster Ansprechpartner bei Compliance-Incident ist ab jetzt dieses Dashboard. Vielleicht einen an der Wand hängenden Bildschirm konfigurieren, der Purview Health anzeigt (für die Nerds 😉).
• 📚 Dokumentation und Policies aktualisieren (Teil 1): Beginnen Sie damit, interne Richtlinien und Benutzerhandbücher zu aktualisieren: Wegfall “Declare Record” in SP, neue “Retention Label”-Prozesse, Info an Mitarbeiter, dass KI (Copilot) regelbasiert eingeschränkt sein kann etc. In 30 Tagen noch nicht alles fertig, aber Start.

(Minimalziel nach 30 Tagen: Sie haben die kritischsten Änderungen angestoßen – keine Altlast ohne Plan, die wichtigsten neuen Schutzmechanismen aktiv (Wait on Send testweise an, DLP auf Mac wirksam), und alle Beteiligten wissen, was kommt.)

Innerhalb von 60 Tagen (Monat 2): “Implementierung & Rollout”

• 🚀 Rollout neuer Policies & Features: Basierend auf den Tests im ersten Monat, weiten Sie Wait on Send auf alle relevanten Outlook-Nutzer aus, mit einem sinnvollen Timeout (z. B. 30 Sek.). Stellen Sie Adaptive DLP Scopes produktiv für erste Anwendungsfälle ein (z. B. alle Projekt-Sites mit Name “Vertraulich” schützen). Nutzen Sie dafür Prod-Daten und monitoren Sie Wirkung.
• 🔄 Migration abschließen: Finalisieren Sie die SharePoint Legacy -> Purview Migration. Spätestens jetzt sollten alle In-Place Records durch Purview Records Labels ersetzt sein und Information Management Policies via Purview Retention laufen. Testen Sie die Wirksamkeit (z. B. ein Dokument mit neuem Label wirklich unlöschbar? Wird eine Datei nach 5 Jahren in Test-Site gelöscht?). Deaktivieren Sie die alten Policies, um Doppelwirkung zu vermeiden. Halten Sie die Dokumentation bereit, falls User Nachfragen haben.
• 🛡️ Insider Risk & Comms Compliance Feintuning: Falls Sie IRM/CommComp im Einsatz haben: Überprüfen Sie die Policies und nutzen Sie die neuen Limits. Passen Sie z. B. Varianten an (mehr Stufen) und fügen Sie ggfls. zusätzliche Nutzer in Detection Groups hinzu (nun da Limit 500). Schauen Sie in CommCompliance Policies, ob die neuen Alert-Einstellungen sinnvoll geändert werden sollen (wahrscheinlich ja): Richten Sie wöchentliche Summaries ein und tragen Sie mehrere Empfänger ein. Kommunizieren Sie dem Review-Team, dass sich der Alert-Rhythmus geändert hat.
• 📊 Analytics & Reporting nutzen: Aktivieren Sie Insider Risk Analytics (sofern nicht schon) und führen Sie erste Auswertungen durch. Zeigen Sie dem Security Committee erste Beispielfälle aus dem User Analytics Dashboard (natürlich pseudonym). Das erhöht das Verständnis und die Unterstützung fürs Programm. Nutzen Sie Advanced eDiscovery falls vorhanden, um den Efficient Review (Ankündigung Q1) im Blick zu behalten – vielleicht als Preview im Lab ausprobieren, um im Juni vorbereitet zu sein.
• 💬 Benutzer-Schulung & Awareness: Mitte der 90 Tage-Spanne sollte ein firmenweites Kommunikationspaket geschnürt werden:
• Informieren Sie über die neuen Outlook-DLP-Funktionen (“Outlook verzögert Versand, das ist normal – schützt Euch und die Firma!”).
• Erinnern Sie an die Sensitivity Labels (dass es neue Label-Gruppen gibt, müssen Enduser kaum wissen, aber dass sie durchgängig Labels nutzen sollen, schon). Vielleicht lancieren Sie eine kleine Kampagne “Klassifizieren statt blamieren!” mit Humor.
• Bei eingeführtem Copilot: Schulen Sie die Nutzer in sicherer Copilot-Nutzung. Erklären Sie, dass Copilot z. B. bestimmte Daten nicht liefern wird (und soll) – geben Sie Beispiele, was erlaubt ist zu fragen und was nicht. Machen Sie klar, dass alle Copilot-Interaktionen geloggt sind gemäß Policies.
• Privacy/Legal: Stellen Sie dem Betriebsrat/DPO die vorgenommenen Kontrollmaßnahmen (IR-Analytics, Comms Compliance Alerts, Copilot DLP) transparent dar, um Vertrauen zu wahren und Compliance auch mit Mitbestimmungsvorgaben zu halten.
• 👩‍💻 Externe Unterstützung einbeziehen: Falls Sie merken, dass bestimmte Migrationen oder Konfigurationen sehr aufwändig sind, ziehen Sie im 60-Tage-Fenster ggf. externe Berater hinzu. Viele Dienstleister bieten Short-Term Engagements, z. B. um DLP-Policies zu optimieren oder die IRM-Implementierung zu prüfen. (Zwei Monate vor Ablauf der Frist – jetzt lohnt es noch, externe Hilfe reinzuholen, falls interne Ressourcen knapp sind.)
• 📚 Dokumentation (Teil 2) & Prozesse: Finalisieren Sie Ihre internen Dokumente: neue Richtlinien, geänderte Arbeitsanweisungen (z. B. “wie deklariere ich jetzt einen Record? –> via Label XY”). Überarbeiten Sie Incident-Response-Playbooks: z. B. fügen Sie im Data Breach Playbook einen Step hinzu “prüfe IRM Analytics auf ähnliche Aktivitäten des Users in letzter Zeit”. Im Comms Compliance Prozess definieren Sie Auswertezyklen anhand der neuen gebündelten Alerts.

(Ziel nach 60 Tagen: Die meisten neuen Funktionen sind produktiv im Einsatz oder zumindest konfiguriert, und Altsysteme wurden ersetzt. Benutzer sind informiert, Admins haben ihre Routine angepasst. Sie haben eventuelle externe Hilfe genutzt, um knifflige Stellen zu bewältigen. Ihre Compliance-Maschine läuft weiter ohne zu stottern, trotz vieler Neuerungen.)

Innerhalb von 90 Tagen (Monat 3): “Nachkontrolle & Optimierung”

• ✅ Review & Audit: Gehen Sie alle eingeführten Änderungen einmal im Rahmen eines internen Audits durch:
• Wurden alle Legacy-Funktionen tatsächlich abgeschaltet? (Überprüfen Sie mit Testuser, ob z. B. der alte “Declare Record”-Button weg ist – positiv sein sollte).
• Sind die neuen DLP/IRM/Compliance Policies wirksam? (Checken Sie Berichte: Sind Wait-on-Send Overrides protokolliert und im erwartbaren Rahmen? Wie viele Comm Compliance Alerts kommen jetzt wöchentlich rein – manageable? Erzeugen IRM’s neue Varianten sinnvolle Differenzierung oder müssen Schwellen nachjustiert werden?)
• Ziehen Sie ein paar Stichproben z. B. in eDiscovery, um zu sehen, ob Audit-Logs erwartungsgemäß da sind (gerade, wenn Standard vs. Advanced Audit – 180 vs 365 Tage – im Blick).
• Nutzen Sie Benutzerfeedback: Fragen Sie z. B. das Legal-Team, ob sie Verbesserungen bemerken in eDiscovery; fragen Sie Vorgesetzte, ob sie weniger irrelevante Comms Compliance Meldungen erhalten jetzt.
• 📈 KPI-Tracking etablieren: Nach 3 Monaten sollten Sie konkrete Daten haben, um KPIs zu definieren und baseline zu setzen. Mögliche Kennzahlen:
• Anzahl der DLP-Vorfälle pro Monat (vorher/nachher mit Mac/WaitOnSend – erwarten Sie evtl. Anstieg gemeldeter, aber evtl. Rückgang tatsächlicher Exfiltration).
• Durchschnittliche Zeit zur Fallauflösung in Insider Risk (hoffentlich sinkend durch Analytics).
• Benutzerakzeptanz: Umfragen zur Zufriedenheit mit Copilot – fühlen sie sich sicherer, weil Policies greifen, oder eher genervt?
• Compliance-Score (Microsoft Compliance Manager Score) – dieser könnte gestiegen sein, wenn Sie Empfehlungen (Copilot readiness, DLP etc.) umgesetzt haben. Überwachen Sie diese KPIs künftig monatlich; 90 Tage ist ein guter Startpunkt, Trends zu identifizieren.
• 📝 Weitere Verbesserungen einplanen: Identifizieren Sie Bereiche, die in Q1-Neuerungen nicht abgedeckt waren, aber Handlungsbedarf haben. Q1 war vollgepackt, aber es kommen immer neue Dinge: Z. B. halten Sie Ausschau nach Q2 2026 Features (vielleicht refinements in Priva oder automatisierte classification). Besser früh antizipieren und Kapazität freihalten.
• Vielleicht sehen Sie nach dem Review: “Okay, Mac DLP läuft jetzt gut, aber unsere Linux-Clients sind ein Gap” – das wäre ein ToDo (auch wenn MS da noch nix hat, Workarounds oder Policies).
• Oder: “Wir haben jetzt toll Comm Compliance Alerts getweakt, aber noch keine Training/Remediation für Täter implementiert” – planen Sie Follow-up Projekt z. B. mit Viva Engage oder Schulungen, um Compliance-Kultur zu stärken.
• 🤝 Erfahrungswerte teilen: Nach drei Monaten können Sie interne Best Practices formulieren. Teilen Sie diese im Unternehmen (z. B. in einem Lunch & Learn mit allen IT-Beteiligten: “Was hat geklappt, was weniger?”). Und gern auch extern – etwa auf Tech Communities oder in beruflichen Netzwerken im DACH-Raum, um von Ihren Purview-Erfahrungen zu berichten. (Nebeneffekt: Ihr Unternehmen positioniert sich als Vorreiter in Compliance.)
• 🚀 Weiterführende Projekte initiieren: Nun, da das Fundament gelegt ist, können Sie größere Vorhaben angehen, z. B. Retention nach “Last Accessed” implementieren, sobald Preview/GA in Q2 kommt (Sie haben ja initiales Interesse identifiziert). Oder Teams Data Archive/Backup Strategien auf Purview/Backup Preview aufbauen. Q1 hat viele Türen geöffnet – nutzen Sie das Momentum, um Ihr Compliance-Programm ganzheitlich weiterzubringen (Stichwort: Privacy und Priva – Q1 war hier ruhig, vielleicht Gelegenheit, das in Q2 aufzubauen).
• 🔒 Fazit-Review mit Management: Nach 3 Monaten berichten Sie idealerweise ans Top-Management: Was haben die Neuerungen gebracht? Betonen Sie erhöhte Sicherheit (z. B. “0 vertrauliche Mails gingen ungefiltert raus dank Wait on Send”), Compliance-Risiken reduziert (Legacy abgelöst, auditfest), und wo noch Risiken liegen (z. B. “Brauchen E5 für volle Abdeckung von XY”). So sichern Sie sich weiteres Buy-in und Budget für kommende Compliance-Initiativen.

(Ergebnis nach 90 Tagen: Ihr Unternehmen hat alle relevanten Q1/2026-Neuerungen erfolgreich umgesetzt. Sie haben die Effektivität überprüft, Kennzahlen im Blick und wissen, wo es als nächstes hingeht. Kurz: Sie sind Montagmorgen bereit, aus diesen Changes konkrete Arbeitsaufträge abzuleiten und den Mehrwert zu realisieren.)

Unterstützung aus der Praxis

Die Umsetzung all dieser Compliance-Maßnahmen kann komplex sein – aber Sie müssen das Rad nicht allein neu erfinden. Es gibt erprobte Best Practices und Experten, die Ihnen mit Erfahrung zur Seite stehen:

Unsere Beratungsteams haben beispielsweise in den letzten Monaten mehrere Unternehmen bei genau solchen Projekten begleitet – von der DLP-Optimierung bis zur Insider Risk Einführung. Ein trocken-humoriges Beispiel aus der Praxis: Bei einem Kunden – einer Versicherung – führte “Wait on Send” zunächst zu Panik (“Mein Outlook ist kaputt, Mails gehen nicht raus!”). Durch gezielte User-Schulung mit einem Augenzwinkern (“Outlook macht jetzt den TÜV vor dem Losfahren”) konnten wir die Akzeptanz rasch steigern. Nach wenigen Wochen wollten die User die Funktion nicht mehr missen, weil sie selbst merkten, wie oft sie korrigieren konnten, bevor etwas Schlimmes passierte.

Gerade im DACH-Raum sind Aspekte wie Datenschutz und Mitbestimmung stets mitzudenken. Wir haben gelernt: Eine offene Kommunikation und Einbindung des Betriebsrats früh im Projekt zahlt sich aus. Zum Beispiel haben wir in einem Projekt zur Einführung von Communication Compliance einen Workshop mit dem Betriebsrat durchgeführt, bevor die technischen Weichen gestellt wurden. Das Ergebnis: klare Leitplanken, was überwacht wird (und was nicht), und volle Zustimmung – damit spart man sich spätere Konflikte. Unsere Berater kennen diese Stolpersteine und helfen, sie pragmatisch zu umschiffen.

Auch technisch profitieren Sie vom Praxis-Know-how: Sie fragen sich vielleicht, wie genau man adaptive Scopes in Purview formuliert oder wie man alte In-Place Records per Skript auf neue Labels umzieht. Solche Rezepte haben wir parat – oft sogar Skriptbibliotheken, die wir teilen können, um Migrations automatisch zu erleichtern. Und wir wissen, wo man aufpassen muss (Pro-Tipp: beim Löschen alter InfoPolicies erst sicherstellen, dass keine Aufbewahrungslücken entstehen – dafür lieber parallel laufen lassen und Monitoring einschalten).

Kurz gesagt: Scheuen Sie sich nicht, sich Unterstützung zu holen. Die Compliance-Welt wird komplexer, aber mit erfahrenen Partnern an der Seite bleiben Sie handlungsfähig und sparen Zeit. Ob es um strategische Beratung geht (“Wie bauen wir ein nachhaltiges Insider Risk Management Programm auf?”) oder um Hands-On Implementierung (“Bitte richtet uns die 50 DLP-Regeln effizient ein!”) – die Expertise ist da draußen. Und ja, manchmal hilft auch einfach ein Blick von außen, um betriebsblind gewordene Einstellungen zu optimieren (vielleicht nutzen Sie eine Funktion bisher gar nicht, die enormen Mehrwert brächte – uns fällt das oft auf in Assessments).

Zum Abschluss bieten viele Beratungen (auch wir) Compliance-Workshops oder “Managed Compliance Services” an. Dabei übernehmen Profis die kontinuierliche Pflege Ihrer Purview-Umgebung – Reporting, Tuning, Schulung inklusive. So können Sie sich aufs Kerngeschäft konzentrieren, während Ihre Compliance-Toolbox immer up-to-date und effektiv bleibt.

Unser Credo: Compliance ist kein Projekt, sondern ein Prozess. Und den meistern Sie am besten mit der richtigen Mischung aus interner Kompetenzaufbau und pragmatischer externer Hilfe, wo nötig. Nach Q1 2026 sind Sie bereits einen großen Schritt gegangen – gehen wir gemeinsam die nächsten.

Fazit

Q1 2026 hat im Microsoft 365 Compliance-Universum ordentlich Bewegung gebracht. Admins und Compliance-Verantwortliche haben jetzt neue Werkzeuge, um Daten noch besser zu schützen und regulatorische Anforderungen zu erfüllen – von der E-Mail, die nicht mehr unbemerkt mit geheimen Infos rauszischen kann, bis hin zur KI, die an der Leine geht und keine Geschäftsgeheimnisse ausplaudert.

Die Nutzen der Neuerungen liegen auf der Hand: Mehr Automatisierung, weniger Lücken, höhere Effizienz. Adaptive Scopes nehmen uns monotone Aufgaben ab, Mac-DLP schließt eine klaffende Lücke auf Apple-Geräten, und User Analytics in IRM liefert uns Sherlock-Holmes-mäßig den Gesamtzusammenhang frei Haus. Das bedeutet konkret: Weniger Risiko von Datenpannen, schnellere Erkennung von Zwischenfällen und am Ende des Tages auch Nachweise, dass wir unseren Compliance-Aufgaben nachkommen – wichtig für jede Prüfung.

Natürlich kommen mit neuen Funktionen auch Risiken & Herausforderungen: Jede Technik kann fehlkonfiguriert werden oder false positives produzieren. Und jede Einführung muss von den Mitarbeitern mitgetragen werden. Aber diese Risiken sind beherrschbar. Indem wir Pilotphasen einplanen, alle Stakeholder ins Boot holen (gerade beim Thema Überwachung ist Transparenz essenziell) und durchdachte Policies aufsetzen, minimieren wir Nebenwirkungen. Wichtig ist, sich nicht von der Technik treiben zu lassen, sondern klar zu definieren, was man erreichen will – dann die Features gezielt dafür einsetzen.

Nächste Schritte nach diesem Quartal: Dran bleiben! Compliance ist kein Zustand, sondern ein Marathon. Die nächsten Updates kommen bestimmt (Stichwort: Q2/2026 wird Purview sicher weiter verzahnen mit Insider Risk “Adaptive Protection” und Priva könnte in den Vordergrund treten). Das Fundament, das Sie jetzt gelegt haben – vereinheitlichte Labels, zentrales Retention-Management, durchgesetzte DLP – wird Ihnen helfen, kommende Neuerungen schneller zu adaptieren.

Unser Ausblick: Microsoft 365 entwickelt sich immer mehr zu einer “Compliance by Design”-Plattform. Was früher externe Tools oder manuelle Prozesse brauchte, ist immer häufiger nativ abgedeckt. Als Admin sollte man diese Chancen ergreifen – sie machen das Leben leichter, auch wenn es initial Arbeit bedeutet. Die Richtung stimmt: Weg von fragmentierten Lösungen, hin zu Purview als One-Stop-Shop für Datenreichtum sicher verwalten. Das reduziert letztlich auch Kosten und Komplexität – wenn richtig umgesetzt.

Zum Schluss noch ein pragmatischer Tipp: Humor kann helfen. Compliance ist ein ernstes Thema, ja – aber eine Prise trockener Humor nimmt die Steifheit und gewinnt Kollegen für sich. Schmunzeln Sie auch mal über die Absurdität mancher Situationen (“Unsere KI ist superintelligent, aber zum Glück zu doof fürs Bankgeheimnis – weil wir es so wollten!”). So vermitteln Sie: wir wissen was wir tun, und wir tun es der Sache nach richtig – ohne Panik, aber mit der nötigen Konsequenz.

In diesem Sinne: Legen Sie los, justieren Sie nach, und behalten Sie Ihre Daten und Risiken im Griff. Q1 2026 hat uns dafür die Tools gegeben. Nutzen wir sie, um unsere Organisation sicherer, regelkonformer und – ja – auch effizienter zu machen. Die Montags-Aufgabenliste ist lang, aber jetzt wissen Sie, wo Sie ansetzen müssen. Viel Erfolg dabei!

(Und denken Sie daran: Wenn’s klemmt, holen Sie sich Hilfe – Compliance ist Teamsport 😉.)

Optional: Mini-FAQ

F: Müssen wir jetzt überall E5-Lizenzen kaufen, um diese Features zu nutzen?
A: Nicht alle. Viele Verbesserungen (z. B. Outlook “Wait on Send”, Mac-PolicyTips, Adaptive Scope Preview) funktionieren mit E3. Aber die fetten Brocken (Insider Risk, Comm Compliance, Records Management) – ja, die sind E5-Domäne. Nutzen Sie ggf. Testlizenzen, um den Mehrwert zu zeigen und Management zu überzeugen. Microsoft bietet Rabatte für Purview Suite in Kombination mit Copilot an.

F: Kann ich “Wait on Send” erstmal nur für sensible Bereiche aktivieren?
A: Ja. Das Feature wird pro Mailbox/User eingeschaltet. Sie könnten z. B. nur für Vorstand und Rechtsabteilung starten. Empfohlen ist aber, es später breit auszurollen, da Datenlecks überall passieren können. Pilotieren – dann skalieren.

F: Unsere Anwender melden, dass Outlook auf Mac jetzt öfter Mails blockt – ist das wegen der neuen DLP-Hinweise?
A: Wahrscheinlich ja – vorher gingen diese Mails ungehindert raus, jetzt greift eben die Policy. Prüfen Sie die DLP-Regeln: Eventuell müssen Nutzer wissen, wie sie legitime Fälle freigeben (Override mit Begründung). Lieber ein false positive als ein echtes Leak, aber Kommunikation hilft hier Missverständnisse zu vermeiden.

F: Wie aufwändig ist die Migration der SharePoint-Inplace-Records zu Purview?
A: Manuell etwas Aufwand: Sie müssen neue Retention Labels anlegen, diese den Dokumenten zuweisen (via Script oder manuell) und die alten abschalten. Je nach Doku-Anzahl kann ein Skript über die Libraries laufen und Label setzen – das geht, aber testen Sie gut. Microsoft stellt keine Automagie bereit, leider. Planen Sie pro betroffener Bibliothek einige Stunden inkl. Tests ein. Bei hunderten Libraries: Scripting & ggf. Partner-Tool nutzen.

F: Was passiert, wenn Copilot etwas Vertrauliches beantworten will?
A: Mit aktivierter DLP-Policy für Copilot wird die Antwort entweder blockiert oder verfremdet (je nach Richtlinie, z. B. <Benutzerdaten entfernt>). Der Nutzer bekommt eine entsprechende Mitteilung. Im Log sehen Sie den Versuch. Ohne diese Policy würde Copilot versuchen zu antworten – in internen Tests hat er durchaus Dinge aus internen Dokus zitiert, die nicht für jeden bestimmt waren. Daher: DLP-Policy für Copilot ist Pflicht, um Oversharing zu verhindern.

F: Können Adaptive Scopes auch für andere Sachen als DLP verwendet werden?
A: In Q1 2026 bezieht sich Adaptive Scope Preview auf DLP (SharePoint). Früher gab’s ähnliches für Retention (Adaptive Policy Scopes für O365 Groups, DLs etc.). Denkbar, dass Microsoft das ausweitet. Aktuell also getrennt: Retention Adaptive Scopes (schon GA) und DLP Adaptive Scopes (jetzt neu in Preview). Beide funktionieren ähnlich, aber für unterschiedlichen Zweck.

F: Unser Betriebsrat hat Bedenken wegen Insider Risk Analytics – wie können wir sicherstellen, dass keine “Mitarbeiterüberwachung” im illegalen Sinn passiert?
A: Insider Risk Management wurde mit Privacy-by-Design entwickelt: Mitarbeiter werden pseudonymisiert dargestellt bis ein hohes Risiko eine Enttarnung rechtfertigt. Legen Sie gemeinsam mit dem BR schriftlich fest, wann ein Fall eröffnet werden darf (z. B. nach x Indikatoren) und wer Zugriff hat. Transparenzprotokolle (Audit Logs) sind aktiviert. Wichtig: IRM zielt auf Schutz von Unternehmen und Mitarbeitern (z. B. Hilfestellung, bevor jemand absichtlich oder unabsichtlich großen Schaden anrichtet). Mit diesen Argumenten und einer Betriebsvereinbarung haben wir in vielen Projekten Zustimmung erhalten.

F: Können wir die neuen Alerts bei Communication Compliance dazu nutzen, dass HR nur einmal die Woche Fälle sichtet?
A: Genau das ist der Gedanke! Sie können pro Policy einstellen, dass z. B. HR-Compliance-Policy Alerts gesammelt Montags 9 Uhr geschickt werden. HR muss dann nicht dauernd Ad-hoc reagieren, sondern kann im Block auswerten. Nur bei extremen Verstößen (definieren Sie entsprechende Policy) würde sofort eine Meldung gehen, z. B. an Security.

F: Wie erfahre ich von solchen Neuerungen zukünftig zeitnah?
A: Am besten durch Kombination: Microsoft 365 Message Center (schauen Sie wöchentlich rein, kategorisieren nach Compliance), Roadmap-Tracking und Tech Community Blogs (wie “What’s new in Purview”). Vielleicht abonnieren Sie auch unseren Newsletter – wir fassen solche Updates praxisgerecht zusammen 😉. Zudem ist jetzt das Purview Health Dashboard da – das kündigt zwar keine neuen Features, aber informiert über Probleme. Für Neuerungen bleibt etwas Fleiß gefragt. Dieser Artikel sollte Sie für Q1 2026 auf Stand gebracht haben – für Q2 und weiter: dranbleiben, lesen, austauschen.

Ende des Fachartikels. Bleiben Sie compliant! 🚀