Sikkerhedstesten

Kunden vil selv teste jeres systemer: skal ledelsen sige ja?

Kunden vil selv teste jeres systemer: skal ledelsen sige ja?

En kunde, der vil lade sine egne testere angribe jeres systemer, beder om noget andet end en rapport. Kunden beder om adgang. Svaret på, om ledelsen skal sige ja, hviler på, at en sådan test kun er i orden, når den, der har ret til systemerne, har givet tilladelse, og at tilladelsen har klare rammer. Det er en ledelsesbeslutning, fordi den berører drift, fortrolighed, andre kunders data og jeres aftaler med leverandører. Teksten er ikke juridisk rådgivning.

Hvorfor tilladelsen er afgørende

I straffeloven er det § 263, stk. 1, der rammer den, som uden ret skaffer sig adgang til en andens datasystem eller data. En sikkerhedstest er ikke uberettiget, når den sker med tilladelse fra den, der har retten til systemet. Derfor er det ikke kundens ønske, der gør testen i orden, men jeres skriftlige tilladelse med en klar afgrænsning.

Det betyder også, at I ikke kan give tilladelse til mere, end I selv råder over. Hvis systemerne ligger hos en driftsleverandør eller i en cloudtjeneste, har leverandøren sine egne regler. Microsoft tillader for eksempel test i kundens egen lejer, men forbyder adgang til andre kunders data og test af tilgængelighed. Ledelsen skal derfor vide, hvem der ejer hvad, før den svarer. → Hvem har adgang til hvad?

Fire spørgsmål til ledelsen

Før der siges ja, bør ledelsen have svar på fire spørgsmål:

  1. Hvorfor vil kunden teste? Er det et krav i kontrakten, et led i kundens egen leverandørvurdering eller en reaktion på noget bestemt?
  2. Hvad skal testes? Kun den løsning, kunden bruger, eller mere? Hvor går grænsen til systemer, der deles med andre kunder?
  3. Hvem udfører testen? Kundens egne folk eller en ekstern tester, og hvad ved I om dem?
  4. Hvad sker der med resultatet? Hvem får rapporten, og får I den selv?

Svarene afgør, om ja er det rigtige, og hvilke betingelser der skal følge med. → Testens egne risici

Det, en aftale bør dække

Et ja bør altid være skriftligt og bør dække det samme, som ledelsen forventer af en test, virksomheden selv bestiller. Detaljerne kan IT og en jurist hjælpe med, men ledelsen bør kende hovedpunkterne:

  • Afgrænsning · hvilke systemer og adresser der må testes, og hvilke der ikke må.
  • Tidspunkt · hvornår testen må finde sted, og hvem der kan stoppe den.
  • Andre kunders data · at testen ikke må berøre dem.
  • Leverandørernes accept · at driftsleverandøren eller cloududbyderen er orienteret eller har givet lov, hvor det kræves.
  • Fortrolighed · hvordan kunden og testeren behandler det, de ser.
  • Resultatet · at I får fundene, og hvor hurtigt.
  • Ansvar · hvem der bærer følgerne, hvis testen forstyrrer driften.

Spørgsmålene om ansvar og fortrolighed er juridiske, og ledelsen bør lade en advokat se på aftalen, hvis der er tvivl.

Når kundens tester finder noget

En test kan finde svagheder, og så ved kunden noget om jeres systemer, før I har nået at rette det. Ledelsen bør derfor på forhånd aftale, hvordan alvorlige fund meldes, så I hører om dem med det samme og ikke først, når rapporten er skrevet. Aftal også, hvem hos jer der modtager fundene, og hvem der beslutter, hvad der skal rettes først.

Overvej, hvad kunden må gøre med viden om fundene. En svaghed, der er rettet, er en anden sag end en, der står åben. Kunden kan have en legitim interesse i at følge rettelserne, og I kan have en lige så legitim interesse i, at oplysningerne ikke bliver delt videre i kundens organisation. → Hvis testresultatet slipper ud

Når svaret bør være nej eller måske

Ledelsen kan have gode grunde til at sige nej eller foreslå noget andet. Hvis løsningen deles med andre kunder, kan en test fra én kunde berøre de andre. Hvis kunden ikke vil dele resultatet, får I risikoen uden udbyttet. Og hvis I selv har fået testet løsningen for nylig, kan en erklæring om den test måske dække kundens behov.

Et alternativ kan være, at kunden får indflydelse på jeres næste test, for eksempel ved at foreslå områder, der skal med, eller ved at få en kort erklæring bagefter. Det giver kunden et svar uden at åbne systemerne for en tester, I ikke selv har valgt. → Leverandøren vil selv teste

Et nej kan opleves som et tegn på, at der er noget at skjule. Det er ledelsens opgave at forklare, hvorfor svaret er, som det er, og hvad kunden kan få i stedet. Et ja kan omvendt styrke relationen, hvis testen gennemføres ordentligt og fundene bliver rettet.

For softwarehuse og SaaS-leverandører, hvor kundetest er en fast del af salget, er emnet beskrevet i dybden på pentestrapport.dk. Her handler det om ledelsens beslutning i den konkrete sag. → Kunderne spørger til vores sikkerhed

Et tænkt eksempel

En logistikvirksomhed driver en kundeportal, hvor flere store kunder følger deres forsendelser. En af kunderne vil lade sin egen sikkerhedsafdeling teste portalen.

Direktøren spørger IT, hvem der driver portalen, og får at vide, at den ligger hos en hostingleverandør og deles af alle kunder. Ledelsen beslutter at sige ja til en test af kundens egen adgang, men ikke af den fælles platform. Aftalen fastlægger, hvad der må testes, hvornår, at andre kunders data ikke må berøres, og at virksomheden får alle fund. Hostingleverandøren bliver orienteret og bekræfter skriftligt. Samtidig får kunden tilbudt at foreslå områder til virksomhedens næste test af hele portalen.

Det skal I lade være med

  • At sige ja mundtligt · tilladelsen skal være skriftlig og afgrænset.
  • At give lov til mere, end I selv råder over · leverandører og cloududbydere har egne regler.
  • At glemme de andre kunder · deres data må ikke blive berørt.
  • At acceptere, at I ikke får resultatet · fundene handler om jeres systemer.
  • At lade IT afgøre det alene · det er en beslutning om risiko og kunderelation.

Hvad kan og ikke kan konkluderes

En skriftlig og afgrænset tilladelse giver ledelsen styr på, hvad kunden må, og hvad virksomheden får ud af det. Det kan ikke konkluderes generelt, om svaret skal være ja eller nej, eller hvordan ansvaret skal fordeles i aftalen. Det afhænger af systemerne, af kunden og af jeres leverandøraftaler.

Tjekliste, når kunden vil teste

  • ☐ Er det klart, hvorfor kunden vil teste, og hvad der skal testes?
  • ☐ Ved ledelsen, hvem der ejer og driver systemerne?
  • ☐ Er driftsleverandør eller cloududbyder spurgt, hvor det kræves?
  • ☐ Er tilladelsen skriftlig med afgrænsning, tidspunkt og stopmulighed?
  • ☐ Er det aftalt, at virksomheden får resultatet?
  • ☐ Har en advokat set på ansvar og fortrolighed, hvis der er tvivl?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til ledelsen

Læs også: Ledelsens godkendelse af testen · Kontrakten med IT-leverandøren

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer ledelsen en sikkerhedstest?

Skriv kort, hvad ledelsen gerne vil have svar på, og hvornår svaret skal bruges. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.