REGISTR INFORMACÍ KROK ZA KROKEM

Co registr informací je a k čemu dohledu slouží

Registr informací je strukturovaná evidence smluvních ujednání o využívání služeb IKT. Povinnost ho vést a aktualizovat plyne z čl. 28 odst. 3 nařízení (EU) 2022/2554 (DORA) a týká se všech smluvních ujednání o službách IKT poskytovaných třetími stranami, nikoli jen těch, která podporují zásadní nebo důležité funkce. Vede se na třech úrovních: na úrovni subjektu a na subkonsolidované a konsolidované úrovni.

Formát není na vůli subjektu. Standardní vzory stanoví prováděcí nařízení Komise (EU) 2024/2956 ze dne 29. listopadu 2024, vyhlášené v Úředním věstníku 2. prosince 2024, přijaté podle zmocnění v čl. 28 odst. 9 druhém pododstavci DORA. Má sedm článků a čtyři přílohy; podle čl. 7 vstupuje v platnost dvacátým dnem po vyhlášení a zvláštní datum použitelnosti nestanoví.

Proč se tomu dohled věnuje takhle podrobně, vysvětluje čl. 31 odst. 10 DORA. Příslušné orgány zasílají zprávy podle čl. 28 odst. 3 třetího pododstavce každoročně a na agregovaném základě fóru dohledu, které na jejich základě posuzuje závislost finančních subjektů na poskytovatelích služeb IKT z řad třetích stran. Registr tedy není jen interní inventura: je to vstup do procesu, ve kterém se určují kritičtí poskytovatelé. Odtud plyne důraz na strojově zpracovatelné identifikátory a na uzavřené číselníky — data z různých subjektů musí jít porovnat.

Vedle samotného vedení registru jsou na něj v čl. 28 odst. 3 navázané další tři povinnosti, které se snadno přehlédnou: alespoň jednou ročně nahlásit příslušným orgánům počet nových ujednání, kategorie poskytovatelů, druh smluvních ujednání a poskytované služby a funkce IKT; zpřístupnit na žádost úplný registr nebo jeho konkrétní části i další informace nezbytné k účinnému dohledu; a včas informovat orgán o každém plánovaném ujednání o službách podporujících zásadní nebo důležité funkce i o tom, že se některá funkce zásadní nebo důležitou stala.

• Rozsah: všechna ujednání o službách IKT. Zúžení jen na kritické dodavatele neplyne z textu čl. 28 odst. 3 ani z prováděcího nařízení. Podle druhého pododstavce se ujednání dokumentují s rozlišením, zda se týkají služeb podporujících zásadní nebo důležité funkce, nebo ne — rozlišuje se tedy uvnitř registru, neselektuje se na vstupu.
• Tři úrovně vedení. Úroveň subjektu, subkonsolidovaná a konsolidovaná. Podle čl. 6 prováděcího nařízení zahrnuje registr vedený na subkonsolidované a konsolidované úrovni všechny finanční subjekty a poskytovatele služeb IKT v rámci skupiny, kteří jsou součástí podskupiny a skupiny.
• Ohlašovací povinnost není totéž co odevzdání registru. Ročně se hlásí souhrn podle třetího pododstavce čl. 28 odst. 3; celý registr nebo jeho části se zpřístupňují na žádost příslušného orgánu podle čtvrtého pododstavce.
• Plánovaná ujednání se hlásí dopředu. Pátý pododstavec žádá včasnou informaci o každém plánovaném ujednání o službách podporujících zásadní nebo důležité funkce — tedy dřív, než se objeví v registru jako existující smlouva.
• Registr žije se změnami funkcí. Informovat je nutné i tehdy, když se některá funkce zásadní nebo důležitou teprve stane. Přeřazení funkce má dopad do několika vzorů najednou.
• Kvalita údajů je předepsaná. Čl. 3 odst. 4 prováděcího nařízení jmenuje šest zásad: přesnost, úplnost, konzistentnost, integrita, jednotnost a platnost. Podle čl. 3 odst. 3 se údaje pravidelně kontrolují a zjištěné chyby nebo nesrovnalosti se neprodleně opravují.

Jak se registr v Česku předkládá a jaké termíny stanoví dohledový orgán, je popsané v sekci o dodavatelském řetězci v průvodci nařízením DORA v této kategorii. Samotné prováděcí nařízení žádnou pravidelnou lhůtu pro předložení nestanoví — termín podání je věcí dohledového procesu, ne textu normy.

Co se do registru uvádí a kteří subdodavatelé v něm nejsou

Nejdůležitější věta celého prováděcího nařízení je čl. 3 odst. 2 a je asymetrická. Registr obsahuje jednak příslušné informace týkající se všech služeb IKT poskytovaných přímými poskytovateli služeb IKT z řad třetích stran, jednak informace o všech subdodavatelích, kteří fakticky zajišťují služby IKT podporující zásadní nebo důležité funkce nebo jejich podstatné části.

Prakticky to znamená dvě různá pravidla pro dvě různé vrstvy. U přímých dodavatelů se nic nefiltruje: do registru patří i drobná služba, která se zásadních funkcí netýká. U subdodavatelů se naopak filtruje dvakrát — musí jít o službu podporující zásadní nebo důležitou funkci nebo její podstatnou část a subdodavatel ji musí fakticky zajišťovat. Kompletní mapa subdodavatelského řetězce u nekritických služeb se tedy nevyžaduje.

K tomu patří tři definice z čl. 1. Přímým poskytovatelem služeb IKT z řad třetích stran je ten, kdo podepsal smluvní ujednání s finančním subjektem o poskytování služeb přímo jemu, nebo s finančním či nefinančním subjektem o poskytování služeb jiným finančním subjektům v rámci téže skupiny. Dodavatelský řetězec služby IKT je posloupnost smluvních ujednání počínaje přímým poskytovatelem, který má jako protistranu jednoho nebo více subdodavatelů. A pořadí je postavení poskytovatele v tomto řetězci.

Co je vlastně služba IKT, se přitom neřeší v prováděcím nařízení, ale v čl. 3 bodě 21 DORA — jde o digitální a datové služby poskytované průběžně prostřednictvím systémů IKT jednomu nebo více interním nebo externím uživatelům, včetně hardwaru jako služby a hardwarových služeb zahrnujících technickou podporu formou aktualizací softwaru nebo firmwaru, s výjimkou tradičních analogových telefonních služeb. Poskytovatelem je podle čl. 3 bodu 19 jakýkoli podnik poskytující služby IKT, bez velikostní hranice.

• Přímý dodavatel: uvádí se vždy a se všemi službami. Bez ohledu na to, jestli daná služba podporuje zásadní nebo důležitou funkci.
• Subdodavatel: jen u zásadních nebo důležitých funkcí. A jen tehdy, když službu nebo její podstatnou část fakticky zajišťuje. Zprostředkující článek, který nic fakticky nezajišťuje, do téhle kategorie nespadá.
• Poskytovatel služeb IKT v rámci skupiny se v registru objevuje samostatně — vzor B_02.03 propojuje ujednání uvnitř skupiny s ujednáními vůči poskytovatelům mimo skupinu pomocí referenčních čísel smluv.
• Referenční čísla smluv se subdodavateli se neuvádějí. Pokyny k vzoru B_02.01 to říkají výslovně: pokud externí přímí dodavatelé využívají subdodavatele, referenční čísla smluvních ujednání mezi nimi a jejich subdodavateli se v registru neuvádějí.
• Doplňkové informace jsou povolené. Podle čl. 5 odst. 2 může finanční subjekt do registru zahrnout další informace ve formátu, který je pro ně nejvhodnější, je-li to relevantní pro řízení rizika nebo řízení smluv.
• Vlastní terminologie se vysvětluje. Vzor B_99.01 slouží k tomu, aby dohled věděl, co u vás znamená „nízký“, „střední“ a „vysoký“ dopad v hodnoticích sloupcích. Bez něj jsou vaše škály nečitelné.

Věta „fakticky zajišťují“ dělá v praxi největší potíže u vícestupňových cloudových řetězců. Rozhodující je, kdo službu nebo její podstatnou část skutečně provozuje, ne kdo je uveden ve smlouvě jako protistrana. Odpověď obvykle není z papírů zřejmá a je potřeba ji získat od přímého dodavatele — což je zároveň důvod, proč jsou v dodatcích podle čl. 30 tak podrobné informační povinnosti.

Pořadí v dodavatelském řetězci a vzor B_05.02

Pořadí je mechanismus, kterým se v registru modeluje hloubka řetězce. Podle čl. 2 prováděcího nařízení přidělí finanční subjekt každému poskytovateli služeb IKT z řad třetích stran pořadí, což je jakékoli přirozené číslo větší nebo rovné jedné, přičemž čím nižší číslo, tím blíž je ujednání finančnímu subjektu. Pořadí přímého poskytovatele je vždy 1 a pořadí subdodavatele musí být vždy vyšší než 1. Žádný pevný počet vrstev norma nestanoví.

Vlastní modelování probíhá ve vzoru B_05.02 (Dodavatelský řetězec služby IKT). Pokyny k němu obsahují příklad, který se vyplatí znát: finanční subjekt má smlouvu s dodavatelem X na dvě služby, službu A a službu B, a dodavatel využívá k poskytování služby B subdodavatele Y. U služby A se řetězec skládá jen z dodavatele X s pořadím 1. U služby B se skládá z dodavatele X s pořadím 1 a subdodavatele Y s pořadím 2.

Z toho plyne důležitá věc: řetězec se určuje pro každou službu IKT v každém smluvním ujednání zvlášť, ne pro dodavatele jako takového. Týž dodavatel může být u jedné služby jediným článkem a u druhé začátkem třístupňového řetězce. Pokyny k tomu doplňují, že všichni poskytovatelé patřící do téhož dodavatelského řetězce mají stejné referenční číslo smluvního ujednání, jak je vykázáno ve vzoru B_02.01, a stejný typ služeb IKT.

Propojení uvnitř řetězce se dělá ukazatelem na příjemce subdodávky. U každého subdodavatele s pořadím vyšším než 1 se ve sloupcích B_05.02.0060 a B_05.02.0070 určí ten poskytovatel, který je příjemcem jeho subdodavatelských služeb. U pořadí 1 se tyto sloupce nevyplňují. Pokyny rovněž počítají s tím, že má-li v témže řetězci stejné postavení víc poskytovatelů, dostanou stejné pořadí.

• B_05.02.0010 — referenční číslo smluvního ujednání. Stejné pro celý řetězec dané služby, převzaté z B_02.01.
• B_05.02.0020 — typ služeb IKT. Kód z uzavřeného číselníku v příloze III, opět stejný pro celý řetězec.
• B_05.02.0030 a 0040 — identifikační kód poskytovatele a jeho typ. Přebírá se z B_05.01, aby se tentýž subjekt v registru neobjevil pod dvěma různými identitami.
• B_05.02.0050 — pořadí. Přirozené číslo od 1 výš; jedna pro přímého poskytovatele, vyšší pro subdodavatele.
• B_05.02.0060 a 0070 — příjemce subdodavatelsky poskytnutých služeb a typ jeho kódu. Vyplňuje se jen u pořadí vyššího než 1 a musí odpovídat identifikátoru téhož poskytovatele v B_05.01.
• Řetězec se váže na službu, ne na dodavatele. Dvě služby od téhož dodavatele mohou mít dva různě hluboké řetězce, a tedy různý počet řádků.
• Do řetězce patří jen subdodavatelé u zásadních nebo důležitých funkcí. Vyplývá to z čl. 3 odst. 2 písm. b) — u ostatních služeb se řetězec pod přímého dodavatele nerozpadá.

Nejčastější chyba v téhle části je vyplnit řetězec podle organizační struktury dodavatele místo podle toho, kdo skutečně poskytuje konkrétní službu. Druhá nejčastější je zapomenout, že se týž poskytovatel musí ve všech vzorech identifikovat stejným kódem — jinak se registr rozpadne na nespojitelné záznamy a kontrola konzistentnosti podle čl. 3 odst. 4 selže.

Identifikátory: LEI, EUID a kdy se smí použít něco jiného

Identifikace poskytovatelů je v registru přísná, protože na ní stojí propojitelnost dat mezi subjekty. Podle čl. 3 odst. 5 prováděcího nařízení se k identifikaci všech poskytovatelů služeb IKT z řad třetích stran, kteří jsou právnickými osobami, používá platný a aktivní identifikační kód právnické osoby (LEI) nebo jedinečný evropský identifikační kód (EUID) podle článku 16 směrnice (EU) 2017/1132, případně oba, jsou-li přiděleny. Výjimkou jsou fyzické osoby jednající v rámci podnikatelské činnosti.

U zásadních a důležitých funkcí se požadavek propisuje dál do řetězce. Podle čl. 3 odst. 6 zajišťuje finanční subjekt prostřednictvím přímého poskytovatele, aby platný a aktivní LEI používali nebo EUID poskytli i všichni subdodavatelé uvedení v registru podle čl. 3 odst. 2 písm. b), kteří tyto služby fakticky zajišťují — opět s výjimkou fyzických osob podnikatelů. Finanční subjekt tedy nemá povinnost si kód obstarat sám, ale má povinnost ho po řetězci vyžadovat.

Pokyny ke vzoru B_05.01 tuhle logiku dotahují na úroveň sloupců: pro právnické osoby se použije pouze LEI nebo EUID, zatímco alternativní kód lze použít pouze pro fyzickou osobu jednající v rámci podnikatelské činnosti. Prakticky to znamená, že interní číslo dodavatele z vašeho systému není u firmy použitelná náhrada — a to je nejčastější důvod, proč výkaz neprojde kontrolou.

Vedle poskytovatelů se identifikují i vlastní subjekty. Finanční subjekt, který registr vede, a subjekty v konsolidaci se ve vzorech B_01.01 a B_01.02 identifikují dvacetiznakovým alfanumerickým kódem LEI podle normy ISO 17442; ve vzoru B_01.03 se k pobočkám uvádí buď jejich vlastní LEI, je-li jedinečný a odlišný od LEI mateřského subjektu, nebo jiný identifikační kód používaný finančním subjektem.

• LEI, nebo EUID, případně oba. Jiná varianta pro právnické osoby neexistuje. Pokud jsou přidělené oba kódy, uvádějí se oba.
• Alternativní kód jen pro podnikající fyzické osoby. U živnostníka, který dodává službu IKT, se alternativní identifikace použít smí; u společnosti s ručením omezeným ne.
• Platný a aktivní. Norma nežádá jen existenci kódu, ale i jeho aktuální stav. Nepodložené LEI se považuje za neplatnou hodnotu a naráží na zásadu platnosti údajů z čl. 3 odst. 4.
• Nejvyšší mateřský podnik. Vzor B_05.01 eviduje i identifikátor nejvyššího mateřského podniku dodavatele; není-li dodavatel součástí skupiny, opakuje se v tomto poli jeho vlastní identifikátor.
• Konzistence napříč vzory. Identifikátor poskytovatele se do B_02.02, B_03.02, B_05.02 a B_07.01 přebírá z B_05.01. Kdo si vede identifikátory v každé tabulce zvlášť, vyrobí si nekonzistentní registr.
• Zřízení kódu je práce na straně dodavatele. Získat LEI trvá dny a je to administrativní úkon, který nelze vyřešit v den odevzdání. U nových dodavatelů se vyplatí ptát se na kód už při výběrovém řízení.

Požadavek na LEI je zároveň nejsnazší otázka do dotazníku pro dodavatele — a nejlepší předběžný test toho, jak bude spolupráce při aktualizaci registru probíhat. Dodavatel, který kód nemá a odmítá si ho zřídit, se v registru vykázat nedá.

Patnáct vzorů v pořadí, ve kterém se vyplňují

Příloha I nařízení (EU) 2024/2956 obsahuje patnáct vzorů a čl. 5 odst. 1 je vyjmenovává pod písmeny a) až o). Kódy jdou od B_01.01 po B_99.01 a jsou provázané: většina vzorů přebírá hodnoty z jiných, takže pořadí vyplňování není libovolné. Číselné pořadí kódů zhruba odpovídá pořadí práce, ale ne úplně — vzor B_05.01 s identifikátory poskytovatelů a vzor B_06.01 s určením funkcí je potřeba mít hotové dřív, než se dají dokončit vzory s nižšími čísly.

Praktické pořadí vypadá takto: nejprve se popíše vlastní organizace (B_01.01 až B_01.03), pak se určí funkce a jejich kritičnost (B_06.01), pak se založí rejstřík dodavatelů s identifikátory (B_05.01), teprve pak se plní smluvní vzory (B_02.01, B_02.02, B_02.03) a vazby podpisů a uživatelů (B_03.01 až B_03.03, B_04.01), následuje řetězec (B_05.02), posouzení služeb u zásadních funkcí (B_07.01) a nakonec slovník vlastních škál (B_99.01).

Podle čl. 4 je každý vzor tabulka s předem definovaným počtem sloupců a neurčitým počtem řádků. Každý datový prvek se vyplní jednou hodnotou, a je-li platných hodnot víc, přidá se pro každou další řádek. Tohle pravidlo je důvod, proč registr rychle roste: u vzoru B_02.02 se vykazují kombinace služeb IKT a podporovaných funkcí, takže jedna smlouva na tři služby podporující dvě funkce znamená šest řádků.

• 1. B_01.01 — Subjekt, který vede registr informací. Určení subjektu, který registr vede a aktualizuje na úrovni subjektu i na subkonsolidované a konsolidované úrovni. Nejkratší vzor a zároveň referenční bod pro ostatní.
• 2. B_01.02 — Seznam subjektů zahrnutých do konsolidace. Všechny subjekty patřící do skupiny. Nepatří-li subjekt do skupiny, uvede se ve vzoru pouze on sám a záznam je totožný s B_01.01. Zde se vykazuje i hodnota celkových aktiv, k níž dává pokyn příloha IV.
• 3. B_01.03 — Seznam poboček. Pobočky subjektů uvedených v B_01.02, které se nacházejí mimo domovskou zemi.
• 4. B_06.01 — Určení funkcí. Předsunuto schválně: bez identifikačních kódů funkcí nelze dokončit B_02.02. Podrobnosti jsou v samostatné sekci níž.
• 5. B_05.01 — Poskytovatelé služeb IKT z řad třetích stran. Seznam a obecné informace k přímým poskytovatelům, poskytovatelům v rámci skupiny, všem subdodavatelům uvedeným v B_05.02 a nejvyšším mateřským podnikům. Zdroj identifikátorů pro všechny ostatní vzory.
• 6. B_02.01 — Smluvní ujednání, obecné informace. Seznam všech smluvních ujednání s přímými poskytovateli. Zde se každému ujednání přiděluje jedinečné referenční číslo, na které se odkazuje ze čtyř dalších vzorů. Rozlišuje se samostatné, zastřešující a navazující ujednání a vykazují se roční výdaje nebo odhadované náklady.
• 7. B_02.02 — Smluvní ujednání, konkrétní informace. Podrobnosti ke každému ujednání z B_02.01 v kombinacích služba IKT a podporovaná funkce: data zahájení a ukončení, důvod vypovězení, výpovědní lhůty pro obě strany ve dnech, země rozhodného práva, země poskytování služby, uchovávání údajů, umístění uchovávaných dat, místo zpracování, citlivost dat a míra závislosti u zásadních funkcí.
• 8. B_02.03 — Seznam smluvních ujednání v rámci skupiny. Vazby mezi ujednáními uvnitř skupiny a ujednáními s poskytovateli mimo skupinu, pomocí referenčních čísel smluv, je-li část dodavatelského řetězce uvnitř skupiny.
• 9. B_03.01 — Subjekty, které podepsaly smluvní ujednání. Kdo smlouvu podepsal s přímým poskytovatelem, ať už pro sebe, nebo jménem subjektu, který službu využívá. Na úrovni subjektu je podepisujícím i uživatelem tentýž finanční subjekt, v konsolidaci se to liší.
• 10. B_03.02 — Poskytovatelé, kteří podepsali smluvní ujednání. Určení všech poskytovatelů z B_05.01, kteří podepsali ujednání uvedená v B_02.01.
• 11. B_03.03 — Subjekty poskytující služby IKT jiným subjektům v konsolidaci. Subjekty z B_01.02, které podepsaly ujednání z B_02.01 o poskytování služeb IKT jiným subjektům ve skupině.
• 12. B_04.01 — Subjekty, které využívají služby IKT. Uživatelé služeb; podle pokynů to jsou buď finanční subjekty v oblasti působnosti, nebo poskytovatelé služeb IKT v rámci skupiny.
• 13. B_05.02 — Dodavatelský řetězec služby IKT. Pořadí a propojení poskytovatelů v témže řetězci, viz samostatná sekce výš.
• 14. B_07.01 — Posouzení služeb IKT. Vyplňuje se jen u služeb podporujících zásadní nebo důležitou funkci či její podstatnou část. Podrobnosti v samostatné sekci níž.
• 15. B_99.01 — Definice subjektů využívajících služby IKT. Vlastní vysvětlení, významy a definice pevně daných škál používaných v registru. Vyplňuje se nakonec, protože se odkazuje na hodnoty použité v ostatních vzorech.

Pořadí výše je pracovní, ne normativní: nařízení stanoví obsah vzorů a jejich vzájemné odkazy, ne sled kroků. Zkušenost je taková, že týmy, které začnou u smluvních vzorů B_02.01 a B_02.02, se dřív nebo později vrátí na začátek — bez seznamu funkcí a bez rejstříku dodavatelů s identifikátory se ty tabulky dokončit nedají.

Funkce, kritičnost a posouzení služeb: vzory B_06.01 a B_07.01

Vzor B_06.01 (Určení funkcí) je místo, kde se registr potkává s vnitřní organizací. Finanční subjekt určí podle své vlastní organizace všechny funkce podporované službou IKT od poskytovatele z řad třetích stran a každé přidělí jedinečný identifikační kód funkce ve tvaru písmene F a přirozeného čísla. Jedinečnost se přitom vyžaduje pro každou kombinaci LEI finančního subjektu, licencované činnosti a názvu funkce.

Příklad z pokynů to ukazuje názorně: subjekt, který působí v rámci dvou licencovaných činností, dostane pro tutéž funkci — třeba prodej — dva různé identifikační kódy, jeden pro činnost A a druhý pro činnost B. Věcně jde o týž proces, v registru o dva záznamy. Seznam licencovaných činností podle typu subjektu je v příloze II; není-li funkce spojena s registrovanou nebo licencovanou činností, vykazuje se jako podpůrná funkce.

Vedle identifikace obsahuje B_06.01 i vlastní posouzení: zda je funkce zásadní nebo důležitá (s možnostmi ano, ne, posouzení nebylo provedeno), stručné odůvodnění klasifikace v rozsahu nejvýše 300 znaků, datum posledního posouzení, cílovou dobu obnovy a cílový okamžik obnovy v celých hodinách a dopad ukončení funkce ve škále nízký, střední, vysoký, posouzení nebylo provedeno. U dosud neprovedeného posouzení se do data vyplňuje 9999-12-31, u nedefinované doby obnovy hodnota 0.

Vzor B_07.01 (Posouzení služeb IKT) se vyplňuje jen tam, kde služba podporuje zásadní nebo důležitou funkci nebo její podstatnou část, a to podle pokynů včetně prvního subdodavatele mimo skupinu, jsou-li předchozí články řetězce uvnitř skupiny. Je to nejvíc analytický vzor celého registru: neptá se, co máte, ale jak jste na tom, kdyby to skončilo.

• Nahraditelnost poskytovatele ve čtyřstupňové škále: nenahraditelný, vysoce obtížná nahraditelnost, středně obtížná nahraditelnost, snadno nahraditelný.
• Důvod obtížné nahraditelnosti z uzavřeného seznamu: nedostatek reálných alternativ na trhu nebo technická složitost služby, potíže s migrací dat a pracovních úkolů či s reintegrací do vlastního provozu, nebo obojí. Vyplňuje se u dvou nejvyšších stupňů nenahraditelnosti.
• Datum posledního auditu poskytovatele. Pokyny výslovně vymezují, co se počítá — audit interním útvarem nebo kvalifikovanými pracovníky, společný audit s dalšími klienty téhož poskytovatele, nebo audit třetí stranou jmenovanou dohlíženým subjektem. Naopak se nepočítá datum certifikace, datum interní auditní zprávy poskytovatele, datum ročního monitorování ujednání ani datum přezkumu vlastního posouzení rizik. Nebyl-li audit proveden, vyplní se 9999-12-31.
• Existence plánu ukončení smluvního vztahu ke konkrétní službě, ano nebo ne.
• Možnost reintegrace služeb ve škále snadná, obtížná, vysoce složitá; vyplňuje se u poskytovatelů mimo skupinu.
• Dopad ukončení služeb IKT ve škále nízký, střední, vysoký, posouzení nebylo provedeno.
• Alternativní poskytovatelé. Zda byli určeni (ano, ne, posouzení nebylo provedeno) — pokyny k tomu dodávají, že posouzení za účelem určení alternativního poskytovatele musí být provedeno u každého poskytovatele podporujícího zásadní nebo důležitou funkci. Doplňující identifikace alternativy je nepovinná.

Sloupce vzoru B_07.01 se čtou jako kontrolní seznam řízení rizik třetích stran: kdo je nenahraditelný, kdy jste ho naposledy auditovali, máte pro něj exit plán a víte o alternativě. Jednou z mála možností, jak registr obrátit ve vlastní prospěch, je vzít tenhle vzor jako zadání pro interní práci, a ne jako tabulku vyplňovanou před odevzdáním.

Číselníky: typy služeb S01 až S19 a přílohy II a IV

Typ služby IKT se v registru neuvádí slovy. Příloha III obsahuje uzavřený číselník s identifikačními kódy od S01 do S19 a pokyn je jednoznačný: ve vzorech se uvádí pouze kód. Číselník je stejný pro všechny subjekty v Unii, což je právě to, co dohledu umožňuje agregovat data napříč trhem — a zároveň to znamená, že vaše vlastní kategorizace dodavatelů se na tenhle seznam musí namapovat.

Zařazení bývá sporné hlavně u softwaru a u cloudu, protože číselník vede dělicí čáru jinde než běžný obchodní jazyk. Software dodávaný jako služba patří pod S19, kdežto licencování softwaru používaného v provozovně pod S13. Cloudové služby mají tři samostatné kódy podle modelu, zatímco hostingové a infrastrukturní služby mimo cloud jsou pod S07 a úložiště mimo cloud pod S09. U telekomunikačních služeb číselník výslovně připomíná, že tradiční analogové telefonní služby jsou podle čl. 3 bodu 21 DORA vyloučené.

Zbývající dvě přílohy jsou pomocné, ale bez nich se registr nedokončí. Příloha II obsahuje seznam licencovaných činností podle typu subjektu — od úvěrových institucí přes platební instituce, poskytovatele služeb informování o účtu, instituce elektronických peněz a investiční podniky až po poskytovatele služeb souvisejících s kryptoaktivy a vydavatele tokenů vázaných na aktiva. Používá se ve vzoru B_06.01, kde je licencovaná činnost součástí kombinace určující identifikační kód funkce. Příloha IV pak dává pro každý typ subjektu pokyn, jak vykázat hodnotu celkových aktiv ve vzoru B_01.02.

• S01 až S04 — služby kolem řízení a bezpečnosti: řízení projektů v oblasti IKT, rozvoj IKT (obchodní analýza, návrh a vývoj softwaru, testování), asistenční služby a podpora první úrovně, služby řízení bezpečnosti v oblasti IKT včetně řešení incidentů a forenzní analýzy.
• S05 a S06 — datové služby: poskytování údajů, tedy předplatné služeb poskytovatelů dat, a analýza údajů.
• S07 až S09 — infrastruktura mimo cloud: IKT, zařízení a hostingové služby s výjimkou cloudu, počítačové zpracování a úložiště dat jiné než cloudové.
• S10 až S12 — sítě a hardware: poskytovatel telekomunikačních služeb, síťová infrastruktura, hardware a fyzická zařízení poskytovaná formou služby.
• S13 — licencování softwaru s výjimkou softwaru jako služby, tedy software používaný v provozovně.
• S14 až S16 — provoz a poradenství: řízení provozu IKT včetně údržby, kam číselník výslovně řadí i poskytovatele řízených služeb, poradenství v oblasti IKT a řízení rizika v oblasti IKT ve smyslu ověřování souladu podle čl. 6 odst. 10 DORA.
• S17 až S19 — cloud: infrastruktura jako služba, platforma jako služba a software jako služba, každý s vlastním kódem.
• Jedna smlouva, více kódů. Poskytuje-li dodavatel v rámci jedné smlouvy víc typů služeb, vzniká víc řádků — a v návazných vzorech víc řetězců, protože ty se určují pro každou službu zvlášť.

Nejjistější způsob, jak si zařazení služby ověřit, je zeptat se dodavatele, do jaké kategorie se hlásí u ostatních zákazníků. Kód se totiž objevuje ve více registrech současně a nesoulad mezi nimi je přesně ten typ nekonzistence, který se při agregaci dat na úrovni dohledu projeví.

Kde registr nejčastěji drhne

Registr je datová úloha, ne dokumentační cvičení, a chybuje se v něm proto podobně jako v jiných výkazech: na okrajích, ve vazbách a v tom, co se do tabulky nevešlo. Níže je přehled míst, která se opakují nejčastěji, seřazený zhruba podle toho, jak drahé je jejich odstranění.

Nejdražší je špatně vymezený rozsah. Zúžení registru jen na velké dodavatele, opomenutí služeb nakupovaných mimo IT útvar nebo vynechání poskytovatelů v rámci skupiny znamená, že se registr nedoplňuje, ale přestavuje. Druhé nejdražší je chybějící vazba na funkce: bez určených funkcí a jejich kritičnosti nelze rozhodnout, kde se vyplňuje B_07.01 a kde se rozpadá dodavatelský řetězec.

Zbytek jsou opakující se drobnosti — formáty dat, kódy, škály, jedna hodnota na buňku. Samy o sobě nejsou dramatické, ale ve výkazu, který se kontroluje strojově, rozhodují o tom, jestli podání projde.

• Zúžený rozsah. Registr se vede ke všem smluvním ujednáním o službách IKT. Rozlišení kritických a nekritických se dělá uvnitř registru podle druhého pododstavce čl. 28 odst. 3 DORA, ne výběrem na vstupu.
• Nákupy mimo IT. Předplatná datových služeb, nástroje pořízené obchodním nebo marketingovým útvarem a software jako služba placený kartou jsou služby IKT stejně jako centrálně řízené smlouvy.
• Chybějící identifikátory. Interní číslo dodavatele není náhrada LEI ani EUID. Alternativní kód je vyhrazen fyzickým osobám jednajícím v rámci podnikatelské činnosti.
• Nekonzistentní identita napříč vzory. Identifikátor poskytovatele se přebírá z B_05.01; když se tentýž dodavatel objeví ve dvou vzorech pod různými kódy, registr se rozpadne.
• Podcenění násobení řádků. Čl. 4 odst. 2 žádá jednu hodnotu na datový prvek a další řádek pro každou další platnou hodnotu. U B_02.02 se vykazují kombinace služeb a funkcí, takže počet řádků roste součinem, ne součtem.
• Formáty a náhradní hodnoty. Data ve formátu ISO 8601, země dvoupísmenným kódem ISO 3166-1, výpovědní lhůty v celých kalendářních dnech, doby obnovy v celých hodinách. Pro neprovedené posouzení nebo neexistující audit se používá 9999-12-31, pro nedefinovanou dobu obnovy 0 a pro smlouvu na dobu neurčitou opět 9999-12-31.
• Nevyplněný slovník škál. Bez vzoru B_99.01 nemá dohled jak vyložit vaše hodnoty nízký, střední a vysoký. Je to poslední vzor v pořadí a zároveň ten, na který se nejčastěji zapomene.
• Jednorázový sběr bez vlastníka. Zásady kvality údajů z čl. 3 odst. 4 a povinnost neprodleně opravovat zjištěné chyby předpokládají průběžnou správu. Registr sestavený jednorázově před odevzdáním je do půl roku neplatný — a mezitím se z něj stal podklad pro rozhodování dohledu.

Praktická rada nakonec: registr se nejlépe drží aktuální tehdy, když je napojený na procesy, které stejně běží — na schvalování nových dodavatelů, na změnové řízení a na periodické přezkumy smluv. Tabulka spravovaná stranou od těchto procesů zastarává rychleji, než se stihne odevzdat.

Pořadí prací při prvním sestavení registru

Kroky vycházejí z vazeb mezi vzory: každý další krok potřebuje výstup předchozího. Nejde o požadavek nařízení, ale o pořadí, které šetří přepracovávání — zejména u subjektů, které registr sestavují poprvé nebo po změně skupinové struktury.

Oficiální zdroje

Údaje o vzorech, sloupcích a číselnících na této stránce vycházejí z českého znění následujících předpisů, stav k 9. 8. 2026. Materiál znění předpisů nenahrazuje.