MSP’ens kunder kræver hver deres test: en fælles plan

En driftsleverandør med tyve kunder kan få tyve forskellige krav om sikkerhedstest, med hver sin frist, sin skabelon og sit syn på, hvad der skal med. Svaret er en fælles testplan, der skelner mellem det, alle kunder deler, og det, der kun hører til den enkelte. Planen hviler på det, kunderne selv skal kunne vise: at testens behov, omfang, hyppighed og type er fastlagt ud fra en risikovurdering, som gennemførelsesforordning (EU) 2024/2690 beskriver det i bilagets punkt 6.5.2, litra a.

Med en plan kan I svare alle kunder ud fra det samme grundlag i stedet for at bestille en ny test, hver gang et skema lander. Teksten er ikke juridisk rådgivning.

To lag i en MSP-leverance

En leverance fra en driftsleverandør kan deles i to lag, og testplanen skal holde dem adskilt.

Det fælles lag · systemer, I bruger til at drive alle kunder: fjernadministration, overvågning, backupplatform, jeres egen identitetsløsning, dokumentationssystem og eventuel hosting.
Kundens lag · det, I drifter hos eller for den enkelte kunde: kundens servere, netværk, Microsoft 365-lejer og forbindelserne mellem kunden og jer.

Det fælles lag er det, hver kunde reelt er afhængig af, men som ingen kunde ejer. Det er også der, en svaghed kan ramme alle på én gang.

Grænsen mellem lagene er ikke altid skarp. En forbindelse fra jeres overvågning ind i kundens netværk hører til begge lag: den udgår fra det fælles, men den åbner ind til kunden. Beslut, hvor sådanne forbindelser placeres i planen, og skriv begrundelsen ned, så kunden kan se, at de ikke er faldet mellem to stole. → Delte platforme hos MSP’en

Saml kravene, før I planlægger

Lav en oversigt over kundernes krav med fire kolonner i hovedet: hvad kunden kræver testet, hvornår kunden skal have dokumentation, i hvilken form, og hvilke regler kunden henviser til. Oversigten viser, om flere krav i virkeligheden peger på det samme fælles lag, og om forskellene mest ligger i frister og form. Den viser også de krav, der ikke kan dækkes af en fælles test, fordi de handler om noget, kun én kunde har.

Kunder, der selv er omfattet af NIS 2-loven, bygger kravet på lovens § 6, stk. 1, nr. 4, om forsyningskædesikkerhed. Nogle henviser også til forordningens formuleringer, selv om forordningen kun gælder bestemte digitale udbydere. Er I selv udbyder af administrerede tjenester, kan forordningen gælde jer direkte, og så er planen ikke kun et svar til kunderne, men også jeres egen pligt. → Forordningen og MSP’en

Hvad planen skal indeholde

En fælles testplan behøver ikke være lang. Den skal kunne vises til en kunde og forstås uden forklaring.

Komponenterne i det fælles lag · hvilke systemer der testes, og hvorfor de er valgt.
Rytmen · hvornår det fælles lag testes, begrundet i jeres risikovurdering og ikke i den første kundes frist.
Udløsere · hvilke ændringer der giver en ekstra test, fx et nyt administrationsværktøj eller en flytning af platformen. → Test ved idriftsættelse
Kundespecifikke tillæg · hvordan og hvornår kundens eget lag testes, og hvem der bestiller det.
Dokumentation · hvilken form hver kunde får, og hvordan andre kunders oplysninger holdes ude.

Planen bør også have en ejer hos jer og en dato for næste gennemgang. Forordningens punkt 6.5.3 nævner, at politikker for sikkerhedstest gennemgås med planlagte mellemrum.

Hvem tester kundens eget lag?

Kundens lag kan testes på tre måder, og planen bør sige, hvilken der gælder for hvem. Kunden kan bestille sin egen test, hvor I deltager som driftsleverandør. I kan bestille testen som en del af aftalen med kunden. Eller kundens lag kan indgå som et tillæg til jeres fælles test, hvis kunden ønsker det.

Valget afhænger af serviceaftalen. Står der intet om test, bliver det et spørgsmål ved hver eneste forespørgsel, og det er netop det, planen skal undgå. → Test i serviceaftalen

Testområderne i kundernes miljøer, fx Active Directory, Microsoft 365 og intern netværkstest, er beskrevet fra IT-afdelingens side på penetration-test.dk (https://penetration-test.dk/).

Når en kunde vil noget andet

Planen dækker ikke alle ønsker. En kunde kan kræve en bestemt tester, en test inden en bestemt dato eller adgang til at teste jeres fælles systemer selv. Så har I tre muligheder: at tilbyde kunden resultatet af den seneste fælles test med en forklaring, at fremrykke en del af planen, eller at aftale en særskilt test for kunden.

Den sidste mulighed rører ved de andre kunder, fordi en test af det fælles lag også er en test af deres drift. Vælg den kun, når de to første ikke kan dække kundens behov, og skriv i planen, hvordan I så varsler de øvrige kunder. → Når kunden vil teste MSP’ens systemer

Et tænkt eksempel

En driftsleverandør har tre kunder under NIS 2-loven: en kommune, en fødevareproducent og en virksomhed inden for affaldshåndtering. Kommunen vil have dokumentation i marts, fødevareproducenten i juni og affaldsvirksomheden til et årligt leverandørmøde i september. Leverandøren lægger testen af det fælles lag i februar og giver alle tre et resumé. Fødevareproducenten har desuden en særlig forbindelse til sit produktionsnet, som testes som tillæg i maj. Affaldsvirksomheden får i september resuméet fra februar sammen med status på rettelserne, så kunden kan se, at fundene er fulgt op.

Det skal I lade være med

At lade den første kundes frist styre rytmen · rytmen skal begrundes i jeres egen risikovurdering.
At teste det fælles lag igen for hver kunde · det giver flere test af det samme og flere forstyrrelser i driften.
At blande kundernes resultater · hver kunde skal kun se sit eget og det fælles.
At glemme ændringer · et nyt værktøj i det fælles lag kan gøre den seneste test forældet.
At love en test, planen ikke rummer · aftal tillæg skriftligt.

Hvad kan og ikke kan konkluderes

En fælles plan kan vise kunderne, at det fælles lag testes efter en begrundet rytme, og at kundespecifikke dele har en aftalt plads. Den kan ikke i sig selv dokumentere, at testene er gennemført, eller hvad de fandt. Det kræver rapporter og status på rettelser. Om planen opfylder den enkelte kundes krav, vurderer kunden ud fra aftalen.