NIS2 en uw softwareleveranciers: wat beide partijen moeten doen

01Waar NIS2 staat in het najaar van 2026

De NIS2-richtlijn (opent een externe website), Richtlijn (EU) 2022/2555, is op 27 december 2022 in het Publicatieblad bekendgemaakt en op 16 januari 2023 in werking getreden. De lidstaten moesten hun nationale maatregelen uiterlijk op 17 oktober 2024 vaststellen en bekendmaken, en ze vanaf 18 oktober 2024 toepassen. Op die dag werd de eerste NIS-richtlijn ingetrokken.

Omdat NIS2 een richtlijn is, bindt de nationale omzettingswet een organisatie, niet de richtlijn zelf. De omzetting verloopt ongelijk: sommige lidstaten pasten hun wet op tijd toe, andere pas in 2025 of 2026, en de Europese Commissie heeft inbreukprocedures gestart tegen lidstaten die de termijn misten. Registratie, meldportalen en toezichthouders verschillen dus per land.

02Essentiële en belangrijke entiteiten

NIS2 geldt voor publieke en private entiteiten in de sectoren van bijlage I (zeer kritieke sectoren: energie, vervoer, bankwezen, infrastructuur voor de financiële markt, gezondheidszorg, drinkwater, afvalwater, digitale infrastructuur, beheer van ICT-diensten, overheid en ruimtevaart) en bijlage II (andere kritieke sectoren: post- en koeriersdiensten, afvalbeheer, chemische stoffen, levensmiddelen, vervaardiging, digitale aanbieders en onderzoek). In de regel gaat het om middelgrote en grote organisaties. Sommige vallen er ongeacht hun omvang onder, zoals verleners van vertrouwensdiensten, DNS-dienstverleners en entiteiten van de centrale overheid.

Artikel 3 deelt die organisaties vervolgens in twee categorieën in:

• Essentiële entiteiten: vooral grote organisaties in sectoren van bijlage I, plus entiteiten die ongeacht hun omvang essentieel zijn, zoals gekwalificeerde verleners van vertrouwensdiensten, registers voor topleveldomeinnamen, DNS-dienstverleners en entiteiten van de centrale overheid. Op hen wordt proactief toezicht gehouden, wat audits en inspecties ter plaatse kan omvatten.
• Belangrijke entiteiten: de andere organisaties binnen het toepassingsgebied van bijlage I en II. Het toezicht is achteraf: de autoriteit treedt op wanneer er aanwijzingen zijn dat de entiteit niet voldoet.

Beide categorieën hebben dezelfde kernplichten: maatregelen voor risicobeheer (artikel 21), melding van incidenten (artikel 23) en verantwoordelijkheid van het bestuur (artikel 20). Het verschil zit in het toezicht en in de boetes. Voor inbreuken op artikel 21 of 23 moet de nationale wet maximumboetes mogelijk maken van ten minste 10 miljoen euro of 2% van de wereldwijde jaaromzet voor essentiële entiteiten, en van ten minste 7 miljoen euro of 1,4% voor belangrijke entiteiten, telkens het hoogste bedrag. Lidstaten beslissen zelf of en in welke mate boetes gelden voor overheidsinstanties.

Valt uw softwareleverancier zelf onder NIS2?

Software schrijven is op zich geen NIS2-sector. Toch kan een leverancier er rechtstreeks onder vallen. Bijlage I omvat aanbieders van beheerde diensten, en NIS2 omschrijft die ruim: entiteiten die ICT-producten, netwerken, infrastructuur of toepassingen voor klanten installeren, beheren, exploiteren of onderhouden, ter plaatse of op afstand. Een middelgrote of grotere leverancier die toepassingen voor klanten draait of onderhoudt, kan dus zelf onder NIS2 vallen, net als aanbieders van cloudcomputing- en datacenterdiensten. Voor die aanbieders werkt Uitvoeringsverordening (EU) 2024/2690 (opent een externe website) de technische eisen in detail uit.

De meeste softwareleveranciers krijgen echter met NIS2 te maken via hun klanten, die hun eigen plicht voor de toeleveringsketen vertalen naar contractbepalingen, vragenlijsten en audits. Softwareproducten vallen bovendien onder de Cyberweerbaarheidsverordening (opent een externe website), Verordening (EU) 2024/2847: de meldplichten voor actief uitgebuite kwetsbaarheden en ernstige incidenten gelden vanaf 11 september 2026, de overige verplichtingen vanaf 11 december 2027.

03De tien minimale maatregelen van artikel 21

Artikel 21 vraagt passende en evenredige technische, operationele en organisatorische maatregelen, gebaseerd op een benadering die alle gevaren omvat. Ze houden rekening met de stand van de techniek en met relevante Europese en internationale normen, en staan in verhouding tot de blootstelling aan risico’s, de omvang van de entiteit en de waarschijnlijke ernst van incidenten. Ze omvatten ten minste:

1. 01beleid voor risicoanalyse en beveiliging van informatiesystemen;
2. 02incidentenbehandeling;
3. 03bedrijfscontinuïteit, zoals back-upbeheer en herstel na een calamiteit, en crisisbeheer;
4. 04beveiliging van de toeleveringsketen, met inbegrip van de beveiligingsaspecten van de relaties met rechtstreekse leveranciers en dienstverleners;
5. 05beveiliging bij het verwerven, ontwikkelen en onderhouden van netwerk- en informatiesystemen, met inbegrip van de behandeling en bekendmaking van kwetsbaarheden;
6. 06beleid en procedures om te beoordelen of die maatregelen doeltreffend zijn;
7. 07basispraktijken voor cyberhygiëne en opleiding in cyberbeveiliging;
8. 08beleid en procedures voor het gebruik van cryptografie en, waar passend, encryptie;
9. 09personeelsbeveiliging, toegangsbeleid en beheer van bedrijfsmiddelen;
10. 10multifactor- of continue authenticatie, en beveiligde spraak-, video-, tekst- en noodcommunicatie, waar passend.

Bij de punten 4 en 5 komen de leveranciers in beeld. Artikel 21, lid 3, vraagt entiteiten rekening te houden met de specifieke kwetsbaarheden van elke rechtstreekse leverancier, met de algemene kwaliteit van diens producten en cyberbeveiligingspraktijken, en met diens procedures voor veilige ontwikkeling. Uw klanten moeten dus kijken naar hoe u software bouwt, niet alleen naar wat u oplevert.

04Het bestuur keurt goed, houdt toezicht en legt verantwoording af

Volgens artikel 20 moeten de bestuursorganen van essentiële en belangrijke entiteiten de maatregelen voor het beheer van cyberbeveiligingsrisico’s goedkeuren en toezien op de uitvoering ervan, en kunnen zij aansprakelijk worden gesteld voor inbreuken. Bestuursleden moeten een opleiding volgen, en entiteiten worden aangemoedigd hun medewerkers ook regelmatig op te leiden. Voor overheden blijven de nationale regels over de aansprakelijkheid van openbare instellingen en ambtsdragers gelden.

Dat verandert het gesprek met leveranciers. Een bestuur dat de maatregelen moet goedkeuren, wil bewijs dat het kan volgen: welke leveranciers welke diensten ondersteunen, welke risico’s overblijven en wat daadwerkelijk getest is.

05Incidenten melden: 24 uur, 72 uur, één maand

Artikel 23 verplicht entiteiten significante incidenten te melden aan hun CSIRT of bevoegde autoriteit. Een incident is significant als het ernstige operationele verstoring of financiële verliezen voor de entiteit heeft veroorzaakt of kan veroorzaken, of aanzienlijke materiële of immateriële schade aan anderen. De melding verloopt in fasen:

Waar passend moeten entiteiten ook de afnemers van hun diensten onverwijld informeren over significante incidenten die de dienstverlening waarschijnlijk zullen aantasten. Nationale wetten voegen daar eigen formulieren en portalen aan toe.

De termijn begint te lopen wanneer de entiteit kennis krijgt van het incident. Begint het incident in een systeem van een leverancier, dan haalt de klant de 24 uur alleen als de leverancier het binnen enkele uren ontdekt, herkent en doorgeeft. Detectie, logging en een afgesproken meldkanaal horen dus in het contract, niet alleen in de techniek.

06Wat een klant onder NIS2 van zijn softwareleverancier vraagt

In de praktijk vertaalt artikel 21 zich in technische maatregelen en bewijs die een leverancier moet kunnen tonen zonder er een project van te maken. Dit zijn de vragen die wij het vaakst zien:

• Een veilige ontwikkelcyclus. Dreigingsmodellering bij belangrijke wijzigingen, peer review, geautomatiseerde beveiligingstests en controle van afhankelijkheden in de pipeline, ondertekende builds en een software bill of materials (SBOM) per release.
• Behandeling en bekendmaking van kwetsbaarheden. Een openbaar kanaal om kwetsbaarheden te melden, reactietermijnen per ernst, en een bericht aan de klant wanneer een kwetsbaarheid zijn omgeving raakt.
• Toegangsbeheer voor medewerkers van de leverancier. Persoonlijke accounts, multifactorauthenticatie, minimale rechten, tijdelijke verhoogde toegang en een log van elke beheeractie in de omgeving van de klant.
• Logging en bewijs bij incidenten. Beveiligingsrelevante gebeurtenissen gelogd met betrouwbare tijdstempels, bewaard voor een afgesproken periode en exporteerbaar, zodat de klant de vragen van de vroegtijdige waarschuwing en het eindverslag kan beantwoorden.
• Samenwerking bij incidenten. Een vaste contactpersoon en een vast kanaal, een meldtermijn die ruim binnen de 24 uur van de klant blijft, en ondersteuning bij de analyse van de grondoorzaak.
• Continuïteit en herstel. Back-ups waarvan het terugzetten is getest, hersteldoelen die aansluiten op die van de klant, en een geoefende procedure.
• Documentatie van de keten. Een actuele lijst van onderaannemers en hostinglocaties, en van de belangrijkste componenten en diensten van derden waarop de oplossing steunt.
• Een exitplan. Export van gegevens in bruikbare formaten, documentatie en ondersteuning bij de overdracht, zodat de klant van leverancier kan wisselen zonder de controle over de dienst te verliezen.

Voor volwassen engineeringteams is dit niet nieuw. Nieuw is dat de klant het moet kunnen aantonen. Onze pagina over vertrouwen en compliance beschrijft hoe wij als leverancier werken, met een managementsysteem voor informatiebeveiliging dat gecertificeerd is volgens ISO/IEC 27001.

07Een checklist voor contracten en aanbestedingen

1. 01Koppel leveranciers aan diensten. Leg vast welke leveranciers welke diensten binnen het toepassingsgebied ondersteunen, en wie toegang heeft tot uw systemen of gegevens.
2. 02Deel in naar kritikaliteit. Leg de zwaarste eisen op aan leveranciers die kritieke systemen draaien of kunnen wijzigen.
3. 03Neem de maatregelen op in het contract. Beveiligingseisen, meldtermijn en meldkanaal voor incidenten, behandeling van kwetsbaarheden, logging en bewaartermijn, audit- of bewijsrechten, regels voor onderaanneming en locaties.
4. 04Vraag bewijs, geen verklaringen. Certificaten met hun toepassingsgebied, testresultaten, een SBOM, de datum van de laatste hersteltest.
5. 05Spreek de exit vooraf af. Teruggave van gegevens, ondersteuning bij de overgang en de periode waarin de leverancier de dienst blijft leveren.
6. 06Oefen samen. Houd met uw kritieke leveranciers een incidentoefening, inclusief de vroegtijdige waarschuwing binnen 24 uur.
7. 07Herzie regelmatig. Leveranciers, diensten en dreigingen veranderen; een leveranciersregister dat eens per jaar wordt bijgewerkt, is het grootste deel van het jaar verouderd.

08De nationale wet bepaalt de details

Registratie, meldportalen, formulieren, de bevoegde autoriteit en eventuele bijkomende eisen volgen uit de nationale wet. Sommige lidstaten koppelen de maatregelen van artikel 21 aan een nationaal raamwerk of een certificering. In de regel valt een entiteit onder de lidstaat waar ze gevestigd is. Artikel 26 maakt uitzonderingen: aanbieders van openbare elektronische communicatie vallen onder elk land waar ze diensten verlenen, cloud-, datacenter- en beheerde dienstverleners en enkele andere digitale aanbieders onder het land van hun hoofdvestiging, en overheidsinstanties onder de staat die ze heeft opgericht.

09Wat u de komende maanden volgt

• Uw nationale omzetting: registratietermijnen, uitvoeringsbesluiten en de richtsnoeren van uw autoriteit.
• Het voorstel voor een Digitale Omnibus (opent een externe website) van de Commissie van 19 november 2025, COM(2025) 837, dat incidentmeldingen onder NIS2, de AVG, DORA en andere wetten via één centraal meldpunt van ENISA zou laten verlopen. In oktober 2026 lag het nog bij het Europees Parlement (opent een externe website)); tot het is aangenomen en van toepassing wordt, gelden de huidige kanalen en termijnen.
• Gecoördineerde EU-risicobeoordelingen van kritieke ICT-toeleveringsketens onder artikel 22, waarmee entiteiten rekening moeten houden bij de keuze van maatregelen voor leveranciers.
• De tijdlijn van de Cyberweerbaarheidsverordening voor softwareproducten, die vanaf 11 december 2027 volledig van toepassing is.

Voor financiële entiteiten vervangt de verordening digitale operationele weerbaarheid (DORA) de NIS2-regels over ICT-risicobeheer, incidentmelding en toezicht; zie ons artikel over DORA en derde aanbieders van ICT-diensten. De Commissie houdt een overzicht van NIS2 en de uitvoeringshandelingen bij op haar NIS2-pagina (opent een externe website).