Bestil testen, så rapporten kan bruges over for kunder

Mange softwarehuse opdager først, når kunden beder om dokumentation, at rapporten ikke passer: modulet, kunden køber, var ikke med, der findes intet resumé, der kan deles, og testeren har ikke aftalt at skrive et erklæringsbrev. Det kan undgås ved at skrive kundernes brug ind i bestillingen. Bestillingen hviler på tre aftaler: et omfang, der dækker det, kunderne bruger, de leverancer, kunderne skal have, og en plan for efterprøvning, så kunderne kan se status.

Det er lettere at aftale det før testen end at få det lavet bagefter. Når testeren ved fra starten, at rapporten skal læses af kunders sikkerhedsfolk, kan rapporten bygges op efter det. Hvordan en bestilling af en penetrationstest generelt skrives, er forklaret på penetrationtest.dk.

Fortæl testeren, hvem rapporten er til

Begynd bestillingen med formålet: rapporten skal bruges over for nuværende og kommende kunder, som stiller krav i sikkerhedsspørgeskemaer og leverandørvurderinger. Nævn de typer krav, I oftest møder, fx krav om uafhængig tester, om test af adskillelsen mellem kunderne eller om en rapport under en bestemt alder. Formålet hjælper testeren med at prioritere og formulere. → Hvad skal kunden bruge rapporten til?

Nævn også, hvem hos jer der er kontaktperson under testen, og hvem der skal godkende de dokumenter, kunderne får. Er det sælgerne, der oftest sender dokumentationen ud, kan det være nyttigt, at en af dem læser udkastet til resuméet og siger, om det besvarer de spørgsmål, kunderne plejer at stille. Konklusionen er stadig testerens, men opbygningen kan tilpasses læseren.

CREST, en britisk nonprofitorganisation for sikkerhedsbranchen, udgiver vejledninger om, hvordan penetrationstest bør afgrænses, udføres og afsluttes. NIST SP 800-115 beskriver planlægning som en fase af testen. Ingen af dem stiller krav til jer, men de kan bruges som tjekliste til, hvad en bestilling bør tage stilling til.

Omfanget skal svare til det, kunderne køber

Tag udgangspunkt i det, kunderne faktisk bruger. Det betyder typisk:

Moduler · de dele af produktet, kunderne har adgang til, også tilkøbsmoduler, der sælges ofte.
Roller · de brugertyper, kundernes medarbejdere får, og jeres egen supportadgang.
Adskillelse · test med mindst to testlejere, så det kan afprøves, om en kunde kan nå en andens data.
API og integrationer · de grænseflader, kunderne bygger på.
Login · den måde, kunderne logger ind på, herunder single sign-on.

Tænk på de opsætninger, kunderne faktisk har. Hvis store kunder bruger funktioner, der kun er slået til for nogle, eller særlige konfigurationer, skal testlejerne have dem slået til, ellers bliver de ikke afprøvet. En testlejer med standardopsætning viser kun, hvordan produktet opfører sig for den kunde, der aldrig ændrer noget.

Skriv også, hvad der bevidst er udeladt, og hvorfor. Udeladelser er i orden, når de står i rapporten. → Scope for et SaaS-produkt

Leverancerne, kunderne skal have

Aftal hver leverance som et selvstændigt punkt i bestillingen:

Den fulde rapport · til jer, med alle detaljer.
Et resumé, der kan stå alene · med omfang, testperiode, version og fund efter alvor.
En kundeversion · hvis I vil kunne udlevere mere end resuméet uden tekniske detaljer.
Et erklæringsbrev · fra testeren, til kunder, der kun skal vide, at testen er udført.
En statusopdatering efter efterprøvning · så kunderne kan se, hvad der er rettet.

Aftal også sprog, og om testerens navn og eventuelle certificeringer må stå i dokumenterne. Kunder kan spørge til begge. → Erklæringsbrevet fra testeren

Version, miljø og datoer

Kunden skal kunne se, hvilken udgave af produktet der blev testet. Aftal, i hvilket miljø testen foregår, og sørg for, at det svarer til produktionen i det omfang, det er muligt. Bed om, at rapporten angiver version eller udgivelsesdato og testperioden. Hvis I udgiver ofte, så aftal, hvilken version der er gældende under testen, og om der må udrulles ændringer undervejs. → Hyppige udrulninger: hvilken version skal testes?

Aftal også, hvilke data testlejerne skal indeholde. Testdata, der ligner kundernes, gør testen mere realistisk, men rigtige kundedata hører ikke hjemme i et testmiljø uden en særskilt aftale med de kunder, det gælder.

Efterprøvning og tidsplan

Kunderne vil se status, ikke kun fund. Aftal derfor efterprøvning af rettede fund som en del af opgaven, med et vindue, hvor jeres udviklere kan nå at rette. Læg tidsplanen, så resultatet foreligger, før de kundekrav, I kender, forfalder, fx en fornyelse eller en kunde, der kræver en rapport under en bestemt alder. → Retest efter rettelser i en ny release

Hvad opgaven kommer til at omfatte, afhænger især af antallet af moduler, roller og testlejere, af om API og integrationer er med, og af hvor mange leverancer der skal laves ud over den fulde rapport. Se hvad der påvirker opgaven under pris og tilbud.

Afklar desuden med testeren, at I må udlevere resumé, kundeversion og erklæringsbrev til kunder, og om der er begrænsninger, fx at dokumenterne ikke må offentliggøres. Aftal også, hvordan kunder skal forholde sig, hvis de har spørgsmål til testeren. → Kunden skal skrive under på fortrolighed

Gem bestillingen sammen med rapporten. Når en kunde senere spørger, hvorfor et modul ikke var med, kan I vise, at udeladelsen var et bevidst valg, og hvad begrundelsen var.

Et tænkt eksempel

Et softwarehus med et system til kvalitetsstyring i fødevarevirksomheder bestiller sin årlige test. Bestillingen nævner, at rapporten skal bruges over for kunder, og at kunderne især spørger til adskillelse og til det nye modul til leverandørgodkendelse. Omfanget omfatter webapplikation, API, tre roller, supportadgangen og to testlejere. Leverancerne er fuld rapport, resumé på dansk og engelsk, kundeversion, erklæringsbrev og en statusopdatering efter efterprøvning seks uger senere. Testen lægges, så resultatet foreligger før to store fornyelser.

Det skal I lade være med

Bestille uden at nævne kunderne · Så skrives rapporten kun til jer.
Lade omfanget følge budgettet alene · Det skal svare til det, kunderne bruger.
Glemme erklæringsbrev og kundeversion · De er svære at få bagefter.
Udelade efterprøvningen · Kunderne vil se status.
Lægge testen efter kundens frist · Planlæg efter de krav, I kender.
Antage, at I må dele alt · Aftal udleveringen med testeren.

Hvad kan og ikke kan konkluderes

En bestilling, der tager højde for kundernes brug, giver dokumenter, der kan udleveres uden efterarbejde, og et omfang, der svarer til det, kunderne spørger om. Den kan ikke sikre, at alle kunder accepterer dokumentationen, og den ændrer ikke på resultatet af testen.

Tjekliste til bestillingen

☐ Står formålet med kundebrug i bestillingen?
☐ Dækker omfanget de moduler, roller og grænseflader, kunderne bruger?
☐ Er resumé, kundeversion og erklæringsbrev aftalt som leverancer?
☐ Er version, miljø og testperiode aftalt?
☐ Er efterprøvning med i opgaven?
☐ Ligger resultatet før de kendte kundefrister?
☐ Er udlevering til kunder aftalt med testeren?

Kilder

CREST: vejledninger om køb og implementering: vejledninger om, hvordan penetrationstest bør afgrænses, udføres og afsluttes.
NIST SP 800-115: teknisk vejledning om planlægning og gennemførelse af sikkerhedstest.

Senest gennemgået: oktober 2026.