Een cyberincident in ICT-compliance is een gebeurtenis die de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van opgeslagen, verzonden of verwerkte gegevens in gevaar brengt. Datzelfde geldt voor de diensten die via je netwerk- en informatiesystemen worden aangeboden.
Dat is de definitie van incident uit artikel 1 van de Cyberbeveiligingswet. Wij gebruiken die als de algemene, omdat zij het breedst is en voor alle sectoren geldt. Het woord cyberincident zelf komt in de wet slechts één keer voor, in artikel 56, waar het wordt afgezet tegen niet-cybergerelateerde incidenten.
Let op wat er niet in die definitie staat. Er staat geen kwaadwilligheid in, geen aanval, geen dader. Een stroomstoring die je systemen platlegt is een incident in de zin van de wet, net als een ransomware-aanval.
De andere kaders hanteren een eigen definitie. Die verschillen op punten die uitmaken. ISO 27001 spreekt van samenhangende gebeurtenissen, DORA van ongeplande gebeurtenissen en de AVG van een inbreuk op de beveiliging van persoonsgegevens.
Niet elk incident is meldplichtig. Daarvoor moet het significant zijn. Dat is een aparte wettelijke drempel met eigen criteria.
De wet kent daarnaast het bijna-incident: een gebeurtenis die de boel in gevaar had kunnen brengen maar met succes is voorkomen. Dat begrip staat in geen enkele norm.
Op deze pagina
- Feitenkader cyberincident in ICT-compliance
- Wanneer een gebeurtenis een incident wordt
- Waarom elk kader een eigen definitie hanteert
- Het bijna-incident, dat alleen de wet kent
- Voor wie het begrip geldt in ICT-compliance
- Positie van het cyberincident binnen ICT-compliance
- Een cyberincident bij je leverancier
- Zo helpt ClickOn
- Veelgestelde vragen over het cyberincident in ICT-compliance
Feitenkader cyberincident in ICT-compliance
Dit feitenkader zet de vaste gegevens over het cyberincident bij elkaar. De definitie per kader staat in de tabel verderop.
| Kenmerk | Waarde |
|---|---|
| Algemene definitie | Cyberbeveiligingswet, artikel 1, onder incident |
| Wat er in gevaar komt | beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid |
| Waarvan | opgeslagen, verzonden of verwerkte gegevens, plus de diensten zelf |
| Kwaadwilligheid vereist | nee, een storing telt ook |
| De term cyberincident in de wet | één keer, in artikel 56, als afbakening tegenover niet-cybergerelateerd |
| Tussenstation gebeurtenis | wel in ISO 27001, niet in de wet |
| Zwaardere categorie | significant incident, Cyberbeveiligingswet artikel 25 |
| Voorkomen incident | bijna-incident, alleen in de Cyberbeveiligingswet gedefinieerd |
| Meldplichtig | alleen bij een significant incident |
| Aantal definities in de kaders | vier, met onderling verschillende reikwijdte |
| In werking | 15 augustus 2026 |
Wanneer een gebeurtenis een incident wordt
Een gebeurtenis wordt een incident op het moment dat zij een van de vier eigenschappen in gevaar brengt. Dat klinkt eenvoudig, maar de kaders leggen die grens niet op dezelfde plek.
ISO 27001 kent een tussenstation. Beheersmaatregel A.5.25 verlangt dat de organisatie informatiebeveiligingsgebeurtenissen beoordeelt en beslist of ze moeten worden gecategoriseerd als informatiebeveiligingsincidenten. Er is dus een expliciete beoordelingsstap tussen wat er gebeurt en wat een incident heet. Wie die stap niet inricht, heeft geen manier om onderscheid te maken tussen ruis en werk.
De wet kent dat tussenstation niet. De Cyberbeveiligingswet gaat rechtstreeks van incident naar significant incident. Een gebeurtenis die de vier eigenschappen in gevaar brengt is meteen een incident; de vraag is alleen nog of het significant is. Dat scheelt een stap, maar het betekent ook dat de zeef ergens anders zit.
Die tweede grens ligt in artikel 25 lid 2. Een incident is significant als het een ernstige operationele verstoring van je diensten of financiële verliezen veroorzaakt of kan veroorzaken. Het geldt ook als het andere entiteiten heeft getroffen of kan treffen door aanzienlijke materiële of immateriële schade.
Voor de praktijk betekent dat twee beoordelingen. Eerst of er sprake is van een incident, daarna of het significant is. De eerste vraag is technisch en de tweede is bestuurlijk. Wie beide bij dezelfde persoon legt, krijgt vroeg of laat een verkeerde uitkomst.
Waarom elk kader een eigen definitie hanteert
Elk kader definieert het incident vanuit zijn eigen doel. Dat verklaart de verschillen. Hier staan ze naast elkaar.
| Kader | Term | Definitie in het kort |
|---|---|---|
| Cyberbeveiligingswet artikel 1 | incident | een gebeurtenis die beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van gegevens of diensten in gevaar brengt |
| ISO 27001 via ISO 27002 3.1.15 | informatiebeveiligingsincident | een of meer samenhangende en geïdentificeerde gebeurtenissen die bedrijfsmiddelen kunnen schaden of de bedrijfsvoering kunnen compromitteren |
| DORA artikel 3 punt 8 | ICT-gerelateerd incident | één gebeurtenis of een reeks gekoppelde gebeurtenissen die niet gepland zijn en de beveiliging in gevaar brengen met nadelig effect |
| AVG | inbreuk in verband met persoonsgegevens | een inbreuk op de beveiliging die per ongeluk of onrechtmatig leidt tot vernietiging, verlies, wijziging of ongeoorloofde verstrekking |
ISO en DORA tellen samenhangende gebeurtenissen als één incident. Dat komt doordat beide vanuit incidentbeheer redeneren. In een meldproces komen losse signalen binnen die achteraf één gebeurtenis blijken; de definitie moet dat kunnen dragen. De wet spreekt van één gebeurtenis en laat die samenvoeging aan jou.
DORA voegt ongepland toe. Een geplande onderbreking voor onderhoud is bij DORA geen incident, ook niet als de dienst eronder ligt. De Cyberbeveiligingswet maakt dat onderscheid niet in de definitie zelf.
De AVG kijkt niet naar systemen maar naar gegevens. Daar gaat het om een inbreuk op de beveiliging met gevolgen voor persoonsgegevens. Een storing zonder gegevensgevolgen is dus wel een incident onder de wet en geen inbreuk onder de AVG.
DORA legt kwaadwilligheid apart vast. Naast het ICT-gerelateerde incident kent die verordening een eigen begrip voor de cyberaanval: een kwaadwillig incident dat voortkomt uit een poging van een dreigingsactor om een actief te vernietigen, te stelen of er ongeoorloofd toegang toe te krijgen. Dat is het enige kader in deze reeks dat de dader in een definitie zet.
Voor de praktijk maakt dat één ding uit. Val je onder meerdere kaders, dan kan dezelfde gebeurtenis onder het ene wel en onder het andere geen incident zijn. Je beoordeelt hem dus per kader en niet één keer voor alles.
Het bijna-incident, dat alleen de wet kent
Het bijna-incident is een eigen begrip in de Cyberbeveiligingswet en het staat in geen van de normen. Artikel 1 definieert het als een gebeurtenis die de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid in gevaar had kunnen brengen, maar die met succes is voorkomen of zich niet heeft voorgedaan.
Het verschil met een incident zit dus in de uitkomst en niet in de gebeurtenis. Een phishingmail die door de filter wordt tegengehouden is een bijna-incident. Dezelfde mail die wordt geopend en tot een gecompromitteerd account leidt, is een incident.
Waarom dat begrip er is: de wet kent een vrijwillige melding. Een bijna-incident hoef je niet te melden, maar je mag het wel. Dat levert het CSIRT beeld op van dreigingen die net niet zijn geland. Dat beeld is bruikbaar voor organisaties die dezelfde aanval nog voor de kiezen krijgen.
Voor je eigen registratie is het onderscheid ook nuttig. Een organisatie die alleen incidenten telt, mist de aanvallen die zijn afgeslagen. Dat is precies de informatie waarmee je aantoont dat je maatregelen werken. Dat sluit aan op de effectiviteitstoets die de zorgplicht vraagt.
Voor wie het begrip geldt in ICT-compliance
Het begrip cyberincident raakt je via het kader waaronder je valt. Dat kader bepaalt welke definitie je moet aanhouden.
Je valt onder de Cyberbeveiligingswet. Dan geldt de definitie uit artikel 1. De vervolgvraag is of het incident significant is in de zin van artikel 25. Alleen dan treedt de meldplicht in werking.
Je verwerkt persoonsgegevens. Dan geldt daarnaast de AVG-definitie van een inbreuk. Eén gebeurtenis kan onder beide vallen en dan zijn het twee beoordelingen met twee verschillende drempels.
Je bent een financiële entiteit. Dan geldt de DORA-definitie, met het extra kenmerk ongepland en met een eigen categorie voor een cyberaanval.
Je werkt met ISO 27001 of NEN 7510. Dan gebruik je de normdefinitie en richt je de beoordelingsstap uit A.5.25 in. Die norm verplicht je niet tot melden aan een autoriteit, maar wel tot het vastleggen van de beoordeling.
Val je onder geen enkel kader, dan bestaat er geen wettelijke definitie die je bindt. Je cyberverzekeraar hanteert dan zijn eigen omschrijving. Die staat in de polis en niet in de wet.
Positie van het cyberincident binnen ICT-compliance
Positie van het cyberincident binnen ICT-compliance is die van scharnierpunt: het is het moment waarop preventie overgaat in respons.
Waar een cyberincident uit voortkomt
Een cyberincident komt voort uit een cyberdreiging die een kwetsbaarheid benut. Samen vormen die het cyberrisico dat je vooraf hebt gewogen.
Waar een cyberincident toe leidt
Een cyberincident leidt tot respons en herstel. Bij een significant incident volgt daarnaast de meldplicht met haar termijnen. De maatregelen die het incident hadden moeten voorkomen staan bij risicobeheersmaatregelen.
Waar een cyberincident op slaat
Een cyberincident slaat op je netwerk- en informatiesystemen en op de gegevens daarin. De schade wordt gemeten langs beschikbaarheid, integriteit en vertrouwelijkheid, aangevuld met authenticiteit.
Een cyberincident bij je leverancier
Een cyberincident bij je leverancier raakt je op twee manieren. Dat is de situatie waarin de meeste mkb-organisaties het begrip voor het eerst tegenkomen.
Via je eigen dienstverlening. Ligt de dienst van je leverancier plat en ligt jouw dienst daardoor ook plat, dan heb je zelf een incident in de zin van artikel 1. De oorzaak ligt buiten je organisatie, de gevolgen niet. Val je onder de wet, dan beoordeel je zelf of het significant is.
Via de gegevens. Verwerkt je leverancier persoonsgegevens voor jou, dan verplicht artikel 33 lid 2 van de AVG hem om jou zonder onredelijke vertraging te informeren zodra hij kennis heeft van een inbreuk. Jij bent dan degene die de melding aan de toezichthouder doet, niet hij.
Dat is waarom je opdrachtgever je een vragenlijst stuurt en waarom in contracten meldtermijnen staan die korter zijn dan de wettelijke. Wie binnen 24 uur moet melden, kan niet wachten tot zijn leverancier na een week belt.
Wat je daarvoor nodig hebt is geen techniek maar afspraken: wie meldt wat aan wie, binnen welke termijn, plus met welke gegevens. Die afspraak leg je vast voordat er iets gebeurt. Dat is ketenverantwoordelijkheid in de praktijk.
Zo helpt ClickOn
ClickOn richt de detectie in waarmee je een incident ziet en levert de vastlegging waarmee je het kunt beoordelen. Wij werken op de Microsoft 365-werkplek en zorgen dat de tijdlijn, de getroffen accounts en de genomen maatregelen vastliggen op het moment dat je ze nodig hebt.
Wat wij oppakken: detectie en alertering, logging met bewaartermijnen, de technische reconstructie van wat er is gebeurd plus het herstel. Wat buiten onze scope valt: de beoordeling of een gebeurtenis een incident is, de vraag of het significant is alsook de melding zelf. Dat zijn beslissingen van je eigen organisatie.
Met ClickOn Compliant MKB is dat beheer doorlopend en standaard compliant ingericht. Heb je een audit of een normeringsplicht op je bord, dan zet de Compliance Sprint je omgeving in één traject op orde tegen een vaste prijs per werkplek.
Vraag de Compliance Sprint aan
Veelgestelde vragen over het cyberincident in ICT-compliance
Wat is een cyberincident?
Een cyberincident is een gebeurtenis die de beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid van je gegevens of van je diensten in gevaar brengt. Dat is de definitie van incident uit artikel 1 van de Cyberbeveiligingswet. Er hoeft geen aanvaller aan te pas te komen: een storing of een menselijke fout valt er net zo goed onder.
Wat is het verschil tussen een cyberincident en een cyberaanval?
Een aanval is een incident met een dader. DORA legt dat als enige kader apart vast: een cyberaanval is daar een kwaadwillig incident dat voortkomt uit een poging van een dreigingsactor om een actief te vernietigen, te stelen of er ongeoorloofd toegang toe te krijgen. De Cyberbeveiligingswet maakt dat onderscheid niet in de definitie, maar vraagt bij de melding wel of het incident vermoedelijk kwaadwillig was.
Waarom hanteren de normen verschillende definities?
Omdat ze een verschillend doel dienen. ISO 27001 en DORA redeneren vanuit incidentbeheer en tellen samenhangende gebeurtenissen als één incident. De AVG kijkt naar persoonsgegevens en spreekt daarom van een inbreuk op de beveiliging. DORA voegt daaraan toe dat het ongepland moet zijn. Val je onder meerdere kaders, dan beoordeel je dezelfde gebeurtenis per kader.
Wat is een bijna-incident?
Een gebeurtenis die de beveiliging in gevaar had kunnen brengen, maar die met succes is voorkomen of zich niet heeft voorgedaan. Dat begrip staat in artikel 1 van de Cyberbeveiligingswet en in geen enkele norm. Je hoeft het niet te melden, maar het mag vrijwillig. Voor je eigen dossier is het waardevol, want het laat zien welke aanvallen je maatregelen hebben tegengehouden.
Moet ik elk cyberincident melden?
Nee. Alleen een significant incident is meldplichtig. Dat is een incident dat een ernstige operationele verstoring of financiële verliezen veroorzaakt of kan veroorzaken. Het geldt ook als het andere entiteiten treft met aanzienlijke schade. De precieze criteria worden bij algemene maatregel van bestuur vastgesteld en verschillen per sector.
Wat als het incident bij mijn leverancier plaatsvindt?
Ligt jouw dienstverlening daardoor plat, dan heb je zelf een incident in de zin van de wet en beoordeel je zelf of het significant is. Verwerkt je leverancier persoonsgegevens voor je, dan moet hij je op grond van artikel 33 lid 2 van de AVG zonder onredelijke vertraging informeren. De melding aan de toezichthouder doe jij, niet hij.