2. díl

Zranitelnost chytrého zámku může během několika hodin spustit povinnosti podle dvou evropských nařízení. Cyber Resilience Act (CRA) řeší bezpečnost produktu, GDPR ochranu osobních údajů jeho uživatelů. Výrobce přitom musí sladit hlášení incidentu, práci s bezpečnostními záznamy i komunikaci s dotčenými osobami. Na konkrétním příkladu ukážeme, kde se požadavky obou předpisů doplňují, kde vzniká napětí a jak je propojit do jednoho funkčního postupu.

Modelový případ: jeden incident, dvě sady povinností

Představme si výrobce chytrého zámku s mobilní aplikací. V pátek večer bezpečnostní výzkumník nahlásí aktivně zneužívanou zranitelnost, která umožňuje vzdálený přístup k účtům, a tím i k údajům o pohybu uživatelů. Do 24 hodin odesílá výrobce podle CRA včasné varování příslušnému CSIRT a agentuře ENISA. Souběžně datový tým vyhodnocuje, zda došlo k porušení zabezpečení osobních údajů s vysokým rizikem – a protože jde o citlivé údaje o zvyklostech uživatelů, dochází k závěru, že ano. Nejpozději do 72 hodin proto míří ohlášení také Úřadu pro ochranu osobních údajů a připravuje se srozumitelné vyrozumění dotčených uživatelů. Do 14 dnů výrobce dokončuje závěrečnou zprávu podle CRA, jakmile je k dispozici oprava.

Na tomto příkladu je vidět, proč koordinace rozhoduje. Kdyby oba týmy pracovaly odděleně, hrozí tři typické chyby: rozdílný popis téže události ve dvou hlášeních, zmeškání jedné z lhůt kvůli čekání na druhý tým a rozporná komunikace navenek. Jeden sdílený rozhodovací strom se dvěma výstupy tato rizika prakticky odstraní.

Jediný incident může spustit oznamovací povinnosti podle CRA i GDPR. Bez společného postupu hrozí rozdílná hlášení i zmeškané lhůty.

Kde se požadavky CRA a GDPR dostávají do napětí

Prolínání dvou norem nepřináší jen synergii. Na několika místech vzniká skutečné napětí, které je třeba vědomě vyřešit – ideálně už ve fázi návrhu, ne až při auditu.

2.1. Logování a monitorování versus minimalizace údajů

CRA požaduje zaznamenávání a monitorování relevantních bezpečnostních událostí. GDPR naopak žádá minimalizaci a účelové omezení. Logy přitom typicky obsahují osobní údaje – IP adresy, identifikátory uživatelů, časy přístupů. Napětí je zjevné, řešení však existuje: bezpečnostní logování má legitimní účel (a tedy i právní základ), musí být ale navrženo s ohledem na minimalizaci – s jasnou dobou uchování, řízeným přístupem a případně pseudonymizací. Užitečné je, že minimalizaci údajů vyžaduje i samotná příloha I CRA; obě normy tedy táhnou za jeden provaz, jen je třeba obě zohlednit najednou.

2.2. Automatické aktualizace, telemetrie a právní základ

CRA tlačí na automatické bezpečnostní aktualizace a na sledování zranitelností, k čemuž se často využívá telemetrie z produktu. Pokud tato telemetrie obsahuje osobní údaje, vstupuje do hry GDPR: je třeba stanovit právní základ, být transparentní vůči uživatelům a poskytnout jim informace podle článku 13. Bezpečnostní přínos automatického updatu tedy musí jít ruku v ruce s transparentností a s promyšleným zpracováním dat, která se přitom přenášejí.

2.3. Uchovávání důkazů versus omezení uložení

CRA vyžaduje uchovávat technickou dokumentaci deset let. To samo o sobě není konflikt – technická dokumentace zpravidla není osobním údajem. Pozor ale na hraniční materiály: záznamy o incidentech, logy a důkazy shromážděné při řešení zranitelnosti mohou osobní údaje obsahovat, a tam už platí zásada omezení uložení podle GDPR. Řešením je oddělit dokumentaci produktu (uchovávanou dlouhodobě) od osobních údajů v provozních a incidentních záznamech (uchovávaných jen po nezbytnou dobu).

2.4. Řešení pro dálkové zpracování dat jako zpracování podle GDPR

Definice produktu s digitálními prvky v CRA zahrnuje i „řešení pro dálkové zpracování dat“ – tedy cloudové a backendové komponenty navržené výrobcem, bez nichž by produkt neplnil své funkce. Taková komponenta je tedy součástí produktu podle CRA a operací zpracování podle GDPR. Jeden a týž prvek architektury tak spadá pod obě normy najednou, což je další důvod, proč je nelze posuzovat odděleně.

2.5. Dodavatelský řetězec a třetí strany

CRA požaduje náležitou péči o komponenty třetích stran a přehled o nich v podobě SBOM. GDPR požaduje smluvní ošetření zpracovatelů a subzpracovatelů (článek 28) a prověření jejich záruk. Jde o tutéž disciplínu z různých úhlů: vědět, z čeho se váš produkt skládá a komu svěřujete data. Kdo umí spravovat SBOM, má nakročeno i k pořádku v evidenci zpracovatelů – a naopak.

2.6. Mezinárodní předávání a umístění dat

Řešení pro dálkové zpracování dat, která jsou součástí produktu, často běží v cloudu mimo Evropskou unii. Tím se do hry dostávají pravidla GDPR o předávání osobních údajů do třetích zemí. CRA sice místo zpracování přímo neřeší, ale tím, že cloudovou komponentu považuje za součást produktu, nepřímo nutí výrobce, aby o toku dat přemýšlel od začátku. Sladění bezpečnostní architektury s pravidly předávání je proto další oblastí, kterou je lepší vyřešit ve fázi návrhu než při pozdějším auditu.

2.7. Když se zájmy skutečně střetnou

Ve výjimečných situacích může jít bezpečnost a ochrana údajů proti sobě – například když forenzní analýza incidentu vyžaduje dočasně uchovat více dat, než by běžný účel dovolil. I tehdy existuje řešení: zdokumentovat vážení zájmů, opřít se o oprávněný zájem na bezpečnosti sítí a informací, který GDPR výslovně uznává, a nasadit kompenzační opatření – omezený okruh přístupu, krátkou lhůtu, pseudonymizaci. Klíčové je rozhodnutí zaznamenat. Právě schopnost doložit úvahu, proč jste se rozhodli tak či onak, je to, co obě normy oceňují nejvíce.

Bezpečnostní logování, telemetrie i forenzní analýza musí obstát také z pohledu minimalizace údajů a právního základu zpracování.

Společné principy, na kterých lze stavět

Když ustoupíme od jednotlivostí, uvidíme, že CRA a GDPR sdílejí stejnou myšlenkovou výbavu. Nejsou to dvě náhodně se křížící regulace, ale dva výhonky téže evropské filozofie: přesouvat odpovědnost za bezpečnost a ochranu na toho, kdo produkt tvoří a data zpracovává, a vyžadovat, aby to uměl doložit.

Obrázek 4 · Pět principů, které spojují CRA a GDPR

Tuto společnou DNA lze shrnout do pěti principů. Zaprvé bezpečnost, respektive soukromí již od návrhu a ve výchozím nastavení. Zadruhé přístup založený na riziku – opatření mají odpovídat riziku, nikoli slepě vyplňovat seznam. Zatřetí řízení zranitelností a incidentů jako trvalý proces od nálezu přes nápravu po hlášení. Začtvrté bezpečnost dodavatelského řetězce. A zapáté doložitelnost a odpovědnost vedení, nikoli jen IT oddělení.

Praktický důsledek je zásadní: kdo poctivě zvládl GDPR, nezačíná u CRA na zelené louce, a naopak. Posouzení rizik, evidenci aktiv, plán reakce na incident, dokumentaci dodavatelů i kulturu doložitelnosti lze z velké části sdílet. Vnímat obě normy jako jeden systém proto není jen filozofie – je to úspora času, peněz a chyb.

Stojí za to zdůraznit i opačný směr toku hodnoty. Nejen že soulad s GDPR usnadňuje CRA – platí to i naopak: produkt vyvinutý podle CRA je pro správce lepším nástrojem k plnění GDPR. Když výrobce dodá zařízení s bezpečným výchozím nastavením, řízením přístupu a jasně stanovenou dobou podpory, dostává správce do ruky prostředek, jímž snáz doloží vhodná opatření podle článku 32 i ochranu již od návrhu podle článku 25. Kvalitní a bezpečný produkt tak zvyšuje úroveň ochrany údajů napříč celým trhem, nejen u svého výrobce.

Sdílená DNA má i organizační rozměr. Obě normy posouvají odpovědnost směrem k vedení: GDPR skrze zásadu odpovědnosti, CRA skrze povinnosti výrobce a jasně určené kontaktní místo. Vedení, které chápe, že bezpečnost produktu a ochrana údajů jsou dvě strany téže mince, nepotřebuje dva soupeřící rozpočty a dvě strategie – vystačí si s jednou, dobře postavenou.

Dobře nastavené procesy podle GDPR mohou být základem pro CRA. Řízení rizik, dokumentaci a reakci na incidenty není nutné budovat dvakrát.

Šest kroků k integrovanému postupu

Jak tedy prakticky postupovat, aby z CRA a GDPR nevznikly dva soupeřící projekty, ale jeden funkční celek? Následujících šest kroků tvoří páteř integrovaného přístupu.

Obrázek 5 · Integrovaný postup: šest kroků k souladu CRA i GDPR

• Zmapovat průnik. Zjistěte, které vaše produkty zpracovávají osobní údaje a kde přesně se obě působnosti setkávají. Tento seznam je základem všeho dalšího.
• Propojit týmy. Posaďte k jednomu stolu bezpečnost produktu, pověřence pro ochranu osobních údajů, právní oddělení a vývoj. Oddělené agendy plodí rozpory; společná agenda plodí řešení.
• Sjednotit řízení rizik. Pište jedno posouzení rizik, které pokrývá jak bezpečnost produktu (CRA), tak rizika zpracování (GDPR). Sdílený jazyk rizik ušetří většinu duplicit.
• Postavit jeden incident-response. Jeden rozhodovací strom, který na konci vygeneruje dvě hlášení – k CSIRT a ENISA podle CRA a k dozorovému úřadu, případně subjektům, podle GDPR. Nacvičte jej dříve, než přijde ostrý incident.
• Sdílet důkazy. Propojte technickou dokumentaci, SBOM a posouzení shody s DPIA, záznamy o zpracování a evidencí opatření. Doložitelnost pak vzniká jednou, ne dvakrát.
• Nakupovat s ohledem na CRA. Jako správce zohledněte soulad s CRA a délku podpory už při výběru produktů a dodavatelů. Bezpečný produkt vám usnadní i plnění GDPR.

Kde začít hned? Nečekejte na velký transformační program. Vyberte jeden produkt, který zpracovává osobní údaje, a proveďte na něm celý cyklus nanečisto: společné posouzení rizik, jedno přejímací kritérium a nácvik dvojího hlášení incidentu. Získáte tím šablonu, kterou pak rozšíříte na celé portfolio – a zároveň hmatatelný důkaz pro vedení, že integrovaný přístup skutečně funguje a šetří práci.

Zbývá otázka vlastnictví. Integrovaný přístup potřebuje jasného garanta – ať už je jím pověřenec pro ochranu osobních údajů rozšířený o bezpečnostní agendu, manažer kybernetické bezpečnosti se znalostí GDPR, nebo malý průřezový výbor. Podstatné není, kdo přesně to bude, ale že někdo obě agendy drží pohromadě a má mandát rozhodovat napříč týmy. Bez jasného vlastníka se i sebelepší postup rozpadne zpět do dvou oddělených sil.

Nad tím vším visí harmonogram. Povinnosti hlášení podle CRA se uplatňují od 11. září 2026, plná shoda produktů se vyžaduje od 11. prosince 2027 a GDPR platí už dnes. Příprava procesů, dokumentace a posouzení shody trvá měsíce, ne týdny – kdo začne pozdě, riskuje, že nebude připraven.

Začněte jedním produktem: společně posuďte rizika, propojte týmy a vyzkoušejte si postup při incidentu ještě před skutečnou krizí.

Jedna odpovědnost, méně duplicit a lepší ochrana

Cyber Resilience Act se dá číst dvěma způsoby. Jako další regulační břemeno naložené na už tak přetíženou compliance – nebo jako logické dovršení cesty, kterou GDPR nastoupilo před osmi lety. Přikláním se k druhému čtení. CRA totiž řeší přesně to, co GDPR předpokládá, ale samo neumí vynutit na úrovni produktu: aby zařízení a software, přes které tečou osobní údaje, byly skutečně bezpečné a udržované po celou dobu své životnosti.

Firmy, které obě normy propojí do jednoho systému, získají víc než jen soulad. Získají vyšší skutečnou úroveň ochrany dat, méně duplicitní práce a silnější vyjednávací pozici – protože zákazníci i partneři se dnes stále častěji ptají „jak to máte ošetřené“ dřív, než podepíšou. Blíží se CRA. A pro toho, kdo umí spojit tečky mezi bezpečností produktu a ochranou údajů, to není hrozba, ale příležitost ukázat, že tomu rozumí.

Zkušenost s GDPR nás naučila ještě jednu věc: největší náklady nevznikají ze samotných pravidel, ale z toho, když se k nim firma postaví na poslední chvíli a odděleně od zbytku svého fungování. CRA dává příležitost tuto chybu nezopakovat. Kdo ji uchopí jako přirozené rozšíření už existující kultury ochrany a doložitelnosti, projde jí nesrovnatelně snáz než ten, kdo v ní uvidí jen další izolovaný audit navíc.

Ať už tedy CRA vnímáte primárně jako výrobce, nebo jako správce dat, závěr je stejný: nejde o dvě oddělené povinnosti, ale o dvě strany téže odpovědnosti za digitální svět, který budujeme. A čím dřív začnete obě strany spravovat společně, tím levnější, klidnější a věrohodnější ta cesta bude.

Zdroje

• Nařízení Evropského parlamentu a Rady (EU) 2024/2847 (Cyber Resilience Act).
• Nařízení Evropského parlamentu a Rady (EU) 2016/679 (GDPR).
• Evropská komise – Cyber Resilience Act; ENISA – jednotná platforma pro hlášení.

Michal Merta

Odborník se specializací na IT bezpečnost, ochranu osobních údajů (včetně role DPO), firemní compliance a IT právo