Cyber Resilience

Cybersikkerhedsrisikovurderingen for et softwareprodukt: det, gennemgangen kontrollerer

Cybersikkerhedsrisikovurderingen for et softwareprodukt: det, gennemgangen kontrollerer

Cybersikkerhedsrisikovurderingen efter CRA handler om ét produkt og skal tage stilling til hvert enkelt af kravene i del I, nr. 2, i bilag I. En gennemgang kontrollerer, om de punkter, artikel 13, stk. 3, kræver som minimum, er der, og om vurderingen faktisk har styret design og udvikling.

Kravet gælder fra 11. december 2027 for alle produkter med digitale elementer, uanset klasse. Det står i artikel 13, stk. 2-4, i forordning (EU) 2024/2847, og Kommissionens tjenestegrene har uddybet det i FAQ’ens afsnit 4.1.

Produktets vurdering er en anden end organisationens

Mange softwarehuse har allerede en risikovurdering for virksomheden, fx i forbindelse med NIS2 eller informationssikkerhed. Genbrugt uændret dækker den ikke det, artikel 13, stk. 3, beder om. Produktets vurdering tager udgangspunkt i, hvad softwaren skal bruges til, hos hvem og i hvilket miljø. Organisationens vurdering handler om virksomhedens egne systemer og forretning. Den almene metode for risikovurdering af hele organisationen er et andet emne.

FAQ 4.1.1 siger, at vurderingen skal dække hele produktet, også fjerndatabehandling. Den dækker identifikation, analyse og evaluering af risici i design og udvikling og risikobehandlingen gennem produktion, levering og vedligeholdelse. Én samlet vurdering for flere EU-retsakter er tilladt, hvis fabrikanten kan vise, at kravene i hver af dem er opfyldt.

Minimumsindholdet efter artikel 13, stk. 3

Artikel 13, stk. 3, kræver, at vurderingen dokumenteres og ajourføres i relevant omfang i supportperioden. Den skal som minimum indeholde:

  • en analyse baseret på det tilsigtede formål og den anvendelse, der med rimelighed kan forudses,
  • anvendelsesbetingelserne, fx driftsmiljøet eller de aktiver, der skal beskyttes,
  • hensyn til, hvor længe produktet forventes at være i brug,
  • for hvert litra i bilag I, del I, nr. 2, om og hvordan det finder anvendelse og gennemføres,
  • hvordan fabrikanten anvender bilag I, del I, nr. 1, om et passende cybersikkerhedsniveau,
  • hvordan del II af bilag I om sårbarhedshåndtering anvendes.

Vurderingen skal indgå i den tekniske dokumentation (artikel 13, stk. 4, og bilag VII, nr. 3). Er et krav ikke relevant, skal der stå en klar begrundelse.

Det, en gennemgang ser efter

Ingen regel beskriver, hvordan en gennemgang af risikovurderingen udføres. Punkterne her er praksis udledt af ordlyden.

Krav for krav. Bilag I, del I, nr. 2, rummer en lang række litraer, fra kendte sårbarheder i litra a og sikker standardkonfiguration i litra b og videre. En vurdering, der kun behandler de risici, udviklerne selv har tænkt på, og ikke tager hvert litra op, mangler det, artikel 13, stk. 3, kræver.

Formålet passer til produktet. Det tilsigtede formål i vurderingen skal svare til det, der står i brugeroplysninger, salgsmateriale og teknisk dokumentation. Er formålet beskrevet snævrere i vurderingen end på produktsiden, hviler vurderingen på et forkert grundlag.

Hele produktet er med. Backend-tjenester, som klienten taler direkte med, er fjerndatabehandling og hører med. Andre systemer, produktet afhænger af, skal stå som eksterne afhængigheder med de risici, produktet selv skal kunne modstå.

Brugstiden er overvejet. Et produkt, der forventes brugt i mange år, skal have en vurdering, der tager højde for, at trusler og algoritmer ændrer sig.

Del II er med. Vurderingen skal også vise, hvordan sårbarhedshåndteringen anvendes. Det kan overses, når del II hører under en anden afdeling end udviklingen.

Når vurderingen er skrevet bagefter

Artikel 13, stk. 2, siger, at fabrikanten skal tage resultatet af vurderingen i betragtning ved planlægning, design, udvikling, produktion, levering og vedligeholdelse. For nye produkter er det derfor et fund, hvis vurderingen tydeligvis er skrevet, efter at produktet var færdigt. Det er vores tolkning af stk. 2.

Typiske tegn er, at vurderingen er dateret kort før frigivelse, at den ikke nævner et eneste designvalg, der blev ændret på grund af den, og at versionshistorikken kun har én version.

For produkter, der blev designet før anvendelsesdatoen, accepterer Kommissionen i sin vejledning C(2026) 5252 (punkt 35) en aktuel vurdering, der viser, at designet afbøder risiciene. Det er behandlet i artiklen om software designet før 2027.

Hvad myndigheden kan bede om

FAQ 4.1.8 nævner, at markedsovervågningsmyndigheden efter artikel 53 på begrundet anmodning kan få adgang til data, herunder intern dokumentation. Vurderingen og dens historik er derfor noget, I skal kunne udlevere. Vurderingen skal opbevares sammen med den tekniske dokumentation i mindst ti år efter omsætning, og i hele supportperioden, når den rækker længere (artikel 13, stk. 13).

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

Det kræver en vurdering pr. produkt, skrevet tidligt, gennemgået krav for krav og holdt ajour med versionshistorik. Den kan bygge på eksisterende trusselsmodeller, så længe den dækker det, artikel 13, stk. 3, nævner.

Uden den mangler grundlaget for alt det andet. Begrundelserne for krav, der ikke er relevante, supportperioden og standardkonfigurationen hviler alle på risikovurderingen.

Det skal I lade være med

  • At genbruge organisationens risikovurdering · produktets vurdering har et andet udgangspunkt.
  • At springe litraer over i stilhed · hvert krav skal have en stillingtagen eller en begrundelse.
  • At skrive vurderingen lige før frigivelse · den skal kunne have påvirket designet.

Det skal auditten kunne vise

  • ☐ En risikovurdering pr. produkt i den tekniske dokumentation.
  • ☐ En stillingtagen til hvert litra i bilag I, del I, nr. 2, og til del II.
  • ☐ Et tilsigtet formål, der svarer til brugeroplysninger og salgsmateriale.
  • ☐ Versionshistorik, der viser, hvornår vurderingen blev lavet og ændret.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Læg jeres risikovurdering ved siden af bilag I, del I, nr. 2, og sæt et flueben ud for hvert litra, den tager stilling til.

Læs også: Tilsigtet formål og forudsigelig brug · Risikovurderingen i supportperioden

→ 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.