Kunden vil selv teste jeres løsning: hvad skal I aftale først?

Nogle NIS2-kunder nøjes ikke med jeres dokumentation. De vil have deres egen tester til at undersøge den løsning, de bruger. Det er forståeligt, for kunden skal selv kunne stå inde for vurderingen af sine leverandører. Men en test af jeres systemer, bestilt af en anden end jer, kræver aftaler, som ingen af parterne bør springe over.

Svaret er en skriftlig aftale før første testdag. Den skal sige, hvem der giver tilladelse, hvad der må testes, hvornår, hvordan andre kunder beskyttes, og hvordan fund deles. Uden den aftale risikerer I driftsforstyrrelser, uklare fund og en rapport om jeres løsning, som I ikke selv har adgang til.

Hvor kravet kommer fra

Kundens ønske kan hænge sammen med en klausul om ret til revision. Gennemførelsesforordning 2024/2690 nævner i bilagets punkt 5.1.4, litra e, retten til revision eller retten til at modtage revisionsrapporter som noget, kontrakter med leverandører kan indeholde. SAMSIK’s vejledning om foranstaltninger har en tilsvarende formulering i afsnit 4.

Bemærk ordet “eller”. Kunden kan få sit behov dækket ved at modtage jeres egen dokumentation, og en test ved kundens tester er kun én mulighed. Hvis I allerede har en nylig test af den samme del, er det rimeligt at tilbyde den først. → Ret til revision

Ønsker kunden alligevel selv at teste, er det ikke nødvendigvis et tegn på mistillid. Kunden kan have et testprogram, hvor alle kritiske leverandører indgår på samme måde.

Hvem giver tilladelsen?

En test må kun ske med tilladelse fra den, der ejer eller har rådighed over systemet. Det er jer, der ejer jeres løsning, ikke kunden. Kundens tester skal derfor have en skriftlig tilladelse fra jer, ikke kun fra kunden.

Kører løsningen hos en hostingpartner eller i en cloudplatform, kan partneren have egne vilkår for test. Undersøg dem, før I giver tilladelsen, og få partnerens accept, hvis det kræves. → Leverance hos en hostingpartner

Indgår der komponenter, I ikke selv ejer, for eksempel en betalingsløsning eller et loginmodul fra en anden leverandør, skal de enten holdes uden for testen eller have deres egen tilladelse. → Når kunden vil teste noget, I ikke ejer

Afgrænsning og tidspunkt

Skriv ned, hvad kundens tester må undersøge. Det kan være den del af løsningen, kunden selv bruger, med de roller, kundens medarbejdere har. Adresser, funktioner og testkonti skal stå i aftalen, og det samme skal det, der ligger udenfor.

Aftal også tidsrummet. En test i kundens arbejdstid kan påvirke kundens egne brugere. En test om natten kan falde sammen med jeres vedligeholdelse. Vælg et vindue, hvor I har folk klar, hvis noget går galt. → Afgrænsning mod kundens miljø

Kontaktpersoner · én hos jer og én hos testeren, som kan nås under hele testen.
Stop · hvem der kan stoppe testen, og hvordan det meldes.
Testkonti · hvem der opretter dem, og hvornår de lukkes igen.
Testdata · at der ikke bruges rigtige personoplysninger, hvor det kan undgås.

Hensyn til jeres andre kunder

Kører flere kunder på samme platform, er det den største risiko ved kundens egen test. En test, der belaster systemet eller ændrer data, rammer måske ikke kun den kunde, der bestilte den. Kundens tester må heller ikke få adgang til andre kunders oplysninger, selv ved et uheld.

Aftal derfor, at testen holdes inden for kundens egen del, og at testeren straks stopper og giver besked, hvis andre kunders data bliver synlige. Et sådant fund er vigtigt for jer at kende, men det skal ikke dokumenteres med andre kunders data. → Delte platforme hos MSP’en

Et tænkt eksempel: En leverandør af et journalsystem til private klinikker har en klinikkæde som NIS2-kunde, der vil lade teste. Platformen deles med mange andre klinikker. Aftalen begrænser testen til kædens egne konti, udelukker belastningstest og kræver besked med det samme ved tegn på adgang til andre klinikkers data.

Fund og rapport

Fund i jeres løsning er jeres at rette. I skal derfor have dem, og helst løbende, hvis noget er alvorligt. Aftal, at kritiske fund meldes til jer under testen, og at I får rapporten eller den del, der handler om jeres løsning.

Aftal også, hvordan kunden opbevarer rapporten, og hvem kunden må dele den med. En rapport om svagheder i jeres løsning er følsom, også hos kunden. Afklar desuden, om I må kommentere fund, før rapporten er endelig, så faktuelle fejl kan rettes. → Kundens test finder fejl

Hvordan en softwareleverandør mere generelt håndterer kunders egne test, er beskrevet på pentestrapport.dk.

Når testen er slut

Aftalen bør også sige, hvad der sker bagefter. Testkonti skal lukkes, og eventuelle data eller filer, testeren har lagt ind i løsningen, skal fjernes. Bed testeren om en liste over det, der er oprettet, så I kan kontrollere oprydningen.

Kunden kan ønske at følge op på de fund, der kom frem. Aftal, hvordan I melder status på rettelserne tilbage, og om kundens tester skal efterprøve dem, eller om jeres egen dokumentation er nok. Det er lettere at aftale, mens begge parter er enige om, at testen var en god idé, end når fristen for en rettelse nærmer sig.

Gem aftalen, tilladelsen og kundens rapport sammen. Næste gang kunden eller en anden kunde vil teste, har I et udgangspunkt, der allerede har været brugt.

Det skal I lade være med

At lade kundens tilladelse stå alene · det er jer, der ejer systemet og skal give lov.
At glemme hostingpartneren · platformens vilkår kan stille krav til test.
At lade testen ramme andre kunder · afgræns til kundens egen del og aftal stop.
At acceptere, at I ikke får fundene · uden dem kan I ikke rette noget.
At afvise uden alternativ · tilbyd jeres egen dokumentation, hvis den dækker behovet.

Hvad kan og ikke kan konkluderes

En test bestilt af kunden kan give kunden sin egen vurdering af den del af løsningen, kunden bruger. Med en god aftale kan den også give jer fund, I ellers ikke havde fået.

Den siger intet om dele af løsningen, der lå uden for afgrænsningen, og den viser kun tilstanden på testtidspunktet. Om aftalen giver kunden ret til at teste, afhænger af ordlyden. Teksten er ikke juridisk rådgivning.