NIS2-cyberwet geldt vanaf augustus voor duizenden Nederlandse organisaties

De Eerste Kamer heeft dinsdag ingestemd met de Cyberbeveiligingswet en de Wet weerbaarheid kritieke entiteiten. Die eerste wet is de Nederlandse implementatie van de Europese NIS2-richtlijn. Dit houdt in dat ruim 8000 Nederlandse organisaties aan nieuwe cyberbeveiligingseisen moeten voldoen.

De wetten treden op 15 augustus in werking, meldt de Nationaal Coördinator Terrorismebestrijding en Veiligheid. Onder de Cyberbeveiligingswet moeten organisaties die essentiële of belangrijke diensten verlenen aan extra regels voldoen. Het gaat bijvoorbeeld om de energie-, drinkwater- en digitale-infrastructuursectoren.

Deze organisaties moeten zich registreren bij het Nationaal Cyber Security Centrum, maatregelen nemen om beveiligingsrisico's te beheren en 'significante incidenten' op tijd melden. De wet maakt het bestuur van een organisatie verantwoordelijk voor het beheren van cyberrisico's. Die bestuursleden moeten hier ook getraind voor zijn.

Wet kwetsbaarheid kritieke entiteiten geldt voor minder organisaties

Met de Wet weerbaarheid kritieke entiteiten wordt de Europese CER-richtlijn van kracht in Nederland. Deze wet geldt voor een stuk minder organisaties: 500. Ook deze organisaties zitten in belangrijke sectoren. Het doel van deze richtlijn is om de kritieke infrastructuur en economische activiteiten zoveel mogelijk te beschermen tegen dreigingen zoals cyberaanvallen, terrorisme, sabotage en natuurrampen, zegt de NCTV.

De Tweede Kamer ging in april akkoord met de Cyberbeveiligingswet. Nederland is daarmee veel te laat. De deadline om de NIS2-richtlijn om te zetten naar nationale wetgeving verliep in oktober 2024. Alleen België en Kroatië haalden die deadline.

Update, woensdag 8 juli – In het artikel stond aanvankelijk dat Nederland uitstel had gekregen voor het implementeren van de NIS2-wetgeving. Dit blijkt niet te kloppen en is daarom verwijderd.

Reacties (70)

[Orangelights23]

En nu is het wachten op de eerste onderzoeken die tonen dat het vooral veel geld kost om compliant te zijn, maar dat het aantal security incidenten en datalekken niet verlaagd is. /s

edit:
grappig dat mensen dit downvoten, want iedereen klaagt over wetgeving :). Ik ben er enorm blij mee, want hierdoor heb ik bakken extra werk als security consultant. En het draagt wel zeker bij aan een hogere bewustzijn en betere controle op cybersecurity. Ter info: ik was onderdeel van de adviesgroep voor NIS2, dus ik weet wel het een en ander van cybersecurity en wetgeving.

[Reactie gewijzigd door Orangelights23 op 7 juli 2026 18:03]

[oscar oscar]

Die resultaten gaan er niet komen, om NIS2 compliant te zijn zullen veruit de meeste instanties kiezen voor ISO27001 certificatie. Verdiep je eens in die materie, het is een goed framework die wel degelijk zwakke punten gaat bloot leggen in een organisatie om dit te verbeteren.

informatieveiligheid zal enkel maar belangrijker worden, het is goed dat dit vanuit Europa opgedragen wordt.

[ibmk90]

ISO 27001:2022 compliance betekent niet dat je ook NIS2 compliant bent.

[nevyn67]

Klopt, maar meestal zal he als een bedrijf voor beiden gaan.

NIS2 ondat het moet (en terecht), ISO27001 omdat menig klant hierom vraagt en er dus direct een waarde aan gekoppeld kan worden.

[R_Zwart]

Een bedrijf die zegt "omdat het moet" verdient het eigenlijk om gehackt te worden. Het is eigenlijk al erg dat er wetgeving nodig is om bedrijven zichzelf moeten beschermen.

[R4gnax]

Deze wetgeving is niet bedoeld om bedrijven tegen zichzelf te beschermen.
Deze wetgeving is bedoeld om de klanten van bedrijven tegen deze bedrijven te beschermen.

[mac1987]

Het lijkt me dat beide van toepassing kunnen zijn. Strategische plannen van kritieke organisaties binnen het land mogen niet uitlekken naar tegenstanders, ook als die inwoners of klanten niet direct raken.

[SunnieNL]

De wetgeving is bedoelt om de maatschappij in zijn geheel te beschermen. Niet alleen de klanten van de bedrijven.

Ik ben geen klant van Tennet, maar het raakt mij wel als ze offline gaan. Ik ga het ook merken als de NS een week plat ligt, ondanks dat ik 1x per kwartaal in een trein zit.

[swhnld]

Als je het framework goed inzet, staat erin dat je de toepasselijke wet en regelgeving moet kennen en toepassen. Dus is NIS2 op jou bedrijf van toepassing, moet je dat hier registreren in je management systeem, en er actie op ondernemen.

Heb je de ISO27001 al volledig geïmplementeerd (dus geen uitzonderingen opgenomen in je Verklaring van Toepasselijkheid), en je doet een GAP analyse, zie je al gauw dat de gaten die je nog zou kunnen hebben redelijk makkelijk te dichten zijn.

Meest lastige vond ik bij ons in het bedrijf nog het registreren van het bedrijf bij de NCSC https://www.ncsc.nl/cyberbeveiligingswet-nis2/registratieplicht want dat moet gebeuren door iemand met eHerkenning (van het juiste niveau), en dat heeft niet iedereen in het bedrijf.

[Wolvenhart]

Klopt NIS2 geeft ook niet direct aan welke standaarden je zou moeten toepassen dit is op basis van je organisatie en risico analyse. voor bepaalde sectoren zouden ze ook moeten focussen op bijvoorbeeld OT standaarden omdat ze naast IT ook een OT omgeving/systeem beheren. Zo zou IEC/ISA 62443-2-1 kunnen helpen als toevoeging op de ISO 27001 om die OT specifieke processen toe te voegen. voor de toeleveranciers zoals product fabrikanten is tevens ook CRA die eraan komt een ook daarvoor kan IEC/ISA 62443-4-1 een sterke OT standaard zijn om ook daaraan voor een deel te voldoen. het dekt niet de gehele CRA, maar wel de secure Development Lifecycle. ook biedt het binnen de 62443 standaard de zelfde taal met de afnemer die aan NIS2 moet voldoen om zo eenduidig de eisen voor producten of Systemen door te geven en verantwoordelijkheden duidelijk te verdelen en vast te leggen

[Sharky]

Er zit enorm veel overlap in de controls. Aangezien NIS2 nog geen formele certificering kent en daardoor meer lijkt op een inspanningsverplichting dan een resultaatverplichting (kort door de bocht) is de stap naar voldoen vervolgens erg klein.

[dakathefox]

ISO 27001 is een wassen neus, zolang je zelf kunt bepalen welk deel van je product gecertificeerd moet zijn.

[Gert]

Je certificeert geen (onderdeel van een) product met de ISO 27001.

[E!Ma0RB7]

Even onduidelijk wat met 'product' bedoeld wordt. Maar je kan wel degelijk slechts (een klein) deel van je dienstverlening laten certificeren.

Je kan als organisatie bijvoorbeeld prima enkel je klantenservice laten certificeren. Voor welk deel van je organisatie het certificaat van toepassing staat dan keurig op het certificaat in de verklaring van toepasselijkheid.

Slaat helemaal nergens op natuurlijk, maar het kan. En het gebeurt!

[dakathefox]

Zie opmerking hieronder.

[EvaluationCopy]

Ik snap je punt, maar die scope staat wel uitgeschreven op je ISO27001 certificaat, klanten die dat certificaat opvragen prikken er wel doorheen als je de scope (bewust) te klein houdt.

[xxs]

ISO27001 is mooi voor IT organisaties binnen een bedrijf maar meestal onhaalbaar voor product development of productie.

[Orangelights23]

Waarom denk je dat? Ik heb het al tientallen keren geïmplementeerd in de maakindustrie en high-tech sector. Gaat prima.

[Mellow Jack]

Het is letterlijk opschrijven wat je moet doen en daarna doen wat je hebt opgeschreven

[R_Zwart]

Mwah, wij zijn al jaren ISO27001 gecertificeerd. Ook voor development. Als mensen zeggen dat het lastig is willen ze het gewoon niet en gaan ze liever door zonder na te denken over fatsoenlijke processen. In het gunstigste geval redden ze het dan doordat er enkele "heroes" rondlopen die voor kwaliteit zorgen. Maar zodra die elders gaan werken....

[E!Ma0RB7]

Waarom dat niet? Onze hele organisatie is al weer heel wat jaartjes ISO27001 gecertificeerd. Wij zijn geen IT-bedrijf en verwerken veel informatie. Voor intern gebruik zijn er een aantal eigenbouw applicaties.

Maar toch nemen wij de hele organisatie, inclusief onze productie en bedrijfsvoering gewoon mee.

Hoofdstukken 5, 6 en 7 van Annex A gaan allemaal over Organisatorische, Mensgerichte en Fysieke beheersmaatregelen die vrij weinig met "IT" te maken hebben.

[Orangelights23]

Ik hoef me niet in de materie te verdiepen, ik heb de twede kamer geadviseerd over de wetgeving en ben geraadpleegd door de EU voorafgaand aan de ontwikkeling van de NIS2-richtlijnen.

[Wolvenhart]

Super interessant. Wat ik persoonlijk mis is dat veel sectoren ook bijvoorbeeld OT systemen draaien/beheren. Je ziet dat veel organisaties vooral eerst op de IT focus legt via de bekende ISO 27001 route. Echter is OT echt een ander beestje en zouden standaarden als bijvoorbeeld IEC 62443-2-1 een sterke toevoeging zijn voor op de ISO 27001 processen. Ik vraag me af in hoeverre die kennis word meegenomen straks ook vanuit de handhaving. Helaas kent OT behoorlijk wat andere risico's wat zelfs in de fysieke wereld gevolgen kan hebben. Enige idee hoe daar naar gekeken word met jou expertise?

[yokiamy]

Laat de organisatie waar ik zit nu de IT uitbesteed hebben en die partij ook het OT gedeelte beheren...
Die partij gedraagt zich als eigenaar en pretendeert 62443-3 geimplementeerd te hebben, laten dat ook zien met documenten tijdens audits, maar ondertussen prik ik daar gewoon gaten in. (te veel technische zaken om op te noemen)
Het lukt me niet om stakeholders binnen mijn organisatie te overtuigen daar wat mee te doen, bijzonder frustrerend.

[-Vasa-]

De meeste organisaties met een IS27001 in de benelux sluiten te veel maatregelen uit om automatisch NIS2 compliant te zijn hoor.

Mogelijk dat het voor die bedrijven wel makkelijker is om de rest dan toch op te nemen, maar ik zie toch vaak dat bedrijven liever niet hun volledig bedrijf ISO27001 compliant maken.

[Reactie gewijzigd door -Vasa- op 8 juli 2026 09:46]

[yokiamy]

De VEWIN heeft succesvol gelobbyd voor een afgeslankte vorm, wat niets meer in dan een ISO27001 light, met de helft van de maatregelen.

Mijn ervaring is dat er heel veel verschil bestaat in maturity van bedrijven. Het bedrijf waar ik werk daar geen uitzondering op en weet zich mooi te profileren, terwijl het inhoudelijk soms gewoon echt een rommeltje is.
Alles valt of staat met de kundigheid van een auditeur of die daar doorheen prikt (of niet).

[dasiro]

Compliant zijn is in de verste verte een garantie dat er geen incidenten of lekken meer zijn, enkel hoe er op gereageerd wordt en welke info bedrijven moeten hebben. De waslijst aan voorwaarden is op zijn minst een paar FTE's aan papierwerk waard en daar zal ook de DPO zijn timesheet al mee volgeschreven zijn.

Deze wetgeving legt bloot hoe ingewikkeld data-security specifiek en IT in het algemeen eigenlijk wel is. Het aan elkaar knopen van wat platformen, API's en dergelijke is simpel gemaakt, maar de opvolging, documentatie en recovery ervan in het geval van een incident allerminst.

Op zich is de gedachte erachter echter wel te verdedigen en wordt er eindelijk verantwoordelijkheid gelegd bij de bedrijven zelf ipv dat ze die af kunnen wimpelen op de onderaannemers die zich er vervolgens weinig of niets van aan trekken. Los daarvan ben ik blij dat ik er zelf niet moet aan beginnen, maar wie er toe verplicht is, maar niet voorbereid/opgeleid gaat waarschijnlijk wel meerdere slapeloze nachten tegemoet.

[NoTechSupport]

De implementatie is duur, maar als je processen en tooling aangepast zijn hoeft dat niet zo veel werk te genereren. (Dat maken wij onszelf toch wijs 😃)

[R_Zwart]

Implementatie is duur, maar het niet implementeren en daardoor met de gebakken peren komen te zitten is nog veel duurder.

[Orangelights23]

Het is een mooie papieren tijger, net als ISO 27001. Dit schrijf ik als ISO 27001 lead auditor en iemand die is geraadpleegd door de EU/ENISA voor de eerste versies van NIS2.

[SunnieNL]

Dan zou je op zich moeten weten dat het niet alleen een papieren tijger is, omdat je ook moet aantonen dat je technische maatregelen werken.

En er is maar 1 goede manier om te testen en aan te tonen dat je security maatregelen werken, of dat je backup werken, of dat je continue kan doorwerken bij een grote failure. En dat is daadwerkelijk een aanval uit te voeren, te restoren en een failover te doen.

Zelfde geldt voor de basis cyber hygiëne, die duidelijk mfa voorschrijft en risico gebaseerd patch beheer (weg zijn de maandelijkse patchrondes).

Wat dat betreft wijkt dit niet zo heel veel af van Dora.

https://www.enisa.europa....l-implementation-guidance

[closefuture]

Dan zou je op zich moeten weten dat het niet alleen een papieren tijger is, omdat je ook moet aantonen dat je technische maatregelen werken.

Dat is echt een lachtertje omdat 99% van de ISO auditors helemaal geen IT achtergrond heeft. Als jij in je beleid zegt dat je een risico afgedekt hebt door maatregel X, dan controleren zij met name of je ook daadwerkelijk X doet. Maar of maatregel X echt de boel veiliger maakt word nagenoeg niet getoetst. Dat kunnen ze ook niet, omdat ze de IT materie inhoudelijk niet beheersen.

Denk jij dat een auditor inhoudelijk wat gaat vinden van jouw interne "secure coding guidlines" als jij software maakt in Rust, Java, C++ of C#? Als ze ontbreken heb je een probleem. Maar inhoudelijk gaan ze er vrij weinig van vinden. Je moet dus voornamelijk dingen op papier zetten. Het is een forse papier winkel met een hoop ceremonie voor een relatief bescheiden veiligheids winst.

Auditors gaan met name kijken naar de dingen die ze wel begrijpen, dus alles wat weinig met IT te maken heeft. Voer je de ISO processen goed uit? Zijn de management review meetings er? Word de clean desk policy nageleefd?

[SunnieNL]

De auditor misschien niet, maar als er iets gebeurd moet je het wel kunnen aantonen dat je de zaken hebt getest en wat daar uit kwam.

En auditors hoeven ook geen kennis te hebben van pentests, ze hoeven alleen maar te begrijpen wat de uitkomst van de pentest was. En als jij die uitkomst niet kan overhandigen, dan moeten ze daar een probleem van maken.

[closefuture]

En auditors hoeven ook geen kennis te hebben van pentests, ze hoeven alleen maar te begrijpen wat de uitkomst van de pentest was. En als jij die uitkomst niet kan overhandigen, dan moeten ze daar een probleem van maken.

Het probleem is dat de meeste pentest opdrachten aan de voorkant al om zo'n manier afgekaderd / geformuleerd worden dat er toch niks boeiends uit gaat komen. Enkel wat minor issues die je dan oplost. En inderdaad, de auditor kijkt enkel naar die bevindingen en vraagt dan: "Hoe heb je die opgepakt?" en dan zeg je: "We hebben die kwetsbare library geupdate". En dat was het dan.

Maar dat er aan de voorkant gezegd is in de opdracht dat er slechts 32 uur besteed mag worden aan de pentest, het een blackbox test is, de gehele web-frontend "out of scope" is, etc. gaat de auditor niks van vinden.

[SunnieNL]

Je gooit het nu steeds op software developers, maar dit geldt natuurlijk voor veel meer partijen. Als jij het risico goed kan onderbouwen waarom jij maar maximaal 32 uur wilde besteden en het volledig afgekaderd hebt, dan is dat prima.

Dan merk je het als bestuurder vanzelf op het moment dat er wel iets gebeurd op een punt wat je nooit hebt laten testen. Leg dat maar uit aan de instanties die je dan een boete opleggen van 2% van je wereldwijde omzet omdat jij je ding niet goed hebt gedaan.

Het hele idee is ook dat deze wetgeving de CISO naar zijn juiste plaats gaat verplaatsen, namelijk naar de bestuurstafel en niet onder de IT Manager. En hij is daar niet alleen verantwoordelijk voor zaken, dat is het hele bestuur. Als de CFO een belangrijke upgrade van het edge component tegenhoud ondanks dat de CISO aangeeft dat dit een gigantisch risico vormt, dan heeft het hele bestuur een probleem. Niet alleen de CISO.

Voorlopig is overigens nog helemaal niet bekend waar de auditor precies op moet gaan auditen. Dat bepalen de overkoepelende instanties. ISO27001 laat je in ieder geval al niet aan de BIO2 voldoen. Verschuilen achter een papiertje kan niet. Odido had een serieus groot probleem extra gehad als de CBW begin vorig jaar al het licht had gezien, want die voldeden totaal niet aan de basis cyberhygiene van MFA, least-access en Identity and Access Management.

[closefuture]

Als jij het risico goed kan onderbouwen waarom jij maar maximaal 32 uur wilde besteden en het volledig afgekaderd hebt, dan is dat prima.

En dat is dus precies de crux, waar ik mijn verhaal ook mee begon. De auditor kan veelal helemaal niet inschatten of iets inhoudelijk "goed onderbouwd" is. Er word eigenlijk enkel gekeken of er onderbouwing is. Niet of die inhoudelijk hout snijd.

[SunnieNL]

Dat zou de auditor in mijn ogen wel moeten kunnen. Wat is anders zijn werk? Kijken of er een tekstje staat en dan gewoon een stempel zetten? Ik heb in het verleden een auditor op bezoek gehad die toch daadwerkelijk wel wilde zien of wij onze patch SLA haalden en ik dat rapport helemaal heb moeten uitleggen. Zelfde bij RI&E, ook daar werd redelijk doorgevraagd. Alleen een policy was absoluut niet voldoende.

Als een auditor geen idee heeft of iets hout snijdt en gewoon zijn handtekening zet, dan is er serieus wel iets mis met die auditor.

[R_Zwart]

Als het een papieren tijger is, dan is het niet goed geïmplementeerd.

[EvaluationCopy]

Dit is nou de vierde keer in alleen dit reactiepaneel alleen al dat je dit vermeldt. Waarom?

Ingaan op de inhoud lijkt me voldoende, dat moet voor een lead auditor toch geen probleem zijn? Omdat je het zo vaak roept ga ik er juist aan twijfelen (naast het feit dat het een authorireitsdrogreden is)

[R_Zwart]

Maar hoe je op incidenten moet reageren is toch waar het om draait? Een regel bedenken die ervoor zorgt dat er geen incidenten of lekken meer zijn kan domweg niet.

[dasiro]

dat is inderdaad wat @Orangelights23 bedoelde: dit is niet ter verbetering van de security op zich, maar hoe er mee om te gaan. Die inzichten zullen wel tot meer bewustzijn zorgen en dat zal voor verbetering of afstraffing leiden.

[CH4OS]

Het gaat er ook niet om, om datalekken te verminderen, dat is een mooi streven, maar met AI en lekken die steeds sneller misbruikt worden, gaat dat gewoon niet lukken. Ook is er nog 'the human factor' waardoor een kwaadwillende via dat lieve poezenplaatje of dat onschuldige linkje uit die ene e-mail alsnog toegang weet te krijgen tot een bedrijfsnetwerk.

Het doel van deze wetgeving is om bedrijven te verplichten een raamwerk te hebben om (data)lekken en veiligjheidsgaten zo snel mogelijk te kunnen en gaan dichten. Een stukje security hardening om lekken te voorkomen (want beter dan genezen) is zeker belangrijk en moet ook niet onderschat worden. Maar helemaal dicht krijgen lukt ook niet; het niveau van de beveiliging is altijd zo sterk (of zwak) als de zwakste schakel in het geheel.

[kodak]

om (data)lekken en veiligjheidsgaten zo snel mogelijk te kunnen en gaan dichten

En dat heeft dus ook als doel om te zorgen dat risico's op misbruik afnemen of voorkomen worden.

Het verschil waar @Orangelights23 het over heeft is dat niet iedereen tevreden gaat zijn omdat het tijd en geld kost. En er dan vaak onenigheid is over welke realistisch bedoelingen er zijn. Niet vreemd, aangezien er nog altijd een groep is die liever risico's wil nemen om tijd en geld te besparen. Een belangrijke reden waarom deze bredere wet er is gekomen.

[Reactie gewijzigd door kodak op 7 juli 2026 19:56]

[Orangelights23]

Ik weet wat het doel is, ik ben op persoonlijke titel geraadpleegd voor het opstellen van de eerste concepten van NIS2. Mijn reactie ging vooral over het feit dat veel mensen klagen over weer een wet. Blijkbaar moet je daarvoor een /s tegenwoordig gebruiken…

[StackMySwitchUp]

Ik snap niet waarom je zo hard gedownvote wordt. Dit soort uitspraken worden doorgaans vrij snel doorgeprikt als ze niet waar zijn, dus ik durf je wel te geloven. En daarmee ben je een potentiele goudmijn voor informatie. Ik kom uit kleine en middelgrote organisaties en kan melden dat het voor een gemiddelde MKB die onder NIS2 valt niet meer te doen is als de ict niet van meet af aan goed is aangepakt. Ik werk nu bij een middelgrote MSP en als we weer eens een kleiner pensioenfonds of een kleinere gemeente als klant krijgen dan hou ik mijn hart vast voor wat we gaan aantreffen. Het is niet alsof je even de boel stopzet en van de grond af opnieuw opbouwt, daar gaat een hoop weerstand, drama, gesprekken en consultancy aan vooraf.

[FirstStop]

Waarom heb jij het nodig om in elke post weer te vertellen dat je betrokken bent bij het opstellen van de NIS2? En dat je lead auditor bent? En dat je al meerdere implementaties hebt gedaan? Om daarna meerdere malen te spreken over de ISO27001 als papieren tijger? Even een check vraag dan: Wat is het echte kern achter een goed geimplementeerde ISO27001? Zodat het geen papieren tijger is? Oprechte vraag en wellicht een aardige vraag voor verdere aanvulling en discussie.

[himlims_]

Jammer dat je negatief gemod wordt; maar slaat spijker op z’n kop!

Als ik zie wat voor bedragen hiermee gemoeid zijn, wat werkgevers “ophoesten” om gecertificeerd te worden.

Betekend niet automatisch dat je de boel nu goed geregeld hebt; tuurlijk helpen deze richtlijnen

• Maar iets kan een geaccepteerd risico zijn
• Iets kan beperkt geïmplementeerd zijn; puntje voor volgend jaar
• Een certificering kan afgekocht worden (slikken de boete en gaan door)
• het is een richtlijn, waar jij jouw eigen implementatie of toepassing aan kent

Het is zeker geen garantie dat als je gecertificeerd bent; je in de toekomst geen artikeltje op nu.nl wordt

[StackMySwitchUp]

NIS2 is juist een stuk minder flexibel wat dat betreft. De zorgplicht gaat vrij ver, en als het een overheidsorgaan is dan wordt je een baseline opgelegd. (ik zie de opportunistische techparasieten alweer speciale producten bij elkaar gooien om aan die baseline te voldoen, uiteraard voor een vriendenprijs het eerste jaar, en daarna de prijs te verhogen)

[CPM]

Kan me niet voorstellen dat er een onderzoek nodig is om aan te tonen dat het compliant zijn veel geld kost. Er gaan echt wel wat uren in zitten om alles voor elkaar te krijgen. Maar als het goed is is het een investering in iets wat een organisatie alleen maar weerbaarder maakt toch?

En die downvote, blijkbaar zijn er nog steeds mensen die de mod-status hebben maar de faq niet hebben gelezen of begrijpen. Die -1 is totaal niet op zijn plek.

[dev-random]

Terechte verwachting die zeker geen downvote waardig is. Ik was persoonlijk heel blij met de transitie van compliancy based security naar de risk based benadering. Maar de laatst jaren bespeur ik weer een tegenovergestelde beweging. En dat kost inderdaad geld en levert per effort/euro aanzienlijk minder op als je het mij vraagt.

[mocem]

Mijn ervaring tot nu toe met NIS2. Alles wat on-prem draait moet er aan voldoen. Als het in een cloud draait vind men het prima en doet men of het daar per definitie veilig is.

[R_Zwart]

Geoutsourcete IT valt ook gewoon on NIS2. Je bent als bedrijf die aan NIS2 moet voldoen gewoon verantwoordelijk voor de hele supply chain security.

[Faeron]

In mijn vorige baan bij CIO Rijk heb ik gewerkt aan een richtlijn voor risicomanagement voor digitale weerbaarheid. Dit ter voorbereiding op de Cbw, omdat die om risicomanagement vraagt. Binnen de overheid zelf is de richtlijn goed ontvangen, maar het dan voor het brede publiek publiceren, daar is de overheid niet zo goed in. Ik heb het daarom zelf maar gepubliceerd. De richtlijn is te vinden op https://www.ravib.nl/publicaties/risicomanagementrichtlijn. Doe er je voordeel mee.

[michelr]

Een "richtlijn" waar je aan "moet" voldoen. Aangezien er geen officiële certificeringsinstantie is, is dit nog steeds grotendeels een papieren oefening. Wie gaat dit toetsen? Breek me de bek niet open over al die bedrijfjes met "deskundigen" die opeens als paddenstoelen zijn opgestegen en denken te weten hoe NIS2 exact geïmplementeerd moet worden. Buiten wat technische richtlijnen (TLS o.a.), zijn NIS2-maatregelen voornamelijk organisatorisch van aard. En dat is een beste puist werk om in te richten, laat staan te controleren. Vwb technisch heeft menig zichzelf respecterende instantie in de EU al iets soortgelijks ingericht met CIS of CISA, BSI (Duitsland), of ANSSI (Frankrijk).

[mrdemc]

Organisaties die onder de richtlijn vallen komen automatisch onder toezicht te staan. Hierbij wordt er gekeken naar de naleving van de verplichtingen uit de richtlijn, zoals de zorg- en meldplicht. Essentiële entiteiten (Art 3, Art 32) vallen onder een intensiever regime van toezicht; zowel vooraf (ex-ante) als achteraf wordt er toezicht gehouden op de naleving van de verplichtingen. Voor belangrijke entiteiten (Art 3, Art 33) geldt een lichtere vorm van toezicht dat alleen achteraf (ex-post) plaatsvindt. Bijvoorbeeld als er aanwijzingen zijn voor het niet naleven van de wet of als een incident heeft plaatsgevonden.

[michelr]

Bekend, en dat is prima, maar terwijl NIS2 al tijd op EU-niveau in de startblokken staat, was er in NL nog geen dwingende wetgeving (zie ook ander bericht van vandaag). Maar er is een verschil tussen wetgeving en handhaving, en voor dat laatste zal het in de praktijk wel neerkomen op aansprakelijkstelling als het erop aankomt. Net zo reactief als AP bij het naleven van de AVG.

FWIW, ik kom dagelijks bij Zorg en Overheid over de vloer; NIS2 staat niet echt hoog op de agenda (ze zitten ook nog eens met resourcing en de aanstaande vakantieperiode). Wellicht dat wetgeving hierbij helpt - dat gezegd hebbende, menig instantie doet al veel van de NIS2 maar heeft het geen NIS2 label.

[Reactie gewijzigd door michelr op 8 juli 2026 19:03]

[Falcon10]

En dan hoor je hier in Belgie afgelopen week nog op het 7u nieuws een CEO van een bepaald ziekenhuis waar het klantensysteem de soep in draaide door een oververhitte server in een datascenter in Parijs zeggen "Ja, we kunnen daar niet zelf aan doen, dat is een taak van de service provider". Moest ik effe om gniffelen.

Enerzijds heeft die man gelijk, maar anderzijds, slaagt ie net de bal volledig mis.

[hherrie]

Andere landen, zoals Nederland, kregen uitstel.

Zo werkt het niet. Nederland is gewoon keihard te laat met de implementatie van beide richtlijnen. Voor de CER-richtlijn is de Europese Commissie al een inbreukprocedure gestart, die waarschijnlijk leidt tot een forse boete voor Nederland.

[Saisho]

In België is deze wet sinds 17/10/2024 actief. Het Belgische Center For Cybersecurity heeft deze kans gegrepen om een stappenplan op poten te zetten die organisaties moet helpen compliant te zijn aan deze wetgeving (Cyfun). Er zijn heel wat informatiecampagnes aan vooraf gegaan om bedrijven bewust te maken van deze verandering.
Als werknemer bij een MSP heb ik gezien wat een verschil dit gemaakt heeft in de bedrijfswereld: vooral het feit dat bestuursleden hoofdelijk aansprakelijk gesteld kunnen worden voor inbreuken, maakt dat er in een snel tempo geprofessionaliseerd is op vlak van cybersecurity. Vanuit mijn ervaring: een erg positieve evolutie!

[alie19875]

Beschermen tegen natuurrampen ... good luck.

Het is maar dat warm/koud weer, bliksem inslag of regenval niet wordt gezien als natuurramp maar zodra deze een beetje te veel is zijn er storingen en andere ellende.

[Audione0]

Het doel van deze richtlijn is om de kritieke infrastructuur en economische activiteiten zoveel mogelijk te beschermen tegen dreigingen zoals cyberaanvallen, terrorisme, sabotage en natuurrampen, zegt de NCTV.

Ik mis oorlog in het rijtje.

[SunnieNL]

Denk dat de combinatie van de eerste 3 wel aardig het kopje oorlog dekt.

[PjotterP]

Een belangrijke stap. Hopelijk zet het zoden aan de dijk. Overigens: Hoewel je het online kan opzoeken had ik wel even een uitspelling van de afkorting NIS verwacht.

[tedades]

En omdat ik het zelf ook moest opzoeken: "Network and Information Security Directive 2". Veel sites vermelden NIS2 met de toevoeging: Cyberbeveiligingswet.

[Damian]

NIS2 is de overkoepelende Europese regelgeving. CBW (Cyberbeveiligingswet) is de nederlandse variant daarvan.