De klant blijft verantwoordelijk voor interne beleidsregels, data-eigenaarschap, risicoacceptatie en wettelijke compliance. De IT-dienstverlener kan binnen de afgesproken scope het technische ontwerp, de tenant-configuratie, monitoring en operationele uitvoering verzorgen; monitoring is alleen een verantwoordelijkheid wanneer baseline, rapportage, opvolging en overleg expliciet zijn overeengekomen.
Kort samengevat: verantwoordelijkheden voor Microsoft 365-beheer
Bij strikte compliance-eisen vraagt Microsoft 365-beheer om een aantoonbare scheiding tussen bestuurlijke besluiten en technische uitvoering, per workload en gedurende de hele beheerperiode.
- Vertaal interne normen naar concrete, beheerbare eisen en leg vast wie wijzigingen goedkeurt, uitvoert en beoordeelt.
- Maak van configuratiecontrole een contractuele dienst: zonder afgesproken baseline, opvolging en besluitmomenten is signalering van afwijkingen geen doorlopende beheertaak.
- Kies bewust tussen maatwerk voor eigen sector- of organisatie-eisen en een herbruikbare standaardinrichting; beide opties vragen expliciete rollen en acceptatiecriteria.
- Behandel toegestane afwijkingen als tijdelijke, formeel goedgekeurde besluiten met een eigenaar, einddatum en herbeoordeling.
- Houd functiescheiding intact: snelle technische uitvoering van toegangsrechten of wijzigingen mag de onafhankelijke goedkeuring niet vervangen.
Wanneer monitoring werkelijk binnen de Microsoft 365-dienst valt
Monitoring van configuratiedrift behoort niet vanzelf tot Microsoft 365-beheer. De taak ontstaat pas wanneer de actuele tenant-instellingen worden vergeleken met een overeengekomen baseline én wanneer is vastgelegd wie signalen beoordeelt, opvolgt en bespreekt. Zonder die referentie zegt een waargenomen instelling alleen wat er op dat moment in de tenant staat. Zij zegt niet of die instelling afwijkt van de gewenste situatie, een goedgekeurde uitzondering vormt of direct actie vraagt.
Een baseline maakt die beoordeling mogelijk. Geautomatiseerde controles kunnen actuele tenant-instellingen doorlopend vergelijken met de afgesproken uitgangspositie. Daardoor komen ongeautoriseerde of ad-hoc wijzigingen aan het licht als verschil tussen de baseline en de feitelijke inrichting. Microsoft Graph of CISA SCuBA kunnen daarbij als hulpmiddel dienen voor API-audits en geautomatiseerde analyse. De technische signalering is echter slechts één deel van de beheertaak. Er blijft een proces nodig dat bepaalt wie een afwijking ontvangt, welke informatie in de rapportage komt en in welk overleg een besluit of vervolgactie wordt bepaald.
Dat onderscheid heeft directe gevolgen voor de serviceafbakening. In een reactief break-fixcontract is herstel na een gemeld probleem het uitgangspunt. Daaruit volgt niet automatisch dat een provider continu naar afwijkingen zoekt, periodieke auditrapportages maakt of met de klant bespreekt welke afwijkingen openstaan. Ook een brede formulering als ‘beheer’ wijst deze activiteiten niet concreet toe. Een dienstverlener kan technisch in staat zijn om drift te signaleren, terwijl de opdracht geen doorlopende monitoring, rapportage of overlegmoment bevat.
Proactieve drift-monitoring vraagt daarom om een structureel servicepakket: een toetsbare baseline, afspraken over de controles, periodieke rapportage en een vast moment voor beoordeling. Een melding zonder toegewezen opvolging blijft slechts een technisch signaal.
De relevante contractvraag is dus of baseline, continue controle, rapportage en besluitoverleg gezamenlijk binnen de afgesproken dienst vallen. Voor de bredere dienstcontext kan Microsoft 365-beheer als vertrekpunt dienen, maar de feitelijke monitoringomvang blijft afhankelijk van de vastgelegde serviceafspraken.
Bronnen bij deze sectie: Secure Cloud Business Applications (SCuBA) Project
De klant houdt risicoacceptatie; de provider voert binnen scope uit
Het shared responsibility model verdeelt verantwoordelijkheden tussen het cloudplatform, de klant en eventueel de IT-dienstverlener. Microsoft beheert de onderliggende cloudinfrastructuur en platformdiensten; de klant bepaalt beleid, data-eigenaarschap en risicoacceptatie. Een provider kan binnen de overeengekomen opdracht technische beheertaken uitvoeren, maar neemt die bestuurlijke keuzes niet over.
De technische beheerrol voor een Microsoft 365-tenant verandert dus niet wie binnen de organisatie beslist over beleid, data en risico. De klant houdt de beleidsautoriteit, het data-eigenaarschap, de risicoacceptatie en de wettelijke compliance. Dat zijn bestuurlijke keuzes: zij bepalen welke eisen gelden en welke restrisico’s de organisatie aanvaardt.
Een IT-dienstverlener kan binnen een afgesproken scope wel het technisch ontwerp, de tenant-configuratie en de operationele uitvoering verzorgen. De provider vertaalt de overeengekomen eisen naar werkzaamheden in Microsoft 365, maar bepaalt niet zelfstandig welke risico’s acceptabel zijn of welke complianceverplichting voorrang krijgt. Voor een CIO is dat het verschil tussen technische uitvoeringscapaciteit inkopen en bestuurlijke verantwoordelijkheid uitbesteden.
Microsoft Purview Compliance Manager helpt om die grens zichtbaar te houden voor customer-managed controls. Door per maatregel actiehouders en documentatieverplichtingen vast te leggen, wordt duidelijk welke actie door een persoon of proces moet worden uitgevoerd en welke onderbouwing daarbij hoort. Platformfunctionaliteit kan een control ondersteunen, maar neemt geen intern beleidsbesluit of risicoacceptatie over.
De verdeling blijft controleerbaar wanneer de klant de norm en het aanvaarde risico vastlegt, terwijl de provider uitsluitend de overeengekomen technische werkzaamheden uitvoert.
Bronnen bij deze sectie: Shared responsibility in the cloud, Microsoft Purview Compliance Manager, ISO 27001 Annex A 5.23 Information Security for Use of Cloud Services
Van beleidsregel naar baseline: eigenaarschap per Microsoft 365-workload
Een interne beleidsregel wordt pas bestuurbaar in Microsoft 365 wanneer de weg van norm naar beheerhandeling uit afzonderlijke, toewijsbare stappen bestaat. De keten hieronder maakt per workload zichtbaar waar besluitvorming eindigt en technische uitvoering begint. CIS Microsoft 365 Foundations Benchmark en CISA SCuBA leveren daarbij gestandaardiseerde configuratiebaselines, waaronder Level 1 en Level 2, om technische verantwoordelijkheden per workload af te bakenen. Zij bepalen echter niet wie intern een wijziging goedkeurt of welk risico de organisatie accepteert.
- 1. Beleidsregel. De organisatie formuleert de interne norm waaraan zij wil voldoen. Hier ligt de beleidsautoriteit: de inhoud van de regel en de acceptatie van het bijbehorende risico zijn geen technische standaardinstellingen.
- 2. Functionele eis. De beleidsregel wordt vertaald naar een eis die technisch en operationeel te beheren is. Deze stap verbindt het normenkader, zoals ISO 27001 of NIS2, met een concrete verwachting voor de betreffende Microsoft 365-workload.
- 3. Technische baseline. De functionele eis krijgt een plaats in een afgesproken baseline. Conditional Access, Intune en Purview kunnen onderdelen van zo’n baseline zijn. Gestandaardiseerde baselines van CIS en CISA bieden referentiepunten voor de technische afbakening, zonder zelf de besluitrechten over te nemen.
- 4. Change management. Een wijziging aan de baseline loopt via een beheerd wijzigingsproces. Daardoor is herkenbaar dat de technische aanpassing voortkomt uit een besluit en niet uit een losstaande ingreep in de tenant.
- 5. Drift-monitoring en uitzonderingsbeheer. Geautomatiseerde monitoring controleert of de feitelijke inrichting afwijkt van de baseline. Als afwijken toegestaan is, wordt het behandeld als uitzondering met een afzonderlijke eigenaar, niet als onduidelijke status tussen beleid en uitvoering.
Bronnen bij deze sectie: CIS Microsoft 365 Foundations Benchmark, Secure Cloud Business Applications (SCuBA) Project
Standaardbaseline of maatwerk: welke afspraken dragen de beheerlast
De keuze tussen klantspecifieke governance en een gestandaardiseerde partner-baseline gaat niet alleen over de inhoud van controls. Zij bepaalt hoeveel vertaalwerk, documentatie en doorlopend beheer nodig zijn. In beide modellen moeten rollen, verantwoordelijkheden en acceptatiecriteria voor clouddiensten expliciet worden vastgelegd. Dat voorkomt dat werk rond beoordeling, aanpassing of acceptatie buiten de rolverdeling valt.
| Aspect | Klantspecifieke maatwerk-governance | Gestandaardiseerde partner-baseline |
|---|---|---|
| Uitgangspunt | De inrichting wordt afgestemd op unieke sectorregels van de organisatie. | De inrichting volgt een herbruikbare baseline die voor meerdere omgevingen toepasbaar is. |
| Beheerlast | Hoger, omdat aanvullende vertaling van regels, documentatie en beheer nodig is. | Kan schaalvoordelen bieden doordat dezelfde basisafspraken herhaalbaar zijn. |
| Procesaanpassing | De technische vertaling volgt sterker de bestaande werkwijze van de klant. | De klant kan eigen processen moeten aanpassen aan de werkwijze die de baseline veronderstelt. |
| Vastlegging | Rollen, verantwoordelijkheden en acceptatiecriteria leggen ook de extra organisatie-specifieke keuzes vast. | Rollen, verantwoordelijkheden en acceptatiecriteria maken duidelijk welke delen van de standaardbaseline worden geaccepteerd en wie afwijkingen behandelt. |
| Operationeel risico | Niet-toegewezen vertaal- en documentatiewerk vergroot de beheerlast wanneer maatwerk niet volledig is beschreven. | Een standaardbaseline past niet vanzelf bij bestaande klantprocessen wanneer benodigde aanpassingen onbenoemd blijven. |
Bronnen bij deze sectie: ISO 27001 Annex A 5.23 Information Security for Use of Cloud Services
Leg uitzonderingen vast als tijdelijke afwijking met een vaste evaluatie
Leg iedere toegestane afwijking van een Microsoft 365-baseline vast in een control register als een tijdelijk besluit, niet als een stille aanpassing van de standaardinrichting. Daarmee blijven de aanvraag, de uitvoering en het moment van herbeoordeling afzonderlijk zichtbaar. De geldigheidsduur is een organisatie- of contractafspraak en geen vaste eigenschap van Microsoft 365.
- Start met risicobeoordeling en klantgoedkeuring. Beschrijf welke beleidsregel of baseline afwijkt, waarom de afwijking wordt aangevraagd en welke risicoafweging eraan voorafgaat. Pas na formele goedkeuring door de klant krijgt de uitzondering een status in het register. Zo is ook later te herleiden welk besluit aan de afwijkende configuratie ten grondslag lag.
- Beperk de technische uitvoering tot de goedgekeurde afwijking. De provider vertaalt de goedkeuring naar een afgebakende technische wijziging in Microsoft 365. In het register hoort daarom naast de goedkeuring ook te staan welke configuratie of baseline-afwijking wordt uitgevoerd. De uitvoerende taak blijft daarmee gescheiden van het besluit om de afwijking toe te staan.
- Geef de uitzondering een einddatum. Neem een geldigheidsduur op die past bij de gekozen organisatie- of contractregel. De einddatum voorkomt dat een tijdelijke afwijking ongemerkt onderdeel wordt van de reguliere baseline. Bij verlenging is opnieuw beoordeling en vastlegging nodig, in plaats van een stilzwijgende voortzetting.
- Plan periodieke evaluatie vóór de einddatum. De evaluatie koppelt de actuele status terug aan de oorspronkelijke goedkeuring. Het register moet daarom duidelijk maken wanneer de volgende beoordeling plaatsvindt en of de afwijking wordt beëindigd, opnieuw beoordeeld of binnen een nieuwe termijn wordt voortgezet.
- Kies bewust hoe afwijkingen worden gevolgd. Continue geautomatiseerde drift-monitoring vraagt licentie-investeringen en kan wijzigingen doorlopend signaleren, afhankelijk van de ingestelde detectie en de mogelijkheden van de gebruikte tooling. Periodieke handmatige inspectie, bijvoorbeeld per kwartaal, is goedkoper maar laat tussen controlemomenten blinde vlekken. De keuze bepaalt hoeveel zicht de organisatie heeft op afwijkingen die na goedkeuring technisch veranderen of buiten de afgesproken afbakening raken.
Bronnen bij deze sectie: Secure Cloud Business Applications (SCuBA) Project
Twee vragen die een verantwoordelijkheidsmodel op scherp zetten
Twee vragen leggen bloot of de verdeling van verantwoordelijkheden ook werkt wanneer snelheid en beoordeling van een provider samenkomen.
- Kan een servicedesk gebruikersrechten direct toekennen?
Dat kan de afhandeling van een gebruikersverzoek versnellen, maar het zet functiescheiding onder druk wanneer dezelfde servicedesk het verzoek beoordeelt én het recht toekent. Dan is achteraf minder helder wie de toegang heeft goedgekeurd, op welke grond dat gebeurde en of de toekenning binnen het interne beleid viel. De servicedesk kan de technische uitvoering verzorgen, terwijl de formele goedkeuring bij een afzonderlijke interne rol blijft. Zo hoeft een aanvraag niet onnodig te blijven liggen, maar blijft zichtbaar welk besluit aan de wijziging voorafging. Voor Microsoft 365-controls is dat onderscheid relevant: snelle uitvoering mag niet betekenen dat de controle op toegangsrechten verdwijnt. - Welk aanvullend signaal is bruikbaar bij de beoordeling van een provider?
Aantoonbaar gecertificeerd personeel op het gebied van Microsoft Security, Compliance en Identity is een bruikbaar afzonderlijk signaal. Certificeringen zoals Information Protection and Compliance Administrator of Cybersecurity Architect maken zichtbaar dat relevante kennis in deze domeinen beschikbaar is. Zij zeggen echter niet op zichzelf wie beleidsbesluiten neemt, uitzonderingen goedkeurt, controles bewaakt of bewijsmateriaal verzamelt. Ook tonen zij niet aan dat de scheiding tussen goedkeuring en uitvoering in de dienstverlening is geregeld. Bij providerselectie ondersteunt certificering daarom de beoordeling van aanwezige expertise, maar vervangt zij geen concrete afspraken over taken, besluiten en vastlegging.
Een partnermodel blijft toetsbaar met register én vast overleg
Een ownershipmodel blijft na livegang toetsbaar wanneer het twee lagen combineert: een vooraf gedefinieerd RACI- en control register per Microsoft 365-workload én terugkerend overleg waarin de geregistreerde informatie tot besluiten leidt. Het register verdeelt ontwerp, implementatie, monitoring en goedkeuring contractueel. Daardoor kan per workload worden onderscheiden wie de inrichting ontwerpt, wie haar uitvoert, wie afwijkingen bewaakt en wie formeel een besluit neemt.
Die registratie alleen maakt de samenwerking nog niet operationeel. Een kwartaaloverleg koppelt rapportages over configuratiedrift, actieve beleidsuitzonderingen en audit-ready bewijslast aan een vast besluitmoment. De rapportage krijgt daarmee een functie in de besturing: afwijkingen worden niet alleen getoond, maar krijgen een eigenaar en een vervolg binnen de afgesproken rolverdeling. Ook actieve uitzonderingen blijven zichtbaar als tijdelijke besluiten die opnieuw aandacht vragen.
De monitoring- en opvolgafspraken uit de dienstafbakening bepalen vervolgens welke signalen in dit overleg thuishoren. Zo voorkomt een register dat openstaande afwijkingen alleen als terugkerende administratieve meldingen blijven bestaan.
Bij de beoordeling van een partnermodel is vooral van belang of de workloadgerichte rolverdeling aansluit op een vast overlegritme. Anders kunnen technische rapportages beschikbaar zijn zonder dat duidelijk is wie een open afwijking moet accepteren, herstellen of opnieuw laten beoordelen.
Bronnen bij deze sectie: Shared responsibility in the cloud, ISO 27001 Annex A 5.23 Information Security for Use of Cloud Services
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.