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:
- Datacenteret · bygning, strøm, køling, fysisk adgang og eventuelt det net, der forbinder udstyret.
- Platformen · servere, virtualisering eller cloudtjenester, som en udbyder stiller til rådighed.
- Driften · opsætning, administration, opdatering, overvågning og backup, som en MSP eller I selv står for.
- Applikationen · den løsning, kunden bruger, med kode, roller og integrationer.
- 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
- NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 4, og bilag 1, pkt. 8.
- Gennemførelsesforordning (EU) 2024/2690: artikel 1 og bilagets punkt 5.1.4, litra g.
- Microsoft Learn (Azure), Penetration testing: test af egne ressourcer og forbudt test.
- AWS, Penetration Testing: tjenester, der kan testes uden forudgående godkendelse, og forbudte aktiviteter.
Senest gennemgået: oktober 2026.
Næste skridt
- Krav, I skal sende videre til jeres egne underleverandører
- Cloududbyderens dokumentation og jeres egen test
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