NIS2-leverantörsavtal med ISO 27001-underlag

Klockan är 07:40 en måndagsmorgon. Informationssäkerhetschefen för en molnansluten logistikplattform öppnar ett e-postmeddelande från en Managed Detection and Response (MDR)-leverantör. Meddelandet är kort, försiktigt och obekvämt: leverantören har upptäckt misstänkt åtkomst till en supportmiljö som används av flera kunder. Detaljerna är begränsade. Leverantören utlovar en uppdatering ”så snart det är praktiskt möjligt”.

Klockan 08:15 frågar efterlevnadsansvarig om detta kan utlösa rapportering enligt NIS2. Klockan 08:40 letar upphandling efter avtalet. Klockan 09:10 vill styrelsesekreteraren ha en lägesbild om ledningens ansvarsskyldighet. Klockan 10:00 frågar juridik om avtalet innehåller avisering inom 24 timmar, revisionsrätt, kontroller för underleverantörer, åtkomst till underlag, skyldigheter avseende verksamhetskontinuitet, återlämning av data och bestämmelser om radering.

Ingen vill upptäcka under en pågående incident att ett avtal med en kritisk leverantör bara anger ”rimliga säkerhetsåtgärder”.

Det är här NIS2-klausuler i leverantörsavtal upphör att vara juridiska standardformuleringar och blir operativa kontroller. För väsentliga och viktiga entiteter är leverantörsstyrning numera en del av styrelsens ansvarsskyldighet, tillsynsunderlag, incidentberedskap, kundförsäkran, efterlevnad av dataskyddskrav och resiliensplanering. Ett undertecknat avtal räcker inte. Organisationen måste kunna visa att leverantörsrisker identifieras, godkänns, behandlas, övervakas och styrks med underlag.

Clarysecs arbetssätt utgår från en enkel princip: om leverantörsklausulen inte kan övervakas, styrkas med underlag och testas är den inte en kontroll.

Zenith Blueprint: en revisors 30-stegs färdplan placerar leverantörsrelationer i fasen Controls in Action, steg 23, där avtal, övervakning, onboarding, omprövning och revisionsbevis omsätts i praktiskt ISMS-arbete. Zenith Controls: vägledningen för efterlevnad av flera regelverk mappar därefter leverantörskontroller i ISO/IEC 27002:2022 mot NIS2, DORA, GDPR, NIST, COBIT 2019, stödjande ISO-standarder och revisionsmetoder.

Resultatet är en modell för leverantörsstyrning som upphandling, juridik, säkerhet, dataskydd och styrelse kan använda gemensamt.

Varför NIS2 gör leverantörsavtal till underlagsposter

NIS2 Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner åtgärder för cybersäkerhetsriskhantering, övervakar genomförandet och hålls ansvariga för överträdelser. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och säkert underhåll, effektivitetsbedömning, cyberhygien, kryptografi, personalsäkerhet, åtkomstkontroll, tillgångshantering och MFA när det är lämpligt.

Article 21(3) gör leverantörsgranskning uttrycklig. Organisationer måste beakta sårbarheter som är specifika för direkta leverantörer och tjänsteleverantörer, den övergripande kvaliteten på produkter och cybersäkerhetspraxis samt rutiner för säker utveckling.

Den formuleringen skapar en praktisk skyldighet: leverantörsrelationer måste vara riskbaserade, avtalsmässigt verkställbara och granskningsbara. Ett leverantörsfrågeformulär som ligger i en mapp räcker inte. Ett generiskt avtal utan tidsfrister för incidenter, utan rätt till underlag och utan insyn i underleverantörer räcker inte. En leverantörscertifiering som ingen har granskat räcker inte.

ISO/IEC 27001:2022 ger den operativa modellen. Klausulerna 4.1 till 4.4 kräver att organisationen förstår kontext, intressenter, rättsliga och avtalsmässiga skyldigheter, ISMS-omfattning och beroenden. Klausulerna 5.1 till 5.3 kräver ledarskap, policy, roller och rapportering. Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling och Statement of Applicability. Klausulerna 8.1 till 8.3 kräver operativ styrning, upprepade riskbedömningar och dokumenterade resultat.

För leverantörsstyrning är de viktigaste kontrollerna i ISO/IEC 27002:2022 Annex A:

• A.5.19 Informationssäkerhet i leverantörsrelationer
• A.5.20 Hantering av informationssäkerhet i leverantörsavtal
• A.5.21 Hantering av informationssäkerhet i IKT-leveranskedjan
• A.5.22 Övervakning, granskning och ändringshantering av leverantörstjänster
• A.5.24 Planering och förberedelse för incidenthantering
• A.5.25 Bedömning och beslut avseende informationssäkerhetshändelser
• A.5.26 Respons på informationssäkerhetsincidenter
• A.5.27 Lärande från informationssäkerhetsincidenter
• A.5.28 Insamling av bevisning
• A.5.29 Informationssäkerhet vid störning
• A.5.30 IKT-beredskap för verksamhetskontinuitet
• A.5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav
• A.5.34 Integritet och skydd av PII
• A.8.8 Hantering av tekniska sårbarheter
• A.8.13 Säkerhetskopiering av information
• A.8.15 Loggning
• A.8.16 Övervakningsaktiviteter
• A.8.24 Användning av kryptografi
• A.8.32 Ändringshantering

Nyckeln är ägarskap. En klausul har begränsat värde om ingen äger risken, ingen granskar underlaget, ingen följer upp undantag och ingen eskalerar bristande efterlevnad.

Enterprise Policy för leverantörssäkerhet och tredjepartssäkerhet gör detta uttryckligt:

”Rätt att granska, inspektera och begära säkerhetsunderlag”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.4.

För små och medelstora företag anger Third-Party and Supplier Security Policy-sme samma praktiska förväntan:

”Revisionsrätt eller tillgång till underlag för regelefterlevnad”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.4.

Skillnaden är viktig. En mindre organisation kanske inte kan granska varje stor molnleverantör på plats, men den kan kräva tillgång till försäkransunderlag, exempelvis omfattning för ISO/IEC 27001:2022-certifiering, SOC-rapporter, sammanfattningar av penetrationstester, intyg om åtgärdande av sårbarheter, incidentsammanfattningar, testrapporter för verksamhetskontinuitet och bekräftelser på dataradering.

De tre kontrollernas ryggrad för NIS2-leverantörsförsäkran

I Clarysecs modell för efterlevnad av flera regelverk utgör tre kontroller i ISO/IEC 27002:2022 ryggraden i NIS2-leverantörsstyrning: 5.19, 5.20 och 5.22.

A.5.19 identifierar leverantörsrisken

Kontroll A.5.19, informationssäkerhet i leverantörsrelationer, är grunden. Den kräver att organisationer skyddar information och tillgångar som nås, behandlas, lagras eller hanteras av leverantörer.

Zenith Controls kategoriserar detta som en förebyggande kontroll som omfattar konfidentialitet, riktighet och tillgänglighet, med cybersäkerhetskonceptet ”Identifiera” och den operativa förmågan ”säkerhet i leverantörsrelationer”. Den kopplar A.5.19 till A.5.20, A.5.21, A.5.14, A.5.36 och A.5.10. I praktiken innebär det att organisationen identifierar leverantörsrisker, definierar säkerhetsförväntningar, styr exponering i IKT-leveranskedjan, skyddar informationsöverföring, övervakar efterlevnad och utvidgar krav på godtagbar användning till externa parter.

För NIS2 mappar detta direkt mot Article 21(2)(d) om säkerhet i leveranskedjan och Article 21(3) om leverantörsgranskning. För GDPR stödjer det kravet att använda personuppgiftsbiträden som ger tillräckliga garantier. För DORA stödjer det hantering av IKT-tredjepartsrisk, leverantörsgranskning före avtal, kritikalitetsbedömning, koncentrationsrisk och livscykeltillsyn.

A.5.20 gör kravet bindande

Kontroll A.5.20, hantering av informationssäkerhet i leverantörsavtal, omvandlar säkerhetsförväntningar till avtalsmässiga skyldigheter. Zenith Controls beskriver relationen mellan A.5.19 och A.5.20 tydligt:

”5.20 fungerar som den avtalsmässiga formaliseringen av de säkerhetsbehov och risker som identifieras enligt 5.19. Medan 5.19 handlar om att bedöma tredjepartsrisker och definiera säkerhetsförväntningar säkerställer 5.20 att dessa förväntningar blir rättsligt bindande genom avtal eller servicenivåavtal (SLA). Utan 5.20 skulle de säkerhetsåtgärder som identifieras i 5.19 sakna möjlighet att göras gällande.”

Det är här NIS2-riskbeslut blir klausuler: incidentanmälan, revisionsrätt och rätt till underlag, kryptering, åtkomstkontroll, sårbarhetshantering, godkännande av underleverantörer, säker överföring, kontinuitet, regulatoriskt samarbete, exitstöd och dataradering.

A.5.22 visar att avtalet är levande

Kontroll A.5.22, övervakning, granskning och ändringshantering av leverantörstjänster, förhindrar att leverantörsförsäkran blir en engångsaktivitet vid onboarding. Zenith Controls kopplar A.5.22 till A.5.19 och A.5.20, men också till A.5.29 informationssäkerhet vid störning, A.8.8 hantering av tekniska sårbarheter, A.5.36 efterlevnad av policyer, regler och standarder för informationssäkerhet, A.5.15 åtkomstkontroll samt A.8.27 säker systemarkitektur och tekniska principer.

Det spelar roll eftersom leverantörstjänster förändras. Datalagringsplatser förändras. Underbiträden förändras. Sårbarheter uppstår. Certifieringar löper ut. Incidentmönster växer fram. En leverantör som var godtagbar förra året kan vara för riskfylld i dag.

Vad NIS2-klausuler i leverantörsavtal bör omfatta

Zenith Blueprint, fasen Controls in Action, steg 23, ger en praktisk uppsättning områden för leverantörsavtal:

”Viktiga områden som normalt hanteras i leverantörsavtal omfattar:

✓ Sekretesskyldigheter, inklusive omfattning, varaktighet och begränsningar för utlämnande till tredje part; ✓ ansvar för åtkomstkontroll, exempelvis vem som får åtkomst till dina data, hur autentiseringsuppgifter hanteras och vilken övervakning som finns; ✓ tekniska och organisatoriska åtgärder för dataskydd, kryptering, säker överföring, säkerhetskopiering och åtaganden om tillgänglighet; ✓ tidslinjer och protokoll för incidentrapportering, ofta med definierade tidsfrister (t.ex. ”avisera inom 24 timmar”); ✓ revisionsrätt, inklusive frekvens, omfattning och tillgång till relevant underlag (t.ex. penetrationstestrapporter, SoA, certifieringar); ✓ kontroller för underleverantörer, med krav på att leverantören vidareför likvärdiga säkerhetsskyldigheter till sina nedströms partner; ✓ bestämmelser vid avtalets upphörande, exempelvis återlämning eller förstöring av data, återställning av tillgångar och avaktivering av konton.”

Från fasen Controls in Action, steg 23: organisatoriska kontroller.

En stark NIS2-leverantörsklausul är tillräckligt specifik för att kunna testas. ”Leverantören ska upprätthålla lämplig säkerhet” är svagt. ”Leverantören ska avisera kundens säkerhetskontakt inom 24 timmar vid bekräftade eller misstänkta incidenter som påverkar kundsystem, kunddata, tjänstetillgänglighet eller regulatoriska rapporteringsskyldigheter” är granskningsbart.

Incidentklausuler måste matcha NIS2:s rapporteringstidsfrister

NIS2 Article 23 skapar en stegvis rapporteringsmodell för betydande incidenter: en tidig varning inom 24 timmar från kännedom, en incidentanmälan inom 72 timmar, mellanliggande rapporter när så begärs och en slutrapport inom en månad från incidentanmälan. En betydande incident är en incident som har orsakat eller kan orsaka allvarlig driftstörning, ekonomisk förlust eller betydande materiell eller immateriell skada för andra.

Leverantörsavtal måste stödja den tidslinjen. Om en kritisk leverantör av hanterade tjänster tar fyra dagar på sig att bekräfta om kundmiljöer påverkats kan kunden missa sitt eget regulatoriska tidsfönster.

Enterprise Policy för leverantörssäkerhet och tredjepartssäkerhet kräver:

”Tidsfrister för incidentanmälan (t.ex. inom 24 eller 72 timmar, beroende på kritikalitet och regulatoriska krav)”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.3.

SME Third-Party and Supplier Security Policy-sme kräver också definierade tidslinjer för incidentanmälan från avsnittet ”Styrningskrav”, policyklausul 5.3.3.

För personuppgiftsincidenter kopplar Enterprise Policy för hantering av PII-incidenter och personuppgiftsincidenter samman cybersäkerhetsrapportering, finanssektorsrapportering samt rapportering till kunder och tjänstemottagare:

”[Villkorligt] Dataskyddsansvarig / PIMS-ansvarig SKA samordna all rapportering av incidenter som krävs till sektorsmyndighet, inom cybersäkerhet, inom finanssektorn, till kund eller till tjänstemottagare när en personuppgiftsincident med hög påverkan uppfyller en tillämplig rapporteringströskel, och SKA registrera myndighet, mottagare, tidslinje, inlämning och underlag för bekräftelse i REG01 och REG10.”

Från avsnittet ”Avisering och kommunikation”, policyklausul 4.4.6.

Detta är moget NIS2-underlag: inte bara ett aviseringsmeddelande, utan en post över myndighet, mottagare, tidslinje, inlämning, bekräftelse, påverkan, rotorsak och uppföljningsåtgärder.

Anpassning till dataskydd och DORA utan dubbla leverantörsprogram

Många NIS2-leverantörer behandlar också personuppgifter. GDPR Article 28 kräver att personuppgiftsansvariga använder personuppgiftsbiträden som ger tillräckliga garantier och att biträdets skyldigheter fastställs i ett skriftligt avtal. GDPR Article 5 kräver ansvarsskyldighet för säker behandling med rättslig grund. GDPR:s krav vid personuppgiftsincidenter kräver också snabbt samarbete när leverantörsincidenter påverkar personuppgifter.

Enterprise Policy för hantering av personuppgiftsbiträden, underbiträden och tredje parter inom dataskydd anger godkännandegrinden:

”[Båda] Leverantörs-/upphandlingsansvarig SKA säkerställa att avtal med personuppgiftsbiträden och underbiträden omfattar dataskyddsstöd, säkerhetsförsäkran, incidentgränssnitt via PII15, återlämning eller radering via PII10, överföringskoppling via PII13 samt samarbete vid revision eller försäkran före godkännande.”

Från avsnittet ”Kontroller för avtal och dokumenterade instruktioner”, policyklausul 4.3.6.

Den kräver också granskning av underlag före godkännande:

”[Alla] Informationssäkerhetsansvarig SKA granska säkerhetsförsäkransunderlag för varje relation med personuppgiftsbiträde, underbiträde eller tredje part med PII-åtkomst eller drift innan godkännande, och SKA registrera resultatet i REG08 eller REG12.”

Från avsnittet ”Leverantörsgranskning och riskbedömning”, policyklausul 4.2.2.

DORA tillför ytterligare ett lager när leverantören betjänar en finansiell entitet. DORA Articles 28 to 30 kräver styrning av IKT-tredjepart, register över IKT-tjänsteavtal, riskbaserad leverantörsgranskning, kritikalitetsbedömning, analys av koncentrationsrisk, revisions- och inspektionsrätt, rätt att säga upp avtalet, exitstrategier och obligatoriska avtalsbestämmelser. Article 30 är särskilt relevant eftersom den kräver avtalsinnehåll om tjänstebeskrivningar, platser, dataskydd, åtkomst och återställning, servicenivåer, incidentstöd, samarbete med myndigheter, revisionsrätt, underleverantörer, beredskapsåtgärder och övergångsstöd.

Det praktiska svaret är inte tre separata leverantörsprogram för NIS2, GDPR och DORA. Det är en harmoniserad leverantörsmodell för underlag, mappad mellan ramverk.

NIST CSF 2.0 är användbart eftersom dess GOVERN-funktion kräver förståelse för beroenden, rättsliga skyldigheter, avtalsmässiga skyldigheter, riskaptit, policyer, ansvarsskyldighet och tillsyn. Leveranskedjekategorin GV.SC omfattar leverantörsroller, kritikalitet, avtalskrav, leverantörsgranskning, övervakning, inkludering i incidenthantering, livscykelövervakning och bestämmelser vid relationens upphörande.

Ett Clarysec-arbetsflöde för onboarding av en kritisk leverantör

Anta att ni introducerar en leverantör av hanterade säkerhetstjänster som ska övervaka slutpunktstelemetri, ta emot larm som innehåller användaridentifierare och stödja incidenttriage för en organisation som omfattas av NIS2.

Steg 1: klassificera leverantören

Registrera leverantören i ert leverantörsregister med tjänstebeskrivning, system och data som nås, PII-involvering, stöd för väsentliga eller viktiga tjänster, privilegierad åtkomst, länder för tjänsteleverans, underleverantörer, fjärdepartsberoenden, kritikalitetsklassning, riskägare, upphandlingsansvarig och granskare inom informationssäkerhet.

Detta genomför ISO/IEC 27001:2022-klausulerna 4.2, 4.3, 6.1.2 och 8.1 genom att koppla samman krav från intressenter, beroenden, riskägarskap och operativ styrning.

Steg 2: mappa risken mot SoA

I Zenith Blueprint, fasen Riskhantering, steg 13, rekommenderar Clarysec att regelverk korsrefereras i riskregistret eller SoA:

”Korsreferera regelverk: Om vissa kontroller införs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du ange detta antingen i riskregistret (som en del av motiveringen för riskpåverkan) eller i SoA-anteckningarna.”

Från fasen Riskhantering, steg 13: planering av riskbehandling och Statement of Applicability.

För MSSP:n bör åtminstone A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 till A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 och A.8.24 ingå.

Steg 3: kräv bindande klausuler

Använd en säkerhetsbilaga för leverantörer som kräver initial incidentavisering inom 24 timmar, detaljerad uppdatering inom 72 timmar, slutlig incidentrapportering, MFA för privilegierad åtkomst, personliga användarkonton med namngiven användare, kontroller för underleverantörer, säker överföring, kryptering, försäkransunderlag, regulatoriskt samarbete, BCP- och DR-underlag, exitstöd, återlämning eller radering av data samt återkallelse av åtkomst.

Enterprise Policy för hantering av risker kopplade till leverantörsberoenden anger kontinuitetskravet:

”I tillämpliga fall, ett krav på att leverantören ska upprätthålla egna planer för verksamhetskontinuitet (BCP/DRP) och incidenthanteringsplaner, testa dem och på begäran tillhandahålla sammanfattningar eller testrapporter till oss.”

Från avsnittet ”Krav för genomförande”, policyklausul 6.8.4.

Steg 4: bygg underlagspaketet för försäkran

Före godkännande bör ni begära det signerade avtalet, SLA, säkerhetsbilaga, omfattning för ISO/IEC 27001:2022-certifiering eller likvärdig försäkran, SOC-rapport där sådan finns, ledningssammanfattning av penetrationstest, sammanfattning av sårbarhetshantering, sammanfattning av incidenthanteringsprocedur, sammanfattning av BCP- eller DR-test, intyg om åtkomstkontroll och MFA, lista över underleverantörer, procedur för dataradering och avslut samt DPA där PII behandlas.

SME Third-Party and Supplier Security Policy-sme gör grundläggande avtalsunderlag mätbart:

”Undertecknade avtal och SLA:er”

Från avsnittet ”Efterlevnad och tillämpning”, policyklausul 8.3.2.1.

Den identifierar även återkommande leverantörsunderlag:

”Giltiga säkerhetscertifieringar eller uppdaterat kontrollunderlag”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.1.2.

För bredare leverantörsgranskning anger Policy för revision och regelefterlevnadsövervakning:

”Leverantörsgranskning ska omfatta granskning av certifieringar (t.ex. ISO 27001, SOC 2), säkerhetsfrågeformulär och incidentposter.”

Steg 5: övervaka baserat på kritikalitet

Enterprise Policy för hantering av personuppgiftsbiträden, underbiträden och tredje parter inom dataskydd kräver kvartalsvis övervakning av högriskrelationer som rör PII:

”[Alla] Leverantörs-/upphandlingsansvarig SKA kvartalsvis övervaka aktiva högriskrelationer med personuppgiftsbiträden och underbiträden samt årligen övervaka övriga aktiva relationer med PII-personuppgiftsbiträden och underbiträden mot villkor från leverantörsgranskning, avtalsstatus, försäkransstatus, öppna frågor och granskningsdatum i REG08.”

Från avsnittet ”Löpande övervakning, stöd, utlämnandegränssnitt och avslut”, policyklausul 4.5.1.

Det är så A.5.22 blir verklig. Granskningen bör fastställa om leverantören fortfarande ligger inom riskaptiten, om underlaget är aktuellt, om det finns öppna frågor, om incidenter har inträffat och om tjänsteförändringar kräver omprövning.

Hur revisorer testar NIS2-klausuler för leverantörer

Revisorer börjar sällan med att läsa policyn isolerat. De tar stickprov på leverantörer och följer underlagskedjan.

En ISO/IEC 27001:2022-revisor kommer att begära leverantörsförteckning, riskklassificering, leverantörskriterier, underlag från leverantörsgranskning, avtal, försäkransunderlag, SoA-mappning och övervakningshistorik. För Annex A 5.20 granskar revisorn om de stickprovsvalda avtalen innehåller klausuler som kan göras gällande. För Annex A 5.22 testar revisorn om rapporter har granskats, undantag har loggats och åtgärder har följts upp.

En behörig NIS2-myndighet kan fokusera på om leverantörers cybersäkerhetspraxis och rutiner för säker utveckling har bedömts enligt Article 21(3). En DORA-inriktad granskare kan begära poster i IKT-avtalsregistret, exitstrategier, analys av koncentrationsrisk och obligatoriska bestämmelser enligt Article 30. En dataskyddsrevisor kan testa biträdesavtal, vidareförda skyldigheter till underbiträden, incidentgränssnitt och underlag för tillräckliga garantier.

Enterprise Policy för PII-säkerhet och åtkomstkontroll visar hur åtkomstkontroll, sårbarheter, konfiguration, övervakning och kryptografi kopplas tillbaka till ISO/IEC 27001:2022:

”ISO/IEC 27001:2022 — Klausul 6.1.3; Klausul 8.1; Annex A-kontrollerna 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Hanteras genom klausulerna [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Från avsnittet ”Referensstandarder och ramverk”, policyklausul 13.9.

När en leverantör har åtkomst till PII, privilegierade system eller övervakningsdata är åtkomstkontrollunderlag inte skilt från leverantörsförsäkran. Det är en del av samma revisionsspår.

Upphandlingsfällan: undertecknade avtal utan operativ försäkran

Det vanligaste felet i NIS2-leverantörsstyrning är inte avsaknad av avtal. Det är gapet mellan avtalsformulering och daglig drift.

Ett avtal kan kräva årliga sammanfattningar av penetrationstester, men ingen ägare begär dem. Det kan kräva incidentavisering inom 24 timmar, men leverantören har bara en generisk supportadress. Det kan kräva godkännande av underleverantörer, men upphandling får aldrig ändringsmeddelanden. Det kan innehålla revisionsrätt, men organisationen saknar process för att bedöma undantag i SOC-rapporter. Det kan kräva dataradering vid avslut, men IT validerar aldrig avaktivering av konton.

Zenith Blueprint, fasen Controls in Action, steg 23, förklarar hur leverantörskontroller blir levande:

”I praktiken blir denna kontroll verksam genom:

✓ leverantörsriskbedömningar, ✓ frågeformulär för leverantörsgranskning före uppdrag, ✓ avtalsmallar med inbyggda säkerhetsvillkor, ✓ checklistor för leverantörsonboarding som omfattar åtkomsttilldelning och etablering av övervakning, ✓ löpande omprövningar, särskilt när leverantörens omfattning förändras, incidenter inträffar eller förnyelser blir aktuella.

Och denna kontroll stannar inte vid leverantörer i första ledet. Din leverantör kan outsourca till sina egna leverantörer, och du kan fortfarande bära risken.”

Det är NIS2-budskapet på styrelsenivå: outsourcing av tjänsteleverans innebär inte outsourcing av ansvarsskyldighet.

Checklista för åtgärdande av NIS2-leverantörsavtal

Börja med era 20 mest kritiska leverantörer och genomför en fokuserad åtgärdsinsats:

• Identifiera leverantörer som stödjer väsentliga eller viktiga tjänster.
• Bekräfta om respektive leverantör behandlar PII, stödjer reglerade tjänster eller har privilegierad åtkomst.
• Tilldela en verksamhetsägare, upphandlingsansvarig och säkerhetsgranskare.
• Verifiera att leverantörsriskbedömningen är aktuell och anpassad till faktisk tjänsteomfattning.
• Bekräfta att avtalet omfattar säkerhetsbaslinje, incidentavisering, revisionsrätt eller rätt till underlag, kontroller för underleverantörer, kontinuitet, säker överföring, åtkomstkontroll, samarbete kring sårbarheter och exitklausuler.
• Bekräfta att tidslinjer för incidentanmälan stödjer behov av eskalering inom 24 och 72 timmar där det är relevant.
• Begär uppdaterat försäkransunderlag, inklusive certifieringar, SOC-rapporter, sammanfattningar av penetrationstester, BCP- eller DR-tester och incidenthistorik.
• Granska underlaget, lagra det inte bara.
• Logga undantag och tilldela ägare för åtgärdande.
• Uppdatera SoA och riskregister där leverantörskontroller stödjer NIS2, GDPR, DORA eller kundåtaganden.
• Schemalägg övervakningsfrekvens baserat på leverantörens kritikalitet.
• Testa en eskaleringsväg för leverantörsincidenter.
• Testa en avslutsväg för leverantör, inklusive återlämning av data, radering, återställning av tillgångar och återkallelse av åtkomst.

Om ni inte kan visa dessa punkter för en kritisk leverantör är avtalet ännu inte revisionsklart.

Omvandla leverantörsklausuler till tillsynsunderlag

NIS2-leverantörsstyrning är nu en levande operativ disciplin. Tillsynsmyndigheter, kunder, certifieringsrevisorer, dataskyddsteam, partner i finanssektorn och styrelser kommer inte bara att fråga om leverantörsklausuler finns. De kommer att fråga om klausulerna är riskbaserade, kan göras gällande, övervakas, styrks med underlag och är kopplade till incidentrapportering, kontinuitet, åtkomstkontroll, sårbarhetshantering, vidareförda skyldigheter till underleverantörer och avslut.

Clarysec hjälper organisationer att stänga gapet med Zenith Blueprint för att omvandla leverantörskontroller till ISMS-faser, riskbehandling, SoA-poster, onboardingrutiner och revisionsbevis. Zenith Controls mappar leverantörskontrollerna A.5.19, A.5.20 och A.5.22 i ISO/IEC 27002:2022 mot NIS2, DORA, GDPR, NIST, COBIT 2019, stödjande ISO-standarder och revisionsmetoder. Clarysecs leverantörs- och dataskyddspolicyer ger klausulstrukturen, underlagsförväntningarna och övervakningsrutinerna som gör leverantörsförsäkran försvarbar.

Nästa åtgärd är enkel: välj fem kritiska leverantörer, ta stickprov på deras avtal, mappa varje klausul mot ISO/IEC 27001:2022-riskbehandling och Annex A-kontroller, begär aktuellt försäkransunderlag och genomför en skrivbordsövning för incidentavisering inom 24 timmar. Om underlagskedjan bryts ger Clarysecs verktygspaket strukturen för att reparera den innan en incident, kundgranskning eller tillsynsbegäran gör det åt er.