Kundens leverandørregister: hvorfor I bliver spurgt om systemer og adgange

Et skema, der beder om kontaktpersoner, en liste over leverede tjenester og en beskrivelse af jeres adgange, kan ligne ren administration. Svaret hviler på et konkret krav i gennemførelsesforordning 2024/2690, bilagets pkt. 5.2: de enheder, forordningen gælder for, skal føre et opdateret register over deres direkte leverandører og tjenesteudbydere. Andre NIS2-kunder kan gøre det samme som led i deres leverandørstyring.

Det, I skriver i registret, bliver kundens billede af jeres leverance. Det billede bruger kunden senere, når kravet om test skal formuleres, og når en hændelse skal håndteres. Derfor er det værd at svare præcist.

Hvad registret skal rumme

Ifølge bilagets pkt. 5.2 skal registret mindst indeholde kontaktpunkter for hver direkte leverandør og tjenesteudbyder og en liste over de IKT-produkter, IKT-tjenester og IKT-processer, leverandøren leverer til enheden. ENISA’s tekniske vejledning foreslår, at registret holdes opdateret og gennemgås mindst en gang om året eller ved væsentlige ændringer, og at kunden fx også noterer kontraktens start- og slutdato.

Forordningen gælder bestemte digitale udbydere som cloud, datacentre, MSP og MSSP. Er jeres kunde en anden type enhed, er registret ikke nødvendigvis et lovkrav, men nogle kunder bruger forordningen og ENISA’s vejledning som skabelon alligevel. → Gennemførelsesforordning 2024/2690

Hvorfor svaret former testkravet

Registret kan være kundens første kilde, når kunden skal afgøre, hvad der skal testes hos jer. Står der kun hjemmeside og support, kan kunden overse den fjernadgang, jeres teknikere bruger. Står der hele virksomheden, kan kunden ende med at bede om en test af systemer, der intet har med leverancen at gøre.

En præcis liste over det, I leverer, gør det lettere at blive enige om et rimeligt omfang. Den bliver i praksis udgangspunktet for afgrænsningen af en test, og den gør det muligt at vise kunden, at testen dækker det, der står i registret. → Hvilke systemer forventer NIS2-kunden testet?

ENISA’s vejledning foreslår desuden, at kunden klassificerer leverandørerne. Oplysningerne i registret indgår i den vurdering. → Kunden har klassificeret jer som kritisk leverandør

Sådan beskriver I leverancen

Hold beskrivelsen i det sprog, kunden forstår, og knyt den til det, kunden bruger. Disse oplysninger kan dække det meste af et skema:

Tjenester · fx drift af kundens servere, en webbaseret kundeportal eller levering og service af et anlæg.
Adgange · hvilke systemer hos kunden I kan komme ind i, og om det sker via fast forbindelse eller efter aftale.
Konti · om I bruger personlige konti, fælles konti eller tjenestekonti, og hvem der administrerer dem.
Data · hvilke af kundens oplysninger der ligger hos jer eller passerer jeres systemer.
Partnere · hvilke af jeres egne leverandører der indgår i leverancen, fx hosting eller en platform.

Skriv kun det, der er rigtigt i dag. Planlagte ændringer kan nævnes for sig, så de ikke forveksles med den nuværende leverance.

Et tænkt eksempel: en leverandør af styringssoftware til et vandværk skriver i første omgang blot software og support. Efter en kort gennemgang bliver det til en webbaseret overvågning, som vandværkets driftsfolk logger ind på, en fast fjernforbindelse til anlæggets styring og to navngivne servicekonti. Den anden beskrivelse fortæller kunden langt mere om, hvor risikoen ligger, og hvad en test bør omfatte. → Delte konti og fælles adgange

Kontaktpunktet for sikkerhed

Kontaktpunkterne er mere end et telefonnummer til salg. Kunden har brug for at vide, hvem hos jer der skal have besked, hvis kunden opdager noget, og hvem der sender besked den anden vej, hvis I finder en sårbarhed eller har en hændelse, der berører kunden.

Angiv en funktion frem for kun en person, så kontakten ikke forsvinder ved ferie eller jobskifte. Notér også, hvem der kan svare på spørgsmål om testresultater. Når kunden senere spørger ind til et fund eller en rapport, er det den kontakt, der bruges. → Leverandørens pligt til at give besked om hændelser

Hvor meget skal I fortælle?

En detaljeret beskrivelse af jeres systemer kan være følsom. Kunden har brug for at vide, hvad I leverer, og hvilken adgang I har, men ikke nødvendigvis for interne navne, adresser eller opsætningsdetaljer. Beskriv funktionen og adgangen, og hold de tekniske oplysninger til den test, hvor de skal bruges under fortrolighed. → Fortrolighed om jeres systemer

Spørg også, hvem hos kunden der kan læse registret. Er det et indkøbssystem med mange brugere, er det endnu en grund til at holde beskrivelsen på funktionsniveau. Hvis kunden har brug for flere detaljer, kan de sendes til en navngiven modtager hos kunden i stedet for at ligge i skemaet.

Hold oplysningerne opdateret

Registret er kun brugbart, hvis det passer. ENISA’s vejledning lægger op til, at kunden gennemgår det med faste mellemrum, og det betyder, at I kan blive spurgt igen. Gør det let for jer selv: gem jeres svar, og opdatér det, når leverancen ændrer sig, fx ved en ny adgang til kundens drift eller et skifte af hostingpartner.

Sig det til kunden af egen drift, når noget væsentligt ændrer sig. Det kan være den ændring, der gør, at kunden vil have en ny test, og det er bedre, at den kommer fra jer end fra en senere gennemgang.

Hold en intern note over, hvilke kunder der har fået hvilken beskrivelse. Når mange kunder fører hver sit register, er det let at glemme, hvem der skal have besked, når en adgang lukkes, eller en ny partner kommer til. En simpel liste med kunde, dato og version af svaret kan være nok, og den gør det muligt at sende samme rettelse til alle de berørte på én gang. → Kundens løbende opfølgning

Det skal I lade være med

At skrive hele virksomheden som leverance · kunden får et forkert billede og et for bredt testkrav.
At udelade fjernadgang og konti · det kan være dem, kunden er mest optaget af.
At angive én person som eneste kontakt · brug en funktion, der altid kan nås.
At sende tekniske detaljer i et åbent skema · beskriv funktion og adgang, ikke opsætningen.
At lade svaret blive gammelt · opdatér det, når leverancen ændrer sig.

Hvad kan og ikke kan konkluderes

Kundens register viser, hvad kunden ved om jeres leverance, og kan danne grundlaget for kundens krav om test og opfølgning. Det dokumenterer ikke, at leverancen er sikker, og det er ikke en vurdering af jer. Om registret er et lovkrav for netop jeres kunde, afhænger af, hvilken type enhed kunden er. Teksten er ikke juridisk rådgivning.

Tjekliste til jeres svar

☐ Er tjenesterne beskrevet, som kunden bruger dem?
☐ Er adgange og konti hos kunden nævnt?
☐ Er kontaktpunktet for sikkerhed en funktion, der altid kan nås?
☐ Er tekniske detaljer holdt ude af skemaet?
☐ Er svaret gemt, så det kan opdateres?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilag, pkt. 5.2, om register over direkte leverandører og tjenesteudbydere.
ENISA, NIS2 Technical Implementation Guidance: vejledning til bilagets pkt. 5.2 om opdatering, gennemgang og klassificering. Ikke bindende.

Senest gennemgået: oktober 2026.