Hoe snel moet je een NIS2-incident melden?
Artikel 23 van NIS2 legt een meldingscadans in drie fasen op voor significante incidenten. U moet binnen 24 uur na het bekend worden van het incident een vroegtijdige waarschuwing indienen. Een gedetailleerde melding van het incident volgt binnen 72 uur. Een eindrapport, inclusief analyse van de hoofdoorzaak en herstelmaatregelen, moet binnen een maand worden ingediend. Als het 24-uursvenster niet wordt nageleefd, kan uw organisatie worden blootgesteld aan handhavingsmaatregelen, boetes en mogelijke persoonlijke aansprakelijkheid van bestuursleden.
NIS2 is de EU-richtlijn die cyberbeveiligingsverplichtingen oplegt aan organisaties in 18 sectoren, waaronder energie, gezondheidszorg, transport, productie en digitale diensten. In België is de wet van kracht sinds oktober 2024 en is deze van toepassing op entiteiten met 50 of meer werknemers of een jaarlijkse omzet van meer dan 10 miljoen euro. Van alle NIS2-vereisten heeft incidentrapportage de strakste deadlines en de meest directe operationele druk. Voor een volledig beeld van wat NIS2 betekent voor teams in het middensegment, zie ons NIS2-complianceoverzicht.
De 24-uurs vroegtijdige waarschuwing is de deadline die de meeste organisaties in het middensegment van de markt breekt. Niet omdat ze niet de wil hebben om te rapporteren, maar omdat ze niet de zichtbaarheid hebben om een incident snel genoeg te classificeren. Als je logbestanden verspreid zijn over vijf verschillende tools, kan alleen al het bevestigen of een gebeurtenis “significant” is het hele venster opslokken. Gecentraliseerde logging verandert die vergelijking. Met één enkel auditspoor dat toegangsevents, beleidsschendingen en beveiligingswaarschuwingen met elkaar in verband brengt, kunt u van detectie naar classificatie in minuten in plaats van uren.
Deze gids gaat in detail in op de drie rapportagefasen, legt uit wat er bij elke melding komt kijken, behandelt de Belgische, Nederlandse en Britse rapportageprocedures en biedt een stapsgewijze workflow voor het reageren op incidenten die u kunt aanpassen aan uw organisatie.
Wat NIS2 Artikel 23 vereist
Artikel 23 vervangt de vage formulering “zonder onnodige vertraging” uit de oorspronkelijke NIS-richtlijn door drie harde termijnen. Elke fase dient een ander doel en de informatie die in elke fase nodig is, is opzettelijk anders.
| Fase | Deadline | Doel | Wat in te sluiten |
|---|---|---|---|
| Vroegtijdige waarschuwing | 24 uur na bewustzijn | De autoriteit waarschuwen dat er iets aan de hand is | Bevestiging van een significant incident, vermoedelijke kwaadaardige oorzaak (ja/nee), potentiële grensoverschrijdende impact, eerste beheersingsmaatregelen |
| Melding incident | 72 uur na bewustzijn | Geef gevalideerde details voor gecoördineerde respons | Ernstbeoordeling, indicatoren van compromittering (IOC’s), aantal getroffen gebruikers, herstelstatus, sectorale impactanalyse |
| Eindrapport | 1 maand na de 72-uurs melding | Permanente verantwoording | Volledige oorzakenanalyse, chronologie van gebeurtenissen, permanente herstelmaatregelen, geleerde lessen |
De klok begint te lopen wanneer je organisatie zich “bewust wordt” dat het incident voldoet aan de criteria voor significantie. Niet wanneer de aanval begon. Niet wanneer u klaar bent met uw onderzoek. Op het moment dat je genoeg informatie hebt om de gebeurtenis als belangrijk te classificeren, gaat de 24-uursperiode in.
Als het incident na een maand nog niet is opgelost, dien je in plaats daarvan een voortgangsrapport in. Het eindrapport volgt dan binnen een maand nadat het is opgelost.
Een detail dat organisaties verrast: Artikel 23(5) vereist dat de ontvangende autoriteit waar mogelijk binnen 24 uur reageert op je vroegtijdige waarschuwing, inclusief een eerste advies over risicobeperking. Dit is geen eenrichtingsverkeer. Van de autoriteit wordt verwacht dat ze helpt, vooral als het incident grensoverschrijdende gevolgen heeft.
Wat telt als een belangrijk incident
Niet elk veiligheidsincident geeft aanleiding tot de meldingsplicht. Artikel 23, lid 3, definieert een significant incident als een incident dat voldoet aan een kwalitatieve of kwantitatieve drempel.
Operationele verstoring. Het incident heeft een ernstige verstoring veroorzaakt of kan een ernstige verstoring veroorzaken voor de diensten die je levert. Een ransomware-aanval die productiesystemen versleutelt, komt in aanmerking. Een mislukte phishingpoging die door uw filters is opgevangen niet.
Financieel verlies. Het incident heeft aanzienlijk financieel verlies veroorzaakt of kan dit veroorzaken. Directe kosten, herstelkosten, gederfde inkomsten en contractuele boetes tellen allemaal mee.
Schade aan derden. Het incident heeft gevolgen gehad of kan gevolgen hebben voor andere mensen of organisaties. Datalekken die persoonlijke informatie blootleggen, of verstoringen in de toeleveringsketen die doorwerken naar je klanten, vallen in deze categorie.
Kwaad opzet. Vermoedens van door de staat gesponsorde activiteiten, spionage of aanvallen met mogelijke grensoverschrijdende gevolgen krijgen prioriteit bij vroegtijdige waarschuwing.
De Uitvoeringsverordening 2024/2690 van de Europese Commissie voegt specifieke technische drempels toe voor leveranciers van digitale infrastructuur zoals clouddiensten, datacenters en DNS-operators. Voor de meeste organisaties in het middensegment van de markt is de praktische test eenvoudig: als het incident uw diensten verstoort, persoonlijke gegevens in gevaar brengt of zich naar andere organisaties kan verspreiden, is het significant en begint de klok te lopen.
Bouw uw interne classificatiematrix op rond deze vier criteria voordat er een incident plaatsvindt. Als er om 2 uur ’s nachts een waarschuwing afgaat, zou uw oproepingenieur geen regelgevende tekst hoeven te interpreteren. Ze hebben een beslisboom van één pagina nodig die hen vertelt: belangrijk of niet belangrijk, melden of bewaken. Platformen als Jimber vereenvoudigen deze stap omdat elke toegangsbeslissing, beleidsschending en beveiligingswaarschuwing al door één controlevlak stroomt. De technicus ziet de betrokken gebruiker, de status van het apparaat en de omvang van de gebeurtenis in één overzicht, in plaats van gegevens uit drie consoles op te vragen voordat een classificatie mogelijk is.
Waar te melden in België, Nederland en het Verenigd Koninkrijk
België
Het Centre for Cybersecurity Belgium (CCB) is de nationale autoriteit. Alle belangrijke NIS2-incidenten moeten worden gemeld via het Safeonweb@Work-portaal. CERT.be, de operationele tak van het CCB, zorgt voor de coördinatie van incidenten en kan technische bijstand verlenen tijdens actieve incidenten.
Het Belgische rapportageformulier vereist de classificatie van uw entiteit (essentieel of belangrijk), het type incident (ransomware, datalek, systeemcompromittering, enz.), de exacte datum en tijd van detectie, een beschrijving van hoe u het incident hebt gedetecteerd, een voorlopige impactbeoordeling, of er grensoverschrijdende effecten worden vermoed en een bevestiging of multifactorauthenticatie actief was op de getroffen systemen.
België was een van de eerste EU-lidstaten die NIS2 op 26 april 2024 in nationale wetgeving hebben omgezet. De meldingsplicht voor incidenten is actief sinds 18 oktober 2024. Dit is geen toekomstige verplichting. Het is nu van toepassing.
Voor organisaties die binnen het CyberFundamentals (CyFun)-raamwerk werken, is incidentrapportage direct gekoppeld aan de Respond-functie. CyFun-controle RS.CO (Communicatie) vereist een gedocumenteerd proces voor rapportage aan zowel intern management als externe autoriteiten, waaronder de CCB. De CyFun-zelfevaluatiegids behandelt deze controles in detail. Het CRACy-compliancehulpmiddel van Jimber brengt uw bestaande configuratie in kaart aan de hand van de Respond-controles en laat zien waar uw incidentrapportageprocedure al voldoet aan de CyFun-vereisten en waar er nog hiaten zijn.
Nederland
Het NCSC-NL (Nationaal Cyber Security Centrum) fungeert als het primaire CSIRT voor essentiële entiteiten. Nederland activeerde zijn Cyberbeveiligingswet in Q1 2026, waarmee NIS2 werd omgezet in Nederlandse wetgeving. Rapportage volgt dezelfde 24/72/1-maandelijkse cadans via het NCSC-portaal.
Verenigd Koninkrijk
Het Verenigd Koninkrijk werkt met zijn eigen NIS-verordeningen 2018 (zoals gewijzigd), die dateren van vóór NIS2 en qua toepassingsgebied verschillen. De Britse overheid heeft updates voorgesteld om beter aan te sluiten bij NIS2, maar het huidige kader maakt gebruik van sectorspecifieke bevoegde instanties in plaats van één nationaal portaal. Raadpleeg de toezichthouder van je sector voor de toepasselijke meldingsprocedure.
Hoe de 24-uurs deadline te halen
Dit is waar theorie en operationele realiteit elkaar ontmoeten. Het venster van 24 uur klinkt krap. Voor organisaties met gecentraliseerde zichtbaarheid is het volledig beheersbaar. Voor organisaties die nog steeds handmatig logs verzamelen van afzonderlijke firewalls, endpoint tools en cloudapplicaties is het bijna onmogelijk.
Het probleem is niet het schrijven van het rapport. De vroegtijdige waarschuwing is bewust licht: bevestig het incident, geef aan of het er kwaadaardig uitziet, noteer het grensoverschrijdende risico, beschrijf de eerste inperking. Je kunt dat formulier in 30 minuten invullen.
Het probleem is om het punt te bereiken waarop je met vertrouwen kunt zeggen “ja, dit is significant” binnen de eerste paar uur. Dat vereist het correleren van gegevens uit meerdere bronnen om te begrijpen wat er is gebeurd, wat er is getroffen en hoe ver het incident zich heeft verspreid.
Waarom verspreide houtkap de deadline niet haalt. Een typische mid-market opstelling heeft firewall logs in één console, endpoint alerts in een andere, cloud applicatie logs in een derde en VPN toegangsrecords ergens anders. Gegevens uit elk systeem halen, tijdstempels normaliseren en gebeurtenissen handmatig met elkaar vergelijken is een werk van vele uren, zelfs voordat je begint met analyseren. Uit onderzoek van IBM’s 2025 Cost of a Data Breach rapport blijkt dat het gemiddeld 186 dagen duurt om incidenten met gecompromitteerde referenties te identificeren. Zelfs teams die over voldoende middelen beschikken, kunnen de eerste triage zelden in minder dan 8 uur afronden als ze met losse tools werken.
Hoe gecentraliseerd loggen dit oplost. Wanneer alle toegangsbeslissingen, netwerkactiviteiten en beveiligingswaarschuwingen via één platform lopen, vindt correlatie automatisch plaats. Een afwijkende aanmelding vanaf een onbekende locatie, gevolgd door een zijwaartse beweging naar een bestandsserver, gevolgd door een poging tot data-exfiltratie, verschijnt als een samenhangende reeks in plaats van drie geïsoleerde waarschuwingen in drie afzonderlijke dashboards.
Jimber’s single management console correleert access events, policy violations en security alerts in één audit trail. Omdat al het verkeer door het SASE-controlevlak loopt, is het volledige aanvalspad zichtbaar vanuit één interface: het eerste toegangspunt, de zijwaartse beweging, de getroffen systemen en gegevens. Hierdoor kan uw beveiligingsverantwoordelijke binnen enkele minuten in plaats van uren bepalen of een incident aan de belangrijkheidsdrempel voldoet, waardoor de deadline van 24 uur verandert van een gevecht in een gestructureerd proces.
Hetzelfde controlespoor genereert het tijdstempelgetrouwe, onveranderlijke bewijs dat een maand later nodig is voor het eindrapport. Platforms zoals Jimber produceren versiegecontroleerde logboeken van elke toegangsbeslissing en beleidswijziging, die direct kunnen worden geëxporteerd naar het rapportageportaal van de CCB. Geen handmatige logboekaggregatie. Geen hiaten in het bewijs.
Praktische tip. Voer een oefening uit waarbij een ransomware-incident wordt gesimuleerd. Start de klok wanneer de eerste waarschuwing afgaat. Houd bij hoe lang uw team erover doet om de significantie te bevestigen met uw huidige hulpmiddelen. Als u niet binnen 4 uur tot een classificatiebesluit kunt komen, hebt u een zichtbaarheidsprobleem dat u met procesverbeteringen alleen niet kunt oplossen.
Uw procedure voor incidentenrapportage opstellen
Een gedocumenteerde procedure die je team onder druk kan volgen, is meer waard dan welk raamwerkschema dan ook. Hier is een stapsgewijze workflow, gestructureerd rond de rapportagefasen van NIS2.
Stap 1: Detecteren en triage (uur 0-2)
Uw monitoringsystemen signaleren een afwijking. De engineer controleert de waarschuwing aan de hand van je classificatiematrix. In een geconsolideerde SASE-omgeving zoals Jimber bevat die waarschuwing al de identiteit van de gebruiker, de status van het apparaat en de gebruikte bronnen, waardoor de engineer de context heeft om binnen enkele minuten in plaats van uren te classificeren. De belangrijkste vragen in dit stadium: wordt de beschikbaarheid van de service beïnvloed? Zijn persoonlijke gegevens mogelijk gecompromitteerd? Lijkt het incident kwaadaardig? Kan het andere organisaties beïnvloeden?
Als een antwoord “ja” of “waarschijnlijk ja” is, classificeer het dan als significant en start de 24-uursklok.
Stap 2: indammen en escaleren (uur 2-6)
Isoleer aangetaste systemen. Schakel gecompromitteerde accounts uit. Blokkeer schadelijke IP’s. Escaleer tegelijkertijd naar uw incident response lead en uw contactpersoon voor juridische zaken/compliance. De mensen die de vroegtijdige waarschuwing zullen geven, moeten het nu weten, niet pas om uur 22.
Stap 3: Dien de vroegtijdige waarschuwing in (uur 6-24)
Stel de 24-uurs melding op en dien deze in via het Safeonweb@Work-portaal (België), NCSC-portaal (Nederland) of uw sectorregulator (VK). Vermeld alleen wat u op dit moment weet. Het CCB geeft de voorkeur aan een eerlijke “onbekend” in een tijdige indiening boven een gedetailleerde melding die op uur 25 wordt ingediend.
Stap 4: Onderzoeken en bewijs verzamelen (uur 24-72)
Gebruik je gecentraliseerde logboeken om de tijdlijn van de aanval te reconstrueren. Identificeer compromitteringsindicatoren: IP-adressen, hashes van bestanden, uitgebuite kwetsbaarheden. Kwantificeer de impact: aantal getroffen gebruikers, systemen, gegevensrecords. Beoordeel of het incident gevolgen heeft voor de sector of de toeleveringsketen.
Stap 5: Dien de 72-uurs kennisgeving in (uur 48-72)
Deze update moet gevalideerde technische details bevatten. Ernstbeoordeling, IOC’s, genomen herstelmaatregelen en een analyse of het incident gevolgen heeft voor andere organisaties of sectoren. Als je ook een GDPR-kennisgevingsverplichting hebt (waarbij persoonsgegevens betrokken zijn), synchroniseer dan de 72-uurs inzendingen voor consistentie.
Stap 6: Analyse van de oorzaak en eindrapport (week 1-4)
Voer na indamming een autopsie uit. Identificeer de hoofdoorzaak, documenteer de volledige tijdlijn van het incident en beschrijf de permanente maatregelen die u neemt om herhaling te voorkomen. Dien het eindrapport binnen een maand in.
Wat u moet voorbereiden voordat er een incident plaatsvindt
Als je deze items klaar hebt voordat je ze nodig hebt, bespaar je uren tijdens een live incident:
- Vooraf ingevulde rapportagesjablonen met de CCB-registratiegegevens, sectorclassificatie en contactgegevens van je organisatie
- Een classificatiematrix die incidenttypen koppelt aan NIS2-belangrijkheidscriteria
- Een escalatiematrix met namen, rollen en contactgegevens voor de 24-uurs, 72-uurs en eindrapporten
- Een communicatieplan voor interne kennisgeving (bestuur, juridische zaken, PR) en externe kennisgeving (CCB, DPA, betrokken derden)
- Bewijs van regelmatig testen: verslagen van tafeloefeningen, simulatieresultaten, data voor procedure-evaluaties
Je NIS2-checklist voor naleving omvat de bredere auditvoorbereiding, inclusief de controles voor incidentrapportage die conformiteitsbeoordelingsinstanties gedocumenteerd willen zien.
NIS2 vs GDPR vs DORA-rapportage: wanneer overlappen ze elkaar?
Een enkel cyberincident kan leiden tot rapportageverplichtingen onder meerdere regelgevingen tegelijk. Dit is geen theoretisch randgeval. Een ransomware-aanval op een ziekenhuis waarbij patiëntendossiers worden versleuteld, leidt tot NIS2 (onderbreking van de dienstverlening), GDPR (inbreuk op persoonsgegevens) en mogelijk tot sectorspecifieke gezondheidsregelgeving. De Belgische ransomware-aanval op ziekenhuizen eerder dit jaar illustreerde precies deze overlapping.
| Aspect | NIS2 | GDPR | DORA |
|---|---|---|---|
| Focus | Beschikbaarheid en integriteit van de service | Vertrouwelijkheid van persoonlijke gegevens | ICT operationele veerkracht (financiële sector) |
| Tijdslijn | 24 uur vroegtijdige waarschuwing, 72 uur kennisgeving, 1 maand definitief | 72 uur melding aan DPA | Verschilt per ernst incident; voor grote ICT-incidenten gelden specifieke tijdlijnen |
| Autoriteit | Nationaal CSIRT / CCB (België) | Gegevensbeschermingsautoriteit | Financiële toezichthouder (NBB/FSMA in België, DNB in NL) |
| Toepassingsgebied | Essentiële en belangrijke entiteiten in 18 sectoren | Elke organisatie die persoonsgegevens verwerkt | Financiële entiteiten en hun kritische ICT-providers |
| Relatie | Algemeen kader | Loopt parallel; aparte melding | Lex specialis voor financiële sector; gaat boven NIS2 voor ICT-incidenten |
Voor financiële dienstverleners heeft DORA over het algemeen voorrang op NIS2 als lex specialis. Maar Belgische en Nederlandse regelgevers hebben bevestigd dat er een dubbele meldingsplicht kan bestaan voor incidenten die zowel de veerkracht van ICT als de algemene netwerkbeveiliging beïnvloeden. Als je actief bent in de financiële dienstverlening, worden de vereisten voor de financiële sector uitgebreid behandeld in het DORA-informatieregister en de SASE voor financiële diensten onder DORA-gidsen.
De praktische oplossing: houd één incidentenregister bij waarin alle meldingen voor alle toepasselijke regels worden bijgehouden. Geef elke melding een tijdstempel. Zorg ervoor dat de feiten die u rapporteert aan de CCB, de DPA en uw financiële toezichthouder consistent zijn. Inconsistenties tussen parallelle meldingen creëren juridische risico’s die volledig te vermijden zijn. Een SASE-platform zoals Jimber genereert dezelfde gebeurtenislogs met tijdstempel voor alle drie de rapportagestromen vanuit één auditspoor, zodat de feiten in je NIS2-waarschuwing, je GDPR-kennisgeving en je DORA-rapport altijd op elkaar zijn afgestemd.
FAQ
Hoe lang heb je de tijd om een NIS2-incident te melden?
Je moet een vroegtijdige waarschuwing indienen binnen 24 uur nadat je weet dat er een belangrijk incident heeft plaatsgevonden. Een gedetailleerde incidentmelding volgt binnen 72 uur. Een eindrapport met analyse van de hoofdoorzaak moet binnen een maand worden ingediend. Als het incident na een maand nog niet is opgelost, dient u een voortgangsrapport in en dient u het eindrapport binnen een maand in.
Wat gebeurt er als je de deadline van 24 uur mist?
Als u uw nationale autoriteit niet binnen de vereiste termijnen op de hoogte brengt, kan dit leiden tot administratieve boetes. Voor essentiële entiteiten in België kunnen de boetes oplopen tot 10 miljoen euro of 2% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Voor belangrijke entiteiten is de bovengrens EUR 7 miljoen of 1,4% van de omzet. Naast boetes kan het CCB certificeringen opschorten, niet-naleving openbaar maken en in geval van herhaalde nalatigheid bestuursfuncties tijdelijk beperken. NIS2 Bestuurdersaansprakelijkheid in België dekt de persoonlijke aansprakelijkheid van bestuurders en leidinggevenden.
Overlapt de NIS2-incidentrapportage de GDPR?
Ja. Als er bij een cyberincident persoonsgegevens betrokken zijn, moet u mogelijk zowel uw nationale CSIRT (onder NIS2) als uw gegevensbeschermingsautoriteit (onder GDPR) binnen 72 uur op de hoogte stellen. De twee meldingen dienen verschillende doelen: NIS2 richt zich op servicecontinuïteit terwijl GDPR zich richt op gegevensbescherming. Bereid beide meldingen parallel voor en zorg ervoor dat de gemelde feiten consistent zijn.
Wie is verantwoordelijk voor NIS2-rapportage in België?
Het Centrum voor Cyberbeveiliging België (CCB) is de bevoegde autoriteit. Alle belangrijke incidenten moeten worden gemeld via het Safeonweb@Work-portaal. CERT.be zorgt voor de operationele coördinatie van incidenten. De verantwoordelijkheid voor het tijdig melden ligt bij het bestuursorgaan van de organisatie. Volgens de Belgische wet kunnen bestuursleden die geen toezicht houden op de implementatie van cyberbeveiliging persoonlijk aansprakelijk worden gesteld.
Welke hulpmiddelen helpen om de deadline van 24 uur te halen?
Het 24-uurs venster vereist een snelle incidentclassificatie, die afhankelijk is van gecentraliseerde zichtbaarheid over je netwerk, endpoints en cloud-applicaties. Een SASE-platform zoals Jimber consolideert alle toegangslogs, beleidsevents en beveiligingswaarschuwingen in één auditspoor, waardoor de tijd om te classificeren wordt teruggebracht van uren tot minuten. SIEM-tools kunnen een vergelijkbare correlatiefunctie vervullen, maar organisaties in het middensegment vinden vaak dat een uniform SASE-platform zowel de beveiligingscontroles als de zichtbaarheid van de logging biedt zonder de complexiteit van een standalone SIEM-implementatie.
Moeten Belgische organisaties CyFun volgen voor het melden van incidenten?
CyFun is het implementatiekader van het CCB voor NIS2 in België. De responsfunctie (controleert RS.RP, RS.CO, RS.AN, RS.MI) stemt rechtstreeks overeen met de rapporteringsvereisten van artikel 23. Essentiële entiteiten moeten ten minste Basic of Important CyFun-verificatie bereiken tegen 18 april 2026. Zelfs als uw organisatie is geclassificeerd als belangrijk in plaats van essentieel, biedt het implementeren van de Respond-controles een gestructureerde, controleerbare benadering van incidentrapportage die voldoet aan zowel de NIS2- als de CyFun-vereisten.
De deadline van 24 uur voor rapportage beloont voorbereiding, geen improvisatie. Organisaties met gecentraliseerde logging en een kant-en-klare rapportageprocedure kunnen deze deadline gemakkelijk halen. Organisaties die nog steeds met losse tools werken, hebben het elke keer moeilijk. Het SASE-platform van Jimber biedt een eenduidig controlespoor, realtime waarschuwingen en onveranderlijke gebeurtenislogboeken die NIS2-incidentrapportage veranderen van een regelkluwen in een gedocumenteerd, herhaalbaar proces. Boek een demo om te zien hoe geconsolideerde zichtbaarheid het 24-uursvenster beheersbaar maakt voor je team.