NIS2 en de Cyberbeveiligingswet: Wat Software Aan Je Keten Verandert

Introductie

Er komt een wet aan die veel softwarebedrijven onderschatten omdat ze denken dat hij niet voor hen geldt. De Cyberbeveiligingswet, de Nederlandse omzetting van de Europese NIS2-richtlijn, treedt naar verwachting in het tweede kwartaal van 2026 in werking. Het wetsvoorstel is op 4 juni 2025 bij de Tweede Kamer ingediend. De invoering is eerder verschoven van het derde kwartaal van 2025 naar 2026 vanwege de complexiteit van de implementatie.

De denkfout zit in het woord essentieel. Veel mkb-ondernemers lezen dat de wet geldt voor essentiële en belangrijke entiteiten zoals energie, water, zorg en banken, en concluderen dat zij buiten schot blijven. Maar NIS2 werkt door de keten heen. Lever je software aan zo'n organisatie, dan moet die organisatie kunnen aantonen dat jij hun beveiliging niet verzwakt. Naar schatting vallen daardoor ongeveer 50.000 Nederlandse bedrijven indirect onder de wet. Dit artikel legt uit wat dat concreet voor software betekent en hoe je nu al bouwt zodat je straks aantoonbaar voldoet.

Wat NIS2 en de Cyberbeveiligingswet precies zijn

"NIS2 werkt niet rechtstreeks op organisaties. Pas wanneer de Cyberbeveiligingswet door Tweede en Eerste Kamer is aangenomen, ontstaan in Nederland de concrete verplichtingen."

— Samenvatting Digitale Overheid over de Cyberbeveiligingswet, geraadpleegd mei 2026

NIS2 staat voor de tweede Network and Information Security Directive, een Europese richtlijn die sinds 16 januari 2023 van kracht is. Een richtlijn werkt niet rechtstreeks: elke lidstaat moet hem omzetten naar nationale wetgeving. In Nederland gebeurt dat via de Cyberbeveiligingswet, die de huidige Wet beveiliging netwerk- en informatiesystemen vervangt. Het doel is de digitale weerbaarheid van essentiële diensten te verhogen, omdat de afhankelijkheid van digitale systemen en de dreiging tegelijk toenemen.

De wet kent twee categorieën entiteiten: essentiële en belangrijke. Essentiële entiteiten hebben bij uitval grote maatschappelijke impact, denk aan betalingsverkeer of energievoorziening. Belangrijke entiteiten zijn een bredere groep, waaronder veel digitale dienstverleners, productiebedrijven en aanbieders van online diensten. NIS2 breidde het aantal sectoren fors uit ten opzichte van de eerste richtlijn, naar achttien sectoren inclusief de maakindustrie en digitale infrastructuur.

De ketenverantwoordelijkheid: waarom dit jou raakt

Het belangrijkste mechanisme voor softwarebedrijven is de ketenverantwoordelijkheid. NIS2 verplicht entiteiten om de beveiligingsrisico's in hun toeleveringsketen te beheersen. In de praktijk betekent dat: als jij software, hosting, koppelingen of beheer levert aan een essentiële of belangrijke entiteit, dan moet die klant kunnen aantonen dat jij zijn beveiliging niet ondermijnt. Jij wordt daarmee onderdeel van zijn compliance.

Dat heeft een concreet gevolg dat al begint voordat de wet formeel in werking treedt. Grote klanten gaan hun leveranciers aanschrijven met vragenlijsten, contractuele eisen en bewijslast over beveiliging. Wie daar geen geloofwaardig antwoord op heeft, verliest opdrachten lang voordat er een toezichthouder in beeld komt. Voor een softwarebureau of SaaS-leverancier is NIS2 daarom niet primair een juridisch risico maar een commercieel risico: je wint of verliest tenders op aantoonbare beveiliging.

Ontwikkel je bijvoorbeeld een planningssysteem voor een ziekenhuis, een koppeling voor een netbeheerder of een portaal voor een financiële instelling, dan ben je in de praktijk al onderdeel van een NIS2-keten. De vraag is niet of je het netjes hebt geregeld, maar of je het kunt bewijzen.

De drie kernverplichtingen

De wet legt drie hoofdverplichtingen op aan organisaties die er direct onder vallen. Eén: de zorgplicht. Je moet je beveiligings- en continuïteitsrisico's systematisch analyseren, van cyberaanvallen tot datadiefstal en risico's in de leveringsketen, en op basis daarvan passende technische en organisatorische maatregelen nemen. Twee: de meldplicht. Significante incidenten meld je binnen 24 uur als vroegtijdige waarschuwing en binnen 72 uur als volledige melding bij de toezichthouder of het Nationaal Cyber Security Centrum. Drie: de registratieplicht. Entiteiten die onder de wet vallen moeten zich registreren, zodat er een Europees totaaloverzicht ontstaat.

Daarbovenop staat een element dat directies vaak onderschatten: bestuurlijke aansprakelijkheid. Het bestuur is verantwoordelijk voor het goedkeuren en bewaken van de risicomaatregelen en kan persoonlijk aansprakelijk worden gesteld. Cybersecurity is daarmee formeel een directieonderwerp geworden, geen taak die je volledig naar je IT-leverancier kunt delegeren.

Voor indirecte leveranciers vertaalt dit zich naar contractuele en aantoonbaarheidseisen. Je hoeft je vaak niet zelf te registreren, maar je moet wel kunnen laten zien dat je software en processen de zorgplicht van je klant ondersteunen in plaats van ondergraven.

Wat dit betekent voor de manier waarop software gebouwd wordt

De zorgplicht klinkt abstract, maar vertaalt zich naar concrete technische maatregelen die je in software inbouwt. Multifactorauthenticatie op alle accounts, want dat is de goedkoopste maatregel met de grootste impact. Toegangsbeheer op rolniveau, zodat gebruikers alleen bij wat ze nodig hebben. Encryptie van data in rust en onderweg. Gestructureerde logging en monitoring, zodat je incidenten kunt detecteren en binnen de meldtermijnen kunt reconstrueren. Patchmanagement, zodat bekende kwetsbaarheden snel gedicht worden.

Het tweede deel is aantoonbaarheid. NIS2 vraagt niet alleen dat je veilig bent, maar dat je het kunt bewijzen. Dat betekent dat beveiliging niet iets is wat je achteraf toevoegt, maar iets wat in de architectuur en in de documentatie zit. Een auditlog die laat zien wie wat wanneer deed. Een overzicht van datastromen en koppelingen. Een beschreven incidentprocedure. Een verwerkersregister. Veel mkb-bedrijven gebruiken ISO 27001 als kapstok, omdat dat raamwerk een groot deel van de zorgplichteisen afdekt. Voor toeleveranciers bestaat daarnaast een lichter NIS2 Supply Chain-certificaat dat in een paar maanden haalbaar is.

Bij MG Software bouwen we deze maatregelen standaard in wanneer een project een NIS2-context heeft. Geen blackbox-componenten zonder logging, geen gedeelde accounts, geen hardcoded secrets. We leveren niet alleen werkende software, maar ook de bewijsstukken die jouw klant nodig heeft voor zijn eigen zorgplicht.

Een praktische tijdlijn richting de inwerkingtreding

Begin met een gap-analyse. Breng in kaart welke van je klanten essentiële of belangrijke entiteiten zijn, welke software je aan hen levert en waar je beveiliging nu staat ten opzichte van de zorgplicht. Dit overzicht bepaalt je prioriteiten en is meteen het document dat je nodig hebt als een grote klant je aanschrijft.

Pak daarna de basismaatregelen op die het meeste risico afdekken: MFA overal, toegangsrechten opschonen, back-ups testen, een incidentresponsplan op papier en logging op orde. Dit zijn maatregelen met hoge impact en relatief lage kosten. Plan parallel de aantoonbaarheid: leg beleid vast, houd incidentlogs bij en documenteer je datastromen. Verwacht dat grote klanten hun leveranciers in de loop van 2026 actief gaan aanschrijven, dus wacht daar niet op.

Vergeet je eigen leveranciers niet. NIS2 loopt door de hele keten, dus de hostingpartij, de externe API's en de open source componenten die jij gebruikt vallen ook onder je verantwoordelijkheid. Een softwareleverancier die zijn eigen toeleveringsketen niet op orde heeft, kan zijn klanten ook niet geruststellen.

NIS2 en de AI Act samen: compliance-by-design

NIS2 staat niet op zichzelf. Voor veel softwarebedrijven valt de inwerkingtreding van de Cyberbeveiligingswet in dezelfde periode als de handhaving van de EU AI Act op 2 augustus 2026. Bouw je AI-functies in software die ook aan een essentiële keten levert, dan stapelen de eisen: NIS2 vraagt om logging, toegangsbeheer en incidentrespons, de AI Act vraagt om risicobeheer, transparantie en menselijk toezicht. Veel van die eisen overlappen.

Dat is precies waarom wij compliance-by-design hanteren in plaats van compliance achteraf. Een goede auditlog dient zowel NIS2 als de AI Act. Goed toegangsbeheer dient beveiliging én governance. Wie deze raamwerken los van elkaar achteraf probeert te bolten, doet het werk dubbel en levert vaak een minder samenhangend systeem. Wie het vanaf de architectuur meeneemt, krijgt er betrouwbaardere software voor terug.

Heb je software die aan een essentiële of belangrijke entiteit levert, of wil je weten of je portfolio NIS2-ready is? Leg ons je situatie voor. We doen een gap-analyse en bouwen waar nodig de maatregelen en bewijslast in.

Conclusie

De Cyberbeveiligingswet maakt van beveiliging een contractueel en commercieel onderwerp, niet alleen een technisch. Voor softwarebedrijven die aan essentiële en belangrijke entiteiten leveren is de belangrijkste verschuiving dat je je beveiliging niet alleen op orde moet hebben, maar ook moet kunnen bewijzen tegenover je klanten.

Wie nu begint met een gap-analyse, basismaatregelen en aantoonbaarheid, zit straks aan de goede kant van de tender en van de wet. Wie wacht tot klanten gaan aanschrijven, loopt achter de feiten aan. Beveiliging die vanaf de architectuur is meegenomen, is geen kostenpost. Het is een verkoopargument.