CRA-leveranciers-due-diligence: vragenlijst en rode vlaggen

Componenten-due-diligence is een fabrikantenverplichting onder artikel 13, lid 5 van de Cyberweerbaarheidsverordening. De volledige verbatim tekst:

"Met het oog op de naleving van lid 1 betrachten fabrikanten de passende zorgvuldigheid bij de integratie van van derden afkomstige componenten in producten met digitale elementen, zodat die componenten de cyberbeveiliging van het product met digitale elementen niet in gevaar brengen, ook bij integratie van componenten van vrije en opensourcesoftware die niet in het kader van een handelsactiviteit op de markt worden aangeboden."

Deze pagina is de operationele aanvulling op het verplichtingenpakket van de fabrikant. Het regelgevende kader, de rolafbakening en de importeur-zijdige controles staan in de clustergidsen: fabrikant, importeur, distributeur en wie moet voldoen. Wat hierna volgt, is de vragenlijst, de draaiboeken per leverancierstype die de clusterpagina's niet behandelen (FOSS, cloud, alleen-hardware, OSS-stewards, gewijzigde COTS-firmware) en de operationele scenario's die teams in de praktijk van inkoop treffen (leveranciers die radiostilte houden, gedeelde upstream-componenten, post-fusie- en overnameachterstanden, n-tier-zichtbaarheid).

Waarom leveranciers-due-diligence ertoe doet

Ook als fabrikant van uw eigen product bevat uw output componenten van leveranciers: softwarebibliotheken van derden, hardwarecomponenten, firmware-modules, clouddiensten. Kwetsbaarheden in die componenten worden uw kwetsbaarheden, en uw conformiteitsbeoordeling moet toeleveringsketenrisico's meewegen.

Artikel 13, lid 5 maakt die beoordeling expliciet. De CRA schrijft geen vragenlijstformaat voor, maar een schriftelijke vragenlijst is de praktische manier om vast te leggen dat u vóór integratie de beveiliging van componenten, de kwetsbaarheidsafhandeling, de SBOM-beschikbaarheid, de ondersteuningstoezeggingen en de responspaden van de leverancier hebt gecontroleerd. Zonder gedateerde records hebt u geen verhaal voor een markttoezichtautoriteit over de wijze waarop het componentrisico is afgehandeld.

Als uw rol bij een bepaald product ook die van importeur is (u brengt het product van een niet-EU-fabrikant de EU binnen), zijn de vier controles voor marktplaatsing van de importeur een aparte verificatieplicht. Deze gids blijft gericht op de fabrikantenzijde van componenten-diligence.

Due-diligencekader

Getrapte aanpak

Niet alle leveranciers vereisen dezelfde diepgang:

INDELING LEVERANCIERSTRANCHE

TRANCHE 1 (Kritiek):
- Componenten met beveiligingsfuncties (crypto, authenticatie, firewalls)
- Kern-softwareafhankelijkheden
- Hardware met firmware
Beoordeling: Volledige vragenlijst + documentatie-review + doorlopende monitoring

TRANCHE 2 (Substantieel):
- Componenten met hoofdfunctionaliteit
- Op netwerk aangesloten elementen
- Gegevensverwerkende componenten
Beoordeling: Standaardvragenlijst + documentatie-review

TRANCHE 3 (Standaard):
- Niet-beveiligingscomponenten
- Hulpbibliotheken
- Randapparatuur
Beoordeling: Basisvragenlijst + steekproefcontroles

TRANCHE 4 (Minimaal):
- Commodity-componenten
- Gevestigde OSS
- Niet-verbonden hardware
Beoordeling: Basiscontrole + opname in SBOM

Beoordelingsgebieden

Uw due diligence moet dekken:

Het kader is generiek, maar het bewijs dat elk leverancierstype daadwerkelijk kan leveren, verschilt. De volgende vijf secties werken de meest voorkomende leverancierscontexten door, met het diligencepad dat bij elke past.

FOSS-specifieke leveranciers-due-diligence

Artikel 13, lid 5 noemt FOSS-componenten expliciet: componenten van vrije en opensourcesoftware die niet in het kader van een handelsactiviteit op de markt worden aangeboden. De wettelijke plicht geldt ongeacht of er geld wordt betaald. Een in bloed ondertekende vragenlijst van een commerciële leverancier is niet het model wanneer de upstream een GitHub-project met drie onderhouders is.

Voor niet-commerciële FOSS-componenten verschuift de bewijsset van door de leverancier geattesteerde documenten naar project-observabele signalen die u zelf kunt verzamelen.

DILIGENCE-CHECKLIST FOSS-COMPONENT

PROJECTGEZONDHEID:
[ ] Actieve commits in de laatste 90 dagen
[ ] Aantal afzonderlijke bijdragers (>1 = bus-factor-verlichting)
[ ] Releasecadans vermeld of waarneembaar
[ ] Issue-tracker reageert (mediane tijd tot eerste reactie)

BEVEILIGINGSHOUDING:
[ ] SECURITY.md aanwezig met openbaarmakingsadres
[ ] CVD-beleid (privékanaal voor beveiligingsadvies, niet enkel een issue)
[ ] CVE-geschiedenis nagekeken (NVD, GitHub Security Advisories, OSV)
[ ] SBOM-ingrediënten zelf herkenbaar, geen diepe forks

LICENTIE EN PROVENANCE:
[ ] SPDX-identifier komt overeen met de pakketmetadata
[ ] Geen licentie-incompatibele transitieve afhankelijkheid
[ ] Vrijgegeven artefacten hebben verifieerbare provenance (bv. SLSA, sigstore)

UW FALLBACKPLAN:
[ ] Forktarget aangewezen als de upstream stilvalt
[ ] Interne patchcapaciteit benoemd (welke engineer, welke code)
[ ] Vervangingskandidaten opgelijst, met substitutie-inspanning ingeschat

Twee operationele regels. Ten eerste verplicht artikel 13, lid 6 u om kwetsbaarheden die u in een FOSS-component vindt, te melden aan het upstream-project en om elke door u ontwikkelde fix terug te delen, in machineleesbaar formaat waar dat passend is. De vragenlijstregel die u controleert, is niet de toezegging van de upstream aan u; het is uw eigen toezegging om kwetsbaarheden en patches terug te laten stromen. Ten tweede dooft een stille upstream uw plicht niet uit. Als het project inactief raakt, hoort uw fallbackplan (fork, intern patchen, vervanging) bij het diligence-record, niet bij een toekomstig probleem.

Voor projecten die in stand worden gehouden door een stichting of rechtspersoon die optreedt als opensourcesoftware-steward, verandert het diligencepatroon opnieuw. Dat geval staat in de volgende sectie.

OSS-steward versus commerciële leverancier

Een kleine maar belangrijke klasse van upstreams wordt gerund door een opensourcesoftware-steward: een rechtspersoon, meestal een stichting, met als kerntaak het ondersteunen van specifieke opensource-projecten bedoeld voor commercieel gebruik. The Linux Foundation, de Eclipse Foundation en de Apache Software Foundation zijn typische voorbeelden. Stewards vallen onder artikel 24, niet onder artikel 13. Het verplichtingenpakket is smaller (een gedocumenteerd cyberbeveiligingsbeleid, een samenwerkingsplicht met markttoezicht, gedeeltelijke toepassing van artikel 14 incidentmelding), en de steward is niet de fabrikant van enig commercieel product downstream.

Voor de fabrikant-versus-steward-grens, zie opensource-stewards.

De diligenceconsequentie voor u, als downstream-integrator, is dat de vragenlijstvorm anders is.

Wat u blijft doen: projectgezondheidscontroles, SBOM-ingestie, CVE-monitoring, uw eigen fork-en-patch-fallback. Wat u niet langer verwacht: contractuele SLA's voor kwetsbaarheidsmelding, betaalde ondersteuningsniveaus, auditclausules. Het diligence-record voor een door een steward ondersteunde component is dunner op leverancierspapier en zwaarder op uw eigen controles dan voor een commerciële leverancier, en dat is juridisch de juiste vorm.

Diligence voor cloud-dienstcomponenten

Wanneer de "component" in uw product een API of een beheerde dienst is (een authenticatie-SaaS, een beheerde message broker, een serverless functie, een clouddatabase), is het bewijspatroon opnieuw anders. Er is geen DoC, geen SBOM, geen broncode die u meelevert. Er is een contract, een portfolio van beveiligingsattestaties en een model van gedeelde verantwoordelijkheid.

DILIGENCE CLOUD-DIENSTCOMPONENT

BEVEILIGINGSATTESTATIES:
[ ] SOC 2 Type II-rapport (actueel)
[ ] ISO/IEC 27001-certificaat (actueel, scopecontrole)
[ ] ISO/IEC 27017 (cloud-specifieke controls) waar relevant
[ ] ISO/IEC 27018 (PII in publieke cloud) waar persoonsgegevens in scope zijn

OPERATIONEEL BEWIJS:
[ ] Statuspagina met incidentgeschiedenis en post-mortems
[ ] Gepubliceerde RTO/RPO en datum laatste DR-test
[ ] Sub-processorlijst en kennisgevingsproces voor wijzigingen
[ ] Verwerkersovereenkomst met EU-dataresidentie, waar van toepassing

GEDEELDE VERANTWOORDELIJKHEID:
[ ] Verantwoordelijkheidsbereik provider gedocumenteerd
[ ] Uw verantwoordelijkheidsbereik bevestigd (configuratie, identiteit, secrets, netwerk)
[ ] Logging- en audittrail-toegang voor uw verantwoordelijkheidsbereik

CRA-AANPALEND:
[ ] Pad voor kwetsbaarheidsopenbaarmaking voor de API zelf
[ ] Termijn voor inbreukmelding in het contract (uren, geen "spoedig")
[ ] Opzegtermijn dienstbeëindiging (doorgaans 12 maanden)

De CRA reguleert de cloudprovider niet rechtstreeks wanneer die geen product met digitale elementen op de markt aanbiedt. Uw plicht onder artikel 13, lid 5 is aantonen dat de cloudafhankelijkheid de cyberbeveiliging van uw product niet in gevaar brengt. De deliverable is het attestatieportfolio plus een schriftelijke verklaring van gedeelde verantwoordelijkheid, geen CRA-vormige vragenlijst.

Diligence voor alleen-hardware- en ODM-leveranciers

Wanneer uw contract manufacturer (ODM, EMS, OEM-achtige assembleur) fysieke borden levert en de firmware van u is, levert de leverancier het hardwaresubstraat maar niet de beveiligingsenvelop. De CRA legt de beveiligingsenvelop bij u, de entiteit die de firmware op het bord flasht en ondertekent.

De vragenlijst is hier dunner op softwarevragen en zwaarder op hardware-vertrouwen en toeleveringsketenintegriteit.

DILIGENCE ALLEEN-HARDWARE / ODM

HARDWARE-VERTROUWEN:
[ ] BOM met cryptografisch-grade componentidentificatie
[ ] Controles tegen namaakcomponenten (auditing van componentinkoop)
[ ] Herkomst secure element en pre-provisioningmethode
[ ] Sleutelinjectieproces in de fabriek en audittrail

ASSEMBLAGE-INTEGRITEIT:
[ ] ISO 9001-kwaliteitssysteem aanwezig
[ ] Tamper-evidence aangebracht tijdens assemblage en verzending
[ ] Lot- en serietraceerbaarheid van fabriek tot ontvangstdok

OVERDRACHT FIRMWARE:
[ ] Wie ondertekent de firmware: u, de ODM, of beiden
[ ] Provisioningstaat bij eerste boot (fabrieksinstellingen, eigendomsoverdracht)
[ ] Bootloader- en secure-bootketen, wie eigenaar is van elke schakel

NA VERZENDING:
[ ] EOL-aankondigingsvenster voor het hardwareplatform
[ ] Last-time-buy-toezegging en duur
[ ] Beschikbaarheid van vervangingsonderdelen voor de door u toegezegde ondersteuningsperiode

Een veelvoorkomende operationele fout: een ondersteuningsperiode van meerdere jaren ondertekenen met een ODM wiens hardware-EOL-venster 18 maanden is. De CRA-ondersteuningsklok start zodra u het product op de EU-markt aanbiedt; valt het onderliggende silicium binnen dat venster in EOL, dan verschuift de ondersteuningsplicht niet naar de tolerantie van uw klant.

COTS-firmware die u wijzigt

Neemt u een commercieel kant-en-klaar product, wijzigt u de firmware en brengt u het resultaat op de EU-markt in de handel, dan behandelt artikel 22 u als fabrikant van het gewijzigde product voor het deel dat door de ingrijpende wijziging wordt geraakt, of voor het hele product als de wijziging de cyberbeveiligingsenvelop raakt.

"Een andere natuurlijke of rechtspersoon dan de fabrikant, de importeur of de distributeur die een ingrijpende wijziging uitvoert aan een product met digitale elementen en het op de markt aanbiedt, wordt voor de toepassing van deze verordening als fabrikant beschouwd."

De diligenceconsequentie is groot: de DoC en conformiteitsbeoordeling van de oorspronkelijke fabrikant dekken het product niet meer zoals u het in de handel brengt. U erft het fabrikantenverplichtingenpakket voor het getroffen deel of het geheel. De oorspronkelijke leverancier wordt irrelevant voor het CRA-dossier; uw eigen engineeringteam wordt de aanspreekbare partij.

De diligencestap hier is daarom geen vragenlijst aan de oorspronkelijke leverancier. Het is een interne impactanalyse van de wijziging. Documenteer de wijzigingsscope, beslis of die ingrijpend is en behandel het geheel als fabrikant-scope-werk als de wijziging authenticatie, encryptie, netwerkoppervlak of het updatemechanisme raakt. Een schone vastlegging van welke wijziging is toegepast op welke eenheidsbatch is het artefact dat een markttoezichtautoriteit als eerste opvraagt.

De vragenlijst

Gebruik deze vragenlijst als startpunt voor commerciële software- en hardwareleveranciers. De voorgaande secties behandelen de varianten voor FOSS, OSS-stewards, cloud-API's, alleen-hardware-ODM's en gewijzigde COTS-firmware.

Sectie 1: Bedrijfsinformatie

VRAGENLIJST LEVERANCIERS-DUE-DILIGENCE
Sectie 1: Bedrijfsinformatie

1.1 Bedrijfsgegevens
    Bedrijfsnaam: _________________________________
    Statutair adres: ______________________________
    Land van oprichting: __________________________
    Primair contact: ______________________________
    Beveiligingscontact: __________________________

1.2 Bedrijfsinformatie
    Aantal jaren actief: __________________________
    Aantal medewerkers: ___________________________
    Jaaromzet (bandbreedte): ______________________

1.3 EU-vertegenwoordiging (indien niet-EU)
    Naam en adres EU-gemachtigde vertegenwoordiger: __
    (Voor volledige uitleg over de AR-cascade en
    importeurroutering wanneer geen EU-vestiging
    bestaat, zie de importeur-clustergids:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certificeringen (kopieën bijvoegen)
    [ ] ISO 9001 (Kwaliteitsmanagement)
    [ ] ISO 27001 (Informatiebeveiliging)
    [ ] ISO 27701 (Privacy)
    [ ] SOC 2
    [ ] Overig: _________________________________

Sectie 2: Productconformiteit

Sectie 2: Productconformiteit

2.1 Productidentificatie
    Productnaam/model: ___________________________
    Versie/revisie: _____________________________
    Productcategorie: ___________________________

2.2 CRA-classificatie
    [ ] Standaard
    [ ] Belangrijk klasse I (bijlage III, deel I)
    [ ] Belangrijk klasse II (bijlage III, deel II)
    [ ] Kritiek (bijlage IV)
    [ ] Nog niet geclassificeerd

2.3 Conformiteitsbeoordeling
    [ ] Module A (Zelfbeoordeling)
    [ ] Module B+C (EU-typeonderzoek)
    [ ] Module H (Volledige kwaliteitsborging)
    [ ] Nog niet afgerond

    Indien module B, C of H:
    Naam aangemelde instantie: ___________________
    Certificaatnummer: ___________________________
    Certificaatdatum: ____________________________

2.4 EU-conformiteitsverklaring
    [ ] DoC beschikbaar (kopie bijvoegen)
    [ ] DoC nog niet uitgegeven
    Datum DoC: __________________________________

2.5 CE-markering
    [ ] CE-markering aangebracht
    [ ] CE-markering nog niet aangebracht
    Indien aangebracht, waar op het product: _____

2.6 Technische documentatie
    [ ] Technisch dossier op verzoek beschikbaar
    [ ] SBOM beschikbaar (formaat: ________________)
    [ ] Documentatie risicobeoordeling beschikbaar
    [ ] Gebruikers-/beveiligingsinstructies beschikbaar

Sectie 3: Beveiligingspraktijken

Sectie 3: Beveiligingspraktijken

3.1 Veilige ontwikkeling
    Volgt u een secure development lifecycle?
    [ ] Ja - Beschrijf: __________________________
    [ ] Nee

    Voert u beveiligingstests uit?
    [ ] Statische analyse (SAST)
    [ ] Dynamische analyse (DAST)
    [ ] Penetratietesten
    [ ] Fuzz-testen
    [ ] Overig: _________________________________

    Hanteert u een secure coding-standaard?
    [ ] Ja - Welke: ____________________________
    [ ] Nee

3.2 Componentbeheer
    Hoe houdt u componenten van derden bij?
    [ ] SBOM onderhouden
    [ ] Tool voor afhankelijkheidsbeheer (naam: _________)
    [ ] Handmatige administratie
    [ ] Niet systematisch bijgehouden

    Hoe monitort u kwetsbaarheden in afhankelijkheden?
    [ ] Geautomatiseerd scannen (tool: _______________)
    [ ] Handmatige CVE-monitoring
    [ ] Afhankelijk van leveranciersmeldingen
    [ ] Geen systematische monitoring

3.3 Beveiligingsarchitectuur
    Beschrijf de belangrijkste beveiligingsfuncties van het product:
    _____________________________________________

    Welke cryptografische standaarden worden gebruikt?
    _____________________________________________

    Hoe is authenticatie geïmplementeerd?
    _____________________________________________

    Hoe worden gegevens in rust en tijdens transport beschermd?
    _____________________________________________

Sectie 4: Kwetsbaarheidsbeheer

Sectie 4: Kwetsbaarheidsbeheer

4.1 Openbaarmaking kwetsbaarheden
    Hebt u een beleid voor gecoördineerde kwetsbaarheidsopenbaarmaking?
    [ ] Ja - URL: ______________________________
    [ ] Nee

    Hebt u een security.txt-bestand?
    [ ] Ja - URL: ______________________________
    [ ] Nee

    Wat is de contactmethode voor beveiliging?
    [ ] E-mail: __________________________________
    [ ] Webformulier: ____________________________
    [ ] Bug-bountyplatform: ______________________
    [ ] Overig: _________________________________

4.2 Responstoezeggingen
    Wat is uw bevestigingstermijn?
    [ ] Binnen 24 uur
    [ ] Binnen 72 uur
    [ ] Binnen 7 dagen
    [ ] Geen toezegging

    Wat is uw gangbare patchtermijn voor:
    Kritieke kwetsbaarheden: _____________________
    Hoge kwetsbaarheden: _________________________
    Middelhoge kwetsbaarheden: ___________________

4.3 ENISA-melding
    Bent u voorbereid op ENISA-melding (september 2026)?
    [ ] Ja, proces ingericht
    [ ] In uitvoering
    [ ] Nee
    [ ] Niet van toepassing (geen fabrikant)

4.4 Historische kwetsbaarheden
    Hoeveel beveiligingskwetsbaarheden zijn er
    in de afgelopen 24 maanden in dit product gemeld? ______

    Hoe zijn ze opgelost?
    [ ] Alle gepatcht binnen de toegezegde termijn
    [ ] Enige vertraging (toelichten): __________________
    [ ] Enkele nog niet gepatcht (toelichten): _________

Sectie 5: Updates en ondersteuning

Sectie 5: Updates en ondersteuning

5.1 Ondersteuningsperiode
    Wat is de toegezegde ondersteuningsperiode vanaf
    de marktplaatsing?
    [ ] 5 jaar (CRA-minimum)
    [ ] 7 jaar
    [ ] 10 jaar
    [ ] Overig: _________________________________
    [ ] Niet vastgesteld

    Wanneer is dit product voor het eerst op de EU-markt aangeboden?
    Datum: ______________________________________

    Wanneer eindigt de ondersteuningsperiode?
    Datum: ______________________________________

5.2 Updatemechanisme
    Hoe worden beveiligingsupdates geleverd?
    [ ] Automatische updates (OTA)
    [ ] Handmatige download via portaal
    [ ] Fysiek medium
    [ ] Overig: _________________________________

    Worden beveiligingsupdates losgekoppeld van functie-updates?
    [ ] Ja
    [ ] Nee - gebundeld

    Kunnen gebruikers updates uitstellen of overslaan?
    [ ] Ja
    [ ] Nee - verplicht
    [ ] Configureerbaar

5.3 Updateverificatie
    Worden updates ondertekend?
    [ ] Ja - Methode: __________________________
    [ ] Nee

    Kunnen gebruikers de echtheid van een update verifiëren?
    [ ] Ja - Hoe: _____________________________
    [ ] Nee

5.4 Planning einde ondersteuning
    Hebt u een gedocumenteerd EOL-proces?
    [ ] Ja
    [ ] Nee

    Hoe worden klanten op de hoogte gebracht van EOL?
    _____________________________________________

    Wat gebeurt er na het einde van de ondersteuningsperiode?
    [ ] Product blijft functioneren
    [ ] Product verliest functionaliteit
    [ ] Product vereist migratie

Sectie 6: Documentatievereisten

Sectie 6: Documentatievereisten

6.1 Beschikbare documentatie
    Vink alle documentatie aan die u kunt leveren:

    [ ] EU-conformiteitsverklaring
    [ ] Technisch dossier (of relevante uittreksels)
    [ ] Software Bill of Materials (SBOM)
        Formaat: [ ] CycloneDX [ ] SPDX [ ] Overig
    [ ] Samenvatting risicobeoordeling
    [ ] Document beveiligingsarchitectuur
    [ ] Gebruikersinstructies (beveiligingsrelevant)
    [ ] Beleid kwetsbaarheidsopenbaarmaking
    [ ] Ondersteunings-/onderhoudsvoorwaarden

6.2 Documentatielevering
    Hoe wordt documentatie geleverd?
    [ ] Op verzoek (responstijd: ____________)
    [ ] Via beveiligd portaal
    [ ] Gebundeld met het product
    [ ] Overig: _________________________________

6.3 SBOM-details (indien beschikbaar)
    SBOM omvat:
    [ ] Alleen directe afhankelijkheden
    [ ] Transitieve afhankelijkheden inbegrepen
    [ ] Hardwarecomponenten (indien van toepassing)

    SBOM-actualiseringsfrequentie:
    [ ] Per release
    [ ] Op verzoek
    [ ] Niet systematisch bijgewerkt

Sectie 7: Contractuele toezeggingen

Sectie 7: Contractuele toezeggingen

7.1 Conformiteitsgarantie
    Garandeert u CRA-conformiteit in het contract?
    [ ] Ja
    [ ] Nee
    [ ] Onderhandelbaar

7.2 Documentatiebewaring
    Bewaart u technische documentatie 10 jaar?
    [ ] Ja
    [ ] Nee
    [ ] Kortere periode: ________________________

7.3 Meldingsverplichtingen
    Brengt u ons op de hoogte van:
    [ ] Beveiligingskwetsbaarheden in het product
    [ ] Wijzigingen in de conformiteitsstatus
    [ ] Beslissingen over einde ondersteuning
    [ ] Materiële wijzigingen in beveiligingsarchitectuur

7.4 Auditrechten
    Staat u conformiteitsaudits toe?
    [ ] Ja - zonder beperking
    [ ] Ja - met aankondiging
    [ ] Nee

7.5 Vrijwaring
    Vrijwaart u voor CRA-niet-conformiteit?
    [ ] Ja
    [ ] Nee
    [ ] Onderhandelbaar

Sectie 8: Verklaring

Sectie 8: Verklaring

Ik verklaar dat de in deze vragenlijst verstrekte informatie
juist en volledig is naar mijn beste weten.

Ik begrijp dat [Uw bedrijf] op deze informatie steunt
voor CRA-compliancedoeleinden en dat materiële onjuistheden
kunnen leiden tot beëindiging van het contract.

Ingevuld door: ____________________________________
Functie: __________________________________________
Datum: ____________________________________________
Handtekening: _____________________________________

Rode vlaggen (signalen vooraf aan het contract)

Deze rode vlaggen zijn signalen om tijdens de vragenlijstreview en de contractonderhandeling op te pikken, vóór er een inkooporder wordt getekend. Voor de importeur-zijdige spiegel, toegepast op het moment dat het product van een niet-EU-fabrikant op de EU-markt wordt aangeboden, zie wat te weigeren en waarom op de importeur-clusterpagina.

Kritieke rode vlaggen (relatie diskwalificeren)

Ernstige rode vlaggen (onderhandelde mitigatie nodig)

Gele vlaggen (monitor gedurende de relatie)

Verificatieproces en monitoring

Initiële verificatie

1. Documentatie verzamelen

   • Vraag kopie van DoC op
   • Vraag SBOM op (of bevestiging van beschikbaarheid)
   • Vraag contactgegevens beveiliging op
   • Vraag toezegging ondersteuningsperiode op

2. Documentatie-review

   • Controleer of de DoC is ondertekend en volledig is
   • Controleer dat de productidentificatie overeenkomt
   • Verifieer de claims over CE-markering
   • Beoordeel SBOM-formaat en volledigheid

3. Steekproefcontroles conformiteit

   • Verifieer of security.txt bestaat (indien webtoegankelijk)
   • Controleer dat het CVD-beleid is gepubliceerd
   • Test of het beveiligingscontact reageert
   • Verifieer de claims over de ondersteuningsperiode in de documentatie

Doorlopende monitoring

MONITORINGSCHEMA LEVERANCIERS

Maandelijks:
[ ] Controleer op gepubliceerde beveiligingsadviezen
[ ] Verifieer dat beveiligingscontact nog werkt
[ ] Beoordeel eventuele kwetsbaarheidsopenbaarmakingen

Per kwartaal:
[ ] Vraag bijgewerkte SBOM op (bij significante releases)
[ ] Verifieer dat CVD-beleid nog toegankelijk is
[ ] Controleer op nieuwe certificeringen of verlopen ervan

Jaarlijks:
[ ] Volledige verversing vragenlijst
[ ] Beoordeel status ondersteuningsperiode
[ ] Verifieer dat documentatie nog beschikbaar is
[ ] Review bedrijfsstabiliteit

Gebeurtenis-gedreven:
[ ] Groot beveiligingsincident -> Onmiddellijke review
[ ] Eigendomswijziging -> Volledige herbeoordeling
[ ] Productbeëindiging -> EOL-planning
[ ] Contractverlenging -> Hernieuwde conformiteitsverificatie

Wanneer een leverancier niet reageert

Het meest voorkomende operationele falen in leveranciers-diligence is geen mislukte vragenlijstresponse: het is de afwezigheid van enige respons. De leverancier houdt radiostilte, traineert maandenlang of stuurt een eenregelig "wij voldoen aan alle toepasselijke regelgeving" terug. Er is geen wettelijke sanctie tegen de leverancier (deze heeft geen CRA-plicht om uw vragenlijst te beantwoorden), dus de escalatieflow moet commercieel en procedureel zijn.

ESCALATIE BIJ UITBLIJVEN LEVERANCIERSRESPONSE

WEEK 1: Initiële vragenlijst verstuurd
        Redelijke responstermijn: 15 werkdagen voor tranche 1,
        30 werkdagen voor tranche 2, 45 voor tranche 3-4.

WEEK 3: Eerste herinnering aan het benoemde beveiligingscontact en
        het primaire commerciële contact. Inkoopverantwoordelijke
        in cc.

WEEK 5: Escalatie naar de account executive van de leverancier en
        uw eigen inkoopdirecteur. Stel een harde datum.

WEEK 7: Bij nog steeds geen inhoudelijke respons:
        a) Documenteer het uitblijven in het leveranciersdossier
        b) Markeer de component "conformiteit-niet-geverifieerd"
        c) Start beoordeling vervangende leverancier
        d) Informeer producteigenaren die van de component afhankelijk zijn

WEEK 9: Beslismoment.
        Inhoudelijke respons ontvangen -> doorgaan naar review.
        Geen respons -> overschakelen naar vervangende leverancier en
        de overstap vastleggen als CRA-gedreven beslissing.

Het uitblijven is zelf diligencebewijs. Een markttoezichtautoriteit die vraagt waarom u een leverancier hebt afgestoten, accepteert een gedocumenteerd escalatietraject en een omschakelbeslissing veel sneller dan een vaag "ze waren moeilijk in de omgang". Het artefact dat u bewaart, is het gedateerde escalatielog plus de beslismemo.

Gedeelde upstream-componenten en gecoördineerde vetting

Wanneer meerdere fabrikanten dezelfde upstream-component integreren (een breed gebruikte cryptografiebibliotheek, een gangbare SDK voor beeldverwerking, een populair embedded OS), draagt elke downstream-fabrikant zijn eigen plicht onder artikel 13, lid 5. De plicht gaat niet over op de meest diligente collega, en "iedereen gebruikt het" is geen verweer.

Er zijn twee coördinatiepatronen die dubbel werk verminderen zonder de plicht af te wentelen:

Het diligence-record moet de bron van de gedeelde vetting expliciet benoemen: "reviewrapport van [werkgroep], gedateerd [X], beoordeeld en aanvaard op [Y], lacunes bijgehouden in [systeem]". Een knip-en-plak uit het diligencedossier van een collega is geen vervanging voor uw eigen beslisrecord.

Na fusie en overname: geërfde leveranciersrelaties

Wanneer uw bedrijf een ander bedrijf overneemt, neemt u ook diens leverancierslijst over. Een gangbare realiteit na fusie en overname is tientallen of honderden leveranciersrelaties zonder enig CRA-vormig diligence-record. Het werk laat zich niet over één nacht doen, maar een triage is binnen één kwartaal haalbaar.

TRIAGE LEVERANCIERS NA OVERNAME (90 DAGEN)

DAG 1-15: Inventarisatie
[ ] Trek de leverancierslijst uit het ERP-/inkoopsysteem van de overgenomen entiteit
[ ] Vergelijk met huidige product-BOM's
[ ] Identificeer welke leveranciers in CRA-scope-producten leveren
[ ] Verwijder buiten-scope-leveranciers uit de actieve triage

DAG 15-30: Indeling in tranches
[ ] Pas uw tranchemodel toe op de geërfde lijst
[ ] Markeer leveranciers zonder bestaand diligence-record
[ ] Markeer leveranciers wier producten in belangrijke klasse II of kritiek vallen

DAG 30-60: Vragenlijsten tranche 1
[ ] Verstuur de vragenlijst naar elke tranche-1-leverancier zonder record
[ ] Herverstuur naar elke tranche-1-leverancier wiens record ouder is dan 24 maanden
[ ] Verzamel responses centraal

DAG 60-90: Beslismoment
[ ] Tranche-1-leveranciers met geslaagde responses -> geïntegreerd
[ ] Tranche-1-leveranciers met rode vlaggen -> mitigatieplan of vervanging
[ ] Tranche-2/3-leveranciers -> inplannen in de reguliere jaarlijkse cyclus

DOORLOPEND:
[ ] Rol geërfde leveranciers in uw normale monitoringschema
[ ] Tag de via-overname-herkomst in het leveranciersrecord voor audit

De CRA geeft geen overnameaflossingsperiode; de overnemende entiteit erft de fabrikantenverplichting op de datum dat de overname rondkomt, voor de componenten die op dat moment in uitgeleverd product zitten. De triage hierboven is het praktische compromis: aantonen dat er een verdedigbaar diligenceprogramma loopt, ook als het volledige record nog wordt heropgebouwd.

N-tier-onderaanneming en zichtbaarheid

Uw tranche-1-leverancier kan zelf onderaanbesteden aan een tranche-2-leverancier, die op zijn beurt componenten van een tranche-3-upstream integreert. De CRA-plicht is van u, ongeacht waar in de keten de kwetsbaarheid ontstaat. Praktische zichtbaarheid loopt echter snel terug voorbij tranche 1.

Drie concrete controls die echte n-tier-zichtbaarheid opleveren:

• Transitieve SBOM-clausule. Het contract verplicht de SBOM van de leverancier om transitieve afhankelijkheden mee te nemen, niet alleen directe. Een SBOM met alleen directe afhankelijkheden verbergt vrijwel het hele werkelijke risicooppervlak.
• Lijst van sub-processors en onderaannemers. Het contract verplicht de leverancier om de lijst met genoemde onderaannemers die beveiligingsrelevante delen van de component raken, openbaar te maken en bij te werken. De clausule geeft u geen vetorecht, maar wel zichtbaarheid.
• Doorgifte van kwetsbaarheden. Het contract verplicht de leverancier om kwetsbaarheden die in transitief geïntegreerde componenten worden ontdekt, op dezelfde termijn door te geven als kwetsbaarheden in eigen ontwikkelde code.

Zonder een transitieve SBOM kunt u geen afhankelijkheidsboomscans uitvoeren op de component en kunt u aan een markttoezichtautoriteit niet aantonen dat het n-tier-risico is beoordeeld. Zonder een sub-processorlijst is een wisseling van onderaannemer bij de upstream (met eigen herkomst, controls en bus-factor) voor u onzichtbaar. Zonder doorgifte van kwetsbaarheden wordt de stilte van de tranche-1-leverancier over een tranche-2-probleem uw stilte over een beveiligingsincident.

Leveranciersovereenkomstclausules

Neem deze bepalingen op in leverancierscontracten. Elke clausule is de contractuele haak voor een van de bovenstaande diligence-uitkomsten.

Conformiteitsverklaring:

Leverancier verklaart en garandeert dat het Product (of de
Producten) voldoet aan Verordening (EU) 2024/2847
(Cyberweerbaarheidsverordening) en dat Leverancier de vereiste
conformiteitsbeoordeling heeft voltooid.

Documentatielevering:

Leverancier verstrekt op verzoek:
(a) Kopie van de EU-conformiteitsverklaring
(b) Software Bill of Materials in [CycloneDX/SPDX]-formaat,
    inclusief transitieve afhankelijkheden
(c) Technische documentatie die relevant is voor de
    conformiteitsverplichtingen van Koper
Responstijd: [5 werkdagen]

Kwetsbaarheidsmelding:

Leverancier informeert Koper binnen [24/48] uur na kennisname
van enige beveiligingskwetsbaarheid in het Product (of de Producten)
of in enige transitief geïntegreerde component die:
(a) Actief wordt misbruikt, of
(b) Een CVSS-score van 7,0 of hoger heeft, of
(c) Onderwerp is van openbaarmaking

Toezegging ondersteuningsperiode:

Leverancier verbindt zich tot het leveren van beveiligingsupdates
voor het Product (of de Producten) gedurende een minimale periode
van [5/7/10] jaar vanaf de datum van eerste marktplaatsing in de EU.

SBOM-actualiseringen:

Leverancier verstrekt een bijgewerkte SBOM binnen [10] werkdagen
na elke productrelease die wijzigingen bevat in directe of
transitieve componenten van derden.

Auditrechten:

Koper mag de naleving door Leverancier van deze Overeenkomst
en de toepasselijke CRA-vereisten auditen na [30 dagen]
schriftelijke aankondiging, maximaal eenmaal per jaar, tenzij
een specifieke conformiteitszorg aanleiding geeft.

Openbaarmaking onderaannemers:

Leverancier onderhoudt en verstrekt op verzoek een lijst van
onderaannemers die bijdragen aan of toegang hebben tot
beveiligingsrelevante componenten van het Product (of de Producten).
Leverancier informeert Koper binnen [30] dagen over elke
materiële wijziging in die lijst.

Veelgemaakte fouten

Vertrouwen op zelfattestatie

Probleem: Mondelinge toezeggingen van een leverancier accepteren zonder documentatie.

Oplossing: Vraag altijd om schriftelijk bewijs. Geen DoC-kopie, geen aankoop. Een ondertekende vragenlijst is de bodem, niet het plafond.

Eenmalige beoordeling

Probleem: Due diligence alleen bij contractondertekening.

Oplossing: Implementeer het monitoringschema hierboven. De conformiteitsstaat verandert; vragenlijsten verlopen.

Tranche-3-4-leveranciers negeren

Probleem: Alleen "grote" leveranciers beoordelen en kleinere overslaan.

Oplossing: Ook kleine componenten introduceren kwetsbaarheden (de log4j-les). Schaal de beoordeling; sla de tranche niet over.

Geen contractuele onderbouwing

Probleem: Vertrouwen op goodwill van de leverancier zonder contracttermen.

Oplossing: Leg conformiteitsverplichtingen schriftelijk vast. De clausules hierboven zijn de bodem.

Wachten tot december 2027

Probleem: Leveranciersbeoordelingen pas starten vlak voor de toepassingsdatum van de CRA.

Oplossing: Begin nu. Responses van leveranciers lopen achter. Niet-conforme leveranciers hebben maanden nodig om te remediëren of vervangen te worden.

Checklist leveranciers-due-diligence

CHECKLIST LEVERANCIERS-DUE-DILIGENCE

VOORAFGAAND AAN DE RELATIE:
[ ] Tranche leverancier vastgesteld (1/2/3/4)
[ ] Leverancierstype vastgesteld (commercieel, FOSS, OSS-steward,
    cloud, alleen-hardware, gewijzigde COTS)
[ ] Passende vragenlijstvariant gekozen
[ ] Interne reviewer toegewezen

INITIËLE BEOORDELING:
[ ] Vragenlijst verstuurd
[ ] Vragenlijst ontvangen en beoordeeld
[ ] Rode vlaggen geïdentificeerd en geadresseerd
[ ] Documentatie verzameld:
    [ ] EU-conformiteitsverklaring (of reden niet-van-toepassing)
    [ ] SBOM met transitieve afhankelijkheden (of beschikbaarheid bevestigd)
    [ ] CVD-beleid
    [ ] Toezegging ondersteuningsperiode
[ ] Steekproefcontroles afgerond:
    [ ] security.txt geverifieerd
    [ ] Beveiligingscontact getest
    [ ] CE-markering geverifieerd

CONTRACTONDERHANDELING:
[ ] Conformiteitsclausules opgenomen
[ ] Documentatiebepalingen overeengekomen
[ ] Kwetsbaarheidsmeldingstermijnen vastgelegd (uren, geen "spoedig")
[ ] Toezegging ondersteuningsperiode vastgelegd
[ ] Auditrechten opgenomen
[ ] SBOM-actualiseringsschema overeengekomen
[ ] Openbaarmakingsclausule onderaannemers opgenomen

NA CONTRACTSLUITING:
[ ] Monitoringschema ingericht
[ ] Eerste documentatielevering bevestigd
[ ] Contacten geregistreerd in leveranciersbeheersysteem
[ ] Reviewdata in de agenda gezet

DOORLOPEND:
[ ] Maandelijkse controles afgerond
[ ] Kwartaalreviews afgerond
[ ] Jaarlijkse herbeoordeling afgerond
[ ] Gebeurtenissen afgehandeld (incident, eigendomswijziging, EOL)

Verwante gidsen

• Een CRA-conforme SBOM genereren: tools, formaten en CI/CD-integratie
• De CRA-fabrikantengids
• CRA-distributeurschecklist

Dit artikel is uitsluitend bedoeld voor informatiedoeleinden en vormt geen juridisch advies. Voor specifieke conformiteitsbegeleiding raadpleegt u een gekwalificeerd juridisch adviseur.