NIS2 Artikel 21(2)(e): Veilige ontwikkeling en kwetsbaarhedenbeheer voor MSP's

Een logging-library die uw klant nooit bewust heeft gekozen, nooit expres heeft geïnstalleerd en niet uit het hoofd kan benoemen, publiceert op een vrijdagmiddag een kritieke CVE. Ze zit drie lagen diep in een monitoringagent die u achttien maanden geleden voor die klant hebt uitgerold. De klok die telt, is niet die van de advisory van de leverancier — het is de klok die een auditor start als hij vraagt hoe snel u het wist, hoe snel u handelde en waar het bewijs is.

Dat scenario is precies wat NIS2 Artikel 21(2)(e) wil voorkomen. Het is de maatregel die de meeste consultants overslaan omdat hij klinkt als een probleem voor ontwikkelaars. Dat is hij niet. Het is een probleem van toeleveringsketen en onderhoud, en voor MSP's is het een van de moeilijkst aantoonbare maatregelen.

Artikel 21(2)(e) dekt alles wat u bouwt, koopt en onderhoudt

De tien risicomaatregelen in Artikel 21(2) vormen de ruggengraat van NIS2-compliance. De meeste aandacht gaat naar de zichtbare — MFA, back-ups, incidentmelding. Maatregel (e) is stiller en breder: "beveiliging bij het verwerven, ontwikkelen en onderhouden van netwerk- en informatiesystemen, met inbegrip van de respons op en bekendmaking van kwetsbaarheden."

Lees het langzaam. Drie werkwoorden — verwerven, ontwikkelen, onderhouden — plus een doorlopende plicht om kwetsbaarheden aan te pakken en te melden. Het geldt of u nu code schrijft, een platform doorverkoopt, of gewoon de software van iemand anders gepatcht houdt. Er is geen uitzondering voor "wij ontwikkelen niets." Als u de systemen van een klant onderhoudt, bent u eigenaar van de onderhoudshelft van deze maatregel.

Artikel 21 — 10 NIS2 Cybersecuritymaatregelen
🛡️
Artikel 21
10 Cybersecuritymaatregelen
📊Governance & Strategie
1Risicoanalyse & informatiebeveiligingsbeleid
6Effectiviteitsbeoordeling van beveiligingsmaatregelen
🚨Incidenten & Continuïteit
2Incidentafhandeling & melding
3Bedrijfscontinuïteit & disaster recovery
🔗Toeleveringsketen & Systemen
4Beveiliging van de toeleveringsketen
5Beveiliging bij de ontwikkeling van netwerk- en informatiesystemen
🔐Technische Beheersing
8Cryptografie & versleuteling
10Multi-factor authenticatie & veilige communicatie
👥Mensen & Middelen
7Cyberhygiëne & training
9HR-beveiliging & toegangscontrole

Voor het volledige overzicht van hoe (e) samenhangt met de andere negen maatregelen, zie onze uitleg van alle tien Artikel 21-maatregelen.

Wat "veilig verwerven, ontwikkelen en onderhouden" in de praktijk betekent

Splits de maatregel in de drie dingen die hij echt vraagt.

Verwerven betekent dat u software en leveranciers kiest met beveiliging als selectiecriterium, niet als bijzaak. Dat betekent gedocumenteerde leveranciersbeoordeling: volgt de leverancier veilige ontwikkelpraktijken, publiceert hij advisories, verplicht hij zich om kwetsbaarheden in zijn product te melden? Een regeltje "wij gebruiken betrouwbare leveranciers" overleeft geen audit.

Ontwikkelen betekent dat alles wat u bouwt — een klantportaal, een automatiseringsscript, een maatwerkintegratie — een veilige levenscyclus doorloopt. Veilige codeerstandaarden, code review, beveiligingstests vóór uitrol en een proces voor kwetsbaarheden die na go-live worden gevonden. U hebt geen SDLC-document van 40 pagina's nodig. U hebt een herhaalbaar proces nodig dat u kunt tonen.

Onderhoud is waar de meeste MSP's leven. Het betekent patchen, wijzigingsbeheer en een accurate inventaris bijhouden van wat waar draait. U kunt niet patchen wat u niet ziet, en u kunt niet bewijzen dat u patchte zonder registratie.

Bouwt u, of onderhoudt u alleen? De controls verschillen

De maatregel geldt voor iedereen binnen scope, maar het zwaartepunt verschuift afhankelijk van wat u doet. Gebruik de beslislogica hieronder om te bepalen welke controls het meeste auditrisico dragen voor uw operatie.

Is NIS2 van toepassing op uw organisatie?
1
Is uw organisatie actief in een essentiële of belangrijke sector (energie, transport, zorg, digitale infrastructuur, enz.)?
Ja▼
Nee▼
2
Heeft uw organisatie 50 of meer werknemers, of een jaarlijkse omzet van meer dan €10 miljoen?
✗
NIS2 is niet rechtstreeks van toepassing op uw organisatie.
Ja▼
Nee▼
✓
NIS2 is van toepassing op uw organisatie als essentiële of belangrijke entiteit.
3
Is uw organisatie een aanbieder van kritieke infrastructuur of een gekwalificeerde vertrouwensdienstverlener?
Ja▼
!
NIS2 kan van toepassing zijn op uw organisatie — raadpleeg juridisch advies om uw status te bevestigen.
1
Is uw organisatie actief in een essentiële of belangrijke sector (energie, transport, zorg, digitale infrastructuur, enz.)?
Ja ↓Nee →
2
Heeft uw organisatie 50 of meer werknemers, of een jaarlijkse omzet van meer dan €10 miljoen?
Ja ↓Nee →
3
Is uw organisatie een aanbieder van kritieke infrastructuur of een gekwalificeerde vertrouwensdienstverlener?
Ja ↓Nee →
✗
NIS2 is niet rechtstreeks van toepassing op uw organisatie.
✓
NIS2 is van toepassing op uw organisatie als essentiële of belangrijke entiteit.
!
NIS2 kan van toepassing zijn op uw organisatie — raadpleeg juridisch advies om uw status te bevestigen.
Van toepassing
Mogelijk van toepassing
Niet van toepassing

Als u alleen software van derden onderhoudt, zit uw blootstelling in de nauwkeurigheid van uw inventaris, patch-SLA's en wijzigingsregistratie. Ontwikkelt u iets klantgericht, voeg dan veilig coderen, code review en pre-release testen toe aan de lijst. Verkoopt u platforms van andere leveranciers door of bundelt u ze, dan worden uw verwervingscontrols — leverancierstoetsing en meldingsclausules — het eerste dat een auditor onderzoekt. Breng uw diensten eerlijk in kaart voordat u de controlset opbouwt.

Kwetsbaarhedenbeheer: intake, triage en patch-SLA's

Kwetsbaarhedenbeheer is een lus, geen project. Het heeft drie bewegende delen.

Intake is hoe kwetsbaarheden u bereiken — advisories van leveranciers, uw eigen scanning, pentests van derden en een kanaal waarlangs buitenstaanders een fout kunnen melden in iets dat u draait. Ontbreekt die laatste inbox, dan mist u een control die de richtlijn expliciet benoemt.

Triage is hoe u rangschikt wat binnenkomt. Ernst plus blootstelling plus exploiteerbaarheid, elke keer op dezelfde manier gescoord zodat twee engineers tot hetzelfde antwoord komen.

Herstel is de patch, gekoppeld aan een service-level-klok. NIS2 schrijft geen patchtermijnen voor, dus de markt heeft een de facto standaard aangenomen die afnemers nu in contracten opnemen: kritiek binnen 24–48 uur, hoog binnen 7 dagen, middel binnen 30 dagen, laag binnen 90 — met een gedocumenteerd uitzonderingsproces voor de gevallen waarin u echt niet op tijd kunt patchen. Dat uitzonderingsproces telt net zo zwaar als de SLA. Een auditor zoekt geen perfect dossier. Hij zoekt een verdedigbaar dossier.

De valkuil voor MSP's: u moet deze registratie per klant kunnen produceren, op het moment van de audit, op verzoek. Scanning die alleen in een dashboard leeft, is geen bewijs. Een gedateerd, exporteerbaar spoor wel.

Gecoördineerde bekendmaking van kwetsbaarheden en de EUVD

Uw eigen kwetsbaarheden aanpakken is de helft van de maatregel. De andere helft is bekendmaking — en NIS2 heeft daar een formeel kanaal voor gebouwd.

Onder Artikel 12 wijst elke lidstaat één CSIRT aan als coördinator voor een nationaal programma voor gecoördineerde bekendmaking van kwetsbaarheden (CVD). Dat CSIRT treedt op als vertrouwde tussenpersoon tussen degene die een fout meldt en de leverancier wiens product hem bevat. Het benadert de betrokken partijen, ondersteunt de melder en onderhandelt over bekendmakingstermijnen — ook in de lastige gevallen waarin één kwetsbaarheid producten in meerdere landen tegelijk raakt.

Dit alles wordt gevoed door de European Vulnerability Database (EUVD), beheerd door ENISA, die sinds januari 2024 een kwetsbaarhedenregister voert als officiële CVE Numbering Authority. Voor een MSP is de EUVD een tweede bron van waarheid naast advisories van leveranciers — en weten hoe u ermee werkt, hoort er nu bij. De praktische kant behandelen we in onze EUVD-gids voor MSP's.

De praktische les: u hebt een gepubliceerde manier nodig waarop iemand een kwetsbaarheid kan melden in een product of dienst die u exploiteert, en een besluit over hoe u meedoet aan het nationale CVD-proces. Beide zijn auditeerbaar. Geen van beide is optioneel als u binnen scope valt.

Wanneer de fout van een leverancier de aansprakelijkheid van uw klant wordt

Hier houdt maatregel (e) op abstract te zijn. Een kwetsbaarheid in het product van een leverancier blijft niet ingekapseld. Ze cascadeert — van de leverancier naar u, naar uw klant, naar diens klanten — en de toeleveringsketenverplichtingen van NIS2 (maatregel (d)) betekenen dat de aansprakelijkheid meereist.

NIS2-sanctie-escalatie — Voorbij de boete
!
Aanleiding
Non-compliance gedetecteerd of incident treedt op
Een toezichthouder identificeert een compliance-hiaat of een organisatie voldoet niet aan de NIS2-vereisten
Toezichthouders kunnen opleggen▼
Niet-financiële sancties
1
Nalevingsbevelen met bindende deadlines
2
Verplichte security-audits op eigen kosten
3
Publieke bekendmaking van overtredingen
4
Bindende instructies over specifieke beveiligingsmaatregelen
Escaleert naar▼
Operationele en persoonlijke gevolgen
1
Opschorting van certificeringen of vergunningen
2
Tijdelijk verbod op bestuursfuncties voor personen
3
Publieke benoeming van verantwoordelijke natuurlijke personen
Aanleiding
Niet-financieel
Operationeel / persoonlijk

Als een component die u hebt uitgerold een ongepatchte kritieke fout bevat en een klant wordt daardoor getroffen, is "de leverancier had het ons moeten zeggen" geen verweer. De richtlijn verwacht dat u die leverancier hebt beoordeeld, meldingsafspraken hebt gecontracteerd en een proces had om te handelen zodra de advisory kwam. Daarom zijn verwerving en kwetsbaarhedenbeheer één maatregel en niet twee — de zwakte komt binnen via wat u kocht en wordt beheerd via wat u daarna doet. Onze uitleg over toeleveringsketenbeveiliging behandelt de contractuele kant.

Het bewijs waar een auditor echt naar vraagt

Maatregel (e) wordt beoordeeld op papieren sporen, niet op intenties. Houd deze klaar, per klant waar relevant:

Een actuele software- en leveranciersinventaris, geen spreadsheet van vorig jaar. Leveranciersbeoordelingen die aantonen dat beveiliging een selectiecriterium was. Een patchbeleid met op ernst gebaseerde SLA's, plus de logs die bewijzen dat u ze haalde — en de uitzonderingsregistratie waar dat niet lukte. Wijzigingsbeheer dat elke wijziging aan een goedkeuring koppelt. Een intake- en meldingskanaal voor kwetsbaarheden dat bestaat en wordt bewaakt. En, als u iets ontwikkelt, veilige SDLC-notities: codeerstandaarden, reviewbewijs, resultaten van pre-release tests.

Niets hiervan is exotisch. Alles ervan is het verschil tussen een audit doorstaan en na een incident uitleggen waarom de registratie ontbreekt. Maatregel (f) — beoordelen of uw controls daadwerkelijk werken — ligt rechtstreeks boven op deze; zie onze audit-lus-gids voor hoe de twee samenhangen.

Begin met wat u kunt zien

De meeste MSP's doen al 60% van deze maatregel — ze patchen, ze houden wijzigingen bij, ze kiezen fatsoenlijke leveranciers. Het gat zit bijna altijd in het bewijs en het meldingskanaal, niet in het onderliggende werk. De snelste manier om uw specifieke gaten te vinden, is uw onderhouds- en verwervingscontrols te bekijken door de lens van Artikel 21(2)(e) en te markeren wat u vandaag aan een auditor zou kunnen overhandigen versus wat u met moeite bij elkaar zou moeten schrapen.

Wilt u dat gat voor u in kaart gebracht, voer dan een gratis NIS2 quick scan uit — die laat per maatregel precies zien waar uw houding op het gebied van veilige ontwikkeling en kwetsbaarhedenbeheer staat ten opzichte van de richtlijn.

Maatregel (e) is niet het meest opvallende onderdeel van NIS2. Het is het onderdeel dat het vaakst dun blijkt als een auditor eraan trekt, juist omdat het lijkt op andermans werk. Voor een MSP is het van u.