Krav om sikker udvikling i kontrakten: hvor test hører til

Et kontraktbilag, der kræver “sikker udvikling”, kan dække alt fra kodegennemgang til en årlig penetrationstest, og det er ikke altid skrevet, hvilken del kunden vil se dokumenteret. Svaret hviler på tre tekster: NIS2-direktivets krav om, at kunden ser på leverandørernes udviklingspraksis, lovbemærkningerne til den danske lov, og gennemførelsesforordning 2024/2690, som gør sikker udvikling og test til konkrete punkter for visse digitale udbydere.

Kort sagt hører testen til i udviklingsforløbet som ét kontrolpunkt blandt flere. En penetrationstest kan vise, om det færdige system holder på et givet tidspunkt. Den kan ikke vise, at jeres udviklingsproces er sikker. Kunden kan bede om begge dele, men det er to forskellige beviser.

Hvorfor kunden overhovedet spørger til jeres udvikling

Direktivets artikel 21, stk. 3, beder de omfattede enheder tage hensyn til den generelle kvalitet af leverandørernes produkter og cybersikkerhedspraksis, herunder procedurerne for sikker udvikling. Den ordlyd står ikke i selve paragraffen i den danske NIS 2-lov, men bemærkningerne til § 6, nr. 4, som SAMSIK gengiver i sin vejledning om foranstaltninger, siger det samme: enhederne bør vurdere leverandørernes sikre udviklingsprocedurer.

SAMSIK’s vejledning nævner også leverandørens cybersikkerhedspraksis, “herunder deres procedurer for sikker udvikling”, som et muligt kriterium, når kunden vælger leverandører. Det forklarer, hvorfor spørgsmålet kan dukke op allerede i et udbud eller en forhandling og ikke først ved den årlige opfølgning. → Artikel 21, stk. 3

Hvad forordningen siger om udvikling og test

Forordning 2024/2690 gælder direkte for bestemte digitale udbydere, blandt andet cloud, datacentre, MSP og MSSP. Er jeres kunde en af dem, eller er I det selv, er bilagets punkter bindende. For alle andre er de en kilde til de formuleringer, kunderne låner. Bilaget har to steder, der rammer emnet:

Punkt 5.1.2, litra a · kriterierne for at vælge og indgå aftale med leverandører skal omfatte leverandørens cybersikkerhedspraksis, herunder procedurer for sikker udvikling.
Punkt 6.2 · enheden skal fastlægge regler for sikker udvikling, før et system udvikles, og reglerne skal dække alle faser fra specifikation og design til implementering og test. Ifølge punkt 6.2.2, litra d, skal der være processer for sikkerhedstest i udviklingsforløbet.

Punkt 6.2.3 siger, at reglerne også gælder, når udviklingen er lagt ud til andre. Det er den sætning, der lander hos jer som leverandør, når I udvikler for en kunde, som forordningen gælder for. → Forordning 2024/2690

Test er én fase, ikke hele kravet

ENISA’s tekniske vejledning til forordningen, som ikke er bindende, beskriver test i udviklingen som noget, der sker i flere faser før idriftsættelse. Den nævner forskellige testmetoder og eksempler på dokumentation som testresultater fra hver fase, kodegennemgang og versionsstyring. En afsluttende penetrationstest dækker kun den sidste del af den kæde.

Det betyder, at kunden kan have ret i at spørge om mere end en testrapport. Har kunden skrevet “sikker udvikling” i kontrakten, kan kunden forvente at se, at sikkerhed er med fra kravspecifikationen. Rapporten fra en penetrationstest svarer på et andet spørgsmål: fandt en udefrakommende tester svagheder i den version, der blev afprøvet? → Test ved idriftsættelse

Et tænkt eksempel

Et softwarehus udvikler et planlægningssystem til en hospitalsafdeling og får et kontraktbilag om sikker udvikling. Bilaget beder om “dokumentation for sikker udvikling og test”. Softwarehuset har en penetrationstest fra sidste halvår, men ingen skrevne regler for, hvordan sikkerhed indgår i design og kodegennemgang.

Rapporten kan dokumentere den testede version. Den kan ikke stå i stedet for reglerne, og kunden vil sandsynligvis spørge, hvordan de nye funktioner siden er blevet kontrolleret. Et præcist svar skiller de to ad: her er reglerne for udvikling, her er testen af den version, kunden kører, og her er planen for næste test efter væsentlige ændringer. → Ny test efter væsentlige ændringer

Sådan svarer I på et udviklingskrav

Del svaret op efter, hvad kunden kan kontrollere. En opdeling, der kan passe:

Reglerne · den skrevne beskrivelse af, hvordan sikkerhed indgår i specifikation, design, kode og test.
Kontrollerne undervejs · kodegennemgang, test i udviklingsmiljøet og godkendelse før frigivelse, beskrevet på begrebsniveau.
Den uafhængige afprøvning · en penetrationstest af den version, kunden bruger, med en beskrevet testmetode. → Dokumenteret testmetode
Opfølgningen · hvordan fund bliver rettet, og hvornår der testes igen.

Hvis kunden kun spørger til test, så svar på det, men nævn de andre punkter kort. Det viser, at testen hører til et forløb og ikke står alene.

Kundekrav til selve softwareproduktet, fx sikkerhedsspørgeskemaer og test i takt med releases, er behandlet for softwarehuse på pentestrapport.dk.

Når I leverer et produkt ind i kundens net

Kravet kan også ramme leverandører, der ikke skriver kundespecifik kode, men leverer udstyr eller standardsoftware, som kunden installerer. Her handler spørgsmålet om produktets kvalitet og om, hvordan I håndterer sårbarheder, der bliver fundet efter levering. En test af produktet i en opsætning, der ligner kundens, kan give kunden et grundlag. Den erstatter ikke en beskrivelse af, hvordan I udvikler og opdaterer produktet. → Udstyr og software, I leverer

Aftal i så fald, hvilken produktversion og hvilken opsætning testen skal gælde for. Kunden kører måske en ældre version eller en tilpasset konfiguration, og et testresultat fra jeres egen standardopsætning siger mindre om den. Skriv forskellen ind i svaret, så kunden ikke læser rapporten som et udsagn om sin egen installation.

Det skal I lade være med

At sende en testrapport som svar på et procesbilag · rapporten dokumenterer en version, ikke jeres udviklingspraksis.
At love sikker udvikling i alle faser uden at have reglerne · kunden kan bede om at se dem.
At beskrive interne kontroller i teknisk detalje · kunden har brug for at vide, at de findes, og hvem der godkender.
At glemme udviklingen, I har lagt ud · kundens krav kan også gælde jeres egne underleverandører.
At antage, at forordningen gælder kunden · den gælder kun bestemte digitale udbydere; spørg, hvad kravet bygger på.

Hvad kan og ikke kan konkluderes

En penetrationstest kan vise, hvilke svagheder en tester fandt i en bestemt version, og at de er rettet. Den kan indgå som testfasen i jeres regler for sikker udvikling. Den kan ikke dokumentere, at kravspecifikation, design og kodegennemgang er sket på en sikker måde, og den siger intet om versioner, der er kommet til efter testen. Om jeres samlede praksis lever op til kundens bilag, afhænger af aftalen. Teksten er ikke juridisk rådgivning.

Tjekliste til et krav om sikker udvikling

☐ Har I spurgt, om kunden vil se regler, kontroller eller testresultater?
☐ Findes jeres regler for sikker udvikling på skrift?
☐ Er det klart, hvilken version testen dækker?
☐ Er udvikling hos jeres underleverandører med i svaret?
☐ Er næste test knyttet til væsentlige ændringer?
☐ Ved I, om forordning 2024/2690 gælder kunden?

Kilder

NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 3, om leverandørers produktkvalitet og sikre udviklingsprocedurer.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 med lovbemærkningerne til § 6, nr. 4, og afsnit 5.a om regler for sikker udvikling.
Gennemførelsesforordning (EU) 2024/2690: bilaget, punkt 5.1.2, litra a, og punkt 6.2.
ENISA, NIS2 Technical Implementation Guidance (juni 2025): ikke bindende vejledning til punkt 6.2 om test i udviklingsforløbet.

Senest gennemgået: oktober 2026.