Kunden vil selv teste jeres produkt: hvad svarer I?

Nogle kunder nøjes ikke med jeres rapport. De vil have deres egen tester til at teste produktet, før de køber, eller som en fast del af aftalen. Svaret er sjældent et rent ja eller nej. Det hviler på, hvor produktet kører, og hvem der ellers bruger det: en installation, der kun tjener kunden selv, kan som udgangspunkt testes på kundens vilkår, mens en løsning, som mange kunder deler, kræver betingelser, der beskytter de andre.

For en sælger er det vigtigt at have svaret klar, før spørgsmålet kommer. Et tøvende svar kan ligne noget, der skal skjules, og et for hurtigt ja kan sætte andre kunders drift og data på spil.

Hvorfor kunden spørger

Kunder har forskellige grunde til at ville teste selv, og grunden afgør, hvad der er det bedste svar:

Egen politik · kundens leverandørpolitik kræver, at kritiske systemer testes af kundens egen tester.
Mistillid til jeres rapport · kunden vil ikke stole på en test, I selv har bestilt og betalt.
Krav fra deres egne kunder eller revisorer · kunden skal dokumentere noget, jeres rapport ikke dækker.
Deres samlede løsning · kunden vil teste sin egen opsætning og integrationer, som jeres produkt er en del af.

Spørg ind, før I svarer. Det kan vise sig, at kunden kan få det, de skal bruge, ad en anden vej. → Kunden vil have testet netop deres opsætning

Behandler produktet betalingskort, kan der være et krav bag spørgsmålet. PCI DSS krav 11.4.7 siger, at udbydere med flere kunder i samme løsning skal støtte deres kunder i forbindelse med kundernes eksterne penetrationstest. → PCI DSS og testkravet

Tre mulige svar

I praksis ender svaret i en af tre former:

Ja, i et afgrænset miljø · kunden får en testlejer eller et særskilt miljø, der ligner produktionen, og som ingen andre kunder bruger.
Ja, i den fælles løsning, med betingelser · testen sker i kundens egen lejer, efter jeres regler, til aftalt tid og med besked på forhånd.
Nej, men her er dokumentationen · I tilbyder jeres egen rapport, et møde med jeres tester eller svar på kundens konkrete spørgsmål.

Den første form er ofte den bedste, når produktet deles af mange kunder. Den giver kunden frihed og holder risikoen væk fra de andre. Den anden kræver mere af aftalen. → Kundens test i et delt miljø

Den tredje er rimelig, når kundens test vil være en reel risiko for andre, eller når kundens behov kan dækkes af det, I allerede har. Men et nej skal begrundes, og det bør ledsages af noget, kunden kan bruge. → Pentestrapporten, der skal vises til kunder

Produktet hos kunden eller i den fælles løsning

Kører produktet i kundens eget miljø, er det kundens system, og kunden må som udgangspunkt teste det. Jeres interesse er at få besked på forhånd og at få fund i selve softwaren at vide, så I kan rette dem for alle. → Installation hos kunden

Kører produktet i en løsning, som mange kunder deler, er det jeres system. Her har I både ret og pligt til at sætte rammer. De store platformsleverandører gør det samme over for deres egne kunder. Microsoft og AWS tillader kunderne at teste deres egne ressourcer i cloudplatformen, men forbyder test af andre kunders data og forsøg på at gøre tjenesten utilgængelig. Den samme tankegang passer på et SaaS-produkt.

Betingelserne, I typisk stiller

Siger I ja, er det betingelserne, der gør forskellen. De bør stå skriftligt, og de bør være de samme for alle kunder, så I ikke forhandler forfra hver gang. En samlet testpolitik er den enkle måde at gøre det på. → En testpolitik for kunder

Betingelserne handler typisk om, hvem der må teste, hvornår, i hvilket miljø, hvad der ikke må ske, og hvad der sker med fundene. Hvem der bærer ansvaret, hvis testen alligevel skader driften, er et spørgsmål for kontrakten og ikke for teknikken. → Ansvar, hvis kundens test skader driften

Når kundens tester finder noget

Kundens test kan sagtens finde noget, også i et produkt, der er testet før. Det er ikke nødvendigvis et tegn på, at jeres egen test var dårlig. En anden tester ser andre ting. Det vigtige er, at fundene kommer til jer, at I kan vurdere dem, og at kunden får et svar. → Kundens tester finder et fund

Kundens rapport om jeres produkt er kundens dokument. Hvordan den må bruges og deles, bør aftales, før testen starter, så den ikke senere dukker op hos en konkurrent eller i et forum.

Et tænkt eksempel

Et softwarehus leverer et system til håndtering af kontrakter, som mange kunder deler. En ny kunde i forsikringsbranchen skriver, at deres politik kræver, at kundens egen tester afprøver alle nye systemer med adgang til kundedata.

Sælgeren spørger ind og hører, at kunden især vil se, om andre kunder kan komme til deres kontrakter. Softwarehuset tilbyder to testlejere i et særskilt miljø, der kører samme version som produktionen, og sender sin testpolitik. Kundens tester får en aftalt periode, et kontaktpunkt og besked om, at fund skal sendes til softwarehuset, før rapporten deles internt hos kunden.

Testen finder et mindre fund, som softwarehuset retter for alle kunder. Kunden får sin dokumentation, og ingen andre kunder har mærket noget til testen.

Det skal I lade være med

Sige ja i en fælles løsning uden betingelser · det er de andre kunder, der bærer risikoen.
Sige nej uden begrundelse · det ligner, at I har noget at skjule.
Forhandle reglerne forfra med hver kunde · én politik er lettere at forklare og overholde.
Glemme at aftale, hvad der sker med fundene · I skal have dem for at kunne rette dem.
Lade kundens test erstatte jeres egen · den dækker kundens behov, ikke alle kunders.
Overse et kortdatakrav bag spørgsmålet · så kan et nej være svært at stå på mål for.

Hvad kan og ikke kan konkluderes

En kundes egen test kan give kunden og jer et ekstra billede af produktet, set med en anden testers øjne. Den kan ikke erstatte jeres egen test over for andre kunder, og den siger kun noget om den del af produktet og den opsætning, kunden testede.

Tjekliste, når kunden vil teste selv

☐ Ved I, hvorfor kunden vil teste, og hvad resultatet skal bruges til?
☐ Kører produktet hos kunden eller i en fælles løsning?
☐ Kan I tilbyde et afgrænset miljø til testen?
☐ Findes der en skrevet testpolitik, kunden kan få?
☐ Er det aftalt, at fundene kommer til jer, og hvordan rapporten må bruges?
☐ Er ansvaret ved skader på driften afklaret i kontrakten?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.7 om, at udbydere med flere kunder i samme løsning støtter kundernes eksterne penetrationstest.
Microsoft: Penetration Testing Rules of Engagement: kunder må teste i egen lejer, men ikke andre kunders data, og test af tilgængelighed er forbudt.
AWS: Penetration Testing: kunder må teste egne ressourcer i udvalgte tjenester, mens test af tilgængelighed og af AWS’ egen infrastruktur er forbudt.

Senest gennemgået: oktober 2026.