Textová podoba smlouvy - Hlídač státu.

Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud

Smlouva o poskytnutí subskripce

Číslo smlouvy Objednatele: 34226/2025-SŽ-GŘ-O8
Číslo smlouvy Poskytovatele: SŽ312505

uzavřená podle ustanovení § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve
znění pozdějších předpisů (dále jen „občanský zákoník“)
(dále jen „Smlouva“)

Objednatel: Správa železnic, státní organizace

zapsaná v obchodním rejstříku vedeném Městským soudem v Praze
pod sp. zn. A 48384

Praha 1 - Nové Město, Dlážděná 1003/7, PSČ 110 00

IČO 70994234, DIČ CZ70994234

zastoupená Ing. Davidem Miklasem, ředitelem organizační
jednotky SŽT

Poskytovatel: GEOKOD Rail s.r.o.

Zapsaný v obchodním rejstříku u krajského soudu v Ostravě, oddíl

C, Vložka 82736

Sídlo: Radniční 165/54, 715 00 Ostrava

IČO 09323261, DIČ CZ09323261

Bankovní spojení: XXX

Číslo účtu: XXX

zastoupená Ing. Miroslavem Konečným, jednatelem

(Objednatel a Poskytovatel dále tak jako „Smluvní strany“ nebo „Strany“)

Tato Smlouva je uzavřena na základě výsledků výběrového řízení veřejné zakázky s názvem
„Subskripce SW RailOffice pro WKokes“, č.j. veřejné zakázky 28437/2025-SŽ-GŘ-O8
(dále jen „Veřejná zakázka“). Jednotlivá ustanovení této Smlouvy tak budou vykládána v
souladu se zadávacími podmínkami Veřejné zakázky.

1. Předmět Smlouvy
1.1.
Předmětem Smlouvy je povinnost Poskytovatele zajištovat a udržovat originální
podporu (maintenance) pro Předmět subskripce od autorizovaného distributora nebo
výrobce Předmětu subskripce, což je Software, jehož parametry a vlastnosti jsou blíže
specifikované v Příloze č. 1 Specifikace Plnění. Předmět subskripce musí být v souladu
s Přílohou č. 1 Specifikace Plnění a Přílohou č. 3 Platforma SŽ (včetně jejích příloh).
Ustanovení Přílohy č. 1 Specifikace Plnění mají přednost před zněním Přílohy č. 3
Platforma SŽ (včetně jejích příloh).

1/7 Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1
IČO: 709 94 234 DIČ: CZ 709 94 234
zapsána v obchodním rejstříku vedeném Městským www.spravazeleznic.cz
soudem v Praze, spisová značka A 48384
1.2. Poskytovatel je povinen v rámci poskytování Subskripce:

1.3. a. dodat a Instalovat Předmět subskripce do IT prostředí objednatele;
2.
2.1. b. udělit nebo zajistit (společně též „poskytnout“) podporu (maintenance) pro
Předmět subskripce obsahující provádění činností v souladu s Přílohou č. 1
Specifikace Plnění, včetně zpřístupňování Aktualizací, Modernizací anebo
Zásadních modernizací a pravidelně informovat Objednatele o dostupných
Aktualizacích, Modernizacích, Zásadních modernizacích, a to nejpozději do
deseti (10) dnů ode dne jejich zpřístupnění výrobcem Předmětu subskripce;

c. zaslat či jinak zpřístupnit Objednateli kódy, klíče či jiné prostředky umožňující
využití jakékoliv Aktualizace, Modernizace anebo Zásadní modernizace
Předmětu subskripce a Subskripce (včetně umožnění ověření originálnosti a
pravosti u autorizovaného distributora nebo výrobce Předmětu subskripce, a to
i opakovaně dle potřeb Objednatele) a udržovat aktuální přístupové kódy,
přístupy a klíče po dobu trvání Subskripce;

d. poskytnout oprávnění užít jakékoliv Aktualizace, Modernizace anebo Zásadní
modernizace poskytnuté v rámci subskripce;

e. registrovat a aktivovat subskripci v elektronickém systému výrobce subskripce
či v elektronickém účtu Objednatele, je-li zřízen;

f. poskytovat Objednateli služby sestávající zejména, nikoliv však výlučně, z
následujících činností, které je Poskytovatel povinen provádět:

i. provozování Helpdesku umožňujícího komunikaci Stran a mající funkce

dále stanovené v této Smlouvě;

ii. udržování aktuální Dokumentace k Předmětu subskripce;

iii. podpora a správa Předmětu subskripce sestávající z řešení Incidentů
spojených s provozem Předmětu subskripce poskytnutou v souladu
s Přílohou č. 1 Specifikace Plnění;

g. poskytnutí oprávnění užít veškerý Software poskytnutý v rámci Subskripce,

(„Plnění“).

Objednatel je povinen platit za řádně a včas provedené Plnění dohodnutou Cenu.

Povinnosti Poskytovatele

Poskytovatel se zavazuje zejména, nikoliv však výlučně:

a. písemně anebo prostřednictvím Helpdesku projednávat s Objednatelem postup
prací a vždy oznámit Objednateli, jaká je požadovaná součinnost Objednatele
a jaký je její požadovaný rozsah;

b. chránit data v Databázích před ztrátou nebo poškozením a přistupovat k nim
a užívat je pouze v souladu s touto Smlouvou, obecně závaznými právními
předpisy a zájmy Objednatele;

c. v případě ukončení trvání Smlouvy jako celku či její části předat Objednateli
veškerá data, týkající se ukončované části Smlouvy a poskytnout další
nezbytnou součinnost při ukončení Smlouvy v souladu s touto Smlouvou, a po
splnění výše uvedeného včetně převzetí daných dat a dokumentů
Objednatelem taková data a dokumenty nejpozději do pěti (5) dnů od potvrzení
splnění povinností Objednatelem smazat, jsou-li uložena kdekoliv v systému
Poskytovatele;

d. zajistit veškerá nutná uzavření prováděcích smluv s výrobcem Předmětu
subskripce, zaplatit veškeré daně, odvody, poplatky a obstarat veškerá
povolení, Licence a souhlasy vyžadované obecně závaznými právními předpisy
ve vztahu k poskytování Plnění;

2/7
2.2. e. být po celou dobu trvání této Smlouvy certifikovaným (případně
autorizovaným) či jinak oprávněným partnerem / distributorem / vývojářem /
3. nositelem práv výrobce Předmětu subskripce v minimálním rozsahu
3.1. dostatečném pro poskytování Plnění dle této Smlouvy. V případě ztráty takové
3.2. certifikace či partnerství je Poskytovatel povinen tuto skutečnost neprodleně
3.3. oznámit Objednateli a vyvinout veškerou nezbytnou činnost k znovunabytí
3.4. takové certifikace či partnerství.
4.
4.1. Poskytovatel se zavazuje nejpozději do deseti (10) dnů od zániku smluvního vztahu
založeného touto Smlouvou z jakéhokoliv důvodu předat Objednateli:
4.2.
a. aktualizovanou Dokumentaci;

b. seznam platných administrátorských účtů k Software, Databázím a platných
hesel k nim;

c. úplnou knowledge base týkající se poskytování paušálních služeb (vč. popisu
uzavřených požadavků v Helpdesku);

d. aktuální seznam standardních provozních úkonů pro údržbu Software;

e. soupis nedokončených servisních zásahů ke dni zániku smluvního závazkového
vztahu založeného Smlouvou a návrh postupu potřebného pro jejich dokončení;

f. seznam platných Poskytovatelových uživatelských účtů a souvisejících
technických prostředků;

g. v případě předčasného ukončení Smlouvy vypracovat kalkulaci finanční
hodnoty provedeného plnění a návrh finančního vypořádání, zejména s
přihlédnutím k okamžiku zániku smluvního závazkového vztahu založeného
Smlouvou a k měsíčním výkazům předcházejícím zániku smluvního
závazkového vztahu.

Doba a místo plnění

Poskytovatel se zavazuje poskytnout Objednateli subskripci ode dne nabytí účinnosti
této Smlouvy.

Poskytovatel se zavazuje poskytovat Objednateli subskripci po dobu 36 měsíců ode
dne nabytí účinnosti této smlouvy.

Místem plnění je IT prostředí objednatele, které je popsáno v Příloze č. 3 Platforma
SŽ (včetně jejích příloh).

Služby budou poskytovány formou vzdáleného přístupu k Systému a IT prostředí
Objednatele. Objednatel se zavazuje umožnit Poskytovateli vzdálený přístup k
Systému a IT prostředí Objednatele prostřednictvím přihlašovacích údajů udělených
konkrétním osobám provádějícím Plnění za Poskytovatele dle rozhodnutí Objednatele.

Poskytnutí součinnosti při ukončení Smlouvy

Poskytovatel se zavazuje dle pokynů Objednatele v období až jednoho (1) měsíce po
zániku smluvního vztahu založeného touto Smlouvou (z jakéhokoliv důvodu)
provádět činnosti spočívající v:

a. přípravě a předání Předmětu subskripce novému poskytovateli Subskripce,

b. předání dat ve struktuře uložené v Předmětu subskripce anebo v Předmětu
subskripce včetně Databází tak, aby tato data a Databáze byly spustitelné
v jiném databázovém nástroji či Software (ve formátu způsobilém provedení
takového exportu a rozbalení Databáze bez ztráty pravosti a správnosti dat), a
to dle pokynu Objednatele

(„Součinnost při ukončení“).

Cena za Součinnost při ukončení je zahrnuta v Ceně subskripce a za její poskytnutí
nenáleží další odměna. Maximální rozsah Součinnosti při ukončení je dvacet (20)

3/7
4.3. Člověkohodin za celou dobu poskytování Součinnosti při ukončení dle této Smlouvy.
4.4.
Poskytovatel se zavazuje součinnost dle tohoto článku poskytovat s odbornou péčí,
4.5. zodpovědně, a to do doby úplného převzetí služeb novým poskytovatelem, nejdéle
4.6. však do uplynutí sjednané doby poskytování Součinnosti při ukončení.
5.
5.1. V případě, že dojde k uzavření nové smlouvy týkající se Plnění s novým
5.2. poskytovatelem odlišným od Poskytovatele, zavazuje se Poskytovatel v období
5.3. poskytování Součinnosti při ukončení poskytovat Objednateli nebo jím určeným
6. třetím stranám veškerou součinnost potřebnou pro účely plynulého a řádného
6.1. poskytování plnění či jejich příslušné části novým poskytovatelem. Poskytovatel se
6.2. zavazuje tuto součinnost poskytovat s odbornou péčí, bez zbytečného odkladu a
zodpovědně, a to až do uplynutí doby Součinnosti při ukončení nebo vyčerpání jeho
6.3. rozsahu. Poskytovatel se zavazuje reagovat na požadavek Objednatele nebo jím
6.4. určené třetí strany a zahájit poskytování součinnosti dle tohoto článku nejpozději do
6.5. tří (3) pracovních dnů ode dne doručení takovéhoto požadavku.

6.6. V případě, že po zániku smluvního vztahu založeného touto Smlouvou bude novým
poskytovatelem Poskytovatel, nebude Součinnost při ukončení realizována.
6.7.
Další podmínky pro provedení Poskytnutí součinnosti při ukončení jsou uvedeny v
7. Příloze č. 1 Specifikace Plnění.
7.1.
Kontaktní osoby

Kontaktními osobami za účelem plnění této Smlouvy jsou za Poskytovatele XXX.

Kontaktními osobami za účelem plnění této Smlouvy jsou za Objednatele XXX,

Kontaktní osobou Objednatele pro oblast kybernetické bezpečnosti je XXX.

Cena a platební podmínky

Cena za předmět Plnění dle této Smlouvy je sjednána v souladu s nabídkovou cenou,
kterou Poskytovatel uvedl ve své nabídce k Veřejné zakázce.

Objednatel je povinen zaplatit Poskytovateli za Plnění cenu uvedenou v příloze č. 2
Cena Plnění („Cena“). Výše DPH může být uplatněna v rozdílné výši, než je uvedeno
v závislosti na platných právních předpisech ke dni zdanitelného plnění, v takovém
případě není zapotřebí uzavírat dodatek k této Smlouvě.

Podrobný rozpis Ceny dle jednotlivých částí Plnění je uveden v Příloze č. 2 Cena
Plnění.

Cena je výslovně sjednávána jako nejvyšší možná a nepřekročitelná.

Cena bude fakturována následovně:

a. 1. splátka – do 30 dnů ode dne nabytí účinnosti této Smlouvy ve výši 1/3 Ceny;

b. 2. splátka – 1 rok ode dne nabytí účinnosti této Smlouvy ve výši 1/3 Ceny;

c. 3. splátka – 2 roky ode dne nabytí účinnosti této Smlouvy ve výši 1/3 Ceny.

Podmínkou uhrazení 2. a 3. splátky je akceptace plnění za předchozí období ze strany
Objednatele formou akceptačního protokolu s vyznačením „akceptováno“, který bude
podepsán odpovědnými zástupci obou smluvních stran. Podepsaný akceptační
protokol bude přílohou každé faktury.

Faktury uhradí Objednatel Poskytovateli do 30 kalendářních dnů ode dne jejich
doručení Objednateli. V případě, že faktura nebude mít odpovídající náležitosti, je
Objednatel oprávněn ve lhůtě splatnosti ji vrátit Poskytovateli s vytknutím
nedostatků, aniž by se dostal do prodlení se splatností. Lhůta splatnosti počíná běžet
znovu od okamžiku doručení opravené či doplněné faktury Objednateli.

Práva duševního vlastnictví

Pro Standardní Software, který je Předmětem subskripce, platí článek 6.5. Přílohy č.

4/7
8. 5 Zvláštní obchodní podmínky.
8.1.
9. Helpdesk
9.1.
10. Poskytovatel bude poskytovat Helpdesk v režimu 4 ve smyslu čl. 10.3. Přílohy č. 5
10.1. Zvláštní obchodní podmínky.
11.
11.1. Servisní model

11.2. Poskytovatel bude poskytovat servisní model v režimu C1 ve smyslu čl. 12. 2. Přílohy
č. 5 Zvláštní obchodní podmínky.
11.3.
11.4. Ochrana osobních údajů

Pokud bude v rámci plnění této Smlouvy docházet ke zpracování osobních údajů,
zavazuje se Poskytovatel dodržovat opatření dle článku 21. Přílohy č. 5 Zvláštní
obchodní podmínky.

Střet zájmů, povinnosti Poskytovatele v souvislosti s konfliktem na Ukrajině

Poskytovatel prohlašuje, že není obchodní společností, ve které veřejný funkcionář
uvedený v ust. § 2 odst. 1 písm. c) zákona č. 159/2006 Sb., o střetu zájmů, ve znění
pozdějších předpisů (dále jen „Zákon o střetu zájmů“) nebo jím ovládaná osoba
vlastní podíl představující alespoň 25 % účasti společníka v obchodní společnosti, a
že žádní poddodavatelé, jimiž prokazoval kvalifikaci v zadávacím řízení na zadání
Veřejné zakázky, nejsou obchodní společností, ve které veřejný funkcionář uvedený
v ust. § 2 odst. 1 písm. c) Zákona o střetu zájmů nebo jím ovládaná osoba vlastní
podíl představující alespoň 25 % účasti společníka v obchodní společnosti.

Poskytovatel prohlašuje, že:

a. on, ani žádný z jeho poddodavatelů, nejsou osobami, na něž se vztahuje zákaz
zadání veřejné zakázky ve smyslu § 48a zákona č. 134/2016 Sb., o zadávání
veřejných zakázek, ve znění pozdějších předpisů,

b. on, ani žádný z jeho poddodavatelů nebo jiných osob, jejichž způsobilost byla
využita ve smyslu evropských směrnic o zadávání veřejných zakázek, nejsou
osobami dle článku 5k nařízení Rady (EU) č. 833/2014 ze dne 31. července
2014 o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím
situaci na Ukrajině, ve znění pozdějších předpisů, jimž se zakazuje zadat nebo
dále plnit jakoukoli veřejnou zakázku nebo koncesní smlouvu spadající do
oblasti působnosti směrnic o zadávání veřejných zakázek, jakož i čl. 10 odst.
1, 3, odst. 6 písm. a) až e), odst. 8, 9 a 10, článků 11, 12, 13 a 14 směrnice
2014/23/EU, článku 7 písm. a) až d), článku 8, čl. 10 písm. b) až f) a písm. h)
až j) směrnice 2014/24/EU, článku 18, čl. 21 písm. b) až e) a písm. g) až i),
článků 29 a 30 směrnice 2014/25/EU a čl. 13 písm. a) až d), f) až h) a j)
směrnice 2009/81/ES a hlavy VII nařízení Evropského parlamentu a Rady (EU,
Euratom) 2018/1046,

c. on, ani žádný z jeho poddodavatelů nebo jiných osob, jejichž způsobilost byla
využita ve smyslu evropských směrnic o zadávání veřejných zakázek, nejsou
osobami dle článku 2 nařízení Rady (EU) č. 269/2014 ze dne 17. března 2014,
o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím
územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění pozdějších
předpisů, a dalších prováděcích předpisů k tomuto nařízení Rady (EU) č.
269/2014 anebo osobami dle čl. 2 nařízení uvedených v odstavci 11.5 této
Smlouvy (dále jen „Sankční seznamy“).

Je-li Poskytovatelem sdružení více osob, platí podmínky dle odstavce 11.1 a 11.2 této
Smlouvy také jednotlivě pro všechny osoby v rámci Poskytovatele sdružené, a to bez
ohledu na právní formu tohoto sdružení.

Přestane-li Poskytovatel nebo některý z jeho poddodavatelů nebo jiných osob, jejichž
způsobilost byla využita ve smyslu evropských směrnic o zadávání veřejných zakázek,
splňovat podmínky dle tohoto článku Smlouvy, oznámí tuto skutečnost bez

5/7
11.5. zbytečného odkladu, nejpozději však do 3 pracovních dnů ode dne, kdy přestal
splňovat výše uvedené podmínky, Objednateli.
11.6.
Poskytovatel se dále zavazuje postupovat při plnění této Smlouvy v souladu s
11.7. nařízením Rady (ES) č. 765/2006 ze dne 18. května 2006 o omezujících opatřeních
vzhledem k situaci v Bělorusku a k zapojení Běloruska do ruské agrese proti Ukrajině,
12. ve znění pozdějších předpisů, nařízením Rady (EU) č. 208/2014 ze dne 5. března
12.1. 2014 o omezujících opatřeních vůči některým osobám, subjektům a orgánům
vzhledem k situaci na Ukrajině, ve znění pozdějších předpisů, a dalších prováděcích
12.2. předpisů k těmto nařízením.
13.
13.1. Poskytovatel se dále zavazuje, že finanční prostředky ani hospodářské zdroje, které
13.2. obdrží od Objednatele na základě této Smlouvy a jejích případných dodatků,
13.3. nezpřístupní přímo ani nepřímo fyzickým nebo právnickým osobám, subjektům či
13.4. orgánům s nimi spojeným uvedeným v Sankčních seznamech, nebo v jejich
13.5. prospěch.
13.6.
Ukáže-li se jakékoliv prohlášení Poskytovatele dle tohoto článku Smlouvy jako
13.7. nepravdivé nebo poruší-li Poskytovatel svou oznamovací povinnost nebo některou
z dalších povinností dle tohoto článku Smlouvy, je Objednatel oprávněn vypovědět
tuto Smlouvu bez výpovědní doby. Poskytovatel je dále povinen zaplatit za každé
jednotlivé porušení povinností dle předchozí věty smluvní pokutu ve výši 100.000,-
Kč. Ustanovení § 2050 Občanského zákoníku se nepoužije.

Compliance

Smluvní strany stvrzují, že při uzavírání této Smlouvy jednaly a postupovaly čestně
a transparentně a zavazují se tak jednat i při plnění této Smlouvy a veškerých
činnostech s ní souvisejících. Každá ze Smluvních stran se zavazuje jednat v souladu
se zásadami, hodnotami a cíli compliance programů a etických hodnot druhé Smluvní
strany, pakliže těmito dokumenty dotčené Smluvní strany disponují, a jsou
uveřejněny na webových stránkách Smluvních stran.

Správa železnic, státní organizace, má výše uvedené dokumenty k dispozici na
webových stránkách: https://www.spravazeleznic.cz/o-nas/nezadouci-jednani-a-
boj-s-korupci.

Závěrečná ustanovení

Ustanovení Přílohy č. 3 Platforma SŽ (včetně jejích příloh) mají přednost před
ustanoveními obchodních podmínek uvedených v odst. 13.2. tohoto článku.

Smlouva se řídí Obchodními podmínkami Objednatele a Zvláštními obchodními
podmínkami. Ustanovení Zvláštních obchodních podmínek mají přednost před
ustanoveními Obchodních podmínek, pokud jsou ustanovení těchto dokumentů v
rozporu, uplatní se ustanovení uvedené ve Zvláštních obchodních podmínkách.

Odchylná ujednání v této Smlouvě mají přednost před ustanoveními Obchodních
podmínek a Zvláštních obchodních podmínek.

Tuto Smlouvu lze měnit pouze písemnými dodatky.

Tato Smlouva nabývá platnosti okamžikem podpisu poslední ze Stran. Je-li Smlouva
uveřejňována v registru smluv, nabývá účinnosti dnem uveřejnění v registru smluv,
jinak je účinná od okamžiku uzavření.

Tato Smlouva je vyhotovena v elektronické podobě, přičemž obě Smluvní strany
obdrží její elektronický originál opatřený elektronickými podpisy. V případě, že tato
Smlouva z jakéhokoli důvodu nebude vyhotovena v elektronické podobě, bude
sepsána ve třech vyhotoveních, přičemž jedno vyhotovení obdrží Poskytovatel a dvě
vyhotovení Objednatel.

Smluvní strany berou na vědomí, že tato Smlouva podléhá uveřejnění v registru
smluv podle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých
smluv, uveřejňování těchto smluv a o registru smluv, ve znění pozdějších předpisů

6/7
(dále jen „ZRS“), a současně souhlasí se zveřejněním údajů o identifikaci smluvních
stran, předmětu Smlouvy, jeho ceně či hodnotě a datu uzavření této Smlouvy.

13.8. Zaslání Smlouvy správci registru smluv k uveřejnění v registru smluv zajišťuje
obvykle Objednatel. Nebude-li tato Smlouva zaslána k uveřejnění a/nebo uveřejněna
prostřednictvím registru smluv, není žádná ze smluvních stran oprávněna požadovat
po druhé smluvní straně náhradu škody ani jiné újmy, která by jí v této souvislosti
vznikla nebo vzniknout mohla.

13.9. Smluvní strany výslovně prohlašují, že údaje a další skutečnosti uvedené v této
Smlouvě, vyjma částí označených ve smyslu následujícího odstavce této Smlouvy,
nepovažují za obchodní tajemství ve smyslu ustanovení § 504 Občanského zákoníku
(dále jen „obchodní tajemství“), a že se nejedná ani o informace, které nemohou
být v registru smluv uveřejněny na základě ustanovení § 3 odst. 1 ZRS.

13.10. Jestliže smluvní strana označí za své obchodní tajemství část obsahu Smlouvy, která
v důsledku toho bude pro účely uveřejnění Smlouvy v registru smluv znečitelněna,
nese tato smluvní strana odpovědnost, pokud by Smlouva v důsledku takového
označení byla uveřejněna způsobem odporujícím ZRS, a to bez ohledu na to, která ze
stran Smlouvu v registru smluv uveřejnila. S částmi smlouvy, které druhá smluvní
strana neoznačí za své obchodní tajemství před uzavřením této Smlouvy, nebude
Objednatel jako s obchodním tajemstvím nakládat a ani odpovídat za případnou
škodu či jinou újmu takovým postupem vzniklou. Označením obchodního tajemství
ve smyslu předchozí věty se rozumí doručení písemného oznámení druhé smluvní
strany Objednateli obsahujícího přesnou identifikaci dotčených částí Smlouvy včetně
odůvodnění, proč jsou za obchodní tajemství považovány. Druhá smluvní strana je
povinna výslovně uvést, že informace, které označila jako své obchodní tajemství,
naplňují současně všechny definiční znaky obchodního tajemství, tak jak je vymezeno
v ustanovení § 504 občanského zákoníku, a zavazuje se neprodleně písemně sdělit
Objednateli skutečnost, že takto označené informace přestaly naplňovat znaky
obchodního tajemství.

13.11. Osoby uzavírající tuto Smlouvu za Smluvní strany souhlasí s uveřejněním svých
osobních údajů, které jsou uvedeny v této Smlouvě, spolu se Smlouvou v registru
smluv. Tento souhlas je udělen na dobu neurčitou.

13.12. Nedílnou součástí této Smlouvy jsou její přílohy:

č. 1. Specifikace Plnění
č. 2. Cena plnění
č. 3. Platforma SŽ (včetně jejích příloh)
č. 4. Poddodavatelé
č. 5. Zvláštní obchodní podmínky
č. 6. Obchodní podmínky

Za Objednatele: Za Poskytovatele:

elektronicky podepsáno 29. 5. 2025 elektronicky podepsáno 10. 6. 2025
…………………………………………………… …………………………………………………

Ing. David Miklas Ing. Miroslav Konečný

ředitel organizační jednotky SŽT jednatel společnosti

7/7
Příloha č. 1 Smlouvy

Bližší specifikace předmětu plnění

Předmět plnění:

- Zajištění předplatného pro portfolio licencí SW RailOffice pro Wkokes.
- Subscription rovněž zahrnuje i maintenance a technickou podporu.
- Maintenance umožňuje uživatelům získat během doby trvání všechny upgrady

programu RailOffice pro Wkokes pro příslušný typ a počet licencí uvedených v portfoliu
SŽ zdarma.

Portfolio SW RailOffice pro Wkokes ve Správě železnic počet
klíče
Portfolio SŽ
Lokální 8
Desktop licence
licence
Síťové 32
Plovoucí licence
40
CELKEM

Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1 Správa železniční telematiky
zapsána v obchodním rejstříku vedeném Městským IČO: 709 94 234 DIČ: CZ 709 94 234 V Celnici 1028/10
soudem v Praze, spisová značka A 48384 spravazeleznic.cz 110 00 Praha 1

1/1
Příloha č. 2 Smlouvy Cena za 1 rok bez DPH Cena za 3 roky bez DPH
480 000,00 Kč
Ceník 120 000,00 Kč 1 440 000,00 Kč
600 000,00 Kč
Název položek 360 000,00 Kč
1 800 000,00 Kč
Poskytnutí subskripce software RailOffice 1 800 000,00 Kč
pro Wkokes včetně aplikačních modulů 378 000,00 Kč
Technická podpora a maintenance 2 178 000,00 Kč

Celková cena za všechny položky
Celková nabídková cena bez DPH
Výše DPH
Celková nabídková cena včetně DPH
Platforma SŽ
Základní dokument

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 6
2 Platforma Správy železnic ......................................................................................... 6
3 Motivace Platformy SŽ.............................................................................................. 6
4 Architektonické principy............................................................................................ 7

4.1 Bezpečnost a soulad s vnitropodnikovými p edpisy............................................. 7
4.2 Auditní záznamy ............................................................................................ 7
4.3 Provozovatelnost ešení .................................................................................. 8
4.4 Znovupoužitelnost ešení ................................................................................ 8
4.5 Nezávislost na dodavatelích............................................................................. 9
4.6 Nákup a vývoj ............................................................................................... 9
4.7 Business kontinuita .......................................................................................10
5 Služby Platformy SŽ................................................................................................10
5.1 Infrastrukturní služby ....................................................................................10
5.2 Platformní služby ..........................................................................................10
5.3 Podpůrné služby ...........................................................................................10

5.3.1 Bezpečnostní služby .........................................................................10
5.3.2 Služby monitoringu ..........................................................................11
5.3.3 Služby patch managementu ..............................................................11
5.3.4 Služby zálohování ............................................................................11
5.3.5 Síťové služby...................................................................................11
6 Technologie Platformy SŽ ........................................................................................12
7 P ílohy Platformy SŽ ...............................................................................................13

2/14 Platforma SŽ – Základní dokument
Seznam zkratek

AD Rozši itelná a škálovatelná adresá ová služba, která umožňuje efektivně uspo ádat
síťové prost edky. Kromě informací o objektech v počítačové síti (uživatelské účty,
API počítače, tiskárny) umožňuje používat stromovou strukturu objektů, nastavovat
CEF globálně systémové politiky, instalovat programy na počítače nebo aplikovat kritické
CIFS aktualizace v celé organizační struktu e. Má úzkou vazbu na DNS (Active Directory)
CSV
DB Komplexně definované komunikační rozhraní aplikace (Application Programming
DB Inteface)
DB
DBMS Datový formát pro uložení logů (Common Event Format)
DNS
Síťový komunikační protokol pro p enos souborů. Kompatibilní se SMB verze 1.0
HTTP (Common Internet File System)
HTTPS
HW Jednoduchý textový souborový formát (Comma-separated values)
IaaS Databázový software/aplikace/entita/instance, která je zpravidla provozována na
databázovém serveru (Database Entity)
ICMP
Soubor datových objektů v elektronické formě uložených společně podle jednoho
ICT schématu a zp ístupňovaných počítačem (Database)
IPMI Komponenta DBMS umožňující operace s daty v databázi. Mnohé DBMS podporují více
IT DB enginů s různými vlastnostmi a specifiky (Database Engine, Storage Engine)
JDBC Systém ízení databáze (Database Management System)
JSON
Distribuovaný hierarchický jmenný systém používaný v síti Internet. P ekládá názvy
LEEF domén na číselné IP adresy a zpět, obsahuje informace o tom, které stroje poskytují
MFA p íslušnou službu (Domain Name System)
NFS Standardizovaný protokol pro p enos webových stránek (Hyper-text Transfer Protokol)
OS Standardizovaný zabezpečený protokol pro p enos webových stránek (Secured Hyper-
PaaS text Transfer Protokol)

Hardware označuje veškeré fyzicky existující technické vybavení počítače

Typ cloudové služby, který poskytuje zákazníkům základní IT infrastrukturu jako
službu, včetně serverů, úložiště, sítě a virtuálních počítačů. Tyto služby se často
poskytují prost ednictvím Internetu a umožňují zákazníkům snadno a rychle využívat
IT infrastrukturu bez nutnosti jejího nákupu, instalace a správy. Mezi nejznámější
poskytovatele IaaS pat í Amazon Web Services, Microsoft Azure a Google Cloud
Platform (Infrastructure as a Service)

Síťový protokol, který slouží ke komunikaci mezi síťovými prvky (jako jsou routery)
a k odesílání zpráv o stavu sítě. Tyto zprávy obsahují informace o stavu spojení, jako
jsou nap íklad informace o chybách nebo omezeních v síti. ICMP se často používá
k diagnostice a ešení problémů v síti, nap íklad k zjišťování, zda je určitý cíl dostupný
nebo zda existuje cesta k němu (Internet Control Message Protocol)

Informační a komunikační technologie (Information and Communication Technology)

Standardizovaný protokol pro vzdálený dohled a management fyzických za ízení

Informační technologie (Information Technology)

API v jazyce Java pro jednotné rozhraní k relačním databázím (Java Database
Connectivity)

Datový formát primárně určený pro p enos dat. Jedná se o způsob zápisu dat nezávislý
na počítačové platformě, která mohou být organizována v polích nebo agregována v
objektech (JavaScript Object Notation)

Datový formát pro uložení logů (Log Event Extended Format)

Více-faktorové ově ení identity uživatele (Multi-Factor Authentification)

Síťový souborový protokol primárně pro p ipojení vzdálených souborových systémů
(Network File System)

Operační systém (Operating System)

Typ cloudové služby, která poskytuje vývojá ům a IT týmům platformu pro vývoj,
nasazení a správu aplikací bez nutnosti starat se o správu hardwaru a infrastruktury.
Poskytovatelé PaaS nabízejí vývojové nástroje, databáze, síťové služby a další nástroje
jako služby, což umožňuje vývojá ům se soust edit pouze na vývoj aplikace (Platform
as a Service)

Platforma SŽ – Základní dokument 3/14
PAM ešení zabezpečení identit, které pomáhá chránit organizaci p ed kybernetickými
PoC hrozbami monitorováním, zjišťováním a prevencí neoprávněného privilegovaného
p ístupu k důležitým prost edkům (Privileged Access Management)
REST/API
RFC Tento pojem se pro p edběžné vyzkoušení určitého návrhu (zpravidla na reálných
datech či jejich výběru), aby došlo k vyzkoušení nebo p edvedení použité logiky
S2S VPN a proveditelnosti návrhu ešení. V podstatě se může jednat o testovací realizaci
SCCM nějakého konkrétního návrhu zpravidla ve zjednodušených podmínkách. Cílem PoC je
ukázat, že návrh je technicky proveditelný a že má potenciál být úspěšný (Proof of
SFTP Concept)
SLA
SMB Webově založené klient-server API (Representational State Transfer)
SNMP
Soubor standardů zejména pro oblast sítí, počítačů a Internetu. RFC jsou považovány
SW spíše za doporučení než normy či standardy v tradičním smyslu jako jsou nap íklad
SŽ normy ČSN nebo ISO, avšak v zájmu interoperability jsou dodržovány (Request For
SŽT Comments)
UAS
VoKB Šifrované VPN p ipojení zajišťující propojení dvou LAN (Site-to-Site VPN, LAN-to-LAN
VPN)
VPN
SCCM je softwarový nástroj společnosti Microsoft určený pro správu a nasazení
WEC koncových za ízení a softwarových aplikací v prost edí Windows. SCCM umožňuje
WEF centrální správu a monitorování koncových za ízení, aktualizace softwaru a operačních
XDR systémů, správu konfiguračních položek a politik, sledování bezpečnostních opat ení a
mnoho dalšího. SCCM může být použit v podnikovém prost edí pro správu tisíců
ZoKB koncových za ízení, od stolních a notebooků až po mobilní za ízení a servery (System
Center Configuration Manager)

Zabezpečený protokol pro p enos souborů. Pro zajištění šifrování využívá protokol SSH
(SSH File Transfer Protocol)

Smluvní nastavení záruk, úrovně, dostupnosti a kvality služeb atd.
(Service-Level Agreement)

Komunikační protokol pro p enos souborů. Lidově nazývaný Samba (Server Message
Block)

Jedná se o protokol pro správu sítí na úrovni aplikační vrstvy síťového OSI modelu,
který umožňuje správcům sítě monitorovat a ídit chod síťových za ízení, jako jsou
routery, switche a průmyslové kontroléry. Protokol umožňuje správcům sítě získat
informace o stavu za ízení, jako jsou statistiky paketů, využití zdrojů a stav služeb,
a měnit nastavení za ízení na dálku (Simple Network Management Protocol)

Programové vybavení počítače či jiného obdobného za ízení. Speciálním druhem
software je firmware, který je úzce spjatý s konkrétním hardwarem (Software)

Správa železnic, státní organizace

Správa železniční telematiky, organizační jednotka

Logická uživatelsko-aplikační síť SŽ, zahrnuje VRF v MPLS sítích a lokální VLAN, běžně
se nazývá také „Intranet SŽ“

Vyhláška č. 82/2018 Sb., o bezpečnostních opat eních, kybernetických bezpečnostních
incidentech, reaktivních opat eních, náležitostech podání v oblasti kybernetické
bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších
p edpisů

Virtuální privátní síť – prost edek pro důvěryhodné propojení komponent informačního
systému v rámci obecně nezabezpečené komunikační sítě. P i navazování spojení je
obvykle vyžadována autentizace, komunikace je většinou šifrována (Virtual Private
Network)

Technologie p edávání logů v prost edí Microsoft Windows (Windows Event Collector)

Technologie p edávání logů v prost edí Microsoft Windows (Windows Event Forwarder)

Koncepce bezpečnosti informačních technologií, která integruje různé nástroje
a technologie pro detekci a reakci na hrozby v jednotném systému. Cílem XDR je
zlepšit schopnost detekovat a reagovat na hrozby v celém IT prost edí, včetně
cloudových a on-premise systémů. Funkce XDR zahrnují automatickou detekci hrozeb,
škálovatelnou analýzu, pokročilou vizualizaci a integraci s jinými bezpečnostními
technologiemi (Extended Detection and Response)

Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů
(zákon o kybernetické bezpečnosti), ve znění pozdějších p edpisů

4/14 Platforma SŽ – Základní dokument
Seznam vysvětlivek

Build Označení konkrétní verze software, zpravidla operačního systému.
Disaster Recovery Plán obnovy po havárii, součást kontinuity IT služeb.
Log Management Systém centrálního sběru a ukládání logů
Platforma SŽ Soubor dokumentů, rozdělený na ve ejnou, interní a metodickou část, určený
pro seznámení dodavatelů se standardy a technologiemi v ICT prost edí SŽ.
Syslog Standardizovaný formát pro ukládání a p edávání logů

Platforma SŽ – Základní dokument 5/14
1 Úvod

Cílem tohoto dokumentu je definovat Platformu SŽ, jakožto souhrn podporovaných
infrastrukturních služeb, technologií, a architektonických principů, která určuje základní rámec
pro návrh ešení ICT jako celku. Platforma SŽ podporuje naplnění strategických cílů IS/ICT
Správy železnic, zejména v oblasti efektivního provozu a rozvoje ICT prost edí Správy železnic.

2 Platforma Správy železnic

Platforma Správy železnic definuje prost edí, které standardizuje a podporuje návrh,
implementaci a provozování veškerého ICT ešení pro Správu železnic. Popisuje infrastrukturní a
platformní služby, podporované technologie a upravuje pravidla jejich použití i rozši ování.
Primárním cílem Platformy SŽ je poskytnout potenciálním dodavatelům základní p ehled o ICT
prost edí SŽ a současně umožnit organizaci SŽ zajištění efektivního vytvá ení a provozování ICT
ešení p i dodržení vysoké kvality a bezpečnosti služeb.

Dokument včetně p íloh je udržován a pravidelně aktualizován organizační jednotkou SŽT.

Platforma SŽ obsahuje:

• Základní popis ICT prost edí (v jednotlivých p ílohách)
• Architektonické principy SŽ
• P ehled služeb Platformy SŽ
• P ehled technologií Platformy SŽ (v jednotlivých p ílohách)

P i plánování a rozši ování ICT ešení je nutné respektovat všechny části Platformy SŽ, které se
daného ešení dotýkají. Jednotlivé p ílohy se pak detailně zabývají vybranými oblastmi
od serverové a síťové infrastruktury, p es softwarový vývoj až po integrace, komunikaci
a zálohování.

3 Motivace Platformy SŽ

Platforma SŽ je motivovaná schválenou strategií IS/ICT SŽ, a to konkrétně cílem zajištění
dlouhodobého koncepčního rozvoje IS/ICT a jeho souladu se strategickými cíli SŽ,
a to zavedením řízení celopodnikové IS/ICT architektury1.

Cílem Správy železnic je zajistit:

• Nastavení jasných a povinných požadavků na nová navrhovaná ešení.
• Uchazeči výběrových ízení na ICT ešení mohou být hodnoceni na základě jejich celkové

ekonomické efektivity, a nikoliv pouze na základě nabídkové ceny. Podrobná pravidla
stanoví Zadávací dokumentace,
• Externí dodávky ICT ešení budou koncepčně a technologicky zapadat do
celopodnikového prost edí Správy železnic,
• Dodávané ešení bude možné bezpečně a ekonomicky efektivně provozovat v krátko-,
st edně-, i dlouhodobém časovém horizontu,
• Provozované technologie SŽ budou perspektivní, moderní a bezpečné,
• Technologická různorodost ICT prost edí SŽ bude:

o na jednu stranu dostatečně široká, aby neúměrně neomezovala soutěž
potenciálních dodavatelů, a

1 Strategie IT a ICT Správy železnic (157463/2021-SŽ-G -SŽT)

6/14 Platforma SŽ – Základní dokument
o na druhou stranu dostatečně ohraničená, aby umožnila efektivní správu systémů
jak dodavateli, tak zaměstnanci Správy železnic.

Mezi hlavní p ínosy Platformy SŽ pat í:

• Nastavení společných (minimálních/maximálních) úrovní vyspělosti jednotlivých
technologií nap íč IS/ICT SŽ a postupné omezení velkých rozdílů v úrovních používaných
technologií.

• Stanovení architektonických a technologických standardů pro tvůrce systémů a pro
uchazeče o dodávku IS/ICT pro SŽ.

• Zajištění standardizace technických prost edků.
• Zajištění ochrany p edchozích investic zamezením vzniku duplicit.
• Zajištění možnosti bezpečného p evzetí systémů do provozu a zajištění provozu interními

silami Správy železnic.

4 Architektonické principy

P i návrhu a realizaci ICT ešení je nutné respektovat a dodržet několik základních principů
a pravidel stanovených v Platformě SŽ.

4.1 Bezpečnost a soulad s vnitropodnikovými předpisy

• Navrhované ešení a procesy jím podporované musí být v souladu s legislativními
a regulatorními nároky a vnitropodnikovými p edpisy Správy železnic.
•
ešení musí umožnit monitorování akcí uživatelů, zejména jejich práce s daty
• a dokumenty.
•
• Musí být zajištěna administrovatelnost a auditovatelnost integračních vazeb.
Vývoj a test nesmí být realizován na produkčním prost edí.
• Topologie a architektura produkčního a testovacího prost edí musí být identická,
• odlišovat se může ve výkonu a použitých zdrojích.
• P ed nasazením do produkčního prost edí je ešení prokazatelně otestováno.
Nejsou realizovány integrace mezi produkčními a neprodukčními prost edími.
• Dohled a monitoring je zajištěn na všech vrstvách ešení (HW, OS, DB, aplikační server,
• aplikace, tenký a tlustý klient, koncový uživatel).
• Musí být zajištěno napojení na centrální dohledovou konzoli.
Služby poskytované do prost edí Internetu musí projít penetračním testováním.
Navrhované ešení musí využívat šifrovanou komunikaci a v p ípadě ukládání jakýchkoli
citlivých informací (hesla apod.) je ukládat v šifrované podobě. Šifrovací algoritmy musí
respektovat doporučení NÚKIB v dokumentu Minimální požadavky na kryptografické
algoritmy v aktuální verzi, která je uve ejněna na ú ední desce NÚKIB.

Zdůvodnění: Bezpečnost umožňuje chránit hodnoty Správy železnic. Ve SŽ je nutné udržovat
vysokou míru bezpečnosti, a to p edevším v oblastech, které mohou mít dopady na lidské životy.
Navrhovaná ešení také musí být nezbytně v souladu s VoKB.

4.2 Auditní záznamy

Celé ešení i jednotlivé prvky ešení (infrastrukturní prvky, aplikace, OS, webové servery,
databáze a middlewary) musí umožňovat vytvá et auditní záznamy tedy logy (záznamy nap . čas
p ihlášení uživatele, čas odhlášení, import, export souborů a podobně) a jejich p enos do
centrálního uložiště log managment v SŽ.

Veškeré činnosti v systému musí být logovány a to včetně neúspěšných pokusů. Jde zejména
o následující činnosti:

• p ihlášení a odhlášení uživatelů a administrátorů
• neúspěšný pokus o p ihlášení
• činnosti provedené administrátory

Platforma SŽ – Základní dokument 7/14
• činnosti vedoucí ke změně p ístupových oprávnění
• neprovedení činností v důsledku nedostatku p ístupových oprávnění a další neúspěšné

činnosti uživatelů
• zahájení a ukončení činností technických aktiv (nap íklad spuštění zastavení služeb)
• automatická varovná nebo chybová hlášení technických aktiv
• pokusy o manipulaci s logy a změny nastavení nástroje pro logování
• použití mechanismů identifikace a autentizace včetně změny údajů, které slouží

k p ihlášení
• operace s citlivými daty
• veškeré události spojené se změnou bezpečnostních parametrů systému

ešení musí být schopno p edávat auditní záznamy v minimálně jednom z formátů:

• CEF
• Microsoft Windows Event Log
• LEEF
• Strukturované DB view
• JSON
• CSV

Pomocí aspoň jednoho z protokolů:

• Syslog RFC5424
• WEC
• JDBC
• REST/API
• NFS
• SFTP
• CIFS/SMB
• SNMPv3

A musí obsahovat minimálně následující informace:

• časové razítko
• druh provedené akce
• unikátní identifikátor uživatele nebo služby
• zdroj události (zdrojová IP adresa/hostname komponenty systému, na které k akci došlo)

Zdůvodnění: Auditní záznamy jsou klíčovou součástí bezpečnosti. Ve SŽ je nutné zajistit vysokou
míru bezpečnosti, a to mimo jiné i auditovatelností veškerých událostí.

4.3 Provozovatelnost řešení

• ešení je provozovatelné na službách a technologiích Správy železnic.
• ešení musí umožňovat p evzetí do provozního prost edí Správy železnic
• ešení umožňuje škálování.

Zdůvodnění: Z důvodu snahy o udržitelnost provozu je stanoven udržitelný počet technologií,
které jsou spolehlivé a mají perspektivu svého rozvoje. Aplikace provozovaná na takto
definované skupině technologií tak může být v p ípadě pot eby p evzata do provozu
a spravována týmem IT specialistů SŽ, jež disponuje pat ičnými znalostmi, p ípadně vlastní
p íslušné certifikace, aby mohli tyto technologie či systémy spravovat. Tím dochází nejen ke
zvýšení produktivity, ale také k časové a finanční úspo e, p edevším z pohledu lidských zdrojů.

4.4 Znovupoužitelnost řešení

• ešení musí umožňovat logické oddělení dat pro současné využívání funkcionality
různými subjekty (tzv. multitenant).
• V rámci Správy železnic se realizuje minimalizace počtu a rozsahu používaných
technologií a aplikací.

8/14 Platforma SŽ – Základní dokument
• Snižováním počtu a rozsahu používaných technologií a aplikací snižujeme komplexitu
správy technologického a aplikačního portfolia.

• ešení je navrhované s opakováním ově ených jednoduchých návrhových vzorů
a designových principů.

• Nasazování změn a nových ešení je seskupováno dle funkcionalit a cílových systémů do
jednotlivých „release“. Termíny releasů jsou stanoveny organizační jednotkou SŽT.

• Nasazované ešení nesmí ke svému provozu vyžadovat pravidelný nutný zásah
administrátora (nap . restarty, čištění logů, ...)

Zdůvodnění: V rámci Správy železnic usilujeme o minimalizaci počtu prost edí pro stejnou
funkcionalitu. Znovupoužitelná ešení vedou k úspo e lidských, finančních, časových
i materiálních zdrojů v životním cyklu celého ešení.

4.5 Nezávislost na dodavatelích

• ešení je navrhované s ohledem na omezení či eliminaci rizika vendor-lock.
• U ešení p evzatých do provozu je cíl p evzetí schopnosti vytvo it build aplikace bez
závislosti na dodavateli.
• Usilujeme o právo zásahu do zdrojových kódů a rozvoje ešení interními kapacitami
Správy železnic nebo dalšími dodavateli. Výjimku mohou tvo it jen p ípady, kdy by
takové požadavky byly ekonomicky výrazně nevýhodné nebo je důvod se domnívat, že
tato práva budou nadbytečná.

Zdůvodnění: Nebýt závislí na malém počtu dodavatelů umožňuje SŽ být transparentní
a flexibilní. Vyšší míra flexibility je také výhodná pro vyjednávaní s jednotlivými dodavateli
o ekonomických a technických podmínkách.

4.6 Nákup a vývoj

• U nákupu standardizovaných komerčních produktů je požadována schopnost nastavení
• balíkového ešení interními kapacitami či nezávislými externími dodavateli.
• U standardizovaných agend je preferován nákup a úprava p ed zakázkovým vývojem
zcela nového zákaznického ešení.
• Vzájemné integrace musí být realizované p es aplikační middleware. Integrační scéná e
• zajišťují, aby implementace nových funkcí v ídící aplikaci minimalizovala vyvolané změny
• na straně návazných aplikací. Detailněji se integracemi zabývá P íloha 5 – Integrační
• standardy.
•
• Preferujeme p írůstkovou integraci p ed p enosem kompletních informací.
Preferujeme ešení v minimálně t ívrstvé architektu e s oddělením databázové, aplikační
• a prezentační vrstvy.
• Minimalizujeme dodávku ešení s takovými úpravami, které by omezovaly nebo
eliminovaly p echod na budoucí vyšší verze produktu.
V transakčních systémech preferujeme pouze základní operativní reporting. Plný
reporting je implementovaný v analytických nástrojích.

ešení je ádně dokumentované po stránce vývojové, provozní, administrátorské
a uživatelské.
P ípadné zdrojové kódy jsou verzovány a ově eny, že z nich je možno vytvo it interními
týmy Správy železnic plnohodnotný a funkční build aplikace. Zdrojové kódy
a dokumentace jsou ukládány na standardizované úložiště Správy železnic.
Návrh prost edí reflektuje trendy technologií a zároveň business pot eby.
Rozši ování a doplňování technologií a ICT prost edí je v souladu s normami, interními
směrnicemi a Platformou SŽ.

Zdůvodnění: Regulace nákupu a p ípadného do-vývoje integrací a aplikací slouží k co
nejsrozumitelnějšímu a transparentnímu užívání daných technologií. Díky danému postupu
v nákupu a vývoji je možné se efektivně vyrovnat s novinkami, které nově nakoupené produkty
p edstavují a efektivně je začlenit do ICT prost edí Správy železnic.

Platforma SŽ – Základní dokument 9/14
4.7 Business kontinuita

• Navržené ešení musí odpovídat kritičnosti aplikace a požadovaným parametrům SLA.
• Servisní model a parametry aplikace odpovídají bezpečnostní klasifikaci a byznysové

kritičnosti aplikace.
• Dle servisního modelu jsou definované plány obnovy („disaster recovery“ postupy).
• SLA je t eba nastavovat a mě it na celém etězci navázaných technologií a služeb.

Zdůvodnění: Správa železnic jakožto správce kritické infrastruktury státu, musí být p ipraven na
p ípadné narušení provozu, a proto musí požadovat taková ešení, která umožní zajistit
kontinuitu a obnovu klíčových procesů, činností a systémů organizace.

5 Služby Platformy SŽ

Platforma SŽ popisuje služby poskytované v rámci ICT prost edí Správy železnic, které je možné
využívat v navrhovaných a dodávaných ešeních a současně nesmí být totožné služby součástí
dodávky daného ešení mimo Platformu SŽ. Cílem je zajistit ve fázích p ípravy poptávky, návrhu
ICT ešení a realizace dodávky kompatibilitu se stávajícím ICT prost edím a v maximální mí e
využít již provozované komponenty a technologie. Tento seznam služeb a komponent je
průběžně aktualizován tak, aby byl popis ICT prost edí v největší mí e aktuální.

5.1 Infrastrukturní služby

Infrastrukturní službou je míněno poskytování IT infrastruktury na úrovni HW, virtualizace,
operačních systémů a diskových úložišť. Jedná se o obdobu cloudových IaaS.

Detailní p ehled o infrastrukturních službách je p edmětem P ílohy 3 – Virtuální prostředí,
serverové farmy a servery.

5.2 Platformní služby

Platformní služba poskytuje standardizované webové či aplikační servery, databázové platformy
či portálová ešení, která integrují webové aplikace a služby do jednoho spolupracujícího celku.
Podporuje standardizované komunikační rozhraní, protokoly a formáty dat. Jedná se o obdobu
cloudových PaaS. Platformní služby jsou v současné době dostupné jen v UAS.

Detailní p ehled o infrastrukturních službách je p edmětem P íloh Platformy SŽ.

5.3 Podpůrné služby

Podpůrné služby zajišťují komplexní správu a provoz IT infrastruktury v prost edí Správy
železnic. Jedná se nap íklad o monitorovací systémy, zálohování, patch management,
mandatorní síťové služby nebo bezpečnostní systémy.

Podpůrné služby jsou povinné k využití dodavatelem, pokud není Správou železnic určeno jinak.

5.3.1 Bezpečnostní služby

Přehled dostupných služeb bezpečnostních aplikací

Služba Popis

Antivirus Antivirové ešení F-Secure, provozované jako virtuální appliance, zajišťuje ochranu
koncových stanic a serverové infrastruktury p ed škodlivým obsahem, zejména
malwarem, exploity, síťovými útoky a jinými bezpečnostními hrozbami.
Každé datové centrum Správy železnic disponuje vlastní virtuální appliance F-Secure.
Nasazením antivirového ešení F-Secure jako virtuální appliance, jsou minimalizovány
konzumované výpočetní zdroje a dopad na výkon virtualizační infrastruktury.

PAM Privileged Access Management je ešení které pomáhá kontrolovat, monitorovat,
zabezpečit a auditovat privilegované identity p ed jejich zneužitím.
Omezení: PAM je v současné době dostupný jen v UAS.

XDR XDR monitoruje síťovou infrastrukturu pomocí sond a uživatelské chování pomocí
agentů na serverech a uživatelských stanicích. Bezpečnostní ešení XDR detekuje

10/14 Platforma SŽ – Základní dokument
Log management pokročilé bezpečnostní hrozby v prost edí SŽ. Každý server či uživatelská stanice musí
mít nainstalovaného agenta XDR. V p ípadě pot eby je možné upravit nastavení agenta
Active Directory and Domain pro korektní běh dodávaného systému.
Services Omezení: Služby XDR jsou v současné době dostupné jen v UAS.

ešení log managementu provádí sběr auditních záznamů z ICT infrastruktury SŽ.
Omezení: V současné době je log management provozován v režimu PoC a je dostupný
pouze v UAS.

Adresá ová služba společnosti Microsoft pro správu za ízení a identit a jejich autentizaci
a autorizaci v podnikových sítích. Dodávaná ešení musí podporovat integraci na službu
Active Directory Správy železnic. Správa železnic provozuje multi-forest prost edí, proto
musí aplikace umožňovat využití více AD konektorů, za účelem ově ení uživatelů.
Omezení: Služby Active Directory jsou v současné době dostupné jen v UAS.

5.3.2 Služby monitoringu

Služba dohledu ICT infrastruktury je zajištěna pomocí nástroje Zabbix a dohledových agentů
instalovaných na provozovaném prost edí nebo bez-agentově se vzdáleným dohledem, sledování
standardními protokoly SNMP, IPMI, HTTP, HTTPS, ICMP apod.

Dodavatelé ve spolupráci s organizační jednotkou SŽT zajistí napojení dodávaných ešení na
monitoring Zadavatele. Tím není dotčena p ípadná povinnost dodavatele ešení monitorovat
kvalitu a dostupnost dodávaného ešení. Preferovaným ešením je v takovém p ípadě využití
služeb monitoringu SŽ s nastavením pot ebných notifikací a procesů.

5.3.3 Služby patch managementu

Popis služeb patch managementu, aktualizací a distribuce aplikací

Služba Popis

Distribuce SW a aktualizace Technologií System Center Configuration Manager (SCCM) je zajištěna distribuce
koncových stanic softwarových balíčků a aktualizace koncových stanic. Patchování klientských stanic
probíhá 1 x měsíčně a je plně v gesci Správy železnic.

Aktualizace serverových Aktualizace serverových operačních systému Windows Server je ešena skriptovacím
operačních systémů jazykem Powershell. Patchování serverových operačních systémů probíhá 1 x měsíčně
a je zajištěno Správou železnic, pokud není s dodavatelem ešení dohodnuto jinak.

Aktualizace linuxových Aktualizace linuxových operačních systémů je ešena vlastním repozitá em
operačních systémů (nap . Red Hat Satellite). Patchování linuxových operačních systémů probíhá dle
pot eby a je zajištěno Správou železnic, pokud není s dodavatelem ešení dohodnuto
jinak.

5.3.4 Služby zálohování

Detailní p ehled o službách zálohování je p edmětem P ílohy 7 – Standardy zálohování a disaster
recovery.

5.3.5 Síťové služby

Přehled síťových služby Popis
Služba
DNS Domain Name System (DNS) je kritickou službou, která má zásadní vliv na bezpečnost,
Firewall odezvu a dostupnost služeb SŽ. Je nezbytná pro správný chod podnikové sítě a služeb
Proxy na bázi Active directory. Správa železnic provozuje interní i externí službu DNS.

Reverzní proxy Za ízení typu firewall jsou je velmi důležitým bezpečnostním prvkem ve veškeré
VPN elektronické komunikaci v sítích SŽ, jenž pomocí pravidel filtruje síťový provoz a chrání
VPN S2S ICT prost edky v síti Správy železnic.

Proxy soustava zajišťuje p ístup uživatelů a serverů k internetu. Naprostá většina
komunikace uživatelů (zaměstnanců SŽ) do sítě Internet prochází p es ni, jiný p ístup
není povolen. Proxy servery fungují jako prost edník mezi klienty a cílovými servery,
mimo perimetr sítě SŽ, p ekládá klientské požadavky a vůči cílovému serveru vystupuje
sám jako klient.

Všechna p ipojení z internetu smě ující na některý ze serverů jsou směrována p es
reverzní proxy server, který buďto požadavek zpracuje sám nebo ho p edá dál
serverům. Umožňuje SSL terminaci a kompresi.

Služba virtuální privátní sítě, umožňující dodavateli zabezpečený p ístup konkrétních
zaměstnanců ke konkrétním prost edkům v prost edí Správy železnic.
Omezení: Jedná se o jmennou VPN s MFA pro konkrétního externistu.

Služba virtuální privátní sítě Site-to-Site.

Platforma SŽ – Základní dokument 11/14
Omezení: S2S VPN jsou z izovány jen ve výjimečných p ípadech po schválení Odborem
IT architektury.

6 Technologie Platformy SŽ

V rámci služeb poskytovaných Platformou SŽ je využívána celá ada ICT technologií.

Tyto technologické služby, softwarové i hardwarové prostředky nesmějí být přímo
použity v návrhu řešení mimo využití těch, které již Platforma SŽ poskytuje.

Pro některé p ípady výběrových ízení pro aplikační software je p ípustné použití tzv.
zapouzd ených technologií, jež nejsou součástí Platformy SŽ, ale nabízené ešení vyžaduje jejich
nasazení. Zapouzd ená technologie je zpravidla součástí jiné primární technologie jako tzv.
podpůrný program. Takový program nevyžaduje samostatnou instalaci, jelikož je instalován jako
součást dané komponenty.

Použití takových zapouzd ených technologií je možné jen v následujících p ípadech:

1. Jejich použití nebude klást žádné dodatečné provozní, finanční ani implementační nároky
po celou dobu životnosti primární technologie.

2. Nebudou vyžadovat žádné dodatečné licence nad rámec licencí hlavního dodávaného
ešení.

3. Aktualizace zapouzd ených technologií bude probíhat pouze současně s aktualizací
hlavního dodávaného ešení.

4. Jejich podpora bude poskytována současně a ve stejném rozsahu jako podpora hlavního
dodávaného ešení.

5. Zapouzd ené technologie nebudou vyžadovat žádné speciální provozní podporu, ze
strany Správy železnic.

6. Zapouzd ené technologie jsou v souladu se standardy kybernetické bezpečnosti (ZoKB,
VoKB).

P i použití zapouzd ených technologií je nutné danou technologii identifikovat nejméně
v následujícím rozsahu – Název, Verze, Výrobce, Licence, Termín a úroveň podpory.

12/14 Platforma SŽ – Základní dokument
7 Přílohy Platformy SŽ

Jednotlivé oblasti jsou dále detailně zpracovány v těchto p ílohách:
• P íloha 1 – Standardy softwarového vývoje
• P íloha 2 – Datová centra a serverovny
• P íloha 3 – Virtuální prost edí, serverové farmy a servery
• P íloha 4 – Konektivita a síťové prost edí
• P íloha 5 – Integrační standardy
• P íloha 6 – Komunikační standardy
• P íloha 7 – Standardy zálohování a disaster recovery

Platforma SŽ – Základní dokument 13/14
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Standardy vývoje
software

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 5
2 Standardy vývoje informačních systémů Správy železnic .............................................. 5

2.1 Dvouvrstvá architektura ................................................................................. 5
2.1.1 Datová vrstva................................................................................... 5
2.1.2 Aplikační vrstva ................................................................................ 5

2.2 T ívrstvá a vícevrstvá architektura ................................................................... 6
2.2.1 Datová vrstva................................................................................... 6
2.2.2 Aplikační vrstva ................................................................................ 6
2.2.3 Prezentační vrstva ............................................................................ 6
2.2.4 Integrační vrstva .............................................................................. 7

2.3 Požadavky na prezentační vrstvu ..................................................................... 7
2.3.1 Uživatelské rozhraní .......................................................................... 7
2.3.2 Uživatelská zkušenost ....................................................................... 7

2.4 Bezpečnost ................................................................................................... 8
2.4.1 Zabezpečení aplikací ......................................................................... 8
2.4.2 Autentizace a autorizace .................................................................... 9
2.4.3 Zpracování osobních údajů................................................................. 9

2.5 Dokumentace ................................................................................................ 9
2.5.1 Technická dokumentace jádra systému................................................ 9
2.5.2 E-R modely databáze ........................................................................ 9
2.5.3 Objektový model pro aplikace ...........................................................10
2.5.4 Procesní diagramy, schémata toků dat ...............................................10
2.5.5 Komunikační rozhraní .......................................................................10
2.5.6 Drátové modely všech obrazovek uživatelského rozhraní aplikací ...........10
2.5.7 Popis konfigurace provozního prost edí ...............................................10
2.5.8 Uživatelská p íručka .........................................................................10
2.5.9 P íručka administrátora ....................................................................10
2.5.10 Disaster Recovery postup (D/R Postup) ..............................................10

2.6 Modelování EA architektury ............................................................................10
2.7 P edávání vývoje do provozu ..........................................................................11

2/12 Platforma SŽ – Standardy vývoje software
Seznam zkratek

2FA Dvou-faktorové ově ení (Two-Factor Authentification)
3NF
DDL T etí normální forma návrhu tabulek databází eší tranzitivní závislosti v rámci návrhu
EA tabulek databází
GDPR
(Data Definition Language)
ICT
IT Podniková architektura (Enterprise Architecture)
LDAP
MFA GDPR neboli Obecné na ízení o ochraně osobních údajů je zákon Evropské unie,
SAP který byl p ijat v roce 2016 a začal platit v květnu 2018. GDPR upravuje ochranu
SOA osobních údajů občanů EU a stanovuje pravidla pro sběr, zpracování, uchovávání
a p edávání osobních údajů. Cílem GDPR je posílit ochranu osobních údajů a zvýšit
SQL kontrolu občanů nad jejich údaji. V ČR je implementován zákonem o zpracování
osobních údajů č. 110/2019 Sb. (General Data Protection Regulation)
SSO
SW Informační a komunikační technologie (Information and Communication
SŽ Technology)
SŽT
UI Informační technologie (Information Technology)
UNICODE
UX (Lightweight Directory Access Protocol)
VoKB
ZoKB Více-faktorové ově ení identity uživatele (Multi-Factor Authentification)
NÚKIB
ZZOU Modulární ERP systém od německé firmy SAP AG

Architektura orientovaná na služby – jedná se o softwarovou architekturu, která se
zamě uje na organizaci a strukturu aplikací a systémů jako soubor nezávislých a
dob e definovaných služeb (Service-Oriented Architecture)

Standardní jazyk pro manipulaci s relačními databázemi. SQL umožňuje ukládat,
manipulovat a vyhledávat data v relačních databázích. SQL je založeno na dotazech
(queries) na data v databázích. Dotazy lze pak definovat a modifikovat strukturu
databází, vytvá et a upravovat tabulky, indexy a další prvky, vkládat a aktualizovat
data, mazat data a další operace. SQL je nezávislý na platformě, což znamená, že
může být použit na různých operačních systémech a s různými databázovými
systémy, avšak každá databázová platforma může mít různé změny v syntaxi
(Structured Query Language)

(Single Sign-On)

Programové vybavení počítače či jiného obdobného za ízení. Speciálním druhem
software je firmware, který je úzce spjatý s konkrétním hardwarem (Software)

Správa železnic, státní organizace

Správa železniční telematiky, organizační jednotka SŽ

(User Interface)

Univerzální kódování znaků s možností reprezentace všech národních znakových
sad

(User Experience)

Vyhláška o kybernetické bezpečnosti č. 82/2018 Sb.

Zákon o kybernetické bezpečnosti č. 181/2014 Sb.

Národní ú ad pro kybernetickou a informační bezpečnost
Zákon o zpracování osobních údajů č. 110/2019 Sb.

Platforma SŽ – Standardy vývoje software 3/12
Seznam vysvětlivek

E-R model (Entity-Relationship model)
Platforma SŽ
Soubor dokumentů, rozdělený na ve ejnou, interní a metodickou část,
určený pro seznámení dodavatelů se standardy a technologiemi v ICT
prost edí SŽ.

4/12 Platforma SŽ – Standardy vývoje software
1 Úvod

Cílem tohoto dokumentu je definovat Platformu SŽ, jakožto souhrn podporovaných
infrastrukturních služeb, technologií, a architektonických principů, která definuje základní
rámec pro návrh ešení ICT. Platforma SŽ naplňuje strategické cíle IS/ICT SŽ, zejména
v oblasti efektivního provozu a rozvoje ICT prost edí Správy železnic.

2 Standardy vývoje informačních systémů
Správy železnic

P i vývoji software ve Správě železnic je požadováno, aby byly plně respektovány obvyklé
metodiky a best-practice pro návrh a vývoj software pomocí vícevrstvé architektury. Konkrétní
užití jednotlivých vzorů se ídí vhodností, plánovanou zátěží a požadavky na dostupnost
vyvíjeného software.

Aplikace či informační systém musí vždy podporovat škálování výkonu, redundanci
a více-jádrové serverové systémy bez ohledu na zvolenou architekturu ešení.

2.1 Dvouvrstvá architektura

Dvouvrstvou architekturu p i vývoji software lze využít v p ípadě, kdy se jedná o menší,
samostatný software, který nebude integrován na další informační systémy, nebo datové
zdroje Správy železnic. Užití takovéhoto software je plánováno pro menší desítky uživatelů,
bez požadavku na vysokou dostupnost a možnosti škálování výkonu a rozložení zátěže
prost ednictvím clusterování. U tohoto typu software nejsou definovány požadavky na vysokou
odolnost proti chybám, rychlou reakci systému, nebo správu dat pro velké sítě.

Využití dvouvrstvé architektury musí být p edem diskutováno s Oddělením IT architektury,
které v odůvodněných p ípadech vydá p íslušnou výjimku.

2.1.1 Datová vrstva

Realizace datové vrstvy je požadována prost ednictví preferované relační databáze (dle služeb
Platformy SŽ) a respektováním metodiky 3NF. Je požadován jednoznačný datový model
s minimální redundancí dat a datové struktury budou modelovány a popsány jazykovými
konstrukcemi DDL, které jsou kompatibilní s určeným databázovým systémem.

Celá struktura dat bude popsána formálně prost edky E-R modelování. K datovému modelu je
požadováno dodat korespondující SQL DDL skripty, který budou plně odpovídat dodané
databázi. Je požadováno, aby správnost, úplnost a optimalizace datového modelu byla ešena
již v rámci návrhu ešení.

V rámci dvouvrstvé architektury je umožněno, aby logika byla rozprost ena částečně
v databázi a částečně v aplikační, resp. prezentační vrstvě.

2.1.2 Aplikační vrstva

Aplikační vrstva a prezentační vrstva je ve dvouvrstvé architektu e realizována jako jedna,
společná a nedělitelná vrstva. Je požadováno, aby tato vrstva byla realizována v souladu
s principy objektově orientovaného programování a komunikace mezi vrstvami byla
realizována standardními zabezpečenými a šifrovanými protokoly. Je požadováno, aby
uživatelské identity nebyly z aplikační vrstvy prezentovány do datové vrstvy, p ičemž tyto
vrstvy musí mezi sebou komunikovat technickým účtem, k tomu účelu v databázi vytvo eném.

Je požadováno, aby aplikační vrstva podporovala Multitasking, tedy umožňovala provádění
několika procesů současně a systém byl již v rámci návrhu a vývoje optimalizován plánovaný
výkon.

Platforma SŽ – Standardy vývoje software 5/12
V rámci vývoje musí být ošet ena všechna bezpečnostní rizika popsaná v kapitole 2.4.

2.2 Třívrstvá a vícevrstvá architektura

T ívrstvá a vícevrstvá architektura je požadována p i vývoji software ve všech p ípadech,
mimo výjimek uvedených v kapitole 2.1 nebo pokud není v zadávací dokumentaci VZ
specifikováno jinak. Specifikace ešení vyžadující t ívrstvou architekturu tak může disponovat
následujícími vlastnostmi:

• Má být integrován na jiný software Správy železnic, nebo software t etích stran,
a to z důvodu jednotného p ístupu k datům a procesům vyvíjeného software

• Je plánováno využití pro větší počty uživatelů
• Je požadována vysoká dostupnost (HA)
• Je požadován Clustering pro rozložení zátěže a škálování výkonu
• Je požadována vysoká odolnost proti chybám, rychlá reakce systému, nebo správa dat

pro velké sítě

2.2.1 Datová vrstva

Realizace datové vrstvy je primárně požadována prost ednictvím relační databáze nabízené
Platformou SŽ, avšak pokud dodavatel navrhne jiné ešení (nap . objektovou databázi či
NoSQL), je povinen toto ešení zahrnout do své ceny implementace a provozu IS. Tento
p ístup zohledňuje různé typy úloh, kde využití relační databáze nemusí být vždy optimální.

Datový model musí být jednoznačný, s minimální redundancí dat, a datové struktury budou
modelovány a popsány jazykovými konstrukcemi DDL, kompatibilními s určeným databázovým
systémem. Formální popis celé struktury dat bude realizován prost edky E-R modelování,
p ičemž je možné povolit také objektový model, nap íklad formou diagramu t íd. K datovému
modelu je nutné dodat odpovídající SQL DDL skripty, které plně reflektují implementovanou
databázi. Důraz je kladen na to, aby správnost, úplnost a optimalizace datového modelu byly
zajištěny již ve fázi návrhu ešení.

V rámci t ívrstvé nebo vícevrstvé architektury není p ípustné, aby logika byla rozdělena mezi
databázi a aplikační vrstvu. Veškerá aplikační logika musí být umístěna výhradně v aplikační
vrstvě.

2.2.2 Aplikační vrstva

Je požadováno, aby tato vrstva byla realizována v souladu s principy objektově orientovaného
programování a komunikace mezi vrstvami byla realizována standardními zabezpečenými
a šifrovanými protokoly. Je požadováno, aby uživatelské identity nebyly z aplikační vrstvy
prezentovány do datové vrstvy, p ičemž tyto dvě vrstvy musí mezi sebou komunikovat
technickým účtem, k tomu účelu v databázi vytvo eném.

Je požadováno, aby aplikační vrstva podporovala Multitasking, tedy umožňovala provádění
několika procesů současně a v již rámci návrhu a vývoje optimalizovat plánovaný výkon.

V rámci vývoje musí být ošet ena všechna bezpečnostní rizika popsaná v kapitole 2.4.

2.2.3 Prezentační vrstva

Pro interakci s uživatelem je požadováno, aby prezentační vrstva byla realizována
desktopovým klientem (tlustým), nebo webovým klientem (tenkým), a to v závislosti
na vhodnosti použití a požadavcích na software kladených. Komunikace mezi prezentační
a aplikační vrstvou musí být realizována standardními zabezpečenými a šifrovanými protokoly.

V rámci prezentační vrstvy a desktopového klienta je možné p enesením části aplikační logiky
na klienta, tedy využití prost edků klientské stanice ke zvýšení výkonu systému, ale pouze
za p edpokladu, že tento systému bude zabezpečovat konzistenci aplikační logiky, nap íč všemi
desktopovými klienty.

6/12 Platforma SŽ – Standardy vývoje software
Bez aktualizačních mechanismů, které zajistí stejné verze software, na všech klientských
stanicích v reálném čase není tato možnost povolena.

2.2.4 Integrační vrstva

V p ípadě, kdy vyvíjený software má být integrován na jiný software Správy železnic, nebo
software t etích stran, je požadováno, aby tato integrační vrstva byla realizována jako
samostatná vrstva, umožňující škálování výkonu a rozložení zátěže.

Realizace integrací mezi aplikačními komponentami musí splňovat principy SOA. Veškerá
komunikace tedy musí probíhat prost ednictvím definovaných služeb rozhraní, a není tedy
povolena výměna dat prost ednictvím p ímých vazeb, jako je sdílení paměti, souborů, nebo
databází. Pokud je k dispozici, komunikace probíhá prost ednictvím k tomu určené sběrnice
(ESB) nebo integrační platformy.

V p ípadě, že má být vyvíjená komponenta integrována se spisovou službou SŽ, musí
splňovat požadavky na integraci prost ednictvím Národního standardu pro elektronické
systémy spisové služby1 a integrace musí být rozhraními definovanými v tomto standardu také
realizována.

V p ípadě, že má být vyvíjená aplikace integrována s programovým prost edím komponent
systému SAP, musí být realizována prost ednictvím určené integrační platformy (SAP Cloud
Platform, p íp. produktu, který jej nahradí). Detailní parametry požadavku na integraci budou
definovány v p íslušných p ípadech.

2.3 Požadavky na prezentační vrstvu

2.3.1 Uživatelské rozhraní

Pomocí uživatelského rozhraní může uživatel komunikovat se za ízením, počítačem
a programy. P i navrhování vysoce kvalitního uživatelského rozhraní je požadováno zohlednit
nejen vzhled rozhraní, ale také jeho logickou strukturu, aby s ním uživatel mohl snadno
a rychle komunikovat a dosáhnout požadovaného výsledku bez zbytečného úsilí. Cílem je
vytvo it rozhraní, které poskytuje jednoduchou, srozumitelnou a pohodlnou interakci uživatele
s informačním systémem.

Pro návrh UI informačních systémů SŽ platí následující zásady:

• standardní ovládací prvky
• uživatelské rozhraní jednoduché a p ehledné
• konzistentní prost edí
• účelné rozvržení obrazovek
• barvy a písma dle grafického manuálu
• hierarchie daná typograficky
• informování uživatele, co systém právě dělá
• odpovídající tvar a velikost ovládacích prvků
• kódování znaků UNICODE
• datumové položky dle českého standardu „DD.MM.RRRR“
• jednotný vizuální styl (pro některé projekty dle korporátní identity)
• webové aplikace musí mít responzivní design p izpůsobený určeným za ízením

koncových uživatelů

2.3.2 Uživatelská zkušenost

Uživatelská zkušenost je to, co uživatel pocítí a pamatuje si v důsledku použití aplikace,
systému nebo webu. UX formuje uživatelské chování a musí plnit požadavky uživatelů na

1 NSESSS, https://www.mvcr.cz/clanek/narodni-standard-pro-elektronicke-systemy-spisove-sluzby.aspx

Platforma SŽ – Standardy vývoje software 7/12
danou aplikaci či webovou stránku. UX musí být bráno v úvahu p i vývoji uživatelského
rozhraní, vytvá ení informační architektury a testování použitelnosti informačních systémů SŽ.
Po určení cílového publika a charakteristiky uživatelů je požadováno vytvo it seznam UX
požadavků na projekt.

UX informačních systémů SŽ musí splňovat následující vlastnosti:

• usnadnění/zefetivnění práce uživatele
• návodné ovládání
• ergonomie
• jednoduché, intuitivní
• pravidla p ístupnosti, tam kde je požadováno
• zobrazování relevantních a požadovaných dat
• doba zpracování požadavku na serveru by neměla p esáhnout 0,5 sekundy, aby

celková doba odezvy uživatelských prvků byla kratší než 0,8 sekundy. Pokud bude
p edpokládaná doba odezvy delší než 0,8 sekundy, ale kratší než 2 sekundy, zobrazí se
uživateli čekací kurzor. V p ípadě, že doba odezvy p esáhne 2 sekundy, bude uživateli
zobrazen indikátor průběhu operace (progress bar) pro lepší informovanost o stavu
zpracování
• použít lazy loading tak, aby uživatel měl co nejrychlejší odezvu
• jednotná terminologie v celém systému
• ne všechno na jedné obrazovce
• ne všechno v rozbalovacím menu (p íliš mnoho položek)
• navigace, kde se uživatel v aplikaci nachází
• minimalizace použití dlouhých textů
• vhodné využití grafických a obrazových prvků
• nepoužívat drobný text
• pečlivé plánování dialogů (logické skupiny)
• ne p ekrývající se dialogy
• jednotné, stejné ovládací prvky v dialozích na stejných místech s popisky s jednotnou
terminologií

2.4 Bezpečnost

Všechny vyvíjené aplikace musejí splňovat požadavky kladené platnou legislativou.
Požadovaný je také soulad s NÚKIB (Bezpečný vývoj aplikací).

Z pohledu požadavků na vyvíjený software je nutné zajistit oblasti:

• Zálohování a obnova
• Bezpečnost komunikací
• ízení p ístupu
• Ochrana p ed škodlivým kódem
• Logování a monitoring
• Bezpečné p edávání a výměna informací
• Akvizice, vývoj a údržba

2.4.1 Zabezpečení aplikací

Je požadováno, aby jednotlivé vrstvy splňovaly minimálně tyto požadavky:

• Ke komunikaci mezi jednotlivými vrstvami je používán systémový účet, který lze
v p ípadě ohrožení kybernetické bezpečnosti deaktivovat, nebo změnit.

• Systémový účet, který je využíván ke komunikaci mezi vrstvami není privilegovaným
účtem.

• Všechny vrstvy jsou ošet eny proti nejzávažnějším bezpečnostním rizikům jako jsou2:

2 Dle aktuálního seznamu nejzávažnějších bezpečnostních rizik definovaných OWASP (https://owasp.org/).

8/12 Platforma SŽ – Standardy vývoje software
o Injection
o Broken Authentication
o Sensitive Data Exposure
o XML External Entities (XXE)
o Broken Access Control
o Security Misconfiguration
o Cross-Site Scripting (XSS)
o Insecure Deserialization
o Using Components with Known Vulnerabilities
o Insufficient Logging&Monitoring
• Jednotlivé vrstvy uchovávají své konfigurační parametry v šifrované podobě.

2.4.2 Autentizace a autorizace

2.4.2.1 Autentizace
Autentizace je proces ově ení proklamované identity subjektu. Je požadováno, aby aplikace
umožňovala následující typy autentizace:

• SSO (Single Sign-On), autentizaci pomocí protokolu Kerberos, nebo OpenID proti
Active Directory

• Autentizaci pomocí protokolu LDAP, proti Active Directory
• ešení 2FA či MFA

Manuální p ihlášení a autentizaci pomocí vyvíjeného software (uživatelská jména a hesla jsou
uložena v databázi v šifrované podobě) je možné jen na základě schválené výjimky Odborem
IT architektury SŽT.

2.4.2.2 Autorizace
Je požadováno, aby vyvíjený software obsahoval vlastní autorizační modul, který bude
minimálně umožňovat:

• Vytvá ení uživatelských účtů
• Vytvá ení rolí
• P idělování jednotlivých uživatelských účtů k rolím
• P idělování konkrétních oprávnění na role

V rámci naplnění povinností vyplývajících ze ZoKB a VoKB je požadováno, aby vyvíjený
software umožňoval správu uživatelů a rolí pomocí externího nástroje na ízení identit.
Integrace mezi vyvíjeným softwarem a Identity management bude realizována prost ednictvím
integrační vrstvy vyvíjeného software.

2.4.3 Zpracování osobních údajů

Je požadováno kompletní splnění všech požadavků na zpracování osobních údajů dle zákona
o zpracování osobních údajů č. 110/2019 Sb. (GDPR). Analýza a návrh opat ení musí být ešen
již v rámci návrhu ešení.

2.5 Dokumentace

Je požadováno, aby součástí dodávky vyvíjeného software byla dokumentace, a to minimálně
v rozsahu:

2.5.1 Technická dokumentace jádra systému

Dokumentace jádra systému, jeho funkcí, služeb a rozhraní. Dokumentace bude obsahovat
kompletní popis architektury jádra systému, výčet a podrobný popis všech jeho funkcí, p ehled
a popis služeb, které jádro poskytuje dalším komponentám systému, modulům a knihovnám.

2.5.2 E-R modely databáze

Kompletní dokumentace ve formě E-R schémat pro všechny implementované databáze včetně
korespondujících DDL SQL skriptů.

Platforma SŽ – Standardy vývoje software 9/12
2.5.3 Objektový model pro aplikace

Dokumentace obsahující objektové modely všech funkcí, jejich komponent, modulů, vztahů.

2.5.4 Procesní diagramy, schémata toků dat

Dokumentace obsahující procesní diagramy a mapu všech toků dat celého ešení.

2.5.5 Komunikační rozhraní

Dokumentace všech typů komunikačních rozhraní, všech jejich registrovaných služeb a všech
funkcí, struktur dat a vlastností těchto služeb.

2.5.6 Drátové modely všech obrazovek uživatelského rozhraní
aplikací

Dokumentace všech částí software musí obsahovat drátové modely všech obrazovek UI včetně
popisu funkcí prvků každé obrazovky.

2.5.7 Popis konfigurace provozního prostředí

Dokumentace musí obsahovat soupis všech požadavků na nastavení hardwarových
a softwarových komponent běhového prost edí jako jsou:

• mapování souborových systémů
• požadavky na operační paměť a počty jader
• konfigurační parametry jednotlivých podpůrných SW prost edků (nap . specifika pro

nastavení databáze, aplikačního serveru, webového serveru, apod.)

2.5.8 Uživatelská příručka

P íručka bude distribuována uživatelům. Musí obsahovat kompletní popis všech uživatelských
funkcí pro práci se software. P íručka bude využívána jako základní materiál pro školení
nových uživatelů. P íručka musí obsahovat kvalitně a jednoznačně zpracovaný popis kroků pro
jednotlivé implementované funkce s vhodným doprovodným obrazovým materiálem ve formě
vý ezů obrazovek. Musí být napsána v českém jazyce a p ed finálním odevzdáním zpracovaná
jazykovým korektorem.

2.5.9 Příručka administrátora

P íručka bude distribuována úzké skupině uživatelů, administrátorům systému. Musí obsahovat
kompletní popis všech funkcí pro práci s administrací software. P íručka bude využívána jako
materiál pro školení nových administrátorů. P íručka musí obsahovat kvalitně a jednoznačně
zpracovaný popis kroků pro jednotlivé implementované funkce s vhodným doprovodným
obrazovým materiálem ve formě vý ezů obrazovek. Musí být napsána v českém jazyce a p ed
finálním odevzdáním zpracovaná jazykovým korektorem.

2.5.10 Disaster Recovery postup (D/R Postup)

Dokumentace Disaster Recovery postupu bude obsahovat kompletní plán pro obnovu klíčových
systémů a dat v p ípadě mimo ádné události nebo havárie. Tento plán bude zahrnovat
podrobný popis zálohovacích strategií, metod obnovy, a kroků nutných pro minimalizaci
výpadků a rychlou obnovu provozu. Dokumentace bude sloužit jako základní materiál pro
školení týmů odpovědných za implementaci a správu obnovovacích procesů.

2.6 Modelování EA architektury

Každý Dodavatel je povinen ádně dokumentovat dodávané ešení v podobě modelu Enterprise
Architektury. V rámci SŽ je využíván jako modelovací nástroj SPARX Enterprise Architect
ve verzi 16 a notace Archimate 3.2.

Za účelem udržení kompatibility všech vytvá ených modelů má SŽ vytvo ený p ehled
povolených elementů pro jednotlivé vrstvy, včetně popisu jejich charakteristik a povinných

10/12 Platforma SŽ – Standardy vývoje software
atributů (závaznou metodiku tvorby a údržby EA modelů). Dodavatel může doplnit další
elementy, jejich schválení však podléhá Odboru IT architektury SŽT.

Modelovaní bude realizováno na repozitory SŽ, kam bude Dodavateli vytvo en p ístup
za účelem možnosti sdílet vytvo ené prvky a jejich definované vazby, tak aby byla zachována
kompatibilita.

Hlavním schvalovatelem p edkládaných modelů je Odbor IT architektury SŽT.

2.7 Předávání vývoje do provozu

Pokud nebude určeno jinak, veškeré výstupy (zdrojové kódy, konfigurační soubory, testovací
data, dokumentace atp.) musejí být p edávány prost ednictvím určeného repositá e. Bez
p edání kompletní dokumentace nelze danou aplikaci či informační systém považovat za
bezchybný a akceptovatelný v rámci procesu akceptace.

Platforma SŽ – Standardy vývoje software 11/12
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Datová centra a
serverovny

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 4
2 Datová centra ......................................................................................................... 4

2.1 Datové centrum CDP Praha ............................................................................. 4
2.2 Datové centrum CDP P erov ............................................................................ 5
3 Serverovny ............................................................................................................. 5
3.1 Významné serverovny .................................................................................... 5
3.2 Serverovny dle geografických oblastí ................................................................ 5
3.3 Serverovny vybraných organizačních jednotek................................................... 5
3.4 Technologické serverovny ............................................................................... 5
3.5 Technologické a sd lovací místnosti ................................................................. 5
4 Technologické vybavení ............................................................................................ 5
4.1 Stavební provedení ........................................................................................ 6
4.2 Napájení ....................................................................................................... 6
4.3 Chlazení........................................................................................................ 6
4.4 Bezpečnost ................................................................................................... 7
4.5 Síťová infrastruktura ...................................................................................... 7
4.6 Ostatní vybavení ............................................................................................ 7

2/8 Platforma SŽ – Datová centra a serverovny
Seznam zkratek

ASHS Stabilní hasicí za ízení, b žn se označuje i zkratkou SHZ a zpravidla bývá na bázi
CDP vodních sprinklerů nebo sm si inertních plynů, které jsou ekologicky neškodné
EPS
Centrální dispečerské pracovišt v kontextu organizační struktury SŽ (CDP Praha,
EZS CDP P erov)

ICT Technologie pro detekci a signalizaci požáru v budovách. Systém EPS zahrnuje
IT detektory požáru, které jsou umíst ny v různých částech budovy a slouží k detekci
OJ ohn nebo kou e. Detektory jsou p ipojeny k ídící jednotce, která sbírá a analyzuje
O data z detektorů a rozhoduje, zda má být spušt na alarmová signalizace. Systémy
OT EPS mohou být konfigurovány pro p enos informací o požáru na centrální
SŽ monitorovací stanice nebo na místní hasičské sbory, aby byla zajišt na rychlá
TIER reakce a minimalizovány škody a ztráty na životech (Elektronická požární
UPS signalizace)

Technologie pro ochranu majetku, budov a objektů p ed neoprávn ným vstupem
a krádežemi. EZS zahrnuje detektory pohybu, otvírání dve í a oken, kamerové
systémy, zabezpečovací panely a další za ízení pro monitorování a signalizaci
neoprávn ného vstupu nebo pokusů o krádež (Elektronická zabezpečovací
signalizace)

Informační a komunikační technologie (Information and Communication
Technology)

Informační technologie (Information Technology)

Organizační jednotka SŽ

Oblastní editelství SŽ

Provozní technologie (Operations Technology)

Správa železnic, státní organizace

Klasifikace datových center dle Uptime Institute. Datová centra se pak označují
jako TIER 1 (nejnižší zabezpečení) až TIER 4 (nejvyšší zabezpečení)

Zdroj nep erušovaného napájení je za ízení, které zajišťuje souvislou dodávku
elektrické energie pro spot ebiče, které nesm jí být neočekávan vypnuty
(Uninterruptible Power Supply)

Seznam vysvětlivek

Platforma SŽ Soubor dokumentů, rozd lený na ve ejnou, interní a metodickou část, určený
pro seznámení dodavatelů se standardy a technologiemi v ICT prost edí SŽ.

Platforma SŽ – Datová centra a serverovny 3/8
1 Úvod

Cílem této části Platformy SŽ je, dle kategorizace datových center a serveroven v prost edí
Správy železnic, definovat technické požadavky na jejich výstavbu a s tím související popis
používaných technologií v datových centrech, serverovnách a technologických místnostech.
Současn dokument slouží jako popis fyzického ICT prost edí, kde jsou provozovány ICT
technologie a provozovány informační systémy.

Z pohledu ICT infrastruktury jde o lokality, kde jsou umíst né zpravidla serverové technologie
pro provoz aplikací a podpůrných systémů, technologie datových spojů, telefonie a další. Může
zde být umíst na i technika externích dodavatelů či napojení na kritické podpůrné systémy
externích subjektů (HZS ČR, PČR, ČEZ).

Datová centra jsou obecn definována jako samostatné budovy sloužící výhradn pro provoz
ICT infrastruktury. Z pohledu provozu a dostupnosti jsou pak kategorizována hodnotami TIER.
Kategorizace mimo jiné zohledňuje redundanci napájení, chlazení, konektivity, fyzické
zabezpečení a technologické vybavení samotných prostor. Vše je následn p epočteno na
nominální dostupnost v procentech za jeden rok (viz ukazatel TIER).

Serverovny jsou pak definovány obdobn jako datová centra, jen již není požadována
vyhrazená samostatná budova, ale b žn bývají součástí administrativních či provozních
a technologických budov. V tšina menších serveroven, technologických a sd lovacích místností
ve Správ železnic vznikla p ebudováním stávajících místností v p íslušné budov .

Tabulka 1. Rozdělení DC a serveroven dle velikosti a významu

Datacentrum / serverovna / rack Počet rackových Kritické Serverová Redundance
skříní aplikace infrastruktura ( napájení,
chlazení,
Datové centrum 10-200+ ANO ANO konektivita)
Významná serverovna 6-25 ANO ANO ANO
Menší serverovna 4-16 ČÁSTEČN ANO
Lokální serverovna 1-8 NE ČÁSTEČN ANO
Technologické místnosti 1-5 NE ČÁSTEČN
Sdělovací místnosti 1-6 NE NE ČÁSTEČN
Samostatné rackové skříně 1-3 NE NE NE
v budovách
NE

Výstavba a projektování datových center a serveroven je standardizována v souboru norem
ČSN EN 50600 a fyzické zabezpečení datových center je dále intern ve Správ železnic
specifikováno ve sm rnici SM07 a jejích p ílohách.

2 Datová centra

Správa železnic disponuje dv ma datovými centry, kde jsou umisťovány technologie jak IT, tak
OT. Tato datová centra jsou součástí technologických ídících center, odkud je dálkov ízen
železniční provoz.

2.1 Datové centrum CDP Praha

Jedná se o primární datové centrum Správy železnic, které zajišťuje b h velkého počtu
provozovaných informačních systémů a aplikací. V datovém centru jsou v samostatných sálech
umíst ny IT technologie i páte ní prvky celorepublikových sítí a rozsáhlé za ízení OT. Objekt je
vn i uvnit zabezpečen v souladu s b žnými standardy i interními sm rnicemi.

4/8 Platforma SŽ – Datová centra a serverovny
Z technologického pohledu je zajišt no redundantní chlazení i napájení s kapacitou p íkonu
v prům ru 3,5 kW pro jeden každý rack.

2.2 Datové centrum CDP Přerov

Jedná se o sekundární datové centrum Správy železnic, které zajišťuje záložní lokalitu pro b h
provozovaných aplikací. V datovém centru jsou v hlavním sále umíst ny veškeré serverové
vybavení, technologické za ízení i síťové prvky.

Datové centrum v současné budov CDP P erov je na své kapacitní hranici (jak fyzické, tak co
se podpůrných technologií týká, jako jsou napájení nebo chlazení). V současné dob probíhají
práce na dostavb a rozší ení CDP P erov o druhou budovu, a to včetn nových datových sálů
a nového ešení zálohovaného napájení.

3 Serverovny

V tších či menších serveroven Správa železnic provozuje desítky v mnoha lokalitách po celém
území republiky.

3.1 Významné serverovny

Správa železnic provozuje adu serveroven, které jsou z pohledu SŽ významné svým
umíst ním nebo účelem, nikoli však t eba velikostí nebo provozovanými technologiemi. Pat í
sem t eba serverovny v budov Generálního editelství SŽ, serverovny kde se realizuje
p ipojení k vn jším sítím a tvo í tak perimetr sít .

3.2 Serverovny dle geografických oblastí

Serverovny O slouží primárn pro provoz ICT infrastruktury a aplikací určených pro jednotlivá
O.

3.3 Serverovny vybraných organizačních jednotek

Vybrané specializované OJ provozují serverovny dedikované pro své pot eby. Jedná se
p edevším o různé vysoce specializované aplikace informační systémy.

3.4 Technologické serverovny

Technologické serverovny slouží k provozu OT serverové infrastruktury a dalších
technologických za ízení.

3.5 Technologické a sdělovací místnosti

Technologické a sd lovací místnosti jsou umíst ny tém v každé železniční stanici a v mnoha
administrativních či p ímo technologických budovách. Úroveň jejich technologického
a provozního vybavení je na nižší úrovni a pramení výhradn ze základních pot eb
provozovaných systémů. Tyto prostory nejsou primárn určeny k provozu serverových
technologií.

4 Technologické vybavení

Technické a bezpečnostní vybavení je velmi důležitým parametrem daného prostoru.
V datových centrech a serverovnách jsou tyto nároky nejvyšší, ale i v b žných
administrativních budovách jsou n které prvky nutné. Následující kapitoly popisují jednotlivé
klíčové technologické prvky:

Platforma SŽ – Datová centra a serverovny 5/8
• Stavební provedení – Specifické stavební provedení datových center
a serveroven je p edpokladem pro bezpečné a spolehlivé provozování ICT
infrastruktury.

• Napájení – Specifickým prvkem pro datová centra a serverovny je redundantní
zálohované napájení.

• Chlazení – Stejn tak je pro datová centra typické chlazení datových sálů.
• Elektronická zabezpečovací signalizace ( EZS) – Tyto systémy fyzické

bezpečnosti se týkají všech typů budov Správy železnic včetn administrativních
budov.
• Přístupové a docházkové systémy – P ístupové a docházkové systémy se
používají nap íč prost edím Správy železnic.
• Kamerový systém – Kamerové systémy uvnit i vn budou jsou součástí
fyzického zabezpečení budov.
• Elektronické požární signalizace ( EPS) – Požární signalizace je dnes
standardem jak v datových centrech a serverovnách, tak ve všech
moderních administrativních budovách.
• Automatické hasicí systémy ( ASHS) – Pro datová centra je ASHS nutným
standardem a v p ípad požáru dokáže minimalizovat škody.
• Ochrana proti vodě – V datových centrech by m la být instalována ochrana proti
vod pro p ípad havárie.
• Monitoring prostředí – Monitoring prost edí (teplota, vlhkost) je pro datová
centra a serverovny nepostradatelný prvek zajišťující bezpečný a spolehlivý
provoz.
• Dohled prostor – Dohled je základní součástí fyzické bezpečnosti budov.

Cílem je pak zajistit pro SŽ datová centra s dostatečnými technickými parametry
odpovídajícími minimáln klasifikaci TIER II a současn s dostatečnou fyzickou kapacitou pro
umíst ní ICT infrastruktury.

4.1 Stavební provedení

Datová centra, serverovny a datové sály musí být projektovány v souladu se souborem norem
ČSN EN 50600. Nepsaným standardem je nap íklad dvojitá zvýšená podlaha nebo dostatečn
dimenzovaný p ístup umožňující p epravu rackové sk ín na výšku na paletovém vozíku.

4.2 Napájení

Napájení datových center a serveroven je klíčovou součástí provozu t chto za ízení.
V datových centrech se provozuje mnoho kritických aplikací a systémů a proto je důležité
zajistit spolehlivé napájení s dostatečnou kapacitou a zálohováním.

Pot eba elektrické energie v serverové infrastruktu e se b hem poslední dekády díky
virtualizacím a rostoucí pot eb výkonu posunula pro každou serverovou rackovou sk íň
na hodnotu v prům ru minimáln 8 kW špičkového p íkonu (3 kW provozního p íkonu).

Pro zálohování napájení se u datových center a významných serveroven používají diesel-
generátory, záložní zdroje napájení a napájení z více zdrojů elektrické energie (distribuční
soustava, trakční napájecí soustava). Určujícím faktorem je vždy kritičnost instalovaných
technologií a požadavek na dobu zálohy.

Významným požadavkem je pak využívání centrálních záložních zdrojů v rámci prostor, jejich
dimenzování a postupné rozši ování. Cílem o omezit vznik v tšího počtu menších „ostrovních“
záložních zdrojů v jedné serverovn , nebo technologické či sd lovací místnosti.

4.3 Chlazení

Chlazení datových center je důležitým faktorem pro udržení vysoké dostupnosti a spolehlivosti
serverů a dalších za ízení v datovém centru. Provoz datových center vyžaduje velké množství
elektrické energie a výsledkem je produkce velkého množství tepla. Pokud se teplo neodvádí

6/8 Platforma SŽ – Datová centra a serverovny
dostatečn rychle, může dojít k p eh átí za ízení, p erušení provozu a v n kterých p ípadech
i porušení či ztrát dat.

Pokud je to technicky možné, je nutné zajistit chlazení koncepcí zakrytované studené uličky,
což musí respektovat i sm r montáže aktivních prvků. V datových centrech a významných
serverovnách je dále vyžadována redundance chladících jednotek.

4.4 Bezpečnost

V datových centrech i serverovnách je nutné zajistit pln funkční EZS, EPS, p ístupový systém
i kamerový systém, který obsáhne nejen vn jší perimetr budovy, ale i jednotlivé sály a uličky
mezi rackovými adami.

Automatický hasicí systém jako rozší ení systému EPS je preferovaným ešením, jelikož
v p ípad požáru dokáže výrazn snížit způsobené škody na ICT infrastruktu e.

Nedílnou součástí je také fyzická bezpečnost a fyzické zabezpečení datových center a budov,
kde jsou umíst ny významné serverovny.

4.5 Síťová infrastruktura

Datová centra a serverovny musí být síťov odd leny od zbytku sít pomocí firewallu. Pro
místní síťové p ipojení je nutné používat výhradn síťové prvky detailn definované
v P íloze 4 – Konektivita a síťové prostředí.

4.6 Ostatní vybavení

Monitorování prost edí v datových centrech je velmi důležité, protože kritické IT systémy jsou
citlivé na zm ny teploty, vlhkosti a kvality vzduchu. P i narušení t chto parametrů může dojít
ke vzniku problémů, jako jsou selhání systémů a ztráta dat. Proto se v datových centrech
používají speciální senzory a za ízení pro monitorování a ízení prost edí.

Nová i rekonstruovaná datová centra a serverovny musí monitorovat minimáln tyto
parametry:

• Teplota
• Vlhkost
• Stav napájení (zálohovaného i nezálohovaného)

Platforma SŽ – Datová centra a serverovny 7/8
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-16

spravazeleznic.cz
Platforma SŽ
Virtuální prostředí,
serverové farmy,
servery

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 4
2 Virtualizační prostředí............................................................................................... 4

2.1 Virtualizace serverů........................................................................................ 4
2.2 Virtualizace koncových počítačů ....................................................................... 4
2.3 Kontejnerizace............................................................................................... 4
3 Serverové farmy...................................................................................................... 4
3.1 Konvergovaná infrastruktura ........................................................................... 4
3.2 Hyper-konvergovaná infrastruktura .................................................................. 5
4 Fyzické servery ....................................................................................................... 5
5 Datová úložiště........................................................................................................ 5
5.1 Datová úložiště farem..................................................................................... 5
5.2 Datová úložiště pro zálohy a archivaci .............................................................. 5
5.3 Datová úložiště pro off-line zálohy ................................................................... 6
5.4 Kancelářská datová úložiště ............................................................................ 6
6 Virtuální servery ...................................................................................................... 6
6.1 Služba virtuálních strojů ................................................................................. 6
6.2 Služby diskových uložišť ................................................................................. 7
7 Databázové servery ................................................................................................. 7
8 Webové servery....................................................................................................... 7
9 Aplikační servery ..................................................................................................... 8

2/10 Platforma SŽ – Virtuální prostředí, serverové farmy, servery
Seznam zkratek

ACI Technologie aplikačně orientované infrastruktury firmy Cisco (Cisco ACI)
CPU
DB Hlavní procesor zařízení či počítače, který je zodpovědný za plynulé spouštění
DR software (Central Processing Unit)
FC
H CI Databázová aplikace (Database Engine)

H TTP Plán obnovy po havárii, součást kontinuity IT služeb (Disaster Recovery)
HW
ICT Vysokorychlostní datové rozhraní primárně používané pro datová úložiště
iSCSI (Fibre Channel)

IT Jde o formu softwarově definované serverové infrastruktury. V principu se jedná
LTO o virtualizační platformu, která redundantně sdílí v rámci clusteru vše – výpočetní
NAS výkon, paměť i datové úložiště (Hyperconverged Infrastructure)
Standardizovaný protokol pro přenos webových stránek (Hyper-text Transfer
OS Protokol)
SAN
SAP Hardware označuje veškeré fyzicky existující technické vybavení počítače
SOH O
SW Informační a komunikační technologie (Information and Communication
SŽ Technology)
SŽT
VDI Protokol, který umožňuje připojení k diskovým zdrojům přes počítačovou síť. To
umožňuje serverům, aby mohly vzdáleně používat disky jako by byly připojeny
VM přímo k nim, což umožňuje centralizaci a vzdálený přístup k datům. iSCSI je často
používán v malých a středních podnicích jako alternativa k SAN (Internet Small
Computer System Interface)

Informační technologie (Information Technology)

Otevřený formát magnetické pásky určené pro záznam velkých objemů dat (Linear
Tape Open)

Zařízení pro ukládání a správu dat, které je připojeno k počítačové síti a umožňuje
přístup k datům přes souborové protokoly jako SMB, NFS, FTP a HTTP. NAS může
být malé zařízení pro jeden či několik disků určené pro domácnosti nebo může jít
profesionální zařízení určené pro montáž do racku (Network Attached Storage)
Operační systém

Oddělená datová síť pro připojení datových úložišť. Zpravidla používá protokol FC
nebo iSCSI (Storage Area Network)

Modulární ERP systém od německé firmy SAP AG

Obecné označení pro zařízení pro domácí a kancelářské použití (Small Office /
Home Office)

Software je sada všech počítačových programů používaných v počítači, které
provádějí nějakou činnost
Správa železnic, státní organizace
Správa železničních informačních technologií

Technologie, která umožňuje uživatelům pracovat na virtuálním desktopu
odděleném od jejich fyzického zařízení. Tyto virtuální desktopy jsou hostovány na
centrálním serveru a uživatelé se k nim připojují pomocí klientských zařízení, jako
jsou stolní počítače, notebooky nebo mobilní zařízení (Virtual Desktop
Infrastructure)

Virtuální počítač (Virtual Machine)

Seznam vysvětlivek

Platforma SŽ Soubor dokumentů, rozdělený na veřejnou, interní a metodickou část, určený
pro seznámení dodavatelů se standardy a technologiemi v ICT prostředí SŽ.

Platforma SŽ – Virtuální prostředí, serverové farmy, servery 3/10
1 Úvod

Cílem této části Platformy SŽ je popis podporovaných infrastrukturních služeb, technologií,
a architektonických principů v oblasti virtualizačního prostředí, fyzických serverů a virtuálních
serverů všech typů v ICT prostředí Správy železnic. Tato příloha definuje jak poskytované
infrastrukturní služby v rámci veřejných zakázek a návrhů dodávaných řešení, tak i samotné
budování a rozšiřování virtualizačního prostředí Správy železnic.

Cílem je zajistit ve fázích přípravy poptávky, návrhu ICT řešení a realizace dodávky
kompatibilitu se stávajícím ICT prostředím Správy železnic a v maximální míře využít již
provozované komponenty a technologie.

2 Virtualizační prostředí

Správa železnic postupně transformuje starší serverovou infrastrukturu na moderní virtuální
řešení avšak s ohledem na rozsáhlost ICT prostředí SŽ je tento proces stále aktuální. Velmi
efektivní je stále také virtualizace koncových počítačů (VDI) ve spojení s centralizovaným
řízením dopravy.

2.1 Virtualizace serverů

Správa železnic ve svém ICT prostředí provozu větší množství serverových farem poskytujících
virtuální prostředí pro běh virtuálních serverů.

Starší a konzervativnější technologií jsou virtualizace na software MS HyperV (nepreferované
řešení určené výhradně pro singlenody) a na software VMware vSphere (vícenodové farmy
s dedikovanou storage připojenou zpravidla přes Fibre Channel).

Novější technologií je pak HCI s využitím software VMware vSphere a VMware vSAN.

2.2 Virtualizace koncových počítačů

Virtualizace typu VDI je provozována na řešení VMware Horizon a slouží především pro
dispečerské stanice dálkového řízení.

S ohledem na specifické určení není tato technologie součástí infrastrukturních služeb
nabízených Platformou SŽ.

2.3 Kontejnerizace

V ICT prostředí Správy železnic probíhá testování a development virtualizačního řešení pro
platformy Docker a Kubernetes. V současné chvíli není možné toto nabídnout jako
infrastrukturní službu v rámci Platformy SŽ.

3 Serverové farmy

Správa železnic provozuje větší množství serverových farem různých velikostí od 3 nodů až po
16 serverových nodů na různých technologiích (klasická virtualizace, virtualizace v OS, HCI,
VDI). Z důvodu vzájemné kompatibility jsou využívány výhradně CPU x86_ 64 verze 3 od firmy
Intel.

3.1 Konvergovaná infrastruktura

V rámci konvergované infrastruktury provozuje SŽ tyto druhy farem:

4/10 Platforma SŽ – Virtuální prostředí, serverové farmy, servery
• Jedno-nodové virtualizace na řešení Microsoft Hyper-V – jedná se o nepreferované
řešení výhradně jen pro virtualizaci OS Windows Server.

• Klasická virtualizace s dedikovanou storage – preferované řešení pro menší clustery
• Virtualizace VDI – výhradní řešení pro virtualizaci koncových počítačů

3.2 H yper-konvergovaná infrastruktura

V minulých letech Správa železnic úspěšně adoptovala technologii HCI a v současné době na ní
provozuje více než 10 serverových farem ve velikostech od 4 nodů až po 16 nodů.

Všechny tyto nové HCI clustery umožňují v budoucnosti zapojení do topologie Cisco ACI jako
Remote Leaf.

Rozšiřování těchto farem musí respektovat tato pravidla a současně je z důvodu kompatibility
nutné dodržet vždy shodné parametry serverových nodů a technologií.

4 Fyzické servery

Samostatné fyzické servery již není možné do ICT prostředí Správy železnic umisťovat. Pokud
je to technicky možné musí být nahrazeny virtualizovaným řešením. Výjimkou jsou návrhy
řešení a dodávky hotových fyzických appliance, pokud jejich výrobce nedodává virtualizovanou
verzi.

U fyzických serverů nedokáže Správa železnic zajistit stejné a plnohodnotné podpůrné služby
jako u virtualizovaných serverů (monitoring, patch management, zálohování, …).

Výjimky posuzuje Odbor IT architektury SŽT v procesu tvorby a/nebo akceptace technické
specifikace veřejné zakázky.

5 Datová úložiště

V ICT prostředí Správy železnic je provozováno více druhů datových úložišť.

5.1 Datová úložiště farem

Pro farmy klasické konvergované infrastruktury jsou provozovány datová úložiště:

• Umisťují se do rackových skříní.
• Slouží výhradně pro připojení daného serverového clusteru.
• Využívají výhradně disky typu SSD nebo NVMe v redundanci minimálně RAID6 nebo

obdobném ekvivalentu.
• Velikost i výkon musí odpovídat potřebám konkrétní farmy.
• Preferované připojení je pomocí Fibre Channel, případně i iSCSI nebo přímé připojení

SAS.

5.2 Datová úložiště pro zálohy a archivaci

Pro ukládání záloh a archivaci jsou určena datová úložiště:

• Umisťují se do rackových skříní.
• Slouží výhradně pro ukládání záloh.
• Využívají výhradně disky typu NL-SAS nebo SAS v redundanci minimálně RAID5 nebo

vyšším. Disky nesmí používat technologii SMR.
• Velikost i výkon musí odpovídat potřebám zálohování farem.
• Preferované připojení je pomocí Fibre Channel, případně i iSCSI nebo přímé připojení

SAS.

Platforma SŽ – Virtuální prostředí, serverové farmy, servery 5/10
5.3 Datová úložiště pro off-line zálohy

Pro archivaci a offline ukládání záloh jsou určeny páskové knihovny:

• Umisťují se do rackových skříní v DR lokalitách a připojují se na backup server.
• Slouží výhradně pro ukládání offline záloh na LTO pásky.
• Využívají pásky typu LTO 9.
• Počet mechanik i počet pásek v knihovně musí odpovídat potřebám offline zálohování.
• Preferované připojení je pomocí Fibre Channel nebo přímé připojení SAS.
• Musí být zajištěn proces pravidelné a bezpečné manipulace s páskami a jejich

ukládáním.

5.4 Kancelářská datová úložiště

Lokální zařízení typu NAS nejsou preferovaná a jejich zapojení do sítě Správy železnic podléhá
schválení Odboru IT architektury SŽT.

Mála SOHO zařízení typu NAS umisťovaná mimo rackové skříně, typicky do kancelářských
prostor, jsou nepřípustná a nesmí být připojována do ICT prostředí Správy železnic.

Větší disková úložiště typu NAS umisťovaná do rackových skříní lze na základě posouzení
a výjimky Odboru IT architektury připojit do sítě SŽ. Redundance disků musí na úrovni RAID5
nebo vyšší.

6 Virtuální servery

Virtualizace v ICT prostředí Správy železnic poskytuje základní infrastrukturní služby jejichž
seznam a popis prezentuje Platforma SŽ.

6.1 Služba virtuálních strojů

Infrastrukturní služba VM je provozována na vysoce dostupných virtualizačních technologiích
VMware. Parametry služby jako sizing virtuálních strojů, výběr OS podporovaných
Platformou SŽ, počet a konfigurace síťových karet jsou konfigurovány individuálně na základě
požadavků projektu, resp. dodávaného řešení.

Správa železnic zajišťuje vysokou dostupnost služby virtuálních strojů na úrovni virtualizace i
sítě, a to v rámci jednoho datového centra či serverovny. Pokud navrhované řešení vyžaduje
také georedundanci nebo redundanci napříč datovými centry, musí být dodavatelem v rámci
dodávky zajištěno řešení loadbalancingu.

Služby virtuálních serverů Popis
Služba
Win.VMware.x86_ 64 Služby virtuálního serveru s operačním systémem Windows Server na virtualizaci
RHEL.VMware.x86_ 64 VMware a architektuře x86_64
Debian.VMware.x86_ 64
Služby virtuálního serveru s operačním systémem RHEL (RedHat Enterprise
SLES.VMware.x86_ 64 Linux) na virtualizaci VMware a architektuře x86_64

Služby virtuálního serveru s operačním systémem Debian Linux na virtualizaci
VMware a architektuře x86_64
Omezení: Preferované řešení pro kontejnerizaci.

Služby virtuálního serveru s operačním systémem SLES (SUSE Linux Enterprise
Server) na virtualizaci VMware a architektuře x86_64
Omezení: Využití pro výhradně pro SAP

6/10 Platforma SŽ – Virtuální prostředí, serverové farmy, servery
6.2 Služby diskových uložišť

Disková kapacita těchto infrastrukturních služeb je provozována v datových úložištích farem, ať
už dedikovaných, nebo interních v rámci technologie VMware vSAN, kde je zajištěna
dostatečná úroveň redundance.

V rámci virtualizačních clusterů jsou dostupné výhradně disky SSD a NVMe. Starší rotační disky
(HDD) jsou dostupné jen jako součást úložišť pro zálohy a archivace. Případný tiering není
součástí služby a je nutné ho řešit na úrovni SW navrhovaného řešení.

Služby diskových úložišť Popis
Služba
Datový disk HDD Služba diskových úložišť pro zálohy a archivaci. Nelze použít pro systémové disky
a/nebo pro provoz aplikací.
Datový disk SSD
Služba diskových úložišť pro aplikace. Není vhodné využívat pro zálohy a
archivaci z důvodu enormní ceny řešení.

7 Databázové servery

V prostředí Správy železnic je provozováno několik typů databázových serverů a v rámci
Platformy SŽ jsou poskytovány tyto platformní služby:

Služby databázových prostředí Popis

Služba Databázová služba Oracle DB provozovaná na optimalizovaném hardware Oracle
Exadata Database Machine – kombinovaná hardwarová a softwarová platforma.
Oracle DB
na Oracle Exadata Služba virtuálních databázových serverů MS SQL Server provozovaná na
serverech s operačním systémem Windows Server a virtualizační platformě
MS SQL VMware.
na Win.VMware.x86_ 64

8 Webové servery

V prostředí Správy železnic je provozováno několik typů webových serverů a v rámci Platformy
SŽ jsou poskytovány tyto platformní služby:

Služby webových serverů Popis
Služba
Microsoft IIS Služba webového serveru postavená na technologií Microsoft Internet
na Win.VMware.x86_ 64 Information Services (IIS) provozovaná na serverech s operačním systémem
Windows Server s virtualizací VMware.
Apache HTTP Server
na Win.VMware.x86_ 64 Služba webového serveru postavená na open-source technologii Apache
provozovaná na serverech s operačním systémem Windows Server s virtualizací
Apache HTTP Server VMware.
na RHEL.VMware.x86_ 64
Služba webového serveru postavená na open-source technologii Apache
provozovaná na serverech s operačním systémem RHEL s virtualizací VMware.

Platforma SŽ – Virtuální prostředí, serverové farmy, servery 7/10
9 Aplikační servery

V prostředí Správy železnic je provozováno jedno portálové řešení, které je v rámci Platformy
SŽ poskytováno jako platformní služba:

Služba zabezpečeného portálového řešení

Služba Popis

Liferay Liferay je přední open-source podnikové portálové řešení založené na jazyce
na Win.VMware.x86_ 64 Java, které umožňuje správu dat, aplikací, procesů a integrace současných i
nových aplikací z jednoho centrálního uživatelského rozhraní.

8/10 Platforma SŽ – Virtuální prostředí, serverové farmy, servery
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Konektivita a síťové
prost edí

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 6

2 Perimetr Správy železnic .......................................................................................... 6

2.1 Perimetr ....................................................................................................... 6

2.2 Demilitarizovaná zóna .................................................................................... 6

2.2.1 Demilitarizovaná zóna pro OT ............................................................. 6

2.3 P ístup p es VPN ............................................................................................ 6

2.3.1 Uživatelské VPN s MFA ...................................................................... 7

2.3.2 Site to Site VPN ................................................................................ 7

2.4 Komunikační směry ........................................................................................ 7

3 Fyzické sítě Správy železnic ...................................................................................... 8

3.1 Uživatelsko-aplikační síť.................................................................................. 8

3.2 Technologické datové sítě ............................................................................... 8

3.2.1 Segmentace sítě ............................................................................... 8

3.2.2 Ostrovní oddělené sítě ....................................................................... 8

4 Logické síťové prost edí ............................................................................................ 9

4.1 Komunikace mezi sítěmi ................................................................................. 9

4.2 Georedundance ............................................................................................. 9

4.3 ešení High Availability................................................................................... 9

5 Sítě APN ................................................................................................................10

6 Síťová za ízení........................................................................................................10

6.1 Používané technologie ...................................................................................10

6.1.1 VLAN..............................................................................................10

6.1.2 VRF................................................................................................10

6.1.3 Technologie DWDM ..........................................................................11

6.1.4 Sítě MPLS .......................................................................................11

6.1.5 Síťová spine-leaf topologie ................................................................11

6.1.6 Technologie Cisco ACI ......................................................................11

6.1.7 Sítě OOB ........................................................................................11

6.2 Firewally ......................................................................................................12

6.3 Routery .......................................................................................................12

6.4 Switche .......................................................................................................12

6.4.1 Switche pro datová centra ................................................................13

6.4.2 Switche pro fibre channel..................................................................13

6.4.3 Switche pro kamerové systémy .........................................................13

6.4.4 Switche pro management za ízení......................................................13

6.4.5 Switche pro lokální sítě.....................................................................14

6.5 Huby ...........................................................................................................14

6.6 Modemy a datová za ízení..............................................................................14

2/16 Platforma SŽ – Konektivita a síťové prost edí
Seznam zkratek

ACI Aplikačně orientovaná infrastruktura
APN
CLI Jméno brány mezi mobilní datovou sítí a jinou počítačovou sítí (může obsahovat MCC
DB a MNC daného mobilního operátora) (Access Point Name)
DC P íkazový ádek (Command Line Interface)
DCS
DDoS Databáze

DMZ Datové centrum v kontextu lokalit (Datacenter)

DoS Distribuovaný systém ízení technologií (Distributed Control System)

DR Distribuované odmítnutí služby je technika útoku na internetové služby nebo stránky,
DSL p i níž dochází k p ehlcení požadavky a k pádu nebo nefunkčnosti a nedostupnosti
systému pro ostatní uživatele, a to útokem mnoha koordinovaných útočníků
DWDM (Distributed Denial of Service)

GPRS Část síťové infrastruktury organizace, ve které jsou soust eděny služby poskytované
někomu z okolí, p ípadně celému Internetu. Tyto vnější (ve ejné) služby jsou obvykle
HA nejsnazším cílem internetového útoku; úspěšný útočník se ale dostane pouze do
HW DMZ, nikoli p ímo do vnit ní sítě organizace (Demilitarized Zone)
ICS
ICT Odmítnutí služby je technika útoku na internetové služby nebo stránky, p i níž
IKEv2 dochází k p ehlcení požadavky a k pádu nebo nefunkčnosti a nedostupnosti systému
pro ostatní uživatele (Denial of Service)
Industrial DMZ
Plán obnovy po havárii, součást kontinuity IT služeb (Disaster Recovery)
IPsec
Technologie pro vysokorychlostní p ipojení k internetu, která využívá telefonní linku.
IT DSL umožňuje p enos dat p es kovový vedení telefonní sítě s využitím frekvenčního
LAN spektra, které není využíváno pro telefonní hovory (Digital Subscriber Line)
LTE
MFA Typ vlnového multiplexu, který je založený na multiplexování více optických signálů
v jednom optickém vlákně na různých vlnových délkách nebo různých typech laserů
(Dense Wavelength Division Multiplex)

GPRS je mobilní datová služba první generace. Dnes je GPRS již zastaralou
technologií a byla nahrazena modernějšími technologiemi, jako jsou nap íklad 4G
a 5G (General Packet Radio Service)

Vysoká dostupnost služeb. P edpokladem ešení je použití dvou a více nezávislých
za ízení s cílem zajistit funkčnost v p ípadě výpadku (High Availability)

Hardware označuje veškeré fyzicky existující technické vybavení počítače

Průmyslové ídicí systémy (Industrial Control System)

Informační a komunikační technologie (Information and Communication Technology)

Protokol pro šifrování síťových spojení, který se používá k zabezpečení VPN
a jakýchkoliv jiných síťových spojení. Tento protokol je specifikován jako standard
Internet Engineering Task Force, nabízí vysokou úroveň bezpečnosti, dostupnosti
a rychlosti. Dále pak podporuje automatické obnovování spojení, umožňuje rychle
reagovat na změny síťového prost edí a také poskytuje podporu pro více typů
šifrování a autentizace.

Část síťové infrastruktury organizace, ve které jsou soust eděny služby poskytované
někomu z okolí, p ípadně do jiných sítí. P ípadným úspěšným útokem se ale útočník
dostane pouze do Industrial DMZ, nikoli p ímo do vnit ní sítě s vyšší bezpečnostní
úrovní (Industrial DeMilitarized Zone)

Jedná se o protokol, který se používá k šifrování a ochraně dat p enášených p es
Internet. IPsec se často používá k ochraně VPN spojení, ale také může být použit
k ochraně jakýchkoli dat p enášených p es internetové sítě. Šifrování zabraňuje
neoprávněnému čtení dat, zatímco autentizace zajišťuje, že data pocházejí od
autorizovaného zdroje. Tyto funkce pomáhají chránit síť p ed neoprávněným
p ístupem, únikem dat a jinými bezpečnostními hrozbami (Internet Protocol Security)
Informační technologie (Information Technology)
Místní počítačová síť (Local Area Network)

ešení mobilního bezdrátového vysokorychlostního p enosu dat čtvrté generace
(4G / Long Term Evolution)

Více-faktorové ově ení identity uživatele (Multi-Factor Authentification)

Platforma SŽ – Konektivita a síťové prost edí 3/16
MGMT ízení, dohled, konfigurace, sběr dat a vzdálený p í tup k serverům a aktivním
MPLS síťovým prvkům (Management)

NGFW Multi-protokolové p epojování podle značek – metoda směrování síťového provozu
OOB používaná ve vysokorychlostních telekomunikačních sítích, která pro směrování
nepoužívá relativně dlouhé a protokolově závislé síťové adresy, ale krátké značky
O pevné délky. Standard je definován v RFC 3031 (Multiprotocol Label Switching)
OS
OT Oproti běžným FW nabízí také doplňkové funkce jako AVC, AMP, IPS, IDS, DPI, DLP,
PAM TD, IdM a dešifrování a kontrolu TLS/SSL obsahu (Next-Generation Firewall)

PLC Oddělená síť určená pro management serverů a aktivních síťových prvků.
PoE Z oprávněných provozních a technických důvodů lze požadavek na oddělení splnit
užitím vyhrazených VLAN nebo VRF VPN (Out-of-Band MGMT LAN)
RJ45
S2S VPN Oblastní editelství SŽ
SAN
SCADA Operační systém (Operating System)
SFP
SFP+ Provozní technologie (Operations Technology)
SMS
SW ešení zabezpečení identit, které pomáhá chránit organizaci p ed kybernetickými
SŽ hrozbami monitorováním, zjišťováním a prevencí neoprávněného privilegovaného
SŽT p ístupu k důležitým prost edkům (Privileged Access Management)
TDS
UAS Programovatelný automat, typické koncové za ízení v OT (Programmable Logic
VM Controller)
VPN
VRF Technologie napájení za ízení p es standardní ethernetový kabel. PoE existuje
v několika standardech, které se liší p edevším p enášeným elektrickým výkonem
WAF (Power over Ethernet)

Standardizovaný metalický konektor pro počítačové sítě (Registered Jack 45)

Šifrované VPN p ipojení zajišťující propojení dvou LAN (Site-to-Site VPN, LAN-to-LAN
VPN)

Oddělená datová síť pro p ipojení datových úložišť. Zpravidla používá protokol FC
nebo iSCSI (Storage Area Network)

Softwarové ešení zpravidla dispečerského dohledu a monitorování technologií
(Supervisory Control And Data Acquisition)

Typ slotu a modulu pro datovou komunikaci zpravidla po optických vláknech.
Podporuje rychlost maximálně 1 Gbps (Small Form Factor Pluggable)

Typ slotu a modulu pro datovou komunikaci zpravidla po optických vláknech.
Podporuje rychlost maximálně 10 Gbps (Small Form Factor Pluggable Plus)
Krátká textová zpráva

Programové vybavení počítače či jiného obdobného za ízení. Speciálním druhem
software je firmware, který je úzce spjatý s konkrétním hardwarem (Software)

Správa železnic, státní organizace

Správa železniční telematiky, organizační jednotka SŽ

Technologické datové sítě SŽ, jedná se o více VRF zpravidla vyhrazených pro OT,
běžně se nazývají také „Techlan“

Logická uživatelsko-aplikační síť SŽ, zahrnuje VRF v MPLS sítích a lokální VLAN,
běžně se nazývá také „Intranet SŽ“

Virtuální počítač (Virtual Machine)

Virtuální privátní síť (Virtual Private Network)

Virtuální směrování a p edávání technologie, která v počítačových sítích založených
na protokolu IP umožňuje souběžnou existenci více instancí směrovací tabulky v
rámci sítě stejného směrovače ve stejnou dobu (Virtual Routing and Forwarding)

WAF je druh firewallu, který se specializuje na zabezpečení webových aplikací a
webových stránek. WAF slouží k ochraně webových aplikací p ed různými druhy
útoků, jako jsou SQL injection, Cross-Site Scripting a další. WAF využívá různé
techniky pro detekci a blokování nežádoucího provozu, včetně filtrace vstupů,
detekce neobvyklých činností a analýzy protokolu HTTP. WAF může být nasazen jako
samostatné za ízení, jako virtuální síťový prvek nebo jako součást firewallu sítě. WAF
může být konfigurován pro konkrétní webové aplikace a stránky, aby poskytoval co
nejlepší ochranu p ed útoky. Mezi funkce WAF pat í nap íklad blokování útoků v
reálném čase, sledování webových aplikací a identifikace bezpečnostních rizik, správa
povolených a zakázaných p ístupů a další. WAF může fungovat i jako load balancer
pro webové servery (Web Application Firewall)

4/16 Platforma SŽ – Konektivita a síťové prost edí
ZoKB Zákon o kybernetické bezpečnosti č. 181/2014 Sb. a souvisejících zákonů v
pozdějším znění

Seznam vysvětlivek

Active-Active Distribuce zátěže na více nebo všechny síťové prvky.
Industrial DMZ
Část síťové infrastruktury organizace, ve které jsou soust eděny služby
Jump server poskytované někomu z okolí, p ípadně do jiných sítí. P ípadným úspěšným
útokem se ale útočník dostane pouze do Industrial DMZ, nikoli p ímo do
vnit ní sítě s vyšší bezpečnostní úrovní

Zabezpečené a monitorované za ízení, které spojuje dvě různé
bezpečnostní zóny.

Platforma SŽ Soubor dokumentů, rozdělený na ve ejnou, interní a metodickou část,
určený pro seznámení dodavatelů se standardy a technologiemi v ICT
Purdue Model prost edí SŽ.
Site-to-Site Strukturální model pro zabezpečení průmyslových ídících systémů.
Spine-Leaf
Propojení dvou a více vzdálených sítí.
Standard IEEE 802.3af
Standard IEEE 802.3at Dvouvrstvá síťová topologie switchů spine a leaf vyvinutá pro datová
centra.
Standard IEEE 802.3bt
Standard pro PoE napájení. Maximální p enášený výkon je 15,4 W.

Standard pro PoE napájení, který se označuje jako PoE+. Maximální
p enášený výkon je 30 W.

Standard pro PoE napájení, který se označuje jako PoE++. Maximální
p enášený výkon je 60 W.

Platforma SŽ – Konektivita a síťové prost edí 5/16
1 Úvod

Tento dokument je p ílohou a nedílnou součástí Základního dokumentu Platformy SŽ a definuje
základní principy a pravidla síťové komunikace v ICT prost edí Správy železnic. Současně
popisuje síťové prost edí a poskytované služby ze strany Správy železnic.

2 Perimetr Správy železnic

2.1 Perimetr

Perimetrem se označuje část systémů, které jsou využity pro komunikace mimo interní sítě
SŽ. Jde o významnou součást celé ICT infrastruktury. Hlavními aspekty pro perimetr sítě jsou
dvě oblasti:

• Bezpečnost – kontrola komunikace a ochrana p ed proniknutím z oblastí mimo síť
Správy železnic (Internet, sítě externích dodavatelů).

• Výkonnost – p edpokladem perimetru je koncentrace komunikace v obou směrech,
tedy, jak p eklad provozu na vnit ní aplikace (web služby, mail systém, VPN), tak
i komunikace ze sítě ven (Internet, aplikace a služby t etích stran).

Perimetr a vnější zabezpečení sítě v sobě spojuje více služeb dále využívaných v ICT
infrastruktu e. Jde primárně o služby ochrany proti DDoS, oddělené DMZ a terminace VPN
p ipojení.

2.2 Demilitarizovaná zóna

Demilitarizovaná zóna (DMZ) je bezpečnostní mechanismus, který se používá v síťové
architektu e pro umístění systémů dostupných z Internetu, či dalších lokalit mimo bezpečnostní
perimetr. DMZ se v prost edí SŽ nachází na hranici sítě mezi Internetem a vnit ní sítí
organizace a obsahuje servery, WAF, VPN koncentrátory a další za ízení, která mají být
p ístupná ze sítě Internet.

Definici DMZ určují pravidla v NGFW, na základě těchto pravidel je striktně zakázána
komunikace z vnit ní sítě p ímo do Internetu bez použití DMZ a stejně tak i opačný směr.

2.2.1 Demilitarizovaná zóna pro OT

Princip industriální DMZ spočívá v použití firewallu mezi IT a OT sítí, neboli mezi uživatelskou
a technologickou sítí a vytvo ení bezpečného prost edí pro umístění aplikací a za ízení pro
p enos dat mezi těmito sítěmi, nap . jump servery, integrační koncentrátory, integrační
servery a jiné. V síti SŽ je totiž striktně zakázán p ímý p ístup z uživatelské do technologické
sítě a naopak.

2.3 P ístup p es VPN

Jde o službu pro realizaci šifrované komunikace z externího prost edí na aplikace či hardware
ve vnit ních sítích a také pro jejich správu. VPN bývá provozována ve dvou základních
režimech, a to jako Site to Site VPN (určeno pro p ipojení celých počítačových sítí nebo
serverů) nebo jako uživatelská Client to Site VPN s MFA (multifaktorovou autentizací) pro
p ístup zaměstnanců a externistů k za ízením a službám v prost edí Správy železnic.

Pro externí Dodavatele je možné z ídit VPN p ístup na konkrétní servery a systémy v UAS nebo
v TDS.

6/16 Platforma SŽ – Konektivita a síťové prost edí
2.3.1 Uživatelské VPN s MFA

Klientské VPN jsou ešené pomocí Cisco AnyConnect klientů s ově ením p es multifaktorovou
autentizaci (MFA). MFA je vyžadováno pro další ově ení uživatele pomocí jednorázového kódu
doručeného prost ednictvím SMS na zaregistrované telefonní číslo.

Pro tyto VPN platí následující pravidla:

• Není povolený split-tunnel.
• Pro externisty není p es VPN povolen p ístup k síti Internet.
• Pro ešení MFA je krom SMS používán i MS Authenticator.

Pro p ístup na cílová za ízení je povinné využít bezpečnostní systém PAM. P ístup na cílové
technologie mimo systém PAM je umožněn pouze na výjimku ze strany Odboru Kybernetické
bezpečnosti SŽT, nap íklad pokud cílový systém není možné integrovat do systému PAM. P i
zavádění systému je nutné poskytnout aktivní spolupráci Dodavatele se Správou železnic
(poskytnout pot ebné informace – použité protokoly pro vzdálený p ístup, testovací účty,
ově ení funkčnosti) pro zprovoznění vzdáleného p ístupu skrze bezpečnostní systém PAM.

2.3.2 Site to Site VPN

Pro p ipojení vzdálených lokalit či podpůrných systémů mimo síť SŽ se používají S2S VPN
s protokolem IPsec IKEv2. Z důvodů vyžadovaných ZoKB musí být komunikace z těchto S2S
VPN explicitně omezena jen na konkrétní vyjmenovaná za ízení (servery apod.) a je nutné
u p ipojené protistrany zajistit průkaznou identifikaci uživatelů, kdo a kdy vyžil p ístup skrze
S2S VPN. Tyto záznamy musí poskytnout na požádání SŽ. Je nutné mít odůvodněný požadavek
pro použití S2S VPN. Pokud je to provozně/technicky možné jsou preferované jmenné VPN
vázané na konkrétní osobu.

2.4 Komunikační směry

Správa železnic má na základě běžných síťových standardů a praktik vydefinovány povolené
a zakázané směry síťové komunikace, tak aby byla zajištěna nejvyšší úroveň zabezpečení sítí,
informačních systémů i celého ICT prost edí.

Pravidla síťové komunikace na perimetru SŽ

Zdroj Směr Cíl Stav
filtrováno
UAS DMZ zakázáno
filtrováno
UAS DMZ filtrováno
zakázáno
VPN DMZ zakázáno
filtrováno
APN DMZ filtrováno
zakázáno
APN UAS filtrováno
filtrováno
APN TDS zakázáno
filtrováno
APN Industrial DMZ filtrováno
zakázáno
UAS VPN zakázáno
filtrováno
TDS DMZ zakázáno
zakázáno
TDS Industrial DMZ

UAS Industrial DMZ

UAS TDS

UAS Internet

Internet VPN (zaměstnanecká)

Internet VPN (externisté)

Internet S2S VPN

Internet DMZ

Internet UAS

Internet TDS

Platforma SŽ – Konektivita a síťové prost edí 7/16
Na základě těchto pravidel veškerá komunikace mezi vnit ními sítěmi a Internetem probíhá
výhradně p es aplikace nebo za ízení umístěná v DMZ na perimetru Správy železnic. P ímá
komunikace z uživatelsko-aplikační sítě do sítě Internet není povolena, existují však specifické
výjimky. Tato omezení platí i pro zabezpečené sítě datových center a serveroven a tedy stejně
tak, p ímá komunikace ze serverů do sítě Internet (aktualizace, stažení instalačních balíčků)
není povolena. Vždy je nutné využít nep ímé komunikace p es proxy server nebo obdobná
za ízení. I zde existuje výjimka a pro specifické systémy lze tuto komunikaci povolit.

Pokud nějaké konkrétní za ízení nebo informační systém není schopen z objektivních
technických důvodů tato omezení dodržet p i zachování své funkce, je nutné p ed
implementací takového ešení požádat o výjimku u Odboru IT architektury SŽT, kde bude
výjimka posouzena a povolena nebo zakázána, p ípadně bude zvoleno alternativní ešení.

3 Fyzické sítě Správy železnic

3.1 Uživatelsko-aplikační síť

Jedná se o rozsáhlou komunikační síť pro veškerý kancelá ský i podpůrný provoz, jsou zde
umístěny běžné uživatelské počítače, tiskárny, skenery, ale i serverovny a datacentra pro
provoz farem a aplikací. Servery pro IT jsou provozovány výhradně v této síti.

V současné době je uživatelsko-aplikační síť (UAS) provozována ve staré MPLS síti, kdy páte ní
uzly komunikační infrastruktury UAS jsou navzájem propojeny, zajišťují směrování síťových
komunikací a na vybraných trasách i redundanci v p ípadě ztráty průchodnosti tras.

3.2 Technologické datové sítě

Tyto sítě jsou v prost edí Správy železnic určeny primárně pro OT za ízení a p evážně pro
provozní drážní a jejich podpůrné systémy. Jsou striktně definované a vlastnostmi odpovídají
nejvyšším zabezpečovacím standardům pro provoz kritické i nekritické infrastruktury.

Jednotlivé technologické sítě v TDS jsou rozdělené dle konkrétních technologií na úrovni
separátních VRF. Od UAS jsou odděleny pomocí firewallů, p ístup k OT za ízením je umožněn
pouze p es jump servery či jiné systémy (koncentrátory) umístěné v IT/OT DMZ. Za ízení ani
uživatelé v TDS nemají p ímý p ístup do sítě UAS ani Internet a to včetně aktualizací SW atp.

3.2.1 Segmentace sítě

V nedávné době proběhl v prost edí SŽ projekt „Rekonstrukce a segmentace technologických
sítí“, jejímž cílem byla migrace z původní sítě do nově segmentované MPLS sítě, včetně z ízení
šesti segmentů propojených p echodovými firewally.

Segmentace UAS se v současné době aktivně p ipravuje, čili tato síť zatím není segmentována,
rozdělena.

3.2.2 Ostrovní oddělené sítě

V prost edí SŽ se z důvodu kritické infrastruktury vyskytují rovněž oddělené (ostrovní) sítě, ty
jsou fyzicky nebo virtuálně síťově odděleny od ostatních sítí pomocí firewallu tak, aby jejich
provoz nemohl být narušen. Typickým p íkladem můžou být sítě pro elektro dispečinky.

8/16 Platforma SŽ – Konektivita a síťové prost edí
4 Logické síťové prost edí

V logickém síťovém prost edí je aplikován modifikovaný Purdue model pro ICS v podobě
8 vrstev. Pot ebné oddělení mezi IT a OT prost edím pomocí industriální DMZ je prováděno
IT/OT firewally. Jedná se o zásadní prvek zabezpečení OT provozu.

Obrázek 1: Purdue ICS model

4.1 Komunikace mezi sítěmi

Komunikace mezi sítěmi je ízena na základě výše zmíněného Purdue modelu, je ízena
a kontrolována firewally v dané oblasti, firewally v perimetru nebo v datových centrech.
Datová komunikace uživatelů je primárně navazována ze zóny s vyšší bezpečnostní úrovní do
zóny s nižší bezpečnostní úrovní. Komunikace systémů s nižší bezpečnostní úrovní do zóny
s vyšší bezpečnostní úrovní je ve výchozím stavu zakázána. Komunikace mezi jednotlivými OT
sítěmi (VRF VPN) jsou ízeny pomocí FW, který je v rámci lokality nebo O anebo centrální
v rámci struktury WAN.

4.2 Georedundance

Díky možnostem rozsáhlé sítě Správy železnic se naplno využily výhody georedundance, čili
distribuce na více fyzických lokalit, ať už z důvodu vysoké dostupnosti či rozdělení zátěže
jednotlivých systémů. V rámci nového perimetru sítě je zajištěna sekundární konektivita do
sítě Internet, v tuto chvíli se však nejedná o georedundantní ešení.

4.3 ešení High Availability

Pro všechny klíčové prvky síťového prost edí je požadován provoz ve vysoké dostupnosti, tedy
zajištění síťového provozu bez p erušení pomocí redundance.

Platforma SŽ – Konektivita a síťové prost edí 9/16
• Clustering – redundance dvou a více prvků je možné provozovat v módech active-
passive nebo active-active (Load Balancing), nap . perimetr sítě je implementován
v plném active-active režimu, segmentační firewally jsou v active-passive režimu, vždy
záleží na konkrétní implementaci za ízení a nárocích na vysokou dostupnost.

• Síťové prvky i optické propoje páte ní MPLS sítě jsou redundantní a je realizováno
p ipojení vždy z více směrů.

5 Sítě APN

Pro některé konkrétní, striktně definované aplikace jsou využívány mobilní služby p enosu dat
protokolem LTE nebo GPRS. Každá taková aplikace je provozována v uzav ené síti (APN),
zakončená na perimetru SŽ, s definovaným rozsahem IP adres a firewallovými pravidly. Pro
p enos dat do sítě UAS se vždy používá DMZ, p ímý p ístup z APN do sítě Internet je zakázán.
Vlastní APN slouží nap . pro tablety strojvedoucích, sběr mě ených hodnot z kolejových
vozidel, IoT a další za ízení nekritické infrastruktury p ipojené mimo síť Správy železnic.

6 Síťová za ízení

Tato kapitola popisuje seznam komoditních ICT služeb a jednotlivých HW/SW komponent,
které tvo í standard v rámci Správy železnic. Cílem je zajistit ve fázích p ípravy poptávky,
návrhu ICT ešení a realizace dodávky kompatibilitu se stávajícím ICT prost edím
a v maximální mí e využít již provozované komponenty a technologie. Seznam služeb
a komponent je průběžně aktualizován.

6.1 Používané technologie

Níže je výčet a popis základních síťových technologií používaných v prost edí Správy železnic.

6.1.1 VLAN

Aktivní síťové prvky musí plně podporovat VLAN. Pro aktivní datovou komunikaci v sítích SŽ je
zakázáno, pokud je to technicky možné, používat defaultní VLAN 1 a tato VLAN se nesmí
používat jako nativní (PVID) VLAN na trunk portech. Nastavení trunk portů musí být statické.
Automatické vyjednávání je povoleno, jen v krajním p ípadě z technických důvodů na co
nejkratší možnou dobu, kdy není jiná možnost.

6.1.2 VRF

Virtual Routing and Forwarding (VRF) je technologie používaná v sítích pro oddělení a izolaci
síťového provozu na virtuální síťové segmenty. Každá VRF reprezentuje oddělenou síť, která
má vlastní směrovací tabulky a rozhraní. Využívá se zejména v prost edí, kde se vyskytují
různé typy síťového provozu, které se musí oddělit a izolovat, aby nedocházelo ke kolizím nebo
únikům dat. VRF umožňuje vytvo it více logických sítí v jedné fyzické síti a zajistit tak
bezpečné oddělení a izolaci síťového provozu.

Využití VRF VPN se obvykle pojí s technologií MPLS, která umožňuje efektivní směrování
a p epínání datových toků mezi jednotlivými virtuálními sítěmi.

VRF Lite je technologie Virtual Routing and Forwarding (VRF) bez podpory MPLS. Oproti VRF
VPN, která využívá MPLS pro směrování datových toků mezi různými virtuálními sítěmi,
VRF Lite používá standardní směrování IP paketů v sítích založených na protokolu IP.

Správa železnic využívá VRF pro segmentaci MPLS sítí.

10/16 Platforma SŽ – Konektivita a síťové prost edí
6.1.3 Technologie DWDM

U technologie DWDM jde o metodu vlnového multiplexování, díky tomu se optické vlákno
využije pro více vlnových délek (více barev) pro oddělené datové p enosy.
V rámci celorepublikového ešení síťové infrastruktury Správy železnic jsou použity DWDM
propoje mezi jednotlivými lokalitami jako nosná p enosová technologie pro MPLS sítě i pro
p ímé propoje datacenter, kde nejsou k dispozici p ímá vlákna. DWDM síť obsahuje mnoho
plnohodnotných p ípojných bodů a více opakovačů pro zajištění spojů na velkou vzdálenost,
zároveň poskytuje redundantní p ipojení jednotlivých DWDM bodů z více směrů.

6.1.4 Sítě MPLS

MPLS je technologie sítí, která umožňuje efektivní a spolehlivý p enos datových paketů
vysokého objemu v rozsáhlých sítích. V prost edí Správy železnic jsou vybudovány dvě MPLS
sítě. Stará MPLS síť pro uživatelsko-aplikační síť a některé technologické prvky a nová MPLS síť
určená primárně pro technologické datové sítě. Záměrem SŽ je starou MPLS síť postupem času
opustit.

6.1.5 Síťová spine-leaf topologie

Na rozdíl od klasické 3vrstvé topologie (Access-Distribution-Core) umožňuje Spine-Leaf díky
dvouvrstvé topologii mimo jiné snížení latence mezi servery, snížení počtu fyzických switchů
v datacentru, snížení počtu hopů p i komunikaci mezi servery, zvyšuje propustnost a omezuje
riziko vzniku úzkého hrdla.

Obrázek 2: Schéma Spine-Leaf topologie

Všechny nově instalované datacentrové switche v síťovém prost edí Správy železnic již plně
podporují integraci do Spine-Leaf topologie, ať už p ímým napojením, nebo jako Remote Leaf.

6.1.6 Technologie Cisco ACI

Cisco ACI (Application Centric Infrastructure) je softwarově definované síťové ešení, které
zjednodušuje, automatizuje a zabezpečuje provoz sítě v datových centrech. V prost edí SŽ se
používá výhradně v Network-Centric módu, který je síťově zamě en na tradiční p ístup
k subnettingu a používání VLAN. Jedná se o poměrně nové ešení, v datových centrech se tato
technologie postupně rozši uje, z toho důvodu všechny nově instalované switche v datových
centrech již podporují integraci do Cisco ACI.

6.1.7 Sítě OOB

V datových centrech SŽ je vyžadováno, aby všechny servery a síťové prvky měly k dispozici
dedikovaný síťový port pro dohled a konfiguraci těchto za ízení. Tyto porty se propojují do
oddělené OOB (Out-of-band) sítě, která je síťově oddělena od hlavní datové sítě. Lokálně
v datovém centru se jedná o fyzicky oddělenou síť, v rámci intranetu jsou odděleny virtuálně
pomocí VLAN a VRF.

Platforma SŽ – Konektivita a síťové prost edí 11/16
6.2 Firewally

Vzhledem k množství a různorodosti datových sítí jsou z pohledu kybernetické bezpečnosti
firewally nejdůležitějšími síťovými prvky pro Správu železnic. Je kladen velký důraz na striktně
oddělené provozy mezi uživatelskými a technologickými sítěmi, mezi uživatelskými sítěmi a
datovými centry a samoz ejmě mezi sítěmi SŽ a Internetem. Perimetrický firewall musí
umožňovat testovací mód FW pravidel, který umožní odladit pravidla bez dopadu na probíhající
provoz, dále musí podporovat HA zapojení a distribuovanou konfiguraci. Podle logického
umístění firewallu je zvolen konkrétní model viz následující tabulka.

Výčet používaných / preferovaných typů firewallů

Typ routeru Popis Konkrétní ady
Palo Alto vyšších ad
Perimetr Hraniční firewall Cisco Firepower 31x0
Cisco Firepower 31x0
Pro segmentaci Segmentační firewally pro IT sítě a IT/OT DMZ Fortinet Fortigate vyšších ad
F5 BIG-IP
Pro datová centra Firewall pro aplikační farmy, clustery, single nody, Kemp LoadMaster
NAS atd.

Pro aplikace Firewall na aplikační vrstvě OSI modelu (WAF)

Pro load balancing Loadbalancer pro vyrovnání zátěže serverů

6.3 Routery

Routery, nebo také směrovače, jsou zásadní aktivní síťové prvky pro segmentaci sítí. Podle
způsobu použití jsou děleny na routery pro provoz v MPLS síti, routery v datových centrech
a perimetru sítě, p ípadně pro IT nebo OT sítě.

Jsou podporovány routery Cisco s požadovanými protokoly:

• HSRP – pro hraniční routery
• VRF – pro MPLS routery
• VRF-Lite – pro routery bez MPLS
• BGP – pro hraniční a MPLS routery
• TACACS+
• RADIUS

V následující tabulce jsou uváděny jednotlivé ady vždy pro konkrétní použití.

Výčet používaných / preferovaných typů routerů

Typ routeru Popis Konkrétní ady

MPLS Routery typu P, PE a RR v MPLS síti Cisco ASR
Cisco NCS
MPLS Routery typu CE
Cisco C9400
IT Routery pro datová centra a IT sítě Cisco C9300

OT Lokální routery pro OT sítě Cisco C9300
Cisco ISR4000

Cisco ISR

6.4 Switche

V prost edí SŽ jsou switche (p epínače) nejčastější síťová za ízení, proto existuje velké riziko
možného nasazení nekompatibilních typů s následnou problematickou výměnou za
kompatibilní. Obecně jsou preferované switche od renomovaného výrobce Cisco ady C9xxx
a pro datacentra ada Nexus 9300, u nichž jsou do značné míry zaručené jednotné
konfigurační prost edí (CLI), podpora VLAN bez omezení jejich počtu, kompatibilita
používaných síťových protokolů, možnost stohování dedikovaným portem aj.

Jsou požadovány síťové a autorizační protokoly jako:

12/16 Platforma SŽ – Konektivita a síťové prost edí
• HSRP – Hot Standby Router Protocol
• PVST+ – Per-VLAN Spanning Tree Plus
• TACACS+
• RADIUS

Platí zákaz používání switchů bez managementu. V následujících podkapitolách jsou uváděny
jednotlivé ady vždy pro konkrétní použití.

6.4.1 Switche pro datová centra

K již zmiňovaným požadavkům je u switchů pro datová centra vyžadováno redundantní
napájení.

Výčet používaných / preferovaných typů

Typ switche Popis Konkrétní ady

Spine Spine switch v topologii Spine-Leaf Cisco Nexus 9332C
Cisco Nexus 9364C
Leaf/ToR Leaf switch v topologii Spine-Leaf nebo Top of Rack /
Top of Row switch Cisco Nexus 93180YC
Cisco Nexus 93240YC
Backend Lokální propojení nodů farem (HCI) Cisco Nexus 93360YC

Access Jako access switch v malých serverovnách Cisco Nexus 93180YC
Cisco C9300X

Cisco C9300X
Cisco C9300

6.4.2 Switche pro fibre channel

K již zmiňovaným požadavkům je u switchů pro datová centra vyžadováno redundantní
napájení.

Výčet používaných / preferovaných typů

Typ switche Popis Konkrétní ady

Fibre Channel Fibre Channel switche p evážně pro p ipojení síťových Cisco MDS 9124T/V
úložišť typu SAN Cisco MDS 9132T/V
Cisco MDS 9148T/V

6.4.3 Switche pro kamerové systémy

Pro kamerové systémy jsou požadovány switche s napájením PoE+ podle standardu 802.3at,
p ípadně PoE++ podle standardu 802.3bt.

Výčet používaných / preferovaných typů pro kamerové systémy

Typ switche Popis Konkrétní ady

Access Běžný PoE switch pro p ipojení kamerových systémů Cisco C9200, resp. C9200L
Cisco C9300, resp. C9300L

6.4.4 Switche pro management za ízení

Pro OOB switche v datových centrech platí mimo jiné požadavek na redundantní napájení.
V ostatních lokalitách, kde nejsou zajištěny dvě nezávislé napájecí větve, je tento požadavek
bezp edmětný.

Výčet používaných / preferovaných typů pro management za ízení

Typ switche Popis Konkrétní ady
Cisco C9200, resp. C9200L
OOB Běžný access switch s metalickými RJ45 porty pro
p ipojení MGMT portů Cisco Nexus 9348GC

OOB Velká datacentra spine-leaf

Platforma SŽ – Konektivita a síťové prost edí 13/16
6.4.5 Switche pro lokální sítě

Tyto switche pro lokální sítě musí být umístitelné v 19” racku p ímo na jeho ližiny.
Redundantní zdroj není vyžadován.

Výčet používaných / preferovaných typů pro lokální sítě

Typ switche Popis Konkrétní ady

Access Běžný access switch pro p ipojení pracovních stanic, Cisco C9200 všech variant
tiskáren atp. Cisco C9300 všech variant

End of Support Dosluhující ada, postupně se nahrazují Cisco C2960 více variant
Cisco C2950

6.5 Huby

Ethernetový hub neboli síťový rozbočovač se v prost edí SŽ nenachází a jeho použití je
zakázané.

6.6 Modemy a datová za ízení

V prost edí rozlehlé sítě SŽ se používají různé typy modemů, tedy za ízení pro p evod mezi
digitálním a analogovým rozhraním. Jde nap . o GSM modemy s protokolem LTE nebo GPRS,
DSL modemy, 2-pair / dial-up.

Výčet používaných / preferovaných modemů a datových za ízení

Výrobce Technologie Popis Konkrétní ady/modely
1088, 3200, 3088
Patton DSL BSTU4 / ULAF+
ASMi50
Albis / Siemens DSL 3202
ER75i
RAD DSL M35i
TRBxxx
Patton 2-pair
ICR-xxxx
CONEL GPRS GPRS modem, již ukončená výroba

Siemens GPRS

Teltonika 4G/LTE Průmyslové LTE routery s rozhraním RS232, RS485,
Ethernet, M-bus

Advantech 4G/LTE Průmyslové LTE routery s rozhraním RS232, RS485,
Ethernet

14/16 Platforma SŽ – Konektivita a síťové prost edí
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Integrační standardy

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 4
2 Moderní architektonické rámce .................................................................................. 4

2.1 Flexibilita ...................................................................................................... 4
2.2 Škálovatelnost ............................................................................................... 4
2.3 Bezpečnost ................................................................................................... 4
2.4 Efektivita ...................................................................................................... 4
3 Architektura integrací ............................................................................................... 5
3.1 Microservices Architecture............................................................................... 5
3.2 Event-Driven Architecture ............................................................................... 5
3.3 API-First Approach ......................................................................................... 5
3.4 Hybridní architektura...................................................................................... 5
4 Typy integrací ......................................................................................................... 5
5 Softwarová architektura Enterprise Service Bus ........................................................... 6
6 Primární integrační scénáře ....................................................................................... 6
6.1 Integrační platforma WSO2 ............................................................................. 6
6.2 SAP Business Technology Platform ................................................................... 7
6.3 Microsoft nástroje a Azure............................................................................... 7
6.4 Integrace stávajících aplikací ........................................................................... 7
7 Datové formáty ....................................................................................................... 9
8 Metody ..................................................................................................................10
9 Dokumentace integračních scénářů ...........................................................................10

2/12 Platforma SŽ – Integrační standardy
Seznam zkratek

API Komplexně definované komunikační rozhraní aplikace (Application Programming
Inteface)
CSV
ESB Jednoduchý textový souborový formát (Comma-separated values)

IoT Softwarová architektura a technologie používaná v oblasti podnikové integrace a
správy služeb (Enterprise Service Bus)
IT
ITIL Internet věcí je souborné označení pro síť fyzických zařízení, která vzájemně,
JSON centrálně nebo i s vnějším světem komunikují a mají možnost předávat data. Každé
KII z těchto zařízení je jasně identifikovatelné díky implementovanému výpočetnímu
REST/API systému, ale přesto je schopno pracovat samostatně v existující infrastruktuře sítě
SAP (Internet of Things)
SFTP
SMTP Informační technologie (Information Technology)
SOA (Information Technology Infrastructure Library)

SŽ Datový formát primárně určený pro přenos dat (JavaScript Object Notation)
XML
Kritická informační infrastruktura

Webově založené klient-server API (Representational State Transfer)

Modulární ERP systém od německé firmy SAP AG

Zabezpečený protokol pro přenos souborů. Pro zajištění šifrování využívá protokol
SSH (SSH File Transfer Protocol)
Základní síťový protokol pro přenos elektronické pošty (Simple Mail Transfer Protocol)

Architektura orientovaná na služby – jedná se o softwarovou architekturu, která se
zaměřuje na organizaci a strukturu aplikací a systémů jako soubor nezávislých a
dobře definovaných služeb (Service-Oriented Architecture)
Správa železnic, státní organizace

Standardizovaný jazyk používaný pro serializaci dat (Extensible Markup Language)

Seznam vysvětlivek

Platforma SŽ Soubor dokumentů, rozdělený na veřejnou, interní a metodickou
Platforma WSO2 část, určený pro seznámení dodavatelů se standardy a
technologiemi v ICT prostředí SŽ.

Open-source platforma pro správu služeb (ESB) a integraci aplikací
(API Management) vyvinutá společností WSO2 Inc. WSO2
poskytuje komplexní sadu nástrojů a produktů, které pomáhají
organizacím implementovat a spravovat architekturu orientovanou
na služby (SOA) a rozhraní pro programování aplikací (API) v jejich
IT infrastruktuře.

Platforma SŽ – Integrační standardy 3/12
1 Úvod

Tento dokument slouží jako příloha k základního dokumentu Platformy SŽ, který je součástí
veřejných zakázek a podrobněji rozvádí integrační standardy naší organizace. Cílem je
poskytnout jasný a konzistentní rámec pro všechny integrační aktivity. Naše cíle dále zahrnují
modernizaci a konsolidaci současných integračních mechanismů za účelem zvýšení efektivity
a snížení nákladů na údržbu. Dokument specifikuje požadavky a standardy, které musí být
dodrženy při implementaci integračních scénářů, s důrazem na bezpečnost a využití hybridních
řešení kombinujících on-premise a cloudovou infrastrukturu s ohledem na celkovou IT strategii.
Všechny aktivity musí cílit na ITIL rámec pro řízení IT služeb, neboť tímto rámcem se naše
organizace rozhodla řídit IT služby.

2 Moderní architektonické rámce

V rámci moderního IT prostředí naše organizace využívá pro nová řešení různé architektonické
rámce a principy k zajištění flexibility, škálovatelnosti a efektivního poskytování služeb. Tato
kapitola se zaměřuje na popis klíčových architektonických principů a jejich implementaci v naší
organizaci. Použití současně moderní architektury nám umožňují efektivně reagovat na měnící
se potřeby a technologické požadavky.

2.1 Flexibilita

Naše architektura umožňuje snadné přizpůsobení se měnícím se potřebám businessu. Tím, že
kombinujeme lokální a cloudové infrastruktury, jsme schopni efektivně reagovat na dynamické
požadavky a přizpůsobit naše služby v reálném čase. Hybridní řešení nám umožňují
optimalizaci výkonu a nákladů tím, že strategicky využíváme výhody obou typů prostředí. Tato
flexibilita nám dává možnost optimalizovat zdroje podle aktuálních potřeb a strategických cílů,
ale hlavně dodržování bezpečnostních kritérií.

2.2 Škálovatelnost

Díky využití mikroslužeb a škálovatelné cloudové infrastruktury můžeme dynamicky
přizpůsobovat kapacitu našich systémů podle aktuální požadavků. To zajišťuje, že naše služby
jsou vždy dostupné a výkonné, i při náhlých změnách v zatížení. Implementujeme mechanismy
automatického škálování, které umožňují plynulý růst a adaptaci bez potřeby manuálního
zásahu, což přispívá k vyšší efektivitě a spolehlivosti.

2.3 Bezpečnost

Naše integrační architektura zahrnuje robustní bezpečnostní opatření na všech úrovních.
Zajišťujeme ochranu dat a služeb pomocí pokročilých metod autentizace a autorizace, šifrování
dat a pravidelného monitorování bezpečnostních hrozeb. Primárně z pohledu Compliance
a regulace dbáme na dodržování všech relevantních bezpečnostních standardů a právních
předpisů, což zajišťuje důvěryhodnost a právní jistotu pro business partnery.

2.4 Efektivita

Využití automatizace v rámci integračních procesů nám umožňuje snížit provozní náklady
a zvýšit produktivitu. Automatizované workflow a orchestrace služeb minimalizují potřebu
manuálních zásahů a zvyšují přesnost a rychlost procesů. Tohoto stavu jsme dosáhli díky
centrálnímu řízení integrací prostřednictvím platformy ESB, ta nám umožňuje efektivně
monitorovat a spravovat všechny integrační toky, což přispívá k vyšší přehlednosti a lepší
koordinaci mezi jednotlivými systémy.

4/12 Platforma SŽ – Integrační standardy
3 Architektura integrací

V rámci naší organizace se zaměřujeme na implementaci moderní architektury integrací, která
podporuje jak on-premise, tak cloudové prostředí. Tato hybridní přístup zajišťuje flexibilitu,
škálovatelnost a bezpečnost, což jsou klíčové faktory pro úspěšné řízení IT služeb podle ITIL
principů. Cílový stav architektury je ESB.

Naše integrační architektura je postavena hlavně na následujících architekturních principech:

3.1 Microservices Architecture

Naše organizace implementuje architekturu mikroslužeb, což znamená decentralizaci
a rozdělení monolitických aplikací na menší, nezávislé služby. Tento přístup zajišťuje vysokou
flexibilitu a usnadňuje správu jednotlivých služeb. Díky mikroservisům můžeme rychleji
reagovat na změny a inovace, což nám umožňuje poskytovat kvalitnější služby našim
zákazníkům v podobě businessu.

3.2 Event-Driven Architecture

Pro lepší škálovatelnost a reaktivitu využíváme architekturu řízenou událostmi. Tento přístup
umožňuje systémům komunikovat prostřednictvím událostí, což zvyšuje jejich schopnost
rychle reagovat na provozní incidenty. Díky tomu můžeme dosahovat vyšší efektivity
a pružnosti v našich provozních procesech.

3.3 API-First Approach

Při návrhu a vývoji systémů se naše organizace řídí principem API-First. API jsou navrhována
a vyvíjena jako primární prostředek komunikace mezi systémy. Tento přístup je v souladu
s ITIL principy, které se zaměřují na poskytování hodnoty zákazníkům prostřednictvím dobře
definovaných služeb. API-First nám umožňuje dosahovat vyšší konzistence a standardizace
v naší IT infrastruktuře.

3.4 Hybridní architektura

Pro zajištění flexibility a škálovatelnosti kombinujeme on-premise a cloudová řešení. Tento
hybridní přístup nám umožňuje využívat výhod obou prostředí, což zajišťuje kontinuitu služeb
a splnění compliance požadavků. Díky hybridní architektuře můžeme optimalizovat naše IT
zdroje a lépe podporovat business v naší organizaci. Toto je obzvláště důležité z důvodu
kritické infrastruktury informací (KII), která vyžaduje vysokou míru bezpečnosti a spolehlivosti.
Hybridní přístup nám umožňuje zajistit, že klíčové systémy a data jsou chráněny a zároveň
flexibilně škálovatelné dle aktuálních potřeb.

4 Typy integrací

Pro celkové pochopení integrací je nutné zmínit úrovně integrací. Existuje totiž několik
pohledů, které následně definují oblasti soustředění a úroveň detailu. Je potřeba podotknout,
že při komplexním řešení integrací dochází k jejich vzájemnému prolínání. Zde jsou
vyjmenovány ty hlavní z nich:

• Datová integrace – Tento typ integrace se zabývá shromažďováním dat z různých
zdrojů a jejich následným poskytnutím uživatelům v jednotné a konzistentní struktuře
a formátu. Datová integrace umožňuje kombinaci dat umístěných v různých zdrojích
a poskytuje uživateli sjednocený pohled na tyto data.

• Procesní integrace – Procesní integrace má za cíl propojit aplikace z hlediska
podnikových procesů. Jakmile skončí jedna činnost, je vykonána činnost druhá. Při
dokončení prvního procesu se spustí proces další, a tím že různé procesy mohou být
realizovány odlišnými subsystémy je důležité zajistit, že tyto procesy jsou správně
a efektivně koordinovány.

Platforma SŽ – Integrační standardy 5/12
• Aplikační integrace – U aplikační integrace jde v zásadě o realizaci výměny informací
(různého charakteru) mezi různými aplikacemi. Výměna přitom může probíhat
s využitím široké škály transportních technologií – např. přes webové služby, databáze,
sdílený soubor, messaging apod.

• Systémová integrace – Systémová integrace je proces spojování různých
softwarových komponent, subsystémů, v jeden fungující celek. Cílem je, aby tento
celek pracoval co možná nejefektivněji, tedy z pohledu jednotlivých subsystémů, aby
komunikace mezi nimi probíhala podle definovaného schématu.

Každý z těchto typů integrace má své výhody a nevýhody a je důležité na základě analýz
vybrat ten vhodný typ integrace, který bude respektovat konkrétní potřeby a požadavky
jednotlivých projektů.

5 Softwarová architektura Enterprise
Service Bus

ESB je softwarová architektura pro distribuované výpočty. ESB implementuje komunikační
systém mezi vzájemně interagujícími softwarovými aplikacemi v rámci SOA. ESB je
centralizovaný, standardizovaný hub, který přijímá, transformuje a poskytuje data, aby různé
aplikace a služby napříč organizací mohly snadno komunikovat. ESB je cílový stav architektury,
která je preferovaná v naší organizaci. Vzhledem ke složitosti prostředí však je doplňován
i jinými způsoby integrací na základě výše popsaných architektur integrací.

ESB poskytuje hlavně tyto funkce:

• Transformace dat – provádí transformování zpráv do formátů, které jsou pro
příjemce zpracovatelné a srozumitelné

• Směrování zpráv – dokáže rozhodovat, kam má zprávu odeslat na základě atributů
obsažených v obsahu daných zpráv

• Mediace služeb – může poskytnout jednotné rozhraní pro více služeb
• Orchestrace – koordinuje interakce mezi službami

ESB je navržen tak, aby zjednodušil vazby a pomohl se oprostit od „Spaghetti“ architektury,
která v organizaci zatím dominuje. ESB je sada nástrojů, která posílá zprávu přímo do
konkrétní destinace mezi buď aplikací a/nebo komponentami. Ať už je to klient nebo proces,
cokoli, co je připojeno k ESB, nekomunikuje přímo mezi sebou, protože komunikují
prostřednictvím samotného ESB platformy.

6 Primární integrační scéná e

6.1 Integrační platforma

Naše organizace plánuje rozvinout integrační platformu WSO2 do podoby ESB, který bude
sloužit jako hlavní integrační páteř. WSO2 bude poskytovat následující funkcionality:

• Service Orchestration – Koordinace a řízení komunikace mezi různými službami, což
podporuje efektivní řízení provozu služeb a incidentů.

• Data Transformation – Převod a mapování datových formátů mezi různými systémy,
což umožňuje jednotné zpracování dat v rámci celé infrastruktury.

• Security Enforcement – Implementace bezpečnostních politik a autentizace, což je
klíčové pro řízení rizik a zajištění integrity služeb.

6/12 Platforma SŽ – Integrační standardy
6.1.1.1 Preferované Protokoly pro Integraci s WSO2
• REST/HTTPS – Pro aplikační a datové integrace díky své jednoduchosti a široké
podpoře, což umožňuje snadnou správu a podporu služeb.
• SOAP – Pro integrace, kde je vyžadována robustní bezpečnost a transakční podpora,
což je v souladu s potřebami řízení kritických služeb.
• MQTT – Pro event-driven integrace a IoT komunikace, které podporují rychlou reakci
na změny a incidenty.
• AMQP – Pro spolehlivý a škálovatelný messaging mezi aplikacemi, což zajišťuje
stabilní a efektivní komunikaci.

6.2 SAP Business Technology Platform

SAP BTP hraje klíčovou roli v naší integrační strategii. Specifické požadavky na integraci SAP
BTP zahrnují:

• Integration Suite – Použití SAP Integration Suite pro propojení SAP a non-SAP
systémů, což podporuje jednotnou správu a provoz služeb.

• Event Mesh – Využití SAP Event Mesh pro událostmi řízenou architekturu, což
umožňuje rychlé a efektivní řízení změn a incidentů.

• Business Process Management – Automatizace a optimalizace obchodních procesů
pomocí SAP Workflow Management, což zajišťuje efektivní poskytování služeb.

6.2.1.1 Preferované Protokoly pro Integraci s SAP BTP
• OData – Pro přístup k datům a jejich manipulaci přes standardizované API, což
podporuje transparentní správu dat.
• RFC/BAPI – Pro volání vzdálených funkcí v SAP systémech, což zajišťuje spolehlivou
integraci služeb.
• IDoc – Pro elektronickou výměnu dat mezi SAP a non-SAP systémy, což umožňuje
efektivní řízení datových toků.
• SOAP – Pro služby vyžadující vysokou úroveň bezpečnosti a transakční podporu, což
zajišťuje integritu a důvěryhodnost služeb.

6.3 Microsoft nástroje a Azure

Integrace s Microsoft technologiemi, včetně Azure, zahrnuje tyto základní komponenty:

• Azure Logic Apps – Automatizace a orchestraci pracovních toků, což podporuje
efektivní správu a provoz služeb.

• Azure API Management – Správa a bezpečné publikování API, což zajišťuje jednotný
přístup a kontrolu nad službami.

• Azure Service Bus – Spolehlivá messagingová platforma pro integraci aplikací, což
podporuje stabilní a efektivní komunikaci.

• Azure Arc – Pro správu a orchestrace zdrojů v hybridním prostředí, což umožňuje
jednotnou správu a kontrolu napříč on-premise a cloudovými systémy.

6.3.1.1 Preferované Protokoly pro Integraci s Azure
• REST/HTTPS – Pro širokou škálu aplikačních a datových integrací, což podporuje
snadnou správu a podporu služeb.
• gRPC – Pro vysoce výkonné, nízko-latentní komunikace mezi mikroservisami, což
zajišťuje rychlou a efektivní komunikaci.
• Event Grid – Pro event-driven architekturu a notifikace, což umožňuje rychlou reakci
na změny a incidenty.
• Service Bus – Pro messaging a integraci podnikových aplikací, což zajišťuje
spolehlivou komunikaci a řízení služeb.

6.4 Integrace stávajících aplikací

Mnoho aplikací, je stále ještě integrováno point-to-point, ty budou postupně převedeny do
centralizovaného integračního prostředí. Hlavní kroky zahrnují:

Platforma SŽ – Integrační standardy 7/12
• Inventarizace a Analýza – Zmapování současných integrací a identifikace klíčových
závislostí, což podporuje efektivní správu a plánování změn.

• Standardizace API – Vytvoření standardních API pro všechny aplikace, což zajišťuje
jednotný přístup a kontrolu nad službami.

• Refaktoring a Modernizace – Přepsání nebo refaktoring stávajících integrací podle
moderních standardů, což podporuje efektivní a bezpečné poskytování služeb.

Tabulka protokolů Použití Výhody Nevýhody Důvod
Protokol Preference/Nepreference
REST/HTTPS Aplikační, Jednoduchost, široká podpora, Omezená
datové škálovatelnost bezpečnost ve Preferovaný pro svou
SOAP srovnání s jinými jednoduchost a širokou
MQTT Kritické služby Vysoká úroveň bezpečnosti, protokoly podporu
AMQP transakční podpora
OData Složitost, větší Preferovaný pro kritické
režie a transakční služby
RFC/BAPI
IDoc Event-driven, Nízká režie, efektivní pro nízko- Omezená podpora Preferovaný pro IoT a
WebSocket IoT šířková pásma pro složitější event-driven
gRPC Messaging operace architekturu
FTP/SFTP Spolehlivost, škálovatelnost
Data, API Komplexita Preferovaný pro
JMS Standardizace, jednoduchý implementace spolehlivý a
SMTP SAP integrace přístup k datům škálovatelný messaging
Omezená
CORBA EDI, SAP funkčnost ve Preferovaný pro
RMI integrace srovnání s plně transparentní správu dat
funkčními API
Telnet
Efektivní volání SAP funkcí Specifické pro SAP Preferovaný pro
spolehlivou integraci
Robustní, vhodné pro velké Specifické pro SAP
objemy dat SAP, složitost
Preferovaný pro EDI a
integraci SAP

Real-time Obousměrná komunikace, nízká Omezená Preferovaný pro real-
komunikace time aplikace
latence bezpečnost

Mikroservisy Vysoký výkon, nízká latence Menší podpora ve Preferovaný pro
Jednoduchost, široká podpora srovnání s HTTP výkonné komunikace
Přenos mikroservis
souborů Zastaralost (FTP),
bezpečnostní Preferovaný (SFTP) pro
rizika (FTP) bezpečný přenos
souborů, FTP je
nepreferovaný kvůli
bezpečnostním rizikům

Messaging Spolehlivost, asynchronní Komplexita, Preferovaný pro robustní
komunikace omezená podpora messagingové potřeby

Email Široká podpora, standardní pro Zastaralost, Nepreferovaný pro
email omezená datové a aplikační
Distribuované bezpečnost integrace kvůli
aplikace Jazyková nezávislost, zastaralosti
Java aplikace robustnost
Efektivní pro Java, Komplexita, Nepreferovaný kvůli
Vzdálená jednoduchost zastaralost, velká zastaralosti a
správa režie komplexitě
Široká podpora
Omezené na Java, Nepreferovaný kvůli
bezpečnostní omezené použitelnosti
rizika mimo Java a
bezpečnostním rizikům

Velmi slabá Nepreferovaný kvůli
bezpečnost vážným bezpečnostním
(nešifrované) rizikům

8/12 Platforma SŽ – Integrační standardy
XMPP Real-time Široká podpora, rozšiřitelnost Omezená Nepreferovaný kvůli
komunikace škálovatelnost, omezené škálovatelnosti
bezpečnostní a bezpečnostním
problémy problémům

Tabulka poskytuje přehled preferovaných a nepreferovaných protokolů pro integrační
architekturu naší organizace, zdůvodňuje jejich použití a vyzdvihuje klíčové výhody
a nevýhody. Protokoly jako REST/HTTP, SOAP, MQTT, AMQP a další jsou preferovány pro svou
robustnost, flexibilitu a bezpečnost. Naopak protokoly jako FTP (nešifrované), SMTP, CORBA,
RMI, Telnet a XMPP jsou nepreferované kvůli jejich zastaralosti, bezpečnostním rizikům nebo
omezené funkčnosti.

7 Datové formáty

V rámci organizace je klíčové zajistit efektivní, bezpečnou a interoperabilní výměnu dat mezi
různými informačními systémy a platformami. Výběr vhodných datových formátů hraje zásadní
roli při dosahování těchto cílů. Datový formát určuje způsob, jakým jsou informace
strukturovány a jakým způsobem mohou být přenášeny a zpracovávány mezi různými
systémy. V této části se zaměříme na nejčastěji používané datové formáty, jejich typické
použití, výhody, nevýhody a důvody, proč jsou preferovány nebo nepreferovány v naší
organizaci, se zvláštním důrazem na bezpečnostní aspekty. Kromě toho uvádíme níže v tabulce
i formáty, které jsou z bezpečnostních nebo jiných důvodů nevhodné a v podstatě zakázané.

Tabulka datových formátů

Formát Použití Výhody Nevýhody Důvod
Preference/Nepreference
REST/HTTPS Aplikační, Jednoduchost, široká podpora, Omezená
datové škálovatelnost bezpečnost ve Preferovaný pro svou
srovnání s jinými jednoduchost a širokou
protokoly podporu

JSON (JavaScript Webové API, Jednoduchost, čitelnost, Není vhodný pro Preferován pro svou
Object Notation) konfigurace, podpora v moderních složité datové jednoduchost a širokou
mobilní programovacích jazycích struktury, bez podporu, bezpečnostní
XML (eXtensible aplikace schématu riziko lze mitigovat
Markup Language) Flexibilita, podporuje složité validací a šifrováním
Webové datové struktury, možnost Verbóznost, vyšší
CSV (Comma- služby, validace pomocí XSD nároky na výkon Preferován pro
Separated Values) dokumenty, komplexní
datová Jednoduchost, široká podpora v Omezená strukturovaná data,
YAML (YAML Ain't výměna mezi aplikacích strukturovanost, bezpečnost lze zlepšit
Markup Language) systémy citlivost na pomocí šifrování a
Čitelnost, jednoduchost, formátování podpisů
EDIFACT (Electronic Export/import podpora komplexních datových
Data Interchange for dat, tabulkové struktur Méně robustní než Preferován pro
Administration, aplikace XML, obtížnější jednoduchou tabulkovou
Commerce and Standardizace, spolehlivost, validace data, nepreferován pro
Transport) Konfigurace, široká akceptace v EDI složité struktury,
data pro Složitost, náročná bezpečnostní riziko při
Plain Text DevOps Jednoduchost, univerzální implementace přenosu nešifrovaných
(neformátovaný nástroje čitelnost dat
text) Žádná
EDI v strukturovanost, Preferován pro
obchodních a vysoké riziko chyb konfigurace a čitelnost,
státních nepreferován pro
systémech kritická data kvůli
chybějícímu schématu a
Základní validaci
komunikace,
logy Preferován pro
standardizované
obchodní procesy,
bezpečnostní riziko lze
řešit šifrováním EDI
zpráv

Zakázán pro přenos
citlivých dat, protože
postrádá jakoukoliv
formu zabezpečení a
struktury

Platforma SŽ – Integrační standardy 9/12
HTML (HyperText Webové Flexibilita, široká podpora v Neefektivní pro Zakázán pro datovou
Markup Language) stránky, obsah prohlížečích strukturovaná výměnu kvůli
dokumentů data, riziko XSS bezpečnostním rizikům
útoků a nevhodnosti pro
Proprietární Formáty Specifické Optimalizace pro konkrétní strukturovaná data
(např. specifické aplikace software Omezená
formáty určitého interoperabilita, Zakázány kvůli
softwaru) závislost na uzamčení na jednoho
konkrétním dodavatele a nízké
dodavateli interoperabilitě, což
zvyšuje riziko vendor
lock-in

Tabulka níže poskytuje přehled jednotlivých datových formátů, jejich specifické použití, výhody
a nevýhody, a důvody preference či nepreference v kontextu naší organizace.

8 Metody

Metody integrací se liší v závislosti na povaze dat, četnosti výměny, úrovni transformace dat
a typu architektury integrace dat. Metody primárně využívané naší organizací lze rozdělit na
tyto čtyři základní:

• ETL - extract, transform, load – je běžnou metodou pro dávkové/hromadné
zpracování velkých objemů strukturovaných nebo částečně strukturovaných dat

• ELT extract, load, transform – je podobná ETL, ale transformace se provádí až po
načtení do cílového místa určení

• CDC - change data capture – zachycuje a přenáší pouze změny ve zdrojových
datech a je užitečná pro integraci v reálném čase nebo téměř v reálném čase

• Virtualizace dat – vytváří virtuální vrstvu, která integruje data z různých zdrojů, aniž
by je fyzicky přesouvala nebo ukládala, tato metoda poskytuje jednotný pohled na
data a je vhodná pro komplexní a heterogenní datová prostředí

9 Dokumentace integračních scéná ů

V naší organizaci je dokumentace integračních scénářů klíčovým nástrojem pro zajištění
přehlednosti a konzistence v rámci všech integračních aktivit. Pro tento účel používáme
standardizovaný dokument s názvem Integrační specifikace, který obsahuje veškeré potřebné
informace k pochopení, implementaci a konfiguraci konkrétního integračního scénáře. Tento
dokument slouží jako detailní blueprint pro všechny zúčastněné strany.

9.1.1.1 Integrační specifikace zahrnuje primárně:
• Stručný popis integračního scénáře, jeho účel a přínosy.
• Název integračního scénáře přidělený dle katalogu Integračních scénářů a zavedené
jmenné konvence, což zajišťuje konzistenci a snadnou identifikaci.
• Popis technologií, protokolů a datových formátů použitých v integraci.
• Detailní popis procesních a datových toků, které jsou součástí integračního scénáře.
• Specifikace bezpečnostních opatření, jako je šifrování, autentizace a autorizace.

Kromě textového popisu využíváme modelovací jazyky, jako je Archimate v poslední platné
verzi, pro vizualizaci integračních scénářů. Tyto modely poskytují grafický přehled
o architektuře, komponentách a vztazích mezi nimi, což usnadňuje pochopení komplexních
integrací.

9.1.1.2 Další používané modelovací jazyky zahrnují:

• UML (Unified Modeling Language) - Pro vytváření diagramů tříd, sekvencí a aktivit,
které detailně popisují jednotlivé části integračního scénáře.

10/12 Platforma SŽ – Integrační standardy
• BPMN (Business Process Model and Notation) - Pro modelování procesů organizace
a jejich interakcí v rámci integračních scénářů.

Integrace jsou v naší organizaci také popsány v katalogu Integračních scénářů, který obsahuje
všechny aktuální a historické integrační scénáře s příslušnými metadaty. Tento katalog je
pravidelně aktualizován a slouží jako centrální zdroj informací pro všechny týmy zapojené do
integračních projektů.

Dokumentace integračních scénářů je důkladně verifikována a validována, aby byla zajištěna
její přesnost a úplnost. To zahrnuje revize od technických odborníků, bezpečnostních
specialistů a dalších relevantních stakeholderů. Tento proces zajišťuje, že všechny integrační
aktivity jsou prováděny konzistentně, efektivně a bezpečně.

10 Řízení integračních scéná ů

Jakékoliv nové Integrační scénáře, či změny Integračních scénářů musí projít skrze
Architecture Board nebo Change managment a být posouzeny v širším kontextu. Skrze jaký
proces bude integrační scénář posuzován určí matice, která zahrnuje posouzení složitosti
změny a její dopady. Integrační scénář následně bude nově zaevidován do katalogu
Integračních scénářů nebo proběhne aktualizace u již existujícího.

Platforma SŽ – Integrační standardy 11/12
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Komunikační
standardy

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 4
2 Komunikační služby ................................................................................................. 4
3 SMS brána .............................................................................................................. 4
4 Emailová komunikace............................................................................................... 4

4.1 Z uživatelsko-aplikační sítě ............................................................................. 4
4.2 Z technologických datových sítí ....................................................................... 4
4.3 Z externích sítí Správy železnic ........................................................................ 4
4.4 Mimo sítě Správy železnic ............................................................................... 5

2/6 Platforma SŽ – Komunikační standardy
Seznam zkratek

API Komplexně definované komunikační rozhraní aplikace (Application Programming
Inteface)
APN
Virtuální vyhrazená část mobilní datové sítě. Nejedná se tak o mobilní p ipojení
CPS k Internetu, ale k lokální síti daného zákazníka mobilního operátora.
ICT
Centrální poštovní systém Správy železnic
O27
SAP Informační a komunikační technologie (Information and Communication
SMS Technology)
SMTP
Odbor komunikace G SŽ
SŽ
SŽT Modulární ERP systém od německé firmy SAP AG
UAS Krátká textová zpráva (Short Message Service)
Základní síťový protokol pro p enos elektronické pošty (Simple Mail Transfer
VPN Protocol)
Správa železnic, státní organizace

Správa železničních informačních technologií

Logická uživatelsko-aplikační síť SŽ, zahrnuje VRF v MPLS sítích a lokální VLAN,
běžně se nazývá také „Intranet SŽ“

Virtuální privátní síť (Virtual Private Network)

Seznam vysvětlivek

Platforma SŽ Soubor dokumentů, rozdělený na ve ejnou, interní a metodickou část, určený
pro seznámení dodavatelů se standardy a technologiemi v ICT prost edí SŽ.

Platforma SŽ – Komunikační standardy 3/6
1 Úvod

Cílem této p ílohy Platformy SŽ je popsat podporovaných komunikačních služeb a technologií,
které lze v rámci Platformy SŽ využít a současně definuje služby, za ízení a technologie, které
není možné z důvodu duplicity v rámci navrhovaných ešení dodávat do ICT prost edí Správy
železnic.

2 Komunikační služby

Platforma Správy železnic definuje základní komunikační služby, které lze v rámci aplikací
a informačních systémů využívat primárně technické notifikace. Použití k jiným účelům
(nap íklad pro marketingové účely nebo komunikaci s ve ejností) je možná jen po p edchozím
schválení ze strany Správy železnic, a to minimálně ze strany SŽT a O27.

3 SMS brána

SMS je negarantovaná služba telekomunikačních operátorů. Garantován není čas doručení ani
samotné doručení SMS zprávy vůbec. SMS brána je aplikace instalovaná v prost edí SŽ
napojená p ímo na telekomunikačního operátora. Nejedná se tedy o použití koncového za ízení
p ihlášeného do ve ejné mobilní telefonní sítě.

SMS brána umožňuje obousměrnou komunikaci, to znamená odesílání SMS zpráv definovaným
p íjemcům a p íjem odpovědí na odeslané zprávy. Stejně tak umožňuje evidenci (logování)
doručenek zpráv. Komunikaci se SMS bránou zajišťuje jednoduché API rozhraní popsané
v implementačním manuálu.

Službu SMS brány lze využít jen pro aplikace a informační systémy umístěné v ICT prost edí
Správy železnic a to pouze v UAS.

4 Emailová komunikace

Pro navrhovaná ešení, pokud je součástí i emailová komunikace, poskytuje službu emailového
serveru pro odchozí poštu. je pro aplikace odpůrné služby standardně poskytované k využití
pro dodávaná ICT ešení.

4.1 Z uživatelsko-aplikační sítě

Z UAS je služba odesílání emailových zpráv zprost edkována takto:

• Nešifrovaně p es CPS a jeho Open-Relay SMTP servery umístěné ve vnit ní síti
• Šifrovaně p es služby MS Exchange

4.2 Z technologických datových sítí

Z technologických datových sítí není v současné době služba odesílání elektronické pošty
podporováno.

4.3 Z externích sítí Správy železnic

Z externích sítí a p ipojení Správy železnic (VPN a APN) není služba odesílání emailových zpráv
dostupná.

4/6 Platforma SŽ – Komunikační standardy
4.4 Mimo sítě Správy železnic

Odesílání emailové komunikace z vnějších sítí mimo perimetr Správy železnic (nap íklad SAP
Cloud, MS Azure atp.) není v současné době možné.

Pro tuto službu je nutné využít lokálních SMTP služeb s omezením, že z technických
a bezpečnostních důvodů nelze takto odesílat emaily z domén Správy železnic.

Platforma SŽ – Komunikační standardy 5/6
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Standardy zálohování
a disaster recovery

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 4
2 Služby zálohování .................................................................................................... 4
3 ešení Disaster recovery .......................................................................................... 4

2/6 Platforma SŽ – Standardy zálohování a disaster recovery
Seznam zkratek

DB Databázová aplikace (Database Engine)
DR
IBM Plán obnovy po havárii, součást kontinuity IT služeb (Disaster Recovery)
ICT
LTO Americká technologická společnost (International Business Machines)
MSSQL
OS Informační a komunikační technologie (Information and Communication
SQL Technology)

SŽ Otevřený formát magnetické pásky určené pro záznam velkých objemů dat (Linear
TSM Tape Open)
UAS
Databázový server od firmy Microsoft (Microsoft SQL Server)

Operační systém (Operating System)

Standardní jazyk pro manipulaci s relačními databázemi. SQL umožňuje ukládat,
manipulovat a vyhledávat data v relačních databázích. SQL je založeno na dotazech
(q ueries) na data v databázích. Dotazy lze pak definovat a modifikovat strukturu
databází, vytvářet a upravovat tabulky, indexy a další prvky, vkládat a aktualizovat
data, mazat data a další operace. SQL je nezávislý na platformě, což znamená, že
může být použit na různých operačních systémech a s různými databázovými
systémy, avšak každá databázová platforma může mít různé změny v syntaxi
(Structured Query Language)

Správa železnic, státní organizace

Nástroj pro zálohování, v současné době již nese název IBM Spectrum Protect
(Tivoli Storage Manager)

Logická uživatelsko-aplikační síť SŽ, zahrnuje VRF v MPLS sítích a lokální VLAN,
běžně se nazývá také „Intranet SŽ“

Seznam vysvětlivek

Platforma SŽ Soubor dokumentů, rozdělený na veřejnou, interní a metodickou část, určený
pro seznámení dodavatelů se standardy a technologiemi v ICT prostředí SŽ.

Platforma SŽ – Standardy zálohování a disaster recovery 3/6
1 Úvod

Cílem této části Platformy SŽ je popis podporovaných služeb, technologií, a architektonických
principů v oblasti zálohování a disaster recovery v ICT prostředí Správy železnic.

2 Služby zálohování

Služba zálohování ICT prostředí Správy železnic je zajištěna technologií IBM Spectrum Protect
(dříve známý jako TSM). Jedná se o komplexní řešení pro fyzické fileservery, virtualizovaná
prostředí a širokou škálu aplikací. IBM Spectrum Protect zálohuje data především s využitím
technologie VMware Snapshot. Služba zálohování je dostupná v současné době jen v UAS.

Služba zálohování umožňuje 3 základní typy zálohování:

• Snapshot disku pro dosažení rychlé obnovy celého OS v Crash Consistent stavu včetně
aplikační konfigurace. Zpravidla je takto zálohován pouze systémový oddíl
virtualizovaného serveru. Záloha probíhá jednou denně a retence je nastavena na 30
posledních verzí.

• Záloha datových svazků připojených k jednotlivým serverům, pro dosažení maximální
možné odolnosti proti náhodnému smazání či poškození apod. Záloha probíhá jednou
denně, kdy se uchovává 90 posledních verzí souborů a poslední smazaná verze
souboru je uchovávána 365 dní.

• Zálohy databází Oracle nebo MSSQL pomocí agentů. Záloha probíhá dvakrát denně.
Přes den jsou zálohovány transakční logy databází, v noci pak vlastní databáze.
Retence je nastavena na 60 posledních verzí.

Zálohy jsou řešeny lokálním backup serverem u každé virtualizační farmy, odkud jsou poté
přenášeny do DR lokality a v rámci řešení offline záloh (pro další zvýšení odolnosti proti ztrátě
dat) jsou zálohy dále ukládány na LTO pásky v páskové knihovně umístěné v DR lokalitě.

3 Řešení Disaster recovery

V rámci UAS byla jako DR lokalita určen objekt Praha U2, kam jsou pravidelně přenášeny
zálohy ze všech lokálních backup serverů.

Všechny zálohy jsou pravidelně testovány a veškeré offline zálohy uložené na LTO páskách
jsou pravidelně převáženy do zabezpečeného prostoru (do trezoru v jiné budově).

4/6 Platforma SŽ – Standardy zálohování a disaster recovery
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Platforma SŽ
Cloudové prostředí

Červen 2024
Obsah

1 Úvod ...................................................................................................................... 5
2 Cloudové prostředí................................................................................................... 5

2.1 Microsoft Entra ID .......................................................................................... 5
2.2 Služby M365 ................................................................................................. 5
3 Cloudové služby ...................................................................................................... 5
3.1 Služba ověření proti Microsoft Entra ID ............................................................. 5
3.2 Integrace s M365 ........................................................................................... 5

2/6 Platforma SŽ – Cloudové prostředí
Seznam zkratek

AAD Služba AD provozovaná v cloudovém prostředí MS Azure. Nový název služby je
AD „MS EntraID“ (Azure Active Directory)

AWS Rozšiřitelná a škálovatelná adresářová služba, která umožňuje efektivně uspořádat
DNS síťové prostředky. Kromě informací o objektech v počítačové síti (uživatelské účty,
ERP počítače, tiskárny) umožňuje používat stromovou strukturu objektů, nastavovat
globálně systémové politiky, instalovat programy na počítače nebo aplikovat
IaaS kritické aktualizace v celé organizační struktuře. Má úzkou vazbu na DNS (Active
Directory)
ICT
IP Cloudové prostředí firmy Amazon (Amazon Web Services)
IT
M365 Distribuovaný hierarchický jmenný systém používaný v síti Internet. Překládá názvy
MS domén na číselné IP adresy a zpět, obsahuje informace o tom, které stroje
PaaS poskytují příslušnou službu (Domain Name System)

SaaS Informační systém pro řízení podniku, který integruje různé oblasti podnikání, jako
je například finanční řízení, řízení zásob, výroby, prodeje, nákupu a personálního
SAP řízení. Cílem je poskytovat podnikovým uživatelům přehled o celkových aktivitách
SSO a umožňovat efektivní a koordinované řízení všech procesů v rámci podniku
SW (Enterprise Resource Planning)
SŽ
SŽT Typ cloudové služby, který poskytuje zákazníkům základní IT infrastrukturu jako
službu, včetně serverů, úložiště, sítě a virtuálních počítačů. Tyto služby se často
poskytují prostřednictvím Internetu a umožňují zákazníkům snadno a rychle
využívat IT infrastrukturu bez nutnosti jejího nákupu, instalace a správy. Mezi
nejznámější poskytovatele IaaS patří Amazon Web Services, Microsoft Azure
a Google Cloud Platform (Infrastructure as a Service)

Informační a komunikační technologie (Information and Communication
Technology)

Jeden ze základních komunikačních protokolů používaných v počítačových sítích
(Internet Protocol)

Informační technologie (Information Technology)

Globální označení služeb společnosti Microsoft, umožňující licencování jejich
produktů a provoz aplikací, a to ať už jako on-premise řešení, či v cloudovém
prostředí (Microsoft 365)

Microsoft Corporation, americký výrobce především SW a provozovatel cloudového
prostředí MS Azure

Typ cloudové služby, která poskytuje vývojářům a IT týmům platformu pro vývoj,
nasazení a správu aplikací bez nutnosti starat se o správu hardwaru a
infrastruktury. Poskytovatelé PaaS nabízejí vývojové nástroje, databáze, síťové
služby a další nástroje jako služby, což umožňuje vývojářům se soustředit pouze
na vývoj aplikace (Platform as a Service)

Model poskytování software, kdy je software hostován v cloudovém prostředí
a poskytován uživatelům přes Internet. Tyto služby jsou poskytovány vývojáři
software jako služby a účtovány jsou za používání (pay-as-you-go). To umožňuje
uživatelům využívat software bez nutnosti investovat do hardware a IT
infrastruktury (Software as a Service)

Modulární ERP systém od německé firmy SAP AG

Metoda jednotného přihlášení (Single Sign-On)

Software je sada všech počítačových programů používaných v počítači, které
provádějí nějakou činnost

Správa železnic, státní organizace

Správa železničních informačních technologií

Platforma SŽ – Cloudové prostředí 3/6
Seznam vysvětlivek

MS Azure Cloudové prostředí firmy Microsoft.
MS EntraID
Platforma SŽ Služba AD provozovaná v cloudovém prostředí MS Azure.
Soubor dokumentů, rozdělený na veřejnou, interní a metodickou část,
Tenant určený pro seznámení dodavatelů s ICT prostředím SŽ a současně
s používanými standardy a technologiemi.

Dedikovaný virtuální prostor v cloudovém prostředí MS Azure

4/6 Platforma SŽ – Cloudové prostředí
1 Úvod

Cílem této části Platformy SŽ je popis podporovaných cloudových služeb, technologií,
a architektonických principů v rámci tenantu provozovaného Správou železnic v cloudovém
prostředí.

Důvodem je zajistit ve fázích přípravy poptávky, návrhu ICT řešení a realizace dodávky
kompatibilitu se stávajícím cloudovým prostředím Správy železnic a umožnit využití pro
aplikace, které splňují podmínky pro umístění v cloudovém prostředí.

2 Cloudové prostředí

U aplikací a informačních systémů, kde je to z technických a bezpečnostních důvodů možné,
adoptuje Správa železnic moderní technologie včetně cloudového prostředí. S ohledem
na vysoké zastoupení kritické informační infrastruktury v portfoliu Správy železnic je tento
proces řízen přísnou metodikou.

V současnosti využívá Správa železnic cloudová prostředí na platformách Microsoft Azure,
Amazon AWS, SAP HANA Cloud a Oracle Cloud Infrastructure, která podporují různé typy
cloudových služeb:

• IaaS – infrastruktura jako služba
• PaaS – platforma jako služba
• SaaS – software jako služba

V rámci Platformy SŽ pak nabízí výhradně SaaS na platformě MS Azure, jelikož ostatní
cloudová prostředí jsou v případě SŽ úzce svázána s konkrétními informačními systémy.

2.1 Microsoft Entra ID

Správa železnic provozuje ve svém ICT prostředí službu Active Directory a spolu s příchodem
cloudového prostředí ho rozšířila i tam, dříve pod názvem Azure Active Directory, dnes
Microsoft Entra ID.

2.2 Služby M365

Správa železnic využívá velkou část portfolia SaaS služeb poskytovaných na platformě
MS Azure pod názvem M365.

3 Cloudové služby

V rámci svého v současnosti používaného cloudového prostředí na platformě Microsoft Azure
jsou Platformou SŽ poskytovány následující služby.

3.1 Služba ověření proti Microsoft Entra ID

Zejména u aplikací jejichž uživatelé se pohybují mimo interní sítě Správy železnic je k dispozici
služba Microsoft Entra ID. Ověřování proti Microsoft Entra ID přináší vyšší bezpečnost a pohodlí
uživatelů i pomocí jednotného přihlašování (SSO).

3.2 Integrace s M365

Pokud u informačního systému či aplikace předpokládá Dodavatel jakoukoli integraci
s aplikacemi z rodiny M365, je nutné využít tenant Správy železnic.

Platforma SŽ – Cloudové prostředí 5/6
Správa železnic, státní organizace
Správa železniční telematiky
Dlážděná 1003/7
110 00 Praha 1
© 2024
Datum tisku
2024-10-01

spravazeleznic.cz
Příloha č. 4 Smlouvy

Poddodavatelé

Poskytovatel poskytuje Objednateli předmět plnění dle Smlouvy sám.

1/1 Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1
IČO: 709 94 234 DIČ: CZ 709 94 234
zapsána v obchodním rejstříku vedeném Městským www.spravazeleznic.cz
soudem v Praze, spisová značka A 48384
Příloha č. 5 Smlouvy

Zvláštní obchodní podmínky pro Zakázky
v oblasti ICT

OBSAH

1. VÝKLAD POJMŮ................................................................................................................................................ 2
2. DOBA A MÍSTO PLNĚNÍ .................................................................................................................................... 8
3. PRÁVA A POVINNOSTI OBOU STRAN................................................................................................................ 8
4. POVINNOSTI DODAVATELE .............................................................................................................................. 9
5. POVINNOSTI OBJEDNATELE............................................................................................................................ 10
6. LICENČNÍ UJEDNÁNÍ ....................................................................................................................................... 10
7. ZDROJOVÝ KÓD A DOKUMENTACE................................................................................................................. 14
8. AKCEPTAČNÍ ŘÍZENÍ........................................................................................................................................ 15
9. ŠKOLENÍ ......................................................................................................................................................... 18
10. HELPDESK....................................................................................................................................................... 18
11. NAHLÁŠENÍ INCIDENTU .................................................................................................................................. 19
12. SERVISNÍ MODELY .......................................................................................................................................... 20
13. ÚČAST PODDODAVATELŮ .............................................................................................................................. 21
14. REALIZAČNÍ TÝM ............................................................................................................................................ 22
15. KOMUNIKACE STRAN ..................................................................................................................................... 22
16. NÁHRADA ŠKODY A SMLUVNÍ POKUTY .......................................................................................................... 23
17. ZÁRUKA ZA JAKOST A PRÁVA Z VADNÉHO PLNĚNÍ ......................................................................................... 24
18. UKONČENÍ SMLUVNÍHO VZTAHU ................................................................................................................... 26
19. ZMĚNY SMLOUVY A ZMĚNOVÉ ŘÍZENÍ ........................................................................................................... 27
20. KYBERNETICKÁ BEZPEČNOST.......................................................................................................................... 27
21. OCHRANA OSOBNÍCH ÚDAJŮ ......................................................................................................................... 31
22. OCHRANA DŮVĚRNÝCH INFORMACÍ .............................................................................................................. 33

1/33 Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1
zapsána v obchodním rejstříku vedeném Městským soudem v IČ: 709 94 234 DIČ: CZ 709 94 234
Praze, spisová značka A 48384 www.spravazeleznic.cz
1. VÝKLAD POJMŮ
1.1.
1.2. Akceptační kritéria představují podmínku anebo vlastnost výstupu provádění Plnění dle
Smlouvy, která musí být splněna, aby bylo Plnění dle Smlouvy provedeno, přičemž Akceptační
1.3. kritéria jsou uvedena v Příloze Smlouvy, která obsahuje specifikaci Plnění (dále jen „Specifikace
1.4. Plnění“).
1.5.
1.6. Akceptační protokol je protokol, který jsou zavázáni podepsat Objednatel i Dodavatel po
1.7. provedení všech nezbytných činností v rámci Akceptačního řízení, potvrzující provedení výstupu
provádění Plnění anebo výsledek Testů výstupů provádění Plnění. Protokol je připravený ze strany
1.8. Dodavatele a následně upravený a vyplněný Objednatelem. Akceptační protokol obsahuje:
1.9.
1.10. a. Specifikaci provedeného Plnění;

b. Akceptační kritéria;

c. informace o průběhu Testů, jsou-li prováděny;

d. další informace a dokumenty nezbytné pro provedení Akceptačního řízení provedeného

Plnění.

Akceptační řízení je postupné provedení akceptačních procesů a podepsání Akceptačního/ch
protokolu/ů pro Plnění dle Smlouvy.

Aktualizace je dílčí změna verze Softwaru, zpravidla odstraňující zranitelnosti či drobné
nedostatky Softwaru většinou neprojevující se navenek uživatelům, v IT obvykle označovaná jako
„patch“ nebo „security update“ (v rámci IT se také často označuje jako změna třetí číslice v čísle
verze Softwaru, tedy např. 4.1.1. na 4.1.2.). Aktualizace představuje takovou změnu Softwaru,
která není Modernizací ani Zásadní modernizací.

Autorské dílo znamená dílo ve smyslu § 2 Autorského zákona; zejména nikoliv však výlučně
Software, Databáze a jakékoliv výstupy předávané Objednateli na základě Smlouvy, které splňují
podmínky stanovené v § 2 Autorského zákona.

Autorský zákon znamená zákon č. 121/2000 Sb., o právu autorském, o právech souvisejících s
právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů.

Cena je celková cena za Plnění bez DPH dle Smlouvy. V případě:

a. Smlouvy na dobu neurčitou, jejímž předmětem jsou výhradně pravidelně se opakující či

trvající služby či činnosti, se cenou Plnění bez DPH rozumí cena bez DPH za 12 měsíců

poskytování takových služeb či činností.

b. Smlouvy na dobu neurčitou, součástí jejíhož předmětu jsou mj. pravidelně se opakující či

trvající služby či činnosti, které je Dodavatel povinen poskytovat na dobu neurčitou, se

cenou Plnění bez DPH rozumí souhrn cen bez DPH ostatních částí Předmětu Smlouvy a

ceny bez DPH za 12 měsíců poskytování takových služeb či činností.

c. Smlouvy, která je rámcovou dohodou, se cenou za Plnění bez DPH této Smlouvy rozumí

limit stanovený v této Smlouvě jako maximální souhrnná hodnota bez DPH všech dílčích

smluv uzavřených na základě této Smlouvy.

d. Smlouvy, která je zčásti rámcovou dohodou, se cenou za Plnění bez DPH této Smlouvy

rozumí souhrn cen bez DPH ostatních části Předmětu Smlouvy a limitu stanoveného v této

Smlouvě jako maximální souhrnná hodnota bez DPH všech dílčích smluv uzavřených na

základě této Smlouvy.

Čas nahlášení Incidentu představuje časový údaj, vyjadřující datum a čas, kdy byl Incident
nahlášen Dodavateli způsobem stanoveným ve Smlouvě a ZOP, tj. vytvořením ticketu
v Helpdesku, vytěžením e-mailu z e-mailového serveru Objednatele a jeho vložením do Helpdesku
jako ticketu anebo ukončením telefonátu.

Data jsou jakékoliv údaje či informace vznikající v souvislosti s Plněním dle Smlouvy.

Databáze znamená databázi splňující požadavky na Autorská díla, databázi ve smyslu § 88
Autorského zákona a jakoukoliv jinou Autorským zákonem neupravenou databázi.

2/33
1.11. Doba vyřešení je pro každou kategorii Incidentů uvedena ve Smlouvě a ZOP a znamená rozdíl
mezi časem nahlášení Incidentu a dodáním řešení. Do Doby vyřešení Incidentu se nezapočítává
1.12. doba, po kterou nemůže Dodavatel řešit Incident z důvodu:
1.13.
1.14. a. neobdržení podkladů a informací vyžádaných Dodavatelem, které jsou nezbytně nutné pro

1.15. lokalizaci nebo replikaci Incidentu, od Objednatele;

1.16. b. řešení Incidentu u třetí osoby (vyjma Poddodavatele), jejíž součinnost je dle Smlouvy

1.17. povinen zajistit Objednatel (např. poskytovatele služeb podpory IT prostředí Objednatele
1.18.
1.19. anebo systémů, na které je Software napojen);
1.20.
1.21. c. neposkytnutí jiné nezbytně nutné součinnosti Objednatele vyžádané Dodavatelem
1.22.
1.23. v souladu s těmito ZOP či Smlouvou a souvisejícími přílohami.
1.24.
Doba zpracování či Reakční doba je doba, ve které Dodavatel musí reagovat prostředkem
odpovídajícím způsobu nahlášení Incidentu či Požadavku o přijetí takového nahlášení a o zahájení
činností směřujících k vyřešení Incidentu či Požadavku.

Dodavatel označuje rovněž Poskytovatele, Zhotovitele či Prodávajícího v závislosti na typu
uzavřené Smlouvy.

Dokumentace znamená část specifikace Předmětu Smlouvy, která představuje jednotlivé
dokumenty popisující Předmět Smlouvy a zacházení s ním, jako jsou uživatelská dokumentace,
administrátorská dokumentace, bezpečnostní dokumentace, a také jakoukoliv jinou dokumentaci
vytvářenou anebo poskytovanou Dodavatelem v rámci provádění Plnění. Dokumentace musí být
vždy vyhotovena a předána Objednateli v elektronické podobě (pokud je vyhotovována v listinné
podobě, pak Dodavatel předá Objednateli elektronickou kopii takové Dokumentace).

Dostupnost znamená stav Software či Hardware, v průběhu kterého je, anebo by v případě
poskytování řádné a včasné součinnosti ze strany Objednatele za podmínek dle Smlouvy byl,
možný řádný provoz Softwaru či Hardware v celém jeho rozsahu, přičemž Software se považuje
za Dostupný, je-li přístupný a použitelný pro všechny uživatele Softwaru ve sjednaném rozsahu
minimálně dle příslušného Servisního modelu dle ZOP.

Důvěrné informace znamenají informace, které jsou zpracovávány, ukládány nebo poskytovány
v IT prostředí Objednatele, včetně Dat Objednatele, veškeré údaje a informace související s těmito
informacemi, s technickým vybavením, komunikačními prostředky a programovým vybavením IT
prostředí Objednatele a s objekty, ve kterých jsou tyto systémy umístěny, zaměstnanci nebo
dodavateli podílejícími se na provozu, rozvoji, správě nebo bezpečnosti IT prostředí Objednatele.
Mezi Důvěrné informace nepatří informace, které jsou veřejně přístupné.

FOSS licence znamená Free Open Source Software licence.

GDPR znamená nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 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ů).

GUI znamená grafické uživatelské rozhraní.

Hands-on se rozumí školení vymezené v rámci Smlouvy či jejích příloh (je-li takové), zpravidla
jde o školení, jehož součástí je komentované provedení části Plnění za účasti zástupců Objednatele

Hardware znamená veškeré hmotné součásti počítačových systémů a veškeré související
vybavení hmotné povahy spolu se vším příslušenstvím, a včetně veškeré související dokumentace.

Helpdesk je Software provozovaný Dodavatelem nebo Objednatelem sloužící ke komunikaci
Stran v průběhu provádění Plnění dle Smlouvy a zároveň bude sloužit jako kontaktní místo
Dodavatele pro nahlašování Incidentů a Požadavků, vznášení dotazů k Plnění, získávání odpovědí
ve vztahu k Plnění a další zaznamenávání průběhu provádění Plnění dle Smlouvy.

Informační či komunikační systém znamená informační či komunikační systém kritické
informační infrastruktury Objednatele ve smyslu § 2 b) ZKB nebo jiný informační či komunikační
systém, na který se vztahuje ZKB.

Incident představuje neplánované přerušení fungování Předmětu Smlouvy, jakékoliv jeho části
anebo Plnění dle Smlouvy, omezení kvality fungování Předmětu Smlouvy a souvisejícího Plnění,
anebo jakoukoliv prokazatelnou nefunkčnost Předmětu Smlouvy a souvisejícího Plnění. Incident

3/33
1.25. se projevuje zejména selháním oproti funkčnosti a funkcionalitě specifikované v Příloze Smlouvy
1.26. Specifikace Plnění, anebo obvyklé pro Předmět Smlouvy. Vada je vždy Incidentem a jde tak o
1.27. podmnožinu pojmu Incident. Za dobu trvání Incidentu se považuje doba od Času nahlášení
1.28. Incidentu Ohlašovatelem do vyřešení Incidentu, které bude Ohlašovatelem nebo jeho nadřízeným
1.29. uživatelem potvrzeno vhodným způsobem v Helpdesku, byl-li Incident vyřešen.

1.30. Kategorizace Incidentů dle důležitosti, zohledňující naléhavost a dopad Incidentu:
1.31.
1.32. A) Vysoká – ohrožení kritických procesů a činností na straně Objednatele
1.33.
1.34. B) Střední – Zásadní vliv na důležité procesy a činnosti Objednatele
1.35.
C) Nízká – standardní řešení v efektivním režimu
1.36.
1.37. Instalace znamená provedení veškerých činností nezbytných ke zprovoznění Hardwaru nebo
1.38. Softwaru vč. jeho Aktualizací, Modernizací či Zásadních modernizací poskytnutých v rámci Plnění
dle Smlouvy v IT prostředí Objednatele, a to na platformě určené Objednatelem.

ISDS znamená informační systém datových schránek ve smyslu zákona č. 300/2008 Sb., o
elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů.

Interní předpisy znamenají interní předpisy Objednatele, jejichž seznam včetně znění daných
interních předpisů, jsou-li relevantní z hlediska Plnění, je uveden v Příloze Smlouvy Seznam
interních předpisů.

Insolvenční zákon znamená zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení
(insolvenční zákon), ve znění pozdějších předpisů.

IT prostředí Objednatele znamená veškerý Hardware ve vlastnictví Objednatele a Software, ve
vztahu k němuž je Objednatel nositelem potřebných oprávnění, nebo Hardware a Software
využívaný Objednatelem na základě jiného právního titulu než Smlouvy. Jedná se zejména o
servery, diskové pole a stanice, aplikace třetích osob, pasivní a aktivní datová infrastruktura
(kabeláže, switche, VPN linky apod.). Podrobná specifikace IT prostředí Objednatele je uvedena
v Příloze Smlouvy Platforma Správy železnic a v Příloze Smlouvy Specifikace Plnění.

Kvalifikovaná osoba je člen Realizačního týmu, kterým Dodavatel prokazoval splnění
kvalifikačních předpokladů v rámci Veřejné zakázky.

Kybernetický bezpečnostní incident je narušení bezpečnosti informací v informačních
systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických
komunikací podle § 7 ZKB v důsledku Kybernetické bezpečnostní události.

Kybernetická bezpečností událost je událost podle § 7 ZKB, která může způsobit narušení
bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo
bezpečnosti a integrity sítí elektronických komunikací.

MD znamená manday/člověkoden. Nestanoví-li Smlouva jinak, odpovídá jeden MD 8 MH.

MH znamená manhour/člověkohodinu. Nestanoví-li Smlouva jinak, odpovídá jedna MH 60
minutám práce.

Modernizace je změna verze Softwaru, která zpravidla představuje výraznější zásah do dílčí
funkcionality Softwaru, přepracováním jeho vybrané funkcionality či doplnění funkcionality nové,
zvýšení kompatibility Softwaru s jinými prvky informačních a komunikačních technologií, či jinou
optimalizaci funkce Softwaru nad rámec Aktualizace, zpravidla v IT označovaná jako „update“ (v
rámci IT se také často označuje jako změna druhé číslice v čísle verze Softwaru, tedy např. 4.1.
na 4.2.).

NÚKIB znamená Národní úřad pro kybernetickou a informační bezpečnost.

Občanský zákoník znamená zákon č. 89/2012 Sb., občanský zákoník, ve znění pozdějších
předpisů.

Obchodní podmínky znamenají obchodní podmínky Objednatele v posledním znění ke dni podání
nabídky do Veřejné zakázky či aktualizace těchto Obchodních podmínek provedené v souladu se
Smlouvou po dobu jejího trvání.

4/33
1.39. Objednatel je Správa železnic, státní organizace, IČO 70994234, se sídlem Praha 1 – Nové Město,
1.40. Dlážděná 1003/7, PSČ 110 00, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze
1.41. pod sp. Zn. A 48384.
1.42.
1.43. Ohlašovatel znamená osobu určenou Objednatelem, zpravidla uživatele Předmětu Smlouvy.
1.44.
1.45. Opční právo představuje vyhrazenou změnu závazku v souladu s ustanovením § 100 odst. 3
ZZVZ ze Smlouvy spočívající v pořízení dalšího obdobného Plnění od vybraného uchazeče v rámci
1.46. zadávacího řízení Veřejné zakázky, tj. od Dodavatele dle Smlouvy.
1.47.
1.48. Osobní údaje znamenají osobní údaje ve smyslu GDPR, včetně zvláštních kategorií osobních
údajů ve smyslu článku 9 a rozsudků ve smyslu článku 10 GDPR.
1.49.
1.50. Pracovní den (PD) znamená kterýkoliv den, kromě soboty a neděle a dnů, na něž připadá státní
1.51. svátek nebo ostatní svátek podle platných a účinných právních předpisů České republiky.
1.52.
1.53. Paušální služby jsou služby definované ve Smlouvě, jsou-li takové, zpravidla trvajícího či
1.54. opakujícího se charakteru.
1.55.
1.56. Platforma Správy železnic je dokument, který definuje prostĜedí, které standardizuje a
podporuje návrh, implementaci a provozování veškerého ICT Ĝešení pro Správu železnic. Popisuje
infrastrukturní a platformní služby, podporované technologie a upravuje pravidla jejich použití i
rozšiĜování. Primárním cílem Platformy SŽ je poskytnout potenciálním dodavatelům základní
pĜehled o ICT prostĜedí SŽ a současně umožnit organizaci SŽ zajištění efektivního vytváĜení a
provozování ICT Ĝešení pĜi dodržení vysoké kvality a bezpečnosti služeb.

Plnění představuje plnění, které tvoří Předmět Smlouvy a k němuž se váže povinnost Dodavatele
toto plnění Objednateli poskytovat. Plnění je blíže specifikované ve Smlouvě a v Příloze Smlouvy
Specifikace Plnění.

Poddodavatel znamená kteroukoli třetí osobu realizující poddodávky pro Dodavatele v souvislosti
s Předmětem Smlouvy. Poddodavatelé mohou být výslovně uvedeni v Příloze Smlouvy
Poddodavatelé.

Požadavek znamená žádost ze strany Objednatele o službu nebo její podporu předanou v souladu
se Smlouvou Dodavateli, která nemá příčinu v chybovém stavu, tj. není Incidentem.

Kategorizace Požadavků dle důležitosti:

A) Vysoká – řešení je pro Objednatele kritické

B) Střední – řešení neovlivňuje využívání hlavních funkcí služby

C) Nízká – řešení výrazně neovlivňuje procesy Objednatele

Produkční prostředí znamená IT prostředí Objednatele v ostrém provozu běžně přípustnou
uživatelům Software, vyjma Testovacího prostředí.

Provozovatel znamená provozovatel ve smyslu § 2 písm. g) ZKB.

Předmět Smlouvy znamená dle typu Smlouvy Software nebo Hardware, přičemž parametry a
vlastnosti Předmětu Smlouvy jsou blíže specifikovány v Příloze Smlouvy Specifikace Plnění.

Převzetí poskytování plnění je předání znalostí Dodavateli a praktické seznámení se Dodavatele
s podmínkami poskytování služeb. Pokud dochází k převzetí poskytování podpory, jsou podmínky
pro Převzetí poskytování plnění uvedeny ve Smlouvě a v Příloze Smlouvy Specifikace Plnění.

Příloha Smlouvy je dokument, který tvoří nedílnou součást Smlouvy a obsahuje bližší specifikaci
smluvních podmínek.

Reakce znamená kvalifikovanou a konkrétní odpověď na nahlášení Incidentu nebo na jiný
požadavek, ve formě a způsobem dále definovanými v Příloze Smlouvy Specifikace Plnění.

Reakční doba je pro každou kategorii Incidentů uvedena v Příloze Specifikace Plnění a
představuje dobu od Času nahlášení Incidentu do doručení Reakce Objednateli nebo Ohlašovateli.

Realizační tým znamená osoby uvedené v příloze Smlouvy Realizační tým, kterými Dodavatel
prokazoval splnění kvalifikačních předpokladů v rámci Veřejné zakázky a další osoby (zaměstnanci
Dodavatele či Poddodavatele), prostřednictvím nichž Dodavatel provádí Plnění dle Smlouvy.

5/33
1.57. Recovery Point Objective (RPO) je parametr, který vyjadřuje maximální ztrátu dat uživatelů
1.58. při havárii systému a následné obnově.
1.59.
1.60. Recovery Time Objective (RTO) je parametr, který vyjadřuje dobu nutnou k obnově chodu
1.61. služby do akceptované úrovně provozu.
1.62.
1.63. Servisní model je standardizovaný model provozu a podpory aplikace, systému nebo instance
služby.
1.64.
SLA znamená úroveň kvality Plnění představující dohodu o úrovni poskytovaných ICT služeb dle
1.65. Smlouvy.
1.66.
1.67. Služby jsou služby definované ve Smlouvě, jsou-li takové.
1.68.
1.69. Smluvní strany či Strany jsou strany Smlouvy, tj. Objednatel a Dodavatel či jinak označené
strany Smlouvy, jejíž součástí jsou tyto ZOP.

Software znamená veškeré programové vybavení a další Autorská díla, stejně jako další věci či
jiné majetkové hodnoty, které s programovým vybavením souvisí a jsou určeny ke společnému
užívání s tímto programovým vybavením, tj. zejména Databáze, GUI, zvukové nahrávky, videa,
obrázky, fotografie apod., včetně veškeré související dokumentace a updatů a upgradů tohoto
programového vybavení, avšak s výjimkou Hardwaru a Databází.

Standardní Software znamená Software, který je distribuován pod standardními licenčními
podmínkami více třetím osobám. Mezi Standardní software patří:

a. Software renomovaných výrobců, jenž je na trhu běžně dostupný, tj. nabízený na území

České republiky alespoň dvěma (2) na sobě nezávislými a vzájemně se neovládajícími

subjekty, a který je v době uzavření Smlouvy prokazatelně užíván v produkčním prostředí

nejméně u pěti (5) na sobě nezávislých a vzájemně nepropojených subjektů.

b. Software, u kterého je s ohledem na jeho (i) marginální význam, (ii) nekomplikovanou

propojitelnost či (iii) oddělitelnost a nahraditelnost v IT prostředí bez nutnosti vynakládání

větších prostředků (více než 50.000 Kč/rok) zajištěno, že další rozvoj Softwaru jinou

osobou než tvůrcem/distributorem takového Softwaru je možné provádět bez toho, aby

tím byla dotčena práva autorů takovéhoto Softwaru, neboť nebude nutné zasahovat do

Zdrojových kódů takovéhoto Softwaru anebo proto, že případné nahrazení takovéhoto

Softwaru nebude představovat výraznější komplikaci a náklad na straně Objednatele.

c. Software, jehož API („Application Programming Interface“) pokrývá všechny moduly a

funkcionality Softwaru, je dobře dokumentované, umožňuje zapouzdření Softwaru a jeho

adaptaci v rámci měnících se podmínek IT prostředí Objednatele a Softwaru bez nutnosti

zásahu do Zdrojových kódů Softwaru, a Dodavatel poskytne Objednateli právo užít toto

rozhraní pro programování aplikací ve stejném rozsahu jako Software.

d. Software, o kterém to stanoví Smlouva.

Smlouva uzavřená na základě zadávacího řízení Veřejné zakázky vztahující se k ICT, která se řídí
těmito ZOP. Smlouvou se rovněž rozumí rámcová dohoda a dílčí smlouva uzavřená na základě
takové rámcové dohody.

Testy se rozumí provádění testovacího užívání Předmětu Smlouvy v Testovacím prostředí
prostřednictvím simulace ostrého provozu v Produkčním prostředí a reálných situací a Testovacích
scénářů.

Testovací prostředí znamená virtuální či fyzickou kopii Předmětu Smlouvy anebo IT prostředí
Objednatele určenou Objednatelem k provádění Testů.

Vada kategorie A znamená kritickou vadu, která má zásadní dopad na základní funkce Plnění,
má jakýkoli vliv na kvalitu a bezpečnost dat a výsledky jejich zpracování anebo způsobuje výpadky
Plnění.

Vada kategorie B znamená vadu umožňující provoz základních funkcí Plnění, zároveň nemá vliv
na kvalitu ani na bezpečnost dat a výsledky zpracování anebo hrozí, že by mohla způsobit výpadek
Plnění.

6/33
1.70. Vada kategorie C znamená vadu, která není Vadou kategorie A anebo B (např. špatná grafická
1.71. úprava aplikace, špatný pravopis u nápovědy apod.).
1.72.
1.73. Veřejná zakázka je zakázka realizovaná na základě smlouvy mezi Objednatelem a Dodavatelem,
1.74. jež byla uzavřena na základě zadávacího řízení dle ZZVZ nebo výběrového řízení dle vnitřních
předpisů Objednatele.
1.75.
1.76. VKB znamená vyhlášku č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických
1.77. bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické
bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů, ,
1.78. případně jiný předpis tuto vyhlášku nahrazující
1.79.
1.80. Výkaz znamená dokument obsahující souhrnnou evidenci poskytnutého Plnění za období
vymezené ve Smlouvě nebo v Příloze Smlouvy Specifikace Plnění. Výkaz je vystavován zpětně za
vymezené období.

Výpadek znamená neplánované přerušení provozu Předmětu smlouvy či jakékoliv jeho podstatné
části, při kterém je tento celek či příslušná část nedostupná pro uživatele (není dostupný). Za
Výpadek se pro účely této Smlouvy nepovažuje Výpadek způsobený z důvodů způsobených třetími
osobami, jejichž součinnost anebo bezvadné poskytování služeb je povinen zajistit Objednatel
(poskytovatel služeb podpory IT prostředí Objednatele a informačních systémů, na které je
Software napojen).

Újma znamená vždy újmu na jmění (škodu) ve smyslu § 2894 odst. 1 Občanského zákoníku a
dále vždy i nemajetkovou újmu ve smyslu § 2894 odst. 2 Občanského zákoníku. Toto ustanovení
je výslovným ujednáním o povinnosti stran odčinit nemajetkovou újmu v případech porušení
povinností dle těchto ZOP a Smlouvy.

Významný dodavatel znamená Dodavatel, který je Provozovatelem, jakož i každý, kdo
s Objednatelem vstupuje do právního vztahu, který je významný z hlediska bezpečnosti
Informačního či komunikačního systému ve smyslu § 2 odst. n) VKB.

Významná změna znamená změna, která má nebo může mít vliv na kybernetickou bezpečnost
a představuje vysoké riziko, např.

a. změny pravidel ochranných systémů aplikačních firewallů a pravidel přepínání a směrování

v sítích,

b. změny autentizačních mechanismů,

c. přidání, změna nebo odebrání služeb, informačních systémů/aplikací nebo ochranných

systémů,

d. změny, které umožňují sdílení informací, služeb nebo zdrojů mimo provozní prostředí,

e. změny opatření pro zajištění bezpečnosti vzdáleného přístupu,

f. zavedení skriptů pro automatické přihlášení,

g. migrace dat do jiné Databáze, apod. ve smyslu § 2 odst. o) VKB.

Zadávací dokumentace je souborem dokumentů obsahujících zadávací podmínky, sdělované
nebo zpřístupňované účastníkům zadávacího řízení na Veřejnou zakázku.

Zásadní modernizace je podstatná změna/rozšíření funkčnosti nebo změna koncepce Softwaru,
přinášející podstatné změny pro chování Softwaru vůči uživatelům, zpravidla v IT označovaná jako
„upgrade“ (v rámci IT se také často označuje jako změna v čísle verze Software, tedy např. 4 na
5).

Zdrojový kód znamená zápis kódu počítačového programu (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 jeho jednotlivé části alespoň ve standardu obvyklém pro open source projekty a
procesy, ve spustitelném formátu odpovídajícím programovacímu jazyku a Produkčnímu prostředí,
včetně ověřeného a podrobného postupu nezbytného pro sestavení plně funkčního strojového
kódu, a v podobě, aby jej bylo možné zkompilovat do strojového kódu bez nutnosti provedení
jiných úprav než kompilace v souladu s postupem k sestavení.

7/33
1.81. ZKB znamená zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů
(zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů, případně jiný předpis tento
1.82. zákon nahrazující
1.83.
1.84. ZOP znamená tento dokument, tedy zvláštní obchodní podmínky, které definují další parametry a
upřesňují konkrétní podmínky a specifické požadavky Objednatele.
1.85.
ZZVZ znamená zákon č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších
1.86. předpisů.
1.87.
Není-li výslovně uvedeno jinak nebo nevyplývá-li něco jiného z povahy věci, mají pojmy, které
nejsou definovány v těchto ZOP, význam uvedený v Obchodních podmínkách či Smlouvě a jejích
přílohách.

Ustanovení ZOP mají přednost před ustanoveními Obchodních podmínek, pokud jsou ustanovení
těchto dokumentů v rozporu, uplatní se ustanovení uvedené v ZOP. Ustanovení Smlouvy mají
přednost před ustanoveními Obchodních podmínek i ZOP.

Pokud je uveden v ZOP čas, jedná se o čas SEČ.

Dodavatel je povinen se seznámit s Platformou Správy železnic, a to bez ohledu na to, zda plnění
probíhá v IT prostředí Objednatele, a to minimálně v rozsahu, v kterém je pro Plnění relevantní.

2. DOBA A MÍSTO PLNĚNÍ
2.1.
2.2. Provádění Plnění bude zahájeno ode dne nabytí účinnosti Smlouvy, není-li ve Smlouvě stanoveno
2.3. jinak.
2.4.
Plnění nebo dílčí části Plnění bude Dodavatel provádět v termínech sjednaných ve Smlouvě či
2.5. definovaných v Příloze Smlouvy Specifikace Plnění nebo Harmonogram.

Místem provádění Plnění jsou místa umístění IT prostředí Objednatele (tj. Testovací prostředí a
Produkční prostředí), není-li ve Smlouvě anebo Příloze Smlouvy Specifikace Plnění výslovně
stanoveno jinak. Popis IT prostředí Objednatele obsahuje Příloha Smlouvy Platforma Správy
železnic.

Služby budou poskytovány formou vzdáleného přístupu k IT prostředí Objednatele, není-li ve
Smlouvě stanoveno jinak. Objednatel se zavazuje umožnit Dodavateli vzdálený přístup k IT
prostředí Objednatele. Objednatel je oprávněn monitorovat a logovat přístupy Dodavatele do IT
prostředí Objednatele, jakož i veškerou další aktivitu Dodavatele významnou z hlediska
bezpečnosti Informačního či komunikačního systému za účelem posouzení souladu Plnění Smlouvy
s pravidly uvedenými v těchto ZOP, zejm. pak v čl. 20. ZOP, a Dodavatel se zavazuje Objednateli
za tímto účelem poskytnout veškerou nutnou součinnost. Vzdálený přístup k IT prostředí
Objednatele může být Objednatelem okamžitě odepřen v případě Kybernetické bezpečnostní
události ve smyslu § 7 ZKB či porušení povinností stanovených v Interních předpisech.

Dodavatel bere na vědomí, že přístup k IT prostředí Objednatele:

a. je udělován fyzickým osobám Dodavatele, jakož i pro konkrétní zařízení, na základě

výslovného požadavku Dodavatele a Objednatel je oprávněn dle svého uvážení přístup

neudělit či kdykoli odebrat;

b. je poskytován na základě principů “need to know” a “deny by default”; a

c. je poskytován za podmínky dodržování veškerých bezpečnostních opatření a požadavků

Objednatele.

3. PRÁVA A POVINNOSTI OBOU STRAN
3.1.
Strany se zavazují postupovat v souladu s veškerými obecně závaznými právními předpisy a
3.2. prohlašují, že Smlouva je v souladu s těmito právními předpisy. Pokud se v průběhu trvání
Smlouvy některé její ustanovení dostane do rozporu s kogentním ustanovením obecně závazného
právního předpisu, platí příslušné ustanovení právního předpisu s tím, že zbývající ustanovení
Smlouvy zůstávají v platnosti.

Strany jsou v průběhu Plnění povinny postupovat v souladu s Interními předpisy Objednatele,
pokud jsou jednoznačně specifikovány v Příloze Smlouvy Seznam Interních předpisů. Podpisem

8/33
Smlouvy Dodavatel prohlašuje, že měl možnost se seznámit s Interními předpisy Objednatele,
jejichž seznam je uveden v Příloze Smlouvy Seznam interních předpisů, a dále bere na vědomí, že
Interní předpisy mohou být přiměřeným způsobem jednostranně měněny či jinak doplňovány
Objednatelem, přičemž každá nová verze je pro Dodavatele závazná vždy ode dne, kdy se s ní
seznámil či měl prokazatelnou možnost se s nimi seznámit. Rozsah Interních předpisů může být
Objednatelem jednostranně rozšířen o další dokumenty stanovující jeho interní procesy.

4. POVINNOSTI DODAVATELE
4.1.
Dodavatel se zavazuje provádět pro Objednatele Plnění osobně, tj. prostřednictvím svých
4.2. zaměstnanců, členů Realizačního týmu a prostřednictvím svých Poddodavatelů za podmínek
stanovených ve Smlouvě a těchto ZOP. V případě, že je požadavek na složení Realizačního týmu
4.3. uveden ve Smlouvě, je Dodavatel povinen provádět Plnění výhradně prostřednictvím členů
Realizačního týmu, kterými prokázal splnění kvalifikace v průběhu zadávacího řízení na Veřejnou
zakázku.

Dodavatel se během poskytování Plnění pro Objednatele zavazuje informovat Objednatele o
Významné změně ovlivnění nebo ovládání Dodavatele podle ust. § 71 a násl. zákona č. 90/2012
Sb., o obchodních korporacích, ve znění pozdějších předpisů (dále jen „ZOK“), nebo změně
vlastnictví zásadních aktiv, využívaných Dodavatelem k Plnění Smlouvy a změně oprávnění
nakládat s těmito aktivy.

Dodavatel se zavazuje poskytovat v rámci Plnění veškerou součinnost nezbytnou k provádění
Plnění, zejména, nikoliv však výlučně:

a. poskytovat Plnění dle Smlouvy ve vysoké kvalitě s odbornou péčí odpovídající podmínkám

sjednaným ve Smlouvě;

a. poskytovat Plnění dle Smlouvy alespoň v závazných parametrech kvality dle Smlouvy
a SLA, a to zejména dodržování stanoveného Servisního modelu dle odst. 12.2. ZOP;

b. upozorňovat Objednatele včas na všechny hrozící vady svého Plnění či potenciální
Výpadky či jiné výpadky Plnění, jakož i poskytovat Objednateli veškeré informace,
které jsou pro Plnění potřebné;

c. zajistit v souladu s podmínkami Smlouvy poskytnutí Dokumentace, a to rovněž vždy
při každé Aktualizaci nebo jiné změně Předmětu smlouvy, nestanoví-li Objednatel
jinak;

d. počínat si při provedení Plnění tak, aby nedošlo k infikaci Softwaru, Standardního
Softwaru nebo IT prostředí Objednatele virem či jiným škodlivým kódem (malware
apod.) způsobujícím narušení zabezpečení Softwaru a Standardního Softwaru za
účelem jeho poškození či jiného narušení běhu;

e. bez zbytečného odkladu oznamovat Objednateli všechny Kybernetické bezpečnostní
události a Kybernetické bezpečnostní incidenty s potenciálním negativním dopadem na
Objednatele;

f. bez zbytečného odkladu na výzvu Objednatele předat Data, provozní údaje a informace
ve formátu předem odsouhlaseném Objednatelem (zpravidla ve formátu daného
prostředí, který umožňuje jejich nasazení „as is“ do prostředí), které má k dispozici
v souvislosti s Plněním Smlouvy, a poskytnout Objednateli za tímto účelem veškerou
nezbytnou součinnost; tato Data musí být po dobu poskytování Plnění dle Smlouvy
uložena u Dodavatele a mohou být Dodavatelem užívána v souladu se Smlouvou a
příslušnými právními předpisy, avšak pouze v nezbytném rozsahu. Dodavatel se
zavazuje dodržovat přiměřená technická a organizační opatření k ochraně těchto Dat.
Veškerá Data jsou vlastnictvím Objednatele, není-li ve Smlouvě výslovně stanoveno
jinak. Toto ustanovení se uplatní obdobně i na jiná data poskytnutá Objednatelem
Dodavateli;

g. plnit Interní předpisy Objednatele a jeho pokyny v oblasti likvidace Dat (ať už Dat na
papírových médiích, Dat zpracovávaných elektronicky nebo prostřednictvím jakýchkoli
dalších nosičů Dat) a případně dále na výzvu Objednatele bez zbytečného odkladu
zlikvidovat Data v souladu s těmito pravidly a pokyny. Dodavatel musí především

9/33
4.4. postupovat tak, aby nebylo možné odstraněná data zneužít. Za odpovídající způsob
likvidace dat je považováno odstranění, přepsání či fyzická likvidace nosiče informace
v souladu se standardem US DoD 5220.22-M;

h. poskytnout při ukončení smluvního vztahu přiměřenou součinnost při Převzetí
poskytování Plnění novým Dodavatelem nebo Objednatelem, a to s odbornou péčí,
zodpovědně a do doby úplného Převzetí poskytování Plnění.

Dodavatel se během poskytování Plnění pro Objednatele zavazuje informovat Objednatele o
žádosti cizozemského orgánu o zpřístupnění nebo předání dat zpracovávaných na území cizího
státu, vyjma situace, kdy by takové informování bylo v rozporu s právním řádem, v jehož
působnosti dochází ke zpracování dat nebo podle kterého byla žádost podána. V případě
zpřístupnění nebo předání dat na základě žádosti cizozemského orgánu o zpřístupnění nebo
předání dat zpracovávaných na území cizího státu se Dodavatel zavazuje tato data zpřístupnit
nebo předat:

a. až po provedení přezkoumání zákonnosti žádosti,

b. až po vynaložení úsilí o zabránění zpřístupnění nebo předání dat v rámci možností
daných právním řádem, v jehož působnosti dochází ke zpracování dat nebo podle
kterého byla žádost podána,

c. pouze v nezbytném rozsahu.

5. POVINNOSTI OBJEDNATELE
5.1.
Objednatel je povinen zajistit Testovací a Produkční prostředí pro činnost Dodavatele v rámci IT
prostředí Objednatele, pokud je to nezbytné pro provádění Plnění. Zajištění prostředí zahrnuje
zajištění vzdáleného přístupu personálu Dodavatele do IT prostředí Objednatele, v přiměřeném
rozsahu odpovídajícího možnostem Objednatele a Zadávací dokumentaci a při respektování
bezpečnostních pravidel Objednatele, zejména bezpečnostní dokumentace, která je součástí
Interních předpisů. Objednatel je povinen zajistit fungování Dodavatelem vytvořeného Testovacího
prostředí, na kterém bude Software Testován, a Produkčního prostředí, na kterém Software poběží
v ostrém provozu, přičemž všechna prostředí budou umístěna na IT prostředí Objednatele, není-li
ve Smlouvě stanoveno jinak.

6. LICENČNÍ UJEDNÁNÍ

6.1. Smlouva stanoví, která licenční ujednání dle tohoto článku se použijí ve vztahu k Plnění.
Neobsahuje-li Smlouva takový odkaz, použije se ve vztahu k Plnění vedle společných ustanovení
k licenčním ujednáním dle odst. 6.7 tohoto článku též odst. 6.3 tohoto článku a ve vztahu k částem
Plnění, která obsahují Standardní Software, též odst. 6.5 tohoto článku. Je-li součástí Plnění
Hardware, použijí se též pravidla dle odst. 6.6 tohoto článku.

6.2. Odměna za oprávnění dle tohoto článku je zahrnuta v ceně Plnění.

6.3. Postoupení výkonu autorských majetkových práv k Software

6.3.1. V případě, že je Software Autorské dílo vznikající v průběhu Plnění, Dodavatel neodvolatelně
postupuje na Objednatele oprávnění k výkonu majetkových práv autorských k takovému
Autorskému dílu).

6.3.2. Dodavatel prohlašuje, že Software byl vytvořen zaměstnanci či Poddodavateli jako zaměstnanecké
dílo ve smyslu § 58 odst. 1 a 7 Autorského zákona, a že je oprávněn k postoupení výkonu
majetkových práv v souladu s tímto odst. 6.3 ZOP a má k takovému postoupení náležité souhlasy,
přičemž Dodavatel se zavazuje na požádání Objednatele neprodleně předložit nebo jinak vhodným
způsobem zpřístupnit dokumenty prokazující rozsah oprávnění Dodavatele.

6.3.3. Objednatel je dále oprávněn postoupit oprávnění k výkonu majetkových práv na jakoukoli další
třetí osobu dle volby Objednatele a udělovat licence a podlicence, s čímž Dodavatel výslovně
souhlasí; pro zamezení pochybnostem je Dodavatel povinen podniknout veškeré kroky k získání
náležitých oprávnění tak, aby mohl oprávnění k výkonu majetkového práva postoupit na
Objednatele v souladu s tímto odst. 6.3 ZOP. S povinností převodu oprávnění k výkonu
majetkových práv se pojí povinnost předání Zdrojového kódu dle čl. 7 ZOP.

10/33
6.3.4. Dodavatel dále prohlašuje, že má svolení autora/ů k zásahům do Software (včetně jeho
Zdrojového a strojového kódu) ve smyslu § 58 odst. 4 Autorského zákona a tato svolení se vztahují
na jakékoliv třetí osoby, jež budou vykonávat autorská majetková práva k tomuto Software.

6.3.5. Dodavatel dále prohlašuje, že vyloučil oprávnění autorů dle ustanovení § 58 odst. 3 Autorského
zákona i vůči všem budoucím vykonavatelům autorských majetkových práv k Software.

6.3.6. Dodavatel dále převádí veškerá zvláštní práva pořizovatele k Databázím, jež tvoří součást Plnění.
Nedojde-li z jakéhokoliv důvodu k převodu práva dle předchozí věty, uděluje Dodavatel
Objednateli oprávnění k vytěžování a zužitkování celého obsahu takové Databáze nebo její
kvalitativně nebo kvantitativně podstatné části a právo udělit jinému oprávnění k výkonu tohoto
práva.

6.3.7. K ostatním majetkovým hodnotám, které spadají pod pojem Software a zároveň nespadají pod
definici Autorského díla, uděluje Dodavatel Objednateli oprávnění v rozsahu dle odst. 6.3.8. ZOP.
Ustanovení odst. 6.5 a 6.6 ZOP tímto nejsou dotčena.

6.3.8. Nevznikne-li Objednateli z jakéhokoliv důvodu ke kterékoliv části Softwaru oprávnění k výkonu
autorských majetkových práv, uděluje Dodavatel Objednateli k dotčené části množstevně a
územně neomezenou výhradní licenci ke všem známým způsobům užití, a to na dobu trvání
autorských majetkových práv. Objednatel je oprávněn k dotčené části Softwaru udělovat licence,
tyto dále postoupit a udělovat podlicence třetím osobám. Objednatel je dále oprávněn dotčené
části upravovat a měnit (včetně Zdrojového a strojového kódu takové části Software), dokončovat,
včetně práva takto upravené či dokončené části užívat, a dále tyto původní, upravené či dokončené
části zveřejňovat, spojovat s jiným dílem či zařazovat do díla souborného, zpracovávat, překládat
či jinak zasahovat, a to vše i prostřednictvím třetí osoby.

6.4. Nevýhradní licence k Software

6.4.1. Ve vztahu k Software Dodavatel tímto uděluje Objednateli okamžikem akceptace Plnění ve smyslu
čl. 8 ZOP, nebo jinak vymezeným okamžikem akceptace Plnění Smlouvou a jejími přílohami
nevýhradní oprávnění k výkonu práva užít Software v souladu s dalšími podmínkami odst. 6.4 ZOP
(dále „Licence“). Ustanovení tohoto odstavce se nevztahují na oprávnění Objednatele k Software,
který je Standardním Software; tato oprávnění jsou upravena samostatně v odst. 6.5 ZOP.
V případě, že je Plnění rozděleno na části, použije se tento odstavec na každou část Plnění.

6.4.2. Licence se uděluje jako nevýhradní a opravňuje Objednatele k výkonu práva užít veškerá Autorská
díla a k výkonu práva vytěžovat a zužitkovat Databáze, jež tvoří Plnění, a to:

a. k jakémukoliv účelu;

b. na dobu trvání majetkových práv autorských;

c. na jakémkoliv území;

d. jakýmkoliv způsobem; a

e. bez množstevního omezení.

6.4.3. Dodavatel okamžikem dle odst. 6.3. ZOP uděluje rovněž oprávnění takový Software upravovat a
měnit (včetně Zdrojového a strojového kódu), dokončovat, včetně práva takto upravený, změněný
či dokončený Software užívat v rozsahu Licence, a dále tyto původní, upravené, změněné či
dokončené části spojovat s jiným dílem či zařazovat do díla souborného, zpracovávat, překládat
či jinak do nich zasahovat, a to vše i prostřednictvím třetí osoby

6.4.4. Objednatel má v rámci Licence právo udělit k Softwaru podlicenci třetím osobám a právo postoupit
Licenci zcela či z části na třetí osoby, s čímž Dodavatel výslovně souhlasí.

6.4.5. Licence zahrnuje povinnost Dodavatele předat Objednateli Zdrojový kód a Dokumentaci
k Software dle článku 7 ZOP.

6.4.6. Licence se vztahuje ve stejné míře a rozsahu jako k Software taktéž na:

a. Dokumentaci specifikovanou ve Smlouvě nebo jejích přílohách;

b. jakoukoliv jinou Dokumentaci předávanou k Software nad rámec Dokumentace dle

předchozího písmene;

11/33
c. loga či jiné předměty duševního vlastnictví, které souvisí s Plněním a jsou vhodné či

nezbytné k užití spolu s Plněním;

d. jakákoliv jiná Autorská díla či jiné předměty duševního vlastnictví, které souvisí s Plněním.

6.5. Licence ve vztahu ke Standardnímu Software

6.5.1. V případech, kdy je součástí Plnění Standardní Software, Dodavatel uděluje Objednateli
okamžikem akceptace Plnění ve smyslu čl. 8 ZOP, jehož součástí je Standardní Software, k
veškerému takovému Standardnímu Software nevýhradní oprávnění k výkonu práva užít příslušný
Standardní Software v souladu s dalšími podmínkami odst. 6.5 ZOP (dále „Licence k
Standardnímu Software“). V případě, že je Plnění rozděleno na části, použije se tento odstavec
na každou část Plnění, jehož součástí je Standardní Software či jeho část.

6.5.2. Licence k Standardnímu Software se uděluje jako nevýhradní a opravňuje Objednatele k výkonu
práva užít veškerý Standardní Software, a to:

a. všemi způsoby odpovídajícími účelu, pro který je takový Standardní Software určen;

b. na dobu trvání majetkových práv autorských, nebo alespoň na dobu trvání Smlouvy;

c. na jakémkoliv území; a

d. bez množstevního omezení.

6.5.3. Dodavatel je v rámci Licence k Standardnímu Software povinen zajistit poskytnutí podpory
(subscription/license maintenance) k veškerému Standardnímu Software, tj. zajistit poskytování
nejnovějších verzí Standardního Software Objednateli a dalších služeb v souladu se standardními
licenčními podmínkami Standardního Software, a to alespoň na dobu trvání Smlouvy.

6.5.4. Objednatel má v rámci Licence k Standardnímu Software oprávnění udělit ke Standardnímu
Software podlicenci třetím osobám a právo postoupit Licenci k Standardnímu Software zcela či z
části na třetí osoby, s čímž Dodavatel výslovně souhlasí.

6.5.5. Licence k Standardnímu Software se vztahuje ve stejné míře jako k Standardnímu Software taktéž
na:

a. Aktualizaci, Modernizaci a Zásadní modernizaci Standardního Software, který je součástí

Plnění;

b. Dokumentaci k Standardnímu Software specifikovanou ve Smlouvě nebo jejích přílohách;

c. Dokumentaci nad rámec Dokumentace k Standardnímu Software dle předchozího písm.;

d. právo zužitkovat a vytěžovat Databáze obsažené ve Standardním Software, který je

součástí Plnění;

e. loga či jiné předměty duševního vlastnictví, které se Standardním Software, jež je součástí

Plnění, souvisí a jsou vhodné či nezbytné k užití spolu s takovým Standardním Software.

6.5.6. V parametrech, které nejsou upraveny Smlouvou, jejími přílohami anebo jinou částí Zadávací
dokumentace, se Licence k Standardnímu Software řídí příslušnými licenčními podmínkami
výrobce Standardního Software.

6.5.7. V případě, že Dodavatel využije při plnění předmětu Smlouvy Standardní Software, je Dodavatel
za účelem vyloučení vzniku proprietárního uzamčení Objednatele (tzv. vendor lock-in) povinen
použít výlučně takový Standardní Software, u kterého jsou splněny podmínky dle definice
Standardního Software dle odst. 1.64 písm. a., b., c. nebo d. ZOP, v době využití Standardního
Software, a u kterého lze zároveň důvodně předpokládat, že tento stav zůstane zachován
minimálně po dobu trvání Smlouvy.

6.5.8. V případě, že Dodavatel v rámci plnění Smlouvy použije Standardní Software, který v průběhu
trvání Smlouvy nebude anebo přestane splňovat podmínky stanovené v odst. 6.5.7 ZOP, je
Dodavatel povinen, po dohodě s Objednatelem, a v případě, že tato dohoda nebude možná, pak
dle volby Dodavatele:

a. na vlastní náklady dodat Objednateli Zdrojový kód předmětného Standardního Software a

poskytnout Objednateli oprávnění užívat tento Standardní Software včetně Zdrojového

kódu (včetně dalších způsobů nakládání) v rozsahu Licence dle odst. 6.4 ZOP; nebo

12/33
b. nahradit na vlastní náklady předmětný Standardní Software jiným Standardním Software,

který bude mít alespoň srovnatelné funkcionality, kvalitu a technickou způsobilost jako

nahrazovaný Standardní Software a zároveň splňovat podmínky stanovené v odst. 6.5.7

ZOP, a poskytnout k tomuto Standardnímu Software Objednateli Licenci k Standardnímu

Software dle odst. 6.5 ZOP; nebo

c. nahradit na vlastní náklady předmětný Standardní Software vlastním Softwarem, tj.

přeprogramovat část Díla představovanou předmětným Standardním Softwarem za využití

vlastního Software vytvořeného na míru Objednateli, který bude mít alespoň srovnatelné

funkcionality, kvalitu a technickou způsobilost jako nahrazovaný Standardní Software, a

poskytnout k tomuto vlastnímu Softwaru Objednateli Licenci dle odst. 6.4 ZOP, a to včetně

Zdrojového kódu.

6.5.9. Postupy dle odst. 6.5.8 písm. a) až c) ZOP podléhají samostatnému Akceptačnímu řízení. Vznikla-
li Dodavateli povinnost dle odst. 6.5.8 ZOP, je Dodavatel povinen splnit povinnosti dle uvedeného
odstavce i po ukončení Smlouvy. Ustanovení Smlouvy a ZOP relevantní pro splnění povinností dle
předchozí věty se použijí i po ukončení Smlouvy.

6.5.10. Pokud v rámci Akceptačního řízení dle čl. 8 ZOP vyjde najevo, že Standardní Software nesplňuje
podmínky odst. 6.5.7 ZOP, je Objednatel oprávněn Akceptační řízení přerušit, dokud Dodavatel
nenapraví tento nedostatek předmětného Standardního Software jedním ze způsobů uvedených v
odst. 6.5.8 ZOP. Objednatel není v takovém případě v prodlení.

6.5.11. Ustanovení odst. 6.3 a 6.6 ZOP se pro Standardní Software nepoužijí.

6.6. Software vztahující se k Hardware

6.6.1. V případech, kdy je k řádnému užívání dodaného Hardwaru potřebný určitý Software, je Dodavatel
povinen poskytnout/zajistit Objednateli jako součást Plnění a za cenu zahrnutou v ceně Hardwaru,
oprávnění užít tento Software v rozsahu, způsoby a za účelem obvyklým ve vztahu k Hardwaru,
se kterým je spojen, nejméně však za podmínek dle Smlouvy a jejích příloh.

6.6.2. Ustanovení odst. 6.3 a 6.4 ZOP se pro Software vztahující se k Hardwaru nepoužijí.

6.7. Společná ustanovení

6.7.1. Nestanoví-li Smlouva a její přílohy či jiné části Zadávací dokumentace jinak, je Dodavatel při
plnění Smlouvy oprávněn využít programy s otevřeným kódem či jejich části distribuovanými pod
FOSS licencemi. Dodavatel však není oprávněn využít programy s otevřeným kódem či jejich
části, které jsou distribuovány pod FOSS licencemi, jejichž podmínky by Objednateli ukládaly
povinnost sdělovat nebo jinak šířit Software či jeho části, včetně Zdrojových kódů, třetím osobám,
nebo umožnit jim změny, úpravy či jiné zásahy do Softwaru nebo jeho části.

6.7.2. Dodavatel je povinen zajistit Objednateli udělení oprávnění k veškerým programům s otevřeným
kódem poskytnutým Objednateli v rozsahu takových FOSS licencí, které se na konkrétní program
s otevřeným kódem, který je součástí Plnění, vztahují, přičemž konkrétní rozsah licence lze určit
odkazem na soubor předávaný v rámci výstupu z Plnění anebo odkazem ve Zdrojovém kódu či
jiným označením 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 příslušné FOSS licence; Dodavatel je dále
povinen zajistit poskytnutí podpory k veškerým programům s otevřeným kódem, které jsou
součástí Plnění, tj. povinnost Dodavatele zajistit poskytování nejnovějších verzí programů s
otevřeným kódem a dalších služeb v souladu se standardními licenčními podmínkami programů s
otevřeným kódem, a to alespoň na dobu trvání této Smlouvy. Ustanovení čl. 7 ZOP se pro
programy s otevřeným kódem či jejich části, které jsou distribuovány pod FOSS licencemi, použije
obdobně.

6.7.3. Dodavatel prohlašuje, že je oprávněn udělit Objednateli veškerá oprávnění v souladu s tímto
článkem ZOP, má k takovému udělení veškeré potřebné souhlasy a jejich udělením Objednateli
ani užíváním Plnění Objednatelem či uživateli Objednatele nebudou porušena práva duševního
vlastnictví třetí osoby. Dodavatel odpovídá Objednateli za zajištění všech nezbytných oprávnění a
souhlasů autora či autorů Software či Standardního Software k oprávněním udělovaným
Objednateli dle tohoto článku ZOP. Dodavatel se zavazuje na výzvu Objednatele poskytnout
Objednateli o zajištění oprávnění a veškerých souhlasů dle tohoto článku ZOP písemné prohlášení
a tyto skutečnosti prokázat.

13/33
6.7.4. 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 Plnění Objednatelem, se Dodavatel zavazuje přijmout taková
opatření, aby Objednatel byl Plnění oprávněn nerušeně užívat, a to zejména zajistit pro
Objednatele udělení oprávnění v rozsahu dle tohoto článku ZOP bez dalších nákladů a požadavků
na úplatu od Objednatele.

6.7.5. 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 Plnění, je Dodavatel povinen nahradit Objednateli veškerou újmu takto způsobenou,
jakož i účelné náklady vynaložené na obranu práv Objednatele. Dodavatel 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 ZOP, zejména mu poskytnout všechny podklady, informace a
vysvětlení k prokázání neoprávněnosti nároku třetí strany.

6.7.6. V případě nároku dle předchozího odst. 6.7.5 ZOP, nebo je-li důvodné předpokládat, že takový
nárok bude uplatněn, zajistí Dodavatel Objednateli možnost dále příslušný výstup užívat bez
nároku na úplatu nad rámec sjednaný ve Smlouvě.

6.7.7. Spolu se Standardním Software, je-li součástí Plnění, musí být Objednateli vždy předána kompletní
Dokumentace, tj. zejména uživatelská, administrátorská, provozní dokumentace a dokumentace
jeho API.

7. ZDROJOVÝ KÓD A DOKUMENTACE
7.1.
7.2. Zdrojový kód bude předáván Objednateli na datovém nosiči společně s předáním výstupu z Plnění
7.3. pro účely zahájení Akceptačního řízení, nebo za podmínek stanovených ve Smlouvě, zejména
pokud bude smluvní vztah ukončen bez provedení Akceptačního řízení.
7.4.
7.5. Na datovém nosiči dat musí být viditelně označen „Zdrojový kód“ s označením části Modifikace a
jeho verze a den předání Zdrojového kódu. O předání nosiče dat bude oběma Smluvními stranami
sepsán a podepsán písemný předávací protokol.

Povinnost Dodavatele předávat Zdrojový kód se přiměřeně použije i pro jakékoliv opravy, změny,
doplnění, upgrade nebo update Zdrojového kódu v rámci následného provádění Plnění anebo v
rámci záručních oprav. Zdrojový kód musí obsahovat podrobný popis a komentář každého zásahu
do Zdrojového kódu.

Objednatel nebude v průběhu provádění Plnění sám anebo prostřednictvím jiných osob zasahovat
do Zdrojového kódu nasazeného anebo fungujícího v Produkčním prostředí či Testovacím
prostředí.

Dodavatel je povinen předat Objednateli příslušnou Dokumentaci a Zdrojový kód ve standardní
podobě (to nejméně v kvalitě obvyklé pro open source projekty), vždy obsahující následující:

a. Kompletní Zdrojové kódy celého díla.

b. Uživatelskou příručku obsahující konkrétní popis uživatelského prostředí, funkcí a postupů

pro zaškolení zaměstnanců.

c. Administrátorskou příručku, popisující všechny parametry, které lze konfigurovat a popis

dopadů změny konfigurace do systému.

d. Technickou dokumentaci systému, pakliže se jedná o vícevrstvou architekturu, popis každé

vrstvy zvlášť:

i. Datová vrstva – popis datové vrstvy, čili tabulek v databázi včetně vazeb mezi

tabulkami a včetně E-R schémat.

ii. Aplikační vrstva – popis jádra systému, jeho funkcí, služeb a rozhraní.

Dokumentace musí obsahovat kompletní popis architektury jádra systému, výčet a

podrobný popis všech jeho funkcí, přehled a popis služeb, které jádro poskytuje

dalším komponentám systému, modulům a knihovnám.

iii. Prezentační vrstva – Dokumentace systému musí obsahovat drátové modely všech

obrazovek uživatelského rozhraní včetně popisu funkcí prvků každé obrazovky.

e. Popis konfigurace provozního prostředí systému (serverová strana i klientská strana).

14/33
f. Dokumentace musí obsahovat soupis všech požadavků na nastavení hardwarových a

softwarových komponent běhového prostředí jako jsou:

i. mapování souborových systémů;

ii. požadavky na operační paměť a procesory;

iii. konfigurační parametry jednotlivých podpůrných Softwarových prostředků (např.

specifika pro nastavení databáze, aplikačního serveru, webového serveru apod.).

g. Objednatel požaduje, aby tato Dokumentace byla ve formátech XML DocBook (zdrojové) a

PDF (export z XML zdroje pro snadnou distribuci uživatelům) nebo případně v jiném

formátu, který Objednatel schválí po vzájemné dohodě s Dodavatelem. Všechny

Dokumentace musí být verzované, opatřené seznamem autorů, přehledem změn

jednotlivých verzí a musí být obsahově úplné pro tu část systému, kterou popisují.

h. Řešení musí obsahovat návod na používání systému (uživatelský manuál) a popis systému

– jeho vlastností, strukturu projektu, použité technologie (technická dokumentace).

Součástí řešení je i Dokumentace a automaticky generovaná dokumentace (Javadoc).

Součástí Dokumentace musí být zip archiv se zdrojovými soubory řešení a

programátorskou dokumentací.

7.6. V případě jakýchkoli pochybností o správnosti předání Zdrojového kódu se bude uvedené
posuzovat podle svého účelu, tedy zejména následné možnosti provádět samostatně či
prostřednictvím třetích osob opravy, změny, doplnění, upgrady nebo updaty Zdrojového kódu. Za
nesprávné předání se přitom považuje takové předání, které v důsledku vede ke znemožnění či
podstatnému ztížení práce se Zdrojovým kódem ve výše uvedeném smyslu.

8. AKCEPTAČNÍ ŘÍZENÍ

8.1. Akceptační řízení Předmětu Smlouvy

8.1.1. Předání a převzetí Předmětu Smlouvy (tj. včetně Zdrojových kódů a Dokumentace) probíhá na
základě Akceptačního řízení, tj. postupným provedením akceptačních procesů a podepsáním
Akceptačního protokolu. Je-li Předmět Smlouvy rozdělen na části, použije se tento článek obdobně
pro každou část, nestanoví-li Smlouva jinak. Jsou-li součástí Předmětu Smlouvy Služby nebo
Paušální služby, použijí se, nestanoví-li Smlouva jinak, pro Služby ustanovení odst. 8.2 ZOP a pro
Paušální služby ustanovení odst. 8.3 ZOP.

8.1.2. Akceptační řízení zahrnuje porovnání skutečných vlastností a funkcionalit s Akceptačními kritérii.

8.1.3. Nestanoví-li Smlouva či její přílohy Akceptační kritéria, rozumí se jimi:

a. vlastnosti a funkcionality uvedené ve specifikaci plnění určené Objednatelem, která je

součástí Smlouvy, a dále vlastnosti a funkcionality uvedené ve specifikaci plnění

Dodavatele či návrhu řešení (jsou-li takové), která je součástí Smlouvy, a

b. požadavky na Zdrojové kódy a Dokumentaci dle čl. 7 ZOP.

8.1.4. Dodavatel je povinen písemně informovat Objednatele minimálně se sedmi denním předstihem o
termínu předání Předmětu Smlouvy či její části, nedohodnou-li se strany jinak.

8.1.5. Dodavatel předá Objednateli Předmět Smlouvy k realizaci Akceptačního řízení. Akceptační řízení
může být zahájeno pouze v případě, že Předmět Smlouvy byl Dodavatelem skutečně předán
Objednateli, a ten se s ním mohl seznámit. Objednatel na žádost Dodavatele bez zbytečného
odkladu potvrdí převzetí Předmětu Smlouvy k Akceptačnímu řízení v Helpdesku, e-mailem, anebo
jiným dohodnutým způsobem. Potvrzením převzetí Díla k Akceptačnímu řízení ve smyslu tohoto
odstavce je zahájeno Akceptační řízení.

8.1.6. Předmět Smlouvy je způsobilý k akceptaci Objednatelem, pokud:

a. splňuje Akceptační kritéria a současně nevykazuje žádnou Vadu kategorie A, B a C či jiné zjevné

vady (zejména vady, pro které není vhodné dělení Vad dle ZOP -> např. Některé vady Hardware

jsou-li součástí plnění), pak Objednatel vyznačí na Akceptačním protokolu „Akceptováno“; nebo

b. splňuje Akceptační kritéria a současně nevykazuje žádnou Vadu kategorie A, B a současně

nemá více než:

15/33
i. 30 Vad kategorie C nebo drobných vad, jež nebrání řádnému užívání Předmětu

Smlouvy, je-li předmětem akceptace vytvoření Software či Dokumentace či

vytvoření části Software či Dokumentace

ii. 10 Vad kategorie C nebo drobných vad, jež nebrání řádnému užívání Předmětu

Smlouvy, nejde-li o případ uvedený v odst. 8.1.6 písm. b. i.

pak Objednatel vyznačí na Akceptačním protokolu „Akceptováno s výhradou“.

8.1.7. V jiných případech než dle odst. 8.1.6 ZOP vyznačí Objednatel na Akceptačním protokolu
„Neakceptováno“.

8.1.8. Nedohodnou-li se Smluvní strany jinak, připraví Dodavatel návrh Akceptačního protokolu, který
musí obsahovat minimálně:

a. označení Smluvních stran a odkaz na Smlouvu,

b. seznam Akceptačních kritérií společně s vedlejším sloupcem pro možnost vyznačení, zda

Předmět Smlouvy splňuje příslušné Akceptační kritérium (např. ano/ne)

c. tabulku pro možnost vepsání zjištěných Vad včetně možnosti uvedení, o jakou Vadu se

jedná (A/B/C),

d. tabulku pro možnost vepsání dalších zjištěných vad,

e. prostor pro závěrečné hodnocení (např. formou výběru z kolonek „Akceptováno“,

„Akceptováno s výhradou“, „Neakceptováno“) a

f. podpisové doložky pro oprávněné osoby za Smluvní strany.

8.1.9. Objednatel je povinen do 30 kalendářních dnů (v případě, že lhůta pro plnění akceptované části
byla kratší než 60 kalendářních dnů, pak do 14 kalednářních dnů, nikdy však déle než činí polovina
lhůty pro plnění) ode dne zahájení Akceptačního řízení posoudit Předmět Smlouvy postupem dle
odst. 8.1.2 ZOP a v případě dle odst. 8.1.6 ZOP podepsat Akceptační protokol a vyznačit na něm
„Akceptováno“, nebo „Akceptováno s výhradou“ včetně vyznačení Vad/y či vad/y. V opačném
případě je Objednatel povinen ve výše uvedené lhůtě podepsat Akceptační protokol společně
s vyznačením „Neakceptováno“ včetně vyznačení nesplněných Akceptačních kritérií nebo
vyznačení Vad/y a jejich/její kategorizace (A, B nebo C) nebo vyznačení dalších vad.

8.1.10. Okamžikem podpisu Akceptační protokolu společně s vyznačením „Akceptováno“, nebo
„Akceptováno s výhradou“ je Předmět Smlouvy proveden.

8.1.11. Podpis Akceptačního protokolu s vyznačením „Akceptováno s výhradou“ nezbavuje
odpovědnosti Dodavatele odstranit vyznačené Vady či vady. Dodavatel je povinen takové Vady či
vady odstranit ve lhůtě určené Objednatelem, jinak do třiceti (30) kalendářních dnů od podpisu
Akceptačního protokolu s vyznačením „Akceptováno s výhradou“. Neodstranění Dodavatel
Vady či vady ve lhůtě dle tohoto odstavce, jedná se porušení této Smlouvy podstatným způsobem.
Do doby odstranění vyznačených Vad či vad dle tohoto odstavce nezaplatí Objednatel Dodavateli
část Ceny (či ceny příslušné části Plnění, je-li plněno po částech) odpovídající její padesáti (50)
procentní výši. Objednatel není v takovém případě v prodlení se zaplacením části Ceny (či ceny
příslušné části Plnění, je-li plněno po částech) dle předchozí věty. Pro účely ověření splnění
povinností Dodavatele dle tohoto odstavce, je Dodavatel Objednateli povinen prokázat, že Plnění
již nemá Vady či vady. Povinnost odstranit Vady či vady dle tohoto odstavce není splněna,
neodstranil-li Dodavatel Vady či vady nebo objeví-li se v průběhu ověření:

a. nové Vady či vady, které vznikly v souvislosti s odstraňováním původních Vad či vad, nebo

b. Vady či vady, které v důsledku existence původních Vad či vad nebylo možné

v Akceptačním řízení odhalit, nebo které bylo možno odhalit pouze s výraznými obtížemi.

8.1.12. V případě neakceptování Předmětu Smlouvy vyznačením na Akceptačním protokolu
„Neakceptováno“ se Dodavatel zavazuje odstranit nesplněná Akceptační kritéria a Vady uvedené
v Akceptačním protokolu ve lhůtách výslovně stanovených v Akceptačním protokolu
Objednatelem, a pokud nejsou takové, pak lhůtách přiměřených. Do odstranění nedostatků
bránících akceptování není Předmět Smlouvy proveden. Po odstranění nedostatků uvedených v

16/33
Akceptačním protokolu Dodavatel opětovně předá Předmět Smlouvy Objednateli k dalšímu kolu
Akceptačního řízení a Objednatel postupuje obdobně podle odst. 8.1.5 ZOP.

8.2. Akceptační řízení ve vztahu ke Službám

8.2.1. Řádné provedení Služeb bude Stranami písemně potvrzeno podpisem Akceptačního protokolu po
ukončení Akceptačního řízení obdobně dle odst. 8.1 ZOP (s výjimkou odst. 8.1.3 ZOP). Pro účely
akceptace Služeb se Předmětem Smlouvy rozumí příslušný výstup ze Služeb (např. rozvoj
Software). Strany jsou oprávněny zkrátit lhůty Akceptačního řízení ve smyslu odst. 8.1 ZOP v dílčí
smlouvě uzavřené na základě Smlouvy. Nestanoví-li dílčí smlouva Akceptační kritéria Služby,
rozumí se jimi:

a. vlastnosti a funkcionality uvedené ve specifikaci plnění Objednatele, která je součástí dílčí

smlouvy uzavřené na základě Smlouvy, a dále vlastnosti a funkcionality uvedené ve

specifikaci plnění Dodavatele (je-li taková), která je součástí dílčí smlouvy, a

b. požadavky na Zdrojové kódy a Dokumentaci dle čl. 7 ZOP.

8.2.2. Jsou-li Služby plněny po částech, použijí se ustanovení pro Akceptační řízení ve vztahu ke Službám
přiměřeně vždy na každou takovou dílčí část výstupu ze Služeb, nedohodnou-li se Strany výslovně
jinak.

8.2.3. Akceptační řízení se neprovádí u Služeb, které z povahy věci nepodléhají Akceptačnímu řízení
(např. konzultace apod.). Služby musí být v souladu s dílčí smlouvou a přílohou č. 1 této Smlouvy.
Uvedeným postupem nejsou dotčena práva z vadného plnění ve vztahu k takovým Službám.

8.3. Akceptační řízení ve vztahu k Paušálním službám

8.3.1. Řádné provádění Paušálních služeb bude každý měsíc potvrzováno podpisem výkazu Paušálních
služeb za bezprostředně předcházející měsíc. Podpisem výkazu Paušálních služeb Objednatelem
jsou Paušální služby za příslušný měsíc akceptovány/provedeny. Objednatel není povinen
podepsat výkaz Paušálních služeb, nebyly-li jednotlivé Paušální služby v příslušném měsíci řádně
provedeny (jedná se např. o Paušální služby, u nichž konec lhůty pro splnění - např. doba pro
vyřešení Incidentu – spadá do příslušného měsíce).

8.3.2. Návrh výkazu dle předchozího odstavce připraví Dodavatel. Výkaz musí obsahovat soupis
provedených Paušálních služeb za bezprostředně předcházející měsíc a soupis dosud
neukončených činností Paušálních služeb. Výkaz Paušálních služeb je Dodavatel povinen doručit
nejpozději do deseti (10) kalendářních dnů po skončení měsíce, ve které byly služby poskytnuty.

8.4. Akceptační řízení ve vztahu ke školení

8.4.1. Dokladem o řádném provedení školení je prezenční listina podepsána účastníky školení, případně
vydání certifikátu, mělo-li být školení zakončené vydáním certifikátu.

8.4.2. Vznikají-li pro školení školící materiály, akceptují se v akceptačním řízení odst. 8.1 ZOP se použije
přiměřeně. V takovém případě je školení řádně provedené dnem, v němž je akceptován poslední
požadovaný výstup.

8.4.3. V případě, že předmětem školení je hands-on školení, je školení řádně provedeno akceptací
výstupu, který byl předmětem hands-on školení dle odst. 8.1 ZOP.

8.5. Akceptace ve vztahu k Hardware

8.5.1. Je-li předmětem Smlouvy či dílčí části, jež je určena k akceptaci pouze dodání Hardware, použije
se pro akceptaci odstavec 8.5 ZOP.

8.5.2. Řádné dodání Hardware se předává a přebírá na základě předávacího protokolu podepsaného
odpovědnými zástupci smluvních stran.

8.5.3. Nestanoví-li Smlouva či její přílohy jinak, Objednatel ověřuje v rámci akceptace Hardware:

a. parametry, vlastnosti a funkcionality uvedené ve specifikaci plnění Objednatele, která je

součástí Smlouvy, a dále vlastnosti a funkcionality uvedené ve specifikaci plnění

Dodavatele (je-li taková), která je součástí Smlouvy;

b. příslušenství a dokumentaci, jež mělo být dodáno spolu s Hardware.

17/33
9. ŠKOLENÍ
9.1.
Vyplývá-li ze Smlouvy Dodavateli povinnost poskytnout školení, aniž jsou blíže určeny jeho
9.2. podmínky, zavazuje se Dodavatel poskytnout školení osobám určeným Objednatelem pomocí
9.3. metod výkladu (zejména popis jednotlivých prvků a funkcionalit Předmětu Smlouvy ve vztahu
k jeho užívání), praktických ukázek obsluhy Předmětu Smlouvy a zodpovězení dotazů školených
osob tak, aby tyto osoby byly na základě provedeného školení ve vztahu ke svým rolím nebo
pracovnímu zařazení (dle sdělení Objednatele) schopné plně porozumět svým odpovědnostem při
obsluze Předmětu Smlouvy, provádět obsluhu v souvislosti se svou rolí nebo pracovním zařazením
samostatně, a přitom minimalizovat riziko chybné obsluhy nebo závad na Předmětu Smlouvy.

Dodavatel provede zaškolení příslušných osob určených Objednatelem v termínu dle Smlouvy, a
pokud takový termín není, pak v termínu určeném Objednatelem po dohodě s Dodavatelem.

Dodavatel je dále povinen provést v přiměřeném rozsahu školení příslušných zaměstnanců
Dodavatele a dalších osob podílejících se na poskytování Plnění dle Smlouvy za účelem splnění
povinností dle čl. 20. ZOP. Tuto skutečnost je povinen na vyžádání Objednateli prokázat.

10. HELPDESK

10.1. Dodavatel se zavazuje:

10.1.1. nejpozději v den účinnosti Smlouvy založit a po celou dobu trvání Smlouvy udržovat v provozu
Helpdesk (včetně úhrady případných licenčních poplatků za aplikaci Helpdesk) a udělit náležitá
oprávnění k přístupu do Helpdesku, a to v počtu přístupů pro Ohlašovatele dle určení Objednatele.
Helpdesk bude fungovat prostřednictvím webové adresy;

nebo

10.1.2. po celou dobu trvání Smlouvy užívat Helpdesk provozovaný Objednatelem.

10.2. Provozovatele Helpdesku stanoví Smlouva. Pokud Smlouva provozovatele Helpdesku nestanoví,
má se za to, že provozovatelem Helpdesku je Dodavatel. V případě, že provozovatelem bude
Objednatel, poskytne Dodavateli nezbytnou součinnost k řádnému užívání Helpdesku včetně
případného poskytnutí licencí.

10.3. Dodavatel se zavazuje zajistit Helpdesk prostřednictvím přímého přístupu do Helpdesku na webové
adrese určené Dodavatelem/Objednatelem dle provozních podmínek aplikace Helpdesk, případně
prostřednictvím přímého datového propojení Helpdesků Objednatele a Dodavatele, a to v jednom
z následujících režimů, který je vymezen ve Smlouvě:

a. Režim 1:

7x24, tj. dvacet čtyři (24) hodin sedm (7) dní v týdnu.

b. Režim 2:

7x12, tj. dvanáct (12) hodin sedm (7) dní v týdnu.

c. Režim 3:

5x12, tj. dvanáct (12) hodin pět (5) dní v týdnu

d. Režim 4:

5×8, tj. osm (8) hodin pět (5) dní v týdnu.

10.4. Nestanoví-li Smlouva jinak, počíná časový rozsah dle zvoleného režimu dle odst. 10.3 ZOP (s
výjimkou režimu 1) shodně s časový rozsahem dle zvoleného Servisního modelu dle odst. 12.2
ZOP (např. pokud doba Servisního modelu začíná každý pracovní den v 7:00, provoz Helpdesk
v rámci příslušného režimu začíná rovněž v 7:00).

10.5. Helpdesk zahrnuje mimo jiné příjem a evidenci Incidentů a Požadavků, oznámení o potřebě
součinnosti Objednatele a dalších zpráv, potvrzování jejich přijetí, předávání jednotlivých úkolů
odpovědným osobám, sledování stavu, průběhu a procesu prací a dalších zpráv, informování o
stavu řešení, vytváření přehledů a statistik, a to přes přehledné webové rozhraní. Je-li Helpdesk
provozován Dodavatelem musí být zabezpečen tak, aby odpovídal požadavkům vyplývajícím ze
ZKB a Interních předpisů. Výstupem z Helpdesku je záznam o veškerých úkonech Helpdesku ve

18/33
10.6. formě přehledného logu, jež umožňuje vyhledávání a uchovávání záznamů tak, aby byly naplněny
10.7. požadavky ZKB a Interních předpisů na takové záznamy.

Helpdesk bude dostupný pouze pro Objednatele a Ohlašovatele.

Nestanoví-li Smlouva jinak, je Dodavatel povinen nezávisle na Helpdesk mít nejpozději k okamžiku
nabytí účinnosti Smlouvy zřízenou elektronickou adresu a telefonní linku a tuto adresu a telefonní
číslo linky sdělit Objednali, a to vše pro účely min. příjmu oznámení Incidentů a Požadavků,
vznášení dotazů k Plnění, získávání odpovědí ve vztahu k Plnění a pro další komunikace dle
Smlouvy. Doba provozu elektronické adresy a telefonní linky bude odpovídat zvolenému režimu
Helpdesk dle odst. 10.3 ZOP.

11. NAHLÁŠENÍ INCIDENTU

11.1. Hlášení o Incidentu Dodavateli bude provedeno Ohlašovatelem bezodkladně po zjištění Incidentu,
a to přímým zadáním Incidentu do Helpdesku (vytvoření ticketu v Helpdesku, tj. okamžikem, jímž
se ticket zpřístupní Dodavateli), odesláním e-mailu nebo telefonátem na kontaktní číslo dle odst.
10.7 ZOP, přičemž Ohlašovatel je povinen uvést popis Incidentu, a to v následujícím rozsahu:

a. krátký a rámcově výstižný název Incidentu;

b. identifikace části Předmětu Plnění, které se Incident týká;

c. určení prostředí (Testovací prostředí, Produkční prostředí);

d. detailní popis Incidentu, průvodních jevů a všech významných souvisejících informací;

e. kategorii Incidentu (A, B, C);

f. identifikaci Ohlašovatele.

11.2. V případě, že některá z náležitosti dle odst. 11.1. ZOP chybí nebo je nedostatečná, může si
Dodavatel vyžádat její doplnění od Ohlašovatele; tato skutečnost však nemá vliv na určení Času
nahlášení Incidentu, ledaže bez tohoto doplnění hlášení Incidentu postrádá informaci natolik
podstatnou, že bez ní objektivně nelze přistoupit k řešení Incidentu a Dodavatel o této skutečnosti
Objednatele vyrozuměl, a to nejpozději v době určené na zpracování Incidentu dle určeného
Servisního modelu dle čl. 12 ZOP, v takovém případě je Incident dle 11.3 ZOP nahlášen
okamžikem doplnění požadované informace.

11.3. Je-li Incident nahlašován prostřednictvím Helpdesku, pak se za Čas nahlášení Incidentu považuje
čas vytvoření ticketu v Helpdesku. Je-li Incident nahlašován písemně na e-mailovou adresu, pak
se za Čas nahlášení Incidentu považuje čas odeslání e-mailu z e-mailového serveru Ohlašovatele,
nebo v případě hlášení Incidentu telefonicky čas ukončení telefonického hovoru. Dodavatel je
povinen prokazatelným způsobem bezodkladně potvrdit přijetí nahlášení Incidentu, a to vždy
prostřednictvím Helpdesku. Nepotvrdí-li Dodavatel přijetí Incidentu, nemá to vliv na Čas nahlášení
Incidentu.

11.4. Je-li je Incident nahlášen mimo časový rozsah Servisního modelu, avšak v rámci časového rozsahu
Helpdesku dle zvoleného režimu dle odst. 10.3 ZOP, považuje se za Čas nahlášení Incidentu
okamžik začátku nejbližšího následujícího časového rozsahu Servisního modelu.

11.5. Dodavatel se zavazuje po dobu poskytování Plnění evidovat všechny nahlášené Incidenty a způsob
jejich řešení, včetně časových údajů o průběhu řešení jednotlivých Incidentů ve Výkazech.

11.6. Není-li v Servisní smlouvě, jejích přílohách jinak, ustanovení článku 11. ZOP se použijí přiměřeně
i na nahlášení a evidování Požadavků.

11.6.1. Dodavatel se zavazuje bezodkladně po nahlášení Incidentu Ohlašovatelem informovat o Incidentu
Objednatele a poskytnout mu veškerou potřebnou součinnost, aby Objednatel mohl nejpozději do
24 hodin po zjištění Incidentu Ohlašovatelem předložit NÚKIB tzv. prvotní hlášení, v němž uvede
své identifikační údaje, základní údaje o kybernetickém bezpečnostním incidentu,
a zda se domnívá, že byl kybernetický bezpečnostní incident způsoben nezákonným zásahem
nebo že by mohl mít přeshraniční dopad.

11.6.2. Bude-li se jednat o Incident s významným dopadem na kybernetický prostor státu, zavazuje se
Dodavatel poskytnout Objednateli veškerou potřebnou součinnost, aby Objednatel mohl předložit
příslušným orgánům:

19/33
a. bez zbytečného odkladu, nejpozději do 72 hodin po zjištění Incidentu oznámení, v němž

aktualizuje informace z prvotního hlášení, předloží prvotní posouzení Incidentu a uvede

dopad a indikátory kompromitace, pokud jsou k dispozici;

b. na výzvu NÚKIB nebo Národního CERT průběžnou zprávu o podstatných změnách stavu

zvládání Incidentu, a

c. nejpozději do 30 dnů ode dne předložení oznámení podle písmene a) závěrečnou zprávu

o vyřešení Incidentu; nebo aby v případě, že po uplynutí uvedené lhůty Incident stále trvá

mohl Objednatel předložit bez zbytečného odkladu po uplynutí lhůty průběžnou zprávu

o aktuálním stavu zvládání Incidentu, a poté nejpozději do 30 dnů ode dne, kdy došlo

k vyřešení Incidentu závěrečnou zprávu o vyřešení kybernetického bezpečnostního

incidentu.

12. SERVISNÍ MODELY
12.1.
Servisní model představuje standardizovaný model provozu a podpory aplikace, systému nebo
12.2. instance služby.

Pokud je součástí Smlouvy zajištění provozu a podpory Softwaru nebo Hardwaru, je ve Smlouvě
vymezen jeden z níže uvedených Servisních modelů:

Servisní model Dostupnost Doba provozu Doba Doba Doba RTO RPO Doba Doba Doba
zpraco vyřešení vyřešení zpracování vyřešení vyřešení
vání Incidentů Incidentů Požadavku Požadavku Požadavku
Incide kategorie kategorie kategorie kategorie
ntu A B A B

A1 Kritický 99.5% 7x24 (0-24) 1 hod 2 hod 2 hod 4 hod < 5 min 1 PD 1 PD 3 PD

A2 Kritický 99.5% 7x12 (6-18) 1 hod 2 hod 2 hod 4 hod < 5 min 1 PD 1 PD 3 PD

A3 Kritický 99.5% 5x8 (7-15) 1 hod 2 hod 2 hod 4 hod < 5 min 1 PD 1 PD 3 PD

A4 Kritický 99.5% 7x24 (0-24) 1 hod 4 hod 12 hod 4 hod < 5 min 1 PD 2 PD 5 PD

A5 Kritický 99.5% 5x8 (7-15) 1 hod 4 hod 12 hod 4 hod < 5 min 1 PD 2 PD 5 PD

B1 Závažný 98.0% 7x24 (0-24) 1 PD 2 PD 3 PD 48 hod 30 min 2 PD 3 PD 5 PD

B2 Závažný 98.0% 7x12 (6-18) 1 PD 2 PD 3 PD 48 hod 30 min 2 PD 3 PD 5 PD

B3 Závažný 98.0% 5x8 (7-15) 1 PD 2 PD 3 PD 48 hod 30 min 2 PD 3 PD 5 PD

C1 Normální 97.0% 5x12 (6-18) 1 PD 3 PD 6 PD 96 hod 24 hod 3 PD 7 PD 10 PD

C2 Normální 97.0% 5x8 (7-15) 1 PD 3 PD 6 PD 96 hod 24 hod 3 PD 7 PD 10 PD

D Minoritní 94.0% 5x8 (7-15) 2 PD 10 PD 14 PD 96 hod 24 hod 5 PD 10 PD 14 PD

E1 Customizovaný

E2 Customizovaný

12.3. Doba řešení Incidentu a Požadavku kategorie C je pro veškeré Servisní modely stanovena na 15
12.4. PD.

Do měření úrovně Dostupnosti (Software) nejsou započítávány:

a. dočasné vyřazení Softwaru z provozu na základě předchozí dohody Objednatele a

Dodavatele (odstávka),

20/33
b. pravidelná vyřazení Softwaru z provozu Dodavatelem v časech sjednaných ve Smlouvě

nebo její příloze (servisní okna),

c. smluvními stranami předem dohodnutý časový úsek za účelem instalace upgradu,

d. výpadky Softwaru způsobené Objednatelem přímo v důsledku jím provedených zásahů do

Softwaru, které nebyly Dodavatelem předem schváleny,

e. skutečnosti ve vztahu k Hardware dle odst. 12.9 ZOP za podmínek, že je takový Hardware

součástí Plnění a současně je nezbytný pro fungování Software.

12.5. Nedostupnost Softwaru dle odst. 12.4. ZOP se nepovažuje za nedosažení sjednaných parametrů
12.6. Dostupnosti dle Smlouvy a nebude započítána do výpočtu dle odst. 12.6. a 12.7. ZOP.

Nestanoví-li Smlouva jinak, bude Dostupnost Software měřena na základě následujícího vzorce:

(%) = − ý × 100

12.7. Doba výpadku Softwaru je časový úsek z Doby provozu v hodinách, kdy je služba nedostupná, a
počítá se podle následujícího vzorce:

ý =

kde:

∑ je celková doba všech výpadků Softwaru za vyhodnocované období

Ti je doba jednotlivého výpadku Softwaru

n je počet všech výpadků

12.8. Doba Provozu Softwaru definovaná pro účely tohoto článku je celková doba provozu Softwaru
v hodinách za vyhodnocované období, kterým je kalendářní měsíc.

12.9. Do měření úrovně Dostupnosti (Hardware) nejsou započítávány:

a. dočasná vyřazení Hardware z provozu na základě předchozí dohody Objednatele a

Dodavatele (odstávka),

b. pravidelná vyřazení Hardware z provozu Dodavatelem v časech sjednaných ve Smlouvě

nebo její příloze (servisní okna)

c. výpadky Hardware způsobené Objednatelem přímo v důsledku jím provedených zásahů do

Hardware, které nebyly Dodavatelem předem schváleny

12.10. Ustanovení odst. 12.5. až 12.8 ZOP se použijí obdobně s tím, že odkaz v odst. 12.5 ZOP na odst.
12.4 ZOP se nahrazuje odkazem na odst. 12.9 ZOP a slovo Software se nahrazují slovem
Hardware.

13. ÚČAST PODDODAVATELŮ
13.1.
Poddodavatele, jejichž prostřednictvím Dodavatel prokazoval kvalifikaci ve Veřejné zakázce, je
13.2. Dodavatel povinen využívat při Plnění Smlouvy po celou dobu jejího trvání v rozsahu, v jakém jimi
prokazoval kvalifikaci. Poddodavatele, jimiž Dodavatel prokazoval kvalifikaci ve Veřejné zakázce,
13.3. lze vyměnit pouze s předchozím listinným souhlasem Objednatele, který může být dán výlučně za
předpokladu, že tyto osoby budou nahrazeny osobami splňujícími kvalifikaci požadovanou ve
Veřejné zakázce ve stejném rozsahu jako nahrazované osoby.

Dodavatel se zavazuje, že při poskytování Plnění pro Objednatele budou všichni Poddodavatelé,
které Dodavatel využívá k poskytnutí Plnění dle Smlouvy, dodržovat veškeré požadavky vyplývající
ze Smlouvy a Příloh Smlouvy. Dodavatel odpovídá za to, že jeho Poddodavatelé nebudou jednat
v rozporu s ujednáními Smlouvy a jejími Přílohami, kterou mezi sebou uzavřeli Dodavatel a
Objednatel.

Významný dodavatel je oprávněn využít k Plnění dle Smlouvy Poddodavatele neuvedené ve
Smlouvě jen v případě, že to Smlouva výslovně připouští, a to za podmínek v ní uvedených.
Nestanoví-li Smlouva jinak, podléhají jednotliví Poddodavatelé Významného dodavatele

21/33
13.4. předchozímu písemnému schválení ze strany Objednatele. Dodavatel může ke schválení navrhnout
13.5. nebo do Plnění Smlouvy zapojit pouze takové Poddodavatele, kteří nejsou v rozporu s požadavky
Objednatele na Významného dodavatele.

Dodavatel nesmí zapojit k Plnění dle Smlouvy Poddodavatele, bylo-li by tím porušeno opatření
obecné povahy vydané ze strany NÚKIB.

Dodavatel je povinen informovat Objednatele předem o zapojení Poddodavatelů a poskytnout mu
veškeré potřebné údaje, zejm. identifikační údaje Poddodavatelů, aby Objednatel mohl splnit svoje
povinnosti stanovené právními předpisy v souvislosti s prověřováním dodavatelského řetězce,
zejm. informační povinnost vůči NÚKIB.

14. REALIZAČNÍ TÝM
14.1.
Pokud je takový požadavek součástí Zadávací dokumentace, je Dodavatel povinen předat
14.2. Objednateli seznam osob, které budou členy Realizačního týmu, který se bude podílet na Plnění
14.3. dle Smlouvy. Členy Realizačního týmu lze měnit pouze s předchozím listinným souhlasem
14.4. Objednatele, který může být dán výlučně za předpokladu, že tyto osoby budou nahrazeny osobami
14.5. splňujícími kvalifikaci požadovanou ve Veřejné zakázce ve stejném rozsahu jako nahrazované
osoby. V případě, že dochází ke změně člena realizačního týmu, který byl v zadávacím řízení
hodnocen, je nezbytné, aby takového člena realizačního týmu nahradila osoba, jež by dosáhla v
rámci hodnocení stejného či lepšího výsledku než osoba nahrazovaná. Při změně Realizačního
týmu není nutné uzavírat listinný dodatek ke Smlouvě a Dodavatel je povinen vypracovat a předat
Objednateli v listinné podobě aktualizované znění seznamu členů Realizačního týmu. Tento článek
se týká pouze Veřejných zakázek, které požadují provádění Plnění prostřednictvím Realizačního
týmu.

Dodavatel se zavazuje provádět Plnění prostřednictvím členů Realizačního týmu uvedených
v Příloze Smlouvy Realizační tým tak, aby jednotliví členové Realizačního týmu, kteří jsou
Kvalifikovanými osobami, prováděli činnosti na pozici dle jejich odbornosti (kvalifikace), které
odpovídají tomu, pro jakou pozici prokazovali kvalifikaci v rámci Veřejné zakázky, a v rozsahu,
který takové pozici běžně odpovídá.

Každá Kvalifikovaná osoba musí po celou dobu provádění Plnění splňovat kvalifikaci uvedenou
v nabídce Dodavatele a zároveň minimální technické kvalifikační předpoklady kladené na pozici,
kterou daná osoba zastává dle Zadávací dokumentace.

Nebude-li se Kvalifikovaná osoba řádně podílet na provádění Plnění v rozsahu stanoveném
Smlouvou, např. v důsledku ukončení její spolupráce s Dodavatelem nebo její dlouhodobé absence
(zejména dlouhodobá nemoc pravděpodobně překračující délku jednoho měsíce), je Dodavatel
povinen neprodleně namísto Kvalifikované osoby zahájit provádění Plnění Náhradní Kvalifikovanou
osobou a nejpozději do tří (3) Pracovních dnů ode dne, kdy taková situace nastala, informovat
Objednatele o této skutečnosti.

Pokud Objednatel nesouhlasí s osobou Náhradní Kvalifikované osoby, je oprávněn žádat
Dodavatele o její výměnu za jinou osobu se stejnou kvalifikací navrženou Dodavatelem, čemuž je
Dodavatel povinen vyhovět.

15. KOMUNIKACE STRAN
15.1.
15.2. Objednatel a Dodavatel si pro vzájemnou komunikaci ohledně Smlouvy zvolí kontaktní osoby,
jejichž seznam uvedou ve Smlouvě.
15.3.
15.4. Jsou-li naplněny podmínky odst. 20.1. ZOP, vykonává kontaktní osoba na straně Dodavatele
povinnosti kontaktní osoby pro kybernetickou bezpečnost vyplývající z článku 20. ZOP, nebo je
pro plnění takových povinností Dodavatel povinen určit zvláštní kontaktní osobu ve Smlouvě (v
takovém případě obě Strany zvolí kontaktní osobu pro kybernetickou bezpečnost, která má na
starosti komunikaci týkající se článku 20. ZOP).

Strany si navzájem oznámí jakékoliv změny v kontaktních osobách, přičemž taková změna je
účinná uplynutím sedmého (7.) dne po jejím doručení.

Není-li ve Smlouvě výslovně stanovena jiná forma pro doručování dokumentů anebo jiných
právních jednání, lze takové dokumenty a jednání doručit v elektronické formě na e-mailovou

22/33
adresu příslušné kontaktní osoby, prostřednictvím datové zprávy zaslané v rámci ISDS, anebo v
listinné podobě.

16. NÁHRADA ŠKODY A SMLUVNÍ POKUTY
16.1.
Poruší-li Dodavatel některé ze svých povinností stanovených ve Smlouvě či jejích přílohách,
16.2. zejména pak pokud poruší SLA, resp. stanovený Servisní model dle odst. 12.2. ZOP, je Objednatel
oprávněn požadovat zaplacení smluvní pokuty ve výši stanovené v odst. 16.2. ZOP, pokud nejsou
ve Smlouvě výslovně zakotveny jiné sankce, které vylučují aplikaci odst. 16.2. ZOP. Ustanovení §
2050 Občanského zákoníku se nepoužije. Objednatel je však oprávněn uplatnit po Dodavateli
nárok na náhradu škody pouze do celkové souhrnné výše sta (100) procent Ceny. Pro vyloučení
všech pochybností se limitace dle předchozí věty vztahuje i na souhrnnou výši smluvních pokut.
Tímto není dotčena odpovědnost za škodu způsobenou úmyslně či hrubou nedbalostí.

Objednateli vzniká vůči Dodavateli právo na zaplacení smluvní pokuty:

a. poruší-li Dodavatel svoji povinnost řádně a včas provést Plnění ve výši 0,05 % z Ceny za

každý započatý den prodlení až do řádného splnění této povinnosti. Plnění se považuje pro

účely této smluvní pokuty za řádně a včas provedené i v případě, že bylo akceptováno s

výhradou;

b. poruší-li Dodavatel svoji povinnost řádně a včas provést jakoukoliv část Plnění ve výši 0,05

% z ceny takové části Plnění za každý započatý den prodlení až do řádného splnění této

povinnosti; v případě, že by smluvní pokuty dle odst. 16.2. písm. a. a písm. b. ZOP měly

běžet vůči Dodavateli zároveň, vzniká za takové období Objednateli nárok pouze dle odst.

16.2. písm. a. ZOP. Plnění se považuje pro účely této smluvní pokuty za řádně provedené i

v případě, že bylo akceptováno s výhradou;

c. poruší-li Dodavatel svoji povinnost dle odst. 8.1.11 ZOP ve výši 0,01 % z Ceny (případně

ceny části Plnění, jedná-li se o akceptaci dílčí části Plnění) za každý započatý den prodlení

až do řádného odstranění poslední vytýkané vady ve smyslu odst. 8.1.11 ZOP ;

d. poruší-li Dodavatel povinnost udělit nebo zajistit Objednateli ze strany třetí osoby/třetích

osob udělovaná oprávnění v rozsahu práv duševního vlastnictví ve výši 5 % z Ceny za

každé jednotlivé porušení;

e. poruší-li Dodavatel povinnost řádně a včas předat Objednateli Zdrojový kód a veškerou

související Dokumentaci, ve výši 0,05 % z Ceny za každý započatý den prodlení;

f. poruší-li Dodavatel některou z povinností týkající se účasti Poddodavatelů anebo

Realizačního týmu, ve výši 2 % z Ceny za každé jednotlivé porušení povinnosti;

g. poruší-li Dodavatel svoji povinnost dodržet sjednanou Dobu vyřešení Incidentu, ve výši:

i. 0,01 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané

Doby vyřešení v případě každého Incidentu kategorie A;

ii. 0,01 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané

Doby vyřešení v případě každého Incidentu kategorie B;

iii. 0,005 % z Ceny v případě každé započaté hodiny/den prodlení nad rámec sjednané

Doby vyřešení v případě každého Incidentu kategorie C;

h. v případě prodlení nad rámec sjednané lhůty pro odstranění vad v Produkčním prostředí:

i. Vada kategorie A ve výši 0,01 % z Ceny za každou započatou hodinu/den v případě

každé Vady;

ii. Vada kategorie B ve výši 0,01 % z Ceny za každou započatou hodinu/den v případě

každé Vady;

iii. Vada kategorie C ve výši 0,005 % z Ceny za každou započatou hodinu/den

v případě každé Vady;

i. v případě prodlení nad rámec sjednané lhůty pro odstranění vad v Testovacím prostředí:

23/33
i. Vada kategorie A ve výši 0,05 % z Ceny za každý započatý Pracovní den v případě

každé Vady; a

ii. Vada kategorie B ve výši 0,01 % z Ceny za každý započatý Pracovní den v případě

každé Vady;

j. V případě, že Dodavatel nedodrží Dostupnost stanovenou Servisním modelem dle odst.

12.2. ZOP, ve výši dle tabulky uvedené níže v závislosti na míře nedodržení požadované

Dostupnosti:

Výše poklesu Dostupnosti oproti Výše smluvní pokuty
stanovené Dostupnosti Servisním
modelem je

Do 2 % 10 % z ceny poskytovaného Plnění odpovídající
vyhodnocovanému období dle odst. 12.8 ZOP

Od 2 (včetně) do 5 % 15 % z ceny poskytovaného Plnění odpovídající
vyhodnocovanému období dle odst. 12.8 ZOP

Od 5 (včetně) do 10 % 25 % z ceny poskytovaného Plnění odpovídající
vyhodnocovanému období dle odst. 12.8 ZOP

Od 10 % (včetně) a více 50 % z ceny poskytovaného Plnění odpovídající
vyhodnocovanému období dle odst. 12.8 ZOP

k. v případě prodlení Dodavatele reagovat na Požadavek Objednatele v době řešení Incidentu

uvedeného v odst. 12.2. ZOP ve výši z 0,02 % z Ceny za každý jednotlivý případ;

l. ve výši a za podmínek dle článku 20. ZOP v oblasti kybernetické bezpečnosti;

m. ve výši a za podmínek dle článku 21. ZOP v oblasti ochrany osobních údajů;

n. ve výši a za podmínek dle článku 22. ZOP v oblasti ochrany Důvěrných informací; nebo

o. poruší-li Dodavatel svoji povinnost dle odst. 13.2. ZOP nebo 13.3. ZOP, ve výši 2 % z Ceny

za každé jednotlivé porušení.

16.3. Pro smluvní pokuty stanovené v odst. 16.2. písm. 16.2.g. a 16.2.h. ZOP platí, že je-li lhůta pro
splnění stanovena v hodinách, je smluvní pokuta počítána za každou započatou hodinu, je-li lhůta
16.4. pro splnění stanovena ve dnech či Pracovních dnech, je smluvní pokuta počítána za každý započatý
16.5. den.
16.6.
Zaplacením smluvních pokut není dotčeno právo Objednatele na náhradu Újmy v plném rozsahu.

Smluvní pokuta je splatná do 30 dnů ode dne doručení písemné výzvy Objednatele k jejímu
uhrazení. Objednatel je oprávněn započíst nárok na zaplacení smluvní pokuty, i pokud ještě není
splatný, proti jakémukoliv nároku Dodavatele na peněžité plnění vyplývajícímu ze Smlouvy.

Za každý den prodlení s úhradou Smluvní pokuty je Objednatel oprávněn požadovat po Dodavateli
úhradu úroků z prodlení ve výši stanovené obecně závaznými právními předpisy.

17. ZÁRUKA ZA JAKOST A PRÁVA Z VADNÉHO PLNĚNÍ

17.1. Společná ustanovení

17.1.1. Dodavatel uděluje Objednateli záruku za jakost Plnění a všech jeho částí na dobu dvou (2) let ode
dne akceptace výstupu Plnění.

24/33
17.1.2. Objednatel je oprávněn Vady, které se vyskytnou v průběhu záruční doby, nahlásit Dodavateli bez
zbytečného odkladu od okamžiku, kdy je zjistil. Lhůta bez zbytečného odkladu činí vždy nejméně
devadesát (90) dnů.

17.1.3. Dodavatel odpovídá za vady zjevné, skryté i právní, které měl výstup provádění Plnění v době
akceptace Objednatelem, a dále za ty, které se na něm vyskytnou v záruční době, a zavazuje se,
vedle dalších nároků Objednatele, je bezplatně odstranit.

17.1.4. Dodavatel neodpovídá za vady, pokud byly způsobeny zásahem do takových výstupů Plnění ze
strany Objednatele nebo jím pověřené osoby, případně jiných dodavatelů Objednatele.

17.1.5. Objednatel je povinen oznámit vady Plnění Dodavateli prostřednictvím Helpdesku, nebude-li
Stranami dohodnuto jinak.

17.1.6. Dodavatel neodpovídá za vady Plnění vzniklé:

a. provozováním Díla Objednatelem v rozporu s Dokumentací;

b. neoprávněným nebo neodborným zásahem či nesprávným užitím Díla Objednatelem;

c. vadami IT prostředí Objednatele.

17.2. Záruka vztahující se k Softwaru

17.2.1. Pokud výrobce Standardního Software poskytuje záruku za jakost, pak Dodavatel postupuje
takovou záruku za jakost Objednateli. To nezbavuje Dodavatele povinnosti poskytnout Objednateli
vlastní záruku za jakost ve smyslu tohoto článku.

17.2.2. V době trvání záruční doby je Dodavatel povinen odstraňovat vady ve lhůtách uvedených v tabulce
níže. Lhůty stanovené v hodinách běží pouze v Pracovní dny osm (8) hodin denně v době od 9:00
do 17:00 hodin (režim 5x8). Lhůty stanovené v hodinách se mimo dobu uvedenou v předchozí
větě staví a pokračují dále v běhu během další bezprostředně následující doby počítání. Strany pro
zamezení pochybnostem prohlašují, že toto se netýká lhůt stanovených v Pracovních dnech ani
počítání doby prodlení v rámci výpočtu smluvních pokut.

Produkční prostředí Lhůta k odstranění počítaná od nahlášení vady
Kategorie vady Objednatelem
do 4 hodin1
Vada kategorie A – kritická do 17:00 hod. třetího Pracovního dne od nahlášení vady2
Vada kategorie B – střední
Vada kategorie C – nízká do 17:00 hod. pátého Pracovního dne od nahlášení vady3

Testovací prostředí Lhůta k odstranění počítaná od nahlášení vady
Kategorie vady Objednatelem
do 17:00 hod. druhého Pracovního dne od nahlášení vady4
Vada kategorie A – kritická do 17:00 hod. pátého Pracovního dne od nahlášení vady5
Vada kategorie B – střední do 17:00 hod. desátého Pracovního dne od nahlášení vady6
Vada kategorie C – nízká

17.3. Záruka vztahující se k Hardwaru

1 Lhůta je stanovena v hodinách.
2 Lhůta je stanovena ve dnech.
3 Lhůta je stanovena ve dnech.
4 Lhůta je stanovena v hodinách.
5 Lhůta je stanovena ve dnech.
6 Lhůta je stanovena ve dnech.

25/33
17.3.1. Poskytuje-li výrobce anebo Dodavatel kterékoliv části Hardwaru na své výrobky anebo služby
záruku za jakost delší, než je záruka za jakost dle tohoto článku, zavazuje se Dodavatel udělit
Objednateli nebo na Objednatele postoupit danou záruku za jakost tak, aby Objednatel byl
oprávněn po skončení záruky za jakost uplatnit nároky ze záruky za jakost bez nutnosti součinnosti
ze strany Dodavatele.

17.3.2. Zjevné vady Hardware a dalších hmotných věcí je Objednatel povinen u Dodavatele reklamovat v
rámci Akceptačního řízení. V případě, že Objednatel zjistí vady hmotných věcí po akceptaci, je
povinen tyto vady bez zbytečného odkladu reklamovat u Dodavatele.

17.3.3. V případě, že odstranění reklamovaných vad bude trvat déle než dva (2) Pracovní dny, zavazuje
se Dodavatel poskytnout Objednateli náhradní Hardware či jinou náhradní hmotnou věc po dobu
trvání odstranění reklamované vady, nedohodnou-li se Strany jinak.

18. UKONČENÍ SMLUVNÍHO VZTAHU
18.1.
Obecně k odstoupení od Smlouvy:
18.2.
a. Strany sjednávají, že vznikne-li Objednateli nárok na odstoupení od Smlouvy, může podle

své volby odstoupit od Smlouvy v celém rozsahu či jen od některé části Plnění určené

Objednatelem.

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ůže mít za následek odstoupení

od této Smlouvy bez dalšího.

c. Dodavatel nemá právo odstoupit od Smlouvy v případě nevhodných příkazů Objednatele

či poskytnutí nevhodné věci Objednatelem dle § 2595 Občanského zákoníku.

Objednatel je oprávněn odstoupit od Smlouvy, v případě, že:

a. Dodavatel je v prodlení s plněním dle Smlouvy či jakékoliv části Plnění déle než 30 dnů a

nezjedná nápravu ani do 15 dnů od doručení písemného oznámení Objednatele o takovém

prodlení.

b. Dodavatel je v prodlení s Plněním dle Smlouvy déle než 60 dnů, a to i bez nutnosti zaslání

předchozího upozornění.

c. Nastane některý ze zákonem stanovených případů a zejména v případech podstatného

porušení povinností Dodavatele stanovených ve Smlouvě. Za podstatné porušení

povinností Dodavatele se považuje zejména:

i. Dodavatel je opakovaně v prodlení s prováděním Plnění dle Smlouvy;

ii. prohlášení Dodavatele učiněné na základě Smlouvy se ukáže jako nepravdivé;

iii. Dodavatel bez upozornění a relevantního odůvodnění nepoužil k Plnění člena

Realizačního týmu, ač k tomu byl povinen; nebo

iv. Dodavatel poruší některou z povinností uvedenou v čl. 20. ZOP opakovaně nebo

závažným způsobem.

d. Dodavatel poruší kteroukoliv svoji povinnost dle Smlouvy jiným než podstatným způsobem

a ve lhůtě 15 dnů od doručení písemného oznámení Objednatele toto své porušení

nenapraví.

e. Dodavatel poruší svou povinnost dle odst. 13.2. ZOP nebo odst. 13.3. ZOP nebo

Poddodavatel Dodavatele poruší některou z povinností vyplývající z požadavků dle odst.

13.2. ZOP.

f. Dodavatel 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 Dodavatele do šesti (6) měsíců od

zahájení insolvenčního řízení, nebo insolvenční soud vydá rozhodnutí o úpadku Dodavatele

ve smyslu § 136 Insolvenčního zákona.

g. Je přijato rozhodnutí o povinném nebo dobrovolném zrušení Dodavatele (vyjma případů

sloučení nebo splynutí).

26/33
h. Okolnost vylučující povinnost k náhradě Újmy kterékoli ze Stran trvá déle než 30 dnů;

i. dojde k Významné změně dle odst. 4.2. ZOP.

j. Dojde k Významné změně kontroly nad Dodavatelem nebo změny kontroly nad zásadními

aktivy využívanými Dodavatelem k plnění Smlouvy, přičemž kontrolou se zde rozumí vliv,

ovládání či řízení dle ust. § 71 a násl. ZOK, či ekvivalentní postavení.

k. Dojde k Významné změně ovlivnění nebo ovládání Dodavatele podle ust. § 71 a násl. ZOK

nebo změně vlastnictví zásadních aktiv, využívaných Dodavatelem k plnění Smlouvy a

změně oprávnění nakládat s těmito aktivy, či dojde ke změně ekvivalentní těmto změnám

a tato změna bude Objednatelem vyhodnocena jako riziko bezpečnosti informací, které

nelze odstranit jiným opatřením; toto ustanovení se uplatní i pro případ, že Dodavatel o

takových změnách dopředu a včas neinformuje Objednatele.

18.3. Dodavatel je oprávněn odstoupit od Smlouvy pouze v případech jejího podstatného porušení,
jestliže:

a. Objednatel nezaplatil jakoukoli dlužnou částku za Plnění dle Smlouvy řádně a včas a toto

porušení nenapravil ani do 60 dnů ode dne obdržení písemné výzvy k nápravě; nebo

b. Objednatel poruší jinou povinnost dle Smlouvy podstatným způsobem a ve lhůtě 60 dnů

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

18.4. Dodavatel není oprávněn odstoupit od Smlouvy ve vztahu k části Plnění, za kterou mu již bylo
Objednatelem zaplaceno.

18.4.1. Objednatel je oprávněn Smlouvu vypovědět bez výpovědní doby, nelze-li v jejím plnění
pokračovat, aniž by bylo porušeno opatření obecné povahy vydané ze strany NÚKIB.

19. ZMĚNY SMLOUVY A ZMĚNOVÉ ŘÍZENÍ
19.1.
19.2. Není-li ve Smlouvě nebo jejích Přílohách stanoveno jinak, může být Smlouva měněna nebo zrušena
pouze v listinné podobě, a to v případě změn Smlouvy číslovanými dodatky, který musí být
19.3. podepsány oběma Stranami a uzavřeny v souladu se ZZVZ.

Pokud je ve Smlouvě upraveno Opční právo, vyhrazuje si Objednatel v souladu s ustanovením §
100 odst. 3 ZZVZ vyhrazenou změnu závazku z této Smlouvy spočívající v pořízení dalšího
obdobného Plnění od vybraného účastníka v rámci zadávacího řízení Veřejné zakázky, tj. od
Dodavatele dle Smlouvy. Předmětem plnění Opčního práva je poskytnutí dalšího obdobného Plnění
dle Smlouvy tak, jak bylo podrobně vymezeno včetně dalších zákonných náležitostí vyhrazené
změny závazku dle § 100 odst. 3 ZZVZ v Zadávací dokumentaci předmětné Veřejné zakázky.

Objednatel je oprávněn do uplynutí tří (3) let od nabytí účinnosti Smlouvy kdykoliv uplatnit toto
Opční právo, a to i opakovaně do vyčerpání limitů Opčního práva definovaných v Zadávací
dokumentaci. Vyhrazená změna závazku ze Smlouvy bude Stranami projednána v rámci jednacího
řízení bez uveřejnění dle § 66 ZZVZ, které bude zahájeno Objednatelem v souladu s tímto
ustanovením, a jehož výsledkem bude uzavření listinného dodatku k této Smlouvě či uzavření
nové smlouvy mezi Objednatelem nebo Dodavatelem.

20. KYBERNETICKÁ BEZPEČNOST
20.1.
Tento článek se uplatní v případě, kdy tak výslovně stanoví Smlouva, pokud je Předmětem
20.2. Smlouvy Informační či komunikační systém, pokud má Plnění dopad na Informační či komunikační
systém, nebo pokud je Smlouva uzavřena s Významným dodavatelem či Provozovatelem. Zda je
Dodavatel Významným dodavatelem či Provozovatelem, stanoví Smlouva. Na jiné Smlouvy a
vztahy se neuplatní, ledaže se Dodavatel stane Významným dodavatelem či Provozovatelem
v průběhu plnění Smlouvy. V takovém případě se na něj čl. 20. uplatní v rozsahu v jakém to po
něm lze spravedlivě požadovat.

Dodavatel se při plnění Smlouvy zavazuje postupovat v souladu se ZKB, VKB a souvisejícími
právními předpisy, příp. vč. právních předpisů tyto předpisy nahrazující, dodržovat zásady
bezpečnosti informací, Interní předpisy Objednatele a z nich vyplývající povinnosti týkající se
bezpečnostních opatření, provozní řády prostor Objednatele, rozhodnutí, opatření obecné povahy,
či jiný správní akt NÚKIB či jiného správního orgánu anebo závazné podmínky pro Objednatele

27/33
stanovené orgánem veřejné moci ukládající Objednateli další povinnosti ve smyslu ZKB a VKB,
včetně upozorňování a zajištění hlášení Kybernetických bezpečnostních událostí a Kybernetických
bezpečnostních incidentů Objednateli, jakož i další bezpečnostní politiky, metodiky a postupy, se
kterými byl Objednatelem seznámen.

20.3. Dodavatel je povinen seznámit se s bezpečnostními požadavky Objednatele uvedenými ve
Smlouvě, jejích přílohách, těchto ZOP, Interních předpisech Objednatele a seznámit s nimi osoby
podílející se na plnění Smlouvy dle potřeby s ohledem na charakter jejich plnění s přihlédnutím
k zajištění bezpečnosti informací. Kontaktní osoba Dodavatele je povinna splnění povinnosti dle
předchozí věty Objednateli potvrdit do 30 dnů od uzavření Smlouvy. Pokud je to potřebné, je
Dodavatel povinen provést školení bezpečnostních požadavků dle tohoto odstavce a dále je
provádět v pravidelných intervalech, nejméně 1x ročně. Dodavatel je také povinen aktivně
vynucovat dodržování takových bezpečnostních požadavků dotčenými osobami na straně
Dodavatele. Za porušení těchto pravidel osobami uvedenými v tomto odstavci odpovídá Dodavatel
tak, jako by je porušil sám.

20.4. Není-li ve Smlouvě ujednáno jinak, je Dodavatel povinen vytvořit, pravidelně aktualizovat a
vynucovat vůči osobám podílejícím se, byť i nepřímo, na Předmětu Smlouvy:

a. politiku řízení přístupu, na základě které přidělí oprávnění k výkonu činností jednotlivým

rolím svých fyzických osob (přístup pro více osob na jednom účtu je nežádoucí a lze pouze

se souhlasem Objednatele) podílejících se na plnění Smlouvy (zaměstnanci, programátoři

podnikatelé apod.) v nejmenším možném a nutném rozsahu tak, aby měly přístup

k aktivům Objednatele pouze ty osoby, které takový přístup skutečně potřebují k výkonu

činností týkajících se předmětu Plnění dle Smlouvy; není-li ve Smlouvě ujednáno jinak, je

Dodavatel dále povinen průběžně monitorovat a zaznamenávat přístupy všech osob

účastnících se na Plnění dle Smlouvy, a to v rozsahu, aby bylo možné jednoznačně určit

uživatele, čas a provedenou činnost, jakož i vyhodnocovat oprávněnost těchto přístupů

(logování přístupů) a tuto svou povinnost v politice řízení přístupu zohlednit a Dodavatel

musí umožnit a poskytnout součinnost na jejich integraci do systému bezpečnostního

monitoringu (SIEM), systému pro správu logů a centrální úložiště logů Objednatele;

b. politiku zvládání Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních

incidentů obsahující činnosti, role, odpovědnosti a pravomoci k rychlému a účinnému

zvládání Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních

incidentů.

20.4.2. Kontaktní osoba Dodavatele je povinna před započetím Plnění, nejpozději však do 30 dnů od
uzavření Smlouvy, určit a popsat veškerá dotčená primární i podpůrná aktiva na straně Dodavatele
potřebná pro plnění Smlouvy. Dodavatel je povinen při nakládání s veškerými aktivy (dotčenými
aktivy Dodavatele a Objednatele) postupovat tak, aby chránil jejich důvěrnost, dostupnost a
integritu a zavést přiměřená opatření na jejich ochranu. Dodavatel je povinen řídit rizika spojená
s Plněním dle Smlouvy minimálně dle standardů požadovaných normou ISO 27001 a případně dle
Interních předpisů, pokud obsahují závazná pravidla pro řízení rizik. Dodavatel je povinen bez
zbytečného odkladu po uzavření Smlouvy kontaktní osobu Objednatele informovat o způsobu
řízení rizik a o zbytkových rizicích souvisejících s Plněním Smlouvy a následně v pravidelných
intervalech informovat o změnách.

20.5. Dodavatel je povinen zaslat kontaktní osobě Objednatele bez zbytečného odkladu všechna hlášení
o událostech, která mají charakter Kybernetické bezpečnostní události nebo Kybernetického
bezpečnostního incidentu, včetně případů porušení zabezpečení Osobních údajů, vždy bez
zbytečného odkladu, nejpozději však do tří (3) hodin po jejich zjištění, a sdělit Objednateli
opatření, která již provedl ve vztahu k této Kybernetické bezpečnostní události anebo
Kybernetickému bezpečnostnímu incidentu, případně zvolí jinou formu dohodnutou mezi
Objednatelem a Dodavatelem určenou ke včasnému hlášení Kybernetické bezpečnostní události
nebo Kybernetického bezpečnostního incidentu a/nebo již učiněných opatření. Dodavatel je
povinen veškeré Kybernetické bezpečnostní události a Kybernetické bezpečnostní incidenty
zaznamenávat a po nezbytně dlouhou dobu uchovávat. Dodavatel je povinen poskytnout
Objednateli veškerou nezbytnou součinnost k detekci, vyhodnocení či řešení Kybernetické
bezpečností události nebo Kybernetického bezpečnostního incidentu, a to včetně případné
realizace nutných opatření dle pokynů Objednatele. Zapříčinil-li Dodavatel Kybernetický

28/33
bezpečnostní incident nebo podílel-li se na jeho vzniku, provede analýzu příčin Kybernetického
bezpečnostního incidentu a navrhne opatření za účelem zamezení jeho opakování v budoucnu.
Dodavatel je povinen ohlásit každou jednotlivou Kybernetickou bezpečnostní událost nebo
Kybernetický bezpečnostní incident jedním z následujících způsobů:

a. e-mailem na adresu kontaktní osoby uvedené ve Smlouvě; nebo

b. telefonicky na telefonní číslo kontaktní osoby uvedené ve Smlouvě; nebo

c. ohlášením do Helpdesku Objednatele.

20.6. Dodavatel je povinen pravidelně alespoň čtvrtletně předkládat Objednateli zprávu o počtu a druhu
útoků a Kybernetických bezpečnostních událostí a Kybernetických bezpečnostních incidentů, které
zaznamenal ve spojení s Plněním a/nebo Předmětem Smlouvy.

20.7. Dodavatel se zavazuje poskytnout Objednateli veškerou součinnost nezbytnou k tomu, aby
Objednatel řádně naplňoval právní povinnosti stanovené ZKB, VKB a Interními předpisy. Zejména
se Dodavatel zavazuje poskytnout Objednateli součinnost směřující k zavedení a provádění
bezpečnostních opatření podle ZKB, VKB a Interních předpisů a řešení Kybernetických
bezpečnostních událostí a Kybernetických bezpečnostních incidentů. Jestliže Dodavatel při plnění
Smlouvy zjistí či jako odborník mohl a měl zjistit rozpor ustanovení Interních předpisů se ZKB,
VKB anebo rozhodnutím či jiným pokynem NÚKIB v souladu se ZKB, je povinen takový rozpor
Objednateli neprodleně ohlásit a poskytnout Objednateli součinnost k jeho odstranění.

20.8. Dodavatel bere na vědomí, že v rámci provádění Plnění může být podroben Interním předpisům
Objednatele či jeho pokynům v oblasti řízení kontinuity činností, zejména může být zahrnut do
havarijních plánů, úkolů při aktivaci řízení kontinuity činností, bezpečnostní politiky apod., a to v
rozsahu, v jakém lze po Dodavateli spravedlivě požadovat s ohledem na předmět plnění.

20.9. V případě, že dojde k jakémukoliv rozporu mezi Dodavatelem a třetí osobou, která není jeho
Poddodavatelem a je dodavatelem Softwaru nebo jiných technologií dotčených plněním povinností
Dodavatele dle této Smlouvy, je Dodavatel povinen tuto skutečnost bez zbytečného odkladu
oznámit Objednateli. Dodavatel je dále povinen poskytovat Objednateli nutnou součinnost pro
jednání s těmito třetími osobami a sám se těchto jednání účastnit, nebo na základě žádosti
Objednatele jednat s těmito třetími osobami napřímo.

20.10. Objednatel má právo v souladu s ustanoveními § 2593 Občanského zákoníku prostřednictvím
určených osob kdykoli kontrolovat plnění Smlouvy u Dodavatele a jeho případných Poddodavatelů,
a to i prostřednictvím třetí osoby; předchozí věta se uplatní obdobně v případě kontroly některé
ze Stran ze strany kontrolního orgánu ve smyslu zákona č. 255/2012 Sb., kontrolní řád, ve znění
pozdějších předpisů.

20.11. Objednatel má právo prostřednictvím určených osob provádět v pravidelných intervalech (1x
ročně, není-li ve Smlouvě ujednáno jinak), jakož i v případě důvodného podezření na závažné
porušení povinností Dodavatele dle těchto ZOP, v případě Kybernetických bezpečnostních
incidentů a/nebo v jiných případech vyžadovaných ZKB a/nebo VKB, audit kybernetické
bezpečnosti, tj. dodržování bezpečnosti informací dle Interních předpisů, ZKB a VKB u Dodavatele
a jeho případných Poddodavatelů, a to i prostřednictvím třetí osoby. V rámci auditu kybernetické
bezpečnosti je Objednatel oprávněn zejména porovnávat zjištěné skutečnosti s bezpečnostní
dokumentací Objednatele a nad rámec obvyklý u auditu kybernetické bezpečnosti dále provádět
následující činnosti:

a. nehlášená návštěva u Dodavatele v místě umístění členů Realizačního týmu či jiných osob

podílejících se na plnění Smlouvy v rozsahu tří (3) hodin vždy nejčastěji čtyřikrát (4x) za

rok; a

b. nehlášený telefonát s členem Realizačního týmu, který má přístup do Informačního či

komunikačního systému, zahrnující konkrétní dotazy na zabezpečení a jiné aspekty

informační bezpečnosti dotčeného Informačního či komunikačního systému.

20.12. Dodavatel je povinen umožnit Objednateli provedení kontroly a auditu kybernetické bezpečnosti a
zajistit (i smluvně) právo na provedení této kontroly a auditu kybernetické bezpečnosti u svých
případných Poddodavatelů, jakož i veškerou další součinnost nezbytnou pro provedení auditu.
Kontrolu a audit kybernetické bezpečnosti může rovněž provést i třetí osoba pověřená
Objednatelem. Průběh takového auditu je doložen např. auditní zprávou či jiným obdobným

29/33
dokumentem. Případné náklady na straně Dodavatele na provedení auditu jsou součástí Ceny za
Plnění dle Smlouvy. Dodavatel je oprávněn rozporovat výsledky auditu kybernetické bezpečnosti
do 7 Pracovních dnů od oznámení výsledku auditu kybernetické bezpečnosti. Dodavatel může
rozporovat a) existenci vytčeného porušení či hrozby; b) že porušení či hrozba byla Dodavatelem
již odstraněna. V obou případech uvede skutečnosti a důkazy k podpoře svých tvrzení. Objednatel
je v takovém případě povinen takové připomínky vypořádat. V případě, že Objednatel na svém
zjištění setrvá, je Dodavatel povinen se tímto auditem řídit.

20.13. Pokud audit kybernetické bezpečnosti odhalí jakékoliv podstatné porušení či hrozbu takového
porušení, je Dodavatel povinen napravit nedostatky vč. přijetí případných dalších bezpečnostních
opatření a o tomto informovat Objednatele, pokud se jedná o Významného dodavatele, je povinen
napravit nedostatky a bezodkladně informovat Objednatele do 7 dnů.

20.14. Je-li součástí Předmětu Plnění přenos Dat a informací, je Dodavatel povinen jej za součinnosti
oprávněných osob na straně Objednatele zabezpečit odolnými kryptografickými algoritmy v
souladu s aktuálními doporučeními NÚKIB.

20.15. Je-li součástí Předmětu Plnění správa síťové infrastruktury a/nebo jejích prvků (aktivních či
pasivních), je Dodavatel povinen za součinnosti oprávněných osob na straně Objednatele:

a. provádět analýzy topologie sítě či skenování aktivních částí Předmětu Plnění; a

b. realizovat bezpečnostní opatření pro odstranění nebo blokování síťových spojení, která

neodpovídají požadavkům na ochranu integrity komunikační sítě.

20.15.2. Významný dodavatel je dále povinen:

a. poskytnout Objednateli veškeré potřebné informace a součinnost v procesu řízení a

evidence změn v souladu s § 11 VKB dle potřeb Objednatele (zejm. při posouzení, zda je

změna Významnou změnou, analýze souvisejících rizik, přijímání opatření za účelem

snížení všech nepříznivých dopadů spojených se změnami, aktualizaci bezpečnostní

dokumentace, souvisejícím testováním, zajištění možnosti navrácení do původního stavu

a provedení dalších činností dle VKB);

b. strpět a poskytnout Objednateli veškerou potřebnou součinnost v případě nutnosti provést

penetrační testování;

c. zpracovat a pravidelně aktualizovat bezpečnostní dokumentaci v rozsahu stanoveném ve

Smlouvě;

d. průběžně detekovat známé zranitelnosti dotčených aktiv Objednatele a bezodkladně na ně

upozorňovat Objednatele;

e. vést v elektronické formě provozní deník obsahující veškeré podstatné okolnosti související

s plněním povinností Dodavatele dle článku 20. ZOP a/nebo Plněním, provozní události

důležitých aktiv a relevantní záznamy o plnění povinností Dodavatele dle článku 20. ZOP a

zpřístupnit jej Objednateli prostřednictvím zabezpečeného vzdáleného přístupu, není-li ve

Smlouvě ujednán jiný způsob; v provozním deníku Významný dodavatel dále do 20. dne

následujícího měsíce uvede výstup z monitoringu dostupnosti, důvěrnosti a integrity aktiv

Objednatele, se kterými pracuje v rámci plnění Smlouvy, prováděného nejméně jedenkrát

měsíčně a vyhodnocovaného vždy k 10. dni následujícího měsíce; a

f. dodržovat pravidla a standardy bezpečného vývoje.

20.15.3. Provozovatel je dále povinen:

a. provádět pravidelné zálohy dat a programového vybavení vztahujících se k Plnění dle

Smlouvy, zabezpečit je vhodnými prostředky proti neoprávněným přístupům nebo jejich

ztrátě a v pravidelných intervalech testovat funkčnost těchto záloh, nejméně jedenkrát za

měsíc, není-li ve Smlouvě ujednáno jinak;

b. plnit další povinnosti vyplývající pro Provozovatele ze ZKB a VKB.

20.16. Dodavatel bere na vědomí, že Objednatel je Poskytovatelem strategicky významné služby ve
smyslu návrhu nového zákona o kybernetické bezpečnosti, který nahradí ZKB. Dodavatel je
povinen postupovat při plnění Smlouvy tak, aby byla zajištěna dostupnost strategicky významné
služby v nezbytném rozsahu, ve stanoveném čase a kvalitě z území České republiky. Dodavatel

30/33
poskytne Objednateli veškerou potřebnou součinnost za účelem splnění povinnosti Objednatele
prověřovat zajištění poskytování strategicky významné služby v nezbytném rozsahu z území České
republiky nejméně jednou za 2 roky a o tomto prověření vyhotovit záznam, a to za předpokladu,
že tato povinnost bude v nových právních předpisech, které nahradí ZKB.

20.17. Pokud Objednatel zjistí, že Dodavatel postupuje v rozporu s tímto článkem, je Objednatel v
takovém případě oprávněn dožadovat se toho, aby Dodavatel odstranil vady vzniklé vadným
postupem Dodavatele, zdržel se provádění postupů, které jsou v rozporu s tímto článkem, nebo
konal, jak je od něj vyžadováno tímto článkem, a dále Smlouvou plnil řádným způsobem. Strany
se dohodnou na podmínkách a lhůtě k odstranění nedostatků plnění Smlouvy ve smyslu tohoto
odstavce, přičemž nedohodnou-li se Strany na konkrétní lhůtě, pak je Dodavatel povinen odstranit
nedostatky do třiceti (30) dnů. Jestliže Dodavatel včas neodstraní nedostatky ve smyslu předchozí
věty tohoto odstavce nebo se jedná o porušení povinnosti (bez ohledu na jeho závažnost), pak je
Objednatel oprávněn od Smlouvy odstoupit.

20.18. Kontaktní osoby Stran vzájemně komunikují v průběhu plnění Smlouvy za účelem dosažení
standardů pro bezpečnost informací. V případě ohrožení anebo porušení bezpečnosti informací,
zejména v případě výskytu Kybernetické bezpečnostní události anebo Kybernetického
bezpečnostního incidentu, jsou kontaktní osoby povinny vzájemně komunikovat, ihned po zjištění
takových skutečností hlásit jejich výskyt druhé Straně a společně podnikat kroky k zajištění
obnovení bezpečnosti informací.

20.19. Dodavateli nenáleží za plnění povinností souvisejících s bezpečností informací ve smyslu článku
20. ZOP jakákoliv další odměna, resp. taková odměna je součástí Ceny.

20.20. Objednatel je oprávněn požadovat na Dodavateli zaplacení smluvní pokuty:

a. za každý den prodlení při zavedení bezpečnostních opatření podle ZKB, VKB, těchto ZOP a

Interních předpisů:

i. ve výši 0,05 % z Ceny po dobu prvních pěti (5) dnů prodlení;

ii. ve výši 0,1 % z Ceny po dobu od šestého (6.) dne prodlení do desátého (10.) dne

prodlení; a

iii. ve výši 0,2 % z Ceny po dobu od jedenáctého (11.) dne prodlení;

b. za každý den Objednatelem zjištěného soustavného porušování bezpečnostních opatření

podle ZKB, VKB, těchto ZOP a Interních předpisů:

i. ve výši 0,05 % z Ceny do šestého (6.) dne soustavného porušování; a

ii. ve výši 0,1 % z Ceny od šestého (6.) dne soustavného porušování;

c. ve výši 2 % z Ceny za každý případ porušení povinnosti hlášení událostí, které mají

charakter Kybernetické bezpečnostní události nebo Kybernetického bezpečnostního

incidentu;

d. ve výši 2 % z Ceny za každý případ neumožnění nebo odepření provedení kontroly a auditu

kybernetické bezpečnosti ve smyslu článku 20. ZOP;

e. ve výši 5 % z Ceny za každý případ porušení článku 20. ZOP, přičemž toto porušení vedlo

ke Kybernetickému bezpečnostnímu incidentu;

f. ve výši 0,1 % z Ceny za každý započatý den trvání porušení povinností Významného

dodavatele dle článku 20. ZOP, dané porušení nebylo odstraněno a negativní následek

porušení povinnosti stále trvá; a

g. ve výši 1 % z Ceny za každý případ jiného porušení článku 20. ZOP neuvedeného výše.

21. OCHRANA OSOBNÍCH ÚDAJŮ
21.1.
Budou-li údaje, ke kterým Dodavatel získá přístup v souvislosti s Plněním dle Smlouvy, mít povahu
Osobních údajů, je Dodavatel povinen přijmout veškerá opatření k tomu, aby nemohlo dojít
k neoprávněnému nebo nahodilému přístupu k těmto Osobním údajům, jejich změně, zničení či
ztrátě, neoprávněným přenosům či jinému zneužití, a zajistit nakládání s Osobními údaji v souladu
s GDPR.

31/33
21.2. Pokud bude v rámci provádění Plnění docházet ke zpracování Osobních údajů, je rozsah
zpracovávaných Osobních údajů uveden ve Smlouvě. Pokud dojde v rámci poskytování Plnění ke
zpracování Osobních údajů, které Smlouva výslovně neuvádí, budou tato nová zpracování
Osobních údajů prováděna za stejných podmínek.

21.3. Dodavatel bude zpracovávat Osobní údaje pro Objednatele výhradně za účelem poskytování služeb
v rozsahu ujednaném podle Smlouvy. Dodavatel bude pro Objednatele zpracovávat Osobní údaje
výhradně za uvedeným účelem, způsobem a na základě doložených pokynů a podmínek
Objednatele a v souladu s nimi tak, jak vyplývají ze Smlouvy. Dodavatel neprodleně informuje
Objednatele, pokud jsou podle jeho názoru určité pokyny Objednatele v rozporu s účinnými
právními předpisy.

21.4. Dodavatel se zavazuje přijmout vhodná technická a organizační opatření podle GDPR, které se na
něj jako na zpracovatele vztahují, a plnění těchto povinností na vyžádání doložit Objednateli.

21.5. Dodavatel může předávat Osobní údaje do třetí země nebo mezinárodní organizaci ve smyslu
GDPR pouze na základě zvláštního pokynu Objednatele. Je-li takovéto předání založeno na
povinnosti vyplývající z práva Unie nebo členského státu, které se na Objednatele vztahuje,
informuje Dodavatel Objednatele o tomto právním požadavku před předáním, ledaže by tyto
právní předpisy toto informování zakazovaly z důležitých důvodů veřejného zájmu.

21.6. Dodavatel je povinen zajistit, aby se osoby oprávněné zpracovávat osobní údaje zavázaly
zachovávat mlčenlivost ve vztahu ke všem Osobním údajům, které zpracovává na základě
Smlouvy, a rovněž tak o bezpečnostních opatřeních, jejichž zveřejnění by ohrozilo zabezpečení
osobních údajů.

21.7. Dodavatel je povinen přijmout všechna opatření dle čl. 32 GDPR tak, aby byla zajištěna
odpovídající bezpečnost Osobních údajů. Dodavatel může do zpracování zapojit Poddodavatele
pouze na základě předchozího písemného souhlasu Objednatele. Dodavatel se zavazuje s těmito
Poddodavateli uzavřít smlouvu v souladu s GDPR zajištující dodržování práv a povinností
stanovených Smlouvou a/nebo těmito ZOP, zvláště pak povinnosti mlčenlivosti a zajištění
bezpečnosti Osobních údajů a poskytnutí dostatečných záruk pro zavedení stejných technických a
organizačních opatření Poddodavatelem, jakož i v souladu s dalšími aplikovatelnými právními
předpisy. Dodavatel je dále povinen zohlednit povahu zpracování, být Objednateli nápomocen
prostřednictvím vhodných technických a organizačních opatření pro splnění povinnosti Objednatele
reagovat na žádost o výkon práv subjektu údajů dle GDPR.

21.8. Dodavatel je povinen být Objednateli nápomocen při zajišťování souladu s povinnostmi podle
článku 32 až 36 GDPR, a to při zohlednění povahy zpracování informací, jež má Dodavatel k
dispozici. V případech, kdy povaha věci vyžaduje informování Objednatele ze strany Dodavatele,
informuje Dodavatel Objednatele bez zbytečného odkladu.

21.9. Dodavatel je povinen umožnit Objednateli a jím pověřené osobě během běžné pracovní doby
Dodavatele provést v sídle Dodavatele kontrolu dodržování povinností týkajících se zpracování
Osobních údajů vyplývajících ze Smlouvy, a to i po ukončení stanovené doby zpracování, tj. po
ukončení této Smlouvy, a to do 3 měsíců od jejího ukončení.

21.10. Po ukončení zpracování Osobních údajů podle Smlouvy je Dodavatel povinen poskytnout
Objednateli všechna Zařízení obsahující Osobní údaje, pokud je to možné, a vymazat všechny
zpracovávané Osobní údaje ze všech svých systémů nebo databází, včetně vymazání všech
záložních kopií, s výjimkou, kdy uchovávání vyžadují právní předpisy, nebo k tomu dal písemný
souhlas Objednatel.

21.11. V případě, že Dodavatel zpracuje osobní údaje nad rámec vymezený Smlouvou/doloženými pokyny
Objednatele, považuje se ve vztahu k takovému zpracování za správce. Pokud tímto zpracováním
nad rámec vymezený Smlouvou/doloženými pokyny Objednatele vznikne Objednateli škoda, je
Dodavatel povinen škodu uhradit.

21.12. Pokud Dodavatel poruší povinnost chránit Osobní údaje v souladu s tímto článkem, vzniká
Objednateli nárok na zaplacení smluvní pokuty ve výši částky sankce případně uložené z tohoto
důvodu Objednateli ze strany Úřadu pro ochranu osobních údajů či jiným správním orgánem, který
bude v budoucnu vykonávat působnost Úřadu pro ochranu osobních údajů. Objednatel je však
za předpokladu, že mu k tomu Dodavatel poskytne nezbytnou součinnost, povinen uplatnit

32/33
v příslušných řízeních veškeré přiměřené námitky, které mohl uplatnit ve svém zájmu, a v rámci
řízení je povinen řádně hájit svá práva.

22. OCHRANA DŮVĚRNÝCH INFORMACÍ
22.1.
22.2. Dodavatel se zavazuje zachovávat mlčenlivost o všech Důvěrných informacích, které získal nebo
22.3. mu byly poskytnuty či zpřístupněny v souvislosti s plněním povinnosti dle Smlouvy, a uchovávat
je v tajnosti.
22.4.
Dodavatel se zavazuje použít Důvěrné informace pouze k plnění svých povinností vyplývajících ze
22.5. Smlouvy. Dodavatel nesmí použít Důvěrné informace k jinému účelu.
22.6.
Dodavatel nesmí bez předchozího písemného souhlasu Objednatele zpřístupnit Důvěrné informace
22.7. žádné třetí osobě, a to v jakékoli formě. To neplatí u Důvěrných informací, ohledně kterých byla
22.8. Dodavateli pravomocným rozhodnutím soudu, správního orgánu, či jiného příslušného státního
orgánu v konkrétním případě uložena povinnost Důvěrnou informaci poskytnout nebo plyne-li
taková povinnost Dodavateli z právního předpisu.

Dodavatel nesmí Důvěrné informace bez předchozího písemného souhlasu Objednatele
rozmnožovat, kopírovat či jakýmkoliv jiným způsobem reprodukovat. Dodavatel dále nesmí
Důvěrné informace bez předchozího písemného souhlasu Objednatele uchovávat v jakékoliv
databázi, počítačovém programu, úložišti či na datovém nosiči, vyjma případů, kdy je takové
uchovávání Důvěrných informací nezbytné pro účel vyplývající ze Smlouvy.

Dodavatel se zavazuje provést technická, organizační, právní a personální opatření, kterými zajistí
dodržování povinnosti zachovat mlčenlivost o Důvěrných informacích a uchovat Důvěrné informace
v tajnosti v rozsahu podle tohoto článku i ze strany svých zaměstnanců, Poddodavatelů, jakož i
dalších osob, kterým budou Důvěrné informace poskytnuty či zpřístupněny.

Objednatel je oprávněn kdykoliv kontrolovat řádné plnění povinností Dodavatele uvedených v
tomto článku, k čemuž se Dodavatel zavazuje bez zbytečného odkladu poskytnout Objednateli
veškerou součinnost, zejména je Objednatel oprávněn kontrolovat řízení bezpečnosti Důvěrných
informací Dodavatelem. V případě, že Objednatel vyzve Dodavatele na základě kontroly k nápravě,
je Dodavatel povinen takové výzvě vyhovět v Objednatelem stanovené přiměřené lhůtě.

Dodavatel se během poskytování Plnění pro Objednatele zavazuje informovat Objednatele o
fyzických osobách přicházejících do kontaktu s Důvěrnými informacemi Objednatele (jedná se
například o osoby zastávající bezpečnostní role, penetrační testery a administrátory apod.).

Objednatel je oprávněn požadovat na Dodavateli zaplacení smluvní pokuty:

a. ve výši 500 000 Kč za každé jednotlivé jednání, které představuje porušení jakékoli z

povinností Dodavatele dle tohoto článku, vyjma povinností stanovených v odst. 22.6. ZOP

b. ve výši 100 000 Kč za každé jednotlivé jednání, které představuje porušení jakékoli

z povinností stanovených v odst. 22.6. ZOP.

33/33
Příloha č. 6 Smlouvy o poskytování služeb

Obchodní podmínky ke Smlouvě o
poskytování služeb

Obchodní podmínky ke Smlouvě o poskytování služeb ........................................................ 1
ČÁST 1 - ÚVODNÍ USTANOVENÍ................................................................................... 2
ČÁST 2 - NÁVRH NA UZAVŘENÍ SMLOUVY O POSKYTOVÁNÍ SLUŽEB ........................... 3
ČÁST 3 - SLUŽBY ......................................................................................................... 3
ČÁST 4 - CENA SLUŽEB ................................................................................................ 4
ČÁST 5 - ZMĚNA CENY SLUŽEB .................................................................................... 4
ČÁST 6 - PLATEBNÍ PODMÍNKY ................................................................................... 5
ČÁST 7 - MÍSTO PLNĚNÍ .............................................................................................. 6
ČÁST 8 - DOBA PLNĚNÍ................................................................................................ 6
ČÁST 9 - PROVÁDĚNÍ SLUŽEB...................................................................................... 6
ČÁST 10 - ZKUŠEBNÍ PROVOZ ..................................................................................... 9
ČÁST 11 - PŘEPRAVA SLUŽEB ...................................................................................... 9
ČÁST 12 - PODDODAVATELÉ ...................................................................................... 10
ČÁST 13 - PŘEDÁNÍ A PŘEVZETÍ SLUŽEB................................................................... 10
ČÁST 14 - VLASTNICKÉ PRÁVO A NEBEZPEČÍ ŠKODY ................................................ 11
ČÁST 15 - VADY PLNĚNÍ A ZÁRUKA ........................................................................... 12
ČÁST 16 - UPLATNĚNÍ PRÁV Z VADNÉHO PLNĚNÍ...................................................... 13
ČÁST 17 - PODMÍNKY ODSTRANĚNÍ VAD................................................................... 13
ČÁST 18 - POJIŠTĚNÍ ................................................................................................ 14
ČÁST 19 - DUŠEVNÍ VLASTNICTVÍ............................................................................. 14
ČÁST 20 - SANKCE ..................................................................................................... 15
ČÁST 21 - OBECNÁ ODPOVĚDNOST POSKYTOVATELE ................................................ 15
ČÁST 22 - ODSTOUPENÍ OD SMLOUVY O POSKYTOVÁNÍ SLUŽEB............................... 16
ČÁST 23 - OSTATNÍ UJEDNÁNÍ .................................................................................. 17

1/18 Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1
zapsána v obchodním rejstříku vedeném Městským IČ: 709 94 234 DIČ: CZ 709 94 234
soudem v Praze, spisová značka A 48384 www.spravazeleznic.cz
ČÁST 1 - ÚVODNÍ USTANOVENÍ

1. Pro účely těchto Obchodních podmínek mají následující slova význam u nich uvedený:
1.1. Občanský zákoník – zákon č. 89/2012 Sb., občanský zákoník, ve znění
pozdějších předpisů.
1.2. ZoDPH – zákon č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších
předpisů.
1.3. ZoÚ – zákon č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů.
1.4. SZ – zákon č. 283/2021 Sb., stavební zákon, ve znění pozdějších předpisů.
1.5. ZZVZ – zákon č. 134/2016 Sb., o zadávání veřejných zakázkách, ve znění
pozdějších předpisů.
1.6. Objednatel – Správa železnic, státní organizace, IČO 70994234, se sídlem Praha
1 – Nové Město, Dlážděná 1003/7, PSČ 110 00, zapsaná v obchodním rejstříku
vedeném Městským soudem v Praze pod sp. zn. A 48384.
1.7. Poskytovatel – osoba uvedená ve Smlouvě o poskytování služeb jako
Poskytovatel; též všechny osoby, které jsou ve Smlouvě o poskytování služeb
uvedené na straně Poskytovatele, je-li na straně Poskytovatele více než jedna
osoba.
1.8. Smluvní strany – Objednatel a Poskytovatel.
1.9. Smluvní strana – Objednatel nebo Poskytovatel dle smyslu ujednání.
1.10. Nabídka – souhrn dokumentů, které Poskytovatel podal jako návrh do zadávacího
řízení, na jehož základě byla uzavřena Smlouva o poskytování služeb.
1.11. Smlouva o poskytování služeb – smlouva uzavřená mezi Smluvními stranami,
která odkazuje na Obchodní podmínky.
1.12. Obchodní podmínky – tento text obchodních podmínek.
1.13. Předmět služeb – věc, která má být zhotovena, nebo činnost s jiným výsledkem,
specifikovaná ve Smlouvě o poskytování služeb.
1.14. Související plnění – další plnění (práce, dodávky, služby, činnosti a výkony),
která je Poskytovatel povinen dle Smlouvy o poskytování služeb poskytnout vedle
samotného provedení Předmětu služeb.
1.15. Rozhodnutí Objednatele – veškerá rozhodnutí, sdělení, souhlasy, povolení či jiné
výsledky úkonů orgánů státní správy, samosprávy či jiných subjektů, které pro
účely Služeb nebo v souvislosti s ním získal nebo do doby dokončení Služeb získá
Objednatel a jež Objednatel Poskytovateli předal nebo s nimiž se Poskytovatel jinak
seznámil.
1.16. Rozhodnutí Poskytovatele – veškerá rozhodnutí, sdělení, souhlasy, povolení či
jiné výsledky úkonů orgánů státní správy, samosprávy či jiných subjektů, které je
Poskytovatel povinen dle Smlouvy o poskytování služeb získat. Jakékoliv
Rozhodnutí Poskytovatele, které není v českém jazyku, musí být do českého jazyka
přeloženo a překlad musí být úředně ověřen.
1.17. Veřejnoprávní podklady – souhrn Rozhodnutí Objednatele a Rozhodnutí
Poskytovatele.
1.18. Doklady – veškeré listiny, které se vztahují k Předmětu služeb nebo Souvisejícímu
plnění a které jsou třeba k jejich převzetí a užívání; veškerá Rozhodnutí
Poskytovatele; veškeré další listiny, vyjma Výzvy k úhradě, které je Poskytovatel
dle Smlouvy o poskytování služeb povinen předat Objednateli. Všechny Doklady
musejí být v českém jazyku, nebo v původním jazyku s překladem do českého
jazyka, není-li uvedeno jinak.
1.19. Služby – souhrn veškerých plnění, která je Poskytovatel povinen provést za
účelem splnění Smlouvy o poskytování služeb; zahrnuje zejm. provedení Předmětu
služeb, poskytnutí či provedení Souvisejícího plnění a dodání Dokladů.
1.20. Cena služeb – cena za Služby sjednaná ve Smlouvě o poskytování služeb (částka
bez DPH).
1.21. Výzva k úhradě – daňový doklad, je-li Poskytovatel povinen dle ZoDHP uhradit
v souvislosti s provedením Služeb nebo jeho části DPH, nebo faktura, pokud

2/18
1.22. Poskytovatel v souvislosti s provedením Služeb nebo jeho části není dle ZoDPH
1.23. povinen uhradit DPH.
1.24. Vícepráce – práce, dodávky nebo služby nad rámec Smlouvy o poskytování
služeb, na jejichž provedení se Smluvní strany dohodnou po uzavření Smlouvy o
1.25. poskytování služeb.
1.26. Méněpráce – práce, dodávky nebo služby v rámci Smlouvy o poskytování služeb,
1.27. na jejichž vypuštění se Smluvní strany dohodnou po uzavření Smlouvy o
1.28. poskytování služeb.
Obalový materiál – palety, dřevěné desky či jiné věci, které slouží pro potřeby
přepravy nebo ochrany Předmětu služeb. Dle kontextu Smlouvy o poskytování
služeb se rozumí Obalovým materiálem též jednotlivý kus palety, dřevěné desky
nebo jiné věci.
Přejímací řízení – proces, při kterém Poskytovatel předává a Objednatel
kontroluje a přebírá Služby, nebo je odmítá.
Předávací protokol – listina osvědčující předání a převzetí Služeb nebo jeho části,
jejíž minimální náležitosti jsou uvedeny v části Předání a převzetí Služeb.
Záruční doba – doba, do jejíhož uplynutí je Objednatel oprávněn uplatňovat práva
z vad plnění poskytnutého Poskytovatelem na základě Smlouvy o poskytování
služeb; Záruční doba činí 24 měsíců.
CTD – Centrum techniky a diagnostiky, organizační jednotka Objednatele.

ČÁST 2 - NÁVRH NA UZAVŘENÍ SMLOUVY O POSKYTOVÁNÍ SLUŽEB

2. Odpověď Smluvní strany na návrh na uzavření Smlouvy o poskytování služeb učiněný
druhou Smluvní stranou, která vymezuje obsah návrhu jinými slovy nebo která obsahuje
jakékoliv, byť nepodstatné, dodatky, odchylky, výhrady nebo omezení není přijetím
návrhu.

3. I pozdní přijetí návrhu na uzavření Smlouvy o poskytování služeb má účinky včasného
přijetí, pokud navrhující Smluvní strana bez zbytečného odkladu alespoň ústně vyrozumí
druhou Smluvní stranu, že přijetí považuje za včasné, nebo pokud se začne chovat ve
shodě s návrhem.

4. Plyne-li z písemnosti, která vyjadřuje přijetí návrhu na uzavření Smlouvy o poskytování
služeb, že byla odeslána za takových okolností, že by došla navrhující Smluvní straně včas,
kdyby její přeprava probíhala obvyklým způsobem, má pozdní přijetí účinky včasného
přijetí, ledaže navrhující Smluvní strana bez odkladu vyrozumí alespoň ústně druhou
Smluvní stranu, že považuje návrh za zaniklý.

5. Bez ohledu na jakékoliv okolnosti nelze přijmout návrh na uzavření Smlouvy o poskytování
služeb tak, že se Smluvní strana, jíž je návrh určen, podle návrhu zachová.

6. Odkáží-li Smluvní strany v návrhu na uzavření Smlouvy o poskytování služeb i v
přijetí návrhu na obchodní podmínky, které si odporují, je Smlouva o poskytování
služeb přesto uzavřena s obsahem určeným v tom rozsahu, v jakém obchodní
podmínky nejsou v rozporu; to platí i v případě, že to obchodní podmínky vylučují.
Vyloučí-li to některá ze Smluvních stran nejpozději bez zbytečného odkladu po
výměně projevů vůle, Smlouva o poskytování služeb uzavřena není.

7. Smlouva o poskytování služeb může být uzavřena pouze v písemné podobě.

ČÁST 3 - SLUŽBY

8. Poskytovatel se zavazuje provést na svůj náklad a nebezpečí pro Objednatele Služby a
Objednatel se zavazuje Služby převzít a zaplatit Poskytovateli Cenu služeb a příslušnou
DPH, bude-li Poskytovatel povinen dle ZoDHP uhradit v souvislosti s provedením Služeb
nebo jeho části DPH.

9. Poskytovatel je povinen provést Služby v jakosti, provedení a způsobem uvedeným ve
Smlouvě o poskytování služeb a zároveň

3/18
9.1. v jakosti, provedení a způsobem, jenž odpovídá vlastnostem a způsobu, které
Poskytovatel popsal nebo které Objednatel očekával s ohledem na povahu Služeb,
a to v rozsahu, ve kterém není v rozporu s jakostí, provedením a způsobem
sjednaným ve Smlouvě o poskytování služeb,

9.2. v jakosti, provedení a způsobem, jenž se hodí k účelu vyplývajícímu ze Smlouvy o
poskytování služeb a není-li v ní vyjádřen pak k účelu, ke kterému se Služby
obvykle používá, a to v rozsahu, ve kterém není v rozporu s jakostí, provedením a
způsobem sjednaným ve Smlouvě o poskytování služeb,

9.3. v souladu s Veřejnoprávními podklady,
9.4. v souladu s požadavky právních předpisů a příslušných ČSN.
10. Je-li jakost či provedení Předmětu služeb zároveň určeno vzorkem nebo předlohou, musí
Předmět služeb odpovídat jakostí nebo provedením vzorku nebo předloze. Liší-li se jakost
nebo provedení určené ve Smlouvě o poskytování služeb a vzorek nebo předloha,
rozhoduje Smlouva o poskytování služeb. Určuje-li Smlouva o poskytování služeb a vzorek
nebo předloha jakost nebo provedení rozdílně, nikoliv však rozporně, musí Předmět služeb
odpovídat Smlouvě o poskytování služeb i vzorku nebo předloze.
11. Opatřuje-li Poskytovatel věc za účelem jejího zpracování při provádění Služeb, je povinen
opatřit věc novou, nepoužitou a neopotřebovanou.
12. Je-li součástí Služeb povinnost Poskytovatele zajistit jakékoliv Rozhodnutí Poskytovatele,
je Poskytovatel povinen provést veškeré činnosti, kterých je k získání příslušného
Rozhodnutí Poskytovatele třeba.

ČÁST 4 - CENA SLUŽEB

13. Cena služeb zahrnuje veškeré náklady Poskytovatele spojené se splněním jeho povinností
vyplývajících ze Smlouvy o poskytování služeb a Obchodních podmínek a zisk
Poskytovatele.

14. Objednatel není povinen hradit v souvislosti se Smlouvou o poskytování služeb žádné jiné
finanční částky, než Cenu služeb a případně příslušnou DPH, není-li uvedeno jinak (tím
není dotčeno právo Poskytovatele na případnou úhradu smluvní pokuty, úroků z prodlení,
či jiných sankcí, a právo na náhradu škody způsobené Objednatelem).

15. Cena služeb obsahuje předpokládaný vývoj cen vstupních nákladů a předpokládané
zvýšení ceny v závislosti na čase plnění, a to až do dokončení Služeb.

16. Je-li Poskytovatel povinen dle ZoDHP uhradit v souvislosti s provedením Služeb nebo jeho
části DPH, je Objednatel povinen Poskytovateli takovou DPH uhradit vedle Ceny služeb.

17. Cenu služeb lze měnit pouze za podmínek uvedených v části Změna ceny Služeb (viz ČÁST
5 - Obchodních podmínek).

18. Konečné finanční částky na fakturách/daňových dokladech nesmí být zaokrouhlovány na
celé Kč. Objednatel nebude akceptovat zaokrouhlení a haléřové vyrovnání v případě
uvedení na faktuře/daňovém dokladu nebude hradit.

ČÁST 5 - ZMĚNA CENY SLUŽEB

19. Změna ceny služeb je možná pouze v případě
19.1. víceprací nebo méněprací,
19.2. zjistí-li Poskytovatel při kontrole projektové dokumentace předané mu
Objednatelem vady nebo její nevhodnost či neúplnost, které mají vliv na náklady
Poskytovatele,
19.3. v jiných případech jen pokud se na tom Smluvní strany dohodnou.

20. V případě víceprací i méněprací Poskytovatel provede ocenění jejich soupisu jednotkovými
cenami položkového rozpočtu, je-li ve Smlouvě o poskytování služeb zahrnut.

21. Pokud práce, dodávky nebo služby nebudou v položkovém rozpočtu obsaženy nebo
položkový rozpočet není ve Smlouvě o poskytování služeb zahrnut, užije se pro jejich
ocenění cena obvyklá.

4/18
22. V případě vad, nevhodnosti nebo neúplnosti projektové dokumentace, kterou předal
Objednatel Poskytovateli, je-li taková projektová dokumentace součástí Smlouvy o
poskytování služeb, mají-li takové vady, nevhodnosti nebo neúplnosti vliv na náklady
Poskytovatele, postupují smluvní strany obdobně jako při oceňování víceprací nebo
méněprací.

23. Změnu Ceny služeb lze provést jen uzavřením dodatku ke Smlouvě o poskytování služeb.

ČÁST 6 - PLATEBNÍ PODMÍNKY

24. Objednatel neposkytuje zálohy.
25. Poskytovatel vyúčtuje Objednateli Cenu služeb a případnou DPH Výzvou k úhradě.
26. Cenu služeb a případnou DPH je Objednatel povinen uhradit Poskytovateli do 30 dnů ode

dne převzetí Služeb; má-li být dle Smlouvy o poskytování služeb proveden též zkušební
provoz, pak do 30 dnů ode dne úspěšného ukončení zkušebního provozu, nastane-li den
skončení zkušebního provozu později než převzetí Služeb Objednatelem.
27. Cena služeb a případná DPH je uhrazena dnem jejich odepsání z bankovního účtu
Objednatele.
28. Je-li Výzva k úhradě fakturou, musí obsahovat náležitosti účetního dokladu dle §11 ZoÚ
a náležitosti stanovené v §435 Občanského zákoníku.
29. Je-li Výzva k úhradě daňovým dokladem, musí obsahovat náležitosti daňového dokladu
dle §28 ZoDPH a náležitosti stanovené v §435 Občanského zákoníku.
30. Výzva k úhradě musí vždy obsahovat číslo Smlouvy o poskytování služeb, včetně uvedení
uzavřených dodatků, její přílohou musí být vždy jedno vyhotovení Protokolu o převzetí
potvrzeného Objednatelem. Ve výzvě k úhradě musí být vždy uvedeny jako identifikace
Objednatele nejméně následující údaje:
Správa železnic, státní organizace
Dlážděná 1003/7, 110 00 Praha 1 – Nové Město
IČO: 709 94 234
Obchodní rejstřík u Městského soudu v Praze, sp. zn. A 48384
31. Výzvu k úhradě je Poskytovatel povinen doručit Objednateli nejpozději 15 dnů před
uplynutím doby uvedené v odstavci 26 Obchodních podmínek.
32. Výzvy k úhradě, vč. všech příloh, budou Objednateli zasílány následovně:
32.1. v digitální podobě na e-mailovou adresu ePodatelnaCFU@spravazeleznic.cz, nebo
32.2. v digitální podobě do datové schránky s identifikátorem Uccchjm, nebo
32.3. v listinné podobě ve dvou vyhotoveních na adresu Správa železnic, státní

organizace, Centrální finanční účtárna Čechy, Náměstí Jana Pernera 217, 530 02
Pardubice, nebo
32.4. prostřednictvím kontaktního formuláře na webových stránkách Objednatele
https://www.spravazeleznic.cz/kontakty/podatelna.
Objednatel upřednostňuje příjem Výzev k úhradě v digitální podobě ve formátu PDF/A,
ISO 19005, min. verze PDF/A-2b, na výše uvedené emailové adrese. V případě, že je
Výzva k úhradě zasílána na výše uvedenou e-mailovou adresu, považuje se za
doručenou po obdržení notifikace doručení, která je automaticky odesílána
odesílateli.
33. Splatnost Výzvy k úhradě musí být stanovena tak, aby nenastala dříve, než uplyne doba
stanovená v odstavci 26 Obchodních podmínek.
34. Stanoví-li Výzva k úhradě splatnost delší, než je jako minimální stanovena v předchozím
odstavci, je Objednatel oprávněn uhradit Cenu služeb a případnou DPH ve lhůtě splatnosti
určené ve Výzvě k úhradě.
35. Stane-li se Poskytovatel nespolehlivým plátcem nebo daňový doklad Poskytovatele bude
obsahovat číslo bankovního účtu, na který má být plněno, aniž by bylo uvedeno ve
veřejném registru spolehlivých účtů, je objednatel oprávněn z finančního plnění uhradit
daň z přidané hodnoty přímo místně a věcně příslušnému správci daně Poskytovatele.
36. Je-li ve Smlouvě o poskytování služeb výslovně stanoveno, že Poskytovatel bude předávat
Objednateli Služby po částech, je Poskytovatel oprávněn vystavit Výzvu k úhradě

5/18
předávané části Služeb poté, co Objednatel převezme příslušnou část Služeb. Ustanovení
odstavců 26 - 33 Obchodních podmínek se užijí obdobně.
37. Ustanovení §2611, §2620–2622 a §2624 Občanského zákoníku se neužijí.

ČÁST 7 - MÍSTO PLNĚNÍ

38. Poskytovatel je povinen předat Objednateli Služby v místě, jež vyplývá ze Smlouvy o
poskytování služeb. Nelze-li takto místo předání Služeb zjistit, vyzve Poskytovatel
Objednatele, aby sdělil, ve kterém místě má Poskytovatel Objednateli Služby předat.
Nesdělí-li Objednatel místo plnění do 5 pracovních dnů ode dne doručení výzvy
Poskytovatele, je Poskytovatel povinen Služby předat Objednateli v sídle Objednatele.

ČÁST 8 - DOBA PLNĚNÍ

39. Poskytovatel je povinen zahájit provádění Služeb bez zbytečného odkladu po uzavření
Smlouvy o poskytování služeb.

40. Je-li součástí povinností Poskytovatele doprava Služeb po jeho zhotovení do místa plnění
dle Smlouvy o poskytování služeb, je Poskytovatel povinen dopravit Služby do místa plnění
v pracovní den v době od 8 do 15 hodin. Dodá-li Poskytovatel Služby Objednateli v jiné
než uvedené době, je Objednatel oprávněn odmítnout Služby převzít a není zároveň
v prodlení s převzetím Služeb. Připadne-li konec sjednané doby plnění na sobotu, neděli
nebo svátek, není Poskytovatel v prodlení, dodá-li Služby nejblíže následující pracovní den
v časovém rozmezí dle tohoto odstavce.

41. Není-li stanoveno jinak, je Poskytovatel povinen začít s plněním svých povinností vždy
bez zbytečného odkladu.

42. Zjistí-li Poskytovatel jakékoliv skutečnosti, které by mohly mít vliv na dobu plnění, je
Poskytovatel povinen bez zbytečného odkladu Objednatele o takových skutečnostech
informovat.

ČÁST 9 - PROVÁDĚNÍ SLUŽEB

43. Poskytovatel provede Služby s potřebnou péčí v ujednaném čase a obstará vše, co je k
provedení Služeb potřeba.

44. Při provádění Služeb postupuje Poskytovatel samostatně, je však vázán příkazy
Objednatele ohledně způsobu provádění Služeb.

45. Poskytovatel se zavazuje brát v úvahu veškeré upozornění Objednatele, týkající se
realizace Služeb a upozorňující na možné porušování smluvních i právními předpisy
stanovených povinností Poskytovatele.

46. Poskytovatel je povinen upozornit Objednatele bez zbytečného odkladu na nevhodnou
povahu věcí převzatých od Objednatele nebo příkazů daných mu Objednatelem k
provedení Služeb, jestliže Poskytovatel mohl tuto nevhodnost zjistit při vynaložení odborné
péče.

47. Překáží-li nevhodná věc nebo příkaz v řádném provádění Služeb, Poskytovatel je v
nezbytném rozsahu přeruší až do výměny věci nebo změny příkazu; trvá-li Objednatel na
provádění Služeb s použitím předané věci nebo podle daného příkazu, má Poskytovatel
právo požadovat, aby tak Objednatel učinil v písemné formě.

48. Doba stanovená pro dokončení Služeb se prodlužuje o dobu vyvolanou přerušením
dle předchozího odstavce.

49. Trvá-li Objednatel na provádění Služeb s použitím předané věci nebo podle daného příkazu
a zachová-li se Poskytovatel podle toho, nemá Objednatel práva z vady Služeb vzniklé
pro nevhodnost věci nebo příkazu.
Harmonogram

50. Je-li dle Smlouvy o poskytování služeb vyžadován Harmonogram provádění Služeb, je
Poskytovatel povinen jej předložit Objednateli bez zbytečného odkladu po uzavření

6/18
Smlouvy o poskytování služeb, nejpozději však do 10 dnů ode dne uzavření Smlouvy o
poskytování služeb.
51. Poskytovatel je povinen udržovat harmonogram v aktuálním stavu a v případě změny vždy
předat Objednateli bezodkladně aktualizovaný harmonogram.
Kontrola provádění prací
52. Objednatel je oprávněn kontrolovat provádění Služeb. Zjistí-li objednatel, že Poskytovatel
provádí Služby v rozporu s povinnostmi vyplývajícími ze Smlouvy o poskytování služeb,
Obchodních podmínek, Veřejnoprávních podkladů, právních předpisů nebo příslušných
ČSN, je Objednatel oprávněn dožadovat se toho, aby Poskytovatel odstranil vady vzniklé
vadným prováděním a Služby prováděl řádným způsobem. Jestliže tak Poskytovatel
neučiní v přiměřené lhůtě, jedná se o podstatné porušení Smlouvy o poskytování služeb.
53. Poskytovatel je povinen písemně vyzvat Objednatele ke kontrole a prověření prací, které
v dalším postupu budou zakryty nebo se stanou nepřístupnými. Poskytovatel je povinen
vyzvat Objednatele nejméně 3 pracovní dny před termínem, v němž budou předmětné
práce zakryty nebo znepřístupněny.
54. Před zakrytím nebo znepřístupněním prací je Poskytovatel povinen pořídit podrobnou
fotodokumentaci prací a předat ji Objednateli v digitální podobě na CD nebo DVD nosiči
bez zbytečného odkladu po pořízení fotodokumentace.
55. Pokud se Objednatel ke kontrole přes včasné písemné vyzvání nedostaví, je Poskytovatel
oprávněn předmětné práce zakrýt. Bude-li se v tomto případě Objednatel dodatečně
požadovat jejich odkrytí, je Poskytovatel povinen toto odkrytí provést na náklady
Objednatele. Pokud se však zjistí, že práce nebyly řádně provedeny, nese veškeré náklady
spojené s odkrytím prací, opravou chybného stavu a následným zakrytím Poskytovatel.
56. Obdobně bude-li Objednatel požadovat vykonání zvláštních zkoušek nebo ověření
jakékoliv části Služeb z důvodu podezření, že tato část Služeb neodpovídá Smlouvě o
poskytování služeb, Obchodním podmínkám, Veřejnoprávním podkladům, právním
předpisům nebo příslušným ČSN, a bude-li zjištěno, že podezření bylo správné, nese
náklady spojené s vykonáním zkoušek nebo ověřením Poskytovatel.
57. Poskytovatel je povinen umožnit výkon technického a autorského dozoru.
Kontrolní dny
58. Pro účely kontroly průběhu provádění Služeb může Objednatel nebo jím pověřená osoba
provést kontrolní dny v termínech nezbytných pro řádné provádění kontroly.
59. Kontrolních dnů se zúčastní zástupci Objednatele případně osob vykonávajících funkci
technického dozoru a autorského dozoru.
60. Zástupci Poskytovatele jsou povinni se kontrolních dnů zúčastňovat. Poskytovatel má
právo přizvat na kontrolní den své poddodavatele podílející se v souladu se Smlouvou o
poskytování služeb a Obchodními podmínkami na provádění Služeb.
61. Kontrolní dny vede Objednatel nebo jím pověřená osoba.
62. Obsahem kontrolního dne je zejména zpráva Poskytovatele o postupu prací, kontrola
postupu prací, připomínky a podněty osob vykonávajících funkci technického a autorského
dozoru a stanovení případných nápravných opatření a úkolů.
63. Objednatel nebo jím pověřená osoba pořizuje z kontrolního dne zápis, který předá všem
zúčastněným.
Dodržování zákazu požívání alkoholických nápojů a užívání jiných návykových
látek
64. Objednatel je oprávněn provádět u všech osob, které Poskytovatel používá při provádění
služeb, kontrolu, zda tyto osoby nejsou pod vlivem alkoholu nebo návykové látky. Osoby
Objednatele oprávněné k provádění této kontroly určí ředitel organizační jednotky Správy
železnic, státní organizace opatřením. V podmínkách Ředitelství Správy železnic, státní
organizace vydá toto opatření ředitel odboru personálního.
65. Poskytovatel seznámí své zaměstnance a osoby, které používá při provádění služeb s
povinností podrobit se kontrole prováděné Objednatelem.
66. Kontrola bude prováděna orientační dechovou zkouškou na přítomnost alkoholu a slinným
testem na přítomnost návykových látek.

7/18
67. Kontrola bude prováděna dle části třetí body 3.2–3.5 a části čtvrté body 4.2–4.5 Pokynu
generálního ředitele č. 3/2011 „Dodržování zákazu požívání alkoholických nápojů a užívání
jiných návykových látek“ č.j.: 12 373/10-PERS účinného od 1. 8. 2011.

68. Pozitivní výsledek ověření bude neprodleně oznámen Poskytovateli (telefonicky, emailem).

69. Náklady na vyšetření v případě pozitivního výsledku uhradí Poskytovatel.
70. V případě pozitivního výsledku kontroly nesmí dotčená osoba Poskytovatele pokračovat ve

vykonávané činnosti a bude jí odebrán „Průkaz ke vstupu do objektů a provozované
železniční dopravní cesty Správy železnic, státní organizace“.

71. V případě, že osoba, kterou Poskytovatel používá při provádění služeb, se odmítne podrobit
zjištění, zda není pod vlivem alkoholu nebo návykové látky, nebo je-li u této osoby
dosaženo pozitivního výsledku kontroly, je Objednatel oprávněn na základě posouzení
souvisejících okolností, uplatnit vůči Poskytovateli sankci až do výše 100 000,- Kč za každý
jednotlivý případ.

Dodržování podmínek stanovisek příslušných orgánů a organizací
72. Poskytovatel se zavazuje dodržet při provádění Služeb veškeré podmínky vyplývající

z Veřejnoprávních podkladů.
73. Pokud nesplněním těchto podmínek vznikne Objednateli škoda, je Poskytovatel povinen

nahradit škodu v plném rozsahu, ledaže prokáže, že škodě nemohl zabránit ani v případě
vynaložení veškeré možné péče, kterou na něm lze spravedlivě požadovat.

Použité materiály a výrobky
74. Poskytovatel se zavazuje a odpovídá za to, že při realizaci Služeb nepoužije žádný materiál,

o kterém je v době jeho užití známo, že je škodlivý. Pokud tak Poskytovatel učiní, je
povinen na vyzvání Objednatele provést nápravu, přičemž veškeré náklady s tím spojené
nese Poskytovatel.
75. Poskytovatel se zavazuje, že k realizaci Služeb nepoužije materiály, které nemají
požadovanou certifikaci či předepsaný průvodní doklad, je-li to pro jejich použití nezbytné
podle Smlouvy o poskytování služeb, Obchodních podmínek, Veřejnoprávních podkladů,
právních předpisů nebo příslušných ČSN. Certifikace a průvodní doklady Poskytovatele
použitých materiálů jsou součástí Dokladů.

Částečné plnění
76. Nabízí-li Poskytovatel Objednateli částečné plnění Předmětu služeb, aniž by částečné

plnění bylo výslovně sjednáno ve Smlouvě o poskytování služeb, není Objednatel povinen
částečné plnění přijmout. Přijme-li Objednatel částečné plnění, je Poskytovatel povinen
nahradit Objednateli zvýšené náklady způsobené mu částečným plněním.

Ostatní ujednání
77. Vícepráce lze provést a méněpráce neprovést až poté, co budou vícepráce nebo méněpráce

dohodnuty včetně změn Ceny služeb dodatkem ke Smlouvě o poskytování služeb.
Provede-li Poskytovatel vícepráce v rozporu s tímto odstavcem, ponese náklady na ně ze
svého.
78. Dojde-li k jakémukoliv úrazu při provádění Služeb nebo při činnostech souvisejících s
prováděním Služeb je Poskytovatel povinen zabezpečit vyšetření úrazu a sepsání
příslušného záznamu. Objednatel je povinen poskytnout Poskytovateli nezbytnou
součinnost.
79. Žádný z podkladů, které Poskytovatel převzal od Objednatele v souvislosti s Dílem ani
žádný Doklad není Poskytovatel oprávněn bez předchozího písemného svolení Objednatele
užít k jiným účelům, než je provedení Služeb, zejména je nesmí poskytnout třetím osobám.
80. Poskytovatel je povinen při provádění Služeb postupovat v součinnosti s případnými jinými
dodavateli Objednatele, a to dle pokynů udělených Objednatelem a nebudou-li pokyny
uděleny, postupovat tak, aby umožnil ostatním dodavatelům v co největší míře plnit jejich
závazky.
81. Objednatel se zavazuje poskytovat Poskytovateli součinnost při provádění Služeb v
rozsahu a způsobem, ve kterém lze tuto součinnost po Objednateli spravedlivě požadovat.
Bude-li Poskytovatelem požadována po Objednateli jakákoliv součinnost dle předchozí
věty, je Poskytovatel povinen Objednatele k jejímu poskytnutí s dostatečným předstihem
vyzvat a ve výzvě ji dostatečně specifikovat.

8/18
82. Poskytovatel na sebe přebírá nebezpečí změny okolností ve smyslu §1765 Občanského
zákoníku.

83. Ustanovení §1912, §2595 Občanského zákoníku se neužijí.

ČÁST 10 - ZKUŠEBNÍ PROVOZ

84. Ustavení této části se užijí v případě, že ze Smlouvy o poskytování služeb nebo z povahy
Předmětu služeb vyplývá, že má být proveden zkušební provoz.

85. Zkušebním provozem se prověřuje, zda Předmět služeb je za předpokládaných provozních
a výrobních podmínek schopen dosahovat výkonů (parametrů) v kvalitě a množství
stanovených Smlouvou o poskytování služeb, Obchodními podmínkami, Veřejnoprávními
podklady, právními předpisy a příslušnými ČSN.

86. Zkušební provoz je Poskytovatel povinen provést před předáním Služeb Objednateli, do
doby úspěšného provedení zkušebního provozu není Služby dokončeno.

87. Zkušební provoz musí trvat minimálně 48 hodin, nestanoví-li Veřejnoprávní podklady,
právní předpisy nebo příslušné ČSN jinak.

88. Poskytovatel se zavazuje v průběhu zkušebního provozu neprodleně odstraňovat veškeré
vady, které bude Předmět služeb vykazovat.

89. Zkušební provoz bude úspěšně proveden, nebude-li Předmět služeb k poslednímu dni doby
stanovené pro zkušební provoz vykazovat vady bránící jeho užívání.

90. Bude-li k poslednímu dni doby zkušebního provozu Předmět služeb vykazovat vady bránící
užívání, prodlužuje se délka trvání zkušebního provozu o dobu dle dohody Smluvních stran,
jinak o 24 hodin.

91. Úspěšné provedení zkušebního provozu je podmínkou převzetí služeb Objednatelem.

ČÁST 11 - PŘEPRAVA SLUŽEB

92. Ustavení této části se užijí v případě, je-li Služby po svém zhotovení za účelem předání
Objednateli přepravováno.

93. Je-li dle Smlouvy o poskytování služeb nebo zvyklostí třeba Předmět služeb zabalit,
Poskytovatel Předmět služeb zabalí dle Smlouvy o poskytování služeb; není-li ujednání o
balení Předmětu služeb ve Smlouvě o poskytování služeb, pak dle zvyklostí, a není-li jich,
pak způsobem potřebným pro uchování Předmětu služeb a jeho ochranu.

94. Jestliže Poskytovatel označí Obalový materiál nejpozději do doby převzetí Předmětu služeb
Objednatelem jako vratný, a to přímo na Obalovém materiálu, v Dokladech nebo jiným
zřejmým způsobem, ze kterého bude zřejmé, který Obalový materiál je vratný, je
Objednatel oprávněn předat Poskytovateli při předávacím řízení (viz ČÁST 13 - Obchodních
podmínek) stejné množství Obalového materiálu téhož druhu a srovnatelného nebo nižšího
stupně opotřebení. V rozsahu předání Obalového materiálu Objednatelem Poskytovateli
dle předchozí věty zaniká právo Poskytovatele na vrácení Obalového materiálu.

95. V rozsahu, v němž Objednatel nevrátí vratný Obalový materiál Poskytovateli dle
předchozího odstavce, je Poskytovatel oprávněn Objednateli vyúčtovat zálohu na vratný
Obalový materiál. Výše zálohy nesmí přesáhnout dvojnásobek pořizovací ceny Obalového
materiálu.

96. Doposud nevrácený vratný Obalový materiál je Objednatel povinen na vlastní náklady
dopravit do sídla Poskytovatele, a to nejpozději do jednoho roku od převzetí Předmětu
služeb Objednatelem. Objednatel je oprávněn nahradit nevrácený vratný Obalový materiál
Obalovým materiálem stejného druhu a srovnatelného nebo nižšího stupně opotřebení.
Bez zbytečného odkladu po převzetí vráceného Obalového materiálu nebo jeho náhrady
Poskytovatelem, je Poskytovatel povinen vrátit Objednateli zaplacenou zálohu na vratný
Obalový materiál. Nevrátí-li Objednatel dosud nevrácený vratný Obalový materiál nebo
Obalový materiál stejného druhu a srovnatelného nebo nižšího stupně opotřebení ani do
dvou let od převzetí Předmětu služeb Objednatelem, stává se nevrácený vratný Obalový
materiál vlastnictvím Objednatele a složená záloha se stává vlastnictvím Poskytovatele.

9/18
97. Pokud Poskytovatel Předmět služeb Objednateli odesílá prostřednictvím dopravce, umožní
98. Poskytovatel Objednateli uplatnit práva z přepravní smlouvy vůči dopravci, pokud o to
99. Objednatel Poskytovatele požádá.
100. Pokud Poskytovatel Předmět služeb Objednateli odesílá prostřednictvím dopravce, je
Poskytovatel povinen zajistit dopravu u dopravce tak, aby Předmět služeb byl dodán
Objednateli v době uvedené v odstavci 40 Obchodních podmínek.
Je-li třeba provést vyložení Předmětu služeb z dopravního prostředku, je vyložení povinen
provést Poskytovatel na své náklady.
Je-li Objednatel v prodlení s převzetím Předmětu služeb, uchová jej Poskytovatel, může-li
s ním nakládat, pro Objednatele způsobem přiměřeným okolnostem. Převzal-li Objednatel
Předmět služeb, který zamýšlí odmítnout, uchová jej způsobem přiměřeným okolnostem.
Smluvní strana, která uchovává Předmět služeb pro druhou Smluvní stranu, má právo na
náhradu účelně vynaložených nákladů spojených s uchováním Předmětu služeb, nemůže
jej však za účelem zajištění svého práva na úhradu nákladů zadržet.

ČÁST 12 - PODDODAVATELÉ

101. Poskytovatel je oprávněn pověřit provedením části Služeb třetí osobu – poddodavatele.
102. Poskytovatel odpovídá za činnost poddodavatele tak, jako by činnost prováděl sám.
103. Poskytovatel je oprávněn pověřit provedením části Služeb poddodavatele pouze, pokud
je poddodavatel uveden v příloze Smlouvy o poskytování služeb.
104. Poskytovatel se zavazuje, že poddodavatelé splní všechny povinnosti vyplývající
Poskytovateli ze Smlouvy o poskytování služeb, a to přiměřeně k povaze a rozsahu
105. poddodávky.
Poskytovatel se zavazuje, že poddodavatelé, kterými prokazoval splnění kvalifikace v
zadávacím řízení, se budou podílet na provedení příslušné věcně vymezené části Služeb v
rozsahu dle Nabídky Poskytovatele.
Poskytovatel je oprávněn změnit poddodavatele pouze s předchozím písemným souhlasem
Objednatele. Objednatel vydá písemný souhlas se změnou do 10 dnů od doručení žádosti
Poskytovatele. Objednatel souhlas se změnou nevydá, pokud
105.1. prostřednictvím původního poddodavatele Poskytovatel v zadávacím řízení

prokazoval kvalifikaci a nový poddodavatel nebude mít stejnou či vyšší kvalifikaci
jako původní nahrazovaný poddodavatel nebo
105.2. po Objednateli nelze spravedlivě požadovat, aby s takovou změnou souhlasil.

ČÁST 13 - PŘEDÁNÍ A PŘEVZETÍ SLUŽEB

106. Závazek Poskytovatele provést Služby je splněn jeho dokončením a převzetím Služeb
107. Objednatelem, včetně převzetí veškerých Dokladů.
Součástí Dokladů je dle povahy a charakteru Služeb též
108. 107.1. dodavatelská výrobní a dílenská dokumentace,
109. 107.2. atesty, záruční listy, prohlášení o shodě všech věcí, jež byly použity při provádění

Služeb,
107.3. zápisy a osvědčení o všech předepsaných zkouškách, měřeních,
107.4. dokumenty osvědčující průběh zkušebního provozu,
107.5. servisní plán, návod k obsluze a návod k použití částí Služeb,
107.6. doklady o zabezpečení likvidace odpadů v souladu s právními předpisy,
107.7. fotodokumentace z průběhu provádění Služeb, zejména fotodokumentace prací

a konstrukcí, které byly dalším postupem prací zakryté nebo jinak znepřístupněné,
V případě, že Smlouva o poskytování služeb, Obchodní podmínky, Veřejnoprávní podklady,
právní předpisy nebo příslušné ČSN předepisují provedení zkoušek, revizí, atestů a měření
či zajištění prohlášení o shodě týkajících se Služeb, je Poskytovatel povinen zajistit jejich
úspěšné provedení před předáním Služeb Objednateli.
Objednatel Služby převezme za předpokladu, že provedení Služeb odpovídá Smlouvě o
poskytování služeb, Obchodním podmínkám, Veřejnoprávním podkladům, právním

10/18
110. předpisům a příslušným ČSN, je dokončeno (plně funkční), a je prosté vad s výjimkou
111. ojedinělých drobných vad, které samy o sobě ani ve spojení s jinými nebrání užívání Služeb
112. funkčně nebo esteticky, ani jeho užívání podstatným způsobem neomezují.
113. Splnění podmínek pro předání Služeb bude ověřeno v rámci přejímacího řízení.
Poskytovatel je povinen písemně vyzvat Objednatele k převzetí Služeb (zahájení
114. přejímacího řízení). Přejímací řízení bude Objednatelem zahájeno do 5 pracovních dnů po
115. obdržení písemné výzvy Poskytovatele.
Objednatel je oprávněn přizvat k účasti v přejímacím řízení i jiné osoby, jejichž účast
116. pokládá za nezbytnou.
117. O průběhu přejímacího řízení bude Poskytovatelem pořízen zápis s identifikací vad Služeb,
pokud budou v průběhu přejímacího řízení zjištěny. Zápis bude použit jako podklad pro
118. zpracování Předávacího protokolu. Zpracování návrhu Předávacího protokolu zajistí
119. Poskytovatel.
120. Předávací protokol obsahuje
121. 113.1. výslovný souhlas Objednatele s převzetím Služeb
113.2. datum převzetí Služeb,
113.3. prohlášení Objednatele, zda přebírá Služby bez výhrad, nebo s výhradami,
113.4. soupis zjištěných vad nebránících řádnému užívání Služeb,
113.5. dohodnuté lhůty k odstranění zjištěných vad nebo jiná opatření (byla-li

dohodnuta),
113.6. soupis Dokladů předaných Poskytovatelem Objednateli.
Objednatel převezme Služby bez výhrad, je-li v předávacím řízení zjištěno, že Služby je
prosté vad.
Převezme-li Objednatel Služby s výhradami, postupují Smluvní strany dále obdobně
dle ustanovení odstavců 144 - 158 Obchodních podmínek, přičemž pro odstranění vad
platí doba sjednaná v Předávacím protokolu, jinak doba 15 dní od oboustranného podpisu
Předávacího protokolu a za reklamaci se považuje identifikace vad uvedená v Předávacím
protokolu podepsaném Objednatelem.
V případě, že Objednatel Služby nepřevezme, bude mezi Smluvními stranami sepsán
záznam s uvedením důvodu nepřevzetí Služeb a s uvedením stanovisek Smluvních stran.
Zpracování záznamu zajistí Poskytovatel.
V případě nepřevzetí Služeb Smluvní strany sjednají lhůtu pro odstranění zjištěných vad.
Nebude-li vada odstraněna ve lhůtě sjednané, jinak do 15 dní, je Objednatel oprávněn
zajistit odstranění vady jinou odborně způsobilou osobou na náklady Poskytovatele.
Veškeré náklady vzniklé Objednateli v souvislosti s odstraněním vady způsobem dle
předchozí věty je Poskytovatel povinen Objednateli uhradit. Poskytovatel je povinen ve
stanovené lhůtě odstranit vady i v případě, kdy podle jeho názoru za vady neodpovídá.
Náklady na odstranění v těchto sporných případech nese až do vyjasnění nebo do vyřešení
rozporu Poskytovatel. Po odstranění vad vyzve Poskytovatel Objednatele k zahájení
náhradního přejímacího řízení, které Objednatel zahájí bezodkladně, nejpozději do 2
pracovních dnů od obdržení výzvy Poskytovatele.
Podpisem Předávacího protokolu nebo záznamu o nepřevzetí Služeb je přejímací řízení
ukončeno.
Pro průběh náhradního přejímacího řízení se užijí ustanovení odstavců 109 - 118
Obchodních podmínek obdobně.
Připouští-li to povaha Předmětu služeb, a není-li sjednán zkušební provoz, má Objednatel
právo, aby byl Předmět služeb před ním překontrolován nebo aby byly předvedeny jeho
funkce.
Ustanovení §1921, §2112, §2605 odst. 2, §2606, §2609, §2618 a §2629 Občanského
zákoníku se neužijí.

ČÁST 14 - VLASTNICKÉ PRÁVO A NEBEZPEČÍ ŠKODY
122. Vlastnické právo k Dílu náleží od počátku Objednateli.

11/18
123. Vlastnické právo k dodávkám materiálu a jiných hmotných movitých věcí nabývá
124. Objednatel okamžikem jejich zapracování do Služeb, učiněním součástí Služeb nebo
125. jakýmkoliv funkčním, estetickým či jiným spojením s Dílem.
126. Vlastnické právo k jakékoli dokumentaci vztahující se k Dílu, která není autorským dílem,
nabývá Objednatel okamžikem jejího vyhotovení.
127. Je-li vlastníkem Služeb nebo jeho části v souladu s §1083 a §1084 Občanského zákoníku
128. vlastník pozemku, užijí se ustanovení odstavců 122 a 123 přiměřeně.
129. Nebezpečí škody na Díle nese Poskytovatel, na Objednatele přechází okamžikem
oboustranného podpisu Předávacího protokolu. Pokud nebyly s Předmětem služeb předány
zároveň též všechny Doklady, nese Poskytovatel nebezpečí škody na dosud nepředaných
Dokladech až do jejich převzetí Objednatelem.
Náklady nutné k odstranění škody na Díle vzniklé v době, kdy nebezpečí škody nese
Poskytovatele, hradí Poskytovatel v plném rozsahu a tyto náklady nemají vliv na Cenu
služeb.
Škody na Díle vzniklé v době, kdy nebezpečí škody nese Poskytovatele, je povinen
Poskytovatel odstranit v součinnosti s Objednatelem jako vlastníkem poškozené věci a dle
jeho pokynů.
Ustanovení §2599 Občanského zákoníku se neužijí.

ČÁST 15 - VADY PLNĚNÍ A ZÁRUKA

130. Poskytovatel se zavazuje, že Služby bude v okamžiku jeho převzetí Objednatelem
vyhovovat všem požadavkům na Služby stanoveným Smlouvou o poskytování služeb,
131. Obchodními podmínkami, Veřejnoprávními podklady, právními předpisy a příslušnými
132. ČSN.
133. Poskytovatel se zavazuje, že Služby bude vyhovovat též plnění nabídnutému
134. Poskytovatelem v Nabídce.
Služby musí být prosté všech faktických a právních vad. Plnění má právní vadu, pokud
135. k němu uplatňuje právo třetí osoba.
136. Poskytovatel se zavazuje (poskytuje Objednateli záruku), že Služby a veškeré jeho části
137. si po celou dobu od okamžiku jeho převzetí Objednatelem, až do uplynutí Záruční doby
zachová vlastnosti stanovené v odstavcích 130 - 132 Obchodních podmínek.
138. Záruční doba začíná běžet dnem převzetí Služeb Objednatelem, nebo jeho poslední části,
139. je-li Služby dodáváno po částech, nebo ode dne úspěšného ukončení zkušebního provozu,
je-li dle Smlouvy o poskytování služeb vyžadován a nastane-li okamžik úspěšného
140. ukončení zkušebního provozu později než okamžik převzetí Služeb, resp. jeho poslední
části.
Služby má vady (Poskytovatel plnil vadně), jestliže při převzetí Objednatelem nebo
kdykoliv od převzetí Objednatelem do konce Záruční doby nebude mít vlastnosti stanovené
v odstavcích 130 - 132 Obchodních podmínek.
Objednatel má práva z vadného plnění i v případě, jedná-li se o vadu, kterou musel
s vynaložením obvyklé pozornosti poznat již při uzavření Smlouvy o poskytování služeb.
Objednatel nemá práva z vadného plnění, způsobila-li vadu po přechodu nebezpečí škody
na věci na Objednatele vnější událost. To neplatí, způsobil-li vadu Poskytovatel nebo
jakákoliv třetí osoba, jejímž prostřednictvím plnil své povinnosti vyplývající ze Smlouvy o
poskytování služeb.
Poskytovatel neodpovídá za vady spočívající v opotřebení Předmětu služeb, které je
obvyklé u věcí stejného nebo obdobného druhu jako Předmět služeb.
Poskytovatel odpovídá za vady spočívající v opotřebení Předmětu služeb, ke kterému do
konce Záruční doby vzhledem k požadavkům Smlouvy o poskytování služeb, Obchodních
podmínek, Veřejnoprávních podkladů, právních předpisů a příslušných ČSN na jakost a
provedení Předmětu služeb nemělo dojít.
Poskytovatel nenese odpovědnost za vady způsobené Objednatelem nebo třetími osobami,
ledaže Objednatel nebo takové osoby postupovaly v souladu s Doklady nebo pokyny, které
obdrželi od Poskytovatele.

12/18
ČÁST 16 - UPLATNĚNÍ PRÁV Z VADNÉHO PLNĚNÍ

141. Odpovídá-li Poskytovatel za vady Služeb, má Objednatel práva z vadného plnění.
142. Objednatel je oprávněn vady reklamovat u Poskytovatele jakýmkoliv způsobem,
143. preferovaná je písemná forma. Poskytovatel je povinen přijetí reklamace bez zbytečného
144. odkladu písemně potvrdit. V reklamaci Objednatel uvede popis vady nebo uvede, jak se
vada projevuje.
145. Vada je uplatněna včas, je-li písemná forma reklamace odeslána Poskytovateli nejpozději
146. v poslední den Záruční doby. Připadne-li konec Záruční doby na sobotu, neděli nebo
147. svátek, je vada včas uplatněna, je-li písemná forma reklamace odeslána Poskytovateli
148. nejblíže následující pracovní den.
149. Má-li Předmět služeb vady, za které Poskytovatel odpovídá, má Objednatel právo
144.1. na odstranění vady dodáním nového Předmětu služeb nebo jeho části bez vady,

pokud to není vzhledem k povaze vady zcela zřejmě nepřiměřené, nebo dodání
chybějící části Předmětu služeb,
144.2. na odstranění vady opravou Předmětu služeb nebo jeho části,
144.3. na přiměřenou slevu z Ceny služeb, nebo
144.4. odstoupit od Smlouvy o poskytování služeb.
Objednatel je oprávněn požadovat odstranění vad dodáním nového Předmětu služeb nebo
jeho části bez vady, vyskytla-li se stejná vada po její opravě opětovně, nebo nemůže-li
Objednatel řádně užívat Předmět služeb nebo jeho část pro větší počet vad.
Objednatel je oprávněn nároky dle odstavce 144 kombinovat, je-li to vzhledem
k okolnostem možné. Objednatel není oprávněn kombinovat nároky, které si navzájem
odporují (např. dodání nové části Předmětu služeb a zároveň slevy z Ceny služeb na tutéž
část Předmětu služeb).
Objednatel sdělí Poskytovateli volbu nároku z vady v reklamaci, nebo bez zbytečného
odkladu po reklamaci. Provedenou volbu nemůže Objednatel změnit bez souhlasu
Poskytovatele; to neplatí, žádal-li Objednatel opravu vady, která se ukáže jako
neopravitelná.
Nesdělí-li Objednatel Poskytovateli, jaké právo si zvolil ani bez zbytečného odkladu poté,
co jej k tomu Poskytovatel vyzval, může Poskytovatel odstranit vady podle své volby
opravou nebo dodáním nového Předmětu služeb nebo jeho části; volba nesmí Objednateli
způsobit nepřiměřené náklady.
Objednatel má nárok na náhradu nákladů účelně vynaložených v souvislosti s oznámením
vad Poskytovateli.

ČÁST 17 - PODMÍNKY ODSTRANĚNÍ VAD

150. Pokud Objednatel požaduje v reklamaci odstranění vady, je Poskytovatel povinen
151. neprodleně po obdržení reklamace zahájit činnosti vedoucí k odstranění reklamované
152. vady. Pokud Objednatel v reklamaci uvede, že se jedná o havárii, je Poskytovatel povinen
zahájit odstraňování vady nejpozději do 48 hodin po obdržení reklamace.
153. Poskytovatel je povinen odstranit Objednatelem reklamovanou vadu nejpozději do 30 dnů
154. ode dne oznámení vady Poskytovateli. Jde-li o vadu označenou Objednatelem v reklamaci
jako havarijní, je Poskytovatel povinen odstranit vadu nejpozději do 5 dnů.
Nezahájí-li Poskytovatel činnosti vedoucí k odstranění vady do 10 dnů od oznámení vady
Poskytovateli, nebo nebude-li vada odstraněna ve lhůtě dle předcházejícího odstavce,
je Objednatel oprávněn
152.1. zajistit odstranění vady jinou odborně způsobilou právnickou nebo fyzickou osobou

na účet Poskytovatele,
152.2. požadovat slevu z Ceny služeb, nebo
152.3. od Smlouvy o poskytování služeb odstoupit.
Veškeré náklady vzniklé Objednateli v souvislosti s odstranění vady způsobem dle
předchozího odstavce je Poskytovatel povinen Objednateli uhradit.
Poskytovatel je povinen odstranit vadu bez ohledu na to, zda je uplatnění vady oprávněné
či nikoli. Prokáže-li se však kdykoli později, že uplatnění vady Objednatelem nebylo

13/18
155. oprávněné, tj. že Poskytovatel za vadu neodpovídal, je Objednatel povinen uhradit
156. Poskytovateli veškeré jím účelně vynaložené náklady v souvislosti s odstraněním vady.
Objednatel je povinen poskytnout Poskytovateli součinnost nezbytnou k odstranění vady.
157. Do odstranění vady nemusí Objednatel platit dosud nezaplacenou část Ceny služeb a
případnou příslušnou DPH odhadem přiměřeně odpovídající jeho právu na slevu.
158. Při dodání nového Předmětu služeb nebo jeho části vrátí Objednatel Poskytovateli na
náklady Poskytovatele Předmět služeb nebo jeho část původně dodanou.
159. Týká-li se vada Dokladů nebo jiného plnění poskytnutého Poskytovatelem dle Smlouvy o
poskytování služeb než Předmětu služeb, užijí se ustanovení odstavců 141 – 157 obdobně.
Ustanovení §1917–1924, §2099–2101, §2103 – 2117, §2165 – 2172, §2618 a §2629
Občanského zákoníku se neužijí.

ČÁST 18 - POJIŠTĚNÍ

160. Ustanovení této části se užijí v případě, že ze Smlouvy o poskytování služeb vyplývá, že
161. Poskytovatel je povinen být pojištěn pro případ odpovědnosti za škodu způsobenou při
výkonu činnosti.
162. Poskytovatel je povinen mít ode dne zahájení provádění Služeb, nejpozději však do 15 dnů
od uzavření Smlouvy o poskytování služeb, až do uplynutí Záruční doby uzavřenou
163. pojistnou smlouvu o pojištění odpovědnosti za škodu způsobenou Poskytovatelem při
164. výkonu činnosti třetím osobám s limitem pojistného plnění pro 1 pojistnou událost ve výši
165. odpovídající Ceně služeb.
Poskytovatel je povinen předložit Objednateli uzavřenou pojistnou smlouvu dle této části
nebo odpovídající pojistku nejpozději do 15 dnů ode dne uzavření Smlouvy o poskytování
služeb a dále kdykoli v průběhu provádění Služeb nebo trvání Záruční doby do 10 dnů ode
dne, kdy k tomu byl Objednatelem vyzván. V případě změn v pojištění je Poskytovatel
povinen bezodkladně tyto změny oznámit Objednateli a předložit dokumenty dokládající
tyto změny.
Poskytovatel se zavazuje, že všichni poddodavatelé, kteří se budou podílet na provedení
Služeb, budou nejméně po dobu provádění poddodávky pojištěni pro případ škody
způsobené poddodavatelem při výkonu činnosti třetím osobám s limitem pojistného plnění
pro 1 pojistnou událost minimálně ve výši odpovídající ceně poddodávky.
Porušení jakékoli povinnosti Poskytovatele dle této části je podstatným porušením
Smlouvy o poskytování služeb.
Náklady na pojištění nese Poskytovatel, jsou zahrnuty v Ceně služeb.

ČÁST 19 - DUŠEVNÍ VLASTNICTVÍ

166. Poskytovatel je povinen při provádění Služeb postupovat tak, aby při provádění Služeb ani
167. následným užíváním Služeb Objednatelem nedošlo k porušení práv duševního vlastnictví.
Bude-li v souvislosti s Dílem, jakkoliv dotčeno právo k duševnímu vlastnictví, je
168. Poskytovatel povinen upravit veškeré právní vztahy s osobami, kterým taková práva
náležejí nebo jež jsou oprávněny je vykonávat, tak, aby zamezil vznášení jakýchkoli
oprávněných nároků těchto osob ve vztahu k Objednateli.
Poskytovatel tímto poskytuje Objednateli oprávnění k výkonu práva duševního vlastnictví
(licenci nebo podlicenci) ke všem plněním poskytnutým Objednateli při provádění Služeb,
které jsou nebo budou předmětem duševního vlastnictví a ke kterým je oprávněn takové
oprávnění poskytnout. Oprávnění Poskytovatel poskytuje
167.1. bezúplatně,
167.2. jako nevýhradní,
167.3. z hlediska časového a územního v rozsahu neomezeném,
167.4. z hlediska věcného rozsahu (způsobu užití) tak, že opravňuje Objednatele ke všem

známým způsobům užití,
167.5. bez množstevního omezení.
Objednatel není povinen oprávnění využít.

14/18
169. Objednatel je oprávněn oprávnění tvořící součást licence nebo podlicence poskytnout nebo
170. též postoupit třetí osobě zcela nebo zčásti.
Poskytovatel se zavazuje, že na žádost Objednatele autor nebo autoři autorského služeb,
171. jež je součástí nebo příslušenstvím Služeb, udělí Objednateli bez zbytečného odkladu
bezúplatně právo
170.1. upravit či jinak změnit označení autora,
170.2. autorské Služby nebo jeho název upravit či jinak měnit,
170.3. autorské Služby s jakýmkoliv jiným autorským dílem spojit či zařadit do služeb

souborného.
Žádný výsledek činnosti provedené na základě Smlouvy o poskytování služeb nebo
v souvislosti s ní, který je předmětem duševního vlastnictví, není Poskytovatel oprávněn
bez předchozího písemného svolení Objednatele užít k jiným účelům, než je provedení
Služeb, zejména je nesmí poskytnout třetím osobám.

ČÁST 20 - SANKCE

172. Poruší-li Poskytovatel povinnost provést Služby ve sjednané době, je Poskytovatel povinen
173. uhradit Objednateli smluvní pokutu ve výši 0,5 % z Ceny služeb za každý den prodlení.
174. Poruší-li Objednatel povinnost zaplatit Cenu služeb ve sjednané době, je povinen uhradit
Poskytovateli zákonný úrok z prodlení ve výši dle právních předpisů.
175. Poruší-li Poskytovatel povinnost odstranit vadu Služeb ve sjednané době, je povinen
uhradit Objednateli smluvní pokutu ve výši 0,5 % z Ceny služeb za každý den prodlení až
176. do odstranění vady. Jde-li o vadu, kterou Objednatel označil v reklamaci jako havárii, je
Poskytovatel povinen uhradit smluvní pokutu ve dvojnásobné výši.
177. Poruší-li Poskytovatel povinnost nepostoupit žádnou svou pohledávku za Objednatelem
178. vyplývající ze Smlouvy o poskytování služeb a/nebo poruší zákaz zřídit zástavní právo k
pohledávce, byť by takové postoupení a/nebo zřízení zástavního práva bylo neplatné či
neúčinné, je Poskytovatel povinen uhradit Objednateli smluvní pokutu ve výši 10 %
z nominální hodnoty postoupené a/nebo zastavené pohledávky, včetně hodnoty
případného příslušenství ke dni účinnosti postoupení vůči postupníkovi.
Poruší-li Poskytovatel jakékoliv jiné povinnosti vyplývající ze Smlouvy o poskytování
služeb, Obchodních podmínek nebo Veřejnoprávních podkladů než povinnosti, na které se
vztahuje smluvní pokuta dle této části, je Poskytovatel povinen uhradit Objednateli
smluvní pokutu ve výši 5% z Ceny služeb za každý jednotlivý případ porušení povinnosti.
Zaplacení smluvní pokuty nezbavuje Poskytovatele povinnosti splnit dluh smluvní pokutou
utvrzený.
Objednatel je oprávněn požadovat náhradu škody a nemajetkové újmy způsobené
porušením povinnosti, na kterou se vztahuje smluvní pokuta, v plné výši.

ČÁST 21 - OBECNÁ ODPOVĚDNOST POSKYTOVATELE

179. Poskytovatel je povinen po dobu plnění povinností ze Smlouvy o poskytování služeb chránit
180. majetek Objednatele i třetích osob před jeho poškozením, znehodnocením, zničením a
ztrátou a postupovat tak, aby neomezoval práva osob nad míru nezbytnou k provádění
181. Služeb.
Způsobí-li Poskytovatel v souvislosti s Dílem nebo porušením svých povinností
vyplývajících ze Smlouvy o poskytování služeb, Obchodních podmínek, Veřejnoprávních
podkladů, právních předpisů a příslušných ČSN jakoukoli újmu Objednateli nebo třetím
osobám, je povinen nahradit Objednateli škodu a nemajetkovou újmu, včetně případných
sankcí udělených Objednateli orgány státní správy, jejichž příčinou bylo porušení
smluvních povinností Poskytovatele, a jde-li o újmu způsobenou třetím osobám, je povinen
způsobenou újmu na vlastní náklady bezodkladně odčinit.
Újmou se pro účely Obchodních podmínek rozumí zejm. jakékoliv poškození,
znehodnocení, či znečištění věcí nebo prostor nebo jejich jiná nežádoucí změna a jakékoliv
neoprávněné omezení práv Objednatele nebo třetích osob.

15/18
182. Poskytovatel odpovídá za jakékoli porušení svých povinností stanovených Smlouvou o
183. poskytování služeb, Obchodními podmínkami, Veřejnoprávními podklady, právními
předpisy a příslušnými ČSN a je povinen uhradit veškeré pokuty udělené mu příslušnými
orgány státní správy v souvislosti s prováděním Služeb ze svého, ledaže mu byla pokuta
udělena v souvislosti s respektováním příkazu Objednatele, proti kterému uplatnil
písemnou výhradu a na jehož splnění Objednatel trval anebo v souvislosti s užitím
Objednatelem opatřené věci, na jejíž nevhodnost Objednatele písemně upozornil a
Objednatel na jejím užití trval.
Povinnosti k náhradě újmy způsobené porušením svých povinností ze Smlouvy o
poskytování služeb, Obchodních podmínek, Veřejnoprávních podkladů, právních předpisů
a příslušných ČSN se Poskytovatel vůči Objednateli zprostí, prokáže-li, že mu ve splnění
povinnosti zabránila mimořádná nepředvídatelná a nepřekonatelná překážka vzniklá
nezávisle na jeho vůli. Překážka vzniklá z osobních poměrů Poskytovatele nebo vzniklá až
v době, kdy byl Poskytovatel s plněním povinnosti v prodlení, ani překážka, kterou byl
Poskytovatel povinen překonat, jej však povinnosti k náhradě nezprostí.

ČÁST 22 - ODSTOUPENÍ OD SMLOUVY O POSKYTOVÁNÍ SLUŽEB

184. Poruší-li Smluvní strana Smlouvu o poskytování služeb podstatným způsobem, může
185. druhá Smluvní strana písemnou formou od Smlouvy o poskytování služeb odstoupit.
Podstatné je takové porušení povinnosti, o němž Smluvní strana porušující Smlouvu o
186. poskytování služeb již při uzavření Smlouvy o poskytování služeb věděla nebo musela
187. vědět, že by druhá Smluvní strana Smlouvu o poskytování služeb neuzavřela, pokud by
toto porušení předvídala, nebo je-li porušení povinnosti ve Smlouvě o poskytování služeb
188. nebo v Obchodních podmínkách jako podstatné označeno; v ostatních případech se má za
189. to, že porušení podstatné není.
190. Podstatným porušením Smlouvy o poskytování služeb je též prodlení Poskytovatele a
191. Objednatele s plněním povinností vyplývajících Poskytovateli a Objednateli ze Smlouvy o
poskytování služeb o více než 30 dní.
Objednatel je oprávněn od Smlouvy o poskytování služeb odstoupit též
187.1. z důvodů uvedených v části Předání a převzetí Služeb (viz ČÁST 13 - Obchodních

podmínek),
187.2. nabylo-li právní moci rozhodnutí o nařízení exekuce vůči Poskytovateli jako

povinnému,
187.3. ocitne-li se Poskytovatel ve stavu úpadku nebo hrozícího úpadku,
187.4. jestliže Poskytovatel nebo jeho poddodavatel, nebo z jejich pokynu jakákoliv

osoba, nabídne nebo poskytne jakékoliv osobě úplatek nebo jiný majetkový či jiný
prospěch za účelem získání neoprávněného prospěchu nebo výhody v souvislosti
s Dílem nebo jeho prováděním,
187.5. uvedl-li Poskytovatel v Nabídce informace nebo doklady, které neodpovídají
skutečnosti a měly nebo mohly mít vliv na výsledek řízení,
187.6. stanoví-li tak Smlouvy o poskytování služeb.
Smluvní strana může od Smlouvy o poskytování služeb odstoupit, pokud z chování druhé
Smluvní strany nepochybně vyplyne, že poruší Smlouvu o poskytování služeb podstatným
způsobem, a nedá-li na výzvu oprávněné Smluvní strany přiměřenou jistotu.
Jakmile Smluvní strana oprávněná odstoupit od Smlouvy o poskytování služeb oznámí
druhé Smluvní straně, že od Smlouvy o poskytování služeb odstupuje, nebo že na Smlouvě
o poskytování služeb setrvává, nemůže volbu již sama změnit.
Zakládá-li prodlení Smluvní strany nepodstatné porušení její povinnosti ze Smlouvy o
poskytování služeb, může druhá Smluvní strana od Smlouvy o poskytování služeb
odstoupit poté, co prodlévající Smluvní strana svoji povinnost nesplní ani v dodatečné
přiměřené lhůtě, kterou jí druhá Smluvní strana poskytla výslovně nebo mlčky.
Oznámí-li Smluvní strana Smluvní straně prodlévající, že jí určuje dodatečnou lhůtu k
plnění a že jí lhůtu již neprodlouží, platí, že marným uplynutím této lhůty od Smlouvy o
poskytování služeb odstoupila.

16/18
192. Poskytla-li Smluvní strana Smluvní straně prodlévající nepřiměřeně krátkou dodatečnou
193. lhůtu k plnění a odstoupí-li od Smlouvy o poskytování služeb po jejím uplynutí, nastávají
194. účinky odstoupení teprve po marném uplynutí doby, která měla být prodlévající Smluvní
195. straně poskytnuta jako přiměřená. To platí i tehdy, odstoupila-li Smluvní strana od
Smlouvy o poskytování služeb, aniž by prodlévající Smluvní straně dodatečnou lhůtu k
196. plnění poskytla.
Plnil-li Poskytovatel zčásti, může Smluvní strana od Smlouvy o poskytování služeb
odstoupit jen ohledně nesplněného zbytku plnění. Nemá-li však částečné plnění pro
Objednatele význam, může Objednatel od Smlouvy o poskytování služeb odstoupit
ohledně celého plnění. Odstoupil-li od nesplněného zbytku plnění Poskytovatel, je
Objednatel oprávněn odstoupit od splněné části Smlouvy o poskytování služeb, nemá-li
částečně plnění pro Objednatele význam.
Zavazuje-li Smlouva o poskytování služeb Poskytovatele k opakované činnosti nebo k
postupnému dílčímu plnění, může Objednatel od Smlouvy o poskytování služeb odstoupit
jen s účinky do budoucna. To neplatí, nemají-li již přijatá dílčí plnění sama o sobě pro
Objednatele význam.
Smluvní strany se dohodly, že dojde-li k odstoupení od Smlouvy o poskytování služeb jen
ohledně nesplněného zbytku plnění, užijí se na splněnou část plnění obdobně všechna
ustanovení Smlouvy o poskytování služeb a Obchodních podmínek týkající se předání a
převzetí Služeb, přičemž přejímací řízení Smluvní strany zahájí nejpozději do 3 pracovních
dnů ode dne odstoupení od Smlouvy o poskytování služeb, a dále všechna ustanovení
Smlouvy o poskytování služeb a Obchodních podmínek o právech a povinnostech
Smluvních stran, které jsou Smluvní stany povinny plnit v době ode dne převzetí Služeb
Objednatelem, tedy zejm. ustanovení o vadách Služeb.
Ustanovení §1977, §2002–2003 Občanského zákoníku se neužijí.

ČÁST 23 - OSTATNÍ UJEDNÁNÍ

197. Částečné plnění
198. Ustanovení Smlouvy o poskytování služeb a Obchodních podmínek platí obdobně též pro
199. části Služeb, provádí-li Poskytovatel Služby v souladu se Smlouvou o poskytování služeb
200. po částech, není-li uvedeno jinak.
201.
Postoupení, započtení
202. Poskytovatel není oprávněn postoupit žádnou svou pohledávku za Objednatelem
vyplývající ze Smlouvy o poskytování služeb nebo vzniklou v souvislosti se Smlouvou o
poskytování služeb.
K pohledávce za Objednatelem vyplývající se Smlouvy o poskytování služeb nebo vzniklé
v souvislosti se Smlouvou o poskytování služeb nesmí být zřízeno zástavní právo.
Poskytovatel není oprávněn provést jednostranné započtení žádné své pohledávky
za Objednatelem vyplývající ze Smlouvy o poskytování služeb nebo vzniklé v souvislosti
se Smlouvou o poskytování služeb na jakoukoliv pohledávku Objednatele za
Poskytovatelem.
Objednatel je oprávněn provést jednostranné započtení jakékoliv své splatné i nesplatné
pohledávky za Poskytovatelem vyplývající ze Smlouvy o poskytování služeb nebo vzniklé
v souvislosti se Smlouvou o poskytování služeb (zejm. smluvní pokutu) na jakoukoliv
splatnou či nesplatnou pohledávku Poskytovatele za Objednatelem.

Mlčenlivost
Poskytovatel je povinen zachovávat mlčenlivost o všech skutečnostech a informacích,
které jsou obsažené ve Smlouvě o poskytování služeb a dále o všech skutečnostech a
informacích, které mu byly v souvislosti se Smlouvou o poskytování služeb nebo jejím
plněním, jakkoliv zpřístupněny, předány či sděleny, nebo o nichž se jakkoliv dozvěděl,
vyjma těch, které jsou v okamžiku, kdy se s nimi Poskytovatel seznámil, prokazatelně
veřejně přístupné, nebo těch, které se bez zavinění Poskytovatele veřejně přístupnými
stanou. Poskytovatel nesmí takové skutečnosti a informace použít v rozporu s jejich
účelem, nesmí je použít ve prospěch svůj nebo třetích osob a nesmí je použít ani
v neprospěch Objednatele. Povinnosti dle tohoto odstavce je Poskytovatel povinen

17/18
203. zachovávat i po zániku závazku ze Smlouvy o poskytování služeb, vyjma případů, kdy se
204. takové skutečnosti a informace stanou prokazatelně veřejně přístupné bez zavinění
205. Poskytovatele. Povinnosti dle tohoto odstavce se nevztahují na případy, kdy je
Poskytovatel povinen zveřejnit takové skutečnosti nebo informace na základě povinnosti
206. uložené mu právním předpisem nebo rozhodnutím orgánu veřejné moci.

207. Poskytování informací
208. Vzhledem k veřejnoprávnímu charakteru Objednatele Poskytovatel výslovně prohlašuje,
209. že je s touto skutečností obeznámen a souhlasí se zveřejněním Smlouvy o poskytování
210. služeb včetně Obchodních podmínek v rozsahu a za podmínek vyplývajících z příslušných
právních předpisů.

Kontrola
Poskytovatel si je vědom, že je ve smyslu §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ů,
povinen spolupůsobit při výkonu finanční kontroly a zavazuje se finanční kontrolu strpět.
Je-li Služby z jakékoliv části financováno z prostředků Evropské unie, je Poskytovatel
povinen
205.1. strpět veškeré kontroly vyplývající z režimu financování Služeb z prostředků

Evropské unie,
205.2. poskytnout při takových kontrolách veškerou nezbytnou součinnost,
205.3. archivovat veškerou dokumentaci týkající se Smlouvy o poskytování služeb po

dobu stanovenou pravidly, jimiž se řídí financování Služeb z prostředků Evropské
unie.

Jazyk
Ve všech záležitostech souvisejících se Smlouvou o poskytování služeb budou zástupci
Smluvních stran komunikovat v českém jazyce. Všichni zástupci musí plynně český jazyk
ovládat. Jestliže český jazyk plynně neovládají, jsou povinni na náklady své Smluvní strany
zajistit, aby byl po celou dobu vzájemné osobní komunikace k dispozici kvalifikovaný
tlumočník.

Forma, označení času
Písemnou formou (podobou) se rozumí listina podepsaná oprávněnou osobou Smluvní
strany nebo email podepsaný zaručeným elektronickým podpisem oprávněné osoby
Smluvní strany.
Je-li ve Smlouvě o poskytování služeb nebo Obchodních podmínkách uvedena lhůta nebo
doba počítané podle dnů, měsíců nebo let, rozumí se tím vždy kalendářní den, měsíc nebo
rok, není-li uvedeno jinak.

Reference
Poskytovatel je oprávněn uvádět Služby a jméno Objednatele jako referenci na svou
činnost pouze s předchozím písemným souhlasem Objednatele.

Salvatorní klauzule
Je-li nebo stane-li se některé oddělitelné ustanovení Smlouvy o poskytování služeb nebo
Obchodních podmínek neplatné, neúčinné či nevymahatelné, nedotýká se tato skutečnost
ostatních ustanovení. Smluvní strany se zavazují nahradit takové ustanovení jiným
ustanovením, které svým obsahem a smyslem bude nejvíce odpovídat obsahu a smyslu
ustanovení nahrazovaného.

18/18

Textová podoba smlouvy Smlouva č. 33630281: Smlouva o poskytnutí subskripce SW RailOffice pro WKokes

Příloha 34226-2025-SZ-GR-O8_Sml. o poskytnutí subskripce_10. 6. 2025.pdf