Container-Labels: Teams, Microsoft-365-Gruppen und SharePoint-Sites klassifizieren – und was das für die Inhalte bedeutet

Der Satz fällt in fast jedem Workshop, und er klingt so vernünftig, dass ihn niemand hinterfragt: „Das Team ist doch als Vertraulich gelabelt, da sind die Dateien drin sicher." Sind sie nicht. In dem Team, über das wir gerade sprachen, lag eine Kalkulation ohne jedes Label, ein Angebot mit „Intern" und ein Vertrag als PDF, den drei Wochen zuvor jemand per „Jeder mit dem Link"-Freigabe an einen Lieferanten geschickt hatte. Das Team trug stolz sein Label im Kopfbereich – und hatte für die Dateien darin exakt nichts getan. Der Site-Besitzer war ehrlich überrascht. Der Datenschutzbeauftragte weniger.

Container-Labels sind eine der nützlichsten und zugleich meistmissverstandenen Funktionen von Microsoft Purview. Ein Sensitivity Label auf einem Team, einer Microsoft-365-Gruppe oder einer SharePoint-Site steuert, wer in den Raum darf: ob das Team privat ist, ob Gäste eingeladen werden dürfen, ob Freigabelinks nach draußen gehen, ob nicht verwaltete Geräte Dateien herunterladen dürfen. Das ist viel, und mit Copilot vor der Tür ist es die schnellste Bremse gegen Oversharing, die es gibt. Aber es ist Schutz der Hülle, nicht des Inhalts. Wer das verwechselt, hat einen gut beschrifteten Raum mit offenen Aktenschränken.

Dieser Artikel zeigt, was Container-Labels steuern und was nicht, wie die vier Stellschrauben zusammenspielen, wie du aus dem Container-Label über das Standard-Label je Bibliothek einen echten Inhaltsschutz machst und wie du Neubau und Bestand in den Griff bekommst. Den Rahmen liefert der Überblick zum Kompetenzbereich Microsoft Purview; für die Berechtigungsarchitektur dahinter ist der SharePoint-Kompetenzbereich zuständig – hier geht es ausschließlich um den Purview-Winkel.

Container vs. Inhalt: dasselbe Label, zwei Wirkungswelten

Die Verwirrung hat einen einfachen Grund: Es ist dasselbe Label. Wenn du „Vertraulich" anlegst und den Geltungsbereich um Gruppen und Sites erweiterst, erscheint dieses eine Label sowohl im Word-Menü als auch im Dialog zum Anlegen eines Teams. Gleicher Name, gleiche Farbe, gleiche Ein-Satz-Definition. Aber je nachdem, worauf es angewendet wird, tut es völlig verschiedene Dinge. Am Dokument steuert es Markierung, Verschlüsselung und Nutzungsrechte; am Team steuert es Privatsphäre, Gäste, Freigabe und Geräte. Die Einstellungen stehen im Label nebeneinander, in getrennten Registerkarten, und keine Einstellung der einen Welt wirkt in der anderen.

Was Container-Labels steuern

Ein Container-Label „Vertraulich" kann festlegen: Das Team ist privat, niemand tritt selbst bei. Die Besitzer dürfen keine Gäste hinzufügen (oder dürfen es, wenn du es so willst). Die SharePoint-Site der Gruppe erlaubt keine Freigabe an „Jeder", sondern nur an vorhandene Gäste oder nur an Personen der Organisation. Nicht verwaltete Geräte – der private Laptop, das Handy ohne Intune – bekommen nur eingeschränkten Webzugriff ohne Download oder werden ganz ausgesperrt. Der Standard-Freigabelink zeigt auf „bestimmte Personen" statt auf „Personen in Ihrer Organisation". Und optional verlangt der Zugriff einen Entra-Authentifizierungskontext, hinter dem eine Conditional-Access-Richtlinie steht – etwa Mehrfaktor-Authentifizierung oder ein konformes Gerät.

Das Label ist außerdem sichtbar: im Kopfbereich des Teams, im Header der SharePoint-Site, in der Gruppenansicht von Outlook. Diese Sichtbarkeit ist kein Detail. Sie ist der Grund, warum Container-Labels ein Kulturwerkzeug sind – wer täglich „Vertraulich – Projekt Phoenix" über seinem Team liest, überlegt beim Einladen des externen Beraters einen Moment länger. Und weil die Einstellungen aus dem Label kommen, kann der Site-Besitzer sie nicht eigenmächtig aufweichen; will er Gäste, muss er das Label wechseln, und das sieht man.

Was Container-Labels nicht tun – und warum das ständig übersehen wird

Jetzt der Teil, den du dem Fachbereich dreimal erklären musst. Ein Container-Label verändert keine einzige Datei im Container. Es labelt keine Dokumente, es verschlüsselt nichts, es setzt keine Kopfzeile, es aktiviert keine DLP-Richtlinie am Dokument. Eine Kalkulation ohne Label in einem „Vertraulich"-Team ist eine Kalkulation ohne Label. Wer sie herunterlädt, per Mail weiterschickt oder in eine Fremd-Cloud kopiert, nimmt genau null Schutz mit – das Container-Label bleibt an der Site zurück. Und umgekehrt: Ein Dokument mit Verschlüsselung per Label ist auch in einem öffentlichen Team geschützt, weil der Schutz am Objekt hängt, nicht am Ort. Wie das im Detail funktioniert, steht im Spoke zur Verschlüsselung per Sensitivity Label.

Warum wird das so oft übersehen? Weil das Label sichtbar ist. Der Site-Besitzer sieht „Vertraulich" im Header und schließt daraus, dass alles darunter vertraulich ist. Purview tut nichts, um diesen Eindruck zu korrigieren – es gibt keine Warnung „Diese Site ist Vertraulich, aber 340 Dateien darin haben kein Label". Diese Lücke musst du selbst schließen, und wie das geht, ist Thema von Kapitel 3. Vorher noch die Stellschrauben im Detail.

Skizze 1: Container vs. Inhalt – dasselbe Label steuert am Team die Hülle und am Dokument den Inhalt; keine Einstellung wirkt in der anderen Welt.

Die vier Stellschrauben: Privatsphäre, Gäste, Freigabe, Geräte

Die Container-Einstellungen eines Labels sind schnell konfiguriert – die Kunst liegt darin, sie zu den Stufen deines Modells passend zu wählen. Ich gehe sie in der Reihenfolge durch, in der sie in Projekten diskutiert werden, und mit den Werten, die sich für ein Vier-Stufen-Modell bewährt haben. Wie das Stufenmodell selbst entsteht, steht im Spoke zur Einführung von Sensitivity Labels; hier geht es um die Container-Seite davon.

Privatsphäre ist die einfachste: „Öffentlich" und „Intern" dürfen öffentliche Teams sein, in denen jeder im Unternehmen stöbern und beitreten kann; ab „Vertraulich" ist privat Pflicht. Gastzugriff ist die umstrittenste: In vielen Unternehmen sollen Gäste in „Vertraulich"-Teams grundsätzlich möglich sein, weil dort Projekte mit Partnern laufen – dann bleibt der Schalter offen, und der Schutz kommt über die Verschlüsselung der Inhalte. Wer stattdessen „keine Gäste ab Vertraulich" wählt, hat es leichter im Datenschutz, aber schwerer mit den Fachbereichen; die Antwort ist eine Frage der Unternehmenskultur, nicht der Technik. Externe Freigabe der Site ist die wirksamste Bremse gegen Oversharing: „Jeder"-Links (anonym) sollten ab „Intern" verboten sein, „Vertraulich" erlaubt bestenfalls Freigaben an vorhandene Gäste, „Streng vertraulich" nur an Personen der Organisation. Und Gerätezugriff schließlich: Web-only für nicht verwaltete Geräte ab „Vertraulich" ist ein Standard, der Downloads auf Privatgeräte unterbindet, ohne die Zusammenarbeit im Browser zu stören – vorausgesetzt, die dahinterliegende Conditional-Access-Richtlinie existiert.

Zwei Sonderfälle verdienen einen eigenen Absatz. Der Authentifizierungskontext ist die stärkste, aber auch anspruchsvollste Stellschraube: Das Label verweist auf einen in Entra definierten Kontext, und eine Conditional-Access-Richtlinie legt fest, was beim Zugriff auf Container mit diesem Kontext gilt – Mehrfaktor-Authentifizierung, ein konformes Gerät, ein bestimmter Standort. Damit lässt sich „Streng vertraulich" auf ein Niveau heben, das ohne Label nur mit Handarbeit je Site erreichbar wäre; der Preis ist Entra ID P1 und ein Team, das Conditional Access beherrscht. Der zweite Sonderfall sind Kommunikationssites und klassische Sites ohne Gruppe: Sie kennen keine Privatsphäre und keine Gäste im Gruppensinn, aber sehr wohl externe Freigabe und Gerätezugriff. Das Label wird dort über das SharePoint Admin Center oder PowerShell gesetzt und wirkt auf genau die Einstellungen, die die Site hat – der Rest bleibt still.

Die Tabelle zeigt eine bewährte Belegung der Container-Einstellungen über vier Stufen. Sie ist Ausgangspunkt für den Workshop mit den Fachbereichen, nicht Endergebnis – vor allem die Gastfrage bei „Vertraulich" entscheidet jedes Unternehmen anders.

Das Zusammenspiel: wie aus dem Container-Label ein Inhaltsschutz wird

Jetzt zur Lücke. Wenn ein Container-Label die Dateien nicht anfasst, wie sorgst du dafür, dass in einem „Vertraulich"-Team auch vertrauliche Dateien liegen? Die Antwort hat zwei Teile: ein Standard-Label für Inhalte, das an der Bibliothek hängt, und – als Sicherheitsnetz – die Kette aus Standard-Label der Label-Richtlinie, DLP und Auto-Labeling. Die Bibliothekseinstellung ist der elegantere Weg, aber sie kostet E5.

Standard-Label je Dokumentbibliothek: die Site erzieht ihre Dateien

SharePoint erlaubt es, für eine Dokumentbibliothek ein Standard-Sensitivity-Label festzulegen. Jede neue Datei, die dort entsteht, und jede Datei, die ohne Label hochgeladen wird, bekommt automatisch dieses Label – inklusive Markierung und, wenn konfiguriert, Verschlüsselung. Bereits gelabelte Dateien werden nicht überschrieben, es sei denn, ihr Label hat eine niedrigere Priorität. Damit schließt sich der Kreis: Ein Team „Vertraulich – Projekt Phoenix" mit Container-Label bekommt in seiner Standardbibliothek das Inhaltslabel „Vertraulich", und plötzlich stimmt der Eindruck des Site-Besitzers wirklich. Der Schutz an der Datei reist mit, wenn sie das Team verlässt; das Container-Label bleibt und regelt weiter, wer reinkommt.

Ein paar Details, die im Betrieb wichtig werden: Die Einstellung sitzt an der Bibliothek, nicht am Container-Label – du musst sie also je Site setzen oder per PowerShell und Skript verteilen, und bei neuen Teams gehört sie in die Team-Vorlage oder in einen kleinen Provisionierungsprozess. Sie erfasst nur Office-Dateien und PDFs, die SharePoint labeln kann; ein CAD-Modell oder eine ZIP-Datei bleibt außen vor. Und sie braucht E5 für die Benutzer, deren Dateien gelabelt werden. Wer nur E3 hat, fährt die zweitbeste Strecke: Das Standard-Label der Label-Richtlinie („Intern") sorgt für ein Mindestlabel, DLP-Richtlinien mit der Bedingung „liegt in Site mit Container-Label Vertraulich" bremsen den externen Versand, und die Anwender stufen bewusst hoch. Das funktioniert, aber die Bibliothek erzwingt dann nichts.

Skizze 2: Die Wirkungskette – Container-Label und Standard-Label je Bibliothek greifen ineinander; ohne Schritt 3 liegen in einem „Vertraulich"-Team ungelabelte Dateien.

Einführung: Neubau absichern, Bestand einfangen, Betrieb organisieren

Container-Labels führst du in einer anderen Reihenfolge ein als Inhalts-Labels. Bei Dokumenten fängst du mit einer Pilotgruppe an; bei Containern fängst du damit an, dass keine neuen ungelabelten Container mehr entstehen – denn jedes Team, das heute ohne Label angelegt wird, ist morgen Teil des Bestandsproblems. Danach kommt der Bestand, und der ist in den meisten Tenants größer und unordentlicher, als der SharePoint-Administrator zugeben mag.

Für den Neubau reichen drei Handgriffe: die Container-Unterstützung in Entra aktivieren, drei bis vier Labels mit Container-Scope in der Label-Richtlinie veröffentlichen und in dieser Richtlinie das Label als Pflicht beim Anlegen von Gruppen und Sites setzen – dazu ein Standard-Label für Container („Intern"), damit niemand aus Bequemlichkeit „Öffentlich" wählt. Wer Team-Vorlagen einsetzt, hinterlegt dort das passende Label. Ab diesem Moment trägt jedes neue Team ein Label, und der Besitzer hat beim Anlegen einmal bewusst über Gäste und Freigabe nachgedacht.

Der Bestand ist Handarbeit mit Skriptunterstützung. Zuerst die Inventur: alle Teams, Gruppen und Sites mit Besitzern, Privatsphäre, Gastanzahl und Zahl der „Jeder"-Links – das liefern SharePoint Admin Center, Graph und die Oversharing-Berichte. Dann bekommen die Besitzer eine Frist, ihre Container selbst zu labeln, mit einer Einseiter-Erklärung, welche Stufe wofür gilt. Was nach der Frist übrig ist, wird per PowerShell oder Graph auf „Intern" gesetzt – lieber ein konservatives Label als keines. Verwaiste Container ohne Besitzer sind ein eigenes Thema: Erst Besitzer nachziehen, dann labeln, sonst archivieren. Wie sich das mit den Oversharing-Berichten und Restricted Content Discovery zur Copilot-Vorbereitung verzahnt, behandelt der Spoke zum Oversharing in SharePoint vor Copilot.

Der Betrieb schließlich ist weniger Purview-Portal als Governance-Routine. Für Container mit „Vertraulich"-Label und Gästen gehört ein Access Review in Entra dazu – vierteljährlich bestätigt der Besitzer, dass die Gäste noch gebraucht werden, sonst fliegen sie raus. Label-Änderungen an Containern tauchen im Audit-Log auf und gehören in einen monatlichen Blick: Wer hat welches Team von „Vertraulich" auf „Intern" gestellt, und warum? Und die Oversharing-Berichte aus DSPM for AI und SharePoint werden gegen die Labels gelesen: Ein Team mit „Streng vertraulich" und dreißig „Jeder"-Links kann es technisch nicht mehr geben, wenn das Label sitzt – taucht es trotzdem auf, sind die Links älter als das Label und müssen manuell entfernt werden. Diese drei Routinen machen aus einem einmaligen Projekt einen Zustand, der hält.

Skizze 3: Einführung in drei Phasen – erst verhindern, dass neue ungelabelte Container entstehen, dann den Bestand einfangen, dann in den Betrieb übergehen.

Als Umsetzungshilfe die Schritte in der Reihenfolge, in der ich sie in Projekten abarbeite. Die Wochenangaben sind Richtwerte für einen Mittelständler mit einigen hundert Teams; bei Tausenden Containern verlängert sich vor allem Phase 2.

Der Deutschland-Winkel: Gäste, Datenschutz und der Betriebsrat

Container-Labels sind für den Datenschutzbeauftragten ein Geschenk, weil sie eine der schwierigsten DSGVO-Fragen technisch beantwortbar machen: Wer außerhalb des Unternehmens hat Zugriff auf welche personenbezogenen Daten? Jeder Gast in einem Team ist ein externer Empfänger, und je nach Konstellation ein Auftragsverarbeiter, ein gemeinsam Verantwortlicher oder ein Dritter im Sinne der DSGVO. Ein Label, das ab „Vertraulich" Gäste nur mit Access Review erlaubt und ab „Streng vertraulich" gar nicht, ist eine dokumentierbare technisch-organisatorische Maßnahme nach Art. 32 und macht die Frage im Verzeichnis der Verarbeitungstätigkeiten beantwortbar. Der Datenschutzbeauftragte sollte die Belegung der Container-Einstellungen mitentscheiden, vor allem die Gast- und Freigabespalte; für NIS2-pflichtige Unternehmen zahlt derselbe Mechanismus auf die Zugriffskontrollanforderungen ein.

Beim Betriebsrat sind Container-Labels weniger heikel als andere Purview-Module – sie bewerten keine Menschen, sie regeln Räume. Zwei Punkte gehören trotzdem in die Purview-Betriebsvereinbarung: Die Inventur des Bestands listet Besitzer namentlich, und der Bericht „wer hat welches Container-Label geändert" ist eine Auswertung über Beschäftigte, die nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig sein kann. Der pragmatische Weg ist derselbe wie überall: Auswertungszwecke benennen, Zugriff auf die Berichte beschränken, keine Einzelbewertung. Und wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist gehören ins Boot.

Stolperfallen aus der Praxis

Das Container-Label als Inhaltsschutz verkauft. Der Site-Besitzer glaubt, seine Dateien seien geschützt, und geht entsprechend sorglos mit Downloads um. Kommunikation von Tag eins: Das Container-Label regelt den Raum, das Inhaltslabel die Akten. Beides gehört zusammen.

Entra nicht freigeschaltet, Label-Sync vergessen. Das Label hat den Container-Scope, aber im Teams-Dialog erscheint nichts. Zwei PowerShell-Zeilen, die in jedem zweiten Projekt in der ersten Stunde fehlen. Prüfliste vor dem Pilot.

Gerätezugriff eingeschränkt, Conditional Access nicht vorhanden. Die Einstellung „nur Web auf nicht verwalteten Geräten" wirkt nur, wenn die passende Conditional-Access-Richtlinie existiert. Ohne sie steht die Einstellung im Label und tut nichts – und keiner merkt es.

Externe Freigabe im Label strenger als der Tenant erlaubt – oder lockerer. Das Label kann die Tenant-Einstellung nur einschränken, nicht erweitern. Wer im Label „Jeder" erlaubt, während der Tenant auf „nur Gäste" steht, wundert sich, warum die Site trotzdem keine anonymen Links zulässt. Reihenfolge: Tenant-Stufe festlegen, dann Labels darunter staffeln.

Bestand ohne Frist an die Besitzer delegiert. „Bitte labelt eure Teams" ohne Datum und ohne Fallback führt dazu, dass nach drei Monaten dreißig Prozent gelabelt sind. Frist setzen, danach automatisch „Intern", verwaiste Container archivieren.

Site-Besitzer dürfen das Label frei ändern – ohne dass es jemand sieht. Ein Besitzer stuft sein „Vertraulich"-Team auf „Intern" herab, weil er Gäste braucht. Technisch erlaubt, aber es sollte im Audit-Log auffallen und in „Vertraulich"-Fällen eine Begründung verlangen. Die Label-Änderung am Container ist ein Ereignis, das man überwacht.

Fazit: Der Raum und die Akten – Container-Labels regeln den Raum

Container-Labels sind die schnellste und sichtbarste Governance-Maßnahme in Microsoft 365: Ein Label auf dem Team, und Privatsphäre, Gäste, Freigabe und Geräte sind geregelt, für jeden sichtbar und vom Besitzer nicht umgehbar. Sie sind die erste Bremse gegen Oversharing und die erste Antwort auf die Copilot-Frage „wo darf er überhaupt suchen". Aber sie schützen die Hülle, nicht den Inhalt – und erst mit dem Standard-Label je Bibliothek oder der Kette aus Richtlinien-Standard, DLP und bewusstem Höherstufen wird aus einem beschrifteten Raum ein geschützter. Wo Container-Labels im Gesamtbild aus Labels, DLP und Copilot-Absicherung stehen, zeigt der Purview-Überblick.

Wenn du wissen willst, wie viele deiner Teams und Sites heute ein Label tragen, wie viele „Jeder"-Links im Umlauf sind und wie ein Container-Konzept für deinen Tenant aussähe: Die Purview-Standortbestimmung liefert genau diese Inventur – kompakt, zum Festpreis, mit Aktionsplan.

FAQ: Häufige Fragen zu Container-Labels für Teams und SharePoint

Was ist ein Container-Label in Microsoft Purview?

Ein Container-Label ist ein Sensitivity Label, dessen Geltungsbereich um „Gruppen und Sites" erweitert wurde und das auf Teams, Microsoft-365-Gruppen und SharePoint-Sites angewendet wird. Es steuert Einstellungen des Containers – Privatsphäre, Gastzugriff, externe Freigabe, Zugriff nicht verwalteter Geräte, Standard-Freigabelink und optional einen Authentifizierungskontext – und ist im Team- und Site-Header sichtbar. Die Inhalte im Container werden dadurch nicht gelabelt oder verschlüsselt.

Schützt ein Sensitivity Label auf einem Team auch die Dateien darin?

Nein. Das Container-Label regelt, wer in das Team kommt und wie die Site nach außen freigegeben werden darf; die Dateien darin behalten ihr eigenes Label oder haben keines. Wer eine ungelabelte Datei aus einem „Vertraulich"-Team herunterlädt, nimmt keinen Schutz mit. Für den Inhaltsschutz braucht es ein Sensitivity Label an der Datei – etwa über ein Standard-Label je Dokumentbibliothek (E5) oder das Standard-Label der Label-Richtlinie.

Brauche ich für Container-Labels Microsoft 365 E5?

Nein. Container-Labels mit Privatsphäre, Gastzugriff, externer Freigabe und Gerätezugriff sind ab Microsoft 365 E3 verfügbar; der Authentifizierungskontext braucht Entra ID P1 mit Conditional Access. E5 oder E5 Compliance brauchst du für das Standard-Sensitivity-Label je Dokumentbibliothek, mit dem Dateien in einer Site automatisch ein Inhaltslabel bekommen (Stand 2026).

Was ist der Unterschied zwischen einem Container-Label und den SharePoint-Freigabeeinstellungen?

Die SharePoint-Freigabeeinstellungen werden je Site vom Administrator oder Besitzer gesetzt und können jederzeit geändert werden. Ein Container-Label bündelt dieselben und weitere Einstellungen (Privatsphäre, Gäste, Geräte) in einem Label, das der Besitzer beim Anlegen wählt und das er nicht eigenmächtig aufweichen kann – will er lockerere Einstellungen, muss er das Label wechseln, was sichtbar und im Audit-Log nachvollziehbar ist. Das Label kann die Tenant-Freigabestufe nur einschränken, nie erweitern.

Kann ich bestehende Teams und Sites nachträglich mit einem Container-Label versehen?

Ja. Besitzer können das Label in den Team- oder Site-Einstellungen wählen, sofern es an sie veröffentlicht ist; Administratoren können Labels per PowerShell (Set-UnifiedGroup, Set-SPOSite) oder Microsoft Graph in großer Zahl setzen. Empfehlung: Besitzern eine Frist zur eigenen Entscheidung geben, danach den Rest automatisch auf ein konservatives Label wie „Intern" setzen und verwaiste Container zuerst mit Besitzern versorgen.

Hilft ein Container-Label gegen Oversharing vor der Copilot-Einführung?

Ja, als erste Maßnahme: Ein Label, das Teams privat schaltet, anonyme „Jeder"-Links unterbindet und Downloads auf nicht verwaltete Geräte verhindert, verkleinert den Bereich, in dem Microsoft 365 Copilot überhaupt suchen kann. Es ersetzt aber weder das Aufräumen von Berechtigungen noch das Inhaltslabel mit Verschlüsselung, das die eigentliche Copilot-Grenze über das EXTRACT-Recht bildet.

Wo fange ich mit Container-Labels an?

Mit dem Neubau: Container-Unterstützung in Entra freischalten, drei bis vier bestehende Labels um den Container-Scope erweitern, die Container-Einstellungen je Stufe mit Fachbereichen und Datenschutzbeauftragtem festlegen und in der Label-Richtlinie das Label beim Anlegen von Teams und Sites zur Pflicht machen. Erst danach den Bestand inventarisieren und über Besitzer und Skripte nachziehen – und für „Vertraulich"-Sites das Standard-Label je Bibliothek ergänzen.