Kunden henviser bredt til en standard: hvad betyder kravet?

En sætning som “leverandøren skal følge anerkendte sikkerhedsstandarder” ser uskyldig ud i et kontraktudkast, men den siger intet om, hvad I konkret skal gøre. Svaret hviler på at oversætte henvisningen til et præcist krav, som kunden selv bekræfter: hvilken standard, hvilken del af den, og hvad den betyder for test af jeres produkt. Indtil det er afklaret, kan I hverken love at opfylde kravet eller vide, om I allerede gør det.

Hvorfor henvisningen bliver så bred

En bred formulering kan have flere forklaringer. Kundens jurist har brugt en skabelon, som skal passe til alle leverandører. Indkøb har kopieret et afsnit fra en tidligere aftale. Eller kundens sikkerhedsfunktion vil holde døren åben for at stille krav senere.

Ingen af forklaringerne giver jer et svar. De betyder blot, at kunden ikke har taget stilling til, hvad kravet skal dække hos netop jer. Det er den stillingtagen, I skal have frem, før kontrakten underskrives. Står kravet i en samlet politik for leverandører, er læsningen af den beskrevet særskilt. → Kravet står i kundens leverandørpolitik

Tre slags henvisninger

Henvisninger til standarder kan deles i tre grupper, og hver kræver sit eget opfølgende spørgsmål.

Ingen standard nævnt · “branchens bedste praksis” eller “anerkendte standarder”. Spørg, hvilken standard kunden selv arbejder efter, og om kunden forventer, at I følger den samme.
En standard nævnt uden afgrænsning · fx ISO 27001 eller PCI DSS. Spørg, om kunden kræver en certificering, en erklæring, eller blot at bestemte krav i standarden er opfyldt for produktet.
Et bestemt krav nævnt · fx et punkt om penetrationstest. Her er udgangspunktet klart, men tjek, om udgaven af standarden er angivet, og om kravet gælder hele produktet.

Den tredje gruppe er den letteste at arbejde med. Målet med de opfølgende spørgsmål er at flytte de to første grupper derhen.

Vær også opmærksom på, hvor i kontrakten henvisningen står. En sætning i hovedaftalen kan gælde hele samarbejdet, mens en sætning i en kravspecifikation eller en serviceaftale kan være begrænset til en bestemt ydelse. Placeringen kan derfor sige noget om, hvad kunden har ment, og den er et godt sted at starte, når I formulerer jeres spørgsmål. Har kunden flere dokumenter, som henviser til forskellige standarder, så saml dem i én oversigt. Det gør det lettere at se, om henvisningerne peger i samme retning, eller om de i virkeligheden stiller to forskellige krav til den samme test.

Hvad standarderne faktisk siger om test

Standarderne er skrevet til forskellige formål, og de taler forskelligt om test. Nogle beskriver et ledelsessystem, hvor virksomheden selv vælger sine kontroller ud fra en risikovurdering. Andre stiller præcise krav. PCI DSS krav 11.4 er et eksempel på det sidste: standarden kræver penetrationstest mindst hver tolvte måned og efter væsentlige ændringer, i de miljøer standarden gælder for. → Når produktet håndterer kortdata

OWASP ASVS er et tredje eksempel. Projektet beskriver sig selv som en ramme for sikkerhedskrav til webapplikationer og webtjenester, og et af dets formål er at give et grundlag for at angive krav i kontrakter. Henviser kunden til ASVS, er næste spørgsmål, hvilke kapitler og hvilket niveau kunden forventer. → OWASP ASVS

Pointen er, at “følg standarden” kan betyde alt fra en årlig test af et afgrænset miljø til en certificering af hele virksomheden. Det er kunden, der skal sige, hvilken læsning der gælder.

Spørgsmål, der fører til det konkrete krav

Send kunden en kort liste med spørgsmål, før I forhandler videre. Hold den skriftlig, så svaret kan lægges ved kontrakten.

Hvilken standard og udgave · mener kunden en bestemt standard, og hvilken version?
Hvilket bevis · skal I fremvise et certifikat, en erklæring, en testrapport eller en egenerklæring?
Hvilket omfang · gælder kravet produktet, platformen under det eller hele virksomheden?
Hvilken hyppighed · en gang ved kontraktens start, årligt eller ved ændringer?
Hvem vurderer · kundens sikkerhedsfunktion, indkøb eller kundens revisor?

Svarene giver jer et krav, I kan holde op mod det, I allerede gør. Det kan vise sig, at kunden først og fremmest ønsker dokumentation for en uafhængig test af produktet og for opfølgning på fundene. → Forhandling af sikkerhedskrav

Foreslå selv en præcis formulering

Kommer der ikke noget brugbart svar, kan I foreslå teksten selv. En formulering, der binder jer til noget målbart, er lettere at leve op til og lettere for kunden at følge op på. Den kan for eksempel angive, at produktet testes af en uafhængig tester mindst én gang om året og efter større ændringer, at kunden får et resumé af resultatet, og at alvorlige fund følges op efter en beskrevet proces.

Sørg for, at forslaget svarer til det, I faktisk har planlagt. En præcis formulering, I ikke kan holde, er ikke bedre end en bred. Placér den gerne i et sikkerhedsbilag, så den kan opdateres uden at hele kontrakten skal genforhandles. → Sikkerhedsbilaget til kundekontrakten

Et tænkt eksempel

Et softwarehus med et system til vagtplanlægning modtager et kontraktudkast fra en større kunde. Udkastet siger, at leverandøren skal efterleve “relevante internationale sikkerhedsstandarder”. Softwarehuset sender fem spørgsmål tilbage og får at vide, at kundens sikkerhedsfunktion arbejder efter ISO 27001, men ikke kræver en certificering af leverandøren. Kunden ønsker en årlig penetrationstest af produktet og et resumé af resultatet.

Softwarehuset foreslår en formulering i sikkerhedsbilaget, der siger netop det. Kunden accepterer, og den brede sætning i hovedaftalen får en henvisning til bilaget. Ved næste fornyelse er der ikke tvivl om, hvad der var aftalt.

Det skal I lade være med

Skrive under på en bred henvisning · I påtager jer et krav, ingen kan beskrive.
Antage, at standarden kræver certificering · spørg, hvilket bevis kunden vil have.
Gætte på udgaven · standarder ændrer sig, og kravene med dem.
Svare, at I allerede følger standarden · uden at kunne vise, hvad det betyder for produktet.
Lade svaret blive i en mailtråd · læg kundens afklaring ved kontrakten.

Hvad kan og ikke kan konkluderes

En afklaring af henvisningen kan give jer et konkret krav om test og dokumentation, som både I og kunden forstår ens. Den afgør ikke, om I opfylder standarden som helhed, og den gør ikke en testrapport til et bevis for overensstemmelse med en standard. Hvordan en kontraktformulering skal forstås juridisk, bør vurderes af den, der normalt varetager jeres aftaler. Teksten er ikke juridisk rådgivning.

Tjekliste til en bred henvisning

☐ Ved I, hvilken standard og udgave kunden mener?
☐ Ved I, hvilket bevis kunden forventer?
☐ Er omfanget afgrænset til produkt, platform eller virksomhed?
☐ Er hyppigheden aftalt?
☐ Er kundens svar gemt sammen med kontrakten?
☐ Svarer den foreslåede formulering til det, I har planlagt?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.2 og 11.4.3 om penetrationstest mindst hver tolvte måned og efter væsentlige ændringer.
OWASP ASVS: ramme for sikkerhedskrav til webapplikationer og webtjenester, blandt andet som grundlag for krav i kontrakter.

Senest gennemgået: oktober 2026.