Hlavní strana -> Časopis IT Systems -> Rok 2026 -> IT Systems 9/2026 -> Máte 24 hodin na odpověď
IT SYSTEMS 9/2026 , IT Security , IT právo

Máte 24 hodin na odpověď

Co mění Cyber Resilience Act od 11. září ve vývoji digitálních výrobků

Jaroslav Eliáš
Od 11. září 2026 se začínají uplatňovat oznamovací povinnosti podle aktu o kybernetické odolnosti (Cyber Resilience Act). Kybernetická bezpečnost se tím přesouvá z okraje IT do konstrukce, systémového inženýrství a změnového řízení. Rozhodující nebude počet dokumentů, ale schopnost během hodin zjistit, které výrobky a verze jsou dotčeny. Za nesplnění hrozí pokuta až 15 milionů eur nebo 2,5 % celosvětového obratu.
Kdyby dodavatel zítra oznámil aktivně zneužívanou zranitelnost, dokázali byste do 24 hodin určit všechny dotčené dodané konfigurace, vyhodnotit riziko a doložit, jak jste rozhodli?



Nejde jen o bezpečnost IT

Představme si následující modelovou situaci. Je pátek odpoledne a dodavatel softwarové knihovny publikuje záznam o zranitelnosti s poznámkou, že je aktivně zneužívána. Ta knihovna je ve firmwaru řídicí jednotky, kterou dodáváte čtvrtý rok ve třech hardwarových revizích a jedenácti zákaznických variantách. Technicky je problém pojmenován. Pro výrobce ovšem teprve začíná složitější část práce.
Ve kterém sestavení se komponenta nachází? Do jakých hardwarových revizí byla nasazena? Kterých variant, sérií a zákaznických konfigurací se týká? Jaké požadavky, testy a schválení musí být znovu otevřeny? A kdo má pravomoc rozhodnout, zda je výrobek skutečně zasažen?
Problém obvykle není v nedostatku dat, ale v chybějícím propojení mezi softwarem, produktovou konfigurací, změnami a dodanými výrobky. Analýza rizik bývá v tabulce, architektura v systémovém modelu, kód v repozitáři, kusovník v PLM a servisní data jinde. Každý záznam může být správný, přesto z nich nelze v časovém tlaku sestavit spolehlivou odpověď.
Problém obvykle není v nedostatku dat, ale v jejich chybějícím propojení.

Dvě data, která mění priority

Cyber Resilience Act (CRA), nařízení (EU) 2024/2847, dopadá na hardwarové i softwarové výrobky s digitálními prvky uváděné na trh EU, jejichž zamýšlené nebo rozumně předvídatelné použití zahrnuje přímé či nepřímé datové spojení se zařízením nebo sítí. Rozsah je nutné posoudit podle role organizace, povahy výrobku a případných výjimek.
Hlavní povinnosti se začnou uplatňovat 11. prosince 2027. Výrobce bude muset promítnout posouzení kybernetických rizik do návrhu, vývoje, výroby i údržby, doložit plnění základních požadavků v technické dokumentaci, provést posouzení shody a po uvedení na trh řešit zranitelnosti po dobu podpory, nejméně pět let. Označení CE tak nebude koncem bezpečnostní práce, ale jedním z milníků dlouhodobé odpovědnosti. Dříve získané certifikace to neřeší: ISO 27001 ani IEC 62443 presumpci shody nezakládají a harmonizované normy k CRA zatím nejsou.
Oznamovací povinnosti však přicházejí dřív, už 11. září 2026. U aktivně zneužívané zranitelnosti nebo závažného incidentu s dopadem na bezpečnost výrobku musí výrobce odeslat včasné varování do 24 hodin od okamžiku, kdy se o události dozví, a hlavní oznámení do 72 hodin. Závěrečná zpráva následuje nejpozději 14 dní poté, co je k dispozici nápravné opatření, u závažného incidentu do jednoho měsíce. Dotčené uživatele je navíc třeba informovat ve strojově čitelném formátu včetně dostupných opatření. Hlášení se podává přes jednotnou platformu ENISA a směruje se současně agentuře ENISA a národnímu CSIRT určenému jako koordinátor.

Co se hlásit nemusí

Spouštěče jsou jen dva a jsou úzké: aktivně zneužívaná zranitelnost, u níž existují spolehlivé doklady o zneužití, a závažný incident s dopadem na bezpečnost výrobku. Běžné chyby a obyčejné aktualizace do rozsahu nepatří. K 11. září 2026 nařízení nevyžaduje zavedené procesy zacházení se zranitelnostmi ani technickou dokumentaci; platí pouze oznamovací povinnosti.
Důležitý detail: plné CRA se na výrobky uvedené na trh před prosincem 2027 vztahuje jen tehdy, projdou-li po tomto datu podstatnou změnou. U oznamovací povinnosti to neplatí, ta se vztahuje na vše, co je na trhu. Výrobek dodaný v roce 2020, kterého se už nikdo nedotkne, musí mít od září 2026 funkční schopnost hlásit do 24 hodin. Dílčí otázky zpřesnily pokyny Evropské komise z července 2026.
 

Obr. 1. Dvě data, od kterých se odvíjí příprava, a lhůty plynoucí z toho prvního

SBOM je začátek, ne úplná odpověď

Softwarový kusovník (SBOM, software bill of materials) dává strukturovaný přehled použitých komponent a jejich verzí. CRA jej vyžaduje v příloze I části II, tedy mezi požadavky na zacházení se zranitelnostmi, ne mezi požadavky na návrh. Musí být v běžně používaném a strojově čitelném formátu a pokrývat alespoň závislosti první úrovně; ručně udržovaná tabulka nevyhoví. Uchovává se deset let, nebo po dobu podpory, je-li delší.
Sám o sobě však SBOM neodpoví na nejdražší otázku: kde přesně se dotčený software nachází ve fyzickém výrobku, v jaké revizi a s jakou platností.
Praktická sledovatelnost vyžaduje návaznost od komponenty a sestavení přes softwarovou položku k definici produktu, variantě, revizi, platnosti (effectivity), uvolněné konfiguraci, a pokud jsou data k dispozici, k dodanému kusu. Stejně důležité jsou vazby na požadavky, testy, změnové řízení a schvalovací historii. Teprve tehdy lze z bezpečnostního nálezu udělat produktové rozhodnutí.
 

Obr. 2. Řetězec sledovatelnosti. SBOM pokrývá levou část, odpověď na hlášení vyžaduje i pravou.
 
Neznamená to, že všechna data musejí být v jedné aplikaci. Specializované nástroje mají dál svou roli, potřebují však stabilní identity objektů, řízené vazby a společná pravidla změn. Digitální vlákno (digital thread) tu má význam důkazního řetězce, nikoli pohodlnějšího úložiště dokumentů.
Postavit takový řetězec je možné z existujících nástrojů. Například na platformě 3DEXPERIENCE se to řeší takto: aplikace Connected Software váže repozitář (Git, GitHub, GitLab či Artifactory) na softwarovou položku, kterou lze vložit do multidisciplinárního kusovníku vedle mechaniky a elektro. Nahlášený problém se naváže na produkt i na dotčenou verzi programu a řeší se přes objekt Investigation Request, který po sobě zanechá auditovatelnou historii rozhodnutí. Kód se v platformě nepíše, řídí se v ní vazba a změna; procesní vrstvu doplňuje Iterop.

Připravit, analyzovat, reagovat

Funkční model kybernetické odolnosti lze rozdělit do tří navazujících schopností. Nejde o názvy softwarových modulů, ale o způsob práce napříč bezpečností, konstrukcí, vývojem softwaru, kvalitou a servisem.
 

Připravit: bezpečnost musí vznikat spolu s architekturou

Ještě před prvním incidentem musí být jasné, co výrobek chrání, jaké scénáře poškození mohou nastat a jaká opatření jsou požadována. Metody typu TARA (Threat Analysis and Risk Assessment) propojují aktiva, hrozby, scénáře útoku, hodnocení rizik a odvozené kybernetické požadavky; v modelově orientovaném systémovém inženýrství lze navíc dohledat, ke kterému prvku architektury se požadavek vztahuje. Podstatné je, aby změna architektury, dodavatele nebo komponenty spustila nové posouzení dopadu. Analýza rizik uložená jako jednorázová prezentace zastarává, řízený model zůstává součástí živé definice výrobku.

Analyzovat: převést bezpečnostní signál na dopad do produktu

Když přijde informace o zranitelnosti, je nejprve třeba určit stabilní identitu dotčené komponenty nebo sestavení. Následuje dohledání produktových struktur, revizí, variant a období platnosti. Teprve pak lze rozhodnout, zda je zasažen celý produktový typ, jen určitá konfigurace, nebo žádný dodaný výrobek. Rozdíl mezi produktovou řadou a přesnou uvolněnou konfigurací je zásadní: příliš široké vyhodnocení vede k nákladným zásahům, příliš úzké přehlédne část instalované základny.

Reagovat: uzavřít smyčku řízenou změnou

Zjištěný dopad musí přejít do opakovatelného procesu: zaznamenat zdroj a čas signálu, určit vlastníka, vyhodnotit riziko, schválit způsob nápravy, zadat a ověřit změny, uvolnit opravenou konfiguraci a uchovat důkazy. Součástí reakce může být i zdůvodněné rozhodnutí, že výrobek zasažen není. Proces pro lhůty 24 a 72 hodin je třeba nacvičit dřív, než nastane kritická událost, včetně předávek mezi produktovou bezpečností, softwarovými týmy, kvalitou, servisem a změnovou autoritou. Improvizace přes e-mail nevytváří spolehlivou odpovědnost ani auditovatelnou historii.

Co v Česku ještě není dořešené

Nařízení CRA je přímo použitelné, povinnosti výrobce tedy na české legislativě nezávisí. Určení dozorových orgánů ale CRA nechává na členských státech. Podle návrhu adaptačního zákona, který Ministerstvo průmyslu a obchodu poslalo v červenci 2026 do připomínkového řízení, má být NÚKIB příjemcem oznámení podle článků 14 a 15 a hlavní díl dozoru nad trhem včetně softwaru má dostat Česká obchodní inspekce. Ovšem ke dni uzávěrky jde o návrh, ne o platný zákon.

Pět otázek pro rychlý test připravenosti

O připravenosti napoví víc než formální checklist pět otázek. U kolika z nich byste odpověď dokázali doložit do 24 hodin, tedy ve lhůtě, kterou vám dává nařízení?
  • Kde žije produktové posouzení kybernetických rizik a co spouští jeho aktualizaci po změně?
  • Propojíte zranitelnou komponentu s přesným softwarovým sestavením a uvolněnou konfigurací výrobku?
  • Kdo rozhoduje, zda zranitelnost výrobek ovlivňuje, a kde je uloženo odůvodnění?
  • Existuje popsaná cesta, jak urgentní oprava projde řízením kvality a konfigurace bez ztráty rychlosti?
  • Sestavíte podklady pro 24hodinové varování z řízených dat, nebo z tabulek a e-mailů?
Každá otázka, u níž odpověď zní „musel bych se poptat“, je hodina, kterou v září nebudete mít.

Důkaz jako vedlejší produkt každodenní práce

CRA nepředepisuje nákup konkrétního PLM, ALM, MBSE ani bezpečnostního nástroje. Vyžaduje však výsledky, které bez propojené produktové reality vznikají obtížně: průběžné posuzování rizik, kontrolu komponent třetích stran, technickou dokumentaci, řízené zacházení se zranitelnostmi a dohledatelné změny.
Nejlépe připravené organizace proto nebudou před auditem ani incidentem zpětně rekonstruovat, co se stalo. Důkazní stopa vznikne jako vedlejší produkt běžného vývoje: rozhodnutí spojené s rizikem, riziko s architekturou, architektura s požadavky a implementací, implementace s konfigurací a náprava s ověřenou uvolněnou verzí.
To je skutečný posun, který akt o kybernetické odolnosti přináší do konstrukce. Kybernetická odolnost už není dokument, který vznikne na konci projektu. Je to schopnost výrobce kdykoli vysvětlit, co dodal, jaké riziko vyhodnotil, co změnil a proč je jeho rozhodnutí obhajitelné.
 
Jaroslav Eliáš
Autor článku působí jako Sales Manager ve společnosti TECHNODAT, CAE-systemy, s. r. o. Věnuje se zavádění řešení pro správu produktových dat, systémového inženýrství a změnového řízení ve strojírenských a výrobních firmách.
 
Poznámka: Článek je redakčním odborným textem a nenahrazuje právní posouzení konkrétního výrobku ani role organizace.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Novinky ze světa kybernetické bezpečnosti na veletrhu it-sa Expo&Congress

Pozvánka se vstupem zdarma

Největší evropský veletrh kybernetické bezpečnosti it-sa Expo&Congress, který se uskuteční v termínu od 27. do 29. října 2026 na výstavišti v Norimberku, potvrzuje svou pozici globálního barometru v oblasti ochrany dat a digitální suverenity.