...
Artikler om pentestrapporten
Kundekravet: når kunden spørger efter test
Kravet om en pentestrapport opstår i salget, ved en fornyelse eller i kundens leverandørpolitik. Artiklerne handler om at forstå kravet, før I bestiller noget.
→ Temaside: Kundekravet: når kunden spørger efter en pentest
- Aftalen venter på en pentestrapport: hvad gør I nu?
- Hvad skal kunden bruge rapporten til? Spørg, før I bestiller testen
- Den første store erhvervskunde: hvornår skal produktet testes?
- Kravet står i kundens leverandørpolitik: sådan læser I det
- Flere kunder stiller forskellige krav til testen: hvad gør I?
- Kunden vil have en rapport, der er under et år gammel
- Salget er gået i stå på kundens sikkerhedsgennemgang
- Integrationsplatformen eller partnerprogrammet kræver en sikkerhedstest
- Kunder omfattet af NIS2: hvad betyder det for jeres produkt?
- En kunde i sundhedssektoren vil se dokumentation for test
- Kunden spørger efter en kendt sårbarhed: er jeres produkt ramt?
- Efter en hændelse hos jer: kunden vil se en ny test
- Kontrakten skal fornyes, og kunden vil se den nyeste rapport
- Kunden accepterer ikke jeres egen interne test
- Konkurrenterne kan vise en test, I kan ikke
- Kravet kommer fra kundens rådgiver eller konsulent
- Hvornår skal I selv bringe testen på bane i salget?
- Startup uden sikkerhedsfunktion: det første krav fra en kunde
- Produktet eller hele virksomheden: hvad vil kunden have testet?
- Kunden spørger til hosting og underleverandører i jeres kæde
- Kunden vil have testet netop deres opsætning af produktet
- En udenlandsk kunde stiller krav efter egne regler
- Pentest af et SaaS-produkt: fra bestilling til kundeudlevering
- Testen er bestilt, men ikke færdig: hvad kan kunden få nu?
Sikkerhedsspørgeskemaer og leverandørvurdering
Kravet kan komme som ét spørgsmål blandt mange i kundens spørgeskema. Her er svarene på de spørgsmål om test, fund, udvikling og underleverandører, der binder jer.
→ Temaside: Sikkerhedsspørgeskemaer og leverandørvurdering
- Sikkerhedsspørgeskema fra kunden: sådan griber I det an
- Spørgsmålet om penetrationstest i skemaet: hvad svarer I?
- I har endnu ikke fået lavet en test: et ærligt svar i skemaet
- Standardiserede spørgeskemaer: CAIQ, SIG og kundens egne
- Et svarbibliotek: genbrug svar uden at love for meget
- Hvem i softwarehuset skal svare på sikkerhedsspørgsmål?
- Hvor ofte tester I? Sådan svarer I præcist på spørgsmålet
- Kunden spørger, hvem der testede: uafhængighed og kvalifikationer
- Skemaet spørger til åbne fund: hvad bør I oplyse?
- Ja, nej eller delvist: når svaret ikke passer i skemaet
- Kompenserende foranstaltninger: når et krav ikke er opfyldt
- Scanning og pentest i samme spørgsmål: hold dem adskilt i svaret
- Opfølgende spørgsmål fra kundens sikkerhedsteam
- Sikkerhedsmødet med kunden: forbered gennemgangen
- Skemaet ligger i kundens vurderingsportal
- Kunden henviser til en ekstern sikkerhedsrating af jeres domæner
- Spørgsmål om sikker udvikling og kodegennemgang
- Spørgsmål om adskillelse af kundernes data
- Spørgsmål om hosting og underleverandører i skemaet
- Spørgsmål om hændelser og håndtering af sårbarheder
- Samme skema hvert år: hvad ændrer I i svarene?
- Svar, I ikke kan dokumentere: risikoen ved at love for meget
- Når kunden bruger SikkerDigitals leverandørværktøj
Rapporten og erklæringen til kunderne
Hel rapport, resumé, kundeversion eller testerklæring: hvad kunden får, på hvilke betingelser, og hvordan I holder styr på, hvem der har fået hvad.
→ Temaside: Rapporten og testerklæringen til kunderne
- Pentestrapporten, der skal vises til kunder: hvad skal den indeholde?
- Hel rapport, resumé eller erklæring: hvad giver I kunden?
- Erklæringsbrevet fra testeren: hvad det kan og ikke kan sige
- Kundeversionen af rapporten: hvad kan udelades?
- Bestil testen, så rapporten kan bruges over for kunder
- Sådan vælger I tester, når rapporten skal bruges over for kunder
- Omfangsafsnittet: det første, kundens sikkerhedsfolk læser
- Version og testdatoer: gør det tydeligt, hvad der blev testet
- Åbne fund i den rapport, kunden skal have
- Retestbevis: vis kunden, at fundene er rettet
- Rapporten dækker ikke det modul, kunden køber
- Kunden skal skrive under på fortrolighed, før rapporten udleveres
- Læseadgang eller vedhæftet fil: sådan udleverer I rapporten
- Vandmærke og sporbarhed på udleverede rapporter
- Kunden har sendt rapporten videre: hvad gør I?
- Kunden vil have testerens navn og certificering i rapporten
- Kunden læser et fund anderledes end jer
- Lav alvorlighed, stor bekymring: forklar et fund for kunden
- Rapport på dansk eller engelsk til internationale kunder
- Rapport fra en tidligere tester: kan den stadig vises?
- Meget er udgivet siden testen: sådan forklarer I kunden ændringerne
- Kunden vil se de tekniske bilag
- Ingen alvorlige fund: formidl et godt resultat ærligt
- Alvorlige fund lige før en kundeaftale
- Log over, hvem der har fået rapporten
Produktet i testen: lejere, API og integrationer
Det, der er særligt for et softwareprodukt: adskillelsen mellem kunderne, roller, API, integrationer, kundedata og de dele, kunderne spørger til i testens omfang.
→ Temaside: Produktet i testen: lejere, API og integrationer
- Hvad skal med i en penetrationstest af et SaaS-produkt?
- Multi-tenant: test af adskillelsen mellem kunderne
- Testlejere: én eller flere kunder i produktet under testen?
- Roller og rettigheder i produktet: hvilke skal med i testen?
- Supportadgang og administrationsmodul: jeres egne medarbejderes adgang
- Produktets API: det, kundernes integrationer bygger på
- Offentligt API og udviklerportal: hvad skal med i testen?
- Webhooks og udgående integrationer
- Integrationer til kundernes systemer: hvor går jeres ansvar til?
- Single sign-on mod kundernes egne login: hvad skal testes?
- Kundespecifikke tilpasninger og konfigurationer
- Installation hos kunden: hvad tester I, og hvad tester kunden?
- Produktet hostes hos en cloududbyder: tilladelser og delt ansvar
- Filupload, eksport og rapporter i produktet
- Betaling og abonnement i produktet
- AI-funktioner i produktet: det, kunderne spørger til
- Open source og tredjepartskomponenter: hvad testen siger om dem
- Et staging-miljø til testen: hvad skal ligne produktionen?
- Rigtige kundedata i testen: hvad aftaler I med kunderne?
- Infrastrukturen bag produktet: skal den med i kundens rapport?
- Kildekode til testeren: hvornår giver det mening for et softwarehus?
- Kodegennemgang eller penetrationstest: hvad efterspørger kunderne?
- Flere produkter i porteføljen: hvilket skal testes først?
- En gammel version, der stadig har kunder
- White label: når en partner sælger produktet under eget navn
- Komponenter, der indlejres på kundernes hjemmesider
- Logning og revisionsspor i produktet, som kunderne spørger til
- Invitationer og brugeroprettelse på tværs af kunder
Test i takt med udvikling og releases
Når produktet ændrer sig, ældes rapporten. Artiklerne handler om at lægge test, retest og fund ind i releaseplanen og udviklingen.
→ Temaside: Test i takt med udvikling og releases
- Test ved hver release eller én gang om året?
- Hvilke ændringer i produktet kræver en ny test?
- Et årshjul for sikkerhedstest i et softwarehus
- Penetrationstest af en ny funktion før lancering
- Større omskrivning eller ny arkitektur
- Fund i backloggen: sådan prioriterer udviklingsteamet
- Sikkerhedsfund i udviklingsprocessen: hvornår er en rettelse færdig?
- Automatiske sikkerhedstest i pipelinen og den manuelle pentest
- Udviklerne og testeren: skal de tale sammen undervejs?
- Produktejerens rolle i penetrationstesten
- Lanceringsdato og testvindue: undgå, at testen bremser releasen
- Kodefrys under testen: er det nødvendigt?
- Hyppige udrulninger: hvilken version skal testes?
- Funktioner, der kun er slået til for nogle kunder
- Sårbarheder i afhængigheder mellem to test
- Fundene som læring for udviklerne
- Trusselsmodellering før testen: hvad den giver testen
- Sikkerhedskrav i kravspecifikationen
- Retest efter rettelser i en ny release
- Beta eller pilot med rigtige kunder: skal den testes først?
Kundens egne test og kontrakter med kunder
Kunder, der vil teste selv, og kontrakter med testklausuler, rettefrister og revisionsret. Teksterne er ikke juridisk rådgivning.
→ Temaside: Kundens egne test og kontrakter med kunder
- Kunden vil selv teste jeres produkt: hvad svarer I?
- Kundens test i et delt miljø: hensynet til de andre kunder
- En testpolitik for kunder: reglerne for deres test af produktet
- Kundens tester finder et fund: sådan modtager I det
- Kundens testrapport om jeres produkt: hvem ejer den?
- Testklausulen i jeres kundekontrakt: hvad kan I acceptere?
- Kunden kræver revisionsret: hvad betyder det for test?
- Rettefrister, kunden vil skrive ind i kontrakten
- Pligt til at underrette kunden om sårbarheder
- Kontrakten kræver en bestemt certificering hos testeren
- Kontrakten kræver årlig test: sådan holder I kravet over tid
- Jeres egne sikkerhedsvilkår frem for kundens
- Ansvar, hvis kundens test skader driften
- Forhandling af sikkerhedskrav: hvad kan I sige nej til?
- Sikkerhedsbilaget til kundekontrakten
- Kunden vil have alle fremtidige rapporter
- Fortrolighed begge veje: kundens oplysninger i jeres test
- Bug bounty som svar på kundens krav om test?
- Kunden vil se scope eller deltage i jeres test
- Et fast kontaktpunkt for kundernes sikkerhedsspørgsmål
Standarder og certificeringer, kunderne nævner
ISO 27001, SOC 2, ISAE, PCI DSS, OWASP, CSA STAR, D-mærket, GDPR og Cyber Resilience Act: hvad de er, og hvor pentesten passer ind.
→ Temaside: Standarder og certificeringer, kunderne nævner
- ISO 27001 i softwarehuset: hvad kunderne forventer af testen
- SOC 2-rapporten: hvad den er, og hvor pentesten passer ind
- Kunden spørger efter SOC 2, men I har ISO 27001
- ISAE 3402 og ISAE 3000: revisorerklæringen og testen
- Når produktet håndterer kortdata: PCI DSS og testkravet
- OWASP ASVS: et fælles sprog for krav til applikationen
- OWASP API Security Top 10 i kundens krav
- CSA STAR og cloudkunders krav
- Cyber Essentials og andre udenlandske ordninger i kundekrav
- D-mærket og sikkerhedstest af produktet
- Kunden er en finansiel virksomhed: krav til jer som IT-leverandør
- Cyber Resilience Act: hvad softwarehuse skal holde øje med
- GDPR artikel 32: regelmæssig afprøvning af sikkerheden
- Kunden henviser bredt til en standard: hvad betyder kravet?
- Compliance-platforme og automatisk dokumentation: hvor pentesten passer ind
- Pentesten som bevis i revisionen
- Sektorkrav hos kunderne: sundhed, finans og energi
Tillid, salg og kommunikation
Tillidsside eller trust center, sikkerhedspakke, salgsmateriale og meddelelser til kunderne: sådan taler I om testen uden at love mere, end den bærer.
→ Temaside: Tillid, salg og kommunikation om sikkerhedstest
- Tillidsside eller trust center: hvad I viser offentligt om sikkerhedstest
- Testen i salgsmaterialet: hvad må I skrive?
- Ansvarlig offentliggørelse: en kontaktvej for sårbarheder
- Sikkerhedspakken: dokumentation klar til kundernes indkøb
- Salgsteamet og sikkerhedsspørgsmål: hvad skal sælgerne vide?
- Sikkerhedsspørgsmål efter salget: kundeansvarliges rolle
- Testen finder noget alvorligt: skal kunderne have besked?
- Sikkerhedsmeddelelse til kunderne om en sårbarhed i produktet
- Åbenhed om tidligere fund over for nye kunder
- Sikkerhed som salgsargument uden at love for meget
- Kundernes eget ansvar: det, I ikke kan teste for dem
- Hvem i softwarehuset ejer kundekravet om test?
- Få udviklere, mange kundekrav: sådan planlægger I testen
- En stor kunde spørger efter mere end en pentest
- Kontornettet og produktet: to forskellige testopgaver
- Ansvarsforsikringen og kundernes krav om test
- At vente, til kunden spørger
- Typiske fejl, når softwarehuse svarer på kundekrav om test
Kræver kunden en pentestrapport?
Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage.
Seneste artikler
Når kunden bruger SikkerDigitals leverandørværktøj
27. oktober 2026
Testen er bestilt, men ikke færdig: hvad kan kunden få nu?
27. oktober 2026
Pentest af et SaaS‑produkt: fra bestilling til kundeudlevering
27. oktober 2026