Wat Is Een Significant Incident Volgens NIS2?
Wanneer is er sprake van een significant incident volgens NIS2? De criteria, voorbeelden van incidenten die wel en niet meldplichtig zijn, en hoe u zelf een werkbare drempelwaarde vastlegt.

Een medewerker meldt op vrijdagmiddag dat een bestandsserver traag is. Twee uur later blijkt een deel van de bestanden versleuteld. Is dat een significant incident volgens NIS2, of een storing die u gewoon oplost? Van dat antwoord hangt af of er binnen 24 uur een melding de deur uit moet.
Die vraag komt bij vrijwel elk incident terug. De Cyberbeveiligingswet, de Nederlandse omzetting van NIS2, geldt vanaf 15 augustus 2026 en verplicht organisaties alleen significante incidenten te melden. De wet geeft criteria, maar geen kant-en-klare grens. Die grens legt u zelf vast, zodat uw mensen niet hoeven te twijfelen op het moment dat het telt.
Wanneer is een incident significant volgens NIS2?
NIS2 werkt met twee criteria. Het eerste kijkt naar uw eigen dienstverlening: veroorzaakt het incident een ernstige operationele verstoring of aanzienlijk financieel verlies, of kan het dat veroorzaken. Het tweede kijkt naar de buitenwereld: brengt het incident aanzienlijke materiële of immateriële schade toe aan andere personen of organisaties.
Twee dingen vallen op. Het woord “kan” betekent dat ook een incident zonder daadwerkelijke schade meldplichtig kan zijn. En het tweede criterium betekent dat u verder kijkt dan uw eigen muren: schade bij klanten of ketenpartners telt mee. Meer over de begrippen in dit domein leest u in de NIS2 begrippenlijst.
Welke factoren wegen mee in de beoordeling?
De criteria zijn kwalitatief. Om ze bruikbaar te maken vertaalt u ze naar factoren die u wel kunt meten. In de praktijk kijkt u naar de volgende punten.
- Duur van de verstoring. Hoe lang is een dienst geheel of gedeeltelijk onbeschikbaar geweest, of hoe lang zal dat naar verwachting duren.
- Aantal geraakte afnemers. Hoeveel klanten, patiënten, aangeslotenen of burgers merken iets van de verstoring.
- Geografische reikwijdte. Betreft het één locatie, heel Nederland of ook andere lidstaten.
- Kritiek karakter van de dienst. Raakt het een dienst waar anderen direct van afhankelijk zijn, zoals zorg, energie of betalingsverkeer.
- Aard van de dreiging. Gaat het om een kwaadwillige handeling, en is er sprake van datadiefstal, versleuteling of ongeautoriseerde toegang.
Welke incidenten zijn wel en niet meldplichtig?
De tabel hieronder geeft voorbeelden. Ze zijn bedoeld als richting, niet als regel: hetzelfde incident kan bij een ziekenhuis wel en bij een kantoororganisatie niet significant zijn.
| Situatie | Beoordeling | Waarom |
|---|---|---|
| Ransomware versleutelt productiesystemen, dienst ligt een dag stil | Meldplichtig | Ernstige operationele verstoring en kwaadwillige handeling |
| Aanvaller had toegang tot een beheeraccount, u ontdekt het voordat er schade is | Meldplichtig | Het incident had ernstige gevolgen kunnen hebben |
| DDoS-aanval maakt uw klantportaal enkele uren onbereikbaar | Meldplichtig | Afnemers ondervinden directe hinder van een gerichte aanval |
| Gegevens van klanten liggen op straat na een inbraak in een applicatie | Meldplichtig | Aanzienlijke schade bij anderen, vaak ook een datalek onder de AVG |
| Eén laptop raakt besmet, direct geïsoleerd, geen verspreiding | Meestal niet | Geen verstoring van de dienst en geen schade bij derden |
| Phishingmail wordt door het filter tegengehouden | Niet | Poging zonder gevolg, wel registreren in uw incidentregister |
| Geplande storing tijdens onderhoud in het onderhoudsvenster | Niet | Geen incident maar een aangekondigde onderbreking |
Let op de tweede rij. Veel organisaties gaan ervan uit dat een incident zonder schade niet gemeld hoeft te worden. Het criterium “kan veroorzaken” maakt dat anders. Zie ook de uitleg in het artikel over de meldplicht binnen NIS2.
Hoe legt u een drempelwaarde vast in uw meldprocedure?
Een medewerker die om twee uur ’s nachts een storing ziet, moet niet hoeven interpreteren wat “ernstige operationele verstoring” betekent. Vertaal het criterium daarom vooraf naar concrete grenzen die passen bij uw organisatie en uw diensten.
Kies bijvoorbeeld een maximale onbeschikbaarheidsduur per dienst, een aantal geraakte afnemers en een categorie systemen waarbij altijd wordt opgeschaald. Onderbouw die keuzes met uw risicoanalyse, want dan kunt u aan de toezichthouder uitleggen waarom uw grens ligt waar hij ligt. Die koppeling met de zorgplicht en uw risicoanalyse is precies wat een drempelwaarde verdedigbaar maakt.
Leg de drempel vast in de incidentprocedure zelf, niet in een apart beleidsstuk. Voeg een korte beslisboom toe van vijf vragen die eindigt in “melden” of “registreren en afhandelen”. Het NIS2 compliance pakket bevat zo’n drempeltoets, en de bijbehorende formulieren staan in de 176 NIS2 document templates.
Wie beoordeelt of een incident significant is?
Beleg de beoordeling bij een rol, niet bij een persoon die er toevallig is. In de praktijk werkt een tweetrapsmodel goed: de dienstdoende medewerker doet de drempeltoets, en bij een positief signaal schakelt hij direct de meldverantwoordelijke in die het besluit neemt.
Geef die meldverantwoordelijke vooraf mandaat van het bestuur om te melden. Zonder mandaat ontstaat er overleg, en overleg kost uren die u niet hebt binnen de meldtermijn van 24 uur.
Wat doet u bij twijfel?
Melden. Een melding die achteraf niet nodig blijkt kost u een formulier en een half uur. Een gemiste melding is een overtreding van de wet die u niet meer kunt herstellen, ook niet als u het incident verder vlekkeloos hebt afgehandeld.
Registreer bij elk incident ook de beoordeling zelf, dus waarom u wel of niet hebt gemeld. Dat register laat aan de toezichthouder zien dat u de afweging structureel maakt. Betreft het incident persoonsgegevens, denk dan ook aan het aparte spoor uit de AVG naast NIS2.
Veelgestelde vragen over het significante incident
1. Wat is een significant incident volgens NIS2?
Een incident dat een ernstige verstoring van uw dienstverlening of financieel verlies veroorzaakt of kan veroorzaken, of dat aanzienlijke materiële of immateriële schade toebrengt aan anderen. Beide criteria kijken ook naar mogelijke gevolgen, dus een incident zonder daadwerkelijke schade kan toch meldplichtig zijn.
2. Is een geslaagde phishingaanval altijd meldplichtig?
Niet automatisch. Bepalend is wat er daarna gebeurde. Kreeg de aanvaller toegang tot systemen of gegevens, of had hij dat kunnen krijgen, dan is de kans groot dat het incident significant is. Bleef het bij een onderschepte mail zonder gevolg, dan registreert u het en meldt u niet.
3. Moet ik een incident melden dat door een leverancier is veroorzaakt?
Ja, als het uw dienstverlening significant raakt. De meldplicht hoort bij de organisatie die de dienst levert, niet bij degene die de storing veroorzaakte. Leg daarom in uw contracten vast dat leveranciers u onmiddellijk informeren, anders haalt u de termijn van 24 uur niet.
4. Wie bepaalt de drempelwaarde voor significantie?
U legt de drempel zelf vast in uw meldprocedure, onderbouwd met uw risicoanalyse en passend bij uw sector en diensten. De wet geeft de criteria, u vertaalt die naar meetbare grenzen zoals duur van de uitval en aantal geraakte afnemers.
5. Telt een bijna-incident ook mee?
Als het incident ernstige gevolgen had kunnen hebben, valt het onder het criterium en meldt u het. Een aanvaller die toegang had tot een beheeromgeving maar op tijd is gestopt, is daarvan het duidelijkste voorbeeld. Pogingen zonder toegang registreert u wel, maar meldt u niet.
Conclusie
De criteria voor een significant incident zijn open geformuleerd, en dat is voor een wet logisch. Voor uw organisatie is het onwerkbaar. Vertaal de criteria daarom vooraf naar concrete grenzen, leg ze vast in uw incidentprocedure en onderbouw ze met uw risicoanalyse. Dan hoeft niemand tijdens een incident nog te interpreteren.
Zorg dat die drempel staat voordat de Cyberbeveiligingswet vanaf 15 augustus 2026 geldt. Het NIS2 compliance pakket bevat de incidentprocedure met drempeltoets en beslisboom, en met de digitale Coach loopt u na of uw beoordeling en meldketen op elkaar aansluiten.
Verder lezen over NIS2
- Welke Logging En Monitoring Vraagt NIS2? NIS2 logging en monitoring praktisch uitgelegd: welke logbronnen u vastlegt, bewaartermijnen, kloksynchronisatie, alerting, en hoe uw logs de…
- Hoe Beoordeelt En Contracteert U Leveranciers Onder NIS2? Een werkend NIS2 leveranciersbeleid in vier stappen: leveranciersregister, risicoclassificatie, vragenlijst en beveiligingsbijlage bij het contract, plus periodieke herbeoordeling…
- Welke Rol Speelt Cryptografie En Encryptie In NIS2? NIS2 cryptografie en encryptie is maatregel 8 van artikel 21. Lees waar u versleuteling toepast in rust en…
