Software skal beskytte tilgængeligheden af sine væsentlige og grundlæggende funktioner, også efter en hændelse, og den skal begrænse den skade, den selv kan gøre på andres tjenester. De to krav er litra h og litra i i bilag I, del I, nr. 2. De to får virkning den 11. december 2027.
Det ene krav vender indad, det andet udad. Tilsammen handler de om, hvordan softwaren opfører sig under pres.
De to krav
Litra h kræver, at produktet beskytter tilgængeligheden af væsentlige og grundlæggende funktioner, også efter en hændelse, herunder gennem modstandsdygtigheds- og afbødningsforanstaltninger mod denial of service-angreb.
Litra i kræver, at produktet minimerer den negative indvirkning, som det selv eller forbundne enheder har på tilgængeligheden af tjenester, der leveres af andre enheder eller netværk.
Hvor meget de to krav vejer, afhænger af produktet og står i risikovurderingen. Et program, der kun kører lokalt uden netværk, har en kort vurdering af litra i. En klient, der taler med en central tjeneste fra tusindvis af installationer, har en lang.
Hvilke funktioner er væsentlige?
Litra h beskytter de væsentlige funktioner, men siger ikke, hvilke de er. Bilag II, nr. 4, kræver, at brugeroplysningerne angiver produktets væsentlige funktioner. Vores tolkning er, at den liste er det naturlige udgangspunkt for, hvad litra h skal beskytte. Det, I selv har kaldt væsentligt over for brugeren, kan I vanskeligt undlade at beskytte.
En gennemgang begynder derfor med at sammenholde bilag II-oplysningerne med risikovurderingen. Står de samme funktioner begge steder? Har risikovurderingen taget stilling til, hvad der sker med hver af dem, når produktet bliver overbelastet, mister forbindelsen eller får ugyldige data?
Adfærd ved udfald
Kommissionens vejledning nævner, at et udfald af en ekstern tjeneste kan kræve foranstaltninger i produktet, så udfaldet ikke bringer produktet i en usikker tilstand. Det er et eksempel, ikke en udtømmende liste.
For software betyder det typisk spørgsmål som disse. Hvad gør klienten, når serveren ikke svarer? Låser den sig, falder den tilbage til en sikker tilstand, eller åbner den op? Hvad sker der med data, der var undervejs? Kan brugeren stadig bruge de funktioner, der ikke kræver forbindelse?
Adfærden kan dokumenteres uden at angribe noget. En almindelig fremgangsmåde er at afbryde forbindelsen til en afhængighed i et testmiljø, sende flere forespørgsler, end produktet er dimensioneret til, eller give det misdannede data, og så skrive ned, hvad der sker. Det er en belastningsprøve i eget miljø, og den er praksis. Forordningen kræver ikke en bestemt prøve.
Når softwaren selv bliver problemet
Litra i er mindre kendt. Den handler om, at produktet ikke må gøre andres tjenester utilgængelige. Kilderne giver ingen konkrete eksempler for software, så de følgende er tænkte.
En klient, der mister forbindelsen og prøver igen med det samme, igen og igen, kan sammen med alle andre installationer lægge en tjeneste ned, når den kommer op igen. En opdatering, der rulles ud til alle installationer på samme minut, kan belaste både fabrikantens egen server og kundernes netværk. En funktion, der scanner det lokale netværk for enheder, kan forstyrre andet udstyr.
Til hvert eksempel findes kendte modtræk, for eksempel voksende ventetid mellem genforsøg, tilfældig spredning af tidspunkter og grænser for, hvor meget produktet sender. Hvilke der passer, er et spørgsmål for risikovurderingen.
Hvordan en gennemgang prøver det
Gennemgangen ser først på dokumentationen: listen over væsentlige funktioner, risikovurderingens stillingtagen til litra h og i og resultater af belastnings- og udfaldsprøver. Derefter kan den gentage enkelte prøver i en installeret kopi for at se, om produktet gør, hvad dokumentationen siger. Det sidste er praksis, og der fandtes pr. november 2026 ingen harmoniseret standard i EU-Tidende, der foreskriver, hvordan det skal ske.
Tilgængelighed efter en hændelse
Litra h nævner udtrykkeligt tiden efter en hændelse. Det peger på genopretning. Kan produktet komme tilbage i drift efter et nedbrud uden manuelle indgreb, der kræver fabrikantens hjælp? Kan det starte op i en sikker tilstand, hvis dets data er beskadiget? Spørgsmålene er vores læsning af ordlyden. De er nyttige, fordi de kan besvares med en prøve i testmiljøet og en kort beskrivelse i dokumentationen. Backup og drift hos kunden er derimod kundens sag og hører ikke til produktkravet.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over væsentlige funktioner, der stemmer med brugeroplysningerne, en beskrivelse af produktets adfærd ved udfald og overbelastning og en vurdering af, hvordan produktet kan belaste andre.
Uden det opdager I adfærden første gang, den sker hos kunderne. Et produkt, der åbner op, når det ikke kan nå sin server, eller som lægger en fælles tjeneste ned ved genstart, er en risiko for både brugeren og andre.
Det skal I lade være med
- At kalde en funktion væsentlig i brugeroplysningerne uden at beskytte den · de to dokumenter skal hænge sammen.
- At teste tilgængelighed ved at angribe andres systemer · prøven hører til i eget testmiljø.
- At overse genforsøg og samtidige opdateringer · det er der, litra i typisk bliver relevant.
Det skal auditten kunne vise
- ☐ En liste over væsentlige funktioner efter bilag II, nr. 4.
- ☐ Risikovurderingens stillingtagen til litra h og litra i.
- ☐ Resultater af prøver med udfald, overbelastning og misdannede data.
- ☐ Beskrevne modtræk mod, at produktet belaster andres tjenester.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, bilag I, del I, nr. 2, litra h og i, og bilag II, nr. 4, læst 13. november 2026.
- Europa-Kommissionen, C(2026) 5252, vejledning om anvendelsen af forordningen, punkt 169, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tag listen over væsentlige funktioner fra jeres brugeroplysninger, og skriv ud for hver, hvad der sker, når serveren ikke svarer.
Læs også: Når noget går galt inde i softwaren · Begrænsning af angrebsflader
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
