Microsoft Teams-Governance – Grundlagen, Umsetzung, Praxis

1. Management Summary

Microsoft Teams hat sich in vielen Unternehmen als zentrales Werkzeug für Zusammenarbeit etabliert – oft jedoch schneller, als strukturierte Leitplanken dafür definiert wurden. Ohne klare Governance drohen unkontrolliertes Wachstum von Teams („Teams-Wildwuchs“) und Risiken: Vertrauliche Daten können in falsche Hände gelangen, Projekte nutzen unübersichtlich viele Arbeitsbereiche, und es fehlen Zuständigkeiten sowie Nachweise für Compliance. Dieses Whitepaper zeigt, wie eine durchdachte Microsoft Teams-Governance Abhilfe schafft. Zielbild ist eine Umgebung, in der jedes Team geregelten Lebenszyklen folgt, Verantwortliche bekannt sind, Zugriffsrechte kontrolliert werden und alle regulatorischen Vorgaben eingehalten werden.

Ohne Governance entstehen erhebliche Schwachstellen. Wesentliche Risiken ohne Teams-Governance: Schatten-IT blüht, weil Nutzer eigene Lösungen nutzen, wenn offizielle Wege zu kompliziert sind. Datenabfluss und Haftungsrisiken nehmen zu, etwa wenn externe Gäste unkontrolliert Zugang zu sensiblen Informationen behalten. Die Anzahl der Teams wächst ungebremst („Wildwuchs“), was zu redundanten Inhalten und erhöhten Kosten führt. Audits und Datenschutz-Prüfungen werden zur Herausforderung, da Nachvollziehbarkeit fehlt. Dem stehen klare Vorteile einer konsequenten Governance gegenüber: Einheitliche Richtlinien und automatisierte Prozesse steigern die Sicherheit und Compliance, ohne die Produktivität zu bremsen. Teams werden einheitlich strukturiert, was die Wiederauffindbarkeit von Informationen verbessert und die bereichsübergreifende Zusammenarbeit erleichtert. Verantwortlichkeiten sind definiert, wodurch Entscheidungen schneller getroffen und Probleme rascher gelöst werden. Insgesamt sinken Betriebsaufwand und Kosten, weil weniger manuelle Nacharbeit und Bereinigungen nötig sind.

Durch einige Quick-Wins innerhalb 30/60/90 Tagen lässt sich bereits spürbarer Fortschritt erzielen: – 30 Tage: Ist-Analyse der bestehenden Teams-Landschaft, Einführung erster Richtlinien (z.B. Namenskonventionen, wer Teams anlegen darf) und Sensibilisierung der Eigentümer für ihre Pflichten. – 60 Tage: Einrichtung eines geregelten Antrags- und Genehmigungsprozesses für neue Teams, Pilotierung eines Provisionierungs-Tools wie CosyTrack.Provisioner in einem Fachbereich, sowie Aktivierung wichtiger Compliance-Funktionen (z.B. grundlegende DLP-Regeln, Gastzugriffsbeschränkungen). – 90 Tage: Ausrollen der Governance unternehmensweit: alle neuen Teams durchlaufen den definierten Prozess; Sensitivitäts- und Aufbewahrungsrichtlinien sind umgesetzt; ein Dashboard zeigt KPIs zur Nutzung und Compliance an; erste Rezertifizierungsrunden für bestehende Teams starten.

Handlungsempfehlung: Die Einführung von Teams-Governance sollte Chefsache sein und bereichsübergreifend abgestimmt werden (IT, Informationssicherheit, Datenschutz, Fachbereiche). Starten Sie kurzfristig mit klar formulierten Richtlinien und nutzen Sie verfügbare Tools zur Automatisierung. Setzen Sie auf Schulung der Nutzer und transparente Prozesse, um Akzeptanz zu schaffen. Die folgenden Kapitel liefern dazu konkrete Modelle, Praxisbeispiele und Checklisten, um innerhalb weniger Monate eine sichere, effektive und auditierbare Nutzung von Microsoft Teams zu gewährleisten.

2. Grundlagen

Governance vs. Administration: Unter Microsoft Teams-Governance versteht man die strategische Steuerung und Leitplanken für den Einsatz von Teams im Unternehmen. Governance legt fest, was erlaubt ist, wie etwas zu erfolgen hat und wer wofür verantwortlich ist. Administration und Betrieb hingegen kümmern sich um das tägliche Wie – sie setzen die Vorgaben technisch um und halten den Dienst am Laufen (z.B. Benutzerverwaltung, Support, Updates). Vereinfacht gesagt: Governance gibt den Rahmen und die Regeln vor, Administration führt die konkreten Maßnahmen durch.

Bausteine einer Teams-Governance: Effektive Governance besteht aus mehreren ineinandergreifenden Elementen: – Richtlinien: Schriftlich definierte Vorgaben, z.B. zur Team-Benennung, Gastzugriff, Klassifizierung von Informationen oder zur Aufbewahrungsdauer von Chats. – Prozesse: Klare Abläufe, wie diese Richtlinien umgesetzt werden (etwa der Prozess zur Beantragung eines neuen Teams oder zur regelmäßigen Überprüfung bestehender Teams). – Rollen und Verantwortlichkeiten: Definition, wer welche Aufgaben in diesen Prozessen übernimmt – vom Team-Eigentümer über IT-Administratoren bis hin zu Compliance-Verantwortlichen (RACI-Modell). – Kontrollen: Mechanismen, um die Einhaltung der Richtlinien zu überwachen, z.B. regelmäßige Audits, Reviews oder technische Policies, die automatisch greifen. – Automatisierung: Technische Tools und Skripte, welche die Prozesse unterstützen und manuelle Arbeit reduzieren (z.B. automatisierte Provisionierung neuer Teams oder Benachrichtigungen bei Verstößen). – Monitoring: Kontinuierliches Beobachten von Nutzung und Sicherheit – über Dashboards, Berichte und das Überprüfen von Kennzahlen (KPIs) lässt sich der Erfolg der Governance messen. – Audits: Formale Prüfungen (intern oder extern), die in definierten Abständen sicherstellen, dass Richtlinien eingehalten werden und der Umgang mit Teams revisionssicher ist.

Integration in Microsoft 365: Teams-Governance lässt sich nicht isoliert betrachten – sie greift auf Funktionen der gesamten Microsoft-365-Plattform zurück: – Microsoft Entra ID (Azure AD): Steuert Identitäten und Zugriffsrechte. Hier wird z.B. festgelegt, wer Teams überhaupt erstellen darf, und Gastbenutzer werden verwaltet. Zudem ermöglicht Entra ID Funktionen wie Access Reviews (regelmäßige Überprüfung externer Nutzer) und Conditional Access (Bedingter Zugriff), um bestimmte Geräte/Standort-Voraussetzungen für den Teams-Zugriff vorzugeben. – SharePoint Online: Jede Teams-Instanz hat im Hintergrund eine SharePoint-Teamwebsite, auf der Dateien liegen. Governance muss daher auch SharePoint-Richtlinien einschließen – etwa die Anwendung von Vertraulichkeitsbezeichnungen auf Sites, Berechtigungssteuerung oder Regeln für die externe Freigabe von Dokumenten. – OneDrive for Business: Dateien, die in privaten Chats geteilt werden, landen im OneDrive der Benutzer. Entsprechend greifen Aufbewahrungsvorgaben und DLP-Regeln auch hier. Die Governance sollte berücksichtigen, wie Chat-Inhalte (die in Exchange Online und OneDrive gespeichert werden) verwaltet und geschützt werden. – Microsoft Purview (Compliance Center): Purview bündelt die Compliance- und Schutzfunktionen. Hier werden Aufbewahrungsrichtlinien definiert (z.B. Chats löschen nach 1 Jahr), Data Loss Prevention (DLP) Regeln verwaltet, und eDiscovery-Abfragen für rechtliche Untersuchungen durchgeführt. Ein Governance-Konzept legt fest, welche dieser Regeln für Teams-Inhalte gelten. – Teams-spezifische Richtlinien: Über das Teams Admin Center können detailreiche Einstellungen gesetzt werden – etwa Meeting-Richtlinien (wer darf aufzeichnen, Lobby-Einstellungen), Messaging-Richtlinien (Bearbeiten/Löschen von Nachrichten, Nutzung von GIFs), App-Berechtigungsrichtlinien (welche Apps erlaubt oder blockiert sind) und Teams-Vorlagen. Diese technischen Policies setzt die IT gemäß den Governance-Vorgaben, um das gewünschte Nutzungsverhalten in Teams zu erzwingen.

3. Warum Teams-Governance unverzichtbar ist

Ohne ein gezieltes Governance-Konzept läuft die Nutzung von Microsoft Teams aus dem Ruder. Im Folgenden sind die größten Risiken skizziert, wenn Unternehmen auf Governance verzichten, und welchen Nutzen eine gute Governance dagegen bringt – jeweils veranschaulicht durch praxisnahe Beispiele.

Risiken ohne Governance: – Schatten-IT: Wenn es keinen klaren Prozess gibt, um benötigte Teams anzulegen, weichen Mitarbeitende auf inoffizielle Lösungen aus. Beispiel: Ein Projektteam nutzt unerlaubt WhatsApp oder private Cloud-Speicher, weil ein offizielles Team nicht schnell genug bereitsteht – Firmeninformationen landen so außerhalb der kontrollierten IT-Umgebung. – Datenabfluss und Zugriffsrisiken: Ohne Richtlinien für Gastzugriff und Berechtigungen kann vertrauliches Material unkontrolliert nach außen gelangen. Beispiel: Externe Berater behalten nach Projektende weiterhin Zugang zum Team, weil niemand ihren Zugriff entzieht. Auch interne Berechtigungen geraten außer Kontrolle, wenn etwa ehemalige Mitarbeiter noch in Teams bleiben. – Haftungs- und Compliance-Risiken: Gesetzliche Vorgaben (z.B. DSGVO, handelsrechtliche Aufbewahrung) werden ohne Governance leicht verletzt. Beispiel: Chat-Protokolle mit personenbezogenen Daten werden unbefristet aufbewahrt, da keine Löschfristen definiert sind – im Falle einer Prüfung drohen Sanktionen wegen Verstoßes gegen Datenschutz oder Archivierungspflichten. – Wildwuchs & Ineffizienz: In einer ungeregelten Umgebung entstehen unzählige redundante oder verwaiste Teams. Beispiel: Für ein und dasselbe Thema existieren fünf unterschiedliche Teams, weil jeder Bereich eigenständig eines erstellt hat. Wissen verteilt sich fragmentiert, Mitarbeiter verlieren Zeit bei der Suche nach der richtigen Plattform, und wichtige Informationen gehen unter. – Kostensteigerung: Wildwuchs treibt auch Kosten. Beispiel: Zig ungenutzte Teams belegen Speicherplatz mit Dateien und Aufzeichnungen, was Speicher- und Backup-Kosten erhöht. Zudem muss der IT-Support häufiger eingreifen, um Chaos zu beheben (z.B. Berechtigungen manuell bereinigen), was personelle Ressourcen bindet. – Audithürden: Bei Prüfungen (internes Audit, Zertifizierungen, Kundenvorgaben) kann das Unternehmen ohne nachweisbare Kontrollen schlechte Karten haben. Beispiel: Ein Auditor fragt nach, wer Zugriff auf sensible Kundenunterlagen in Teams hatte – ohne Governance gibt es weder saubere Rollenvergaben noch Aktivitätsprotokolle, um diese Frage überzeugend zu beantworten.

Nutzen mit Governance: – Sicherheit und Zugriffs­kontrolle: Klare Regeln stellen sicher, dass nur berechtigte Personen auf Informationen zugreifen. Beispiel: Dank definierter Teams-Besitzer und regelmäßiger Überprüfung der Mitgliederlisten (Rezertifizierung) bleiben Team-Inhalte auf aktuelle Berechtigte beschränkt. Sensible Bereiche sind durch Sensitivitätslabel zusätzlich abgesichert (z.B. keine externen Gäste in „vertraulichen“ Teams). – Compliance und Nachweisbarkeit: Mit Governance werden regulatorische Vorgaben systematisch erfüllt. Beispiel: Durch Aufbewahrungsrichtlinien werden alle Teams-Chats nach 180 Tagen automatisch gelöscht, sofern sie nicht als geschäftsrelevant klassifiziert sind. Audit-Logs und Dokumentationen zeigen jederzeit, dass Datenschutz- und Archivierungsvorschriften eingehalten werden – im Prüffall kann das Unternehmen sauber belegen, wie mit Daten umgegangen wird. – Produktivität und Struktur: Governance bedeutet nicht Bürokratie, sondern auch Effizienzgewinne. Beispiel: Einheitliche Namenskonventionen und vorgegebene Team-Vorlagen helfen Mitarbeitern, das richtige Team schneller zu finden und sich darin zurechtzufinden. Ein neuer Mitarbeiter weiß dank Standard-Struktur (etwa immer ein „Allgemein“- und „Projektstatus“-Kanal) sofort, wo er Informationen findet – das Onboarding in neuen Teams geht schneller. – Skalierbarkeit und Ordnung: Mit definierten Prozessen kann die Organisation deutlich mehr Teams beherrschen, ohne Chaos zu riskieren. Beispiel: Das Unternehmen wächst um 500 neue Teams in einem Jahr – dank automatisierter Provisionierung und klaren Verantwortlichkeiten bleibt die Umgebung dennoch geordnet. Jedes neue Team durchläuft den gleichen Genehmigungs- und Einrichtungsvorgang, was konsistente Qualität garantiert. – Geringere Betriebskosten: Weniger Wildwuchs und Automation führen zu Einsparungen. Beispiel: Wo früher ein Admin manuell Teams angelegt und hinterher aufgeräumt hat, erfolgt dies nun per Self-Service mit Kontrolle – der Administrationsaufwand sinkt spürbar. Auch Supportfälle à la „Ich finde meine Dateien nicht“ nehmen ab, da die Struktur klar vorgegeben ist. Insgesamt spart die IT Zeit und Lizenzen (z.B. durch das rechtzeitige Löschen inaktiver Teams), was die Kosten senkt.

4. Architektur- und Rollenmodell

Eine durchdachte Governance basiert auf einer klaren Ziel-Architektur und einem passenden Rollenmodell. Logisch betrachtet gibt es verschiedene Ebenen und Vorgaben, die zusammenspielen: – Mandant-Ebene: Auf höchster Ebene wird der Microsoft-365-Mandant als Ganzes betrachtet. Hier werden globale Richtlinien gesetzt, etwa welche Sensitivitäts-Labels es gibt oder ob Gäste grundsätzlich zugelassen sind. Die Governance-Architektur legt fest, dass es z.B. verschiedene Kategorien von Teams gibt (nach Vertraulichkeitsstufe oder Verwendungszweck), für die unterschiedliche Regeln gelten. – Richtlinien-Ebenen: Einige Vorgaben gelten global für alle Teams (z.B. Namenskonventionen), andere können auf bestimmte Gruppen beschränkt sein (z.B. strengere Regeln für Teams mit sensiblen Daten). Das Modell kann z.B. vorsehen, dass projektbezogene Teams nach 180 Tagen Inaktivität archiviert werden, während permanente Abteilungsteams unbegrenzt bestehen dürfen. – Sensitivitätslabels als Steuerung: Vertraulichkeitsbezeichnungen (Sensitivity Labels) dienen als Schalter, um technische Einstellungen pro Team zu steuern. Beispielsweise könnte ein Label „Vertraulich“ bewirken, dass das entsprechende Team privat ist, keine Gäste aufnehmen darf und strenge DLP-Regeln greifen. Ein Label „Öffentlich“ hingegen erlaubt offene Mitgliedschaft und Gastzugriff. Die Architektur definiert, welche Labels für Teams genutzt werden und was sie bewirken. – Teams-Vorlagen: Standardisierte Team-Vorlagen sorgen für einheitliche Struktur und Ausstattung neu angelegter Teams. Eine Vorlage enthält vordefinierte Kanäle, Registerkarten (etwa OneNote, Planner) und Basis-Einstellungen. So wird sichergestellt, dass z.B. jedes Projektteam ähnlich aufgebaut ist und nichts Wichtiges vergisst (etwa einen „Projektplan“-Kanal). Die Governance-Architektur bestimmt, welche Vorlagen es gibt und wann welche zu verwenden sind. – Lebenszyklus und Ablaufdaten: Jedes Team durchläuft einen Lebenszyklus von der Entstehung bis zur möglichen Auflösung. Governance definiert diese Phasen und Übergänge. Zum Beispiel: Jedes Team hat ein Erstellungsdatum und wird nach 1 Jahr automatisch zur Überprüfung vorgelegt. In dieser Review-Phase entscheidet der Verantwortliche, ob das Team weiter aktiv bleibt, archiviert oder gelöscht wird. Auch Zwischenstufen wie temporäres Archivieren (nur-Lese-Zustand) sind möglich. Dieses Lebenszyklus-Konzept verhindert, dass Teams unkontrolliert dauerhaft bestehen bleiben.

Rollen und Verantwortlichkeiten (RACI-Modell): Ein zentrales Element der Governance ist die klare Zuweisung von Verantwortungen. RACI steht für Responsible (ausführend Verantwortlicher), Accountable (endgültig Verantwortlicher), Consulted (konsultiert) und Informed (zu informieren). Die folgende RACI-Matrix zeigt ein beispielhaftes Rollenmodell für typische Vorgänge im Teams-Lebenszyklus:

Vorgang	Team-Eigentümer (Antragsteller)	Fachbereichsleitung (Genehmiger)	Teams-Administrator (IT)	Compliance/Datenschutz
Team anlegen (Neuanlage)	R – Beantragt und liefert Informationen	A – Genehmigt das neue Team (fachlich)	I – Wird über neues Team informiert	C – Prüft bei Bedarf (z.B. Klassifizierung)
Wesentliche Änderung<br>(z.B. Gast hinzufügen)	R – Initiiert Änderung (lädt Gast ein)	C/A – Evtl. Freigabe durch Vorgesetzten je nach Richtlinie	A – Technische Umsetzung/Überwachung	C – Bei sensiblen Daten zur Beratung hinzugezogen
Periodische Rezertifizierung<br>(Team-Überprüfung)	R – Überprüft Mitglieder und Bedarf regelmäßig	A – Stellt Durchführung sicher (fordert ggf. ein)	I – Erhält Ergebnis/Protokoll der Überprüfung	I – Erkennt Gesamtstatus für Audits
Archivierung oder Löschung<br> eines Teams	R – Meldet Team zur Stilllegung an, liefert Bewertung	I – Wird informiert, bei kritischen Inhalten A für Freigabe	A – Führt Archivierung/Löschung technisch durch	C – Bestätigt Einhaltung von Aufbewahrungsfristen
Ausnahmefall (Policy-Ausnahme)	R – Beantragt Ausnahme begründet	I – Kennt die Ausnahme im eigenen Bereich	C – Berät zu machbaren Lösungen	A – Entscheidet über Gewährung der Ausnahme

Hinweis: Die Rollen und Zuständigkeiten können je nach Organisation variieren. Wichtig ist, dass für jede Aktion klar festgelegt ist, wer sie ausführt (R), wer die letzte Verantwortung trägt (A), wer fachlich mitreden darf (C) und wen man zumindest informieren muss (I). Dieses Modell schafft Transparenz und verhindert Überschneidungen oder Lücken in der Verantwortung.

5. Zehn zentrale Governance-Szenarien

5.1 Team-Lebenszyklusmanagement: Antrag → Genehmigung → periodische Review/Rezertifizierung → Archivierung/Löschung

Ziel & Bedeutung: Ohne gesteuerten Lebenszyklus entstehen immer mehr Teams, die nie wieder genutzt werden. Dieses Szenario adressiert den vollständigen Lebenszyklus jedes Teams – von der Beantragung über die aktive Nutzung bis zur geordneten Stilllegung. Ziel ist, dass kein Team ohne ausreichende Legitimation entsteht und kein überflüssiges Team unbegrenzt weiterbesteht.

Richtlinien & Prozesse: Es wird ein standardisierter Prozess eingeführt: Neue Teams müssen formal beantragt werden (durch den zukünftigen Besitzer oder Sponsor). Eine vordefinierte Instanz (z.B. die Fachbereichsleitung) genehmigt den Antrag nach Prüfung des Zwecks. Nach Freigabe wird das Team gemäß den Vorgaben erstellt (idealerweise automatisiert). Jedem Team wird bereits bei Anlage ein Review-Intervall mitgegeben – z.B. alle 180 Tage muss der Team-Eigentümer bestätigen, dass das Team noch benötigt wird und die Mitgliederliste aktuell ist (Rezertifizierung). Erfolgt keine Bestätigung oder ist das Projekt abgeschlossen, greift die nächste Phase: Archivierung des Teams (Inhalte bleiben schreibgeschützt erhalten) oder vollständige Löschung nach definierten Fristen. Wichtig ist auch ein Verfahren für Sonderfälle: Sollte ein Team ausnahmsweise länger inaktiv bleiben dürfen (etwa für Wissenstransfer), kann per Ausnahmegenehmigung die Aufbewahrungsfrist verlängert werden.

Technische Umsetzung: Microsoft 365 bietet Features wie die Gruppenablaufrichtlinie (Group Expiration Policy), die automatisch Team-Besitzer zur Verlängerung auffordert und Gruppen löscht, wenn niemand reagiert. Alternativ oder ergänzend kann ein Provisionierungstool (siehe Abschnitt 6) diese Logik umsetzen und z.B. Wiedervorlage-E-Mails versenden. Die Teams-Admin-Konsole ermöglicht das Archivieren von Teams mit einem Klick – im Governance-Prozess sollte definiert sein, wer diese Aktion ausführt (meist die IT auf Anstoß des Eigentümers). Für die Löschung sollte eine Prozedur bestehen, um zuvor die Einhaltung von Aufbewahrungsfristen zu prüfen und ggf. Daten zu exportieren (für Compliance).

Metriken & Beispiel: Erfolgskriterium ist u.a., dass kein Team die Überprüfung überfällig überschreitet. KPIs können sein: Anteil der Teams mit aktueller Rezertifizierung oder Anzahl archivierter vs. aktiver Teams. Ein praktisches Beispiel: Das Projektteam „Migration2025“ wird mit 1 Jahr Laufzeit angelegt. Nach 12 Monaten erhält der Eigentümer eine Erinnerung zur Verlängerung. Da das Projekt abgeschlossen ist, markiert er das Team zur Schließung. Die IT archiviert das Team, sodass Inhalte erhalten bleiben, aber keine neuen Beiträge mehr möglich sind. Nach weiteren 6 Monaten werden die Inhalte gemäß Aufbewahrungsrichtlinie endgültig gelöscht. Dieses geregelte Vorgehen verhindert Datenfriedhöfe und sorgt für aktuelle, relevante Teamräume.

5.2 Namenskonventionen & Klassifizierung: Sensitivitätslabels, Metadaten, zugehörige SharePoint-Sites, E-Mail-Aliasse

Ziel: Einheitliche und aussagekräftige Namen sowie Klassifizierungen der Teams sorgen für bessere Orientierung und unterstützen die Einhaltung von Sicherheitsvorgaben. Jedes Team sollte schon am Namen erkennbar sein – z.B. Abteilung oder Projekt – und eine formale Klassifizierung tragen (etwa vertraulich vs. öffentlich).

Risiken ohne Standard: Ohne Namenskonvention entstehen z.B. Teams namens „Projekt X“ ohne Hinweis, welcher Bereich dahintersteht, oder Dubletten wie „Marketing“ mehrfach. Das erschwert die Suche und fördert Verwechslungen. Fehlt die Klassifizierung, werden vertrauliche Inhalte womöglich nicht entsprechend behandelt (z.B. keine Kennzeichnung, dass ein Team personenbezogene Daten enthält).

Richtlinien & Umsetzung: Die Governance gibt ein Namensschema vor – etwa Abkürzung des Bereichs – Teamzweck – optional Sensitivität. Beispiel: FIN-Projekt Neptune (Intern) für ein internes Finanzprojekt. Technisch lässt sich dies mit einer Azure AD Namensrichtlinie unterstützen: Prefixe/Suffixe können automatisch hinzugefügt oder gesperrte Wörter blockiert werden (etwa keine Teamnamen, die „CEO“ enthalten). Zusätzlich sollen bei Team-Erstellung Klassifizierungsattribute vergeben werden. In Microsoft 365 können Sensitivitätslabels auf M365-Gruppen/Teams angewandt werden. Ein Label Öffentlich vs. Vertraulich könnte z.B. steuern, ob externe Gäste erlaubt sind und ob das Team im Adressbuch sichtbar ist. Wichtig: Diese Labels sollten für Nutzer verständlich benannt und ihre Bedeutung klar kommuniziert sein.

SharePoint- und E-Mail-Aspekte: Da jeder Team-Name auch im SharePoint-Site-Namen und im E-Mail-Alias der Gruppe erscheint, verhindern klare Regeln unschöne Bezeichnungen (eine Site „Marketing1“ oder ein Alias „ProjektX2@…“). Änderungen im Nachhinein sind aufwendig, daher muss der Name gleich zu Beginn stimmen. Die Richtlinie kann vorsehen, dass Team-Namen in Englisch oder Deutsch einheitlich verwendet werden – je nach Unternehmenssprache.

Klassifizierung nutzen: Neben Sensitivitätslabels können weitere Metadaten erfasst werden, z.B. Teamtyp (Projekt, Abteilung, externes Projekt) oder Datenkategorie. Diese Informationen helfen im Inventar-Management und ermöglichen gezielte Auswertungen (z.B. wie viele Teams welcher Kategorie existieren). Ein Provisionierungstool kann solche Pflichtfelder im Antragsformular verlangen.

Metriken & Beispiel: Ein Erfolgsmesser ist die Konformität der Teamnamen: z.B. 100% der neuen Teams folgen dem Schema ohne manuelle Nachkorrektur. Beispiel: Ohne Regel nennt ein Mitarbeiter sein Team schlicht „Vertrieb“, ein anderer „Sales-Team“ – Chaos ist vorprogrammiert. Mit Governance heißt es z.B. „SALE-Kundenprojekte-extern“ für ein Verkaufsteam mit externen Partnern. Sofort ist klar: Bereich Sales, Anwendungsfall Kundenprojekte, extern zugänglich.

5.3 Gastzugriff & externe Zusammenarbeit: B2B-Einladung, Conditional Access, zeitliche Begrenzung, Eigentümerpflichten

Ziel: Externe Partner (Kunden, Lieferanten, Berater) sollen kontrolliert und sicher in Teams zusammenarbeiten können, ohne die Unternehmens-IT zu gefährden. Governance definiert, wie Gäste eingeladen werden dürfen und wie lange sie Zugang haben, sowie welche Sicherheitsanforderungen gelten.

Risiken ohne Steuerung: Unregulierter Gastzugriff ist ein großes Sicherheitsloch. Beispiel: Ein Projektteam lädt spontan einen externen Berater mit seiner privaten Gmail-Adresse ein. Ohne Richtlinien könnte dieser Gast dauerhaft im Team verbleiben, auch wenn das Projekt endet, und weiterhin auf vertrauliche Dateien zugreifen. Zudem könnten Gäste unsichere Anmeldemethoden nutzen (ohne MFA), was das Risiko von Kontoübernahmen erhöht.

Governance-Maßnahmen: Zunächst sollte festgelegt sein, wer überhaupt Gäste einladen darf – typischerweise nur Team-Eigentümer oder definierte Personen. Die Einladung erfolgt über Azure AD B2B (sicheres Gästekonto). Bei sensiblen Teams kann ein zusätzlicher Genehmigungsschritt verlangt werden (z.B. Freigabe durch IT-Sicherheit oder den Vorgesetzten, bevor der Gast Zutritt erhält). Jeder Gast sollte einen Sponsor im Unternehmen haben (meist der Team-Eigentümer), der für dessen Zugriffe verantwortlich ist. Weiterhin ist eine maximale Zugriffsdauer festzulegen: Beispielsweise werden Gastkonten nach 90 Tagen Inaktivität automatisch deaktiviert, oder der Zugriff wird von vornherein bis zum Projektende befristet. Team-Besitzer müssen regelmäßig prüfen, ob ihre Gäste noch benötigt werden – Microsoft Entra ID Access Reviews können diesen Prozess unterstützen, indem periodisch eine Überprüfung aller Gastnutzer in einem Team ausgelöst wird.

Sicherheit & Compliance: Über Conditional Access Richtlinien sollte erzwungen werden, dass Gäste nur unter bestimmten Bedingungen zugreifen dürfen (z.B. nur mit Multi-Faktor-Authentifizierung und nicht aus bestimmten Hochrisiko-Ländern). Optional können Gäste auf ausgewählte Geräte oder Apps beschränkt werden (z.B. kein Download von Dateien auf private Geräte). Zudem können Terms of Use (Nutzungsbedingungen/NDA) präsentiert werden, die Externe bei erstem Login akzeptieren müssen.

Metriken & Beispiel: Sinnvolle Kennzahlen sind z.B. Anteil der Gastkonten mit aktuellem Review oder Durchschnittliche Verweildauer von Gastzugriffen. Ein Beispiel aus der Praxis: Eine externe Agentur erhält für die Dauer einer Kampagne Zugang zum Team „Marketing Kampagne 2025“. Governance stellt sicher, dass beim Einladen der Gäste ein Enddatum gesetzt wird. Nach Kampagnenende entfernt der Team-Eigentümer die Agentur-Mitarbeiter umgehend aus dem Team. Zudem hatte jeder Gast nur mit MFA und über das Web Zugriff, wodurch das Risiko eines Datenabflusses minimiert wurde.

5.4 Vorlagen, Provisionierung & Genehmigungsworkflow: standardisierte Teams-Typen, Pflichtfelder, automatische Ausstattung

Ziel: Die Bereitstellung neuer Teams soll schnell, kontrolliert und nach festen Standards erfolgen. Unterschiedliche Einsatzszenarien (Projektteam, Abteilungsteam, Team mit Externen etc.) werden durch Vorlagen abgebildet, sodass jedes neue Team die nötigen Strukturen und Einstellungen gleich mitbringt. Ein definierter Genehmigungsworkflow stellt sicher, dass nur legitime Teams entstehen.

Problem ohne Governance: Werden Teams ad-hoc von Benutzern erstellt, entstehen große Qualitätsunterschiede. Beispielsweise legt ein Mitarbeiter ein Team an, vergisst wichtige Kanäle oder Sicherheits-Einstellungen – oder erstellt versehentlich ein privates statt geteiltes Kanal-Konzept. Zudem können ohne Freigabe unnötige oder redundante Teams entstehen („jeder macht mal eins“). Die IT wird oft reaktiv eingebunden, um nachzubessern.

Lösung – Provisionierungsprozess: Governance etabliert einen workflow-basierten Ansatz: Ein Antragsteller füllt ein Formular aus (im einfachsten Fall ein Microsoft-Formular oder ein angepasstes Tool). Dort werden Pflichtangaben abgefragt: z.B. Name gemäß Richtlinie, Zweck des Teams, gewünschte Vorlage, Sensitivitätsstufe, verantwortlicher Eigentümer, voraussichtliche Dauer, ggf. Projekt- oder Ticketnummer zur Nachverfolgung. Dieses Gesuch durchläuft einen oder mehrere Genehmigungsschritte – typischerweise muss der Vorgesetzte oder Fachbereichsleiter zustimmen. Bei bestimmten Kriterien kann eine zweite Instanz einbezogen werden (etwa IT-Security, falls externe Beteiligung geplant ist). Nach Freigabe erfolgt die automatische Provisionierung: Das Team wird durch ein Script oder Tool erstellt, basierend auf der gewählten Vorlage. Automatisch werden definierte Standard-Kanäle angelegt (z.B. „Allgemein“, „Planung“, „Ergebnisse“), Registerkarten (Planner, OneNote, etc.) hinzugefügt und die initialen Besitzer/Mitglieder gemäß Antrag eingetragen.

Vorteile & technische Umsetzung: Durch diese Automatisierung reduziert sich die Bereitstellungszeit neuer Teams drastisch – von oft mehreren Tagen (manuelle Beantragung per E-Mail an IT) auf wenige Minuten. Gleichzeitig wird sichergestellt, dass jedes Team die Compliance-Vorgaben erfüllt: z.B. wird beim Anlegen gleich das passende Sensitivitätslabel gesetzt und eine Mindestanzahl an Team-Besitzern erzwungen (um Single Points of Failure zu vermeiden). Lösungen hierfür reichen von Power Automate/Logic Apps bis zu spezialisierten Drittanbieter-Tools (siehe CosyTrack.Provisioner im nächsten Abschnitt).

KPI & Beispiel: Als Kennzahl bietet sich die Durchlaufzeit von Team-Anträgen an (Ziel z.B. < 1 Tag von Antrag bis Team verfügbar). Ebenfalls relevant: Prozentsatz der automatisiert erstellten Teams (gegenüber händisch erstellten). Beispiel: In Firma X dauerte es früher bis zu 5 Werktage, ein neues Team zu bekommen (mehrere E-Mails, manuelle Einrichtung). Nach Einführung eines Self-Service-Portals mit Genehmigungsworkflow bekommt der Anwender sein Team binnen einer Stunde nach Freigabe – komplett mit voreingerichteter Struktur. Gleichzeitig sind alle Teams konsistent benannt und dokumentiert, was spätere Verwaltung und Audits erleichtert.

5.5 Kanalrichtlinien & Struktur: Standard-, private und geteilte Kanäle, Benennungsregeln, Verantwortlichkeiten, Datenlage

Ziel: Teams sollen innerhalb eine klare Kanalstruktur haben, die den Arbeitsabläufen entspricht, und der Einsatz von privaten oder geteilten Kanälen soll gezielt geregelt sein. Governance stellt sicher, dass Kanäle sinnvoll benannt und angelegt werden und alle wissen, wann welche Kanalart verwendet werden darf.

Arten von Kanälen: – Standard-Kanäle sind für alle Teammitglieder sichtbar und dienen der offenen Zusammenarbeit. – Private Kanäle sind auf einen Teil der Mitglieder begrenzt (für vertrauliche Unterthemen innerhalb des Teams). – Geteilte Kanäle ermöglichen sogar den Austausch mit spezifischen Personen außerhalb des Teams (auch organisationsübergreifend), ohne gleich alle ins Team einzuladen.

Governance-Vorgaben: Grundsätzlich sollte offene Kommunikation der Standard sein – d.h. Standard-Kanäle nutzen, wo möglich. Die Richtlinie könnte vorsehen, dass private Kanäle nur für wirklich sensible Themen genutzt werden dürfen, die nicht für alle Teammitglieder gedacht sind (z.B. ein Personal-Themenkanal im Team der Abteilung). Ebenso sollte festgelegt sein, wer private/geteilte Kanäle anlegen darf. Eine übliche Einstellung ist, dass nur Team-Besitzer dies dürfen (verhindert Wildwuchs an privaten Kanälen, die Administratoren schwer nachverfolgen können). Benennungsregeln für Kanäle können helfen, deren Inhalt klar zu machen – z.B. Präfixe wie „INT-“ für interne vertrauliche Kanäle.

Datenhaltung und technische Aspekte: Wichtig zu wissen: Private Kanäle haben eigene SharePoint-Sites, getrennt vom Hauptteam. Daher müssen Aufbewahrungs- und DLP-Richtlinien auch diese abdecken. Die Governance sollte dokumentieren, welche zusätzlichen Stellen (z.B. IT oder Compliance) Zugriff auf diese separaten Speicher haben, falls etwa eine eDiscovery-Suche ansteht. Für geteilte Kanäle ist zu beachten, dass Mitglieder aus anderen Organisationen direkt Zugriff auf einen Kanal bekommen – das erfordert in Entra ID die entsprechende Konfiguration (B2B Direct Connect) und sollte nur aktiviert sein, wenn geprüft wurde, dass die Partnerorganisation den nötigen Sicherheitsstandards entspricht.

Verantwortlichkeiten: Die Team-Eigentümer sind dafür verantwortlich, eine sinnvolle Kanalstruktur im Team zu etablieren und regelmäßig zu überprüfen. Sie sollten vermeiden, dass übermäßig viele Kanäle entstehen, die am Ende ungenutzt bleiben. Eine Governance-Regel kann z.B. sein, dass maximal eine gewisse Anzahl an Hauptkanälen erstellt werden darf, um Überschaubarkeit zu wahren, oder dass inaktive Kanäle nach Absprache entfernt werden.

Metriken & Beispiel: Ein möglicher KPI ist die Anzahl privater Kanäle pro Team (um früh einzugreifen, falls ein Team exzessiv vieles im Verborgenen diskutiert). Beispiel: Im Team „Entwicklung“ legen die Besitzer einen privaten Kanal „Management-Planung“ an, um vertrauliche Budgetthemen zu besprechen – konform zur Richtlinie, da sensible Informationen. Sie erlauben aber nicht, dass jeder Entwickler nach Belieben private Kanäle für Kleinigkeiten eröffnet. So bleibt die Kommunikation transparent, wo möglich, und vertraulich, wo nötig.

5.6 Aufbewahrung & Records Management: Retention, Löschkonzepte, eDiscovery-Vorbereitung, rechtssichere Stilllegung

Ziel: Unternehmensdaten in Teams müssen weder zu lange noch zu kurz aufgehoben werden – genau so lange, wie Gesetze und Geschäftsanforderungen es verlangen. Dieses Szenario stellt sicher, dass Chatnachrichten, Team-Beiträge und Dateien eine definierte Aufbewahrungsdauer haben und anschließend korrekt gelöscht oder archiviert werden. Gleichzeitig muss bei Bedarf (z.B. Rechtsstreit) die Wiederauffindbarkeit gewährleistet sein.

Richtlinien: Die Governance legt für verschiedene Datenkategorien in Teams klare Aufbewahrungsfristen fest. Beispielsweise: Informelle Chat-Nachrichten werden nach 6 Monaten gelöscht, formelle Team-Kanalbeiträge nach 3 Jahren, wichtige Dokumente (etwa in bestimmten Teams mit Projektabschlüssen) 10 Jahre. Diese Fristen orientieren sich an rechtlichen Vorgaben (z.B. handels- und steuerrechtliche Aufbewahrung von Geschäftsunterlagen) und internen Policies. Wo notwendig, werden Records (dauerhaft aufzubewahrende Dokumente) identifiziert – etwa durch ein Records-Management-Label, das verhindert, dass ein Dokument vor Ablauf von x Jahren gelöscht wird.

Technische Umsetzung: Microsoft Purview ermöglicht es, Retention-Richtlinien zu erstellen, die auf Teams-Inhalte angewendet werden. So kann eine Richtlinie alle Teams-Chats unternehmensweit nach 180 Tagen löschen (aus Benutzer-Sicht verschwinden die Nachrichten dann). Für Dateien in SharePoint und OneDrive lassen sich Aufbewahrungsbezeichnungen nutzen, die manuell oder automatisch gesetzt werden und die Löschfristen steuern. Wichtig: Bei sensiblen oder revisionsrelevanten Bereichen kann man Inhalte als Records deklarieren – diese können dann vor Ablauf der Frist nicht mehr geändert oder gelöscht werden (Schreibschutz). Die Teams-Governance sollte definieren, in welchen Fällen solche Schutzmechanismen genutzt werden (z.B. Vorstandskommunikation als „record“ behandeln).

eDiscovery & Stilllegung: Für gerichtsfeste Nachweise muss gewährleistet sein, dass auch nach Team-Löschung relevante Inhalte abrufbar sind. Lösung: Rechtssichere Stilllegung eines Teams bedeutet, es zwar für Benutzer zu schließen, die Daten aber bis zum Ablauf der Aufbewahrungsfrist intakt zu lassen (z.B. Team archivieren und Retention-Policy aktiv lassen, oder vor Löschung alle Inhalte exportieren). Zudem sollte das Unternehmen einen definierten eDiscovery-Prozess haben: Wer darf im Compliance-Portal Suchen durchführen? Wie wird ein „legal hold“ auf ein Team oder Nutzerpostfach gesetzt, wenn eine Litigation droht? Governance sorgt hier für klare Verantwortlichkeiten (meist Compliance-Officer oder Rechtsabteilung in Zusammenarbeit mit IT).

Risiken ohne & KPIs: Ohne solche Regeln können entweder Daten zu lange gespeichert werden (Datenschutzrisiko) oder versehentlich zu früh gelöscht werden (Compliance-Verstoß, Verlust von Beweismitteln). Ein KPI ist z.B. Quote fristgerecht gelöschter Inhalte: zeigt, dass Aufbewahrungsfristen eingehalten werden. Beispiel: In einem Unternehmen wurde vor Governance jede Teams-Unterhaltung ewig aufbewahrt. Nach Einführung von Retention Policies werden Routine-Chats nach 6 Monaten gelöscht – die Mitarbeiter wurden darüber informiert, vertrauliche Absprachen gehören in Protokolle. Gleichzeitig weiß die Rechtsabteilung: für ein laufendes Gerichtsverfahren wurden alle einschlägigen Teams mittels Litigation Hold eingefroren, sodass keine relevanten Daten verlorengehen.

5.7 App-, Bot- und Connector-Governance: Zulassungslisten, Review-Prozess, Risiko-Klassifizierung, Telemetrie

Ziel: Teams bietet eine Vielzahl an Apps, Bots und Schnittstellen (Connectors) – von Microsoft-Apps wie Planner bis hin zu Drittanbieter-Tools. Governance steuert, welche dieser Erweiterungen im Unternehmen eingesetzt werden dürfen, um Sicherheits- und Compliance-Risiken zu minimieren.

Risiken ohne Kontrolle: Ohne Vorgaben könnten Benutzer beliebige Apps hinzufügen. Dies birgt Gefahren: Ein unbekannter Drittanbieter-Connector könnte z.B. Chat-Inhalte auslesen oder Daten an externe Server senden. Oder es werden redundante Tools genutzt, die Lizenzkosten verursachen und Daten verteilen (z.B. mehrere Umfrage-Apps im Einsatz, obwohl eine zentrale genehmigt wäre). Zudem steigt der Support-Aufwand, wenn plötzlich viele verschiedene Bots genutzt werden, die IT nicht kennt.

Richtlinien & Freigabeprozess: Die Governance definiert eine Zulassungsliste (Allow-List) von geprüften Apps/Bots. Standardmäßig sind alle anderen geblockt (Teams bietet in den Admin-Richtlinien die Möglichkeit, Drittanbieter-Apps generell zu verbieten oder nur ausgewählte zu erlauben). Für neue Apps gibt es einen Freigabeprozess: Möchte ein Fachbereich eine nicht gelistete App einsetzen, stellt er einen Antrag (mit Begründung und Nutzen). Ein Gremium (z.B. IT-Architekt und Security Officer) prüft die App auf Risiken – etwa Datenzugriffsrechte, DSGVO-Konformität, Herstellervertrauen – und entscheidet über Zulassung. Die Entscheidung wird dokumentiert. Ähnlich verfahren sollte man mit selbst entwickelten Power Apps oder Bots: auch diese durchlaufen eine Compliance-Prüfung bevor allgemeiner Einsatz.

Risikoklassifizierung: Es kann sinnvoll sein, Apps in Risikoklassen einzuteilen (z.B. intern entwickelt, vertrauenswürdiger Partner, unbekannter Herausgeber). Je nach Klasse gelten unterschiedliche Anforderungen (z.B. für „hohes Risiko“-Apps zusätzliche Freigabe durch Datenschutzbeauftragten). So fließt die Risikoabwägung systematisch in die Governance ein.

Monitoring & Telemetrie: Die IT sollte zudem überwachen, welche Apps in welchen Teams genutzt werden. Das Teams-Admin Center liefert Berichte, welche Apps populär sind. Darüber hinaus kann man über Graph API regelmäßige Scans fahren, um z.B. neu hinzugefügte Apps aufzuspüren. Eine periodische Review der App-Nutzung (z.B. alle 6 Monate) stellt sicher, dass keine genehmigte App in der Zwischenzeit unsicher geworden ist oder kaum noch gebraucht wird – dann könnte man sie wieder entfernen.

Beispiel & KPIs: Ein KPI kann sein Anteil genehmigter Apps an allen installierten Apps (Ziel: 100% langfristig). Beispiel: In einem Unternehmen fand man 20 verschiedene ungeprüfte Apps in Nutzung, darunter eine Notiz-App mit fragwürdigen Berechtigungen. Nach Einführung der App-Governance wurde der Einsatz auf 5 geprüfte Apps reduziert. Mitarbeiter beantragen seitdem neue Apps formal, sodass keine unbekannte Software mehr unbemerkt Daten aus Teams abziehen kann.

5.8 Meeting-, Chat- & Aufzeichnungsrichtlinien: Lobby, Gastrechte, Transkription, Untertitel, E2EE, Export/Aufbewahrung

Ziel: Die Echtzeitkommunikation in Teams (Besprechungen, Anrufe, Chats) soll sicher und regelkonform ablaufen. Governance gibt vor, welche Einstellungen für Meetings gelten (z.B. Wer darf aufzeichnen? Wie werden Gäste behandelt?), und wie Chatfunktionen genutzt werden dürfen.

Meeting-Richtlinien: Ein wichtiger Aspekt ist die Lobby-Einstellung: Standard sollte sein, dass externe Teilnehmer zunächst in der Lobby warten, bis ein Organisator sie zulässt – so verhindert man, dass Unbefugte direkt einer Besprechung beitreten. Weiter regelt die Governance die Teilnehmerrechte: Dürfen Gäste ihren Bildschirm teilen? Dürfen alle Teilnehmer spontan andere einladen? Hier empfiehlt es sich, für externe Meetings restriktivere Vorgaben zu machen (z.B. nur Organisatoren dürfen einladen). Die Aufzeichnung von Meetings ist oft kritisch: In manchen Branchen müssen Meetings aus Compliance-Gründen aufgezeichnet werden (z.B. Börsengespräche), in anderen sind Aufnahmen aus Datenschutzgründen sehr eingeschränkt. Die Richtlinie sollte klar definieren, wann Aufzeichnungen erlaubt sind und welche Zustimmung erforderlich ist. Microsoft Teams kann per Richtlinie steuern, ob Benutzer überhaupt Aufzeichnen dürfen oder ob nur bestimmte Rollen (z.B. Organisator oder Referenten) Aufzeichnungen starten können. Zudem kann festgelegt werden, dass Teilnehmer beim Betreten eines aufgezeichneten Meetings automatisch benachrichtigt werden (dies ist in Teams ohnehin Standard, aber die Policy stellt sicher, dass es nicht deaktiviert wird).

Transkription und Untertitel: Teams bietet Live-Untertitel und die Möglichkeit, automatisch ein Transkript des gesprochenen Wortes zu erzeugen. Governance muss entscheiden, ob dies aktiviert sein soll – Transkripte können helfen (Durchsuchbarkeit, Barrierefreiheit), bedeuten aber auch zusätzliche gespeicherte Daten. Für mehrsprachige Meetings sind Live-Übersetzungsuntertitel nützlich, aber vielleicht nicht in allen Fällen gewünscht. Die Richtlinie könnte lauten: „Transkription ist standardmäßig aus und wird nur auf Anforderung für wichtige Meetings aktiviert.“

E2EE (Ende-zu-Ende-Verschlüsselung): Teams unterstützt E2EE für Einzelanrufe, was maximale Vertraulichkeit bietet (nicht mal Microsoft kann mithören), aber viele Funktionen (Aufzeichnung, Transkription, Teilnehmer hinzuholen) sind dann deaktiviert. Governance sollte festlegen, ob und wann E2EE genutzt werden darf. Beispielsweise könnten Vorstandsgespräche E2EE nutzen dürfen, alle anderen Calls jedoch nicht, damit Compliance-Features (wie Aufzeichnung oder Qualitätsüberwachung) nicht generell unterlaufen werden.

Chat- und Export-Richtlinien: Für Chats (sowohl in Meetings als auch 1:1) kann vorgegeben werden, ob Nutzer ihre Nachrichten löschen/editieren dürfen. In stark regulierten Umgebungen deaktiviert man das Löschen, damit Chats lückenlos archivierbar sind. Auch die Frage der Exportierbarkeit von Chat-Verläufen und Dateien spielt hinein: Dürfen Benutzer z.B. Meeting-Chats als HTML exportieren oder ist das untersagt? Die Microsoft 365 DLP-Regeln sollten so eingestellt sein, dass vertrauliche Informationen nicht einfach per Copy-Paste aus dem Chat entnommen und extern verschickt werden können.

Aufbewahrung von Aufzeichnungen: Meeting-Aufzeichnungen werden in OneDrive/SharePoint gespeichert und unterliegen daher den dortigen Aufbewahrungsrichtlinien. Governance stellt sicher, dass Aufzeichnungen nach angemessener Zeit automatisch gelöscht werden (z.B. nach 180 Tagen), sofern sie nicht als offizielles Protokoll klassifiziert sind. Teams bietet eine Einstellung, mit der Aufzeichnungen standardmäßig nach X Tagen gelöscht werden – das kann im Sinne von Datenhygiene genutzt werden.

Praxisbeispiel: In einem Unternehmen ist geregelt, dass nur der Meeting-Organisator Aufzeichnungen starten darf und externe Gäste gar nicht aufzeichnen können. Ein Projektleiter startet bei einem Kunden-Meeting bewusst keine Aufzeichnung, da vertrauliche Kundendaten besprochen werden – stattdessen wird ein schriftliches Protokoll angefertigt. Für ein internes Training hingegen wird die Aufnahmefunktion genutzt und das Video 30 Tage bereitgestellt. Durch diese klaren Regeln wissen alle Beteiligten, wann welche Kommunikationsfunktionen genutzt werden dürfen.

5.9 Schutz sensibler Informationen: DLP-Regeln, Insider-Risk-Kontrollen, Sensitivitätslabels in Teams/SharePoint/Office

Ziel: Vertrauliche und schützenswerte Daten sollen auch in der agilen Teams-Kommunikation nicht unkontrolliert abfließen oder missbraucht werden. Governance integriert daher Informationsschutzmaßnahmen direkt in Teams: Data Loss Prevention (DLP) zum Erkennen und Blockieren kritischer Inhalte, Insider Risk Management zur Erkennung ungewöhnlicher Aktivitäten, und Sensitivitätslabels zur durchgängigen Klassifizierung und Verschlüsselung sensibler Dokumente.

Data Loss Prevention (DLP): DLP-Regeln durchsuchen Chats und geteilte Dateien nach definierten Mustern – etwa Personalausweisnummern, Kreditkartendaten oder als intern eingestufte Dokumente. Wird z.B. versucht, eine Datei mit personenbezogenen Daten in einen öffentlichen Team-Channel hochzuladen oder an einen Gast zu schicken, kann die DLP-Policy automatisch alarmieren oder die Aktion unterbinden. Die Governance sollte festlegen, welche Arten von Informationen besonders geschützt werden müssen (z.B. „vertraulich intern“, „geheim“ etc.) und entsprechende DLP-Policies in Microsoft 365 Purview konfigurieren. Wichtig ist auch ein Prozess: Wenn eine DLP-Regel auslöst, wer wird benachrichtigt? (z.B. Datenschutzbeauftragter oder SecOps-Team) und was ist zu tun (Incident-Handling).

Sensitivitätslabels: Dokumente und E-Mails lassen sich mit Vertraulichkeitsbezeichnungen versehen, die z.B. Verschlüsselung erzwingen oder Warnbanner einblenden. In Teams-Kontext heißt das: Dateien, die in Team-Sites liegen, können vom Benutzer oder automatisch (per Auto-Labeling) klassifiziert werden. Ein Dokument mit Label „Vertraulich“ ist dann nur von autorisierten Personen zu öffnen – selbst wenn es das Team versehentlich verlässt, bleibt es verschlüsselt. Governance sorgt dafür, dass passende Labels definiert sind (z.B. Öffentlich, Intern, Vertraulich, Geheim) und die Mitarbeiter geschult werden, diese konsequent anzuwenden. Auch die Team-Container selbst können Labels haben, die z.B. steuern, ob Gäste erlaubt sind (siehe Szenario 5.2).

Insider Risk Management: Überwachungsfunktionen können ungewöhnliches Nutzerverhalten erkennen – etwa massenhafte Downloads von Team-Dateien oder das Löschen großer Datenmengen kurz vor einem Mitarbeiter-Austritt. Solche Muster können auf Datenabzug hindeuten. Microsoft Purview bietet ein Insider-Risk-Modul, das anhand vordefinierter Policies solche Events meldet. Die Governance sollte definieren, ob und wann dieses Instrument eingesetzt wird (z.B. für hochsensible Bereiche wie Forschung & Entwicklung) und wie mit den Alerts verfahren wird (Wahrung der Mitarbeiterrechte, aber dennoch eingreifen bei echten Vorfällen).

Beispiel: In einem Unternehmen versuchte ein Mitarbeiter, Kundendaten (inklusive Kreditkartennummern) via Teams an seinen privaten E-Mail-Account zu schicken – die DLP-Regel erkannte das Muster und blockierte die Nachricht, das Security-Team wurde alarmiert. Ein anderes Beispiel: Ein Entwickler lädt kurz vor Kündigung noch schnell alle Dateien des „Projekt Titan“-Teams herunter. Die Insider-Risk-Lösung schlägt Alarm, sodass das Unternehmen eingreifen kann. KPIs in diesem Bereich könnten sein: Anzahl verhinderter DLP-Vorfälle pro Quartal oder Prozentsatz der Dateien mit Sensitivitätslabel. Sie zeigen, wie effektiv die Schutzmechanismen greifen und ob Nachschulungen nötig sind.

5.10 Betrieb, Monitoring & Rezertifizierung: KPIs, Dashboards, Audit-Trails, Lizenzsteuerung, Ausnahme- und Notfallprozesse

Ziel: Auch nach Implementierung der Richtlinien muss die Teams-Umgebung kontinuierlich überwacht und gesteuert werden. Dieses Szenario bündelt die operativen Aspekte der Governance: fortlaufendes Monitoring mittels Kennzahlen und Berichten, Nutzung von Audit-Trails zur Nachvollziehbarkeit, optimierte Lizenznutzung sowie das Handling von Ausnahmefällen und Notfällen.

Monitoring & KPIs: Ein Governance-Dashboard fasst die wichtigsten Kennzahlen zusammen: z.B. Anzahl der aktiven Teams, davon wie viele ohne Besitzer, wie viele mit externen Gästen, Anteile richtlinienkonformer Teams (alle Pflichtfelder ausgefüllt, Labels gesetzt), offene Rezertifizierungsfälle, u.v.m. Diese KPIs werden idealerweise monatlich ausgewertet und Trends beobachtet. So sieht man früh, wenn etwa die Zahl inaktiver Teams steigt (Signal für Aufräumbedarf) oder ungewöhnlich viele Gastnutzer hinzugekommen sind (Überprüfung der Zugriffsregeln nötig).

Audit-Trails: Microsoft 365 protokolliert viele Aktivitäten (Team erstellt, Gast hinzugefügt, Datei zugriffen etc.) im Unified Audit Log. Die Governance stellt sicher, dass diese Protokollierung aktiviert ist und definiert Verantwortliche, die stichprobenartig oder anlassbezogen die Logs prüfen. Beispielsweise könnte festgelegt sein, dass quartalsweise ein Audit-Report ans Informationssicherheits-Team geht mit allen Teams-Änderungen der letzten 3 Monate. Bei Abweichungen (z.B. Team ohne Sensitivitätslabel angelegt) wird nachgesteuert.

Lizenzsteuerung: Gerade in größeren Organisationen ist im Blick zu behalten, wie Teams und zugehörige Services Lizenzen nutzen. Gastnutzer sind zwar kostenlos, aber Funktionen wie Advanced DLP oder eDiscovery erfordern teurere Lizenzen für beteiligte User. Governance Monitoring umfasst daher auch Lizenzmetriken: Sind genug Lizenzen der richtigen Kategorie verfügbar? Werden ungenutzte Lizenzen (z.B. für gelöschte Nutzer oder deaktivierte Teams-Funktionen) zeitnah frei? Auch die Ausnutzung von Speicherplatz in SharePoint (durch Teams-Dateien) sollte verfolgt werden, um rechtzeitig Kapazitäten zu planen oder Kosten für Zusatzspeicher zu vermeiden.

Ausnahme- und Notfallprozesses: Trotz aller Policies gibt es Sonderfälle. Governance definiert einen geregelten Ausnahmeprozess: Wenn eine Vorgabe aus geschäftskritischen Gründen temporär verletzt werden muss (z.B. ein Team soll doch einen dritten externen Gast aufnehmen, obwohl Limit 2), können Verantwortliche eine Ausnahme beantragen. Dieser Antrag wird dokumentiert und befristet genehmigt, inklusive Plan zur Rückführung in den Normalzustand. Ebenso wichtig: Notfallverfahren. Beispielsweise, wenn eine Sicherheitslücke bekannt wird und alle Teams-Inhalte kurzfristig durchsucht oder bestimmte Funktionen abgeschaltet werden müssen – wer entscheidet das und wer führt es aus? Oder wenn alle Team-Eigentümer ausfallen (etwa durch einen Vorfall), muss klar sein, dass die IT-Administratoren als Global Admins eingreifen dürfen, um Zugriff zu erhalten (Stichwort „Break-Glass-Account“ für den Notfallzugriff, der in keiner MFA-Sperre hängt). Solche Szenarien sollten in der Governance-Dokumentation durchgespielt und hinterlegt sein.

Beispiel: Der Governance-Koordinator erstellt jeden Monat ein Reporting: z.B. „10 neue Teams angelegt, 2 Teams wegen Inaktivität archiviert, 3 ausstehende Rezertifizierungen, keine Policy-Ausnahmen beantragt“. Dieses Reporting geht an den IT-Leiter und wird im quartalsweisen Governance-Board-Meeting diskutiert. Dadurch bleibt die Kontrolle über die Teams-Landschaft erhalten und man kann proaktiv nachjustieren.

6. Produktbezug: CosyTrack.Provisioner in der Praxis

Überblick: CosyTrack.Provisioner ist ein spezialisiertes Tool, um Microsoft-Teams-Arbeitsräume standardisiert bereitzustellen und die oben beschriebenen Governance-Prinzipien technisch umzusetzen. Es handelt sich um eine Self-Service-Lösung, die Nutzern auf Knopfdruck Teams nach vordefinierten Regeln anlegen lässt – ohne manuelle IT-Eingriffe. In der Architektur fungiert der Provisioner als orchestrierende Schicht zwischen den Anwendern und Microsoft 365: Er bietet ein Web-Frontend (Cockpit) für Anträge und Vorlagen-Auswahl, verarbeitet Genehmigungen und nutzt dann die Microsoft Graph API, um Teams, Sites und Gruppen gemäß den Vorgaben anzulegen. Rollen und Berechtigungen: Typischerweise darf jeder Mitarbeiter einen Team-Antrag im Provisioner stellen, während definierte Genehmiger (z.B. Abteilungsleiter) im Tool hinterlegt sind. Administratoren konfigurieren die Vorlagen und Richtlinien im Provisioner, benötigen aber im Alltag kaum einzugreifen, da die Prozesse automatisiert ablaufen.

Funktionen für die Governance-Umsetzung: CosyTrack.Provisioner deckt mit zahlreichen Features die zuvor beschriebenen Anforderungen ab: – Standardisierte Team-Vorlagen: Mehrere vordefinierte Vorlagen für unterschiedliche Team-Typen (Projekt, Vertrieb, externe Kollaboration). Jede Vorlage enthält festgelegte Kanalstrukturen, Apps und Einstellungen. Beim Antrag wählt der Nutzer die passende Vorlage – der Provisioner erstellt das Team genau nach diesem Muster, sodass nichts Wichtiges fehlt. – Geführter Antrags- und Genehmigungsworkflow: Der Prozess zur Team-Erstellung ist mehrstufig und nachvollziehbar. Antragsteller geben alle erforderlichen Informationen im Tool ein. Dann wird automatisch der zuständige Genehmiger benachrichtigt (mehrstufig möglich, z.B. erst Fachvorgesetzter, dann IT). Jede Freigabe wird protokolliert. Bei Bedarf können Genehmiger die Aufgabe delegieren (etwa wenn sie im Urlaub sind). – Automatische Durchsetzung von Namensregeln, Labels und Besitzern: Der Provisioner generiert den Team-Namen gemäß Richtlinie (z.B. fügt Präfixe hinzu) und weist dem Team direkt ein Sensitivitätslabel zu, basierend auf der Auswahl (z.B. „Extern“ vs. „Intern“ Team). Auch erzwingt das Tool, dass pro Team mindestens zwei Besitzer eingetragen werden – falls nur einer angegeben ist, erinnert es daran, noch einen Co-Owner zu benennen. – Vorkonfiguration von Kanälen, Registerkarten und Apps: Teams werden nicht leer erstellt, sondern mit einer Startkonfiguration. Beispielsweise fügt CosyTrack.Provisioner bei einem „Projekt“-Team automatisch Kanäle wie Planung, Dokumentation und Allgemein hinzu, richtet eine Planner-App oder Aufgabenliste ein und bindet die relevante SharePoint-Bibliothek als Registerkarte ein. So ist das Team ab der ersten Minute arbeitsfähig und konsistent strukturiert. – Lebenszyklus-Automatisierung: Das Tool überwacht die Aktivität der bereitgestellten Teams. Es kann z.B. Inaktivität erkennen (wenn über X Monate keine Posts/Dateien erstellt wurden) und dann automatisch den Team-Besitzer zur Prüfung auffordern. Rezertifizierungen werden vom Provisioner initiiert: Team-Besitzer erhalten nach z.B. 180 Tagen eine Aufgabenliste, ihr Team im Tool zu bestätigen oder zur Archivierung vorzuschlagen. Auch die Archivierung oder Löschung kann das Tool nach Freigabe automatisch anstoßen. – Governance-Kontrollen bei Gästen & Risiken: Basierend auf der im Antrag angegebenen Risikoklasse oder Sensitivität kann der Provisioner bestimmte Controls erzwingen. Beispiel: Wenn externe Zusammenarbeit = Ja, dann zwingend ein Enddatum für den Gastzugriff verlangen und den Genehmiger auf das erhöhte Risiko hinweisen. Oder: Teams mit Label „Vertraulich“ werden so erstellt, dass Guest Access in Teams automatisch deaktiviert ist. Auch muss der Antragsteller in solchen Fällen eine Begründung angeben, die mitprotokolliert wird. – Protokollierung und Nachweisführung: Jede Aktion im Provisioner wird geloggt – von Antragsstellung über Genehmigungen bis hin zu Änderungen am Team (z.B. Besitzerwechsel). Diese Logs sind revisionssicher und können für Audits exportiert werden. Damit lässt sich jederzeit nachweisen, wer wann ein Team beantragt hat, wer freigab und welche Einstellungen angewendet wurden. – Integration in ITSM/CMDB und Benachrichtigungen: CosyTrack.Provisioner lässt sich an vorhandene Prozesse anbinden. Beispielsweise kann ein Antrag mit einer Ticketnummer oder Kostenstelle verknüpft werden, sodass im Configuration Management Database (CMDB) jeder Team-Arbeitsraum als Konfigurationseinheit erscheint. Zudem verschickt das Tool automatische Benachrichtigungen – etwa E-Mails an den Helpdesk bei bestimmten Ereignissen (z.B. Ausnahmegenehmigung erteilt) oder an den Datenverantwortlichen, wenn ein Team vor der Löschung steht. Eskalationen sind ebenso konfigurierbar, falls Genehmigungen zu lange ausbleiben.

Nutzenbilanz: Durch diese Funktionen erzielt der Provisioner vor allem eine schnellere und konsistentere Bereitstellung von Teams. Fachabteilungen können neue Arbeitsräume innerhalb von Minuten nutzen, was die Produktivität fördert, während die IT entlastet wird. Gleichzeitig sind alle erforderlichen Governance-Vorgaben von Anfang an erfüllt – es muss nachträglich weniger korrigiert oder auditiert werden. Für Compliance-Verantwortliche ist besonders wertvoll, dass vollständige Nachweise über die Entstehung und Veränderungen jedes Teams vorliegen. Insgesamt sinkt das Risiko menschlicher Fehler deutlich, und der Betrieb skaliert besser, da Wachstum der Teams-Landschaft kaum zusätzlichen Aufwand erzeugt.

Vergleich: Nativ (manuell/halbautomatisch) vs. CosyTrack.Provisioner
Nachfolgend ein Vergleich einiger wichtiger Kriterien zwischen einer herkömmlichen Bereitstellung (durch Benutzer und Admins manuell oder mit einfachen Skripten) und der Nutzung von CosyTrack.Provisioner:

Kriterium	Nativ (manuell/halbautomatisch)	Mit CosyTrack.Provisioner
Geschwindigkeit	Tage bis Woche (Antrag per E-Mail, manuelle Anlage)	Minuten bis Stunde (Self-Service, auto. Genehmigung)
Konsistenz	Uneinheitliche Teams-Struktur je nach Ersteller	Einheitliche Struktur gemäß Vorlage
Nachweisbarkeit	Genehmigungen oft formlos (E-Mails), schlecht nachvollziehbar	Lückenloses Protokoll aller Schritte
Betriebsaufwand	Hohe manuelle Tätigkeit für IT und Nacharbeiten	Minimaler Aufwand, Prozess läuft automatisch
Fehlerquote	Fehler möglich (vergessene Einstellungen, falsche Berechtigungen)	Fehler nahezu eliminiert (Tool erzwingt Regeln)
Governance-Abdeckung	Viele Richtlinien nur schwer manuell umsetzbar	Volle Abdeckung: Tool implementiert Vorgaben praktisch

Mini-Fallstudien: Zum Abschluss drei kurze Beispiele aus der Praxis, wie der Provisioner Governance unterstützt: – Projektteam mit externen Partnern: Eine Marketingabteilung will gemeinsam mit einer externen Agentur ein Kampagnen-Team nutzen. Über den Provisioner wählt der Mitarbeiter die Vorlage „Projekt mit Externen“ und gibt Laufzeit und Agentur-Domain an. Nach Freigabe erstellt das Tool ein Team mit vordefinierten Kanälen für Planung, Kreativ-Brainstorming und Abstimmung. Die Gastzugriffe sind automatisch so konfiguriert, dass Agentur-Mitglieder nur bis Kampagnenende Zugang haben. Der gesamte Prozess dauerte vom Antrag bis zur Einsatzbereitschaft weniger als 2 Stunden. Ohne Provisioner hätte es Abstimmungen mit IT und händische Konfiguration gebraucht, mit Risiko, wichtige Sicherheitsdetails zu übersehen. – Internes Bereichsteam: Die HR-Abteilung benötigt ein Team für ihr internes Wissensmanagement. Mit dem Provisioner wird das Team „HR-Wissensbasis“ über die Vorlage „Abteilungsteam“ erstellt. Es enthält sofort einen Kanal Vertrauliches-HR (als privaten Kanal nur für die Personalleiter) und Standardkanäle für Richtlinien und Austausch. Sensitivitätslabel „Intern“ wird automatisch gesetzt. Die HR-Leiterin als Antragstellerin trägt gleich zwei Stellvertreter als Co-Owner ein, wie es das Tool verlangt. So entsteht in Minuten ein datenschutzgerechter Raum, den die Belegschaft sofort nutzen kann. – Temporäres Krisenteam: Für eine unerwartete Incident Response (z.B. Cybersecurity-Vorfall) muss sehr schnell ein Team aufgesetzt werden, das nach der Krise auch wieder geschlossen wird. Der Provisioner hat eine spezielle Vorlage „Krisen-Team“ mit hoher Priorität (auto-sofortige Genehmigung durch IT-Notfalluser). Innerhalb von 10 Minuten steht das Team bereit, inkl. Kanälen Lage, Maßnahmen, Entscheidungen. Nach Ablauf von 30 Tagen Inaktivität wird dieses Team vom Provisioner zur Archivierung vorgeschlagen, sodass keine sensiblen Incident-Daten unnötig lange online bleiben. Dadurch konnte in der akuten Phase wertvolle Zeit gespart werden, und dennoch wird die ordnungsgemäße Nachbearbeitung (Schließung/Aufbewahrung) nicht vergessen.

7. Umsetzungsvorgehen (Roadmap)

Die Einführung einer Teams-Governance erfolgt idealerweise schrittweise in klar definierten Phasen. So kann man früh Erfahrungen sammeln und Anpassungen vornehmen, bevor das Modell flächendeckend gilt.

1. Phase 1 (0–30 Tage): In der Startphase steht die Ist-Analyse und Konzeption im Vordergrund. Zunächst wird die aktuelle Teams-Landschaft erhoben: Wie viele Teams gibt es, wo liegen offensichtliche Probleme (z.B. sehr viele Gäste, inaktive Teams, Wildwuchs)? Parallel werden die Governance-Richtlinienentwürfe erarbeitet – unter Einbezug aller Stakeholder (IT, Informationssicherheit, Datenschutz, Fachbereiche). Man definiert Namenskonventionen, Rollen, grobe Prozesse. Auch werden Referenz-Vorlagen für Teams skizziert (z.B. welche Teamtypen brauchen wir?). Bereits in Phase 1 empfiehlt sich ein Pilotprojekt: Eine kleine Anzahl neuer Teams wird nach den entstehenden Regeln angelegt, ggf. manuell oder mit einem Testeinsatz von CosyTrack.Provisioner. Ziel ist, Feedback aus der Praxis zu sammeln und die Akzeptanz bei Nutzern und Entscheidern zu sichern.
2. Phase 2 (31–90 Tage): In dieser Phase erfolgt die Initiale Umsetzung der Governance. Die erarbeiteten Richtlinien werden offiziell verabschiedet und in die Praxis überführt: z.B. Rollout der technischen Policies (Einrichten der Azure AD Namenskonvention, DLP-Regeln aktivieren, Teams-Admin-Einstellungen anpassen). Zudem startet man ein Schulungsprogramm: Team-Eigentümer und Administratoren werden mit ihren neuen Pflichten vertraut gemacht (etwa wie Rezertifizierung läuft, oder dass nun Anträge über das Tool zu stellen sind). CosyTrack.Provisioner wird in einer erweiterten Pilotierung eingesetzt – z.B. eine ausgewählte Abteilung nutzt ihn für alle neuen Teams, sodass man die Workflows unter Realbedingungen testet. Gleichzeitig werden KPI-Dashboards aufgebaut: Man definiert die Metriken (siehe Abschnitt 8) und richtet erste Berichte ein, um den Erfolg zu messen. Wichtig in Phase 2 ist auch, bereits bestehende Teams einzubinden: Evtl. startet man eine erste Rezertifizierungsrunde für ältere Teams, um das Prinzip zu etablieren (z.B. Eigentümer anschreiben und Aktualität der Teams prüfen lassen).
3. Phase 3 (ab 90 Tage): Nun erfolgt der Rollout in die Breite. Nach den Pilot-Erfolgen werden die Governance-Prozesse für alle neuen Teams verbindlich gemacht. CosyTrack.Provisioner (oder das gewählte Verfahren) wird für das gesamte Unternehmen ausgerollt. Begleitend richtet man dauerhafte Support- und Optimierungsprozesse ein: z.B. ein Governance Board, das sich quartalsweise trifft, um Kennzahlen zu prüfen und Anpassungen an Richtlinien vorzunehmen. Ausnahmemanagement tritt nun in den Echtbetrieb – es wird kommuniziert, wie Sonderfälle zu beantragen sind. Gleichzeitig beginnt die Vorbereitung auf Audits: Alle Richtlinien und Nachweise werden sauber dokumentiert, erste interne Audits oder Kontrollen werden durchgeführt, um Lücken aufzudecken. Langfristig etabliert sich ein Zyklus, in dem die Governance jährlich grundlegend überprüft und bei Bedarf nachgeschärft wird, damit sie mit Wachstums- oder Technologietrends Schritt hält.

90-Tage-Checkliste: Nachfolgend eine kompakte Liste von Aufgaben, die innerhalb der ersten 3 Monate (90 Tage) anzugehen sind:

• [ ] Stakeholder-Kickoff durchführen: Team aus IT, Compliance, Datenschutz, Fachbereichen zusammenstellen und Ziele abstimmen.
• [ ] Bestandsaufnahme erstellen: Alle bestehenden Teams erfassen (Anzahl, Besitzer, Gäste, Aktivität) und Hauptproblempunkte dokumentieren.
• [ ] Governance-Richtlinien entwerfen: Namenskonvention, Klassifizierungen, Team-Lebenszyklus, Rollenmodell (RACI), Gastregeln als Entwurf ausarbeiten.
• [ ] Schnelle Sofortmaßnahmen umsetzen: Evtl. temporär Selbst-Erstellung von Teams einschränken, offensichtlich veraltete Teams einfrieren, kritische Gastzugänge überprüfen.
• [ ] Teams-Vorlagen definieren: 2–3 wichtigste Team-Typen skizzieren (z.B. Projekt, Abteilung, externes Projekt) inkl. benötigter Kanäle/Apps.
• [ ] Pilot-Abteilung wählen: Bereich finden, der neue Teams-Governance testweise anwenden will; Pilotumfang und Erfolgskriterien festlegen.
• [ ] CosyTrack.Provisioner Pilot aufsetzen: Testinstanz installieren/konfigurieren, Pilotnutzer schulen, ersten Team-Antrag darüber abwickeln.
• [ ] Policies technisch konfigurieren: Azure AD Namensrichtlinie, Teams-Admin-Einstellungen (Gastzugriff, Apps), Basis-DLP und Retention-Policies im Compliance Center aktivieren.
• [ ] Kommunikation & Training starten: Governance-Grundsätze an Mitarbeiter kommunizieren (z.B. Intranet-Ankündigung), Schlüsselrollen (Team-Eigentümer) in Workshops schulen.
• [ ] KPI-Dashboard initialisieren: Ersten Satz Kennzahlen definieren und mit verfügbaren Daten füllen (z.B. aktuelle Anzahl Teams, Gäste, inaktive Teams) als Ausgangsbasis.
• [ ] Review nach 60–90 Tagen: Zwischenergebnisse des Piloten und der ersten Maßnahmen auswerten, Verbesserungen für den großen Rollout beschließen.

8. Erfolgsmessung & KPI-Set

Um die Wirksamkeit der Teams-Governance nachzuhalten, werden Key Performance Indicators (KPIs) definiert. Diese Kennzahlen ermöglichen es, Fortschritte und etwaige Lücken objektiv zu bewerten. Wichtige KPIs können sein:

• Anteil richtlinienkonformer Teams: Prozent der Teams, die alle Governance-Vorgaben erfüllen (korrekter Name, Sensitivitätslabel gesetzt, ≥2 Owner, regelmäßige Reviews etc.). Zielwert nahe 100%. Ein Absinken würde anzeigen, dass Regeln umgangen oder nicht durchgesetzt werden – ab einer Schwelle (z.B. <90%) sollte nachjustiert oder interveniert werden.
• Durchschnittliche Bereitstellungszeit pro Team: Gemessen vom Antrag bis zur erfolgreichen Erstellung. Dieser Wert (idealerweise in Stunden oder wenigen Tagen) zeigt die Effizienz des Prozesses. Wenn er steigt (z.B. über 2 Tage), liegt evtl. ein Engpass im Genehmigungsworkflow vor. Eskalation: Ab bestimmten Verzögerungen (z.B. >3 Tage) sollte der Helpdesk nachhaken.
• Inaktivitätsquote: Anteil der Teams, die seit >X Monaten keine Aktivität zeigen. Ein hoher Wert (viele „tote“ Teams) deutet auf Aufräumbedarf hin. Dieser KPI hilft zu entscheiden, wann nächste Archivierungswellen nötig sind. Z.B. bei >10% inaktiven Teams könnte man gezielt eine Bereinigungskampagne starten.
• Offene Rezertifizierungen: Anzahl der Teams, bei denen eine periodische Überprüfung überfällig ist (Team-Eigentümer haben nicht fristgerecht reagiert). Diese Zahl sollte möglichst Null sein. Steigt sie, greifen Eskalationen – etwa Erinnerungen an die säumigen Owner oder Info an deren Vorgesetzte bei >5 offenen Fällen.
• Gastzugriffe mit Ablaufdatum: Hier wird gemessen, wie viele Gastkonten ein definiertes Enddatum haben bzw. wie viele Gastzugriffe unbefristet laufen. Ziel: möglichst alle externen Zugänge zeitbegrenzt. Wenn z.B. erst 70% der Gäste ein Enddatum haben, ist das ein KPI, um weitere Sensibilisierung zu betreiben. Auch die Anzahl durchgeführter Access Reviews pro Quartal für Gäste kann hier zählen.
• DLP-Treffer pro Sensitivitätsklasse: Anzahl der DLP-Verstöße (blockierte oder gemeldete Versuche) aufgeschlüsselt nach Team-Klassifizierung. Z.B. 5 Vorfälle in „Öffentlich“-Teams vs. 1 in „Vertraulich“. Viele Vorfälle in eigentlich offenen Umgebungen könnten Schulungsbedarf anzeigen. Bei Anstieg über einen Schwellenwert (z.B. >10 Vorfälle/Monat) sollte das Sicherheits-Team genauer hinschauen und ggf. Policies verschärfen.
• Ausnahmefälle vs. Gesamt: Verhältnis der genehmigten Policy-Ausnahmen zur Gesamtzahl der Teams. Wenn z.B. 5% aller Teams nur durch Ausnahme entstanden oder betrieben werden konnten, ist das noch vertretbar – bei 20% müsste man die generellen Richtlinien überdenken. Diese Kennzahl zeigt, ob die Governance realistisch und praktikabel ist, oder ob viele an ihr vorbei müssen.
• Trainingsquote der Team-Besitzer: Wie viele der aktuellen Team-Owner haben an einer Governance-Schulung teilgenommen oder die Richtlinien bestätigt? Ziel sollte ein hoher Wert (nahe 100%) sein, da geschulte Besitzer das Fundament für die Einhaltung bilden. Wenn dieser Wert niedrig ist, müssen weitere Trainingsrunden oder verpflichtende E-Learnings angesetzt werden.

Diese KPIs sollten in einem regelmäßigen Reporting zusammenfließen – etwa in Form eines quartalsweisen Governance-Reports ans Management. Ein Dashboard (z.B. in Power BI) kann live anzeigen, wie die Werte stehen: z.B. Ampelfarben für „zu viele offene Rezertifizierungen“ oder Diagramme über die Team-Wachstumsrate. Eskalationsschwellen sind für jede Kennzahl festzulegen: Überschreitet oder unterschreitet ein KPI einen bestimmten Wert, wird automatisch eine zuständige Stelle informiert (z.B. IT-Leiter bei mehr als 10 Ausnahmefällen im Monat, Informationssicherheit bei jedem DLP-Vorfall der höchsten Kategorie, etc.). So wird Governance nicht nur eingeführt, sondern auch im laufenden Betrieb gelenkt und optimiert.

9. Antipatterns & Lessons Learned

Bei der Einführung von Teams-Governance zeigen sich in der Praxis einige häufige Stolpersteine. Im Folgenden vier typische Antipatterns und wie man ihnen begegnet:

• Antipattern: Zu viele Templates. Enthusiasmus bei der Einführung führt manchmal dazu, dass Dutzende Team-Vorlagen definiert werden („für jede erdenkliche Nutzung eine eigene Vorlage“). Das überfordert Nutzer und macht die Pflege komplex. Pragmatische Leitplanke: Nur die wichtigsten, deutlich unterscheidbaren Vorlagen anbieten (z.B. 3–5 Stück). Feinheiten lieber über optionale Einstellungen innerhalb der Vorlagen regeln, statt neue Templates zu erstellen. So bleibt das System übersichtlich.
• Antipattern: Keine Rezertifizierung. Oft wird Governance einmalig beim Anlegen von Teams bedacht, aber bestehende Teams werden nie überprüft. Folge: Leichen sammeln sich an, Berechtigungen veralten. Pragmatische Leitplanke: Von Beginn an einen regelmäßigen Überprüfungsprozess einplanen (z.B. halbjährlich). Notfalls klein anfangen – etwa jährliche manuelle Owner-Abfrage per Excel – statt gar nichts zu tun. Wichtig ist, Verantwortliche an ihre Pflicht zu erinnern, Teamdaten aktuell zu halten.
• Antipattern: Unklare Rollenverteilung. Ohne klar kommunizierte Verantwortlichkeiten entstehen Lücken oder Doppelarbeit. Z.B. glauben Team-Besitzer, IT kümmere sich um die Datenklassifizierung, während IT annimmt, der Fachbereich macht es. Pragmatische Leitplanke: RACI-Matrix erstellen (wie oben) und publik machen. Jeder beteiligten Rolle muss bewusst sein, was von ihr erwartet wird. Im Zweifel einmal mehr abstimmen – z.B. regelmäßige Jour-fixe zwischen IT und Compliance – um sicherzustellen, dass nichts „zwischen den Stühlen“ bleibt.
• Antipattern: App-Wildwuchs. Wenn die Governance das Thema Apps/Add-Ons ignoriert, installieren Nutzer munter alles Mögliche in Teams. Später herauszufiltern, welche Apps kritisch sind, wird zur Mammutaufgabe. Pragmatische Leitplanke: Früh ein App-Governance-Prozess etablieren (Whitelist/Blacklist) und diesen den Nutzern kommunizieren. Lieber initial strenger (erstmal weniger Apps erlauben) und aufstocken, als umgekehrt. Zudem sollte regelmäßig ein Review der genutzten Apps erfolgen, um Altlasten zu entfernen.

Lessons Learned: Insgesamt zeigt Erfahrung, dass Governance ein Balanceakt ist – zu strikte Regeln können Umgehungen fördern (Schatten-IT), zu lasche Regeln verfehlen den Zweck. Daher sollte man Governance immer als lebendigen Prozess begreifen: Feedback der Anwender einholen, Regelwerk pragmatisch halten und kontinuierlich nachsteuern. Ein weiterer Lernpunkt ist die Bedeutung von Change-Management: Die beste Richtlinie nützt wenig, wenn Nutzer und Führungskräfte nicht an Bord sind. Kommunikation, Schulung und Quick-Wins helfen, Akzeptanz zu schaffen und die Vorteile der Governance erlebbar zu machen.

10. FAQ

1. Was versteht man unter Microsoft Teams-Governance?
Unter Microsoft Teams-Governance versteht man einen Rahmen aus Richtlinien, Prozessen und Verantwortlichkeiten, der die Nutzung von Teams im Unternehmen steuert. Es geht darum, klare Regeln festzulegen – etwa wie Teams benannt werden, wer sie erstellen darf, wie mit sensiblen Daten umzugehen ist – und sicherzustellen, dass diese Regeln eingehalten werden. Governance ist also die „Spielregeln und Aufsicht“ rund um Teams, um Wildwuchs zu vermeiden und Sicherheit sowie Compliance zu gewährleisten. Im Gegensatz zur reinen Administration (dem technischen Verwalten von Teams) umfasst Governance auch organisatorische Aspekte: Welche Abteilungen und Personen sind in Entscheidungen einzubinden? Wie wird die Lebensdauer eines Teams gehandhabt? Ziel ist, dass Teams effizient genutzt werden können, ohne dass Risiken für Datenschutz, Informationssicherheit oder Ordnung entstehen. Eine gute Teams-Governance bedeutet letztlich, dass Teams als Plattform verlässlich, überschaubar und regelkonform bleibt – trotz hunderter oder tausender Teams im Einsatz. Sie schafft Transparenz und stellt sicher, dass Teams den Unternehmensrichtlinien und gesetzlichen Vorgaben entsprechen.

2. Worin unterscheidet sich Governance von Administration und Betrieb?
Governance betrifft die strategischen Leitplanken und Regeln – also das Was und Warum. Sie definiert die Policies (z.B. Namenskonventionen, wer darf was) und stellt sicher, dass Prozesse und Kontrollen etabliert sind. Administration hingegen ist das operative Wie: die tägliche Verwaltung der Teams-Umgebung. Administratoren setzen die Governance-Vorgaben technisch um, erstellen z.B. ein Team, fügen Benutzer hinzu, konfigurieren Einstellungen, kümmern sich um Support und Wartung. Der Betrieb (Operations) umfasst alle laufenden Aktivitäten, um den Service stabil und verfügbar zu halten – Monitoring der Plattform, Troubleshooting, Updates. Während also Governance vorgibt „Neue Teams müssen genehmigt werden und sensibel gekennzeichnet sein“, sorgt die Administration dafür, dass ein solches Genehmigungsverfahren implementiert ist und tatsächlich durchlaufen wird, und der Betrieb stellt sicher, dass Teams als System performant läuft. Einfach gesagt: Governance ist die Regelsetzung, Administration die Regelumsetzung, Betrieb das Sicherstellen des technischen Funktionierens.

3. Welche Risiken entstehen ohne Governance – organisatorisch, rechtlich, technisch?
Ohne Governance droht ein unkontrolliertes Wachstum und diverse Risiken in mehreren Bereichen. Organisatorisch entsteht Chaos: Benutzer legen unkoordiniert Teams an, es kommt zu Doppelstrukturen und Wildwuchs. Informationen verteilen sich in zig Teams, was Zusammenarbeit ineffizient macht – niemand hat mehr den Überblick, wo welche Datei liegt oder welches das „richtige“ Team ist. Rechtlich und compliance-seitig wird es gefährlich: Ohne Regeln können vertrauliche oder personenbezogene Daten in Teams geteilt werden, ohne Schutz oder Freigabe. Beispielsweise könnten Mitarbeiter sensible Daten mit externen Personen teilen, ohne Genehmigung oder Audit-Trail, was gegen Datenschutzvorschriften (DSGVO etc.) verstößt. Auch Aufbewahrungsfristen werden evtl. ignoriert – Chats oder Dateien werden zu lange (oder zu kurz) aufgehoben, was im Prüffall sanktioniert werden kann. Technisch/Sicherheit: Fehlende Governance heißt oft, dass Sicherheitsfeatures ungenutzt bleiben (z.B. kein DLP aktiv, offene Gastzugänge). Dadurch steigt die Gefahr von Datenlecks erheblich. Ex-Mitarbeiter könnten weiter Zugriff auf Teams haben, weil niemand Berechtigungen nachhält. Zudem fehlt Monitoring: Angriffe oder Missbrauch in Teams würden gar nicht auffallen. Zusammengefasst: Ohne Governance drohen Wildwuchs, ineffiziente Zusammenarbeit, Datenabfluss, Rechtsverstöße und unsichtbare Sicherheitslücken – ein erhebliches Risiko für das Unternehmen.

4. Wer trägt Verantwortung: Wie sieht ein sinnvolles Rollen- und RACI-Modell aus?
Eine Teams-Governance verteilt die Verantwortung auf mehrere Schultern. Typischerweise gibt es folgende Hauptrollen: Team-Eigentümer (meist aus dem Fachbereich) sind verantwortlich für ihr jeweiliges Team – sie pflegen Mitglieder, setzen ggf. das passende Label und achten auf die Einhaltung der Regeln im Team. Dann Fachbereichsleitung oder Sponsor: Oft muss ein Vorgesetzter die Anlage eines neuen Teams genehmigen und steht als Verantwortlicher mit in der Pflicht (Accountable für das fachliche Bedürfnis des Teams). Die IT-Administratoren bzw. der Teams Service Owner sind verantwortlich für die Plattform und dafür, dass Richtlinien technisch umgesetzt werden (z.B. Einstellungen, Policies in Teams Admin Center). Sie sind außerdem Anlaufstelle für technische Probleme. Die Compliance- oder Datenschutzbeauftragten definieren Vorgaben (etwa zur Datensicherheit) und werden konsultiert, wenn es um sensible Inhalte geht oder Ausnahmen entschieden werden müssen. Ein RACI-Modell hilft, diese Rollen pro Prozessschritt festzulegen: z.B. beim Team-Erstellen ist der Anwender (zukünftiger Owner) “Responsible” (führt aus), der Vorgesetzte “Accountable” (gibt frei), IT/Tool “Informed” (führt technisch aus) und Compliance bei sensiblen Fällen “Consulted”. Ähnlich für Änderungen, Reviews, Schließungen (siehe Abschnitt 4 mit Tabelle). Wichtig ist, dass jede Aufgabe klar einem Verantwortlichen zugewiesen ist und diese Personen das auch wissen. Ein sinnvolles Modell vermeidet Überschneidungen (dass sich zwei kümmern wollen) ebenso wie Lücken (niemand fühlt sich zuständig).

5. Wie werden neue Teams beantragt, genehmigt und dokumentiert?
Idealerweise über einen standardisierten Prozess: Ein Mitarbeiter, der ein neues Team benötigt, füllt einen kurzen Antrag aus – darin stehen Zweck des Teams, vorgeschlagener Name, Sensitivität (z.B. ob Externe mitmachen sollen) und wer es besitzen soll. Dieser Antrag wird an eine definierte Stelle zur Genehmigung weitergeleitet, typischerweise den zuständigen Vorgesetzten oder Teamlead des Antragstellers. Die Genehmigung kann formlos per E-Mail erfolgen, besser aber via Tool oder Formular, damit sie dokumentiert ist. Sobald der Genehmiger “Okay” gibt, wird das Team erstellt – entweder manuell durch einen Administrator oder automatisiert durch ein Provisionierungstool. Dokumentation: Wichtig ist, dass alle relevanten Infos protokolliert werden: Wer hat wann beantragt? Wer hat freigegeben? Unter welchen Bedingungen (z.B. Team als “intern” klassifiziert, läuft bis Datum X)? In einfachen Umgebungen kann das eine Excel- oder SharePoint-Liste sein, in der jeder Team-Antrag erfasst wird. Professioneller ist die Unterstützung durch ein Tool (etwa CosyTrack.Provisioner), das diese Daten automatisch mitloggt. So hat man einen Audit-Trail. Der gesamte Ablauf – Antrag, Genehmigung, Erstellung – sollte klar kommuniziert sein, damit Nutzer wissen, wie sie ein Team bekommen und Entscheider wissen, was sie prüfen sollen. Ergebnis: Jedes Team entsteht nachvollziehbar mit Freigabe, statt wild per Knopfdruck.

6. Welche Namenskonventionen und Klassifizierungen sind sinnvoll und wie werden sie durchgesetzt?
Ein konsistentes Benennungschema sorgt für Ordnung. Sinnvoll ist z.B. ein Prefix/Suffix-System: Der Teamname beginnt mit einem Kürzel für die Abteilung oder Funktion (etwa “HR-” für Human Resources), optional gefolgt vom Projektnamen oder Zweck, und evtl. einem Hinweis auf Vertraulichkeit. Beispielsweise “HR-Recruiting (Intern)” versus “HR-Recruiting (Extern)”, um direkt zu sehen, ob Gäste drin sind. Auch Datumskomponenten können Sinn machen bei temporären Teams (z.B. “ProjektX-2025”). Wichtig ist, dass die Konvention einfach und für Nutzer verständlich ist. Durchgesetzt wird sie idealerweise technisch: Azure AD bietet Namensrichtlinien, mit denen man bestimmte Prefixe/Suffixe automatisch anfügt oder verbotene Wörter sperrt. Alternativ kann ein Provisionierungstool den Namen prüfen und nur akzeptieren, wenn er der Policy entspricht.
Klassifizierung meint, Teams in Kategorien einzuteilen, etwa nach Vertraulichkeit. Hier bieten sich Sensitivitätslabels an: z.B. ein Label “Öffentlich” für frei zugängliche Teams, “Intern” für nur interne Mitglieder, “Vertraulich” für Teams mit sensiblen Daten (keine externen Gäste). Diese Labels kann man beim Anlegen abfragen und sie werden dem Team zugewiesen. Dadurch wissen alle und auch die IT-Systeme, wie mit dem Team umzugehen ist (beispielsweise aktiviert das Label bestimmte Sicherheitsmaßnahmen). Durchgesetzt wird das, indem die Vergabe eines Labels verpflichtend gemacht wird – entweder via Richtlinie (Teams lässt Erstellung ohne Label nicht zu, sofern konfiguriert) oder organisatorisch (kein Team ohne Klassifizierung freigeben). Kombination aus beidem: Tools, die den Ersteller zwingen, eine Kategorie auszuwählen. Nachträglich sollte die Einhaltung stichprobenartig geprüft werden – etwa ob Team-Namen wirklich dem Schema entsprechen – und bei Abweichungen korrigierend eingreifen.

7. Wie wird Gastzugriff sicher geregelt und regelmäßig überprüft?
Zunächst mit klaren Regeln, wer Gäste einladen darf und in welchen Teams Gäste zulässig sind. Oft entscheidet man: Nur Team-Eigentümer dürfen externe Personen hinzufügen, und dies auch nur in Teams, die als “extern erlaubt” klassifiziert sind. Zusätzlich sollte jeder Gast einen internen Sponsor haben (der Team-Eigentümer) und es muss dokumentiert sein, welcher externe zu welchem Zweck Zugang hat. Sicherheit erreicht man durch Azure AD B2B: Externe loggen sich mit einem definierten Gastkonto ein, das in unserer Azure AD geführt wird – so kann man zentral Richtlinien darauf anwenden (z.B. MFA erzwingen). Conditional Access hilft, Gastzugriff einzuschränken (etwa verbieten, dass Gäste sich ohne MFA anmelden oder aus bestimmten Ländern). Wichtig ist die zeitliche Begrenzung: Gäste sollten kein unbegrenztes Dauerticket bekommen. Lösungen: Entweder man trägt direkt beim Einladen ein Ablaufdatum ein (manuell oder via Tool), oder man nutzt Access Reviews. Letztere senden z.B. alle 3 oder 6 Monate dem Team-Eigentümer eine Liste der Gäste mit der Frage “noch berechtigt ja/nein?”. Nicht bestätigte Gäste werden dann automatisch deaktiviert oder entfernt. Microsoft Entra ID (Azure AD) bietet solche Access Reviews out-of-the-box für Gastnutzer. Zusätzlich sollte die IT periodisch einen Report ziehen, welche Gäste in wie vielen Teams sind und ob es auffällige Alt-Gäste gibt (z.B. jemand, der seit Jahren drin ist, obwohl das Projekt längst beendet wurde). Zusammengefasst: Durch initiale Beschränkung (nur bestimmte dürfen Gäste hinzufügen), technische Barrieren (MFA, keine anonymen Links, etc.) und regelmäßige Reviews bleibt der Gastzugriff unter Kontrolle. Jeder Gast hat einen Verantwortlichen und ein definiertes End-of-Life.

8. Welche Regeln gelten für Standard-, private und geteilte Kanäle?
Standardmäßig sollten Standard-Kanäle genutzt werden – diese sind für alle Teammitglieder sichtbar und fördern offene Zusammenarbeit. Die Governance-Regel könnte lauten: “Alles, was nicht wirklich vertraulich sein muss, gehört in Standard-Kanäle.” Private Kanäle hingegen erlauben eine Untergruppe innerhalb des Teams, getrennt zu kommunizieren. Die Regel hier: Einsatz nur, wenn Inhalte wirklich nur von einem Teil des Teams gesehen werden dürfen (z.B. Leitungskreis, vertrauliche Personalthemen). Man sollte definieren, wer private Kanäle erstellen darf – oft beschränkt man das auf Team-Eigentümer, um Wildwuchs zu vermeiden. Auch sollte begrenzt werden, wie viele private Kanäle sinnvoll sind (zu viele fragmentieren die Kommunikation). Geteilte Kanäle (Shared Channels) erlauben das Einbinden von Personen außerhalb des Teams (sogar außerhalb der Organisation) in einen einzelnen Kanal. Sie sind praktisch für bereichsübergreifende Themen, ohne gleich allen Zugriff auf alles zu geben. Hier sollte die Governance festlegen: Shared Channels nur nach Prüfung durch IT/Entra ID-Settings, da externe Zusammenarbeit über geteilte Kanäle besondere Voraussetzungen hat (z.B. müssen Partnerorganisationen via B2B Direct verbunden sein). Möglicherweise verbietet man Shared Channels zunächst ganz, bis das Modell erprobt ist, oder erlaubt sie nur für bestimmte vertrauenswürdige Partner. Zusätzlich gelten Benennungsregeln: ein privater Kanal könnte z.B. einen Schlüssel im Namen tragen (“🔒” oder “priv-” im Namen), damit klar ist, dass er eingeschränkt ist. Verantwortlichkeit: Team-Owner müssen auch ihre privaten und geteilten Kanäle verwalten, sprich Mitgliederlisten aktuell halten und entscheiden, wann solche Kanäle vielleicht wieder gelöscht werden können. Zusammengefasst: Standard-Kanäle als Default, private nur wenn nötig (erst nachdenken, ob wirklich erforderlich), geteilte sehr restriktiv handhaben – diese Entscheidungen und Rechte sollte die Governance eindeutig vorgeben.

9. Wie lange bleiben inaktive Teams bestehen und wer entscheidet über Archivierung/Löschung?
Inaktive Teams – also solche, in denen über einen längeren Zeitraum keine Aktivitäten stattfanden – sollten nicht unbegrenzt herumliegen. Viele Unternehmen führen daher eine Ablaufregel ein: z.B. “Wenn ein Team 180 Tage inaktiv war, muss es überprüft werden”. Microsoft 365 bietet die Gruppen-Expiration-Funktion: Hier kann man z.B. 180 Tage einstellen; danach bekommen die Owner eine Benachrichtigung und können mit einem Klick verlängern – tun sie nichts, wird das Team (die M365-Gruppe dahinter) gelöscht. Governance-technisch ist das eine praktische Automatisierung. Alternativ oder zusätzlich kann ein Review-Prozess definiert sein: z.B. ein Governance-Team sichtet vierteljährlich die Nutzungsstatistiken und schreibt die Owner inaktiver Teams an mit der Frage, ob das Team noch gebraucht wird. Entscheidungshoheit sollte beim Fachbereich liegen: Der Team-Eigentümer (oder sein Vorgesetzter) weiß am besten, ob der Inhalt noch relevant ist. Er meldet zurück “bitte noch behalten” oder “kann weg”. Die IT kann dabei beraten (etwa Alternativen anbieten, Archivierung statt Löschung). Archivierung bedeutet: das Team wird auf “nur Lesen” gesetzt – damit ist es aus der aktiven Liste raus, aber Daten sind noch da. Das kann ein guter Zwischenschritt sein. Letztlich, wenn gelöscht werden soll, sollte die IT die Ausführung übernehmen, damit sichergestellt ist, dass z.B. ein Backup existiert oder gesetzliche Aufbewahrungsfristen beachtet wurden. Zusammengefasst: Inaktive Teams sollten typischerweise nach ca. 6-12 Monaten einer Überprüfung unterzogen werden. Der Team-Eigentümer entscheidet fachlich, ob das Team noch lebt. Gibt es keine Rückmeldung, kann eine Governance-Regel vorsehen, dass das Team automatisiert erst archiviert und später gelöscht wird (Safety-Net). Diese Vorgehensweise verhindert endlose Karteileichen, ohne dass wichtige Infos ungefragt verschwinden.

10. Wie setzt man Aufbewahrung, Löschung und eDiscovery in Teams um?
Hier kommt Microsoft Purview (das Compliance Center) ins Spiel. Für Aufbewahrung definiert man Retention-Richtlinien: z.B. “Alle Teams-Channel-Nachrichten 3 Jahre aufbewahren, dann löschen” oder “Chats der Benutzer 1 Jahr aufbewahren”. Solche Richtlinien werden im Purview Compliance Center konfiguriert und greifen im Hintergrund auf Teams-Inhalte (die ja in Exchange Online Postfächern liegen für Chat/Channel-Nachrichten). Ähnlich kann man für SharePoint (Team-Dateien) Aufbewahrungsvorgaben machen – etwa Projektdokumente 7 Jahre behalten. Wichtig: Diese Policies sollten mit der Rechtsabteilung abgestimmt sein. Für die Löschung gilt: Entweder automatisch durch Ablauf der Retention-Period (dann löscht das System die Inhalte oder markiert sie als zur Löschung bereit), oder manuelle Löschung im Rahmen eines Governance-Prozesses (z.B. Team wird abgeschlossen und manuell gelöscht, nachdem Inhalte exportiert wurden). Oft kombiniert man beides: Regelmäßige automatische Löschfristen für Routine-Inhalte, plus manuelle Verfahren für Sonderfälle. eDiscovery: Um Daten in Teams zu durchsuchen (etwa im Rechtsstreit oder bei Compliance-Untersuchungen), nutzt man eDiscovery-Tools im Purview Center. Dafür muss zunächst das Überwachungsprotokoll aktiviert sein (Unified Audit Log), damit alle Aktivitäten erfasst werden. Dann können berechtigte Personen (meist Compliance-Staff oder Juristen in Zusammenarbeit mit IT) einen eDiscovery-Fall erstellen, Suchkriterien definieren (z.B. alle Nachrichten von Benutzer X in Zeitraum Y mit Keyword Z) und die Ergebnisse exportieren. Es ist ratsam, dafür ein eingespieltes Verfahren zu haben – einschließlich Rollenverteilung: Wer darf solche Suchen initiieren (nur wenige Vertrauenspersonen!) und wie wird das Ergebnis behandelt. Zusätzlich gibt es die Möglichkeit von Legal Hold: Wenn z.B. ein Gerichtsverfahren läuft, kann man alle Inhalte, die einen bestimmten Benutzer oder Team betreffen, auf Hold setzen, damit nichts gelöscht wird – auch das im Purview Center. Kurz gesagt: Umsetzung erfolgt über die vorhandenen M365-Compliance-Werkzeuge, die in der Governance festgelegten Aufbewahrungsfristen und Verantwortlichkeiten müssen dort technisch abgebildet werden.

11. Welche Apps/Connectors sind erlaubt und wie funktioniert ihre Freigabe?
Grundsätzlich sollte es eine Positivliste erlaubter Apps geben. Microsoft Teams hat einen App Store mit Hunderten Apps – ohne Governance könnten Nutzer theoretisch alle installieren. Daher entscheidet das Unternehmen, welche Typen von Apps erlaubt sind: Meist sind die Microsoft-eigenen Standard-Apps (Planner, Forms, OneNote etc.) gesetzt. Bei Drittanbieter-Apps wählt man gezielt aus, was sinnvoll und sicher ist, z.B. eine bekannte Umfrage-App oder ein genehmigter PDF-Signer. Alles andere wird standardmäßig blockt. Technisch setzt man dies über Teams Berechtigungsrichtlinien um: dort kann man einstellen “Nur erlaubte Apps zulassen” und die gewünschten Apps auflisten. Nun zum Freigabeprozess: Wenn ein Benutzer oder Fachbereich eine neue App/Connector nutzen möchte, die noch nicht erlaubt ist, stellt er einen Antrag (ähnlich wie bei neuen Tools generell). Dieser sollte Informationen enthalten, wozu die App dient, ob sie Daten aus Teams herausführt, wer der Anbieter ist usw. Eine IT- oder Security-Abteilung prüft dann diese App auf Herz und Nieren: Sicherheitsaspekte, Datenschutz (ist der Anbieter DSGVO-konform?), vielleicht ein Test in einer Sandbox. Falls die App unbedenklich und nützlich ist, wird sie in die erlaubten Apps aufgenommen und im Teams Admin Center freigeschaltet. Falls nicht, lehnt man sie ab und kommuniziert Alternativen. Wichtig ist, diese Entscheidungen zu dokumentieren (z.B. in einem Wiki: “App XYZ geprüft am…, nicht zugelassen weil…”). Zudem sollten regelmäßige Reviews stattfinden – Apps, die früher ok waren, könnten unsicher werden oder vom Anbieter aufgegeben. Daher z.B. jährlich prüfen: welche Apps sind im Einsatz, sind alle noch genehmigt? Fazit: Erlaubt ist nur, was auf der Liste steht. Die Freigabe neuer Apps läuft über einen formalen Prozess zwischen Antragsteller, IT und Compliance, um Risiken zu checken. Dadurch behält man die Kontrolle über die Integrationen in Teams.

12. Wie steuert man Meeting-, Chat- und Aufzeichnungsfunktionen (z. B. Aufzeichnungen, Transkripte)?
Über dedizierte Teams-Policies lässt sich sehr fein einstellen, wer was darf. Beispiel Meetings: In der Teams-Adminkonsole kann man Meeting-Richtlinien anlegen – dort kann man definieren, ob Benutzer Meetings aufnehmen dürfen, ob Transkriptionen erlaubt sind, ob anonyme Teilnehmer zugelassen sind, ob Lobby aktiviert ist, wer präsentieren darf etc. Eine Governance könnte z.B. vorgeben: Aufzeichnungen nur für interne Meetings, daher für Gäste-Accounts die Aufzeichnungsfunktion deaktivieren. Oder: Transkription standardmäßig aus, außer für bestimmte Nutzergruppen (etwa Vorstand, für Protokollzwecke). Chat-Funktionen steuert man über Nachrichtenrichtlinien: Man kann unterbinden, dass Benutzer ihre Chatnachrichten löschen oder bearbeiten – relevant, wenn Chats als offizieller Kommunikationsweg angesehen werden, der nachvollziehbar sein muss. Auch kann man z.B. Benutzer von externen Organisationen das Starten von Chats verbieten (sodass Externe nur innerhalb von Teams-Kanälen kommunizieren dürfen). Aufzeichnungen: Hier ist neben der technischen Einstellung (wer darf aufzeichnen) auch wichtig, wie lange Aufzeichnungen aufbewahrt werden. Teams bietet eine automatische Löschung nach X Tagen, was man einschalten kann. Wenn z.B. die Governance sagt “Meeting-Aufzeichnungen gelten als temporär”, könnte man sie nach 30 Tagen löschen lassen. Ist eine Aufzeichnung hingegen ein offizielles Protokoll, sollte es woanders abgelegt und länger aufbewahrt werden (Records Management). Transkripte sind praktisch für Durchsuchbarkeit, aber erzeugen sensible Textdaten – Governance kann festlegen, ob sie automatisch erstellt werden dürfen. Man kann Transkription in den Richtlinien deaktivieren oder aktivieren. Steuerung in der Praxis: In vielen Fällen erstellt man verschiedene Richtlinien für verschiedene Nutzergruppen. Beispielsweise eine strenge Policy für alle Standardnutzer (keine externen Chats, keine privaten Besprechungen ohne Lobby, keine Aufzeichnung durch Teilnehmer) und eine gelockerte für Moderatoren oder Führungskräfte, die gewisse Funktionen brauchen. Diese Policies weist man per Gruppe oder Attribut zu. So wird zentral gesteuert, welche Funktionen in welchem Kontext genutzt werden können. Zudem sollte kommuniziert werden: z.B. “Aufzeichnen von Meetings ist nur mit Einwilligung aller Teilnehmer zulässig und technisch auch nur für Organisatoren freigeschaltet.” Damit ist klar geregelt, was geht und was nicht.

13. Wie schützt man sensible Daten (DLP, Sensitivitätslabels, Insider-Risk-Kontrollen)?
Durch eine Kombination aus Prävention und Überwachung. DLP (Data Loss Prevention) ist ein präventiver Ansatz: Man definiert Regeln, die erkennen, wenn jemand z.B. in einem Chat eine Kreditkartennummer oder Kundendaten verschickt, oder wenn ein Dokument mit vertraulichen Informationen in ein öffentliches Team hochgeladen wird. Diese Regeln greifen dann ein – entweder wird die Nachricht blockiert oder es geht zumindest ein Alarm an einen Security-Verantwortlichen. So verhindert man viele versehentliche (oder absichtliche) Datenlecks direkt im Entstehungsmoment. Sensitivitätslabels wirken ebenfalls präventiv, indem sie Daten klassifizieren und schützen. Ein Dokument, das als “Vertraulich” gelabelt ist, kann automatisch verschlüsselt werden, sodass nur bestimmte Personen es lesen können. Oder ein ganzes Team mit Label “Geheim” lässt keine externen Gäste zu und alle Dateien darin erben bestimmte Schutzmaßnahmen. Indem man also konsequent Labels einsetzt – entweder manuell durch die Nutzer (die beim Speichern von Dokumenten die Vertraulichkeit wählen) oder automatisch per Regeln – stellt man sicher, dass sensible Daten als solche markiert sind und nicht offen rumliegen. Insider Risk Kontrollen ergänzen das durch Überwachung: Sie erkennen Muster, die auf Datenabzug oder Missbrauch hindeuten, z.B. wenn jemand massenhaft Dateien aus Teams herunterlädt, kurz bevor er das Unternehmen verlässt, oder wenn ungewöhnlich viele sensible Infos auf einmal extern geteilt werden. Solche Tools (in Microsoft Purview verfügbar) generieren Warnungen, damit Sicherheitsverantwortliche nachforschen können. Zusätzlich sollte man administrative Schutzmaßnahmen nicht vergessen: z.B. Zugriffsbeschränkungen per Conditional Access (dass sensible Teams nur von Firmengeräten aus aufgerufen werden dürfen), oder Blockieren von Forwarding/Downloads in bestimmten Fällen (man kann z.B. verhindern, dass in einem als “Top Secret” klassifizierten Team überhaupt Dateien heruntergeladen werden). Und schließlich Schulung: Nutzer sensibilisieren, was als sensibel gilt und wie sie damit umgehen sollen (nicht alles in Teams posten, sichere Kanäle nutzen etc.). Diese vielfältigen Maßnahmen greifen idealerweise ineinander: Labels und DLP verhindern viel im Voraus, und falls doch jemand versucht, etwas zu umgehen, schlagen Überwachungsmechanismen Alarm, sodass Schäden eingegrenzt werden.

14. Wie werden externe Projekte sauber abgewickelt – vom Start bis zur Beendigung?
Ein externes Projekt beginnt typischerweise damit, dass ein Team mit Gastzugriff eingerichtet wird. Start: Governance sorgt hier dafür, dass schon die Anlage strukturiert erfolgt: Das Team wird z.B. als “Extern” klassifiziert, es bekommt einen eindeutigen Namen (Projektname + Extern), und jeder externe Partner, der eingeladen wird, durchläuft den definierten B2B-Einladungsprozess (inkl. MFA, Terms of Use etc.). Zudem wird idealerweise gleich ein Enddatum für das Projekt (bzw. die Team-Überprüfung) festgelegt – z.B. Projektlaufzeit 1 Jahr. Während der Projektphase gelten die normalen Regeln: Der Team-Eigentümer muss darauf achten, neue Externe nur kontrolliert hinzuzufügen und die Daten im Blick zu behalten. Regelmäßige Gast-Access-Reviews (z.B. alle 3 Monate) stellen sicher, dass nur noch aktive Partner drin sind. Oft werden bei externen Projekten auch bestimmte Einschränkungen aktiv: z.B. dürfen Externe keine Dateien downloaden oder es wird verhindert, dass vertrauliche Infos ins Team hochgeladen werden (per DLP-Regel), um das Risiko klein zu halten. Beendigung: Schon bevor das Projekt ausläuft, erinnert die Governance (oder ein Tool wie CosyTrack.Provisioner) den Owner daran, das Team zu schließen. Dann werden schrittweise die externen Partner entfernt (damit sie keinen Zugang mehr haben), und das Team wird archiviert oder gelöscht. Archivierung ist sinnvoll, wenn die Projektergebnisse noch intern referenziert werden sollen – dann bleibt das Team als Read-only bestehen, aber ohne externe Zugriffe. Nach einer Aufbewahrungsfrist kann es endgültig gelöscht werden. Wichtig ist auch die Nachbereitung: Der interne Projektleiter sollte evtl. eine Abschlussdokumentation in einer dauerhaften Ablage sichern (falls das Team gelöscht wird, damit Wissen nicht verloren geht). Die Governance könnte vorschreiben, dass ein Projektabschluss-Report im Intranet abgelegt wird. Schlussendlich wird das Team in der Teams-Übersicht als “geschlossen” markiert oder verschwindet, und in der CMDB/Team-Datenbank wird vermerkt, dass das Projekt beendet ist. So behält das Unternehmen den Überblick. Kurz gesagt: Saubere Abwicklung heißt, von der kontrollierten Einrichtung (mit Klassifizierung und bewusstem Aktivieren des Gastzugriffs) über laufende Kontrolle (wer ist drin, was passiert) bis zur geordneten Abschaltung (Entzug aller Externen, Archivierung, Daten sichern, Löschen nach Frist) ist alles geplant und wird nach Prozess erledigt.

15. Wie misst man den Erfolg von Governance (KPIs, Audits, Reifegrad)?
Der Erfolg einer Governance-Initiative lässt sich an bestimmten Kennzahlen und Prüfungen ablesen. Zunächst bieten KPIs (Key Performance Indicators) quantitative Einblicke: Beispiele sind Anteil der Teams, die allen Richtlinien entsprechen (sollte stetig steigen Richtung 100%), durchschnittliche Bereitstellungsdauer eines Teams (sollte sinken, wenn Prozesse effizienter werden), Anzahl der Sicherheitsvorfälle oder DLP-Treffer in Teams (sollte sinken, wenn Policies greifen), oder auch Nutzungshäufigkeit von Teams (bleibt sie stabil oder steigt, was auf Akzeptanz hindeutet). In Abschnitt 8 sind diverse KPIs aufgeführt. Diese Werte regelmäßig zu erheben und zu vergleichen (Vorher-Nachher) zeigt, ob Governance messbare Verbesserungen bringt – z.B. schnellere Bereitstellung, weniger Verstöße, weniger Wildwuchs.
Zusätzlich sind Audits wichtig: Ein internes Audit kann prüfen, ob die definierten Prozesse auch eingehalten werden. Beispielsweise stichprobenartig 10 neue Teams nehmen und schauen: Haben die alle Genehmigungen? Wurden die richtig benannt? Solche Audits (oder externe Prüfungen, z.B. ISO 27001) geben qualitatives Feedback, ob die Governance funktioniert oder ob Lücken bestehen. Wenn ein Auditor feststellt, dass z.B. einige Teams ohne Label existieren trotz Vorgabe, ist das ein Hinweis, nachzusteuern.
Der Reifegrad der Governance kann mit Modellen bewertet werden – etwa anlehnend an CMMI (Level 1-5) oder einfach anhand eines M365 Governance Maturity Models. Am Anfang (Level 1) hat man vielleicht nur informelle Regeln, auf höheren Leveln sind Prozesse automatisiert, KPIs werden ausgewertet und kontinuierlich verbessert. Das Unternehmen kann sich Zielvorgaben setzen, z.B. innerhalb eines Jahres von “ad-hoc” zu “standardisiert” (Level 2 zu 3) zu kommen.
Konkret misst man Erfolg, indem man vor Einführung der Governance einen Baseline-Status aufnimmt (wie viele Verstöße/Probleme treten auf, wie lange dauert X) und nach einigen Monaten vergleicht. Auch weiches Feedback zählt: Fragen wie “fühlen sich die Nutzer besser unterstützt?” können via Umfrage ermittelt werden. Wenn z.B. die Fachabteilungen sagen “Team-Anfragen gehen viel schneller und die Struktur hilft uns”, ist das ein Erfolg. Zusammengefasst: Erfolgsmessung = KPIs tracken, Audits/Reviews durchführen und vielleicht einen Reifegrad bestimmen. Wenn die Kennzahlen in die richtige Richtung laufen und Audits wenige Findings haben, ist die Governance auf gutem Weg.

16. Wie gehen Ausnahmefälle und Sonderrechte regelkonform?
Auch mit strikter Governance wird es immer Szenarien geben, die nicht ins Schema passen – sogenannte Exceptions. Wichtig ist, diese Ausnahmefälle gezielt zu managen, statt stillschweigend Unregelmäßigkeiten zu dulden. Das heißt: Es muss einen definierten Ausnahmeprozess geben. Beispiel: Die Policy sagt max. 5 Externe pro Team, aber ein Großprojekt benötigt 10 Externe. Der Projektleiter beantragt eine Ausnahme mit Begründung (“Großprojekt X erfordert mehr Gäste wegen Partner Y”). Diese Anfrage geht an eine zuständige Stelle, z.B. das Governance Board oder den CISO/IT-Leiter, je nach Thema. Die prüfen das Risiko und Nutzen ab und entscheiden, ob die Ausnahme gewährt wird. Wenn ja, dann befristet und dokumentiert: z.B. “Erlaubnis erteilt, 10 Gäste bis Projektende 31.12., danach wieder Policy-konform reduzieren”. Solche Sonderfreigaben sollten am besten im System hinterlegt oder zumindest per E-Mail schriftlich festgehalten werden, damit bei Audit klar ist, dass es autorisiert war.
Sonderrechte – das können auch spezielle Accounts oder Einstellungen sein, z.B. ein Team, das keine Löschfristen hat, weil es ein Archiv ist. Diese müssen ebenso offiziell genehmigt werden.
Regelkonform heißt hier: Der Prozess selbst wird Teil der Governance-Dokumentation. Man definiert: wer darf Ausnahmen genehmigen? (Meist höheres Management oder eine interdisziplinäre Runde). Wie werden sie festgehalten? Und idealerweise: Nachprüfung der Ausnahme. Nach Ablauf der Zeit sollte geprüft werden, ob sie noch nötig ist. Governance kann z.B. vorsehen, dass alle Ausnahmen jährlich auf den Prüfstand kommen.
Wichtig: Ausnahmen sollten Ausnahmen bleiben, also selten vorkommen. Wenn man merkt, es häufen sich ähnliche Ausnahmen, ist das ein Signal, die generelle Policy anzupassen. Sonst baut man sich eine Schatten-Governance neben der offiziellen.
Beispiel: Ein Team braucht einen dauerhaft offenen externen Zugang für einen öffentlichen Chat (Community). Wenn das gegen Policy ist, kann man das als Ausnahme genehmigen, aber parallel überlegen, ob man für solche Fälle eine offizielle Lösung anbietet (z.B. via Yammer/Communities), damit es nicht ständig als Ausnahme läuft. Kurz gesagt: Ausnahmen geregelt zulassen, aber im Blick behalten und möglichst daraus lernen, um die Regeln praxisnah zu halten.

17. Wie funktioniert die periodische Rezertifizierung von Besitzern und Mitgliedern in der Praxis?
In der Praxis wird dies häufig über E-Mails oder ein Tool gelöst, das in regelmäßigen Abständen Aktivität auslöst. Beispiel: Die Governance schreibt vor, alle 6 Monate muss jedes Team bestätigt werden. Konkret könnte das so ablaufen: Ein Scheduler (oder Admin manuell) schaut, welche Teams demnächst fällig sind – sagen wir, Team “XYZ” hat 6 Monate bestanden. Der Team-Eigentümer erhält automatisiert eine E-Mail oder Aufgabe: “Bitte überprüfe Team XYZ: Ist das Team noch aktiv benötigt? Sind die Mitgliederlisten und Gäste aktuell? Bestätige oder melde zurück bis zum Datum…”. Der Owner klickt dann entweder auf “Team bleibt aktiv” oder “Team kann geschlossen werden” bzw. teilt Änderungen mit (“Bitte 2 neue Owner ernennen, ich verlasse die Abteilung”). Dieses Feedback geht an die zuständige Stelle – evtl. ein Workflow, der bei “schließen” direkt die Archivierung anstößt.
Microsoft bietet mit Entra ID Access Reviews eine Möglichkeit für Mitglieder-Überprüfung (insbesondere Gäste) – dabei bekommt der Owner eine Liste der Benutzer zur Bestätigung/Ausmisten. Für die generelle Team-Notwendigkeit macht es der Expiration-Workflow: Owner klickt “verlängern” oder lässt es auslaufen. In Unternehmen ohne diese Features kann man es auch manuell machen: z.B. Excel-Liste aller Teams mit letztem Aktivitätsdatum erzeugen, filtern welche >6 Monate inaktiv sind, und dann die jeweiligen Owner anschreiben. Das ist aufwändiger, aber erfüllt den Zweck.
Wichtig ist die Nachverfolgung: In der Praxis reagieren nicht alle Owner sofort. Daher muss es eine Eskalation geben: keine Rückmeldung = Erinnerung, weiterhin nichts = Info an dessen Chef oder automatische Archivierung. Hier zeigt sich der Wert von Automatisierungstools, die diese Logik abbilden.
Zusammengefasst: Rezertifizierung heißt konkret alle X Monate ein “Ping” an die Verantwortlichen: Ist dein Team noch ok? Das läuft ideal automatisiert (via M365 Group Expiration oder Tools wie Provisioner). Der Owner bestätigt oder bereinigt Mitglieder. Dieses Ergebnis wird protokolliert. So bleibt die Team-Landschaft aktuell. In der Praxis startet man vielleicht mit einem Jahresturnus und verkürzt später, je nach Risikoprofil.

18. Wie integriert man Governance in ITSM/CMDB und Change-Prozesse?
Teams-Governance sollte in die bestehenden IT-Prozesse eingebettet werden, damit sie nachhaltig gelebt wird. Integration in ITSM bedeutet z.B., dass das Anlegen eines neuen Teams als standardisierter Service Request im IT-Servicekatalog geführt wird. Wenn also jemand ein Team braucht, öffnet er nicht formlos irgendein Tool, sondern es gibt einen definierten “Neues Team beantragen”-Service (der im Hintergrund vielleicht den Provisioner aufruft). Damit ist jeder Antrag auch im Ticket-System nachvollziehbar. Ebenso können Änderungen an Teams (wie “Gast hinzufügen” in sensiblen Bereichen) als Changes erfasst werden, sofern das Risiko hoch ist. Hier muss man aber abwägen: Nicht jede Team-Aktion als Ticket, sonst überfrachtet man das System. Wichtiger ist die CMDB-Integration. CMDB (Configuration Management Database) kann Teams als Configuration Items enthalten – mit Attributen wie Teamname, Owner, Erstellungsdatum, Sensitivitätslevel, Status (aktiv/archiviert). Der Provisionierungsprozess kann so gestaltet sein, dass bei Team-Erstellung automatisch ein Eintrag in der CMDB erzeugt oder aktualisiert wird. Dadurch hat die IT einen vollständigen Überblick aller “Workspaces” ähnlich wie bei Servern oder Anwendungen. Das hilft auch, Abhängigkeiten zu sehen (z.B. Team verlinkt zu zugehöriger SharePoint-Seite etc.).
Change Management: Größere Änderungen an der Governance selbst (etwa neue Richtlinie, oder Einführung des Provisioning-Tools) sollten dem regulären Change-Prozess folgen – also mit Risikoabschätzung, Freigabe durch Change Advisory Board. Auf Teamebene könnte man definieren, dass bestimmte heikle Aktionen nur via Change Request erfolgen: z.B. “Öffnen eines Teams für externe nachträglich” könnte einen Change erfordern, den IT und Security absegnen. Das sorgt dafür, dass solche Änderungen dokumentiert und bewusst entschieden sind.
Insgesamt sollte die Governance-Dokumentation in die IT-Prozesslandschaft eingebettet sein: Die Betriebshandbücher erwähnen die Teams-Governance, das Onboarding neuer Mitarbeiter im IT-Bereich schult gleich diese Abläufe mit. Bei Audits kann man dann zeigen: Hier ist unser Prozess (im ITSM-Tool abgebildet), hier unsere CMDB-Liste der Teams mit allen Eigenschaften. Das wirkt sehr reif und kontrolliert. Praktisch heißt das, idealerweise automatisiert das Provisioning-Tool bereits viele Einträge; wenn nicht, müssen Administratoren manuell nachpflegen (z.B. einmal im Monat neue Teams in CMDB eintragen). Und jeder Ausnahme-Change wird als normaler IT-Change dokumentiert. So verzahnt sich die Spezialwelt “Teams” mit den allgemeinen IT-Governance-Prozessen.

19. Welche Schulungen benötigen Besitzer, Mitglieder und Administratoren?
Team-Besitzer (Owner) sind die wichtigste Gruppe, weil sie im täglichen Betrieb die Governance umsetzen. Sie brauchen Schulung darin, was ihre Verantwortungen sind: z.B. Mitgliederpflege (wer darf rein, Gastprüfung), wie man Sensitivitätslabels am Team und an Dateien setzt, was bei externen Freigaben zu beachten ist, und dass sie Rezertifizierungen durchführen müssen. Außerdem sollten sie das Provisionierungstool bedienen können, falls sie Teams beantragen müssen oder bestimmte Vorgänge dort zu erledigen sind. Diese Schulung kann in Form von kurzen Workshops oder Online-Trainings passieren. Wichtig ist regelmäßige Auffrischung, da oft Fluktuation herrscht oder Neuerungen dazukommen.
Team-Mitglieder: Alle Nutzer von Teams sollten zumindest die “Netiquette” und Grundregeln kennen. Schulung für Mitglieder umfasst z.B.: Welche Daten dürfen in Teams geteilt werden und welche nicht (Datenklassifikation erklären)? Wie findet man Informationen (damit weniger Wildwuchs durch Unkenntnis entsteht)? Was tun, wenn man jemand Externes einbeziehen will (nicht selbst umgehen, sondern offiziellen Weg)? Außerdem gute Praktiken wie Ordnerstruktur, @Mention-Etikette etc., um produktiv zu arbeiten – das ist eher Governance-adjacent (Best Practices). Eine pragmatische Lösung sind kurze How-To-Guides oder Wiki-Seiten, eventuell ein obligatorisches eLearning für alle Mitarbeiter zum Thema “sicher und effizient mit Teams arbeiten”.
Administratoren: Für IT-Administratoren, besonders jene im M365/Teams Admin Center, ist vertieftes Wissen nötig. Sie müssen die technischen Einstellungen kennen, um die Richtlinien umzusetzen: z.B. wie man eine DLP-Regel konfiguriert, wo man die Gastzugangsoptionen findet, wie Sensitivity Labels für Teams aktiviert werden. Sie sollten auch mit dem Provisionierungstool vertraut sein und es administrieren können. Dazu kommt Schulung im Bereich Compliance-Features (Audit-Log, eDiscovery) – hier überschneidet sich das Aufgabengebiet mit IT-Security/Compliance-Team. Oft lohnt es sich, gemeinsame Workshops zwischen IT und Compliance zu machen, damit Admins verstehen, warum sie bestimmte Dinge tun, und die Security-Leute verstehen, was technisch möglich ist.
Zusätzlich: Key User/Power User – manche Unternehmen setzen auf Botschafter in Fachabteilungen, die etwas tiefer geschult werden, um Kollegen zu unterstützen und als verlängerter Arm der Governance zu wirken. Solche Power User könnte man gezielt trainieren in Team-Lebenszyklusprozessen, dem richtigen Umgang mit externen etc.
In Summe: Jeder bekommt eine seinem Rollenlevel angepasste Schulung – vom allgemeinen Userguide für alle Team-Mitglieder bis zur detaillierten Admin-Schulung für die IT. Entscheidend ist, dass die Schulungsinhalte praktisch und relevant sind, damit die Leute verstehen, wie Governance ihnen im Alltag begegnet (z.B. “Wie beantrage ich ein Team?” live vorführen, “Wie führe ich eine Mitgliederprüfung durch?”). Nur so werden die Regeln auch akzeptiert und befolgt.

20. Wie unterstützt der CosyTrack.Provisioner Governance-Prozesse konkret und messbar?
CosyTrack.Provisioner automatisiert viele der genannten Governance-Aufgaben und macht sie damit nicht nur einfacher, sondern auch besser nachverfolgbar. Konkret sorgt das Tool dafür, dass bei der Team-Erstellung keine Richtlinie vergessen wird: Es erzwingt z.B. die richtige Namenskonvention (der Benutzer kann gar keinen falschen Namen eingeben, da Vorlagen und Prefixe vorgegeben sind) und verlangt bestimmte Eingaben wie Sensitivitätsstufe oder Projektlaufzeit. Damit ist jedes neue Team von Anfang an konform – messbar etwa daran, dass 100% der über den Provisioner erstellten Teams korrekt klassifiziert sind (im Gegensatz zu vielleicht nur 60% bei freier Erstellung vorher). Der Provisioner implementiert auch den Genehmigungsworkflow, d.h. es gibt immer einen dokumentierten Freigabeschritt. Messbar wird das z.B. in der KPI “Teams ohne Genehmigung”: die sollte durch Einsatz des Tools auf 0 sinken. Durch die Vorlagen stellt er Konsistenz sicher – alle Projektteams haben die gleichen Kanäle, was man auch statistisch sieht (z.B. kein Team hat plötzlich fehlende Standardkanäle). Lebenszyklus: Das Tool erinnert automatisch an Rezertifizierungen und archiviert inaktive Teams nach Prozess – Erfolg messbar daran, dass kein Team länger als X Tage unüberprüft bleibt. Logging: Jede Aktion ist protokolliert und kann ausgewertet werden (Audit-Quote verbessert sich). Geschwindigkeit: Provisioner verkürzt die Bereitstellungszeit enorm – das kann man messen als Durchschnittszeit vom Antrag bis Bereitstellung, die z.B. von 5 Tagen (manuell) auf 5 Stunden sinkt. Fehlervermeidung ist schwer direkt zu messen, aber indirekt: z.B. vorher musste IT 20% der neu erstellten Teams nacharbeiten (wegen falscher Einstellungen), nach Einführung sind Korrekturen gegen Null. Zudem liefert das Tool Berichte/Dashboards: Es kann z.B. anzeigen, wie viele Teams pro Monat erstellt wurden, wie viele davon mit Gästen, wie viele archiviert etc. Diese Zahlen fließen direkt in die KPI-Messung ein. Alles in allem fungiert CosyTrack.Provisioner als Enforcer und Beschleuniger der Governance. Prozesse wie Beantragung, Freigabe, Namensprüfung, Label-Zuweisung, Owner-Check, Gastkontrolle – all das läuft automatisch und homogen. Dadurch werden Governance-Vorgaben nicht nur Theorie auf Papier, sondern gelebte Praxis, und das Unternehmen kann anhand der Tool-Daten jederzeit nachweisen, dass die Regeln eingehalten werden (Compliance-Nachweise) und wo ggf. nachjustiert werden muss (das Tool macht Abweichungen sichtbar, falls jemand manuell etwas ändert). Dieser konkrete, messbare Support ist der Hauptnutzen: Governance wird greifbar und auditierbar, ohne jeden einzelnen Schritt manuell prüfen zu müssen.

11. Schluss & Handlungsaufforderung

Wichtigste Erkenntnisse:
– Ohne klare Teams-Governance drohen Chaos, Sicherheitsrisiken und Regelverstöße – eine strategische Steuerung ist für mittelgroße und große Organisationen unverzichtbar.
– Teams-Governance besteht aus technischen Policies und organisatorischen Prozessen. Nur das Zusammenspiel von beidem (Tools plus Rollen/Abläufe) bringt Sicherheit und Effizienz.
– Eine gute Governance bremst nicht die Produktivität, sondern schafft im Gegenteil Struktur und klare Verantwortlichkeiten, was die Zusammenarbeit effektiver macht.
– Zentrales Erfolgsrezept ist Automatisierung: Wo immer möglich sollten Richtlinien durch die Plattform oder Tools wie CosyTrack.Provisioner durchgesetzt werden, statt auf manuelle Disziplin zu hoffen.
– Die Einführung erfordert bereichsübergreifende Abstimmung (IT, Fachbereiche, Compliance) und Change-Management – aber die Mühe lohnt sich durch deutlich weniger Wildwuchs und nachweisbare Compliance.
– Governance ist kein einmaliges Projekt, sondern ein kontinuierlicher Verbesserungsprozess. Regelmäßiges Monitoring der KPIs und Anpassung der Regeln halten die Teams-Landschaft langfristig gesund.

Nächste Schritte (Beispielplan für Entscheider):
– Innerhalb der nächsten 2 Wochen: Governance-Kickoff mit allen Stakeholdern ansetzen, um Commitment von Management-Seite und Ressourcen für das Vorhaben zu sichern. Verantwortliche benennen (Governance Lead) und ein Kernteam bilden.
– Innerhalb von 4–6 Wochen: Ist-Analyse und Konzeptphase abschließen – erste Richtlinienentwürfe, Definition von Team-Typen und Auswahl eines Pilotszenarios. Entscheidung fällen, ob ein Tool (wie CosyTrack.Provisioner) pilotiert werden soll; ggf. Teststellung vorbereiten.
– In ca. 2–3 Monaten: Pilotierung durchführen (z.B. in einem ausgewählten Geschäftsbereich). Ergebnisse auswerten und Feinjustierung vornehmen. Parallel Schulung der Key User/Owner im Pilotbereich.
– Folgend: Entscheidungsvorlage für Rollout erstellen und vor Top-Management präsentieren. Bei positivem Entscheid: unternehmensweiten Rollout planen (Policy-Veröffentlichung, Tool-Einsatz, Trainings für alle Team-Eigentümer), mit konkretem Zeitplan und Verantwortlichkeiten.

Damit liegt ein klarer Weg vor, um Microsoft Teams in geordnete Bahnen zu lenken – jetzt heißt es: anfangen und die Collaboration-Plattform fit machen für nachhaltigen, sicheren Einsatz.

 

Weitere Beiträge zum Thema SharePoint und Teams