Kunden kræver ny test efter væsentlige ændringer: hvad tæller som væsentligt?

En leverandøraftale med en NIS2-kunde kan sige, at leverancen skal testes igen efter væsentlige ændringer, uden at nogen af parterne har skrevet ned, hvad ordet dækker. Svaret hviler på to ting: kilderne bag kravet knytter test til ændringer, uden at definere dem for jeres leverance, og det er derfor op til jer og kunden at aftale en definition, der passer. Uden den bliver hver ny version et spørgsmål om fortolkning.

En brugbar definition tager udgangspunkt i det, kunden er afhængig af. En ændring er væsentlig for kunden, når den berører kundens data, kundens adgang eller den forbindelse, der går mellem jer og kunden.

Hvor kravet kommer fra

Styrelsen for Samfundssikkerheds vejledning om foranstaltninger skriver i afsnit 6.b, at systemer bør sikkerhedstestes ved installation, vedligeholdelse og ved opgradering eller ændringer af infrastruktur og applikationer, som enheden vurderer som væsentlige. ENISA’s tekniske vejledning til gennemførelsesforordning 2024/2690, pkt. 6.5, peger på test ved opsætning, efter væsentlige opgraderinger eller ændringer og efter vedligehold.

Forordningens bilag, pkt. 5.1.6, siger desuden, at de enheder, den gælder for, skal følge op på ændringer i leverandørernes cybersikkerhedspraksis med planlagte mellemrum og ved væsentlige ændringer. Kildernes ordlyd handler altså om kundens egne systemer og kundens opfølgning, og det er kunden, der vurderer, hvad der er væsentligt for kunden. Kravet til jer er kundens måde at omsætte det til aftalen. → Test ved idriftsættelse

Ændringer, der kan berøre kunden

Sæt jer i kundens sted og spørg, hvad der ændrer kundens risiko. Ændringer af denne slags kan være væsentlige set fra kunden:

Adgangsvejen ind til kunden · en ny måde for jeres teknikere at komme ind i kundens systemer, eller nye konti med flere rettigheder.
Kundens data · data flyttes til et nyt sted, nye typer oplysninger behandles, eller flere hos jer får adgang.
Integrationen · en ny eller ombygget forbindelse til kundens systemer. → Integrationer og dataudveksling med kundens systemer
Login og roller · en ny måde for kundens medarbejdere at logge ind på, eller en ny rollemodel.
Driftsmiljøet · flytning til en anden hostingpartner eller cloudplatform. → Leverancen kører hos en hostingpartner
Komponenter, testen byggede på · en central del af løsningen er skiftet ud.

Rettelser af kendte fejl, nye tekster og ændringer i dele, kunden ikke bruger, vil som udgangspunkt ikke være væsentlige for netop denne kunde. Det er grunden til at definere begrebet ud fra kundens brug og ikke ud fra versionsnumre.

Skriv definitionen ind

En definition kan være kort. Den behøver ikke at liste alle tænkelige ændringer, men den skal give begge parter et fælles udgangspunkt:

Kategorier · de typer ændringer, der altid udløser en vurdering, fx dem ovenfor.
Besked · at I giver kunden besked, før en ændring i en af kategorierne sættes i drift.
Vurdering · hvem der vurderer, om en ny test er nødvendig, og hvordan uenighed håndteres.
Omfang · at en ny test kan afgrænses til det ændrede, med den seneste rapport som baggrund.
Tidspunkt · om testen skal ligge før idriftsættelsen eller inden for en aftalt periode efter.

Teksten er ikke juridisk rådgivning, og selve formuleringen bør vurderes af den, der normalt håndterer jeres aftaler.

Gør det til en del af jeres ændringsstyring

Definitionen virker kun, hvis den bliver brugt. Knyt den til den måde, I i forvejen planlægger ændringer på. Når en ændring registreres, kan et enkelt spørgsmål være nok: berører den en af kategorierne i aftalen med en NIS2-kunde? Er svaret ja, sendes besked, og vurderingen dokumenteres.

Har I flere kunder med hver sin definition, så saml dem i en oversigt, så den, der planlægger ændringen, kan se, hvilke kunder der skal have besked. En ændring af den fælles platform kan være væsentlig for én kunde og ligegyldig for en anden.

Dokumentér også de gange, hvor I vurderer, at en ændring ikke kræver ny test. En kort note med begrundelse er værdifuld, hvis kunden senere spørger, hvorfor en bestemt version ikke blev testet. → Dokumentationen på et fast tidspunkt hvert år

Når kunden og I er uenige

Kunden kan mene, at en ændring er væsentlig, selv om I ikke gør. Husk, at kunden har sin egen risikovurdering og sit eget tilsyn at tage hensyn til. Spørg, hvilken del af ændringen kunden er bekymret for, og foreslå en test, der er afgrænset til netop den. Det kan være en mindre opgave end en fuld gentagelse.

Omvendt kan I selv have grund til at teste, selv om kunden ikke spørger. En stor ombygning af adgangen til kundernes systemer er værd at få afprøvet, uanset om aftalen kræver det. → Testfrekvens efter risiko

Ændringer, I ikke selv sætter i gang

Ikke alle væsentlige ændringer kommer fra jeres egen udvikling. En hostingpartner kan flytte jeres servere til et nyt datacenter, en platform kan ændre den måde, login fungerer på, eller en underleverandør kan få en ny rolle i driften. Set fra kunden er det stadig en ændring i leverancen.

Tag derfor også de ændringer med i definitionen, som jeres egne leverandører gennemfører, når de berører en af kategorierne. Det kræver, at I selv får besked fra dem i tide. Hvis jeres aftaler med underleverandørerne ikke sikrer det, er det et hul, I bør kende, før kunden spørger, hvorfor en flytning af driften ikke blev meldt. → Krav til egne underleverandører

Det skal I lade være med

At lade ordet væsentlig stå udefineret · aftal kategorier, før den første ændring kommer.
At bruge versionsnumre som målestok · en lille version kan ændre adgangen til kundens data.
At sætte ændringen i drift før beskeden · kunden skal kunne vurdere den på forhånd.
At gentage hele testen hver gang · afgræns den nye test til det, der er ændret.
At undlade at notere vurderingen · også en beslutning om ikke at teste skal kunne findes.

Hvad kan og ikke kan konkluderes

En aftalt definition gør det tydeligt, hvornår kunden kan forvente en ny test, og giver begge parter et fælles grundlag. Den kan ikke forudse alle ændringer, og den erstatter ikke kundens egen vurdering af, hvad der er væsentligt for kunden. En ny test efter en ændring dokumenterer det ændrede på et tidspunkt, ikke hele leverancen.