ENISA EUVD 2026: ISO 27001 pro NIS2 a CRA

Je úterý roku 2026, 08:17. Maria, ředitelka informační bezpečnosti (CISO) rychle rostoucí fintech SaaS platformy, obdrží během několika minut dva signály. Nejprve SOC zveřejní do incidentního kanálu upozornění z ENISA EU Vulnerability Database. Dotčená komponenta není přímo ve vlastním kódu Mariina týmu. Nachází se v autentizačním SDK třetí strany, které je vložené do mobilní aplikace udržované partnerem pro outsourcovaný vývoj.

Poté bezpečnostní výzkumník pošle e-mail na veřejný bezpečnostní kontakt s předmětem: “Oznámení zranitelnosti - váš SaaS produkt”. Výzkumník tvrdí, že za určitých podmínek by chyba mohla zpřístupnit nekritická zákaznická metadata.

Není potvrzeno žádné narušení bezpečnosti. Žádný zákazník nehlásil újmu. Řídicí panel skeneru neukazuje kritický stav. Otázky však přicházejí okamžitě.

Jsme zranitelní? Které služby dostupné zákazníkům SDK používají? Jde o významný incident podle NIS2, incident související s ICT podle DORA, porušení zabezpečení osobních údajů podle GDPR, nebo problém bezpečnosti produktu podle Cyber Resilience Act? Musíme informovat dodavatele, zákazníka, příslušný orgán nebo ENISA? A především: dokážeme prokázat, kdy jsme se o tom dozvěděli?

Právě v tomto okamžiku mnoho organizací zjistí, že informace o zranitelnostech nejsou problémem datového zdroje. Jsou problémem provozního modelu.

ENISA EUVD se stane praktickým referenčním bodem pro informace o zranitelnostech v EU, koordinované zveřejňování zranitelností a transparentnost bezpečnosti produktů. Samotná databáze však Marii neřekne, zda je dotčená služba v rozsahu NIS2, zda se uplatní DORA z důvodu činností finančních služeb, zda je pravděpodobná expozice osobních údajů ani zda se spouští připravenost na hlášení podle CRA. Tato rozhodnutí musí proběhnout uvnitř řízeného, dokumentovaného a auditovatelného systému řízení bezpečnosti informací.

Přístup Clarysec spočívá v zavedení EUVD do provozní praxe prostřednictvím správy a řízení podle ISO/IEC 27001:2022, implementace opatření ISO/IEC 27002:2022, vlastnictví politik a důkazů napříč požadavky na soulad. Cílem není vytvořit další tabulku s názvem “EUVD tracker”. Cílem je vybudovat obhajitelný model pro práci s informacemi o zranitelnostech a pro hlášení, který obstojí při dotazech regulačních orgánů, zákaznických auditech, certifikačních auditech ISO 27001 i přezkumu řídicím orgánem.

Proč ENISA EUVD v roce 2026 mění řízení zranitelností

Bezpečnostní týmy po mnoho let vnímaly informace o zranitelnostech jako vstup pro záplatování. Objeví se CVE, skener zjistí expozici, provoz nasadí záplatu a tiket se uzavře. Pro organizace regulované v EU už tento model nestačí.

NIS2 přesouvá řízení rizik kybernetické bezpečnosti do oblasti správy a řízení. Article 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření pro řízení rizik kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení v oblasti kybernetické bezpečnosti. Article 21 vyžaduje přiměřená technická, provozní a organizační opatření, včetně politik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a údržby, nakládání se zranitelnostmi a jejich zveřejňování, posuzování účinnosti, kybernetické hygieny, kryptografie, bezpečnosti lidských zdrojů, řízení přístupu, správy aktiv a případně vícefaktorové autentizace nebo průběžné autentizace.

Article 23 doplňuje postupné hlášení významných incidentů, včetně včasného varování do 24 hodin od okamžiku, kdy se organizace o incidentu dozví, oznámení incidentu do 72 hodin a závěrečné zprávy do jednoho měsíce. Pokud se upozornění EUVD změní ve zneužité narušení služby, organizace potřebuje důkazy o okamžiku zjištění, triáži, posouzení dopadů, zmírnění a rozhodnutích o hlášení.

DORA vytváří paralelní, ale sektorově specifický režim pro finanční subjekty. Vyžaduje vnitřní uspořádání správy a řízení a kontrolu rizik ICT, odpovědnost řídicího orgánu, procesy řízení incidentů, řízení rizik ICT třetích stran, testování, odolnost, smluvní kontroly a hlášení závažných incidentů souvisejících s ICT podle DORA Article 19. Pro finanční subjekty v rozsahu působnosti funguje DORA jako sektorově specifický rámec pro rizika ICT a hlášení incidentů.

GDPR přidává další rozměr. Pokud by zneužití mohlo způsobit neoprávněný přístup, zpřístupnění, ztrátu, změnu nebo zničení osobních údajů, musí se postup řízení zranitelností propojit s posouzením porušení zabezpečení osobních údajů. Zásada odpovědnosti podle GDPR znamená, že správce musí soulad prokázat, nikoli pouze tvrdit, že postupoval přiměřeně.

Cyber Resilience Act činí z nakládání se zranitelnostmi a koordinovaného zveřejňování zranitelností povinnost v oblasti bezpečnosti produktů s digitálními prvky. Zároveň vytváří očekávání ohledně hlášení aktivně zneužívaných zranitelností a závažných bezpečnostních incidentů tam, kde je to relevantní. I když konečné právní rozhodnutí o hlášení vyžaduje odborné posouzení, provozní důkazy jsou bezpečnostní důkazy: dotčený produkt, dotčená verze, zneužitelnost, zmírnění, stav oznámení, dopad na zákazníky, koordinace s dodavateli a časová osa.

Jakmile je zranitelnost veřejně viditelná prostřednictvím EUVD, auditoři a regulační orgány se mohou ptát, proč nebyla posouzena, proč nebyla identifikována dotčená aktiva, proč nebyli kontaktováni dodavatelé nebo proč nebylo zvažováno hlášení. Nejsilnější organizace budou schopny odpovědět na šest otázek s důkazy:

1. Která upozornění EUVD jsou pro nás relevantní?
2. Která aktiva, produkty, dodavatelé a zákazníci jsou dotčeni?
3. Kdo vlastní rozhodnutí?
4. Jaká lhůta platí pro nápravu nebo zmírnění?
5. Kdy se řízení zranitelnosti mění v hlášení incidentu?
6. Jak prokážeme uzavření a dohled vedení?

Základ ISO 27001:2022 pro důkazy EUVD

ISO/IEC 27001:2022 je přirozenou páteří systému řízení pro zavedení EUVD do provozní praxe, protože začíná kontextem, zainteresovanými stranami, rozsahem, rizikem a důkazy.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace definovala interní a externí otázky, zainteresované strany, právní, regulační a smluvní požadavky, rozsah ISMS, rozhraní a závislosti. Pro připravenost na EUVD nemůže rozsah ISMS končit u interních serverů. Musí zohlednit SaaS produkty, cloudové služby, outsourcovaný vývoj, poskytovatele řízených služeb, dodavatele ICT, závazky vůči zákazníkům, regulační povinnosti a očekávání týkající se zranitelností produktů.

Kapitoly 5.1 až 5.3 vyžadují vedení, sladění politik, zdroje, komunikaci, odpovědnost a odpovědnosti za hlášení. Zde vrcholové vedení přijímá skutečnost, že informace o zranitelnostech nejsou technická zdvořilost. Jsou signálem podnikatelského rizika.

Kapitoly 6.1.1 až 6.1.3 poskytují mechanismus pro posouzení rizik, ošetření rizik, výběr opatření, porovnání s přílohou A, Prohlášení o použitelnosti, schválení zbytkového rizika a plánování ošetření rizik. Pokud položka EUVD ovlivní prostředí, reakce musí spustit opakovatelný rizikový postup, který propojí dotčená aktiva, pravděpodobnost, dopad, stávající opatření, možnosti ošetření a schválení vlastníkem rizika.

Kapitoly 8.1 až 8.3 a 9.1 až 9.3 převádějí tento model do provozního cyklu. Organizace musí plánovat a řídit procesy ISMS, uchovávat dokumentované informace, řídit externě poskytované procesy, znovu posuzovat rizika, implementovat plány ošetření, monitorovat a měřit výkonnost, provádět interní audity a uskutečňovat přezkoumání vedením.

V praxi Clarysec mapuje EUVD do tří vrstev:

Základní princip je jednoduchý. Upozornění EUVD se musí stát záznamy uvnitř ISMS, nikoli neformálními zprávami v chatu, které zmizí po nasazení záplaty.

Soubor opatření ISO 27001, díky kterému je EUVD použitelná

Nejdůležitější opatření přílohy A ISO/IEC 27001:2022 pro provoz EUVD jsou 5.7 informace o hrozbách, 8.8 řízení technických zranitelností, 5.21 řízení bezpečnosti informací v dodavatelském řetězci ICT a 5.31 právní, zákonné, regulační a smluvní požadavky.

Clarysec je mapuje prostřednictvím Zenith Controls: The Cross-Compliance Guide Zenith Controls, který slouží jako kompas napříč požadavky na soulad pro ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF a plánování auditních důkazů.

Mapování Zenith Controls pro opatření ISO/IEC 27002:2022 5.7, informace o hrozbách, jej označuje jako preventivní, detekční a nápravné, podporující důvěrnost, integritu a dostupnost a sladěné s koncepty kybernetické bezpečnosti Identify, Detect a Respond. Jeho provozní schopností je řízení hrozeb a zranitelností, s bezpečnostními doménami ochrany a odolnosti.

Mapování Zenith Controls pro opatření ISO/IEC 27002:2022 8.8, řízení technických zranitelností, jej označuje jako preventivní, podporující důvěrnost, integritu a dostupnost a sladěné s Identify a Protect. Jeho provozní schopností je řízení hrozeb a zranitelností a jeho bezpečnostní domény zahrnují správu a řízení, ekosystém, ochranu a obranu.

Mapování Zenith Controls pro opatření ISO/IEC 27002:2022 5.21, řízení bezpečnosti informací v dodavatelském řetězci ICT, jej označuje jako preventivní, podporující důvěrnost, integritu a dostupnost a sladěné s Identify. Jeho provozní schopností je bezpečnost vztahů s dodavateli, s doménami správy a řízení, ekosystému a ochrany.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint také zdůrazňuje opatření 5.31 v kroku 23, právní, zákonné, regulační a smluvní požadavky:

Bezpečnost neexistuje ve vakuu. Funguje v síti povinností, z nichž některé vyplývají ze zákona, jiné ze smluv a další ze sektorové regulace.

To je řídicí most mezi EUVD a regulatorním hlášením. Záznam o zranitelnosti může začít jako informace o hrozbách, stát se tiketem technické zranitelnosti, vyvolat spolupráci s dodavatelem a následně se stát incidentem nebo rozhodnutím o právním oznámení.

Proto by EUVD neměla být považována jen za další datový zdroj. Je to integrační bod opatření.

Model politik Clarysec: od upozornění k odpovědnému rozhodnutí

Vyspělý provozní model EUVD potřebuje jazyk politik, který týmům říká, co mají dělat ještě před příchodem prvního kritického upozornění.

Vulnerability and Patch Management Policy společnosti Clarysec Vulnerability and Patch Management Policy dává podnikovým týmům jasný mandát k monitorování a eskalaci:

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

Tatáž politika vyžaduje centrální důkazní základnu:

Centralizovaný registr zranitelností musí udržovat tým bezpečnostního provozu a měsíčně jej musí přezkoumávat CISO nebo pověřená osoba.

Pro malé a střední podniky Clarysec Vulnerability and Patch Management Policy - SME Vulnerability and Patch Management Policy - SME výslovně stanoví model zdrojů zahrnutím:

Důvěryhodná upozornění v rámci informací o hrozbách (např. CISA, ENISA, upozornění národních CERT)

Zároveň zachovává auditní stopu:

Log záplat musí být udržován a přezkoumáván během auditů a činností reakce na incidenty

Tato ustanovení brání běžnému selhání. Pokud dorazí upozornění EUVD a nikdo neví, zda patří do registru zranitelností, fronty incidentů, evidence dodavatelů nebo právního posouzení, organizace ztrácí čas. Jazyk politiky činí první krok automatickým.

Rozměr CVD je řešen prostřednictvím Coordinated Vulnerability Disclosure Policy společnosti Clarysec Coordinated Vulnerability Disclosure Policy, která stanoví postup příjmu, potvrzení přijetí, posouzení závažnosti a ověření:

Po obdržení hlášení jej VRT zaznamená a do 2 pracovních dnů odešle oznamovateli potvrzení o přijetí s přiřazeným referenčním číslem. VRT provede předběžné posouzení závažnosti, například pomocí skórování CVSS, a ověří problém, včetně podpory týmů IT a vývoje tam, kde je to nezbytné, v cílové lhůtě 5 pracovních dnů. Kritické zranitelnosti, například ty, které umožňují vzdálené spuštění kódu nebo závažné porušení zabezpečení dat, se řeší zrychleně.

Zároveň propojuje zranitelnosti třetích stran se spoluprací dodavatelů:

U každé potvrzené kritické nebo vysoce rizikové zranitelnosti CISO neprodleně informuje vrcholové vedení a příslušné vlastníky systémů. Pokud zranitelnost ovlivňuje produkty nebo služby poskytované dodavatelem nebo jinou třetí stranou, VRT bez zbytečného odkladu informuje bezpečnostní kontakt dodavatele a usiluje o spolupráci na nápravě.

Application Security Requirements Policy - SME společnosti Clarysec Application Security Requirements Policy - SME posiluje očekávání vůči produktům a dodavatelům tím, že od týmů vyžaduje:

specifikovat povinnosti pro oznamování zranitelností, reakční doby a záplatování.

Pro dodavatelské smlouvy obsahuje Third-Party and Supplier Security Policy - SME společnosti Clarysec Third-Party and Supplier Security Policy - SME:

Lhůty pro oznámení porušení zabezpečení dat (např. do 24-72 hodin)

Nakonec Incident Response Policy společnosti Clarysec Incident Response Policy propojuje regulovaná data a sektorové hlášení s rozhodnutím o incidentu prostřednictvím článku 6.4.1:

Verze pro malé a střední podniky zachovává stejný praktický spouštěč. Clarysec Incident Response Policy - SME Incident Response Policy - SME uvádí:

Pokud jsou dotčena zákaznická data, generální ředitel musí posoudit právní oznamovací povinnosti na základě použitelnosti GDPR, NIS2 nebo DORA.

To je most mezi “viděli jsme zranitelnost” a “posoudili jsme, zda podléhá hlášení”.

Praktický záznam příjmu EUVD

Předpokládejme, že EUVD zveřejní nebo aktualizuje položku zranitelnosti ovlivňující autentizační SDK v Mariině mobilní aplikaci. SDK udržuje dodavatel, integruje jej partner pro outsourcovaný vývoj a používají jej zákazníci, kteří se autentizují do fintech SaaS produktu. Existuje veřejná diskuse o exploitu, ale v logách tenantů není potvrzeno žádné zneužití.

Obhajitelný záznam příjmu musí zachytit technický i regulatorní kontext.

Tento záznam není ozdobou pro soulad. Je to řídicí centrum pro rozhodování.

Praktický postup vypadá takto:

1. SOC přijme upozornění EUVD a vytvoří záznam o zranitelnosti.
2. Vlastník aktiva potvrdí, zda dotčená komponenta existuje v produkčním prostředí.
3. Bezpečnostní tým provede posouzení závažnosti podle technické závažnosti, zneužitelnosti, expozice, citlivosti dat a kritičnosti služby.
4. Vlastník dodavatele kontaktuje dodavatele SDK nebo partnera pro outsourcovaný vývoj pomocí předem stanovených bezpečnostních kontaktů.
5. Vedoucí reakce na incidenty rozhodne, zda existují důkazy o zneužití, dopadu na službu nebo újmě zákazníků.
6. Právní oddělení, DPO a funkce compliance posoudí, zda se spouští postupy související s GDPR, NIS2, DORA nebo CRA.
7. Engineering nasadí záplatu nebo zmírnění.
8. Bezpečnost ověří nápravu prostřednictvím skenu, kontroly verze, přezkumu logů nebo testu kompenzačního opatření.
9. CISO přezkoumá kritické a vysoké záznamy a reportuje trendy do přezkoumání vedením.

Ve fázi Opatření v praxi, krok 19, Technologická opatření I, vysvětluje Zenith Blueprint technické řízení zranitelností srozumitelně pro audit:

Toto opatření není o dokonalosti, ale o organizovaném, transparentním a odpovědném procesu.

Na této větě záleží. Regulační orgány a auditoři neočekávají, že každá zranitelnost bude opravena okamžitě. Očekávají, že organizace ví, co existuje, prioritizuje to, přijímá přiměřená opatření, zaznamenává výjimky a prokazuje dotažení do konce.

Informace o hrozbách jsou rozhodovací funkce, nikoli poštovní schránka

Největší chybou při plánování EUVD je přiřadit datový zdroj jednomu analytikovi a označit to za “informace o hrozbách”. Zenith Blueprint ve fázi Opatření v praxi, krok 22, Organizační opatření, vysvětluje opatření ISO/IEC 27002:2022 5.7 takto:

Nejlepší zdroje informací o hrozbách často představují kombinaci interního monitorování, externích partnerství a zapojení komunity.

Zároveň upozorňuje, že informace se musí změnit v akci:

Toto opatření skutečně ožívá při rozhodování. Informace o hrozbách by měly přímo ovlivňovat, která opatření se zpřísní, která aktiva se reklasifikují nebo izolují, jaké scénáře se testují v tabletop cvičeních a jak rychle se nasazují záplaty nebo zmírňující opatření.

Pro EUVD musí být příjemci informací definováni podle rolí.

NIST CSF 2.0 může pomoci tento model strukturovat. Jeho funkce GOVERN zdůrazňuje očekávání zainteresovaných stran, právní a regulační povinnosti, ochotu podstupovat riziko, odpovědnost vedení, definované role, politiku, zdroje a dohled. Jeho provozní funkce pomáhají organizovat evidenci aktiv, identifikaci zranitelností, ochranu, detekci, reakci, obnovu a zlepšování. Metodu profilu NIST CSF lze použít k definování aktuálního a cílového stavu provozu EUVD a následně převést mezery do prioritizovaného akčního plánu.

V pojetí Clarysec je NIST CSF užitečnou organizační vrstvou, ISO/IEC 27001:2022 je auditovatelným systémem řízení a Zenith Controls je kompasem napříč požadavky na soulad, který udržuje mapování konzistentní.

Sledování zranitelností dodavatelů a produktů

NIS2 Article 21 činí zabezpečení dodavatelského řetězce součástí minimálních opatření pro řízení rizik kybernetické bezpečnosti. Article 21(3) vyžaduje, aby subjekty zohledňovaly zranitelnosti specifické pro každého přímého dodavatele a poskytovatele služeb, kvalitu produktů a postupy kybernetické bezpečnosti dodavatelů, včetně postupů bezpečného vývoje. Recitály 85 a 86 zdůrazňují riziko třetích stran vyplývající ze zpracování dat, řízených služeb, dodavatelů softwaru a poskytovatelů řízených bezpečnostních služeb.

DORA je pro finanční subjekty preskriptivnější. Vyžaduje, aby riziko ICT třetích stran bylo řízeno jako součást rámce rizik ICT, včetně registrů informací, náležité péče, analýzy rizika koncentrace, písemných smluv, práv na audit a kontrolu, podpory při incidentech, viditelnosti subdodavatelů, bezpečnostních požadavků, práv na ukončení a otestovaných strategií odchodu.

EUVD bolestivě zviditelní slabou přehlednost dodavatelů. Pokud je dotčena dodavatelská komponenta, organizace potřebuje víc než kontakt z nákupu. Potřebuje:

1. Jmenovaný bezpečnostní kontakt dodavatele.
2. Smluvní povinnosti oznamovat zranitelnosti.
3. Evidenci produktů a verzí.
4. SBOM nebo transparentnost komponent tam, kde je relevantní.
5. SLA pro nápravu a povinnosti náhradních postupů.
6. Práva na audit nebo ujištění.
7. Povinnosti podpory při incidentech.
8. Plány odchodu nebo nahrazení u kritických závislostí.

Proto Clarysec mapuje provoz EUVD na opatření ISO/IEC 27002:2022 5.21 prostřednictvím Zenith Controls. Domény správy a řízení, ekosystému a ochrany odpovídají praktickému problému dodavatelů: nelze napravit to, co nelze dohledat, a nelze doložit to, co nebylo smluvně vyžadováno.

Pro připravenost na hlášení podle CRA se stejný záznam o zranitelnosti dodavatele a produktu stává zásadním. I když konečné regulatorní rozhodnutí vyžaduje právní analýzu, provozní důkaz pochází z bezpečnostních a inženýrských důkazů.

Kdy se zranitelnost EUVD stává incidentem

Ne každá zranitelnost je incident. Každá závažná zranitelnost by však měla být schopna rychle se stát záznamem incidentu.

Praktický spouštěč je tento: pokud informace EUVD ukazují možnou expozici, otevřete záznam o zranitelnosti. Pokud existují důkazy o zneužití, dopadu na službu, expozici regulovaných dat, újmě zákazníků nebo provozním narušení, propojte jej se záznamem incidentu nebo jej na incidentní záznam převeďte.

NIS2 Article 23 vyžaduje oznamování významných incidentů ovlivňujících poskytování služeb, včetně incidentů, které způsobují nebo mohou způsobit závažné provozní narušení nebo finanční ztrátu, nebo ovlivňují jiné osoby značnou hmotnou či nehmotnou újmou. DORA vyžaduje, aby finanční subjekty zaznamenávaly incidenty související s ICT a významné kybernetické hrozby, klasifikovaly závažné incidenty související s ICT, hlásily je podle Article 19 tam, kde je to vyžadováno, komunikovaly s klienty tam, kde jsou dotčeny finanční zájmy, a uzavíraly je s analýzou kořenové příčiny. GDPR vyžaduje posouzení porušení zabezpečení osobních údajů tam, kde bezpečnostní incident způsobí náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim.

Zenith Blueprint, fáze Opatření v praxi, krok 16, Personální opatření II, posiluje význam kultury hlášení:

Podporujte přístup “hlášení s nízkým prahem”; sdělení má znít: “Když si nejste jistí, hlaste.”

Pro EUVD to platí pro inženýry a dodavatele stejně jako pro zaměstnance. Pokud vývojář uvidí dotčenou závislost, pokud dodavatel potvrdí zneužitelnost nebo pokud podpora zaznamená podezřelé chování zákazníka, organizace musí upřednostnit včasnou triáž před opožděnou jistotou.

Jak auditoři otestují váš program EUVD

Silný provozní model EUVD musí být navržen pro více auditních pohledů. Stejné důkazy mohou splnit různá očekávání, pokud jsou dobře strukturované.

Auditor ISO 27001 obvykle vybere vzorek záznamu s vysokou závažností spuštěného EUVD a zeptá se, zda je propojen s rozsahem, povinnostmi vůči zainteresovaným stranám, posouzením rizik, ošetřením, opatřeními přílohy A, provozními důkazy a přezkumem. Hodnotitel orientovaný na NIST se zaměří na výsledky. Auditor ve stylu COBIT se zaměří na správu a řízení, vlastnictví, výkonnost a ujištění. Přezkum podle DORA bude věnovat zvýšenou pozornost závislostem ICT třetích stran, smluvním kontrolám a klasifikaci incidentů.

Reporting řídicímu orgánu bez šumu CVE

NIS2 a DORA staví řídicí orgány do centra odpovědnosti za kybernetickou bezpečnost. Vrcholové vedení však nepotřebuje výpis položek EUVD. Potřebuje reporting vhodný pro rozhodování.

Měsíční zpráva o informacích o zranitelnostech musí obsahovat:

1. Kritické a vysoké zranitelnosti spárované s EUVD, které ovlivňují aktiva v rozsahu.
2. Otevřené zranitelnosti mimo SLA pro nápravu.
3. Zpoždění způsobená dodavateli a smluvní eskalace.
4. Zranitelnosti propojené s incidenty nebo téměř vzniklými incidenty.
5. Spouštěče a výsledky postupu pro zranitelnosti produktů podle CRA.
6. Posouzení hlášení podle NIS2, DORA nebo GDPR.
7. Přijatá zbytková rizika a osoby, které je přijaly.
8. Trendy podle podnikové služby, produktu, dodavatele a kořenové příčiny.
9. Metriky účinnosti kontrol a zlepšovací opatření.

To přímo odpovídá očekáváním přezkoumání vedením podle kapitoly 9.3 ISO/IEC 27001:2022, včetně změn kontextu, potřeb zainteresovaných stran, trendů výkonnosti, výsledků auditů, plnění cílů, zpětné vazby, výsledků posouzení rizik, stavu ošetření a příležitostí ke zlepšení.

Běžná selhání připravenosti na EUVD

Organizace, které se potýkají s informacemi o zranitelnostech, obvykle selhávají předvídatelnými způsoby.

Za prvé, nemají spolehlivou evidenci aktiv a softwaru. Relevanci EUVD nelze posoudit bez názvů produktů, verzí, knihoven, cloudových služeb, dodavatelů a toků dat.

Za druhé, oddělují řízení zranitelností od reakce na incidenty. Tým zranitelností uzavírá tikety, zatímco incidentní tým nikdy neposoudí, zda došlo ke zneužití. Tím vznikají slepá místa v hlášení.

Za třetí, dodavatelské smlouvy mlčí. Pokud dodavatel není povinen oznámit, spolupracovat, záplatovat, poskytnout důkazy nebo podporovat reakci na incidenty, zákazník má během kritického časového okna jen malou vyjednávací sílu.

Za čtvrté, právní tým a DPO jsou zapojeni příliš pozdě. Pokud rozhodování o hlášení souvisejícím s GDPR, NIS2, DORA nebo CRA začne až poté, co engineering záplatu nasadil a posunul se dál, časová osa zjištění se stává nejasnou.

Za páté, reporting vedení je příliš technický. Řídicí orgány dostávají dlouhé seznamy CVE bez dopadu na podnikání, regulatorní relevance, trendů dodavatelů nebo rozhodnutí o zbytkovém riziku.

Metodika Clarysec toto napravuje propojením opatření. V Zenith Blueprint krok 19 posiluje technické řízení zranitelností, krok 22 uvádí informace o hrozbách do provozní praxe, krok 16 posiluje kulturu hlášení incidentů a krok 23 udržuje právní, zákonné, regulační a smluvní povinnosti viditelné.

30denní sprint připravenosti na EUVD

Pokud vaše organizace potřebuje rychlou cestu, začněte soustředěným 30denním sprintem.

První týden: definujte rozsah a povinnosti. Potvrďte, zda organizace může být základním nebo důležitým subjektem podle NIS2, zda se DORA vztahuje na finanční činnosti, zda se GDPR vztahuje na zpracování osobních údajů a kde mohou být relevantní povinnosti související se zranitelnostmi produktů podle CRA. Aktualizujte právní a smluvní registr ISMS.

Druhý týden: vybudujte postup příjmu. Přidejte EUVD, národní CERT, bezpečnostní oznámení dodavatelů a sektorové zdroje do seznamu zdrojů informací o zranitelnostech. Definujte, kdo otevírá záznamy, kdo ověřuje expozici, kdo kontaktuje dodavatele, kdo posuzuje hlášení a kdo schvaluje zbytkové riziko.

Třetí týden: propojte dodavatele a produkty. Identifikujte kritické produkty, služby dostupné zákazníkům, přímé dodavatele ICT, outsourcované vývojáře, poskytovatele cloudových služeb a poskytovatele řízených bezpečnostních služeb. Potvrďte bezpečnostní kontakty, smluvní doložky, povinnosti reakce na zranitelnosti a očekávání důkazů.

Čtvrtý týden: otestujte postup. Proveďte tabletop cvičení s realistickým upozorněním EUVD. Vyžadujte, aby tým vytvořil záznam o zranitelnosti, komunikaci s dodavatelem, posouzení incidentu, rozhodnutí o právním oznámení, log záplat, schválení zbytkového rizika a shrnutí pro vedení.

Výstupem nemá být sada slidů. Má to být důkazní balíček, ze kterého může auditor vybírat vzorky.

Udělejte z EUVD systém opatření, ne další datový zdroj

V roce 2026 nebudou organizace, které dobře zvládají ENISA EUVD, těmi, které se pouze přihlásí k odběru dalších upozornění. Budou to ty, které převádějí veřejné informace o zranitelnostech do rizikově orientované akce, odpovědnosti dodavatelů, koordinovaného zveřejňování, rozhodnutí o hlášení a auditních důkazů.

Clarysec vám může pomoci tento model vybudovat pomocí Zenith Blueprint Zenith Blueprint, knihovny politik Clarysec a Zenith Controls Zenith Controls. Mapujeme kapitoly ISO/IEC 27001:2022 a opatření ISO/IEC 27002:2022 na očekávání auditů podle NIS2, DORA, GDPR, NIST CSF a ve stylu COBIT a poté mapování převádíme do praktických registrů, playbooků, dodavatelských doložek a reportingu vedení.

Pokud se váš tým připravuje na nakládání se zranitelnostmi podle NIS2, připravenost na hlášení podle CRA, provoz CVD nebo informace o zranitelnostech řízené EUVD, začněte přezkumem připravenosti na EUVD od Clarysec. Pomůžeme vám identifikovat mezery, prioritizovat opatření a vybudovat auditní stopu dříve, než první kritické upozornění otestuje váš program.