Artikel 21, stk. 3: hvorfor kunden spørger til jeres udvikling og produktkvalitet

Nogle kunder nøjes ikke med at spørge, om jeres leverance er testet. De vil vide, hvordan jeres produkter bliver til, hvor gode de er, og hvilke svagheder der er særlige for jer. Den type spørgsmål har en bestemt kilde: NIS2-direktivets artikel 21, stk. 3, og de danske lovbemærkninger til § 6, nr. 4, som udtrykker samme tanke.

Kort sagt skal kunden, når den vurderer sin forsyningskæde, tage hensyn til tre forhold hos hver direkte leverandør: de sårbarheder, der er særlige for netop den leverandør, den generelle kvalitet af produkterne, og leverandørens cybersikkerhedspraksis, herunder procedurerne for sikker udvikling. En penetrationstest kan belyse det første og en del af det andet. Det tredje kræver andre beviser.

Hvad bestemmelsen siger

Artikel 21, stk. 2, litra d, kræver, at kunden har foranstaltninger for forsyningskædesikkerhed. Stk. 3 siger, hvad kunden skal tage hensyn til, når den vælger de foranstaltninger. Ordlyden handler om sårbarheder, der er specifikke for hver direkte leverandør og tjenesteudbyder, og om den generelle kvalitet af deres produkter og cybersikkerhedspraksis, herunder procedurer for sikker udvikling.

Den danske NIS 2-lov har ikke en paragraf med samme ordlyd. Men bemærkningerne til § 6, nr. 4, som SAMSIK citerer i sin vejledning om foranstaltninger, siger, at enhederne bør vurdere og tage hensyn til den generelle kvalitet og modstandsdygtighed af produkter og tjenester, de indbyggede sikkerhedsforanstaltninger og leverandørernes praksis, herunder deres sikre udviklingsprocedurer. For en dansk kunde er det den formulering, der ligger nærmest. → Forsyningskædesikkerhed

Tre forhold, tre slags beviser

Det hjælper at skille de tre forhold ad, fordi de besvares forskelligt.

Sårbarheder, der er særlige for jer · det, der kan findes i netop jeres leverance: jeres opsætning, jeres adgang til kunden, jeres kode. Her er en penetrationstest et direkte svar, fordi den leder efter svagheder i det konkrete.
Produkternes generelle kvalitet · hvor robust produktet er, og hvordan det holdes opdateret i hele levetiden. En test kan vise en del, men kunden vil også se, hvordan I håndterer opdateringer og fejl, der bliver meldt efter levering. → Opdateringskanalen
Praksis og sikker udvikling · hvordan I arbejder: regler for udvikling, kodegennemgang, ændringsstyring. Her er en testrapport et indirekte bevis. Den viser resultatet af praksis på ét tidspunkt, ikke praksis selv. → Krav om sikker udvikling

Hvorfor kunden spørger bredere end til testen

En kunde, der kun får en testrapport, ved, hvordan leverancen så ud, da den blev testet. Stk. 3 peger på, at kunden også skal forholde sig til, hvordan leverancen vil se ud fremover. Det er derfor, spørgeskemaer kan rumme spørgsmål om udviklingsmiljø, adskillelse af test og drift, og hvordan I får besked om sårbarheder i komponenter, I bygger på.

SAMSIK’s vejledning nævner også, at kunden kan sikre, at sikkerhedsopdateringer er tilgængelige fra producenten i hele produktets forventede levetid. For en leverandør af udstyr eller standardsoftware er det et spørgsmål om support og opdateringspolitik, ikke om test. → Udstyr og software, I leverer

Når kunden spørger til komponenter fra andre

Leverancer kan bygge på biblioteker, platforme eller udstyr fra andre producenter. Stk. 3 taler om leverandørens produkter, og kunden kan derfor spørge, hvordan I holder styr på det, jeres produkt indeholder. En penetrationstest kan finde en kendt svaghed i en komponent, men den giver ikke et overblik over alle komponenter.

Det kunden har brug for, er en forklaring på, hvordan I opdager og håndterer sårbarheder i det, I har købt eller hentet, og hvordan kunden får besked. → Fund i tredjepartskomponenter

Sådan bygger I et svar, kunden kan bruge

Når spørgsmålet tydeligt bygger på stk. 3 eller på lovbemærkningerne, kan et svar i fire dele dække det meste:

Hvad der er testet · hvilken version og opsætning, hvornår, og hvad der blev fundet og rettet.
Hvordan produktet holdes ved lige · opdateringspolitik, supportperiode og leveringsvejen for rettelser.
Hvordan I udvikler · en kort beskrivelse af reglerne for sikker udvikling og af, hvem der godkender en frigivelse.
Hvordan sårbarheder når kunden · hvordan I modtager meldinger, vurderer dem og giver kunden besked.

Skriv svaret, så det kan genbruges over for andre kunder med samme spørgsmål, og hold fortrolige detaljer om jeres systemer ude af det. Hvis kunden ønsker mere, kan resten vises på et møde eller under en fortrolighedsaftale.

Et tænkt eksempel

En producent af styreenheder til vandbehandling får et spørgeskema fra et forsyningsselskab. Skemaet beder om “dokumentation for produktets sikkerhedsniveau og producentens udviklingspraksis”. Producenten har en penetrationstest af den seneste firmwareversion i en laboratorieopsætning.

Testen svarer på spørgsmålet om sårbarheder i den version. Til spørgsmålet om produktkvalitet over tid kan producenten beskrive, hvor længe enheden får sikkerhedsopdateringer, og hvordan de leveres. Til spørgsmålet om udviklingspraksis kan producenten beskrive sine regler for sikker udvikling og ændringsstyring. Tre korte svar, der hver hviler på det rigtige bevis, er stærkere end en rapport, der bliver sendt som svar på det hele. Forsyningsselskabet kan så selv vurdere, om de tre svar tilsammen er nok, eller om det vil bede om mere på et bestemt punkt.

Det skal I lade være med

At svare på et spørgsmål om praksis med en testrapport alene · rapporten viser et resultat, ikke en proces.
At love opdateringer i hele levetiden uden at have en plan · kunden kan bede om at se den.
At beskrive udviklingsmiljøet i teknisk detalje · kunden har brug for at vide, at det er adskilt og styret.
At glemme komponenter fra andre · de er en del af jeres produkts kvalitet set fra kunden.
At tro, at bestemmelsen gælder jer direkte · den beskriver, hvad kunden skal tage hensyn til.

Hvad kan og ikke kan konkluderes

Artikel 21, stk. 3, forklarer, hvorfor en kunde kan spørge ind til jeres produkter og jeres måde at udvikle på, og ikke kun til et testresultat. Den fastsætter ikke, hvilke beviser kunden skal kræve, og den gælder ikke jer direkte. En penetrationstest kan dokumentere sårbarheder, der blev fundet i en bestemt version på et bestemt tidspunkt. Den kan ikke dokumentere, at jeres udviklingspraksis er sikker, eller at kommende versioner bliver det. Teksten er ikke juridisk rådgivning, og direktivets ordlyd bør læses i den officielle udgave.

Kundekrav til selve softwareproduktet, set fra et softwarehus, er behandlet på pentestrapport.dk.

Tjekliste til spørgsmål om produkt og udvikling

☐ Har I skilt spørgsmålene om sårbarheder, produktkvalitet og praksis ad?
☐ Er testen af den version, kunden bruger, eller en anden?
☐ Kan I beskrive, hvor længe produktet får sikkerhedsopdateringer?
☐ Har I en beskrivelse af regler for sikker udvikling, der kan deles?
☐ Ved I, hvordan sårbarheder i komponenter fra andre bliver opdaget?
☐ Er det aftalt, hvordan kunden får besked om nye sårbarheder?

Kilder

NIS2-direktivet (EU) 2022/2555: artikel 21, stk. 2, litra d, og stk. 3.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 med lovbemærkningerne til § 6, nr. 4, og afsnit 5.a om sikkerhedsopdateringer i produktets levetid.
NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 4 og 5.

Senest gennemgået: oktober 2026.