ÚOHS S0682/2021/VZ – Centrální Log Management

Zadavatel – Česká pošta, s.p., IČO 47114983, se sídlem Politických vězňů 909/4, 225 99

Podle bodu 2.1 zadávací dokumentace je předmětem veřejné zakázky „dodávka software pro centrální sběr a management logů pro Českou poštu, s. p. včetně hardware, software a potřebných licencí k jeho provozování, jeho implementace a poskytování podpory a údržby (support & maintenance) po dobu 48 měsíců od akceptace dodaného řešení.“

Dne 22. 7. 2021 rozhodl zadavatel o výběru dodavatele – AXENTA a.s., IČO 28349822, se sídlem

Proti rozhodnutí o výběru navrhovatel podal dne 10. 8. 2021 námitky z téhož dne (dále jen „námitky“). Rozhodnutím o námitkách ze dne 23. 8. 2021 (dále jen „rozhodnutí o námitkách č. 1“), které bylo navrhovateli doručeno téhož dne, zadavatel citované námitky navrhovatele odmítl. Vzhledem k tomu, že navrhovatel nepovažoval rozhodnutí o námitkách za učiněné v souladu se zákonem, podal dne 2. 9. 2021 návrh na zahájení řízení o přezkoumání úkonů zadavatele Úřadu (dále jen „návrh ze dne 2. 9. 2021“), které Úřad vedl pod sp. zn. ÚOHSS0379/2021/VZ.

Ve správním řízení sp. zn. S0379/2021/VZ Úřad rozhodnutím č. j. ÚOHS-39240/2021/500/AIv ze dne 19. 11. 2021 zrušil rozhodnutí o námitkách č. 1. Zadavatel s ohledem na citované rozhodnutí Úřadu rozhodl znovu o námitkách navrhovatele rozhodnutím o námitkách ze dne

Vzhledem k tomu, že navrhovatel s rozhodnutím o námitkách nesouhlasil, podal dne

Navrhovatel úvodem v čl. I návrhu rekapituluje dosavadní průběh zadávacího řízení. Následně navrhovatel objasňuje důvody, jež ho vedly k podání návrhu.

V čl. II návrhu navrhovatel shrnuje důvody nezákonnosti postupu zadavatele, přičemž má za to, že

a. řešení nabízené vybraným dodavatelem nesplňuje všechny požadavky zadavatele na nástroj pro Log Management stanovené v příloze č. 1 s názvem „Technická specifikace Nástroje/Řešení a Podpory (funkční a technické požadavky)“ přílohy č. 6 zadávací dokumentace – Vzor smlouvy (dále jen „příloha č. 1 smlouvy“), přičemž zadavatel měl dle navrhovatele přistoupit k vyloučení vybraného dodavatele ze zadávacího řízení, a tím, že tak neučinil, porušil ustanovení § 48 odst. 2 spím. a) zákona ve spojení s § 48 odst. 9 zákona. b. zadavatel nesprávně posoudil mimořádně nízkou nabídkovou cenu (dále jen „MNNC“) obsaženou v nabídce vybraného dodavatele, neboť za jím nabízenou cenu není a ani nemůže být zajištěno plnění veřejné zakázky.

Konkrétně navrhovatel uvádí, že nástroj vybraného dodavatele dle uživatelského manuálu v rozporu s bodem 304 přílohy č. 1 smlouvy neumožňuje aktualizaci systému v jednom kroku a v jednotném balíku prostřednictvím centrální konzole a neumožňuje ani rolling upgrade.

Navrhovatel dále uvádí, že v době podání tohoto návrhu nedisponuje přístupem k nabídce vybraného dodavatele ani k neveřejné části dokumentace nástroje LogMan.io. V tomto kontextu navrhovatel žádá Úřad, aby si podklady k nástroji Logman.io od společnosti

K námitce, že „nabízený nástroj navíc v rozporu s bodem 506 Přílohy č. 1 negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), přičemž nesplnění těchto požadavků je v přímém rozporu s bodem 901 Přílohy č. 1 smlouvy“, pak navrhovatel dodává, že argumentace zadavatele týkající se režimu write-once, která má být dle zadavatele zajištěna pomocí kryptografických funkcí, je absurdní. Dle navrhovatele kryptografické funkce mohou napomoci předejít pozměnění logů, v žádném případě však nemohou napomoci zabránit jejich smazání. Použití kryptografických funkcí tak dle názoru navrhovatele zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání.

Navrhovatel je dle svých slov nadále přesvědčen, že v rozporu s požadavkem dle bodu č. 201 přílohy č. 1 smlouvy nástroj vybraného dodavatele neumožňuje hardwarovou appliance, ale toliko appliance virtuální. Navrhovatel je přitom přesvědčen, že by vybraný dodavatel nemohl hardware dle požadavků zadavatele dodat s ohledem na jeho velmi nízkou nabídkovou cenu.

Navrhovatel má dále za to, že nástroj vybraného dodavatele v rozporu s body 101 až 144 přílohy č. 1 smlouvy nepodporuje sběr, parsování a normalizaci logů požadovaných platforem a technologií. K tomu navrhovatel uvádí, že v námitkách zcela jednoznačně označil, že nástroj

Mnoho z údajně produktem LogMan.io podporovaných technologií potřebuje dle navrhovatele složitou konfiguraci nejen v rámci LogMan.io, ale i jeho komponent.

K tabulce a dokumentaci LogMan.io, na kterou odkazoval vybraný dodavatel ve svých vyjádřeních v rámci správního řízení sp. zn. ÚOHS-S0379/2021/VZ, navrhovatel uvádí, že uvedené specifikuje parsování pouze zlomku zadavatelem požadovaných zdrojů. Z této části dokumentace pak zároveň vyplývá, že u zdrojů, které jsou podporovány, dochází k parsování pouze hlaviček logů daných zdrojů, nikoliv jejich vlastního obsahu. Výjimku tvoří pouze logy, které jsou předávané ve strukturovaném formátu (zde formáty CEF a JSON), kde je parsování algoritmizované již samotným formátem předávaných dat. Dle navrhovatele je zřejmé, že ačkoliv celá tabulka na první pohled působí dojmem, že nástroj LogMan.io podporuje parsování všech logů a technologií požadovaných zadavatelem, a to v zadavatelem požadovaném rozsahu, po jejím důkladném prostudování nezbývá než dojít k závěru, že tomu tak není. Z tabulky je přitom dále dle navrhovatele evidentní neznalost dotčené problematiky vybraným dodavatelem a také to, že nástroj LogMan.io parsování a normalizaci některých zdrojů podporovat nemůže.

Navrhovatel poukazuje na to, že např. ve vztahu k podpoře MS Azure Cloud vybraný dodavatel uvádí, že logy z této platformy budou získávány prostřednictvím transportního protokolu.

Ve vztahu k požadavku na podporu platformy Microsoft SQL pak vybraný dodavatel odkazuje na Microsoft SQL Server 2008, přičemž se dle navrhovatele jedná o již dlouhou dobu

Ve vztahu k požadavku na normalizaci a parsování logů ze zdroje Microsoft – any logs from

Navrhovatel je zároveň nadále přesvědčen, že nástroj nabízený vybraným dodavatelem nemá v rozporu s bodem 153, 154 a 159 přílohy č. 1 smlouvy nijak řešenu zálohu a obnovu konfigurací celého nástroje z centrální konzole a rovněž neumožňuje nastavení nezávislé zálohovací politiky, což dle navrhovatele vyplývá zejména z uživatelského manuálu tohoto nástroje. Dokumentace nástroje LogMan.io dle navrhovatele nepopisuje a ani nezmiňuje v žádném bodě zálohování nebo obnovování konfigurace systému jako celku prostřednictvím centrální konzole a způsob zpracování zálohy konfigurace.

K tomu v reakci na rozhodnutí o námitkách dále navrhovatel uvádí, že požadavek na možnost nastavení nezávislé zálohovací politiky rozhodně nezahrnuje pouze možnost určit, kde se data nachází. Pokud má nástroj umožňovat nastavení nezávislé zálohovací politiky, nestačí pouze pokud je schopen identifikovat, kde se data v systému nachází, ale musí také z logiky věci umožňovat nastavení, kdy a v jakém rozsahu mají být zálohy prováděny a takto nastavené zálohování také provést, a to sám o sobě. Současně navrhovatel poukazuje na to, že dle jeho názoru sám zadavatel v rozhodnutí o námitkách potvrzuje, že nástroj LogMan.io (ani žádná z jeho komponent či jiných částí plnění poskytovaných vybraným dodavatel) neumožňuje tvorbu záloh, přičemž logicky nemůže umožňovat ani tvorbu zálohovací politiky. Dále navrhovatel k argumentu zadavatele, že zálohovací politika je implementována pomocí „Index

Daný nástroj pak také dle názoru navrhovatele v rozporu s bodem 145 přílohy č. 1 smlouvy neumožňuje přístup více uživatelů současně. Ani tato funkcionalita totiž dle navrhovatele z veřejně dostupných dokumentů nevyplývá a zadavatel v rozhodnutí o námitkách pouze konstatoval, že nástroj tuto funkcionalitu podporuje a ničím relevantním tuto skutečnost nepodložil.

Navrhovatel také dále trvá na námitce, že daný nástroj v rozporu s body 146 a 166 přílohy č. 1 smlouvy neumožňuje snadné vytváření a definování uživatelských rolí s možností definice přístupových práv a granulárního přidělování práv v rámci rolí, podle zdrojů logů, skupin

Ani ve vztahu k námitce, že nástroj dle uživatelského manuálu zároveň v rozporu s bodem 304 přílohy č. 1 smlouvy neumožňuje aktualizaci systému v jednom kroku a v jednotném balíku prostřednictvím centrální konzole a neumožňuje ani rolling upgrade, a v rozporu s bodem 305 přílohy č. 1 smlouvy neumožňuje ani downgrade, přičemž veškerá konfigurace není verzována ve version control systému (Git) tak, aby byla zajištěná vysoká úroveň kontroly nad provozním nastavením systému včetně možnosti návratu k předchozí verzi konfigurace, zadavatel dle navrhovatele neuvedl v rozhodnutí o námitkách žádnou relevantní argumentaci, která by tento závěr navrhovatele vyvracela.

K uvedenému navrhovatel dále doplňuje, že zadavatelem odkazované části dokumentace nástroje Logman.io neprokazují jím tvrzené skutečnosti, ale pravý opak. Navrhovatel mj. uvádí, že část dokumentace nástroje LogMan.io1 obsahuje informace prokazující, Logman.io používá pro správu verzí nástroj GIT, že jsou jednotlivé komponenty Logman.io zabaleny a provozovány v dockeru a že pro správu docker kontejneru používá docker-compose. Proces aktualizace je dle navrhovatele následující: 1. git pull; 2. docker-compose pull; 3. dockercompose up -d. Dle navrhovatel se tedy proces aktualizace se v případě nástroje LogMan.io skládá ze tří kroků a nikoliv jednoho, jak se snaží tvrdit zadavatel. Tato skutečnost je přitom v přímém rozporu s požadavkem zadavatele dle bodu 304 přílohy č. 1 smlouvy na umožnění aktualizace v jednom kroku. Další skutečností je dle navrhovatele to, že z žádné části veřejné dokumentace není zřejmé, že by se aktualizace systému prováděla jinak, než pomocí nástrojů pro příkazovou řádku git, docker, docker-compose. Vzhledem k tomu, že SSH shell, prostřednictvím které jsou výše uvedené příkazy používány, nelze považovat za „centrální konzoli“ ve smyslu požadavku dle bodu 304 přílohy č. 1 smlouvy, je dle navrhovatele zřejmé, že nástroj LogMan.io nesplňuje ani požadavek na aktualizaci prostřednictvím centrální konzole. K tomu navrhovatel dále ve svém návrhu odkazuje na strukturu nástroje Logman.io.

Skutečnost, že SSH shell příkaz docker-compose nelze považovat za provedení aktualizace prostřednictvím centrální správcovské konzole, jelikož spravuje pouze microservice spuštěné na tom konkrétním node, kde příslušný uživatel daný příkaz spustí, pak dle navrhovatele prokazuje tvrzení samotného vybraného dodavatele uvedeného v rámci vyjádření ve správním řízení sp. zn. ÚOHS-S0379/2021/VZ. Sám zadavatel navíc dle navrhovatele odkazuje na centrální konzoli (která dle navrhovatele není v dokumentaci nástroje vůbec zmíněna, natož snad popsána) jako na SSH konzoli k systému. Lze přitom s jistotou tvrdit, že se nejedná o centrální konzoli, nýbrž o konzoli k jednomu systému v rámci clusteru. Dle navrhovatele je tedy zřejmé, že požadavek na aktualizaci systému prostřednictvím centrální konzole není

Ani využití architektury microservices dle navrhovatele nezaručuje splnění zadavatelova požadavku na průběh aktualizace (Rolling upgrade atd.), když i při jejím využití se může výrobce systému rozhodnout takovou funkcionalitu neimplementovat a tím při vývoji nástroje ušetřit čas a náklady. Nástroj nabízený vybraným dodavatelem tak požadavek zadavatele dle bodu 304 přílohy č. 1 smlouvy nesplňuje, když neumožňuje aktualizaci celého nástroje prostřednictvím centrální konzole.

Navrhovatel je i nadále přesvědčen, že nástroj nabízený vybraným dodavatelem v rozporu s bodem 401 a 506 přílohy č. 1 smlouvy nezabezpečuje data proti jejich modifikaci nebo smazání a zároveň umožňuje mazání nebo modifikování již uložených logů. Zadavatelem odkazované kryptografické funkce nemohou splnění těchto zadávacích podmínek nástrojem zajistit. Použití kryptografických funkcí zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je dle navrhovatele přitom v přímém rozporu s bodem 401 a 506 přílohy č. 1 smlouvy a je tak dle jeho názoru zřejmé, že se zadavatel s námitkou toho, že nástroj umožňuje v rozporu s požadavky zadavatele mazání a modifikaci logů, řádně nevypořádal.

Z veřejně dostupné dokumentace a rozhodnutí o námitkách č. 2 nástroje dle navrhovatele vyplývá, že jeho instalaci provádí sám uživatel (zde zadavatel), přičemž v takovém případě musí mít přístup k root oprávněním celého systému. V takovém případě však zadavatel, respektive jím pověřená osoba, může využít těchto root oprávnění a smazat jak samotný systém, tak všechna data, která jeho prostřednictvím byla uložena. Současně navrhovatel uvádí, že s ohledem na to, co uvádí zadavatel v rozhodnutí o námitkách, tak navrhovatel má za to, že vybraný dodavatel svým nástrojem porušuje pravidla poskytnutí licence komponenty

Navíc i v případě, že by instalaci neprováděl samotný uživatel, je navrhovatel přesvědčen, že z veřejné části dokumentace nástroje LogMan.io vyplývá, že root přístup bude zachován minimálně zástupci vybraného dodavatele/výrobci nástroje LogMan.io, případně jiné osobě provádějící instalaci nástroje. V takovém případě bude mít vždy daná osoba možnost smazat celý systém včetně všech jeho uložených logů, což je v rozporu s požadavkem zadavatele v bodu 506 přílohy č. 1 smlouvy, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky, přičemž nesplnění těchto požadavků je v přímém rozporu rovněž s bodem 901 přílohy č. 1 smlouvy.

Co se týče dříve předloženého znaleckého posudku, navrhovatel konstatuje, že z něj žádným způsobem nevyplývá, jak znalec došel k závěru, že nástroj LogMan.io splňuje všechny legislativní požadavky dle vyhlášky. Z obrázků ani skutečností uvedených ve znaleckém posudku totiž nevyplývá nic, na čem by bylo uvedený závěr možné postavit. V tomto kontextu se tedy jeví jako vhodné, aby Úřad v souladu se zásadou materiální pravdy nechal zpracovat

Co se týče námitky, že nástroj v rozporu s body 510 a 511 přílohy č. 1 smlouvy neumožňuje definici a zasílání alertů (upozornění) pomocí SMTP, přičemž v rozporu s bodem 810 a 813 přílohy č. 1 smlouvy ani nedisponuje předpřipravenými alerty (upozorněními) a pohledy na uložená data dle kategorií a logického členění a nepodporuje jejich zasílání v různých formátech PDF, HTML a CSV příp. dalších, a námitky, že v nástroji rovněž chybí předdefinované pohledy na uložená data, tzv. dashboardy dle bodů 705 a 706 přílohy č. 1 smlouvy, podle navrhovatele zadavatel nijak nepotvrdil, že by stejné formáty byly podporovány také v rámci odesílání alertů pomocí SMTP, přičemž navrhovatel má dále za to, že použitá komponenta

Ve vztahu k námitce, že v rozporu s bodem 512 přílohy č. 1 neumožňuje nástroj konfiguraci notifikací pomocí grafického vizuálního programovacího jazyka formou obrázků obsahujících aplikační logiku, neboť celá konfigurace probíhá prostřednictvím příkazových řádek zadáváním písemných příkazů, navrhovatel konstatuje, že argumentace zadavatele k této námitce uvedená v rozhodnutí o námitkách není pravdivá, nebo přinejmenším není ze strany zadavatele podložená relevantními podklady. Sám zadavatel dle navrhovatele v poznámce pod čarou č. 6 uvádí odkaz na LogMan.io, avšak z tohoto odkazu je dle navrhovatele zřejmé, že LogMan.io žádným grafickým vizuálním prostředím pro tvorbu aplikační logiky nedisponuje, když veškeré programování probíhá pomocí příkazového řádku, tedy ve formě textu.

Navrhovatel k tomu dále uvádí, že dokumentace k produktu LogMan.io neobsahuje žádnou zmínku o podpoře vizuálního programování. Poznámka pod čarou číslo 9 rozhodnutí o námitkách č. 2 totiž dle navrhovatele obsahuje odkaz na deklarativní jazyk používaný pro psaní parserů v rámci produktu LogMan.io, nikoliv na zadávací dokumentací požadované použití vizuálního programovacího jazyka. Dle veřejně dostupné dokumentace, na kterou zadavatel odkazuje, je dle navrhovatele zřejmé, že produkt LogMan.io nemá integrovanou grafickou nadstavbu používající aplikační logiku pro vizuální programování. „SP-Lang“ je navíc termín, jehož obsah není zadavateli, ale ani obecně v dotčeném odvětví známý (což dle navrhovatele vyplývá i z toho, že tento pojem nelze vyhledat prostřednictvím internetového vyhledávače a není ani popsán na wikipedii). Navrhovateli tedy není zřejmé, co se snaží zadavatel poukazem na tento „jazyk“ prokázat. Navrhovateli ani není zřejmé, jak zadavatel k tomuto „pojmu“ přišel, přičemž zde je důvodné se domnívat, že zadavatel cituje „nějaký“ podklad od vybraného dodavatele, aniž by bylo zřejmé, zda předmětný podklady byl součástí nabídky, nebo byl opatřen od vybraného dodavatele v souvislosti s přípravou vyjádření k návrhu. Druhá z obou možnosti by pak zjevně indikovala rozpor se zásadou transparentnosti a rovného přístupu.

Dále navrhovatel uvádí, že ze zadavatelem tvrzené kombinace prostředí YAML a deklarativního jazyka SP-Lang splnění požadavku na programování prostřednictvím obrázků nevyplývá. YAML je dle navrhovatele textový formát, který specifikuje strukturu dokumentu (textu), přičemž česká ani anglická wikipedie k prostředí YAML, ani hlavní web tohoto formátu, a dokonce ani manuál LogMan.io nezmiňují žádnou možnost práce s tímto formátem prostřednictvím obrázků (vizuálně).

Ani ve vztahu k absenci překladu dokumentace nástroje a veškerého jeho konfiguračního a nástrojového rozhraní do českého jazyka zadavatel dle navrhovatele neuvedl žádné konkrétní skutečnosti, o které by opřel svá tvrzení, že nástroj nabízený vybraným dodavatelem tyto požadavky zadavatele splňuje.

Ze všeho výše uvedeného tak dle navrhovatele vyplývá, že nabídka vybraného dodavatele byla zpracována v rozporu se zadávacími podmínkami a vybraný dodavatel měl být tedy v souladu s ustanovením § 48 odst. 2 písm. a) nebo c) zákona, ve spojení s ustanovením § 48 odst. 8 zákona ze zadávacího řízení vyloučen. To se ovšem nestalo a zadavatel místo toho přistoupil k odeslání oznámení o výběru, čímž se dle navrhovatele dopustil porušení ustanovení § 48 odst. 8 zákona.

Nadto navrhovatel upozorňuje, že není přípustné, aby vybraný dodavatel po uplynutí lhůty pro podání nabídek daný software nějak dále upravoval a tím fakticky měnil podstatu své nabídky, resp. dodávané plnění, přičemž k okamžiku uplynutí lhůty pro podání nabídek nástroj

V čl. IV návrhu se navrhovatel vyjadřuje k nesprávnému posouzení MNNC, přičemž uvádí, že zadavatel nepostupoval způsobem, který vyžaduje zákon a rozhodovací praxe, když si zřejmě zdůvodnění MNNC od vybraného dodavatele vůbec nevyžádal, nebo pokud si jej vyžádal, toto vyjádření dostatečně kriticky nepřezkoumal. Pokud by tak totiž učinil, musel by dle navrhovatele dojít k jednoznačnému závěru, že předmět veřejné zakázky nelze vůbec za nabídkovou cenu vybraného dodavatele realizovat, pokud by vybraný dodavatel měl dodržet všechny zákonem a zadavatelem stanovené povinnosti ve smyslu § 113 odst. 4 písm. a) zákona nebo pokud by vybraný dodavatel neobdržel neoprávněnou veřejnou podporu dle § 113 odst. 4 písm. b) zákona. Zadavatel tak i tímto svým postupem zatížil dle navrhovatele zadávací řízení vadou, když v rozporu s § 6 odst. 1 zákona, a tedy v rozporu se zásadou přiměřenosti a transparentnosti, a rovněž v rozporu s ustanovením § 113 odst. 1 zákona neprovedl řádné posouzení zákona obsažené v nabídce vybraného dodavatele, a když v rozporu s § 113 odst. 6 vybraného dodavatele ze zadávacího řízení nevyloučil. Současně navrhovatel odkazuje na svou argumentaci uvedenou v námitkách, kde nad výše uvedené uvádí, že nabídka vybraného dodavatele byla nízká ve srovnání s nabídkami ostatních dodavatelů a taktéž ve srovnání s předpokládanou hodnotou veřejné zakázky.

Závěrem návrhu navrhovatel shrnuje, že nabídka vybraného dodavatele nesplňuje požadavky zadavatele, zákona a vyhlášky, přičemž vybraný dodavatel měl být z tohoto důvodu v souladu s § 48 odst. 2 písm. a) nebo c) zákona vyloučen a zadavatel měl dle § 48 odst. 8 zákona povinnost takto učinit, což se ovšem nestalo. Navrhovatel je také přesvědčen, že nabídka vybraného dodavatele obsahuje MNNC, kterou vybraný dodavatel nemůže řádně zdůvodnil, a charakter MNNC vybraného dodavatele, v kombinaci s nedostatky jím nabízeného řešení, jednoznačně znemožňuje řádné plnění předmětu veřejné zakázky. S ohledem na uvedené navrhovatel navrhuje, aby Úřad rozhodl o návrhu tak, že zadavatel nedodržel postup stanovený zákonem, a aby uložil zadavateli opatření k nápravě spočívající ve zrušení rozhodnutí o výběru i všech navazujících úkonů, a aby zavázal zadavatele, aby následně

Podle § 249 zákona ve spojení s § 44 odst. 1 zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád“) bylo zahájeno správní řízení o přezkoumání úkonů zadavatele dne 27. 12. 2021, kdy Úřad obdržel návrh navrhovatele. Předmět správního řízení je vymezen obsahem uvedeného návrhu.

Účastníky správního řízení podle § 256 zákona jsou: • zadavatel, • navrhovatel, • vybraný dodavatel.

Zahájení správního řízení oznámil Úřad jeho účastníkům oznámením č. j. ÚOHS44335/2021/511/KZa ze dne 28. 12. 2021.

Dne 6. 1. 2022 Úřad od zadavatele obdržel dokumentaci o zadávacím řízení. Tentýž den Úřad rovněž obdržel vyjádření zadavatele k návrhu z téhož dne (dále jen „vyjádření k návrhu“).

Zadavatel v prvé řadě uvádí, že navrhovatelův návrh se obsahově shoduje s návrhem ze dne

Zadavatel zdůrazňuje zejména to, že navrhovatel neustále setrvává v té argumentační rovině, kdy by za jediné řádné vypořádání jeho námitek považoval předložení, resp. praktickou demonstraci funkčnosti řešení vybraného dodavatele. To však zadavatel považuje za nemožné, přičemž analogicky řečeno jde dle jeho názoru v daném případě o totéž, jako by v zakázce na zhotovení stavby navrhovatel žádal po zadavateli za účelem ověření např. správnosti statických výpočtů či tepelně izolačních vlastností stavby zhotovení samotné stavby.

Dále zadavatel upozorňuje na to, že navrhovatel ve svém návrhu odkazuje na přílohu návrhu, která mu nebyla však zaslána. Zadavatel v tomto ohledu má za to, že navrhovatel nesplnil svou povinnost uloženou mu v § 251 odst. 1 a 2 zákona, neboť návrh neobsahuje všechny písemné důkazní prostředky, na které se navrhovatel odvolává (resp. takto byl alespoň zadavateli zaslán), což mj. dle zadavatele znamená, že přinejmenším zadavateli nebyl v zákonné lhůtě dle § 251 odst. 2 zákona návrh doručen v kompletní podobě.

Zadavatel uvádí, že z důvodu nezaslání příloh návrhu se není objektivně schopen vyjádřit k argumentaci obsažené v odst. 35 až 43, 63 a 64 návrhu č. 2, neboť pro takové vyjádření nedisponuje potřebnými podklady. I přes uvedené zadavatel uvádí, že údajné tvrzení vybraného dodavatele obsažené v první větě odst. 41 návrhu č. 2 zadavatel v dokumentaci předložené vybraným dodavatelem v rámci zadávacího řízení nikde nenalezl. Navíc zadavatel požaduje podporu platformy MS SQL bez uvedení verze obecně a vybraný dodavatel potvrzuje, že předmětný systém toto splňuje.

K tvrzením navrhovatele obsaženým v odst. 33 návrhu č. 2 zadavatel uvádí, že zde navrhovatel toliko spekuluje o tom, že podpora zpracování logů získaných z platformy AZURE je složitá a není časově možné ji zvládnout. To je ovšem velmi zavádějící tvrzení, které je postaveno čistě na subjektivním pocitu či dojmu. Z hlediska zadavatele je podstatné to, že vybraný dodavatel uvedl, že je schopen plnění poskytnout, přičemž zadavatel nemá rozumné důvody zpochybňovat to, že vybraný dodavatel disponuje zkušeností s implementací, a jeho deklaraci, že jím nabízený produkt uvedené podporuje a on má znalosti potřebné k implementaci navrhovaného řešení.

Tvrzení navrhovatele obsažená v odst. 34 návrhu č. 2 pak zadavatel považuje předně za zmatečná, neboť čistě z textace jmenovaného odstavce zadavateli není jasné, co přesně chce navrhovatel říci, resp. uvedené chápe nejvýše jako nepodloženou spekulaci, že bude nutno v rámci řešení vybraného dodavatele implementovat další API.

Ke skutečnostem uváděným v odst. 47 až 50 návrhu č. 2 zadavatel nejprve uvádí, že citace uvedená v odst. 48 návrhu č. 2 je vytržena z kontextu, resp. následné závěry navrhovatele zcela zjevně ignorují zbytek textu odst. 16 rozhodnutí o námitkách č. 2, kde je tvorba záloh a zálohovací politiky v řešení vybraného dodavatele popsána. Argumentace navrhovatele se pro zadavatele nepochopitelně omezuje na tvrzení, že nástroj nabízený vybraným dodavatelem sám o sobě nevytváří kopie určené k zálohování (byť i toto v něm provést lze), přičemž ignoruje úvod odpovědi zadavatele, v níž je popsáno, že předmětný nástroj poskytuje připravená data k zálohování a umožňuje potom obecnými nástroji zálohu vytvořit.

V případě odst. 79 návrhu č. 2 pak zadavatel poukazuje na to, že se navrhovatel snaží překrucovat argumentaci, kterou zadavatel uvedl ve svých dřívějších vyjádřeních.

K podmínce grafického vizuálního prostředí pro tvorbu aplikační logiky zadavatel opětovně uvádí, že produkt TeskaLabs LogMan.io nabízený vybraným dodavatelem v jeho nabídce obsahuje výkonný deklarativní jazyk SP-Lang, přičemž tento jazyk je používán pro tvorbu vlastních parserů, normalizaci, logů, vytváření korelací a konfiguraci notifikací. SP-Lang poskytuje dle navrhovatele i grafické vizuální prostředí pro tvorbu aplikační logiky. Svým uživatelům pak umožnuje vytvářet jednoduchou formou vysoce výkonné konfigurace respektive deklarace. LogMan.io nabízí i možnost práce přes příkazový řádek (CLI), což je varianta preferovaná pokročilými uživateli, kteří chtějí mít absolutní kontrolu nad provozem nástroje nebo požadují hlubokou integraci např. v rámci SOCu (Security Operation Centre).

Ke skutečnostem uvedeným v odst. 86 návrhu č. 2 zadavatel uvádí, že především vůbec nereflektují realitu kontraktačního procesu v rámci zadávání veřejných zakázek. Zadavatel dle

V návaznosti na uvedené a dále k tvrzením a závěrům navrhovatele obsaženým v odst. 87 návrhu č. 2 zadavatel uvádí, že nástroj LogMan.io není dle vědomostí zadavatele nabízen výlučně jako plnění této veřejné zakázky, ale výrobce jej distribuuje i jiným svým klientům. Je přitom dle zadavatele logické, že jeho výrobce nemůže zastavit jeho vývoj jen proto, že figuruje jako poddodavatel určité veřejné zakázky. Taková představa je obzvláště v tak dynamickém sektoru, jako je vývoj IT, dle zadavatele naprosto absurdní.

Co se týká odkazu na metadata příloh č. 1 až 4 rozhodnutí o námitkách č. 2 v odst. 87 návrhu

Zadavatel dále doplňuje, že v obecné rovině nabídka sama o sobě nemůže obsahovat bez dalšího úplně vše, na co se může navrhovatel teoreticky zeptat, neboť to by součástí nabídky de facto muselo být její vlastní a kompletní plnění, což jednoduše není reálné (v tomto konkrétním případě by opět musel zadavatel požadovat předložení funkčního řešení již v nabídkách, k čemuž se zadavatel již vyjadřoval výše).

Co se týká posouzení MNNC v nabídce vybraného dodavatele, zadavatel uvádí, že problematiku technické relevance nabídky a mimořádně nízké nabídkové ceny samozřejmě posuzoval ve vzájemných souvislostech, neboť jinak dle názoru zadavatele ani postupovat nelze, jelikož (ne)relevanci ceny ve smyslu případné existence MNNC je třeba vždy porovnávat s konkrétně nabídnutým plněním. Uvedené ostatně vyplývá dle názoru zadavatele přímo z obsahu jeho žádosti o vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny zaslané vybranému dodavateli dne 16. 6. 2021. Jelikož pak k otázce MNNC navrhovatel v příslušné části návrhu č. 2 neuvedl nic, co by již nebylo obsaženo v návrhu č. 1, zadavatel opětovně odkazuje na své vyjádření ze dne 13. 9. 2021 a rovněž na závěry Úřadu obsažené v odst. 106 rozhodnutí č. 1.

Ve svém vyjádření ze dne 13. 9. 2021 zadavatel k námitce navrhovatele týkající se hardwarové appliance zadavatel uvádí, že byť nástroj LogMan.io lze dodávat i provozovat jako virtuální appliance, tato varianta nebyla pro plnění veřejné zakázky vybraným dodavatelem zvolena.

K tvrzením navrhovatele týkajícím se režimu write-once zadavatel uvádí, že režim write-once, jak napovídá již prostý překlad, znamená „zápis jednou“. V praxi to znamená, že nástroj umožňuje pouze jeden zápis, který je originální a neměnný, a jelikož produkt LogMan.io v tomto režimu pracuje, tak tímto deklaruje, že jakýkoli uložený údaj nelze nijak modifikovat.

Tvrzení navrhovatele o možném zneužití root oprávnění je dle zadavatele zavádějící, neboť popisovaná možnost kompromitace produktu (SW nástroje) naprosto nesouvisí s jeho vlastnostmi. Každá aplikace musí pro svůj provoz mít roli root (superadmin) pro zajištění privilegovaných operací. Pravidla pro provádění privilegovaných oprávnění má ovšem zadavatel zakotvena a velmi detailně popsána v rámci systému pro řízení uživatelů (Identity management) a systému pro řízení privilegovaných účtů (Privileged identity management), což je součástí komplexního systému pro řízení kybernetické bezpečnosti zadavatele. Ochrana privilegovaných oprávnění či účtů však není předmětem veřejné zakázky, jak navozuje navrhovatel, pročež uvedená námitka je dle zadavatele neopodstatněná.

Zadavatel dále dodává, že vybraný dodavatel podáním nabídky, resp. souhlasem s obchodními podmínkami (tj. návrhem smlouvy), potvrzuje, že jím nabízené řešení je v souladu s požadovanými licenčními podmínkami zadavatele, což v praxi znamená, že pokud dojde k jejich porušení, pak vybraný dodavatel odpovídá za z toho vzešlé následky (škody), což je v závazném návrhu smlouvy jednoznačně deklarováno. Jelikož zadavatel po prozkoumání informací jemu dostupných jak z veřejně dostupných zdrojů, tak těch uvedených v nabídce vybraného dodavatele a ve vysvětlení nabídky, neshledal žádný relevantní důvod pro pochybnosti v tomto směru, pak má za to, že převzetí zmíněného smluvního závazku vybraným dodavatelem mu v tomto ohledu poskytuje dostatečnou záruku.

Dále se zadavatel postupně vyjadřuje k jednotlivým požadavkům, které dle navrhovatele nástroj vybraného dodavatele nesplňuje, a vysvětluje, proč je podle něj tento názor navrhovatele nesprávný.

K otázkám zasílání alertů (upozornění) pomocí SMTP a údajně chybějících předdefinovaných pohledů na uložená data (dashboardy) zadavatel poukazuje na logickou nekonzistenci argumentace navrhovatele, který dle zadavatele jak návrhu, tak v námitkách obě otázky spojil dohromady a současně se v návrhu nad tímto spojením pozastavuje (zadavatel ovšem dle svých slov v daném ohledu reagoval na námitku tak, jak byla vznesena). K tomu dále zadavatel dodává, že v rozhodnutí o námitkách netvrdil nic o spojitosti zasílání alertů s komponentou pro export, nýbrž pouze uvedl výčet, kde všude je mimo jiné podporováno více formátů.

Zadavatel dále reaguje na námitky týkající se MNNC. K tomu zadavatel zejména uvádí, že posouzení MNNC v nabídce vybraného dodavatele provedl, když vybraného dodavatele

Ve vyjádření k podkladům rozhodnutí ze dne 12. 11. 2021 se zadavatel vyjádřil mj. k argumentaci navrhovatele, že „není možné, aby zpřístupněním nabídky jednoho dodavatele druhému došlo k porušení obchodního tajemství“; zadavatel k tomu uvedl, že tento závěr je nesprávný, neboť nejde jen o ty parametry nabízeného plnění, které jsou v zadávacím řízení „testovány“ a z povahy věci tak nemohou být utajovány, ale např. o způsob, jakým jich dodavatel dosáhl. Tj. v obecné rovině např. výrobní postup, v IT oblasti např. konkrétní architektura dodávaného řešení, zdrojové kódy, ale např. též způsob cenotvorby, způsob vytěžování personálních kapacit, atp., které samozřejmě mohou být pro každého dodavatele konkurenčně významné.

Usnesením č. j. ÚOHS-00966/2022/511 ze dne 10. 1. 2022 určil Úřad zadavateli lhůtu k provedení úkonu – podání informace Úřadu o dalších úkonech, které zadavatel v šetřeném zadávacím řízení v průběhu správního řízení provede, a zaslání příslušné dokumentace o zadávacím řízení pořízené v souvislosti s provedenými úkony.

Rozhodnutím č. j. ÚOHS-01487/2022/500 ze dne 13. 1. 2022 Úřad uložil zadavateli zákaz uzavřít smlouvu na veřejnou zakázku, a to až do pravomocného skončení správního řízení vedeného pod sp. zn. ÚOHS-S0682/2021/VZ.

Usnesením č. j. ÚOHS-01495/2022/511 ze dne 13. 1. 2022 Úřad správní řízení podle § 64 odst. 1 písm. e) správního řádu ve spojení s § 261 odst. 2 zákona přerušil s cílem získat s cílem získat znalecký posudek z oboru Kybernetická bezpečnost a/nebo Informační a komunikační technologie, a to do doby doručení výše uvedeného znaleckého posudku.

Dne 2. 6. 2022 byl usnesením č. j. ÚOHS-18650/2022/500 z téhož dne (dále jen „usnesení ze dne 2. 6. 2022“) ustanoven v projednávané věci znalec. Tento byl vyzván, aby zodpověděl otázky, které jsou blíže popsány v bodech 165 až 200 odůvodnění tohoto rozhodnutí. Znalci bylo v rámci daného usnesení rovněž uloženo, aby znalecký posudek ve 2 vyhotoveních podal

Dne 2. 6. 2022 Úřad účastníkům řízení prostřednictvím přípisu „Sdělení o ustanovení znalce“ č. j. ÚOHS-18722/2022/511 z téhož dne oznámil, že v daném zadávacím řízení na veřejnou zakázku byl ustanoven znalec k vypracování znaleckého posudku.

Usnesením č. j. ÚOHS-18722/2022/511 ze dne 9. 8. 2022 Úřad prodloužil znalci lhůtu pro provedení znaleckého posudku na základě žádosti znalce ze dne 8. 8. 2022, a to do 19. 8. 2022.

Usnesením č. j. ÚOHS-28419/2022/500 ze dne 19. 8. 2022 Úřad prodloužil znalci lhůtu pro provedení znaleckého posudku na základě žádosti znalce ze dne 17. 8. 2022, a to do 31. 8. 2022.

Dne 31. 8. 2022 byl Úřadu doručen ve 3 vyhotoveních „Znalecký posudek č. 73/7/2022“ ze dne

Žádostí o doplnění znaleckého posudku ze dne 9. 9. 2022 Úřad požádal o doplnění znaleckého posudku č. 73/7/2022 ze dne 31. 8. 2022 o odpovědi na dotazy č. 1 až 56 tak, aby byly skutečně zodpovězeny Úřadem položené otázky. Současně Úřad požádal o řádné zdůvodnění odpovědí.

Dne 16. 9. 2022 byl Úřadu doručen ve 3 vyhotoveních „Znalecký posudek č. 73/7/2022“ ze dne

Žádostí o vysvětlení znaleckého posudku ze dne 20. 9. 2022 Úřad požádal znalce o bližší vysvětlení jeho odpovědi k dotazu č. 51 znaleckého posudku tak, aby nevznikaly pochybnosti mezi zdůvodněním a samotnou odpovědí na položený dotaz.

Dne 21. 9. 2022 Úřad obdržel vysvětlení znalce z téhož dne (dále jen „vysvětlení znaleckého posudku“) k odpovědi na dotaz č. 51 znaleckého posudku.

Přípisem č. j. ÚOHS-33339/2022/511 ze dne 23. 9. 2022 Úřad oznámil pokračování správního řízení vedeného pod sp. zn. ÚOHS-S0682/2021/VZ účastníkům řízení.

Žádostí o vysvětlení znaleckého posudku ze dne 30. 9. 2022 Úřad požádal znalce o bližší vysvětlení jeho odpovědi k dotazu č. 53 znaleckého posudku tak, aby byly Úřadu známy bližší důvody, proč nemůžete jednoznačně vyloučit, že požadavek uvedený v bodě č. 53 lze splnit způsobem uvedeným v tomto bodě a bližší vysvětlení role „nezávislého auditora“.

Dne 7. 10. 2022 Úřad obdržel vysvětlení znalce (dále jen „vysvětlení znaleckého posudku č. 2“) k odpovědi na dotaz č. 53 znaleckého posudku a k otázce „nezávislého auditora“.

Usnesením č. j. ÚOHS-35119/2022/511 ze dne 7. 10. 2022 Úřad stanovil účastníkům lhůtu 10 dnů k vyjádření se ke znaleckému posudku. Uvedenou lhůtu Úřad následně prodloužil usnesením č. j. ÚOHS-35811/2022/511 ze dne 13. 10. 2022 a usnesením č. j. ÚOHS37738/2022/511 ze dne 26. 10. 2022.

Dne 20. 10. 2022 zadavatel doručil vyjádření z téhož dne, ve kterém uvádí, že nemá ke znaleckému posudku připomínky, a současně opakuje, že nabídka vybraného dodavatele splňuje podmínky předmětného zadávacího řízení a zadavatel v jeho rámci postupoval v souladu se zákonem.

Usnesením č. j. ÚOHS-39512/2022/511 ze dne 8. 11. 2022 Úřad stanovil účastníkům lhůtu 7 dnů k vyjádření se k podkladům rozhodnutí.

Dne 8. 11. 2022 zadavatel doručil vyjádření z téhož dne, ve kterém uvádí, že odkazuje na své předchozí vyjádření k návrhu. Zadavatel je též toho názoru, že i ostatní důkazy obsažené ve správním spisu jeho názor podporují.

Dne 15. 11. 2022 doručil navrhovatel vyjádření k podkladům rozhodnutí z téhož dne (dále jen „vyjádření navrhovatele k podkladům“).

Navrhovatel nejprve namítá nepřezkoumatelnost znaleckého posudku, přičemž uvádí, že znalecký posudek ve znění vysvětlení znaleckého posudku nedisponuje všemi náležitostmi ve smyslu § 28 odst. 1 a 2 zákona o znalcích. Konkrétně navrhovatel uvádí, že většina odpovědí znalce neobsahuje odůvodnění v rozsahu umožňujícím přezkoumatelnost znaleckého posudku, jakož i povinnou náležitost ve smyslu § 28 odst. 2 písm. h) zákona o znalcích.

Tyto nedostatky navrhovatel demonstruje mj. na tom, že u odpovědí na otázku č. 8 a č. 18–25 znalec odpovídá pouze v tom smyslu, že nástroj logman.io má cca 80 % předdefinovaných výrobců a ostatní je nutné doprogramovat na místě zákazníka z důvodu rozdílných požadavků, přičemž dále znalec dodává, že se jedná o běžnou praxi. Navrhovatel má tedy za to, že se jedná o nedostatečné zdůvodnění, resp. znalec nekriticky převzal tvrzení vybraného dodavatele či spol. TeskaLabs. Současně navrhovatel uvádí, že dle bodu č. 1.1.2 písm. b) znaleckého posudku znalec vychází z toho, že informace z jiných zdrojů, které sloužily jako další podklad pro zpracování znaleckého posudku, jsou věrohodné a nebyly ve všech případech z hlediska jejich přesnosti a úplnosti ověřovány.

Dále navrhovatel uvádí, že z bodu č. 1.9.3 znaleckého posudku vyplývá, že znalec provedl dne

Navrhovatel taktéž uvádí, že znalecký posudek je vnitřně rozporný. Dle navrhovatele znalec na jednu stranu v bodě 1.9.3 nálezu znaleckého posudku uvádí, že mu byla při místním šetření „vysvětlena, umožněna a předvedena funkcionalita související s dotazy 1 – 56“, čímž dle navrhovatele znalecký posudek evokuje, že znalec prověřil funkčnost všech rozporovaných aspektů nástroje LogMan.io a že mu bylo předvedeno splnění veškerých požadavků zadavatele, na které se Úřad dotazoval. Na druhou stranu znalec dle navrhovatele v řadě případů uvádí, že splnění dílčích požadavků vůbec neověřil. Toto měl znalec udělat např. u otázky č. 48, kde uvedl, že „nebylo znalcem ověřeno“, přičemž dále vychází pouze z webu společnosti TeskaLabs. Navrhovatel má však za to, že znalec pouze přebírá závěry společnosti

Vnitřní rozpornost znaleckého posudku navrhovatel dovozuje i z odpovědi na otázku č. 51, přičemž navrhovatel uvádí, že z odpovědi znalce vyplývá, že mu splnění předmětného požadavku zadavatele nebylo v rámci místního šetření předvedeno. Navrhovatel má za to, že odpověď znalce na tuto otázku je ve vzájemném rozporu s jejím odůvodněním, když znalec na jednu stranu tvrdí, že nemůže vyloučit, že splnění takového požadavku zajistit lze, a na druhou stranu tvrdí, že takový požadavek objektivně splnit nelze, resp. že takovou možnost v některých aspektech vůbec neověřoval. Současně navrhovatel uvádí, že požadavek zadavatele na integritu a nesmazatelnost dat neurčuje konkrétní míru nesmazatelnosti či nemodifikovatelnosti pořízených dat, ale vyplývá z něj, že nástroj nesmí umožnit modifikaci či smazání dat žádným způsobem, a to ani prostřednictvím příkazu administrátora, ani prostřednictvím „hackerských technik“. Dále navrhovatel uvádí, že ani závěr znalce, že nástroj

Obdobné závěry navrhovatel tvrdí i k odpovědi znalce na otázku č. 53, kde znalec taktéž uvádí, že „nebylo znalcem jednoznačně ověřeno nebo vyloučeno“. Navrhovatel má za to, že pokud však nebylo splnění tohoto požadavku jednoznačně ověřeno ani vyloučeno, nemůže znalec poskytnout jednoznačnou odpověď na položenou otázku a uvést, že možnost splnění tohoto požadavku nemůže jednoznačně vyloučit. Navrhovatel tak má za to, že závěr znalce a jeho zdůvodnění jsou ve vzájemném rozporu. K dopovězení na otázku Úřadu by dle navrhovatele stačilo, aby znalci bylo předvedeno, že nástroj LogMan.io vizuálním programovacím jazykem disponuje a že je tento funkční.

S ohledem na výše uvedené má navrhovatel za to, že znalecký posudek je vnitřně rozporný a nepřezkoumatelný, přičemž pokud jde o účast znalce na místním šetření, nezachytil znalec dle navrhovatele žádným způsobem obsah tohoto místního šetření a neučinil jej přílohou znaleckého posudku tak, aby ve smyslu § 28 odst. 1 a § 28 odst. 2 písm. f) a h) zákona o znalcích zajistil přezkoumatelnost znaleckého posudku. Znalecký posudek tak vykazuje dle navrhovatele formální vady, pro které mu není možné přiznat důkazní váhu. Dále v tomto ohledu navrhovatel odkazuje na judikaturu soudů týkající se problematiky dokazování znaleckým posudkem. Dle navrhovatele má Úřad povinnost zadat zpracování revizního znaleckého posudku znaleckému ústavu, přičemž zadání by Úřad měl formulovat takovým způsobem, aby nebylo ověřováno, zda je možné jednoznačně vyloučit, že určitým způsobem není možné určitý požadavek zadavatele splnit, ale aby znalec jednoznačně potvrdil, že nástroj nabízený vybraným dodavatelem tyto požadavky jednoznačně splňuje či nesplňuje, a to k okamžiku podání finální nabídky.

Dále navrhovatel namítá, že jím dosud popsaná pochybení týkající se zpracování znaleckého posudku ve spojení se skutečností, že znalec přebírá pouze závěry zadavatele, které mu sdělil vybraný dodavatel a společnost TeskaLabs, ukazují na potenciální podjatost znalce.

Navrhovatel má za to, že s ohledem na doktrinální výklad a rozhodovací praxi je přitom nutné připomenout, že pro vyloučení znalce z důvodu jeho podjatosti není nezbytně nutné, aby bylo prokázáno, že znalec skutečně podjatý je, postačí, že o jeho nepodjatosti lze pochybovat.

V další části svého vyjádření navrhovatel napadá dle jeho názoru nevhodně položené otázky na znalce. S ohledem na položené otázky jsou dle stěžovatele odpovědi znalce vzhledem k předmětu správního řízení a ke konkrétně rozporovaným skutečnostem naprosto irelevantní. Dle navrhovatele předmětem správního řízení je otázka, zda nabídka vybraného dodavatele splnila zadávací podmínky. Otázky na znalce tak dle navrhovatele měly být položeny takovým způsobem, aby se znalec jednoznačně vyjádřil, zda nástroj LogMan.io zadávací podmínky splňuje, či nikoliv. Dle navrhovatele Úřadem položené otázky žádným způsobem nepřispívají k objasnění skutkového stavu.

Navrhovatel dále upozorňuje na to, že veřejná zakázka je koncipována jako veřejná zakázka na dodávky ve smyslu § 14 odst. 1 zákona, nikoliv jako veřejná zakázka na služby ve smyslu § 14 odst. 2 zákona. Současně navrhovatel uvádí, že technické podmínky vymezující předmět veřejné zakázky jsou dle § 37 odst. 1 zákona součástí podmínek účasti v zadávacím řízení.

Navrhovatel dále uvádí, že zadavatel stále nemá a nemůže mít postaveno najisto, zda vybraný dodavatel splnil podmínky účasti v zadávacím řízení, pročež jej nemohl k uzavření smlouvy vybrat a ani s ním nemůže následně smlouvu uzavřít. Jedinou možností je dle navrhovatele v případě, kdy Úřad nepřistoupí k doplnění dokazování, zrušení rozhodnutí o výběru.

V další části vyjádření k podkladům se navrhovatel vyjadřuje k jednotlivým částem znaleckého posudku a navrhuje dílčí části zadání revizního znaleckého posudku. K odpovědi na otázky č. 1 až 43 navrhovatel uvádí, že není jednoznačně průkazná a spoléhá se výhradně na tvrzení dodavatele. Znalec dle navrhovatele neprovedl ani základní šetření, kterým by ověřil, zda je tvrzení vybraného dodavatele nebo výrobce LogMan.io o minimálně 80 % podporovaných zdrojů skutečně pravdivé, a neuvedl relevantní skutečnosti odůvodňující závěr, že absentující funkcionality lze skutečně doprogramovat. S ohledem na tuto skutečnost navrhovatel navrhuje provést důkladné šetření směřující k objasnění těchto skutečností. K tomu uvádí, že pro každý požadovaný či podporovaný zdroj logů by měla být k dispozici dokumentace nastavení daného zdroje pro sběr logů či událostí do nástroje LogMan.io. V tomto nástroji se přitom musí nacházet pro každý podporovaný zdroj unikátní parser či normalizátor logů. Ten lze i rychlým náhledem identifikovat a posoudit, zda danou operaci normalizace je opravdu schopen realizovat. Strojová data jednotlivých požadovaných či podporovaných výrobců se natolik liší, že tyto unikátní parsery či normalizátory logů lze snadno prozkoumat a potvrdit, zda jsou v řešení LogMan.io přítomny a zda daný zdroj dle otázek č. 1 až 43 je opravdu podporován a nejedná se tak pouze o přejmenovanou kopii jiného parseru či normalizátoru.

K odpovědi na otázky č. 44, 45A a 45B navrhovatel uvádí, že není jednoznačně průkazná.

K odpovědi na otázku č. 46 navrhovatel uvádí, že není jednoznačně průkazná. Z požadavků zadavatele, resp. z přílohy č. 1 smlouvy, dle jeho názoru vyplývá, že řešení musí umožňovat zálohování a obnovení konfigurace z centrální konzole. Znalcem přiložený odkaz na dokumentaci dle navrhovatele popisuje pouze způsob organizace diskového úložiště řešení

K odpovědi na otázku č. 47 navrhovatel uvádí, že není jednoznačně průkazná. Z požadavků zadavatele, resp. z přílohy č. 1 smlouvy, dle jeho názoru vyplývá, že řešení musí umožňovat nastavení nezávislé zálohovací politiky jak pro konfiguraci, tak pro jednotlivá úložiště.

K odpovědi na otázky č. 49 a 50 navrhovatel uvádí, že není jednoznačně průkazná. Zadavatel prostřednictvím těchto logicky spojených bodů požaduje možnost aktualizace nástroje v jednotném balíku a dále i downgrade (ponížení software verze řešení) přes centrální konzoli.

K odpovědi na otázku č. 51 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele, resp. přílohy č. 1 smlouvy, na nástroj je, aby nástroj garantoval integritu pořízených dat a systém neumožňoval mazání nebo modifikaci již pořízených dat. Požadavek zadavatele přitom neurčuje konkrétní míru nesmazatelnosti či nemodifikovatelnosti pořízených dat. Požadavek je tedy nutné vykládat tak, že nástroj nesmí umožnit modifikaci či smazání dat žádným způsobem, a to ani prostřednictvím příkazu administrátora, ani prostřednictvím „hackerských“ technik. Pro tyto a ani pro jiné případy totiž požadavek zadavatele žádnou výjimku neobsahuje. Závěr znalce je tak v kontextu jeho konstatování, že vždy lze určitým způsobem dosáhnout smazání dat, zcela nepodložený, a tudíž nepřezkoumatelný. Navrhovatel dále uvádí, že dle veřejně dostupné dokumentace k nástroji

K odpovědi na otázku č. 53 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele na nástroj je, aby byla umožněna konfigurace notifikací prostřednictvím vizuálního programovacího jazyka. Znalec však tuto funkcionalitu dle navrhovatele žádným způsobem

K odpovědi na otázku č. 55 navrhovatel uvádí, že není jednoznačně průkazná. Požadavek zadavatele na nástroj je, aby obsahoval předpřipravené pohledy na data dle seznamu technologií dle bodů č. 1 až 44 znaleckého posudku. Ve způsobu řešení se pouze konstatuje, že dané pohledy jsou již předpřipravené, ale není představen ani seznam těchto pohledů a nebyla provedena kontrola, zda se o tyto pohledy dle jednotlivých technologií opravdu jedná.

V návaznosti na vše výše uvedené tak navrhovatel navrhuje, aby Úřad přistoupil k zadání revizního znaleckého posudku, který bude zpracován transparentním způsobem, který bude zpětně přezkoumatelný a který jednoznačně zodpoví otázku, zda nabídka vybraného dodavatele ke dni podání nabídek splňovala technické podmínky vymezující předmět veřejné zakázky. Při zpracování tohoto revizního posudku je dle navrhovatele nutné provést testování verze nástroje LogMan.io, která byla aktuální k okamžiku uplynutí lhůty pro podání nabídek, a ověření všech navrhovatelem rozporovaných požadavků zadavatele a zejména výše uvedených skutečností. V zájmu zajištění transparentnosti a přezkoumatelnosti revizního znaleckého posudku navrhovatel žádá, aby testování nástroje proběhlo v rámci ústního jednání před Úřadem, které Úřad za tímto účelem nařídí, a to za účasti zástupců vybraného dodavatele, spol. TeskaLabs, navrhovatele a za účasti samotného znalce. Navrhovatel dále žádá, aby byl průběh testování zdokumentován prostřednictvím audiovizuálního záznamu,

Závěrem navrhovatel uvádí, že trvá na svém návrhu, a navrhuje, aby Úřad rozhodl o návrhu tak, že zadavatel nedodržel postup stanovený zákonem, a aby uložil zadavateli opatření k nápravě spočívající ve zrušení rozhodnutí o výběru i všech navazujících úkonů, a aby zavázal zadavatele k provedení nového posouzení nabídek, k vyloučení vybraného dodavatele z další účasti v zadávacím řízení a k rozhodnutí o výběru nabídky navrhovatele.

Úřad přezkoumal na základě § 248 a následujících ustanovení zákona případ ve všech vzájemných souvislostech a po zhodnocení všech podkladů, zejména relevantních částí obdržené dokumentace o zadávacím řízení, vyjádření účastníků řízení, znaleckého posudku a na základě vlastních zjištění rozhodl: • o zastavení správního řízení podle § 257 písm. h) zákona ve vztahu k částem návrhu týkajícím se nesplnění požadavků č. 147, 148, 149, 150, 159, 401 uvedených v příloze č. 1 návrhu smlouvy vybraným dodavatelem, neboť předmětným částem návrhu nepředcházely řádně a včas podané námitky. • ve vztahu ke zbývajícím částem návrhu o zamítnutí návrhu dle § 265 písm. a) zákona, neboť nebyly zjištěny důvody pro uložení nápravného opatření.

Ke svému rozhodnutí Úřad uvádí následující rozhodné skutečnosti.

Podle § 6 odst. 1 zákona musí zadavatel při postupu podle tohoto zákona dodržovat zásady transparentnosti a přiměřenosti.

Podle § 28 odst. 1 písm. o) zákona se pro účely tohoto zákona mimořádně nízkou nabídkovou cenou rozumí nabídková cena nebo náklady uvedené účastníkem zadávacího řízení, které se jeví jako mimořádně nízké ve vztahu k předmětu veřejné zakázky.

Podle § 48 odst. 4 zákona zadavatel může vyloučit účastníka zadávacího řízení, pokud nabídka účastníka zadávacího řízení obsahuje mimořádně nízkou nabídkovou cenu, která nebyla účastníkem zadávacího řízení zdůvodněna.

Podle § 113 odst. 4 zákona zadavatel požádá účastníka zadávacího řízení o písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny. Žádost o zdůvodnění mimořádně nízké nabídkové ceny se považuje za žádost podle § 46 zákona, lze ji doplňovat a vznést opakovaně. V žádosti o zdůvodnění mimořádně nízké nabídkové ceny musí zadavatel požadovat, aby účastník zadávacího řízení potvrdil, že a) při plnění veřejné zakázky zajistí dodržování povinností vyplývajících z právních předpisů vztahujících se k předmětu veřejné zakázky, jakož i pracovněprávních předpisů a kolektivních smluv vztahujících se na zaměstnance, kteří se budou podílet na plnění veřejné zakázky, a b) neobdržel neoprávněnou veřejnou podporu.

Podle § 113 odst. 5 zákona účastník zadávacího řízení musí v objasnění mimořádně nízké nabídkové ceny potvrdit skutečnosti podle § 113 odst. 4 zákona. Mimořádně nízkou nabídkovou cenu může účastník zadávacího řízení dále odůvodnit zejména prostřednictvím a) ekonomických aspektů konstrukčních metod, výrobního procesu, poskytovaných služeb nebo b) použitých technických řešení nebo výjimečně příznivých podmínek, které má účastník zadávacího řízení k dispozici pro plnění veřejné zakázky, nebo c) originality stavebních prací, dodávek nebo služeb.

Podle § 113 odst. 6 zákona zadavatel posoudí objasnění mimořádně nízké nabídkové ceny.

Podle § 242 odst. 2 zákona námitky proti úkonům oznamovaným v dokumentech, které je zadavatel povinen podle tohoto zákona uveřejnit či odeslat stěžovateli, musí být doručeny zadavateli do 15 dnů od jejich uveřejnění či doručení stěžovateli.

Podle § 251 odst. 4 zákona náležitosti návrhu podle odstavce 1 věty první a druhé nemohou být dodatečně měněny ani doplňovány s výjimkou odstranění nedostatků návrhu ve lhůtě stanovené Úřadem; Úřad k takovým změnám a doplněním nepřihlíží. K novým skutečnostem uvedeným v návrhu oproti skutečnostem obsaženým v námitkách podaných zadavateli přihlédne Úřad jen tehdy, jde-li o takové skutečnosti, které navrhovatel nemohl tvrdit již vůči zadavateli; navrhovatel je povinen prokázat, že jde o takové nové skutečnosti, které nemohl tvrdit již vůči zadavateli.

Podle § 251 odst. 2 zákona návrh musí být, není-li stanoveno jinak, doručen Úřadu a ve stejnopisu zadavateli do 10 dnů ode dne, v němž stěžovatel obdržel rozhodnutí, kterým zadavatel námitky odmítnul.

Podle § 257 písm. h) zákona Úřad zahájené řízení usnesením zastaví, jestliže návrhu nepředcházely řádně a včas podané námitky, to neplatí pro návrhy podle § 254 zákona.

Podle § 265 písm. a) zákona platí, že Úřad návrh zamítne, pokud nebyly zjištěny důvody pro uložení nápravného opatření.

K námitce zadavatele, že mu navrhovatel ve lhůtě dle § 251 odst. 2 zákona nedoručil kompletní stejnopis návrhu, když zadavateli nebyly doručeny přílohy návrhu, na které navrhovatel v textu návrhu odkazuje, Úřad uvádí následující. V § 250 odst. 1 větě druhé a třetí zákona je

Úřad tak k uvedené argumentaci zadavatele uzavírá, že nedoručení příloh stejnopisu návrhu není vadou, která by byla důvodem pro zastavení správního řízení dle § 257 písm. e) zákona.

V námitkách je v čl. II. s názvem „K nesplnění zadávacích podmínek“ odstavci 8. uveden seznam požadavků, které zadavatel stanovil v příloze č. 1 smlouvy. V uvedeném seznamu požadavků jsou pod jednotlivými písmeny uvedeny body 101 a 144, 145, 146 a 166, 153, 154,

V odstavci 11. námitek je uvedeno: „Z dostupných informací a z uživatelského manuálu nástroje pak vyplývá, že tento nemá v rozporu s bodem 153 a 154 Přílohy č. 1 smlouvy nijak řešenu zálohu a obnovu konfigurací celého nástroje z centrální konzole a rovněž neumožňuje nastavení nezávislé zálohovací politiky. V rozporu s bodem 145 Přílohy č. 1 pak nástroj také neumožňuje přístup více uživatelů současně.“.

V odstavci 12. námitek je uvedeno: „Nabízený nástroj pak také v rozporu s body 146 a 166 neumožňuje snadné vytváření a definování uživatelských rolí s možností definice přístupových práv a granulárního přidělování práv v rámci rolí, podle zdrojů logů, skupin zařízení, jednotlivých serverů, typu logu, když jejich definice je řešena tenanty, nikoliv pomocí pokročilých funkcí jako jsou RBAC apod.“.

V odstavci 14. námitek je uvedeno: „Dle dostupných informací nabízený nástroj navíc v rozporu s bodem 506 Přílohy č. 1 negarantuje integritu uložených dat a umožňuje mazání a modifikaci uložených logů, přičemž tato skutečnost je také v rozporu s legislativními a normativními požadavky kladenými na tento nástroj prostřednictvím vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), přičemž nesplnění těchto požadavků je v přímém rozporu s bodem

Úřad předně v obecné rovině uvádí, že jednou z podmínek pro řádné projednání návrhu na přezkoumání úkonů zadavatele Úřadem je předchozí podání námitek zadavateli. Platí, že návrh je až druhotným nástrojem procesní obrany dodavatele, neboť prvotním nástrojem jsou námitky, jež jsou podávány přímo zadavateli, který tím dostává možnost na námitky dodavatele reagovat. Zákon tak vyžaduje, aby byly veškeré námitky nejprve uplatněny u zadavatele, a to řádně a včas. V situaci, kdy navrhovatel nevyužije možnosti podání námitek, resp. takto neučiní včas a řádně, tedy s veškerými zákonnými náležitostmi, pak není oprávněn domáhat se ochrany svých práv před Úřadem.

Úřad v posuzované věci předně uvádí, že zadavatel doručil navrhovateli oznámení o výběru dne 29. 7. 2021. Proti rozhodnutí o výběru navrhovatel podal dne 10. 8. 2021 námitky.

Úřad uvádí, že navrhovatel v námitkách mj. namítá, že nástroj nabídnutý vybraným dodavatelem nesplňuje zadávací podmínky. Konkrétně navrhovatel namítá nesplnění některých technických požadavků na poptávaný nástroj uvedených zadavatelem v příloze č. 1 smlouvy. Navrhovatel v námitkách nejprve uvedl výčet napadených požadavků, konkrétně požadavky uvedené v příloze č. 1 smlouvy pod body 101 a 144, 145, 146 a 166, 153, 154, 167,

V návrhu navrhovatel taktéž namítá, že nástroj nabídnutý vybraným dodavatelem nesplňuje zadávací podmínky, nicméně po porovnání námitek s obsahem návrhu Úřad zjistil, že v návrhu navrhovatel nově napadá nesplnění dalších požadavků dle přílohy č. 1 smlouvy.

Konkrétně navrhovatel nově napadá nesplnění požadavku č. 159 (týkajícího se nastavení nezávislé archivační politiky viz bod 141. odůvodnění tohoto rozhodnutí); tvrzení o nesplnění tohoto požadavku přitom navrhovatel včleňuje ke své argumentaci, v níž napadá nesplnění požadavku č. 153 a č. 154 (viz bod 19. odůvodnění tohoto rozhodnutí). V námitkách jsou naopak napadány pouze požadavky 153 a 154, resp. požadavek na zálohu a obnovu konfigurací celého nástroje z centrální konzole a nastavení nezávislé zálohovací politiky (viz

Dále navrhovatel v návrhu nově napadá nesplnění požadavků č. 147 až 150, přičemž tyto námitky navrhovatel včleňuje do argumentace týkající se nesplnění požadavků č. 146 a 166 (neumožnění snadného vytváření a definování uživatelských rolí), přičemž navrhovatel uvádí, že body č. 147 až 150 souvisejí s požadavkem dle bodu 146 přílohy č. 1 smlouvy (viz bod 22. odůvodnění rozhodnutí). K tomu Úřad uvádí, že byť zadavatel rozdělil požadavky v příloze č. 1 smlouvy do určitých dílčích tematických celků, přičemž požadavek č. 146 a požadavky č. 147 –

Navrhovatel v návrhu nově uvádí též nesplnění požadavku č. 401, přičemž tuto námitku včleňuje do argumentace k nesplnění bodu č. 506 přílohy č. 1 smlouvy, když mj. uvádí, že „Použití kryptografických funkcí tak zajišťuje toliko kontrolu integrity (tedy zjištění, zda byl zápis změněn), přičemž zápis před samotnou změnou či smazáním nechrání. To je přitom v přímém rozporu s bodem 401 a 506 Přílohy č. 1 smlouvy“ (viz bod 27. odůvodnění tohoto rozhodnutí). Navrhovatel tedy v námitkách namítal nesplnění požadavku č. 506, podle něhož má nástroj garantovat integritu uložených dat, přičemž nesmí umožnit mazání nebo modifikování již uložených logů. Každý log pak dle tohoto požadavku musí mít unikátní identifikátor, který umožní jeho jednoznačnou identifikaci. Tento požadavek č. 506 byl v příloze č. 1 smlouvy uveden v sekci „Zpracování událostí“. Nově napadený požadavek č. 401 byl naopak zařazen do sekce „Sběr a distribuce dat“, přičemž dle tohoto požadavku zadavatel požaduje řešení, které zahrnuje také kolektor, který sbírá události ve vzdálených lokalitách a umožní jejich odeslání po saturované lince bez ztráty dat. Zároveň šifruje a komprimuje posílaná data a zabezpečuje je proti jejich modifikaci nebo smazání, přičemž je garantováno doručení do centrálního prvku (viz bod 141. odůvodnění tohoto rozhodnutí). Byť se tedy oba požadavky částečně týkají modifikace a mazání, každý z těchto požadavků je samostatný a každý v sobě zahrnuje širší problematiku. Současně Úřad podotýká, že z přílohy č. 1 smlouvy vyplývá, že požadavek č. 506, který byl napadnutý v námitkách, se týká konkrétně mazání a modifikace logů, ale nově napadnutý požadavek č. 401 je obecnějšího charakteru a týká mj. obecně mazání a modifikace dat.

Úřad tedy konstatuje, že v případě shora tvrzení se jedná o uvedení nových skutečností v návrhu oproti skutečnostem obsaženým v námitkách; k takovým skutečnostem má Úřad v souladu s § 251 odst. 4 zákona přihlédnout pouze tehdy, jde-li o takové skutečnosti, které navrhovatel nemohl tvrdit již vůči zadavateli, přičemž navrhovatel je povinen prokázat, že jde o takové nové skutečnosti, které nemohl tvrdit již vůči zadavateli. Navrhovatel přitom to, že by šlo o takové skutečnosti, neprokázal (a ani netvrdil). Úřad dodává, že dle jeho názoru o takové skutečnosti nešlo, neboť z ničeho neplyne, že by o těchto skutečnostech navrhovatel nemohl vědět již při podání námitek (např. z veřejně dostupné dokumentace nástroje, která byla jeho primárním zdrojem u ostatních námitek).

Dle § 257 písm. h) zákona je podání včasných a řádných námitek zadavateli podmínkou pro následné podání návrhu na přezkoumání úkonů zadavatele v téže věci. Z výše uvedeného

Úřad dodává, že z důvodu procesní ekonomie rozhodl o zastavení řízení o části návrhu (výrok

S ohledem na vše výše uvedené Úřad rozhodl tak, jak je uvedeno ve výroku I. tohoto rozhodnutí.

V bodě 4.1 vzoru smlouvy je uvedeno následující: »Dodavatel se zavazuje realizovat Předmět plnění v následujících termínech:

V bodě 5.1.1 vzoru smlouvy je uvedeno následující: „Spolu s Předmětem plnění bude předána také veškerá dokumentace (např. produktová, uživatelská) vztahující se k Předmětu plnění a k Software, bez níž by nemohlo docházet k řádnému užívání Software v souladu s poskytnutou Licencí, v českém jazyce, která bude předána spolu s Předmětem plnění v elektronické podobě.“

V příloze č. 1 smlouvy je část označená jako „Popis řešení Nástroje včetně schématického znázornění architektury“, přičemž je zde poznámka „(doplní dodavatel)“.

V příloze č. 1 smlouvy je část označená jako „Požadavky na nástroj pro Log Management“, kde jsou uvedeny mj. následující požadavky:

V příloze č. 3 smlouvy s názvem „Harmonogram“ je uvedena následující tabulka:

V protokolu o jednání komise ze dne 15. 6. 2021 (dále jen „protokol č. 1) je uvedeno k nabídce vybraného dodavatele, že „Komise shledala celkovou nabídkovou cenu jako mimořádně nízkou“, přičemž dále je zde uvedeno následující: »Komise proto požádala v souladu s § 113 odst. 4 zákona o písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny k výše uvedené veřejné zakázce, která se liší od ostatních nabídek téměř řádově (jednotky mio vers. desítka mio.).

Z žádosti o písemné vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny ze dne

Z dokumentace o zadávacím řízení vyplývá, že dne 22. 6. 2021 vybraný dodavatel doručil zadavateli vysvětlení nabídky a zdůvodnění mimořádně nízké nabídkové ceny z téhož dne (dále jen „objasnění MNNC“), kde vybraný dodavatel na položené dotazy zadavatele týkající se MNNC uvedl mj. následující: „Společnost AXENTA a.s. především prohlašuje, že nabízené řešení kvalitativně a funkčně odpovídá zadání a je proveditelné v rámci nabídkové ceny.

V protokolu o jednání komise ze dne 29. 6. 2021 (dále jen „protokol č. 2“) je uvedeno následující: „Náplní jednání komise bylo dokončení posouzení splnění podmínek účasti v zadávacím řízení a objasnění mimořádně nízké nabídkové ceny u účastníka řízení, jehož nabídka byla vyhodnocena jako ekonomicky nejvýhodnější. Komise zohlednila doručené písemné vysvětlení předložených informací a písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny, která jsou součástí dokumentace o zadávacím řízení.

Ve veřejné dokumentaci nástroje Logman.io2 na stránce týkající se manuální instalace je popsán postup manuální instalace nástroje, přičemž mj. jsou zde uvedeny interakce s Git viz následující obrázky:

Zadavatel v rámci správního řízení sp. zn. S0379/2021/VZ doručil Úřadu vyjádření zadavatele ze dne 13. 9. 2021, přičemž k němu jako přílohu přiložil znalecký posudek č. 203-7/2020 (dále jen „znalecký posudek č. 203-7/2020“) vypracovaný znalcem Vítem Lidinským, IČO 71443029, se sídlem Jesenicova 500/8, Praha 3 – Žižkov, zadaný společností TESKALABS LTD, odštěpný závod, IČO 07957157, se sídlem Kodaňská 1441/46, 101 00 Praha 10 (dále jen „Teskalabs“).

Ve znaleckém posudku č. 203-7/2020 je v bodě 1 s názvem „Úvod“ uvedeno, že „Předmětem znaleckého posudku je odpovědět na následující otázky položené Znalci Zadavatelem

Posuďte, zda produkt naší společnosti TeskaLabs Logman.io splňuje požadavky ČSN/ISO

Posuďte, zda produkt naší společnosti TeskaLabs LogMan.io splňuje požadavky zákona o kybernetické bezpečnosti v platném znění pro Log Management SW.“

Ve znaleckém posudku č. 203-7/2020 v bodě 1.3 s názvem „Použité podklady a zdroje informací“ jsou uvedeny následující podklady pro tvorbu posudku.

Ve znaleckém posudku č. 203-7/2020 v bodě 2.3 s názvem „Požadavek ISO 27001 na Log

Ve znaleckém posudku č. 203-7/2020 v bodě 2.4 s názvem „Požadavek ZKB a VKB“3 je uvedeno následující: »Zákon o kybernetické bezpečnosti v detailu prováděný vyhláškou o kybernetické bezpečnosti vychází z ISO 27001. V některých případech (to je i případ logů) nastavuje některé základní požadavky (požadavky nejsou nastaveny dle analýzy rizik s „nulovou” počáteční hodnotou, ale již s hodnotou přednastavenou na konkrétní hodnotě).