Slabý článok: príručka pre CISO na vybudovanie programu riadenia rizík dodávateľského reťazca v súlade s NIS2

Upozornenie pôsobilo neškodne, iba ako drobná odchýlka zo služby monitorovania tretej strany. Pre Anyu, CISO stredne veľkej logistickej spoločnosti, to však bolo už tretie takéto oznámenie za mesiac od toho istého dodávateľa: „Zistená anomália prihlásenia.“ Dodávateľ, malý, ale kritický poskytovateľ softvéru na správu vozového parku, ju uisťoval, že nejde o nič vážne. Falošne pozitívny nález. Anya však vedela, že situácia je iná. Neboli to len technické chyby; boli to signály hlbšej nestability v kritickej časti jej dodávateľského reťazca. Keďže jej spoločnosť je teraz podľa smernice NIS2 klasifikovaná ako „dôležitý subjekt“, tieto signály pôsobili ako predzvesť zemetrasenia.
Starý spôsob riadenia dodávateľov, založený na podaní ruky a voľne formulovanej zmluve, je definitívne minulosťou. NIS2 jasne ukazuje, že kybernetická bezpečnosť organizácie je len taká silná, ako jej najslabší článok. Tento slabý článok už nie je „niekde vonku“ – nachádza sa vo vašom dodávateľskom reťazci. Podľa NIS2 nie je nezvládnutie dodávateľského rizika len technickým pochybením. Je to regulačná hrozba na úrovni riadiacich orgánov s prevádzkovými, reputačnými a finančnými dôsledkami. Anyin problém nebol iba jeden nestabilný dodávateľ. Bola to systémová zraniteľnosť zabudovaná do jej prevádzkového modelu – a audítori by ju hľadali. Nepotrebovala rýchlu opravu; potrebovala príručku.
Táto príručka tento postup poskytuje. Prejdeme si štruktúrovaný prístup, ktorý pomáha CISO, manažérom súladu a audítorom vybudovať obhájiteľný program riadenia rizík dodávateľského reťazca použiteľný naprieč regulačnými rámcami. Využitím robustného rámca, akým je ISO/IEC 27001:2022, a odborných nástrojových balíkov Clarysec môžete prepojiť naliehavé riziká dodávateľského reťazca s praktickými metódami na splnenie požiadaviek NIS2, DORA, GDPR a ďalších rámcov.
Mandát založený na riziku: ako NIS2 nanovo definuje bezpečnosť dodávateľského reťazca
Smernica NIS2 mení bezpečnosť dodávateľského reťazca z obyčajného osvedčeného postupu na právne záväznú povinnosť. Vyžaduje priebežný prístup založený na riziku k zabezpečeniu dodávateľských reťazcov IKT a OT, rozširuje rozsah na množstvo sektorov a priamo vyvodzuje zodpovednosť vedenia za zlyhania v oblasti súladu. Znamená to:
- Rozšírený rozsah: Do rozsahu patrí každý dodávateľ, ďalší sprostredkovateľ, poskytovateľ cloudových služieb a outsourcingový partner, ktorý sa dotýka vášho prostredia IKT.
- Neustále zlepšovanie: NIS2 vyžaduje živý proces posúdenia rizík, monitorovania a prispôsobovania, nie jednorazové preskúmanie typu „urob a zabudni“. Tento proces musia spúšťať interné udalosti (incidenty, porušenia bezpečnosti) aj externé zmeny (nové právne predpisy, zmeny služieb dodávateľa).
- Povinné opatrenia: Reakcia na incidenty, riadenie zraniteľností, pravidelné bezpečnostné testovanie a robustné šifrovanie sú teraz povinné v celom dodávateľskom reťazci, nielen vo vašom vlastnom perimetri.
Tým sa stierajú hranice medzi internou bezpečnosťou a rizikom tretích strán. Kybernetické zlyhanie vášho dodávateľa je vašou regulačnou krízou. Štruktúrovaný rámec ako ISO/IEC 27001:2022 sa stáva nevyhnutným, pretože poskytuje opatrenia a procesy potrebné na vybudovanie odolného a auditovateľného programu, ktorý spĺňa požiadavky NIS2. Cesta sa nezačína technológiou, ale stratégiou sústredenou na tri kľúčové opatrenia:
- 5.19 – Informačná bezpečnosť vo vzťahoch s dodávateľmi: Zavedenie strategického rámca na riadenie dodávateľského rizika.
- 5.20 – Riešenie informačnej bezpečnosti v dodávateľských zmluvách: Premietnutie bezpečnostných očakávaní do právne záväzných zmlúv.
- 5.22 – Monitorovanie, preskúmanie a riadenie zmien služieb dodávateľov: Zabezpečenie priebežného dohľadu a prispôsobovania počas celého životného cyklu dodávateľa.
Zvládnutie týchto troch oblastí zmení váš dodávateľský reťazec zo zdroja obáv na dobre riadené, súladné a odolné aktívum.
Krok 1: Vybudovanie základu riadenia pomocou opatrenia 5.19
Anyino prvé uvedomenie bolo, že so všetkými dodávateľmi nemôže zaobchádzať rovnako. Dodávateľ kancelárskych potrieb nie je to isté ako poskytovateľ kritického softvéru na správu vozového parku. Prvým krokom pri budovaní programu v súlade s NIS2 je pochopiť a klasifikovať ekosystém dodávateľov na základe rizika.
Opatrenie 5.19, Informačná bezpečnosť vo vzťahoch s dodávateľmi, je strategickým základom. Núti vás ísť ďalej než len k jednoduchému zoznamu dodávateľov a vytvoriť viacúrovňový systém riadenia. Tento proces musí vychádzať z jasnej politiky schválenej predstavenstvom. Politika bezpečnosti tretích strán a dodávateľov od Clarysec priamo prepája túto činnosť so širším rámcom riadenia rizík organizácie:
„P6 – Politika riadenia rizík. Usmerňuje identifikáciu, posúdenie a zmierňovanie rizík spojených so vzťahmi s tretími stranami vrátane zdedených alebo systémových rizík vyplývajúcich z ekosystémov dodávateľov.“ Zo sekcie „Súvisiace politiky a väzby“, ustanovenie politiky 10.2.
Táto integrácia zabezpečuje, že riziká z nadväzujúcich závislostí alebo expozícií štvrtých strán sa riadia ako súčasť vášho vlastného ISMS. Samotný proces klasifikácie má byť metodický. V kroku 23 fázy „Audit a zlepšovanie“ vedie Zenith Blueprint: 30-kroková cestovná mapa audítora organizácie ku klasifikácii dodávateľov podľa kritických otázok:
- Nakladá dodávateľ s vašimi citlivými alebo regulovanými informáciami alebo ich spracúva?
- Poskytuje infraštruktúru alebo platformy, od ktorých závisia vaše kritické činnosti?
- Spravuje alebo udržiava systémy vo vašom mene?
- Mohla by jeho kompromitácia priamo ovplyvniť vaše ciele v oblasti dôvernosti, integrity alebo dostupnosti?
Anya použila túto logiku na opätovné posúdenie poskytovateľa softvéru na správu vozového parku. Spracúval údaje o polohe v reálnom čase (citlivé), jeho platforma bola nevyhnutná pre každodennú prevádzku (kritická infraštruktúra) a kompromitácia by mohla zastaviť doručovanie (vysoký dopad na dostupnosť). Okamžite bol preklasifikovaný zo „štandardného dodávateľa“ na „kritického dodávateľa s vysokým rizikom“.
Toto členenie podľa rizika určuje požadovanú úroveň náležitej starostlivosti, zmluvnej prísnosti a priebežného monitorovania. Ako vysvetľuje náš Zenith Controls: príručka ku krížovému súladu, tento prístup priamo zodpovedá očakávaniam hlavných regulačných predpisov.
| Predpis | Požiadavka | Ako ju pokrýva opatrenie 5.19 |
|---|---|---|
| NIS2 | Article 21(2)(d) ukladá povinnosť riadiť riziká dodávateľských reťazcov. | Poskytuje rámec na identifikáciu dodávateľského rizika a určenie jeho úrovne. |
| DORA | Articles 28-30 vyžadujú klasifikáciu kritických dodávateľov IT a finančných služieb. | Zavádza proces klasifikácie poskytovateľov IKT podľa kritickosti. |
| GDPR | Article 28 vyžaduje, aby prevádzkovatelia využívali len sprostredkovateľov poskytujúcich záruky. | Tvorí základ náležitej starostlivosti potrebnej na posúdenie týchto záruk. |
Tento základný krok nie je iba interným cvičením; je to pevný podklad, na ktorom stojí celý váš obhájiteľný program bezpečnosti dodávateľského reťazca.
Krok 2: Vytvorenie nepriestrelných dohôd pomocou opatrenia 5.20
Keď Anya identifikovala dodávateľa s vysokým rizikom, otvorila jeho zmluvu. Išlo o štandardnú obstarávaciu šablónu s neurčitou doložkou o dôvernosti a takmer ničím ďalším v oblasti kybernetickej bezpečnosti. Neobsahovala žiadne konkrétne bezpečnostné opatrenia, žiadnu lehotu na oznámenie porušenia bezpečnosti ani žiadne právo na audit. Z pohľadu audítora NIS2 bola bezcenná.
Práve tu sa stáva kritickým opatrenie 5.20, Riešenie informačnej bezpečnosti v dodávateľských zmluvách. Je mechanizmom, ktorý premieňa riziká identifikované v 5.19 na vynútiteľné, právne záväzné povinnosti. Zmluva nie je iba obchodný dokument; je to primárne bezpečnostné opatrenie.
Túto transformáciu musia riadiť vaše politiky. Politika bezpečnosti tretích strán a dodávateľov stanovuje túto požiadavku ako kľúčový cieľ:
„Zosúladiť bezpečnostné opatrenia tretích strán s príslušnými regulačnými a zmluvnými povinnosťami vrátane GDPR, NIS2, DORA a noriem ISO/IEC 27001.“ Zo sekcie „Ciele“, ustanovenie politiky 3.6.
Táto doložka mení politiku z usmernenia na priamy mandát pre tímy obstarávania a právne oddelenie. Pre Anyu to znamenalo vrátiť sa k dodávateľovi a zmluvu prerokovať. Nový dodatok k zmluve obsahoval konkrétne, nevyjednateľné doložky:
- Oznámenie porušenia bezpečnosti: Dodávateľ musí nahlásiť každý podozrivý bezpečnostný incident ovplyvňujúci údaje alebo služby jej spoločnosti do 24 hodín, nie „v primeranej lehote“.
- Právo na audit: Spoločnosť si vyhradzuje právo každoročne vykonať bezpečnostné posúdenia alebo vyžiadať auditné správy tretích strán (napríklad SOC 2 Type II).
- Bezpečnostné štandardy: Dodávateľ musí dodržiavať konkrétne bezpečnostné opatrenia, napríklad viacfaktorovú autentifikáciu pre všetky administrátorské prístupy a pravidelné skenovanie zraniteľností svojej platformy.
- Riadenie ďalších sprostredkovateľov: Dodávateľ musí zverejniť a získať predchádzajúci písomný súhlas pre každého vlastného subdodávateľa, ktorý bude nakladať s údajmi spoločnosti.
- Stratégia ukončenia: Zmluva musí definovať postupy bezpečného vrátenia alebo zničenia údajov pri ukončení, aby bol zabezpečený čistý proces vyradenia dodávateľa.
Ako zdôrazňuje Zenith Controls, táto prax je ústredná pre viaceré rámce. GDPR v Article 28(3) vyžaduje podrobné zmluvy o spracúvaní osobných údajov. DORA v Article 30 predpisuje vyčerpávajúci zoznam zmluvných ustanovení pre kritických poskytovateľov IKT. Implementáciou robustného opatrenia 5.20 Anya nespĺňala iba ISO/IEC 27001:2022; zároveň budovala obhájiteľnú pozíciu pre audity NIS2, DORA a GDPR.
Krok 3: Strážna veža – priebežné monitorovanie pomocou opatrenia 5.22
Anyin pôvodný problém, opakované bezpečnostné upozornenia, pramenil z klasického zlyhania: „podpíš a zabudni“. Silná zmluva je zbytočná, ak sa založí do archívu a už sa k nej nikto nevráti. Posledným dielom skladačky je opatrenie 5.22, Monitorovanie, preskúmanie a riadenie zmien služieb dodávateľov. Ide o prevádzkové opatrenie, ktoré zabezpečuje, že prísľuby uvedené v zmluve sa aj dodržiavajú.
Toto opatrenie mení riadenie dodávateľov zo statickej aktivity pri úvodnom schvaľovaní na dynamický a priebežný proces. Podľa Zenith Controls zahŕňa viacero vzájomne prepojených činností:
- Preskúmania výkonnosti: Pravidelne plánované stretnutia (napr. štvrťročne pri dodávateľoch s vysokým rizikom) na diskusiu o plnení bezpečnostných SLA, preskúmanie incidentných správ a plánovanie pripravovaných zmien.
- Preskúmanie auditných artefaktov: Proaktívne vyžadovanie a analyzovanie auditných správ dodávateľa, certifikácií a výsledkov penetračného testovania. Audítor overí, či tieto správy nielen zhromažďujete, ale či aktívne sledujete a riadite výnimky, ktoré obsahujú.
- Riadenie zmien: Keď dodávateľ zmení službu – napríklad migráciou k novému poskytovateľovi cloudových služieb alebo zavedením nového API – musí to na vašej strane spustiť bezpečnostné preskúmanie. Tým sa zabráni tomu, aby dodávatelia nevedomky zaviedli nové riziká do vášho prostredia.
- Priebežné monitorovanie: Využívanie nástrojov a spravodajských zdrojov na udržiavanie prehľadu o externom bezpečnostnom stave dodávateľa. Náhly pokles bezpečnostného hodnotenia alebo správa o porušení bezpečnosti musí spustiť okamžitú reakciu.
Táto priebežná slučka monitorovania, preskúmavania a prispôsobovania je podstatou „priebežného procesu riadenia rizík“, ktorý NIS2 vyžaduje. Zabezpečuje, že dôvera sa nikdy nepredpokladá; priebežne sa overuje.
Praktický príklad: kontrolný zoznam preskúmania dodávateľa
Aby to bolo praktické, Anyin tím vytvoril kontrolný zoznam pre nové štvrťročné preskúmania s poskytovateľom správy vozového parku, založený na auditných metodikách uvedených v Zenith Controls.
| Oblasť preskúmania | Dôkazy na zhromaždenie a prerokovanie | Požadovaný výsledok |
|---|---|---|
| SLA a výkonnosť | Správy o dostupnosti, incidentné logy, časy vyriešenia ticketov podpory. | Overiť súlad so zmluvnými záväzkami v oblasti dostupnosti a podpory. |
| Bezpečnostné incidenty | Podrobná správa o všetkých bezpečnostných upozorneniach (vrátane „falošne pozitívnych“), analýza koreňovej príčiny a nápravné opatrenia. | Potvrdiť transparentné hlásenie a účinné riešenie incidentov. |
| Súlad a audity | Najnovšia správa SOC 2 alebo súhrn penetračného testovania. | Preskúmať zistenia a sledovať plán nápravy dodávateľa pre každú identifikovanú zraniteľnosť. |
| Riadenie zraniteľností | Správy o kadencii záplatovania kritických systémov. | Zabezpečiť, že dodávateľ plní svoju povinnosť včas záplatovať kritické zraniteľnosti. |
| Pripravované zmeny | Diskusia o produktovej roadmap dodávateľa, zmenách infraštruktúry alebo nových ďalších sprostredkovateľoch. | Proaktívne posúdiť bezpečnostné dôsledky budúcich zmien pred ich implementáciou. |
Tento jednoduchý nástroj zmenil rozhovor zo všeobecnej aktualizácie stavu na sústredené stretnutie riadenia bezpečnosti založené na dôkazoch a vytvoril auditovateľný záznam o priebežnom dohľade.
Definovanie hranice: akceptácia rizika vo svete NIS2
Pôvodný incident s dodávateľom prinútil Anyu riešiť základnú otázku: aká úroveň rizika je prijateľná? Aj pri najlepších zmluvách a monitorovaní vždy zostane určité reziduálne riziko. Preto je jasná definícia kritérií akceptácie rizika schválená vedením nevyhnutná.
V kroku 10 fázy „Riziká a implementácia“ poskytuje Zenith Blueprint k tomuto bodu zásadné usmernenie. Nestačí povedať „akceptujeme nízke riziká“. Musíte definovať, čo to znamená v kontexte vašich zákonných a regulačných povinností.
„V kritériách akceptácie zvážte aj zákonné/regulačné požiadavky. Niektoré riziká môžu byť neprijateľné bez ohľadu na pravdepodobnosť, a to z dôvodu právnych predpisov… Podobne NIS2 a DORA ukladajú určité požiadavky základnej bezpečnostnej úrovne – ich nesplnenie (aj keď je pravdepodobnosť incidentu nízka) môže predstavovať neprijateľné riziko nesúladu. Zahrňte tieto hľadiská, napr.: „Akékoľvek riziko, ktoré by mohlo viesť k nesúladu s uplatniteľnými právnymi predpismi (GDPR atď.), nie je prijateľné a musí byť zmiernené.““
Pre Anyu to znamenalo zásadnú zmenu. Spolu s právnym oddelením a obstarávaním aktualizovala politiku riadenia rizík. Nové kritériá výslovne uvádzali, že každý kritický dodávateľ, ktorý nespĺňa požiadavky základnej bezpečnostnej úrovne vyžadované NIS2, predstavuje neprijateľné riziko a musí sa preň okamžite spustiť plán ošetrenia rizík. Tým sa odstránila nejednoznačnosť z rozhodovania a vznikol jasný riadiaci spúšťač. Ako sa uvádza v Politike bezpečnosti tretích strán a dodávateľov:
„Výnimky s vysokým rizikom (napr. dodávatelia spracúvajúci regulované údaje alebo podporujúci kritické systémy) musia schváliť CISO, právne oddelenie a vedenie obstarávania a musia byť zapísané do Registra výnimiek ISMS.“ Zo sekcie „Ošetrenie rizík a výnimky“, ustanovenie politiky 7.3.
Audítor je tu: zvládnutie kontroly z viacerých uhlov
O šesť mesiacov neskôr, keď prišli interní audítori vykonať posúdenie pripravenosti na NIS2, bola Anya pripravená. Vedela, že jej program dodávateľského reťazca budú posudzovať z viacerých perspektív.
Audítor ISO/IEC 27001:2022: Tento audítor sa sústredil na proces a dôkazy. Vyžiadal si inventár dodávateľov, overil jeho kategorizáciu podľa rizika, vybral vzorku zmlúv na kontrolu konkrétnych bezpečnostných doložiek a preskúmal zápisnice zo štvrťročných preskúmaní. Jej štruktúrovaný prístup, postavený na opatreniach 5.19, 5.20 a 5.22, poskytol jasnú auditnú stopu.
Audítor COBIT 2019: Tento audítor so zameraním na riadenie chcel vidieť väzbu na ciele organizácie. Pýtal sa, ako sa dodávateľské riziko reportuje výkonnému výboru pre riziká. Anya predstavila svoj register rizík, ktorý ukazoval, ako bolo určené rizikové hodnotenie dodávateľa a ako sa mapovalo na celkový apetít spoločnosti na riziko.
Posudzovateľ NIS2: Táto osoba sa cielene zameriavala na systémové riziko pre základné služby. Nezaujímala ju len zmluva; chcela vedieť, čo by sa stalo, keby dodávateľ úplne prestal poskytovať službu. Anya ju previedla plánom kontinuity činností, ktorý už obsahoval časť o zlyhaní kritického dodávateľa vypracovanú v súlade s princípmi ISO/IEC 22301:2019.
Audítor GDPR: Keďže dodávateľ spracúval údaje o polohe, tento audítor sa okamžite zameral na ochranu údajov. Vyžiadal si zmluvu o spracúvaní osobných údajov (DPA) a dôkazy o náležitej starostlivosti pri overovaní, že dodávateľ poskytuje „dostatočné záruky“ požadované v Article 28. Keďže jej proces integroval ochranu súkromia od začiatku, DPA bola robustná.
Táto viacperspektívna auditná optika ukazuje, že dobre implementovaný ISMS založený na ISO/IEC 27001:2022 nespĺňa iba jednu normu. Vytvára odolnú a obhájiteľnú pozíciu v celom regulačnom prostredí. Nasledujúca tabuľka sumarizuje, ako tieto kroky vytvárajú auditovateľné dôkazy pre akúkoľvek kontrolu.
| Krok | Odkaz na politiku/opatrenie | Mapovanie na NIS2 | Mapovanie na GDPR | Mapovanie na DORA | Dôkaz o vykonaní |
|---|---|---|---|---|---|
| Určenie úrovní dodávateľov | 5.19, Blueprint S10/S23 | Article 21 | Article 28 | Art. 28-30 | Inventár dodávateľov v ISMS rozdelený podľa rizikových úrovní. |
| Bezpečnostné zmluvné doložky | 5.20, ISO/IEC 27036-2 | Article 22 | Article 28(3) | Art. 30 | Vzorky zmlúv s bezpečnostnými dodatkami a SLA. |
| Priebežné preskúmanie | 5.22, ISO/IEC 22301 | Article 21 | Article 32 | Art. 31 | Zápisnice zo stretnutí, dashboardy výkonnosti, auditné logy. |
| Podmienky ochrany údajov | 5.20, ISO/IEC 27701 | Recital 54 | Arts. 28, 32 | Art. 30 | Uzatvorené zmluvy o spracúvaní osobných údajov (DPA). |
| Oznamovanie incidentov | 5.22, ISO/IEC 27036-2 | Article 23 | Arts. 33, 34 | Art. 31 | Incidentné logy dodávateľa, komunikačné záznamy. |
| Ukončenie spolupráce | 5.20, ISO/IEC 27001:2022 A.5.11 | Relevantné pre odolnosť | Article 28(3) | Art. 30 | Potvrdenia o zničení údajov, kontrolné zoznamy vyradenia dodávateľa. |
Vaša príručka pre ďalšie kroky
Anyin príbeh nie je výnimočný. CISO a manažéri súladu v celej EÚ čelia tej istej výzve. Hrozba regulačných pokút a osobná zodpovednosť zavedená NIS2 robia z rizika dodávateľského reťazca jednu z najvyšších priorít organizácie. Dobrá správa je, že cesta vpred je jasná. Využitím štruktúrovaného prístupu ISO/IEC 27001:2022 založeného na riziku môžete vybudovať program, ktorý je súladný aj skutočne odolný.
Nečakajte, kým vás k akcii prinúti incident. Začnite budovať rámec dodávateľského reťazca v súlade s NIS2 už dnes:
- Zaveďte riadenie: Použite Politiku bezpečnosti tretích strán a dodávateľov – SME od Clarysec alebo podnikové šablóny na definovanie vykonávacích pravidiel.
- Poznajte svoj ekosystém: Použite klasifikačné kritériá zo Zenith Blueprint na identifikáciu a určenie úrovní vašich kritických dodávateľov s vysokým rizikom.
- Posilnite svoje zmluvy: Auditujte existujúce dodávateľské zmluvy voči požiadavkám opatrenia 5.20 podľa ISO/IEC 27001:2022 a využite usmernenia ku krížovému súladu v Zenith Controls na splnenie očakávaní NIS2, DORA a GDPR.
- Implementujte priebežné monitorovanie: Naplánujte prvé štvrťročné bezpečnostné preskúmanie s najkritickejším dodávateľom a použite náš kontrolný zoznam ako pomôcku. Všetky zistenia dokumentujte vo svojom ISMS.
- Pripravte auditné dôkazy: Zostavte vzorky zmlúv, zápisnice z preskúmaní, incidentné logy a posúdenia rizík namapované na základné opatrenia pre každého kritického dodávateľa.
Váš dodávateľský reťazec nemusí byť vaším najslabším článkom. So správnym rámcom, procesmi a nástrojmi ho môžete premeniť na zdroj sily a základný pilier svojej stratégie kybernetickej bezpečnosti.
Ste pripravení vybudovať dodávateľský reťazec, ktorý obstojí pred regulátormi aj predstavenstvom? Stiahnite si Clarysec Zenith Blueprint a urýchlite svoju cestu k súladu a odolnosti už dnes.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


