Waarom MSP-toeleveringsketens nu uw grootste aanvalsoppervlak zijn
Moderne managed service providers worden geconfronteerd met toenemende risico's vanuit ICT-toeleveringsketens, niet alleen vanuit hun eigen datacenters. Upstream tools, platforms en partners kunnen single points of failure worden die, wanneer ze gecompromitteerd of niet beschikbaar zijn, veel klanten en diensten tegelijk beïnvloeden. Bijlage A.5.21 helpt u deze afhankelijkheden te begrijpen, duidelijke beveiligingsverwachtingen af te spreken met leveranciers en klanten en supply chain-risico's te beschouwen als een bewust onderdeel van uw ISMS in plaats van een bijzaak.
Voor veel managed service providers is de toeleveringsketen van tools, platformen en partners waarvan u afhankelijk bent, een van de meest risicovolle onderdelen van uw omgeving geworden, naast uw eigen datacenter. Deze gedeelde componenten vormen de basis van uw omzet, uw contracten en uw wettelijke beloften. Wanneer een van deze componenten uitvalt of gecompromitteerd raakt, kan de impact binnen enkele uren vele klanten bereiken. Daarom is Bijlage A.5.21 zo belangrijk om dat web van afhankelijkheden om te zetten in iets dat u bewust ontwerpt en beheert.
Moderne MSP's erven risico's door de multi-tenant aard van platforms voor extern beheer, cloudservices, identiteitsproviders en nichetools die tussen u en uw klanten in zitten. Eén enkele upstream-compromis kan een aanvaller privileged access geven tot een groot deel van uw klantenbestand. Evenzo kan een storing in een kernplatform meerdere clients tegelijk offline halen, ongeacht hoe goed u uw eigen infrastructuur beheert.
Sterke toeleveringsketens beginnen met weten van wie u echt afhankelijk bent.
De nieuwe realiteit van MSP-toeleveringsketenrisico's
De nieuwe realiteit voor MSP's is dat aanvallers en storingen zich nu sneller via gedeelde ICT-platforms verspreiden dan via individuele klantnetwerken. Wanneer u tools voor extern beheer, cloudservices, identiteitsplatforms en beveiligingsproducten in uw aanbod integreert, wordt elk gedeeld onderdeel een potentieel single point of failure. Bijlage A.5.21 is ontworpen om u te helpen deze realiteit te erkennen en hieromheen proportionele controles te creëren.
Moderne MSP's erven het grootste deel van hun supply chain-risico's via de cloudplatforms, SaaS-tools en onderaannemers die ze in hun diensten integreren. Naarmate u nieuwe diensten ontwikkelt, is het logisch om naast een basispakket aan functionaliteiten ook gespecialiseerde platforms, monitoringtools, back-upproviders en beveiligingsdiensten toe te voegen.
Uit het rapport 'State of Information Security 2025' blijkt dat de meeste organisaties in het afgelopen jaar te maken hebben gehad met minimaal één beveiligingsincident dat werd veroorzaakt door een externe partij of leverancier.
Na verloop van tijd creëert die groei dichte, gelaagde afhankelijkheidsketens: tools voor externe monitoring bovenop de publieke cloud, identiteitsplatforms gekoppeld aan klanttenants, back-upproviders die gegevens tussen regio's repliceren en gespecialiseerde beveiligingstools die via API's zijn geïntegreerd. Aanvallers hoeven niet elke klant afzonderlijk aan te vallen. Het compromitteren van één upstream service kan bevoorrechte toegang verlenen tot meerdere beheerde omgevingen, of ervoor zorgen dat ransomware zich snel verspreidt tussen clients die dezelfde tooling gebruiken. Analyses van incidenten in de software supply chain beschrijven precies dit patroon, waarbij het compromitteren van een veelgebruikte leverancier of component een groot aantal downstream organisaties tegelijk kan treffen (analyse van een software supply chain-aanval).
Storingen gedragen zich op dezelfde manier. Een storing in een centrale identiteitsprovider of een externe beheerstack kan meerdere klanten offline halen, contractuele sancties veroorzaken en de aandacht van de toezichthouder trekken, zelfs als uw eigen infrastructuur niet wordt beïnvloed. Brancherichtlijnen voor het beoordelen en beheren van cyberbeveiligingsrisico's in de toeleveringsketen benadrukken vaak hoe verstoring of inperking van gedeelde cloud- of identiteitsdiensten kan leiden tot gelijktijdige storingen en bedrijfsimpact bij meerdere klanten, evenals contractuele en wettelijke gevolgen voor providers die hiervan afhankelijk zijn (overzicht van cyberbeveiligingsrisico's in de toeleveringsketen). Bijlage A.5.21 richt zich specifiek op die gecombineerde technische en contractuele explosieradius, niet alleen op geïsoleerde kwetsbaarheden.
Beveiligingsstatistieken van veel MSP's zijn nog niet mee met deze verschuiving. Teams volgen nog steeds perimetergebeurtenissen, patchfrequenties en endpointwaarschuwingen, maar hebben weinig zicht op geërfde kwetsbaarheden of incidenten die door leveranciers worden veroorzaakt. Zonder een duidelijk beeld van de upstream-afhankelijkheden en hun risicoprofielen, loopt u feitelijk blind rond op de plekken waar storingen de meeste kans hebben. Daarom hebt u supply chain-overzichten binnen uw ISMS nodig in plaats van alleen netwerkstatistieken.
Waar zichtbaarheid echt tekortschiet
Zichtbaarheid is meestal beperkt in de 'schaduw'-supply chain: tools, diensten en partners die buiten de formele inkoop om zijn binnengekomen. Dit lijken op het moment zelf vaak eenmalige beslissingen, maar ze worden onderdeel van uw permanente afhankelijkheidskaart.
De meeste MSP's kunnen hun primaire leveranciers uit hun hoofd opnoemen, maar weinigen kunnen een compleet beeld schetsen van wie en wat ze werkelijk vertrouwen. Freemium-services die door engineers worden gebruikt, 'tijdelijke' pilottools die nooit eindigen en door de klant verplichte platforms die u hebt geaccepteerd om te ondersteunen, dragen allemaal bij aan die verborgen laag.
Het probleem is dat aanvallers en toezichthouders er niet om geven of een afhankelijkheid formeel is goedgekeurd of stilletjes is overgenomen. Zelfs als een inbreuk via uw beheerde omgevingen binnenkomt, verwachten klanten nog steeds antwoorden van u. Bijlage A.5.21 behandelt deze relaties als binnen de scope. U moet ze opnemen in uw supply chain-overzicht, ze classificeren en voor elk bepalen wat "veilig genoeg" betekent op basis van risico.
Een praktische eerste stap is het in kaart brengen van de explosieradius van uw meest kritieke gedeelde componenten. Schat voor elke belangrijke tool of platform hoeveel klanten, welke soorten data en welke services ervan afhankelijk zijn. Wanneer u beseft dat één enkele beheerstack op afstand een aanzienlijk deel van uw omzet vormt, is dat vaak het moment waarop supply chain-risico's niet langer abstract aanvoelen en gestructureerde controles vereisen.
Waarom uw bestuur net zoveel om u zou moeten geven als uw ingenieurs
Uw bestuur en senior management moeten de beveiliging van de ICT-toeleveringsketen zien als een governance-kwestie, niet alleen als een technische zorg voor engineers. Klanten, verzekeraars en toezichthouders vragen steeds vaker hoe IT-risico's van derden en uitbestede IT worden geïdentificeerd, beoordeeld en beheerst, en ze verwachten coherente antwoorden die verder reiken dan het beveiligingsteam. Brancheorganisaties die software- en ICT-toeleveringsketenbedreigingen monitoren, merken op dat externe stakeholders meer aandacht besteden aan hoe organisaties risico's van derden beheren, niet alleen welke technologieën ze inzetten (toenemende dreiging van aanvallen op de softwaretoeleveringsketen).
Uit het ISMS.online-onderzoek uit 2025 blijkt dat klanten steeds vaker verwachten dat leveranciers zich houden aan formele kaders zoals ISO 27001, ISO 27701, AVG of SOC 2, in plaats van dat ze vertrouwen op algemene claims over goede praktijken.
Wanneer stakeholders zich realiseren dat uw managed services bovenop die van andere aanbieders liggen, die mogelijk zelf doelwit zijn, zoeken ze naar bewijs dat u die schakels begrijpt en beheert. Supply chain security wordt een onderwerp op bestuursniveau, omdat tekortkomingen hier kunnen leiden tot verstoring van de bedrijfsvoering, toezicht door toezichthouders en reputatieschade.
Leiderschap heeft doorgaans de zekerheid nodig dat:
- Kritieke upstream-tools en partners worden geïdentificeerd, er wordt een risicobeoordeling uitgevoerd en contractueel vastgelegd in duidelijke beveiligingsvereisten.
- De organisatie weet welke klanten en diensten getroffen zouden worden door specifieke storingen stroomopwaarts.
- Er zijn beproefde draaiboeken voor incidenten met leveranciers, waarin technische reacties, communicatie en contractuele verplichtingen aan bod komen.
Zonder die zekerheid belanden lastige vragen op het slechtst mogelijke moment in de bestuurskamer: tijdens een storing, een inbreuk of een audit. Door Bijlage A.5.21 te beschouwen als de formele ruggengraat van de zekerheid van uw ICT-toeleveringsketen, geeft u leiders een gestandaardiseerd verhaal waarop ze kunnen vertrouwen, in plaats van geïmproviseerde verklaringen onder druk.
Demo boekenBijlage A.5.21 en de nieuwe definitie van ICT-toeleveringsketenborging
Bijlage A.5.21 vraagt u om passende verwachtingen op het gebied van informatiebeveiliging af te spreken, te documenteren en te handhaven met de ICT-leveranciers en klanten waarvan u afhankelijk bent. In de praktijk moet u weten op wie u vertrouwt, wat u van hen verwacht, wat zij van u verwachten en hoe die verwachtingen in de loop van de tijd worden gecontroleerd. Voor een MSP betekent dit dat u erkent dat u deel uitmaakt van de ICT-toeleveringsketens van veel klanten en dat u uw eigen toeleveringsketen beheert. Dit weerspiegelt de manier waarop ISO/IEC 27001:2022 beheersmaatregel A.5.21 beschrijft in de catalogus met informatiebeveiligingsmaatregelen voor ICT-toeleveringsketens (ISO/IEC 27001:2022 overzicht).
Bijna alle organisaties in het ISMS.online-onderzoek van 2025 noemden het behalen of behouden van beveiligingscertificeringen zoals ISO 27001 of SOC 2 als topprioriteit.
Als we Bijlage A.5.21 serieus nemen, verschuift de borging van de ICT-toeleveringsketen van een gevoel naar een risicogebaseerde, gedocumenteerde praktijk. Het bouwt voort op de bredere reeks van Bijlage A-controles voor leveranciersrelaties, contracten en monitoring, en past deze specifiek toe op ICT-producten en -diensten. Begrijpen hoe Bijlage A.5.19, A.5.20 en A.5.22 zich verenigen, geeft u een kader om dit te doen zonder uw hele ISMS opnieuw uit te vinden.
Met een geïntegreerd ISMS-platform als ISMS.online houdt u dat overzicht op één plek. Leveranciers, klanten, diensten, risico's en Bijlage A-controles worden aan elkaar gekoppeld. Zo kunt u ze eenvoudig beoordelen en bijwerken naarmate uw bedrijf groeit.
Deze informatie is van algemene aard en vormt geen juridisch advies. Organisaties dienen passende professionele begeleiding in te schakelen voor regelgevende beslissingen.
Wat Bijlage A.5.21 eigenlijk verwacht
Bijlage A.5.21 verwacht dat u de beveiliging van de ICT-toeleveringsketen behandelt als een continue, gedeelde verantwoordelijkheid in plaats van een eenmalige contractclausule. Dit versterkt het idee dat verwachtingen risicogebaseerd, gedocumenteerd en in de loop van de tijd gehandhaafd moeten zijn, in plaats van dat ze worden aangenomen of eenmalig worden vastgesteld en vervolgens worden vergeten. Voor MSP's betekent dit dat ze upstream- en downstreamverwachtingen moeten opstellen en moeten controleren of deze relevant blijven naarmate diensten en risico's veranderen.
Bijlage A.5.21 staat naast drie nauw verwante controles:
- A.5.19, waarin het beleid voor leveranciersrelaties wordt behandeld.
- A.5.20, dat zich richt op het waarborgen dat informatiebeveiliging wordt opgenomen in leveranciersovereenkomsten.
- A.5.22, dat betrekking heeft op het toezicht, de beoordeling en het beheer van wijzigingen in de dienstverlening aan leveranciers.
Samen kunnen deze maatregelen in alledaagse taal worden gelezen als: identificeer uw ICT-toeleveringsketen, definieer de informatiebeveiligingseisen die u ervan verwacht, integreer deze eisen in de manier waarop u leveranciers selecteert, contracteert en controleert, en zorg ervoor dat het toezicht gaande blijft naarmate de dienstverlening verandert. Bijlage A.5.21 gaat specifiek over ICT-diensten en -producten, zowel upstream als downstream. Deze titels en groeperingen van maatregelen volgen de structuur die is gepubliceerd in ISO/IEC 27001:2022, waarin de bijlage A-maatregelen en hun aandachtsgebieden voor de beveiliging van leveranciers en ICT-toeleveringsketen zijn vastgelegd (overzicht van ISO/IEC 27001:2022).
Voor een MSP is er nog een extra uitdaging. U bent zowel klant als leverancier. U vertrouwt op upstream ICT-diensten om uw diensten te leveren en u bent een cruciale leverancier in de ICT-toeleveringsketen van uw klanten. Bijlage A.5.21 verwacht dat u beide aspecten consistent beheert op een manier die risico's weerspiegelt en is ingebed in dagelijkse processen, en niet in geïsoleerde documenten.
Standaardtekst omzetten in iets dat iedereen kan begrijpen
De kans is groter dat uw teams zich betrokken voelen als u de taal van de norm vertaalt in een aantal duidelijke, praktische afspraken. Deze afspraken moeten beschrijven wat u daadwerkelijk doet, in termen die engineers, accountmanagers en juridische teams herkennen, in plaats van de norm te citeren.
U kunt Bijlage A.5.21 herformuleren als toezeggingen zoals:
- “We screenen en classificeren de ICT-leveranciers en -platformen waarop we vertrouwen en gebruiken ze wanneer ze voldoen aan de overeengekomen beveiligingscriteria.”
- “Wij definiëren en documenteren wie verantwoordelijk is voor welke beveiligingsmaatregelen in elke beheerde dienst die wij verkopen.”
- “We houden toezicht op belangrijke leveranciers en diensten en reageren snel en transparant als er iets verandert of misgaat.”
Zodra u deze vertalingen hebt, wordt het veel gemakkelijker om te zien waar u al onderdelen van Bijlage A.5.21 hebt geïmplementeerd, zoals onboardingcontroles van leveranciers, contractsjablonen of periodieke beoordelingen. Het geeft ook aan waar praktijken ad hoc, ongedocumenteerd of afhankelijk zijn van individuele medewerkers. Deze inventarisatie biedt u een startpunt voor het meer gedetailleerde upstream- en downstream-ontwerpwerk dat volgt.
Bijlage A.5.21 verwacht dat uw vereisten in verhouding staan tot het risico en niet blindelings van de ene relatie naar de andere worden gekopieerd. Leveranciers en klanten met een grote impact hebben doorgaans behoefte aan een grondigere due diligence en sterkere verplichtingen dan leveranciers en klanten met een kleine impact. Hetzelfde principe maakt uw downstream-contracten beter verdedigbaar tegenover toezichthouders en auditors.
De controle impliceert niet dat u aan elke leverancier of klant identieke, gedetailleerde beveiligingsverwachtingen moet opleggen. Het verwacht van u dat u uw verwachtingen rechtvaardigt in het licht van de risico's. Een kritisch cloudplatform dat klantgegevens host, vereist grondiger due diligence, sterkere contractbepalingen en intensievere monitoring dan een tool met een laag risico en zonder kritieke status.
Dezelfde logica geldt ook stroomafwaarts. Een beheerde dienst die aan een ziekenhuis of financiële instelling wordt geleverd, brengt andere verplichtingen en controles met zich mee dan een dienst die aan een kleine, ongereguleerde onderneming wordt geleverd. Uw implementatie van Bijlage A.5.21 is geloofwaardig wanneer die verschillen zichtbaar zijn in uw risicobeoordelingen en in de manier waarop u overeenkomsten structureert, en niet wanneer elke relatie gebruikmaakt van gekopieerde en geplakte formuleringen, ongeacht de impact.
Het kan helpen om Bijlage A.5.21 af te stemmen op frameworks die u al gebruikt, zoals SOC 2, erkende richtlijnen voor cybersecurity of nationale aanbevelingen voor de toeleveringsketen. Best practices voor de toeleveringsketen van beveiligingsleveranciers en -professionals moedigen u aan om gemeenschappelijke controledoelstellingen in kaart te brengen voor standaarden zoals ISO 27001, SOC 2 en nationale cybersecurityframeworks, zodat teams geen meerdere, conflicterende sets van vereisten hanteren (overzicht van beveiligingspraktijken voor de toeleveringsketen). "Tiering" betekent hier simpelweg het groeperen van leveranciers en klanten in een aantal impactgebaseerde niveaus, in plaats van elke relatie als uniek te behandelen.
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.
Upstream- versus downstream-controles in een MSP-context
In een MSP omvat 'upstream' de leveranciers, platforms en onderaannemers waarop u vertrouwt, terwijl 'downstream' de klanten en huurders omvat die op u vertrouwen. Bijlage A.5.21 is eenvoudiger te implementeren wanneer u deze relaties als afzonderlijk maar gekoppeld behandelt, met duidelijke verantwoordelijkheden en verwachtingen in elke richting. Die structuur vertaalt abstracte supply chain-aangelegenheden in contracten, draaiboeken en dashboards waarmee mensen aan de slag kunnen.
Een helder upstream/downstream-model vertaalt standaardteksten naar werkbare contracten, draaiboeken en dashboards. U kunt vastleggen hoe u leveranciers selecteert en monitort, hoe u de verantwoordelijkheid deelt met klanten en hoe u reageert op incidenten in beide richtingen. Zodra deze structuur op papier staat, wordt het veel eenvoudiger om deze te operationaliseren in tooling en gedrag.
Het definiëren van upstream-, downstream- en hybride relaties
Uw eerste taak is het benoemen en classificeren van de externe relaties waarvan u afhankelijk bent, in plaats van ze allemaal als generieke 'leveranciers' of 'klanten' te behandelen. Deze classificatie bepaalt welke onderdelen van Bijlage A.5.21 het meest van toepassing zijn en waar u uw ontwerpinspanningen op moet richten. Het creëert ook een gemeenschappelijke taal binnen uw organisatie wanneer u supply chain-risico's bespreekt.
Begin met het inventariseren van externe partijen en classificeer ze op basis van twee dimensies: leveren zij aan u, of levert u aan hen, en hoe cruciaal zijn ze voor uw diensten? Een upstream ICT-leverancier kan een leverancier van cloudinfrastructuur, een tool voor remote monitoring, een back-upplatform of een gespecialiseerde beveiligingspartner zijn. Downstream partijen zijn uw klanten voor managed services, inclusief die waarbij u optreedt als gegevensverwerker in het kader van de wetgeving inzake gegevensbescherming.
Sommige relaties zijn hybride. Een peer MSP in een gezamenlijk beheerde overeenkomst levert u bepaalde functionaliteiten en rekent in ruil daarvoor op uw diensten. Een klant die zijn eigen cloudtenant host, maar u vraagt deze te beheren, vervaagt de grens tussen het klantplatform en de upstreamomgeving. Deze hybride relaties vereisen bijzondere aandacht, omdat belangrijke verantwoordelijkheden gemakkelijk door beide partijen of door geen van beide partijen kunnen worden overgenomen.
Zodra u deze rollen hebt vastgelegd, kunt u beginnen met het definiëren van welke categorieën controles van toepassing zijn op welke rollen. Voor upstream-relaties staan due diligence, veilige technische integratie, incidentmelding en controles voor subverwerkers centraal. Voor downstream-relaties zijn gedeelde verantwoordelijkheid, basisbeveiligingsverwachtingen en klantverplichtingen prominenter. Hybride arrangementen vereisen een mix en zeer duidelijke grenzen om hiaten te voorkomen.
Het gebruik van risicogebaseerde niveaus om structuur aan te brengen
Risicogebaseerde niveaus maken van een lange lijst met leveranciers en klanten iets waarmee u kunt werken. Door relaties te groeperen in een aantal impactgebaseerde klassen, kunt u standaard controlesets voor elk niveau definiëren in plaats van elke relatie vanaf nul te moeten ontwerpen.
U kunt bijvoorbeeld drie niveaus creëren voor upstream-leveranciers:
- Niveau 1: kritieke platforms met bevoorrechte toegang of hosting van klantgegevens.
- Niveau 2: belangrijke ondersteunende diensten met beperkte directe toegang tot klantensystemen.
- Niveau 3: tools met een laag risico, zonder toegang tot gevoelige gegevens of productieomgevingen.
Stroomopwaarts kunt u niveaus zoals 'gereguleerd', 'hoge beschikbaarheid' en 'standaard' hanteren, gebaseerd op de gevoeligheid van de gegevens en de impact van uitval op de bedrijfsvoering.
Elke combinatie van upstream- en downstream-niveaus schept verschillende verwachtingen. Een Tier 1 upstream-platform dat ten grondslag ligt aan een gereguleerde zorgcliënt vereist diepere garanties en strengere controles dan een Tier 2-tool die een standaardcliënt ondersteunt. Door deze combinaties in eenvoudige patronen te documenteren - bijvoorbeeld "MSP–hyperscaler–gereguleerde cliënt" versus "MSP–distributeur–MSP–onderneming" - kunt u standaard controlesets ontwerpen in plaats van voor elke nieuwe relatie helemaal opnieuw te beginnen.
Een bondige manier om dit te visualiseren is door gebruik te maken van een kleine matrix die laat zien hoe verantwoordelijkheden verschillen per relatietype.
| Relatie type | Upstream-verantwoordelijkheden (voorbeelden) | Downstream-verantwoordelijkheden (voorbeelden) |
|---|---|---|
| MSP – cloudplatform – gereguleerde klant | Certificeringen, incidentmeldingen, segmentatie, toegangslogboeken | Goedkeuringen, plichten inzake gegevensbescherming, communicatie over klantbeveiliging |
| MSP – SaaS-beveiligingstool – gemengde klanten | Veilige integratie, rolontwerp, monitoring, leveranciersbeoordeling | Klantbewustzijn van de reikwijdte van de tool, toestemming waar nodig |
| MSP – peer MSP (co-managed) – klant | Grensdefinitie, gezamenlijke incidentafhandeling, gedeelde toegang | Klant begrijpt taakverdeling en escalatiepaden |
Zoals de tabel aangeeft, verschillen de verantwoordelijkheden aanzienlijk tussen bijvoorbeeld een hyperscalerscenario en een gezamenlijk beheerde MSP-overeenkomst. In de praktijk kunt u beginnen met het in kaart brengen van uw huidige relaties in een van deze patronen, vaststellen welke taken waar vallen en vervolgens uw contractclausules en interne draaiboeken rond die patronen standaardiseren.
Het ontwerpen van upstream-controles voor leveranciers en subverwerkers
Upstream-controles definiëren hoe u de leveranciers en platforms waarop u vertrouwt selecteert, onboardt, monitort en verlaat. Een eenvoudige, herhaalbare levenscyclus verandert leveranciersvertrouwen van veronderstellingen in bewijs, ondersteund door risicobeoordelingen, contracten en configuratie. Bijlage A.5.21 verwacht dat deze levenscyclus in verhouding staat tot het risico en consistent wordt toegepast op de leveranciers die er het meest toe doen.
Een goed upstream-ontwerp zet vertrouwen om van een informeel oordeel naar een gedocumenteerde beslissing. Dat betekent dat u begrijpt wat elke leverancier voor u doet, welke risico's u erft, welke controles zij hanteren en welke u zelf moet voorzien. Een risicogebaseerde levenscyclus maakt dit beheersbaar en geeft auditors de zekerheid dat u leveranciers niet als een black box behandelt.
Het creëren van een leverancierslevenscyclus die door auditors wordt herkend
Auditors zoeken over het algemeen naar een duidelijke, risicogebaseerde levenscyclus voor kritieke leveranciers: hoe u een leverancier beoordeelt vóór gebruik, hoe u controles inbouwt wanneer u ze implementeert, hoe u toezicht houdt en hoe u veilig uittreedt. Als u deze stappen en het bewijs erachter kunt aantonen, voelt uw Annex A.5.21-verhaal geloofwaardig en compleet aan. Richtlijnen voor leveranciersrisico's van instituten zoals SANS beschrijven risicogebaseerde levenscycli van leveranciers – van selectie, onboarding, doorlopend toezicht tot uittreding – als een kenmerk van volwassen beveiligingsmanagement van derden (whitepaper over leveranciersrisico's van SANS).
Uit het rapport 'State of Information Security 2025' blijkt dat de meeste organisaties het risicomanagement van derden al hebben versterkt en van plan zijn hier verder in te investeren.
Een praktische upstream-levenscyclus bestaat uit vier fasen: due diligence voorafgaand aan de indiensttreding, onboarding, business-as-usual toezicht en exit. Definieer voor elke fase wat er van elke leverancierslaag wordt verwacht en welke artefacten er moeten zijn om aan te tonen dat deze activiteiten hebben plaatsgevonden.
Stap 1: Voer risicogebaseerde due diligence uit
Risicogebaseerde due diligence draait om het verzamelen van voldoende informatie om de beveiligingspositie van een leverancier te begrijpen en hoe deze aansluit bij uw behoeften. Dit omvat doorgaans onafhankelijke certificeringen, algemene beveiligingsverklaringen, testoverzichten, rollen bij de verwerking van persoonsgegevens en informatie over subverwerkers. Het resultaat moet een volledig beoordelingsrapport zijn waarin wordt uitgelegd waarom de leverancier acceptabel is op het gekozen niveau.
Stap 2: Aan boord met concrete technische en contractuele controles
Onboarding vertaalt beoordeling in concrete controles. Voor een kritisch platform kan dit onder meer het configureren van sterke authenticatie, het beperken van beheerdersrollen, het inschakelen en integreren van logging en het afspreken van tijdlijnen en contactpunten voor incidentmeldingen omvatten. Een eenvoudige onboardingchecklist helpt ervoor te zorgen dat deze stappen niet worden overgeslagen en dat er voor elke stap duidelijk iemand verantwoordelijk is.
Stap 3: Houd toezicht op de gebruikelijke gang van zaken
Het gebruikelijke toezicht moet licht maar reëel zijn. Stel voor leveranciers met een grote impact een beoordelingsfrequentie in om te controleren of de certificeringen worden gehandhaafd, de beveiligingsafspraken nog steeds gelden en er geen grote wijzigingen zijn opgetreden zonder uw medeweten. Voor lagere niveaus kunnen beoordelingen worden geactiveerd door gebeurtenissen zoals servicewijzigingen, nieuwe gegevensstromen of incidenten. Registraties van deze beoordelingen, zelfs als ze kort zijn, tonen aan dat er sprake is van actief toezicht in plaats van verondersteld.
Stap 4: Ga veilig naar buiten en werk uw supply chain-kaart bij
Exit wordt vaak over het hoofd gezien, maar is van cruciaal belang. Wanneer u stopt met het gebruik van een leverancier of overstapt naar een nieuw platform, moet er een vastgelegd proces zijn voor het intrekken van toegang, het retourneren of veilig verwijderen van gegevens en het bijwerken van uw documentatie, zodat uw supply chain-kaart accuraat blijft. Een korte exitchecklist en een bijgewerkte registervermelding tonen aan dat u de relatie op een gecontroleerde manier hebt afgesloten.
Auditors verwachten geen perfectie, maar ze verwachten wel dat er een levenscyclus bestaat, dat deze risicogebaseerd is en dat deze in de praktijk wordt gevolgd voor kritische leveranciers.
Geen enkele leverancier is perfect en Bijlage A.5.21 vereist geen perfectie. Er wordt van u verwacht dat u weloverwogen, gedocumenteerde beslissingen neemt over de risico's die u erft en de compenserende maatregelen die u toepast, en dat u deze beslissingen kunt uitleggen aan auditors en klanten.
Niet elke leverancier zal aan alle ideale controles voldoen, en dat hoeft ook niet. Waar het om gaat, is dat u kunt uitleggen waarom een relatie acceptabel is gezien het risico dat deze met zich meebrengt. Tiering helpt, maar u moet ook duidelijk zijn over wanneer u zich op uw gemak voelt bij het overnemen van controles van het eigen beveiligingsframework van een leverancier en wanneer u de voorkeur geeft aan compenserende maatregelen.
Als een grote cloudprovider bijvoorbeeld over algemeen erkende certificeringen beschikt en een strenge beveiligingsstandaard hanteert, is het doorgaans redelijk om daarop te vertrouwen voor veel onderliggende controles, mits u uw configuratie veilig beheert. Voor een kleiner, gespecialiseerd platform met minder formele zekerheid kunt u er daarentegen voor kiezen om de reikwijdte ervan te beperken, specifieke contractuele verplichtingen te eisen of uw eigen monitoring en tests toe te voegen.
Incidentafhandeling verdient speciale aandacht. Voor kernplatformen moeten er expliciete afspraken worden gemaakt over hoe snel u op de hoogte wordt gesteld van een beveiligingsprobleem, welke informatie u ontvangt en hoe u de reacties kunt coördineren om uw klanten te beschermen. Deze verwachtingen kunnen het beste worden vastgelegd in contracten of serviceovereenkomsten in plaats van dat het bij informele afspraken blijft.
Door deze beoordelingen te documenteren in uw risicoregister en de Verklaring van Toepasselijkheid, laat u auditors zien dat Bijlage A.5.21 zorgvuldig wordt toegepast, en niet automatisch. Uw Verklaring van Toepasselijkheid is simpelweg uw formele lijst met beheersmaatregelen van Bijlage A, waarin u uitlegt welke van toepassing zijn, hoe en waarom.
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.
Het ontwerpen van downstream controles voor klanten en hun verplichtingen
Downstream controles definiëren hoe u de verantwoordelijkheid deelt met klanten en wat u van hen verwacht om de veiligheid van diensten te waarborgen. Voor MSP's verkleinen duidelijke downstream controles het risico om verantwoordelijk te worden gehouden voor risico's die bij de klant liggen en tonen ze toezichthouders dat u passende, gedocumenteerde verwachtingen hebt gesteld. Bijlage A.5.21 benadrukt de noodzaak om deze verwachtingen expliciet, afdwingbaar en onderbouwd te maken.
In de praktijk draait downstream control om het stellen van grenzen en ervoor zorgen dat iedereen die begrijpt. U definieert wat u standaard doet, wat klanten moeten doen en hoe u aantoont dat beide partijen hun verantwoordelijkheden nakomen. Wanneer dit goed wordt gedaan, beginnen gesprekken over incidenten, nieuwe eisen of aanvullende diensten vanuit een gedeeld begrip in plaats van een meningsverschil over wie verantwoordelijk is.
Het ontwerpen van servicespecifieke gedeelde verantwoordelijkheidsmodellen
Een bruikbaar model voor gedeelde verantwoordelijkheid vertelt klanten, in begrijpelijke taal, welke onderdelen van de beveiliging u en zij voor een bepaalde dienst beheren. Verschillende dienstfamilies hebben verschillende verdelingen, dus elk heeft zijn eigen, eenvoudige model nodig dat weerspiegelt hoe de dienst in werkelijkheid is ontworpen. In deze context is een model voor gedeelde verantwoordelijkheid simpelweg een duidelijke beschrijving van hoe de beveiligingstaken tussen u en de klant worden verdeeld.
Maak voor elke servicefamilie een model voor gedeelde verantwoordelijkheid dat antwoord geeft op drie vragen:
- Welke configuratie en monitoring biedt u standaard?
- Wat moet de klant doen om dat effectief te maken?
- Hoe gaat u aantonen dat beide partijen hun deel doen?
Voor een beheerde Microsoft 365-service kunnen uw verantwoordelijkheden bijvoorbeeld bestaan uit het configureren van beleid voor voorwaardelijke toegang, het inschakelen van logging en het monitoren van belangrijke waarschuwingen. De verantwoordelijkheden van de klant kunnen bestaan uit het accuraat houden van gebruikersgegevens, het handhaven van beleid voor acceptabel gebruik en het snel reageren op beveiligingsmeldingen. Het aantonen van het model kan bestaan uit periodieke configuratierapporten en gedocumenteerde klantgoedkeuringen.
Deze modellen moeten in toegankelijke taal worden geschreven, hergebruikt in contracten en offertes, en ondersteund worden door interne handleidingen die uw teams laten zien hoe ze aan uw kant van de afspraak kunnen voldoen. Wanneer klanten het model vanaf het begin begrijpen, worden latere gesprekken over beveiligingsincidenten of aanvullende verplichtingen gebaseerd op dat gedeelde begrip in plaats van op ad-hoc verwachtingen.
Het vaststellen van klantverplichtingen en het omgaan met niet-naleving
Klantverplichtingen beschrijven wat klanten moeten doen om uw dienstverlening effectief te maken en hun eigen risico binnen aanvaardbare grenzen te houden. Bijlage A.5.21 verwacht dat u deze verplichtingen duidelijk vastlegt, waar mogelijk bewaakt en vooraf bepaalt hoe u eventuele hiaten aanpakt.
Downstream controles omvatten vaak verplichtingen zoals:
- Onderhoud van ondersteunde besturingssystemen.
- Zorgen dat het personeel de training in beveiligingsbewustzijn voltooit.
- Het inschakelen van multifactorauthenticatie op hun eigen systemen.
- U tijdig op de hoogte stellen van relevante wijzigingen in hun omgeving.
Deze verplichtingen moeten passen bij de service en het risicoprofiel, vastgelegd zijn in contracten of beveiligingsschema's en ondersteund worden door eenvoudige mechanismen om bewijs te verzamelen. Denk hierbij aan periodieke attestaties, technische controles waar u zicht op heeft, of uitkomsten van gezamenlijke beoordelingen.
Het is net zo belangrijk om vooraf te bepalen hoe u met niet-naleving omgaat. Sommige tekortkomingen kunnen worden verholpen; andere kunnen leiden tot uitzonderingen, extra kosten of, in extreme gevallen, weigering om een dienst te verlenen.
Stap 1: Definieer hoe non-conformiteit wordt geïdentificeerd
Bepaal welke verplichtingen u technisch kunt controleren en welke afhankelijk zijn van klantattesten of evaluatiegesprekken. Leg de controles vast in uw processen of tools, zodat non-compliance zichtbaar is.
Stap 2: Bepaal wie uitzonderingen kan verlenen en goedkeuren
Leg vast welke rollen tijdelijke uitzonderingen kunnen goedkeuren, onder welke voorwaarden en voor hoe lang. Dit voorkomt onmiddellijke compromissen die later permanent worden.
Stap 3: Registreer en beoordeel het resterende risico
Zorg ervoor dat uitzonderingen en gevallen van non-compliance worden vastgelegd in uw risicoregister en worden beoordeeld in de juiste governancefora. Dit toont aan dat u het resterende risico beheerst en niet negeert.
Duidelijke downstreammodellen en -verplichtingen zijn aantrekkelijk voor volwassen klanten. Ze laten zien dat u hun risico serieus neemt en dat u bereid bent om redelijke grenzen te stellen en te handhaven in plaats van akkoord te gaan met vage, niet-afdwingbare beloftes.
Bestuur, rollen en levenscyclus voor supply chain-controle
Supply chain security schaalt alleen wanneer iemand er duidelijk eigenaar van is en de rest van de organisatie zijn of haar rol begrijpt. Bijlage A.5.21 wordt duurzaam wanneer het is ingebed in governance, met gedefinieerde rollen, verantwoordelijkheden en evaluatieritmes, in plaats van dat het een informele bijtaak voor security blijft. Effectieve governance draait minder om het organiseren van nieuwe vergaderingen en meer om het stellen van betere vragen in de vergaderingen die je al hebt.
Als de beveiliging van de toeleveringsketen zonder duidelijkheid als "iemands probleem" wordt beschouwd, zal het afdrijven. U moet bepalen wie verantwoordelijk is voor de controle, wie input levert, wie specifieke taken uitvoert en hoe vaak de prestaties worden beoordeeld. Goed bestuur draait om duidelijke beslissingen en regelmatige feedback, niet om meer vergaderingen.
Effectief beheer van de toeleveringsketen betekent dat er tijdens bestaande vergaderingen betere vragen worden gesteld.
Het toewijzen van eigendom en RACI binnen het bedrijf
Een benoemde controle-eigenaar geeft Bijlage A.5.21 een duidelijke plek, maar succes hangt af van gecoördineerde inspanningen op het gebied van inkoop, bedrijfsvoering, juridische zaken en accountmanagement. Een eenvoudig RACI-model maakt duidelijk wie wat doet, wie goedkeurt en wie op de hoogte moet blijven wanneer de risico's voor leveranciers of klanten veranderen.
Een praktisch startpunt is om één controle-eigenaar aan te wijzen voor Bijlage A.5.21, vaak uw informatiebeveiligingsmanager of virtuele CISO. Deze persoon is verantwoordelijk voor het ontwerp en de werking van de controle, maar kan deze niet alleen uitvoeren. Inkoop, juridische zaken, operations en accountmanagement spelen allemaal een rol.
Een eenvoudige RACI-matrix (Responsible, Accountable, Consulted, Informed) helpt. Bijvoorbeeld voor het onboarden van een nieuwe Tier 1-leverancier:
- De afdeling Inkoop is verantwoordelijk voor het waarborgen dat de overeengekomen beveiligingsclausules in het contract zijn opgenomen.
- De informatiebeveiligingsmanager is verantwoordelijk voor het goedkeuren van de risicobeoordeling en het niveau van de leverancier.
- Juridische zaken worden geraadpleegd over complexe termen, uitzonderingen en aansprakelijkheden.
- Operations en accountmanagement worden geïnformeerd over verplichtingen die van invloed zijn op de manier waarop zij diensten leveren.
Wanneer deze verdeling helder is, zien collega's Bijlage A.5.21 niet langer als 'het probleem van de ISO-medewerker', maar beginnen ze te begrijpen wat hun eigen rol is in de oplossing hiervan.
Het kiezen van governance-ritmes die passen bij de bedrijfsvoering
Governance werkt het beste wanneer vragen over de toeleveringsketen worden opgenomen in vergaderingen die er al toe doen, zoals risicocommissies, managementreviews en servicebeoordelingen. Bijlage A.5.21 vereist geen nieuwe bureaucratie; het vereist dat u op het juiste moment de juiste vragen stelt aan leveranciers en klanten en de antwoorden vastlegt.
Controles hebben meer kans om te overleven wanneer ze aansluiten bij ritmes die de organisatie al hanteert. Voor de beveiliging van de toeleveringsketen kan dat het volgende betekenen:
- Belangrijke leveranciers- en klantrisicoonderwerpen opnemen als vaste agendapunten bij bestaande risico- of servicebeoordelingscommissies.
- Plan periodieke beoordelingen van kritieke leveranciers en klanten met een hoog risico in, in lijn met contractcycli of belangrijke wijzigingen.
- Het beoordelen van incidenten en bijna-ongelukken in de toeleveringsketen tijdens evaluaties na het incident en het toepassen van de geleerde lessen op het leveranciers- en klantbeheer.
Vermijd het oprichten van geheel nieuwe commissies, tenzij u ze nodig hebt; verweef in plaats daarvan Bijlage A.5.21 met bestaande governancefora. Uw ISO 27001-managementbeoordeling kan bijvoorbeeld expliciet betrekking hebben op prestaties ten opzichte van supply chain-indicatoren, zoals het aantal kritieke leveranciers zonder actuele beoordelingen, de frequentie van incidenten met leveranciers of de tijdigheid van incidentmeldingen.
Governance zou zich ook moeten uitstrekken tot minder zichtbare relaties, zoals onderaannemers die buiten kantooruren werken of whitelabel-aanbieders die diensten onder uw merknaam leveren. Het plaatje van de toeleveringsketen is niet compleet zonder hen, en incidenten waarbij deze partijen betrokken zijn, kunnen net zo schadelijk zijn. Zorgen dat ze binnen het bereik van risicobeoordeling, contractuele controles en toezicht vallen, maakt deel uit van een geloofwaardige implementatie van Bijlage A.5.21.
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.
Integratie van A.5.19–A.5.22 met risico-, leveranciers- en wijzigingsprocessen
Bijlagen A.5.19–A.5.22 werken het beste wanneer ze verweven zijn met processen die u al gebruikt voor risico-, leveranciers-, wijzigings- en incidentenbeheer. In plaats van ze los te zien van de "ISO-taken", moeten ze worden weerspiegeld in uw risicoregister, inkoopworkflow, wijzigingsmanagement en post-incident reviews, zodat supply chain-denken onderdeel wordt van uw dagelijkse werkzaamheden. Deze integratie zorgt ervoor dat beleidsverklaringen consistent gedrag worden.
Twee derde van de organisaties die deelnamen aan het State of Information Security-onderzoek van 2025 gaf aan dat de snelheid en omvang van de veranderingen in de regelgeving het moeilijker maken om aan de regelgeving te voldoen.
Het ontwerpen van beleid en modellen is noodzakelijk, maar niet voldoende. Supply chain controls werken alleen als ze verweven zijn met de formulieren, tickets en workflows die mensen al gebruiken om wijzigingen aan te vragen, nieuwe tools te implementeren, risico's te beoordelen en te reageren op incidenten. Bijlagen A.5.19–A.5.22 zijn het meest effectief wanneer ze worden weerspiegeld in de manier waarop u risico's registreert, leveranciersbeslissingen neemt, wijzigingen goedkeurt en leert van incidenten.
Supply chain-denken integreren in dagelijkse workflows
De eerste stap is om de risico's in de ICT-toeleveringsketen zichtbaar te maken naast andere risico's. Dit betekent dat u expliciete risico-items moet aanmaken voor kritieke diensten en leveranciers en moet vastleggen hoe u deze risico's wilt aanpakken. Zodra dit is geïmplementeerd, kunt u kleine, verplichte controlepunten toevoegen aan de workflows die uw team al volgt, zodat beslissingen over leveranciers en wijzigingen automatisch aansluiten bij de verwachtingen in Bijlage A.
Begin met ervoor te zorgen dat uw centrale risicoregister de risico's in de ICT-toeleveringsketen expliciet vastlegt. Voor elke belangrijke dienst en kritieke leverancier moeten er risicoposten zijn die de potentiële impact van een storing of inbreuk weergeven, samen met de gekozen maatregelen. Dit plaatst toeleveringsketenrisico's naast andere kwetsbaarheden en helpt leidinggevenden om afwegingen te maken.
Integreer vervolgens controlepunten in de toeleveringsketen in bestaande workflows:
- Inkoopprocessen moeten mogelijkheden bevatten om te controleren of een voorgestelde leverancier in een bepaalde risicoklasse valt, of er een due diligence-onderzoek is uitgevoerd en of de contractsjablonen de vereiste beveiligingsclausules bevatten.
- Wijzigingsverzoeken waarmee belangrijke tools of subverwerkers worden geïntroduceerd of vervangen, moeten automatisch leiden tot een beoordeling van de upstream- en downstream-impact, en niet alleen van de technische compatibiliteit.
- Serviceontwerp- of onboardingprocessen voor nieuwe klanten moeten stappen bevatten om het juiste model voor gedeelde verantwoordelijkheid toe te passen en te bevestigen dat downstream-verplichtingen zijn gedocumenteerd en geaccepteerd.
Deze prompts kunnen vaak met minimale moeite aan formulieren en ticketsjablonen worden toegevoegd, mits ze verplicht zijn voor de scenario's die van belang zijn en de reacties centraal worden vastgelegd, zodat ze worden teruggekoppeld naar uw ISMS-records.
Prestaties meten en leren van incidenten
Je kunt niet verbeteren wat je niet ziet. Bijlage A.5.21 wordt veel waardevoller wanneer je bijhoudt hoe goed de supply chain-controles werken en lessen uit incidenten terugkoppelt naar je niveaus, sjablonen en draaiboeken. Het doel is niet om elk cijfer naar nul te brengen, maar om te begrijpen waar je grootste supply chain-risico's zich werkelijk bevinden en aan te tonen dat je ze beheerst.
Zodra de controles werken, hebt u feedback nodig om ze te verbeteren. Nuttige maatregelen kunnen zijn:
- Het percentage kritische leveranciers met actuele risicobeoordelingen en gedocumenteerde beveiligingsverbintenissen.
- Het aantal en de ernst van incidenten waarbij de hoofdoorzaak te wijten is aan een boven- of onderstroomse relatie.
- De tijd die nodig is om op de hoogte te worden gebracht van relevante incidenten met leveranciers en om te communiceren met de getroffen klanten.
- Het percentage klanten dat belangrijke verplichtingen niet nakomt en hoe vaak er uitzonderingen worden verleend.
Wanneer incidenten zich voordoen, moet een root-cause analyse bewust onderscheid maken tussen upstream fouten, interne problemen en downstream zwakheden. Dat onderscheid geeft aan waar u verwachtingen moet aanscherpen, uw eigen werkwijze moet verbeteren of klantverplichtingen moet aanpassen. Door deze inzichten terug te koppelen aan leveranciersniveaus, contractsjablonen en draaiboeken, wordt uw implementatie van Bijlage A.5.21 daadwerkelijk iteratief en niet statisch.
Een speciaal ISMS-platform helpt u leveranciers, diensten, klanten, risico's en controles op één plek te koppelen, zodat een enkele wijziging of incident traceerbaar is in alle relaties die ermee te maken hebben. Zelfs als u nog niet klaar bent om zo'n platform direct te implementeren, is het ontwerpen van uw processen zodat de benodigde gegevens later centraal kunnen worden vastgelegd een pragmatische stap naar een meer geïntegreerd ISMS.
Boek vandaag nog een demo met ISMS.online
ISMS.online helpt u om Bijlage A.5.21 te transformeren van verspreide leverancierslijsten en contractbepalingen naar één enkel, actueel beeld van uw ICT-toeleveringsketen, controles en bewijs. Door spreadsheets, e-mailverkeer en losse documenten te vervangen door één geïntegreerde omgeving, krijgt u een duidelijker beeld van de upstream- en downstreamrelaties, kunt u verantwoordelijkheden traceren en lastige vragen van klanten en auditors met meer vertrouwen beantwoorden.
Als u vermoedt dat het beantwoorden van een complexe klantenvragenlijst of een ISO 27001:2022-audit nog steeds tot problemen zou leiden, is dat een signaal om een meer gestructureerde aanpak te overwegen. Wanneer uw upstream- en downstreamrelaties duidelijk in kaart worden gebracht, met verantwoordelijkheden en risico's in één oogopslag, geeft dit u een geruster gevoel voor klanten, auditors en leidinggevenden.
Hoe u A.5.21 in een deel van uw toeleveringsketen kunt testen
Een gerichte pilot is de eenvoudigste manier om te zien hoe Bijlage A.5.21 eruitziet wanneer deze volledig is ingebed in een ISMS. In plaats van te proberen uw hele wereld in één keer te modelleren, concentreert u zich op een klein, representatief deel van uw toeleveringsketen en test u of de structuur en tooling daadwerkelijk de inspanning en onzekerheid verminderen.
Een praktische pilot zou kunnen beginnen met één kritisch upstreamplatform en één klant met een hoog risico. U kunt deze relaties importeren in ISMS.online, ze toewijzen aan Bijlage A.5.19–A.5.22 en de belangrijkste artefacten vastleggen: risicobeoordelingen van leveranciers, modellen voor gedeelde verantwoordelijkheid, verplichtingen van klanten en monitoringbewijs. Binnen die beperkte scope kunt u zien of het platform de inspanning daadwerkelijk vermindert, de verantwoordelijkheid verduidelijkt en uw paraatheid voor vragen van auditors en klanten verbetert.
Door de pilot kleinschalig te houden, behoudt u de controle over de scope en voorkomt u dat de toch al drukke teams overbelast raken. Tegelijkertijd geeft u uzelf concrete voorbeelden – een ingevuld risicoregister, een gedocumenteerde leverancierslevenscyclus, een matrix voor gedeelde verantwoordelijkheid – die u aan collega's en leidinggevenden kunt laten zien tijdens de bespreking van de opschaling van de aanpak.
Wat u mee moet nemen naar een ISMS.online-gesprek
U haalt het meeste uit een gesprek over ISMS.online als u begint met een helder beeld van uw huidige supply chain en de uitdagingen die daarbij horen. Een beetje voorbereiding maakt het makkelijker om te zien hoe het platform uw specifieke situatie kan ondersteunen en of het geschikt is voor uw organisatie.
Nuttige invoergegevens zijn doorgaans:
- Een lijst met uw belangrijkste upstream ICT-leveranciers en de services die zij ondersteunen.
- Een korte lijst met klanten met een grote impact, met name die in gereguleerde sectoren.
- Bestaande documenten waarin gedeelde verantwoordelijkheden, verplichtingen van klanten of verwachtingen van leveranciers worden beschreven.
- Voorbeelden van recente incidenten met leveranciers of klanten die moeilijk te beheren waren.
Met deze input kan het ISMS.online-team bekijken hoe uw werkelijke relaties er binnen het platform uit zouden zien en hoe Bijlage A.5.19–A.5.22 in de praktijk tot uiting zouden komen. Het doel is niet om een generieke oplossing voor te stellen, maar om aan de hand van uw eigen voorbeelden te laten zien hoe een gekoppeld ISMS Bijlage A.5.21 kan vereenvoudigen en uw supply chain-verhaal kan verbeteren.
Als u zich in deze scenario's herkent en een meer geïntegreerde aanpak wilt testen, staat ISMS.online klaar om samen met u een gerichte pilot uit te voeren, waarbij uw echte leveranciers en klanten worden gebruikt om te bekijken of een gekoppeld ISMS de juiste volgende stap is voor uw MSP.
Demo boekenVeelgestelde Vragen / FAQ
Hoe verandert ISO 27001:2022 Bijlage A.5.21 de manier waarop een MSP over zijn ICT-toeleveringsketen moet denken?
Bijlage A.5.21 verwacht dat u uw ICT-toeleveringsketen beheert als één beheerd systeem, van cloudplatform tot klantresultaat, en niet als een verzameling losse leveranciers, tools en contracten. Voor een MSP betekent dit dat u een actueel, verdedigbaar beeld nodig hebt van hoe upstream-leveranciers, uw eigen diensten en downstream-klanten met elkaar verbonden zijn en hoe u risico's in die keten beheert.
Wat betekent “end-to-end ICT-toeleveringsketen” eigenlijk voor een MSP?
End-to-end betekent dat u met één service kunt beginnen en het volgende kunt traceren:
- Welke ICT-producten en -diensten waarop u vertrouwt om het te leveren.
- Hoe je eigen platforms en processen in het midden zitten.
- Welke klanten of klantsegmenten worden beïnvloed als er iets kapot gaat.
In plaats van “wij maken gebruik van leverancier X en bedienen klant Y”, gaat Bijlage A.5.21 ervan uit dat u het hele traject begrijpt en beheert: cloud/platforms → MSP-tools en -processen → klantomgevingenAls een kernplatform uitvalt of gecompromitteerd raakt, moet u al weten welke services en tenants hierdoor worden blootgesteld en wat u hieraan gaat doen.
In de praktijk betekent dit dat u:
- Verwijs naar een leveranciersregister waarin ICT-leveranciers worden gekoppeld aan services en risicoklassen.
- Leg in begrijpelijke taal uit wie wat doet (jij, de leverancier, de klant) voor elk type dienst.
- Laat zien dat dit beeld actueel blijft, ook als diensten, leveranciers of regelgeving veranderen.
Als u een auditor door die verdieping kunt leiden aan de hand van alledaagse gegevens in plaats van een eenmalig 'auditpakket', behandelt u Bijlage A.5.21 als onderdeel van de manier waarop u uw bedrijf runt, en dat is precies wat ze willen.
Hoe bouwt Bijlage A.5.21 voort op de overige leveranciersbeheersmaatregelen van Bijlage A.5 voor een managed service provider?
Bijlage A.5.21 neemt de algemene leveranciersthema's uit A.5.19, A.5.20 en A.5.22 over en past deze specifiek toe op de ICT-stack die ten grondslag ligt aan uw managed services. Het gaat minder om het bedenken van nieuwe processen en meer om het verbinden van leveranciersselectie, contracten, monitoring en verandering tot één samenhangende aanpak voor ICT-producten en -diensten.
Hoe passen de leverancierscontroles van Bijlage A.5 in de ICT-toeleveringsketen van een MSP?
U kunt de vier bedieningselementen als één stroom beschouwen:
- A.5.19 – Informatiebeveiliging in leveranciersrelaties: Bepaal waar beveiliging van belang is in uw leverancierslandschap en hoe u dit meeneemt in uw keuzes.
- A.5.20 – Informatiebeveiliging in leveranciersovereenkomsten aanpakken: Zet deze verwachtingen om in heldere clausules, addenda en servicebeschrijvingen.
- A.5.21 – Informatiebeveiliging beheren in de ICT-toeleveringsketen: Pas die gedachtegang toe op het specifieke web van ICT-platformen, tools en integraties die onder uw beheerde services vallen.
- A.5.22 – Monitoring, beoordeling en wijzigingsbeheer van leveranciersdiensten: Houd de risico's en prestaties van leveranciers nauwlettend in de gaten en reageer op incidenten en veranderingen.
Voor een MSP vertaalt dit zich doorgaans in drie zichtbare mogelijkheden:
- A samengevoegd register waarbij ICT-leveranciers gebonden zijn aan diensten, risicoclassificaties en contractuele verplichtingen.
- A consistent patroon voor de manier waarop u ICT-leveranciers onboardt, controleert en verlaat, in plaats van eenmalige beslissingen in e-mails.
- A traceerbare link van die activiteiten tot klantgerichte beloften en uw interne risicoregister.
Met een platform zoals ISMS.online kunt u deze punten eenvoudiger met elkaar verbinden, omdat u leveranciers, contracten, risico's en controles in Bijlage A.5.19-A.5.22 op één plek kunt bewaren. Zo kunt u auditors en klanten laten zien dat u een ICT-toeleveringsketen beheert, en niet slechts een archiefkast met overeenkomsten.
Hoe moet een MSP een upstream ICT-leverancierslevenscyclus ontwerpen die voldoet aan Bijlage A.5.21 zonder het team te overbelasten?
De meest effectieve manier om aan Bijlage A.5.21 te voldoen, is door één herhaalbare leverancierslevenscyclus te definiëren en vervolgens de controlediepte te schalen op basis van risico, niet op basis van gissingen. Uw team hoeft slechts één patroon te leren en u reserveert grondige due diligence voor de leveranciers die u of uw klanten echt schade kunnen berokkenen.
Hoe ziet een praktische, herhaalbare ICT-leverancierslevenscyclus eruit voor een MSP?
Een eenvoudige levenscyclus met vier fasen zorgt doorgaans voor een evenwicht tussen inspanning en zekerheid:
- Selecteer: Classificeer de leverancier op impact voordat u zich vastlegt. Een platform dat klantgegevens verwerkt of zich midden in uw externe beheerstack bevindt, verdient grondigere controles dan een nutsvoorziening met een lage waarde.
- Aan boord: Zet uw verwachtingen om in concrete controles. Configureer toegang, logging, wijzigingsmeldingen, ondersteuningskanalen en exitvoorwaarden voordat u live gaat.
- Bedienen: Evalueer prestaties en risico's met een verstandige frequentie. Plan voor kritieke platforms ten minste een jaarlijkse evaluatie, plus controles na beveiligingsadviezen, incidenten of significante servicewijzigingen.
- Exit: Plan hoe u gegevens verwijdert of migreert, toegang intrekt, afhankelijkheden wijzigt en uw eigen documentatie bijwerkt wanneer u een leverancier verlaat of een downgrade uitvoert.
U hebt geen complexe tools nodig om aan te tonen dat u deze levenscyclus volgt. Een goed onderhouden leveranciersregister, korte due diligence-notities, eenvoudige onboarding checklists en eenvoudige reviewrapporten geven auditors al een duidelijk signaal dat u ICT-leveranciers als onderdeel van uw ISMS beschouwt.
ISMS.online kan dit verder versterken door het leveranciersregister, de levenscyclusgegevens en de bijbehorende controles in Bijlage A.5.19–A.5.22 in één omgeving te bewaren. Zo houdt u het proces overzichtelijk voor uw team en presenteert u tegelijkertijd een duidelijk, consistent patroon aan klanten, auditors en partners.
Hoe kan een MSP de gedeelde verantwoordelijkheden met klanten stroomafwaarts definiëren, zodat Bijlage A.5.21 wordt gedekt, zonder dat elk contract een juridische roman wordt?
Stroomopwaarts is Bijlage A.5.21 voldoende wanneer uw klanten in begrijpelijke taal kunnen zien wat u standaard beveiligt, wat ze zelf moeten doen en hoe u samenwerkt wanneer er iets verandert of misgaat. U hebt geen specifieke juridische tekst nodig voor elke deal, maar wel een kleine set gedeelde verantwoordelijkheidspatronen die uw teams begrijpen en consistent toepassen.
Hoe ziet een werkbaar model voor gedeelde verantwoordelijkheid eruit voor gemeenschappelijke MSP-services?
Een praktisch patroon is om modellen per servicefamilie te standaardiseren en de structuur telkens identiek te houden. Definieer voor elke familie vier blokken:
- Service scope: Wat deze beheerde service omvat en wat niet.
- Jouw verantwoordelijkheden: Bijvoorbeeld basisconfiguratie, logging, back-up, monitoring, afhandeling van kwetsbaarheden en coördinatie van incidenten.
- Verantwoordelijkheden van de klant: Denk bijvoorbeeld aan het ondersteunen van eindpunten, het afdwingen van multifactorauthenticatie, het beheren van nieuwe leden/verlaters en het informeren over belangrijke wijzigingen.
- Gedeelde verantwoordelijkheden: U kunt bijvoorbeeld beoordelingen uitvoeren, wijzigingen met een hoog risico goedkeuren of communicatie over incidenten voeren.
Je kunt deze modellen vervolgens op verschillende manieren uitdrukken:
- Slips verantwoordelijkheidsmatrices in voorstellen, werkomvang en onboardingdocumenten.
- Beveiligingsaddenda: die aan contracten worden gekoppeld zonder dat de volledige voorwaarden opnieuw worden geschreven.
- Interne runbooks: die uw teams gebruiken bij het onboarden, uitvoeren en afhandelen van incidenten.
Wanneer een klant een uitzondering nodig heeft, documenteert u die afwijking expliciet in plaats van het model stilzwijgend te verruimen. Zodra deze patronen en uitzonderingen in uw ISMS aanwezig zijn en in uw risicoregister worden weergegeven, kunt u aantonen dat downstream-risico's bewust in plaats van informeel worden aangepakt. Dat is precies wat Bijlage A.5.21 beoogt te testen.
Met ISMS.online beschikt u over een centrale plek waar u deze modellen kunt opslaan en hergebruiken, ze kunt koppelen aan specifieke diensten en klanten en de contractvoorwaarden, interne draaiboeken en risico-items op elkaar kunt afstemmen naarmate uw portefeuille groeit.
Hoe kan een MSP een complex web van leveranciers, platforms en klanten omzetten in een overzichtelijke risicokaart voor de ICT-toeleveringsketen die voldoet aan de Annex A.5.21-beoordelingen?
De eenvoudigste manier om een zinvolle risicokaart voor uw toeleveringsketen te maken, is door te beginnen met hoe uw dienstverlening vandaag de dag daadwerkelijk verloopt, in plaats van met een statische leverancierslijst. Wanneer u gegevensstromen en controlepunten van links naar rechts volgt, komen de relaties die het belangrijkst zijn voor Bijlage A.5.21 vanzelf naar voren.
Welke praktische stappen kunt u gebruiken om een ICT-toeleveringsketen in kaart te brengen die auditors kunnen volgen?
U kunt de kaart in drie onafhankelijke stappen bouwen die elkaar versterken:
- Serviceweergave: Maak een lijst van uw beheerde services (bijvoorbeeld beheerd Microsoft 365, beheerde eindpunten, beheerde back-up, gezamenlijk beheerde cloud) en noteer van welke upstreamplatforms, tools en integraties elke service afhankelijk is.
- Relatieweergave: Vermeld voor elke dienst:
- De stroomopwaarts ICT-leveranciers en platformen die essentieel zijn.
- De stroomafwaarts Klanten of klantgroepen die van die dienst gebruikmaken.
- Risicoweergave: Voor elk leveranciers- of klantsegment met een grote impact registreert u een afzonderlijk risico waarin het volgende wordt vermeld:
- Wat er redelijkerwijs mis zou kunnen gaan (bijvoorbeeld uitval, datalek, wijziging van licentie).
- Welke invloed dat zou hebben op uw dienstverlening en de resultaten voor uw klanten.
- Welke controlemaatregelen, contractvoorwaarden en operationele praktijken verminderen de waarschijnlijkheid of impact?
Veel MSP's vinden een eenvoudig diagram handig, zelfs als u het nooit extern laat zien: cloud/platforms → MSP-tools en -processen → klantomgevingen, met kleuren of pictogrammen om het relatieve risico weer te geven. Die afbeelding helpt u te bepalen waar u moeite in moet steken en geeft auditors en klanten een eenvoudige manier om uw afhankelijkheden te begrijpen.
In ISMS.online kunt u deze structuur spiegelen door diensten, leveranciers, klanten en risico's in één omgeving te koppelen. Dit maakt het veel eenvoudiger om te laten zien hoe een nieuw platform of een nieuwe klant aan de kaart wordt toegevoegd, hoe deze wordt geclassificeerd en hoe gerelateerde risico's en verantwoordelijkheden consistent worden bijgewerkt.
Welke dagelijkse registraties overtuigen ISO 27001-auditors ervan dat een MSP daadwerkelijk Bijlage A.5.21 beheert, in plaats van het alleen maar in de documentatie te benoemen?
Auditors zijn doorgaans meer geïnteresseerd in de vraag of uw dagelijkse administratie een samenhangend verhaal vertelt dan in hoe indrukwekkend uw tools eruitzien. Voor Bijlage A.5.21 willen ze zien dat u begrijpt waar risico's in de ICT-toeleveringsketen vandaan komen, een herhaalbare aanpak toepast en die aanpak kunt aantonen zonder een tweede bedrijf op te zetten dat zich bezighoudt met het controleren van de documentatie.
Welke normale artefacten voldoen doorgaans aan Bijlage A.5.21 voor MSP's zonder een parallelle 'auditindustrie' te creëren?
Bij de meeste MSP's is een compacte set records voldoende, zolang deze compleet is en actueel wordt gehouden:
- A leveranciersregister dat ICT-leveranciers vermeldt, koppelt aan diensten, hun risicoclassificatie weergeeft en de datum van de laatste beoordeling vastlegt.
- Kort due diligence-notities voor leveranciers met een hoger risico, zoals verwijzingen naar certificeringen, antwoorden op vragenlijsten of beknopte risicobeoordelingen.
- Contracten of beveiligingsaddenda: waarin de verwachtingen op het gebied van beveiliging, regels voor het melden van incidenten, gegevensverwerking en voorwaarden voor subverwerkers worden vastgelegd.
- Monitoring- en beoordelingsgegevens: , zoals servicebeoordelingstickets, notulen van controles bij leveranciers of beoordelingen na incidenten die laten zien hoe u hebt gereageerd.
- Gedeelde verantwoordelijkheidsmodellen: en gerelateerde clausules in klantcontracten, plus echte voorbeelden van hoe u handelt wanneer verplichtingen aan beide kanten niet worden nagekomen.
In plaats van aparte 'audit packs' te maken, is het doorgaans efficiënter om ervoor te zorgen dat uw normale documenten (onboarding-checklists, wijzigingsrecords, runbooks, incident- en probleembeoordelingen) automatisch het bewijs achterlaten waar een auditor om vraagt.
Als u deze artefacten centraliseert in ISMS.online en ze expliciet koppelt aan Annex A-controles en relevante risico's, kunt u snel auditvragen en klantvragenlijsten beantwoorden door ze vanaf één plek te filteren en te exporteren. Na verloop van tijd vermindert dit de auditstress, verkort het de verkoopcycli en zorgt het ervoor dat uw team erkend wordt voor het runnen van een goed beheerde ICT-toeleveringsketen, in plaats van elk jaar opnieuw dezelfde verdieping op te moeten bouwen.
Hoe kan een MSP ISMS.online gebruiken om Bijlage A.5.21 te integreren in de normale werkzaamheden in de toeleveringsketen in plaats van het te behandelen als een eenmalig nalevingsproject?
Bijlage A.5.21 wordt beheersbaar wanneer het geïntegreerd is in de manier waarop u diensten inkoopt, levert en beoordeelt, niet wanneer het als een op zichzelf staande standaard wordt beschouwd die u kunt afvinken. ISMS.online ondersteunt die verschuiving door u één omgeving te bieden waarin u leveranciers, diensten, klanten, risico's, controles en bewijsmateriaal kunt verbinden, zodat dagelijkse handelingen Bijlage A.5.21 op natuurlijke wijze in goede staat houden.
Hoe ziet het eruit als Bijlage A.5.21 daadwerkelijk operationeel is in ISMS.online?
Een realistisch patroon voor veel MSP's ziet er als volgt uit:
- Je onderhoudt een live leveranciersregister in ISMS.online ICT-leveranciers classificeren op basis van impact en elke leverancier koppelen aan de beheerde services en Annex A.5.19–A.5.22-controles die deze ondersteunt.
- Je vangt due diligence, onboarding, monitoring en exit-activiteiten als normale werkzaamheden of taken, dus het bewijsmateriaal dat u nodig hebt voor Bijlage A.5.21 verzamelt zich automatisch terwijl uw team met leveranciers werkt.
- Je slaat op en hergebruikt gedeelde verantwoordelijkheidsmodellen als gestructureerde content, waarbij deze worden gekoppeld aan servicefamilies en klantgroepen, zodat contracttaal, runbooks en risico-items op elkaar afgestemd blijven.
- Je linkt risico's voor zowel toeleveranciers als klanten stroomafwaarts. Een verandering in één deel van de keten heeft dus direct invloed op uw beeld van de algehele blootstelling van de toeleveringsketen.
Een laagdrempelige manier om te beginnen is door één belangrijke service, één kritisch upstreamplatform en één representatieve klant te kiezen, die keten van begin tot eind te modelleren in ISMS.online en vervolgens een echte wijziging of incident via het systeem uit te voeren. Als uw teams en uw auditor het gemakkelijker vinden om afhankelijkheden te zien, verplichtingen uit te leggen en bewijs te verzamelen op basis van dat ene voorbeeld, heeft u een sterke interne reden om dezelfde aanpak uit te breiden naar een groter deel van uw ICT-toeleveringsketen.
Na verloop van tijd zorgt deze manier van werken ervoor dat uw bedrijf niet alleen wordt gezien als "systemen draaiende houden", maar ook als een bedrijf dat een traceerbare, goed beheerde ICT-toeleveringsketen beheert die bestand is tegen klantvragenlijsten en ISO 27001-audits, met veel minder verstoring van uw dagelijkse werkzaamheden. Wanneer u klaar bent om dat verhaal aan een klant of auditor te laten zien, biedt ISMS.online u alles wat u nodig hebt op één plek, in plaats van dat u het onder druk zelf moet samenstellen.
