VisszaA DORA nem egy újabb compliance-projekt, hanem a pénzügyi szektor új működési minimuma: a bankoknak, biztosítóknak és pénzügyi szolgáltatóknak bizonyítaniuk kell, hogy egy kibertámadás vagy technológiai hiba esetén is képesek helyreállni és működni.
A DORA nem egy újabb compliance-projekt, hanem a pénzügyi szektor új működési minimuma. A bankoknak, biztosítóknak és pénzügyi szolgáltatóknak ma már nem elég „jó IT-biztonságot” fenntartaniuk — bizonyítaniuk kell, hogy egy kibertámadás vagy technológiai hiba esetén is képesek helyreállni, működni és szolgáltatni. Ez a gyakorlatban azt jelenti, hogy a digitális ellenállóképesség többé nem egy papíron létező fogalom, hanem napi működési követelmény. A DORA-megfeleléshez pedig olyan működési fegyelem kell, amelyet sok szervezet csak külső támogatással tud fenntarthatóan biztosítani.
A DORA (Digital Operational Resilience Act) az EU 2025. január 17-től kötelezően alkalmazandó rendelete, amely a pénzügyi szektor digitális ellenállóképességét szabályozza. A célja, hogy egységes, kötelező és auditálható keretrendszert teremtsen az ICT- (Information and Communication Technology) kockázatok kezelésére. Ez azért kritikus, mert a pénzügyi szektor ma már teljes mértékben digitális infrastruktúrára épül, ezért akár egyetlen technológiai hiba vagy támadás is rendszerszintű fennakadást okozhat. A DORA ezt a kockázatot hivatott csökkenteni.
A DORA minden EU-s pénzügyi entitásra vonatkozik, többek között:
A DORA tehát nem csak a pénzügyi intézményeket, hanem az egész ökoszisztémát szabályozza.
A magyarországi pénzügyi intézmények DORA-megfelelésének felügyeletét elsődlegesen a Magyar Nemzeti Bank (MNB) látja el, de a rendszer több szinten működik: a nemzeti és uniós felügyeletek (EBA, ESMA, EIOPA) együtt biztosítják a megfelelést.
A DORA megsértése komoly pénzügyi, működési és reputációs következményekkel jár. A felügyeletek már 2025-től aktívan ellenőrzik a megfelelést, és a szankciók nem jelképesek.
A nem megfelelés tehát nem csak jogi, hanem üzleti kockázat is.
A DORA öt nagy területre bontja a megfelelési követelményeket. Ezek együtt alkotják a digitális reziliencia keretrendszerét, és mindegyik folyamatos működést követel meg, nem egyszeri projektet.
Fel kell mérni és folyamatosan értékelni a kritikus rendszerek kockázatait, dokumentált és auditálható folyamatok mentén.
A súlyos incidenseket osztályozni, sürgősen bejelenteni, és részletes zárójelentésben dokumentálni kell.
Rendszeres rezilienciatesztek, háromévente kötelező TLPT és valós támadás-szimulációk igazolják a védelem hatékonyságát.
A cloud- és egyéb ICT-beszállítók kockázatáért is a pénzügyi szervezet felel — szerződéses és láncbeli átláthatóság szükséges.
Naprakész fenyegetési információk és iparági szintű adatmegosztás erősítik a szektor közös ellenállóképességét.
A felkészülés négy fő lépésből áll, és mindegyik kritikus a megfeleléshez.
Gap-analízis — A szervezetnek fel kell mérnie, hol áll most a DORA követelményeihez képest. Ez a lépés adja meg a teljes projekt irányát és prioritásait.
Kockázatkezelési és incidenskezelési folyamatok kialakítása — A DORA nem csak dokumentációt, hanem működő folyamatokat vár el. A szerepkörök és felelősségek kijelölése itt kulcsfontosságú.
Technológiai megoldások bevezetése — SIEM, SOAR, EDR, CTI — ezek nélkül nem lehet valós idejű rezilienciát fenntartani. A technológia biztosítja a gyors reagálást és az auditálhatóságot.
Folyamatos működés biztosítása — A DORA-megfelelés nem projekt, hanem működési modell. A 7/24-es felügyelet és a rendszeres tesztelés elengedhetetlen.
A SOC (Security Operations Center) működése szinte tökéletesen leképezi a DORA által előírt kontrollokat. A SOCaaS modell pedig lehetővé teszi, hogy a pénzügyi szervezetek a megfelelést folyamatos működésként biztosítsák, nem egyszeri projektként.
A DORA a pénzügyi szektor új működési alapja. A megfelelés nem opcionális, és nem egyszeri projekt — folyamatos működési rezilienciat követel meg. A bankok és biztosítók számára a legnagyobb kihívás nem a szabályok megértése, hanem a 7/24-es, auditálható, technológia-intenzív működés fenntartása.
Ezt a működést egy SOC képes a legköltséghatékonyabban biztosítani:
A kérdés tehát nem az, hogy kell-e SOC, hanem az, hogy: belső SOC vagy SOC mint szolgáltatás?
