CRA-cyberbeveiligingsrisicobeoordeling: gids en sjabloon

Elke fabrikant van een product met digitale elementen binnen het toepassingsgebied van de CRA moet een cyberbeveiligingsrisicobeoordeling uitvoeren en schriftelijk vastleggen. Dit document bepaalt welke CRA-beveiligingsvereisten voor uw specifieke product gelden, en hoe u eraan voldoet. Markttoezichtautoriteiten kunnen het opvragen. Zonder deze beoordeling is uw technisch dossier onvolledig en mist uw conformiteitsclaim een fundament.

Deze gids legt uit hoe u de beoordeling uitvoert, vastlegt en actueel houdt. Ze bevat een volledige mapping van de beveiligingsvereisten, een uitgewerkt voorbeeld en een kopieerbaar documentskelet.

Wat is de CRA-cyberbeveiligingsrisicobeoordeling?

De cyberbeveiligingsrisicobeoordeling is een gedocumenteerde analyse van de risico's die uw product loopt, gebaseerd op het beoogde doel en de manieren waarop mensen het redelijkerwijs kunnen gebruiken. Ze behandelt de gebruiksomstandigheden, zoals de operationele omgeving en de bedrijfsmiddelen die het product moet beschermen, en houdt rekening met hoe lang het product naar verwachting in gebruik blijft.

De beoordeling heeft één uitkomst waar al het andere van afhangt. Ze geeft voor elke productbeveiligingsvereiste in de CRA aan of die vereiste op uw product van toepassing is, en zo ja, hoe uw ontwerp en processen daaraan voldoen. Ze legt ook vast hoe u aan het secure-by-design-basisniveau voldoet en hoe uw processen voor kwetsbaarheidsafhandeling het product dekken.

Drie eigenschappen maken haar anders dan een generiek bedrijfsbreed risicoregister:

• Ze is productspecifiek. Gebaseerd op de architectuur, interfaces en gebruikers van dát product. Een bedrijfsbreed ISMS-risicoregister voldoet er niet aan. Onze ISO 27001-vergelijking behandelt dat gat in detail.
• Ze is een levenscyclusdocument. U gebruikt haar tijdens planning en ontwerp, niet alleen bij release. En u werkt haar bij gedurende de hele ondersteuningsperiode.
• Ze is bewijs. De gedocumenteerde beoordeling gaat in uw technisch dossier, waar toezichthouders haar kunnen opvragen.

Wie heeft er een nodig, en wanneer

Elke fabrikant die een product met digitale elementen op de EU-markt plaatst, heeft er een nodig, tenzij het product volledig buiten de CRA valt. Binnen het toepassingsgebied: hardware met firmware, standalone software, en producten waarvan remote data-verwerking deel uitmaakt van het aanbod. Dit geldt voor een eenmansbedrijf net zo goed als voor een multinational. Producten die de CRA uitsluit, zoals gedekte medische hulpmiddelen, bepaalde voertuigen en gecertificeerde luchtvaartapparatuur, volgen in plaats daarvan hun eigen sectorregels. Twijfelt u of de CRA uw product überhaupt dekt, begin dan met de scopegids.

Timing is belangrijker dan de meeste teams verwachten:

• Begin tijdens de planning. De beoordeling moet ontwerpbeslissingen sturen. Doe een eerste doorloop wanneer de architectuur nog goedkoop is aan te passen.
• Rond haar af en documenteer haar vóór marktplaatsing. De schriftelijke beoordeling moet in het technisch dossier staan wanneer het product wordt uitgeleverd.
• Onderhoud haar gedurende de ondersteuningsperiode. De beoordeling is nooit definitief. Ze volgt het product zolang u beveiligingsupdates verschuldigd bent.

Er bestaat één smalle vereenvoudiging. Ze geldt alleen voor producten die de CRA als hoogrisico-AI-systemen behandelt en die ook onder andere EU-wetgeving vallen die een risicobeoordeling vereist. Voor die producten mag de cyberbeveiligingsbeoordeling onderdeel worden van die andere risicobeoordeling, in plaats van een apart document. De inhoudelijke verplichtingen blijven hetzelfde. Zie de gids over de overlap met de AI-verordening voor hoe dat in de praktijk werkt.

Wat de beoordeling moet bevatten

De CRA stelt een minimale inhoud vast. Uw beoordeling moet drie dingen dekken:

• Het product in context. Waarvoor het product dient, hoe mensen het redelijkerwijs kunnen gebruiken, de omgeving waarin het werkt, de bedrijfsmiddelen die het moet beschermen, en hoe lang het naar verwachting in gebruik blijft.
• Toepasselijkheidsbesluiten. Voor elk van de 13 productbeveiligingsvereisten: is deze van toepassing op dit product, en hoe wordt zij geïmplementeerd. Waar een vereiste niet van toepassing is, een duidelijke schriftelijke rechtvaardiging.
• Procesdekking. Hoe aan het secure-by-design-basisniveau wordt voldaan en hoe uw processen voor kwetsbaarheidsafhandeling het product dekken.

De rechtvaardigingsplicht verdient extra aandacht. “Niet van toepassing” zonder reden is een gebrek. Benoem de productfeiten die de vereiste wegnemen, en leg ze vast. De schriftelijke rechtvaardiging gaat samen met de rest van de beoordeling in het technisch dossier.

Voeg naast dat wettelijke minimum de maatregelen toe die het document verdedigbaar maken: behandelingsbesluiten met hun restrisico, acceptatiecriteria, een benoemde goedkeuring met datum, en een revisiegeschiedenis. De CRA schrijft geen van deze voor. Ze tonen dat de beoordeling actueel is gebleven, en dat iemand met verantwoordelijkheid het resterende risico heeft geaccepteerd.

Kies een methode

De CRA schrijft geen beoordelingsmethode, scoreschaal of sjabloon voor. Wat de verordening vereist, is een gedocumenteerd resultaat dat de toepasselijkheidsbesluiten onderbouwt. Kies een methode die uw team kan herhalen, en beschrijf haar in de beoordeling zodat een reviewer uw redenering kan volgen.

Eén regel geldt ongeacht de keuze. Druk elk risico uit als een combinatie van de waarschijnlijkheid ervan en de omvang van het verlies of de verstoring die het kan veroorzaken. De CRA vat cyberbeveiligingsrisico exact in die twee dimensies, dus een dreigingslijst die geen van beide beoordeelt, is nog geen beoordeling.

Veelgebruikte, werkbare keuzes:

Methode	Wat het oplevert	Past het best bij
Waarschijnlijkheid x impact-matrix	Eenvoudige numerieke risicoscores en een gerangschikt register	Kleine teams, eerste beoordelingen
STRIDE-achtige dreigingsmodellering	Systematische dreigingsidentificatie per component en datastroom	Softwarezware producten met duidelijke architectuurdiagrammen
Proces in de stijl van ISO/IEC 27005	Een volledige risicomanagementcyclus met context, analyse, behandeling	Organisaties die al een ISMS gebruiken
IEC 62443-dreiging-risicobenadering	Zone- en kanaalanalyse voor industriële context	Industriële en OT-producten, zie de gids industriële automatisering

De komende geharmoniseerde normen veranderen niets aan de vrije keuze van methode. De ontwerp-Europese kadernorm voor CRA-risicomanagement is zelf methode-neutraal en bouwt voort op het ISO 31000-risicoproces, zonder een scoremodel voor te schrijven. Onze pagina status geharmoniseerde normen volgt de voortgang ervan. En normen vervangen de beoordeling nooit: ook een product dat geharmoniseerde normen volledig toepast, heeft zijn eigen gedocumenteerde beoordeling nodig, en u moet controleren of de normen de risico's dekken die u daadwerkelijk hebt geïdentificeerd.

Welke methode u ook kiest, houd u aan twee regels:

1. De methode moet toepasselijkheidsantwoorden opleveren. Een stapel beoordeelde risico's is niet genoeg. De uitkomst moet gekoppeld zijn aan de 13 beveiligingsvereisten hieronder.
2. Leg de methode vast. Schaaldefinities, formule, acceptatiedrempels. Een score van “12 (Hoog)” betekent niets als de schaal niet is gedocumenteerd. De vastlegging zou een markttoezichtautoriteit in staat moeten stellen te verifiëren hoe elk risico is geïdentificeerd, beoordeeld en behandeld.

De beoordeling, stap voor stap

Een werkbaar proces in zeven stappen. Pas de diepgang aan op de complexiteit en het risico van uw product.

Stap 1: bepaal reikwijdte en context

Leg de productnaam en -versie vast, het beoogde doel, de omgevingen waarin het draait, en de gebruikers. Vermeld wat binnen de reikwijdte valt, inclusief companion-apps, cloudbackends die deel uitmaken van het aanbod, en meegeleverde componenten. Vermeld wat buiten de reikwijdte valt en waarom.

Stap 2: identificeer bedrijfsmiddelen

Som op wat het product moet beschermen. Typische bedrijfsmiddelen zijn gebruikersgegevens, inloggegevens en sleutels, de integriteit van firmware en configuratie, de beschikbaarheid van de functie van het product, en het omringende netwerk. Noteer waar elk bedrijfsmiddel zich bevindt en hoe het beweegt.

Stap 3: identificeer dreigingen

Doorloop uw architectuur oppervlak voor oppervlak. Begin met externe interfaces, want daar beginnen aanvallers. Vraag u voor elke interface en datastroom af wat een aanvaller zou kunnen doen: onderscheppen, spoofen, manipuleren, overspoelen, gegevens onttrekken. Neem ook voorzienbaar misbruik van het product mee, niet alleen opzettelijke aanvallen. Leg elke geloofwaardige dreiging vast met de kwetsbaarheid die ze zou uitbuiten.

Stap 4: beoordeel de risico's

Beoordeel waarschijnlijkheid en impact voor elke dreiging met uw gedocumenteerde schaal. Kan een incident fysieke schade veroorzaken, neem dan het effect op de gezondheid en veiligheid van gebruikers mee in de impactbeoordeling. Rangschik de resultaten. Het doel van de beoordeling is prioritering, geen precisie. Een verdedigbare rangschikking die ontwerpbeslissingen stuurt, is beter dan een precies ogende tabel die niemand gebruikt.

Stap 5: bepaal de toepasselijkheid van de beveiligingsvereisten

Doorloop de 13 productbeveiligingsvereisten één voor één. Geef voor elke vereiste aan of ze op dit product van toepassing is, welke van uw geïdentificeerde risico's ze behandelt, en hoe u haar implementeert. Waar een vereiste écht niet van toepassing is, schrijft u de rechtvaardiging. De volledige mappingtabel hieronder is uw werkblad.

Stap 6: behandel de risico's en leg de restrisico's vast

Leg voor elk materieel risico de gekozen maatregel vast, waar ze is geïmplementeerd, en het restrisico na de maatregel. Definieer acceptatiecriteria en leg vast wie het resterende risico heeft geaccepteerd. Risico's zonder maatregel hebben een expliciet, toegewezen acceptatiebesluit nodig.

Stap 7: keur goed en stel onderhoudstriggers vast

Laat een benoemde eigenaar de beoordeling goedkeuren, met een datum. Definieer vervolgens de gebeurtenissen die haar heropenen: nieuwe informatie over kwetsbaarheden, nieuwe functies, wijzigingen in componenten of leveranciers, incidentbevindingen. Voeg een tabel met revisiegeschiedenis toe zodat toezichthouders kunnen zien dat het document leeft.

Mapping van de 13 beveiligingsvereisten

Dit is de kern van de beoordeling. De CRA somt 13 productbeveiligingsvereisten op, en uw document moet voor elk daarvan twee vragen beantwoorden: is de vereiste van toepassing, en hoe implementeert u haar. De tabel hieronder vertaalt elke vereiste naar toetsvragen en typisch bewijs.

De kolom Vereiste blijft dicht bij de wettelijke formulering. De kolom Maatregelen maakt geen deel uit van de wet: ze somt de maatregelen en het bewijs op die teams doorgaans gebruiken om aan te tonen dat aan de vereiste is voldaan.

Twee praktische opmerkingen bij het gebruik van de tabel:

• “Waar van toepassing” is een besluit per product, en u moet het verdedigen. De vereisten gelden op basis van uw risicobeoordeling. Een standalone softwaretool die geen gegevens en geen instellingen bevat, kan de uitsluiting van de vereiste voor gegevensverwijdering rechtvaardigen. Geen enkel product kan het updatevermogen uitsluiten alleen omdat updates onhandig zijn.
• De mapping doet ook dienst als index voor uw conformiteitsbewijs. De kolom Maatregelen van elke rij vertelt u wat in het technisch dossier thuishoort, en het is het materiaal dat een conformiteitsbeoordeling zal onderzoeken.

Dekking van de kwetsbaarheidsafhandelingsprocessen

De beoordeling moet ook aangeven hoe uw lopende processen het product dekken. De procesvereisten van de CRA zijn de operationele kant van dezelfde medaille. Uw beoordeling moet, kort en met verwijzingen naar de verantwoordelijke procesdocumenten, bevestigen dat u voor dit product:

• kwetsbaarheden en componenten identificeert en documenteert, inclusief een SBOM die ten minste de directe afhankelijkheden dekt
• kwetsbaarheden zonder onnodige vertraging aanpakt en verhelpt, met beveiligingsupdates die waar technisch haalbaar los van functie-updates worden geleverd
• doeltreffende en regelmatige tests en reviews van de beveiliging van het product uitvoert
• zodra een update beschikbaar is, de verholpen kwetsbaarheid publiek openbaar maakt met een beschrijving, de getroffen producten, de impact, de ernst en hulp bij het verhelpen ervan. Een gerechtvaardigd uitstel is toegestaan wanneer de beveiligingsrisico's van publicatie zwaarder wegen dan de voordelen, en alleen totdat gebruikers de kans hebben gehad de patch toe te passen
• een beleid voor gecoördineerde kwetsbaarheidsopenbaarmaking hanteert
• een contactadres beschikbaar stelt voor meldingen van kwetsbaarheden en helpt informatie over mogelijke kwetsbaarheden te laten doorstromen, ook voor componenten van derden
• updates via veilige mechanismen distribueert, zodat fixes tijdig aankomen, automatisch waar dat voor beveiligingsupdates geldt
• beveiligingsupdates zonder onnodige vertraging en kosteloos verspreidt, met adviesberichten die gebruikers vertellen wat te doen. Voor een product op maat kan een zakelijke klant alleen op het punt van kosteloosheid anders overeenkomen

Deze punten zijn werksamenvattingen, niet de volledige wettelijke formulering. Houd deze sectie kort in uw beoordeling, verwijs naar de verantwoordelijke procesdocumenten, en controleer de volledige vereisten in onze gids kwetsbaarheidsafhandeling.

Uitgewerkt voorbeeld

De onderstaande uittreksels tonen het detailniveau dat in de praktijk werkt. Het product is een fictieve connected omgevingssensor met een companion-app en clouddashboard.

Uittreksel risicoregister

CYBERBEVEILIGINGSRISICOBEOORDELING

Product: SmartSense Pro (SSP-3000)
Versie: 2.4.1
Beoordelingsdatum: January 2027
Eigenaar: [Naam, beveiligingsteam]

METHODE:
Waarschijnlijkheid x impact, schalen gedefinieerd in sectie 1.
Risico = Waarschijnlijkheid (1-5) x Impact (1-5)
Banden: Laag (1-4), Gemiddeld (5-9), Hoog (10-16), Kritiek (17-25)

-------------------------------------------------------------
RISICO-ID: R-001
DREIGING: Ongeautoriseerde firmwarewijziging
KWETSBAARHEID: Ongetekende firmware kan worden geïnstalleerd
IMPACT: 5 - Compromittering van het apparaat, datalek
WAARSCHIJNLIJKHEID: 3 - Vereist fysieke toegang of toegang tot het lokale netwerk
INHERENT RISICO: 15 (Hoog)

MAATREGEL: Verificatie van de firmwarehandtekening
IMPLEMENTATIE: ECDSA P-256-handtekening gecontroleerd vóór installatie
RESTRISICO: 3 (Laag) - Cryptografische aanval onwaarschijnlijk
STATUS: Gemitigeerd
-------------------------------------------------------------
RISICO-ID: R-002
DREIGING: Onderschepping van cloudcommunicatie
KWETSBAARHEID: Netwerkverkeer leesbaar onderweg
IMPACT: 4 - Blootstelling van gegevens, command injection
WAARSCHIJNLIJKHEID: 3 - Gedeelde en publieke netwerken te verwachten
INHERENT RISICO: 12 (Hoog)

MAATREGEL: TLS 1.3 met certificate pinning
IMPLEMENTATIE: Vastgezet CA-certificaat, geen fallback
RESTRISICO: 2 (Laag) - Compromittering van certificaat onwaarschijnlijk
STATUS: Gemitigeerd
-------------------------------------------------------------
[Vervolg voor alle geïdentificeerde risico's...]

RISICO-OVERZICHT:
Totaal aantal geïdentificeerde risico's: 23
Kritiek: 0
Hoog: 3 (alle gemitigeerd tot Laag of Gemiddeld)
Gemiddeld: 8 (alle gemitigeerd tot Laag)
Laag: 12 (geaccepteerd of gemitigeerd)

ACCEPTATIE VAN RESTRISICO:
Alle restrisico's binnen de tolerantie gedefinieerd in sectie 1.
Geaccepteerd door: [Beveiligingsverantwoordelijke], [Datum]

Uittreksel toepasselijkheidsrecord

TOEPASSELIJKHEID VAN DE BEVEILIGINGSVEREISTEN

VEREISTE 3 - BEVEILIGINGSUPDATES
Van toepassing: JA
Behandelde risico's: R-004, R-011
Implementatie: Ondertekende OTA-updates. Automatische beveiligingsupdates
standaard ingeschakeld, met opt-out en uitstelmogelijkheid in de
app-instellingen. Gebruikers worden in de app en per e-mail op de
hoogte gebracht.
Bewijs: Ontwerp updatemechanisme UMD-002

VEREISTE 12 - LOGGING EN MONITORING
Van toepassing: JA
Behandelde risico's: R-009
Implementatie: Beveiligingsgebeurtenissen (mislukte authenticatie,
configuratiewijzigingen, updategebeurtenissen) worden op het apparaat
vastgelegd en doorgestuurd naar de cloud. Opt-out voor logging
beschikbaar in de privacy-instellingen.
Bewijs: Ontwerp logging LD-001, gebeurtenissencatalogus

VEREISTE 13 - VEILIGE GEGEVENSVERWIJDERING
Van toepassing: JA
Behandelde risico's: R-015
Implementatie: Fabrieksreset wist permanent alle opgeslagen gegevens
en instellingen, inclusief netwerkgegevens. Het apparaat bevat geen
overdraagbare gebruikersgegevens, dus is er geen overdrachtspad.
Bewijs: Ontwerp reset en wissen RD-001

[Vervolg voor alle 13 vereisten...]

Let op de vermelding voor gegevensverwijdering: de vereiste dekt alle gegevens en instellingen, en opgeslagen netwerkgegevens tellen mee. Waar een vereiste écht niet van toepassing is, behoudt de vermelding dezelfde vorm, maar noemt ze de productfeiten die de vereiste wegnemen. Een standalone softwaretool zonder opgeslagen gegevens en zonder instellingen zou kunnen vastleggen: “Niet van toepassing. Het product bevat geen gegevens en geen instellingen. Er is niets te verwijderen.” Die feitelijke zin is wat een toezichthouder kan beoordelen.

Documentskelet

Een structuur die u kunt kopiëren voor de schriftelijke beoordeling:

CYBERBEVEILIGINGSRISICOBEOORDELING - [Product, versie]

1. METHODE
   Schalen, formule, risicobanden, acceptatiedrempels

2. PRODUCTCONTEXT
   Beoogd doel / Voorzienbaar gebruik en misbruik
   Operationele omgeving / Gebruikers
   Te beschermen bedrijfsmiddelen
   Verwachte gebruiksduur
   Reikwijdte: opgenomen componenten, uitsluitingen met redenen

3. ARCHITECTUUR EN AANVALSOPPERVLAK
   Interfaces, datastromen, vertrouwensgrenzen
   (verwijzing naar diagram)

4. RISICOREGISTER
   Eén vermelding per geloofwaardige dreiging, beoordeeld, met maatregel,
   restrisico en status

5. TOEPASSELIJKHEID VAN DE BEVEILIGINGSVEREISTEN
   Eén vermelding per vereiste (alle 13), van toepassing ja/nee,
   implementatie, verwijzing naar bewijs, rechtvaardiging waar
   niet van toepassing

6. SECURE-BY-DESIGN-BASISNIVEAU EN PROCESDEKKING
   Hoe het algehele beveiligingsniveau van het product aansluit bij
   de risico's, verwijzingen naar de processen voor kwetsbaarheidsafhandeling

7. RESTRISICO EN ACCEPTATIE
   Samenvatting, acceptatiecriteria, benoemde acceptatie

8. GOEDKEURING EN ONDERHOUD
   Eigenaar, goedkeuringsdatum
   Updatetriggers
   Tabel met revisiegeschiedenis

Houd de beoordeling actueel

De beoordeling is een levend document voor de hele ondersteuningsperiode. Heropen ze wanneer:

• er nieuwe informatie over kwetsbaarheden binnenkomt voor het product of de componenten ervan, via uw eigen monitoring, onderzoeksmeldingen of leveranciersadviezen
• het product wijzigt, en altijd wanneer een wijziging ingrijpend genoeg is om een nieuwe conformiteitsbeoordeling te vereisen
• componenten wijzigen, inclusief nieuwe leveranciers en versies van componenten van derden of opensourcecomponenten
• een incident u iets leert dat uw beoordelingen niet hadden voorzien

Leg elke revisie vast in de historietabel, met wat er is gewijzigd en waarom. Een beoordeling die drie jaar geleden eenmalig is gedateerd, vertelt een markttoezichtfunctionaris dat het document decoratief is.

Eén consistentieplicht wordt makkelijk over het hoofd gezien. Uw beoordeling houdt rekening met hoe lang het product naar verwachting in gebruik blijft. De ondersteuningsperiode die u vastlegt, moet die verwachte gebruiksduur weerspiegelen, afgewogen tegen de eigen wettelijke factoren daarvan. Beide vastleggingen moeten dus op elkaar aansluiten. Verwacht uw beoordeling acht jaar gebruik in het veld en bedraagt de vastgelegde ondersteuningsperiode vijf jaar, herzie dan de bepaling aan de hand van die factoren. De gebruikelijke uitkomst is een langere ondersteuningsperiode, geen voetnoot die het verschil verklaart.

Wie is eigenaar, en waar past de beoordeling in uw workflow

De CRA legt de verantwoordelijkheid bij de fabrikant. De verordening wijst geen interne rollen toe en schrijft geen risicobeoordelingsmethode of teamworkflow voor. Maar een beoordeling zonder eigenaar veroudert, dus verdelen werkende teams de taken doorgaans ongeveer zo:

• Product owner. Eigenaar van de context: beoogd doel, voorzienbaar gebruik, verwachte gebruiksduur. Bepaalt wat het product belooft, en tekent daarom af zodra die belofte verandert.
• Ontwikkelaars en architecten. Eigenaar van het dreigingsbeeld: interfaces, datastromen, de maatregelen die elk risico behandelen, en het bewijs dat die maatregelen bestaan.
• Security lead, of wie die pet draagt. Eigenaar van de methode, het register, het toepasselijkheidsrecord en de goedkeuring. In een klein team is dit één persoon die drie petten draagt, en dat werkt prima.

Koppel de updatetriggers vervolgens aan de momenten waarop al wordt gewerkt, zodat de beoordeling nooit afhangt van iemands geheugen:

Het pipeline-bewijs komt uit de tooling die u al gebruikt: SBOM-generatie in CI/CD voedt het componentregister, en uw proces voor kwetsbaarheidsafhandeling is wat de vermeldingen bij stap 4 heropent. De CRA schrijft de uitkomst voor, een gedocumenteerde en actuele beoordeling, niet de cyclus zelf. De cyclus is wat die verplichting behapbaar maakt naast de druk van de dagelijkse levering.

Componenten van derden

Het risico van uw product omvat ook de componenten erin. Wanneer u componenten van derden integreert, inclusief opensourcecomponenten, moet u due diligence uitvoeren zodat ze de beveiliging van het product niet ondermijnen. In de beoordeling betekent dat:

• componentrisico's staan waar relevant in het register, met de SBOM als de ruggengraat van de inventarisatie
• uw aanpak voor het selecteren en monitoren van componenten is vastgelegd, met verwijzingen naar leveranciersbewijs
• updatepaden voor componenten maken deel uit van de analyse van het updatevermogen

De praktische uitwerking, inclusief een leveranciersvragenlijst, vindt u in de gids leveranciers-due-diligence.

Waar de beoordeling zich bevindt

De schriftelijke beoordeling maakt deel uit van uw technisch dossier, naast de ontwerpdocumentatie, het testbewijs en de vastlegging van het besluit over de ondersteuningsperiode. Houd de goedgekeurde versie, de revisiegeschiedenis en het bewijs waarnaar ze verwijst, opvraagbaar zolang het dossier moet worden bewaard. De gids technische documentatie toont de structuur van het dossier en waar elk artefact staat.

Veelgemaakte fouten

• Achteraf geschreven. Een beoordeling die in de week voor uitlevering is opgesteld, kan het ontwerp niet hebben gestuurd. Reviewers merken dat.
• Geen toepasselijkheidsbesluiten. Een risicoregister alleen beantwoordt niet de vraag die de CRA stelt. Elk van de 13 vereisten heeft een expliciet antwoord nodig.
• “Niet van toepassing” zonder rechtvaardiging. Elke uitsluiting heeft een schriftelijke onderbouwing in het dossier nodig.
• Ongedocumenteerde methode. Scores zonder schalen, formules zonder definities.
• Bedrijfsbreed in plaats van op productniveau. Een ISMS-risicoregister dekt uw organisatie. De CRA wil dit product.
• Bevroren bij release. Geen revisiegeschiedenis, geen updatetriggers, geen koppeling met kwetsbaarheidsmonitoring.
• Inconsistent met de ondersteuningsperiode. Aannames over de verwachte gebruiksduur die de vastgelegde ondersteuningsperiode tegenspreken.
• Geen benoemd eigenaarschap. Niemand heeft ze goedgekeurd, niemand accepteert het restrisico, niemand is eigenaar van de updates.