Welke IT-risico's zien de meeste organisaties over het hoofd?

Wat is afhankelijkheidsrisico in IT, en waarom wordt het over het hoofd gezien?

Afhankelijkheidsrisico is de kans dat een systeem dat je niet zelf beheert uitvalt en daarmee je processen, of je herstel, meetrekt. Het wordt over het hoofd gezien omdat risicoregisters de systemen opsommen die een IT-team zelf beheert, niet de leveranciers waar die systemen op leunen.

Het is maandagochtend. Je servers staan aan en de back-uptaken van vannacht staan op groen. Maar je CRM-leverancier ligt eruit, de koppeling die orders synchroniseert is gestopt en de remote-tooling van je IT-dienstverlener (MSP) is offline na een beveiligingsincident. Niets van jou is uitgevallen, en toch kan niemand werken.

Inzicht in endpoints (laptops, desktops en mobiele apparaten), bijvoorbeeld via een EDR Platform, laat zien wat er op je eigen apparaten draait. Het vertelt je niet wat er gebeurt als een leverancier hogerop in de keten uitvalt.

Een typische afhankelijkheidsketen

Een middelgrote organisatie in Nederland of Duitsland kan afhankelijk zijn van:

• Microsoft 365 of Google Workspace voor e-mail, bestanden en samenwerking
• Een SaaS-platform voor CRM of ERP, voor verkoop, financiën en klantdata
• Een integratielaag of iPaaS (een platform dat data tussen systemen verplaatst)
• Een MSP die infrastructuur, patches en toegang op afstand beheert
• Een back-upleverancier die de kopieën bewaart waaruit je zou herstellen

Hoe vaak leiden storingen bij leveranciers echt tot uitval?

Vaak genoeg dat Europese en nationale autoriteiten het inmiddels als een kernbedreiging zien. Meerdere recente incidenten laten zien dat één leverancier duizenden organisaties tegelijk kan raken.

• Gecompromitteerde leverancier. In de Threat Landscape for Supply Chain Attacks (2021) stelde ENISA vast dat in 66% van de geanalyseerde aanvallen op de toeleveringsketen de leveranciers niet wisten, of niet meldden, hoe ze waren gecompromitteerd.
• Eén tool, veel slachtoffers. Volgens CISA-advisory AA23-158A begon de ransomwarebende CL0P op 27 mei 2023 met het misbruiken van een zero-day (een nog onbekende kwetsbaarheid) voor SQL-injectie (CVE-2023-34362) in Progress MOVEit Transfer en stal ze data uit de onderliggende databases. Elke organisatie die de tool voor bestandsoverdracht aan internet had hangen, liep risico via hetzelfde product.
• Eén foutieve update. Op 19 juli 2024 liet een update van CrowdStrike Windows-machines wereldwijd crashen. Microsoft schatte dat 8,5 miljoen Windows-apparaten getroffen waren, minder dan 1% van alle Windows-machines. Toch raakten luchtvaartmaatschappijen, ziekenhuizen en banken ontregeld, door de plek waar die apparaten stonden.
• Eén gedeelde IT-dienstverlener. In oktober 2023 verstoorde een ransomware-aanval op de gemeentelijke IT-dienstverlener Südwestfalen-IT de dienstverlening in meer dan 70 Duitse gemeenten, van inwonerregistratie tot de burgerlijke stand, meldde The Record.

De ENISA Threat Landscape 2025 beschrijft hetzelfde patroon: digitale infrastructuur en diensten in de EU blijven doelwitten met een hoge waarde, "met name bij incidenten waarbij cyberafhankelijkheden worden gebruikt als lanceerplatform voor vervolgaanvallen".

Waarom komen afhankelijkheidsrisico's niet naar voren in IT-audits?

Omdat de meeste audits nagaan of je eigen maatregelen bestaan, niet of je kunt blijven werken als de maatregelen van een ander falen. Drie blinde vlekken komen steeds terug.

1. Geen afhankelijkheidskaart. Teams leggen de systemen vast die ze zelf beheren. Diensten van derden worden zelden in kaart gebracht met hun storingsscenario's, eigenaren en de processen die ervan afhangen.
2. De aanname dat het beschikbaar blijft. Een uptime-SLA van een SaaS-leverancier is makkelijk aan te zien voor een herstelbelofte. Dat is hij niet. Een beschikbaarheidsdoel van 99,9% zegt niets over je data terugkrijgen na een onbedoelde verwijdering, een kwaadwillende beheerder of een synchronisatiefout die goede records overschrijft.
3. Toegang die je niet beheerst. Veel platforms bepalen zelf de toegang tot je eigen data. Ligt de leverancier eruit, schorst hij je tenant (je eigen omgeving bij het platform) of beperkt hij de toegang tijdens een incident, dan kun je mogelijk niets exporteren of terugzetten, soms zelfs niet uit een back-up die afhankelijk is van de inloggegevens of API's van dat platform.

Het gevolg is een kloof tussen een back-up hebben en kunnen herstellen. Daar zijn de meeste organisaties kwetsbaar. De kant van SaaS bespreken we uitgebreider in wat er gebeurt als je SaaS-leverancier uitvalt.

Is een back-up genoeg als je van derden afhankelijk bent?

Ja, maar alleen als back-ups onafhankelijk zijn opgezet van de systemen die ze beschermen. Een back-up die binnen het falende platform staat, of alleen via dat platform kan worden teruggezet, valt samen met dat platform om.

Klassieke back-upontwerpen gaan stilzwijgend uit van drie dingen: de herstelomgeving is beschikbaar, systemen kunnen één voor één worden teruggezet en je houdt toegang tot het platform waar de data staat. In een verbonden omgeving kunnen alle drie tegelijk wegvallen. Dat gebeurde in 2024 bij het Australische pensioenfonds UniSuper, dat herstelde met kopieën bij een andere leverancier. We bespreken de lessen in UniSuper en back-ups bij derden.

De 3-2-1-1-0-regel is een praktische basis: drie kopieën, op twee soorten media, één off-site, één onveranderbaar of offline, en nul fouten na verificatie. Vergeet endpoints niet: die bevatten vaak werkbestanden die nooit op een server komen. Zie endpoint-back-up bij hybride werken.

Hoe verklein je verborgen afhankelijkheidsrisico's? Een aanpak in 4 stappen

Begin met inzicht, maak herstel daarna onafhankelijk en bewijs dat het werkt. Deze vier stappen passen bij het IT-team van een mkb-bedrijf of bij een MSP die de oefening voor een klant uitvoert.

1. Breng elke externe afhankelijkheid in kaart

• Maak een lijst van elk SaaS-platform, elke clouddienst, MSP, koppeling en API die je gebruikt.
• Noteer welk proces ervan afhangt, welke data erin staat en wie de beheerdersinloggegevens en versleutelingssleutels heeft.

2. Beoordeel herstel, niet alleen beschikbaarheid

• Kunnen we deze data terugzetten zonder dat de leverancier online is?
• Hoe lang kan het proces zonder dit systeem? Dat is je RTO, de maximale hersteltijd die je je kunt veroorloven.
• Hoeveel data kunnen we kwijtraken? Dat is je RPO, het maximale dataverlies: hoeveel werk je mag verliezen. In onze uitleg over RTO en RPO lees je hoe je beide bepaalt.
• Wat doen we als de leverancier de toegang beperkt tijdens een eigen incident?

3. Bouw een onafhankelijke herstelroute

• Bewaar back-upkopieën buiten de productieomgeving, bij een andere leverancier dan degene die het meest waarschijnlijk uitvalt.
• Gebruik aparte inloggegevens en eis MFA voor het beheer van back-ups.
• Maak minstens één kopie onveranderbaar en één air-gapped.
• Dek ook SaaS-data en endpoints af, niet alleen servers.

4. Test de uitval van een leverancier, niet alleen een servercrash

• Voer minstens één hersteltest per jaar uit waarbij een belangrijke leverancier niet beschikbaar is.
• Controleer dat het draaiboek geen toegang nodig heeft tot het systeem dat is uitgevallen.
• Noteer de hersteltijden die je haalt en vergelijk ze met je RTO.

Verplicht NIS2 je om afhankelijkheidsrisico te beheersen?

Ja, voor organisaties die eronder vallen. Richtlijn (EU) 2022/2555 verplicht essentiële en belangrijke entiteiten tot risicobeheersmaatregelen die continuïteit en leveranciers uitdrukkelijk omvatten.

• NIS2-artikel 21(2)(c): bedrijfscontinuïteit, zoals back-upbeheer en disaster recovery, en crisisbeheer.
• NIS2-artikel 21(2)(d): ketenbeveiliging, inclusief de relaties tussen elke entiteit en haar directe leveranciers of dienstverleners.
• NIS2-artikel 21(3): entiteiten moeten rekening houden met de kwetsbaarheden van elke directe leverancier en dienstverlener en met de kwaliteit van hun cyberbeveiligingspraktijken.
• NIS2-artikel 20: bestuursorganen keuren deze maatregelen goed, houden er toezicht op en kunnen aansprakelijk worden gesteld.

In Nederland is de Cyberbeveiligingswet (Cbw) op 15 augustus 2026 in werking getreden. In Duitsland geldt de NIS2UmsuCG sinds 6 december 2025. Zie het overzicht van artikel 21 en onze gids over NIS2-ketenbeveiliging.

Wat je nu kunt doen

Je grootste risico is waarschijnlijk geen ontbrekende back-up. Het is een back-up die je niet kunt terugzetten, omdat de leverancier, het platform of de tool waarvan hij afhangt juist is uitgevallen. Breng je afhankelijkheden in kaart, geef elke kritieke afhankelijkheid een herstelroute die zonder haar werkt en test die route minstens één keer per jaar.

Mindtime is gebouwd om die onafhankelijke kopie te zijn. Back-ups staan alleen in onze eigen Tier III-datacenters in Nederland en Duitsland, onder EU-recht en onafhankelijk van de grote Amerikaanse cloudaanbieders, als onveranderbare kopieën (Object Lock) plus een air-gapped kopie. Elke back-uptaak wordt automatisch gecontroleerd, back-ups worden gescand op malware en je kunt virtuele machines (VM's) direct opstarten in een geïsoleerde herstelomgeving op een apart, schoon netwerk. Voor MSP's voegt ons EDR Platform inzicht in endpoints toe bij elke klanttenant, terwijl de MSP de dienst zelf beheert.

Wil je weten welke afhankelijkheden jouw herstel zouden blokkeren? Vraag een gratis assessment aan.

Dit artikel is algemene informatie, geen juridisch advies.