De multi-cloud, multi-tenant hoofdpijn voor ISO 27001 MSP's
Multicloud en multitenant public cloud maken ISO 27001-compliance moeilijker, omdat gedeelde lagen en virtuele grenzen de kans op fouten vergroten. U voert klantworkloads uit via AWS, Azure en Google Cloud en gebruikt teams, tools en beheervlakken opnieuw, waardoor één fout meerdere tenants tegelijk kan beïnvloeden. Om compliant te blijven, moet uw ISMS deze realiteit beschrijven, gedeelde lagen als risico's van de hoogste klasse behandelen en laten zien hoe u klantomgevingen gescheiden houdt. Die verwachting is in lijn met de vereisten van ISO 27001:2022 om de organisatorische context te begrijpen, de reikwijdte te definiëren en risicobehandeling en -beheersing te plannen op een manier die weerspiegelt hoe u daadwerkelijk diensten levert, zoals uiteengezet in de norm.
Een publieke cloud kan uw diensten schaalbaarder en winstgevender maken, maar het verandert ook uw ISO 27001-risicobeeld op manieren die gemakkelijk te onderschatten zijn. Wanneer u tientallen klantomgevingen op verschillende platforms beheert, creëren multi-tenancy, gedeelde tooling en complexe datastromen paden voor misconfiguratie waar de oudere, on-premises versie van uw ISMS mogelijk nooit rekening mee heeft gehouden. Als uw beheersysteem nog steeds uitgaat van fysieke scheiding en op maat gemaakte stacks per klant, zal het moeilijk zijn om te beschrijven hoe u vandaag de dag daadwerkelijk werkt.
Bijna alle respondenten van het ISMS.online-onderzoek uit 2025 gaven aan dat het behalen of behouden van beveiligingscertificeringen zoals ISO 27001 of SOC 2 hun hoogste prioriteit had.
Voor een managed service provider (MSP) is 'multi-tenant' niet zomaar een softwareterm. Het beschrijft uw volledige operationele model: veel klanten delen dezelfde onderliggende cloudplatforms, supportteams, monitoring stacks en vaak hetzelfde managementplatform. ISO 27001:2022 verwacht dat u deze gedeelde lagen begrijpt, de bijbehorende risico's expliciet behandelt en laat zien hoe u voorkomt dat de problemen van de ene klant overslaan op die van een andere klant. Dit vloeit direct voort uit de nadruk die de norm legt op het identificeren van informatiebeveiligingsrisico's die voortvloeien uit uw context en verwerkingsactiviteiten, en het selecteren en toepassen van controlemechanismen om die risico's op een aantoonbare manier aan te pakken in overeenstemming met de norm.
Sterke cloudgarantie begint wanneer u de realiteit beschrijft zoals die is, en niet zoals u zou willen dat die is.
Waarom multi-tenancy uw risicoprofiel verandert
Multi-tenancy verandert uw risicoprofiel omdat isolatie nu logisch is in plaats van fysiek, en gedeelde componenten kunnen leiden tot storingen met een grote explosieradius. In plaats van te vertrouwen op aparte hardware per klant, vertrouwt u op configuraties, identiteiten en centrale platforms, waardoor één enkele fout uw aannames over de scheiding van tenants kan verstoren. ISO 27001 verwacht dat deze wijziging duidelijk tot uiting komt in uw risicobeoordelingen, controlemaatregelen en bewijs. Dit is in lijn met de risicogebaseerde aanpak van ISO 27001:2022, die vereist dat u analyseert hoe veranderingen in technologie en dienstverlening risico's beïnvloeden en vervolgens de resulterende controlemaatregelen en ondersteunend bewijs documenteert in uw risicobehandelingsplan en verklaring van toepasselijkheid.
In een on-premises omgeving had je doorgaans aparte hardware, netwerken en soms aparte toolstacks per klant. Isolatie was voornamelijk fysiek. In de publieke cloud is isolatie logisch en sterk afhankelijk van configuratie en identiteits- en toegangsbeheer (IAM). Dat brengt drie grote veranderingen met zich mee voor ISO 27001:
-
Huurdersgrenzen zijn meestal virtueel.
Een verkeerd geconfigureerde rol, beveiligingsgroep of opslagbeleid kan plotseling meerdere klanten omvatten. ISO 27001 verwacht dat u dit in uw risicobeoordeling analyseert en beheersmaatregelen ontwerpt die het onwaarschijnlijk en detecteerbaar maken. -
Gedeelde componenten worden activa met een grote impact.
Loggingpipelines, back-updoelen, beheernetwerken, monitoringtools en identiteitsproviders bedienen nu meerdere klanten. Als één van hen wordt gecompromitteerd, kan de impact groot zijn. Deze assets moeten daarom in uw inventaris, risicoregister en verklaring van toepasselijkheid worden opgenomen. -
De verantwoordelijkheid is op drie manieren verdeeld.
Voor elke controle moet u bepalen wat door de cloudprovider wordt afgehandeld, wat onder uw verantwoordelijkheid als MSP valt en wat uw klant moet doen. Als die verdeling onduidelijk is, is uw risicobeeld onvolledig en zal uw bewijs door auditors worden betwist. Brancherichtlijnen voor gedeelde verantwoordelijkheidsmodellen in de cloud, waaronder communitybronnen zoals de OWASP-documentatie voor gedeelde verantwoordelijkheid in de cloud, benadrukken de noodzaak om eigenaarschap voor elke activiteit toe te wijzen en te documenteren tussen provider, MSP en klant, zodat er geen hiaten ontstaan.
Als u deze verschuivingen binnen uw ISMS niet herkent, slaagt u misschien nog wel een of twee keer voor een audit, maar u zult het moeilijker vinden om beslissingen te rechtvaardigen als er iets misgaat in een gedeelde omgeving.
Typische zwakke plekken die MSP's over het hoofd zien
Typische zwakke plekken in public-cloud MSP-omgevingen zijn onder andere een te grote afhankelijkheid van providercertificeringen, het vergeten van gedeelde platforms in de assetlijst en het achterlaten van cruciale kennis in de hoofden van mensen in plaats van in uw ISMS. Deze hiaten ondermijnen overigens sterke ISO 27001-verhalen en komen vaak als eerste aan het licht onder auditdruk of tijdens incidenten.
Wanneer MSP's hun diensten naar de publieke cloud verplaatsen en proberen ISO 27001 te handhaven, duiken er steeds weer verschillende patronen op:
- Ervan uitgaande dat de cloud gecertificeerd is, is alles in orde:
Cloudcertificeringen gelden voor de provider; u moet nog steeds elke klantomgeving veilig configureren en bedienen.
- Gedeelde platformen niet als activa vermelden:
Door centrale logging-, beheer- of bastionplatformen als generieke infrastructuur te behandelen, blijven risico's en controles voor meerdere gebruikers ongedocumenteerd.
- Inconsistente isolatiepatronen voor huurders:
Het mengen van gespecialiseerde en gepoolde modellen zonder standaardpatronen of onderbouwing maakt isolatiebeslissingen moeilijk uit te leggen en te verdedigen.
- Kennis van ongedocumenteerde helden:
Wanneer u vertrouwt op een paar senior engineers in plaats van op gedocumenteerde rollen, processen en diagrammen, raakt het ISMS los van de realiteit.
U hoeft dit niet allemaal in één keer op te lossen. Een praktische doelstelling voor het eerste kwartaal is om risico's met meerdere tenants in uw risicobeoordeling te onderkennen, gedeelde platforms als kritieke assets te identificeren en de belangrijkste tenantpatronen die u vandaag gebruikt, te documenteren.
Demo boekenDe cloud opnieuw definiëren als een uitbreiding van uw ISMS-scope
Door de cloud te beschouwen als een verlengstuk van uw ISMS-scope, ziet u AWS, Azure en Google Cloud niet langer als generieke leveranciers, maar als kernonderdelen van uw omgeving. De ISO 27001:2022-bepalingen over context, scope, risico en belanghebbenden maken het vanzelfsprekend om grote cloudplatforms te beschouwen als binnen uw systeemgrenzen, niet slechts aan de rand ervan. Wanneer uw scope die realiteit weerspiegelt, wordt al het andere gemakkelijker uit te leggen en te verdedigen.
Als uw ISMS nog steeds overkomt alsof u één of twee datacenters beheert met een paar SaaS-tools, is het waarschijnlijk niet in lijn met uw huidige public cloud-realiteit. Een heldere, cloudbewuste scope schept verwachtingen bij auditors, klanten en interne teams en voorkomt discussies achteraf over de vraag of een bepaalde service, regio of account "binnen de scope" valt. Zonder die duidelijkheid riskeert u verborgen hiaten waar klantworkloads of ondersteunende platforms buiten uw gedocumenteerde systeem vallen.
Zodra u de publieke cloud als binnen uw grenzen beschouwt, wordt elk account, abonnement of project dat beheerde workloads host, een nieuwe faciliteit die u moet begrijpen, documenteren en controleren. Deze verschuiving klinkt misschien administratief, maar heeft zeer praktische gevolgen voor de manier waarop u beleid schrijft, activa bijhoudt, leveranciers beheert en uw betrouwbaarheidsverhaal aan klanten uitlegt.
Vernieuw uw scopeverklaring voor de publieke cloud
Het vernieuwen van uw scopeverklaring voor de publieke cloud betekent dat u in begrijpelijke taal moet aangeven welke services, omgevingen en partijen onder uw ISMS vallen. In plaats van alleen datacenters te vermelden, moet u cloudaccounts benoemen en beschrijven hoe nieuwe omgevingen binnen de scope komen. Dit geeft auditors en klanten een duidelijk beeld van waar uw verantwoordelijkheden beginnen en eindigen.
In uw scope statement moet u drie vragen beantwoorden:
- Welke diensten worden gedekt?:
Voor een MSP omvat dat doorgaans beheerde hosting, monitoring, back-up, beveiligingsactiviteiten, servicedesk en eventuele klantportals die u host of beheert.
- Welke omgevingen worden gedekt?:
In plaats van alleen benoemde datacenters, dient u te verwijzen naar cloudaccounts, abonnementen en projecten. Beschrijf waar mogelijk hoe nieuwe omgevingen standaard in scope komen zodra ze aan bepaalde criteria voldoen, zoals het hosten van productieklantgegevens.
- Welke partijen en locaties zijn relevant?:
Hierbij moet u denken aan uw eigen organisatie, de klantomgevingen die u beheert, belangrijke leveranciers (grote cloudproviders, belangrijke SaaS-tools) en, indien nodig, geografische overwegingen zoals de locatie van uw gegevens.
Een eenvoudige manier om uw scope bij te werken, is door elk cloudaccount, abonnement of project dat beheerde klantworkloads host, te behandelen als een 'informatieverwerkingsfaciliteit' volgens ISO 27001. Deze formulering helpt om de scope af te stemmen op de norm en maakt het gemakkelijker om te rechtvaardigen waarom bepaalde controles van toepassing zijn.
Aanpassing van risicomanagement, activa en leveranciers
Het aanpassen van risicomanagement, activa en leveranciers voor de cloud betekent dat uw bestaande ISO 27001-processen de taal van accounts, regio's en managed services moeten spreken. In plaats van cloud te verstoppen onder generieke outsourcingrisico's, geeft u het expliciete vermeldingen in uw methodologie, inventaris en leveranciersniveaus, zodat clausules 4, 5 en 6 geworteld blijven in uw werkelijke werkwijze.
Een ruime meerderheid van de organisaties die deelnamen aan het ISMS.online State of Information Security-onderzoek van 2025, geeft aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.
Zodra de cloud expliciet in het bereik komt, moeten verschillende ondersteunende onderdelen van het ISMS worden vernieuwd:
- Risicomethodologie:
Cloudspecifieke risico's zoals regionale uitval, wijzigingen in beheerde services, problemen met identiteitsfederatie en concentratierisico's bij één provider moeten als benoemde items worden weergegeven, niet als generieke outsourcingrisico's.
- Inventaris van activa:
Cloudservices, gedeelde beheersvlakken, landingszones en configuratiebasislijnen moeten worden vermeld als activa met eigenaren, classificatie en levenscyclusstatussen.
- Leveranciersbeheer:
Grote cloudproviders vallen in een laag met een hoge mate van criticaliteit, met grondigere due diligence en voortdurende monitoring, terwijl SaaS-tools met een lager risico in een lichtere laag vallen.
- Verklaring van toepasselijkheid:
Controlemechanismen met een clouddimensie, waaronder Bijlage A 5.23 over het gebruik van cloudservices, vereisen expliciete toelichtingen over hoe ze van toepassing zijn op cloudservices en -configuraties. Organisaties die koppelingen publiceren tussen Bijlage A-controlemechanismen en cloudplatformconfiguraties, zoals technische documenten over koppeling van cloudcontrolemechanismen van onafhankelijke instanties zoals MITRE, benadrukken de waarde van het specificeren hoe doelstellingen zoals A.5.23 worden bereikt in specifieke services en instellingen in bronnen zoals documenten over koppeling van cloudcontrolemechanismen. Exacte koppelingen zijn altijd afhankelijk van uw architectuur, dus behandel voorbeelden als patronen in plaats van vaste voorschriften.
Probeer in het volgende kwartaal uw scopeverklaring, risicomethodologie, activa-inventarisatie en leveranciersniveaus bij te werken, zodat deze expliciet de cloudplatforms weerspiegelen waarvan u afhankelijk bent.
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.
Ontwerpen van ISO 27001-conforme multi-tenant architecturen (AWS, Azure, GCP)
Het ontwerpen van ISO 27001-conforme multi-tenant architecturen betekent het kiezen van een kleine set patronen die een evenwicht bieden tussen beveiliging, kosten en complexiteit, en deze vervolgens consistent toepassen. In plaats van elk team zijn eigen tenantmodel te laten bedenken, standaardiseert u op gepoolde, geïsoleerde en hybride benaderingen die u in ISO-termen kunt uitleggen, documenteren en koppelen aan risico's en controles in uw ISMS.
Nu de scope en het risico duidelijk zijn, is de volgende stap het vaststellen van een klein aantal multi-tenant patronen die u technisch en voor een auditor kunt verdedigen. Proberen elke mogelijke structuur te ondersteunen leidt tot uitzonderingen, technische schulden en auditfrictie. Als u een korte lijst met patronen kunt aanwijzen, kunt uitleggen wanneer u elk patroon gebruikt en kunt laten zien hoe ze verband houden met uw risicobeoordelingen, worden uw cloudarchitecturen veel gemakkelijker te rechtvaardigen.
In de publieke cloud is multi-tenant design meestal een keuze tussen drie high-level modellen: gepoold, gesiloed en hybride. De norm schrijft geen patroon voor, maar verwacht wel dat u weloverwogen keuzes maakt, deze documenteert en de resterende risico's beheert. Dit komt overeen met de technologieonafhankelijke ISO 27001:2022-standaard, die vereist dat u controles en maatregelen selecteert en rechtvaardigt op basis van gedocumenteerde risico's en het door u gekozen bedrijfsmodel, zoals beschreven in de norm.
Vergelijking van gepoolde, geïsoleerde en hybride modellen
Door gepoolde, gesilode en hybride modellen te vergelijken, kunt u bepalen welke patronen bij welke services en risiconiveaus passen. Gepoolde ontwerpen bevorderen efficiëntie en logische isolatie, gesilode ontwerpen bevorderen duidelijkere grenzen en hybride ontwerpen combineren gedeelde tools met gescheiden datavlakken. ISO 27001 schrijft geen model voor, maar verwacht wel dat u uw keuze rechtvaardigt en de bijbehorende risico's beheert.
Hier is een vereenvoudigd overzicht van de afwegingen waarmee u te maken krijgt:
| Model | Veiligheid en zekerheid | Kosten en operationele inspanning |
|---|---|---|
| Gepoold | Sterk afhankelijk van logische isolatie en testen; moeilijker te rechtvaardigen voor gegevens met een hoog risico. | Efficiënt gebruik van hulpbronnen; eenvoudiger te hanteren op kleinere schaal. |
| Siled | Duidelijkere isolatiegrenzen; vaak gemakkelijker uit te leggen aan accountants en toezichthouders. | Hogere kosten per huurder; meer omgevingen om te beheren. |
| Hybride | Zorgt voor een evenwicht tussen isolatie voor kritieke elementen en gedeelde componenten voor efficiëntie. | De complexiteit van ontwerp en bestuur neemt toe; er zijn sterke patronen nodig. |
- Gepoold model.:
Veel klanten delen dezelfde infrastructuur, applicatie en database, gescheiden door tenant-ID's, beveiliging op rijniveau, schema's of naamruimten. U moet aantonen hoe toegangscontrole, testen en monitoring de kans op blootstelling tussen tenants verkleinen.
- Silo-model:
Elke klant heeft zijn eigen account, abonnement of project, vaak met een eigen database en soms een eigen instance van kernservices. Dit is aantrekkelijk voor sectoren met een hoger risico, omdat de isolatie gemakkelijker te begrijpen is. U moet echter nog steeds laten zien hoe u consistente basislijnen handhaaft en configuratiedrift voorkomt.
- Hybride model:
Gedeelde besturingsvlakken en tools voeden afzonderlijke datavlakken, zoals accounts per tenant, netwerken of databases. U moet laten zien hoe u gedeelde componenten beschermt en bewaakt en de explosieradius van gedeelde storingen beperkt.
De meeste MSP's gebruiken uiteindelijk een mix: meer gepoolde modellen voor diensten met een laag risico en een hoog volume, en geïsoleerde of hybride modellen voor diensten met een hoge mate van zekerheid. Belangrijk voor ISO 27001 is dat u definieert welke diensten welk patroon gebruiken en waarom, de risico's en controles voor elk documenteert en patronen consistent toepast.
Cloudbouwstenen op een ISO-vriendelijke manier gebruiken
Het ISO-vriendelijk gebruiken van cloudbouwstenen betekent dat AWS-, Azure- en Google Cloud-constructies worden afgestemd op Annex A-controlethema's zoals toegangscontrole, segregatie, logging en leveranciersbeheer. Als u accounts, abonnementen, projecten en beheergroepen in die taal kunt uitleggen, verandert u potentieel verwarrende cloudterminologie in een coherent assurance-verhaal.
Elke grote cloud heeft zijn eigen terminologie en kenmerken, maar de ISO-conforme principes zijn vergelijkbaar:
- On AWSMeerdere accounts binnen een organisatie met centrale beveiliging zorgen voor isolatie van tenants, terwijl gedeelde tools in afzonderlijke beheeraccounts worden bewaard.
- On AzuurEntra-tenants, beheergroepen en abonnementen zorgen voor hiërarchie. Veel MSP's gebruiken een abonnement-per-klantpatroon met gedeelde beheerservices.
- On Google Cloud, organisaties, mappen en projecten creëren lagen; een project-per-tenant-model met centrale logging en gedeelde netwerken is gebruikelijk.
In alle gevallen moet u de door u gekozen patronen vastleggen in architectuurdocumenten, diagrammen en infrastructuur-als-code-sjablonen. Zo kunt u auditors laten zien dat uw ontwerpen weloverwogen zijn gemaakt, gecontroleerd, gekoppeld aan risicobeoordelingen en consistent geïmplementeerd.
Beveiliging inbouwen in pijplijnen en documentatie
Door beveiliging in te bouwen in pipelines en documentatie, worden uw multi-tenant patronen herhaalbare, controleerbare praktijken. In plaats van te vertrouwen op eenmalige configuraties, dwingt u isolatie, logging en tagging af in code en houdt u een duidelijke geschiedenis bij van wie wat en waarom heeft gewijzigd. Dit ondersteunt direct de ISO 27001-verwachtingen rondom wijzigingsbeheer, operationele planning en prestatie-evaluatie.
Stap 1 – Bouw vangrails in de infrastructuurcode
Gebruik sjablonen, beleidsregels en configuratieregels om isolatie-, encryptie-, logging- en taggingbasislijnen af te dwingen wanneer u een nieuwe omgeving maakt.
Stap 2 – Integreer beveiligingscontroles in CI/CD
Scan automatisch infrastructuurcode en cloudconfiguraties op problemen die de scheiding van tenants of andere belangrijke controles in gevaar kunnen brengen, voordat wijzigingen de productie bereiken.
Stap 3 – Leg beslissingen en bedreigingen vast in documentatie
Leg vast waarom u voor elk patroon hebt gekozen, welke bedreigingen u hebt overwogen en op welke controlemaatregelen u vertrouwt. Gebruik hiervoor beknopte beslissingsverslagen en bedreigingsmodellen.
Als realistische doelstelling voor het volgende kwartaal kunt u het beste twee of drie huurderspatronen standaardiseren, deze vastleggen in code en diagrammen en ze koppelen aan uw risicobeoordelingen en bijlage A-controles.
Toewijzing van ISO 27001:2022 Bijlage A aan cloudservices en -patronen
Door ISO 27001:2022 Bijlage A toe te wijzen aan cloudservices en -patronen, ontstaat een gedeelde taal tussen auditors en engineers. In plaats van te discussiëren over de vraag of een controle "van toepassing" is, wijst u naar een eenvoudige matrix die laat zien welke AWS-, Azure- en Google Cloud-services, baselines en rapporten aan elke doelstelling voldoen. Dit vermindert de auditfrictie en maakt changemanagement voorspelbaarder.
ISO 27001:2022 geeft niet aan welke cloudservice u moet gebruiken of hoe u een firewallregel moet configureren. Het definieert controledoelstellingen en laat u de technische middelen kiezen. Dat is inherent aan het ontwerp: ISO 27001:2022 richt zich op het 'wat' van informatiebeveiliging (risicomanagement, controledoelstellingen en continue verbetering) en blijft technologieneutraal, zodat u zelf kunt bepalen 'hoe' u deze doelstellingen implementeert op de door u gekozen platforms, zoals weerspiegeld in de norm. In een complexe MSP-omgeving is de enige praktische manier om dit beheersbaar te houden, het opstellen van een eenvoudige 'control-to-service'-kaart die engineers vertrouwen en auditors kunnen volgen.
Deze kaart vormt de brug tussen de taal die auditors gebruiken (controles in Annex A) en de taal die uw engineers gebruiken (cloudservices, API's, configuratiebaselines). Door deze kaart te onderhouden, krijgt u ook een voorsprong bij het koppelen aan andere frameworks, zoals SOC 2 of sectorspecifieke standaarden.
Het bouwen van een controle-naar-servicematrix
Het opstellen van een control-to-servicematrix betekent identificeren welke Annex A-controls een sterke clouddimensie hebben en vervolgens een lijst maken van de services, configuraties en processen die u nodig hebt om hieraan te voldoen. Wanneer u dit eenmalig doet en onderhoudt, vermindert u de inspanning van elke toekomstige audit en framework mapping.
Een nuttig startpunt is om u te concentreren op de thema's uit Bijlage A die het meest veranderen wanneer u naar de publieke cloud verhuist, zoals:
- Toegangscontrole en identiteit:
Controles rondom gebruikerstoegang, bevoorrechte toegang en authenticatie worden gekoppeld aan identiteitsproviders, op rollen gebaseerde toegangscontrole, multifactorauthenticatie en toegangscontroles in uw cloudplatformen.
- Logging en monitoring:
Besturingselementen voor gebeurtenisregistratie, monitoring en anomaliedetectie worden gekoppeld aan cloudloggingservices, centrale SIEM, waarschuwingen en runbooks voor incidentafhandeling.
- Back-up, herstel en verwijdering van informatie:
Controlemechanismen voor back-ups, hersteltests, retentie en veilig verwijderen worden gekoppeld aan snapshotbeleid, back-uptools, levenscyclusregels en procedures voor gegevensopschoning.
- Leveranciers- en cloudgebruik:
Controlemaatregelen met betrekking tot het gebruik van clouddiensten, waaronder Bijlage A 5.23, zijn van toepassing op uw proces voor het selecteren van clouddiensten, het beoordelen van gedeelde verantwoordelijkheid en het bewaken van de leveranciersgarantie.
Voor elk besturingselement geeft u vervolgens aan welke cloudservices en configuraties u gebruikt.
Stap 1 – Kies de cloud-zware besturingsthema's
Bepaal welke controlethema's uit Bijlage A het meest veranderen in de cloud, zoals toegangscontrole, logging, back-up en cloudgebruik, en geef ze een prioriteit in uw matrix.
Stap 2 – Koppel elke controle aan concrete services
Registreer voor elke prioriteitscontrole de identiteits-, logging-, back-up- of beheerservices, plus de belangrijkste configuraties die deze effectief maken in AWS, Azure of Google Cloud.
Stap 3 – Bepaal wat als bewijs geldt
Definieer de screenshots, configuratie-exporten, logs, rapporten of ISMS-records die u gebruikt om aan te tonen dat elke controle geïmplementeerd en operationeel is. De exacte toewijzingen variëren per MSP, dus gebruik dit als leidraad en pas het aan uw architectuur aan.
Het doel is niet om een enorme spreadsheet te maken. Het doel is om de relatie tussen controles en de cloudrealiteit expliciet te maken, zodat je hiaten kunt opsporen en het ontwerp aan auditors kunt uitleggen.
Het afstemmen van basislijnen, kaders en bewijs
Door baselines, frameworks en bewijsmateriaal af te stemmen op uw matrix, wordt het een dagelijkse tool in plaats van een eenmalige oefening. Wanneer u een standaardstructuur wijzigt, een nieuw framework implementeert of zich voorbereidt op interne audit en management review, raadpleegt u dezelfde kaart in plaats van dat u helemaal opnieuw begint.
Zodra u een basismatrix hebt, volgen hier drie praktische voordelen uit:
-
Technische basislijnen zijn gemakkelijker te rechtvaardigen.
Wanneer u een standaardversie bijwerkt, bijvoorbeeld om overal encryptie te vereisen, kunt u snel zien welke besturingselementen hierdoor worden beïnvloed en kunt u uw documentatie dienovereenkomstig bijwerken. -
Externe raamwerken overlappen elkaar duidelijker.
Door ISO-controles toe te wijzen aan cloudbasislijnen kan één set technische standaarden voldoen aan meerdere frameworks, waardoor duplicatie wordt verminderd. -
Bewijs wordt voorspelbaar.
Voor elk besturingselement in de matrix kunt u definiëren welk bewijs u wilt gebruiken: configuratie-exporten, schermafbeeldingen, logboeken, beleidsdocumenten, rapporten van bewakingstools of uitvoer van uw ISMS-platform.
Een speciaal ISMS-platform zoals ISMS.online kan hierbij helpen door u één plek te bieden om controles, cloudassets en bewijsmateriaal te koppelen, in plaats van dit te verspreiden over spreadsheets, diagrammen en issue trackers. Probeer de komende maanden een first-pass matrix te bouwen voor uw belangrijkste services en deze te verfijnen naarmate uw architecturen evolueren.
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.
Operationalisering van het model voor gedeelde verantwoordelijkheid in alle clouds
Het operationaliseren van het model van gedeelde verantwoordelijkheid in alle clouds betekent dat u providerdiagrammen omzet in concreet eigenaarschap voor u en uw klanten. In plaats van vage uitspraken over "het beveiligen van de cloud", hanteert u duidelijke matrices die laten zien wie wat doet voor elke dienst en zorgt u ervoor dat uw contracten, procedures en risicobeoordelingen aansluiten op die verdelingen.
Elke grote cloudprovider publiceert een model voor gedeelde verantwoordelijkheid. Grote providers zoals AWS, Microsoft Azure en Google Cloud publiceren allemaal hun eigen model voor gedeelde verantwoordelijkheid. Brancheorganisaties zoals de Cloud Security Alliance bespreken hoe ze deze in de praktijk kunnen communiceren en implementeren, bijvoorbeeld in hun blog over het communiceren van gedeelde verantwoordelijkheid in de cloud. Op hoofdlijnen zeggen ze allemaal hetzelfde: de provider beveiligt de cloud, jij beveiligt wat je in de cloud zet. Wanneer je MSP-diensten en klantverplichtingen aan dat plaatje toevoegt, wordt de splitsing complexer – en belangrijker voor ISO 27001.
ISO 27017, de uitbreiding van ISO 27001 op het gebied van cloudbeveiliging, is er vooral om deze verschillen te verduidelijken. Richtlijnen voor cloudbeveiliging en referenties over gedeelde verantwoordelijkheid, waaronder community-werk zoals het OWASP-materiaal over gedeelde verantwoordelijkheid in de cloud, benadrukken de rol van ISO 27017 bij het verduidelijken van de verantwoordelijkheden van leveranciers en klanten voor clouddiensten en het helpen van organisaties bij het toepassen van de ISO 27001-principes in gehoste omgevingen. Zelfs als u niet formeel gecertificeerd bent, zijn de concepten nuttig voor uw ISMS en kunnen ze u helpen uw model duidelijker uit te leggen aan auditors, klanten en juridische of privacy-stakeholders die belang hechten aan verdedigbare verantwoording.
Het omzetten van gedeelde verantwoordelijkheidsdiagrammen in concreet eigenaarschap betekent dat u voor elke beheerde service vastlegt welke taken eigendom zijn van de provider, welke eigendom zijn van u en welke eigendom zijn van de klant. Wanneer deze toewijzingen worden vastgelegd en gesynchroniseerd met uw ISMS, wordt het veel gemakkelijker om vragen van auditors te beantwoorden over wie verantwoordelijk is voor welke controles.
Ongeveer 41% van de organisaties die deelnamen aan het ISMS.online-onderzoek uit 2025 gaf aan dat het beheersen van risico's van derden en het bijhouden van de naleving door leveranciers een van hun grootste uitdagingen op het gebied van informatiebeveiliging is.
Voor elke belangrijke dienst die u aanbiedt (managed hosting, beveiligingsmonitoring, back-up, identiteit, endpoint management) moet u drie vragen kunnen beantwoorden:
- Waarvoor is de cloudprovider verantwoordelijk?
- Waarvoor bent u als MSP verantwoordelijk?
- Waarvoor is de klant verantwoordelijk?
De meest praktische manier om dit vast te leggen is een eenvoudige verantwoordelijkheidsmatrix (vaak een RACI genoemd: Responsible, Accountable, Consulted, Informed) voor elke dienst of dienstcategorie. Deze matrix moet aansluiten op:
- Uw contracten en servicebeschrijvingen.
- Uw interne beleid en procedures.
- Uw risicobeoordelingen en behandelplannen.
- Uw controlekaart en bewijsmodel.
Wanneer auditors een duidelijke, consistente reeks matrices zien die aansluiten bij uw werkelijke activiteiten en documenten, krijgen ze vertrouwen in het feit dat u de gedeelde verantwoordelijkheid begrijpt en beheert.
Het inbedden van gedeelde verantwoordelijkheid in contracten en dagelijkse werkzaamheden
Door gedeelde verantwoordelijkheid in contracten en dagelijkse werkzaamheden te verankeren, worden RACI-diagrammen zinvol. In plaats van in een geïsoleerd spreadsheet te werken, zijn de splitsingen zichtbaar in juridische documenten, operationele draaiboeken en trainingsmateriaal, zodat mensen handelen in lijn met wat u klanten en auditors hebt beloofd.
Gedeelde verantwoordelijkheid moet op twee plaatsen zichtbaar zijn:
-
Toewijding aan de klant.
In contracten, werkomschrijvingen, servicebeschrijvingen en bijlagen over informatiebeveiliging moet duidelijk staan wie wat doet en onder welke voorwaarden. -
Interne draaiboeken en trainingen.
Draaiboeken, incidentprocedures, onboardingmaterialen en teambriefings moeten naar dezelfde verdelingen verwijzen, zodat technici en ondersteuningsteams weten welke acties voor hen zijn en welke moeten worden doorgezet.
Uw ISMS is de lijm die deze twee visies op elkaar afstemt. Wanneer het verantwoordelijkheidsmodel verandert – bijvoorbeeld als u een groter deel van de beveiligingsconfiguratie van de klant gaat beheren – zouden uw scope, risico's, procedures en contracten mee moeten veranderen.
Een realistisch doel voor het komende kwartaal is om RACI's te bouwen voor uw drie belangrijkste cloudservices, de bijbehorende contractclausules bij te werken en uw teams te informeren zodat ze de nieuwe verdeling begrijpen. Voor privacy- en juridische functionarissen versterkt deze afstemming ook uw positie als een toezichthouder later onderzoekt wie verantwoordelijk was voor een bepaalde controle.
Continue naleving: governance, monitoring en bewijs
Continue compliance in de publieke cloud betekent dat u ISO 27001-governance kunt integreren in dezelfde monitoring, rapportage en automatisering die u al gebruikt om uw services uit te voeren. In plaats van u jaarlijks voor te bereiden op audits, ontwerpt u uw dashboards, waarschuwingen en reviews zo dat ze ook de effectiviteit van de controle aantonen, interne audits ondersteunen en managementreview voeden.
Publieke cloudomgevingen veranderen voortdurend. Er verschijnen nieuwe services, bestaande services krijgen meer functionaliteit, de workloads van klanten veranderen en regelgeving evolueert. Een ISO 27001-programma dat pas na een audit tot leven komt, kan dit tempo niet bijhouden. Voor MSP's is de oplossing om ISO 27001-governance te integreren in dezelfde monitoring, rapportage en automatisering die worden gebruikt voor het uitvoeren van services, zodat assurance een routinematig bijproduct wordt van goede bedrijfsvoering.
Continue naleving is eenvoudiger wanneer dit gebeurt via de systemen die u al vertrouwt voor uw bedrijfsvoering.
Het ontwerpen van monitoring die ook als bewijs kan dienen
Het ontwerpen van monitoring die tevens als bewijs dient, betekent dat u uw meetgegevens en waarschuwingen zo moet plannen dat ze de werking van de controle aantonen en de services gezond houden. Als uw dashboards al laten zien of back-ups zijn uitgevoerd, de toegang is beoordeeld en incidenten volgens plan zijn afgehandeld, heeft u minder extra werk te doen voor de ISO 27001-prestatiebeoordeling.
De meeste organisaties die deelnamen aan het ISMS.online State of Information Security-onderzoek van 2025, geven aan dat ze in het afgelopen jaar al te maken hebben gehad met minimaal één beveiligingsincident gerelateerd aan een derde partij of leverancier.
Wanneer u de monitoringvereisten definieert, streeft u ernaar om zowel aan de operationele als aan de ISO-doelstellingen te voldoen:
- Waarschuwingen toewijzen aan bedieningselementen:
Zorg ervoor dat er voor elke belangrijke controle een bijbehorende metriek of waarschuwing is. Als er te vaak waarschuwingen verschijnen, kan dit betekenen dat de controle niet effectief is.
- Zorg voor een zorgvuldige centralisatie van de zichtbaarheid van alle tenants:
Gebruik centrale registratie en monitoring om de activiteiten van klanten in kaart te brengen, maar beperk de toegang per rol om isolatie en privacy te respecteren.
- Leg context vast met gebeurtenissen:
Verrijk logboeken met informatie die van belang is voor audits, zoals welk beleid een herstelactie heeft geactiveerd of welk wijzigingsverzoek een configuratiewijziging heeft goedgekeurd.
Stap 1 – Beslis welke controles directe monitoring nodig hebben
Bepaal welke toegangs-, wijzigings-, back-up- en incidentgerelateerde controlemaatregelen het meest effectief zijn op de lange termijn, aan de hand van statistieken of waarschuwingen.
Stap 2 – Ontwerp dashboards en waarschuwingen rond deze controles
Configureer dashboards en waarschuwingen zodat ze de controlestatus, trends en uitschieters weergeven in een taal die uw leiders en auditors kunnen begrijpen.
Stap 3 – Hergebruik monitoringresultaten in interne audit en review
Neem monitoringrapporten op in interne audits en managementbeoordelingen, zodat de prestatie-evaluatie van Clausule 9 gebaseerd is op actuele gegevens en niet op meningen.
Als u een auditor kunt laten zien dat uw dashboards en rapporten al antwoord geven op zijn vragen over de operationele controle, wordt de grens tussen operationele activiteiten en naleving prettig dun.
Automatisering, rapportage en triggers voor verandering
Automatisering, rapportage en triggers voor wijzigingen zorgen ervoor dat continue compliance voor meerdere tenants duurzaam is. In plaats van elke omgeving handmatig te controleren, handhaaft u baselines in de code, vat u de controlestatus samen voor leidinggevenden en definieert u duidelijke voorwaarden voor het herzien van risico's en controles.
Om ervoor te zorgen dat veel huurders zich aan uw ISO 27001-verplichtingen houden, is handmatige controle niet voldoende. U heeft het volgende nodig:
- Automatisering om basislijnen af te dwingen:
Met beleid als code, configuratiebeheer en herstelhulpmiddelen blijven omgevingen afgestemd op uw normen en wordt vastgelegd wanneer afwijkingen worden gecorrigeerd.
- Regelmatige governance-rapportages:
Dashboards en samenvattingen voor het leiderschap omvatten de controlestatus, uitzonderingen, trends en openstaande risicobehandelingen, en voeden Clausule 9 en de managementbeoordeling.
- Wis triggers om de bedieningselementen opnieuw te bekijken:
Nieuwe cloudservices, grote architectuurwijzigingen, terugkerende waarschuwingen of wijzigingen in de regelgeving zouden allemaal aanleiding moeten zijn om uw risicobeoordelingen en controles te herzien.
Een platform zoals ISMS.online kan u helpen deze operationele signalen te koppelen aan het ISMS zelf – door risico's, controles, acties en bewijs te koppelen – zodat het managementsysteem daadwerkelijk weerspiegelt wat er in de cloud gebeurt. Probeer de komende maanden een aantal impactvolle controles te identificeren, deze te integreren in uw monitoring en automatisering en ervoor te zorgen dat de resulterende rapporten worden opgenomen in uw interne audit- en managementreviewcycli. Voor IT- en beveiligingsprofessionals vermindert dit moeizame handmatige controles en zet goed technisch werk om in zichtbare complianceresultaten.
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.
“ISO in de cloud” omzetten in een commercieel voordeel
Om van "ISO in de cloud" een commercieel voordeel te maken, moet u uw cloudbewuste ISMS beschouwen als onderdeel van uw aanbod, niet slechts als een compliancebadge. In plaats van uw werkwijzen te verbergen achter een certificaat, verpakt u isolatieopties, assurance-artefacten en responsieve governance als functies die de moeite van de klant verminderen en vertrouwen opbouwen.
Veel MSP's beschouwen ISO 27001 als een noodzakelijk keurmerk voor aanbestedingen. In een moderne public cloudomgeving kan het meer zijn dan dat: het kan een manier worden om uw diensten te onderscheiden, verkoopproblemen te verminderen en vertrouwen op lange termijn op te bouwen. Branchemateriaal over het gebruik van ISO 27001 en cloudbeveiliging in RFP's en marketing, inclusief richtlijnen van grote leveranciers zoals IBM over de positionering van certificeringen in de inkoopcyclus van bedrijven, gaat vaak uit van dit 'keurmerk voor aanbestedingen' als uitgangspunt en laat vervolgens zien hoe u verder kunt gaan, zoals in bronnen zoals IBM's richtlijnen voor beveiligingsattesten in RFP's. Wanneer uw ISMS de multi-tenant-realiteit duidelijk beschrijft, kunt u dat werk hergebruiken om vragen van potentiële klanten sneller en met meer geloofwaardigheid te beantwoorden.
Klanten, met name in gereguleerde sectoren, willen steeds vaker weten hoe u hun workloads in de cloud beveiligt, niet alleen of u een certificaat hebt. Dit komt overeen met wat veel cloudbeveiligings- en marketinggidsen melden: kopers, met name in gereguleerde sectoren, verwachten steeds vaker gedetailleerde uitleg over hoe workloads worden beveiligd, niet alleen een lijst met certificaten, zoals blijkt uit de richtlijnen van leveranciers over best practices voor cloudbeveiligingsmarketing van aanbieders zoals Oracle's best practices voor cloudbeveiligingsmarketing. Als u uw ISO-conforme cloudpraktijken kunt omzetten in duidelijke serviceopties en herbruikbaar bewijs, maakt u het voor hen gemakkelijker om voor u te kiezen en die keuze intern te rechtvaardigen.
Verpakkingsgarantie als kenmerken, niet alleen certificaten
Verpakkingsgarantie als kenmerken betekent uitleggen hoe U beveiligt workloads in de cloud, en u beschikt niet alleen over ISO 27001. Wanneer u isolatieniveaus, bewijspakketten en duidelijke verantwoordelijkheidsverdelingen als onderdeel van uw services presenteert, maakt u het werk van uw verkoop- en klantensuccesteams eenvoudiger.
Uit het ISMS.online-onderzoek van 2025 blijkt dat klanten steeds vaker verwachten dat leveranciers zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG, Cyber Essentials, SOC 2 en opkomende AI-normen.
U kunt uw ISO-afgestemde cloudpraktijken gebruiken om:
- Bied duidelijke serviceniveaus die isolatie- en zekerheidsniveaus voor huurders koppelen aan gedocumenteerde ISO-conforme controles.
- Bied standaardbewijspakketten aan die klanten kunnen hergebruiken in hun eigen audits, inclusief matrices, toewijzingen, logboeken en samenvattende risicooverzichten.
- Verkort de inkoopcycli door een samenhangend, kant-en-klaar verhaal te presenteren over hoe uw ISMS de publieke cloud bestrijkt in een taal die beveiligingsteams herkennen.
Voor oprichters en commerciële leiders veranderen deze elementen beveiliging van een bezwaar in een reden om te kopen. Voor CISO's en privacy officers aan de klantzijde bieden ze voldoende diepgang om uw aanpak te vertrouwen zonder dat u deze hoeft te reverse-engineeren. Voor uw eigen professionals valideren ze de technische inspanning die in uw architectuur en controlemechanismen is gestoken.
Het werk dat u hebt verricht om de reikwijdte, patronen, controletoewijzingen en monitoring te documenteren, kan selectief worden hergebruikt in verkoopmateriaal en communicatie met klanten, zolang u het nauwkeurig houdt en erop gericht bent om klanten te helpen aan hun eigen assurance-verplichtingen te voldoen.
Het meten en communiceren van de commerciële impact
Het meten en communiceren van de commerciële impact van uw ISO-conforme cloudpraktijk helpt compliance te herpositioneren als een bron van inkomsten. Wanneer u kunt wijzen op snellere vragenlijsten, hogere succespercentages en verlengingen die beveiliging als reden aanvoeren om te blijven, is uw investering in het ISMS veel gemakkelijker te verdedigen.
Als u wilt dat ISO 27001 wordt gezien als een bron van inkomsten en niet als een kostenpost, is het handig om een paar eenvoudige meetgegevens bij te houden:
- Winstpercentage in gereguleerde of veiligheidsgevoelige sectoren.
- Tijd tussen vragenlijst over de beveiliging en ondertekening van het contract.
- Deals verloren vanwege veiligheid of naleving van wet- en regelgeving.
- Retentie waarbij beveiliging en naleving belangrijke redenen voor verlenging zijn.
Stap 1 – Kies een kleine set commerciële beveiligings-KPI's
Selecteer twee of drie meetgegevens, zoals de doorlooptijd van vragenlijsten of het winstpercentage in gereguleerde sectoren, die duidelijk worden beïnvloed door uw assurance-verhaal.
Stap 2 – Verzamel en bekijk deze statistieken regelmatig
Maak eenvoudige rapporten die trends in de loop van de tijd weergeven en bespreek deze tijdens commerciële en leidinggevende vergaderingen, naast de traditionele verkoopcijfers.
Stap 3 – Geef inzichten terug aan uw ISMS en aanbiedingen
Als u betere resultaten ziet wanneer u uitgebreidere assurance-pakketten of sterkere isolatieopties aanbiedt, moet u dat in uw diensten en in uw ISMS-documentatie tot uitdrukking brengen.
U kunt uw account- en klantensuccesteams ook coachen om te praten over de blijvende waarde van beveiliging: regelmatige controlebeoordelingen, bewijspakketten, roadmap-briefings en reacties op nieuwe bedreigingen of wetswijzigingen. Zo blijft ISO 27001 aanwezig in verlengingsgesprekken zonder dat het auditvergaderingen worden.
Boek vandaag nog een demo met ISMS.online
Met ISMS.online kunt u één cloudbewust ISO 27001-managementsysteem beheren dat gelijke tred houdt met hoe uw MSP daadwerkelijk AWS, Azure en Google Cloud gebruikt. In plaats van te jongleren met spreadsheets, diagrammen en ad-hoc bewijsmappen, kunt u risico's, controles, gedeelde verantwoordelijkheidsmatrices en cloudspecifieke documentatie op één plek samenbrengen en koppelen aan de dagelijkse werkzaamheden van uw teams.
Voor MSP-oprichters en -leiders betekent dit een duidelijker beeld van hoe uw AWS-, Azure- en Google Cloud-praktijken zich verhouden tot ISO 27001:2022, en meer vertrouwen dat uw certificering weerspiegelt wat er daadwerkelijk in uw omgevingen gebeurt. Compliancemanagers krijgen gestructureerde ondersteuning voor het bijwerken van scope, risicobeoordelingen, Annex A-toewijzingen en bewijsmateriaal naarmate uw cloudomgeving groeit, inclusief cloudgerichte controles zoals die voor het gebruik van cloudservices. Serviceleiders, architecten en beveiligingsprofessionals krijgen praktische manieren om referentiearchitecturen te koppelen, workflows te wijzigen en output te monitoren in het ISMS zonder een aparte laag papierwerk te creëren.
Als u serieus bezig bent met het gebruik van openbare cloudplatformen en tegelijkertijd wilt voldoen aan ISO 27001 - en die mogelijkheid wilt omzetten in een tastbaar voordeel voor uw klanten - is het boeken van een korte demonstratie van ISMS.online een eenvoudige volgende stap. U zult zien hoe uw bestaande cloudarchitecturen en -processen kunnen worden vertaald naar een levend, auditklaar ISMS dat meegroeit met uw managed services-bedrijf en de druk op uw team vermindert.
Deze informatie is van algemene aard en vormt geen juridisch, certificerings- of auditadvies. Raadpleeg altijd een gekwalificeerde professional of certificeringsinstantie voor beslissingen die van invloed zijn op uw verplichtingen.
Veelgestelde Vragen / FAQ
Hoe verandert het verplaatsen van MSP-klanten naar de publieke cloud daadwerkelijk uw ISO 27001-naleving?
Wanneer u klanten naar AWS, Azure of Google Cloud verhuist, verandert uw ISO 27001-naleving. Dit komt doordat uw scope, risico's en controles verschuiven van fysieke apparatuur naar cloudplatformen, accounts en automatisering. Uw ISMS moet rekening houden met deze verschuiving, anders weerspiegelt het niet langer hoe u daadwerkelijk services uitvoert.
Welke ISMS-elementen moet u als eerste bijwerken voor de publieke cloud?
Er zijn drie zaken waar de meeste ISO 27001-gecertificeerde MSP's eerst naar moeten kijken:
- Omvang en context:
In uw scope statement moet u expliciet de cloudproviders, kernaccounts/abonnementen, regio's en gedeelde beheerplannen (bijvoorbeeld centrale logging, beveiligingstools, CI/CD, identiteit) benoemen. Zo weet een auditor precies waar uw ISO 27001-grenzen nu liggen en welke platforms uw beheerde services ondersteunen.
- Inventarisatie en classificatie van activa:
Fysieke servers worden cloudaccounts, projecten, services, pipelines en configuratiesLandingszones, tenant baselines, beheerabonnementen, gedeelde monitoring stacks en automatisering moeten worden behandeld als informatiemiddelen, waarbij de gegevens die ze verwerken duidelijk worden geclassificeerd. Dit helpt u precies te laten zien waar klantgegevens zich bevinden in AWS, Azure of Google Cloud.
- Risicobeoordeling en behandeling:
Fysieke bedreigingen worden minder relevant; cloud-centrische risico's nemen toe. Verkeerde configuratie, te brede rollen, kwetsbare beheerinterfaces, zwakke API-controles, onveilige automatisering en uitval in providerregio's zouden zichtbaar moeten zijn in uw risicoregister, met behandelingen die gekoppeld zijn aan Annex A-controles zoals A.5.23 (gebruik van clouddiensten) en de netwerkbesturingen in A.8.20–A.8.22.
Als uw ISMS nog steeds functioneert als een on-premises operatie, terwijl uw klanten zich in de publieke cloud bevinden, zal een auditor zich afvragen of uw risicobeeld en controleset nog wel geldig zijn.
Hoe verandert de publieke cloud hoe ‘controle’ er in de praktijk uitziet?
In de publieke cloud wordt veel controle tot uitdrukking gebracht via patronen en automatisering, niet alleen documenten:
- Toegangscontrole is terug te vinden in identiteitsproviders, rollen, beleidsregels, voorwaardelijke toegang en workflows met bevoorrechte toegang.
- Netwerksegregatie komt tot uiting in VPC's/VNets, beveiligingsgroepen, NSG's, firewalls, privé-eindpunten en peeringregels.
- Back-up, monitoring en incidentafhandeling zijn afhankelijk van native services die met elkaar zijn verbonden via infrastructuur als code, serverloze functies en runbooks.
Voor een ISO 27001-gecertificeerde MSP is de test of deze hefbomen:
- Gestandaardiseerd: in patronen en basislijnen, in plaats van uniek per project.
- eigendom: door duidelijke verantwoordelijkheden tussen de aanbieder, u en de klant.
- Bestuurd: door uw ISMS (wijziging, testen, beoordeling) en niet door "wat het cloudteam maar wil".
Wanneer deze cloudrealiteiten worden weerspiegeld in een gestructureerd ISMS-platform zoals ISMS.online - met bijgewerkte scope, risico's, controles en bewijs - kunt u auditors ervan verzekeren dat uw certificering nog steeds overeenkomt met de manier waarop u daadwerkelijk werkt.
Hoe moet een MSP multi-tenant cloudarchitecturen ontwerpen die nog steeds voldoen aan ISO 27001?
Je houdt ISO 27001 aan je zijde door jezelf te beperken tot een klein aantal multi-tenant patronendoor elk aspect te koppelen aan risico's en Bijlage A-controles, en deze consistent toe te passen in plaats van voor elke nieuwe klant of werklast een op maat gemaakt ontwerp te bedenken.
Welke multi-tenantpatronen werken goed voor ISO 27001 in AWS, Azure en Google Cloud?
De meeste MSP's kiezen voor twee of drie standaardmodellen en behandelen alles wat daarbuiten valt als een uitzondering die een sterkere rechtvaardiging nodig heeft:
- Gepoolde huur voor diensten met een lager risico:
Meerdere klanten delen een onderliggende infrastructuur (bijvoorbeeld gedeelde Kubernetes-clusters of multi-tenant SaaS), waarbij isolatie wordt afgedwongen door ID's, schema's, naamruimten en autorisatie. Om dit ISO-vriendelijk te houden, moet u het volgende specificeren:
- Hoe tenantgegevens worden gescheiden (netwerksegmentatie, databasebesturingselementen, per-tenantsleutels).
- Hoe isolatie wordt getest en gemonitord (automatische controles, gesimuleerde aanvallen, logging).
- Hoe u een luidruchtige of lastige huurder in toom houdt (snelheidslimieten, beperking van de snelheid, veilige opschorting).
- Toegewijd account/abonnement/project per tenant voor services met een hogere betrouwbaarheid:
Elke klant heeft zijn eigen account, abonnement of project, gekoppeld aan gedeelde landingszones en beheertools. Dit sluit natuurlijk aan bij de vereisten voor segregatie in Annex A, maar verhoogt het aantal omgevingen dat u op één lijn moet houden met uw baselines.
- Gedeeld controlevlak met gescheiden datavlakken:
Een centraal controlevlak (CI/CD, logging, beveiligingstools) dient aparte datavlakken waar de workloads en data van klanten zich bevinden. Dit kan u operationele efficiëntie bieden en tegelijkertijd duidelijke grenzen voor data-isolatie behouden.
Het belangrijkste is dat u het volgende kunt laten zien:
- A gedocumenteerde referentiearchitectuur voor elk patroon, met diagrammen en voorbeelden van infrastructuur-als-code.
- Een spoor van elk patroon in uw risicoregister en Bijlage A-controles (bijvoorbeeld A.8.20–A.8.22 voor netwerkbeveiliging en -segregatie).
- Verander- en testprocessen die ervoor zorgen dat elke nieuwe huurder een bekend patroon volgt in plaats van 'wat een ingenieur onder druk deed'.
Wanneer deze architecturen en controles zich in uw ISMS bevinden en uw teams met dezelfde ontwerpen werken, kunt u multi-tenancy aan auditors en kopers uitleggen zonder dat u daarvoor onbewerkte cloudconsoles voor schermdeling nodig hebt.
Hoe legt u uw multi-tenantmodel uit, zodat auditors en klanten er vertrouwen in hebben?
Beide doelgroepen willen een schone route zien vanaf risico → ontwerp → configuratie → bewijsEen eenvoudig verhaal werkt goed:
- Risico: “Cross-tenant datatoegang op een gedeeld platform.”
- Design: “Gepoold clusterpatroon met per-tenant naamruimten, netwerkbeleid en tenant-gerichte encryptiesleutels.”
- Configuratie: “Basissjablonen en richtlijnen passen we toe via Terraform of implementatiepijplijnen.”
- Bewijs: “Testresultaten, isolatiecontroles, logboeken en incidenten die laten zien hoe de controles in de loop van de tijd werken.”
Door die keten in uw ISMS te integreren, met ondersteunende diagrammen en basislijnen, kunt u een auditor of prospect op een rustige, herhaalbare manier door uw model leiden. ISMS.online helpt u die risico's, architecturen en controles op één plek te houden, zodat elke nieuwe omgeving uw verhaal versterkt in plaats van verwarring te zaaien.
Hoe kan een MSP ISO 27001:2022 Annex A-controles toewijzen aan AWS-, Azure- en Google Cloud-services?
Je maakt Annex A bruikbaar in AWS, Azure en Google Cloud door elk controlethema te vertalen naar specifieke diensten, basisconfiguraties en ondersteunende processenen dit vastleggen in een controle-naar-service-mapping die uw technici en auditors kunnen volgen.
Hoe ziet een praktische mapping van controle naar service eruit?
Een eenvoudige, uitbreidbare matrix zou er als volgt uit kunnen zien:
| Focusgebied Bijlage A | Clouddiensten in scope | Basisconfiguratie en processen |
|---|---|---|
| Toegangscontrole (A.5, A.8.x-familie) | IAM, Azure AD, Cloud IAM, PIM/PAM | Standaardrollen, MFA, just-in-time-elevatie |
| Logging en monitoring (A.8.15–A.8.16) | CloudTrail, Defender, Cloud Logging, SIEM | Centralisatie, alarmroutering, oproepdiensten |
| Back-up en herstel (A.8.13–A.8.14) | Snapshots, back-upkluizen, kopieën tussen regio's | Schema's, retentie, hersteltests |
| Gebruik van clouddiensten (A.5.23) | Leverancierscatalogi, service-onboardingstroom | Leveranciersbeoordeling, risico-goedkeuring, exitplanning |
Voor elke rij definieert u:
- Welke diensten: die u voor dat thema op elk platform gebruikt.
- De basislijninstellingen u verwacht (encryptie, retentie, privétoegang, logging, MFA).
- De bewijzen u kunt produceren (IaC, rapporten, tickets, logboeken, screenshots indien nodig).
Vervolgens koppelt u elke rij terug aan specifieke Annex A-bedieningselementen en geeft u aan of een bedieningselement:
- Beheerd door de provider: (fysieke beveiliging van datacentra, kerninfrastructuur).
- Door u uitgevoerd en gecontroleerd: (configuratie, monitoring, respons).
- Afhankelijk van de klant: (beveiliging van de applicatielaag, enkele beslissingen over gegevensverwerking).
Deze mapping vormt een gedeelde referentie voor beveiligings-, engineering- en auditteams en vormt een basis waarop u kunt voortbouwen naarmate uw cloudomgeving groeit.
Waarom is deze mapping ook nuttig na ISO 27001-certificering?
Als u eenmaal een goede mapping van controle naar service hebt, kunt u deze op verschillende manieren hergebruiken:
- Strek het uit om te bedekken SOC 2, NIS 2, DORA of ISO 27701, in plaats van nieuwe matrices helemaal opnieuw te ontwerpen.
- Versnel het beantwoorden van beveiligingsvragenlijsten en RFP's, omdat u al weet welke patronen en services voldoen aan algemene vereisten.
- Geef je teams een enkele bron van waarheid over hoe AWS, Azure en Google Cloud moeten worden geconfigureerd en beheerd om binnen uw ISMS te blijven.
Door deze mapping op te slaan in een geïntegreerd ISMS-platform zoals ISMS.online (naast risico's, beleid, SoA's en interne audits), worden alle wijzigingen in cloudservices of patronen automatisch doorgevoerd in uw assurance-proces, in plaats van dat ze in een vergeten spreadsheet verdwijnen.
Wat betekent gedeelde verantwoordelijkheid eigenlijk voor een ISO 27001-gecertificeerde MSP in de publieke cloud?
Voor een ISO 27001-gecertificeerde MSP betekent gedeelde verantwoordelijkheid in de publieke cloud dat u: expliciet besloten, gedocumenteerd en overeengekomen wie wat doet voor elk belangrijk controlegebied en dat beeld is consistent in al uw ISMS, contracten, servicebeschrijvingen en draaiboeken.
Hoe kun je gedeelde verantwoordelijkheid omzetten van een dia naar iets controleerbaars?
Een eenvoudige manier is om een verantwoordelijkheidsmatrix per service, meestal met behulp van RACI:
- Verantwoordelijk: wie de werkzaamheden uitvoert (bijvoorbeeld het configureren van tenants, het uitvoeren van back-ups, het afstemmen van waarschuwingen).
- Verantwoordelijk: wie de eigenaar is van het risico en de uitkomst (u, de klant, of soms beiden).
- Geraadpleegd: wie input levert (klantbeveiliging, juridische zaken, data-eigenaren).
- Op de hoogte: wie updates nodig heeft (accountmanagers, klantenbelanghebbenden).
Pas die matrix toe op controlethema's zoals:
- Beveiliging van huurders, platformen en netwerken.
- Identiteits- en toegangsbeheer.
- Back-up-, herstel- en veerkrachttesten.
- Logging, monitoring en afhandeling van waarschuwingen.
- Rapportage over naleving en zekerheid voor de klant.
Elke matrix moet aansluiten op:
- Contracten en werkomschrijvingen: , dus de reikwijdte en de aannames zijn expliciet.
- Intern runbooks en diagrammen, dus ingenieurs volgen dezelfde werkverdeling.
- Risico's en controles: in uw ISMS, inclusief de gevallen waarin u afhankelijk bent van de acties van uw klanten.
Wanneer u een service aanpast – bijvoorbeeld wanneer u meer beveiliging op de applicatielaag invoert of de klant meer operationele controle krijgt – werk dan de matrix bij, herzie uw documentatie en voer die wijziging door middel van interne audits door. Die geschiedenis geeft u een verdedigbare positie in geval van een incident of geschil.
Hoe kan ISO 27017 uw model van gedeelde verantwoordelijkheid versterken?
ISO 27017 biedt cloudspecifieke beveiligingsrichtlijnen die naast ISO 27001 en ISO 27002 worden gebruikt. Als u deze gebruikt om uw model voor gedeelde verantwoordelijkheid vorm te geven, kunt u:
- Laat auditors en klanten zien dat uw taakverdeling overeenkomt met gepubliceerde goede praktijk, niet zomaar een huisaanzicht.
- Maak grijze gebieden duidelijk, zoals wie virtuele firewalls configureert, wie encryptiesleutels beheert en wie virtuele machines, containers of serverloze functies beveiligt.
- Verminder de wrijving bij het onboarden door een gestandaardiseerd verantwoordelijkheidsmodel die overeenkomt met de ISO-richtlijnen.
Door ISO 27017 te vermelden in uw ISMS en klantgerichte documentatie, verandert gedeelde verantwoordelijkheid van een marketingdiagram in iets dat standhoudt tijdens ISO 27001-audits en gesprekken met toezichthouders. ISMS.online helpt u om die verantwoordelijkheidsmodellen, risicoregisters en controlemappings synchroon te houden naarmate uw cloudservices zich ontwikkelen.
Hoe kunnen MSP's overtuigende ISO 27001-auditbewijzen genereren wanneer workloads in de publieke cloud worden uitgevoerd?
U levert overtuigend ISO 27001-bewijs in de publieke cloud door aan te tonen dat uw managementsysteem integreert cloud volledig en dat je cloudplatforms worden consistent beheerd met dat systeem voor alle huurders, regio's en diensten.
Welke ISMS-artefacten moeten duidelijk laten zien dat u AWS, Azure en Google Cloud gebruikt?
Wat het managementsysteem betreft, zullen auditors erop letten dat de cloud expliciet voorkomt in:
- Uw scope-verklaring en context, inclusief de afhankelijkheid van specifieke aanbieders en gedeelde beheerplatforms.
- Risicobeoordelingen: en behandelplannen die cloudspecifieke problemen benadrukken, zoals verkeerde configuratie, identiteitsspreiding, regionale storingen en afhankelijkheden in de toeleveringsketen.
- De Verklaring van toepasbaarheid, vooral waar controles door aanbieders worden geïmplementeerd of met klanten worden gedeeld.
- Interne auditschema's en -rapporten: die betrekking hebben op cloud governance-activiteiten, zoals beoordelingen van landingszones, toegangscontroles en controles op configuratie-afwijkingen.
- Input en output van managementbeoordeling: waar cloudincidenten, wijzigingen en prestatiegegevens worden besproken en beslissingen worden vastgelegd.
Deze artefacten laten zien dat de cloud deel uitmaakt van uw normale Plan-Do-Check-Act-cyclus, en niet iets is dat informeel buiten het ISMS wordt geregeld.
Welk bewijs op cloudniveau biedt ISO 27001-auditors zekerheid?
Op technisch vlak willen auditors doorgaans een combinatie van configuratie-, monitoring- en operationele registraties die aansluiten op uw controlemechanismen, bijvoorbeeld:
- Toegang tot beoordelingsgegevens: voor landingszones, tenantomgevingen en beheertools, inclusief hoe bevoorrechte toegang wordt goedgekeurd en verwijderd.
- Configuratiebasislijnen en driftrapporten: (bijvoorbeeld IaC-sjablonen, beleidspakketten, configuratie-nalevingsdashboards) waarin wordt getoond hoe u verkeerde configuraties kunt detecteren en corrigeren.
- Back-up- en herstelbewijs: zoals back-upschema's, taakrapporten, hersteltestlogboeken en hoe mislukte taken werden afgehandeld.
- Logging- en bewakingsresultaten: , inclusief SIEM-dashboards, voorbeeldwaarschuwingen, afstemmingsrecords en voorbeeldtijdlijnen voor incidenten.
- Wijzigings- en incidenttickets: die laten zien hoe echte gebeurtenissen door uw workflows voor wijzigingsbeheer en incidentbeheer zijn gegaan.
Door dit materiaal in een gestructureerde omgeving te plaatsen - in plaats van screenshots op verschillende consoles te moeten verzamelen - bespaart u tijd en wordt uw verhaal consistenter. ISMS.online helpt u elk bewijsstuk te koppelen aan de relevante risico's, controles en services, zodat u het kunt hergebruiken voor zowel audits als klantgarantiepakketten zonder alles helemaal opnieuw te hoeven opbouwen.
Hoe kan een MSP cloudbewuste ISO 27001-naleving omzetten in een commercieel voordeel?
U zet cloudbewuste ISO 27001-naleving om in een commercieel voordeel door uw beheerde services zo te ontwerpen en te beschrijven dat klanten het gevoel hebben dat u hun beveiligings- en nalevingswerklast verlagen in de publieke cloud, in plaats van dat ze alles zelf moeten samenstellen.
Hoe kunt u publieke clouddiensten zo bundelen dat uw ISO 27001-sterktes duidelijk zichtbaar zijn?
Een praktische aanpak is om een paar benoemde servicelagen die architectuur, zekerheid en prijs met elkaar verbinden:
- Elk niveau combineert een huurdersisolatiemodel (gepoold, hybride, toegewezen) met:
- Gedefinieerde monitoring- en rapportagediepte.
- Overeengekomen frequentie van toegangsbeoordelingen en hersteltesten.
- Duidelijke afspraken over incidentrespons en communicatiepatronen.
Vervolgens ondersteunt u elke laag met:
- Een standaard verantwoordelijkheidsmatrix voor dat niveau, zodat klanten precies zien wat u aanbiedt en wat hen bijblijft.
- Een bijpassende controle- en bewijspakketwaarin u opsomt welke Annex A-thema's u behandelt en welke artefacten klanten kunnen verwachten tijdens het due diligence-onderzoek.
- Herbruikbare RFP en vragenlijstinhoud, zodat uw teams niet voor elke potentiële klant de beveiligingsantwoorden opnieuw hoeven te schrijven.
Vanaf daar kunt u het volgende volgen:
- Winpercentages waarbij kopers expliciet vroegen naar ISO 27001 of beveiliging in de publieke cloud.
- Tijd tussen de eerste veiligheidsvragenlijst en de ondertekening van het contract.
- Verlengings- en uitbreidingsredenen die betrekking hebben op veiligheid, naleving of gemoedsrust.
Met deze gegevenspunten kunt u intern aantonen dat een cloudbewust ISMS niet alleen een kostenpost is voor het zakendoen; het ondersteunt actief de groei met de juiste klanten.
Hoe kan een ISMS-platform het commerciële verhaal gemakkelijker vertellen?
Wanneer risico's, controles, verantwoordelijkheden en bewijs verspreid zijn over teams en tools, is het lastig om simpele vragen van klanten zoals "Hoe houden jullie mijn data veilig in AWS of Azure?" met vertrouwen te beantwoorden. Een speciaal ISMS-platform zoals ISMS.online helpt u:
- Breng uw ISO 27001-maatregelen, multi-cloudarchitecturen en Annex A 5.23-verwachtingen samen in één gestructureerd systeem dat weerspiegelt hoe u werkelijk werkt.
- Zorg dat gedeelde verantwoordelijkheidsmatrices, risicobehandelingen en controletoewijzingen actueel blijven wanneer uw services, regio's en cloudfuncties veranderen.
- Genereer consistente, auditorvriendelijke uitvoer (scope statements, Statements of Applicability, auditrapporten en klantgarantiepakketten) zonder dat u deze telkens opnieuw hoeft op te bouwen als er een nieuwe kans zich voordoet.
Als u wilt dat potentiële klanten en bestaande klanten u ervaren als de MSP die neemt de naleving van de publieke cloud van hun schoudersis het de moeite waard om te onderzoeken hoe een geïntegreerd ISMS-platform uw AWS-, Azure- en Google Cloud-ontwerpen kan verbinden met uw ISO 27001-verplichtingen en de garanties die kopers tegenwoordig standaard verwachten.
