Opgavebeskrivelsen: dokumentet, der sendes til testeren

Et uklart dokument giver tilbud, der ikke kan sammenlignes, og en test, hvor parterne forstår opgaven forskelligt. En brugbar opgavebeskrivelse samler formål, systemer, rammer og ønsket leverance i én version, som både køber og tester kan henvise til.

Svaret på spørgsmålet om, hvad dokumentet skal indeholde, er derfor ret jordnært: det skal kunne læses af en person, der aldrig har set jeres systemer, og alligevel give et entydigt billede af opgaven. Selve valget af, hvad der skal testes, træffes før dokumentet skrives. → Scope i en penetrationstest

Et arbejdsdokument, ikke en kontrakt

Opgavebeskrivelsen er grundlaget for tilbud, planlægning og senere rapport. Den erstatter ikke kontrakten, men kontrakten bør henvise til den. Når testeren skriver i rapporten, hvad der blev undersøgt, skal det kunne sammenholdes med det, I bad om.

Dokumentet skal derfor være skrevet, så det kan sendes til flere leverandører uden mundtlige tillæg. Hvis en forklaring kun findes i et møde, når den ikke frem til alle, og tilbuddene bliver svære at holde op mod hinanden. → Sammenlign tilbud på penetrationstest

Formen kan være enkel. Et par sider med faste overskrifter er ofte lettere at bruge end et langt skema, hvor halvdelen af felterne står tomme. Det vigtige er, at hver del har en ansvarlig hos jer, og at versionen er dateret.

Dokumentets faste dele

En opgavebeskrivelse kan bygges op omkring nogle få afsnit, der går igen fra opgave til opgave:

Baggrund og formål · hvorfor testen bestilles, og hvilken beslutning den skal understøtte.
Systemer og afgrænsning · hvad der er med, og hvad der udtrykkeligt er holdt ude.
Udgangspunkt og adgang · om testen sker udefra, internt eller med brugerkonti.
Rammer for gennemførelsen · periode, tidsrum, miljø og hensyn til driften.
Kontakter og beslutningsveje · hvem der svarer, og hvem der kan stoppe arbejdet.
Leverancer · rapportens modtagere, sprog, form og eventuel kontrol af rettelser.
Praktiske forhold · tilladelser, fortrolighed og håndtering af materiale.

Rækkefølgen er ikke afgørende. Men hvis et afsnit mangler, bør det være et valg og ikke en forglemmelse.

Formålet skal kunne læses af en fremmed

Baggrundsafsnittet er det, testeren læser først. Skriv det i almindeligt sprog: kundeportalen skal åbne for nye erhvervskunder, en kunde har bedt om dokumentation, eller ledelsen vil vide, om adskillelsen mellem kontornettet og gæstenettet holder.

Et formål som “at øge sikkerheden” giver testeren meget lidt at arbejde med. En konkret anledning gør det muligt at foreslå den rette type test og at prioritere tiden fornuftigt. Den gør det også lettere at vurdere bagefter, om rapporten svarede på spørgsmålet.

Nævn også, hvem der skal læse resultatet. En rapport, der skal videre til en kunde, kan stille andre krav til resumé og sprog end en rapport, der kun bruges internt af driftsleverandøren.

Systemerne beskrevet, så de kan genkendes

Afsnittet om systemer skal være så præcist, at to testere ville forstå det ens. Det betyder navne, adresser eller placeringer, de funktioner der har betydning, og de brugerroller, der findes. For webshoppen kan det være kundekonto, kurv og ordrehistorik; for ERP-systemet afdelingsroller og administratorer.

Skriv undtagelser lige så tydeligt. Hvis betalingsløsningen drives af en anden part og ikke må undersøges, skal det stå her. Det samme gælder systemer, der deler adresse med noget, der er med, men tilhører en anden virksomhed.

Angiv også, hvem der ejer og driver de enkelte dele. Det er grundlaget for at indhente de nødvendige tilladelser, før testen begynder. → Er en penetrationstest lovlig?

Rammer og kontakter i praksis

Rammeafsnittet beskriver, hvornår og hvor testen må foregå. Angiv ønsket periode, eventuelle tidsrum hvor der ikke må testes, og om arbejdet sker i produktion eller et testmiljø. Hvis der er driftsperioder, hvor systemet er særligt følsomt, hører de også hjemme her.

Kontaktafsnittet er kort, men skal være brugbart. Navn, rolle og kontaktvej for den ansvarlige hos jer, en stedfortræder og den relevante kontakt hos driftsleverandøren. Skriv, hvem der kan træffe beslutning, hvis noget skal ændres eller stoppes undervejs.

Forberedelsens øvrige punkter, som testkonti og orientering af drift, kan nævnes med en henvisning. De behøver ikke beskrives i detaljer i dokumentet til tilbudsgiverne. → Før penetrationstesten

Leverancen beskrevet før testen

Mange uklarheder opstår først, når rapporten kommer. Beskriv derfor på forhånd, hvad I forventer at modtage: et resumé til ledelsen, en teknisk del til dem der retter, og en tydelig beskrivelse af, hvad der ikke kunne undersøges.

Skriv også, om I ønsker et afslutningsmøde, og om kontrol af rettelser skal indgå eller tilbydes som en særskilt del. Et tilbud uden den oplysning kan se billigere ud uden at være det. Angiv det ønskede sprog, hvis rapporten skal bruges over for udenlandske kunder.

Til sidst kan dokumentet have et kort afsnit med spørgsmål, I ønsker besvaret i tilbuddet. Det kan være, hvordan tiden fordeles mellem systemerne, hvem der udfører arbejdet, og hvordan alvorlige fund meldes undervejs. Når alle tilbudsgivere svarer på de samme spørgsmål, bliver forskellene synlige. Svarene kan bagefter flyttes ind i den endelige version, så dokumentet også bliver den fælles reference under selve testen.

Det skal I lade være med

At sende en liste over systemer uden formål · testeren kan ikke prioritere uden at kende anledningen.
At gemme vigtige forbehold i mails · alt, der ændrer opgaven, skal ind i en ny version af dokumentet.
At kopiere sidste års dokument uændret · systemer, roller og leverandører kan have flyttet sig siden.
At skrive “alt” eller “hele miljøet” · det giver tilbud, der dækker forskellige ting under samme ord.
At udelade det, der ikke må testes · undtagelser er en del af beskrivelsen og skal stå lige så klart.
At lade versionen være udateret · ellers kan ingen vide, hvilket grundlag rapporten bygger på.

Hvad kan og ikke kan konkluderes

En god opgavebeskrivelse gør det muligt at sammenligne tilbud og læse rapporten mod et fælles grundlag. Den kan ikke i sig selv sikre, at den valgte afgrænsning er den rigtige. Det er en vurdering, der skal træffes, før dokumentet skrives.

Dokumentet beskriver også kun det, I ved på skrivetidspunktet. Opstår der nye forhold, skal de godkendes og føres ind, så rapporten senere kan læses mod den version, der faktisk gjaldt.

Tjekliste før dokumentet sendes

☐ Står anledning og formål i almindeligt sprog?
☐ Er systemer, funktioner og roller beskrevet, så de kan genkendes?
☐ Er undtagelser og ejerskab skrevet tydeligt?
☐ Er periode, tidsrum og miljø angivet?
☐ Er kontakter, stedfortræder og beslutningsvej med?
☐ Er leverancer, modtagere og eventuel retest beskrevet?
☐ Har dokumentet dato og versionsnummer?

Kilder

NIST SP 800-115, kapitel 6: planlægning af en sikkerhedstest og indholdet i en testplan.
NCSC: Penetration testing: råd om at afklare omfang og formål, før en test bestilles.

Senest gennemgået: oktober 2026.