Incident response plan voor je website na een datalek of hack: zo stel je het op

Waarom een incident response plan voor je website onmisbaar is

Een datalek of gehackte website komt vaak onverwachts, maar de impact kun je beperken als je een duidelijk incident response plan klaar hebt liggen. Zonder plan verlies je kostbare tijd, maak je fouten in communicatie en loop je meer risico op juridische problemen, bijvoorbeeld rond de AVG en meldplicht datalekken. Met een gestructureerde aanpak herstel je sneller, houd je grip op de situatie en bescherm je de reputatie van je bedrijf.

Stap 1: bepaal het incident response team en rollen

Begin met het vastleggen van wie welke verantwoordelijkheid heeft zodra er iets misgaat. Denk aan een technisch verantwoordelijke voor de website en hosting, iemand die communicatie naar klanten en partners verzorgt en een contactpersoon richting eventuele toezichthouders. Zorg dat contactgegevens van alle betrokkenen centraal en offline beschikbaar zijn. Als je een externe hostingpartner zoals PC Patrol hebt, leg dan vast wie je belt en welke ondersteuning je mag verwachten volgens de gemaakte afspraken. Wil je die rollen, hersteltijden en contactgegevens in één document hebben staan, gebruik dan de gratis NIS2 disaster recovery plan generator om je plan direct op papier te zetten.

Technische eerste hulp na een hack of datalek

Bij een vermoedelijke hack is het cruciaal om rustig maar snel te handelen. Je wilt de schade beperken, het bewijs veiligstellen en voorkomen dat aanvallers nog langer toegang houden. Een goed incident response plan beschrijft precies welke stappen je eerst zet, zodat je niet hoeft te improviseren op een stressvol moment.

Stap 2: isoleren, logbestanden veiligstellen en oorzaak zoeken

Het plan moet beschrijven hoe je de website tijdelijk isoleert zonder alle data te verliezen. Denk aan het in onderhoudsmodus zetten van de site of het beperken van toegang via een web application firewall of IP-restricties. Vervolgens verzamel je server- en applicatielogs voordat je wijzigingen doorvoert, zodat je later kunt analyseren wat er precies is gebeurd. In een eerdere blog zijn we al dieper ingegaan op het herkennen van hackpogingen via logbestanden, wat je terugvindt in ons artikel over het analyseren van webserverlogbestanden om hackpogingen vroegtijdig te herkennen: hoe analyseer je webserverlogbestanden om hackpogingen vroegtijdig te herkennen.

Communicatie, AVG en documentatie tijdens een incident

Een incident response plan gaat niet alleen over techniek. Minstens zo belangrijk is hoe je communiceert met klanten, leveranciers en toezichthouders. Onvolledige of te late communicatie kan net zoveel reputatieschade veroorzaken als het incident zelf. Door dit vooraf vast te leggen, reageer je consistent en conform de wet. Val je onder de nieuwe Europese regels, kijk dan ook naar wat de NIS2-richtlijn van je website en hosting verplicht stelt, want daar gelden eigen meldtermijnen.

Stap 3: meldplicht, klantcommunicatie en vastleggen van acties

Beschrijf in je plan wanneer je een datalek moet melden bij de Autoriteit Persoonsgegevens en wanneer je betrokkenen moet informeren. Leg ook voorbeeldteksten klaar voor e-mails of websiteberichten, zodat je snel en duidelijk kunt communiceren wat er is gebeurd, welke data mogelijk geraakt is en welke maatregelen je neemt. Meer achtergrond over wat een datalek precies is en welke meldplicht je hebt als website-eigenaar vind je in onze uitgebreide uitleg: wat is een datalek en welke meldplicht heb je als website-eigenaar volgens de AVG. Tot slot hoort bij je incident response plan een evaluatiefase: documenteer alle stappen, leer van het incident en werk je beveiligingsmaatregelen en procedures bij zodat je website bij een volgend incident nog beter beschermd is.