M365-Compliance in der Praxis (oder: „So mache ich das in Projekten“)

Management Summary

Ich habe in den letzten Jahren zahlreiche Microsoft-365-Umgebungen auf Compliance getrimmt – vom kleinen Mittelständler bis zum Großkonzern. Meine Erkenntnis: M365-Compliance ist weder Hexerei noch ein Spaßverderber, sondern solide Handwerksarbeit. Mit den richtigen Regelwerken, klar verteilten Rollen und pragmatischen Maßnahmen verwandeln Sie abstrakte Vorgaben (Hallo DSGVO!) in funktionierende Praxis. Klingt trocken? Keine Sorge – wir machen das Ganze greifbar und verlieren den Humor nicht: Ein bisschen Augenzwinkern hat noch jedem Projekt gutgetan.

Dieser Leitfaden (Stand: November 2025) zeigt Schritt für Schritt, wie Sie Compliance in Microsoft 365 umsetzen. Vom Umgang mit Risiken über die passende Architektur bis hin zu Richtlinien, technischen Lösungen und KPIs decken wir alles ab. Ich berichte in Ich-Form aus der Praxis – jedes Beispiel, jede Anekdote stammt aus echten Projekten, die ich persönlich betreut habe. Apropos persönlich: alle Leistungen erbringe ich selbst, kein Outsourcing, keine anonyme Hotline. Managed Services? Fehlanzeige. Weder 24/7-Betrieb noch Wartungsverträge – stattdessen punktuelle Unterstützung nach Bedarf. Das heißt, ich stehe Ihnen etwa für Audits, Reviews oder Schulungen zur Seite, wenn’s drauf ankommt, übernehme aber nicht den Dauerbetrieb Ihrer Systeme.

Am Ende des Artikels stelle ich Ihnen drei klar umrissene Beratungspakete vor – Compliance-Start, Compliance-Pro und Compliance-Enterprise/KRITIS. Jedes Paket hat ein definiertes Ziel, einen festen Umfang, konkrete Ergebnisse – und eine transparente Preisformel (Tagessatz: 1.500 € zzgl. MwSt., Reisekosten separat). So wissen Sie von Anfang an, womit Sie rechnen können.

Kurzum: Sie bekommen hier einen praxisnahen Leitfaden für M365-Compliance und einen Eindruck, wie eine Zusammenarbeit mit mir aussieht. Wenn Sie IT-Leiter, CISO, Datenschutzbeauftragter, Revisor oder M365-Architekt sind – also jemand, der die Ehre hat, sich um “diesen Compliance-Kram” zu kümmern –, dann ist dieser Artikel für Sie. Viel Spaß beim Lesen und auf geht’s zur M365-Compliance in der Praxis!

Regelwerke & Standards

Jede Compliance-Reise beginnt mit einem Blick ins Regelwerk-Dickicht. Für Microsoft 365 bedeutet das: Welche externen und internen Vorgaben müssen wir einhalten? Externe Vorgaben sind z.B. Gesetze und Standards: allen voran die Datenschutz-Grundverordnung (DSGVO) in der EU. Dazu kommen branchenspezifische Anforderungen – von ISO 27001 über TISAX (für die Automobilbranche) bis zu HIPAA (für Gesundheitsdaten) oder dem deutschen IT-Sicherheitsgesetz (KRITIS) für kritische Infrastrukturen. Auch die neue NIS2-Richtlinie der EU und der AI Act werfen ihre Schatten voraus – man sieht, Langeweile kommt nicht auf.

Daneben gibt es interne Richtlinien und Verträge: Unternehmensweite Policies, Betriebsvereinbarungen, vielleicht ein Code of Conduct oder spezielle Vorgaben der Konzernmutter. Nicht zu vergessen: Der Vertrag zur Auftragsverarbeitung mit Microsoft. Microsoft agiert in Cloud-Szenarien als Auftragsverarbeiter, während Sie (bzw. Ihre Organisation) der Verantwortliche im Sinne der DSGVO sind. Heißt im Klartext: Sie müssen nachweisen können, dass Microsoft 365 datenschutzkonform eingesetzt wird. Das Lizenzkleingedruckte mag trocken sein, aber prüfen Sie es – insbesondere die Punkte Datenstandorte, Subunternehmer und internationale Datenübermittlungen (Stichwort EU-USA).

Praxis-Kasten: So mache ich das in Projekten
Ganz am Anfang eines Compliance-Projekts erstelle ich mit dem Kunden ein Regelwerks-Inventar. Wir notieren gemeinsam alle Gesetze, Standards und internen Vorgaben, die relevant sind – vom DSGVO-Check bis zur Konzernrichtlinie. Diese Liste hängt dann oft gut sichtbar im Projektbüro (oder digital im Team-Chat angepinnt). So verliert niemand die Vorgaben aus den Augen. Es klingt simpel, aber glaubt mir: Diese Klarheit am Start erspart später endlose Diskussionen à la „Müssen wir das auch noch machen…?“.

Praxis-Tipp: Machen Sie zu Beginn eine Liste aller relevanten Regelwerke. Fragen Sie sich: Welche Gesetze gelten für uns? Gibt es interne Compliance-Vorgaben? Und was erwarten unsere Kunden oder Auditoren? Diese “Compliance-Landkarte” bildet den Ausgangspunkt. In Microsoft 365 hilft Ihnen übrigens der Compliance Manager (Teil von Microsoft Purview): Er bietet Vorlagen für viele Regelwerke – von DSGVO über ISO 27001 bis hin zu spezifischen Benchmarks. Damit können Sie Ihren Umsetzungsgrad messen (als Compliance Score in Prozent) und sehen, wo noch Lücken sind. Natürlich ersetzt das nicht den gesunden Menschenverstand, aber es ist ein nettes Cockpit, um nicht den Überblick zu verlieren.

Kurz gesagt: Kennen Sie Ihre Spielregeln. M365-Compliance heißt, diese oft abstrakten Vorgaben greifbar zu machen. Keine Panik – Sie müssen jetzt nicht jeden Paragrafen auswendig lernen. Aber die großen Leitplanken sollte man im Kopf haben, bevor man losrennt. Sonst läuft man Gefahr, etwas Wichtiges zu übersehen – und am Ende schaut der Auditor genauso grimmig wie ein Schiedsrichter mit Kartenflut. 😉

Risiken & Herausforderungen

Wo Licht ist, ist auch Schatten – bei Compliance heißt das: Risiken. Bevor wir kopfüber in technische Details springen, lohnt ein Blick auf die größten Risiken und Stolperfallen in einer M365-Umgebung. Denn nur was wir verstanden haben, können wir managen (sagt der Risiko-Manager und zieht bedeutungsvoll die Augenbraue hoch).

Typische Compliance-Risiken in Microsoft 365 sind: – Datenpannen: Ein vertrauliches Dokument wird versehentlich extern geteilt oder eine E-Mail mit Patienteninfos gelangt in falsche Hände. Die Folgen? DSGVO-Bußgelder, Reputationsverlust, schlaflose Nächte. – Unzureichende Aufbewahrung: Wichtige Unterlagen werden zu früh gelöscht (ups…) oder zu lange behalten (auch nicht besser). Beides kann rechtliche Probleme nach sich ziehen. – Zugriffsverstöße: Mitarbeiter erhalten Zugang zu Daten, die sie nichts angehen – ob absichtlich oder durch schlampige Rechtevergabe. Dadurch drohen Insider-Leaks und Prügel von der Revision. – Fehlende Nachvollziehbarkeit: Ohne Logging und Audit-Trails tappen Sie im Ernstfall im Dunkeln. „Wer hat denn die Datei gelöscht?“ – „Keine Ahnung.“ Solche Dialoge möchten Sie vermeiden. – Menschliches Versagen: Ja, auch das gehört dazu. Phishing, einfache Passwörter auf Post-its, vertrauliche Infos im Plauderton via Teams-Chat an Externe… Die beste Technik hilft wenig, wenn der Mensch quer schießt. – Schatten-IT: Nutzer umschiffen Richtlinien, indem sie eigene Cloud-Dienste nutzen (Stichwort: Dropbox, private WhatsApp-Gruppen). Damit entziehen sich Daten den offiziellen Kontrollen – ein Alptraum für Compliance.

Um diese Risiken greifbar zu machen, erstelle ich gerne ein Risiko-Register. Hier ein Beispiel, wie so etwas aussehen kann:

Risiko	Auswirkung	Wahrscheinlichkeit	Gegenmaßnahmen
Datenpanne – z.B. vertrauliches Dokument versehentlich extern geteilt	Hohe Bußgelder (DSGVO), Vertrauensverlust, Imageschaden	Mittel	DLP-Policies einführen; Sensibilisierung der Nutzer; Freigaben überwachen
Verstoß gegen Aufbewahrungspflichten – Daten werden zu früh gelöscht (oder zu lange aufgehoben)	Rechtliche Konsequenzen, Prüfungsbeanstandungen	Niedrig-Mittel	Aufbewahrungsrichtlinien konfigurieren; regelmäßige Auditierung der Löschprotokolle
Unberechtigter Zugriff – fehlende oder falsche Berechtigungskonzepte	Diebstahl von Informationen, Insider Threats, mögliche Datenschutzverstöße	Mittel	Striktes Rollen- und Rechtemodell; MFA und Conditional Access einsetzen; Berechtigungs-Reviews durchführen
Keine Protokollierung – Audit-Logs deaktiviert oder zu kurz aufbewahrt	Vorfälle können nicht aufgeklärt werden; fehlender Nachweis bei Audits	Niedrig	Audit-Log in M365 aktivieren (Standard: 90 Tage, evtl. E5 für länger); Logs zentral sammeln (SIEM)
Benutzerfehler – Phishing-Angriff erfolgreich oder Passwortraten	Kontoübernahme, Datenabfluss, Malware-Schäden	Hoch	Awareness-Schulungen, Phishing-Tests; strikte Passwort-Policies und Multi-Faktor-Authentifizierung (MFA)
Schatten-IT – Nutzung nicht freigegebener Tools (z.B. private Cloud-Speicher)	Daten liegen außerhalb der kontrollierten Umgebung; Compliance-Kontrollen greifen nicht	Mittel	Klare Richtlinien kommunizieren; attraktive offizielle Alternativen bieten (z.B. OneDrive/Teams statt unsichere Tools); Monitoring von Datenabflüssen

Man erkennt: Viele Risiken lassen sich mit technischen und organisatorischen Maßnahmen reduzieren. Ganz eliminieren lässt sich kein Risiko – aber wir können die Eintrittswahrscheinlichkeit und den Schaden begrenzen. Wichtig ist, zunächst ehrlich hinzuschauen: Wo sind wir verwundbar?

Praxis-Kasten: So mache ich das in Projekten
In jedem Projekt starte ich mit einem munteren Risiko-Workshop. Klingt unpopulär, macht aber sogar Spaß (auf eine schräge Art): Alle Beteiligten werfen mal die schlimmsten Szenarien in den Raum – vom „CEO verschickt Gehaltsliste an alle“ bis „Hacker streamt Firmenmeeting live auf YouTube“. Da wird gelacht (Galgenhumor verbindet), aber plötzlich nehmen alle das Thema sehr ernst. Das Ergebnis ist eine priorisierte Liste echter Risiken, über die wir sprechen müssen. Dieser frühe Realitätscheck rückt die Sinne zurecht und schafft Commitment, die Risiken auch anzugehen. Jeder im Raum weiß danach: Wegschauen gilt nicht, wir sitzen alle im selben Boot – also sorgen wir lieber dafür, dass es nicht leckschlägt.

Ein Punkt zum Schluss dieses Kapitels: Balance finden. Zu viel Panikmache lähmt, zu viel Leichtsinn rächt sich. Compliance bedeutet, Risiken zu managen, nicht um jeden Preis auszumerzen. Eine 100% risikofreie IT gibt es nicht – und wenn doch, möchte ich nicht darin arbeiten (zu viele Verbote, zu wenig Kaffee). Das Ziel ist ein vertretbares Restrisiko, mit dem alle leben können. Mit diesem Mindset gehen wir nun an die konkrete Umsetzung.

Rollen & Verantwortlichkeiten

Compliance in M365 ist Teamsport. Es reicht nicht, einen IT-Admin auf die Schulung zu schicken und „Mach mal Compliance!“ zu sagen. Verschiedene Schultern müssen verschiedene Lasten tragen. Deshalb klären wir früh: Wer übernimmt welche Rolle?

Typischerweise sind folgende Rollen im Spiel: – Geschäftsführung/Vorstand – gibt den Ton von oben an („Tone from the Top“) und stellt Ressourcen bereit. Ohne Rückendeckung von oben verpufft jedes Compliance-Projekt. – IT-Leiter / CIO – verantwortet die technische Umsetzung im großen Ganzen, priorisiert Maßnahmen und koordiniert zwischen IT und Fachbereichen. – CISO / IT-Sicherheitsverantwortlicher – kümmert sich um die Sicherheit und hat oft auch Compliance-Teilaufgaben (Policies, Monitoring) auf dem Tisch. Quasi der Sicherheitsdirigent. – Datenschutzbeauftragter (DSB) – wacht über die Einhaltung der DSGVO und anderer Datenschutzvorschriften. Er ist derjenige, der nervös mit der DSGVO-Fahne wedelt, wenn mal wieder jemand alle Mitarbeitergeburtstage im Intranet posten will. – Microsoft-365-Administrator / Architekt – setzt die technischen Einstellungen um (von Labels bis DLP-Regeln) und kennt die Plattform in- und auswendig. Ohne ihn läuft nichts, wortwörtlich. – Interne Revision / Auditor – prüft unabhängig, ob alles regelkonform abläuft. Sie/Er kommt gerne mit Fragen wie „Wo steht das geschrieben?“ und „Zeigen Sie mir mal das Protokoll von jenem Löschvorgang“.

In größeren Organisationen gibt es vielleicht noch mehr Rollen (z.B. einen Compliance Officer, Fachbereichskoordinatoren, Legal-Abteilung etc.). Aber konzentrieren wir uns auf die Kernspieler. Um Überschneidungen und Lücken zu vermeiden, arbeite ich gerne mit einer RACI-Matrix. RACI steht für Responsible, Accountable, Consulted, Informed (Verantwortlich, Rechenschaftspflichtig, Eingebunden, Informiert). Für alle wichtigen Aufgaben wird festgelegt, wer sie umsetzt (R), wer die endgültige Verantwortung trägt (A), wer beratend zuzieht ist (C) und wer zumindest Bescheid wissen muss (I). Hier ein vereinfachtes Beispiel:

Aufgabe	Geschäfts- führung	IT-Leiter	CISO	DSB	M365-Admin	Interne Revision
Compliance-Ziele definieren	A	C	R	C	I	I
Rollen & Verantwortlichkeiten festlegen	A	R	C	C	I	I
Risiko-Analyse durchführen	I	C	A/R	C	I	I
M365-Architektur planen (Compliance by Design)	I	A	C	C	R	I
Richtlinien (Policies) entwerfen	I	C	A	R	C	I
Technische Maßnahmen umsetzen	I	A	C	C	R	I
Mitarbeiter schulen & sensibilisieren	A	C	C	R	I	I
Monitoring & KPIs etablieren	I	A	R	C	R (für Reports)	I
Audit / Review durchführen	I	C	C	C	C	A/R
Programm kontinuierlich verbessern	I	C	A	C	C	C

(A = Accountable, R = Responsible, C = Consulted, I = Informed)

In diesem (beispielhaften) Modell sehen Sie, dass niemand alle Aufgaben allein stemmt – und idealerweise jede Aufgabe genau einen verantwortlichen Besitzer hat (Accountable). Die Geschäftsführung ist z.B. für Ziele und Top-Level-Entscheidungen accountable, während die Umsetzung bei IT-Leiter, CISO, DSB und Admin-Team liegt. Die interne Revision ist für Audits verantwortlich, nicht jedoch für die Umsetzung der Maßnahmen – das wäre der Bock als Gärtner. 😉

Praxis-Kasten: So mache ich das in Projekten
Bei der Rollendefinition erlebe ich oft Aha-Momente. Etwa wenn dem Vorstand klar wird, dass er am Ende den Kopf für die Compliance hinhält (Accountable), auch wenn die IT natürlich operativ umsetzt. Oder wenn der IT-Admin merkt, dass er nicht allein im stillen Kämmerlein zaubern muss, sondern andere mit im Boot sind. Ich lasse jede Rolle am Anfang schriftlich bestätigen, welche Verantwortlichkeiten sie übernimmt – kein Witz! Das muss kein dröges Dokument sein; manchmal reicht eine E-Mail an alle: „Hiermit übernehme ich Rolle X und kümmere mich um Y“. Das schafft Verbindlichkeit. Und keine Sorge: Sollte irgendwo eine Lücke klaffen, merken wir das schnell und justieren nach. Wichtig ist, dass alle wissen, wer im Zweifel welche Mütze aufhat.

Klare Rollenverteilung ist übrigens auch für mich als externer Berater wichtig. In RACI-Begriffen bin ich meist Consulted (beratend) und selten mal Responsible – denn umsetzen müssen es letztlich Ihre Leute im Unternehmen. Accountable für Compliance bleibt sowieso immer die Unternehmensleitung. Ich helfe, coache, erinnere – aber Ihre Mannschaft muss am Ball bleiben (was sie mit klaren Zuständigkeiten auch tut). Fazit: Definieren Sie früh, wer was macht. Dann klappt’s auch im Alltag – ohne Fingerpointing, dafür mit viel Teamgeist.

M365-Architektur: Fundament der Compliance

Jetzt wird’s technisch: Die Architektur Ihrer Microsoft-365-Umgebung legt den Grundstein für Compliance. Hier geht es um die großen Design-Entscheidungen, bevor wir in einzelne Richtlinien abtauchen. Stellen Sie sich die Architektur wie den Bauplan eines Hauses vor – wenn Sie den Tresorraum (sprich: vertrauliche Daten) direkt neben den Besucherempfang planen, wird’s ungemütlich. Also, worauf kommt es an?

• Tenant-Standort & Datenresidenz: Wählen Sie die richtige geografische Region für Ihren M365-Tenant. In Europa tätige Firmen sind i.d.R. mit einem EU-Tenant gut beraten (Microsoft betreibt Rechenzentren in der EU, z.B. in Deutschland und den Niederlanden). So bleiben Kundendaten, soweit möglich, in der EU. Für multinationale Konzerne bietet Microsoft auch Multi-Geo an – damit können Sie Daten bestimmter Nutzergruppen gezielt in bestimmten Regionen speichern (praktisch für lokale Datenschutzanforderungen).
• Aufbau der Arbeitsräume: Überlegen Sie sich eine sinnvolle Struktur von Teams, Sites und Gruppen. Sensible Daten gehören in speziell gesicherte Bereiche – z.B. ein Team „Finance – Vertraulich“ mit streng limitiertem Zugriff. Öffentliche Teams für belanglose Plaudereien dürfen offen sein, aber nicht alles sollte wild herumgeteilt werden. Mit einer klugen Informationsarchitektur (wer speichert was wo?) schaffen Sie klare Datenzonen, die sich unterschiedlich schützen lassen.
• Identity & Access Management: Nutzen Sie die Stärken von Microsoft Entra ID (vormals Azure AD). Das heißt: konsequente Multi-Faktor-Authentifizierung (MFA) für alle, bedingter Zugriff (Conditional Access) für sensible Aktionen und ein Least-Privilege-Prinzip für Admins. Globale Administratoren sollten so selten wie möglich genutzt werden – stattdessen verteilen Sie granular Rechte (Exchange-Admin, SharePoint-Admin, Compliance-Admin etc.). Und für kritische Rollen: aktivieren Sie Privileged Identity Management (PIM), damit Admin-Rechte nur temporär auf Anfrage vergeben werden (Stichwort: just-in-time Administration).
• Integrationen & Logging: Planen Sie, wie Logs und Datenflüsse in Ihrer Architektur integriert sind. Beispiel: Alle Audit-Logs könnten in ein zentrales SIEM (Security Information and Event Management) fließen, damit Sie Vorfälle zentral überwachen. Oder: setzen Sie auf Microsoft Purview und dessen Compliance Center als Zentrale, um M365-Compliance-Daten und -Einstellungen zu bündeln. Purview ist quasi die Schaltzentrale, in der Sie alles verwalten – von DLP-Regeln bis eDiscovery – und sollte architektonisch von Anfang an eingeplant sein (Zugriff drauf, Rollen dafür etc.).
• Geräte & Netzwerk: Überlegen Sie, wie Endgeräte und Netzwerk in die Gleichung passen. Gerätemanagement (Intune) und Policies für Bring Your Own Device (BYOD) sind architekturelle Fragen, die Compliance beeinflussen (z.B. verhindern, dass Unternehmensdaten auf privaten ungesicherten Geräten landen). Ebenso die Netzwerkarchitektur: Direkter Cloud-Zugriff vs. VPN – es gibt kein richtig oder falsch, aber es beeinflusst, wie Sie z.B. Cloud App Security (jetzt Defender for Cloud Apps) einsetzen.

Kurzum, Compliance by Design bedeutet: Schon in der Bauphase Ihres M365-Hauses denken Sie an Sicherheit und Vorschriften. Wer erst nach dem Einzug überall Alarmanlagen anbringt, wird viele Kompromisse machen müssen. Lieber von Anfang an eine Architektur wählen, die flexibel genug ist, um Compliance-Anforderungen abzubilden. Und falls Ihr Haus (sprich Tenant) schon steht: Keine Sorge, man kann nachrüsten – es kostet nur manchmal ein paar Nerven mehr. Ich empfehle, regelmäßig einen Architektur-Review durchzuführen, gerade wenn Microsoft neue Services einführt (Hallo, Microsoft Copilot?) oder sich interne Anforderungen ändern.

Ein letzter Hinweis: Verschlüsselung. M365 verschlüsselt Daten standardmäßig (in Ruhezustand und Übertragung). Für die meisten reicht das vollkommen. Aber wer es ganz genau braucht (Stichwort: streng geheime Daten, Regulierung, paranoider Vorstand mit Aluhut 😜): Es gibt Optionen wie Kundenschlüssel (Customer Key) und Doppelverschlüsselung (Double Key Encryption), wo Sie eigene Schlüssel ins Spiel bringen. Diese erfordern aber eine durchdachte Architektur und gutes Schlüsselmanagement – nichts für mal eben nebenbei. Planen Sie so etwas also frühzeitig ein, falls benötigt.

Fazit: Eine solide M365-Architektur ist die halbe Miete. Sie schafft die Grundlage, auf der Richtlinien und technische Maßnahmen erst richtig wirken können. Bauen Sie das Fundament stabil, dann wackelt das Compliance-Haus auch in stürmischen Zeiten nicht.

Compliance-Richtlinien & Policies

Jetzt wird’s formal: Richtlinien. Keine Compliance ohne ein paar sauber formulierte Regeln auf Papier – oder besser gesagt in PDFs, Intranet-Wikis etc. Diese Policies legen fest, wie mit Daten und IT umzugehen ist, damit wir im grünen Bereich bleiben. Wichtig: Die schriftlichen Richtlinien des Unternehmens bilden die Grundlage, die wir dann technisch in M365 abbilden. Erst kommt die Regel, dann die technische Umsetzung – nicht umgekehrt.

Typische Richtlinien im Compliance-Katalog sind zum Beispiel:

Richtlinie	Zweck / Beschreibung
Datenschutzrichtlinie	Regelt den Umgang mit personenbezogenen Daten im Unternehmen. Enthält z.B. Grundsätze zur DSGVO, Rechte der Betroffenen, Meldepflichten bei Datenpannen und Vorgaben zur Auftragsverarbeitung.
Informationsklassifizierung	Legt fest, wie Informationen nach Sensitivität eingestuft werden (z.B. Öffentlich, Intern, Vertraulich, Geheim) und welche Schutzmaßnahmen je Klasse gelten. Dient als Basis für Sensitivity Labels in M365.
Aufbewahrungsrichtlinie	Bestimmt, wie lange Daten aufzubewahren sind und wann sie zu löschen sind. Orientiert sich an gesetzlichen Aufbewahrungsfristen (z.B. 10 Jahre für Geschäftsunterlagen) und internen Bedürfnissen. In M365 durch Retention Labels/Policies umgesetzt.
Zugriffskontrollrichtlinie	Beschreibt, wer auf welche Daten zugreifen darf. Prinzip der minimalen Rechte (Least Privilege), Verfahren zur Rechtevergabe und -entzug, regelmäßige Berechtigungsüberprüfungen (Rezertifizierungen).
Nutzungsrichtlinie IT/Cloud	„Acceptable Use Policy“ für M365: Was dürfen Nutzer und was nicht? Z.B. Regeln für externe Sharing, Verbot der privaten Nutzung von Geschäftsdaten, keine Installation unerlaubter Apps, Umgang mit Passwörtern, etc.
Incident-Response-Plan	Vorgehensplan für Sicherheitsvorfälle und Datenschutzverletzungen. Wer muss was tun, wenn’s knallt (z.B. Meldung an DSB innerhalb 24h, Forensik, Info an Betroffene etc.) – damit im Ernstfall alle wissen, was zu tun ist.
Bereichsspezifische Policies	Optional: Weitere Richtlinien je nach Bedarf, z.B. E-Mail-Richtlinie (Nutzung von Verschlüsselung, Disclaimer etc.), BYOD-Policy (Regeln für private Geräte im Unternehmensgebrauch), Clear-Desk-Policy (auch analog wichtig!) und so weiter.

Man muss nicht mit 20 Richtlinien auf einmal starten. Qualität vor Quantität. Wichtig ist, dass die vorhandenen Policies auch gelebt werden. Eine tolle Datenklassifizierungsregel bringt nichts, wenn keiner sie kennt oder anwendet. Daher: Schreiben Sie Richtlinien verständlich (kein Juristendeutsch für die Mülltonne), schulen Sie die Mitarbeiter darauf und stellen Sie sicher, dass Führungskräfte mit gutem Beispiel vorangehen.

Praxis-Kasten: So mache ich das in Projekten
Die Einführung der Informationsklassifizierung ist oft ein Kulturschock – positiv gemeint! In Workshops lasse ich gerne realistische Beispiele bewerten: Ist die Kantinen-Speisekarte „öffentlich“ oder „intern“? Was ist mit dem Organigramm? Plötzlich diskutieren Vertriebsleiter und Datenschützer leidenschaftlich über Einstufungen. Genau das will ich erreichen: Bewusstsein schaffen. Am Ende des Workshops stehen meist 3–4 klare Klassifizierungsstufen samt Definition, und jeder hat verstanden, warum wir das tun. Pro-Tipp: Halten Sie die Klassifizierung simpel. Lieber drei Stufen, die jeder kapiert, als sieben Stufen, die keiner auseinanderhält. Und: Verbinden Sie jede Klasse mit konkreten Beispielen und Maßnahmen („Vertraulich = z.B. Kundenlisten; müssen verschlüsselt gespeichert und dürfen nur intern geteilt werden.“). So wird aus trockener Theorie gelebte Praxis.

Wenn die Policies stehen, folgt der Abgleich mit M365: Jede Richtlinie muss technisch unterfüttert werden. Haben wir z.B. eine Aufbewahrungsrichtlinie „E-Mails 6 Jahre aufbewahren“, dann richten wir genau das als Retention Policy ein. Steht in der Datenschutzpolicy, dass alle personenbezogenen Daten zu verschlüsseln sind, setzen wir z.B. Sensitivity Labels mit Verschlüsselung durch. Dieser Schulterschluss zwischen Papier und Cloud ist essentiell. Nichts ist peinlicher, als wenn in der Policy etwas versprochen wird, was in der IT nicht umgesetzt ist – das merken Prüfer sofort.

Last but not least: Halten Sie Ihre Richtlinien aktuell. Technologien ändern sich (M365 bringt ständig neue Features), Gesetze ändern sich (hallo Telemetrie-Diskussion, hallo KI-Regulierung) – also sollten die Policies mindestens jährlich auf den Prüfstand. Und bei Änderungen: alle betroffenen Kollegen informieren! Nur so bleiben Richtlinien lebendige Leitplanken und verkommen nicht zum Papiertiger.

Technische Maßnahmen in M365

So, Richtlinien stehen – jetzt ab in die Cloud-Konsole! Technische Maßnahmen sind das, was die schönen Policies tatsächlich wirksam macht. Microsoft 365 bietet eine Fülle an Features, um Compliance umzusetzen. Hier ein Überblick der wichtigsten Werkzeuge, die ich in der Praxis einsetze:

• Sensitivity Labels & Verschlüsselung: Mit Empfindlichkeitsbezeichnungen (Sensitivity Labels) können Sie Dokumente und E-Mails klassifizieren und bei Bedarf automatisch verschlüsseln. Beispiel: Label „Vertraulich“ = Nur firmeninterne Personen können öffnen, Weiterleiten wird verhindert, Watermark aufs Dokument. Labels lassen sich manuell durch Benutzer setzen oder (mit ausreichend Lizenz) anhand von Inhalt automatisiert anwenden. Wichtig: Definieren Sie Ihre Label-Taxonomie klug (siehe Klassifizierung oben) und testen Sie gründlich, wer auf ein verschlüsseltes Dokument noch zugreifen kann und wer nicht. Nichts ist peinlicher, als wenn der Vorstand seine eigenen vertraulichen Dateien nicht mehr öffnen kann.
• Data Loss Prevention (DLP): DLP-Policies überwachen E-Mails, Teams-Chats und Dateien darauf, ob sensible Informationen nach draußen fließen. Klassisches Beispiel: Jemand will eine Liste mit 1000 Kundendaten an einen externen Partner mailen. DLP erkennt: „Uhhh, da sind viele Personendaten oder Kreditkartennummern drin“ und kann je nach Regel die Mail blocken, verzögern oder zumindest warnen. Sie können DLP-Regeln für verschiedenste Datentypen nutzen (vordefinierte Patterns wie Kreditkartennummern, IBAN, Ausweisnummern etc. sind an Bord). In der Praxis ist DLP Gold wert, um versehentliche Datenlecks zu verhindern – aber achten Sie auf Tuning, sonst nervt es die Anwender (Stichwort: False Positives).
• Aufbewahrung & Löschung (Retention): Über Retention Policies und Retention Labels stellen Sie sicher, dass Daten so lange aufbewahrt (oder so früh gelöscht) werden, wie es die Regelwerke verlangen. Beispiele: „Alle E-Mails 6 Jahre behalten, dann löschen“ oder „SharePoint-Dateien in Projektseite X nach Projektende 3 Jahre aufbewahren“. Mit Labels können Sie sogar einzelne Dokumente als „Record“ deklarieren (unveränderbar archivieren). Wichtig ist, die Aufbewahrungsfristen aus Ihrer Aufbewahrungsrichtlinie konsequent in M365 abzubilden. Tipp: Fangen Sie mit den kritischsten Inhalten an (z.B. Finanzdaten, Personalakten) – Sie müssen nicht alles auf einmal regeln.
• eDiscovery & Legal Hold: Wenn’s hart auf hart kommt – Rechtsstreit oder Prüfung – brauchen Sie alle relevanten Mails und Dokumente auf Abruf. Hier kommt eDiscovery ins Spiel (Elektronische Beweissuche). In Microsoft 365 können Sie mit eDiscovery gezielt Inhalte suchen, exportieren und rechtssicher bereitstellen. Wichtiger Bestandteil ist der Legal Hold (rechtliche Aufbewahrungssperre): Damit frieren Sie Daten ein, sodass niemand sie löschen kann, solange die Hold aktiv ist. Beispiel: Ein (Ex-)Mitarbeiter verklagt die Firma, also setzen wir sein Postfach und OneDrive unter Legal Hold, damit nichts verloren geht, bis der Fall geklärt ist. Pro-Tipp: Legal Hold frühzeitig nutzen, sobald sich ein Rechtsfall andeutet – rückwirkend kann man gelöschte Mails nicht herbeizaubern.
• Audit-Logging & Überwachung: Aktivieren Sie unbedingt das Unified Audit Log in M365 (falls nicht eh schon aktiv). Darin protokolliert das System nahezu jede Aktion: Login-Versuche, Datei-Downloads, Mail-Regeländerungen, Admin-Aktionen, you name it. Diese Logs sind Gold wert, um im Nachhinein Vorfälle aufzuklären und um regelmäßige Checks zu fahren („Wer hat letzte Woche Zugriffsrechte geändert, und war das legitim?“). Für E5-Kunden gibt’s Advanced Audit, das einige wichtige Aktivitäten länger als 90 Tage vorhält (bis zu 1 Jahr) – sehr hilfreich für langfristige Forensik. Zudem würde ich einen automatisierten Audit-Review-Prozess etablieren: z.B. monatlich stichprobenartig Logberichte prüfen oder Alarme einrichten (via SIEM oder Cloud App Security) bei bestimmten Ereignissen.
• Insider Risk Management & Communication Compliance: Zwei Premium-Funktionen aus Microsoft Purview, die in sehr sensitiven Umgebungen genutzt werden. Insider Risk Management analysiert Benutzeraktionen auf potentielle Insider-Risiken (z.B. Mitarbeiter lädt kurz vor Kündigung massenhaft Dateien herunter – könnte Datenabzug sein). Communication Compliance überwacht Kommunikationsinhalte auf definierte Verstöße (z.B. Belästigung, Insider-Handel-Hinweise in Chats bei Banken). Diese Tools erfordern viel Feintuning und eine klare Governance (wer darf Alerts einsehen? wie reagieren?), können aber als zusätzliche Sicherheitsnetze dienen. Für kritische Branchen oder sehr große Firmen sind sie einen Blick wert.
• Geräte- und Anwendungsrichtlinien: Ergänzend zu den Cloud-Diensten sollten Sie auch Endgeräte und Apps im Griff haben. Mit Intune (Endpoint Manager) setzen Sie Device Compliance durch (verschlüsselter Speicher, Passwortschutz auf Smartphones, Remote-Wipe bei Verlust etc.). Und über Defender for Cloud Apps (ehemals Cloud App Security) können Sie Cloud-Zugriffe überwachen – z.B. erkennen, wenn jemand unerlaubt Dateien zu Dropbox hochlädt, und alarmieren/blocken. Diese Maßnahmen schließen den Kreis, damit Daten nicht an der M365-Plattform vorbei entweichen.
• Compliance Manager & Score: Zu guter Letzt sei nochmal der Microsoft Purview Compliance Manager erwähnt. Er ist kein direktes Schutz-Tool, aber ein Planungs- und Tracking-Tool. Er listet empfohlene Controls auf (basierend auf Regelwerken) und trackt, was Sie schon umgesetzt haben. Daraus ergibt sich ein Compliance Score, der zumindest intern ein Gefühl gibt, wo Sie stehen. Ich nutze den Compliance Manager gerne als „Checkliste“ in Projekten, aber mit Vorsicht: Nicht jeder hohe Score heißt, dass man safe ist – und ein niedriger Score heißt nicht automatisch Desaster. Nutzen Sie ihn als Kompass, nicht als Cockpit-Höhenmesser.

Wie man sieht, M365 hat die technischen Mittel im Werkzeugkasten. Die Kunst besteht darin, die richtigen Tools zur richtigen Zeit zu nutzen und sie auf Ihre Policies zuzuschneiden. Und dabei immer die Nutzer im Blick zu haben: Jede technische Maßnahme sollte zwar konsequent sein, aber nicht unnötig die Arbeit blockieren. Sonst wird aus Compliance schnell „Shadow-IT-Förderungsprogramm“. 😉

Dokumentation & Auditierung

Ein Spruch aus der Revision: „Was nicht dokumentiert ist, hat nicht stattgefunden.“ Für Compliance heißt das: Führen Sie Nachweise darüber, was Sie tun. Technische Maßnahmen allein reichen nicht – Sie müssen sie auch belegen und gegenüber Prüfern erklären können. Daher gehört zur M365-Compliance eine gehörige Portion Dokumentation und eine systematische Auditierung.

Was sollten Sie dokumentieren? Kurz gesagt: Alles Wichtige. Dazu zählen: – Richtlinien und Konzepte: Alle Unternehmens-Policies (wie oben beschrieben) sollten schriftlich vorliegen, versioniert und von der Geschäftsführung verabschiedet. Ebenso ein übersichtliches Compliance-Konzept für M365: darin steht, welche Maßnahmen Sie ergriffen haben (z.B. „Klassen Confidential und Secret mit Sensitivity Labels XYZ, DLP-Regeln für diese und jene Datentypen, etc.“). – Rollen & Zuständigkeiten: Halten Sie fest, wer welche Rolle innehat (z.B. ein Organigramm oder ein Responsibility-Assignment-Dokument für Compliance). Wenn morgen der Auditor fragt „Wer ist bei Ihnen für Datenschutz verantwortlich und wer administriert das System?“, zücken Sie das Dokument – zack, Frage beantwortet. – Risikobewertung: Dokumentieren Sie Ihre Risiko-Analyse (z.B. das Risiko-Register aus dem vorigen Kapitel). Es zeigt, dass Sie bewusst vorgegangen sind und Risiken kennen. Idealerweise steht da auch, welche Gegenmaßnahmen implementiert wurden und welcher Restrisikowert verbleibt. – System-Einstellungen & Änderungen: Führen Sie Protokoll über wichtige Compliance-relevante Einstellungen in M365. Beispiel: Wann wurde welche DLP-Regel aktiviert, von wem genehmigt? Welche Labels gibt es mit welchen Einstellungen? Das muss kein Roman sein – oft reichen Screenshots oder Exporte aus dem Compliance Center, abgelegt in einer Audit-Dokumentation. Microsoft Purview Compliance Manager kann hier helfen: Man kann Notizen hinzufügen, welche Maßnahmen umgesetzt wurden. – Schulungsnachweise: Wenn Mitarbeiter geschult wurden (Security Awareness, Datenschutz-Schulungen etc.), dokumentieren Sie Teilnehmerlisten, Daten und Inhalte. Sollte es jemals zu einem Vorfall kommen, können Sie zeigen: „Unsere Leute wurden sensibilisiert, siehe Nachweis vom xx.xx.2025.“ – Verarbeitungsverzeichnis: Gerade für DSGVO ein Muss – das Verzeichnis aller Verarbeitungstätigkeiten. Stellen Sie sicher, dass die Nutzung von Microsoft 365 dort sauber beschrieben ist (Kategorien von Daten, Zweck, Aufbewahrung, Rechtsgrundlage…). Ein DSB-Thema, aber als IT muss man zuliefern. – Notfallprozedere: Halten Sie Incident-Response-Pläne schriftlich fest und üben Sie diese vielleicht sogar (Stichwort: Planspiel „Datenpanne“). Im Ernstfall können Sie dann nachweisen, dass Sie vorbereitet waren und gemäß Plan gehandelt haben.

Neben der Dokumentation ist die Auditierung zentral. Planen Sie regelmäßige Compliance-Reviews oder Audits ein. Das kann die interne Revision übernehmen oder externe Auditoren, je nach Bedarf. Ziel ist, unabhängig zu prüfen: Sind die Richtlinien eingehalten? Greifen die Kontrollen? Wird geloggt, was geloggt werden soll? Werden unwirksame Maßnahmen identifiziert und verbessert?

Ich empfehle, mindestens jährlich einen Compliance-Audit für M365 durchzuführen – ruhig als freundschaftliche Überprüfung, nicht als Suche nach dem Schuldigen. Idealerweise wird ein Auditbericht erstellt mit Feststellungen und Maßnahmen. Das zeigt gegenüber Geschäftsführung und ggf. Aufsichtsbehörden, dass Sie aktive Kontrolle über das Thema haben.

Praxis-Kasten: So mache ich das in Projekten
Oft werde ich gefragt, ob ich bei Audits „dabei sein“ kann. Absolut – ich begleite gerne als Übersetzer zwischen IT und Prüfer. In einem Projekt haben wir vor dem offiziellen Audit einen Mock-Audit gemacht: Ich habe den strengen Prüfer gespielt, Fragen gestellt, Unterlagen sehen wollen. Ergebnis: leichte Panik beim Team („Oh, das haben wir gar nicht dokumentiert!“), aber genau das war der Zweck. Wir haben in der Generalprobe die Lücken entdeckt und gefüllt. Beim echten Audit gab’s dann viel Lob für die vorbildliche Dokumentation. Mein Tipp: Sehen Sie Audits nicht als Bedrohung, sondern als Chance, Schwachstellen zu finden, bevor es ein echter Gegner tut.

Fazit: Führen Sie Buch über Ihre Compliance-Aktivitäten. Und prüfen Sie sich regelmäßig selbst. So sind Sie jederzeit auskunftsfähig – sei es gegenüber dem Wirtschaftsprüfer, der Datenschutzaufsicht oder dem eigenen Vorstand. Ein gut dokumentiertes, auditierbares Compliance-Programm strahlt Professionalität aus und gibt allen Beteiligten (inklusive mir als Berater) ein gutes Gefühl.

Roadmap: Schritt-für-Schritt zur M365-Compliance

Der Weg zur M365-Compliance ist kein Sprint, sondern eher eine Wanderung mit Etappenzielen. Damit Sie nicht in die falsche Richtung laufen, skizziere ich hier eine Roadmap, die sich in der Praxis bewährt hat. Natürlich muss jeder die Schritte an seine Lage anpassen – aber die Grundidee bleibt: strukturierter Vorgehensplan statt planloser Aktionismus.

1. Kickoff & Scope festlegen: Bringen Sie alle Schlüsselpersonen an einen Tisch (virtuell oder real, Kaffee und Gipfeli in Zürich-Zeitzone schaden nie 😁). Im Kickoff klären wir: Was sind die Ziele? Welcher Bereich von M365 ist im Fokus (gesamtes Tenant vs. nur Teams/SharePoint etc.)? Wer sponsort das Ganze (hoffentlich jemand aus der Chefetage)? Und welche Ressourcen stehen zur Verfügung? Ergebnis dieses Schritts: Ein gemeinsames Verständnis und ein grober Projektauftrag. Ohne diesen Schulterschluss würde ich gar nicht erst loslaufen.
2. Ist-Analyse & Anforderungen: Nun schauen wir, wo wir stehen. Welche Compliance-Maßnahmen sind vielleicht schon eingerichtet (manchmal gibt’s ja doch ein paar Richtlinien oder Logs)? Wo drückt der Schuh am meisten? Parallel sammeln wir die Anforderungen: aus den Regelwerken (Kapitel 2), von den Stakeholdern (Fachbereiche, DSB, IT). Hier kann der Compliance Manager Score eine erste Orientierung geben, aber wichtiger ist der menschliche Blick: Haben wir schon DSGVO-Beschwerden gehabt? Gab es fast-Datenpannen? Was fordert die interne Revision dringend ein? Am Ende wissen wir, welche Lücken es gibt und was besonders kritisch ist.
3. Planung & Konzeption: Auf Basis der Anforderungen entwerfen wir das Compliance-Konzept. Welche Richtlinien brauchen wir (oder müssen aktualisiert werden)? Welche technischen Maßnahmen wollen wir einsetzen? Hier entsteht unser „Masterplan“. Wichtig: Prioritäten setzen! Nicht alles geht auf einmal. Ich teile gern in Wellen ein: Erst die Basics (z.B. Audit-Log an, MFA für alle, wichtigste Policies schreiben), dann fortgeschrittene Sachen (DLP feinjustieren, Labels einführen), zum Schluss Nice-to-haves. Außerdem definieren wir Kennzahlen (KPIs), um später Erfolg zu messen. Dieses Konzept sollte abgesegnet werden (durch Lenkungsausschuss oder den Chef) – dann hat man Rückendeckung.
4. Quick Wins umsetzen: Jetzt wird’s konkret. In Phase 1 nehmen wir uns die Quick Wins vor – Maßnahmen, die wenig Aufwand, aber hohen Impact haben. Beispiele: Audit-Logging aktivieren (falls noch aus), MFA überall durchsetzen, kritische Administratorrollen absichern (PIM einrichten), vielleicht schon Standard-DLP-Richtlinien für offensichtliche Dinge (Kreditkartendaten) einschalten. Auch organisatorisch: direkt mal alle Mitarbeiter auf ein kurzes „Security/Compliance Awareness“ Training schicken schadet nie. Diese Quick Wins geben Erfolgserlebnisse und reduzieren sofort gewisse Risiken.
5. Implementierung Kernmaßnahmen: In Phase 2 kommen die großen Brocken: Entwicklung von Klassifikationsschema und Ausrollen der Sensitivity Labels, Einrichten von maßgeschneiderten DLP-Regeln für Ihre Daten (basierend auf der vorher erarbeiteten Policy), Aufbewahrungsrichtlinien definieren und im Compliance Center konfigurieren, eventuell Aufbau von eDiscovery-Fällen und Prozessen. Das ist der Hauptteil des Projekts, oft iterativ: man richtet etwas ein, testet, passt an. Ich empfehle, Änderungen zunächst mit einer begrenzten Gruppe zu pilotieren (z.B. IT-Dept oder ein „Compliance Champion“-Team), bevor man es global ausrollt. Nichts ist schlimmer, als wenn eine neue Policy plötzlich den halben Vertrieb lahmlegt, weil etwas übersehen wurde.
6. Rollout, Schulung & Change Management: Sobald die Kernmaßnahmen technisch stehen, geht’s an die breite Einführung in der Organisation. Die besten DLP-Regeln nützen nichts, wenn alle sie umgehen, weil keiner kapiert hat, warum plötzlich E-Mails blockiert werden. Also: Kommunikation, Kommunikation, Kommunikation! Erklären Sie den Nutzern die neuen Klassifizierungslabels (z.B. mit einer schönen Guideline oder kurzen Video-Tutorials), schulen Sie die Support-Teams, damit sie Anwenderfragen beantworten können („Warum darf ich dieses Dokument nicht teilen?“). Celebrate Erfolge: „Wir haben jetzt 0 kritische Datenpannen in 3 Monaten – danke fürs Mitmachen!“. In dieser Phase begleite ich gern eng, um Feedback der User aufzunehmen und in Feinjustierungen einfließen zu lassen. Change Management ist die Geheimzutat, damit Compliance nicht als Alien-Eindringling gesehen wird, sondern als gemeinsames Unternehmensziel.
7. Betrieb etablieren & Übergabe: Die letzten Projektmeter: Wir integrieren Compliance in den Regelbetrieb. Das heißt, Verantwortlichkeiten werden nun „leben” gelassen (das RACI wird Realität), Monitoring wird auf Dauerschleife geschaltet (wer schaut sich welche Reports regelmäßig an?), ein Prozess für Ausnahmen oder Freigaben wird definiert (z.B. was tun, wenn jemand eine legitime Mail schicken muss, die DLP sonst blocken würde?). Zudem ziehen wir Bilanz: Haben wir die KPI-Ziele erreicht? Wo gibt es noch offene Baustellen? Oft erstelle ich am Projektende einen Compliance-Handbuch oder Abschlussbericht, der alles zusammenfasst – dieser wird an das Betriebsteam übergeben. Damit ist klar: Das Projekt ist abgeschlossen, und M365-Compliance geht ins Tagesgeschäft über.

Diese Roadmap dauert je nach Unternehmensgröße und Umfang einige Wochen bis mehrere Monate. Wichtig ist, dass Sie die Reihenfolge sinnvoll gestalten und das Tempo an Ihre Organisation anpassen. Agil vorgehen schadet nicht: Liefern, lernen, nachjustieren. Compliance ist kein Einmal-Projekt, sondern ein kontinuierlicher Prozess – aber dazu gleich mehr im Thema Governance. Mit dieser strukturierten Umsetzung stellen Sie sicher, dass nichts Wesentliches vergessen wird und alle Beteiligten Schritt für Schritt mitkommen.

Governance & Betrieb

Nach dem Projekt ist vor dem Betrieb. Governance bedeutet in diesem Kontext: das dauerhafte Verankern von Compliance im Tagesgeschäft. Es reicht nicht, einmal alles einzurichten – man muss auch dafür sorgen, dass die Regeln eingehalten und die Prozesse gelebt werden. Wie schafft man das?

Wichtig ist zunächst ein Gremiummodell oder zumindest klare Verantwortlichkeiten für den laufenden Betrieb. Viele Unternehmen richten einen Compliance-Lenkungsausschuss oder regelmäßigen Jour fixe ein, in dem IT, Security, Datenschutz und ggf. weitere zusammenkommen. Dort werden z.B. Vorfälle besprochen, Änderungen an Richtlinien genehmigt oder neue Anforderungen diskutiert. Das muss kein bürokratisches Monster sein – ein einstündiges Meeting pro Quartal kann schon reichen, solange die richtigen Leute teilnehmen.

Dann braucht es feste Betriebsprozesse: – Incident-Management: Wenn ein Compliance-Verstoß passiert (z.B. jemand hat sensible Daten falsch geteilt), wie läuft die Meldung und Bearbeitung? Gibt es ein festgelegtes Verfahren, wer informiert wird (DSB, CISO, Management) und wie man reagiert (sofortige Bereinigung, Meldung an Behörden innerhalb 72h etc.)? Diese Abläufe sollten definiert und bekannt sein. – Change Management: Jede Änderung in der M365-Umgebung, die Compliance tangiert, sollte bewertet werden. Beispiel: Neue Teams-App integrieren – birgt das Risiken? Oder Änderung einer DLP-Regel – wer muss zustimmen? Verankern Sie in Ihrem Change-Prozess entsprechende Prüfschritte („Hat Compliance zugestimmt?“) damit nicht aus Versehen jemand Ihre schöne Konfiguration aushebelt. – Zugriffs- & Berechtigungsmanagement: Im Betrieb sollte etabliert sein, dass z.B. alle 6 Monate ein Berechtigungsreview stattfindet (Fachabteilungen checken, ob ihre Team-Sites noch korrekt berechtigt sind). Oder dass bei Mitarbeiterwechseln (Onboarding/Offboarding) die entsprechenden Compliance-Maßnahmen greifen: neuen Mitarbeiter gleich Schulung + passenden Gruppen zuordnen; bei Austritt alles entziehen, Inhalte ggf. archivieren etc. Solche operativen Themen klingen banal, sind aber essenziell, um „dranzubleiben“. – Monitoring-Routine: Jemand (oder ein Team) muss die definierten KPIs und Reports auch wirklich anschauen. Legen Sie fest, wer z.B. wöchentlich die DLP-Vorfallsliste prüft, wer monatlich die Compliance Score-Änderungen bewertet, wer quartalsweise die Audit-Logs nach Auffälligkeiten scannt. Und falls eine Kennzahl aus dem Ruder läuft (z.B. plötzlich 50 GDPR Incidents in einem Monat), braucht es einen Prozess: Eskalation an das Gremium oder an den Verantwortlichen, Ursachenanalyse, Maßnahmen einleiten.

Governance heißt auch, Compliance in die Unternehmensführung einzubetten. Berichten Sie wichtige Compliance-Kennzahlen regelmäßig an Management oder den Aufsichtsrat, je nach Organisationsstruktur. So bleibt das Thema sichtbar und bekommt Rückendeckung – niemand soll sagen können „Davon haben wir oben nie etwas gehört“.

Kurz gesagt: Im Betrieb muss es Rollen, Meetings und Prozesse geben, die sicherstellen, dass die schöne neue Compliance-Welt nicht langsam verstaubt oder umgangen wird. Hier trennt sich die Spreu vom Weizen: Unternehmen, die Governance ernst nehmen, bleiben compliant; andere erleben oft nach einem Jahr ein böses Erwachen, wenn die ersten Maßnahmen verpufft sind.

Kontinuierliche Verbesserung

Stillstand ist Rückschritt – das gilt besonders für Compliance. Kontinuierliche Verbesserung (Continuous Improvement) sollte Teil Ihres Programms sein. Die Rahmenbedingungen ändern sich ständig: Neue gesetzliche Vorgaben (morgen vielleicht strengere KI-Regeln, übermorgen irgendwas mit Quantum Computing, wer weiß), neue Features in Microsoft 365 (jede Woche ein neues Purview-Tool?), veränderte Geschäftsprozesse im Unternehmen. Deshalb ist ein Mechanismus nötig, um regelmäßig zu prüfen und anzupassen.

Ein bewährter Ansatz ist der PDCA-Zyklus (Plan-Do-Check-Act): – Plan: Neue Anforderungen identifizieren, Verbesserungsmaßnahmen planen (z.B. „Wir sollten die Communication Compliance einführen, weil wir festgestellt haben, dass…“). – Do: Umsetzung dieser Änderungen im kleinen Rahmen ausprobieren. – Check: Wirksamkeit prüfen – hat die Maßnahme das gewünschte Ergebnis gebracht? Gibt es Nebenwirkungen? – Act: Überführen in den Regelbetrieb und Standard, oder ggf. verwerfen, wenn es nicht taugt.

Ich empfehle, mindestens jährlich einen Compliance-Review zu machen, besser halbjährlich. In diesem Review geht man das gesamte Compliance-Setup durch: Stimmen die Policies noch? Gab es Änderungen in den Rechtsgrundlagen? Hat Microsoft neue Sicherheitsfunktionen, die wir nutzen sollten (oder alte, die abgekündigt wurden)? Wie entwickeln sich unsere KPIs – sind Ziele vielleicht zu leicht erreicht (dann kann man den Standard erhöhen) oder utopisch (dann pragmatisch anpassen)? Auch die Risiko-Bewertung aus Kapitel 3 sollte man hierbei neu bewerten: Vielleicht ist ein Risiko gesunken, dafür ein neues aufgetaucht.

Praxis-Kasten: So mache ich das in Projekten
Bei allen meinen Kunden vereinbare ich eine Nachbetreuung: Oft komme ich nach ~6 Monaten für einen „Check-up“ vorbei. Das ist kein aufdrängter Servicevertrag, sondern schlicht ein gemeinsamer Workshop-Tag, an dem wir schauen, was gut läuft und wo nachgesteuert werden muss. In einem Fall bemerkten wir z.B., dass trotz Schulung immer noch 30% der Dokumente unlabeled waren – Grund: ein bestimmter Bereich nutzte eine Spezial-App, die keine Labels unterstützen konnte. Lösung: Wir haben für diesen Bereich einen Workaround geschaffen und das nächste Training spezifischer gemacht. Solche Erkenntnisse bekommt man nur im laufenden Betrieb. Der Blick von außen hilft oft, betriebsblind gewordene Stellen aufzudecken.

Das Motto lautet: Dranbleiben! M365-Compliance ist kein Projekt mit Enddatum, sondern eine dauerhafte Aufgabe. Das heißt nicht, dass Sie permanent Feuerwehr spielen müssen – wenn alles gut eingerichtet ist, hält sich der Aufwand in Grenzen. Aber es erfordert ein Mindestmaß an Aufmerksamkeit. Sehen Sie es positiv: Durch kontinuierliche Verbesserung wird Ihr Compliance-Niveau mit der Zeit immer höher, und Audits oder Assessments verlieren ihren Schrecken, weil Sie ohnehin immer auf aktuellem Stand sind.

Wer weiß, vielleicht sind Sie in ein paar Jahren sogar Vorreiter und geben Best Practices an andere weiter. 😉 Aber selbst wenn nicht: Die Hauptsache ist, dass Sie Schritt halten mit Veränderungen und Ihr Compliance-System lebendig halten. Dann haben wir unser Ziel erreicht.

KPIs & Monitoring

Wie wissen wir, ob wir gut sind? Key Performance Indicators (KPIs) helfen dabei, den Erfolg unserer Compliance-Maßnahmen messbar zu machen. Im Eifer des Gefechts kann man sonst gar nicht sagen, ob sich all die Mühe lohnt. Also: Legen wir ein paar Kennzahlen fest und beobachten diese regelmäßig (Monitoring).

Typische Compliance-KPIs könnten sein:

KPI	Zielwert	Ist (Beispiel)
MFA-Abdeckung Mitarbeiter	100% (alle User mit Multi-Faktor auth.)	98% (Nov 2025)
Datenklassifizierungs-Quote	≥ 90% aller neuen Dateien/E-Mails gelabelt	85% (leicht steigend)
Kritische DLP-Vorfälle pro Quartal	< 5	2 (Q3 2025)
Durchschnittliche Reaktionszeit auf Incidents	< 24 Stunden bis Erstmaßnahme	Ø 12h (bei 3 Incidents)
Offene Audit-Feststellungen (hoch)	0	0
Microsoft Compliance Score	> 85%	82%

Dies sind Beispiele – Sie wählen KPIs passend zu Ihren Zielen. Der Compliance Score von Microsoft Purview ist bequem, aber ich würde immer auch eigene Metriken heranziehen, die Ihre spezifischen Risiken abbilden (z.B. DLP-Vorfälle, wenn Datenaustritt Top-Risiko ist).

Wichtig ist, dass jemand diese Zahlen überwacht und interpretiert. Eine Zahl allein sagt wenig – die Trends sind interessant. Steigt die Zahl der DLP-Vorfälle plötzlich an? Dann ggf. nachforschen: Haben wir neue Mitarbeiter, die ungeschult sind? Oder eine Regel zu lasch eingestellt? Sinkt der Compliance Score trotz mehr Maßnahmen? Vielleicht wurden neue Kontrollfragen hinzugefügt, die wir noch nicht bearbeitet haben – kein Grund zur Panik, aber ein Hinweis.

Ein Tipp: Bereiten Sie die KPIs anschaulich auf, z.B. als kleines Dashboard im Intranet oder für Management-Meetings. Viele nutzen Power BI oder Excel, um monatlich einen Compliance-Statusbericht zu erzeugen. Darin könnten stehen: „Status Grün/Gelb/Rot“ für die Hauptkennzahlen, plus Highlights wie „Keine kritischen Incidents im letzten Quartal“ oder „DSGVO-Auskunftsanfragen alle fristgerecht erledigt“. Das zeigt, dass das Thema gemanagt wird.

Doch Achtung: KPIs sind Mittel zum Zweck, nicht Selbstzweck. Es geht nicht darum, schöne Zahlen zu produzieren, sondern darum, echte Sicherheit und Regelkonformität zu erreichen. Wenn eine Zahl dauerhaft vom Ziel abweicht, nutzen Sie es als Lernchance: Ziel realistisch anpassen oder Maßnahmen verstärken. Und wenn alle Zahlen grün sind: Super – aber bleiben Sie wachsam (oder erhöhen Sie die Messlatte 😉).

Letztlich geben KPIs Ihnen die Möglichkeit, Erfolge zu feiern („X Tage ohne Datenschutzvorfall!“) und Problemfelder früh zu erkennen. Damit sind sie unverzichtbarer Bestandteil des Compliance-Monitorings und ein gutes Kommunikationsmittel gegenüber dem Top-Management.

Checkliste: M365-Compliance umgesetzt?

Zum Schluss eine praktische Checkliste. Können Sie alle Punkte abhaken? Dann sind Sie auf einem sehr guten Weg! Nutzen Sie diese Liste gern, um den Fortschritt in Ihrem Projekt zu verfolgen:

• [ ] Regelwerke identifiziert & dokumentiert: Alle relevanten Gesetze, Standards und internen Vorgaben sind bekannt und als Anforderungen festgehalten.
• [ ] Rollen & Verantwortlichkeiten festgelegt: Es gibt klare Verantwortliche (Accountables) für alle Compliance-Bereiche und Aufgaben (RACI definiert).
• [ ] Risiko-Analyse durchgeführt: Mögliche Risiken in der M365-Nutzung wurden bewertet und ein Maßnahmenplan zur Risikominimierung ist erstellt.
• [ ] Richtlinien erstellt & veröffentlicht: Wichtige Policies (Datenschutz, Klassifizierung, Aufbewahrung, Zugriffsrechte, Nutzungsregeln etc.) sind schriftlich fixiert, von der Leitung genehmigt und allen Mitarbeitern bekannt.
• [ ] M365-Architektur geprüft: Tenant-Region passend gewählt, Datenverarbeitungsabkommen mit Microsoft geschlossen, Architektur berücksichtigt Compliance (z.B. separate Sites für kritische Daten, Admin-Beschränkungen, Logging).
• [ ] Technische Grundmaßnahmen aktiviert: Audit-Log an, MFA für alle User aktiviert, notwendige Lizenzen (E5/E5 Compliance Add-ons) beschafft für gewünschte Features.
• [ ] Sensitivity Labels implementiert: Klassifizierungsschema in M365 abgebildet, Labels verteilt und Benutzer wissen, wie sie diese anwenden.
• [ ] DLP-Policies eingerichtet: Relevante DLP-Regeln aktiv (E-Mail, SharePoint/OneDrive, Teams), getestet und optimiert auf wenige False Positives.
• [ ] Retention Policies aktiv: Aufbewahrungsrichtlinien für wichtige Daten (Emails, Dateien, Teams-Chats etc.) entsprechend der Vorgaben konfiguriert.
• [ ] eDiscovery/Legal Hold vorbereitet: Verantwortliche kennen das Vorgehen, Legal Hold für relevante Postfächer bei Bedarf eingerichtet, eDiscovery-Fall angelegt (ggf. testweise).
• [ ] Schulung & Awareness durchgeführt: Mitarbeiter wurden über neue Richtlinien und Tools informiert, Schulungen (z.B. Datenschutz, Umgang mit Klassifizierung) sind erfolgt; neue Mitarbeiter erhalten Onboarding zu diesen Themen.
• [ ] Monitoring & KPIs etabliert: Kennzahlen definiert (z.B. DLP-Vorfälle, Label-Abdeckung, Compliance Score), Dashboard/Reports eingerichtet, Verantwortliche für Auswertung benannt.
• [ ] Dokumentation vollständig: Alle oben genannten Punkte sind nachvollziehbar dokumentiert (Policies, Protokolle, Berichte, Nachweise); ein Audit könnte kommen, ohne dass Hektik ausbricht.
• [ ] Governance im Alltag verankert: Regelmäßige Meetings oder Abstimmungen zu Compliance finden statt, es gibt einen Prozess für Incidents und Änderungen, das Thema hat einen festen Platz in der Organisation.
• [ ] Kontinuierliche Verbesserung läuft: Geplante Reviews/Audits terminiert (mind. jährlich), Feedback-Schleifen eingerichtet, Change-Management greift bei Neuerungen.

Wenn Sie hier fast überall einen Haken setzen können – Glückwunsch! Dann haben Sie M365-Compliance wirklich „in der Praxis“ umgesetzt. Fehlende Haken zeigen, wo Sie noch nachlegen sollten. Aber kein Stress: Rom wurde auch nicht an einem Tag gebaut. Wichtig ist, die Liste im Blick zu behalten und Schritt für Schritt abzuarbeiten.

FAQ – Häufige Fragen aus der Praxis

Was versteht man unter „M365-Compliance“?
Unter M365-Compliance verstehe ich die Gesamtheit aller Maßnahmen, um Microsoft 365 rechtskonform und sicher zu betreiben. Es geht darum, die einschlägigen Gesetze (z.B. Datenschutz), Standards und Unternehmensrichtlinien innerhalb von Microsoft 365 umzusetzen – von Zugriffsschutz über Datenspeicherung bis zur Dokumentation. Kurz: dafür zu sorgen, dass Ihre Nutzung von Cloud-Services wie Exchange, SharePoint, Teams & Co. im Einklang mit den Regeln steht und Risiken minimiert werden.

Ist Microsoft 365 automatisch rechts- und datenschutzkonform, wenn wir es nutzen?
Nein, nicht automatisch. Microsoft 365 bietet zwar viele Compliance-Features und ist als Plattform nach diversen Standards zertifiziert (ISO 27001, etc.). Aber Sie als Kunde müssen es richtig konfigurieren und einsetzen. Beispiel: Microsoft stellt Werkzeuge für DSGVO-Bedürfnisse bereit, aber Sie müssen selbst dafür sorgen, dass z.B. sensible Daten getaggt werden, Aufbewahrungsfristen eingestellt sind und Zugriffe passend beschränkt werden. Microsoft liefert die „Compliance-Bauteine“, aber der Zusammenbau zur Konformität liegt in Ihrer Verantwortung.

Welche Gesetze und Standards sind für uns relevant?
Das hängt von Ihrer Branche und Region ab. Allgemein ist in der EU die DSGVO fast immer relevant (Datenschutz). Dazu kommen oft branchenspezifische Regelwerke: z.B. HGB, AO und GoBD (für Aufbewahrung finanzrelevanter Daten in DE), ISO/IEC 27001 (wenn Sie ein ISMS zertifizieren wollen), TISAX (Automotive), BAIT/VAIT (Banken/Versicherungen in DE), HIPAA (Gesundheitsdaten, falls US-Bezug) oder BSI-Grundschutz/IT-SiG bzw. NIS2 (bei Kritischer Infrastruktur). Auch interne Standards (Code of Conduct, Betriebsvereinbarungen) gehören dazu. Sie sollten also eine Liste aller externen und internen Vorgaben erstellen, die für Ihre Daten und Prozesse gelten. An dieser Liste richten Sie dann Ihr Compliance-Projekt aus.

Wer ist für die Compliance in M365 verantwortlich – die IT oder der Datenschutzbeauftragte?
Idealerweise arbeiten hier mehrere Rollen Hand in Hand. Die Gesamtverantwortung trägt am Ende die Geschäftsführung (sie haftet für Verstöße). Operativ sind aber IT-Leitung/CISO und Datenschutzbeauftragter wichtige Partner. Die IT kennt das System und setzt technische Maßnahmen um, der DSB kennt die Datenschutzvorgaben und prüft die Einhaltung. Oft bildet man ein Team oder Gremium, wo Security, Datenschutz, IT-Admin und evtl. Compliance Officer zusammenkommen. Wichtig: Nicht gegenseitig den Ball zuschieben, sondern gemeinsam tragen. Jeder hat seine Teilverantwortung (siehe RACI-Matrix im Artikel), aber nur zusammen wird ein rundes Ergebnis daraus.

Wie starte ich ein M365-Compliance-Projekt – gibt es einen ersten Schritt?
Erster Schritt: Awareness schaffen und Scope klären. Holen Sie alle relevanten Leute an einen Tisch (Management-Support einholen!) und definieren Sie, was erreicht werden soll (z.B. „DSGVO-Konformität für unsere M365-Daten herstellen“). Dann machen Sie eine Bestandsaufnahme: welche Policies und Einstellungen gibt es schon, wo sind die größten Lücken? Oft hilft es, einen Workshop zu machen, um Ziele, Risiken und grobe Maßnahmen zu sammeln. Daraus entsteht ein Plan (Roadmap). Also kurz gesagt: Kickoff mit den Stakeholdern, Ist-Analyse, Ziele definieren – dann kann’s ins Eingemachte gehen.

Was ist der Microsoft Purview Compliance Manager und sollten wir ihn nutzen?
Das ist ein Tool im Microsoft Purview Compliance Portal, das Ihnen bei der Verwaltung von Compliance-Anforderungen hilft. Er enthält Vorlagen für diverse Regelwerke (DSGVO, ISO etc.) und eine Checklisten-Ansicht mit „Verbesserungsmaßnahmen“. Sie können abhaken, was Sie schon umgesetzt haben, Dokumente hochladen und Verantwortliche zuweisen. Daraus errechnet sich ein Compliance Score in Prozent. Nutzen: Man behält den Überblick, was noch zu tun ist, und bekommt Empfehlungen. Aber Achtung: Der Compliance Manager ist kein Ersatz für Nachdenken. Man sollte ihn als Hilfsmittel sehen – er deckt nicht jede firmenspezifische Nuance ab. Ich nutze ihn gerne zu Projektbeginn (für Gap-Analyse) und später, um Fortschritte zu tracken. Also ja, schauen Sie ihn sich an. Er ist in den meisten M365-Plänen enthalten (für manche Templates braucht man aber Premium-Lizenzen).

Brauchen wir eine E5-Lizenz für Compliance-Funktionen in M365?
Nicht unbedingt für alle, aber für manche fortgeschrittenen Funktionen ja. Viele Basisfunktionen (Audit-Log, grundlegende DLP, einfache Retention Policies, Sensitivity Labels mit manuellem Setzen) gibt es schon in Microsoft 365 E3. Die E5 Compliance-Lizenz (bzw. Add-On) bietet zusätzlich z.B. Advanced Audit (längere Log-Aufbewahrung), automatisch angewandte Labels via AI, erweitertes eDiscovery (eDiscovery Premium), Insider Risk Management, Communication Compliance und mehr vorkonfigurierte DLP-Patterns. Ob Sie das brauchen, hängt von Ihrem Risiko und Budget ab. Mein Rat: Starten Sie mit dem, was Sie haben (oft E3), und wenn Sie an Grenzen stoßen (z.B. „Wir bräuchten die Logs länger als 90 Tage“), können Sie gezielt auf E5 (ganz oder teilweise für bestimmte User) upgraden. Microsoft bietet auch Standalone-Addons für vieles. Fazit: E5 ist nett, aber kein Muss für grundlegende Compliance.

Wie hilft Microsoft 365 konkret bei der DSGVO-Einhaltung?
M365 bringt einige Werkzeuge und Vertragszusagen mit, um DSGVO umzusetzen. Beispiele: – Auftragsverarbeitung: Microsoft stellt einen standardisierten AV-Vertrag bereit, der die DSGVO-Anforderungen abdeckt (inkl. EU-Standardvertragsklauseln für internationale Datenflüsse). – Datenspeicherorte: Sie können Ihre Hauptdaten innerhalb der EU speichern lassen, was für den DSGVO-Grundsatz der Datensparsamkeit und lokalen Verarbeitung wichtig ist. – Betroffenenrechte: Mit eDiscovery und Content Search können Sie Daten exportieren, um z.B. Auskunftsanfragen zu erfüllen. Mit dem Datensubjekt-Anfragen-Tool (DSR) im Compliance Center können Sie solche Anfragen verwalten. – Löschung personenbezogener Daten: Über Retention Policies und das Löschen via Content Search können Sie Daten auf Anforderung entfernen (Recht auf Vergessenwerden), soweit keine Aufbewahrungspflicht entgegensteht. – Transparenz & Dokumentation: Audit-Logs liefern Nachvollziehbarkeit, und Sie können im Compliance Manager Ihre DSGVO-Maßnahmen dokumentieren.

Natürlich müssen Sie diese Features auch aktiv nutzen. Microsoft 365 nimmt Ihnen nicht alle Pflichten ab (z.B. die Pflicht, Betroffene zu informieren oder ein Verzeichnis zu führen), aber es bietet Tools, um die meisten technischen/organisatorischen Anforderungen zu erfüllen.

Wo liegen unsere Microsoft-365-Daten – in der EU oder außerhalb?
Standardmäßig werden die Kern-Daten (Exchange Mails, SharePoint/OneDrive Dateien, Teams Chats) in der geo-Region gespeichert, die Ihr Tenant zugewiesen hat. Wenn Sie z.B. bei der Einrichtung „Europa“ gewählt haben, liegen die Daten in europäischen Rechenzentren (Dublin, Amsterdam etc., bei deutschem Tenant teilweise Frankfurt/Berlin). Microsoft gibt an, alle neuen Kunden in der EU auch in EU Datacentern zu halten. Allerdings können gewisse Metadaten oder weniger kritische Daten (wie Telemetrie, Service Logs) global verarbeitet werden. Microsoft arbeitet am EU Data Boundary, um noch mehr in EU zu halten. Wichtig: Wenn Sie spezifische Anforderungen haben (etwa Schweiz: Daten müssen in CH sein), gibt es dafür lokale Angebote oder Multi-Geo. Grundsätzlich kann man aber sagen: Ja, Ihre Hauptdaten liegen in der EU, sofern so konfiguriert. Für Details kann man die Microsoft-Dokumentation oder das Trust Center konsultieren. Im Zweifel: im Admin Center unter „Datenspeicherorte“ nachsehen – dort steht recht genau, was wo liegt.

Müssen wir mit Microsoft einen Auftragsverarbeitungsvertrag (AVV/DPA) abschließen?
Ja, und das passiert in der Regel automatisch durch die Online Services Terms von Microsoft. Sobald Sie M365 nutzen (und bezahlen), haben Sie den Microsoft-Standard-AV-Vertrag akzeptiert, der Bestandteil des Vertrags ist. In Deutschland fordern viele Datenschutzbehörden, dass man diesen AVV ausdruckt und intern ablegt. Sie können im Microsoft 365 Admin Center unter Datenschutz die Vertragsdokumente einsehen (Stichwort „DPA“ oder deutsch AVV herunterladen). Also: Ja, es gibt einen gültigen Vertrag zur Auftragsverarbeitung mit Microsoft als Auftragsverarbeiter. Stellen Sie sicher, dass Ihre Rechtsabteilung/DSB den vorliegen hat. Und überprüfen Sie auch, ob eventuelle Zusatzvereinbarungen nötig sind (z.B. falls Sie in sehr reguliertem Bereich sind, gab es früher die Möglichkeit, EU-Modellklauseln separat zu zeichnen – mittlerweile ist das aber inkludiert).

Wie verhindern wir Datenlecks in M365 am effektivsten?
Kombination aus Technik und Training. Technisch: Setzen Sie DLP-Richtlinien ein, um das versehentliche Versenden sensibler Daten zu stoppen (z.B. automatische Erkennung von Kundenlisten, die nach extern gehen). Nutzen Sie Sensitivity Labels, um den Zugriff auf vertrauliche Dokumente einzuschränken (z.B. kein externer Zugriff erlaubt). Stellen Sie Sharing-Einstellungen restriktiv ein (standardmäßig Links nur intern, externe Freigaben nur gezielt). Und erzwingen Sie MFA sowie sichere Geräte, damit kein Unbefugter zugreift.
Organisatorisch: Schulen Sie Mitarbeiter, was sie teilen dürfen und was nicht. Etablieren Sie eine Kultur des „Im Zweifel nachfragen“. Manche Firmen führen auch Fake-Datenleck-Tests durch (ähnlich Phishing-Tests) – muss man abwägen.
Wichtig: Absolute Sicherheit gibt es nicht. Aber mit DLP + Labels + Bewusstsein bekommen Sie 90% der typischen Datenlecks in den Griff. Und für den Rest hilft ein klarer Incident-Plan.

Wie richten wir eine Informationsklassifizierung und Labels in M365 ein?
Schritt 1: Klassifizierungsschema festlegen (das ist eine Policy-Aufgabe). Typischerweise 3-4 Stufen definieren (z.B. Öffentlich, Intern, Vertraulich, Streng Vertraulich) mit Kriterien und Beispielen.
Schritt 2: Sensitivity Labels erstellen im Purview Compliance Portal entsprechend dieser Stufen. Bei jeder Label können Sie einstellen, was passieren soll: z.B. ab Stufe Vertraulich Verschlüsselung erzwingen, bestimmte Wasserzeichen, oder Einschränkungen (nicht extern freigeben etc.).
Schritt 3: Publish Labels: Die Labels müssen in Label Policies veröffentlicht werden an die Benutzer bzw. Locations (z.B. alle Benutzer können die Standard-Labels nutzen; besonders hohe Labels nur bestimmten Gruppen zugänglich machen, falls nötig).
Schritt 4: Schulung & Rollout: Den Usern erklären, dass es diese Labels jetzt gibt und wie sie sie anwenden (z.B. ein Pop-up in Office zeigt ja die Labels an). Evtl. mit Testläufen beginnen: ein paar Pilotanwender, Feedback einsammeln.
Schritt 5: Automatisierung (optional): Falls Sie E5 haben, können Sie Auto-Label-Policies einrichten, die z.B. Dokumente mit bestimmten Mustern automatisch als „Vertraulich“ labeln. Das aber erst tun, wenn man sicher ist, dass das Schema passt – sonst labelt die KI fröhlich Dinge falsch.

In Summe: Konzept ausarbeiten, technische Labels konfigurieren, breit ausrollen, Feedback justieren. Planen Sie dafür ruhig ein paar Wochen ein. Es lohnt sich aber enorm, weil Labels die Basis für viele andere Controls (DLP, Verschlüsselung) sind.

Wie lange sollten E-Mails und Dokumente aufbewahrt werden?
Das hängt von rechtlichen Vorgaben und Ihren Geschäftsanforderungen ab. In Deutschland gibt es z.B. gesetzliche Aufbewahrungsfristen für steuerrelevante Dokumente (meist 6 oder 10 Jahre). Geschäftliche E-Mails können darunter fallen. Personalakten evtl. auch 10 Jahre nach Austritt (für eventuelle Rechtsansprüche). Andererseits verlangt die DSGVO, Daten nicht länger als nötig zu speichern.
Ein bewährter Ansatz: Machen Sie für jede Datenart eine Tabelle: Dokumenttyp vs. Aufbewahrungsdauer. Finanzdokumente 10 Jahre, normale Geschäfts-E-Mails 6 Jahre, rein Operatives evtl. 3 Jahre, Bewerberdaten 6 Monate etc. Der DSB und die Rechtsabteilung sollten das absegnen. Diese Zeiten setzen Sie dann in M365 als Retention Policies/Labels um.
Wichtig: „Für immer aufbewahren“ ist selten eine gute Idee (Ausnahme: spezielle Archive). Und „sofort löschen“ geht auch schief, wenn man es doch mal braucht. Also die goldene Mitte nach Vorschrift. Wenn unsicher: im Zweifel lieber konservativ etwas länger aufbewahren (sofern erlaubt), als zu früh löschen und dann fehlt was bei einer Prüfung.

Wie funktioniert eDiscovery und Legal Hold in der Praxis?
eDiscovery ist das Suchen und Aufbereiten von Daten für rechtliche oder regulatorische Zwecke. In M365 haben Sie das eDiscovery-Tool: Dort können berechtigte Personen (z.B. Rechtsabteilung) einen Fall anlegen, Suchkriterien definieren (z.B. alle E-Mails von Person X im Zeitraum Y mit Stichwort Z) und die Treffer exportieren.
Legal Hold (auch „Aufbewahrungssperre“) ist eine Funktion, mit der Sie sicherstellen, dass bestimmte Daten nicht gelöscht werden. Wenn z.B. ein Gerichtsverfahren läuft, setzen Sie alle relevanten Postfächer und Sites auf Hold. Dann greifen auch keine Retention-Policies oder Benutzeraktionen – die Daten bleiben unverändert erhalten, bis der Hold aufgehoben wird.
In der Praxis würden Sie bei einem konkreten Fall zuerst einen Hold einrichten (damit nichts verlorengeht), dann via eDiscovery die Daten sammeln. Wichtig: Halten Sie das Prinzip der Verhältnismäßigkeit ein – nur die wirklich relevanten Personen/Daten auf Hold setzen, sonst haben Sie unnötig alles eingefroren. Und achten Sie, dass Zugriffsrechte passen: eDiscovery-Manager darf viel sehen, das sollte auf wenige vertrauenswürdige Personen beschränkt sein.

Was tun wir, wenn es doch zu einem Compliance-Verstoß oder Data Breach kommt?
Ruhe bewahren und den Incident Response Plan aus der Schublade holen (hoffentlich haben Sie einen!). Konkret:
1. Identifizieren & Bewerten: Was ist passiert? Welche Daten sind betroffen? Ist es ein Datenschutzvorfall nach DSGVO-Definition (personenbezogene Daten betroffen und Risiko für Rechte der Personen)?
2. Sofortmaßnahmen: Schaden begrenzen. Z.B. bei geleakter Datei – Zugriff entziehen, Link ungültig machen. Bei kompromittiertem Account – Konto sperren, Passwort zurücksetzen.
3. Meldung intern: Informieren Sie das interne Krisenteam/Management, den Datenschutzbeauftragten und ggf. IT-Security. Transparenz intern ist wichtig.
4. Externe Meldung (falls nötig): Wenn DSGVO-relevant und Risiko für Personen besteht, innerhalb 72 Stunden Meldung an die Datenschutzaufsichtsbehörde. Evtl. auch Betroffene informieren (muss man abwägen, je nach Schwere). Bei anderen Compliance-Verstößen (z.B. Insiderhandel-Verdacht) ggf. Behörden oder Prüfer einschalten, je nach Rechtsgebiet.
5. Dokumentation: Alles protokollieren – was wurde wann entdeckt, was unternommen, wer informiert. Das brauchen Sie als Nachweis.
6. Learnings umsetzen: Nach der Akutphase eine Ursachenanalyse: Warum konnte das passieren? Müssen wir eine Policy anpassen, Schulung machen, technische Lücke schließen?

Je nach Art des Verstoßes ziehen Sie die entsprechenden Experten hinzu (Rechtsabteilung, Forensik etc.). Wichtig ist, einen kühlen Kopf zu bewahren und nach Plan zu handeln – Panik hilft nicht. Mit guter Vorbereitung (Übungen, klare Verantwortlichkeiten) lässt sich so ein Vorfall managen. Und danach: nicht Gras drüber wachsen lassen, sondern verbessern, damit es nicht nochmal passiert.

Wie schulen wir Mitarbeiter in Sachen Compliance effektiv?
Idealerweise kontinuierlich und praxisnah. Ein Pflichttraining einmal im Jahr ist ein Anfang (z.B. E-Learning oder Präsenz-Workshop zu Datenschutz und IT-Security-Grundlagen). Wichtiger ist aber die laufende Awareness:
– Machen Sie kurze Info-Happen im Intranet oder per Mail („Tipp der Woche: So erkennst du Phishing in Teams“).
– Führen Sie Phishing-Tests durch, um Security-Bewusstsein zu schärfen (und nachfassen bei denen, die reingefallen sind, aber ohne Pranger, eher hilfsbereit).
– Schulen Sie gezielt, wenn neue Tools eingeführt werden – z.B. wenn Sensitivity Labels neu sind, bieten Sie eine 15-Minuten-Demo für alle an oder erstellen Sie ein kurzes Erklärvideo.
– Fördern Sie eine Kultur, in der Fragen erlaubt sind. Nutzer sollen lieber einmal zu viel fragen „Darf ich das so?“, als unsicher etwas falsch machen.

Aus der Praxis: Gamification kann wirken – kleine Quiz, Wettbewerbe („Security-Champion des Monats“) – alles was das Thema etwas auflockert. Wichtig ist, dass Führungskräfte mitziehen: Wenn die Chefetage selbst auf Compliance achtet und das kommuniziert, nehmen Mitarbeiter es ernster. Schulung ist kein One-Time-Event, sondern ein Dauerthema, das ruhig kreativ und abwechslungsreich sein darf.

Wie messen wir, ob unsere Compliance-Maßnahmen wirken (Erfolgskontrolle)?
Über KPIs und Monitoring (siehe Kapitel zuvor). Setzen Sie sich Kennzahlen, die Erfolg greifbar machen: Anzahl Vorfälle, Durchlaufzeit von Anfragen, Prozentsatz gelabelter Daten etc. Dann tracken Sie diese über die Zeit. Wenn z.B. die Zahl der DLP-Vorfälle sinkt nach Einführung von Schulungen und Labels, ist das ein gutes Zeichen.
Auch qualitative Messungen: z.B. interne Audits ohne Feststellungen – top! Oder Mitarbeiter-Feedback: „Früher wusste ich nicht, was vertraulich ist, jetzt weiß ich es“.
Microsoft liefert mit dem Compliance Score auch einen groben Gesamtwert. Den können Sie als Trend nehmen: steigt von 50% auf 75% ist das Erfolg.
Wichtig ist, regelmäßig draufzuschauen (Monitoring-Routine). Ich mache gerne vierteljährlich einen Report mit den wichtigsten Kennzahlen und bespreche den im Team. So sieht man, wo’s klemmt oder ob Maßnahmen fruchten. Außerdem kann man Erfolge ans Management melden („wir haben das Risiko X um Y% reduziert“ – kommt immer gut an).

Wie oft sollten wir unsere Einstellungen und Policies überprüfen bzw. anpassen?
Laufend im Auge behalten und mindestens einmal im Jahr formell überprüfen. Die IT-Umgebung und die Bedrohungslage ändern sich ständig, ebenso die Rechtslage. Ich empfehle:
– einen jährlichen Compliance-Review (Audit) einplanen, wie in Governance beschrieben. Dabei alle Policies durchgehen: Sind sie noch aktuell? Jede technische Einstellung stichprobenartig checken (z.B. stimmen unsere DLP-Regeln noch mit dem überein, was die Policy will?).
– Zusätzlich bei großen Änderungen sofort: Neue Gesetzeslage (z.B. neues Urteil zur Datenübertragung) -> Policy anpassen. Microsoft führt neues Feature ein (z.B. Loop-Komponenten speichert was Neues in OneDrive) -> überlegen, ob das Policies tangiert.
– Und natürlich nach jedem relevanten Incident: Policy/Einstellung prüfen – hätte man das verhindern können, muss man etwas schärfen?

Praktisch hat sich ein Quartalsrhythmus bewährt für kleine Anpassungen und ein großer Rundumschlag einmal pro Jahr. Aber ehrlicherweise: Lieber on-the-fly anpassen, wenn etwas auffällt, als stur auf den Kalender warten. Agil bleiben.

Brauchen wir ein Backup unserer M365-Daten für Compliance-Zwecke?
Die Meinungen dazu gehen auseinander. Microsoft 365 hat eingebaute Redundanz und gelöschte Daten lassen sich über Versionierung/Recycle Bin eine Weile wiederherstellen. Für viele Compliance-Szenarien (Legal Hold, Retention) braucht man kein separates Backup.
Aber: Manche Unternehmen machen trotzdem Backups (über Drittanbieter-Tools), um z.B. E-Mails jahrelang in einem getrennten Archiv aufzubewahren oder um gegen versehentliche Massenlöschungen abgesichert zu sein, die außerhalb der Retention-Fristen passieren.
Aus Compliance-Sicht ist ein Backup nicht ausdrücklich vorgeschrieben. Es kann aber ein zusätzliches Sicherheitsnetz sein. Wichtig: Wenn Sie Backups ziehen, gelten auf diese Kopien natürlich dieselben Datenschutzregeln! Also nicht irgendwohin sichern ohne Schutz.
Mein Rat: Prüfen Sie, ob es konkrete Anforderungen gibt (z.B. „E-Mails müssen in einem revisionssicheren Archiv gemäß GoBD vorgehalten werden“ – das könnte über M365 allein schwierig sein, da dort gelöscht werden kann, wenn kein Hold). In solchen Fällen dann ein Journal-Backup oder Third-Party-Lösung erwägen. Ansonsten können Sie sich M365 anvertrauen – es hat z.B. 4-fache Datenreplikation. Für die meisten reicht das aus.

Können Microsoft-Mitarbeiter auf unsere Daten zugreifen (Stichwort Cloud-Admins bei MS)?
Microsoft gibt an, dass ohne Ihre Zustimmung kein Mensch auf Ihre Inhalte zugreift. Vieles ist technisch durch Prozesse und Verschlüsselung abgesichert. Administratoren von Microsoft haben nur in Ausnahmefällen Zugang und dann auch nur mit Zustimmung über das Customer Lockbox-Verfahren (falls Sie das aktiviert haben, müssen Sie Anfrage freigeben, bevor MS-Support auf z.B. ein Mailbox-Item darf). Außerdem sind Zugriffe protokolliert und reglementiert.
Trotzdem: absolute Kontrolle behalten Sie nur mit eigenem Schlüssel (Customer Key/Double Key), aber das ist wie gesagt aufwendig. In der Praxis vertraut man hier auf Microsofts Sicherheitsmaßnahmen und vertragliche Zusagen. Microsoft-Mitarbeiter werden außerdem intensiv geprüft und überwacht.
Kurz: Im Normalbetrieb hat kein MS-Admin etwas in Ihren Daten verloren. Bei Supportfällen könnte es vorkommen, aber auch dann meist beschränkt (die sehen z.B. vielleicht Meta-Daten oder müssen auf einen defekten Datensatz zugreifen). Durch strenge Prozesse (inkl. Vier-Augen-Prinzip bei MS) ist das Risiko sehr gering. Wenn es Sie beruhigt, aktivieren Sie Customer Lockbox, dann haben Sie noch ein Kontrollmoment.

Worin unterscheidet sich „Compliance“ von klassischer IT-Sicherheit?
IT-Sicherheit (Security) fokussiert auf den Schutz vor Bedrohungen (Hacker, Malware, unbefugter Zugriff). Compliance fokussiert darauf, dass Regeln und Vorgaben eingehalten werden. Natürlich gibt es große Überschneidungen: Zugriffsschutz ist sowohl Security- als auch Compliance-Thema (weil z.B. DSGVO verlangt „Stand der Technik“-Schutz). Aber Compliance geht darüber hinaus: Es umfasst auch Dinge wie „halten wir gesetzliche Aufbewahrungsfristen ein?“, „haben wir die Verarbeitung dokumentiert?“, „können wir nachweisen, dass wir Policy X eingehalten haben?“.
Ein Beispiel: Security fragt „ist die Tür abgeschlossen?“, Compliance fragt „soll die Tür vielleicht offen sein müssen für eine behördliche Prüfung, und haben wir ein Schild dran dass nur Befugte rein dürfen?“. Okay, das hinkt etwas 😅 – Im Grunde: Compliance ist breiter, es schließt Security mit ein, kümmert sich aber auch um rechtliche Aspekte und interne Governance. Ich sage gern: Security macht die Burg sicher, Compliance sorgt dafür, dass die Burg den königlichen Bauvorschriften entspricht und alle Auflagen erfüllt.

Ist Microsoft 365 für hochregulierte Branchen oder KRITIS geeignet?
Ja, aber mit Abstrichen und Aufwand. Viele Banken, Gesundheitsunternehmen und sogar Regierungsstellen nutzen Microsoft 365 – allerdings in der Regel mit strengen zusätzlichen Kontrollen. Microsoft bietet spezielle Clouds (Government Clouds in USA, für EU zwar keine separate Cloud aber deutsche Datentreuhand gab es mal früher). Für KRITIS-Betreiber in DE gelten besondere Anforderungen (BSI-KritisV etc.), die aber oft erfüllt werden können, wenn man M365 richtig konfiguriert und ggf. Zusatzmaßnahmen ergreift (z.B. SIEM-Anbindung, Notfallpläne, regelmäßige PenTests etc.).
Wichtig in regulierten Umfeldern ist die Beweisführung: Man muss jedem Auditor zeigen können, wie M365 abgesichert ist. Hier punkten Sie mit Dokumentation der Microsoft-Zertifizierungen (Trust Center) und Ihrer eigenen Maßnahmen. Und manchmal gibt es Detailanforderungen, wo man Workarounds braucht – z.B. komplette Netzabschottung (da muss man mit Conditional Access und eigenem Netzwerkdesign arbeiten).
Unterm Strich: Ja, es geht. Die Microsoft-Cloud ist ziemlich zertifiziert und robust. Aber Sie müssen sich auf intensivere Prüfungen einstellen und sollten ggf. externe Expertise hinzuziehen. Und bei KRITIS immer das BSI-Empfehlungswerk beachten – M365 kann Teil eines compliant Setup sein, aber eben nicht „einfach anknipsen und fertig“. Bisher habe ich aber noch keinen regulierten Kunden gesehen, der es bereut hätte – mit der richtigen Vorbereitung klappt es.

Welche typischen Stolpersteine gibt es bei der Umsetzung von M365-Compliance?
Oh, da gibt es einige Klassiker:
– Kein Rückhalt von oben: Wenn Geschäftsführung nicht wirklich hinter dem Projekt steht, geraten Policies schnell unter die Räder („Ach, schalte die DLP doch ab, das stört gerade den Vertrieb…“).
– Zu viel auf einmal wollen: Wenn man versucht, alle Features und Regeln gleichzeitig auszurollen, überfordert man Organisation und IT. Besser iterativ vorgehen (siehe Roadmap).
– Mangelnde Kommunikation: Plötzlich funktionieren für die User Dinge anders (Mail blockiert, Dokument verlangt Label) und keiner weiß warum – das erzeugt Frust und Umgehung. Transparenz und Schulung sind essenziell.
– Ignorieren der Fachbereiche: Compliance wird nur von IT/Security aus gedacht. Besser: die Daten-Eigentümer (Fachbereiche) einbinden, sonst passen die Richtlinien nicht zur Realität.
– Kein Monitoring: Maßnahmen einführen und dann nie draufschauen – man merkt gar nicht, wenn etwas nicht wirkt oder falsch konfiguriert ist.
– Dokumentationsfaulheit: Alles mündlich beschlossen, nichts schriftlich fixiert. Spätestens beim Personalwechsel oder Audit hat man ein Problem.
– Technische Tücken unterschätzen: Manche Features beeinflussen sich gegenseitig (z.B. Verschlüsselung vs. DLP-Scan). Da muss man sauber testen. Oder Lizenzlimits nicht beachten (Plötzlich sind nur 5 eDiscovery-Cases erlaubt und man braucht mehr – sowas vorher prüfen).
– User-Feedback ignorieren: Wenn Mitarbeiter sichere Workarounds suchen, weil Policies zu strikt sind, sollte man das ernst nehmen und nachjustieren. Sonst entsteht Schatten-IT.

Kurz: Meist sind es weiche Faktoren – Mensch, Prozess – nicht die Technik. Wenn man die genannten vermeidet, ist man schon auf gutem Weg.

Wie lange dauert es, bis wir M365-Compliance „durch“ haben?
Das variiert stark. Für ein mittelständisches Unternehmen (500 User) würde ich grob 3-6 Monate Projektzeit schätzen, um die wichtigsten Punkte umzusetzen – vom Kickoff bis zum Abschlussaudit. Größere Unternehmen brauchen eher 6-12 Monate, verteilt auf Phasen und mit Pilotprojekten. Kleinere können es in wenigen Wochen schaffen, wenn wenig Komplexität da ist. Aber: Wirklich „fertig“ ist man nie, weil sich ja ständig etwas ändert (siehe kontinuierliche Verbesserung).
Dennoch, man kann Meilensteine setzen: z.B. „Bis Ende Q2 haben wir DLP & Labels flächendeckend, bis Ende Jahr sind alle Audits bestanden“. So hat man ein greifbares Ziel.
Wichtig ist, realistisch zu planen und Puffer einzuplanen. Oft zieht sich die Abstimmung von Policies länger als gedacht (gerade mit Datenschutz und Betriebsrat ggf.). Oder technische Probleme tauchen auf. Daher lieber iterative Go-Lives machen (nicht alles auf letzten Drücker).
Mit externer Hilfe kann es schneller gehen, weil man typische Stolpersteine umschifft. Aber intern müssen die Leute trotzdem mitkommen, das braucht seine Zeit.
Also: Wochen bis Monate, je nach Ambition. Und danach geht die Reise weiter, nur entspannter, weil die Grundlage dann steht.

Was kostet die Umsetzung – womit müssen wir rechnen?
Kosten setzen sich aus ein paar Komponenten zusammen:
– Lizenzkosten: Evtl. brauchen Sie höherwertige Lizenzen oder Add-ons (z.B. für Advanced Compliance Features). Das kann pro Nutzer einige Euro mehr im Monat bedeuten. Das summiert sich je nach Nutzerzahl.
– Interner Aufwand: Ihre Mitarbeiter investieren Zeit (Workshops, Doku, Implementierung). Das sind Opportunitätskosten. Schwer in € zu beziffern, aber spürbar.
– Externe Beratung: Wenn Sie jemanden wie mich hinzuziehen, kommen Tagessätze ins Spiel. Ich z.B. arbeite mit 1.500 € pro Beratungstag (zzgl. MwSt). Ein Compliance-Startpaket (siehe unten) mit ein paar Tagen Aufwand bleibt also im einstelligen Tausenderbereich, während ein großes Projekt sich im höheren vier- bis fünfstelligen Bereich bewegen kann – je nach Umfang.
– Tools/Drittanbieter: Falls Sie Zusatzlösungen einsetzen (Backup-Lösung, spezielle Audit-Tools) kommen deren Kosten hinzu.

Unterm Strich: Für einen Mittelständler würde ich grob einige zehntausend Euro Gesamtkosten schätzen (verteilt über Projektlaufzeit), wenn externe Unterstützung dabei ist. Ohne externe Hilfe vor allem interne Personalkosten.
Wichtig ist, den Nutzen dagegen zu halten: Vermeidung von Datenschutzstrafen (könnten Millionen sein), keine Imageschäden, effizientere Prozesse. Das rechnet sich meist. Oft hilft es, in Paketen zu denken (siehe Beratungspakete unten), um klar zu budgetieren.
Natürlich mache ich hier keine verbindliche Kalkulation – jedes Projekt ist anders. Aber mit Transparenz und einem festen Tagessatz wissen Sie zumindest, womit Sie pro Tag externer Hilfe rechnen müssen.

Wer prüft unsere M365-Compliance eigentlich – kommt da jemand von außen?
Das kann unterschiedlich sein:
– Interne Revision: In vielen Firmen schaut die interne Revision oder der Compliance Officer regelmäßig drauf, ob IT-Vorgaben eingehalten werden. Die sind sozusagen „im Haus“, aber unabhängig von der operativen IT.
– Wirtschaftsprüfer: Bei Jahresabschlussprüfungen schauen sie manchmal auch auf IT-Controls (insb. wenn es um finanzrelevante Daten geht). Die könnten Fragen stellen wie „Wie stellen Sie sicher, dass Buchhaltungsdaten 10 Jahre aufbewahrt werden?“.
– Datenschutz-Aufsichtsbehörde: Im Falle einer Beschwerde oder stichprobenartig kann die Behörde prüfen, ob Sie DSGVO einhalten. Dann müssen Sie nachweisen, welche technischen und organisatorischen Maßnahmen Sie in M365 haben (da kommt dann alles oben Beschriebene ins Spiel).
– Zertifizierer/Auditoren: Wenn Sie z.B. ISO 27001 Zertifizierung anstreben, kommt ein externer Auditor und prüft Ihr ISMS – da wäre M365 ein Teil davon (Access Control, Logging etc. muss er sehen).
– Kunden/Auftraggeber: Gerade in B2B können große Kunden Audits bei Ihnen durchführen oder zumindest einen Fragenkatalog schicken („Bitte beantworten Sie, wie Sie O365 datenschutzkonform betreiben“). Da sollten Sie gut vorbereitet sein.
– Sie selbst: Nicht vergessen, die beste Prüfung ist die, die Sie selbst veranlassen – proaktiv als internes Audit (siehe oben). Dann sind die externen Prüfungen nur noch Formsache.

Also ja, jemand schaut bestimmt hin – die Frage ist nur wann und wer. Mit den Maßnahmen aus diesem Artikel sind Sie aber gewappnet, jedem Prüfer ruhig entgegenzutreten.

Beratungspakete

Zum Abschluss möchte ich Ihnen drei Beratungspakete vorstellen, die ich anbiete. Jedes Paket ist modular aufgebaut, klar umrissen und auf Ihre Bedürfnisse anpassbar. Die Devise: Beratung auf den Punkt – keine endlosen Bindungen, keine Übernahme von Betrieb, sondern gezielte Hilfe zur Selbsthilfe. (Tagessatz in allen Paketen: 1.500 € zzgl. MwSt., Reisekosten nach Aufwand separat.)

Compliance-Start

Für wen: Unternehmen, die am Anfang stehen oder einen kompakten Check-up wollen.
– Ziel: Schnelle Standortbestimmung und Umsetzung der wichtigsten Grundmaßnahmen. Am Ende wissen Sie, wo Sie stehen, und haben die größten Lücken geschlossen.
– Umfang: Typisch ca. 3–5 Beratungstage. Ein Kickoff-Workshop zur Anforderungsklärung, Durchsicht Ihrer aktuellen M365-Einstellungen, Identifikation von Quick Wins. Anschließend unterstütze ich bei der Umsetzung einiger Kernmaßnahmen (z.B. Audit-Log aktivieren, MFA einrichten, erste Richtlinien formulieren).
– Ergebnisse: Sie erhalten einen kompakten Bericht („Compliance-Start-Report“) mit Risikoübersicht, empfohlenen Maßnahmen und den bereits umgesetzten Quick Wins. Erste Policies sind erstellt oder aktualisiert, wichtige Security/Compliance-Features sind eingeschaltet. Außerdem: eine grobe Roadmap, wie es weitergehen könnte – entweder in Eigenregie oder mit weiterem Support.
– Aufwand: Ca. 5 Personentage (nach tatsächlichem Aufwand).
– Preis: ca. 5 * 1.500 € = 7.500 € (zzgl. MwSt.). Reisekosten werden separat nach tatsächlichem Aufwand abgerechnet.

Compliance-Pro

Für wen: Unternehmen, die das Thema systematisch angehen wollen – mittlere bis große Umgebungen, die mehrere Bereiche abdecken müssen.
– Ziel: Ganzheitliche Implementierung des Compliance-Programms in M365. Nach diesem Paket haben Sie ein umfassendes Set an Richtlinien und technischen Maßnahmen implementiert, das die wesentlichen Anforderungen erfüllt.
– Umfang: Typisch 10–15 Beratungstage, verteilt auf mehrere Wochen oder Monate (je nach Ihrem Tempo). Enthält Workshops zur Policy-Entwicklung (z.B. Klassifizierung, DLP-Strategie, Aufbewahrungsplan), intensive Hilfe bei der technischen Umsetzung (Konfiguration von Labels, DLP, Retention, Monitoring) und Begleitung beim Rollout (Schulungskonzepte, Kommunikation). Auch die Erstellung der nötigen Dokumentation (Richtliniendokumente, Betriebskonzepte) unterstütze ich. Wir machen mehrere Review-Schleifen und Tests, um sicherzustellen, dass alles funktioniert und von den Stakeholdern abgesegnet ist.
– Ergebnisse: Ein vollständiges Compliance-Framework in Ihrem M365-Tenant. Alle relevanten Policies sind live und veröffentlicht, Purview ist konfiguriert (Labels, DLP, etc.), Benutzer sind geschult, KPIs definiert und erste Reports laufen. Sie sind bereit für interne Audits und externe Prüfungen – und vor allem: Ihre Risiken sind deutlich reduziert. Sie erhalten einen ausführlichen Abschlussbericht inkl. aller vereinbarten Deliverables (Policy-Dokumente, Risikoregister, RACI, etc.).
– Aufwand: Je nach Umfang ca. 15 Personentage (kann variieren nach Bedarf).
– Preis: z.B. 15 * 1.500 € = 22.500 € (zzgl. MwSt.) bei 15 PT. Genauere Kalkulation erfolgt nach Absprache des genauen Leistungsumfangs.

Compliance-Enterprise / KRITIS

Für wen: Große Unternehmen, Konzerne oder KRITIS-Betreiber mit sehr hohen Compliance-Anforderungen, ggf. internationalen Rahmenbedingungen und Auditierungsdruck.
– Ziel: Maßgeschneiderte Compliance-Beratung auf höchstem Niveau. Dieses Paket zielt darauf ab, höchste Reifegrade zu erreichen – inklusive Integration in vorhandene Governance-Strukturen, Vorbereitung auf formale Zertifizierungen (ISO 27001 o.Ä.) oder strenge regulatorische Prüfungen (BSI, BaFin, etc.).
– Umfang: Ab 20 Beratungstagen aufwärts, typischerweise als längerfristige Begleitung in Phasen. Ich unterstütze bei der detaillierten Risikoanalyse nach anerkannten Methoden, beim Aufbau eines umfassenden Kontrollsystems (z.B. Mapping von M365-Controls zu Frameworks wie ISO oder NIST). Technisch werden alle fortgeschrittenen Features genutzt: z.B. Customer Key wenn nötig, Insider Risk Management, Integration mit SIEM, Automatisierungs-Workflows für Compliance (PowerPlatform). Ich arbeite eng mit Ihren internen Revision-/Security-Teams zusammen, evtl. auch mit externen Auditoren, um sicherzustellen, dass M365 lückenlos ins Gesamt-GRC passt.
– Ergebnisse: Ein absolut auditfestes M365-Setup. Sie bekommen eine lückenlose Dokumentation, die auch strengsten Prüfern standhält, inkl. z.B. Schutzklassen-Konzepte, Notfallpläne für M365, Testprotokolle (DR/BCP-Tests im O365-Kontext) und alles, was in Ihrer Branche erwartet wird. Ihr Team ist durch intensive Workshops befähigt, den Betrieb selbstsicher weiterzuführen. Bei Bedarf erstelle ich mit Ihnen zusammen Reports für Zertifizierungen oder Berichte an Behörden. Kurz: Sie erreichen einen Compliance-Zustand, der Benchmark-Charakter hat.
– Aufwand: Nach Vereinbarung, erfahrungsgemäß 20–40 Personentage über einen längeren Zeitraum verteilt. Ggf. als Rahmenvertrag mit Abrufkontingent gestaltbar.
– Preis: Tagessatz-basiert, z.B. 20 PT * 1.500 € = 30.000 € (zzgl. MwSt.) als Richtwert. Exakte Kosten kalkulieren wir gemeinsam anhand Ihres konkreten Bedarfs.

Hinweis: Alle Pakete sind flexibel anpassbar. Vielleicht brauchen Sie etwas zwischen „Start“ und „Pro“ – gar kein Problem, wir schneiden das passend zu. Mir ist wichtig: Sie sollen genau so viel Unterstützung bekommen, wie nötig – und so viel selber machen, wie möglich (Stichwort Befähigung Ihrer Mitarbeiter). In keinem Paket übernehme ich langfristig den Betrieb oder biete 24/7-Service – das bleibt bewusst in Ihrer Verantwortung. Ich stehe aber immer für punktuelle Einsätze bereit, wenn Sie mich brauchen.

Fazit & nächste Schritte – Ihr Call-to-Action

Herzlichen Glückwunsch, dass Sie bis hierher gelesen haben – das zeigt Ihr ernsthaftes Interesse an M365-Compliance (oder Sie mögen einfach meinen Schreibstil 😉). Fazit: Mit der richtigen Mischung aus Organisation, Technik und Menschlichkeit ist Compliance in Microsoft 365 absolut machbar. Es ist Arbeit, ja, aber wie wir gesehen haben, lässt sich diese in strukturierte Bahnen lenken.

Wichtig ist mir zu betonen: Ich unterstütze Sie gerne auf diesem Weg – persönlich und maßgeschneidert. Alle Leistungen erbringe ich selbst; Sie haben es immer mit mir als Ihrem Berater zu tun, nicht mit irgendeinem austauschbaren Ticket-System. Ich biete keine dauerhaften Managed Services an, weil ich fest daran glaube, dass Compliance in Ihrem Haus verankert sein sollte. Stattdessen setze ich auf Empowerment: Ich helfe Ihnen, dass Sie es können. Und wenn Sie mich brauchen – sei es für einen Audit, ein Review in einem Jahr, ein Update-Workshop oder eine spezielle Schulung – dann bin ich punktuell für Sie da. Langfristige Zusammenarbeit heißt bei mir: immer wieder mal den Kompass justieren, aber das Steuer bleiben Sie.

Call-to-Action: Wenn Sie jetzt das Gefühl haben, Sie könnten einen erfahrenen Begleiter gebrauchen – sei es beim Start, beim Feinschliff oder beim großen Rundumschlag – dann lassen Sie uns reden! Ich freue mich auf ein unverbindliches Kennenlerngespräch, in dem wir ausloten, welches Paket oder welcher Ansatz für Sie passt. Greifen Sie zum Hörer, schreiben Sie mir eine Mail oder schicken Sie eine Teams-Einladung – ganz wie Sie mögen.

Machen wir Ihre Microsoft-365-Umgebung gemeinsam compliance-fit – mit Augenmaß, Pragmatismus und (versprochen) auch mit dem ein oder anderen Schmunzeln unterwegs. Ich freue mich darauf, von Ihnen zu hören!

 

Weitere Beiträge zum Thema Security und Compliance