NIS2 meldplicht bij incidenten: wat is een significant incident en hoe richt je je incidentresponse in?

Onder NIS2 ben je verplicht om significante incidenten binnen 24 uur te melden. Een incident is significant als het leidt tot verstoring van essentiële diensten, financiële schade veroorzaakt of impact heeft op derden, ook als die schade nog niet is opgetreden. Een solide incidentresponsproces begint met proactieve detectie, objectieve impactbeoordeling (bijv. via BIV-classificatie) en heldere verantwoordelijkheden. Zo voldoe je aan de meldplicht én vergroot je je digitale weerbaarheid.

Wat lees je in dit artikel?

Onder de NIS2-richtlijn zijn organisaties verplicht om significante incidenten binnen 24 uur te melden bij het nationale CSIRT of de bevoegde autoriteit. De meldplicht is van toepassing op zowel essentiële als belangrijke entiteiten, maar geldt ook als incidenten ontstaan bij leveranciers die cruciale diensten leveren.

Een incident wordt als significant beschouwd als het:

De impact hoeft dus nog niet te zijn gerealiseerd: potentiële schade telt ook mee. De definitie uit Artikel 23, lid 3, van de richtlijn is bewust breed.

De definitie geeft ruimte voor interpretatie; de richtlijn geeft immers geen harde drempelwaarden. Om die reden is het van belang om met behulp van objectieve criteria, zoals een BIV-classificatie of impactmodel, te onderbouwen of de impact daadwerkelijk ‘significant’ is voor de organisatie.

Bron: Eur-lex.europa.eu

In tegenstelling tot de AVG, die zich beperkt tot incidenten met persoonsgegevens, kijkt NIS2 veel breder. Elke verstoring van de beschikbaarheid, integriteit of vertrouwelijkheid (BIV) van netwerken, informatiesystemen of diensten kan een meldingswaardig incident zijn. Denk aan:

Belangrijk is: NIS2 kijkt niet of er schade ís, maar of er schade kan ontstaan. Dat kan zijn voor klanten, de samenleving of andere partijen in je keten. De lat ligt dus lager dan je misschien gewend bent.

NIS2 verwacht niet alleen dat je reageert op incidenten, maar ook dat je ze vroegtijdig detecteert. Dat betekent dat digitale monitoring van je netwerk en systemen niet optioneel is, het is verplicht. Organisaties moeten:

Waar organisaties nu vaak nog reactief handelen (“iemand meldt een probleem”), vereist NIS2 een verandering naar proactieve signalering. Dit geldt ook voor ketenincidenten: als jouw leverancier uitvalt, moet jij weten wat de impact is en dat betekent dat je afhankelijkheden scherp moet hebben én structureel moet volgen.

De richtlijn stelt drie duidelijke rapportagemomenten bij significante incidenten:

De klok begint te lopen vanaf het moment van ontdekking, niet vanaf het moment dat je alles zeker weet.

Dit betekent dat je vooraf dient te hebben bepaald:

Twijfel je? Dan kun je ook vrijwillig melden, wat positief wordt gewaardeerd door toezichthouders.

Bij welke autoriteit moet je een melding maken? Dat is afhankelijk van de sector waarin je actief bent. Hieronder een kort overzicht van de autoriteiten en de sectoren per autoriteit.

Veel organisaties hanteren al een classificatiemodel voor hun informatie en systemen op basis van Beschikbaarheid, Integriteit en Vertrouwelijkheid (BIV). Dat model wordt vaak gebruikt om passende maatregelen te kiezen. De BIV-classificatie is echter ook een krachtig instrument om te bepalen of een incident significant is.

Door deze drie invalshoeken te combineren met de ernst en duur van het incident, kan onderbouwd worden of de drempel van “significant” wordt overschreden.

Een bijkomend voordeel: organisaties die hun systemen en processen al hebben geclassificeerd volgens BIV, hebben hiermee automatisch een risicoprofiel in handen. Dat profiel kun je uitbreiden met incidentdrempels en meldcriteria, zonder een compleet nieuw beoordelingsmodel te hoeven invoeren.

Om BIV effectief in te zetten bij incidentbeoordeling, dien je vooraf per systeem of proces:

Een voorbeeld:

De meldplicht volgt niet automatisch uit bovengenoemde, maar uit het geheel van de impact op de bedrijfsvoering en afhankelijkheden. Combineer BIV-classificatie bij NIS2 met aanvullende factoren als duur van de verstoring, de schaal van het incident, het aantal betrokken gebruikers en de aanwezigheid van ketenafhankelijkheden.

Combineer dit met controlevragen als:

Antwoord je op twee of meer vragen met “ja”? Dan is melden waarschijnlijk verstandig. Let wel op: de toetsing moet reproduceerbaar zijn. Als er later een audit of toezichtvraag komt, moet je kunnen aantonen dat je objectieve criteria hebt gebruikt.

NIS2 maakt incidentrespons een onderdeel van de bestuurlijke verantwoordelijkheid van organisaties. Het is dus niet voldoende dat IT “ergens” een incidentprocedure heeft.

De organisatie als geheel moet:

Voor organisaties die onder NIS2 vallen, betekent dit ook dat incidentrapportages onderdeel kunnen worden van toezicht of handhaving. Je moet dus kunnen aantonen hoe je hebt gehandeld, wie welke keuzes heeft gemaakt, en op basis van welke informatie.

Een effectief incidentresponsproces onder NIS2 bestaat uit deze stappen:

Zorg dat je intern hebt vastgelegd wie verantwoordelijk is voor de beoordeling en communicatie van incidenten.

Onder NIS2 ben je óók verantwoordelijk voor incidenten bij leveranciers als die jouw dienstverlening raken. Je moet daarom:

Een goede documentatie is cruciaal. Leg per incident vast:

Deze informatie is verplicht in je eindrapportage, maar helpt je ook bijinterne auditsen toezicht. Ook wanneer je besluit om het incident niet te melden, moet je het besluit onderbouwen en vastleggen. Het is daarom aan te raden om deze beoordeling gestructureerd vast te leggen in je ISMS of incidentlogboek. Gebruik een sjabloon of incidentbeoordelingsformulier waarmee je consequent werkt.

Sommige incidenten kunnen ook meld plichtig zijn onder andere wetgevingen, zoals de AVG of sectorale toezichtkaders (bijvoorbeeld de Wet beveiliging netwerk- en informatiesystemen voor aanbieders van essentiële diensten). Gebruik daarom altijd een multidisciplinaire toetsing bij twijfel, met input van de juridische, beveiliging en naleving (compliance) afdelingen.

BIV-classificatie kan ook daar waardevol zijn: als het incident een systeem raakt met vertrouwelijke persoonsgegevens (V=Hoog), moet je mogelijk ook melding doen bij de Autoriteit Persoonsgegevens. Onder NIS2 is beschikbaarheid echter een even belangrijk criterium, dus de BIV-methode biedt hier brede toepasbaarheid.

Scenario 1: Ransomware legt een productiesysteem stil
Het systeem is essentieel voor de levering van diensten (B: Hoog), en de verwachte uitval duurt langer dan 4 uur.
Melding vereist

Scenario 2: Logging-gegevens met gebruikersnamen per ongeluk gepubliceerd
Geen persoonsgegevens, geen impact op dienstverlening. BIV: Laag voor Vertrouwelijkheid.
Waarschijnlijk geen melding nodig.

Scenario 3: Fout in softwareconfiguratie zorgt voor verkeerde facturatie
Integriteitsinbreuk op kritische systemen, fout ontdekt na verzending.
Afhankelijk van schadeomvang: mogelijk meld plichtig.

Scenario 4: Incident bij leverancier waardoor SaaS-platform tijdelijk uitvalt
Ketenafhankelijkheid, maar intern geen concrete schade. Wel risico op verstoring.
Afhankelijk van klantimpact en duur van uitval.

Scenario 5: Extern beveiligingslek zonder datadiefstal
Systemen kwetsbaar gebleken, maar geen aanwijzingen van misbruik.
Wel meld plichtig als de kwetsbaarheid significante risico’s veroorzaakt.

NIS2 vraagt niet om perfectie, maar om aantoonbare beheersing. Begin daarom met:

De meldplicht onder NIS2 vraagt meer dan een reactieve houding. Het vereist:

Door te werken met een BIV-classificatie met concrete drempelwaarden, een solide incidentresponsplan en duidelijke interne rollen en processen, voldoe je niet alleen aan de NIS2, maar vergroot je ook je weerbaarheid én vertrouwen bij klanten en toezichthouders. En bovenal: je bent voorbereid, want 24 uur is erg kort…

Wil je incidentmanagement opzetten in het kader van NIS2 of juist weten hoe je dit integreert in je ISMS of incidentresponseplan? Neem gerust contact op. We denken graag met je mee!