Wann gehören Dateien in OneDrive, SharePoint oder Teams – und wie verhindere ich Wildwuchs in Microsoft 365?

OneDrive, SharePoint und Teams technisch sauber abgrenzen: Datenhaltung, Berechtigungen und Abhängigkeiten

Eine tragfähige Datenarchitektur in Microsoft 365 beginnt mit der technischen Trennung der Rollen von OneDrive, SharePoint und Teams. Die drei Namen werden im Alltag oft als austauschbare „Orte für Dateien“ behandelt, tatsächlich unterscheiden sie sich jedoch in Datenhaltung, Sicherheitsmodell, Lifecycle und den dahinterliegenden Abhängigkeiten. Wer diese Unterschiede ignoriert, erzeugt Strukturen, die später nur mit hohem Aufwand bereinigt werden können, etwa weil Berechtigungen, Freigaben und Verknüpfungen über mehrere Dienste hinweg ineinandergreifen.

OneDrive for Business: persönlicher Arbeitsbereich mit nutzerzentriertem Sicherheitsmodell

OneDrive for Business ist technisch die persönliche SharePoint-Site eines Benutzers (OneDrive-Site) mit einer Dokumentbibliothek als primärem Ablageort. Der entscheidende Unterschied liegt nicht in der Dateitechnik, sondern im Eigentümer- und Berechtigungsmodell: Standardmäßig ist der Benutzer Owner und primärer Administrator der Inhalte. Freigaben entstehen ad hoc (Einzelpersonen, Links, ggf. externe Gäste) und folgen typischerweise kurzfristigen Arbeitsprozessen. Genau diese Freiheit macht OneDrive geeignet für persönliche Arbeitsstände, Entwürfe, Notizen, temporäre Exporte oder Dateien, die noch nicht in eine organisatorische Struktur gehören.

Für Governance ist relevant, dass OneDrive stark an die Identität und den Lifecycle des Kontos gekoppelt ist. Beim Austritt eines Mitarbeiters müssen Inhalte über definierte Prozesse gesichert oder übergeben werden; je nach Tenant-Konfiguration greifen Aufbewahrungsrichtlinien und der Zugriff für Manager oder Administratoren zeitlich begrenzt. OneDrive ist damit kein neutraler, teambezogener Datenraum, sondern ein persönlicher Arbeitskontext, der Freigaben zwar ermöglicht, aber strukturell nicht dafür ausgelegt ist, dauerhaft als „Teamlaufwerk“ zu fungieren.

SharePoint Online: strukturierte Dokumentenplattform mit Metadaten, Versionierung und Governance

SharePoint Online ist die Plattform für gemeinsam verantwortete Inhalte: Abteilungswissen, Projektdokumentation, Vorlagen, Prozessunterlagen oder Produktdokumente. Technisch sind Dokumentbibliotheken mehr als Ordnercontainer; sie unterstützen Versionierung, Content Types, Metadaten, Ansichten, Genehmigungsprozesse sowie Compliance- und Aufbewahrungsfunktionen. Governance wird in SharePoint nicht nur über Berechtigungen, sondern auch über Informationsarchitektur (Sites, Hub-Sites, Bibliotheken, Spalten, Sensitivity Labels) umgesetzt.

Das Berechtigungsmodell ist gruppenorientiert: Ideal ist die Arbeit mit Microsoft 365-Gruppen und SharePoint-Gruppen (Owners, Members, Visitors) statt Einzelberechtigungen auf Dateiebene. SharePoint toleriert zwar tiefere Vererbung und Breaks, der Betrieb wird dadurch aber schnell unübersichtlich. Je stärker Inhalte als „organisatorisches Gedächtnis“ dienen, desto wichtiger werden konsistente Strukturen, nachvollziehbare Verantwortlichkeiten und eine saubere Trennung zwischen Lese- und Änderungsrechten.

Microsoft Teams: Kollaborationsoberfläche mit Abhängigkeiten zu SharePoint und Exchange

Teams ist keine eigenständige Dateiablage, sondern eine Kollaborationsoberfläche. Bei der Erstellung eines Teams wird in der Regel eine Microsoft 365-Gruppe angelegt, die mehrere Workloads bündelt: eine SharePoint-Teamwebsite (für Dateien), ein Exchange-Postfach und Kalender (für Gruppenfunktionen), dazu Planner/To Do-Integrationen sowie je nach Nutzung weitere verbundene Dienste. Der „Dateien“-Tab in einem Standardkanal zeigt technisch eine Dokumentbibliothek auf der zugehörigen SharePoint-Site an; pro Standardkanal entsteht dort typischerweise ein Ordner. Private Kanäle und Shared Channels weichen hiervon ab und nutzen jeweils eigene SharePoint-Sites, was die Berechtigungs- und Lifecycle-Planung zusätzlich beeinflusst.

Die praktische Konsequenz: Wer Teams als primäre Strukturierungslogik für Ablage betrachtet, modelliert Informationen entlang von Chat-/Meeting-Strukturen statt entlang von Prozessen, Verantwortlichkeiten und Wiederverwendbarkeit. Dateien „in Teams“ sind fast immer Dateien „in SharePoint“, nur in einer anderen Oberfläche dargestellt. Governance muss deshalb die SharePoint-Ebene als führend betrachten, andernfalls entstehen Inkonsistenzen zwischen Kanalstruktur, Bibliotheksstruktur, Freigaben und externem Zugriff.

Typische Abgrenzung anhand technischer Merkmale

Eine belastbare Trennung lässt sich über wenige technische Leitplanken formulieren: Eigentümerprinzip, Stabilität des Datenkontexts, gewünschte Nachvollziehbarkeit von Berechtigungen sowie die Frage, ob Inhalte künftig als Referenz (Wissensbasis) oder nur als Arbeitsstand dienen. Besonders kritisch sind hybride Konstrukte, bei denen persönliche OneDrive-Dateien als „Teamablage“ verlinkt werden oder Teams-Kanäle als alleinige Navigationslogik für Dokumente dienen, während Berechtigungen auf SharePoint-Ebene davon abweichen.

• OneDrive ist technisch passend, wenn: Inhalte an eine Person gebunden bleiben (Entwürfe, Arbeitskopien, persönliche Analysen) und Freigaben bewusst punktuell erfolgen, z. B. über https://<tenant>-my.sharepoint.com/personal/....
• SharePoint ist technisch passend, wenn: Inhalte langfristig teambezogen sind, nachvollziehbare Gruppenrechte benötigen und von Metadaten/Ansichten profitieren; der führende Ablageort ist eine Site wie https://<tenant>.sharepoint.com/sites/<site> mit klaren Bibliotheken.
• Teams ist technisch passend, wenn: Kommunikation, Meetings und Aufgaben die Arbeit treiben und Dokumente nur kontextuell eingeblendet werden; der Dateienbereich ist dabei eine Projektion auf SharePoint, nicht ein separates Repository.
• Warnsignal „Teams = Dateiablage“: Kanalstruktur ersetzt Informationsarchitektur, Dateien werden in Ordnern „pro Kanal“ abgelegt, während Berechtigungen für private Kanäle oder externe Gäste zu Schattenstrukturen führen.

Abhängigkeiten, die in der Architekturentscheidung sichtbar sein müssen

Die Abgrenzung gelingt nur, wenn Abhängigkeiten explizit berücksichtigt werden. Teams „erbt“ die Dateispeicherung aus SharePoint; damit gelten auch SharePoint-Grenzen, etwa für Bibliotheksfunktionen, Aufbewahrung, Sensitivity Labels und externe Freigaben. Gleichzeitig führt die Teams-Konstruktion (Standardkanäle, private Kanäle, Shared Channels) zu mehreren SharePoint-Sites mit eigenem Berechtigungsmodell. Was in Teams wie eine einfache Kanalentscheidung wirkt, erzeugt in SharePoint faktisch zusätzliche Security Boundaries.

OneDrive wiederum bleibt ein Sonderfall: Es nutzt SharePoint-Technologie, ist aber im Besitz des Benutzers und damit in der Administration anders zu behandeln (Offboarding, Zugriffskontrollen, Delegation, Wiederherstellung). Eine saubere Datenarchitektur trennt deshalb „persönliche Verantwortung“ (OneDrive) konsequent von „geteilter Verantwortung“ (SharePoint) und nutzt Teams als Arbeitsoberfläche, nicht als strukturelles Rückgrat der Ablage.

Entscheidungslogik für die Dateiablage: persönliche Arbeitsstände, Teamdokumente und Teams als Kontext statt Speicherort

Eine stabile Informationsarchitektur in Microsoft 365 entsteht nicht durch das Tool, das Dateien „sichtbar macht“, sondern durch die Entscheidung, welchem Lebenszyklus und welcher Berechtigungslogik Inhalte folgen sollen. Für die Dateiablage ist deshalb weniger die Benutzeroberfläche entscheidend als die Frage, ob es sich um persönliche Arbeitsstände, um gemeinschaftlich verantwortete Teamdokumente oder um Inhalte handelt, die nur vorübergehend im Umlauf sind. Teams spielt dabei in der Regel die Rolle des Kontextes: Dateien werden dort verlinkt, diskutiert, gemeinsam bearbeitet und findenbar gemacht, technisch liegen sie jedoch in SharePoint (Teamkanäle) oder im OneDrive einer Person (private Chats, persönlicher Arbeitsbereich).

Grundregel: Besitzer, Lebenszyklus und Berechtigungen entscheiden

Die schnellste Fehleinschätzung lautet „Teams ist der Speicherort“. Diese Sicht verschiebt die Aufmerksamkeit auf Kanäle und Chatverläufe, während Eigentümerschaft, Aufbewahrung und Zugriffskontrolle unklar bleiben. Für eine belastbare Entscheidung muss pro Inhaltstyp geklärt sein, wer fachlich verantwortlich ist (Person oder Einheit), wie lange der Inhalt relevant bleibt (temporär, projektbezogen, dauerhaft) und ob Zugriffe individuell oder gruppenbasiert gesteuert werden sollen. Daraus ergeben sich klare Zielsysteme: OneDrive für persönliche, nicht kuratierte Arbeitsstände; SharePoint-Dokumentbibliotheken für gemeinsam verantwortete, strukturierte und governancefähige Inhalte; Teams für die Zusammenarbeitsschicht, die auf diese Inhalte verweist.

Eine zusätzliche Trennlinie verläuft entlang der Nachvollziehbarkeit: Teamdokumente benötigen häufig Versionierung, Metadaten, definierte Bibliotheksstrukturen und nachvollziehbare Berechtigungsgruppen. Persönliche Arbeitsstände benötigen das meist nicht, dafür aber schnelle Ablage, individuelle Freigaben und die Möglichkeit, Entwürfe ohne strukturelle Verpflichtung zu entwickeln.

Konkrete Ablageentscheidung: OneDrive vs. SharePoint

OneDrive ist der richtige Ort, solange ein Inhalt eine persönliche Arbeitskopie darstellt oder die Verantwortung bei einer einzelnen Person liegt. Dazu zählen Entwürfe, Zwischenstände, Recherchematerial, Notizen oder Dateien, die nur mit wenigen Personen kurzfristig geteilt werden. Kritisch wird OneDrive, sobald Inhalte faktisch Teamwissen werden: Wenn mehrere Personen dauerhaft darauf angewiesen sind, entsteht bei reinem Teilen aus OneDrive ein fragiles Konstrukt aus Einzelberechtigungen, das bei Rollenwechseln oder Kontoänderungen zu Zugriffsabbrüchen führt.

SharePoint ist für Inhalte vorgesehen, die organisatorisch „über“ einzelnen Personen stehen: Projektdokumentation, Prozess- und Qualitätsunterlagen, Vorlagen, Abteilungsakten oder Produktdokumente. Dort lassen sich Bibliotheken nach Zweck trennen, Metadaten für Auffindbarkeit etablieren und Berechtigungen gruppenbasiert abbilden. Entscheidend ist, dass SharePoint nicht als weiterer Dateiordner verstanden wird, sondern als Dokumentenplattform mit bewusstem Struktur- und Governanceanspruch.

• OneDrive (persönlich): Arbeitsstände, die noch nicht veröffentlicht sind, individuelle Verantwortung, spontane Freigaben, temporäre Inhalte; Freigabe-URLs sind häufig personengebunden und sollten nicht als „offizielle“ Verteilung genutzt werden.
• SharePoint (Team/Organisation): Inhalte mit gemeinsamem Eigentümer, längerem Lebenszyklus, Anforderungen an Struktur (Bibliotheken/Metadaten), konsistente Versionierung und revisionsfähige Nachvollziehbarkeit; Berechtigungen werden primär über Gruppen statt Einzelpersonen gesteuert.
• Teams (Kontext): Zugriff und Zusammenarbeit im Kanal; Dateioperationen wirken auf die zugrunde liegende SharePoint-Bibliothek des Teams (Standardkanal) oder auf separate Sites (Private/Shared Channels) und sollten als Oberfläche, nicht als Ablageentscheidung verstanden werden.

Entscheidungsmatrix für typische Inhalte

Für die Praxis hilft eine Matrix, die wiederkehrende Dateitypen nicht nach „wo wurde daran gearbeitet“, sondern nach Verantwortlichkeit und Stabilitätsbedarf einordnet. Damit sinkt die Wahrscheinlichkeit, dass Projektakten in privaten Chat-Dateiablagen verschwinden oder dass OneDrive-Freigaben zum impliziten Teamlaufwerk werden.

Teams richtig einordnen: Kanalstruktur ist keine Informationsarchitektur

Standardkanäle eines Teams schreiben Dateien in die Standarddokumentbibliothek der zugehörigen SharePoint-Teamwebsite, typischerweise in Ordnern je Kanal. Das verführt dazu, die Kanalstruktur als „Ablagelogik“ zu missbrauchen. Kanäle bilden jedoch Kommunikations- und Arbeitszuschnitte ab, die sich häufig ändern (z. B. nach Projektphase, Verantwortungswechsel, parallele Initiativen). Wird die Dateiablage daran festgekoppelt, entsteht eine Ordnerlandschaft, die weder Metadaten noch langfristige Verantwortlichkeiten sauber abbildet.

Private und Shared Channels verschärfen das Thema: Sie erzeugen eigene SharePoint-Sites mit separaten Berechtigungsgrenzen. Das kann fachlich korrekt sein, wenn wirklich eine eigenständige Zugriffssphäre gebraucht wird. Wird diese Funktion jedoch als Ersatz für Bibliotheks- oder Ordnerkonzepte genutzt, verteilt sich eine einzelne fachliche Ablage auf mehrere Sites, mit inkonsistenter Navigation, unterschiedlichen Berechtigungsgruppen und schwierigem Lebenszyklusmanagement.

• Teamdateien im Kanal: Dateien im Reiter „Dateien“ eines Standardkanals landen in SharePoint unter Dokumente/<Kanalname>; die Governance muss sich daher an SharePoint orientieren, nicht an der Kanaloberfläche.
• Chat-Dateien: Dateien aus Chats werden im OneDrive des Uploaders gespeichert und typischerweise unter Microsoft Teams Chat Files organisiert; sie sind kein geeigneter Ort für Teamakten und sollten bei Relevanz in SharePoint überführt werden.
• Private/Shared Channels: Für restriktive Arbeitsbereiche entstehen getrennte SharePoint-Sites; der Einsatz sollte an ein klares Zugriffskonzept gebunden werden, sonst fragmentiert die Ablage.

Pragmatische Regelstrecken für den Alltag: von „Entwurf“ zu „Teamstandard“

In der täglichen Arbeit wechseln Dokumente ihren Status: vom persönlichen Entwurf zur gemeinsam bearbeiteten Arbeitsversion und schließlich zur referenzierbaren, „gültigen“ Fassung. Eine saubere Entscheidungslogik bildet diesen Übergang explizit ab. Solange ein Dokument noch nicht als Teamartefakt gilt, bleibt es in OneDrive. Sobald es als Arbeitsgrundlage für eine Gruppe dient, wird es in die zuständige SharePoint-Bibliothek verschoben oder dort neu erstellt. Teams stellt diese Bibliothek im passenden Kontext bereit, ohne dass sich daraus eine eigene Ablagekategorie ergeben muss.

Damit die Logik im Betrieb tragfähig bleibt, braucht sie klare Trigger statt Ermessensentscheidungen im Einzelfall: beispielsweise „sobald ein Dokument in einem Meeting als verbindliche Referenz zitiert wird“, „sobald eine Datei Teil eines Projektreportings ist“ oder „sobald externe Zugriffe geplant sind“. Solche Trigger lassen sich organisatorisch definieren und technisch unterstützen, etwa durch getrennte Bibliotheken für Arbeitsdokumente und veröffentlichte Inhalte sowie durch eindeutige Verantwortlichkeiten für die Pflege.

Umsetzung in der Organisation: SharePoint-Struktur, Namenskonventionen, Berechtigungsmodell, kontrollierte Team-Erstellung und Governance gegen Fehlkonfigurationen

Eine stabile Datenarchitektur in Microsoft 365 entsteht nicht durch „Aufräumen im Nachhinein“, sondern durch konsequente Standards für Sites, Bibliotheken, Berechtigungen und die kontrollierte Anlage von Teams. Technisch wird damit vor allem verhindert, dass sich Teams-Workspaces als vermeintliche Dateiablage verselbstständigen, Inhalte ohne Metadatenlogik entstehen oder Rechte „ad hoc“ über Freigaben verstreut werden. Organisatorisch braucht es klare Zuständigkeiten: Wer darf neue Arbeitsbereiche anlegen, wer verantwortet deren Lifecycle, und welche Mindestanforderungen gelten für Struktur, Benennung und Compliance.

SharePoint-Struktur: Site-Typen, Bibliotheken, Metadaten und Grenzen

Für die Strukturierung hat sich eine klare Trennung zwischen dauerhaften Arbeitskontexten (Abteilungen, Linienfunktionen) und temporären Kontexten (Projekte, Initiativen) bewährt. Beide sollten in eigenen SharePoint-Sites abgebildet werden, nicht als Ordnerwelten in einer „Sammel-Site“. Je Site bleiben Eigentümerschaft, Berechtigungen, Aufbewahrung und Navigation konsistent steuerbar. Innerhalb der Site werden Dokumentbibliotheken als fachliche Container definiert (z. B. „Verträge“, „Spezifikationen“, „Vorlagen“), nicht als Ablage nach Personen oder E-Mail-Verläufen.

Ordner sind in SharePoint möglich, sollten aber sparsam eingesetzt werden. Tiefe Ordnerbäume erschweren Suche, Berechtigungsprüfung und langfristige Konsistenz; zudem werden Metadaten dann häufig gar nicht genutzt. Stabiler sind wenige, flache Bibliotheken mit verpflichtenden Metadaten für Klassifikation (z. B. Dokumenttyp, Vorgang, Kunde, Vertraulichkeit) und klaren Content Types, wenn mehrere Dokumentarten unterschiedliche Pflichtfelder oder Vorlagen benötigen. Versionierung und ggf. Haupt-/Nebenversionen werden pro Bibliothek so konfiguriert, dass fachliche Review-Prozesse unterstützt werden, ohne dass der Versionsspeicher unkontrolliert wächst.

Namenskonventionen: Eindeutigkeit über alle Workloads hinweg

Benennungen wirken zuerst kosmetisch, sind aber ein technischer Steuerungshebel: Sie beeinflussen URL-Pfade, Suchtreffer, Adressbücher, Gruppenlisten, Compliance-Auswertungen und die spätere Migration. Namenskonventionen müssen daher Teams, M365-Gruppen, SharePoint-Sites und (wo relevant) Sensitivitätsbezeichnungen zusammen denken. Entscheidend ist ein konsistenter Präfix/Suffix-Mechanismus, der Zweck, Organisationseinheit und Vertraulichkeitsniveau transportiert, ohne dass Namen unnötig lang werden.

Parallel zur Anzeige-Bezeichnung sollten auch Alias/URL-Teil (Mail-Nickname) und optionale Kurzkennungen (z. B. Projektcode) geregelt werden. Sonderzeichen, zu generische Namen und häufige Umbenennungen erzeugen Folgekosten: Links können brechen, Bookmarks altern, und es entsteht Schatten-Content in Chats oder OneNote/Planner-Kontexten. In der Praxis braucht es deshalb definierte „zulässige Muster“ und klare Regeln, wann Umbenennungen überhaupt erlaubt sind.

• Einheitlicher Präfix: Abteilungs-Teams/Sites beginnen z. B. mit ORG-DEP-, Projekte mit ORG-PRJ-, Communities mit ORG-COM-; das erleichtert Filtering, Ownership und Lifecycle-Regeln.
• Projektkennzeichen: Kurzcode als Pflichtbestandteil, z. B. PRJ-0421, um Dubletten zu verhindern und Vorhaben über Systeme hinweg zu korrelieren.
• Vertraulichkeit sichtbar machen: Ergänzung über Sensitivitätslabel (bevorzugt) oder als Suffix, z. B. -CONF; Anzeige und technische Policy sollten zusammenpassen.
• Alias-Regeln: Mail-Alias nur aus Kleinbuchstaben/Ziffern/Bindestrich, z. B. org-prj-0421-steuerung; keine nachträgliche „Kreativkorrektur“ ohne Change-Prozess.

Berechtigungsmodell: Gruppen statt Einzelrechte, wenige Brüche, klare Rollen

Ein belastbares Berechtigungsmodell minimiert Sonderfälle. Für Team- und Projektdaten gilt als Standard: Zugriff über Gruppenmitgliedschaften, nicht über Datei-für-Datei-Freigaben. SharePoint-Gruppen (Besitzer, Mitglieder, Besucher) oder Microsoft-365-Gruppen liefern dafür die Basisschicht. Abweichungen werden bewusst selten gehalten und fachlich begründet, etwa für externe Zusammenarbeit oder für Bibliotheken mit besonderen Schutzanforderungen.

„Permission Sprawl“ entsteht typischerweise durch das Brechen der Vererbung auf Ordner- oder Dokumentebene. Kurzfristig löst das Einzelfälle, langfristig verliert die Organisation die Erklärbarkeit: Niemand kann zuverlässig sagen, wer warum Zugriff hat, Audits werden aufwendig, und bei Rollenwechseln bleiben Altberechtigungen bestehen. Deshalb sollten Ausnahmen in separate Bibliotheken oder – bei stark abweichenden Personenkreisen – in eigene Sites ausgelagert werden. Externe Zugriffe werden über definierte Prozesse und die vorgesehenen Gastmechanismen gesteuert; anonyme Links sind in vielen Umgebungen bewusst zu unterbinden oder strikt zu begrenzen.

• Rollenmodell: Klare Definition für „Owner“, „Member“, „Visitor“ sowie optionale Sonderrollen; Zuweisung primär über Gruppen, nicht über individuelle ACLs.
• Berechtigungsbrüche minimieren: Vererbung nur auf Bibliotheksebene brechen; keine dauerhaften Einzelrechte auf Dokumenten, außer für klar abgegrenzte, kurzlebige Ausnahmen.
• Externe Zusammenarbeit: Zugriff über Gastkonten und definierte Freigaberichtlinien; wenn Links genutzt werden, dann bevorzugt „bestimmte Personen“ statt „jeder mit dem Link“.
• Technische Prüfpunkte: Regelmäßige Kontrolle auf Site-Ebene über https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/user.aspx und Berechtigungen über https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/permsetup.aspx.

Kontrollierte Team-Erstellung: Template-Logik, Provisioning und Lifecycle

Teams sollte nicht als „schneller Container“ für Dateien missverstanden werden, sondern als Oberfläche für einen definierten Arbeitsraum, der technisch eine Microsoft-365-Gruppe, eine SharePoint-Teamwebsite und Exchange-Komponenten provisioniert. Unkontrollierte Team-Erstellung führt deshalb nicht nur zu Chat-Wildwuchs, sondern zu einer unübersichtlichen Site-Landschaft inklusive redundanter Bibliotheken („General“), inkonsistenter Berechtigungen und nicht gepflegter Gastzugriffe.

In reifen Umgebungen wird die Erstellung neuer Teams an Bedingungen geknüpft: Namenskonvention wird automatisiert erzwungen, Ownership wird verpflichtend doppelt besetzt, und ein Template legt Kanäle, Tabs, Standardbibliotheken/Verknüpfungen und Sensitivitätslabels fest. Für Projekt-Teams gehört ein Ablaufdatum oder zumindest eine regelmäßige Rezertifizierung dazu; bei Ablauf wird der Workspace archiviert, inaktiv gesetzt oder nach einer Übergangsphase gelöscht. Technisch lassen sich diese Leitplanken über Entra ID (Azure AD), Sensitivity Labels für Container und Genehmigungsprozesse in den internen Serviceprozessen kombinieren; entscheidend ist die organisatorische Verbindlichkeit.

• Creation Guardrails: Team-Erstellung nur für definierte Personenkreise oder via Serviceprozess; Sensitivity Labels für Gruppen/Teams nutzen, um Gastzugriff und externe Freigaben policy-basiert zu steuern.
• Standard-Templates: Wiederkehrende Strukturen als Vorlage (Kanäle, Registerkarten, verlinkte SharePoint-Bibliotheken statt lokaler „Ablage-Ordner“ in jedem Team); damit bleibt „Teams zeigt Inhalte“ konsequent vom „SharePoint verwaltet Inhalte“ getrennt.
• Ownership und Vertretung: Mindestens zwei Owner je Team; bei Abteilungs-Workspaces zusätzlich Verantwortlichkeit über Rolle statt Person, um Fluktuation abzufangen.
• Lifecycle-Mechanik: Regelmäßige Rezertifizierung von Ownern und Mitgliedschaften; für inaktive Workspaces definierte Schritte „Archivieren → Read-only/Retention → Löschen“ mit dokumentierten Kriterien.

Governance gegen Fehlkonfigurationen: Policies, Monitoring und Korrekturpfade

Governance wirkt nur, wenn sie Fehlkonfigurationen früh sichtbar macht und Korrekturen ohne Eskalationsdrama ermöglicht. Dazu gehören technische Policies (z. B. Freigabelimits, Standard-Linktypen, Sensitivitätslabels, Aufbewahrung), aber ebenso Betriebsroutinen: regelmäßige Reviews von externen Gästen, verwaisten Teams, Sites ohne Owner, Bibliotheken mit tausenden Elementen ohne Metadaten und Bereiche mit massiven Berechtigungsbrüchen. Die Korrekturpfade sollten klar sein: Wann wird restrukturiert, wann wird in eine neue Site migriert, wann werden Inhalte in ein Records-Konzept überführt.

Typische Fehlkonfigurationen lassen sich eindeutig einordnen. Tiefe Ordnerstrukturen sind meist ein Symptom fehlender Taxonomie und fehlender Pflichtmetadaten. Unkontrollierte Team-Erstellung ist kein „Nutzerproblem“, sondern ein fehlender Provisioning-Prozess. Die Vermischung persönlicher und gemeinsamer Daten entsteht häufig dort, wo OneDrive-Freigaben als dauerhafte Teamablage missbraucht werden; hier braucht es klare Regeln, wann Inhalte aus OneDrive in die zuständige SharePoint-Bibliothek überführt werden. Governance bedeutet in diesem Kontext nicht maximale Einschränkung, sondern belastbare Spielregeln mit wenigen, gut begründeten Ausnahmen.

• Standardisierung von Freigaben: Standard-Linktyp und Ablaufregeln definieren; für sensible Bereiche Freigaben auf „bestimmte Personen“ beschränken und Rezertifizierung von Gästen etablieren.
• Kontrolle von Berechtigungsbrüchen: Berichte/Reviews für Sites und Bibliotheken mit gebrochener Vererbung; Abweichungen in separate Bibliotheken/Sites konsolidieren, statt Sonderrechte zu stapeln.
• Qualitätskriterien für Bibliotheken: Pflichtmetadaten, sinnvolle Views, Limitierung von Ordnern; für Masseninhalte gezielte Informationsarchitektur statt „Ordner nach Jahr nach Monat nach Tag“.
• Ownership- und Verwaisungsmanagement: Regel „keine Site/kein Team ohne Owner“; regelmäßige Prüfungen auf verwaiste Workspaces und definierte Übergabeprozesse.