Ketenincidenten oefenen: hoe test je of je keten uitval overleeft?

Ketenincidenten oefenen doe je met een tafeloefening van twee uur: kies een echte kritieke leverancier, schets een uitval van drie dagen en laat IT, inkoop, directie en communicatie in hun eigen rol besluiten nemen. Leg daarna vast wat er miste, met een eigenaar en een datum per verbeterpunt.

Ketenincidenten oefenen betekent dat je nabootst wat er gebeurt als niet jouw organisatie wordt geraakt, maar een leverancier waarvan je afhankelijk bent. Dat is een ander scenario dan een aanval op jezelf, want je hebt geen toegang tot de systemen, geen zicht op de oorzaak en geen controle over het herstel. Juist daarom valt een oefening op dit scenario bijna altijd anders uit dan verwacht.

Het is ook het meest waarschijnlijke scenario geworden. Grote incidenten van de afgelopen jaren kwamen zelden binnen via de voordeur van de getroffen organisatie, maar via een softwareleverancier of een beheerpartij. In dit artikel lees je hoe je zo’n oefening opzet zonder dat het een dagvullend project wordt.

Kort samengevat

• Ketenincidenten oefenen richt zich op besluitvorming en niet op techniek, want een incident bij een leverancier kun je niet zelf oplossen.
• Een tafeloefening van twee uur levert meer op dan een technische test van een dag.
• Neem inkoop en directie mee, niet alleen IT: de knelpunten zitten in mandaat en communicatie.
• De drie gaten die er standaard uit komen: geen actuele contactgegevens, geen mandaat om te besluiten, geen beeld van wie geinformeerd moet worden.
• Leg de uitkomst vast als verbeterpunten met een eigenaar, anders is het een gesprek geweest.

Waarom ketenincidenten oefenen anders werkt dan een gewone oefening

Bij een incident in je eigen omgeving heb je knoppen. Je kunt isoleren, uitzetten, terugzetten. Bij een ketenincident heb je die knoppen niet: je wacht op iemand anders, terwijl je eigen klanten of patienten wel bij jou aankloppen.

Wat je in die situatie nodig hebt is geen technisch draaiboek maar helderheid over besluiten. Wie bepaalt dat je overschakelt op een noodproces? Wie mag zeggen dat de koppeling met die leverancier eruit gaat, terwijl dat de dienstverlening raakt? Wie communiceert er naar buiten, en wat zeg je als je de oorzaak niet weet?

Daar zit ook de link met je eigen verplichtingen. Een incident bij een leverancier kan voor jou meldingsplichtig zijn. Bekijk daarom voor de oefening de meldtermijnen bij een incident, want de klok begint te lopen op het moment dat jij ervan weet.

Hoe zet je een tafeloefening op?

Ketenincidenten oefenen hoeft geen project te zijn. Houd het klein: twee uur, een vergaderruimte, geen techniek. Deze opzet werkt:

1. Kies een echte leverancier, niet een fictieve. Neem er een die je in je risicoassessment als kritiek hebt aangemerkt.
2. Formuleer een scenario van drie regels, bijvoorbeeld: deze partij meldt vanmorgen dat ze zijn geraakt door ransomware, ze kunnen niet zeggen of jouw data erbij zit, en hun dienst is minstens drie dagen niet beschikbaar.
3. Laat de deelnemers besluiten nemen, in de rol die ze in het echt hebben. Geen discussie over wat er zou moeten, maar wat ze nu doen.
4. Voeg halverwege een complicatie toe, bijvoorbeeld dat een journalist belt of dat blijkt dat je back-up bij dezelfde partij staat.
5. Sluit af met de vraag wat er miste, en leg dat vast met een naam eraan.

Wie erbij hoort: iemand van IT, iemand van inkoop of contractbeheer, iemand die mag besluiten, en iemand die over communicatie gaat. Zonder die laatste twee wordt het een technisch gesprek en mis je precies de knelpunten waar het in het echt op vastloopt.

Welke gaten komen er altijd uit?

In de praktijk levert ketenincidenten oefenen steeds dezelfde drie tekortkomingen op, ongeacht de omvang van de organisatie.

• Verouderde contactgegevens. Het escalatienummer in het contract is van een accountmanager die er niet meer werkt, en er is geen route buiten kantooruren.
• Geen mandaat. Iedereen weet welk besluit nodig is, maar niemand durft of mag het nemen zonder iemand die op vakantie is.
• Geen beeld van de kring. Er is geen lijst van wie geinformeerd moet worden: klanten, toezichthouder, medewerkers, en in welke volgorde.

Blijkt bovendien dat je back-up, je monitoring en je beheer bij dezelfde partij liggen, dan heb je geen incidentprobleem maar een concentratierisico in je keten. De uitweg daaruit begint bij wat je in leverancierscontracten vastlegt, met een exit die je vooraf regelt in plaats van op het moment dat je hem nodig hebt.

Hoe vaak en wat doe je met de uitkomst?

Ketenincidenten oefenen is een keer per jaar genoeg, mits je het serieus doet en de uitkomst vastlegt. Belangrijker dan de frequentie is dat er een lijst uitkomt met verbeterpunten, een eigenaar per punt en een datum. Zonder dat is de oefening een interessant gesprek geweest.

Die lijst is bovendien precies het soort bewijs dat een toezichthouder zoekt. Niet het draaiboek zelf, maar het bewijs dat je het hebt getoetst en er iets mee hebt gedaan. Zie daarover ook welke maatregelen de zorgplicht vraagt.

Wil je een oefening met echte druk erop in plaats van een tafelgesprek, dan is dat wat een NIS2-directietraining doet: dezelfde besluiten, maar met een confrontatie die blijft hangen.

Veelgestelde vragen over ketenincidenten oefenen

Hoe lang duurt een goede tafeloefening?

Twee uur is genoeg. Langer levert zelden meer op, en korter geeft geen ruimte voor de complicatie halverwege, die juist de knelpunten blootlegt.

Moet de leverancier meedoen aan de oefening?

Niet de eerste keer. Je oefent juist het scenario waarin je van die partij afhankelijk bent en niets kunt afdwingen. Werkt de eigen oefening goed, dan is een gezamenlijke oefening met een kritieke leverancier een logische volgende stap.

Wie moet er zeker bij zijn?

Iemand die mag besluiten en iemand die over communicatie gaat. Zonder die twee wordt het een technisch gesprek, terwijl de echte vertraging bij een ketenincident in besluitvorming en communicatie zit.

Is oefenen verplicht onder NIS2?

De Cyberbeveiligingswet vraagt om maatregelen voor incidentbehandeling en bedrijfscontinuiteit, en het toetsen daarvan hoort bij een aantoonbaar werkend stelsel. Ketenincidenten oefenen is de meest praktische manier om dat bewijs te leveren.