Den svaga länken: CISO:ns handbok för ett NIS2-anpassat program för riskhantering i leveranskedjan

Larmet verkade harmlöst: en mindre avvikelse från en tredjepartsbaserad övervakningstjänst. För Anya, CISO på ett medelstort logistikföretag, var det den tredje aviseringen på en månad från samma leverantör: “Inloggningsavvikelse upptäckt.” Leverantören, en liten men kritisk leverantör av programvara för fordonsflottehantering, försäkrade att det inte var något. Ett falskt positivt resultat. Men Anya visste bättre. Det här var inte bara tekniska störningar; det var skakningar som signalerade djupare instabilitet i en kritisk del av leveranskedjan. När hennes företag nu klassificerats som en “viktig entitet” enligt NIS2-direktivet kändes dessa skakningar som förskalv inför en jordbävning.

Det gamla sättet att hantera leverantörer, med ett handslag och ett löst formulerat avtal, är definitivt förbi. NIS2 gör det smärtsamt tydligt att en organisations cybersäkerhetsläge bara är så starkt som dess svagaste länk. Den svaga länken finns inte längre “där ute” – den finns i leveranskedjan. Enligt NIS2 är bristande hantering av leverantörsrisker inte bara ett tekniskt förbiseende. Det är ett regulatoriskt hot på styrelsenivå, med operativa, anseendemässiga och finansiella konsekvenser. Anyas problem var inte bara en enskild osäker leverantör. Det var en systemisk sårbarhet invävd i verksamhetens grundstruktur, och revisorerna skulle leta efter den. Hon behövde mer än en snabb åtgärd; hon behövde en handbok.

Den här vägledningen är den handboken. Vi går igenom ett strukturerat arbetssätt för CISO:er, ansvariga för regelefterlevnad och revisorer som vill bygga ett försvarbart program för riskhantering i leveranskedjan över flera regelverk. Genom att använda ett robust ramverk som ISO/IEC 27001:2022 och expertverktyg från Clarysec kan du koppla akuta risker i leveranskedjan till genomförbara metoder som uppfyller NIS2, DORA, GDPR och andra krav.

Riskkravet: hur NIS2 omdefinierar säkerhet i leveranskedjan

NIS2-direktivet omvandlar säkerhet i leveranskedjan från ren bästa praxis till en rättsligt bindande skyldighet. Det kräver ett riskbaserat och löpande arbetssätt för att säkra IKT- och OT-leveranskedjor, utökar omfattningen till många sektorer och gör ledningen direkt ansvarig för brister i efterlevnaden. Detta innebär följande:

• Utökad omfattning: Varje leverantör, underleverantör, molnleverantör och outsourcingpartner som berör din IKT-miljö omfattas.
• Ständig förbättring: NIS2 kräver en levande process för riskbedömning, övervakning och anpassning, inte en engångsgranskning. Processen ska drivas av både interna händelser (incidenter, överträdelser) och externa förändringar (nya lagar, ändringar i leverantörstjänster).
• Obligatoriska kontroller: Incidentrespons, sårbarhetshantering, regelbunden säkerhetstestning och robust kryptering krävs nu i hela leveranskedjan, inte bara inom den egna perimetern.

Detta suddar ut gränserna mellan intern säkerhet och tredjepartsrisk. Leverantörens cyberincident blir din regulatoriska kris. Ett strukturerat ramverk som ISO/IEC 27001:2022 blir nödvändigt eftersom det tillhandahåller de kontroller och processer som behövs för att bygga ett resilient och verifierbart program som uppfyller NIS2:s krav. Resan börjar inte med teknik, utan med en strategi som fokuserar på tre kärnkontroller:

• 5.19 - Informationssäkerhet i leverantörsrelationer: Etablerar det strategiska ramverket för hantering av leverantörsrisker.
• 5.20 - Hantering av informationssäkerhet i leverantörsavtal: Kodifierar säkerhetsförväntningar i rättsligt bindande avtal.
• 5.22 - Övervakning, granskning och ändringshantering av leverantörstjänster: Säkerställer kontinuerlig tillsyn och anpassning under hela leverantörslivscykeln.

När du behärskar dessa tre områden omvandlas leveranskedjan från en källa till oro till en välstyrd, kravuppfyllande och resilient tillgång.

Steg 1: Bygg styrningsgrunden med kontroll 5.19

Anyas första insikt var att hon inte kunde behandla alla leverantörer lika. Leverantören av kontorsmaterial var inte jämförbar med leverantören av den kritiska programvaran för fordonsflottehantering. Det första steget för att bygga ett NIS2-anpassat program är att förstå och klassificera leverantörsekosystemet utifrån risk.

Kontroll 5.19, Informationssäkerhet i leverantörsrelationer, är den strategiska hörnstenen. Den tvingar organisationen att gå bortom en enkel leverantörslista och skapa ett nivåindelat styrningssystem. Processen ska drivas av en tydlig policy som godkänts av styrelsen. Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet kopplar denna aktivitet direkt till organisationens bredare riskhanteringsramverk:

“P6 – Riskhanteringspolicy. Vägleder identifiering, bedömning och riskreducering av risker kopplade till tredjepartsrelationer, inklusive ärvda eller systemiska risker från leverantörsekosystem.” Från avsnittet ‘Relaterade policyer och kopplingar’, policyklausul 10.2.

Denna integrering säkerställer att risker från nedströmsberoenden, eller exponeringar via fjärde part, hanteras som en del av det egna ISMS. Själva klassificeringsprocessen ska vara metodisk. I steg 23 i fasen ‘Revision och förbättring’ vägleder Zenith Blueprint: en revisors 30-stegs färdplan organisationer att klassificera leverantörer utifrån kritiska frågor:

• Hanterar eller behandlar leverantören känslig eller reglerad information?
• Tillhandahåller leverantören infrastruktur eller plattformar som kritisk verksamhet är beroende av?
• Förvaltar eller underhåller leverantören system för din räkning?
• Kan en kompromettering hos leverantören direkt påverka mål för konfidentialitet, riktighet eller tillgänglighet?

Anya använde denna logik för att ompröva leverantören av programvaran för fordonsflottehantering. Leverantören behandlade positionsdata i realtid (känsliga), plattformen var integrerad i den dagliga verksamheten (kritisk infrastruktur), och en kompromettering skulle kunna stoppa leveranser (hög påverkan på tillgänglighet). Omedelbart omklassificerades leverantören från “standardleverantör” till “kritisk högriskleverantör”.

Denna riskbaserade nivåindelning styr nivån på leverantörsgranskning, avtalsmässig stringens och löpande övervakning som krävs. Som vår Zenith Controls: guiden för tvärgående efterlevnad tydliggör ligger detta arbetssätt direkt i linje med förväntningarna i centrala regelverk.

Detta grundläggande steg är inte bara en intern övning; det är fundamentet som hela det försvarbara programmet för säkerhet i leveranskedjan byggs på.

Steg 2: Skapa robusta bindande avtal med kontroll 5.20

När Anya hade identifierat sin högriskleverantör öppnade hon avtalet. Det var en standardmall för upphandling, med en vag sekretessklausul och i princip inget annat om cybersäkerhet. Det innehöll inga specifika säkerhetskontroller, ingen tidsfrist för incidentanmälan och ingen revisionsrätt. I en NIS2-revisors ögon var det värdelöst.

Det är här kontroll 5.20, Hantering av informationssäkerhet i leverantörsavtal, blir kritisk. Den är mekanismen för att omsätta riskerna som identifierats enligt 5.19 till verkställbara avtalsvillkor och rättsligt bindande skyldigheter. Ett avtal är inte bara ett kommersiellt dokument; det är en primär säkerhetskontroll.

Organisationens policyer ska driva denna omställning. Policyn för leverantörssäkerhet och tredjepartssäkerhet fastställer detta som ett centralt mål:

“Anpassa tredjeparts säkerhetskontroller till tillämpliga regulatoriska och avtalsmässiga skyldigheter, inklusive GDPR, NIS2, DORA och ISO/IEC 27001-standarder.” Från avsnittet ‘Mål’, policyklausul 3.6.

Denna klausul omvandlar policyn från en riktlinje till ett direkt uppdrag för upphandlings- och juristfunktionerna. För Anya innebar det att återvända till leverantören för att omförhandla. Det nya avtalstillägget innehöll specifika, icke förhandlingsbara klausuler:

• Incidentanmälan: Leverantören ska rapportera varje misstänkt säkerhetsincident som påverkar företagets data eller tjänster inom 24 timmar, inte “inom rimlig tid”.
• Revisionsrätt: Företaget har rätt att genomföra säkerhetsbedömningar eller begära tredjepartsrevisionsrapporter (till exempel SOC 2 Type II) årligen.
• Säkerhetsstandarder: Leverantören ska följa specifika säkerhetskontroller, till exempel flerfaktorsautentisering för all administrativ åtkomst och regelbunden sårbarhetsskanning av plattformen.
• Hantering av underleverantörer: Leverantören ska redovisa och inhämta föregående skriftligt godkännande för alla egna underleverantörer som ska hantera företagets data.
• Avslutsstrategi: Avtalet ska definiera rutiner för säker återlämning eller förstöring av data vid uppsägning, så att leverantörsavvecklingen blir kontrollerad.

Som Zenith Controls framhåller är denna praxis central i flera ramverk. GDPR:s Article 28(3) kräver detaljerade personuppgiftsbiträdesavtal. DORA:s Article 30 föreskriver en uttömmande lista över avtalsbestämmelser för kritiska IKT-leverantörer. Genom att införa en robust kontroll 5.20 uppfyllde Anya inte bara ISO/IEC 27001:2022; hon byggde samtidigt en försvarbar position för revisioner enligt NIS2, DORA och GDPR.

Steg 3: Vakttornet – kontinuerlig övervakning med kontroll 5.22

Anyas ursprungliga problem, de återkommande säkerhetslarmen, berodde på ett klassiskt misslyckande: “skriv under och glöm”. Ett starkt avtal är värdelöst om det arkiveras och aldrig används igen. Den sista pusselbiten är kontroll 5.22, Övervakning, granskning och ändringshantering av leverantörstjänster. Detta är den operativa kontroll som säkerställer att löftena i avtalet hålls.

Kontrollen omvandlar leverantörshantering från en statisk aktivitet vid leverantörsintroduktion till en dynamisk och löpande process. Enligt Zenith Controls omfattar detta flera sammankopplade aktiviteter:

• Prestationsbedömningar: Regelbundna möten (t.ex. kvartalsvis för högriskleverantörer) för att diskutera prestation mot säkerhetsrelaterade SLA:er, granska incidentrapporter och planera kommande ändringar.
• Granskning av revisionsunderlag: Proaktiv begäran om och analys av leverantörens revisionsrapporter, certifieringar och resultat från penetrationstestning. En revisor kontrollerar om organisationen inte bara samlar in rapporterna, utan även aktivt följer upp och hanterar eventuella avvikelser i dem.
• Ändringshantering: När en leverantör ändrar sin tjänst – genom att migrera till en ny molnleverantör eller införa ett nytt API – ska detta utlösa en säkerhetsgranskning hos er. Det förhindrar att leverantörer omedvetet introducerar nya risker i er miljö.
• Kontinuerlig övervakning: Användning av verktyg och flöden med hotinformation för att hålla sig informerad om leverantörens externa säkerhetsläge. Ett plötsligt fall i säkerhetsbetyg eller nyheter om en incident ska utlösa omedelbar respons.

Denna kontinuerliga loop av övervakning, granskning och anpassning är kärnan i den “löpande riskhanteringsprocess” som NIS2 kräver. Den säkerställer att förtroende aldrig antas; det verifieras kontinuerligt.

Ett praktiskt exempel: checklistan för leverantörsgranskning

För att göra detta praktiskt skapade Anyas team en checklista för de nya kvartalsvisa granskningarna med leverantören av fordonsflottehanteringen, baserad på revisionsmetodiken i Zenith Controls.

Detta enkla verktyg omvandlade samtalet från en allmän avstämning till ett fokuserat, evidensbaserat möte för säkerhetsstyrning och skapade en verifierbar dokumentation av kontinuerlig tillsyn.

Dra gränsen: riskacceptans i en NIS2-värld

Den första incidenten med leverantören tvingade Anya att hantera en grundläggande fråga: vilken risknivå är acceptabel? Även med de bästa avtalen och den bästa övervakningen kommer viss kvarstående risk alltid att finnas. Här är en tydlig, ledningsgodkänd definition av kriterier för riskacceptans icke förhandlingsbar.

I steg 10 i fasen ‘Risk och genomförande’ ger Zenith Blueprint kritisk vägledning i denna fråga. Det räcker inte att säga “vi accepterar låga risker”. Du måste definiera vad det betyder i kontexten av rättsliga och regulatoriska skyldigheter.

“Beakta även rättsliga/regulatoriska krav i era acceptanskriterier. Vissa risker kan vara oacceptabla oavsett sannolikhet på grund av lagstiftning… På motsvarande sätt ställer NIS2 och DORA vissa grundläggande säkerhetskrav – att inte uppfylla dem (även om sannolikheten för en incident är låg) kan innebära en oacceptabel efterlevnadsrisk. Integrera dessa perspektiv: t.ex. “Varje risk som kan leda till bristande efterlevnad av tillämpliga lagar (GDPR osv.) är inte acceptabel och ska riskreduceras.””

Detta förändrade spelplanen för Anya. Hon arbetade med jurist- och upphandlingsteamen för att uppdatera deras riskhanteringspolicy. De nya kriterierna angav uttryckligen att varje kritisk leverantör som inte uppfyller de grundläggande säkerhetskrav som NIS2 kräver innebär en oacceptabel risk och ska utlösa en omedelbar riskbehandlingsplan. Det tog bort otydligheten i beslutsfattandet och skapade en tydlig styrningsutlösare. Som anges i policyn för leverantörssäkerhet och tredjepartssäkerhet:

“Högriskundantag (t.ex. leverantörer som hanterar reglerade data eller stödjer kritiska system) ska godkännas av informationssäkerhetschefen, juridik och upphandlingsledningen samt registreras i ISMS-undantagsregister.” Från avsnittet ‘Riskbehandling och undantag’, policyklausul 7.3.

Revisorn är här: att hantera granskning ur flera perspektiv

Sex månader senare, när internrevisorerna kom för att genomföra en bedömning av beredskap för NIS2, var Anya förberedd. Hon visste att de skulle betrakta hennes program för leveranskedjan ur flera perspektiv.

• ISO/IEC 27001:2022-revisorn: Denna revisor fokuserade på process och underlag. De begärde leverantörsförteckningen, verifierade riskkategoriseringen, gjorde stickprov på avtal för specifika säkerhetsklausuler och granskade mötesprotokollen från de kvartalsvisa granskningsmötena. Hennes strukturerade arbetssätt, byggt på kontrollerna 5.19, 5.20 och 5.22, gav ett tydligt revisionsspår.

• COBIT 2019-revisorn: Med ett styrningsperspektiv ville revisorn se kopplingar till verksamhetsmål. De frågade hur leverantörsrisk rapporterades till den verkställande riskkommittén. Anya presenterade sitt riskregister och visade hur leverantörens riskklassning fastställdes och hur den mappades mot företagets övergripande riskaptit.

• NIS2-bedömaren: Denna person hade ett skarpt fokus på systemisk risk för samhällsviktiga tjänster. Det räckte inte att se avtalet; bedömaren ville veta vad som skulle hända om leverantören blev helt otillgänglig. Anya gick igenom sin plan för verksamhetskontinuitet, som nu innehöll ett avsnitt om avbrott hos kritisk leverantör, framtagen i linje med principerna i ISO/IEC 22301:2019.

• GDPR-revisorn: När revisorn såg att leverantören behandlade positionsdata fokuserade hen omedelbart på dataskydd. Revisorn begärde personuppgiftsbiträdesavtal och underlag för hennes leverantörsgranskning som visade att leverantören gav “tillräckliga garantier” enligt Article 28. Eftersom hennes process integrerade integritetsskydd från början var personuppgiftsbiträdesavtalet robust.

Detta revisionsperspektiv från flera vinklar visar att ett väl infört ISMS baserat på ISO/IEC 27001:2022 inte bara uppfyller en standard. Det skapar en resilient och försvarbar position i hela det regulatoriska landskapet. Tabellen nedan sammanfattar hur dessa steg skapar verifierbart underlag för varje granskning.

Din handbok för åtgärder

Anyas berättelse är inte unik. CISO:er och ansvariga för regelefterlevnad i hela EU står inför samma utmaning. Hotet om regulatoriska sanktionsavgifter och det personliga ansvar som NIS2 inför gör leverantörsrisk till en affärskritisk fråga. Den goda nyheten är att vägen framåt är tydlig. Genom att använda det strukturerade, riskbaserade arbetssättet i ISO/IEC 27001:2022 kan du bygga ett program som både uppfyller kraven och är genuint resilient.

Vänta inte på att en incident ska tvinga fram åtgärder. Börja bygga ditt NIS2-anpassade ramverk för leveranskedjan redan idag:

1. Etablera styrning: Använd Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet - SME eller företagsmallar för att definiera era spelregler.
2. Känn ditt ekosystem: Tillämpa klassificeringskriterierna från Zenith Blueprint för att identifiera och risknivåindela kritiska högriskleverantörer.
3. Stärk dina avtal: Granska befintliga leverantörsavtal mot kraven i kontroll 5.20 i ISO/IEC 27001:2022 och använd vägledningen för tvärgående efterlevnad i Zenith Controls för att uppfylla förväntningarna i NIS2, DORA och GDPR.
4. Inför kontinuerlig övervakning: Schemalägg den första kvartalsvisa säkerhetsgranskningen med den mest kritiska leverantören och använd checklistan som vägledning. Dokumentera alla iakttagelser i ISMS.
5. Förbered revisionsbevis: Sammanställ exempelavtal, granskningsprotokoll, incidentloggar och riskbedömningar som mappas mot kärnkontrollerna för varje kritisk leverantör.

Leveranskedjan behöver inte vara din svagaste länk. Med rätt ramverk, processer och verktyg kan du omvandla den till en styrka och en hörnsten i cybersäkerhetsstrategin.

Redo att bygga en leveranskedja som uppfyller både tillsynsmyndigheternas och styrelsens krav? Ladda ner Clarysec Zenith Blueprint redan idag för att påskynda resan mot efterlevnad och resiliens.