Řízení zranitelností z CISA KEV pro ISO 27001, NIS2 a DORA

Páteční zranitelnost, která se stala otázkou pro řídicí orgán

Je pátek 16:40. Vedoucí SOC přepošle upozornění CISA KEV, skener zranitelností potvrdí expozici na bráně dostupné z internetu a ENISA EUVD obsahuje odpovídající záznam o zneužívané zranitelnosti. Dodavatel vydal záplatu, ale vlastník produkčního prostředí varuje, že její okamžitá aplikace může narušit zákaznicky orientovanou službu. Právní oddělení se ptá, zda mohou být dotčeny osobní údaje. Odpovědná osoba pro DORA se ptá, zda platforma podporuje kritickou nebo důležitou funkci. Koordinátor NIS2 se ptá, zda se z toho může stát významný incident.

CISO položí jedinou otázku, na které záleží:

“Dokážeme doložit, že jsme přijali správné rozhodnutí, dostatečně rychle a se správnými schváleními?”

To je skutečný problém řízení známých zneužívaných zranitelností v roce 2026. Nejde pouze o identifikaci CVE nebo rychlejší aplikaci záplat. Jde o převod informací o exploitech do obhajitelného provozního modelu: příjem, třídění, prioritizace, nouzová změna, kompenzační opatření, eskalace na dodavatele, schválení výjimky, uchovávání důkazů, reporting vedení a rozhodnutí o nápravě připravená pro regulační orgán.

Mnoho organizací již má SLA pro zranitelnosti. Některé využívají zdroje informací o hrozbách. Několik z nich provozuje průběžné řízení expozice. Jakmile je však zranitelnost již aktivně zneužívána, kontext rizika se mění. Známá zneužívaná zranitelnost uvedená v CISA KEV nebo ENISA EUVD nemá zůstat ve stejné frontě jako běžné nevyřízené záplaty. Má spustit odlišnou cestu správy a řízení, protože riziko již není teoretické.

Postoj Clarysec je jednoduchý: náprava řízená informacemi o exploitech musí být řízena jako obchodní proces vytvářející důkazy, nikoli jako neformální technický chaos. Tento proces lze postavit na ISO/IEC 27001:2022 ISO/IEC 27001:2022, posílit prostřednictvím ISO/IEC 27002:2022 ISO/IEC 27002:2022 a namapovat na očekávání v oblasti správy a řízení podle NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 19.

Od záplatování k prokazatelné správě a řízení

Tradiční řízení zranitelností často začíná závažností: skóre CVSS, kritičnost aktiva, expozice a dostupnost záplaty. Řízení založené na informacích o exploitech přidává přesnější otázku: je tato zranitelnost již používána útočníky a máme dotčená aktiva, dodavatele, cloudové služby nebo datové toky?

Tento posun mění pracovní postup. Známá zneužívaná zranitelnost musí spustit:

1. Ověření informací o hrozbách z důvěryhodných zdrojů, jako jsou CISA, ENISA, národní CERT, dodavatelé, ISAC a MSSP.
2. Korelaci aktiv včetně internetové expozice, podnikové funkce, klasifikace dat a závislosti na dodavateli.
3. Nouzové rozhodnutí o riziku, včetně možnosti okamžitě záplatovat, izolovat, vypnout funkci, použít workaround, monitorovat nebo dočasně přijmout zbytkové riziko.
4. Schválení změny s dohledatelností, i když je změna provedena ve zrychleném režimu.
5. Zachycení důkazů, včetně časových razítek, schválení, logů, snímků obrazovky, výsledků skenů, vyjádření dodavatelů a záznamů o kompenzačních opatřeních.
6. Reporting vedení, zejména pokud zranitelnost ovlivňuje kritické služby, osobní údaje, regulované finanční služby nebo základní či důležité služby podle NIS2.
7. Ověření po nápravě a zachycení získaných poznatků.

ISO 27001:2022 poskytuje tomuto pracovnímu postupu kostru správy a řízení. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím otázkám, zainteresovaným stranám, právním a regulačním požadavkům, rozhraním a závislostem a následně definovala a udržovala rozsah ISMS. V řízení zranitelností to znamená, že rozsah musí zahrnovat skutečné systémy, cloudové služby, třetí strany a regulované služby, u nichž může expozice zneužívané zranitelnosti způsobit dopad na podnikání.

Kapitoly 5.1 až 5.3 posouvají problém za hranice provozu IT. Vrcholové vedení musí sladit ISMS se strategickým směřováním, přiřadit odpovědnosti, přidělit zdroje, komunikovat význam souladu a přijímat reporty o výkonnosti. V praxi není shoda CISA KEV u kritické služby pouze požadavkem na záplatu. Je to událost odpovědnosti vedení.

Kapitoly 6.1.1 až 6.1.3 poskytují rizikovou páteř: kritéria rizik, vlastníky rizik, posouzení pravděpodobnosti a dopadů, možnosti ošetření, Prohlášení o použitelnosti, plán ošetření rizik a přijetí zbytkového rizika. To je mechanismus, který převádí tvrzení “zatím jsme nemohli záplatovat” na zdokumentovanou, schválenou a časově omezenou výjimku s kompenzačními opatřeními.

Kapitola 8.1 je následně důležitá ve chvíli, kdy tým přechází od rozhodnutí k provedení. Vyžaduje provozní plánování a řízení, včetně řízení plánovaných změn a přezkumu nezamýšlených změn. Při události KEV musí být organizace rychlá, aniž by ztratila kontrolu.

Kontrolní trojúhelník Clarysec pro zneužívané zranitelnosti

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls chápe řízení známých zneužívaných zranitelností jako kombinaci tří ústředních témat opatření ISO/IEC 27002:2022. Uvádí tematicky související opatření jako “informace o hrozbách (5.7)”, “řízení technických zranitelností (8.8)” a “řízení změn (8.32)”.

Společně tato opatření tvoří praktický trojúhelník:

Tento trojúhelník brání častému selhání při auditu: zacházení s řízením zranitelností jako s výstupem skeneru, nikoli jako s řízeným řetězcem rozhodnutí. Auditor, regulační orgán nebo tým zákaznického ujištění se nebude ptát jen na to, zda byla záplata aplikována. Bude se ptát, jak organizace zranitelnost zjistila, prioritizovala, schválila, implementovala a ověřila.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to konkretizuje ve fázi Controls in Action, kroku 22, kde týmům ukládá vytvořit registr informací o hrozbách:

Vytvořte zdokumentovaný seznam zdrojů informací o hrozbách (5.7) od dodavatelů, ISAC nebo otevřených zdrojů a určete, jak se tyto informace ověřují a začleňují do rozhodování. Definujte, kdo dostává aktualizace o hrozbách a jak se používají (např. prioritizace záplat, školení bezpečnostního povědomí).

V kroku 19 Zenith Blueprint rámuje řízení zranitelností jako moderní kybernetickou hygienu a zdůrazňuje zrychlenou nápravu kritických zranitelností:

Řízení zranitelností je jednou z nejkritičtějších oblastí moderní kybernetické hygieny. Firewally a antivirové nástroje poskytují ochranu, ale mohou být oslabeny, pokud zůstanou vystavené nezáplatované systémy nebo nesprávně nakonfigurované služby.

Zároveň varuje, že zjištění ze skenů nesmí být pasivně archivována. Musí být vytříděna, přiřazena a sledována až do uzavření. Přesně tuto disciplínu řízení CISA KEV a ENISA EUVD vyžaduje.

Politika převádí naléhavost na pravidla

Model správy a řízení funguje pouze tehdy, když je promítnut do politiky. Podniková Politika řízení zranitelností a záplat Clarysec Politika řízení zranitelností a záplat, v kontextu toolkitů označovaná také jako P19 Politika řízení zranitelností a záplat, jasně přiřazuje požadavek na monitorování a eskalaci:

Monitorujte upozornění na hrozby (např. CVE, CISA KEV, bulletiny dodavatelů) a eskalujte kritické zranitelnosti.

Ze sekce “Role a odpovědnosti”, ustanovení politiky 4.5.1.

Stejná podniková politika definuje přísné očekávání nápravy kritických zranitelností:

Kritické (CVSS 9.0-10.0): okamžitý přezkum; lhůta pro aplikaci záplaty maximálně 72 hodin.

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

Pro malé a střední podniky převádí Vulnerability and Patch Management Policy-sme Clarysec Vulnerability and Patch Management Policy-sme - SME, označovaná také jako P19S Vulnerability and Patch Management Policy-sme, stejný koncept do provozní a přímé podoby:

Důvěryhodná bezpečnostní oznámení vycházející z informací o hrozbách (např. CISA, ENISA, upozornění národních CERT)

Ze sekce “Požadavky na implementaci politiky”, ustanovení politiky 6.2.1.3.

Stanovuje také praktický standard záplatování:

Kritické záplaty musí být aplikovány do 3 dnů od vydání, zejména u systémů dostupných z internetu

Ze sekce “Požadavky na implementaci politiky”, ustanovení politiky 6.1.1.

Formulace “zejména u systémů dostupných z internetu” je zásadní. Řízení známých zneužívaných zranitelností musí prioritizovat exponované systémy, služby vzdáleného přístupu, infrastrukturu identit, perimetrová zařízení, administrátorské panely SaaS a systémy zpracovávající citlivá nebo regulovaná data.

Co se ale stane, když podnik nedokáže záplatovat v rámci SLA? Podniková politika uzavírá smyčku:

Pokud zranitelnost nelze napravit v rámci definovaných SLA z provozních, technických nebo dodavatelských důvodů, musí být podána formální žádost o výjimku.

Ze sekce “Ošetření rizik a výjimky”, ustanovení politiky 7.1.

Verze pro malé a střední podniky vyžaduje logy záplatování podporující auditovatelnost:

Logy musí obsahovat název zařízení, aplikovanou aktualizaci, datum záplatování a důvod jakéhokoli zpoždění

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

Tato ustanovení politik tvoří důkazní páteř. Umožňují CISO říci: máme pravidla pro příjem informací, prioritizaci, lhůty pro záplaty, výjimky a důvody zpoždění. To je rozdíl mezi reaktivním záplatováním a řízenou nápravou.

Nouzová změna bez ztráty kontroly

Známé zneužívané zranitelnosti často vynucují nouzové změny. Čekat na další jednání poradního orgánu pro změny může být nedbalé. Obejít řízení změn úplně může být nezodpovědné. Řešením je zrychlené a dohledatelné řízení změn.

Podniková Politika řízení změn Clarysec Politika řízení změn, označovaná také jako P05 Politika řízení změn, uvádí:

Nouzové změny mohou pokračovat na základě zrychleného ústního nebo delegovaného schválení oprávněnými rolemi.

Ze sekce “Požadavky na implementaci politiky”, ustanovení politiky 6.5.1.

Pro malé a střední podniky uznává Politika řízení změn Clarysec Politika řízení změn - SME stejnou provozní realitu:

Nouzové nebo neplánované změny mohou být implementovány okamžitě v reakci na kritické výpadky nebo hrozby. Nicméně:

Ze sekce “Ošetření rizik a výjimky”, ustanovení politiky 7.4.1.

Slovo “nicméně” je místem, kde se projevuje správa a řízení. Nouzová změna musí i nadále dokumentovat spouštěč, dotčené systémy, rozhodnutí o riziku, schvalovatele, čas implementace, výsledek ověření a retrospektivní přezkum. Zenith Blueprint, fáze Controls in Action, krok 21, popisuje řízení změn jako opakovatelný pracovní postup, v němž jsou změny hodnoceny, autorizovány, implementovány a přezkoumávány. Varuje, že mnoho incidentů není způsobeno útočníky, ale špatně řízenou změnou: pravidlem firewallu otevřeným příliš široce, ponechaným zapnutým ladicím nastavením nebo zapomenutou závislostí po migraci.

U nápravy známé zneužívané zranitelnosti musí minimální důkazy pro nouzovou změnu zahrnovat:

To není byrokracie. Je to minimální životaschopná auditní stopa pro rozhodnutí učiněné pod tlakem protivníka.

Mapování CISA KEV a ENISA EUVD na důkazy ISO 27001

ISO 27001:2022 nevyžaduje konkrétní zdroj informací o hrozbách. Vyžaduje, aby organizace identifikovala požadavky, řídila rizika, implementovala opatření, uchovávala dokumentované informace a zlepšovala se. CISA KEV a ENISA EUVD se mohou stát autoritativními vstupy do tohoto systému řízení.

Zenith Blueprint, fáze Risk Management, krok 13, doporučuje dohledatelnost mezi riziky, opatřeními a kapitolami:

Proveďte křížové odkazy 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.

U známé zneužívané zranitelnosti nemá záznam v registru rizik říkat jen “záplatovat CVE”. Musí identifikovat zdroj hrozby, dotčenou službu, regulační relevanci, vlastníka rizika, ošetření, odkazy na opatření a umístění důkazů.

Mapování napříč požadavky NIS2, DORA, GDPR a reportingem správy a řízení

Hodnota řízení založeného na informacích o exploitech spočívá v tom, že jeden kontrolovaný pracovní postup dokáže odpovědět na více regulačních otázek. Stejný záznam, záznam o změně, formulář výjimky, e-mail dodavatele a validační sken mohou podporovat různé důkazní příběhy, pokud jsou záměrně namapovány.

NIS2 mění debatu pro základní a důležité subjekty, protože Article 20 činí z kybernetické bezpečnosti otázku odpovědnosti řídicího orgánu. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, zvládání a oznamování zranitelností, kybernetické hygieny, řízení přístupu, správy aktiv a autentizace.

Article 23 přidává postupné hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy do jednoho měsíce po oznámení incidentu. Shoda CISA KEV nebo ENISA EUVD není automaticky incidentem podléhajícím hlášení. Musí však spustit zdokumentované posouzení incidentu, pokud je pravděpodobné zneužití, narušení služby, újma zákazníkům nebo dopad na data.

DORA přidává sektorovou optiku pro finanční subjekty. Použije se od 17. ledna 2025 a vyžaduje správu, zdokumentované řízení rizik v oblasti ICT, testování, odolnost, řízení incidentů a řízení rizik ICT třetích stran. Article 13 je zvlášť relevantní, protože vyžaduje schopnosti týkající se zranitelností a informací o kybernetických hrozbách, získaných poznatků a monitorování technologického vývoje. Article 17 vyžaduje proces řízení incidentů souvisejících s ICT, který zaznamenává incidenty a významné kybernetické hrozby, klasifikuje je podle priority a závažnosti, eskaluje, identifikuje kořenové příčiny a obnovuje bezpečný provoz.

DORA Articles 28 a 30 také vynucují disciplínu u dodavatelů. Pokud platební platforma závisí na cloudovém WAF, spravované databázi, poskytovateli identit nebo nástroji SaaS pro pracovní postupy dotčeném známou zneužívanou zranitelností, důkazy nemohou skončit u výroku “dodavatel říká, že je opraveno”. Musí zahrnovat oznámení dodavatele, posouzení kritičnosti, použitá smluvní práva, kompenzační opatření, posouzení dopadu na zákazníky a ověření po nápravě.

GDPR přidává otázku zaměřenou na data. Article 32 vyžaduje zabezpečení zpracování, zatímco Article 5(2) vytváří odpovědnost. Přezkum ochrany soukromí musí začít před potvrzeným porušením, nikoli až poté, co je prokázána exfiltrace.

Praktický záznam nápravy KEV a EUVD

Zvažte realistický scénář. ENISA EUVD a CISA KEV indikují aktivní zneužívání zranitelnosti ovlivňující službu pro přenos souborů dostupnou z internetu. Služba podporuje onboarding zákazníků a ukládá omezené osobní údaje. Záplata dodavatele existuje, ale vlastník aplikace žádá o okno údržby a jedna související komponenta SaaS závisí na nápravě ze strany dodavatele.

Vytvořte jeden záznam v registru řízení zranitelností s těmito poli:

Poté použijte pravidla politik Clarysec:

• Použijte podnikovou Politiku řízení zranitelností a záplat, pokud provozujete větší organizaci s formálními rolemi, SLA a eskalací.
• Použijte Vulnerability and Patch Management Policy-sme pro malé a střední podniky, pokud potřebujete odlehčený, ale auditovatelný model.
• Použijte podnikovou Politiku řízení změn nebo Politiku řízení změn pro malé a střední podniky k dokumentaci nouzového schválení, testování, nasazení a retrospektivního přezkumu.
• Propojte záznam s Registrem rizik a Prohlášením o použitelnosti podle doporučení v Zenith Blueprint, kroku 13.
• Označte opatření v Zenith Controls jako 5.7, 8.8 a 8.32 a následně doplňte podpůrné důkazy pro řízení dodavatelů, správu cloudu, protokolování, řízení incidentů a kontinuitu činností, pokud jsou relevantní.

Nakonec uchovejte auditní důkazy. Podniková Politika monitorování auditu a souladu Clarysec Politika monitorování auditu a souladu, označovaná také jako P33 Politika monitorování auditu a souladu, definuje výslovný cíl:

Vytvářet obhajitelné důkazy a auditní stopu na podporu regulačních šetření, soudních řízení nebo požadavků zákazníků na doložení zajištění.

Ze sekce “Cíle”, ustanovení politiky 3.4.

To je smysl celého pracovního postupu. Neopravujete pouze zranitelnost. Vytváříte obhajitelné důkazy, že organizace jednala přiměřeně, včas a pod kontrolou.

Jak auditoři otestují stejné rozhodnutí KEV

Vyspělý proces pro známé zneužívané zranitelnosti musí obstát z různých auditorských pohledů.

Auditor ISO 27001:2022 začne rozsahem ISMS, zainteresovanými stranami, regulačními povinnostmi, metodou posouzení rizik, Prohlášením o použitelnosti a dokumentovanými informacemi. Zeptá se, zda jsou informace o hrozbách začleněny do posouzení rizik, zda je řízení zranitelností opakovatelné, zda jsou nouzové změny řízené, zda zbytkové riziko přijal správný vlastník rizika a zda jsou důkazy uchovávány.

Hodnotitel zaměřený na NIS2 se soustředí na odpovědnost vedení, opatření řízení rizik podle Article 21, zranitelnosti dodavatelů, zvládání incidentů, kontinuitu činností a posouzení významného incidentu podle Article 23. Budou ho zajímat časová razítka, eskalace, záznamy o rozhodnutí a to, zda byly příslušné řídicí orgány informovány.

Auditor DORA nebo příslušný orgán se zeptá, zda rámec řízení rizik v oblasti ICT zachytil dotčené aktivum, obchodní funkci, závislost a službu třetí strany. Bude očekávat klasifikaci incidentu, záznamy o významných kybernetických hrozbách, eskalaci na vedení, následné kroky k analýze kořenové příčiny, důkazy od dodavatelů, testování a sledování nápravy.

Přezkoumávající osoba pro GDPR se zeptá, zda šlo o osobní údaje, zda mohla být ovlivněna důvěrnost, integrita nebo dostupnost, jaká technická a organizační opatření byla zavedena, zda bylo posouzeno oznamování porušení zabezpečení a zda existují důkazy odpovědnosti.

Hodnotitel NIST CSF 2.0 může použít CSF Core a profily k ověření, zda jsou definovány a měřeny výsledky správy, identifikace, ochrany, detekce, reakce a obnovy. Praktický cílový profil může znít: “Všechny známé zneužívané zranitelnosti ovlivňující kritická aktiva dostupná z internetu jsou vytříděny do 24 hodin, ošetřeny do 72 hodin nebo formálně vyňaty s kompenzačními opatřeními a schválením vlastníka rizika.”

Auditor COBIT 19 se zeptá, kdo je odpovědný, zda jsou definovány cíle správy a řízení, zda ochota podstupovat riziko určuje naléhavost, zda jsou přezkoumávány ukazatele výkonnosti, zda jsou monitorovány výjimky a zda funkce zajištění proces nezávisle testují.

Stejný důkazní záznam musí odpovědět všem. To je hodnota inženýringu napříč požadavky na soulad.

Metriky, které má vidět řídicí orgán

Řídicí orgány nepotřebují seznam každého CVE. Potřebují metriky kvality rozhodování, které ukazují expozici, rychlost reakce a zbytkové riziko. Pro řízení známých zneužívaných zranitelností Clarysec doporučuje stručný manažerský report obsahující:

Tyto metriky podporují přezkoumání ISMS vedením podle ISO 27001, odpovědnost vedení podle NIS2, reporting rizik ICT podle DORA a komunikaci o správě podle NIST CSF. Pomáhají také vlastníkům byznysu pochopit, proč kapacita záplatování, kvalita evidence aktiv, dodavatelské smlouvy a okna údržby nejsou “detaily IT”. Jsou to rozhodnutí o odolnosti.

Časté vzorce selhání, které je třeba odstranit

V hodnoceních Clarysec řízení známých zneužívaných zranitelností obvykle selhává předvídatelnými způsoby.

Za prvé, zdroje informací jsou neformální. Jeden bezpečnostní inženýr sleduje CISA KEV, druhý bulletiny dodavatelů a třetí spoléhá na výstup skeneru. Neexistuje zdokumentovaný registr informací o hrozbách, pravidlo ověření ani vlastnictví.

Za druhé, korelace aktiv je slabá. Organizace ví, že CVE existuje, ale nedokáže rychle určit, kde produkt běží, zda je dostupný z internetu, kdo ho vlastní, jaká data zpracovává nebo který dodavatel ho spravuje.

Za třetí, nouzová změna je buď příliš pomalá, nebo příliš nekontrolovaná. Týmy čekají dny na schválení, nebo záplatují produkční prostředí bez poznámek k návratu zpět, ověření nebo retrospektivního přezkumu.

Za čtvrté, výjimky jsou vágní. “Nelze záplatovat kvůli dopadu na podnikání” není přijetí rizika. Správná výjimka musí definovat omezení, dotčená aktiva, kompenzační opatření, zbytkové riziko, schvalovatele, datum expirace a kadenci přezkumu.

Za páté, důkazy jsou roztříštěné. Snímky obrazovky ze skeneru, schválení v chatu, e-maily dodavatelů, dotazy SIEM a záznamy o změnách žijí na různých místech. Při auditu nebo šetření regulačního orgánu organizace nedokáže rekonstruovat časovou osu rozhodnutí.

Nápravou není další šum. Je jí jednotný pracovní postup správy řízený informacemi o exploitech, který integruje procesy informací o hrozbách, rizik, změn, incidentů, dodavatelů a důkazů.

Vybudujte svůj důkazní engine řízený informacemi o exploitech

Známé zneužívané zranitelnosti zůstanou v roce 2026 vysoce objemovým provozním tématem. CISA KEV a ENISA EUVD zviditelňují informace o zneužívání, ale samotná viditelnost nesplňuje očekávání ISO 27001:2022, NIS2, DORA ani GDPR v oblasti důkazů. Potřebujete řízený proces, který převádí informace do opatření a opatření do důkazů.

Začněte čtyřmi kroky:

1. Vytvořte registr informací o hrozbách pomocí Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, fáze Controls in Action, krok 22.
2. Slaďte pravidla politik s Politikou řízení zranitelností a záplat Clarysec Politika řízení zranitelností a záplat nebo Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME.
3. Použijte Zenith Controls: The Cross-Compliance Guide Zenith Controls k mapování 5.7 informace o hrozbách, 8.8 řízení technických zranitelností a 8.32 řízení změn na potřeby důkazů pro ISO, NIS2, DORA, GDPR, NIST a COBIT.
4. Otestujte jeden skutečný případ KEV nebo EUVD end-to-end, od příjmu přes nápravu, ošetření výjimky, nouzovou změnu, ověření až po reporting vedení.

Clarysec vám může pomoci převést tento přístup do funkčního provozního modelu připraveného na audit: politiky, registry, šablony důkazů, mapování napříč požadavky na soulad a reporting pro řídicí orgán, které činí nápravu řízenou informacemi o exploitech obhajitelnou před auditorem, regulačním orgánem i vašimi zákazníky.

Stáhněte si Zenith Blueprint, prozkoumejte Zenith Controls nebo požádejte o posouzení připravenosti Clarysec a vybudujte svůj pracovní postup řízení CISA KEV a ENISA EUVD dříve, než se příští páteční zranitelnost stane otázkou pro řídicí orgán.