Bezpečnostní spis produktu podle CRA 2026 s ISO 27001

Výrobce připojených zařízení svolá svou ředitelku informační bezpečnosti (CISO) Marii na páteční odpolední schůzku. Obchodní tým právě zajistil evropskou distribuční smlouvu. Právní oddělení se ptá, zda společnost dokáže podpořit prokazování shody podle Cyber Resilience Act. Vývoj uvádí, že bezpečný vývoj je „z velké části pokrytý“, protože existuje přezkum kódu, SAST a záplatování. Oddělení nákupu tvrdí, že dodavatelé jsou „pod NDA“. Produktové týmy mají závislosti firmwaru v jednom nástroji, evidenci cloudových API v jiném a tikety ke zranitelnostem v Jira. Tým pro soulad má certifikační důkazy ISO/IEC 27001:2022, ale jsou uspořádány kolem podnikového ISMS, nikoli kolem jednotlivých produktů uváděných na trh EU.

Pak přijde nepříjemná otázka: „Pokud si orgán EU, zákazník, oznámený subjekt nebo významný distributor v roce 2026 vyžádá bezpečnostní spis produktu, dokážeme jej dodat do jednoho týdne?“

U mnoha dodavatelů softwaru, výrobců chytrých zařízení a poskytovatelů připojených služeb je upřímná odpověď ne. Ne proto, že by neměli bezpečnostní opatření, ale proto, že jejich důkazy o produktové bezpečnosti jsou roztříštěné. Záznamy o bezpečném vývoji má vývojový tým. SBOM se generují pro jednotlivé buildy, ale nejsou řízeny. Koordinované oznamování zranitelností existuje jako webová stránka, ale není vždy propojeno s triáží, opravami, bezpečnostními oznámeními a monitorováním po uvedení na trh. Bezpečnost dodavatelů je ukryta ve smluvní dokumentaci nákupu. Hlášení incidentů spadá do bezpečnostního provozu, zatímco dokumentace shody patří do oblasti produktového souladu.

Cyber Resilience Act mění provozní model. Kybernetická bezpečnost produktů již není jen osvědčeným postupem nebo smluvním příslibem. Stává se povinností průběžně prokazovat důkazy v celém životním cyklu. Organizace musí být schopny ukázat, jak jsou požadavky kybernetické bezpečnosti zabudovány do návrhu, vývoje, vydání, zvládání zranitelností, aktualizací a monitorování po uvedení produktu na trh.

Právě zde se ISO/IEC 27001:2022 stává silným nástrojem, pokud je použita správně. Sama o sobě není schématem produktové certifikace, ale její ISMS, řízení rizik, správa aktiv, řízení dodavatelů, bezpečný vývoj, řízení zranitelností a incidentní opatření mohou tvořit páteř bezpečnostního spisu produktu podle CRA. Cílem není vytvořit další silo souladu. Cílem je převést stávající ISMS na systém důkazů na úrovni produktu.

Jak uvádí Clarysec Zenith Blueprint: 30krokový plán auditora ve fázi 2, kroku 8, Architektura důkazů:

„Důkazy by se neměly shromažďovat až na konci auditního cyklu. Měly by být navrženy přímo do opatření, přiřazeny vlastníkovi, opatřeny časovým razítkem procesem a opakovaně použitelné napříč každou povinností, která klade stejnou otázku jinými slovy.“

Tato věta vystihuje jádro připravenosti na CRA. Otázka nezní jen: „Máme bezpečný vývoj?“ Otázka zní: „Dokážeme prokázat bezpečný vývoj, znalost komponent, zvládání zranitelností a monitorování po uvedení na trh pro tento produkt, tuto verzi, toto vydání a tento trh?“

Bezpečnostní spis produktu podle CRA je živý systém důkazů

Bezpečnostní spis produktu podle CRA by neměl být považován za statický dokument PDF vytvořený jednou před vydáním a následně odložený. Má jít o strukturovanou dokumentaci, která popisuje bezpečnostní příběh produktu od konceptu až po ukončení podpory.

Užitečný spis vysvětluje:

1. Co produkt je a k jakému zamýšlenému použití slouží.
2. Jaký software, firmware, cloudové služby a závislosti na třetích stranách obsahuje.
3. Jaká kybernetická rizika byla posouzena.
4. Jaké bezpečnostní požadavky byly uplatněny.
5. Jak byl proveden bezpečný vývoj.
6. Jak jsou zranitelnosti přijímány, tříděny, opravovány a oznamovány.
7. Jak jsou doručovány bezpečné aktualizace.
8. Jak jsou řízeni dodavatelé a open-source komponenty.
9. Jak jsou eskalovány incidenty a aktivně zneužívané zranitelnosti.
10. Jak je produkt monitorován po uvedení na trh.

Pro CISO jde o výzvu v oblasti důkazů ISMS. Pro manažera produktového souladu jde o technickou dokumentaci. Pro vývoj jde o DevSecOps a řízení vydání. Pro vrcholové vedení jde o přístup na trh a kontrolu odpovědnosti.

Chybou je zacházet s těmito oblastmi jako s oddělenými pracovními proudy. Lepším modelem je vytvořit důkazní spis na úrovni produktu, který se mapuje na opatření ISO/IEC 27001:2022 a ISO/IEC 27002:2022, a následně tytéž důkazy křížově mapovat na NIS2, DORA, GDPR, NIST a COBIT 2019 tam, kde je to relevantní.

Clarysec Zenith Controls: Průvodce souladem napříč regulacemi to popisuje jako řetězec opatření–důkaz–auditor:

„Důkazní spis pro soulad napříč předpisy by měl mapovat každou povinnost na provozní opatření, opakovaně používaný důkazní objekt, odpovědného vlastníka a auditní perspektivu, kterou bude zpochybňován.“

Právě tuto disciplínu příprava na CRA vyžaduje. Bezpečnostní spis produktu není pouhou složkou. Je to překladová vrstva mezi produktovým vývojem, správou a řízením bezpečnosti, posuzováním shody a ujištěním zákazníků.

Nejprve vybudujte páteř produktových důkazů

Spis potřebuje konzistentní strukturu dříve, než týmy začnou nahrávat záznamy. Bez jasné páteře se důkazy změní v hromadu snímků obrazovky, exportů a PDF politik, ve které se žádný auditor nevyzná.

Pro workshopy připravenosti na CRA Clarysec obvykle doporučuje následující strukturu bezpečnostního spisu produktu pro organizace, které již provozují ISMS podle ISO/IEC 27001:2022.

Tato tabulka nenahrazuje právní povinnosti technické dokumentace. Poskytuje organizaci provozní model pro jejich prokazování.

V Zenith Blueprint se fáze 1, krok 3 zaměřuje na vymezení rozsahu a hranic. Pro CRA se tento krok stává produktově specifickým. Definujte produktovou rodinu, verze softwaru, předpoklady nasazení, uživatelské role, připojené služby, aktualizační kanály a období podpory. Pokud je rozsah ISMS „podniková SaaS a platforma pro správu zařízení“, spis CRA musí stále odpovědět na užší otázku: „Který produkt s digitálními prvky je uváděn na trh EU a co je do tohoto produktu zahrnuto?“

Mapujte bezpečný vývoj na záznamy na úrovni produktu

Jádrem bezpečnostního spisu produktu jsou důkazy o bezpečnosti již od návrhu. ISO/IEC 27001:2022 poskytuje systém správy a řízení. ISO/IEC 27002:2022 poskytuje implementační vodítka prostřednictvím opatření, jako jsou A.8.25 životní cyklus bezpečného vývoje, A.8.27 bezpečná architektura systému a inženýrské zásady, A.8.28 bezpečné kódování a A.8.29 bezpečnostní testování ve vývoji a akceptaci.

Důležitý posun spočívá v přechodu od obecných tvrzení o bezpečném vývoji k záznamům specifickým pro vydání. „Provádíme přezkum kódu“ nestačí. Spis má ukázat, které vydání bylo přezkoumáno, jaká rizika byla zvažována, které bezpečnostní testy prošly, které zranitelnosti byly akceptovány nebo napraveny a kdo vydání schválil.

Podniková Politika bezpečného vývoje společnosti Clarysec je navržena tak, aby tuto důkazní stopu vynutila. V kapitole 6.1, Požadavky životního cyklu bezpečného vývoje, uvádí:

„Každé vydání produktu nebo služby musí před nasazením do produkčního prostředí udržovat dokumentované důkazy o bezpečnostních požadavcích, přezkumu návrhu, činnostech bezpečného kódování, bezpečnostním testování, rozhodnutích o nápravě zranitelností a schválení vydání.“

Tato kapitola je pro CRA užitečná, protože převádí bezpečný vývoj na opakovatelný důkazní vzor. Auditor nemusí dovozovat, že bezpečný vývoj proběhl. Může zkontrolovat záznam o vydání.

U chytrého termostatu, zdravotnického IoT zařízení, průmyslového senzoru nebo produktu připojeného k SaaS by důkazy bezpečného vývoje měly zahrnovat:

• Bezpečnostní požadavky produktu namapované na identifikovaná rizika.
• Model hrozeb nebo analýzu scénářů zneužití pro produkt a připojené služby.
• Přezkum architektury včetně hranic důvěry a externích rozhraní.
• Standard bezpečného kódování a důkaz o potvrzení seznámení nebo školení vývojářů.
• SAST, DAST, analýzu složení softwaru, skenování tajemství a analýzu firmwaru tam, kde je to použitelné.
• Nápravné tikety pro vysoce riziková zjištění.
• Záznamy o akceptaci rizika se schválením ze strany obchodního vlastníka a bezpečnosti.
• Kontrolní seznam schvalovací brány vydání prokazující splnění bezpečnostních kritérií.
• Důkazy o kryptografickém podepisování a integritě aktualizací.
• Předpoklady období podpory a ukončení životního cyklu.

Metodu pomáhají posílit i další normy. ISO/IEC 27005 podporuje rizikový přístup stojící za těmito záznamy. ISO/IEC 27017 je užitečná tam, kde jsou cloudové služby součástí produktového ekosystému. ISO/IEC 27035 podporuje zvládání incidentů. ISO/IEC 29147 a ISO/IEC 30111 jsou zvlášť relevantní pro oznamování zranitelností a zvládání zranitelností. ISO/IEC 27036 podporuje bezpečnost dodavatelů, což je důležité, pokud produkt obsahuje outsourcovaný software, vestavěné moduly, řízené cloudové služby nebo knihovny třetích stran.

V Zenith Controls jsou důkazy bezpečného vývoje pro CRA obvykle mapovány kolem témat opatření ISO/IEC 27002:2022, jako je bezpečnost informací v projektovém řízení, životní cyklus bezpečného vývoje, bezpečné kódování, bezpečnostní testování, řízení změn a řízení technických zranitelností. Průvodce je také propojuje s evidencí aktiv a dodavatelskými kontrolami, protože žádný proces bezpečného vývoje není úplný, pokud organizace nedokáže identifikovat komponenty, které dodává.

Zacházejte se SBOM jako s regulovaným produktovým důkazem

Softwarový kusovník (Software Bill of Materials, SBOM) je často považován za technický artefakt. Pro připravenost na CRA by měl být považován za produktový důkaz.

Užitečný SBOM sděluje, jaké komponenty jsou v produktu, jaké verze se používají, odkud pocházejí, jaké licence se na ně vztahují, jaké zranitelnosti je ovlivňují a ve kterých vydáních jsou obsaženy. U firmwaru a vestavěných produktů to může zahrnovat balíčky operačního systému, bootloadery, knihovny, ovladače, kontejnery, moduly třetích stran a cloudové závislosti potřebné pro provoz produktu.

Problém je, že mnoho organizací SBOM generuje, ale neřídí je. Build pipeline může vytvořit soubor SPDX nebo CycloneDX, ale nikdo neověřuje úplnost. Bezpečnostní nástroje mohou označit zranitelnosti, ale výsledky nejsou navázány na verze produktu. Nákup může schválit dodavatele, ale seznam komponent daného dodavatele není sladěn s vydaným produktem.

Podniková Politika správy aktiv společnosti Clarysec řeší tuto mezeru ve správě v kapitole 5.2, Evidence informací a souvisejících aktiv:

„Informační aktiva a související technologické komponenty musí být identifikovány, musí jim být přiřazen vlastník, musí být klasifikovány tam, kde je to použitelné, a udržovány v evidenci, která podporuje posouzení rizik, řízení zranitelností, řízení změn a auditní důkazy.“

Pro CRA se tato kapitola stává produktově specifickou. SBOM je součástí evidence souvisejících technologických komponent. Potřebuje vlastníka, pravidlo uchovávání, proces ověření a vazbu na řízení zranitelností.

Praktické pravidlo pro důkazy SBOM je jednoduché: každá vydaná verze produktu musí mít schválenou evidenci komponent, kterou lze spárovat s artefaktem vydání. Pokud organizace nedokáže propojit SBOM s přesným obrazem firmwaru, aplikačním balíčkem, digestem kontejneru nebo vydáním SaaS, je SBOM slabým důkazem.

Pokud selžou více než dva řádky, problém obvykle není v nástroji SBOM. Problémem je správa a řízení. Bezpečnostní spis produktu by měl zaznamenat nápravné opatření v ISMS, protože slabina důkazů CRA je zároveň problémem účinnosti opatření podle ISO/IEC 27001:2022.

Propojte CVD se zvládáním zranitelností a řízením vydání

Koordinované oznamování zranitelností patří mezi nejviditelnější oblasti připravenosti na CRA, protože externí výzkumníci, zákazníci a orgány jej mohou přímo otestovat. Zveřejnění stránky pro oznamování zranitelností nebo souboru security.txt je užitečné, ale je to pouze vstupní brána. Bezpečnostní spis produktu musí prokázat, že navazující procesy skutečně fungují.

Obhajitelný soubor důkazů CVD a zvládání zranitelností by měl zahrnovat:

• Veřejný kanál pro oznámení a pokyny pro podání.
• Proces potvrzení přijetí pro výzkumníky.
• Kritéria triáže včetně posouzení závažnosti a zneužitelnosti.
• Analýzu dopadu na produkt.
• Vlastnictví nápravy a cílové lhůty.
• Šablony zákaznických oznámení a komunikace k aktualizacím.
• Důkazy o bezpečném vývoji a testování záplat.
• Záznamy o koordinovaném zveřejnění tam, kde je to použitelné.
• Získané poznatky a analýzu opakujících se trendů zranitelností.

Podniková Politika řízení zranitelností a záplat společnosti Clarysec v kapitole 6.3, Příjem, triáž a náprava zranitelností, uvádí:

„Nahlášené zranitelnosti musí být protokolovány, posouzeny z hlediska dotčených aktiv a produktů, prioritizovány podle rizika a zneužitelnosti, přiřazeny odpovědnému vlastníkovi a sledovány přes nápravu, ověření, komunikaci a uzavření.“

Tato kapitola propojuje CVD se SBOM, evidencí aktiv, vývojovými tikety, řízením vydání a monitorováním po uvedení na trh. Je to také kapitola, kterou budou auditoři přirozeně testovat: ukažte záznam o příjmu, ukažte dotčené produkty, ukažte triáž, ukažte opravu, ukažte komunikaci se zákazníkem, ukažte uzavření.

Vaše stávající Politika řízení incidentů informační bezpečnosti by měla být také rozšířena tak, aby pokrývala produktové zranitelnosti, které se stanou incidenty nebo vyžadují externí oznámení. ISO/IEC 27002:2022 A.5.24 pokrývá plánování a přípravu řízení incidentů, A.5.25 pokrývá posouzení a rozhodnutí o událostech informační bezpečnosti, A.5.26 pokrývá reakci na incidenty informační bezpečnosti a A.5.27 pokrývá poučení z incidentů.

V Zenith Controls je řízení zranitelností chápáno jako preventivní i nápravné. Preventivní stránka zahrnuje evidenci aktiv, bezpečný vývoj, monitorování dodavatelů a bezpečnou konfiguraci. Nápravná stránka zahrnuje detekci, triáž, záplatování, komunikaci a eskalaci incidentů. Toto rozlišení je důležité, protože zvládání zranitelností po uvedení produktu na trh je součástí povinnosti v životním cyklu produktu, nikoli dodatečnou aktivitou.

Dodavatelské důkazy jsou skrytou slabinou

Bezpečnostní spis produktu bude často nejpřísněji prověřován tam, kde výrobce spoléhá na jiné subjekty. Patří sem vestavěné moduly, outsourcovaný vývoj firmwaru, white-label komponenty, cloud hosting, mobilní SDK, platební služby, kryptografické knihovny a poskytovatelé řízené podpory.

Běžným vzorcem selhání je smluvní abstrakce. Výrobce říká: „Za to odpovídá náš dodavatel.“ Při prověřování produktové bezpečnosti to nestačí. Organizace musí ukázat, že dodavatelské riziko je identifikováno, bezpečnostní požadavky jsou komunikovány, důkazy jsou shromažďovány, zranitelnosti jsou koordinovány a změny jsou řízeny.

Podniková Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran společnosti Clarysec v kapitole 7.1, Bezpečnostní požadavky na dodavatele, uvádí:

„Dodavatelé, kteří vyvíjejí, provozují, zpracovávají, podporují nebo podstatně ovlivňují informační systémy, produkty nebo služby, musí být posuzováni podle rizika a musí podléhat bezpečnostním požadavkům zahrnujícím přístup, řízení zranitelností, oznamování incidentů, subdodávky, kontinuitu a poskytování důkazů.“

Pro CRA je klíčová formulace „podstatně ovlivňují produkty“. Pokud dodavatelská komponenta může zavést zranitelnost, narušit aktualizace, zpřístupnit zákaznická data nebo ohrozit integritu zařízení, patří do bezpečnostního spisu produktu.

Tatáž politika může podpořit také smluvní požadavky na SBOM. Kapitola 7.3 uvádí:

„U všech softwarových komponent, knihoven nebo operačních systémů třetích stran, které mají být integrovány do firemních ‚Produktů s digitálními prvky‘, musí dodavatel na vyžádání poskytnout strojově čitelný Software Bill of Materials (SBOM) ve standardním formátu, jako je SPDX nebo CycloneDX. Tento požadavek musí být zapracován do všech smluv o pořizování a dodavatelských smluv.“

Silný balíček dodavatelských důkazů by měl zahrnovat klasifikaci dodavatelů podle dopadu na produkt, bezpečnostní požadavky ve smlouvách, dodavatelské důkazy bezpečného vývoje u kritických komponent, závazky dodavatelů k oznamování zranitelností, SBOM nebo prohlášení ke komponentám tam, kde je to proveditelné, podporu záplat a termíny ukončení životního cyklu, záznamy o pravidelných přezkumech a eskalační cesty pro zranitelnosti pocházející od dodavatele.

ISO/IEC 27002:2022 A.5.19, A.5.20 a A.5.21 poskytují klíčová témata dodavatelských opatření. ISO/IEC 27036 přidává hloubku pro bezpečnost dodavatelských vztahů. Z pohledu souladu napříč předpisy NIS2 zdůrazňuje dodavatelský řetězec a zvládání zranitelností. DORA zdůrazňuje rizika ICT třetích stran pro finanční subjekty. GDPR je relevantní, pokud produkt nebo jeho cloudové služby zpracovávají osobní údaje. COBIT 2019 rámuje správu dodavatelů jako otázku správy a řízení podnikových technologií, nikoli pouze jako otázku bezpečnostního provozu.

Monitorování po uvedení na trh mění důkazy v provoz

Nejvyspělejší organizace v oblasti produktové bezpečnosti přemýšlejí za hranicí vydání. Ptají se: „Jak zjistíme, že se tento produkt po nasazení v terénu stal rizikovým?“

Monitorování po uvedení na trh by mělo zachytávat signály ze zdrojů informací o zranitelnostech, informací o exploitech, zákaznické podpory, telemetrie, programů bug bounty nebo hlášení výzkumníků, oznámení dodavatelů, cloudových logů, záznamů incidentů a provozních dat z terénu. Mělo by zahrnovat také pravidelný přezkum produktového rizika při změně podmínek hrozeb.

Podniková Politika protokolování a monitorování společnosti Clarysec v kapitole 5.4, Bezpečnostní monitorování a přezkum, uvádí:

„Bezpečnostně relevantní události musí být shromažďovány, přezkoumávány, eskalovány a uchovávány způsobem, který podporuje včasnou detekci, vyšetřování, reakci na incidenty, regulační oznámení a neustálé zlepšování.“

U připojených produktů musí být toto vykládáno opatrně. Monitorování musí respektovat soukromí, minimalizaci dat a právní omezení, zejména pokud telemetrie zahrnuje osobní údaje nebo provozní data zákazníků. Mapování na GDPR je důležité. Týmy produktové bezpečnosti by měly spolupracovat s týmy ochrany soukromí na definici toho, jaká telemetrie je pro bezpečnost nezbytná, jak je minimalizována, jak dlouho je uchovávána a jak jsou zákazníci informováni.

Důkazy monitorování po uvedení na trh by měly zahrnovat plán monitorování produktové bezpečnosti, zdroje informací o zranitelnostech, vstupní kanály pro zákaznická hlášení, kanály oznámení dodavatelů, rozsah přezkumu telemetrie nebo logů, zápisy z pravidelných přezkumů produktového rizika, sledování přijetí záplat, analýzu trendů incidentů a vstupy do přezkoumání vedením.

V Zenith Blueprint se fáze 5, krok 30 zaměřuje na neustálé zlepšování a připravenost na dozor. Pro CRA je to místo, kde se bezpečnostní spis produktu stává živým spisem. Každé vydání produktu, zranitelnost, dodavatelská změna a signál z terénu by měly aktualizovat důkazní záznam.

Jeden důkazní spis, mnoho otázek souladu

Dobře navržený bezpečnostní spis produktu podle CRA snižuje duplicitu, protože stejné důkazy odpovídají na více otázek souladu. Jazyk se mění, ale realita opatření je často podobná.

Zenith Controls je navržen pro toto opakované využití. Mapuje témata opatření ISO/IEC 27002:2022 na atributy, jako je preventivní, detekční a nápravný účel opatření, koncepty kybernetické bezpečnosti, provozní schopnosti a bezpečnostní vlastnosti. Pro CRA to pomáhá CISO vysvětlit, proč jeden důkazní objekt, například bezpečnostní přezkum vydání, podporuje bezpečný vývoj, ošetření rizik, řízení změn, řízení zranitelností a připravenost na audit.

Připravte se na různé auditorské perspektivy

Bezpečnostní spis produktu podle CRA může být zpochybněn ISO auditorem, týmem interního auditu, týmem zákaznického ujištění, posuzovatelem produktové shody, regulačním orgánem, hodnotitelem vycházejícím z NIST nebo auditorem COBIT školeným v ISACA. Každý položí podobné otázky jinou optikou.

Stejné slabé místo bude odhaleno různě. Pokud se SBOM generují, ale neuchovávají, ISO auditor vidí problém řízení záznamů a provozních opatření. Hodnotitel NIST vidí slabinu správy aktiv a řízení zranitelností. Auditor COBIT vidí slabou správu informačních aktiv. Posuzovatel produktu vidí nedostatečnou technickou dokumentaci.

30krokový plán přizpůsobený připravenosti na CRA

Zenith Blueprint brání týmům pro soulad v tom, aby skočily rovnou do sběru dokumentů. Pro CRA se 30krokový plán mění v program důkazů produktové bezpečnosti.

Fáze 1 začíná mapováním povinností a rozsahu. Identifikujte, které produkty, verze, komponenty, cloudové služby a procesy podpory jsou v rozsahu. Potvrďte zamýšlené použití, kategorie uživatelů, trhy a období bezpečnostní podpory.

Fáze 2 buduje architekturu důkazů. Definujte index bezpečnostního spisu produktu, vlastníky důkazů, požadavky na uchovávání, strukturu repozitáře a schvalovací pracovní postup. Slaďte jej s vývojovými systémy namísto vynucování ručního nahrávání.

Fáze 3 implementuje provozní opatření. Bezpečný vývoj, generování SBOM, zvládání zranitelností, dodavatelské důkazy, schvalovací brány vydání, bezpečné aktualizace a eskalace incidentů musí fungovat jako skutečné procesy.

Fáze 4 testuje připravenost na audit. Vyberte vydání produktu a proveďte simulovaný audit. Dokáže tým získat SBOM? Dokáže prokázat bezpečnostní testování? Dokáže ukázat, jak byla zranitelnost tříděna? Dokáže propojit dodavatelské důkazy s produktovými komponentami?

Fáze 5 zabudovává dohled a zlepšování. Monitorování po uvedení na trh, analýza trendů zranitelností, přezkumy dodavatelů a vstupy do přezkoumání vedením udržují spis aktuální.

Tento sprint obvykle rychle odhalí skutečný stav. Organizace málokdy selhávají proto, že by neměly žádná opatření. Selhávají proto, že opatření nejsou propojena na úrovni produktu.

Běžné mezery v připravenosti na CRA před rokem 2026

U dodavatelů softwaru, výrobců zařízení a poskytovatelů připojených služeb se opakují konzistentní mezery.

Za prvé, rozsah ISMS je příliš podnikový. Pokrývá organizaci, ale ne dostatečný detail životního cyklu produktu. Nápravou je vytvoření produktových příloh a důkazních spisů.

Za druhé, SBOM existují, ale nejsou důvěryhodné. Jsou generovány nástroji, ale nejsou přezkoumávány, schvalovány, uchovávány ani propojeny s rozhodnutími o zranitelnostech. Nápravou je správa SBOM, nikoli pouze produkce SBOM.

Za třetí, CVD je veřejně dostupné, ale provozně nevyzrálé. Hlášení přicházejí, ale kritéria triáže, cíle reakce, schvalování bezpečnostních oznámení a důkazy uzavření jsou nekonzistentní. Nápravou je integrace CVD s řízením zranitelností, řízením incidentů a řízením vydání.

Za čtvrté, dodavatelské důkazy jsou příliš povrchní. Kritičtí dodavatelé jsou schváleni obchodně, ale nejsou posouzeni z hlediska dopadu na produktovou bezpečnost. Nápravou je klasifikace dodavatelů podle produktového rizika a povinné důkazy pro kritické komponenty.

Za páté, monitorování po uvedení na trh je reaktivní. Týmy reagují na urgentní zranitelnosti, ale neprovádějí pravidelné přezkumy produktového rizika. Nápravou je plánovaný bezpečnostní přezkum po uvedení produktu na trh provázaný s reportováním vedení.

Za šesté, auditní důkazy jsou příliš manuální. Týmy pro soulad nahánějí snímky obrazovky. Nápravou jsou důkazy navržené přímo do procesu, tedy využití vývojových systémů, ticketovacích pracovních postupů a repozitářů jako autoritativních zdrojů.

Vybudujte důkazní spis dříve, než vám ho vybuduje termín

Cyber Resilience Act odměňuje organizace, které dokážou prokázat produktovou bezpečnost jako provozní disciplínu. Vytváří riziko pro organizace, které považují důkazy za cvičení souladu na poslední chvíli.

Začněte jedním produktem. Vytvořte jeden bezpečnostní spis produktu. Namapujte jej na ISO/IEC 27001:2022 a ISO/IEC 27002:2022. Připojte důkazy bezpečného vývoje, SBOM, záznamy CVD, dodavatelské ujištění a monitorování po uvedení na trh. Proveďte auditní simulaci dříve, než ji za vás provede někdo externí.

Clarysec vám může tuto cestu urychlit pomocí Zenith Blueprint, Zenith Controls, podnikové Politiky bezpečného vývoje, Politiky řízení zranitelností a záplat, Politiky správy aktiv, Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran, Politiky protokolování a monitorování a Politiky řízení incidentů informační bezpečnosti.

Vaše nejdůležitější otázka k CRA 2026 nezní: „Máme bezpečnostní opatření?“

Zní: „Dokážeme prokázat produktovou bezpečnost po jednotlivých vydáních, komponentách a zranitelnostech i poté, co je produkt již na trhu?“

Vybudujte důkazní spis nyní, propojte jej se svým ISMS a zajistěte, aby každé budoucí vydání produktu bylo připravené na audit již od návrhu.