Kunden skal kunne vise tilsynet jeres testresultat: hvad det kræver af dokumentet

Et testresultat, der fungerer fint mellem jer og kunden, kan være svært at bruge, når det skal videre til en myndighed. Kunden kender jer, leverancen og baggrunden; myndigheden kender intet af det. Dokumentet skal derfor kunne stå alene: det skal være dateret, knyttet til en bestemt leverance, forståeligt for en sagkyndig udenforstående og vise, hvad der er sket med fundene. Det hviler på NIS 2-lovens § 21, stk. 1, nr. 5 til 7, som beskriver, hvad myndigheden kan kræve udleveret af en væsentlig enhed.

Hvordan myndigheden vurderer kundens samlede foranstaltninger, kan ingen leverandør påvirke med et dokument. Teksten er ikke juridisk rådgivning.

Hvad myndigheden kan bede kunden om

Efter § 21, stk. 1, kan den kompetente myndighed over for en væsentlig enhed blandt andet kræve at få udleveret oplysninger, der er nødvendige for at vurdere enhedens foranstaltninger (nr. 5), kræve adgang til data, dokumenter og oplysninger, der er nødvendige for tilsynet (nr. 6), og kræve dokumentation for gennemførelsen af cybersikkerhedspolitikker (nr. 7). Stk. 2 siger, at myndigheden skal angive formålet og præcisere, hvilke oplysninger der kræves, og hvordan og i hvilken form de skal udleveres. For vigtige enheder findes tilsvarende redskaber i § 24, når der er indikationer på, at loven ikke overholdes.

Kundens leverandørstyring er en del af foranstaltningerne efter § 6, stk. 1, nr. 4. Jeres testresultat kan derfor blive en del af det, kunden udleverer. → Tilsynets audits og sikkerhedsscanninger hos kunden

Kundens aftale kan pege på jer

Styrelsen for Samfundssikkerhed (SAMSIK) nævner i sin vejledning om foranstaltninger, afsnit 4, at aftaler med leverandører kan indeholde et afsnit om, at leverandøren samarbejder med enheden om at bistå de sektoransvarlige myndigheder, hvis enheden er under tilsyn. Står der sådan en bestemmelse i jeres aftale, bør I vide, hvad I kan levere, og hvor hurtigt.

Det er stadig kunden, der er under tilsyn. Jeres rolle er at give kunden et dokument, kunden kan bruge, og at svare kunden, når der kommer spørgsmål. Det kan være en god idé at aftale på forhånd, hvem hos jer der modtager den slags henvendelser, og hvor hurtigt I svarer. En anmodning fra en myndighed kan have en frist, som kunden skal overholde, og kunden har brug for at vide, om I kan nå at bidrage inden for den. → Ret til revision i aftalen

Seks egenskaber, der gør dokumentet brugbart

Et dokument, der skal kunne nå en myndighed, bør have disse egenskaber:

Dateret og versioneret · det fremgår, hvornår testen fandt sted, og hvornår dokumentet blev skrevet eller opdateret.
Knyttet til leverancen · leverancen er beskrevet med de navne, kunden bruger i sit leverandørregister.
Afgrænset · omfang og udeladelser står tydeligt, så ingen tror, det dækker mere.
Forståeligt for en udenforstående · fagudtryk og forkortelser er forklaret, og konklusionen kan læses uden jeres hjælp.
Med vurdering og status · hvert fund har en alvorlighed og en status.
Med afsender · det fremgår, hvem der testede, og hvem der er kontaktperson hos jer.

Ifølge SAMSIK’s afsnit 6.b bør dokumentationen af tekniske test kunne forstås af eksperter fra en tredjepart. En myndighed er netop sådan en læser, og en sagkyndig, myndigheden bruger, er det også. → Dokumentation, som en sagkyndig tredjepart kan forstå

Navnene skal passe til kundens register

Gennemførelsesforordning (EU) 2024/2690, som gælder direkte for bestemte digitale udbydere og kan bruges som model af andre kunder, beder i bilagets punkt 5.2 enheden føre et register over direkte leverandører med kontaktpunkter og en liste over de produkter, tjenester og processer, leverandøren leverer.

Hvis kundens register kalder jeres leverance “lønsystem og integration” og jeres dokument taler om tre servere med tekniske navne, skal nogen oversætte. Brug kundens betegnelser i resuméet, og læg de tekniske navne i et bilag. Så kan en myndighed følge sporet fra registret til testen. Spørg kunden, hvad leverancen hedder i registret, hvis I ikke ved det. Det er et kort spørgsmål, der kan spare kunden for en lang forklaring senere. → Kundens leverandørregister

Fund og opfølgning

Bilagets punkt 6.5.2, litra c, beskriver, at en enhed dokumenterer testenes type, omfang, tid og resultater med en vurdering af kritisk betydning og af afbødende foranstaltninger for hver konstatering. En myndighed, der kender forordningen, vil genkende den form.

Et dokument, der viser fundene, men ikke hvad der er sket med dem, efterlader kunden med et problem: kunden skal selv forklare, hvorfor alvorlige fund stadig står åbne. Sørg for, at status er opdateret, når kunden får dokumentet, og at datoen for statussen fremgår. Er et fund accepteret frem for rettet, skal begrundelsen stå i dokumentet. SAMSIK nævner i samme afsnit, at restrisiko hos enheden skal accepteres af risikoejere. En myndighed kan derfor spørge kunden, hvem der har accepteret et åbent fund i en leverance, kunden er afhængig af, og kunden skal kunne svare. → Status på rettelser

Et tænkt eksempel

En leverandør af et system til en kommunes borgerservice får en mail fra kommunen: myndigheden har bedt om dokumentation for opfølgning på kritiske leverandører, og kommunen vil fremlægge leverandørens testresultat.

Leverandøren gennemgår sit seneste resumé. Det mangler dato for status og bruger interne servernavne. Leverandøren tilføjer statusdato, omskriver omfanget med kommunens betegnelse fra leverandørregistret og forklarer to forkortelser. Kommunen kan nu lægge dokumentet ved sit svar uden at skulle forklare det. Leverandøren gemmer den opdaterede version som skabelon til næste år.

Det skal I lade være med

At sende et dokument uden dato · så kan ingen se, hvor gammelt resultatet er.
At bruge interne betegnelser alene · en udenforstående kan ikke koble dem til leverancen.
At lade status være forældet · den skal passe på det tidspunkt, kunden fremlægger den.
At kontakte kundens myndighed direkte uden aftale · kommunikationen går gennem kunden, medmindre andet er aftalt.
At skrive, at leverancen opfylder NIS2 · det vurderer hverken I eller testeren.

Hvad kan og ikke kan konkluderes

Et dokument med disse egenskaber gør det lettere for kunden at vise, at leverandøren er testet og fulgt op. Det kan ikke afgøre, om myndigheden finder kundens foranstaltninger tilstrækkelige, og det kan ikke erstatte kundens egen vurdering af jer. Det beskriver heller ikke andet end den testede leverance i den testede periode. Er der sket væsentlige ændringer siden, bør dokumentet sige det, så kunden ikke fremlægger et billede, der ikke længere passer.

Tjekliste før dokumentet går videre

☐ Er testperiode og statusdato angivet?
☐ Bruger resuméet kundens betegnelser for leverancen?
☐ Er omfang og udeladelser tydelige?
☐ Er fagudtryk forklaret?
☐ Har hvert fund alvorlighed og opdateret status?
☐ Fremgår tester og kontaktperson?

Kilder

NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 4, § 21, stk. 1, nr. 5 til 7, og stk. 2, samt § 24.
Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.2 og 6.5.2, litra c.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om leverandørers samarbejde, når enheden er under tilsyn, og afsnit 6.b om dokumentation af tekniske test.

Senest gennemgået: oktober 2026.