CRA-cybersäkerhetsriskbedömning: guide och mall

Varje tillverkare av en produkt med digitala element inom CRA:s tillämpningsområde måste genomföra en cybersäkerhetsriskbedömning och dokumentera den skriftligt. Det är dokumentet som avgör vilka CRA-säkerhetskrav som binder just din produkt, och hur du uppfyller dem. Marknadskontrollmyndigheter kan begära att få se det. Utan det är din tekniska dokumentation ofullständig och din försäkran om överensstämmelse saknar grund.

Den här guiden förklarar hur du genomför bedömningen, hur du dokumenterar den och hur du håller den aktuell. Den innehåller en fullständig mappning av säkerhetskraven, ett genomarbetat exempel och en kopierbar dokumentmall.

Vad är CRA:s cybersäkerhetsriskbedömning?

Cybersäkerhetsriskbedömningen är en dokumenterad analys av de risker din produkt utsätts för, baserad på dess avsedda ändamål och de sätt användare rimligen kan förväntas använda den på. Den täcker användningsförhållandena, till exempel driftmiljön och de tillgångar produkten måste skydda, och den tar hänsyn till hur länge produkten förväntas vara i bruk.

Bedömningen har ett resultat som allt annat bygger på. Den anger, för vart och ett av CRA:s produktsäkerhetskrav, om kravet gäller för din produkt och, om så är fallet, hur din konstruktion och dina processer uppfyller det. Den registrerar också hur du uppfyller säkerhetsbaslinjen och hur dina sårbarhetshanteringsprocesser täcker produkten.

Tre egenskaper skiljer den från ett generellt företagsomfattande riskregister:

• Den är produktspecifik. Förankrad i just den produktens arkitektur, gränssnitt och användare. Ett företagsomfattande ISMS-riskregister uppfyller inte kravet. Vår jämförelse med ISO 27001 går igenom skillnaden i detalj.
• Den är ett dokument för hela livscykeln. Du använder den under planering och konstruktion, inte bara vid lansering. Och du uppdaterar den under hela stödperioden.
• Den är bevis. Den dokumenterade bedömningen ingår i din tekniska dokumentation, där myndigheter kan begära den.

Vem behöver en, och när

Varje tillverkare som släpper ut en produkt med digitala element på EU-marknaden behöver en, om inte produkten helt faller utanför CRA. Inom tillämpningsområdet: hårdvara med firmware, fristående programvara och produkter vars fjärrdatabehandling är en del av erbjudandet. Kravet gäller ett enmansföretag inom programvara på samma sätt som en multinationell koncern. Produkter som CRA undantar, till exempel vissa medicintekniska produkter, vissa fordon och certifierad flygutrustning, följer i stället sina egna sektorsregler. Är du osäker på om CRA överhuvudtaget omfattar din produkt, börja med guiden om tillämpningsområdet.

Tidpunkten spelar större roll än de flesta team räknar med:

• Börja under planeringen. Bedömningen är tänkt att styra konstruktionsbeslut. Gör en första genomgång medan arkitekturen fortfarande är billig att ändra.
• Slutför och dokumentera den innan produkten släpps ut på marknaden. Den skriftliga bedömningen måste finnas i den tekniska dokumentationen när produkten skickas.
• Underhåll den under hela stödperioden. Bedömningen är aldrig slutgiltig. Den följer produkten så länge du är skyldig att leverera säkerhetsuppdateringar.

Det finns en smal förenkling. Den täcker bara de produkter som CRA behandlar som AI-system med hög risk och som samtidigt omfattas av annan EU-lagstiftning som kräver en riskbedömning. För dem kan cybersäkerhetsbedömningen bli en del av den andra riskbedömningen i stället för ett separat dokument. Innehållskraven är desamma. Se guiden om överlappet med AI-förordningen för hur det fungerar i praktiken.

Vad bedömningen måste innehålla

CRA sätter en minimibaslinje för innehållet. Din bedömning måste täcka tre saker:

• Produkten i sitt sammanhang. Vad produkten är till för, hur användare rimligen kan förväntas använda den, miljön den verkar i, de tillgångar den måste skydda och hur länge den förväntas vara i bruk.
• Tillämplighetsbeslut. För vart och ett av de 13 produktsäkerhetskraven: gäller det för produkten, och hur implementeras det. Där ett krav inte gäller, en tydlig skriftlig motivering.
• Processtäckning. Hur säkerhetsbaslinjen uppfylls och hur dina sårbarhetshanteringsprocesser täcker produkten.

Motiveringsplikten förtjänar att understrykas. ”Inte tillämpligt” utan skäl är en brist. Namnge de produktfakta som gör att kravet faller bort, och skriv ned dem. Den skriftliga motiveringen ingår i den tekniska dokumentationen tillsammans med resten av bedömningen.

Utöver detta rättsliga minimum, lägg till de kontroller som gör dokumentet försvarbart: behandlingsbeslut med sin kvarstående risk, acceptanskriterier, ett namngivet godkännande med datum och en revisionshistorik. CRA kräver inget av detta. Det är så du visar att bedömningen hållits aktuell, och att någon ansvarig accepterat den kvarstående risken.

Välj en metod

CRA kräver ingen bedömningsmetodik, betygsskala eller mall. Vad som krävs är ett dokumenterat resultat som stödjer tillämplighetsbesluten. Välj en metod ditt team kan upprepa, och beskriv den i bedömningen så att en granskare kan följa ditt resonemang.

En regel gäller oavsett vilken metod du väljer. Uttryck varje risk som en kombination av dess sannolikhet och omfattningen av den förlust eller störning den kan orsaka. CRA ramar in cybersäkerhetsrisk i precis dessa två dimensioner, så en hotlista som inte värderar någon av dem är ännu ingen bedömning.

Vanliga fungerande val:

Metod	Vad den ger dig	Passar bäst för
Sannolikhet x konsekvens-matris	Enkla numeriska riskvärden och ett rangordnat register	Små team, första bedömningar
STRIDE-liknande hotmodellering	Systematisk hotidentifiering per komponent och dataflöde	Mjukvarutunga produkter med tydliga arkitekturdiagram
Process i ISO/IEC 27005-stil	En fullständig riskhanteringscykel med kontext, analys och behandling	Organisationer som redan driver ett ledningssystem för informationssäkerhet
IEC 62443 hot-riskmetod	Zon- och kanalanalys för industriella sammanhang	Industriella produkter och OT-produkter, se guiden om industriell automation

De kommande harmoniserade standarderna ändrar inte det fria metodvalet. Utkastet till den europeiska ramverksstandarden för CRA-riskhantering är i sig metodneutralt, byggt på riskprocessen i ISO 31000 utan att föreskriva en poängsättningsmodell. Vår sida om status för harmoniserade standarder följer dess framsteg. Och standarder ersätter aldrig bedömningen: även en produkt som tillämpar harmoniserade standarder fullt ut behöver sin egen dokumenterade bedömning, och du måste kontrollera att standarderna täcker de risker du faktiskt identifierat.

Oavsett vad du väljer, håll två regler:

1. Metoden måste ge tillämplighetssvar. En hög med värderade risker räcker inte. Resultatet måste kopplas till de 13 säkerhetskraven nedan.
2. Skriv ned metoden. Skaldefinitioner, formel, acceptanströsklar. Ett värde på ”12 (Hög)” betyder ingenting om skalan inte är dokumenterad. Dokumentationen bör göra det möjligt för en marknadskontrollmyndighet att verifiera hur varje risk identifierades, värderades och behandlades.

Bedömningen, steg för steg

En fungerande process i sju steg. Anpassa djupet efter din produkts komplexitet och risk.

Steg 1: Definiera omfattning och sammanhang

Registrera produktens namn och version, dess avsedda ändamål, miljöerna den ska köras i och dess användare. Ange vad som ingår, inklusive kompletterande appar, molnbackender som är en del av erbjudandet och medföljande komponenter. Ange vad som inte ingår och varför.

Steg 2: Identifiera tillgångar

Lista vad produkten måste skydda. Typiska tillgångar är användardata, autentiseringsuppgifter och nycklar, integriteten hos firmware och konfiguration, tillgängligheten hos produktens funktion och det omgivande nätverket. Notera var varje tillgång finns och hur den rör sig.

Steg 3: Identifiera hot

Gå igenom din arkitektur yta för yta. Externa gränssnitt först, eftersom angripare börjar där. För varje gränssnitt och dataflöde, fråga vad en angripare skulle kunna göra: avlyssna, förfalska, manipulera, överbelasta, extrahera. Ta med förutsebart missbruk av produkten, inte bara avsiktliga angrepp. Registrera varje trovärdigt hot tillsammans med den sårbarhet det skulle utnyttja.

Steg 4: Värdera riskerna

Värdera sannolikhet och konsekvens för varje hot enligt din dokumenterade skala. Där en incident skulle kunna orsaka fysisk skada, ta med effekten på användarnas hälsa och säkerhet i konsekvensvärderingen. Rangordna resultaten. Poängen med värderingen är prioritering, inte precision. En försvarbar rangordning som styr konstruktionsbeslut slår en till synes exakt tabell som ingen använder.

Steg 5: Bestäm tillämpligheten för säkerhetskraven

Gå igenom de 13 produktsäkerhetskraven ett i taget. För varje: ange om det gäller för produkten, vilka av dina identifierade risker det hanterar och hur du implementerar det. Där ett krav genuint inte gäller, skriv motiveringen. Den fullständiga mappningstabellen nedan är ditt arbetsunderlag.

Steg 6: Behandla riskerna och registrera kvarstående risk

För varje väsentlig risk, registrera den kontroll du valt, var den är implementerad och den kvarstående risken efter kontrollen. Definiera acceptanskriterier och registrera vem som accepterade den kvarstående risken. Risker utan kontroll behöver ett uttryckligt, ägt acceptansbeslut.

Steg 7: Godkänn och sätt underhållstriggers

Låt en namngiven ägare godkänna bedömningen, med datum. Definiera sedan de händelser som öppnar den på nytt: ny sårbarhetsinformation, nya funktioner, ändringar av komponenter eller leverantörer, resultat från incidenter. Lägg till en revisionshistorik så att myndigheter kan se att dokumentet har levt.

Mappning av de 13 säkerhetskraven

Detta är bedömningens kärna. CRA listar 13 produktsäkerhetskrav, och ditt dokument måste besvara två frågor för vart och ett: gäller det, och hur implementerar du det. Tabellen nedan översätter varje krav till granskningsfrågor och typiska bevis.

Kravkolumnen ligger nära den juridiska formuleringen. Kontrollkolumnen är inte en del av lagtexten: den listar de åtgärder och bevis team vanligtvis använder för att visa att kravet är uppfyllt.

Två praktiska anmärkningar om hur tabellen används:

• ”Där tillämpligt” är ett beslut per produkt, och det är ditt att försvara. Kraven gäller på grundval av din riskbedömning. Ett fristående programvaruverktyg som varken lagrar data eller inställningar kan motivera att utesluta kravet på dataradering. Ingen produkt kan utesluta uppdateringsförmåga bara för att uppdateringar är opraktiska.
• Mappningen fungerar även som ditt index över bevis för överensstämmelse. Varje rads kontrollkolumn talar om vad som hör hemma i den tekniska dokumentationen, och det är det underlag en bedömning av överensstämmelse kommer att granska.

Täcka processerna för sårbarhetshantering

Bedömningen måste också ange hur dina löpande processer täcker produkten. CRA:s processkrav är den operativa sidan av samma mynt. Din bedömning bör kortfattat, med hänvisningar till de ägande dokumenten, bekräfta att du för denna produkt:

• identifierar och dokumenterar sårbarheter och komponenter, inklusive en SBOM som täcker minst beroenden på toppnivå
• åtgärdar sårbarheter utan dröjsmål, med säkerhetsuppdateringar levererade separat från funktionsuppdateringar där det är tekniskt möjligt
• tillämpar effektiv och regelbunden testning och granskning av produktens säkerhet
• offentliggör, när en uppdatering väl finns, den åtgärdade sårbarheten med en beskrivning, berörda produkter, konsekvenser, allvarlighetsgrad och hjälp med åtgärder. En motiverad fördröjning är tillåten där säkerhetsriskerna med publicering överväger fördelarna, och bara fram till dess att användare haft möjlighet att installera patchen
• driver en policy för samordnad sårbarhetsredovisning
• tillhandahåller en kontaktadress för sårbarhetsrapporter och hjälper information om potentiella sårbarheter att flöda, inklusive för tredjepartskomponenter
• distribuerar uppdateringar genom säkra mekanismer så att fixar når fram i tid, automatiskt där det gäller säkerhetsuppdateringar
• sprider säkerhetsuppdateringar utan dröjsmål och kostnadsfritt, med rådgivande meddelanden som talar om för användarna vad de ska göra. För en skräddarsydd produkt kan en företagskund komma överens om annat, men bara på punkten om kostnadsfrihet

Dessa punkter är arbetssammanfattningar, inte den fullständiga juridiska formuleringen. Håll det här avsnittet kort i din bedömning, länka till de ansvariga processdokumenten och kontrollera de fullständiga kraven i vår guide om sårbarhetshantering.

Genomarbetat exempel

Utdragen nedan visar den detaljnivå som fungerar i praktiken. Produkten är en fiktiv uppkopplad miljösensor med en kompletterande app och molndashboard.

Utdrag ur riskregistret

CYBERSECURITY RISK ASSESSMENT

Produkt: SmartSense Pro (SSP-3000)
Version: 2.4.1
Bedömningsdatum: January 2027
Ägare: [Namn, säkerhetsteamet]

METOD:
Sannolikhet x konsekvens, skalorna definierade i avsnitt 1.
Risk = Sannolikhet (1-5) x Konsekvens (1-5)
Nivåer: Låg (1-4), Medel (5-9), Hög (10-16), Kritisk (17-25)

-------------------------------------------------------------
RISK-ID: R-001
HOT: Obehörig ändring av firmware
SÅRBARHET: Osignerad firmware skulle kunna installeras
KONSEKVENS: 5 - Enheten komprometteras, dataintrång
SANNOLIKHET: 3 - Kräver fysisk eller lokal nätverksåtkomst
URSPRUNGLIG RISK: 15 (Hög)

KONTROLL: Verifiering av firmwaresignatur
IMPLEMENTERING: ECDSA P-256-signatur kontrolleras före installation
KVARSTÅENDE RISK: 3 (Låg) - Kryptografiskt angrepp osannolikt
STATUS: Åtgärdad
-------------------------------------------------------------
RISK-ID: R-002
HOT: Avlyssning av molnkommunikation
SÅRBARHET: Nätverkstrafik läsbar under överföring
KONSEKVENS: 4 - Dataexponering, kommandoinjektion
SANNOLIKHET: 3 - Delade och publika nätverk förväntas
URSPRUNGLIG RISK: 12 (Hög)

KONTROLL: TLS 1.3 med certifikatpinning
IMPLEMENTERING: Fastnålat CA-certifikat, ingen reservlösning
KVARSTÅENDE RISK: 2 (Låg) - Certifikatkompromettering osannolik
STATUS: Åtgärdad
-------------------------------------------------------------
[Fortsätt för alla identifierade risker...]

RISKSAMMANFATTNING:
Totalt identifierade risker: 23
Kritisk: 0
Hög: 3 (alla åtgärdade till Låg eller Medel)
Medel: 8 (alla åtgärdade till Låg)
Låg: 12 (accepterade eller åtgärdade)

ACCEPTANS AV KVARSTÅENDE RISK:
Alla kvarstående risker inom toleransen definierad i avsnitt 1.
Accepterat av: [Säkerhetsansvarig], [Datum]

Utdrag ur tillämplighetsregistret

SECURITY REQUIREMENTS APPLICABILITY

KRAV 3 - SÄKERHETSUPPDATERINGAR
Gäller: JA
Hanterade risker: R-004, R-011
Implementering: Signerade OTA-uppdateringar. Automatiska
säkerhetsuppdateringar aktiverade som standard, med möjlighet
att avstå eller skjuta upp i appinställningarna. Användare
notifieras i appen och via e-post.
Bevis: Design av uppdateringsmekanism UMD-002

KRAV 12 - LOGGNING OCH ÖVERVAKNING
Gäller: JA
Hanterade risker: R-009
Implementering: Säkerhetshändelser (misslyckade
inloggningsförsök, konfigurationsändringar,
uppdateringshändelser) registreras på enheten och
vidarebefordras till molnet. Möjlighet att avstå från
loggning finns i integritetsinställningarna.
Bevis: Loggdesign LD-001, händelsekatalog

KRAV 13 - SÄKER DATARADERING
Gäller: JA
Hanterade risker: R-015
Implementering: Fabriksåterställning raderar permanent all
lagrad data och alla inställningar, inklusive
nätverksuppgifter. Enheten innehåller ingen överförbar
användardata, så ingen överföringsväg finns.
Bevis: Design av återställning och radering RD-001

[Fortsätt för alla 13 krav...]

Notera posten om dataradering: kravet täcker alla data och inställningar, och lagrade nätverksuppgifter räknas in. Där ett krav genuint inte gäller behåller posten samma form men namnger de produktfakta som gör att det faller bort. Ett fristående programvaruverktyg utan lagrad data och utan inställningar skulle kunna registrera: ”Inte tillämpligt. Produkten innehåller ingen data och inga inställningar. Det finns inget att ta bort.” Den faktabaserade meningen är vad en myndighet kan bedöma.

Dokumentmall

En struktur du kan kopiera för den skriftliga bedömningen:

CYBERSECURITY RISK ASSESSMENT - [Produkt, version]

1. METOD
   Skalor, formel, risknivåer, acceptanströsklar

2. PRODUKTENS SAMMANHANG
   Avsett ändamål / Förutsebar användning och missbruk
   Driftmiljö / Användare
   Tillgångar som ska skyddas
   Förväntad användningstid
   Omfattning: ingående komponenter, undantag med skäl

3. ARKITEKTUR OCH ANGREPPSYTA
   Gränssnitt, dataflöden, förtroendegränser
   (diagramreferens)

4. RISKREGISTER
   En post per trovärdigt hot, värderad, med kontroll,
   kvarstående risk och status

5. TILLÄMPLIGHET FÖR SÄKERHETSKRAVEN
   En post per krav (alla 13), gäller ja/nej,
   implementering, bevispekare, motivering där
   kravet inte gäller

6. SÄKERHETSBASLINJE OCH PROCESSTÄCKNING
   Hur produktens övergripande säkerhetsnivå matchar dess
   risker, hänvisningar till processer för sårbarhetshantering

7. KVARSTÅENDE RISK OCH ACCEPTANS
   Sammanfattning, acceptanskriterier, namngivet godkännande

8. GODKÄNNANDE OCH UNDERHÅLL
   Ägare, godkännandedatum
   Uppdateringstriggers
   Revisionshistorik

Håll den aktuell

Bedömningen är ett levande dokument under hela stödperioden. Öppna den på nytt när:

• ny sårbarhetsinformation dyker upp för produkten eller dess komponenter, från din egen övervakning, forskarrapporter eller leverantörsrekommendationer
• produkten ändras, och alltid när en ändring är tillräckligt väsentlig för att kräva en ny bedömning av överensstämmelse
• komponenter ändras, inklusive nya leverantörer och versioner av tredjeparts- eller öppen källkod-komponenter
• en incident lär dig något dina värderingar inte förutsåg

Registrera varje revision i historiktabellen, med vad som ändrades och varför. En bedömning daterad en gång, för tre år sedan, talar om för en marknadskontrollhandläggare att dokumentet är dekorativt.

En konsekvensplikt är lätt att missa. Din bedömning beaktar hur länge produkten förväntas vara i bruk. Den stödperiod du deklarerar måste spegla den förväntade användningstiden, vägd mot sina egna lagstadgade faktorer. Så de två registren måste stämma överens. Om din bedömning förväntar sig åtta år i fält och din deklarerade stödperiod är fem, se över fastställandet mot de faktorerna. Det vanliga utfallet är en längre stödperiod, inte en fotnot som förklarar gapet.

Vem äger den, och var den passar i ditt arbetsflöde

CRA gör tillverkaren ansvarig. Den tilldelar inte interna roller och kräver inte en specifik riskbedömningsmetodik eller ett arbetsflöde för teamet. Men en bedömning som ingen äger blir föråldrad, så arbetande team delar upp den ungefär så här:

• Produktägaren. Äger sammanhanget: avsett ändamål, förutsebar användning, förväntad användningstid. Bestämmer vad produkten lovar, och godkänner därför när löftet ändras.
• Utvecklare och arkitekter. Äger hotbilden: gränssnitt, dataflöden, de kontroller som behandlar varje risk och beviset för att kontrollerna finns.
• Säkerhetsansvarig, eller den som bär den hatten. Äger metoden, registret, tillämplighetsposten och godkännandet. I ett litet team är detta en person som bär tre hattar, och det fungerar.

Koppla sedan in uppdateringstriggers i de stunder där arbetet redan sker, så att bedömningen aldrig är beroende av att någon kommer ihåg den:

Pipeline-bevisen kommer från de verktyg du redan kör: SBOM-generering i CI/CD matar registerposten, och din process för sårbarhetshantering är det som öppnar poster på nytt i steg 4. CRA kräver resultatet, en dokumenterad bedömning som hålls aktuell, inte cykeln. Cykeln är det som gör den plikten uthärdlig mitt i verkligt leveranstryck.

Tredjepartskomponenter

Din produkts risk inkluderar komponenterna inuti den. När du integrerar tredjepartskomponenter, inklusive komponenter med öppen källkod, måste du utöva tillbörlig aktsamhet så att de inte äventyrar produktens säkerhet. I bedömningen betyder det att:

• komponentrisker syns i registret där de är väsentliga, med SBOM som inventeringens ryggrad
• ditt tillvägagångssätt för urval och övervakning av komponenter anges, med hänvisningar till leverantörsbevis
• uppdateringsvägar för komponenter är en del av analysen av uppdateringsförmåga

Den praktiska mekaniken, inklusive ett leverantörsfrågeformulär, finns i guiden om leverantörers due diligence.

Var bedömningen finns

Den skriftliga bedömningen är en del av din tekniska dokumentation, tillsammans med konstruktionsdokumentation, testbevis och beslutsposten för stödperioden. Håll den godkända versionen, dess revisionshistorik och de bevis den pekar på åtkomliga så länge dokumentationen måste bevaras. Guiden om teknisk dokumentation visar filstrukturen och var varje artefakt hör hemma.

Vanliga misstag

• Skriven i efterhand. En bedömning som tas fram veckan innan leverans kan inte ha påverkat konstruktionen. Granskare märker det.
• Inga tillämplighetsbeslut. Ett riskregister ensamt besvarar inte den fråga CRA ställer. Vart och ett av de 13 kraven behöver ett uttryckligt svar.
• ”Inte tillämpligt” utan motivering. Varje undantag behöver skriftligt resonemang i dokumentationen.
• Odokumenterad metod. Värderingar utan skalor, formler utan definitioner.
• Företagsnivå i stället för produktnivå. Ett ISMS-riskregister täcker din organisation. CRA vill ha den här produkten.
• Fryst vid release. Ingen revisionshistorik, inga uppdateringstriggers, ingen koppling till sårbarhetsövervakning.
• Inkonsekvent med stödperioden. Antaganden om förväntad användning som motsäger det deklarerade stödfönstret.
• Inget namngivet ägarskap. Ingen har godkänt den, ingen accepterar kvarstående risk, ingen äger uppdateringarna.