Čo musia finančné subjekty preukázať o riadení prístupov podľa DORA

DORA neobmedzuje riadenie prístupov na viacfaktorové overovanie alebo každoročnú kontrolu používateľov. Pri dotknutých finančných subjektoch ho prepája s riadením rizík IKT. Ľudia a systémy musia byť jednoznačne identifikovateľní a účty riadené počas celého životného cyklu. Oprávnenia sa majú riadiť zásadami nevyhnutnej znalosti, nevyhnutného používania a minimálnych oprávnení. Nezlučiteľné práva treba oddeliť a nepotrebné prístupy odobrať bez zbytočného odkladu.

Podrobné požiadavky nájdete aj mimo hlavného textu DORA. Nariadenie (EÚ) 2022/2554 stanovuje rámec digitálnej prevádzkovej odolnosti a uplatňuje sa od 17. januára 2025. Delegované nariadenie Komisie (EÚ) 2024/1774 spresňuje pravidlá riadenia rizík IKT a obsahuje výslovné požiadavky na správu identít a riadenie prístupov. Stručné zhrnutie DORA preto nestačí na pochopenie prevádzkových podrobností, ktoré môžu orgány dohľadu preverovať.

Praktická odpoveď: finančný subjekt má vedieť doložiť, kto alebo čo získalo prístup, prečo bol potrebný, kto ho schválil, aké opatrenia ho obmedzujú, kedy prešiel kontrolou, ako rýchlo sa zmenil alebo skončil a čo potvrdzuje vykonanie vo všetkých príslušných IKT aktívach.

Táto príručka vysvetľuje tento reťazec dôkazov. Vychádza z právnych textov EÚ a materiálu Európskeho orgánu dohľadu skontrolovaného 12. septembra 2026. Uplatniteľnosť, proporcionalita a očakávania dohľadu stále závisia od subjektu, jeho sektora, jeho rizikového profilu IKT a príslušného orgánu.

Rozlišujte jednotlivé právne predpisy

DORA je priamo uplatniteľné právo EÚ. Zahŕňa širokú škálu finančných subjektov vrátane úverových inštitúcií, platobných inštitúcií, investičných spoločností, poisťovní a zaisťovní, inštitúcií zamestnaneckého dôchodkového zabezpečenia, poskytovateľov služieb krypto-aktív a niekoľko ďalších kategórií uvedených v článku 2. Vytvára tiež rámec dohľadu pre poskytovateľov kritických IKT služieb tretích strán.

Rámec zahŕňa viac než riadenie prístupov: riadenie rizík IKT, riešenie a hlásenie incidentov, testovanie odolnosti, riziká tretích strán aj výmenu informácií. Riadenie prístupov je jeho súčasťou. Nedostatočný postup pri nástupe, zmene pracovného zaradenia či odchode nie je len problémom správy adresára. Môže ohroziť kritické alebo dôležité funkcie, sťažiť vyšetrovanie a znemožniť doloženie zodpovednosti.

Podrobné povinnosti týkajúce sa prístupu relevantné pre väčšinu finančných subjektov sú uvedené v delegovanom nariadení 2024/1774:

• Článok 20 sa týka správy identít;
• Článok 21 sa týka kontroly prístupu;
• Článok 19 prepája personálne pravidlá so zodpovednosťou za bezpečnosť IKT a vrátením IKT a informačných aktív;
• Článok 12 sa zaoberá postupmi, systémami a uchovávaním protokolov;
• ostatné ustanovenia spájajú klasifikáciu aktív, riadenie zmien, riešenie incidentov a kontinuitu podnikania s rovnakým rámcom riadenia rizík IKT.

Články 20 a 21 sú v hlave II. Subjekty, na ktoré sa vzťahuje článok 16 ods. 1 DORA, sa namiesto toho riadia zjednodušeným rámcom v hlave III vrátane článku 33 o kontrole prístupu. Článok 33 vyžaduje pravidelné preskúmanie a odobratie nepotrebných práv, ale neopakuje ročné a šesťmesačné intervaly podľa článku 21. Pred prijatím týchto intervalov ako zákonného minima potvrďte príslušný režim.

Čo vyžaduje článok 20 od správy identít

Článok 20 vyžaduje zdokumentované a implementované politiky a postupy správy identít, ktoré umožňujú jedinečnú identifikáciu a autentifikáciu fyzických osôb a systémov pristupujúcich k informáciám finančného subjektu. Neobmedzuje sa len na zamestnancov. Zamestnanci poskytovateľov služieb IKT tretích strán, ktorí majú prístup k informáciám alebo aktívam IKT, sú výslovne relevantní.

Zásady musia poskytovať jedinečnú identitu zodpovedajúcu jedinečnému používateľskému účtu pre každého zamestnanca alebo príslušného zamestnanca tretej strany. Subjekt musí viesť záznamy o pridelených identitách v súlade s platnými pravidlami EÚ a vnútroštátnymi pravidlami uchovávania údajov. Musí tiež prevádzkovať proces životného cyklu zahŕňajúci vytváranie, zmenu, kontrolu, aktualizáciu, dočasnú deaktiváciu a zrušenie všetkých účtov.

Nariadenie uvádza, že automatizované riešenia na správu životného cyklu identít sa majú zaviesť tam, kde je to uskutočniteľné a vhodné. Toto znenie neukladá všeobecnú povinnosť kúpiť konkrétny produkt IGA. Výlučne manuálny postup sa však obhajuje ťažšie, ak je automatizácia realizovateľná, riziká významné a ručná práca nevytvára včasné a úplné podklady.

Užitočný záznam identity preto spája aspoň:

1. identitu osoby, služby alebo systému;
2. smerodajný zdroj a stav zamestnania alebo zmluvy;
3. jedinečné účty spojené s touto identitou;
4. vlastníka a pracovný účel strojových identít;
5. práva, skupiny, roly a privilegované priradenia spojené s každým účtom;
6. schválenie, dátumy účinnosti a podmienky uplynutia platnosti;
7. históriu kontrol a odoberania prístupov; a
8. výnimky, náhradné opatrenia a osoby zodpovedné za riziká.

Bez týchto prepojení môžete zablokovať účet v adresári, no ponechať aktívny prístup v lokálnej aplikácii, cloude, databáze, núdzovom účte či na portáli dodávateľa.

Článok 21: ako doložiť fungovanie opatrení

Článok 21 vyžaduje zdokumentované a zavedené pravidlá riadenia prístupov. Tabuľka rozlišuje zákonné požiadavky a praktické podklady, ktorými môže organizácia doložiť ich plnenie. Uvedené príklady podkladov sú možnosťami implementácie, nie ďalšími zákonnými povinnosťami.

Ako často treba kontrolovať prístupy

Delegované nariadenie neponecháva každý interval preskúmania nedefinovaný. V článku 21 písm. e) bode iv) sa vyžaduje, aby sa prístupové práva aktualizovali, keď sú potrebné zmeny, a aspoň raz ročne pre systémy IKT iné ako tie, ktoré podporujú kritické alebo dôležité funkcie; pre tieto podporné systémy je interval minimálne každých šesť mesiacov. Kontrola prístupu by mala identifikovať potrebné aktualizácie a overiť ich dokončenie. Revízia, ktorá zaznamenáva rozhodnutia bez ich uplatnenia, nespĺňa požiadavku na aktualizáciu.

Tieto intervaly určujú najdlhší prípustný odstup, nie dôvod čakať. Odchod, zmena zaradenia či rizika alebo zistenie nepotrebného prístupu majú viesť k aktualizácii na základe udalosti. Polročná kontrola nevyrieši účet bývalého zamestnanca, ktorý zostal päť mesiacov aktívny.

Pri kontrole potrebuje zodpovedný človek vidieť používateľa alebo systém, aktuálne oprávnenia, ich účel a vlastníka, dostupný údaj o poslednom použití, privilegované práva, konflikty aj dôsledky odobratia. Po rozhodnutí treba zmenu vykonať v aplikácii a overiť výsledok. Tabuľka so schváleniami bez potvrdenia vykonania nie je úplným záznamom kontroly.

Privilegované, núdzové a zdieľané prístupy potrebujú osobitný postup

Privilegovaný prístup môže zmeniť konfigurácie, nastavenia zabezpečenia, údaje alebo identity. V článku 21 sa vyžaduje, aby bol privilegovaný, núdzový a administrátorský prístup pridelený systémom IKT na základe potreby použitia alebo ad hoc. Vyžaduje tiež silnú autentifikáciu pre privilegovaný prístup a pre prístup k aktívam IKT podporujúcim kritické alebo dôležité funkcie, ako aj pre vzdialené a verejne dostupné aktíva.

Účinný prevádzkový model oddeľuje bežnú identitu od administrátorskej. Zvýšenie oprávnení sa schvaľuje na konkrétnu úlohu, má obmedzené trvanie a jeho použitie sa zaznamenáva. Výnimočné činnosti sa preverujú. Trvalá rola správcu udelená iba preto, že ju človek možno neskôr využije, odporuje princípu minimálnych oprávnení.

Rovnako dôsledne treba posudzovať všeobecné a zdieľané účty. DORA ich úplne nezakazuje. Vyžaduje čo najväčšie obmedzenie ich používania a identifikovateľnosť používateľov pri vykonávaných činnostiach. Odôvodnená výnimka uvádza vlastníka, účel, používateľov alebo spôsob ich dohľadania, overovanie totožnosti, zaznamenávanie činnosti, koniec platnosti a interval kontrol. Ak viacerí ľudia poznajú rovnaké heslo a činnosť nemožno spoľahlivo priradiť konkrétnej osobe, zodpovednosť nie je doložená.

Ak je to možné a vhodné, delegované nariadenie očakáva aj automatizované riadenie privilegovaného prístupu. Automatizácia by mala obmedziť privilégiá, vynútiť uplynutie platnosti a vytvoriť dôkazy. Nemalo by to jednoducho automatizovať schvaľovanie zle navrhnutých stálych rolí.

Otestujte odobratie prístupov pri odchode zamestnanca

V článku 21 sa vyžaduje odobratie prístupových práv bez zbytočného odkladu, keď sa pracovný pomer skončí alebo prístup už nie je potrebný. V článku 19 sa vyžaduje, aby zamestnanci pri ukončení vrátili aktíva IKT a hmotné informačné aktíva patriace subjektu. Článok 20 vyžaduje, aby riadenie životného cyklu zahŕňalo zrušenie účtov.

Tieto ustanovenia robia z odchodu pracovníka užitočný test celej architektúry identít. Organizácia má poznať smerodajný čas ukončenia, nájsť všetky súvisiace účty, odobrať aktívne prístupy vrátane privilegovaných a núdzových oprávnení, zabezpečiť vrátenie vybavenia a doložiť konečný stav. Rovnakú dôslednosť vyžadujú dodávatelia a pracovníci tretích strán po skončení zmluvnej potreby.

„Bez zbytočného odkladu“ nemá pre každý odchod rovnaký počet minút. Organizácia má určiť lehoty podľa rizika. Pri okamžitom ukončení pracovného pomeru človeka s privilegovanými prístupmi môže byť potrebné koordinované odobratie počas oznámenia. Pri plánovanom odchode do dôchodku bez takých práv môže postačiť vopred nastavený postup. Odôvodnenie aj výsledok treba zaznamenať.

Zahrňte systémové identity do riadenia prístupu

Článok 20 sa týka fyzických osôb a systémov prístup k informáciám. Servisné účty, pracovné zaťaženie, integrácie, roboty, klienti API a identity automatizácie preto môžu spadať do problému správy identít. Často prežijú projekty, používajú neinteraktívne prihlasovacie údaje a hromadia široké povolenia.

Pri každej strojovej identite evidujte zodpovedného človeka, technického správcu, účel, prostredia, oprávnenia, spôsob overovania, miesto uloženia prihlasovacích údajov, pravidlá ich obmeny, posledné zistené použitie, závislosti a podmienky ukončenia. Keď zodpovedný človek odíde, správu treba odovzdať. Zablokovanie jeho účtu nestačí, ak skript, token či integrácia zostanú bez nového vlastníka.

Pri kontrole prístupov treba rozlišovať používateľské účty a identity služieb. Otázka, či je servisný účet s nezrozumiteľným názvom „stále potrebný“, manažérovi nestačí. Na spoľahlivé rozhodnutie potrebuje poznať účel účtu, závislosti a jeho používanie.

Aj za prístup dodávateľa zodpovedá finančný subjekt

DORA venuje veľkú pozornosť rizikám IKT tretích strán. Zmluvné opatrenia nenahrádzajú interné riadenie prístupov. Finančný subjekt potrebuje prehľad o externých osobách a systémoch s prístupom k jeho aktívam IKT, prípadne aj o subdodávateľoch.

Prístup tretej strany má mať aspoň zodpovedného garanta, odkaz na zmluvu alebo službu, schválený rozsah, začiatok a koniec platnosti, spôsob overovania a osobu zodpovednú za kontrolu. Na vzdialené a privilegované prístupy sa majú vzťahovať prísnejšie opatrenia opísané vyššie. Po skončení zmluvy, pridelenia či spolupráce sa musí požiadavka na odobratie dostať do príslušných systémov.

Subjekt má vedieť prepojiť záznamy o prístupoch s registrom zmluvných dojednaní, ak to pomáha identifikovať riziká IKT služieb. Zdroj Európsky orgán pre bankovníctvo: register informácií DORA potvrdzuje, že DORA sa uplatňuje od 17. januára 2025 a že príslušné subjekty musia udržiavať komplexné informácie o zmluvných dojednaniach s poskytovateľmi IKT tretích strán. Register a zoznam identity odpovedajú na rôzne otázky, ale každý môže odhaliť medzery v tom druhom.

Pripravte auditné podklady pre orgán dohľadu

Pravidlá dokladajú návrh opatrení. Orgány dohľadu a audítori potrebujú aj podklady o ich fungovaní v praxi. Užitočný súbor podkladov k riadeniu prístupov môže odpovedať na päť otázok.

1. Čo by sa malo stať?

Zachovajte schválenú politiku správy identít, kontroly prístupu, autentifikácie, privilegovaného prístupu, SoD, fyzického prístupu a uchovávania. Zobrazte rozsah, vlastníkov, dátumy účinnosti, históriu kontrol a prepojenie na ICT riziká a klasifikáciu aktív.

2. Prečo bol povolený prístup?

Pri vzorke rizikových prístupov uchovajte žiadosť, pracovný účel, systém a oprávnenie, schvaľovateľa, vyhodnotenie pravidiel, výsledok SoD, obdobie platnosti a výsledok vykonania zmeny. Pri núdzovom prístupe doložte aj dôvod použitia mimoriadneho postupu.

3. Čo sa zmenilo?

Uchovajte smerodajné udalosti nástupu, zmeny zaradenia a odchodu spolu s následnými zmenami účtov. Rozlišujte, čo bolo vyžiadané, schválené, o čo sa systém pokúsil, čo dokončil a čo overil porovnaním so skutočným stavom. Neúspešná zmena má vytvoriť výnimku s pridelenou zodpovednosťou, nie zostať skrytá v technickom logu.

4. Bol prístup preskúmaný?

Uchovajte rozsah kampane, posudzovateľa, zobrazené podklady, rozhodnutie, čas, eskaláciu, odobratie aj potvrdenie dokončenia. Rozlíšte systémy podporujúce kritické alebo dôležité funkcie, ktoré patria do polročnej kontroly, a ostatné IKT systémy s ročnou kontrolou.

5. Fungovala kontrola?

Použite porovnanie so skutočným stavom, vzorky z cieľových systémov, údaje o oneskorených úlohách, zisťovanie účtov bez vlastníka, prehľad neaktívnych privilegovaných účtov a testy odchodov. Doložte nápravu neúspešných alebo oneskorených krokov.

90-dňový plán zlepšenia kontroly prístupu

Nasledujúci postup vám pomôže overiť opatrenia v praxi. Riadenie prístupov však zostáva priebežnou úlohou, ktorú jednorazová certifikácia neuzavrie.

Dni 1 až 30: určte rozsah a zistite stav. Potvrďte príslušné ustanovenia DORA. Určte kritické alebo dôležité funkcie a aktíva IKT, ktoré ich podporujú. Zmapujte smerodajné zdroje identít, úložiská privilegovaných prístupov, prístupy tretích strán a strojové identity. Schváľte zodpovedné osoby a lehoty odoberania prístupov podľa rizika. Zdokumentujte známe medzery v pokrytí.

Dni 31 až 60: zaveďte opatrenia a prepojte systémy. Zaveďte jednotný záznam žiadosti a schválenia. Pripojte najrizikovejšie systémy k udalostiam životného cyklu. Kde je to možné, zaveďte časovo obmedzené privilegované prístupy. Definujte pravidlá SoD pre závažné konflikty, rozsah kontrol a eskaláciu. Zabezpečte, aby po ukončení identity nezostali aktívne relácie ani alternatívne lokálne účty.

Dni 61 až 90: overte výsledky a zlepšujte. Vykonajte jeden test odchodu od začiatku po koniec, overte vzorku privilegovaných prístupov a spustite kontrolnú kampaň pre kritickú skupinu. Porovnajte výsledky so stavom cieľových systémov. Merajte oneskorené odobratia, neúspešné zmeny, účty bez vlastníka a nevyriešené rozhodnutia z kontrol. Výnimky a termíny nápravy predložte osobe zodpovednej za riziká IKT.

Bežné chyby, ktoré vytvárajú falošnú istotu

„MFA zabezpečuje, aby bol účet v súlade.“ Silné overovanie chráni prihlasovanie. Nepotvrdzuje však, že používateľ daný účet a jeho oprávnenia potrebuje.

„Účet v adresári je deaktivovaný, takže prístup už neexistuje.“ Lokálne účty, relácie aplikácií, tokeny, identity služieb a fyzický prístup môžu zostať.

"Manažér schválil tabuľku." Podpis nestačí, ak schvaľovateľ nepoznal význam oprávnení alebo sa zmeny nevykonali.

„Za používateľov dodávateľa zodpovedá dodávateľ.“ Dodávateľ môže spravovať účty, ale finančný subjekt naďalej zodpovedá za riadenie prístupov k svojim aktívam a informáciám.

"Ročná kontrola znamená ročné čistenie." Prístupy treba upravovať aj pri zmenách. Pri systémoch podporujúcich kritické alebo dôležité funkcie platí navyše kontrola najmenej raz za šesť mesiacov.

"DORA vyžaduje tento produkt." DORA a delegované nariadenie stanovujú požiadavky na pravidlá, opatrenia a ich výsledky. Vyberajte technológiu, ktorá ich vo vašom prostredí dokáže spoľahlivo podporiť.

Otázky, ktoré by si mal klásť manažment

1. Ktoré IKT systémy podporujú naše kritické alebo dôležité funkcie a môžeme dokázať ich šesťmesačné kontroly prístupu?
2. Môže byť každá privilegovaná akcia spojená s identifikovateľnou osobou a schválenou potrebou?
3. Koľko aktívnych účtov nemá určenú osobu, účel alebo zodpovedného vlastníka?
4. Aký čas meriame od smerodajného ukončenia vzťahu po overené odobratie prístupu v každom kritickom systéme?
5. Ktoré dôležité aplikácie zostávajú mimo automatizovaného riadenia životného cyklu identity a prečo je to stále primerané?
6. Vieme spätne vysvetliť rozhodnutie o prístupe od žiadosti cez schválenie, vyhodnotenie pravidiel, vykonanie zmeny a kontrolu až po odobratie?
7. Ktoré účty dodávateľov a strojové identity by zostali aktívne, keby dnes odišiel človek, ktorý za ne zodpovedá?

Jasné odpovede premenia riadenie prístupu zo súboru nastavení na schopnosť prevádzkovej odolnosti. To je štandard, ktorý DORA považuje za relevantný: zdokumentované riadenie, primeraná kontrola a dôkaz, že kontrola funguje v rámci IKT.

Pred výberom platformy potvrďte rozsah produktu

Porovnajte rozsah záznamov easyIGA s podkladmi, ktoré vyžaduje vaše kontrolné opatrenie. easyIGA uchováva zachytené schvaľovacie kroky a rozlišuje prístupy pridelené inde; chýbajúce historické údaje jasne označuje. Kontroly konfliktov sú dostupné pri rozhodovaní, zatiaľ čo tvorba a simulácia pravidiel v easyIGA sú plánované. Skúsenosti nášho tímu zo 14+ implementácií midPointu využívame pri návrhu rozsahu a prevádzke týchto procesov.

Pokračujte v implementácii

Podrobnosti o krokoch nad rámec zrušenia účtu vysvetľuje sprievodca odchodom zamestnanca. Pre širšiu kategóriu a výberové kritériá si prečítajte sprievodcu IGA.

Zdroje a overovací záznam

Rozsah produktu a redakčné znenie aktualizované dňa 24. septembra 2026. Pôvodné dátumy kontroly zdroja uvedené nižšie zostávajú dátumami týchto kontrol.

Všetky zdroje a licencia na obrázok boli skontrolované 12. septembra 2026.

1. Nariadenie (EÚ) 2022/2554 o digitálnej prevádzkovej odolnosti finančného sektora, EUR-Lex
2. Delegované nariadenie Komisie (EÚ) 2024/1774, EUR-Lex
3. Konsolidované delegované nariadenie 2024/1774, EUR-Lex
4. Príprava registra informácií DORA, Európsky orgán pre bankovníctvo
5. Harmonizované hlásenie incidentov DORA platí od 17. januára 2025, Európsky orgán pre bankovníctvo
6. Foto Jakub Żerdzicki, Unsplash, použitá v súlade s licenciou Unsplash License

Článok poskytuje praktické usmernenie a výklad citovaných textov EÚ, nie právne poradenstvo. Pôsobnosť a očakávania vnútroštátneho dohľadu si overte s kvalifikovanými právnikmi a odborníkmi na súlad s predpismi.