Executive Summary
Alt for mange danske SMV’er køber en penetrationstest og opdager først bagefter, at scope var uklart, testadgange manglede, logning ikke var slået til, og at ingen havde aftalt, hvad et brugbart resultat egentlig skulle være. Så bliver pentesten dyr læring i stedet for et ledelsesværktøj. En bedre forberedt test giver ikke bare færre misforståelser. Den giver en rapport, du faktisk kan bruge til prioritering, dokumentation og opfølgning.
Det er relevant, fordi både NIS2 artikel 21 og GDPR artikel 32 lægger vægt på passende sikkerhedsforanstaltninger, risikostyring og evnen til at teste, om kontroller virker i praksis. En pentest er ikke i sig selv compliance. Men når den er forberedt ordentligt, kan den blive stærk evidens for, at din virksomhed arbejder systematisk med sikkerhed.
Løsningen er enkel: tag fem ledelsesbeslutninger på forhånd, saml dokumentationen på én side, og brug 10 arbejdsdage på at gøre de vigtigste systemer testklare. Du behøver ikke starte et stort IT-projekt. Du skal bare sikre, at din leverandør, din interne IT-ansvarlige og din pentester tester det rigtige under klare rammer.
Hvorfor SMV’er spilder værdi på pentest
En pentest fejler sjældent, fordi testeren er dårlig. Den fejler oftere, fordi virksomheden bestiller for bredt, for uklart eller for sent. Hvis scope hedder “test vores miljø”, får du næsten altid et diffust output. Hvis der ikke er afklaret, om testen gælder Microsoft 365, en kundevendt webapplikation, en VPN, et betalingsflow eller et testmiljø, bliver rapporten svær at omsætte til handling.
NIST SP 800-115 anbefaler netop klar planlægning, regler for gennemførelse og tydelig afgrænsning før sikkerhedstest. Det samme mønster går igen i OWASP Web Security Testing Guide, hvor testens værdi hænger tæt sammen med afgrænsning, forudsætninger og forventet resultat. I praksis betyder det, at ledelsen skal tage stilling til, hvad der er forretningskritisk, før en teknisk test giver mening.
For en dansk SMV er det som regel ikke hele infrastrukturen, der skal testes først. Det er de få systemer, hvor et brud vil ramme drift, omsætning eller fortrolige data. Det kan være mailmiljøet, en kundeportal, fjernadgang, integrationspunkter eller et system med persondata. Hvis du vil have mere klarhed over forskellen på en dyb test og et hurtigere konfigurationseftersyn, kan det give mening at se på både pentest og sikkerhedstjek som to forskellige værktøjer.
De 5 beslutninger ledelsen skal tage før testen
Hvis du kun gør én ting rigtigt før en pentest, så gør dette: beslut på ledelsesniveau, hvad testen skal svare på. Det flytter arbejdet fra teknik til styring. Her er de fem beslutninger, der normalt afgør, om rapporten bliver brugbar.
- 1. Scope: Hvilke systemer, domæner, IP-intervaller, applikationer eller brugerrejser er med, og hvad er udtrykkeligt udenfor scope.
- 2. Adgang: Skal testen være black box, grey box eller white box, og hvem leverer konti, testbrugere, MFA-flow og tekniske kontaktpunkter.
- 3. Stopregler: Hvilke handlinger må ikke påvirke drift, data eller kunder, og hvornår skal testen pauses eller eskaleres.
- 4. Succeskriterier: Hvad skal rapporten kunne bruges til, for eksempel prioriteret handlingsliste, lederresume, bevis til kunder eller grundlag for retest.
- 5. Retest: Hvornår sker opfølgning, hvad er inkluderet, og hvilke fund skal være lukket før testen kan kaldes afsluttet.
Det lyder enkelt, men det er her de fleste misforståelser starter. Hvis IT-leverandøren tror, at formålet er at “se hvad testeren finder”, mens ledelsen forventer bevis for om de vigtigste kontroller virker, ender man med forskellige mål. CISA’s vejledning om penetration testing lægger også vægt på planlagte rammer, autorisation og klare mål for testen. Det er værd at tage alvorligt, især hvis testen sker i et miljø med leverandører, cloud-platforme og begrænset intern IT-bemanding.
Den ene side du skal kræve før opstart
Du behøver ikke en tung projektmappe. Men du bør kræve et 1-sides testbrief, som alle parter kan læse og godkende. Det dokument kan sagtens være det vigtigste i hele forløbet, fordi det reducerer misforståelser før de bliver dyre.
En praktisk version for en SMV bør indeholde virksomhedens testmål, scope, kontaktpersoner, testvindue, stopregler, godkendte testkilder, nødvendige konti, logningskrav og acceptkriterier for rapporten. Hvis testen berører persondata, bør den også pege på relevant behandlingsgrundlag, dataminimering og håndtering af fund med henvisning til GDPR artikel 32. Hvis virksomheden samtidig arbejder med NIS2 eller kundekrav om dokumentation, er det oplagt at koble testbriefet til jeres overordnede modenhedsanalyse, så pentesten bliver del af en større styringshistorik og ikke et enkeltstående stunt.
Det vigtige er ikke formen. Det vigtige er, at leverandør, intern ansvarlig og pentester kan svare ja til det samme dokument. Når alle ser den samme ene side, falder behovet for lange afklaringsmøder markant.
Pentest-ready på 10 dage
Du kan gøre en SMV klar til en brugbar pentest på 10 arbejdsdage uden at gøre det til et særskilt transformationsprojekt. Pointen er ikke at pynte på miljøet. Pointen er at fjerne friktion, så testen kan gennemføres ordentligt og give valide fund.
- Dag 1-2: Vælg de 1 til 3 vigtigste systemer og beslut præcist scope. Notér også hvad der ikke skal testes nu.
- Dag 3: Udpeg én forretningsansvarlig og én teknisk kontaktperson. Aftal hvem der kan stoppe testen ved driftsrisiko.
- Dag 4: Afklar adgangsmodel. Opret testbrugere, midlertidige konti og nødvendig MFA eller VPN-adgang.
- Dag 5: Bekræft testvinduer, driftskritiske perioder og stopregler. Undgå test under lønkørsel, release-dage eller større kundeaktiviteter.
- Dag 6: Tjek at logging virker på de centrale systemer. Ikke perfekt logging, bare nok til at kunne se hændelser, loginforsøg og kritiske ændringer.
- Dag 7: Bekræft testmiljø versus produktion. Hvis I bruger testmiljø, så vurder om det reelt afspejler det, I vil have svar på.
- Dag 8: Aftal rapportformat. Kræv lederresume, prioriterede fund, forretningspåvirkning, anbefalet ansvarlig og forslag til retest.
- Dag 9: Gennemgå 1-sides testbrief med leverandør og pentester. Ret uklarheder nu, ikke på testdagen.
- Dag 10: Hold et 30-minutters go eller no-go møde og bekræft, at alle forudsætninger er på plads.
Det er ofte på dag 6 og 7, at virkeligheden bider. Mange tror, at en pentest automatisk giver mening i et testmiljø. Men hvis testmiljøet ikke ligner produktion, får du svar på noget andet end det, ledelsen bad om. Her er det bedre at være ærlig og sige, at testen afgrænses til det, der faktisk kan vurderes forsvarligt. Hvis I mangler et hurtigt overblik over opsætning og kontroller før selve testen, kan et sikkerhedstjek være en god forberedende aktivitet.
Logging, drift og leverandørstyring uden drama
Mange ledere tror, at mere forberedelse betyder mere nedetid. Det behøver det ikke. Tværtimod handler pentest-ready hardening mest om forventningsafstemning. Du skal ikke bygge et SOC før en pentest. Du skal bare sikre, at nogen kan følge med, hvis testen udløser alarmer, låser konti eller rammer en integrationsfejl.
Det gælder især i virksomheder, hvor drift er outsourcet. Her bør din IT-leverandør være med til at bekræfte, hvilke ændringer der kan ske under testen, hvem der har adgang til logs, og hvordan fejl eskaleres. Den disciplin er også relevant i forhold til NIS2’s fokus på risikostyring og sikkerhed i leverandørkæden i artikel 21. En pentest bliver langt mere værdifuld, når den ikke bare tester systemet, men også samspillet mellem virksomhed og leverandør.
Her er tommelfingerreglen: hvis en ekstern partner driver kritiske systemer for dig, skal de ikke først høre om testen, når alarmerne går. De skal kende scope, testvindue og stopregler på forhånd. Det er ledelse, ikke teknik.
Hvad et godt resultat faktisk ligner
Et godt pentest-resultat er ikke en lang rapport med mange screenshots. Et godt resultat er, at du efter testen kan svare på fire ting: Hvad blev testet. Hvad virkede ikke. Hvad betyder det for forretningen. Hvem gør hvad nu.
Bed om et lederresume på én side og en prioriteret handlingsplan med få, tydelige ejere. Bed også om acceptkriterier for, hvornår et fund kan anses for lukket. Det gør retest langt lettere og reducerer diskussionen mellem virksomhed, leverandør og pentester. Hvis målet er dokumentation til kunder, bestyrelse eller audit, bør rapporten også koble fundene til risiko, sandsynlig konsekvens og anbefalet prioritet frem for kun teknisk alvorlighed.
Det er her en pentest kan blive et forretningsværktøj. Ikke fordi testen i sig selv løser noget, men fordi den giver et fælles beslutningsgrundlag. Og hvis du vil undgå at gentage klassikeren med en rapport, der bliver liggende i et SharePoint-bibliotek, så gør retest til en aftalt del af forløbet fra starten. Det er også i tråd med god praksis fra NIST og OWASP, hvor test giver mest værdi, når fund verificeres og følges op.
Næste skridt: brug 30 minutter på de fem beslutninger
Sæt 30 minutter i kalenderen med din IT-ansvarlige og din vigtigste leverandør. Beslut de fem punkter: scope, adgang, stopregler, succeskriterier og retest. Skriv dem på én side. Vælg derefter de 1 til 3 systemer, hvor et sikkerhedsbrud vil gøre mest ondt på drift, omsætning eller persondata.
Når de beslutninger er taget, bliver pentest ikke et diffust IT-projekt, men en målrettet test af noget, der betyder noget for din virksomhed. Hvis du har brug for at placere testen i en større sammenhæng med governance, compliance og prioritering, så kan du også se, hvordan modenhedsanalyse, pentest og workshop for ledelse spiller sammen.