Når en ny løsning skal sættes i drift hos en NIS2-kunde, kan spørgsmålet om test komme sent i projektet, selv om det burde have stået i planen fra start. Kunden vil vide, at det, der sættes i drift, er afprøvet i den opsætning, kunden faktisk skal bruge. Svaret hviler på de danske og europæiske vejledninger om test ved installation og væsentlige ændringer og, for visse digitale udbydere, på gennemførelsesforordning 2024/2690.
Kort sagt er idriftsættelsen det tidspunkt, hvor en test giver mest mening for kunden, fordi den kan vise tilstanden i den endelige opsætning, før rigtige data og brugere kommer ind. Det kræver, at testen er planlagt som en del af projektet med tid til at rette fund.
Hvad vejledningerne siger om tidspunktet
Styrelsen for Samfundssikkerheds vejledning om foranstaltninger fra juni 2025 siger i afsnit 6.b, at net- og informationssystemer bør sikkerhedstestes i forbindelse med installation, vedligeholdelse og ved opgradering eller ændringer, som enheden vurderer som væsentlige. ENISA’s tekniske vejledning fra juni 2025, som ikke er bindende, siger i sin vejledning til bilagets punkt 6.5.2, at der bør testes ved opsætning, efter væsentlige opgraderinger eller ændringer og efter vedligeholdelse.
Begge tekster er rettet til kunden, ikke til jer. Men når en ny leverance er en del af kundens net- og informationssystemer, er det jeres opsætning, kunden skal teste eller have testet. Kunden kan vælge at teste selv, at lade en tredjepart gøre det eller at bede jer sørge for testen. Hvem der gør hvad, bør stå i aftalen, så testen ikke bliver glemt mellem to parter, der begge tror, den anden har ansvaret. → Test før kontraktstart
Forordningens krav til det, kunden køber
For de digitale udbydere, forordning 2024/2690 gælder for, fx cloud, datacentre og udbydere af administrerede tjenester, er der et særskilt punkt om erhvervelse. Bilagets punkt 6.1.2 nævner bl.a. sikkerhedskrav til de IKT-tjenester og produkter, der skal erhverves, oplysninger om den konfiguration, der er nødvendig for sikker drift, og i litra f metoder til at validere, at det leverede opfylder kravene, samt dokumentation for resultatet.
En test ved idriftsættelse er én måde at validere på. Selv når kunden ikke er under forordningen, kan punktet forklare, hvorfor kunden beder om dokumentation, før leverancen godkendes. Udvikler I løsningen for kunden, gælder punkt 6.2.3 om outsourcet udvikling desuden for kunden. → Krav om sikker udvikling
Planlæg testen i projektet
En test ved idriftsættelse skal passe ind i projektplanen. Det, der skal være på plads, er:
- Tidspunktet · når opsætningen er færdig, men før kundens data og brugere kommer ind.
- Miljøet · det miljø, der sættes i drift, eller et, der svarer til det, og en beskrivelse af eventuelle forskelle.
- Omfanget · den del af leverancen, kunden er afhængig af, herunder integrationer og adgange til kundens egne systemer.
- Tilladelserne · fra jer, fra kunden og fra eventuelle hosting- og cloudpartnere. → Afgrænsning mod kundens eget miljø
- Tid til at rette · en periode mellem testen og idriftsættelsen, hvor fund kan rettes og eventuelt afprøves igen.
- Kriteriet for at gå i drift · hvad kunden og I gør, hvis der findes noget alvorligt.
Det sidste punkt er det, der kan mangle. Uden en aftale om, hvad der sker ved et alvorligt fund, kan testen ende som en forsinkelse, ingen har planlagt for.
Standardløsning eller kundens opsætning
En leverance kan bygge på en fælles platform med en opsætning til den enkelte kunde. Har platformen været testet for nylig, kan det være nok at teste kundens særlige del: adgange, roller, integrationer og indstillinger. Kunden skal så have både den tidligere test af platformen og den nye test af opsætningen og kunne se, hvordan de hænger sammen. → Kundespecifik opsætning eller fælles platform
Leverer I udstyr eller software, som kunden selv installerer, er opsætningen kundens. Her kan jeres bidrag være en beskrivelse af den sikre konfiguration og en test af produktet som sådan. → Udstyr og software, I leverer
Et tænkt eksempel
En leverandør skal sætte et nyt system til patientbooking i drift hos en privat klinik, der er omfattet af NIS 2-loven. Kontrakten nævner test før idriftsættelse, men ikke hvornår. Leverandøren lægger testen ind flere uger før den planlagte dato og aftaler med klinikken, at fund med høj alvorlighed skal være rettet, før systemet åbnes for patienter, mens øvrige fund kommer med i en plan. Testen finder én alvorlig fejl i en integration, som rettes og afprøves igen inden åbningen. Klinikken får et resumé, der viser omfang, tidspunkt, fund og status.
Efter idriftsættelsen
En test ved idriftsættelse er et øjebliksbillede. Kunden kan forvente nye test ved væsentlige ændringer og ved opgraderinger, og det bør stå i aftalen, hvad der tæller som væsentligt. ENISA’s vejledning nævner også løbende test, særligt hvor ændringer udrulles ofte og automatisk. Udgiver I nye versioner af leverancen jævnligt, kan det give mere mening at aftale en fast måde at teste ændringer på end at vente på en stor test hvert år.
Gem dokumentationen fra testen ved idriftsættelsen sammen med beskrivelsen af opsætningen. Når kunden senere beder om dokumentation for test, er den første test udgangspunktet, og ændringer siden da kan beskrives i forhold til den. → Ny test efter væsentlige ændringer
Det skal I lade være med
- At planlægge testen dagen før idriftsættelsen · der er så ingen tid til at rette fund.
- At teste et andet miljø uden at sige det · kunden skal vide, hvad testen dækker.
- At sætte i drift med alvorlige fund uden aftale · beslutningen skal være kundens og jeres sammen og skrevet ned.
- At lade integrationerne vente til senere · forbindelserne til kunden kan være det, kunden er mest optaget af.
- At lade testen stå uden plan for næste gang · aftal, hvad der udløser en ny test.
Hvad kan og ikke kan konkluderes
En test ved idriftsættelse kan vise tilstanden i den opsætning, der blev testet, på det tidspunkt, den blev testet. Den kan ikke vise, at leverancen forbliver sikker, når den ændres, eller at kunden lever op til sine krav. Teksten er ikke juridisk rådgivning, og aftalen med kunden afgør, hvad der skal testes før idriftsættelse.
Tjekliste til testen før idriftsættelse
- ☐ Står testen i projektplanen med tid til rettelser?
- ☐ Er det aftalt, hvilket miljø der testes, og hvordan det svarer til driften?
- ☐ Er integrationer og adgange til kundens systemer med i omfanget?
- ☐ Har kunden og partnere givet tilladelse, hvor det kræves?
- ☐ Er der et skriftligt kriterium for at gå i drift ved alvorlige fund?
- ☐ Er det aftalt, hvad der udløser en ny test efter idriftsættelsen?
Kilder
- SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 6.b om test ved installation, vedligeholdelse og væsentlige ændringer.
- ENISA, NIS2 Technical Implementation Guidance (juni 2025): vejledningen til punkt 6.5.2 om test ved opsætning, opgraderinger og vedligehold. Ikke bindende.
- Gennemførelsesforordning (EU) 2024/2690: artikel 1 (hvem den gælder for) og bilagets punkt 6.1.2 og 6.2.3.
- NIS 2-loven, lov nr. 434 af 6. maj 2025: § 6, stk. 1, nr. 5 og 6.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om NIS2 og penetrationstest
Læs også: Ny test efter væsentlige ændringer · Kundespecifik opsætning eller fælles platform
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT