Incidentresponsplan ransomware: wat moet er echt in staan?

Wat een incidentresponsplan voor ransomware precies is

Een incidentresponsplan voor ransomware is het plan op hoofdlijnen waarmee je een incident bestuurbaar houdt zodra de druk oploopt. Het bepaalt niet elk technisch detail vooraf, maar wel welke fases je hanteert, wie verantwoordelijk is, wanneer bestuur of crisisteam aan zet is en welke parallelle sporen meteen moeten lopen.

Dat is ook waarom NCSC incidentresponse beschrijft als het vermogen, de processen en afspraken waarmee je schade beperkt en de bedrijfsvoering zo min mogelijk verstoort. Het plan is dus geen theoretisch document, maar een startpunt voor echte beslissingen onder tijdsdruk.

De plancanvas die vooraf klaar moet staan

Onderstaande blokken moeten vóór een oefening of incident al scherp genoeg zijn. Niet perfect, maar concreet genoeg om te voorkomen dat teams tijdens een verstoring eerst nog basisvragen moeten uitvinden.

• Voorbereiding

  Hoofdvraag: wie activeert het plan? Eigenaar: security lead of incidentcoördinator. Vooraf klaar: scope, contactlijst, escalatieregels en crisisteam.

• Identificatie

  Hoofdvraag: wanneer is dit meer dan een alert? Eigenaar: detectie/IR. Vooraf klaar: triggers, logbronnen, leverancierscontacten en ernstcriteria.

• Inperking

  Hoofdvraag: wat mag direct worden afgesloten? Eigenaar: IT/security. Vooraf klaar: beslisrechten, netwerkafspraken, isolatiegrenzen en rollback-risico’s.

• Eliminatie

  Hoofdvraag: wat moet veilig worden verwijderd of opnieuw ingericht? Eigenaar: IR + beheer. Vooraf klaar: recovery-keuzes, golden images en externe hulp.

• Herstel

  Hoofdvraag: wat moet eerst terug? Eigenaar: IT + proceseigenaren. Vooraf klaar: prioriteiten, restore-volgorde, identiteiten en afhankelijkheden.

• Leren en bijsturen

  Hoofdvraag: wat leggen we vast voor de volgende keer? Eigenaar: incidentcoördinator. Vooraf klaar: notulenritme, evaluatievorm en verbeterlog.

Het verschil tussen plan, draaiboek, tabletop en checklist

Deze begrippen worden vaak door elkaar gebruikt, terwijl ze elk een andere rol hebben. Als je dat niet uit elkaar trekt, wordt een plan te vaag of juist te detailgedreven.

• Incidentresponsplan

  Het plan op hoofdlijnen: scope, fases, eigenaarschap, escalatie, parallelle werkstromen en besluitvormingskaders.

• Draaiboek of playbook

  De scenariokaart voor een specifiek type incident, zoals ransomware. Praktischer en concreter dan het plan, maar niet breder.

• Tabletop-oefening

  De oefenvorm waarmee je test of het plan en het draaiboek onder druk ook echt werken.

• Checklist

  Een geheugensteun voor losse acties. Handig, maar te smal om plan, regie en besluitvorming te vervangen.

Welke beslissingen je vooraf moet vastleggen

Een goed plan laat niet alles open tot het moment van crisis. Juist bepaalde keuzes moeten vooraf helder zijn: wie mag systemen isoleren, wie mag leveranciers instrueren, welke bestuurder of proceseigenaar knopen doorhakt en wanneer privacy, legal of communicatie formeel aansluiten.

Dat betekent niet dat elk incident lineair verloopt. Het betekent wel dat de basis van eigenaarschap al is geregeld, zodat snelheid niet verandert in chaos.

• wie het plan activeert en wie incidentcoördinator is
• wie systemen, accounts of leveranciers mag laten afsluiten of beperken
• welke omgeving, data of dienstverlening als eerste prioriteit krijgt
• wanneer bestuur, legal, privacy en communicatie verplicht aanhaken
• welke externe partijen al vooraf in het besluitpad zitten

Wat in herstel, back-up, accounts en afhankelijkheden moet zijn uitgewerkt

Ransomware draait zelden alleen om encryptie. In de praktijk lopen herstel, back-up, accounts en leveranciersafhankelijkheden parallel. Daarom moet het plan vastleggen welke systemen eerst terugkomen, hoe je schoon herstelt, welke identity-vragen direct meespelen en welke externe partij waarvoor nodig is.

Een plan dat alleen zegt ‘restore from backup’ is niet bruikbaar genoeg. Het moet ook duidelijk maken wie de volgorde bepaalt, welke accounts nog vertrouwd zijn en hoe je voorkomt dat je te vroeg weer afhankelijkheden terugzet die nog niet veilig genoeg zijn.

Communicatie, meldplicht en leveranciers lopen parallel

Tijdens een ransomware-incident wachten communicatie, AP-afwegingen en leverancierscoördinatie niet netjes op het einde van technisch herstel. Daarom horen deze sporen vanaf het begin in het plan. Niet als appendix, maar als parallelle werkstroom.

Dat is ook het punt waarop veel teams vastlopen: IT wil tijd, bestuur wil duidelijkheid, communicatie wil geen verkeerde uitspraken doen en leveranciers willen weten wie formeel beslist. Als je dat vooraf niet ordent, oefen je later vooral verwarring.

Hoe toets je of het plan echt bruikbaar is?

De snelste toets is niet nog een extra document, maar een oefening die het plan echt dwingt te werken. NCSC benadrukt daarom ook scenariokaarten en jaarlijkse oefeningen. Een tabletop laat zien of eigenaarschap, escalatie en communicatie voldoende scherp zijn. Restore-tests laten zien of de technische laag het plan werkelijk kan dragen.

Een bruikbaar plan herken je eraan dat teams sneller dezelfde hoofdvraag zien, dat beslissingen niet tussen stoelen vallen en dat parallelle sporen niet pas te laat worden ontdekt.

Snelle plancheck: wat ontbreekt nog bij jouw team?

Als twee of meer van deze punten nog onduidelijk zijn, is de kans groot dat het incidentresponsplan te abstract is om tijdens een echt ransomware-incident goed te werken.

• het is nog onduidelijk wie het plan activeert en wie de regie neemt
• restore-volgorde en kritieke systemen zijn nog niet met proceseigenaren afgestemd
• accounts, privileged access en leverancierslogins zijn geen onderdeel van het herstelpad
• communicatie, meldplicht en leverancierscoördinatie zijn nog geen parallelle spoor in het plan
• er is wel een document, maar het is nog niet getest in tabletop of restore-oefeningen

Welke vervolgstap past nu het best bij jouw situatie?

Heb je nog geen scherp incidentresponsplan, begin dan hier en gebruik daarna de oefenwijzer om te bepalen welke oefenvorm het meeste oplevert. Is het plan er wel, maar voelt het nog theoretisch, dan is tabletop vaak de snelste volgende stap. En als herstel nog vooral op vertrouwen leunt, moet je naar restore-tests en identity.

• Open de oefenwijzer als je na het plan de juiste oefenvorm wilt kiezen
• Ga naar tabletop-oefening voor ransomware als je het plan onder druk wilt toetsen
• Lees back-up en restore-tests voor de herstelvolgorde en technische realiteitscheck
• Open crisiscommunicatie, meldplicht en leveranciers en incidentrespons voor de parallelle sporen

• NCSC: Incidentresponsplan Ransomware
• NCSC: Incidentresponse, waar begin ik?
• NCSC: Crisisoefening Ransomware
• AP: Datalek? Dit moet u doen