Průzkum z roku 2024 ukázal, že firmy bez dokumentovaného Business Continuity Plánu (BCP) trvá v průměru 3,5× déle dostat se po kybernetickém incidentu zpět do normálního provozu než organizace s BCP. Přitom tvorba BCP není nutně komplexní a drahý projekt — základní verzí lze pokrýt největší rizika i v menší firmě.
Tento článek vám vysvětlí klíčové koncepty, požadavky NIS2 a praktický postup pro vytvoření efektivního plánu kontinuity provozu se zaměřením na kybernetické hrozby.
BCP vs. DRP: Jaký je rozdíl a proč na tom záleží
Dva základní pojmy jsou často zaměňovány nebo splývají:
Business Continuity Plan (BCP)
BCP je strategický dokument popisující, jak organizace bude fungovat za narušených podmínek. Odpovídá na otázku: "Jak budeme podnikat, pokud naše normální způsoby fungování selžou?"
BCP zahrnuje:
- Identifikaci kritických obchodních procesů a jejich prioritizaci.
- Alternativní způsoby výkonu kritických procesů (manuálně, jiným systémem, jiným pracovištěm).
- Komunikační plán — kdo koho kontaktuje, jakými kanály.
- Role a odpovědnosti krizového týmu.
Disaster Recovery Plan (DRP)
DRP je technický dokument popisující, jak obnovit IT infrastrukturu a systémy po výpadku. Odpovídá na otázku: "Jak vrátíme IT systémy zpět do provozu?"
DRP zahrnuje:
- Postupy obnovy pro každý kritický systém.
- Zálohovací strategie a obnova dat.
- Failover postupy (přepnutí na záložní systémy).
- Testovací procedury.
Jednoduše: BCP říká, co firma bude dělat. DRP říká, jak technici obnoví systémy. Oboje je potřeba — DRP bez BCP vede k situaci, kde IT obnoví systémy, ale firma neví, jak mezitím fungovat. BCP bez DRP vede k situaci, kde firma ví, co chce dělat, ale nemá nástroje na obnovu.
RTO a RPO: Klíčové metriky pro kybernetické scénáře
Dvě nejdůležitější metriky v kontinuitě provozu:
RTO (Recovery Time Objective)
RTO je maximální přijatelná doba výpadku systému nebo procesu — tedy za jak dlouho musí být systém obnoven, aby nedošlo k nepřijatelným obchodním ztrátám.
Příklady:
- E-shop: RTO pro platební systém = 2 hodiny (každá hodina výpadku = přímá ztráta tržeb).
- Výrobní firma: RTO pro ERP systém = 24 hodin (výroba může dočasně fungovat manuálně).
- Nemocnice: RTO pro zdravotní IS = 30 minut (bezpečnost pacientů).
RPO (Recovery Point Objective)
RPO je maximální přijatelná ztráta dat — tedy jak stará data jsme ochotni obnovit ze zálohy, aniž by to způsobilo nepřijatelné problémy.
Příklady:
- E-shop: RPO pro objednávkový systém = 1 hodina (ztráta objednávek za více než hodinu je nepřijatelná).
- Účetnictví: RPO = 24 hodin (denní záloha postačuje).
- Finanční transakce: RPO = 0 (žádná ztráta dat — nutné synchronní replikace).
Jak stanovit RTO a RPO
Správné stanovení RTO a RPO vyžaduje Business Impact Analysis (BIA) — analýzu dopadu výpadku na obchodní procesy:
- Identifikujte kritické obchodní procesy a jejich závislosti na IT systémech.
- Kvantifikujte dopad výpadku v čase (finanční ztráta za hodinu, regulatorní riziko, reputační škoda).
- Stanovte maximální přijatelný dopad — to určuje RTO a RPO.
- Ověřte, zda existující zálohovací a recovery kapacity RTO a RPO splňují. Pokud ne, investujte do zlepšení nebo přijměte riziko vědomě.
NIS2 a požadavky na kontinuitu provozu
NIS2 směrnice v článku 21 explicitně požaduje implementaci opatření zahrnujících "kontinuitu provozu a krizový management". Konkrétně to zahrnuje:
- Zálohy a obnova dat: dokumentovaná zálohovací politika s definovanými RTO a RPO, pravidelné testování obnovy dat.
- Krizové řízení: definované postupy pro řízení kybernetických incidentů s jasnou eskalaní cestou a rozhodovacími pravomocemi.
- Redundance: "přiměřená redundance" kritických systémů a komunikačních prostředků.
- Dodavatelský řetězec: BCP musí zahrnovat scénáře výpadku klíčových dodavatelů (cloud provider, MSP, klíčový software).
Klíčové: NIS2 nežádá dokonalé plány — žádá přiměřené a dokumentované plány odpovídající rizikovému profilu organizace. Absence jakéhokoliv dokumentovaného přístupu je přímé porušení požadavků.
Kybernetické scénáře a jak je plánovat
Scénář 1: Ransomware útok
Nejčastější a nejničivější kybernetický scénář. BCP/DRP musí pokrývat:
- Izolaci zasažených systémů od sítě (a kdo to provede, jakými nástroji).
- Přepnutí na záložní komunikační kanály (firemní email může být kompromitován).
- Postup obnovy ze záloh — v jakém pořadí, jak dlouho to trvá (toto musíte vědět předem, ne hádat uprostřed incidentu).
- Alternativní způsoby výkonu kritických procesů po dobu obnovy (papírové záznamy, alternativní systémy).
- Hlášení NÚKIB a GDPR notifikace (s připravenými šablonami).
Scénář 2: DDoS útok na klíčové služby
DDoS útok může znepřístupnit webové stránky, online obchod nebo zákaznické portály. Plán musí obsahovat:
- Kontakt a postup aktivace DDoS mitigation služby (Cloudflare, Akamai, Radware) — předem sjednaná smlouva, ne hledání kontaktu uprostřed útoku.
- Komunikace zákazníkům o výpadku (připravená šablona na sociální sítě a email).
- Alternativní přijímání objednávek (telefon, email) po dobu výpadku.
Scénář 3: Výpadek klíčového cloud poskytovatele
Azure, AWS nebo Google Cloud mají i přes vysokou dostupnost výpadky. Pokud jste závislí na jednom cloudu, vaše RTO je závislé na cloud providera, ne na vás.
- Multi-cloud nebo hybrid strategie pro kritické systémy.
- Offline kopie klíčových dat pro nejkritičtější scénáře.
- Znalost SLA cloud providera a jejich komunikačních kanálů při incidentu.
- Alternativní přístupy k datům (lokální kopie nejkritičtějších dat).
Testování plánů: Proč je to nejdůležitější krok
Netesstovaný BCP/DRP je jen dokument, který vám nezaručí úspěšnou obnovu. Praxe ukázala, že plány, které nikdo nikdy nezkoušel, selhávají v reálných situacích z předvídatelných důvodů: zastaralé kontakty, neaktuální postupy, předpoklady, které nejsou pravdivé.
Typy testů (od nejjednodušších po nejnáročnější)
- Tabletop exercise (stolní cvičení): diskuse o scénáři v konferenční místnosti. Tým prochází plán krok za krokem, identifikuje mezery a otázky. Nízká nákladnost, lze dělat čtvrtletně.
- Walkthrough test: každý člen týmu popisuje své kroky při incidentu — ověření, zda každý zná svou roli. Odhalí mezery ve znalostech a odpovědnostech.
- Simulation test: simulace incidentu v testovacím prostředí, bez dopadu na produkci. Technici skutečně provádějí kroky obnovy, ale s testovacími daty a systémy.
- Full interruption test: reálné přepnutí na záložní systémy. Nejreálnější test, ale nejvyšší riziko a nákladnost. Vhodný pro kritickou infrastrukturu minimálně 1× ročně.
Co testovat prioritně
- Obnova dat ze záloh: zkuste skutečně obnovit zálohu a ověřte, že data jsou kompletní a konzistentní. Mnohé firmy zjistí, že zálohy jsou poškozené nebo neúplné, až když je potřebují.
- Komunikační plán: ověřte, že máte platné kontakty na klíčové osoby (NÚKIB, pojišťovna, IR firma, právník) mimo firemní systémy.
- Předání odpovědností: co se stane, pokud klíčová osoba není dostupná (dovolená, nemoc)?
Komunikace při incidentu: Kdo říká co a komu
Komunikace při kybernetickém incidentu je klíčová a nelze ji improvizovat. Špatná komunikace může způsobit reputační škody větší než samotný incident.
Připravte šablony předem pro:
- Interní zaměstnanci: co se stalo, co mají (ne)dělat, kdy dostanou více informací.
- Zákazníci: upřímné a faktické sdělení bez přehánění ani bagatelizování.
- Regulátoři (NÚKIB, ÚOOÚ): formální hlášení dle zákonných požadavků s připravenými šablonami.
- Média: konzistentní, stručná zpráva — media relations řeší vždy jedna určená osoba, nikoli IT.
- Obchodní partneři: informace o potenciálním dopadu na jejich systémy nebo data.
SecureOn.cz poskytuje komplexní podporu při tvorbě BCP a DRP pro kybernetické scénáře — od Business Impact Analysis přes tvorbu plánů po jejich testování a pravidelnou aktualizaci. Rádi vám pomůžeme splnit NIS2 požadavky na kontinuitu provozu a zároveň vytvořit plány, které skutečně fungují, ne jen existují na papíře.
Závěr: Plán, který leží v šuplíku, vás nezachrání
Business continuity plánování není byrokratické cvičení pro splnění auditu. Je to investice do odolnosti organizace, která se vrátí v prvním závažném incidentu. Klíčové poselství: plán musí být testovaný, aktualizovaný a znám lidem, kteří ho budou v krizi potřebovat.
Začněte tam, kde jste: i jednoduchý, jednostránkový postup pro ransomware scénář s kontakty, kroky izolace a postupem obnovy ze zálohy je lepší než žádný plán. Postupně ho rozšiřujte. Testujte ho. A doufejte, že ho nikdy nepotřebujete — ale buďte rádi, že ho máte, pokud nastane nejhorší.