De klant is eindverantwoordelijk voor de interne beleidsregels, de acceptatie van risico’s en de goedkeuring van herstelmaatregelen met bedrijfsimpact. De IT-partner voert de technische monitoring en eerste beoordeling uit, onderzoekt afwijkingen en bereidt herstelvoorstellen voor. Wie ontwerp- en configuratietaken uitvoert, moet vóór de livegang expliciet worden vastgelegd, naast de bevoegdheid om over beleid, uitzonderingen en herstel te besluiten.
Kort samengevat: beheer van Microsoft 365-configuratiedrift
Effectief driftbeheer na de livegang vraagt om een actuele, goedgekeurde referentietoestand en een duidelijke overdracht van technische signalering naar bestuurlijke besluitvorming.
- Een afwijking is pas goed te beoordelen wanneer actieve instellingen worden getoetst aan een vastgelegde, goedgekeurde uitgangstoestand en aan geautoriseerde wijzigingen.
- Monitoring, technische analyse en herstelvoorstellen zijn andere taken dan het bepalen van beleid, het accepteren van restrisico en het goedkeuren van ingrijpende maatregelen.
- Tijdelijke uitzonderingen hebben opvolging nodig: zonder een vastgelegd eindmoment en herbeoordeling kunnen zij ongemerkt onderdeel van de reguliere configuratie worden.
- Proactieve detectie moet apart zijn afgesproken van reactieve ticketafhandeling, met aandacht voor controle-relevante instellingen en herkenbare klantvarianten.
- Automatisch herstel past wanneer terugdraaien geen relevante bedrijfsimpact heeft; als samenwerking of een zakelijk project kan worden geraakt, is eerst een expliciet besluit nodig.
- Periodieke gezamenlijke beoordeling en vastlegging houden afwijkingen, open besluiten en geaccepteerde uitzonderingen bestuurlijk traceerbaar.
Leg de rolverdeling vast voordat drift een open vraag wordt
Na de livegang ontstaat eigenaarschapsverwarring meestal niet doordat niemand technisch kan ingrijpen, maar doordat een afwijking tegelijk een technische én een bestuurlijke vraag oproept. Een beheerpartij kan een wijziging signaleren, de afwijking onderzoeken en een herstelvoorstel voorbereiden. Daarmee is nog niet bepaald of de instelling zonder verdere afweging mag worden teruggezet. Die beslissing raakt de interne regels van de organisatie en de aanvaardbaarheid van de gevolgen van herstel.
Een bruikbare rolverdeling maakt daarom onderscheid tussen uitvoering en besluitvorming. De IT-partner kan technische monitoring uitvoeren, een eerste beoordeling doen en beschrijven welke herstelactie mogelijk is. De klant houdt het eigenaarschap over het beleid waaraan die instelling wordt getoetst, en over de acceptatie van een resterend risico wanneer herstel niet direct plaatsvindt. Dit voorkomt dat een technische melding stilzwijgend verandert in een beleidsbesluit dat niemand formeel heeft genomen.
Die grens werkt ook twee kanten op. De klant hoeft niet iedere technische afwijking zelf te analyseren voordat deze kan worden beoordeeld. Tegelijk kan de IT-partner niet uit een brede beheeropdracht afleiden dat iedere afwijking automatisch mag worden hersteld. De opdracht voor monitoring en triage moet dus naast de bevoegdheid voor besluiten bestaan, niet in plaats daarvan. Voor de bredere verdeling van taken rond beheer kan ook Microsoft 365-beheer als vertrekpunt dienen.
Bij CloudSphere is de scheiding tussen technische monitoring, triage, herstelvoorstellen en klantbesluiten over beleid en risicoacceptatie het uitgangspunt voor deze taakverdeling. Bij iedere afwijking moet direct duidelijk zijn: wie onderzoekt, wie formuleert de opties, wie besluit en wie draagt een geaccepteerde uitzondering?
Een formeel, periodiek overleg tussen IT-partner en security officer houdt die verdeling levend na de livegang. Daar kunnen geconstateerde afwijkingen worden gelegd naast de risicobereidheid van de organisatie, in plaats van uitsluitend naast de vraag of een instelling technisch afwijkt. Zo krijgen terugkerende uitzonderingen, open herstelvoorstellen en besluiten die nog wachten op acceptatie een vaste plaats. Zonder zo’n ritme blijven technische opvolging en beleidsverantwoordelijkheid naast elkaar bestaan, terwijl juist hun overdracht bepalend is voor een werkbaar beheerproces.
Bronnen bij deze sectie: microsoft.com
Een tijdelijke uitzondering kan ongemerkt een blijvende afwijking worden
Een tijdelijke uitzondering verdient een andere behandeling dan een normale wijziging, juist omdat de bedoeling tijdelijk is. Denk aan een ad-hoc uitzondering op Conditional Access tijdens een storing, zodat het werk door kan gaan. Zonder expiratiedatum en signalering dat de uitzondering nog actief is, kan deze maanden deel blijven uitmaken van de tenantinstellingen.
Het risico zit dan niet in één ontbrekende handeling, maar in het ontbreken van een vastgelegde eindtoestand. Er is geen moment waarop iemand beoordeelt of de oorspronkelijke reden nog geldt, terwijl drift-alerting de blijvende afwijking evenmin opnieuw onder de aandacht brengt. In een ongunstig scenario kan een uitzondering die MFA uitschakelt bijdragen aan accountovername en laterale beweging. Dat maakt niet iedere tijdelijke uitzondering onveilig, maar onderstreept waarom afloop en herbeoordeling onderdeel van de wijziging moeten zijn.
De technische opvolging bestaat uit het vastleggen van wat is veranderd, waarom dit buiten de beoogde toestand valt en welk terugdraaien mogelijk is. Alleen wanneer dat terugdraaien de samenwerking merkbaar beperkt, is een expliciete klantgoedkeuring nodig. Een restrictieve configuratie afdwingen voordat de klant-securityverantwoordelijke die gevolgen heeft beoordeeld, kan een bedrijfsactiviteit raken.
Een proces rond tijdelijke uitzonderingen heeft daarom baat bij twee afzonderlijke controlevragen: is de uitzondering nog actief nadat de aanleiding voorbij is, en vraagt het verwijderen ervan een besluit vanwege de impact op samenwerking? Daarmee wordt voorkomen dat tijdelijkheid een aanname blijft en dat een technische partij onbedoeld mandaat krijgt voor een beperkende ingreep.
Bronnen bij deze sectie: microsoft365dsc.com, upguard.com
Zonder Golden State is niet vast te stellen wat drift is
Drift is alleen vast te stellen wanneer de goedgekeurde uitgangstoestand van de tenant vooraf is vastgelegd. De Golden State maakt de koppeling tussen interne controle-eisen en actieve Microsoft 365-instellingen toetsbaar: een detectie kan dan worden beoordeeld tegen een concrete referentie, in plaats van tegen een algemene verwachting over hoe de omgeving zou moeten zijn ingericht.
- Leg de Golden State vast voor de relevante tenant-instellingen. De baseline beschrijft de goedgekeurde actieve instellingen binnen Entra ID, Exchange, SharePoint en Intune. Daarmee is per instelling zichtbaar welke toestand als uitgangspunt geldt voor de vertaling van een interne controle naar de Microsoft 365-tenant.
- Classificeer drift aan de hand van autorisatie. Van configuratiedrift is sprake wanneer een actieve tenant-instelling afwijkt van de Golden State zonder geautoriseerd change request. Een instelling die anders staat dan de baseline is dus niet automatisch ongeautoriseerd: het gekoppelde change request bepaalt of de afwijking een goedgekeurde wijziging is of nader moet worden onderzocht. Zonder die koppeling kunnen klant en IT-partner dezelfde detectie verschillend duiden.
- Houd baseline en goedgekeurde standaard in beheer. In lijn met het doel van ISO/IEC 27001:2022 Annex A.8.9 vraagt configuratiebeheer om documentatie, monitoring en periodieke toetsing aan goedgekeurde standaarden. De Golden State blijft daarom een actuele referentie voor de actieve omgeving, niet alleen opleverdocumentatie. Documentatie legt vast wat is goedgekeurd; monitoring toont verschillen; periodieke toetsing controleert of baseline en goedgekeurde standaard nog op elkaar aansluiten.
Bronnen bij deze sectie: microsoft365dsc.com, upguard.com
Maak proactieve detectie en klantspecifieke uitzonderingen onderdeel van dezelfde opvolging
Behandel proactieve monitoring en reactieve ticketafhandeling als twee afzonderlijke onderdelen van het beheer. Daarmee blijft zichtbaar welke afwijkingen actief worden onderzocht en welke pas worden opgepakt nadat iemand een vraag of incident meldt.
- Bepaal wat reactieve ticketafhandeling wel en niet opvangt. Een ticketproces start bij een gemelde vraag, storing of wijzigingsverzoek. Het biedt geen dekking voor een controle-relevante configuratiewijziging die niemand opmerkt en daarom ook niet als ticket binnenkomt. Wie alleen reactief werkt, moet die grens expliciet maken; anders ontstaat de indruk dat alle afwijkingen automatisch onder beheer vallen.
- Leg proactieve monitoring als afzonderlijke scope vast. Proactieve monitoring richt zich op afwijkingen van de beheerde Microsoft 365-baseline, ook wanneer gebruikers geen probleem ervaren. De afspraak moet daarom niet alleen benoemen dát er wordt gemonitord, maar ook dat beleidsafwijkingen buiten het ticketkanaal worden gesignaleerd en opgevolgd. Zonder die afbakening kan een afwijking tussen de verwachtingen van klant en MSP blijven liggen.
- Toets de grens aan wijzigingen buiten het ticketkanaal. Service updates kunnen aanleiding zijn om te controleren of standaardinstellingen of deelopties nog aansluiten op de afgesproken baseline. Als proactieve detectie niet is overeengekomen, leidt zo’n verschil niet vanzelf tot een ticket of beoordeling. Daardoor kan een beleidsafwijking buiten beeld blijven totdat deze later in een controle wordt vastgesteld.
- Houd de MSP-baseline schaalbaar, met herkenbare klantvarianten. Een standaardbaseline ondersteunt beheersbaarheid over meerdere omgevingen. Klantspecifieke compliance-eisen kunnen echter een toegestane afwijking vragen. Die variant hoort niet als losse afspraak naast het beheerproces te bestaan, maar als herkenbare uitzondering in relatie tot de standaardbaseline. Zo blijft onderscheid mogelijk tussen een toegestane klantvariant en een afwijking die onderzoek of herstel vraagt, zonder dat iedere klantvariant de algemene beheerwijze onoverzichtelijk maakt.
Toets rolverdeling en monitoringsscope vóór de afwijkingen zich opstapelen
Open tickets bij bezwaar vanuit de business zijn vaak terug te voeren op taken die wel algemeen zijn besproken, maar niet operationeel zijn toegewezen. De onderstaande RACI-matrix vertaalt de eerder beschreven rolverdeling daarom naar concrete controlepunten: per taak wordt vastgelegd wat vooraf bekend moet zijn en welke instellingen daadwerkelijk binnen de monitoringsscope vallen. Het is geen universele standaardrolverdeling, maar een hulpmiddel om afspraken vóór de livegang toetsbaar te maken.
| Taak | Wat vooraf expliciet wordt vastgelegd | Waarom dit nodig is | Relatie met monitoringsscope |
|---|---|---|---|
| Beleid | Wie het interne beleid bepaalt waaraan instellingen worden getoetst. | De technische uitvoerder kan anders een afwijking herkennen zonder te weten welke beleidskeuze de organisatie eraan verbindt. | Alleen instellingen die aan een relevante controle zijn gekoppeld, hoeven structureel onderdeel van de scope te zijn. |
| Monitoring | Wie afwijkingen signaleert en de eerste beoordeling uitvoert. | Hiermee is duidelijk wie de technische opvolging start zodra een instelling afwijkt. | Volledige scanning van elk cosmetisch Microsoft 365-attribuut veroorzaakt signaalruis en alert fatigue. Een gerichte scope houdt aandacht beschikbaar voor controle-relevante beveiligingsinstellingen. |
| Herstelgoedkeuring | Wie een herstelactie goedkeurt wanneer die verder reikt dan technische uitvoering. | Een gedetecteerde afwijking verandert dan niet automatisch in een maatregel zonder duidelijk mandaat. | De gerichte scope helpt om herstelbesluiten te concentreren op afwijkingen met daadwerkelijke controlewaarde, in plaats van op cosmetische verschillen. |
| Bewijsvoering | Wie de gegevens rond afwijkingen en besluiten vastlegt. | De opvolging blijft controleerbaar wanneer zichtbaar is wie welke taak heeft uitgevoerd of goedgekeurd. | Een beperkte, relevante scope voorkomt dat bewijsvoering wordt overspoeld door meldingen zonder betekenis voor de afgesproken controles. |
Bronnen bij deze sectie: microsoft.com
Een ticket blijft open wanneer blokkeren wel technisch kan maar bestuurlijk vastloopt
Een open ticket is niet altijd een technisch probleem. Het kan het zichtbare gevolg zijn van een ontbrekend besluitpad: de beheerpartij kan een instelling blokkeren, maar de gevolgen voor een business unit maken duidelijk dat niemand heeft vastgelegd wie bij bezwaar beslist.
- De melding wordt gezien als een puur technische taak. Een drift-tool kan bijvoorbeeld ongeoorloofde self-service consent voor een externe AI-tool signaleren. De melding beschrijft een actieve afwijking, maar bepaalt niet hoe de organisatie de gevolgen van blokkeren wil wegen. Zonder gekoppelde analyse- en besluitrol krijgt het ticket wel een eigenaar voor onderzoek, maar niet voor de keuze.
- Businessweerstand stopt de technische opvolging zonder een volgend besluitmoment. Wanneer een business unit bezwaar maakt tegen direct blokkeren, kan dat erop wijzen dat de maatregel werkprocessen raakt. Dat bezwaar wordt pas een beheersprobleem als het ticket daardoor alleen vertraagt en niet automatisch naar een aangewezen beslisser gaat.
- Een onduidelijke escalatieroute laat de afwijking tussen partijen hangen. Als niet is vastgelegd waar een conflict tussen technische opvolging en bedrijfsbelang terechtkomt, blijven beide partijen wachten. De beheerpartij wacht op een besluit; de business unit verwacht mogelijk dat IT de afweging maakt. Het ticket blijft dan open zonder formele risicoacceptatie.
- De resterende afwijking krijgt geen formele status. De kernfout is niet dat blokkeren altijd de enige juiste actie is, maar dat geen keuze wordt geregistreerd: herstellen, tijdelijk toestaan onder voorwaarden, of een risico expliciet accepteren. Zolang die keuze ontbreekt, is de technische afwijking zichtbaar maar bestuurlijk onbehandeld.
Bronnen bij deze sectie: ncsc.nl
Wanneer is automatisch herstel te ingrijpend voor de business?
Automatisch herstel is niet per definitie passend of onpassend. De grens ligt bij de vraag of direct terugrollen alleen een technische afwijking herstelt, of tegelijkertijd een legitiem zakelijk project kan blokkeren zonder dat daar een expliciet besluit aan voorafging.
- Is auto-remediation altijd passend?
Nee. Direct terugrollen ondersteunt beleidsnaleving wanneer er geen relevante bedrijfsimpact aan het herstel verbonden is. Dezelfde actie kan een zakelijk project abrupt blokkeren wanneer de afwijkende configuratie daarvoor wordt gebruikt. Een technische hersteloptie is daarom niet in alle gevallen een grond voor onmiddellijke uitvoering. - Wat maakt een goedkeuringsworkflow hier anders dan een administratieve stap?
De workflow markeert welke herstelacties direct kunnen worden uitgevoerd en welke eerst beoordeling vragen vanwege hun impact op samenwerking. Zij maakt zichtbaar wie die gevolgen afweegt, zonder van de technische partij te verlangen dat deze zelf het bedrijfsrisico overneemt. - Betekent dit dat een afwijking onbeperkt mag blijven bestaan?
Nee. De afweging gaat tussen onmiddellijke beleidsnaleving en flexibiliteit in bedrijfssamenwerking, niet tussen opvolgen en negeren. Een goedkeuringsworkflow geeft de afwijking juist een pad naar een geregistreerde uitkomst: direct terugrollen, tijdelijk toestaan onder voorwaarden of verdere beoordeling van de gevolgen. - Welke vraag hoort bij een restrictieve herstelmaatregel?
Beoordeel of de maatregel een legitieme samenwerking of een zakelijk project plotseling belemmert. Als dat mogelijk is, past een goedkeuringsmoment tussen detectie en terugrollen. Als die impact niet speelt, kan direct herstel passend zijn.
Bronnen bij deze sectie: microsoft.com
Een beheermodel blijft toetsbaar wanneer afwijkingen en besluiten samen worden vastgelegd
De afronding van driftbeheer ligt in een vast overlegmoment waarin klant en IT-partner geconstateerde configuratieafwijkingen, risico’s en uitzonderingen gezamenlijk beoordelen én vastleggen. Een kwartaaloverleg kan daarvoor een bruikbare vorm zijn. De waarde zit niet in de frequentie op zichzelf, maar in een terugkerend moment waarop dezelfde onderwerpen niet opnieuw uit losse tickets, mailwisselingen of dagelijkse beheerafstemming hoeven te worden gereconstrueerd.
Dat overleg moet daarom ook een protocol opleveren: welke afwijkingen en uitzonderingen zijn behandeld, welke punten blijven open en welke status hebben zij na de beoordeling? Zo blijft de koppeling zichtbaar tussen een Microsoft 365-configuratie, de beleidscontrole waarop die betrekking heeft en de besluitstatus die daarbij hoort. Technische opvolging krijgt pas blijvende bestuurlijke samenhang wanneer afwijkingen, risico’s en uitzonderingen periodiek gezamenlijk worden geëvalueerd en geprotocolleerd. Zonder die terugkerende vastlegging blijven open afwijkingen en besluitstatussen verspreid in de dagelijkse uitvoering.
Dit artikel biedt geen juridisch advies. De toepasselijke verplichtingen hangen af van het doel, de functionaliteit, de gebruikerscontext en de risicoclassificatie van het systeem. Laat de concrete toepassing juridisch beoordelen vóór productiegebruik.