Waarom MSP Cloud Security van de ene op de andere dag niet meer werkte
De cloudbeveiliging van MSP's ging failliet toen cloudplatforms niet langer eenvoudige leveranciers waren, maar gedeelde verantwoordelijkheidsomgevingen werden die u actief moet beheren. ISO 27001 A.5.23 maakt die verschuiving expliciet door van u te verwachten dat u zelf bepaalt hoe u cloudservices selecteert, gebruikt en afdankt in overeenstemming met uw ISMS, in plaats van alleen te vertrouwen op certificaten van providers. Die verwachting weerspiegelt de formulering van ISO 27001:2022 A.5.23 en de gangbare richtlijnen voor cloudbeveiliging, die de nadruk leggen op gedefinieerde processen voor de aanschaf, het gebruik, het beheer en de afdanking van cloudservices in plaats van alleen te vertrouwen op garanties van providers, zoals benadrukt in het commentaar op de richtlijnen van ISO 27001 A.5.23.
Clouddiensten lieten uw MSP snel groeien, maar brachten ook hiaten in eigenaarschap, governance en bewijsvoering aan het licht die het oude leveranciersmodel nooit hoefde op te lossen. Wanneer klanten en auditors zich nu afvragen wie waarvoor verantwoordelijk is in de cloud, is "de provider doet dat" niet langer voldoende. A.5.23 concretiseert deze spanning door een gecontroleerde, gedocumenteerde aanpak van cloudgebruik te verwachten in plaats van ad-hoc platformkeuzes.
Cloud biedt MSP's alleen voordelen als de verantwoordelijkheid bewust wordt gedeeld en niet wordt overgenomen.
De cloud is uw oude 'leveranciers'-mentaliteit ontgroeid
Cloud is het idee ontgroeid dat je een contract kunt tekenen, een certificaat kunt vertrouwen en ervan uit kunt gaan dat de beveiliging stopt aan de rand van de provider. Voor MSP's dwingt A.5.23 je te erkennen dat identiteiten, configuraties en dagelijkse activiteiten op elk platform nu stevig binnen je verantwoordelijkheden vallen.
Veel MSP's behandelen cloudproviders nog steeds als traditionele leveranciers, en dat is precies waar A.5.23 tekortschiet. Jarenlang kon je een contract tekenen, certificeringen vertrouwen, er wat monitoring bovenop doen en zo doorgaan. Dat werkte toen cloud alleen nog maar e-mailhosting of een paar virtuele machines betrof.
Tegenwoordig draaien complete servicecatalogi op hyperscale platforms, waarbij uw engineers krachtige beheerdersrollen en automatiseringstools hebben die tientallen gebruikers tegelijk bedienen. In zo'n omgeving is "de leverancier beheert de beveiliging" niet meer waar. De cloudprovider beveiligt zijn infrastructuur en kernservices, maar u bepaalt identiteiten, configuraties, integraties en een groot deel van de operationele veerkracht. Klanten begrijpen dit steeds beter en verwachten dat u laat zien hoe gedeelde verantwoordelijkheden zijn gedefinieerd en hoe uw team deze controles dagelijks uitvoert.
A.5.23 is het punt waarop de standaard deze verschuiving expliciet aankaart. Verwacht wordt dat u overstapt van generieke leveranciersgarantie naar actief beheer van de manier waarop cloudplatforms uw diensten en klanten ondersteunen.
De verborgen complexiteit van uw huidige cloudstack
De verborgen complexiteit van uw cloudstack wordt pas duidelijk wanneer u deze opschrijft. Een korte, gerichte inventarisatie onthult meestal veel meer services, datastromen en beheerdersrollen dan u verwachtte. En dat is precies wat A.5.23 u wil laten zien en vervolgens doelbewust wil beheren.
De meeste MSP's ontdekken dat ze veel meer diensten aanbieden, op veel meer manieren, dan iedereen zich realiseert:
- Interne SaaS-hulpmiddelen voor samenwerking, ticketing, CRM en financiën.
- Openbare cloudplatformen die beheerde infrastructuur-, back-up-, monitoring- en beveiligingsdiensten mogelijk maken.
- Specifieke cloudtools die door individuele teams of engineers worden gekozen om specifieke problemen op te lossen.
Samen creëren deze services een web van datalocaties, beheerdersrollen, logs en faalmodi. Zonder centraal overzicht stapelen risico's zich ongemerkt op: één engineer beheert de wereldwijde administratie voor meerdere tenants, een "tijdelijke" SaaS-tool wordt bedrijfskritisch, een back-upservice is nog nooit getest op echte herstelscenario's. Een ISMS-platform zoals ISMS.online kan u helpen dat centrale overzicht te behouden, zodat de complexiteit niet verborgen blijft.
Om de verandering concreet te maken, is het handig om de oude leveranciersmentaliteit te vergelijken met de cloud governance die A.5.23 verwacht.
Een korte vergelijking laat zien hoe uw aanpak moet veranderen:
| Aspect | Oud leveranciersmodel | A.5.23 cloudbeheer voor MSP's |
|---|---|---|
| Weergave van aanbieder | “Een vertrouwde leverancier zorgt voor de beveiliging.” | “Werk samen aan een gedefinieerd model van gedeelde verantwoordelijkheid.” |
| Reikwijdte van de controle | Contract plus basismonitoring | Volledige levenscyclus: selectie, gebruik, wijziging, exit |
| Bewijs dat u bezit | Certificaten en contracten | Registers, risicoregistraties, matrices, levenscyclusartefacten |
| Eigendom binnen de MSP | Impliciet, persoonsafhankelijk | Expliciete rollen, runbooks en ISMS-integratie |
Als u uw situatie vanuit deze invalshoek bekijkt, wordt het gemakkelijker om te bepalen waar structuur nodig is in plaats van ad-hocoplossingen.
Waar klanten en auditors de scheuren blootleggen
Klanten en auditors leggen de gaten in uw cloudomgeving bloot door duidelijke vragen te stellen over services, data en verantwoordelijkheden. Hun vragen brengen vaak hiaten in eigenaarschap, levenscyclus en bewijsvoering aan het licht, lang voordat een inbreuk of uitval zich voordoet. Het beheren van risico's van derden en het volgen van de naleving door leveranciers werd door 41% van de organisaties in de ISMS.online-enquête van 2025 genoemd als een van de grootste uitdagingen.
Veelvoorkomende vragen zijn:
- Welke clouddiensten gebruiken jullie namens ons en waar worden onze gegevens opgeslagen?
- Wie is verantwoordelijk voor back-up, identiteit, logging en configuratie op elk platform?
- Hoe controleert, monitort en verlaat u indien nodig cloudproviders?
- Hoe kunt u ons ondersteunen als wij willen stoppen met een bepaalde service?
Deze vragen laten zien waar uw huidige aanpak vaag is. Als uw antwoorden afhankelijk zijn van wie er in de vergadering aanwezig is, of vereisen dat iemand een controle uitvoert, is A.5.23 al een probleem. De controle verwacht dat u processen heeft voor het aanschaffen, gebruiken, beheren en beëindigen van cloudservices in overeenstemming met de gedefinieerde beveiligingsvereisten. Voor een MSP betekent dit de overstap van een geïmproviseerde cloudomgeving naar een gestructureerde omgeving die auditors en klanten kunnen testen.
In dit soort gevallen is het essentieel om een actueel register van cloudservices te hebben, gekoppeld aan risico's, verantwoordelijkheden en levenscyclusrecords. Het is dan niet langer een prettige bijkomstigheid, maar juist essentieel.
Demo boekenWat ISO 27001 A.5.23 werkelijk van u vraagt
ISO 27001 A.5.23 vraagt u om de cloud te behandelen als een gereguleerd servicelandschap met duidelijke regels, verantwoordelijkheden en bewijs, en niet als een losse verzameling tools en aanbieders. In de praktijk betekent dit dat u kunt aantonen hoe cloudservices worden geselecteerd, beheerd en beëindigd in overeenstemming met uw informatiebeveiligingsvereisten.
Uit het rapport 'State of Information Security 2025' blijkt dat klanten doorgaans van leveranciers verwachten dat zij zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG, Cyber Essentials, SOC 2 en opkomende AI-normen.
In de editie van 2022 stelt A.5.23 dat u processen moet opzetten en implementeren voor de aanschaf, het gebruik, het beheer en de beëindiging van cloudservices, in overeenstemming met uw eisen op het gebied van informatiebeveiliging. Deze formulering is consistent met de gepubliceerde controletekst in ISO 27001:2022 A.5.23 en met ondersteunende cloudrichtlijnen zoals ISO 27017 en ISO 27018, die allemaal de nadruk leggen op end-to-end governance van cloudservices in plaats van eenmalige leverancierscontroles. Een centraal ISMS-platform zoals ISMS.online kan dit werk beheersbaar maken door beleid, risico's, verantwoordelijkheden en registraties op één plek te bewaren.
Auditors zoeken doorgaans naar een duidelijke lijn tussen die controletekst en het daadwerkelijke beleid, de procedures en de registraties. Als u in uw eigen woorden kunt uitleggen wat A.5.23 voor uw bedrijf betekent, heeft u al een voorsprong op veel MSP's die uitsluitend op de formele bewoordingen vertrouwen.
Van één zin naar praktische doelstellingen
Het omzetten van A.5.23 in praktische doelstellingen betekent het opsplitsen van de formele formulering in een kleine set concrete, toetsbare verwachtingen waar u beheersmaatregelen en bewijsmateriaal op kunt baseren. Deze doelstellingen bieden u een kader om de beheersmaatregelen uit te leggen aan uw team en auditors. Interpretaties van cloudgerichte ISO 27001-professionals groeperen de vereisten van A.5.23 doorgaans in thema's zoals cloudbeleid, risico's en vereisten, gedeelde verantwoordelijkheid, levenscyclus en bewijsmateriaal. Deze aanpak wordt hier weerspiegeld.
In de praktijk verwacht A.5.23 dat u vijf dingen consistent doet en deze kunt bewijzen. Een nuttige manier om de controle te interpreteren, is door deze op te splitsen in vijf praktische doelstellingen:
- Cloudbeleid en -bereik – definieer wat ‘cloud’ voor uw organisatie betekent, welke services en data binnen het bereik vallen en wie nieuwe services kan adopteren.
- Risico en vereisten – cloudspecifieke risico’s identificeren, zoals multitenancy, gegevenslocatie en connectiviteit, en minimale beveiligings- en privacyvereisten vaststellen.
- Gedeelde verantwoordelijkheid – documenteren wie verantwoordelijk is voor de belangrijkste controles bij de provider, MSP en klant voor elk belangrijk platform en elke belangrijke service.
- Levenscyclus management – zorg dat de beveiliging niet alleen in contracten zit, maar ook in de selectie, onboarding, verandering, monitoring en exit van clouddiensten.
- Bewijs en verbetering – houd gegevens bij die aantonen dat deze processen werken en controleer deze wanneer platforms, klanten en regelgeving veranderen.
Samen maken deze doelstellingen van A.5.23 van een enkele zin een verzameling gewoonten. Ze bieden u ook een structuur om de controle in uw Verklaring van Toepasselijkheid en uw bredere ISMS in kaart te brengen. Door de doelstellingen, eigenaren en ondersteunende bewijsstukken vast te leggen in een systeem zoals ISMS.online, kunt u ze consistent houden naarmate diensten en standaarden zich ontwikkelen.
Hoe A.5.23 het oudere leveranciersmodel uitbreidt
A.5.23 breidt het oudere leveranciersmodel uit door te erkennen dat cloud een technische basis is, niet zomaar een outsourcingcontract. Wanneer uw diensten afhankelijk zijn van gedeelde platforms, hebben uw configuratie-, toegangs- en operationele keuzes een sterke invloed op de beveiligingsresultaten, zelfs als de onderliggende infrastructuur van iemand anders is.
Vergeleken met generieke leverancierscontroles in domeinen zoals leveranciersbeheer en operationele beveiliging, A.5.23:
- Legt de nadruk op de levenscyclus van clouddiensten en niet alleen op de selectie van leveranciers.
- Verwacht dat er expliciet rekening wordt gehouden met gedeelde verantwoordelijkheid en multi-tenancy.
- Richt zich op de manier waarop u cloudservices kunt beëindigen of vervangen zonder de controle over uw gegevens te verliezen.
Deze nadruk komt terug in de specialistische A.5.23-commentaren en cloud control mappings, die de levenscyclus, gedeelde verantwoordelijkheid en exitplanning benadrukken in tegenstelling tot traditioneel leverancierstoezicht. Voor MSP's staat A.5.23 ook naast toegangscontrole, assetmanagement, incidentmanagement en andere Annex A-controles. Het doel is niet om werk te dupliceren, maar om ervoor te zorgen dat uw bestaande controles volledig rekening houden met de cloud en de manier waarop u diensten levert.
Door deze controle duidelijk aan uw ISMS te koppelen, zien auditors dat cloud governance geïntegreerd is en niet als een apart traject wordt behandeld.
Documenttypen die auditors verwachten te zien
De documenttypen die auditors verwachten voor A.5.23, zijn die welke aantonen dat uw cloudbeleid, -processen en -verantwoordelijkheden reëel, consistent en toegepast zijn. Ze zoeken naar een kleine, samenhangende set artefacten in plaats van een grote hoeveelheid losjes samenhangende documenten. Implementatiehandleidingen voor cloudgovernance voor A.5.23 verwijzen vaak naar een combinatie van beleid, serviceregisters, risicobeoordelingen en levenscyclusrecords als de belangrijkste bewijsset die auditors verwachten.
Tijdens een audit wordt u waarschijnlijk om bewijsmateriaal gevraagd, zoals:
- Een beleid voor cloudgebruik of cloudbeveiliging.
- Een register van cloudservices die intern en namens klanten worden gebruikt.
- Cloudspecifieke risicobeoordelingen en behandelplannen.
- Due diligence-gegevens voor belangrijke cloudproviders en subverwerkers.
- Gedeelde verantwoordelijkheidsmatrices of equivalente roldefinities.
- Procedures of draaiboeken voor het onboarden en verlaten van services.
- Voorbeelden van logs, beoordelingen of tickets die laten zien hoe deze processen werken.
Als je deze snel kunt vinden en ze een consistent verhaal vertellen, voelt A.5.23 gecontroleerd en proportioneel aan. Als ze alleen in verspreide documenten of in de hoofden van mensen voorkomen, wordt de controle een bron van bevindingen en extra werk. Door een ISMS-platform zoals ISMS.online te gebruiken om deze artefacten op één plek te bewaren, wordt het veel gemakkelijker om te laten zien hoe cloudbeheer in de praktijk wordt uitgevoerd.
ISO 27001 eenvoudig gemaakt
Een voorsprong van 81% vanaf dag één
Wij hebben het harde werk voor u gedaan, waardoor u vanaf het moment dat u inlogt een voorsprong van 81% heeft. U hoeft alleen nog maar de lege plekken in te vullen.
Het dubbelleven van de MSP: cloudklant en -provider
Uw MSP heeft een dubbelleven onder A.5.23: u bent zowel een veeleisende cloudklant van upstream-providers als een verantwoordelijke cloudprovider voor uw eigen klanten. De controle verwacht dat u beide rollen begrijpt, documenteert en beheert, inclusief hoe ze samenwerken in de gedeelde verantwoordelijkheidsketen.
Als cloudklant vertrouwt u op hyperscale-platformen en SaaS-tools om uw eigen bedrijf te runnen en diensten te leveren. Als cloudprovider zien uw klanten u als de partij die verantwoordelijk is voor beveiliging, continuïteit en ondersteuning, zelfs wanneer de onderliggende technologie van iemand anders is. A.5.23 brengt deze twee perspectieven samen en vraagt u om ze coherent te beheren.
Inzicht in uw upstream- en downstream-rollen
Inzicht in uw upstream- en downstreamrollen betekent dat u erkent dat u clouddiensten als interne klant gebruikt en tegelijkertijd cloudgebaseerde diensten als leverancier aan uw eigen klanten verkoopt. A.5.23 verwacht dat u beide perspectieven in het oog houdt en ervoor zorgt dat ze elkaar ondersteunen in plaats van tegenspreken.
Als cloudklantU gebruikt diensten zoals productiviteitssuites, ticketing, monitoringplatforms en openbare cloudinfrastructuur. U bent verantwoordelijk voor de configuratie van deze diensten, wie er toegang heeft en hoe ze worden gemonitord. Wanneer zich incidenten voordoen of toezichthouders vragen stellen, hangt uw vermogen om controle te tonen af van hoe goed u dat verbruik beheert en hoe duidelijk dit is gekoppeld aan uw ISMS-processen, zoals risicobeoordeling en changemanagement.
Als cloudprovider of -beheerder, ontwerpt, levert en ondersteunt u diensten die op deze platforms draaien. U verkoopt mogelijk beheerde infrastructuur, back-up, SOC, applicatiehosting of beveiligingsdiensten. Uw klanten zien u als de verantwoordelijke partij, zelfs wanneer u bouwt op een externe cloud. Ze maken geen onderscheid tussen uw dienst en de hyperscaler waarop deze draait; ze gaan ervan uit dat u de details goed hebt geregeld.
Een veelvoorkomende mismatch ontstaat wanneer u afspraken maakt met klanten over logretentie of back-upgeschiedenis, maar een upstream-tool nog steeds op de standaard, veel kortere, instelling draait. In dat geval heeft uw downstream-afspraak uw upstream-configuratie overtroffen, en A.5.23 zal die kloof blootleggen.
Het ontwikkelen van een visie op dubbele verantwoordelijkheid
Het ontwikkelen van een dual-rolverantwoordelijkheidsvisie betekent dat u de verantwoordelijkheden van providers, uw MSP-teams en klanten in één coherent model in kaart brengt. Dit geeft uw CISO, hoofd service delivery en accountmanagers een gezamenlijk beeld van wie wat in de hele keten verantwoordelijk maakt.
Een praktische manier om dit te doen, is door een matrix met dubbele verantwoordelijkheden te creëren. Voor de belangrijkste controlegebieden – identiteits- en toegangsbeheer, configuratie, logging, back-up, incidentrespons, wijzigingsbeheer, gegevensbescherming – vermeldt u:
- Waar uw upstream-leveranciers zich toe verbinden.
- Waar u als MSP zich upstream aan committeert (bijvoorbeeld het inschakelen van bepaalde functies, het beheren van bepaalde risico's).
- Waartoe u zich verderop in uw klantcontracten en SLA's verbindt.
- Wat u verwacht dat klanten zelf doen.
Deze oefening brengt vaak mismatches aan het licht: verplichtingen aan klanten die geen upstream-ondersteuning hebben, of aannames over aanbieders die niet door hun contracten worden ondersteund. Het maakt ook duidelijk waar u sterkere controles, duidelijkere formuleringen of andere serviceontwerpen nodig hebt. Wanneer u dit inzicht inbouwt in een ISMS-platform zoals ISMS.online, biedt u teams één bron van waarheid over gedeelde verantwoordelijkheden.
Verantwoordelijkheidskaarten omzetten in dagelijkse praktijk
Het omzetten van verantwoordelijkheidskaarten in de dagelijkse praktijk betekent ervoor zorgen dat iedereen die met cloudservices te maken heeft, de onderdelen begrijpt die erop van toepassing zijn en er snel mee aan de slag kan. De kaarten moeten het gedrag in sales, engineering, support en accountmanagement sturen.
Verantwoordelijkheidskaarten concreet maken betekent:
- Ze worden gebruikt om verkoop- en accountteams te briefen, zodat ze niet te veel beloven of improviseren.
- Het afstemmen van draaiboeken en playbooks op de verantwoordelijkheden die u hebt gedefinieerd, zodat technische teams consistent handelen.
- Het opleiden van engineers in hoe en wanneer zij hun rechten bij klanthuurders moeten uitoefenen, inclusief tijdsgebonden verhogingen en goedkeuringen.
- Afspraken maken over de wijze waarop incidenten waarbij providers betrokken zijn, met klanten worden gecommuniceerd en afgehandeld, inclusief escalatiepaden.
Wanneer uw dual-rolperspectief op deze manier is ingebed, is A.5.23 geen abstracte vereiste meer, maar een natuurlijke lens voor hoe uw MSP in de cloud opereert. Het biedt u ook een duidelijk verhaal voor directies en klanten die uw plaats in de keten van gedeelde verantwoordelijkheid willen begrijpen.
Een praktisch model voor gedeelde verantwoordelijkheid voor MSP-cloudplatforms
Een praktisch model voor gedeelde verantwoordelijkheid voor MSP-cloudplatforms is een set duidelijke matrices die laten zien wie wat doet, ongeacht provider, MSP en klant, voor elke service. Onder A.5.23 maken deze matrices van het idee van gedeelde verantwoordelijkheid iets dat u kunt uitvoeren, aanleren en controleren.
De meeste aanbieders van openbare clouds hanteren een eenvoudige indeling: zij beveiligen de infrastructuur; u beveiligt wat u erop bouwt. Dit patroon is vastgelegd in de uitleg van het model voor gedeelde verantwoordelijkheid van grote aanbieders zoals AWS, Azure en Google Cloud, en is een gangbare basis geworden voor het ontwerp van cloudbeheer. Voor MSP's is dat slechts het beginpunt. U hebt modellen nodig die de specifieke platforms die u gebruikt, de services die u aanbiedt en de manier waarop uw teams daadwerkelijk werken, weerspiegelen.
Verder kijken dan de generieke ‘gezamenlijke verantwoordelijkheid’
Verder kijken dan de generieke labels van 'gezamenlijke verantwoordelijkheid' betekent vage uitspraken vervangen door specifieke, benoemde taken die individuen en teams begrijpen. A.5.23 beloont deze helderheid, omdat auditors en klanten kunnen zien wie verantwoordelijk is voor echte acties, niet alleen voor abstracte concepten.
Generieke labels voor 'gezamenlijke verantwoordelijkheid' verbergen reële risico's. Om deze te overstijgen, moet u rekening houden met het volgende:
- De specifieke platforms die u gebruikt (bijvoorbeeld infrastructuur als een service, software als een service, beheerde beveiligingstools).
- De specifieke services die u aanbiedt (bijvoorbeeld beheerde back-up, beheerde SOC, beheerde moderne werkplek).
- De manier waarop uw team daadwerkelijk functioneert (bijvoorbeeld gebruik van automatisering, centrale monitoring, onderhoudsvensters).
Voor elke combinatie van platform en service moet een verantwoordelijkheidsmatrix de verantwoordelijkheden zo gedetailleerd definiëren dat mensen actie kunnen ondernemen. Dat betekent dat er moet worden benoemd wie logging inschakelt, wie herstel test, wie verzoeken om toegang tot gegevens afhandelt en wie de incidentcommunicatie leidt, in plaats van simpelweg te spreken van "gedeeld".
Met deze extra stap worden ook gerelateerde controles ondersteund, zoals incidentbeheer en operationele beveiliging, omdat iedereen kan zien waar zijn of haar rol begint en eindigt.
Het structureren van uw verantwoordelijkheidsmatrices
Een goede structurering van uw verantwoordelijkheidsmatrices betekent een consistente lay-out gebruiken die de denkwijze van uw engineers en servicemanagers weerspiegelt, maar toch gedetailleerd genoeg is om actie te sturen. Een eenvoudige structuur, die voor alle services wordt herhaald, maakt training en evaluatie veel eenvoudiger.
Een praktische matrix voor elke service zou domeinen kunnen omvatten zoals:
- Identiteits- en toegangsbeheer: – die accounts aanmaakt en intrekt, rollen beheert en toegang controleert.
- Configuratie en verharding: – die basislijnen toepast, beveiligingsupdates afhandelt en configuratieafwijkingen controleert.
- Logging en monitoring: – die logs inschakelt, ze opslaat, waarschuwingen beoordeelt en reageert op incidenten.
- Back-up en herstel: – die back-ups configureert, herstel test en hersteldoelstellingen verifieert.
- Gegevensbescherming en privacy: – die gegevens classificeert, bewaartermijnen toepast en de rechten van betrokkenen beheert.
- Continuïteit en exit: – wie verantwoordelijk is voor veerkrachtpatronen, failover en gegevensexport of -verwijdering aan het einde van een contract.
Voor elke rij moet de matrix de verantwoordelijkheden duidelijk markeren: provider, MSP, klant of gedeeld met specifieke toegewezen taken. Zorg er ook voor dat elke matrix versiebeheer heeft en wordt gecontroleerd wanneer services, platforms of contracten veranderen, zodat deze in de loop van de tijd accuraat blijft.
Een vereenvoudigd voorbeeld voor beheerde back-up op een openbaar cloudplatform zou er als volgt uit kunnen zien:
| Domein | Verantwoordelijkheden van de leverancier/MSP/klant |
|---|---|
| Back-upconfiguratie | Provider biedt functionaliteit aan; **MSP** configureert beleid; klant beoordeelt bereik |
| Herstel testen | **MSP** voert periodieke testherstelbewerkingen uit; klant valideert de volledigheid van de gegevens |
| Bewaarinstellingen | Provider handhaaft limieten; **MSP** stelt retentie in; klant keurt beleid goed |
Vervolgens kunt u deze matrices hergebruiken voor klanten die hetzelfde servicepatroon gebruiken. Pas ze alleen aan waar dat echt nodig is.
Het model koppelen aan uw ISMS en klanten
Door het model van gedeelde verantwoordelijkheid te koppelen aan uw ISMS en klanten, zorgt u ervoor dat het beslissingen beïnvloedt van pre-sales tot offboarding, in plaats van dat het geïsoleerd blijft. Hoe meer u het verbindt, hoe nuttiger en geloofwaardiger het wordt.
Nadat u deze modellen hebt gedefinieerd, verbindt u ze:
- Intern, door ernaar te verwijzen in beleid, procedures, draaiboeken en trainingen.
- Commercieel gezien door uw servicebeschrijvingen, voorstellen en SLA's af te stemmen op de verantwoordelijkheden die u hebt vastgesteld.
- Door tijdens het onboardingproces vereenvoudigde weergaven of diagrammen te delen met klanten, zijn de verwachtingen vanaf dag één duidelijk.
Wanneer een auditor vraagt hoe u gedeelde verantwoordelijkheid onder A.5.23 beheert, kunt u verwijzen naar deze matrices, hun koppelingen met uw ISMS en voorbeelden van hoe ze daadwerkelijke beslissingen hebben beïnvloed. Wanneer een klant, zoals een CISO of IT-manager, vraagt "wie is verantwoordelijk voor deze controle?", heeft u een antwoord dat consistent is binnen de hele organisatie. Een centraal platform zoals ISMS.online kan deze matrices naast risico's, controles en contracten bewaren, zodat ze eenvoudig te onderhouden en te bewijzen zijn.
Bevrijd jezelf van een berg spreadsheets
Integreer, breid uit en schaal uw compliance, zonder rommel. IO geeft u de veerkracht en het vertrouwen om veilig te groeien.
Ontwerpen van levenscyclusprocessen voor cloudservices voor A.5.23
Met processen voor de levenscyclus van cloudservices bewijst u dat A.5.23 meer is dan een beleidsverklaring: ze laten zien dat u cloudservices op een gecontroleerde en herhaalbare manier selecteert, uitvoert en buiten gebruik stelt. Voor een MSP is het doel om stappen in de levenscyclus van de cloud te integreren in uw bestaande ISMS-processen, niet om een aparte bureaucratie te creëren.
A.5.23 verwacht dat u aantoont dat cloudservices gedefinieerde stappen volgen van idee tot exit, waarbij beveiliging en gedeelde verantwoordelijkheid in elke fase worden meegenomen. Dit sluit nauw aan bij de eigen taal van de controle over "aanschaf, gebruik, beheer en exit" van cloudservices in lijn met de eisen voor informatiebeveiliging, en bij gangbare levenscyclusmodellen die worden gebruikt in ISO 27001 en cloudstandaardrichtlijnen, zoals het commentaar in ISO 27001 A.5.23. Dit sluit naadloos aan bij de ISO 27001-bepalingen over risicobehandeling, operationele planning, verandermanagement en leveranciersmanagement.
Het definiëren van een levenscyclus voor clouddiensten die mensen kunnen volgen
Het definiëren van een levenscyclus voor cloudservices die mensen kunnen volgen, betekent dat A.5.23 wordt omgezet in een kleine set herhaalbare stappen die aansluiten bij uw bestaande werkwijzen. De levenscyclus moet zo eenvoudig zijn dat producteigenaren, engineers en inkoopteams deze zonder specialistische kennis kunnen toepassen. Twee derde van de organisaties in het ISMS.online State of Information Security-onderzoek van 2025 geeft aan dat de snelheid en omvang van de regelgevingswijzigingen het moeilijker maken om naleving te handhaven.
Een typische levenscyclus voor belangrijke cloudservices kan de volgende fasen omvatten:
- Idee en beoordeling – iemand stelt een nieuwe clouddienst voor of een nieuwe manier om een bestaande dienst te gebruiken. U screent deze op bedrijfswaarde, beveiliging en compliance.
- Selectie en due diligence – u controleert certificeringen, gegevenslocaties, contractvoorwaarden en ondersteuningsmogelijkheden en vergelijkt opties.
- Ontwerp en onboarding – u bepaalt hoe de service wordt geconfigureerd, geïntegreerd en gemonitord en wie er eigenaar van is.
- Bediening en verandering – u voert de service uit, controleert logboeken en statistieken, verwerkt wijzigingen en incidenten en zorgt ervoor dat de configuratie voldoet aan uw normen.
- Herziening en verlenging – U evalueert periodiek of de dienstverlening nog steeds aansluit bij de behoeften, of de risico’s acceptabel zijn en of er verbeteringen nodig zijn.
- Uitgang of vervanging – Als u de dienst uitschakelt of vervangt, verzorgt u de gegevensexport, verwijdering en klantcommunicatie.
Deze fasen maken beslissingen over cloudservices herhaalbaar in plaats van ad-hoc. Definieer voor elke stap de minimale acties, goedkeuringen en registraties die u verwacht. Dit kan risicobeoordelingen, due diligence-checklists, configuratiebasislijnen, wijzigingsrecords en exitbevestigingen omvatten, allemaal afgestemd op uw centrale ISMS.
Om het nog bruikbaarder te maken, kunt u de levenscyclus weergeven als een eenvoudige reeks stappen die teams kunnen volgen.
Stap 1: Leg het idee vast en screen het
Registreer en screen elk idee voor een cloudservice voordat iemand zich aanmeldt of het integreert. Zo kunt u de waarde, risico's en afstemming op uw ISMS afwegen.
Leg de voorgestelde cloudservice, het doel ervan en de initiële risico's vast voordat iemand zich aanmeldt of de service integreert.
Stap 2: Voltooi due diligence en ontwerp
Voer grondig due diligence en ontwerp uit voordat een cloudservice wordt geïmplementeerd, zodat de configuratie, monitoring en verantwoordelijkheden worden vastgelegd in plaats van geïmproviseerd.
Controleer de zekerheid, contracten en gegevensverwerking en definieer vervolgens de configuratie, monitoring en gedeelde verantwoordelijkheden.
Stap 3: Aan boord gaan, bedienen en exit plannen
Zorg dat u op een gestructureerde manier aan boord gaat, de exit uitvoert en plant, zodat u kunt aantonen hoe de service gedurende de gehele levensduur wordt aangestuurd.
Start de service volgens uw basislijnen, houd toezicht en registreer hoe u deze veilig verlaat of vervangt.
Levenscycluscontroles inbedden in de manier waarop u werkt
Het integreren van lifecycle controls in uw werkwijze betekent dat u ze integreert in processen en tools die uw teams al gebruiken. Wanneer de lifecycle het standaardpad is, wordt naleving van A.5.23 veel gemakkelijker te handhaven.
Overwegen:
- Door het af te stemmen op de inkoopprocessen, kunnen contracten pas worden ondertekend nadat de beveiliging, privacy en operationele vereisten zijn gecontroleerd.
- Koppel het aan uw service-introductieproces, zodat nieuwe aanbiedingen of grote wijzigingen de poorten van de cloudlevenscyclus passeren.
- Integreer levenscyclustaken in uw ticketing- en wijzigingssystemen, en niet alleen in afzonderlijke clouddocumenten.
Door levenscyclusstappen te koppelen aan gevestigde processen zoals changemanagement en leveranciersmanagement, vermindert u de wrijving en verbetert u de acceptatie. Mensen volgen de levenscyclus omdat het de weg van de minste weerstand is, niet omdat ze een ander beleid moeten lezen.
Levenscyclusbewijs gereed maken voor audits
Levenscyclusbewijs auditklaar maken betekent dat je een paar complete voorbeelden kunt laten zien die dezelfde logica toepassen op verschillende services. Auditors willen patronen zien, geen eenmalige successen.
Probeer voor elk voorbeeld het volgende te demonstreren:
- Waarom de service is gekozen, op basis van risico en vereisten.
- Hoe verantwoordelijkheden werden gedefinieerd, met behulp van uw model van gedeelde verantwoordelijkheid.
- Welke controles werden geïmplementeerd bij onboarding, inclusief basislijnen en toegangspatronen?
- Hoe de service wordt gemonitord en beoordeeld, met voorbeelden van wijzigingen of verbeteringen.
- Hoe gegevens en toegang bij exit worden afgehandeld, zelfs als die exit nog niet heeft plaatsgevonden.
Als u dit bewijs zonder al te veel moeite kunt leveren, voelt A.5.23 eerder ingebed dan eraan vastgeschroefd. Een systeem als ISMS.online kan hierbij helpen door diensten, risico's, verantwoordelijkheden, wijzigingen en exit-records op één plek te koppelen, zodat u niet telkens opnieuw een compleet beeld hoeft samen te stellen wanneer iemand ernaar vraagt.
Technische controles voor meerdere huurders: consistente waarborgen implementeren
Technische controles voor meerdere tenants vormen de praktische uitwerking van uw A.5.23 cloud governance-beslissingen in de dagelijkse engineering. Ze vertalen gedeelde verantwoordelijkheidsmodellen en levenscyclusprocessen naar concrete basislijnen die meerdere klanten tegelijk beschermen.
Wanneer u meerdere tenants op gemeenschappelijke platforms beheert, verwacht A.5.23 dat u een proactieve, gestandaardiseerde aanpak hanteert voor identiteit, configuratie, logging, back-up en isolatie. Zo kunt u aantonen dat uw technische beveiliging aansluit bij de verantwoordelijkheden die u hebt aanvaard en de toezeggingen die u aan klanten doet.
Waarom multi-tenant basislijnen belangrijk zijn
Multi-tenant baselines zijn belangrijk omdat kleine zwakke punten grote gevolgen kunnen hebben voor meerdere klanten tegelijk. Eén te permissieve rol, een gemiste update of een niet-geteste back-up kan uw algehele cloud assurance-niveau ondermijnen. Cloudbeveiligingskaders en nationale richtlijnen, zoals discussies over multi-tenant risico's in controlecatalogi en cloudbeveiligingscollecties van nationale cybersecuritycentra, benadrukken consequent identiteitsbeheer, patching en back-up als systemische risicogebieden die snel kunnen opschalen naar andere tenants wanneer ze uitvallen. Een meerderheid van de organisaties in de ISMS.online-enquête van 2025 gaf aan in het afgelopen jaar te zijn getroffen door ten minste één beveiligingsincident gerelateerd aan een derde partij of leverancier.
In een MSP-omgeving kan één beheerdersaccount met te veel rechten, een niet-gelogde kritieke actie of een niet-getest back-upproces tientallen klanten treffen in één incident. A.5.23 verwacht dat u deze risico's systematisch beheert, niet reactief, en dat u kunt aantonen hoe uw controles van toepassing zijn op de cloudservices die u gebruikt en levert. Consistente basislijnen definiëren de minimale controles die van toepassing zijn voor elke klant die een bepaald platform of een bepaalde service gebruikt en geven auditors en klanten het vertrouwen dat u de beveiliging niet telkens opnieuw uitvindt.
Vanuit het perspectief van het leiderschap bieden deze basislijnen ook een basis voor zekerheid: u kunt besturen en klanten laten zien dat de technische waarborgen aansluiten bij de governance- en contractuele beslissingen die u al hebt genomen.
Kerntechnische thema's om te standaardiseren
Belangrijke technische thema's die gestandaardiseerd moeten worden, zijn de gebieden waar consistente beveiligingsmaatregelen de kans op problemen tussen tenants verkleinen en engineers op elk platform een duidelijk startpunt bieden.
Hoewel de details per platform verschillen, hebben de meeste MSP's baat bij standaardisatie van ten minste de volgende thema's. Dit maakt het makkelijker voor uw hoofd beveiliging, operationeel leider en engineeringteams om dezelfde kant op te werken.
- Identiteits- en toegangsbeheer: – rolgebaseerde toegang, minimale privileges, scheiding van taken, tijdsgebonden verhoging voor acties met een hoog risico en robuuste offboarding.
- Configuratie en verharding: – basissjablonen voor netwerksegmentatie, encryptie, eindpuntbeveiliging, patchbeleid en resourcebenaming.
- Logging en monitoring: – consistente logboekconfiguraties, centrale logboekaggregatie, gedefinieerde waarschuwingsregels en gedocumenteerde responsplaybooks.
- Back-up en herstel: – standaard back-upschema’s, retentie, encryptie, hersteltestroutines en documentatie van de hersteldoelstellingen van de klant.
- Isolatie en huur: – patronen voor het scheiden van tenants op de netwerk-, identiteits- en gegevenslagen, en controles om te verifiëren of de isolatie standhoudt.
Elke baseline moet duidelijk aangeven wat de provider levert, wat u configureert en onderhoudt, en wat u van klanten verwacht. Samen vormen deze thema's de technische ruggengraat van uw A.5.23-implementatie.
Nadat u deze thema's hebt gedefinieerd, is de volgende stap om ze te integreren op de locaties waar engineers zich bevinden: sjablonen, scripts, infrastructuur als code, centrale beheertools en gedocumenteerde playbooks.
Technische besturingen aansluiten op A.5.23 en hoger
Door technische controles te koppelen aan A.5.23 en gerelateerde controles, zorgt u ervoor dat uw governance, wettelijke verplichtingen en technische praktijken elkaar ondersteunen in plaats van dat ze elkaar uit elkaar drijven. Deze afstemming maakt uw algehele systeem gemakkelijker uit te leggen en te verdedigen.
Dat betekent:
- Koppel elk basiselement aan uw gedeelde verantwoordelijkheidsmatrices, zodat technische controles aansluiten op de verantwoordelijkheden die u hebt toegewezen.
- Zorg ervoor dat basislijnen deel uitmaken van de levenscyclus van uw cloudservice, zodat ze worden toegepast bij de onboarding en worden herzien tijdens beoordelingen.
- Koppel thema's zoals toegang, logging en back-up aan Annex A-controles op toegangscontrole, operationele beveiliging, incidentbeheer en bedrijfscontinuïteit.
Deze afstemming zorgt voor een coherent totaalcontrolesysteem. Het betekent ook dat u, wanneer A.5.23 wordt besproken tijdens audits of klantbeoordelingen, niet alleen beleidsregels kunt laten zien, maar ook werkende technische waarborgen die aansluiten bij uw governance-niveau. Als u deze basislijnen beheert in een centraal systeem zoals ISMS.online, kunt u met een paar klikken de koppeling van een cloudservice met de bijbehorende risicobeoordeling en technische maatregelen aantonen.
Beheer al uw compliance op één plek
ISMS.online ondersteunt meer dan 100 normen en voorschriften, waardoor u één platform krijgt voor al uw compliancebehoeften.
Contracten, SLA's en subprocessorclausules die standhouden bij audits
Contracten, SLA's en subverwerkersclausules vormen de basis voor uw A.5.23 cloud governance-beslissingen die juridisch bindende beloftes worden. De controle verwacht dat uw overeenkomsten met providers, subverwerkers en klanten de gedeelde verantwoordelijkheid, levenscyclus en technische keuzes die u hebt gemaakt, weerspiegelen, in plaats van deze te weerspreken.
A.5.23 vereist niet dat u contracten op een bepaalde manier opstelt, maar auditors en klanten zullen toetsen of uw juridische verplichtingen en uw technische realiteit overeenkomen. Principegebaseerde richtlijnen voor A.5.23 en gerelateerde cloudcontroles benadrukken systematisch het belang van het afstemmen van contractuele beloften op de daadwerkelijke controles en gedeelde verantwoordelijkheidsmodellen, omdat onjuiste afstemming vaak de oorzaak is van auditbevindingen en geschillen.
A.5.23 vereist niet dat u contracten op een bepaalde manier opstelt, maar accountants en klanten zullen toetsen of uw juridische verplichtingen en uw technische realiteit overeenkomen. Zo niet, dan wordt de controle een bron van risico's en bevindingen.
Het expliciet vastleggen van verantwoordelijkheden en verwachtingen in contracten en SLA's betekent dat u uw interne verantwoordelijkheidsmatrices vertaalt naar heldere, stabiele bewoordingen die juridische zaken, verkoop en klanten allemaal kunnen begrijpen. A.5.23 is veel gemakkelijker te onderbouwen wanneer die documenten overeenkomen met de manier waarop u daadwerkelijk opereert.
Contracten en SLA's zijn de plekken waar misverstanden uitmonden in geschillen, vooral wanneer het om clouddiensten gaat. Ter ondersteuning van A.5.23 moeten uw overeenkomsten:
- Geef een duidelijke beschrijving van de services, inclusief eventuele afhankelijkheid van cloudplatforms van derden.
- Leg de verplichtingen inzake beveiliging en gegevensbescherming zo gedetailleerd vast dat ze zinvol zijn, zonder te beloven wat u niet kunt waarmaken.
- Leg uit wie verantwoordelijk is voor welke aspecten van incidentdetectie, -respons en -communicatie.
- Maak duidelijk wat er aan het einde van het contract gebeurt, inclusief het exporteren of verwijderen van gegevens en eventuele ondersteuning bij de overgang.
Stem deze taal waar mogelijk direct af op de domeinen in uw gedeelde verantwoordelijkheidsmatrices, zodat er een duidelijke lijn is van model naar formulering. Dit helpt ook om te voldoen aan de gerelateerde ISO 27001-vereisten met betrekking tot wettelijke, wettelijke en contractuele verplichtingen.
Als verantwoordelijkheden expliciet zijn vastgelegd in zowel matrices als contracten, is er voor uw teams minder ruimte voor tegenstrijdige interpretaties wanneer zich incidenten of complexe klantvragen voordoen.
Het afstemmen van de technische realiteit op de wettelijke verplichtingen
Het afstemmen van de technische realiteit op wettelijke verplichtingen betekent controleren of wat u in contracten belooft, haalbaar is met uw huidige tools, processen en uitgangspunten. Dit verkleint het risico dat klanten of auditors hiaten ontdekken tussen woorden en daden. Slechts ongeveer 29% van de organisaties in de ISMS.online-enquête van 2025 gaf aan geen boetes te hebben ontvangen voor tekortkomingen in de gegevensbescherming. De meerderheid meldde boetes en sommigen kregen boetes van meer dan £ 250,000.
Juridische clausules wijken na verloop van tijd gemakkelijk af van de technische realiteit. Een sjabloon belooft bijvoorbeeld zeer snelle melding van incidenten, maar uw monitoring- en escalatieprocessen maken dat in de praktijk lastig. Of een SLA legt hersteldoelstellingen vast die niet overeenkomen met de back-upontwerpen.
Om dit te voorkomen, moet u uw contracten en SLA's gezamenlijk beoordelen op de afdelingen juridische zaken, beveiliging, bedrijfsvoering en accountmanagement. Vraag:
- Kunnen wij, gegeven onze huidige monitoring, ondersteuningsuren en technische basislijnen, blijvend voldoen aan onze toezeggingen?
- Zijn er gebieden waar we moeten investeren in betere controles of instrumenten om deze na te leven?
- Zijn er verplichtingen die in plaats daarvan bij de klant of leverancier zouden moeten liggen en als zodanig gecommuniceerd zouden moeten worden?
Wanneer uw juridische verplichtingen en technische mogelijkheden op elkaar zijn afgestemd, wordt A.5.23 gemakkelijker te bewijzen en minder riskant om mee te werken. U verkleint ook de kans op verrassingen voor klanten, toezichthouders of accountants die zich verdiepen in de details achter uw beloftes.
Governance opnemen in uw overeenkomsten
Governance opnemen in uw overeenkomsten betekent dat u contractuele taal gebruikt om het gewenste gedrag van leveranciers en klanten te benadrukken, en niet alleen om diensten en prijzen te documenteren. Het kan gedeelde verantwoordelijkheid en levenscyclusdenken onderdeel maken van de dagelijkse relatie.
Dat kan het volgende omvatten:
- Recht om garanties van zorgverleners te ontvangen of te beoordelen, zoals bijgewerkte certificeringen of onafhankelijke rapporten.
- Verwachtingen omtrent deelname aan gezamenlijke incident- of continuïteitsoefeningen.
- Verplichtingen om belangrijke wijzigingen in de dienstverlening of locatie te melden.
- Vereisten om overeengekomen exit-processen te volgen, inclusief tijdlijnen en samenwerking.
Door deze in uw contracten te verweven, zorgt u ervoor dat governance niet alleen een interne aangelegenheid is. Het wordt onderdeel van de manier waarop u, uw leveranciers en uw klanten samenwerken gedurende de gehele levensduur van de dienst. Wanneer auditors A.5.23 testen, zien ze dat de levenscyclus en gedeelde verantwoordelijkheid consistent worden weerspiegeld in uw overeenkomsten, niet alleen in uw beleid.
Boek vandaag nog een demo met ISMS.online
Een demo boeken bij ISMS.online is een praktische manier om te zien hoe uw MSP A.5.23 cloud governance onder controle kan krijgen zonder uw teams complexer te maken. Op één plek ziet u hoe cloudservices, risico's, verantwoordelijkheden, levenscyclusstappen en bewijsmateriaal met elkaar samenhangen, zodat u klaar bent voor audits, klantvragen en board reviews.
U krijgt A.5.23 cloud governance onder controle wanneer u verspreide documenten en ad-hoc beslissingen vervangt door één coherent systeem dat services, risico's, verantwoordelijkheden, levenscyclusstappen en bewijsmateriaal koppelt. Voor veel MSP's kan het gebruik van een speciaal ontwikkeld ISMS-platform zoals ISMS.online een praktische manier zijn om die consolidatie te bereiken zonder extra complexiteit toe te voegen.
Met ISMS.online kunt u uw verantwoordelijkheden voor A.5.23 cloudgovernance omzetten in één geïntegreerd systeem dat cloudinventarissen, gedeelde verantwoordelijkheidsmodellen, levenscyclusworkflows, contracten en bewijsmateriaal met elkaar verbindt. In plaats van documenten te moeten zoeken op schijven, consoles en inboxen, kunt u op één plek zien hoe cloudservices worden beheerd en hoe verantwoordelijkheden worden beheerd.
Voor MSP's betekent dit dat u auditors, directies en klanten een duidelijker en samenhangender verhaal kunt laten zien: welke cloudservices u gebruikt, hoe verantwoordelijkheden worden gedeeld, welke controlemechanismen er zijn en hoe die regelingen in de loop van de tijd veranderen. Waarnemers van governance-, risico- en compliancetools (GRC) merken vaak op dat gecentraliseerde platformen dit soort verhalen gemakkelijker samen te stellen en consistent te houden maken, omdat ze risico's, controlemechanismen en bewijsmateriaal in één omgeving samenbrengen. U behoudt de controle over beslissingen; het platform helpt u die controle consistent aan te tonen, naarmate uw bedrijf groeit en de standaarden evolueren.
Bekijk uw cloudverdieping in één oogopslag
Door uw cloudomgeving in één oogopslag te bekijken, kunnen uw CISO, operations lead en klantgerichte teams moeilijke vragen gemakkelijker en zonder problemen beantwoorden. A.5.23 wordt minder een compliance-oefening en meer een eenvoudige manier om te beschrijven hoe u echt werkt.
Wanneer u uw cloudbeheer centraliseert in een ISMS-platform, geeft u uzelf en uw team één referentiepunt voor A.5.23. U kunt:
- Houd een actueel register bij van interne en klantgerichte cloudservices.
- Koppel elke service aan risico's, controles, verantwoordelijkheidsmatrices en levenscyclusfasen.
- Koppel contracten, due diligence-onderzoeken, wijzigingsrapporten en exit-bewijzen rechtstreeks aan de diensten waarop ze betrekking hebben.
Samen maken deze mogelijkheden het veel gemakkelijker om te reageren op vragen van auditors, beveiligingsbeoordelingen van klanten en interne besluitvormers die inzicht willen krijgen in hoe de cloud wordt beheerd. U bent niet langer afhankelijk van geheugen of losse spreadsheets om uw cloudverhaal te vertellen.
Zet vol vertrouwen de volgende stap
Als u uw MSP herkent in de hier beschreven uitdagingen – onduidelijke verantwoordelijkheden, verspreid bewijs, toenemende druk van klanten en auditors – is het verkennen van een platform zoals ISMS.online in een korte, gerichte demonstratie een praktische volgende stap. Ondanks de toenemende druk noemden bijna alle respondenten in het State of Information Security-onderzoek van 2025 het behalen of behouden van beveiligingscertificeringen zoals ISO 27001 of SOC 2 als topprioriteit.
U ziet hoe het uw bestaande hulpmiddelen en werkwijzen ondersteunt en u tegelijkertijd de structuur biedt die A.5.23 verwacht.
Kies ISMS.online als u uw cloudserviceregister, verantwoordelijkheden, risico's en bewijs op één plek wilt bewaren, zodat u kunt aantonen (en niet alleen beweren) dat A.5.23 onder controle is. Als u waarde hecht aan heldere governance, soepelere audits en een sterker verhaal voor klanten en besturen, staat ons team klaar om u te laten zien hoe dat er in uw omgeving uitziet.
Demo boekenVeelgestelde Vragen / FAQ
Wat verwacht ISO 27001:2022 A.5.23 nu werkelijk van een MSP die gebruikmaakt van cloudservices?
ISO 27001:2022 A.5.23 verwacht dat uw MSP: Beheer actief de volledige levenscyclus van elke cloudservice waarop u vertrouwt, niet alleen het verzamelen van providercertificaten en hopen op het beste. U moet snel en consistent kunnen aantonen wat u gebruikt, waarom u het gebruikt, wat er mis kan gaan, wie welke controles uitvoert en hoe u de verbinding kunt verbreken zonder gegevens of service te verliezen.
Hoe ziet ‘goed’ A.5.23-bewijs eruit voor een MSP?
Auditors en betrokken klanten zijn doorgaans op zoek naar een kleine, samenhangende bundel bewijsmateriaal, geen gigantisch archief. Voor een MSP bestaat de kernset doorgaans uit:
- Een duidelijke cloudgebruik / cloudbeveiligingsbeleid
Hierin definieert u wat in uw wereld als 'cloud' wordt beschouwd (IaaS, SaaS, PaaS, beheerde beveiligingsservices), wie nieuwe services kan goedkeuren en wat uw minimale verwachtingen zijn voor configuratie, monitoring en exit.
- A cloud service register dat het volgende omvat:
- interne tools (RMM, PSA, ticketing, facturering, CRM, monitoring, beveiligde bestandsoverdracht); en
- klantgerichte services (IaaS-platforms, Microsoft 365 en andere SaaS-suites, back-up/DR, SOC/XDR, beheerde firewalls en WAF's).
- Cloudspecifieke risicobeoordelingen en -behandelingen:
Deze moeten betrekking hebben op multi-tenant exposure, krachtige cross-tenant rollen, dataresidentie, vendor lock-in, API-afhankelijkheden en sleutelbeheer. De risico's moeten gekoppeld zijn aan concrete controles en verbeteracties.
- Due diligence-gegevens: voor belangrijke aanbieders en subverwerkers
Meestal gaat het hierbij om beveiligingssamenvattingen, certificeringen (bijvoorbeeld ISO 27001, SOC 2), DPA's, uptimegeschiedenis, inbreukgeschiedenis en bekende beperkingen of uitsluitingen die van invloed zijn op uw ontwerpen.
- Gedeelde verantwoordelijkheidsmatrices:
Laat voor elke belangrijke service zien wat de provider doet, wat uw MSP doet en wat de klant moet doen. De tekst moet concreet genoeg zijn zodat een engineer of klant "mijn taken" kan zien zonder een tweede afspraak.
- Levenscyclusrecords van cloudservices:
Bewijs dat selectie, onboarding, configuratie, wijziging, periodieke beoordeling en exit op een gecontroleerde, herhaalbare manier worden afgehandeld en niet via ad-hoctickets.
Als deze elementen samengevoegd en eenvoudig te navigeren zijn, voelt A.5.23 gecontroleerd en geloofwaardig aan. Door ISMS.online te gebruiken om beleid, risico-items, leveranciersgegevens, verantwoordelijkheidsmatrices en levenscyclusgegevens in één ISMS-werkruimte te bewaren, hoeft u uw cloudomgeving niet telkens opnieuw op te bouwen aan de hand van inboxzoekopdrachten en consolescreenshots wanneer een auditor of klant de clausule aanhaalt.
Hoe moet een MSP een bruikbaar gedeeld verantwoordelijkheidsmodel voor de cloud opbouwen onder A.5.23?
U voldoet aan de bedoeling van A.5.23 wanneer ‘gedeelde verantwoordelijkheid’ een service-voor-service kaart van echte taken, niet alleen een marketingdia met de tekst: "Wij en de leverancier geven allebei om beveiliging." Iedereen die het leest – ingenieur, verkoper, contractbeoordelaar of klant – zou precies moeten kunnen zien wat hij of zij bezit.
Hoe maak je van ‘gedeelde verantwoordelijkheid’ iets concreets?
Een praktisch patroon dat goed werkt voor MSP's is:
1. Catalogiseer uw clouddiensten per categorie
Begin met een korte lijst met buckets:
- Publieke cloud-workloads (IaaS/PaaS).
- SaaS-productiviteitssuites (Microsoft 365, Google Workspace en vergelijkbare producten).
- Beheerde back-up- en noodherstelservices.
- Beheerde SOC/XDR en bedreigingsdetectieservices.
- Andere terugkerende cloudgebaseerde hulpmiddelen waarop u vertrouwt om uw bedrijf te runnen of diensten te leveren.
Deze lijst weerspiegelt doorgaans de vermeldingen in uw cloudserviceregister, waardoor u alles gemakkelijker op elkaar kunt afstemmen.
2. Kies een gemeenschappelijke set beveiligingsdomeinen
Kies een kleine set domeinen die van toepassing zijn op de meeste van uw diensten, zoals:
- Identiteits- en toegangsbeheer.
- Basisconfiguratie en verharding.
- Logging, monitoring en waarschuwingen.
- Back-up-, herstel- en testroutines.
- Encryptie en sleutelbeheer.
- Detectie, triage en reactie op incidenten.
- Wijzigingsbeheer en goedkeuringen.
- Bewaring, opslag en vernietiging van gegevens.
Door vast te houden aan een standaardset is het model eenvoudiger te begrijpen en te hergebruiken voor verschillende services.
3. Wijs eigendom toe per domein, per service
Bepaal voor elke dienst en elk beveiligingsdomein wie het werk in de praktijk daadwerkelijk uitvoert:
- Cloudprovider: – veerkracht van de infrastructuur, fysieke beveiliging, de meeste onderliggende platformpatches, enkele opties voor logopslag.
- Uw MSP: – basislijnen voor tenantconfiguratie, routering van waarschuwingen, back-upschema's, hersteltesten, triage van incidenten, rapportage aan klanten.
- Klant: – gebruikersgedrag, acceptabel gebruik, gegevensclassificatie, toegangsgoedkeuring, beslissingen over de levenscyclus van content.
Wanneer verantwoordelijkheden worden gedeeld, schrijf de splitsing dan als volgt op: specifieke taken, geen vage "gezamenlijke" labels. Bijvoorbeeld:
- “Klant keurt bewaartermijn goed; MSP implementeert en beoordeelt de configuratie elk kwartaal.”
- “MSP controleert beveiligingswaarschuwingen; provider verzorgt de reactie op incidenten op platformniveau.”
4. Integreer het model in de dagelijkse bedrijfsvoering
Een verantwoordelijkheidsmatrix is alleen zinvol als deze zichtbaar is op de werkplek. Zorg ervoor dat u:
- Verwijs ernaar in runbooks en playbooks, zodat engineers kunnen zien wat ze moeten doen tijdens incidenten en wijzigingen.
- richten standaard servicebeschrijvingen en SoW's zodat de verkoop geen taken belooft die u niet uitvoert.
- Weerspiegel het in contracten en SLA's, zodat de juridische verplichtingen aansluiten bij de technische realiteit en de mogelijkheden van de toeleverancier.
- Neem het op in onboardingpakketten, zodat nieuwe klanten begrijpen welke acties hen bijblijven en welke bij u blijven.
Door deze matrices centraal te beheren in ISMS.online – gekoppeld aan services in uw cloudregister, risico-items en leveranciersrecords – kunt u een matrix één keer bijwerken en de wijziging doorvoeren in runbooks, documentatie en auditbewijs. Dit maakt het veel gemakkelijker om aan te tonen dat A.5.23 in de praktijk werkt, niet alleen in een beleidsdocument.
Welke cloudspecifieke risico's benadrukt A.5.23 voor MSP's en waar glippen ze vaak weg?
Voor MSP's gaat A.5.23 minder over generieke verhalen over 'cloud-inbreuken' en meer over verkeerde verwachtingen, zwakke configuraties en slechte controle over de levenscyclus in gedeelde omgevingen. Problemen ontstaan vaak wanneer uw marketingbeloftes, de mogelijkheden van uw leverancier en het gedrag van uw team niet op elkaar aansluiten.
Waar komen MSP's vaak in de problemen?
Patronen die herhaaldelijk problemen veroorzaken zijn onder andere:
Te veel vertrouwen op aannames over de beveiliging van de provider
Het is gemakkelijk om te praten over 'secure by design' terwijl je ervan uitgaat dat taken zoals hersteltesten, logcontrole, threat hunting of verharding op tenantniveau zijn inbegrepen in een cloudabonnement. In werkelijkheid zijn veel van deze activiteiten uw verantwoordelijkheid als MSP, en soms gedeeltelijk die van uw klant. Wanneer ze niet in uw verantwoordelijkheidsmatrices en runbooks zijn vastgelegd, worden ze zelden consistent uitgevoerd.
Overmatige, slecht beheerde bevoorrechte toegang
MSP's vervullen vaak machtige rollen – wereldwijde beheerdersaccounts, partnerportals, break-glass-identiteiten – die meerdere tenants omvatten. Als deze rechten niet goed worden goedgekeurd, geregistreerd en gecontroleerd, kan één gecompromitteerde inloggegevens of misbruikt account uitgroeien tot een aanzienlijk incident met meerdere tenants. A.5.23 verwacht dat u dit risico in uw activa- en risicoregisters herkent en er duidelijke controles op toepast.
Niet-geregistreerde of “schaduw” SaaS
Teams gebruiken SaaS-tools die gevoelige of klantgegevens verwerken – voor ondersteuning, samenwerking, ontwikkeling, verkoop of automatisering – zonder deze ooit toe te voegen aan uw ISMS, leveranciersregister of risicoprocessen. Deze services vallen dan buiten uw monitoring-, incidentrespons- en exitplannen.
Zwakke of ongeteste exitplannen
Veel MSP's denken pas aan exit wanneer een provider een productbeëindiging, een grote prijswijziging of een uitval aankondigt. Zonder een vastgelegd exitplan – inclusief data-export, migratie, bewijsbewaring en klantcommunicatie – improviseert u op het moment dat u de meeste controle nodig hebt.
SLA's die te veel beloven
Contracten leggen u soms verplichtingen op aan hersteldoelstellingen, bewaartermijnen of specifieke dataresidentie die de onderliggende stack niet kan garanderen. Wanneer het serviceontwerp, de functies van de cloudprovider en de contractvoorwaarden niet overeenkomen, loopt u onnodig risico.
A.5.23 biedt u een raamwerk om deze problemen systematisch aan te pakken:
- Inventariseer en classificeer cloudservices: zodat u weet waar de risico’s zich concentreren.
- Uitvoeren cloudspecifieke risicobeoordelingen die problemen met meerdere tenants, bevoorrechte toegang en providerstoringen aanpakken.
- Onderhouden verantwoordelijkheidsmatrices zodat taken worden toegewezen, erkend en beoordeeld.
- bewijsmateriaal levenscyclusstappen – van onboarding tot exit – zodat mensen kunnen zien dat veranderingen, beoordelingen en exits gecontroleerde gebeurtenissen zijn, en geen reacties.
Wanneer u een risico (bijvoorbeeld overmatige toegang tot partnerportals) kunt traceren van uw register naar verantwoordelijkheidsmatrices, en vervolgens naar wijzigingsrecords en verbeteracties, voldoet u niet alleen aan A.5.23, maar vormt u ook een veel sterker cloudrisico voor auditors en klanten.
Hoe kan een MSP A.5.23 in zijn ISMS documenteren zonder alles opnieuw te ontwerpen?
U kunt A.5.23 doorgaans dekken door het toevoegen van cloudspecifiek bestuur aan uw bestaande ISMS, in plaats van een parallelle structuur op te bouwen. Het doel is dat iedereen die bekend is met ISO 27001 net zo gemakkelijk kan volgen hoe u cloudservices selecteert, beheert en verwijdert als traditionele assets of leveranciers.
Hoe integreert u cloud governance in wat u al hebt?
Een eenvoudig maar effectief patroon is om te beginnen met drie verbonden componenten en deze vervolgens aan te sluiten op uw bestaande ISMS:
1. Cloudgebruik / cloudbeveiligingsbeleid
Breid uw bestaande informatiebeveiligingsbeleid uit met een gericht document dat:
- Definieert wat in uw context als een cloudservice wordt beschouwd.
- Stelt goedkeuringsdrempels in (bijvoorbeeld wie een nieuwe provider kan autoriseren).
- Geeft de verwachtingen aan ten aanzien van due diligence, configuratiebasislijnen, monitoring, incidentafhandeling en exit.
Dit beleid vormt het anker voor gerelateerde procedures en registraties.
2. Cloudserviceregister
Maak een register – vaak een ISMS.online-activa- of leverancierslijst – waarin u minimaal het volgende vastlegt:
- Servicenaam en provider.
- Interne eigenaar.
- Zakelijk doel.
- Verwerkte gegevenstypen en gegevenslocaties.
- De kriticiteit en impact van het verlies.
- Links naar contracten, DPA's, certificeringen en verantwoordelijkheidsmatrices.
U kunt dit integreren met uw bestaande activa-inventaris, zodat cloudservices zich niet in een afzonderlijk universum bevinden.
3. Gedeelde verantwoordelijkheidsmatrices
Voor de services die er het meest toe doen, bouw en onderhoudt u verantwoordelijkheidsmatrices zoals eerder beschreven. Concentreer u in eerste instantie op:
- Uw primaire publieke cloudplatform.
- Uw belangrijkste SaaS-productiviteits- en samenwerkingssuite.
- Uw toonaangevende beheerde backup/DR-aanbod.
- Uw beheerde SOC/XDR of vergelijkbare Security-as-a-Service-oplossingen.
Vervolgens kunt u deze componenten verbinden met de ISMS-elementen die u al gebruikt:
- Risicomanagement: – cloudservices koppelen aan risico-invoer en -behandelingen, vooral in situaties waarin sprake is van multi-tenant- of provider-uitvalscenario's.
- Leveranciers management: – contracten, beveiligingsoverzichten, DPA’s en auditrapporten aan de relevante aanbieders toevoegen; periodieke beoordelingen en beslissingen vastleggen.
- Operationele controles: – verwijzen naar cloudspecifieke onboarding-, wijzigings-, beoordelings- en exitstappen binnen uw bestaande processen voor wijzigingsbeheer en incidentafhandeling.
- Bewijsbeheer: – koppel incidenten, back-uptestresultaten, toegangsbeoordelingen en verbeteracties terug aan de relevante cloudvermeldingen en risico's.
Aan de hand van uitgewerkte voorbeelden – bijvoorbeeld één interne SaaS, één klantgerichte oplossing gebouwd op de publieke cloud en één niche maar cruciaal platform – kunt u auditors laten zien dat het patroon herhaalbaar is zonder elke kleine service afzonderlijk te documenteren. ISMS.online is ontworpen voor deze vorm van modellering: beleid, registers, risico's, leveranciers, taken en bewijs staan bij elkaar, met koppelingen die het beeld van cloud governance gemakkelijk te volgen maken.
Welke contracten en SLA's moet een MSP afstemmen om A.5.23 aan klanten te demonstreren?
Om A.5.23 overtuigend te demonstreren, moet u: zowel uw upstream- als downstream-overeenkomsten om aan te sluiten bij de manier waarop u daadwerkelijk cloudrisico's beheert. Dat betekent dat uw contracten en SLA's met providers en subverwerkers, en uw voorwaarden met klanten, allemaal dezelfde verantwoordelijkheidsverdelingen en capaciteiten moeten vermelden die u in uw ISMS documenteert.
Wat moet u controleren in overeenkomsten met upstream-leveranciers en subverwerkers?
Bekijk de onderdelen van elke overeenkomst die rechtstreeks van invloed zijn op uw diensten en claims:
- Beveiligings- en beschikbaarheidsverbintenissen: – zorg ervoor dat RPO/RTO-doelen, uptime-SLA's en duurzaamheid van gegevens aansluiten bij de manier waarop u services ontwerpt en de beloften in uw eigen SLA's.
- Locatie- en woonplaatsverklaringen van gegevens: – U moet met zekerheid kunnen antwoorden op de vraag “Waar zijn onze gegevens?”, inclusief back-uplocaties en failoverregio’s.
- Melding en escalatie van incidenten: – controleer hoe en wanneer aanbieders u informeren over incidenten die uw klanten kunnen treffen.
- Ondersteuning voor belangrijke besturingselementen: – bevestig of functies zoals gedetailleerde logging, door de klant beheerde encryptiesleutels, onveranderlijke back-ups of geavanceerde toegangscontroles waarop u vertrouwt, expliciet beschikbaar zijn en worden ondersteund.
- Verzekeringsmechanismen: – certificeringen, assurance-rapporten, samenvattingen van penetratietests of contractuele auditrechten identificeren die u als bewijsmateriaal in uw eigen ISMS en klantrapportages kunt gebruiken.
Mogelijk hoeft u niet elk contract opnieuw te onderhandelen, maar u moet wel begrijpen en documenteren waar de toezeggingen van een provider tekortschieten ten opzichte van uw huidige servicebeschrijvingen, en uw eigen aanbiedingen of architectuur dienovereenkomstig aanpassen.
Hoe moeten klantcontracten en SLA's worden gewijzigd om A.5.23 te weerspiegelen?
Stroomopwaarts moeten uw klantgerichte documenten:
- Duidelijk identificeren welke diensten afhankelijk zijn van welke cloudplatforms, vooral als dat gevolgen heeft voor de locatie, veerkracht of ondersteuning van gegevens.
- Verklaren wie is verantwoordelijk voor welke controlegebieden – zoals goedkeuringen voor gebruikerstoegang, acceptabel gebruik, classificatie, juridische verplichtingen en de levenscyclus van inhoud – in overeenstemming met uw gedeelde verantwoordelijkheidsmatrices.
- Toewijden aan hersteldoelstellingen, bewaartermijnen en communicatietermijnen voor incidenten dat uw upstream-overeenkomsten en ontwerpen betrouwbaar kunnen worden uitgevoerd.
- Referentie of link naar, verantwoordelijkheids- en afhankelijkheidsinformatie op een manier die klanten kunnen begrijpen zonder uw ISMS te lezen.
Wanneer upstream-contracten, interne verantwoordelijkheidsmatrices en downstream-SLA's allemaal hetzelfde verhaal vertellen, is het veel gemakkelijker om een klant of auditor uit te leggen hoe u cloudrisico's beheert volgens A.5.23. Door deze documenten in ISMS.online te beheren, samen met uw beleid en risico's, kunt u het verhaal consistent houden naarmate providers hun voorwaarden bijwerken, regelgeving evolueert en klanten veeleisender worden.
Hoe kan een MSP ISMS.online gebruiken om A.5.23 onder controle te houden wanneer cloudservices veranderen?
ISMS.online helpt u A.5.23 onder controle te houden door cloud governance om te zetten in een continu bijgewerkt, verbonden systeem, in plaats van een set statische documenten die achterblijven bij wijzigingen in uw stack. Terwijl u cloudservices implementeert, wijzigt of uitfaseert, blijft uw ISMS-weergave actueel, controleerbaar en uitlegbaar.
Hoe ziet het dagelijkse A.5.23-beheer eruit in ISMS.online?
In een typische opstelling gebruikt uw team ISMS.online om:
Houd een live cloudserviceregister bij
- Registreer voor elke cloudservice de eigenaar, het doel, de gegevenstypen, de gegevenslocaties en het kriticiteitsniveau.
- Intern gebruikte tagservices versus de tagservices die worden gebruikt om beheerde services te leveren.
- Koppel elk item aan relevante beleidsregels, risico's, leveranciers en verantwoordelijkheidsmatrices.
Cloudspecifieke risico's en behandelingen koppelen en volgen
- Maak risico-items voor blootstelling aan meerdere tenants, krachtige accounts voor meerdere tenants, gegevensresidentie, providervergrendeling en API-afhankelijkheden.
- Wijs behandelingen, eigenaren en evaluatiedata toe.
- Gebruik de gekoppelde werkzaamheden en projecten op het platform om herstel- en verbeteringsacties bij te houden.
Sla contracten, certificeringen en due diligence op één plek op
- Upload leverancierscontracten, DPA's, beveiligingssamenvattingen en assurance-rapporten rechtstreeks naar leveranciersrecords.
- Registreer de uitkomsten van beoordelingen en beslissingen, zodat u kunt aantonen dat het risico voor de zorgverlener in de loop van de tijd wordt beheerd.
Centraliseer gedeelde verantwoordelijkheidsmatrices
- Houd één gezaghebbende matrix aan per belangrijke cloudservice of servicefamilie.
- Koppel matrices aan beleid, servicebeschrijvingen, risico-items en leveranciersrecords.
- Gebruik ze als referentiepunten bij het bijwerken van runbooks, SLA's en onboardingmaterialen.
Activiteiten in de levenscyclus van bewijsmateriaal
- Logboekselectie, onboarding, goedkeuringen van configuratiebasislijnen, wijzigingen beoordelen, periodieke herbeoordelingen en exit-stappen als taken of gekoppelde werkitems.
- Koppel gerelateerde incidenten, back-uptests, toegangsbeoordelingen en verbeteringen aan de relevante services en risico's.
Wanneer u een nieuw platform implementeert, kunt u binnen enkele minuten een bestaand item klonen, de configuratie en verantwoordelijkheden aanpassen en koppelen aan risico's en leveranciers. Wanneer u een service buiten gebruik stelt, kunt u de beslissingen over datamigratie, -sanering en -retentie op dezelfde plek vastleggen.
Voor audits, klantvragenlijsten of bestuursvergaderingen kunt u vervolgens rechtstreeks vanuit ISMS.online een gericht A.5.23-bewijspakket samenstellen: het cloudbeleid, het huidige register, voorbeelden van verantwoordelijkheidsmatrices, belangrijke cloudrisico's en -behandelingen, due diligence van leveranciers en een voorbeeld van levenscyclus- en incidentregistraties. Die mogelijkheid om een consistent, end-to-end verhaal te schetsen, zorgt ervoor dat een MSP de controle over cloudgovernance lijkt te hebben in plaats van constant te reageren. Wilt u dat klanten en auditors u tot die eerste groep rekenen, dan is investeren in een goede structurering van A.5.23 binnen ISMS.online een zeer effectieve volgende stap.
