Microsoft 365 governance inrichten
Wat governance in Microsoft 365 werkelijk is, waarom het zo vaak spaak loopt, en in welke volgorde je het aanpakt zodat het houdt.
In veel groeiende organisaties draaien er drie Teams-kanalen voor hetzelfde project, elk met een andere eigenaar en net iets andere bestanden. Ergens staat een SharePoint-site waarvan niemand nog kan zeggen wie er toegang heeft. En er is een account van een medewerker die twee jaar geleden vertrok en dat vanochtend nog een keer inlogde. Wie verantwoordelijk is voor Microsoft 365 in een organisatie die groeit, herkent dit rijtje meteen.
Het zijn geen incidenten. Het is wat er gebeurt als een platform jarenlang meegroeit zonder dat iemand de afspraken heeft vastgelegd. Microsoft 365 is gebouwd om mensen te laten samenwerken zonder dat ze op IT hoeven te wachten, en precies die kracht wordt na verloop van tijd het probleem. Governance is het antwoord daarop. Op deze pagina leggen we uit wat het werkelijk inhoudt, waarom het zo vaak misgaat en in welke volgorde je het aanpakt zodat het standhoudt.
Wat governance in Microsoft 365 werkelijk betekent
Governance klinkt als een beleidsstuk dat in een la verdwijnt, terwijl het in Microsoft 365 iets heel concreets is. Het is het geheel van afspraken, processen en technische instellingen die samen bepalen hoe een organisatie het platform gebruikt. Wie mag een Team of een site aanmaken. Waar hoort welke informatie thuis en hoe lang blijft die bewaard. Wie heeft toegang tot wat, en hoe weet je volgende maand nog steeds dat dat klopt. Wat gebeurt er met de gegevens en de accounts van iemand die uit dienst gaat.
Het bijzondere is dat de middelen om die vragen te beantwoorden er meestal al zijn. In vrijwel elke Microsoft 365-licentie zit meer besturing dan een organisatie benut. Conditionele toegang, gevoeligheidslabels, bewaarbeleid en toegangsbeoordelingen staan klaar in de omgeving en wachten tot iemand ze inricht. Governance draait om het benutten van wat er al is, en om het vastleggen van hoe je dat doet. Nieuwe software is er zelden voor nodig.
We merken dat het onderwerp pas gaat leven op het moment dat we het aan die vragen ophangen in plaats van aan een definitie. Een directeur die niet kan achterhalen wie er bij de jaarcijfers kan, heeft geen behoefte aan een verhandeling over informatiebeheer. Die wil weten hoe de toegang weer klopt en hoe dat zo blijft. Vanuit die vragen wordt governance een praktische inrichting en geen papieren oefening.
Waarom het meestal misgaat
De wildgroei is bijna nooit het gevolg van onwil of onkunde. Ze ontstaat doordat het onderwerp nooit structureel is opgepakt terwijl de organisatie doorgroeide. Neem een productiebedrijf dat in vijf jaar van veertig naar driehonderd medewerkers gaat. Microsoft 365 groeit al die tijd organisch mee. Een projectleider maakt snel een Team aan voor een klus die een paar weken zou duren en twee jaar later nog draait. Een afdeling zet een eigen SharePoint-site op omdat dat op dat moment het handigst was. IT lost per geval op wat er binnenkomt, zonder de tijd om de omgeving als geheel te ontwerpen. Elk van die keuzes was op zichzelf logisch, en bij elkaar leveren ze een omgeving op die niemand nog kan overzien.
Het verschil zit in het moment waarop je het oppakt. Doe je het achteraf, dan ben je aan het opruimen: je reconstrueert wie waar toegang toe heeft, je zoekt uit welke sites nog in gebruik zijn en je probeert bewaartermijnen te herstellen op data die al jaren rondzwerft. Doe je het vooraf, dan ben je aan het ontwerpen: je legt vast hoe een Team ontstaat, waar informatie hoort en wanneer die verdwijnt, nog voordat de eerste site wordt aangemaakt. Opruimen kost altijd meer dan ontwerpen. Daarom zien we governance het liefst als de manier waarop je de omgeving vanaf het begin inricht, en niet als een schoonmaak achteraf.
De volgorde die uitmaakt
Hier zit de kern. Governance in Microsoft 365 werkt alleen als je de lagen in de juiste volgorde aanpakt, en die volgorde is niet vrijblijvend. We werken vanuit een vaste opbouw van zes lagen die op elkaar rusten, van identiteit en toegang onderaan tot de governance van Copilot bovenaan. Grofweg zijn dat drie bewegingen: eerst de architectuur, dan de toetsing aan kaders, dan het doorlopende toezicht.
Het begint bij identiteit en toegang. Zolang niet vaststaat wie iemand is en wat die persoon mag bereiken, heeft de rest geen betekenis. Daarop volgt de informatie- en rechtenstructuur: waar informatie thuishoort en hoe rechten logisch zijn opgebouwd, zodat toegang volgt uit iemands rol en niet uit een reeks losse uitzonderingen. De derde laag is gegevensbescherming en levenscyclus, waar we bepalen hoe informatie wordt beschermd en hoe data geordend verdwijnt als ze haar tijd heeft gehad. Deze drie lagen samen vormen de architectuur. Pas als die staat, heeft toetsing aan kaders als NIS2 of ISO 27001 zin, en pas daarna kun je zinvol monitoren of het in de praktijk klopt. Copilot-governance is het sluitstuk bovenop, want een AI die door je omgeving leest is alleen zo veilig als de toegangsstructuur eronder.
Draai je die volgorde om, dan bouw je op een basis die het gewicht niet kan dragen. Monitoring op een omgeving zonder heldere rechtenstructuur levert een dashboard vol ruis op waar niemand naar handelt. Toetsen aan NIS2 terwijl je niet kunt aantonen wie waar toegang toe heeft, is een momentopname zonder waarde. En Copilot loslaten op een omgeving waarin toegang nooit is opgeschoond, betekent dat het model documenten naar boven haalt die mensen nooit onder ogen hadden mogen krijgen. Automatisering is vermogen, en vermogen op een wankele basis versnelt de chaos in plaats van het werk.
Die afhankelijkheid tussen de lagen is de reden dat we zelden in stukken knippen wat een klant het liefst los zou oppakken. Een organisatie die vraagt om enkel Copilot uit te rollen, vraagt in feite om de bovenste laag zonder de vijf eronder. We raden dat af, omdat we weten waar het op uitloopt: een indrukwekkende demo, gevolgd door het eerste incident waarin iemand via een simpele vraag bij informatie komt die niet voor hem bedoeld was. Die volgorde is precies wat het resultaat laat standhouden. Daarom beginnen we altijd onderaan, bij identiteit en toegang, en werken we laag voor laag omhoog.
Wat we concreet inrichten
In de onderste laag richten we identiteitsbeheer in via Microsoft Entra ID. Daar leggen we vast wie toegang heeft tot de omgeving en onder welke voorwaarden. Conditionele toegang maakt van aanmelden een afweging: het apparaat, de locatie en het risico van een poging bepalen mee of iemand binnenkomt. Zo wordt toegang een bewuste beslissing van het systeem in plaats van een deur die altijd openstaat.
De laag daarboven gaat over informatie en rechten. We ontwerpen de structuur van Teams en SharePoint zo dat informatie een logische plek heeft en dat rechten meebewegen met rollen. Iemand krijgt toegang omdat die een functie vervult, en verliest die toegang zodra de functie verandert. Dat voorkomt de stapeling van uitzonderingen die een omgeving op termijn onbeheersbaar maakt.
Voor gegevensbescherming en levenscyclus gebruiken we Microsoft Purview. Daarmee classificeren en labelen we informatie naar gevoeligheid, stellen we bewaartermijnen in en zorgen we dat gegevens verdwijnen wanneer ze niet langer nodig zijn. Data die er niet meer is, kan ook niet lekken. Bij elk onderdeel beschrijven we wat het oplost en niet welke instelling waar staat: de configuratie is vakwerk dat achter de schermen hoort, het resultaat is een omgeving die te overzien en te verantwoorden is.
Deze onderdelen grijpen in elkaar. Een gevoeligheidslabel uit Purview heeft pas betekenis als de identiteiten in Entra ID kloppen, en een rechtenstructuur houdt alleen stand als er een proces achter zit dat toegang intrekt zodra iemand van rol wisselt. We richten de techniek daarom in als een samenhangend geheel, waarin elke laag de laag eronder veronderstelt en losse knoppen zelden op zichzelf staan.
Waaraan we toetsen
Zodra de architectuur staat, leggen we die naast de kaders die voor de organisatie gelden. De AVG stelt eisen aan de omgang met persoonsgegevens. NIS2 verlangt van een groeiende groep organisaties dat ze aantoonbaar grip hebben op toegang, continuïteit en incidenten. De EU AI Act stelt regels aan het gebruik van AI, wat direct raakt aan de manier waarop je Copilot inzet. Waar het nodig is, toetsen we de inrichting aan ISO 27001, het internationale kader voor informatiebeveiliging.
Toetsen is iets anders dan certificeren. Bij een toetsing leggen we de omgeving naast een kader en maken we zichtbaar waar die aansluit en waar nog werk ligt. Een certificering is een formeel traject met een externe auditor en een uitgereikt certificaat. Wij zorgen dat een organisatie klaar is voor dat gesprek, zodat een audit een bevestiging wordt en geen verrassing. Voor het meten van die readiness gebruiken we Compliance Compass, dat een Microsoft 365-omgeving geautomatiseerd doorlicht tegen kaders als NIS2, ISO 27001, de AVG en de AI Act.
Die readiness is geen eenmalige uitkomst. Kaders veranderen, de omgeving verandert en mensen wisselen van rol. Daarom bouwen we de toetsing zo in dat een organisatie op elk moment kan laten zien hoe ze ervoor staat, in plaats van dat pas te ontdekken op het moment dat een klant of een toezichthouder ernaar vraagt.
Van analyse naar traject
In de praktijk is dit een traject. We brengen de bestaande omgeving in kaart, ontwerpen de zes lagen in samenhang en voeren ze door in een tempo dat de organisatie kan bijhouden. Het M365 Blueprint is daarbij het vehikel: het legt de opbouw vast, van identiteit en toegang tot de governance van Copilot, zodat de keuzes navolgbaar zijn en de omgeving na oplevering te beheren blijft. Wil je zien hoe die aanpak er voor jouw situatie uitziet, lees dan meer over onze dienst governance, compliance en security of neem contact op voor een kennismaking.
Governance op orde krijgen
Een gesprek van een half uur, vrijblijvend. We luisteren, kijken mee met je omgeving en geven je een helder beeld van waar je staat en wat de eerste stap is.
PLAN EEN KENNISMAKING