Kundens krav til testeren: når NIS2‑kunden vil godkende, hvem der tester

Det sker, at en NIS2-kunde ikke kun kræver en test af leverancen, men også vil have indflydelse på, hvem der udfører den. Svaret hviler på kundens egen testpraksis: en kunde, der skal kunne forklare sit tilsyn, hvordan leverandørernes sikkerhed er vurderet, vil være sikker på, at resultatet kommer fra en part, kunden har tillid til. For jer betyder det, at kundens kriterier skal kendes og godkendes, før testen bestilles, ikke bagefter.

Kravet er ikke i sig selv urimeligt. Det bliver først et problem, når kriterierne er uklare, eller når godkendelsen kommer, efter at testen er gennemført.

Hvorfor kunden vil godkende testeren

Styrelsen for Samfundssikkerheds vejledning om foranstaltninger siger om tekniske test, at de kan udføres af enheden selv eller af tredjepart. ENISA’s tekniske vejledning til gennemførelsesforordning 2024/2690 foreslår, at en enheds testpolitik bl.a. beskriver godkendte parter, interne eller eksterne. Kunder, der har sådan en politik, kan også bruge den, når de vurderer dokumentation fra leverandører.

Kunden kan desuden have dårlige erfaringer med rapporter, der ikke kunne bruges: en scanning præsenteret som penetrationstest eller en test udført af leverandørens egen driftsafdeling. Et krav om godkendelse er kundens måde at undgå det på. → Krav om test af en uafhængig tredjepart

Det, kunden kan spørge til

Kriterierne varierer, men de kan falde inden for nogle få områder:

Uafhængighed · at testeren ikke har udviklet, driver eller sælger den løsning, der testes.
Erfaring · at testeren har arbejdet med den type system, leverancen består af.
Metode · at testen følger en dokumenteret fremgangsmåde, som kan beskrives i rapporten.
Fortrolighed · at testeren kan underskrive en fortrolighedsaftale, der også dækker kundens oplysninger.
Navngivne personer · at kunden ved, hvem der faktisk udfører arbejdet.
Certificeringer · at testeren har bestemte faglige certificeringer, hvis kunden lægger vægt på det.

Bed kunden om kriterierne på skrift. Et ønske om en anerkendt tester kan betyde meget forskelligt, og I skal kunne vise, at den valgte tester opfylder det, kunden faktisk har skrevet. → Dokumenteret testmetode

Godkendelsen skal komme før bestillingen

Den dyreste fejl er at bestille testen, gennemføre den og først derefter sende rapporten til en kunde, der ikke kan acceptere testeren. Så står I med en test, der kan bruges internt, men ikke som dokumentation over for den kunde, der stillede kravet.

Send derfor kunden et kort forslag, før I bestiller: navnet på testleverandøren, de personer, der skal udføre arbejdet, en beskrivelse af uafhængigheden og en henvisning til, hvordan kundens kriterier er opfyldt. Bed om en skriftlig godkendelse. Hvis kunden har flere krav end forventet, er det billigere at opdage det nu. → Når kravet er uklart: send en plan

Når kunden vil vælge testeren selv

Nogle kunder går længere og ønsker at bruge deres egen faste testleverandør. Det kan være en fordel, fordi kunden så har tillid til resultatet fra starten. Det rejser dog nogle spørgsmål, der skal afklares:

Hvem er bestilleren? · kunden eller jer, og hvem har kontraktforholdet til testeren.
Hvem betaler? · kunden, jer eller en fordeling efter aftale.
Hvem får rapporten? · og hvilken del af den kan kunden se.
Hvem må testen omfatte? · kun den del, kunden bruger, eller også fælles systemer med betydning for andre kunder.
Hvem kan stoppe testen? · hvis driften påvirkes, skal I kunne gribe ind.

Når testen udføres på kundens foranledning af kundens leverandør, ligner situationen en kundes egen test af jeres løsning, og de samme hensyn til tilladelse og afgrænsning gælder. → Kunden vil selv teste jeres løsning

Oplysninger, der gør godkendelsen let

Jo bedre I beskriver testleverandøren, jo hurtigere kan kunden sige ja. Bed testleverandøren om en kort præsentation, som kan sendes videre: hvem der udfører arbejdet, hvilken erfaring der er relevant, hvordan uafhængigheden er sikret, og hvordan resultatet afleveres. Bruger I fx Nielco IT, er det én konsulent, som er selvstændig, ikke sælger produkter og ikke har leverandørpartnerskaber; den slags oplysninger kan stå direkte i forslaget. → Hvad I skal bede testleverandøren om

Vær opmærksom på, at oplysninger om testleverandøren også hører hjemme i den færdige dokumentation. Kunden skal kunne se, hvem der testede, og hvornår, uden at slå op i en gammel mail. → Oplysninger om testleverandøren i dokumentationen

Hvordan en køber generelt vurderer en penetrationstester, står på penetrationtest.dk.

Flere kunder med hver sine krav til testeren

Har I flere NIS2-kunder, kan de have forskellige kriterier. Én vil have en tester med en bestemt certificering, en anden lægger vægt på, at det ikke er den samme tester hvert år, og en tredje har ingen krav overhovedet. Hvis I vil bruge én test over for dem alle, skal testeren kunne godkendes af den kunde, der stiller de strengeste krav.

Saml kundernes kriterier i en enkel oversigt, før I vælger testleverandør. Så kan I se, om der er krav, der modsiger hinanden, og tage det op med de berørte kunder i god tid. Det kan vise sig, at kravene ligner hinanden mere, end formuleringerne antyder, og at en kort forklaring er nok til at få alle til at acceptere samme valg.

Er der en reel modsigelse, fx hvis én kunde kræver en ny tester, mens en anden ønsker kontinuitet, så forklar valget og begrundelsen åbent. Kunderne skal ikke nødvendigvis være enige, men de skal kunne se, hvorfor I valgte, som I gjorde.

Det skal I lade være med

At bestille testen, før kunden har godkendt testeren · rapporten kan ende som ubrugelig over for kunden.
At lade jeres egen driftsafdeling teste, når kunden kræver uafhængighed · det opfylder ikke nødvendigvis kravet.
At acceptere vage kriterier · få dem på skrift, så I kan vise, at de er opfyldt.
At lade kundens testleverandør teste uden aftale om omfang og stop · I har stadig ansvaret for driften.
At glemme testerens navn i dokumentationen · kunden skal kunne se, hvem der udførte arbejdet.

Hvad kan og ikke kan konkluderes

En godkendelse af testeren viser, at kunden på forhånd har accepteret, hvem der udfører testen. Den gør det mere sandsynligt, at kunden kan bruge resultatet, men den afgør ikke, om testens omfang og resultat er tilstrækkeligt for kunden. En navngiven, uafhængig tester siger heller ikke noget om, hvad testen fandt. Teksten er ikke juridisk rådgivning.

Tjekliste, før testen bestilles

☐ Har kunden sendt sine kriterier for testeren på skrift?
☐ Er den valgte testleverandør og de udførende personer beskrevet?
☐ Er uafhængigheden forklaret?
☐ Har kunden godkendt testeren skriftligt?
☐ Er det aftalt, hvem der bestiller, betaler og får rapporten?
☐ Kommer testerens navn og tidspunktet med i dokumentationen?

Kilder

SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 6.b om tekniske test udført af enheden eller af tredjepart.
ENISA, NIS2 Technical Implementation Guidance: vejledning til bilagets pkt. 6.5 om testpolitik og godkendte parter. Ikke bindende.

Senest gennemgået: oktober 2026.