Afgrænsning mod kundens eget miljø: hvad I må teste, og hvad kunden skal godkende

Når kunden kræver, at I tester jeres leverance, opstår et praktisk spørgsmål: hvor slutter jeres systemer, og hvor begynder kundens? Svaret afgør, hvem der skal give tilladelse. Det hviler på et enkelt princip: en test må kun ramme systemer, som den, der bestiller testen, ejer eller har fået skriftlig tilladelse til at lade teste. Kundens krav til jer er ikke i sig selv en tilladelse til at teste kundens miljø.

Straffelovens § 263, stk. 1, omfatter den, der uberettiget skaffer sig adgang til en andens datasystem. En aftalt test er ikke uberettiget, men det forudsætter, at den, der ejer systemet, har sagt ja. Teksten er ikke juridisk rådgivning, og tvivl om en konkret aftale bør afklares med en jurist.

Hvor grænsen kan gå

En leverance kan berøre kundens miljø et eller flere steder. Det kan være:

Integrationer · forbindelser, hvor jeres løsning henter eller sender data til kundens systemer. → Integrationer og dataudveksling
Supportadgang · den forbindelse, jeres medarbejdere bruger til at logge på hos kunden. → Jeres supportadgang til kunden
Software eller agenter · noget, I har installeret på kundens servere eller arbejdspladser.
Fælles login · når kundens medarbejdere logger ind i jeres løsning med kundens egne konti.
Konti, I har hos kunden · brugere i kundens systemer, som jeres medarbejdere arbejder med. → Delte konti og fælles adgange

Det, der ligger på jeres side af hver forbindelse, kan I som udgangspunkt selv give tilladelse til. Det, der ligger på kundens side, kræver kundens tilladelse, også når det er jeres software, der kører der.

Tre zoner i afgrænsningen

Det kan hjælpe at dele omfanget i tre zoner og skrive dem ind i opgavebeskrivelsen:

Jeres egne systemer · jeres løsning, jeres servere, jeres konti. Her giver I selv tilladelsen.
Grænsefladen · forbindelsen mellem jer og kunden. Her tester I som udgangspunkt fra jeres egen side, fx om forbindelsen kun giver den adgang, der er aftalt. Kunden skal være orienteret, og kunden kan skulle godkende, fordi trafikken ender hos kunden.
Kundens miljø · alt bag forbindelsen. Her tester I kun, hvis kunden har givet skriftlig tilladelse med en præcis afgrænsning.

Hvis jeres løsning kører hos en hostingpartner eller i en cloudplatform, er der en fjerde part med egne regler. → Leverancen hos en hostingpartner

Hvad kunden skal godkende

Når testen skal ind i zone to eller tre, bør kundens godkendelse dække mindst følgende:

Systemerne · hvilke adresser, konti og funktioner hos kunden der må indgå.
Tidspunktet · hvornår testen må køre, og hvornår den ikke må, fx under drift med særlige krav.
Kontaktpersoner · hvem hos kunden der kan stoppe testen, og hvem der skal have besked om kritiske fund.
Data · om testeren må se kundens data, og hvordan oplysninger behandles og slettes bagefter.
Den, der underskriver · en person hos kunden, der har ret til at give tilladelsen til de pågældende systemer.

Det sidste punkt er let at overse. En indkøber eller kontaktperson for leverandøraftalen er ikke nødvendigvis den, der kan give lov til, at kundens net bliver testet.

Hvorfor kunden kan have en procedure for det

Nogle kunder har en fast procedure for, hvornår leverandører må forbinde sig til deres systemer. For de digitale udbydere, som gennemførelsesforordning (EU) 2024/2690 gælder for, står det i bilagets punkt 6.7.2, litra h: forbindelser mellem tjenesteudbydere og enhedens systemer tillades kun efter en anmodning om autorisering og i en bestemt periode. Andre NIS2-kunder kan bruge samme tanke. En test, der går gennem jeres forbindelse til kunden, skal derfor også passe ind i kundens procedure. SAMSIK’s vejledning om foranstaltninger stiller i et eksempel om forsyningskæden spørgsmålet, om leverandørers adgang er passende segmenteret og kontrolleret, og nævner tidsbegrænset adgang for eksterne parter. En kunde, der arbejder sådan, kan kræve, at testens adgang åbnes til et bestemt tidsrum og lukkes igen bagefter.

Når kunden selv vil have sin side med

Kunden kan ønske, at testen også dækker kundens side af integrationen, fordi det er den samlede forbindelse, kunden er afhængig af. Det er rimeligt, men så er testen ikke længere kun jeres. Aftal, hvem der bestiller, hvem der betaler, og hvem der modtager rapporten for kundens del. Det kan være enklest, at kunden bestiller sin del selv, og at I bidrager med oplysninger og kontaktpersoner. Så har hver part sin egen tilladelse og sin egen rapport, og ingen af jer kommer til at stå med ansvaret for systemer, I ikke har indflydelse på. → Kunden vil selv teste

Et tænkt eksempel

En leverandør af et system til ruteplanlægning har en integration til en kommunes lønsystem og en fast supportforbindelse ind til kommunens servere. Kommunen kræver en årlig test af leverancen. Leverandøren beskriver tre zoner: ruteplanlægningssystemet og leverandørens egne konti i zone et, integrationen og supportforbindelsen i zone to, kommunens servere og lønsystem i zone tre.

Kommunen godkender zone to med et bestemt tidsrum og en kontaktperson i sin IT-afdeling, men ikke zone tre. Testen undersøger derfor, om supportforbindelsen og integrationen kun giver den adgang, der er aftalt, set fra leverandørens side. Lønsystemet bliver ikke berørt, og det står i rapporten. Kommunen kan senere bestille en test af sin egen side, hvis den ønsker det, og bruge leverandørens beskrivelse af forbindelserne som grundlag.

Det skal I lade være med

At læse kundens testkrav som en tilladelse · kravet siger, at I skal teste, ikke at I må teste kundens systemer.
At lade testen følge forbindelsen ind hos kunden uden aftale · grænsefladen er ikke en åben dør.
At få tilladelsen fra den forkerte person · kontrollér, at underskriveren kan give lov til de systemer, det drejer sig om.
At glemme kundens andre leverandører · systemer hos kunden kan være drevet af en tredjepart med egne regler.
At ændre omfanget undervejs uden ny godkendelse · et nyt system hos kunden kræver et nyt ja.

Hvad kan og ikke kan konkluderes

En test afgrænset til jeres side kan dokumentere, hvordan jeres systemer og jeres ende af forbindelsen modstod testen. Den siger ikke noget om kundens systemer bag forbindelsen. En skriftlig tilladelse sikrer ikke, at testen er uden risiko for kundens drift, men den gør det klart, hvem der har accepteret hvad.

En generel indføring i tilladelser og afgrænsning ved penetrationstest findes på penetrationtest.dk (https://penetrationtest.dk/).

Tjekliste før testen berører kunden

☐ Har I beskrevet de tre zoner i opgavebeskrivelsen?
☐ Har kunden skriftligt godkendt systemer, tidspunkt og kontaktpersoner?
☐ Har underskriveren ret til at give tilladelsen?
☐ Er det afklaret, om kundens systemer drives af en anden leverandør?
☐ Er der aftalt et stop, hvis testen påvirker kundens drift?
☐ Ved testeren, hvad der ikke må berøres?

Kilder

Straffeloven, lovbekendtgørelse nr. 1294 af 2025: § 263, stk. 1, om uberettiget adgang til en andens datasystem.
Gennemførelsesforordning (EU) 2024/2690: artikel 1 (hvem den gælder for) og bilagets punkt 6.7.2, litra h.
SAMSIK, vejledning om foranstaltninger (juni 2025): eksemplet om forsyningskædesikkerhed under afsnit 4 (segmenteret og tidsbegrænset adgang for eksterne parter).

Senest gennemgået: oktober 2026.