Een incidentresponsplan klinkt als iets voor grote, technisch volwassen organisaties. In de praktijk is het precies het tegenovergestelde: hoe kleiner de organisatie en hoe minder reserves er zijn om een crisis op te vangen, hoe belangrijker een goed plan is.
Een incidentresponsplan is, in de kern, een document dat vastlegt wat een organisatie doet op het moment dat er een beveiligingsincident plaatsvindt. Niet als theoretische exercitie, maar als praktisch draaiboek dat tijdens een crisis daadwerkelijk wordt gevolgd.
Waarom dit niet hetzelfde is als “wel zien wanneer het gebeurt”
De gedachte “we lossen het op als het zich voordoet” klinkt praktisch, maar werkt averechts in een crisis. Onder druk, met systemen die niet werken en klanten die bellen, neemt iedereen impulsieve beslissingen. Onderzoek naar incidentrespons laat consistent zien dat organisaties zonder vooraf vastgelegd plan trager herstellen en hogere kosten maken dan organisaties met een geoefend plan.
Het verschil zit niet in technische kennis, maar in voorbereiding. Wie van tevoren heeft nagedacht over wie wat doet, wie beslist en hoe gecommuniceerd wordt, verliest geen tijd aan het uitvinden van die antwoorden terwijl de klok doortikt.
De onderdelen van een werkend plan
Een ouderwets stukje papier. Als je systemen eruit liggen wil je dat je alsnog wel je responsplan kunnen gebruiken, het beste advies is daarom ook: zorg dat je ze letterlijk op papier hebt.
Een duidelijk crisisteam met vastgelegde rollen. Wie neemt de leiding? Wie communiceert naar klanten? Wie is het aanspreekpunt voor IT-leveranciers of forensisch onderzoek? Deze rollen moeten vooraf zijn toegewezen aan specifieke personen, niet aan functies in algemene zin. Een plan dat zegt “de IT-manager regelt dit” werkt niet als die persoon op vakantie is.
Classificatie van incidenten. Niet elk incident is even ernstig. Een plan moet onderscheid maken tussen kleinschalige incidenten die binnen het team worden opgelost, en grootschalige incidenten die het bestuur en mogelijk externe partijen vereisen. Deze classificatie bepaalt welk escalatieniveau wordt geactiveerd.
Contactgegevens die up-to-date zijn. Een lijst met telefoonnummers van het crisisteam, de IT-leverancier, een forensisch onderzoeksbureau, juridisch advies en, indien relevant, de cyberverzekeraar. Deze lijst moet ook werken als de reguliere systemen, zoals e-mail, niet beschikbaar zijn.
Een communicatiestrategie. Wat communiceer je naar medewerkers, klanten, leveranciers en mogelijk de media? Wie is woordvoerder? Een ongecoördineerde communicatie tijdens een crisis vergroot de reputatieschade aanzienlijk meer dan het incident zelf.
Meldprocedures richting toezichthouders. Bij een datalek geldt onder de AVG een meldtermijn van 72 uur richting de Autoriteit Persoonsgegevens. Onder de aankomende Cyberbeveiligingswet gelden voor bepaalde organisaties nog kortere termijnen. Het plan moet beschrijven wie verantwoordelijk is voor deze melding en hoe die wordt voorbereid.
Technische herstelstappen. Welke systemen worden eerst herstart, welke back-ups worden gebruikt, en wie voert deze stappen uit? Dit onderdeel wordt meestal door IT opgesteld, maar moet wel zijn afgestemd op de prioriteiten die het bestuur heeft vastgesteld over welke processen het meest kritiek zijn.
De stap die het vaakst wordt overgeslagen: oefenen
Een plan op papier is nuttig, maar onvoldoende. De organisaties die het snelst herstellen na een incident, zijn vaak degenen die hun plan periodiek hebben getest met een tabletop-oefening: een gesimuleerd scenario waarbij het crisisteam doorloopt wat ze zouden doen, zonder dat er daadwerkelijk iets misgaat.
Tijdens zo’n oefening komen vrijwel altijd hiaten naar boven. Een contactpersoon die niet meer bij de organisatie werkt. Een back-up waarvan niemand weet hoe die precies wordt teruggezet. Een beslissing over het al dan niet betalen van losgeld waarover het bestuur nog nooit heeft gesproken. Het is veel beter om deze hiaten te ontdekken tijdens een rustige oefening dan tijdens een daadwerkelijke crisis.
Wie is hier verantwoordelijk voor?
Net als bij patchbeheer is incidentrespons een onderwerp dat verder gaat dan IT. Het bestuur is verantwoordelijk voor de uiteindelijke besluitvorming tijdens een crisis, met name bij vragen die buiten het technische domein vallen: wel of geen losgeld betalen, wanneer klanten te informeren, en wanneer externe partijen zoals de politie of toezichthouders te betrekken.
Onder de Cyberbeveiligingswet wordt deze verantwoordelijkheid ook formeel: bestuurders moeten kunnen aantonen dat ze betrokken zijn bij het beleid rondom incidentrespons, niet alleen bij de uitvoering ervan.
Een eenvoudig startpunt
Organisaties die nog geen plan hebben, hoeven niet meteen een uitgebreid document op te stellen. Een goed startpunt is het beantwoorden van een paar fundamentele vragen: wie bel je als eerste als er iets misgaat, wat is onze meest kritieke data en systeem, en wanneer is de laatste keer dat onze back-up daadwerkelijk is getest door die terug te zetten? De antwoorden op die drie vragen leggen vaak al de grootste hiaten bloot.
Wat RiskGuard hierin doet
RiskGuard helpt organisaties een incidentresponsplan op te stellen dat past bij hun omvang en risicoprofiel, en begeleidt tabletop-oefeningen om te testen of het plan in de praktijk werkt. Geen generiek document, maar een plan dat aansluit op hoe de organisatie daadwerkelijk functioneert.
Wil je weten of jullie incidentresponsplan stand zou houden tijdens een echte crisis? Neem contact op voor een vrijblijvend gesprek.
Benieuwd hoe jouw organisatie scoort?
Doe de gratis zelfscan en ontdek waar de risico's zitten.
