Vermoeden van een cybersecurity-incident? Dit zijn de juiste stappen in 2026

Een medewerker meldt dat ze "misschien op iets verkeerds heeft geklikt". De boekhouder ziet een factuur met een rekeningnummer dat niet klopt. Of je krijgt om 23:14 uur een mailtje van Microsoft dat er is ingelogd vanuit een land waar niemand in je bedrijf ooit is geweest. Op zo'n moment begint een periode waarin de beslissingen die je in het eerste uur neemt bepalend zijn voor de schade in de weken erna.

Het vervelende is dat de eerste reflex bij de meeste MKB-bedrijven verkeerd is. Niet uit onwil, maar omdat de intuïtieve reactie — snel opruimen, alles opnieuw opstarten, niemand lastigvallen — precies het tegenovergestelde is van wat een incidentonderzoek nodig heeft. Dit artikel legt uit wat er in zo'n situatie werkelijk gebeurt, waarom bepaalde stappen in een bepaalde volgorde moeten, en hoe je als organisatie zonder eigen securityafdeling toch professioneel handelt.

Waarom "even kijken of het overwaait" zo duur uitpakt

Om te begrijpen waarom snelheid telt, moet je weten hoe een aanval doorgaans verloopt. Vrijwel geen enkele moderne aanval bestaat uit één klap. Er zit bijna altijd een fase tussen het eerste binnenkomen en het daadwerkelijke schadeveroorzakende moment. Die tussenfase heet in vakjargon dwell time: de periode waarin een aanvaller wel binnen is, maar nog niets zichtbaars doet.

In die fase gebeurt het echte werk. De aanvaller kijkt rond, kaart welke accounts beheerdersrechten hebben, zoekt naar back-upsystemen, kopieert gegevens en zet extra toegangswegen op — een tweede account, een mailregel, een API-sleutel, een VPN-configuratie. Pas als dat allemaal staat, volgt het zichtbare deel: de versleuteling, de frauduleuze betaling, de afpersmail.

Dat verklaart twee dingen tegelijk. Ten eerste: als je iets verdachts opmerkt, ben je waarschijnlijk niet aan het begin van het verhaal maar ergens in het midden. Ten tweede: er is dus vaak nog wél tijd om in te grijpen, mits je snel handelt. De aanvaller heeft zijn eindzet nog niet gedaan. Elk uur dat je verliest met twijfelen, is een uur waarin de positie van de tegenpartij steviger wordt.

De tweede reden waarom uitstel duur is, ligt in de bewijsvoering. Sporen van een aanval — logbestanden, sessiegegevens, tijdelijke bestanden, geheugeninhoud — hebben een houdbaarheidsdatum. Veel systemen bewaren logs standaard maar een beperkte periode voordat ze overschreven worden. Wie na drie weken pas onderzoek laat doen, ontdekt regelmatig dat de belangrijkste bewijsstukken inmiddels verdwenen zijn. En zonder bewijs kun je niet vaststellen wát er precies gestolen is, wat weer betekent dat je je meldplicht, je klantcommunicatie en je verzekeringsclaim niet goed kunt onderbouwen.

De eerste dertig minuten: wat je wél en niet doet

De belangrijkste regel in de eerste minuten is contra-intuïtief: zet het getroffen apparaat niet uit, maar haal het wel van het netwerk.

Het verschil is groot. Een computer uitzetten wist het werkgeheugen, en juist in dat werkgeheugen zit vaak de meest waardevolle informatie: actieve verbindingen, sleutels van versleutelingssoftware, processen die nergens op schijf staan. Loskoppelen van het netwerk — netwerkkabel eruit, wifi uit, eventueel de switchpoort dichtzetten — stopt de communicatie met de aanvaller zonder het bewijs te vernietigen.

Concreet in het eerste halfuur:

• Isoleer het verdachte apparaat of de verdachte accounts van het netwerk.
• Verander wachtwoorden vanaf een ánder, schoon apparaat. Wachtwoorden wijzigen op een mogelijk besmet toestel betekent dat je het nieuwe wachtwoord direct cadeau doet aan een eventuele keylogger.
• Trek actieve sessies in. Dit is de stap die het vaakst vergeten wordt. Een gewijzigd wachtwoord verbreekt niet automatisch bestaande sessies; in Microsoft 365 en Google Workspace moet je expliciet alle sessies laten vervallen, anders blijft de aanvaller gewoon ingelogd.
• Controleer op nieuwe mailregels en doorstuurregels. Een klassieke truc bij gekaapte mailboxen is een regel die alle berichten met woorden als "factuur", "IBAN" of "betaling" direct naar een verborgen map of extern adres verplaatst.
• Noteer tijdstippen. Wie meldde wat, hoe laat, en wat heb jij vervolgens gedaan? Deze tijdlijn is later goud waard.

En wat je nadrukkelijk níet doet: bestanden verwijderen, het systeem "even opnieuw installeren", de antivirus alles laten opruimen zonder de melding te bewaren, of zelf gaan zoeken in de mailbox van de aanvaller. Iedere handeling verandert de digitale situatie en maakt reconstructie moeilijker.

Vaststellen wat er werkelijk aan de hand is

Nadat de acute bloeding gestelpt is, komt de vraag: wat is dit eigenlijk? Die vraag is lastiger dan hij lijkt, omdat verschillende incidenttypen op het eerste gezicht op elkaar lijken maar totaal verschillende gevolgen hebben.

Accountovername is het meest voorkomende scenario in het MKB. Iemand heeft inloggegevens buitgemaakt, via phishing of via een wachtwoord dat elders is gelekt en hergebruikt. De schade zit meestal in de mailbox: meelezen, factuurfraude, of het van binnenuit versturen van nieuwe phishing naar klanten en leveranciers. Dat laatste is belangrijk: bij accountovername ben je niet alleen slachtoffer maar ook — ongewild — verspreider.

Ransomware begint zelden als ransomware. Het begint als een besmetting die zich verspreidt, rechten verzamelt en pas daarna toeslaat. Zie je op één werkstation vreemde processen of onbekende beheeraccounts, dan is de vraag niet alleen "hoe schoon ik dit apparaat op" maar vooral "waar is dit nog meer?".

CEO-fraude of factuurfraude hoeft technisch gezien geen inbraak te zijn. Soms is er alleen een overtuigende mail met een vervalst afzenderadres. Maar vaak zit er wél een gehackte mailbox achter — bij jou of bij je leverancier. Dat onderscheid bepaalt of je een betalingsprobleem hebt of een securityprobleem.

Datalek zonder inbraak is de categorie die de meeste organisaties over het hoofd zien. Een verkeerd geadresseerde mail met een klantenbestand, een verloren telefoon, een openbaar toegankelijke map in de cloud: het is geen aanval, maar de meldplicht kan onverminderd gelden.

De praktische aanpak is om vier vragen te beantwoorden voordat je verder gaat: Wat is het eerste bewijs en hoe laat trad het op? Welke accounts en systemen zijn geraakt? Is er data ingezien of gekopieerd? Zijn er nog andere ingangen die openstaan? Als je op vraag drie geen antwoord kunt geven, heb je externe hulp nodig — dat is geen zwakte, dat is de normale gang van zaken bij organisaties zonder eigen securityteam.

Wie schakel je in, en in welke volgorde

De verleiding is groot om als eerste je vaste IT-leverancier te bellen. Doe dat vooral, maar met een kanttekening: een systeembeheerder is niet automatisch een incidentonderzoeker. Beheer is gericht op herstel — zo snel mogelijk weer draaien. Onderzoek is gericht op bewijs — eerst vastleggen, dan herstellen. Die twee doelen botsen letterlijk in de eerste uren. Maak dus expliciet de afspraak: niets opruimen of herinstalleren voordat er is vastgelegd wat er stond.

De partijen die in beeld komen:

Je IT-partner of beheerder. Kan isoleren, sessies intrekken, wachtwoorden resetten en logging veiligstellen. Vraag expliciet om export van de relevante logbestanden voordat er iets wordt aangepast.

Een gespecialiseerde incidentresponspartij. Voor forensisch onderzoek, het vaststellen van de omvang en het advies over communicatie. Veel cyberverzekeringen hebben een vaste partij die je moet inschakelen — check dat vóórdat je zelf iemand belt, anders loop je risico dat kosten niet vergoed worden.

Je verzekeraar. Cyberpolissen kennen doorgaans een meldtermijn en soms een verplichting om vooraf toestemming te vragen voor gemaakte kosten. Bel dus vroeg, ook als je nog niets weet.

De Autoriteit Persoonsgegevens. Bij een datalek met persoonsgegevens geldt in beginsel een meldtermijn van 72 uur na ontdekking, tenzij het onwaarschijnlijk is dat het lek risico oplevert voor betrokkenen. Die klok begint te lopen bij het moment dat je redelijkerwijs kon weten dat er iets mis was — niet als het onderzoek klaar is. Je mag een melding aanvullen of intrekken; te laat melden repareer je niet.

De politie. Aangifte doen is verstandig, ook als de kans op opsporing beperkt is. Het levert een dossiernummer op dat je bij verzekering en bank nodig kunt hebben, en het draagt bij aan het bredere beeld van criminaliteitspatronen. Voor fraudemeldingen is het bovendien nuttig om direct de bank te betrekken; bij snel handelen is terughalen van een overboeking soms nog mogelijk.

Je klanten, leveranciers en medewerkers. Als er vanuit jouw mailbox phishing is verstuurd, moeten zij dat weten. Niet weken later, maar zodra je het vermoedt.

Communiceren tijdens een incident: minder is niet altijd beter

Veel ondernemers zwijgen tijdens een incident uit angst voor reputatieschade. In de praktijk is het omgekeerde waar: reputatieschade ontstaat vooral door het gevoel dat er iets is verzwegen. Een organisatie die snel, feitelijk en zonder opsmuk communiceert, komt er doorgaans beter uit dan een organisatie die pas reageert als een klant zelf de vervalste factuur ontdekt.

Wat werkt: vertel wat je wéét, vertel wat je niet weet, vertel wat je doet en wanneer je opnieuw laat horen. Wat niet werkt: geruststellende conclusies trekken die je nog niet kunt onderbouwen. "Er zijn geen gegevens gelekt" is een zin die je alleen mag uitspreken als je dat onderzocht hebt. Trek je hem later in, dan verlies je in één keer alle geloofwaardigheid.

Intern geldt hetzelfde. De medewerker die de phishinglink aanklikte en het zelf meldt, doet precies wat je wilt. Wie die persoon berispt, zorgt ervoor dat de volgende collega het níet meldt — en dat kost je de uren die je nodig had. Een van de meest onderschatte securitymaatregelen is een cultuur waarin melden veilig is.

Herstellen zonder de deur weer open te zetten

Na het onderzoek volgt herstel, en juist daar gaan organisaties opnieuw de mist in. De meest gemaakte fout is te vroeg terugkeren naar "normaal" terwijl de oorspronkelijke ingang nog openstaat. Herbesmettingen binnen enkele weken komen vaker voor dan je zou verwachten, en de oorzaak is bijna altijd dezelfde: één vergeten account, één ongepatchte server, één back-up die zelf besmet bleek.

Een verantwoorde hersteloperatie kent een paar vaste elementen. Je stelt eerst vast hoe de aanvaller binnenkwam en dicht dát gat — niet de symptomen. Je reset niet alleen de gecompromitteerde accounts maar ook alle accounts met verhoogde rechten, inclusief servicenaccounts en API-sleutels, die notoir vaak vergeten worden. Je controleert of er persistentiemechanismen zijn achtergebleven: geplande taken, mailregels, extra beheerders, apparaten die aan een account gekoppeld zijn.

Bij back-ups geldt: herstellen van een back-up die is gemaakt ná het moment van binnendringen, betekent dat je het probleem terugzet. Daarom is de tijdlijn uit het onderzoek zo belangrijk — zonder die datum weet je niet welke back-up veilig is. Test bovendien of een herstelde omgeving daadwerkelijk werkt voordat je hem in productie neemt.

Tot slot: leg vast wat er gebeurd is. Niet als bureaucratische verplichting, maar omdat de evaluatie de enige plek is waar een incident zich terugverdient. Welke signalen waren er, wie zag ze, waarom is er niet eerder gehandeld, welke maatregel had dit voorkomen?

Voorbereiden op het incident dat nog moet komen

De beste manier om een incident goed af te handelen, is de belangrijkste beslissingen nemen op een moment dat er niets aan de hand is. Een incidentplan hoeft voor een MKB-bedrijf geen lijvig document te zijn; één A4 met de juiste informatie is beter dan een handboek dat niemand vindt.

Zet daarop wie de leiding neemt bij een incident en wie beslist over betalen, communiceren en het stilleggen van systemen. Zet er telefoonnummers op — van je IT-partner, je verzekeraar, je bank en eventueel een incidentresponspartij — en print het uit. Een contactlijst die alleen in de gehackte omgeving staat, is precies op het verkeerde moment onbereikbaar.

Zorg daarnaast dat de basis technisch op orde is: meervoudige authenticatie op alles wat van buiten bereikbaar is, logging die lang genoeg bewaard blijft om achteraf onderzoek te doen, back-ups die niet vanaf het productienetwerk te wissen zijn, en een periodieke controle op accounts van vertrokken medewerkers. Deze maatregelen voorkomen niet elk incident, maar ze verkorten de duur en beperken de omvang aanzienlijk — en dat is uiteindelijk waar het verschil in schade zit.

Een cyberincident is voor de meeste organisaties geen kwestie van of, maar van wanneer. Het onderscheid tussen een vervelende week en een existentieel probleem zit zelden in de geavanceerdheid van de aanval. Het zit in de vraag of iemand wist wat te doen in het eerste uur.