METODICKÝ NÁVOD PRO ŘÍZENÍ TECHNOLOGICKÝCH ZMĚN A INTEGRACÍ V INFRASTRUKTUŘE STÁTNÍ SPRÁVY
Rozsah a účel dokumentu: Tato metodika definuje univerzální rámec pro integraci technologických komponent (hardwaru, infrastrukturního softwaru, úložných systémů, serverových platforem, řídicích platforem nebo aktivních síťových prvků) do stávající sdílené infrastruktury státní správy. Cílem je eliminovat rizika neřízeného nárůstu rozsahu (scope creep), zajistit legislativní a bezpečnostní kompatibilitu, garantovat jednoznačnou procesní odpovědnost všech zúčastněných stran a ošetřit celý životní cyklus změny od iniciace až po dlouhodobý provoz.
0. Definice, zkratky a role
Pojmy a role uvedené v této tabulce jsou pro účely metodiky závazné. Konkrétní subjekty zastávající dané role se stanoví v zahajovací dokumentaci projektu.
| Pojem / zkratka | Význam |
|---|---|
| HIP | Hostitelský infrastrukturní projekt – projekt vlastnící a spravující cílovou sdílenou infrastrukturu, do níž se integruje. Vystupuje jako technický konzultant a garant akceptačních kritérií. |
| IPSS | Iniciující projekt specifické služby – projekt zavádějící novou technologii. Nositel smluvního vztahu, plátce a subjekt odpovědný za dotační tituly a soulad se ZZVZ. |
| ÚSÚ | Ústřední správní úřad – zákazník a věcný vlastník/koncový uživatel cílové služby. |
| Digitální autorita (DA) | Ústřední koordinační a metodická autorita pro digitalizaci a kybernetickou bezpečnost. V podmínkách ČR této roli zpravidla odpovídá Digitální a informační agentura (DIA), v bezpečnostní rovině ve spolupráci s NÚKIB. |
| Provozovatel | Subjekt provozující hostitelskou infrastrukturu na vrstvách L1–L3 (dostupnost, HW, konektivita, základní směrování). |
| ZZVZ | Zákon č. 134/2016 Sb., o zadávání veřejných zakázek. |
| VRF | Virtual Routing and Forwarding – logicky oddělený směrovací kontext. |
| SPOF | Single Point of Failure – jediný kritický bod selhání. |
| OOB | Out-of-Band – mimopásmová (oddělená) management síť. |
| ISMS | Information Security Management System dle ISO/IEC 27001. |
| SIEM | Security Information and Event Management. |
| IAM / PAM / PIM | Identity / Privileged Access / Privileged Identity Management. |
| HLD / LLD / DSP | High-Level Design / Low-Level Design / Dokumentace skutečného provedení. |
| BCM / DR / IRP | Business Continuity Management / Disaster Recovery / Incident Response Plan. |
| BIA | Business Impact Analysis. |
| RPO / RTO | Recovery Point Objective / Recovery Time Objective. |
| SLA / OLA | Service / Operational Level Agreement. |
| CAPEX / OPEX | Investiční / provozní výdaje. |
| ZTA | Zero Trust Architecture dle NIST SP 800-207. |
| CERT / CSIRT | Národní bezpečnostní tým pro reakci na kybernetické incidenty. |
| RACI | Matice odpovědností – Responsible / Accountable / Consulted / Informed. |
1. Finančně-legislativní rámec a ochrana integrity smluvních vztahů
Při implementaci nových technologických celků do stávající, dosud nedokončené nebo nepředané infrastruktury je nutné striktně oddělit roli HIP od role IPSS. HIP vystupuje výhradně jako technický konzultant a garant akceptačních kritérií. IPSS je nositelem smluvního vztahu, plátcem a subjektem odpovědným za dotační tituly a soulad se ZZVZ.
- Změna závazku ze smlouvy (§ 222 ZZVZ): Pokud smlouvy HIP nemají rámcový charakter a disponují fixně definovaným předmětem plnění vzešlým z již uzavřených veřejných zakázek, je legislativně nepřípustné realizovat nebo hradit integrační, konfigurační a instalační práce z těchto smluv. Jakékoliv svévolné navyšování objemu plnění pro potřeby jiného projektu by představovalo podstatnou změnu smlouvy. IPSS je povinen zajistit smluvní a pořizovací tituly pro nezbytnou součinnost, kapacitní alokace a rekonfiguraci infrastruktury od stávajících dodavatelů HIP samostatně, napřímo a z vlastních zdrojů. Pokud je to nezbytné pro zachování záruk a servisní podpory (SLA), stávající dodavatel HIP musí být do realizační struktury IPSS zapojen napřímo nebo formou subdodavatelského vztahu.
- Dlouhodobá udržitelnost a finanční kontrola: Dotační tituly zpravidla pokrývají pouze investiční a implementační fázi (CAPEX). Nová technologie však generuje trvalé provozní výdaje (OPEX) na softwarová předplatná, aktualizace, podporu nebo externí kapacity. Před zahájením jakýchkoliv prací musí IPSS prokazatelně deklarovat mechanismus zajištění trvalého provozního financování ze strany správce rozpočtové kapitoly. Pozn. k právnímu základu: požadavek na dobu udržitelnosti (zpravidla minimálně 5 let po finančním ukončení projektu) vyplývá z pravidel konkrétního dotačního titulu (např. IROP, OP TAK, OPZ+), nikoli ze zákona o finanční kontrole. Samotné nakládání s veřejnými prostředky a ověření zajištění krytí současně podléhá zákonu č. 320/2001 Sb., o finanční kontrole. Obě roviny musí být doloženy odděleně.
2. Mandatorní podmínky pro zahájení změnového řízení
Formulace technického zadání a alokace plných kapacit architektů HIP jsou striktně podmíněny písemným splněním následujících prerekvizit ze strany IPSS:
- Dodání konkrétních a měřitelných akceptačních kritérií: IPSS musí specifikovat jednoznačná, měřitelná technická a bezpečnostní kritéria pro rozsah a posouzení proveditelnosti integrace (rámec viz kap. 8).
- Doložení formálního souhlasu zákazníka: Prokazatelné písemné schválení těchto akceptačních kritérií odpovědnou osobou na straně ÚSÚ.
Pro vyřešení vstupní závislosti (IPSS nemůže formulovat smysluplná kritéria bez znalosti cílové architektury) poskytne HIP před touto fází nezbytné vstupní rámcové podklady (aktuální topologii, adresní plán, omezení perimetru) v rozsahu nutném pro formulaci kritérií. Teprve dodání kritérií dle bodů 1–2 odblokovává alokaci plných projekčních kapacit HIP. Postup při nesplnění nebo pouze formálním splnění prerekvizit řeší kap. 7.
3. Architektonické, technické a bezpečnostní mantinely integrace
Implementace nových komponent do izolovaného produkčního prostředí vyžaduje řízené výjimky, zachování systémové integrity a eliminaci rizik selhání dostupnosti stávajících služeb.
3.1 Řízená výjimka z principu síťové izolace
Pokud integrovaná technologie (včetně cloud-managed serverů, úložných systémů s externí telemetrií nebo SaaS řídicích platforem) vyžaduje trvalou konektivitu do vnějšího prostředí pro aktualizace, synchronizaci stavů nebo sběr telemetrických dat, musí být implementován dedikovaný management VRF kontext. Tento kontext musí splňovat:
- Striktní filtraci na hraničních firewallech omezenou výhradně na schválené a dokumentované IP prefixy a porty externí platformy.
- Kryptografické a logické oddělení od produkčních datových toků hostitelské infrastruktury.
- Kontinuální logování a monitorování v rámci ISMS s generováním bezpečnostních alertů do SIEM.
3.2 Doplňkový bezpečnostní model: Zero Trust pro hybridní konektivitu
Perimetrická izolace (VRF, firewallová filtrace, omezení na L3/L4) je nutnou, nikoli však postačující podmínkou u komponent s trvalou konektivitou do externích platforem (cloud-managed, SaaS). U těchto prvků musí návrh doplnit perimetrický model o principy Zero Trust Architecture (NIST SP 800-207):
- Identitně orientovaný přístup: žádný implicitní důvěryhodný segment; každý přístup z/do externí platformy je autentizován a autorizován na úrovni identity, nikoli pouze síťové polohy.
- Verifikace per relace a nejnižší privilegium: krátkodobé, kontextově omezené oprávnění; mikrosegmentace toků mezi integrovanou komponentou a produkčními systémy.
- Kontinuální vyhodnocování důvěry: trvalé monitorování stavu, anomálií a integrity komponenty, nikoli jednorázové ověření při zařazení do sítě.
Míra uplatnění ZTA je úměrná klasifikaci aktiv a musí být odsouhlasena bezpečnostním architektem ÚSÚ.
3.3 Prevence Single Point of Failure (SPOF) a zajištění kontinuity provozu
V závislosti na typu integrace musí architektura garantovat odolnost proti selhání:
- Komponenty zařazené přímo do datové cesty (aktivní inline síťové prvky): Nasazení takové komponenty vytváří kritický bod selhání. Architektura musí obsahovat fyzické (optické nebo metalické) bypass přepínače. Při ztrátě napájení, chybě firmwaru nebo hardwarové havárii musí linka okamžitě přejít do stavu Fail-Open. Tím je upřednostněna kontinuita provozu a dostupnost informačních systémů před funkcí integrovaného prvku. Stav Fail-Open a jeho přijatelná délka trvání musí být akceptovány z pohledu řízení rizik ISMS ÚSÚ.
- Standardní infrastrukturní komponenty (servery, úložiště, řídicí uzly): Integrace nesmí narušit stávající úroveň vysoké dostupnosti (HA). Nové komponenty musí být zapojeny redundantně (N+1, multi-chassis link aggregation, multipathing) napříč nezávislými napájecími větvemi a distribučními přepínači HIP.
3.4 Sizing a kapacitní plánování (Technické prerekvizity)
Bezpečnostní a infrastrukturní dopady vyžadují před schválením rozsahu součinnosti od IPSS kvantifikaci těchto parametrů:
- Log management a SIEM: Odhadovaný počet událostí za vteřinu (EPS) v klidovém stavu a špičkový nárůst při provozní špičce a mimořádných stavech; objem NetFlow/IPFIX dat (Flows per Second) generovaných ze síťových prvků pro potřeby analýzy; celkový počet přidávaných aktiv (assets).
- Identity & Access Management (IAM/PAM): Celkový počet administrátorů a operátorů v jednotlivých rolích; předpokládaný počet souběžných relací (concurrent sessions) pro dimenzování Jump serverů a licenční pokrytí přístupových nástrojů, jelikož stávající kapacity HIP nejsou pro potřeby IPSS alokovány; přesný počet nových spravovaných prvků pro integraci do PIM/PAM. Přístup musí respektovat princip nejnižších privilegií (least privilege). Mandatorně musí být zřízeny lokální nouzové účty (break-glass) pro případ krizového výpadku centrální autentizace v důsledku saturace infrastruktury.
- Zálohování: Alokace dedikovaného zálohovacího serveru, retence záloh, situování zálohovacích oken do mimoprodukčních hodin a definice parametrů RPO/RTO pro obnovu konfigurací a systémových stavů.
4. Kybernetická bezpečnost, legislativa a logování
4.1 Zákaz TLS terminace a omezení na nižších vrstvách
Z důvodu ochrany osobních údajů (GDPR) a zachování důvěrnosti v rámci ISMS je nepřípustné, aby externě spravovaná technologie, sdílený perimetrický prvek třetí strany nebo neověřená appliance terminovala TLS spojení a disponovala privátními kryptografickými klíči aplikačních služeb eGovernmentu. Integrační vrstva musí být konfigurována striktně na úrovni L3/L4, pokud vlastník systému explicitně neschválí výjimku. Aplikační inspekce na L7 zůstává v kompetenci vlastníků IS spravovaných v rámci lokálních aplikačních platforem a dedikovaných webových firewallů.
4.2 Autonomní architektura logování a telemetrie
Pokud stávající architektura logování HIP nepredikovala integraci telemetrie z prvků IPSS, je tato komunikace kompletně vyňata z centrálního logování HIP. Předávání bezpečnostních a provozních událostí musí směřovat přímo do SIEM infrastruktury IPSS za dodržení standardů šifrovaného přenosu (Syslog over TLS dle RFC 5425, SNMPv3 authPriv). Pokud zařízení nepodporuje šifrovaný přenos nativně, musí IPSS zajistit přenos těchto dat přes plně izolovanou samostatnou mimopásmovou (OOB) management síť bez jakéhokoliv logického kontaktu s produkčními datovými VLAN. Tok logů musí být zdokumentován end-to-end včetně správy TLS certifikátů a důvěryhodnosti CA řetězců.
4.3 Bezpečnost dodavatelského řetězce
Fyzická i softwarová dodávka podléhá ustanovením o bezpečnosti dodavatelského řetězce dle platné legislativy o kybernetické bezpečnosti a navazujících vyhlášek a stanovisek NÚKIB (v souladu s rámci ISO/IEC 27001, NIST SP 800-161 a transpozicí NIS2). Tým IPSS musí v rámci řízení rizik:
- Prověřit původ nasazovaných hardwarových komponent a předložit dokumentaci prokazující, že komponenty nepocházejí od nedůvěryhodných výrobců z hlediska geopolitických rizik.
- Jednoznačně analyzovat a zdokumentovat rizika spojená s geolokací externích zpracovatelských center, jimiž prochází nebo v nichž jsou zpracovávána data subjektů. Pokud jsou osobní údaje zpracovávány mimo EU/EHP, musí IPSS doložit rovněž právní titul předání dle hlavy V GDPR (rozhodnutí o adekvátnosti nebo standardní smluvní doložky) a příslušné DPIA.
- Smluvně zavázat externího dodavatele k poskytování podkladů pro prověřování ze strany národní autority pro kybernetickou bezpečnost.
5. Matice odpovědností pro fázi implementace (RACI)
Fyzickou manipulaci, montáž do racků, instalaci do napájecích větví a propojování kabeláže v datových centrech provádí výlučně personál zajištěný projektem IPSS. Z důvodu legislativních omezení ZZVZ musí projekt IPSS smluvní pokrytí, alokace, financování a součinnost dodavatelů infrastruktury zajistit výlučně z vlastních pořizovacích titulů.
Výklad sémantiky RACI: Role A (Accountable) a R (Responsible) jsou záměrně oddělené. Accountable schvaluje a nese konečnou odpovědnost za výsledek; Responsible dílo fakticky realizuje. Jejich umístění u různých stran (např. ÚSÚ schvaluje architekturu, kterou navrhuje IPSS) je korektní stav, nikoli rozpor. Na každém řádku platí pravidlo: právě jedno A a alespoň jedno R.
| Fáze dodávky a integrace | ÚSÚ (Zákazník) | Digitální autorita | Provozovatel | Tým HIP | Tým IPSS |
|---|---|---|---|---|---|
| Řízení smlouvy a koordinace plnění externího dodavatele | I | I | C | I | A/R |
| Architektonický návrh (HLD/LLD) a integrační postupy | A | C | C | C | R |
| Návrh a rekonfigurace firewallů (Management VRF) | C | I | R | I | A |
| Fyzická instalace komponent, kabeláž a zapojení | I | I | C | C | A/R |
| ISMS/KB dokumentace (katalog aktiv, rizika, BIA) | A | C | I | I | R |
| BCM/DR scénáře a IRP playbooky | A | C | R | C | R |
| Konfigurace logování (Syslog TLS, přímý tok do SIEM) | C | A | R | C | R |
| Ověření bezpečnostních restrikcí (L3/L4 konfigurace) | A | C | I | I | R |
| Supply chain security prověření | C | A | I | I | R |
| Technická a provozní akceptace díla od dodavatele | C | C | C | I | A |
| Předání do provozu infrastruktury | C | A | R | I | R |
| Infrastrukturní provoz L1–L3 (Dostupnost linek, HW, routing) | A | R | I | I | I |
| Bezpečnostní provoz L4+ (Analýza incidentů, konfigurace logických politik) | A | C | R | I | I |
Vysvětlivky: A – Accountable (odpovědný za rozhodnutí a schválení), R – Responsible (odpovědný za realizaci), C – Consulted (konzultovaný), I – Informed (informovaný). Zápis A/R značí stranu, která je současně odpovědná za rozhodnutí i za realizaci.
Po úspěšné akceptaci a předání do produkce zaniká projektová struktura a operativní roli přebírá liniová organizační jednotka správce v režimu striktního rozdělení povinností (Segregation of Duties): provozovatel odpovídá za infrastrukturní vrstvu L1–L3 (HW, konektivita, základní směrování), zatímco specializovaný bezpečnostní útvar odpovídá za vrstvy L4+ (konfigurace logických politik, analýza incidentů, vyhodnocování anomálií). Řízení změn po předání do provozu upravuje kap. 9.
6. Prerekvizity pro zahájení implementačních a instalačních prací
Před započetím reálných zásahů do infrastruktury je PM IPSS povinen předložit a obhájit na koordinační schůzce následující body:
- Doložení finančního krytí: Písemné potvrzení správce rozpočtové kapitoly o zajištění krytí OPEX závazku na dobu udržitelnosti vyplývající z příslušného dotačního titulu, doložené v souladu se zákonem č. 320/2001 Sb., o finanční kontrole.
- Schválení bezpečnostní architektury: Písemné stanovisko bezpečnostního architekta ÚSÚ potvrzující soulad s bezpečnostními politikami, zákaz terminace TLS na neoprávněných prvcích, případné omezení integrační vrstvy na úrovni L3/L4 a míru uplatnění principů ZTA.
- Protokol o předání podkladů: Formální převzetí aktuální HLD/LLD dokumentace a adresních plánů od architektů HIP, podepsané věcně příslušnými autoritami obou projektů.
- Schválený harmonogram servisních oken: Odsouhlasení plánovaných výpadků a přepojení perimetrových linek s provozovatelem za účelem minimalizace dopadů na dostupnost běžících služeb.
- Návrh architektury management segmentu: Definice dedikovaného VRF, seznamu schválených vnějších IP prefixů a firewallových pravidel, schválený bezpečnostním architektem ÚSÚ.
- Dokumentace supply chain security: Prokazatelné ověření původu komponent a analýza rizik spojených s geolokací externích zpracovatelských center předložená ke konzultaci Digitální autoritě.
- Návrh end-to-end toku logů: Technické doložení autonomního kanálu do SIEM IPSS s potvrzením šifrovaného přenosu (Syslog over TLS, SNMPv3 authPriv) nebo izolované OOB sítě.
7. Eskalace, lhůty a řešení neplnění prerekvizit
Prerekvizity dle kap. 2 a 6 jsou vymahatelné. Metodika definuje postup pro případ jejich nesplnění nebo pouze formálního splnění (podpis bez věcného obsahu, prázdné šablony).
- Lhůty pro posouzení: HIP posoudí úplnost a věcnou kvalitu dodaných podkladů ve stanovené lhůtě (zpravidla do 10 pracovních dnů). Při neúplnosti vrací podklady IPSS k doplnění s konkrétní lhůtou.
- Věcný (nikoli formální) přezkum: Akceptační kritéria a dokumentace podléhají věcnému přezkumu. Dokument formálně existující, avšak obsahově prázdný nebo nevyplněná šablona, se považuje za nesplněnou prerekvizitu. Kritéria věcné úplnosti klíčových artefaktů stanoví příloha metodiky / dohoda obou projektů.
- Právo na odepření součinnosti: Do splnění prerekvizit jsou HIP i provozovatel oprávněni odepřít alokaci kapacit a součinnost. Nesplnění je legitimním důvodem pro nezahájení nebo pozastavení prací bez sankčního dopadu na HIP.
- Stupně eskalace: PM projektu → řídicí výbor projektu → Digitální autorita (jako arbitr sporů mezi HIP a IPSS) → zřizovatel / nadřízený orgán ÚSÚ. Každý stupeň má definovanou lhůtu pro rozhodnutí.
- Řešení vzájemného sporu HIP × IPSS: Vzhledem k záměrně oddělenému postavení obou projektů (kap. 1) je arbitrem věcných i kapacitních sporů Digitální autorita; její rozhodnutí je pro fázi projektu závazné.
8. Měřitelná akceptační kritéria (rámec)
Metodika nestanovuje konkrétní prahové hodnoty (ty jsou specifické pro každý projekt a dodává je IPSS dle kap. 2), definuje však povinné kategorie měřitelných kritérií a požadavky na jejich formu. Každé kritérium musí být měřitelné, mít definovanou metodu měření, prahovou hodnotu a odpovědnou osobu za verifikaci.
| Kategorie | Příklad metriky (hodnotu doplní projekt) |
|---|---|
| Výkon a latence | Přidaná latence integrovaného (zejm. inline) prvku vůči SLA; propustnost při špičce; režie v záložních stavech. |
| Dostupnost | Maximální povolený dopad na dostupnost během servisního okna; doba do aktivace Fail-Open / HA failover; počet a délka okenních výpadků. |
| Funkční regrese | Sada testů ověřujících, že integrace nezhoršila stávající služby (end-to-end průchodnost, stavové relace). |
| DR / BCM | Minimální sada DR testů; ověření splnění RTO/RPO; úspěšný obnovovací běh dle scénářů. |
| Bezpečnost | Ověření filtrace management VRF; potvrzení zákazu TLS terminace; doložení end-to-end toku logů do SIEM; ověření break-glass účtů. |
Bez doložení splnění kritérií ze všech relevantních kategorií nelze dílo akceptovat (kap. 9).
9. Change management a životní cyklus po předání do provozu
Po předání do provozu projektová struktura IPSS zaniká a řízení změn integrované technologie přechází do standardního provozního režimu správce.
- Iniciace změn: Běžné změny (aktualizace firmware/SW, ladění politik) iniciuje a realizuje provozovatel, resp. bezpečnostní útvar, formou standardního change requestu (RFC) v režimu change/incident managementu správce, při zachování Segregation of Duties dle kap. 5.
- Regrese odolnosti: Každá aktualizace firmwaru či konfigurace inline prvku musí být ověřena z hlediska zachování funkce Fail-Open / HA failover před nasazením do produkce.
- Podstatné změny → opětovné posouzení: Změna, která rozšiřuje rozsah (nová externí konektivita, nová geolokace zpracování dat, změna architektury TLS, přidání nových prvků do datové cesty), spouští opětovné uplatnění relevantních prerekvizit této metodiky (kap. 2, 6) a posouzení bezpečnostním architektem ÚSÚ. Tím se brání obcházení rámce „zadními vrátky”.
- Smluvní kontinuita: Vyžaduje-li změna zásah dodavatele HIP, platí i nadále logika § 222 ZZVZ – takové práce nelze hradit ze smluv HIP a musí být pokryty samostatným pořizovacím titulem vlastníka služby.
- Aktualizace dokumentace: Každá schválená změna se promítá do živé dokumentace dle kap. 10 (zejm. DSP, registr rizik, runbooky).
10. Požadované artefakty a dokumentace
Veškerá dokumentace musí být vyhotovena v elektronické podobě a digitálně podepsána uznávaným elektronickým podpisem příslušných odpovědných osob za ÚSÚ, Digitální autoritu, provozovatele, HIP a IPSS. Artefakty jsou rozděleny podle okamžiku, k němuž musí být splněny. U každého artefaktu musí být předem dohodnut minimální přijatelný obsah; prázdná šablona se nepovažuje za splnění (viz kap. 7).
Skupina A – Prerekvizita zahájení (před zásahem do infrastruktury)
- High-Level Design (HLD) – topologie, logické vazby, provozní a havarijní stavy (failover, izolace komponenty).
- Návrh Low-Level Design (LLD) – síťové schéma, VLAN, adresace, konfigurační parametry, návrh management VRF.
- Návrh architektury management segmentu – VRF, schválené IP prefixy, firewallová pravidla.
- Měřitelná akceptační kritéria + formální souhlas zákazníka (kap. 2 a 8).
- Doložení OPEX krytí a souladu se zákonem o finanční kontrole.
- Stanovisko bezpečnostního architekta (zákaz TLS terminace, L3/L4, míra ZTA).
- Návrh end-to-end toku logů (Syslog over TLS / SNMPv3 authPriv / OOB).
- Dokumentace supply chain security a analýza geolokace zpracování dat (vč. titulu předání dle GDPR, je-li relevantní).
- Schválený harmonogram servisních oken.
Skupina B – Prerekvizita akceptace (před předáním do provozu)
- Dokumentace skutečného provedení (DSP) – reálný stav po implementaci a odladění politik vč. soupisu licencí.
- Konfigurační příručka modulů, správa TLS certifikátů, postupy aktualizace SW/firmware a bezpečnostních definic.
- Katalog aktiv (klasifikace, vlastníci, závislosti), Registr rizik, BIA (RTO/RPO pro scénáře selhání).
- BCM/DR scénáře, testovací protokoly DR (periodicita min. 1×/rok), IRP playbooky, eskalační schémata (interní, dodavatel, národní CERT/CSIRT, připojené subjekty).
- Posouzení z pohledu GDPR (logování, mimopásmový přenos, geolokace zpracování).
- SLA/OLA mezi provozními útvary, technický popis napojení na SIEM, monitorované metriky (SNMPv3 MIB), metodika eskalace.
- Hardening guide výrobce.
- Protokol o ověření měřitelných akceptačních kritérií (kap. 8).
- Akceptační protokol technologie + Předávací protokol do provozu (podepsány ÚSÚ, DA, provozovatelem, HIP, IPSS).
Skupina C – Živá dokumentace v provozu (udržovaná po předání)
- Aktualizovaný DSP a konfigurace po každé schválené změně (kap. 9).
- Provozní model (role, procesy change/incident managementu).
- Průběžně aktualizovaný katalog aktiv a registr rizik.
- Síťové a provozní runbooky vč. postupů při kaskádovém selhání bypass prvků (pokud jsou relevantní).
- Protokoly pravidelných DR/BCM testů.
- Evidence změn (RFC log) s vazbou na opětovné posouzení podstatných změn.
