Risikovurdering og udviklingsproces

Risikovurderingen er det dokument, alle andre krav i Cyber Resilience Act hænger på. Den skal beskrive produktets formål og forudsigelige brug, driftsmiljøet og hvert krav i bilag I, og den skal begrunde hvert krav, I vælger fra. Forordningen siger ikke, hvilken metode I skal bruge, og der er endnu ingen harmoniserede standarder. Artiklerne her viser, hvad en gennemgang kontrollerer i vurderingen og i den udviklingsproces, der skal holde den levende fra første release til supportens sidste dag.

Vurderingens indhold

• Cybersikkerhedsrisikovurderingen for et softwareprodukt: det, gennemgangen kontrollerer Formål, brug, miljø og bilag I punkt for punkt.
• Tilsigtet formål og forudsigelig brug: produktside, dokumentation og integrationsscenarier Tre kilder, der skal sige det samme.
• “Ikke relevant”: begrundelser, der holder, og begrundelser, der ikke gør Fravalg prøvet mod det, softwaren gør.
• Afhængigheder uden for produktet: risici, softwaren selv skal kunne modstå Andres net og backend set fra jeres kode.

Risikoen, der bliver tilbage

• Restrisiko: jeres egen risikovillighed, omkostninger og kommercielle hensyn tæller ikke Målt mod et passende niveau.
• Risikoen kan ikke flyttes til brugeren: forudsigelig fejlanvendelse, og hvad anvisninger må bære En advarsel retter ikke en designfejl.
• Ny sårbarhed kort før release: frigiv eller udskyd, og sporet efter beslutningen Beslutningsnoten, der skal skrives.

Processen bag

• CRA foreskriver ingen metode: hvad måler en gennemgang af udviklingsprocessen så imod? En valgt og begrundet målestok.
• Hvornår i udviklingsforløbet skal gennemgangen ligge? Tre tidspunkter, der finder forskellige ting.
• Risikovurderingen i supportperioden: hvad udløser en ajourføring, og hvordan ses det bagefter? Anledningerne og sporet.
• Regelmæssige afprøvninger og gennemgange i supportperioden: et program, der følger truslerne Et program frem for en fast kalender.
• Ny byggekæde, ny proces eller ændret standard: proceduren efter artikel 13, stk. 14 Fortsat overensstemmelse, når processen lægges om.
• Kode skrevet af AI-assistenter: de samme krav i bilag I og det spor, en gennemgang beder om Værktøjet i risikovurderingen, foreslåede afhængigheder og gennemgang før frigivelse.

Sådan kommer I i gang

Vælg ét produkt og tag kravene i bilag I, del I, et ad gangen. Skriv for hvert, hvordan softwaren opfylder det, eller hvorfor det ikke er relevant for netop dette produkt, og henvis til det sted i koden, testen eller konfigurationen, hvor det kan ses. Beskriv dernæst, hvilken metode I har brugt, og hvorfor den passer. Har jeres organisation allerede en risikoproces fra NIS2- eller ISO-arbejdet, kan sitet om sikkerhedsaudit hjælpe med at skille den fra den produktvurdering, forordningen kræver her. Kunder, der vil se jeres proces, stiller ofte spørgsmål af den slags, der er beskrevet på sitet om leverandøraudit.

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

Vurderingen kræver folk, der kender produktets arkitektur og dets kunder, og den skal skrives, mens produktet udvikles, ikke bagefter. En vurdering, der først laves, når produktet er færdigt, ender som regel med at beskrive de valg, der allerede er truffet, og så er det dyrt at rette de krav, der viser sig ikke at være opfyldt.

Det skal I lade være med

• At skrive “ikke relevant” uden en grund, der kan efterprøves · fravalget skal passe med softwarens adfærd.
• At arkivere vurderingen ved første release · den skal følge produktet i hele supportperioden.
• At lade omkostninger begrunde en ubehandlet risiko · forordningen godtager det ikke.

Det skal auditten kunne vise

• ☐ En dateret risikovurdering pr. produkt, der dækker hvert krav i bilag I.
• ☐ Den valgte metode og grunden til valget.
• ☐ Ajourføringer med dato og anledning.
• ☐ Beslutningsnoter ved releases med kendte risici.

Senest gennemgået: november 2026.

Næste skridt

• Cybersikkerhedsrisikovurderingen for et softwareprodukt
• CRA foreskriver ingen metode

Læs også: Krav til produktet · Sårbarheder og opdateringer

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