IRP, DRP, BCP a krize

Krizové plány často vypadají dobře, dokud je nikdo nemusí použít. Mají kapitoly, tabulky, kontakty, odpovědnosti i formální schválení. Jenže ve chvíli, kdy se incident začne měnit v krizi, rozhoduje něco úplně jiného: kdo má právo plán aktivovat, kdo má poslední slovo a podle čeho se určí priority.

Pokud krizový plán na tyto otázky neodpovídá, není to nástroj řízení. Je to jen další dokument, který uklidňuje organizaci přesně do okamžiku, kdy začne být opravdu potřeba.

Krizový plán, který neříká, kdo rozhodne, není krizový plán

Krizový plán, který nikdo neumí aktivovat, není krizový plán. Je to dokument pro audit. Možná hezky strukturovaný, možná formálně schválený, možná uložený přesně tam, kde má být. Ale ve chvíli, kdy organizace skutečně narazí, je jeho hodnota blízká nule. V tomto článku je krizový plán používán ve smyslu interní dokumentace pro krizové řízení organizace, nikoliv ve smyslu krizového plánu podle krizové legislativy veřejné správy.

Organizace dnes obvykle netrpí nedostatkem dokumentace. Naopak. Mají incident response plány, playbooky, runbooky, disaster recovery plány, business continuity plány, krizové plány, havarijní plány a k tomu několik tabulek s kontakty, které už půl roku nikdo neověřil.

Problém tedy většinou není v tom, že by žádný plán neexistoval. Problém je v tom, že není jasné, co který plán řeší, kdy se aktivuje, kdo za něj odpovídá a jak na sebe jednotlivé plány navazují.

Výsledek bývá předvídatelný. Incident se začne řídit jako krize. Krize se tváří jako eskalovaný incident. Disaster recovery se spustí příliš brzy, nebo naopak pozdě. Business continuity plán leží stranou, protože „tohle přece řeší IT“. A krizový plán se otevře až ve chvíli, kdy už organizace není v krizi, ale v chaosu.

Přitom právě rozdíl mezi IRP, DRP, BCP a krizovým plánem rozhoduje o tom, zda organizace dokáže reagovat řízeně, nebo jen improvizuje s profesionálně vypadající dokumentací v ruce.

Čtyři dokumenty, čtyři různé vrstvy problému

IRP, DRP, BCP a krizový plán nejsou čtyři názvy pro totéž. Jsou to čtyři různé vrstvy reakce. Každá řeší jiný typ problému, má jiný účel a má být aktivována v jiný okamžik.

IRP: jak zastavit incident

Incident Response Plan řeší první odbornou reakci na bezpečnostní nebo IT incident. Jeho úkolem není řídit firmu jako celek. Jeho úkolem je zjistit, co se stalo, omezit škody, izolovat problém a zabránit jeho dalšímu šíření. IRP odpovídá hlavně na otázky:

• co se stalo,
• které systémy, účty nebo služby jsou dotčené,
• jak incident zastavit nebo izolovat,
• kdo provádí odborné kroky,
• kdy a komu se incident eskaluje,
• jaké důkazy, logy a informace je nutné zachovat.

IRP je operativní dokument. V praxi na něj navazují playbooky a runbooky, které popisují konkrétní postupy pro konkrétní situace. Například kompromitovaný účet, malware, únik dat, podezřelou aktivitu v síti nebo ransomware.

Dobře napsaný IRP pomáhá týmu jednat rychle a disciplinovaně. Neřeší však reputaci, právní dopady, komunikaci s médii, vztah se zákazníky ani strategické rozhodnutí, zda zastavit část provozu. To už není incident response. To je řízení organizace.

DRP: jak obnovit technologie, systémy a data

Disaster Recovery Plan řeší obnovu technologií, systémů, infrastruktury a dat. Je to technicky orientovaný plán, který odpovídá na otázku, jak dostat IT prostředí zpět do použitelného stavu. DRP řeší zejména:

• které systémy se obnovují a v jakém pořadí,
• jaké jsou technické závislosti mezi systémy,
• kde jsou zálohy a jak se ověřuje jejich použitelnost,
• kdo má potřebné přístupy,
• jaké jsou cílové časy obnovy,
• jak se ověřuje, že obnovené prostředí je bezpečné a funkční.

DRP typicky navazuje na IRP. Nejdříve je potřeba incident zastavit, izolovat nebo alespoň stabilizovat. Teprve potom má smysl obnovovat. Obnovovat napadené systémy do prostředí, které stále ovládá útočník, není obnova. Je to jen dražší forma opakování stejné chyby.

DRP má vycházet z požadavků organizace na dostupnost služeb, systémů a dat. Tyto požadavky se obvykle odvozují z BIA, tedy z analýzy dopadů na podnikání. BIA neříká jen to, co je technicky důležité. Říká hlavně to, co je důležité pro fungování organizace.

Čím lépe je provedena BIA, tím snazší je určit priority obnovy. Bez ní se DRP často mění v technický seznam systémů, kde nejhlasitější vlastník aplikace vítězí nad skutečnou kritičností procesu.

BCP: jak udržet organizaci při životě

Business Continuity Plan neřeší primárně servery, databáze ani síťové prvky. Řeší kontinuitu kritických činností organizace. BCP odpovídá na otázku, co musí fungovat, aby organizace přežila i v omezeném režimu. Nejde o komfortní provoz. Jde o minimální přijatelný provoz. BCP stanovuje zejména:

• které procesy jsou kritické,
• jak dlouho mohou být nedostupné,
• jaká je minimální úroveň služby,
• jaké jsou alternativní postupy,
• kteří lidé, dodavatelé, informace a systémy jsou pro daný proces nezbytní,
• co se stane, pokud plná IT podpora není dostupná.

Zjednodušeně řečeno: IRP říká, jak zastavit problém. DRP říká, jak technicky obnovit systémy a data. BCP říká, co musí organizace udržet v chodu, aby se nezastavila jako celek.

BCP by nemělo být dokumentem IT. Aktivace kontinuity je manažerské rozhodnutí, protože se týká priorit organizace. IT může dodat technické možnosti, omezení a odhady. Nemá ale samo rozhodovat, které služby, zákazníci, procesy nebo závazky mají mít přednost.

Krizový plán: kdo rozhodne, když už nestačí postup

Krizový plán koordinuje rozhodování nad ostatními plány. Ne proto, že by byl důležitější na papíře, ale proto, že řeší jinou úroveň problému. Aktivuje se ve chvíli, kdy dopad události přestává být pouze technický, bezpečnostní nebo provozní a začíná ohrožovat organizaci jako celek. Krizový plán neodpovídá na otázku, jak obnovit databázi, jak izolovat server nebo jak přepnout provoz do záložního režimu. Od toho jsou jiné dokumenty. Krizový plán odpovídá na otázky:

• kdo může vyhlásit krizový režim,
• kdo má rozhodovací autoritu,
• podle čeho se určuje priorita,
• kdy se z incidentu stává krize,
• jak se koordinují odborné týmy, vedení a externí partneři,
• kdo komunikuje se zákazníky, médii, regulátory a dalšími stakeholdery,
• jak se řídí reputační, právní, finanční a strategické dopady.

Krizový plán je především rozhodovací a řídicí rámec. Pokud neříká, kdo má autoritu rozhodnout a podle jakých kritérií, není skutečnou oporou. Je to jen dobře upravený pocit falešného bezpečí.

Ransomware jako praktický příklad

Rozdíl mezi jednotlivými plány je dobře vidět na ransomwarovém útoku.

• IRP v první fázi řeší, co se stalo. Izoluje napadené systémy, analyzuje rozsah kompromitace, koordinuje technický a bezpečnostní tým, chrání důkazy, sbírá logy a stanovuje, zda a kdy je nutné incident eskalovat.
• DRP přichází ve chvíli, kdy má smysl obnovovat. Řeší zálohy, pořadí obnovy systémů, technické závislosti, kontrolu integrity dat a ověření, že obnovené prostředí není stále kompromitované.
• BCP mezitím říká, které procesy musí pokračovat i bez plné IT podpory. Určuje, zda lze některé činnosti provádět alternativně, jaká minimální úroveň služby je přijatelná a které procesy mají prioritu.
• Krizový plán drží pohromadě rozhodování celé organizace. Řeší, kdo má poslední slovo, jaké dopady jsou ještě přijatelné, kdy informovat zákazníky, kdy zapojit právníky, kdy komunikovat s regulátorem a jak chránit reputaci organizace.

Právě tady se často ukazuje, zda má organizace skutečný krizový plán, nebo jen několik dokumentů, které vypadají dobře, dokud se nic nestane.

Kde krizové plány obvykle selhávají

Největší slabinou krizových plánů nebývá jejich rozsah. Často mají desítky stran. Někdy dokonce stovky. Slabinou je, že vycházejí z předpokladu, že organizace bude během krize fungovat skoro stejně jako v běžném provozu. Jenže krize je právě okamžik, kdy tento předpoklad přestává platit.

Lidé nejsou dostupní. Informace jsou neúplné. Některé informace jsou rozporné. Technické týmy nemají jistotu. Vedení chce rozhodnout, ale nechce nést odpovědnost za špatné rozhodnutí. Dodavatelé nereagují. Zákazníci se ptají. Média mohou být rychlejší než interní komunikace. A do toho všichni doufají, že se najde někdo, kdo „to celé nějak vyřeší“. Typické slabiny krizových plánů vypadají nenápadně:

• není jasné, kdo může krizovou situaci vyhlásit,
• není jasné, kdo má poslední slovo,
• krizový tým nemá skutečnou autoritu,
• kontakty nejsou aktuální,
• plán počítá s lidmi, kteří už v organizaci nepracují,
• alternativní komunikační kanály nejsou otestované,
• rozhodnutí se odkládají na „jistotu“, která nikdy nepřijde,
• krizové řízení se zaměňuje za rozšířený incident management,
• není zajištěna zastupitelnost.

Poslední bod je zvlášť důležitý. Krize není jen větší incident. Krize je situace, kdy samotný odborný postup nestačí, protože rozhodnutí má dopady na celou organizaci. Čím je situace techničtější, tím více pomáhá postup. Čím je situace krizovější, tím více pomáhá jasná autorita. Checklist může pomoci. Ale checklist nerozhodne za vedení, jestli zastavit výrobu, informovat zákazníky, přiznat rozsah dopadu nebo obětovat část služeb kvůli ochraně zbytku organizace.

Moderní krizový plán nesmí stát na iluzi dokonalého scénáře

Staré krizové plány často stojí na představě, že lze dopředu popsat všechny důležité scénáře. Požár. Povodeň. Výpadek elektřiny. Kybernetický útok. Epidemie. Nedostupnost budovy. Výpadek dodavatele.

Scénáře mají smysl. Jsou užitečné pro testování, cvičení a přemýšlení o možných dopadech. Problém nastává ve chvíli, kdy organizace uvěří, že dobrý krizový plán je katalog předem připravených odpovědí na předem známé situace. Tak krize obvykle nevypadá. Skutečná krize často kombinuje několik dopadů najednou. Technický problém se rychle změní v provozní problém. Provozní problém v reputační problém. Reputační problém v právní problém. A právní problém v problém důvěry, který může organizaci bolet déle než samotný výpadek.

Moderní krizový plán proto nemá stát na snaze předvídat každý možný scénář. Má stát na typech dopadů, rozhodovacích pravomocích, prioritách a komunikačních pravidlech. Jinými slovy: nejde o to vědět předem všechno. Jde o to mít jasně určeno, kdo bude rozhodovat, podle čeho bude rozhodovat a jak se jeho rozhodnutí dostane k těm, kteří podle něj mají jednat.

Co má použitelný krizový plán skutečně obsahovat

Použitelný krizový plán nemusí být dlouhý. Musí být srozumitelný, aktuální a použitelný pod tlakem. To je mnohem vyšší laťka než vytvořit dokument, který projde auditem. Základní osnova krizového plánu by měla obsahovat alespoň tyto části:

• Účel a rozsah plánu – jaké situace plán řeší, kdy se aktivuje a kdy se naopak použijí jiné plány.
• Kritéria aktivace – podle čeho se pozná, že už nejde jen o incident, ale o krizovou situaci.
• Role a odpovědnosti – složení krizového týmu, náhradníci, kontakty, autorita a rozhodovací pravomoci.
• Rozhodovací rámec – pravidla pro stanovení priorit, eskalaci, zastavení škod, přijetí rizika a návrat do běžného režimu.
• Komunikační plán – komu, kdy, jak a co se komunikuje. Interně i externě.
• Alternativní kanály – jak bude organizace komunikovat při výpadku e-mailu, internetu, telefonu nebo běžných komunikačních nástrojů.
• Vazby na IRP, DRP a BCP – aby bylo jasné, jak se jednotlivé plány spouštějí, koordinují a ukončují.
• Návrat do běžného režimu – kdo rozhodne, že krize skončila, jak se předává řízení zpět do standardního provozu a jak se vyhodnotí poučení.
• Údržba a testování – kdo plán aktualizuje, jak často se ověřují kontakty a kdy se plán cvičí.

Do krizových plánů se přitom často nedostávají věci, které rozhodují o jejich použitelnosti. Například psychologická připravenost týmu, práce s panikou, identifikace single point of failure, předpřipravené komunikační šablony nebo trénink vedení a mluvčích pro komunikaci v krizovém režimu.

Právě tyto detaily rozhodují. Pokud krizový manažer nemá přístup do budovy, zasedací místnosti, záložního kanálu nebo klíčového systému, není to drobná nepříjemnost. Je to strukturální selhání přípravy.

Test použitelnosti krizového plánu

Skutečnou kvalitu krizového plánu lze poznat poměrně rychle. Stačí si položit několik nepříjemně jednoduchých otázek.

• Kdo může krizový plán aktivovat?
• Kdo má v krizi poslední slovo?
• Podle čeho poznáme, že už nejde o incident, ale o krizi?
• Jak budeme komunikovat, když nebude fungovat e-mail, Teams ani telefonní ústředna?
• Kdo rozhodne o prioritách, pokud nebude možné obnovit všechno najednou?
• Kdy jsme krizový plán naposledy opravdu otestovali?
• Co se při posledním testu ukázalo jako nefunkční?

Pokud odpovědi na tyto otázky začínají slovy „to bychom asi nějak vyřešili“, problém nezačne až při krizi. Ten problém už existuje.

Závěr

Krizový plán není dokument pro audit ani formální pojistka proti odpovědnosti. Je to nástroj, který má organizaci umožnit rozhodovat ve chvíli, kdy už neexistuje ideální řešení. IRP pomáhá zvládnout incident. DRP pomáhá obnovit technologie. BCP pomáhá udržet kritické činnosti. Krizový plán má zajistit, že se organizace v nejhorší chvíli nerozpadne na skupinu odborníků, manažerů a externích partnerů, kteří sice všichni něco dělají, ale nikdo ve skutečnosti neřídí celek. Pokud krizový plán nedává jasnou odpověď na otázku, kdo rozhodne a proč, pak nejde o krizový plán.

LITERATURA

ISO. ISO/IEC 27035-1:2023 Information technology — Information security incident management — Part 1: Principles and process. Geneva: International Organization for Standardization, 2023. Online. Dostupné z: https://www.iso.org/standard/78973.html. [cit. 2026-05-07].

ISO. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements. Geneva: International Organization for Standardization, 2019. Online. Dostupné z: https://www.iso.org/standard/75106.html. [cit. 2026-05-07].

NELSON, Alexander, Sanjay REKHI, Murugiah SOUPPAYA a Karen SCARFONE. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. Gaithersburg: National Institute of Standards and Technology, 2025. NIST SP 800-61 Rev. 3. Online. Dostupné z: https://doi.org/10.6028/NIST.SP.800-61r3. [cit. 2026-05-07].

SWANSON, Marianne, Pauline BOWEN, Amy PHILLIPS, Dean GALLUP a David LYNES. Contingency Planning Guide for Federal Information Systems. Gaithersburg: National Institute of Standards and Technology, 2010. NIST SP 800-34 Rev. 1. Online. Dostupné z: https://doi.org/10.6028/NIST.SP.800-34r1. [cit. 2026-05-07].

Pokud se vám líbí naše články, tak zvažte podporu naši práce – Naskenujte QR kód a přispějte libovolnou částkou.

Děkujeme!