Cyber Resilience

Restrisiko: jeres egen risikovillighed, omkostninger og kommercielle hensyn tæller ikke

Restrisiko: jeres egen risikovillighed, omkostninger og kommercielle hensyn tæller ikke

Restrisikoen i et softwareprodukt måles efter CRA mod et passende cybersikkerhedsniveau for produktets formål og brug. Virksomhedens egen risikovillighed, kommercielle strategi og rene omkostningshensyn kan ifølge Kommissionen ikke begrunde, at en risiko står ubehandlet.

Det vender den måde om, mange virksomheder er vant til at acceptere risiko på. Grundlaget er bilag I, del I, nr. 1, i forordning (EU) 2024/2847, som Kommissionen udlægger i vejledningen C(2026) 5252, punkt 157-166. Vejledningen er ikke bindende, men punkterne er usædvanligt klare. Kravet gælder fra 11. december 2027.

To slags risikostyring

I en organisations risikostyring vurderes risici ofte mod acceptkriterier, der udspringer af virksomhedens mål og risikovillighed. Ledelsen kan beslutte at leve med en risiko, fordi det er dyrere at fjerne den end at bære den.

Vejledningens punkt 157 siger, at det ikke er sådan, CRA fungerer for et produkt. Efter forordningen vurderes restrisikoen i lyset af kravet om et passende cybersikkerhedsniveau ud fra risiciene, formålet og den forudsigelige brug. Målestokken ligger uden for virksomheden.

Punkt 158 er endnu mere direkte. Fabrikantens interne risikotolerance, kommercielle strategi eller rene omkostningshensyn er ikke relevante for, om risici er behandlet. Det, der tæller, er, om risiciene er tilstrækkeligt behandlet gennem bilag I, del I, set i lyset af formål, forudsigelig brug, anvendelsesbetingelser, driftsmiljø, aktiver og forventet brugstid.

Restrisiko kan ikke fjernes helt

Vejledningen erkender i punkt 159, at restrisiko aldrig kan fjernes helt. Det betyder ikke, at enhver risiko kan accepteres efter fabrikantens skøn. Produktet må først bringes i omsætning, når restrisiciene er tilstrækkeligt behandlet.

Kan en risiko ikke behandles tilstrækkeligt, kan det kræve ændringer i design, funktionalitet eller formål (punkt 163). Hensyn alene til omkostninger eller kommerciel gennemførlighed er ikke nok til at lade en risiko stå, hvor det hindrer opfyldelse af kravene.

Bilag I, del I, nr. 1

Det overordnede krav i bilag I, del I, nr. 1, er, at produkter designes, udvikles og produceres, så de sikrer et passende cybersikkerhedsniveau baseret på risiciene. Vejledningen forklarer i punkt 164-166, at nr. 1 anses for opfyldt, når de øvrige krav er opfyldt og dækker alle risici. Er der risici, de øvrige krav ikke dækker, kræves yderligere foranstaltninger.

Det betyder, at en liste over opfyldte litraer i nr. 2 ikke afslutter vurderingen. Den sidste kontrol er, om der er risici tilbage, som ingen af litraerne har taget sig af.

Fire udsagn, en gennemgang ser efter

Følgende formuleringer i en risikovurdering er tegn på, at organisationens logik har sneget sig ind. Listen er vores egen og bygger på punkt 157-163.

“Risikoen accepteres af ledelsen.” Accept efter risikovillighed er netop det, punkt 158 udelukker. Spørgsmålet er, om risikoen er tilstrækkeligt behandlet for produktets formål og brug.

“Udbedring er ikke rentabel.” Omkostningshensyn alene er ikke en gyldig grund efter punkt 163.

“Kunden kan selv vælge at slå funktionen til.” Det kan være gyldigt, hvis det reelt behandler risikoen. Det er emnet i artiklen om, at risikoen ikke kan flyttes til brugeren.

“Lav sandsynlighed, accepteret.” Sandsynlighed er relevant, men vurderingen skal holdes op mod formål og brug. En lav sandsynlighed for en hændelse med stor virkning i et produkt til kritiske miljøer er ikke nødvendigvis et passende niveau.

Hvad det betyder for vurderingen

En vurdering af restrisiko efter CRA kan med fordel skrives anderledes end i et ISMS. I stedet for en kolonne med “accepteret af” kan der stå, hvorfor risikoen er tilstrækkeligt behandlet for produktets formål, og hvilke krav i bilag I der bærer behandlingen. Er det svært at skrive den begrundelse, er det et tegn på, at der mangler en foranstaltning, eller at formålet skal snævres ind. Det er praksis og intet lovkrav, men det gør punkt 158 til noget, der kan efterprøves.

Hvad det kræver, og hvad det koster at lade være

Det kræver, at produktets risikovurdering skrives med en anden begrundelse end virksomhedens risikoregister. Ledelsens accept kan stadig have en plads, men den kan ikke bære vurderingen alene.

En vurdering, der lukker risici med henvisning til omkostninger eller ledelsens accept, viser efter vejledningen det modsatte af det, den skal. Den dokumenterer, at en risiko er kendt og ikke behandlet.

Det skal I lade være med

  • At kopiere acceptkriterierne fra virksomhedens risikoregister · produktets restrisiko måles mod et passende niveau.
  • At lukke en risiko med omkostninger som eneste begrundelse · omkostninger alene er ikke nok efter punkt 163.
  • At stoppe ved listen over opfyldte litraer · bilag I, del I, nr. 1, spørger til de risici, der er tilbage.

Det skal auditten kunne vise

  • ☐ En begrundelse for hver restrisiko, der henviser til formål og forudsigelig brug.
  • ☐ Ingen restrisici lukket alene med henvisning til omkostninger eller risikovillighed.
  • ☐ En vurdering af, om bilag I, del I, nr. 1, er opfyldt ud over de enkelte litraer.
  • ☐ Spor af ændringer i design, funktionalitet eller formål, hvor en risiko ikke kunne behandles.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Søg i jeres risikovurdering efter ordene accepteret og omkostning, og læs hver begrundelse igen med punkt 158 i hånden.

Læs også: Kravet kan ikke opfyldes fuldt · Ny sårbarhed kort før release

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres software gennemgås?

Skriv kort, hvilket produkt det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.