NIS2-gereedheid voor DevSecOps betekent bewijzen dat uw softwareontwikkelingsproces over werkende beveiligingscontroles beschikt, en niet alleen over geschreven beleid. Vóór juli 2026 moeten Nederlandse bedrijven die binnen de scope van de Cyberbeveiligingswet vallen, bewijsmateriaal leveren voor Artikel 21-controles, zoals veilige ontwikkeling, beveiliging van de toeleveringsketen, toegangsbeheer en effectiviteitstesten. Voor engineeringteams komt het praktische bewijs meestal voort uit SAST, SCA, CI/CD-toegangsbeoordelingen, logs van kwetsbaarheidsherstel en verslagen van incidentrespons.
Voor Nederlandse engineeringteams vereist NIS2 een gedocumenteerde manier om aan te tonen dat beveiliging is ingebouwd in de manier waarop code wordt geschreven, getest, vrijgegeven en onderhouden.
Een DevOps-team dat al code-reviews, dependency-scans en gecontroleerde releases uitvoert, is wellicht dichterbij dan het denkt. Het gat is vaak het auditspoor: wie heeft de bevinding beoordeeld, wanneer is deze opgelost, welke release heeft deze gesloten en waar is het bewijsmateriaal opgeslagen.
Voor bedrijven die een breder DevSecOps-capaciteitsplan nodig hebben, lees onze DevSecOps teamwervingsgids voor EU-bedrijven.
TL;DR:
- NIS2-gereedheid voor DevSecOps betekent dat uw softwareleveringsproces kan bewijzen dat Artikel 21-controles actief zijn, beoordeeld en gecorrigeerd.
- Voor Nederlandse bedrijven die zich voorbereiden op de Cyberbeveiligingswet rond juli 2026, is de kern van het bewijsmateriaal SAST/SCA-output, toegangsbeoordelingen, herstelverslagen, dependency-beheer en tijdlijnen voor incidentrespons.
Wat NIS2 Artikel 21 vereist van uw softwareontwikkelingsproces
NIS2 Artikel 21 vereist dat essentiële en belangrijke entiteiten technische, operationele en organisatorische maatregelen nemen om cyberbeveiligingsrisico’s te beheersen. Voor softwareontwikkelingsteams, zijn de meest relevante clausules Artikel 21(2)(d), 21(2)(e), 21(2)(f) en 21(2)(i).
Artikel 21(2)(d) behandelt de beveiliging van de toeleveringsketen. In een ontwikkelingscontext betekent dit dat uw team moet weten welke bibliotheken van derden, open-source dependencies, clouddiensten en tools voor softwareontwikkeling het risico van uw product beïnvloeden.
Artikel 21(2)(e) behandelt de beveiliging bij de verwerving, ontwikkeling en het onderhoud van netwerk- en informatiesystemen. Voor engineeringteams sluit dit direct aan bij veilige SDLC-controles: code-review, SAST, DAST, kwetsbaarheidsafhandeling en veilig onderhoud na release.
Artikel 21(2)(f) behandelt beleid en procedures om te beoordelen of maatregelen voor cyberbeveiligingsrisicobeheer werken. Alleen beleid is niet genoeg. Uw team heeft testverslagen, scancadans, bewijs van hertesten en bewijs dat kritieke bevindingen worden gevolgd tot sluiting nodig.
Artikel 21(2)(i) behandelt de beveiliging van personeel, toegangscontrole en activabeheer. Voor DevSecOps, betekent dit least-privilege toegang tot repositories, CI/CD-pijplijnen, cloudomgevingen en productiesystemen, met gedocumenteerde toegangsbeoordelingen.
| NIS2 Artikel 21 sub-clausule | Wat het betekent voor uw dev-team | Vereist bewijsmateriaal |
|---|---|---|
| 21(2)(d) – Beveiliging van de toeleveringsketen | Beveiligingsscreening van bibliotheken van derden, open-source dependencies en leveranciers van ontwikkelingstools | Software Composition Analysis-logs, dependency-inventaris, verslagen van beveiligingsbeoordelingen van leveranciers |
| 21(2)(e) – Veilige ontwikkeling en onderhoud | Beveiligingscontroles ingebed in de ontwikkelingslevenscyclus: code-review, SAST, DAST en penetratietesten vóór belangrijke releases | SAST-scanrapporten, DAST-rapporten, bevindingen van penetratietesten, herstelverslagen, bewijs van hertesten |
| 21(2)(f) – Beoordeling van effectiviteit | Regelmatig testen of controles daadwerkelijk werken, en niet alleen beleid dat stelt dat ze bestaan | Kwartaal-auditspoor, penetratietestrapport met hertest, cadanslog van kwetsbaarheidsscans |
| 21(2)(i) – Toegangscontrole | Least-privilege toegang tot CI/CD-pijplijnen, code-repositories en productieomgevingen | Kwartaalverslagen van toegangsbeoordelingen, RBAC-beleidsdocumentatie, auditlog van offboarding |
Als uw compliance-team Artikel 21 nog aan het vertalen is naar controlegebieden, verken dan NIS2 Artikel 21 risicobeheersmaatregelen, waarin de volledige set vereisten van Artikel 21 wordt uitgelegd.
De Cyberbeveiligingswet: wat er verandert voor Nederlandse bedrijven in juli 2026
De Cyberbeveiligingswet is de Nederlandse wet die de EU NIS2-richtlijn omzet in nationale wetgeving. Er wordt verwacht dat deze de huidige Wet beveiliging netwerk- en informatiesystemen zal vervangen zodra deze in werking treedt.
Voor Nederlandse bedrijven is de praktische verandering dat meer organisaties hun zorgplicht, gereedheid voor incidentrapportage en registratie moeten aantonen. De exacte scope hangt af van de sector, grootte en of het bedrijf is geclassificeerd als een essentiële of belangrijke entiteit.
Essentiële entiteiten omvatten organisaties in sectoren zoals energie, transport, bankwezen, infrastructuur voor de financiële markt, gezondheidszorg, drinkwater, digitale infrastructuur, beheer van ICT-diensten, overheid en ruimtevaart.
Belangrijke entiteiten omvatten sectoren zoals postdiensten, afvalbeheer, productie, levensmiddelen en digitale aanbieders. Software- en IT-dienstverleners kunnen binnen de scope vallen wanneer ze voldoen aan de relevante criteria voor grootte en sector, of wanneer ze diensten verlenen die klanten in essentiële sectoren ondersteunen.
Voor overtredingen van Artikel 21 en Artikel 23, stelt NIS2 boetedrempels vast van ten minste EUR 10 miljoen of 2% van de wereldwijde jaaromzet voor essentiële entiteiten, afhankelijk van wat hoger is. Voor belangrijke entiteiten is de drempel ten minste EUR 7 miljoen of 1,4% van de wereldwijde jaaromzet, afhankelijk van wat hoger is.
Voor engineering- en DevOps-teams is de boete niet het belangrijkste punt. Het belangrijkste punt is het verzoek om bewijsmateriaal dat voorafgaat aan een audit, vragenlijst van klanten of toezichthoudende toetsing: “Toon aan dat uw ontwikkelingscontroles actief waren, beoordeeld en gecorrigeerd wanneer er bevindingen verschenen.” Dat betekent dat de Cyberbeveiligingswet zowel een documentatieprobleem als een beveiligingstoolingprobleem creëert. Een werkende pijplijn die geen auditspoor achterlaat, zal moeilijk te verdedigen zijn.
Niet zeker of uw DevSecOps-proces voldoet aan NIS2 Artikel 21? Sunbytes voert een gestructureerde NIS2-gereedheidscontrole uit op uw huidige ontwikkelpijplijn, waarbij uw bestaande controles in kaart worden gebracht aan de hand van Artikel 21-verplichtingen en een herstelstappenplan met bewijsvereisten wordt opgesteld. ISO 27001 gecertificeerd. Alle opdrachten kunnen worden uitgevoerd onder een ondertekende DPA. Controleer uw NIS2-gereedheid.
Hoe DevSecOps-controles in kaart worden gebracht aan de hand van NIS2 Artikel 21-verplichtingen
NIS2 noemt DevSecOps niet bij naam. Maar Artikel 21(2)(d), 21(2)(e), 21(2)(f) en 21(2)(i) beschrijven de outputs die een volwassen DevSecOps-pijplijn zou moeten produceren: dependency-controle, controles voor veilige ontwikkeling, toegangsbeheer en herhaalbare effectiviteitstesten.
De controle zelf is slechts de helft van de vereiste. De andere helft is bewijs.
| DevSecOps-controle | Brengt NIS2 Artikel 21 in kaart | Bewijsformaat voor audit |
|---|---|---|
| SAST in CI/CD-pijplijn | 21(2)(e) – veilige ontwikkeling | Scanrapport per release, bevindingenlijst met ernst, herstelstatus |
| DAST vóór release | 21(2)(e) – veilige ontwikkeling | Testrapport met aanvalspaden, bewijs van hertesten dat bevindingen zijn gesloten |
| Software Composition Analysis voor dependencies | 21(2)(d) – beveiliging van de toeleveringsketen | Auditlog van dependencies, CVE-tracking, verslagen van patching-SLA |
| Penetratietesten, jaarlijks of per belangrijke release | 21(2)(f) – beoordeling van effectiviteit | Volledig penetratietestrapport, herstelstappenplan, bewijs van hertesten per kritieke bevinding |
| Least-privilege toegangscontrole in pijplijn en repositories | 21(2)(i) – toegangscontrole | Kwartaalverslag van toegangsbeoordelingen dat aantoont wie toegang heeft en het goedkeuringsspoor |
| Geautomatiseerde geheimen-scan in CI/CD | 21(2)(e) – veilige ontwikkeling | Scanlogs, documentatie van beleid voor geen-geheimen-in-repo |
| Gedocumenteerde incidentrespons-procedure met benoemde rollen | 21(2)(b) – incidentafhandeling | Incidentresponsplan, tijdlijn van detectie-tot-melding, Artikel 23 log |
Als uw pijplijn al SAST en dependency-scans uitvoert met gedocumenteerde herstel-SLA’s, beschikt u over de bewijsbasis voor delen van Artikelen 21(2)(d) en 21(2)(e). Het gat is meestal niet de tooling. Het gat is of de output wordt bewaard, beoordeeld en gekoppeld aan eigenaarschap.
Een SAST-bevinding die verschijnt in een build-log maar nooit een ticket wordt, is zwak bewijs. Een SAST-bevinding die wordt gelogd, toegewezen, op risico gerangschikt, opgelost, hergetest en gekoppeld aan een release-verslag is bruikbaar bewijs.
Hetzelfde geldt voor dependency-scanning. Een dependency-tool die CVE’s markeert is nuttig, maar bewijs voor Artikel 21 heeft de volgende stap nodig: welke CVE’s zijn geaccepteerd, welke zijn opgelost, welke zijn uitgesteld en wie heeft het besluit goedgekeurd.
Voor degenen die de pijplijnmechanica achter deze controles nodig hebben, lees onze DevSecOps pijplijngids. Hierin wordt uitgelegd hoe CI/CD, geautomatiseerde beveiligingscontroles en release-gates samenwerken.
Hoe het auditbewijsspoor eruitziet
Een NIS2-bewijsspoor moet vier vragen beantwoorden:
- Welke controle bestaat er?
- Wanneer is het uitgevoerd?
- Wat is er gevonden?
- Wat is er veranderd naar aanleiding van de bevinding?
Voor een DevSecOps-team bevindt het bewijsspoor zich meestal in verschillende systemen: CI/CD-logs, dashboards van beveiligingstools, ticketsystemen, verslagen van toegangsbeoordelingen, documentatie van incidentrespons en release-opmerkingen. Het compliancerisico ontstaat wanneer die systemen niet op elkaar aansluiten.
Een praktisch bewijspakket voor softwareontwikkeling moet het volgende bevatten:
| Bewijsgebied | Minimaal nuttig verslag | Eigenaar |
|---|---|---|
| CI/CD-beveiligingstesten | Resultaten van SAST, DAST en geheimen-scanning gekoppeld aan releases | DevSecOps engineer |
| Dependency-beveiliging | SCA-rapporten, CVE-triage en patching-verslagen | DevOps Lead |
| Toegangscontrole | Driemaandelijkse toegangsbeoordeling voor repositories, CI/CD en productie | IT Manager |
| Kwetsbaarheidsafhandeling | Bevindingenregister, herstelstatus, hertestverslag | CISO of Security Lead |
| Incidentrespons | Benoemde rollen, escalatieroute, tijdlijn van detectie-tot-melding | CISO of IT Director |
| Beveiliging van leveranciers en tools | Beoordelingsnota’s van leveranciers, inventarisatie van tools, dependency-beleid | Engineering Manager |
De auditvraag is zelden: “Gebruikt u SAST?” Het is waarschijnlijker: “Toon bewijs aan dat uw SAST-controle de afgelopen 12 maanden actief was, en laat zien hoe bevindingen met een hoge ernst werden afgehandeld.”
Hetzelfde geldt voor toegangscontrole. Een op rollen gebaseerd toegangsbeleid is nuttig, maar het sterkere bewijs is een driemaandelijks beoordelingsverslag: wie had toegang, wat is er veranderd, wie heeft het goedgekeurd en welke accounts zijn verwijderd.
Bewijs voor incidentrespons heeft een aparte tijdlijn nodig. Artikel 23 vereist een vroege waarschuwing binnen 24 uur nadat men zich bewust is geworden van een significant incident en een gedetailleerdere incidentmelding binnen 72 uur. Uw engineeringproces moet al definiëren wie de technische impact bevestigt, wie het incidentverslag opent, wie indicatoren van compromis verzamelt en wie het meldingstraject goedkeurt.
Stappen die u vóór juli 2026 moet nemen
- Breng uw huidige DevSecOps-controles in kaart aan de hand van Artikel 21(2)(d), 21(2)(e), 21(2)(f) en 21(2)(i).
Eigenaar: CISO of DevOps Lead.
Output: één gap-analysedocument dat laat zien welke controles bestaan, waar het bewijsmateriaal is opgeslagen en waar de hiaten zitten.
- Stel een driemaandelijkse cadans voor toegangsbeoordelingen vast voor CI/CD-pijplijnen, code-repositories en productieomgevingen.
Eigenaar: IT Manager.
Output: verslag van toegangsbeoordeling met naam van de beoordelaar, datum van goedkeuring, verwijderde accounts en aantekeningen over uitzonderingen.
- Verifieer SAST- en SCA-tooling in uw CI/CD-pijplijn.
Eigenaar: DevSecOps engineer.
Output: scanrapporten opgeslagen per release, met bevindingen toegewezen aan tickets en bewaard gedurende ten minste 12 maanden.
- Plan een penetratietestsessie als er de afgelopen 12 maanden geen geldige test is voltooid.
Eigenaar: CISO.
Output: penetratietestrapport, herstelstappenplan en bewijs van hertesten voor kritieke en hoge bevindingen.
- Documenteer uw incidentrespons-procedure voor ontwikkelings- en productiesystemen.
Eigenaar: CISO of IT Director.
Output: benoemde rollen, escalatiepad, ernstcriteria en tijdlijn van detectie-tot-melding.
- Beoordeel uw toeleveringsketen voor ontwikkeling.
Eigenaar: DevOps Lead.
Output: dependency-inventaris, lijst met ontwikkelingstools, beoordelingsnota’s voor beveiliging van leveranciers en een beleid voor het goedkeuren van nieuwe dependencies.
Deze zes stappen leveren de bewijsbasis op die Artikel 21-naleving vereist. Door vóór juli 2026 te beginnen, heeft uw team de tijd om de cadans voor toegangsbeoordelingen op te bouwen, testen te plannen en risicovolle bevindingen te sluiten voordat een klant of toezichthouder om bewijs vraagt.
Na de gap-analyse ontdekken sommige teams dat de ontbrekende controle niet een tool is, maar eigenaarschap. Dit is waar een speciale DevSecOps-rol noodzakelijk wordt.
Hoe Sunbytes NIS2-gereed DevSecOps ondersteunt
NIS2 Artikel 21 vereist bewijs dat de controles die uw team al uitvoert, of zou moeten uitvoeren, gedocumenteerd, getest en effectief zijn. Het gat tussen een functionerende DevSecOps-pijplijn en een NIS2-gereede pijplijn is meestal een auditspoor, geen herbouw van de tooling.
Sunbytes helpt Nederlandse bedrijven om dat bewijsgat om te zetten in een herstelstappenplan. Onze CyberSecurity Solutions brengen CI/CD-controles, toegangsbeoordelingen, kwetsbaarheidsafhandeling en verslagen van incidentrespons in kaart voor Artikel 21-verplichtingen van de NIS2. De Digital Transformation Solutions helpen engineeringteams bij het implementeren van de vereiste leveringswijzigingen in de pijplijn, terwijl Accelerate Workforce Solutions gescreende DevSecOps- of QA-capaciteit kunnen toevoegen wanneer eigenaarschap ontbreekt. ISO 27001 gecertificeerd. Opdrachten kunnen worden uitgevoerd onder een ondertekende DPA met documentatie die klaar is voor audit.Voor NIS2-gereed DevSecOps is het doel een ontwikkelingsproces dat kan bewijzen wat het controleert: scanresultaten, toegangsbeoordelingen, herstelverslagen, incidenttijdlijnen en bewijseigenaren. Sunbytes helpt Nederlandse bedrijven dat werk te structureren op het gebied van levering, beveiliging en capaciteit. Vraag een NIS2-gereedheidscontrole aan voor uw DevSecOps-pijplijn.
FAQs
NIS2 kan van toepassing zijn als uw Nederlandse softwarebedrijf actief is in een gedekte sector, kwalificeert als een middelgrote of grote entiteit, digitale diensten verleent of klanten in essentiële sectoren ondersteunt. Software- en IT-dienstverleners moeten controleren of ze vallen onder de criteria voor digitale aanbieders, managed service providers of toeleveringsketens. Gebruik de Nederlandse NIS2-zelfevaluatietool voordat u een definitief besluit neemt over de scope.
NIS2 is de EU-richtlijn. De Cyberbeveiligingswet is de Nederlandse wet die de NIS2 in Nederland implementeert. Voor Nederlandse bedrijven bepaalt de Cyberbeveiligingswet hoe de NIS2-verplichtingen lokaal van toepassing zijn, inclusief registratie, toezicht en handhaving.
NIS2 vereist DevSecOps niet bij naam. Het vereist maatregelen voor cyberbeveiligingsrisicobeheer, waaronder beveiliging van de toeleveringsketen, veilige ontwikkeling, kwetsbaarheidsafhandeling, effectiviteitstesten en toegangscontrole. DevSecOps is een praktische manier voor softwareteams om het bewijsmateriaal achter die vereisten te leveren.
De meest relevante controles zijn SAST, DAST, softwareontledingsanalyse (SCA), geheimen-scanning, penetratietesten, least-privilege toegang en procedures voor incidentrespons. Deze controles worden in kaart gebracht voor Artikel 21(2)(d), 21(2)(e), 21(2)(f), 21(2)(i) en Artikel 21(2)(b).
Nee. Een SAST-scan is nuttig bewijsmateriaal voor veilige ontwikkeling, maar op zichzelf niet voldoende. Uw team heeft ook herstelverslagen, afhandeling van de ernst, bewijs van hertesten, dependency-beheer, toegangsbeoordelingen en bewijs nodig dat bevindingen worden gevolgd tot ze zijn opgelost.
Een gerichte nulmeting kan in drie tot vier weken worden opgebouwd als uw pijplijn al over beveiligingstools en toegangsverslagen beschikt. Herstel kan langer duren als penetratietesten, toegangsbeoordelingen of dependency-beheer ontbreken. De items die het langst duren, zijn meestal de planning van de testen en het opbouwen van een driemaandelijkse cadans voor beoordelingen.
Bereid een overzicht van de controles voor, samen met CI/CD-scanbewijs, een inventaris van dependencies, een register van kwetsbaarheden, verslagen van toegangsbeoordelingen, een tijdlijn van de incidentrespons, een penetratietestrapport en een herstelstappenplan. Het bewijsmateriaal moet laten zien welke controle er bestaat, wanneer deze is uitgevoerd, wat er is gevonden en wat er is veranderd naar aanleiding van de bevinding.
De CISO of IT-directeur moet de eigenaar zijn van het complianceresultaat, maar de DevOps Lead of Head of Engineering moet de eigenaar zijn van het technische bewijsmateriaal. NIS2-gereedheid mislukt wanneer compliance de eigenaar is van het beleid, maar engineering de eigenaar is van de systemen en geen van beide teams de eigenaar is van het bewijsspoor.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
