A DORA (Digital Operational Resilience Act, EU 2022/2554 rendelet) 2025. január 17-től hatályos és közvetlenül alkalmazandó nemzeti átültetés nélkül. Az EU-ban körülbelül 22 000 pénzügyi szervezetre vonatkozik — bankokra, biztosítókra, befektetési cégekre, kriptoplatformokra, fizetési intézményekre — és alapvetően az ICT harmadik fél szolgáltatókra is, beleértve a SaaS ERP/CRM szolgáltatókat. A DORA öt pillére lefedi az ICT kockázatmenedzsmentet, incidensjelentést, reziliencia-tesztelést, harmadik fél kockázatát és az információmegosztást. A szankciók a jogsértés időtartamára az éves napi forgalom 1%-áig terjedhetnek.

Ez a cikk a felhő ERP biztonsági és megfelelési pillérjéhez kapcsolódik. Elmagyarázza, kit érint a DORA közvetlenül, kit közvetve az ellátási láncon keresztül, és milyen konkrét követelményeknek kell megfelelnie a szabályozott pénzügyi szervezeteket kiszolgáló SaaS ERP-nek.

Miért a DORA és miben különbözik más szabályozásoktól

A DORA előtt a pénzügyi szervezetek digitális rezilienciáját széttagoltan szabályozták — EBA iránymutatások bankoknak, EIOPA biztosítóknak, ESMA befektetési cégeknek. A DORA ezt egyetlen rendeletbe egységesíti közvetlen hatállyal az egész EU-ban.

Legfontosabb újítások:

  • Közvetlen ICT harmadik fél szabályozás. Ha „kritikus” ICT szolgáltatója a pénzügyi szektornak, az EU szervek közvetlenül felügyelhetik (az új Joint Oversight Forum-on keresztül).
  • Fenyegetésvezérelt penetrációs tesztelés (TLPT). A nagy pénzügyi szervezeteknek 3 évente TLPT-t kell végezniük.
  • Szabványosított incidensjelentés harmonizált küszöbértékekkel.
  • Információnyilvántartás — kötelező nyilvántartás az összes ICT szerződéses megállapodásról.

A DORA két fő dologban különbözik a NIS2-től: szektorális (csak pénzügyi) és szigorúbb (lex specialis). Ha Ön bank, mindkét rezsim vonatkozik Önre, de a DORA elsőbbséget élvez.

Kit érint a DORA

Közvetlenül szabályozott szervezetek

A DORA a 2. cikkben több mint 20 típusú szervezetet sorol fel. Magyar vonatkozásban a legrelevánsabbak:

  • Hitelintézetek (bankok)
  • Fizetési intézmények és elektronikus pénz intézmények
  • Befektetési vállalkozások és értékpapír-kereskedők
  • Biztosítók és viszontbiztosítók
  • Alapkezelő társaságok (befektetési alapok, nyugdíjpénztárak)
  • Kriptovaluta-szolgáltatók (CASP a MiCA szerint)
  • Tőzsdék és központi értéktárak
  • Közösségi finanszírozási platformok
  • Könyvvizsgálók és tanácsadók (részben, csak jelentéstétel)

Közvetve az ellátási láncon keresztül

A DORA bevezeti az ICT harmadik fél szolgáltató koncepcióját. Ha IT-szolgáltatásokat nyújt pénzügyi szervezetnek — beleértve a SaaS ERP-t, CRM-et, felhő hostingot, e-mailt, identitásszolgáltatót, monitorozást —, az ügyfele szerződésen keresztül alkalmazza a DORA követelményeit.

Ez azt jelenti, hogy még ha Ön nem bank is, ha ügyfelei bankok/biztosítók, technológia és dokumentáció szintjén de facto DORA-kompatibilisnek kell lennie.

Kritikus ICT szolgáltatók (CTPP)

Az EU szervek (EBA, EIOPA, ESMA) évente meghatározzák a kritikus ICT harmadik fél szolgáltatók (CTPP) listáját — jellemzően a nagy felhő hyperscalerek (AWS, Azure, GCP), amelyek nagy részesedéssel rendelkeznek a pénzügyi piacon. Ezekre közvetlen európai felügyelet vonatkozik, beleértve a helyszíni vizsgálatokat és szankciókat.

Kis méretű SaaS ERP szolgáltatók esetén nem valószínű, hogy CTPP-ként sorolják be őket — azonban ügyfeleiken keresztül szabályozzák őket.

A DORA öt pillére

1. pillér: ICT kockázatmenedzsment keretrendszer

Átfogó keretrendszer az alábbi elemekkel:

  • Irányítás — igazgatósági szintű felelősség, meghatározott szerepek.
  • Azonosítás — ICT eszköznyilvántartás, függőségek feltérképezése.
  • Védelem és megelőzés — szabályzatok, technikai ellenőrzések, szegmentálás.
  • Detektálás — monitorozás, SIEM, anomáliadetektálás.
  • Reagálás és helyreállítás — incidenskezelés, BCP, DRP.
  • Tanulás és fejlődés — incidens utáni értékelések, fenyegetés-hírszerzés.

Kis pénzügyi szervezetek számára egyszerűsített keretrendszer létezik, de formalizált dokumentációt még mindig megkövetel.

2. pillér: ICT-kapcsolatos incidenskezelés

Szabványosított folyamat:

HatáridőIntézkedés
4 óra a besorolástólKezdeti értesítés az illetékes hatóságnak (MNB Magyarországon)
72 óraKözbenső jelentés
1 hónapVégső jelentés

Az incidens major besorolása olyan kritériumok alapján történik, mint az érintett ügyfelek száma, pénzügyi kár, kritikus szolgáltatások kiesése, földrajzi hatókör. Az RTS (Regulatory Technical Standards) pontosan meghatározza a küszöbértékeket.

3. pillér: Digitális operatív reziliencia tesztelése

Kétféle teszt:

  1. Szabványos tesztek (évente) — sebezhetőség-vizsgálatok, forráskód-értékelések, penetrációs tesztelés, forgatókönyv-alapú tesztelés.
  2. TLPT (Threat-Led Penetration Testing) — csak nagy szervezetek számára, 3 évente. Reális red-team támadás a TIBER-EU módszertan szerint.

A szabályozott szervezetek által igénybe vett ICT szolgáltatóknak tesztelési környezeteket kell biztosítaniuk és együtt kell működniük a tesztelésben.

4. pillér: ICT harmadik fél kockázatmenedzsment

A legnehezebb és legambiciózusabb pillér. Megköveteli:

  • Információnyilvántartás — az összes ICT megállapodás teljes listája.
  • Szerződéskötés előtti értékelés — átvilágítás a szerződéskötés előtt.
  • Szerződési követelmények — kifejezett DORA záradékok a szerződésekben.
  • Kilépési stratégiák — meghatározott terv az ICT szolgáltatóval való együttműködés befejezésére.
  • Koncentrációs kockázat monitorozása — egyetlen szolgáltatótól való függés követése.

Az ICT szolgáltatóval kötött szerződésnek a 30. cikk szerint legalább az alábbiakat kell tartalmaznia:

  • Szolgáltatások leírása és SLA
  • Adatfeldolgozási helyek (EU-nak kell lennie kritikus funkciókhoz)
  • Biztonsági szabványok
  • A szolgáltató auditálásának joga
  • Alvállalkozásba adás szabályai
  • Incidensjelentés az ügyfélnek
  • Felmondási feltételek és kilépési támogatás
  • Együttműködés felügyeleti hatóságokkal
  • Fizetésképtelenségi rendelkezések

5. pillér: Információmegosztás

Önkéntes, de támogatott — a pénzügyi szervezetek fenyegetés-hírszerzési adatokat oszthatnak meg az ISAC/ISAO közösségeken belül.

Gyakorlati ellenőrzőlista SaaS ERP szolgáltató számára, amely a pénzügyi szektort célozza

Ha ERP-t fejleszt vagy értékesít bankoknak, biztosítóknak vagy fintech cégeknek az EU-ban, íme a DORA-felkészültség ellenőrzőlistája:

A) Architektúra és infrastruktúra

  • Kizárólag EU-s hosting (kritikus funkciókhoz nem kerülhet adat az EU-n kívülre)
  • Többrégiós bevezetés automatikus failoverrel
  • RTO < 4 óra, RPO < 1 óra (kritikus pénzügyi szolgáltatásoknál)
  • Air-gapped biztonsági mentések (nem módosítható, ransomware-ellenálló)
  • Hálózati szegmentálás (éles vs. staging vs. management)
  • Titkosítás tároláskor és átvitel közben (AES-256, TLS 1.3)
  • Hardware Security Modules (HSM) kulcskezeléshez
  • Privileged Access Management (PAM) admin fiókokhoz

B) Alkalmazásbiztonság

  • Kötelező MFA az összes felhasználónak
  • SSO-támogatás (SAML 2.0, OIDC)
  • Szerepkör-alapú hozzáférés-vezérlés részletes jogosultságokkal
  • Munkamenet-kezelés (időtúllépés, újrahitelesítés érzékeny műveletekhez)
  • Bemeneti ellenőrzés és kimeneti kódolás (OWASP Top 10)
  • API biztonság (sebességkorlátozás, OAuth 2.0, API kulcsrotáció)
  • Sebezhetőség-vizsgálat a CI/CD pipeline-ban
  • Forráskód-értékelés rendszeresen

C) Monitorozás és incidenskezelés

  • SIEM integráció (naplók exportálhatósága az ügyfél számára)
  • Audit napló az összes változáshoz (nem módosítható, min. 12 hónapos megőrzés)
  • Valós idejű anomáliadetektálás
  • 24/7 incidenskezelési csapat (vagy SLA külső szolgáltatással)
  • Incidensértesítés az ügyfél felé 4 órán belül
  • Forenzikus képesség az incidens utáni elemzéshez

D) Dokumentáció és tanúsítványok

  • ISO 27001 tanúsítvány (minimum)
  • SOC 2 Type II (ideálisan USA/nemzetközi kontextushoz)
  • Penetrációs teszt jelentés (évente, külső)
  • DPA a GDPR 28. cikke szerint
  • DORA-kompatibilis szerződéssablonok a 30. cikk záradékaival
  • Alprojcesszor lista előzetes jóváhagyási folyamattal
  • BCP és DRP dokumentáció (megosztva az ügyféllel)
  • Rendszeres DR teszt (min. 2-szer évente, dokumentált)

E) Ügyfél és felügyeleti hatóság együttműködés

  • Az ügyfél auditálási joga (szerződésben rögzítve)
  • TLPT együttműködés — tesztelési környezetek, red-team együttműködés
  • Kilépési támogatás — adatexport, tudástranszfer (meghatározott SLA)
  • Felügyeleti hatóságokkal való együttműködés — felkészültség az EBA/ESMA közvetlen kéréseire
  • Fizetésképtelenségi rendelkezések — a szolgáltatás folytonossága a szolgáltató fizetésképtelensége esetén

Modulario és DORA

A Modulario elsősorban nem szabályozott pénzügyi szervezetek számára (bankok, biztosítók) készült — fókuszban a nem-pénzügyi szektorok KKV-i állnak (gyártás, szolgáltatások, kiskereskedelem, szállítás, építőipar). Azonban a fintech, fizetési szolgáltatások és befektetési tanácsadás szegmensében olyan bevezetéseket is biztosítunk, amelyeknek DORA-kompatibilisnek kell lenniük.

DORA-releváns képességeink:

  • Kizárólag EU-s hosting (Frankfurt + Prága, többrégiós)
  • ISO 27001 tanúsítvány 2024 óta
  • Audit napló minden modulban
  • Szabványosított DPA + nyilvános alprojcesszor lista
  • MFA / SSO támogatás (TOTP, WebAuthn, SAML, OIDC)
  • API biztonság OAuth 2.0-val és sebességkorlátozással
  • BCP/DRP RTO < 8 óra és RPO < 1 óra (standard bevezetéseknél; DORA-kritikus bevezetéseknél rövidebb SLA kérésre)
  • Kilépési támogatás — teljes adatexport standard formátumokban (CSV, JSON, API)

Szabályozott szervezetek számára DORA-kompatibilis szerződéssablonokat és specifikus SLA-kat biztosítunk. Részletesen a Biztonság oldalon és a felhő ERP biztonsági pillér cikkben.

Szankciók és személyes felelősség

A DORA nem határoz meg fix maximumot egy összegben (a GDPR-ral ellentétben), de a felügyeleti hatóságoknak jogot ad a következők alkalmazására:

  • Ismétlődő szankciós kifizetések — legfeljebb a globális napi forgalom 1%-a a jogsértés időtartamára (max. 6 hónap).
  • Közigazgatási szankciók a nemzeti jogszabályok szerint.
  • Nyilvános figyelmeztetések — nyilvános megjelölés.
  • Engedély visszavonása — kritikus jogsértések esetén.

Kritikus ICT harmadik fél szolgáltatók (CTPP) esetén az ESA közvetlenül napi forgalom 1%-ára vonatkozó ismétlődő szankciókat szabhat ki, nemzeti felügyeleti hatóság közvetítése nélkül.

Személyes felelősség: a felsővezetőség végső felelősséget visel a DORA-megfelelésért. Ez Magyarországon a hitelintézeti törvénynek és hasonló jogszabályoknak megfelelően a társaság vezető tisztségviselőjét jelenti.

DORA, NIS2 és GDPR kapcsolata

SzempontDORANIS2GDPR
TípusRendeletIrányelvRendelet
SzektorPénzügyi18 szektorMinden
Lex specialisIgen (pénzügyinél)NemNem
Közvetlen hatályIgenNem (átültetés)Igen
ICT harmadik félKözvetlen felügyeletEllátási láncon keresztülDPA-n keresztül
Jelentési határidők4ó / 72ó / 1 hó24ó / 72ó / 1 hó72 óra
Maximális szankciókNapi forgalom 1%-a10 millió EUR / 2%20 millió EUR / 4%

Az EU-ban egy bank mindháromnak egyszerre van alávetve. A DORA az IT operációkhoz elsődleges, a NIS2 a szélesebb kiberbiztonsági keretrendszerhez, a GDPR az ügyfelek személyes adataihoz.

Gyakran ismételt kérdések

Kis fintech cégünk van 8 alkalmazottal és fizetési szolgáltatásokat nyújtunk. Vonatkozik ránk a DORA? Igen. A DORA nem küszöböl méret szerint olyan szigorúan, mint a NIS2. A fizetési intézmény kifejezetten szerepel a 2. cikkben. Kis szervezetek számára egyszerűsített keretrendszer (arányosság) létezik, de az alapvető követelmények érvényesek. Tervezzen minimálisan 2–4 hónap megfelelési munkával.

Az ERP szolgáltatónk nem DORA-kompatibilis. Használhatjuk-e? Nem kritikus funkcióknál igen, kritikusaknál nem. A DORA megköveteli, hogy az ICT funkciókat kritikusság szerint osztályozza, és kritikus funkciókhoz csak DORA-követelményeknek megfelelő szolgáltatókat használjon. Ha az ERP például core banking adatokat vagy valós idejű fizetési feldolgozást tartalmaz, DORA-kompatibilisnek kell lennie.

Mi a különbség a DORA és a TIBER-EU között? A TIBER-EU az EKB által kidolgozott fenyegetésvezérelt penetrációs tesztelési keretrendszer, amelyet a DORA előtt önkéntesen alkalmaztak. A DORA TLPT (26. cikk) átvette referencia-módszertanként és kötelezővé tette a nagy pénzügyi szervezetek számára. Az MNB a TIBER-HU változatot alkalmazza.

Milyen gyakran kell frissíteni az ICT szerződések nyilvántartását? A Register of Information (RoI) nyilvántartást folyamatosan kell frissíteni (minden szerződésmódosításnál) és legalább évente kell jelenteni a nemzeti felügyeleti hatóságnak szabványosított formátumban. Az RTS a pontos formátumot határozza meg (XBRL).