Prioritizace zranitelností podle rizika pro rok 2026

Je úterý 08:17 na začátku roku 2026. Skener zranitelností dokončil noční běh a dashboard svítí červeně. Tým infrastruktury vidí 1 842 zjištění. Vlastník cloudové platformy říká, že pouze 73 z nich je dosažitelných z internetu. Manažer pro soulad se připravuje na posouzení NIS2 a DORA. Vedoucí pro ochranu osobních údajů se ptá, zda některý z dotčených systémů zpracovává osobní údaje. SOC chce vědět, zda jsou některé z nich zneužívány v reálném prostředí. Ředitel informační bezpečnosti (CISO) potřebuje jednu odpověď pro vývojové a provozní týmy, druhou pro správní radu a třetí pro příští audit ISO 27001.
Poté správní rada položí nejnebezpečnější otázku v řízení zranitelností:
“Proč jsme nejdříve opravili právě tuto zranitelnost?”
V roce 2026 už prioritizace zranitelností není cvičením v třídění výstupů skeneru. Je to rozhodnutí v oblasti správy a řízení. Závažnost podle CVSS 4.0 je důležitá, ale neřekne vám, zda zranitelný systém podporuje autentizaci zákazníků, ukládá platební metadata, umožňuje vzdálený přístup, zpracovává záznamy zákazníků z EU, závisí na poskytovateli ICT služeb třetí strany nebo se objevuje ve zdrojích známého zneužívání, jako je KEV nebo informace související s EUVD.
EPSS doplňuje pravděpodobnost zneužití, ale pravděpodobnost není dopad na podnikání. Kritičnost aktiv doplňuje kontext, ale pouze tehdy, pokud je evidence aktiv spolehlivá. GDPR mění výpočet, když zranitelné systémy zpracovávají osobní údaje. NIS2 a DORA jej mění znovu, pokud by narušení mohlo ovlivnit základní služby, důležité subjekty, finanční služby, kritické nebo důležité funkce, závislosti na třetích stranách v oblasti ICT nebo regulovanou provozní odolnost.
Právě tuto mezeru Clarysec vidí v reálných auditech. Mnoho organizací dokáže předložit zprávu ze skenu a ticket k záplatě. Méně z nich dokáže předložit obhajitelný rozhodovací model. Nedokážou prokázat, proč byla jedna zranitelnost řešena jako urgentní, proč byla jiná dočasně akceptována nebo proč odložená záplata nevytvořila neřízenou expozici.
Odpovědí Clarysec je převést prioritizaci zranitelností na auditovatelné důkazy o rizicích, a to s využitím Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, politik Clarysec a Zenith Controls: průvodce souladem napříč rámci Zenith Controls jako provozního modelu.
Proč řízení zranitelností založené primárně na CVSS v roce 2026 selhává
Většina programů řízení zranitelností stále začíná závažností ze skeneru. Je to pochopitelné. CVSS 4.0 poskytuje strukturovaný technický základ pro posouzení závažnosti, včetně dimenzí zneužitelnosti a dopadu. Je užitečný, opakovatelný a široce podporovaný.
Samotná závažnost však nestačí.
Kritická zranitelnost na izolovaném laboratorním hostiteli může být méně naléhavá než vysoká zranitelnost na poskytovateli identit dostupném z internetu. Střední zranitelnost ve veřejném API, které zpracovává záznamy zákazníků z EU, může znamenat vyšší regulatorní expozici než vysoká zranitelnost v neprodukčním analytickém systému. Zranitelnost uvedená ve zdrojích známého zneužívání vyžaduje jiné zacházení než zranitelnost, která je teoreticky závažná, ale není pozorována při aktivním zneužívání.
Podniková Politika řízení zranitelností a záplat Clarysec Politika řízení zranitelností a záplat tento posun výslovně stanoví. Ustanovení 4.5.2 uvádí:
“Mapujte zranitelnosti na kontext podnikových rizik s využitím CVSS, zneužitelnosti a metrik expozice.”
Tato věta tvoří hranici mezi základním záplatováním a řízením zranitelností podle rizika. Verze pro malé a střední podniky, Politika řízení zranitelností a záplat – SME Politika řízení zranitelností a záplat – SME, formuluje provozní spouštěč ještě jasněji. Ustanovení 6.5.1 uvádí:
“Systémy, které zpracovávají osobní údaje, poskytují vzdálený přístup nebo jsou externě dostupné, musí být prioritizovány pro skenování a aktualizace.”
Právě zde se mnoho programů rozpadá. Skenují vše, ale prioritizují tak, jako by všechna aktiva byla stejná. Dokumentují termíny nápravy, ale ne odůvodnění. Znají skóre CVSS, ale nevědí, zda aktivum podporuje regulovanou službu, kritickou závislost na dodavateli nebo prostředí pro zpracování osobních údajů.
Obhajitelný model pro rok 2026 kombinuje pět pohledů:
- Technickou závažnost, například CVSS 4.0.
- Pravděpodobnost zneužití, například EPSS nebo srovnatelné informace o pravděpodobnosti zneužití.
- Známé zneužívání, včetně KEV, informací souvisejících s EUVD a upozornění CERT a ENISA.
- Kritičnost aktiv a služeb.
- Regulatorní a datový dopad, včetně důkazů pro ISO 27001, NIS2, DORA a GDPR.
Výsledkem není dokonalá matematická pravda. Je to dokumentovaný, opakovatelný a vedením schválený proces rozhodování o rizicích.
Začněte u ISMS: prioritizace je rozhodnutí v oblasti správy a řízení
ISO/IEC 27001:2022 není jen certifikační norma. Při správném použití se stává páteří systému řízení pro prioritizaci zranitelností. Její kapitoly vyžadují, aby organizace porozuměla kontextu, zainteresovaným stranám, právním a smluvním požadavkům, rozsahu, vedení, rolím, posouzení rizik, ošetření rizik, dokumentovaným informacím a neustálému zlepšování.
To je důležité, protože prioritizace zranitelností je plná předpokladů. Co znamená „kritické“? Jaká úroveň rizika je nepřijatelná? Kdo může akceptovat zbytkové riziko? Kdy musí být informováno vedení? Jaké důkazy musí být uchovávány? Nejde o nastavení skeneru. Jde o rozhodnutí ISMS.
Zenith Blueprint se tomu věnuje ve fázi Řízení rizik, v kroku 10, Stanovení kritérií rizik a matice dopadů:
“Kritéria rizik jsou pravidla a referenční hodnoty, které vaše organizace používá k hodnocení významnosti jednotlivých rizik. Jejich stanovení předem zajišťuje, že všichni používají stejný jazyk rizik.”
Krok 10 také vede organizace k definování pravděpodobnosti a dopadu podle kritérií specifických pro podnikání, včetně regulatorního dopadu. Porušení zabezpečení osobních údajů může být automaticky hodnoceno jako závažné nebo kritické z důvodu povinností podle GDPR. Narušení ovlivňující základní nebo důležitou službu podle NIS2 může zvýšit provozní a právní dopad. Zranitelnost ovlivňující kritickou nebo důležitou funkci finančního subjektu může vyvolat obavy z hlediska odolnosti podle DORA.
Než začnete zranitelnosti řadit, definujte pravidla.
Clarysec obvykle pomáhá klientům zavést záznam o rozhodnutí ke zranitelnosti s těmito poli:
| Pole | Účel | Příklad důkazů |
|---|---|---|
| Závažnost podle CVSS 4.0 | Stanovit technický základ pro zneužitelnost a dopad | Výstup skeneru, záznam CVE, bezpečnostní oznámení dodavatele |
| Skóre EPSS | Doplnit signál pravděpodobnosti očekávaného zneužití | Záznam obohacení informacemi o hrozbách |
| Známé zneužívání | Identifikovat potvrzené nebo důvěryhodně hlášené zneužívání | Záznam v KEV, oznámení související s EUVD, upozornění CERT, upozornění ENISA |
| Expozice | Určit, zda je aktivum dosažitelné nebo přístupné | Evidence útočného povrchu, pravidlo firewallu, telemetrie EDR |
| Kritičnost aktiva | Propojit zjištění s významem pro podnikání | CMDB, katalog služeb, klasifikace aktiv |
| Dopad na data | Identifikovat osobní údaje, přihlašovací údaje, platební údaje nebo regulované záznamy | Evidence dat, DPIA, záznamy o činnostech zpracování |
| Kompenzační opatření | Snížit pravděpodobnost nebo dopad tam, kde jsou opatření účinná | Pravidlo WAF, izolace, EDR, MFA, virtuální záplatování |
| Rozhodnutí o ošetření | Zaznamenat záplatu, zmírnění, izolaci, monitorování, akceptaci nebo odklad | Záznam změny, akceptace rizika, plán ošetření rizik |
| Regulatorní mapování | Vysvětlit relevanci pro ISO 27001, NIS2, DORA, GDPR nebo smlouvy | Poznámky k SoA, Registr rizik, mapování opatření |
Tato tabulka není byrokracie. Je to rozdíl mezi „řekl to skener“ a „vedení učinilo dokumentované rozhodnutí o riziku podle schválených kritérií“.
Kritičnost aktiv je chybějící multiplikátor
Ani nejpřesnější data o zneužívání na světě nepomohou, pokud nevíte, k čemu aktivum slouží.
Clarysec často vidí organizace s vyspělými skenery a nevyspělou evidencí aktiv. Znají názvy hostitelů, IP adresy a CVE, ale ne vlastníky z pohledu podnikání, klasifikaci dat, závislosti služeb, dopad na zákazníky, vztah s dodavatelem, prioritu obnovy nebo regulatorní rozsah. To znemožňuje prioritizaci zranitelností podle rizika.
Politika správy aktiv – SME Politika správy aktiv – SME zachycuje základní požadavek v ustanovení 5.3:
“Aktiva musí být klasifikována podle jejich citlivosti nebo kritičnosti. Například:”
Tato klasifikace je motorem řízení zranitelností s ohledem na podnikání. Je dotčené aktivum součástí autentizace zákazníků? Podporuje zpracování plateb? Jde o záložní server? Je to brána API používaná externími partnery? Ukládá logy obsahující osobní údaje? Je hostováno poskytovatelem cloudových služeb nebo provozováno poskytovatelem ICT služeb třetí strany?
Zenith Controls s tím pracuje jako s kotvou napříč rámci souladu. U opatření ISO/IEC 27002:2022 5.9, Evidence informací a dalších souvisejících aktiv, mapuje evidenci aktiv na GDPR Article 30 a Article 32, NIS2 Article 21, DORA Articles 5, 9 a 18 a NIST CSF ID.AM. Zároveň propojuje evidenci aktiv s řízením konfigurací, monitorovacími činnostmi a klasifikací informací.
Praktické pravidlo Clarysec je jednoduché: žádnou zranitelnost nelze správně prioritizovat, dokud dotčené aktivum nemá vlastníka, kritičnost, klasifikaci dat a stav expozice.
Pokud tato pole chybí, zranitelnost může stále vyžadovat nápravu, ale mezera ve správě aktiv se stává samostatným rizikem.
Vytvořte vícefaktorový model prioritizace zranitelností
Praktický model priorit by neměl jednoduše sčítat nesouvisející čísla a tvářit se, že jde o vědu. CVSS 4.0 a EPSS měří různé věci. CVSS je rámec závažnosti. EPSS je signál pravděpodobnosti zneužití. KEV nebo informace související s EUVD ukazují na známou nebo nově vznikající relevanci zneužívání. Kritičnost aktiv a dopad na data určují důsledek pro podnikání.
Jednoduchý model Clarysec používá tyto faktory:
| Faktor | Doporučené hodnocení | Co zvyšuje prioritu |
|---|---|---|
| Závažnost podle CVSS 4.0 | 1 až 5 | Kritická nebo vysoká technická závažnost, vysoký dopad, nízká složitost útoku |
| Pravděpodobnost zneužití podle EPSS | 1 až 5 | Vysoká pravděpodobnost ve srovnání s organizační prahovou hodnotou |
| Známé zneužívání | 0 nebo 5 | Záznam v KEV, důvěryhodné zprávy o zneužívání, upozornění národního CERT nebo ENISA |
| Expozice | 1 až 5 | Dostupnost z internetu, cesta vzdáleného přístupu, přístupnost pro třetí stranu, slabá segmentace |
| Kritičnost aktiva | 1 až 5 | Podporuje kritickou službu, identitu, platby, produkci, bezpečnost nebo klíčové výnosy |
| Dopad na data a regulaci | 1 až 5 | Osobní údaje, zvláštní kategorie údajů, regulovaná finanční služba, funkce podle NIS2 nebo DORA |
| Snížení díky kompenzačním opatřením | 0 až minus 3 | Účinný WAF, izolace, hardening, detekce nebo dočasné zmírnění |
Příklad vzorce může být:
Prioritní skóre = hodnocení CVSS + hodnocení EPSS + známé zneužívání + expozice + kritičnost aktiva + dopad na data - snížení díky kompenzačním opatřením
Organizace poté definuje prahové hodnoty:
| Priorita | Rozsah skóre | Typické opatření |
|---|---|---|
| P1 nouzová | 24 nebo více | Okamžitě aplikovat záplatu nebo zmírnit dopad, informovat vedení, zahájit přezkum incidentu, pokud existuje podezření na zneužití |
| P2 urgentní | 18 až 23 | Provést nápravu ve zrychleném SLA, sledovat denně, vyžadovat viditelnost pro vlastníka rizika |
| P3 plánovaná | 12 až 17 | Provést nápravu v běžném cyklu záplatování, monitorovat změny hrozeb |
| P4 monitorovaná | Méně než 12 | Dočasně akceptovat, monitorovat informace o hrozbách a změny expozice aktiva |
To funguje pouze tehdy, pokud je model schválen a konzistentně uplatňován. Kapitoly ISO/IEC 27001:2022 6.1.1 až 6.1.3 vyžadují definované posouzení rizik bezpečnosti informací, ošetření rizik, výběr opatření, schválení zbytkového rizika a dokumentované informace.
Podniková Politika řízení rizik Clarysec Politika řízení rizik to posiluje v ustanovení 6.2.2:
“Analýza zohlední účinnost stávajících opatření, relevantní informace o hrozbách, kritičnost aktiv a závažnost zranitelnosti.”
Politika řízení rizik – SME Politika řízení rizik – SME poskytuje v ustanovení 5.1.2 jednoduché pravidlo pro důkazy:
“Každý záznam rizika musí obsahovat: popis, pravděpodobnost, dopad, skóre, vlastníka a plán ošetření rizik.”
Pro prioritizaci zranitelností to znamená, že každá významná odložená náprava má vytvořit záznam rizika nebo na něj odkazovat. Pokud je zranitelnost s vysokou závažností odložena, protože je aktivum izolované a existují kompenzační opatření, musí Registr rizik obsahovat vlastníka, odůvodnění, důkazy a datum přezkumu.
Informace o hrozbách: EPSS, KEV, EUVD, ENISA a upozornění CERT
Známé zneužívání mění vše.
Podniková Politika řízení zranitelností a záplat uvádí, že správa a řízení má zohlednit:
“Známé exploity (např. záznam CISA KEV)”
Politika pro malé a střední podniky rozšiřuje zdroje informací v ustanovení 6.2.1.3:
“Důvěryhodná bezpečnostní oznámení s informacemi o hrozbách (např. CISA, ENISA, upozornění národního CERT)”
Vyspělý program řízení zranitelností v roce 2026 má využívat více zdrojů: oznámení dodavatelů skenerů, bezpečnostní bulletiny dodavatelů, KEV, informace o zranitelnostech související s EUVD, upozornění národních CERT, oznámení ENISA, odvětvová ISAC, pravděpodobnost EPSS, signály EDR a telemetrii incidentů.
Tyto zdroje neznamenají totéž. Zdroje typu KEV ukazují známé zneužívání. EPSS odhaduje pravděpodobnost. Zdroje EUVD a ENISA podporují evropské povědomí o zranitelnostech a koordinaci. Oznámení dodavatelů objasňují dotčené verze, zmírňující opatření, podmínky zneužití a dostupnost záplat.
Zenith Controls popisuje opatření ISO/IEC 27002:2022 5.7, Informace o hrozbách, jako preventivní, detekční a nápravné opatření podporující důvěrnost, integritu a dostupnost. Přímo propojuje informace o hrozbách s opatřením 8.8, Řízení technických zranitelností:
“Informace o hrozbách často obsahují data o nově vznikajících zranitelnostech a exploitech v reálném prostředí, což umožňuje prioritizované záplatování a zmírňování zranitelností podle 8.8.”
Tento vztah je zásadní. Informace o hrozbách nejsou samostatným zájmem SOC. Jsou vstupem pro prioritizaci, rozhodnutí o nouzových změnách, oznámení dodavatelům, třídění incidentů a reporting vedení.
GDPR, NIS2 a DORA mění význam naléhavosti
Zranitelnost v systému zpracovávajícím osobní údaje není jen IT slabina. Může se stát selháním zabezpečení zpracování, pokud nejsou zavedena vhodná technická a organizační opatření.
GDPR Article 5 vyžaduje integritu, důvěrnost a odpovědnost. Article 32 vyžaduje vhodná bezpečnostní opatření s ohledem na riziko. Article 4 široce definuje osobní údaje a definuje porušení zabezpečení osobních údajů jako incident vedoucí k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění nebo přístupu k osobním údajům. Article 9 zvyšuje závažnost u zvláštních kategorií údajů, například biometrických nebo zdravotních údajů.
Podniková Politika ochrany dat a soukromí Clarysec Politika ochrany dat a soukromí uvádí v ustanovení 3.3:
“Zavést technická a organizační opatření (TOM), která chrání důvěrnost, integritu a dostupnost osobních údajů (PII) po celý jejich životní cyklus.”
Proto model prioritizace potřebuje faktor dopadu na data. Pokud zranitelnost ovlivňuje záznamy zákazníků, soubory pro ověřování identity, platební metadata, tickety podpory, HR data nebo telemetrii identifikující uživatele, hodnocení dopadu má vzrůst. Pokud by zneužití mohlo vést k neoprávněnému přístupu, změně nebo zpřístupnění, událost může vyžadovat také posouzení porušení zabezpečení a analýzu případné oznamovací povinnosti.
Zenith Controls mapuje opatření ISO/IEC 27002:2022 8.8 na GDPR Articles 32(1), 5(1)(f) a Recital 83 a popisuje, jak řízení technických zranitelností podporuje vhodná technická a organizační opatření a aktuální zmírňování rizik u systémů zpracovávajících osobní údaje.
NIS2 přidává další vrstvu. Article 21 vyžaduje, aby základní a důležité subjekty přijaly vhodná a přiměřená technická, provozní a organizační opatření k řízení kybernetických rizik a minimalizaci dopadu incidentů. Základní sada zahrnuje analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování a vývoj, zvládání a oznamování zranitelností, posuzování účinnosti, kybernetickou hygienu, školení, kryptografii, personální bezpečnost, řízení přístupu, správu aktiv a případně autentizaci. Article 20 ukládá povinnosti správy a řízení řídicím orgánům, včetně schvalování a dohledu nad opatřeními řízení kybernetických rizik.
DORA je obzvlášť důležitá pro finanční subjekty. Vytváří rámec digitální provozní odolnosti zahrnující řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s ICT, testování odolnosti, sdílení informací a řízení rizik třetích stran v oblasti ICT. Articles 5 a 6 vyžadují vnitřní správu a řízení, dokumentované řízení rizik v oblasti ICT, politiky, postupy, nástroje, přezkum, audit, nápravu a strategii digitální provozní odolnosti. Articles 9, 10 a 11 se věnují ochraně, prevenci, detekci, reakci a obnově. Articles 17 až 19 vyžadují detekci, klasifikaci, eskalaci, oznamování a reporting incidentů. Article 28 vyžaduje řízení rizik třetích stran v oblasti ICT, registry smluvních ujednání, předsmluvní posouzení, práva na audit a inspekci, práva na ukončení a strategie ukončení spolupráce.
U zranitelností to znamená, že finanční subjekty musí vědět, zda slabina ovlivňuje kritickou nebo důležitou funkci, ICT službu třetí strany, cloudovou pracovní zátěž, platební proces nebo cíl odolnosti.
Praktický příklad: od červeného dashboardu k obhajitelné nejvyšší prioritě
Představte si, že poskytovatel SaaS zjistí CVE-2026-XXXX ve webovém frameworku. Skener ji označí jako vysokou. EPSS je zvýšené. Objeví se v oznámení souvisejícím s ENISA a později ve zdroji známého zneužívání. Dotčená aplikace je dostupná z internetu, podporuje přihlášení zákazníků a zpracovává profilová data zákazníků z EU. Vývojový tým chce záplatu odložit na víkend kvůli riziku nedostupnosti.
Takto by Clarysec rozhodnutí dokumentoval.
Nejprve potvrďte kontext aktiva. Evidence ukazuje, že aplikace je produkční, externě dostupná, vlastněná týmem Platform, podporuje autentizaci, zpracovává osobní údaje a má vysoké hodnocení kritičnosti pro podnikání. To odpovídá ustanovení 5.3 Politiky správy aktiv – SME a mapování opatření 5.9 v Zenith Controls na evidenci aktiv, GDPR a důkazy DORA.
Za druhé ohodnoťte zranitelnost:
| Faktor | Hodnocení | Důkazy |
|---|---|---|
| Závažnost podle CVSS 4.0 | 4 | Skener a oznámení dodavatele ukazují vysokou závažnost |
| Pravděpodobnost zneužití podle EPSS | 4 | Obohacení o informace o hrozbách indikuje zvýšenou pravděpodobnost |
| Známé zneužívání | 5 | Byl zjištěn zdroj známého zneužívání nebo důvěryhodné oznámení |
| Expozice | 5 | Aplikace pro přihlášení zákazníků dostupná z internetu |
| Kritičnost aktiva | 5 | Produkční autentizační služba |
| Dopad na data a regulaci | 4 | Zpracovávají se profilová data zákazníků z EU |
| Snížení díky kompenzačním opatřením | -1 | Pravidlo WAF je dostupné, ale zůstává nejistota ohledně obejití |
| Celkem | 26 | Prahová hodnota P1 nouzová překročena |
Za třetí vyberte ošetření. Rozhodnutím je okamžité zmírnění plus zrychlené záplatování. Pravidlo WAF je nasazeno během hodin, monitorovací pravidla jsou doladěna a záplata je aplikována v režimu nouzové změny. Pokud je riziko nedostupnosti významné, vlastník služby a vlastník rizika nouzovou změnu schválí.
Za čtvrté zaznamenejte důkazy. Politika řízení zranitelností a záplat – SME vyžaduje, aby logy záplat obsahovaly:
“Logy musí obsahovat název zařízení, použitou aktualizaci, datum záplatování a důvod případného zpoždění.”
Podniková politika také vyžaduje:
“Důkazy o prioritizaci podle rizik”
Ticket má obsahovat skóre, zdroj informací o hrozbách, kritičnost aktiva, dopad na osobní údaje, rozhodnutí o ošetření, schválení změny, důkazy o testování, časové razítko nasazení, detekční dotazy a vyjádření ke zbytkovému riziku.
Nakonec aktualizujte Registr rizik a Prohlášení o použitelnosti. Zenith Blueprint, fáze Řízení rizik, krok 11, Vytvoření a dokumentace Registru rizik, vysvětluje:
“Registr rizik je živý dokument. V průběhu životního cyklu ISMS jej aktualizujte po rozhodnutích o ošetření rizik, kdykoli vzniknou nová rizika, když se objeví nové informace o hrozbách nebo když incident odhalí zranitelnost.”
Pokud tato zranitelnost vytváří nepřijatelné riziko, patří do Registru rizik až do provedení nápravy. V kroku 13, Plánování ošetření rizik a Prohlášení o použitelnosti, Zenith Blueprint doporučuje doplnit do plánu ošetření odkazy na opatření Annex A a uvést, kde opatření podporují soulad s GDPR, NIS2 nebo DORA. Krok 19 poté propojuje tento model správy a řízení s prováděním technického řízení zranitelností.
Mapování napříč rámci souladu: jedno rozhodnutí, mnoho povinností
Síla řízení zranitelností podle rizika spočívá v tom, že stejné důkazy mohou sloužit více rámcům. Zenith Controls funguje jako kompas napříč rámci souladu a ukazuje, jak opatření ISO/IEC 27002:2022 souvisejí s právními předpisy, frameworky a očekáváními auditorů.
| Položka důkazů | Vazba na ISO 27001 a ISO 27002 | Vazba na NIS2 | Vazba na DORA | Vazba na GDPR | Vazba na NIST a COBIT |
|---|---|---|---|---|---|
| Kritéria rizik a matice dopadů | Podporuje kapitoly ISO/IEC 27001:2022 6.1.1 až 6.1.3 | Podporuje přiměřená opatření řízení kybernetických rizik | Podporuje rámec řízení rizik v oblasti ICT a proporcionalitu | Podporuje TOM založená na rizicích | Je v souladu s NIST CSF GOVERN a správou rizik COBIT |
| Evidence aktiv s kritičností | Podporuje opatření ISO/IEC 27002:2022 5.9 | Podporuje správu aktiv a povědomí o kritických systémech | Podporuje znalost ICT aktiv a závislostí | Podporuje záznamy, systémy a zabezpečení zpracování | Mapuje se na NIST CSF ID.AM a správu aktiv COBIT |
| Obohacení informacemi o hrozbách | Podporuje opatření ISO/IEC 27002:2022 5.7 | Podporuje kybernetickou hygienu, sdílení informací a zvládání zranitelností | Podporuje monitorování vyvíjejících se hrozeb a testování odolnosti | Podporuje vhodná bezpečnostní opatření | Mapuje se na výsledky detekce, reakce a řízení zranitelností |
| Skóre zranitelnosti a ošetření | Podporuje opatření ISO/IEC 27002:2022 8.8 | Podporuje bezpečnou údržbu a zvládání zranitelností | Podporuje identifikaci, zmírňování a nápravu zranitelností | Podporuje důvěrnost, integritu a dostupnost osobních údajů | Mapuje se na NIST SP 800-53 RA-5, SI-2, CA-7 a COBIT APO12.06, DSS05.03, BAI09.02 |
| Důkazy o záplatě nebo zmírnění | Podporuje dokumentované informace a účinnost opatření | Podporuje prevenci a minimalizaci dopadu | Podporuje nápravu a provozní odolnost | Podporuje odpovědnost podle Article 5 a Article 32 | Podporuje auditní stopy a průběžné monitorování |
| Důkazy o zranitelnostech dodavatele | Podporuje dodavatelská opatření a opatření dodavatelského řetězce ICT | Podporuje zabezpečení dodavatelského řetězce | Podporuje řízení rizik třetích stran v oblasti ICT | Podporuje náležitou péči u zabezpečení zpracovatele | Mapuje se na NIST CSF GV.SC |
ISO/IEC 27005:2024 tento přístup podporuje tím, že uznává nezáplatované zranitelnosti jako faktory přispívající k riziku bezpečnosti informací a podporuje nápravu založenou na rizicích. ISO/IEC TS 27008:2019 doplňuje pohled auditora, kdy auditoři posuzují, zda existují skenovací nástroje, zda se výsledky skenů přezkoumávají, zda jsou lhůty záplatování přiměřené a zda auditní stopy ukazují detekci, hodnocení rizika a nápravu.
Na co se budou auditoři ptát
Auditor ISO/IEC 27001:2022 začne u ISMS. Bude se ptát, zda je řízení zranitelností v rozsahu, zda jsou definována kritéria rizik, zda posouzení rizik zohledňuje důvěrnost, integritu a dostupnost, zda je opatření 8.8 zahrnuto v Prohlášení o použitelnosti, zda vlastníci rizik schvalují ošetření a zda je zbytkové riziko řádně akceptováno.
Auditor NIS2 se bude ptát, zda proces podporuje opatření podle Article 21, zda je zvládání zranitelností přiměřené, zda jsou chráněny základní nebo důležité služby, zda se zohledňuje expozice dodavatelského řetězce a zda řídicí orgány dohlížejí na kybernetická rizika.
Orgán dohledu podle DORA nebo tým interního auditu se bude ptát, zda je prioritizace zranitelností součástí rámce řízení rizik v oblasti ICT, zda podporuje digitální provozní odolnost, zda pokrývá ICT služby třetích stran, zda vstupuje do klasifikace incidentů a zda jsou zranitelnosti ovlivňující kritické nebo důležité funkce sledovány prostřednictvím správy a řízení.
Přezkoumávající osoba v kontextu GDPR se bude ptát, zda byly identifikovány systémy zpracovávající osobní údaje, zda byly zranitelnosti, které je ovlivňují, řešeny podle rizika, zda byla technická a organizační opatření vhodná, zda podezření na zneužití spustilo posouzení porušení zabezpečení a zda existují důkazy o odpovědnosti.
Hodnotitel orientovaný na NIST nebo COBIT se zaměří na výsledky, správu a řízení, vlastnictví procesů, reakci na rizika, průběžné monitorování, ošetření výjimek a měřitelné zlepšování.
Nejlepší odpovědí pro všechny je jedna ucelená důkazní stopa: kontext aktiva, informace o hrozbách, prioritní skóre, rozhodnutí o ošetření, schválení vlastníkem rizika, důkaz o nápravě a mapování opatření.
Běžné vzorce selhání
Prvním selháním je zacházet s CVSS jako s jedinou proměnnou prioritizace. To vytváří falešnou naléhavost u izolovaných systémů a falešný pocit bezpečí u exponovaných systémů kritických pro podnikání.
Druhým selháním je chybějící kritičnost aktiv. Bez vlastnictví a klasifikace dat nemůže tým řízení zranitelností přijímat regulatorní ani provozní rozhodnutí.
Třetím selháním je slabé ošetření výjimek. Odložená záplata bez dokumentovaného důvodu, kompenzačního opatření a schválení vlastníkem rizika není řízení podle rizika. Je to neřízený backlog.
Čtvrtým selháním je oddělení řízení zranitelností od reakce na incidenty. Pokud je zranitelnost známě zneužívána a dotčené aktivum vykazuje podezřelou aktivitu, problém už nemusí být pouze otázkou záplatování. Může jít o otázku klasifikace incidentu a reportingu podle NIS2, DORA nebo GDPR.
Pátým selháním je slepota vůči dodavatelům. DORA Article 28 a očekávání NIS2 v oblasti dodavatelského řetězce činí důkazy o zranitelnostech třetích stran nezbytnými. Pokud poskytovatel cloudových služeb, dodavatel SaaS nebo poskytovatel řízených služeb hostuje zranitelnou komponentu ovlivňující vaši službu, stále potřebujete evidenci, smluvní práva, komunikaci, posouzení rizik a důkazy.
Kontrolní seznam auditovatelné prioritizace zranitelností
Použijte tento kontrolní seznam k ověření, zda je váš proces prioritizace zranitelností obhajitelný:
- Mějte vedením schválená kritéria rizik pro pravděpodobnost, dopad, regulatorní dopad a ochotu podstupovat riziko.
- Obohacujte zranitelnosti o CVSS 4.0, EPSS, známé zneužívání, expozici, kritičnost aktiv a dopad na data.
- Udržujte evidenci aktiv s vlastníkem, podnikovou službou, kritičností, klasifikací dat a závislostí na dodavateli.
- Definujte prahové hodnoty ošetření pro nouzové, urgentní, plánované a monitorované případy.
- Vyžadujte schválení vlastníkem rizika u porušení SLA, odkladů a akceptace rizika.
- Propojujte významné zranitelnosti s Registrem rizik a plánem ošetření rizik.
- Mapujte opatření v Prohlášení o použitelnosti, zejména opatření ISO/IEC 27002:2022 5.7, 5.9 a 8.8.
- Uchovávejte logy záplat, záznamy změn, důkazy o testování, důkazy o zmírnění a důvody zpoždění.
- Eskalujte podezření na zneužití do reakce na incidenty a posouzení porušení zabezpečení.
- Sledujte zranitelnosti dodavatelů a smluvní povinnosti nápravy.
- Přezkoumávejte metriky při přezkoumání vedením, včetně zpožděných položek P1 a P2, trendů výjimek a opakovaných kořenových příčin.
- Aktualizujte pravidla prioritizace, když se změní informace o hrozbách, podnikové služby nebo regulatorní rozsah.
Tento kontrolní seznam odráží logiku Zenith Blueprint: definovat kritéria, vytvořit registr, ošetřit rizika, mapovat opatření, uchovávat důkazy a neustále se zlepšovat.
Přístup Clarysec: zajistěte vysvětlitelnost prioritizace ještě před auditem
Prioritizace zranitelností podle rizika v roce 2026 není o vytvoření dokonalého skóre. Jde o vytvoření rozhodovacího modelu, který může ředitel informační bezpečnosti (CISO) obhájit, technický tým provozovat, vlastník rizika schválit a auditor otestovat.
Clarysec pomáhá organizacím tento model zavést prostřednictvím:
- Zenith Blueprint Zenith Blueprint, zejména kroku 10 fáze Řízení rizik pro kritéria rizik, kroku 11 pro živý Registr rizik, kroku 13 pro ošetření rizik a dohledatelnost SoA a kroku 19 pro technické řízení zranitelností.
- Podnikových politik Clarysec a politik pro malé a střední podniky, včetně Politiky řízení zranitelností a záplat Politika řízení zranitelností a záplat, Politiky řízení zranitelností a záplat – SME, Politiky řízení rizik Politika řízení rizik, Politiky řízení rizik – SME Politika řízení rizik – SME, Politiky správy aktiv – SME Politika správy aktiv – SME a Politiky ochrany dat a soukromí Politika ochrany dat a soukromí.
- Zenith Controls Zenith Controls, které mapují informace o hrozbách, evidenci aktiv a technické řízení zranitelností napříč ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST SP 800-53, NIST CSF a COBIT 2019.
Pokud váš současný proces stále říká „nejdříve záplatovat kritické CVSS“, rok 2026 je čas na posun. Vybudujte důkazní model nyní: závažnost, pravděpodobnost zneužití, známé zneužívání, expozice, kritičnost aktiv, dopad na data, kompenzační opatření, rozhodnutí vlastníka rizika a regulatorní mapování.
Váš příští audit, dotaz regulačního orgánu, bezpečnostní přezkum zákazníka nebo jednání správní rady se nebude ptát, zda váš skener našel zranitelnosti. Bude se ptát, zda vaše organizace učinila správná rozhodnutí, dostatečně rychle a s důkazy.
Stáhněte si šablony Clarysec, namapujte svůj současný proces řízení zranitelností podle Zenith Controls nebo si objednejte posouzení Clarysec a převeďte prioritizaci zranitelností na důkazy připravené pro audit.
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


