Dokumentace kybernetické bezpečnosti. Každý ví, že ji musí mít. Málokdo ví, jak s ní v praxi pracovat. A ještě méně firem ji má ve stavu, který by obstál ve chvíli skutečné krize.
Na webináři CyberEdu: Dokumentace v kybernetické bezpečnosti: Co musí firma mít – A proč to často nestačí se Roman Vontor ze společnosti Premium Systems, firmy propojující kybernetickou bezpečnost, technologie a řízení rizik, podělil o zkušenosti z praxe.
Výsledkem je přehled toho, co zákon o kybernetické bezpečnosti (zákon č. 264/2025 Sb., zkráceně ZoKB) skutečně vyžaduje, kde firmy nejčastěji chybují a jak z dokumentace udělat nástroj, který vás skutečně ochrání, ne jen šuplíkový papír.
Můžete se podívat na záznam, nebo si přečíst detailní zápisky pod videem.
Proč nestačí „mít splněno“
Nejrozšířenějším přístupem k dokumentaci kybernetické bezpečnosti je to, čemu Roman Vontor říká šuplíkový projekt: firma si dá dohromady sadu dokumentů, nechá je schválit vedením, uloží je… a s tím to hasne. Hlavně aby bylo co ukázat při auditu.
Problém nastane ve chvíli, kdy přijde skutečný incident.
„Stačí jedna změna, která většinou bývá hned na začátku, a v té dokumentaci se začnete ztrácet. Nastane panika, dokumentaci zahodíte a začnete řešit, co přijde dřív.“
Statická dokumentace popisuje stav v jednom konkrétním okamžiku, ale a firmy se vyvíjejí. Přibývají lidé, systémy, dodavatelé. Mění se hrozby. Dokumentace, která se neaktualizuje, je k ničemu. A někdy i škodlivá, protože vytváří falešný pocit bezpečí.
Zákon o kybernetické bezpečnosti, stejně jako norma NIS2, ze které vychází, přistupuje k věci jinak: nevyžaduje konkrétní sadu dokumentů, ale funkční systém řízení kybernetické bezpečnosti. Systém, který se průběžně vyvíjí, jehož pravidla jsou vymahatelná a jehož stav lze doložit auditní stopou.
Tři vrstvy bezpečnostní dokumentace
Dokumentaci kybernetické bezpečnosti si lze představit jako operační systém vaší firmy. A stejně jako každý OS, i ona má svou hierarchii.
1. Strategická vrstva — bezpečnostní politiky
Nejvyšší úroveň. Dokumenty na této vrstvě popisují co firma chce a jak to chce dělat. Velmi obecně, s přiřazenými odpovědnostmi. Patří sem například politika řízení přístupu, politika zálohování nebo politika řízení incidentů.
Jde o pravidla hry, nikoliv o návod krok za krokem. Jejich účelem je definovat záměr a přiřadit garanta.
2. Analytická vrstva — aktiva a rizika
Střední vrstva se věnuje tomu, co chcete chránit a před čím. Sem patří evidence aktiv, hodnocení rizik a plán jejich ošetření.
Tato vrstva tvoří základ všeho ostatního a proto zabere nejvíce času. Roman Vontor odhaduje, že analýza a hodnocení aktiv tvoří přibližně 70 % celkové práce při implementaci ZoKB.
3. Operativní vrstva — postupy a instrukce
Třetí vrstva je každodenním nástrojem. Konkrétní postupy, konfigurační záznamy, návody pro obnovu systémů. Přesně to, po čem sáhne správce sítě v pátek večer, kdy se něco pokazí.
Zásadní chybou je tyto vrstvy míchat. Když v jednom dokumentu kombinujete obecné principy s konkrétními IP adresami a pracovními postupy, výsledek není použitelný ani jako strategický dokument, ani jako operativní příručka.
Organizace kybernetické bezpečnosti: kdo za co odpovídá
Zákon vyžaduje jasnou strukturu rolí. V vyšším režimu to znamená formálně ustanovený výbor pro kybernetickou bezpečnost a jasně definované funkce manažera, architekta a auditora kybernetické bezpečnosti.
V nižším režimu zpravidla postačí pověřená osoba.
V obou případech platí jedno zásadní pravidlo: ten, kdo IT provozuje, nesmí být sám sobě auditorem.
Praktickým nástrojem, který Roman Vontor doporučuje, je přehledná matice politik — tabulka, kde každý zákonný požadavek má přiřazenou směrnici, zodpovědnou osobu a datum poslední aktualizace. Nejde o formalitu, ale o živý dokument, do kterého kdokoli nahlédne a okamžitě ví, co platí, kdo za to ručí a kdy se to naposledy revidovalo.
Dokument tohoto typu se v nižším režimu nazývá Přehled bezpečnostních opatření, ve vyšším režimu Prohlášení o aplikovatelnosti. Smysl je v obou případech stejný: vnést pořádek do toho, jak máte kybernetickou bezpečnost nastavenou.
Analýza a hodnocení aktiv: jak jít správně hluboko
Paragraf 12 ZoKB ukládá povinnost vymezit rozsah řízení kybernetické bezpečnosti — tedy identifikovat aktiva, která budete chránit, a přiřadit k nim bezpečnostní opatření.
Klíčová otázka, kterou si firmy kladou: do jaké hloubky máme jít?
Roman Vontor doporučuje princip, který popisuje jako „co nejméně možné, ale jak nejvíce nutné„: aktiva popisujte na takové úrovni granularity, na jaké k nim přistupujete stejným způsobem. Pokud ke všem notebookům uplatňujete stejná pravidla bez ohledu na výrobce nebo verzi operačního systému, evidujte je jako jednu kategorii — nikoliv jako sto samostatných položek.
„Když si řeknete, řeším notebooky jako celek, je to pro vás jedno aktivum. Když si řeknete, budu řešit každý notebook zvlášť, může to být sto aktiv — každé s vlastními opatřeními a hodnocením.“
Zvláštní pozornost si zaslouží zařízení bez aktuální podpory výrobce (end-of-support). Tato zařízení je třeba evidovat samostatně a přijmout vůči nim kompenzační opatření. Typicky omezit jejich přístup do sítě nebo je zcela izolovat.
Ilustrativním příkladem z praxe je průmyslový CNC stroj s 30letou životností, jehož řídící počítač stále běží na Windows XP. Firma si toto riziko neuvědomila, neizolovala stroj od sítě a právě přes něj se útočník dostal do systémů. Incident byl odhalen až v pondělí ráno, zálohy nebyly otestovány a výsledkem byl velmi dlouhý výpadek.
Aktuálním tématem jsou také počítače s Windows 10, jejichž prodloužená podpora Microsoftu se blíží ke konci. Všechna taková zařízení by měla být evidována zvlášť a měla by pro ně existovat specifická opatření.
Rizika a jejich ošetření
Výstupem analýzy rizik by neměl být dokument, ale úkolovník. Živý seznam, kde je ke každému riziku zaznamenáno, jaké opatření bylo přijato, kdy a kým. V nižším režimu není Risk Treatment Plan (RTP) formálně povinný, ale v praxi jen těžko prokážete přiměřenost přijatých opatření bez toho, abyste si nejprve analýzu udělali.
Pro malé firmy s nižším počtem aktiv postačí Excel. Pro organizace s více než 30 aktivy, nebo tam kde s dokumentací pracuje více lidí, doporučuje Roman Vontor specializovaný nástroj — například MoyaKybeon, kde jsou provazby mezi aktivy, hrozbami a opatřeními zabudovány přímo do platformy.
Vzdělávání zaměstnanců: víc než prezenční listina
Zákon jasně stanovuje, že školení zaměstnanců nesmí být odbyta dvěma otázkami přilepenými na konec kurzu BOZP. Obsah i forma školení musí odpovídat konkrétním cílovým skupinám a účinnost musí být prokazatelná.
Přílohy příslušných vyhlášek (příloha č. 6 pro vyšší režim, příloha č. 3 pro nižší) obsahují témata, která mají být proškolena. Patří sem například bezpečnost hesel, obrana proti sociálnímu inženýrství a phishingu nebo problematika používání vlastních zařízení (BYOD), zejména mobilních telefonů, které se v podnikových sítích chovají jako nekontrolovaný vstupní bod.
Jako naprosté minimum doporučuje Roman Vontor test po každém školení s nastavenou minimální úspěšností (70–80 %) a systémem opakování pro ty, kteří ho nesplní. Nestačí vědět, že zaměstnanec byl přítomen, potřebujete doložit, že problematice porozuměl.
Stále oblíbenější formou jsou phishingové kampaně: simulované útoky, po nichž zaměstnanci, kteří klikli na podvodný odkaz, absolvují cílené školení. Výsledky bývají anonymizované. Nejde o odhalování jednotlivců, ale o měření celkové odolnosti organizace.
Z praxe: nejčastějším vektorem finančního útoku jsou v současnosti e-maily s podvrženými fakturami (Business Email Compromise), kde se liší pouze číslo bankovního účtu. Účetní v časovém stresu toto přehlédne a záměna čísla účtu na jinak identické faktuře je přesně ten typ útoku, který standardní technická opatření nezachytí.
Řízení dodavatelů: specifikum českého zákona
Na rozdíl od samotné normy NIS2 český ZoKB explicitně vyžaduje přenášet požadavky kybernetické bezpečnosti i na dodavatele. Přílohy obou vyhlášek obsahují seznam ustanovení, která by měla být součástí každé smlouvy s dodavatelem majícím přístup k vašim systémům nebo datům.
Klíčové body, na které se zaměřit:
- Povinnost informovat o incidentech a výpadcích na straně dodavatele
- Multifaktorové ověřování pro vzdálený přístup do vašich systémů
- Pravidelná revize toho, zda dodavatel dodržuje dohodnutá pravidla
- Smazání nebo vrácení dat při ukončení smluvního vztahu
- SLA s reálnými sankcemi, nikoliv pouze nominální dostupnost, za jejíž nedodržení je dodavatel připraven spíše podstoupit soudní spor, než ji skutečně garantovat
Roman Vontor doporučuje připravit standardizovanou bezpečnostní přílohu ke smlouvám a ve spolupráci s právníkem ji postupně zapracovávat. A to jak do nových, tak do stávajících smluvních vztahů.
Kontinuita fungování: zálohy nestačí
Většina firem dnes zálohuje. Málokterá zálohování testuje. A ještě méně firem dokáže říct, za jak dlouho by obnovila provoz po výpadku. A zda by to pro ně bylo přijatelné.
ZoKB v nižším režimu vyžaduje stanovit priority obnovy klíčových služeb a přiřadit k nim odpovědné osoby. Ve vyšším režimu k tomu přibývá formální Business Impact Analysis (BIA) s přesně definovanými metrikami:
- RTO (Recovery Time Objective) — maximální přijatelná doba výpadku
- RPO (Recovery Point Objective) — jak daleko dozadu je přijatelné ztratit data
Tato čísla nesmí vycházet z pocitu IT správce. Musí vycházet z obchodní reality. Z toho, jaké sankce hrozí při nedodání, jak kritický je konkrétní datum v měsíci (pro účetní firmu je to jiný den než pro výrobní podnik) a jak dlouhý výpadek by skutečně znamenal existenční riziko.
Praktickým nástrojem pro ověření je tabletop cvičení: simulace incidentu se stopkami v ruce. Vypadl server. Správce je na dovolené. Co teď? Za jak dlouho se systém obnoví? Kdo co dělá?
Výsledek takového cvičení je mnohem cennější než jakýkoliv papírový plán. Ukáže mezery, které v dokumentaci nevidíte.
Tištěná krizová dokumentace
Roman Vontor zastává jednoznačný názor: krizová dokumentace by měla existovat v tištěné podobě a být fyzicky dostupná na více místech.
„Při skutečném incidentu se může stát, že se nedostanete na cloud, nedostanete se na úložiště. Ten papír vás v krizi nezradí.“
Přirovnání k pilotovi v letadle, který při technické závadě nalistuje správnou stránku příručky a postupuje krok za krokem, není náhodné. Přesně tak by měla fungovat vaše krizová dokumentace: stručně, jednoznačně, s jasně přiřazenými odpovědnostmi.
Nejčastější chyby v praxi
Na základě zkušeností Romana Vontora z práce s desítkami firem lze identifikovat opakující se vzorce selhání:
- Odpovědnost hozena na IT — kybernetická bezpečnost je záležitost celé organizace a ze zákona odpovídá vedení. IT manažer bez odpovídajících pravomocí a času nemůže tuto roli plnit.
- Hledání okamžiku „máme splněno“ — zákon nevyžaduje jednorázový výstup, ale průběžné řízení. „Splněno“ neexistuje.
- Dokumentace bez vlastníka — každý dokument potřebuje konkrétního garanta, který za jeho aktuálnost ručí jménem a funkcí.
- Zálohy bez testování — záloha, jejíž obnovitelnost nikdo neověřil, je pouze statistická položka. Neexistuje, dokud neproběhne úspěšný test obnovy.
- Přílišná hloubka analýzy aktiv — firmy, které se ponoří do přílišného detailu, se v něm zahltí a ztrácejí schopnost celkového přehledu.
Jak začít — praktická doporučení
Pokud teprve začínáte: Sestavte tabulku, kde každému požadavku vyhlášky přiřadíte garanta, příslušnou směrnici nebo opatření a datum poslední revize. Tento jednoduchý dokument je základem funkčního systému.
Pokud dokumentaci máte, ale víte, že leží v šuplíku: Zařaďte kybernetickou bezpečnost jako pravidelný bod porad. I 10 minut jednou týdně, kdy se jeden z garantů vyjádří ke stavu své oblasti, udělá z byrokratické nutnosti živý proces.
Pokud nevíte, kde začít s aktivy: Sedněte si s týmem a odpovězte na tři otázky:
- Co by vám způsobilo největší škodu?
- Bez čeho se nedokážete obejít?
- Co by ohrozilo vaše zákazníky nebo vaši reputaci?
Odpovědi naznačí, kde soustředit pozornost.
Pokud máte ISO 27001: Dobrá zpráva: analýza rizik zpracovaná v rámci ISO 27001 je dostatečná i pro požadavky ZoKB. Stačí ji revidovat a ověřit aktuálnost.
Dokumentace jako nástroj, ne jako povinnost
Závěrečná myšlenka Romana Vontora vystihuje podstatu celého tématu:
„Splnit zákon a mít dotaženou dokumentaci by měl být první krok, ne váš cíl. Cílem by měly být postupy a procesy, které vás ochrání ve chvíli, kdy na nich budete záviset.“
Kybernetický incident se nestane ve chvíli, kdy na to budete připraveni. Stane se v pátek večer, kdy je správce na dovolené, záloha nebyla testována a krizový plán existuje jen v jednom PDF souboru na serveru, který právě nefunguje.
Dobře nastavená dokumentace není o papírech. Je o tom, aby každý ve firmě věděl, co dělat, i v kritické situaci.
Chcete zjistit, kde stojíte?
Pokud si po přečtení tohoto článku nejste jisti, zda vaše dokumentace splňuje požadavky ZoKB, nebo chcete vědět, jak k řízení kybernetické bezpečnosti přistoupit prakticky a bez zbytečné byrokracie:
- MoyaKybeon vám pomůže strukturovat a udržovat evidenci aktiv, hodnocení rizik a bezpečnostní dokumentaci na jednom místě, s auditní stopou a přehlednou vazbou mezi jednotlivými oblastmi.
- Premium Systems nabízí úvodní konzultaci zdarma pro účastníky webináře — assessment stávajícího stavu a konkrétní doporučení, jak postupovat dál.
Víte, jak vám s tím vím může pomoci MoyaKybeon?
V Knihovně můžet mít všechny dokumenty přehledně uložené ať už formou přílohy nebo odkazu na jiné úložiště. Díky tomu máte na první pohled jasno, jak na tom s dokumentací jste. Jen to vytištění na papír už musíte zvládnout sami.
Dokumentaci teprve vytváříte? I s tím vám může MoyaKybeon elegantně pomoci. Nadefinujte si potřebnou dokumentaci do pracovních postupů a rozdělte její zpracování na jednotlivé úkoly. Každý dokument tak získá jasný termín i zodpovednou osobu.