Leverantörsregistret som NIS2 artikel 21.2 d kräver

NIS2 — direktiv (EU) 2022/2555 — gäller medelstora och större verksamheter i sektorerna i bilaga I och II, och några typer av verksamheter oavsett storlek (artikel 2). De flesta startups och små företag omfattas inte. Deras kunder gör det ofta, och artikel 21.2 d gör de kunderna ansvariga för säkerheten i sin leveranskedja, “inbegripet säkerhetsrelaterade aspekter som rör förhållandet mellan varje entitet och dess direkta leverantörer eller tjänsteleverantörer”. Den meningen är skälet till att en liten leverantör får ett säkerhetsformulär, och den är också specifikationen för det register ett litet företag bör föra över sina egna leverantörer. Den här guiden går igenom vad registret måste innehålla.

Vad artikel 21 faktiskt kräver

Artikel 21.1 kräver att väsentliga och viktiga entiteter vidtar “lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder” för att hantera riskerna för säkerheten i sina nätverks- och informationssystem. Artikel 21.2 räknar upp tio åtgärder som “minst” ska ingå; d är säkerhet i leveranskedjan. Artikel 21.3 ger detaljen: när entiteterna avgör vilka åtgärder som är lämpliga ska de “beakta de sårbarheter som är specifika för varje direkt leverantör och tjänsteleverantör samt den övergripande kvaliteten på produkter och cybersäkerhetspraxis hos sina leverantörer och tjänsteleverantörer, inbegripet deras säkra utvecklingsförfaranden”.

Tre ord bär registret. Varje direkt leverantör: inte de viktiga, alla. Specifika sårbarheter: per leverantör, inte ett allmänt uttalande. Praxis: vad leverantören faktiskt gör, vilket ni lär er av dess säkerhetssida, dess biträdesavtal, dess certifieringar och dess incidenthistorik. Artikel 20.1 lägger godkännande och tillsyn av åtgärderna på ledningsorganet, som kan hållas ansvarigt, så registret är ett styrelsedokument lika mycket som ett operativt. Artikel 23 sätter klockan för incidentrapportering — tidig varning inom 24 timmar, incidentanmälan inom 72, slutrapport inom en månad efter incidentanmälan — och vid en incident i leveranskedjan måste verksamheten inom timmar veta vilken leverantör, vilken tjänst och vem som ska ringas.

Kommissionens genomförandeförordning (EU) 2024/2690, som preciserar artikel 21 för moln-, DNS-, datacenter-, managed service- och liknande leverantörer, säger det rakt ut i avsnitt 5 i sin bilaga: en policy för säkerhet i leveranskedjan och ett uppdaterat register över direkta leverantörer och tjänsteleverantörer med en kontaktpunkt för var och en och en lista över de produkter, tjänster och processer var och en levererar. Den binder bara de verksamheter den namnger, men det är den mest konkreta beskrivningen av vad en tillsynsmyndighet menar med “leverantörsregister”, och den mall en kund i vilken sektor som helst kommer att känna igen.

Vad registret måste innehålla

En rad per leverantör. Juridiskt namn, land, vad den gör för er, om den är i bruk, vem som äger relationen internt. Leverantörer ni utvärderat och inte valt stannar i registret med den statusen; beslutet är också bevis.

Tjänsterna och systemen varje leverantör ingår i. Registret svarar på “vem är vi beroende av”; systemvyn svarar på “vad är beroende av dem”. Länka dem åt båda håll, så att en incident hos e-postleverantören berättar vilka av era tjänster som slutar skicka. Det här är genomförandeförordningens “lista över produkter, tjänster och processer”.

Dokumenten ni förlitar er på. Biträdesavtalet, villkoren, säkerhetssidan, listan över underbiträden, SLA:t, AI-policyn — som de lästes ett visst datum, med de fakta ni plockat ut och styckena de kom ur. Se Så läser du en leverantörs personuppgiftsbiträdesavtal för just biträdesavtalet.

Leverantörens egna leverantörer. De “specifika sårbarheterna” i artikel 21.3 omfattar var uppgifterna ligger och vem mer som rör dem. Listan över underbiträden, med länder, hör hemma här.

Säkerhetsåtaganden och deras bevis. Kryptering, MFA, loggning, säkerhetskopior, penetrationstester, certifieringar — vart och ett med sin källa. “Praxis” i artikel 21.3 betyder vad ni kan visa, inte vad ni fick höra på ett säljmöte.

Kontakter och SLA-villkor. Supportvägen, incidentvägen, tiderna, tillgänglighetsåtagandet och krediterna. Vid en incident är det detta ni behöver först — se SLA för små företag.

Vad ni frågade och vad de svarade. Fynd från er läsning är frågor till leverantören; leverantörens svar, daterade, stänger dem eller håller dem öppna.

Ändringar. Vad som ändrats i varje dokument, när, om det var väsentligt, vem som granskade. Ett register som bara visar nuläget kan inte visa att granskningen faktiskt sker.

Beslutet. Godkänd, godkänd med villkor, under granskning, utbytt — av vem och när. Det är den rad ledningsorganet står bakom enligt artikel 20.1.

Vad en kund som omfattas kommer att fråga er

När er kund är NIS2-entiteten är registret svaret på dess formulär. Den kommer att fråga efter era underbiträden och deras länder, era säkerhetsåtgärder med bevis, er incidentfrist och kontaktväg, er kontinuitetsplanering, er utvecklingspraxis och om ni bedömer era egna leverantörer. Den sista frågan är den små företag misslyckas med: kundens skyldighet enligt artikel 21.3 sträcker sig genom er till era leverantörer, och “vi använder välrenommerade leverantörer” är ingen bedömning. Ett register med raderna ovan svarar på den med en mening och en skärmbild.

Vad registret inte är

Det är inget avtalsarkiv; era påskrivna avtal ligger i era egna handlingar, och registret håller vad de säger och var. Det är inget efterlevnadsintyg för någon leverantör; en rad som lyder “biträdesavtal läst 2026-09-24, incidentfrist 48 timmar, radering inom 30 dagar, underbiträden i DE och IE” anger fakta, och beslutet att fortsätta använda leverantören är ert. Och det blir aldrig färdigt: artikel 21.2 f kräver “policyer och förfaranden för att bedöma effektiviteten” av åtgärderna, vilket för ett register betyder att läsa om, kontrollera om och besluta om enligt schema.

Så gör Maditon

Leverantörsregistret är där varje Maditon-konto börjar. Ni lägger till en leverantör och adresserna till dess dokument; Maditon hämtar dem, läser dem, citerar stycket varje fakta vilar på och listar vad ett dokument av den typen är skyldigt att ange och inte anger. Leverantörer länkas till era system och tjänster, och varje system bär sina egna dokument och sin supportnotering. Vyn SLA och kontakt visar, för varje leverantör, vad den lovat och vem som ska ringas, med dokumentet och datumet varje värde kom ur. Ändringar kommer i ett dagligt mejl. Ett PDF-paket lägger ett system med dess leverantörer, eller hela registret, på papper för en kund, en revisor eller den dag ni inte har någon åtkomst alls. Varje läsning är ett utkast tills en namngiven användare godkänner den, och varje fynd är en fråga till leverantören, inte en dom.

Se Vad är system och tjänster i Maditon? och Vad innehåller ett PDF-paket från Maditon?, eller bygg den första raden i appen.