Datalek incidentrespons voorbeeld voor het mkb

Een medewerker klikt op een geloofwaardige phishingmail, voert zijn wachtwoord in en een onbekende logt in op de zakelijke mailbox. Dan telt niet alleen de techniek. Een goed datalek incidentrespons voorbeeld laat zien wie meteen handelt, welke gegevens u veiligstelt en wanneer u klanten, de Autoriteit Persoonsgegevens of andere betrokkenen informeert. Juist voor mkb-organisaties voorkomt die duidelijkheid dat een beperkt incident uitgroeit tot langdurige uitval, reputatieschade of verlies van gegevens.

Een realistisch datalek incidentrespons voorbeeld

Stel: een administratiekantoor met twaalf medewerkers gebruikt zakelijke e-mail, cloudopslag en een online boekhoudpakket. Op dinsdagochtend ziet een medewerker dat vanuit de mailbox onverwacht e-mails met een betaalverzoek zijn verstuurd. In de verzonden items staan berichten die hij niet zelf heeft gemaakt. De mailbox bevat klantnamen, facturen, bankgegevens en kopieën van identiteitsbewijzen.

Dit is een mogelijk datalek, maar nog niet elk beveiligingsincident is automatisch een meldingsplichtig datalek. Eerst moet de organisatie vaststellen of persoonsgegevens verloren zijn gegaan, gewijzigd, ingezien of beschikbaar zijn gekomen voor onbevoegden. In dit voorbeeld is ongeautoriseerde toegang tot de mailbox al voldoende reden om het incident serieus te onderzoeken.

De medewerker meldt het probleem direct bij de aangewezen verantwoordelijke. Die belt de IT-partner of beheerder in plaats van zelf willekeurig instellingen te wijzigen. Zo blijven loggegevens en sporen behouden. De beheerder blokkeert actieve sessies, wijzigt het wachtwoord, schakelt waar mogelijk multifactorauthenticatie in en controleert of er regels voor automatisch doorsturen, onbekende apparaten of extra mailboxrechten zijn toegevoegd.

Tegelijkertijd wordt het incident geregistreerd: wanneer kwam de melding binnen, wie heeft welke actie uitgevoerd, welke accounts zijn betrokken en wat is op dat moment bekend? Die registratie hoeft niet ingewikkeld te zijn. Hij moet wel feitelijk, tijdig en volledig genoeg zijn om later verantwoording af te leggen.

De eerste uren: indammen zonder te gokken

De eerste prioriteit is verdere toegang stoppen. Dat kan betekenen dat u één mailbox blokkeert, maar soms is het verstandiger om alle sessies van een account of een hele groep gebruikers opnieuw te laten aanmelden. Welke keuze passend is, hangt af van de aanwijzingen in de logbestanden en de inrichting van uw omgeving.

Bij dit voorbeeld controleert de beheerder ook of dezelfde inloggegevens zijn gebruikt voor cloudopslag, VPN, hostingbeheer of een klantportaal. Hergebruik van wachtwoorden vergroot de schade snel. Zijn er verdachte aanmeldingen in meerdere systemen, behandel het dan als een breder accountcompromis en beperk niet alles tot alleen e-mail.

Maak in deze fase een veilige kopie van relevante loggegevens. Noteer onder meer de bron-IP-adressen, tijdstippen, aangemelde apparaten, ingestelde doorstuurregels en uitgevoerde acties. Verwijder schadelijke regels pas nadat u hebt vastgelegd wat ze deden. U wilt het incident oplossen, maar ook kunnen bepalen welke gegevens mogelijk zijn ingezien of verstuurd.

Beoordelen of u het datalek moet melden

Na het indammen volgt de beoordeling. De AVG verlangt dat u datalekken documenteert, ook wanneer een melding bij de Autoriteit Persoonsgegevens niet nodig blijkt. Als het lek waarschijnlijk een risico oplevert voor de rechten en vrijheden van betrokkenen, moet de verwerkingsverantwoordelijke het datalek in beginsel binnen 72 uur melden bij de Autoriteit Persoonsgegevens. Die termijn loopt vanaf het moment dat u kennis krijgt van het datalek, niet vanaf het moment dat het volledige onderzoek klaar is.

In het voorbeeld zijn de mogelijke gevolgen reëel: klanten kunnen phishingmails ontvangen die geloofwaardig lijken, financiële gegevens kunnen worden misbruikt en kopieën van identiteitsbewijzen kunnen identiteitsfraude faciliteren. Dat maakt een melding aannemelijk. Blijkt de kans op een hoog risico voor betrokkenen, dan moeten zij doorgaans ook rechtstreeks en in duidelijke taal worden geïnformeerd.

Wacht niet op absolute zekerheid. Een eerste melding mag worden aangevuld wanneer onderzoek nog loopt. Vermeld dan wat bekend is, welke stappen al zijn gezet en wanneer aanvullende informatie volgt. Een onvolledige maar tijdige melding is beter dan een late melding omdat niemand de knoop durft door te hakken.

De verantwoordelijke organisatie is degene die bepaalt waarom en hoe persoonsgegevens worden verwerkt. Werkt u met een externe hosting- of IT-partner die gegevens namens u verwerkt, dan is die partij verwerker. De verwerker moet het incident zonder onredelijke vertraging aan u melden en technische informatie leveren. U blijft als verwerkingsverantwoordelijke verantwoordelijk voor de beoordeling en eventuele melding, tenzij de rollen in de specifieke situatie anders zijn verdeeld.

Wat zet u in de interne incidentregistratie?

Leg minimaal vast wat er is gebeurd, wat de mogelijke gevolgen zijn en welke maatregelen u hebt genomen. Voor dit soort incidenten zijn vier onderdelen onmisbaar:

• De datum, het tijdstip, de ontdekking en de betrokken systemen of accounts.
• De soorten persoonsgegevens, de geschatte omvang en de groep betrokken personen.
• De oorzaak of vermoedelijke aanvalsmethode, inclusief wat nog onderzocht wordt.
• De herstelmaatregelen, de meldingsbeslissing en de communicatie met betrokkenen.

Houd feiten en aannames uit elkaar. Schrijf dus niet: “de aanvaller heeft alle dossiers gedownload” als u alleen weet dat de mailbox is geopend. Noteer liever: “er is toegang geweest tot een mailbox met dossiers; downloadactiviteit is nog niet vastgesteld.” Die precisie voorkomt onnodige onrust en helpt bij een zorgvuldige beoordeling.

Herstellen: niet alleen het wachtwoord wijzigen

Een nieuw wachtwoord is een begin, geen afronding. Controleer na een gecompromitteerd account of de aanvaller persistentie heeft achtergelaten. Denk aan doorgestuurde e-mails, extra beheerdersrechten, gekoppelde apps, gewijzigde herstelgegevens, API-sleutels of onbekende apparaten. Controleer ook of er vanaf de mailbox betaalinstructies of frauduleuze berichten naar klanten zijn verstuurd.

In het voorbeeld neemt het administratiekantoor contact op met klanten die een verdacht betaalverzoek hebben ontvangen. De boodschap is kort en concreet: welk bericht niet vertrouwd mag worden, welke actie de klant wel of niet moet nemen en waar vragen terechtkunnen. Vermijd technische details die klanten niet helpen, maar wees niet vaag. Mensen moeten direct weten of zij een betaling moeten stoppen, een wachtwoord moeten aanpassen of extra alert moeten zijn op fraude.

Herstel daarna de normale bedrijfsvoering gecontroleerd. Test of de medewerker weer kan werken, maar kijk ook of beveiligingsmaatregelen geen ongewenste blokkades veroorzaken. Als meerdere wachtwoorden zijn gereset, moet iemand bereikbaar zijn om gebruikers snel te helpen. Incidentrespons die technisch klopt maar medewerkers urenlang buitensluit, levert alsnog bedrijfsrisico op.

Goede back-ups helpen vooral wanneer gegevens zijn verwijderd, versleuteld of overschreven. Ze lossen echter geen ongeautoriseerde inzage op. Daarom hoort back-upbeheer naast toegangsbeveiliging, monitoring en logregistratie te staan. Een beheerpartner zoals DeltaServ kan hierin helpen door omgevingen actief te monitoren, back-ups te beheren en bij afwijkingen snel mee te onderzoeken. De organisatie zelf moet wel weten wie intern beslissingen neemt en wie de communicatie verzorgt.

Van voorbeeld naar een werkbaar incidentresponsplan

Een plan werkt alleen als het ook onder tijdsdruk bruikbaar is. Bewaar daarom geen document van dertig pagina’s waar niemand toegang toe heeft tijdens een storing. Maak een korte procedure met namen, telefoonnummers, escalatieafspraken en een vaste volgorde: melden, indammen, onderzoeken, beoordelen, communiceren, herstellen en evalueren.

Wijs vooraf minimaal een bedrijfsverantwoordelijke, een technische contactpersoon en een communicatieverantwoordelijke aan. In een klein bedrijf kan één persoon meerdere rollen hebben. Dat is geen probleem, zolang vervanging geregeld is voor vakantie, ziekte of een incident buiten kantooruren. Leg ook vast welke leverancier u belt bij een probleem met e-mail, hosting, werkplekken of netwerktoegang.

Oefen één scenario per jaar, bijvoorbeeld een gestolen laptop, een verkeerd geadresseerde e-mail of een gehackte mailbox. Een oefening hoeft geen grote crisissimulatie te zijn. Bespreek in een halfuur wie als eerste wordt gebeld, waar de loggegevens staan en wie een meldingsbeslissing voorbereidt. Dan ontdekt u rustig waar contactgegevens ontbreken of verantwoordelijkheden door elkaar lopen.

Na het incident: verbeteren zonder schuldspel

Plan na herstel een korte evaluatie. Niet om één medewerker aan te wijzen als oorzaak, maar om te bepalen welke barrière ontbrak. Was multifactorauthenticatie niet ingeschakeld? Waren waarschuwingen over verdachte aanmeldingen niet zichtbaar? Was er geen duidelijke route om een incident direct te melden? Vaak ligt de verbetering in een combinatie van techniek, processen en gerichte instructie.

Leg concrete vervolgacties vast met een eigenaar en deadline. Bijvoorbeeld: multifactorauthenticatie verplicht maken, beheeraccounts scheiden van gewone accounts, mailboxregels periodiek controleren of medewerkers trainen op betaalfraude. Kies maatregelen die bij uw organisatie passen. Een zelfstandige heeft een andere aanpak nodig dan een webshop met twintig medewerkers en een externe klantenservice.

Een incidentresponsplan geeft geen garantie dat een datalek nooit gebeurt. Het geeft u wel iets dat op een kritisch moment veel waard is: rust, duidelijke taken en de mogelijkheid om klanten en medewerkers snel verder te helpen.