GDPR / NIS28 min24. května 2026

Incident response cvičení: jak ověřit, že váš plán skutečně funguje

V březnu 2023 hit ransomware středně velký český výrobní podnik.

Autor: Splnit.eu, Redakce Splnit.eu

Co je tabletop cvičení a jak se liší od jiných testů

Svět incident response testování má několik úrovní:

Pro MSP a SaaS firmy je **tabletop cvičení** nejlepším poměrem nákladu a přínosu. Nepotřebuje specializované nástroje, nezasahuje do produkce a lze ho zvládnout interně s minimální přípravou.

**Co tabletop NENÍ:** tabletop není hodnocení zaměstnanců. Cílem je najít slabá místa systému — ne ukázat, kdo se připravil, a kdo ne. Toto musíte jasně sdělit na začátku cvičení.

Jak vybrat scénář: tři doporučené pro MSP

Typ testu	Popis	Náročnost
Tabletop cvičení	Strukturovaná diskuze nad fiktivním scénářem	Nízká
Walk-through	Detailní procházení plánu krok za krokem s týmem	Nízká–střední
Simulace	Technická simulace incidentu v izolovaném prostředí	Vysoká
Live fire / red team	Reálný útok v produkčním prostředí	Velmi vysoká

Scénář by měl být realistický pro vaše prostředí, dostatečně komplexní na to, aby testoval více aspektů plánu, ale ne tak technický, aby odstranil netechnické účastníky.

Scénář 1: Ransomware útok

**Kontext pro facilitátora:** Pondělní ráno, 7:45. První zaměstnanec, který přichází do kanceláře, se přihlásí na svůj počítač a uvidí zprávu: „Vaše soubory byly zašifrovány." Monitoring systému začíná alertovat na neobvyklé aktivity na fileserveru. Zákazníci hlásí, že SaaS platforma je nedostupná.

**Injekty (postupně přidávané informace):**

*Inject 1 (t+0):* Přijde alert z monitoringu. Fileserver vykazuje neobvyklou aktivitu — masivní čtení a zápis souborů. IT zjistí, že na třech serverech jsou soubory přejmenované s příponou `.locked`.

*Inject 2 (t+30 min):* Záložní server je také zasažen — ransomware měl přístup k zálohovacímu systému. Zálohy z posledních 3 dnů jsou zašifrovány. Nejstarší čistá záloha je stará 5 dní.

*Inject 3 (t+1 hod):* Útočníci tvrdí, že exfiltrovali zákaznická data (součástí útoku bylo i stažení dat před šifrováním). Požadují výkupné 50 000 EUR v BTC.

*Inject 4 (t+2 hod):* Velký zákazník volá CEO přímo a chce vědět, co se děje. Novinář z odborného media píše e-mail s dotazem.

**Klíčové otázky pro diskuzi:**

Kdo rozhoduje o izolaci systémů? Kdy?
Jak rychle zjistíme, která zákaznická data byla možná odcizena?
Platíme výkupné, nebo ne? Kdo rozhoduje?
Co říkáme zákazníkovi do 1 hodiny? Co do 24 hodin?
Musíme hlásit NÚKIB? Do kdy? Kdo to dělá?
Musíme hlásit ÚOOÚ? Do kdy? Kdo to dělá?
Jak obnovujeme provoz z čisté zálohy?

Scénář 2: Únik přihlašovacích údajů

**Kontext:** Ve středu odpoledne přijde automatický alert z threat intelligence systému: přihlašovací údaje ve formátu `jmeno@vasefirma.cz` se objevily v dark web databázi zkompromitovaných účtů. Jde o e-mail + heslo jednoho z vývojářů s přístupem do produkčního prostředí.

**Injekty:**

*Inject 1:* Přistoupíte k logům a zjistíte, že z tohoto účtu proběhlo přihlášení v neobvyklou dobu (2:47 v noci) z IP adresy v Rumunsku — 72 hodin zpátky.

*Inject 2:* Dotyčný vývojář tvrdí, že ve 2:47 spal a přihlášení neprovedl. Zkontrolujete jeho přístupy: má admin práva k produkční databázi zákazníků.

*Inject 3:* Logy produkční databáze ukazují, že v onom nočním přihlášení bylo spuštěno několik SELECT dotazů na tabulky zákazníků. Nevíte, zda, a co bylo staženo.

*Inject 4:* Zákazník vám hlásí, že k jeho účtu byl neoprávněný přístup z neznámé lokace.

**Klíčové otázky:**

Co uděláte jako první — změna hesla, nebo zachování přístupu pro forenzní analýzu?
Jak určíte, jaká data mohla být kompromitována?
Kdy musíte hlásit ÚOOÚ? Máte dost informací pro hlášení?

Scénář 3: Incident u cloudového poskytovatele

**Kontext:** V pátek večer pošle váš cloudový provider e-mail: „Zjistili jsme bezpečnostní incident v naší infrastruktuře. Provádíme šetření. Vaše data mohla být dotčena." Neposkytují žádné další detaily.

**Injekty:**

*Inject 1:* Provider uvede, že incident se týká části infrastruktury, kde jsou uložena zákaznická data. Nevyloučili únik dat.

*Inject 2:* Zákazníci začínají hlásit podezřelé aktivity ve svých účtech. Zdá se, že útočníci znají interní informace, které mohli získat jen z vašich systémů.

*Inject 3:* Provider potvrdí, že data z vašeho tenantuje mohla být přístupná neoprávněné straně po dobu 6 hodin.

**Klíčové otázky:**

Co řešíte sami a co čekáte od providera?
Kde jsou hranice vaší odpovědnosti vs. providera vůči zákazníkům?
Začíná 72hodinová lhůta GDPR od okamžiku, kdy vás provider informoval, nebo od okamžiku, kdy incident skutečně nastal?

Struktura cvičení (3 hodiny)

Část 1: Úvod (20 minut)

**Facilitátor vysvětlí:**

**Rozdejte materiály:**

Cíl cvičení: najít slabá místa v systému, ne hodnotit lidi
Pravidla: co padne v místnosti, zůstane v místnosti (pro otevřenou diskuzi)
Formát: facilitátor přidává informace (injekty), tým diskutuje, co by dělal
Vytištěný (nebo sdílený) incident response plán
Kontaktní seznam (NÚKIB, ÚOOÚ, forenzní firma, klíčoví zákazníci)
Zákonné lhůty (GDPR 72h, nZKB 24h) — jako quick reference card

Část 2: Scénář ve fázích (80 minut)

Facilitátor čte injekty postupně, s dostatečnými pauzami pro diskuzi. Po každém injektu se tým ptá:

**Facilitátor sleduje a zapisuje:**

Co víme? Co nevíme?
Co musíme udělat jako první?
Kdo to dělá?
Co říkáme — komu, kdy a jak?
Kdo se rozhoduje a na základě čeho
Jak dlouho trvá, než padne rozhodnutí
Kde nastávají nejasnosti nebo diskuze
Kde plan nevede jasně k akci
Chybějící informace, které tým potřeboval a neměl (kontakty, přístupy, dokumenty)

Část 3: Hot wash — debriefa (60 minut)

**Nejcennější část cvičení.** Facilitátor projde s týmem:

1. **Co fungovalo dobře?** (Začněte pozitivně — co plan zvládl, co tým věděl)
2. **Kde nastaly nejasnosti?** (Role, rozhodovací pravomoci, komunikační toky)
3. **Co v plánu chybí?** (Kontakty, postupy, šablony)
4. **Co jsme nevěděli, a potřebovali vědět?** (Přístupy k logům, zálohovací architektura, kontakty na NÚKIB/ÚOOÚ)
5. **Konkrétní akční body:** Co kdo udělá do kdy? Přiřaďte zodpovědnosti a termíny.

Část 4: Dokumentace (20 minut nebo po cvičení)

Sepište **zápis z cvičení:**

``` Datum: [datum] Účastníci: [seznam jmen a rolí] Scénář: [název a stručný popis] Klíčová zjištění:

Otevřené akční body:

Příští cvičení plánováno: [datum] ```

Tento dokument uschovejte. Je to váš důkaz pro auditory a zákazníky.

1. [zjištění]
2. [zjištění]
[akce] → zodpovídá [jméno] → do [datum]

Incident response cvičení: jak ověřit, že váš plán skutečně funguje

Co je tabletop cvičení a jak se liší od jiných testů

Proč tabletop právě teď — zákonné důvody

nZKB (zákon č. 264/2025 Sb.)

GDPR (Nařízení EU 2016/679)

Zákaznické audity

Kdo musí být u stolu

Nezbytní účastníci

Doporučení účastníci

Jak vybrat scénář: tři doporučené pro MSP

Scénář 1: Ransomware útok

Scénář 2: Únik přihlašovacích údajů

Scénář 3: Incident u cloudového poskytovatele

Struktura cvičení (3 hodiny)

Část 1: Úvod (20 minut)

Část 2: Scénář ve fázích (80 minut)

Část 3: Hot wash — debriefa (60 minut)

Část 4: Dokumentace (20 minut nebo po cvičení)

Nejčastější zjištění z tabletop cvičení

Jak zavést pravidelná cvičení

TL;DR

Splňte požadavky bez zbytečné byrokracie