Incident response plan, playbook a runbook:
Jak se vyznat v dokumentaci pro řízení incidentů

V prostředí řízení bezpečnostních incidentů se často zaměňují pojmy incident response plan, playbook a runbook. Přestože se tyto dokumenty vzájemně doplňují, liší se svým účelem, úrovní řízení i mírou detailu.

Cílem článku je vyjasnit, jak tyto pojmy používají mezinárodní standardy (ISO/IEC 27035, NIST SP 800-61 Rev. 3) a jak je vhodně propojit v praxi.

V mnoha organizacích se totiž tyto termíny používají nahodile a bez jednotného rámce, což vede k nejasnostem, zmatkům a neefektivní reakci při skutečných incidentech. Text zároveň ukazuje, jak vypadá typická struktura každého z těchto dokumentů a proč by automatizace nikdy neměla nahradit porozumění samotnému postupu.

V každé organizaci, která bere kybernetickou bezpečnost vážně, existuje nějaká forma reakce na incidenty. Někde se jí říká plán, jinde scénář nebo postup, ale jen málokdo přesně ví, kde končí incident response plan a kde začíná playbook či runbook. V praxi tak vzniká zvláštní směs strategií, checklistů a automatizovaných skriptů, které spolu často neladí. Tento text má vnést pořádek do pojmů, které se sice často používají, ale jen zřídka podle norem.

V praxi se pojmy incident response plan, playbook a runbook často používají společně, jako by tvořily jednotný rámec řízení incidentů. Ovšem standardy jako ISO/IEC 27035 hovoří výhradně o incident response planu a souvisejících postupech či procedurách, NIST SP 800-61r3 pak používá i pojem playbook, ovšem pojem runbook se v těchto dokumentech nevyskytuje vůbec.

Incident response plan (IRP)

Normy ISO/IEC 27035-1 a 27035-2 definují rámec řízení bezpečnostních incidentů, a to od přípravy až po zlepšování procesů. Hovoří výhradně o incident response plan, documented processes a procedures, tedy o strategickém a procesním řízení.

V žádné z částí ISO/IEC 27035 (ani ve verzi 2023) se neobjevují termíny playbook nebo runbook. Norma zůstává na úrovni procesů a odpovědností, nikoli konkrétních akčních kroků. Pro ISO tedy existuje pouze pojem incident response plan (IRP).

Playbook

Playbook představuje taktický plán reakce na konkrétní typ incidentu, například ransomware, phishing nebo insider threat. NIST SP 800-61 Rev. 3 z května 2025 pojem playbook výslovně používá a popisuje ho jako strukturovaný způsob, jak zvýšit použitelnost a opakovatelnost postupů.

Playbook určuje, v jakém pořadí a za jakých podmínek mají být jednotlivé kroky provedeny, kdo rozhoduje o dalším postupu a jaké jsou možné větve rozhodování. Na rozdíl od runbooku nepopisuje přesné technické akce, ale zaměřuje se na rozhodovací logiku a koordinaci týmu. CISA Cybersecurity Incident & Vulnerability Response Playbooks, který pak uvádí praktické příklady těchto scénářů v prostředí federálních institucí.

Runbook

Termín runbook se nevyskytuje ani v ISO/IEC 27035, ani v NIST SP 800-61. Runbook vznikl v praxi dodavatelů SOAR (Security Orchestration, Automation and Response) řešení, kde označuje soubor přesně definovaných technických kroků, které může provádět člověk nebo systém. Na rozdíl od playbooku se runbook nezabývá rozhodovací logikou, ale pouze provedením jednotlivých akcí.

Každý krok popisuje, co konkrétně udělat, kde a jak, např. izolovat zařízení v EDR, zablokovat IP adresu ve firewallu nebo obnovit účet v doméně. runbooky tvoří základ pro automatizaci v rámci SOAR nástrojů, ale musí být zároveň proveditelné i manuálně, pokud by automatizace selhala.

Normy vymezují rámec pouze částečně, neboť mluví o plánu a někdy o playboocích, ale zcela pomíjejí operativní rovinu, kterou praxe řeší prostřednictvím runbooků. Následující text proto představuje autorskou interpretaci toho, jak by měly být tyto tři vrstvy dokumentace propojeny a jak je lze prakticky vytvářet.

Co z toho vyplývá pro praxi

Pod IRP spadají playbooky a pod ně zase runbooky. V moderním SOC/SIEM/SOAR prostředí jsou runbooky často částečně či plně automatizované, zatímco playbooky drží rozhodovací logiku a návaznost kroků v čase. Rozdíly mezi těmito pojmy, tak jak je vnímá současná praxe, je možné zachytit v následující tabulce.

Playbooky a runbooky vznikly jako reakce na potřebu zrychlit a sjednotit reakce týmu během incidentů. Jejich cílem je snížit MTTR a minimalizovat závislost na individuálním úsudku jednotlivých analytiků. Otázka však je, do jaké míry detailně popisovat jednotlivé kroky a jak moc vše automatizovat.

Schvalování Runbooku by měl mít na starosti technický vedoucí nebo CSIRT Lead, cílem je zajistit, že popsaný postup je nejen funkční, ale i bezpečný a v souladu s interními politikami.

Kroky k vytvoření IRP:

• Definujte rámec a odpovědnosti: Ujasněte účel IRP, jeho rozsah, role a odpovědnosti jednotlivých členů týmu. Stanovte, kdy a kým je plán aktivován, jak se incident klasifikuje a jak probíhá eskalace.
• Popište proces reakce: Zpracujte základní fáze řízení incidentů – přípravu, detekci a analýzu, zabránění dalšímu šíření, odstranění příčin, obnovu a poučení se z incidentu. Ke každé fázi uveďte hlavní úkoly, vstupy, výstupy a komunikační toky.
• Propojte IRP s praxí: Doplňte vazby na krizové řízení, BCM/DRP, regulatorní povinnosti a odkazy na konkrétní playbooky a runbooky. Nastavte mechanismus pravidelné aktualizace a vyhodnocování účinnosti plánu.

Kroky k vytvoření playbooku:

• Začněte definováním bezpečnostního incidentu, který se má vyřešit.
• Pokračujete přes definování dílčích cílů každé jednotlivé fáze incident response, tj. čeho má být dosaženo formou předdefinovaných pracovních postupů.
• Definujte klíčové role k dosažení tohoto cíle a specifikujte jejich odpovědnosti, kdo, kdy, jak, koho má kontaktovat a co mu má sdělit.

Kroky k vytvoření runbooku:

• Identifikujte konkrétní úkol nebo proces, který je potřeba v rámci dosažení cíle uvedeného v playbooku udělat a přesně popište krok za krokem, který k němu vede.
• Napište, kam je třeba kliknout, co vybrat, co napsat na konzoli, jaké skripty je třeba ať už automatizovaně nebo manuálně spustit.
• Uveďte screenshoty obrazovek, ať vše jasné nenechává nikoho na pochybách.

Poznámka: IRP, playbook a runbook jsou de facto pracovní postupy, které musí někdo provést. Kvalitní playbook by měl být srozumitelný, jednoznačný a proveditelný bez nutnosti improvizace. Každý krok proto formulujte jako jednoduchý akční blok ve tvaru: kdo provádí jakou akci na čem a pomocí čeho. Pokud jej popíšeme jako stavební blok ve tvaru: <subjekt> provede <akci> na <objektu> pomocí < nástroje>, tak tento stavební blok popisuje, jak tým pro reakci nebo analytik <subjekt> provede speciální akci <akce> na souboru, účtu, IP adrese, haši, klíči registru atd. <objekt> pomocí systémů s funkcí pro provedení této akce < nástroj >. Tento způsob zápisu zvyšuje čitelnost i opakovatelnost a umožňuje snadný přechod k automatizaci (SOAR) bez ztráty srozumitelnosti pro člověka.

Vzhledem k tomu, že právě runbooky tvoří základ pro technickou realizaci a automatizaci kroků v rámci SOAR nástrojů, stojí za to zamyslet se nad tím, kde automatizace pomáhá, a kde už může být rizikem.

Automatizace ano, ale s rozumem

Automatizace v rámci SOAR a dalších bezpečnostních nástrojů je bezpochyby užitečná, neboť zrychluje reakci, snižuje chybovost a umožňuje lepší škálování. Je však nutné si uvědomit, že v případě skutečného bezpečnostního incidentu se může stát právě terčem útoku. Útočník typu APT může cíleně paralyzovat nebo kompromitovat samotné bezpečnostní nástroje, aby tým CSIRT zůstal slepý a ztratil schopnost reagovat.

Každý krok by proto mělo být možné provést i manuálně, a každý člen týmu by měl rozumět tomu, proč něco dělá, a ne jen slepě spouštět předem připravené skripty jako cvičená opice. Automatizace může významně urychlit rychlost reakce na incident, ale nemůže plně nahradit schopnost reagovat na nestandardní a neočekávané situace, kdy něco přestane fungovat apod. Z tohoto důvodu je třeba upozornit na:

• Nedostatek flexibility: Automatizované systémy se mohou obtížně přizpůsobovat nepředvídaným okolnostem, zatímco manuální zásah může na tuto situaci reagovat promptně.
• Složitost nastavení: Příprava runbooků a jejich integrace do automatizace vyžaduje značné počáteční úsilí, testování a validaci.
• Přílišné spoléhání se na automatizaci: Týmy se mohou stát závislými na automatizovaných procesech a zanedbat potřebu hlubšímu porozumění tomu, co dělají a nebudou pak schopni reagovat v neočekávaných situacích.

Příklad

Uveďme si, jak by mohly vypadat jednotlivé dokumenty:

• IRP: „Při potvrzené ransomware infekci Incident Manager aktivuje Ransomware playbook a svolá krizový tým.“
• Ransomware playbook: „Pokud jsou indikátory šifrování na >3 hostech, nasadit síťovou segmentaci; přejít na Runbook – EDR izolace hostu a runbook – Blokace IOC ve firewallu.“
• Runbook EDR izolace hostu: „V konzoli EDR otevři host → akce → isolate; ověř telemetrii; označ ticketem #INC-2025-001…“

Nejčastější chyby v organizacích

Obecně chybí detailní porozumění IHP a zmatek do toho trochu zanáší i rozdílné pojmenování jednotlivých fází v ISO, NIST. CMU/SEI a SANS, což je téma na samostatný článek. Dále se můžeme setkat s:

• Smíchání úrovní: IRP obsahuje technické kroky, které rychle zastarají; playbooky chybí.
• Chybějící rozhodovací body v playboocích: tým neví, kdy eskalovat/izolovat/komunikovat externě.
• Nesprávná údržba runbooků: po update EDR/FW postup nefunguje; automatizace nebyla otestována.
• Bez metrik: bez MTTD/MTTR a „lessons learned“ se artefakty nelepší a nereflektují realitu.

Závěr

Z analýzy norem jednoznačně vyplývá, že mezinárodní rámce v oblasti řízení incidentů nejsou v této terminologii jednotné. Z hlediska mezinárodních standardů existuje pouze IRP (v ISO/IEC 27035) a playbook (v NIST SP 800-61 Rev. 3 a CISA). Pojem runbook se do oblasti kybernetické bezpečnosti rozšířil primárně z IT operačních procesů a platforem pro orchestraci a automatizaci (SOAR) bez jasné definice. Výsledkem je, že nejeden manažer bezpečnosti tápe, co přesně má jeho organizace mít – plán, playbook, nebo runbook. Ve skutečnosti by měl mít incident response plan jako rámec, a z něj odvozené playbooky pro klíčové scénáře a pro ně pak zase runbooky. Všechny tři artefakty by měly být propojeny do cyklu neustálého zlepšování, kdy výstupy z lessons learned aktualizují nejen IRP, ale i příslušné playbooky a runbooky. Z praktického pohledu je proto vhodné uvažovat o třístupňové hierarchii dokumentace:

• Incident response plan (IRP) jako strategický rámec řízení incidentů,
• Playbook jako taktický scénář pro konkrétní typ hrozby,
• Runbook jako operativní návod pro přesné provedení jednotlivých kroků a to jak manuálně tak i automatizovaně.

Tento přístup přináší přehlednost, konzistenci a umožňuje efektivní využití automatizace bez ztráty kontroly nad procesem.

A jak jste na tom vy, jaké používáte SOAR nástroje a proč? Napište.

LITERATURA

ISO/IEC. ISO/IEC 27035-1:2023 – Information technology — Information security incident management — Part 1: Principles and process. Geneva: ISO, 2023. Online. Dostupné z: https://www.iso.org/standard/78973.html. [cit. 2025-10-09].

ISO/IEC. ISO/IEC 27035-2:2023 – Information technology — Information security incident management — Part 2: Guidelines to plan and prepare for incident response. Geneva: ISO, 2023. Online. Dostupné z: https://www.iso.org/standard/78974.html. [cit. 2025-10-09].

CICHONSKI, Paul; MILLAR, Tom; GRANCE, Tim; SCARFONE, Karen; MURPHY, Celia. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST Special Publication 800-61 Revision 3. Gaithersburg, MD: National Institute of Standards and Technology, 2025. DOI: https://doi.org/10.6028/NIST.SP.800-61r3. Online. Dostupné z: https://csrc.nist.gov/pubs/sp/800/61/r3/final. [cit. 2025-10-09].

CYBERSECURITY AND INFRASTRUCTURE SECURITY AGENCY (CISA). Cybersecurity Incident & Vulnerability Response Playbooks. Washington, D.C.: CISA, 2021. Online. Dostupné z: https://www.cisa.gov/resources-tools/resources/cybersecurity-incident-and-vulnerability-response-playbooks. [cit. 2025-10-09].

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!

Štítky: kybernetická bezpečnost