Een kwetsbaarheid in ICT-compliance is een zwakheid, vatbaarheid of gebrek van ICT-producten of ICT-diensten die door een cyberdreiging kan worden uitgebuit.
Die definitie staat in artikel 1 van de Cyberbeveiligingswet. Let op de afbakening: het gaat om ICT-producten en ICT-diensten. Die twee zijn in datzelfde artikel gedefinieerd. Een zwakte in een proces of in een gebouw valt er niet onder.
De kwetsbaarheid is de opening. Zij wordt pas gevaarlijk als er een cyberdreiging is die haar kan uitbuiten. Samen vormen die twee het risico waarop je maatregelen kiest.
De Cyber Resilience Act splitst het begrip verder op in drie gradaties. Die splitsing bepaalt wanneer een fabrikant moet melden.
Wat je met een gevonden kwetsbaarheid moet doen, staat niet in de wet maar in de normen. ISO 27001 beschrijft het proces. De BIO stelt als enige kader een harde termijn: bij hoge kans en hoge schade uiterlijk binnen een week.
Melden mag door iedereen, ook anoniem. De wet wijst daarvoor een coördinator aan die bemiddelt tussen de melder en de leverancier.
Op deze pagina
- Feitenkader kwetsbaarheid in ICT-compliance
- Drie gradaties van kwetsbaarheid
- In welke normen kwetsbaarheid staat
- Wat je met een kwetsbaarheid moet doen
- Melden en gecoördineerd bekendmaken
- Voor wie het begrip geldt in ICT-compliance
- Positie van de kwetsbaarheid binnen ICT-compliance
- Kwetsbaarheid in ICT-compliance in de praktijk
- Zo helpt ClickOn
- Veelgestelde vragen over kwetsbaarheid in ICT-compliance
Feitenkader kwetsbaarheid in ICT-compliance
Dit feitenkader zet de vaste gegevens over de kwetsbaarheid bij elkaar. Wat elk kader ervan vraagt, staat in de normtabel verderop.
| Kenmerk | Waarde |
|---|---|
| Wettelijke definitie | Cyberbeveiligingswet, artikel 1, onder kwetsbaarheid |
| Waarin | ICT-producten of ICT-diensten |
| Wat het is | een zwakheid, vatbaarheid of gebrek |
| Wanneer het telt | wanneer een cyberdreiging haar kan uitbuiten |
| Gradaties in de CRA | kwetsbaarheid, uitbuitbare kwetsbaarheid, actief uitgebuite kwetsbaarheid |
| Hersteltermijn in de BIO | uiterlijk binnen een week bij hoge kans plus hoge schade |
| Termijn in de wet of in ISO 27001 | geen |
| Melden verplicht voor entiteiten | nee |
| Vrijwillig melden | ja, door eenieder, ook anoniem, artikel 34 |
| Wie bemiddelt | de coördinator gecoördineerde bekendmaking, artikel 17 |
| Voorwaarde voor beheer | een actuele inventarislijst met leverancier, versie en eigenaar |
| Term in de AVG | komt niet voor; het mechanisme zit in artikel 32 |
| In werking | 15 augustus 2026 |
Drie gradaties van kwetsbaarheid
De Cyber Resilience Act onderscheidt drie gradaties. Die oplopende reeks verklaart waarom niet elke kwetsbaarheid dezelfde behandeling krijgt.
| Gradatie | Wat de verordening zegt |
|---|---|
| kwetsbaarheid | een zwakheid, vatbaarheid of gebrek van een product met digitale elementen dat door een cyberdreiging kan worden uitgebuit |
| uitbuitbare kwetsbaarheid | een kwetsbaarheid die onder praktische operationele omstandigheden effectief door een tegenstander zou kunnen worden gebruikt |
| actief uitgebuite kwetsbaarheid | een kwetsbaarheid waarvoor betrouwbare bewijzen bestaan dat een kwaadwillige actor die heeft uitgebuit in een systeem zonder toestemming van de systeemeigenaar |
Het verschil zit in het bewijs. De eerste categorie is theoretisch mogelijk, de tweede is praktisch bruikbaar, de derde is aantoonbaar gebruikt. Pas bij die derde ontstaat de meldplicht voor fabrikanten.
Die meldplicht gaat eerder in dan de rest van de verordening. De CRA is van toepassing met ingang van 11 december 2027, maar het artikel over het melden van actief uitgebuite kwetsbaarheden geldt al vanaf 11 september 2026. De bepalingen over conformiteitsbeoordelingsinstanties gelden vanaf 11 juni 2026.
Er zit bovendien terugwerking in. De meldverplichting geldt voor alle producten binnen het toepassingsgebied die vóór 11 december 2027 in de handel zijn gebracht. De overige eisen gelden voor die producten alleen wanneer ze na die datum ingrijpend worden gewijzigd.
Wat een fabrikant volgens de CRA moet inrichten. Een beleid inzake gecoördineerde openbaarmaking van kwetsbaarheden invoeren en handhaven, een contactadres verstrekken voor het melden van ontdekte kwetsbaarheden, plus mechanismen inrichten om updates veilig te verspreiden zodat kwetsbaarheden tijdig en waar van toepassing automatisch worden verholpen of beperkt. De verordening staat daarbij toe dat de fabrikant openbaarmaking van een verholpen kwetsbaarheid uitstelt totdat gebruikers de patch hebben kunnen uitvoeren.
In welke normen kwetsbaarheid staat
Kwetsbaarheid komt in vijf van de zes kaders voor, met per kader een andere reikwijdte. Dat verschil bepaalt waarover je het precies hebt.
| Kader | Reikwijdte | Vindplaats |
|---|---|---|
| Cyberbeveiligingswet en NIS2 | ICT-producten of ICT-diensten | Artikel 1 voor de definitie, artikel 17 en 34 voor het melden |
| Cyber Resilience Act | producten met digitale elementen, in drie gradaties | Artikel 3, met artikel 14 voor het melden |
| DORA | een actief, systeem, proces of controle | Artikel 3 |
| ISO 27001 | technische kwetsbaarheden in in gebruik zijnde informatiesystemen | Beheersmaatregel 8.6 |
| NEN 7510 | gelijk aan ISO 27001, met een zorgspecifieke aanvulling | Beheersmaatregel 8.6 |
| BIO | overheidsmaatregelen met termijnen plus testverplichtingen | Overheidsmaatregel 8.08, plus hoofdstuk 6.3 |
| AVG | kent het begrip niet | het mechanisme zit in artikel 32 |
DORA rekt het begrip het verst op. Daar is een kwetsbaarheid een zwakte, gevoeligheid of tekortkoming in een actief, systeem, proces of controle die kan worden misbruikt. Proces en controle staan er dus expliciet in, terwijl de Nederlandse wet zich beperkt tot producten en diensten.
De BIO gebruikt het begrip ook in de risicoanalyse. In hoofdstuk 6.3 stelt de entiteit vast welke waardevolle informatiemiddelen aanwezig zijn, brengt de relevante bedreigingen in kaart, identificeert kwetsbaarheden en bepaalt wat de consequenties zijn als die bedreigingen zich manifesteren.
De wet gebruikt het begrip op nog twee plekken. In de definitie van beveiligingsscan, technisch onderzoek van netwerk- en informatiesystemen om inzicht te krijgen in kwetsbaarheden en risico’s van deze systemen. En in artikel 21 lid 4, dat bij ketenmaatregelen verlangt dat je rekening houdt met de specifieke kwetsbaarheden van elke rechtstreekse leverancier en dienstverlener.
Wat je met een kwetsbaarheid moet doen
Wat je met een kwetsbaarheid moet doen, staat het volledigst in ISO 27001, beheersmaatregel 8.6 over het beheer van technische kwetsbaarheden. De beheersmaatregel vraagt drie dingen: informatie verkrijgen over technische kwetsbaarheden van in gebruik zijnde informatiesystemen, de blootstelling van de organisatie daaraan evalueren, plus passende maatregelen treffen. Het doel is misbruik voorkomen.
Er is een harde voorwaarde vooraf. De norm noemt een nauwkeurige inventarislijst van bedrijfsmiddelen een voorwaarde voor doeltreffend beheer. In die lijst horen de leverancier en de naam van de software, de versienummers, de toepassingsstatus en de verantwoordelijke persoon te staan. Zonder die lijst weet je bij een waarschuwing niet of hij jou raakt.
De BIO stelt als enige kader een termijn. Overheidsmaatregel 8.08.01: als van een kwetsbaarheidswaarschuwing de kans op misbruik en de verwachte schade beide hoog zijn, worden passende mitigerende maatregelen zo snel mogelijk getroffen, maar uiterlijk binnen een week. Lukt dat niet, dan worden op basis van een expliciete risicoafweging andere mitigerende maatregelen getroffen.
De BIO kent ook een productieblokkade. Internetfacing-informatiesystemen krijgen bij iedere nieuwe release of major update een verplichte, waar mogelijk geautomatiseerde penetratietest. Komen daar bevindingen met een hoog risico uit die niet anders te mitigeren zijn, dan mag het systeem niet in productie. Daarnaast worden die systemen minimaal jaarlijks getest op zwakheden en kwetsbaarheden.
Drie dingen uit ISO 27001 die vaak ontbreken. Je hoort van leveranciers van informatiesystemen te verlangen dat zij het melden, afhandelen en bekendmaken van kwetsbaarheden garanderen, met die eisen in de contracten. Je houdt een auditlogbestand bij van alle uitgevoerde stappen. En je stemt het kwetsbaarhedenproces af op je incidentbeheer, zodat gegevens over kwetsbaarheden terechtkomen bij de functie die op incidenten reageert.
Voor clouddiensten ligt de verantwoordelijkheid anders. Gebruik je een clouddienst van een derde aanbieder, dan garandeert die aanbieder het beheer van de technische kwetsbaarheden van zijn eigen middelen.
Wanneer patchen niet kan. NEN 7510 erkent als enige norm dat de standaardmaatregel soms onmogelijk is. Voor bepaalde medische apparaten die gegevens registreren, verwerken of rapporteren is het niet mogelijk of om klinische veiligheidsredenen niet passend om software te updaten of patches toe te passen. In dat geval behoren waar nodig compenserende beheersmaatregelen te worden getroffen. Certificering voor veilige werking kan bovendien verbieden dat er iets aan de softwarestack wordt veranderd, met inbegrip van beveiligingspatches.
Melden en gecoördineerd bekendmaken
Melden van een kwetsbaarheid is niet verplicht voor entiteiten, maar de wet richt er wel een compleet apparaat voor in.
Eenieder mag melden, ook anoniem. Artikel 34 bepaalt dat iedereen op vrijwillige basis een melding kan maken van een kwetsbaarheid bij de coördinator, dat die melding anoniem kan worden gedaan, plus dat de coördinator de anonimiteit van de melder waarborgt.
Er is een aangewezen bemiddelaar. Artikel 17 wijst een CSIRT aan als coördinator met het oog op een gecoördineerde bekendmaking van kwetsbaarheden. Die coördinator heeft vijf taken:
| Taak | Wat het inhoudt |
|---|---|
| Bemiddelen | optreden als tussenpersoon tussen de melder en de fabrikant of aanbieder van het mogelijk kwetsbare ICT-product of de dienst |
| Opsporen | de betrokken entiteiten opsporen en contact met ze opnemen |
| Bijstaan | de melder ondersteunen |
| Onderhandelen | tijdschema’s voor bekendmaking afspreken en kwetsbaarheden beheren die meerdere entiteiten raken |
| Samenwerken | binnen het CSIRT-netwerk optreden wanneer een kwetsbaarheid gevolgen kan hebben in meer dan één lidstaat |
Die vierde taak is de kern van gecoördineerde bekendmaking: er wordt onderhandeld over het moment waarop een kwetsbaarheid openbaar wordt, zodat de leverancier tijd heeft om te herstellen voordat de informatie beschikbaar komt.
Aan de andere kant van die route staat de fabrikant. ISO 27001 merkt op dat organisaties die zelf software of diensten leveren herstelmaatregelen kunnen vrijgeven en informatie over kwetsbaarheden kunnen bekendmaken via een openbaar informatiebericht, plus informatie kunnen aanleveren voor databasediensten voor softwarekwetsbaarheden.
Voor wie het begrip geldt in ICT-compliance
Het begrip raakt vrijwel iedereen die ICT gebruikt, maar wat je moet doen verschilt per rol.
Je gebruikt ICT-producten en diensten. Dan is beheersmaatregel 8.6 het relevante kader wanneer je met ISO 27001 of NEN 7510 werkt. De zorgplicht geldt wanneer je onder de Cyberbeveiligingswet valt. Artikel 21 lid 3 onderdeel e noemt de respons op en bekendmaking van kwetsbaarheden uitdrukkelijk als onderdeel van je maatregelen.
Je bent een overheidsorganisatie. Dan gelden de termijnen en testverplichtingen uit de BIO, inclusief de week bij hoge kans en hoge schade.
Je maakt of levert ICT-producten. Dan raakt de Cyber Resilience Act je rechtstreeks, met de meldplicht voor actief uitgebuite kwetsbaarheden vanaf 11 september 2026.
Je vindt een kwetsbaarheid bij een ander. Dan staat de route van artikel 34 voor je open, vrijwillig en anoniem, met de coördinator als bemiddelaar.
Positie van de kwetsbaarheid binnen ICT-compliance
Positie van de kwetsbaarheid binnen ICT-compliance is die van opening: het is de zwakte die een dreiging nodig heeft om schade te kunnen veroorzaken.
Waar een kwetsbaarheid toe leidt
Een kwetsbaarheid leidt samen met een cyberdreiging tot een cyberrisico. Wordt zij uitgebuit, dan is er een cyberincident.
Waar een kwetsbaarheid onder valt
Het beheer van kwetsbaarheden valt onder de zorgplicht, die de respons op en bekendmaking van kwetsbaarheden als eigen onderdeel noemt. De maatregelen die eruit volgen staan bij risicobeheersmaatregelen.
Waar een kwetsbaarheid in zit
Een kwetsbaarheid zit in een ICT-product of ICT-dienst, dus in je netwerk- en informatiesystemen. Via je leveranciers raakt zij ook je ketenverantwoordelijkheid.
Kwetsbaarheid in ICT-compliance in de praktijk
Kwetsbaarhedenbeheer strandt in de praktijk zelden op de wil om te patchen en bijna altijd op het overzicht. Er komt een waarschuwing binnen en niemand kan snel vaststellen of de organisatie dat product draait, in welke versie en op welke systemen.
Dat is precies waarom ISO 27001 de inventarislijst als voorwaarde stelt en er vier velden bij noemt. Zonder leverancier, versienummer, toepassingsstatus en verantwoordelijke is een waarschuwing niet te vertalen naar een actie.
Het tweede patroon is dat de termijn nergens is afgesproken. Alleen de BIO noemt een week. Die geldt voor overheden. Wie daar niet onder valt heeft geen extern gegeven termijn en moet er zelf een afspreken, want zonder termijn schuift een patch door tot er iets gebeurt.
Het derde is de keten. Een kwetsbaarheid zit vaker in software van een leverancier dan in je eigen systemen. ISO 27001 zegt daarom dat je contractueel van leveranciers hoort te verlangen dat zij melden, afhandelen en bekendmaken. In de praktijk staat dat zelden in een contract. Dan ben je afhankelijk van of je leverancier je uit zichzelf informeert.
Het herstel zit dus in drie afspraken die je vooraf maakt: wie de inventarislijst bijhoudt, binnen welke termijn wat wordt gepatcht, plus wat je leverancier je moet melden.
Zo helpt ClickOn
ClickOn houdt de inventarislijst van je Microsoft 365-omgeving actueel, volgt de kwetsbaarheidswaarschuwingen die jouw omgeving raken en voert het patchbeheer uit. Wij leggen vast wat er is gepatcht en wanneer, zodat je het kunt aantonen.
Wat wij oppakken: het bijhouden van de inventaris, patchbeheer op werkplekken en servers, kwetsbaarheidssignalen vertalen naar maatregelen plus de vastlegging daarvan. Wat buiten onze scope valt: het bepalen van je eigen hersteltermijnen, de contractuele eisen aan je softwareleveranciers alsook het besluit om een systeem niet in productie te nemen.
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 kwetsbaarheid in ICT-compliance
Wat is een kwetsbaarheid in ICT-compliance?
Een kwetsbaarheid is een zwakheid, vatbaarheid of gebrek van ICT-producten of ICT-diensten die door een cyberdreiging kan worden uitgebuit. Die definitie staat in artikel 1 van de Cyberbeveiligingswet. De afbakening naar ICT-producten en ICT-diensten is belangrijk: een zwakte in een proces valt onder de Nederlandse wet niet onder dit begrip.
Wat is het verschil tussen een kwetsbaarheid en een risico?
Een kwetsbaarheid is de opening, een risico is de weging. Pas als er een cyberdreiging bestaat die de kwetsbaarheid kan uitbuiten, ontstaat een risico dat je kunt beoordelen op kans en gevolg. Een kwetsbaarheid zonder dreiging levert geen risico op.
Binnen welke termijn moet ik een kwetsbaarheid verhelpen?
Dat hangt af van je kader. De Cyberbeveiligingswet en ISO 27001 noemen geen termijn. De BIO wel: als bij een kwetsbaarheidswaarschuwing de kans op misbruik en de verwachte schade beide hoog zijn, worden mitigerende maatregelen zo snel mogelijk getroffen, maar uiterlijk binnen een week. Val je niet onder de BIO, dan spreek je zelf een termijn af.
Moet ik een kwetsbaarheid melden?
Als entiteit hoef je dat niet. Wel mag iedereen op vrijwillige basis een kwetsbaarheid melden bij de aangewezen coördinator, ook anoniem. Die coördinator bemiddelt tussen de melder en de leverancier. Ook onderhandelt hij over het moment van bekendmaking. Voor fabrikanten van producten met digitale elementen geldt vanaf 11 september 2026 wel een meldplicht voor actief uitgebuite kwetsbaarheden.
Wat als een systeem niet gepatcht kan worden?
Dan tref je compenserende beheersmaatregelen. NEN 7510 erkent dat het bij bepaalde medische apparaten niet mogelijk of om klinische veiligheidsredenen niet passend is om te patchen. De norm schrijft dan compenserende maatregelen voor. Certificering voor veilige werking kan wijzigingen aan de softwarestack zelfs verbieden. Diezelfde redenering geldt buiten de zorg voor apparatuur die je niet kunt aanraken.
Wie is verantwoordelijk voor kwetsbaarheden in software van mijn leverancier?
Je blijft zelf verantwoordelijk voor de beveiliging van je systemen, maar ISO 27001 zegt dat je van leveranciers hoort te verlangen dat zij het melden, afhandelen en bekendmaken van kwetsbaarheden garanderen, met die eisen in het contract. Bij clouddiensten garandeert de aanbieder het beheer van de kwetsbaarheden in zijn eigen middelen.