Risk assessment podľa čl. 13: praktická metóda na dve strany

Slovo „risk assessment" znie ako projekt na týždne, ale pre malú firmu je to dvojstranový dokument, ktorý raz spíšete a potom už len udržiavate. Cyber Resilience Act ho vyžaduje v čl. 13: posúdenie kybernetických rizík má riadiť to, ako produkt navrhujete, vyvíjate, dodávate a udržiavate, a je súčasťou technickej dokumentácie (bod 3 Prílohy VII). Ukážeme jednoduchú metódu, ktorú zvládnete bez konzultanta.

Načo to je (a načo nie)

Risk assessment nie je papier pre papier. Je to nástroj, ktorý vám povie, kam sústrediť úsilie: ktoré časti produktu chrániť najviac a ktoré požiadavky z Prílohy I sú pre vás relevantné. CRA nechce univerzálny „maximálny" produkt — chce, aby ste bezpečnostné opatrenia zvolili primerane rizikám svojho konkrétneho produktu. A práve to risk assessment dokladá.

Metóda na dve strany

Postupujte v piatich krokoch. Každý je pár riadkov, nie kapitola:

1. Popíšte produkt a jeho hranice. Čo to je, čo robí, s čím komunikuje (siete, API, súbory, zariadenia), aké dáta spracúva. Toto je kontext pre všetko ďalšie.
2. Vymenujte aktíva a dáta. Čo má hodnotu alebo je citlivé: používateľské údaje, prihlasovacie tajomstvá, konfigurácia, integrita samotného produktu.
3. Identifikujte hrozby. Ku každému aktívu: čo by sa mohlo pokaziť? Neoprávnený prístup, únik dát, podvrhnutá aktualizácia, zneužitie zraniteľného komponentu, DoS. Nemusí to byť vyčerpávajúce — musí to byť poctivé.
4. Ohodnoťte pravdepodobnosť a dopad. Jednoduchá škála (nízka/stredná/vysoká) stačí. Súčin vám dá poradie: čo riešiť prednostne a čo je okrajové.
5. Priraďte opatrenia. Ku každému významnému riziku napíšte, čo s ním robíte — a naviažte to na konkrétnu požiadavku z Prílohy I časť I (napr. bezpečná autentifikácia, šifrovanie dát, minimalizácia útočnej plochy, bezpečná distribúcia aktualizácií).

Na koniec pridajte krátku vetu ku každému riziku, ktoré vedome neriešite — a prečo (je mimo hraníc produktu, dopad je zanedbateľný). Vedomé rozhodnutie zdokumentované je lepšie než tichá diera.

Mini-príklad na jednom riadku

Ako vyzerá jeden riadok takého posúdenia? Povedzme desktop aplikácia, ktorá ukladá prihlasovacie tokeny:

1. Aktívum: prihlasovací token uložený lokálne.
2. Hrozba: iný proces alebo používateľ na tom istom stroji token prečíta.
3. Pravdepodobnosť × dopad: stredná × vysoká → prednostné.
4. Opatrenie: token šifrovať a uložiť do OS keychainu; naviazané na požiadavku „ochrana dôvernosti údajov" z Prílohy I časť I.

Takýchto riadkov máte na dvoch stranách pokojne desať–pätnásť. Nie je to o objeme, ale o tom, že ku každému významnému riziku existuje rozhodnutie s väzbou na požiadavku. To je presne to, čo od vás risk assessment podľa čl. 13 chce — a čo neskôr uľahčí aj technickú dokumentáciu.

Ako ho napojiť na zvyšok

Risk assessment nestojí sám. Jeho výstup sa premieta do:

1. Návrhu a vývoja — opatrenia z bodu 5 sú to, čo v produkte reálne robíte (secure-by-design vlastnosti z Prílohy I časť I).
2. Riešenia zraniteľností — riziko „zraniteľný komponent" vás privedie k SBOM a monitoringu (Príloha I časť II).
3. Technickej dokumentácie — samotný dokument je bod 3 Prílohy VII, viď článok o self-assessmente.

Udržiavanie

Čl. 13 očakáva, že posúdenie aktualizujete, keď je to potrebné — nie mesačne pre nič za nič, ale pri väčších zmenách produktu, novej integrácii alebo novom type hrozby. V praxi stačí prejsť dvojstranu pri každom väčšom release a upraviť, čo sa zmenilo. Datujte verzie, aby bolo vidno, že dokument žije.

Kedy ho revidovať

Risk assessment nie je „raz a hotovo". Čl. 13 očakáva jeho aktualizáciu, keď je to potrebné — teda pri udalostiach, ktoré menia obraz rizika:

1. väčšia zmena produktu (nová funkcia, ktorá otvára novú útočnú plochu),
2. nová integrácia (pripojenie na cudzí systém, nový typ vstupu),
3. nová trieda hrozby alebo významná zraniteľnosť v komponente, ktorý používate,
4. zmena spôsobu nasadenia (napr. z on-prem na sieťovo dostupné).

V praxi stačí prejsť dvojstranu pri každom väčšom release a upraviť, čo sa zmenilo. Datovanie verzií ukáže, že dokument žije — čo je pre orgán aj odberateľa dôveryhodnejšie než pekný, ale rok neaktualizovaný papier.

Časté otázky

1. Musí to robiť bezpečnostný expert? Nie. Poctivá dvojstrana od vývojárskeho tímu je lepšia než drahý dokument, ktorému nikto nerozumie.
2. Ako podrobné to má byť? Primerane riziku produktu (čl. 13). Bežná aplikácia nepotrebuje stovky strán — potrebuje jasné rozhodnutia k významným rizikám.
3. Kde risk assessment „žije" v dokumentácii? Je to bod 3 technickej dokumentácie podľa Prílohy VII — teda niečo, čo aj tak potrebujete spísať.
4. Musíme použiť konkrétnu metodiku? Nariadenie žiadnu nepredpisuje; dôležité je, aby posúdenie bolo poctivé, naviazané na Prílohu I a aktualizované, keď je to potrebné.

Kľúčový bod

Risk assessment podľa čl. 13 nie je akademické cvičenie — je to nástroj, ktorý vám povie, kam sústrediť úsilie, a zároveň dôkaz, že ste bezpečnostné opatrenia zvolili primerane rizikám svojho produktu. Dá sa zvládnuť na dve strany v piatich krokoch: opíšte produkt a jeho hranice, vymenujte aktíva a dáta, identifikujte hrozby, ohodnoťte pravdepodobnosť a dopad a ku každému významnému riziku priraďte opatrenie naviazané na požiadavku z Prílohy I časť I. Riziká, ktoré vedome neriešite, tiež zapíšte — vedomé rozhodnutie s odôvodnením je lepšie než tichá diera. Dokument je bod 3 vašej technickej dokumentácie a živý zostáva vďaka revíziám pri väčších zmenách. Najživšiu vetvu — „zraniteľný komponent" — pokrýva priebežný monitoring SBOM, takže tá časť posúdenia je vždy aktuálna a doložená.

Ako pomáha CRAguard

Jednu z najživších častí rizika — „zraniteľný komponent" — drží CRAguard za vás: denne porovnáva váš SBOM proti databázam a dáva jasný verdikt, takže táto vetva risk assessmentu je vždy aktuálna a doložená audit trailom. Zvyšok dvojstrany navádzame šablónou. Zistite, či sa vás CRA týka, alebo sa zaraďte do waitlistu.

Tento článok je informatívny a nie je právnym poradenstvom. Vychádza z nariadenia (EÚ) 2024/2847 (čl. 13, Príloha I časť I, Príloha VII) a usmernenia Európskej komisie zo dňa 27. 7. 2026.