NIS2 & de Nederlandse Cyberbeveiligingswet: wat dit betekent voor legacysystemen, shadow IT en AI-ondersteunde ontwikkeling

Voorafgaand aan de opname lazen we beide onderliggende teksten volledig door, Richtlijn (EU) 2022/2555 en de Cyberbeveiligingswet zoals gepubliceerd in Staatsblad 2026, 187, en doorzochten we die op wat ze zeggen over systemen die het einde van hun ondersteunde levensduur voorbij zijn. Die zoektocht leverde vrijwel niets op, en daar ging het grootste deel van het gesprek over.

Bron: Law & More, Tom Meevis

Samenvatting

Het artikel zet de reikwijdte, de zorgplicht, de meldplicht, de bestuurdersverantwoordelijkheid en de handhaving onder NIS2 en de Nederlandse implementatie uiteen. NIS2 bestrijkt achttien aangewezen sectoren, verdeeld in sectoren van hoog kritiek belang en overige kritieke sectoren. Daarbinnen vangt de hoofdregel organisaties met ten minste vijftig medewerkers of meer dan tien miljoen euro omzet of balanstotaal, terwijl verschillende categorieën ongeacht hun omvang onder de wet vallen, waaronder aanbieders van domeinnaamregistratiediensten en vertrouwensdienstverleners. De zorgplicht benoemt tien verplichte onderwerpen, van risicoanalyse via beveiliging van de toeleveringsketen tot meervoudige authenticatie. Incidenten volgen een vaste ladder: een vroegtijdige waarschuwing binnen 24 uur, een formele melding binnen 72 uur, een eindrapport binnen een maand. De verantwoordelijkheid ligt uitdrukkelijk bij het bestuur, inclusief persoonlijke aansprakelijkheid. Boetes lopen voor essentiële entiteiten op tot tien miljoen euro of twee procent van de wereldwijde omzet. We bespraken het stuk met Kishan Chamman, onze CTO.

Bespreking en inzichten

De wet gebruikt het woord legacy nergens. We doorzochten zowel de richtlijn als de wet op legacy, end of life, buitengebruikstelling, uitfasering, verouderd en vervanging, en het resultaat was vrijwel leeg. Wat er wel staat, is indirect. Artikel 21(2)(e) van NIS2 vereist beveiliging bij de verwerving, ontwikkeling en het onderhoud van netwerk- en informatiesystemen, inclusief de omgang met en openbaarmaking van kwetsbaarheden. Overweging 89 schaart software-updates, netwerksegmentatie en zerotrustprincipes onder basale cyberhygiëne. Overweging 90 benoemt technologische lock-in en leveranciersafhankelijkheid als risicofactoren en verbindt er geen enkele actie aan. De levenscyclus wordt erkend en het einde daarvan blijft open. Kishan leest dat als een bewuste keuze. De regelgever specificeert het resultaat dat een organisatie moet bereiken en laat de route volledig aan de organisatie zelf. Een applicatie refactoren om aan de eis van meervoudige authenticatie te voldoen, die vervangen, of er op een andere manier komen: de toezichthouder is onverschillig zolang aan de eis wordt voldaan. De Nederlandse wet bevat één bepaling die dicht in de buurt komt van een gebod tot vervanging: die stelt een minister in staat een entiteit te verplichten het gebruik van producten van een aangewezen partij in aangewezen componenten te staken en een termijn te stellen voor vervanging van wat al geïnstalleerd is. Die bepaling wordt geactiveerd door dreiging van statelijke actoren, en niet door ouderdom.

Daarmee zijn compenserende maatregelen de goedkoopste juridische route. Niets in beide teksten dwingt tot vervanging, dus netwerksegmentatie, monitoring en een webapplicatiefirewall vóór een verouderend systeem kunnen aan de norm voldoen terwijl het systeem eronder precies blijft zoals het is. Artikel 21(1) zegt dat bijna met zoveel woorden, door maatregelen te eisen die passend zijn bij het risico, "rekening houdend met de stand van de techniek en, in voorkomend geval, relevante Europese en internationale normen, alsook met de kosten van de uitvoering". Overweging 81 legt uit dat die evenredigheid bestaat om te voorkomen dat een onevenredige financiële en administratieve last wordt opgelegd. Op de vraag welke strategische opties er zijn zodra een securityteam een kwetsbaar systeem tegen het einde van de ondersteuning heeft gemarkeerd, telde Kishan er minstens zes, wat het 6R-framework we published last year. The three he sees most often are refactoring to a supported long-term version, rebuilding from scratch while honouring every contract the old system holds, and replacing it with a commercial or SaaS product. Each one fails on a different constraint: refactoring and rebuilding both need planning and engineering capacity, rebuilding adds the complexity of reproducing undocumented behaviour, and replacing needs budget.

A legacy system does not automatically need improving. The fourth route is the one nobody sells, and Kishan raised it before any of the others. Sometimes the correct answer is to cut a system off from everything around it and let it run. Systems built in the seventies and eighties are still in production on contained machines with no contact with the outside world, and the risk they carry does not justify touching them. What changes the calculation is exposure. A public-facing system is visible to everyone, the attack surface is real, and that is where the duty of care starts to bite. The honest version of this advice is uncomfortable to give, because isolation looks like inaction on a roadmap while being exactly the proportionate measure the law is asking for.

The duty of care starts with an inventory almost nobody has. Article 21(2)(i) requires asset management alongside human resources security and access control policies, and the supervisor's stated approach is to test the duty of care by asking whether an organization has mapped its risks and taken matching measures. That makes the inventory the entry point to the entire assessment. Kishan's view is that a complete overview has always been out of reach for any organization with a varied application landscape, and that the name shadow IT has existed for years precisely because people build outside managed IT to get their work done. What changed is the consequence. Someone running something on the side is now a compliance failure the organization does not know it has, and the repercussions land at management level. One provision sharpens this further. Article 11 allows the CSIRTs to carry out proactive non-intrusive scanning of publicly accessible systems belonging to essential and important entities, to detect vulnerable or insecurely configured ones. The supervisor may map an organization's landscape from the outside before the organization has mapped it from the inside.

Anyone with a work laptop can create an asset before lunch. Asked directly whether NIS2 is a quiet killer for vibe coding inside organizations, Kishan's answer was that it depends on who provides the tooling. Right now anyone can open a Claude or ChatGPT session and build whatever they want, with nobody knowing what data passes through the result. He gave his own example. He could clone the company project management tool onto a free Vercel plan, no credit card required, and load in the legacy ticket archive, which holds screenshots and production data. That puts the organization in violation straight away. His working definition of an asset is broader than most people expect. Anything created in a company environment is an asset of that company, whether or not it holds relevant data, because an asset is something the company controls. That includes a trial account spun up on a work laptop. The duty of care requires asset management and never defines an asset, so the gap gets filled by whoever is doing the filling. The constructive answer is for the IT organization to provide a company platform where people can build these things and where the people managing IT keep oversight and governance of what gets built.

If an agent wrote the code, the responsibility does not move. The obligation sits with the entity itself, wherever the code came from, which means an organization develops a network and information system the moment anyone puts generated code into production. Kishan is direct about where that lands. A company is ultimately run by people, so humans stay responsible for whatever the agents produce, and an organization detached from the process does not even know which problems exist. Setting one agent to check another inherits the same limitation, because the checking agent only looks for what it was told to look for, and without the right guardrails it will not find security issues on its own unless it was built for that. Eli5 ships with AI daily, and the way we keep it defensible is to keep the work scoped and stay in control of it. Other teams queue tickets, let the loop run and never read the output, which leaves the organization unable to describe its own exposure. Industry research on AI-generated code consistently finds a meaningful share of it carrying vulnerabilities from the OWASP Top 10. The counterweight belongs here too, and Kishan raised it himself. Humans write bugs, plenty of incidents trace back to code a person wrote and reviewed, and a reviewer can miss what an agent would have caught. This is not a clean line.

Supply chain security is the subject no organization can fully discharge. Article 21(2)(d) makes supply chain security one of the ten mandatory subjects, and Article 21(3) requires entities to take into account the vulnerabilities specific to each direct supplier and the overall quality of their products and cybersecurity practices, including their secure development procedures. Recital 85 names software editors explicitly. The mechanism Kishan described is the one the industry has watched repeatedly. A dependency maintainer or their publishing token gets compromised, an infected version ships, and everything downstream that pulled the update inherits the compromise. An organization can write secure code and still be exposed through software it did not write, and in modern web development nobody depends on nobody.

The link to software modernization

The Act does not require modernization, and reading it as a modernization mandate leads to the wrong first move. What it requires is that an organization knows what it runs, has judged the risk each system carries, and can substantiate why the measures it chose are appropriate. The reasoning is supervised alongside the outcome. That puts the inventory and the risk assessment ahead of any migration plan, and it explains why organizations that start by scoping a replacement often cannot answer the supervisor's first question.

It also changes what a modernization business case has to look like. Article 20 requires management bodies to approve the cybersecurity risk-management measures, to oversee their implementation, and it makes them liable for the entity's infringements. It also requires board members to follow training so they can identify risks and assess the measures and their impact on the services the entity provides. The Dutch implementation goes further, adding a deadline for board members to reach that level of knowledge along with a certificate evidencing the training. Enforcement reaches individuals: for essential entities the supervisor can request that a court temporarily prohibit a person at chief executive or legal representative level from exercising managerial functions. Technical debt that used to live in an engineering backlog now has to be written in a form a director can sign, with the risk stated as an effect on service continuity that a board can actually weigh.

The pattern underneath is one we keep arriving at. In our review of Meta's AI-tweede brein de overdraagbare les was dat de agentlaag het eenvoudige deel is en dat de jarenlange inspanning om systemen bereikbaar te maken de tijd en het geld opslokt. In onze beschouwing over ter plaatse gedetacheerde ingenieurs was de test die telde of een organisatie het geheel nog kan bedienen zodra de specialisten vertrekken. De Cyberbeveiligingswet stelt een variant van dezelfde vraag. Een organisatie die niet kan aangeven wat er draait, wie het onderhoudt en wat er gebeurt wanneer de leverancier verdwijnt, heeft tegelijk een operationeel en een compliancevraagstuk, en aan slechts een van beide hangt een datum.

Afsluitende opmerkingen

Het stuk van Law & More is goed geschreven en juridisch degelijk, en voor een bestuur dat zijn positie wil bepalen doet het zijn werk. Wie het naast de wettekst legt, stuit op een punt dat het benoemen waard is. De opsomming van de verplichte zorgplichtonderwerpen reduceert het onderwerp aanschaf, ontwikkeling en onderhoud tot louter kwetsbaarhedenbeleid, waarmee de eerste helft ervan wegvalt, en laat beveiliging van personeel, beleid inzake toegangsbeheer en beheer van bedrijfsmiddelen volledig buiten beschouwing. Dat zijn juist de twee onderwerpen die iets zeggen over de staat van het softwarelandschap van een organisatie. Wat overblijft is een lijst die leest als beleid, procedures en meervoudige authenticatie, en dat alles kan worden geregeld zonder ooit naar de onderliggende systemen te kijken.

Dit verdient een zorgvuldige formulering, want het punt is structureel en heeft niets te maken met een enkel kantoor. De compliancesamenvatting is de versie die het bestuur leest, en de samenvattingen die in omloop zijn laten consequent de inventarisatieplicht weg. Een organisatie die met een van die samenvattingen werkt, kan de deadline halen met een verdedigbare beleidsmap en geen enkel idee van wat er draait.

Twee bewegingen zijn beter te vermijden. Wachten op de gedetailleerde technische eisen is de eerste, want die worden overgelaten aan een nadere regeling die op de dag van inwerkingtreding van de wet niet bestaat, terwijl de risico-inventarisatie met of zonder die eisen het startpunt van de beoordeling vormt. Een compliancedocument kopen in plaats van een inventarisatie is de tweede, en dat zal ruimschoots worden aangeboden.

Waar te beginnen

Weten wat er draait, wie het onderhoudt en wat er gebeurt wanneer een leverancier verdwijnt, is het eerste op te leveren resultaat, en juist dat kunnen de meeste organisaties niet op korte termijn produceren. Onze moderniseringsassessment brengt het applicatielandschap in kaart, scoort elk systeem op blootstelling en onderhoudbaarheid, en levert de onderbouwing die de zorgplicht vraagt, in taal die een bestuur kan goedkeuren. Het geeft ook antwoord op de vraag die de wet openlaat: of een bepaald systeem moet worden gerefactord, herbouwd, vervangen of bewust ongemoeid gelaten.

Vragen waar we telkens op terugkwamen

Valt mijn organisatie onder de Cyberbeveiligingswet?

Dat hangt af van sector, omvang en groepsstructuur, en het antwoord moet worden bepaald zonder op een kennisgeving te wachten. De sectortoets loopt langs de achttien aangewezen sectoren in de twee bijlagen bij NIS2. De omvangtoets begint bij vijftig medewerkers of tien miljoen euro omzet of balanstotaal. De uitzondering die het vaakst over het hoofd wordt gezien is de groepsoptelling: de mkb-definitie in Aanbeveling 2003/361/EG omvat partnerondernemingen en verbonden ondernemingen, waardoor een dochteronderneming met dertig medewerkers binnen een grotere groep voor dit doel geen mkb-onderneming is. Verschillende categorieën vallen ongeacht hun omvang onder de wet, en een aanwijzing kan ook een organisatie meetrekken wier diensten op nationaal of regionaal niveau kritiek zijn. De RDI publiceert een zelftest voor sectoren onder toezicht.

De technische regels zijn nog niet gepubliceerd. Nu investeren of wachten?

Het werk kan nu al beginnen, want het ontbrekende onderdeel staat dat niet in de weg. De gedetailleerde eisen worden overgelaten aan een nadere regeling die bij inwerkingtreding van de wet niet bestaat. Wat al volledig geldt, is de plicht om risico's te identificeren, proportionele maatregelen te nemen en de afweging te onderbouwen, en het door de toezichthouder genoemde startpunt is of een organisatie haar risico's in kaart heeft gebracht. Een inventarisatie en een risicobeoordeling behouden hun waarde, wat de uiteindelijke technische norm ook bepaalt, en geen van beide is onder tijdsdruk snel te produceren.

Wat moet het bestuur daadwerkelijk doen?

Het bestuur moet de maatregelen goedkeuren, begrijpen en beide kunnen aantonen. Op grond van artikel 20 van NIS2 keurt het bestuursorgaan de maatregelen voor het beheer van cyberbeveiligingsrisico's goed, ziet het toe op de uitvoering ervan en kan het aansprakelijk worden gesteld voor inbreuken van de entiteit. Bestuursleden zijn verplicht opleiding te volgen zodat zij risico's kunnen identificeren en de maatregelen en de impact daarvan op de geleverde diensten kunnen beoordelen. De Nederlandse implementatie voegt daar een termijn aan toe waarbinnen dat kennisniveau moet zijn bereikt, plus een certificaat dat de opleiding aantoont. Bij essentiële entiteiten kan de toezichthouder verder gaan en de rechter verzoeken een bestuurder of wettelijke vertegenwoordiger tijdelijk te verbieden leidinggevende functies uit te oefenen.

Wij bouwen software voor een organisatie die binnen de reikwijdte valt en zijn zelf te klein om eronder te vallen. Raakt dit ons?

Ja, het bereikt leveranciers via het contract met de klant en niet via de wet zelf. Artikel 21, lid 3, verplicht entiteiten rekening te houden met de specifieke kwetsbaarheden van elke directe leverancier en met de algehele kwaliteit van hun producten en cyberbeveiligingspraktijken, met inbegrip van hun procedures voor veilige ontwikkeling, en overweging 85 noemt softwareleveranciers expliciet. Omdat uitbesteding de aansprakelijkheid van de klant niet verplaatst, gaan klanten om bewijs vragen dat zij kunnen auditen: auditrechten in het contract, een gedocumenteerd kwetsbaarhedenbeleid met reactietijden, en meldingsafspraken die snel genoeg zijn om hun eigen 24-uursklok te ondersteunen, wat in de praktijk neerkomt op acht tot twaalf uur voor de leverancier. Bij openbare aanbestedingen geldt helemaal geen omvangsdrempel.

Wat noteren we als grondoorzaak wanneer het eerlijke antwoord is dat het systeem vijftien jaar oud is?

Noteer precies die zin, als die klopt. Het eindverslag op grond van artikel 23 moet het type dreiging of de grondoorzaak beschrijven die het incident waarschijnlijk heeft veroorzaakt, samen met de toegepaste en de lopende mitigerende maatregelen. Een organisatie die het risico heeft gedocumenteerd, de opties heeft afgewogen en heeft vastgelegd waarom voor compenserende maatregelen is gekozen, beschikt over een verdedigbaar dossier. Een organisatie die die beoordeling nooit heeft gemaakt, dient een incidentmelding in die tegelijk dient als bewijs van een tekortkoming in de zorgplicht, wat een materieel slechtere positie is dan de technische schuld zelf.

Volledige video-aflevering

De eerste stap om de moderniseringsreis te starten

Softwaremodernisering en architecturale herbouw vormen de kern van Eli5. Wij lossen complexiteit op en leveren directe bedrijfswaarde door te focussen op pragmatische, cloud-native transities.

Voordat de keuze wordt gemaakt tussen het inkapselen van een legacysysteem, de aanschaf van een nieuw SaaS-product of het inzetten van AI om maatwerktools te bouwen, is volledig zicht op het huidige technologielandschap essentieel.

Is een gratis brainstorm over de legacy stack interessant? Dat is de essentiële eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.