Når kunden vil teste MSP’ens systemer: hensyn til de andre kunder

En kunde, der er omfattet af NIS2, kan bede om at lade sin egen tester afprøve driftsleverandørens systemer. Ønsket er forståeligt, for kunden er afhængig af dem. Problemet er, at MSP’ens systemer ikke kun er kundens. Fjernadministration, overvågning, backup og identitetsløsning deles med andre kunder, og en test af dem er også en test af deres drift og deres data. Svaret hviler derfor på én skelnen: hvad der kun er kundens, og hvad der er fælles.

Det, der kun er kundens, kan kunden som udgangspunkt få lov at teste efter aftale. Det fælles kræver hensyn, som kunden ikke selv kan tage. Teksten er ikke juridisk rådgivning.

Hvorfor kunden spørger

Gennemførelsesforordning (EU) 2024/2690, som gælder bestemte digitale udbydere, nævner i bilagets punkt 5.1.4, litra e, retten til audit eller retten til at modtage auditrapporter som noget, der kan stå i kontrakter med leverandører. En kunde uden for forordningens kreds kan skrive det samme ind i sin aftale med jer. Ordet “eller” er vigtigt: kundens behov kan dækkes af jeres egen dokumentation, og en test ved kundens tester er én mulighed blandt flere. → Ret til revision

Det generelle forløb, når en kunde vil teste en leverandørs løsning, er beskrevet for sig. Her er fokus det særlige ved en MSP: de fælles systemer. → Kunden vil selv teste jeres løsning

Hvad der er kundens, og hvad der er fælles

Del systemerne op, før I svarer.

Kundens eget · kundens servere, netværk, lejer i Microsoft 365 og de konti, I bruger hos kunden. Her kan kundens tester arbejde efter aftale med jer.
Grænsefladen · forbindelsen fra jeres systemer ind til kunden, set fra kundens side. Kunden kan teste, hvad jeres adgang kan inde hos kunden.
Det fælles · administrationsværktøjer, overvågningsplatform, backupplatform, jeres egen identitetsløsning og de servere, alle kunder går igennem. Her er der andre kunder på den anden side.

Det fælles lag er netop det, en kunde har størst interesse i, og det, en kunde har mindst ret til at teste på egen hånd. → Delte platforme hos MSP’en

Hensynene til de andre kunder

En test af det fælles lag rører ved tre ting, der tilhører andre:

Andre kunders drift · en test, der belaster eller ændrer et fælles system, kan påvirke alle kunder.
Andre kunders data · finder testeren en vej ind i det fælles, kan andre kunders oplysninger blive synlige for en tester, de ikke har valgt.
Andre kunders aftaler · I kan have lovet andre kunder fortrolighed om deres forhold, og den gælder også over for en tredje kundes tester.

Ingen af de tre kan kunden give tilladelse til. Det er jer, der har ansvaret over for de andre kunder, og det er jer, der skal sige nej, hvis testen ikke kan holdes inden for rammerne. → Scope og fortrolighed

Alternativer til kundens egen test af det fælles

Et nej behøver ikke være slutningen. I kan tilbyde kunden noget, der dækker behovet:

Jeres egen test af det fælles lag · med et resumé til kunden og mulighed for at stille spørgsmål til testeren. → MSP’ens kunder kræver hver deres test
Kundens tester som observatør · kundens tester kan få indsigt i jeres test, uden selv at arbejde i de fælles systemer.
Test mod et separat miljø · hvis I har et testmiljø, der ligner produktionen, kan kundens tester arbejde dér.
Test fra kundens side · kundens tester afprøver, hvor langt jeres adgang rækker inde hos kunden, men går ikke videre ind i jeres systemer.

Hvilken løsning der passer, afhænger af kundens krav og af jeres aftale. Er I selv udbyder af administrerede tjenester og omfattet af NIS 2-loven, har I en egen pligt til at teste det fælles lag efter jeres risikovurdering. Så findes der allerede en test, kunden kan få indsigt i, og en ekstra test af de samme systemer ved en anden tester giver flere forstyrrelser uden nødvendigvis at give kunden mere viden. → MSP og NIS2

Uanset løsning bør kunden få et skriftligt svar på, hvorfor det fælles ikke testes af kundens tester, så kunden kan forklare det videre. Er kunden under tilsyn, er det kunden, der skal kunne vise sin myndighed, at leverandørrisikoen er håndteret. Det kan ske med jeres dokumentation.

Hvis I siger ja

Siger I ja til, at kundens tester arbejder i en del af det fælles, så aftal skriftligt:

Afgrænsningen · præcis hvilke systemer og konti testen må bruge.
Stopregler · testen stopper straks, hvis andre kunders data eller miljøer kan nås, og I får besked med det samme.
Tidspunkt · et vindue, hvor I har folk klar, og hvor de andre kunder er varslet, hvis deres drift kan påvirkes. → Testvindue hos MSP’en
Rapportens indhold · fund, der vedrører andre kunder, beskrives uden deres oplysninger og deles med jer.
Fortrolighed · kundens tester tavshedsforpligtes over for jer, ikke kun over for kunden.

Et fund i det fælles lag angår alle kunder. Aftal derfor også, at I må give de andre kunder besked om fundet. → Fund, der rammer flere kunder

Et tænkt eksempel

En driftsleverandør har en kommune og 25 private kunder. Kommunen vil lade sin egen tester afprøve leverandørens fjernadministration. Leverandøren foreslår, at kommunens tester tester kommunens eget miljø og den adgang, leverandøren har dér, og at kommunen får et resumé af leverandørens egen test af fjernadministrationen med mulighed for et møde med testeren. Kommunen accepterer og noterer i sit leverandørregister, hvilken dokumentation der dækker hvad.

Det skal I lade være med

At sige ja til en test af det fælles uden afgrænsning · andre kunder bærer risikoen.
At sige nej uden at tilbyde noget andet · kunden har stadig et behov.
At lade kundens tester se andre kunders data · heller ikke for at dokumentere et fund.
At glemme de andre kunders aftaler · fortrolighed over for dem gælder også her.
At holde fund i det fælles for jer selv · de angår alle.

Hvad kan og ikke kan konkluderes

En test, kunden selv lader udføre af sit eget miljø og af jeres adgang dertil, kan vise, hvor langt jeres adgang rækker hos kunden. Den kan ikke vise, hvordan jeres fælles systemer er sikret, medmindre de var med. Jeres egen test af det fælles kan vise det for de dele, der indgik. Om det samlede billede er nok, er kundens vurdering efter aftalen.