Kundens brev om NIS2: sådan deler I kravene op

Et NIS2-brev fra en kunde er ikke nødvendigvis ét krav. Det kan være en pakke, hvor sikkerhedstest står side om side med krav om politikker, besked om hændelser, ret til revision og regler for underleverandører. Hvis det hele ender på testerens bord, får I en rapport, der svarer på for meget og for lidt på samme tid.

Løsningen er at dele brevet op, før noget bestilles. Hvert krav får en ejer hos jer og et svar i den form, der passer til kravet. Penetrationstesten dækker kun de punkter, hvor kunden beder om at få noget teknisk afprøvet, og alle andre punkter besvares for sig.

Hvorfor brevene ligner hinanden

Kundebreve kan følge den samme skabelon, og det er ikke tilfældigt. SAMSIK’s vejledning om foranstaltninger nævner i afsnit 4 om forsyningskædesikkerhed en række emner, som aftaler med leverandører eksempelvis kan indeholde. Gennemførelsesforordning 2024/2690 har i bilagets punkt 5.1.4 en lignende liste for de digitale udbydere, den gælder for.

Listerne omfatter blandt andet sikkerhedskrav til leverandøren, krav til personalets kompetencer, besked om hændelser, ret til revision eller revisionsrapporter, håndtering af sårbarheder, regler for underleverandører og forhold ved aftalens ophør. Ser jeres brev sådan ud, er det et tegn på, at kunden har brugt en af disse lister som udgangspunkt.

Fem bunker

Gå brevet igennem punkt for punkt, og læg hvert krav i en af fem bunker. Nogle punkter hører til i flere, men hvert punkt kan få en hovedbunke.

Teknisk afprøvning · krav om penetrationstest, sårbarhedsscanning eller anden test af en bestemt del af leverancen.
Politik og styring · krav om informationssikkerhedspolitik, risikovurdering, uddannelse og roller.
Hændelser · krav om at give kunden besked om hændelser og bistå kunden med kundens egen rapportering.
Revision og kontrol · kundens ret til at revidere jer eller få revisionsrapporter.
Kæden · krav til jeres egne underleverandører, sårbarhedshåndtering og ophør.

Kun den første bunke er testens opgave. Den femte kan få betydning for testen, fordi kravet om at håndtere sårbarheder kan forudsætte, at I opdager dem. → Pligt til at håndtere sårbarheder

Testbunken: gør kravet konkret

Når testkravene er samlet, skal de oversættes til noget, en tester kan arbejde ud fra. Spørg, hvilket system eller hvilken adgang kravet gælder, hvilken type test kunden forventer, og hvilken dokumentation kunden skal have. Hvis brevet blot siger “regelmæssig sikkerhedstest”, er det jeres opgave at foreslå en fortolkning, som kunden kan godkende.

Et tænkt eksempel: En leverandør af adgangskontrol til en fødevarevirksomhed får et brev med tolv punkter. To af dem handler om test: en årlig penetrationstest af den webløsning, kunden administrerer adgangskort i, og dokumentation for, at fjernsupporten er sikret. Resten handler om politik, hændelser og kontrakt. Testplanen skal kun rumme de to punkter. → Fra effektivitetskrav til testplan

De andre bunker kræver andre svar

En penetrationstest kan ikke vise, at I har en politik for informationssikkerhed, at medarbejderne er uddannet, eller at I vil give besked inden for en bestemt frist. De krav besvares med dokumenter, procedurer og aftaletekst. Hvem der ejer dem hos jer, er en styringsopgave, som ligger uden for testens felt.

Kravet om besked om hændelser hænger sammen med kundens egne frister over for myndigheden. Kunden kan have brug for jer hurtigt, hvis noget sker. → Besked til kunden om hændelser

Retten til revision er en særlig bunke, fordi den kan føre til, at kunden eller en revisor senere vil se nærmere på jeres systemer. Det er ikke det samme som et krav om penetrationstest, men de to kan mødes. → Ret til revision

Krav til jeres egne underleverandører kan betyde, at I skal bede jeres hostingpartner eller udviklingspartner om dokumentation. → Krav til egne underleverandører

Når et punkt hører til flere steder

Nogle krav kan ikke lægges i én bunke. Et krav om “sikker fjernadgang” kan både handle om, at I har en procedure for, hvem der får adgang, og om, at adgangen faktisk er sikret i praksis. Proceduren besvares med et dokument. Om den virker, kan en test belyse.

Del sådanne punkter i to. Skriv i svaret, hvilken del der dækkes af jeres procedure, og hvilken del testen skal sige noget om. Så undgår I, at testen bliver gjort ansvarlig for at bevise en politik, og at politikken bliver brugt som bevis for, at noget er afprøvet.

Kravet om sårbarhedshåndtering er et andet eksempel. Det kræver en proces for at modtage, vurdere og rette sårbarheder. En test kan bidrage med fund og vise, om tidligere fund er rettet, men selve processen skal I beskrive. → Status på rettelser

Svar samlet, men hold svarene adskilt

Kunden ønsker ét samlet svar. Det kan godt være en enkelt mail eller et enkelt dokument, så længe hvert punkt får sit eget svar. Henvis til testen der, hvor testen er svaret, og til politikken eller aftaleteksten, hvor de er svaret.

Hold også øje med punkter, I ikke kan opfylde, eller som ikke passer til jeres leverance. Det er bedre at skrive det tydeligt og foreslå et alternativ end at lade punktet stå ubesvaret. Er kravet uklart, så send kunden en plan for testdelen. → Send kunden en plan

Det skal I lade være med

At sende hele brevet til testeren · testeren skal kun have de punkter, der handler om teknisk afprøvning.
At henvise til rapporten som svar på alt · en testrapport viser ikke en politik eller en beredskabsplan.
At overse kæden · krav til underleverandører kan kræve dokumentation fra andre end jer.
At svare med et samlet ja · hvert punkt har sin egen betydning, også juridisk.
At glemme ejeren · et punkt uden ansvarlig hos jer bliver ikke besvaret.

Hvad kan og ikke kan konkluderes

Opdelingen gør det muligt at bestille en test, der rammer kundens tekniske spørgsmål, og at besvare resten med det rette materiale. Den afgør ikke, om jeres samlede svar er tilstrækkeligt. Det vurderer kunden ud fra sin egen risikovurdering.

Testen kan dokumentere, at de udvalgte dele af leverancen er afprøvet. Den kan ikke dokumentere, at jeres organisation lever op til de øvrige punkter i brevet. Teksten er ikke juridisk rådgivning, og bindende formuleringer i aftalen bør vurderes af den, der normalt varetager jeres kontrakter.