Kunden kræver test, før samarbejdet starter

En ny kunde, der er omfattet af NIS2, kan bede om dokumentation for test, inden kontrakten er underskrevet, og det skaber et praktisk problem: den leverance, kunden skal bruge, findes måske ikke endnu. Svaret hviler på at skille tre ting ad. Hvad kan I dokumentere i dag om det, der allerede findes? Hvad kan først testes, når kundens opsætning er bygget? Og hvordan skrives det sidste ind i aftalen, så kunden ved, hvornår beviset kommer?

Et nyt samarbejde kan derfor starte med en kombination af eksisterende dokumentation og en aftalt test ved idriftsættelse. Det kræver, at I siger tydeligt, hvad der dækkes nu, og hvad der ikke gør.

Hvorfor kravet kommer så tidligt

Styrelsen for Samfundssikkerheds vejledning om foranstaltninger beskriver, at en omfattet enhed bør have kriterier for, hvordan den udvælger leverandører, og at den bør overveje at bruge sikkerhedskravene allerede i udvælgelsen af nye leverandører. Gennemførelsesforordning 2024/2690 har et beslægtet krav til de digitale udbydere, den gælder for: bilagets pkt. 5.1.2 handler om kriterier for at vælge og indgå kontrakt med leverandører.

For jer betyder det, at sikkerhedsspørgsmålene kommer, mens kunden stadig sammenligner tilbud. Det er ikke mistillid. Det er kundens måde at dokumentere, at leverandørrisikoen er vurderet, før aftalen indgås. → Kundens risikovurdering som grundlag

Spørg derfor, hvad kunden skal bruge svaret til på dette tidspunkt. Det kan være et punkt i en sammenligning af tilbud, hvor kunden skal kunne se, at I har en praksis for test, og hvornår den nye leverance bliver afprøvet. Det er et andet behov end den dokumentation, kunden senere skal kunne vise sit tilsyn. Når I kender formålet, kan I sende det, der passer til fasen, i stedet for alt, hvad I har.

Det, der allerede findes

Tag udgangspunkt i det, kunden faktisk kommer til at bruge, og se, hvad af det der allerede er testet:

Fælles platform · den løsning, alle kunder bruger, kan være testet for nylig, også selv om den nye kundes opsætning ikke er.
Standardprodukt · et produkt, der leveres ens til alle, kan have en test, der dækker det meste af kundens brug.
Supportadgang · den måde, jeres teknikere kommer ind hos kunder, kan være den samme for alle og allerede være afprøvet.
Hosting og drift · miljøet, løsningen kører i, kan have egen dokumentation, enten fra jer eller fra en partner.

Skriv for hvert punkt, hvad testen omfattede, og hvornår den blev gennemført. Kunden kan så se, hvor meget af den fremtidige leverance der allerede er dækket. Nævn også de dele, der ikke har været testet, så kunden ikke selv skal finde hullerne. → Kundespecifik opsætning eller fælles platform

Det, der først kan testes senere

Kundespecifikke dele kan ikke testes, før de er bygget. Det gælder fx en integration til kundens ERP-system, en særlig rollemodel for kundens medarbejdere eller en fjernforbindelse ind til kundens produktionsanlæg. De dele kan beskrives, men ikke afprøves.

ENISA’s tekniske vejledning til forordningens pkt. 6.5 peger på test ved opsætning, efter væsentlige opgraderinger og efter vedligehold. Det giver en naturlig plads til den kundespecifikke test: når opsætningen er færdig, og før den tages i brug med rigtige data. → Test ved idriftsættelse

Vær ærlig om rækkefølgen. Hvis kunden skal i drift på en bestemt dato, skal testen ligge så tidligt, at alvorlige fund kan nå at blive håndteret. Ellers ender I med at gå i drift med en test, der kun viser, hvad der mangler.

Skriv testen ind i aftalen

Når en del af dokumentationen først kan leveres senere, skal det fremgå af aftalen. Kunden har brug for at vide, hvad der er lovet, og I har brug for at vide, hvad der forventes. Punkterne kan være få:

Omfang · hvilke kundespecifikke dele testen skal omfatte.
Tidspunkt · før idriftsættelse, eller inden for en aftalt periode efter.
Dokumentation · om kunden får et resumé, en erklæring eller rapporten.
Alvorlige fund · hvordan kunden får besked, og hvad der sker med idriftsættelsen.
Udgiften · hvem der betaler testen af den kundespecifikke del.

Teksten er ikke juridisk rådgivning, og den endelige formulering bør vurderes af den, der normalt håndterer jeres kontrakter. → Hvilke systemer forventer NIS2-kunden testet?

Når kunden vil have en test af alt, før der skrives under

Nogle kunder beder om en test af hele leverancen før kontraktstart, også de dele, der ikke findes endnu. Det kan ikke lade sig gøre, og det er bedre at sige det end at sende en rapport, der lader som om. Forklar, hvad den eksisterende dokumentation dækker, og foreslå en plan for resten.

En kort plan med omfang, tidspunkt og leverance kan være det, kunden har brug for i sin egen dokumentation. Den viser, at spørgsmålet er taget alvorligt, og den kan godkendes af kunden, før aftalen underskrives. → Når kravet er uklart: send en plan

Hvis kunden insisterer på en test af en eksisterende del før kontraktstart, så aftal, hvem der betaler, og hvad der sker med dokumentationen, hvis samarbejdet ikke bliver til noget. Rapporten handler om jeres systemer, og den skal ikke blive liggende hos en virksomhed, der aldrig blev kunde.

Det skal I lade være med

At sende en gammel rapport uden dato og omfang · kunden skal kunne se, hvad den dækker.
At love en test af noget, der ikke er bygget · beskriv i stedet, hvornår den kan gennemføres.
At lade idriftsættelsen ligge før testen · uden tid til rettelser bliver testen en liste over mangler.
At glemme testen i aftalen · et mundtligt løfte bliver let glemt, når projektet går i gang.
At dele den fulde rapport med en kunde, der endnu ikke er kunde · aftal vilkår for opbevaring og sletning først.

Hvad kan og ikke kan konkluderes

Dokumentation, der findes før kontraktstart, kan vise, at fælles dele af leverancen er afprøvet. Den kan ikke sige noget om den kundespecifikke opsætning, der endnu ikke er bygget. En aftalt test ved idriftsættelse kan lukke det hul, men først når den er gennemført, og fundene er håndteret. Kundens beslutning om at indgå aftalen er kundens egen vurdering, som ingen test kan træffe på kundens vegne.

Tjekliste før tilbuddet sendes

☐ Er det klart, hvilke dele af leverancen der allerede findes?
☐ Er eksisterende test af de dele beskrevet med omfang og dato?
☐ Er de kundespecifikke dele, der først kan testes senere, nævnt?
☐ Står testen ved idriftsættelse i aftaleudkastet?
☐ Er der tid til rettelser mellem test og drift?
☐ Er vilkår for deling af dokumentation før kontraktstart aftalt?

Kilder

SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om kriterier for valg af leverandører og sikkerhedskrav i udvælgelsen.
Gennemførelsesforordning (EU) 2024/2690: bilag, pkt. 5.1.2, om kriterier for valg af leverandører.
ENISA, NIS2 Technical Implementation Guidance: vejledning til bilagets pkt. 6.5 om test ved opsætning og efter væsentlige ændringer. Ikke bindende.

Senest gennemgået: oktober 2026.