En testpolitik for kunder: reglerne for deres test af produktet

Når flere kunder vil teste jeres produkt, holder det ikke at forhandle reglerne forfra hver gang. En testpolitik samler reglerne ét sted: hvem der må teste, hvor og hvornår, hvad der ikke må ske, og hvad der sker med fundene. Den hviler på det samme hensyn som al test i et delt produkt, nemlig at én kundes test ikke må gå ud over de andre kunders drift og data.

Politikken er ikke en kontrakt i sig selv. Den er et dokument, kunderne kan få på forhånd, og som kontrakten kan henvise til. Det gør svaret til sælgeren kort: ja, det må I gerne, og her er reglerne.

Hvorfor en politik er bedre end aftaler fra sag til sag

Uden en politik bliver hver kundes ønske om at teste en lille forhandling. Sælgeren spørger udviklerne, udviklerne spørger driften, og svaret afhænger af, hvem der svarer. Det tager tid i salget, og kunderne får forskellige vilkår uden at vide hvorfor.

En skrevet politik gør tre ting. Den giver kunderne et hurtigt svar. Den sikrer, at alle kunder bliver behandlet ens. Og den gør det muligt for driften at planlægge, fordi de ved, hvad en kundes test må indebære. → Kunden vil selv teste jeres produkt

De store cloudplatforme har offentlige regler af samme slags. Microsoft og AWS beskriver, hvad deres kunder må teste i egne ressourcer, hvad der er forbudt, og hvornår der kræves forudgående godkendelse. Jeres kunder kender formen, og det gør jeres egen politik lettere at forstå.

Hvad politikken bør tage stilling til

En testpolitik for et SaaS-produkt bør som minimum svare på disse spørgsmål:

Hvem må teste · kunden selv og testere, kunden har bemyndiget, og kun i kundens egen lejer eller et miljø, I stiller til rådighed.
Besked og godkendelse · om testen skal anmeldes, hvor længe før, og hvilke oplysninger anmeldelsen skal indeholde.
Miljø og tidsrum · om testen sker i et særskilt miljø eller i produktionen, og hvornår den må finde sted.
Hvad der er udelukket · test, der belaster den fælles drift, forsøg på at gøre produktet utilgængeligt, test af andre kunders data og af jeres underleverandørers systemer.
Uheld · hvad testeren gør, hvis andres data bliver synlige: stoppe, give besked, ikke gemme og ikke dele.
Fund · at fund i produktet sendes til jer, hvordan, og hvornår.
Fortrolighed · hvordan kundens rapport om produktet må bruges og deles.
Kontakt og stop · hvem testeren kontakter, og hvem der kan stoppe testen.

Listen er ikke udtømmende. Har produktet særlige dele, fx integrationer til tredjeparter eller betalinger, kan de kræve egne regler. → Kundens test i et delt miljø

Fundene og fortroligheden

Et punkt, kunderne kan overse, er, hvad der sker med fundene. For jer er det det vigtigste. Et fund i produktet rammer alle kunder, og I skal kende det for at kunne rette det. Politikken bør sige, at fund i selve produktet sendes til jer, og gerne inden kunden deler rapporten bredt internt. → Kundens tester finder et fund

Fortroligheden går begge veje. Kunden skal kunne stole på, at det, I ser af deres opsætning, bliver hos jer. I skal kunne stole på, at detaljer om svagheder i produktet ikke bliver delt, før der er en rettelse. → Fortrolighed begge veje

Testpolitik og politik for sårbarhedsrapporter

En testpolitik for kunder er ikke det samme som en politik for, hvordan udefrakommende kan rapportere sårbarheder. Den første handler om kunder, der har en aftale med jer og vil teste med jeres viden. Den anden handler om alle andre, der finder noget og vil sige det.

RFC 9116 beskriver en fast fil, hvor organisationer kan oplyse, hvordan sårbarheder rapporteres, og hvor deres politik for offentliggørelse findes. Det er naturligt at holde de to politikker hver for sig, men at lade dem henvise til hinanden, så en kunde, der finder noget uden for sin aftalte test, ved, hvad der gælder. → Ansvarlig offentliggørelse

Hvor politikken bor

Politikken gør mest gavn, når kunderne kan finde den uden at spørge. Den kan fx ligge på jeres tillidsside eller i den sikkerhedspakke, der sendes til nye kunder. Så kan kundens sikkerhedsansvarlige læse den, før spørgsmålet overhovedet kommer til sælgeren. → Tillidsside

I kontrakten kan en kort henvisning til politikken erstatte lange bestemmelser om test. Vil kunden have en egentlig testklausul, er politikken et godt udgangspunkt for, hvad I kan acceptere. → Testklausulen i jeres kundekontrakt

Politikken bør også have en ejer og et fast kontaktpunkt. Det er den, kunder henvender sig til, og den, der sørger for, at politikken følger med, når produktet ændrer sig. → Et fast kontaktpunkt for sikkerhed

Et tænkt eksempel

Et softwarehus med et system til projektstyring har på et år fået fire anmodninger fra kunder, der vil teste selv. Hver gang er der gået uger med mails mellem sælger, udviklere og drift, og de fire kunder har fået forskellige vilkår.

Den sikkerhedsansvarlige skriver en politik på to sider ud fra de spørgsmål, der kom op i de fire sager. Den siger, at test sker i et særskilt miljø, medmindre andet aftales, at testen anmeldes på en fast formular, at fund sendes til en bestemt adresse, og hvad testeren gør, hvis andres data bliver synlige. Politikken lægges på tillidssiden.

Næste gang en kunde spørger, sender sælgeren et link. Kundens tester udfylder formularen, og driften får besked uden at nogen skal finde svaret frem igen.

Det skal I lade være med

Skrive politikken så stramt, at ingen test er mulig · så ender kunderne med at forhandle uden om den.
Skrive den så løst, at de andre kunder ikke er beskyttet · det er hovedformålet.
Glemme reglen om uheld med andres data · det er her, de alvorligste situationer opstår.
Lade den ligge, hvor kunderne ikke kan finde den · så spørger de alligevel sælgeren.
Blande den sammen med politikken for sårbarhedsrapporter · de har forskellige modtagere.
Lade den stå uændret, når produktet ændrer sig · nye dele kan kræve nye regler.

Hvad kan og ikke kan konkluderes

En testpolitik kan gøre kundernes test forudsigelige, ens og sikrere for de andre kunder, og den kan forkorte forhandlingen i salget. Den kan ikke fjerne al risiko ved test i et delt produkt, og den erstatter ikke de aftaler om ansvar, som hører hjemme i kontrakten. Teksten er ikke juridisk rådgivning.

Tjekliste til testpolitikken

☐ Siger politikken, hvem der må teste, og i hvilke lejere eller miljøer?
☐ Er krav om anmeldelse og tidsrum beskrevet?
☐ Er belastende test og test af andre kunders data udelukket?
☐ Er der en regel for uheld med andres data?
☐ Skal fund sendes til jer, og er fortroligheden beskrevet?
☐ Kan kunderne finde politikken uden at spørge?
☐ Har politikken en ejer, der holder den opdateret?

Kilder

Microsoft: Penetration Testing Rules of Engagement: eksempel på offentlige regler for kunders test, med test i egen lejer, forbudte aktiviteter og håndtering af utilsigtet adgang til data.
AWS: Penetration Testing: eksempel på en politik med tilladte tjenester, forbudte aktiviteter og forudgående godkendelse af visse former for test.
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure: fast fil med oplysninger om, hvordan sårbarheder rapporteres, og henvisning til politik for offentliggørelse.

Senest gennemgået: oktober 2026.