DORA-felkészültség pénzügyi szervezetek és IKT-beszállítóik számára

A DORA 2025. január 17. óta alkalmazandó. A pénzügyi szervezetek számára a felkészültség ma már a digitális működési reziliencia működési modelljének fenntartását jelenti, nem pedig egy jövőbeli határidőre való felkészülést. A technológiai beszállítók számára azt jelenti, hogy megértik az ügyfelek felé fennálló felelősségeiket, és azt, hogy vonatkozik-e rájuk egy külön, közvetlen felügyeleti rendszer.

A vezetői kérdés gyakorlati: meg tudja-e magyarázni a szervezet, mely pénzügyi szolgáltatások mely IKT-rendszerektől függenek, hogyan kezelik a fennakadásokat, és milyen bizonyítékok támasztják alá a helyreállításra vonatkozó feltételezéseit? A szabályzatok számítanak, de önmagukban nem tudnak választ adni erre a kérdésre. A vezetésnek összefüggő képre van szüksége a felelősségekről, a függőségekről, a szerződésekről, a tesztekről, az incidensekről és a nyitott kockázatokról.

Határozza meg a szerepét, mielőtt összeállítja az ellenőrzőlistát

Minden érintett jogi egységre vonatkozóan kezdje dokumentált alkalmazhatósági döntéssel. A DORA 2. cikke meghatározza a hatály alá tartozó kategóriákat és a kivételeket. Egy vállalkozás, amely FinTechként, startupként vagy kkv-ként írja le magát, nem automatikusan tartozik a hatály alá, és nem is automatikusan mentesül.

A hatály alá tartozó pénzügyi szervezetek közé tartoznak például a hitelintézetek, a pénzforgalmi intézmények, a befektetési vállalkozások és a biztosítók, a rendelet részletes hatályra vonatkozó szabályai szerint. Rögzítse az alkalmazandó kategóriát, az esetleges kivételt vagy mentességet, az illetékes hatóságot és a következtetése mögötti indoklást.

A beszállítóknál három helyzetet különböztessen meg:

Egy kritikus vagy fontos pénzügyi funkciót támogató beszállító pusztán ezért még nem kijelölt kritikus IKT-szolgáltató harmadik fél. A pénzügyi szervezetek értékelik funkcióik és függőségeik jelentőségét; a kritikus szolgáltatók kijelölése a 31. cikk szerinti felügyeleti keretrendszeren keresztül történik.

A székhely nem dönti el a beszállítói kérdést. Egy amerikai székhelyű felhő- vagy szoftverszolgáltatóval szemben is felmerülhetnek DORA-val kapcsolatos ügyfélkövetelmények, ha uniós pénzügyi szervezeteket szolgál ki. Ez a kereskedelmi kapcsolat nem teszi automatikusan a pénzügyi szervezetekre rótt összes kötelezettség alanyává.

Az arányosság is indokolt értékelést igényel. A 4. cikk olyan tényezőket vesz figyelembe, mint a méret, az átfogó kockázati profil, valamint a szolgáltatások jellege, nagyságrendje és összetettsége. A 16. cikk egyszerűsített IKT-kockázatkezelési keretrendszert ír elő meghatározott kategóriák számára. Ezek nem felcserélhető fogalmak, és a szokásos kkv-státusz nem általános rövidítés. A jogosultsági elemzést a hatályra vonatkozó döntéssel együtt őrizze meg.

Tegye láthatóvá a vezetői elszámoltathatóságot

A DORA 5. cikke szerint a vezető testület viseli a végső felelősséget a pénzügyi szervezet IKT-kockázatainak kezeléséért. Ha a megvalósítást egy CISO-ra, technológiai csapatra vagy külső szolgáltatóra delegálják, ez az elszámoltathatóság nem száll át.

A vezetésnek meg kell határoznia, ki javasol döntéseket, ki hagyja jóvá őket, és ki ellenőrzi, hogy a megvalósítás működik-e. A működési modellnek ki kell terjednie az üzletmenet-folytonosságra, az incidenskezelésre és helyreállításra, a harmadik felekkel kötött megállapodásokra, a költségvetésre és az érdemi felügyelethez szükséges tudásra.

Gyakorlati ajánlásként adjon a vezetésnek döntésközpontú jelentéscsomagot egy készültségi százalékot mutató irányítópult helyett. Tartalmazza a következőket:

• A nem tesztelt helyreállítási feltételezésekkel rendelkező kritikus vagy fontos funkciók.
• Jelentős incidensek, az ügyfelekre gyakorolt hatások és a nyitott korrekciós intézkedések.
• Hiányos szerződésekkel vagy gyenge kilépési lehetőségekkel rendelkező beszállítói függőségek.
• Jelentős kontrollhiányosságok, elszámoltatható felelősök és javítási határidők.
• Finanszírozást, beszállítóváltást vagy kifejezett kockázati választ igénylő döntések.

Minden hiányosságnál meg kell különböztetni a szabályozói követelményt, a jelenlegi operatív gyengeséget és a javasolt orvoslást. Egy hiányzó jóváhagyási dokumentum más, mint egy vissza nem állítható mentés. Mindkettő intézkedést igényelhet, de eltérő felelősöket és prioritásokat kívánnak.

Egy javítási terv vezetői jóváhagyása nem engedély az alkalmazandó kötelezettségek határozatlan idejű elhalasztására. Ha egy hiányosság jelentős, a hosszabb távú javítás mellett mérlegelje az azonnali védelmi intézkedéseket, az eszkalációt és az esetleges felügyeleti következményeket.

Építse a programot a pénzügyi funkciók köré

Az eszközleltár szükséges, de a rezilienciatervezésnek azzal a szolgáltatással kell kezdődnie, amelynek folytatódnia kell. Azonosítsa a pénzügyi funkciót, az üzleti gazdáját, a fennakadás következményeit, valamint az azt támogató rendszereket és szolgáltatókat.

Egy pénzforgalmi szolgáltatásnál térképezze fel az identitáskezelést, a felhőinfrastruktúrát, a tranzakciófeldolgozást, a felügyeletet és a beszállítói eszkalációt. Vegye fel a kevésbé látható függőségeket is, mint a DNS, a hálózati kapcsolat, a kiemelt hozzáférés, a titkosítási kulcsok és a támogató eszközök. Egy alternatív éles környezet használhatatlan lehet, ha ugyanattól a meghibásodott identitásszolgáltatástól függ.

Az így kapott térképnek minden funkciót össze kell kapcsolnia a következőkkel:

• Támogató alkalmazások, infrastruktúra, információs eszközök és külső szolgáltatások.
• Releváns szerződések és szolgáltatásgazdák.
• Helyreállítási célok és az ezeket alátámasztó üzleti hatáselemzés.
• Észlelési, reagálási, helyreállítási és kommunikációs megoldások.
• Tesztek, megállapítások és nyitott függőségi kockázatok.

Validálja a térképet az operatív és az üzleti csapatokkal egyaránt. A beszerzési nyilvántartások azt mutatják, mit vásároltak; nem feltétlenül azt, hogyan működik ma egy szolgáltatás.

Ezt a modellt használja az IKT-kockázatkezelés, az incidenskezelés és -bejelentés, a rezilienciatesztelés és az IKT-harmadik felekkel kapcsolatos kockázatok megszervezésére. A DORA a kiberfenyegetésekre vonatkozó információk önkéntes megosztásáról is tartalmaz rendelkezéseket. Részvétel esetén határozza meg a tagságot, a titoktartást, a megengedett felhasználást és a kezelési szabályokat, ahelyett hogy a megosztást az incidensadatok korlátlan cseréjeként kezelné.

Alakítsa az IKT-kockázatkezelést finanszírozott munkává

A DORA IKT-kockázatkezelési rendelkezései kiterjednek az azonosításra, a védelemre és megelőzésre, az észlelésre, a reagálásra és helyreállításra, a tanulásra és a kommunikációra. A keretrendszernek össze kell kapcsolnia ezeket a tevékenységeket, nem hagyhatja őket különálló szabályzatgyűjteményekként.

A hiányelemzést a feltérképezett funkciókkal kezdje. Kérdezze meg, hogy a hozzáférés-szabályozás védi-e a rendszereiket, kezelik-e a sérülékenységeket, kontrolláltak-e a változtatások, észlelik-e a gyanús tevékenységet, és tükrözik-e a helyreállítási megoldások a reális meghibásodásokat. A rosszindulatú támadások mellett vegye figyelembe a műszaki hibákat és az operatív tévedéseket is.

Minden lényeges gyengeséghez hozzon létre javítási nyilvántartást, amely tartalmazza a felelőst, az üzleti hatást, a szükséges intézkedést, a teljesítési kritériumokat és a lezárás bizonyítékát. A függőségek számítanak: a visszaállítási eljárások javításához szükség lehet a mentésekhez való hozzáférés, a beszállítói kötelezettségvállalások és a munkatársak képzésének módosítására, mielőtt egy sikeres teszt lehetséges lenne.

A helyreállítási célokat az üzleti igényekből és a hatáselemzésből kell levezetni, nem abból, amit egy szállító szokásos szolgáltatási szintje éppen kínál. Ha a műszaki képesség nem tudja teljesíteni a célt, a vezetésnek kell döntenie arról, hogy javítja-e az architektúrát, módosítja-e a szolgáltatási megállapodást, vagy újragondolja-e a működési modellt. Egy folytonossági tervben leírt célérték nem bizonyítja a helyreállíthatóságot.

Készítse elő az incidensdöntéseket a fennakadás előtt

A DORA előírja, hogy a pénzügyi szervezetek kezeljék az IKT-vonatkozású incidenseket, és a súlyos incidenseket jelentsék be az illetékes hatóságnak. A 17–23. cikk határozza meg a keretrendszert; az alkalmazandó szabályozástechnikai és végrehajtás-technikai standardok adják a részletes osztályozási kritériumokat, küszöbértékeket, a bejelentések tartalmát és az eljárásokat.

A részletes bejelentési ütemtervhez ne egy általános incidens-ellenőrzőlistára támaszkodjon. Tartson naprakész bejelentési mátrixot, amely azonosítja az alkalmazandó standardokat, a hatósági utasításokat, a benyújtási csatornát, a bejelentési szakaszokat és a határidők számítását. Jelölje ki, ki felel a naprakészen tartásáért.

A reagálási folyamatnak nyomás alatt is végrehajthatóvá kell tennie több döntést:

• Ki rögzíti az észlelés, az értékelés és az osztályozás időbélyegeit?
• Ki szerzi be a hatásra vonatkozó információkat az üzemeltetéstől és a beszállítóktól?
• Ki dönti el, hogy teljesülnek-e a súlyos incidens kritériumai?
• Ki hagyja jóvá és nyújtja be a bejelentéseket, a szokásos munkaidőn kívül is?
• Ki kezeli az ügyfélkommunikációt és az egyéb alkalmazandó értesítéseket?

Az osztályozás indoklását akkor is rögzítse, ha egy incidenst nem jelentenek be súlyosként. A kezdeti hiányos kép az információk bővülésével újraértékelést kell, hogy kiváltson, nem pedig azt a végleges feltételezést, hogy az esemény csekély jelentőségű.

A beszállítói értesítési kötelezettségvállalásoknak elegendő időt kell hagyniuk a pénzügyi szervezetnek saját kötelezettségei értékelésére és teljesítésére. A bejelentési feladatok, ahol megengedett, kiszervezhetők, de a felelősség a pénzügyi szervezetnél marad.

Ha egy súlyos IKT-vonatkozású incidens érinti az ügyfelek pénzügyi érdekeit, a DORA előírja, hogy a pénzügyi szervezetek indokolatlan késedelem nélkül tájékoztassák ezeket az ügyfeleket az incidensről és a káros hatások enyhítésére hozott intézkedésekről. Külön értékelje a személyes adatokat érintő incidensekre vonatkozó kötelezettségeket és az egyéb alkalmazandó szabályokat. Egyetlen fennakadás több bejelentési döntést is eredményezhet, eltérő címzettekkel és jogi tesztekkel.

Tesztelje azokat a feltételezéseket, amelyekre a vezetés támaszkodik

A digitális működési reziliencia tesztelési programjának arányosnak és kockázatalapúnak kell lennie. A sérülékenységvizsgálatok, a forgatókönyv-alapú gyakorlatok, a biztonsági tesztelés és a helyreállítási tesztek különböző kérdésekre adnak választ; egyiket sem szabad a többi általános helyettesítőjének tekinteni.

Egy asztali gyakorlat megmutathatja, hogy a döntéshozók értik-e az eszkalációt. Azt azonban nem tudja bizonyítani, hogy a tranzakciós adatok pontosan visszaállíthatók. Egy behatolásteszt feltárhat kihasználható gyengeségeket anélkül, hogy bizonyítaná, egy alternatív beszállító át tud venni egy szolgáltatást.

Minden teszthez határozza meg a funkciót, a forgatókönyvet, a hatókört, a sikerkritériumokat, adott esetben a függetlenségi megoldásokat és a várt bizonyítékokat. Őrizze meg az eredményeket, a megállapításokat, a javítási döntéseket és az újratesztelés eredményeit. Vesse össze az alkalmazandó lefedettségi és gyakorisági követelményeket a DORA-val és a vonatkozó standardokkal, beleértve az esetleges mentességeket vagy az egyszerűsített keretrendszerre vonatkozó rendelkezéseket.

A fenyegetésalapú penetrációs tesztelés a 26. cikk szerint a kiválasztott pénzügyi szervezetekre vonatkozó külön felügyeleti követelmény. Nem minden pénzügyi vállalkozásra vagy IKT-beszállítóra vonatkozó általános kötelezettség.

A vezetésnek a meghiúsult feltételezéseket kell áttekintenie, nem csupán azt, hogy a tesztek megtörténtek-e. Ha egy gyakorlat feltárja, hogy a visszaállítás egyetlen, nem elérhető adminisztrátortól függ, az eredmény intézkedést igénylő operatív kockázat, nem pedig egy teljesített tesztelési mérföldkő.

A harmadik felekkel kapcsolatos kockázatot szolgáltatásfolytonossági kérdésként kezelje

A DORA szerint a pénzügyi szervezet IKT-beszállítók igénybevétele esetén is felelős marad a kötelezettségeiért. A 28–30. cikk összekapcsolja a harmadik felekkel kapcsolatos kockázatértékelést, a szerződéses megállapodásokat, a nyomon követést és a kilépési tervezést.

Tartsa karban a nyilvántartást és az operatív képet

A pénzügyi szervezeteknek az IKT-szerződéses megállapodásokra vonatkozó információkról nyilvántartást kell vezetniük a megkövetelt egyedi, szubkonszolidált és konszolidált szinten. A szerkezetéhez az alkalmazandó végrehajtás-technikai standardokat használja. Egy beszerzési táblázat vagy a jóváhagyott szállítók listája nem automatikusan elegendő.

Egyeztesse a nyilvántartást a szerződésekkel, a szolgáltatásgazdákkal és a függőségi térképekkel. Tartsa fenn a kritikus vagy fontos funkciókat támogató szolgáltatásokra vonatkozó kötelező megkülönböztetéseket. Egy új alvállalkozó, szolgáltatási helyszín vagy kibővített hatókör akkor is megváltoztathatja a kockázati képet, ha a beszállító neve ugyanaz marad.

Vizsgálja felül a szerződéseket a tényleges szolgáltatáshoz mérten

Értékelje az alkalmazandó szerződéses követelményeket, beleértve a szolgáltatásleírásokat, a helyszíneket, az adatvédelmet, az adatokhoz való hozzáférést és azok helyreállítását, az incidensek esetén nyújtott segítséget, az együttműködést, a felmondási jogokat és a szolgáltatási szinteket. A kritikus vagy fontos funkciókat támogató megállapodások további rendelkezéseket igényelnek, beleértve a vonatkozó jelentéstételi, folytonossági, hozzáférési, helyszíni vizsgálati, audit- és kilépési megoldásokat.

A jogi, beszerzési, technológiai és üzleti gazdáknak ezeket együtt kell felülvizsgálniuk. Egy szerződéses auditjogot a gyakorlatban nehéz lehet gyakorolni; egy megígért helyreállítási megoldás nem feltétlenül fedi le az ügyfél teljes szolgáltatási láncát. Ezeket a korlátokat a megállapodás elfogadása előtt azonosítsa.

Vizsgálja meg a koncentrációt és a kilépési képességet

A koncentrációs kockázat nem korlátozódik arra, hogy több szolgáltatást vásárolnak egyetlen vállalattól. Különböző beszállítók is támaszkodhatnak ugyanarra a felhőplatformra, régióra, hálózatra vagy alvállalkozóra. Értékelje a helyettesíthetőséget, a migráció összetettségét és egy közös meghibásodás következményeit.

A kilépési tervnek ki kell terjednie az adatformátumokra, az adatkinyerésre, a hozzáférésre, a migrációs függőségekre, az átmeneti támogatásra, a törlésre és az áttérés alatti folytonosságra. A kritikus vagy fontos funkciók esetében a kilépés tesztelését és felülvizsgálatát érdemi munkaként kezelje, ne dokumentumírási gyakorlatként.

A beszállítók egységes garanciális csomagot állíthatnak össze, amely tartalmazza a szolgáltatás hatókörét, a felelősségi határokat, az incidens-kapcsolattartókat, a folytonossági bizonyítékokat, az alvállalkozói információkat és a szerződéses álláspontokat. Az ügyfélspecifikus követelményeket ettől még felül kell vizsgálni; egy tanúsítvány nem helyettesíti őket.

Értse meg, hol találkozik a DORA és a NIS2

A DORA közvetlenül alkalmazandó uniós rendelet. A NIS2 a nemzeti jogon keresztül átültetett irányelv, amelynek alkalmazhatósága az ágazattól, a mérettől, a szolgáltatástól és a bevonási szabályoktól függ. Nemzeti átültetési határideje 2024. október 17. volt; a szervezeteknek az alkalmazandó nemzeti átültetést kell megvizsgálniuk, ahelyett hogy egyetlen, mindenhol azonos működési rendszert feltételeznének.

A DORA 1. cikkének (2) bekezdése a NIS2 irányelv 4. cikkével együtt határozza meg az ágazatspecifikus viszonyt a hatály alá tartozó pénzügyi szervezetek esetében az érintett területeken. Ezt ne értelmezze úgy, mintha az egyenértékű kockázatkezelési és incidensbejelentési kontrollok megkettőzésére utasítana. Ugyanígy ne feltételezze, hogy egy pénzügyi csoport vagy annak ellátási láncának minden vállalatát mentesíti a kötelezettségek alól.

Egy bankot kiszolgáló menedzselt szolgáltatónak saját NIS2-értékelésre lehet szüksége, miközben teljesíti a DORA-val kapcsolatos szerződéses kötelezettségvállalásokat. Egy jogi egységenként vezetett kötelezettségmátrixnak rögzítenie kell a jogalapot, a hatályt, a hatóságot, a bejelentési útvonalat és a szükséges bizonyítékokat.

A közös kontrollok támogathatják a DORA-t, az ISO 27001-et, az adatvédelmi kötelezettségeket és az ügyfeleknek nyújtott garanciákat, ha a hatókör és a bizonyítékok egyeznek. Egy hozzáférés-felülvizsgálatot vagy helyreállítási tesztet akkor használjon újra, ha az valóban több követelményt is alátámaszt, miközben megőrzi a pénzügyi ágazatra vonatkozó részleteket. Egy ISO 27001 tanúsítvány nem bizonyítja a DORA-nak való megfelelést.

A jogérvényesítés is eltér. A DORA pénzügyi szervezetekre vonatkozó felügyeleti jogkörei és szankciói a rendelkezéseitől és az alkalmazandó nemzeti intézkedésektől függenek; a kijelölt kritikus szolgáltatókra külön felvigyázási rendszer vonatkozik. Ne egy feltételezett, általános DORA-bírság köré tervezze a kockázati költségvetést. Értékelje a releváns jogi kitettséget és a nem megfelelő reziliencia operatív következményeit.

Kidolgozott példa: egy pénzforgalmi szolgáltatás függőségi felülvizsgálata

Vegyünk egy szemléltető pénzforgalmi intézményt, amely felhőplatformot, identitásszolgáltatót és kiszervezett felügyeleti szolgáltatást használ. Tegyük fel, hogy az intézmény a DORA hatálya alá tartozik, és a fizetési műveletek végrehajtását kritikus vagy fontos funkcióként osztályozták.

Az első felülvizsgálat három gyengeséget tár fel: az éles és a helyreállítási környezet ugyanattól az identitásszolgáltatástól függ; a felügyeleti beszállító incidens-eszkalációs folyamata nem egyértelmű; a felhőből való kilépési terv pedig megnevez egy alternatív szolgáltatót anélkül, hogy bizonyítaná az adatkinyerést és a migrációt.

A vezetés három, egymáshoz kapcsolódó munkacsomagot rendel meg:

Az üzleti gazda ellenőrzi, hogy a fizetésekre vonatkozó helyreállítási célok továbbra is teljesíthetők-e. A compliance-terület ellenőrzi, hogy a bejelentési eljárások és a nyilvántartási bejegyzések tükrözik-e a megállapodásokat. A vezetés jóváhagyja a szükséges finanszírozást, és felülvizsgálja a fennmaradó korlátokat.

Ez a példa önmagában nem bizonyítja a megfelelést. Azt mutatja meg, hogyan tárhat fel egyetlen funkció olyan döntéseket, amelyek a különálló szabályzati, beszállítói és tesztelési ellenőrzőlistákban rejtve maradnának.

Alakítson ki bizonyítékalapú felülvizsgálati ritmust

A DORA-ban nincs olyan általános tanúsítási eljárás, amely a folyamatos kötelezettségeket kiváltaná. A független bizonyosságnyújtás tájékoztathatja a vezetést, de a felkészültséget működő kontrollokkal, nyilvántartásokkal és szükség esetén a felügyelettel való együttműködéssel kell igazolni.

Gyakorlati következő lépésként válasszon ki egy kritikus vagy fontos funkciót, és állítsa össze a hatályra vonatkozó döntését, a függőségi térképét, a kockázatértékelését, a szerződéseit, az incidenskezelési eljárásait, a teszteredményeit és a nyitott intézkedéseit. Vizsgálja meg, hogy ezek a nyilvántartások következetes képet adnak-e.

A Secani ezt a munkafolyamatot azzal támogatja, hogy modellezi a rendszereket és a szolgáltatásokat, összekapcsolja a függőségeket, és kontextusban tartja a követelményeket, a bizonyítékokat, a felelősöket, a feladatokat és a felülvizsgálati döntéseket. Töltse fel a meglévő anyagokat a releváns objektumokhoz, alakítsa a hiányosságokat kiosztott feladatokká, és az MI-támogatott javaslatoknál és következtetéseknél őrizze meg a kifejezett emberi jóváhagyást.

Ha a felelősségi és bizonyítéki útvonalak egyértelművé váltak, bővítsen az első funkcióból kiindulva. A vezetésnek látnia kell, mit bizonyítottak, mi marad bizonytalan, és melyik döntésre van szükség következőként.