Kontrakten om penetrationstesten: hvilke punkter skal I have med?

En penetrationstest giver en udefra kommende part lov til at gøre noget over for virksomhedens systemer, som ellers ville være uacceptabelt. Kontrakten skal derfor først beskrive, hvad der er tilladt, hvornår og med hvilket formål, og dernæst hvad der leveres, og hvordan ansvaret er fordelt.

Det korte svar er en liste: opgavens afgrænsning, grundlaget for tilladelsen, tidsrum og kontaktpersoner, retten til at stoppe, fortrolighed og data, leverancen, ændringer og ansvar. Punkterne kan samles i ét dokument eller fordeles på kontrakt, opgavebeskrivelse og spilleregler. Det afgørende er, at dokumenterne henviser til hinanden uden at modsige hinanden. Teksten er ikke juridisk rådgivning. Er der tvivl om formuleringer, ejerskab eller ansvar, bør en advokat se på den konkrete aftale.

Tre dokumenter, én sammenhæng

Køberen modtager ofte et tilbud, en standardkontrakt og senere en praktisk aftale om afviklingen. Det kan fungere fint, hvis rækkefølgen er klar. Skriv i kontrakten, hvilket dokument der går forud, når to tekster siger noget forskelligt om samme forhold.

Opgavebeskrivelsen fortæller, hvad der skal undersøges. Spillereglerne fortæller, hvordan arbejdet må foregå: tidsrum, udelukkede metoder, kontakt og stop. Kontrakten binder delene sammen og placerer betaling og ansvar. Testes kundeportalen og webshoppen i samme opgave, skal det fremgå, om de har fælles eller adskilte vilkår. → Opgavebeskrivelsen til testeren

NIST SP 800-115 indeholder en skabelon til rules of engagement som bilag. Den er skrevet til en amerikansk sammenhæng, men kan bruges som huskeliste over emner, der bør være aftalt skriftligt, før arbejdet går i gang.

Opgaven og grundlaget for tilladelsen

Kontrakten bør henvise til en bestemt version af scope med systemer, adresser, brugerroller og undtagelser. En formulering som “test af vores IT” giver hverken testeren et klart mandat eller virksomheden et grundlag for at vurdere leverancen. → Scope i en penetrationstest

Tilladelsen skal komme fra den, der råder over systemerne. Driftes ERP-systemet af en leverandør, eller ligger webshoppen hos et hostingfirma, kan deres godkendelse være en forudsætning. Skriv forudsætningen ind, og skriv, hvem der skaffer den. Spørgsmålet om, hvem der kan give tilladelsen, er gennemgået i → Er en penetrationstest lovlig?

Se også efter, om kontrakten har en erklæring om, at bestilleren har ret til at godkende testen. En sådan erklæring flytter ikke rådigheden over systemerne. Den gør blot synligt, hvem der har påtaget sig at afklare den.

Tidsrum, kontakt og retten til at stoppe

Aftal perioden og eventuelle testvinduer. Skriv navne og kontaktveje for begge parter, også uden for almindelig arbejdstid, hvis der testes på de tidspunkter. En kontaktperson, der ikke kan træffes, gør stopretten mindre værd.

Begge parter bør kunne standse arbejdet. Virksomheden kan få brug for det, hvis kundeportalen bliver ustabil. Testeren kan få brug for det, hvis der viser sig tegn på et reelt angreb. Kontrakten bør sige, hvem der må beslutte et stop, hvordan det meddeles, og hvordan arbejdet genoptages. Det samme gælder varsling, hvis et alvorligt forhold dukker op, mens testen står på. → Kritisk fund midt i testen

Det kan også være nyttigt at aftale, hvordan testerens aktivitet kan genkendes. Driftsleverandøren og en eventuel overvågning skal kunne skelne den aftalte test fra noget uvedkommende. Hvilke oplysninger der udleveres til det formål, og hvem der modtager dem, hører med i aftalen.

Fortrolighed og data

Testeren kan få indblik i oplysninger, som virksomheden ellers beskytter. Kontrakten eller en særskilt fortrolighedsaftale bør dække, hvem der må se oplysningerne, hvordan de opbevares under opgaven, og hvad der sker med dem bagefter. → Fortrolighedsaftale før penetrationstesten

Aftal også, hvor rapporten må ligge, og hvordan den overføres. Kan testen berøre personoplysninger i webshoppen eller kundeportalen, bør virksomheden vurdere den del særskilt sammen med sin egen rådgiver. Datatilsynet har vejledning om behandling af personoplysninger.

Leverancen og modtagelsen af den

Beskriv, hvad der afleveres: rapport, resumé til ledelsen, gennemgang og eventuel retest. Er retest med, skal omfang og periode være beskrevet. Ellers skal der stå, at retest aftales særskilt. Skriv også rapportens sprog, hvis det har betydning for modtagerne.

At rapporten er modtaget, betyder ikke, at parterne er enige om indholdet. Kontrakten kan beskrive, hvordan faktuelle fejl i et udkast rettes, og hvordan en uenighed om en vurdering noteres. Ejerskab og brugsret til rapporten bør også fremgå, særligt hvis den skal vises til kunder eller en revisor.

Tænk desuden over leveringstidspunktet. Skal rapporten bruges til en beslutning om at åbne webshoppen eller til at svare en kunde, bør datoen for udkast og endelig version stå i aftalen. En leverance uden dato kan ende med at styre jeres tidsplan i stedet for omvendt.

Ændringer, ansvar og ophør

Opgaver ændrer sig. Et nyt system kommer til, eller en del må udgå, fordi en godkendelse mangler. Kontrakten bør sige, hvem der kan godkende en ændring, at den skal være skriftlig, og hvordan den påvirker tid og pris. → Ændringer i opgaven undervejs

Ansvar ved skade eller driftsforstyrrelser er et emne for sig. Læs ansvarsbegrænsninger og eventuelle krav om forsikring grundigt, og sammenhold dem med det miljø, der testes. Spørgsmålene, I kan stille, er samlet i → Ansvar og forsikring før start. Aftal endelig, hvad der sker, hvis opgaven afbrydes før tid: hvad der afleveres, og hvad der betales for.

Spørg også, om andre end kontraktparten skal udføre en del af arbejdet. Gør de det, bør kontrakten sige, at de er bundet af samme fortrolighed og samme spilleregler. En godkendelse fra hostingfirmaet kan desuden være givet til navngivne personer og skal i så fald dække alle, der deltager i testen.

Det skal I lade være med

At underskrive et tilbud uden scope · Prisen siger intet om, hvad der må testes.
At lade tre dokumenter sige tre ting · Fastlæg, hvilket dokument der går forud.
At glemme stopretten · Begge parter skal kunne standse arbejdet ad en kendt vej.
At regne bestillingen for tilladelse nok · Hostingfirma og driftsleverandør kan have egne krav.
At udskyde fortroligheden · Aftalen skal være på plads, før testeren får adgang.
At lade retest være underforstået · Står den ikke i aftalen, er den ikke aftalt.

Hvad kan og ikke kan konkluderes

En gennemarbejdet kontrakt viser, at parterne har aftalt rammerne. Den siger intet om testens kvalitet eller systemernes sikkerhed. Den kan heller ikke erstatte en juridisk vurdering af ansvar, ejerskab eller personoplysninger i den konkrete situation.

Tjekliste til kontraktudkastet

☐ Henviser kontrakten til en bestemt version af scope?
☐ Er det klart, hvilket dokument der gælder ved uoverensstemmelse?
☐ Står leverandørers godkendelser som forudsætninger med en ansvarlig?
☐ Er periode, testvinduer og kontaktpersoner for begge parter beskrevet?
☐ Kan begge parter stoppe arbejdet, og er vejen dertil beskrevet?
☐ Er fortrolighed, opbevaring og sletning af data aftalt?
☐ Er leverancer, retest og brugsret til rapporten beskrevet?
☐ Er ændringer, ansvar og ophør behandlet?

Kilder

NIST SP 800-115: kapitlerne om planlægning og bilaget med skabelon til rules of engagement.
Datatilsynet: vejledning om behandling af personoplysninger.

Senest gennemgået: oktober 2026.