Et krav er ikke bare et krav – hvor kommer det fra?

“I skal kunne dokumentere jeres informationssikkerhed.”

Sådan kan et krav lande midt i en kundedialog. Nogle gange står det i et spørgeskema eller en kontrakt. Andre gange kommer det fra en konsulent eller en platformsælger, der henviser til NIS2, DORA eller en standard.

Formuleringen kan lyde præcis, selv om sammenhængen stadig mangler. Forkortelsen fortæller måske, hvor afsenderen har hentet sin inspiration, men ikke nødvendigvis hvorfor kravet er relevant for jeres leverance, eller hvad kunden skal bruge svaret til.

I artikel 2 så vi på, hvordan kundernes egne forpligtelser kan bevæge sig gennem salget og videre til leverandørerne. Næste skridt er at skelne mellem de kilder, som et konkret krav kan bygge på.

Fire kilder, der kan hænge sammen

Lovgivning kan være den oprindelige kilde. Det betyder ikke automatisk, at den samme lov gælder direkte for jer. En kunde kan være omfattet af regler, som kræver, at den styrer sine leverandører, og derfor stille krav til jeres leverance.

En kontrakt kan være kilden til det krav, I møder. Kravet kan stå i hovedkontrakten, et bilag eller leverandørbetingelserne. Det centrale er at finde den konkrete formulering og forstå, hvad virksomheden har forpligtet sig til.

En kundepolitik beskriver kundens egen måde at styre sikkerhed, indkøb eller leverandører på. Den kan være strengere eller mere detaljeret end det bagvedliggende lovkrav. Hvis politikken indgår i kontrakten, får den betydning som kontraktvilkår.

En faglig anbefaling kan komme fra en standard, branchevejledning eller kendt praksis. Den kan være nyttig uden at være lov. Dens betydning afhænger af, om den er gjort til en del af kundens politik, kontrakten eller den konkrete vurdering af leverancen.

De fire kilder er derfor ikke adskilte kasser. Et lovkrav til en finansiel virksomhed kan blive omsat til en intern leverandørpolitik og derefter til vilkår i kontrakten med jer. DORA indeholder eksempelvis krav til bestemte kontraktvilkår mellem finansielle virksomheder og deres it-leverandører. Det gør kontrakten vigtig for leverandøren, selv om det fortsat skal vurderes særskilt, hvem der er direkte omfattet af reglerne.

De faglige referencer er ikke det samme

Lovgivning er allerede behandlet som en særskilt kilde ovenfor. Her ser vi på fire faglige referencer, som ofte bliver nævnt i samme samtale. Kun ISO/IEC 27001 er en standard. SOC 2, CIS Controls og OWASP Top 10 har andre formål.

ISO/IEC 27001 er en standard for et ledelsessystem for informationssikkerhed. En virksomhed kan bruge standarden uden at være certificeret, og en certificering er et særskilt valg.

SOC 2 er en revisorerklæring om kontroller hos en serviceorganisation.

CIS Controls er en prioriteret samling af sikkerhedsforanstaltninger.

OWASP Top 10 er et oplysningsdokument om væsentlige risici i webapplikationer.

En standard, en erklæring eller en vejledning kan indgå i en anbefaling, kundepolitik eller kontrakt. Derfor er det mere nyttigt at forstå, hvilken rolle henvisningen spiller i den konkrete dialog, end blot at genkende forkortelsen.

Se på, hvad kunden forsøger at forstå

Begynd med selve spørgsmålene. Spørger kunden til, hvordan I beskytter og behandler deres data? Til hvordan jeres infrastruktur er bygget, og hvilke leverandører den afhænger af? Til hvordan ansvar og roller er placeret i organisationen? Eller handler spørgsmålene om produktet, den konkrete leverance eller hele virksomheden?

Spørgsmålenes tyngdepunkt kan fortælle noget om kundens hensigt. Mange spørgsmål om data kan pege mod fortrolighed og databeskyttelse. Spørgsmål om infrastruktur og underleverandører kan handle om driftsstabilitet og afhængigheder. Spørgsmål om ansvar kan vise, at kunden vil vide, hvem der reagerer, hvis noget går galt.

Fastlæg også, hvem kunden er. En finansiel virksomhed, en energivirksomhed, en offentlig organisation eller et børsnoteret selskab kan have forskellige egne forpligtelser og forskellige forventninger til leverandører. Kundens branche og status beviser ikke i sig selv, at I er omfattet af den samme lovgivning, men de kan forklare, hvorfor et krav bevæger sig gennem kunden og videre til jer.

Vælg ét krav fra en mail, kontrakt eller et spørgeskema, og brug ti minutter på fire spørgsmål:

1. Hvilke emner spørger kunden mest ind til?
2. Handler spørgsmålene om produktet, leverancen eller hele virksomheden?
3. Hvad ved I om kundens branche, rolle og egne forpligtelser?
4. Hvilken risiko eller beslutning ser spørgsmålene ud til at være knyttet til?

Sammenfat jeres foreløbige forståelse i én sætning:

Det er ikke et endeligt svar, men et bedre udgangspunkt for dialogen. Når I har en begrundet idé om kundens hensigt, bliver det lettere at finde den relevante dokumentation, genbruge det I allerede gør, og se hvor der faktisk mangler noget.

Et krav bliver vurderbart, når kilden, kundens sammenhæng og hensigten med spørgsmålet kan ses.

Næste artikel går videre med netop hensigten: Hvad skal kunden kunne beskytte eller beslutte, når I har besvaret kravet?

Kilder og forbehold

• DORA, forordning (EU) 2022/2554, særligt artikel 30 om kontraktbestemmelser.
• ISO om ISO/IEC 27001:2022.
• AICPA om SOC-ydelser.
• Center for Internet Security om CIS Controls.
• OWASP Top 10.

Kilder og beskrivelser er kontrolleret 13. september 2026. Artiklen giver generel information og er ikke juridisk rådgivning. Om et konkret regelsæt gælder for en virksomhed, et produkt eller en leverance, kræver en individuel vurdering.