Welke verplichting geldt al?
Sinds 11 september 2026 geldt de CRA-meldplicht voor fabrikanten van producten met digitale elementen die onder de regels vallen. Het gaat om actief uitgebuite kwetsbaarheden en ernstige incidenten die de productbeveiliging raken. De bredere productverplichtingen volgen in hoofdzaak op 11 december 2027. Laat scope, uitzonderingen en overgangsrecht per product beoordelen. Lees de uitleg van de RDI.
Een organisatie die software gebruikt, is niet daardoor automatisch de fabrikant. Een eigen merk of een ingrijpende wijziging kan wel relevant zijn. Dit artikel beschrijft de fabrikantworkflow; voor open-sourcesoftwarestewards geldt een andere regeling en ingangsdatum. Controleer het toepasselijke meldregime.
Verbind het signaal met een product en versie
Houd voor de producten binnen scope bij wie eigenaar is, welke versies worden gebruikt en waar onderbouwde componentinformatie staat. Een lijst softwarecomponenten kan helpen om een getroffen onderdeel te vinden. Zij bewijst niet zelfstandig dat misbruik heeft plaatsgevonden of welke klanten geraakt zijn.
Laat een inkomend signaal een taak opleveren met bron, tijdstip en bekende feiten. De deskundige beoordeelt de melding en legt onzekerheden vast. Maak van iedere gevonden kwetsbaarheid niet automatisch een wettelijke melding: de toepasselijke criteria vragen een afzonderlijk oordeel.
Gebruik de juiste klok
Op een smal scherm kun je de tabel zijwaarts verschuiven. Met een toetsenbord: focus de tabel en gebruik de pijltjestoetsen.
| Moment | Termijn |
|---|---|
| Vroegtijdige waarschuwing | Zonder onnodige vertraging, uiterlijk 24 uur na kennisname. |
| Nadere melding | Zonder onnodige vertraging, uiterlijk 72 uur na kennisname. |
| Eindverslag actief uitgebuite kwetsbaarheid | Uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is. |
| Eindverslag ernstig incident | Binnen één maand na de incidentmelding binnen 72 uur. |
Bron en toelichting op de meldmomenten. Een interne wachtrij mag de wettelijke termijn niet verschuiven. Registreer feiten rond kennisname en laat het juiste startmoment vaststellen; een ontbrekende interne handtekening is geen reden om de klok later te starten.
Fictief voorbeeld: een kwetsbare component in twee versies
Een fictieve softwaremaker ontvangt een geloofwaardige melding over misbruik in een gedeelde component. Het productregister toont dat twee ondersteunde versies die component gebruiken. Het team onderzoekt welke configuraties geraakt zijn. Het dossier houdt aantoonbare feiten en nog open vragen gescheiden.
Automatisering zet productinformatie klaar, bewaakt taken en herinnert de aangewezen vervanger. Een bevoegde medewerker beoordeelt meldplicht en inhoud. Na beschikbaarstelling van een oplossing ontstaat een aparte taak voor het bijbehorende eindverslag. De workflow beweert niet dat alle klanten de update al hebben geïnstalleerd.
Bereid voor; veronderstel geen automatische portaalintegratie
ENISA beheert het Europese Single Reporting Platform. De Nederlandse NCSC-informatie beschrijft melden via MijnNCSC of het CRA-meldformulier, inclusief doorgeleiding en het koppelen van vervolgmeldingen. Bevestig vóór een oefening de juiste route voor jouw vestiging en bevoegdheden. Een interne melding naar een mailbox is geen bewijs van officiële indiening. Bekijk ENISA en de Nederlandse meldinstructie.
Het voorstel is daarom eerst een gecontroleerd conceptdossier met handmatige indiening. Leg een ontvangen referentie en de daadwerkelijk ingediende versie vast. Onderzoek bij een time-out eerst de portaalstatus; een blinde herhaling kan dubbele meldingen opleveren. Veronderstel geen beschikbare API of gegarandeerde ontvangst.
Oefen zonder echte kwetsbaarheden te verspreiden
Gebruik fictieve producten en gebeurtenissen. Test een afwezige beslisser, een onvolledige productlijst en een onbereikbaar portaal. Stuur de oefening niet naar een echte overheidsmeldroute. Beperk toegang tot exploitdetails en voeg geen productgeheimen toe aan een onbeoordeelde AI-tool.
De vakpublicatie van CMS bespreekt de voorbereiding van incident- en kwetsbaarheidsprocessen. Platforminformatie kan snel verouderen; actuele officiële instructies gaan daarom vóór een ouder stappenplan.
Veelgestelde vragen
Is een kwetsbaarheidsscan voldoende?
Nee. De scan kan een signaal leveren. Productscope, misbruik, impact, melding en herstel vragen verdere beoordeling.
Kan hetzelfde dossier voor andere regels worden gebruikt?
Feiten kunnen soms worden hergebruikt. Meldcriteria, ontvangers en termijnen van bijvoorbeeld Cbw, DORA of AVG moet je afzonderlijk beoordelen. Eén melding dekt niet vanzelf alle verplichtingen.
Wat levert een eerste proef op?
Een toetsbaar proces: wie pakt een signaal op, welke informatie ontbreekt en hoe snel is een gecontroleerd concept beschikbaar? Meet ook controlewerk en onderhoud. Bepaal vooraf wat er gebeurt wanneer de automatisering zelf vastloopt.
Een concreet proces bespreken?
Wil je onderzoeken waar informatie verzamelen, controleren of overdragen eenvoudiger kan? Beschrijf één proces en de systemen die je al gebruikt. Een nieuwe tool is niet altijd nodig. Oriënterende gesprekken zijn kosteloos en vrijblijvend. Aanvullend advies en uitvoering worden via Korper afzonderlijk afgesproken, inclusief aanpak en kosten.
