Pripravenosť na DORA pre finančné subjekty a ich dodávateľov IKT

Nariadenie o digitálnej prevádzkovej odolnosti finančného sektora (DORA) sa uplatňuje od 17. januára 2025. Pre finančné subjekty dnes pripravenosť znamená udržiavať prevádzkový model digitálnej prevádzkovej odolnosti, nie pripravovať sa na budúci termín. Pre dodávateľov technológií znamená pochopiť zodpovednosti voči zákazníkom a to, či sa na nich vzťahuje samostatný režim priameho dohľadu.

Otázka pre vedenie je praktická: dokáže organizácia vysvetliť, ktoré finančné služby závisia od ktorých systémov IKT, ako sa bude riešiť narušenie a aké dôkazy podporujú jej predpoklady o obnove? Politiky sú dôležité, no samy na túto otázku odpovedať nedokážu. Manažment potrebuje prepojený pohľad na zodpovednosti, závislosti, zmluvy, testy, incidenty a nevyriešené riziká.

Pred zostavením kontrolného zoznamu určte svoju rolu

Začnite zdokumentovaným rozhodnutím o uplatniteľnosti pre každú relevantnú právnickú osobu. Článok 2 nariadenia DORA vymedzuje dotknuté kategórie a výnimky. Firma, ktorá sa označuje za FinTech, startup alebo MSP, nie je automaticky v pôsobnosti ani z nej vyňatá.

Medzi príklady dotknutých finančných subjektov patria úverové inštitúcie, platobné inštitúcie, investičné spoločnosti a poisťovne, s výhradou podrobných pravidiel pôsobnosti nariadenia. Zaznamenajte uplatniteľnú kategóriu, prípadné vylúčenie alebo výnimku, príslušný orgán a zdôvodnenie vášho záveru.

Pri dodávateľoch rozlišujte tri pozície:

Dodávateľ, ktorý podporuje kritickú alebo dôležitú finančnú funkciu, sa už len z tohto dôvodu nestáva určeným kritickým tretím poskytovateľom IKT služieb. Finančné subjekty posudzujú dôležitosť svojich funkcií a závislostí; určovanie kritických poskytovateľov prebieha v rámci dohľadu podľa článku 31.

Sídlo otázku dodávateľa nerieši. Poskytovateľ cloudu alebo softvéru so sídlom v USA môže čeliť požiadavkám zákazníkov súvisiacim s DORA, keď obsluhuje finančné subjekty v EÚ. Tento obchodný vzťah ho automaticky nepodriaďuje všetkým povinnostiam uloženým finančnému subjektu.

Aj proporcionalita si vyžaduje odôvodnené posúdenie. Článok 4 zohľadňuje faktory vrátane veľkosti, celkového rizikového profilu a povahy, rozsahu a zložitosti služieb. Článok 16 stanovuje zjednodušený rámec riadenia rizík IKT pre určené kategórie. Tieto pojmy nie sú zameniteľné a bežný status MSP nie je univerzálnou skratkou. Analýzu oprávnenosti uchovávajte spolu s rozhodnutím o pôsobnosti.

Zviditeľnite zodpovednosť manažmentu

Podľa článku 5 nariadenia DORA nesie riadiaci orgán konečnú zodpovednosť za riadenie rizík IKT finančného subjektu. Delegovanie implementácie na CISO, technologický tím alebo externého poskytovateľa túto zodpovednosť neprenáša.

Vedenie by malo určiť, kto rozhodnutia navrhuje, kto ich schvaľuje a kto kontroluje, či implementácia funguje. Prevádzkový model by mal pokrývať kontinuitu činností, reakciu na incidenty a obnovu, dojednania s tretími stranami, rozpočet a znalosti potrebné na zmysluplný dohľad.

Praktickým odporúčaním je poskytnúť manažmentu reportingový balík zameraný na rozhodnutia namiesto dashboardu s percentom dokončenia. Zahrňte:

• Kritické alebo dôležité funkcie s neotestovanými predpokladmi obnovy.
• Závažné incidenty, dopady na zákazníkov a nedokončené nápravné opatrenia.
• Závislosti od dodávateľov s neúplnými zmluvami alebo slabými možnosťami odchodu.
• Významné medzery v opatreniach, zodpovedných vlastníkov a termíny nápravy.
• Rozhodnutia, ktoré si vyžadujú financovanie, zmenu dodávateľa alebo explicitnú reakciu na riziko.

Pri každej medzere by sa mala rozlišovať regulačná požiadavka, súčasná prevádzková slabina a navrhovaná náprava. Chýbajúci záznam o schválení je niečo iné ako záloha, ktorú nemožno obnoviť. Obe si môžu vyžadovať riešenie, ale potrebujú rozdielnych vlastníkov a priority.

Schválenie plánu nápravy manažmentom nie je povolením odkladať uplatniteľné povinnosti donekonečna. Ak je medzera podstatná, zvážte popri dlhodobejšej oprave aj okamžité záruky, eskaláciu a prípadné dôsledky voči orgánu dohľadu.

Postavte program okolo finančných funkcií

Inventár aktív je nevyhnutný, plánovanie odolnosti by sa však malo začínať službou, ktorá musí pokračovať. Identifikujte finančnú funkciu, jej biznisového vlastníka, dôsledky narušenia a systémy a poskytovateľov, ktorí ju podporujú.

Pri platobnej službe zmapujte identity, cloudovú infraštruktúru, spracovanie transakcií, monitoring a eskaláciu k dodávateľom. Zahrňte aj menej viditeľné závislosti, ako sú DNS, konektivita, privilegovaný prístup, šifrovacie kľúče a nástroje podpory. Alternatívne produkčné prostredie môže byť nepoužiteľné, ak závisí od tej istej zlyhanej služby identít.

Výsledná mapa by mala každú funkciu prepojiť s:

• Podpornými aplikáciami, infraštruktúrou, informačnými aktívami a externými službami.
• Relevantnými zmluvami a vlastníkmi služieb.
• Cieľmi obnovy a analýzou dopadov na podnikanie, ktorá ich podporuje.
• Dojednaniami o detekcii, reakcii, obnove a komunikácii.
• Testami, zisteniami a nevyriešenými rizikami závislostí.

Mapu overte s prevádzkovými aj biznisovými tímami. Záznamy z nákupu ukazujú, čo sa kúpilo; nemusia nevyhnutne ukazovať, ako služba funguje dnes.

Tento model použite na usporiadanie riadenia rizík IKT, riadenia a hlásenia incidentov, testovania odolnosti a rizika IKT tretích strán. DORA obsahuje aj ustanovenia o dobrovoľnej výmene informácií o kybernetických hrozbách. Ak sa do nej zapojíte, definujte členstvo, dôvernosť, povolené použitie a pravidlá zaobchádzania, namiesto toho, aby ste výmenu chápali ako neobmedzenú výmenu údajov o incidentoch.

Premeňte riadenie rizík IKT na financovanú prácu

Ustanovenia DORA o riadení rizík IKT pokrývajú identifikáciu, ochranu a prevenciu, detekciu, reakciu a obnovu, učenie sa a komunikáciu. Rámec musí tieto činnosti prepájať, a nie ich nechávať ako samostatné zbierky politík.

Analýzu medzier začnite zmapovanými funkciami. Pýtajte sa, či opatrenia na riadenie prístupu chránia ich systémy, či sa riešia zraniteľnosti, či sú zmeny riadené, či sa odhaľuje podozrivá aktivita a či dojednania o obnove zohľadňujú realistické zlyhania. Zvážte technické poruchy a prevádzkové chyby, nielen škodlivé útoky.

Pre každú podstatnú slabinu vytvorte záznam o náprave obsahujúci vlastníka, dopad na podnikanie, požadovaný úkon, kritériá dokončenia a dôkaz o uzavretí. Závislosti sú dôležité: zlepšenie postupov obnovy si môže vyžadovať zmeny v prístupe k zálohám, záväzkoch dodávateľov a školení pracovníkov skôr, než bude možný úspešný test.

Ciele obnovy by mali vychádzať z potrieb podniku a analýzy dopadov, nie z toho, čo náhodou ponúka štandardná úroveň služieb dodávateľa. Ak technická spôsobilosť nedokáže cieľ splniť, manažment musí rozhodnúť, či zlepší architektúru, zmení dojednanie o službe alebo prehodnotí prevádzkový model. Cieľ zapísaný v pláne kontinuity nie je dôkazom obnoviteľnosti.

Pripravte rozhodnutia o incidentoch skôr, než príde narušenie

DORA vyžaduje, aby finančné subjekty riadili incidenty súvisiace s IKT a závažné incidenty hlásili príslušnému orgánu. Články 17 – 23 stanovujú rámec; uplatniteľné regulačné technické a vykonávacie technické predpisy poskytujú podrobné kritériá klasifikácie, prahové hodnoty, obsah hlásení a postupy.

Pri podrobnom harmonograme hlásení sa nespoliehajte na všeobecný kontrolný zoznam pre incidenty. Udržiavajte aktuálnu maticu hlásení, ktorá identifikuje uplatniteľné predpisy, pokyny orgánu, kanál na podanie, fázy hlásenia a výpočet lehôt. Určte zodpovednosť za jej aktualizáciu.

Proces reakcie by mal umožniť vykonať pod tlakom niekoľko rozhodnutí:

• Kto zaznamenáva časové pečiatky detekcie, posúdenia a klasifikácie?
• Kto získava informácie o dopade od prevádzky a dodávateľov?
• Kto rozhoduje, či sú splnené kritériá závažného incidentu?
• Kto schvaľuje a podáva hlásenia, a to aj mimo bežného pracovného času?
• Kto zabezpečuje komunikáciu so zákazníkmi a ďalšie uplatniteľné oznámenia?

Zdôvodnenie klasifikácie zaznamenajte aj vtedy, keď sa incident nehlási ako závažný. Neúplný úvodný obraz by mal s pribúdajúcimi informáciami viesť k opätovnému posúdeniu, nie k trvalému predpokladu, že udalosť je menej významná.

Záväzky dodávateľov na oznamovanie by mali finančnému subjektu ponechať dostatok času na posúdenie a splnenie vlastných povinností. Úlohy hlásenia možno tam, kde je to povolené, zabezpečovať externe, zodpovednosť však zostáva na finančnom subjekte.

Ak závažný incident súvisiaci s IKT ovplyvní finančné záujmy klientov, DORA vyžaduje, aby finančné subjekty bez zbytočného odkladu informovali týchto klientov o incidente a o opatreniach prijatých na zmiernenie jeho nepriaznivých účinkov. Samostatne posúďte povinnosti pri porušení ochrany osobných údajov a ďalšie uplatniteľné pravidlá. Jedno narušenie môže vyvolať viacero rozhodnutí o oznámení s rôznymi príjemcami a právnymi testami.

Testujte predpoklady, na ktoré sa manažment spolieha

Program testovania digitálnej prevádzkovej odolnosti by mal byť primeraný a založený na riziku. Posúdenia zraniteľností, scenárové cvičenia, bezpečnostné testovanie a testy obnovy odpovedajú na rôzne otázky; žiadne z nich by sa nemalo považovať za univerzálnu náhradu za ostatné.

Cvičenie typu tabletop môže zistiť, či osoby s rozhodovacou právomocou rozumejú eskalácii. Nedokáže však preukázať, že transakčné údaje možno presne obnoviť. Penetračný test môže odhaliť zneužiteľné slabiny bez toho, aby preukázal, že službu dokáže prevziať alternatívny dodávateľ.

Pre každý test definujte funkciu, scenár, rozsah, kritériá úspechu, dojednania o nezávislosti tam, kde sa vyžadujú, a očakávané dôkazy. Uchovajte výsledky, zistenia, rozhodnutia o náprave a výsledky opakovaných testov. Uplatniteľné požiadavky na pokrytie a frekvenciu overte voči DORA a relevantným predpisom vrátane prípadných výnimiek alebo ustanovení o zjednodušenom rámci.

Penetračné testovanie na základe hrozieb (TLPT) je samostatnou požiadavkou dohľadu pre vybrané finančné subjekty podľa článku 26. Nie je to plošná povinnosť pre každý finančný podnik alebo dodávateľa IKT.

Manažment by mal skúmať zlyhané predpoklady, nie len to, či sa testy uskutočnili. Ak cvičenie odhalí, že obnova závisí od jedného nedostupného administrátora, výsledkom je prevádzkové riziko, ktoré si vyžaduje riešenie, nie splnený míľnik testovania.

Riziko tretích strán ako otázka kontinuity služieb

Podľa DORA zostáva finančný subjekt zodpovedný za svoje povinnosti aj pri využívaní dodávateľov IKT. Články 28 – 30 prepájajú posúdenie rizika tretích strán, zmluvné dojednania, monitorovanie a plánovanie odchodu.

Udržiavajte register aj prevádzkový obraz

Finančné subjekty musia udržiavať register informácií o zmluvných dojednaniach o IKT službách na požadovanej individuálnej, subkonsolidovanej a konsolidovanej úrovni. Pre jeho štruktúru použite uplatniteľné vykonávacie technické predpisy. Nákupná tabuľka alebo zoznam schválených dodávateľov automaticky nepostačuje.

Register zosúlaďte so zmluvami, vlastníctvom služieb a mapami závislostí. Zachovajte požadované rozlíšenie pre služby podporujúce kritické alebo dôležité funkcie. Nový subdodávateľ, lokalita poskytovania služby alebo rozšírený rozsah môžu zmeniť rizikový obraz, aj keď meno dodávateľa zostane rovnaké.

Porovnajte zmluvy so skutočnou službou

Posúďte uplatniteľné zmluvné požiadavky vrátane opisov služieb, lokalít, ochrany údajov, prístupu k údajom a ich obnovy, súčinnosti pri incidentoch, spolupráce, práv na ukončenie a úrovní služieb. Dojednania podporujúce kritické alebo dôležité funkcie si vyžadujú dodatočné ustanovenia vrátane relevantných dojednaní o vykazovaní, kontinuite, prístupe, inšpekcii, audite a odchode.

Právne oddelenie, nákup, technológie a biznisoví vlastníci by ich mali posudzovať spoločne. Zmluvné právo na audit sa môže v praxi ťažko uplatňovať; prisľúbené dojednanie o obnove nemusí pokrývať celý reťazec služieb zákazníka. Tieto obmedzenia identifikujte skôr, než dojednanie prijmete.

Preskúmajte koncentráciu a schopnosť odísť

Koncentračné riziko sa neobmedzuje na nákup viacerých služieb od jednej spoločnosti. Rôzni dodávatelia sa môžu spoliehať na tú istú cloudovú platformu, región, sieť alebo subdodávateľa. Posúďte nahraditeľnosť, zložitosť migrácie a dôsledky spoločného zlyhania.

Plán odchodu by mal riešiť formáty údajov, ich extrakciu, prístup, závislosti migrácie, súčinnosť pri prechode, vymazanie a kontinuitu počas presunu. Pri kritických alebo dôležitých funkciách berte testovanie a revíziu odchodu ako vecnú prácu, nie ako cvičenie v písaní dokumentov.

Dodávatelia si môžu pripraviť konzistentný balík uistenia obsahujúci rozsah služby, hranice zodpovedností, kontakty pre incidenty, dôkazy o kontinuite, informácie o subdodávkach a zmluvné pozície. Požiadavky konkrétnych zákazníkov si aj tak vyžadujú posúdenie; certifikát ich nenahrádza.

Pochopte, kde sa DORA a NIS2 stretávajú

DORA je nariadenie EÚ s priamou uplatniteľnosťou. NIS2 je smernica transponovaná prostredníctvom vnútroštátneho práva, ktorej uplatniteľnosť závisí od odvetvia, veľkosti, služby a pravidiel zaradenia. Lehota na jej transpozíciu uplynula 17. októbra 2024; organizácie musia preskúmať uplatniteľnú vnútroštátnu úpravu, a nie predpokladať jediný rovnaký prevádzkový režim.

Článok 1 ods. 2 DORA spolu s článkom 4 NIS2 stanovuje odvetvovo špecifický vzťah pre dotknuté finančné subjekty v relevantných oblastiach. Nevykladajte to ako pokyn zdvojovať rovnocenné opatrenia na riadenie rizík a hlásenie incidentov. Rovnako nepredpokladajte, že to odstraňuje povinnosti každej spoločnosti vo finančnej skupine alebo v jej dodávateľskom reťazci.

Poskytovateľ riadených služieb, ktorý obsluhuje banku, môže potrebovať vlastné posúdenie podľa NIS2 a zároveň plniť zmluvné záväzky súvisiace s DORA. Matica povinností pre jednotlivé subjekty by mala zaznamenávať právny základ, pôsobnosť, orgán, cestu hlásenia a požadované dôkazy.

Spoločné opatrenia môžu podporovať DORA, ISO 27001, povinnosti v oblasti ochrany súkromia aj uistenie pre zákazníkov tam, kde sa rozsah a dôkazy zhodujú. Revíziu prístupov alebo test obnovy využite opakovane, ak skutočne podporuje viacero požiadaviek, no zachovajte špecifiká finančného sektora. Certifikát ISO 27001 nepreukazuje súlad s DORA.

Odlišuje sa aj presadzovanie. Právomoci dohľadu a sankcie voči finančným subjektom podľa DORA závisia od jeho ustanovení a uplatniteľných vnútroštátnych opatrení; pre určených kritických poskytovateľov platí samostatný režim dohľadu. Nerozpočtujte riziko okolo údajne univerzálnej pokuty podľa DORA. Posúďte relevantnú právnu expozíciu a prevádzkové dôsledky nedostatočnej odolnosti.

Praktický príklad: revízia závislostí platobnej služby

Zoberme si ilustratívnu platobnú inštitúciu, ktorá využíva cloudovú platformu, poskytovateľa identít a externe zabezpečovanú monitorovaciu službu. Predpokladajme, že inštitúcia je v pôsobnosti DORA a vykonávanie platieb je klasifikované ako kritická alebo dôležitá funkcia.

Prvá revízia odhalí tri slabiny: produkčné prostredie a prostredie obnovy zdieľajú tú istú závislosť od identít; proces eskalácie incidentov u dodávateľa monitoringu je nejasný; a plán odchodu z cloudu uvádza alternatívneho poskytovateľa bez preukázania extrakcie a migrácie údajov.

Manažment zadá tri prepojené pracovné balíky:

Biznisový vlastník overí, či sú ciele obnovy platieb naďalej dosiahnuteľné. Compliance overí, či postupy hlásenia a záznamy v registri zodpovedajú dojednaniam. Manažment schváli potrebné financovanie a preskúma zostávajúce obmedzenia.

Tento príklad sám osebe nepreukazuje súlad. Ukazuje, ako jedna funkcia dokáže odhaliť rozhodnutia, ktoré by v oddelených kontrolných zoznamoch pre politiky, dodávateľov a testovanie zostali skryté.

Zaveďte rytmus revízií založený na dôkazoch

DORA nemá univerzálny certifikačný proces, ktorý by nahrádzal priebežné povinnosti. Nezávislé uistenie môže manažmentu poskytnúť informácie, pripravenosť sa však musí preukazovať fungujúcimi opatreniami, záznamami a tam, kde sa to vyžaduje, spoluprácou s orgánom dohľadu.

Praktickým ďalším krokom je vybrať jednu kritickú alebo dôležitú funkciu a zostaviť jej rozhodnutie o pôsobnosti, mapu závislostí, posúdenie rizík, zmluvy, postupy pre incidenty, výsledky testov a otvorené úlohy. Preskúmajte, či tieto záznamy rozprávajú konzistentný príbeh.

Secani tento workflow podporuje modelovaním systémov a služieb, prepájaním závislostí a udržiavaním požiadaviek, dôkazov, vlastníkov, úloh a rozhodnutí z revízií v kontexte. Existujúce materiály nahrajte k relevantným objektom, medzery premeňte na priradenú prácu a pri návrhoch a záveroch s podporou AI zachovajte explicitné ľudské schválenie.

Keď sú vlastníctvo a cesty k dôkazom jasné, rozšírte prácu z tejto prvej funkcie ďalej. Vedenie by malo vidieť, čo bolo preukázané, čo zostáva neisté a aké rozhodnutie je potrebné ako ďalšie.