Voor software- en SaaS-bedrijven komt er een reden bij om het incidentproces op orde te hebben: vanaf 11 september 2026 gelden de meldverplichtingen uit de Cyber Resilience Act voor producten met digitale elementen. Fabrikanten moeten actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten melden, en getroffen gebruikers informeren en adviseren. Melden gebeurt eenmalig via het Single Reporting Platform van de CRA, gericht aan het CSIRT van je lidstaat; in Nederland is dat het NCSC. De RDI is hier de toezichthouder.

Maar dit stuk gaat niet over de wet. Het gaat over waarom een incidentproces in de praktijk stukloopt, ook bij bedrijven die precies weten wat er van ze verwacht wordt.

Vier plekken waar het misgaat

De melding komt via een omweg binnen. Een klant mailt een medewerker rechtstreeks. Iemand ziet iets geks in een logbestand en zet het in een teamchat. Een onderzoeker stuurt een bericht naar het algemene adres. Er is geen vaste ingang, en dus is er ook geen moment waarop de klok begint te lopen. Achteraf is niet te reconstrueren wanneer je het wist.

De informatie is incompleet. Welk product, welke versie, hoeveel klanten geraakt, zijn er aanwijzingen voor actief misbruik? Die vragen worden meestal pas gesteld op het moment dat iemand het meldformulier opent. Dan begint het rondbellen, en dat kost precies de tijd die je niet hebt.

Niemand weet wie beslist. Er is een oprichter, een developer en misschien een externe securitypartij. Wie geeft akkoord op wat er naar buiten gaat? En wat als die persoon in een vlucht zit?

Achteraf is er geen dossier. Wat wanneer bekend was, wie wat besloot en welke klanten geïnformeerd zijn, staat verspreid over chat, mail en iemands geheugen. Precies de reconstructie die je nodig hebt als er later vragen over komen.

Wat je eraan kunt doen zonder een securityafdeling

Het goede nieuws: het meeste hiervan is procesautomatisering, geen securityvraagstuk. Acht stappen, waarvan er zeven automatisch kunnen lopen.

1. Eén ingang. Een adres, een formulier of een melding uit je eigen monitoring, die allemaal in dezelfde bak terechtkomen. Vanaf dat moment bestaat het incident officieel.

2. Een tijdstempel dat niet meer verandert. Het moment van binnenkomst wordt vastgelegd. Dat is het startpunt van elke termijn en van de tijdlijn achteraf.

3. Gestructureerd uitvragen. Vaste velden in plaats van vrije tekst: product, versie, aard van de kwetsbaarheid, aanwijzingen voor actief misbruik, geraakte klanten, impact. Dat scheelt niet alleen tijd; het voorkomt dat je op dag drie ontdekt dat niemand naar de versie heeft gevraagd.

4. Toewijzen en waarschuwen. De verantwoordelijke krijgt automatisch bericht, met een terugvaloptie als die niet binnen een afgesproken tijd reageert. Er blijft niets liggen omdat één persoon in vergadering zat.

5. Ernst inschatten. Op basis van je eigen criteria wordt een voorstel gedaan. Een voorstel, geen besluit: dat blijft bij een mens.

6. Termijnbewaking. De verordening werkt met korte termijnen: een vroegtijdige waarschuwing binnen 24 uur nadat je ervan op de hoogte raakt, een volledige melding binnen 72 uur, en een eindverslag uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is (bij een ernstig incident binnen een maand). De teller staat daarop, met een waarschuwing ruim voordat een termijn afloopt. Of die termijnen in jouw geval gelden, hangt af van de vraag of jouw product onder de CRA valt en of een gebeurtenis meldingsplichtig is; dat blijft jouw beoordeling, zo nodig met je juridisch adviseur.

7. Eén dossier. Alles wat bekend wordt, komt op één plek: wat wanneer bekend was, welk bewijs erbij hoort, welke besluiten genomen zijn en wie ze nam. Dat is de audittrail, en die bouw je tijdens het incident op of helemaal niet.

8. Menselijke goedkeuring. Het conceptrapport en de klantcommunicatie staan klaar. Een verantwoordelijke leest, past aan en geeft akkoord. Pas dan gaat er iets de deur uit.

Die achtste stap is met opzet handwerk

Er is technisch niets dat een automatische melding in de weg staat. Toch hoort dat niet.

Een melding aan een toezichthouder is een verklaring namens je bedrijf, met gevolgen. De inschatting of iets meldingsplichtig is, en wat je precies zegt, is een beoordeling die een mens moet maken, met de informatie die op dat moment beschikbaar is.

Wat automatisering hier wel doet: zorgen dat die beoordeling op tijd gemaakt kan worden, met complete informatie en door de juiste persoon. Dat is precies het deel dat nu misgaat.

Wat wij hier wel en niet in doen

Wij bepalen niet of jouw product onder de CRA valt en of een incident meldingsplichtig is. De termijnen staan in de verordening en worden zo ook door de Europese Commissie gepubliceerd; of ze in jouw geval gelden, is werk voor een jurist en voor jou.

Wat wij doen is het proces eromheen bouwen, in de omgeving die je al gebruikt: Microsoft 365, je ticketsysteem of het platform waarop we de automatisering draaien. Geen nieuwe tool waarvoor je apart betaalt en waar niemand naar kijkt.

Beginnen

Hoe die workflow eruitziet en wat er precies wordt opgeleverd, staat op CRA Incident Workflow. De data en verplichtingen op een rij, met de officiële bronnen erbij, staan op wetgeving en verplichtingen.

En als je vooral wilt weten hoe je organisatie er in bredere zin voor staat op incidenten, back-ups en toegang: dat is de gratis Security Check.