Penetrationstest og straffeloven: hvorfor skriftlig tilladelse og klart omfang er afgørende

En penetrationstest er lovlig, fordi den er berettiget: Den, der råder over systemet, har givet tilladelse. Uden tilladelse er det samme arbejde strafbart. Efter straffeloven § 263, stk. 1 straffes den, der uberettiget skaffer sig adgang til en andens datasystem eller data, med bøde eller fængsel indtil 1 år og 6 måneder, og under særligt skærpende omstændigheder kan straffen efter stk. 3 stige til fængsel indtil 6 år. Derfor skal en pentest altid bygge på en skriftlig aftale med et præcist omfang, et tidsrum og en tilladelse fra den rette part – og ligger systemerne hos en cloud- eller hostingleverandør, skal deres regler også overholdes.

Guiden hører under faldgruber og officielle kilder. Indholdet er generel information, ikke juridisk rådgivning. Pris og indhold af selve testen står i pris på penetrationstest.

Hvad straffeloven siger

I den gældende lovbekendtgørelse af straffeloven (LBK nr. 1294 af 7. november 2025) gælder bl.a.:

Bestemmelse	Indhold (forenklet)
§ 263, stk. 1	Uberettiget adgang til en andens datasystem eller data bestemt til brug i et datasystem: bøde eller fængsel indtil 1 år og 6 måneder
§ 263, stk. 3	Ved forsæt til erhvervshemmeligheder, særligt skærpende omstændigheder eller systematisk/organiseret karakter: indtil 6 år
§ 263 a	Uberettiget salg, udbredelse eller videregivelse af adgangsmidler (fx adgangskoder) til datasystemer

Nøgleordet er "uberettiget". En test, der er aftalt med den, der har ret til at råde over systemet, og som holder sig inden for aftalen, er ikke uberettiget. En test, der går ud over aftalen – fx et system, der ikke var nævnt – kan være det. Bestemmelsernes nummerering kan ændre sig ved lovændringer; tjek altid den aktuelle lovbekendtgørelse på retsinformation.dk.

Hvem kan give tilladelse?

Tilladelsen skal komme fra den, der råder over systemet:

Egne servere og netværk: virksomheden selv, ved en person med bemyndigelse (fx direktør eller it-chef med fuldmagt).
Systemer hos hostingleverandør: Virksomheden kan give tilladelse til sine egne data og applikationer, men infrastrukturen tilhører leverandøren. Tjek leverandørens regler for sikkerhedstest – nogle kræver forhåndsbesked.
Cloudtjenester (fx store platforme til e-mail, filer og servere): De fleste har offentlige regler for, hvad kunder må teste uden forhåndsgodkendelse, og hvad der er forbudt (fx belastningstest).
Systemer, der deles med andre (fx et fælles bookingsystem): Kræver tilladelse fra ejeren af systemet, ikke kun fra jer som bruger.
Medarbejdernes private enheder: Er normalt uden for omfang.

Testaftalen: indhold

Punkt	Eksempel
Parter og bemyndigelse	Hvem giver tilladelsen, og med hvilken ret
Omfang	Konkrete IP-adresser, domæner, applikationer, konti
Uden for omfang	Systemer, der ikke må berøres
Metode	Black/grey/white box; social engineering ja/nej
Tidsrum	Datoer og klokkeslæt
Kontaktpersoner	Hos begge parter, med nødtelefon
Stop-regel	Hvem kan stoppe testen, og hvordan
Kritiske fund	Besked med det samme, ikke først i rapporten
Data	Fortrolighed, opbevaring og sletning af data, testeren har set
Ansvar	Hvad sker der, hvis testen forstyrrer driften

Gem aftalen, så testeren kan dokumentere sin tilladelse, hvis testen opdages og misforstås – fx af jeres MDR-leverandør.

Faldgruber

Mundtlig tilladelse: "Bare test hjemmesiden" er ikke nok. Skriv det ned.
Glemt tredjepart: Hjemmesiden ligger hos et webbureau, mailen i skyen, og webshoppen hos en platformudbyder. Hver har regler.
Omfanget skrider: Testeren finder adgang til et andet system og fortsætter. Aftal, at nye mål kræver ny tilladelse.
MDR'en ved det ikke: Jeres overvågning reagerer på testen som et ægte angreb. Aftal med MSSP'en, om testen skal være kendt eller ukendt for dem – og hvordan alarmer håndteres.
Social engineering uden ramme: Phishing-test af medarbejdere bør aftales med ledelsen og tage hensyn til databeskyttelse og arbejdsmiljø.
Bug bounty og "venlige" hackere: Finder en udefrakommende en sårbarhed uden aftale, er det ikke automatisk lovligt. Overvej en offentlig politik for, hvordan sårbarheder kan indberettes til jer (fx en security.txt-fil på hjemmesiden).

Hvis I selv er leverandør

Er I en IT-virksomhed, der laver test for kunder, så sørg for:

en standard testaftale med alle punkter ovenfor,
at kunden bekræfter sin ret til at råde over systemerne,
logning af, hvad der er testet hvornår,
forsikring, der dækker skader ved test.

Tilladelseserklæringen: kort og konkret

Ud over selve testaftalen er det en god idé, at testeren har en kort, underskrevet tilladelseserklæring med:

virksomhedens navn, CVR-nummer og underskriverens rolle,
en bekræftelse af, at virksomheden har ret til at råde over de nævnte systemer,
den præcise liste over mål (IP-adresser, domæner, applikationer),
datoer og tidsrum for testen,
navn og telefonnummer på en kontaktperson, der kan bekræfte tilladelsen døgnet rundt.

Erklæringen kan vises, hvis en hostingleverandør, en MDR-analytiker eller andre spørger, hvem der står bag den usædvanlige trafik.

Ofte stillede spørgsmål

Må vores it-medarbejder teste vores egne systemer?

Ja, hvis det sker efter aftale med ledelsen og inden for virksomhedens egne systemer. Skriv omfanget ned, især hvis systemerne ligger hos tredjepart.

Er en sårbarhedsscanning også omfattet?

En scanning af egne systemer efter aftale er berettiget. Scanning af andres systemer uden tilladelse kan være problematisk. Hold jer til jeres egne adresser.

Hvad hvis testen lægger et system ned?

Det skal testaftalen tage stilling til. Aftal tidsrum med lav risiko, en stop-regel og ansvarsfordeling.

Kilder

Retsinformation – straffeloven (LBK nr. 1294 af 7. november 2025), §§ 263 og 263 a
SikkerDigital – test og værktøjer
Datatilsynet – databeskyttelse ved test og overvågning af medarbejdere
Politi – it-kriminalitet