En NIS2-kunde ser jeres leverance som én helhed. I ved, at den består af dele med forskellige ejere: software, I har licens til, en platform, I lejer, og en partner, der driver en del af løsningen. Når kunden beder om en test af det hele, er svaret, at I kun kan give tilladelse til det, I selv råder over. Resten kræver ejerens accept, og nogle ejere har faste regler for, hvad der må testes. Kunden kan heller ikke give tilladelsen på ejerens vegne.
Det hviler på et enkelt princip, som går igen i både platformsleverandørernes regler og i almindelig praksis for penetrationstest: det er ejeren af systemet, der giver lov. Teksten er ikke juridisk rådgivning.
Tre slags dele, I ikke ejer
De dele, der volder problemer, kan falde i tre grupper:
- Licenseret software · et produkt fra en anden producent, som I bygger ind i jeres løsning eller videresælger.
- Platforme · cloud, hosting eller en fælles tjeneste, som løsningen kører på.
- Partneres systemer · en underleverandør, der driver en del af leverancen, fx support, overvågning eller betaling.
For hver gruppe gælder det samme spørgsmål: hvem ejer systemet, og hvad har ejeren sagt om test? Svaret er ikke det samme for de tre. → Hvem tester hvad i kæden?
Platformene har deres egne regler
De store cloudplatforme har offentliggjort regler for test. Microsoft skriver på Microsoft Learn, at kunder kan teste de Azure-ressourcer, de selv ejer, uden forudgående godkendelse, men at testen skal følge Microsofts regler for penetrationstest. Tredjeparter må teste med udtrykkelig skriftlig tilladelse fra ejeren af ressourcerne, og Microsoft giver ikke tilladelse på kundens vegne. Test af ressourcer, man ikke ejer eller har tilladelse til, er forbudt.
AWS skriver tilsvarende, at kunder kan teste deres egen infrastruktur på en række navngivne tjenester uden forudgående godkendelse, mens test af AWS’ egne tjenester ikke er tilladt.
Det betyder to ting for jer. Den del af platformen, I selv har sat op, kan normalt testes efter platformens regler. Platformen bag kan ikke. Kunden kan altså ikke regne med en test af selve cloudtjenesten, men kan få en test af jeres opsætning af den. → Cloudtjenester i leverancen
Licenseret software og producentens rolle
Software fra en anden producent er en særlig sag. Kører produktet i jeres miljø, kan I som udgangspunkt teste, hvordan I har sat det op og koblet det sammen med resten. Om licensen tillader en dybere test af selve produktet, afhænger af licensvilkårene, og dem skal I læse, før testen bestilles.
Finder testen en svaghed i producentens produkt, er det ikke jer, der kan rette den. Fundet skal meldes til producenten, og kunden skal vide, hvad I gør i mellemtiden. I kan muligvis begrænse risikoen i jeres egen opsætning, fx ved at lukke en funktion eller indsnævre adgangen, indtil producenten har en rettelse klar. Den slags midlertidige tiltag hører med i dokumentationen til kunden. → Fund i tredjepartskomponenter
Partnere og underleverandører
En partner, der driver en del af leverancen, ejer sine egne systemer. En test af dem kræver partnerens skriftlige accept, og partneren kan foretrække at stille sin egen dokumentation til rådighed end lade en anden part teste. Det er forståeligt: partneren har andre kunder på de samme systemer, og en test bestilt af jer kan påvirke dem. Spørg tidligt, så I ikke står med et kundekrav og et nej fra partneren samtidig. Er partneren villig, skal tilladelsen beskrive omfang, tidspunkt og kontaktpersoner, ligesom en tilladelse fra kunden.
Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, men dens punkter kan bruges som model af andre kunder. Bilagets punkt 5.1.4, litra g, nævner krav om underentreprise og cybersikkerhedskrav til underleverandører som noget, der kan stå i kundens kontrakt med jer. Styrelsen for Samfundssikkerhed (SAMSIK) nævner det samme i sin vejledning om foranstaltninger, afsnit 4. Har kunden skrevet sådan et krav ind, skal I kunne vise, hvordan I selv følger op på jeres partnere. → Krav til jeres egne underleverandører
Hvad I kan tilbyde i stedet
Når en del ikke kan testes på jeres tilladelse, er der stadig noget at give kunden:
- Testen af jeres del · jeres opsætning, konti og forbindelser til den del, I ikke ejer.
- Ejerens dokumentation · fx en platformsleverandørs egne rapporter eller erklæringer, når de må deles.
- Ejerens accept · hvis ejeren vil, kan testen udvides med en skriftlig tilladelse.
- En beskrivelse af grænsen · hvilke dele der er uden for jeres rækkevidde, og hvorfor.
Det sidste kan være det vigtigste. Kunden har brug for at vide, at grænsen er bevidst, og hvad der dækker den anden side. Skriv beskrivelsen, så den kan stå alene i kundens leverandøropfølgning, også når den, der modtog den, er skiftet ud.
Et tænkt eksempel
En leverandør af et system til vandværkers målerdata kører løsningen hos en cloudplatform og bruger en partner til at drive sms-varsler til forbrugerne. Et vandværk beder om en penetrationstest af hele løsningen.
Leverandøren bestiller en test af sin egen applikation og sin opsætning af cloudplatformen, inden for platformens regler. Partneren vil ikke testes, men sender en beskrivelse af sin egen sikkerhedstest og en kontaktperson til hændelser. Leverandøren samler det i én pakke til vandværket: sin egen testdokumentation, partnerens materiale og en kort beskrivelse af, hvad hver del dækker. Vandværket noterer partneren i sit leverandørregister.
Det skal I lade være med
- At lade testeren gå ud over jeres egen tilladelse · det gælder også, når kunden beder om det.
- At tro, at kundens ønske er en tilladelse · kunden ejer heller ikke jeres partneres systemer.
- At springe platformens regler over · de gælder også for en tester, I har bestilt.
- At skjule, at en del er udeladt · kunden skal kunne se grænsen.
- At glemme licensvilkårene · de kan begrænse, hvad der må testes i et produkt.
Hvad kan og ikke kan konkluderes
En test af jeres del kan vise, hvordan jeres opsætning og forbindelser til andres systemer opførte sig på testtidspunktet. Den siger intet om selve platformen, producentens produkt eller partnerens systemer, medmindre ejeren har givet lov til, at de kom med. Ejerens egen dokumentation kan supplere, men den er ejerens udsagn og ikke en del af jeres test.
Tjekliste, før testen bestilles
- ☐ Er ejeren af hver del af leverancen kendt?
- ☐ Er platformens regler for test læst og givet til testeren?
- ☐ Er licensvilkårene for indbygget software kontrolleret?
- ☐ Har partnere givet skriftlig accept, hvis deres systemer skal med?
- ☐ Er det beskrevet for kunden, hvilke dele der ligger uden for testen?
Kilder
- Microsoft Learn, penetrationstest i Azure: kundens test af egne ressourcer, krav om skriftlig tilladelse fra ejeren og forbud mod test af andres ressourcer.
- AWS, penetration testing: kundens test af egen infrastruktur og forbud mod test af AWS’ egne tjenester.
- Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.4, litra g, om underentreprise.
- SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om underleverandører i aftaler med leverandører.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om NIS2 og penetrationstest
Læs også: MSP’en som mellemled · Afgrænsning mod kundens eget miljø
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT