# Základní hodnocení NIST CSF 2.0

> *„Většina organizací neví, co neví. Tento workshop zpřístupní neznámé — za dva půldenní bloky, bez jediného technického nástroje."*

> *Anglická verze tohoto dokumentu je k dispozici zde: [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md). Metodika, struktura hodnocení a pokyny pro konzultanta jsou totožné — tento dokument slouží jako pracovní nástroj pro workshopy vedené v češtině.*

---

## Účel

Toto hodnocení je **vstupním bodem před výběrem jakéhokoliv modulu**. Odpovídá na otázku, kterou každý klient potřebuje zodpovědět před přijetím závazku k programu: *„Kde skutečně jsme a co je nejdůležitější napravit?"*

Jde o strukturovaný workshop, nikoli technický audit. Žádné nástroje se neinstalují. Z IT systémů se neshromažďují žádná data. Výstupem je jasný obraz bezpečnostní pozice organizace napříč šesti funkcemi NIST CSF 2.0, zpráva o silných stránkách a mezerách a prioritizovaný plán nápravy, který se přímo mapuje na menu antifragilních modulů.

**Délka**: Dva půldenní bloky (4 hodiny každý). Preferovaná forma je osobní přítomnost; vzdálená s kamerou je přijatelná.

**Kdo se účastní**:
- CIO/CISO nebo ekvivalent (povinný účastník)
- IT manažer / vedoucí infrastruktury (povinný účastník)
- Jeden vlastník business procesu (finance, provoz nebo HR — ten, kdo spravuje nejkritičtější data)
- Volitelně: Legal/compliance, provozní manažer pro OT prostředí

**Předpoklady**: Žádné. Toto je výchozí bod.

---

## Jak workshop vést

### Před workshopem

Zašlete klientovi jednostránkovou přípravnou poznámku:

> *„Strávíme dva půldenní bloky společným zodpovídáním upřímných otázek o tom, jak vaše organizace dnes řídí bezpečnost. Neexistují špatné odpovědi. Naším cílem je porozumět skutečnému stavu — ne tomu, co říkají politiky, ne tomu, co byste chtěli dělat, ale tomu, co se skutečně děje. Přiveďte prosím lidi, kteří vědí, jak věci opravdu fungují."*

Žádné domácí úkoly, žádný dotazník k předvyplnění. Předvyplněné dotazníky produkují aspirační odpovědi. Workshop produkuje upřímné.

### Struktura workshopu

**Sezení 1 (1. půlden): Kontext a základy**
- 30 min — Úvod, pravidla, přehled metodiky
- 90 min — Doména GOVERN (organizační kontext a řízení rizik)
- 60 min — Doména IDENTIFY (správa aktiv a hodnocení rizik)
- 20 min — Shrnutí, nedořešené body, náhled na 2. sezení

**Sezení 2 (2. půlden): Kontroly, detekce a obnova**
- 30 min — Rekapitulace a otevřené body ze sezení 1
- 45 min — Doména PROTECT (kontroly a záruky)
- 45 min — Doména DETECT (monitoring a detekce anomálií)
- 30 min — Doména RESPOND (řízení incidentů)
- 30 min — Doména RECOVER (obnova a zlepšování)
- 20 min — Předběžná zjištění, další kroky

---

## Dotazníky k jednotlivým doménám

Pro každou otázku zaznamenejte:
- **Aktuální stav** (co se skutečně děje)
- **Důkazy** (jaká dokumentace nebo artefakty existují)
- **Skóre**: 🔴 Není přítomno / 🟡 Částečné nebo nekonzistentní / 🟢 Funkční a efektivní

Skóre je diskusní nástroj, nikoli auditní zjištění. Jeho účelem je odhalit mezery, nikoli klienta hodnotit na prospěl/neprospěl.

---

### GV — GOVERN (Řízení)

*Identifikuje procesy, role a struktury dohledu, které přijímají bezpečnostní rozhodnutí a určují směr.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| GV-1 | Kdo v organizaci nese konečnou odpovědnost za kybernetickou bezpečnost? Má tato osoba pravomoc nad rozpočtem? | „Kdyby dnes v noci došlo k úniku dat, kdo by přijímal rozhodnutí o oznámení a nápravě?" |
| GV-2 | Má organizace zdokumentovanou politiku kybernetické bezpečnosti? Kdy byla naposledy přezkoumána? | „Četl ji někdo za posledních 12 měsíců? Odráží to, co skutečně děláte?" |
| GV-3 | Je riziko kybernetické bezpečnosti formálně reportováno představenstvu nebo výboru? Jak často? | „Co vedení skutečně vidí? Ohodnocení rizik? Přehledy incidentů? Nic?" |
| GV-4 | Jsou role a odpovědnosti v oblasti bezpečnosti jasně přiděleny a pochopeny těmi, kdo je zastávají? | „Kdybych se vašeho IT manažera zeptal, jaké jsou jeho bezpečnostní odpovědnosti, shodovala by se jeho odpověď s vaším očekáváním?" |
| GV-5 | Má organizace proces pro přezkoumání a schválení nových technologií před jejich nasazením? | „Jak byl váš poslední velký SaaS nástroj vyhodnocen před pořízením?" |
| GV-6 | Jsou dodavatelé a partneři třetích stran hodnoceni z hlediska bezpečnostního rizika? | „Víte, zda u vašich kritických dodavatelů došlo v posledním roce k narušení bezpečnosti?" |

**Klíčový poznatek k odkrytí**: Většina SMB má „odpovědnost za bezpečnost" neformálně přiřazenou tomu, kdo spravuje IT. To není totéž, jako mít odpovědného vedoucího pracovníka. Mezera bývá obvykle nikoli technická — je to mezera v řízení.

---

### ID — IDENTIFY (Identifikace)

*Rozvíjí organizační porozumění aktivům, business kontextu, zdrojům a schopnostem pro řízení kybernetického rizika.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| ID-1 | Udržuje organizace inventář hardwarových aktiv? Je aktuální? | „Kdybych se vás teď zeptal, kolik notebooků vaše společnost vlastní, dokázali byste mi to říct?" |
| ID-2 | Udržuje organizace inventář softwaru a SaaS služeb? | „Víte, které SaaS nástroje vaši zaměstnanci používají s firemními daty? Včetně těch neoficiálních?" |
| ID-3 | Jsou nejkritičtější business procesy organizace a data, na nichž závisejí, zdokumentovány? | „Které tři systémy by, kdyby byly nedostupné týden, nejvíce ohrozily podnikání?" |
| ID-4 | Bylo v posledních 12 měsících provedeno hodnocení rizik? | „Kdo ho provedl? Bylo pouze technické, nebo zahrnovalo i riziko business procesů?" |
| ID-5 | Jsou definovány a uplatňovány úrovně klasifikace dat na citlivá data? | „Vědí zaměstnanci, které dokumenty jsou důvěrné a co to v praxi znamená?" |
| ID-6 | Rozumí organizace svému externímu útočnému povrchu (veřejné služby, domény, IP rozsahy)? | „Naskenovali jste někdy svoji organizaci zvenčí?" |

**Klíčový poznatek k odkrytí**: Propast mezi „máme registr aktiv" a „máme aktuální, přesný registr aktiv, na němž jsou bezpečnostní rozhodnutí založena" je téměř vždy větší, než klient očekává.

---

### PR — PROTECT (Ochrana)

*Rozvíjí a implementuje odpovídající záruky pro zajištění dodávky kritických služeb.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| PR-1 | Je vícefaktorové ověření (MFA) vynuceno pro všechny uživatelské účty, včetně administrátorských? | „Existují výjimky? Přístup přes VPN? Starší aplikace? Sdílené účty?" |
| PR-2 | Jak jsou privilegované (administrátorské) účty spravovány? Jsou odděleny od každodenně používaných účtů? | „Kontroluje váš IT admin e-mail ze stejného účtu, ze kterého spravuje servery?" |
| PR-3 | Jsou aktualizace softwaru a záplaty aplikovány systematicky na všech zařízeních? Jaká je typická prodleva? | „Jak dlouho po vydání kritické záplaty Microsoftem ji vaše endpointy typicky obdrží?" |
| PR-4 | Jsou citlivá data šifrována v klidu i při přenosu? | „Kdyby byl dnes v noci ukraden notebook, mohl by útočník přistupovat k datům na něm?" |
| PR-5 | Je přístup k systémům založen na principu nejnižšího oprávnění? | „Když nastoupí nový zaměstnanec, k čemu má automaticky přístup?" |
| PR-6 | Existuje program bezpečnostního povědomí pro všechny zaměstnance? Kdy proběhlo poslední sezení? | „Kdybych dnes phishoval vaše zaměstnance, přibližně kolik procent by kliklo na odkaz?" |
| PR-7 | Jsou endpointová zařízení chráněna aktuálním anti-malware/EDR? Jaké je pokrytí? | „Existují zařízení — osobní notebooky, BYOD — která přistupují k firemním datům bez endpointové ochrany?" |

**Klíčový poznatek k odkrytí**: Většina organizací má MFA nasazené, ale nevynucené. Rozdíl je zásadní — „nasazené" znamená, že existuje; „vynucené" znamená, že ho nikdo nemůže obejít.

---

### DE — DETECT (Detekce)

*Rozvíjí a implementuje odpovídající aktivity pro identifikaci výskytu kybernetické bezpečnostní události.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| DE-1 | Existuje centralizované logování pro kritické systémy? Kdo logy přezkoumává? | „Kam ukládáte logy ze serverů? Kdy se naposledy někdo díval do logů z jiného důvodu než kvůli incidentu?" |
| DE-2 | Existují automatizované alerty pro bezpečnostně relevantní události? | „Co by spustilo alert dnes v noci, kdyby se někdo pokoušel brutální silou napadnout váš admin účet ze zahraničí?" |
| DE-3 | Existuje monitoring neobvyklého chování uživatelů (přihlášení mimo pracovní dobu, velké exporty dat)? | „Věděli byste, kdyby zaměstnanec dnes v noci stáhl veškeré dokumenty z vašeho SharePointu?" |
| DE-4 | Jak jsou bezpečnostní alerty třídeny a eskalovány? Kdo je přijímá? | „Kdyby váš SIEM dnes v noci vygeneroval 100 alertů, kdo by je viděl? Zítra ráno? Nebo ihned?" |
| DE-5 | Byla testována účinnost detekčních kontrol? | „Kdy jste naposledy ověřili, že váš monitoring by skutečně něco zachytil?" |

**Klíčový poznatek k odkrytí**: Většina klientů má logy. Téměř nikdo je nečte. „Logujeme vše" a „detekujeme hrozby" jsou různé schopnosti.

---

### RS — RESPOND (Reakce)

*Rozvíjí a implementuje odpovídající aktivity pro přijetí opatření při zjištěné kybernetické bezpečnostní události.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| RS-1 | Má organizace zdokumentovaný plán reakce na incidenty? | „Byl testován? Obsahuje kontaktní seznamy, rozhodovací stromy a komunikační šablony?" |
| RS-2 | Kdo odpovídá za vyhlášení incidentu a koordinaci reakce? | „Ve 2 hodiny ráno v sobotu, kdy se ransomware šíří sítí, kdo rozhodne o izolaci systémů?" |
| RS-3 | Má organizace záložní komunikační kanál pro reakci na incidenty? | „Když budou při incidentu nedostupné e-mail a Teams, jak budete komunikovat?" |
| RS-4 | Jsou předem identifikovány a nasmlouvány externí strany (právní poradenství, IR firma, pojišťovna, regulátor)? | „Máte vztah s cyber pojišťovnou? Retainer na incident response? Právního poradce obeznámeného s oznamováním narušení dat?" |
| RS-5 | Jak jsou zachycena a aplikována ponaučení z incidentů nebo téměř-miss situací? | „Dokážete uvést příklad procesu, který se změnil kvůli bezpečnostnímu incidentu za posledních dva roky?" |

**Klíčový poznatek k odkrytí**: Většina organizací má plán reakce na incidenty, který nebyl nikdy testován. Netestovaný plán není plán. Je to dokument. Otázka, kterou je třeba položit: „Kdy jste naposledy simulovali ransomwarový incident?"

---

### RC — RECOVER (Obnova)

*Rozvíjí a implementuje odpovídající aktivity pro udržení plánů odolnosti a obnovu schopností narušených kybernetickým bezpečnostním incidentem.*

| # | Otázka | Doptejte se, pokud není jasná |
|---|--------|-------------------------------|
| RC-1 | Zálohuje organizace své kritické systémy? Jak často? Jsou zálohy testovány? | „Kdy jste naposledy obnovili data ze zálohy? Ne zkopírovali — skutečně obnovili a ověřili, že to fungovalo?" |
| RC-2 | Jsou zálohy uloženy odděleně od primárních systémů (offline nebo neměnné)? | „Kdyby ransomware dnes v noci zašifroval vaše servery, mohl by se dostat také k zálohám?" |
| RC-3 | Jsou pro kritické systémy definovány cíle doby obnovy (RTO) a cíle bodu obnovy (RPO)? | „Jak dlouho by mohlo podnikání fungovat bez základního systému? Hodinu? Den? Týden?" |
| RC-4 | Jsou postupy obnovy zdokumentovány a známy osobám, které by je prováděly? | „Kdyby byl váš primární IT pracovník nedostupný při incidentu, dokázal by někdo jiný provést obnovu?" |
| RC-5 | Bylo provedeno úplné cvičení obnovy alespoň pro jeden kritický systém? | „Rekonstruovali jste někdy skutečně server ze zálohy v testovacím prostředí, abyste ověřili, že proces funguje?" |

**Klíčový poznatek k odkrytí**: Zálohy, které nebyly obnoveny, nejsou zálohy. Jsou to naděje. Nejčastějším zjištěním v této doméně je, že zálohy existují, ale nikdo neověřil, zda jsou konzistentní, úplné nebo obnovitelné ve stanoveném časovém rámci.

---

## Bodování a analýza mezer

Po dokončení všech domén sestavte skóre do souhrnné matice:

| Doména | Skóre | Kritické mezery (🔴) | Výrazné silné stránky (🟢) |
|--------|-------|---------------------|--------------------------|
| GOVERN | | | |
| IDENTIFY | | | |
| PROTECT | | | |
| DETECT | | | |
| RESPOND | | | |
| RECOVER | | | |

**Skóre domény**: počet 🟢 položek ÷ celkový počet položek. Není to přesná metrika — je to diskusní nástroj pro prioritizaci.

**Překryv s útočným řetězcem**: Po bodování položte ještě jednu otázku:

> *„Na základě toho, co jsme probrali, jaká je nejkratší cesta od ‚zatím se nic špatného nestalo' k ‚organizace nemůže fungovat'? Proveďte mě jí."*

Tím vznikne útočný řetězec. Moduly, které tento řetězec uzavírají, jsou prioritním doporučením.

---

## Struktura zprávy

Hodnocení produkuje dvoudílný výstup:

### Část 1: Zpráva o aktuálním stavu (doručena 5 pracovních dní po workshopu)

1. **Výkonné shrnutí** — jedna stránka; celková pozice, tři kritické mezery, tři klíčové silné stránky
2. **Zjištění k doménám** — pro každou doménu: aktuální stav, mezery v důkazech, klíčová rizika
3. **Analýza útočného řetězce** — nejkratší cesta k organizačnímu selhání na základě zjištění z workshopu
4. **Rychlá vítězství** — až 5 položek, které lze zlepšit za < 30 dní stávajícími nástroji a bez rozpočtu

### Část 2: Plán nápravy (součást části 1)

Mapuje zjištění přímo na antifragilní moduly:

| Priorita | Mezera | Modul | Odhadované úsilí |
|----------|--------|-------|-----------------|
| P0 (útočný řetězec) | [Zjištění] | [Modul č.] | [Délka] |
| P1 (kritické) | [Zjištění] | [Modul č.] | [Délka] |
| P2 (důležité) | [Zjištění] | [Modul č.] | [Délka] |

---

## Mapování na výběr modulu

| Typické zjištění hodnocení | Doporučený vstupní modul |
|---------------------------|-------------------------|
| Žádný inventář aktiv; neznámý útočný povrch | Modul 1 (Endpoint) + Modul 3 (M365 Hardening) |
| MFA nasazeno, ale nevynuceno; slabá identity hygiene | Modul 2 (Identity Security) |
| Žádné logování nebo alerty; „slepí" vůči útokům | Modul 3 (M365 Hardening) + Modul 12 (Blue/Purple Team) |
| Zálohy existují, ale netestovány; žádné cvičení obnovy | Modul 7 (Recovery & Resilience) |
| OT/IT síť bez segmentace; žádná kontrola přístupu dodavatelů | Modul 8 (OT Security) + Modul 13 (Privileged Access) |
| AD ve špatném stavu; zastaralé účty; žádná PAW | Modul 6 (On-Premise AD Hardening) |
| Žádný plán reakce na incidenty nebo krizová komunikace | Modul 14 (Sovereign Communications) + Modul 7 |
| Nástroje vlastněny, ale nepoužívány; týmy se necítí pod kontrolou | Modul 11 (Embedded Quality) |
| Dev a bezpečnost v silo; pomalé release cykly | Modul 9 (Organisational Resilience) |
| MSSP podvýkonný; žádná vlastní detekce | Modul 12 (Blue/Purple Team) |

---

## Cena a model angažmá

Toto hodnocení je **samostatné placené angažmá**, nikoli bezplatný scoping call.

**Typický rozsah**:
- Příprava před angažmá: 2 hodiny
- Dvě půldenní workshopová sezení: 8 hodin celkem
- Příprava zprávy: 4–8 hodin
- Prezentace zprávy a Q&A: 2 hodiny
- **Celkový čas konzultanta**: 16–20 hodin

**Co to produkuje**:
- Jasný, upřímný obraz toho, kde organizace stojí
- Doporučení modulů na základě důkazů (nikoli generická výzva „potřebujete více bezpečnosti")
- Prioritizovaný plán, na němž může klient jednat okamžitě — bez ohledu na to, zda pokračuje v angažmá

**Pitch**:

> *„Dříve než cokoliv doporučíme, chceme přesně pochopit, kde se nacházíte. Toto hodnocení trvá dva půldenní bloky a přináší upřímnou zprávu: vaše silné stránky, vaše mezery a tři věci, které je nejdůležitější napravit. Pokud po tomto doporučíme moduly, přesně pochopíte proč. Pokud se rozhodnete nepokračovat, stále máte plán, který můžete realizovat nezávisle. Oba výsledky jsou dobrý výsledek."*

---

## Integrace se stávajícími dokumenty

| Dokument | Integrace |
|----------|-----------|
| [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md) | Toto hodnocení operacionalizuje mapování rámce — domény dotazníku se přímo mapují na referenci |
| [Modular Engagements](../core/modular-engagements.md) | Zjištění hodnocení řídí Diagnostic Path a výběr modulů |
| [Antifragile Risk Register](antifragile-risk-register.md) | Zjištění hodnocení naplňují počáteční registr rizik |
| [Rapid Modernisation Plan](../playbooks/rapid-modernisation-plan.md) | Výstupní kritéria fáze 1 (Hygiene) zrcadlí zjištění domén Identify a Protect |
| [Business Case Template](../playbooks/business-case-template.md) | Zjištění hodnocení poskytují vstup pro kvantifikaci rizik v business case |

---

*Pro referenci ke standardům viz [NIST CSF 2.0 Mapping](../reference/nist-csf-mapping.md).*
*Pro proces výběru modulů viz [Modular Engagements](../core/modular-engagements.md).*
*Pro šablonu registru rizik viz [Antifragile Risk Register](antifragile-risk-register.md).*