SharePoint Governance – Grundlagen, Umsetzung, Praxis

Management Summary

SharePoint Governance bezeichnet ein Rahmenwerk aus Richtlinien, Rollen, Prozessen, Kontrollen und Werkzeugen, das sicherstellt, dass die Nutzung von SharePoint in Einklang mit den Unternehmenszielen sowie gesetzlichen Vorgaben erfolgt. Ohne Governance entstehen schnell Wildwuchs und Schatten-IT, während eine klare Governance Ordnung, Sicherheit und Effizienz fördert. Jede Organisation, die Microsoft SharePoint, Teams und OneDrive einsetzt, benötigt daher eine passende Governance-Strategie, um Geschäftsnutzen zu realisieren und Risiken zu minimieren.

• Strukturierte Zusammenarbeit: Governance ermöglicht schnellere Projektstarts und effizientere Zusammenarbeit, da klare Vorlagen und Prozesse den Teams von Anfang an Orientierung geben.
• Vermeidung von Datenverlust: Durch definierte Berechtigungen und Überwachungsmechanismen wird das Risiko von Datenabfluss und unbefugtem Zugriff deutlich reduziert.
• Compliance-Sicherheit: Einheitliche Regeln für Aufbewahrung, Klassifizierung und Dokumentation stellen sicher, dass regulatorische Anforderungen (z.B. DSGVO) erfüllt werden.
• Kosteneinsparungen: Standardisierung und Automatisierung sparen Zeit bei der Erstellung und Verwaltung von Arbeitsräumen, reduzieren Doppelarbeit und senken langfristig Betriebs- und Supportkosten.
• Wissensmanagement: Durch konsistente Metadaten und zentrale Suche werden Informationen leichter auffindbar und besser wiederverwendbar, was die Innovationsfähigkeit fördert.

Sofortnutzen: Erste Governance-Maßnahmen zeigen schnell Wirkung – z.B. klar definierte Verantwortlichkeiten und ein Self-Service-Prozess für neue Teams/Sites ermöglichen sofortige Entlastung der IT und beseitigen Wildwuchs. Mittelfristig führt ein Governance-Konzept zu messbaren Effekten wie höherer Nutzerzufriedenheit, weniger Support-Aufwand und einer besseren Datenqualität. Langfristig steigert eine verankerte SharePoint Governance den Wertbeitrag der Plattform zum Kerngeschäft: Wissen wird nachhaltig bewahrt, die Umgebung bleibt schlank und konform, und das Unternehmen kann flexibel auf neue Anforderungen reagieren.

Eine Roadmap in vier Phasen hat sich bewährt: In Phase 0 (Assessment) werden Anforderungen und Risiken erhoben, Phase 1 (Pilot) entwickelt Governance-Leitplanken und erste Blueprints im kleinen Rahmen, Phase 2 (Rollout) überführt die Governance unternehmensweit in Wellen, und Phase 3 (Verstetigung) etabliert ein kontinuierliches Verbesserungsprogramm. So werden früh Quick Wins erzielt und gleichzeitig die Grundlagen für langfristigen Erfolg gelegt.

Top-5 Risiken ohne Governance: 1. Unkontrollierter Wildwuchs: Teams und Websites schießen ungeplant aus dem Boden, was zu Chaos und Sicherheitslücken führt. 2. Datenverlust oder -abfluss: Ohne klare Zugriffsregeln können vertrauliche Informationen in falsche Hände gelangen. 3. Nichteinhaltung von Vorschriften: Fehlende Aufbewahrungs- und Löschkonzepte riskieren Verstöße gegen DSGVO oder interne Richtlinien. 4. Ineffiziente Suche: Ohne einheitliche Metadaten gehen Dokumente in der Masse unter, Mitarbeiter verschwenden Zeit mit Suchen. 5. Hohe Betriebskosten: Redundante Strukturen und manuelle Verwaltung treiben den Aufwand für IT-Betrieb und Support in die Höhe.

Top-5 KPI für Governance-Erfolg: 1. Provisionierungszeit – Durchschnittliche Dauer von der Anforderung bis zur Bereitstellung neuer Teams/Sites (Ziel: wenige Minuten statt Tage). 2. Klassifizierungsquote – Anteil der Sites und Dokumente mit zugewiesenem Vertraulichkeits-Label (Ziel: 100% klassifiziert). 3. Rezertifizierungsrate – Prozentsatz der Bereiche, in denen Berechtigungen planmäßig (z.B. quartalsweise) überprüft und bestätigt wurden. 4. Archivierungsquote – Anteil inaktiver Arbeitsräume, die gemäß Lifecycle-Plan archiviert oder gelöscht wurden (zeigt Bereinigungsgrad). 5. Support-Tickets – Anzahl der Supportanfragen zu SharePoint/Teams pro Monat; ein Rückgang weist auf besseres Verständnis und reibungslose Prozesse hin.

1. Einordnung & Begriffe

Eine effektive SharePoint Governance ist die Abstimmung aus Richtlinien, Rollen, Prozessen, Kontrollen und Werkzeugen, um den Einsatz von SharePoint zielgerichtet zu steuern. Governance legt fest, wer was in SharePoint (und den verbundenen Diensten wie Microsoft Teams und OneDrive) tun darf, wie Inhalte strukturiert und verwaltet werden und welche Regeln für Sicherheit und Compliance gelten. Wichtig ist dabei die Abgrenzung zwischen verschiedenen Umgebungen: SharePoint Online (Teil von Microsoft 365, cloudbasiert und eng mit Teams/OneDrive verknüpft) versus SharePoint Server Subscription Edition (on-premises im eigenen Rechenzentrum betrieben). Während SharePoint Online regelmäßig neue Funktionen bietet und nahtlos in Entra ID (Azure AD) sowie die Microsoft 365 Suite integriert ist, ermöglicht die Subscription Edition mehr Kontrolle über Updates und Datenhaltung vor Ort. Die Grundprinzipien der Governance gelten in beiden Fällen, müssen aber an technische Gegebenheiten (z.B. externe Freigaben in der Cloud vs. VPN-Zugriff on-premises) angepasst werden.

Governance-Ebenen: In einer SharePoint-Umgebung lassen sich mehrere Ebenen unterscheiden, die jeweils eigene Governance-Vereinbarungen erfordern:
– Organisations-Ebene: Übergreifende Vorgaben und Leitlinien, die für das gesamte Unternehmen gelten (z.B. Sicherheitsstandards, Compliance-Grundsätze).
– Tenant-Ebene: Einstellungen und Richtlinien auf Mandantenebene in Microsoft 365 (z.B. wer darf neue Teams/Sites anlegen, Richtlinien für externes Teilen, globale Branding-Vorgaben).
– Informationsarchitektur: Struktur der digitalen Arbeitsräume – z.B. Aufteilung in Hub-Sites, Bereiche für Abteilungen vs. Projekte, zentrale Navigation und festgelegte Inhaltskategorien.
– Website-/Site-Ebene: Governance innerhalb einzelner SharePoint-Site-Sammlungen oder Teams: Rollen der Site-Eigentümer, lokale Berechtigungsgruppen, aktivierte Features, Konfigurationen (z.B. Versionsverwaltung).
– Bibliotheken/Listen: Standards für einzelne Dokumentbibliotheken oder Listen, etwa Vorlagen, Pflicht-Metadatenfelder, Aufbewahrungsrichtlinien pro Bibliothek.
– Inhalte & Metadaten: Vorgaben zur Klassifizierung und Verschlagwortung von Dokumenten und Listeneinträgen, Nutzung von Content-Types, Pflege des Taxonomie-Systems.
– Berechtigungen: Modell der Zugriffsteuerung über alle Ebenen hinweg – Nutzung von Gruppen statt Einzelberechtigungen, Prinzip der minimalen Rechtevergabe, regelmäßige Überprüfung der Zugriffsrechte.
– Lebenszyklus: Regeln für die Phasen von Inhalten und ganzen Sites: Erstellung, aktive Nutzung, Archivierung (Read-only) und endgültige Löschung, inkl. Definition von Verantwortlichkeiten je Phase.

SharePoint Governance greift in viele benachbarte Disziplinen: Compliance (z.B. Datenschutz und gesetzliche Aufbewahrungspflichten) ist ein zentraler Treiber, da Governance-Regeln sicherstellen müssen, dass Vorgaben wie die DSGVO eingehalten werden – etwa durch definierte Speicherfristen, kontrollierte externe Freigaben und Nachvollziehbarkeit über Audit-Logs. Auch die Informationssicherheit profitiert: Ein gutes Berechtigungskonzept und der Einsatz von DLP-Technologien (Data Loss Prevention) verhindern, dass vertrauliche Daten in die falschen Hände geraten. Weiterhin spielt Governance eine Rolle in der IT-Architektur (wie sind die Systeme integriert, z.B. Teams als Frontend zu SharePoint, OneDrive als persönlicher Speicher, Entra ID als zentrales Identitätsmanagement) und im Betrieb (z.B. wie Änderungen an Strukturen oder Funktionen kontrolliert ausgerollt werden, oder wer bei Vorfällen eingreift). Kurzum: SharePoint Governance verbindet organisatorische Regeln mit technischen Einstellungen, um eine nachhaltige, sichere und effiziente Plattform bereitzustellen.

2. Warum Governance unverzichtbar ist

Ohne klare Governance kommt es in SharePoint- und Teams-Umgebungen früher oder später zu Problemen, die sowohl betriebswirtschaftliche als auch sicherheitsrelevante Risiken darstellen:
– Schatten-IT und Wildwuchs: In Abwesenheit zentraler Vorgaben entstehen parallele Strukturen außerhalb der offiziellen Plattform oder unkontrolliert innerhalb davon. Beispielsweise legen Benutzer eigenmächtig neue Sites oder nutzen fremde Cloud-Dienste, was zu einem unübersichtlichen Wildwuchs führt.
– Datenabfluss und Sicherheitsvorfälle: Fehlt ein abgestimmtes Berechtigungskonzept, besteht die Gefahr, dass Unbefugte Zugriff auf sensible Daten erhalten. Unkontrolliertes externes Teilen (ohne Governance) erhöht das Risiko von Datenlecks erheblich.
– Revisionslücken: Ohne definierte Prozesse für Dokumentation und Auditierung fehlen Nachweise, wer wann auf Informationen zugegriffen oder Änderungen vorgenommen hat. Bei Prüfungen (z.B. interne Revision, externe Audits) können so Compliance-Verstöße unentdeckt bleiben.
– Ineffiziente Zusammenarbeit: Uneinheitliche Strukturen und fehlende Standards bedeuten, dass Teams viel Zeit mit der Suche nach Informationen verbringen. Doppelarbeit ist häufig, weil keine zentralen Ablagen oder wiederverwendbaren Vorlagen existieren.
– Such- und Performance-Probleme: Bei unstrukturiertem Inhalt und fehlenden Metadaten wird die Suche unpräzise und langsam. Zudem können übervolle Sites oder gigantische Listen ohne Archivierung die Performance beeinträchtigen.
– Hohe Kosten durch Redundanz: Ohne Governance entstehen zahlreiche redundante Inhalte (Dateien werden mehrfach abgelegt, veraltete Informationen nie gelöscht). Die Storage-Kosten steigen und die Administration wird aufwändiger, da jede Abteilung eigene Lösungen bastelt.

Demgegenüber schafft eine konsequente Governance Wertbeiträge für die Organisation:
– Schnellere Projektstarts: Anstatt jedes Projekt bei Null zu beginnen, stehen vordefinierte Teams/Sites mit passenden Vorlagen bereit. Das verkürzt die Einrichtungszeit erheblich und neue Teams können sich sofort auf inhaltliche Arbeit konzentrieren.
– Bessere Wiederverwendung von Wissen: Einheitliche Strukturen und zentral gepflegte Taxonomien bedeuten, dass Informationen aus früheren Projekten leichter auffindbar und wiederverwendbar sind. Lessons Learned, Dokumentvorlagen oder Best Practices gehen nicht verloren, sondern stehen unternehmensweit zur Verfügung.
– Einheitliche Metadaten: Wenn alle Bereiche die gleichen Begriffe und Kategorien verwenden (z.B. für Abteilungen, Projekttypen, Vertraulichkeitsstufen), werden Auswertungen und bereichsübergreifende Suchen genauer. Die Datenqualität steigt, was fundierte Entscheidungen ermöglicht.
– Konforme Aufbewahrung und Löschung: Governance legt fest, wie lange Dokumente aufbewahrt werden und wann sie zu löschen sind. Damit werden rechtliche Vorgaben (etwa steuer- oder datenschutzrechtliche Fristen) eingehalten, ohne dass jede Abteilung eigene Lösungen erfindet.
– Reduzierte Betriebsaufwände: Durch Standards und Automatisierung (z.B. automatische Provisionierung, regelmäßige Archivierung) sinkt der manuelle Aufwand für IT-Administratoren. Wiederkehrende Aufgaben laufen nach definiertem Prozess ab, was zu weniger Supportfällen und geringerer Fehleranfälligkeit führt.

Zur Kosten-Nutzen-Abwägung lassen sich typische Aufwände einer Governance-Initiative den daraus resultierenden Einsparungen gegenüberstellen:

3. Zielbild & Leitplanken

Um SharePoint erfolgreich zu steuern, braucht es ein klares Zielbild und verbindliche Leitplanken. Ein Zielbild beschreibt, wie die Zusammenarbeit idealerweise aussehen soll – von der Architektur der Sites bis zur Nutzererfahrung – während Leitplanken die Prinzipien und Regeln vorgeben, die auf dem Weg dorthin gelten. Typische Leitprinzipien einer SharePoint Governance sind:
– Secure by Default: Sicherheit von Anfang an. Neue Sites, Teams und Inhalte sind standardmäßig privat und nur für Berechtigte zugänglich, anstatt offen für alle. Einstellungen werden so gewählt, dass im Zweifelsfall die sicherere Option greift (Prinzip der geringsten Berechtigung).
– Metadata First: Metadaten werden nicht als lästige Kür, sondern als integraler Bestandteil gesehen. Jede Information wird nach Möglichkeit schon bei der Erstellung verschlagwortet (Projektname, Kategorie, Vertraulichkeit etc.), damit sie später leicht auffindbar ist und in Regeln (Retention, DLP) einbezogen werden kann.
– Lifecycle from Day One: Von Beginn an wird jeder Arbeitsraum mit seinem gesamten Lebenszyklus im Blick angelegt. Das bedeutet, es gibt eine Planung für die aktive Nutzungsphase, aber auch bereits Kriterien für Inaktivität, Archivierung und End-of-Life (Löschung) des Bereichs.
– Guided Self-Service: Benutzer sollen eigenständig Arbeitsräume anfordern und nutzen können, aber innerhalb gesteckter Leitplanken. Selbstbedienung ja – aber nur über genehmigte Vorlagen und mit automatisierten Kontrollen, sodass Wildwuchs vermieden wird.

Im Zielarchitektur-Modell der Informationsräume werden Struktur und Standards festgelegt: Häufig bewährt sich ein Hub-and-Spoke-Ansatz mit zentralen Hub-Sites (z.B. pro Unternehmensbereich oder Produktlinie), unter denen thematisch oder projektbezogen einzelne Team-Sites angesiedelt sind. Jede Site (bzw. jedes Team in Microsoft Teams) folgt Namenskonventionen, sodass bereits am Namen erkennbar ist, um welchen Zweck oder Bereich es sich handelt (etwa Prefix „PROJ-“ für Projekte). Beim Anlegen werden Sensitivity Labels vergeben, um die Vertraulichkeitsstufe des gesamten Arbeitsraums technisch durchzusetzen (z.B. Einschränkungen für externes Teilen bei „Vertraulich“). Zudem gibt es Standards für die Provisionierung: neue Sites/Teams entstehen nur über definierte Prozesse oder Automatisierungstools – nie ad-hoc durch Benutzer mit unterschiedlichen Einstellungen. So bleibt die Architektur konsistent: Abteilungsseiten, Projekträume, Teams-Kanäle etc. sind klar zugeordnet und folgen festen Strukturen, was Navigation und Governance erheblich vereinfacht.

Zur Governance gehören auch konkrete Artefakte, die das Regelwerk greifbar machen:
– Policy-Katalog: Sammlung aller geltenden Richtlinien und Standards für den Umgang mit der Plattform. Hier sind z.B. Richtlinien zu Berechtigungen, Datenklassifizierung, externer Zusammenarbeit etc. schriftlich festgehalten.
– Rollenmodell: Definition aller relevanten Rollen (z.B. Site-Eigentümer, Informationsarchitekt, Datenschutzbeauftragter) und deren Verantwortlichkeiten. Oft als RACI-Matrix dargestellt, um Klarheit über Zuständigkeiten zu schaffen.
– Prozesslandkarte: Übersicht der Prozesse rund um den Lebenszyklus von Sites und Inhalten – von der Beantragung eines neuen Teams über Änderungsprozesse bis zur endgültigen Löschung. Diese Darstellung hilft, Abhängigkeiten zu erkennen und Schulungen zu planen.
– Kontrollmatrix: Auflistung aller Governance-Kontrollen (Prüfpunkte) mit Zuordnung, wann und durch wen geprüft wird. Beispielsweise könnte festgelegt sein, dass vierteljährlich ein Berechtigungsreview erfolgt (Kontrolle) und der Fachbereichsleiter dafür verantwortlich ist (Owner).
– Vorlagenkatalog: Zentraler Satz an freigegebenen Templates für Sites, Teams, Dokumentbibliotheken, Listen und ggf. Inhalten. Diese Vorlagen stellen sicher, dass bei neuen Arbeitsräumen immer eine definierte Grundstruktur (Ordner, Listen, Metadaten, Labels) zur Verfügung steht.

4. Rollen & Verantwortlichkeiten (RACI)

Klare Rollenverteilungen sind essenziell, damit Governance gelebt wird. Im Kontext von SharePoint (und Microsoft 365 insgesamt) haben sich u.a. folgende Rollen etabliert:
– Site-Eigentümer: Verantwortlich für einen bestimmten Arbeitsbereich (z.B. Team-Website) und dessen Inhalte. Er stellt sicher, dass die Regeln eingehalten werden, pflegt Inhalte und genehmigt oder initiiert Änderungen (z.B. neue Mitglieder hinzufügen). In der Regel kommt der Site-Eigentümer aus dem Fachbereich.
– Site-Administrator: Technisch versierte Person (oft aus IT oder als Power User im Fachbereich), die administrative Aufgaben auf Site-Ebene übernimmt. Sie setzt Einstellungen, verwaltet Berechtigungen und unterstützt den Eigentümer bei komplexeren Konfigurationen.
– Informationsarchitekt: Experte für Informationsstruktur und Metadaten. Diese Rolle definiert die Taxonomie, Content-Types und sorgt dafür, dass unternehmensweit einheitliche Metadaten benutzt werden. Der Informationsarchitekt berät bei der Planung neuer Sites hinsichtlich Navigation und Ablagestruktur.
– Records Manager: Zuständig für Aufbewahrung und Lifecycle. Der Records Manager definiert Aufbewahrungsfristen, sorgt für Umsetzung von Löschkonzepten und verwaltet ggf. Dokumentenklassifikationen oder das Records Center. Er stellt sicher, dass regulatorische Vorgaben zu Archivierung und Löschung eingehalten werden.
– Datenschutzbeauftragter: Überwacht die Einhaltung der Datenschutzrichtlinien (DSGVO etc.) in der Plattform. Diese Rolle prüft z.B. Freigaben an externe Partner auf Datenschutzkonformität und berät bei der Behandlung personenbezogener Daten (inkl. Bearbeitung von Auskunfts- oder Löschersuchen von Betroffenen).
– IT-Betrieb (Plattform-Team): Die IT-Abteilung, die die technische Plattform bereitstellt und betreibt. Sie ist verantwortlich für Verfügbarkeit, Performance, technische Änderungen und fungiert oft als Service Owner für SharePoint/Teams. Das Betriebsteam setzt Einstellungen auf Tenant-Ebene und führt Deployments oder Scripts aus.
– Fachbereichsleitung: Die Leitung der jeweiligen Abteilung oder Projektgruppe, die einen Arbeitsraum nutzt. Sie hat eine Schirmherren-Funktion: trägt die Verantwortung, dass der Bereich einen Mehrwert liefert und governance-konform genutzt wird. Oft entscheidet sie über Anträge (z.B. Freigabe eines neuen Projektspaces) und stellt Ressourcen (z.B. Site-Eigentümer aus dem Team).
– Revision (Audit): Interne oder externe Prüfer, die die Einhaltung der Richtlinien überprüfen. Sie führen Audits durch, kontrollieren z.B. Berechtigungsvergaben, Protokolleinträge und generell die Wirksamkeit der Governance. Ihre unabhängige Sicht hilft, Lücken aufzudecken und Verbesserungen anzustoßen.

Eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) veranschaulicht, wer bei typischen Aufgaben welche Rolle einnimmt:

5. Policies & Standards

Governance spiegelt sich in konkreten Policies und Standards wider, die für alle Nutzer verbindlich sind. In diesem Kontext nennen wir übergreifende Vorgaben Richtlinien (Policies) und konkrete Umsetzungen Standards. Beispielsweise kann eine Richtlinie festlegen, dass jede Site klassifiziert sein muss; der Standard dazu gibt die konkreten Klassifizierungsstufen und Label vor.

Wichtige Bereiche für Policies & Standards in SharePoint/M365 sind:
– Namenskonventionen: Einheitliche Benennung von Teams, Sites, Gruppen und sogar Bibliotheken. Dies vermeidet Verwechslungen. Zum Beispiel könnten alle Projekt-Teams nach dem Muster PROJ_Projektname benannt werden oder Abteilungsseiten tragen das Abkürzel der Abteilung im Namen. Namenskonventionen erhöhen die Übersicht und lassen sich technisch oft durchsetzen (etwa indem Provisioning-Tools keine freien Namen erlauben, sondern Vorgaben prüfen).
– Klassifizierung & Sensitivity Labels: Das Unternehmen sollte festlegen, welche Informationsklassen es gibt (z.B. öffentlich, intern, vertraulich, streng vertraulich) und wie diese zu handhaben sind. Dazu gehören Sensitivity Labels in Microsoft 365: Sie ermöglichen es, Dokumente oder ganze Sites entsprechend einzustufen und automatisch mit Schutzmaßnahmen zu versehen (z.B. Verschlüsselung oder Begrenzung von Freigaben). Standards definieren hier zum Beispiel: „Vertrauliche Dokumente müssen mindestens Label X tragen und dürfen nicht extern geteilt werden.“
– Vorlagen & Strukturen: Um Wildwuchs zu vermeiden, gibt es Standards für die Anlage von Arbeitsräumen. Z.B. eine Policy „Jede neue Team-Website muss eine freigegebene Vorlage nutzen“. Der Vorlagenkatalog (Abschnitt 3) stellt die Referenz bereit. Ebenso können Ordnerstrukturen standardisiert sein (etwa jeder Projektraum hat die Ordner „01 Planung“, „02 Durchführung“, „03 Abschluss“).
– Berechtigungsmodell: Hier gilt Least Privilege als Leitmotiv. Policies legen fest, dass Berechtigungen grundsätzlich rollenbasiert/gruppenbasiert erfolgen sollen (keine individuellen Nutzer direkt eintragen). Auch das Vorgehen für externe Freigaben wird hier geregelt: Zum Beispiel eine Policy, dass externe Gäste nur auf dafür ausgewiesene Bereiche dürfen und eine monatliche Überprüfung dieser Gäste erfolgt. Gastzugriff generell kann in Policies eingeschränkt sein (z.B. Verbot von anonymen Links, siehe auch Abschnitt 10).
– Metadaten & Taxonomie: Standards für Metadaten sorgen dafür, dass Inhalte unternehmensweit konsistent beschrieben sind. Beispielsweise könnte festgelegt sein, dass Dokumentbibliotheken immer ein Feld „Dokumententyp“ oder „Abteilung“ haben, um später filtern und suchen zu können. Eine Taxonomie-Policy regelt, wie neue Schlagworte ins System kommen (z.B. nur der Informationsarchitekt darf globale Termini hinzufügen).
– Inhaltslebenszyklus: Vom Erstellen bis zum Löschen werden Inhalte nach definierten Standards behandelt. Etwa: „Ein Projektarbeitsraum muss spätestens 6 Monate nach Projektende archiviert werden“ oder „E-Mails gelten nach X Jahren als aufbewahrungswürdig und werden ins Archiv verschoben“. Auch die Nutzung von Retention-Labels* und Löschregeln gehört hier hinein (Überschneidung mit Compliance-Richtlinien).

Nachfolgend ein beispielhafter Policy-Katalog, der einige dieser Punkte veranschaulicht:

6. Prozesse & Kontrollen

Die Governance muss durch Prozesse untermauert sein, damit Regeln im Alltag befolgt werden. Zu den wichtigsten Prozessen gehören:
– Anforderungs- und Provisionierungsprozess: Wie wird ein neuer Arbeitsraum (Team, SharePoint-Site) beantragt und erstellt? Der Prozess definiert, wer einen Antrag stellen darf, welche Informationen Pflicht sind (Name, Zweck, Verantwortlicher, Klassifizierung) und wer genehmigen muss. Die Bereitstellung erfolgt idealerweise automatisiert nach Freigabe.
– Änderungsprozess: Änderungen an bestehenden Arbeitsräumen – etwa das Hinzufügen neuer Apps, Anpassung der Seitenstruktur oder Ändern von Klassifizierungen – sollten gesteuert ablaufen. Oft ist dafür ein kurzes Change-Request-Verfahren definiert, damit z.B. die IT oder der Informationsarchitekt bei größeren Umstellungen einbezogen wird.
– Berechtigungs-Rezertifizierung: Ein regelmäßiger Prozess (z.B. quartalsweise), in dem die Site-Eigentümer die aktuellen Zugriffsberechtigungen überprüfen. Sie bestätigen, dass jede Person noch Zugriff benötigt, oder entfernen veraltete Berechtigungen. Dies stellt sicher, dass z.B. ehemalige Mitarbeiter oder Externe nicht unnötig lange Zugriff behalten.
– Archivierungs-/Schließungsprozess: Wenn ein Projekt endet oder ein Team langfristig inaktiv ist, wird der entsprechende Arbeitsraum geschlossen. Der Prozess legt fest, wann eine Site als „inaktiv“ gilt (z.B. 6 Monate ohne Aktivität) und wie dann zu verfahren ist: Oft erfolgt eine Benachrichtigung an den Eigentümer, anschließend wird die Site auf schreibgeschützt gesetzt (Archiv) und nach Freigabe durch Records Manager oder Eigentümer endgültig gelöscht.
– Lösch- bzw. Records-Prozess: Für Daten, die nicht mehr aufbewahrt werden dürfen (Ende der Aufbewahrungsfrist oder DSGVO-Löschbegehren), muss ein definierter Prozess sicherstellen, dass diese Daten ordnungsgemäß entfernt werden. Dazu gehört auch die Protokollierung der Löschung und ggf. die Dokumentation für Nachweise (z.B. im Rahmen der DSGVO).

Viele dieser Prozesse beinhalten Genehmigungsworkflows. Beispielsweise kann die Einrichtung einer neuen Team-Site eine Freigabe durch einen Vorgesetzten erfordern, oder der externe Zugriff auf eine vertrauliche Bibliothek muss von Datenschutz und IT-Sicherheit abgenickt werden. Genehmigungen laufen idealerweise elektronisch (etwa über Power Automate oder integrierte Workflows im Provisioning-Tool), sodass jede Entscheidung nachvollziehbar protokolliert wird. Mehrstufige Workflows sind möglich – z.B. zuerst Freigabe durch den Fachbereich, dann finale Zustimmung durch IT oder Compliance bei besonders sensiblen Fällen. Wichtig ist, dass klar definiert ist, wann eine Genehmigung erforderlich ist und wer im Einzelfall zuständig ist.

Parallel dazu sorgen Kontrollen und Monitoring dafür, dass die definierten Prozesse eingehalten werden. Alle wichtigen Aktionen sollten über Audit-Trails nachvollziehbar sein – Microsoft 365 bietet hier das Unified Audit Log, das z.B. Site-Anlagen, Löschvorgänge, Zugriffsänderungen usw. aufzeichnet. Darüber hinaus können spezifische Kontrollpunkte eingerichtet werden: Etwa ein monatlicher Report aller neu angelegten Sites zur Überprüfung durch das Governance Board oder automatische Prüfscripts, die überprüfen, ob jede neue Site ein Klassifizierungs-Label hat. Kontrollen können präventiv (im Prozess vor einer Aktion, z.B. Formulare lassen nur validierte Eingaben zu) oder detektiv (im Nachgang, z.B. regelmäßige Audits) sein. Wichtig ist auch ein Eskalationsmechanismus: Wenn etwa ein Site-Eigentümer die quartalsweise Rechteüberprüfung versäumt, sollte automatisiert eine Erinnerung oder Eskalation an dessen Vorgesetzten erfolgen. Durch dieses Zusammenspiel von definierten Prozessen und Kontrollen wird Governance vom Papiertiger zur gelebten Praxis.

Beispielhafte Kontrollmatrix:

7. Zehn konkrete Governance-Szenarien

Im Folgenden werden zehn praxisnahe Szenarien vorgestellt, in denen sich eine gute Governance besonders auszahlt. Jedes Szenario beschreibt den Nutzen, die Rollen und Richtlinien, den Ablauf (Prozess), technische Umsetzung, Kontrollen/KPI sowie Risiken und gibt ein Beispiel aus der Praxis.

Szenario 1: Standardisierte Provisionierung von Teams/Sites mit Metadatenpflicht

Ziel und Nutzen: Neue Zusammenarbeitssites sollen schnell, aber kontrolliert entstehen. Durch Standardisierung der Anlage (z.B. über ein zentrales Antragsformular) wird Wildwuchs vermieden und gleichzeitig der Aufwand für die IT reduziert. Pflicht-Metadaten wie Projektnamen oder Kategorien sorgen dafür, dass jede neue Site gleich richtig einsortiert ist und später leichter verwaltet werden kann.

Beteiligte Rollen: Typischerweise initiiert ein Fachbereich (Projektleiter o.ä.) den Antrag. Die Fachbereichsleitung oder IT muss die Anlage genehmigen (abhängig von Richtlinien, z.B. muss ein Geschäftsbereichsleiter externe Projekte absegnen). Die IT-Betrieb Rolle führt die Provisionierung durch, meist automatisiert über ein Tool oder Skript. Der Informationsarchitekt stellt sicher, dass die neue Site in die Informationsarchitektur passt (z.B. Hub-Zuordnung, richtige Template-Wahl), und der Datenschutz kann involviert sein, falls besondere Datenschutzkategorien betroffen sind.

Policies/Standards: Hier greifen mehrere Vorgaben: Namenskonventionen (der Antrag erzwingt einen Name nach Muster, z.B. „PROJ_<Projektname>“), Klassifizierung (der Antragssteller muss angeben, ob die Site vertraulich ist, entsprechend wird ein Sensitivitätslabel gesetzt), Vorlagenpflicht (es muss eine Kategorie/Template ausgewählt werden, z.B. „Projektraum IT-Projekt“ mit vordefinierten Listen) und Berechtigungsmodell (Standardgruppen Owner/Member werden automatisch angelegt, keine externen Gäste falls Policy es verbietet). Zudem ist oft Versionierung in Bibliotheken per Standard aktiviert.

Prozess: Der Ablauf beginnt mit einem elektronischen Formular: Der Nutzer gibt Eckdaten ein (Titel, Beschreibung, Verantwortlicher, gewünschte Template, Klassifizierung). Ein definierter Genehmiger (z.B. Abteilungsleiter) erhält daraufhin eine Benachrichtigung und prüft den Antrag. Nach Freigabe löst das System die Provisionierung aus: Innerhalb weniger Minuten wird das Team bzw. die SharePoint-Site angelegt. Dabei werden automatisch die gewählten Einstellungen umgesetzt: z.B. Kanäle und Ordnerstruktur angelegt, das Sensitivitätslabel gesetzt, der Antragsteller als Owner eingetragen und evtl. angegebene Mitglieder hinzugefügt. Der Antragsteller erhält eine Bestätigung, und die neue Site wird ins Inventar aufgenommen (inkl. Vermerk der gewählten Kategorie, Erstelldatum, etc.).

Technische Umsetzung: Ohne Drittmittel lässt sich so etwas mit Power Automate und Skripten realisieren (Formular -> Genehmigung -> Graph-API Call zur Team/Site-Erstellung), jedoch ist der Aufwand hoch. Viele Unternehmen nutzen spezialisierte Provisioning-Tools (siehe Abschnitt 8), die solche Prozesse schlüsselfertig bieten. Wichtig ist in jedem Fall, dass normale Anwender nicht über die Standard-UI von Teams eigenständig Teams anlegen dürfen, sondern die Berechtigung hierzu eingeschränkt ist – so fließen alle Anfragen in den geregelten Prozess.

Kontrollen & KPI: Dieses Szenario hat klare Erfolgsindikatoren: z.B. Durchschnittliche Bereitstellungszeit (Ziel: < 1 Stunde), Einhaltung Naming Convention (Ziel: 100%), und Anteil der automatisiert erstellten vs. manuell erstellten Arbeitsräume (Ziel: 100% über Prozess). Als Kontrolle dient vor allem das Genehmigungsprotokoll (jede neue Site hat eine dokumentierte Freigabe) und die Überwachung, dass keine Umgehung stattfindet (Audit-Log auf spontane Site-Anlagen durch Administratoren).

Risiken/Antipatterns: Wenn der Prozess zu komplex oder langsam ist, suchen Nutzer nach Umwegen (z.B. nutzen ein anderes Tool ohne Freigabe). Auch können zu starre Templates zum Problem werden, wenn spezielle Anforderungen nicht abgebildet werden – dann entstehen „Schatten-Teams“ außerhalb der Struktur. Ein weiteres Antipattern wäre, den Genehmigungsprozess zu formell zu gestalten (z.B. papierbasierte Freigaben) – das widerspricht dem Ziel der schnellen Bereitstellung.

Praxisbeispiel: Die Contoso AG hat ein Self-Service-Portal eingeführt, über das Projektleiter neue Projekträume beantragen. Ein vorgegebenes Template stellt sicher, dass jede Projekt-Site eine einheitliche Dokumentenbibliothek, einen Aufgabenplaner und ein OneNote-Notizbuch enthält. Seit Einführung des Prozesses werden pro Monat ~20 neue Teams angelegt, alle mit korrekter Bezeichnung und Dokumentation – früher entstanden Wildwuchs und es dauerte oft Wochen, bis alle Tools eingerichtet waren; heute erfolgt dies innerhalb eines Tages, komplett nachvollziehbar.

Szenario 2: Einheitliche Projektakten mit Vorlagen und Rollenpaketen

Ziel und Nutzen: Jedes Projekt im Unternehmen soll ähnliche Strukturen und Ablagen nutzen, damit Mitarbeiter sich nicht jedes Mal neu orientieren müssen. Eine „Projektakte“ als standardisierte Team-Site sorgt dafür, dass wichtige Elemente wie Aufgabenlisten, Risiko-Register oder Meetings-Protokolle überall vorhanden sind. Das erleichtert die Einarbeitung neuer Teammitglieder und die Qualitätssicherung (kein Projekt vergisst z.B. seinen Abschlussbericht, weil dafür eine Vorlage existiert).

Beteiligte Rollen: Der Project Owner (Projektleiter) übernimmt die Rolle des Site-Eigentümer und damit die Verantwortung für die Inhalte. Das PMO (Projektmanagement Office) oder ein Qualitätsmanager im Unternehmen definiert die einheitlichen Inhalte der Projektakte (welche Listen, Dokumente etc. enthalten sein müssen). IT-Betrieb oder der Provisioning-Prozess sorgt bei jeder neuen Projektakte für die Bereitstellung der Vorlage. Fachbereichsleitung und Revision interessieren sich hier für die Vergleichbarkeit der Projekte und die Vollständigkeit der Dokumentation.

Policies/Standards: Vorgeschrieben ist die Nutzung einer Projektvorlage für alle formal gestarteten Projekte. Darin sind z.B. Ordner wie „Projektplan“, „Berichte“, Listen wie „Risiken“ oder „Entscheidungen“ und ein OneNote-Bereich für Meetings definiert. Rollenpakete bedeuten: sobald die Site erstellt ist, werden z.B. automatisch die Projektteam-Mitglieder hinzugefügt (aus dem Antrag) als Mitglieder, ggf. externe Partner als Gäste (falls erlaubt), und eine standardisierte Besucher-Leserechte-Gruppe kann für Stakeholder bereitgestellt werden. Namensgebung der Projektseiten folgt einem Muster mit Projekt-ID oder Name. Zudem gelten alle generellen Standards (Klassifizierung, Berechtigungsprinzip etc.) auch hier.

Prozess: Bei Initiierung eines neuen Projekts (oft nach einem Projektauftrag) wird – analog zu Szenario 1 – eine neue Projektakte angelegt. Der Antrag enthält die Projekt-ID, Namen der Kernteam-Mitglieder und voraussichtliche Laufzeit. Nach Genehmigung erstellt das System die Site aus der Projektvorlage. Während der Laufzeit pflegen Projektmitarbeiter alle relevanten Infos in dieser Site. Zum Projektende gibt es einen definierten Abschluss-Check: Der Projektleiter stellt sicher, dass z.B. das Lessons-Learned-Dokument im Ordner „Berichte“ abgelegt ist und die Risiko-Liste final aktualisiert ist.

Technische Umsetzung: Hier kommen Site Templates (SharePoint) oder Teams-Templates zum Einsatz, um die Struktur vorzugeben. Rollenpakete lassen sich mit Azure AD-Gruppen oder in Provisionierungs-Tools abbilden (z.B. Angabe einer gesamten AD-Gruppe für das Projektteam im Antrag, die dann als Member hinzugefügt wird). Ein Workflow könnte am Ende des Projekts automatisch ausgelöst werden (z.B. bei angegebenem Enddatum), um den Abschluss-Check einzuleiten oder die Site auf „Nur-Lesen“ zu setzen.

Kontrollen & KPI: Als Kontrolle dient ein Projektabschluss-Review: das PMO prüft stichprobenartig, ob in der Projektakte alle geforderten Dokumente vorhanden sind. KPI könnten sein: Projektdokumentationsquote (Anteil der Projekte, die alle Pflichtdokumente enthielten), Durchlaufzeit Projektanlage (wie schnell nach Freigabe war der Projektraum nutzbar) und Wiederverwendungsquote (z.B. wie oft Projektvorlagen für neue Projekte übernommen wurden).

Risiken/Antipatterns: Ein mögliches Problem ist Überfrachtung: Wenn die Vorlage zu viele unnötige Listen/Ordner enthält, fühlen sich Projekte gegängelt und pflegen die Inhalte nicht. Umgekehrt können fehlende Elemente dazu führen, dass jeder doch wieder eigene Strukturen baut. Deshalb muss das Template gepflegt und bei Bedarf angepasst werden. Auch wichtig: Nicht alle Projekte sind gleich – für Ausnahmen sollte es einen Prozess geben (z.B. genehmigte Abweichungen bei sehr kleinen oder sehr speziellen Projekten).

Praxisbeispiel: Die Stadtverwaltung einer Großstadt nutzt ein einheitliches Projektraum-Template für alle IT-Projekte. Darin sind von Anfang an ein Task-Board (Planner), ein Risiko-Register und Vorlagen für Projektstatusberichte enthalten. Das PMO berichtet, dass die Qualität der Projektdokumentation deutlich gestiegen ist, weil kein Projektteam mehr vergisst, diese Elemente anzulegen – sie sind ja schon da. Gleichzeitig können neue Projektleiter viel schneller starten, da sie eine vollständige Grundstruktur vorfinden.

Szenario 3: Externe Zusammenarbeit mit klaren Freigaberichtlinien

Ziel und Nutzen: Zusammenarbeit mit externen Partnern (Kunden, Lieferanten, etc.) soll ermöglicht, aber sicher gestaltet werden. Governance stellt sicher, dass externe Zugriffe kontrolliert erfolgen: Welche Informationen dürfen geteilt werden, wie werden Gäste verwaltet, und was ist verboten (z.B. freigegebene Links ohne Passwort). Der Nutzen: Effiziente Kollaboration über die Organisationsgrenzen hinweg, ohne die Datenhoheit und Compliance zu gefährden.

Beteiligte Rollen: Site-Eigentümer müssen bei externen Freigaben besonders sorgfältig handeln – sie dürfen Gäste nur gemäß den Richtlinien einladen und überprüfen. IT-Sicherheit und Datenschutz definieren diese Richtlinien (etwa welche Daten als vertraulich gelten und nicht extern geteilt werden dürfen). IT-Betrieb setzt die technischen Einstellungen (z.B. globale Externeinstellungen, Gastzugriff an/aus, Domain Allow-/Blocklisten) und überwacht die Nutzung. Revision kann stichprobenartig prüfen, ob externe Zugänge ordentlich dokumentiert sind.

Policies/Standards: Wesentlich ist eine Policy für externe Zusammenarbeit: z.B. „Externe Dürfen nur in dedizierten Teams mit dem Sensitivitätslabel ‚Extern‘ eingeladen werden“ oder „Vertrauliche Inhalte dürfen nicht via OneDrive geteilt werden“. Gastkonten-Management ist Teil der Standards: Jeder Gast erhält einen namentlichen Account in Entra ID (Azure AD) und muss bestimmten Regeln folgen (z.B. MFA-Pflicht, automatisches Ablaufdatum nach 90 Tagen Inaktivität). Anonyme Freigabelinks sind unterbunden; stattdessen nur adressierte Einladungen. Zudem sollte geklärt sein, wer die Verantwortung für externe im System trägt (z.B. muss ein interner Sponsor benannt sein).

Prozess: Wenn ein Mitarbeiter Inhalte extern teilen möchte, beantragt er ggf. die Einrichtung eines gemeinsamen Team-Bereichs für externe Zusammenarbeit. Alternativ (bei bestehenden Teams): er fordert die Freigabe für einen konkreten externen Nutzer an. In beiden Fällen prüft ein Verantwortlicher (z.B. der Datenschutzbeauftragte bei sensiblen Daten oder der Vorgesetzte) den Zweck und Umfang. Nach Freigabe wird entweder ein neuer Bereich mit entsprechenden Einstellungen erstellt (z.B. Team „Projekt X – Extern“ mit geringerem Berechtigungsumfang) oder der Gastnutzer dem vorhandenen Team hinzugefügt. Während der Zusammenarbeit ist definiert, welche Inhalte extern geteilt werden dürfen (evtl. nur ein Unterordner mit geringfügigen Daten, keine personenbezogenen Daten etc.). Bei Projektende oder nach definierter Zeitspanne werden externe wieder entfernt.

Technische Umsetzung: Microsoft 365 bietet viele Schalter: Im Azure AD kann man Gast-Zugriff zentral steuern (MFA erzwingen, Gastberechtigungs-Einschränkungen), in SharePoint kann man den externen Teilen-Modus pro Site festlegen (z.B. „Nur vorhandene Gäste“). Sensitivity Labels können genutzt werden, um Sites als „Extern“ zu markieren und damit z.B. zu verhindern, dass als „Vertraulich“ markierte Dokumente überhaupt extern geteilt werden. Ein Power Automate Flow kann dazu dienen, externe Freigaben genehmigen zu lassen (z.B. bei Hochstufung eines Team auf extern zugänglich, erst Freigabe durch IT-Security einholen). Wichtig ist auch die Schulung der Benutzer, damit sie wissen, wie sie korrekt teilen (z.B. keinen Inhalt einfach per E-Mail-Anhang senden, sondern über die vorgesehenen SharePoint/Teams-Mechanismen).

Kontrollen & KPI: Regelmäßig sollte ein Gastnutzer-Review stattfinden: Welche Gäste sind noch aktiv, wann haben sie zuletzt zugegriffen? KPI wie Anzahl Gäste insgesamt, Anteil der Sites mit externen und Anzahl der freigegebenen Dateien zeigen die Verbreitung. DLP-Regeln können als Kontrollen dienen, um z.B. Alarm zu schlagen, wenn jemand sensible Dateien einem Gast freigibt. Eine weitere Kontrolle: Automatische Ablaufdaten für Gastzugriff (Azure AD Access Reviews kann Gastzugriffe nach X Tagen entfernen, falls nicht verlängert).

Risiken/Antipatterns: Ohne klare Regeln droht entweder Wildwuchs (zu viele Freigaben, unbekannte Gäste im Tenant) oder übertriebenes Verbot (die Nutzer weichen dann auf nicht genehmigte Methoden aus, z.B. private Dropbox). Ein Antipattern wäre, externe generell zuzulassen, aber niemand fühlt sich zuständig für das Aufräumen – dann sammelt sich ein Haufen verwaister Gastkonten an. Ebenso problematisch: Daten werden unkontrolliert per E-Mail an Externe geschickt, weil die SharePoint-Freigabe als zu umständlich empfunden wird.

Praxisbeispiel: Ein mittelständischer Maschinenbauer arbeitet häufig mit externen Ingenieurbüros zusammen. Er hat dafür pro Projekt ein Team mit dem Label „Extern“ eingerichtet, in dem Zeichnungen und Dokumente geteilt werden. Die externen Partner müssen sich über Azure AD mit MFA anmelden. Alle 90 Tage werden ihre Zugriffsrechte automatisch entzogen, falls das Projekt nicht verlängert wird. Dadurch behält das Unternehmen die Kontrolle über seine Daten, während die Zusammenarbeit reibungslos klappt.

Szenario 4: Berechtigungs-Rezertifizierung mit Nachweis (quartalsweise)

Ziel und Nutzen: Über die Zeit sammeln sich in Teams und Sites viele Berechtigungen an. Die regelmäßige Rezertifizierung bedeutet, dass z.B. alle drei Monate überprüft wird, wer noch Zugriff benötigt. Dies erhöht die Sicherheit (entfernt Karteileichen) und erfüllt Compliance-Anforderungen, indem nachgewiesen werden kann, dass Zugriffsrechte aktuell und gerechtfertigt sind.

Beteiligte Rollen: Hier sind in erster Linie die Site-Eigentümer gefordert, denn sie kennen ihr Team am besten und müssen entscheiden, wer bleiben darf. IT-Betrieb oder das Security-Team orchestriert den Prozess (verschickt Erinnerungen, stellt Tools bereit). Revision und Compliance Officers können die Ergebnisse später einsehen, um zu prüfen, dass alles ordnungsgemäß erfolgte.

Policies/Standards: In der Governance ist festgelegt: Zugriffsrechte-Review alle X Monate ist Pflicht für bestimmte Bereiche. Zum Beispiel müssen alle vertraulichen Projekträume quartalsweise rezertifiziert werden, weniger kritische evtl. halbjährlich. Es gibt ein Standardverfahren dafür (wer initiiert, Fristen, Dokumentation). Wichtig: Eine klare Accountability muss definiert sein (z.B. „Fehlende Bestätigung führt zur Eskalation an den Vorgesetzten des Eigentümers“).

Prozess: Zu Stichtagen (z.B. jeweils 1. Januar, 1. April, usw.) generiert die IT einen Bericht aller Nutzer pro Team/Site und sendet diesen an die jeweiligen Eigentümer mit der Aufforderung zur Bestätigung. Der Eigentümer prüft die Liste: Nutzer, die das Team verlassen haben oder den Zugriff nicht mehr brauchen, werden entfernt. Idealerweise gibt es ein einfaches Web-Interface oder Formular, wo der Owner per Klick „Bestätigen“ oder „Entfernen“ markieren kann. Nach Durchlauf dokumentiert das System, dass Team X am Datum Y von Owner Z überprüft wurde. Falls ein Owner nicht reagiert, gehen automatische Erinnerungen raus und letztlich wird eskaliert (z.B. an IT-Security oder den Fachvorgesetzten).

Technische Umsetzung: Microsoft stellt mit Azure AD Access Reviews (in Azure AD P2/Entra ID Governance) ein passendes Feature bereit: man kann regelmäßige Reviews für Gruppen/Teams definieren, die dann vom Owner via Portal durchgeführt werden. Alternativ kann ein PowerShell-Skript regelmäßig Listen ziehen und Mails verschicken; oder man nutzt ein Governance-Tool, das Rezertifizierungen modulartig enthält. Wichtig ist, dass die Ergebnisse gespeichert werden (Nachvollziehbarkeit!). Oft werden diese Reports für Audits aufbewahrt.

Kontrollen & KPI: Ein KPI hier ist die Rezertifizierungsquote: Haben 100% der kritischen Teams das Review im Quartal durchlaufen? Wie viele Zugriffe wurden entzogen (Anzeichen, dass es vorher Überberechtigungen gab)? Kontrollen sind automatische Logiken: z.B. nach 14 Tagen keine Reaktion -> Reminder, nach 1 Monat -> Meldung an Compliance. Die Nachweise selbst (Berichte) sind ebenfalls Kontrollpunkte, die von Revision gesichtet werden können.

Risiken/Antipatterns: Gefahr ist, dass Owner das Review pro forma abnicken, ohne wirklich zu prüfen – dann hat man den Prozess formal erfüllt, aber nicht inhaltlich. Schulung und Sensibilisierung sind daher wichtig. Ein Antipattern wäre, den Prozess zu komplex zu machen (z.B. verlangt man detaillierte Begründungen für jeden einzelnen Zugriff) – dann sinkt die Akzeptanz. Auch muss man aufpassen, dass gelöschte Zugriffe nicht gleich wieder reinrutschen, weil jemand denselben Nutzer über eine Gruppe wieder hinzufügt: Daher sollte man in der Rezertifizierung auch die Mechanik (Einzelberechtigungen vs. Gruppen) im Blick haben.

Praxisbeispiel: Ein Finanzdienstleister hat für alle sensiblen SharePoint-Bereiche (z.B. Vorstandsteams, HR, Finanzen) vierteljährliche Access Reviews eingerichtet. In den ersten Durchläufen wurden jeweils 10-15% der Berechtigungen entzogen (ehemalige Mitarbeiter, temporäre Projektteilnehmer). Die Verantwortlichen berichten, dass sie jetzt deutlich besser überblicken, wer auf ihre Bereiche zugreift, und interne Audits haben dies als Best Practice hervorgehoben.

Szenario 5: Lebenszyklussteuerung – Inaktivitäts-Archiv und geregelte Löschung

Ziel und Nutzen: SharePoint-Bereiche sollen nicht endlos bestehen, wenn sie ihren Zweck erfüllt haben. Durch eine Lebenszyklus-Steuerung bleiben die Inhalte aktuell und rechtlich sauber: Inaktive Bereiche werden erkannt, wichtige Inhalte archiviert (und falls nötig als Records aufbewahrt) und irgendwann werden obsolet gewordene Daten gelöscht. Das reduziert Speicher- und Verwaltungsaufwand und minimiert Risiken (alte Inhalte, die evtl. falsch oder sensibel sind, schlummern nicht unbemerkt herum).

Beteiligte Rollen: Der Records Manager definiert die Aufbewahrungsfristen für verschiedene Inhalte. Site-Eigentümer spielen eine Rolle, wenn es darum geht, Inaktivität zu bestätigen („Ja, dieses Projekt ist abgeschlossen, kann archiviert werden“). IT-Betrieb implementiert die Mechanismen (z.B. Inaktivitäts-Job, Archivschritte) und Revision kontrolliert, dass wirklich nach Plan gelöscht wird. Datenschutz hat Interesse daran, dass personenbezogene Daten nicht länger als zulässig gespeichert bleiben.

Policies/Standards: Oft gibt es Site-Lebenszyklus-Policies: z.B. „Projekt-Sites werden spätestens 6 Monate nach Projektende geschlossen“ oder „Inaktive Team-Sites (12 Monate ohne Aktivität) werden archiviert“. Eine Archivierungsrichtlinie definiert, was Archivieren bedeutet (z.B. auf Read-Only setzen, Owners entziehen oder an Records Manager übertragen, Inhalte in speziellen Archivbereich überführen). Die Löschrichtlinie hängt oft an Aufbewahrungsfristen: z.B. „Geschäftsunterlagen 10 Jahre, danach Löschung“ oder „Personaldaten 6 Jahre nach Austritt“. Wichtig: diese Regeln müssen greifbar (automatisiert) sein, sonst werden sie vergessen.

Prozess: Ein typischer Lifecycle-Prozess: Ein Monitoring identifiziert eine Site als inaktiv (etwa weil 180 Tage lang keine Datei geöffnet wurde). Daraufhin wird der Site-Eigentümer automatisiert informiert: „Ihr Bereich XYZ scheint inaktiv. Bitte entscheiden Sie: weiter nutzen (verlängern) oder archivieren?“. Reagiert er nicht, wird nach Erinnerung der Bereich in den Archivzustand versetzt. Im Archivzustand wird die Site z.B. schreibgeschützt und nur noch für Lesen behalten. Eventuell werden Inhalte mit Retention Labels versehen (à la „Record – nicht verändern/löschen bis Datum X“). Nach Ablauf der gesetzlichen Frist oder einer vordefinierten Zeit (z.B. 3 Jahre Archiv) initiiert das System die endgültige Löschung: die Site wird gelöscht, ein Backup/Export der wichtigsten Metadaten kann für Nachweise behalten werden.

Technische Umsetzung: In SharePoint Online gibt es Out-of-the-Box Site Expiration für M365-Gruppen: Man kann z.B. festlegen, dass Gruppen (und deren Sites) nach 6 Monaten erneuert werden müssen oder automatisch entfernt werden. Diese Renewal-Mails gehen an Owner und können den Prozess teilweise abbilden. Für Archivierung können Retention Labels verwendet werden, um Inhalte als Records (unveränderbar) zu deklarieren und eine Aufbewahrungsdauer zu setzen. Manche Organisationen nutzen auch separate Archiv-Sites: Inhalte werden mittels Skript in eine zentrale Archiv-SiteCollection verschoben, die nur für Compliance zugänglich ist. Ein Provisioning-/Governance-Tool kann Lifecycle ebenfalls automatisieren (siehe CosyTrack.Provisioner mit Inaktivitätschecks).

Kontrollen & KPI: Hier sind Berichte über inaktive Sites zentral (KPI: % der Sites, die >12 Monate inaktiv sind). Kontrollen: Der Inaktivitäts-Scan selbst ist eine Kontrolle. Die Löschdurchführung sollte protokolliert werden (Audit-Log). KPI könnte auch die Lösch-Compliance sein: Anteil der Inhalte, die nach Frist X auch tatsächlich gelöscht wurden. Weitere Kennzahl: Anzahl archivierter Sites pro Quartal (als Maß für „Aufräum-Fortschritt“).

Risiken/Antipatterns: Eine Falle ist, dass niemand die Verantwortung fürs Archivieren/Löschen übernimmt und die Regeln nur auf dem Papier stehen. Auch können Nutzer Archive umgehen, indem sie Sites „künstlich am Leben halten“ (einfach irgendwas bearbeiten, um Aktivität vorzutäuschen) – das muss nicht böswillig sein, oft hängen sie einfach an ihren Ablagen. Antipattern: man löscht zu aggressiv ohne Rücksprache, was zu Unmut führt oder im Worst Case zum Verlust noch benötigter Infos. Daher sind Transparenz und Kommunikation über den Lifecycle-Prozess wichtig.

Praxisbeispiel: Eine Krankenversicherung hat für Teamsites einen automatischen Lifecycle eingeführt. Nach 1 Jahr ohne Dateienzugriff bekommt der Owner eine E-Mail, nach 1,5 Jahren wird das Team als „inaktiv“ markiert (und nur noch Lesezugriff gestattet), nach 3 Jahren wird es gelöscht. Durch diesen Prozess konnten in einem Audit verwaiste Altdaten um 40% reduziert werden, ohne dass relevante Infos verloren gingen – man stellte fest, dass die meisten inaktiven Bereiche wirklich nicht mehr gebraucht wurden.

Szenario 6: Sensitivity Labels und DLP für vertrauliche Informationen

Ziel und Nutzen: Schützenswerte Informationen (etwa personenbezogene Daten, Finanzzahlen, Betriebsgeheimnisse) müssen besonders gesichert werden. Durch Sensitivity Labels (Vertraulichkeitskennzeichnung) wird bereits beim Speichern klar, wie sensitiv ein Dokument ist, und durch DLP-Regeln (Data Loss Prevention) wird verhindert, dass solche Inhalte unkontrolliert das Unternehmen verlassen. Der Nutzen: Vertrauliches bleibt vertraulich, das Risiko von Datenpannen sinkt drastisch, während Mitarbeiter dennoch flexibel arbeiten können.

Beteiligte Rollen: Informationssicherheitsbeauftragte bzw. Datenschutz legen fest, welche Klassifizierungsstufen es gibt und welche Schutzmaßnahmen je Stufe greifen. IT-Betrieb implementiert die Labels im M365 Compliance Center und stellt DLP-Policies ein. Endanwender (Dokument-Autoren) tragen Verantwortung, Inhalte korrekt zu klassifizieren (ggf. werden sie vom System dazu gezwungen). Das Security Operations Team überwacht die DLP-Vorfälle und geht diesen nach.

Policies/Standards: Es gibt eine Klassifizierungsrichtlinie: z.B. 4 Stufen (Offen, Intern, Vertraulich, Streng Vertraulich) mit Definitionen und Beispielen. Jede Stufe hat Standards: z.B. „Streng Vertraulich: darf nicht extern geteilt werden, ist verschlüsselt, nur bestimmte Personen haben Zugriff“. Sensitivity Labels werden so konfiguriert, dass sie diese Regeln erzwingen (z.B. für höchste Stufe externer Zugriff = verboten). DLP-Standards definieren, welche Datentypen erkannt werden (Kreditkartennummern, Gesundheitsdaten etc.) und was bei Erkennung passiert (Blockieren, Benutzerwarnung, Meldung ans Security-Team). Außerdem: Schulungsstandard – alle Mitarbeiter werden im Umgang mit vertraulichen Infos geschult und auf die Kennzeichnungspflicht hingewiesen.

Prozess: Sobald ein Nutzer ein Dokument hochlädt oder erstellt, muss er ggf. eine Klassifizierung auswählen (man kann z.B. per Policy verlangen, dass alle Dokumentbibliotheken ein Standard-Label haben). Wenn das Dokument etwa als „Vertraulich“ gekennzeichnet ist, greift automatisch die hinterlegte Policy: z.B. nur interne Mitglieder dürfen es lesen; wenn jemand versucht, es extern zu teilen, wird dies geblockt oder eine Extra-Genehmigung verlangt. Im Hintergrund laufen DLP-Scanner: Laden Nutzer Dateien hoch, die z.B. 10 Kreditkartennummern enthalten und versuchen die extern zu teilen, dann greift eine DLP-Regel und blockiert diese Aktion, zugleich erhält der Compliance Officer einen Vorfallbericht.

Technische Umsetzung: Microsoft Purview (Compliance) bietet Sensitivity Labels mit Verschlüsselung und DLP-Policies out-of-the-box. Diese lassen sich tenantweit definieren und auf SharePoint, OneDrive, Teams-Chats anwenden. Beispielsweise kann ein Label „Streng Vertraulich“ so eingestellt werden, dass Dokumente damit nur von Mitgliedern der eigenen Organisation nach MFA zugreifen werden können und auch im Download-Fall verschlüsselt bleiben. DLP-Regeln können z.B. vorkonfigurierte Muster (IBAN, Personalausweisnummer etc.) erkennen. Die technische Herausforderung ist oft die Feineinstellung, damit es einerseits wirksam ist, aber nicht zu viele False Positives produziert, die den Arbeitsfluss stören.

Kontrollen & KPI: Hier wird viel automatisiert kontrolliert: KPI sind z.B. Anteil der Dokumente mit Label (Ziel: 100% in sensiblen Bereichen), Anzahl DLP-Vorfälle pro Monat (sollte mit der Zeit sinken, wenn Nutzer sensibilisiert sind). Als Kontrolle kann ein monatlicher DLP-Report dienen, den das Security-Team durchgeht, um Muster zu erkennen (z.B. häufen sich Vorfälle in Abteilung X?). Auch kann man stichprobenartig prüfen, ob Dokumente korrekt klassifiziert wurden (Audit durch InfoSec).

Risiken/Antipatterns: Ein Risiko ist Overkill: Zu restriktive Regeln führen dazu, dass Mitarbeiter sich behindert fühlen und kreative Workarounds suchen (z.B. Screenshots machen, Daten abtippen, um DLP zu umgehen). Daher muss die Balance stimmen. Ein Antipattern wäre, Labels einzuführen, aber nicht zu kontrollieren – wenn jeder einfach „Intern“ auf alles lässt, weil es die Standardeinstellung ist, hat man keine Sicherheit gewonnen. Auch schlechtes Handling von False Positives kann zu Frust führen (wenn legitime Vorgänge dauernd blockiert werden).

Praxisbeispiel: Ein Krankenhaus hat für alle Patientendaten-Dokumente das Label „Patientendaten – Vertraulich“ eingeführt. Beim Versuch, solche Dokumente extern zu teilen, wird der Vorgang unterbunden und das Security-Team informiert. Anfangs gab es viele Warnungen, doch nach Schulungen gingen die Vorfälle zurück. Inzwischen sind 95% aller Dokumente in sensiblen Bereichen korrekt klassifiziert und es gab keine bekannten Datenlecks mehr über die offizielle Plattform.

Szenario 7: Ablösung von E-Mail & File Share durch SharePoint-Regeln

Ziel und Nutzen: Viele Unternehmen leiden unter vollgestopften E-Mail-Postfächern und verstreuten File Shares. Dieses Szenario zielt darauf ab, E-Mail-Anhänge und Netzlaufwerke als primäre Ablage abzulösen und stattdessen SharePoint/Teams als zentralen Ort für Dokumente zu etablieren. Nutzen: Es gibt eine Single Source of Truth, Versionschaos wird reduziert, Suchen geht schneller, und die Kollaboration verbessert sich (gleichzeitiges Bearbeiten statt Serien von Mail-Anhängen).

Beteiligte Rollen: IT-Leitung und Geschäftsführung müssen hier oft als Sponsoren auftreten, denn es geht um Kulturwandel. IT-Betrieb sorgt für technische Rahmenbedingungen (z.B. genug SharePoint-Speicher, Abschalten alter File-Server schrittweise). Fachbereichsleitung und Power User fungieren als Multiplikatoren, die im Team darauf achten, dass Dateien im Team gespeichert werden statt lokal. Change Manager (siehe Abschnitt 14) begleiten diese Umstellung mit Schulungen.

Policies/Standards: Eine klare Ablagerichtlinie: z.B. „Geschäftsrelevante Dateien dürfen nicht allein auf persönlichen Laufwerken oder in E-Mails gehalten werden; sie müssen im dafür vorgesehenen SharePoint-Bereich abgelegt werden.“ Eventuell technische Mail-Regeln: ein Anhang > X MB wird geblockt mit Hinweis, einen SharePoint-Link zu verwenden. Versionierungsstandard: In allen Bibliotheken ist Versionierung aktiv, daher bitte kein manuelles „Dokument_final_v3.docx“ mehr. Ordnerstruktur & Benennung: Vorgaben, wie Dokumente einzuordnen sind, damit sie wiederfindbar sind (z.B. Dokumente im Projekt gehören in die Projekt-SharePoint, nicht ins persönliche OneDrive). Auch: Offboarding-Prozess stellt sicher, dass E-Mails von gehenden Mitarbeitern durchsucht werden nach geschäftsrelevanten Anhängen, die dann überführt werden.

Prozess: Die Einführung läuft oft als Projekt: Zuerst werden Nutzungsdaten analysiert (wie viele Mails mit Attachments, welche Abteilungen nutzen noch File Shares). Dann werden Pilot-Teams in SharePoint migriert. Im Alltag gibt es konkrete Regeln: Z.B. Projektberichte sind nicht per Mail an alle zu schicken, sondern in SharePoint abzulegen und nur der Link wird verschickt. Alte Netzlaufwerke werden schrittweise auf read-only gesetzt, damit neue Dateien nur noch ins neue System gehen. Die IT kann auch Tools bereitstellen: z.B. ein Outlook-AddIn „Als Link teilen“ oder automatische Notifikationen, wenn jemand eine große Datei anhängt („Möchten Sie stattdessen einen OneDrive-Link senden?“).

Technische Umsetzung: Microsoft 365 unterstützt dies mit OneDrive/SharePoint Integration in Outlook (Cloud-Anhänge). Admins können via Exchange Transport Rules warnen oder blocken, wenn sensible Anhänge gesendet werden. Microsoft Teams fördert das Ablegen von Dateien direkt im Kanal (statt über E-Mail zu teilen). Zudem können Migrationstools genutzt werden, um bestehende File Shares in Dokumentbibliotheken zu überführen, damit die Nutzer ab Tag X dort weiterarbeiten. Wichtig ist auch die Suche: mit SharePoint Search und Delve können Nutzer unternehmensweit Inhalte finden, was bei dezentralen Laufwerken kaum möglich war.

Kontrollen & KPI: Ein interessanter KPI ist die Anzahl der versendeten Mail-Anhänge pro Benutzer (sollte sinken) versus Anzahl der in SharePoint gespeicherten Dokumente (sollte steigen). Auch die Speicherbelegung auf File-Servern gegenüber SharePoint kann gemessen werden. Kontrollen: IT kann Reports fahren über Top-Anhänge-Versender und diese gezielt ansprechen. Oder es werden Stichproben gemacht, ob wichtige Dokumente auch wirklich in den Team-Sites liegen und nicht nur lokal.

Risiken/Antipatterns: Der größte Faktor ist Mensch & Gewohnheit. Ein Antipattern ist zu glauben, eine Policy allein reicht – ohne Change Management werden viele weiter ihre alten Wege gehen. Auch fatal: wenn die SharePoint-Lösung nicht performant oder die Struktur unlogisch ist, wechseln die Nutzer entnervt zurück zu E-Mail. Hier ist Feedback-Loop wichtig. Risiko ist auch Überforderung: wenn alles auf einmal umgestellt wird, könnte Chaos entstehen – besser etappenweise mit Unterstützung.

Praxisbeispiel: Die Contoso Bank hat in einem Jahr ihr altes Netzlaufwerk komplett migriert: 5 Millionen Dateien landeten in SharePoint Online, strukturiert nach Abteilungen. Sie setzte eine Regel auf Exchange: E-Mails intern mit Anhängen >10MB werden geblockt. Ergebnis: Die Zahl der Mail-Anhänge sank um 60%, während SharePoint- und Teams-Nutzung stark stieg. Mitarbeiter berichten, dass es zunächst Umstellungsschwierigkeiten gab, nun aber alle die Vorteile der gemeinsamen Ablage schätzen (keiner fragt mehr „Schick mir mal Version X“).

Szenario 8: Mandantenweite Such- und Taxonomie-Governance

Ziel und Nutzen: Eine leistungsfähige Suche und konsistente Taxonomie sorgen dafür, dass Mitarbeiter Informationen schnell finden, auch wenn unterschiedliche Begriffe benutzt werden. Durch Governance der Suchfunktionen (Synonyme, Favoriten) und der zentralen Term-Speicher (Managed Metadata) wird das Wissensmanagement gestärkt. Nutzen: Weniger Suchaufwand, weniger Dubletten, mehr Wiederverwendung von vorhandenem Wissen.

Beteiligte Rollen: Der Informationsarchitekt oder Knowledge Manager ist hauptverantwortlich für die Pflege der Taxonomie und für die Konfiguration der Suchfeatures. Fachbereiche liefern Input zu branchenspezifischen Begriffen und Abkürzungen (die als Synonyme hinterlegt werden sollten). IT-Betrieb stellt die Indizierung sicher und behält Performance im Auge. Endanwender können über Feedback-Mechanismen (z.B. „Hat diese Suche geholfen?“) indirekt beitragen.

Policies/Standards: Es gibt einen Taxonomie-Standard: Nutzung des Managed Metadata Service in SharePoint für unternehmensweite Begriffe (z.B. Liste aller Produktnamen, offiziellen Organisationsbezeichnungen etc.). Frei sollte z.B. niemand einfach eigenständig neue globale Terms einfügen, dafür gibt es einen Prozess. Synonym-Management: Für wichtige Begriffe werden Synonyme und Akronyme gepflegt (z.B. „HR“ = „Human Resources“ = „Personal“). Search Best Practices sind dokumentiert (z.B. wie man Schlagworte vergibt, welche Metadaten durchsucht werden). Außerdem kann man Promoted Results definieren – für bestimmte Suchwörter (z.B. „Urlaub“) erscheint als erstes ein Treffer zur HR-Seite.

Prozess: Bei der Einführung wird bestehendes Vokabular gesammelt und im Term Store abgebildet. Es gibt einen laufenden Prozess: z.B. monatliches Search-Tuning Meeting, in dem das Team prüft, welche Suchanfragen häufig keine Ergebnisse liefern – daraus leitet man neue Synonyme oder Tags ab. Neue Projekte oder Abteilungen können über ein Formular beantragen, dass ihre spezifischen Begriffe in die Taxonomie aufgenommen werden. Die Inhalte-Ersteller (z.B. beim Hochladen eines Dokuments) werden angewiesen, aus dem vorgegebenen Wortschatz zu verschlagworten statt freie Tags zu erfinden. Die Suche wird konfiguriert, dass sie die Managed Metadata und Synonyme mit einbezieht.

Technische Umsetzung: In SharePoint Online kann man mit SharePoint Synonyms/Acronyms (via Microsoft Search admin center) oder Term Store arbeiten. Der Term Store ermöglicht hierarchische, übergreifende Schlagwort-Listen; Synonyme können als Eigenschaften eines Terms hinterlegt werden. Moderne Microsoft Search erlaubt sogar Vertikalen (eigene Suchbereiche) und Bookmarks. Es kann sinnvoll sein, für komplexe Szenarien ein Tool wie Microsoft Viva Topics zu prüfen, das KI-gestützt Begriffe erkennt und verknüpft. Allerdings schlägt Governance auch hier vor: manuell gepflegte Inhalte (z.B. Who’s Who in Glossar-Form) sollten vorhanden sein, damit Viva Topics sinnvoll trainiert wird.

Kontrollen & KPI: Erfolg sieht man z.B. in der Such-Zufriedenheit (vielleicht gemessen über Befragungen oder über die Quote der Suchanfragen, die ohne Ergebnis bleiben). KPI: Anzahl gepflegter Synonympaare, Anzahl der Suchabfragen mit Klick auf Top-Treffer (Zeichen für Relevanz). Kontrollen sind eher qualitativ: Der Informationsarchitekt wertet regelmäßig die Such-Logs aus und kontrolliert, ob wichtige Begriffe evtl. neue Tags brauchen. Bei inkonsistenten Tags in Inhalten wird nachgeschult.

Risiken/Antipatterns: Ein typisches Problem: Über-Engineering – eine zu komplexe Taxonomie, die keiner versteht, oder hunderte Schlagworte, die kaum genutzt werden. Dann ignorieren die Nutzer das System. Ein Antipattern ist auch, den Term Store gar nicht zu pflegen: Dann entstehen parallel zig Schreibweisen („CRM“, „C.R.M.“, „CustomerRelationship“ etc.) und die Suche findet nicht alles. Wenn jeder Bereich eigenständig Tags erstellt, verliert man den Überblick. Also: Balance zwischen zentraler Kontrolle und genug Flexibilität finden.

Praxisbeispiel: Ein Pharma-Unternehmen hat ein zentrales Thesaurus-Team gebildet, das alle Fachbegriffe (Medizin, Produkte, Studiennamen) im Term Store verwaltet. Suchen nach internen Produktnamen liefern nun dank Synonymen auch Dokumente, in denen nur der Entwicklungs-Codename stand. Die Trefferqualität stieg messbar, was die Akzeptanz von SharePoint als Wissensdrehscheibe erhöht hat.

Szenario 9: Notfall-/Incident-Prozess für schnelle Isolation und Wiederherstellung

Ziel und Nutzen: Im Fall eines Sicherheitsvorfalls (z.B. kompromittiertes Konto, Malware in einer SharePoint-Datei oder öffentlich gewordene vertrauliche Infos) muss schnell reagiert werden. Ein definierter Notfallprozess für SharePoint und Teams ermöglicht es, die betroffenen Bereiche sofort zu isolieren (Schaden begrenzen), forensische Beweise zu sammeln und dann zügig wiederherzustellen. Das minimiert den potenziellen Schaden und zeigt gegenüber Aufsichtsbehörden, dass man vorbereitet ist.

Beteiligte Rollen: IT-Security Incident Response Team führt im Ernstfall das Kommando: Sie haben Runbooks für O365-Vorfälle. IT-Betrieb unterstützt technisch (z.B. Berechtigungen entziehen, Backups einspielen). Site-Eigentümer oder Fachbereichs-Vertreter werden hinzugezogen, um inhaltlich einzuschätzen, welche Daten betroffen sind. Datenschutzbeauftragter muss eingebunden werden, falls personenbezogene Daten betroffen sind (Meldepflicht nach DSGVO innerhalb 72h!). Management und Kommunikation spielen ggf. auch eine Rolle (Abwägung Informationsweitergabe intern/extern).

Policies/Standards: Teil der Governance ist eine Incident-Response-Policy für Cloud-Dienste: wer darf im Notfall was tun? (Z.B. dürfen bestimmte Admins im Ernstfall eine Site einfrieren ohne extra Freigabe.) Standards wie Notfallberechtigungen (Break-Glass-Account) müssen definiert sein, falls normale Admin-Accounts kompromittiert sind. Es gibt einen Kommunikationsplan: wer wird wann informiert (z.B. Security-Team sofort, GF und Datenschutz binnen X Stunden). Zudem ein Standard für Forensik: alle relevanten Logs sichern, evtl. ein eDiscovery Case erstellen, betroffene Inhalte auf Hold setzen.

Prozess: Erkennungsphase: Ein Vorfall wird gemeldet oder durch Monitoring erkannt (z.B. plötzlich Massendownload durch einen User). Sofortmaßnahme: Das Team isoliert den Schaden – z.B. kompromittierten User blockieren, betroffene SharePoint-Site berechtigen nur für Admins (niemand sonst kommt mehr ran). Dann Analyse: Was ist passiert? Dazu werden Audit-Logs ausgewertet, verdächtige Dateien heruntergeladen und in sicherer Umgebung analysiert. Wenn nötig, wird ein Backup der Site gezogen oder eine Momentaufnahme für spätere Untersuchungen. Nach der Analysephase werden Wiederherstellungsmaßnahmen ergriffen: z.B. bereinigte Daten wieder bereitstellen, Benutzerpasswörter zurücksetzen, etc. Abschließend Review: Hat der Prozess funktioniert, was lernen wir daraus?

Technische Umsetzung: SharePoint Online ermöglicht via Administrative Berechtigungen schnelles Entziehen von Zugängen (z.B. über Security & Compliance Center kann man eine Location auf eDiscovery Hold setzen oder per PowerShell alle Nutzer entfernen). Versionierung und Papierkorb unterstützen bei Ransomware-Vorfällen (man kann verschlüsselte Dateien durch frühere Versionen ersetzen). Microsoft liefert auch Tools wie Alert Policies (z.B. Alarm bei Massendownloads) und Cloud App Security (Defender for Cloud Apps), um anormales Verhalten zu erkennen. Im Notfall können Snapshots von Site Collections gezogen werden (per PnP.PowerShell kann man z.B. Inhalte extrahieren). Wichtig ist, die Admins sind trainiert, diese Tools unter Zeitdruck richtig zu nutzen.

Kontrollen & KPI: Regelmäßige Notfallübungen (z.B. einmal jährlich) sind die beste Kontrolle, ob der Prozess funktioniert. KPI: Time to isolate (Zeit von Incident-Erkennung bis Isolation, angestrebt < 30 Minuten), Time to recover (bis Normalbetrieb wiederhergestellt). Auch: Anzahl Security-Incidents pro Jahr (hoffentlich niedrig). Checklisten „was tun bei Vorfall“ müssen aktuell gehalten werden (Kontrolle durch Reviews).

Risiken/Antipatterns: Ohne Vorbereitung herrscht im Ernstfall Chaos: niemand weiß, wer entscheiden darf, oder man verliert Zeit mit der Suche nach Logs. Ein Antipattern ist, Vorfälle zu verheimlichen oder zu zögern – bei Datenschutzvorfällen kann das rechtliche Folgen haben. Auch falsch: alles abzuschalten (z.B. ganze Plattform runterfahren), obwohl nur ein kleiner Bereich betroffen ist – das stört unnötig den Betrieb. Balance aus schnell und gezielt handeln ist wichtig.

Praxisbeispiel: Bei einem Energieversorger wurde ein internes Projekt-Team kompromittiert, weil ein externer Partneraccount missbraucht wurde. Dank vordefiniertem Plan sperrte die IT innerhalb von 15 Minuten den gesamten Team-Bereich (Zugriff nur noch für Admins), zog die Logfiles und konnte forensisch nachweisen, welche Dateien eventuell abflossen. Der betroffene Partner wurde informiert, Passwörter reset, und nach zwei Tagen konnte das Team, bereinigt und mit neuem Gastzugriffsprozess, wieder geöffnet werden. Die schnelle Eingrenzung verhinderte Schlimmeres und diente als Bewährungsprobe für das Incident Response Konzept.

Szenario 10: Mandanten-/Quota-Management und Kostentransparenz

Ziel und Nutzen: Auch wenn Cloud-Speicher vermeintlich unbegrenzt ist, gibt es finanzielle und Performance-Kosten. Governance umfasst daher das Kapazitätsmanagement: Monitoring von Tenant-Ressourcen (Speicherplatz, Anzahl Sites/Teams) und Steuerung über Quotas oder Richtlinien. Gleichzeitig sollen die Kosten transparent sein – etwa welcher Fachbereich wie viel vom SharePoint-Speicher nutzt – um Verursachergerechtigkeit zu fördern. Nutzen: keine Überraschungen bei Speicherbedarf/Lizenzen, Anreize zum Aufräumen, Budgetplanung für IT.

Beteiligte Rollen: IT-Betrieb/Plattform-Owner überwacht die Kapazitäten und setzt Limits. IT-Controlling oder die Geschäftsleitung interessiert die Kostenverteilung (z.B. wenn intern weiterverrechnet wird, wer viel verbraucht zahlt mehr). Fachbereichsleiter werden informiert, wenn ihr Bereich z.B. außergewöhnlich viel Speicher belegt, und müssen dann ggf. Entscheide treffen (Aufstocken des Budgets oder Aufräumen). Records Manager und Informationsarchitekt tragen indirekt bei: durch Lifecycle-Maßnahmen und effiziente Informationsstruktur steuern sie mit, dass nicht unnötig viel Ballast gespeichert wird.

Policies/Standards: Ein Speicher-Quota-Standard kann definieren: z.B. jede Abteilung hat 500 GB für ihre Sites, darüber hinaus muss begründet werden. Logging & Reporting-Standard: Es wird monatlich ein Report über die Nutzung (Sites, Speicher, aktive Nutzer) erzeugt. Kostenallokation: falls vorgesehen, wird z.B. Speicher oder zusätzliche Premium-Features (wie zusätzlicher Analytics-Tools) den Bereichen anteilig verrechnet. Zudem können Aufbewahrungsrichtlinien aus finanzieller Sicht betrachtet werden: Daten löschen spart Speicher, daher hat das auch Kostengründe neben Compliance.

Prozess: Regelmäßig (z.B. vierteljährlich) überprüft das IT-Team die Auslastung: Wie viel % des Tenant-Speichers ist belegt? Wo gibt es Ausreißer (Site XY mit 100 GB)? Dann wird gehandelt: ggf. Erhöhung des Speichers (Budgetantrag) oder Aufräumaktion im Bereich auslösen. Berichte werden an die Fachbereichsleiter geschickt: „Ihre Abteilung nutzt aktuell 20% des gesamten Speichers (500 GB)“. Bei Bedarf kann man Quotas technisch durchsetzen (auf Site-Collection-Ebene ein Limit setzen, das jedoch in SharePoint Online standardmäßig nicht mehr strikt ist, aber administrativ beobachtbar). Auch die Anzahl an aktiven Lizenzen wird überwacht – z.B. ungenutzte Accounts entfernen, um Kosten zu sparen.

Technische Umsetzung: In SharePoint Online lässt sich der Gesamtspeicher und pro Site Collection anzeigen (über Admin Center oder PowerShell). Zwar gibt es keine fest zugewiesenen Quotas mehr by default (außer man setzt sie manuell), aber per Skript können Alerts eingerichtet werden, wenn eine Site > X GB wächst. Power BI kann genutzt werden, um einen schönen Kosten-/Nutzungs-Dashboard zu bauen (Daten aus M365 Admin APIs). Azure AD und M365 Admin zeigen Lizenznutzung; über Skripte kann man z.B. alle 30 Tage Inaktive auflisten. Wichtig ist hier eher das Monitoring als die Echtzeitkontrolle.

Kontrollen & KPI: KPI könnten sein: Speicherverbrauch pro User (steigt der kontinuierlich?), Anzahl der Sites >100GB, Kosten pro aktivem Nutzer (Lizenzen/Storage). Kontrollen: monatlicher Report ans Management (Transparenz), Review-Meetings bei Überschreiten bestimmter Schwellwerte. In manchen Firmen wird ein Chargeback gemacht – das ist indirekt auch eine Kontrolle: wenn Bereich A für 2 TB zahlen muss, überlegt er sich, ob alles gebraucht wird.

Risiken/Antipatterns: Problematisch kann sein, Kosten zu verstecken – dann fehlt der Anreiz zur Optimierung. Ein Antipattern: strikte Quotas ohne Rücksicht auf tatsächliche Bedarfe (dann legen die Leute z.B. woanders Dateien ab oder beantragen ständig Erhöhung). Ebenso schlecht: gar keine Limits kommunizieren – dann ist das Erwachen groß, wenn plötzlich doch Speicher gekauft werden muss. Balance: angemessene Puffer, aber trotzdem Verantwortungsgefühl fördern.

Praxisbeispiel: Bei einer Versicherung wurden interne „Speicherkonten“ eingeführt: Jede Abteilung hatte 1 TB zugeteilt. Ein Dashboard zeigte live, wie viel sie nutzen. Die IT erkannte dadurch, dass einige Teams massenhaft Videos speicherten, was 30% des Speichers fraß. Daraufhin wurden für Videos Richtlinien eingeführt (Komprimierung, Ablage in Stream). Ergebnis: Der Speicherzuwachs konnte um 50% gebremst werden und die Abteilungen optimierten ihren Datenhaushalt, da sie erstmals Transparenz hatten.

8. Produktbezug: CosyTrack.Provisioner in der Umsetzung

Um die genannten Governance-Bausteine effizient umzusetzen, setzen manche Organisationen auf spezialisierte Tools. CosyTrack.Provisioner ist ein Beispiel für eine Lösung, die Provisionierung und Governance-Automatisierung für SharePoint und Teams bietet. Im Folgenden wird aufgezeigt, wie so ein Tool die verschiedenen Governance-Aspekte abdecken kann:
– Vorlagenkatalog & Blueprints: CosyTrack.Provisioner verwaltet zentral Site- und Teams-Vorlagen. Jede Vorlage definiert Struktur (z.B. Kanäle, Bibliotheken, Ordner), vordefinierte Listen oder Planner sowie Metadaten. So wird bei jeder neuen Bereitstellung ein konsistentes Grundgerüst erstellt. Beispiel: Ein „Projekt-Workspace“-Blueprint enthält bereits die Listen „Risiken“ und „Entscheidungen“ sowie eine Dokumentbibliothek mit Ordnern für Phasen.
– Namenskonvention & Klassifizierung: Bei der Anlage erzwingt das Tool Namenspräfixe oder Suffixe nach Regel (z.B. „INT-“ für interne Teams). Der Antragsdialog kann ein Pflichtfeld „Vertraulichkeitsstufe“ haben; wählt der Nutzer z.B. „Vertraulich“, wird automatisiert ein entsprechendes Sensitivitätslabel auf Team und Site gesetzt. So wird unternehmensweit eine einheitliche Benennung und Klassifizierung sichergestellt.
– Genehmigungs-Workflows: CosyTrack.Provisioner lässt sich an mehrstufige Freigabeprozesse koppeln. Beispielsweise startet ein Antrag für ein neues Team automatisch einen Genehmigungsworkflow – etwa via Power Automate oder integrierte Approval-Funktion. Entscheidungen (Freigegeben/Abgelehnt) werden protokolliert und erst bei Freigabe geht es weiter. Damit wird Governance „by Design“ durchgesetzt: Kein Bereich entsteht ohne das OK der zuständigen Stellen.
– Automatische Inhaltserstellung & Pflicht-Metadaten: Das Tool kann neben der Site selbst auch Inhalte anlegen: z.B. eine vorgeschriebene Ordnerstruktur einfügen oder bestimmte Spalten (Metadaten) in Bibliotheken erzeugen. Falls Metadaten Pflichtfelder sein sollen, erzwingt der Provisioner bereits im Template, dass die Nutzer diese beim Hochladen angeben müssen. So wird sichergestellt, dass gleich zu Beginn alle erforderlichen Informationen erfasst werden.
– Lifecycle-Automatisierung: CosyTrack.Provisioner „vergisst“ die Arbeitsräume nach der Erstellung nicht. Er trackt das Erstellungsdatum und kann nach definierten Regeln Aktionen auslösen: z.B. wenn ein Projekt 180 Tage inaktiv war, markiert er es als „Archivierbar“ und informiert den Owner. Er kann den Bereich automatisiert schließen (auf Read-Only setzen) und später auch endgültig löschen oder zur Überprüfung dem Records Manager melden. Diese automatischen Lifecycle-Jobs halten die Umgebung sauber.
– Berechtigungs-Rezertifizierung: Das Tool unterstützt Erinnerungs-Workflows an Site-Eigentümer: In definierten Abständen sendet es E-Mails oder Tasks, die den Owner auffordern, die Mitglieder- und Gästeliste zu kontrollieren. Die Ergebnisse („Ok“ oder geändert) werden erfasst. Bei ausbleibender Reaktion kann CosyTrack nachfassen oder eskalieren. Dadurch wird die in Szenario 4 beschriebene Rezertifizierung effizient operationalisiert.
– Reporting & KPI-Dashboard: CosyTrack.Provisioner führt Buch über alle bereitgestellten Arbeitsräume (mit Attributen wie Owner, Erstelldatum, Vorlage, Klassifizierung). Daraus lassen sich Berichte generieren: z.B. wie viele Projekte wurden dieses Quartal angelegt, wie viele davon haben den Lifecycle eingehalten, welche noch nicht. KPIs wie „Durchschnittliche Bereitstellungsdauer“ oder „Anteil klassifizierter Sites“ kann das System auf Knopfdruck liefern. Diese Transparenz hilft dem Governance Board, Fortschritte zu messen.
– Integration & Schnittstellen: Das Tool nutzt die offiziellen APIs (Graph API, SharePoint API) und kann damit gut in bestehende Prozesse eingebunden werden. Beispiel: Ein vorhandenes IT-Service-Portal könnte einen Projektantrag entgegennehmen und über eine Schnittstelle den Provisioner ansteuern. Auch Power Automate Flows können angebunden werden, um z.B. bei Abschluss eines Provisionierungsvorgangs weitere Schritte zu starten (Benachrichtigung, Teams-Channel-Post, etc.).

Ein End-to-End-Beispiel für die Nutzung von CosyTrack.Provisioner ist der Workflow „Neue Projektakte“:
1. Antrag: Ein Mitarbeiter stellt über das Self-Service-Portal einen Antrag für einen neuen Projektraum (Angaben: Projektname, Sponsor, Team-Mitglieder, Vertraulichkeitsstufe).
2. Genehmigung: Der vordefinierte Genehmiger (Abteilungsleitung) erhält automatisch eine Anfrage und gibt diese mit einem Klick frei (oder lehnt ab, dann Ende).
3. Bereitstellung: Nach Freigabe erstellt CosyTrack.Provisioner im Hintergrund das neue Team samt SharePoint-Site entsprechend dem ausgewählten Blueprint.
4. Rollen & Labels: Das System trägt den Antragsteller als Owner ein, fügt die Team-Mitglieder hinzu und weist gemäß der gewählten Vertraulichkeitsstufe ein Sensitivitätslabel zu.
5. Kick-off: Bei Bereitstellung kann optional eine Kick-off-Checkliste oder Begrüßungsnachricht hinterlegt werden, die den Projektleiter an wichtige erste Schritte erinnert (z.B. „Füge eure Projektdaten in die Vorlagen-Dokumente ein“).
6. Rezertifizierung: Nach drei Monaten sendet das Tool automatisch eine Aufforderung an den Owner, die Mitglieder zu überprüfen. Er bestätigt im Provisioner-Cockpit, wer bleiben darf, und entfernt veraltete Zugriffe.
7. Abschluss & Archiv: Ist das Projekt beendet, markiert der Owner im System „Projekt abgeschlossen“. Daraufhin setzt der Provisioner das Team auf read-only (Archivmodus) und informiert den Records Manager.
8. Löschung: Nach Ablauf der Aufbewahrungsfrist (z.B. 3 Jahre nach Abschluss) wird das Team vom Provisioner automatisch endgültig gelöscht. Es entsteht ein Löschprotokoll für die Audit-Trail.

Trotz aller Automation gibt es auch Grenzen und Fallbacks: Nicht jeder Spezialfall lässt sich in Regeln gießen. Für Ausnahmen sollte der Provisioner – wie auch die Governance insgesamt – einen definierten Weg haben (z.B. „Manuelle Anlage durch IT mit Ausnahmegenehmigung, dokumentiert im Ticket-System“). Das Tool unterstützt in der Regel das Hinterlegen solcher manuellen Schritte und Ausnahmen (z.B. Kennzeichnung „ohne Vorlage“ für Sonderfälle). Wichtig ist, dass diese Ausnahmefälle später im Governance-Review betrachtet werden: Sind sie notwendig, können künftig Templates erweitert werden, oder muss die Regel angepasst werden? CosyTrack.Provisioner liefert hier zumindest Transparenz, wo es Abweichungen gab, und erleichtert so den kontinuierlichen Verbesserungsprozess.

9. Informationsarchitektur & Metadaten

Eine durchdachte Informationsarchitektur bildet das Fundament für erfolgreiche Governance. Dazu gehört die Definition verschiedener Site-Typen, ihrer Beziehungen (z.B. Hub-Struktur) und die Metadaten, die in diesen Bereichen gepflegt werden müssen. Ebenfalls wichtig: ein konsistentes Taxonomie-Design (kontrolliertes Vokabular für Schlagwörter) und ein Plan, wie Inhalte übergreifend gefunden werden.

• Site-Typen & Hubs: In Microsoft 365 empfiehlt sich ein „flaches“ Modell mit Hub Sites statt tief geschachtelter Unterseiten. Z.B. gibt es pro Abteilung eine Kommunikationssite, die als Hub fungiert, und darunter mehrere Team-Sites für Projekte oder Arbeitsgruppen. Weitere Hub-Kandidaten: ein Projekt-Hub (unter dem alle Projekträume hängen), ein Produkt-Hub (für alle produktbezogenen Sites) etc. Durch Hubs wird eine einheitliche Navigation ermöglicht (Hub-Menü mit bereichsübergreifenden Links) und es können übergreifende Features genutzt werden (z.B. Hub-weite Suche oder News-Rollups).
• Navigationsprinzipien: Nutzer sollten möglichst über 2-3 Klicks alle für sie relevanten Bereiche erreichen. Eine Global Navigation (z.B. via SharePoint-App-Bar) enthält die Haupt-Hubs. Innerhalb eines Hubs geben Standard-Menüs Orientierung (z.B. alle Projektseiten haben ähnliche Menüpunkte: Dokumente, Risiken, Teammitglieder). Wichtig ist Konsistenz: Wenn jede Abteilung eigene Navigationsbegriffe nutzt, wird es schwierig. Governance schreibt daher oft einheitliche Menüstrukturen für vergleichbare Sites vor.
• Vorlagen je Site-Typ: Wie schon beschrieben (siehe Szenarien), hat jeder Site-Typ im Idealfall ein Template. Ein Projektworkspace enthält eben andere Komponenten als ein Abteilungsteam. Durch Vorlagen wird die Architektur standardisiert: Alle Projektseiten schauen „gleich“ aus, was Schulung und Nutzbarkeit erhöht. Eine Muster-Vorlage für Abteilungen könnte z.B. neben einer Dokumentbibliothek auch ein Organigramm-Webpart und einen bereichsspezifischen Kalender enthalten.
• Kontrollierte Metadaten & Taxonomie: Anstatt beliebiger Tags setzen Unternehmen auf einen Managed Metadata Service: z.B. zentrale Begriffslisten für Standort, Produkt, Kunde, etc. So kann ein Benutzer beim Taggen eines Dokuments aus vordefinierten Werten auswählen. Das erhöht die Qualität der Daten erheblich. Über alle Sites hinweg sollten gewisse Pflichtmetadaten gelten (z.B. Dokumentenkategorie, Vertraulichkeitsstufe), die entweder automatisiert oder manuell gesetzt werden.
• Suchstrategie: Die Suchfunktion sollte – wie in Szenario 8 adressiert – aktiv gemanagt werden. Dazu gehören Synonyme (damit verschiedene Begriffe zum selben Resultat führen), promoted results (z.B. für wichtige Policies direkt einen Link ganz oben anzeigen) und Einstellungen, welche Inhalte bevorzugt durchsuchbar sind. Eine eigene Search Best Practices-Dokumentation hilft Nutzern, effektiv zu suchen (z.B. wie filtere ich nach Dateityp, nutze Phrasensuche etc.). Und das Governance-Team sollte die Such-Analytics im Auge behalten, um die Informationsarchitektur laufend zu verbessern (wenn Nutzer oft nach einem Begriff suchen, der keine Treffer liefert, fehlt vielleicht ein Content oder Tag).

Metadaten-Mindestanforderungen je Site-Typ:

Beispiele für Synonyme und Abkürzungen in der Suche:

Suchen-Best-Practices:

10. Sicherheit, Compliance & Recht

SharePoint Governance steht in engem Zusammenhang mit der IT-Sicherheit, Compliance (Regelkonformität) und rechtlichen Anforderungen. Einige Schwerpunkte:
– Zugriffsschutz & Externe: Sicherheitsrichtlinien legen fest, wer überhaupt auf die Plattform darf und unter welchen Bedingungen. Dazu gehören Authentifizierungsanforderungen (MFA-Pflicht, gerätebezogene Zugangskontrollen), Netzwerkbeschränkungen (z.B. bestimmte Inhalte nur aus dem Firmen-VPN erreichbar) und Richtlinien für Gäste (siehe Szenario 3: Jeder Gast braucht einen Sponsor, muss Sicherheitsregeln akzeptieren, etc.). SharePoint-spezifisch kann man z.B. steuern, dass externe Nutzer keine eigenen Links weiterfreigeben können oder nur in bestimmten Sites vorhanden sein dürfen. All dies fließt in Governance-Vorgaben ein, die wiederum technisch in Azure AD, SharePoint Admin Center und Compliance Policies umgesetzt werden.
– Protokollierung & Überwachung: Um Compliance nachweisen zu können, ist eine lückenlose Audit-Log-Funktionalität zentral. In M365 sollte daher das Unified Audit Log aktiviert und aufbewahrt werden (idealerweise länger als Standard 90 Tage, z.B. über eine erweiterte Lizenz oder Export). So kann man im Bedarfsfall rekonstruieren, wer auf welche Datei zugegriffen oder sie geteilt hat. Monitoring-Lösungen können verdächtige Aktivitäten melden (z.B. Massendownloads, siehe Szenario 9). Wichtig auch: eDiscovery-Fähigkeiten – Governance sorgt dafür, dass im Fall rechtlicher Verfahren relevante Informationen auffindbar sind, weil sie nicht wild verstreut oder privat gelagert werden. Man definiert, wer eDiscovery Cases anlegen darf (meist Rechtsabteilung/Compliance) und stellt sicher, dass die Inhalte entsprechend der Aufbewahrung noch vorhanden sind.
– Retention & Records Management: Ein großer Compliance-Aspekt ist die Aufbewahrungspflicht für bestimmte Dokumente (z.B. Rechnungen 10 Jahre, Vertragsunterlagen etc.) und die anschließende Löschung. In der Governance werden diese Fristen katalogisiert und mit technischen Mitteln hinterlegt (Retention Labels/Policies). Records Management bedeutet, dass wichtige Dokumente zu offiziellen „Geschäftsunterlagen“ erklärt werden können, die dann nicht mehr bearbeitet oder gelöscht werden dürfen (bis Fristende). SharePoint bietet hierfür Funktionen wie Deklaration als Datensatz oder die Nutzung spezieller Records Center Sites. Die Governance regelt, wer sowas tun darf (z.B. nur Records Manager dürfen Dateien als Record deklarieren) und wie Aufbewahrungs- und Löschkonzepte konkret umgesetzt werden (siehe Szenario 5). Dazu gehört auch ein Verfahren für Legal Hold: falls z.B. ein Gerichtsverfahren läuft, muss sichergestellt werden, dass relevante Inhalte nicht gelöscht werden – hier arbeiten Rechtsabteilung und IT zusammen.
– DSGVO-Aspekte: Die Datenschutz-Grundverordnung bringt weitere Anforderungen: Zweckbindung verlangt, dass personenbezogene Daten nur für den vorgesehenen Zweck genutzt werden – Governance sollte also vorgeben, wo solche Daten hingehören (z.B. Kundendaten nur in CRM-System oder speziellen SharePoint-Bereichen, nicht wild verteilt). Datenminimierung und Speicherbegrenzung decken sich mit Lifecycle-Regeln: Es sollen nicht unnötig Daten gesammelt und über Gebühr lange aufgehoben werden. Zudem muss es Prozesse für Betroffenenrechte geben: Kann eine Person Auskunft verlangen, muss man alle ihre Daten finden (hier hilft es, wenn über Metadaten klar ist, wo z.B. Kundendaten liegen). Und bei Löschersuchen müssen Verfahren bereitstehen, diese Daten aus SharePoint zu entfernen oder zu anonymisieren. Governance definiert hier, wer solche Requests bearbeitet (Datenschutzbeauftragter mit IT-Unterstützung) und wie sichergestellt wird, dass wirklich alle Kopien erwischt werden (z.B. durchsuchen von OneDrives, Teams-Chats via Content Search).

11. Betrieb & Service Management

Damit die Governance im Alltag wirkt, muss sie im Betrieb verankert sein. Das heißt, die IT-Organisation richtet Prozesse ein, um die Einhaltung der Regeln zu überwachen und einen reibungslosen Service zu gewährleisten:
– Runbooks & Betriebsprozesse: Für wiederkehrende Aktivitäten existieren Runbooks. Beispiele: „Wiederherstellung einer gelöschten Site“ (Schritte: Papierkorb oder Backup nutzen, Prüfliste abarbeiten wer informiert werden muss), oder „Onboarding neuer Mitarbeiter in Teams“ (Checkliste für Account, Gruppen, Schulung). Diese Dokumentation stellt sicher, dass im Tagesgeschäft nichts vergessen geht und neue Admins schnell handlungsfähig sind.
– Rollen im Betrieb: Klar definierte Verantwortlichkeiten analog zur Governance. Das Plattform-Team (IT-Betrieb) übernimmt 2nd/3rd-Level-Support, überwacht die Plattform (Monitoring, Health-Checks) und führt technische Changes durch. First-Level-Support/Helpdesk nimmt Benutzeranfragen entgegen (z.B. „Ich komme nicht auf Team X“) und löst einfache Fälle oder leitet weiter. Bei größeren Themen (Compliance-Fragen, neue Anforderungen) wird an das Governance Board oder die Experten (Security, Compliance Officer) eskaliert. Ein Service Manager könnte die Gesamtsicht haben und als Bindeglied zum Geschäft fungieren.
– Change Management: Auch wenn SharePoint Online kontinuierlich Updates erhält, muss intern entschieden werden, wie neue Features eingeführt werden (sofort nutzen, erst evaluieren?). Governance sieht vor, dass es ein Änderungsboard gibt, das größere Änderungen (z.B. neue Workflows, Hinzufügen eines Add-Ons) beurteilt. In On-Prem-Umgebungen gelten sowieso Wartungsfenster und Patch-Zyklen (z.B. Security-Updates monatlich installieren in definiertem Zeitfenster). Wichtig: Änderungen an Governance-Regeln selbst (Policies) sollten ebenso im Konsens entschieden und dokumentiert werden, idealerweise in einem Governance-Änderungsprotokoll.
– Backup & Restore: Für Notfälle braucht es Datensicherung. Bei SharePoint Online übernimmt Microsoft die Verfügbarkeit, aber ein Governance-Team kann entscheiden, ob ein zusätzliches Backup-Tool eingesetzt wird (manche Unternehmen sichern kritische Inhalte separat, um schneller granular wiederherstellen zu können). In jedem Fall muss der Restore-Prozess geübt werden: Wissen die Admins, wie man eine versehentlich gelöschte Site aus dem Second-Stage Papierkorb holt? Wie stellt man einzelne Dokumente aus Versionen wieder her? Zuständigkeiten: IT-Betrieb für technische Restore-Durchführung, Site-Eigentümer für Prüfung danach, ob alles korrekt ist.
– KPI, SLAs & Reporting: Im Betriebsmodell sind Service-Level-Agreements definiert: z.B. Verfügbarkeit 99,9% (bei Cloud durch Microsoft gewährleistet), Reaktionszeit auf ein „High Priority“ Ticket < 1 Stunde, Lösungszeit < 8 Stunden. Governance kann eigene KPIs integrieren (Anteil Compliance-Reviews on time etc.). Diese Kennzahlen werden in Monats- und Quartalsberichten aufbereitet. Ein typischer Monatsreport enthält z.B.: Anzahl neuer Sites, Anzahl gelöschter/archivierter Sites, offene Incidents, DLP-Vorfälle, Support-Volumen und evtl. Trainingsaktivitäten. Das schafft Transparenz und erlaubt es, Trends zu erkennen (steigende Nutzung? wiederkehrende Probleme?) und kontinuierlich nachzusteuern.

12. Einführung & Roadmap

Die Implementierung von SharePoint Governance erfolgt idealerweise schrittweise. Eine bewährte Roadmap umfasst mehrere Phasen:
1. Phase 0 – Assessment/Discovery: Zunächst steht eine Bestandsaufnahme. Wie wird SharePoint heute genutzt? Wo drücken die Schuhe (Sicherheitsvorfälle, Wildwuchs, Nutzerunzufriedenheit)? In Workshops mit IT, Fachbereichen und Compliance werden Anforderungen und Pain Points gesammelt. Ergebnis dieser Phase ist ein klares Bild des Ist-Zustands, ein erstes Risiko-Register der größten Lücken, und eine grobe Vision (Zielbild) der Governance. Ebenfalls definiert man die Projektorganisation für die nächsten Phasen (Wer sponsort, wer arbeitet mit?).
2. Phase 1 – Pilot & Blueprints: Nun wird im Kleinen gestartet. Man wählt einen oder wenige Bereiche für einen Pilot (z.B. die IT-Abteilung oder ein neues Großprojekt), um dort Governance-Maßnahmen prototypisch einzuführen. In dieser Phase entstehen die wichtigsten Artefakte: der Entwurf des Policy-Katalogs, erste Templates/Blueprints, ein RACI-Modell und evtl. schon Tools (z.B. Einrichtung eines Provisionierungstools in der Testumgebung). Der Pilot dient dazu, diese Konzepte auszuprobieren und Feedback einzuholen, bevor man unternehmensweit ausrollt. Am Ende der Phase 1 sollten Governance-Regeln und Prozesse so weit konkret sein, dass man sie dokumentieren und schulen kann.
3. Phase 2 – Rollout Welle 1-n: Hier wird die Governance stufenweise in die Breite gebracht. Statt Big Bang geht man oft bereichs- oder standortweise vor. Z.B. Rollout Welle 1: alle Abteilungen der Zentrale, Welle 2: alle Niederlassungen. In diesen Rollouts werden die in Phase 1 entwickelten Policies angewendet: Sites werden ggf. migriert oder neu angelegt nach den Standards, Benutzer werden geschult, alte Strukturen bereinigt. Ein Kommunikationsplan sorgt für Transparenz (z.B. ankündigen: „Ab nächstem Quartal nutzen wir das neue Teams-Request-Verfahren“). Auch werden in dieser Phase Metriken gesammelt, um Erfolg zu messen (wie viele Sites wurden schon auf Templates umgestellt etc.). Wichtig: aus den frühen Wellen lernen und ggf. Feinjustieren für spätere Wellen.
4. Phase 3 – Verstetigung & Optimierung: Nach dem Rollout geht Governance in den Regelbetrieb über. Es wird ein Regelprozess etabliert, um die Governance zu pflegen: z.B. jährliche Überprüfung der Policies, ein Governance Board, das quartalsweise tagt, um neue Anforderungen oder Änderungswünsche zu behandeln. KPIs werden kontinuierlich überwacht und berichtet (siehe Abschnitt 15). In dieser Phase schaut man auch auf Verbesserungspotenzial: Gibt es neue Tools, die wir einsetzen sollten (z.B. neue Features von Microsoft 365)? Haben sich Risiken verändert (z.B. neue Datenschutzgesetze)? Die Governance wird also lebendig gehalten.

Bei der Einführung steht oft die Entscheidung an: Starten wir mit einem Minimal Viable Governance (MVG), also einem Kernset an Regeln, oder bauen wir gleich ein umfassendes Enterprise-Programm auf? Folgende Matrix skizziert Unterschiede:

13. Risiken & Antipatterns

Trotz guter Planung gibt es typische Risiken und Fehlmuster (Antipatterns), die Governance-Vorhaben scheitern lassen können. Die folgende Tabelle zeigt einige davon mit Ursache, möglicher Auswirkung, Wahrscheinlichkeit und Gegenmaßnahmen:

14. Schulung & Change

Eine noch so gute Governance bleibt wirkungslos, wenn die Anwender nicht mitziehen. Deshalb sind Schulungen und Change Management zentrale Erfolgsfaktoren:
– Zielgruppengerechte Schulungen: Verschiedene Rollen brauchen unterschiedliches Wissen. IT-Administratoren müssen die neuen Prozesse/Tools im Detail beherrschen (z.B. wie funktioniert das Provisioning-Tool, was tun bei Policy-Verstoßen). Fachbereichs-User brauchen praxisnahe Anleitung, wie sie im neuen System arbeiten sollen (z.B. „Wie lege ich richtig Dokumente ab?“, „Was mache ich, wenn ich einen externen teilen will?“). Führungskräfte wiederum sollten die strategischen Vorteile verstehen (Warum Governance? Wie reduziert es Risiken? Ihre Vorbildrolle beim Einhalten der Regeln). Schulungen sollten kurzweilig, wiederholt und verankert im Onboarding neuer Mitarbeiter sein.
– Kommunikation & Adaption: Ein begleitender Kommunikationsplan verhindert Gerüchte und Widerstände. Early Adopter-Erfolge werden geteilt („Projekt XY konnte dank des neuen Templates 30% Zeit sparen“). Intranet-Artikel, Emails der IT-Leitung und FAQs klären auf. Wichtig: nicht nur einmalig ankündigen, sondern über die Rollout-Phasen hinweg immer wieder informieren, Erfolge feiern und Feedback einholen. Adoption bedeutet auch: hören, wo es klemmt, und nachbessern. Hier kommen Champions ins Spiel: Das sind Power User in den Bereichen, die die Neuerungen gut angenommen haben und Kollegen unterstützen. Ein Champions-Netzwerk kann z.B. monatlich mit dem Projektteam sprechen, um Stimmungen und Ideen aus den Fachbereichen aufzunehmen.
– Governance-Sprechstunde & Feedback: Es kann sinnvoll sein, offene Fragerunden anzubieten („Governance Clinic“), wo Nutzer ihre Sorgen oder Probleme mit den neuen Regeln loswerden können. Dieser direkte Draht hilft, Missverständnisse auszuräumen (z.B. „Warum dürfen wir keine Dropbox mehr nutzen?“) und steigert die Akzeptanz, weil die Leute merken, dass Governance-Team ist ansprechbar. Auch ein Feedback-Formular oder „Wünsche für Verbesserungen“ auf der Intranet-Seite der Governance kann eingebunden werden.
– Kontinuierliche Schulung: Nach dem initialen Rollout darf man nicht aufhören. Regelmäßige Refresh-Trainings, neue Mitarbeiter schulen, Updates bei Änderungen (z.B. wenn Microsoft neue Features einführt, die Policies tangieren) – das alles gehört zum Betrieb dazu.

Vor dem breiten Go-Live einer Governance-Initiative sollte eine Checkliste durchgegangen werden:

• Alle Policies sind final abgestimmt, dokumentiert und vom Management freigegeben.
• Governance-Rollen (Owner, Architekt, etc.) sind benannt und die Verantwortlichen kennen ihre Aufgaben.
• Technische Tools/Funktionen (Provisioning, Labels, DLP etc.) sind eingerichtet und getestet.
• Schulungsunterlagen für alle Zielgruppen stehen bereit; Pilotnutzer wurden bereits geschult und geben positives Feedback.
• Kommunikationsplan für den Launch ist umgesetzt (Ankündigungsmail, Intranet-News, Teams-Info-Session, etc.).
• Supportwege sind definiert: Helpdesk ist vorbereitet, FAQs sind verfügbar, Ansprechpartner (z.B. Champions) vor Ort benannt.
• Erfolgskriterien für die ersten Monate sind festgelegt (z.B. 80% der Teams nutzen neues Template) und ein Review-Termin nach z.B. 3 Monaten ist eingeplant.

15. Messbarkeit & kontinuierliche Verbesserung

Governance ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Daher muss der Erfolg messbar sein und es sollten Regelkreise für Verbesserungen etabliert werden.
– KPIs definieren: Zu Beginn werden Schlüssel-Kennzahlen festgelegt, um die Wirkung der Governance zu überwachen. Beispiele: Klassifizierungsquote (Anteil der Sites/Dokumente mit korrektem Sensitivitäts-Label), Rezertifizierungsrate (wie viel % der Zugriffsreviews wurden planmäßig durchgeführt), Durchschnittliche Provisionierungsdauer (Zeit von Antrag bis fertiger Workspace), Sucherfolgsquote (Anteil der Suchanfragen, die einen Klick auf Top-Ergebnis erzeugen – Indikator für Trefferqualität), Archivierungsquote (Verhältnis archivierter zu inaktiven Sites) und Lösch-Compliance (Anteil der Inhalte, die sofort nach Fristablauf gelöscht wurden). Diese KPIs sollten realistisch angesetzt werden (z.B. am Anfang 80% Klassifizierungsquote als Ziel, später steigernd zu 100%).
– Reporting & Review-Zyklen: Die KPIs werden in regelmäßigen Abständen erhoben und in Reports aufbereitet (siehe Abschnitt 11). Ein Governance-Review Meeting – etwa quartalsweise oder halbjährlich – analysiert diese Zahlen: Wo gibt es Probleme (z.B. manche Bereiche hinken bei Rezertifizierung hinterher)? Daraus werden Aktionspunkte abgeleitet (z.B. gezielte Schulung oder Eskalation in dem Bereich). Auch qualitative Feedbacks aus Schulungen oder der Governance-Sprechstunde fließen hier ein.
– PDCA-Zyklus: Wie in jedem Managementsystem gilt: Plan – Do – Check – Act. Die Governance-Policies werden geplant und umgesetzt (Plan/Do), dann über die KPIs und Audits geprüft (Check). Anschließend werden Verbesserungen abgeleitet (Act): Policies anpassen, Prozesse optimieren, neue Tools in Erwägung ziehen. Dieser Zyklus läuft kontinuierlich, typischerweise mit einem größeren Jahres-Review.
– Jährlicher Governance-Review: Mindestens einmal pro Jahr sollte das Governance-Board zusammenkommen, um grundsätzlich zu evaluieren: Erfüllen die Regeln noch ihren Zweck? Gibt es neue gesetzliche Anforderungen (z.B. Änderungen in Datenschutz) oder neue Microsoft-Features, die wir einbeziehen sollten (z.B. wenn MS ein neues Feature für Lifecycle herausbringt)? Auch Ergebnisse von Audits oder Incidents des Jahres fließen ein. Daraus entsteht ein Update-Plan: welche Policies werden geändert, welche Schulungen neu aufgelegt, wo investieren wir evt. in Tools.
– Kultur der Verbesserung: Über allem steht, dass Governance nicht als starres Regelwerk gesehen wird, sondern als lernendes System. Nutzerfeedback wird ernst genommen, gute Ideen aus den Fachbereichen für mehr Effizienz können in Standards übernommen werden. So bleibt die SharePoint Governance lebendig und trägt dauerhaft zum Unternehmenserfolg bei.

16. FAQ

1. Was ist der Unterschied zwischen einer Richtlinie und einem Standard?
   Antwort: Eine Richtlinie (Policy) ist eine grundsätzliche Vorgabe oder Regel (das „Was“ und „Warum“), während ein Standard das konkrete „Wie“ ausformuliert – also spezifische Vorgaben, um die Richtlinie umzusetzen. Beispiel: Eine Richtlinie könnte fordern, dass alle Teams klassifiziert werden müssen; der Standard definiert dann die konkreten Klassifizierungsstufen und Verfahren. Anders gesagt: Richtlinien setzen den Rahmen, Standards machen ihn messbar und umsetzbar (siehe Abschnitt 5 Policies & Standards).
2. Wie verhindere ich Berechtigungs-Wildwuchs?
   Antwort: Indem man von Anfang an ein striktes Berechtigungsmodell durchsetzt: Keine individuellen „Sonderrechte“, sondern Gruppen und Rollen verwenden (z.B. feste Owner-/Member-Gruppen pro Site). Außerdem durch regelmäßige Rezertifizierungen (Abschnitt 7, Szenario 4): Site-Eigentümer prüfen periodisch, wer noch Zugriff braucht, und entfernen Veraltetes. Technisch kann man z.B. Berichte nutzen, die alle Einzelberechtigungen aufspüren. Wichtig ist auch, dass neue Berechtigungen nur kontrolliert (z.B. über definierte Prozesse) vergeben werden (siehe Abschnitt 5, Least Privilege-Policy).
3. Wie gehe ich mit projektspezifischen Ausnahmen um?
   Antwort: Ausnahmen sollte es nur in klar begründeten Fällen geben – und dann über einen definierten Prozess. Typischerweise müssen Ausnahmen beantragt und genehmigt werden (z.B. durch das Governance Board oder Management) und zeitlich befristet sein. Alle Ausnahmen sollte man dokumentieren, damit man später evaluieren kann, ob die Regeln angepasst werden müssen. So bleibt die Governance konsistent. (Siehe Abschnitt 13, Risiko „Zu viele Ausnahmen“ – dort ist auch die Gegenmaßnahme eines strikten Ausnahmeprozesses beschrieben.)
4. Brauche ich für Microsoft Teams eine eigene Governance?
   Antwort: Teams ist eng mit SharePoint verzahnt, daher führt man keine völlig separate Governance ein, sondern erweitert die bestehende. Viele Regeln (Berechtigungen, Lifecycle, Klassifizierung) gelten für Teams genauso, da ja jedes Team eine SharePoint-Site im Hintergrund hat. Zusätzlich gibt es ein paar Teams-spezifische Punkte – z.B. Namenskonventionen für Teams-Namen oder Richtlinien für private Kanäle, Gast-Chat etc. Im Grunde ist es Teil der Gesamt-Governance (siehe Abschnitt 1 zur Beziehung Teams/SharePoint). Man erstellt also keinen separaten Governance-Silos, sondern integriert Teams-Aspekte in das bestehende Rahmenwerk.
5. Wie setze ich Aufbewahrung und Löschung gleichzeitig um?
   Antwort: Indem man Lifecycle-Regeln definiert, die beides abdecken: Zuerst eine definierte Aufbewahrungsdauer (während der die Inhalte schreibgeschützt archiviert sind) und danach die automatisierte Löschung. In Microsoft 365 kann man z.B. Retention Labels verwenden, die genau das tun: Dokumente können bis Datum X aufbewahrt und dann gelöscht werden. Wichtig ist, diese Regeln zentral festzulegen (z.B. „Projektdaten 3 Jahre aufbewahren, dann Löschung“) und technisch zu hinterlegen (siehe Abschnitt 5, Policy „Retention Policy“ und Szenario 5). So ist sichergestellt, dass nichts vorzeitig gelöscht wird, aber nach Fristablauf auch nichts liegen bleibt.
6. Welche Minimalanforderungen gelten für externe Gäste?
   Antwort: Grundsätzlich: Externe Gäste dürfen nur über namentliche Accounts mit definierten Rechten ins System (keine anonymen Links). Sie sollten immer einen internen Sponsor haben, der ihren Zugriff verantwortet. Security-Minimum: Gast muss MFA nutzen und sollte automatisch entfernt werden, wenn er X Tage nicht aktiv war. Außerdem dürfen Externe nur auf freigegebene Bereiche zugreifen (nicht global suchen etc.). Diese Anforderungen stehen meist in einer Externe-Policy (siehe Abschnitt 10 „Sicherheit, Compliance & Recht“ und Szenario 3 für konkrete Ausgestaltung).
7. Wie messe ich Governance-Reife?
   Antwort: Zum einen über Kennzahlen (KPIs), die zeigen, wie gut die Regeln umgesetzt werden – z.B. Prozentsatz klassifizierter Inhalte, Anteil Sites mit Owner-Zuordnung, Häufigkeit von Policy-Verstößen. Zum anderen über Audit-Ergebnisse: Wenn Audits kaum Findings haben und Nutzer die Prozesse befolgen, ist die Reife hoch. Man kann auch an ein Maturity Model denken (Stufe 1 = ad-hoc, Stufe 5 = optimiert), um qualitativ zu bewerten. Wichtig: Governance-Reife zeigt sich über kontinuierliche Verbesserung (siehe Abschnitt 15), d.h. ob man aus Messungen lernt und nachsteuert.
8. Was sind sinnvolle Namenskonventionen?
   Antwort: Namenskonventionen sollten einheitlich, kurz und aussagekräftig sein. Oft nutzt man Prefixe oder Suffixe: z.B. alle Projekte beginnen mit „PROJ-<Name>“, Abteilungs-Teams mit einem Kürzel der Abteilung. Sonderzeichen und sehr lange Namen vermeidet man (bessere Lesbarkeit und weniger technische Probleme). Wichtig ist auch Konsistenz zwischen Azure AD Gruppen, Teams und SharePoint-Sites (da diese verbunden sind). So erkennt jeder Benutzer schon am Namen, worum es sich handelt (siehe Abschnitt 3, Leitplanke Namenskonvention, und Szenario 1 als Beispiel, wo Projektnamen ein Präfix erhalten).
9. Wie baue ich einen Vorlagenkatalog auf?
   Antwort: Zuerst identifiziert man die wiederkehrenden Szenarien: z.B. Projektworkspace, Team für Abteilung, Externen-Team, Intranet-Seite etc. Dann definiert man für jeden ein Template: Welche Listen/Bibliotheken, welche Metadaten und Berechtigungsgruppen werden benötigt. Diese Vorlagen erstellt man idealerweise in einer Testumgebung und verfeinert sie mit Pilot-Nutzern. Anschließend stellt man sie zentral bereit – entweder über ein Provisioning-Tool (Abschnitt 8) oder über SharePoint Site Templates. Wichtig: den Vorlagenkatalog dokumentieren und bekannt machen (damit jeder weiß, es gibt eine Vorlage für xy, die er nutzen sollte). Abschnitt 7, Szenarien 1 und 2 geben Einblick, wie solche Templates aussehen können.
10. Wie verhindere ich Einzelrechte?
    Antwort: Durch klare Vorgaben und technische Unterstützung: Richtlinie, dass Berechtigungen grundsätzlich nur über Gruppen erfolgen (siehe Abschnitt 5 „Berechtigungsmodell“). In der Praxis bedeutet das, dass man Ownern schult, keine einzelnen User hinzuzufügen, sondern falls nötig eine neue Gruppe. Man kann mit Tools Einzelberechtigungen aufspüren und entfernen. Zudem sollten Standard-Teamsites schon mit passenden Gruppen kommen (Owners/Members/Visitors), sodass gar kein Bedarf entsteht, direkt auf Bibliotheksebene einzelne User reinzunehmen.
11. Welche Rolle spielt CosyTrack.Provisioner konkret?
    Antwort: CosyTrack.Provisioner automatisiert viele der oben beschriebenen Governance-Aufgaben. Er stellt sicher, dass neue Teams/Sites standardisiert angelegt werden (inkl. Name, Vorlage, Label – siehe Abschnitt 8). Er erzwingt Genehmigungen, trägt gleich die richtigen Berechtigungen ein, und kümmert sich auch später um Lifecycle (z.B. Archivierung nach Inaktivität). Kurz gesagt: Das Tool implementiert die Governance „in Software“, damit weniger manuelle Fehler passieren und die Richtlinien technisch eingehalten werden.
12. Wie automatisiere ich Rezertifizierungen?
    Antwort: Entweder mit Bordmitteln von Azure AD (Access Reviews in Entra ID Governance) oder mit einem speziellen Workflow/Tool. Bei Access Reviews kann man z.B. für jede Microsoft 365 Gruppe (bzw. Team) einen quartalsweisen Review ansetzen, bei dem der Owner im Portal die Mitgliederliste bestätigen oder bereinigen muss. Provisionierungs-Lösungen wie CosyTrack.Provisioner bieten ähnliches: Das Tool schickt Mails an Owner und sammelt deren Bestätigung (siehe Abschnitt 8, Berechtigungs-Rezertifizierung). Wichtig ist die Nachverfolgung: automatische Erinnerungen und Eskalation, damit niemand den Review „verschläft“ (Abschnitt 7, Szenario 4 beschreibt den Prozess im Detail).
13. Wie halte ich Metadatenpflichten durch?
    Antwort: Indem man die Notwendigkeit klar kommuniziert und es den Nutzern so leicht wie möglich macht. Konkret: In Bibliotheken von Anfang an Pflichtfelder einrichten (SharePoint zwingt dann zur Eingabe). Gute Templates enthalten bereits die richtigen Spalten, sodass jeder neue Workspace vorbereitet ist (Abschnitt 8). Zusätzlich kann man Mechanismen einführen wie „Upload Formulare“ die Metadaten abfragen, oder Workflows, die fehlende Angaben melden. Letztlich ist aber auch Schulung entscheidend: wenn Nutzer verstehen, dass sie dank Metadaten später schneller finden oder dass nur so Compliance geht, steigt die Bereitschaft (siehe auch Szenario 1 und 8, wo Metadaten von Day One forciert werden).
14. Wie gehe ich mit Altlasten/Legacy um?
    Antwort: Legacy-Inhalte (alte SharePoint-Seiten oder File Shares) sollte man vor der Einführung einmal sichten und kategorisieren. Sinnvolle Inhalte migriert man in die neue Struktur (idealerweise mit einem Migrationsplan und Tools, z.B. SPMT oder CosyTrack.Migrate). Dubletten und veraltete Dateien können archiviert oder entsorgt werden – hier lohnt es sich, einen Altdaten-Archivbereich zu haben, wo man zweifelhafte Altlasten für den Notfall ablegt. Governance sollte regeln, dass nach dem Stichtag keine alten Pfade mehr benutzt werden dürfen. Wichtig ist, Stakeholder einzubinden: Die Fachbereiche müssen mithelfen zu entscheiden, was von früher noch gebraucht wird. (Abschnitt 12, Phase 0 und 2 sprechen die Behandlung von Altbeständen an, auch Szenario 7 indirekt.)
15. Was ist bei sensiblen Daten zu beachten?
    Antwort: Solche Daten (etwa personenbezogene oder geheime Infos) müssen besonders geschützt werden: Immer korrekt klassifizieren/labeln, Zugriffe stark beschränken (nur notwendige Personen), idealerweise mit Verschlüsselung (Sensitivity Label) arbeiten, so dass auch ein Download nicht ungeschützt ist. Weiterhin sollten DLP-Regeln aktiv sein, um versehentliche Weitergaben zu verhindern (Abschnitt 10 und Szenario 6 geben dazu Details). Man braucht außerdem klar definierte Speicherorte – z.B. „streng vertrauliche“ Daten gehören nur in spezielle Sites mit zusätzlichen Schutzmaßnahmen. Und natürlich: alles protokollieren für den Fall der Fälle.
16. Wie organisiere ich Governance in internationalen Teams?
    Antwort: Hier gilt es, ein zentrales Rahmenwerk zu haben, das lokale Unterschiede berücksichtigt. Die Kern-Policies (Sicherheit, Lifecycles etc.) sollten weltweit gleich sein, aber für bestimmte Länder muss man landesspezifische Regeln einbauen können (z.B. längere Aufbewahrung wegen lokaler Gesetze). Wichtig ist, Unterstützung in der jeweiligen Sprache zu bieten (Schulungsunterlagen, Ansprechpersonen). Ein globales Governance-Board kann Vertreter aus verschiedenen Regionen haben, um Input zu bekommen. Champions-Netzwerke in jedem Land helfen bei der Umsetzung (Abschnitt 14). Insgesamt muss Governance flexibel genug sein, internationale Zusammenarbeit nicht zu behindern, aber lokal relevante Vorschriften einzuhalten (siehe DSGVO-Aspekte in Abschnitt 10 als Beispiel für regionale Compliance).
17. Wie reduziere ich Kosten durch Governance?
    Antwort: Governance spart Kosten, indem sie Effizienz schafft: Z.B. werden redundante Inhalte vermieden (weniger Speicherplatz und Backupkosten), und Mitarbeiter verschwenden weniger Zeit mit Suchen oder Eigenbasteleien. Standardisierung senkt den Betriebsaufwand – die IT muss nicht jedes Team manuell einrichten, Automatisierung übernimmt Routinearbeiten (Abschnitt 2 und Abschnitt 8 verdeutlichen das Einsparpotenzial). Auch Shadow-IT wird reduziert, was Lizenzkosten spart (anstatt zig separate Tools zu bezahlen, nutzt man vorhandene Funktionen von Microsoft 365). Kurz: Anfangs investiert man etwas in Governance, aber mittelfristig holt man das durch effizientere Nutzung und weniger Fehlerkosten (Datenpannen, Nacharbeiten) wieder rein.
18. Welche KPIs sind zu Beginn realistischerweise erreichbar?
    Antwort: Am Anfang sollte man mit Basis-KPIs starten und keine 100%-Idealwerte erwarten. Realistisch wäre z.B. innerhalb des ersten halben Jahres: >80% aller neuen Teams folgen dem Template-Prozess, >70% der bestehenden Sites haben einen Owner eingetragen, Klassifizierungsquote steigt von 0 auf 60%. Wichtig ist der Trend: Die Kennzahlen sollen in die richtige Richtung gehen. Anfangs mögen manche Werte niedrig sein (viele Alt-Daten unklassifiziert), aber man setzt sich Zwischenziele. Abschnitt 15 schlägt vor, KPIs zu definieren und nachzuverfolgen – wichtig ist eher die Verbesserung über Zeit als ein absoluter Wert nach wenigen Wochen.
19. Wie bringe ich Fachbereiche ins Boot?
    Antwort: Indem man Governance nicht als reines IT-Projekt verkauft, sondern den Nutzen für die Fachbereiche betont. Zum Beispiel: schnellere Projektstarts, weniger Aufwand bei Audits, bessere Auffindbarkeit kommen ihnen zugute. Es hilft, Key User früh einzubinden – etwa in Piloten – sodass sie sich gehört fühlen und später als Multiplikatoren auftreten (siehe Abschnitt 14, Champions-Konzept). Auch Erfolgsgeschichten aus den Fachbereichen kommunizieren („Sales hat dank Governance endlich Ordnung in Angeboten und spart pro Woche 2h Suche“). Und last but not least: Rückenwind vom Management der Fachbereiche holen, damit klar ist, dass dies vom ganzen Unternehmen gewollt ist, nicht nur von der IT.
20. Wie plane ich den Übergang vom Pilot zum breiten Rollout?
    Antwort: Der Übergang gelingt, wenn man aus dem Pilot die richtigen Lehren zieht. Nach dem Pilotprojekt sollte man die Policies und Templates feinjustieren (Pilot-Feedback umsetzen). Dann erstellt man einen Rollout-Plan (Abschnitt 12) – z.B. phasenweise pro Abteilung oder Standort. Wichtig ist, die notwendige Infrastruktur zu skalieren (falls Tools eingesetzt werden, sicherstellen, dass sie produktionsreif und für mehr Nutzer dimensioniert sind). Zudem müssen Schulungsmaterialien bereitstehen, und das Kommunikationsteam sollte vor dem breiten Rollout eine Info-Offensive starten. Praktisch empfiehlt es sich, zuerst „Early Adopter“ Bereiche auszurollen, die positiv eingestellt sind, um weitere Erfolgsstories für skeptischere Bereiche zu haben. Sobald der Übergang gestartet ist, heißt es: eng begleiten, mögliche Probleme schnell lösen und flexibel bleiben, falls der Plan angepasst werden muss.

Weitere Beiträge zum Thema SharePoint und Teams