Dodavatelské smlouvy podle NIS2 s důkazy podle ISO 27001

Je pondělí 07:40. CISO logistické platformy využívající cloud otevírá e-mail od dodavatele řízené detekce a reakce. Zpráva je krátká, opatrná a nepříjemná: dodavatel zjistil podezřelý přístup do prostředí podpory používaného několika zákazníky. Podrobnosti jsou omezené. Dodavatel slibuje aktualizaci „jakmile to bude prakticky možné“.

V 08:15 se manažer compliance ptá, zda to může spustit oznamovací povinnost podle NIS2. V 08:40 nákup hledá smlouvu. V 09:10 chce tajemník představenstva podklady k odpovědnosti vedení. V 10:00 se právní oddělení ptá, zda smlouva obsahuje oznámení do 24 hodin, práva na audit, kontrolu subdodavatelů, přístup k důkazům, povinnosti kontinuity činností, vrácení dat a ustanovení o výmazu.

Nikdo nechce během probíhajícího incidentu zjistit, že smlouva s kritickým dodavatelem obsahuje jen formulaci „přiměřená bezpečnostní opatření“.

Právě zde přestávají být dodavatelské smluvní doložky podle NIS2 šablonovitým právním textem a stávají se provozními opatřeními. U základních a důležitých subjektů je řízení dodavatelů součástí odpovědnosti řídicích orgánů, důkazů pro dohled, připravenosti na incidenty, ujištění zákazníků, souladu v oblasti ochrany soukromí a plánování odolnosti. Podepsaná smlouva nestačí. Organizace musí prokázat, že dodavatelská rizika jsou identifikována, schválena, ošetřena, monitorována a doložena důkazy.

Přístup Clarysec vychází z jednoduché zásady: pokud dodavatelskou doložku nelze monitorovat, doložit důkazy a otestovat, nejde o opatření.

Zenith Blueprint: 30kroková roadmapa auditora zařazuje dodavatelské vztahy do fáze Opatření v praxi, kroku 23, kde jsou smlouvy, monitorování, onboarding, opětovné posouzení a auditní důkazy převedeny do praktické práce v ISMS. Zenith Controls: průvodce mapováním souladu napříč rámci následně mapuje dodavatelská opatření ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST, COBIT 2019, podpůrné normy ISO a auditní metodiky.

Výsledkem je model řízení dodavatelů, který mohou používat nákup, právní oddělení, bezpečnost, ochrana soukromí i řídicí orgány.

Proč NIS2 mění dodavatelské smlouvy na záznamy důkazů

NIS2 Article 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření k řízení kybernetických rizik, dohlížely na jejich implementaci a nesly odpovědnost za porušení. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a údržby, posuzování účinnosti, kybernetické hygieny, kryptografie, bezpečnosti lidských zdrojů, řízení přístupu, správy aktiv a případně MFA.

Article 21(3) výslovně stanoví náležitou péči ve vztahu k dodavatelům. Organizace musí zohlednit zranitelnosti specifické pro každého přímého dodavatele a poskytovatele služeb, celkovou kvalitu produktů a postupů kybernetické bezpečnosti a postupy bezpečného vývoje.

Tato formulace vytváří praktickou povinnost: dodavatelské vztahy musí být založené na rizicích, smluvně vymahatelné a přezkoumatelné. Dotazník dodavatele uložený ve složce nestačí. Obecná smlouva bez incidentní lhůty, bez práv na důkazy a bez viditelnosti subdodavatelů nestačí. Certifikace dodavatele, kterou nikdo nepřezkoumal, nestačí.

ISO/IEC 27001:2022 poskytuje provozní model. Kapitoly 4.1 až 4.4 vyžadují, aby organizace rozuměla kontextu, zainteresovaným stranám, právním a smluvním povinnostem, rozsahu ISMS a závislostem. Kapitoly 5.1 až 5.3 vyžadují vedení, politiku, role a reporting. Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik a Prohlášení o použitelnosti. Kapitoly 8.1 až 8.3 vyžadují operativní řízení, opakovaná posouzení rizik a dokumentované výsledky.

Pro řízení dodavatelů patří mezi nejdůležitější opatření přílohy A ISO/IEC 27002:2022:

• A.5.19 Bezpečnost informací ve vztazích s dodavateli
• A.5.20 Řešení bezpečnosti informací ve smlouvách s dodavateli
• A.5.21 Řízení bezpečnosti informací v dodavatelském řetězci IKT
• A.5.22 Monitorování, přezkum a řízení změn dodavatelských služeb
• A.5.24 Plánování a příprava řízení incidentů
• A.5.25 Posouzení bezpečnostních událostí a rozhodování o nich
• A.5.26 Reakce na incidenty informační bezpečnosti
• A.5.27 Poučení z incidentů informační bezpečnosti
• A.5.28 Sběr důkazů
• A.5.29 Bezpečnost informací při narušení
• A.5.30 Připravenost IKT na kontinuitu činností
• A.5.31 Právní, zákonné, regulatorní a smluvní požadavky
• A.5.34 Ochrana soukromí a ochrana PII
• A.8.8 Řízení technických zranitelností
• A.8.13 Zálohování informací
• A.8.15 Protokolování
• A.8.16 Monitorovací činnosti
• A.8.24 Používání kryptografie
• A.8.32 Řízení změn

Klíčové je vlastnictví. Doložka má malou hodnotu, pokud někdo nevlastní riziko, někdo nepřezkoumává důkazy, někdo nesleduje výjimky a někdo neeskaluje nesoulad.

Podniková Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran to stanoví výslovně:

„Práva na audit, kontrolu a vyžádání bezpečnostních důkazů“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.4.

Pro malé a střední podniky stanoví Bezpečnostní politika třetích stran a dodavatelů pro SME stejné praktické očekávání:

„Práva na audit nebo dostupnost důkazů o souladu“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.4.

Na tomto rozlišení záleží. Menší organizace nemusí být schopna auditovat každého významného poskytovatele cloudových služeb na místě, může však vyžadovat přístup k důkazům ujištění, jako je rozsah certifikace ISO/IEC 27001:2022, zprávy SOC, shrnutí penetračního testování, potvrzení o nápravě zranitelností, shrnutí incidentů, zprávy z testů kontinuity činností a potvrzení o výmazu dat.

Tři opatření jako páteř ujištění o dodavatelích podle NIS2

V modelu Clarysec pro mapování souladu napříč rámci tvoří tři opatření ISO/IEC 27002:2022 páteř řízení dodavatelů podle NIS2: 5.19, 5.20 a 5.22.

A.5.19 identifikuje dodavatelské riziko

Opatření A.5.19, Bezpečnost informací ve vztazích s dodavateli, je základem. Vyžaduje, aby organizace chránily informace a aktiva, k nimž dodavatelé přistupují nebo která zpracovávají, ukládají či spravují.

Zenith Controls toto opatření kategorizuje jako preventivní kontrolu pokrývající důvěrnost, integritu a dostupnost, s konceptem kybernetické bezpečnosti „Identify“ a provozní schopností „Supplier Relationships Security“. Propojuje A.5.19 s A.5.20, A.5.21, A.5.14, A.5.36 a A.5.10. V praxi organizace identifikuje dodavatelské riziko, definuje bezpečnostní očekávání, řídí expozici dodavatelského řetězce IKT, chrání přenos informací, monitoruje soulad a rozšiřuje povinnosti přijatelného užívání na externí strany.

Pro NIS2 se to přímo mapuje na Article 21(2)(d) zabezpečení dodavatelského řetězce a Article 21(3) náležitou péči o dodavatele. Pro GDPR to podporuje požadavek používat zpracovatele, kteří poskytují dostatečné záruky. Pro DORA to podporuje řízení rizik IKT třetích stran, předsmluvní náležitou péči, posouzení kritičnosti, riziko koncentrace a dohled nad životním cyklem.

A.5.20 činí požadavek vymahatelným

Opatření A.5.20, Řešení bezpečnosti informací ve smlouvách s dodavateli, převádí bezpečnostní očekávání na smluvní povinnosti. Zenith Controls jasně vysvětluje vztah mezi A.5.19 a A.5.20:

„5.20 slouží jako smluvní formalizace bezpečnostních potřeb a rizik identifikovaných podle 5.19. Zatímco 5.19 zahrnuje posouzení rizik třetích stran a definování bezpečnostních očekávání, 5.20 zajišťuje, aby tato očekávání byla právně závazná prostřednictvím smluv nebo dohod o úrovni služeb (SLA). Bez 5.20 by bezpečnostní opatření identifikovaná v 5.19 postrádala vymahatelnost.“

Zde se rozhodnutí o rizicích podle NIS2 mění ve smluvní doložky: oznámení porušení zabezpečení, práva na audit a důkazy, šifrování, řízení přístupu, řízení zranitelností, schvalování subdodavatelů, bezpečný přenos, kontinuita, regulatorní součinnost, podpora při ukončení spolupráce a výmaz dat.

A.5.22 prokazuje, že smlouva žije

Opatření A.5.22, Monitorování, přezkum a řízení změn dodavatelských služeb, brání tomu, aby se ujištění o dodavatelích stalo jednorázovým onboardingovým cvičením. Zenith Controls propojuje A.5.22 s A.5.19 a A.5.20, ale také s A.5.29 bezpečností informací při narušení, A.8.8 řízením technických zranitelností, A.5.36 souladem s politikami, pravidly a normami bezpečnosti informací, A.5.15 řízením přístupu a A.8.27 bezpečnou architekturou systémů a inženýrskými principy.

To je důležité, protože dodavatelské služby se mění. Mění se lokality dat. Mění se dílčí zpracovatelé. Objevují se zranitelnosti. Certifikace expirují. Vznikají vzorce incidentů. Dodavatel, který byl přijatelný minulý rok, může být dnes příliš rizikový.

Co musí obsahovat dodavatelské smluvní doložky podle NIS2

Zenith Blueprint, fáze Opatření v praxi, krok 23, uvádí praktický soubor oblastí dodavatelských smluv:

„Mezi klíčové oblasti obvykle řešené v dodavatelských smlouvách patří:

✓ povinnosti zachování důvěrnosti, včetně rozsahu, doby trvání a omezení zpřístupnění třetím stranám; ✓ odpovědnosti za řízení přístupu, například kdo může přistupovat k vašim datům, jak jsou spravovány přihlašovací údaje a jaké monitorování je zavedeno; ✓ technická a organizační opatření pro ochranu dat, šifrování, bezpečný přenos, zálohování a závazky dostupnosti; ✓ lhůty a protokoly pro hlášení incidentů, často s definovanými časovými rámci (např. „oznámit do 24 hodin“); ✓ právo na audit, včetně frekvence, rozsahu a přístupu k relevantním důkazům (např. zprávy z penetračního testování, SoA, certifikace); ✓ kontroly subdodavatelů vyžadující, aby dodavatel přenesl rovnocenné bezpečnostní povinnosti na své navazující partnery; ✓ ustanovení pro ukončení smlouvy, jako je vrácení nebo zničení dat, obnova aktiv a deaktivace účtů.“

Z fáze Opatření v praxi, krok 23: Organizační opatření.

Silná dodavatelská doložka podle NIS2 je dostatečně konkrétní, aby ji bylo možné testovat. „Dodavatel bude udržovat přiměřenou bezpečnost“ je slabé. „Dodavatel oznámí bezpečnostnímu kontaktu zákazníka do 24 hodin potvrzené nebo podezřelé incidenty ovlivňující zákaznické systémy, zákaznická data, dostupnost služby nebo regulatorní oznamovací povinnosti“ je auditovatelné.

Incidentní doložky musí odpovídat oznamovacím lhůtám NIS2

NIS2 Article 23 vytváří stupňovaný model hlášení významných incidentů: včasné varování do 24 hodin od okamžiku zjištění, oznámení incidentu do 72 hodin, průběžné zprávy, pokud jsou vyžádány, a závěrečnou zprávu do jednoho měsíce od oznámení incidentu. Významný incident je incident, který způsobil nebo může způsobit závažné provozní narušení, finanční ztrátu nebo značnou hmotnou či nehmotnou újmu jiným osobám.

Dodavatelské smlouvy musí tuto časovou osu podporovat. Pokud kritický poskytovatel řízených služeb potřebuje čtyři dny, aby potvrdil, zda byla zasažena zákaznická prostředí, může zákazník zmeškat vlastní regulatorní lhůtu.

Podniková Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran vyžaduje:

„Lhůty pro oznámení porušení zabezpečení (např. do 24 nebo 72 hodin v závislosti na kritičnosti a regulatorních požadavcích)“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.3.

Bezpečnostní politika třetích stran a dodavatelů pro SME rovněž vyžaduje definované oznamovací lhůty pro porušení zabezpečení ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.3.

U incidentů týkajících se PII propojuje podniková Politika řízení incidentů a porušení zabezpečení PII hlášení v oblasti kybernetické bezpečnosti, finančního sektoru, zákazníků a příjemců služeb:

„[Podmíněně] Vedoucí ochrany soukromí / manažer PIMS MUSÍ koordinovat veškeré požadované sektorové hlášení incidentů, hlášení v oblasti kybernetické bezpečnosti, finančního sektoru, zákazníků nebo příjemců služeb, pokud incident s významným dopadem týkající se PII splní příslušnou oznamovací prahovou hodnotu, a MUSÍ zaznamenat důkazy o orgánu, příjemci, časové ose, podání a potvrzení v REG01 a REG10.“

Ze sekce „Oznamování a komunikace“, ustanovení politiky 4.4.6.

Toto jsou vyspělé důkazy podle NIS2: nejen oznamovací e-mail, ale záznam o orgánu, příjemci, časové ose, podání, potvrzení, dopadu, kořenové příčině a navazujících opatřeních.

Slaďte ochranu soukromí a DORA bez duplicitních dodavatelských programů

Mnoho dodavatelů podle NIS2 zároveň zpracovává osobní údaje. GDPR Article 28 vyžaduje, aby správci používali zpracovatele, kteří poskytují dostatečné záruky, a aby povinnosti zpracovatele byly vymezeny v písemné smlouvě. GDPR Article 5 vyžaduje odpovědnost za bezpečné a zákonné zpracování. Povinnosti podle GDPR při porušení zabezpečení také vyžadují rychlou součinnost, pokud dodavatelské incidenty ovlivňují osobní údaje.

Podniková Politika řízení zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí stanoví schvalovací bod:

„[Oba] Vlastník dodavatele / nákup MUSÍ před schválením zajistit, aby smlouvy se zpracovateli a dílčími zpracovateli obsahovaly součinnost v oblasti ochrany soukromí, ujištění o bezpečnosti, incidentní rozhraní prostřednictvím PII15, vrácení nebo výmaz prostřednictvím PII10, vazbu na předávání prostřednictvím PII13 a součinnost při auditu nebo ujištění.“

Ze sekce „Kontroly smluv a dokumentovaných pokynů“, ustanovení politiky 4.3.6.

Vyžaduje také přezkum důkazů před schválením:

„[Všichni] Vedoucí informační bezpečnosti MUSÍ před schválením přezkoumat důkazy o zajištění bezpečnosti pro každý vztah se zpracovatelem, dílčím zpracovatelem nebo třetí stranou s přístupem k PII nebo hostingem PII a MUSÍ zaznamenat výsledek v REG08 nebo REG12.“

Ze sekce „Náležitá péče a posouzení rizik“, ustanovení politiky 4.2.2.

DORA přidává další vrstvu, pokud dodavatel obsluhuje finanční subjekt. DORA Articles 28 až 30 vyžadují správu a řízení třetích stran v oblasti IKT, registry smluv na služby IKT, náležitou péči založenou na rizicích, posouzení kritičnosti, analýzu rizika koncentrace, práva na audit a kontrolu, práva na ukončení, strategie ukončení a povinná smluvní ustanovení. Article 30 je zvlášť relevantní, protože vyžaduje smluvní obsah zahrnující popisy služeb, lokality, ochranu dat, přístup a obnovu, úrovně služeb, součinnost při incidentech, spolupráci s orgány, práva na audit, subdodávky, opatření pro mimořádné situace a podporu při přechodu.

Praktickou odpovědí nejsou tři oddělené dodavatelské programy pro NIS2, GDPR a DORA. Je jí jeden harmonizovaný model dodavatelských důkazů namapovaný napříč rámci.

NIST CSF 2.0 je užitečný, protože jeho funkce GOVERN vyžaduje porozumění závislostem, právním povinnostem, smluvním povinnostem, ochotě podstupovat riziko, politikám, odpovědnosti a dohledu. Jeho kategorie dodavatelského řetězce GV.SC pokrývá role dodavatelů, kritičnost, smluvní požadavky, náležitou péči, monitorování, zahrnutí do incidentů, monitorování životního cyklu a ustanovení pro ukončení vztahu.

Pracovní postup Clarysec pro onboarding kritického dodavatele

Předpokládejme, že zavádíte poskytovatele řízených bezpečnostních služeb, který bude monitorovat telemetrii koncových bodů, přijímat upozornění obsahující identifikátory uživatelů a podporovat třídění incidentů pro organizaci v rozsahu NIS2.

Krok 1: klasifikujte dodavatele

Zaznamenejte dodavatele do registru dodavatelů spolu s popisem služby, systémy a daty, k nimž má přístup, zapojením PII, podporou základních nebo důležitých služeb, privilegovaným přístupem, zeměmi poskytování služby, subdodavateli, závislostmi na čtvrtých stranách, hodnocením kritičnosti, vlastníkem rizika, vlastníkem nákupu a osobou provádějící bezpečnostní přezkum.

Tím se implementují kapitoly ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 a 8.1 propojením požadavků zainteresovaných stran, závislostí, vlastnictví rizika a operativního řízení.

Krok 2: namapujte riziko do SoA

V Zenith Blueprint, fázi Řízení rizik, kroku 13, Clarysec doporučuje křížové odkazy na právní předpisy v registru rizik nebo SoA:

„Křížově odkazujte na právní předpisy: Pokud jsou určitá opatření implementována konkrétně za účelem souladu s GDPR, NIS2 nebo DORA, můžete to uvést buď v Registru rizik (jako součást odůvodnění dopadu rizika), nebo v poznámkách SoA.“

Z fáze Řízení rizik, krok 13: Plánování ošetření rizik a Prohlášení o použitelnosti.

U MSSP zahrňte minimálně A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 až A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 a A.8.24.

Krok 3: vyžadujte vymahatelné doložky

Použijte bezpečnostní přílohu dodavatele vyžadující prvotní oznámení incidentu do 24 hodin, podrobnou aktualizaci do 72 hodin, závěrečné hlášení incidentu, MFA pro privilegovaný přístup, jmenovité uživatelské účty, kontrolu subdodavatelů, bezpečný přenos, šifrování, důkazy ujištění, regulatorní součinnost, důkazy BCP a DR, podporu při ukončení, vrácení nebo výmaz dat a odebrání přístupu.

Podniková Politika řízení rizik závislostí na dodavatelích poskytuje požadavek na kontinuitu:

„Je-li to relevantní, požadavek, aby dodavatel udržoval vlastní Plány kontinuity činností (BCP/DRP) a plány řízení incidentů, testoval je a na vyžádání nám poskytoval jejich shrnutí nebo zprávy z testů.“

Ze sekce „Požadavky na implementaci“, ustanovení politiky 6.8.4.

Krok 4: vytvořte balíček důkazů ujištění

Před schválením si vyžádejte podepsanou smlouvu, SLA, bezpečnostní přílohu, rozsah certifikace ISO/IEC 27001:2022 nebo rovnocenné ujištění, zprávu SOC, pokud je dostupná, manažerské shrnutí penetračního testování, shrnutí řízení zranitelností, shrnutí postupu reakce na incidenty, shrnutí testu BCP nebo DR, potvrzení o řízení přístupu a MFA, seznam subdodavatelů, postup výmazu dat a ukončení spolupráce a DPA, pokud se zpracovávají PII.

Bezpečnostní politika třetích stran a dodavatelů pro SME činí základní smluvní důkazy měřitelnými:

„Podepsané smlouvy a SLA“

Ze sekce „Vynucování a dodržování“, ustanovení politiky 8.3.2.1.

Rovněž identifikuje opakující se dodavatelské důkazy:

„Platné bezpečnostní certifikace nebo aktualizované důkazy o opatřeních“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.2.

Pro širší prověrku dodavatelů Politika monitorování auditu a souladu stanoví:

„Prověrka dodavatelů musí zahrnovat přezkum certifikací (např. ISO 27001, SOC 2), bezpečnostních dotazníků a záznamů o incidentech.“

Krok 5: monitorujte podle kritičnosti

Podniková Politika řízení zpracovatelů, dílčích zpracovatelů a třetích stran v oblasti ochrany soukromí vyžaduje čtvrtletní monitorování vysoce rizikových vztahů týkajících se PII:

„[Všichni] Vlastník dodavatele / nákup MUSÍ čtvrtletně monitorovat aktivní vysoce rizikové vztahy se zpracovateli a dílčími zpracovateli a ročně ostatní aktivní vztahy se zpracovateli a dílčími zpracovateli PII podle podmínek náležité péče, stavu smlouvy, stavu ujištění, otevřených problémů a dat přezkumu v REG08.“

Ze sekce „Průběžné monitorování, součinnost, rozhraní zpřístupnění a ukončení“, ustanovení politiky 4.5.1.

Tak se A.5.22 stává skutečností. Přezkum má určit, zda dodavatel zůstává v rámci ochoty podstupovat riziko, zda jsou důkazy aktuální, zda existují otevřené problémy, zda došlo k incidentům a zda změny služby vyžadují opětovné posouzení.

Jak budou auditoři testovat dodavatelské doložky podle NIS2

Auditoři jen zřídka začínají tím, že čtou vaši politiku izolovaně. Vzorkují dodavatele a sledují řetězec důkazů.

Auditor ISO/IEC 27001:2022 si vyžádá inventář dodavatelů, klasifikaci rizik, kritéria pro dodavatele, záznamy o náležité péči, smlouvy, důkazy, mapování SoA a historii monitorování. U přílohy A 5.20 auditor ověří, zda vzorkované smlouvy obsahují vymahatelné doložky. U přílohy A 5.22 auditor otestuje, zda byly zprávy přezkoumány, výjimky zaznamenány a opatření následně provedena.

Příslušný orgán podle NIS2 se může zaměřit na to, zda byly postupy kybernetické bezpečnosti dodavatelů a postupy bezpečného vývoje posouzeny podle Article 21(3). Přezkoumávající osoba orientovaná na DORA si může vyžádat záznamy v registru smluv IKT, strategie ukončení, analýzu rizika koncentrace a povinná ustanovení Article 30. Auditor ochrany soukromí může testovat smlouvy se zpracovateli, přenesení povinností na dílčí zpracovatele, rozhraní pro porušení zabezpečení a důkazy o dostatečných zárukách.

Podniková Politika zabezpečení a řízení přístupu k PII ukazuje, jak se řízení přístupu, zranitelnosti, konfigurace, monitorování a kryptografie vážou zpět na ISO/IEC 27001:2022:

„ISO/IEC 27001:2022 — kapitola 6.1.3; kapitola 8.1; opatření přílohy A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Řešeno ustanoveními [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].“

Ze sekce „Referenční normy a rámce“, ustanovení politiky 13.9.

Pokud má dodavatel přístup k PII, privilegovaným systémům nebo monitorovacím datům, důkazy o řízení přístupu nejsou oddělené od ujištění o dodavatelích. Jsou součástí stejné auditní stopy.

Past nákupu: podepsané smlouvy bez provozního ujištění

Nejčastějším selháním řízení dodavatelů podle NIS2 není absence smluv. Je jím mezera mezi smluvním zněním a každodenním provozem.

Smlouva může vyžadovat každoroční shrnutí penetračního testování, ale žádný vlastník si je nevyžádá. Může vyžadovat oznámení incidentu do 24 hodin, ale dodavatel má pouze obecnou adresu podpory. Může vyžadovat schvalování subdodavatelů, ale nákup nikdy nedostává oznámení změn. Může obsahovat práva na audit, ale organizace nemá proces pro vyhodnocení výjimek ve zprávě SOC. Může vyžadovat výmaz dat při ukončení, ale IT nikdy neověří deaktivaci účtů.

Zenith Blueprint, fáze Opatření v praxi, krok 23, vysvětluje, jak dodavatelská opatření ožívají:

„V praxi toto opatření ožívá prostřednictvím:

✓ posouzení rizik dodavatelů, ✓ dotazníků náležité péče před zahájením spolupráce, ✓ smluvních šablon se zabudovanými bezpečnostními podmínkami, ✓ kontrolních seznamů pro onboarding dodavatelů, které zahrnují zřizování přístupu a nastavení monitorování, ✓ průběžných opětovných posouzení, zejména při změně rozsahu dodavatele, při incidentech nebo při blížícím se obnovení.

A toto opatření nekončí u dodavatelů první úrovně. Váš dodavatel může outsourcovat svým vlastním poskytovatelům a riziko můžete stále nést vy.“

To je sdělení NIS2 pro řídicí orgány: outsourcing poskytování služby neznamená outsourcing odpovědnosti.

Kontrolní seznam nápravy dodavatelských smluv podle NIS2

Začněte u 20 nejvýznamnějších dodavatelů podle kritičnosti a proveďte cílenou nápravu:

• Identifikujte dodavatele podporující základní nebo důležité služby.
• Potvrďte, zda každý dodavatel zpracovává PII, podporuje regulované služby nebo má privilegovaný přístup.
• Přiřaďte vlastníka za obchodní oblast, vlastníka nákupu a osobu odpovědnou za bezpečnostní přezkum.
• Ověřte, že posouzení rizik dodavatele je aktuální a sladěné se skutečným rozsahem služby.
• Potvrďte, že smlouva obsahuje základní bezpečnostní požadavky, oznámení incidentů, práva na audit nebo důkazy, kontrolu subdodavatelů, kontinuitu, bezpečný přenos, řízení přístupu, součinnost při zranitelnostech a doložky pro ukončení.
• Potvrďte, že lhůty pro oznámení porušení zabezpečení podporují potřeby eskalace do 24 hodin a 72 hodin, kde je to relevantní.
• Vyžádejte si aktualizované důkazy ujištění, včetně certifikací, zpráv SOC, shrnutí penetračního testování, testů BCP nebo DR a historie incidentů.
• Důkazy přezkoumejte, ne pouze uložte.
• Zaznamenejte výjimky a přiřaďte vlastníky nápravy.
• Aktualizujte SoA a registr rizik tam, kde dodavatelská opatření podporují NIS2, GDPR, DORA nebo závazky vůči zákazníkům.
• Naplánujte frekvenci monitorování podle kritičnosti dodavatele.
• Otestujte jednu eskalační cestu dodavatelského incidentu.
• Otestujte jednu cestu ukončení dodavatele, včetně vrácení dat, výmazu, obnovy aktiv a odebrání přístupu.

Pokud tyto body u kritického dodavatele nedokážete prokázat, smlouva ještě není připravena pro audit.

Přeměňte dodavatelské doložky na důkazy pro dohled

Řízení dodavatelů podle NIS2 je nyní živou provozní disciplínou. Dozorové orgány, zákazníci, certifikační auditoři, týmy ochrany soukromí, partneři z finančního sektoru a řídicí orgány se nebudou ptát jen na to, zda dodavatelské doložky existují. Budou se ptát, zda jsou založené na rizicích, vymahatelné, monitorované, doložené důkazy a propojené s hlášením incidentů, kontinuitou, řízením přístupu, řízením zranitelností, přenesením povinností na subdodavatele a ukončením spolupráce.

Clarysec pomáhá organizacím tuto mezeru uzavřít prostřednictvím Zenith Blueprint, který převádí dodavatelská opatření do fází ISMS, ošetření rizik, položek SoA, onboardingových postupů a auditních důkazů. Zenith Controls mapuje dodavatelská opatření ISO/IEC 27002:2022 A.5.19, A.5.20 a A.5.22 na NIS2, DORA, GDPR, NIST, COBIT 2019, podpůrné normy ISO a auditní metodiky. Dodavatelské a privacy politiky Clarysec poskytují strukturu doložek, očekávání ohledně důkazů a monitorovací postupy, které činí ujištění o dodavatelích obhajitelným.

Váš další krok je jednoduchý: vyberte pět kritických dodavatelů, vzorkujte jejich smlouvy, namapujte každou doložku na ošetření rizik podle ISO/IEC 27001:2022 a opatření přílohy A, vyžádejte si aktuální důkazy ujištění a proveďte stolní cvičení oznámení incidentu do 24 hodin. Pokud se auditní stopa přeruší, toolkity Clarysec vám poskytnou strukturu pro nápravu dříve, než to za vás udělá incident, zákaznický přezkum nebo žádost dozorového orgánu.