Website-incidentplan voor MKB: het eerste uur
Bram SuurdTips & Tricks
Regel toegang, contacten, bewijs, communicatie en herstel voordat een storing je klanten en team inhaalt.
In dit artikel
Een misbruikte website, een kapotte koppeling of formulieren die nergens aankomen: in die eerste uren telt vooral hoe snel je de juiste mensen en toegangen vindt. Een website-incidentplan voor MKB legt dat vast, zodat je team kan handelen terwijl er nog veel onduidelijk is.
Het hoeft geen zwaar proces te zijn. Beantwoord gewone, concrete vragen: wie belt de hostingpartij, waar liggen de back-ups, welke accounts kunnen worden afgesloten en wie geeft een statusbericht aan klanten vrij?
Een storing is vervelend. Het zoekwerk eromheen kost tijd.
Een verlopen certificaat, een kwetsbare plug-in, een gestolen beheerdersaccount of een fout in een koppeling kunnen klanten hinderen, aanvragen laten verdwijnen of ongewenste inhoud op je site zetten.
ENISA analyseerde 4.875 cyberincidenten in de periode van 1 juli 2024 tot en met 30 juni 2025. Je hebt dat getal niet nodig om een plan te maken. Het helpt wel om incidentrespons te behandelen als regulier beheerwerk, niet als een uitzonderlijk project.
Maak eerst een kaart van je website
Een bruikbaar website-incidentplan begint met een overzicht dat iemand zonder voorkennis kan openen. Zet er in ieder geval in:
- de domeinnamen, DNS-provider, hostingpartij en contactgegevens voor spoed;
- het CMS, de belangrijkste plug-ins of maatwerkonderdelen en wie ze beheert;
- koppelingen met bijvoorbeeld CRM, e-mail, betalingen, planning of voorraad;
- alle beheeraccounts, inclusief de locatie van multifactor-authenticatie;
- de locatie en bewaartermijn van back-ups, plus wie een herstel mag starten;
- één interne beslisser en één technische contactpersoon met een telefoonnummer.
Bewaar dit overzicht buiten je website zelf. Een gedeelde, goed beveiligde kluis of documentomgeving werkt, zolang de betrokkenen er ook bij kunnen als je site of e-mail niet werkt.
Leg het eerste uur vast
In de eerste minuten hoef je de oorzaak nog niet te kennen. Beperk verdere schade en houd een spoor van feiten bij.
- Noteer tijd, URL, foutmelding, screenshots en de persoon die het probleem meldde. Test vanaf een tweede netwerk of apparaat voordat je concludeert dat de hele site platligt.
- Schakel een verdacht account uit, verander wachtwoorden van betrokken beheerders en verbreek een verdachte API-token. Laat systemen die bewijs bevatten beschikbaar zolang dat veilig kan.
- Neem contact op met hosting, domeinbeheer, ontwikkelaar en eventuele securitypartij. Zij moeten weten wie het incident leidt en hoe zij die persoon bereiken.
- Exporteer relevante logs en noteer elke wijziging. Een snelle opruimactie kan informatie verwijderen die later nodig is om de oorzaak te achterhalen.
- Bereid een korte, feitelijke status voor als klanten de gevolgen merken of gegevens mogelijk geraakt zijn. Communiceer pas een hersteltijd als je die kunt onderbouwen.
Back-ups tellen pas mee als herstel werkt
Een back-up is pas bruikbaar als je weet hoe lang herstel duurt en welke onderdelen daarna gecontroleerd moeten worden. Oefen daarom op een aparte omgeving: herstel een kopie, controleer formulieren en koppelingen, en meet hoeveel tijd het kost.
Leg ook vast welke gegevens na het laatste back-upmoment opnieuw moeten worden verwerkt. Denk aan bestellingen, contactaanvragen of wijzigingen in een klantportaal. Dat bepaalt hoe je de dagelijkse dienstverlening na herstel weer op gang brengt.
Wanneer dit ook juridisch speelt
De Nederlandse Cyberbeveiligingswet treedt volgens het NCSC op 15 augustus 2026 in werking. Organisaties die binnen de wet vallen, krijgen onder meer registratie-, zorg- en meldverplichtingen. Het NCSC vermeldt dat een incidentmelding zo snel mogelijk moet gebeuren, uiterlijk binnen 24 uur.
Een website op zichzelf bepaalt niet of de wet geldt. Beoordeel sector, bedrijfsomvang, rol in de keten en contractuele eisen. Laat de juridische reikwijdte toetsen wanneer dat nodig is. Een technische contactlijst en een herstelprocedure blijven in elk geval nuttig.
Velden voor je incidentlog
- Incident: korte omschrijving van wat er zichtbaar misgaat.
- Incidentleider: naam en mobiel nummer van de beslisser.
- Technisch contact: naam en mobiel nummer van degene die toegang heeft of de ontwikkelaar inschakelt.
- Hosting, domein en DNS: provider, spoednummer en locatie van de toegangen.
- Betrokken systemen: websiteonderdelen, koppelingen en mogelijke geraakte gegevens.
- Leverancier of verwerker: naam, escalatiecontact en de dienst die deze partij levert.
- Eerste bekende tijdstip: datum, tijd en wie de melding deed.
- Acties en bewijs: genomen maatregel, loglocatie en screenshots.
- Communicatie-eigenaar: wie een update aan klanten, partners of medewerkers mag goedkeuren.
- Herstelbesluit: wie beslist over de aanpak en welke back-up of herstelroute wordt gebruikt.
Werk dit overzicht bij als je van hosting wisselt, een koppeling toevoegt of een beheerder vertrekt. Dan blijft je website-incidentplan bruikbaar wanneer je het nodig hebt.
Wat je deze week kunt doen
- Plan 45 minuten met je technische beheerder en vul de contact- en toegangsgegevens in.
- Kies een datum om een herstel van een back-up veilig te testen.
Begin met het overzicht. Daarna kun je gericht kiezen welke toegangen, logging of herstelstappen aandacht nodig hebben.
