Een plan dat niet getest is, bestaat in feite alleen op papier. Dat is een constatering die in de praktijk steeds opnieuw terugkomt. Incident response gaat zelden mis door een gebrek aan tools of technologie. Het loopt vast op aannames, op ontbrekende afspraken, op onduidelijkheid over verantwoordelijkheden of op het simpele feit dat niemand vooraf heeft geoefend hoe een incident zich in het echt ontvouwt.
Bij mkb-omgevingen komt daar nog iets bij. IT wordt vaak met weinig mensen gedaan, veel functionaliteit is ondergebracht in SaaS, en bedrijfskritische systemen zijn vaak gegroeid in plaats van ontworpen. De business wil ondertussen vooral door. In die context heeft een uitgebreid draaiboek weinig waarde als het niet uitvoerbaar is op het moment dat het nodig is.
Haalbare incident response zit daarom niet in volledigheid of perfectie, maar in herkenbaarheid en herhaalbaarheid. In weten wat je doet als het misgaat, met de mensen en middelen die er op dat moment zijn.
Haalbare incident response voor het mkb
Voor mkb-klanten betekent haalbare incident response vooral dat je snel overzicht krijgt en keuzes kunt maken. Niet alles hoeft tegelijk opgelost te worden. Binnen korte tijd moet duidelijk zijn wat geraakt is, welke systemen of processen direct risico lopen en waar ingrijpen het meeste effect heeft. Dat vraagt om beslissingen in plaats van analyses.
In de meeste incidenten begint dat bij identiteit. Compromittering van accounts, misbruik van sessies, verkeerd ingestelde toegangsrechten of zwakke authenticatie vormen vaak het startpunt. Dat betekent dat je snel moet kunnen zien wie waar toegang heeft, welke sessies actief zijn en wat recent is veranderd. Zonder dat inzicht doe je vooral aan symptoombestrijding.
Daarnaast moet er een set basisacties zijn die onder druk uitvoerbaar blijft. Endpoints isoleren, accounts blokkeren of resetten, verdachte mailregels uitschakelen, logs veiligstellen, back-ups beschermen. Dat zijn geen bijzondere verrichtingen, maar je moet ze wel oefenen. Een incident is niet het moment om procedures te lezen of uit te zoeken waar je moet klikken.
Ten slotte vraagt haalbare incident response om een minimale voorbereiding. Dat betekent niet dat alles vooraf dichtgetimmerd moet zijn, maar wel dat cruciale toegang geregeld is. Zonder adminrechten, logging en een globaal overzicht van de omgeving verandert elk incident in een zoektocht, en die kost altijd meer tijd dan je denkt.
Voorbereiding zinvol?
De grens van voorbereiding ligt niet bij wat technisch mogelijk is, maar bij wat tijdens een incident daadwerkelijk tijd oplevert. Alles wat je vooraf regelt moet zich terugbetalen in snelheid en duidelijkheid op het moment dat het nodig is. Voor veel mkb-omgevingen zit die voorbereiding vooral in de basis. Identiteit goed ingericht, MFA afdwingbaar, beheeraccounts afgebakend, logging op kernsystemen actief en back-ups die niet alleen bestaan, maar ook getest zijn. Dit zijn geen specifieke incident response-maatregelen, maar voorwaarden om überhaupt te kunnen reageren.
Daarbovenop kun je versnellers aanbrengen die specifiek helpen tijdens een incident. Denk aan standaardprocedures per type incident, vaste communicatielijnen, vooraf ingerichte scripts voor isolatie of resets en een duidelijke afspraak over wie beslist als er impactvolle keuzes gemaakt moeten worden.
Wat vaak weinig toevoegt, is het blind overnemen van een enterprise-aanpak. Volledige forensische tooling op elk systeem, uitgebreide monitoring die niemand interpreteert of complexe escalatiestructuren die in de praktijk niet worden gevolgd. Dat kan waardevol zijn in grotere omgevingen, maar in het mkb wordt het al snel te zwaar om goed te onderhouden.
Uitvoering
Incident response heeft altijd twee gezichten. Voorbereiding is rationeel en planbaar. Uitvoering is rommelig, tijdgevoelig en vol verrassingen. Als je voorbereiding te ver afstaat van de uitvoering, bouw je een museumstuk.
Voorbereiding die je wél wilt
1) Scope en assets die ertoe doen
Je hoeft niet alles te inventariseren, maar je wilt wél weten welke systemen bedrijfsprocessen dragen. Een beknopte lijst is genoeg: M365 tenant, identities, endpoints, file shares, back-upomgeving, kernapplicaties (ERP, planning, kassa, EPD, wat dan ook), DNS, en de netwerktoegangspunten (firewall, VPN, remote management).
2) Identiteit als startpunt
In veel incidenten begint het bij accounts: phish, token theft, MFA fatigue, misbruik van legacy auth, of misconfiguraties in conditional access. Voor IR betekent dat: zorg dat je weet waar je identities beheert, hoe je sessies en tokens intrekt, hoe je admin-rollen controleert, en hoe je auditlogs snel boven water krijgt.
3) Logging die bruikbaar is
Logs die niemand kan lezen zijn decoratie. Leg vooraf vast: waar loggen we wat, hoe lang bewaren we het, wie kan erbij, en wat zijn de minimale bronnen. Voor het mkb is minimaal vaak al een grote sprong vooruit: M365 audit logs, Entra sign-in logs, endpoint alerts, firewall events, back-up events, en change logs van beheerplatformen.
4) Back-up en herstel als onderdeel van IR
Back-ups zijn geen IR-plan, maar zonder herstel ben je aan het dweilen met de kraan open. Belangrijker dan weten of er back-ups zijn, is weten we hoe snel we terug kunnen, en wat de afhankelijkheden zijn. Test herstel niet alleen op bestanden, maar ook op identiteit en configuraties, denk aan M365 restore scenario’s, conditional access, en sleutelaccounts.
5) Toegang en sleutels in orde, ook als de boel brandt
Als je RMM-account zelf is gecompromitteerd, kun je niet even inloggen om dingen te fixen. Voorbereiding betekent: break-glass accounts, offline bewaarde recovery keys, en een procedure om beheerkanalen gecontroleerd te pauzeren.
Rollen maken het verschil tijdens een incident
Zonder duidelijke rolverdeling ontstaat chaos. Dat geldt zeker in mkb-situaties, waar mensen meerdere petten op hebben en lijnen kort zijn. Er moet iemand zijn die de regie voert en beslissingen neemt. Niet per se de beste techneut, maar wel iemand die overzicht houdt en prioriteiten stelt. Daarnaast is een technische verantwoordelijke nodig die de uitvoering coördineert en bewaakt dat acties samenhangen.
Communicatie verdient een eigen rol. Eén aanspreekpunt richting de klant voorkomt ruis en misverstanden. Hetzelfde geldt intern. Tijdens een incident is het funest als iedereen tegelijk communiceert zonder afstemming.
Documentatie wordt vaak onderschat, maar is cruciaal. Vastleggen wat er gebeurt, wanneer beslissingen zijn genomen en welke acties zijn uitgevoerd, is nodig voor evaluatie, aansprakelijkheid en eventuele meldplichten. Dat is geen administratieve last, maar onderdeel van professioneel handelen.
Aan klantzijde is mandaat essentieel. Er moet iemand zijn die mag besluiten om systemen uit te schakelen, processen stil te leggen of externe partijen in te schakelen. Zonder die beslissingsbevoegdheid blijft een msp hangen tussen techniek en bestuur.
Externe partijen betrek je niet ad hoc
Bij veel incidenten is externe hulp nodig. Forensische specialisten zijn zinvol als er sprake is van grote impact, mogelijke datadiefstal of juridische gevolgen. Dan moet wel duidelijk zijn welke data beschikbaar is en hoe bewijs veiliggesteld wordt.
Cyberverzekeraars stellen vaak eisen aan melding en opvolging. Soms sturen ze hun eigen specialisten. Wie dat niet vooraf heeft uitgezocht, verliest tijd op een moment dat snelheid telt.
Leveranciers van kernsystemen spelen eveneens een rol. Hostingpartijen, applicatieleveranciers en netwerkproviders moeten snel bereikt kunnen worden, met duidelijke afspraken over verantwoordelijkheden.
Ook meldplichten verdienen aandacht. Of er sprake is van een datalek, wie dat beoordeelt en wie communiceert met toezichthouders en betrokkenen, moet geen discussiepunt zijn tijdens het incident zelf.
Incident response hoeft niet dramatisch gebracht te worden. Het helpt om het te benaderen als onderdeel van continuïteit. Net zoals back-ups, monitoring en onderhoud. Door te werken met herkenbare scenario’s wordt het onderwerp concreet zonder angst aan te wakkeren. Verdachte inlogpogingen, vreemde mailboxregels of plotselinge encryptie zijn situaties die organisaties herkennen. Dat maakt het gesprek praktisch.
Oefenen hoort bij beheer
Oefenen hoeft niet duur te zijn. Het hoeft ook niet groots. Wat je wilt is routine opbouwen.
1) Tabletop-oefening per kwartaal of halfjaar
Een uur, maximaal anderhalf, één scenario. Wie doet wat, wie belt wie, welke informatie ontbreekt, welke beslissingen zijn lastig. Resultaat: een korte lijst verbeterpunten.
2) Mini-runbooks testen tijdens regulier onderhoud
Test bijvoorbeeld: kunnen we binnen 10 minuten een endpoint isoleren, kunnen we binnen 15 minuten admin-rollen en recente role assignments exporteren, kunnen we binnen 20 minuten alle actieve sessies van één account intrekken.
3) Hersteltests koppelen aan back-upbeheer
Niet alleen terugzetten, maar ook: klopt de toegang, werken afhankelijkheden, is er geen herinfectie, en kunnen we gecontroleerd terug online?
4) Contact- en toegangstesten
Klinkt suf, maar het werkt: bel eens het noodnummer, controleer of de contactpersoon nog klopt, check of break-glass accounts werken en gelogd worden, en check of je offline bij je klantprofiel kunt.
Wat msp’s hiermee kunnen doen
Een eenvoudige opbouw met verschillende niveaus werkt vaak beter dan één allesomvattend aanbod. Begin met afspraken, basisvoorbereiding en oefenen. Breid dat uit met scenario’s, betere monitoring en externe ondersteuning waar dat past. Het mkb hoeft niet alles tegelijk. Maar een aanpak die getest is en meegroeit met de omgeving, maakt het verschil op het moment dat het echt misgaat.
