Er en penetrationstest lovlig: hvem kan give tilladelsen?

En bestilling fra en medarbejder gør ikke i sig selv en penetrationstest lovlig på alle de systemer, der bliver nævnt. Vurderingen skal bygge på, hvem der råder over hvert system, hvilke handlinger aftalen omfatter, og hvilke tredjeparters regler der gælder.

En penetrationstest indebærer bevidste handlinger mod it-systemer. Derfor skal tilladelsen være afklaret, før arbejdet begynder. Straffelovens § 263 omfatter uberettiget adgang til en andens datasystem eller data, og bestemmelsen gør sondringen mellem berettiget og uberettiget central. Artiklen giver generel købervejledning og er ikke juridisk rådgivning.

Hvis ejerskab, kontrakter eller fuldmagter er uklare, bør en advokat vurdere den konkrete situation. Testeren kan hjælpe med at beskrive den tekniske opgave, men bør ikke afgøre, hvem der juridisk kan godkende den på virksomhedens vegne.

Tilladelsen skal dække den konkrete opgave

En tilladelse bør kunne forbindes med de systemer, miljøer og handlinger, der er aftalt. En generel accept af at teste sikkerheden kan være for upræcis, hvis kundeportalen bruger eksterne tjenester eller deler infrastruktur med andre. Den godkendende part skal kunne se, hvad der omfattes, og hvad der er undtaget.

Tilladelsen bør også kunne knyttes til den udførende part og den aktuelle opgave. Et tidligere brev til en anden leverandør eller en anden udgave af webshoppen er ikke nødvendigvis dækkende. Notér versionsdato og henvisning, så grundlaget kan findes igen uden at fortolke løse mails.

Det er nyttigt at skelne mellem virksomhedens forretningsmæssige ønske og retten til at give adgang. En projektejer kan have budget og ansvar for webshoppen, mens driftsleverandøren kontrollerer dele af infrastrukturen. Begge forhold kan have betydning for aftalen.

Den konkrete dokumentation af kontaktpersoner, tidsrum og stop behandles i en anden vejledning. → Før penetrationstesten. Her er spørgsmålet først, om de relevante parter overhovedet kan og vil tillade den beskrevne opgave.

Find den part der råder over hvert system

Lav en ejeroversigt over de elementer, som scope omfatter. Den kan vise juridisk ejer, systemejer, driftsansvarlig og ekstern leverandør. Titlerne er ikke i sig selv afgørende; virksomhedens aftaler og fuldmagter viser, hvem der kan træffe beslutningen.

For et internt kontornet kan virksomheden råde over både udstyr og drift. For en kundeportal kan domæne, applikation, hosting og eksterne integrationer ligge hos forskellige parter. En tilladelse til applikationen bør ikke uden kontrol læses som tilladelse til hele kæden.

Markér uafklarede dele som undtagelser, indtil retten til at teste dem er dokumenteret. Det er bedre at indsnævre opgaven end at lade en antagelse udvide den. Den faglige afgrænsning beskrives i → Scope i en penetrationstest.

Hosting ændrer ikke behovet for rådighed

Når en ekstern leverandør hoster webshoppen, kan virksomheden eje indhold og applikation uden at råde frit over den underliggende platform. Kontrakten kan fordele ansvar og sætte betingelser for sikkerhedstest. Disse vilkår skal læses i deres aktuelle form.

Spørg hostingparten, hvilken godkendelse der kræves, og hvem der kan give den. Hvis leverandøren selv skal deltage, bør rollen fremgå. Det samme gælder andre kunders delte ressourcer, som ikke må blive omfattet ved en upræcis formulering.

Et brev fra virksomheden kan dokumentere dens egen accept, men ikke automatisk hostingpartens. Omvendt er en tilladelse fra hostingen ikke nødvendigvis en beslutning på vegne af applikationsejeren. Det samlede grundlag bør passe til den kortlagte ejerstruktur.

Cloudleverandørens regler er en selvstændig ramme

Cloudtjenester har vilkår for sikkerhedstest, og reglerne er ikke ens. Microsoft oplyser på sin side om Azure, at kunder kan teste deres egne ressourcer uden forhåndsgodkendelse, hvis reglerne følges. Siden siger samtidig, at test af tredjepartsressourcer kræver udtrykkelig skriftlig tilladelse fra ressourceejeren.

AWS oplyser, at kunder kan gennemføre visse sikkerhedsvurderinger af angivne tjenester uden forudgående godkendelse. Siden skelner mellem kundens egne ressourcer og AWS’ infrastruktur og tjenester, som kunder ikke har tilladelse til at teste. Den aktuelle politik og eventuelle undtagelser skal kontrolleres før opgaven.

Disse eksempler viser, hvorfor ordet cloud ikke er en tilladelse. Identificér konto, ressourcer, tjeneste og relevant ejer, og hold opgaven inden for leverandørens gældende regler. Testtyper og cloud som afgrænsningsspørgsmål forklares i → Typer af penetrationstest.

SaaS kræver kontrol af leverandørens vilkår

Ved en SaaS-løsning bruger virksomheden en tjeneste, som leverandøren driver. Virksomhedens egne brugere og data giver ikke nødvendigvis ret til at teste hele tjenestens tekniske lag. Aftalen, leverandørens politik og en eventuel særskilt godkendelse skal derfor undersøges.

For ERP-systemet kan virksomheden eksempelvis have administrative rettigheder i løsningen, mens leverandøren råder over platformen. En testkonto viser, hvad brugeren må gøre i almindelig drift, men er ikke i sig selv et mandat til en penetrationstest.

Hvis leverandøren alene tillader en bestemt type vurdering, bør begrænsningen stå i scope og rapport. Hvis vilkårene ikke giver et klart svar, må virksomheden indhente en afklaring eller holde området uden for opgaven. Den konkrete aftaletolkning bør overlades til juridisk rådgivning.

Koncerner skal afklare selskaber og fuldmagter

Fælles drift i en koncern kan få flere selskabers systemer til at ligne ét miljø. Den bestillende IT-funktion kan have operationelt ansvar uden at have fuldmagt til at godkende test af alle selskabers løsninger. Organisationsdiagrammet er derfor ikke nok.

Kortlæg hvilke selskaber der ejer systemer, indgår leverandøraftaler eller er kunder i de relevante tjenester. Hvis kontornettet deles, bør det fremgå, hvem der godkender test af de fælles dele, og hvem der kan acceptere påvirkning af driften.

En koncernpolitik kan støtte beslutningen, men dens rækkevidde skal være klar. Spørg juridisk ansvarlige, hvis godkendelsen bygger på interne bemyndigelser. Gem den endelige afklaring sammen med den opgave, den gælder, så rapportens forudsætninger senere kan dokumenteres.

Medarbejdere og personoplysninger kræver egne vurderinger

En teknisk tilladelse afgør ikke alle spørgsmål om medarbejdere og personoplysninger. Hvis testen kan berøre personlige konti, kommunikation eller oplysninger om brugere, skal virksomheden vurdere det relevante databeskyttelsesgrundlag og sine interne regler.

Social engineering eller kontakt til medarbejdere bør ikke udledes af en godkendelse af en teknisk test. Den aktivitet kræver sin egen beskrivelse, målgruppe og beslutning. En test af ERP-systemet giver tilsvarende ikke automatisk ret til at bruge enhver rigtig brugerkonto.

Brug testkonti og syntetiske oplysninger, når det passer til formålet og opgaven kan besvares på den måde. Det er en redaktionel anbefaling om at begrænse eksponering, ikke et udsagn om, at metoden altid er tilstrækkelig. Valget mellem miljøer behandles i → Penetrationstest i produktion eller testmiljø.

Det skal I lade være med

At antage at betaling giver tilladelse · En bestiller kan mangle ret til at godkende test af en tredjeparts system.
At lade et domænenavn definere ejerskab · Applikation, hosting og integrationer kan tilhøre forskellige parter.
At bruge administratoradgang som mandat · Tekniske rettigheder er ikke automatisk en juridisk godkendelse.
At genbruge en gammel tilladelse ukritisk · Systemer, leverandørvilkår og det nye scope kan være ændret.
At udvide testen undervejs ved mundtlig antagelse · Nye områder bør først have dokumenteret godkendelse.
At lade leverandørens cloudpolitik erstatte virksomhedens beslutning · Begge grundlag kan være nødvendige.

Tilbuddet bør vise de nødvendige godkendelser som forudsætninger, ikke skjule dem i en generel formulering. → Sammenlign tilbud på penetrationstest

Hvad kan og ikke kan konkluderes

En skriftlig tilladelse kan dokumentere, at en identificeret part har accepteret en beskrevet opgave. Den dokumenterer ikke alene, at parten havde den nødvendige ret over alle omfattede systemer. Det spørgsmål må vurderes ud fra ejerskab, aftaler og fuldmagter.

Overholdelse af en cloudleverandørs testpolitik kan vise, at opgaven følger leverandørens offentliggjorte ramme. Det afgør ikke andre juridiske spørgsmål, interne godkendelser eller rettigheder hos tredjeparter. Politikken kan desuden ændre sig, så den aktuelle version bør gemmes eller henvises til i opgaven.

En penetrationstest kan heller ikke konkludere, at virksomhedens aftaler generelt er tilstrækkelige. Testeren kan registrere forudsætninger og begrænsninger, mens en advokat må vurdere konkrete kontrakter og § 263 i den relevante situation. En introduktion til bestillingen findes på penetration-test.dk.

Tjekliste før opgaven godkendes

☐ Er hvert system, miljø og hver integration knyttet til en identificeret ejer?
☐ Har den godkendende person dokumenteret mandat til den konkrete opgave?
☐ Er hostingpartens og SaaS-leverandørens aktuelle vilkår kontrolleret?
☐ Er cloudressourcer afgrænset fra leverandørens og tredjeparters infrastruktur?
☐ Er relevante selskaber og interne fuldmagter afklaret i koncernen?
☐ Er medarbejdere, konti og personoplysninger vurderet særskilt?
☐ Står undtagelser og uafklarede dele tydeligt i scope?
☐ Er konkrete juridiske tvivlsspørgsmål sendt til en advokat?

Kilder

Straffeloven, § 263: uberettiget adgang til en andens datasystem eller data.
Microsoft Learn: Penetration testing i Azure: regler for test af egne ressourcer og krav om tilladelse ved tredjepartsressourcer.
AWS: Penetration Testing: rammer for kunders test af angivne tjenester og afgrænsning fra AWS’ infrastruktur.

Senest gennemgået: oktober 2026.