CRA versus NIS2: produktová kybernetická bezpečnost a bezpečnost organizace – kde se režimy překrývají a jak do nich vstupuje AI Act?

Dva předpisy, dva různé pohledy na kybernetickou bezpečnost

Na první pohled mohou CRA a NIS2 působit jako dvě varianty téže kyberbezpečnostní regulace. Oba režimy pracují s řízením rizik, incidenty, zranitelnostmi nebo bezpečností dodavatelského řetězce. Jejich základní logika je ale odlišná.

Směrnice NIS2 [1] je primárně subjektovou a sektorovou regulací. Jejím těžištěm je řízení kybernetických rizik na úrovni regulovaných subjektů. Článek 21 směrnice za tímto účelem vymezuje rámec opatření k řízení kybernetických bezpečnostních rizik, který zahrnuje mimo jiné řešení incidentů, kontinuitu činností, bezpečnost dodavatelského řetězce, bezpečnost při pořizování, vývoji a údržbě sítí a informačních systémů nebo řízení zranitelností. V České republice jsou požadavky NIS2 promítnuty zejména do nového zákona o kybernetické bezpečnosti[2] (dále jen „ZoKB“), který vedle rozšíření okruhu regulovaných subjektů posiluje také požadavky na řízení kybernetických rizik, bezpečnost dodavatelského řetězce a odpovědnost vedení organizací.

Významnou změnou oproti dosavadnímu pojetí kybernetické bezpečnosti je také výslovné zapojení vedení regulovaných subjektů. NIS2 nepohlíží na kybernetickou bezpečnost pouze jako na technickou oblast v gesci IT oddělení, ale jako na součást řízení rizik na úrovni celé organizace. Členové statutárních orgánů a osoby odpovědné za řízení organizace musí zajistit, aby byla kybernetická rizika odpovídajícím způsobem zohledněna v řízení organizace, řádně identifikována, řízena a průběžně vyhodnocována.

Součástí tohoto přístupu je také odpovědnost vedení za schválení opatření k řízení kybernetických rizik, dohled nad jejich zavedením a zajištění odpovídajících znalostí a školení osob odpovědných za kybernetickou bezpečnost. Kybernetická bezpečnost se tak podle NIS2 stává nejen technickým, ale především řídicím a strategickým tématem.

Cyber Resilience Act [3] jde jinou cestou. Jde o horizontální produktovou regulaci, která stanoví povinné kyberbezpečnostní požadavky pro tzv. produkty s digitálními prvky. Těmi se rozumí softwarové nebo hardwarové produkty a jejich řešení pro vzdálené zpracování dat, včetně softwarových nebo hardwarových komponent uváděných na trh samostatně. CRA se vztahuje na takové produkty, pokud jejich zamýšlený účel nebo rozumně předvídatelné použití zahrnuje přímé či nepřímé logické nebo fyzické datové připojení k zařízení nebo síti. Nezaměřuje se primárně na to, jak bezpečně funguje organizace jako celek, ale na bezpečnost konkrétního produktu během jeho životního cyklu.

Základní rozdíl mezi oběma režimy tak spočívá v předmětu regulace. NIS2 se soustředí především na kybernetickou bezpečnost organizace a poskytovaných služeb, zatímco CRA stanoví požadavky na bezpečnost konkrétních produktů s digitálními prvky a na povinnosti jejich výrobců v průběhu celého životního cyklu produktu, tedy i po jeho uvedení na trh.

Jedna společnost může podléhat oběma režimům

Rozdílný předmět regulace neznamená, že by se působnost CRA a NIS2 ve vztahu ke konkrétní společnosti vzájemně vylučovala. Naopak, zejména u technologických společností se mohou oba režimy v praxi překrývat.

Rozdílný je však okruh povinných osob. V režimu NIS2 stojí v centru regulovaný subjekt, v českém prostředí poskytovatel regulované služby. CRA naproti tomu pracuje s hospodářskými subjekty v jednotlivých částech dodavatelského řetězce, především s výrobcem, ale také s dovozcem a distributorem produktu s digitálními prvky.

Výrobcem podle CRA přitom není pouze společnost, která produkt fakticky vyvinula nebo vyrobila. Podle čl. 3 CRA se za výrobce považuje také osoba, která si produkt nechá navrhnout, vyvinout nebo vyrobit a uvádí jej na trh pod svým jménem nebo ochrannou známkou. Prakticky tak mohou být povinnostmi výrobce dotčeny i společnosti, které produkt samy technicky nevyvíjejí, ale uvádějí jej na trh pod vlastní značkou, například v rámci private label nebo OEM modelů, kdy je produkt vyroben třetí stranou a následně uveden na trh pod značkou dané společnosti. Postavení jednotlivých subjektů se navíc může v průběhu životního cyklu produktu měnit. Dovozce nebo distributor se podle čl. 21 CRA považuje za výrobce například tehdy, pokud produkt uvede na trh pod vlastním jménem nebo ochrannou známkou nebo pokud provede jeho podstatnou změnu. Obdobné pravidlo se podle čl. 22 CRA uplatní také na jinou osobu, která produkt po jeho uvedení na trh podstatně změní a následně jej na trhu zpřístupní.

V praxi tak může například společnost poskytující cloudové nebo řízené IT služby současně vyvíjet a pod vlastní značkou uvádět na trh vlastní softwarový produkt. Pokud jsou splněny podmínky ZoKB, může být ve vztahu k poskytované službě poskytovatelem regulované služby a současně ve vztahu k vlastnímu produktu výrobcem podle CRA.

Souběh obou režimů má přímý dopad také na rozsah povinností společnosti. Na organizační úrovni musí podle pravidel vycházejících z NIS2 řídit kybernetická rizika, zavádět bezpečnostní opatření, řešit incidenty nebo bezpečnost dodavatelského řetězce. Ve vztahu ke konkrétnímu produktu musí podle CRA posoudit jeho kybernetická rizika, zajistit splnění požadavků na bezpečný návrh a vývoj, řídit zranitelnosti a bezpečnostní aktualizace a splnit požadavky na dokumentaci a posouzení shody.

Splnění režimu podle jednoho předpisu přitom automaticky neznamená splnění druhého. Dobře nastavený systém řízení kybernetické bezpečnosti podle NIS2 může vytvořit důležitý základ i pro plnění CRA, nenahradí však povinnosti, které jsou spojeny přímo s konkrétním produktem a s postavením jeho výrobce.

Regulatorní posouzení proto nelze založit pouze na tom, čím se společnost obecně zabývá. Je třeba samostatně určit, jaké služby poskytuje, jaké produkty uvádí na trh a v jakém postavení vystupuje ve vztahu ke každému z nich.

NIS2 řeší organizaci, CRA celý životní cyklus produktu

Tento rozdíl se dále promítá do samotného rozsahu povinností. Zatímco NIS2 staví na řízení kybernetických rizik na úrovni regulovaného subjektu, CRA promítá řízení těchto rizik přímo do životního cyklu konkrétního produktu.

Podle čl. 13 odst. 2 CRA musí výrobce provést posouzení kybernetických rizik spojených s produktem s digitálními prvky a jeho výsledek zohlednit při plánování, návrhu, vývoji, výrobě, dodání i údržbě produktu. Toto posouzení musí být podle čl. 13 odst. 3 dokumentováno a v průběhu doby podpory podle potřeby aktualizováno.

Konkrétní požadavky na bezpečnost produktu stanoví zejména příloha I CRA. Produkt musí být navržen, vyvinut a vyroben tak, aby s ohledem na identifikovaná rizika zajišťoval odpovídající úroveň kybernetické bezpečnosti. Příloha I dále stanoví konkrétní požadavky například na bezpečné výchozí nastavení, možnost řešit zranitelnosti prostřednictvím bezpečnostních aktualizací, ochranu před neoprávněným přístupem nebo omezení dopadů bezpečnostních incidentů. Samostatná část přílohy I se věnuje také procesům řízení zranitelností, jejich identifikaci, dokumentaci a nápravě.

Bezpečnost produktu tak podle CRA není jednorázovým požadavkem, který je třeba splnit pouze před jeho uvedením na trh. Výrobce za ni nese odpovědnost také v průběhu stanovené doby podpory, kdy musí průběžně řešit zranitelnosti a zajišťovat odpovídající bezpečnostní aktualizace.

Specificky produktovou povinností CRA je také stanovení doby podpory. Podle čl. 13 odst. 8 musí výrobce zohlednit očekávanou dobu používání produktu, jeho povahu, účel nebo dobu podpory relevantních komponentů třetích stran; zásadně přitom má doba podpory činit nejméně pět let; pokud se však očekává používání produktu po dobu kratší než pět let, odpovídá doba podpory této očekávané době používání. Po tuto dobu musí výrobce zajistit účinné řešení zranitelností produktu.

Dodavatelský řetězec v CRA a NIS2

Jednou z oblastí, ve kterých se CRA a NIS2 výrazně potkávají, je bezpečnost dodavatelského řetězce. NIS2 podle čl. 21 odst. 2 písm. d) zahrnuje mezi opatření k řízení kybernetických bezpečnostních rizik také bezpečnostní aspekty vztahů s přímými dodavateli a poskytovateli služeb. CRA se na dodavatelský řetězec dívá z pohledu bezpečnosti výsledného produktu.

Pokud výrobce integruje do produktu komponent třetí strany, musí podle čl. 13 odst. 5 CRA postupovat s náležitou péčí tak, aby tento komponent neohrozil bezpečnost produktu. CRA současně vyžaduje, aby výrobce identifikoval a dokumentoval zranitelnosti a komponenty obsažené v produktu, mimo jiné prostřednictvím softwarového kusovníku („SBOM“).

Povinnosti výrobce tak budou mít přímý dopad i na vztahy s jeho dodavateli, od nichž bude potřebovat informace o zranitelnostech a komponentech, bezpečnostní aktualizace nebo součinnost při řešení incidentů. Smluvním dopadům CRA na softwarový dodavatelský řetězec se proto budeme věnovat v navazujícím článku.

Procesy lze propojit, právní režimy však zůstávají samostatné

Překryv obou režimů neznamená, že splnění NIS2 automaticky zajistí soulad s CRA.

Rozdíl je patrný zejména u požadavků spojených s uvedením produktu na trh. CRA vyžaduje před uvedením produktu s digitálními prvky na trh posouzení jeho shody se základními kyberbezpečnostními požadavky, vypracování technické dokumentace a EU prohlášení o shodě a opatření produktu označením CE. Konkrétní způsob posuzování shody závisí na kategorii produktu. U produktů, které nejsou zařazeny mezi důležité nebo kritické produkty, lze využít postup založený na interní kontrole výrobce, zatímco u důležitých a kritických produktů podle příloh III a IV CRA se mohou uplatnit přísnější postupy, včetně zapojení oznámeného subjektu nebo příslušného evropského systému certifikace kybernetické bezpečnosti.

NIS2 obdobný produktový režim posuzování shody neobsahuje. Procesy zavedené v rámci NIS2 tak mohou výrobci poskytnout významné podklady pro řízení rizik, testování nebo dokumentaci podle CRA, nemohou však nahradit specifické povinnosti spojené s konkrétním produktem a jeho uvedením na trh.

Jeden incident může spustit několik oznamovacích režimů

Výrazný praktický překryv obou režimů nastává při řešení kybernetických incidentů. Jedna událost může zasáhnout regulovanou službu, současně souviset se zranitelností produktu s digitálními prvky a v některých případech vést také k porušení zabezpečení osobních údajů. Společnost proto musí v krátkém čase posoudit, které oznamovací režimy se na konkrétní situaci použijí.

Jednotlivé právní režimy však pracují s odlišnými kategoriemi incidentů a sledují odlišný účel oznamovací povinnosti. NIS2 pracuje s kategorií významného incidentu podle čl. 23, zatímco český ZoKB rozsah povinně hlášených incidentů dále rozlišuje podle režimu povinností a u některých digitálních služeb stanoví zvláštní pravidla. Povinnost oznámit incident typicky dopadá na regulovaný subjekt jako provozovatele služby.

CRA naopak sleduje bezpečnost konkrétního produktu s digitálními prvky. Výrobce má povinnost reagovat zejména na aktivně zneužívané zranitelnosti obsažené v produktu nebo na závažné incidenty, které mají dopad na bezpečnost produktu. Oznamovací povinnost tedy nevzniká proto, že incident zasáhl konkrétní organizaci jako uživatele produktu, ale proto, že se týká bezpečnosti produktu uváděného na trh.

Samostatně je třeba posoudit také případný dopad do oblasti ochrany osobních údajů. Pokud kybernetický incident vede k porušení zabezpečení osobních údajů, může vzniknout oznamovací povinnost podle GDPR vůči dozorovému úřadu, případně informační povinnost vůči dotčeným subjektům údajů. Tato povinnost se přitom posuzuje nezávisle na tom, zda současně vznikla oznamovací povinnost podle NIS2, ZoKB nebo CRA.

V praxi tak jedna bezpečnostní událost může vyžadovat několik paralelních právních posouzení. Rozhodující není pouze technická povaha incidentu, ale zejména role konkrétního subjektu, povaha dotčeného systému nebo produktu a dopad incidentu na chráněný zájem jednotlivých právních režimů.

NIS2 v čl. 23 stanoví vícestupňový mechanismus oznamování významných incidentů, na který navazuje česká úprava v ZoKB. Ten pracuje s vlastním vymezením povinně hlášených kybernetických bezpečnostních incidentů, přičemž rozsah oznamovací povinnosti se liší podle režimu povinností. Poskytovatel v režimu vyšších povinností podle § 15 odst. 1 ZoKB hlásí incidenty, které se projevily ve stanoveném rozsahu, mají původ v kybernetickém prostoru a u nichž nelze ve lhůtě pro prvotní hlášení vyloučit úmyslné zavinění. V režimu nižších povinností musí incident navíc dosahovat významného dopadu na poskytování regulované služby. U vybraných služeb uvedených v § 18 ZoKB se však uplatní zvláštní režim, podle něhož se hlásí kybernetické bezpečnostní incidenty s významným dopadem na poskytování regulované služby; § 15 odst. 1 a 2 se v tomto případě pro vymezení hlášených incidentů nepoužijí. Prvotní hlášení se podle § 16 ZoKB podává bez zbytečného odkladu, nejpozději do 24 hodin od zjištění incidentu; u incidentů s významným dopadem následuje další oznámení nejpozději do 72 hodin a následně závěrečná zpráva.

Od 11. září 2026 se začaly uplatňovat také samostatné oznamovací povinnosti výrobců podle čl. 14 CRA. Výrobce musí prostřednictvím jednotné platformy podle čl. 16 CRA oznámit každou aktivně zneužívanou zranitelnost obsaženou v produktu s digitálními prvky, o které se dozví, a rovněž závažný incident s dopadem na bezpečnost produktu. V obou případech se prvotní varování podává bez zbytečného odkladu, nejpozději do 24 hodin, a podrobnější oznámení nejpozději do 72 hodin. U aktivně zneužívané zranitelnosti následuje závěrečná zpráva nejpozději do 14 dnů od okamžiku, kdy je k dispozici nápravné nebo zmírňující opatření; u závažného incidentu do jednoho měsíce od podání oznámení.

Podobné lhůty však neznamenají totožný rozsah oznamovacích povinností. Významný incident podle NIS2, kybernetický bezpečnostní incident podle ZoKB a aktivně zneužívaná zranitelnost nebo závažný incident podle CRA představují samostatné právní kategorie s vlastními definičními znaky a podmínkami vzniku oznamovací povinnosti.

Pokud incident současně představuje porušení zabezpečení osobních údajů, je třeba samostatně posoudit také oznamovací povinnosti podle čl. 33 a 34 GDPR; u některých regulovaných finančních subjektů může být relevantní také DORA. Jeden kybernetický incident tak nemusí automaticky vést k několika samostatným oznámením, může však vyžadovat souběžné posouzení podle několika regulatorních režimů, často ve velmi krátkých lhůtách.

Oznamovací povinnosti podle CRA nastupují dříve než ostatní požadavky

Jednotlivé části CRA se nezačínají uplatňovat současně. Nařízení vstoupilo v platnost 10. prosince 2024 a v plném rozsahu se použije od 11. prosince 2027, některé povinnosti však nastupují dříve. Kapitola IV upravující oznamování subjektů posuzování shody se uplatňuje od 11. června 2026 a oznamovací povinnosti výrobců podle čl. 14 od 11. září 2026.

Významné je přitom přechodné ustanovení čl. 69 CRA. Produkty s digitálními prvky uvedené na trh před 11. prosincem 2027 budou hlavním produktovým požadavkům CRA zásadně podléhat až tehdy, pokud po tomto datu projdou podstatnou změnou. Oznamovací povinnosti podle čl. 14 se však vztahují i na produkty uvedené na trh dříve. Výrobci proto musí již nyní určit, které jejich produkty spadají do působnosti CRA, a nastavit proces přijímání, vyhodnocování a případného oznamování informací o zranitelnostech a incidentech.

CRA a AI Act: kdy se překrývají požadavky na bezpečnost produktů a systémů AI

Další regulatorní přesah vzniká tam, kde produkt s digitálními prvky současně využívá technologie umělé inteligence. Samotná skutečnost, že produkt obsahuje funkcionalitu využívající umělou inteligenci, však automaticky neznamená, že se na něj použijí požadavky AI Actu[4] určené pro vysoce rizikové systémy AI.

AI Act přitom nestanoví povinnosti pouze poskytovatelům systémů AI. Samostatné povinnosti mohou vznikat také organizacím, které systémy AI používají ve svých procesech jako tzv. zavádějící subjekty (deployers), zejména pokud jde o systémy AI podléhající zvláštním požadavkům podle AI Actu. Pro organizace regulované podle NIS2 může být významné zejména posouzení, jaké systémy AI využívají, k jakým účelům, jaká rizika jejich použití přináší a zda jsou nastavena odpovídající opatření pro jejich bezpečné používání.

Rozhodující je konkrétní účel použití AI systému a jeho klasifikace podle AI Actu. Umělá inteligence může být součástí produktu regulovaného podle CRA, aniž by současně šlo o vysoce rizikový systém AI podle AI Actu. Teprve pokud AI systém naplní podmínky stanovené AI Actem pro vysoce rizikový systém, vzniká potřeba koordinovat požadavky obou regulatorních režimů.

Pokud tedy produkt spadající do působnosti CRA současně naplní podmínky pro klasifikaci jako vysoce rizikový systém AI podle čl. 6 AI Actu, mohou se požadavky obou nařízení přímo překrývat.

Jedním z hlavních styčných bodů je kybernetická bezpečnost. Článek 15 AI Actu vyžaduje, aby byly vysoce rizikové systémy AI navrženy a vyvinuty tak, aby po celý svůj životní cyklus dosahovaly odpovídající úrovně přesnosti, spolehlivosti a kybernetické bezpečnosti. AI Act přitom zohledňuje také rizika specifická pro systémy AI, například útoky zaměřené na manipulaci s tréninkovými daty nebo předtrénovanými komponenty, adversariální příklady či jiné útoky využívající zranitelností samotného modelu. Kybernetická bezpečnost podle AI Actu se přitom zaměřuje nejen na obecnou ochranu systému, ale také na specifická rizika spojená s využitím umělé inteligence, zejména rizika manipulace s daty, útoků využívajících zranitelnosti modelu nebo zásahů, které mohou ovlivnit chování a výstupy systému AI.

CRA vztah obou režimů výslovně upravuje s cílem omezit duplicitní plnění kyberbezpečnostních požadavků. Podle čl. 12 odst. 1 CRA se produkt s digitálními prvky, který je současně vysoce rizikovým systémem AI, považuje za vyhovující požadavkům na kybernetickou bezpečnost podle čl. 15 AI Actu, pokud splňuje základní kyberbezpečnostní požadavky podle části I přílohy I CRA, výrobce zavedl odpovídající procesy pro řešení zranitelností podle části II přílohy I CRA a dosažení požadované úrovně kybernetické ochrany je doloženo v EU prohlášení o shodě podle CRA.

Tento mechanismus byl v roce 2026 promítnut také přímo do AI Actu. Nařízení (EU) 2026/1744 [5] doplnilo do jeho čl. 42 odstavec 3, podle kterého se vysoce rizikový systém AI spadající současně do působnosti CRA považuje při splnění podmínek čl. 12 odst. 1 CRA za vyhovující kyberbezpečnostním požadavkům čl. 15 AI Actu.

Nejde však o obecnou domněnku souladu s AI Actem. Nedotčeny zůstávají zejména požadavky týkající se přesnosti a odolnosti systému a další povinnosti vysoce rizikových systémů AI, například v oblasti řízení rizik, správy dat, technické dokumentace, vedení záznamů, transparentnosti nebo lidského dohledu.

Po změnách přijatých v roce 2026 se požadavky na vysoce rizikové systémy AI uvedené v příloze III AI Actu začnou uplatňovat od 2. prosince 2027. U vysoce rizikových systémů AI podle čl. 6 odst. 1, které jsou spojeny s produkty regulovanými harmonizačními právními předpisy uvedenými v příloze I AI Actu, se relevantní pravidla začnou uplatňovat od 2. srpna 2028. Přesto je vhodné implementaci CRA a AI Actu připravovat koordinovaně, protože v řadě případů budou oba režimy pracovat se stejným produktem, technickou dokumentací a bezpečnostními procesy.

Překryv se promítá také do posuzování shody

Propojení CRA a AI Actu není pouze materiální, ale také procesní. Článek 12 odst. 2 CRA počítá s koordinací postupů posuzování shody. U produktů s digitálními prvky, které jsou současně vysoce rizikovými systémy AI, se pro dotčené požadavky zásadně použije relevantní postup posuzování shody podle čl. 43 AI Actu. Oznámené subjekty oprávněné posuzovat shodu vysoce rizikových systémů AI mohou za stanovených podmínek posuzovat také splnění základních kyberbezpečnostních požadavků CRA.

U důležitých a kritických produktů s digitálními prvky však CRA zachovává vlastní přísnější požadavky na posuzování shody. Pokud je tedy produkt současně vysoce rizikovým systémem AI a důležitým nebo kritickým produktem podle CRA, použijí se za podmínek čl. 12 odst. 3 pro posouzení základních kyberbezpečnostních požadavků postupy stanovené CRA.

Pro výrobce z toho plyne praktická potřeba koordinovat přípravu technické dokumentace, testování a posuzování shody tak, aby bylo možné společné podklady využít napříč oběma režimy, aniž by tím byly opomenuty jejich specifické právní požadavky.

Praktický příklad:

Výrobce průmyslového zařízení může podle CRA odpovídat za bezpečnost produktu s digitálními prvky, který obsahuje AI funkcionalitu například pro optimalizaci provozu nebo prediktivní údržbu. Samotná přítomnost AI funkcionality však automaticky neznamená, že se na tento produkt použijí požadavky AI Actu pro vysoce rizikové systémy AI. Rozhodující je konkrétní účel použití AI systému a jeho klasifikace podle AI Actu.

Pokud AI systém splní podmínky vysoce rizikového systému podle AI Actu, musí výrobce koordinovat požadavky obou režimů – zejména požadavky na kybernetickou bezpečnost, řízení rizik, technickou dokumentaci a posuzování shody. Pokud nejsou splněny podmínky pro klasifikaci systému jako vysoce rizikového, zůstávají relevantní zejména požadavky CRA vztahující se k bezpečnosti produktu. Současně však může být relevantní posouzení dalších povinností podle AI Actu, například pokud organizace využívá AI systém jako zavádějící subjekt pro vlastní rozhodovací nebo provozní procesy.

Jak překryv řídit v praxi

Pokud na společnost dopadá více regulatorních režimů současně, není účelné vytvářet pro každý z nich zcela oddělený systém. Stejně tak však nelze předpokládat, že jeden obecně nastavený rámec kybernetické bezpečnosti automaticky zajistí splnění všech povinností podle CRA, NIS2, ZoKB nebo AI Actu.

Základem by proto mělo být společné regulatorní mapování. U jednotlivých produktů, služeb a systémů je vhodné určit zejména:

v jaké regulatorní roli společnost podle CRA, ZoKB/NIS2 a případně AI Actu vystupuje;
které produkty, služby, systémy a komponenty spadají do působnosti jednotlivých předpisů;
které interní a bezpečnostní procesy lze využít společně a které povinnosti naopak vyžadují samostatné plnění;
kdo odpovídá za posouzení rizik, zranitelností a incidentů;
jaké skutečnosti spouštějí jednotlivé oznamovací povinnosti a jaké lhůty se na ně vztahují;
jaké informace a součinnost je třeba zajistit od dodavatelů a dalších osob v dodavatelském řetězci.

Na toto mapování by mělo navazovat propojení interních procesů. Jeden proces řízení zranitelností může sloužit jak pro potřeby NIS2 a ZoKB, tak pro plnění povinností výrobce podle CRA. Musí však umožnit rozlišit právní význam konkrétní zranitelnosti v jednotlivých režimech a například určit, zda jde o aktivně zneužívanou zranitelnost podléhající oznámení podle CRA. Obdobně může jeden proces řešení incidentů pokrývat jejich technickou stránku, právní vyhodnocení však musí zohlednit rozdílné podmínky a lhůty podle ZoKB, CRA, GDPR nebo případně DORA.

Významnou roli bude mít také smluvní dokumentace. CRA zvyšuje význam informací, které výrobce potřebuje od svých dodavatelů, například o použitých komponentech, jejich zranitelnostech, bezpečnostních aktualizacích nebo době podpory. NIS2 a ZoKB současně vyžadují řízení bezpečnostních rizik spojených s dodavatelským řetězcem na úrovni regulované organizace. Smluvní vztahy tak představují jednu z oblastí, ve které se požadavky obou režimů v praxi výrazně propojují.

Shrnutí

Požadavky CRA a NIS2 se mohou v praxi výrazně prolínat – v rámci jedné organizace, při zajišťování bezpečnosti téhož technologického řešení, v dodavatelském řetězci i při řešení jednoho kybernetického incidentu. U produktů využívajících systémy AI může tuto regulatorní kombinaci dále rozšířit AI Act, který zároveň v některých oblastech své požadavky s CRA výslovně koordinuje, zejména pokud jde o kybernetickou bezpečnost a posuzování shody.

CRA proto nelze vnímat pouze jako další vrstvu kybernetické regulace navazující na NIS2. Jde o samostatný produktový režim s vlastními regulatorními rolemi a povinnostmi. AI Act pak představuje další regulatorní vrstvu, která se může podle okolností propojit jak s bezpečností produktu podle CRA, tak s řízením rizik na úrovni organizace podle NIS2. Praktickým úkolem pro společnosti bude využít společné technické a organizační procesy tam, kde je to možné, a současně správně rozlišit povinnosti, které jednotlivé právní režimy vyžadují plnit samostatně.