⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Riadenie CISA KEV pre ISO 27001, NIS2 a DORA

Igor Petreski
14 min read
Riadenie zraniteľností z CISA KEV a ENISA EUVD namapované na dôkazy pre ISO 27001, NIS2, DORA a GDPR

Piatková zraniteľnosť, z ktorej sa stala otázka pre predstavenstvo

Je piatok 16:40. Vedúci SOC vám prepošle upozornenie CISA KEV, skener zraniteľností potvrdí expozíciu na bráne dostupnej z internetu a ENISA EUVD obsahuje zodpovedajúci záznam o zneužívanej zraniteľnosti. Dodávateľ vydal záplatu, ale vlastník produkčného prostredia upozorňuje, že jej okamžité nasadenie môže narušiť službu určenú zákazníkom. Právne oddelenie sa pýta, či môžu byť dotknuté osobné údaje. Garant DORA sa pýta, či platforma podporuje kritickú alebo dôležitú funkciu. Koordinátor NIS2 sa pýta, či by sa z toho mohol stať významný incident.

CISO položí jedinú otázku, na ktorej záleží:

“Dokážeme preukázať, že sme prijali správne rozhodnutie, dostatočne rýchlo a so správnymi schváleniami?”

To je skutočný problém riadenia známych zneužívaných zraniteľností v roku 2026. Nejde iba o identifikáciu CVE alebo rýchlejšie nasadzovanie záplat. Ide o premenu spravodajstva o zneužívaní na obhájiteľný prevádzkový model: príjem, triáž, prioritizáciu, núdzovú zmenu, kompenzačné opatrenia, eskaláciu dodávateľovi, schválenie výnimky, uchovávanie dôkazov, reportovanie manažmentu a rozhodnutia o náprave pripravené na preverenie regulátorom.

Mnohé organizácie už majú SLA na nápravu zraniteľností. Niektoré majú zdroje spravodajstva o hrozbách. Niekoľko z nich prevádzkuje priebežné riadenie expozície. Keď je však zraniteľnosť už zneužívaná v reálnom prostredí, kontext rizika sa mení. Známa zneužívaná zraniteľnosť uvedená v CISA KEV alebo ENISA EUVD nemá zostať v rovnakom rade ako bežný backlog záplat. Má spustiť odlišnú cestu riadenia, pretože riziko už nie je teoretické.

Pozícia Clarysec je jednoduchá: náprava riadená exploitmi sa má riadiť ako podnikový proces produkujúci dôkazy, nie ako neformálny technický zhon. Tento proces možno vybudovať na ISO/IEC 27001:2022 ISO/IEC 27001:2022, posilniť prostredníctvom ISO/IEC 27002:2022 ISO/IEC 27002:2022 a namapovať na očakávania riadenia podľa NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 19.

Od záplatovania k preukázateľnému riadeniu

Tradičné riadenie zraniteľností často začína závažnosťou: skóre CVSS, kritickosť aktíva, expozícia a dostupnosť záplaty. Riadenie zamerané na exploity pridáva ostrejšiu otázku: používajú už túto zraniteľnosť útočníci a máme dotknuté aktíva, dodávateľov, cloudové služby alebo toky údajov?

Táto zmena mení pracovný tok. Známa zneužívaná zraniteľnosť má spustiť:

  1. Validáciu spravodajstva o hrozbách z dôveryhodných zdrojov, ako sú CISA, ENISA, národné tímy CERT, dodávatelia, ISAC a MSSP.
  2. Koreláciu aktív vrátane dostupnosti z internetu, podnikovej funkcie, klasifikácie údajov a závislosti od dodávateľov.
  3. Núdzové rozhodnutie o riziku vrátane okamžitého záplatovania, izolácie, vypnutia funkcie, použitia zmierňujúceho opatrenia, monitorovania alebo dočasnej akceptácie zostatkového rizika.
  4. Schválenie zmeny so sledovateľnosťou, aj keď je zmena urýchlená.
  5. Zaistenie dôkazov vrátane časových pečiatok, schválení, logov, snímok obrazovky, výsledkov skenovania, vyhlásení dodávateľov a záznamov o kompenzačných opatreniach.
  6. Reportovanie manažmentu, najmä ak zraniteľnosť ovplyvňuje kritické služby, osobné údaje, regulované finančné služby alebo základné či dôležité služby podľa NIS2.
  7. Validáciu po náprave a poučenia.

ISO 27001:2022 dáva tomuto pracovnému toku rámec riadenia. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia pochopila interné a externé otázky, zainteresované strany, zákonné a regulačné požiadavky, rozhrania a závislosti, a následne definovala a udržiavala rozsah ISMS. Pri riadení zraniteľností to znamená, že rozsah musí zahŕňať reálne systémy, cloudové služby, tretie strany a regulované služby, pri ktorých expozícia zneužívaným zraniteľnostiam môže vytvoriť dopad na činnosť organizácie.

Kapitoly 5.1 až 5.3 posúvajú túto otázku za hranice prevádzky IT. Vrcholový manažment musí zosúladiť ISMS so strategickým smerovaním, priradiť zodpovednosti, prideliť zdroje, komunikovať význam zhody a prijímať reporty o výkonnosti. V praxi zhoda CISA KEV na kritickej službe nie je iba požiadavka na záplatu. Je to udalosť preukázateľnej zodpovednosti vrcholového vedenia.

Kapitoly 6.1.1 až 6.1.3 poskytujú rizikový základ: kritériá rizika, vlastníkov rizík, posúdenie pravdepodobnosti a následkov, možnosti ošetrenia, Vyhlásenie o uplatniteľnosti, plán ošetrenia a akceptáciu zostatkového rizika. Toto je mechanizmus, ktorý mení vetu “zatiaľ sme nemohli záplatovať” na zdokumentovanú, schválenú a časovo obmedzenú výnimku s kompenzačnými opatreniami.

Kapitola 8.1 je potom dôležitá, keď tím prechádza od rozhodnutia k vykonaniu. Vyžaduje prevádzkové plánovanie a riadenie vrátane riadenia plánovaných zmien a preskúmania neúmyselných zmien. Pri udalosti KEV musí byť organizácia rýchla bez toho, aby stratila kontrolu.

Trojuholník opatrení Clarysec pre zneužívané zraniteľnosti

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls považuje riadenie známych zneužívaných zraniteľností za kombináciu troch ústredných tém opatrení podľa ISO/IEC 27002:2022. Uvádza súvisiace tematické opatrenia ako “Informácie o hrozbách (5.7)”, “Riadenie technických zraniteľností (8.8)” a “Riadenie zmien (8.32)”.

Spoločne tieto opatrenia tvoria praktický trojuholník:

Otázka riadeniaTéma opatrenia ISO/IEC 27002:2022Prevádzkový dôkaz
Ako sme vedeli, že na tejto zraniteľnosti záleží?5.7 Informácie o hrozbáchPríjem CISA KEV alebo ENISA EUVD, bezpečnostné upozornenie dodávateľa, upozornenie CERT, validačné poznámky, dotaz na dotknuté aktíva
Ako sme ju posúdili a odstránili?8.8 Riadenie technických zraniteľnostíZáznam o zraniteľnosti, výsledok skenu, hodnotenie rizika, vlastník, SLA, záplata alebo zmierňujúce opatrenie, overovací sken
Ako sme bezpečne zmenili produkčné prostredie?8.32 Riadenie zmienZáznam núdzovej zmeny, schválenie, výsledok testu, plán návratu k pôvodnému stavu, log nasadenia, preskúmanie po zmene

Tento trojuholník predchádza bežnému auditnému zlyhaniu: zaobchádzaniu s riadením zraniteľností ako s výstupom skenera namiesto riadeného reťazca rozhodnutí. Audítor, regulátor alebo tím zákazníckeho uistenia sa nebude pýtať iba na to, či bola záplata nasadená. Bude sa pýtať, ako organizácia vedela, prioritizovala, schválila, implementovala a overila rozhodnutie.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to konkretizuje vo fáze Controls in Action, kroku 22, kde tímom odporúča vytvoriť register spravodajstva o hrozbách:

Vytvorte zdokumentovaný zoznam zdrojov spravodajstva o hrozbách (5.7) od dodávateľov, ISAC alebo otvorených zdrojov a určite, ako sa informácie validujú a integrujú do rozhodovania. Definujte, kto prijíma aktualizácie o hrozbách a ako sa používajú (napr. prioritizácia záplat, školenie bezpečnostného povedomia).

V kroku 19 Zenith Blueprint rámcuje riadenie zraniteľností ako modernú kybernetickú hygienu a zdôrazňuje urýchlenú nápravu kritických zraniteľností:

Riadenie zraniteľností je jednou z najkritickejších oblastí modernej kybernetickej hygieny. Hoci firewally a antivírusové nástroje poskytujú ochranu, môžu byť oslabené, ak zostanú vystavené nezaplátané systémy alebo nesprávne nakonfigurované služby.

Zároveň upozorňuje, že zistenia zo skenov sa nesmú pasívne archivovať. Musia byť triážované, priradené a sledované až do uzavretia. Presne takúto disciplínu vyžaduje riadenie CISA KEV a ENISA EUVD.

Politika mení naliehavosť na pravidlá

Model riadenia funguje iba vtedy, keď sa premietne do politiky. Podniková Politika riadenia zraniteľností a záplat Clarysec Politika riadenia zraniteľností a záplat, v kontexte toolkitov uvádzaná aj ako P19 Politika riadenia zraniteľností a záplat, jasne priraďuje požiadavku na monitorovanie a eskaláciu:

Monitorujte upozornenia na hrozby (napr. CVE, CISA KEV, bulletiny dodávateľov) a eskalujte kritické zraniteľnosti.

Zo sekcie “Roly a zodpovednosti”, kapitola politiky 4.5.1.

Tá istá podniková politika definuje prísne očakávanie nápravy kritických zraniteľností:

Kritické (CVSS 9.0-10.0): okamžité preskúmanie; lehota záplatovania maximálne 72 hodín.

Zo sekcie “Požiadavky na riadenie”, kapitola politiky 5.2.1.

Pre MSP politika Clarysec Vulnerability and Patch Management Policy-sme Politika riadenia zraniteľností a záplat – MSP, uvádzaná aj ako P19S Vulnerability and Patch Management Policy-sme, robí ten istý koncept prevádzkovým a priamym:

Dôveryhodné upozornenia spravodajstva o hrozbách (napr. CISA, ENISA, upozornenia národných tímov CERT)

Zo sekcie “Požiadavky na implementáciu politiky”, kapitola politiky 6.2.1.3.

Stanovuje aj praktický štandard záplatovania:

Kritické záplaty musia byť nasadené do 3 dní od vydania, najmä pri systémoch dostupných z internetu

Zo sekcie “Požiadavky na implementáciu politiky”, kapitola politiky 6.1.1.

Formulácia “najmä pri systémoch dostupných z internetu” je dôležitá. Riadenie známych zneužívaných zraniteľností musí uprednostniť exponované systémy, služby vzdialeného prístupu, infraštruktúru identít, okrajové zariadenia, administračné panely SaaS a systémy spracúvajúce citlivé alebo regulované údaje.

Čo sa však stane, keď organizácia nedokáže záplatovať v rámci SLA? Podniková politika uzatvára cyklus:

Ak zraniteľnosť nemožno odstrániť v rámci definovaných SLA z prevádzkových, technických alebo dodávateľských obmedzení, musí byť predložená formálna žiadosť o výnimku.

Zo sekcie “Ošetrenie rizík a výnimky”, kapitola politiky 7.1.

Verzia pre MSP vyžaduje logy záplatovania, ktoré podporujú auditovateľnosť:

Logy musia obsahovať názov zariadenia, použitú aktualizáciu, dátum záplatovania a dôvod každého omeškania

Zo sekcie “Požiadavky na riadenie”, kapitola politiky 5.4.2.

Tieto ustanovenia politiky vytvárajú dôkazovú kostru. Umožňujú CISO povedať: máme pravidlá pre príjem spravodajstva, prioritizáciu, lehoty záplatovania, výnimky a dôvody omeškania. To je rozdiel medzi reaktívnym záplatovaním a riadenou nápravou.

Núdzová zmena bez straty kontroly

Známe zneužívané zraniteľnosti často vynútia núdzové zmeny. Čakanie na najbližšie zasadnutie výboru pre zmeny môže byť nedbanlivé. Úplné obídenie riadenia zmien môže byť riskantné. Riešením je urýchlené a sledovateľné riadenie zmien.

Podniková Politika riadenia zmien Clarysec Politika riadenia zmien, uvádzaná aj ako P05 Politika riadenia zmien, stanovuje:

Núdzové zmeny môžu pokračovať na základe urýchleného ústneho alebo delegovaného schválenia od oprávnených rolí.

Zo sekcie “Požiadavky na implementáciu politiky”, kapitola politiky 6.5.1.

Pre MSP Politika riadenia zmien Clarysec Politika riadenia zmien – MSP uznáva rovnakú prevádzkovú realitu:

Núdzové alebo neplánované zmeny môžu byť implementované okamžite ako reakcia na kritické výpadky alebo hrozby. Avšak:

Zo sekcie “Ošetrenie rizík a výnimky”, kapitola politiky 7.4.1.

Slovo “avšak” je miestom, kde sa prejavuje riadenie. Núdzová zmena má aj naďalej dokumentovať spúšťač, dotknuté systémy, rozhodnutie o riziku, schvaľovateľa, čas implementácie, výsledok validácie a spätné preskúmanie. Zenith Blueprint, fáza Controls in Action, krok 21, opisuje riadenie zmien ako opakovateľný pracovný tok, v ktorom sa zmeny hodnotia, autorizujú, implementujú a preskúmavajú. Upozorňuje, že mnohé incidenty nespôsobujú útočníci, ale nesprávne riadené zmeny: pravidlo firewallu otvorené príliš široko, ponechané zapnuté debug nastavenie alebo zabudnutá závislosť po migrácii.

Pri náprave známej zneužívanej zraniteľnosti má minimálny dôkazový materiál k núdzovej zmene obsahovať:

Dôkazová položkaPrečo je dôležitá
Zdroj hrozby a časová pečiatkaUkazuje, kedy sa organizácia dozvedela o aktívnom zneužívaní
Zoznam dotknutých aktívPreukazuje analýzu rozsahu a prioritizáciu
Vlastník podniku a vlastník rizikaUkazuje zodpovedné rozhodovanie
Rozhodnutie o záplate alebo zmierňujúcom opatreníUkazuje vybranú možnosť ošetrenia
Núdzové schválenieUkazuje riadenú autorizáciu pod tlakom
Poznámka k testu alebo plánu návratu k pôvodnému stavuUkazuje, že sa zohľadnilo prevádzkové riziko
Logy nasadeniaUkazujú, že implementácia prebehla
Validačný sken alebo kontrola konfigurácieUkazuje účinnosť nápravy
Záznam o výnimke, ak nebolo záplatovanéUkazuje, že zostatkové riziko bolo formálne ošetrené
Oznámenie manažmentuUkazuje eskaláciu pri kritickej expozícii

Toto nie je byrokracia. Je to minimálna životaschopná auditná stopa pre rozhodnutie prijaté pod tlakom protivníka.

Mapovanie CISA KEV a ENISA EUVD na dôkazy ISO 27001

ISO 27001:2022 nevyžaduje konkrétny zdroj spravodajstva o hrozbách. Vyžaduje, aby organizácia identifikovala požiadavky, riadila riziko, implementovala opatrenia, uchovávala zdokumentované informácie a zlepšovala sa. CISA KEV a ENISA EUVD sa môžu stať autoritatívnymi vstupmi do tohto systému riadenia.

Aktivita riadená exploitmiDôkazy podľa ISO 27001:2022 a prílohy A
Udržiavať register zdrojov KEV a EUVDDôkazy podľa kapitol 4.1, 4.2, 4.4 a prílohy A 5.7
Korelovať zneužívané CVE s aktívami a dodávateľmiDôkazy k posúdeniu rizík podľa kapitoly 6.1 a prílohy A 5.9, 5.19, 5.20, 5.21, 5.22 a 5.23
Prioritizovať služby dostupné z internetu a kritické službyKritériá rizika a prioritizácia ošetrenia podľa kapitoly 6.1
Aplikovať záplaty alebo zmierňujúce opatreniaPríloha A 8.8 Riadenie technických zraniteľností
Použiť schválenie núdzovej zmenyKapitola 8.1 a príloha A 8.32 Riadenie zmien
Zaznamenávať omeškania a výnimkyAkceptácia zostatkového rizika a plán ošetrenia podľa kapitoly 6.1.3
Uchovávať dôkazyPríloha A 5.28 Zhromažďovanie dôkazov a zdokumentované informácie podľa kapitoly 7.5
Reportovať trendy manažmentuVýkonnosť a preskúmanie manažmentom podľa kapitol 5.3, 9.1 a 9.3
Aktualizovať opatrenia po incidentoch alebo takmer vzniknutých incidentochPríloha A 5.27 Poučenie z incidentov informačnej bezpečnosti a zlepšovanie podľa kapitoly 10

Zenith Blueprint, fáza Risk Management, krok 13, odporúča sledovateľnosť medzi rizikami, opatreniami a kapitolami:

Krížovo odkazujte predpisy: Ak sú určité opatrenia implementované osobitne na dosiahnutie súladu s GDPR, NIS2 alebo DORA, môžete to uviesť buď v registri rizík (ako súčasť odôvodnenia dopadu rizika), alebo v poznámkach k SoA.

Pri známej zneužívanej zraniteľnosti by záznam v registri rizík nemal uvádzať iba “Záplatovať CVE”. Má identifikovať zdroj hrozby, dotknutú službu, regulačnú relevantnosť, vlastníka rizika, ošetrenie, odkazy na opatrenia a umiestnenie dôkazov.

Mapovanie krížového súladu pre NIS2, DORA, GDPR a reportovanie riadenia

Hodnota riadenia zameraného na exploity spočíva v tom, že jeden riadený pracovný tok dokáže odpovedať na viacero regulačných otázok. Ten istý záznam, záznam o zmene, formulár výnimky, e-mail od dodávateľa a validačný sken môžu podporiť odlišné dôkazové naratívy, ak sú zámerne namapované.

RámecRelevantné požiadavkyAko riadenie zamerané na exploity poskytuje dôkazy
ISO/IEC 27001:2022Kapitoly 6.1.2, 6.1.3 a 8.1, príloha A 5.7, 8.8 a 8.32Preukazuje posúdenie rizík, ošetrenie rizík, prevádzkové riadenie, spravodajstvo o hrozbách, riadenie zraniteľností a riadenú zmenu
Smernica NIS2Article 20, Article 21 a Article 23Ukazuje dohľad manažmentu, riešenie zraniteľností, kybernetickú hygienu, zohľadnenie dodávateľského reťazca a posúdenie hlásenia incidentu
DORAArticles 5, 6, 9, 13, 17, 28 a 30Ukazuje riadenie IKT, riadenie rizík IKT, ochranu, spravodajstvo o hrozbách, riadenie incidentov a riadenie rizika tretích strán
GDPRArticles 5(2), 25 a 32Ukazuje zodpovednosť, ochranu údajov už od návrhu a štandardne a primerané technické a organizačné bezpečnostné opatrenia
NIST CSF 2.0GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVERPremieta pracovný tok do exekutívneho rizika, kontextu aktív, opatrení, telemetrie, eskalácie a výsledkov obnovy
COBIT 19Riadenie, optimalizácia rizík, monitorovanie výkonnosti a uistenieUkazuje rozhodovacie právomoci, vlastníctvo, metriky, zosúladenie s apetítom na riziko, dohľad nad výnimkami a nezávislé uistenie

NIS2 mení diskusiu pre základné a dôležité subjekty, pretože Article 20 robí z kybernetickej bezpečnosti otázku zodpovednosti riadiaceho orgánu. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, riešenia a zverejňovania zraniteľností, kybernetickej hygieny, riadenia prístupu, správy aktív a autentifikácie.

Article 23 pridáva postupné hlásenie významných incidentov vrátane včasného varovania do 24 hodín, oznámenia do 72 hodín a záverečnej správy do jedného mesiaca po oznámení incidentu. Zhoda s CISA KEV alebo ENISA EUVD nie je automaticky incident podliehajúci hláseniu. Má však spustiť zdokumentované posúdenie incidentu, ak je pravdepodobné zneužitie, prerušenie služby, ujma zákazníkov alebo dopad na údaje.

DORA pridáva odvetvový pohľad pre finančné subjekty. Uplatňuje sa od 17. januára 2025 a vyžaduje riadenie, zdokumentované riadenie rizík IKT, testovanie, odolnosť, riadenie incidentov a riadenie rizík externých poskytovateľov IKT. Article 13 je osobitne relevantný, pretože vyžaduje schopnosti týkajúce sa zraniteľností a spravodajstva o kybernetických hrozbách, poučení a monitorovania technologického vývoja. Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT, ktorý zaznamenáva incidenty a významné kybernetické hrozby, klasifikuje ich podľa priority a závažnosti, eskaluje ich, identifikuje koreňové príčiny a obnovuje bezpečnú prevádzku.

DORA Articles 28 a 30 zároveň vynucujú disciplínu dodávateľov. Ak platobná platforma závisí od cloudového WAF, spravovanej databázy, poskytovateľa identít alebo workflow enginu SaaS dotknutého známou zneužívanou zraniteľnosťou, dôkazy nemôžu skončiť pri vyjadrení “dodávateľ tvrdí, že záplatoval”. Majú obsahovať oznámenie dodávateľa, posúdenie kritickosti, použité zmluvné práva, kompenzačné opatrenia, posúdenie dopadu na zákazníkov a overenie po náprave.

GDPR pridáva otázku zameranú na údaje. Article 32 vyžaduje bezpečnosť spracúvania, zatiaľ čo Article 5(2) vytvára zodpovednosť. Preskúmanie ochrany súkromia má začať pred potvrdeným porušením, nie až po preukázaní exfiltrácie.

Dôkazová otázka GDPRPraktická odpoveď
Spracúva dotknuté aktívum osobné údaje?Odkaz na register inventára údajov a rola prevádzkovateľa alebo sprostredkovateľa
Aké kategórie osobných údajov sú zahrnuté?Klasifikácia údajov a účel spracúvania
Mohlo by zneužitie ovplyvniť dôvernosť, integritu alebo dostupnosť?Posúdenie dopadu na CIA
Boli zavedené šifrovanie, riadenie prístupu alebo segmentácia?Dôkaz opatrení a odkaz na konfiguráciu
Bolo podozrenie alebo potvrdenie porušenia ochrany osobných údajov?Posúdenie incidentu a právne preskúmanie
Zvažovalo sa oznámenie dozornému orgánu?Záznam rozhodnutia o porušení ochrany osobných údajov podľa GDPR
Boli dotknuté dotknuté osoby?Posúdenie dopadu a komunikácie

Praktický záznam o náprave KEV a EUVD

Zvážte realistický scenár. ENISA EUVD a CISA KEV indikujú aktívne zneužívanie zraniteľnosti, ktorá ovplyvňuje službu prenosu súborov dostupnú z internetu. Služba podporuje onboarding zákazníkov a uchováva obmedzený rozsah osobných údajov. Záplata dodávateľa existuje, ale vlastník aplikácie žiada údržbové okno a jeden súvisiaci komponent SaaS závisí od nápravy dodávateľom.

Vytvorte jeden záznam v registri riadenia zraniteľností s týmito poľami:

PolePríklad záznamu
Zdroj spravodajstvaCISA KEV, ENISA EUVD, bulletin dodávateľa, upozornenie národného CERT
Dátum a čas identifikácie2026-05-29 16:40 UTC
ZraniteľnosťIdentifikátor CVE, produkt dodávateľa, dotknuté verzie
Stav zneužívaniaZnáma zneužívaná zraniteľnosť, dostupný verejný exploit, dodávateľ potvrdzuje aktívne zacielenie
Korelácia aktívProdukčná brána na prenos súborov pre onboarding dostupná z internetu
Podniková službaOnboarding zákazníkov, regulovaný zákaznícky pracovný tok
Dopad na údajePrítomné osobné údaje, obmedzené identifikátory a nahrané dokumenty
Regulačné príznakyRozsah ISMS podľa ISO 27001, posúdenie služby podľa NIS2, dôkaz podľa GDPR Article 32, DORA, ak ide o podporu finančnej služby
Počiatočné hodnotenie rizikaKritické vzhľadom na aktívne zneužívanie a dostupnosť z internetu
Rozhodnutie o ošetreníNúdzová záplata do 24 hodín, okamžité pravidlo WAF, zvýšené logovanie
Cesta zmenyNúdzová zmena s delegovaným schválením
SchvaľovateľDelegát CISO a vlastník služby
Kompenzačné opatreniaObmedzenie IP, virtuálna záplata WAF, pravidlo EDR, monitorovanie SIEM, dočasné limity nahrávania
Potrebná výnimkaVyžaduje sa iba pre komponent SaaS čakajúci na nápravu dodávateľom
ValidáciaSkener bez nálezu, verzia overená, logy preskúmané na indikátory
Umiestnenie dôkazovOdkaz na záznam, dotaz SIEM, záznam o zmene, log záplaty, snímka obrazovky, oznámenie dodávateľa
PoučeniaPridať službu do týždennej kontroly expozície a playbooku oznamovania dodávateľom

Následne uplatnite pravidlá politík Clarysec:

  • Použite podnikovú Politiku riadenia zraniteľností a záplat, ak prevádzkujete väčšiu organizáciu s formálnymi rolami, SLA a eskaláciou.
  • Použite Vulnerability and Patch Management Policy-sme pre MSP, ak potrebujete jednoduchý, ale auditovateľný model.
  • Použite podnikovú Politiku riadenia zmien alebo Politiku riadenia zmien pre MSP na zdokumentovanie núdzového schválenia, testovania, nasadenia a spätného preskúmania.
  • Prepojte záznam s registrom rizík a Vyhlásením o uplatniteľnosti, ako odporúča Zenith Blueprint, krok 13.
  • Označte opatrenia v Zenith Controls ako 5.7, 8.8 a 8.32 a následne doplňte podporné dôkazy pre riadenie dodávateľov, cloudové riadenie, logovanie, riadenie incidentov a kontinuitu činností, ak sú relevantné.

Napokon uchovajte auditné dôkazy. Podniková Politika monitorovania auditov a súladu Clarysec Politika monitorovania auditov a súladu, uvádzaná aj ako P33 Politika monitorovania auditov a súladu, definuje výslovný cieľ:

Vytvárať obhájiteľné dôkazy a auditnú stopu na podporu regulačných preverení, súdnych konaní alebo požiadaviek zákazníkov na preukázanie súladu.

Zo sekcie “Ciele”, kapitola politiky 3.4.

To je zmysel pracovného toku. Neodstraňujete iba zraniteľnosť. Produkujete obhájiteľné dôkazy, že organizácia konala primerane, včas a pod kontrolou.

Ako audítori otestujú rovnaké rozhodnutie KEV

Zrelý proces známych zneužívaných zraniteľností musí obstáť pri rôznych auditných pohľadoch.

Audítor ISO 27001:2022 začne rozsahom ISMS, zainteresovanými stranami, regulačnými povinnosťami, metódou posúdenia rizík, Vyhlásením o uplatniteľnosti a zdokumentovanými informáciami. Bude sa pýtať, či je spravodajstvo o hrozbách integrované do posúdenia rizík, či je riadenie zraniteľností opakovateľné, či sú núdzové zmeny riadené, či je zostatkové riziko akceptované správnym vlastníkom rizika a či sa dôkazy uchovávajú.

Posudzovateľ orientovaný na NIS2 sa zameria na zodpovednosť manažmentu, opatrenia riadenia rizík podľa Article 21, zraniteľnosti dodávateľov, riešenie incidentov, kontinuitu činností a posúdenie významného incidentu podľa Article 23. Bude ho zaujímať časová pečiatka, eskalácia, záznamy rozhodnutí a to, či boli príslušné riadiace orgány informované.

Audítor DORA alebo príslušný orgán sa bude pýtať, či rámec riadenia rizík IKT zachytil dotknuté aktívum, podnikovú funkciu, závislosť a službu tretej strany. Bude očakávať klasifikáciu incidentu, záznamy o významných kybernetických hrozbách, eskaláciu manažmentu, následné činnosti k príčine, dôkazy od dodávateľov, testovanie a sledovanie nápravy.

Recenzent GDPR sa bude pýtať, či boli zahrnuté osobné údaje, či mohla byť ovplyvnená dôvernosť, integrita alebo dostupnosť, aké technické a organizačné opatrenia boli zavedené, či bolo posúdené oznámenie porušenia ochrany osobných údajov a či existujú dôkazy zodpovednosti.

Posudzovateľ NIST CSF 2.0 môže použiť CSF Core a Profiles na overenie, či sú definované a merané výsledky riadenia, identifikácie, ochrany, detekcie, reakcie a obnovy. Praktický cieľový profil by mohol uvádzať: “Všetky známe zneužívané zraniteľnosti ovplyvňujúce kritické aktíva dostupné z internetu sú triážované do 24 hodín, ošetrené do 72 hodín alebo formálne výnimkované s kompenzačnými opatreniami a schválením vlastníka rizika.”

Audítor COBIT 19 sa bude pýtať, kto je zodpovedný, či sú definované ciele riadenia, či apetít na riziko určuje naliehavosť, či sa preskúmavajú ukazovatele výkonnosti, či sa monitorujú výnimky a či funkcie uistenia nezávisle testujú proces.

Ten istý dôkazový záznam má odpovedať všetkým. To je hodnota inžinierstva krížového súladu.

Metriky, ktoré má vidieť predstavenstvo

Predstavenstvá nepotrebujú zoznam každého CVE. Potrebujú metriky kvality rozhodovania, ktoré ukazujú expozíciu, rýchlosť reakcie a zostatkové riziko. Pre riadenie známych zneužívaných zraniteľností Clarysec odporúča stručný manažérsky report s týmito položkami:

MetrikaPrečo je dôležitá
Počet zhôd KEV alebo EUVD za obdobieUkazuje objem expozície voči hrozbám
Percento ovplyvňujúce aktíva dostupné z internetuUkazuje riziko externej útočnej plochy
Percento ovplyvňujúce kritické služby alebo osobné údajeUkazuje podnikovú a regulačnú relevantnosť
Medián času do triážeUkazuje rýchlosť príjmu
Medián času do nápravyUkazuje prevádzkovú účinnosť
Počet porušení SLAUkazuje problémy s účinnosťou opatrení
Otvorené výnimky podľa vlastníka rizikaUkazuje zodpovednosť za zostatkové riziko
Omeškania nápravy spôsobené dodávateľomUkazuje riziko závislosti od tretích strán
Potvrdené udalosti zneužitiaUkazuje relevantnosť incidentov
Opakovane zraniteľné aktívaUkazuje systémové problémy hygieny

Tieto metriky podporujú preskúmanie manažmentom podľa ISO 27001, zodpovednosť manažmentu podľa NIS2, reportovanie rizík IKT podľa DORA a komunikáciu riadenia podľa NIST CSF. Zároveň pomáhajú vlastníkom podniku pochopiť, prečo kapacita záplatovania, kvalita inventarizácie aktív, zmluvy s dodávateľmi a údržbové okná nie sú “IT detaily”. Sú to rozhodnutia o odolnosti.

Bežné vzorce zlyhaní, ktoré treba odstrániť

V posúdeniach Clarysec riadenie známych zneužívaných zraniteľností zvyčajne zlyháva predvídateľnými spôsobmi.

Po prvé, zdroje spravodajstva sú neformálne. Jeden bezpečnostný inžinier sleduje CISA KEV, ďalší bulletiny dodávateľov a tretí sa spolieha na výstup skenera. Neexistuje zdokumentovaný register spravodajstva o hrozbách, pravidlo validácie ani vlastníctvo.

Po druhé, korelácia aktív je slabá. Organizácia vie, že CVE existuje, ale nevie rýchlo identifikovať, kde produkt beží, či je dostupný z internetu, kto ho vlastní, aké údaje spracúva alebo ktorý dodávateľ ho spravuje.

Po tretie, núdzová zmena je buď príliš pomalá, alebo príliš nekontrolovaná. Tímy čakajú dni na schválenie alebo záplatujú produkčné prostredie bez poznámok k návratu k pôvodnému stavu, validácie alebo spätného preskúmania.

Po štvrté, výnimky sú vágne. “Nemožno záplatovať z dôvodu dopadu na činnosť organizácie” nie je akceptácia rizika. Riadna výnimka musí definovať obmedzenie, dotknuté aktíva, kompenzačné opatrenia, zostatkové riziko, schvaľovateľa, dátum skončenia platnosti a periodicitu preskúmania.

Po piate, dôkazy sú roztrúsené. Snímky obrazovky zo skenera, schválenia v chate, e-maily dodávateľov, dotazy SIEM a záznamy o zmenách sú na rôznych miestach. Počas auditu alebo regulačného preverenia organizácia nedokáže zrekonštruovať časovú os rozhodnutí.

Riešením nie je viac šumu. Je ním jeden pracovný tok riadenia zameraný na exploity, ktorý integruje procesy spravodajstva, rizík, zmien, incidentov, dodávateľov a dôkazov.

Vybudujte dôkazový engine riadený exploitmi

Známe zneužívané zraniteľnosti zostanú v roku 2026 prevádzkovým problémom s vysokým objemom. CISA KEV a ENISA EUVD zviditeľňujú spravodajstvo o zneužívaní, ale samotná viditeľnosť nespĺňa dôkazové očakávania ISO 27001:2022, NIS2, DORA ani GDPR. Potrebujete riadený proces, ktorý mení spravodajstvo na akciu a akciu na dôkaz.

Začnite štyrmi krokmi:

  1. Vytvorte register spravodajstva o hrozbách pomocou Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, fáza Controls in Action, krok 22.
  2. Zosúlaďte pravidlá politík s Politikou riadenia zraniteľností a záplat Clarysec Politika riadenia zraniteľností a záplat alebo Vulnerability and Patch Management Policy-sme Politika riadenia zraniteľností a záplat – MSP.
  3. Použite Zenith Controls: The Cross-Compliance Guide Zenith Controls na mapovanie 5.7 Informácie o hrozbách, 8.8 Riadenie technických zraniteľností a 8.32 Riadenie zmien na dôkazové potreby ISO, NIS2, DORA, GDPR, NIST a COBIT.
  4. Otestujte jeden reálny prípad KEV alebo EUVD end-to-end, od príjmu cez nápravu, ošetrenie výnimiek, núdzovú zmenu, validáciu až po reportovanie manažmentu.

Clarysec vám môže pomôcť premeniť tento prístup na funkčný prevádzkový model pripravený na audit: politiky, registre, šablóny dôkazov, mapovania krížového súladu a reportovanie pre predstavenstvo, vďaka ktorým je náprava riadená exploitmi obhájiteľná pred audítorom, regulátorom aj vašimi zákazníkmi.

Stiahnite si Zenith Blueprint, preskúmajte Zenith Controls alebo požiadajte o posúdenie pripravenosti Clarysec, aby ste vybudovali pracovný tok riadenia CISA KEV a ENISA EUVD skôr, než sa ďalšia piatková zraniteľnosť stane otázkou pre predstavenstvo.

Frequently Asked Questions

About the Author

Igor Petreski

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

Share this article

Related Articles

Riadenie bezpečnosti CI/CD pipeline pre audity v roku 2026

Riadenie bezpečnosti CI/CD pipeline pre audity v roku 2026

Praktický sprievodca pre CISO k riadeniu CI/CD pipeline ako auditovateľných systémov softvérového dodávateľského reťazca s pôvodom zostavenia, hardenovanými runnermi, podpísanými artefaktmi, dôkazmi o nasadení a mapovaniami politík Clarysec.