Lille leverandør med få systemer: hvad er et rimeligt omfang?

En virksomhed med en håndfuld medarbejdere, en webløsning og nogle cloudtjenester kan få samme brev om NIS2 og penetrationstest som en stor it-leverandør. Et rimeligt omfang for den lille leverandør er som regel det, kunden faktisk er afhængig af, testet helt, frem for en bred test af alt, hvad virksomheden ejer. Det hviler på vejledningen fra Styrelsen for Samfundssikkerhed (SAMSIK), som anbefaler, at kravene til den enkelte leverandør står i forhold til leverancens betydning for kunden.

Princippet er beskrevet i → Forholdsmæssige krav. Her handler det om det praktiske: hvordan I som lille leverandør kommer fra brevet til et omfang, der kan forklares. Teksten er ikke juridisk rådgivning.

Få systemer er en fordel

En lille leverandør kan have en fordel, som store leverandører mangler: overblikket. Når det, kunden bruger, består af tre eller fire dele, kan testen dække dem alle, og dokumentationen kan sige det uden forbehold. En stor leverandør kan være nødt til at nøjes med et udsnit og forklare, hvorfor resten ikke var med.

Det betyder også, at omfanget kan beskrives i få linjer. Kunden behøver ikke læse en lang afgrænsning for at forstå, hvad der blev afprøvet. Det gør dokumentationen lettere at bruge i kundens egen leverandørvurdering. → Hvilke systemer forventer NIS2-kunden testet?

Start med en liste over det, I har

Før I kan foreslå et omfang, skal I vide, hvad der findes. Skriv det ned, også det, der virker oplagt:

Det, kunden bruger · webløsningen, portalen eller den tjeneste, kunden har købt.
Det, der forbinder jer · fjernadgang, integrationer, delte mapper og mailudveksling.
Det, I driver løsningen med · de konti og maskiner, der bruges til at administrere den.
Det, I lejer · cloudtjenester og hosting, som en anden part driver for jer.
Det, der ikke angår kunden · fx bogføring og interne dokumenter.

Den sidste gruppe er lige så vigtig som de andre. Den viser kunden, at I har tænkt over grænsen og ikke bare har glemt noget.

Sæt for hvert punkt et kryds ved, om kunden er afhængig af det, og om det kan nå kundens systemer eller data. Det, der får to kryds, er kernen i omfanget. Det, der får ét, skal I tage stilling til. Det, der ikke får nogen, kan normalt holdes ude, med en kort begrundelse. Listen kan genbruges, når den næste kunde spørger, og den gør det lettere at opdage, når der kommer et nyt system til.

Et rimeligt omfang i praksis

Et rimeligt omfang kan samles i to eller tre punkter fra listen. Hvilke det er, afhænger af leverancen, men dette mønster er et godt udgangspunkt:

Løsningen, kunden bruger · afprøvet med de roller, kundens medarbejdere har.
Vejen ind til kunden · hvis I har adgang til kundens systemer, kan den være det vigtigste punkt.
Administrationen af løsningen · de konti, der kan ændre alt, og hvordan de er beskyttet.

Testformen kan også tilpasses. SAMSIK beskriver i afsnit 5.a, at test kan spænde fra konfigurationsgennemgange til test af den samlede sikkerhed. For en enkel løsning med lav risiko kan en gennemgang af opsætningen sammen med en sårbarhedsscanning være et rimeligt bud, mens en løsning med adgang til kundens drift kan kalde på en egentlig penetrationstest. → Sårbarhedsscanning eller penetrationstest

Det, I lejer, og det, I selv har sat op

En lille leverandør har måske ingen egne servere. Løsningen kører hos en cloud- eller hostingleverandør, og mail og dokumenter ligger i en fælles kontortjeneste. Det fjerner ikke behovet for test, men det flytter det. Platformen er udbyderens ansvar; jeres opsætning, jeres konti og jeres egen kode er jeres.

Et rimeligt omfang tester derfor jeres del og henviser til platformens egen dokumentation for resten. Gør det tydeligt for kunden, hvor skillelinjen går. Kontroller også platformens regler for test, før testen bestilles, så testeren holder sig inden for dem. → Cloududbyderens dokumentation

Når I ikke har en it-afdeling

En lille leverandør har ikke nødvendigvis en sikkerhedsfunktion, der kan følge en test. Det er ikke en hindring, men det skal planlægges. Udpeg én person, der er kontakt for testeren, kan godkende, hvis noget skal stoppes, og modtager resultatet. Aftal på forhånd, hvem der retter fund, hvis en ekstern partner drifter løsningen. Læg også tid til side efter testen: fundene skal forstås, rettes og beskrives over for kunden, og det arbejde kan lande hos de samme få personer, der også passer den daglige drift.

Hvad testen koster, afhænger især af antallet af systemer, adgangsveje og roller, der skal med; se pris og tilbud for, hvordan opgaverne prissættes. Et præcist omfang er også den bedste måde at holde udgiften i forhold til leverancen.

Et tænkt eksempel

En virksomhed med fire ansatte leverer et bookingsystem til en regions patientkørsel. Systemet kører hos en hostingudbyder, og to medarbejdere har administratoradgang. Regionen sender et standardbilag med krav om årlig penetrationstest af leverandørens it-miljø.

Virksomheden laver en liste over sine systemer og foreslår regionen en test af bookingsystemet med regionens brugerroller og af administratorkontiene, mens kontorets egen mail og bogføring holdes uden for. Regionen accepterer på skrift og beder om at få besked, hvis virksomheden senere skifter hostingudbyder. Dokumentationen viser, at alle dele, regionen bruger, var med, og henviser til hostingudbyderens dokumentation for platformen.

Det skal I lade være med

At sige ja til en test af hele virksomheden uden at tænke · det giver en dyr test, der dækker meget, kunden ikke bruger.
At udelade vejen ind til kunden · den kan være vigtigere end selve løsningen.
At gå ud fra, at platformen dækker alt · jeres opsætning og konti er jeres.
At lade omfanget stå uden begrundelse · skriv, hvorfor resten er udeladt.
At glemme en kontaktperson under testen · nogen skal kunne svare og stoppe.

Hvad kan og ikke kan konkluderes

Et smalt, men fuldt omfang kan give kunden en klar dokumentation for netop de dele, kunden er afhængig af. Det siger ikke noget om de dele, der var udeladt, og det afgør ikke, om kunden accepterer afgrænsningen. Kunden vurderer selv, om omfanget passer til sin risikovurdering. Ændrer leverancen sig, fx med en ny integration eller en ny adgang, skal omfanget ses igennem igen. → Kunden skal kunne vise tilsynet jeres testresultat

Tjekliste til omfanget

☐ Er alle systemer skrevet ned, også dem, der ikke angår kunden?
☐ Er det markeret, hvad kunden er afhængig af, og hvad der kan nå kundens data?
☐ Er vejen ind til kunden med, hvis den findes?
☐ Er skillelinjen mod platformen beskrevet?
☐ Er der en kontaktperson under testen?
☐ Har kunden accepteret omfanget på skrift?

Kilder

SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om krav, der står i forhold til leverancens betydning, og afsnit 5.a om test fra konfigurationsgennemgange til test af den samlede sikkerhed.
SAMSIK, vejledning om anvendelsesområdet (maj 2025): afsnit 8 om forholdsmæssige krav til leverandører.

Senest gennemgået: oktober 2026.