Přeskočit na obsah
← Komentář k CRA

Průvodce · jak dosáhnout souladu · revize 5. 8. 2026

Jak dosáhnout souladu s CRA

Nařízení nedává jeden seznam úkolů. Dává různé seznamy podle toho, čím v řetězci jste: výrobce nese celý čl. 13 a 14, dovozce a distributor mají povinnosti hlavně kontrolní a správce otevřeného kódu má vlastní, výrazně užší režim. Nejdřív si proto projděte zařazení, pak zvolte roli. Odškrtávejte si kroky, jak procházíte; postup zůstane uložený ve vašem prohlížeči zvlášť pro každou roli.

Zařazení, společné pro všechny

Tři otázky, které předcházejí všemu ostatnímu. Odpověď na druhou a třetí z nich rozhoduje o tom, kolik vás soulad bude stát.

  1. Rozhoduje připojení, ne obor. Podle čl. 2 odst. 1 jde o produkty, jejichž zamýšlený účel nebo rozumně předvídatelné použití zahrnuje přímé nebo nepřímé logické či fyzické datové připojení k zařízení nebo síti. Software je produktem stejně jako hardware. Zkontrolujte i vyloučení v odstavcích 2 až 8: zdravotnické prostředky, vozidla, letectví, námořní výstroj a náhradní díly.

  2. Tohle rozhodnutí stojí nejvíc peněz. Není-li produkt v příloze III ani IV, stačí interní kontrola. Je-li v příloze III, platí přísnější režim podle čl. 32 odst. 2 a 3 (odst. 2 pro třídu I, odst. 3 pro třídu II); u třídy II a u kritických produktů interní kontrola nestačí nikdy. Začněte prováděcím nařízením (EU) 2025/2392 z 28. listopadu 2025, které kategorie obou příloh technicky popisuje. Teprve co z něj nevyplyne, se dovozuje z bodu 45 odůvodnění, podle kterého rozhoduje klíčová funkce produktu, ne to, co všechno obsahuje.

  3. Role není volba. Kdo uvede produkt na trh pod svým jménem nebo ochrannou známkou, anebo produkt podstatně změní, je podle čl. 21 výrobcem, i kdyby se považoval za distributora. Totéž podle čl. 22 platí pro kohokoli dalšího, kdo provede podstatnou změnu a produkt dodá na trh.

Vyberte roli

Role není volba, plyne ze skutečnosti. Kdo uvede produkt na trh pod svým jménem nebo ho podstatně změní, je podle čl. 21 výrobcem, ať si říká jakkoli. Jedna společnost může být ve více rolích u různých produktů.

Kdo to je. Vyvíjíte nebo vyrábíte produkt a uvádíte ho na trh pod svým jménem nebo ochrannou známkou. Patří sem i ten, kdo cizí produkt přeznačí nebo podstatně změní.

Pozor. Tahle role nese nařízení celé. Porušení základních požadavků podle přílohy I a povinností podle čl. 13 a 14 spadá do nejvyššího sankčního pásma: 15 000 000 EUR nebo 2,5 % celosvětového obratu, podle toho, co je vyšší.

Než produkt půjde na trh

  1. Podle čl. 13 odst. 2 a 3 se posouzení promítá do celého životního cyklu a dokumentuje se po dobu podpory. Právě z něj se odvozuje, které požadavky přílohy I části I bodu 2 se na produkt uplatní. Nevztahuje-li se některý požadavek, musí být v dokumentaci podle odst. 4 jasné odůvodnění.

  2. Část I přílohy I ukládá vlastnosti produktu: žádné známé zneužitelné zranitelnosti, bezpečná výchozí konfigurace, možnost aktualizací, řízení přístupu, důvěrnost a integrita dat, minimalizace údajů, dostupnost, omezení prostoru k útoku, protokolování a možnost trvale smazat data. Část II ukládá postupy při řešení zranitelností.

  3. Podle přílohy I části II bodu 1 ve strojově čitelném formátu, alespoň s nejdůležitějšími závislostmi. Zveřejňovat ho nemusíte (bod 77 odůvodnění), ale existovat musí a dozor si ho může vyžádat podle přílohy VII bodu 8.

  4. Náležitá péče podle čl. 13 odst. 5: ověřte označení CE u komponent, které nařízení podléhají, historii bezpečnostních aktualizací a to, že komponenta nemá známé zranitelnosti. U cizího kódu bez přístupu k dokumentaci si přístup zajistěte smluvně, jinak nedoložíte ani soulad, ani nesplníte žádost dozoru podle čl. 53.

  5. Podle čl. 13 odst. 8 zpravidla nejméně pět let, u produktů s delší očekávanou životností déle. Informace, ke kterým jste při jejím stanovení přihlédli, patří do technické dokumentace, a měsíc a rok konce podpory musí být podle přílohy II bodu 7 znám uživateli už při koupi.

  6. Podle čl. 32 a přílohy VIII. Interní kontrola (modul A) u běžných produktů; u důležitých produktů třídy I bez použití harmonizovaných norem, u třídy II a u kritických produktů vždy s oznámeným subjektem (modul B s C, nebo modul H). Harmonizované normy zatím z velké části neexistují, takže u třídy I počítejte spíš se zapojením třetí strany.

  7. Obsah podle přílohy VII a čl. 31. Nejčastější slabinou bývají body 3 a 4, tedy posouzení rizik a odůvodnění doby podpory. Aktualizace a uchovávání jsou dvě různá pravidla: podle čl. 31 odst. 2 se dokumentace ve vhodných případech aktualizuje přinejmenším během doby podpory, podle čl. 13 odst. 13 se uchovává nejméně deset let od uvedení na trh nebo po dobu podpory, je-li delší.

  8. Prohlášení podle čl. 28 a přílohy V, v češtině pro český trh. Označení podle čl. 29 a čl. 30; u softwaru jen dvě varianty, buď na EU prohlášení o shodě, nebo na internetových stránkách doprovázejících produkt, a tam musí být příslušná část snadno a přímo přístupná spotřebitelům. Identifikační číslo oznámeného subjektu se za označením uvádí jen tehdy, byl-li subjekt zapojen do posuzování podle modulu H; u modulu B s C se neuvádí.

  9. Devět položek podle přílohy II. Nejlevnější a nejčastěji opomíjená je bod 2, tedy jednotné kontaktní místo pro oznamování zranitelností s odkazem na politiku koordinovaného zveřejňování.

Průběžně po celou dobu podpory

  1. Osm bodů přílohy I části II: dokumentovat zranitelnosti a komponenty, neprodleně je řešit, pravidelně testovat, zveřejňovat informace o opravených zranitelnostech, mít politiku koordinovaného zveřejňování, přijímat hlášení zvenčí, bezpečně distribuovat aktualizace a šířit je neprodleně a bezplatně.

  2. Je-li to technicky možné, podle přílohy I části II bodu 2. Cílem je, aby uživatel nemusel přijmout nechtěnou změnu funkcí jen proto, že chce opravu. Prakticky to znamená oddělené větve vydání, tedy zásah do vývojového procesu, ne do dokumentace.

  3. Podstatná změna podle čl. 3 bodu 30 spouští nové posouzení shody. Běžná bezpečnostní aktualizace jí není; nová funkce, která rozšiřuje prostor k útoku, jí být může. Zaveďte si rozhodovací krok ve vývoji, ať se na to nepřijde až při kontrole.

Když se něco stane

  1. Podle čl. 14: včasné varování do 24 hodin od zjištění, oznámení do 72 hodin, a závěrečná zpráva. U aktivně zneužívané zranitelnosti do 14 dnů od okamžiku, kdy začalo být k dispozici nápravné nebo zmírňující opatření; u závažného incidentu do jednoho měsíce od oznámení podle písmene b). Adresátem je CSIRT určený jako koordinátor a agentura ENISA přes jednotnou platformu podle čl. 16. Tohle je nejdřív dopadající povinnost celého nařízení, běží už od 11. září 2026.

  2. Vedle oznámení orgánům ukládá čl. 14 informovat dotčené uživatele o incidentu a o nápravných opatřeních. Text a kanál si připravte předem; v průběhu incidentu na formulace není čas a nesoulad mezi tím, co jste řekli orgánu a uživatelům, se špatně vysvětluje.

Co za vás tenhle seznam nerozhodne

  • Do které kategorie produkt patří. Od 28. listopadu 2025 k tomu existuje prováděcí nařízení (EU) 2025/2392 s technickým popisem kategorií přílohy III i IV, takže se začíná tam. Hraniční případy ale pořád rozhoduje klíčová funkce produktu, a to je úsudek nad jeho architekturou.
  • Co je u vás podstatná změna. Definice v čl. 3 bodu 30 je obecná a bod 39 odůvodnění k ní dává příklady, ale hranici mezi rozšířením funkce a pouhou opravou určuje povaha vašeho produktu.
  • Jaký rozsah opatření je přiměřený. Požadavky přílohy I části I bodu 2 se uplatní „v příslušných případech" na základě posouzení rizik. Vypustit požadavek lze, ale jen s jasným odůvodněním v dokumentaci.
  • Jestli na vás sahá i jiný předpis. Provozujete-li navíc službu, řešíte souběžně NIS2 a zákon č. 264/2025 Sb. Je-li produkt vysoce rizikovým systémem umělé inteligence, přidává se AI Act, byť s mostem podle čl. 12.

Souvislosti a přesné znění drží komentář k CRA po článcích, časovou osu a sankční pásma přehledová karta. Není to právní služba ani posouzení konkrétního produktu. Jak k obsahu přistupuji a co si ověřit, popisuje metodika.

Jak vzniká obsah

Obsah vzniká v právním workflow Legal To Code pro Claude Code (verze 1.131.0). Citovaná ustanovení se ověřují proti lokální knihovně jejich verbatim znění. Není-li příslušné znění v knihovně, ověřuje se v e‑Sbírce. Pro rešerši judikatury je workflow napojeno na MCP server Salvia. Součástí workflow jsou automatizované kontroly citací a vnitřní konzistence. Ani tyto kontroly nevylučují chybu. Rozhodné informace proto ověřujte v původních pramenech.

Podrobně v metodice · Co se změnilo