Når testeren melder en alvorlig svaghed i produktet, står softwarehuset med et spørgsmål, som rapporten ikke svarer på: skal kunderne vide det nu, senere eller slet ikke? Svaret hviler på tre forhold, som skal vurderes hver for sig: hvad I har lovet i kontrakterne, om nogen kunde reelt har været eller er udsat, og om en lov stiller krav til jer som producent. Er ingen af de tre udløst, er det stadig en beslutning, I bør træffe bevidst og skrive ned. Teksten er ikke juridisk rådgivning.
Tre spørgsmål afgør svaret
Et fund i en pentest er en svaghed, testeren har påvist under aftalte forhold. Det er ikke i sig selv en hændelse. Forskellen betyder noget, fordi kontrakter og regler kan behandle de to situationer forskelligt.
Stil derfor spørgsmålene i denne rækkefølge:
- Kontrakten · har nogen kunder en bestemmelse, der kræver besked om sårbarheder af denne alvor?
- Udsættelsen · har svagheden været tilgængelig i produktionen, og er der tegn på, at andre end testeren har brugt den?
- Loven · er produktet omfattet af regler, der kræver underretning af brugerne i bestemte situationer?
Den sikkerhedsansvarlige, produktejeren og den, der ejer kunderelationerne, bør svare sammen. Den britiske NCSC skriver om penetrationstest, at vurderingen af risiko og beslutningen om rettelser er organisationens ansvar og ikke bør overlades helt til testteamet. Det samme gælder beslutningen om at orientere kunderne. → Produktejerens rolle i penetrationstesten
Hvad kontrakterne allerede siger
Start med listen over kunder, der har særlige sikkerhedsvilkår. Nogle kontrakter kræver besked om sårbarheder over en vis alvorlighed, andre kun om hændelser, og nogle intet. Læs ordlyden for de kunder, der er berørt, og notér, hvad der udløser pligten, og hvornår beskeden skal sendes.
Har I forskellige løfter til forskellige kunder, kan det betyde, at nogle skal have besked før andre. Det er en praktisk grund til at holde vilkårene ens. Hvordan I læser og afgrænser selve bestemmelsen, er beskrevet for sig. → Pligt til at underrette kunden om sårbarheder
Kontrakten sætter et minimum. Den forbyder jer ikke at fortælle mere, og den siger ikke, at kunder uden en bestemmelse er ligegyldige.
Er nogen kunde reelt udsat?
Den vigtigste faglige vurdering er, om svagheden kunne bruges mod rigtige kunder. Et fund, der kun fandtes i et testmiljø, eller som kræver en rolle, ingen kunde har givet ud, er en anden sag end et fund i den offentlige del af produktet, der har været i drift i måneder.
Saml de oplysninger, der afgør spørgsmålet:
- Hvor fundet blev påvist · produktion, staging eller en version, der ikke er udrullet.
- Hvem der kunne nå det · alle på internettet, alle brugere eller kun bestemte roller hos en kunde.
- Hvilke kunder der har funktionen · alle, nogle moduler eller kun kunder med en bestemt opsætning.
- Spor af brug · hvad jeres logning kan sige, og hvad den ikke kan.
Viser logningen tegn på, at andre end testeren har brugt svagheden, er I ikke længere kun i en sag om et testfund. Så gælder jeres proces for hændelser, og kunderne kan have krav på besked efter andre bestemmelser. → Efter en hændelse hos jer: kunden vil se en ny test
Når loven kan stille krav
Cyber Resilience Act, forordning (EU) 2024/2847, pålægger fabrikanter af produkter med digitale elementer at underrette den koordinerende CSIRT og ENISA om aktivt udnyttede sårbarheder (artikel 14, stk. 1). Efter artikel 14, stk. 8, skal fabrikanten også underrette de berørte brugere og om nødvendigt fortælle, hvad de selv kan gøre. Artikel 71, stk. 2, siger, at artikel 14 finder anvendelse fra den 11. september 2026.
To forbehold er vigtige. Pligten gælder aktivt udnyttede sårbarheder, ikke ethvert fund i en pentest. Og ifølge betragtning 12 er cloudtjenester, der er udviklet uden for en fabrikants ansvar for et produkt med digitale elementer, ikke omfattet; forordningen henviser her til NIS2 for SaaS. Leverer I også software, der installeres hos kunden, kan billedet være et andet. Om jeres produkt er omfattet, kræver en konkret vurdering. → Cyber Resilience Act: hvad softwarehuse skal holde øje med
Hvornår åbenhed giver mening uden pligt
Selv når hverken kontrakt eller lov kræver det, kan en kort orientering være det rigtige. Det gælder, hvis kunderne selv kan gøre noget for at mindske risikoen, fx ændre en indstilling eller begrænse en rolle, mens rettelsen bliver klar. Det gælder også, hvis svagheden har været udsat længe, og I ikke kan udelukke brug.
Omvendt kan en orientering om et fund, der allerede er rettet, og som aldrig var tilgængeligt i drift, give mere uro end oplysning. Så kan det være nok, at fundet står i kundeversionen af rapporten og i jeres svar på næste spørgeskema. Uanset valget skal begrundelsen kunne genfindes, hvis en kunde senere spørger. → Åbne fund i kundens rapport
Beslutter I at orientere, er indhold og tone en opgave for sig. Meddelelsen skal kunne læses af en kunde uden teknisk baggrund og samtidig være præcis nok til kundens sikkerhedsfolk. → Sikkerhedsmeddelelsen
Et tænkt eksempel
Et softwarehus leverer et bookingsystem til fysioterapeuter. Testeren finder, at en bruger med rollen receptionist kunne se kalenderen hos en anden klinik. Fundet var til stede i produktionen. To kunder har en bestemmelse om besked ved sårbarheder med høj alvorlighed.
Teamet retter fejlen inden for få dage og gennemgår logningen. Den viser ingen opslag på tværs af klinikker ud over testerens. Softwarehuset sender en kort meddelelse til de to kunder med bestemmelsen og vælger at orientere alle kunder samtidig, fordi alle havde funktionen. Beslutningen og begrundelsen gemmes sammen med rapporten.
Det skal I lade være med
- Vente på den endelige rapport · vurderingen begynder, når testeren melder fundet.
- Lade salget bestemme tidspunktet · en forestående aftale er ikke et argument for at tie.
- Kalde et testfund en hændelse eller omvendt · de to har forskellige regler.
- Sende tekniske detaljer · beskriv risiko og handling, ikke fremgangsmåde.
- Glemme at skrive beslutningen ned · også et fravalg skal kunne forklares.
Hvad kan og ikke kan konkluderes
En gennemgang af kontrakter, udsættelse og regler kan give et begrundet svar på, hvem der skal have besked. Den kan ikke udelukke, at en kunde senere ser anderledes på sagen. Logning kan vise spor af brug, men fravær af spor er ikke bevis for, at svagheden aldrig blev brugt.
Tjekliste til beslutningen
- ☐ Er det afklaret, om fundet var tilgængeligt i produktionen?
- ☐ Er det kendt, hvilke kunder der har den berørte funktion?
- ☐ Er kontrakter med underretningsbestemmelser gennemgået?
- ☐ Er logningen undersøgt for tegn på brug?
- ☐ Er det vurderet, om produktet er omfattet af lovkrav om underretning?
- ☐ Er beslutningen og begrundelsen skrevet ned?
Kilder
- Cyber Resilience Act, forordning (EU) 2024/2847: artikel 14, stk. 1 og 8, om underretning af CSIRT, ENISA og brugere ved aktivt udnyttede sårbarheder; artikel 71, stk. 2, om anvendelse fra 11. september 2026; betragtning 12 om cloudtjenester.
- NCSC: Penetration testing: risikovurdering og beslutning om rettelser er organisationens ansvar.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Alvorlige fund lige før en kundeaftale · Et fast kontaktpunkt for kundernes sikkerhedsspørgsmål
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT