NIS2, DORA en de Cyber Resilience Act: wat moet je ermee?

Wat zijn NIS2, DORA en de CRA?

Wat is NIS2 (Cyberbeveiligingswet)?

NIS2 is een Europese richtlijn. Dat betekent: elk land moet die richtlijn omzetten naar nationale wetgeving. In Nederland gebeurt dat via de Cyberbeveiligingswet (Cbw).

Belangrijk om te weten: de EU-deadline om NIS2 om te zetten was 17 oktober 2024. Veel landen (waaronder Nederland) zijn nog bezig met die vertaling naar nationale regelgeving.

Status Nederland: de Cbw treedt pas in werking na akkoord van Tweede en Eerste Kamer. De verwachting die de overheid zelf noemt is eind Q2 2026, maar dat hangt af van het tempo in de Kamers.

Wat is DORA?

DORA (Digital Operational Resilience Act) is een Europese verordening. Dat is meteen het verschil met NIS2: een verordening geldt rechtstreeks in de hele EU.

DORA richt zich op de financiële sector (banken, verzekeraars, beleggingsondernemingen en meer) en is van toepassing sinds 17 januari 2025.

Wat is de Cyber Resilience Act (CRA)?

De Cyber Resilience Act is óók een Europese verordening, maar met een andere insteek: dit gaat niet primair over organisaties, maar over producten met digitale elementen (hardware, software en vaak ook bijbehorende “remote” diensten).

De CRA is in werking sinds 10 december 2024. De meldverplichtingen starten op 11 september 2026 en de hoofdeisen gaan gelden vanaf 11 december 2027.

Actuele ontwikkeling: op 3 maart 2026 publiceerde de Europese Commissie conceptrichtsnoeren (“draft guidance”) voor feedback, met focus op o.a. remote data processing, open source, support periods en de samenhang met andere EUwetgeving.

Waarom stelt de EU deze regels op?

De simpele reden: we zijn digitaal afhankelijker dan ooit, en die afhankelijkheid zit in ketens.

• Eén incident bij een leverancier kan tientallen organisaties raken.
• Storingen en aanvallen stoppen niet bij landsgrenzen.
• De impact is niet meer “alleen IT”: het is productie, zorg, betalingen, logistiek, publieke dienstverlening.

Daarom wil de EU een hoger, gelijker basisniveau van cyberweerbaarheid, met duidelijke verwachtingen over maatregelen, melding, toezicht en (steeds vaker) aantoonbaarheid. Dat zie je terug in de NIS2-doelstelling en de druk op lidstaten om de weerbaarheid op kritieke oorganisaties binnen de samenleving te versterken.

Waar zijn deze regels vooral op gericht?

Aandachtsgebieden binnen NIS2 / Cyberbeveiligingswet

NIS2/Cbw draait om “beheerste beveiliging” voor essentiële en belangrijke organisaties: niet alleen techniek, maar ook bestuur, processen en keten.

In de Nederlandse uitleg zie je drie pijlers terug:

1. Zorgplicht: passende maatregelen nemen op basis van risico’s, gericht op continuïteit en bescherming van informatie.

2. Registratieplicht: organisaties in scope moeten zich (straks verplicht) registreren. Vrijwillige registratie kon al vanaf 17 oktober 2024, verplicht wordt het pas na inwerkingtreding van de Cbw.

3. Meldplicht (significante incidenten): in stappen en met tempo:

• binnen 24 uur vroegtijdige waarschuwing,

• binnen 72 uur vervolgmelding,

• uiterlijk 1 maand na de eerste melding een eindverslag.

Wat je hier in de praktijk steeds vaker ziet: organisaties die wachten op “de exacte wetstekst” lopen achter. De meldketen, besluitvorming en crisisorganisatie moet je namelijk oefenen, niet alleen opschrijven.

Aandachtsgebieden binnen DORA

DORA is gemaakt voor één scenario: de financiële sector móét blijven draaien, ook als ICT onder druk staat.

De focus ligt op:

• ICTrisicomanagement: beleid, controles, monitoring, ownership.

• Incidentmanagement en rapportage: processen om grote ICTincidenten te beheersen en te melden.

• Testen van weerbaarheid: niet één keer per jaar een testje, maar structureel en aantoonbaar.

• Derden/leveranciers: grip op uitbesteding, contracten, exitscenario’s.

Toezicht op kritieke ICT leveranciers: dit is een belangrijke trend. De Europese toezichthouders hebben op 18 november 2025 de eerste lijst met aangewezen kritieke ICT thirdparty providers gepubliceerd.

Kort gezegd: DORA maakt van “leveranciers management” een expliciete prioriteit.

Aandachtsgebieden binnen de CRA

De CRA trekt cybersecurity het product in: securebydesign wordt een voorwaarde om in de EU te verkopen.

De kern draait om:

• Veilig ontwerp en veilige standaardinstellingen.

• Kwetsbaarheden managen: vinden, fixen, communiceren.

• Updates en support: hoe lang blijft een product veilig en ondersteund?

• Melden van problemen: vanaf 2026 gaan reportingverplichtingen lopen.

Duidelijkheid over scope: vooral bij software, cloudachtige functies en open source. Juist daarom komt er nu extra guidance vanuit de Commissie.

Een praktische observatie: de CRA raakt niet alleen “security teams”. Ook productmanagement, development, legal, QA en supply chain komen ineens samen in één compliance vraagstuk.

Waarom is voldoen belangrijk?

Natuurlijk: het is wetgeving, dus je wil boetes, toezicht en reputatieschade en aansprakelijkheid voorkomen. Maar er zijn drie redenen die vaak zwaarder wegen dan “compliance”:

• Continuïteit: je wil niet dat één incident je dienstverlening stillegt.

• Vertrouwen: klanten en ketenpartners vragen steeds vaker om aantoonbare weerbaarheid.

• Markttoegang: bij de CRA wordt productsecurity letterlijk een toegangsbewijs tot de EU-markt (of in elk geval een harde verkoopvoorwaarde).

Wie nu investeert, koopt rust: minder adhoc incidenten, snellere recovery, betere voorspelbaarheid.

Hoe begin je zonder te verdrinken in regels?

Als je het praktisch wilt aanpakken, werkt dit bijna altijd:

Bepaal scope: val je onder NIS2/Cbw, DORA, CRA of meerdere?

• Leg je kritieke keten bloot: welke leveranciers zijn “single point of failure”?

• Maak incidentmelding uitvoerbaar: kun je binnen 24/72 uur melden met de juiste info, zonder paniek?

• Start met verzamelen van bewijsvoering: niet alleen beleid, maar ook logs, testen, oefeningen en opvolging.

• Voor productteams: ontwikkel processen voor vulnerability handling, updateprocessen en supportafspraken in je lifecycle.

Als je één actie kiest voor deze week: maak een scopecheck en test je incidentflow (wie doet wat, wanneer, met welke informatie). Dan ben je al verder dan veel organisaties die nog “op de wet wachten”.

(Dit blog is bedoeld als informatief overzicht en geen juridisch advies.)