Incidentrespons: wat het is, hoe u een plan opstelt en wat B2B-bedrijven moeten weten
Een praktische gids voor incidentrespons — wat het inhoudt, hoe u een incidentresponsplan opstelt, de fasen van het afhandelen van beveiligingsincidenten, wettelijke vereisten onder NIS2, DORA en ISO 27001, en hoe u incidenten communiceert aan klanten en toezichthouders.
Incidentrespons: wat het is, hoe u een plan opstelt en wat B2B-bedrijven moeten weten
Incidentrespons is het gestructureerde proces dat een organisatie gebruikt om beveiligingsincidenten te detecteren, in te perken, te onderzoeken en ervan te herstellen. Elke organisatie die met gegevens werkt, krijgt uiteindelijk te maken met een incident — of het nu gaat om een phishing-compromittering, een verkeerd geconfigureerde clouddienst, een ransomware-aanval of een insiderdreiging.
Voor B2B SaaS-bedrijven is incidentresponscapaciteit zowel een operationele noodzaak als een compliance-eis. Zakelijke kopers verwachten gedocumenteerde incidentresponsprocedures in leveranciersbeoordelingen. Regelgevingskaders — AVG, NIS2, DORA, ISO 27001 — schrijven specifieke incidentafhandelings- en meldingsprocessen voor. Het verschil tussen een beheerst incident en een crisis hangt vaak af van voorbereiding.
Deze gids behandelt hoe u een incidentresponsprogramma opbouwt, de fasen van incidentafhandeling, wettelijke meldingsvereisten en hoe u incidenten communiceert naar klanten.
Basisbeginselen van incidentrespons
Wat is een beveiligingsincident?
Een beveiligingsincident is elke gebeurtenis die de vertrouwelijkheid, integriteit of beschikbaarheid van informatiesystemen of gegevens in gevaar brengt of bedreigt. Voorbeelden:
| Categorie | Voorbeelden |
|---|---|
| Datalekken | Ongeoorloofde toegang tot persoonsgegevens, exfiltratie van klantgegevens |
| Malware en ransomware | Versleuteling van systemen, cryptomining, installatie van achterdeuren |
| Accountcompromittering | Gestolen inloggegevens, sessiekaping, privilege-escalatie |
| Denial of service | Volumetrische DDoS, applicatielaag-aanvallen, bronuitputting |
| Insiderdreigingen | Kwaadwillige gegevensdiefstal, onbedoelde gegevensblootstelling, beleidsschendingen |
| Supply chain-compromittering | Gecompromitteerde software van derden, kwetsbare afhankelijkheden |
| Cloudmisconfiguratie | Blootgestelde opslagbuckets, te ruime IAM-rechten, onversleutelde gegevens |
Incident vs. gebeurtenis vs. kwetsbaarheid
| Term | Definitie | Voorbeeld |
|---|---|---|
| Beveiligingsgebeurtenis | Een waarneembare gebeurtenis in een systeem of netwerk | Mislukte inlogpoging |
| Beveiligingsincident | Een gebeurtenis die de beveiliging compromitteert of beleid schendt | Succesvolle brute force die leidt tot gegevenstoegang |
| Kwetsbaarheid | Een zwakheid die kan worden uitgebuit | Niet-gepatcht software, zwak wachtwoordbeleid |
Niet elke gebeurtenis is een incident, en niet elke kwetsbaarheid leidt tot een incident. Effectieve triage onderscheidt tussen ruis en echte incidenten die respons vereisen.
De incidentrespons-levenscyclus
NIST-framework (SP 800-61)
De NIST Computer Security Incident Handling Guide definieert vier fasen:
Fase 1: Voorbereiding
Voorbereiding vindt plaats vóór incidenten:
- Stel een Incidentresponsteam (IRT) samen met gedefinieerde rollen
- Documenteer incidentresponsprocedures voor gangbare scenariotypen
- Implementeer detectie- en monitoringtools (SIEM, EDR, netwerkmonitoring)
- Maak communicatiesjablonen voor interne en externe meldingen
- Leg relaties vast met externe partijen (juridisch adviseur, forensische dienstverleners, rechtshandhaving, CERT's)
- Voer tabletop-oefeningen en simulaties uit
- Zorg voor uitgebreide en manipulatiebestendige logging
Fase 2: Detectie en analyse
Vaststellen dat een incident heeft plaatsgevonden en de omvang begrijpen:
- Monitor beveiligingsalerts van SIEM, IDS/IPS, EDR en cloudbeveiligingstools
- Analyseer anomalieën in logs, netwerkverkeer en gebruikersgedrag
- Correleer gebeurtenissen uit meerdere gegevensbronnen
- Bepaal de ernst van het incident en classificeer volgens uw taxonomie
- Documenteer eerste bevindingen en tijdlijn
- Informeer relevante belanghebbenden volgens escalatieprocedures
Fase 3: Inperking, uitroeiing en herstel
Het incident stoppen, de dreiging verwijderen en operaties herstellen:
- Korte-termijninperking: Isoleer getroffen systemen om verspreiding te voorkomen (netwerksegmentatie, accountopschorting, firewallregels)
- Bewijsbewaring: Maak forensische images, bewaar logs, handhaaf de bewijsketen
- Lange-termijninperking: Pas tijdelijke oplossingen toe om doorwerken mogelijk te maken terwijl volledige remediatie wordt voorbereid
- Uitroeiing: Verwijder malware, sluit aanvalsvectoren, patch kwetsbaarheden, reset gecompromitteerde inloggegevens
- Herstel: Herstel systemen vanuit schone back-ups, verifieer integriteit, monitor op herinfectie
- Validatie: Bevestig dat de dreiging is geëlimineerd en systemen normaal functioneren
Fase 4: Post-incidentactiviteiten
Leren van het incident om toekomstige respons te verbeteren:
- Voer een post-incidentbeoordeling uit (blameloze post-mortem)
- Documenteer de volledige incidenttijdlijn
- Identificeer root causes en bijdragende factoren
- Bepaal wat goed werkte en wat verbetering behoeft
- Werk incidentresponsprocedures bij op basis van geleerde lessen
- Volg herstelacties op tot afronding
- Deel relevante bevindingen (eventueel geanonimiseerd) met branchegenoten
Een incidentresponsplan opstellen
Incidentclassificatie
Definieer duidelijke ernstniveaus met objectieve criteria:
| Ernst | Criteria | Responstijd | Voorbeelden |
|---|---|---|---|
| Kritiek (P1) | Actief datalek, systeembrede uitval, ransomware | Onmiddellijk (< 1 uur) | Klantgegevens geëxfiltreerd, productie versleuteld |
| Hoog (P2) | Significante compromittering, gedeeltelijke dienstverstoring | < 4 uur | Accountovername, malware op server, gerichte phishing-succes |
| Medium (P3) | Ingeperkte compromittering, beperkte impact | < 24 uur | Malware op één werkstation, beleidsschending, verdachte activiteit |
| Laag (P4) | Kleine gebeurtenis, geen bevestigde compromittering | < 72 uur | Gerapporteerde phishing-e-mail (niet geklikt), poortscan gedetecteerd |
Rollen van het incidentresponsteam
| Rol | Verantwoordelijkheid |
|---|---|
| Incident Commander | Algehele coördinatie, besluitvorming, escalatie |
| Technisch Lead | Technisch onderzoek, inperking en remediatie |
| Communicatielead | Interne en externe communicatie, mediabehandeling |
| Juridisch adviseur | Wettelijke meldingsvereisten, bewijsbewaring, aansprakelijkheid |
| Uitvoerend sponsor | Zakelijke beslissingen, toewijzing van middelen, stakeholdermanagement |
| Forensisch analist | Bewijsverzameling, malware-analyse, root cause-bepaling |
| Operations | Systeemherstel, back-upbeheer, dienstverlening continuïteit |
Communicatieplan
Interne communicatie:
- Escalatiematrix met contactgegevens (telefoon, niet alleen e-mail)
- Procedures voor opzetten van war room of incidentkanaal
- Statusupdate-cadans (elke 2-4 uur tijdens actieve incidenten)
- Need-to-know-classificatie voor gevoelige incidentdetails
Externe communicatie:
- Sjablonen voor wettelijke meldingen (AVG 72 uur, NIS2 24 uur, DORA 4 uur)
- Sjablonen voor klantmeldingen (getroffen vs. mogelijk getroffen)
- Persverklaring en aanwijzing van woordvoerder
- Criteria en procedures voor inschakeling van rechtshandhaving
Wettelijke incidentmeldingsvereisten
AVG (Artikelen 33-34)
| Vereiste | Detail |
|---|---|
| Wie meldt | Verwerkingsverantwoordelijke aan toezichthoudende autoriteit |
| Termijn | Binnen 72 uur na kennisname |
| Drempel | Inbreuken die waarschijnlijk risico opleveren voor de rechten van betrokkenen |
| Melding aan betrokkenen | Vereist bij hoog risico voor betrokkenen (Artikel 34) |
| Verwerkersverplichting | Verwerkingsverantwoordelijke zonder onredelijke vertraging informeren |
NIS2 (Artikel 23)
| Vereiste | Detail |
|---|---|
| Vroegtijdige waarschuwing | Binnen 24 uur na kennisname van een significant incident |
| Incidentmelding | Binnen 72 uur met initiële beoordeling |
| Tussentijdse rapporten | Op verzoek van het CSIRT of de bevoegde autoriteit |
| Eindrapport | Binnen één maand na de incidentmelding |
| Drempel | Significante operationele verstoring of financieel verlies |
DORA (Artikelen 17-19)
| Vereiste | Detail |
|---|---|
| Initiële melding | Binnen 4 uur na classificatie (of 24 uur na detectie) |
| Tussentijds rapport | Binnen 72 uur na classificatie |
| Eindrapport | Binnen één maand na het laatste tussentijdse rapport |
| Classificatiecriteria | Getroffen klanten, duur, geografische spreiding, gegevensverlies |
| Vrijwillige melding | Significante cyberdreigingen mogen vrijwillig worden gemeld |
ISO 27001
| Maatregel | Vereiste |
|---|---|
| A.5.24 | Vaststellen van planning en voorbereiding van incidentbeheer |
| A.5.25 | Beveiligingsgebeurtenissen beoordelen en beslissen |
| A.5.26 | Reageren volgens gedocumenteerde procedures |
| A.5.27 | Leren van incidenten om beveiliging te verbeteren |
| A.5.28 | Bewijs correct verzamelen en bewaren |
| A.6.8 | Voorzien in een mechanisme voor het melden van beveiligingsgebeurtenissen |
Incidentrespons voor B2B SaaS-bedrijven
SaaS-specifieke overwegingen
Multi-tenant-impact: Een incident in een multi-tenant-platform kan alle klanten tegelijkertijd treffen. Uw plan moet tenant-isolatie, cross-tenant-impactbeoordeling en per-klant-melding adresseren.
Gedeelde verantwoordelijkheid: Incidenten in de cloudinfrastructuur kunnen uw cloudprovider (AWS, Azure, GCP) betreffen. Verduidelijk verantwoordelijkheden en escalatiepaden met providers vooraf.
Verwerkersverplichting: Als verwerker onder de AVG moet u uw klanten (verwerkingsverantwoordelijken) zonder onredelijke vertraging informeren, zodat zij aan hun eigen 72-uurmeldingstermijn bij toezichthoudende autoriteiten kunnen voldoen.
API- en integratiebeveiliging: Incidenten met API's of integraties kunnen downstream-systemen beïnvloeden. Identificeer afhankelijkheden en meldingsverplichtingen voor gekoppelde diensten.
Continue uitrol: Snelle releasecycli kunnen kwetsbaarheden introduceren. Uw incidentresponsplan moet incidenten als gevolg van uitrolmomenten dekken (rollback-procedures, feature flag-noodschakelaars).
Klantcommunicatie tijdens incidenten
Best practices voor B2B-incidentcommunicatie:
- Meld tijdig — Directe communicatie naar getroffen klanten, niet alleen een statuspagina-update
- Wees feitelijk — Vermeld wat u weet, wat u niet weet en wat u onderzoekt
- Vermijd speculatie — Speculeer niet over toeschrijving, omvang of impact voordat het onderzoek dit bevestigt
- Geef bruikbare instructies — Vertel klanten wat zij moeten doen (inloggegevens roteren, toegangslogs controleren, hun eigen gebruikers informeren)
- Geef regelmatige updates — Stel verwachtingen voor updatefrequentie en houd u eraan
- Publiceer een post-incidentrapport — Tijdlijn, root cause, herstelacties en geplande verbeteringen
Uw incidentrespons testen
Tabletop-oefeningen
Scenariogebaseerde discussies waarbij het IRT hypothetische incidenten doorneemt:
- Geen daadwerkelijke systemen worden beïnvloed
- Focus op besluitvorming, communicatie en procedurevalidatie
- Gebruikelijke duur: 2-4 uur
- Aanbevolen frequentie: elk kwartaal
- Neem scenario's op die relevant zijn voor uw technologie en dreigingslandschap
Functionele oefeningen
Praktische oefeningen die specifieke technische capaciteiten testen:
- Herstellen vanuit een back-up binnen de hersteltijddoelstellingen
- Een gecompromitteerd systeem isoleren van het netwerk
- Forensische analyse uitvoeren van een gesimuleerde compromittering
- Communicatieprocedures uitvoeren (intern en extern)
- Aanbevolen frequentie: tweemaal per jaar
Volledige simulaties
End-to-end-oefeningen die het volledige incidentresponsproces testen:
- Gesimuleerde aanval met echte (maar gecontroleerde) technische activiteit
- Test detectiecapaciteiten — kan uw team het incident identificeren?
- Omvat executive communicatie en externe meldingsprocedures
- Aanbevolen frequentie: jaarlijks
- Overweeg een red team in te schakelen om het realisme te vergroten
Veelgemaakte fouten bij incidentrespons
Geen plan tot het eerste incident
Incidentresponsprocedures ontwikkelen tijdens een actief incident leidt tot chaos. Het moment om te plannen is vóór het incident — niet ertijdens. Zelfs een basis gedocumenteerd plan verbetert de responseffectiviteit drastisch.
Onvoldoende logging
U kunt niet onderzoeken wat u niet hebt gelogd. Zorg voor uitgebreide logging in applicaties, infrastructuur, authenticatiesystemen en netwerkgrenzen. Bewaar logs minimaal 12 maanden (veel regelgevingen vereisen langer).
Bewijs vernietigen
Goedwillende IT-medewerkers die gecompromitteerde systemen onmiddellijk opnieuw installeren, vernietigen forensisch bewijs dat nodig is voor onderzoek en wettelijke rapportage. Train personeel in bewijsbewaring vóór remediatie.
Communicatiestoringen
Interne communicatiestoringen tijdens incidenten veroorzaken dubbel werk, tegenstrijdige acties en gemiste meldingen. Externe communicatiestoringen — vertraagde, inconsistente of misleidende klantmeldingen — vernietigen vertrouwen sneller dan het incident zelf.
Post-incidentbeoordelingen overslaan
Elk incident, zelfs kleine, biedt leermogelijkheden. Organisaties die post-incidentbeoordelingen overslaan, herhalen dezelfde fouten. Maak post-incidentbeoordelingen verplicht en blameloos.
Hoe Orbiq incidentrespons ondersteunt
- Trust Center: Publiceer uw incidentresponshouding, post-incidentrapporten en remediatiestatus voor klanttransparantie
- Continue monitoring: Volg incidentresponsmaatregelen voor ISO 27001-, NIS2- en DORA-vereisten
- Bewijsbeheer: Centraliseer incidentregistraties, post-mortemdocumentatie en oefenrapporten gekoppeld aan compliance-frameworks
- AI-gestuurde vragenlijsten: Beantwoord incidentresponsvragen in beveiligingsvragenlijsten automatisch vanuit uw gedocumenteerde procedures
Verder lezen
- AVG-compliance — Meldingsvereisten bij datalekken onder de AVG
- Informatiebeveiligingsbeleid — Het beleidskader dat incidentresponsprocedures regelt
- Compliance-automatisering — Automatisering van incidentresponsbewijs en -rapportage
- Penetratietesten — Proactief testen om incidenten te voorkomen
Deze gids wordt onderhouden door het Orbiq-team. Laatste update: maart 2026.