Een gecombineerde NIS-2 DORA CRA compliance-architectuur voor niet-financiële organisaties is een geïntegreerd risicobeheerprogramma dat de beveiligings- en meldverplichtingen uit de NIS-2 Richtlijn (EU 2022/2555), de Cyber Resilience Act (EU 2024/2847) en toepasselijke sectorale normen samenvoegt in één beheersbaar kader, zodat organisaties buiten de financiële sector meervoudige nalevingslast beheersen zonder parallelle audittrajecten.
Welke niet-financiële organisaties dragen een meervoudige nalevingslast?
De meervoudige nalevingslast ontstaat wanneer een organisatie tegelijk kwalificeert als essentiële of belangrijke entiteit onder NIS-2 én producten of software uitbrengt die onder de Cyber Resilience Act vallen.
Denk aan een ziekenhuis dat eigen patiëntsoftware ontwikkelt: het valt als essentiële entiteit onder NIS-2 (en onder de Nederlandse Cyberbeveiligingswet, Cbw), is verplicht NEN 7510 na te leven als informatieveiligheidsnorm voor de zorg, én moet voor de uitgebrachte software voldoen aan CRA bijlage I. Gemeenten en andere overheidsorganen opereren tegelijk onder NIS-2, de Baseline Informatiebeveiliging Overheid versie 2 (BIO2) en de Cbw. Producenten van industriële besturingssystemen of netwerkapparatuur voor drinkwaterbeheer komen er nog een sectorale Europese productnorm bovenop. De combinatie van een dienstverleningsgericht regime (NIS-2) en een productgericht regime (CRA) is daarbij structureel nieuw: NIS-2 richt zich op de continuïteit van diensten, de CRA op de veiligheid van producten met digitale elementen gedurende hun levenscyclus.
Statistisch gezien is de urgentie helder: het aantal gemelde significante incidenten bij ENISA steeg in de periode 2022-2023 met 30 procent, waarbij overheid en gezondheidszorg de meest getroffen sectoren waren (ENISA Threat Landscape 2023). Tegelijk voldeed in 2023 minder dan 40 procent van de Nederlandse overheidsorganisaties volledig aan de Baseline Informatiebeveiliging Overheid (Rijksinspectie Digitale Infrastructuur, rapportage 2023). De financiële druk om te voldoen is navenant: de CRA kent maximale boetes van 15 miljoen euro of 2,5 procent van de wereldwijde jaaromzet (CRA artikel 64, 2024).
NIS-2 artikel 21, CRA bijlage I en sectorale normen in één risicobeheerprogramma
Een geïntegreerd programma vertrekt vanuit het principe dat overlappende eisen één keer worden geadresseerd, in plaats van per regime apart.
De structurele overlap in kaart
NIS-2 artikel 21 verplicht essentiële en belangrijke entiteiten tot maatregelen op tien domeinen, waaronder risicoanalyse, incidentbeheer, bedrijfscontinuïteit, toeleveringsketensecurity en toegangsbeheer. CRA bijlage I, deel I stelt technische beveiligingseisen aan producten zelf: veilig ontwerp, kwetsbaarheidsbeheer gedurende de levensduur en het vermijden van bekende kwetsbaarheden bij marktintroductie. Deel II van dezelfde bijlage verplicht tot een Software Bill of Materials (SBOM), transparantie over beveiligingsupdates en documentatie van de patch-levenscyclus.
NEN 7510 (zorg) en BIO2 (overheid) zijn beide geënt op ISO/IEC 27001 en beschrijven beheersmaatregelen die grotendeels overeenkomen met NIS-2 artikel 21. Een compliance officer die werkt vanuit een gecertificeerd ISO 27001-managementsysteem heeft daarmee al een substantieel deel van de NIS-2- én de sectorale norm afgedekt. De aanvullende stap is het inrichten van de CRA-specifieke eisen, in het bijzonder de SBOM en het kwetsbaarheidsbeheerproces, als geïntegreerde module binnen dat bestaande managementsysteem.
Praktische integratiestappen
Een werkbare methode is het opzetten van een geconsolideerde beheersmaatregelenmatrix. Elke rij bevat een technische of organisatorische maatregel; de kolommen verwijzen naar de toepasselijke artikelen en bijlagen per regime. Zo wordt zichtbaar welke maatregelen meervoudig gedekt zijn en welke aanvullend vereist zijn. Voor een zorginstellingen die NEN 7510 al hebben geïmplementeerd, blijkt dat de access control-vereisten van NIS-2 artikel 21 lid 2j en NEN 7510 hoofdstuk 9 nagenoeg identiek zijn: één beleidsdocument en één set technische controles is voldoende, mits de scope correct is gedocumenteerd.
De rol van ENISA NIS360 bij het vermijden van dubbele audits
ENISA NIS360 is een periodieke volwassenheidsmonitor die de implementatietoestand van NIS-2 in de EU-lidstaten in kaart brengt en aanbevelingen doet voor gekoppelde implementatie met aanverwante regelgeving.
ENISA formuleerde het zelf scherp: “Organisaties die NIS-2 en de Cyber Resilience Act als afzonderlijke projecten behandelen, lopen het risico dat zij dubbele controlemechanismen bouwen die elkaar tegenspreken in plaats van versterken.” (ENISA, NIS360-publicatie). De NIS360-rapporten bevatten control mappings die auditors kunnen gebruiken als basis voor een geconsolideerde auditaanpak. In de praktijk betekent dit dat een externe auditor aan de hand van de mapping één bewijsdossier beoordeelt dat zowel NIS-2-artikel-21-vereisten als CRA-bijlage-I-vereisten dekt, in plaats van twee afzonderlijke dossiers op te vragen.
Voor organisaties die ook BIO2 of NEN 7510 moeten aantonen, is de vervolgstap het uitbreiden van de NIS360-mapping met de sectorspecifieke beheersmaatregelen. Zolang de mapping transparant is gedocumenteerd en de bewijsstukken eenduidig verwijzen naar de juiste regelgevingsartikelen, accepteren toezichthouders in toenemende mate een gecombineerd dossier. De Rijksinspectie Digitale Infrastructuur (RDI), die in Nederland toezicht houdt op zowel de Cbw als op de CRA als markttoezichthouder, heeft aangegeven dat geconsolideerde auditrapportages worden geaccepteerd mits de scope per regime expliciet is afgebakend.
Één meldinfrastructuur voor CRA en NIS-2 tegelijk
De meldplichten van NIS-2 en de CRA richten zich op andere triggers en soms op andere bevoegde autoriteiten, maar een organisatie kan ze met één technische infrastructuur afdekken.
NIS-2 verplicht tot een eerste melding binnen 24 uur bij een significant incident, gevolgd door een gedetailleerd rapport binnen 72 uur aan de nationale bevoegde autoriteit (in Nederland de RDI of een sectorale toezichthouder). De CRA schrijft voor dat actief misbruikte kwetsbaarheden in producten met digitale elementen binnen 72 uur worden gemeld aan ENISA én de nationale markttoezichthouder. De trigger verschilt: NIS-2 adresseert een incident dat de dienstverlening raakt, de CRA adresseert een kwetsbaarheid in een product die actief wordt misbruikt, ook als de eigen dienstverlening nog intact is.
De RDI stelde hierover: “De meldplicht onder de Cyberbeveiligingswet sluit aan op de NIS-2-termijnen, maar organisaties moeten beseffen dat de CRA een parallelle, productgerichte meldlijn introduceert die een andere bevoegde autoriteit kan betreffen.” (RDI, toezichtsinformatie CRA en NIS-2). Een gecombineerde meldinfrastructuur bevat minimaal: een geautomatiseerd detectie- en classificatiemechanisme dat onderscheidt of een event een NIS-2-incident of een CRA-kwetsbaarheid is (of beide), vooraf opgestelde meldsjablonen per regime, en duidelijk benoemde verantwoordelijken (een incident response owner voor NIS-2, een product security officer voor CRA). De tijdregistratie moet juridisch houdbaar zijn, want de termijn loopt vanaf het moment van ontdekking, niet vanaf het moment van interne escalatie.
Soevereine softwareselectie: SBOM, CE-markering en toeleveringsketensecurity
De keuze tussen open-source en commerciële tools raakt direct aan zowel de CRA-vereisten als de NIS-2-toeleveringsketenbepalingen van artikel 21 lid 2d.
| Criterium | Open-source software | Commerciële software |
|---|---|---|
| SBOM beschikbaarheid | Vaak via community (bijv. SPDX), maar kwaliteit varieert sterk | Leverancier is CRA-plichtig; SBOM moet contractueel worden opgeëist |
| CE-markering (CRA) | Niet vereist voor intern gebruik; wel als product wordt uitgebracht | Vereist voor in de handel gebrachte producten met digitale elementen |
| Patchsnelheid | Afhankelijk van community-capaciteit; risico op verlaten projecten | Contractueel af te dwingen SLA, inclusief kritieke patches |
| Toeleveringsketentransparantie (NIS-2 art. 21) | Hoog bij actieve community; broncode controleerbaar | Afhankelijk van contractuele openheid van leverancier |
| Jurisdictioneel risico (data sovereignty) | Laag bij zelf gehoste open-source | Hoog bij US-gebaseerde SaaS-aanbieders (CLOUD Act) |
Voor een NIS-2-plichtige organisatie zijn de minimumvereisten voor soevereine softwareselectie als volgt samen te vatten. Ten eerste moet van elke derde software een actuele SBOM beschikbaar zijn, inclusief de transitieve afhankelijkheden. Ten tweede moeten kwetsbaarheidsinformatie en patches aantoonbaar tijdig worden geleverd, conform de CRA-bijlage-I-vereisten. Ten derde moet de juridische vestigingsplaats van de leverancier en de verwerkingslocatie van data beoordeeld worden op jurisdictionele risico’s, met name als het gaat om cloudgebaseerde diensten. Ten vierde moet de leverancier contractueel bereid zijn mee te werken aan de NIS-2-toeleveringsketenbeoordeling en incidentrapportage.
Open-source software zoals zelf gehoste samenwerkingsplatforms biedt op het punt van jurisdictioneel risico en transparantie voordelen, maar vereist interne capaciteit voor beveiligingsbeheer en SBOM-onderhoud. Commerciële software van Europese aanbieders met aantoonbare CRA-compliance en contractuele garanties kan voor organisaties zonder grote interne securitycapaciteit een robuustere keuze zijn, mits de SBOM en CE-markering contractueel worden geborgd.
Samenvattend: de architectuurprincipes
Een gecombineerde NIS-2 en CRA compliance-architectuur voor niet-financiële organisaties staat of valt bij drie principes. Allereerst: één geconsolideerde beheersmaatregelenmatrix als gezaghebbende bron, met expliciete verwijzingen per regime en per sectorale norm. Vervolgens: een meldinfrastructuur die de twee afzonderlijke meldpaden (incident bij NIS-2, kwetsbaarheid bij CRA) technisch en organisatorisch ondersteunt zonder ze samen te voegen. Tot slot: een softwaretoeleveringsbeleid dat SBOM-beschikbaarheid, patchsnelheid en jurisdictionele onafhankelijkheid als selectiecriteria formaliseert, zodat toeleveringsketensecurity (NIS-2 artikel 21) en productveiligheid (CRA bijlage I) structureel geborgd zijn in elke aanbestedingsbeslissing.
Veelgestelde vragen
Welke niet-financiële sectoren vallen tegelijk onder NIS-2 én de Cyber Resilience Act?
Ziekenhuizen, drinkwaterbedrijven, gemeenten, digitale infrastructuuraanbieders en producenten van netwerkapparatuur of medische software zijn voorbeelden. De overlap ontstaat zodra een organisatie zelf software ontwikkelt of hardware levert met digitale elementen, terwijl zij tegelijk als essentiële of belangrijke entiteit kwalificeert.
Is het verplicht om een aparte SBOM bij te houden voor de CRA naast de al bestaande NIS-2-documentatie?
Nee. De SBOM is een CRA-verplichting (bijlage I, deel II) maar fungeert tegelijk als invoer voor de NIS-2-toeleveringsketenbeoordeling (artikel 21, lid 2d). In een geïntegreerde aanpak dekt één actuele SBOM beide verplichtingen, mits de scope per regime expliciet is gedocumenteerd.
Hoe verschilt de CRA-meldplicht van de NIS-2-meldplicht qua termijnen en bevoegde autoriteit?
NIS-2 vereist een eerste melding binnen 24 uur bij een significant incident, gevolgd door een gedetailleerd rapport binnen 72 uur, gericht aan de nationale bevoegde autoriteit. De CRA schrijft voor dat actief misbruikte kwetsbaarheden in producten binnen 72 uur worden gemeld aan ENISA én de nationale markttoezichthouder. De trigger en de adressaten verschillen, maar de tijdvensters overlappen deels.
Hoe helpt ENISA NIS360 bij het vermijden van dubbele audittrajecten?
ENISA NIS360 biedt gestructureerde control mappings die NIS-2-vereisten koppelen aan de CRA en aanverwante regelgeving. Auditoren kunnen op basis van deze mappings één geconsolideerd bewijsdossier beoordelen. Toezichthouders accepteren een gecombineerd dossier mits de scope per regime expliciet is afgebakend.
Telt open-source software als product met digitale elementen onder de CRA, en wat betekent dat voor interne softwareontwikkeling?
Open-source software die commercieel wordt uitgebracht of als onderdeel van een dienst aan derden beschikbaar wordt gesteld, valt onder de CRA. Software die uitsluitend intern wordt gebruikt en niet aan derden wordt geleverd, valt buiten de CRA-reikwijdte. Organisaties die open-source componenten verwerken in producten voor externe afnemers moeten de SBOM-verplichting en kwetsbaarheidsbeheereisen van CRA bijlage I alsnog naleven.
