NIS2-pentest

Datacenter, cloud og MSP: hvem tester hvad i en lagdelt leverance?

Datacenter, cloud og MSP: hvem tester hvad i en lagdelt leverance?

En NIS2-kunde ser én leverance: et system, der virker. Bag den kan der ligge et datacenter, en cloudplatform, en driftsleverandør og en softwareleverandør, som hver ejer sit lag. Når kunden beder om dokumentation for test, er spørgsmålet ikke kun, hvad der skal testes, men hvem der må give lov. Svaret hviler på et enkelt princip: kun den, der ejer eller råder over et system, kan give tilladelse til at teste det. Kundens krav bygger på forsyningskædesikkerhed i NIS 2-lovens § 6, stk. 1, nr. 4, men tilladelsen følger ejerskabet.

Teksten er ikke juridisk rådgivning. Den beskriver, hvordan lagene kan fordeles, så kunden får et samlet billede.

Lagene i en leverance

En lagdelt leverance kan beskrives nedefra:

  1. Datacenteret · bygning, strøm, køling, fysisk adgang og eventuelt det net, der forbinder udstyret.
  2. Platformen · servere, virtualisering eller cloudtjenester, som en udbyder stiller til rådighed.
  3. Driften · opsætning, administration, opdatering, overvågning og backup, som en MSP eller I selv står for.
  4. Applikationen · den løsning, kunden bruger, med kode, roller og integrationer.
  5. Kundens del · kundens brugere, kundens data og kundens egne forbindelser til løsningen.

Ikke alle leverancer har alle lag, og nogle parter ejer flere lag. Det vigtige er at vide, hvem der ejer hvert lag i netop jeres leverance. → Hvilke systemer skal testes?

Hvem kan give lov til hvad

Tilladelsen til en test følger ejerskabet. Kunden kan give lov til test af kundens brugere og kundens egne systemer, men ikke til test af jeres platform. I kan give lov til test af det, I selv ejer og driver, men ikke til test af cloududbyderens infrastruktur eller datacenterets net.

Cloudplatformene har egne regler. Microsoft beskriver for Azure, at kunder kan teste deres egne ressourcer uden forudgående godkendelse, når reglerne for test følges, og at test af andre kunders ressourcer er forbudt. AWS beskriver, hvilke tjenester kunder kan teste uden forudgående godkendelse, og hvilke aktiviteter der er udelukket. Reglerne gælder også for en tester, I har bestilt. → Cloudtjenester i leverancen

Når flere ejere er involveret i samme test, skal hver tilladelse foreligge skriftligt, før testen begynder. Testeren skal kunne se, hvem der har sagt ja til hvilken del, og hvem der skal kontaktes, hvis noget uventet sker i et lag, som en anden ejer.

Datacenteret og hostingpartneren har deres aftaler. Står der intet om test, så spørg, før testen planlægges. → Leverancen kører hos en hostingpartner

Dokumentation, der ikke er en test

For de lag, I ikke ejer, er svaret til kunden ikke nødvendigvis en test, I har bestilt. Det er ejerens egen dokumentation: en erklæring, en certificering eller et resumé af ejerens egne test, hvis ejeren vil dele det. Datacentertjenester og cloudcomputingtjenester står i NIS 2-lovens bilag 1, pkt. 8, og en udbyder af den type kan selv være omfattet af loven og af forordning (EU) 2024/2690. Det betyder ikke, at udbyderens dokumentation dækker jeres opsætning. → Datacenteret i kæden

Forordningens bilagspunkt 5.1.4, litra g, nævner krav vedrørende underentreprise og cybersikkerhedskrav til underleverandører. For en kunde under forordningen betyder det, at kunden kan spørge, hvordan I stiller krav videre til platform og datacenter. Andre NIS2-kunder kan stille samme spørgsmål ud fra deres egen vurdering af forsyningskæden.

Grænsefladerne er ingens lag

Hvert lag kan være dokumenteret for sig, og leverancen kan alligevel have en svaghed der, hvor to lag mødes. Det kan være den konto, MSP’en bruger til at administrere cloudmiljøet, forbindelsen mellem applikationen og en database hos platformen, eller den vej, opdateringer kommer ind ad. Ingen af ejerne ser grænsefladen som sin, hvis det ikke er aftalt.

Placér derfor hver grænseflade hos en part, der tager den med i sin test. Det kan være den part, der har sat forbindelsen op eller bruger den. En MSP, der administrerer et cloudmiljø, kan tage sin egen adgang og sine egne roller med i testen, selv om platformen er udbyderens. En softwareleverandør kan tage applikationens forbindelser med, selv om databasen drives af andre.

Skriv grænsefladerne ind i oversigten til kunden som egne linjer. Så kan kunden se, at de ikke er faldet mellem to stole. → Integration med kunden

Saml billedet til kunden

Kunden har brug for at se, at alle lag er dækket, også selv om de er dækket på forskellige måder. En enkel oversigt kan vise hvert lag, hvem der ejer det, og hvilken dokumentation der findes:

  • Datacenter · ejerens erklæring eller certificering, dato og omfang.
  • Platform · udbyderens dokumentation og en henvisning til udbyderens regler for test.
  • Drift · jeres test af administrationsadgange, konti og værktøjer.
  • Applikation · test af løsningen, med eller uden kundens brugerroller.
  • Kundens del · det, kunden selv har ansvar for, og som I ikke har testet.

Huller skal fremgå af oversigten. Står der et lag uden dokumentation, er det bedre, at kunden ser det, end at kunden opdager det senere. → Afgrænsning mod kunden

Et tænkt eksempel

En softwareleverandør leverer et planlægningssystem til en vandforsyning. Systemet kører i et cloudmiljø, som en MSP drifter, og cloududbyderens tjenester ligger i et datacenter, som leverandøren aldrig har set. Vandforsyningen beder om testdokumentation. Softwareleverandøren lader applikationen teste. MSP’en lader sin administrationsadgang til cloudmiljøet teste efter aftale med softwareleverandøren. For platformen henvises til cloududbyderens egen dokumentation. Kunden får en oversigt over de tre dele og en kort beskrivelse af, hvad cloududbyderens dokumentation dækker.

Det skal I lade være med

  • At lade kunden give lov til test af jeres platform · tilladelsen skal komme fra ejeren.
  • At bede testeren teste cloudplatformen selv · udbyderens regler sætter grænsen.
  • At bruge datacenterets certificering som svar på hele kravet · den dækker ikke drift og applikation.
  • At skjule et lag uden dokumentation · kunden skal kunne se hullet.
  • At glemme MSP’en, når I selv er softwareleverandør · driftsadgangen er et lag for sig.

Hvad kan og ikke kan konkluderes

En oversigt over lagene kan vise kunden, hvem der har testet eller dokumenteret hvad, og hvor grænserne går. Den kan ikke gøre én parts test til dokumentation for et andet lag, og den kan ikke vise, at lagene hænger sikkert sammen, hvis grænsefladerne ikke er testet. Kunden vurderer selv, om helheden passer til kundens krav.

Tjekliste til en lagdelt leverance

  • ☐ Har I beskrevet, hvem der ejer hvert lag i leverancen?
  • ☐ Har ejeren af hvert lag givet tilladelse til det, der skal testes?
  • ☐ Kender I cloududbyderens og hostingpartnerens regler for test?
  • ☐ Har I ejerens dokumentation for de lag, I ikke tester?
  • ☐ Er grænsefladerne mellem lagene med i testen?
  • ☐ Viser oversigten til kunden både dækning og huller?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om NIS2 og penetrationstest

Læs også: MSP’en som mellemled · Når kunden vil have testet noget, I ikke ejer

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Har en kunde stillet NIS2‑krav?

Fortæl kort, hvad kunden har bedt om, og hvornår kunden skal have svar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.