NIS2 je pro mnoho organizací první moment, kdy se kybernetická odolnost přestává brát jako interní technická agenda a stává se tématem pro vedení firmy, audit, provoz i reputaci. V praxi nejde jen o to mít směrnici, odpovědnosti a několik bezpečnostních nástrojů. Důležité je také umět doložit, co se v prostředí děje, co se stalo při incidentu a na základě čeho organizace přijala konkrétní rozhodnutí. Právě tady vstupují do hry logy, jejich centralizace a uchování mimo zdrojové systémy.
U menších a středních organizací bývá kolem NIS2 častý dvojí omyl. První je čistě právní optika: stačí zjistit, zda „spadáme pod zákon“, a tím je téma vyřešené. Druhý je čistě technická optika: koupíme jeden nástroj, začneme sbírat všechno a budeme mít hotovo. Ani jeden přístup sám o sobě nestačí. NIS2 je provozní disciplína. Ověřuje se v okamžiku auditu, incidentu, interního šetření nebo manažerského rozhodování pod tlakem.
Tento materiál nepředstavuje právní poradenství. Slouží jako praktický přehled pro vedení organizací, IT manažery, správce infrastruktury a role odpovědné za bezpečnost, rizika a compliance.
Pro koho je tato stránka
Tato stránka je určená hlavně pro:
- jednatele, majitele a ředitele firem,
- IT manažery a vedoucí infrastruktury,
- externí správce a MSP,
- security, risk a compliance role,
- organizace, které si nejsou jisté, zda se na ně NIS2 vztahuje přímo nebo nepřímo přes dodavatelský řetězec.
Co si z ní odnesete
Po přečtení by vám mělo být jasnější:
- co je NIS2 a proč je důležitá i mimo právní a bezpečnostní oddělení,
- koho se regulace typicky týká a proč nestačí řešit jen jednu podmínku,
- proč samotná dokumentace neprokáže skutečnou připravenost,
- proč jsou logy zásadní pro audit, incidenty a dohledatelnost,
- jaké logy firmy typicky potřebují jako realistické minimum,
- proč lokální logy nestačí a proč jsou při kompromitaci ohrožené,
- kdy dává smysl centralizovaný nebo SaaS model.
Co je NIS2 a proč je to manažerské i provozní téma
NIS2 je evropská směrnice, která zpřísňuje očekávání na kybernetickou bezpečnost organizací poskytujících důležité nebo kritické služby. Není postavená jen na technologiích. Pracuje s řízením rizik, odpovědností vedení, hlášením incidentů, provozní odolností a schopností prokázat, že přijatá opatření nejsou jen formální.
Pro české organizace je důležité i načasování. Nový zákon o kybernetické bezpečnosti byl v Česku publikován 4. srpna 2025 a účinnosti nabyl 1. listopadu 2025. Od té doby už nejde o vzdálenou legislativní debatu, ale o praktickou otázku: koho se nový rámec týká, jaké má povinnosti a jak rychle je schopný dát dohromady minimálně obhajitelný stav.
Z pohledu managementu je NIS2 důležitá proto, že:
- přináší osobní odpovědnost vedení za přiměřené řízení kybernetických rizik,
- zvyšuje nároky na rozhodování pod časovým tlakem při incidentu,
- nutí organizaci pracovat s důkazní stopou, ne jen s deklaracemi,
- dopadá na reputaci, kontinuitu provozu i důvěru zákazníků a partnerů.
Z pohledu IT je důležitá proto, že:
- vyžaduje provozně funkční procesy, ne jen „papírové“ politiky,
- zvyšuje důraz na evidenci, dohledatelnost a kvalitu záznamů,
- tlačí na schopnost rychle vyhodnotit rozsah incidentu,
- odhaluje slabiny lokálního a nekoordinovaného logování.
Koho se regulace typicky týká
NIS2 míří na organizace v klíčových a důležitých odvětvích. Typicky jde o oblasti jako energetika, doprava, zdravotnictví, digitální infrastruktura, veřejná správa, vybrané digitální služby, výroba kritických produktů nebo další segmenty, u kterých výpadek nebo kompromitace může mít širší dopad.
V praxi ale nestačí podívat se jen na obor. Rozhoduje kombinace faktorů:
- jakou službu organizace skutečně poskytuje,
- v jakém odvětví působí,
- jak je velká,
- zda je součástí skupiny propojených podniků,
- jakou roli hraje v dodavatelském řetězci.
Proto bývá nejčastější chybou otázka „jsme kritická infrastruktura ano nebo ne“. Správnější je ptát se, zda poskytujeme regulovanou službu, jaký je náš význam v konkrétním sektoru a podle jakých kritérií bude naše organizace posuzovaná.
Pokud si potřebujete udělat první orientaci, pokračujte na stránku Spadá vaše organizace pod NIS2?.
Nižší a vyšší režim nejsou detail pro právníka
Český rámec rozlišuje nižší a vyšší režim povinností. Rozdíl není jen terminologický. V praxi ovlivňuje hloubku dohledu, intenzitu požadavků na řízení, kvalitu evidence i očekávání vůči managementu a IT týmu.
Pro vedení to znamená hlavně otázku, jak robustně musí být postavené procesy, reporting a kontrola. Pro IT to znamená mimo jiné to, jak dobře musí být organizace schopná doložit změny, přístupy, incidentní časovou osu nebo technické důkazy o tom, že opatření fungují.
Podrobněji to rozebírá stránka Nižší a vyšší režim NIS2.
Co NIS2 typicky neznamená
Kolem NIS2 se často míchají realistické požadavky s nereálnými představami. Většině organizací pomůže si hned na začátku ujasnit, co regulace typicky neznamená:
- neznamená automaticky, že musíte vybudovat vlastní SOC,
- neznamená automaticky, že bez velkého enterprise SIEM nemá smysl začínat,
- neznamená, že stačí vydat směrnici a tím se problém vyřeší,
- neznamená, že lokální Event Viewer, lokální syslog nebo několik oddělených logovacích ostrůvků je dostačující základ,
- neznamená, že odpovědnost lze jednoduše přesunout na MSP nebo dodavatele.
Pro mnoho organizací je důležitější realistické minimum než ambiciózní architektura, kterou neudrží v provozu. Smyslem není „mít všechno“, ale mít dostatečně spolehlivý základ pro audit, incidenty a provozní dohledatelnost.
Proč samotná dokumentace nestačí
Dokumentace je nutná. Potřebujete definované role, řízení rizik, bezpečnostní opatření, plán reakce na incidenty i základní odpovědnosti. Problém je, že dokumentace sama o sobě neodpoví na otázky, které přijdou při kontrole nebo po incidentu:
- Kdo měl přístup do napadeného systému?
- Odkud přišlo podezřelé přihlášení?
- Jaké změny proběhly před incidentem?
- Které systémy byly zasažené a v jakém pořadí?
- Kdy se organizace o problému prokazatelně dozvěděla?
- Z čeho vychází interní vyhodnocení dopadu?
Bez provozní evidence a použitelných logů se z auditu nebo incident response stává kombinace domněnek, ručního dohledávání a neúplných informací. To je slabé místo jak pro IT, tak pro management, který musí obhájit, že organizace reagovala přiměřeně a včas.
Proč jsou logy klíčové pro audit, incidenty a dohledatelnost
Logy nejsou „nice to have“. Jsou to základní provozní záznamy, ze kterých se skládá důkazní stopa. V kontextu NIS2 mají několik praktických funkcí najednou.
Audit a kontrola
Auditor nebo kontrolní orgán obvykle nechce slyšet, že „to máme nastavené“. Chce vidět:
- záznamy o přístupech,
- záznamy o změnách,
- historii relevantních bezpečnostních událostí,
- důkaz, že evidence existuje i zpětně,
- schopnost dohledat konkrétní situaci bez improvizace.
Bez logů lze doložit úmysl. S logy lze doložit skutečnost.
Incident response
Když organizace řeší bezpečnostní incident, potřebuje během krátké doby sestavit časovou osu, odhadnout rozsah a rozhodnout, koho informovat a jaká opatření přijmout. Pokud logy existují jen lokálně, bývá reakce pomalá, nepřesná a závislá na tom, zda napadené systémy ještě vůbec něco obsahují.
Interní šetření a provozní dohledatelnost
Logy nejsou důležité jen při velkém útoku. Pomáhají i při méně dramatických, ale provozně zásadních situacích:
- kdo změnil nastavení firewallu,
- kdo založil nebo povýšil účet,
- kdy byla vypnutá bezpečnostní funkce,
- z jakého systému přišla neobvyklá aktivita,
- zda šlo o chybu administrátora, nebo o kompromitaci.
Regulatorní obhajitelnost
Při hlášení incidentu nebo při následné kontrole organizace potřebuje ukázat, z čeho vycházela. Nejen co tvrdí, ale proč to tvrdí. Logy uložené mimo napadené systémy výrazně zvyšují důvěryhodnost takového vysvětlení.
Jaké typy logů firmy typicky potřebují
Základ obvykle nezačíná u „sbírejme všechno“, ale u několika prioritních vrstev.
Identita a přístupy
Sem patří Active Directory, Entra ID nebo jiný identitní systém, přihlášení, změny skupin, privilegované účty, MFA události a administrátorské zásahy. Pokud nevíte, kdo se kam přihlásil a kdo komu změnil oprávnění, bude slabá většina dalších vyšetřovacích scénářů.
Windows servery a vybrané endpointy
Ne každá stanice musí být první den součástí logovacího minima. Ale klíčové servery, jump hosty, management stanice nebo vysoce privilegovaná zařízení by v evidenci chybět neměly.
Firewally, VPN a síťové prvky
Přístup zvenčí, vzdálené připojení, komunikace mezi segmenty a podezřelý odchozí provoz často rozhodují o tom, zda organizace pochopí rozsah incidentu.
Hypervizory, NAS a appliance
Pokud je důležitý provoz postavený na virtualizaci nebo specializovaných boxech, potřebujete vědět i to, co se děje tam. Právě tato vrstva bývá při minimálním logování často přehlížená.
Cloud a SaaS
Řada organizací už nemá kritické systémy jen on-premise. Auditně relevantní mohou být i záznamy z M365, Google Workspace, cloudových platforem, ticketingu nebo identity providerů.
Praktický přehled priorit je na stránce Jaké logy potřebujete pro audit a NIS2.
Co je realistické minimum pro menší a střední organizaci
Pro většinu SMB a středních firem je vhodné začít minimem, které je skutečně provozovatelné. To minimum obvykle zahrnuje:
- centralizovaný sběr logů mimo zdrojové systémy,
- pokrytí identity, firewallů, VPN, klíčových serverů a vybraných cloudových služeb,
- základní retenční politiku odpovídající auditním a provozním potřebám,
- pravidelnou kontrolu, že sběr logů skutečně funguje,
- schopnost rychle dohledat události při interním šetření nebo incidentu.
Realistické minimum neznamená rezignaci. Znamená, že organizace staví první vrstvu tak, aby ji dokázala dlouhodobě udržet. Teprve na ní dává smysl přidávat širší pokrytí, korelace, alerting nebo pokročilejší analytiku.
Proč lokální logy nestačí
Tohle je jeden z nejdůležitějších praktických bodů celého tématu. Logy uložené jen lokálně v serveru, zařízení nebo aplikaci jsou při kompromitaci slabé místo.
Útočník se velmi často snaží:
- lokální logy změnit,
- smazat je,
- přepsat je dalším provozem,
- vypnout jejich generování,
- znepřístupnit napadený systém tak, že se k nim organizace nedostane včas.
Jestliže je důkazní stopa uložená mimo napadený systém, organizace výrazně snižuje riziko, že přijde o klíčové záznamy právě v momentu, kdy je nejvíc potřebuje. Centralizovaný sběr a uchování logů mimo zdrojové systémy proto není jen technická preference. Je to praktické opatření pro audit, šetření incidentů i regulatorní obhajitelnost.
Toto téma detailně rozebírá stránka Audit, dohledatelnost a důkazní stopa.
Jak logy souvisí s incident reportingem a časovou osou
NIS2 zvyšuje důraz na včasné hlášení významných incidentů. Už samotná směrnice pracuje s brzkým varováním do 24 hodin od okamžiku, kdy se organizace o významném incidentu dozví, a s incidentním oznámením do 72 hodin. Česká implementace navazuje vlastními procesy a formuláři.
V praxi to pro organizaci znamená, že v krátkém čase musí alespoň rámcově vědět:
- zda skutečně došlo k relevantnímu incidentu,
- co bylo zasažené,
- jaký může být provozní dopad,
- jaká je pravděpodobná časová osa,
- z jakých technických podkladů vychází první závěry.
Bez logů mimo napadené systémy se tento proces mění v odhadování. S centralizovanými logy má organizace šanci rychleji ověřit fakta, zpřesňovat obraz incidentu a obhájit, proč postupovala určitým způsobem.
Kdy dává smysl centralizovaný nebo SaaS přístup
Vlastní log management stack je validní cesta pro organizace, které mají tým, rozpočet i kapacitu na jeho provoz. Pro řadu středních firem ale bývá reálnější přístup:
- začít centralizací bez budování plného SIEM,
- držet důležitou evidenci mimo zdrojové systémy,
- snížit provozní náročnost interní platformy,
- postupovat po krocích místo velkého transformačního projektu.
SaaS model dává smysl hlavně tam, kde je cílem rychle získat použitelný základ pro auditní připravenost, incidenty a dohledatelnost bez budování komplexního interního stacku. Neznamená to, že každý musí jít do SaaS. Znamená to, že centralizace a retence logů může být dosažitelná i bez velkého bezpečnostního programu.
Oficiální zdroje a další čtení
Při orientaci v požadavcích je rozumné opírat se o oficiální zdroje a neřešit celé téma jen podle sekundárních článků.
Doporučené zdroje:
- směrnice NIS2 na EUR-Lex,
- oficiální stránky Evropské komise k NIS2,
- Portál NÚKIB k novému zákonu o kybernetické bezpečnosti,
- kalkulačka a podpůrné materiály NÚKIB pro orientační posouzení dopadu v českém prostředí.
Další navazující čtení v tomto hubu:
- Spadá vaše organizace pod NIS2?
- Nižší a vyšší režim NIS2
- NIS2 pro vedení firmy
- Audit, dohledatelnost a důkazní stopa
- Jaké logy potřebujete pro audit a NIS2
FAQ
Musíme kvůli NIS2 sbírat všechny logy ze všech systémů?
Ne. Většině organizací víc pomůže promyšlená priorita než nekontrolované sbírání všeho. Začněte u identit, klíčových serverů, firewallů, VPN, vybraných cloudových služeb a dalších systémů s vysokou auditní nebo incidentní hodnotou.
Znamená NIS2, že musíme koupit SIEM?
Ne automaticky. Potřebujete použitelnou evidenci, dohledatelnost a schopnost reagovat. U některých organizací to povede k SIEM, u jiných dává nejdřív smysl centralizovaný sběr a retence logů bez plnohodnotného SOC modelu.
Nestačí, že logy máme na serverech a v aplikacích?
Nestačí, pokud jsou jen lokálně. Při kompromitaci bývají právě lokální logy jedny z prvních záznamů, které útočník mění, maže nebo znepřístupní. Důkazní stopa mimo napadený systém je výrazně obhajitelnější.
Je to téma jen pro organizace, které už mají jistotu, že pod NIS2 spadají?
Ne. Stejné principy jsou důležité i pro firmy v dodavatelském řetězci regulovaných subjektů nebo pro organizace, které si zatím dělají interní první posouzení.
Kolik retence je správně?
Neexistuje jedno univerzální číslo platné pro každého. Retence se odvíjí od typu organizace, auditních potřeb, provozní reality a rizik. Důležité je, aby byla obhajitelná a aby logy byly v relevantním horizontu skutečně dostupné.
Další krok
Pokud si chcete ujasnit, kde začít:
- Stáhnout checklist pro první interní posouzení relevance NIS2 a stavu logování.
- Požádat o orientační konzultaci k tomu, jaké minimum dává smysl pro vaši organizaci.
- Přihlásit se k early access a novinkám k minimálnímu standardu centralizovaného logování pro audit a incidenty.