{"id":12944,"date":"2026-04-17T09:00:57","date_gmt":"2026-04-17T07:00:57","guid":{"rendered":"https:\/\/jimber.io\/?p=12944"},"modified":"2026-04-17T09:00:57","modified_gmt":"2026-04-17T07:00:57","slug":"nis2-incidentrapportage-tijdlijnen-sjablonen-en-praktische-stappen","status":"publish","type":"post","link":"https:\/\/jimber.io\/nl\/blog\/nis2-incidentrapportage-tijdlijnen-sjablonen-en-praktische-stappen\/","title":{"rendered":"NIS2-incidentrapportage: tijdlijnen, sjablonen en praktische stappen"},"content":{"rendered":"

Hoe snel moet je een NIS2-incident melden?<\/h2>\n

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. <\/p>\n

\n

NIS2 is de EU-richtlijn die cyberbeveiligingsverplichtingen oplegt aan organisaties in 18 sectoren, waaronder energie, gezondheidszorg, transport, productie en digitale diensten. In Belgi\u00eb 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<\/a>. <\/p>\n<\/div>\n

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 \u00e9\u00e9n enkel auditspoor dat toegangsevents, beleidsschendingen en beveiligingswaarschuwingen met elkaar in verband brengt, kunt u van detectie naar classificatie in minuten in plaats van uren. <\/p>\n

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.<\/p>\n

Wat NIS2 Artikel 23 vereist<\/h2>\n

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. <\/p>\n

\n\n\n\n\n\n\n\n
Fase<\/th>\nDeadline<\/th>\nDoel<\/th>\nWat in te sluiten<\/th>\n<\/tr>\n<\/thead>\n
Vroegtijdige waarschuwing<\/td>\n24 uur na bewustzijn<\/td>\nDe autoriteit waarschuwen dat er iets aan de hand is<\/td>\nBevestiging van een significant incident, vermoedelijke kwaadaardige oorzaak (ja\/nee), potenti\u00eble grensoverschrijdende impact, eerste beheersingsmaatregelen<\/td>\n<\/tr>\n
Melding incident<\/td>\n72 uur na bewustzijn<\/td>\nGeef gevalideerde details voor geco\u00f6rdineerde respons<\/td>\nErnstbeoordeling, indicatoren van compromittering (IOC’s), aantal getroffen gebruikers, herstelstatus, sectorale impactanalyse<\/td>\n<\/tr>\n
Eindrapport<\/td>\n1 maand na de 72-uurs melding<\/td>\nPermanente verantwoording<\/td>\nVolledige oorzakenanalyse, chronologie van gebeurtenissen, permanente herstelmaatregelen, geleerde lessen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

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. <\/p>\n

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. <\/p>\n

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. <\/p>\n

Wat telt als een belangrijk incident<\/h2>\n

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. <\/p>\n

Operationele verstoring.<\/strong> 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. <\/p>\n

Financieel verlies.<\/strong> Het incident heeft aanzienlijk financieel verlies veroorzaakt of kan dit veroorzaken. Directe kosten, herstelkosten, gederfde inkomsten en contractuele boetes tellen allemaal mee. <\/p>\n

Schade aan derden.<\/strong> 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. <\/p>\n

Kwaad opzet.<\/strong> Vermoedens van door de staat gesponsorde activiteiten, spionage of aanvallen met mogelijke grensoverschrijdende gevolgen krijgen prioriteit bij vroegtijdige waarschuwing.<\/p>\n

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. <\/p>\n

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 \u00e9\u00e9n 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 \u00e9\u00e9n controlevlak stroomt. De technicus ziet de betrokken gebruiker, de status van het apparaat en de omvang van de gebeurtenis in \u00e9\u00e9n overzicht, in plaats van gegevens uit drie consoles op te vragen voordat een classificatie mogelijk is. <\/p>\n

Waar te melden in Belgi\u00eb, Nederland en het Verenigd Koninkrijk<\/h2>\n

Belgi\u00eb<\/h3>\n

Het Centre for Cybersecurity Belgium (CCB) is de nationale autoriteit. Alle belangrijke NIS2-incidenten moeten worden gemeld via het Safeonweb@Work-portaal<\/a>. CERT.be, de operationele tak van het CCB, zorgt voor de co\u00f6rdinatie van incidenten en kan technische bijstand verlenen tijdens actieve incidenten. <\/p>\n

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.<\/p>\n

Belgi\u00eb 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. <\/p>\n

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<\/a> behandelt deze controles in detail. Het CRACy-compliancehulpmiddel<\/a> 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. <\/p>\n

Nederland<\/h3>\n

Het NCSC-NL (Nationaal Cyber Security Centrum) fungeert als het primaire CSIRT voor essenti\u00eble 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. <\/p>\n

Verenigd Koninkrijk<\/h3>\n

Het Verenigd Koninkrijk werkt met zijn eigen NIS-verordeningen 2018 (zoals gewijzigd), die dateren van v\u00f3\u00f3r 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 \u00e9\u00e9n nationaal portaal. Raadpleeg de toezichthouder van je sector voor de toepasselijke meldingsprocedure. <\/p>\n

Hoe de 24-uurs deadline te halen<\/h2>\n

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. <\/p>\n

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. <\/p>\n

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. <\/p>\n

Waarom verspreide houtkap de deadline niet haalt.<\/strong> Een typische mid-market opstelling heeft firewall logs in \u00e9\u00e9n 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. <\/p>\n

Hoe gecentraliseerd loggen dit oplost.<\/strong> Wanneer alle toegangsbeslissingen, netwerkactiviteiten en beveiligingswaarschuwingen via \u00e9\u00e9n 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\u00efsoleerde waarschuwingen in drie afzonderlijke dashboards. <\/p>\n

Jimber’s single management console correleert access events, policy violations en security alerts in \u00e9\u00e9n audit trail. Omdat al het verkeer door het SASE-controlevlak loopt, is het volledige aanvalspad zichtbaar vanuit \u00e9\u00e9n 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. <\/p>\n

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\u00ebxporteerd naar het rapportageportaal van de CCB. Geen handmatige logboekaggregatie. Geen hiaten in het bewijs. <\/p>\n

Praktische tip.<\/strong> 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. <\/p>\n

Uw procedure voor incidentenrapportage opstellen<\/h2>\n

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. <\/p>\n

Stap 1: Detecteren en triage (uur 0-2)<\/h3>\n

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\u00efnvloed? Zijn persoonlijke gegevens mogelijk gecompromitteerd? Lijkt het incident kwaadaardig? Kan het andere organisaties be\u00efnvloeden? <\/p>\n

Als een antwoord “ja” of “waarschijnlijk ja” is, classificeer het dan als significant en start de 24-uursklok.<\/p>\n

Stap 2: indammen en escaleren (uur 2-6)<\/h3>\n

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. <\/p>\n

Stap 3: Dien de vroegtijdige waarschuwing in (uur 6-24)<\/h3>\n

Stel de 24-uurs melding op en dien deze in via het Safeonweb@Work-portaal (Belgi\u00eb), 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. <\/p>\n

Stap 4: Onderzoeken en bewijs verzamelen (uur 24-72)<\/h3>\n

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. <\/p>\n

Stap 5: Dien de 72-uurs kennisgeving in (uur 48-72)<\/h3>\n

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. <\/p>\n

Stap 6: Analyse van de oorzaak en eindrapport (week 1-4)<\/h3>\n

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. <\/p>\n

Wat u moet voorbereiden voordat er een incident plaatsvindt<\/h3>\n

Als je deze items klaar hebt voordat je ze nodig hebt, bespaar je uren tijdens een live incident:<\/p>\n