En gennemført penetrationstest bliver let til en sætning om, at virksomheden er sikker. Den sætning holder ikke, fordi testens udsagn altid er bundet til det aftalte omfang, den adgang testeren fik, den metode der blev brugt, og det tidsrum testen fandt sted i.
Svaret på titlens påstand er derfor nej. En test kan vise svagheder, der fandtes og kunne påvises under bestemte forhold. Den kan ikke bevise, at der ikke findes andre. Det er ikke en fejl ved testen, men en egenskab ved enhver afprøvning, der foregår inden for rammer.
Hvad en test faktisk udtaler sig om
En penetrationstest besvarer et afgrænset spørgsmål. Kan en kunde i kundeportalen se en anden kundes ordrer? Kan en bruger på kontornettet nå ERP-systemets administrative funktioner? Svaret er gyldigt for de roller, systemer og forudsætninger, der indgik.
Resultatet har to sider. Påviste fund er konkret dokumentation for et problem. Fravær af fund er en svagere oplysning: det fortæller, at testeren ikke påviste noget inden for de givne rammer. Det er ikke det samme som en bekræftelse af, at området er fejlfrit. → En penetrationstest uden fund
Hvorfor ønsket om en garanti er forståeligt
Den, der har betalt for en test, vil gerne kunne lukke sagen. Ledelsen vil have et klart svar, kunden vil have et ja, og projektlederen vil kunne sætte flueben ved punktet i planen. En garanti ville gøre alle tre ting lette.
Problemet er, at en garanti flytter ansvaret fra virksomheden til et dokument. Når rapporten bliver beviset på, at alt er i orden, holder nogen op med at stille spørgsmål. Det er mere nyttigt at se testen som et stykke viden, der skal bruges, end som en kvittering, der skal arkiveres.
Fire grænser for testens udsagn
Hver rapport har grænser, og de bør kunne findes i teksten.
- Omfang · systemer, funktioner og net uden for scope er ikke vurderet, uanset hvor tæt de ligger på det testede.
- Udgangspunkt · en test uden login siger ikke det samme som en test med en udleveret konto, og omvendt.
- Tid · testen beskriver en tilstand i en periode. Nye versioner, ændrede regler og ny viden om svagheder kan flytte billedet bagefter. → Penetrationstesten er et øjebliksbillede
- Ressourcer · testeren har en aftalt mængde tid og må ikke alt. En angriber er ikke bundet af samme rammer.
De fire grænser er ikke svagheder, der kan fjernes med en større bestilling. En bredere test flytter grænserne, men de forsvinder ikke.
Når garantien sniger sig ind i sproget
En omhyggeligt skrevet rapport lover ikke sikkerhed. Risikoen ligger i det, der skrives bagefter. En statusmail til ledelsen kan hedde “testen er bestået”. Et svar til en kunde kan lyde “vi er pentestet og godkendt”. En linje på hjemmesiden kan love, at webshoppen er sikkerhedstestet uden at sige hvornår eller hvordan.
Samme glidning kan ske internt. Et budgetoplæg kan bruge testen som begrundelse for at udskyde en opgradering af kontornettet, selv om kontornettet aldrig var en del af opgaven. Når resultatet citeres, bør det altid ske med henvisning til, hvad der blev testet.
Hver af de formuleringer lover mere, end rapporten dækker. Ordet bestået forudsætter en standard, testen ikke har målt imod. Godkendt antyder en myndighed eller et certifikat. Og en løs henvisning til sikkerhedstest uden dato kan blive stående, længe efter at systemet er ændret.
Sådan omtaler I resultatet uden at overdrive
Brug sprog, der kan føres tilbage til rapporten. En brugbar formulering nævner systemet, perioden, typen af test og status for fundene. For eksempel: kundeportalen blev testet med kunde- og administratorroller i en angiven periode; de påviste fund er rettet og efterprøvet, bortset fra et fund, som ledelsen har besluttet at håndtere senere.
Den slags sætninger er længere end et stempel, men de kan forsvares. Skal en kunde have dokumentation, er en erklæring med omfang og dato bedre end en løs bekræftelse. → Testerklæring til kunder
Det britiske NCSC beskriver i sin vejledning penetrationstest som en måde at opnå sikkerhed for, at organisationens egen håndtering af sårbarheder virker, snarere end som den primære måde at finde dem på. Den tanke er nyttig her: testen er en kontrol af jeres arbejde, ikke en erstatning for det.
Det, der skal være på plads ud over testen
Når testen ikke kan garantere noget, må sikkerheden hvile på andet end testen alene. Det løbende arbejde med opdateringer, overblik over systemer og håndtering af kendte svagheder hører til hverdagen. → Sårbarhedsstyring og penetrationstest
Det samme gælder evnen til at opdage og reagere, hvis noget alligevel sker. En test af webshoppen siger ikke, om nogen opdager et uønsket login en søndag aften, eller om backup kan genskabes. Det er andre spørgsmål med andre undersøgelser.
Og det, der står tilbage efter testen, skal have en ejer. Både urettede fund og uprøvede områder er en del af den rest, ledelsen skal kende. → Restrisiko
Det skal I lade være med
- At skrive bestået om en test · der findes ingen bestået eller dumpet, kun resultater under bestemte forudsætninger.
- At lade nul fund betyde sikker · fravær af fund er en oplysning om testen, ikke om systemets fejlfrihed.
- At bruge en gammel test som aktuel dokumentation · nævn altid perioden og de ændringer, der er sket siden.
- At omtale en test af ét system som en test af virksomheden · webshoppens resultat dækker ikke ERP-systemet eller kontornettet.
- At bruge testen som argument for at skære i det løbende arbejde · overvågning, opdateringer og beredskab er fortsat nødvendige.
- At love kunder mere end rapporten siger · hold udsagn udadtil inden for det dokumenterede omfang.
Hvad kan og ikke kan konkluderes
En penetrationstest kan dokumentere, at bestemte svagheder fandtes og kunne udnyttes under de beskrevne forhold. Den kan efter rettelse og efterprøvning underbygge, at netop de fund ikke længere blev påvist.
Den kan ikke konkludere, at systemet er sikkert, at der ikke findes andre fejl, eller at resultatet gælder efter senere ændringer. Den siger heller intet om systemer, der ikke var med. Rapporten skal læses sammen med scope og testperiode, før nogen bygger en beslutning på den. → Sådan læser I en pentestrapport
Tjekliste, før I omtaler resultatet
- ☐ Nævner formuleringen det testede system og ikke hele virksomheden?
- ☐ Står testperioden, så læseren kan se, hvor gammelt resultatet er?
- ☐ Fremgår det, om testen var med eller uden login?
- ☐ Er status for fund beskrevet som rettet, efterprøvet eller åben?
- ☐ Er ord som bestået, godkendt og certificeret undgået?
- ☐ Er de væsentligste fravalg i scope nævnt?
- ☐ Er det løbende sikkerhedsarbejde stadig planlagt uafhængigt af testen?
Kilder
- NCSC: Penetration testing: penetrationstest som kontrol af organisationens egen sårbarhedshåndtering.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Testerklæring til kunder · Spørgsmål og svar
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
