Veřejný zadavatel, který pořizuje nový informační systém nebo cloudovou službu, stojí před úkolem, který ještě před pár lety neexistoval. Zadavatel musí zároveň správně vysoutěžit zakázku a splnit povinnosti, které mu ukládá zákon o kybernetické bezpečnosti. Tyto dvě roviny se přitom na první pohled tváří jako nepřátelé – bezpečnostní pravidla tlačí na omezení okruhu možných dodavatelů, zatímco zadávací předpisy vyžadují otevřenou soutěž a rovné zacházení. Pokud zadavatel toto napětí nezvládne správně uchopit, riskuje buď sankci od regulátora za nedostatečnou ochranu, nebo napadení výběrového řízení pro diskriminaci uchazečů. V tomto článku vysvětlujeme, kde přesně toto napětí vzniká, jak ho bezpečně překlenout a co konkrétně musí obsahovat smlouva s dodavatelem informačních technologií, aby obstála na obou frontách.
Dvojí role, se kterou se musí veřejný zadavatel naučit žít
Kyberbezpečnost přestala být výhradně technickou agendou IT oddělení. Je to regulatorní povinnost se sankčními důsledky, odpovědností statutárních orgánů a přímým dopadem na způsob zadávání a smluvního ošetření ICT projektů. Veřejný zadavatel (například krajský úřad, nemocnice nebo provozovatel kritické infrastruktury) se ocitá ve dvojí roli – musí férovým a nediskriminačním způsobem soutěžit dodávky IT a zároveň aktivně řídit bezpečnostní rizika spojená s těmito dodavateli. Tyto dvě role si přitom mohou navzájem překážet.
Nový zákon o kybernetické bezpečnosti (č. 264/2025 Sb., dále jen „nZKB") zásadně mění pravidla hry pro veřejné zadavatele. Musejí přitom však nadále soutěžit IT zakázky podle přísných pravidel zákona o zadávání veřejných zakázek (dále jen „ZZVZ"). Jak tyto dva světy sladit v praxi, aniž by výsledkem byl buď nevymahatelný kontrakt, nebo úspěšné odvolání uchazeče u dozorového úřadu?
Co nZKB nově vyžaduje od zadavatelů
Nový zákon o kybernetické bezpečnosti implementuje evropskou směrnici NIS2 a přináší strukturovaný systém povinností. Pro veřejné zadavatele jsou klíčové zejména dva koncepty.
Zaprvé, rozlišení vyššího a nižšího režimu. Subjekty ve vyšším režimu (typicky velcí poskytovatelé klíčových nebo důležitých služeb) mají přísnější povinnosti – podléhají registraci u Národního úřadu pro kybernetickou a informační bezpečnost (NÚKIB), musejí zavést komplexní bezpečnostní opatření a hlásit incidenty v kratších lhůtách. Subjekty v nižším režimu mají povinnosti mírnější, ale stále závazné.
Zadruhé, řízení dodavatelů je výslovně součástí zákonných bezpečnostních opatření. Nestačí tedy mít v pořádku vlastní interní procesy. Povinná je totiž i kontrola nad tím, kdo a jakým způsobem přistupuje k infrastruktuře, datům nebo provozním systémům.
Aktuálně tedy již nestačí „dělat jen ZZVZ". Smlouva s IT dodavatelem, která by ignorovala požadavky nZKB, může totiž zadavatele vystavit nejen regulatorní odpovědnosti, ale i provoznímu riziku v případě kybernetického incidentu.
Co musí smlouva s IT dodavatelem obsahovat
Dobře nastavená smlouva s dodavatelem IT pro regulovaný subjekt by měla pokrývat alespoň těchto pět oblastí:
- Rozhraní odpovědností. Smlouva musí jasně vymezit, která bezpečnostní opatření zajišťuje organizace vlastními silami a která jsou na straně dodavatele. Osvědčenou pomůckou je RACI tabulka nebo přehledný seznam povinností přiložený jako příloha smlouvy – předejde se tím tak sporům v případě incidentu.
- Audit a hlášení incidentů. Zadavatel musí mít smluvně zakotvené právo na audit (ideálně včetně práva využít třetí stranu), jasně definované lhůty pro hlášení bezpečnostních incidentů a povinnost dodavatele poskytnout forenzní součinnost. Tyto lhůty musejí být konzistentní s povinnostmi zadavatele vůči NÚKIB.
- Dodavatelský řetězec. Bezpečnostní povinnosti musejí dopadnout i na poddodavatele. Smlouva by měla obsahovat povinnost dodavatele oznamovat změny v poddodavatelském řetězci, mechanismus reakce na varování NÚKIB a v odůvodněných případech i zákaz konkrétních technologií nebo komponent.
- Přístup k datům a provozním informacím. Zadavatel potřebuje mít kdykoli přístup k informacím o stavu své infrastruktury a k provozním logům. V opačném případě nemůže plnit vlastní povinnosti podle nZKB a reagovat na případný zásah regulátora.
- Exit a kontinuita. Změna dodavatele nesmí sama o sobě vytvořit bezpečnostní riziko. Smlouva by měla řešit předání nebo bezpečnou likvidaci dat, dokumentaci architektury, kryptografické klíče a závazek součinnosti při migraci na nástupnický systém.
Jak to vypadá v praxi: dva přístupy, jeden výsledek
Vezměme modelový příklad: krajský úřad zadává provoz bezpečnostního dohledového centra (SOC) jako službu.
V prvním scénáři jsou bezpečnostní požadavky přidány do smlouvy „na konec" jako standardní příloha převzatá z dřívějšího projektu. Nejsou provázány s architekturou systému, neobsahují konkrétní lhůty pro hlášení incidentů ani mechanismy auditu. V tomto případě se často po prvním závažném incidentu ukáže, že dodavatel nemá povinnost poskytnout logy v čase, kdy to NÚKIB požaduje, a odpovědnost za selhání není jasná.
Ve druhém scénáři zadavatel před zahájením zadávacího řízení zpracuje analýzu rizik, která je podkladem pro zadávací podmínky. Bezpečnostní požadavky jsou poté promítnuty do kvalifikačních předpokladů i hodnoticích kritérií. Smlouva pak obsahuje strukturované přílohy s rozhraním odpovědností, lhůtami pro hlášení incidentů a exit protokolem. Výsledkem je situace, kdy zadavatel je schopen prokázat soulad s nZKB a v případě incidentu rychle reagovat.
Rozdíl mezi těmito dvěma přístupy není v délce smlouvy. Je to o tom, kdy a jak se o bezpečnosti začne přemýšlet. Pokud se o ní začne přemýšlet až „na poslední chvíli“, pak se velmi často jedná o nefunkční nastavení. Navíc tato nefunkčnost se projeví až v případě nějakého kritického incidentu, což je již pozdě. Komplexní uchopení celé problematiky hned na začátku je sice časově náročnější, ale výsledkem je přesně to, co je cílem regulace kyberbezpečnosti – předcházet kybernetickým incidentům a minimalizovat jejich dopady na fungování státu, firem i jednotlivců.
Závěr: co si z toho odnést
Nový zákon o kybernetické bezpečnosti nepřidává pouze novou vrstvu compliance. Mění způsob, jakým musejí veřejní zadavatelé přistupovat k celému životnímu cyklu ICT projektu – od přípravy zadávací dokumentace přes výběr dodavatele až po smluvní podmínky a jejich pravidelnou revizi.
Praktická doporučení:
- Analýzu rizik proveďte před zahájením zadávacího řízení, ne až při přípravě smlouvy.
- Bezpečnostní požadavky promítněte do kvalifikačních podmínek a hodnoticích kritérií – ne jen do příloh smlouvy.
- Revidujte stávající smlouvy s IT dodavateli z pohledu nZKB, zejména pokud byly uzavírány před účinnosti nZKB.
- Zajistěte použitelnost bezpečnostních povinností na celý dodavatelský řetězec.
- Připravte exit scénáře dříve, než budete potřebovat změnit dodavatele.
Tým HAVEL & PARTNERS dlouhodobě pomáhá veřejným zadavatelům i IT dodavatelům propojovat požadavky kybernetické bezpečnosti, zadávacího řízení a smluvní praxe. Pokud řešíte nastavení zadávací strategie, přípravu smluvních vzorů nebo revizi stávajících kontraktů tak, aby byly funkční a současně obstály jak před regulátorem, tak před Úřadem pro ochranu hospodářské soutěže, rádi se do toho s Vámi pustíme společně.
