ISO/IEC 27001:2022 Annex A A.5.24–A.5.28 Incidentmanagement voor Nederlands MKB

Executive summary

Incidentmanagement in ISO/IEC 27001:2022 Annex A (A.5.24–A.5.28) is nadrukkelijk méér dan “een incidentenregister”. De controls vragen aantoonbare voorbereiding, triage & besluitvorming, gecoördineerde respons, leren/verbeteren en bewijsvoering. Juist bij Nederlandse MKB-organisaties zonder SOC ontstaan blinde vlekken en grote risico’s: verantwoordelijkheden zijn impliciet, paniek slaat toe, beslissingen gebeuren in chat/telefoon en blijven vaag, bewijs raakt kwijt, en meldplichten worden pas laat opgepakt. [1]

De grootste auditvalkuil het blijven hangen in: “laat maar een lijstje incidenten zien”, terwijl de normlogica (en praktische weerbaarheid) draait om herhaalbaar handelen onder druk: wie beslist wat, binnen welke tijd, met welke informatie, en hoe toon je dat achteraf aan. [2]

Voor MKB is een “Minimum Viable Incident Management” realistisch en effectief: een compact incidentresponsplan, een eenvoudige severity-matrix, een bel- en escalatielijst, vaste templates (incidentlog, besluitlog, bewijslijst, lessons learned), en contractuele afspraken met ICT-leveranciers. Dit sluit aan bij praktische handreikingen van Nationaal Cyber Security Centrum[3] en Digital Trust Center[4]. [5]

Wettelijk is “incident” vaak breder dan “datalek”, maar zodra persoonsgegevens geraakt (kunnen) zijn, gelden duidelijke verplichtingen: meldtermijnen, informatie aan betrokkenen wanneer er waarschijnlijk een hoog risico is, en een documentatieplicht. In de praktijk mislukken organisaties niet op techniek, maar op tempo + onderbouwing (wat wist je wanneer, waarom heb je wel/niet gemeld, welk bewijs is verzameld, welke besluiten zijn genomen en wat heb je gedaan om schade te beperken). [6]

Afbakening en uitgangspunten

Deze blogbehandelt ISO/IEC 27001:2022 Annex A controls A.5.24 t/m A.5.28 (incidentmanagement) met een focus op Nederlandse MKB bedrijven zonder dedicated securityteam en zonder SOC. Hiervoor zijn onder andere de volgende bronnen gebruikt: publicaties van International Organization for Standardization[7], NEN[8], Autoriteit Persoonsgegevens[9], ENISA[10] en National Institute of Standards and Technology[11] (voor incident response en forensics). [12]

Omdat de exacte ISO-teksten auteursrechtelijk beschermd zijn, bespreken wij die hier niet letterlijk: wel bespreken wij de normintentie, en vervolgens praktisch invullen met auditbare implementatie-eisen, bewijsvoorbeelden en MKB-specifieke patronen. De ISO/IEC 27035-serie wordt expliciet genoemd als relevante verdieping bij incidentmanagement (plan/prepare en lessons learned). [13]

Overzichtstabel: controls vs. typische faalpatronen vs. auditbewijs vs. remediatie

Control A.5.24 Information security incident management planning and preparation

Scope en doel

A.5.24 draait om vooraf organiseren: processen, rollen en verantwoordelijkheden, zodat je tijdens een incident sneller, consistenter kunt handelen wat leidt tot minder schade. Dit is in lijn met de definitie van incidentrespons als gecoördineerd proces om schade te beperken en herstel te versnellen. [34]

Voor MKB is de kern niet “meer documenten”, maar minder improvisatie: een klein team dat weet wat het moet doen, met een beperkte set scenario’s die je echt geoefend hebt. [35]

Concrete implementatie-eisen

Een auditwaardige implementatie voor MKB heeft minimaal:

Incidentresponsplan (IRP) met scope en triggers - Definieer wat je als organisatie als “security event” ziet en wanneer iets “incident” wordt (incl. voorbeelden). [36] - Leg vast welke incidenttypen je primair voorbereidt (praktisch: ransomware, phishing/BEC, datalek door misconfig, account compromise). Dit sluit aan bij de NCSC-aanpak om voorbereid te zijn op incidenten en incidentrespons (ook specifiek voor ransomware). [35] Leg hierbij ook vast welke acties direct genomen moeten worden om verdere schade te beperken, het is belangrijk om dit vooraf, in rust te doen.

Rollen en bevoegdheden (MKB-realistisch) - Incidentcoördinator (meestal IT-lead of MSP-contact). - Business owner (MT-lid) voor impact/continuïteitsbeslissingen. - Privacy/AVG-verantwoordelijke (FG of ‘privacy contactpunt’) voor datalekbeoordeling en communicatie. - Communicatie-eigenaar (intern/extern). - Leverancierscontact (MSP, cloud, softwareleverancier). [37]

Severity-matrix en escalatiecriteria - Een severity-matrix (S1–S4) op basis van impact (C/I/A), scope, klantimpact, wettelijke meldplichten, herstelduur. [21]Oefenen en onderhoud - Tabletop-oefeningen (minimaal jaarlijks; praktischer: 2× per jaar) en “lessons learned” verwerken. Oefenen en testen van voorbereiding en herstel (zoals back-ups) is expliciet onderdeel van “bereid je voor op incidenten”. [38]

Veelvoorkomende MKB-tekortkomingen

Rollen zonder gezag: “IT regelt het wel”, maar IT mag niet besluiten om productie stil te zetten, klanten te informeren of een juridische melding te doen. Resultaat: tijdverlies en chaotische communicatie. [39]

Geen contractuele route naar leveranciers: bij incidenten is de MSP vaak de feitelijke responder, maar escalatie/SLAs/forensische ondersteuning zijn niet vooraf afgesproken. Dit zie je terug bij supply-chain-achtige incidenten waar veel organisaties afhankelijk zijn van één beheerplatform. [40]

Oefenen ontbreekt: het plan bestaat, maar is nooit getest. Dan vallen belboom, toegang tot admin-accounts, crisiscommunicatie en besluitvorming juist onder druk uit elkaar. [41]

Audittekortkomingen: wat te weinig wordt gevraagd, en wat wél nodig is

Wat auditors vaak accepteren - “Hier is ons incidentprocedure-document” + “hier is de incidentenlijst”. [42]

Wat je als auditor óók zou moeten willen zien - Bewijs dat het IRP werkt: oefenverslag + verbeteracties + her-test (PDCA). [43]
- Actuele bel- en escalatielijst (inclusief buiten kantooruren) en aantoonbaar gebruikt bij minstens één (tabletop of echt) scenario. [44]
- Scenario-runbooks (ransomware/datalek/accountcompromise) inclusief “first 60 minutes” acties. [45]

Aanbevelingen en pragmatische tips

Tip: bouw een “IRP-lite” dat je durft te gebruiken - 3 pagina’s is vaak beter dan 30: (1) scope/rollen, (2) severity + escalatie, (3) runbooks + bewijschecklist. [15]

Tip: leg beslisbevoegdheid vooraf vast - Wie mag: systemen isoleren, accounts resetten, extern communiceren, forensisch onderzoek starten, klanten informeren, datalek melden? Dit voorkomt besluitvacuüm. [46]

Tip: maak herstel testbaar (niet alleen back-ups maken) - Test periodiek herstel; anders ontdek je bij een incident pas dat restores niet werken of te traag zijn. [47]

Relevante auditvragen en rode vlaggen

Interviewvragen - “Wie is incidentcoördinator bij afwezigheid van persoon X, en hoe bereiken we die buiten kantooruren?” [44]
- “Welke 3 incidenttypen hebben jullie geoefend, en wat hebben jullie aangepast na de oefening?” [43]

Documentchecks - IRP-versiebeheer + wijzigingslog + oefenverslagen. [14]
- Leverancierscontracten/SLAs: incidentnotificatie, support bij forensics, logtoegang, responstijden. [48]

Rode vlaggen - “We hebben geen tijd gehad om te oefenen” (structureel). [27]
- “We bellen wel iemand als het gebeurt” zonder belboom en zonder escalatiecriteria. [15]

Control A.5.25 Assessment and decision on information security events

Scope en doel

A.5.25 gaat over triage en besluitvorming: beveiligingsgebeurtenissen beoordelen en beslissen of (en hoe) ze als incident verder behandeld worden. De normintentie is dat je niet pas reageert als het “duidelijk fout is”, maar dat er een consistente, gedocumenteerde beoordelingsstap is die prioritering en respons triggert. [49] Ook betekent het beoordelen van gebeurtenissen, dat gebeurtenissen die geen impact hebben of kunnen hebben niet volledig gedocumenteerd hoeven te worden, dat scheelt weer administratie.

Concrete implementatie-eisen

Definities en classificatie - Definieer “event”, “incident”, “datalek/persoonsgegevensinbreuk” en koppel dit aan besliscriteria. [50] - Implementeer een eenvoudige classificatie: impact (C/I/A), waarschijnlijkheid/zekerheid, scope, wettelijke/contractuele impact, en urgentie. [21]

Besluitlog (auditbaar) - Leg vast: wie beoordeelde, welk bewijs was beschikbaar, welke severity, welke beslissing (escaleren/monitoren/sluiten), en waarom. Dit is in de praktijk cruciaal om achteraf te kunnen verantwoorden (ook richting toezichthouder). [51]

Koppeling aan meldplicht datalekken - Als er (mogelijk) persoonsgegevens geraakt zijn, moet je die beoordeling expliciet en tijdig doen, omdat de meldtermijn kort is en omdat documentatie vereist is. [52]

Veelvoorkomende MKB-tekortkomingen

Triage = “gevoel”: één IT’er beslist op intuïtie en sluit meldingen te vroeg (“vals alarm”), waardoor latere escalatie te laat komt. Dit patroon speelt nog meer bij organisaties met beperkte detectie/monitoring. [53]

Geen registratie van gebeurtenissen: gebeurtenissen die vaak voorkomen worden daardoor vergeten en niet structureel geanalyseerd op trends (en oorzaak). Één CEO Fraude mail is niet erg, maar 12 per jaar kan wel duiden op een gerichte aanval.

Geen scheiding tussen incidentmanagement en privacybeoordeling: men behandelt een mogelijk datalek puur technisch en vergeet de juridische workflow (melding aan toezichthouder/betrokkenen en documentatie). [54]

Audittekortkomingen: wat te weinig wordt gevraagd, en wat wél nodig is

Te lage lat - Een incidentregister zonder zichtbare classificatie/triage en zonder besluiten log. [55]

Wat “goed” eruitziet - Voor 3–5 willekeurige events: complete triage (input → beoordeling → besluit → opvolging), inclusief bewijs (logfragmenten, tickets, e-mails/Teams) en expliciete datalekbeoordeling waar relevant. [56]

Aanbevelingen en pragmatische tips

Tip: maak triage laagdrempelig, maar verplicht voor S2+ - Gebruik een template met 10 velden (tijd, bron, systeem, type, C/I/A, scope, vermoedelijke oorzaak, acties, beslissing, owner). Consistentie wint van perfectie. [57]

Tip: neem “beslisregels” op die auditors kunnen volgen - Voorbeelden: “Als e-mailaccount gecompromitteerd + mailboxregels → automatisch S2/S3”; “Als productie >2 uur stil → S3”; “Als persoonsgegevens mogelijk exfil → privacybeoordeling binnen 4 uur”. (Voorbeeldregels: organisatie-specifiek invullen.) [58]

Relevante auditvragen en rode vlaggen

Interviewvragen - “Wanneer was de laatste keer dat een event níet als incident is geclassificeerd—waarom, en wie heeft dat besloten?” [59]
- “Wie doet de datalekbeoordeling als de privacy-contactpersoon afwezig is?” [60]

Log-/toolchecks - Bestaan er “security events” in logs (bijv. M365 sign-in alerts) die nooit in triage terugkomen? (Dat is een signaal dat triage niet end-to-end is.) [18]

Rode vlaggen - Geen bewijs dat beslissingen zijn vastgelegd (“staat in Teams”). [61]
- Alles is “laag” geclassificeerd, maar er zijn duidelijke verstoringen geweest (bijv. herstelacties, downtime). [62]

Control A.5.26 Response to information security incidents

Scope en doel

A.5.26 vereist dat je incidenten afhandelt volgens gedocumenteerde procedures, in een gecoördineerde aanpak die containment, herstel en communicatie omvat. Dit sluit aan bij standaard incident response fasering (detectie/analyse → containment → eradication → recovery → post-incident). [63]

Concrete implementatie-eisen

Operationaliseren van procedures - Runbooks per incidenttype met: first response, containment opties, herstelstappen, communicatiestappen, en “stop/think” beslispunten (bijv. isoleren vs uitzetten). [64]

Communicatieplan (intern en extern) - Wie communiceert wat, naar wie, wanneer, en via welke kanalen; inclusief klanten/leveranciers en—indien relevant—verplichte communicatie. [37]

Herstelorganisatie - Herstel van kritieke processen hoort te zijn afgestemd op wat je maximaal acceptabel vindt aan uitval en wat je moet beschermen; dat vraagt om vooraf nadenken over herstel (KPI’s/continuïteit). [65]

Veelvoorkomende MKB-tekortkomingen

Containment is te drastisch of te laat - Te drastisch: direct alles uitzetten (bewijsverlies, langere downtime). - Te laat: blijven “kijken” tot ransomware of exfiltratie doorzet. Georganiseerde respons reduceert die extremen. [66]

Herstel zonder integriteitscontrole - MKB herstelt vaak “zo snel mogelijk” zonder te valideren of systemen schoon zijn of of back-ups betrouwbaar zijn. NCSC benadrukt het belang van herstel-inrichting en back-up testen. [67]

In stand houden van containment en respons maatregelen: na het incident de focus op de maatregelen die getroffen waren vanwege het incident verliezen, waardoor bijvoorbeeld een “tijdelijke downgrade van security om toch door te kunnen blijven werken” een permanente downgrade van security wordt.

Leverancier komt pas in beeld als het brandt - Bij MSP/cloud afhankelijkheden blijkt tijdens crisis dat support niet 24/7 is, of dat logtoegang/forensics “extra” is. Supply-chain incidenten laten zien hoe breed impact kan zijn. [68]

Audittekortkomingen: wat te weinig wordt gevraagd, en wat wél nodig is

Te magere auditpraktijk - “Laat 1 incident zien; oké, het is geregistreerd.” (Maar de kern is: was de respons aantoonbaar volgens procedure, incl. communicatie, containment, herstel en bewijs?) [42]

Wat je als auditor zou moeten eisen (steekproef) - Een end-to-end dossier: tijdlijn, beslissingen, communicatie, herstel, en (waar relevant) datalekmelding of onderbouwing waarom niet. [69]

Aanbevelingen en pragmatische tips

Tip: scheid “business restore” van “forensic preserve” - Maak een expliciet moment: “freeze evidence” (log export, snapshots) vóór grootschalige opschoonacties. Dit is consistent met forensics best practices. [70]

Tip: maak twee snelheden - Fast lane: bedrijfscontinuïteit (minimaal herstellen). - Deep lane: oorzaakonderzoek (wat/hoe binnengekomen, wat geraakt, wat moet structureel beter). [71]

Tip: borg communicatie-artefacten - Bewaar (1) een interne status-update (tijdlijn), (2) een klantbericht (indien nodig), (3) een leverancier-escalatie mail/ticket, en (4) een managementbesluitlog. [72]

Relevante auditvragen en rode vlaggen

Interviewvragen - “Toon het laatste incident waarbij je systemen hebt geïsoleerd: hoe is besloten, en welke procedure volgden jullie?” [73]
- “Wie mag extern communiceren, en hoe voorkom je tegenstrijdige boodschappen?” [39]

Documentchecks - Runbooks + bewijs dat ze gebruikt zijn (tickets, exports, changelogs). [74]

Rode vlaggen - Onverklaarbaar ontbreken van logs/snapshots “omdat we alles al opnieuw geïnstalleerd hebben”. [75]
- Geen aantoonbare back-up hersteltest, terwijl men zegt “we kunnen altijd terugzetten”. [76]

Control A.5.27 Learning from information security incidents

Scope en doel

A.5.27 verplicht dat opgedane kennis uit incidenten wordt gebruikt om controls en processen te versterken en herhaling te voorkomen. Dit is ook kernonderdeel van ISO/IEC 27035 (lessons learned fase) en van gangbare incident response guidance (post-incident activity). [77]

Concrete implementatie-eisen

Post-Incident Review (PIR) als vast proces - Binnen vaste termijn (bijv. 10 werkdagen) een review met: root cause, wat ging goed/fout, detectiepunten, responstijd, communicatie, klantimpact, kosten/uren, en verbeteracties. [78]

Trend & metrics (MKB-light) - Houd minimaal bij: type incident, volume, doorlooptijd tot detectie/containment, impact op business, en (grof) kosten/uren. Dit ondersteunt managementbesluitvorming en prioritering. [29] Dit kan ook waardevol zijn om periodiek te doen bij gebeurtenissen.

Aantoonbare opvolging - Verbeteracties krijgen owner, deadline, status. “Lessons learned” zonder opvolging is auditmatig en operationeel waardeloos. [29]

Veelvoorkomende MKB-tekortkomingen

“We hebben geen tijd” - De organisatie gaat door na herstel, maar laat de oorzaak en structurele verbeteringen liggen. Daardoor herhaalt het incident (varianten op hetzelfde patroon). [43]

Geen feedback-loop naar awareness - Het incident wordt niet vertaald naar gedrag en proces (bijv. phishing → training → e-mailhardening). ISO/IEC 27035-2 benoemt expliciet lessons learned; NCSC benadrukt ook voorbereiding en leren. [29]

Audittekortkomingen: wat te weinig wordt gevraagd, en wat wél nodig is

Te lage lat - Een “evaluatie” zonder concrete verbeteracties, of alleen technische acties zonder governance/communicatie-lessen. [29]

Sterk bewijs - PIR-document + actie-registratie in ISMS + bewijs van implementatie (config changes, trainingsmateriaal, aangepaste runbooks) en een tweede moment waarop is vastgesteld dat het nu beter is. [28]

Aanbevelingen en pragmatische tips

Tip: “3 verbeteringen max, maar echt afmaken” - MKB verdrinkt anders in verbeterlijsten. Kies de 3 meest risicoreducerende acties (bijv. MFA op admins, logging uitbreiden, back-up hersteltest), en rond af. [79]

Tip: maak een kwartaalritueel - Elk kwartaal 30 minuten: trendoverzicht incidenten/events + status verbeteracties. Dit is goedkoop, maar houdt het levend. [43]

Tooling: gebruik waar mogelijk handige applicaties die ondersteunen bij de processen (en ook herinneringen sturen).

Relevante auditvragen en rode vlaggen

Interviewvragen - “Welke structurele wijziging is voortgekomen uit het laatste serieuze incident, en hoe bewijs je dat die wijziging is doorgevoerd?” [29]

Rode vlaggen - PIR bestaat alleen voor grote incidenten (“de rest is niet belangrijk”). A.5.27 gaat nadrukkelijk ook over leren van kleinere incidenten en trends. [78]

Control A.5.28 Collection of evidence

Scope en doel

A.5.28 vereist dat je procedures hebt om bewijs rond security events/incidents te identificeren, veilig te verzamelen, te bewaren en overdraagbaar te maken. Het doel is tweeledig: - incident oplossen (technisch en organisatorisch), - en waar nodig juridische/contractuele stappen kunnen ondersteunen. [80]

Voor MKB is dit een van de meest vergeten controls, maar ook één van de meest “laaghangende” verbeteringen: een simpele evidence checklist + retentie-afspraken voorkomt dat je jezelf later niet kunt verdedigen (“we weten niet wat er is gebeurd” of juridisch nóg erger: “we kunnen niet aantonen dat er niet geknoeid is met het bewijsmateriaal”). [81]

Concrete implementatie-eisen

Evidence playbook - Wat verzamel je bij welke incidenttypen (ransomware, BEC, datalek, insider, misconfig). - In welke volgorde (evidence freeze vóór opschonen). - Waar sla je het op (gescheiden, beperkt toegankelijk). - Wie mag het inzien/delen. [82]

Chain of custody (praktisch) - Een log met: item, bron, tijd, verzamelaar, opslaglocatie, overdrachten, integriteitskenmerken (bijv. hash waar relevant). Blijft vooral belangrijk als er juridische stappen kunnen volgen. [83]

Logretentie en integriteit - Zonder minimale logretentie is “bewijs verzamelen” feitelijk onmogelijk. Dit raakt niet alleen techniek, maar ook governance (welke logs, hoe lang, en wie kan erbij). [84]

AVG-implicaties: bewijs is vaak ook persoonsgegevens

In veel incidenten bevatten logs, e-mails en ID’s persoonsgegevens. Praktisch betekent dit voor MKB: - beperk toegang tot evidence (need-to-know), deel extern alleen wat nodig is (dataminimalisatie), - leg vast waarom je informatie deelt (accountability), en zorg dat je datalekdocumentatie op orde is (die documentatieplicht bestaat expliciet). [85]

Veelvoorkomende MKB-tekortkomingen

“We hebben het al weggegooid” - Endpoint opnieuw geïnstalleerd zonder exports; mailbox opgeschoond; logs overschreven door korte retentie; cloud audit logs niet ingeschakeld. Dan blijft alleen sentiment over, geen feiten. [75]

Bewijs besmet - MKB laat responders direct inloggen, tools draaien, bestanden verplaatsen zonder vastlegging. Dan is later niet aantoonbaar wat origineel was en wat door response is veranderd. [86]

Audittekortkomingen: wat te weinig wordt gevraagd, en wat wél nodig is

Te lage lat - “We bewaren logs” zonder bewaartermijn, procedure, toegangsbeperking en zonder voorbeeld van een evidence set. [87]

Sterke auditaanpak (praktisch) - Neem één incident en vraag: “Welke evidence is veiliggesteld, waar ligt het, wie had toegang, en hoe toon je integriteit/keten aan?” [88]

Aanbevelingen en pragmatische tips

Tip: evidence checklist per scenario (start klein) - Ransomware minimumset: domain controller logs, EDR alerts, back-up logs, snapshots, lijst versleutelde systemen, ransom note, netflow/firewall logs indien beschikbaar. [89]

Tip: gebruik een “evidence vault” - Een aparte, beperkte opslaglocatie (bijv. afgeschermde SharePoint/drive) met logging van toegang en versiebeheer. Dit is al een grote stap voor MKB. Indien mogelijk, pas zelfs integritieitsmaatregelen toe zoals hashing.[55]

Relevante auditvragen en rode vlaggen

Interviewvragen - “Wat is jullie minimale logretentie per kernsysteem, en hoe voorkom je overschrijven bij incidenten?” [33]
- “Kun je laten zien hoe de chain-of-custody template wordt gebruikt?” [90]

Rode vlaggen - Geen procedure “freeze evidence first”. [33]
- Evidence wordt gedeeld via e-mail/WhatsApp zonder controle of minimale set. [91]

Thematische patronen, casussen en MKB-checklist

Voorbereiding en governance

Een MKB-implementatie werkt pas als governance klopt: wie beslist, wie betaalt, wie communiceert. NCSC benadrukt voorbereiden op incidenten als basisprincipe, inclusief plannen, oefenen en getest herstel. [92]

Implementatiepatronen (MKB) - “Virtual IR team” (geen SOC): vaste kern + vaste externe responder (MSP/forensisch bureau) met contractueel afgesproken responstijden en deliverables. [93]
- MT-beslislog: elk S3/S4 incident heeft een management-besluitlog (ook als het kort is). Dat is auditbaar en versnelt meldplichtbeslissingen. [51]

Typische casus (NL): ransomware en governance-falen - In de casus rondom Hof van Twente[94] (ransomware) kwam in bestuurlijke evaluaties sterk terug hoe groot de impact op dienstverlening kan zijn en welke bestuurlijke lessen er zijn (o.a. rond monitoring, sturing en weerbaarheid). [95]
Hoe betere A.5.24–A.5.27 had geholpen: vooraf geoefende escalatie + herstelscenario’s, scherpere sturing op risicoreductie en aantoonbare opvolging van verbeterpunten.

Detectie en triage

Zonder SOC moet je triage slim “inkopen”: benut cloud-native alerts (M365/Google/EDR), maak een meldkanaal voor medewerkers (phishing/verdachte mails) en creëer een simpele severity-matrix die beslissingen versnelt. [96]

Typische casus (NL): late detectie → zware impact - In het rapport over de cyberaanval op Universiteit Maastricht[97] werd o.a. beschreven dat onvoldoende detectie/monitoring en opvolging na phishing een rol speelde bij het kunnen uitvoeren van ransomware later. [98]
Hoe betere A.5.25 had geholpen: eerder event→incident escaleren, vastgelegde triage en prioritering, en sneller containment.

Respons en escalatie

Voor MKB is de eerste uur-fase (“first 60 minutes”) vaak bepalend. NCSC biedt expliciet handvatten rond incidentrespons en communicatie. [99]

De grootste praktische tip hiervoor is het gebruik van specieke tooling dat voor jou werkt.

Leren en verbeteren

Leren is niet “post-mortem als er tijd is”, maar een control (A.5.27). ISO/IEC 27035-2 benoemt expliciet plan/prepare én lessons learned als onderdeel van incident response guidance. [101]

Praktisch patroon - PIR-template + verbeteractie-register + kwartaalreview met MT (30 minuten). [29]

Bewijs en forensics

Praktische diepte: chain of custody en logretentie (MKB-proof)

- NIST benadrukt het belang van gedocumenteerde evidence-handling wanneer bewijs ook voor juridische trajecten nodig kan zijn. [75]

- ENISA biedt guidance voor first responders over het omgaan met elektronisch bewijs en het belang van een audit trail/chain-of-custody. [103]

Wat je in MKB minimaal regelt

- Evidence freeze: export logs + snapshots vóór opschonen.

- Chain-of-custody template (1 pagina).

- Minimale logretentie voor kernsystemen (auth, e-mail, endpoint, firewall) afgestemd op risico. [70]

Leveranciers, BCP en privacy

Leveranciers - Contracteer verplicht: incidentnotificatie, support bij onderzoek, responstijden, en toegang tot relevante logs. De Kaseya VSA supply-chain ransomware casus laat zien dat veel (MKB-)organisaties tegelijk geraakt kunnen worden via beheerketens; dit maakt leverancier-afspraken prioriteit. [40]

Business continuity - NCSC benadrukt herstel, MTPD-achtige denkstappen (maximale uitvalsduur) en het testen van back-ups als kern van herstelvermogen. [104]

Privacy/meldplicht - AP geeft stapsgewijze uitleg over datalek melden en criteria voor wel/niet melden en informeren van betrokkenen. [105] - AP heeft bovendien handreikingen en “10 tips” gepubliceerd om datalekregistratie professioneler te maken; dit is direct relevant voor auditbewijs rond incidentdocumentatie. [106] - De boete voor een te late melding (Uber) onderstreept dat tijdigheid en naleving daadwerkelijk gehandhaafd worden. [107]

Afsluitende checklist voor MKB-managers

Deze checklist is bedoeld als “audit-ready minimum” voor A.5.24–A.5.28:

Governance & voorbereiding - IRP (≤3–5 pagina’s) met rollen, scope, belboom en externe contactpunten. [14]
- Severity-matrix + escalatiecriteria (S1–S4) + beslisboom event→incident. [21]
- 2 tabletop-oefeningen per jaar + aantoonbare verbeteracties. [43]

Triage & besluitvorming - Triage-template + besluitlog verplicht voor S2+. [55]
- Datalekbeoordeling workflow (wie, wanneer, welke informatie nodig). [105]

Respons - Runbooks voor top-3 incidenttypen (ransomware, BEC/phishing, datalek door misconfig). [45]
- Communicatieplan intern/extern (incl. klanten/leveranciers). [39]
- Back-up hersteltest frequentie vastgelegd én uitgevoerd. [76]

Leren - PIR binnen 10 werkdagen + actie-eigenaren/deadlines + kwartaalreview. [29]

Bewijs/forensics - Evidence checklist + “freeze first” procedure. [70]
- Chain-of-custody template en veilige evidence opslag (need-to-know). [108]
- Minimale logretentie voor kernsystemen (auth/e-mail/endpoint/firewall) afgestemd op risico. [33]

Leveranciers/contracten - Contractuele incidentnotificatie, responstijden, forensische ondersteuning en logtoegang met MSP/cloud-leveranciers. [48] 

Bronnen en verwijzingen

[1] [2] [5] [9] [14] [15] [16] [17] [22] [23] [34] [42] [44] [73] [74] [99] NCSC - Incidentresponseplan

https://www.ncsc.nl/incidenten-en-herstellen/incident-response-plan

[3] [13] [28] [29] [77] [78] [101] ISO/IEC 27035-2:2023 - Information technology

https://www.iso.org/standard/78974.html

[4] [11] [26] [27] [35] [38] [41] [43] [79] [92] Basisprincipe 5. Bereid je voor op incidenten

https://www.ncsc.nl/basisprincipes/basisprincipe-5-bereid-je-voor-op-incidenten

[6] [20] [52] [54] [58] [60] [69] [105] Zo meldt u een datalek

https://www.autoriteitpersoonsgegevens.nl/themas/beveiliging/datalekken/zo-meldt-u-een-datalek

[7] [47] [76] Hoe test ik een back-up?

https://www.ncsc.nl/back-up/hoe-test-ik-een-back-up

[8] [39] [46] [72] Externe communicatie na een incident

https://www.ncsc.nl/incidenten-en-herstellen/externe-communicatie-na-een-incident

[10] [40] [48] [68] [93] CISA-FBI Guidance for MSPs and their Customers Affected ...

https://www.cisa.gov/news-events/alerts/2021/07/04/cisa-fbi-guidance-msps-and-their-customers-affected-kaseya-vsa-supply-chain-ransomware-attack

[12] NEN-EN-ISO/IEC 27001:2023 nl

https://www.nen.nl/nen-en-iso-iec-27001-2023-nl-314206

[18] [36] [37] [49] [50] [57] [96] [100] Incidentresponse: waar begin ik?

https://www.ncsc.nl/incidenten-en-herstellen/incidentresponse-waar-begin-ik

[19] [51] [56] [59] [85] [106] AP doet handreikingen om registratie datalekken te ...

https://www.autoriteitpersoonsgegevens.nl/uploads/imported/handreiking_verbeteren_registratie_datalekken.pdf

[21] Plan: Your cyber incident response processes

https://www.ncsc.gov.uk/collection/incident-management/cyber-incident-response-processes

[24] [62] [65] [67] [71] [104] Hoe herstel ik van een cyberincident?

https://www.ncsc.nl/incidenten-en-herstellen/herstel-van-een-cyberincident

[25] [45] [64] [94] NCSC - Incidentresponsplan Ransomware

https://www.ncsc.nl/incidenten-en-herstellen/incidentresponsplan-ransomware

[30] [32] [81] [82] [97] Good Practice Guide for Incident Management - ENISA

https://www.enisa.europa.eu/sites/default/files/publications/Incident_Management_guide.pdf

[31] [63] [66] [75] [80] [84] [87] [89] [102] Computer Security Incident Handling Guide

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf

[33] [70] [86] NIST SP 800-86, Guide to Integrating Forensic Techniques ...

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf

[53] [98] CYBERAANVAL UNIVERSITEIT MAASTRICHT

https://www.onderwijsinspectie.nl/site/binaries/site-content/collections/documents/2020/06/12/rapport-cyberaanval-universiteit-maastricht/Rapport%2BCyberaanval%2BUniversiteit%2BMaastricht.pdf

[55] [61] [91] 10 tips voor professionele datalekregistratie

https://www.autoriteitpersoonsgegevens.nl/uploads/imported/10_tips_datalekregistratie.pdf

[83] [88] [90] [108] Electronic evidence - a basic guide for First Responders

https://syntheticdrugs.unodc.org/uploads/syntheticdrugs/res/library/cybercrime_html/Electronic_Evidence_A_Basic_Guide_for_First_Responders_ENISA.pdf

[95] De perfecte storm

https://gemeenteraad.hofvantwente.nl/Vergaderingen/Gemeenteraad/2022/25-oktober/19%3A30/Eindrapport-rekenkamercommissie-Informatiebeveiligingsbeleid-Hof-van-Twente-De-perfecte-storm-1.pdf

[103] Electronic evidence - a basic guide for First Responders - ENISA

https://www.enisa.europa.eu/publications/electronic-evidence-a-basic-guide-for-first-responders

[107] AP legt Uber boete op voor te laat melden datalek

https://www.autoriteitpersoonsgegevens.nl/actueel/ap-legt-uber-boete-op-voor-te-laat-melden-datalek