Plán reakce na incidenty¶

Postupy detekce, reakce a obnovy po bezpečnostních incidentech MazeVault

ID dokumentů: MV-LEG-007
Verze: 1.0.0
Klasifikace: Důvěrné
Vlastník: Ředitel informační bezpečnosti (CISO)
Poslední aktualizace: 2026-05-01
Cyklus revize: Roční (a po každém významném incidentů)
Schválil: CEO / Představenstvo
Regulatorní základ: Zákon č. 264/2025 Sb. §15, Směrnice NIS2 čl. 23, DORA čl. 17-19, ISO/IEC 27001:2022 A.16

1. Účel a rozsah¶

1.1 Účel¶

Tento Plán reakce na incidenty stanoví formální postupy pro detekci, hlášení, reakci, obnovu a poučení z bezpečnostních incidentů ovlivňujících systémy, služby a zákaznická data MazeVault. Plán zajišťuje koordinovanou, efektivní a právně souladnou reakci na všechny bezpečnostní události.

1.2 Rozsah¶

Tento plán se vztahuje na:

Všechny bezpečnostní incidenty ovlivňující platformu, infrastrukturu a služby MazeVault
Veškerá zákaznická data zpracovávaná, uchovávaná nebo přenášená systémy MazeVault
Veškerý personál MazeVault, dodavatele a poskytovatele služeb třetích stran
Všechna prostředí: produkční (PRO), neprodukční (NPR), vývojové a testovací
Všechny modely nasazení: cloudové, on-premise brány a hybridní konfigurace

1.3 Definice¶

Pojem	Definice
Bezpečnostní událost	Jakýkoli pozorovatelný výskyt v systému nebo síti naznačující porušení bezpečnostní politiky
Bezpečnostní incident	Potvrzená bezpečnostní událost ohrožující důvěrnost, integritu nebo dostupnost informačních aktiv
Porušení zabezpečení dat	Incident vedoucí k neoprávněnému přístupu k osobním údajům nebo zákaznickým tajemstvím
Tým reakce na incidenty (IRT)	Určená skupina odpovědná za řízení reakce na incidenty
Velitel incidentů (IC)	Osoba s celkovou pravomocí a odpovědností během incidentů

2. Klasifikace incidentů¶

2.1 Matice klasifikace závažnosti¶

Závažnost	Popis	Příklady	Počáteční doba reakce	Eskalace
Kritická (P1)	Bezprostřední nebo potvrzená kompromitace zákaznických dat, úplná nedostupnost služby nebo aktivní zneužívání	Únik dat, RCE, obejití autentizace, expozice zákaznických klíčů/tajemství, nasazení ransomware	Okamžitě (do 15 min)	CISO + CEO okamžitě
Vysoká (P2)	Významné zhoršení bezpečnosti, eskalace oprávnění nebo zásadní dopad na dostupnost bez potvrzené ztráty dat	Eskalace oprávnění, významný DoS ovlivňující SLA, neoprávněný admin přístup	Do 1 hodiny	CISO do 30 min
Střední (P3)	Omezené zveřejnění informací, lokalizovaný DoS nebo degradované bezpečnostní kontroly	Omezené zveřejnění, lokální DoS, neúspěšné pokusy o exploitaci s částečným úspěchem	Do 4 hodin	Vedoucí bezpečnostního týmu
Nízká (P4)	Menší bezpečnostní obavy, průzkumná aktivita	Skenování portů, menší únik informací, phishing (bez kompromitace)	Do 24 hodin	Další pracovní den

2.2 Klasifikace dopadů¶

Dimenze	Vysoký	Střední	Nízký
Důvěrnost	Zákaznická tajemství, šifrovací klíče nebo osobní údaje exponovány	Interní systémová data exponována; žádná zákaznická tajemství	Informace minimální citlivosti
Integrita	Zákaznická data upravena, auditní logy manipulovány	Systémová konfigurace změněna; bez přímého dopadů na zákaznická data	Menší nekonzistence
Dostupnost	Úplný výpadek služby nebo degradace kapacity > 50%	Degradovaný výkon nebo částečné narušení; workaroundy dostupné	Minimální dopad

2.3 Spouštěč regulatorní klasifikace¶

Incident BUDE klasifikován jako hlásitelný regulatorním orgánům při splnění některé z podmínek:

Potvrzený neoprávněný přístup k osobním údajům zákazníků (GDPR čl. 33)
Významný dopad na poskytování základní služby (NIS2 čl. 23)
Závažný ICT incident ovlivňující zákazníky finančních subjektů (DORA čl. 19)
Incident splňující kritéria zákona č. 264/2025 Sb. §15

3. Tým reakce na incidenty (IRT)¶

3.1 Složení a role týmu¶

Role	Primární odpovědnost	Zástupce
Velitel incidentů (IC) - CISO	Celková koordinace, rozhodování o regulatorní komunikaci, eskalační autorita	CTO
Technický vedoucí - CTO / Sr. Engineer	Technické vyšetřování, provedení izolace, sběr forenzních důkazů	Senior Platform Engineer
Vedoucí komunikace	Interní komunikace, zákaznické notifikace, koordinace s médii, status page	Head of Customer Success
Právní poradce	Posouzení regulatorních oznámení, soulad s právními povinnostmi	Externí právní poradce
Zákaznické vztahy	Komunikace se zákazníky, posouzení dopadů na zákazníka	Account Management Lead
Vedoucí provozu	Infrastrukturní akce, záloha/obnova, monitoring systému	DevOps Engineer

3.2 Matice eskalace¶

Úroveň 1: Bezpečnostní operace (on-call inženýr)
    - [P3/P4 potvrzeno nebo P2/P1 podezření]
Úroveň 2: Vedoucí bezpečnostního týmu + Technický vedoucí
    - [P2 potvrzeno nebo P1 podezření]
Úroveň 3: CISO (Velitel incidentů) + Plná aktivace IRT
    - [P1 potvrzeno nebo vyžadováno regulatorní oznámení]
Úroveň 4: CEO + Oznámení představenstvu + Externí poradce

3.3 Kontakt a dostupnost¶

Velitel incidentů a Technický vedoucí BUDOU dosažitelní 24/7/365.
Všichni členové IRT POTVRDÍ aktivaci do 15 minut v pracovní době a 30 minut mimo pracovní dobu.

3.4 Pravomoci¶

Velitel incidentů je oprávněn:

Vypnout jakýkoli systém nebo službu pro izolaci incidentů
Revokovat jakékoli přístupové údaje nebo certifikáty
Angažovat externí forenzní specialisty
Autorizovat nouzové změny bez standardního schvalování
Komunikovat s regulatorními orgány jménem MazeVault

4. Mechanismy detekce¶

4.1 Automatická detekce¶

4.1.1 AnomalyDetectionService¶

Sledování přístupových vzorů: Vytváří baseline chování pro každého uživatele a zařízení
Detekce odchylek: Spouští upozornění při překročení prahových hodnot
Riziková skóre: Přiřazuje dynamická riziková skóre relacím
Integrace: Vstup do ZeroTrustService pro rozhodnutí o vynucení

4.1.2 ZeroTrustService¶

Detekce nedůvěryhodných zařízení: Identifikuje zařízení nesplňující bezpečnostní požadavky
Řízení přístupu ke kritickým zdrojům: Blokuje přístup z nedůvěryhodných kontextů
Ukončení relace: Automaticky ukončí podezřelé relace
Generování upozornění: Vytváří bezpečnostní události pro vyšetřování

4.1.3 Detekční pravidla SIEM¶

Sedmnáct (17) detekčních pravidel pokrývajících následující kategorie hrozeb:

Kategorie pravidel	Detekční scénář	Závažnost upozornění
Autentizace	Hrubá síla (> 10 selhání za 5 min)	Vysoká
Autentizace	Credential stuffing (distribuovaná selhání)	Vysoká
Autentizace	Nemožné cestování	Kritická
Autorizace	Eskalace oprávnění	Kritická
Exfiltrace dat	Hromadný export (> 100 tajemství za 1 hodinu)	Kritická
Exfiltrace dat	Neobvyklý objem stahování (> 3x baseline)	Vysoká
Provozní	Masové odvolání (> 50 certifikátů za 1 hodinu)	Vysoká
Provozní	Masové mazání tajemství (> 20 za 30 min)	Kritická
Infrastruktura	Neoprávněná změna konfigurace	Vysoká
Síť	Indikátory laterálního pohybu	Kritická
Síť	Vzory komunikace C2	Kritická
Dostupnost	Detekce vzoru DDoS (> 10x normální provoz)	Vysoká
Soulad	Mezera v auditním logu (> 5 min bez očekávaných záznamů)	Vysoká
Soulad	Detekce manipulace (selhání validace hash řetězce)	Kritická
Kryptografické	Anomálie použití klíče (operace podpisu mimo okno údržby)	Vysoká

4.1.4 GatewayHealthMonitor¶

Heartbeat monitoring: Timeout práh 2 minuty
Práh selhání: 3 po sobě jdoucí zmeškané heartbeaty spustí upozornění a failover
Interval health checku: Každých 30 sekund

4.1.5 Prometheus Alerting¶

Monitoring infrastrukturních metrik (CPU, paměť, disk, síť)
Aplikační metriky (latence požadavků, chybovost)
Upozornění na prahové hodnoty SLA
Varování o expiraci certifikátů (30, 14, 7, 3, 1 den)

4.2 Manuální detekce¶

Zdroj	Proces
Zákaznické hlášení	Přes support kanály; eskalace na bezpečnost při indikátorech incidentů
Hlášení zaměstnanců	Interní kanál (info@mazevault.com)
Oznámení třetích stran	Výzkumníci zranitelností, CERT týmy, partneři, orgány činné v trestním řízení
Auditní zjištění	Interní nebo externí audit identifikuje selhání kontrol
Zpravodajství o hrozbách	Varování NÚKIB, doporučení výrobců, odvětvové zprávy

5. Fáze reakce¶

5.1 Fáze 1: Detekce a triage¶

Cíl: Potvrdit incident, posoudit počáteční závažnost a aktivovat zdroje reakce.

Akce:

Validovat upozornění: Potvrdit, že se jedná o skutečný incident
Přiřadit ID incidentů: Formát INC-YYYY-MMDD-NNN
Klasifikovat závažnost: Aplikovat matici klasifikace (oddíl 2)
Posoudit rozsah: Určit postižené systémy, data, zákazníky
Aktivovat IRT: Oznámit dle matice eskalace (oddíl 3.2)
Inicializovat záznam incidentů: Vytvořit formální záznam
Zachovat počáteční důkazy: Zajistit pokračování logování
Určit regulatorní povinnosti: Posoudit dosažení oznamovacích prahů (oddíl 6)

Časový rámec: Triage BUDE dokončen do 30 minut pro P1/P2 incidenty.

5.2 Fáze 2: Izolace¶

5.2.1 Krátkodobá izolace (okamžitá)¶

Izolovat postižené systémy: Segmentace sítě, odpojení kompromitovaných bran
Revokovat kompromitované přihlašovací údaje: Zneplatnit tokeny, API klíče, relace, certifikáty
Blokovat škodlivé zdroje: Blokování IP, geo-blokování, aktualizace firewall pravidel
Zablokovat kompromitované účty: Zamknout uživatelské účty
Aktivovat zvýšený monitoring: Zvýšit verbozitu logování, snížit prahy upozornění

5.2.2 Dlouhodobá izolace¶

Aplikovat nouzové záplaty: Nasadit opravy zneužívaných zranitelností
Rekonfigurovat postižené systémy: Zpřísnit konfigurace, rotovat tajemství
Implementovat další kontroly: Nasadit nová detekční pravidla
Rotovat šifrovací klíče: Při podezření na kompromitaci klíčů

Rozhodovací brána: Velitel incidentů musí schválit přechod z izolace do eradikace.

5.3 Fáze 3: Eradikace¶

Cíl: Odstranit kořenovou příčinu a ověřit nepřítomnost persistenčních mechanismů.

Akce:

Identifikovat kořenovou příčinu: Dokončit forenzní analýzu
Odstranit škodlivé artefakty: Smazat malware, backdoory, neoprávněné účty
Záplatovat zranitelností: Aplikovat trvalé opravy
Ověřit čistý stav: Skenovat postižené systémy; validovat integritu
Ověřit nepřítomnost laterálního pohybu: Potvrdit, že útok se nerozšířil
Aktualizovat detekční pravidla: Přidat signatury z incidentů
Validovat integritu auditních logů: Ověřit řetězový hash

5.4 Fáze 4: Obnova¶

Cíl: Obnovit postižené systémy do plného provozního stavu.

Akce:

Obnovit z ověřených záloh: Pokud nelze potvrdit integritu systému
Ověřit integritu dat: Porovnat s kontrolními součty záloh
Postupná obnova služby: Systémy obnovit inkrementálně s monitoringem anomálií
Ověřit bezpečnostní kontroly: Potvrdit funkčnost ZeroTrust, AnomalyDetection, SIEM
Monitorovat recidivu: Udržovat zvýšený monitoring minimálně 72 hodin po obnově
Potvrdit obnovení SLA: Ověřit výkon systému vůči SLA
Komunikace se zákazníky: Oznámit obnovu služby a případné nutné akce

Rozhodovací brána: Velitel incidentů autorizuje přechod do post-incidentní fáze po potvrzení stability systémů po dobu min. 24 hodin.

5.5 Fáze 5: Post-incidentní¶

Cíl: Poučení z incidentů, zlepšení procesů, splnění zbývajících povinností.

Akce:

Provést post-incidentní revizi (PIR): Bezúhonná retrospektiva do 5 pracovních dnů
Zdokumentovat poučení: Co fungovalo dobře, co zlepšit
Aktualizovat politiky a postupy: Revidovat tento plán a další dokumenty
Implementovat preventivní opatření: Řešit kořenovou příčinu
Podat závěrečné regulatorní zprávy: Dokončit všechny požadované zprávy (oddíl 6)
Aktualizovat registr rizik: Promítnout nová rizika
Informovat zainteresované strany: Poskytnout exekutivní souhrn vedení
Uzavřít záznam incidentů: Formálně uzavřít s kompletní dokumentací

6. Požadavky na regulatorní oznámení¶

6.1 Matice oznamovacích lhůt¶

Orgán / Příjemce	Spouštěč	Počáteční oznámení	Průběžná zpráva	Závěrečná zpráva	Metoda
NÚKIB (dle zákona č. 264/2025 Sb. §15)	Významný bezpečnostní incident	Do 24 hodin od detekce	Do 72 hodin	Do 1 měsíce od uzavření	Elektronický portál NÚKIB (ESVZ)
Oznámení zákazníkům	Incident přímo ovlivňující zákaznická data	Okamžitě pro Kritické (P1); do 24 hodin pro Vysoké (P2)	Průběžné aktualizace	Závěrečný souhrn	E-mail + notifikace v platformě + status page
GDPR - ÚOOÚ (čl. 33)	Porušení zabezpečení osobních údajů	Do 72 hodin od zjištění	Dle dostupnosti informací	Po dokončení vyšetřování	Elektronický formulář úřadu
GDPR - Subjekty údajů (čl. 34)	Porušení s vysokým rizikem pro práva subjektů	Bez zbytečného odkladu	N/A	N/A	Přímá komunikace
DORA - Příslušný orgán (čl. 19)	Závažný ICT incident (zákazníci finančního sektoru)	Do 4 hodin od klasifikace	Do 72 hodin	Do 1 měsíce	Regulatorní kanál
ČNB	Incident ovlivňující zákazníky regulovaných finančních subjektů	Podpora zákaznického hlášení	Průběžná podpora	Závěrečná technická zpráva	Přes zákazníka; přímo na vyžádání
Orgány činné v trestním řízení	Důkazy trestné činnosti	Dle pokynu právního poradce	Na vyžádání	Na vyžádání	Přímý kontakt

6.2 Kritické lhůty¶

T+0          Incident detekován
T+15 min     P1 triage dokončen, IRT aktivován
T+4 hodiny   DORA počáteční oznámení (pokud aplikovatelné) - POVINNÉ
T+24 hodin   NÚKIB počáteční oznámení - POVINNÉ
T+72 hodin   GDPR oznámení ÚOOÚ - POVINNÉ
T+72 hodin   Průběžné zprávy (NÚKIB, DORA)
T+1 měsíc    Závěrečné zprávy (NÚKIB, DORA)

KRITICKÉ: Nesplnění 24hodinového požadavku na hlášení NÚKIB nebo 4hodinového počátečního oznámení DORA představuje regulatorní porušení a může vést k administrativním sankcím. Velitel incidentů ZAJISTÍ včasné oznámení i v případě, že plné podrobnosti incidentů dosud nejsou k dispozici.

6.3 Autorita pro rozhodování o oznámení¶

Oznámení NÚKIB: Autorizuje Velitel incidentů (CISO) nebo CEO
Oznámení ÚOOÚ (GDPR): Autorizuje Pověřenec pro ochranu údajů (DPO)
Oznámení DORA: Autorizuje Velitel incidentů s potvrzením právního poradce
Oznámení zákazníkům: Autorizuje Velitel incidentů; obsah schválen Vedoucím komunikace a právním poradcem
Kontakt s orgány činnými v trestním řízení: Autorizuje výhradně právní poradce a CEO

7. Komunikační šablony¶

7.1 Šablona interní eskalace¶

Předmět: [ZÁVAŽNOST] Bezpečnostní incident - INC-YYYY-MMDD-NNN

SOUHRN INCIDENTU
- ID incidentů: [INC-YYYY-MMDD-NNN]
- Závažnost: [Kritická / Vysoká / Střední / Nízká]
- Detekován: [Časová značka UTC]
- Metoda detekce: [Automatická/Manuální - podrobnosti]
- Postižené systémy: [Seznam]
- Postižení zákazníci: [Počet / "Vyšetřuje se"]
- Aktuální status: [Detekován / Vyšetřován / Izolován / Vyřešen]

POČÁTEČNÍ POSOUZENÍ
- Popis: [Stručný popis incidentů]
- Předpokládaný dopad: [Důvěrnost / Integrita / Dostupnost]

PROVEDENÉ OKAMŽITÉ AKCE
- [Akce 1]
- [Akce 2]

DALŠÍ AKTUALIZACE: [Časová značka nebo "Do X hodin"]
Velitel incidentů: [Jméno]

7.2 Šablona oznámení zákazníkům¶

Předmět: Bezpečnostní oznámení - Vyžadována akce / Pro vaši informací

Vážený [Zákazníku],

informujeme Vás o bezpečnostním incidentů, který [může ovlivnit / ovlivnil]
Vaše prostředí MazeVault.

CO SE STALO
[Faktický popis]

JAKÉ INFORMACE BYLY DOTČENY
[Typy dat]

CO DĚLÁME
[Akce provedené a plánované]

CO BYSTE MĚLI UDĚLAT
[Konkrétní doporučené akce]

Pro dotazy: [Kontakt na podporu]
Další aktualizace: [Datum/čas]

Bezpečnostní tým MazeVault

7.3 Šablona regulatorního oznámení (formát portálu NÚKIB)¶

OZNÁMENÍ BEZPEČNOSTNÍHO INCIDENTU

1. OZNAMUJÍCÍ SUBJEKT
   - Organizace: MazeVault s.r.o.
   - IČO: [Registrační číslo]
   - Kontaktní osoba: [Jméno CISO]

2. IDENTIFIKACE INCIDENTU
   - Interní reference: [INC-YYYY-MMDD-NNN]
   - Datum/čas detekce: [ISO 8601]
   - Soulad s oznamovací lhůtou: [Ano - do 24h / Vysvětlení]

3. POPIS INCIDENTU
   - Kategorie: [Neoprávněný přístup / Únik dat / DoS / Malware / Jiné]
   - Postižená služba: MazeVault platforma správy tajemství
   - Popis: [Faktický souhrn]

4. POSOUZENÍ DOPADU
   - Postižené systémy: [Seznam]
   - Postižení uživatelé/zákazníci: [Počet]
   - Přeshraniční dopad: [Ano/Ne]

5. PROVEDENÉ AKCE
   - Izolace: [Implementovaná opatření]
   - Mitigace: [Kroky ke snížení dopadů]
   - Obnova: [Status a harmonogram]

Status: [Počáteční / Průběžná / Závěrečná]

8. Zachování důkazů¶

8.1 Principy¶

Integrita: Důkazy nesmí být změněny během sběru nebo uložení
Řetězec úschovy: Kompletní dokumentace přístupu k důkazům
Přípustnost: Metody sběru musí podporovat případná právní řízení
Úplnost: Všechny relevantní typy důkazů musí být sebrány
Včasnost: Důkazy musí být sebrány před přepsáním nebo expirací

8.2 Typy důkazů a sběr¶

Typ důkazu	Metoda sběru	Priorita	Retence
Auditní logy	Řetězově hashované, tamper-evident logy z AuditService	Kritická	Minimálně 3 roky
Systémové logy	Export z centralizované agregace (strukturované JSON)	Kritická	Minimálně 3 roky
Aplikační logy	Export ze systému správy logů	Vysoká	Minimálně 3 roky
Síťové zachycení	PCAP z postižených segmentů	Vysoká	Doba vyšetřování + 1 rok
Dumpy paměti	Živé zachycení paměti	Střední	Doba vyšetřování + 1 rok
Obrazy disků	Forenzní obraz (bit-for-bit kopie)	Vysoká	Doba vyšetřování + 3 roky
Konfigurační snapshoty	Konfigurace systému v čase incidentů	Vysoká	Minimálně 3 roky
Autentizační logy	Všechny auth události pro postižené účty	Kritická	Minimálně 3 roky
SIEM upozornění/korelace	Kompletní řetězec upozornění	Kritická	Minimálně 3 roky

8.3 Integrita řetězově hashovaných auditních logů¶

Každá auditní událost obsahuje hash předchozí události vytváření neměnného řetězce
Jakákoli úprava historických logových záznamů přeruší hash řetězec a je okamžitě detekovatelná
Slouží jako autoritativní důkaz systémové aktivity během incidentů

8.4 Požadavky na řetězec úschovy¶

Pro každý sebraný důkaz:

Označení: Jedinečný identifikátor důkazu vázaný na ID incidentů
Záznam: Datum/čas sběru, identita sběratele, metoda sběru
Bezpečné uložení: Přístupově kontrolované, integritně chráněné úložiště
Log přístupu: Veškerý přístup k důkazům logován
Záznamy o přenosu: Přenosy mezi stranami dokumentovány a podepsány
Ověření integrity: Hash hodnoty vypočteny při sběru a ověřovány při každém přístupu

8.5 Retence důkazů¶

Minimální doba retence: 3 roky od uzavření incidentů
Prodloužená retence: Při zahájení nebo očekávání právních řízení
Regulatorní požadavky: Důkazy pro DORA minimálně 5 let
Likvidace: Vyžaduje schválení Velitele incidentů a BUDE zdokumentována

9. Služba oznamování incidentů¶

9.1 Technická implementace¶

IncidentService poskytuje automatizovanou správu životního cyklu incidentů:

9.1.1 Vytvoření a oznámení incidentů¶

Při vytvoření bezpečnostního incidentů:

Generován jedinečný identifikátor
Automatická oznámení na všechny aktivní kanály:
E-mail: Distribuční list IRT
Slack: Kanál bezpečnostních incidentů
Microsoft Teams: Kanál bezpečnostního provozu
Jira: Tiket incidentů vytvořen s prioritou
Webhook: HTTP POST na konfigurované endpointy (SIEM, SOAR)
Logována auditní událost INCIDENT_DETECTED
Status nastaven na open

9.1.2 Životní cyklus statusu¶

open - investigating - contained - resolved - closed

Status	Popis	Spouštěč
`open`	Incident detekován, čeká na triage	Automaticky při vytvoření
`investigating`	IRT aktivně analyzuje a reaguje	Manuálně: IC potvrdí dokončení triage
`contained`	Aktivní hrozba neutralizována	Manuálně: IC potvrdí izolaci
`resolved`	Kořenová příčina odstraněna	Manuálně: IC potvrdí obnovu
`closed`	Post-incident dokončen, vše odesláno	Manuálně: IC finální sign-off

10. Testování a cvičení¶

10.1 Program cvičení¶

Typ cvičení	Frekvence	Rozsah	Účastníci
Stolní cvičení	Pololetně	Scénářová diskuze; nácvik rozhodování	Celý IRT + vedení
Simulační cvičení	Ročně	Realistický simulovaný incident; end-to-end validace	Celý IRT + provoz
DR failover testy	Čtvrtletně	Technické postupy obnovy; failover bran, obnova databáze	Provoz + infrastruktura
Testy komunikace	Čtvrtletně	Ověření funkčnosti notifikačních kanálů	Vedoucí komunikace + IRT
Post-incident revize	Po každém P1/P2	Komplexní revize skutečné reakce	Všichni zúčastnění

10.2 Požadavky na cvičení¶

Všechna cvičení BUDOU mít definované cíle, scénáře a kritéria úspěchu
Výsledky BUDOU zdokumentovány včetně identifikovaných mezer
Akce ke zlepšení BUDOU sledovány s přiřazenými vlastníky a termíny
Minimálně jedno roční cvičení BUDE zahrnovat simulaci regulatorního oznámení

10.3 Minimální scénáře cvičení¶

Únik zákaznických dat přes zneužitou zranitelnost
Ransomware útok na produkční databázi
Insider threat: privilegovaný uživatel exfiltrující tajemství
Kompromitace dodavatelského řetězce přes kompromitovanou závislost
Kompromitace brány a pokus o laterální pohyb
Kompromitace šifrovacího klíče vyžadující nouzovou rotaci

11. Metriky¶

11.1 Klíčové ukazatele výkonnosti¶

Metrika	Cíl	Měření
Průměrná doba detekce (MTTD)	< 15 min (P1), < 1 hodina (P2)	Čas od výskytu do detekce
Průměrná doba reakce (MTTR)	< 30 min (P1), < 2 hodiny (P2)	Čas od detekce do zahájení izolace
Průměrná doba obnovy	< 4 hodiny (P1), < 8 hodin (P2)	Čas od izolace do obnovy služby
Soulad regulatorních oznámení	100% včas	Procento oznámení odeslaných v termínu
Incidenty dle závažnosti za čtvrtletí	Klesající trend	Počet incidentů dle závažnosti
Míra falešně pozitivních	< 5% pro P1/P2	Procento falešných upozornění
Míra dokončení cvičení	100% dle plánu	Procento provedených plánovaných cvičení
Dokončení post-incidentních akcí	100% do 30 dnů	Procento PIR akcí dokončených včas

11.2 Reporting¶

Měsíčně: Dashboard bezpečnostních operací pro CISO
Čtvrtletně: Souhrnná zpráva o incidentech pro CEO a představenstvo
Ročně: Komplexní revize programu reakce na incidenty

12. Integrace s dalšími procesy¶

12.1 Správa zranitelností (MV-LEG-005)¶

Aktivně zneužívaná zranitelnost BUDE eskalována na incident
Forenzika incidentů může identifikovat neznámé zranitelností pro proces správy
Kritické záplaty mohou být nasazený pod nouzovou autoritou Velitele incidentů

12.2 Řízení změn¶

Selhání změn vedoucí k bezpečnostní degradaci BUDOU řešeny jako incidenty
Nouzové změny během reakce BUDOU retrospektivně zdokumentovány

12.3 Kontinuita podnikání / Obnova po havárii (MV-LEG-008)¶

Kritický (P1) incident s prodlouženým výpadkem (> RTO) SPUSTÍ aktivaci BCP
Procesy BCP a reakce na incident běží paralelně s koordinovaným vedením

12.4 Řízení rizik (MV-LEG-002)¶

Každý P1/P2 incident BUDE mít za následek aktualizaci registru rizik
Trendy incidentů informují roční hodnocení rizik

12.5 Řízení přístupu (MV-LEG-003)¶

Incidenty zahrnující neoprávněný přístup spouští okamžitou revizi přístupu
Post-incident: přístupové politiky aktualizovány k prevenci opakování

13. Mapování souladu¶

Požadavek	Oddíl v tomto dokumentů
Zákon č. 264/2025 Sb. §15 (Hlášení incidentů NÚKIB)	Oddíl 6.1 (24hodinové oznámení), Oddíl 7.3
Směrnice NIS2 čl. 23 (Oznámení incidentů)	Oddíl 6.1, Oddíl 6.2
DORA čl. 17 (Řízení ICT incidentů)	Oddíly 2-5 (celý životní cyklus)
DORA čl. 18 (Klasifikace ICT incidentů)	Oddíl 2 (matice klasifikace)
DORA čl. 19 (Hlášení závažných ICT incidentů)	Oddíl 6.1 (4hodinové oznámení), Oddíl 6.2
GDPR čl. 33 (Oznámení dozorovému orgánu)	Oddíl 6.1 (72hodinové oznámení ÚOOÚ)
GDPR čl. 34 (Komunikace se subjektem údajů)	Oddíl 6.1
ISO/IEC 27001:2022 A.5.24 (Plánování řízení incidentů)	Oddíly 1-5
ISO/IEC 27001:2022 A.5.25 (Posouzení a rozhodnutí)	Oddíl 2, Oddíl 5.1
ISO/IEC 27001:2022 A.5.26 (Reakce na incidenty)	Oddíly 5.2-5.4
ISO/IEC 27001:2022 A.5.27 (Poučení z incidentů)	Oddíl 5.5, Oddíl 11
ISO/IEC 27001:2022 A.5.28 (Sběr důkazů)	Oddíl 8
SOC 2 CC7.3 (Reakce na incidenty)	Oddíly 2-5, 8
SOC 2 CC7.4 (Obnova po incidentů)	Oddíly 5.4, 12.3

14. Související dokumenty¶

ID dokumentů	Název
MV-LEG-001	Politika informační bezpečnosti
MV-LEG-002	Politika řízení rizik
MV-LEG-003	Politika řízení přístupu
MV-LEG-004	Kryptografická politika
MV-LEG-005	Politika správy zranitelností a záplat
MV-LEG-006	Politika protokolování a monitorování
MV-LEG-008	Plán kontinuity podnikání a obnovy po havárii

Správa dokumentů¶

Verze	Datum	Autor	Popis změny
1.0.0	2026-05-01	CISO	Prvotní vydání

KONEC DOKUMENTU