Pentestrapport

White label: når en partner sælger produktet under eget navn

White label: når en partner sælger produktet under eget navn

Når en partner sælger jeres produkt under sit eget navn, ender kundens spørgsmål om sikkerhedstest hos partneren, men svaret ligger hos jer. Hvem der må vise rapporten, og hvad den dækker, hviler på to aftaler: jeres aftale med partneren om, hvad der må videregives, og testens omfang, som afgør, om partnerens udgave af produktet overhovedet er med.

Rapporten er jeres. Den handler om jeres produkt, den er bestilt af jer, og testeren har skrevet den til jer. Det ændrer sig ikke, fordi en anden virksomhed sætter sit logo på brugerfladen. Partneren kan få lov at vise den eller en del af den, men det skal være aftalt, og partnerens kunder skal kunne forstå, at det er det samme produkt under et andet navn.

To lag i samme produkt

Et white label-produkt består typisk af to lag. Det ene er jeres: koden, platformen, adskillelsen mellem kunderne, login og administrationen. Det andet er partnerens: navnet, udseendet, måske et eget domæne, en egen opsætning af funktioner og egne integrationer til partnerens øvrige systemer.

En pentest af jeres produkt dækker jeres lag. Om den også dækker partnerens lag, afhænger af, hvordan partnerens udgave er sat op. Kører den på samme platform med kun et nyt udseende, er afstanden lille. Har partneren egen drift, egne udvidelser eller egen kobling til sine kunders systemer, er der dele, som jeres rapport ikke siger noget om. → Kundens egen opsætning testet

Gør det tydeligt i omfanget, hvilken udgave testen omfatter. Hvis partnerens udgave var med, så skriv det. Hvis den ikke var, så skriv det også, så partneren ikke kommer til at love mere end rapporten bærer. → Omfangsafsnittet

Et tænkt eksempel: et softwarehus leverer et system til vagtplanlægning, som en større leverandør af lønsystemer sælger videre under eget navn. Lønleverandøren har tilføjet en kobling til sit eget lønsystem og kører en egen udgave med sit domæne. Softwarehusets rapport dækker vagtplanlægningen og platformen. Koblingen til lønsystemet og lønleverandørens drift er ikke med, og det skal lønleverandørens kunder kunne læse.

Partnerens kunder spørger partneren

Partnerens kunder kender måske ikke jer. De sender deres sikkerhedsspørgeskema til partneren, og partneren videresender spørgsmålene om test, udvikling og adskillelse til jer. Det giver en kæde, hvor svaret let bliver forvansket undervejs.

Aftal på forhånd, hvordan spørgsmålene skal håndteres:

  • Faste svar · et sæt svar om test og udvikling, som partneren må bruge uden at spørge hver gang.
  • Svar fra jer · spørgsmål, der går ud over de faste svar, sendes videre og besvares af jer.
  • Møder · om I deltager i partnerens sikkerhedsmøder med større kunder, og hvem der i så fald fører ordet.
  • Hvad partneren ikke må love · fx en bestemt testfrekvens eller rettefrist, som I ikke har aftalt.

Et fælles svarbibliotek kan gøre arbejdet lettere for begge, så længe det holdes opdateret fra jeres side. → Et svarbibliotek

Hvem må vise rapporten til hvem?

Det er her, uklarhederne let opstår. Partneren vil gerne kunne vise rapporten til sine kunder, fordi det hjælper salget. I vil gerne bevare kontrollen over et dokument, der beskriver svagheder i jeres produkt.

En løsning er at skelne mellem dokumenterne. Den fulde rapport bliver hos jer og udleveres kun i særlige tilfælde. Et resumé eller et erklæringsbrev fra testeren må partneren vise til sine kunder på aftalte vilkår. → Erklæringsbrevet fra testeren

Aftalen med partneren bør sige, hvem der må modtage dokumenterne, om modtageren skal skrive under på fortrolighed, og om partneren skal registrere, hvem der har fået dem. Det er de samme hensyn, som gælder jeres egne kunder, men med et ekstra led. Aftal også, hvad der sker med dokumenterne, når samarbejdet med partneren ophører, og om partneren får de nye rapporter, når produktet testes igen. Ellers kan en gammel rapport blive ved med at cirkulere hos partnerens kunder længe efter, at den er forældet. → Fortrolighed før udlevering

Rapporten må ikke ændres, så den ser ud til at handle om partnerens produkt. Hvis partnerens kunder skal kunne genkende produktet, kan en kort følgeskrivelse fra jer forklare, at partnerens løsning bygger på jeres produkt, og hvilken version testen omfattede.

Når testen finder noget

Et alvorligt fund rammer både jeres egne kunder og partnerens. Partneren skal derfor have besked, men kæden skal være aftalt: hvem underretter partnerens kunder, hvornår, og med hvilken tekst? Uden en aftale risikerer I, at partnerens kunder hører om fundet sent, eller at de hører forskellige versioner fra jer og partneren. → Pligt til at underrette kunden om sårbarheder

Aftal også, hvor partnerens kunder skal melde en sårbarhed, de selv finder. Kommer meldingen til partneren, skal den videre til jer hurtigt og i sin fulde form. Omvendt bør partneren melde til jer, hvis en kunde rapporterer noget, der kan skyldes partnerens egne tilføjelser, så I sammen kan finde ud af, hvor fejlen sidder.

Partnerens egen test

Nogle partnere vil selv teste produktet, før de sætter deres navn på det, eller fordi deres egne kunder kræver det. Det er rimeligt, men en test af et delt miljø skal ske på jeres betingelser, så andre kunder ikke påvirkes. Testen bør følge den samme politik, som gælder, når en kunde vil teste. Aftal også, hvem der ejer partnerens rapport, og om I får den. → En testpolitik for kunder

Det skal I lade være med

  • Lade partneren vise den fulde rapport frit · aftal, hvilke dokumenter der må deles, og med hvem.
  • Ændre rapporten til partnerens navn · det er jeres produkt og testerens dokument.
  • Glemme partnerens egne dele · eget domæne, egen drift og egne integrationer er ikke med, medmindre omfanget siger det.
  • Lade partneren svare frit i kundernes skemaer · faste svar og en vej til jer skal være aftalt.
  • Springe underretningskæden over · partnerens kunder skal også have besked ved et alvorligt fund.

Hvad kan og ikke kan konkluderes

Jeres rapport viser, hvad der blev fundet i den version og den opsætning, der var med i testen. Den kan bruges over for partnerens kunder, når partnerens udgave bygger på den testede platform uden væsentlige tilføjelser. Den siger intet om partnerens egen drift, egne udvidelser eller egne integrationer.

Tjekliste til en white label-aftale

  • ☐ Er det beskrevet, hvilke dele af produktet der er jeres, og hvilke der er partnerens?
  • ☐ Står det i omfanget, om partnerens udgave var med i testen?
  • ☐ Er det aftalt, hvilke dokumenter partneren må vise, og til hvem?
  • ☐ Skal partnerens kunder skrive under på fortrolighed?
  • ☐ Er der faste svar til partnerens spørgeskemaer og en vej videre til jer?
  • ☐ Er underretningen ved alvorlige fund aftalt hele vejen ud til partnerens kunder?

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Log over, hvem der har fået rapporten · Integrationer til kundernes systemer

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Kræver kunden en pentestrapport?

Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.