A DORA rendelet 2025. január 17. óta kötelező az EU bankjainak, biztosítóinak és más pénzügyi szolgáltatóinak, és egy dolgot nagyon világossá tesz: a felelősséget nem lehet kiszervezni. Ha egy külső IT-szolgáltató kiesik, a pénzügyi szolgáltató felel azért, hogy a működése folytatódjon. A legtöbb munkát a beszállítói kapcsolatok adják: nyilvántartás minden IT-szerződésről, kockázatelemzés még aláírás előtt, kötelező szerződési pontok, és a kritikus funkcióknál tesztelt kilépési terv. Ebben a cikkben megmutatom, mit jelent ez a gyakorlatban, mit kérj a beszállítóidtól, és hol csúszik el leggyakrabban.
Röviden
- A DORA (Digital Operational Resilience Act) az (EU) 2022/2554 rendelet. 2023. január 16-án lépett hatályba, és két év felkészülési idő után 2025. január 17. óta alkalmazandó.
- A külső IT-szolgáltatókra a 28–30. cikk vonatkozik: nyilvántartás, előzetes kockázatelemzés, kötelező szerződési pontok, kilépési stratégia.
- A kritikus vagy fontos funkciókat támogató szolgáltatásoknál a kilépési tervnek dokumentáltnak, teszteltnek és rendszeresen felülvizsgáltnak kell lennie.
- A rendelet a beszállítók méretétől függetlenül érvényes: a nagy felhőszolgáltatóra és a kis fejlesztőcégre is.
- A leggyakoribb hiba, hogy a DORA-felkészülést jogi feladatnak tekintik. A kilépési terv valójában tudásátadási és kapacitáskérdés.
Volt CIO-ként azt látom, hogy sok helyen a compliance-osztály átnézi a szerződéseket, beírja a kötelező pontokat, és ezzel lezártnak tekintik a témát. A rendelet viszont nem papírt kér, hanem azt, hogy egy beszállító kiesése után is tovább tudj működni. Ezt pedig nem a szerződés, hanem az IT-szervezet tudja garantálni.
Mit vár el a DORA rendelet a külső IT-szolgáltatóktól?
A DORA öt területet szabályoz: az IKT-kockázatkezelést, az IKT-incidensek kezelését és jelentését, a digitális működési ellenállóképesség tesztelését, a harmadik féltől eredő IKT-kockázat kezelését és az információmegosztást. A legtöbb gyakorlati változást a harmadik felekről szóló rész hozza, mert ez minden IT-beszállítói szerződést érint, a nagy felhőszolgáltatótól a kétfős fejlesztőcégig.
Az alapelv egyszerű: a pénzügyi szolgáltató akkor is teljes mértékben felel a rendelet betartásáért, ha egy feladatot külső cég végez. A beszállító átveheti a munkát, a felelősséget nem.
Négy kötelezettség, ami minden beszállítói kapcsolatot érint
1. Nyilvántartás minden IT-szerződésről. A 28. cikk (3) bekezdése szerint a pénzügyi szolgáltatónak információs nyilvántartást kell vezetnie az IKT-szolgáltatásokra kötött összes szerződéséről, és ezt naprakészen kell tartania. A felügyeletnek legalább évente jelentenie kell az új szerződések számáról és jellegéről, a kritikus vagy fontos funkciókat támogató tervezett szerződésekről pedig időben tájékoztatnia kell. Sok cégnél ez az első igazi leltár: ekkor derül ki, hány kisebb szerződés, licenc és „ideiglenes” megoldás fut a háttérben.
2. Kockázatelemzés még aláírás előtt. A 28. cikk (4) bekezdése alapján a szerződéskötés előtt fel kell mérni, hogy a szolgáltatás kritikus vagy fontos funkciót támogat-e, milyen kockázatokkal jár (beleértve a koncentrációs kockázatot), át kell világítani a leendő szolgáltatót, és azonosítani kell az esetleges összeférhetetlenséget. Ezt nem lehet utólag pótolni, a beszerzési folyamat része kell legyen.
3. Kötelező szerződési pontok. A 30. cikk minden IKT-szerződésre előír egy alapcsomagot: a szolgáltatás pontos leírását és azt, hogy megengedett-e az alvállalkozó bevonása, a szolgáltatás és az adatkezelés helyszíneit, az adatok védelmét és visszaadását a szerződés megszűnésekor, a segítségnyújtást IKT-incidensek esetén, az együttműködést a hatóságokkal, a felmondási jogokat és a biztonsági tudatossági képzéseken való részvételt. Kritikus vagy fontos funkcióknál ennél több kell: számszerű szolgáltatási szintek (SLA), felmondási idők és jelentési kötelezettségek, tesztelt üzletmenet-folytonossági terv, részvétel a fenyegetésalapú penetrációs tesztekben (TLPT), korlátlan hozzáférési és audit-jog, valamint kilépési stratégia kötelező átállási időszakkal.
4. Tesztelt kilépési terv. A 28. cikk (8) bekezdése szerint a kritikus vagy fontos funkciókat támogató szolgáltatásokhoz kilépési stratégia kell, a kilépési terveknek pedig átfogónak, dokumentáltnak, megfelelően teszteltnek és rendszeresen felülvizsgáltnak kell lenniük. Erről az IT contractor vagy saját fejlesztő cikkben már írtam röviden. Itt azt nézzük meg, miért ez a legnehezebb rész.
A tipikus hiba – a kilépési terv, ami csak papíron létezik
A legtöbb kilépési terv valahogy így szól: „szerződésbontás esetén a szolgáltató hat hónapig támogatja az átállást, és átadja a dokumentációt”. Ez szerződési pont, nem kilépési terv.
Egy valódi kilépési terv három kérdésre ad választ:
- Ki veszi át a munkát? Másik szolgáltató, saját csapat, vagy a rendszer kivezetése? Van-e erre ma kapacitás és tudás a házon belül?
- Mit kell átadni? Forráskódot, üzemeltetési leírást, hozzáféréseket, adatokat, és ami a legtöbbször hiányzik: a fejekben lévő tudást arról, miért működik a rendszer úgy, ahogy.
- Mennyi idő alatt? Reálisan, nem a szerződésben szereplő számmal. Ha egy core rendszerhez közeli alkalmazást egyetlen beszállító ismer, a hat hónapos átállás gyakran kevés.
A „tesztelt” szó itt a lényeg. Tesztelés alatt nem azt értem, hogy a tervet valaki újraolvassa. Legalább egy asztali gyakorlat kell, ahol végigveszitek, ki mit csinálna holnap reggel, ha a beszállító megszűnne. Ilyenkor szokott kiderülni, hogy a hozzáférések egy része a beszállító nevén van, vagy hogy a dokumentáció két verzióval le van maradva.
CIO-ként a legnagyobb kockázatot nem a nagy, ismert szolgáltatókban láttam, hanem a régi, egyedileg fejlesztett rendszerekben, amelyeket évek óta ugyanaz a kis csapat tart életben. Ott a kilépési terv valójában tudásátadási projekt, amit nem a felmondáskor kell elkezdeni. A legacy rendszerek dilemmáiról itt írtam részletesebben: mikor NE modernizáld a legacy rendszered.
Koncentrációs kockázat: amikor mindenki ugyanarra a szolgáltatóra épít
A DORA arra is figyel, ha egy pénzügyi szolgáltató túlzottan egyetlen beszállítóra támaszkodik, vagy ha az egész szektor ugyanazokra a szolgáltatókra épül. Ezért vezette be a kritikus harmadik fél IKT-szolgáltatók (CTPP) uniós felügyeletét. Az európai felügyeleti hatóságok által kijelölt szolgáltatók listája 19 céget tartalmaz, köztük az AWS, a Google Cloud, a Microsoft, az Oracle, az SAP és az IBM európai egységeit (EBA: DORA oversight).
Ez nem veszi le a terhet a pénzügyi szolgáltatóról. Attól, hogy a felhőszolgáltatódat uniós szinten felügyelik, a saját kilépési tervedet és a saját koncentrációs kockázatodat neked kell kezelned.
Mit kérj a beszállítóidtól?
A DORA a pénzügyi szolgáltatót kötelezi, de a teljesítéshez a beszállítóra is szükség van. Egy felkészült IT-beszállító ezeket elfogadja, és meg is tudja adni:
- a szolgáltatás és az adatkezelés helyszíneinek pontos listáját, és előzetes értesítést, ha ezek változnak;
- az alvállalkozók listáját, ha kritikus funkciót támogató szolgáltatásban vesznek részt;
- incidens esetén azonnali értesítést és segítséget, előre rögzített feltételekkel;
- hozzáférési és audit-jogot neked, az általad megbízott auditornak és a felügyeletnek;
- naprakész, átadható dokumentációt: architektúra, üzemeltetési leírás, hozzáférések listája;
- részvételt az üzletmenet-folytonossági és kilépési tesztekben, valamint a biztonsági képzésekben;
- vállalt, megfelelő átállási időszakot, amely alatt a szolgáltatás változatlanul működik.
Ha egy beszállító ezek közül többet is vonakodva fogad, az önmagában fontos információ a kockázatelemzéshez.
Döntési keretrendszer: mennyi munka kell egy beszállítónál?
| Kérdés | Ha igen | Ha nem |
|---|---|---|
| Kritikus vagy fontos funkciót támogat? | A 30. cikk (3) teljes csomagja: SLA, audit-jog, tesztelt kilépési terv | A 30. cikk (2) alap szerződési pontjai |
| Egyetlen beszállító ismeri a rendszert? | Tudásátadási terv most, nem felmondáskor | Elég a dokumentált átadási folyamat |
| Alvállalkozót is bevon kritikus funkciónál? | Az alvállalkozói láncot is fel kell mérni és nyilvántartani | – |
| Több kritikus szolgáltatás ugyanannál a szolgáltatónál? | A koncentrációs kockázat elemzése, alternatíva felmérése | – |
Hol kezdd? És mikor ne a szerződésekkel?
Ha még nincs naprakész lista arról, mely üzleti funkciók kritikusak vagy fontosak, a szerződések átírása korai. Fordított sorrendben a cég vagy minden szerződést kritikusként kezel és megfullad az adminisztrációban, vagy éppen a fontos kapcsolatok maradnak ki. A sorrend, ami bevált:
- Sorold be az üzleti funkciókat: melyik kritikus vagy fontos.
- Rendeld hozzájuk a rendszereket és a mögöttük álló beszállítókat.
- Töltsd fel a nyilvántartást, és nézd meg, hol van koncentráció.
- A kritikus kapcsolatoknál pótold a hiányzó szerződési pontokat.
- Írd meg és teszteld a kilépési terveket, kezdve azzal, ahol a legkevesebb a belső tudás.
Amit a FrontX-nél másképp csinálunk
- Mindkét oldalt ismerjük. Csapatunk tagjai pénzügyi szolgáltatóknál dolgoztak megrendelői oldalon, ma pedig beszállítóként dolgozunk pénzügyi szolgáltatóknak. Tudjuk, mit kell a beszállítónak megadnia ahhoz, hogy a megrendelő DORA-megfelelése ne csak papíron létezzen.
- A dokumentáció és a tudásátadás a munka része. Nem a szerződés végén, extra feladatként készül, hanem a szállítással együtt.
- Átlátható csapatot adunk. Az IT csapatkiterjesztés és contracting szolgáltatásunkban név szerint tudod, ki dolgozik a rendszereden, és a belső csapatod tanul tőlük.
- A régi rendszereknél a tudás feltárásával kezdünk. A legacy modernizáció és support szolgáltatásunk első lépése a rendszer felmérése és dokumentálása, hogy a működése ne egy-két ember fejében legyen.
Ha szeretnéd átnézni, mennyire valós a kilépési terved egy kritikus beszállítónál, szívesen segítünk feltérképezni, hol a legnagyobb a kockázat: kérj ingyenes konzultációt.
Gyakran ismételt kérdések
Kire vonatkozik a DORA rendelet?
Az EU pénzügyi szolgáltatóira, köztük a bankokra, biztosítókra, befektetési vállalkozásokra, pénzforgalmi és elektronikuspénz-kibocsátó intézményekre. A mikrovállalkozásokra és néhány kisebb szereplőre egyszerűsített szabályok vonatkoznak. A külső IT-szolgáltatókat a rendelet a szerződéseken keresztül érinti, a kijelölt kritikus szolgáltatók emellett közvetlen uniós felügyelet alá kerülnek.
Mióta kötelező a DORA?
2023. január 16-án lépett hatályba, és 2025. január 17. óta alkalmazandó. Azóta a nyilvántartásnak, a szerződéseknek és a kilépési terveknek meg kell felelniük a rendeletnek.
Mi számít kritikus vagy fontos funkciónak?
Olyan funkció, amelynek kiesése vagy hibás működése jelentősen rontaná a pénzügyi szolgáltató pénzügyi teljesítményét, működésének megbízhatóságát vagy folytonosságát, illetve a szabályoknak való megfelelését. A besorolást a pénzügyi szolgáltató végzi, és ebből következik, mely beszállítói szerződésekre vonatkoznak a szigorúbb előírások.
Kis beszállítónál is kell kilépési terv?
Igen, ha a beszállító kritikus vagy fontos funkciót támogató szolgáltatást nyújt. A kilépési tervet a pénzügyi szolgáltatónak kell elkészítenie, a beszállító méretétől függetlenül. Kis beszállítóknál ez gyakran még fontosabb, mert kevesebb ember hordozza a tudást.
Mi a különbség a DORA és a NIS2 között?
A NIS2 több ágazatra vonatkozó, általános kiberbiztonsági irányelv, amelyet a tagállamok saját jogszabályban ültetnek át. A DORA a pénzügyi szektorra szabott, közvetlenül alkalmazandó rendelet. A pénzügyi szolgáltatóknál a DORA a különös szabály, így az általa szabályozott területeken elsőbbséget élvez.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 20 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil
