Laatst gecontroleerd: 12 juli 2026
Kort antwoord
Incidentmanagement toon je meestal niet aan met één beleidsdocument. Een klant wil kunnen begrijpen:
- hoe een incident wordt gemeld;
- wie beoordeelt wat er aan de hand is;
- wie beslissingen neemt;
- hoe schade wordt beperkt;
- hoe herstel en communicatie verlopen;
- hoe gebeurtenissen worden geregistreerd;
- of de procedure wordt geoefend of geëvalueerd;
- hoe verbeterpunten worden opgevolgd.
Sterker bewijs bestaat daarom uit een combinatie van een actuele incidentprocedure, rollen en verantwoordelijkheden, een meld- en escalatieroute, registratie, communicatieafspraken en bewijs van oefening of review.
Een klein bedrijf heeft niet automatisch een zwaar SOC-proces nodig. Het moet wel duidelijke, uitvoerbare werkafspraken hebben die passen bij de eigen dienstverlening en klantimpact.
Krijg je deze vraag in een klantuitvraag? Bekijk ook welke bewijsstukken bij een securityvragenlijst passen of laat de securityvragenlijst beoordelen.
Welke vraag stelt de klant eigenlijk?
Incidentmanagement kan in een assessment op veel manieren worden gevraagd.
| Klantvraag | Wat de klant mogelijk wil weten | Wat je niet automatisch moet aannemen |
|---|---|---|
| Hebben jullie een incidentprocedure? | Is er een gedocumenteerde werkwijze? | Dat een document ook geoefend en actueel is |
| Hoe worden incidenten gemeld? | Bestaat een bereikbaar en bekend meldkanaal? | Dat 24/7-bereikbaarheid contractueel is afgesproken |
| Wie is verantwoordelijk? | Zijn rollen en beslissingsrechten duidelijk? | Dat een formeel SOC-team nodig is |
| Wanneer informeren jullie klanten? | Zijn impact, contract en communicatie meegenomen? | Dat één vaste termijn voor ieder incident geldt |
| Hoe behandelen jullie datalekken? | Bestaat een privacy- en escalatieroute? | Dat ieder securityincident automatisch een meldplichtig datalek is |
| Registreren jullie incidenten? | Kunnen gebeurtenissen en acties worden gereconstrueerd? | Dat ruwe tickets met de klant gedeeld moeten worden |
| Wordt de procedure getest? | Is de werking beoordeeld, niet alleen opgeschreven? | Dat iedere oefening dezelfde omvang moet hebben |
| Hebben jullie 24/7 incident response? | Is directe bereikbaarheid en operationele opvolging geregeld? | Dat een mailbox of informele belafspraak gelijkstaat aan een 24/7-dienst |
| Welke meldtermijnen gelden? | Zijn contractuele of wettelijke afspraken bekend? | Dat een algemene termijn zonder context kan worden beloofd |
Vraag om verduidelijking wanneer de klant contractuele responstijden, wettelijke meldingen, privacyincidenten en technische incidentrespons in één vraag combineert.
Welke bewijsstukken kunnen bruikbaar zijn?
| Bewijstype | Wat het kan aantonen | Wat het niet automatisch aantoont | Wat je afschermt |
|---|---|---|---|
| Deelbare incidentprocedure | Dat stappen en verantwoordelijkheden zijn beschreven | Dat medewerkers ze kennen of hebben geoefend | Interne nummers, gevoelige locaties en operationele details |
| Rollen- of RACI-matrix | Wie uitvoert, beslist en geïnformeerd wordt | Dat personen beschikbaar en getraind zijn | Privécontactgegevens |
| Meld- en escalatieschema | Hoe een melding door de organisatie loopt | Dat iedere uitzonderingssituatie is afgedekt | Persoonsnamen waar rollen volstaan |
| Classificatiemodel | Hoe ernst en prioriteit worden bepaald | Dat classificatie in de praktijk consistent gebeurt | Interne drempels die nieuwe risico’s tonen |
| Geanonimiseerd incidentformulier | Welke informatie wordt vastgelegd | Dat ieder incident volledig geregistreerd is | Klant-, persoons- en technische incidentdata |
| Communicatiesjabloon | Dat externe communicatie is voorbereid | Dat een specifieke melding juridisch correct is | Vooraf ingevulde klant- of incidentdetails |
| Oefenverslag | Dat een scenario is doorlopen en geëvalueerd | Dat ieder ander scenario ook beheerst wordt | Namen, kwetsbaarheden en niet-opgeloste details |
| Reviewlog of wijzigingshistorie | Dat de procedure wordt onderhouden | Dat de uitvoering effectief is | Interne opmerkingen zonder klantrelevantie |
| Geanonimiseerd ticket | Dat detectie, acties en afsluiting zijn geregistreerd | Dat het hele proces structureel werkt | Persoonsgegevens, IOC’s en klantnamen |
| Managementrapportage | Dat trends en verbeteracties worden gevolgd | Dat alle operationele details correct zijn | Gevoelige statistiek of andere klanten |
| Training- of awarenessrecord | Dat rollen zijn geïnformeerd of geoefend | Dat iemand tijdens een echt incident correct handelt | Individuele resultaten zonder noodzaak |
Een klantvriendelijke bewijsset hoeft niet alle documenten volledig te bevatten. Vaak is een samenvatting met scope, versie, reviewdatum en beschikbare onderliggende bewijzen veiliger.
Wat moet minimaal in een incidentprocedure staan?
De passende diepgang hangt af van omvang en risico. Controleer minimaal:
-
Doel en scope
Welke diensten, systemen, gegevens en typen incidenten vallen onder de procedure? -
Definities en classificatie
Wanneer is iets een storing, securitygebeurtenis, incident, crisis of mogelijk datalek? -
Meldkanaal
Hoe melden medewerkers, klanten en externe partijen een vermoeden? -
Triage en eerste beoordeling
Wie bepaalt ernst, impact, scope en prioriteit? -
Rollen en beslissingsrechten
Wie coördineert, onderzoekt, communiceert en keurt belangrijke acties goed? -
Escalatie
Wanneer worden directie, IT-partner, privacyverantwoordelijke, klant of externe specialist betrokken? -
Containment
Welke principes gelden om verdere schade te beperken? -
Onderzoek en bewijsbehoud
Hoe worden gebeurtenissen, logbestanden, besluiten en acties zorgvuldig vastgelegd? -
Herstel
Hoe wordt gecontroleerd dat systemen en dienstverlening veilig kunnen worden hervat? -
Communicatie
Wie communiceert intern en extern, via welk kanaal en na welke goedkeuring? -
Registratie
Welke feiten, tijden, beslissingen, eigenaren en vervolgacties worden vastgelegd? -
Evaluatie en lessons learned
Hoe worden oorzaak, respons, impact en verbeterpunten beoordeeld? -
Opvolging
Wie bewaakt verbeteracties en wanneer wordt de procedure opnieuw beoordeeld? -
Beschikbaarheid van het plan
Kan het plan ook worden geraadpleegd wanneer normale systemen niet beschikbaar zijn?
Niet ieder klein bedrijf heeft gespecialiseerde teams voor al deze onderdelen. Rollen kunnen gecombineerd worden, zolang eigenaarschap en escalatie maar duidelijk zijn.
Klantcommunicatie bij incidenten
Een klantvraag over incidentmelding vraagt meer dan een standaardzin “we melden incidenten direct”.
Leg intern vast:
- wie beoordeelt of de klant geraakt kan zijn;
- welke contractuele afspraken bestaan;
- wie communicatie goedkeurt;
- welke feiten al bevestigd zijn;
- welke onzekerheden nog bestaan;
- wie de vaste contactpersonen zijn;
- hoe vaak updates worden gegeven;
- hoe afsluiting en evaluatie worden vastgelegd.
Gebruik in vroege communicatie geen onbevestigde oorzaak of definitieve impactclaim.
Een veilige structuur is:
- wat is feitelijk vastgesteld;
- welke dienst of data kan geraakt zijn;
- welke maatregelen zijn genomen;
- wat wordt nog onderzocht;
- wanneer volgt de volgende update;
- via welk contactpunt vragen lopen.
Contractuele en wettelijke meldtermijnen kunnen verschillen. Beoordeel de exacte overeenkomst, het type incident en toepasselijke regelgeving voordat je één algemene termijn toezegt.
Oefenen, reviewen en leren
Een procedure op papier toont voorbereiding. Een oefening of gedocumenteerde evaluatie toont dat de organisatie heeft gekeken of de afspraken uitvoerbaar zijn.
Mogelijke vormen:
- tabletop-oefening met een realistisch scenario;
- simulatie van ransomware, accountovername of uitval;
- technische herstel- of uitwijkoefening;
- evaluatie van een echt incident;
- controle van bellijst en bereikbaarheid;
- review van klantcommunicatie;
- doorlopen van een privacy- en datalekscenario;
- gezamenlijke oefening met IT-partner of belangrijke klant;
- documentreview na grote organisatorische of technische wijziging.
Leg minimaal vast:
- datum;
- scenario;
- scope;
- deelnemers of betrokken rollen;
- belangrijke besluiten;
- knelpunten;
- verbeteracties;
- eigenaar;
- streefdatum;
- nacontrole.
Het NCSC adviseert leveranciers periodiek te oefenen en noemt in de context van verdiepende leveranciersmaatregelen ten minste jaarlijks als advies. Behandel dat als guidance, niet als een universele wettelijke termijn voor iedere organisatie. Risico, contract, omvang en wijzigingen kunnen aanleiding geven tot een andere frequentie.
Wat moet je niet delen?
Deel richting een klant niet automatisch:
- volledige incidentdossiers;
- persoonsgegevens;
- klantnamen;
- ongeredigeerde tickets;
- kwetsbaarheden die nog niet zijn opgelost;
- forensische images of ruwe forensische data;
- credentials, tokens en secrets;
- interne privécontactgegevens;
- aanvalspaden en technische zwakke plekken;
- volledige detectieregels;
- juridische correspondentie;
- communicatie met verzekeraar of advocaat;
- informatie over andere klanten;
- vertrouwelijke dreigingsinformatie zonder noodzaak.
Deel liever:
- een klantgerichte proceduresamenvatting;
- rollen in plaats van persoonsnamen;
- een geanonimiseerd registratievoorbeeld;
- een oefensamenvatting;
- de reviewdatum;
- relevante contractuele communicatiestappen;
- open punten en verbeteracties op hoofdlijnen.
Wat als er nog geen volwassen incidentproces bestaat?
Beschrijf dan niet dat een “volledig incident responseprogramma” is ingericht.
Gebruik deze structuur:
| Onderdeel | Wat je eerlijk beschrijft |
|---|---|
| Bestaande meldroute | Waar medewerkers of klanten nu melden |
| Huidige verantwoordelijke | Wie coördineert en beslist |
| Aanwezige onderdelen | Bijvoorbeeld bellijst, tickets, IT-partner, back-up en contactproces |
| Ontbrekende onderdelen | Bijvoorbeeld classificatiemodel, oefening of formele review |
| Tijdelijke werkwijze | Hoe incidenten tot formalisering worden behandeld |
| Verbeteractie | Welk document, proces of oefening wordt ingericht |
| Eigenaar | Wie verantwoordelijk is |
| Streefdatum | Realistisch besluit- of afrondmoment |
| Toekomstig bewijs | Procedureversie, oefenverslag of reviewlog |
Voorbeeld: procedure aanwezig, nog niet geoefend
Er is een vastgelegd incidentproces met meldkanaal, coördinatie, technische escalatie en klantcommunicatie. De procedure is nog niet in een formele tabletop-oefening getest. Dat is als open punt geregistreerd; na de oefening worden bevindingen en verbeteracties vastgelegd.
Voorbeeld: informeel proces wordt geformaliseerd
Incidenten worden momenteel gemeld bij de operationeel verantwoordelijke en samen met de IT-partner geregistreerd en opgevolgd. Rollen en contactlijnen bestaan in de praktijk, maar de volledige classificatie- en evaluatieprocedure wordt nog formeel vastgelegd. We claimen daarom niet dat het proces al volledig volwassen is.
Voorbeeld: klant vraagt om gevoelige incidentdetails
Wij kunnen onze incidentprocedure, rollen en communicatieroute toelichten. Specifieke incidentdossiers, persoonsgegevens en niet-opgeloste technische kwetsbaarheden delen wij niet zonder duidelijke noodzaak, passende grondslag en afgesproken vertrouwelijkheid.
Lees ook hoe je gedeeltelijk antwoordt op een securityvraag.
Voorbeeld van een volledig maar voorzichtig antwoord
Voor de geleverde dienst is een incidentprocedure ingericht met meldkanaal, triage, toegewezen rollen, technische escalatie, registratie, herstel en klantcommunicatie. De procedure wordt periodiek beoordeeld en is op [datum] doorlopen in een afgebakend scenario. We kunnen een klantgerichte samenvatting, de reviewdatum en een geanonimiseerd overzicht van verbeteracties aanleveren. Operationele contactgegevens, persoonsgegevens en gevoelige incidentdetails zijn uit de klantversie verwijderd.
Praktische checklist vóór verzending
- De klantvraag en scope zijn duidelijk.
- Procedureversie en reviewdatum zijn actueel.
- Rollen en beslissingsrechten zijn benoemd.
- Meldkanaal en escalatie zijn uitvoerbaar.
- Klantcommunicatie is afgestemd op contract en impact.
- Registratie en bewijsbehoud zijn beschreven.
- Er is bewijs van oefening, review of evaluatie.
- Open verbeterpunten hebben eigenaar en planning.
- Persoonsgegevens en gevoelige incidentdetails zijn verwijderd.
- Er wordt geen 24/7-dienst geclaimd zonder echte dekking.
- Meldtermijnen zijn niet generiek beloofd.
- De definitieve klantversie is intern goedgekeurd.
Wanneer is externe hulp nodig?
Betrek een technische incidentresponder wanneer actuele incidenten, forensisch onderzoek, containment of veilig herstel specialistische kennis vereisen.
Betrek privacy- of juridisch advies wanneer een mogelijk datalek, wettelijke melding, contractuele aansprakelijkheid, toezichthouder of klantclaim speelt. InstantSecure helpt met het structureren van de klantvraag en het bewijs, maar vervangt geen formeel juridisch oordeel of operationele incidentrespons.
Bronnen en actuele informatie
Geraadpleegd op 12 juli 2026:
- NCSC — Incidentresponsplan: https://www.ncsc.nl/incidenten-en-herstellen/incident-response-plan
- NCSC — Basisprincipe 5: Bereid je voor op incidenten: https://www.ncsc.nl/basisprincipes/basisprincipe-5-bereid-je-voor-op-incidenten
- NCSC — Verdiepende maatregelen voor toeleveranciers: https://www.ncsc.nl/cyberbeveiligingswet-nis2/verdiepende-maatregelen-voor-toeleveranciers
- NCSC — Toeleveranciers van Cbw-organisaties: https://www.ncsc.nl/cyberbeveiligingswet-nis2/toeleveranciers-van-cbw-organisaties
Hulp nodig bij het onderbouwen van incidentmanagement?
Moet je incidentmanagement onderbouwen? Laat de klantvraag, procedure en beschikbare bewijzen structureren.
Laat je concrete securityvragenlijst beoordelen
Gaat het om een breder leveranciersproces met documenten, vervolgvragen en contractafspraken? Bekijk dan vendor assessment hulp. Voor herhaald gebruik kun je een gecontroleerde klantversie en reviewbewijs opnemen in de Cybersecurity Bewijsmap.
