De CRA-meldplicht: ik wil vooraf weten wie er handelt als de klok loopt
Vanaf 11 september 2026 geldt de CRA-meldplicht voor fabrikanten. Ik kijk vooral naar de voorbereiding: weten mensen wie beslist, welke productinformatie nodig is en wie de melding op tijd indient?
Stel dat op vrijdagavond een ernstig beveiligingsprobleem wordt ontdekt in een digitaal product van je organisatie. De technische specialisten onderzoeken wat er gebeurt. De productverantwoordelijke wil weten welke klanten geraakt kunnen zijn. Ondertussen moet iemand bepalen of een melding nodig is en wie die gaat indienen.
In zo'n situatie zou ik willen dat de belangrijkste afspraken al vastliggen. Daarom kijk ik bij de nieuwe CRA-meldplicht vooral naar de samenwerking tussen mensen: wie verzamelt de feiten, wie beoordeelt ze en wie mag handelen?
Vanaf 11 september 2026 moeten fabrikanten actief misbruikte kwetsbaarheden en ernstige incidenten melden die de beveiliging van hun producten met digitale elementen raken. Een eerste waarschuwing moet binnen 24 uur na bewustwording worden ingediend. Europese Commissie, meldverplichtingen
De vrijdagavond hierboven is een hypothetisch voorbeeld. Ik zou het wel gebruiken om de voorbereiding te testen.
Eerst vaststellen of deze verplichting van toepassing is
CRA staat voor Cyber Resilience Act: Europese wetgeving over de cyberbeveiliging van producten met digitale elementen. De wet stelt eisen aan onder meer de ontwikkeling en het onderhoud van zulke producten. De belangrijkste verplichtingen gaan gelden vanaf 11 december 2027; de meldverplichtingen beginnen eerder, op 11 september 2026. Europese Commissie, CRA-overzicht
Ik zou daarom eerst per product laten vaststellen welke rol de organisatie heeft en welke verplichtingen daarbij horen. Het gebruik van software betekent op zichzelf nog niet dat een organisatie voor die software de fabrikant is. Ik zou de juridische beoordeling verbinden met het productoverzicht, zodat medewerkers kunnen zien voor welke producten de meldprocedure geldt.
Ook het soort gebeurtenis doet ertoe. De meldplicht gaat over actief misbruikte kwetsbaarheden en ernstige incidenten volgens de criteria van de CRA. Een gevonden zwakke plek is dus niet zonder meer hetzelfde als aantoonbaar misbruik. ENISA, uitleg over meldingen
Mijn advies is om deze begrippen vooraf te vertalen naar een korte beoordelingsinstructie. Daarmee kan een medewerker een signaal doorzetten zonder zelf alle juridische afwegingen te hoeven maken.
De eerste melding is het begin van de rapportage
De CRA kent opeenvolgende rapportagestappen. Na de vroege waarschuwing volgt een uitgebreidere melding en later een eindrapport. De termijnen voor de eerste twee stappen worden gerekend vanaf het moment van bewustwording; de termijn voor het eindrapport hangt af van het type gebeurtenis. Europese Commissie
| Rapportagestap | Termijn |
|---|---|
| Vroege waarschuwing | Zonder onnodige vertraging, uiterlijk binnen 24 uur na bewustwording |
| Uitgebreidere melding | Zonder onnodige vertraging, uiterlijk binnen 72 uur na bewustwording |
| Eindrapport bij een actief misbruikte kwetsbaarheid | Uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is |
| Eindrapport bij een ernstig incident | Binnen één maand na de 72-uursmelding |
Deze termijnen zijn uitgewerkt in de ENISA-FAQ.
Ik zou de stappen in één dossier bijhouden. Dat dossier moet laten zien wat bekend is, wat nog wordt onderzocht en welke informatie al is verstrekt. Een nieuwe bevinding mag de eerdere kennisstand niet onzichtbaar maken.
Voor de betrokken medewerkers zou ik daarnaast één eerstvolgende deadline tonen, met de persoon die verantwoordelijk is voor de betreffende stap. Zo is duidelijk waar de aandacht op dat moment naartoe moet.
Wie mag een besluit nemen?
Ik zou een verantwoordelijke voor de hele meldprocedure aanwijzen, met een vervanger. Vervolgens wil ik concreet vastleggen welke bijdrage van de technische specialisten, de productverantwoordelijke en de juridische functie nodig is.
De technische specialisten onderzoeken het signaal. De productverantwoordelijke helpt de mogelijke gevolgen voor de dienst en de klanten te bepalen. De juridische functie ondersteunt de beoordeling van de meldplicht. Iemand met vooraf afgesproken mandaat moet de uitkomsten bij elkaar brengen en de vervolgstap bewaken.
Dat is mijn voorstel voor de verantwoordelijkheidsverdeling; de passende invulling hangt af van de organisatie. Het belangrijkste vind ik dat er geen onbesliste overdracht overblijft.
Ik zou ook vastleggen hoe wordt opgeschaald wanneer een verantwoordelijke niet bereikbaar is. In het vrijdagavondscenario wil ik kunnen aanwijzen wie als vervanger optreedt. Alleen een naam in een procedure vind ik onvoldoende: bereikbaarheid en bevoegdheid moeten in de oefening blijken.
Productinformatie moet vindbaar zijn
Tijdens een incident wil ik kunnen achterhalen welk product en welke versie betrokken zijn. Ook wil ik weten waar de onderliggende informatie vandaan komt en wie onzekerheden kan uitzoeken.
Daarom zou ik bestaande productregistraties, technische inventarissen en incidentdossiers met elkaar verbinden. Mijn voorkeur is om met de informatievraag te beginnen: wat moeten mensen voor de beoordeling en melding kunnen vinden? Pas daarna bepalen we welke koppelingen of aanpassingen nodig zijn.
Stel dat een kwetsbaarheid wordt gevonden in een softwarecomponent die in meerdere producten voorkomt. Dan zou ik willen kunnen onderzoeken welke productversies die component bevatten en welke verantwoordelijken daarbij horen. Dit is een hypothetisch scenario waarmee je de bruikbaarheid van de registraties kunt testen.
Ook leveranciers zou ik in die oefening betrekken. Welke informatie kunnen zij leveren, wie is bereikbaar en hoe gaat een onvolledige melding verder? Ik zou onzekerheden expliciet in het dossier laten staan, met een eigenaar voor de vervolgvraag. Een lege plek mag niet ongemerkt een geruststellende conclusie worden.
Er blijft bij de start een menselijke handeling nodig
De externe melding verloopt via het Europese Single Reporting Platform. Volgens de ENISA-instructies heeft dit platform bij de eerste release geen API, een koppeling waarmee systemen rechtstreeks gegevens kunnen indienen. De melding moet dan via het scherm van het platform worden verstuurd. Vertegenwoordigers gebruiken hiervoor een persoonlijk EU Login-account met multifactorauthenticatie. ENISA-FAQ
Ik zou het werk daarom zo organiseren dat de indiener een gecontroleerd informatiepakket ontvangt. Leg vervolgens de verzonden versie en de ontvangstbevestiging vast bij hetzelfde dossier.
Controleer ook vooraf of de aangewezen mensen daadwerkelijk kunnen inloggen. Ik wil dat een ontbrekend account of een onduidelijke vervangingsafspraak tijdens de voorbereiding zichtbaar wordt.
Laat de oefening bepalen wat nog ontbreekt
Mijn eerste praktische stap zou een gezamenlijke oefening zijn met een fictief incident. Geef de deelnemers een onvolledig signaal en laat ze met de bestaande middelen de beoordeling en rapportage voorbereiden. Verstuur tijdens die oefening uiteraard geen fictieve melding als echt incident.
Ik zou observeren waar mensen moeten wachten, welke informatie ontbreekt en waar niemand zich bevoegd voelt om door te gaan. Die bevindingen vertaal ik naar concrete verbeteringen in de procedure, de registraties en de ondersteuning.
Na de verbeteringen zou ik het scenario opnieuw doorlopen. Pas dan weten we of het probleem werkelijk is opgelost.
Voor mij is de voorbereiding geslaagd wanneer medewerkers kunnen uitleggen wat zij moeten doen, de benodigde informatie kunnen vinden en de overdracht aan de volgende persoon werkt. Daarmee krijgt de wettelijke termijn een uitvoerbare werkwijze.
Bronnen
Bronnen
Bronnen die voor dit artikel zijn gebruikt of geraadpleegd.
- Cyber Resilience Act – Reporting obligations — Europese Commissie
- Cyber Resilience Act — Europese Commissie
- Frequently Asked Questions: CRA Single Reporting Platform — ENISA