Uw organisatie gebruikt drie verschillende SaaS-platformen. Op papier zijn dat drie afzonderlijke leveranciers. Maar stel dat alle drie uiteindelijk afhankelijk zijn van dezelfde cloudprovider.
Bij een grote storing blijken drie bedrijfsprocessen tegelijkertijd geraakt. Dat is concentratierisico en laat zien waarom cyberrisico verder gaat dan uw directe contractpartij.
Van leverancier naar keten
Een directe leverancier wordt ook wel een third party genoemd. Daarachter kunnen vierde en verdere partijen zitten.
Uw organisatie → SaaS-leverancier → cloudprovider → datacenter → netwerkprovider
Start met kritieke dienstverlening
- primaire leverancier;
- essentiële onderaannemers;
- gebruikte cloudplatformen;
- kritieke koppelingen;
- alternatieven;
- afhankelijkheid van specifieke regio’s of infrastructuur.
Zoek naar single points of failure
- één identityprovider voor alle applicaties;
- één cloudregio;
- één telecomprovider;
- één externe beheerpartij;
- één integratieplatform.
Concentratierisico wordt vaak onderschat
Vraag: hoeveel van onze kritieke diensten zijn afhankelijk van dezelfde achterliggende partij?
Subleveranciers en contracten
Voor kritieke dienstverlening kan het verstandig zijn afspraken te maken over gebruik van belangrijke subleveranciers, materiële wijzigingen, incidentmeldingen, gegevensverwerking, continuïteit en beëindiging.
Test wat er gebeurt wanneer de keten breekt
Scenario: de belangrijkste SaaS-dienst is 48 uur niet beschikbaar.
- welke processen stoppen?
- bestaat een handmatige werkwijze?
- welke data is lokaal beschikbaar?
- wie communiceert met klanten?
- bestaat een alternatieve leverancier?
Koppel ketenrisico aan bedrijfsrisico
Verbind dit met risicomanagement en leveranciersmanagement.
Combineer TPRM en ketenanalyse
Third party risk management richt zich op de beheerscyclus rond uw leveranciers. Ketenrisicomanagement kijkt daarnaast naar relaties en afhankelijkheden achter die leveranciers.
Vijf nuttige ketenvragen
- Welke externe partij is onmisbaar?
- Van welke belangrijke partijen is deze leverancier zelf afhankelijk?
- Hebben meerdere leveranciers dezelfde achterliggende afhankelijkheid?
- Wat gebeurt wanneer die schakel langdurig uitvalt?
- Hebben we een realistisch alternatief?
Mijn IBP brengt kritieke leveranciers, risico’s, maatregelen en acties samen. Bij ernstige verstoringen kan ook een Incident Response Retainer relevant zijn.
Breng verborgen afhankelijkheden boven water
Veel ketenafhankelijkheden zijn niet zichtbaar in het contractregister. Een softwaredienst kan bijvoorbeeld afhankelijk zijn van één identityprovider, DNS-dienst, content delivery network of cloudregio. Wanneer zo’n partij uitvalt, kunnen verschillende leveranciers tegelijkertijd problemen ervaren.
Vraag bij kritieke leveranciers daarom niet alleen welke subverwerkers persoonsgegevens verwerken, maar ook welke technische partijen essentieel zijn voor beschikbaarheid en authenticatie. Daarmee ontstaat een completer ketenbeeld.
Gebruik scenario’s voor concentratierisico
Concentratierisico wordt duidelijker wanneer concrete scenario’s worden getest. Wat gebeurt er bijvoorbeeld wanneer de primaire cloudprovider in een regio acht uur niet beschikbaar is? Welke systemen vallen uit, welke leveranciers worden geraakt en welke handmatige noodprocedures bestaan?
Een ander scenario kan gaan over uitval van de centrale identityprovider. Zelfs applicaties die technisch beschikbaar zijn, kunnen dan onbruikbaar worden omdat medewerkers niet meer kunnen inloggen.
Software supply chain als apart aandachtspunt
Moderne software bestaat uit veel componenten en externe libraries. Een kwetsbaarheid in een veelgebruikte component kan daardoor tegelijkertijd honderden organisaties raken. Uw directe leverancier hoeft zelf niet de oorspronkelijke ontwikkelaar te zijn.
Vraag kritieke softwareleveranciers hoe zij kwetsbaarheden in afhankelijkheden volgen, hoe snel patches worden beoordeeld en hoe klanten worden geïnformeerd wanneer een supply-chainprobleem gevolgen kan hebben.
Ketenrisico en gegevenslocatie
Een leverancier kan aangeven dat gegevens in Europa worden verwerkt, terwijl onderdelen van support, logging of analytics door andere partijen elders worden uitgevoerd. Breng bij gevoelige dienstverlening daarom de relevante gegevensstromen en subleveranciers in kaart.
Dit is zowel een privacy- als securityvraagstuk en kan gevolgen hebben voor contractuele of sectorale verplichtingen.
Maak exit een ketenscenario
Een leverancier vervangen kan moeilijk blijken wanneer dataformaten, koppelingen of licenties sterk afhankelijk zijn van één ecosysteem. Beoordeel daarom vooraf hoe een exit werkt. Kan data in bruikbaar formaat worden geëxporteerd? Is documentatie beschikbaar? Welke kennis moet intern aanwezig zijn?
Een realistische exitstrategie verlaagt niet alleen leveranciersrisico, maar vergroot ook onderhandelingsruimte.
Bestuurlijke rapportage over ketenrisico
Management hoeft niet iedere subleverancier te kennen. Wel moet zichtbaar zijn waar grote concentraties en single points of failure bestaan. Een kort overzicht kan bijvoorbeeld tonen welke vijf externe afhankelijkheden de meeste kritieke processen raken.
Koppel daar continuïteitsmaatregelen en restrisico’s aan. Zo wordt ketenrisico onderdeel van ondernemingsrisicomanagement in plaats van een technisch detail.
Veelgestelde vragen over ketenrisico
Moet ik alle subleveranciers van mijn leverancier kennen?
Niet altijd. Richt u vooral op materiële afhankelijkheden die invloed hebben op kritieke dienstverlening, informatie of compliance.
Wat is het verschil tussen leveranciersrisico en ketenrisico?
Leveranciersrisico kijkt primair naar de directe partij. Ketenrisico kijkt verder naar onderliggende afhankelijkheden en concentraties die meerdere leveranciers of processen tegelijk kunnen raken.
Kan een SLA ketenrisico oplossen?
Nee. Een SLA kan afspraken vastleggen, maar voorkomt geen storing. Continuïteitsmaatregelen, alternatieven en realistische scenario-oefeningen blijven nodig.
Neem ketenrisico mee bij architectuurkeuzes
Ketenrisico kan soms al tijdens ontwerp worden verminderd. Wanneer twee kritieke diensten bewust op verschillende infrastructuur worden geplaatst, kan een organisatie concentratierisico beperken. Andersom kan standaardisatie op één platform kosten besparen maar ook een grotere gezamenlijke afhankelijkheid creëren.
Maak deze afweging expliciet. Architectuurkeuzes zijn niet uitsluitend technisch of financieel; ze beïnvloeden ook continuïteit en risicoprofiel. Leg vast waarom een bepaalde concentratie acceptabel wordt gevonden en welke noodmaatregelen bestaan.
Oefen communicatie tijdens ketenincidenten
Een groot extern incident kan meerdere teams tegelijk raken. Klanten willen informatie, IT onderzoekt de impact, procurement spreekt met leveranciers en management moet besluiten nemen. Oefen daarom niet alleen technisch herstel, maar ook communicatie en escalatie.
Een tabletop-oefening met een fictieve cloud- of identitystoring kan snel laten zien of contactpersonen, beslissingsbevoegdheden en alternatieve processen voldoende duidelijk zijn.
Herzie het ketenbeeld na grote wijzigingen
Een overname, migratie naar een ander cloudplatform of wijziging van een belangrijke subleverancier kan het ketenrisico sterk veranderen. Maak zulke gebeurtenissen daarom tot vaste trigger voor een nieuwe ketenanalyse en actualiseer gekoppelde continuïteitsplannen.
Praktijkvoorbeeld: gedeelde identityprovider
Een organisatie gebruikt verschillende applicaties van verschillende leveranciers. Tijdens een ketenanalyse blijkt dat bijna alle applicaties dezelfde identityprovider gebruiken. Een storing van die provider heeft daardoor veel grotere gevolgen dan uitval van één afzonderlijke applicatie.
Door dit als apart ketenrisico te registreren kan de organisatie noodprocedures, alternatieve authenticatie en communicatie voorbereiden. Het voorbeeld laat zien waarom een lijst met directe leveranciers alleen onvoldoende inzicht geeft in digitale weerbaarheid.
Maak ketenrisico onderdeel van periodieke reviews
Bespreek grote externe afhankelijkheden minimaal periodiek met procurement, IT en management. Nieuwe contracten, migraties en incidenten kunnen het ketenbeeld snel veranderen. Een vaste review voorkomt dat belangrijke afhankelijkheden alleen tijdens een storing zichtbaar worden.
