SMLOUVA O DÍLO

SMLOUVA O DÍLO

NA DODÁVKU A IMPLEMENTACI SYSTÉMU AUTOMATIZACE NASTAVENÍ PRÁV A PORTÁL IDENTIT

uzavřená podle ustanovení § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník (dále jen

„občanský zákoník“) a podle zákona č. 121/2000 Sb., o právu autorském (dále jen „autorský zákon“), ve znění pozdějších předpisů („Smlouva“)

Smluvní strany

(1) město Zábřeh

se sídlem na adrese Xxxxxxxxxx xxxxxxx 000/0, 000 00 Xxxxxx XXX, DIČ: 00303640, CZ00303640

bankovní spojení: Československá obchodní banka, a. s. číslo účtu: 188491461/0300

zastoupené: RNDr. Mgr. Xxxxxxxxxx Xxxxxx, Ph.D., starostou číslo smlouvy: SD00401

(„Objednatel“)

(2) Orchitech Solutions, s.r.o.

se sídlem na adrese Xxxxxxxxx 0000/000, 000 00 Xxxxx 0

společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, vložka 135096, oddíl C

IČO: 28246764

DIČ: CZ28246764

bankovní spojení: Fio Banka, a.s.

číslo účtu: 2100886119 / 2010

zastoupený: Ing. Xxxxxxxx Xxxxxx, MBA, jednatelem („Zhotovitel“)

(Objednatel a Zhotovitel společně jen „Strany“ a každý z nich samostatně „Strana“)

● PREAMBULE

(A) Objednatel oznámil v otevřeném zadávacím řízení ve smyslu § 56 a násl. zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů („ZZVZ“), svůj úmysl zadat v tomto řízení veřejnou zakázku s názvem „V 00705 – Automatizace procesů města Zábřeh“, část 3, jejímž předmětem je provedení komplexního díla a zajištění poskytování služeb dodávky, implementace údržby, podpory a rozvoje systému automatizace nastavení práv a portál identit („Veřejná zakázka“).

(B) Současně s uzavřením této Smlouvy je mezi Objednatelem a Zhotovitelem uzavírána „Servisní smlouva o údržbě, podpoře a rozvoji systému“, na základě níž se Zhotovitel zavazuje poskytovat Objednateli v souladu se zadávací dokumentací na Veřejnou zakázku („Zadávací dokumentace“) servis, údržbu, podporu a rozvoj systému („Servisní smlouva“).

(C) Zhotovitel je v oboru informačních technologií odborníkem ve smyslu § 5 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů, („Občanský zákoník“) a prohlašuje, že má

veškeré dostupné požadované znalosti a nejnovější relevantní zkušenosti v oblasti ICT technologií pro oblast dodávek systému a technik požadovaných pro provedení takových plnění. Xxxxxxxxxx je proto připraven plnit své povinnosti vyplývající ze Xxxxxxx a realizovat předmět Xxxxxxx zakázky v souladu s principy „best practice“ dle svého nejlepšího vědomí, ve prospěch Objednatele a s ohledem na úsporu nákladů Objednatele.

(D) Zhotovitel je srozuměn s tím, že pro dodávku a implementaci systému musí vycházet ze stávajícího serverového software Objednatele a obecných požadavků Objednatele uvedených v zadávací dokumentaci, která je Přílohou č. 8 této smlouvy.

(E) Zhotovitel prohlašuje, že před podpisem Xxxxxxx obdržel od Objednatele veškeré podklady a informace potřebné k řádnému provedení díla dle Článku 1.2 písm. a) Smlouvy.

1 ÚČEL A PŘEDMĚT SMLOUVY

1.1 Účelem Smlouvy je dodávka systému automatizace nastavení práv a portál identit

(„Systém“) včetně jeho implementace a napojení na ostatní infrastrukturu Objednatele (včetně současně budované infrastruktury) a následné předání funkčního kompletu Objednateli, zaškolení administrátorů, uživatelů, rozvoje a podpory. Systém je určený pro Objednatele (město Zábřeh) a pro jeho organizace. Systém musí být navržen a dodán tak, aby neumožňoval vendor lock-in.

1.2 Předmětem této Smlouvy je zejména:

(a) povinnost Zhotovitele provést dílo za podmínek stanovených touto Smlouvou, zejména uvedených v Příloze č. 1 [Technická a věcná specifikace] a v Zadávací dokumentaci, včetně udělení veškerých souvisejících oprávnění Objednateli („Dílo“);

(b) povinnost Objednatele zaplatit Zhotoviteli za řádně provedené Dílo cenu sjednanou v Článku 3 (Cena).

2 DOBA A MÍSTO PROVEDENÍ DÍLA

2.1 Zhotovitel se zavazuje provést Dílo tak, aby došlo k řádnému provedení, předání a dokončení Díla včas a podle níže uvedených fází („Fáze“). Dílo jako celek je provedeno řádným dokončením všech Fází a odstraněním veškerých vad uvedených ve výhradách Objednatele v akceptačním protokolu dle Článku 6 (Akceptační řízení) a Přílohy č. 2 [Akceptační řízení].

2.2 Harmonogram realizace díla („Harmonogram“) je následující:

Fáze 0 – Implementační studie

Zahájení zpracování implementační studie ihned po účinnosti smlouvy. Předání zpracovaného návrhu implementační studie nejpozději do 45 dnů od účinnosti smlouvy. Následně Objednatel do 14 dnů od předání zpracuje své připomínky k implementační studii a předá je Zhotoviteli. Zhotovitel má následně 14 dní na zapracování připomínek k implementační studii a předložení finálního znění implementační studie Objednateli. Objednatel implementační studii do 5 dnů od předání akceptuje anebo ji v případě nezapracování připomínek Objednatele vrátí Zhotoviteli k celkovému přepracování. Vrácením implementační studie k celkovému přepracování Zhotoviteli se Zhotovitel dostává do prodlení se splněním termínu dokončení této fáze.

Fáze 1 – Instalace a implementace

Zahájení realizace Díla (tj. návrh, vytvoření, instalace a implementace Systému) proběhne neprodleně po akceptaci implementační studie.

Zahájení implementace – do 5 dnů po akceptaci implementační studie a po dodání plnění dle části 4 veřejné zakázky podle toho, který okamžik nastane později, přičemž Dodavatel je oprávněn

provádět přípravné práce před vlastním zahájením implementace (tyto se nepovažují za zahájení implementace), pakliže to bude s ohledem na stav infrastruktury možné a vhodné.

Dokončení implementace – nejpozději do 150 dnů od zahájení implementace. Fáze 2 – Zkušební provoz

Po dokončení implementace bude Dílo předáno do zkušebního/testovacího provozu v délce trvání 30 dní. Objednatel si vyhrazuje možnost zkrátit zkušební provoz, pakliže to bude dle jeho potřeb vhodné.

Fáze 3 – Plný provoz

Spuštění plného provozu proběhne do 7 dnů po ukončení zkušebního provozu akceptací Díla ze strany Objednatele.

2.3 Po dobu 5 let od spuštění plného provozu se zavazuje Dodavatel udržovat systém plně funkční, rozvíjet ho v souladu s potřebami Objednatele a dle relevantních právních předpisů a jejich změn.

2.4 Zhotovitel se zavazuje provést Dílo v sídle Objednatele, případně na jiném místě určeném Objednatelem v České republice v souladu s touto Smlouvou, nebo vzdáleným přístupem.

3 CENA

3.1 Objednatel se zavazuje zaplatit Xxxxxxxxxxx za řádně provedené Dílo cenu ve výši 1 444 000 Kč (slovy: jeden milion čtyři sta čtyřicet čtyři tisíc korun českých) bez DPH, DPH 21 % činí 303 240 Kč (slovy: tři sta tři tisíc dvě stě čtyřicet korun českých), tj. 1 747 240 Kč včetně DPH (slovy: jeden milion sedm set čtyřicet sedm tisíc dvě stě čtyřicet korun českých) („Cena“).

3.2 Cena je splatná na základě daňového dokladu – faktury vystavené Zhotovitelem v souladu s tímto Článkem 3 (Xxxx) a s Článkem 4 (Fakturace a platební podmínky).

3.3 Cena bez DPH je mezi Stranami výslovně sjednávána jako nejvyšší možná a nepřekročitelná. Tímto není dotčeno ujednání Stran obsažené v Článku 5.11. DPH bude stanovena ve výši dle právních předpisů platných a účinných ke dni uskutečnění zdanitelného plnění.

3.4 Cena zahrnuje odměnu za veškeré dodávky, činnosti - služby prováděné na základě této Smlouvy, veškeré náklady Zhotovitele spojené s plněním Smlouvy, odměnu za udělení Oprávnění dle Článku 8 (Práva duševního vlastnictví), jakož i výdaje a náklady, které Zhotoviteli vzniknou či mohou vzniknout, včetně výdajů a nákladů na využití Poddodavatele. Aplikace ustanovení § 2436 Občanského zákoníku upravujícího úhradu hotových výdajů a povinnost poskytnout odpovídající zálohu se vylučuje.

4 FAKTURACE A PLATEBNÍ PODMÍNKY

4.1 Cena dle Článku 3 (Cena) bude hrazena na základě daňového dokladu – Faktury. Faktura musí vždy obsahovat:

(a) údaje v souladu s § 29 zák. č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů („Zákon o DPH“);

(b) údaje v souladu s § 435 Občanského zákoníku;

(c) označení a číslo této Smlouvy;

(d) název projektu, registrační číslo projektu a informaci, že se jedná o projekt podpořený z Integrovaného regionálního operačního programu, následujícím způsobem: Projekt

„Automatizace procesů města Zábřeh“, reg. č. CZ.06.01.01/00/22_008/0000512 je spolufinancován z Integrovaného regionálního operačního programu.

(e) kopie Závěrečného akceptačního protokolu dle Článku 4.4;

(f) případně další náležitosti stanovené Smlouvou („Faktura“).

4.2 Cena bude hrazena přímo na bankovní účet Zhotovitele specifikovaný v záhlaví této Smlouvy, nebo na jiný bankovní účet Zhotovitele zveřejněný správcem daně, který bude později písemně oznámený Objednateli a uvedený ve Faktuře.

4.3 Lhůta splatnosti Faktury je 30 dnů ode dne doručení Faktury Zhotovitele Objednateli. Fakturu lze zaslat formou e-faktury, prostřednictvím informačního systému datových schránek do datové schránky Objednatele, nebo elektronicky (ve formátu PDF) se zaručeným elektronickým podpisem na emailovou adresu Objednatele: Připadne-li termín splatnosti na den, který není pracovním dnem, posouvá se termín splatnosti na nejbližší následující pracovní den. Faktura se považuje za uhrazenou odepsáním příslušné částky z účtu Objednatele.

4.4 Faktura ve výši 10 % z ceny díla dle čl. 3.1 bude vystavena po akceptaci implementační studie. Zbývající část ceny ve výši 90 % z ceny díla dle čl. 3.1 bude vystavena po provedení Díla, tzn. po podpisu Závěrečného akceptačního protokolu pro Dílo Objednatelem s výrokem

„Akceptováno“ dle Článku 6 (Akceptační řízení) a dle bodu 1.8 Přílohy č. 2 [Akceptační řízení], jehož kopie musí tvořit přílohu originálu Faktury.

4.5 Objednatel má po obdržení Faktury 30 dnů na posouzení toho, zda je bezchybně vystavena (splňuje podmínky této Smlouvy) a splňuje všechny náležitosti daňového dokladu ve smyslu právních předpisů, a na její vrácení, a to i opakovaně, pokud není bezchybně vystavena nebo nesplňuje všechny náležitosti daňového dokladu nebo k ní nebyl přiložen podklad dle Článku 4.4. Vrácením takové Faktury se lhůta splatnosti a lhůta pro posouzení bezchybnosti Faktury přerušuje a po dodání opravené Faktury začíná běžet lhůta nová.

4.6 V peněžních částkách poukazovaných mezi Zhotovitelem a Objednatelem na základě této Smlouvy nejsou zahrnuty bankovní poplatky ani jiné náklady spojené s převody peněžních částek. Strana poukazující hradí bankovní poplatky spojené s odepsáním peněžní částky z účtu poukazující Strany a Strana poukázaná hradí bankovní poplatky spojené s připsáním peněžní částky na účet poukázané Strany.

4.7 V případě, že Zhotovitel získá v průběhu trvání smluvního vztahu založeného touto Smlouvou rozhodnutím správce daně status nespolehlivého plátce v souladu s § 106a Zákona o DPH, uhradí Objednatel daň z přidané hodnoty z poskytnutého plnění – dle § 109a Zákona o DPH – přímo příslušnému správci daně namísto Zhotovitele a následně uhradí Zhotoviteli cenu poníženou o takto zaplacenou daň. Zhotovitel se zavazuje na Faktuře uvést účet zveřejněný správcem daně.

4.8 Objednatel neposkytuje na žádné plnění dle této Smlouvy žádné zálohy ani závdavek.

4.9 V případě prodlení Objednatele s platbou Faktury má Zhotovitel právo požadovat úhradu úroku z prodlení dle zvláštního právního předpisu v platném znění (nařízení vlády č. 351/2013 Sb.).

5 ZPŮSOB PROVEDENÍ DÍLA

5.1 Dílo je rozděleno do čtyř (4) Fází. Jednotlivé Fáze jsou detailně specifikované v Článku 2 (Doba a místo provedení díla), včetně plnění, které je jejich součástí.

5.2 Zhotovitel se zavazuje provést všechny 4 Fáze. Výstupy Fází 1 a 2 budou předmětem Akceptačního řízení dle Článku 6 (Akceptační řízení) a dle Přílohy č. 2 [Akceptační řízení].

5.3 Fáze je dokončena akceptací všech jejích výstupů.

5.4 Výstupy Fáze 0, 1 a 2 budou předány Xxxxxxxxxxxx Objednateli na základě podpisu příslušného předávacího protokolu vyplněného Zhotovitelem a upraveného Objednatelem („Předávací protokol“).

5.5 Zhotovitel musí písemně informovat Objednatele nejméně 3 dny předem o termínu předání každého výstupu Fáze 0, 1 a 2.

5.6 Do 7 pracovních dnů od účinnosti Smlouvy proběhne úvodní schůzka členů realizačního týmu dle Článku 12 (Realizační tým a Kontaktní osoby) („Realizační tým“) a zástupců Objednatele.

5.7 V rámci provedení Díla se Zhotovitel zavazuje řídit pokyny Objednatele a rovněž provést dodatečné finální úpravy předmětu Díla, které nelze specifikovat předem a které budou definovány až při provádění Díla jako součást optimalizace předmětu Díla. Tyto dodatečné finální úpravy slouží pouze k naplnění účelu, pro který je Dílo prováděno, a zajištění řádného fungování Díla jako celku, tj. zejména k odstranění nepřesností, které vzniknou při provádění Díla a k řádnému uvedení Díla do rutinního provozu, když rutinním provozem se rozumí běžný provoz Systému v prostředí Objednatele („Rutinní provoz“). Uvedené dodatečné finální úpravy nezahrnují dodatečné změny Díla, které nebyly předmětem Xxxxxxx zakázky a jejichž provedení by představovalo vícepráce či méněpráce a na které se uplatní postup podle Článku 5.12.

5.8 Objednatel se může dožadovat toho, aby Xxxxxxxxxx odstranil vady vzniklé postupem v rozporu s touto Smlouvou do 5 dní od doručení výzvy a dále tuto Smlouvu plnil řádným způsobem. Jestliže tak Zhotovitel neučiní do 15 pracovních dnů od doručení výzvy, jeho postup bude chápán jako podstatné porušení této Smlouvy.

5.9 Zhotovitel musí pro implementaci a provoz Systému využít pouze Objednatelem přidělené prostředky – IT prostředí. Popis IT prostředí ke dni uzavření této Smlouvy je uveden v Příloze č. 1 [Technická a věcná specifikace].

5.10 Zhotovitel musí v průběhu provádění Díla postupovat v souladu s platnou interní bezpečnostní politikou a platnými bezpečnostními předpisy Objednatele.

5.11 Zhotovitel se zavazuje při provádění Xxxx postupovat ve vzájemné součinnosti s dodavateli dalších částí veřejné zakázky tak, aby bylo dosaženo účelu této smlouvy.

5.12 Podle tohoto Článku 5.12 bude postupováno při zadání a schvalování změnových požadavků týkajících se Díla a předmětu Díla spočívajících v méněpracích (zúžení rozsahu Díla) nebo vícepracích (rozšíření rozsahu Díla), případně v dalších změnách Díla („Změnové řízení“).

(a) Změny Díla smí být provedeny pouze písemným dodatkem ke Smlouvě.

(b) Požadavek na změnu Díla může zaslat Objednatel, resp. Kontaktní osoba Objednatele Zhotoviteli.

(c) Zhotovitel vypracuje do 5 pracovních dnů ode dne doručení požadavku Objednatele na změnu Díla shrnutí, které musí obsahovat:

● odkaz na tuto Smlouvu;

● označení Stran;

● předmět změny;

● dopad na Dílo;

● návrh konceptu technického řešení včetně plánu činností,

● dopad na Harmonogram;

● termín nasazení změny;

● testovací scénáře, když testovacím scénářem se pro účely Xxxxxxx rozumí scénář průběhu a provedení konkrétního procesu, přičemž tento scénář zpravidla určuje jednotlivé kroky, které mají být provedeny, počet uživatelů k jejich provedení, množství dat k jejich provedení a další atributy tak, aby došlo k dostatečnému otestování příslušné funkčnosti Systému („Testovací scénář“);

● požadavky na součinnost Objednatele a třetích osob;

● posouzení dopadů a rizik;

● akceptační kritéria, která vycházejí z požadavku na změnu;

● pracnost a cenu změny Díla na základě plánovaných činností; („Shrnutí“).

Shrnutí předloží Zhotovitel v uvedené lhůtě Objednateli ke schválení.

(d) Po schválení Shrnutí Objednatelem přistoupí Strany k uzavření dodatku ke Smlouvě v písemné podobě s obsahem dle schváleného Shrnutí.

5.13 Dojde-li k neshodě Stran ohledně požadavku na změnu Díla nebo nedojde-li ke schválení Shrnutí Objednatelem do 5 pracovních dnů od jeho doručení Objednateli, přistoupí Strany k postupu dle Eskalačního procesu dle Článku 22.3.

6 AKCEPTAČNÍ ŘÍZENÍ

6.1 Proces akceptace výstupů Fází probíhá v souladu s Harmonogramem na základě Akceptačního řízení, tj. postupným provedením akceptačních testů a jiných procesů a podepsáním Akceptačních protokolů pro výstupy jednotlivých Fází. Podrobný popis Akceptačního řízení, včetně kategorizace vad a kritérií pro akceptaci výstupů Fází je uveden v Příloze č. 2 [Akceptační řízení].

6.2 Po provedení všech nezbytných činností v rámci Akceptačního řízení se Objednatel i Zhotovitel zavazují podepsat příslušný protokol potvrzující výsledek Akceptačního řízení příslušné Fáze Díla vyplněný Zhotovitelem a upravený Objednatelem („Akceptační protokol“).

6.3 V případě, že Zhotovitel předá Objednateli výstup Fáze potvrzený podpisem Akceptačního protokolu, přestože tento výstup nesplňuje Akceptační kritéria a Objednatel daný výstup neschválí uvedením „Neakceptováno“ v Akceptačním protokolu, může Objednatel požadovat sankci (dle Článku 16.1(b), a to i opakovaně v rámci jednoho Akceptačního řízení (týkajícího se stejného výstupu), i mimo tento rámec (tzn. v Akceptačním řízení pro jiné výstupy nebo jiné Fáze), a to i v případě, že bude současně uplatněna sankce dle Článku 16.1(a)).

6.4 Lhůta k vytčení vad, resp. výhrad nemá žádný vliv na dobu trvání Záruční doby a podmínky pro uplatnění vad dle Článku 14 (Záruka a práva z vadného plnění).

7 SOUČINNOST

7.1 Strany si poskytnou součinnost nezbytně nutnou pro řádné plnění této Smlouvy.

7.2 V rámci poskytování součinnosti musí Objednatel předávat Zhotoviteli dokumenty v držení Objednatele nezbytně nutné pro řádné plnění této Smlouvy Zhotovitelem. Objednatel však nemusí v rámci poskytování součinnosti vytvářet žádné nové dokumenty.

7.3 V případě, že Zhotovitel zjistí, nebo při vynaložení odborné péče mohl zjistit, že informace nebo pokyny poskytnuté Objednatelem nebo specifikace Díla nezbytné pro provedení Díla jsou neúplné, chybné nebo nevhodné, musí Zhotovitel na tuto skutečnost Objednatele bez zbytečného odkladu písemně upozornit a vyžádat si doplnění nebo úpravu informací nebo

pokynů. V případě, že tak Zhotovitel neučiní, odpovídá za případně vzniklou újmu, přičemž újmou se pro účely této Smlouvy rozumí vždy újma na jmění (škoda) ve smyslu § 2894 odst. 1 Občanského zákoníku a dále vždy i nemajetková újma ve smyslu § 2894 odst. 2 Občanského zákoníku.

7.4 Zhotovitel se zavazuje umožnit osobám oprávněným k výkonu kontroly projektu, z něhož je Veřejná zakázka hrazena, provést kontrolu dokladů souvisejících s plněním zakázky, a to po dobu nejméně 10 let od ukončení financování díla způsobem, který je v souladu s platnými právními předpisy České republiky a Evropských společenství.

7.5 Zhotovitel je povinen minimálně do konce roku 2035 poskytovat požadované informace a dokumentaci související s realizací projektu, z něhož je Veřejná zakázka hrazena, zaměstnancům nebo zmocněncům pověřených orgánů (CRR, MMR ČR, MF ČR, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, příslušného orgánu finanční správy a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci projektu a poskytnout jim při provádění kontroly součinnost.

7.6 Zhotovitel je podle ustanovení §2 písm. e) Zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů, ve znění pozdějších předpisů, osobou povinou spolupůsobit při výkonu finanční kontroly prováděné v souvislosti s úhradou zboží nebo služeb z veřejných výdajů.

7.7 Zhotovitel i Objednatel poskytnou veškerou součinnost potřebnou pro zajištění komunikace a vzájemné interoperability Systému s dalšími informačními systémy určenými Objednatelem.

7.8 Objednatel musí poskytovat součinnost pouze v rozsahu a způsoby stanovenými v Článku 7.2,

7.3 a 7.4 Xxxxxxx.

8 PRÁVA DUŠEVNÍHO VLASTNICTVÍ

8.1 Vyjma případů, kdy je užit běžně dostupný software, který Zhotovitel považuje za vhodné instalovat a integrovat do Systému, a který slouží k řádnému provozu Systému, a zároveň byl vytvořen a je distribuován pod standardními licenčními podmínkami více třetím osobám („Standardní software“), je Zhotovitel za všech okolností povinen užít k provedení Díla autorská díla, k nimž je oprávněn poskytnout Objednateli oprávnění taková autorská díla užít za podmínek stanovených v tomto Článku 8 (Práva duševního vlastnictví). Autorským dílem se pro účely Smlouvy rozumí dílo ve smyslu § 2 zákona č. 120/2000 Sb., autorský zákon v platném znění („Autorské dílo“ a „Autorský zákon“).

8.2 S účinností ke dni předání jednotlivých výstupů Fází Zhotovitel uděluje Objednateli oprávnění užívat Autorská díla a databáze ve smyslu § 88 Autorského zákona (či jinou nechráněnou databázi) („Databáze“) obsažené v předmětu Díla či v jeho části, a to v rozsahu dle tohoto Článku 8.2, není-li v tomto Článku 8 sjednáno jinak, přičemž:

(a) pokud se jedná o Autorské dílo nebo Databázi, k nimž je vykonavatelem anebo nositelem majetkových autorských práv Xxxxxxxxxx, uděluje Zhotovitel Objednateli:

(i) Nevýhradní licenci (jak je definována níže), pokud se jedná o Autorské dílo nebo Databázi, ve vztahu k nimž je Xxxxxxxxxx oprávněn sám udělit Objednateli oprávnění k jejich užití a nejedná se o Standardní software nebo software šířený či distribuovaný pod některou z veřejných licencí (například opensource anebo free software licence), který je veřejnosti poskytován zdarma, včetně detailně komentovaných Zdrojových kódů, úplné uživatelské, provozní a administrátorské dokumentace a práva Software měnit, který Zhotovitel považuje za vhodné použít, instalovat a integrovat do IT prostředí v souladu s touto Smlouvou, a který slouží k řádnému provozu Systému

(„Program s otevřeným kódem“). Dokumentací se pro účely Xxxxxxx rozumí jakákoli dokumentace (záznamy o provádění Díla, popis Zdrojových kódů, protokoly o provedených testech a/nebo o odstranění vad, technická, uživatelská, bezpečnostní, provozní a případně další dokumentace) vyhotovovaná v rámci provádění Díla, s tím, že musí být vždy vyhotovena v souladu s platnými právními předpisy a předána Objednateli v elektronické podobě („Dokumentace“);

(ii) Nevýhradní licenci, pokud se jedná o Dokumentaci;

(iii) Nevýhradní licenci (jak je definována níže), pokud se jedná o Standardní software; povinnost Zhotovitele zajistit poskytnutí podpory (subscription/license maintenance) nejméně v takovém rozsahu, aby bylo Objednateli umožněno používání Standardního Softwaru u Objednatele a na všech organizačních složkách či jiných útvarech Objednatele;

(iv) pokud se jedná o Program s otevřeným kódem anebo Autorské dílo podobné Programu s otevřeným kódem ve smyslu distribuce pod jednou z veřejných licencí, které jsou součástí Systému, je Zhotovitel povinen zajistit Objednateli udělení oprávnění v rozsahu takových veřejných licencí, které se na Autorské dílo vztahují, přičemž konkrétní rozsah licence lze určit odkazem na soubor předávaný v rámci provádění Díla anebo odkazem ve Zdrojovém kódu či jiném označení takové licence ve formátu vyžadovaném takovou veřejnou licencí, včetně odkazu na kompletní znění aktuálních licenčních podmínek veřejné licence; povinnost Zhotovitele zajistit poskytnutí podpory (subscription/license maintenance) se uplatní obdobně na Program s otevřeným kódem; a

(v) pro zamezení pochybnostem je Xxxxxxxxxx povinen podniknout veškeré kroky k získání náležitých oprávnění tak, aby mohl udělit Objednateli veškeré nezbytné licence v souladu s tímto Článkem 8.2.

(b) pokud se jedná o Autorské dílo nebo Databázi, ve vztahu k nimž je nositelem anebo vykonavatelem majetkových autorských práv třetí osoba odlišná od Xxxxxxxxxxx nebo se Xxxxxxxxxxxx propojených osob a Xxxxxxxxxx nemůže z objektivních důvodů udělit Objednateli oprávnění k užití Autorských děl a Databází dle Článku 8.2(a) (například z důvodů prokazatelné absence vůle takové třetí osoby) splní Zhotovitel svou povinnost udělit Objednateli oprávnění tím, že Objednateli bude uděleno oprávnění ze strany takové třetí osoby, a to v rozsahu:

(i) Nevýhradní licence, pokud se nejedná o Standardní software, a

(ii) Nevýhradní licence, pokud se jedná o Standardní software.

Tento Článek 8.2(b) se neuplatní na Program s otevřeným kódem, jelikož na ten se vztahuje Článek 8.2.(a) bod (iv).

8.3 Zhotovitel bude při pořizování oprávnění dle Článků 8.2(b) vystupovat jako příkazník Objednatele a zajistí pro Objednatele oprávnění tam stanovená za následujících podmínek:

(a) Strany vylučují aplikaci ustanovení § 2436 až 2438, § 2440 a § 2443 Občanského zákoníku, jelikož Smlouva obsahuje vlastní úpravu daných záležitostí;

(b) Objednatel uzavřením této Smlouvy zmocňuje Xxxxxxxxxxx k právnímu jednání pouze a jenom ve smyslu a rozsahu dle tohoto Článku 8.3 a na dobu trvání této Smlouvy. Objednatel vystaví na žádost Zhotovitele plnou moc pro účely splnění tohoto Článku 8.3;

(c) pořízení oprávnění je součástí Ceny a Zhotovitel musí v této souvislosti postupovat vždy tak, aby Objednateli nevznikaly žádné další náklady nad rámec Ceny po celou dobu trvání takových oprávnění.

8.4 Nevýhradní licencí se rozumí nevýhradní nevýlučné oprávnění Autorské dílo užít v původní i změněné podobě, v neomezeném územním, množstevním rozsahu, v míře neomezené počtem uživatelů nebo mírou užívání, pro jakýkoliv způsob užití a k jakémukoliv účelu, v časovém rozsahu na dobu trvání majetkových autorských práv a v souladu s dalšími podmínkami tohoto Článku 8.4 („Nevýhradní licence“), přičemž Nevýhradní licence je poskytována dále za následujících podmínek, není-li v této Smlouvě dále stanoveno výslovně jinak:

(a) vztahuje-li se na Software, Databáze, pak jak ve Zdrojovém kódu, tak strojovém kódu;

(b) zahrnuje nevýhradní oprávnění Objednatele Autorské dílo upravovat, měnit, spojit s jiným dílem či zařadit do díla souborného, zpracovávat včetně překladu (například do jiného programovacího jazyka), dokončovat nehotové Autorské dílo, a to vše i prostřednictvím třetí osoby, s čímž Xxxxxxxxxx souhlasí. Zhotovitel zajistí případný nezbytný souhlas třetích osob, které užil k plnění jeho povinností při plnění Smlouvy, s výše uvedeným a s postupováním tohoto oprávnění na třetí osoby v rámci postoupení Nevýhradní licence či udělení podlicence dle Článku 8.4(c).

(c) Objednatel je oprávněn postoupit Nevýhradní licenci zčásti, v celku anebo udělit podlicenci jakýmkoliv organizacím, organizačním složkám a jiným útvarům podřízeným anebo spravovaným Objednatelem, s čímž Zhotovitel výslovně souhlasí. Objednatel je oprávněn v rozsahu dle tohoto Článku 8.4 (c) Autorské dílo zveřejňovat.

8.5 V případě, že v rámci provádění Xxxx Xxxxxxxxxxxx dojde k vytvoření Databáze, přísluší zvláštní práva pořizovatele Databáze Objednateli. Odměna za poskytnutí (postoupení) oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) je součástí Ceny.

8.6 Bez ohledu na jakákoliv omezení oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) Objednatel smí vytvářet záložní kopie Autorského díla pro své vnitřní potřeby bez množstevního omezení bez ohledu na omezení oprávnění. Objednatel je oprávněn přenášet elektronicky kopie Autorského díla prostřednictvím počítačové sítě či jinak z jednoho počítače do jiného. Oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) jsou udělována jako on- premise oprávnění, tj. součástí Díla nesmí být cloudová či obdobná řešení.

8.7 Objednatel může publikovat výstupy Fází, jejichž povaha to umožňuje, zejména pod veřejnou licencí Evropské unie EUPL („EUPL licence“). Zhotovitel odpovídá za to, že výstupy Fází, jejichž povaha to umožňuje, vytvořené na základě této Smlouvy, budou slučitelné s EUPL licencí a že tyto výstupy bude možné dále oprávněně převádět, šířit, sdělovat či jinak užívat dle podmínek této Smlouvy a podmínek EUPL licence. Jestliže práva průmyslového nebo duševního vlastnictví k některému plnění, které je součástí Díla, existují již před uzavřením této Smlouvy, provede Zhotovitel příslušnou kontrolu a zajistí, aby bylo možné všechny výstupy, jejichž povaha to umožňuje, vzniklé na základě této Smlouvy, převádět, šířit a sdělovat či jinak užívat prostřednictvím licence EUPL. Výjimky jsou možné pouze s předchozím souhlasem Objednatele uděleným v listinné podobě na žádost Zhotovitele.

8.8 Objednatel není povinen nabytá oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) využít. Zhotovitel prohlašuje, že oprávněné zájmy autora nemohou být značně nepříznivě dotčeny tím, že Objednatel nebude oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) vůbec či zčásti užívat.

8.9 Zhotovitel prohlašuje, že s ohledem na povahu výnosů z poskytnutých oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) nemohou vzniknout podmínky pro uplatnění ustanovení

§ 2374 Občanského zákoníku, tedy že odměna za udělení oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) k jednotlivým Autorským dílům nemůže být ve zřejmém nepoměru k zisku z využití oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) a významu příslušného Autorského díla pro dosažení takového zisku.

8.10 Zhotovitel není oprávněn užít k vytvoření Autorského díla vytvářeného v rámci provádění Xxxx nebo jeho části Autorská díla, u nichž není oprávněn vykonávat majetková autorská práva nebo ke kterým nemůže udělit licenci alespoň v rozsahu Nevýhradní licence.

8.11 K žádosti Objednatele zajistí Zhotovitel i po zániku smluvního vztahu založeného touto Smlouvou vyhotovení/podepsání jakýchkoliv listin či dokumentů, které by mohly být potřebné k přiznání právních účinků a účelu tohoto Článku 8 (Práva duševního vlastnictví), kterým je poskytnutí Zhotovitelem v maximální možné míře přípustné dle českého práva oprávnění v rozsahu dle tohoto Článku 8 (Práva duševního vlastnictví).

8.12 Nevýhradní licence dle Smlouvy se použije v maximální možné míře připuštěné českým právem nejen na Autorská díla, ale také na jakékoliv výstupy Fází a jiné výsledky provádění Díla, které jsou předmětem právní ochrany nehmotných statků, zejména na know-how, které Zhotovitel vytvoří v rámci nebo v souvislosti s plněním Smlouvy („Předměty práv k nehmotným statkům“). Zhotovitel tak tímto uděluje Nevýhradní licenci rovněž k Předmětům práv k nehmotným statkům, a to v maximálním rozsahu, v jakém je k tomu oprávněn, jinak alespoň podle toho, ke které části Systému se Předměty práv k nehmotným statkům vztahují. Strany přitom pro zamezení pochybnostem prohlašují, že veškerá data předaná či zpřístupněná Objednatelem a zpracovávaná Zhotovitelem při plnění Smlouvy nadále náleží Objednateli.

8.13 Zhotovitel prohlašuje, že je oprávněn Objednateli udělit anebo zajistit udělení oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) a že udělením takových oprávnění Objednateli za podmínek dle Smlouvy ani užíváním výstupů Fází Objednatelem či uživateli v souladu se Smlouvou nebudou porušena práva duševního vlastnictví třetí osoby. V případě, že by třetí osoba vznesla vůči Objednateli jakékoliv nároky z porušení práv duševního vlastnictví v souvislosti s užíváním výstupů Fází Objednatelem, zavazuje se Objednatel o této skutečnosti neprodleně informovat Xxxxxxxxxxx. Zhotovitel se zavazuje přijmout taková opatření, aby Objednatel byl oprávněn nerušeně užívat výstupy Fází, zejména zajistit pro Objednatele udělení oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) ve stejném rozsahu, v jakém jej má Zhotovitel, bez dalších nákladů a požadavků na úplatu od Objednatele.

8.14 V případě, že jakákoliv třetí osoba uplatní nárok z důvodu porušení práv duševního vlastnictví ve vztahu k výstupu Fází, jež Zhotovitel předal Objednateli, je Zhotovitel povinen nahradit Objednateli veškerou újmu takto způsobenou, jakož i účelné náklady vynaložené na obranu práv Objednatele z oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví) ve smyslu § 2369 Občanského zákoníku. Zhotovitel se v takovém případě dále zavazuje na svůj náklad poskytnout Objednateli veškerou možnou součinnost k ochraně jeho práv a oprávnění dle tohoto Článku 8 (Práva duševního vlastnictví); zejména mu poskytnout všechny podklady, informace a vysvětlení k prokázání neoprávněnosti nároku třetí strany, a to bezúplatně a bez požadavků na úhradu dalších nákladů.

8.15 V případě nároku dle předchozího Článku 8.14, nebo je-li důvodné předpokládat, že takový nárok bude uplatněn, zajistí Zhotovitel Objednateli možnost dále příslušný výstup užívat bez nároku na úplatu nad rámec sjednaný v této Smlouvě.

8.16 Objednatel předal Zhotoviteli v rámci podkladů pro realizaci Díla Autorská díla a Databáze, včetně související dokumentace, k nimž je Objednatel vykonavatelem anebo nositelem majetkových autorských práv. Strany výslovně sjednávají, že Xxxxxxxxxx je oprávněn tato Autorská díla a Databáze (včetně dokumentace) dle věty první tohoto Článku 8.16 užít pouze za účelem provedení Díla. Vznikne-li při takovémto užití (případně při zpracování či úpravě) Autorského díla, Databáze nebo dokumentace dle věty první tohoto článku 8.16 nové Autorské dílo, nová Databáze nebo Dokumentace uplatní se ustanovení § 58 odst. 7 Autorského zákona. Nositelem majetkových autorských práv k novému Autorskému dílu tak bude Objednatel, kterému rovněž budou příslušet zvláštní práva pořizovatele nové Databáze. Zhotovitel v této

souvislosti uděluje Objednateli souhlas s postoupením majetkových práv k nově vzniklému Autorskému dílu, Databázi či Dokumentaci třetí osobě.

8.17 Strany výslovně prohlašují, že pokud při poskytování plnění dle Smlouvy vznikne činností Zhotovitele a Objednatele dílo spoluautorů nebo kolektivní dílo a nedohodnou-li se Strany výslovně jinak, Objednatel nabývá v tomto případě práva duševního vlastnictví stanovená výše v tomto Článku 8 (Práva duševního vlastnictví). Cena dle Článku 3 (Cena) je stanovena se zohledněním tohoto ustanovení a Zhotoviteli nevzniknou v případě vytvoření díla spoluautorů žádné nové nároky na odměnu.

8.18 Spolu se Standardním software a Programem s otevřeným kódem musí vždy být předána kompletní Dokumentace.

8.19 Veškerá data předaná či zpřístupněná Objednatelem a/nebo zpracovávaná Zhotovitelem při plnění této Smlouvy náleží Objednateli.

9 ZDROJOVÝ KÓD

9.1 Zdrojovým kódem se pro tuto Smlouvu rozumí takový zápis kódu Softwaru v programovacím jazyce, který je uložen v jednom nebo více editovatelných souborech, čitelný, opatřený komentáři vysvětlujícími jednotlivé jeho části a procesy alespoň ve standardu obvyklém pro opensource projekty a procesy ve spustitelném formátu odpovídajícím programovacímu jazyku a prostředí Objednatele, včetně ověřeného postupu nezbytného pro sestavení strojového kódu („Zdrojový kód“). Zdrojový kód musí být spustitelný v prostředí Objednatele a zaručující možnost ověření, že je kompletní a ve správné verzi, tzn. umožňující kompilaci, instalaci, spuštění a ověření funkcionality, a to včetně podrobné dokumentace Zdrojového kódu takovéto části Systému, na základě které bude kvalifikovaný pracovník Objednatele schopen pochopit veškeré funkce a vnitřní vazby software a zasahovat do něj.

10 POJIŠTĚNÍ

10.1 Zhotovitel se zavazuje udržovat v platnosti po celou dobu trvání závazkového právního vztahu založeného touto Smlouvou a Servisní smlouvou pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou v souvislosti s výkonem činností, které jsou předmětem této Smlouvy a Servisní smlouvy, s limitem pojistného plnění nejméně ve výši ceny Díla dle čl. 3.1, a to ze všech pojistných událostí vzniklých v 1 pojišťovacím roce v souvislosti s touto Smlouvou a Servisní smlouvou. Maximální výše spoluúčasti Xxxxxxxxxxx pro každou pojistnou událost nesmí přesahovat částku 100.000 Kč. Ve vztahu k pojištění dle tohoto Článku 10 (Pojištění) Zhotovitel zajistí, že v případě vzniku pojistné události bude pojistné plnění placeno přímo Objednateli.

10.2 Zhotovitel nemůže snížit výši pojistného krytí nebo podstatným způsobem s negativními důsledky pro Objednatele změnit podmínky pojistné smlouvy dle Článku 10.1 bez předchozího souhlasu Objednatele.

10.3 Zhotovitel je povinen do 15 dnů od účinnosti této Smlouvy předložit Objednateli platnou a účinnou pojistnou smlouvu dle Článku 10.1, nebo pojistku ve smyslu § 2775 Občanského zákoníku či jiný pojistný certifikát. Zhotovitel je povinen na žádost Objednatele předložit dokumenty uvedené v předchozí větě kdykoliv v průběhu trvání této Smlouvy a Servisní smlouvy, a to vždy nejpozději do 14 dnů ode dne doručení žádosti Objednatele.

10.4 Jestliže Zhotovitel nebude udržovat pojištění dle tohoto Článku 10 (Pojištění) v platnosti nebo nepředloží Objednateli včas doklady dle Článku 10.3, může Objednatel v takovém případě svým jménem sjednat a udržovat pojištění ve stejném rozsahu a pokrývající stejná rizika jako pojištění, které měl zajistit Zhotovitel, platit pojistné a započíst platbu za pojistné vůči

jakýmkoliv peněžním nárokům Zhotovitele vyplývajícím z této Smlouvy nebo Servisní smlouvy. Ustanovení tohoto Článku 10.4 není na újmu jiným nárokům a oprávněním Objednatele stanoveným v této Smlouvě nebo Servisní smlouvě.

10.5 Pojištění dle tohoto Článku 10 (Pojištění) slouží společně jako pojištění pro tuto Smlouvu i pro Servisní smlouvu. Účinnost tohoto Článku 10 (Pojištění) neskončí před zánikem smluvního vztahu založeného Servisní smlouvou.

11 ÚČAST PODDODAVATELŮ

11.1 Zhotovitel k plnění části předmětu této Smlouvy smí využít třetí osobu realizující subdodávky pro Zhotovitele v souvislosti s touto Smlouvou („Poddodavatel“). V Příloze č. 4 [Poddodavatelé] jsou uvedeni Poddodavatelé, které Zhotovitel využije k provedení Díla, včetně informací o konkrétním plnění a konkrétní Fázi, pro které budou příslušní Poddodavatelé využiti. Realizací subdodávek se rozumí i poskytnutí oprávnění (např. licence) Objednateli ze strany třetích osob.

11.2 Zhotovitel v plném rozsahu odpovídá za zapojení a činnost Poddodavatelů. Ohledně práv a povinností Poddodavatelů, jejich zaměstnanců, členů a členů statutárního orgánu se dále obdobně použijí ustanovení Smlouvy o právech a povinnostech Zhotovitele a členů Realizačního týmu podle Článku 12.

11.3 Využití nového Poddodavatele, změnu Poddodavatele nebo rozsahu jeho využití musí předem odsouhlasit Objednatel, který je oprávněn toto odmítnou pouze v odůvodněných případech.

11.4 Poddodavatelé, jejichž prostřednictvím Zhotovitel prokazoval kvalifikaci ve Veřejné zakázce, musí Zhotovitel využívat při plnění této Smlouvy po celou dobu jejího trvání v rozsahu, v jakém jimi prokazoval kvalifikaci, ledaže dojde ke změně Poddodavatele. Poddodavatele, xxxxx Xxxxxxxxxx prokazoval kvalifikaci ve Veřejné zakázce, lze vyměnit, pouze pokud budou nahrazeni osobami splňujícími kvalifikaci požadovanou ve Veřejné zakázce a další kritéria pro hodnocení v rámci Zadávacího řízení nejméně ve stejném rozsahu jako nahrazovaní Poddodavatelé.

12 REALIZAČNÍ TÝM A KONTAKTNÍ OSOBY

12.1 Zhotovitel provede Dílo prostřednictvím členů Realizačního týmu uvedených v Příloze č. 3 [Realizační tým a Kontaktní osoby] tak, aby jednotliví členové Realizačního týmu prováděli činnosti na pozicích dle jejich odbornosti (role) uvedené v Příloze č. 3 [Realizační tým a Kontaktní osoby] a v rozsahu, který těmto rolím běžně odpovídá.

12.2 Využití nového člena Realizačního týmu, změnu člena Realizačního týmu nebo rozsahu jeho využití musí předem odsouhlasit Objednatel.

12.3 Při změně Realizačního týmu není nutné uzavírat písemný dodatek ke Smlouvě a Zhotovitel po změně Realizačního týmu vypracuje a předá Objednateli v podobě elektronického dokumentu aktualizované znění Přílohy č. 3 [Realizační tým a Kontaktní osoby], čímž dojde automaticky k jejímu nahrazení novým zněním.

12.4 Každý člen Realizačního týmu zejména musí:

(a) podílet se na provádění Díla v rozsahu odpovídajícím své roli,

(b) dle své role a zapojení na provádění Díla se osobně zúčastnit všech porad a jednání (včetně online jednání) se zástupci Objednatele v rámci provádění Díla či jeho části nebo v rámci plnění prováděném Zhotovitelem v rámci Díla, a adekvátně reagovat na dotazy Objednatele,

(c) v rámci své role efektivně komunikovat s Objednatelem, resp. s Kontaktními osobami Objednatele za účelem včasného a bezvadného provádění Díla,

(d) a postupovat v rámci svých pracovních povinností dle nejlepšího vědomí, tak aby byl co nejlépe naplněn účel Smlouvy.

12.5 Zhotovitel musí bezodkladně, nejpozději však do 10 pracovních dnů, nahradit člena Realizačního týmu na odůvodněnou žádost Objednatele v případě, že člen Realizačního týmu neplní své povinnosti podle této Smlouvy nebo svou činností způsobil Objednateli újmu.

12.6 Strany si pro vzájemnou komunikaci ohledně této Smlouvy zvolily kontaktní osoby a pro některé konkrétní úkony v rámci vzájemné komunikace další osoby („Kontaktní osoby“), jejichž seznam je uveden v Příloze č. 3 [Realizační tým a Kontaktní osoby].

12.7 Každá Strana oznámí druhé Straně jakékoliv změny v Kontaktních osobách, jiných osobách stanovených v Příloze č. 3 [Realizační tým a Kontaktní osoby], kontaktních údajích nebo bankovních údajích uvedených v záhlaví této Smlouvy, přičemž taková změna je účinná dnem následujícím po jejím skutečném doručení bez nutnosti uzavření dodatku k této Smlouvě, není-li v této Smlouvě stanoveno jinak.

13 OCHRANA DŮVĚRNÝCH INFORMACÍ

13.1 Informace, které se Strany dozvědí v souvislosti s touto Smlouvou nebo jejím plněním, mohou být považovány za důvěrné („Důvěrné informace“), pokud je za důvěrné označí Smlouva nebo pokud si strany bezodkladně sdělí, že určitou informaci považují za důvěrnou.

13.2 Strany nesdělí Xxxxxxx informace třetí osobě, budou s nimi nakládat jako s obchodním tajemstvím, zejména uchovávat je v tajnosti, a učiní veškerá smluvní a technická opatření zabraňující jejich zneužití či prozrazení třetím osobám. Ustanovení předchozí věty se nevztahuje na případy, kdy:

(a) Důvěrné informace mají být Objednatelem zpřístupněny na základě právního předpisu včetně práva EU nebo závazného rozhodnutí oprávněného orgánu veřejné moci;

(b) Důvěrné informace druhé Strany sdělí osobám, které mají ze zákona stanovenou povinnost mlčenlivosti;

(c) Důvěrné informace druhé Strany sdělí Poddodavatelům, je-li to nezbytné k plnění této Smlouvy a zavážou-li se takové osoby mlčenlivostí ve stejném rozsahu jako Strany;

(d) se takové Důvěrné informace stanou veřejně známými či dostupnými jinak než porušením povinností vyplývajících z tohoto Článku 13 (Ochrana Důvěrných informací);

(e) se jedná o Důvěrné informace, k nimž Objednatel nabyl oprávnění dle této Smlouvy nevylučující poskytnutí Důvěrných informací třetím osobám; nebo

(f) Strana dá ke zpřístupnění konkrétní vlastní Důvěrné informace souhlas.

14 ZÁRUKA A PRÁVA Z VADNÉHO PLNĚNÍ

14.1 Zhotovitel uděluje Objednateli záruku za jakost Díla a jednotlivých výstupů Fází po dobu 5 let ode dne provedení Díla („Záruční doba“) pokud není v příloze č. 1 uvedeno něco jiného.

14.2 Zhotovitel odpovídá za vady zjevné, skryté i právní, které má Dílo v době provedení Díla (tzn. v době podpisu Závěrečného akceptačního protokolu), a dále za ty, které se na něm vyskytnou v Záruční době. Strany pro zamezení pochybnostem prohlašují, že po dobu trvání Servisní smlouvy budou vady odstraňovány v rámci Servisní smlouvy a za podmínek v ní sjednaných pro Služby podpory, tzn. že Zhotovitel odstraní jednotlivé vady ve lhůtách uvedených v bodu 2 Přílohy A Servisní smlouvy. Zhotovitel je povinen vady odstranit ve lhůtách dle předchozí věty

i v případě, že v době Záruční doby Servisní smlouva nebude účinná nebo závazek založený Servisní smlouvou zanikne.

15 NÁROK NA NÁHRADU ÚJMY

15.1 Zhotovitel nahradí Objednateli prokazatelnou újmu případně vzniklou na základě ztráty či poškození dat v důsledku činnosti Zhotovitele, a to vše včetně regresní náhrady případných přiznaných nároků třetích osob vůči Objednateli. To neplatí, došlo-li k daným důsledkům výhradně činností Objednatele nebo osob Objednatelem pověřených, případně jiných dodavatelů Objednatele.

15.2 Za okolnost vylučující povinnost k náhradě újmy se nepovažuje jakékoliv prodlení s plněním povinností smluvních partnerů Zhotovitele, stávka zaměstnanců Zhotovitele a jeho smluvních partnerů, jakož i úpadek, likvidace či jiná obdobná událost týkající se Zhotovitele nebo jakéhokoliv smluvního partnera Xxxxxxxxxxx a exekuce majetku Xxxxxxxxxxx nebo jakéhokoliv smluvního partnera Xxxxxxxxxxx. Strana se zavazuje druhou Stranu informovat o tom, že nastala okolnost vylučující povinnost k náhradě újmy, bez zbytečného odkladu poté, co bude objektivně možné takovouto komunikaci uskutečnit.

16 SMLUVNÍ POKUTY

16.1 Aniž by byla dotčena práva Objednatele podle Článku 17 (Ukončení smluvního vztahu), vzniká Objednateli vůči Zhotoviteli právo na zaplacení smluvní pokuty v následujících případech:

(a) poruší-li Zhotovitel svoji povinnost řádně a včas předat všechny výstupy Fáze tak, aby byla Fáze dokončena do konce doby pro provedení Fáze stanovené v Harmonogramu, musí Zhotovitel uhradit Objednateli smluvní pokutu ve výši 5.000,- Kč za každý započatý den prodlení s dokončením konkrétní Fáze;

(b) předá-li Zhotovitel k Akceptačnímu řízení výstup Fáze 1, 2, který není způsobilý k akceptaci (Čl. 6.3) pro Vady kategorie A, musí Zhotovitel uhradit Objednateli smluvní pokutu ve výši 50.000,- Kč za každý jednotlivý případ;

(c) bude-li Zhotovitel v prodlení s odstraněním vad uvedených Objednatelem ve výhradách v Akceptačním protokolu, musí Zhotovitel uhradit Objednateli smluvní pokutu ve výši 5.000,- Kč za každý započatý den prodlení s odstraněním vady;

(d) za každé jednotlivé porušení povinnosti chránit Důvěrné informace dle Článku 13.2 je porušující Strana povinna zaplatit druhé Straně smluvní pokutu ve výši 10.000,- Kč, přičemž toto ujednání o smluvní pokutě je účinné do uplynutí 5 let ode dne ukončení této Smlouvy nebo Servisní smlouvy (jako celku) podle toho, která z nich bude ukončena později;

(e) poruší-li Zhotovitel povinnost udržovat v platnosti pojištění dle Článku 10 (Pojištění) musí uhradit Objednateli za toto porušení smluvní pokutu ve výši 50.000,- Kč za každé zjištěné porušení této povinnosti;

(f) poruší-li Zhotovitel povinnost chránit Osobní údaje v souladu s Přílohou č. 5 [Ochrana osobních údajů], vzniká Objednateli nárok na zaplacení smluvní pokuty ve výši 10.000,- Kč za každé zjištěné porušení této povinnosti;

(g) za porušení jakékoli jiné povinnosti Zhotovitele (než jsou povinnosti uvedené shora v tomto Článku 16.1) vyplývající z této Smlouvy smluvní pokutu ve výši 10.000,- Kč za každé takové porušení.

16.2 Právo na zaplacení smluvních pokut dle této Smlouvy nevzniká v případě, že je porušení povinnosti Zhotovitele či prodlení s plněním povinnosti Zhotovitele způsobené:

(a) neposkytnutím součinnosti Objednatelem včas v souladu s touto Smlouvou nebo jiným prodlením Objednatele;

(b) okolnostmi vylučujícími povinnost k náhradě újmy dle § 2913 odst. 2 Občanského zákoníku;

(c) porušením povinností Objednatele; nebo

(d) stanoví-li tak tato Smlouva.

16.3 Zaplacením smluvní pokuty není dotčeno právo poškozené Strany domáhat se náhrady újmy v plném rozsahu.

16.4 Smluvní pokuty, na jejichž zaplacení vznikne oprávněné Straně nárok v souladu s touto Smlouvou, nepřekročí v součtu celkem částku odpovídající Ceně Díla. Ustanovení tohoto Článku 16.4 není a nemůže být vykládáno jako omezení výše náhrady újmy.

16.5 Pokud v důsledku porušení povinností Zhotovitele stanovených touto smlouvou nebude Objednateli uhrazen finanční podíl nebo jeho část z Integrovaného regionálního operačního programu na projektu „Automatizace procesů města Zábřeh“, reg. č. CZ.06.01.01/00/22_008/0000512 bude Zhotovitel povinen uhradit Objednateli takto způsobenou škodu (celý podíl z Integrovaného regionálního operačního programu na projektu týkajícího se tohoto díla ve výši, kterou vyčíslí Objednatel a písemně sdělí Zhotoviteli).

16.6 Nesplní-li Zhotovitel své závazky stanovené v čl. 4.1. této Smlouvy a Objednateli v důsledku toho vznikne škoda (např. uhrazením sankcí uložených příslušným finančním úřadem v důsledku pozdní úhrady DPH u prací a dodávek podléhajících režimu přenesené daňové povinnosti), bude Zhotovitel povinen objednateli tuto škodu v plném rozsahu uhradit.

16.7 Splatnost smluvních pokut činí 10 dnů ode dne doručení výzvy k její úhradě.

17 UKONČENÍ SMLUVNÍHO VZTAHU

17.1 Tato Smlouva a Servisní smlouva jsou vzájemně závislými smlouvami. Zánik této Smlouvy jiným způsobem než splněním, nebo neplatnost této Smlouvy způsobuje zánik Servisní smlouvy, a to s obdobnými právními účinky. Zánik nebo neplatnost Servisní smlouvy však nemá za následek zánik této Smlouvy.

17.2 Smlouvu je možné ukončit dohodou Stran, výpovědí či odstoupením od Xxxxxxx.

17.3 Objednatel může vypovědět Xxxxxxx bez uvedení důvodu s výpovědní dobou 3 měsíce, která počíná běžet prvním dnem měsíce následujícího po doručení písemné výpovědi Zhotoviteli. Ustanovení Článku 18 (Vypořádání v případě zániku smluvního vztahu) se užijí přiměřeně. Zhotovitel nesmí vypovědět tuto Smlouvu dříve než po uplynutí 5 let od okamžiku spuštění plného provozu (tj. Fáze 3). Po uplynutí 5 let od okamžiku spuštění plného provozu (tj. Fáze 3) může Zhotovitel vypovědět Xxxxxxx bez uvedení důvodu s výpovědní dobou 3 měsíce, která počíná běžet prvním dnem měsíce následujícího po doručení písemné výpovědi Objednateli.

17.4 Strany mohou odstoupit od Smlouvy ze zákonných důvodů nebo v případech stanovených touto Smlouvou.

(a) Odstoupení od této Smlouvy je účinné a Xxxxxxx zaniká dnem doručení písemného odstoupení druhé Straně, není-li v odstoupení stanoveno pozdější datum. Od Smlouvy jako celku je možné odstoupit pouze s účinky ex nunc (do budoucna), jinak v souladu s touto Smlouvou.

(b) Strany se dohodly na vyloučení použití § 1978 odst. 2 Občanského zákoníku, který stanoví, že marné uplynutí dodatečné lhůty stanovené k plnění má za následek odstoupení od této Smlouvy bez dalšího.

17.5 Odstoupení od Smlouvy Objednatelem. Objednatel může odstoupit od této Smlouvy zejména v případě, že:

(a) Zhotovitel je v prodlení s provedením Díla či s dokončením jakékoliv Fáze Díla déle než 5 dnů a nezjedná nápravu ani do 10 dnů od doručení písemného oznámení Objednatele o takovém prodlení;

(b) Zhotovitel poruší svoji povinnost předložit doklad o pojištění do 15 dnů od účinnosti této Smlouvy dle věty první Článku 10.3;

(c) Zhotovitel poruší kteroukoli svoji povinnost dle této Smlouvy podstatným způsobem;

(d) Zhotovitel poruší kteroukoli svoji povinnost dle této Smlouvy jiným než podstatným způsobem a nezjedná nápravu ani v dodatečné přiměřené lhůtě po doručení písemného oznámení Objednatele o takovém prodlení, přičemž daná lhůta nebude kratší než 15 dnů;

(e) Zhotovitel podá insolvenční návrh jako dlužník ve smyslu § 98 Insolvenčního zákona, nebo insolvenční soud nerozhodne o insolvenčním návrhu na Zhotovitele do šesti (6) měsíců od zahájení insolvenčního řízení, nebo insolvenční soud vydá rozhodnutí o úpadku zhotovitele ve smyslu § 136 Insolvenčního zákona;

(f) je přijato rozhodnutí o povinném nebo dobrovolném zrušení Zhotovitele (vyjma případů sloučení nebo splynutí);

(g) okolnost vylučující povinnost k náhradě újmy kterékoli ze Stran trvá déle než 90 dnů;

(h) Zhotovitel či Poddodavatel je nebo se v průběhu účinnosti Xxxxxxx stane osobou, na kterou se vztahuje zákaz zadání veřejné zakázky dle § 48a ZZVZ;

(i) nastala změna uvedená v Článku 21.3.

17.6 Odstoupení od Xxxxxxx Xxxxxxxxxxxx. Zhotovitel může odstoupit od této Smlouvy pouze v případě jejího podstatného porušení, jestliže:

(a) Objednatel nezaplatil jakoukoli dlužnou částku za provedení Díla dle této Smlouvy řádně a včas a toto porušení nenapravil ani do třiceti (30) dnů ode dne obdržení písemné výzvy k nápravě;

(b) Objednatel poruší jinou povinnost dle této Smlouvy podstatným způsobem a ve lhůtě třiceti

(30) dnů ode dne obdržení písemné výzvy k nápravě toto své porušení nenapraví.

17.7 Vznikne-li Objednateli právo odstoupit od této Smlouvy, může podle své volby odstoupit od této Smlouvy v celém rozsahu či jen od některé části Díla určené Objednatelem.

17.8 Přetrvávající ustanovení. Zánik smluvního vztahu založeného touto Smlouvou nemá vliv na ustanovení této Smlouvy, která dle své povahy mají trvat i po jejím ukončení, zejména Články 8 (Práva duševního vlastnictví), 9 (Zdrojový kód), 10 (Pojištění), 13 (Ochrana Důvěrných informací), 14 (Záruka a práva z vadného plnění), 15 (Nárok na náhradu újmy), 16 (Smluvní pokuty), 18 (Vypořádání v případě zániku smluvního vztahu), 19 (Komunikace Stran), 20 (Kontrola provádění Díla a opatření dle ZKB), 21.2 (Ochrana osobních údajů), 22 (Rozhodné právo a řešení sporů), 23 (Závěrečná ustanovení) a tento Článek 17.8.

18 VYPOŘÁDÁNÍ V PŘÍPADĚ ZÁNIKU SMLUVNÍHO VZTAHU

18.1 V případě zániku smluvního vztahu založeného touto Smlouvou může Objednatel:

(a) vrátit veškeré či pouze některé dodané výstupy Fází Zhotoviteli; nebo

(b) ponechat si veškeré či pouze některé dodané výstupy Fází

18.2 a to bez ohledu na to, zda již byl daný výstup Fáze akceptován.

18.3 Rozhodne-li se Objednatel vrátit výstupy Fází, musí je vrátit bez zbytečného odkladu.

18.4 Za výstupy Fází, ke kterým Objednatel uplatní své právo na ponechání si výstupů Fází podle Článku 18.1(b), má Zhotovitel nárok na zaplacení části Ceny pouze v rozsahu, ve kterém má Objednatel z předmětného nevráceného výstupu Fáze prospěch.

18.5 V rámci provádění činností Zhotovitelem souvisejících s vypořádáním v případě zániku smluvního vztahu musí Zhotovitel postupovat tak, aby Objednateli nevznikaly nedůvodné náklady, nebyly prováděny činnosti, které jsou pro Objednatele ekonomicky nevyužitelné a byly prováděny pouze takové činnosti, které směřují k zakonzervování hotových výstupů Fází pro jejich případné další využití Objednatelem, například za účelem dokončení Díla jiným dodavatelem.

18.6 V případě zániku smluvního vztahu založeného touto Smlouvou Strany sjednají dohodu o vypořádání vzájemných nároků.

18.7 V případě zániku smluvního vztahu založeného touto Smlouvou nesmí Zhotovitel nadále užívat a musí dle pokynů Objednatele zlikvidovat nebo Objednateli vrátit veškeré přihlašovací údaje do IT prostředí a jakékoliv další údaje obdobného typu, včetně osobních údajů.

19 KOMUNIKACE STRAN

19.1 Veškerá komunikace mezi Objednatelem a Zhotovitelem bude probíhat v českém jazyce. Dokumentaci poskytne Zhotovitel Objednateli v českém jazyce, nestanoví-li Smlouva jinak nebo nesjednají-li Strany v daném případě jinak.

19.2 Není-li v této Smlouvě stanovena jiná forma pro doručování dokumentů nebo jiných právních jednání, lze takové dokumenty a jednání doručit v elektronické formě na e-mailovou adresu příslušné Kontaktní osoby, na adresu elektronické podatelny Objednatele, prostřednictvím datové zprávy zaslané v rámci ISDS nebo v listinné podobě na adresu uvedenou v záhlaví.

19.3 Komunikace mezi Stranami bude probíhat a právní jednání ve vztahu k této Smlouvě budou Strany činit písemně, pokud Xxxxxxx nestanoví jinak.

19.4 Dokumenty v elektronické formě obsahující právní jednání ve vztahu k této Smlouvě podepíše Zhotovitel uznávaným elektronickým podpisem založeným na kvalifikovaném certifikátu a Objednatel kvalifikovaným elektronickým podpisem.

20 KONTROLA PROVÁDĚNÍ DÍLA A DALŠÍ OPATŘENÍ DLE ZÁKONA O KYBERNETICKÉ BEZPEČNOSTI

20.1 Zhotovitel bude při provádění Díla dodržovat zásady bezpečnosti informací, bezpečnostní opatření dle vyhlášky č. 82/2018 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů, a dle interních předpisů, rozhodnutí či jiné pokyny Národního úřadu pro kybernetickou a informační bezpečnost v souladu se zákonem č. 181/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů („ZKB“), včetně upozorňování a zajištění hlášení kybernetických bezpečnostních incidentů a událostí; Zhotovitel musí zaslat bezodkladně Objednateli vyplněný formulář hlášení kybernetického bezpečnostního incidentu a události, aby ten mohl splnit svou ohlašovací povinnost dle ZKB.

20.2 Zhotovitel musí poskytnout Objednateli veškerou součinnost nezbytnou k tomu, aby Objednatel řádně naplňoval právní povinnosti stanovené ZKB a Vyhláškou o kybernetické bezpečnosti. Zhotovitel musí zejména poskytnout Objednateli součinnost směřující k zavedení a provádění bezpečnostních opatření podle uvedených právních předpisů a interními předpisy, zejména, nikoliv však výlučně, bezpečnostní politiky Objednatele.

20.3 Objednatel může prostřednictvím určených osob kdykoli provést audit dodržování bezpečnosti informací dle bezpečností dokumentace, ZKB a Vyhlášky o kybernetické bezpečnosti u Zhotovitele, a to i prostřednictvím třetí osoby. V rámci kontroly a auditu může Objednatel zejména porovnávat zjištěné skutečnosti s procesními standardy, které jsou sjednány v této Smlouvě nebo byly uvedeny v nabídce Zhotovitele. Nejsou-li takové procesní standardy, může být porovnání uskutečněno vůči obvykle uznávaným procesním standardům, vždy však v souladu s bezpečnostní politikou Objednatele.

21 OSTATNÍ UJEDNÁNÍ

21.1 Strany se dohodly, že:

(a) Zhotovitel nemůže postoupit jakékoliv své pohledávky z této Xxxxxxx na třetí osobu bez předchozího souhlasu Objednatele, a to ani částečně.

(b) Objednatel může kdykoli započíst jakékoli své pohledávky za Xxxxxxxxxxxx proti pohledávce Xxxxxxxxxxx. Zhotovitel si může započíst své pohledávky za Objednatelem proti pohledávce Objednatele výlučně na základě dohody Stran.

(c) Xxxxxxxxxx nemůže jakkoli zastavit jakékoli své pohledávky za Objednatelem vyplývající z této Smlouvy.

21.2 Podmínky ochrany a zpracování osobních údajů Strany upravily v Příloze č. 5 [Ochrana osobních údajů].

21.3 Dojde-li k přeměně společnosti Zhotovitele či poddodavatele, ke změně jeho vlastnické struktury nebo ke změně podílu na hlasovacích právech ve společnosti Zhotovitele či poddodavatele, zejména změny týkající se skutečného majitele Zhotovitele či poddodavatele ve smyslu zákona č. 37/2021 Sb., o evidenci skutečných majitelů, je Zhotovitel povinen neprodleně písemně oznámit tuto skutečnost Objednateli, nejpozději však do 5 dnů od zápisu této změny ve veřejném rejstříku. Objednatel je v tomto případě oprávněn od Smlouvy odstoupit.

22 ROZHODNÉ PRÁVO A ŘEŠENÍ SPORŮ

22.1 Tato Smlouva se řídí a bude vykládána v souladu s právním řádem České republiky. Obchodní zvyklosti nemají přednost před žádnými ustanoveními zákona, a to ani před ustanoveními zákona, jež nemají donucující účinky.

22.2 Strany budou řešit veškeré spory, které mezi nimi mohou vzniknout v souvislosti s prováděním nebo výkladem této Smlouvy, jednáním a vzájemnou dohodou.

22.3 Dojde-li mezi Stranami ke sporu

- ohledně kategorizace vad v rámci Akceptačního řízení,

- týkajícího se akceptace některého z výstupů kterékoli Fáze,

- souvisejícího s předmětem plnění dle Xxxxxxx, který má či by mohl mít dopad na dodržení Harmonogramu,

uskuteční Smluvní strany nejpozději do 5 pracovních dnů od vzniku sporu osobní schůzku osob oprávněných za Strany k podpisu této Smlouvy, a to za účelem vyřešení vzniklého sporu („Eskalační proces“).

22.4 Pokud se Stranám nepodaří vyřešit předmětný spor, bude předložen jednou ze Stran obecnému soudu Objednatele.

23 ZÁVĚREČNÁ USTANOVENÍ

23.1 Smlouva nabývá platnosti dnem podpisu oběma Stranami a účinnosti dnem jejího uveřejnění v registru smluv ve smyslu zákona č. 340/2015 Sb., o registru smluv („ZRS“). Uveřejnění v registru smluv zajistí Objednatel. Zhotovitel výslovně souhlasí s uveřejněním Smlouvy a údajů v ní uvedených v registru smluv.

23.2 Tato Smlouva může být měněna pouze písemnými vzestupně číslovanými dodatky, podepsanými k tomu oprávněnými zástupci obou Stran.

23.3 Strany vylučují použití § 1740 odst. 3 Občanského zákoníku, který stanoví, že smlouva je uzavřena i tehdy, kdy nedojde k úplné shodě projevů vůle Stran.

23.4 Neplatnost či nicotnost kterékoliv části této Smlouvy nemá vliv na platnost Smlouvy jako celku. Strany nahradí neprodleně neplatné či nicotné ustanovení ustanovením platným; obdobně budou postupovat v případě ostatních nedostatků této Smlouvy či souvisejících ujednání.

23.5 Žádné nevyužití nebo opominutí nároku nebo práva vyplývajícího z této Smlouvy nebude vykládáno jako vzdání se nároku nebo práva, pokud tak nebude učiněno výslovně. Pokud není v této Smlouvě uvedeno jinak, práva a nápravné prostředky upravené v této Smlouvě lze uplatnit souběžně a nevylučují žádná práva ani nápravné prostředky, na něž vzniká právo z právních předpisů.

23.6 Zhotovitel se zavazuje k dodržování mezinárodních sankcí Evropské unie, přijatých v souvislosti s ruskou agresí na území Ukrajiny vůči Rusku a Bělorusku, zejména nařízení Rady EU č. 2022/576, nařízení Rady (EU) č. 269/2014 ve spojení s prováděcím nařízením Rady (EU) č. 2022/581, nařízení Rady (EU) č. 208/2014 a nařízení Rady (ES) č. 765/2006 nebo v jejich prospěch (dále jen „mezinárodní sankce EU“).

23.7 Xxxxxxx je podepsána v souladu s podmínkami 134/2016 Sb., elektronicky.

23.8 Rada města Zábřeh schválila uzavření této smlouvy na svém 24. jednání dne 27. 2. 2024 usnesením č. 24/RM/24/OI/5496.

23.9 Přílohy, na něž text této Smlouvy odkazuje a jejichž seznam je k této Smlouvě přiložen, tvoří nedílnou součást této Smlouvy. Jedná se o tyto přílohy:

Příloha č. 1 – Technická a věcná specifikace Příloha č. 2 – Akceptační řízení

Příloha č. 3 – Realizační tým a Kontaktní osoby Příloha č. 4 – Poddodavatelé

Příloha č. 5 – Ochrana osobních údajů Příloha č. 6 – Vzor Předávacího protokolu Příloha č. 7 – Vzor Akceptačního protokolu

Příloha č. 8 – Zadávací dokumentace (bez příloh)

Objednatel

V Zábřehu dne dle data el. podpisu

Zhotovitel

V Praze dne dle data el. podpisu

…......................................................................

město Zábřeh

RNDr. Mgr. Xxxxxxxxx Xxxx, PhD.

…......................................................................

Orchitech Solutions, s.r.o.

Xxx. Xxxxxx Xxxxx, MBA

Strany prohlašují, že si tuto Smlouvu přečetly, že s jejím obsahem souhlasí, a na důkaz toho k ní připojují svoje podpisy.

Příloha č. 1 - Technická a věcná specifikace

1 SYSTÉM AUTOMATIZACE NASTAVENÍ PRÁV A PORTÁL IDENTIT

Zadavatel požaduje zavedení platformy Identity and Access Managementu (dále jen IAM), který zajistí centralizovanou správu identit a jejich oprávnění.

Přínosy řešení IAM Usnadnění práce uživatelům:

1. Přehled o identitě - Jednoduchá nástěnka v IAM, kde vidím základní informace o své identitě, přidělených přístupech a všech úkolech (pro schválení nebo vykonání nějakého požadavku), které mám v IAM řešit.

2. Včasné nástupy - automatizace procesu nástupu nového zaměstnance umožní rychlejší onboarding zaměstnanců. Aktuálně je tento proces dobře popsán, i tak ale může trvat i týden.

3. Usnadnění odchodů - centrální evidence přístupů umožní jednodušší odebírání přístupů při odchodu. Cílem je co nejvíce digitalizovat odchod například zjednodušením výstupního listu - odstraněním položek, které může IAM řešení automaticky zajistit.

Usnadnění práce IT:

1. Automatizované zakládání/rušení uživatelských účtů - díky tomu dojde k uvolnění rukou administrátorů od rutinních úkolů správy účtů. Zejména proces zakládání nového uživatele je náročný - existuje pro to obsáhlý manuál.

2. Digitalizace procesu přidělování práv - pro řízení přístupů k IT systémům existuje excelová tabulka, která mapuje práva na konkrétní pracovní pozice. Pokud nastupuje nebo mění pracovní pozici zaměstnanec, pak vybraný pracovník úřadu dle této tabulky zajišťuje aktualizaci přístupů k IT systémům. Cílem je tuto agendu digitalizovat do automatického přidělování přístupů dle pozic.

3. Větší zastupitelnost pracovníků IT díky standardizovaným procesům.

Zvýšení bezpečnosti

1. Zamezení existence nepoužívaných účtů - automatizace procesu odchodu zaměstnance povede k eliminaci existence nepoužívaných účtů.

2. Zvýšení kvality dat - Minimalizace chyb v datech způsobených ručním zásahem.

3. Efektivní a pravidelný audit přístupů - IAM umožní centrální pohled na identity a jejich účty. Kontrola přístupů a příprava podkladů pro bezpečnostní audit bude značně jednodušší a časově méně náročná.

4. Plnění budoucích bezpečnostních legislativních požadavků. Např. NIS2

5. Zabránění kumulace práv - Centrální správa umožní pravidelnou recertifikaci (přeschválení přístupů).

2 SYSTÉMOVÉ POŽADAVKY

● Řešení bude dodáno jako připravená dávka spustitelná na virtualizační platformě .

● Řešení nesmí pro svůj provoz vyžadovat jiné SW prostředky (například LDAP, DB, webserver apod.) než ty, které jsou součástí dodané dávky. Výjimkou jsou služby pro notifikace (SMTP server pro odesílání pošty nebo SMS brána) či běžné služby prostředí zadavatele jako SIEM, logmanager, monitoring apod…

● Veškerá komunikace dodaného řešení s ostatními systémy je šifrovaná

3 LICENCE

● Licence systému pro správu identit musí pokrývat potřebný počet identit v celé organizaci (zaměstnanci i externisté), tj. 250 identit.

● Systém pro správu Identit bude možné provozovat v produkční a dalších (testovacích) instancích bez potřeby pořízení dalších licencí produktu.

● Dodavatel se zaručuje, že v dodávce jsou zahrnuty případné nezbytné licence třetích stran a používání díla jako celku nevyžaduje žádné další dodatečné licenční náklady.

● Licence musí opravňovat zadavatele k tomu, aby:

o Využíval dílo v rámci své činnosti po definovanou dobu nejméně 5 let

o Sám nebo prostřednictvím třetích osob mohl rozšiřovat dílo v souladu se svými potřebami.

4 SPRAVOVANÉ SYSTÉMY

K systému IAM budou integrovány následující systémy objednatele:

1. HR systém FLUX

○ Personální systém je zdrojem dat pro identity manager o identitách (IdM), jejich kontraktech a organizační struktuře, která je také automaticky synchronizována do identity manageru. Z předávaných dat (organizační struktura) bude sestaven v IdM organizační stom, na který budou navázána práva podobně, jako to je nyní definováno v excelovské tabulce pozic a přístupů.

2. MS Active Directory (on-premise) – doména je interně rozdělená po organizačních jednotkách.

○ V rámci napojení bude realizována správa účtů (CRUD) včetně členství v AD skupinách, nastavení a změna hesla, aktivace/deaktivace účtu, nastavení příznaku pro vynucenou změnu hesla při prvním přihlášení, výpočtu vedoucího v atributu

„manager“ a zařazení účtu do organizační jednotky.

○ Automatické pravidelné načítání skupin MS AD do identity manageru

○ Iniciální migrace stavu účtu ve smyslu členství v AD skupinách a párování na identity v identity manageru.

○ Uživatelé se při ukončení kontraktu nemažou, blokují se v MS AD a exchange a smažou se po 2 měsících.

3. MS Exchange – každý zaměstnanec objednatele má emailovou schránku v Exchange

4. e-spis (dodavatel ICZ)

○ Systém e-spis je integrován pro přihlašování uživatelů vůči MS AD doméně skrze kerberos. Je však nutné pro fungování přihlašování tvořit lokální účty. IdM bude spravovat účty v e-spis.

○ Organizační struktura v e-spis odpovídá organigramu HR pouze do určité úrovně. Detailní zařazení uživatele však provádí IT pracovník manuálně na základě znalosti.

○ IdM musí umožnit

i. evidovat více organizačních struktur

ii. zakládat účty do nejbližšího “sběrného” bodu (funkčního místa) v organizační struktuře e-spis a nadále nespravovat organizační zařazení uživatele.

iii. Role v e-spis se přiděluji na funkční místa a přidělení nebude spravovat IdM.

iv. Připravit emailovou šablonu pro nový účet uživatele v e-spis, kde bude popsáno, jaké manuální úkony musí administrátor ještě udělat po automatickém založení nového uživatele z IdM.

○ Smazání uživatele probíhá odebráním z funkčního místa. Uživatele nelze přímo smazat, protože z důvodů integrace e-spis a systému VITA je nutné uživatele mazat nejdříve v systému VITA.

○ e-spis umožnuje správu funkčních míst, která ale zůstane v manuálním režimu, neboť při editaci funkčních míst je potřeba manuálně exportovat data v xml formátu z rozhraní správy funkčních míst do rozhraní správy uživatelů.

5. Helios Fenix (dodavatel Asseco solutions)

○ Systém Fenix je informační systém pro veřejnou správu s modulární architekturou.

○ Přístupy se řídí na úrovni modulů, kterých je cca 20 a jejich počet se v čase nemění. IdM umožní správu přístupu k modulům systému Fenix, pokud to API umožní.

○ Přístupy do systému Fenix se dělí do 2 základních skupin - admin, user. IdM bude toto třídění umožňovat.

○ V poznámce uživatele je udržována informace o odboru/oddělení zaměstnance. IdM bude tuto informaci udržovat.

○ Jednotlivé moduly mají skupiny funkcí a u nich jsou definována práva, ale tuto oblast IdM řídit nebude.

○ Smazání uživatele probíhá odebráním přístupu ke všem modulům Fenix. Pokud to API umožní, lze uvažovat o blokaci či mazání uživatele namísto odebrání přístupu k modulům.

6. FLUX portál (dodavatel Asseco solutions)

○ Jde o zaměstnanecký portál, kam přistupuje většina uživatelů/zaměstnanců, protože zde řeší například žádosti a schvalování dovolených.

○ Založení uživatele probíhá aktuálně lokálně a následně je nutné manuálně provázat nový účet s AD účtem (admin klikne na jedno tlačítko v GUI fluxu). IdM umožní založit lokální účet a pokud to API umožní, tak zajistí i provázání s AD účtem. Pokud to API neumožní, tak založí lokální účet a notifikuje administrátora, aby založení účtu dokončil - mailová šablona s návodem.

7. JIP (rozhraní XXXX)

○ Systém pro jednotný přístup úředníků k agendám státních orgánů.

○ V rámci rozhraní bude IdM řídit životní cyklus účtu a navíc umožní propisování sériového čísla certifikátů vydaných akreditovanou certifikační autoritou.

8. CA post signum

○ IdM umožní stažení veřejné části uživatelského certifikátu, zejména sériové číslo certifikátu, které je důležité pro přístup úředníků do JIP.

○ IdM umožní i manuální nahrání certifikátu do IdM. Například pokud nebude potřebná webová služba České pošty dostupná.

9. Eskon:

○ Jde o docházkový systém provázaný s MS AD.

○ Řízení systému bude probíhat buď skrz lokální účet, pokud to umožní API, nebo alespoň bude IdM předávat doplňující informace o uživatelích skrz MS AD.. Eskon si natahuje informace o zaměstnancích z AD, zejména používá atribut “manager” pro zjištění nadřízeného zaměstnance.

10. Další systémy napojené skrz MS AD skupiny:

○ Nextcloud - cloudové úložstě. Plně integrované s MS AD.

○ Formulářový server

○ XxX - xxxxxxx fronta

○ Moodle - e-learning

11. Další systémy napojené virtuálně - offline:

○ VITA - modulární agendový systém (AIS). Je integrovaný s e-spis. Podporuje zařazení uživatele do odboru.

○ EZS

○ OPNsense

○ Safetica

○ Intranet

5 PROSTŘEDÍ

Řešení bude dodáno nejméně do 2 prostředí. Testovacího prostředí, ve kterém bude probíhat integrace a testovaní řešení dodavatelem a odběratelem a produkčního prostředí pro provoz IAM.

6 TYPY SPRAVOVANÝCH IDENTIT

IAM umožní správu různých typů uživatelů – zaměstnanci, externisté a další. Pro každý typ identity umožní IAM konfiguračně definovat vlastní formulář v GUI pro manuální správu s možností definovat si libovolné atributy – různé pro každý typ identity včetně validátorů vstupu hodnot, unikátnosti.

Zaměstnanci úřadu

Zaměstnanci jsou evidováni v personálním systému. Pokud má zaměstnanec více úvazků, má v rámci organizace zadavatele jednu identitu s více kontrakty (například DPP/DPČ při mateřské dovolené).

Počet aktivních identit zaměstnanců je cca 130.

Městská policie, knihovna a další organizační složky

Jedná se o další zaměstnance města, nejsou to však zaměstnanci přímo úřadu. V MS AD jsou evidování v oddělené OU. Zaměstnanci města jsou evidováni v HR a z pohledu procesů správy identit se neliší. Jde cca do 50 identit.

Uživatelé příspěvkových organizací - např školy

Uživatelé spadající do příspěvkových organizací jsou typicky zaměstnanci škol a dle způsobu správy účtů se chovají jako externisté. Nejsou evidováni v HR města a budou manuálně zavedeni do IdM. Pro příspěvkové organizace bude město nabízet různé IT služby. Jde o cca 20 uživatelů.

Zastupitelé

Jsou evidování v HR systému (dostávají odměny). Z pohledu správy identit mají přístup pouze do jednoho systému pro přípravu materiálů pro jednání rady a zastupitelstva. Přístup k němu získávají skrze MS AD skupinu. V AD jsou evidování v oddělené OU od zaměstnanců úřadu a dalších identit. Jde o 21 uživatelů.

Externisté - dodavatelé

Jedinou skutečně externí identitou, která není evidována v HR, jsou dodavatelé. Je jich cca 30 a typicky mají účet v AD a VPN přístup (openVPN). Jejich evidence a správa bude prováděna v IdM odpovědnou osobou - garantem externistů.

7 UŽIVATELÉ PRACUJÍCÍ V IAM

Webové rozhraní identity manageru zpřístupňuje funkce na základě oprávnění uživatele. Pro prostředí Zákazníka lze počítat nejméně s následujícími typy uživatelů:

1. Administrátor IAM - kontrola běhu, zakládání rolí a přístupů. Provoz a administrátorská podpora IAM. Řeší výjimečné stavy, kontroluje reporting a životní cyklus identit, plně spravuje IAM. Může delegovat svá oprávnění a přidělovat oprávnění s granularitou až na jednotlivé agendy v GUI a datové objekty (identity, role, organizace…)

2. Helpdesk – pracovník helpdesku, který má přístup k informacím o identitách a jejich rolích. Resetuje hesla.

3. Nadřízený – vidí své uživatele, může jim požádat o role, ze své pozice nadřízeného schvaluje přidělení rolí podřízeným.

4. Garant externisty – Spravuje identity a přístupy svěřených externistů

5. Uživatel – samoobsluha pro změnu hesel, informace o svých uživatelských účtech a rolích, žádosti o role, nástěnka pro nejčastější operace a aktuální stav žádostí.

6. Správce off-line systému - realizuje operace (vytvoření, smazání, úprava účtu) na základě mailové notifikace IAM a potvrzuje realizaci požadavku v IAM.

Konkrétní role a jejich oprávnění budou řešeny při implementaci IAM do prostředí zadavatel.

8 ORGANIZAČNÍ STRUKTURA

Organizační struktura je evidována a udržována v personálním systému FLUX. Organizační struktura obsahuje organigram a lze z ní vypočítat podřízenost zaměstnanců.

Organizační struktura bude načítána do IAM a IAM umožní automatické přiřazování rolí na základě zařazení uživatele ve struktuře.

Kromě automatické synchronizace organizační struktury umožní IAM i manuální správu. IAM umožní definovat více organizačních struktur. IAM umožní:

● Vytváření libovolného počtu nezávislých organizačních struktur.

● V rámci každé struktury vytvořit libovolný počet organizačních prvků (stromů)

● Zařazovat uživatele do organizačních struktur (i více struktur v rámci jednoho kontraktu uživatele – například pro pracovní zařazení a účast na projektu)

● Definovat role pro identity v daném stromě

● Vizualizovat strom organizační struktury

● Filtrovat uživatele dle zařazení v organizační struktuře

● Identita může být zařazena ve více stromech.

9 ŽÁDOSTI O ROLE A SCHVALOVACÍ PROCESY

Většina práv bude přidělována automaticky na základě rolí dle organizační struktury.

Žádost o změnu oprávnění může být iniciována jak řadovými pracovníky, tak vedoucími pracovníky. V žádosti o roli je zřetelně vyznačeno, kdo žádá, komu je žádáno, o jaké role, jaké jsou současné role identity a jaké jsou změny rolí (přidané, odebrané, nezměněné).

IAM eviduje všechny žádosti o role v přehledu včetně jejich stavu a schvalovatelů, aby bylo dohledatelné, kdo aktuálně žádost řeší, nebo kdo ji finálně schválil.

Obsahuje-li žádost o roli také role, které zajišťují provisioning (propis dat do řízeného systému), je ihned po schválení žádosti vyvolán propis dat do systémů.

Každá žádost obsahuje evidenci, v jakém stavu se nachází, a to jak z pohledu schválení žádosti, tak z pohledu následné aplikace rolí do řízených systémů – tzn., zda již proběhl propis dat na základě aktuálně změněných rolí v dané žádosti.

Schvalovací workflow je konfigurovatelné v aplikaci, schvalovací kola je možné zapínat a vypínat. U každé role je možné definovat, jakým workflow bude schvalované nebo zda není schvalovaná vůbec. Konfigurace schvalování je dostupná v GUI pro administrátora IAM a změna nevyžaduje restart aplikace.

Administrátor IAM bude mít možnost definovat, o které role v IAM lze žádat a které se nebudou

v žádostech uživatelů nabízet. Takto bude možné některé role načítat například z AD a definovat jejich automatické přidělování, avšak uživatelům se nebudou nabízet (a mást je) v žádostech. Jiným příkladem může být seskupování rolí, kdy uživatelé budou moci žádat o definované skupiny, avšak

z důvodu složitosti se nebudou nabízet dílčí role.

10 PROCESY NÁSTUPŮ, ZMĚN A ODCHODŮ

Nástup zaměstnance

Při nástupu nového zaměstnance zadává personalistka data do HR systému dopředně a cca 14 dní před začátkem kontraktu informuje IT o novém plánovaném nástupu. V den začátku úvazku je zaměstnanci předáno heslo do domény a usb token pro certifikáty. Dále může používat certifikát z interní

certifikační autority pro přihlašování do domény. Pokud uživatel potřebuje kvalifikovaný certifikát, tak si dojde na poštu registrovat se a poté IT stáhne jeho certifikát a nahraje do usb tokenu.

IdM musí poskytnout funkce a podmínky pro nástup uživatele a také pro správu hesel. Zejména se jedná o možnosti:

● použití jednorázového časově omezeného hesla, které si uživatel musí při prvním přihlášení do domény (nebo i jiného systému, který tuto možnost nabízí), změnit.

● Distribuci hesla vhodným způsobem tak, aby heslo nebylo v čitelné podobě dostupné nikomu jinému než je samotný uživatel - například zaslání na sms. Pokud to není z procesních důvodů možné, například uživatelé neposkytují číslo mobilního telefonu, tak alespoň zaslání jednorázového hesla emailem

● Možnost pro uživatele měnit si z IdM hesla do všech systémů centrálně.

V rámci nástupu uživatele požaduje zadavatel zjednodušit a automatizovat proces tak, aby IdM data získávala dopředně a včas notifikovala dotčené administrátory systémů mimo online správu IdM pro založení účtů. Dále IdM bude automaticky zakládat účty dle pracovní pozice zaměstnance. Do IdM bude v rámci projektu importována matice rolí pro jednotlivé pozice v organizačním stromě města.

Vynětí z evidenčního počtu

IdM zautomatizuje tento proces (např. odchod na mateřskou dovolenou) a bude automaticky blokovat či mazat (dle preference a možností každého systému) účty uživatelů na online napojených systémech. Na systémech, které jsou spravovány v offline (virtuální) systému bude informovat dotčené administrátory. Cílem je co nejvíce proces zjednodušit a zautomatizovat. Při návratu do evidenčního počtu (např. návrat z mateřské dovolené) pokračuje uživatel pod stejným osobním číslem a loginem v IT systémech. IdM automaticky vrátí role dle pracovní pozice a nabídne možnost požádat o další přístupy, pokud to bude potřeba.

IdM musím umožnit evidovat druhý aktivní úvazek pod stejnou identitou (např. DPP či DPČ po dobu mateřské dovolené). Role přidělované pod aktivní úvazek však budou jiné než role, které měl uživatel ve své původní pozici, na které je vyňata z evidenčního stavu.

Ukončení uživatele

Výstupní list bude zavedením IdM zjednodušen, neboť IdM zajistí blokaci či smazání účtů v online řízených systémech a také notifikuje dotčené administrátory offline řízených systémů.

Změna pracovní pozice zaměstnance

IdM zjednoduší tento proces. Automaticky aktualizuje uživateli přístupy dle automatických rolí na pracovních pozicích. Certifikáty, HW prostředky a role, které jsou uživateli přiděleny manuálně na pracovní kontrakt nejsou dotčeny.

11 OBECNÉ POŽADAVKY NA UŽIVATELSKÉ ROZHRANÍ

Nabízené řešení musí splňovat následující požadavky:

● Lokalizace uživatelského prostředí nejméně do českého a anglického jazyka

● Jedno srozumitelné webové grafické rozhraní pro všechny uživatele

● Možnost grafického přizpůsobení rozhraní v rozsahu nejméně

o Logo organizace

o Barevný skin grafického rozhraní

o Odkaz na podporu

● Opatření proti útoku hrubou silou na přihlášení do systému; Při pokusu o několikanásobné neúspěšné přihlášení IAM dočasně zablokuje účet a zaeviduje tuto událost do auditu.

● IAM v rámci různých agend – například správy rolí, identit, organizací, systémů – umožní uživatelům jednoduché kontextové prokliky mezi jednotlivými agendami. Například z detailu přidělených rolí u uživatele bude moci přímým proklikem zobrazit detail vybrané přidělené role nebo uživatele, který mu roli schválil (má-li na tyto objekty dostatečná oprávnění

● IAM bude v grafickém rozhraní dynamicky obnovovat zobrazení dat v jednotlivých agendách, aniž by to musel řešit uživatel manuálně. Například když se odbavují požadavky na koncový systém, seznam požadavků ve frontě se postupně zmenšuje.

● IAM nabídne možnost konfigurovat šablony pro odesílané mailové notifikace. Rozhraní správy notifikací a náhledu na odeslané notifikace je v grafickém rozhraní systému. IAM umožní konfiguračně v grafickém rozhraní deaktivovat odesílání emailů se zachováním logování pokusů o odeslání pro kontrolu notifikací. Nejméně je možné upravovat:

▪ a. příjemce

▪ b. předmět a obsah dané notifikace

▪ c. zvolit jazyk notifikace.

o Emailové notifikace je možné definovat ve formátu čistého textu (plaintext) i stylovaného formátu (html). Do html šablony je možné vkládat hodnoty objektů z IAM, jako například login identity, a také odkazy na objekty v IAM – například odkaz na schvalovací úkol nebo odkaz na roli v IAM.

12 ZPŮSOB DODÁNÍ ŘEŠENÍ

Implementace řešení IAM musí splňovat požadavky na rychlé a jednoduchý provoz, nasazení a obnovení v případě potřeby. Je požadované dodat IAM včetně všech závislých SW komponent jako je DB, aplikační server apod., jako jeden balík připravený k nasazení na virtualizační platformu VMWare. Aplikace musí být srozumitelná a přehledná pro koncové uživatele i administrátory.

Pro zabránění vendor locku je požadováno, aby pro dodávaný software byli na českém trhu minimálně čtyři certifikovaní partneři pro implementaci a servis řešení.

13 STANDARDNÍ A OBECNÉ KONEKTORY

Konektory umožní komunikaci IAM s koncovými systémy a umožní jak synchronizaci dat (do IAM), tak provisioning (propis dat do systému). Veškerá komunikace musí probíhat zabezpečeným šifrovaným spojením.

Dodané řešení bude obsahovat nejméně následující konektory. Konektory lze použít pro napojení systémů na synchronizaci dat a řízení účtů bez dalších úprav s výjimkou REST/WS konektoru, kde je třeba doplnit konkrétní volání dle specifikace napojovaného systému. Univerzální skriptované

konektory typu DB, SSH, Powershell budou dodány s příklady skriptů pro CRUD operace řízení účtů v napojeném systému.

● Microsoft Active Directory

● CSV konektor

● REST konektor, Web service konektor

● Powershell konektor (Exchange, AD)

● LDAP konektor (AD, LDAP)

● DB konektor (univerzální skriptovaný konektor)

● Konektor pro offline napojování dalších systémů (virtuální systémy)

IAM umožní jednoduše přidávat další konektory do aplikace. IAM umožní použít konektory běžící mimo dodané řešení například v externích connector serverech.

IAM bude efektivně spravovat spojení na koncové systémy skrze konektory. Například bude udržovat spojení pro systémy, aby nebylo třeba při každé komunikaci navazovat nové spojení. Zároveň bude využívat poolling spojení, aby využilo plného potenciálu počtu spojení na každý systém tak, aby bylo možné co nejvíce paralelizovat veškeré operace vyžadující komunikaci se systémy.

14 OBECNÉ POŽADAVKY NA SYNCHRONIZACI

IAM umožní

● Synchronizaci (provisioning) změn z IAM do řízených systémů v reálném čase s odolností proti výpadkům informačních systémů - vestavěná podpora opakování propagace změn v případě neúspěchu.

● Obousměrná synchronizace dat jak z IAM (provisioning) do koncového systému (např. uživatele a jejich atributy), tak z koncového systému do IAM (např. role v konkrétním koncovém systému).

● Mapování atributů mezi koncovým systémem a IAM na základě transformačních pravidel/vzorců. IAM bude obsahovat knihovnu transformačních pravidel pro běžné napojení atributů jako je displayName (MS AD). IAM nabídne IDE (integrované prostředí pro vývoj) pro rychlou a pohodlnou tvorbu skriptů přímo v grafickém webovém rozhraní IAM.

● Práce s komplexními (tabulky) či binárními atributy uživatele - certifikáty, fotografie, autentizační tokeny

● Nastavení pravidel pro párování mezi identitou a účtem (například email identity na login účtu) skrze všechny koncové systémy.

● Možnost nastavení white-listu účtů, které IAM nikdy nemění (např. pro technické účty);

● Veškeré aktivity synchronizací jsou logovány.

IAM umožní synchronizovat data o identitách, organizačních strukturách, kontraktech, rolích ze zdroje dat (HR, AD, csv, import) jak v režimu

● plné synchronizace – tzn. veškerá data budou autoritativně načtena do IAM

● rozdílové synchronizace – s využitím příznaku časové značky záznamu. Tzn. IAM zpracovává pouze ty záznamy, které mají časovou značku změny ve zdroji dat novější než běh poslední synchronizace IAM.

● Synchronizace všech objektů nebo definice filtru omezení synchronizovaných dat. Například při zavádění IAM bude možné nejdříve vyzkoušet synchronizaci pro jednoho uživatele (vyfiltrovaného například podle příjmení) nebo skupinu uživatelů.

I v případě, že zdroj dat nepodporuje časovou značku změny záznamu (csv import), umožní IAM

v režimu plné synchronizace rozpoznat pouze ty záznamy, které mají v nějakém synchronizovaném atributu změnu, a pouze ty načíst.

Synchronizace dat lze spouštět manuálně z grafického rozhraní nebo plánovaně pomocí grafického plánovače úloh.

IAM umožní v grafickém rozhraní zobrazit stav probíhající synchronizace – zpracované objekty, log chyb, rychlost synchronizace nebo odhad zbývající doby trvání. Výsledek synchronizace je uchováván v auditu a lze zpětně dohledat v grafickém rozhraní veškeré běhy, výsledky a obsah předcházejících synchronizací.

Synchronizace dat lze plánovat v grafickém rozhraní IAM. Synchronizace lze naplánovat na konkrétní čas – například každých den ve 1 hodinu a v 5 hodin. Synchronizace i jiné úlohy lze v plánovači

v grafickém rozhraní zřetězit. Například lze definovat, že synchronizace identit zaměstnanců začne v návaznosti na úspěšné dokončení synchronizace organizační struktury.

15 AUTENTIZACE DO IAM

Přihlášení (SSO) oproti MS Active Directory (tedy přihlášený uživatel do MS AD domény je automaticky zalogován do IAM). V případě, že uživatel přistupující na IAM není v MS AD doméně zaveden, je mu zobrazen přihlašovací formulář, kde se může přihlásit pomocí jména a hesla ověřovanému proti úložišti IAM. V obou případech je operace logována do auditního logu přihlášení.

Řešení umožní autentizaci vůči více systémům s možností definice pořadí, ve kterém se bude autentizace provádět. Například 1 MS AD, 2 IAM.

16 AUTORIZAČNÍ MODEL IAM

Přístup k datům v identity manageru je řízen stejným přístupem – RBAC (role base access control) jako do řízených systémů. Identity manager umožní definovat práva na jednotlivé agendy jako je správa uživatelů, správa systémů, konfigurace IAM a další. Dále bude možné pro každou agendu specifikovat, na jaká data má držitel dané role právo. Například garant externisty může spravovat pouze své externisty. Běžný uživatel, který není vedoucí, může editovat pouze vybrané atributy vlastní identity, zobrazit si může seznam identit v organizaci. Vybraný administrátor může realizovat konkrétní akce jako spustit workflow, vyplnit formulář, schválit požadavek, spustit a prohlédnout report, vidět specifické akce nebo datové objekty, přidělit nebo odejmout oprávnění/roli apod.

● Autorizace v IAM se neliší od ostatních napojených systémů. Oprávnění k jednotlivým objektům a částem v IAM budou definovány v aplikačních/business rolích.

● Autorizace lze nastavovat nejen na jednotlivé části GUI, ale také pomocí filtrů na jakékoliv entity (např. Identity, role, prvky organizační struktury), které splňují nebo naopak nesplňují definované podmínky

● Systém musí podporovat multitenantní přístup z pohledu autorizace. Systém umožní vytvořit administrátorská práva nad určitými organizačními jednotkami, skupinami uživatelů nebo obecně nad definovanými objekty IAM. Účelem je umožnit delegovanému administrátorovi správu uživatelů patřících do samostatného podřízeného celku (například různých úřadů).

o Delegovat správu konkrétních organizací (identit a daného organizačního stromu) v IAM různým administrátorům.

● Nabízené řešení musí umožňovat konfigurovat práva i pro koncové uživatele tak, aby si mohli zobrazit přiřazená oprávnění, přiřazení do organizační struktury, provést schválení přiřazených požadavků a spouštět reporty. Oprávnění dále musí jít nastavit až na úroveň jednotlivých atributů (například, uživatel může editovat pouze atribut osobního telefonního čísla, ale nesmí měnit login)

● Oprávnění se přidělují skrze role v IAM (RBAC model stejně jako u řízeného systému). IAM umožní v grafickém webovém rozhraní u uživatele zobrazit všechna oprávnění do IAM včetně detailu – na které objekty, jakým pravidlem a pro jaké operace je oprávnění vydáno.

17 POŽADAVKY NA DOKUMENTACI

Dokumentace realizace projektu musí být napsána v českém jazyce. Součástí dodávky je nejméně následující dokumentace

Dokumentace skutečné realizace

Musí obsahovat design dodaného řešení formou diagramu a popis všechny změn platných pro prostředí zadavatele proti výchozí či standardní konfiguraci jednotlivých komponent.

Dokumentace instalace SW

Řešení musí obsahovat kompletní dokumentaci instalačních postupů a konfigurace (síť, názvy apod.) dodaného řešení. Dle dodané dokumentace instalace bude schopen kdokoli tento postup v budoucnu opakovat.

Plán obnovy (disaster recovery plán)

Plán obnovy zahrnuje postupy pro obnovu prostředí v různých krizových momentech, jako je smazání či nechtěná změna dat, znepřístupnění administrátorského účtu atd. Pro každý krizový scénář je definován postup obnovy s přihlédnutím na dostupné zálohovací mechanismy.

Testovací scénáře

V rámci řešení projektu budou vypracovány testovací akceptační scénáře, které budou použity jak pro testování aplikace zadavatelem, tak jejich podmnožina i jako regresní testy například pro kontrolu základní funkčnosti při nasazování rozvoje a upgrade řešení.

Plán přechodu do produkčního provozu

Přes spuštěním IAM v produkčním provozu bude vypracován detailní plán pro nasazení identity managementu do provozu. Plán musí formou checklistu obsahovat všechny kroky od instalace a nastavení produkční instance IAM, přes import konfigurace z testovacího prostředí, rozplánování

všech potřebných úloh, tvorbu reportu rozdílů dat (IAM vs řízené systémy), čištění dat se zákazníkem, zálohování systémů a součinnosti na zákazníka a jeho případné dodavatele až po postupné/dávkové spuštění propisu dat do řízených systémů.

Plán záloh

V rámci dokumentace řešení bude navrhnuto a zadokumentováno zálohování, které provádí jak zadavatel (záloha virtualizace, odlévání záloh dat ze serveru apod…), tak dodavatel (aplikační data IAM, konfigurace aplikace IAM, zálohy logů). Veškeré zálohy dat uživatelů musí být ukládány

v šifrované podobě.

18 POŽADAVKY NA ŠKOLENÍ

Poptávané řešení musí obsahovat školení v rozsahu minimálně 1MD pro systémové administrátory IdM.

19 POŽADAVKY NA ZÁLOHOVÁNÍ

Řešení bude obsahovat aktivní zálohy dat a konfigurace tak, aby byla zajištěna obnova dat v případě neočekávané situace na základě recovery plánů. Dále bude v rámci řešení předáno doporučení pro zálohování prostředků poskytovaných zadavatelem.

20 POŽADAVKY NA MONITORING

IAM zajistí monitoring na několika úrovních

● Kompletní monitoring běhu IAM s přehledem v grafickém webovém prostředí IAM. Administrátor bude moci z jednoho místa vyhodnotit stav IAM a zda je potřeba nějakého zásahu. Zejména bude k dispozici přehled:

o Všech událostí na systému s vyznačením nevyřešených chyb

o Přehled chyb s komunikaci se systémy – jak synchronizace, tak propis.

o Přehled čekajících neprovedených úloh, reportů, operací na koncové systémy

● Denní business přehled změn na identitách – nástupy, odchody, nová vynětí z evidenčního počtu apod…

● API pro sledování IAM externími monitoringovými a logmanagement nástroji. Například možnost zapojit nagios sondy, SIEM a další.

21 PODPORA DODANÉHO ŘEŠENÍ

Součástí poptávky je poskytnutí podpory pro řešení souvisejících technických problémů, incidentů a závad, včetně pravidelného nasazování nových verzí a patchů veškerého dodaného SW (OS, IAM, DB, webový server atd...). Podpora řešení musí splňovat základní parametry dostupnosti a kvality (SLA) – dostupnost podpory v režimu 5x8. Podpora započíná dnem nasazení do produkčního provozu.

22 SOUPIS POŽADOVANÝCH FUNKCÍ IAM

Dodavatel do sloupce „Ano/Ne“ vyplní splnění funkce nabízeného systému.

Funkce	Popis	Ano/Ne
Nástěnka uživatele	Jedno místo se všemi základními informaci (identita, role, úvazky) a souborem úkolů pro právě přihlášeného uživatele v IAM	ano
Recertifikace přístupů nadřízeným nebo garantem role	Pravidelné přeschvalování přístupů odpovědnými osobami	ano
Automatické přidělení rolí na základě zařazení v organizační struktuře	Tvorba matice rolí pro automatické přiřazování přístupů do řízených systémů i do IAM.	ano
Automatické přidělení rolí na základě atributů identity, úvazku nebo jejich kombinací	Tvorba matice rolí pro automatické přiřazování přístupů do řízených systémů i do IAM.	ano
Schvalování pravidel pro přidělení role	IAM umožní schvalovat tvorbu pravidel pro automatické přidělování rolí.	ano
Hromadný import definic automatického přidělení rolí dle organizační struktury	IAM umožní hromadně importovat definice pravidel pro automatické přidělování rolí (např. z csv)	ano
Podpora vnořených AD skupin	IAM musí podporovat načtení pouze vybraných AD skupin (dle filtrů – vybraná OU, pouze skupiny s vyplněnými konkrétními atributy konkrétní hodnotou) a také umožnit některé skupiny v IAM označit tak, aby o ně nebylo možné žádat v GUI	ano
Seskupování rolí	IAM umožní seskupovat role. Skupina rolí se pak chová jako samostatná jednotka – lze o ni žádat, schvaluje se najednou. Skupiny rolí do sebe lze nadále vnořovat a vytvořit tak víceúrovňové vnořování. Skupiny rolí lze katalogizovat, aby běžní uživatelé nemuseli žádat o dílčí role, ale žádali pouze pro skupinu rolí. Skupinám rolí lze také nastavit automatická pravidla pro přidělování uživatelům jako běžné roli. Skupina rolí je v grafickém uživatelském rozhraní vždy	ano

	jednoznačně graficky odlišena od rolí, které nemají jinou vnořenou roli. Role lze seskupovat v grafickém rozhraní IAM nebo hromadně importovat seskupení rolí z jiných systémů či souboru.
Katalog rolí	Role nebo skupiny rolí lze třídit do katalogu pro přehlednost. Role lze do katalogu vložit vícekrát. Jednou například do složek tříděných podle systémů (AD, Informační systém…) a podruhé například do složky pro konkrétní oddělení/project (Sales, ITsecurity…). Ke každé složce lze evidovat také url na danou aplikaci (například odkaz do konkrétního systému pro lepší přehlednost katalogizace rolí) Katalog rolí lze spravovat manuálně v GUI nebo lze synchronizovat z napojeného systému a importovat například z CSV.	ano
SoD (segregation of duties)	Role lze definovat jako vzájemně výlučné. Žádá-li uživatel o role, které jsou neslučitelné, je v rámci schvalovacího procesu o tomto spraven jak žadatel, tak schvalovatelé. Dále je možné přidělení neslučitelných rolí evidovat v reportu. IAM umožní dodatečné schvalování žádostí, které obsahují výlučné role – například to musí posvětit zástupce IT security (nebo obecně držitel nějaké role v IAM).	ano
Centrální reset hesla v napojených systémech	IAM umožní centrální správu hesla (změna, reset) pro MS AD i další napojované systémy. Změnu může provést uživatel, nadřízený, helpdesk nebo správce IAM. Oprávnění provést reset nebo změnu hesla lze konfigurovat v IAM dle potřeby. Při propisu hesla do řízených systémů umožní IAM propagovat i metadata o hesle, jako je platnost hesla, příznak povinné změny hesla (must change password) atd… Pokud to řízený systém vyžaduje, umožní IAM zaslání hesla do více atributů jednoho účtu, například pro systémy, které podporují různé šifrovací algoritmy.	ano
Jednotné heslo	IAM umožní centrální správu jednotného hesla ● Pro všechny napojené systémy i ● Pro několik skupin systémů – každá definovaná	ano

	skupina systémů v IAM bude mít vlastní jednotné heslo s vlastní politikou hesla ● Inicializací změny z IAM nebo z napojeného systému (AD) Dle aktuální potřeby
Validace synchronizovaného hesla z AD	IAM umožní odchytávat změnu hesel v doméně MS AD a validovat ji proti centrální politice organizace. IAM umožní definovat skupinu řízených systémů, do kterých se změna hesla uživatele z domény také zpropaguje.	ano
Komplexní politika pro hesla	IAM umožní definovat politiky hesel pro generování nových hesel a validování změn hesla. Politika musí splňovat komplexnost politik domény MS AD, zákonu o kybernetické bezpečnosti a příslušných vyhlášek a nařízení jako je NIS2 apod. IAM z bezpečnostních důvodů neumožní zobrazit heslo identit v ní spravované, a to ani administrátorovi s nejvyššími právy (ani při využití funkce generátoru hesel). Navíc musí umožnit definovat skupiny povolených a zakázaných znaků (whitelist, blacklist) kvůli možné distribuci hesel pomocí kanálů jako SMS, aby se znaky vzájemně nepletly. Např. el „l“ vs. velké i „I“. Produkt musí podporovat historii hesel uživatelů, v případě změny hesla přes IAM. Nová hesla zadaná v IAM jsou kontrolována proti historii. Hesla v historii jsou uložena tak, že není možné získat jejich čitelnou podobu. IAM musí umožnit nastavit platnost hesla na určité období a informaci o expiraci hesla přehledně zobrazovat v grafickém webovém rozhraní v seznamu identit a dopředně notifikovat uživatele o blížící se expiraci hesla. IAM musí podporovat konfiguraci neexpirujícího hesla pro vybrané účty – typicky systémové/servisní účty.	ano
Bezpečnost práce s hesly	IAM nesmí ukládat hesla uživatelů v historii hesel ani jinde takovým způsobem, aby bylo možné zpětně zkonstruovat původní heslo (bez znalosti hesla samotného). Hesla uživatelů je možné udržovat v podobě otisku (hash), ze kterého není možné původní heslo odvodit. Kvalita hashovacího algoritmu musí zajistit odolnost vůči útokům, zejména proti útoku hrubou silou. Existují-li hesla, která je z principu nutné ukládat do aplikace v podobně umožňující jejich použití – jedná se například o hesla technických účtů napojovaných systémů nutná pro navazování spojení – musí být hesla uložena v šifrovaném úložišti odděleně od zbytku dat aplikace.	ano

	IAM musí takové úložiště nabízet a musí umožnit použít externí šifrovaná úložiště (například poskytnutá zákazníkem). Do šifrovaného úložiště umožní aplikace ukládat vedle hesel i údaje, které zákazník považuje za citlivé, je-li třeba je v projektu použít. Například číslo občanského průkazu.
Generátor a validátor hesel dle komplexních politik	IAM umožní definování rozdílných politik pro generování nového hesla a pro validaci změny hesla. Pro generování hesla může být například využita politika, dle které se nepoužívají zaměnitelné znaky `I` a `l` - velké i a malé el, protože se můžou automaticky posílat v psané podobě a vyvolaly by zmatení uživatelů. Naopak ve validačních politikách se toto pravidlo neuplatní, protože uživatel/administrátor sám heslo zadává dle svého uvážení. Generátor umožní generovat náhodná hesla i tzv. passphrases – velmi dlouhá hesla generovaná náhodným spojením slov ze slovníku, dle preference zadavatele.	ano
Zástupnost pro schvalování - delegace	IAM umožní uživatelům, aby si v grafickém rozhraní nastavili zástupnost schvalování úkolů po určitou dobu – například v době dlouhodobé nemoci nebo dovolené – nebo na neurčito – například deleguji schvalování úkolů na svého zástupce. Všechny úkoly, které byly delegovány jsou následně ve všech agendách grafického rozhraní jednoznačně označeny od koho -> na koho byl úkol delegován. Stejně tak je vyřešený úkol v rámci auditu uchován se stejnou informací o delegaci. IAM umožní nastavit zastupitelnost pro schvalování úkolů i oprávněným administrátorům.	ano
Zástupnost práv - stejná židle	IAM umožní dočasně (dle data od-do) posadit uživatele na pozici jiného uživatele, jehož zastupuje, aby tak získal veškerá automatická práva v IAM i řízených systémech jako zastupovaný uživatel. Pokud je třeba, aby zastupující získal i role přidělené zastupovanému, IAM nabídne nástroj, jak tyto role jednoduše zkopírovat včetně možnosti nastavení platnost od-do, aby odpovídala posazení na pozici.	ano
Možnost přesunout schvalovací úkol na jiného	Uživatelé s vyšším oprávněním, například administrátor IAM, budou mít možnost přesunout úkol na jiného řešitele nebo úkol zrušit. Tuto funkci lze použít, například pokud	ano

řešitele.	je současný řešitel nedostupný (nemoc, nenadálá nepřítomnost). Přesun i zrušení je řádně evidováno v auditu IAM.
Náhled za jiného uživatele	IAM umožní náhled do IAM pohledem jiného uživatele v režimu pro čtení. Tato funkce je zpřístupněna vybraným uživatelům dle nastavených práv v IAM, například pro uživatele podpory nebo IT administrátora IAM, aby zajistili support běžným uživatelům.	ano
Zástupnost garantů rolí (schvalovatelů) vydefinováním skupiny garantů	IAM umožní definovat skupinu (roli), jejíž členové budou vystupovat jako garanti/schvalovatelé nějaké jiné role. Tím, že budou garanti role určeni skupinou a nikoli přímým výčtem identit, se zajistí jejich zastupitelnost v případě nepřítomnosti konkrétního garanta nebo při odchodu garanta. Členství ve skupině/roli lze automatizovat pomocí definovaných pravidel.	ano
Podpora managementu uživatelských certifikátů	IAM přehledně v grafickém rozhraní zobrazí seznam certifikátů uživatele včetně sériového čísla a aktuálního data platnosti. IAM umožní manuálně vložit certifikát k identitě skrz grafické webové rozhraní a stáhnout certifikát (veřejnou část). IAM umožní distribuovat certifikáty (veřejné části), zejména sériová čísla do napojených systémů.	ano
Podpora evidence a managementu vydaného drobného majetku identitám	IAM v rámci správy životního cyklu identit zajistí možnost k identitám evidovat drobný vydaný majetek jako například moblní telefon, notebook, hardwarové usb tokeny pro certifikáty atd… Evidenci a přidělení IAM umožní přehledně ve svém grafickém webovém rozhraní.	ano
Univerzální API (např. REST)	IAM umožní kromě správy přes grafické webové rozhraní také kompletní správu přes univerzální API. Toto lze využít například pro napojení provozních systémů - monitoring, datawarehouse, SIEM apod... nebo pro aktivní (push) správu dat v IAM – například dávkové založení uživatelů, stažení reportu, stažení certifikátů atd… Veškeré operace umožněné v grafickém rozhraní musí být dostupné i pro automatizovanou správu přes univerzální API. Univerzální rozhraní komunikuje vždy šifrovaně. Systémy se k IAM univerzálnímu API autentizují a autorizují dedikovaným technickým uživatelem. IAM umožní správu takových technických uživatelů, jejich	ano

	evidenci, změnu přihlašovacích údajů, hromadné odhlášení všech aktuálně přihlášených uživatelů.
Volání a dokumentace univerzálního API	Univerzální API bude také možné přímo v IAM volat interaktivně přes grafické rozhraní. Obsluha IAM si tak bude moci bez programování vyzkoušet metody API například pro definici napojení na dávkové zpracování dat nebo nově zaváděné systémy v organizaci.	ano
Podpora logování standardem syslog	Pro napojení log managementu	ano
Hromadné změny	IAM umožní hromadně v grafickém rozhraní provádět změny na objektech identit, rolí a organizačních prvků. Minimálně budou dostupné hromadné operace pro ● vkládání objektů, úprava objektů, mazání objektů. ● V případě identit bude možné vyfiltrovat hledané identity a přidělit jim hromadně role/oprávnění, změnit jim vedoucího, zablokovat, změnit organizační zařazení, změnit platnost kontraktu atd.. ● Spustit proces přeschválení přidělených přístupů pro vybrané role nebo vybrané uživatele ● Hromadné schvalování přidělených úkolů řešitelů off-line systémů. Existuje-li v IAM více úkolů na stejný účet (např. CREATE, UPDATE), IAM v grafickém rozhraní zobrazí uživateli tuto vazbu s možností prokliku mezi takto provázanými úkoly, aby administrátor řešit úkoly na reálném systému ve správném pořadí. Každá změna provedená pomocí hromadné akce je auditovaná. Hromadné operace v GUI jsou standardem pro UX a nutností pro hromadnou migraci dat například při napojování nového systému, zapojování nové pobočky do infrastruktury nebo větší organizační změny.	ano
Okamžitá blokace účtů identity	IAM musí být schopno řešit mimořádné události při zcizení identity – okamžité zakázání identity ve všech řízených systémech.	ano
Požadavky na reporting.	IAM umožní tvořit reporty nejméně v následujících formátech:	ano

	● formátu kompatibilního s MS Office (Excel). ● Univerzální strojově zpracovatelný report (json, xml apod.) IAM umožní reporty generovat na vyžádání z grafického webového rozhraní i plánovat jejich pravidelné spouštění (např. každý den ráno přehledový report). V případě plánovaného spuštění IAM odešle po vytvoření reportu notifikaci s reportem či odkazem na získání reportu. Data obsažená v reportech budou podléhat stejnému systému řízení práv jako při prohlížení dat v grafickém webovém rozhraní nebo univerzálním API. Tzn. uživatel si do reportu může dát pouze taková data, na která má v IAM právo – například vedoucí si může do reportu vyexportovat pouze sebe a své podřízené. Administrátor může exportovat všechny uživatele. Garant rolí může exportovat pouze role, jimž je garantem apod. Dodané řešení bude obsahovat nejméně následující reporty: ● Denní přehled změn v životním cyklu identit – nástupy, odchody, nové mateřské apod… ● Denní přehled monitoringu aplikace – všechna varování či chyby procesů IAM (chyba v propisu, synchronizaci apod.) ● Přehled identit, kontraktů a přidělených rolí ● Přehled rolí a příslušných držitelů ● Změny v přiřazení rolí uživatelů v definovaném období ● Přehled změn hesla uživatelů pro vybraný systém ● Všechny změny účtů na vybraném koncovém systému
Export dat z grafického rozhraní	Objekty Identit, systémů a rolí lze v grafickém webovém rozhraní přehledně vyfiltrovat a hromadně exportovat do formátu kompatibilního s MS Office (Excel). Dále lze z IAM jednoduše zálohovat do souboru ● Workflow ● Transformační skripty ● Šablony notifikací ● Konfigurace všech napojených systémů a všech rolí IAM umožní jednoduchý import výše uvedených objektů do IAM například za účelem přenosu mezi prostředími –	ano

	po otestování na testovacím prostředí se importuje veškerá nová konfigurace do produkčního prostředí.
Konfigurovatelné číselníky	IAM musí umožnit definovat různé číselníky v grafickém rozhraní a. Číselníky se používají například jako ● číselník stavu úvazku – pro výpočet vynětí z evidenčního stavu ● typ úvazku – dpp, hpp, dpč apod. ● typ uživatele – interní, externí, dohodář, stážista apod. a další. Číselníky lze dále používat jako hodnoty atributů objektů (identit, kontraktů, rolí, organizačních prvků apod…) nebo jako vstup do transformací dat v rámci synchronizace a provisioningu (propisu dat na řízený systém). Například pro plnění atributu oddělení v MS AD.	ano
Rozšířené atributy identit, rolí a organizačních prvků	Základní objekty v IAM musí mít možnost definovat v grafickém rozhraní, jaké atributy budou u objektu evidovány a jakých datových typů jsou. Počet uživatelsky definovaných atributů není omezen. Uživatelsky definované rozšířené atributy bude moci editovat pouze uživatel s oprávněním správy tohoto atributu. Například IAM umožní nastavit, aby každý uživatel sám sobě mohl vyplnit soukromou mailovou adresu, ale nedovolí editovat tyto údaje ostatním uživatelům. Naopak některé atributy budou pouze popisné (například ty, které jsou automaticky generovány systémem nebo synchronizovány z jiných systémů) a uživatel je uvidí v režimu pouze pro čtení, aby je nemohl nedopatřením změnit. U každého uživatelsky definovaného atributu bude moci administrátor v grafickém rozhraní definovat, jak budou hodnoty při zadávání validovány. Například bude určeno, že korespondenční adresa je textový řetězec s nejméně třemi znaky. Validátor soukromého tel. čísla bude moci vyhodnotit, že zadavatel zadává správný formát čísla. Validátory budou umět používat základní regulární výrazy pro práci s textem. Validátory umí vyhodnocovat zadaná data online, tzn. uživatel píše do formuláře a IAM vyhodnotí, zda zadaná hodnota odpovídá validátorům, případě graficky vyznačí chybu v zadání.	ano

Přílohy	IAM umožní v rozšířených atributech identit evidovat nejen jednoduché datové typy (číslo, text atd…), ale i obecně binární soubory – přílohy. Přílohou může být vstupní list, který uloží HR nebo například certifikace uživatelů ze školení apod… Přílohy spravuje a ukládá IAM a umožní jejich distribuci do řízených systémů. Práce s přílohami se řídí oprávněními stejně jako jiné rozšířené atributy.	ano
Standardní generátory hodnot	IAM umožní použít pokročilé generátory v GUI pro běžně generované atributy jako je login a email. IAM umožní vybrat si tvar loginu a emailu uživatelů, například určitý počet písmen ze jména a určitý počet písmen z příjmení (nebo celé) a spojovací znak (nebo bez spojovacího znaku).	ano
Validace unikátnosti hodnot	Generátory a validátory umožní zjištění unikátnosti hodnoty generovaného atributu v rámci IAM, ale i v rámci napojeného systému. Například IAM umožní validovat unikátnost vygenerovaného emailu v rámci IAM a domény MS AD, a to včetně emailových aliasů uživatelů.	ano
Rozdílový seznam stavu účtů v řízených systémech	IAM umožní pravidelně validovat stav účtů na koncovém systému oproti stavu v identity manageru a na základě toho vystaví report rozdílů. Rozdíly jsou evidovány až na úroveň konkrétních hodnot atributů účtů a stavu přidělených rolí/skupin.	ano
Plánovač úloh	IAM umožní procesy, hromadné operace a reporty spouštět pomocí plánovače. V plánovači bude moci administrátor v grafickém webovém rozhraní naklikat, kdy se má daná úloha spouštět a s jakou periodou. Například si vybere první spuštění 23.10.2021 od 10:30 hod. a úloha se bude spouštěn 1x týdně. IAM umožní spouštět úlohy v návaznosti. Například v plánovaný čas je spuštěna synchronizace organizační struktury a po úspěšném dokončení synchronizace je spuštěna synchronizace identit, poté kontraktů, poté přidělování rolí, pak třeba report atd… IAM umožní pokročilejší plánování pomocí regulárních výrazů, cronu nebo podobných výrazových prvků. IAM bude zobrazovat a uchovávat veškeré informace o	ano

	plánovaných úlohách, zejména: ● Všechny rozplánované úlohy s vyznačením termínu příštího spuštění ● V případě, že se úlohy spouštějí v návaznosti (synchronizace identit po synchronizaci organizační struktury), tak je tato závislost v plánovači vyznačená. ● IAM uchová pro auditní účely záznam o proběhlých úlohách včetně zpracovaných objektů a výsledku zpracování, chybových hlášení či varování. V rámci plánovače bude možné spustit vlastní připravené úlohy, například script pro hromadné operace. Spuštění vlastních úloh nevyžaduje rebuild či restart aplikace. IAM bude při dodání obsahovat sadu rozplánovaných úloh pro běžný provoz IAM, například úlohy životního cyklu identity, systémové úlohy, úlohy pro čištění zastaralých logů atd… IAM umožní plánované úlohy spouštět nanečisto (dry- run), aby bylo možné kritické úlohy (např. mazací operace) vyzkoušet bez dopadu na data před plným spuštěním.
Režimy online napojených systémů	IAM nabízí při komunikaci s koncovým systémem minimálně tyto režimy: ReadWrite, Read only s generováním operací do grafické fronty (pro kontrolu správnosti při zavádění – dry-run nebo pro maintenance odstávky napojeného systému), Read only bez generovaní, neaktivní	ano
Zobrazení operací na systémy	IAM umožní přehledně v grafickém webovém rozhraní zobrazit všechny operace, které čekají na propis do napojeného systému i všech již propsaných operací. IAM umožní ● vyprázdnit vybrané čekající požadavky na propis do sytému ● opakovat požadavky (např. při nedostupnosti systému) automaticky v určených intervalech nebo manuálně v GUI. Při manuálním opakování operací zajistí IAM, že bude zachována posloupnost operací pro jednotlivé identity. (např. Create, update, update), i když uživatel vybere pouze poslední operaci. ● Každou čekající či provedenou operaci přehledně	ano

	zobrazí včetně kompletního výčtu všech hodnot, které IAM pro daný účet posílá. Zobrazí jak stav v IAM, tak stav na systému a přehledně zvýrazní rozdíl hodnot, který je zpropagován do řízeného systému.
Aktivní hlídání operací na systémy	IAM umožní monitorovat všechny prováděné operace (Create, Update, Delete) pro každý systém. V IAM bude možné konfiguračně definovat bezpečné limity (varování, blokace) pro každou operaci na každém systému. Při překročení limitu varování bude IAM notifikovat administrátora. Při překročení limitu blokace bude IAM blokovat veškeré následné operace. Například IAM umožní nastavit limit operací DELETE pro systém MS AD na úroveň 5 účtů za 30 minut pro varování a 10 účtů za 60 minut na zablokování. Takto bude možné ochránit účty v napojených systémech proti různým incidentům – například velká změna dat z HR systému.	ano
Online zobrazení aktuálních atributů účtu na napojeném systému	IAM umožní v grafickém uživatelském rozhraní online náhled na účet a jeho atributy v napojeném systému. Administrátoři budou moci kontrolovat propis dat bez nutnosti použít jinou aplikaci pro správu řízených systémů, například pokud k ní nemají přístup.	ano
Správa přihlášení uživatelů a systémů	IAM zajistí v grafickém rozhraní přehlednou agendu pro evidenci a správu všech přihlášených uživatelů – včetně technických účtů používaných například pro vyčítání dat z IAM pomocí univerzálního rozhraní. U každého uživatele bude evidováno a zobrazeno nejméně ● Datum přihlášení ● Datum expirace přihlášení ● Seznam agend, objektů a akcí v IAM, ke kterým má přihlášený uživatel přístup V rámci správy přihlášených uživatelů IAM umožní v grafickém rozhraní IAM vybrané nebo všechny uživatele odhlásit a vynutit tak znovupřihlášení bez nutnosti restartovat aplikaci.	ano
Požadavky na auditní nástroje	IAM bude uchovávat kompletní auditní záznamy pro všechny spravované objekty. V rámci auditu bude možné porovnat objekt (identitu, roli, systém atd…), jak vypadal v různých časových okamžicích. IAM nabídne seznam okamžiků, kdy se objekt měnil a porovná dva takové záznamy. Například jak vypadala identita při založení vs jak vypadala při změně organizačního zařazení	ano

	na začátku měsíce. Audit dále bude obsahovat nejméně: ● Audit přihlášení uživatelů do IAM – jak úspěšných přihlášení, tak i neúspěšných pokusů o přihlášení například pro účely ochrany proti kyberútokům. ● Audit změn hesla ● Audit přidělení rolí včetně odkazu na proces a schvalovatele procesu ● Audit všech synchronizací – průběh, log chyb, log zpracovaných objektů ● Audit všech odchozích operací do řízených systémů včetně obsahu přenášených dat ● Provozní aplikační audit - zaznamenává události systému ● Notifikační log – zaznamenává log odeslaných emailových a sms notifikací ● Audit plánovaných úloh – všechny běhy úloh spuštěných v rámci plánovače ● Audit hromadných změn Audit změn objektu v IAM musí obsahovat kompletní auditní stopu, která vede od konkrétního záznamu v auditu, například změna popisného atributu identity, celým řetězcem kroků až k inicializaci změny – například kliknutí na tlačítko uživatele v GUI, nebo konkrétnímu běhu synchronizace dat z HR spuštěné plánovačem úloh.
Audit klíčových objektů	Audit kritických objektů v IAM (identity, role, organizační prvky, kontrakty…) bude umožňovat zobrazit stav objektu pomocí obrazu stavu objektu v čase. IAM nabídne možnost porovnat stav objektu v různých časových okamžicích – jak vypadá identita nyní vs jak vypadala identita například před měsícem. Porovnání bude obsahovat položky daného objektu se zřejmým vyznačením změněných položek, časové značky, kdy byla položka změněna a jednoznačným identifikátorem původce změny.	ano
Přehled workflow	IAM zpřístupní přehled všech workflow včetně stavu (běží, ukončeno…). Z přehledu workflow bude možné prohlédnout detail workflow včetně grafické vizualizace průběhu.	ano
Kompatibilita prohlížečů	Webová rozhraní IAM musí být přístupné pomocí prohlížečů EDGE, Firefox v aktuálních verzích	ano

Příprava identity před nástupem	IAM umožní identitě uživatelů, kteří mají nastoupit do organizace, přidělovat role pro aplikace dopředně. U jednotlivých rolí půjde definovat, zda se role má na identitu aplikovat a propsat do koncového systému. U některých systémů (AD) může být chtěné, aby se účet vytvořil dopředu a administrátoři například mohli nakonfigurovat zaměstnanci pracovní stanici/notebook, nainstalovat do profilu aplikace apod. Bude-li se účet propisovat před nástupem, bude účet vytvořen neaktivní a heslo k němu nebude předáno, dokud držitel identity nenastoupí. Některé jiné systémy tento režim využívat nemusí. Ať jsou účty pro jednotlivé systémy připraveny dopředně či nikoli, IAM musí zajitit propis jediného iniciálního hesla v den nástupu na všechny systémy a jeho distribuci uživateli.	ano
Karanténa účtů	Při ukončení platnosti identity umožní identity manager zablokování účtů ve vybraných systémech na předem definovanou dobu (například 14 dní). Po tuto dobu bude možné identitu obnovit (například při prodloužení smlouvy nebo znovunástupu) s původními atributy. Zejména bude zachován login a email v řízených systémech. Účty identit v karanténě nemají žádné přístupy (role) a jsou blokovány – tzn. uživatelé je nemohou používat. Po uplynutí doby karantény je účet ze systémů smazán. Na systémech, kde není karanténa nastavena, je účet smazán ihned při ukončení identity. Karanténa účtu slouží nejen pro zachování důležitých atributů při prodloužení kontraktu, ale i jako přechodné období pro dokončení mazání účtů. Například administrátoři vybraných systémů musí pro kompletní odmazání účtů provést v rámci definované karantény archivaci mailových schránek nebo souborů ve sdílených adresářích. Karanténu bude možné nakonfigurovat pro každý řízený systém zvlášť.	ano
Ukončení identity	Při ukončení identity v identity manageru je pro účely auditů přístupů zachována kompletní auditní stopa. Lze zpětně dohledat, kam měla identita přístup v kterémkoli časovém úseku existence identity. V případě potřeby umožní identity manager periodické nebo ad-hoc odmazání (archivaci) auditních dat od konkrétního data (například auditní informace starší 2 let).	ano
Synchronizace pro párování dat	V rámci synchronizace dat bude možné nejen importovat data do IAM, ale také spárovat identity k jejich existujícím	ano

	účtům (např. pro AD). Párování IAM umožní na základě konfigurace ● vybraný atribut – např. osobní číslo ● korelace více atributů – např. jméno + příjmení (v případě, že systémy neobsahují jednoznačný identifikátor nebo se na jeho kvalitu nelze spolehnout)
Migrační nástroje pro export/import dat	IAM bude obsahovat migrační nástroje pro export konfigurací a naplnění IAM daty. Import daty: ● import externistů mimo HR – identit, platností kontraktů, garantů externistů… ● naplnění off-line systémů – účty a atributy, role a jejich přiřazení k účtům, vazby na identity v IAM ● import katalogů rolí ● import organizačních struktur mimo HR – například z AD, csv, DB (struktury projektů) ● import pravidel pro automatické přidělování rolí Export/Import konfigurací (migrace IAM) je nutný zejména pro dávkový či automatizovaný přenos konfigurací z testovacího prostředí do předprodukčního/referenčního či produkčního systému. IAM umožní importovat/exportovat: ● konfiguraci aplikace IAM ● konfiguraci napojených systémů ● role pro napojené systémy i rolí pro přidělování práv v IAM IAM umožní před importem zobrazit grafický přehled změn, které se administrátor chystá importem provést. To je třeba z bezpečnostních důvodů, ale i pro vyřešení možných konfliktů v importovaných datech a již existujících datech.	ano
Fulltextové vyhledávání	IA umožní fulltextové vyhledáván. Běžný uživatel si tak například najde roli, o kterou chce žádat. Správce uživatelů dle loginu vyhledá požadovanou identitu apod…	ano
Kopírování rolí od uživatele	IAM umožní kopírovat role od jiného uživatele - v grafickém rozhraní umožní zkopírovat všechny nebo vybrané role. Při kopírování rolí od uživatele je graficky	ano

	odlišeno, které role jsou speciálního typu – skupina rolí, automaticky přidělená role, manuálně přidělená role, role je součástí skupiny jiných rolí. Pokud je zapnuto schvalování, pak je žádost o změnu schvalována jako při běžném výběru z katalogu rolí.
Role management	IAM obsahuje přehlednou agendu v grafickém webovém rozhraní pro správu rolí. Správa rolí umožní definovat jak administrátory IAM, tak delegovaným uživatelům – správcům rolí. IAM umožní schvalovat role management (vytvoření, úpravu či smazání role). Schvalovací proces je ovládán workflow, které bude konfigurovatelné, nebo lze zcela vypnout. IAM umožní v grafickém webovém prostředí zobrazovat oprávněným uživatelům kompletní informace o rolích včetně: ● seznamu držitelů role ● seznamu systémů, pro které je role definována ● seznamu systémů, odkud byla role synchronizována nebo kam byla zpropagována (provisioning dat) ● schvalovacího workflow a garantů role ● skupin rolí, jejíž je role členem a zároveň seznamu rolí, kterým je role nadřazena. ● SoD – seznamu rolí, které jsou s danou rolí neslučitelné ● Parametrů role ● Prostředí systému (AD), pro které je role určena – například test, reference, produkce ● Xxxxxx katalogu, kam je role zařazena IAM přehledně zobrazí u každé identity, jaké role má přidělena a jakým způsobem (žádostí vs automaticky dle pravidla). Zároveň bude zobrazeno, zda má uživatel roli přidělenu napřímo nebo skrze seskupení rolí. V případě skupiny rolí umožní zobrazit (rozkliknout či jinak zobrazit) všechny role dané přidělené skupiny. Zároveň bude u uživatele zřejmé z jakého kontraktu/úvazku role pochází. IAM umožní automaticky načítat seznam skupin/rolí z řízených systémů – zejména MS AD. Role je možné zadávat i manuálně skrze grafické webové rozhraní nebo dávkově přes univerzální API nebo importem ze souboru. IAM umožní definovat vlastníky rolí, kteří mohou role	ano

	upravit, smazat či přiřadit uživatelům. Vlastníci rolí a privilegovaní uživatelé mohou v grafickém rozhraní získat seznam držitelů role či si mohou role vyexportovat do reportu. Uživatelé s patřičnými oprávněními můžou nad vybranými uživateli spustit deduplikaci přiřazení rolí. Tento proces vyčistí duplicitně přiřazené role u uživatele – například pokud má uživatel roli automaticky a zároveň ji dříve získal manuální žádostí, je mu manuální role odebrána (nekončí-li platnost přidělení automatické role dříve než manuální).
Uložení dat	Systém pro správu identit bude používat pro uložení parametrů identit vlastní databázi. IAM umožní v případě potřeby použít jinou externí databázi pro uchovávání dat (např centrální MSSQL).	ano
Modulární architektura	Architektura řešení bude modulární. Jednotlivé funkční celky budou odděleny do vlastních modulů s jasně definovaným rozhraním pro komunikaci s ostatními moduly. Každý z modulů půjde samostatně zapnout a vypnout a tím se zpřístupní nebo zablokuje jeho funkce i příslušné agendy v grafickém rozhraní. Po vypnutí a opětovném zapnutí modulu nedojde ke ztrátě dat, se kterými modul (například seznam uživatelských licencí) pracuje. Modularita řešení zajistí jednoduchou rozšiřitelnost o další nové funkce a moduly. Nově vydané moduly bude možné do IAM jednoduše začlenit jejich stažením a přidáním k již existujícím modulům. Veškeré implementace zákazníkovi na míru v rámci projektu budou implementovány do odděleného modulu pro usnadnění nasazování nových verzí produktu a zajištění dlouhodobé udržitelnosti.	ano

Zhotovitel tímto čestně prohlašuje, že jím nabízený systém automatizace nastavení práv a portál identit splňuje veškeré požadavky zadavatele, uvedené v této příloze.

V Praze dne dle data el. podpisu

...podepsáno elektronicky... Xxx. Xxxxxx Xxxxx, MBA jednatel

Příloha č. 2 – Akceptační řízení

1. AKCEPTAČNÍ ŘÍZENÍ

1.1. Akceptační řízení zahrnuje porovnání skutečných vlastností předmětu Díla (konkrétního výstupu některé z Fází) se specifikací předmětu Díla dle Smlouvy, zejména Přílohy č. 1 [Technická a věcná specifikace], Harmonogramu v souladu s Článkem 2.2 Smlouvy, a s požadavky pro akceptaci.

1.2. Výstup jednotlivé Fáze je způsobilý k akceptaci Objednatelem, pokud naplňuje požadavky pro akceptaci a splňuje Akceptační kritéria.

1.3. V jiných případech není výstup Fáze způsobilý k akceptaci.

1.4. Požadavky pro akceptaci jsou jakékoliv podmínky a kritéria, která musí výstupy provádění Díla nebo Systém splňovat, aby takové výstupy či Systém odpovídaly požadavkům na ně kladeným právními předpisy, aby mohly plně sloužit svému účelu a aby Systém a IT prostředí fungovaly alespoň tak, jak jsou specifikovány v Příloze č. 1 [Technická a věcná specifikace].

1.5. Akceptační řízení proběhne na závěr Fáze 1 a 2, pro každý výstup zvlášť. Dílo tak bude předáváno k Akceptačnímu řízení a akceptováno po částech, s tím, že:

a. o předání výstupu Fáze Objednateli bude Objednatelem podepsán Předávací protokol, a to i v případě opakování činností v rámci Akceptačního řízení v důsledku „Neakceptováno“ na Akceptačním protokolu;

b. Objednatel posoudí předané výstupy Fáze nebo zajistí provedení testů předaného výstupu uživateli (testery), přičemž posouzení předaného výstupu Fáze nebo testy budou probíhat ve lhůtě 10 pracovních dnů ode dne předání výstupu Fáze;

c. testy probíhají s využitím testovacích dat dodaných Objednatelem;

d. testy se v případě, že je na Akceptačním protokolu uveden výrok „Neakceptováno“, opakují, dokud nebudou splněna Akceptační kritéria;

e. v případě nutnosti opakování činností v rámci Akceptačního řízení v důsledku uvedení

„Neakceptováno“ v Akceptačním protokolu Zhotovitel Objednateli předá výstup k opětovnému provedení činností v rámci Akceptačního řízení (další kolo Akceptačního řízení) a Objednatel připraví nový Akceptační protokol vztahující se k dalšímu kolu Akceptačního řízení. Akceptační řízení může být vícekolové, ovšem vždy se jedná o jedno Akceptační řízení;

1.6. Akceptační řízení konkrétního výstupu končí a výstup se považuje za provedený podpisem Akceptačního protokolu Objednatelem s uvedením „Akceptováno“ nebo „Akceptováno s výhradou“, nestanoví-li Akceptační kritéria pro danou Fázi, že výstup lze akceptovat pouze bez výhrad.

1.7. Objednatel na Akceptačním protokolu uvede výrok „Akceptováno“, „Akceptováno s výhradou“ nebo „Neakceptováno“ v závislosti na splnění Akceptačních kritérií. Pokud není uveden výrok

„Akceptováno“, uvede rovněž zjištěné vady, jejich typ (kategorii) a popis. Zhotovitel je povinen odstranit vady uvedené ve výhradách Objednatele ve lhůtě stanovené Objednatelem v Akceptačním protokolu.

1.8. Po provedení poslední Fáze a odstranění veškerých vad uvedených v případných výhradách Objednatele bude Stranami podepsán Závěrečný akceptační protokol potvrzující provedení Díla.

2. KATEGORIZACE VAD

2.1. Objednatel u každé zjištěné vady dostatečně popíše, v čem spočívá a kde se vyskytuje. Na základě popisu vady uvede její kategorii.

2.2. Zhotovitel může Objednateli ve lhůtě tří (3) dnů sdělit, že s kategorií vady nesouhlasí. Při tom uvede, zda se má jednat o vadu jiné kategorie či zda se o vadu nejedná. Svůj nesouhlas Zhotovitel dostatečně odůvodní.

2.3. Objednatel může změnit klasifikaci vady podle vyjádření Zhotovitele. Pokud s klasifikací navrženou Zhotovitelem nesouhlasí, použije se ohledně sporné vady Eskalační proces.

2.4. Výstup Fází 1, 2 vykazuje

a. vadu kategorie A (kritickou vadu), pokud

i. základní funkce Systému nelze využít vůbec nebo jen s výraznými obtížemi;

ii. je jakkoliv ohrožena kvalita a bezpečnost dat nebo výsledky jejich zpracování;

iii. funkce, část nebo chování Systému způsobuje či může způsobit výpadek;

iv. není možné řádné užívání funkcí Systému požadovaných právními či technickými předpisy;

v. ve výstupu Fáze nejsou zahrnuty požadavky dle Přílohy č. 1 [Technická a věcná specifikace];

vi. je výstup v rozporu s dříve akceptovaným výstupem;

vii. nelze úspěšně projít Testovací scénář;

viii. chybí konkrétní výstup Fáze;

b. vadu kategorie B (závažnou vadu), pokud se nejedná o vadu kategorie A a

i. lze funkce Systému využít s výraznými obtížemi;

ii. jsou ve výstupu Fáze požadavky dle Přílohy č. 1 [Technická a věcná specifikace] zapracovány v rozporu s těmito dokumenty;

iii. Systém nesplňuje požadavky na přístupnost, zejména podle doporučení W3C WCAG 2.1;

c. vadu kategorie C (běžnou vadu), pokud se nejedná o vadu kategorie A nebo B a

i. Systém nelze plně využít;

ii. jde o vadu grafického prvku nebo uživatelského rozhraní;

iii. jde o výrazný nedostatek uživatelsky přívětivého chování Systému při využívání jeho funkcí.

3. AKCEPTAČNÍ KRITÉRIA

3.1. Výstup Fáze 1:

a. lze akceptovat, pokud nevykazuje žádné vady;

b. lze akceptovat s výhradou, pokud vykazuje vady, které nebrání tomu, aby výstup sloužil svému účelu bez významnějších omezení pro Objednatele, a při testech v souhrnu vykazuje nejvíce 4 vady kategorie B a 10 vad kategorie C.

3.2. Výstup Fáze 2:

a. lze akceptovat, pokud nevykazuje žádné vady;

b. lze akceptovat s výhradou, pokud vykazuje vady, které nebrání tomu, aby výstup sloužil svému účelu bez významnějších omezení pro Objednatele, a při testech v souhrnu vykazuje nejvíce 6 vad kategorie C.

Příloha č. 3 - Realizační tým a Kontaktní osoby

1. REALIZAČNÍ TÝM

Role	Kontaktní údaje	Činnosti obvykle prováděné členem Realizačního týmu
IdM garant	Xxxxx a příjmení: Xxxxx Xxxxx Telefon: E-mail:	Technické vedení celého životního cyklu projektu, návrh architektury a procesů u řešení výstavby IdM.
Senior IdM specialista	Xxxxx a příjmení: Xxxxx Xxxx Telefon: E-mail:	Analytické a projektové činnosti u řešení výstavby IdM, školení administrátorů a klíčových uživatelů.
Projektový manažer	Xxxxx a příjmení: Xxxxx Xxxxxx Telefon: E-mail:	Služby řízení projektu a činností projektového týmu, sledování průběhu plnění a kontrola harmonogramu, řízení rizik, změnové a akceptační řízení, příprava a koordinace jednání.

2. KONTAKTNÍ OSOBY

Strany se dohodly na následujících Kontaktních osobách:

(a) Kontaktní osoba Objednatele pro technické otázky je ke dni podpisu smlouvy:

(i) Xxxxx a příjmení: Xxxx Xxxxxxxx

(ii) Telefon: +

(iii) email:

(b) Kontaktní osoba Objednatele pro obchodní otázky je ke dni podpisu Servisní smlouvy:

(i) Xxxxx a příjmení: Xxxx Xxxxxxxx

(ii) Telefon: +

(iii) email:

(c) Kontaktní osoba Poskytovatele pro technické otázky:

(i) Xxxxx a příjmení: Xxxxx Xxxxx

(ii) Telefon:

(iii) email:

(d) Kontaktní osoba Poskytovatele pro obchodní otázky:

(i) Xxxxx a příjmení: Xxxxxx Xxxxx

(ii) Telefon:

(iii) email:

Kontaktními osobami pro technické otázky jsou osoby, které mohou jednat v záležitostech technických, vést jednání technického charakteru, poskytovat stanoviska v technických otázkách a podepisovat Předávací a Akceptační protokoly;

Kontaktními osobami pro obchodní otázky jsou osoby, které mohou vést jednání a připravovat dokumenty vedoucí ke změně Servisní smlouvy, vést s druhou Stranou jednání obchodního charakteru a za Objednatele udělovat souhlas se změnou Poddodavatelů a členů v Realizačním týmu Poskytovatele;

Právní jednání, která mohou činit Kontaktní osoby pro technické otázky, mohou činit také Kontaktní osoby pro obchodní otázky, a jednání, které mohou činit Kontaktní osoby, může činit u Objednatele také starosta, u Poskytovatele jeho statutární orgán nebo člen statutárního orgánu. Pokud bude jakékoliv jednání učiněno, schváleno, uskutečněno nebo přijato jinou osobou než osobou oprávněnou dle této Přílohy č. 3 [Realizační tým a Kontaktní osoby] nebo aprobačního řádu Objednatele, nepřihlíží se k němu.

Příloha č. 4 – Poddodavatelé

Xxxxxxxxxx realizuje Xxxx sám.

Příloha č. 5 – Ochrana osobních údajů

1 ÚVODNÍ USTANOVENÍ

V rámci plnění Smlouvy může docházet ke zpracování Osobních údajů Zhotovitelem pro Objednatele ve smyslu článku 4 bodu 2) nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů), („Nařízení“).

Na základě článku 28 Nařízení je Objednatel povinen uzavřít se Zhotovitelem písemnou smlouvu o zpracování Osobních údajů, ve které Zhotovitel mimo jiné poskytne dostatečné záruky

o technickém a organizačním zabezpečení ochrany Osobních údajů, přičemž Strany se rozhodly vtělit tuto písemnou smlouvu o zpracování Osobních údajů do této Přílohy č. 5 [Ochrana Osobních údajů].

Strany mají zájem na tom, aby tato Příloha č. 5 [Ochrana Osobních údajů] ve spojení se Smlouvou pokrývaly veškeré činnosti zpracování Osobních údajů, které Zhotovitel provádí pro Objednatele v souvislosti nebo na základě Smlouvy. Účelem této Přílohy č. 5 [Ochrana Osobních údajů] je stanovení rozsahu povinností Zhotovitele souvisejících především se zajištěním ochrany Osobních údajů při jejich zpracování.

Zhotovitel bude ve smyslu článku 4 bodu 2) Nařízení pro Objednatele zpracovávat Osobní údaje, které Objednatel získal nebo získá jako zaměstnavatel, objednatel nebo nadřízený orgán v roli správce Osobních údajů svých zaměstnanců, dodavatelů, spolupracovníků podřízených organizací, úřadů, adresátů a odesílatelů písemností a jiných subjektů nebo které pro Objednatele za tímto účelem získá samotný Xxxxxxxxxx („Subjekty údajů“), a to v rámci plnění povinností Zhotovitele vyplývajících ze Smlouvy.

2 PŘEDMĚT PŘÍLOHY

Předmětem této Přílohy č. 5 [Ochrana Osobních údajů] je vymezení vzájemných práv a povinností Stran při zpracování Osobních údajů.

Tato Příloha č. 5 [Ochrana Osobních údajů] dále stanoví rozsah Osobních údajů, které mají být zpracovávány, účel jejich zpracování a podmínky a záruky na straně Zhotovitele ohledně zajištění technického a organizačního zabezpečení Osobních údajů.

Strany budou dále postupovat v souladu s touto Přílohou č. 5 [Ochrana Osobních údajů] za účelem splnění povinností dle Nařízení a zákona č. 110/2019 Sb. o zpracování osobních údajů a z dalších platných právních předpisů týkajících se ochrany a zpracování osobních údajů („Zákon

o zpracování OU“) a zabezpečení ochrany Osobních údajů zpracovávaných Stranami.

3 ÚČEL, ROZSAH A DOBA ZPRACOVÁNÍ OSOBNÍCH ÚDAJŮ

Za účelem plnění předmětu Smlouvy může Zhotovitel Osobní údaje v nezbytném rozsahu získávat, shromažďovat, zaznamenávat, uspořádat je, prohlížet, jakož s nimi vykonávat i další operace, které jsou nezbytné k plnění předmětu Smlouvy.

Zhotovitel bude dle této Přílohy č. 5 [Ochrana Osobních údajů] zpracovávat zejména následující kategorie Osobních údajů Subjektů údajů:

(a) jméno a příjmení;

(b) kontaktní adresa;

(c) email a telefonní číslo;

(d) pracovní zařazení a středisko;

(e) funkci (název pozice) v dotčeném systému;

(f) další údaje dostupné v Systému v souladu s platnými právními předpisy;

(g) další informace zveřejňované (zpřístupněné veřejnosti) v souladu s platnými právními předpisy.

V případě, že Objednatel Zhotoviteli poskytne nebo Zhotoviteli budou jinak v souvislosti s plněním předmětu Smlouvy zpřístupněny i jiné Osobní údaje Subjektů údajů nebo Zhotoviteli budou poskytnuty Osobní údaje jiných subjektů údajů, musí Zhotovitel zpracovávat a chránit i tyto Osobní údaje v souladu s požadavky vyplývajícími z (i) Nařízení, (ii) ze Zákona o zpracování OÚ a (iii) z této Přílohy č. 5 [Ochrana Osobních údajů].

Osobní údaje Subjektů údajů bude Zhotovitel zpracovávat nejdéle po dobu trvání Smlouvy.

4 ODMĚNA

Za zpracování Osobních údajů nenáleží Zhotoviteli zvláštní odměna, odměna je zahrnuta v rámci Ceny. Zhotoviteli rovněž nevzniká nárok na náhradu jakýchkoliv dalších nákladů, které Zhotoviteli v souvislosti se zpracováním Osobních údajů vzniknou.

5 PRÁVA A POVINNOSTI ZHOTOVITELE

Zhotovitel musí při zpracování Osobních údajů postupovat s náležitou odbornou péčí tak, aby nezpůsobil nic, co by mohlo představovat porušení Nařízení, zejména článku 25 a 32 Nařízení ve spojení s článkem 28 Nařízení, nebo porušení Zákona o zpracování OÚ.

Zhotovitel se při zpracování Osobních údajů na základě této Přílohy č. 5 [Ochrana Osobních údajů] musí řídit doloženými pokyny Objednatele. Zhotovitel musí upozornit Objednatele bez zbytečného odkladu na nevhodnou povahu pokynů, jestliže Zhotovitel mohl tuto nevhodnost zjistit při vynaložení veškeré odborné péče. Zhotovitel v takovém případě musí pokyny provést pouze na základě písemného požadavku Objednatele.

Zhotovitel musí v souladu s článkem 82 Nařízení dbát, aby žádný Subjekt údajů neutrpěl újmu na svých právech, zejména na právu na zachování lidské důstojnosti, a také dbát na ochranu před neoprávněným zasahováním do soukromého a osobního života Subjektů údajů.

Jakmile pomine účel, pro který byly Osobní údaje zpracovány, zejména v případě zániku Smlouvy, v případě odvolání souhlasu Subjektu údajů, nebo na základě žádosti Subjektu údajů podle článku 17 Nařízení, musí Zhotovitel ve smyslu článku 28 odst. 3 písm. g) Nařízení na základě a v souladu s pokyny Objednatele předat Objednateli takové Osobní údaje v souladu se Smlouvou nebo provést výmaz takových Osobních údajů.

V případě, že se kterýkoli Subjekt údajů bude domnívat, že Objednatel nebo Zhotovitel provádí zpracování jeho Osobních údajů, které je v rozporu s ochranou soukromého a osobního života Subjektu údajů nebo v rozporu se zákonem či Nařízením, zejména budou-li dle Subjektu údajů Osobní údaje nepřesné s ohledem na účel jejich zpracování, a tento Subjekt údajů ve smyslu článku 15 Nařízení požádá Xxxxxxxxxxx o vysvětlení, opravu vzniklého stavu dle Článku 16 Nařízení nebo výmaz Osobních údajů dle článku 17 Nařízení, musí o tom Zhotovitel neprodleně informovat Objednatele.

Zhotovitel musí Objednateli neprodleně oznámit provedení kontroly ze strany Úřadu pro ochranu osobních údajů a poskytnout Objednateli na jeho žádost podrobné informace o průběhu kontroly a kopii kontrolního protokolu. V případě zahájení správního řízení o uložení opatření k nápravě nebo uložení pokuty („Správní řízení“) musí Zhotovitel rovněž tuto skutečnost neprodleně oznámit Objednateli a poskytnout Objednateli na jeho žádost podrobné informace o průběhu a výsledcích Správního řízení, popř. Objednateli poskytnout plnou moc k nahlížení do spisu

týkajícího se Správního řízení. Zhotovitel musí poskytnout Objednateli kopii zprávy o odstranění nebo prevenci nedostatků zjištěných kontrolou/přezkumem, pokud je tato zpráva vypracována nebo může být na vyžádání Zhotovitele či Objednatele vypracována.

Zhotovitel musí informovat Objednatele o každém případu ztráty či úniku Osobních údajů, neoprávněné manipulace s Osobními údaji nebo jiného porušení zabezpečení Osobních údajů („Porušení zabezpečení Osobních údajů“), a to bez zbytečného odkladu, nejpozději do 24 hodin od vzniku Porušení zabezpečení Osobních údajů nebo i pouhé hrozby, jestliže Zhotovitel mohl o tomto Porušení zabezpečení Osobních údajů či i o hrozbě vzniku Porušení zabezpečení Osobních údajů vědět při vynaložení veškeré odborné péče. Nemohl-li Zhotovitel zjistit případ skutečného či hrozícího Porušení zabezpečení Osobních údajů před uplynutím lhůty dle předchozí věty tohoto bodu, informuje Zhotovitel Objednatele nejpozději do 24 hodin od okamžiku, kdy se o vzniku Porušení zabezpečení Osobních údajů nebo jeho hrozbě Zhotovitel dozví. Zhotovitel musí být i po poskytnutí informace Objednateli maximálně nápomocen při řešení Porušení zabezpečení Osobních údajů, resp. při přijímání opatření ke zmírnění možných nepříznivých dopadů a zabránění vzniku obdobných situací v budoucnu.

Pokud Objednatel na základě provedení posouzení vlivu na ochranu Osobních údajů podle článku 35 Nařízení dojde k závěru, že je nezbytné provést další opatření v této Příloze č. 5 [Ochrana Osobních údajů] nestanovené, musí Zhotovitel taková opatření provést a obě Strany takovou změnu promítnou do této Přílohy č. 5 [Ochrana Osobních údajů] bez nutnosti uzavření dodatku k Smlouvě, přičemž Zhotovitel musí na potřebu změny Přílohy č. 5 [Ochrana Osobních údajů] Objednatele upozornit. Obdobně budou Strany postupovat v případě rozhodnutí Úřadu pro ochranu osobních údajů o přijetí vzorových smluvních klauzulí o ochraně Osobních údajů nebo kodexu chování.

Zhotovitel musí být Objednateli nápomocen při zajišťování povinností dle Nařízení, především povinnosti zabezpečit zpracování Osobních údajů, ohlašovat případy Porušení zabezpečení Osobních údajů, zajištění posouzení vlivu na ochranu Osobních údajů či předchozí konzultace s Úřadem pro ochranu osobních údajů, a to při zohlednění povahy zpracování a informací, jež má Zhotovitel k dispozici.

Zhotovitel musí být Objednateli nápomocen při plnění povinnosti Objednatele reagovat na žádosti o výkon práv Subjektů údajů, zejména na žádost o přístup k Osobním údajům, o opravu či výmaz Osobních údajů, o omezení zpracování či o přenositelnost Osobních údajů.

Zhotovitel musí poskytnout Objednateli veškeré informace potřebné k doložení toho, že byly splněny povinnosti zpracování Osobních údajů včetně zpracování prostřednictvím Dalších zpracovatelů, a umožnit audity, včetně inspekcí, prováděné Objednatelem nebo jiným auditorem, kterého Objednatel pověří, a k těmto auditům přispěje.

Informace dle bodu 5.7 této Přílohy č. 5 [Ochrana Osobních údajů] musí přinejmenším obsahovat:

(a) popis povahy daného případu Porušení zabezpečení Osobních údajů včetně, pokud je to možné, kategorií a přibližného počtu dotčených Subjektů údajů a kategorií a přibližného množství dotčených záznamů Osobních údajů;

(b) popis pravděpodobných důsledků Porušení zabezpečení Osobních údajů;

(c) popis opatření, která Zhotovitel přijal nebo navrhl k přijetí s cílem vyřešit dané Porušení zabezpečení Osobních údajů, včetně případných opatření ke zmírnění možných nepříznivých dopadů.

6 ZÁRUKY TECHNICKÉHO A ORGANIZAČNÍHO ZABEZPEČENÍ OCHRANY OSOBNÍCH ÚDAJŮ

Zhotovitel musí ve smyslu článku 32 Nařízení přijmout s přihlédnutím ke stavu techniky, nákladům na provedení, povaze, rozsahu, kontextu a účelům zpracování i k různě pravděpodobným a různě závažným rizikům pro práva a svobody fyzických osob veškerá technická a organizační opatření k zabezpečení ochrany Osobních údajů způsobem uvedeným v Nařízení a Zákonu o zpracování OÚ či jiných právních předpisech k vyloučení možnosti neoprávněného nebo nahodilého přístupu k Osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití Osobních údajů. Tato povinnost platí i po ukončení zpracování Osobních údajů.

Zhotovitel musí zejména, nikoliv však výlučně, přijmout následující organizační a technická opatření:

(d) aniž by byl dotčen bod 6.3 této Přílohy č. 5 [Ochrana Osobních údajů], Zhotovitel v případě zpracování Osobních údajů prostřednictvím vlastních zaměstnanců pověří touto činností pouze své vybrané zaměstnance a členy Realizačního týmu, které poučí o jejich povinnosti zachovávat mlčenlivost ohledně Osobních údajů a o dalších povinnostech, které musí dodržovat tak, aby nedošlo k porušení Nařízení či této Přílohy č. 5 [Ochrana Osobních údajů];

(e) bude používat odpovídající technické zařízení a programové vybavení způsobem, který vyloučí neoprávněný či nahodilý přístup k Osobním údajům ze strany jiných osob než pověřených osob Zhotovitele ve smyslu bodu 6.2(a) této Přílohy č. 5 [Ochrana Osobních údajů];

(f) bude Osobní údaje uchovávat v náležitě zabezpečených objektech a místnostech;

(g) Osobní údaje v elektronické podobě bude uchovávat na zabezpečených serverech nebo na nosičích dat, ke kterým budou mít přístup pouze pověřené osoby na základě přístupových kódů či hesel, a bude Osobní údaje pravidelně zálohovat, pokud takové zálohy neprovádí Objednatel v souladu se Smlouvou nebo interními předpisy;

(h) zajistí dálkový přenos Osobních údajů buď pouze prostřednictvím veřejně nepřístupné sítě, nebo prostřednictvím zabezpečeného přenosu po veřejných sítích;

(i) písemné dokumenty obsahující Osobní údaje bude uchovávat na zabezpečeném místě, přičemž bude vést řádnou evidenci o pohybu takových písemných dokumentů;

(j) bude v co největší míře zpracovávat pouze pseudonymizované a šifrované Osobní údaje, je-li takové opatření vhodné a nezbytné ke snížení rizik plynoucích ze zpracování Osobních údajů;

(k) zajistí neustálou důvěrnost, integritu, dostupnost a odolnost systémů a služeb zpracování;

(l) prostřednictvím vhodných technických prostředků zajistí schopnost obnovit dostupnost Osobních údajů a přístup k nim včas v případě fyzických či technických incidentů;

(m) zajistí pravidelné testování posuzování a hodnocení účinnosti zavedených technických a organizačních opatření pro zajištění bezpečnosti zpracování; a

(n) při ukončení zpracování Osobních údajů zajistí Zhotovitel dle dohody s Objednatelem výmaz Osobních údajů, nebo tyto Osobní údaje předá Objednateli viz bod 5.5 této Přílohy č. 5 [Ochrana Osobních údajů].

Zhotovitel může pověřit zpracováním Osobních údajů dalšího zpracovatele („Další zpracovatel“). Zhotovitel informuje Objednatele o veškerých Dalších zpracovatelích, které zamýšlí pověřit zpracováním Osobních údajů, o veškerých zamýšlených změnách týkajících se přijetí Další

zpracovatelů nebo jejich nahrazení, a poskytne tak Objednateli příležitost vyslovit vůči přijetí těchto Dalších zpracovatelů námitky. Mimo Další zpracovatele, vůči kterým Objednatel nic nenamítal, Xxxxxxxxxx nesvěří zpracování osobních údajů žádné třetí osobě. Další zpracovatel musí být zároveň Poddodavatelem odsouhlaseným Objednatelem a musí splňovat podmínky stanovené pro Poddodavatele dle Smlouvy.

Pokud Zhotovitel zapojí ve smyslu bodu 6.3 Přílohy č. 5 [Ochrana Osobních údajů] Dalšího zpracovatele, aby provedl určité činnosti zpracování, musí být tomuto Dalšímu zpracovateli uloženy na základě smlouvy stejné povinnosti na ochranu Osobních údajů, jaké jsou uvedeny v této Příloze č. 5 [Ochrana Osobních údajů], a to zejména poskytnutí dostatečných záruk, pokud jde o zavedení vhodných technických a organizačních opatření tak, aby zpracování splňovalo požadavky Nařízení, Zákona o zpracování OÚ a Interní dokumentace. Neplní-li Další zpracovatel své povinnosti v oblasti ochrany údajů, odpovídá Objednateli za plnění povinností dotčeného Dalšího zpracovatele i nadále plně Zhotovitel.

Zhotovitel musí zavést a dokumentovat přijatá a provedená technicko-organizační opatření k zajištění ochrany Osobních údajů v souladu s Nařízením (včetně článku 30 Nařízení), Zákonem o zpracování OÚ a jinými právními předpisy.

7 POVINNOSTI PO ZÁNIKU SMLOUVY

Zhotovitel musí po zániku Smlouvy dodržovat veškeré povinnosti plynoucí z Nařízení či Zákona o zpracování OÚ vedoucí zejména k předejití jakémukoliv neoprávněnému nakládání s Osobními údaji do doby, než dle pokynů Objednatele a v souladu se Smlouvou tyto Osobní údaje Zhotovitel předá Objednateli nebo provede jejich výmaz.

Povinnost zachování důvěrné povahy Osobních údajů trvá i po ukončení Smlouvy.

Příloha č. 6 - Vzor Předávacího protokolu

Zhotovitel: Orchitech Solutions, s.r.o. Xxxxxxxxx 2660/141, 130 00 Praha 3 IČO: 28246764	Objednatel: město Zábřeh Xxxxxxxxxx xxxxxxx 000/0, 000 00 Xxxxxx XXX: 00303640
Fáze: Předmět předání:

Dne: Podpis:

Za Objednatele (přebírajícího):

Útvar:

Xxxxx a příjmení:

Příloha č. 7 - Vzor Akceptačního protokolu

Zhotovitel: Orchitech Solutions, s.r.o.		Objednatel: město Zábřeh
Xxxxxxxxx 0000/000, 000 00 Xxxxx 0		Xxxxxxxxxx xxxxxxx 000/0, 000 00 Xxxxxx
IČO: 28246764		IČO: 00303640
Předmět: Fáze:
Popis plnění:
Vyjádření Objednatele:
Neakceptováno	Akceptováno s výhradou	Akceptováno
Výhrady, popis Vad, jejich počet a kategorie: Doba pro odstranění Vad:
Za Zhotovitele Jméno a funkce: Podpis:		Jméno a funkce: Podpis:	Za Objednatele
V ……………………… dne ………………………………….

Příloha č. 8 – Zadávací dokumentace (bez příloh)