Når kravet er uklart: send kunden en plan for testen

Et krav som “leverandøren skal løbende teste sin sikkerhed i overensstemmelse med NIS2” kan læses på mange måder, og spørgsmål tilbage til kunden giver ikke altid et klarere svar. Svaret hviler på at vende rollerne: i stedet for at vente på, at kunden præciserer, sender I selv et konkret forslag til testen, som kunden kan godkende, rette eller afvise. Et forslag på et par sider er lettere for kunden at tage stilling til end et åbent spørgsmål.

Planen bliver samtidig jeres dokumentation for, hvad I og kunden er enige om. Når testen senere er gennemført, kan resultatet holdes op mod den.

Hvorfor en plan virker bedre end spørgsmål

Nogle kunder sender samme kravbilag til alle leverandører. Den, der har skrevet det, er ikke nødvendigvis den, der svarer på spørgsmål, og indkøb kan have svært ved at sige, hvad sikkerhedsfunktionen forventer. Et åbent spørgsmål om, hvad kravet betyder, ender derfor let i en ny henvisning til loven.

Et konkret forslag giver kunden noget at forholde sig til. Kunden kan vise det til sin sikkerhedsansvarlige, få et ja eller nej og sende det tilbage. Det tager kortere tid og giver et tydeligere resultat end en række mails om fortolkning. Hvis I først vil skille kundens brev ad i test, politik og hændelser, så gør det før planen skrives. → Kundens brev om NIS2

Det, planen skal rumme

Hold planen kort og konkret. Disse punkter dækker meget af det, et krav kan rumme:

Kundens krav · citér den præcise formulering, planen svarer på.
Leverancen · hvilke dele kunden bruger, og som testen skal omfatte.
Uden for omfang · hvad der ikke testes, og hvorfor.
Testtype · penetrationstest, sårbarhedsscanning eller en kombination.
Tidspunkt · hvornår testen gennemføres, og hvornår resultatet foreligger.
Testleverandør · hvem der udfører testen, og hvordan uafhængigheden er sikret.
Dokumentation · hvad kunden får, fx et resumé med omfang, tidspunkt og resultat.
Fund · hvordan kunden får besked om alvorlige fund, og hvornår status på rettelser sendes.
Næste gang · hvornår og ved hvilke ændringer testen gentages.

Hvert punkt kan være en eller to sætninger. Det er præcisionen, ikke længden, der gør planen brugbar. → Fra effektivitetskrav til testplan

Byg planen på kundens egne rammer

Planen bliver lettere at godkende, når den bruger de begreber, kunden selv arbejder med. Gennemførelsesforordning 2024/2690 gælder kun bestemte digitale udbydere, men bilagets pkt. 6.5.2 beskriver en opbygning, NIS2-kunder kan genkende: behov, omfang, hyppighed og type fastlægges ud fra en risikovurdering, testen følger en dokumenteret metode, og type, omfang, tidspunkt og resultater dokumenteres med en vurdering af hvert fund. Styrelsen for Samfundssikkerheds vejledning om foranstaltninger beskriver tekniske test på samme måde i afsnit 6.b.

Når jeres plan følger den opbygning, kan kunden lægge den direkte ind i sin egen dokumentation af leverandørstyringen. → Fire oplysninger om testen

Skriv også, hvorfor omfanget er valgt, som det er. En kort begrundelse, fx at kunden kun bruger kundeportalen og jeres supportadgang, gør det lettere for kunden at forsvare afgrænsningen over for sin egen ledelse eller sit tilsyn. → Hvilke systemer forventer NIS2-kunden testet?

Hyppigheden: undgå et tal uden begrundelse

Et uklart krav kan nævne løbende eller regelmæssig test uden at sige, hvad det betyder. Det er fristende at skrive en gang om året, fordi det lyder rimeligt, men hverken NIS 2-loven eller forordningen fastsætter et bestemt interval. Forordningens bilag lægger hyppigheden ind under risikovurderingen.

Foreslå i stedet en hyppighed, der hænger sammen med leverancen: en fast test med et interval, I kan begrunde, og en ekstra test, når der sker væsentlige ændringer i det, kunden bruger. Skriv, hvad I forstår ved en væsentlig ændring, så kunden kan sige til, hvis forståelsen er en anden. → Testfrekvens efter risiko

Få planen godkendt

En plan, kunden ikke har svaret på, er kun jeres egen fortolkning. Bed om en skriftlig accept, og gør det let at give den: en mail med et klart spørgsmål om, kunden kan godkende planen, eller hvilke punkter der skal ændres.

Hvis kunden ikke svarer, så skriv en kort bekræftelse af, at I gennemfører testen som beskrevet, medmindre I hører andet inden en bestemt dato. Det er ikke det samme som en godkendelse, men det viser, at I har forsøgt at afstemme kravet. Gem planen og korrespondancen sammen med aftalen.

Bruger kunden en fast skabelon for leverandørers dokumentation, så tilpas planen, så den passer ind i den. Det sparer kunden for at oversætte jeres forslag. → Kundens skabelon

Når kunden ændrer planen

Kunden kan svare med ændringer, der gør testen bredere, end I forventede. Tag dem seriøst, men spørg til begrundelsen, hvis de rækker ud over leverancen. Et ønske om at få testet hele kontornettet kan have en god grund, fx at supportteknikerne arbejder derfra, men det kan også være en standardformulering, som kunden gerne giver slip på.

Opdatér planen, så den afspejler det, I er enige om, og send den endelige version. Det er den version, testleverandøren skal have, og den, testens resultat senere skal holdes op mod. Giv versionen en dato og et nummer, så der ikke opstår tvivl om, hvilken plan der gælder, hvis kunden vender tilbage med flere ændringer, efter at testen er bestilt. Ændringer, der kommer så sent, kan betyde et nyt tidspunkt eller en ekstra udgift, og det er lettere at tale om, når begge parter kan se, hvad der oprindelig blev aftalt.

Det skal I lade være med

At vente på, at kunden præciserer · et konkret forslag giver hurtigere et klart svar.
At skrive en plan uden kundens ordlyd · planen skal vise, hvilket krav den svarer på.
At vælge et interval uden begrundelse · knyt hyppigheden til risiko og ændringer.
At gå i gang uden svar fra kunden · bed om accept, eller send en bekræftelse med frist.
At glemme at sende den endelige version · både kunde og testleverandør skal arbejde ud fra samme plan.

Hvad kan og ikke kan konkluderes

En godkendt plan viser, at I og kunden er enige om, hvad testen skal omfatte, og hvad kunden får. Den gør det lettere at vise, at kravet er opfyldt efter den fælles forståelse. Den kan ikke garantere, at kundens tilsyn eller en senere kontaktperson hos kunden læser kravet på samme måde, og den siger intet om testens resultat. Teksten er ikke juridisk rådgivning.