CRA 2026: productbeveiligingsdossier met ISO 27001

Een fabrikant van verbonden apparaten roept zijn CISO, Maria, op vrijdagmiddag naar een overleg. Sales heeft zojuist een Europese distributieovereenkomst binnengehaald. Juridische Zaken vraagt of het bedrijf conformiteit met de Cyber Resilience Act kan onderbouwen. Engineering stelt dat veilige ontwikkeling “grotendeels is afgedekt” omdat code review, SAST en patching aanwezig zijn. Inkoop zegt dat leveranciers “onder NDA” staan. Productteams beheren firmwareafhankelijkheden in de ene tool, cloud-API-inventarissen in een andere en kwetsbaarheidstickets in Jira. Compliance beschikt over ISO/IEC 27001:2022-certificeringsbewijsmateriaal, maar dat is ingericht rond het corporate ISMS en niet rond elk product dat op de EU-markt wordt gebracht.

Dan komt de ongemakkelijke vraag: “Als een EU-autoriteit, klant, aangemelde instantie of grote distributeur in 2026 om het productbeveiligingsdossier vraagt, kunnen we dat dan binnen één week opleveren?”

Voor veel softwareleveranciers, fabrikanten van slimme apparaten en aanbieders van verbonden diensten is het eerlijke antwoord nee. Niet omdat zij geen beveiligingsmaatregelen hebben, maar omdat hun bewijsmateriaal voor productbeveiliging versnipperd is. Registraties over veilige ontwikkeling liggen bij engineering. SBOM’s worden per build gegenereerd, maar niet beheerst. Gecoördineerde openbaarmaking van kwetsbaarheden bestaat als webpagina, maar is niet altijd verbonden met triage, fixes, adviezen en monitoring na het in de handel brengen. Leveranciersbeveiliging zit verstopt in inkoopcontracten. Incidentmelding valt onder security operations, terwijl conformiteitsdocumentatie onder productcompliance valt.

De EU Cyber Resilience Act verandert het operationele model. Productcybersecurity is niet langer alleen een best practice of een contractuele belofte. Het wordt een verplichting om gedurende de levenscyclus bewijsmateriaal te leveren. Organisaties moeten kunnen aantonen hoe cybersecurityvereisten zijn ingebouwd in ontwerp, ontwikkeling, release, kwetsbaarhedenafhandeling, updates en monitoring nadat het product in de handel is gebracht.

Hier wordt ISO/IEC 27001:2022 krachtig, mits correct toegepast. Het is op zichzelf geen productcertificeringsschema, maar het ISMS en de beheersmaatregelen voor risico’s, bedrijfsmiddelen, leveranciers, veilige ontwikkeling, kwetsbaarheden en incidenten kunnen de ruggengraat vormen van een CRA-productbeveiligingsdossier. Het doel is niet om nog een compliancesilo te creëren. Het doel is om uw bestaande ISMS om te zetten in een bewijssysteem op productniveau.

Zoals Clarysecs Zenith Blueprint: een 30-stappenroadmap voor auditors het in fase 2, stap 8, bewijsmateriaalarchitectuur, formuleert:

“Bewijsmateriaal moet niet aan het einde van de auditcyclus worden verzameld. Het moet in de beheersmaatregel worden ontworpen, aan een eigenaar worden toegewezen, door het proces van een tijdstempel worden voorzien en herbruikbaar zijn voor elke verplichting die dezelfde vraag in andere bewoordingen stelt.”

Die zin vat de kern van CRA-gereedheid samen. De vraag is niet alleen: “Hebben we veilige ontwikkeling?” De vraag is: “Kunnen we veilige ontwikkeling, componentinzicht, kwetsbaarhedenafhandeling en monitoring na het in de handel brengen aantonen voor dit product, deze versie, deze release en deze markt?”

Het CRA-productbeveiligingsdossier is een levend bewijssysteem

Een CRA-productbeveiligingsdossier mag niet worden behandeld als een statische PDF die één keer vóór release wordt geproduceerd en daarna wordt vergeten. Het moet een gestructureerd dossier zijn dat het beveiligingsverhaal van het product vertelt vanaf concept tot einde ondersteuning.

Een bruikbaar dossier legt uit:

1. Wat het product is en waarvoor het bedoeld is.
2. Welke software, firmware, cloudservices en afhankelijkheden van derden het bevat.
3. Welke cybersecurityrisico’s zijn beoordeeld.
4. Welke beveiligingsvereisten zijn toegepast.
5. Hoe veilige ontwikkeling is uitgevoerd.
6. Hoe kwetsbaarheden worden ontvangen, getrieerd, opgelost en openbaar gemaakt.
7. Hoe beveiligde updates worden geleverd.
8. Hoe leveranciers en open-sourcecomponenten worden beheerst.
9. Hoe incidenten en actief misbruikte kwetsbaarheden worden geëscaleerd.
10. Hoe het product wordt gemonitord nadat het in de handel is gebracht.

Voor een CISO is dit een uitdaging rond ISMS-bewijsmateriaal. Voor een productcompliancemanager is het technische documentatie. Voor engineering is het DevSecOps en releasegovernance. Voor het bestuur gaat het om markttoegang en beheersing van aansprakelijkheid.

De fout is om deze onderdelen als afzonderlijke werkstromen te behandelen. Het betere model is een bewijsmateriaalbestand op productniveau dat wordt gekoppeld aan ISO/IEC 27001:2022- en ISO/IEC 27002:2022-beheersmaatregelen, waarna hetzelfde bewijsmateriaal waar relevant wordt doorvertaald naar NIS2, DORA, GDPR, NIST en COBIT 2019.

Clarysecs Zenith Controls: de cross-compliancegids beschrijft dit als een keten van beheersmaatregel naar bewijsmateriaal naar auditor:

“Een cross-compliancebewijsmateriaalbestand moet elke verplichting koppelen aan de operationele beheersmaatregel, het terugkerende bewijsobject, de verantwoordelijke eigenaar en de auditlens waarmee het zal worden getoetst.”

Dat is de discipline die CRA-voorbereiding vereist. Het productbeveiligingsdossier is niet zomaar een map. Het is de vertaallaag tussen productengineering, beveiligingsgovernance, conformiteitsbeoordeling en klantassurance.

Bouw eerst de bewijsmateriaalstructuur voor het product

Het dossier heeft een consistente structuur nodig voordat teams registraties gaan uploaden. Zonder duidelijke ruggengraat wordt bewijsmateriaal een stapel screenshots, exports en beleids-PDF’s die geen auditor kan volgen.

Voor CRA-gereedheidsworkshops adviseert Clarysec doorgaans de volgende structuur voor het productbeveiligingsdossier bij organisaties die al een ISO/IEC 27001:2022 ISMS hebben geïmplementeerd.

Deze tabel vervangt geen wettelijke verplichtingen voor technische documentatie. Zij geeft de organisatie een operationeel model om die verplichtingen aantoonbaar te maken.

In de Zenith Blueprint richt fase 1, stap 3 zich op het definiëren van scope en grenzen. Voor de CRA wordt die stap productspecifiek. Definieer de productfamilie, softwareversies, implementatieaannames, gebruikersrollen, verbonden diensten, updatekanalen en ondersteuningsperiode. Als de ISMS-scope “Corporate SaaS and device management platform” is, moet het CRA-dossier nog steeds een smallere vraag beantwoorden: “Welk product met digitale elementen wordt op de EU-markt gebracht en wat valt binnen dat product?”

Koppel veilige ontwikkeling aan registraties op productniveau

De kern van het productbeveiligingsdossier is bewijsmateriaal van security-by-design. ISO/IEC 27001:2022 biedt het governancesysteem. ISO/IEC 27002:2022 biedt implementatierichtlijnen via beheersmaatregelen zoals A.8.25 Veilige ontwikkelingslevenscyclus, A.8.27 Veilige systeemarchitectuur en engineeringprincipes, A.8.28 Veilig programmeren en A.8.29 Beveiligingstesten tijdens ontwikkeling en acceptatie.

De belangrijke verschuiving is van generieke claims over veilige ontwikkeling naar release-specifieke registraties. “Wij voeren code review uit” is niet voldoende. Het dossier moet laten zien welke release is beoordeeld, welke risico’s zijn overwogen, welke beveiligingstests zijn geslaagd, welke kwetsbaarheden zijn geaccepteerd of verholpen en wie de release heeft goedgekeurd.

Clarysecs Enterprise Beleid inzake veilige ontwikkeling is ontworpen om die bewijsroute af te dwingen. In clausule 6.1, Vereisten voor de veilige ontwikkelingslevenscyclus, staat:

“Voor elke product- of servicerelease moet vóór uitrol naar productie gedocumenteerd bewijsmateriaal worden bijgehouden van beveiligingsvereisten, ontwerpbeoordeling, activiteiten voor veilig programmeren, beveiligingstesten, besluiten over herstel van kwetsbaarheden en releasegoedkeuring.”

Deze clausule is nuttig voor de CRA omdat zij veilige ontwikkeling omzet in een herhaalbaar bewijspatroon. Een auditor hoeft niet af te leiden dat veilige ontwikkeling heeft plaatsgevonden. De auditor kan de releaseregistratie inspecteren.

Voor een slimme thermostaat, medisch IoT-apparaat, industriële sensor of SaaS-verbonden product moet het bewijsmateriaal voor veilige ontwikkeling het volgende omvatten:

• Productbeveiligingsvereisten gekoppeld aan geïdentificeerde risico’s.
• Dreigingsmodel of abuse-caseanalyse voor het product en de verbonden diensten.
• Architectuurbeoordeling, inclusief vertrouwensgrenzen en externe interfaces.
• Standaard voor veilig programmeren en bewijs van kennisname of training door ontwikkelaars.
• SAST, DAST, Software Composition Analysis, scanning op secrets en firmwareanalyse waar van toepassing.
• Hersteltickets voor bevindingen met hoog risico.
• Risicoacceptatieregistraties met zakelijke en beveiligingsgoedkeuring.
• Checklist voor release gates waaruit blijkt dat aan beveiligingscriteria is voldaan.
• Bewijsmateriaal van cryptografische ondertekening en update-integriteit.
• Aannames over ondersteuningsperiode en end-of-life.

Andere normen versterken de methode. ISO/IEC 27005 ondersteunt de risicobenadering achter deze registraties. ISO/IEC 27017 is nuttig wanneer cloudservices deel uitmaken van het productecosysteem. ISO/IEC 27035 ondersteunt incidentafhandeling. ISO/IEC 29147 en ISO/IEC 30111 zijn vooral relevant voor openbaarmaking en afhandeling van kwetsbaarheden. ISO/IEC 27036 ondersteunt leveranciersbeveiliging, wat van belang is wanneer het product uitbestede software, embedded modules, beheerde clouddiensten of bibliotheken van derden bevat.

In Zenith Controls wordt CRA-bewijsmateriaal voor veilige ontwikkeling meestal gekoppeld aan ISO/IEC 27002:2022-beheersmaatregelthema’s zoals informatiebeveiliging in projectmanagement, veilige ontwikkelingslevenscyclus, veilig programmeren, beveiligingstesten, wijzigingsbeheer en beheer van technische kwetsbaarheden. De gids verbindt deze ook met de inventaris van bedrijfsmiddelen en leveranciersbeheersmaatregelen, omdat geen enkel veilig ontwikkelproces volledig is als de organisatie niet kan identificeren welke componenten zij levert.

Behandel de SBOM als gereguleerd productbewijsmateriaal

De Software Bill of Materials wordt vaak behandeld als een technisch artefact. Voor CRA-gereedheid moet zij worden behandeld als productbewijsmateriaal.

Een bruikbare SBOM laat zien welke componenten in het product zitten, welke versies worden gebruikt, waar ze vandaan komen, welke licenties van toepassing zijn, welke kwetsbaarheden erop van invloed zijn en welke releases ze bevatten. Voor firmware en embedded producten kan dit besturingssysteempakketten, bootloaders, bibliotheken, drivers, containers, modules van derden en cloud-side afhankelijkheden omvatten die nodig zijn voor de werking van het product.

Het probleem is dat veel organisaties SBOM’s genereren maar niet beheersen. Een buildpijplijn kan een SPDX- of CycloneDX-bestand produceren, maar niemand valideert de volledigheid. Beveiligingstooling kan kwetsbaarheden signaleren, maar de resultaten zijn niet gekoppeld aan productversies. Inkoop kan een leverancier goedkeuren, maar de componentenlijst van die leverancier wordt niet vergeleken met het vrijgegeven product.

Clarysecs Enterprise Beleid inzake beheer van bedrijfsmiddelen adresseert dit governancehiaat in clausule 5.2, Inventaris van informatie en bijbehorende bedrijfsmiddelen:

“Informatieactiva en bijbehorende technologische componenten moeten worden geïdentificeerd, aan een eigenaar worden toegewezen, waar van toepassing worden geclassificeerd en worden bijgehouden in een inventaris die risicobeoordeling, kwetsbaarhedenbeheer, wijzigingsbeheer en auditbewijsmateriaal ondersteunt.”

Voor de CRA wordt die clausule productspecifiek. De SBOM maakt deel uit van de inventaris van bijbehorende technologische componenten. Zij heeft een eigenaar, een bewaarregel, een validatieproces en een koppeling met kwetsbaarhedenbeheer nodig.

Een praktische regel voor SBOM-bewijsmateriaal is eenvoudig: elke vrijgegeven productversie moet een goedgekeurde componenteninventaris hebben die aan het releaseartefact kan worden gekoppeld. Als de organisatie de SBOM niet kan verbinden met de exacte firmware-image, het applicatiepakket, de containerdigest of de SaaS-release, is de SBOM zwak bewijsmateriaal.

Als meer dan twee rijen niet voldoen, ligt het probleem meestal niet bij de SBOM-tool. Het is governance. Het productbeveiligingsdossier moet een corrigerende maatregel in het ISMS vastleggen, omdat een zwakte in CRA-bewijsmateriaal ook een issue is voor de doeltreffendheid van beheersmaatregelen onder ISO/IEC 27001:2022.

Verbind CVD met kwetsbaarhedenafhandeling en releasegovernance

Gecoördineerde openbaarmaking van kwetsbaarheden is een van de meest zichtbare gebieden van CRA-gereedheid, omdat externe onderzoekers, klanten en autoriteiten dit rechtstreeks kunnen testen. Het publiceren van een pagina voor openbaarmaking van kwetsbaarheden of een security.txt-bestand is nuttig, maar het is alleen de voordeur. Het productbeveiligingsdossier moet aantonen dat de backoffice werkt.

Een verdedigbare set bewijsmateriaal voor CVD en kwetsbaarhedenafhandeling moet het volgende bevatten:

• Publiek openbaarmakingskanaal en indieningsinstructies.
• Proces voor bevestiging aan onderzoekers.
• Triagecriteria, inclusief beoordeling van ernst en exploiteerbaarheid.
• Productimpactanalyse.
• Eigenaarschap van herstel en doeltermijnen.
• Sjablonen voor klantadviezen en updatecommunicatie.
• Bewijsmateriaal van veilige patchontwikkeling en -testen.
• Registraties van gecoördineerde publicatie waar van toepassing.
• Lessons learned en trendanalyse van terugkerende kwetsbaarheden.

Clarysecs Enterprise Beleid inzake kwetsbaarheden- en patchbeheer, clausule 6.3, Ontvangst, triage en herstel van kwetsbaarheden, stelt:

“Gemelde kwetsbaarheden moeten worden gelogd, beoordeeld op getroffen bedrijfsmiddelen en producten, geprioriteerd op basis van risico en exploiteerbaarheid, toegewezen aan een verantwoordelijke eigenaar en gevolgd tot en met herstel, verificatie, communicatie en afsluiting.”

Die clausule verbindt CVD met SBOM, inventaris van bedrijfsmiddelen, engineeringtickets, releasemanagement en monitoring na het in de handel brengen. Het is ook de clausule die auditors vanzelf zullen toetsen: toon de ontvangstregistratie, toon de getroffen producten, toon de triage, toon de fix, toon de klantcommunicatie, toon de afsluiting.

Uw bestaande Informatiebeveiligingsincidentbeheerbeleid moet ook worden uitgebreid naar productkwetsbaarheden die incidenten worden of externe melding vereisen. ISO/IEC 27002:2022 A.5.24 dekt planning en voorbereiding voor incidentbeheer, A.5.25 dekt beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen, A.5.26 dekt respons op informatiebeveiligingsincidenten en A.5.27 dekt leren van incidenten.

In Zenith Controls wordt kwetsbaarhedenbeheer behandeld als zowel preventief als corrigerend. De preventieve kant omvat inventaris, veilige ontwikkeling, leveranciersmonitoring en beveiligde configuratie. De corrigerende kant omvat detectie, triage, patching, communicatie en incidentescalatie. Dit onderscheid is belangrijk omdat kwetsbaarhedenafhandeling na het in de handel brengen deel uitmaakt van de verplichting voor de productlevenscyclus en geen bijzaak is.

Leveranciersbewijsmateriaal is de verborgen zwakte

Het productbeveiligingsdossier zal vaak het zwaarst worden bevraagd waar de fabrikant afhankelijk is van anderen. Dit omvat embedded modules, uitbestede firmwareontwikkeling, white-labelcomponenten, cloudhosting, mobiele SDK’s, betaaldiensten, cryptografische bibliotheken en managed support providers.

Het gebruikelijke faalpatroon is contractuele abstractie. De fabrikant zegt: “Onze leverancier is daarvoor verantwoordelijk.” Onder toetsing van productbeveiliging is dat niet genoeg. De organisatie moet aantonen dat leveranciersrisico is geïdentificeerd, beveiligingsvereisten zijn gecommuniceerd, bewijsmateriaal is verzameld, kwetsbaarheden worden gecoördineerd en wijzigingen worden beheerst.

Clarysecs Enterprise Beleid inzake beveiliging van derde partijen en leveranciers, clausule 7.1, Beveiligingsvereisten voor leveranciers, stelt:

“Leveranciers die informatiesystemen, producten of diensten ontwikkelen, exploiteren, verwerken, ondersteunen of materieel beïnvloeden, moeten op basis van risico worden beoordeeld en moeten worden onderworpen aan beveiligingsvereisten voor toegang, kwetsbaarhedenbeheer, incidentmelding, onderaanneming, continuïteit en het leveren van bewijsmateriaal.”

Voor de CRA is de zinsnede “producten materieel beïnvloeden” cruciaal. Als een leverancierscomponent een kwetsbaarheid kan introduceren, updates kan verstoren, klantgegevens kan blootstellen of de integriteit van apparaten kan compromitteren, hoort deze thuis in het productbeveiligingsdossier.

Hetzelfde beleid kan ook SBOM-contractering ondersteunen. Clausule 7.3 stelt:

“Voor alle softwarecomponenten, bibliotheken of besturingssystemen van derden die worden geïntegreerd in bedrijfsproducten met digitale elementen, moet de leverancier op verzoek een machineleesbare Software Bill of Materials (SBOM) verstrekken in een standaardformaat zoals SPDX of CycloneDX. Deze eis moet worden opgenomen in alle inkoop- en leverancierscontracten.”

Een sterk pakket met leveranciersbewijsmateriaal moet omvatten: leveranciersclassificatie op basis van productimpact, beveiligingsvereisten in contracten, bewijsmateriaal van veilige ontwikkeling door leveranciers voor kritieke componenten, toezeggingen van leveranciers over openbaarmaking van kwetsbaarheden, SBOM’s of componentverklaringen waar haalbaar, patchondersteuning en end-of-life-termijnen, periodieke beoordelingsregistraties en escalatiepaden voor kwetsbaarheden die bij leveranciers ontstaan.

ISO/IEC 27002:2022 A.5.19, A.5.20 en A.5.21 bieden de belangrijkste thema’s voor leveranciersbeheersmaatregelen. ISO/IEC 27036 voegt diepgang toe voor beveiliging van leveranciersrelaties. In cross-compliancetermen benadrukt NIS2 de toeleveringsketen en kwetsbaarhedenafhandeling. DORA benadrukt ICT-risico’s van derde partijen voor financiële entiteiten. GDPR wordt relevant wanneer het product of de bijbehorende clouddiensten persoonsgegevens verwerken. COBIT 2019 positioneert leveranciersgovernance als een vraagstuk van ondernemingsbrede technologiegovernance, niet alleen als een issue voor security operations.

Monitoring na het in de handel brengen maakt van bewijsmateriaal een operationeel proces

De meest volwassen productbeveiligingsorganisaties denken verder dan release. Zij vragen: “Hoe weten we dat dit product risicovol is geworden nadat het in het veld is geplaatst?”

Monitoring na het in de handel brengen moet signalen vastleggen uit kwetsbaarhedenfeeds, exploit intelligence, klantenservice, telemetrie, bug bounty- of onderzoekersmeldingen, leveranciersmeldingen, cloudlogboeken, incidentregistraties en prestatiegegevens uit het veld. Zij moet ook periodieke beoordeling van productrisico omvatten wanneer dreigingscondities veranderen.

Clarysecs Enterprise Beleid voor logging en monitoring, clausule 5.4, Beveiligingsmonitoring en -beoordeling, stelt:

“Beveiligingsrelevante gebeurtenissen moeten worden verzameld, beoordeeld, geëscaleerd en bewaard op een manier die tijdige detectie, onderzoek, incidentrespons, nalevingsrapportage en voortdurende verbetering ondersteunt.”

Voor verbonden producten moet dit zorgvuldig worden geïnterpreteerd. Monitoring moet privacy, gegevensminimalisatie en wettelijke beperkingen respecteren, vooral wanneer telemetrie persoonsgegevens of operationele klantgegevens bevat. Koppeling aan GDPR is belangrijk. Productbeveiligingsteams moeten met privacyteams bepalen welke telemetrie noodzakelijk is voor beveiliging, hoe deze wordt geminimaliseerd, hoe lang deze wordt bewaard en hoe klanten worden geïnformeerd.

Bewijsmateriaal voor monitoring na het in de handel brengen moet een productbeveiligingsmonitoringplan, bronnen voor kwetsbaarhedeninformatie, ontvangstkanalen voor klantmeldingen, meldingskanalen van leveranciers, reikwijdte van telemetrie- of logboekbeoordeling, notulen van periodieke productrisicobeoordelingen, opvolging van patchadoptie, incidenttrendanalyse en input voor directiebeoordeling omvatten.

In de Zenith Blueprint richt fase 5, stap 30 zich op voortdurende verbetering en gereedheid voor toezicht. Voor de CRA wordt het productbeveiligingsdossier hier een levend dossier. Elke productrelease, kwetsbaarheid, leverancierswijziging en veldsignaal moet de bewijsregistratie actualiseren.

Eén bewijsmateriaalbestand, veel nalevingsvragen

Een goed ontworpen CRA-productbeveiligingsdossier vermindert dubbel werk omdat hetzelfde bewijsmateriaal meerdere nalevingsvragen beantwoordt. De taal verandert, maar de beheersingsrealiteit is vaak vergelijkbaar.

Zenith Controls is ontworpen voor dit hergebruik. Het koppelt ISO/IEC 27002:2022-beheersmaatregelthema’s aan kenmerken zoals preventieve, detectieve en corrigerende beheersdoelstelling, cybersecurityconcepten, operationele capaciteiten en beveiligingseigenschappen. Voor de CRA helpt dit een CISO uit te leggen waarom één bewijsobject, zoals een releasebeveiligingsbeoordeling, veilige ontwikkeling, risicobehandeling, wijzigingsbeheer, kwetsbaarhedenbeheer en het vermogen om naleving aan te tonen ondersteunt.

Bereid u voor op verschillende auditlenzen

Een CRA-productbeveiligingsdossier kan worden bevraagd door een ISO-auditor, intern auditteam, klantassuranceteam, beoordelaar van productconformiteit, toezichthouder, NIST-georiënteerde assessor of ISACA-opgeleide COBIT-auditor. Elk stelt vergelijkbare vragen vanuit een andere invalshoek.

Hetzelfde zwakke punt wordt op verschillende manieren zichtbaar. Als SBOM’s worden gegenereerd maar niet bewaard, ziet de ISO-auditor een probleem met registratiebeheer en operationele beheersing. De NIST-assessor ziet een zwakte in beheer van bedrijfsmiddelen en kwetsbaarheden. De COBIT-auditor ziet zwakke governance over informatieactiva. De productbeoordelaar ziet onvoldoende technische documentatie.

Een 30-stappenroadmap, aangepast voor CRA-gereedheid

De Zenith Blueprint voorkomt dat compliance teams direct in documentverzameling springen. Voor de CRA wordt de 30-stappenroadmap een programma voor productbeveiligingsbewijsmateriaal.

Fase 1 begint met het in kaart brengen van verplichtingen en scope. Identificeer welke producten, versies, componenten, cloudservices en ondersteuningsprocessen binnen scope vallen. Bevestig beoogd gebruik, gebruikerscategorieën, markten en de periode voor beveiligingsondersteuning.

Fase 2 bouwt de bewijsmateriaalarchitectuur. Definieer de index van het productbeveiligingsdossier, eigenaren van bewijsmateriaal, bewaareisen, repositorystructuur en goedkeuringsworkflow. Stem af op engineeringsystemen in plaats van handmatige uploads af te dwingen.

Fase 3 implementeert operationele beheersmaatregelen. Veilige ontwikkeling, SBOM-generatie, kwetsbaarhedenafhandeling, leveranciersbewijsmateriaal, release gates, beveiligde updates en incidentescalatie moeten als echte processen functioneren.

Fase 4 test of de organisatie auditgereed is. Selecteer een productrelease en voer een mock-audit uit. Kan het team de SBOM ophalen? Kan het beveiligingstesten aantonen? Kan het laten zien hoe een kwetsbaarheid is getrieerd? Kan het leveranciersbewijsmateriaal verbinden met productcomponenten?

Fase 5 verankert toezicht en verbetering. Monitoring na het in de handel brengen, trendanalyse van kwetsbaarheden, leveranciersbeoordelingen en input voor directiebeoordeling houden het dossier actueel.

Deze sprint maakt de waarheid doorgaans snel zichtbaar. Organisaties falen zelden omdat zij alle beheersmaatregelen missen. Zij falen omdat beheersmaatregelen niet op productniveau zijn verbonden.

Veelvoorkomende hiaten in CRA-gereedheid vóór 2026

Bij softwareleveranciers, apparaatfabrikanten en aanbieders van verbonden diensten keren dezelfde hiaten terug.

Ten eerste is de ISMS-scope te corporate. Zij dekt de organisatie, maar onvoldoende detail over de productlevenscyclus. De oplossing is het maken van bijlagen en bewijsdossiers op productniveau.

Ten tweede bestaan SBOM’s wel, maar worden ze niet vertrouwd. Ze worden door tools gegenereerd, maar niet beoordeeld, goedgekeurd, bewaard of gekoppeld aan kwetsbaarheidsbesluiten. De oplossing is SBOM-governance, niet alleen SBOM-productie.

Ten derde is CVD publiek zichtbaar maar operationeel onvoldoende volwassen. Meldingen komen binnen, maar triagecriteria, responsdoelen, goedkeuringen van adviezen en afsluitingsbewijsmateriaal zijn inconsistent. De oplossing is CVD integreren met kwetsbaarhedenbeheer, incidentbeheer en releasemanagement.

Ten vierde is leveranciersbewijsmateriaal te oppervlakkig. Kritieke leveranciers worden commercieel goedgekeurd, maar niet beoordeeld op hun impact op productbeveiliging. De oplossing is leveranciersclassificatie op basis van productrisico en verplicht bewijsmateriaal voor kritieke componenten.

Ten vijfde is monitoring na het in de handel brengen reactief. Teams reageren op urgente kwetsbaarheden, maar voeren geen periodieke productrisicobeoordelingen uit. De oplossing is een geplande beveiligingsbeoordeling na het in de handel brengen die is gekoppeld aan managementrapportage.

Ten zesde is auditbewijsmateriaal te handmatig. Compliance teams jagen op screenshots. De oplossing is evidence-by-design, waarbij engineeringsystemen, ticketingworkflows en repositories als gezaghebbende bronnen worden gebruikt.

Bouw het bewijsdossier voordat de deadline het voor u doet

De Cyber Resilience Act beloont organisaties die productbeveiliging als operationele discipline kunnen aantonen. Zij creëert risico voor organisaties die bewijsmateriaal behandelen als een lastminuteoefening voor naleving.

Begin met één product. Bouw één productbeveiligingsdossier. Koppel het aan ISO/IEC 27001:2022 en ISO/IEC 27002:2022. Voeg bewijsmateriaal voor veilige ontwikkeling, SBOM, CVD-registraties, leveranciersassurance en monitoring na het in de handel brengen toe. Voer een auditsimulatie uit voordat een externe partij dat voor u doet.

Clarysec kan u helpen die reis te versnellen met de Zenith Blueprint, Zenith Controls, het Enterprise Beleid inzake veilige ontwikkeling, Beleid inzake kwetsbaarheden- en patchbeheer, Beleid inzake beheer van bedrijfsmiddelen, Beleid inzake beveiliging van derde partijen en leveranciers, Beleid voor logging en monitoring en Informatiebeveiligingsincidentbeheerbeleid.

Uw belangrijkste CRA 2026-vraag is niet: “Hebben we beveiligingsmaatregelen?”

De vraag is: “Kunnen we productbeveiliging aantonen, release voor release, component voor component, kwetsbaarheid voor kwetsbaarheid, nadat het product al in de handel is gebracht?”

Bouw het bewijsdossier nu, verbind het met uw ISMS en maak elke toekomstige productrelease vanaf het ontwerp auditgereed.