[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"article:da:cra-cybersikkerhedsrisikovurderingen-hvad-artikel-13-faktisk-kraever":3},{"locale":4,"slug":5,"title":6,"description":7,"published":8,"body":9},"da","cra-cybersikkerhedsrisikovurderingen-hvad-artikel-13-faktisk-kraever","CRA-cybersikkerhedsrisikovurderingen: hvad artikel 13 faktisk kræver, og det ene resultat, den skal levere","Artikel 13, stk. 2 til 4, i Cyber Resilience Act gør risikovurderingen til det dokument, alle andre CRA-pligter hænger på. Den skal analysere risici ud fra det tilsigtede formål, den forventelige brug og brugsbetingelserne over den forventede brugstid; angive om og hvordan hvert krav i del I, punkt 2, gælder; sige hvordan del I, punkt 1, og del II anvendes; være dokumenteret, holdt ajour over supportperioden og indgå i den tekniske dokumentation, med en klar begrundelse for hvert udeladt krav. De fire stykker, og en struktur på én side, der opfylder dem.","2026-09-11","\nSpørg, hvad en fabrikant først skal gøre efter Cyber Resilience Act, forordning (EU) 2024\u002F2847, og de fleste svar siger \"den tekniske dokumentation\". Forordningen siger noget snævrere: Før dokumentationen, før [de 22 krav](\u002Farticles\u002Fcra-annex-i-the-22-essential-requirements-as-a-checklist) anvendes, er der en **cybersikkerhedsrisikovurdering**, og det er det dokument, der afgør, hvilke krav der gælder for jeres produkt, og begrunder hvert krav, I udelader. Artikel 13, stk. 2 til 4, beskriver den. De er korte og usædvanligt konkrete om, hvad vurderingen skal indeholde.\n\n## Hvad den er til: artikel 13, stk. 2\n\nFabrikanten \"foretager en vurdering af de cybersikkerhedsrisici, der er forbundet med et produkt med digitale elementer, og tager hensyn til resultatet af denne vurdering i planlægnings-, design-, udviklings-, produktions-, leverings- og vedligeholdelsesfaserne\", med henblik på at minimere cybersikkerhedsrisici, forebygge hændelser og minimere deres virkning, \"herunder i forhold til brugernes sundhed og sikkerhed\".\n\nTo ting følger. Det er et livscyklusdokument, ikke et lanceringsdokument: Resultatet tages i betragtning fra planlægning til vedligeholdelse. Og sundhed og sikkerhed er omfattet: Et produkt, hvis kompromittering kunne skade nogen, skal sige det og behandle den risiko.\n\n## Hvad den skal indeholde: artikel 13, stk. 3\n\nStk. 3 er det, man skal læse langsomt, for det opregner indholdet.\n\n**Dokumenteret og ajourført.** \"Cybersikkerhedsrisikovurderingen dokumenteres og ajourføres efter behov i en supportperiode.\" En risikovurdering lavet én gang ved lanceringen og aldrig revideret er ikke, hvad teksten beskriver; den ajourføres, når produktet, dets miljø og truslen ændrer sig, så længe [supportperioden](\u002Farticles\u002Fhow-long-is-the-cra-support-period) løber.\n\n**En analyse baseret på brug.** Den \"omfatter som minimum en analyse af cybersikkerhedsrisici baseret på det tilsigtede formål og den med rimelighed forventelige anvendelse samt brugsbetingelserne for produktet med digitale elementer, såsom driftsmiljøet eller de aktiver, der skal beskyttes, under hensyntagen til den periode, hvori produktet forventes at være i brug\". Inputtene er altså navngivet: hvad produktet er til, hvordan det forventeligt bruges og misbruges, hvor det kører, hvad det beskytter, og hvor længe.\n\n**En afgørelse om hvert krav i del I, punkt 2.** Den \"angiver, om og i givet fald hvordan sikkerhedskravene i bilag I, del I, punkt 2, finder anvendelse på det pågældende produkt med digitale elementer, og hvordan disse krav gennemføres på grundlag af cybersikkerhedsrisikovurderingen\". Det er den sætning, der gør vurderingen til dokumentationens rygrad: For hver af de tretten egenskaber \"hvor det er relevant\", gældende eller ej, og hvis ja, hvordan gennemført.\n\n**En erklæring om del I, punkt 1, og del II.** Den \"angiver også, hvordan fabrikanten skal anvende bilag I, del I, punkt 1, og kravene til håndtering af sårbarheder i bilag I, del II\". Punkt 1 (et passende cybersikkerhedsniveau) og de otte krav til håndtering af sårbarheder gælder altid; vurderingen siger hvordan.\n\n## Hvor den hører til, og begrundelsesreglen: artikel 13, stk. 4\n\nVurderingen indgår i den tekniske dokumentation ([bilag VII, punkt 3](\u002Farticles\u002Fwhat-goes-in-the-cra-technical-file-annex-vii-point-by-point)). Hvor et produkt også er omfattet af anden EU-ret med egen risikovurdering, må de to være ét dokument. Og den sætning, der betyder mest: \"Hvis visse væsentlige cybersikkerhedskrav ikke finder anvendelse på produktet med digitale elementer, medtager fabrikanten en klar begrundelse herfor i den tekniske dokumentation.\"\n\nEn udelukkelse uden skriftlig begrundelse er et hul. En begrundelse, der ikke kommer fra risikoanalysen (\"vi havde ikke tid\", \"vores konkurrenter gør det ikke\"), er ikke den slags begrundelse, teksten beder om.\n\n## En struktur på én side, der opfylder de fire stykker\n\nForordningen foreskriver ingen metode. Enhver struktureret metode virker, hvis dens resultat dækker indholdet ovenfor. Én, der gør det, i den rækkefølge, teksten antyder:\n\n1. **Produkt og tilsigtet formål.** Hvad det er, hvad det er til, de dækkede versioner og den forventede brugstid (som også fodrer supportperioden).\n2. **Forventelig brug og misbrug, og brugsbetingelser.** Hvem der bruger det, hvor det kører, hvad det forbinder til, hvad det beskytter (aktiverne), og hvordan et rimeligt misbrug ser ud.\n3. **Trusler og risici.** For hvert aktiv og hver grænseflade: hvad der kan gå galt, hvor sandsynligt, hvor slemt, inklusive sundhed og sikkerhed, hvor det er relevant. Enhver anerkendt metode (en trusselsmodel, et angrebstræ, et scoret register) er fin; teksten beder om en analyse, ikke en bestemt form.\n4. **Tabellen for del I, punkt 2.** Tretten rækker, litra a til m: gældende ja eller nej; hvis ja, hvordan gennemført; hvis nej, begrundelsen fra trin 3. Den tabel er den leverance, et bemyndiget organ eller en myndighed læser først.\n5. **Del I, punkt 1, og del II.** Hvordan det passende cybersikkerhedsniveau opnås samlet set, og hvordan hvert af de otte krav til håndtering af sårbarheder opfyldes i praksis: [SBOM'en](\u002Farticles\u002Fdoes-the-cra-require-an-sbom), offentliggørelsespolitikken, opdateringskanalen, kontaktpunktet.\n6. **Gennemgang.** Hvem der ejer den, hvornår den gennemgås næste gang, og hvad der udløser en tidligere gennemgang (en ny version, et nyt miljø, en indberettet sårbarhed). Vurderingen ajourføres over supportperioden, og dette afsnit siger hvordan.\n\nDatér den, versionér den, og arkivér den sammen med den tekniske dokumentation. Når produktet ændrer sig, så ændr vurderingen først og dokumentationen bagefter, for dokumentationen er vurderingens konsekvens, ikke omvendt.\n\n## Hvad den ikke behøver at være\n\nDen behøver ikke være lang: Teksten beder om \"som minimum\" en analyse og de to angivelser, og et kort dokument, der træffer hver afgørelse, er bedre end et langt, der ikke træffer nogen. Den behøver ikke en konsulents metodik, selv om en eksisterende (ISO\u002FIEC 27005, en trusselsmodelleringspraksis, der allerede er i brug) kan genbruges, så længe dens resultat mappes til de tretten rækker og erklæringen om del II. Og den behøver ikke vente på en harmoniseret standard: [Ingen er offentliggjort](\u002Farticles\u002Fthe-eu-s-own-cra-machinery-on-the-day-the-duty-started), og vurderingen er det, en fabrikant har i stedet.\n\n## Hvad Kommissionens FAQ tilføjer\n\nKommissionens FAQ om gennemførelsen, version 1.4 af 4. september 2026, afsnit 4.1, afgør fem ting, forordningen overlader til læseren.\n\n**Ingen metode er foreskrevet.** Post 4.1.2: \"CRA foreskriver ikke en bestemt metode til cybersikkerhedsrisikovurdering.\" Det, den kræver, er, at metoden \"støtter fabrikanterne i at dokumentere\", at hver relevant risiko er behandlet, så en myndighed \"kan verificere, hvordan risici er identificeret, evalueret og afbødet\", og at trusselsmodellen passer til produktet: Produkter til kritisk infrastruktur \"kan skulle behandle risici knyttet til statslige aktører og avancerede vedvarende trusler\", mens forbrugerprodukter \"typisk har en lavere risikoprofil og kan bruge en anden trusselsmodel\".\n\n**Del II altid, del I som risiciene siger.** Post 4.1.3: Kravene til sårbarhedshåndtering i bilag I, del II, gælder fuldt ud \"i hele produktets supportperiode\", mens fabrikanten for produktegenskaberne i del I \"på grundlag af cybersikkerhedsrisikovurderingen skal afgøre, hvilke af disse krav der er relevante\". Et krav, der lægges til side, kræver \"en klar begrundelse i den cybersikkerhedsrisikovurdering, der indgår i den tekniske dokumentation\". FAQ'ens eksempel er personoplysninger: Et produkt, hvis tilsigtede formål ikke omfatter behandling af personoplysninger, behøver måske ingen foranstaltning til beskyttelse af dem, og hvor en interoperabilitetsstandard, produktet skal følge (betragtning 55), gør et krav uanvendeligt, men efterlader en risiko, behandles risikoen \"på anden vis, f.eks. ved at begrænse produktets tilsigtede formål til betroede miljøer og\u002Feller ved at informere brugerne\".\n\n**Én vurdering kan tjene flere retsakter.** Post 4.1.1: En fabrikant \"kan gennemføre én enkelt risikovurdering, der dækker behovene i forskellige lovgivninger\", forudsat at den kan \"påvise overensstemmelse med hver enkelt lovgivning\". Vurderingen dækker \"hele produktet med digitale elementer, herunder fjerndatabehandling, når den er omfattet\", og hver fase fra planlægning til vedligeholdelse, for alle niveauer.\n\n**Tilsigtet formål er det, I offentliggør.** Post 4.1.4 med artikel 3(23): Det tilsigtede formål er den brug, fabrikanten angiver \"i brugsanvisningen, i salgs- og markedsføringsmateriale og -udsagn samt i den tekniske dokumentation\", og hvor produktet lader brugeren ændre konfigurationer eller sænke sikkerheden af hensyn til ældre kompatibilitet, hører de anvendelser med i vurderingen, får deres egen behandling og beskrives i brugsanvisningen.\n\n**Forudsigelig fejlanvendelse er også omfattet.** Post 4.1.5 med artikel 3(24): At udrulle et produkt \"på et usikkert netværk\", når vejledningen kræver et sikkert, \"kan udgøre en rimeligt forudsigelig fejlanvendelse\", og risici ved forudsigelig fejlanvendelse \"skal også meddeles i oplysningerne og vejledningen til brugeren\" efter bilag II, punkt 5. At hacke sin egen enhed for sjov eller for forskning er fejlanvendelse i denne forstand, ikke tilsigtet brug.\n\n## Kilder\n\n- Forordning (EU) 2024\u002F2847, artikel 13, stk. 1 til 4 (citeret), artikel 13, stk. 8, for supportperioden, artikel 31 og bilag VII, punkt 3, for dokumentationen, bilag I, del I og II. Læst i EU-Tidende-teksten på EUR-Lex den 11. september 2026.\n- Europa-Kommissionen, FAQ om Cyber Resilience Act, version 1.4 af 4. september 2026, posterne 4.1.1 til 4.1.5.\n\nDette er ikke juridisk rådgivning. Artikel 13, stk. 3, er ét stykke; læs det op imod jeres egen vurdering, og tjek, at hvert nævnt indhold er der.\n",1789383976494]