Kernpunten van dit artikel

Zonder interne technische eigenaar ontstaat vooral risico op de grenzen tussen leveranciers: alerts worden niet opgevolgd, besluiten blijven open en de klant moet onverwacht zelf de regie voeren.

• Leg in de dienstverlening niet alleen beschikbare expertise, maar ook proactieve opvolging, meetbare verplichtingen en periodieke controle van herstel vast.
• Maak bij incidenten expliciet wie een melding ontvangt, beoordeelt, doorzet en de organisatie informeert; een algemeen aanspreekpunt zonder opvolgplicht is onvoldoende.
• Houd eigendom en dagelijkse uitvoering gescheiden: externe partijen kunnen beheer uitvoeren, maar de zeggenschap over tenant, data, identiteiten en noodtoegang blijft bij de klant.
• Kies bewust wie de afstemming draagt wanneer Microsoft 365, back-up, monitoring, connectiviteit en support elkaar raken; meerdere leveranciers vragen om expliciete regie.
• Beperk externe beheerrechten, maar organiseer vooraf wie toegang en spoedwijzigingen mag goedkeuren zodat beveiliging geen onverwachte operationele blokkade wordt.
• Beoordeel leveranciers periodiek op hun rol, uitgevoerde beheeractiviteiten, aantoonbare resultaten en openstaande opvolgingen; documentatie en toegangen moeten overdraagbaar blijven bij een wisseling.

Leg eigenaarschap en overdraagbaarheid vast vanaf de eerste servicedag

Een afspraak op basis van losse uren of regie kan passend zijn voor afgebakende werkzaamheden, maar bevat niet vanzelf een verplichting om risico’s proactief te volgen of herstel periodiek te toetsen. Daar ligt de grens tussen beschikbaarheid van technische hulp en operationeel eigenaarschap. Als een externe partij uitsluitend reageert wanneer de organisatie een vraag stelt, blijft onduidelijk wie signalen volgt die nog niet tot een concrete melding hebben geleid. Ook periodieke hersteltests zijn dan niet automatisch onderdeel van de dienstverlening.

Een managed service kan die verantwoordelijkheid wel expliciet maken. De afspraak krijgt dan betekenis door vastgelegde KPI’s en responsverplichtingen: niet alleen wat een dienstverlener kan doen, maar ook welke beheeractiviteiten bij diens rol horen. Voor een organisatie zonder interne technische eigenaar is dat verschil zakelijk relevant. De directie hoeft niet zelf te interpreteren of een activiteit onder regulier beheer valt, als vooraf zichtbaar is wie die activiteit draagt en waarop de uitvoering wordt beoordeeld.

Maandelijks opzegbare dienstverlening vraagt om een tweede vorm van duidelijkheid. Flexibiliteit houdt alleen stand wanneer een volgende partij zonder interpretatieverlies kan overnemen. Daarom horen documentatie, tenant-eigenaarschap en back-upregie vanaf de eerste servicedag vast te liggen. Documentatie maakt zichtbaar welke informatie overdraagbaar moet zijn. Tenant-eigenaarschap houdt de zeggenschap over de omgeving bij de organisatie. Back-upregie bepaalt wie verantwoordelijk is voor de sturing rond die dienst, ook wanneer de feitelijke werkzaamheden extern worden uitgevoerd.

Deze punten zijn geen algemene contractonderhandeling, maar de basis voor beveiligingsverantwoordelijkheid in uitbesteed beheer. Een maandelijkse relatie is niet minder bruikbaar dan een meerjarige overeenkomst; zij verschuift alleen de nadruk naar continu aantoonbare kwaliteit en een nette overdracht. Wanneer eigendom en beheerinformatie pas bij beëindiging ter sprake komen, kan de organisatie afhankelijk blijken van kennis of toegang die buiten haar eigen bereik ligt. Een heldere afbakening van beheer maakt vanaf het begin zichtbaar welke informatie bij een wisseling beschikbaar moet blijven.

Bronnen bij deze sectie: cisecurity.org, cyber.gc.ca

Een SPOC zonder triageplicht laat securitymeldingen alsnog liggen

Een Single Point of Contact (SPOC) voorkomt pas vertraging wanneer die partij meer doet dan meldingen aannemen en doorsturen. Bij een securityalert moet vooraf vastliggen dat het aanspreekpunt de melding beoordeelt, bepaalt welke leverancier moet handelen en de escalatie in gang zet. Zonder die taken blijft een algemeen serviceloket vooral een doorgeefluik.

Dat wordt zichtbaar wanneer Microsoft 365, back-up, securitymonitoring en connectiviteit bij verschillende partijen liggen. Monitoringtools kunnen een alert versturen, terwijl iedere leverancier de oorzaak buiten het eigen werkgebied plaatst. Als niemand de eerste beoordeling en opvolging op zich neemt, blijft de melding liggen totdat de organisatie zelf de technische samenhang moet uitzoeken en partijen moet aansturen. Voor een bedrijf zonder interne technische regiehouder is een contactpersoon dus niet genoeg: er moet één partij zijn die bij een incident actief de volgende stap organiseert.

Leg daarom bij incidentmeldingen afzonderlijk vast wie ontvangt, beoordeelt, opschaalt en de organisatie informeert. Aantoonbare vakbekwaamheid van betrokken specialisten kan daarbij worden meegewogen, maar vervangt geen ingerichte incidentroute. Ook deskundige specialisten kunnen pas handelen wanneer duidelijk is wie de opvolging tussen leveranciers aanjaagt.

Bronnen bij deze sectie: europa.eu, cyber.gc.ca

Leveranciersbeheer blijft werk na de selectie

Leveranciersbeheer stopt niet bij contractondertekening. Voor Microsoft 365, back-up en aanverwante IT-diensten vraagt het om een vast kwartaalmoment waarop management kan vaststellen wat een externe partij beheert, wat aantoonbaar is uitgevoerd en welke afspraken nog openstaan.

• Classificeer IT-leveranciers. CIS Control 15 noemt expliciete classificatie als onderdeel van leveranciersbeheer. Neem daarom iedere partij die een rol heeft in Microsoft 365, back-up, connectiviteit of support op in één overzicht. Koppel de classificatie aan de dienst die de partij levert, zodat bij de kwartaalbespreking duidelijk is welke leverancier op welk onderdeel wordt beoordeeld.
• Maak security-eisen onderdeel van de overeenkomst. CIS Control 15 vraagt ook om contractuele borging van security-eisen. Bespreek per leverancier niet alleen de dienstverlening, maar ook welke rapportage en beoordeling daarbij horen. Een security responsibility matrix kan daarbij naast het contract worden gelegd: de rol die daarin staat, moet aansluiten op de afgesproken werkzaamheden en rapportageverplichtingen.
• Toets prestaties op vaste bespreekpunten. Gebruik elk kwartaal transparante rapportages over Microsoft Secure Score, patch-status en geverifieerde back-uphersteltests. Die rapportages maken zichtbaar wat is gemeten of bevestigd. Ze bewijzen niet op zichzelf dat patches zijn uitgevoerd, herstel is georganiseerd of opvolging plaatsvindt. Leg tijdens de beoordeling daarom vast welke partij de onderliggende beheeractiviteit uitvoert en welke punten nog opvolging vragen.

Bronnen bij deze sectie: cisecurity.org

In Microsoft 365 blijven data, identiteiten en rechten aan klantzijde

Uitbesteding van Microsoft 365-beheer verandert wie dagelijkse werkzaamheden uitvoert, maar niet waar de uiteindelijke verantwoordelijkheid in een SaaS-omgeving ligt. Voor gegevensbescherming, identiteiten, toegangsapparaten en rechtenbeheer blijft die verantwoordelijkheid volledig bij de afnemer of diens beheerpartner. De matrix moet daarom onderscheid maken tussen beslissingsbevoegdheid en de dagelijkse uitvoering van taken.

Dit onderscheid voorkomt een verkeerde verwachting: Microsoft 365 of een externe beheerpartij neemt niet automatisch alle keuzes over die horen bij data, identiteit, apparaten en rechten. Delegatie is mogelijk, maar werkt alleen wanneer de opdrachtgever kan aanwijzen wat gedelegeerd is en welke zeggenschap bewust bij de klant blijft. Exclusieve controle over break-glass accounts is daarbij een concrete toets: deze toegang blijft niet afhankelijk van een leverancier. Daardoor houdt de organisatie een eigen positie, ook als dagelijkse werkzaamheden bij een beheerpartner liggen.

De tabel is geen technische configuratiehandleiding. Zij maakt de bestuurlijke grens zichtbaar tussen eigendom en uitvoering. Wie beide begrippen in één kolom zet, maakt het lastig om bij een wijziging, beoordeling of wisseling van dienstverlener vast te stellen wie beslissingsbevoegdheid heeft. Een pagina over Microsoft 365-beheer kan de dienstverlening beschrijven, maar de matrix legt daarnaast vast welke verantwoordelijkheden de klant expliciet behoudt.

Bronnen bij deze sectie: cloudsecurityalliance.org, microsoft.com

Kies per component wie de leveranciersketen coördineert

Een security responsibility matrix kan per component laten zien waar de coördinatielast terechtkomt. Dat is nodig wanneer Microsoft 365, back-up, MDR, connectiviteit en support niet door dezelfde partij worden geleverd. Losse leveranciers kunnen scherpere afzonderlijke tarieven bieden. Daartegenover staat dat een organisatie zonder interne IT-capaciteit zelf de onderlinge afstemming en het risico op vingerwijzen draagt. Een totaalaanbieder kan die operationele belasting beperken, maar is geen automatische oplossing voor iedere verstoring. De kernvraag is steeds: wie coördineert de keten wanneer een onderwerp meerdere componenten raakt?

De tabel dwingt niet tot een voorkeur voor één model. Een multi-leveranciersmodel past wanneer de organisatie de bijbehorende regielast daadwerkelijk kan dragen. Voor een bedrijf zonder interne technische eigenaar verandert die afweging: de lagere prijs per afzonderlijke dienst zegt dan nog niets over de tijd en verantwoordelijkheid die nodig zijn om partijen op één lijn te krijgen. In een matrix staat daarom niet alleen wie een component levert, maar ook wie bij overlap coördineert.

Zo voorkomt de matrix dat de klant tijdens een grensoverschrijdende kwestie onverwacht technisch regisseur wordt. Een totaalaanbieder kan operationele belemmeringen verminderen doordat de regie op één plek ligt. Bij afzonderlijke leveranciers blijft die regierol even goed mogelijk, mits zij expliciet aan een partij is toegewezen en niet stilzwijgend bij de klant terechtkomt.

Bronnen bij deze sectie: cisecurity.org, cyber.gc.ca

Vertraagt streng toegangsbeheer externe IT-support?

Ja. Streng toegangsbeheer kan een wijziging door een externe consultant minder direct maken, maar de vertraging zit niet vanzelf in de techniek. Conditional Access, just-in-time beheer en GDAP-workflows beperken het aanvalsoppervlak doordat een externe partij niet onbeperkt met beheerrechten werkt. Daar staat tegenover dat toegang en wijzigingen afhankelijk worden van een vooraf ingerichte goedkeuring. Bij spoedwerk ontstaat vooral oponthoud wanneer niemand bevoegd is om die goedkeuring te geven, of wanneer niet duidelijk is welke toegang voor de gevraagde wijziging nodig is.

• Conditional Access: deze werkwijze stelt voorwaarden aan toegang. Voor externe support moet vooraf duidelijk zijn welke voorwaarden gelden en wie een uitzondering of benodigde toegang kan autoriseren.
• Just-in-time beheer: tijdelijke beheerrechten verkleinen de periode waarin een consultant toegang heeft. Dat werkt alleen zonder onnodige vertraging als de aanvraag, beoordeling en toekenning vooraf zijn georganiseerd.
• GDAP-workflows: ook hierbij is externe toegang gekoppeld aan een gestructureerd proces. Leg daarom vast wie toestemming geeft voor de benodigde rollen en wie bereikbaar is wanneer een wijziging niet kan wachten.

De praktische afweging is dus niet onbeperkte toegang tegenover stilstand. Beperkte toegang blijft werkbaar wanneer de autorisatieketen aansluit op het dagelijkse wijzigingswerk en op situaties waarin externe ondersteuning snel nodig is. Ontbreekt die voorbereiding, dan moet de consultant tijdens het werk eerst achterhalen wie mag beslissen. Dat maakt een noodzakelijke beveiligingsmaatregel alsnog een onverwachte blokkade voor de bedrijfsvoering.

De matrix wordt pas bruikbaar wanneer elke rol aan een partij hangt

Een leveranciersoverzicht wordt een bruikbare security responsibility matrix wanneer het niet alleen componenten en namen toont, maar per component ook concrete werkwoorden aan een benoemde partij koppelt. Voor Microsoft 365, back-up, MDR en connectiviteit gaat het dan om vijf afzonderlijke kolommen: adviseren, autoriseren, implementeren, bewaken en escaleren. Die kolommen maken zichtbaar dat betrokkenheid niet hetzelfde is als verantwoordelijkheid.

Adviseren betreft de partij die een oordeel of voorstel levert. Autoriseren wijst de partij aan die een besluit mag nemen. Implementeren maakt duidelijk wie het overeengekomen werk uitvoert. Bewaken benoemt wie de dagelijkse opvolging draagt. Escaleren legt vast wie een onderwerp doorzet zodra het de grens van een component, leverancier of gewone behandeling overschrijdt. Door deze handelingen apart te houden, verdwijnt de aanname dat een partij die iets implementeert ook automatisch mag beslissen, of dat een partij die adviseert ook de opvolging bewaakt.

Voor de organisatie zonder interne technische eigenaar maakt deze indeling vooral verborgen besluit- en opvolgtaken zichtbaar. Als bij back-up of connectiviteit geen partij in de kolom autoriseren staat, ligt het besluit nog open. Ontbreekt bij MDR of Microsoft 365 een bewakingspartij, dan is onduidelijk wie de voortdurende opvolging verzorgt. Een lege escalatiekolom laat zien dat de afhandeling van onderwerpen met meerdere leveranciers alsnog bij de klant kan belanden.

De matrix kan vooraf worden aangeleverd en worden gebruikt als toetsbaar overzicht van de verantwoordelijkheidsverdeling over deze componenten. In deze context betekent het Shared Responsibility Model dat verantwoordelijkheden voor besluiten, uitvoering, bewaking en escalatie tussen klant en leveranciers worden verdeeld en expliciet worden vastgelegd. Het vraagt niet om een algemene belofte over security, maar om namen naast taken. Daarmee wordt ook overdraagbaarheid eenvoudiger te beoordelen: bij een wisseling van leverancier is herkenbaar welke rol opnieuw toegewezen moet worden en welke rol bij de organisatie blijft.

De waarde van de matrix ligt daarmee in de bruikbaarheid tijdens regulier beheer én bij verstoringen: voor elke taak is zichtbaar wie handelt, wie beslist en wie anderen in beweging brengt.

Bronnen bij deze sectie: cloudsecurityalliance.org, microsoft.com