Deze pagina hoort bij onze gids voor het opstellen van een incident response plan, die de acht stappen beschrijft, waar u het plan bewaart en hoe u het test. Hier behandelen we de fasen die een respons doorloopt en wat elk onderdeel van het plan moet bevatten. Voor de aanpak per scenario, zie playbooks voor incident response.
De zes fasen van incident response
NIST Special Publication 800-61 is de meest gebruikte referentie voor incident response. Revisie 2 (2012) beschrijft een levenscyclus in vier fasen: Voorbereiding; Detectie en analyse; Inperking, uitroeiing en herstel; en Activiteit na het incident. Revisie 3, gepubliceerd in april 2025, vervangt deze. Het plaatst incident response binnen de zes functies van het NIST Cybersecurity Framework 2.0 (Besturen, Identificeren, Beschermen, Detecteren, Reageren en Herstellen) en beschouwt voorbereiding en verbetering als continu risicobeheer in plaats van eenmalige fasen.
Voor operationele procedures doorlopen de meeste beoefenaars nog steeds de zes onderstaande stappen, waarbij inperking en uitroeiing afzonderlijk worden behandeld. Ze zijn van toepassing op alle typen incidenten, van een gecompromitteerd e-mailaccount tot een volledige ransomware-implementatie.
1
Voorbereiding
Alles wat er gebeurt voordat er een incident plaatsvindt. Het documenteren van rollen en verantwoordelijkheden, het opbouwen van escalatiepaden, het bijhouden van een actuele contactlijst, het inventariseren van kritieke bedrijfsmiddelen en hun herstelprioriteiten, het definiëren van wat een meldingsplichtig incident is, het trainen van personeel om verdachte activiteiten te herkennen en te rapporteren, en het testen van back-ups onder realistische omstandigheden. Voorbereiding is de enige fase waarin geen tijdsdruk bestaat. Het is ook de fase die de meeste organisaties voor onbepaalde tijd uitstellen.
2
Detectie en analyse
Vaststellen dat er een incident heeft plaatsgevonden en de aard, omvang en ernst ervan bepalen. Dit vereist gecentraliseerde registratie en waarschuwingen die gebeurtenissen tussen systemen kunnen correleren. Veel organisaties ontdekken inbreuken via een externe melding, van een klant, zakenpartner, bank of wetshandhavingsinstanties, in plaats van interne detectie. Deze kloof kan ertoe leiden dat aanvallers weken of maanden onopgemerkt blijven in de omgeving. Betere detectie verkort de tijd tussen het starten van een aanval en het herkennen ervan. Waar u moet investeren, hangt af van uw bestaande zichtbaarheid, uw waarschijnlijke aanvalspaden en het vermogen van uw team om op waarschuwingen te reageren.
3
Inperking
Het beperken van de verspreiding en impact van het incident zonder forensisch bewijsmateriaal te vernietigen. Inperking op korte termijn isoleert getroffen systemen direct. Inperking op langere termijn herstelt beperkte functionaliteit terwijl de aangetaste omgeving geïsoleerd blijft. Aanvallers handelen snel: CrowdStrike's Global Threat Report 2026 schat de gemiddelde uitbraaktijd van eCrime, vanaf de eerste toegang tot het doorschakelen naar andere systemen, op 29 minuten. Het inperkingsbesluit vereist een vooraf gedefinieerde bevoegdheid. Wie mag een productiesysteem tijdens kantooruren offline halen? Op die vraag moet vóór het incident een naam staan.
4
Uitroeiing
Het verwijderen van de dreiging uit de omgeving: kwaadaardige code, gecompromitteerde accounts, achterdeurtjes en persistentiemechanismen achtergelaten door aanvallers. Uitroeiing zonder grondige forensische analyse riskeert onvolledige verwijdering. Onvolledige verwijdering leidt tot herinfectie. Bij ransomware leidt het hervatten van de bedrijfsvoering op infrastructuur die nog de oorspronkelijke toegangsroute of tools van de aanvaller bevat tot een tweede, vaak snellere versleutelingsronde.
5
Herstel
Normale werking herstellen. Hier blijkt of uw back-ups in de praktijk werken: kan de organisatie binnen de maximaal toelaatbare downtime herstellen naar een bruikbare staat? Herstel omvat monitoring op herinfectie, extra logboekregistratie om de aanvaller op te vangen als deze terugkomt, en het valideren dat getroffen systemen correct functioneren voordat ze weer in productie worden genomen. Zonder dat toezicht kan een aanvaller die voet aan de grond heeft gehouden het herstel ongedaan maken.
6
Activiteit na een incident
De gestructureerde evaluatie nadat het incident is opgelost: wat is er gebeurd, hoe werd het voor het eerst ontdekt, wat werkte, wat mislukte, wat moet er veranderen in het plan, de controles of de omgeving. Evaluaties na incidenten zijn de belangrijkste manier om het responsvermogen te verbeteren. Organisaties die deze stap overslaan omdat het team uitgeput is, hebben de neiging dezelfde fouten te herhalen bij het volgende incident.
Wat uw plan moet bevatten
Een plan dat niet onder druk kan worden uitgevoerd, is geen plan. De volgende elementen zijn het minimum voor een functioneel document.
Reikwijdte en doelstellingen
Op welke soorten incidenten het plan betrekking heeft, wat de responsdoelen van de organisatie zijn (de operationele impact minimaliseren, voldoen aan wettelijke meldingsverplichtingen, forensisch bewijsmateriaal bewaren, reputatie beschermen) en wat expliciet buiten de reikwijdte valt. Een plan dat elke denkbare situatie even gedetailleerd wil beschrijven, dekt er vaak geen enkele goed. Begin met de typen incidenten waarmee uw organisatie waarschijnlijk te maken krijgt.
Rollen, verantwoordelijkheden en bevoegdheden
Benoemde personen voor elke rol, elk met een benoemde plaatsvervanger. Vastgelegde bevoegdheden: wie een formeel incident kan melden, wie inperkingsmaatregelen kan autoriseren, inclusief het offline halen van systemen, wie externe communicatie kan goedkeuren, wie een betalingsbesluit kan autoriseren. Zonder vastgelegde bevoegdheden belanden beslissingen bij de hoogste beschikbare leidinggevende. Dat is niet altijd de juiste persoon, en het gaat langzamer.
Escalatiepaden en externe contacten
Interne escalatie: wie wordt als eerste gebeld, wie wordt gebeld als die persoon niet bereikbaar is, op welk ernstniveau wordt het bestuur geïnformeerd. Externe contacten: juridisch adviseur (met 24/7 noodnummer), cyberverzekering (polisnummer, claimnummer, IR-contactpersoon van de verzekeraar, indien inbegrepen), uw incident response- of MDR-leverancier, indien van toepassing, kritieke leveranciers en cloudproviders (accountreferenties en ondersteuningsescalatieroutes), uw toezichthouder voor gegevensbescherming en eventuele sectortoezichthouders, uw nationale cyberbeveiligingsinstantie en wetshandhavingsinstanties. In Nederland betekent dat de Autoriteit Persoonsgegevens, het NCSC of uw sector-CSIRT, en de politie; in het Verenigd Koninkrijk de ICO en het NCSC; in de VS CISA en het IC3 van de FBI. Een contactlijst die alleen in het e-mailsysteem staat, is onbruikbaar wanneer het e-mailsysteem is aangetast. Spreek een out-of-band kanaal af, zoals persoonlijke mobiele telefoons of een afzonderlijke berichtenservice, voor wanneer zakelijke e-mail of identiteitsservices niet beschikbaar zijn. Spreek ook af hoe responders elkaars identiteit op dat kanaal bevestigen, bijvoorbeeld door terug te bellen naar een nummer dat al op het contactblad staat, omdat een aanvaller die uw e-mail leest het plan kan zien en kan proberen deel te nemen aan het gesprek.
Communicatieprotocollen
Aparte protocollen voor interne en externe communicatie. Wie het personeel informeert en wat er gezegd mag worden. Wie extern communiceert, met klanten, leveranciers, de pers en toezichthouders, en wat wettelijke goedkeuring vereist voordat het wordt verzonden. Geïmproviseerde externe communicatie tijdens een incident kan juridische en reputatieschade veroorzaken die groter is dan de technische impact. Vooraf opgestelde sjablonen voor veelvoorkomende meldingen verkorten de beslistijd en voorkomen fouten onder druk.
Classificatie van incidenten
Een ernstschaal (P1 tot P3, of Kritiek, Hoog en Gemiddeld) met duidelijke criteria voor elk niveau, een reactiedoel en een escalatiepad. Zonder schaal krijgt elk incident dezelfde behandeling: te veel inzet op kleine incidenten en te weinig op grote. Het voorbeeld hieronder is een startpunt dat u kunt aanpassen.
| Niveau | Voorbeelden | Reactiedoel | Wie wordt ingelicht |
|---|---|---|---|
| P1 Kritiek | Ransomware die zich verspreidt; bevestigde diefstal van persoonsgegevens of gevoelige gegevens; een kritieke service uitgevallen; inbreuk op een beheerdersaccount of het identiteitssysteem | Onmiddellijk, op elk uur | Incidentleider, verantwoordelijk bestuurder, juridisch adviseur en gegevensbescherming; bestuur dezelfde dag geïnformeerd |
| P2 Hoog | Bevestigde compromittering, beperkt tot één systeem of account; vermoedelijke gegevensblootstelling die wordt onderzocht; een incident bij een kritieke leverancier dat u raakt | Binnen 1 uur, op elk uur | Incidentleider en technisch leider; contactpersoon gegevensbescherming als er persoonsgegevens bij betrokken kunnen zijn |
| P3 Gemiddeld | Malware tegengehouden op één apparaat; een phishingklik waarna het wachtwoord direct is gewijzigd; een beleidsschending zonder enig teken van schade | Binnen 4 werkuren | Beveiligings- of IT-team; incidentleider op de hoogte |
Dit zijn illustratieve interne doelstellingen, geen wettelijke deadlines. De ernst kan stijgen of dalen naarmate er bewijsmateriaal binnenkomt; registreer elke wijziging en de reden ervan in het beslissingslogboek. Of u een toezichthouder moet informeren, toetst u apart aan de drempel van elke wet. Ook een P3 kan een meldplichtig datalek zijn, bijvoorbeeld een e-mail met gezondheidsinformatie die naar de verkeerde persoon is verzonden.
Herstelprioriteiten en afhankelijkheden
De kritieke diensten, de systemen en leveranciers waarvan elk ervan afhankelijk is, en de volgorde waarin ze terugkomen. Leg voor elk een hersteltijddoelstelling (RTO) en een herstelpuntdoelstelling (RPO) vast, die overeenkomen met de doelstellingen in uw bedrijfscontinuïteit- en noodherstelplannen, zodat het herstelteam niet midden in een incident prioriteiten hoeft te stellen. Leg de overdracht naar uw noodherstel- en bedrijfscontinuïteitsplannen vast: wie beslist of een systeem schoon genoeg is om te herstellen, en welke schijfimages en logboeken het forensische team moet bewaren voordat er iets opnieuw kan worden opgebouwd.
Beslissings- en bewijslogboek
Een lopende registratie, vanaf het eerste uur buiten de getroffen omgeving bewaard: wat er werd besloten, wie er toestemming voor gaf, wanneer, welk bewijsmateriaal er op dat moment beschikbaar was en welke actie daarop volgde. Het ondersteunt het forensisch onderzoek, beantwoordt vragen van verzekeraars en toezichthouders en voedt de beoordeling na incidenten. Het laat de toezichthouder ook zien dat beslissingen op een redelijke basis zijn genomen, ook als achteraf een andere keuze beter was geweest.
Register van kritieke leveranciers
De leveranciers zonder wie een kritieke dienst stilvalt, en voor elke leverancier: wat deze voor u doet, welke gegevens deze bevat, welke toegang deze heeft tot uw systemen, hoe u deze buiten kantooruren kunt bereiken, wat zij volgens het contract moeten melden en hoe snel, en de noodoplossing als de leverancier uitvalt. Houd het kort genoeg om te gebruiken tijdens een crisis en bewaar het bij de offline kopie van het plan. Een leverancier die uw gegevens bewaart of op uw systemen kan inloggen, hoort op de lijst, ook als de dienst klein lijkt. Als u uw leveranciers al in tiers heeft ingedeeld, is de Tier 1-lijst het startpunt.
Sluitingscriteria en aftekening
De voorwaarden voor het afsluiten van een incident: de toegang van de aanvaller is verwijderd en de monitoring heeft gedurende een afgesproken periode niets gevonden, de getroffen systemen zijn hersteld en de eigenaren hebben bevestigd dat ze werken, elke melding is gedaan of het besluit om niet te melden is vastgelegd, het bewijsmateriaal is veiliggesteld en de evaluatie na het incident is ingepland. Leg vast wie het incident afsluit, meestal de incidentleider samen met de verantwoordelijk bestuurder. Zonder dat blijven incidenten wekenlang open of sluiten ze voordat de aanvaller verdwenen is.
