Obsah (13)

§ 140 § 147 § 170 § 175 § 2 § 172 § 53 § 10 § 173 § 24 § 20 § 66 § 40

Bratislava Číslo: 29. 04. 2024 7305-6000/2024 Úrad pre verejné obstarávanie ako ústredný orgán štátnej správy pre verejné obstarávanie

§ 140

a orgán príslušný

§ 147písm.

c), § 167 ods. 2 písm. b), § 169 ods. 1 písm. c) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov vo veci námietok uchádzača zloženého zo skupiny dodávateľov, a to z vedúceho člena XX a z člena YY (ďalej len „navrhovateľ“) 1, smerujúcich

§ 170ods.

3 písm. d) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov proti vylúčeniu vo verejnej súťaži na predmet nadlimitnej zákazky „eTest druhej generácie (eTest II.)“, vyhlásenej verejným obstarávateľom Národný inštitút vzdelávania a mládeže, Ševčenkova 11, 850 05 Bratislava, IČO: 00 164 348, v Úradnom vestníku Európskej únie pod značkou 2023/S 190595830 zo dňa 03. 10. 2023 a vo Vestníku verejného obstarávania č. 193/2023 zo dňa 04. 10. 2023 pod značkou 32687-MSS (ďalej len ,,verejná súťaž“), vydáva toto rozhodnutie Úrad pre verejné obstarávanie

§ 175ods.

3 zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov námietky navrhovateľa zamieta. Odôvodnenie:

Navrhovateľ dňa
2024 doručil Úradu pre verejné obstarávanie (ďalej len „úrad“) námietky v listinnej podobe, smerujúce

§ 170ods.

3 písm. d) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len ,,zákon o verejnom obstarávaní“) proti vylúčeniu ponuky (ďalej len „námietky“). Kontrolovanému boli doručené námietky navrhovateľa toho istého dňa, a to v elektronickej podobe funkcionalitou informačného systému EPVO, prostredníctvom ktorého sa verejné obstarávanie realizuje (ďalej len „IS EPVO“). Námietky navrhovateľa boli doručené úradu a kontrolovanému v lehote

§ 170ods.

4 zákona o verejnom obstarávaní, v podobe

§ 170ods.

9 zákona o verejnom obstarávaní a obsahujú všetky náležitosti

§ 170ods.

5 zákona o verejnom obstarávaní. 2. Navrhovateľ doručil úradu námietky v zmysle § 170 ods. 1 písm. a) zákona o verejnom obstarávaní ako uchádzač.

§ 2ods.

5 písm. c) zákona o verejnom obstarávaní, na účely tohto zákona sa rozumie uchádzačom hospodársky subjekt, ktorý predložil ponuku. Navrhovateľ v predmetnej verejnej súťaži predložil ponuku v elektronickej podobe prostredníctvom IS JOSEPHINE dňa 05. 02. 2024 o 14:25:28 hod. V danom prípade má úrad za to, že navrhovateľ preukázal aktívnu vecnú legitimáciu na podanie námietok. 3.

§ 172ods.

1 zákona o verejnom obstarávaní s podaním námietok je navrhovateľ povinný zložiť na účet úradu kauciu; táto povinnosť sa nevzťahuje na orgán štátnej správy Námietky v mene skupiny dodávateľov podal vedúci člen skupiny dodávateľov, a to spoločnosť XX, na základe Plnomocenstva pre člena skupiny dodávateľov zo dňa 29. 01. 2024, ktoré tvorí prílohu námietok. 1 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie

§ 170ods.

1 písm. e). Kaucia musí byť pripísaná na účet úradu najneskôr na druhý pracovný deň nasledujúci po doručení námietok v lehote

§ 170ods.

4. Za každú skutočnosť, proti ktorej námietky

§ 170ods.

3 smerujú, sa skladá samostatná kaucia. 4.

ustanovenia § 172 ods. 2 písm.

b)zákona o verejnom obstarávaní je výška kaucie pri podaní námietok 0,1 % z predpokladanej hodnoty zákazky alebo koncesie, najmenej však 2000 eur a najviac 50 000 eur, ak ide o iné námietky, ako uvedené v písmene
a)tohto zákona. V danom prípade bol navrhovateľ povinný zložiť na účet úradu kauciu vo výške 0,1 % z predpokladanej hodnoty zákazky (10 741 032,19 Eur bez DPH), čo predstavuje sumu 10 741,03 EUR po zaokrúhlení na dve desatinné miesta. Úrad lustráciou účtu úradu zistil, že navrhovateľ s podaním námietok zložil na účet úradu dňa 22. 02. 2024 kauciu vo výške 10 742,- EUR. To znamená, že navrhovateľ v danom prípade uhradil za podanie námietok kauciu vo vyššej sume (o 0,97 Eur viac) ako je stanovená v zmysle § 172 ods. 2 zákona o verejnom obstarávaní. 5. Na základe vyššie uvedených skutočností má úrad za to, že s podaním námietok navrhovateľa boli splnené procesné podmienky pre konanie vo veci. Námietky navrhovateľa 6. Úvodom námietok navrhovateľ poukazuje na Oznámenie o vylúčení zo dňa 15. 02. 2024 v ktorom kontrolovaný uviedol, že ponuka navrhovateľa bola v zmysle § 53 ods. 5 písm.
b)zákona o verejnom obstarávaní vylúčená z predmetnej verejnej súťaže, t. j. z dôvodu, že ponuka uchádzača nespĺňa požiadavky na predmet zákazky uvedené dokumentoch potrebných na vypracovanie ponuky vo vzťahu k obsahu ponuky, konkrétne voči Návrhu riešenia predloženého v ponuke uchádzača a údajnej absencii popisu niektorých funkčných požiadaviek na predmet zákazky/verejnej súťaže. Navrhovateľ považuje rozhodnutie kontrolovaného o vylúčení navrhovateľa za nezákonné, ktoré vychádza z nesprávneho posúdenia skutkového stavu veci, nakoľko kontrolovaný nevyužil inštitút vysvetlenia v zmysle § 53 ods. 1 zákona o verejnom obstarávaní. 7. K tvrdeniu kontrolovaného, že uchádzač nepredložil niektoré požadované doklady a dokumenty preukazujúce splnenie požiadaviek na predmet zákazky a ďalšie nejasnosti/nezrovnalosti v požadovaných dokladoch a dokumentoch preukazujúcich splnenie požiadaviek na predmet zákazky v súlade so súťažnými podkladmi navrhovateľ konštatuje, že si detailne preštudoval oznámenie o vyhlásení verejného obstarávania, kompletné súťažné podklady, ich vysvetlenia i zmluvné podmienky tejto verejnej súťaže a všetky požiadavky a okolnosti spojené s realizáciou predmetu tejto zákazky zohľadnil vo svojej ponuke. Navrhovateľ je presvedčený, že popísal vlastný návrh riešenia vo svojej ponuke v plnom súlade so všetkými požiadavkami kontrolovaného a že vo svojej ponuke predložil všetky požadované doklady/dokumenty, čím preukázal splnenie požiadaviek na predmet zákazky v predmetnej verejnej súťaži v plnom rozsahu. Uvedené navrhovateľ deklaroval kontrolovanému priamo vo svojej ponuke, konkrétne v rámci vlastného návrhu riešenia (pdf dokument s názvom „16_Návrh_riešenia eTest“, ďalej len „Návrh riešenia“), kde konštatoval splnenie všetkých požiadaviek klienta, cit.: ,,Dielo bude dodané plne v súlade s funkčnými, nefunkčnými, legislatívnymi, výkonnostnými, bezpečnostnými a inými požiadavkami uvedenými v opise predmetu zákazky. Všetky požadované výstupy, dokumenty a iné produkty diela budú dodané v požadovanej forme a kvalite.“ Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 2 8. Navrhovateľ konštatuje, že v ďalšom texte Návrhu riešenia už nekopíroval jednotlivé textácie z katalógu požiadaviek tvoriace opis predmetu zákazky (Príloha č. 7 súťažných podkladov, ďalej len ,,Príloha č. 7 OPZ“), ktoré považoval za kontrolovaným stanovený štandard kladený na technické riešenie uchádzačov predkladajúcich ponuku, práve naopak, zameral sa na procesné rozpracovanie ním ponúkaného riešenia na predmet zákazky. Navrhovateľ konštatuje, že Návrh riešenia spracoval tak, aby reflektoval požadované dokumenty v bode 16.1.11 súťažných podkladov, ktoré rozpracoval do takej miery a v takej granularite, ktorá v prípade úspešnosti jeho ponuky, umožní zapracovať všetky detailnejšie požiadavky kontrolovaného do Detailného návrhu riešenia (ďalej len ,,DNR“) počas samotnej realizácie zákazky. Navrhovateľ konštatuje, že požiadavky, ktoré je nutné zohľadniť v DNR, vychádzajú z legislatívy, zo štandardov a vyhlášok MIRRI (najmä zo zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov; z vyhlášky Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy), a štandardne sú zapracované v rámci realizačnej etapy Analýzy a návrhu riešenia IS. Uvedený prístup navrhovateľ zvolil, keďže kontrolovaný deklaroval, že DNR (etapa už samotného plnenia zákazky) musí byť v súlade s Návrhom riešenia predloženým v ponuke úspešného uchádzača. Navrhovateľ podotýka, že spracovanie Návrhu riešenia a jeho granularita je limitovaná práve tým, že nemá dostatočnú znalosť prostredia, aby vedel spracovať Návrh riešenia ešte vo väčšom detaile. DNR môže

navrhovateľa ponúknuť len uchádzač/zhotoviteľ, ktorý pre kontrolovaného realizoval predchádzajúce riešenie/riešenia a pozná dokonale interné prostredie kontrolovaného, čo by však bolo príkro v rozpore s princípom nediskriminácie a rovnakého zaobchádzania, keďže by práve takéhoto uchádzača (súčasného, resp. predchádzajúceho zhotoviteľa IS pre kontrolovaného) neodôvodnene zvýhodňovalo. Ďalej sa navrhovateľ vyjadruje k jednotlivým dôvodom vylúčenia uvedeným v Oznámení o vylúčení. Ad) A – dôvod vylúčenia súvisiaci s požiadavkou kontrolovaného v bode 16.1.11 písm.

b)súťažných podkladov (ďalej len ,,SP“) 9. Navrhovateľ uvádza, že kontrolovaný v Oznámení o vylúčení poukázal na bod 16.1.11 písm.
b)SP, v ktorom požadoval nasledovné, cit.: ,,Klientské testovacie zariadenie – Požaduje sa určitá úroveň zabezpečenia klientskych testovacích zariadení počas certifikačných testovaní, preto súčasťou ponuky uchádzača bude: • Návrh technológie na zabezpečenie klientskej testovacej stanice tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, prípadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice, ktorý bude popisovať, akým spôsobom budú problémy s podvádzaním žiakov účinne eliminované na centrálnej úrovni a na úrovni školy.“ 10. Následne navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke, v dokumente s názvom 16_Návrh_riešenia eTest (ďalej len „Návrh“) ani v ostatných dokumentoch nebol doplnený Návrh technológie na zabezpečenie klientskej testovacej stanice tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, prípadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice, ktorý bude popisovať, akým spôsobom budú problémy s podvádzaním žiakov účinne eliminované na centrálnej úrovni a na úrovni školy. Vo Vami predloženej ponuke je uvedené Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 3 v dokumente Návrh v kapitole 2.1.6 Klientské testovacie zariadenie a aplikácia Testovací klient, kde je však len prepísaný s miernymi úpravami text požiadavky z Opisu predmetu zákazky str. 21 Zabezpečenie pracovnej stanice a Testovanie, pričom je uvedené, že Technické detaily zabezpečenia klientskej stanice budú predmetom Detailného návrhu riešenia (ďalej iba ,,DNR“), avšak nie sú uvedené žiadne ďalšie technické informácie, ktoré by popisovali, akým spôsobom budú problémy s podvádzaním žiakov účinne eliminované na centrálnej úrovni a na úrovni školy. Zároveň nie je ani uvedená v Návrhu riešenia v kapitole 3.4.1 Prevádzkové a podporné moduly a komponenty, ani v ostatných dokumentoch, biznis architektúra klientského testovacieho zariadenia.“ 11. Navrhovateľ v námietkach odmieta tvrdenia kontrolovaného v súvislosti s uvedenou požiadavkou a uvádza, že sa v Návrhu riešenia k spôsobu a k technológii zabezpečenia pracovnej stanice vyjadril nasledovne: • Navrhovateľ poukázal na bod 2.1.4., 1, Certifikačné a pilotné testovanie (str. 11) Návrhu riešenia, cit.: „Informačný systém bude spĺňať nasledovné požiadavky: ,,...vykonávanie testu na zabezpečenej pracovnej stanici s kontrolovaným prístupom (zabezpečenie na úrovni informačného systému, nie manuálne) k systémovým funkciám, ktorá neumožňuje používanie neoprávnených zdrojov, počas realizácie testu, ...“ • Navrhovateľ poukázal na bod 2.1.5., Realizácia testu (str. 14) Návrhu riešenia, cit.: „Dôležitou požiadavkou je: vyriešenie autentifikácie žiaka, obmedzenie možností žiaka podvádzať, zabezpečiť, že žiak bude pracovať samostatne a nebude nepoužívať nepovolené aplikácie alebo nebude pracovať s inými zdrojmi informácií. Tieto problémy budú adresované tak, aby ich bolo možné účinné eliminovať na centrálnej úrovni a na úrovni školy.“ • Navrhovateľ poukázal na bod 2.1.6. (str. 15) Návrhu riešenia, cit.: „...Systém bude fungovať na HW a SW, ktoré sú bežne dostupné na školách, pričom minimálne predpokladané požiadavky sú: • Operačný systém Windows 10, • 4GB RAM, • Internetový prehliadač Edge, Chrome, Firefox. Požaduje sa určitá úroveň zabezpečenia klientskych testovacích zariadení počas certifikačných testovaní, preto zabezpečenie klientskej testovacej stanice bude v rámci Detailného návrhu riešenia navrhnuté tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, prípadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice. Certifikačné testy sa budú vykonávať na zabezpečenej pracovnej stanici s kontrolovaným prístupom k systémovým funkciám (napr. menu Start, panel úloh, prepínanie/spustenie/ukončenie úloh/okien/aplikácií, tlač, vybrané klávesové skratky, zamknutie obrazovky, zmena používateľa, odhlásenie, zmena hesla, vypnutie, reštartovanie, pravé tlačidlo myši, atď). Počas realizácie testu nebude umožnené používanie neoprávnených zdrojov (napr. internetových stránok, okien/aplikácií, súborov, atď). Pracovná stanica bude zabezpečená systémovo, nie manuálne administrátorom školy na každej pracovnej stanici. Kontrola prístupu bude konfigurovateľná. Technické detaily zabezpečenia klientskej stanice budú predmetom Detailného návrhu riešenia. Predpokladáme, že systém pre zabezpečenie pracovnej stanice bude súčasťou aplikácie Testovací klient.“ • Navrhovateľ poukázal na bod 2.1.6. (str. 16) Návrhu riešenia, cit.: „Pre účely ponuky a na základe informácií z Opisu predmetu zákazky navrhujeme vybudovanie Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 4 desktopovej aplikácie, ktorá bude bežať nad operačným systémom pracovnej stanice (notebook, desktop), pričom vlastnosti pracovnej stanice sú špecifikované v OPZ. Desktopová aplikácia umožní vypracovať test aj v prípade výpadku internetového pripojenia. Zároveň takáto aplikácia by mohla umožniť aj distribúciu testu bez pripojenia pracovnej stanice na internet. Rovnako by bolo možné uložiť vypracovaný test a následne ho odoslať na server až po pripojení na internet, prípade ho odoslať alternatívnou cestou - napr. z iného PC, alebo pod.“ 12. Navrhovateľ má za to, že zabezpečeniu pracovných staníc (kapitola testovania) v rámci Návrhu riešenia venoval dostatočnú pozornosť a primerane rozpracoval danú požiadavku kontrolovaného. Zároveň navrhovateľ tvrdí, že určil a popísal aj to, že technológia zabezpečenia pracovnej stanice bude využívať prostriedky operačného systému Windows 10 a že bude súčasťou dodanej aplikácie Testovací klient. Podrobnejšie technické detaily je

navrhovateľa možné spracovať až v rámci plnenia predmetu zákazky a navrhovateľ je pripravený ich spracovať v DNR. V kontexte uvedeného má navrhovateľ za to, že dôvod vylúčenia nie je opodstatnený a aplikovateľný. Ad) B – dôvod vylúčenia súvisiaci s požiadavkou kontrolovaného v bode 16.1.11 písm.

c)SP 13. Navrhovateľ uvádza, že kontrolovaný v Oznámení o vylúčení poukázal na bod 16.1.11 písm.
c)SP, v ktorom požadoval nasledovné, cit.: ,,Návrh riešenia – Návrh riešenia, vychádzajúci z Opisu predmetu zákazky a z Katalógu požiadaviek v rozsahu: • Aplikačná a technická architektúra • Bezpečnostná architektúra • Popis funkčného testovania • Popis záťažového testovania • Popis testovania kybernetickej bezpečnosti • Popis funkcionality pre zabezpečenie testovania pri nedostupnosti Internetu • Popis migrácie dát • Špecifikácia použitého nástroja na kontrolu gramatiky a pravopisu • Popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov, • Aby obsahoval požiadavky a podklady na rozsah a prácnosť a rozsah súčinnosti pri migrácií údajov, • Aby obsahoval požiadavky a podklady na rozsah integrácie na iné informačné systémy.“ Ad) B1 – popis migrácie dát 14. Navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke, v dokumente Návrh je vo vzťahu k Popisu migrácie dát uvedený Export a import len vo všeobecnej rovine ako „export a import testovacích úloh“, bez uvedenia štandardu QTI, alebo ekvivalentného. Predmetná formulácia je zbežne použitá v kapitole 2.1.5. Testovanie — Príprava testovania len ako: „Informačný systém umožní tvorbu úloh prinajmenšom nasledovnými spôsobmi: importom, vytvorením v autorskom nástroji, vytvorením zo šablóny, duplikovaním“ a tiež v kapitole 4.2. Integrácia na externé služby len ako: „Informačný systém bude tiež podporovať export a import testovacích úloh.“ Predmetná formulácia je len opisom požiadaviek č. 91 a č. 110 uvedených v Katalógu požiadaviek.“ Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 5 15. Navrhovateľ v námietkach konštatuje, že v rámci návrhu riešenia kontrolovaný požadoval popísať migráciu dát. Z kontextu súťažných podkladov bolo

navrhovateľa zrejmé, že sa jedná o migráciu dát z existujúceho informačného systému do nového informačného systému eTest. Navrhovateľ uvádza, že migráciu dát v Návrhu riešenia podrobne popísal na niekoľkých miestach: • Navrhovateľ poukázal na kapitolu

(str. 5) Návrhu riešenia, cit.: „Predmetom dodania informačného systému bude predovšetkým: ... dodanie a implementácia centrálneho informačného systému na elektronické testovanie a tvorbu banky úloh, testov a dotazníkov, ktorý bude slúžiť na prípravu, realizáciu, vyhodnocovanie, štatistické spracovanie dát a reportovanie výsledkov, vrátane migrácie dát (z pôvodného informačného systému e-Test), pre všetky ostatné typy úloh, testovania a získavania spätnej väzby.” • Navrhovateľ poukázal na kapitolu
(str. 6) Návrhu riešenia, cit.: „Samotný obsah Banky úloh a testov bude zabezpečený migráciou údajov z pôvodného eTestu a tvorbou nových úloh, testov, dotazníkov a pod.“ • Navrhovateľ poukázal na kapitolu
(str. 7) Návrhu riešenia, - detailizácia migrácie vychádza z požiadaviek kontrolovaného, cit.: “V rámci dodávky projektu budú dodané nasledovné hlavné skupiny manažérskych a Špecializovaných produktov: ... Detailný návrh riešenia ... Popis migrácie dát,“ • Navrhovateľ poukázal na kapitolu
Migrácia dát a bod 5.
Požiadavky na súčinnosť pri migrácii údajov (str. 60 a 61) Návrhu riešenia, kde

neho detailne popisuje proces a jednotlivé kroky migrácie dát. Navyše tieto budú na základe štandardov a tiež požiadavky kontrolovaného detailizované v DNR v rámci realizačnej etapy Analýza a Návrh riešenia. 16. Navrhovateľ má za to, že v rámci Návrhu riešenia venoval dostatočnú pozornosť popisu spôsobu migrácie dát a popísal ju dostatočne. Navrhovateľ dáva do pozornosti, že kontrolovaný nikde v súťažných podkladoch nepožadoval podrobnejší popis importu dát v súvislosti s migráciou dát, navyše požiadavky na import vrátane požadovaného štandardu QTI uviedol v rámci katalógu požiadaviek, pričom navrhovateľ vo svojom Návrhu riešenia jednoznačne deklaroval a zaviazal sa k splneniu všetkých požiadaviek uvedených v rámci katalógu požiadaviek a tiež opisu predmetu zákazky. Z vyššie uvedeného

navrhovateľa vyplýva, že kontrolovaný, v bode B1) Oznámenia o vylúčení, uviedol dôvod, ktorý nebol súčasťou požiadavky na obsah dokumentu/návrhu vlastného riešenia v zmysle súťažných podkladov predmetnej verejnej súťaže. Ad) B2 - Bezpečnostná architektúra

Navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke, v dokumente Návrh je vo vzťahu k Bezpečnostnej architektúre uvedená len všeobecná federácia identít v kapitole 2.1.
Správa používateľov a kapitole 4.
Integrácia na externé služby. V navrhnutom riešení sa používa len štandard OWASP Web Security Testing Guide (WSTG) a neuvažuje sa štandard OWASP Application Security Verification Standard (ASVS), ktorý bol jasne uvedený ako požiadavka (v Katalógu požiadaviek ako č. 52, č. 64 a 65). Ďalej vo Vami predloženej ponuke, v dokumente Návrh Popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov nebol použitý štandard Web Content Accessibility Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 6 Guidelines (WCAG) a bol poskytnutý iba všeobecný vlastný popis riešenia pre zdravotne znevýhodnených žiakov v kapitole 2.1.
Realizácia testovania pre zdravotne znevýhodnených žiakov, ktorý bol jasne uvedený ako požiadavka (v Katalógu požiadaviek ako č. 106). Ďalej vo Vami predloženej ponuke, v dokumente Návrh, vo vzťahu k Bezpečnostnej architektúre, je len citácia požiadavky z Opisu predmetu zákazky — Správa používateľov, resp. z Opisu predmetu zákazky — Požadované výsledky/výstupy. V dokumente Návrh v kapitole 2.1.
Správa používateľov je uvedené: „dvojfaktorová autentifikáciu, minimálne štandardné OTP 2FA autentifikačné, aplikácie (Authy, Microsoft Authenticator, LastPass, alebo ekvivalent — bude definovaný v rámci DNR)“, respektíve v kapitole 4.
Integrácia na externé služby, je uvedené: „integrácia na systém podporujúci dvojfaktorovú autentifikáciu, minimálne štandardné OTP 2FA autentifikačné aplikácie (Authy, Microsoft Authenticator, LastPass, alebo ekvivalent).“ Zahrnutie možnosti pokročilejších metód autentifikácie v podobe U2F, FIDO tokenov, alebo ekvivalentu bolo jasne uvedené ako požiadavka (v Katalógu požiadaviek ako č. 76).“
Navrhovateľ v námietkach konštatuje, že kontrolovaný v rámci dôvodu vylúčenia B2) uvádza 3 rôzne dôvody vylúčenia, a síce že v Návrhu riešenia neboli explicitne uvedené: • štandardy OWASP ASVS • Štandardy WCAG • metódy autentifikácie v podobe U2F, FIDO tokenov alebo ekvivalent.
V tejto súvislosti navrhovateľ uvádza, že kontrolovaný v rámci súťažných podkladov nepožadoval podrobnejší popis súvisiaci s týmito štandardami alebo ich implementáciou. Navrhovateľ konštatuje, že všetky tieto štandardy sú explicitne uvedené v katalógu požiadaviek, ku ktorým v rámci svojho Návrhu riešenia pristúpil a zaviazal sa ich splniť, a z uvedeného dôvodu ich následne v texte Návrhu riešenia nekopíroval. Navrhovateľ konštatuje, že sa v Návrhu riešenia naopak zameral na procesný návrh ním ponúkaného riešenia. Keďže však kontrolovaný v návrhu riešenia požadoval od uchádzačov uviesť: • Popis bezpečnostnej architektúry, • Popis testovania kybernetickej bezpečnosti a • Popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov, tak sa navrhovateľ k týmto jednotlivým štandardom vyjadril aj v rámci svojho Návrhu riešenia nasledovne: • Navrhovateľ poukazuje na bod 7.
Testovanie kybernetickej bezpečnosti (str. 68 a 69) Návrhu riešenia, kde popisuje využitie Štandardu OWASP WSTG a tiež všeobecnejšie postupov OWASP so zameraním na najdôležitejšie ale aj iné zraniteľnosti. Štandard OWASP ASVS je explicitne definovaný v rámci katalógu požiadaviek ale nebolo požadované tento Štandard nejako bližšie upresňovať v rámci návrhu riešenia. Pre samotný Návrh riešenia je však

navrhovateľa dôležité konštatovanie na str. 69, cit.: ,,Testovacie postupy pre bezpečnostné testovanie budú vychádzať zo zmluvných požiadaviek projektu, zákonných požiadaviek ITVS a ZoKB a aplikačnej, biznisovej a bezpečnostnej architektúry, ktorá bude uvedená v Detailnom návrhu riešenia. Jednotlivé bezpečnostné testy budú realizované manuálne vo forme auditu príslušnej konfigurácie komponentu, alebo log záznamu, respektíve s použitím rôznych opensource nástrojov tretích strán, ktoré budú uvedené v dokumente testovacích postupov pre bezpečnostné testovanie.“ Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 7 Navrhovateľ poukazuje na Návrh riešenia - str. 9 a str. 57, že k dvojfaktorovej autentifikácii v Návrhu riešenia uviedol v rámci kapitol „Správa používateľov“ a „Integrácia na externé služby“, cit.: „Modul bude umožňovať ... dvojfaktorovú autentifikáciu, minimálne štandardné OTP 2FA autentifikačné aplikácie (Authy, Microsoft Authenticator, LastPass, alebo ekvivalent – bude definovaný v rámci DNR),“ „V Opise predmetu zákazky sú požadované predovšetkým integrácie na služby súvisiace s prihlasovaním do systému: federácia identít (t.j. využitie inej identity na prihlásenie sa do eTest, napríklad mena a hesla z RIAM), import identít, integrácia na externého providera / SSO / federácia s iným autentifikačným serverom (napr. Facebook, Google, Apple, Microsoft), integrácia na systém podporujúci dvojfaktorovú autentifikáciu, minimálne štandardné OTP 2FA autentifikačné aplikácie (Authy, Microsoft Authenticator, LastPass, alebo ekvivalent).“ Navrhovateľ dodáva, že požiadavka na podrobnejší popis autentifikačných mechanizmov a štandardov sa v súťažných podkladoch tejto verejnej súťaže nenachádza. Navrhovateľ má za to, že príslušné kapitoly v súvislosti so splnením kontrolovanej požiadavky popísal v rámci Návrhu riešenia dostatočne detailne. • Navrhovateľ poukázal na bod 2.1.7. Realizácia testovania pre zdravotne znevýhodnených žiakov (str. 17) Návrhu riešenia, kde

neho popisuje realizáciu testovania pre zdravotne znevýhodnených žiakov, uvádza nástroje, odporúčané asistenčné aplikácie a pod. V súvislosti s normou WCAG je

navrhovateľa dôležité konštatovanie, cit.: „Informačný systém bude spĺňať štandardy pre informačné systémy verejnej správy vrátane štandardov pre znevýhodnených používateľov definovanom v Metodickom usmernení Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky k monitorovaniu prístupnosti webových sídel a mobilných aplikácii.“ Navrhovateľ zároveň dodáva, že uvedené metodické usmernenie nastavuje praktickú aplikáciu vyhodnocovania prístupnosti práve

Web Content Accessibility Guidelines (ďalej len „WCAG“). Navrhovateľ má za to, že v rámci Návrhu riešenia dostatočne popísal realizáciu testovania pre zdravotne znevýhodnených žiakov. • Ad) C – dôvod vylúčenia súvisiaci s požiadavkou kontrolovaného v bode 16.1.11 písm.

d)SP 20. Navrhovateľ uvádza, že kontrolovaný v Oznámení o vylúčení poukázal na bod 16.1.11 písm.
d)súťažných podkladoch, v ktorom požadoval nasledovné, cit.: ,,Architektonický návrh – Architektonický návrh, ktorý bude pozostávať z: • nákresu a popisu biznis architektúry, • nákresu a popisu aplikačnej architektúry, • nákresu a popisu technologickej architektúry, • použitých komponentoch (komerčných alebo open source), • popisu využitia cloudových služieb a odhadu ich mesačnej ceny, • popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po nasadení diela, • popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po uplynutí trvania prevádzkovej podpory po nasadení diela do produkcie.“ Ad) C1 – k nákresu a popisu aplikačnej architektúry Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 8 21. Navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke v dokumente Návrh je vo vzťahu k Nákresom uvedený nákres aplikačnej architektúry. Nákres aplikačnej architektúry neobsahuje potrebné informácie o vzťahoch medzi jednotlivými prvkami a obsahuje len rozdelenie aplikačných prvkov do kategórií po jednotlivých stĺpcoch. Zobrazenie týchto vzťahov je nevyhnutné na zabezpečenie jasného a komplexného pochopenia fungovania navrhovaného riešenia. Nákres aplikačnej architektúry je obmedzený len na vizualizáciu aplikačných prvkov v jednotlivých kategóriách, bez jasného určenia ich vzájomných vzťahov a nie je možné zhodnotiť efektívnosť, škálovateľnosť a integrovanosť navrhovaného riešenia. Absencia vzájomných vzťahov znemožňuje komplexné posúdenie predkladanej ponuky voči stanoveným požiadavkám.“ 22. Navrhovateľ v námietkach konštatuje, že kontrolovaný požadoval v rámci návrhu riešenia predložiť nákres a popis biznis architektúry, aplikačnej architektúry a tiež technologickej architektúry. Navrhovateľ konštatuje, že architektúra navrhovaného riešenia bola nakreslená a popísaná na základe informácií uvedených v súťažných podkladoch a bude na základe štandardov upresnená v rámci DNR v realizačnej etape projektu. Navrhovateľ konštatuje, že väzby sú uvedené v dodanej biznis a tiež technologickej infraštruktúre. Zároveň z Návrhu riešenia a popisu

navrhovateľa vyplýva, že väzby budú výhradne medzi komponentami prístupovej vrstvy a biznis komponentami, prístupovej vrstvy a prevádzkovými a podpornými modulmi a tiež externými systémami a komponentami prostredníctvom API rozhrania. Konkrétne prepojenia medzi jednotlivými modulmi budú

navrhovateľa došpecifikované v rámci DNR (v etape analýzy a návrhu riešenia) z dôvodu minimalizácie eliminácie chýb v návrhu vyplývajúcich z nedostatku informácií v rámci procesu zadávania tejto verejnej súťaže.

Navrhovateľ má za to, že splnil požiadavku kontrolovaného súvisiacu s dodaním návrhu architektúry riešenia a jej popis je dostatočný na to, aby mohol kontrolovaný riadne posúdiť ponuku. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 9
Navrhovateľ konštatuje, že architektúra riešenia je popísaná na str. 26 až 52 Návrhu riešenia. V kontexte uvedeného navrhovateľ poukazuje na nasledovné časti (kapitoly) Návrhu riešenia: • kapitola
Architektúra riešenia (str. 26) Návrhu riešenia, cit.: „Predložený návrh riešenia spĺňa požiadavky verejného obstarávateľa. Ide o predbežný návrh riešenia, ktorý však ešte nepredstavuje plnenie a je pripravený na základe znalostí uvedených v rámci Opisu predmetu zákazky a iných dokumentov predložených v rámci procesu VO. Tento návrh bude rozšírený, doplnený alebo upravený v rámci plnenia zmluvy, pričom súčasťou plnenia je na základe štandardov aj Detailný návrh riešenia, ktorý bude záväzný pre implementáciu riešenia. Informačný systém bude koncipovaný ako otvorená platforma postavená na otvorených štandardoch v oblasti elektronického testovania a súvisiacich informačných technológií.” • K aplikačnej architektúre navrhovateľ uvádza (str. 27 Návrhu riešenia), cit.: ,,Navrhovaná logická aplikačná architektúra popisuje aktuálne identifikované aplikačné komponenty na základe informácií poskytnutých v rámci Opisu predmetu zákazky. Aplikačná architektúra bude upresnená v rámci Detailného návrhu riešenia.“
Navrhovateľ má za to, že požiadavka kontrolovaného na ešte väčšiu mieru detailu v popise uvedených oblastí, by už predstavovalo samotné plnenie diela/plnenie predmetu zákazky a vzhľadom na fakt, že kontrolovaný deklaroval v súťažných podkladoch tejto verejnej súťaže, že DNR musí byť v súlade s návrhom riešenia predloženým v procese verejného obstarávania, by detailný popis vzťahov a väzieb neúmerne obmedzoval úspešného uchádzača/zhotoviteľa diela IS eTest II. v etape analýzy a dizajnu plnenia zákazky. Ad) C2 – k popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po nasadení diela a popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po uplynutí trvania prevádzkovej podpory po nasadení diela do produkcie
Navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke, v dokumente Návrh, vo vzťahu k popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po nasadení diela, a k popisu a využitia licencií tretích strán a ich cena jednorazového nákupu a cena za prevádzku na 24 mesiacov v trvaní 24 mesiacov po uplynutí trvania prevádzkovej podpory po nasadení diela do produkcie v kapitole 3.4.2 Prevádzkové a podporné moduly a komponenty nie sú uvedené v prípade produktov WSO2 Enterprise Integrátor, WSO2 API Manager, WSO2 Integration Studio definície integračných komponentov. Ďalej vo Vami predloženej ponuke, v dokumente Návrh, vo vzťahu k Cene za licencie tretích strán, ich maintenance a support a za cloud služby, v kapitole 3.4.3 Technologické moduly a komponenty nie sú uvedené v prípade produktov ESET, Clam AV a GRAYLOG definície technologických modulov a komponentov.“
K uvedenému navrhovateľ v námietkach konštatuje, že ide o sadu štandardných opensource softvérových produktov, ktorých funkcionalita a účel použitia sa nachádza vo viacerých častiach jeho ponuky, keďže účelom ich použitia je vytvorenie štandardných integračných rozhraní, externých ako aj interných. Z uvedeného dôvodu navrhovateľ neuvádzal Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 10 opakovane všetky popisy a definície funkcionalít predmetných SW produktov v bode 3.4.
svojho Návrhu riešenia. Zároveň navrhovateľ uvádza, že predložený Návrh riešenia obsahuje popis všetkých požadovaných funkcionalít a procesov definovaných kontrolovaným v súťažných podkladoch, v niektorých prípadoch aj nad rámec požiadaviek. Tabuľka v bode 3.4.
Návrhu riešenia je

navrhovateľa len prevodníkom medzi funkcionalitami navrhovaného informačného systému a SW produktami, ktoré chce navrhovateľ využiť na naplnenie požiadaviek. Keďže funkcionalita logovania sa nachádza vo viacerých častiach Návrhu riešenia, navrhovateľ konštatuje, že tabuľka v bode 3.4.3. neobsahuje zduplikovaný popis už popísanej funkcionality technologického modulu, ktorým je v tomto prípade SW GRAYLOG. Rovnako to

navrhovateľa platí aj pre oblasť bezpečnosti a SW produkty a moduly ESET a Clam AV. Ad) D – dôvod vylúčenia súvisiaci s požiadavkou kontrolovaného v bode 16.1.11 písm.

l)SP 28. Navrhovateľ uvádza, že kontrolovaný v Oznámení o vylúčení poukázal na bod 16.1.11 písm.
l)súťažných podkladoch, v ktorom požadoval nasledovné, cit.: ,,Štruktúra detailného návrhu riešenia (DNR) – návrh štruktúry (v členení na kapitoly, t.j. názvy kapitol) Detailného návrhu riešenia, ktorý bude plne v súlade s dokumentami, ktoré tvoria obsah ponuky a sú vymenované a špecifikované vyššie v písm.
a)– k).“ 29. Navrhovateľ poukazuje na závery kontrolovaného, ktorý v Oznámení o vylúčení skonštatoval, cit.: ,,Vo Vami predloženej ponuke, v dokumente Návrh, v kapitole 10 Štruktúra detailného návrhu riešenia (DNR) je uvedená štruktúra DNR, v ktorej ale nie je uvedená časť popisujúca testovacie scenáre, časť popisujúca funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov a pre dynamické testovanie, tiež neobsahuje časť „presná špecifikácia úloh pre certifikované merania“.“ 30. K uvedenému navrhovateľ v námietkach konštatuje, že testovacie scenáre sú síce na základe štandardov popisované v rámci etapy Analýza a Návrh riešenia avšak majú byť popísané vo výstupoch Rl-2 Plán testov, resp. R-1-2 Plán a stratégia testovania. Ďalej navrhovateľ uvádza, že to, že návrh štruktúry DNR neobsahuje názvy kapitol, resp. podkapitol s uvedenými témami, neznamená, že uvedené témy nebudú riešené v rámci podkapitol, popisu komponentov, prípadov použitia a pod. jednotlivých kapitol DNR.

navrhovateľa bola požadovaná štruktúra DNR vytvorená na základe požadovaných štandardov a je s nimi plne v súlade. 31. V kontexte vyššie uvedeného je navrhovateľ presvedčený, že ak mal kontrolovaný po preštudovaní ponuky navrhovateľa pochybnosti o splnení požiadaviek na predmet zákazky, resp. mu vystali pochybnosti/nejasnosti v súvislosti s preukázaním naplnenia požiadaviek na predmet zákazky, mal priestor využiť inštitút vysvetlenia ponuky v zmysle § 53 ods. 1 zákona o verejnom obstarávaní. 32.

navrhovateľa ust. § 53 ods. 5 písm. b) zákona o verejnom obstarávaní neumožňuje kontrolovanému vylúčiť uchádzača len na základe pochybností či cenová ponuka zahŕňa všetky požiadavky na predmet zákazky, najmä ak vylúčenie predstavuje najsilnejší a najprísnejší zásah do práv uchádzača a každé takéto rozhodnutie by mal kontrolovaný dôkladne zvážiť a mal by k nemu dospieť po vyhodnotení všetkých relevantných dôkazov. Oprieť vylúčenie uchádzača na nedostatočne zistenom skutkovom stave, na nedostatočne a Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 11 nesprávne vyhodnotených predložených dôkazoch

navrhovateľa predstavuje zásadné porušenie princípu právneho státu, a to princípu právnej istoty. Navrhovateľ má za to, že využitím inštitútu vysvetlenia a jeho prípadným akceptovaním zo strany kontrolovaného nedochádza automaticky k zmene ponuky, ale išlo by len o vyjasnenie nejasností a nezrovnalostí, ktoré kontrolovanému v súvislosti s vyhodnotením ponuky navrhovateľa vznikli. V súvislosti s uvedeným navrhovateľ poukazuje na rozhodovaciu prax úradu

Navrhovateľ konštatuje, že pri Návrhu riešenia vychádzal z dostupných informácií a svojich skúseností z iných projektov, ktoré dodával alebo sú v procese dodávky (napr. Digitálny konferenčný systém pre Kanceláriu NR SR, Komplexný informačný systém pre Úrad na ochranu osobných údajov, Centrálny informačný systém pre štátnu službu pre Národnú agentúru sieťových a elektronických služieb, alebo aktuálne implementovaný IS Evidencie odsúdených osôb pre Generálnu prokuratúru Slovenskej republiky a mnohé ďalšie). Nakoľko navrhovateľ nie je aktuálnym dodávateľom/zhotoviteľom na strane kontrolovaného konštatuje, že pri Návrhu riešenia mohol vychádzať len zo zverejnených informácií poskytnutých kontrolovaným v súťažných podkladoch (najmä v Prílohe č. 7 OPZ) tejto verejnej súťaže. Navyše navrhovateľ dodáva, že v Návrhu riešenia poskytol takú mieru detailu ponúkaného riešenia, ktoré mu nebude brániť ho dopracovať v rámci DNR po oboznámením sa s interným prostredím kontrolovaného, t.j. vo fáze v procese analýzy.
V kontexte vyššie uvedeného má navrhovateľ za to, že kontrolovaný vylúčením navrhovateľovej ponuky bez aplikovania inštitútu vysvetľovania

§ 53zákona o verejnom obstarávaní porušil najmä § 10 ods.

2 zákona o verejnom obstarávaní, a to princíp transparentnosti, princíp proporcionality a princíp nediskriminácie hospodárskych subjektov a rovnakého zaobchádzania. Navrhovateľ je presvedčený, že predložená ponuka Rozhodnutie úradu č. 2052-6000/2015, bod 53, cit.: ,,Úrad má za to, že je potrebné, aby vysvetlením ponuky bola každá požiadavka kontrolovaného skutočne preukázaná, teda aby bolo jasné aký výrobok a s akými parametrami uchádzač č. 1 kontrolovanému ponúka, a teda či výrobok uvedený v ponuke uchádzača č. 1 spĺňa požiadavky kontrolovaného na predmet zákazky. Úrad má za to, že kontrolovaný je v tomto prípade povinný dôkladne preskúmať splnenie predmetnej požiadavky na predmet zákazky tak, aby bolo možné bez, pochybností konštatovať jej splnenie/nesplnenie a tiež skutočnosť, či vysvetlením došlo alebo nedošlo k zmene ponuky. Kontrolovaný má teda povinnosť náležite sa vysporiadať s každým predloženým vysvetlením ponuky v intenciách zákona o verejnom obstarávaní a jednoznačne konštatovať k akému záveru dospel. V dokumentácii by zároveň malo byť uvedené odôvodnenie, na základe akých skutočností dospel k záveru, že predložené vysvetlenie možno akceptovať, resp. či vysvetlenie zakladá dôvod na vylúčenie ponuky uchádzača.“ Rozhodnutie úradu č. 12073-6000/2023-OD zo dňa 25 .08.2023, bod 36, cit.: ,,Úrad poukazuje na to, že verejný obstarávateľ by mal pristúpiť k vylúčeniu ponuky uchádzača až po predchádzajúcom riadnom zvážení všetkých zákonných možností, tak aby vylúčenie ponuky uchádzača z verejného obstarávania predstavovalo prostriedok ultima ratio. Každý krok verejného obstarávateľa uskutočnený v procese verejného obstarávania musí byť vhodný, potrebný a nevyhnutý, čo sú základné požiadavky vyplývajúce z princípu proporcionality

§ 10ods.

2 zákona o verejnom obstarávaní.

princípu proporcionality verejný obstarávateľ nesmie ísť nad rámec toho, čo je na dosiahnutie daného cieľa potrebné a nevyhnutné. To znamená, že medzi rozhodnutím o vylúčení a sledovaným cieľom musí byť určitá kolerácia. Inštitút vylúčenia sa má využiť až po vyčerpaní všetkých inštitútov, ktoré dáva k dispozícii normatívna právna úprava reprezentovaná zákonom o verejnom obstarávaní. Miernejší prostriedok, resp. úkon kontrolovaného, ktorý by mal predchádzať samotnému úkonu vylúčenia ponuky z verejného obstarávania, je inštitút vysvetlenia, ktorý je v súlade s princípom proporcionality možné využiť aj opätovne, pokiaľ by prípadné nedostatky predložených dokladov bolo možné vysvetlením jednoducho objasniť alebo dovysvetliť. Ak uchádzač nedokáže ani v rámci vysvetľovacieho konania ozrejmiť, vysvetliť, odstrániť nezrovnalosti v predloženej ponuke, až v tomto momente možno považovať vylúčenie ponuky uchádzača za nevyhnutné. Požiadavka nevyhnutnosti vylúčenia ponuky uchádzača z verejného obstarávania spočíva v tom, že je potrebné skúmať či v daných okolnostiach neexistovali menej šetrnejšie prostriedky, než je vylúčenie ponuky uchádzača z verejného obstarávania.“ 2 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 12 (najmä Návrh riešenia) spĺňa všetky požiadavky na predmet zákazky uvedené v dokumentoch potrebných na vypracovanie ponuky.

navrhovateľa z doručeného Oznámenia o vylúčení, nie je možné dôjsť k jednoznačnému záveru, že ním predložená ponuka nespĺňa vyššie identifikované požiadavky na predmet zákazky, čím kontrolovaný neuniesol dôkazné bremeno vo vzťahu k preukázaniu existencie dôvodov na vylúčenie, tak ako ich identifikoval v Oznámení o vylúčení. Z tohto dôvodu navrhovateľ považuje vylúčenie za nezákonné. Na podporu svojich tvrdení navrhovateľ poukazuje aj na metodické usmernenia úradu

V petite námietok navrhovateľ navrhuje, aby úrad v súlade s § 175 ods. 1 písm. a) zákona o verejnom obstarávaní nariadil kontrolovanému odstrániť protiprávny stav, a to zrušiť rozhodnutie o vylúčení navrhovateľa zo dňa
2024, vrátiť navrhovateľa späť do procesu predmetnej verejnej súťaže a pokračovať vo vyhodnotení predložených ponúk. Začiatok konania o preskúmanie úkonov kontrolovaného 36.

ust. § 171 ods. 1 zákona o verejnom obstarávaní sa konanie o preskúmanie úkonov kontrolovaného na základe námietok začína dňom doručenia námietok úradu. Na základe uvedeného úrad konštatuje, že konanie o preskúmanie úkonov kontrolovaného na základe námietok navrhovateľa začalo dňa 23. 02. 2024. 37.

§ 173ods.

1 písm. a) zákona o verejnom obstarávaní kontrolovaný je povinný doručiť úradu písomné vyjadrenie k podaným námietkam a kompletnú dokumentáciu

§ 24

v origináli do siedmich dní odo dňa doručenia námietok, ak ide o konanie o preskúmanie úkonov kontrolovaného na základe námietok; úrad neprihliada na písomné vyjadrenie k podaným námietkam a dôkazy doručené kontrolovaným po uplynutí tejto lehoty. 38.

§ 173ods.

2 zákona o verejnom obstarávaní doručením kompletnej dokumentácie v origináli úradu, ak ide o elektronickú komunikáciu, sa rozumie sprístupnenie elektronickej podoby dokumentácie zriadením prístupu do elektronického prostriedku použitého na elektronickú komunikáciu v lehote

odseku

Súčasťou elektronickej podoby dokumentácie sú aj auditné záznamy o všetkých úkonoch vykonaných v použitom elektronickom prostriedku. Ak kontrolovaný predkladá dokumentáciu alebo jej časť v listinnej podobe, môže úradu predložiť fotokópiu tejto dokumentácie, ak zároveň písomne potvrdí, že táto dokumentácia súhlasí s originálnym vyhotovením dokumentácie. Kontrolovaný môže nahliadať do dokumentácie ním doručenej úradu. V prípadoch, keď sa konanie o preskúmanie úkonov kontrolovaného pred úradom nezačne, úrad bez zbytočného odkladu poskytnutú dokumentáciu vráti.
Kontrolovaný dňa
2024 doručil úradu vyjadrenie k podaným námietkam spolu s listinnou dokumentáciou. Následne kontrolovaný dňa
2024 zriadil úradu ako kontrolnému orgánu prístup do IS EPVO použitého na elektronickú komunikáciu, a to v súlade s postupom

§ 173ods.

2 zákona o verejnom obstarávaní. Úrad preskúmaním sprístupnenej elektronickej a doručenej listinnej dokumentácie kontrolovaného konštatuje, že kontrolovaným predloženú dokumentáciu v origináli k predmetnej verejnej súťaži považuje za kompletnú odo dňa

3 MU úradu č. 3890-5000/2019 a MU úradu č. 14623-5000/2023 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 13 40.

§ 173ods.

8 zákona o verejnom obstarávaní úrad môže prerušiť konanie o preskúmanie úkonov kontrolovaného s cieľom získať odborné stanovisko alebo znalecký posudok. Od vydania rozhodnutia o prerušení konania do doručenia odborného stanoviska alebo znaleckého posudku úradu lehota

§ 175ods.

5 neplynie, najviac však 30 dní. Túto lehotu môže úrad z objektívnych dôvodov predĺžiť najviac o 30 dní, o čom informuje účastníkov konania.

Nakoľko úradu v predmetnom konaní vznikla potreba zabezpečiť si zodpovedanie otázok odborného charakteru v kontexte navrhovateľom uvádzaných skutočností, úrad v súlade s ustanovením § 173 ods. 8 zákona o verejnom obstarávaní vydal dňa
2024 rozhodnutie o prerušení konania č. 7305-6000/2024-P, ktorým prerušil konanie s cieľom získať v predmetnej veci odborné stanovisko.
Po prerušení konania úrad listom označeným ako ,,Žiadosť o odborné stanovisko“ č. 73056000/2024-OS zo dňa
2024 oslovil p. AA znalca z odboru 100000 elektrotechniky, resp. odvetvia: 100900 počítačové programy (software), zapísaného v zozname znalcov vedeným Ministerstvom spravodlivosti Slovenskej republiky pod ev. č. xxxx (ďalej len „znalec“). Dňa
2024 znalec doručil úradu dokument označený ako „Odborné stanovisko“ č. 06/2024 zo dňa
2024 (ďalej len „odborné stanovisko“) vo vzťahu k namietaným skutočnostiam navrhovateľa. Písomné vyjadrenie kontrolovaného k námietkam navrhovateľa
Úvodom kontrolovaný pre ucelenosť uvádza, že predmetná zákazka je celonárodného významu, ktorá v zmysle programového vyhlásenia vlády je zásadným krokom k podpore digitalizácie a rozvíjania moderných metód pri vzdelávaní žiakov. Kontrolovaný zároveň zdôrazňuje, že predmet zákazky - systém eTest II. bude výnimočným v kontexte IT systémov verejnej správy najmä z pohľadu vysokých nárokov na zvládnutie paralelného pripojenia veľkého počtu užívateľov (požadovaných 60 000 žiakov prihlasujúcich sa naraz v priebehu 3 sekúnd), a preto je kľúčovou úlohou kontrolovaného obstarať nielen lacný ale aj kvalitný a technologicky jedinečný systém eTest II., ktorý zaručí splnenie deklarovaných cieľov z Plánu obnovy a odolnosti (ďalej len ,,POO“) a splnenie míľnika realizácie elektronickej maturity na všetkých stredných školách. V kontexte uvedeného kontrolovaný konštatuje, že s maximálnou mierou profesionality, odbornosti a objektivity pristúpil k vyhodnoteniu ponuky navrhovateľa a s vedomím si veľkej zodpovednosti voči budúcim maturantom a Ministerstvu školstva, výskumu, vývoja a mládeže SR, ako svojho zriaďovateľa, posúdil ponuku navrhovateľa s jediným cieľom a to vybrať dodávateľa systému, ktorý naplní všetky požiadavky na predmet zákazky v požadovanej kvalite a plne v súlade s dokumentmi potrebnými na vypracovanie ponuky.
Kontrolovaný zároveň poukazuje na chybnú interpretáciu v úvode námietky, že cit.: ,,V nadväznosti na „Oznámenie o vylúčení uchádzača“ zo dňa
2024...“, kde v skutočnosti bolo navrhovateľovi doručené oznámenie o vylúčení ponuky (nie uchádzača), ktorá jednoznačne a preukázateľne nespĺňala požiadavky na predmet zákazky, ktoré boli stanovené kontrolovaným v súťažných podkladoch v bode 16.1.11 písm. b), 16.1.11 písm. c), 16.1.11 písm. d) a 16.1.11 písm. l), pričom vylúčenie bolo v plnom súlade s princípmi verejného obstarávania. Kontrolovaný považuje všeobecnú argumentáciu navrhovateľa, vrátane citovaní rozhodnutí a metodických usmernení úradu, za bezpredmetnú, nakoľko uvedené citované dokumenty popisujú vysvetľovanie ponuky v prípade identifikovania Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 14 nejasností resp. nezrovnalostí, avšak v ponuke navrhovateľa boli identifikované skutočnosti neuvedenia/nepredloženia požadovaných informácií tak, ako uviedol v oznámení o vylúčení, cit.: ,,(...) v prípade skutočností špecifikovaných vyššie (A, B1, B2, C1, C2 a D) nejde o nezrovnalosti alebo nejasnosti v poskytnutých dokumentoch, ktoré je možné s využitím inštitútu vysvetľovania odstrániť, naopak ide o neodstrániteľné a zásadné nedostatky v ponuke uchádzača a preto komisia navrhla verejnému obstarávateľovi ponuku vylúčiť“. Kontrolovaný trvá na svojom rozhodnutí o vylúčení ponuky navrhovateľa. Kontrolovaný v súvislosti s argumentáciou navrhovateľa upriamuje pozornosť na rozhodnutie úradu č. 9533-6000/2022-OD 4 zo dňa
2022 a výkladové stanovisko úradu č. 1/2021 zo dňa
2021
Z vyššie citovaného rozhodnutia, resp. výkladového stanoviska úradu

kontrolovaného vyplýva, že vo verejnom obstarávaní sa od hospodárskych subjektov vyžaduje určitá miera aktivity, a preto sa kontrolovaný nestotožňuje s postupom, ktorý uplatnil navrhovateľ, keď namiesto toho, aby pred predložením svojej ponuky proaktívne skontroloval obsah svojej ponuky a jej plný súlad s požiadavkami na obsah ponuky, očakával, že kontrolovaný v rámci vyhodnocovania ponúk po identifikácii nesúladu navrhovateľom predloženej ponuky s požiadavkami na predmet zákazky, bude tento zjavný nesúlad riešiť inštitútom vysvetľovania. Naopak, kontrolovaný je presvedčený, že postupoval v súlade s ustanovením § 53 ods. 1 zákona o verejnom obstarávaní, cit.: „Ak komisia identifikuje nezrovnalosti alebo nejasnosti v informáciách alebo dôkazoch, ktoré uchádzač poskytol, písomne požiada o vysvetlenie ponuky a ak je to potrebné aj o predloženie dôkazov. Vysvetlením ponuky nemôže dôjsť k jej zmene.“, zmysle ktorého si jasne uvedomoval, že inštitútom vysvetľovania nie je možné ponuku meniť a teda ani dopĺňať chýbajúce informácie a preto postupoval tak, ako mu navrhovateľ vytýka v námietkach, a teda, že ponuku navrhovateľa vylúčil bez procesu vysvetľovania, vzhľadom na to, že zistený nesúlad ponuky bol takého charakteru, ktorý neumožnil nápravu využitím inštitútu vysvetľovania.

Kontrolovaný konštatuje, že všeobecným nedostatkom ponuky navrhovateľa v časti Návrh riešenia je, že sa navrhovateľ prílišne zameral na procesné rozpracovanie 6 a naopak na niekoľkých miestach opomenul rozpracovanie technického riešenia v zmysle požiadaviek kontrolovaného. Z pohľadu kontrolovaného, išlo často len o prepis textu Súťažných podkladov a to Prílohy 07 Opis predmetu zákazky, miestami aj s typografickými nepresnosťami v pôvodnom Opise predmetu zákazky, pričom tento prepis bol V ktorom sa okrem iného uvádza, cit.: ,,(...) úrad považuje za potrebné podotknúť, že uchádzač, ktorý chce byť v akomkoľvek verejnom obstarávaní úspešný, by mal pristupovať k príprave ponuky dôsledne, s istou dávkou obozretnosti a profesionality, nakoľko zostavenie a predloženie kvalifikovanej ponuky obsahujúcej všetky potrebné doklady preukazujúce technickú alebo odbornú spôsobilosť na plnenie predmetu zákazky je v jeho záujme, pričom je potrebné si uvedomiť, že len uchádzač zodpovedá za obsah svojej ponuky. Uchádzač by mal teda pri zostavovaní ponuky plne reflektovať podmienky stanovené verejným obstarávateľom alebo obstarávateľom v dokumentoch potrebných na vypracovanie ponuky, resp. v dokumentoch potrebných na preukázanie splnenia podmienok účasti(...)“ 5 V ktorom sa okrem iného uvádza, cit.: ,,(...) Uchádzač by sa nemal spoliehať na skutočnosť, že na odstránenie prípadných nezrovnalostí jeho ponuky bude vytvorený priestor v neskorších fázach verejného obstarávania a že situácia bude na základe iniciatívy verejných obstarávateľov nakoniec vyriešená v jeho prospech. Pasivita uchádzača a jeho nedôsledné dbanie o svoje práva môže vyvolať práve opačný následok a nič na tom nemusí zmeniť ani prípadné podanie námietok.“ 6 Pozn. kontrolovaného, cit.: ,,ako aj uvádza vo svojej námietke na str. 2: „Navrhovateľ sa v Návrhu riešenia zameral naopak práve na procesné rozpracovanie ním ponúkaného riešenia.““ 4 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 15 navrhovateľom spracovaný bez dostatočného zapracovania bodov Katalógu požiadaviek, tam, kde to bolo kontrolovaným požadované.
K tvrdeniu navrhovateľa, cit.: ,,Treba si však uvedomiť, že spracovanie Návrhu riešenia a jeho granularita je limitovaná práve tým, že navrhovateľ nemá dostatočnú znalosť prostredia, aby vedel spracovať Návrh riešenia ešte vo väčšom detaile.“ kontrolovaný konštatuje, že navrhovateľ mal dostatok informácií na to, aby svoju ponuku vypracoval v zmysle požiadaviek kontrolovaného a práve v Návrhu riešenia navrhovateľ nepreukázal schopnosť analyzovať a v rámci svojej ponuky prepojiť dva jemu dostupné základné dokumenty potrebné na vypracovanie ponuky, ktoré boli súčasťou Súťažných podkladov a to menovite Prílohu 07 Opis predmetu zákazky a Prílohu 07 P1 Katalóg požiadaviek a svoju ponuku vypracovať v súlade s požiadavkami kontrolovaného. Kontrolovaný dodáva, že v rámci Súťažných podkladov (bod 16.1.11) požadoval iba také dokumenty ponuky na splnenie požiadaviek na predmet zákazky, ktoré by bol ktorýkoľvek uchádzač, aj bez predchádzajúcej detailnej znalosti prostredia, schopný vypracovať a dodať v rámci svojej ponuky v plnom súlade s požiadavkami kontrolovaného.
Kontrolovaný sa následne ďalej vo vyjadrení vyjadruje k jednotlivým dôvodom vylúčenia a podáva stanovisko k jednotlivým častiam námietky navrhovateľa. K dôvodu vylúčenia pod písm. A)
K požiadavke na Klientské testovacie zariadenie kontrolovaný konštatuje, že je pre neho kľúčovou požiadavkou, nakoľko samotné testovanie žiakov na školách pri certifikačných testovaniach na celoštátnej úrovni bude prebiehať cez toto zariadenie a bude musieť technologicky zvládnuť vysoké nároky na počet súčasných používateľov (požadovaných 60 tisíc testovaných žiakov). Preto kontrolovaný vyžadoval, aby v rámci ponuky uchádzači dodali návrh technológie na zabezpečenie klientskej testovacej stanice tak, ako je jasne uvedené v požiadavke v bode 16.1.11 písm. b) SP.

kontrolovaného ide o neodpustiteľnú požiadavku, pretože chcel mať istotu, že sa uchádzač bude s touto požiadavkou na predmet zákazky vedieť technicky vysporiadať a už pri predkladaní ponuky by mal mať uchádzač jasno, akou technológiou bude táto klientská testovacia stanica riešená. Kontrolovaný, vedomý si časových rámcov zákazky, jednoznačne pokladal za dôležité, aby technické riešenie klientskej testovacej stanice mal uchádzač jednoznačne a jasne premyslené, pretože nemá byť predmetom rozhodovania a hľadania najvhodnejšieho riešenia v rámci prípravy DNR, ale musí byť jasne uchádzačom deklarované už v rámci ponuky. 50. Následne kontrolovaný argumentuje k jednotlivým odkazom navrhovateľa na jeho Návrh riešenia uvedených v námietkach (viď bod 11 tohto rozhodnutia): • • Návrh riešenia, bod 2.1.4. 1, Certifikačné a pilotné testovanie - citovaná textácia v Návrhu riešenia je

kontrolovaného iba doslovným prepisom požiadavky z OPZ str. 14 Testy a dotazníky,

Certifikačné a pilotné testovanie. Návrh riešenia, bod 2.1.
– citovaná textácia v Návrhu riešenia je

kontrolovaného iba doslovným prepisom požiadavky zo str. 22 OPZ Zabezpečenie proti podvodom, pričom z takto formulovanej informácie navrhovateľa v jeho Návrhu riešenia vyplýva, že sa tým navrhovateľ bude musieť ešte len zaoberať. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 16 • • Návrh riešenia, bod 2.1.

- k tomuto kontrolovaný uvádza, že navrhovateľ v tomto bode iba prepísal text zo str. 10 a str. 21 OPZ. Návrh riešenia, bod 2.1.6 - k tomuto bodu kontrolovaný dodáva, že navrhovateľ vo svojej námietke cituje iba časť textu svojho Návrhu riešenia, pričom kompletný text je nasledovný: „Existuje viacero spôsobov ako vyriešiť situáciu s výpadkami, malou priepustnosťou alebo nedostupnosťou siete Internet pri používaní centralizovaných aplikácii Finálne riešenie pre aplikáciu Testovacieho klienta bude detailne popísané a schválené v rámci Detailného návrhu riešenia. Pre účely ponuky a na základe informácií z Opisu predmetu zákazky navrhujeme vybudovanie desktopovej aplikácie, ktorá bude bežať nad operačným systémom pracovnej stanice (notebook, desktop), pričom vlastnosti pracovnej stanice sú špecifikované v OPZ. Desktopová aplikácia umožní vypracovať test aj v prípade výpadku internetového pripojenia. Zároveň takáto aplikácia by mohla umožniť aj distribúciu testu bez pripojenia pracovnej stanice na internet. Rovnako by bolo možné uložiť vypracovaný test a následne ho odoslať na server až po pripojení na internet, prípade ho odoslať alternatívnou cestou - napr. z iného PC, alebo pod. Alternatívnou technológiou môže byť využitie Progressive Web Apps, ktorá umožňuje offline mód webových aplikácií. Aj toto riešenie má svoje výhody. Finálna technológia bude predmetom Detailného návrhu riešenia. V každom prípade Testovací klient bude spĺňať všetky požiadavky na aplikáciu a bude rešpektovať všetky požiadavky súvisiace s nedostupnosťou siete Internet na pracovných staniciach, na ktorých bude prebiehať testovanie.“ K odcitovanému kontrolovaný uvádza, že celá táto časť je venovaná popisu spôsobu, ako chce navrhovateľ riešiť situáciu s výpadkami, malou priepustnosťou alebo nedostupnosťou siete Internet, a okrem toho - uvádza alternatívne technológie, nie však jednoznačný návrh technického riešenia a zároveň tiež opakovane uvádza, že finálna technológia bude predmetom DNR.
K tvrdeniu navrhovateľa, že určil a popísal aj to, že technológia zabezpečenia pracovnej stanice bude využívať prostriedky OP Windows 10 atď. (viď bod 12 tohto rozhodnutia) kontrolovaný konštatuje, že navrhovateľ iba zopakoval požiadavku kontrolovaného v OPZ a zopakoval, že sa tým mieni zaoberať až v rámci spracovania DNR.
V kontexte vyššie uvedeného kontrolovaný zotrváva na tom, že cit.: ,,navrhovateľ vo svojej ponuke nepredložil Návrh technológie na zabezpečenie klientskej testovacej stanice tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, prípadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice, ktorý bude popisovať, akým spôsobom budú problémy s podvádzaním žiakov účinné eliminované na centrálnej úrovni a na úrovni školy.“ K dôvodu vylúčenia pod písm. B1)
Kontrolovaný zdôrazňuje, že v SP bod 16.1.11 c) - Návrh riešenia - vyslovene žiadal, aby dokumenty ponuky požadované na splnenie požiadaviek na predmet zákazky vychádzali z OPZ a z Príloha 07 P1 Katalógu požiadaviek v nich definovanom rozsahu. Zároveň kontrolovaný poukazuje aj na str. 7 OPZ, cit.: „Opis predmetu zákazky a Katalóg požiadaviek tvoria komplementárne dokumenty a vzájomne sa dopĺňajú. Všetky požiadavky uvedené v Opise predmetu zákazky a v Katalógu požiadaviek sú záväzné pre uchádzača.“ Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 17
Z pohľadu kontrolovaného navrhovateľ vo svojom Návrhu riešenia neprihliadal v plnom rozsahu na požiadavky SP a to konkrétne Príloha 07 P1 Katalóg požiadaviek. Kontrolovaný konštatuje, že navrhovateľ by vo vlastnom záujme mal využiť verejne dostupné informácie k príprave Návrhu riešenia, čo v obdržanom Návrhu riešenia

kontrolovaného nenastalo.

Následne kontrolovaný argumentuje k jednotlivým odkazom navrhovateľa na jeho Návrh riešenia uvedených v námietkach v bode 15 tohto rozhodnutia: • Návrh riešenia, kapitola
(str. 5) - citovaná textácia v námietke navrhovateľa je

kontrolovaného iba doslovným prepisom požiadavky z OPZ str. 5 Všeobecné vymedzenie predmetu zákazky. • Návrh riešenia, kapitola 2. (str. 6) - citovaná textácia je

kontrolovaného mierne upraveným prepisom požiadavky kontrolovaného zo str. 28 OPZ Realizácia a uplatnenie výstupov riešenia a neponúka žiadne doplňujúce informácie oproti zmienenej požiadavke kontrolovaného. • Návrh riešenia, kapitola 2. (str. 7) „V rámci dodávky projektu“ - citovaná textácia v námietke navrhovateľa je

kontrolovaného prepisom požiadavky kontrolovaného zo str. 10 OPZ Zoznam požadovaných produktov. • Návrh riešenia, kapitola

Migrácia dát a bod 5.
Požiadavky na súčinnosť pri migrácii údajov (str. 60 a 61) k tomuto kontrolovaný uvádza, že obsah bodu 5.1 Návrhu riešenia navrhovateľa obsahuje požiadavky na súčinnosť pri migrácii údajov a nie je pravdivé tvrdenie navrhovateľa, že detailne popisuje proces a jednotlivé kroky migrácie dát.

kontrolovaného uvedené neponúka žiadne doplňujúce informácie ohľadom popisu, ako bude migrácia dát riešená. 56. K tvrdeniu navrhovateľa v námietkach uvedenom v bode 16 tohto rozhodnutia kontrolovaný konštatuje, že zotrváva na tom, že cit.: ,,v SP v bode 16.1.11

c)jasne požadoval Návrh riešenia, ktorý má vychádzať z OPZ a Prílohy 07 P1 Katalóg požiadaviek, pričom vyžadoval jasné popísanie migrácie dát a v Návrhu riešenia navrhovaného identifikoval, že citovaný „export a import testovacích úloh“ priamo neuvažuje zaviazanosť k štandardu QTI v žiadnej kapitole Návrhu riešenia. Z pohľadu kontrolovaného ide o neakceptovateľnú úroveň spracovania časti Popis migrácie dát.“ K dôvodu vylúčenia pod písm. B2) 57. Kontrolovaný poukazuje na identifikované skutočnosti z Oznámenia o vylúčení rovnako ako ich odcitoval navrhovateľ v námietkach (viď bod 17 tohto rozhodnutia) a zároveň vo vyjadrení naviac uvádza, cit.: ,,V Návrhu riešenia bol popísaný prístup k Bezpečnostnej architektúre nedostatočne. V navrhovateľom predloženom Návrhu riešenia chýba štandard na postup pri vývoji riešenia a štandard na verifikovanie zvoleného postupu. Navrhovateľ neuviedol záväzok k štandardu OWASP Application security verification standard (ASVS). Z Návrhu nie je zrejmý, mimo bezpečnostného testovania na konci, príklon k bezpečnému vývoju v zmysle pravidiel štandardu. Ďalej v uvedenom bode ohľadom OTP 2FA sa uchádzač zaväzuje ku slabšej podmienke ako je vyžadovaná v podobe U2F, FIDO tokenov alebo ekvivalentu.“ 58. Následne kontrolovaný argumentuje k jednotlivým odkazom navrhovateľa na jeho Návrh riešenia uvedených v námietkach v bode 19 tohto rozhodnutia: Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 18 • • • Návrh riešenia, bod 7.7. Testovanie kybernetickej bezpečnosti (str. 68 a 69) - k tomuto kontrolovaný uvádza, že jedna všeobecná formulácia v rámci bodu 7.7., ako ju navrhovateľ vo svojej námietke cituje, nenahrádza v zmysle Súťažných podkladov bod 16.1.11
c)Návrh riešenia, vychádzajúci z Opisu predmetu zákazky a z Katalógu požiadaviek. Podriadenie metodiky vývoja štandardu OWASP Application Security Verification Standard (ASVS), bolo

kontrolovaného jasne uvedené ako požiadavka (v Prílohe 07 P1 Katalóg požiadaviek ako č. 52, č. 64 a 65), pričom navrhovateľ v navrhnutom riešení uviedol iba štandard, resp. riešenie pre následné testovanie (OWASP WSTG), čo požiadavku na bezpečný vývoj

OWASP ASVS

kontrolovaného nezahŕňa. Návrh riešenia - str. 9 a str. 57 - k tomuto kontrolovaný uvádza, že v Prílohe 07 P1 Katalóg požiadaviek (požiadavka č. 76) jasne žiadal podporovanie pre U2F a FIDO tokeny alebo ekvivalentné, čo citovaná autentifikácia v zmysle OTP 2FA spĺňa nedostatočne. Prihlasovanie pomocou federácie identít je samostatná požiadavka a nezahŕňa umožnenie prihlasovania pomocou U2F, FIDO tokenov alebo ekvivalentu. Návrh riešenia, bod 2.1.7. Realizácia testovania pre zdravotne znevýhodnených žiakov (str. 17) - k tomuto kontrolovaný uvádza, že Metodické usmernenie MIRRI č. 010777/2021/oSKŠITVS-1 zo dňa 21.05.2021 k monitorovaniu prístupnosti webových sídel a mobilných aplikácií, ktoré má nezáväzný charakter, pojednáva predovšetkým o metodike testovania zhody, cit.: „Toto metodické usmernenie zároveň nastavuje praktickú aplikáciu vyhodnocovania prístupnosti

Web Content Accessibillity Guidelines (ďalej len „WCAG“) vo verzii 2.1 nezávisle od legislatívnych požiadaviek a je preto použiteľná ľubovoľne pre akékoľvek webové sídlo, vrátane webových sídel súkromných subjektov, a mobilnú aplikáciu, pričom postačuje preskočiť znenie, ktoré opisuje väzby k legislatíve.“

kontrolovaného gestor metodického usmernenia v ňom prakticky popisuje ako hodnotiť prístupnosť webových sídiel a mobilných aplikácií, a nie akým spôsobom majú byť jednotlivé požiadavky definované a zapracované. Kontrolovaný má zato, že jeho požiadavka na splnenie predmetu zákazky bola stanovená tak, aby zaistil, či uchádzač má svoje riešenie pripravené na tento špecifický prípad testovania zdravotne znevýhodnených žiakov v rámci uvedenej normy WCGA 2.1

bodu 16.1.11

c)SP „Popis funkcionality realizácie testovania pre znevýhodnených žiakov“, a nie to, čo navrhovateľ vo svojom Návrhu riešenia popisuje, ako bude posudzovaná miera prístupnosti diela v zmysle uvedenej vyhlášky. 59. V kontexte vyššie uvedeného kontrolovaný konštatuje, že zotrváva na tom, že cit.: ,,navrhovateľ vo svojej ponuke nepredložil Návrh riešenia - Návrh riešenia, vychádzajúci z Opisu predmetu zákazky a z Katalógu požiadaviek, ktorý by bol plne v súlade s požiadavkou kontrolovaného.“ K dôvodu vylúčenia pod písm. C1) 60. Kontrolovaný taktiež poukazuje na identifikované skutočnosti z Oznámenia o vylúčení rovnako ako ich odcitoval navrhovateľ v námietkach (viď bod 21 tohto rozhodnutia). 61. K tvrdeniam navrhovateľa uvedených v bodoch 22 až 24 tohto rozhodnutia kontrolovaný uvádza, že zotrváva na tom, že cit.: ,,dodať nákres Aplikačnej architektúry bez uvedenia väzieb považuje za nesplnenie požiadavky na Návrh riešenia. Argument, že väzby sú uvedené v Biznis architektúre a Technologickej architektúre je nedostatočný. Rovnako trvá Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 19 na tom, že nákres Biznis architektúry alebo Technologickej architektúry nemôže nahradiť nákres samotnej Aplikačnej architektúry.“ K dôvodu vylúčenia pod písm. C2) 62. Kontrolovaný taktiež poukazuje na identifikované skutočnosti z Oznámenia o vylúčení rovnako ako ich odcitoval navrhovateľ v námietkach (viď bod 26 tohto rozhodnutia). 63. K tvrdeniam navrhovateľa uvedených v bode 27 tohto rozhodnutia kontrolovaný poukazuje na bod 16.1.11
e)SP, kde je presne vymedzená požiadavka na popis a nacenenie licencií tretích strán nasledovne, cit.: „Cenu za licencie tretích strán, ich maintenance a support a za cloud služby musia byť súčasťou ponuky vyplnené do súboru, ktorý ma dva pracovné hárky Zoznam licencií a cloud služieb.xlsx (príloha 2 Opisu predmetu zákazky). Kumulatívna cena za cloud služby a licencie bude uvedená v kalkulácii ceny v položke 1.3 a 1.4. Prílohy č. 9 týchto súťažných podkladov Kalkulácia ceny.“ Kontrolovaný konštatuje, že cit.: ,,navrhovateľ v uvedených prípadoch tieto produkty tretích strán v určenom súbore neuviedol, nestanovil ich cenu a tým jasne nedeklaroval ich cenu v rámci finálneho diela. S cieľom hospodárneho nakladania zverených prostriedkov si kontrolovaný uvedomuje, že cenová kalkulácia takto komplexného diela je kritická pre prevádzku a časovú udržateľnosť, preto aj nulová hodnota licencie pri open-sourcových produktoch definuje finálnu podobu ceny. Niektoré z uvedených produktov tretích strán môžu mať pri nulovej cene licencie ďalšie poplatky späté napríklad s počtom užívateľov alebo s objemom prenesených dát, čo vzhľadom na absenciu ich vymenovania v uvedenej prílohe, chýba. Preto kapitoly 3.4.2. a 3.4.3 v ponuke navrhovateľa nemôžu byť zdrojom požadovaných informácií o štruktúre a cene licencií tretích strán.“ 64. V kontexte vyššie uvedeného kontrolovaný konštatuje, že zotrváva na tom, že cit.: ,,navrhovateľ vo svojej ponuke nepredložil Architektonický návrh, ktorý by bol plne v súlade s požiadavkou kontrolovaného.“ K dôvodu vylúčenia pod písm. D) 65. Kontrolovaný uvádza, že v rámci OPZ str. 11 jasne a jednoznačne deklaroval, čo má DNR obsahovať. Kontrolovaný konštatuje, že navrhovateľ v Návrhu riešenia, v kapitole 10 uviedol štruktúru DNR, v ktorej nie sú jednoznačne a nespochybniteľne identifikovateľné časti (kapitoly/podkapitoly) popisujúce/týkajúce sa nasledujúcich položiek uvedené v OPZ na str. 11: Testovacie scenáre - akceptačné, bezpečnostné záťažové a UX, Podrobný popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov, Podrobný popis funkcionality dynamického testovania, Presná špecifikácia úloh pre certifikované merania. 66. K tvrdeniu navrhovateľa, cit.: ,,V tejto súvislosti navrhovateľ uvádza, že to, že návrh štruktúry DNR neobsahuje názvy kapitol, resp. podkapitol s uvedenými témami, neznamená, že uvedené témy nebudú riešené v rámci podkapitol, popisu komponentov, prípadov použitia a pod. jednotlivých kapitol DNR.“ kontrolovaný namieta, že nie je jeho povinnosťou dedukovať a predvídať, v ktorých častiach DNR plánoval navrhovateľ predmetné témy (požiadavky) riešiť.

kontrolovaného navrhovateľovi nič nebránilo, aby vo svojej ponuke vypracoval štruktúru DNR tak, aby kontrolovaný vedel všetky požadované časti jednoznačne v predloženej štruktúre DNR identifikovať. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 20

Na základe vyššie uvedeného kontrolovaný konštatuje, že zotrváva na tom, že cit.: ,,navrhovateľ vo svojej ponuke nepredložil Štruktúru detailného návrhu riešenia, ktorá by bola plne v súlade s požiadavkou kontrolovaného.“
Záverom vyjadrenia kontrolovaný konštatuje, že na základe všetkých vyššie uvedených jednoznačných a nespochybniteľných dôkazov, považuje námietku navrhovateľa za absolútne neopodstatnenú, v ktorej navrhovateľ uvádza najmä všeobecné argumentácie v snahe spochybniť tú skutočnosť, že jeho ponuka neobsahovala požadované informácie a teda nespĺňala vo svojej celistvosti požiadavky na predmet zákazky, čo kontrolovaný jednoznačne a nespochybniteľne preukázal. Kontrolovaný je presvedčený o správnosti svojho konania, t. j. vylúčení ponuky navrhovateľa. Právny rámec 69.

§ 10ods.

1 zákona o verejnom obstarávaní sú verejný obstarávateľ a obstarávateľ povinní pri zadávaní zákaziek, koncesií a pri súťaži návrhov postupovať

tohto zákona. 70.

§ 10ods.

2 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ musia dodržať princíp rovnakého zaobchádzania, princíp nediskriminácie hospodárskych subjektov, princíp transparentnosti, princíp proporcionality a princíp hospodárnosti a efektívnosti. 71.

§ 24ods.

1 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ sú povinní zdokumentovať celý priebeh verejného obstarávania s dôrazom na preskúmateľnosť rozhodnutí prijatých vo všetkých fázach verejného obstarávania, bez ohľadu na použité prostriedky komunikácie. Na tento účel evidujú kompletnú dokumentáciu, ktorú uchovávajú desať rokov odo dňa odoslania oznámenia o výsledku verejného obstarávania, ak osobitný predpis neustanovuje inak; rovnopis zmluvy, rámcovej dohody alebo koncesnej zmluvy uchovávajú počas celej doby jej trvania. Ak trvanie zmluvy, rámcovej dohody alebo koncesnej zmluvy presiahne desať rokov odo dňa odoslania oznámenia o výsledku verejného obstarávania, verejný obstarávateľ a obstarávateľ uchovávajú kompletnú dokumentáciu do uplynutia troch rokov odo dňa skončenia alebo zániku zmluvy, koncesnej zmluvy alebo rámcovej dohody. Dokumentáciu vyhotovovanú v jednotlivých fázach verejného obstarávania, ktorá nie je súčasťou elektronickej komunikácie

§ 20

, verejný obstarávateľ a obstarávateľ môžu viesť aj prostredníctvom elektronického prostriedku, ktorého prostredníctvom sa komunikácia a výmena informácií vo verejnom obstarávaní uskutočňuje. 72.

§ 53ods.

1 zákona o verejnom obstarávaní vyhodnocovanie ponúk komisiou je neverejné. Komisia vyhodnotí ponuky z hľadiska splnenia požiadaviek verejného obstarávateľa alebo obstarávateľa na predmet zákazky alebo koncesie a v prípade pochybností overí správnosť informácií a dôkazov, ktoré poskytli uchádzači; ak ide o zákazku v oblasti obrany a bezpečnosti, komisia vyhodnotí ponuky aj z hľadiska požiadaviek na bezpečnosť a ochranu utajovaných skutočností a bezpečnosť dodávok. Ak verejný obstarávateľ alebo obstarávateľ vyžadoval od uchádzačov zábezpeku, komisia posúdi zloženie zábezpeky. Ak komisia identifikuje nezrovnalosti alebo nejasnosti v informáciách alebo dôkazoch, ktoré uchádzač poskytol, písomne požiada o vysvetlenie Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 21 ponuky a ak je to potrebné aj o predloženie dôkazov. Vysvetlením ponuky nemôže dôjsť k jej zmene. Za zmenu ponuky sa nepovažuje odstránenie zrejmých chýb v písaní a počítaní. 73.

§ 53ods.

5 písm. b) zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ vylúčia ponuku, ak ponuka nespĺňa požiadavky na predmet zákazky alebo koncesie uvedené v dokumentoch potrebných na vypracovanie ponuky. 74.

§ 53ods.

8 zákona o verejnom obstarávaní komisia vyhodnocuje ponuky, ktoré neboli vylúčené,

kritérií určených v oznámení o vyhlásení verejného obstarávania, v oznámení o koncesii, v oznámení použitom ako výzva na súťaž alebo v súťažných podkladoch, ktoré sú nediskriminačné a podporujú hospodársku súťaž. 75.

§ 175ods.

3 zákona o verejnom obstarávaní ak úrad v konaní o preskúmanie úkonov kontrolovaného na základe námietok nezistí porušenie tohto zákona, na ktoré poukazuje navrhovateľ v podaných námietkach a ktoré by mohlo ovplyvniť výsledok verejného obstarávania, námietky zamietne. Právne posúdenie námietok navrhovateľa úradom Úrad preskúmal postup kontrolovaného v predmetnej verejnej súťaži v rozsahu namietaných skutočností a po zhodnotení všetkých relevantných podkladov, najmä dokumentácie predloženej kontrolovaným, vyjadrenia kontrolovaného k podaným námietkam navrhovateľa a navrhovateľom namietaných skutočností v námietkach, ako aj odborného stanoviska, konštatuje nasledovné:

Úvodom právneho posúdenia úrad uvádza, že v závislosti od predmetu zákazky, typu kontrolovaného a predpokladanej hodnoty zákazky vo výške 10 741 032,19 EUR bez DPH ide o nadlimitnú zákazku na poskytnutie služieb, ktorá má byť financovaná z fondov Európskej únie (č. projektu alebo refer. č.: Plán obnovy a odolnosti SR). Kontrolovaný zverejnil súťažné podklady k predmetnej zákazke priamo a bez obmedzení vo svojom profile na stránke úradu 7 a taktiež v IS EPVO, ktorý si v zmysle § 20 zákona o verejnom obstarávaní stanovil na komunikáciu s uchádzačmi, resp. záujemcami. V lehote na predkladanie ponúk, t. j.
2024 do 15:00 hod. 8 predložili svoje ponuky traja uchádzači, vrátane navrhovateľa. Otváranie ponúk sa uskutočnilo dňa
2024 o 10:00 hod. ako on-line sprístupnenie ponúk v IS EPVO. Za kritérium na vyhodnotenie ponúk si kontrolovaný stanovil najnižšiu cenu. Kontrolovaný v procese vyhodnocovania postupoval

§ 66ods.

7 písm.

b)zákona o verejnom obstarávaní, tzv. super reverzným spôsobom. V kontexte uvedeného zo Zápisnice z vyhodnotenia ponúk z hľadiska splnenia požiadaviek na predmet zákazky č. 1 zo dňa 15. 02. 2024 (ďalej len ,,Zápisnica z vyhodnotenia“) vyplýva, že ponuka navrhovateľa bola najnižšia a následne kontrolovaný vyhodnocoval splnenie požiadaviek na predmet zákazky len u navrhovateľa. Dňa 15. 02. 2024 kontrolovaný prostredníctvom IS EPVO doručil navrhovateľovi list označený ako ,,Oznámenie o vylúčení ponuky“ (ďalej len ,,Oznámenie Verejne dostupné na stránke úradu link: https://www.uvo.gov.sk/vyhladavanie/vyhladavaniezakaziek/dokumenty/482668?cHash=512dc653b176895ac418654b7f9095ee 8 V znení Opravy Oznámenia o vyhlásení verejného obstarávania zverejnenej vo VVO č. 24/2024 zo dňa 02. 02. 2024 pod značkou 3304-IOX. 7 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 22 o vylúčení“). Následne navrhovateľ dňa 23. 02. 2024 doručil úradu a kontrolovanému predmetné námietky. 77. Z obsahu podaných námietok vyplýva, že navrhovateľ namieta vylúčenie ponuky z dôvodu nesplnenia požiadaviek na predmet zákazky. Navrhovateľ považuje Oznámenie o vylúčení za neproporčné a predčasné, vychádzajúce z nedostatočne zisteného skutkového stavu a nesprávneho právneho posúdenia, keď kontrolovaný nepožiadal navrhovateľa o vysvetlenie ponuky. Navrhovateľ v námietkach argumentuje, že v návrhu riešenia nekopíroval jednotlivé textácie z katalógu požiadaviek tvoriace opis predmetu zákazky, ktoré považoval za kontrolovaným stanovený štandard kladený na technické riešenie ponuky ale práve naopak, že sa zameral na procesné rozpracovanie ním ponúkaného riešenia. Zároveň navrhovateľ namieta jednotlivé kontrolovaným identifikované skutočnosti uvedené v Oznámení o vylúčení. Naopak kontrolovaný vo vyjadrení k námietkam konštatuje, že pri vyhodnocovaní ponuky navrhovateľa postupoval v súlade so zákonom o verejnom obstarávaní. Zároveň kontrolovaný vo vyjadrení poukazuje na interpretačnú nezrovnalosť navrhovateľa v námietkach, keď navrhovateľ uvádza, že cit.: ,,v nadväznosti na ,,Oznámenie o vylúčení uchádzača“ zo dňa 15. 02.2024“. 9 78. V zmysle uvedeného bolo v danom prípade úlohou úradu posúdiť, či postup kontrolovaného, ktorý predchádzal vylúčeniu ponuky navrhovateľa z predmetnej verejnej súťaže bol uskutočnený v súlade so zákonom o verejnom obstarávaní a teda, či dôvod, na ktorom kontrolovaný založil vylúčenie ponuky navrhovateľa bol zákonný a opodstatnený. 79. Ako vyplýva z Oznámenia o vylúčení kontrolovaný založil dôvod vylúčenia ponuky navrhovateľa na ust. § 53 ods. 5 písm.
b)zákona o verejnom obstarávaní. Kontrolovaný v Oznámení o vylúčení konkretizoval pod písm. A, B1, B2, C1, C2 a D skutočnosti, na základe ktorých dospel k záveru, že ponuka navrhovateľa nespĺňa kontrolovaným stanovené požiadavky na predmet zákazky uvedené v súťažných podkladoch. 80. V súvislosti s kontrolovaným uplatneným vylučovacím dôvodom

§ 53ods.

5 písm.

b)zákona o verejnom obstarávaní spočívajúcim v skutočnosti, že ponuka navrhovateľa nespĺňa požiadavky na predmet zákazky uvedené v dokumentoch potrebných na vypracovanie ponuky, považuje úrad za potrebné najskôr poukázať na súťažné podklady a s nimi súvisiace dokumenty. Úrad vo všeobecnosti podotýka, že súťažné podklady predstavujú najkomplexnejší dokument verejného obstarávania, ktorý má obsahovať dostatok informácií o predmete zákazky na to, aby záujemcovia mohli vypracovať svoje ponuky v súlade s požiadavkami verejného obstarávateľa/obstarávateľa, ktorí disponujú dostatkom informácií o predmete zákazky a poznajú svoje potreby. 81. Z predloženej dokumentácie je zrejmé, že kontrolovaný v bode 16.1.11 Dokumenty ponuky požadované na splnenie požiadaviek na predmet zákazky v písm.
a)až
l)Pozn. úradu: K uvedenému úrad konštatuje, že sa stotožňuje s tvrdením kontrolovaného a ide zrejme o argumentačnú chybu navrhovateľa. Z Oznámenia o vylúčení, resp. v ňom uvedenom dôvode vylúčenia

§ 53ods.

5 písm. b) zákona o verejnom obstarávaní je zrejmé, že uvedený vylučovací dôvod sa týka ponuky. Ak by malo ísť o vylúčenie navrhovateľa ako uchádzača, muselo by ísť o niektorý z vylučovacích dôvodov

§ 40ods.

6 alebo 8 zákona o verejnom obstarávaní. 9 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 23 zadefinoval jednotlivé dokumenty, ktoré požadoval na splnenie požiadaviek na predmet zákazky nasledovne, cit.: ,,

a)Detailný harmonogram – Detailný harmonogram dodávky diela vychádzajúci z harmonogramu uvedeného v Opise predmetu zákazky (Tabuľka 1, strp. 5-6). (...)
b)Klientské testovacie zariadenie – Požaduje sa určitá úroveň zabezpečenia klientskych testovacích zariadení počas certifikačných testovaní, preto súčasťou ponuky uchádzača bude: • Návrh technológie na zabezpečenie klientskej testovacej stanice (...)
c)Návrh riešenia – Návrh riešenia, vychádzajúci z Opisu predmetu zákazky a z Katalógu požiadaviek v rozsahu: (...)
d)Architektonický návrh – Architektonický návrh, ktorý bude pozostávať z: (...)
e)Backend infraštruktúra a architektúra (Technologická architektúra riešenia) – Súčasťou ponuky musí byť: (...)
f)Reporty a Štatistiky – Súčasťou ponuky musí byť: (...)
g)Archivácia – Súčasťou ponuky budú aj archivačné pravidlá, ktoré deklarujú ako bude zabezpečená: (...)
h)Migrácia údajov z pôvodného informačného systému eTest – Súčasťou ponuky bude: (...)
i)Integrácia na externé služby – (...)
j)Prevádzková podpora informačného systému a rozvoj - (...)
k)Spôsob riadenia implementácie a projektový manažment – (...)
l)Štruktúra detailného návrhu riešenia (DNR) –návrh štruktúry (v členení na kapitoly, t.j. názvy kapitol) Detailného návrhu riešenia, ktorý bude plne v súlade s dokumentami, ktoré tvoria obsah ponuky a sú vymenované a špecifikované vyššie v písm.
a)– k).“ 10 Zároveň kontrolovaný bližšie špecifikoval predmet zákazky v prílohe č. 7 Opis predmetu zákazky (obsahujúca detailnejší popis predmetu zákazky) a prílohe č. 7 P1 Katalóg požiadaviek (obsahujúca 137 požiadaviek). 82. Nakoľko právne posúdenie navrhovateľových námietok presahuje do nevyhnutnosti technického skúmania navrhovateľovej ponuky v kontexte stanovených požiadaviek na predmet zákazky kontrolovaným, úrad si nechal vypracovať odborné stanovisko znalcom z odboru elektrotechniky, resp. odvetvia počítačové programy (software). 11 83. V úvodnej časti odborného stanoviska znalec identifikoval svoju úlohu (zodpovedanie otázok položených úradom), účel znaleckého úkonu a zosumarizoval aj podklady, z ktorých v priebehu svojej znaleckej činnosti vychádzal. V časti „II. Odborné stanovisko“ sa znalec vyjadril k jednotlivým namietaným skutočnostiam (pod písm. A, B1, B2, C1, C2 a D) 12, poukázal na súťažné podklady aj na Návrh riešenia navrhovateľa a v kontexte svojich postrehov odpovedal na otázky úradu. V záverečnej III. časti odborného stanoviska znalec zosumarizoval odpovede na úradom položené otázky. Súťažné podklady verejne dostupné v profile kontrolovaného na stránke úradu, link: https://www.uvo.gov.sk/vyhladavanie/vyhladavaniedokumentov/detail/3337275?cHash=e0534982b7e7b305d30e41a766230568 11 K uvedenému pozri aj bod 42 tohto rozhodnutia 12 Pozn. úradu: namietané skutočnosti navrhovateľa vychádzajúc z Oznámenia o vylúčení, kde kontrolovaný skutočnosti na základe ktorých vylúčil ponuku navrhovateľa rozdelil pod písm. A, B1, B2, C1, C2 a D. 10 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 24 84. Úrad následne rozoberie jednotlivé namietané skutočnosti (pod. písm. A, B1, B2, C1, C2 a D) v kontexte námietok navrhovateľa, vyjadrenia kontrolovaného a v kontexte záverov odborného stanoviska. Ad) A – k dôvodu vylúčenia súvisiaceho s požiadavkou kontrolovaného v bode 16.1.11 písm.
b)SP 85. Z bodu 16.1.11 písm.
b)SP (odcitované navrhovateľom v námietkach viď bod 9 tohto rozhodnutia) vyplýva, že kontrolovaný požaduje určitú úroveň zabezpečenia klientskych testovacích zariadení počas certifikačných testovaní, a preto súčasťou ponuky navrhovateľa mal byť, cit.: ,,Návrh technológie na zabezpečenie klientskej testovacej stanice tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, prípadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice, ktorý bude popisovať, akým spôsobom budú problémy s podvádzaním žiakov účinne eliminované na centrálnej úrovni a na úrovni školy.“ 86. K uvedenej požiadavke znalec v odbornom stanovisku uvádza nasledovné, cit.: ,,Zabezpečenie klientskych staníc Informačný systém eTest je navrhovaný ako centrálny informačný systém, určený okrem iného i na realizáciu celoplošného testovania žiakov v jednotnom čase. Výsledky napr. testovania deviatakov2 sú využívané strednými školami v prijímacom konaní, takže môžu mať zásadný dopad na životy jednotlivcov. Z tohto dôvodu je nanajvýš dôležité, aby namerané výsledky boli objektívne a nespochybniteľné - pre samotnú realizáciu testu sa pritom jedná najmä o zamedzenie "odpisovania", resp. používania nepovolených nástrojov aktérmi testov, a odolnosť systému voči krátkodobým výpadkom internetu. Obstarávateľ sa tejto téme (t.j. zabezpečeniu klientskych staníc) v [OPZ] venuje v kapitole "Požiadavky na priebeh testovaní a ich bezpečnosť", resp. jej podkapitolách, kde sa okrem iného doslova píše, citujem: Certifikačné testy sa majú vykonávať na zabezpečenej pracovnej stanici s kontrolovaným prístupom k systémovým funkciám (...), ktorá neumožňuje používanie neoprávnených zdrojov (napr. internetových stránok, okien/aplikácií, súborov atď), počas realizácie testu. Pracovná stanica má byť zabezpečená systémovo, nie manuálne administrátorom školy na každej pracovnej stanici. (...) Od informačného systému sa požaduje bezpečné testovanie cez počítačovú sieť, ktoré nebude možné odchytiť a prípadne modifikovať. Informačný systém musí byť odolný voči krátkodobým výpadkom pripojenia k počítačovej sieti. (...) Ukladanie odpovedí počas testovania musí byť zabezpečené tak, že bude 100% istota, že výsledky všetkých spustených testov budú v prípade certifikačných testovaní k dispozícií v centrálnom informačnom systéme na vyhodnotenie. (...) (...) Dôležitou požiadavkou je: vyriešenie autentifikácie žiaka, obmedzenie možností žiaka podvádzať, zabezpečiť že žiak pracuje samostatne a nepoužíva nepovalené aplikácie alebo nepracuje s inými zdrojmi informácií. (koniec citátu) Explicitne je v tejto kapitole uvedená aj požiadavka na vysvetlenie prístupu potenciálne uchádzača k týmto bezpečnostným aspektom, citujem: V ponuke bude vysvetlené, akým Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 25 spôsobom budú tieto problémy adresované tak, aby ich bolo možné účinne eliminovať na centrálnej úrovni a na úrovni školy (koniec citátu). Navrhovateľ téme zabezpečenia klientskych zariadení vo svojej ponuke ([NávrhRiešenia]) venoval kapitolu "2.1.6. Klientske testovacie zariadenie a aplikácia Testovací klient". Lenže vôbec nepopisuje spôsob, akým plánuje túto požiadavku zabezpečiť (napr. Windows Assigned Access3, čo je spôsob využívaný napr. pre bankomaty) – iba 1. opakuje formulácie (požiadavky) z [OPZ] 2. odvoláva sa na došpecifikovanie témy v DNR.“ 87.

názoru znalca bolo cit.: ,,nevyhnutné (a v súťažných podkladoch aj požadované) už v návrhu riešenia sa zamyslieť, akým spôsobom skutočne dané požiadavky adresovať, zvlášť v prípade, kedy hovoríme o školských počítačoch, ktoré nepodliehajú centrálnej správe, a nedá sa teda uvažovať s nejakou centralizovane nastavenou politikou pomocou napr. prostriedkov Windows domény. Obstarávateľ na tento aspekt nezabudol poukázať v dedikovanej požiadavke Bring Your Own Device - BYID (viď [KP], požiadavka 133), ktorý v skratke hovorí o tom, že v systéme musí byť možné pracovať na zariadeniach, ktoré nespravuje správca systému eTest, a teda ich zabezpečenie je nutné riešiť iným spôsobom (napr. aplikačne; návodom pre správcov školských počítačov, ako pripraviť klientske stanice na testovanie (spolu s mechanizmom overenia korektného nastavenia); prostriedkom tretej strany, atď.).“ 88. V súvislosti so závermi kontrolovaného uvedenými v Oznámení o vylúčení k nesplneniu predmetnej požiadavky (odcitované navrhovateľom v bode 10 tohto rozhodnutia) úrad položil znalcovi nasledovnú otázku č. 1, cit.: ,,Je

Vášho odborného názoru pravdivé tvrdenie kontrolovaného, že v ponuke navrhovateľa, konkrétne v Návrhu riešenia, navrhovateľ nepredložil Návrh technológie na zabezpečenie klientskej testovacej stanice, tak, aby nebolo možné spúšťať externé programy mimo samotného testovania, pripadne robiť obrazový alebo iný záznam z priebehu testovania priamo v prostredí klientskej testovacej stanice, ktorý bude popisovať, akým spôsobom budú problémy s podvádzaním žiakov účinne eliminované na centrálnej úrovni a na úrovni školy? Vašu odpoveď prosíme zdôvodnite.“ Znalcova odpoveď bola jednoznačná, cit.: ,,ÁNO, Kontrolovaný pravdivo konštatuje, že ponuka Navrhovateľa v [NávrhRiešenia] neobsahuje popis zabezpečenia klientskej testovacej stanice. [NávrhRiešenia] vo svojej kapitole 2.1.6 v zásade len opakuje zadanie z [OPZ] s dovetkom, že bližšie bude téma rozpracovaná v DNR. Kontrolovaný teda nedokáže z [NávrhRiešenia] zistiť, akým spôsobom Navrhovateľ túto požiadavku plánuje naplniť, a nemá teda istotu, že Navrhovateľ správne posúdil a odhadol požiadavky, a naozaj ponúka dodať riešenie v zmysle súťažných podkladov.“ 89. V prípade, že by znalec nepotvrdil pravdivosť tvrdenia kontrolovaného, úrad položil znalcovi otázku č. 2, ktorou si chcel overiť tvrdenia navrhovateľa v námietkach (viď bod 11 tohto rozhodnutia), cit.: ,,V prípade, že

Vášho odborného názoru tvrdenie kontrolovaného nie je pravdivé, je pravdivé tvrdenie navrhovateľa v námietkach, že sa k spôsobu a k technológii zabezpečenia pracovnej stanice vyjadril na viacerých miestach svojho Návrhu riešenia a to konkrétne v bodoch, na ktoré v námietkach poukazuje? Vašu odpoveď prosíme zdôvodnite.“ Znalec na úradom položenú otázku odpovedal nasledovne, cit.: ,,Tvrdenie Kontrolovaného považujem za jednoznačne PRAVDIVÉ. Navrhovateľ vo svojej námietke argumentuje všeobecnými frázami a opakovaním textácie požiadaviek z [OPZ], ktoré naozaj sú uvedené v [NávrhRiešenia], pričom ale nikde nevysvetľuje, ako Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 26 je jeho riešenie skutočne postavené. V zásade sa ním predložený návrh riešenia dá zjednodušiť do jednoduchého konštatovania "Dodáme všetko, čo požadujete", čo rozhodne nepredstavuje popis a vysvetlenie spôsobu riešenia zákazníckych požiadaviek tak, aby Obstarávateľ dokázal pochopiť, čo je vlastne predmetom ponuky.“

Úrad sa taktiež opýtal na odborný názor znalca k tvrdeniu navrhovateľa v námietkach, cit.: ,,že podrobnejšie technické detaily k Návrhu technológie na zabezpečenie klientskej testovacej stanice je možné spracovať až v rámci plnenia predmetu zákazky, a že budú predmetom spracovania v rámci DNR“
Znalec vo svojej odpovedi úvodom popísal problematiku DNR a v kontexte toho skonštatoval, že nesúhlasí s tvrdením navrhovateľa, cit.: ,,(...) Nesúhlasím s tvrdením, že akékoľvek ďalšie podrobnejšie informácie sú predmetom DNR. Som presvedčený o tom, že ak by Navrhovateľ túto tému poznal a/alebo sa nad ňou zamyslel, dokáže aspoň rámcovo v ponuke načrtnúť, akým spôsobom by požiadavku realizoval. Takto nie je jasné, na základe čoho Navrhovateľ stanovil náklady na implementáciu požiadaviek a hrozí riziko, že nedodá to, čo Obstarávateľ požaduje, resp. bude požadovať navýšenie ceny v zmenovom konaní.“14 Ad) B – k dôvodu vylúčenia súvisiaceho s požiadavkou kontrolovaného v bode 16.1.11 písm. c) SP - B1 – popis migrácie dát
Z bodu 16.1.11 písm. c) SP (odcitované navrhovateľom v námietkach viď bod 13 tohto rozhodnutia) vyplýva, že kontrolovaný požaduje popis migrácie dát v Návrhu riešenia, vychádzajúci z Opisu predmetu zákazky a z Katalógu požiadaviek. Pozn. úradu: presné znenie otázky č. 3, cit.: ,,Je

Vášho odborného názoru pravdivé tvrdenie navrhovateľa, že podrobnejšie technické detaily k Návrhu technológie na zabezpečenie klientskej testovacej stanice je možné spracovať až v rámci plnenia predmetu zákazky, a že budú predmetom spracovania v rámci DNR? Vašu odpoveď prosíme zdôvodnite.“ 14 Pozn. úradu: celé znenie odpovede znalca na otázku č. 3, cit.: ,,DNR, ako už z názvu vyplýva, je detailný návrh riešenia. Je to dokument, ktorý slúži na detailné našpecifikovanie systému tak, aby obe strany - zákazník aj dodávateľ chápali, čo je predmetom dodávky, obsahuje podrobne rozanalyzované funkčné aj nefunkčné požiadavky, v zásade je to dokument, kde by mal byť vysvetlený každý aspekt budúceho informačného systému. Keďže DNR spravidla vzniká až po zazmluvnení v rámci plnenia dodávky, v praxi nastávajú často situácie, kedy nastáva nesúlad medzi predstavami zákazníka a dodávateľa, nakoľko ich záujmy sú z finančného pohľadu opačné - zákazník, chce dostať čo najlepší výsledok za peniaze, ktoré za zákazku zaplatil, dodávateľ chce mať čo najmenšie náklady. Navyše, dodávky IT systémov sú zložitejšie a komplikovanejšie ako dodávky napr. materiálu alebo stavebných prác, pretože ich nie je vzhľadom na komplexitu dodávaných služieb možné dopodrobna našpecifikovať ešte pred uzatvorením zmluvy. V rámci plnenia IT zákaziek bežne hovoríme o tzv. zmenových konaniach, t.j. procesoch navýšenia ceny v prípadoch, že obe strany dospejú k dohode, že požiadavka nebola špecifikovaná v pôvodnom opise predmetu zákazky. Ak predmet dodávky / zákazku nie je možné našpecifikovať na úrovni DNR, je dôležité (najmä, ak jediným vyhodnocovaním kritériom je najnižšia cena) pochopiť, čo vlastne je ponúkané potenciálnym zhotoviteľom. Preto je pri IT zákazkách bežné, že obstarávateľ požaduje rámcový opis ponúkaného riešenia. Nie je, samozrejme, možné, aby tento opis dosahoval detailnosť DNR, avšak mali by byť z neho jasné základné princípy, hlavné technológie, architektonické celky či rámcové postupy nového riešenia, aby sa zadávateľ vedel čo najlepšie rozhodnúť a najmä zistiť, či ponuka spĺňa jeho požiadavky alebo nie (a minimalizoval potenciálne zvýšené náklady vo forme zmenových konaní). Navrhovateľ vo svojej ponuke [NávrhRiešenia] k téme zabezpečenia klientskych staníc nevysvetľuje nič. Konštatuje len, že dodrží všetky požiadavky Kontrolovaného, ktoré pre istotu zopakoval v texte ponuky. Nesúhlasím s tvrdením, že akékoľvek ďalšie podrobnejšie informácie sú predmetom DNR. Som presvedčený o tom, že ak by Navrhovateľ túto tému poznal a/alebo sa nad ňou zamyslel, dokáže aspoň rámcovo v ponuke načrtnúť, akým spôsobom by požiadavku realizoval. Takto nie je jasné, na základe čoho Navrhovateľ stanovil náklady na implementáciu požiadaviek a hrozí riziko, že nedodá to, čo Obstarávateľ požaduje, resp. bude požadovať navýšenie ceny v zmenovom konaní.“ 13 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 27 92. K uvedenej požiadavke znalec v odbornom stanovisku uvádza nasledovné, cit.: ,,Migrácia dát Migrácia dát z existujúceho systému je v [OPZ] požadovaná v kapitole "Migrácia údajov z pôvodného informačného systému eTest", kde sa uvádza rozsah migrovaných entít: • úlohy • predpisy testov • testy • história testovaní • register škôl zároveň sa uvádza v samostatnej prílohe podrobnejšia štruktúra zbieraných dát a na záver uvádza celkový objem údajov, ktoré je potrebné migrovať, 4 GB. Zo štruktúry dát (samostatná príloha Súťažných podkladov) vyplýva využitie 20 entít / tabuliek. Navrhovateľ popísal spôsob realizácie migrácie v [NávrhRiešenia], kapitola 5, pričom zopakoval predmet migrácie

[OPZ], rámcovo popísal kroky migrácie a požadovanú súčinnosť pri migrácii. Na rozdiel od napr. popisu zabezpečenia klientskych staníc, rozoberaného v predošlej kapitole tohto stanoviska, aj vzhľadom na to, že predmetom migrácie je pomerne malý rozsah údajov, čo do typu (20 entít) a množstva (4 GB dát), považujem tento popis za DOSTATOČNÝ pre naplnenie požiadaviek zo Súťažných podkladov (kapitola 16.1.11, písm. c), citujem: • Popis migrácie dát (…) • Aby obsahoval požiadavky a podklady na rozsah a prácnosť a rozsah súčinnosti pri migrácií údajov, (koniec citátu) Kontrolovaný vo vyjadrení k námietke spomína aj štandard QTI, avšak

môjho názoru tento štandard neovplyvňuje (iniciálnu) migráciu údajov ako takú, pretože nebola zadefinovaná aj požiadavka kvalitatívneho posunu týchto dát, teda napr. zvýšenia verzie QTI. V [KP] sa QTI spomína v požiadavkách na import (požiadavka 91) a export (požiadavka 110) úloh, avšak tieto požiadavky nepovažujem za migračné požiadavky, ale požiadavky na integráciu.“ 93. V súvislosti s predmetnou požiadavkou kontrolovaného úrad položil znalcovi nasledovnú otázku č. 4, cit.: ,,

Vášho odborného názoru, popísal navrhovateľ vo svojom Návrhu riešenia migráciu dát v súlade s požiadavkou kontrolovaného uvedenou v bode 16.1.11 písm. c) súťažných podkladov? Vašu odpoveď prosíme zdôvodnite.“ Znalec vyhodnotil, že navrhovateľ v Návrhu riešenia popísal riešenie migrácie dát v súlade s predmetnou požiadavkou kontrolovaného. 15 94. Úrad sa ďalej znalca pýtal, cit.: ,,

Vášho odborného názoru, vyplýva z bodu 16.1.11 písm.

c)súťažných podkladov, že súčasťou Návrhu riešenia mal byť aj detailnejší popis spôsobu migrácie dát, vrátane uvedenia štandardu QTI, alebo ekvivalentného? Vašu odpoveď prosíme zdôvodnite.“ Znalec skonštatoval, cit.: ,,NIE, z bodu 16.1.11 písm.
c)Pozn. úradu: celé znenie odpovede na otázku č. 4, cit.: ,,ÁNO, som presvedčený o tom, že Navrhovateľ v [NávrhRiešenia], kapitola 5 popísal riešenie migrácie dát V SÚLADE s požiadavkou Kontrolovaného z bodu 16.1.11 písm.
c)súťažných podkladov. Vzhľadom na pomerne malú náročnosť dátového modelu (20 entít) a objemu dát (4 GB) si myslím, že základné kroky migrácie a popísaná požadovaná súčinnosť postačujú na to, aby Kontrolovaný získal predstavu o tom, čo mu v tejto oblasti bolo ponúknuté.“ 15 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 28 súťažných podkladov rozhodne nevyplýva nutnosť detailnejšieho popisu spôsobu migrácie dát. Štandard QTI hovorí najmä o interoperabilite dátových štruktúr medzi rôznymi (testovacími) systémami, avšak tento fakt nemá dopad na migráciu údajov z pôvodného systému eTest do nového eTest II za predpokladu, že Obstarávateľ nepožadoval využitie tohto formátu na samotnú migráciu, resp. jej časť. V požiadavkách [KP] sa spomína štandard QTI iba vo forme dvoch integračných požiadaviek - import a export úloh. Som presvedčený o tom, že na základe týchto dvoch požiadaviek nemožno konštatovať, že QTI bolo požadované v rámci migrácie údajov.“ 95. V súvislosti s migráciou dát sa úrad znalca pýtal taktiež na pravdivosť tvrdenia navrhovateľa v námietkach, že detailný popis migrácie bude až predmetom plnenia v rámci vyhotovenia DNR v rámci realizačnej etapy Analýza a Návrh riešenia. 16 Znalec súhlasil s tvrdením navrhovateľa a uviedol nasledovné, cit.: ,,ÁNO, v rámci DNR býva štandardne vytvorený aj dátový model nového riešenia, prebehne základná analýza kvality dát, odhadne sa náročnosť jednotlivých krokov migrácie, atď. Ako som uviedol pri predchádzajúcich dvoch otázkach, som presvedčený o tom, že popis migrácie tak, ako ho Navrhovateľ poskytol v [NávrhRiešenia] kapitola 5, je dostatočným popisom v zmysle súťažných podkladov.“ Ad) B – k dôvodu vylúčenia súvisiaceho s požiadavkou kontrolovaného v bode 16.1.11 písm.
c)SP – B2 – Bezpečnostná architektúra 96. K uvedenej požiadavke znalec v odbornom stanovisku uvádza nasledovné, cit.: ,,(Namietané) bezpečnostné štandardy Otázke zabezpečenia venoval Obstarávateľ v [OPZ] pomerne veľký priestor. Zatiaľ, čo pri iných technologických štandardoch sa [OPZ] obmedzuje na odporúčania s dovetkom "alebo ekvivalent", namietané bezpečnostné štandardy vymenúva v [KP] veľmi konkrétne. • požiadavka 52 - súlad s požiadavkami OWASP ASVS pre úroveň L2: https://owasp.org/www-project-application-security-verification-standard/ • požiadavka 64 - Ochrana proti Injection attack: informačný systém bude poskytovať ochranu voči útokom typu injection attack pomocou validácie vstupov (detailnejšie požiadavky sú v časti 5 OWASP ASVS); • požiadavka 65 - Splnenie požiadaviek OWASP ASVS v oblasti kryptografických opatrení informačný systém plní požiadavky kapitoly 6 OWASP ASVS: o všetky kryptografické moduly a funkcie zlyhajú bezpečným spôsobom a je zabezpečený error handling, o je použitý overený generátor náhodných čísiel, o prístup k kľúčom a heslám je zabezpečený a riadený; • požiadavka 76 - Využívanie 2FA6 pre prihlásenie do systému: informačný systém bude podporovať prihlásenie pomocou 2FA, podporované budú U2F a FIDO tokeny alebo ekvivalentné. Vybrané funkcionality budú prístupné iba po autentifikáciu sa s 2FA; • požiadavka 106 - Podpora funkcionality a obmedzení pre využívanie systému žiakmi so zdravotným znevýhodnením: stránka bude spĺňať štandard prístupnosti pre úroveň WCAG 2.1AA. Pre žiakov s znevýhodnením bude k dispozícii možnosť prepnúť si kontrastný režim

príslušných štandardov. OWASP ASVS Pozn. úradu: presné znenie otázky č. 6, cit.: ,,Je pravdivé tvrdenie Navrhovateľa, že detailný popis migrácie bude až predmetom plnenia v rámci vyhotovenia DNR v rámci realizačnej etapy Analýza a návrh riešenia?“ 16 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 29 OWASP Application Security Verification Standard (https://owasp.org/www-projectapplication-security-verification-standard/) je sada návodov a odporúčaní, zameraných na tvorbu bezpečnostných aplikácií. OWASP je nezisková organizácia, ktorá tieto dokumenty poskytuje bezplatne, pričom ich pravidelne aktualizuje v súlade s aktuálnymi bezpečnostnými trendami. Aktuálna verzia 4.0.3 je z roku 2021 dostupná vo forme dokumentu na stránke https://github.com/OWASP/ASVS/tree/v4.0.3?tab=readme-ov-file#latest-stable-version--403 pričom je štruktúrovaný ako sadu bodov, ktoré je potrebné skontrolovať (tzv. kontrolný zoznam = checklist). Jednotlivé body sú zaradené do troch úrovní L1, L2 a L3, kde L1 sú predstavuje najmenej náročné požiadavky, L2 stredné a L3 najviac zabezpečenú aplikáciu. Obstarávateľ požaduje všeobecné splnenie OWASP ASVS na úrovni L2 (viď [KP], požiadavka 52), navyše sa špeciálne Obstarávateľ zmieňuje o validácii vstupov ([KP], požiadavka 64), spomínaná v bodoch 5.1.1 až 5.1.5, a troch kryptografických opatrení ([KP], požiadavka 65), spomínaných v bodoch kapitoly

Navrhovateľ túto požiadavku adresuje v [NávrhRiešenia], kapitola "7.
Testovanie kybernetickej bezpečnosti", ktorá popisuje testovanie voči štandardu OWASP Web Security Testing Guide (WSTG) a zmieňuje OWASP TopTen, citujem: Webová časť informačného systému eTest II bude otestovaná na základe požiadaviek verejného obstarávateľa s využitím metodiky OWASP, pričom hlavné zameranie bude na Top 10 zraniteľností, čo je zoznam najčastejších zraniteľností webových aplikácií, vytvorený a udržiavaný organizáciou OWASP. (koniec citátu) Nepovažujem prihlásenie sa k OWASP WSTG a OWASP TopTen za ekvivalent naplnenia požiadavky na OWASP ASVS úrovne L2: • OWASP WSTG je spôsob, akým testovať zraniteľnosti, pričom tieto zraniteľnosti sú popísané v OWASP ASVS; neexistuje však priamy vzťah medzi OWASP WSTG a OWASP ASVS, preto implementáciou OWASP WSTG nie je zaručené dodržanie všetkých pravidiel z OWASP ASVS; • OWASP TopTen je výber 10 najdôležitejších zraniteľností z OWASP ASVS, čiže prirodzene nemôže pokrývať kompletnú špecifikáciu OWASP ASVS úrovne L
(...) Štandardy prístupnosti Každý informačný systém vo verejnej správe musí spĺňať štandardy pre informačné systémy verejnej správy vrátane štandardov pre znevýhodnených používateľov definovanom v Metodickom usmernení Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky k monitorovaniu prístupnosti webových sídel a mobilných aplikácií (https://mirri.gov.sk/sekcie/informatizacia/dokumenty/standardy-isvs/pristupnostwebovych-sidel/metodika-monitorovania-webovych-sidel/) (ďalej len "Metodické usmernenie"), ktoré vychádza z medzinárodného štandardu prístupnosti WCAG 2.1 úrovne AA, ktorý je dostupný tu: https://www.w3.org/TR/WCAG21/. Obstarávateľ v súťažných podkladoch upozorňuje najmä na režim kontrastu, avšak v zmysle vyššie uvedeného musí dodávaný informačný systém spĺňať všetky relevantné požiadavky z tohto Metodického usmernenia. Navrhovateľ sa venuje tejto požiadavke v [NávrhRiešenia], kapitola "2.1.
Realizácia testovania pre zdravotne znevýhodnených žiakov", kde popisuje spôsob riešenia prístupnosti, zmieňuje množstvo príkladov a možných nástrojov. Deklaruje súlad s [OPZ] a vyššie spomínaným Metodickým usmernením, citujem: Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 30 Informačný systém bude spĺňať štandardy pre informačné systémy verejnej správy vrátane štandardov pre znevýhodnených používateľov definovanom v Metodickom usmernení Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky k monitorovaniu prístupnosti webových sídel a mobilných aplikácií. (koniec citátu) Popis Navrhovateľa neobsahuje deklaratívny súlad so štandardom WCAG 2.1 úrovne AA v zmysle požiadavky z [KP], avšak samotné Metodické usmernenie je de facto postavené na tomto štandardne, čo mimo iné uvádza aj svojom úvode, citujem: Metodické usmernenie zároveň nastavuje praktickú aplikáciu vyhodnocovania prístupnosti

Web Content Accessibility Guidelines (ďalej len „WCAG“) vo verzii 2.1 (...) (koniec citátu) preto si dovolím považovať deklarovaný súlad s WCAG zahrnutý v deklarovanom súlade s Metodickým usmernením. 2FA Dvojfaktorová autentifikácia je bezpečnostný mechanizmus, ktorý vyžaduje nielen znalosť hesla, ale aj niečo ďalšie, čím disponuje len osoba s oprávnením k prístupu. Sú kombinované dva faktory:

Niečo, čo viete: môže to byť vaše heslo, PIN alebo odpoveď na bezpečnostnú otázku;
Niečo, čo máte: tento faktor sa zvyčajne odohráva prostredníctvom fyzického objektu, ktorý len máte len vy, napr. kľúč z generátora jednorazových kódov alebo váš mobilný telefón, na ktorý je poslaná správa SMS, atď. Pre úspešné prihlásenie je nutné zadať oba faktory správne. Obstarávateľ v požiadavke explicitne uvádza štandardy U2F a FIDO tokeny alebo ekvivalentné. Z toho vyplýva, že nie je možné vystačiť si napr. s dodatočnými kódmi zasielanými cez SMS, ale je nutná vyššia forma zabezpečenia vo forme dedikovaného hardvérového tokenu USB zariadenia bližšie viď napr. https://www.keeprivacy.sk/blog/co-je-to-fido2-u2f-bezpecnostny-kluc/ kde je spôsob autentifikácie cez FIDO tokeny podrobne vysvetlený. Navrhovateľ zmieňuje 2FA na niekoľkých miestach [NávrhRiešenia], avšak len deklaratívne vymenovaním potenciálne vhodných technológií (prebratá formulácia z [OPZ]): "Authy, Microsoft Authenticator, LastPass, alebo ekvivalent" s dovetkom, že bližšie bude téma upresnená v DNR. Nepovažujem takýto 2FA popis za dostatočný. Navrhovateľ mal vybrať konkrétny spôsob implementácie a predložiť ho vo svojom popise navrhovaného riešenia. Okrem toho [KP] explicitne požaduje FIDO, resp. jeho ekvivalent a táto požiadavka nebola v [NávrhRiešenia] ani deklarovaná (odmysliac si všeobecnú alibistickú deklaráciu v zmysle "Dodáme všetko, čo je požadované").“
V súvislosti so závermi kontrolovaného uvedenými v Oznámení o vylúčení k nesplneniu predmetnej požiadavky (odcitované navrhovateľom v bode 17 tohto rozhodnutia) úrad položil znalcovi nasledovnú otázku č. 7, cit.: ,,Je

Vášho odborného názoru pravdivé tvrdenie Kontrolovaného, že v navrhnutom riešení sa používa len štandard OWASP Web Security Testing Guide (WSTG) a neuvažuje sa štandard OWASP Application Security Verification Standard (ASVS), ktorý bol jasne uvedený ako požiadavka (v Katalógu požiadaviek ako č. 52, č. 64 a 65)? Vašu odpoveď prosíme zdôvodnite.“ Znalec potvrdil tvrdenie kontrolovaného a skonštatoval nasledovné, cit.: ,,ÁNO, v navrhnutom riešení nebol priamo zmienený štandard OWASP ASVS, ale iba štandard OWASP WSTG a zoznam najdôležitejších zraniteľností OWASP TopTen

Nepovažujem preto požiadavky na dodržanie štandardu OWASP ASVS, úrovne L2 za splnené, práve naopak - z formulácie návrhu riešenia Obstarávateľ s najväčšou pravdepodobnosťou nadobudol Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 31 pocit, že namiesto OWASP ASVS je ponúkaný OWASP WSTG v kombinácii s OWASP TopTen, čo je v rozpore s požiadavkami zo súťažných podkladov.“
V súvislosti so závermi kontrolovaného uvedenými v Oznámení o vylúčení k nesplneniu predmetnej požiadavky (odcitované navrhovateľom v bode 17 tohto rozhodnutia) úrad položil znalcovi aj ďalšiu otázku, cit.: ,,otázka č. 8: Je

Vášho odborného názoru pravdivé tvrdenie Kontrolovaného, že v Návrhu riešenia Popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov nebol použitý štandard Web Content Accessibility Guidelines (WCAG) a bol poskytnutý iba všeobecný vlastný popis riešenia pre zdravotne znevýhodnených žiakov v kapitole "2.1.7. Realizácia testovania pre zdravotne znevýhodnených žiakov", ktorý bol jasne uvedený ako požiadavka (v Katalógu požiadaviek ako č. 106)? Vašu odpoveď prosíme zdôvodnite.“ Znalec nepotvrdil tvrdenie kontrolovaného a skonštatoval nasledovné, cit.: ,,Na popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov nebol Navrhovateľom priamo použitý štandard Web Content Accessibility Guidelines (WCAG), avšak Navrhovateľ v tomto popise deklaroval súlad s Metodickým usmernením MIRRI k monitorovaniu prístupnosti webových sídel a mobilných aplikácií (https://mirri.gov.sk/sekcie/informatizacia/dokumenty/standardy-isvs/pristupnostwebovych-sidel/metodika-monitorovania-webovych-sidel/), ktoré z WCAG 2.1 úrovne AA vychádza. Preto tvrdenie Kontrolovaného považujem za NEPRAVDIVÉ a

môjho názoru je popis funkcionality realizácie testovania pre zdravotne znevýhodnených žiakov v Navrhovateľom predloženej ponuke (v zásade) vytvorený použitím štandardu WCAG 2.1 úrovne AA.“ 17 99. V súvislosti s požiadavkou na podporu pre U2F a FIDO tokeny (alebo ekvivalentné) sa úrad znalca pýtal na pravdivosť tvrdenia kontrolovaného vo vyjadrení k námietkam (viď bod 58 tohto rozhodnutia), cit.: ,,v Prílohe 07 P1 Katalóg požiadaviek požiadavka č. 76 jasne žiadal podporovanie pre U2F a FIDO tokeny alebo ekvivalentné, čo Navrhovateľom citovaná autentifikácia v zmysle OTP 2FA z Návrhu riešenia spĺňa nedostatočne“. 18 Znalec potvrdil tvrdenie kontrolovaného, keď skonštatoval nasledovné, cit.: ,,ÁNO, popis riešenia 2FA v [NávrhRiešenia] je iba deklaratívny a Navrhovateľ

môjho názoru mal vybrať konkrétny spôsob implementácie, ktorý bolo nutné bližšie vysvetliť. Požadovaný FIDO token nebol dokonca ani zmienený, takže Kontrolovaný má jednoznačne pravdu v tvrdení, že túto požiadavky Navrhovateľ svojou ponukou JEDNOZNAČNE NESPLNIL.“ Ad) C – k dôvodu vylúčenia súvisiacim s požiadavkou kontrolovaného v bode 16.1.11 písm. d) SP – C1 - k nákresu a popisu aplikačnej architektúry 100. K uvedenej požiadavke znalec v odbornom stanovisku uvádza nasledovné, cit.: ,,Architektúra riešenia Pozn. znalca, cit.: ,,Je faktom, že Navrhovateľ v zásade len deklaratívne potvrdzuje, že požiadavky na zabezpečenie prístupnosti eviduje a bude riešiť v DNR. Zatiaľ čo pri napr. popise architektúry má základný náčrt už vo fáze ponukovania svoj zmysel, požiadavka riešenia prístupnosti je pomerne jasne definovaná formou Metodického usmernenia a nemá zmysel ju špeciálne rozpisovať do ponuky.“ 18 Pozn. úradu: celé znenie otázky č. 9, cit.: ,,Je

Vášho odborného názoru pravdivé tvrdenie Kontrolovaného vo vyjadrení k námietkam, že v Prílohe 07 P1 Katalóg požiadaviek požiadavka č. 76 jasne žiadal podporovanie pre U2F a FIDO tokeny alebo ekvivalentné, čo Navrhovateľom citovaná autentifikácia v zmysle OTP 2FA z Návrhu riešenia spĺňa nedostatočne?“ 17 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 32 Obstarávateľ požiadavky na architektúru riešenia ponechal pomerne otvorené, obmedzil sa iba na vymenovanie odporúčaných štandardov a technológií, hoci vždy nezabúda uviesť, že pripúšťa aj alternatívy, a nefunkčných architektonických požiadaviek (napr. požiadavka č. 53 na archiváciu čo požiadavky č. 75 a 129 na centralizáciu logov). Dokonca je možné využiť i tzv. tučného klienta (t.j. prístup cez vlastného aplikačného klienta, nie cez internetový prehliadač). (...) 19 V [OPZ] Obstarávateľ sústredí pozornosť, týkajúcu sa architektúry, najmä na cloudové požiadavky, pretože potrebuje riešenie (automatického) škálovania z dôvodu nárazovej záťaže počas celoplošného testovania, ktorá sa javí ako kľúčovým prvkom nového systému - viď [OPZ], kapitola "Backend infraštruktúra a architektúra" na strane 9 a 10, ako aj Súťažné podklady, bod 16.1.11, písm. e), kde sa explicitne od uchádzačov požaduje ako nutnú súčasť ponuky aj, citujem:

Návrh na typ a dodávateľa cloudu.
Detailný logický návrh technologickej architektúry (infraštruktúry) riešenia s popisom a kvantifikáciou minimálnych potrebných HW a SW komponentov.
Detailný fyzický návrh technologickej architektúry (infraštruktúry) riešenia s popisom a kvantifikáciou minimálnych potrebných HW a SW komponentov.
Výber vhodných cloudových služieb a spôsobu fakturácie.
Detailný architektonický a technologický návrh spôsobu škálovania systému.
Odhad nákladov na prevádzku informačného systému eTest II. vo zvolenom cloude v trvaní 24 mesiacov po nasadení diela
Odhad nákladov (opcia ) na prevádzku informačného systému eTest II. vo zvolenom cloude v trvaní na obdobie maximálne 24 mesiacov po uplynutí trvania prevádzkovej podpory po nasadení diela do produkcie. (koniec citátu) Cloud na jednej strane naozaj prináša lepšie možnosti (automatického) škálovania, na druhej strane je potrebné ustriehnuť náklady, čo si Obstarávateľ veľmi dobre v týchto požiadavkách uvedomuje a žiada od uchádzačov v ponuke popísať. Pri finálnom zostavovaní odpovedí na jednotlivé otázky, týkajúce sa architektúry - viď nižšie, som využíval aj dokument referenčnej architektúry systémov verejnej správy [ReferArch], z ktorého som čerpal "typický" obsah jednotlivých podkapitol / častí architektonického návrhu (viď aj [ReferArch], kapitola 2), citujem: (...) • Biznis architektúra – zameriava sa na realizáciu cieľov pomocou organizácie verejnej správy jej procesmi a koncovými službami, ktoré verejná správa ponúka v rámci svojich úsekov a agend, distribučnými kanálmi a prístupovými miestami pre poskytovanie týchto služieb občanom, podnikateľom, a tiež orgánom verejnej moci Slovenskej republiky alebo členského štátu EÚ. • Architektúra informačných systémov9 – zameriava sa na realizáciu koncových služieb pomocou aplikačných služieb, ich poskytovanie cez prístupové rozhrania, spracovanie a výmenu dát, vzťahy a závislosti na strategickú, biznis, technologickú a bezpečnostnú architektúru. Definuje základné členenie informačných systémov verejnej správy, ich klasifikáciu, vzájomné vzťahy a integráciu. • Technologická architektúra - zameriava sa na infraštruktúru podporujúcu informačné systémy verejnej správy prostredníctvom jednotlivých infraštruktúrnych (technologických) služieb s prioritným zameraním na vládny cloud a jeho rozširovanie vo verejnej správe. (...) (koniec citátu) Názornejšie je obsah vyjadrený vo forme schémy "Vysokoúrovňový 19 Pozn. úradu: citácia bodu 16.1.11 písm. d) SP Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 33 referenčných architektonický rámec" na strane 10 [ReferArch], z ktorého sú zrejme komponenty, z akých sa tieto tri architektonické vrstvy skladajú: Navrhovateľ popísal architektúru ponúkaného riešenia v [NávrhRiešenia], kapitola "3 Architektúra riešenia", ktorá je nosnou kapitolou celého dokumentu a ktorú som využíval ako primárny zdroj informácií o ponuke a vyhodnotenia naplnenia architektonických požiadaviek z [OPZ]. Obsahuje popis požadovaných architektonických vrstiev / pohľadov biznis architektúry, aplikačnej architektúry aj technologickej architektúry. Biznis architektúra Navrhovateľom predložený popis architektúry začína Biznis architektúrou, avšak táto predstavuje iba jednu schému bez akéhokoľvek popisu. Je pravdou, že názvy jednotlivých komponentov Biznis architektúry sú pomerne veľavravné, avšak niektoré procesy (napr. Aktualizácia údajov študentov) sa bez podrobnejšieho vysvetlenia naozaj nezaobídu. Je, jednoducho, NEAKCEPTOVATEĽNÉ považovať jeden obrázok, nech by bol akokoľvek názorný, za plnohodnotný popis Biznis architektúry systému - pre príklad popisu Biznis architektúry viď napr. [ReferArch], kapitola
Aplikačná architektúra Navrhovateľ pokračuje popis architektúry kľúčovou časťou 3.2 Aplikačná architektúra,

ktorej Aplikačná architektúra budúceho systému pozostáva z troch častí: • Biznisové moduly a komponenty • Prevádzkové moduly a komponenty • Technologické moduly a komponenty Popis Aplikačnej architektúry začína prehľadovou schémou, ktorá je ďalej upresňovaná v jednotlivých podkapitolách: Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 34 Schéma javí ZÁSADNÉ nedostatky: • chýbajú vzájomné väzby, • členenie jednotlivých blokov je zmätočné a nie je jasné, či má schéma predstavovať pohľad na moduly / komponenty systému, platformy, prístupové prvky alebo biznis procesy, • miešajú sa vzájomne nesúvisiace veci - napr. Integračný komponent obsahuje služby Poskytovanie dát, Import dát a REST API bez bližšieho vysvetlenia. Navyše REST API sa rozhodne nedá považovať za komponent, ide o technologický protokol realizácie integračných rozhraní10, • nie všetky komponenty sú popísané v ďalšom texte (napr. Správa popiskov) a zároveň ďalší text obsahuje komponenty, ktoré nie sú v schéme znázornené (napr. Bezpečnostné služby), • popis, ktorý vysvetľuje jednotlivé komponenty sa spravidla obmedzuje na taxatívne vymenovanie ich častí bez ďalšieho popisu. Technologická architektúra V nadväzujúcej kapitole "3.3 Komponentová architektúra" sú okrem iného spomínané i technológie, ktoré Navrhovateľ navrhuje použiť na vytvorenie nového systému. Avšak najmä v kapitolách "3.4.1. Biznisové moduly" a "3.4.3. Technologické moduly a komponenty" sú tabuľky, kde sú technológie spomenuté bez bližšieho vysvetlenia a nie je zrejmé, ako a prečo budú použité - napr. spomína sa Apache Cassandra i Microsoft SQL Server a nie je zrejmý účel jednotlivých platforiem; spomínajú sa XX produkty, ktoré bez bližšieho popisu nedávajú predstavu o ich potrebe pre budúci systém; technológie v tabuľke v kapitole 3.4.3 vôbec nie sú rozdelené medzi jednotlivé časti systému, ale iba vymenované - napr. ktoré komponenty budú postavené na Windows Serveri a ktoré na CentOS?, atď. Nasledujúca kapitola dokumentu

🔗 Na úradný zdroj

AI výklad z oficiálneho znenia zákona. Orientačný, nenahrádza právne poradenstvo.

Národný inštitút vzdelávania a mládeže - eTest druhej generácie (eTest II.)

Bratislava Číslo: 29. 04. 2024 7305-6000/2024 Úrad pre verejné obstarávanie ako ústredný orgán štátnej správy pre verejné obstarávanie

§ 140

§ 147písm.

§ 170ods.

§ 175ods.

§ 170ods.

§ 170ods.

§ 170ods.

§ 170ods.

§ 2ods.

§ 172ods.

§ 170ods.

§ 170ods.

§ 170ods.

§ 53zákona o verejnom obstarávaní porušil najmä § 10 ods.

§ 10ods.

§ 173ods.

§ 24

§ 173ods.

§ 173ods.

§ 173ods.

§ 175ods.

§ 10ods.

§ 10ods.

§ 24ods.

§ 20

§ 53ods.

§ 53ods.

§ 53ods.

§ 175ods.

§ 66ods.

§ 53ods.

§ 53ods.

§ 40ods.