CRA: wat vraagt u van uw softwareleverancier?
De Cyber Resilience Act raakt niet elke website. Wel moet u weten welke rol u heeft, wat er in uw software zit en wie bij een incident handelt.
Bram SuurdCo-founder / DeveloperU laat een klantportaal, app of koppeling bouwen. Er blijken aanwijzingen dat een kwetsbaarheid in een gebruikte component actief wordt uitgebuit, of er doet zich een ernstig beveiligingsincident voor. Weet u dan welke versies bij welke klanten draaien, wie de feiten verzamelt en wie binnen 24 uur in actie komt?
Dat is de praktische kant van de Cyber Resilience Act (CRA). De wet raakt niet iedere website. Maar brengt uw organisatie software of een digitaal product onder eigen naam op de EU-markt, dan kan uw rol verder gaan dan alleen opdrachtgever zijn. Vanaf 11 september 2026 gelden al meldverplichtingen voor fabrikanten. De meeste andere CRA-verplichtingen volgen op 11 december 2027.
Twee data, twee soorten werk
Voor uw planning zijn twee data belangrijk.
- 11 september 2026: de rapportageplicht uit artikel 14 gaat in. Bij een actief uitgebuite kwetsbaarheid of een ernstig incident met gevolgen voor de beveiliging van een product meldt de fabrikant dit via het aangewezen meldproces. De eerste waarschuwing volgt zonder onnodige vertraging en uiterlijk binnen 24 uur na kennisname. Daarna volgt uiterlijk binnen 72 uur een melding.
- 11 december 2027: de verordening wordt in hoofdzaak van toepassing. Dan spelen onder meer risicobeoordeling, technische documentatie, het behandelen van kwetsbaarheden tijdens de ondersteuningsperiode en, waar van toepassing, conformiteitsbeoordeling en CE-markering.
Dat verschil is relevant voor uw planning. Een team dat pas in 2027 begint met incidentafspraken, kan de meldtermijnen al eerder niet halen. Andersom is het onnodig om nu iedere zakelijke website als CE-project te behandelen.
Valt uw product onder de CRA?
De CRA gaat over producten met digitale elementen die op de EU-markt beschikbaar worden gemaakt en bedoeld zijn om direct of indirect gegevens met een apparaat of netwerk uit te wisselen. Software en softwarecomponenten kunnen daaronder vallen. Een gewone informatieve website valt doorgaans buiten de CRA. Een losse SaaS- of clouddienst valt in beginsel ook buiten de reikwijdte, behalve wanneer de fabrikant die dienst heeft ontworpen of ontwikkeld en de dienst nodig is om een functie van een product met digitale elementen te laten werken.
De uitkomst hangt af van het product, de functie en de rol van uw organisatie. De volgende vragen brengen het gesprek op gang:
- Brengen we een digitaal product onder onze eigen naam of ons eigen merk op de markt?
- Is de software een product op zichzelf, een onderdeel daarvan, of een oplossing die nodig is voor de werking van dat product?
- Wie bepaalt de release, de ondersteuning en de communicatie met gebruikers?
- Gebruiken we de software alleen intern, of leveren we die aan klanten of partners?
Laat u software ontwerpen of ontwikkelen en brengt u die vervolgens onder uw eigen naam of merk op de EU-markt, dan bent u in beginsel de fabrikant onder de CRA. Een ontwikkelbureau kan de ontwikkeling, updates en documentatie uitvoeren, maar die wettelijke rol neemt het daarmee niet automatisch over. Laat bij twijfel de scope en rol toetsen, zeker bij apps, plug-ins, apparaten met software of klantsoftware die u onder uw eigen naam verkoopt.
Maak onderhoud en incidentrespons onderdeel van de opdracht
Een livegang is geen eindpunt. Bij maatwerksoftware ontstaat het lastigste werk vaak daarna: afhankelijkheden bijhouden, updates beoordelen, klanten informeren en bewijs verzamelen. Als dit niet vooraf is afgesproken, begint een incident met zoeken naar de juiste persoon en de juiste versie.
Neem daarom concrete afspraken op in uw offerte, SOW of onderhoudscontract:
- Een overzicht van gebruikte componenten en versies. Voor toepasselijke CRA-producten moet de technische documentatie ook een software bill of materials (SBOM) in een gangbaar machineleesbaar formaat bevatten, ten minste met de afhankelijkheden op het hoogste niveau (bijlage VII van de CRA).
- Een release-overzicht dat laat zien welke klant of omgeving welke versie gebruikt.
- Responstijden voor triage, tijdelijke maatregelen, patches en rollback. Leg ook vast wie buiten kantooruren bereikbaar is als uw risico dat vraagt.
- Een afgesproken ondersteuningsperiode, inclusief wat er gebeurt bij end-of-life of een leverancierswissel. Voor toepasselijke CRA-producten moet de fabrikant die periode bepalen. Die duurt vijf jaar vanaf het in de handel brengen, tenzij de verwachte levensduur van het product korter is (artikel 13, lid 8).
- Een route voor incidentinformatie: wie onderzoekt, wie levert technische feiten aan en wie communiceert met klanten.
Leg praktische taken contractueel vast, maar behandel de CRA-rol niet als onderhandelbaar: de wettelijke fabrikant blijft verantwoordelijk voor de toepasselijke CRA-verplichtingen, ook als een leverancier onderdelen van het proces uitvoert.
Vijf vragen voor uw softwareleverancier
- Welke partij is volgens u fabrikant van dit product, en waarom?
- Kunt u per release laten zien welke componenten en versies zijn gebruikt?
- Levert u een SBOM en technische documentatie mee, en hoe houden we die actueel?
- Welke ondersteuning en beveiligingsupdates levert u, tot wanneer en onder welke voorwaarden?
- Wie onderzoekt een incident, wie levert binnen 24 uur de technische feiten aan en wie informeert klanten?
Vraag om aantoonbare werkwijzen en documentatie, niet alleen om een algemene claim dat een leverancier "CRA-ready" is.
Oefen één incident voordat het echt gebeurt
U hoeft geen groot crisisteam op te tuigen om te zien waar het proces hapert. Plan een sessie van 45 minuten met de producteigenaar, ontwikkelpartner en iemand die klantcommunicatie beheert. Gebruik een geloofwaardig scenario: een veelgebruikte dependency blijkt actief uitgebuit te worden.
- Noteer het tijdstip waarop het team betrouwbare informatie ontvangt. Vanaf dat moment telt de tijd.
- Bepaal welke producten, versies en klanten geraakt kunnen zijn. Als u dat niet snel kunt achterhalen, ontbreekt er waarschijnlijk versie- of componentinformatie.
- Spreek af wie tijdelijke maatregelen kan nemen, zoals een feature uitschakelen of toegang beperken.
- Laat de technische partner vastleggen welke feiten nog onzeker zijn en wanneer die worden aangevuld.
- Bepaal wie onderzoekt of de CRA-meldplicht, een AVG-datalekmelding of andere sectorregels aan de orde zijn. Dat zijn afzonderlijke beoordelingen.
De oefening hoeft niet perfect te verlopen. Juist de onduidelijkheden zijn nuttig: ontbrekende loggegevens, een oud contactnummer of een leverancier die alleen overdag reageert. Zet per knelpunt een eigenaar en een datum voor herstel.
Wat u deze maand kunt regelen
Kies één product of klantreis die u onder eigen naam aanbiedt. Verzamel de actuele contracten, onderhoudsafspraken en technische documentatie. Vraag vervolgens uw ontwikkelpartner om drie dingen: een versie- en componentenoverzicht, de afgesproken ondersteuningsperiode en een kort incidentdraaiboek met rollen en contactpunten.
Daarmee weet u nog niet automatisch of de CRA op uw product van toepassing is. U voorkomt wel een veel voorkomend probleem: dat de organisatie met de wettelijke en commerciële verantwoordelijkheid pas tijdens een incident ontdekt dat niemand het volledige plaatje heeft.
Wilt u een product, portal of integratie hierop laten doorlichten? Begin met de technische keten, de marktrol en het onderhoudsproces. Dan wordt snel duidelijk welke afspraken ontbreken en welke specialistische juridische toetsing nodig is.