ISMS Copilot
NIS2 met AI

Hoe u NIS2-incidentrapportage implementeert met behulp van AI

Overzicht

U leert hoe u AI kunt gebruiken om een volledige NIS2-incidentrapportagefunctie op te bouwen die is afgestemd op Artikel 23. Deze gids behandelt de criteria voor de significantie van incidenten, de verplichte rapportageworkflow van 24 uur/72 uur/één maand, sjablonen voor vroege waarschuwingen, formaten voor incidentmeldingen met indicators of compromise (IOC's), de structuur van het eindrapport met oorzaakanalyse (root cause analysis), vrijwillige rapportage van dreigingen en near-misses, en integratie met uw nationale CSIRT.

Voor wie dit bedoeld is

Deze gids is voor:

  • Incident response managers en SOC-leads die NIS2-conforme rapportageworkflows opbouwen

  • CISO's die verantwoordelijk zijn voor het opzetten van incidentrapportagefuncties die voldoen aan de tijdlijnen van Artikel 23

  • Compliance officers die moeten garanderen dat rapportageprocedures voldoen aan de eisen van toezichthoudende autoriteiten

  • Security consultants die incidentrapportage implementeren voor klanten in door NIS2 gereguleerde sectoren

  • Leden van het bestuursorgaan die inzicht moeten hebben in hun meldingsplicht en toezichthoudende verantwoordelijkheden

Voordat u begint

U heeft het volgende nodig:

  • Een ISMS Copilot-account (gratis proefperiode beschikbaar)

  • Uw NIS2-entiteitsclassificatie (essentieel of belangrijk) -- zie Hoe te beginnen met NIS2-implementatie met behulp van AI

  • Contactgegevens van uw nationale CSIRT en bevoegde autoriteit

  • Uw Incident Response-beleid (zie Hoe u NIS2-cyberbeveiligingsbeleid opstelt met behulp van AI voor hulp bij het genereren hiervan)

  • Inzicht in uw kritieke diensten en systemen vanuit uw risicobeoordeling (zie Hoe u een NIS2-risicobeoordeling uitvoert met behulp van AI)

Er gelden strikte tijdlijnen: NIS2 Artikel 23 vereist een vroege waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport na één maand voor significante incidenten. Het niet naleven van deze tijdlijnen kan leiden tot boetes tot € 10 miljoen of 2% van de wereldwijde omzet voor essentiële entiteiten. Het bouwen van robuuste rapportageworkflows voordat een incident zich voordoet is niet optioneel -- het is een compliance-vereiste.

De vereisten voor NIS2-incidentrapportage begrijpen

Wat Artikel 23 vereist

Artikel 23 van de NIS2-richtlijn stelt een meerfasig meldingskader vast voor significante incidenten. Elke fase heeft specifieke inhoudelijke vereisten en deadlines.

Rapportagefase

Deadline

Inhoudelijke vereisten

Ontvanger

Vroege waarschuwing (Early warning)

Binnen 24 uur na kennisname

Indicatie of het incident vermoedelijk is veroorzaakt door onrechtmatige of kwaadwillige handelingen; indicatie of het grensoverschrijdende impact kan hebben

Nationaal CSIRT of bevoegde autoriteit

Incidentmelding

Binnen 72 uur na kennisname

Update van de vroege waarschuwing; eerste beoordeling van de ernst en impact; indicators of compromise (IOC's) indien beschikbaar

Nationaal CSIRT of bevoegde autoriteit

Tussenrapportage

Op verzoek van CSIRT of bevoegde autoriteit

Relevante statusupdates over de afhandeling van incidenten en herstel

Nationaal CSIRT of bevoegde autoriteit

Eindrapport

Binnen één maand na de incidentmelding

Gedetailleerde beschrijving van het incident inclusief ernst en impact; type dreiging of basisoorzaak; toegepaste en lopende beperkende maatregelen; grensoverschrijdende impact (indien van toepassing)

Nationaal CSIRT of bevoegde autoriteit

Voortgangsrapport (voor lopende incidenten)

Na één maand indien het incident nog steeds voortduurt

Voortgangsupdate in plaats van een eindrapport; eindrapport verschuldigd binnen één maand na afloop van het incident

Nationaal CSIRT of bevoegde autoriteit

De klok begint te lopen bij kennisname: De vensters van 24 uur en 72 uur beginnen op het moment dat de entiteit zich bewust wordt van het significante incident -- niet vanaf het moment dat het bevestigd of volledig geanalyseerd is. Dit betekent dat uw detectie- en triageprocessen snel genoeg moeten zijn om potentiële significante incidenten te identificeren en de rapportage binnen enkele uren te activeren.

Wanneer is een incident "significant"?

Artikel 23, lid 3, definieert een significant incident als een incident dat:

  • (a) Een ernstige operationele verstoring van de diensten of financiële verliezen voor de betrokken entiteit heeft veroorzaakt of kan veroorzaken

  • (b) Andere natuurlijke of rechtspersonen heeft getroffen of kan treffen door aanzienlijke materiële of immateriële schade te veroorzaken

De Europese Commissie kan via uitvoeringshandelingen de criteria voor de significantie van incidenten nader specificeren. Nationale omzettingswetten kunnen ook aanvullende of specifiekere drempels definiëren. Uw organisatie moet interne classificatiecriteria opstellen die aansluiten bij deze definities.

Vrijwillige rapportage

Artikel 23 moedigt ook vrijwillige rapportage aan van:

  • Near-misses (incidenten die een significante impact hadden kunnen hebben, maar die voorkomen zijn of vroegtijdig ontdekt zijn)

  • Significante cyberdreigingen die potentieel significante incidenten kunnen veroorzaken

  • Informatie die kan helpen bij het voorkomen van of reageren op incidenten die andere entiteiten treffen

Stap 1: Bouw uw incidentclassificatiematrix

Significantiedrempels definiëren

Voordat u incidenten kunt rapporteren, hebt u duidelijke, ondubbelzinnige criteria nodig om te bepalen wanneer een incident de drempel "significant" overschrijdt en NIS2-rapportageverplichtingen activeert.

  1. Genereer de classificatiematrix:

    "Maak een uitgebreide incidentclassificatiematrix voor NIS2 Artikel 23-compliance voor onze [sector]-organisatie (geclassificeerd als [essentiële/belangrijke] entiteit). De matrix moet bevatten: vier ernstniveaus (Kritiek, Hoog, Medium, Laag) met duidelijke criteria voor elk niveau. Definieer voor elk niveau: drempels voor operationele impact (duur van de dienstonderbreking, percentage betrokken gebruikers, degradatieniveau), drempels voor financiële impact (directe kosten, potentiële regelgevende boetes, omzetverlies), drempels voor data-impact (blootgestelde records, getroffen datatypes, impact op vertrouwelijkheid/integriteit/beschikbaarheid), impact op derden (aantal getroffen entiteiten, potentieel voor sectorbrede impact) en reputatie-impact. Geef duidelijk aan welke ernstniveaus een 'significant incident' vormen onder Artikel 23, lid 3, en verplichte rapportage triggeren. Voeg sectorspecifieke voorbeelden toe voor [sector]."

  2. Maak de triage-beslisboom:

    "Maak een beslisboom voor eerstehulpverleners om snel te bepalen of een incident 'significant' is onder NIS2 Artikel 23 en rapportage vereist. De beslisboom moet bruikbaar zijn binnen 30 minuten na detectie van het incident. Voeg ja/nee-vragen toe over: (1) Is de dienstverlening aangetast of loopt deze gevaar? (2) Heeft het incident betrekking op kritieke systemen of gegevens? (3) Kan het impact hebben op andere entiteiten of personen? (4) Is er bewijs van kwaadwillige of onrechtmatige activiteit? (5) Zou er sprake kunnen zijn van grensoverschrijdende impact? Koppel elk pad aan een classificatieniveau en de vereiste responsacties."

  3. Genereer sectorspecifieke significantievoorbeelden:

    "Genereer 15 realistische incidentscenario's voor een [sector]-organisatie en classificeer elk scenario als significant of niet-significant onder NIS2 Artikel 23, lid 3. Leg voor elk scenario de rationale achter de classificatie uit. Voeg scenario's toe die twijfelgevallen zijn om te illustreren waar een vakkundig oordeel nodig is. Dit dient als referentie voor training van ons incident response team."

Bij twijfel: rapporteren: De gevolgen van te late rapportage zijn ernstiger dan de gevolgen van het rapporteren van een incident dat achteraf niet significant blijkt te zijn. Als er een redelijke mogelijkheid is dat een incident aan de significantiecriteria voldoet, start dan de vroege waarschuwing binnen 24 uur. U kunt de classificatie in latere meldingen bijwerken.

Stap 2: Maak de workflow en het sjabloon voor de 24-uurs vroege waarschuwing

De vereisten voor vroege waarschuwing begrijpen

De vroege waarschuwing is uw eerste communicatie naar het nationale CSIRT of de bevoegde autoriteit. Deze moet binnen 24 uur na kennisname van een significant incident worden ingediend. De inhoudelijke vereisten zijn bewust minimaal gehouden om snelle rapportage mogelijk te maken -- er wordt niet verwacht dat u in dit stadium een volledig beeld heeft.

  1. Genereer het sjabloon voor vroege waarschuwing:

    "Maak een NIS2 Artikel 23 sjabloon voor een vroege waarschuwing (early warning) voor onze [sector]-organisatie. Het sjabloon moet alle velden bevatten die binnen het venster van 24 uur vereist zijn: identificatie van de rapporterende entiteit (naam, NIS2-registratienummer, sector, entiteitsclassificatie), incident-ID (intern referentienummer), datum en tijd van kennisname, korte beschrijving van het incident (wat is er gebeurd, welke systemen/diensten zijn getroffen), of het incident vermoedelijk is veroorzaakt door onrechtmatige of kwaadwillige handelingen (ja/nee/onbekend met motivatie), of het grensoverschrijdende impact kan hebben (ja/nee/onbekend met motivatie), eerste beoordeling van de omvang (betrokken diensten, geografische reikwijdte), contactpersoon voor follow-up (naam, rol, telefoon, e-mail, beveiligd communicatiekanaal) en eventuele onmiddellijk genomen maatregelen. Vormgegeven als een formulier dat in 15 minuten kan worden ingevuld."

  2. Bouw de workflow voor vroege waarschuwing:

    "Maak een stapsgewijze workflow voor het indienen van de NIS2 24-uurs vroege waarschuwing, van incidentdetectie tot de indiening van het rapport. Inclusief: (1) detectie en eerste triage (doel: 2 uur), (2) significantiebeoordeling met behulp van onze classificatiematrix (doel: 1 uur), (3) melding aan incidentmanager en CSIRT-liaison (doel: 30 minuten), (4) invullen van het vroege waarschuwingsrapport (doel: 30 minuten), (5) interne goedkeuring (CISO of aangewezen autoriteit) (doel: 1 uur), (6) indiening bij nationaal CSIRT via [kanaal specificeren], (7) interne documentatie en tracking. Voeg tijdsdoelen toe voor elke stap om te garanderen dat de deadline van 24 uur met marge wordt gehaald. Specificeer wie verantwoordelijk is voor elke stap, escalatieprocedures als verantwoordelijken niet beschikbaar zijn, en procedures voor buiten kantooruren."

24 uur betekent 24 uur: De klok loopt continu vanaf het moment van kennisname -- inclusief weekenden, feestdagen en uren buiten kantoortijd. Uw workflow moet procedures bevatten voor buiten kantooruren en in het weekend met aangewezen on-call personeel dat gemachtigd is om vroege waarschuwingen in te dienen. Een significant incident op vrijdag om 23:00 uur moet nog steeds uiterlijk zaterdag om 23:00 uur gerapporteerd zijn.

Stap 3: Maak de workflow en het sjabloon voor de 72-uurs incidentmelding

Meldingsvereisten begrijpen

De incidentmelding na 72 uur werkt de vroege waarschuwing bij met aanvullende details. In dit stadium moet uw onderzoek ver genoeg gevorderd zijn om een eerste beoordeling te geven van de ernst, de impact en indicators of compromise.

  1. Genereer het sjabloon voor incidentmelding:

    "Maak een NIS2 Artikel 23 sjabloon voor incidentmelding (72-uurs rapport) voor onze organisatie. Voeg alle vereiste velden toe: verwijzing naar de vroege waarschuwing, bijgewerkte incidentbeschrijving met meer detail, eerste beoordeling van de ernst van het incident (volgens onze classificatiematrix), beoordeling van de impact -- getroffen diensten, aantal getroffen gebruikers/entiteiten, duur van de verstoring, indicators of compromise (IOC's) indien beschikbaar -- IP-adressen, domeinen, file hashes, malware signatures, waargenomen TTP's (Tactics, Techniques, Procedures), identificatie van de aanvalsvector (indien bekend), getroffen systemen en netwerken, eerste genomen inperkings- en herstelmaatregelen, beoordeling van grensoverschrijdende impact, beoordeling of het incident veroorzaakt werd door onrechtmatige of kwaadwillige handelingen en eventuele verzoeken om assistentie van het CSIRT. Voeg een bijlagegedeelte toe voor technische IOC-details."

  2. Bouw de procedure voor IOC-verzameling:

    "Maak een procedure voor het verzamelen en formatteren van indicators of compromise (IOC's) voor NIS2-incidentmeldingen. Behandel: types IOC's om te verzamelen (netwerk-, host-, e-mail-, bestandsindicatoren), verzamelmethoden en tools, bewijsbehoud en chain of custody, standaarden voor IOC-formattering (STIX/TAXII waar van toepassing), classificatie van IOC's (TLP-markering -- Traffic Light Protocol), wat op te nemen in het 72-uurs rapport versus wat apart te delen met CSIRT, en hoe om te gaan met gevoelige IOC's die de interne architectuur kunnen onthullen."

  3. Bouw de 72-uurs meldingsworkflow:

    "Maak een gedetailleerde workflow voor de NIS2 72-uurs incidentmelding. Inclusief: onderzoeksactiviteiten die binnen het 72-uurs venster moeten worden voltooid (loganalyse, forensische triage, IOC-extractie, impactbeoordeling), stappen voor bewijsverzameling en -behoud, proces voor het opstellen van het rapport met input van het technische team/juridisch/communicatie, interne beoordeling- en goedkeuringsketen, indieningsprocedure bij het nationale CSIRT, melding aan stakeholders (bestuursorgaan, betrokken partijen, wetshandhaving indien van toepassing) en documentatievereisten. Specificeer rollen, tijdsdoelen en escalatieprocedures."

Stap 4: Maak de workflow en het sjabloon voor het eindrapport na één maand

Vereisten voor het eindrapport begrijpen

Het eindrapport is de meest uitgebreide indiening en moet een gedetailleerde beschrijving van het incident, een oorzaakanalyse (root cause analysis) en beperkende maatregelen bevatten. Als het incident na één maand nog steeds voortduurt, dient u een voortgangsrapport in en levert u het eindrapport binnen één maand na de oplossing van het incident.

  1. Genereer het sjabloon voor het eindrapport:

    "Maak een NIS2 Artikel 23 sjabloon voor een eindrapport voor onze [sector]-organisatie. Voeg alle vereiste onderdelen toe: (1) Managementsamenvatting (overzicht van één pagina voor management en autoriteiten), (2) Tijdlijn incident (chronologische volgorde van de eerste indicatoren via detectie, rapportage, inperking, uitroeiing en herstel, met tijdstempels), (3) Gedetailleerde beschrijving incident (getroffen systemen, aanvalsvector, beoordeling van de dreigingsactor, getroffen gegevens), (4) Beoordeling ernst en impact (definitieve beoordeling van operationele, financiële, data- en derde-partij impact volgens onze matrix), (5) Oorzaakanalyse (technische root cause, bijdragende factoren, systemische zwakheden), (6) Indicators of Compromise (volledige IOC-lijst met classificaties), (7) Toegepaste beperkende maatregelen (onmiddellijke inperking, uitroeiingsacties, herstelstappen), (8) Lopende beperkende maatregelen (lange-termijn fixes, verbetering van controles, versterking monitoring), (9) Beoordeling grensoverschrijdende impact, (10) Geleerde lessen en preventieve aanbevelingen, (11) Bijlagen (technisch bewijs, tijdlijndetails, IOC-details). Formatteer voor indiening bij nationaal CSIRT."

  2. Genereer de methodologie voor oorzaakanalyse:

    "Maak een methodologie voor oorzaakanalyse (RCA) voor de definitieve NIS2-incidentrapporten. Inclusief: RCA-technieken die geschikt zijn voor cybersecurity-incidenten (Five Whys, Fishbone/Ishikawa, Fault Tree Analysis), hoe onderscheid te maken tussen de directe oorzaak en de basisoorzaak (root cause), sjabloon voor het documenteren van het RCA-proces en de bevindingen, hoe bijdragende factoren te identificeren (technisch, procesmatig, menselijk, organisatorisch), hoe corrigerende en preventieve acties af te leiden uit basisoorzaken, en hoe RCA-bevindingen te presenteren aan zowel technisch publiek als het bestuursorgaan."

  3. Bouw het sjabloon voor voortgangsrapportage bij lopende incidenten:

    "Maak een NIS2-sjabloon voor een voortgangsrapport voor incidenten die na één maand nog lopen. Inclusief: verwijzing naar de oorspronkelijke vroege waarschuwing en melding, huidige incidentstatus en responsfase, bijgewerkte impactbeoordeling, genomen acties sinds het laatste rapport, lopende inperkings- en uitroeiingsmaatregelen, geschatte tijdlijn voor oplossing en eventuele bijgewerkte IOC's of threat intelligence."

Kwaliteit telt: Het eindrapport is het document dat toezichthouders het meest zorgvuldig zullen bestuderen. Een grondige oorzaakanalyse die systemische zwakheden identificeert en concrete corrigerende acties voorstelt, getuigt van een volwassen incidentmanagement. Een oppervlakkig rapport dat het incident toeschrijft aan één enkel foutpunt zonder bijdragende factoren te onderzoeken, zal extra aandacht trekken.

Stap 5: Bouw incident response playbooks

Scenariospecifieke playbooks met geïntegreerde NIS2-rapportage

Playbooks vertalen uw incident response-beleid en rapportageworkflows in specifieke, bruikbare procedures voor veelvoorkomende incidenttypes. Elk playbook moet de NIS2-rapportagemijlpalen integreren in de responsworkflow.

  1. Genereer een ransomware-playbook:

    "Maak een uitgebreid ransomware incident response playbook voor onze [sector]-organisatie met geïntegreerde NIS2 Artikel 23 rapportage. Inclusief: detectietriggers en vroege indicatoren, onmiddellijke inperkingsacties (netwerkisolatie, rotatie van inloggegevens), NIS2-significantiebeoordeling (ransomware die essentiële/belangrijke diensten treft is bijna altijd significant), trigger en voltooiing van de 24-uurs vroege waarschuwing, bewijsbehoud (schakel versleutelde systemen niet uit, maak geheugendumps), forensische onderzoeksstappen, IOC-extractie voor 72-uurs melding, uitroeiingsstappen (verwijdering malware, sluiten aanvalsvector), herstel van offline backups, beoordeling van data-exfiltratie, voltooiing 72-uurs melding met IOC's, coördinatie met wetshandhaving, besliskader voor losgeldbetaling, verificatie van herstel van diensten, eindrapport na één maand met oorzaakanalyse en verbeteringen na het incident."

  2. Genereer een datalek-playbook:

    "Maak een datalek incident response playbook met geïntegreerde NIS2 Artikel 23 en AVG (GDPR) Artikel 33/34 rapportage. Behandel: detectie en beoordeling van blootstelling van gegevens, bepaling omvang (welke gegevens, hoeveel records, welke categorieën), NIS2-significantiebeoordeling, 24-uurs vroege waarschuwing, inperking van ongeoorloofde toegang, AVG 72-uurs meldingsbeoordeling (parallel aan NIS2-rapportage), IOC-verzameling en 72-uurs NIS2-melding, beoordeling melding aan betrokkenen (AVG Artikel 34), forensisch onderzoek en bewijsbehoud, eindrapport na één maand voor NIS2 en coördinatie tussen NIS2 CSIRT-rapportage en AVG-melding bij de Autoriteit Persoonsgegevens."

  3. Genereer een DDoS-aanval-playbook:

    "Maak een DDoS incident response playbook voor onze [sector]-organisatie met NIS2-rapportage. Behandel: detectie (verkeersanomalieën, monitoring van gedegradeerde diensten), eerste beoordeling (volumetrische, protocol- of applicatielaag-aanval), NIS2-significantiebeoordeling (is de dienstverlening aan gebruikers/afhankelijke entiteiten getroffen?), 24-uurs vroege waarschuwing indien significant, activering van DDoS-mitigatie (upstream filtering, CDN, scrubbing services), voortdurende monitoring van de dienst, IOC-verzameling (bron-IP's, aanvalssignaturen, patronen), 72-uurs melding indien van toepassing, onderzoek of de DDoS een afleidingsmanoeuvre is voor een secundaire aanval, en analyse na het incident."

  4. Genereer een playbook voor supply chain compromise:

    "Maak een incident response playbook voor supply chain compromise met NIS2-rapportage. Behandel: detectie van inbreuk bij leverancier (melding leverancier, afwijkend gedrag van vertrouwde software/diensten), impactbeoordeling op onze systemen en data, NIS2-significantiebeoordeling (supply chain incidenten hebben vaak grensoverschrijdende gevolgen), 24-uurs vroege waarschuwing met beoordeling van grensoverschrijdende impact, inperking (isoleren getroffen leveranciersverbindingen, intrekken inloggegevens, blokkeren van gecompromitteerde updates), coördinatie met de getroffen leverancier, beoordeling van laterale verplaatsing (lateral movement), IOC-extractie en delen, 72-uurs melding, melding aan downstream entiteiten die wij bedienen, en eindrapport na één maand met lessen over de supply chain."

  5. Genereer sectorspecifieke playbooks:

    "Maak een [OT/ICS inbreuk | verstoring zorgsysteem | inbreuk financieel systeem | incident elektriciteitsnet] responsplaybook specifiek voor onze [sector] met geïntegreerde NIS2-rapportage. Behandel sectorspecifieke overwegingen zoals [veiligheidsimplicaties, impact op patiënten, stabiliteit financiële markt, continuïteit energievoorziening] en coördinatie met sectorspecifieke autoriteiten."

Tabletop-oefeningen: Gebruik na het genereren van uw playbooks ISMS Copilot om tabletop-scenario's te maken waarmee de bekwaamheid van uw team wordt getest om de playbooks te volgen en de NIS2-tijdlijnen te halen. Vraag: "Maak een tabletop-oefenscenario voor een [ransomware/datalek/supply chain] incident bij een [sector]-organisatie. Inclusief tijdlijn van incidenten (injects), verwachte acties in elke fase, NIS2-beslispunten voor rapportage en evaluatiecriteria."

Stap 6: Stel integratie met CSIRT en communicatiekanalen vast

Verbinding maken met uw nationale CSIRT

NIS2 vereist rapportage aan uw nationale CSIRT (Computer Security Incident Response Team) of de aangewezen bevoegde autoriteit. Elke EU-lidstaat heeft specifieke autoriteiten aangewezen en meldingsmechanismen opgezet.

  1. Identificeer uw rapporterende autoriteit:

    "Help me de bevoegde NIS2-autoriteit en het CSIRT voor [lidstaat] te identificeren. Geef: de officiële naam en contactinformatie, het rapportageportaal of de indieningsmethode, eventuele specifieke rapportformaten die vereist zijn door de omzettingswet van deze lidstaat, registratievereisten en eventuele sectorspecifieke rapportagekanalen die van toepassing kunnen zijn op onze [sector]."

  2. Maak de CSIRT-communicatieprocedure:

    "Maak een CSIRT-communicatieprocedure voor onze NIS2-incidentrapportage. Behandel: primaire en back-up indieningsmethoden (online portaal, e-mail, telefoon), beveiligde communicatiekanalen voor het delen van gevoelige IOC's, aangewezen CSIRT-liaisonpersonen (primair en back-up, met 24/7 dekking), escalatieprocedures als CSIRT-communicatiekanalen niet beschikbaar zijn, de omgang met adviezen en instructies van het CSIRT tijdens de incidentrespons, informatieclassificatie en -behandeling (wat mag gedeeld worden, TLP-markeringen) en coördinatie met het CSIRT bij incidenten die meerdere entiteiten treffen."

Ondersteuning van CSIRT: Uw nationale CSIRT is niet alleen een ontvanger van rapporten, maar ook een bron van hulp tijdens incidenten. CSIRT's kunnen technische bijstand verlenen, threat intelligence delen, coördineren met andere getroffen entiteiten en sectorspecifieke begeleiding bieden. Bouw de relatie op voordat u deze nodig hebt -- maak uw eerste contact niet pas tijdens een crisis.

Stap 7: Bouw procedures voor vrijwillige rapportage

Near-miss en dreigingsrapportage

NIS2 moedigt vrijwillige rapportage aan (maar stelt deze niet verplicht) voor near-misses, significante cyberdreigingen en informatie die kan helpen incidenten bij andere entiteiten te voorkomen. Het opzetten van vrijwillige rapportage toont volwassen security governance en bouwt goodwill op bij toezichthouders.

  1. Genereer een procedure voor vrijwillige rapportage:

    "Maak een procedure voor de vrijwillige rapportage van incidenten en dreigingen voor NIS2-compliance. Behandel: definitie van rapporteerbare near-misses (incidenten voorkomen door controles, gedetecteerde phishingcampagnes, geblokkeerde inbraakpogingen), definitie van rapporteerbare dreigingen (informatie over ophanden zijnde dreigingen voor onze sector, nieuw ontdekte kwetsbaarheden in veelgebruikte systemen), rapportageformaten voor vrijwillige meldingen (lichter dan verplichte rapporten, gericht op bruikbare informatie), intern proces voor het besluiten wanneer vrijwillige rapporten ingediend worden, anonimiserings-overwegingen waar van toepassing en voordelen van vrijwillige rapportage (relatie met CSIRT, informatiedeling binnen de sector)."

Stap 8: Implementeer rapportage-KPI's en continue verbetering

De effectiviteit van incidentrapportage meten

Artikel 21, lid 2, onder f, vereist een beoordeling van de effectiviteit van uw cyberbeveiligingsmaatregelen. Uw incidentrapportagefunctie moet regelmatig worden gemeten en verbeterd.

  1. Definieer rapportage-KPI's:

    "Maak een set KPI's om de effectiviteit van onze NIS2-incidentrapportagefunctie te meten. Inclusief: gemiddelde tijd tot detectie van significante incidenten, gemiddelde tijd van detectie tot indiening vroege waarschuwing, percentage vroege waarschuwingen ingediend binnen 24 uur, percentage meldingen ingediend binnen 72 uur, percentage eindrapporten ingediend binnen één maand, kwaliteitsscore voor volledigheid en nauwkeurigheid van rapporten, aantal incidenten correct geclassificeerd als significant vs. niet-significant, prestatiescores bij tabletop-oefeningen, tijd om CSIRT-communicatie op te zetten tijdens incidenten en frequentie van rapportage aan het bestuursorgaan over incidentstatistieken."

  2. Maak de procedure voor review na incidenten:

    "Maak een procedure voor een evaluatie na het incident (post-incident review) die specifiek onze NIS2-rapportageprestaties beoordeelt. Beoordeel na elk significant incident (en geselecteerde niet-significante incidenten): (1) was het incident correct geclassificeerd voor NIS2-significantie? (2) zijn alle rapportage-tijdlijnen gehaald? (3) was de inhoud van het rapport volledig en nauwkeurig? (4) was de communicatie met het CSIRT effectief? (5) zijn alle interne stakeholders op de juiste wijze geïnformeerd? (6) welke verbeteringen zijn nodig in onze detectie-, triage- of rapportageworkflows? Documenteer bevindingen en volg corrigerende acties op."

Rapportage aan het bestuursorgaan: Onder Artikel 20 moet het bestuursorgaan toezicht houden op de implementatie van cyberbeveiligingsmaatregelen. Dit omvat incidentrapportage. Stel een vaste regelmaat vast (minimaal elk kwartaal) voor het rapporteren van incidentstatistieken, significante incidenten en rapportageprestaties aan het bestuursorgaan. Leg deze briefings vast in de notulen van de bestuursvergadering.

Veelvoorkomende uitdagingen en oplossingen bij incidentrapportage

Uitdaging

Risico

Oplossing

Onduidelijke significantiecriteria

Te late rapportage of over-rapportage

Implementeer de classificatiematrix en beslisboom met sectorspecifieke voorbeelden

Geen dekking buiten kantooruren

Het missen van de 24-uurs deadline voor incidenten gedetecteerd buiten kantoortijden

Stel een 24/7 on-call rotatie in met de bevoegdheid om vroege waarschuwingen in te dienen

Tekortkomingen in IOC-verzameling

Onvolledige 72-uurs melding

Integreer IOC-verzameling in standaard forensische procedures; configureer verzamelingstools vooraf

Diepgang van oorzaakanalyse

Eindrapporten die niet voldoen aan de eisen van toezichthouders

Gebruik een gestructureerde RCA-methodologie; kijk verder dan de directe oorzaak naar systemische factoren

Coördinatie AVG/NIS2

Dubbele of tegenstrijdige meldingen aan verschillende autoriteiten

Maak een geünificeerde meldingsworkflow die zowel aan de NIS2- als AVG-vereisten voldoet

Falen van CSIRT-communicatie

Geen rapporten kunnen indienen tijdens een groot incident

Stel back-up communicatiekanalen in; test deze regelmatig

Juridische zorgen over openbaarmaking

Vertraagde rapportage door knelpunten in juridische toetsing

Keur rapportagesjablonen vooraf goed; betrek juridische zaken bij de ontwikkeling van playbooks, niet per incident

Volgende stappen

Nu uw incidentrapportagefunctie is opgezet, hebt u een van de meest tijdsgevoelige en kritische gebieden van NIS2-compliance aangepakt.

Ga verder met de volgende gids in deze serie:

  • Beveiliging van de toeleveringsketen: Zie Hoe u NIS2 supply chain-beveiliging beheert met behulp van AI voor het opbouwen van de risicobeoordelingsfunctie voor de toeleveringsketen die vereist is onder Artikel 21, lid 2, onder d -- inclusief hoe supply chain-incidenten doorstromen naar uw rapportageworkflows

Als u eerdere stappen nog niet hebt voltooid, zie dan:

  • Hoe te beginnen met NIS2-implementatie met behulp van AI voor scoping en governance-opzet

  • Hoe u een NIS2-risicobeoordeling uitvoert met behulp van AI voor de risicobeoordeling die uw incidentclassificatie onderbouwt

  • Hoe u NIS2-cyberbeveiligingsbeleid opstelt met behulp van AI voor het beleidskader dat uw incidentrespons regelt

Voor kant-en-klare prompts voor incidentrapportage kunt u de NIS2-richtlijn Promptbibliotheek verkennen. Voor een uitgebreid overzicht van alle NIS2-vereisten, zie de NIS2 Compliance-gids voor bedrijven binnen de reikwijdte.

Hulp krijgen

Voor extra ondersteuning bij NIS2-incidentrapportage:

  • Vraag het ISMS Copilot: Gebruik uw NIS2-workspace voor vragen over incidentrapportage, het aanpassen van sjablonen en de ontwikkeling van playbooks

  • Simuleer incidenten: Vraag ISMS Copilot om realistische incidentscenario's te genereren voor tabletop-oefeningen en teamtraining

  • Beoordeel rapporten: Upload concept-incidentrapporten en vraag om een controle op volledigheid ten opzichte van de vereisten van Artikel 23

  • Nationale vereisten: Vraag naar specifieke rapportageformaten, portalen of aanvullende vereisten opgelegd door de omzettingswet van uw lidstaat

Klaar om uw NIS2-incidentrapportagefunctie te bouwen? Open uw NIS2-workspace op chat.ismscopilot.com en begin met het genereren van uw incidentclassificatiematrix. Bouw van daaruit systematisch uw rapportagesjablonen en playbooks verder uit. Met ISMS Copilot kunt u een volledige, geteste workflow voor incidentrapportage ontwikkelen in dagen in plaats van maanden.

Was dit nuttig?