Guide · 8 min
NIS2 Art. 21(2): säkerhetschecklista för leverantörer
Ett fungerande manus för upphandlings- och säkerhetsteam: för introduktion av en ny leverantör likaväl som för den årliga granskningen. För var och en av NIS2-artikel 21(2):s sex leveranskedjerelevanta klausuler: vad du ska fråga, varför det spelar roll, vilket bevis du ska begära och hur du reagerar när svaret brister.
Kontrollera din domän nu
Se vad som är offentligt synligt om din organisations säkerhet, utan registrering.
Denna snabbkontroll granskar:
- HTTPS nåbart
- HSTS aktiverat
- HTTP → HTTPS-omdirigering
- SPF konfigurerat
- DMARC framtvingat
- E-post (MX) konfigurerat
Den fullständiga rapporten lägger till ransomware, dark web, certifikat, företagsinformation och 100+ andra kontroller.
Viktigaste punkterna
- Sex underklausuler i artikel 21(2) bär större delen av leveranskedjans tyngd: här är vad du ska fråga om var och en och dokumentet som bevisar det.
- Hälften av dem är tekniska och förändras utan förvarning, så de behöver löpande kontroll snarare än en rad i ett årligt frågeformulär.
- En brist är inte en dom. Ett dokumenterat, ägt åtgärdsbeslut är det som gör din position försvarbar inför en revisor.
Artikel 21(2)(d) gör bedömningen av dina leverantörers säkerhet till en del av din egen riskhantering, och det är inte en engångsåtgärd. Plikten omfattar både leverantören du är på väg att skriva avtal med och den du har arbetat med i åratal. En årlig granskning är golvet, inte taket. Det svåra är att måttet (”lämpliga åtgärder”) skalar med risken och står aldrig still, så en bedömning som var ren på våren kan säga mycket lite på hösten.
Det följande går igenom de sex underklausuler i artikel 21(2) som bär mest leveranskedjetyngd. Var och en presenteras som den faktiskt är användbar i rummet: vad du ska fråga, varför det spelar roll och vilket dokument du ska begära som bevis. Använd det som manus för introduktionssamtalet likaväl som för den årliga granskningen, och läs de tekniska klausulerna som sådant som ska verifieras löpande, inte en gång.
En notering om omfattning. Detta är vägledning, inte ett juridiskt utlåtande: din behöriga myndighet eller revisor kan förvänta sig mer givet din sektor och storlek, och avtalsformuleringar är värda en jurists öga. De nämnda tidsramarna (patchfönster och liknande) är rimliga riktvärden, inte lagstadgade NIS2-frister.
De sex underklausulerna, i den ordning det är värt att fråga dem:
Art. 21(2)(a)Riskhantering
Börja med skillnaden mellan en leverantör som hanterar cyberrisk som en stående disciplin och en som rusar runt en gång om året. Ett dokumenterat ledningssystem för informationssäkerhet (ISO 27001 är den rena förkortningen, men en skriftlig ISMS-policy duger) visar att processen finns; den mer avslöjande frågan är när ledningen eller styrelsen senast granskade den, och om kritiska system och data faktiskt har inventerats och klassificerats. Begär policyn eller certifikatet och notera datumet för den senaste granskningen: ett program som ingen har öppnat på två år är ett sådant bara till namnet.
Art. 21(2)(b)Incidenthantering
Om denna leverantör är betydande nog att deras intrång kan störa din tjänst, startar deras incident din rapporteringsklocka enligt artikel 23, och du klarar den bara om de berättar för dig snabbt. God vilja bär inte det; avtalet måste: ett definierat tidsfönster för att meddela dig om en säkerhetsincident, en namngiven kontakt som svarar dygnet runt, och bakom den en testad responsplan snarare än ett dokument ingen har övat. Begär en sammanfattning av incidentresponsplanen och gör 24-timmarsmeddelandet till en skriftlig avtalsklausul, inte en rad i ett mejl.
Art. 21(2)(d)Leveranskedja
Din exponering sträcker sig förbi leverantören du skrev avtal med till dem som denne är beroende av: fjärdepartsrisken. En kompetent leverantör kan namnge de underleverantörer som rör dina data eller system, håller dem till säkerhetsvillkor inskrivna i sina egna avtal snarare än en vag hänvisning till ”branschstandarder”, och omprövar dem minst årligen. Fråga om de kan ta fram ett underleverantörsregister och beskriva hur de granskar dessa parter; en leverantör som inte kan namnge sina kritiska fjärdeparter har just berättat något värt att veta.
Art. 21(2)(e)Upphandling och utveckling
Kända, oåtgärdade sårbarheter och programvara i slutet av livscykeln hör till de mest använda vägarna in, så leverantören bör visa att sårbarhetshanteringen är verklig snarare än önskad. Rimliga riktvärden: inget bortom supportslut körs i produktion, kritiska brister (CVSS 9.0 och högre) åtgärdas inom ungefär en månad från offentliggörandet, och allt på CISA:s katalog över kända utnyttjade sårbarheter behandlas som ett nödläge. Begär en beskrivning av patchprocessen och en färsk sårbarhetsögonblicksbild: avståndet mellan policyn och den senaste skanningen är oftast där sanningen bor.
Art. 21(2)(h)Kryptografi
Detta är den mest externt synliga klausulen, och den som glider iväg tystast. Utgångna eller självsignerade TLS-certifikat, sajter som inte tvingar HTTPS och e-postautentisering som lämnats halvkonfigurerad är alla vanliga, ändras utan förvarning och är alla kontrollerbara utifrån. Ribban är osexig: giltiga certifikat överallt, HTTPS framtvingat på varje sajt och API, och SPF, DKIM och DMARC faktiskt konfigurerade (hardfail, signerat, minst en karantänpolicy) snarare än lämnade på sina standardvärden. Begär certifikathanteringsprocessen och en DMARC- eller DNS-avläsning.
Art. 21(2)(i)/(j)Åtkomstkontroll och autentisering
Stulna inloggningsuppgifter är fortfarande det vanligaste sättet för en angripare att få fotfäste, så en leverantör behöver visa både att missbruk är svårt och att det skulle upptäckas snabbt. I praktiken betyder det multifaktorautentisering framtvingad på varje kritiskt system och administratörskonto utan tysta undantag, övervakning av läckta inloggningsuppgifter som dyker upp i intrångs- och dark web-data, och vanan att rotera varje exponerad inloggning omedelbart och skriva ner incidenten. Be att få se MFA-tillämpningspolicyn och hur övervakningen av läckta inloggningsuppgifter sköts.
När en leverantör brister
En enskild brist är sällan ett skäl att gå; en behörig myndighet (och din egen styrelse) letar efter bevis på att du märkte den och fattade ett medvetet, ägt beslut om den. Anpassa reaktionen efter hur mycket som saknas, och var.
En eller två brister: dokumentera och acceptera
Registrera dem i ditt leverantörsregister, be om en åtgärdsplan inom cirka 90 dagar och följ upp vid nästa granskning. En noterad, accepterad risk är en försvarbar position; en bortglömd är det inte.
Tre till fem brister, eller någon brist i incidenthantering: skärp bevakningen
Flytta leverantören till en högre risknivå, be om en skriftlig åtgärdsplan med datum och överväg att begränsa deras åtkomst till dina mest kritiska system tills bristerna är slutna.
Sex eller fler brister, eller en kritisk teknisk sårbarhet: eskalera
Ta det till din CISO eller ledning, väg de avtalsmässiga medel du faktiskt har, och (om leverantören kan nå produktionsdata eller -system) överväg att stänga av den åtkomsten tills bilden är klar.
Se hur du och dina leverantörer faktiskt presterar
Gratis · inget kreditkort · utan tidsgräns
Vad du inte kan göra för hand
Flera av dessa kontroller är tekniska, och de förfaller utan att någon skickar dig ett meddelande: ett certifikat går ut, en inloggningsuppgift dyker upp i en läcka, en leverantör hamnar på en ransomware-offerlista. Ett frågeformulär som besvaras en gång om året ser inget av det: vilket är just avståndet mellan en pappersgranskning och den löpande aktsamhet som måttet ”lämpliga åtgärder” förväntar sig.
norppa.io kör den tekniska halvan av denna lista varje dag, för varje leverantör du lägger till:
- Kryptografi (h): TLS-certifikats giltighet och HTTPS-framtvingande, SPF/DKIM/DMARC-konfiguration, DNSSEC
- Åtkomst och autentisering (i): anställdas och kunders inloggningsuppgifter som dyker upp i intrångs- och dark web-data
- Upphandling och utveckling (e): katalognoteringar över utnyttjade sårbarheter och allvarlighetspoängsatta sårbarhetsfynd
- Incidenthantering (b): förekomster på ransomware-offerlistor, med en varning i samma stund en leverantör dyker upp
Underklausulerna på processnivå (riskhantering, incidenthantering och styrning av leveranskedjan) är precis vad självbedömningsformuläret är till för; du kan skicka det till en leverantör direkt från portalen och läsa deras svar bredvid de tekniska fynden.