Når kunden beder om “testmetoden” sammen med rapporten, er det næppe kun nysgerrighed. Kunden vil kunne vise, at testen ikke var tilfældig, men fulgte en beskrevet fremgangsmåde, der dækkede det rigtige. Kravet kommer fra gennemførelsesforordning (EU) 2024/2690, bilagets punkt 6.5.2, litra b: sikkerhedstest skal udføres efter en dokumenteret testmetode, der omfatter de komponenter, en risikoanalyse har udpeget som relevante for sikker drift.
Forordningen gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Andre kunder låner ordlyden. I begge tilfælde er spørgsmålet til jer det samme: Kan I vise, hvordan testen var tilrettelagt? Teksten er ikke juridisk rådgivning.
Hvad ordlyden kræver, og hvad den ikke kræver
Punktet har to dele. Metoden skal være dokumenteret, altså beskrevet på skrift, før eller under testen. Og den skal omfatte de komponenter, en risikoanalyse har peget på. Metoden er dermed ikke kun en beskrivelse af, hvordan der testes, men også af, hvad der testes og hvorfor. Det er den sidste del, der knytter testen til kundens egen vurdering af risiko, og som gør det muligt at forklare et omfang, der ikke dækker alt.
Ordlyden peger ikke på en bestemt standard. ENISA’s vejledning til forordningen, som ikke er bindende, anbefaler at tage hensyn til branchens anerkendte standarder, når testpolitikken udarbejdes, og nævner i en fodnote eksempler som OWASP Web Security Testing Guide. Som eksempel på dokumentation nævner ENISA beskrevne testprocedurer, der bygger på standarder og god praksis, og en oversigt over de retningslinjer, enheden følger. SAMSIK’s vejledning bruger lignende ord: test kan udføres efter en dokumenteret testmetodologi og dække de komponenter, risikoanalysen har udpeget. → Det, NIS2 ikke siger om penetrationstest
Hvorfor kunden vil se metoden
En rapport viser, hvad testen fandt. Metoden viser, hvad testen kunne have fundet. Uden den kan kunden ikke skelne mellem en grundig test uden fund og en overfladisk test uden fund. Det er især vigtigt for en kunde, der selv skal kunne forklare sit grundlag over for sin myndighed. Metoden er også det, der gør det muligt for kunden at sammenligne jeres test med en anden leverandørs.
Ifølge ENISA bør dokumentationen af testen kunne forstås af en sagkyndig, der ikke selv var med. Metodebeskrivelsen er den del, der gør det muligt for en udenforstående at vurdere, om resultatet er til at stole på. → Dokumentation, som en sagkyndig tredjepart kan forstå
Det, I skal bede testleverandøren beskrive
Bed om en metodebeskrivelse, der kan følge rapporten til kunden. Den bør mindst beskrive:
- Formål · hvilke foranstaltninger eller spørgsmål testen skal belyse.
- Omfang og begrundelse · hvilke systemer, adgangsveje og funktioner der er med, og hvorfor de er valgt.
- Udeladelser · hvad der bevidst er holdt uden for, og hvorfor.
- Testtype og udgangspunkt · fx hvilken adgang testeren havde fra start, og om testen ramte et testmiljø eller drift.
- Referencer · hvilke standarder eller anerkendte vejledninger testen er tilrettelagt efter, hvis nogen.
- Vurdering af fund · hvilke kriterier der bruges til at bedømme alvoren.
- Forudsætninger og begrænsninger · tidsrum, testkonti, forhold, der kan have begrænset testen.
- Sikkerhed under testen · kontaktpersoner, og hvordan testen kunne standses.
Listen er ikke en opskrift på, hvordan testen udføres. Den er en beskrivelse, kunden kan læse og bruge. Aftal den, før testen bestilles, så den ikke skal skrives bagefter ud fra hukommelsen. → Hvad I skal bede testleverandøren om
Komponenterne fra risikoanalysen
Den del af punktet, der let bliver overset, er koblingen til risikoanalysen. Forordningen siger ikke “test alt”, men “test det, risikoanalysen har udpeget”. For en leverandør betyder det, at metodebeskrivelsen bør kunne pege tilbage på en vurdering af, hvad der er vigtigt for den sikre drift af leverancen.
Har kunden lavet en risikovurdering af jer, kan den bruges. Har I selv en, kan den også. Det vigtige er, at omfanget kan forklares med andet end “det var, hvad budgettet rakte til”.
En praktisk måde er at lade metodebeskrivelsen indeholde en kort liste over de dele af leverancen, kunden er afhængig af, og markere, hvilke der er med i denne test. De dele, der ikke er med, kan have deres egen plan eller være dækket af en tidligere test. Så kan kunden se hele billedet og ikke kun det udsnit, rapporten handler om. → Kundens risikovurdering som grundlag for jeres test
Et tænkt eksempel
En leverandør af en webbaseret løsning til indberetning af måledata for en vandforsyning sender sin seneste testrapport til kunden. Kunden svarer, at rapporten mangler en beskrivelse af metoden. Leverandøren beder testleverandøren om et kort afsnit, der forklarer formålet, de tre dele af løsningen, der var med, hvorfor styringsudstyret hos kunden var udeladt, hvilke testkonti der blev brugt, og hvordan fund blev vurderet.
Afsnittet fylder to sider. Kunden kan nu se, at det, kunden var mest bekymret for, nemlig adgangen til at ændre måledata, var en del af testen, og at udeladelsen af anlægget var et bevidst valg af hensyn til driften. Næste gang aftaler leverandøren metodeafsnittet med testleverandøren fra start, så det følger rapporten automatisk.
Når metoden skal genbruges
En dokumenteret metode gør det også lettere at gentage testen. Bruges den samme beskrivelse ved næste test, kan kunden sammenligne resultaterne og se, om noget er blevet bedre eller værre. Ændres metoden, bør ændringen forklares, så et fald i antallet af fund ikke bare skyldes, at der blev testet mindre. ENISA nævner som eksempel på dokumentation planer for kommende og gennemførte test og en liste over rapporter fra tidligere test. → Kunden vil se jeres testpolitik
Det skal I lade være med
- At sende en rapport uden metodebeskrivelse · kunden kan ikke vurdere et resultat uden fund.
- At love, at testen følger en bestemt standard · medmindre det er aftalt og beskrevet.
- At beskrive værktøjer i stedet for metode · kunden har brug for formål, omfang og kriterier.
- At skjule udeladelser · de skal stå med en begrundelse.
- At ændre metoden uden at sige det · resultaterne kan så ikke sammenlignes.
Hvad kan og ikke kan konkluderes
En dokumenteret metode viser, at testen var tilrettelagt og afgrænset bevidst, og den gør resultatet muligt at vurdere for andre. Den viser ikke, at metoden var den rigtige for kundens risiko, eller at testen fandt alt inden for omfanget. Om metoden er tilstrækkelig, vurderer kunden, og for en omfattet kunde i sidste ende kundens myndighed. → Kundens krav til testeren
Tjekliste til metodebeskrivelsen
- ☐ Står formålet og de foranstaltninger, testen skal belyse?
- ☐ Er omfanget begrundet i en vurdering af risiko?
- ☐ Er udeladelser nævnt med begrundelse?
- ☐ Er kriterierne for at vurdere fund beskrevet?
- ☐ Står eventuelle referencer til standarder, hvis de er aftalt?
- ☐ Kan beskrivelsen genbruges ved næste test?
Kilder
- Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 6.5.2, litra b.
- ENISA, NIS2 Technical Implementation Guidance (juni 2025): ikke bindende vejledning til punkt 6.5.1 og 6.5.2, herunder standarder og dokumentation.
- SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 6.b om dokumenteret testmetodologi.
- OWASP Web Security Testing Guide: et af de eksempler på anerkendte vejledninger, ENISA nævner.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om NIS2 og penetrationstest
Læs også: Fra effektivitetskrav til testplan · Gennemførelsesforordning 2024/2690
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT