Ein Microsoft 365 Governance-Modus ist das Betriebsmodell, das ein Unternehmen für die Verwaltung seiner Teams- und SharePoint-Workspaces wählt — bestimmt durch zwei unabhängige Entscheidungen: den Governance-Ansatz (präventiv oder reaktiv) und die Sicherheitsanforderung (scoped oder tenant-weiter Tool-Zugriff). Diese zwei Entscheidungen ergeben vier Modi — Enclave, Enforced, Scoped und Native — und der Modus, den Sie brauchen, entscheidet, welche Governance-Tools für Sie überhaupt infrage kommen.
Die meisten Gespräche über Microsoft 365 Governance springen direkt zu Features — Templates, Lifecycle-Regeln, Gäste-Ablauf, Audit-Trails. Davor muss eine IT-Abteilung jedoch diese zwei Entscheidungen treffen, denn sie bestimmen, welche Tools überhaupt in Betracht kommen. Und dieselbe Governance-Lösung kann für jede Kombination unterschiedlich ausgerollt werden.
Die zwei Dimensionen hinter jedem Governance-Modus: Ansatz und Sicherheit
Die zwei Entscheidungen sind unabhängig, und zusammen definieren sie den Modus. Die erste bestimmt, wie Sie Governance betreiben; die zweite, wie viel Zugriff das Tool dafür braucht.
Die erste ist eine Entscheidung über den Governance-Ansatz: Verhindern wir Probleme im Moment der Erstellung eines Workspaces, oder lassen wir Microsofts Standardverhalten laufen und räumen hinterher auf? Ein präventiver Ansatz konfiguriert jede Teams-Gruppe oder SharePoint-Site-Collection bei der Erstellung korrekt — die richtige Struktur, die richtigen Berechtigungen, die richtigen Lifecycle-Regeln — sodass die Probleme gar nicht erst auftreten und Strukturen standardisiert bleiben und schwer aus der Richtlinie zu bringen sind. Ein reaktiver Ansatz kann die Erstellung nicht steuern, also entsteht Wildwuchs, der nachträglich identifiziert, eingeordnet und aufgeräumt werden muss — was standardisierte Channel- und Ablagestrukturen nahezu unmöglich garantierbar macht.
Die zweite ist eine Sicherheits-Entscheidung: Wie viel Zugriff sind wir bereit, einem Drittanbieter-Tool in unserem Tenant zu gewähren? Das ist einer der größten Schmerzpunkte für IT-Abteilungen: Viele Governance-Tools verlangen hohe, tenant-weite Microsoft-Graph-Berechtigungen wie `Sites.FullControl.All` oder `Group.ReadWrite.All` — von denen einige aus Datenschutz- und Sicherheitssicht kritisch sind. Unternehmen, die Frameworks wie ISO 27001 oder TISAX erfüllen müssen, wollen — oder dürfen — solch weitreichende Rechte oft nicht an ein Governance-Tool vergeben und gehen Richtung scoped Zugriff, bei dem das Tool nur die Workspaces verwalten darf, für die es explizit freigegeben ist. Andere vergeben unbedenklich tenant-weite Rechte.
Keine der beiden Antworten sagt die andere voraus. Prävention ist mit breitem oder scoped Tool-Zugriff möglich — Sie können Strukturen bei der Erstellung durchsetzen, egal ob das Tool tenant-weite oder minimale Berechtigungen hält. Und scoped Zugriff ist mit präventiver oder reaktiver Governance möglich — wie viele Rechte das Tool hält, diktiert nicht, wie das Unternehmen seine Workspaces betreiben will.
Zwei unabhängige Entscheidungen — Ansatz (präventiv / reaktiv) und Sicherheit (scoped / tenant-weit) — ergeben vier mögliche Kombinationen. Ein echtes 2×2, kein einzelnes Spektrum. Wir benennen jede Kombination als Governance-Modus, damit eine IT-Abteilung auf den zeigen kann, der zu ihrem Ansatz und ihren Sicherheitsanforderungen passt: die Modi Enclave, Enforced, Scoped und Native.
In Valprovia Governance entsteht jeder Modus aus zwei Konfigurations-Schaltern — es hilft also, sie vor den Modi zu kennen: Pooling ist der Deployment-Schalter (die Sicherheitsachse). Mit Pooling an legt die IT einen Pool von Workspaces an, die das Tool verwalten darf, sodass es scoped läuft, ohne tenant-weite Rechte; mit Pooling aus hält das Tool tenant-weite Berechtigungen. Standard Owners ist der Ownership-Schalter (die Ansatz-Achse). Mit Standard Owners aus ist die Governance-Ebene der technische Owner und Regeln werden bei der Erstellung durchgesetzt (präventiv); mit Standard Owners an arbeiten benannte Owner nativ in Teams und Abweichungen werden nachträglich abgeglichen (reaktiv). Jeder Modus unten ist einfach eine Kombination dieser zwei Schalter, weiter unten im Detail beschrieben.
Die vier Microsoft 365 Governance-Modi im Detail
Jeder Modus ist ein benannter Punkt im 2×2: ein Governance-Ansatz gepaart mit einer Sicherheitsanforderung. Hier steht, was jeder Modus ist, wie Valprovia Governance ihn umsetzt, welche Situation er trifft und welche Art von Unternehmen in ihm läuft.
Enclave-Modus (präventiv + scoped)
Der Enclave-Modus ist präventive Governance ohne tenant-weite Rechte — Strukturen werden bei der Erstellung durchgesetzt, während das Tool immer nur eine begrenzte Menge an Workspaces berührt. Er ist der anspruchsvollste der vier Modi und der, den die meisten etablierten M365-Governance-Tools nicht bedienen können, weil sie tenant-weite Berechtigungen brauchen, um überhaupt etwas durchzusetzen. Valprovia setzt ihn mit einem Pooling-Deployment und deaktivierten Standard Owners um. Pooling ist die Deployment-Option, mit der die Lösung ohne tenant-weite Anwendungsberechtigungen läuft: Statt dass das Tool Microsoft-365-Gruppen zur Laufzeit erstellt (was tenant-weite Rechte erfordern würde), legt die IT vorab einen Pool leerer Workspaces an, die das Tool beanspruchen und verwalten darf. Valprovia arbeitet dann als scoped Service-User, der nichts außerhalb dieses Pools berühren kann, und kein Endnutzer wird in eine SharePoint-Site-Collection-Administrator-Rolle befördert.
Die klassische Situation ist eine Tochtergesellschaft oder Landesgesellschaft innerhalb eines größeren Konzerns, die für ihre Projektarbeit strukturierte Teams ausrollen will, deren Konzern-Sicherheitsteam aber keine tenant-weiten Admin-Rechte an eine Tochter vergeben wird — beide Anforderungen gelten also gleichzeitig: Prävention und minimale Berechtigungen. Er passt am schärfsten zu regulierten Tochter- und Landesgesellschaften innerhalb größerer Konzerne — über Financial Services, Public Sector, Fertigung, Pharma und Automotive hinweg — die Frameworks wie ISO 27001 oder TISAX erfüllen müssen, keine tenant-weiten M365-Rechte erhalten können und trotzdem standardisierte Channel- und Ablagestrukturen wollen.
Eine schnelle Prüfung, ob der Enclave-Modus zu Ihnen passt: fünf Fragen, jede zeigt entweder auf einen präventiven Ansatz oder auf scoped Zugriff. Je mehr Sie mit ja beantworten, desto klarer ist Enclave der Modus, den Sie brauchen.
Passt der Enclave-Modus zu Ihrem Unternehmen?
Fünf Fragen, die auf den Enclave-Modus zeigen — je mehr zutreffen, desto schärfer der Fit.
- 1 Brauchen Sie standardisierte Teams- und SharePoint-Strukturen? Präventiv
- 2 Gelten für Sie Compliance-Frameworks wie ISO 27001 oder TISAX? Scoped
- 3 Geht es um eine Geschäftseinheit im Konzern, nicht um das gesamte Unternehmen? Scoped
- 4 Sind Sie ein großes Unternehmen mit vielen Workspaces und Nutzern? Präventiv
- 5 Sollen Probleme bei der Erstellung verhindert statt nachträglich aufgeräumt werden? Präventiv
Enforced-Modus (präventiv + tenant-weit)
Der Enforced-Modus ist präventive Governance mit der stärksten Durchsetzungsgarantie — jede Workspace-Aktion läuft in dem Moment durch die Governance-Ebene, in dem sie passiert, sodass eine Regel nicht einmal kurzzeitig gebrochen werden kann. Valprovia setzt ihn mit einem Standard-Deployment und deaktivierten Standard Owners um: Das Service-Konto ist der einzige technische Owner und der einzige Site Collection Administrator, sodass Regeln von einem kontrollierten Punkt aus durchgesetzt statt nachträglich abgeglichen werden. Er passt zu zentralen IT-Teams, die den gesamten Tenant besitzen, bereit sind, tenant-weite Rechte zu vergeben, und Teams- und SharePoint-Sites im großen Maßstab erstellen — typischerweise größere Unternehmen mit einem harten Standardisierungs- oder Audit-Mandat, die jeden Workspace bei der Erstellung in der Richtlinie brauchen, nicht nachträglich abgefangen und zurückgesetzt.
Scoped-Modus (reaktiv + scoped)
Der Scoped-Modus hält den Footprint des Governance-Tools minimal, während Owner nativ arbeiten — Prävention ist nicht der Treiber; eine kleine Angriffsfläche plus starkes Reporting und Remediation ist es. Valprovia setzt ihn mit einem Pooling-Deployment und aktivierten Standard Owners um: Es werden keine tenant-weiten Berechtigungen benötigt, und die benannten Owner arbeiten im nativen Teams-Client, während Valprovia Governance Abweichungen über seinen Sync-Zyklus abgleicht. Er passt zu sicherheitsbewussten Unternehmen, die einem Drittanbieter-Tool unter keinen Umständen breite Rechte gewähren, aber keine harte Notwendigkeit haben, Strukturen vorab zu standardisieren — der scoped Footprint ist eine Sicherheitsentscheidung, unabhängig vom Governance-Reifegrad.
Native-Modus (reaktiv + tenant-weit)
Der Native-Modus ist die Microsoft-Standardposition — breiter Zugriff, native Tools, Probleme werden nach ihrem Auftreten abgefangen und aufgeräumt. Valprovia setzt ihn mit einem Standard-Deployment und aktivierten Standard Owners um: Owner arbeiten vollständig im nativen Teams-Client, während Valprovia Governance die Governance-Ebene synchron hält. Er passt zu agilen Unternehmen ohne schwere Sicherheitsverbindlichkeiten, die reaktives Aufräumen gegenüber vorgelagerter Durchsetzung akzeptieren — und viele Unternehmen sitzen hier einfach, weil es die Standardeinstellung ist.
Governance ohne tenant-weite Rechte: der gemeinsame Nenner
Die zwei scoped Modi — Enclave und Scoped — hängen von derselben zugrunde liegenden Fähigkeit ab: einem Governance-Tool, das ohne tenant-weite Microsoft-Graph-Berechtigungen arbeiten kann. Das ist es, was Microsoft 365 Governance, die keine tenant-weiten Rechte verlangt von einem Slogan zu einem echten Produktversprechen macht. Valprovia Microsoft 365 Governance ist so konzipiert, dass ein einziges Produkt jeden dieser Modi bedient, weil jeder Modus einfach eine benannte Kombination zweier Konfigurations-Schalter ist: der Deployment-Modus (Standard oder Pooling) und der Standard-Owners-Schalter.
Die zwei Schalter hinter jedem Modus
Pooling: wie Valprovia Governance ohne tenant-weite Anwendungsberechtigungen deployt
Pooling ist die eingebaute Deployment-Option von Valprovia Governance für Umgebungen, in denen tenant-weite Anwendungsberechtigungen nicht verfügbar oder nicht erwünscht sind. Statt dass die Lösung Microsoft-365-Gruppen zur Laufzeit erstellt (was die tenant-weite `Group.ReadWrite.All`-Berechtigung erfordern würde), legt das IT-Team des Kunden vorab eine Menge leerer Teams-Gruppen an. Diese Gruppen liegen in einem Pool, bereit, beansprucht zu werden. Wenn ein Nutzer einen Workspace anfragt, nimmt Valprovia eine Gruppe aus dem Pool, konfiguriert sie passend zum angefragten Template und Security Level und übergibt sie.
Valprovia Governance authentifiziert sich als dediziertes Service-Konto — ein reguläres Benutzerkonto, kein Administrator, geschützt durch MFA und Conditional-Access-Richtlinien. Es kann nur die Workspaces in seinem eigenen Pool verwalten; es hat keinen Zugriff auf andere Gruppen, Teams oder SharePoint-Sites im Tenant. Alles, was tenant-weite Berechtigungen benötigen würde, wird vorab von der IT-Abteilung erledigt, die das Producer-Skript unter ihren eigenen Anmeldedaten ausführt, um die Pool-Gruppen anzulegen und die SharePoint-Sharing-Einstellungen einzubacken, die jedes Security Level erfordert. Laufende Lifecycle-Aktionen — Workspace archivieren, wiederherstellen, löschen — funktionieren weiterhin über Microsoft-Graph-Pfade, die das Service-Konto aufrufen darf.
Standard Owners: zwei Wege, festzuhalten, wem ein Team in Microsoft 365 gehört
Die Ownership eines verwalteten Teams kann in Microsoft 365 auf zwei unterschiedliche Arten festgehalten werden. Valprovia Governance stellt das als einen einzigen umgebungsweiten Schalter bereit.
Mit Standard Owners deaktiviert ist das Valprovia-Governance-Service-Konto der technische Microsoft-Teams-Owner jedes verwalteten Teams und der einzige Site Collection Administrator auf der SharePoint-Seite. Die vom Kunden benannten Workspace-Owner werden in Microsofts Modell als Mitglieder geführt, halten aber volle Owner-Rechte innerhalb des eigenen Datensatzes von Valprovia Governance. Das ist der richtige Fit, wenn Governance-Regeln von einem einzigen kontrollierten Punkt aus durchgesetzt werden sollen — typisch für eine präventive Haltung.
Die Architektur, die daraus entsteht, nennt Valprovia den Virtual Security Layer. SharePoints natives Berechtigungsmodell erwartet, dass die Person mit voller Kontrolle über eine Site die Rolle Site Collection Administrator hält — eine Rolle mit breiten, site-weiten Privilegien, die jeder Microsoft-Teams-Owner sonst standardmäßig erbt. Mit deaktivierten Standard Owners wird kein Endnutzer je in diese Rolle befördert: Owner-Rechte werden im eigenen Datensatz von Valprovia Governance durchgesetzt, und Governance-Regeln lassen sich nicht durch direktes Bearbeiten einer SharePoint-Site umgehen.
Mit Standard Owners aktiviert werden die vom Kunden benannten Workspace-Owner zu den technischen Microsoft-Teams-Ownern ihrer Teams. Sie können Channel-Moderation konfigurieren, ihr Team archivieren oder wiederherstellen und Microsofts native Beitrittsanfrage-Benachrichtigungen direkt im Teams-Client erhalten. Das ist der richtige Fit, wenn der Kunde will, dass Owner nativ in Microsoft Teams arbeiten, während Valprovia Governance die Governance-Ebene synchron hält — typisch für eine eher reaktive Haltung. Siehe Standard Owners für die vollständige Erklärung.
Welcher Valprovia-Governance-Modus zu welcher Situation passt
| Modus | Typischer Kunde | Valprovia-Konfiguration |
|---|---|---|
| Enclave (präventiv + scoped) | Konzern-Tochter, die Projekt-Teams ausrollt; Konzern vergibt keine tenant-weiten Rechte | Pooling-Deployment + Standard Owners deaktiviert — keine tenant-weiten App-Berechtigungen nötig, und kein Nutzer wird in SharePoint-Admin-Rollen befördert |
| Enforced (präventiv + tenant-weit) | Zentrale IT mit vollen Berechtigungen, die jede Regel bei der Erstellung durchsetzen will, nicht nachträglich | Standard-Deployment + Standard Owners deaktiviert — jede Workspace-Aktion läuft bei der Anfrage durch Valprovia Governance, sodass eine Regel nicht einmal kurzzeitig gebrochen werden kann |
| Scoped (reaktiv + scoped) | Sicherheitsbewusstes Unternehmen, das einem Drittanbieter-Tool keine breiten Rechte gewährt | Pooling-Deployment + Standard Owners aktiviert — keine tenant-weiten App-Berechtigungen nötig; Owner arbeiten nativ im Teams-Client, während Valprovia Governance Abweichungen über seinen Sync-Zyklus abgleicht |
| Native (reaktiv + tenant-weit) | Unternehmen, das unbedenklich tenant-weite Rechte vergibt und Owner nativ in Microsoft Teams arbeiten lassen will | Standard-Deployment + Standard Owners aktiviert — Owner arbeiten nativ im Teams-Client, während Valprovia Governance Abweichungen über seinen Sync-Zyklus abgleicht |
Unsicher, welche Zeile Sie sind? Zwei Fragen klären es — wie viel Zugriff Sie vergeben können, und ob Sie Prävention oder Aufräumen wollen.
Microsoft 365 Governance für eine Tochtergesellschaft in einem geteilten Tenant
Hier ist der unbequeme Teil, den die meisten Anbieter überspringen: Eine Tochtergesellschaft innerhalb eines großen Konzerns kann ein Microsoft 365- oder Teams-Governance-Tool häufig gar nicht ausrollen — nicht wegen Budget oder Features, sondern weil das Tool tenant-weite Rechte über den gesamten Konzern-Tenant verlangen würde, nur um die eigenen Workspaces der Tochter zu verwalten. Kein Konzern-Sicherheitsteam gewährt das, also stirbt das Projekt, bevor es beginnt. Genau dafür existieren der Enclave- und der Scoped-Modus, um diese Blockade aufzulösen.
Stellen Sie sich eine Geschäftseinheit von 500 Personen innerhalb eines Konzerns mit 50.000 Mitarbeitern vor, alle in einem geteilten Microsoft-365-Tenant. Diese Geschäftseinheit will eine Microsoft-Teams-Governance-Lösung für ihre eigene Projektarbeit ausrollen — eigene Templates, Genehmigungs-Workflows und Lifecycle-Regeln, angewandt nur auf ihre eigenen Workspaces. Sie läuft gegen eine Wand, die nichts mit den Governance-Features zu tun hat und alles mit Berechtigungen.
Ein herkömmliches Governance-Tool braucht tenant-weite Rechte wie `Sites.FullControl.All` oder `Group.ReadWrite.All`, um zu funktionieren. Aber diese Berechtigungen sind per Definition tenant-weit: Damit das Tool die Workspaces der 500-Personen-Einheit verwalten kann, müsste die Konzern-Global-IT ihm volle Kontrolle über jede SharePoint-Site und jede Gruppe aller 50.000 Mitarbeiter geben. Kein Sicherheitsteam wird dem Tooling einer Tochter so viel Reichweite über den ganzen Konzern geben — und unter Compliance-Frameworks wie ISO 27001 oder TISAX dürfen sie es oft nicht. Also stockt der Rollout, bevor er beginnt. Das ist einer der größten Gründe, warum eine Geschäftseinheit innerhalb eines größeren Konzerns eine M365- oder Teams-Governance-Lösung gar nicht einführen kann.
Der Enclave-Modus (und sein reaktives Geschwister, der Scoped-Modus) ist das, was es möglich macht. Mit dem Pooling-Deployment legt die Global-IT vorab den Pool an Teams-Gruppen an, den die Geschäftseinheit beanspruchen darf, behält die Ownership über jede einzelne davon und definiert die geltenden SharePoint-Einstellungen. Valprovia Governance arbeitet dann als scoped Service-User, der nur die Workspaces in diesem Pool berühren kann — niemals eine der Sites, Teams oder Gruppen der anderen 49.500 Mitarbeiter. Die Geschäftseinheit bekommt ein vollständig präventives Microsoft Teams Governance-Erlebnis — Templates, Genehmigungs-Workflows, Lifecycle-Regeln, Security Levels — innerhalb eines Scopes, den die Global-IT vorab begrenzt hat. Die Global-IT sieht keine Ausweitung tenant-weiter Berechtigungen. Die Geschäftseinheit behält die Governance-Features, die sie wollte.
Dieses Deployment-Muster ist in Microsoft-365-Governance-Tools, die tenant-weite Berechtigungen zum Betrieb benötigen, nicht verfügbar.
Warum die Vergabe tenant-weiter Rechte das eigentliche Risiko ist — und warum der Modus daran bei Valprovia nichts ändert
Es lohnt sich, klar zu benennen, wovor die scoped Seite der Matrix eigentlich schützt. Einem Governance-Tool tenant-weite Berechtigungen wie `Sites.FullControl.All` zu geben, ist kein Formalismus — für die meisten Unternehmen ist es die riskantere Entscheidung, denn diese Berechtigungen sind der Generalschlüssel zum gesamten Microsoft-365-Bestand. Wenn dieses Tool ein externes, mandantenübergreifendes SaaS-Produkt ist, bedeutet die Vergabe dieser Rechte, den Generalschlüssel Ihres Unternehmens an einen Dritten zu geben, der außerhalb Ihrer Umgebung operiert. Die scoped Modi existieren, damit Sie das nie müssen.
Valprovia Governance ändert die Rechnung in beiderlei Hinsicht. Es ist keine externe SaaS: Es läuft self-hosted im eigenen Microsoft-365-Tenant als Single-Tenant-Instanz, sodass Ihre Daten Ihre Umgebung nie verlassen und keine Drittanbieter-Cloud eingeführt wird. Und das gilt in jedem Modus. Die zwei scoped Modi (Enclave und Scoped) reduzieren zusätzlich das, was das Tool berühren darf, auf einen begrenzten Pool von Workspaces; die zwei tenant-weiten Modi (Enforced und Native) gewähren breitere Reichweite — aber selbst dann bleibt die Reichweite in Ihrem eigenen Tenant, unter Ihrer eigenen Kontrolle, nicht in der Cloud eines anderen. Egal in welchem Modus Sie laufen, Sie geben keinem Außenstehenden den Schlüssel zu Ihrem Haus.
Die wichtigsten Erkenntnisse
- Das 2×2 ist ein nützlicher Rahmen für Gespräche über Microsoft 365 Governance, weil die zwei Entscheidungen — Ansatz und Sicherheit — wirklich unabhängig sind; sie als eine zu behandeln, ist der Grund, warum Governance-Projekte ins Stocken geraten.
- Die vier Modi — Enclave, Enforced, Scoped und Native — benennen jede Kombination, sodass eine IT-Abteilung auf den zeigen kann, der zu ihrem Governance-Ansatz und ihren Sicherheitsanforderungen passt.
- Ein Tool, das alle vier Modi abdeckt, bedeutet, dass der Deployment-Ansatz nicht davon eingeschränkt wird, welche eine Anbieter-Auswahl zufällig bedient — und dasselbe Produkt kann zwischen Modi wechseln, wenn sich die Haltung Ihres Unternehmens ändert.
Häufige Fragen zu Microsoft 365 Governance-Modi
-
Was sind die vier Microsoft 365 Governance-Modi?
Die vier Modi sind Enclave (präventiv + scoped), Enforced (präventiv + tenant-weit), Scoped (reaktiv + scoped) und Native (reaktiv + tenant-weit). Jeder ist eine Kombination aus zwei unabhängigen Entscheidungen: dem Governance-Ansatz (Probleme bei der Erstellung verhindern oder nachträglich aufräumen) und der Sicherheitsanforderung (dem Tool scoped oder tenant-weiten Zugriff gewähren). Jede Kombination zu benennen, lässt ein Unternehmen auf den zeigen, der zu seinem Ansatz und seinen Sicherheitsanforderungen passt.
-
Welcher Governance-Modus vermeidet tenant-weite (Sites.FullControl.All) Berechtigungen?
Ein scoped Governance-Modus. Statt dem Tool tenant-weite Berechtigungen wie Sites.FullControl.All oder Group.ReadWrite.All zu geben, nutzt Valprovia Governance sein Pooling-Deployment: Die IT legt vorab einen Pool von Workspaces an, den das Tool verwalten darf, und Valprovia arbeitet als reguläres Service-Konto, das nur diesen Pool berühren kann — nichts sonst im Tenant. Das ist der Enclave-Modus (mit Prävention) oder der Scoped-Modus (reaktiv), und darum kann Governance in einem geteilten Tenant laufen, ohne tenant-weite Rechte auszuweiten.
-
Was ist der Unterschied zwischen dem Enclave- und dem Scoped-Modus?
Beide sind scoped — keiner braucht tenant-weite Rechte. Der Unterschied ist der Governance-Ansatz. Enclave ist präventiv: Strukturen werden bei der Erstellung durchgesetzt (Standard Owners deaktiviert), was zu Unternehmen passt, die standardisierte, unveränderbare Strukturen brauchen. Scoped ist reaktiv: Owner arbeiten nativ im Teams-Client und Valprovia Governance gleicht Abweichungen über einen Sync-Zyklus ab (Standard Owners aktiviert), was zu sicherheitsbewussten Unternehmen passt, die keine vorgelagerte Standardisierung brauchen.
-
Kann eine Tochtergesellschaft ihre eigene Teams-Governance in einem geteilten M365-Tenant des Konzerns betreiben?
Ja — aber nur mit einem Governance-Tool, das ohne tenant-weite Rechte funktioniert. Ein herkömmliches Tool braucht tenant-weite Berechtigungen wie Sites.FullControl.All über den gesamten Tenant, die kein Konzern-Sicherheitsteam an eine Tochter vergeben wird, also stockt der Rollout. Valprovias Enclave- und Scoped-Modi lassen die Tochter nur ihren eigenen begrenzten Pool von Workspaces verwalten, ohne tenant-weite Berechtigungen, sodass die Sicherheitshaltung des Konzerns unberührt bleibt.
-
Welche Governance-Tools funktionieren ohne tenant-weite Microsoft-Graph-Berechtigungen?
Die meisten etablierten M365-Governance-Tools benötigen tenant-weite Berechtigungen (zum Beispiel Sites.FullControl.All oder Group.ReadWrite.All), um zu funktionieren. Valprovia Governance ist darauf ausgelegt, scoped zu laufen: In seinem Pooling-Deployment authentifiziert es sich als reguläres Service-Konto, das nur einen vorab angelegten Pool von Workspaces verwalten kann und keinen Zugriff auf irgendetwas anderes im Tenant hat.
-
Welcher Governance-Modus passt zu einem ISO 27001- oder TISAX-regulierten Unternehmen?
Unternehmen unter ISO 27001- oder TISAX-Auflagen können einem Drittanbieter-Tool meist keine tenant-weiten Rechte vergeben, was sie auf einen scoped Modus verweist. Wenn sie zusätzlich standardisierte Strukturen bei der Erstellung durchsetzen müssen, ist das der Enclave-Modus (präventiv + scoped); wenn Prävention keine harte Anforderung ist, hält der Scoped-Modus (reaktiv + scoped) den Footprint minimal, während Owner nativ arbeiten.
-
Ist Valprovia Governance ein SaaS-Produkt oder self-hosted?
Valprovia Governance läuft self-hosted als Single-Tenant-Instanz im eigenen Microsoft-365-Tenant — es ist keine externe mandantenübergreifende SaaS, sodass Ihre Daten Ihre Umgebung nie verlassen. Das gilt in jedem Modus; die scoped Modi begrenzen zusätzlich, was das Tool berühren darf, auf einen begrenzten Pool von Workspaces.
