Når kunden afviser jeres dokumentation

Det er frustrerende at få testdokumentationen retur med besked om, at den ikke kan bruges. Men en afvisning fra en NIS2-kunde handler ikke nødvendigvis om, at testen var dårlig. Det kan være, at dokumentationen ikke passer til det, kunden skal bruge den til: den dækker ikke den del, kunden er afhængig af, den er for gammel, den har ikke den form, kunden skal bruge, eller den mangler opfølgning. Svaret hviler på at finde den præcise årsag, før I bestiller noget nyt.

En afvisning kan løses med et supplement frem for en ny test. Teksten er ikke juridisk rådgivning.

Bed om begrundelsen skriftligt

Det første skridt er at få kunden til at skrive, hvad der mangler. Et kort “den lever ikke op til vores krav” er ikke noget, I kan handle på. Spørg konkret: hvilket krav i aftalen eller i kundens leverandørpolitik er dokumentationen målt imod, og hvilken del af det er ikke opfyldt?

Kunden er selv bundet af sin egen leverandørstyring. En enhed omfattet af NIS 2-loven skal efter § 6, stk. 1, nr. 4, have foranstaltninger for forsyningskædesikkerhed, og bilaget til forordning (EU) 2024/2690 beskriver i punkt 5.1.6 og 5.1.7, hvordan en enhed overvåger leverandørerne og dokumenterer resultaterne. Forordningen gælder direkte for bestemte digitale udbydere, fx cloud og administrerede tjenester, men bruges som model af andre. Kundens afvisning kan altså have rod i kundens egen dokumentationspligt, ikke i en vurdering af jer. → Sådan læser I kundens NIS2-krav

Fire mulige årsager

En afvisning kan falde i én af fire grupper:

Omfang · testen dækkede ikke den del af leverancen, kunden bruger, fx supportadgangen eller integrationen til kundens systemer.
Alder · testen ligger før en væsentlig ændring i leverancen, og kunden kan ikke se, om resultatet stadig gælder.
Form · kunden skal bruge oplysninger, der ikke står i dokumentet, eller skal have dem i sin egen skabelon.
Opfølgning · fundene står uden status, så kunden ikke kan se, om de er håndteret.

En femte gruppe er tvivl om, hvem der testede, og hvor uafhængig testeren var. Den kan løses med en kort oplysningsblok om testleverandøren. → Oplysninger om testleverandøren

Omfanget passer ikke

Hvis kunden peger på en del af leverancen, der ikke var med, er der tre muligheder. Delen kan have været med under et andet navn, så det er et spørgsmål om at forklare afgrænsningen bedre. Den kan være afprøvet på anden vis, fx gennem en konfigurationsgennemgang, som I kan dokumentere særskilt. Eller den har ikke været testet, og så må I tage stilling til, om den skal med i næste test, eller om der skal en afgrænset test nu.

Skriv svaret, så kunden kan se, at afgrænsningen var et valg og ikke en forglemmelse. Brug gerne kundens egne ord for delene af leverancen. → Hvilke systemer kunden forventer testet

Resultatet er for gammelt

Hverken NIS 2-loven eller forordningen fastsætter, hvor gammel en testrapport må være. Punkt 5.1.6 knytter kundens opfølgning til planlagte mellemrum og til væsentlige ændringer i drift eller risici. Har I ændret noget væsentligt i leverancen siden testen, er det rimeligt, at kunden spørger, om resultatet stadig gælder.

Svaret kan være en kort redegørelse for, hvad der er ændret, og om ændringen berører de testede dele. Er der ændret i noget, testen dækkede, kan en afgrænset test af netop den del være nok. → Væsentlig ændring og kundens krav

Formen eller opfølgningen halter

Nogle kunder skal bruge testresultatet i et bestemt format, fordi det skal ind i et leverandørregister eller en fast rapport til ledelsen. Andre afviser en fuld rapport, fordi de ikke må eller vil opbevare den. Her er løsningen ikke nødvendigvis en ny test, men et andet dokument: et resumé, en udfyldt skabelon eller en erklæring fra testleverandøren.

SAMSIK skriver i sin vejledning om anvendelsesområdet, afsnit 8, at en NIS2-kunde ikke skal kræve fx en særlig certificering eller revisionserklæring af sine leverandører. Står et bestemt format i jeres aftale, er det dog aftalen, der gælder mellem jer. → Kundens skabelon

Mangler opfølgningen, er det et andet problem. En fundliste uden status kan kunden ikke bruge. Forordningens punkt 6.5.2, litra c, nævner en vurdering af afbødende foranstaltninger for hver konstatering, og SAMSIK’s vejledning om foranstaltninger, afsnit 6.b, taler om, at restrisiko skal accepteres af risikoejere. Kunden leder efter netop det: hvad der er gjort ved hvert fund, og hvem der har besluttet det.

Send en statusliste, og bed kunden vurdere dokumentationen igen sammen med den. Er nogle fund accepteret frem for rettet, så skriv begrundelsen, og skriv, hvem hos jer der har truffet beslutningen. Det er den oplysning, kunden skal bruge, hvis kundens egen ledelse eller en myndighed senere spørger, hvorfor et kendt fund stadig står åbent. → Status på rettelser

Et tænkt eksempel

En leverandør af et system til tidsregistrering får sin testdokumentation afvist af en kommune. Begrundelsen er kort: dokumentationen er ikke tilstrækkelig.

Leverandøren beder om en skriftlig uddybning. Det viser sig, at kommunen savner to ting: om den fjernadgang, leverandørens support bruger til kommunens installation, var med i testen, og hvad der er sket med de tre middelalvorlige fund. Fjernadgangen var med, men hed noget andet i rapporten. Leverandøren sender et supplement, der forklarer afgrænsningen med kommunens egne betegnelser, og en statusliste. Kommunen godkender dokumentationen uden en ny test.

Det skal I lade være med

At bestille en ny test, før årsagen er kendt · det løser ikke nødvendigvis problemet, hvis det er formen eller opfølgningen.
At sende den samme dokumentation igen med en længere forklaring · svar på det, kunden konkret mangler.
At diskutere, om kunden har ret til at stille kravet · tag først stilling til, hvad aftalen siger.
At love dækning, testen ikke gav · et supplement må kun beskrive det, der faktisk blev afprøvet.
At glemme at notere årsagen · næste års dokumentation kan undgå samme afvisning.

Hvad kan og ikke kan konkluderes

En afvisning siger noget om, hvad kunden skal bruge, ikke nødvendigvis noget om testens kvalitet. Når årsagen er fundet, kan I løse den med et supplement, en statusliste eller en afgrænset test. Hvis I og kunden er uenige om, hvad aftalen kræver, er det et aftalespørgsmål og ikke et testspørgsmål. → Uenighed med kunden