Produktet eller hele virksomheden: hvad vil kunden have testet?

Et krav om, at leverandøren skal være penetrationstestet, kan betyde to meget forskellige opgaver for et softwarehus: en test af det produkt, kunden køber, eller en test af virksomhedens egen IT, hvor medarbejdere, mail og kontornet hører til. Hvilken af dem kunden mener, afgør, hvad I skal bestille, og svaret findes i kravets ordlyd og i det, kunden er bekymret for.

For en SaaS-kunde er produktet det centrale, fordi det er der, kundens data ligger. Men nogle kunder spørger også til virksomheden bag, fordi en svaghed i jeres egen drift kan give vej ind til produktet. Det korte svar er derfor: læs kravet, spørg, hvis det er uklart, og bestil det, kravet handler om. Gør ikke den ene test til et svar på den andens spørgsmål.

To testopgaver med hvert sit spørgsmål

En test af produktet ser på det, kunderne bruger: webapplikationen, API’et, login, roller og adskillelsen mellem kunder. Spørgsmålet er, om en bruger eller en udefrakommende kan få adgang til data eller funktioner, de ikke skulle have. → Scope for et SaaS-produkt

En test af virksomheden ser på jeres egen IT: kontornettet, medarbejdernes konti, mail, fjernadgang og de systemer, udviklere og support arbejder fra. Spørgsmålet er, om en angriber kan komme ind i virksomheden og derfra videre. For et softwarehus kan den vej føre til produktionsmiljøet, kildekoden eller supportværktøjer med adgang til kundedata. Testområderne i en sådan test er beskrevet i dybden på penetration-test.dk.

De to test kan ikke erstatte hinanden. En rapport om kontornettet siger intet om, hvorvidt én kunde kan se en anden kundes data i produktet. En rapport om produktet siger intet om, hvorvidt en udvikler kan narres til at give adgang.

Sådan læser I kravet

Kig efter ordene i kravet. Nævner det produktet, tjenesten, løsningen eller applikationen, er det typisk produktet. Nævner det leverandørens systemer, infrastruktur, netværk eller organisation, kan det være virksomheden. Mange krav er formuleret bredt, fx at leverandøren skal gennemføre regelmæssige penetrationstest, og så er I nødt til at spørge.

Spørg kunden, hvad de er bekymrede for. Er det deres data i produktet? Er det jeres medarbejderes adgang til deres data? Eller er det, at de skal kunne vise deres egen revisor, at leverandørerne er testet? Svaret kan pege tydeligt på den ene eller den anden test. Bed om svaret skriftligt, så I kan henvise til det, når testen bestilles, og hvis kundens krav senere fortolkes anderledes. → Kravet står i kundens leverandørpolitik

Hvor de to mødes

For et softwarehus er der et område, hvor produkt og virksomhed overlapper: de veje, hvorpå jeres egne medarbejdere når produktet. Supportadgang til kundernes data, administrative værktøjer, adgang til produktionsmiljøet og den måde, udviklere udruller ændringer på, hører til begge verdener.

Hvis kunden er bekymret for jeres medarbejderes adgang, er det typisk her, testen skal ligge. Det kan være en del af produkttesten, hvis supportfunktionen er bygget ind i produktet, eller en særskilt opgave, hvis adgangen går gennem jeres interne systemer. Beskriv grænsen i bestillingen, så rapporten viser, hvad der var med. → Supportadgang og administrationsmodul · → Infrastrukturen bag produktet

Et tænkt eksempel

Et softwarehus med et økonomisystem til foreninger får to krav samme kvartal. Den ene kunde skriver, at løsningen skal være penetrationstestet inden for det seneste år. Den anden skriver, at leverandøren skal have gennemført en penetrationstest af egne systemer. Softwarehuset spørger begge kunder. Den første vil vide, om andre foreninger kan se deres medlemsdata. Den anden har fået et krav fra sin egen revisor om, at leverandører med adgang til økonomidata skal være testet, og er især optaget af, hvem hos softwarehuset der kan se dataene.

Svaret bliver en produkttest, der også dækker supportadgangen, og en kort beskrivelse af, hvordan medarbejdernes adgang til produktionen er styret. En separat test af kontornettet bliver planlagt til næste år, fordi den anden kunde accepterer det som plan.

Når kunden vil have begge dele

Nogle kunder, fx i regulerede brancher, kræver begge. Så er det to opgaver med hvert sit omfang og helst hver sin rapport eller hvert sit tydeligt afgrænsede afsnit. Det gør det lettere at udlevere den del, en given kunde skal bruge, og at planlægge test af produktet i takt med releases, mens test af kontornettet følger en anden rytme. Overvej også, om det er den samme tester, der skal udføre begge opgaver, eller om de kræver forskellige kompetencer. → Kontornettet og produktet: to forskellige testopgaver

Sig i rapporten, hvad der ikke var med

Uanset hvilken test I vælger, skal rapporten gøre grænsen tydelig. Kundens sikkerhedsfolk læser omfangsafsnittet først, og hvis det blot nævner produktets navn, kan en læser tro, at hele virksomheden er vurderet. Bed testeren beskrive, hvilke dele af produktet der indgik, hvilke dele af jeres egen IT der eventuelt var med, og hvad der bevidst blev holdt udenfor.

Det samme gælder jeres egne svar til kunderne. Når I henviser til testen i et spørgeskema, så skriv, hvad den dækkede, og om spørgsmålet handler om noget andet. Et svar som produktet er testet af en uafhængig part i en bestemt måned, mens den interne IT ikke var omfattet, er præcist og kan stå for et opfølgende spørgsmål. Et svar om, at virksomheden er penetrationstestet, uden forbehold, kan ikke. Kunder, der senere opdager, at testen kun dækkede den ene del, kan stille flere spørgsmål til resten af jeres dokumentation. → Omfangsafsnittet: det første, kundens sikkerhedsfolk læser

Det skal I lade være med

Sende en rapport om kontornettet som svar på et produktkrav · Den besvarer ikke kundens spørgsmål.
Gætte på, hvad et bredt krav betyder · Spørg kunden, hvad de er bekymrede for.
Glemme medarbejdernes adgang · Supportværktøjer og produktionsadgang hører til begge test.
Blande to test i én uklar rapport · Hold omfang og resultater adskilt.
Love en test af alt · Kunden får mere ud af to præcise svar end af ét bredt.

Hvad kan og ikke kan konkluderes

En test af produktet kan dokumentere, hvordan den afprøvede version modstod forsøg på at nå data og funktioner uden adgang. Den siger intet om jeres interne IT. En test af virksomheden kan dokumentere, hvordan jeres egne systemer klarede sig, men intet om produktets adskillelse af kunder. Hvilken dokumentation der er tilstrækkelig, afgør kundens krav.

Tjekliste til et uklart krav

☐ Er kravets ordlyd læst, og peger den på produkt eller virksomhed?
☐ Har I spurgt kunden, hvad de er bekymrede for?
☐ Er medarbejdernes adgang til produktion og kundedata placeret i en af testene?
☐ Er grænsen mellem de to test beskrevet i bestillingen?
☐ Kan rapporterne udleveres hver for sig?
☐ Har kunden accepteret planen, hvis den ene test ligger senere?

Senest gennemgået: oktober 2026.