Kunden skriver, at testeren skal have jeres accept, før testen kan begynde. Som driftsleverandør skal I ikke godkende, at kunden tester sit eget miljø. Det har kunden ret til. Det, I godkender, er de dele, der er jeres: den fælles platform, jeres værktøjer og konti i kundens miljø, og de forhold, der kan påvirke andre kunder. Jeres krav til testeren skal derfor sikre tre ting: at kunden står bag testen, at grænsen til jeres platform og andre kunder er tydelig, og at I kan reagere, hvis noget går galt.
Et hurtigt og klart svar gør testen bedre. Et langsomt eller uklart svar skubber den eller får den til at foregå uden jer.
Hvad I godkender, og hvad I ikke godkender
Skellet mellem kundens og jeres er udgangspunktet for alle jeres krav. Det kan stilles op sådan:
- Kundens egne systemer · servere, lejer og net, som kunden ejer eller lejer alene. Kunden beslutter. I bidrager med viden og drift.
- Jeres komponenter i kundens miljø · agenter, servicekonti og forbindelser til jeres platform. Kunden må få dem vurderet, men I skal vide det og kunne svare.
- Jeres fælles platform · hosting, backup, fjernstyring og andet, som flere kunder deler. Her kræves jeres tilladelse, og test kan kræve særlige vilkår.
- Andres platforme · cloudtjenester og hostingleverandører, som I selv køber. Deres regler gælder ud over jeres.
Platformsleverandørerne har egne regler. Microsofts regler for test af deres cloudtjenester gælder for alle, der tester, også eksterne konsulenter, og test er kun tilladt i egne lejere eller dem, man har udtrykkelig tilladelse til at teste.
Det, I skal kræve
Kravene er få, men de skal være skriftlige og stilles ens til alle testere. Bed om dem, så snart henvendelsen kommer.
- Kundens tilladelse · en skriftlig bekræftelse fra en, der kan forpligte kunden, på at testen er bestilt. I kan ikke selv vurdere, om testeren har lov.
- Opgavebeskrivelsen · systemer, adresser, testform og eventuelle testkonti, så I kan se, om noget rører jeres platform.
- Testperioden · dage og klokkeslæt, så vagt og overvågning ved besked.
- Hvorfra testen kommer · de adresser og den udleverede maskine, testeren bruger, så trafik kan genkendes.
- Kontakter · navngivne personer hos testeren og kunden, som kan nås i hele perioden.
- Stopprocedure · hvem der kan bede om at stoppe, og hvordan beskeden når frem.
- Behandling af oplysninger om jer · at loginoplysninger eller beskrivelser af jeres platform, testeren støder på, ikke bruges videre og behandles fortroligt.
Det sidste punkt er vigtigt, hvis testen rører noget, der kan give adgang til andre kunder. Bed om at blive orienteret med det samme, hvis testeren finder noget, der rækker ud over kunden. → Fælles administrationskonti hos MSP’en
Betingelser i stedet for afslag
Nogle dele af kundens ønske kan være vanskelige. En test, der belaster en fælles server, eller en test af backupsystemet, som rummer andre kunders kopier, kan ikke gennemføres uden hensyn. Svaret behøver ikke være nej. Det kan være en betingelse: et bestemt testvindue, en testkunde i stedet for den rigtige, eller en afgrænsning, så kun kundens egen del vurderes. → Adskillelse mellem kunder i MSP’ens miljø
Skriv betingelserne ind i jeres svar, og bed om, at de kommer med i opgavebeskrivelsen. Så ved testeren, hvad der gælder, og rapporten kan vise, hvad der blev holdt ude og hvorfor.
Det, I ikke skal kræve
Jeres godkendelse er ikke en ret til at styre testen. Undgå krav, der svækker kundens uafhængige billede af driften:
- Valg af tester · kunden vælger. I kan stille krav om fortrolighed og kontakt, ikke om hvem.
- Indflydelse på rapporten · I kan rette faktuelle fejl, men ikke få fund fjernet eller nedtonet.
- Ret til at se hele rapporten · kunden beslutter, hvad I får, og I beder om det, der er nødvendigt for at rette.
- Forudgående rettelser · det er ikke rimeligt at kræve tid til at rette før testen, hvis kunden vil se driften, som den er.
Køberens side af samme sag, herunder hvad kunden gør, hvis godkendelsen trækker ud, er beskrevet på penetrationtest.dk.
Hvem hos jer svarer
Henvendelsen kan lande hos en tekniker, en kundeansvarlig eller i den fælles servicepostkasse. Uden en fast vej risikerer den at ligge, til nogen spørger. Beslut, hvem hos jer der kan give godkendelsen, og hvem der vurderer de tekniske dele. Det kan være to forskellige personer: den ene kender kunden og aftalen, den anden kender platformen.
Lav en kort skabelon til svaret med de krav, I altid stiller, og plads til de betingelser, der gælder netop denne kunde. Så bliver svarene ens fra kunde til kunde, og kunden ved, hvad der skal til, næste gang en test er på vej. En fast svartid, som I selv har besluttet og fortalt kunderne, gør det lettere for dem at planlægge.
Jeres egen forberedelse
Når godkendelsen er givet, skal den føre til handling hos jer. Giv vagten og overvågningen besked efter aftalen. Registrer testen i jeres ændringsstyring, så andre opgaver ikke kolliderer med den. Udpeg den tekniker, der er kontakt. Og noter de testkonti og undtagelser, I opretter, så de kan fjernes bagefter. → Kunden har bestilt en test
Gem korrespondancen sammen med kundens øvrige dokumentation, så den kan findes af andre end den, der svarede. Hvis der senere opstår spørgsmål om, hvad der var aftalt, er jeres svar og kundens bekræftelse dokumentationen. → Testen i jeres ændringsstyring
Det skal I lade være med
- At godkende på et mundtligt ja fra testeren · tilladelsen skal komme fra kunden.
- At afslå hele testen, fordi en del er svær · stil betingelser for den del.
- At kræve indflydelse på rapporten · det svækker kundens uafhængige billede.
- At lade godkendelsen ligge · et sent svar presser testen ind i et dårligere vindue.
- At glemme jeres egne leverandører · deres regler gælder også.
- At undlade at informere vagten · en aftalt test, der behandles som angreb, koster tid for alle.
Hvad kan og ikke kan konkluderes
Jeres godkendelse viser, at I kender testen og har accepteret de dele, der berører jer. Den er ikke en vurdering af testerens kvalifikationer og ikke en garanti for, at testen forløber uden driftspåvirkning. Den lovlige tilladelse til at teste kundens systemer kommer fra kunden. Teksten er ikke juridisk rådgivning.
Tjekliste til godkendelsen
- ☐ Har I kundens skriftlige bekræftelse?
- ☐ Har I opgavebeskrivelsen, og ved I, om den rører jeres platform?
- ☐ Er testperiode, adresser og kontakter oplyst?
- ☐ Er der en stopprocedure?
- ☐ Er betingelser for delte dele skrevet ind?
- ☐ Er jeres egne leverandørers regler afklaret?
- ☐ Er vagt og overvågning informeret?
- ☐ Er korrespondancen gemt?
Kilder
- Microsoft: Microsoft Cloud Penetration Testing Rules of Engagement: reglerne gælder for alle, der tester, også eksterne konsulenter, og test er kun tilladt i egne lejere og ressourcer eller dem, man har udtrykkelig tilladelse til at teste.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Midlertidige undtagelser til testen · Alarmer under testen · IT-ansvarlig ved siden af jobbet
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
