MSP’en som mellemled: når kravet skal videre til platforme og licenser

En driftsleverandør sidder midt i en kæde. Kunden stiller krav om sikkerhedstest og dokumentation til jer, men en del af det, I leverer, er bygget på andres platforme: cloud, licensbaserede programmer, backuptjenester og værktøjer til fjernadministration. Svaret på, hvordan kravet kommer videre, hviler på én skelnen: det, I selv ejer og kan teste, og det, I kun kan dokumentere med andres papirer. Kundens krav til jer kan ikke række længere, end I selv kan få nedefra.

Den skelnen skal være synlig, før I underskriver, og ikke først, når kunden beder om dokumentationen. Teksten er ikke juridisk rådgivning.

Hvor kravet kommer fra

NIS2-direktivets artikel 21, stk. 2, litra d, og NIS 2-lovens § 6, stk. 1, nr. 4, handler om forsyningskædesikkerhed og om forholdet til enhedens direkte leverandører og tjenesteudbydere. Kunden ser altså primært på jer. Men gennemførelsesforordning (EU) 2024/2690, som gælder bestemte digitale udbydere, nævner i bilagets punkt 5.1.4, litra g, at kontrakter med leverandører, hvor det er relevant, angiver krav vedrørende underentreprise og cybersikkerhedskrav til underleverandører i overensstemmelse med kravene til leverandøren selv.

Kunder, der ikke er bundet af forordningen, kan låne formuleringen. For jer betyder den, at kunden kan bede jer om at sikre, at jeres underleverandører lever op til de samme krav, som I gør. → Krav til egne underleverandører

Kortlæg kæden fra jeres side

Før I svarer, så lav en oversigt over leverancen set nedefra. For hvert led noteres tre ting:

Hvem ejer det · jer selv, en platform, en licensgiver eller en anden driftsleverandør.
Hvad I må teste · alt, en del efter platformens regler, eller intet.
Hvilken dokumentation leddet giver · fx revisionserklæringer, certificeringer eller platformens egne rapporter.

Tag også de led med, der ikke er synlige for kunden: licensservere, opdateringstjenester fra producenter og de værktøjer, jeres teknikere bruger til at nå kunden. De er en del af leverancen, selv om de ikke står i kontrakten med kunden. Et led, der kan ændre noget hos kunden, hører med i oversigten.

Oversigten bliver jeres svar til kunden. Den viser, hvor jeres test dækker, hvor platformens dokumentation dækker, og hvor der er huller. → Hvem tester hvad i en lagdelt leverance

Store platforme forhandler ikke krav ind

En stor cloudplatform eller en softwareproducent med mange kunder arbejder med standardvilkår, offentliggjorte regler for test og en samling af dokumentation, som kunder kan hente. Regn ikke med, at den underskriver jeres kundes særlige kravbilag. Det, I kan få, er det, platformen stiller til rådighed for alle.

Microsoft beskriver for eksempel, at kunder må teste de Azure-ressourcer, de ejer, uden forhåndsgodkendelse, men skal følge platformens regler for test, og at en tredjepart kun må teste med skriftlig tilladelse fra ejeren af ressourcerne. AWS har sine egne regler. Reglerne bestemmer, hvad I kan lade teste. Dokumentationen af platformens egen del findes de steder, platformen selv anviser. → Cloududbyderens dokumentation og jeres egen test

For kunden betyder det, at et krav om “test af hele leverancen” i praksis bliver til jeres test af jeres del plus platformens dokumentation af dens del. Skriv det sådan i aftalen, så kunden ikke venter en rapport, I ikke kan skaffe.

Mindre underleverandører kan godt sige ja

Anderledes forholder det sig med mindre underleverandører: en lokal hostingpartner, et firma, der leverer jeres overvågning, eller en freelancekonsulent, der drifter et bestemt system. Med dem kan I aftale konkrete krav, fx at de lader deres del teste, giver jer et resumé og melder sårbarheder og hændelser til jer i tide til, at I kan melde videre til kunden.

Fristerne skal passe sammen. Har kunden en frist over for jer, skal underleverandørens frist over for jer være kortere. Det samme gælder formen: beder kunden om type, omfang, tidspunkt og resultater for hver test, så bed underleverandøren om de samme fire oplysninger, så I kan sætte dem direkte ind i jeres eget svar. → Krav i andet eller tredje led

Lov ikke mere opad, end I kan få nedefra

Den største risiko i et mellemled er en aftale med kunden, der lover noget, underleverandøren aldrig har lovet jer. Det kan være ret til at teste platformen, en frist for besked om sårbarheder eller en rapport i en bestemt form. Gennemgå kundens krav punkt for punkt, og marker for hvert punkt, om I selv kan opfylde det, om det afhænger af en underleverandør, og om underleverandøren har sagt ja.

Gør det også, når kravet ser harmløst ud. En frist på et bestemt antal timer for besked om sårbarheder lyder enkel, men hvis en del af leverancen kommer fra en producent, der selv bestemmer, hvornår den melder ud, kan I ikke holde fristen for den del.

Hvor kravet afhænger af en underleverandør, der ikke har sagt ja, er der to ærlige løsninger: at tage forbehold i aftalen med kunden eller at skaffe accepten, før I underskriver. → Grænser for leverandørkrav

Et tænkt eksempel

En driftsleverandør leverer drift af et sagssystem til en region. Systemet kører i en offentlig cloud, backup leveres af en specialiseret backuptjeneste, og overvågningen er købt hos en mindre leverandør. Regionen kræver årlig test af hele leverancen og ret til at modtage rapporterne.

Driftsleverandøren svarer med en oversigt i tre dele. Egen opsætning i cloud og egne administrationsadgange testes årligt efter platformens regler, og regionen får et resumé. Platformens del dokumenteres med de erklæringer, platformen stiller til rådighed, og regionen henvises til dem. Backuptjenesten og overvågningsleverandøren har skrevet under på at lade deres del teste og give et resumé, og fristerne er lagt, så de når frem før regionens frist.

Det skal I lade være med

At skrive kundens kravbilag videre ordret · en platform svarer ikke på det.
At love en test af noget, I ikke ejer · det kræver ejerens tilladelse.
At glemme fristerne nedad · jeres underleverandører skal være hurtigere end jer.
At skjule hullerne · kunden kan bedre leve med et kendt hul end et overraskende.
At gengive platformens dokumentation med egne ord · henvis til kilden.

Hvad kan og ikke kan konkluderes

En kortlægning af kæden kan vise kunden, hvem der tester og dokumenterer hvilken del, og hvor der er forbehold. Den kan ikke gøre platformens dokumentation til en test af jeres opsætning, og den kan ikke give kunden rettigheder over for en underleverandør, som underleverandøren ikke har givet. Hvad kunden kan acceptere, afgøres af kundens egen risikovurdering.