NIS2 není úkol, který může vedení předat správci IT s požadavkem, aby „nějak zabezpečil servery“. Dotýká se odpovědnosti za provoz firmy, dodavatelů, přístupových práv, obnovy po výpadku, vývoje aplikací i způsobu, jakým se při incidentu rozhoduje.
V České republice se povinnosti neřídí pouze samotnou evropskou směrnicí NIS2. Od 1. listopadu 2025 je účinný zákon č. 264/2025 Sb., o kybernetické bezpečnosti, doplněný prováděcími vyhláškami. Firmy proto musí vycházet z české právní úpravy, svého režimu povinností a skutečného rozsahu poskytované regulované služby.
Pro vedení firmy je podstatná především jedna otázka: dokážeme doložit, že známe svá hlavní kybernetická rizika a že je přiměřeně řídíme?
Nestačí mít antivirový program, zálohování a několik bezpečnostních směrnic. Opatření musí odpovídat skutečnému provozu a musí fungovat i ve chvíli, kdy odejde administrátor, selže dodavatel nebo útok zasáhne důležitou firemní aplikaci.
Obsah článku
Týká se NIS2 právě vaší firmy?
Proč už kybernetická bezpečnost není pouze odpovědností IT
Jak povinnosti vypadají v reálném provozu
Praktické příklady problémů, které dokumentace sama nevyřeší
Co musí firma stihnout po registraci
Doporučený postup během prvních 90 dnů
Nejčastější chyby při přípravě na NIS2
Sankce nejsou jediným obchodním rizikem
Kdy dává smysl technický audit
Jak může pomoci GoveSoft
Týká se NIS2 právě vaší firmy?
Prvním krokem není nákup bezpečnostního nástroje ani objednání penetračního testu. Nejdříve je nutné správně určit, zda firma poskytuje některou z regulovaných služeb a do jakého režimu povinností spadá.
Rozhodování obvykle vychází ze tří oblastí:
- Jakou službu firma skutečně poskytuje.
- Zda splňuje kritéria významnosti, nejčastěji podle velikosti podniku.
- Zda bude zařazena do režimu nižších, nebo vyšších povinností.
Regulace se týká například vybraných subjektů v energetice, dopravě, zdravotnictví, výrobním průmyslu, digitální infrastruktuře, odpadovém hospodářství, potravinářství, výzkumu a dalších odvětvích. Samotné zařazení firmy do určitého oboru ale ještě nemusí dát jednoznačnou odpověď. Rozhodující je konkrétní regulovaná služba a podmínky uvedené ve vyhlášce. NÚKIB pro prvotní posouzení provozuje oficiální kalkulačku.
Modelový příklad: výrobní firma
Strojírenská společnost má 120 zaměstnanců a vyrábí specializovaná průmyslová zařízení. Vedení původně předpokládá, že NIS2 se týká pouze energetiky, bank a nemocnic.
Výrobní průmysl je ale mezi regulovanými oblastmi. Firma proto musí ověřit své přesné zařazení, velikost a podmínky konkrétní služby. Pokud kritéria splní, může spadat do režimu nižších povinností.
Pro management tím vzniká další problém. Firma neprovozuje pouze kancelářské počítače. Její výroba závisí na ERP, plánování výroby, sdílených technologických datech, vzdáleném přístupu servisních firem a někdy také na komunikaci se stroji. Určení rozsahu proto nelze provést pouze podle seznamu serverů.
Pozor na velikost celé skupiny
Častou chybou je posuzovat pouze počet zaměstnanců nebo obrat jedné české společnosti. Při určování velikosti mohou být relevantní také partnerské a propojené podniky.
Česká firma může mít například jen 35 zaměstnanců. Pokud je ale součástí skupiny s několika stovkami zaměstnanců, nemusí být pro účely regulace považována za malý podnik. Posouzení skupinových vazeb proto patří mezi první kroky, nikoliv až mezi právní detaily na konci projektu.
Pokud firma splní podmínky později, má regulovanou službu ohlásit do 60 dnů od okamžiku, kdy podmínky naplnila. Organizace, které kritéria splňovaly už při účinnosti zákona, měly původní lhůtu do konce roku 2025.
Proč NIS2 není pouze odpovědností IT
Technické oddělení může spravovat servery, aktualizace, zálohování a monitoring. Nemůže však samo rozhodnout:
- které služby jsou pro firmu nejdůležitější,
- jak dlouhý výpadek je pro podnik přijatelný,
- jaký rozpočet se má použít na odstranění rizik,
- které dodavatelské vztahy je nutné změnit,
- kdo smí přijmout rozhodnutí při závažném incidentu,
- ani jaká obchodní rizika může firma akceptovat.
To jsou rozhodnutí vedení.
V režimu nižších povinností musí vrcholné vedení mimo jiné určit osobu pověřenou kybernetickou bezpečností, absolvovat příslušné školení, zajistit potřebné personální, finanční a technické zdroje a sledovat stav zavádění opatření. Vyšší režim obsahuje formálnější systém bezpečnostních rolí, řízení a kontrol.
Prakticky to znamená, že jednatel nebo představenstvo nemůže odpovědnost vyřešit větou: „Má to na starosti náš externí IT technik.“ Externí dodavatel může opatření realizovat, ale vedení musí vědět, co objednalo, proč je to potřeba a podle čeho zkontroluje výsledek.
Jak povinnosti vypadají v reálném provozu
NIS2 není seznam konkrétních produktů, které firma musí nakoupit. Požaduje řízení rizik a přiměřená organizační a technická opatření. Jejich podoba se proto bude lišit podle velikosti firmy, poskytované služby, používaných systémů a možných dopadů výpadku.
| Oblast | Otázka pro vedení | Praktická realizace |
|---|---|---|
| Rozsah a aktiva | Které systémy jsou nezbytné pro regulovanou službu? | Seznam aplikací, serverů, databází, integrací, zařízení, dat a odpovědných osob |
| Přístupová práva | Kdo má administrátorský nebo vzdálený přístup? | Jmenné účty, vícefaktorové ověřování, pravidelná kontrola oprávnění a odebrání neplatných přístupů |
| Zálohování a kontinuita | Za jak dlouho dokážeme obnovit provoz? | Oddělené zálohy, určené pořadí obnovy a pravidelné testování návratu do provozu |
| Aktualizace a zranitelnosti | Kdo sleduje zranitelnosti používaných systémů? | Evidence verzí, proces aktualizací, stanovené termíny a odpovědnost |
| Monitoring a logování | Jak rychle zjistíme, že se něco děje? | Centrální logy, upozornění, provozní monitoring a stanovený způsob vyhodnocování |
| Dodavatelé | Jak rychle nám dodavatel oznámí svůj incident? | Bezpečnostní požadavky ve smlouvách, kontaktní osoby, lhůty a pravidla vzdáleného přístupu |
| Řešení incidentů | Kdo rozhoduje v noci nebo o víkendu? | Incidentní plán, pohotovostní kontakty, eskalační matice a připravené komunikační postupy |
| Zaměstnanci | Rozpoznají lidé podezřelou situaci? | Pravidelná školení, jednoduchý způsob hlášení a praktické testování |
Nejdůležitější není počet vytvořených dokumentů. Rozhodující je, zda popsaný postup odpovídá skutečnosti.
Praktické příklady problémů, které dokumentace sama nevyřeší
1. Firma zálohuje, ale nedokáže obnovit provoz
Výrobní firma každý den zálohuje ERP databázi. V bezpečnostní dokumentaci proto uvádí, že má zálohování vyřešené.
Při ransomwarovém útoku ale zjistí, že zálohovací server používá stejné přihlašovací údaje jako produkční prostředí. Útočník zašifruje také zálohy. Starší kopie sice existuje, nikdo však několik let nezkoušel její obnovu a chybí aktuální konfigurace aplikace.
Formálně firma zálohovala. Provozně ale neměla připravenou obnovu.
Správná otázka vedení proto není: „Máme zálohy?“ Lepší otázka zní: „Kdy jsme naposledy obnovili celý kritický systém a jak dlouho to trvalo?“
2. Dodavatel má přístup, ale smlouva neřeší incidenty
Externí společnost spravuje ERP a vzdáleně se připojuje do firemní sítě. Smlouva obsahuje cenu podpory a reakční dobu při výpadku, ale neřeší způsob zabezpečení účtů, evidenci přístupů ani povinnost oznámit bezpečnostní incident.
Dodavateli uniknou přihlašovací údaje v pátek večer. Zákazník se o problému dozví až v pondělí, protože smlouva ani provozní postup neurčují, komu a do jaké doby se má událost hlásit.
Odpovědnost za vlastní regulovanou službu tím na dodavatele nepřechází. Firma musí bezpečnostní požadavky zapracovat do smluv a zajistit, aby se o incidentu dozvěděla včas.
3. Bývalý zaměstnanec má stále aktivní přístup
Vedoucí údržby odejde z firmy. Personální oddělení ukončí pracovní poměr, ale informace se nedostane ke správci externího servisního portálu.
Účet zůstane aktivní dalšího půl roku. Má přístup k technické dokumentaci, údajům o zařízeních a vzdálené správě.
Problém nevznikl kvůli slabému heslu. Vznikl proto, že firma neměla propojený proces nástupu, změny pozice a odchodu zaměstnance s řízením přístupových práv.
4. Incident začne v sobotu ráno
Monitoring zaznamená neobvyklý přenos dat v sobotu v 6:30. Automatické upozornění přijde pouze administrátorovi, který je na dovolené. O problému se vedení dozví v pondělí dopoledne.
U incidentů podléhajících hlášení může být nutné podat prvotní hlášení nejpozději do 24 hodin od jejich zjištění a následně dodat další informace do 72 hodin. Prvotní hlášení nemusí obsahovat kompletní forenzní analýzu. Firma ale musí dokázat incident rozpoznat, vyhodnotit a předat odpovědné osobě.
Bez pohotovostních kontaktů a jasného rozhodovacího postupu je lhůta 24 hodin velmi krátká.
Co musí firma stihnout po registraci
Poskytovatel regulované služby má na zavedení požadovaných bezpečnostních opatření zpravidla jeden rok od doručení rozhodnutí o registraci. Stejná přechodná doba se vztahuje také na zahájení plnění povinností spojených s hlášením incidentů.
Rok může působit jako dlouhá doba. U firmy s více pobočkami, starším ERP, výrobními zařízeními a několika externími správci se však rychle spotřebuje na:
- určení rozsahu,
- zmapování systémů a dat,
- úpravu smluv,
- výběr odpovědných osob,
- odstranění největších nedostatků,
- zavedení monitoringu,
- testování záloh,
- změny aplikací,
- školení lidí,
- a vytvoření použitelného incidentního procesu.
Některé nedostatky lze opravit během několika dnů. Změna způsobu přihlašování do starší aplikace, oddělení sítí nebo doplnění auditních záznamů ale může vyžadovat zásah do systému a několik měsíců práce.
Doporučený postup během prvních 90 dnů
1. Ověřte působnost a režim
Použijte kalkulačku NÚKIB, prověřte konkrétní regulovanou službu, velikost podniku a vztahy v rámci skupiny. U nejasného případu zapojte právníka nebo specialistu na regulaci.
Výstupem musí být písemně zachycené rozhodnutí, proč firma pod regulaci spadá, nebo nespadá.
2. Určete odpovědnost
Jmenujte člověka, který bude přípravu koordinovat. Musí mít přístup k vedení, potřebné pravomoci a možnost získávat informace od IT, personalistiky, provozu, nákupu i dodavatelů.
Samotné jmenování člověka bez času a rozpočtu nic nevyřeší.
3. Popište regulovanou službu a její závislosti
Začněte službou, nikoliv hardwarem.
Zjistěte:
- co firma musí dodávat zákazníkům nebo veřejnosti,
- které procesy službu zajišťují,
- na jakých aplikacích a datech závisí,
- kdo systémy spravuje,
- kteří dodavatelé do nich mají přístup,
- a co se stane při jejich výpadku.
Výstupem by měla být srozumitelná mapa služby a jejích technických závislostí.
4. Proveďte analýzu skutečného stavu
Porovnejte požadovaná opatření se skutečným provozem. Nestačí zkontrolovat existenci směrnic.
Ověřte například:
- zda jsou administrátorské účty vedené na konkrétní osoby,
- zda je možné obnovit systémy ze záloh,
- zda jsou důležité aplikace podporované a aktualizované,
- zda monitoring upozorňuje správné lidi,
- zda jsou dostupné bezpečnostní logy,
- zda dodavatelé dodržují pravidla vzdáleného přístupu,
- a zda firma zná všechny veřejně dostupné služby.
5. Odstraňte největší rizika
Některá opatření není nutné odkládat do dokončení celé analýzy.
Typickými rychlými kroky jsou:
- zapnutí vícefaktorového ověřování,
- odebrání neplatných účtů,
- oddělení záloh od produkčního prostředí,
- aktualizace veřejně dostupných systémů,
- omezení sdílených administrátorských účtů,
- doplnění pohotovostních kontaktů,
- a kontrola vzdálených přístupů dodavatelů.
6. Připravte plán s prioritami a rozpočtem
Každé zjištění musí mít:
- popsaný dopad,
- prioritu,
- odpovědnou osobu,
- navržené řešení,
- odhad nákladů,
- a cílový termín.
Seznam padesáti nedostatků bez pořadí vedení nepomůže. Firma musí vědět, které tři problémy mohou zastavit provoz a které úpravy lze bezpečně naplánovat na další období.
7. Vyzkoušejte incident nanečisto
Připravte modelovou situaci. Například:
V sobotu v 8:00 monitoring zjistí podezřelé přihlášení administrátora a hromadný export zákaznických dat. Správce systému není dostupný. Externí dodavatel zatím nepotvrdil, zda byl napaden také jeho účet.
Během cvičení ověřte:
- kdo situaci převezme,
- kdo může odstavit systém,
- kdo kontaktuje dodavatele,
- kdo posoudí ohlašovací povinnost,
- kdo informuje vedení,
- kde jsou potřebné kontakty,
- a zda jsou dostupné logy.
Takové cvičení často odhalí více než další obecná bezpečnostní směrnice.
Nejčastější chyby při přípravě na NIS2
Nákup nástroje před určením problému
Firma koupí nový firewall, SIEM nebo bezpečnostní dohled, ale stále neví, které služby a systémy jsou kritické. Výsledkem mohou být další licence a upozornění, která nikdo neumí vyhodnocovat.
Technologie má řešit konkrétní riziko. Nemá nahrazovat analýzu.
Dokumentace neodpovídá provozu
Směrnice stanoví, že přístupy bývalých zaměstnanců se ruší okamžitě. Ve skutečnosti ale personalistika neposílá správci seznam odchodů a některé externí účty nemají evidovaného vlastníka.
Při kontrole nebo incidentu bude rozhodující skutečný stav, nikoliv formulace v dokumentu.
Projekt zůstane pouze v IT
IT může popsat infrastrukturu, ale nemusí znát smluvní závazky, obchodní priority ani přijatelné délky výpadků.
Do projektu proto musí vstoupit také vedení, provoz, nákup, personalistika, právník a vlastníci důležitých služeb.
Firma prověří síť, ale přehlédne aplikace
Závažné riziko nemusí být jen v nedostatečně chráněném serveru. Může se nacházet přímo ve firemní aplikaci:
- uživatelé mají příliš široká oprávnění,
- citlivé operace se nezapisují do logu,
- aplikace používá nepodporované knihovny,
- hesla nebo přístupové klíče jsou uložené v konfiguraci,
- aktualizaci dokáže nasadit pouze jeden vývojář,
- nebo nelze rychle zablokovat kompromitovaný účet.
Bez kontroly aplikací, databází a integrací může bezpečnostní posouzení přehlédnout systémy, na kterých firma skutečně závisí.
Příprava skončí po splnění termínu
Kybernetická bezpečnost není jednorázový projekt. S každou novou integrací, cloudovou službou, aplikací nebo změnou dodavatele se mění také rizika.
Přehled aktiv, přístupů a opatření proto musí firma pravidelně aktualizovat a kontrolovat.
Sankce nejsou jediným obchodním rizikem
Maximální sankce mohou v režimu vyšších povinností dosáhnout až 250 milionů Kč nebo 2 % čistého ročního obratu podniku. V nižším režimu může jít až o 175 milionů Kč nebo 1,4 % obratu, podle toho, která hodnota je vyšší. Jde o maximální hranice; konkrétní výši určuje NÚKIB ve správním řízení.
Pro většinu firem ale nebude největším rizikem samotná pokuta. Závažnější může být:
- zastavení výroby,
- nedostupnost služby zákazníkům,
- ztráta nebo poškození dat,
- nákladná obnova provozu,
- smluvní sankce,
- ztráta důvěry obchodních partnerů,
- nebo nemožnost prokázat, co se během incidentu skutečně stalo.
Dobře provedená příprava na NIS2 proto nemá sloužit jen regulátorovi. Má snížit pravděpodobnost, že jeden napadený účet, nefunkční záloha nebo chyba dodavatele zastaví celou firmu. Podobné provozní slabiny se často projeví ještě před závažným incidentem. Shrnuje je článek 7 signálů, že firemní software brzdí růst firmy.
Kdy dává smysl technický audit
Technický audit firemní aplikace je vhodný ve chvíli, kdy firma zná zákonné požadavky, ale neví, jaký je skutečný stav jejích aplikací a infrastruktury.
Audit zaměřený na technickou připravenost by měl prověřit zejména:
- architekturu důležitých aplikací,
- uživatelská a administrátorská oprávnění,
- autentizaci a správu přístupů,
- používané knihovny a aktualizace,
- ukládání hesel, certifikátů a klíčů,
- databáze a citlivá data,
- logování důležitých operací,
- monitoring a upozornění,
- zálohování a obnovu,
- způsob nasazování změn,
- napojení na další systémy,
- a vzdálené přístupy dodavatelů.
Výstupem nemá být pouze technický seznam zranitelností. Vedení potřebuje znát obchodní dopad, prioritu, doporučené řešení a odhad náročnosti.
Technický audit nenahrazuje právní posouzení působnosti zákona. Může ale ukázat, zda jsou firemní systémy reálně připravené na požadovaný způsob řízení bezpečnosti, reakci na incident a obnovu provozu.
Podrobnější postup je popsán v článku Technický audit firemní aplikace: kdy se vyplatí a co musí obsahovat.
Jak může pomoci GoveSoft
GoveSoft se zaměřuje na technickou část přípravy: firemní aplikace, databáze, integrace, infrastrukturu a oblasti bezpečnosti, přístupových práv, monitoringu, zálohování a nasazování změn.
Prověříme skutečný stav systému a oddělíme formální nedostatky od rizik, která mohou mít přímý dopad na provoz. Výstup seřadíme podle naléhavosti a navrhneme, co lze opravit rychle, co vyžaduje změnu procesů a které části systému bude nutné modernizovat.
Nezačínáme automaticky návrhem kompletní výměny aplikace ani nákupem dalšího bezpečnostního produktu. Před rozhodnutím o nahrazení systému doporučujeme projít si také 12 otázek před přepisem firemního systému. Prvním cílem je zjistit:
- Které systémy jsou pro poskytovanou službu skutečně důležité.
- Jaká technická rizika dnes firma nedokáže kontrolovat.
- Která opatření přinesou největší snížení rizika.
- Jak rozdělit realizaci do zvládnutelných etap.
Pokud potřebujete ověřit technickou připravenost firemních aplikací a infrastruktury na požadavky nového zákona o kybernetické bezpečnosti, začněte technickou konzultací. Výsledkem má být konkrétní plán opatření, odpovědností a priorit, nikoliv další obecná prezentace o NIS2.
Článek představuje obecný technický a provozní přehled a nenahrazuje právní posouzení konkrétní regulované služby a režimu povinností.