Shrnutí

Metodický rámec pro IT architekty v prostředí státní správy ČR, který poskytuje komunikační a procesní nástroje pro obranu proti technické manipulaci, nezdůvodněným restrikcím a byrokratické svévoli. Manuál definuje protokol F-D-R-P (Fakt, Dedukce, Riziko, Požadavek) pro reakci na nepodložené bezpečnostní požadavky, nabízí konkrétní eskalační scénáře opřené o legislativu (3E, ZZVZ, zákon o finanční kontrole) a zavádí kvantitativní metody pro hodnocení ekonomické účelnosti bezpečnostních opatření. Slouží k ochraně profesionální integrity architekta a zajištění transparentního rozhodovacího procesu v hierarchických institucích.

Incident Response Manual

Obranný rámec pro IT architekty ve státní správě

Autor: IT architekt s reálnou zkušeností z prostředí státní správy ČR
Verze: 4.1
Datum: Leden 2026
Účel: Ochrana před technickou manipulací, procesní svévolí a institucionální byrokracií

ÚVOD: Od technické defenzivy k institucionální diplomacii

Tento manuál je výsledkem evoluce od technické argumentace k institucionální diplomacii. Je navržen pro prostředí, kde fakta ustupují moci, a jeho účelem je buď prosadit racionalitu, nebo bezpečně izolovat vaši odpovědnost.

Kdy tento manuál potřebujete:

✅ Čelíte bezpečnostním útvarům, které používají FUD (Fear, Uncertainty, Doubt) místo analýzy rizik
✅ Jste nuceni implementovat technická řešení, která odporují principům 3E (účelnost, hospodárnost, efektivnost)
✅ Vaše odborné argumenty jsou ignorovány z “politických důvodů”
✅ Potřebujete ochránit svou profesionální integritu a kariéru

Co tento manuál NENÍ:

❌ Návod, jak “vyhrát” nad bezpečnostními útvary za každou cenu
❌ Technický manuál kybernetické bezpečnosti
❌ Nástroj pro sabotování legitimních bezpečnostních opatření

Co tento manuál JE:

✅ Rámec pro zajištění, aby bezpečnostní opatření byla proporcionální, efektivní a v souladu se zákonem
✅ Soubor procesních a komunikačních protokolů pro práci v hierarchickém prostředí státní správy
✅ Exit strategy pro situace, kdy racionalita selže a musíte ochránit svou odpovědnost

ČÁST 1: KOMUNIKAČNÍ PROTOKOL F-D-R-P

Každá vaše reakce na FUD (Fear, Uncertainty, Doubt) musí následovat tuto strukturu:

F – FAKT

Odkaz na normu (ISO 27001/27005, NIST CSF), metodiku NÚKIB, nebo zákon (ZZVZ, zákon 320/2001 Sb. o finanční kontrole).

D – DEDUKCE

Logické vyvození, v čem je požadavek bezpečnosti v rozporu s faktem.

R – RIZIKO

Konkrétní dopad (pokuta ÚOHS, zrušení VZ, technologický dluh, nález NKÚ).

P – POŽADAVEK

Jasné určení dalšího kroku (nikoliv prosba, ale profesionální požadavek).

ČÁST 2: SCÉNÁŘE A PROTOKOLY

Scénář A: Reakce na nepodložené “Veto” bezpečnosti

Situace: Bezpečnost řekne: “Toto řešení nepovolíme, je to příliš velké riziko,” ale nedodá analýzu.

Tvoje odpověď (F-D-R-P):

“Bezpečnost se měří měřitelným rizikem, nikoliv subjektivním pocitem [F: ISO 27005, NÚKIB metodika řízení rizik]. Váš požadavek na zamítnutí architektury [X] postrádá oporu v těchto metodikách [D]. Bez specifikace konkrétní hrozby, zranitelnosti a dopadu (vektoru útoku) není možné provést kvalifikované rozhodnutí o alokaci prostředků [R: porušení § 2 zákona 320/2001 Sb.].

Požaduji, aby útvar bezpečnosti do [Datum] předložil písemné vyjádření obsahující analýzu rizik. Pokud ji nemůžete poskytnout, budu nucen konstatovat procesní vadu v přípravě projektu a postoupit věc k metodickému dotazu na NÚKIB, zda je tento typ restrikce v v souladu s aktuálními bezpečnostními standardy a metodickým rámcem NÚKIB. [P].”

Scénář B: Eskalace k Project Managerovi (PM) / Výboru

Situace: Bezpečnost blokuje projekt a PM začíná být nervózní.

Tvoje odpověď:

“Upozorňuji na kritické riziko zablokování projektu z důvodu nezdůvodněných požadavků útvaru bezpečnosti [F: aktuální stav projektu]. Požadavky jsou v přímém rozporu s principy 3E (§ 2 zákona 320/2001 Sb.), neboť vyžadují investici bez doložené účelnosti [D].

Požaduji, aby toto bylo zaneseno do registru rizik s příznakem ‘Vysoký dopad na rozpočet a harmonogram’ [P]. Zároveň navrhuji, aby vedení projektu vyžadovalo od bezpečnosti Prohlášení o akceptaci reziduálního rizika (Risk Acceptance Statement). Pokud bezpečnost odmítá podepsat analýzu rizik, za kterou si stojí, nemůže vedení projektu tyto vícenáklady schválit [R: právní a finanční odpovědnost vedení].”

Scénář C: Konzultace s právním oddělením

Situace: Bezpečnost si vymyslela technický parametr, který splňuje jen jeden produkt.

Tvoje odpověď:

“Při revizi technické specifikace pro VZ jsem identifikoval požadavek bezpečnosti na [Parametr], který se jeví jako diskriminační ve smyslu § 36 ZZVZ [F: zákon]. Neexistuje žádná analýza aktiv, která by tento specifický požadavek ospravedlňovala jako nezbytný [D].

Požaduji, aby právní oddělení přezkoumalo riziko napadení zakázky u ÚOHS [P]. Jako architekt nemohu převzít odpovědnost za zadávací dokumentaci, která je v rozporu s rozhodovací praxí ÚOHS v oblasti technologické neutrality [R: riziko zrušení zakázky a sankce].”

Scénář D: Obrana proti Megalomanii (Gold-plating)

Situace: Bezpečnost vyžaduje extrémní sizing nebo konkrétní technické řešení bez analýzy.

Tvoje odpověď – Obrácení důkazního břemene (Burden of Proof Reversal):

“Vámi definovaný sizing [X] postrádá dokumentovanou analýzu rizik [F: ISO 27005, metodika NÚKIB]. Jako architekt nenesu odpovědnost za neopodstatněné navyšování rozpočtu bez věcného zdůvodnění [D: rozpor s § 2 písm. m zákona 320/2001 Sb.].

Požaduji, aby útvar bezpečnosti do [Datum] předložil [P]:

Analýzu rizik dle ISO 27005 (včetně kvantifikace hrozeb a zranitelností)

Cost-Benefit Analysis (CBA) prokazující, že vícenáklady jsou proporcionální k redukci rizika

Kvantifikaci ALE (Annualized Loss Expectancy) prokazující ekonomickou účelnost opatření (viz ČÁST 6)

Funkční a výkonnostní specifikaci (co má systém zvládnout) namísto technického diktátu (jaké železo koupit)

Pokud tyto podklady nebudou dodány, iniciuji revizi zadání právním oddělením pro rozpor se zásadou přiměřenosti (§ 6 odst. 1 ZZVZ) [R].”

Scénář E: Compliance $\neq$ Security (Papírová vs. reálná bezpečnost)

Situace: Bezpečnost trvá na ISO certifikacích a procesních razítkách, ale ignoruje reálnou odolnost systému.

Tvoje odpověď – Bezpečnost orientovaná na výsledky (Outcome-based Security):

“Samotná formální shoda (compliance) s ISO 27001 nezaručuje bezpečnostní integritu řešení [F: historické incidenty u certifikovaných institucí]. Historické útoky na státní sféru ukazují, že kompromitovány byly primárně ‘compliant’ subjekty [D].

Požaduji, aby útvar bezpečnosti definoval metriky orientované na výsledek (outcome-based metrics) [P], které budeme po dodavateli vyžadovat v rámci SLA:

MTTD (Mean Time to Detect): Maximální čas na detekci průniku

MTTR (Mean Time to Respond): Maximální čas na izolaci napadeného segmentu

SLA na Patch Management: Povinnost opravit kritické zranitelnosti (CVSS 9+) do 24 hodin

Trvání na certifikátech bez těchto metrik považuji za vytvoření falešného pocitu bezpečí, což je riziko, které musí být zaneseno do registru rizik projektu [R].”

Scénář F: Exploitability Test (Štít proti teoretickým hrozbám)

Situace: Manipulátor vytáhne exotický vektor útoku (např. hypotetický Zero-day) a vyžaduje extrémní investici.

Tvoje odpověď:

“Váš scénář je teoreticky přípustný [F: uznání možnosti]. V rámci hospodárného řízení rizik však musíme posoudit reálnou zneužitelnost (exploitability) v našem specifickém prostředí [D: § 2 písm. m zákona 320/2001 Sb.].

Požaduji, aby útvar bezpečnosti doložil [P]:

Attack Surface Analysis (Analýza povrchu útoku): Které konkrétní komponenty naší architektury tento vektor odhalují?

Prerequisites Test (Prověření prerekvizit/předpokladů): Jaké podmínky musí útočník splnit (přístup k L2, fyzický přístup, zkompromitované biometrické údaje)?

EPSS Score – Exploit Prediction Scoring System (Systém bodování predikce zneužití): Jaká je statistická pravděpodobnost zneužití této zranitelnosti v příštích 12 měsících?

Comparable Incidents (Srovnatelné incidenty): Existuje historický precedens u srovnatelných institucí?

Bez těchto dat je váš požadavek pouze akademickou hypotézou, nikoliv identifikovaným rizikem vyžadujícím okamžitou alokaci veřejných prostředků [R: porušení 3E].”

Scénář G: Redukce na základní předpoklad (Reduce to Core Assumption / Gish Gallop Neutralizer)

Situace: Úředník tě zahlcuje smrští technických detailů (Gish Gallop).

Tvoje odpověď:

“Váš útočný scénář je komplexní, ale stojí na jediném primárním předpokladu (Core Assumption) [D: identifikace základního předpokladu]: Že útočník již získal přístup k vnitřní síti s právy lokálního administrátora.

Místo diskuse o detailech laterálního pohybu požaduji analýzu stromu útoků (Attack Tree Analysis) [P], která odpoví na:

Jaká je pravděpodobnost selhání primárních kontrol (MFA, segmentace), které k tomuto stavu vedou?

Je vámi navržený hardware firewall nejefektivnější obranou v porovnání se zvýšením granularity oprávnění v AD?

Analýza stromu útoků musí obsahovat:

Root Node (Kořenový uzel): Cíl útočníka.

Attack Paths (Cesty útoku): Všechny realistické cesty k cíli.

Attack Steps (Kroky útoku): U každého kroku specifikujte: Difficulty (Obtížnost), Probability (Pravděpodobnost) a Controls (Existující vs. navrhovaná opatření).

Pokud neprokážete, že vámi navržené opatření je nejúčinnější v poměru náklady/benefit (3E), je návrh v rozporu s principem účelnosti [R: § 2 písm. n zákona 320/2001 Sb.].”

ČÁST 3: KONSTRUKTIVNÍ ESKALACE

Místo hrozeb: Nabídka dvou postupů

Když identifikujete procesní nebo právní problém, nabídněte vedení dva postupy – standardní (vámi doporučený) a eskalovaný (pro případ, že standard není možný).

Formulace:

“Analyzoval jsem technický požadavek útvaru bezpečnosti. Identifikoval jsem věcný rozpor s § 2 písm. m zákona č. 320/2001 Sb.:

Absence Cost-Benefit Analysis

Chybějící srovnání alternativ

Zvýšené riziko napadení u ÚOHS

V zájmu ochrany instituce navrhuji dva možné postupy:

A) Standardní (Doporučený):
Útvar bezpečnosti doplní chybějící analýzu rizik a CBA, čímž zhojí procesní vady návrhu před zahájením zakázky.

B) Eskalovaný:
Pokud není varianta A z časových či jiných důvodů možná, navrhuji postoupit rozhodnutí Projektovému výboru. Požaduji, aby bylo v zápisu výboru uvedeno:

Požadavek je implementován z důvodů jiných než technických (např. strategických)

Vedení je si vědomo vícenákladů [X] mil. Kč

Vedení akceptuje riziko přezkumu u ÚOHS

Rozhodnutí je přijato na úrovni [jméno a funkce rozhodujícího]

Tento postup volím výhradně pro zajištění transparentnosti pro budoucí audit, aby byla doložena kontinuita rozhodovacího procesu.”

Proč to funguje:

✅ Neobviňujete z “politických důvodů” (říkáte “důvody jiné než technické”)
✅ Nabízíte legitimní cestu pro vedení
✅ Dokumentujete procesní problém
✅ Chráníte svou odpovědnost

ČÁST 4: Eskalační žebřík zapojení autority (NÚKIB Escalation Ladder)

NÚKIB používejte jako objektivního arbitra, nikoliv jako hrozbu.

Stupeň 1: Neformální metodický dotaz

“Tento výklad ZoKB se jeví jako neobvyklý. Pošlu neformální metodický dotaz svému kontaktu na NÚKIB, abychom si potvrdili, že jdeme správnou cestou a neriskujeme budoucí neshodu při auditu.”

Stupeň 2: Formální konzultace

“Vzhledem k přetrvávajícím rozporům v interpretaci přiměřenosti navrhuji, aby PM oficiálně požádal NÚKIB o metodickou konzultaci k tomuto konkrétnímu technickému požadavku (§ 3 odst. 2 písm. b) ZoKB – metodická podpora).”

Stupeň 3: Osobní iniciativa

“Pokud projektový manažer neiniciuje konzultaci s NÚKIB, jsem nucen osobně zaslat metodický dotaz jako fyzická osoba (§ 3 odst. 2 písm. b) ZoKB neomezuje dotazy jen na instituce). V dotazu uvedu technickou situaci bez jmenování konkrétních osob. Odpověď NÚKIB pak předložím projektovému výboru jako podklad pro rozhodnutí.”

Důležité: NÚKIB má mandát poskytovat metodickou podporu. Neváhejte je kontaktovat.

ČÁST 5: EXIT STRATEGY – Přijetí prohry s grácií

Kdy přestat bojovat:

✅ Když vedení rozhodlo s plnou znalostí rizik
✅ Když rozhodnutí je dokumentováno (zápis + podpis)
✅ Když je to legitimní manažerské rozhodnutí (např. strategická priorita)

Jak to udělat:

“Beru na vědomí rozhodnutí Projektového výboru ze dne [datum], sp. zn. [číslo], kterým bylo schváleno implementovat požadavek útvaru bezpečnosti na [X] s vícenáklady [Y] mil. Kč.

Nesouhlasím s tímto rozhodnutím z technických důvodů uvedených v mém vyjádření ze dne [datum], ale respektuji právo vedení rozhodnout jinak na základě strategických priorit, které jako architekt nemohu plně posoudit.

Budu pokračovat v implementaci dle schváleného rozhodnutí s plnou profesionalitou.”

Proč je to důležité:

✅ Dokumentujete svůj nesouhlas (pro případný audit)
✅ Respektujete hierarchii (nejste “rebel”)
✅ Ponecháváte si integritu (nejste “ten, který to schválil”)
✅ Někdy je lepší přijmout prohru s grácií než bojovat do konce

ČÁST 6: KVANTITATIVNÍ ARGUMENTACE (Risk Math & 3E)

Tato část slouží k demaskování investic, které jsou v hrubém nepoměru k reálnému riziku.

1. Výpočet ALE (Annualized Loss Expectancy) – Předpokládaná roční ztráta

Aby byla investice hospodárná, musí být roční náklady na opatření nižší než hodnota ALE.

Vzorec: $ALE = SLE \times ARO$
ALE (Annualized Loss Expectancy) – Předpokládaná roční ztráta.
SLE (Single Loss Expectancy): Finanční škoda způsobená jedním výskytem incidentu (zahrnuje i pokuty a reputaci).
ARO (Annualized Rate of Occurrence): Pravděpodobnost (četnost), kolikrát za rok k incidentu dojde.

2. Vztah k principu ALARP (As Low As Reasonably Practicable)

Bezpečnost není absolutní stav, ale bod rovnováhy. Pokud náklady na další snižování rizika rostou exponenciálně, zatímco hodnota ALE klesá lineárně, nacházíme se v zóně ALARP – bodu, kde je další investice nepřípustným mrháním veřejnými prostředky.

3. Propojení se zákonem o finanční kontrole

Jakýkoliv požadavek bezpečnosti, který ignoruje výše uvedené parametry, je z definice v rozporu s hospodárností (minimalizace výdajů při zachování kvality) a účelností (užití prostředků pro zajištění daného cíle s co největším přínosem).

ČÁST 7: FINAL BATTLE CARD

Rychlý přehled taktik a proti-akcí

Situace	Taktika bezpečnosti	Tvoje proti-akce	Cílový stav
Obecné strašení	“Je to díra do systému”	F-D-R-P + Požadavek na analýzu rizik	Přechod od emocí na data
Metodický faul	“Naše pravidla to neumožňují”	Požadavek na konkrétní paragraf metodiky	Odhalení subjektivního názoru
Absolutismus	“Musí to být 100% bezpečné”	Residual Risk + ALARP princip	Akceptace zbytkového rizika
Vendor Lock-in	“Chceme jen technologii XY”	ZZVZ § 36 + právní oddělení	Technologická neutralita
Gold-plating	Extrémní sizing bez odůvodnění	Burden of Proof Reversal + CBA	Oni dokazují, ty reviduješ
Gish Gallop	Zahlcení detaily	Reduce to Core Assumption	Redukce na testovatelný bod
Teoretická hrozba	Hypotetický útok bez dat	Exploitability Test	Přechod od “možná” k “pravděpodobně”
Checkbox Security	Požadavek na ISO certifikaci	Outcome-based Security (MTTD/MTTR)	Reálné metriky místo razítek
Politický tlak	“To je priorita vedení”	Konstruktivní eskalace (2 postupy)	Rozhodnutí vedení, ne tvé selhání
Patová situace	Nikdo neustoupí	NÚKIB Escalation Ladder	Externí arbitr

ČÁST 8: PRAVIDLA PŘEŽITÍ VE STÁTNÍ SPRÁVĚ

1. Nejsi sám

Najdi další architekty ve státní správě se stejným problémem. Společný podnět má mnohem větší váhu než individuální stížnost.

2. Dokumentace je tvůj pancíř

Každé jednání, každý požadavek, každá eskalace musí být písemně zaznamenána. “Co není v zápisu, to se nestalo.”

3. NÚKIB je tvoje zbraň

Neváhej je kontaktovat. Mají mandát poskytovat metodickou podporu (§ 3 odst. 2 písm. b) ZKB).

4. Používej jazyk auditora

Místo “Myslím si, že to je drahé,” říkej “Tento náklad postrádá doložitelnou účelnost v rámci finanční kontroly (§ 2 zákona 320/2001 Sb.).”

5. Nenabízej řešení příliš brzy

Nech je nejdřív definovat problém (hrozbu). Pokud ji nedokážou definovat, nemají co řešit.

6. Dokumentuj ticho

Pokud na tvůj požadavek (např. o analýzu rizik) neodpoví, pošli po 3 dnech urgenci v kopii PM: “Jelikož útvar bezpečnosti nedodal požadovanou analýzu hrozeb, pracuji s předpokladem, že riziko je marginální.”

7. Někdy je lepší přijmout prohru s grácií

Pokud vedení rozhodlo legitimně (s plnou znalostí rizik a s dokumentací), respektuj to. Zachráníš si kariéru a integritu.

ČÁST 9: DIAGNOSTIKA – Expert vs. Manipulátor

Používej tuto tabulku k rozlišení, zda čelíš expertovi nebo manipulátorovi:

Znak	Expert	Manipulátor
Reference	Ochotně poskytne odkaz (NIST SP 800-53, ISO 27002)	“To je příliš komplikované vysvětlovat”
Limity	Přiznává: “To je teoreticky možné, ale pravděpodobnost je nízká”	“Tohle MUSÍ být, jinak budeme hacknutí”
Alternativy	Nabízí: “Můžeme to řešit třemi způsoby, každý má trade-offs”	“Jediné správné řešení je moje”
Reakce na protinárazy	“Dobrý point, to jsem nezohlednil”	“Vy tomu nerozumíte, já mám 20 let praxe”
Precedenty	Doloží: “Toto se stalo v instituci X v roce Y”	“Nevím o konkrétním případě, ale teoreticky…”
Kvantifikace	Uvede: “Pravděpodobnost 15 %, dopad 5 mil., ALE 750k”	“Je to kritické riziko” (bez čísel)

Jak použít: Pokud vidíš 3+ znaků manipulátora, použij protokol “Burden of Proof Reversal” a nesnaž se technicky přesvědčit – snaž se procesně vynutit dokumentaci.

ZÁVĚR: Tvoje nová identita

Nejsi “ten, co bojuje proti bezpečnosti.”
Jsi “ten, co zajišťuje, aby bezpečnostní opatření byla proporcionální, efektivní a v souladu se zákonem.”

Nejsi “problémový architekt.”
Jsi “ochránce instituce před právními a finančními riziky.”

Nejsi “technický puritán.”
Jsi “profesionál, který respektuje hierarchii, ale vyžaduje transparentnost rozhodovacího procesu.”

PŘÍLOHA: Právní rámec (Zkratky a odkazy)

ZZVZ: Zákon č. 134/2016 Sb., o zadávání veřejných zakázek
Zákon 320/2001 Sb.: Zákon o finanční kontrole ve veřejné správě
ZKB: Zákon č. 181/2014 Sb., o kybernetické bezpečnosti
3E: Účelnost, hospodárnost, efektivnost (§ 2 písm. m, n, o zákona 320/2001 Sb.)
§ 6 odst. 1 ZZVZ: Zásada přiměřenosti
§ 36 ZZVZ: Zákaz diskriminace a bezdůvodných překážek soutěže
ISO 27005: Mezinárodní standard pro řízení rizik v informační bezpečnosti
NÚKIB: Národní úřad pro kybernetickou a informační bezpečnost
ALARP Princip (As Low As Reasonably Practicable): Metoda určení hranice mezi nezbytným zabezpečením a neefektivním vynakládáním prostředků

Konec dokumentu

“Tento manuál není o tom, jak vyhrát. Je o tom, jak přežít s integritou.”