Meget er udgivet siden testen: sådan forklarer I kunden ændringerne

Et SaaS-produkt står ikke stille, mens rapporten ældes. Når en kunde læser en rapport, der er nogle måneder gammel, kan produktet have fået nye funktioner, en ny login-løsning og flere integrationer, og en opmærksom kunde vil spørge, hvor meget af det, rapporten egentlig dækker. Svaret er en kort, dateret redegørelse for de væsentlige ændringer siden testen, koblet til en plan for den næste test.

Redegørelsen hviler på det, I selv ved om produktet: releasenoter, arkitekturbeslutninger og listen over ændringer, der berører sikkerheden. Den erstatter ikke en ny test, men den giver kunden mulighed for selv at vurdere, hvor godt rapporten stadig passer.

Kunden spørger, fordi rapporten er et øjebliksbillede

Det britiske NCSC påpeger, at en penetrationstest kun kan bekræfte forholdene på den dag, den blev udført. En kunde, der kender det princip, ved, at hver release efter testen er uden for rapportens dækning. Spørgsmålet er altså ikke mistro. Det er en rimelig kontrol af, om dokumentationen stadig siger noget om det produkt, kunden køber.

Det gælder især, når kunden skal bruge en del af produktet, der er kommet til efter testen. Så er rapporten ikke bare ældre; den dækker slet ikke det, kunden spørger om. → Når rapporten ikke dækker modulet

Skel mellem ændringer, der rører sikkerheden, og resten

Et produkt med hyppige udrulninger har hundredvis af små ændringer mellem to test. Kunden har ikke brug for dem alle, og en lang liste skjuler de få ændringer, der betyder noget. Udvælgelsen kræver, at nogen, der kender både produktet og testen, går listen igennem. Det, kunden har brug for, er de ændringer, der kan påvirke det, testen afprøvede:

Login og adgang · nye loginmetoder, ændret håndtering af sessioner eller nye roller.
Adskillelse mellem kunder · ændringer i, hvordan data for forskellige kunder holdes adskilt.
Nye indgange · nye API’er, integrationer, webhooks eller filupload.
Arkitektur og hosting · ny platform, ny database eller nye underleverandører.
Nye funktioner med følsomme data · fx eksport, rapporter eller AI-funktioner.

Hvilke ændringer der i jeres egen praksis udløser en ny test, er et spørgsmål for sig. → Ændringer, der udløser en ny test

Redegørelsen til kunden

Hold redegørelsen kort, så den kan læses på et par minutter. Den bør indeholde:

Rapportens udgangspunkt · testdatoer og den testede version.
Den nuværende version · og hvornår den blev udgivet.
Væsentlige ændringer · en linje for hver, med dato og en angivelse af, om den var med i testen.
Hvordan ændringerne er sikret · fx kodegennemgang, automatiske test eller en afgrænset pentest, uden at love mere end der er gjort.
Næste test · hvornår den er planlagt, og hvad den skal dække.

Skriv redegørelsen som jeres udsagn, dateret og underskrevet af en, der kender produktet. Den må ikke ligne en del af testerens rapport. Brug jeres eget brevpapir eller dokumentskabelon, og henvis til rapporten ved titel og dato, så kunden kan se, hvilket dokument redegørelsen hører til. → Version og testdatoer

Når en kunde henviser til væsentlige ændringer

Nogle kunder bruger formuleringer fra standarder. PCI DSS, som gengivet af Microsoft Learn, kræver i krav 11.4.2 og 11.4.3 intern og ekstern penetrationstest mindst hver tolvte måned og efter enhver væsentlig opgradering eller ændring af infrastruktur eller applikation. Standarden gælder ikke for alle produkter, men kunder, der kender den, kan låne tankegangen og spørge, om en bestemt ændring var væsentlig.

Det spørgsmål skal I kunne besvare med en begrundelse. Hvis I selv har vurderet, at en ændring ikke krævede en ny test, så sig hvorfor, og hvem der traf beslutningen. Hvis ændringen faktisk burde have været testet, er det bedre at sige det og vise planen. En kunde, der får en ærlig vurdering, kan have lettere ved at acceptere en plan end en kunde, der senere opdager, at en vigtig ændring aldrig blev testet. Kunder med kortdata i produktet har deres egne krav. → PCI DSS for SaaS-produkter

Et tænkt eksempel

Et softwarehus leverer et system til håndtering af kontrakter. Rapporten er fra marts. Siden er der udgivet mange mindre releases, en ny integration til et e-signaturprodukt og single sign-on mod kundernes eget login. En ny kunde i september spørger, om rapporten stadig gælder.

Softwarehuset sender rapportens kundeversion og en redegørelse på én side. Den viser testdatoerne og versionen fra marts, den nuværende version og to linjer om de væsentlige ændringer: integrationen, som ikke var med i testen, og single sign-on, som blev testet i en afgrænset test i juni med en særskilt rapport. Redegørelsen oplyser, at den næste fulde test ligger i november og dækker integrationen. Kunden kan se præcis, hvad der er dokumenteret, og hvad der venter. → Kundernes single sign-on i testen

Gør redegørelsen til en fast vane

En redegørelse, der skal skrives fra bunden, hver gang en kunde spørger, bliver forsinket og upræcis. Før i stedet en løbende liste over sikkerhedsrelevante ændringer, som produktejeren eller den sikkerhedsansvarlige opdaterer ved hver release. Listen bruges både til at svare kunderne og til at planlægge næste test, så omfanget passer til det, der faktisk er ændret.

Listen er også nyttig, når den næste test skal bestilles. Testeren får et præcist billede af, hvad der er nyt, og kan bruge tiden der, hvor ændringerne er størst. → Årshjulet for test

Det skal I lade være med

Sige, at rapporten dækker den nuværende version · Den dækker den version, der blev testet.
Sende hele releaseloggen · Kunden har brug for de sikkerhedsrelevante ændringer.
Kalde jeres egne kontroller en pentest · Beskriv dem som det, de er.
Skjule en ændring, der burde være testet · Det kommer frem ved næste test.
Love en test, der ikke er planlagt · Nævn kun en dato, der er besluttet.
Lade redegørelsen stå udateret · Kunden skal vide, hvornår den var rigtig.

Hvad kan og ikke kan konkluderes

En redegørelse for ændringer viser kunden, hvor tæt rapporten ligger på det produkt, kunden faktisk køber, og hvordan I har håndteret ændringerne. Den er jeres udsagn og ikke en test. Den kan ikke erstatte en ny test af væsentlige ændringer, men den kan vise, at I ved, hvilke ændringer der er væsentlige, og har en plan.

Tjekliste til redegørelsen for ændringer

☐ Står rapportens testdatoer og version øverst?
☐ Er de sikkerhedsrelevante ændringer listet med dato?
☐ Fremgår det for hver ændring, om den var med i en test?
☐ Er jeres egne kontroller beskrevet uden at blive kaldt pentest?
☐ Er den næste test nævnt med dato og omfang?
☐ Er redegørelsen dateret og underskrevet af en, der kender produktet?

Kilder

NCSC (UK): Penetration testing: en penetrationstest kan kun bekræfte forholdene på den dag, testen blev udført.
PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.2 og 11.4.3 om penetrationstest mindst hver tolvte måned og efter væsentlige ændringer af infrastruktur eller applikation.

Senest gennemgået: oktober 2026.