- A register of information a DORA 28. cikke szerinti kötelező, szabványos ICT-szerződés-nyilvántartás.
- Összekapcsolt RT-táblák (RT.01–RT.07) halmaza, relációs logikával — nem egyetlen lapos lista.
- Kulcsadat: a szolgáltató LEI-je, a szerződés-azonosító, a támogatott funkció és annak kritikussága.
- Évente (vagy kérésre) be kell küldeni a felügyeletnek — Magyarországon az MNB-nek —, előírt gépi formátumban.
- A LEI hiánya és a kulcsmezők inkonzisztenciája a leggyakoribb elakadás.
01A lényeg 30 másodpercben
A register of information (információs nyilvántartás) a DORA-rendelet 28. cikkének kötelező eszköze: minden hatálya alá tartozó pénzügyi szervezetnek egységes, szabványos formátumban kell nyilvántartania az összes ICT-szolgáltatási szerződését a harmadik fél szolgáltatókkal.
- Mi: összekapcsolt táblák (RT-sablonok) halmaza — entitások, szerződések, szolgáltatók, funkciók.
- Kulcsadat: a szolgáltató LEI-je, a szerződés-azonosító, a támogatott funkció és annak kritikussága.
- Mikor: folyamatosan naprakészen tartva, évente (vagy kérésre) beküldve a felügyeletnek — Magyarországon az MNB-nek.
- Buktató: a táblák kulcsmezőkkel kapcsolódnak (relációs logika); a beküldés gépi formátumot vár — ezt nem érdemes laza Excelben kezdeni.
02Mi a register of information?
A DORA (EU 2022/2554 rendelet) célja a pénzügyi szektor digitális működési ellenállóképességének (operational resilience) erősítése. Ennek egyik pillére, hogy a felügyelet és maga a szervezet is pontosan lássa, mely külső ICT-szolgáltatóktól és milyen mértékben függ a működése — különösen a kritikus vagy fontos funkciók terén.
Ezt szolgálja a register of information: egy strukturált nyilvántartás, amely a szervezet összes ICT-harmadikfél-szerződését rögzíti, egységes adatszerkezetben. A formátumot az európai felügyeleti hatóságok (ESA-k) végrehajtási technikai standardja (ITS) írja elő — így minden uniós pénzügyi szervezet ugyanazokat a mezőket, ugyanúgy tölti ki, és a felügyelet aggregálni tudja a szektor-szintű koncentrációs kockázatot (pl. ha túl sokan ugyanattól a felhőszolgáltatótól függenek).
A register valódi tétje, hogy a felügyelet lássa: nem függ-e túl sok pénzügyi szereplő ugyanattól a felhőszolgáltatótól.
A nyilvántartást három szinten kell vezetni: entitás, részkonszolidált és konszolidált szinten — vagyis cégcsoportnál a csoport-szintű kép is összeáll. A részletes megfelelőségi kontextust lásd a DORA bevezetési útmutatóban, az átfedő keretek (NIS2, ISO 27001) viszonyát pedig az átfedés-térképben.
03Az RT-táblák szerkezete
A nyilvántartás nem egyetlen lapos lista, hanem összekapcsolt táblák (RT-sablonok — a végleges (EU) 2024/2956 végrehajtási rendeletben B_01.01–B_99.01 kóddal) halmaza, öt logikai blokkban. A táblák kulcsmezőkkel (pl. szerződés-azonosító, LEI) hivatkoznak egymásra — relációs adatbázis-szerű logika. A blokkok relatív „adatsűrűsége" (hány kitöltendő mező-csoport tartozik hozzájuk) jó támpont, hova kell a legtöbb energia:
A blokkok röviden: RT.01.* — a nyilvántartást vezető szervezet, a hatókörbe tartozó entitások és fióktelepek. RT.02.* — a szerződéses megállapodások (általános, specifikus, csoporton belüli). RT.03.* / RT.04.* — ki írja alá és ki veszi igénybe a szolgáltatást. RT.05.* — maguk az ICT harmadik fél szolgáltatók és az alvállalkozói (ellátási) láncuk. RT.06.* / RT.07.* — a támogatott funkciók és az ICT-szolgáltatás kockázati értékelése.
04A kötelező adatmezők
A teljes mezőlista terjedelmes, de a gyakorlatban néhány kulcsadaton áll vagy bukik a kitöltés:
| Adat | Miért kritikus |
|---|---|
| LEI (Legal Entity Identifier) | A szolgáltató egyértelmű jogi azonosítója (EU-ban letelepedett szolgáltatónál LEI helyett EUID is elfogadott, harmadik országbelinél LEI kell). Gyakran hiányzik — be kell szerezni (LOU-tól). |
| Szerződés referencia-azonosító | Ez köti össze a táblákat (RT.02 ↔ RT.03/04/05). Konzisztensnek kell lennie. |
| Funkció-azonosító + kritikusság | Kritikus vagy fontos funkciót (CIF) támogat-e — ez vezérli a szigorúbb elvárásokat. |
| Adat tárolási/feldolgozási hely | Ország/régió — az adatrezidencia és a koncentráció miatt. |
| Ellátási lánc (alvállalkozók) | A negyedik fél kockázat — ki van a szolgáltatód mögött. |
| Kilépési (exit) feltételek | Felmondhatóság, átállási idő — a felhő exit-stratégia köti ide. |
Minden (jogi személy) ICT-szolgáltatónak érvényes azonosítóval — LEI-vel, EU-ban letelepedett szolgáltatónál LEI-vel vagy EUID-vel — kell szerepelnie a nyilvántartásban, és a LEI beszerzése átfutási idővel jár. Ha a szolgáltatódnak még nincs, kérd időben, mielőtt a beküldési határidő szorít.
05Kitöltés lépésről lépésre
A nyilvántartás felépítése nem egynapos feladat — de jól tagolható öt fázisra. A nagyját az adatgyűjtés teszi ki (szerződések és LEI-k összeszedése), nem maga a kitöltés:
- Hatókör & szerződés-leltár
- Adatgyűjtés(LEI, funkció)
- Táblák kitöltése
- Validáció & jóváhagyás
- Beküldés & karbantartás
Kezdheted a hivatalos ESA-sablonnal, de néhány tucat szerződés felett a kézi Excel hibázós és karbantarthatatlan. Időben válts strukturált, validálható megoldásra, ahol a kulcsmezők (LEI, szerződés-azonosító) ellenőrzöttek — így a beküldés már csak export.
06Beküldés & határidő
- Kinek: az illetékes nemzeti hatóságnak — Magyarországon a Magyar Nemzeti Banknak (MNB).
- Mikor: a nyilvántartást folyamatosan naprakészen kell tartani, és évente (illetve a felügyelet kérésére bármikor) beküldeni. A pontos határidőt és csatornát az MNB adatszolgáltatási rendje rögzíti.
- Formátum: előírt gépi adatformátum (a hatóság által megadott séma szerint). Az ESA-k 2024-ben önkéntes próbaadatgyűjtést (dry run) tartottak a formátum élesítésére.
- Tipp: mivel a beküldés gépi, a nyilvántartást kezdettől strukturáltan, validálható kulcsmezőkkel érdemes vezetni — így a beküldés export, nem újragépelés.
Ez a cikk gyakorlati, mérnöki útmutató. A pontos, hatályos mezőszerkezetet, formátumot és határidőt mindig a hatályos ESA ITS és az MNB adatszolgáltatási előírása határozza meg; megfelelőségi döntésnél egyeztess a jogi/compliance felelőssel.
07Gyakori hibák
- Hiányzó vagy hibás LEI: a leggyakoribb elakadás — minden ICT-szolgáltatónak kell egy érvényes azonosító (LEI; EU-s szolgáltatónál EUID is lehet), ezt időben be kell szerezni.
- Inkonzisztens szerződés-azonosítók: ha a kulcsmezők nem egyeznek a táblák között, a nyilvántartás nem áll össze (és a validáció elhasal).
- Hiányos ellátási lánc: a negyedik fél (alvállalkozó) kockázatát kihagyni — pedig ez kifejezett elvárás.
- Egyszeri kitöltés: a nyilvántartást élő dokumentumként kell kezelni, nem évente egyszer összecsapni.
- Túl sokáig Excelben: néhány tucat szerződés felett a kézi tábla karbantarthatatlan és hibázós — időben strukturált megoldásra kell váltani.
08GYIK
Mi a különbség a register of information és egy egyszerű szállítói lista között?
A szállítói lista szabad formájú; a register of information szabványos, gépi formátumú, összekapcsolt táblákból áll, előírt mezőkkel (LEI, funkció-kritikusság, ellátási lánc), és a felügyelet aggregálni tudja. Ez utóbbi jogi kötelezettség, az előbbi nem helyettesíti.
Honnan szerzek LEI-t a szolgáltatómnak?
A LEI-t a szolgáltató maga igényli egy LEI-kibocsátótól (LOU). Te a nyilvántartásban a meglévő LEI-jüket rögzíted — ha nincs nekik, kérned kell, hogy szerezzék be (a DORA miatt a legtöbb komoly ICT-szolgáltatónak már van).
A felhőszolgáltatóm (AWS/Azure/GCP) is bekerül?
Igen — a hyperscaler is ICT harmadik fél szolgáltató. A felhő-szerződés, a támogatott funkció, az adatrezidencia és az alvállalkozói lánc mind a nyilvántartás része. A koncentrációs kockázat miatt ez a felügyeletnek kiemelten fontos.
Kell hozzá külső segítség?
A nehézség nem a darabszám, hanem a strukturáltság és a kulcsmezők konzisztenciája. Egy felmérés + a sablon helyes felállítása + a validációs logika megtérül. Pont ezt csináljuk: banki/pénzintézeti megfelelőségi tapasztalatból, KKV-léptékre szabva.
Mi a DORA register of information (információs nyilvántartás)?
A register of information a DORA-rendelet (EU 2022/2554) 28. cikke szerinti kötelező nyilvántartás, amelyben a pénzügyi szervezetnek dokumentálnia kell az összes ICT (informatikai) szolgáltatásra vonatkozó szerződéses megállapodását a harmadik fél szolgáltatókkal. Egységes, szabványos formátumban kell vezetni — az ESA-k (európai felügyeleti hatóságok) végrehajtási technikai standardja (ITS) írja elő a táblák (RT-sablonok; a végleges (EU) 2024/2956 rendeletben B_01.01–B_99.01 kóddal) szerkezetét és a kötelező adatmezőket. A nyilvántartást entitás, részkonszolidált és konszolidált szinten is vezetni kell, és évente be kell küldeni az illetékes felügyeletnek (Magyarországon az MNB-nek).
Milyen táblákból (RT-sablonokból) áll a nyilvántartás?
A nyilvántartás összekapcsolt táblák halmaza, öt logikai blokkban: (1) a nyilvántartó és a hatókörbe tartozó entitások (RT.01.*); (2) a szerződéses megállapodások — általános és specifikus, csoporton belüli (RT.02.*); (3) a szerződést aláíró entitások és szolgáltatók (RT.03.*) és a szolgáltatást igénybe vevők (RT.04.*); (4) maguk az ICT harmadik fél szolgáltatók és az ellátási láncuk (RT.05.*); (5) a szolgáltatott funkciók és az ICT-szolgáltatás értékelése (RT.06.*, RT.07.*). A táblák kulcsmezőkkel (pl. szerződés-azonosító, LEI) kapcsolódnak egymáshoz — ez relációs adatbázis-szerű logika, nem egyetlen lapos lista.
Milyen adatok kötelezőek a nyilvántartásban?
A legfontosabbak: a szolgáltató jogi azonosítója (LEI — Legal Entity Identifier; EU-ban letelepedett szolgáltatónál EUID is elfogadott), a szerződés referencia-azonosítója, kezdő/lejárati dátum, a szolgáltatás típusa, a támogatott üzleti funkció és annak kritikussága (kritikus vagy fontos funkciót támogat-e — CIF), az adat tárolási és feldolgozási helye (ország/régió), a kiszervezés szintje, az alvállalkozói (ellátási lánc) lánc, valamint a kilépési (exit) lehetőségre és a felmondási feltételekre vonatkozó adatok. A LEI hiánya a leggyakoribb elakadás — a harmadik országbeli ICT-szolgáltatóknak LEI kell, ha még nincs, igényelniük kell.
Mikor és kinek kell beküldeni a nyilvántartást?
A nyilvántartást folyamatosan naprakészen kell tartani, és évente (illetve a felügyelet kérésére bármikor) be kell küldeni az illetékes nemzeti hatóságnak — Magyarországon a Magyar Nemzeti Banknak (MNB). Az ESA-k 2024-ben önkéntes próbaadatgyűjtést (dry run) is végeztek a formátum élesítésére. A pontos beküldési határidőt és csatornát a felügyelet adatszolgáltatási rendje határozza meg; az adatot az előírt gépi formátumban (a hatóság által megadott séma szerint) kell szolgáltatni, ezért érdemes a nyilvántartást kezdettől gépiesen, strukturáltan vezetni.
Kis pénzügyi cégnek (KKV) is kell ilyen nyilvántartás?
Igen, ha a DORA hatálya alá tartozik — a rendelet a pénzügyi szervezetek széles körére vonatkozik (bankok, befektetési vállalkozások, pénzforgalmi és e-pénz intézmények, kriptoeszköz-szolgáltatók, biztosítók stb.), méretkorláttól nagyrészt függetlenül. A mikrovállalkozásokra egyes követelmények arányosan, enyhébben alkalmazandók, de a nyilvántartás-vezetési kötelezettség alól ez nem mentesít. KKV-méretben a kihívás nem a darabszám, hanem a strukturáltság: a szerződések és LEI-k összegyűjtése, és a táblák közti kapcsolatok helyes kitöltése. Pont itt segít a banki tapasztalatból hozott, de KKV-léptékre szabott módszertan.
Excel-ben is vezethetem, vagy kell hozzá rendszer?
Kis szerződés-számnál az ESA-k által közzétett sablon (táblázatos formátum) elegendő lehet a kezdéshez, de figyelni kell: a táblák kulcsmezőkkel kapcsolódnak (relációs logika), és a beküldés gépi formátumot vár. Néhány tucat szerződés felett a kézi Excel hibázós és karbantarthatatlan — érdemes egy egyszerű strukturált megoldásra váltani (adatbázis vagy GRC-eszköz), amely validálja a kulcsokat és exportálja a beküldési formátumot. A józan KKV-út: kezdj a hivatalos sablonnal, de tervezd a strukturált vezetést, mielőtt elszaporodnak a szerződések.
09Konzultáció
Ha DORA-hatály alá esel, és a register of information felállítása vagy felülvizsgálata előtt állsz, egy felmérés a szerződéseid és szolgáltatóid alapján gyorsan láthatóvá teszi a hiányokat (LEI, kritikusság, ellátási lánc). Egy 30 perces ingyenes konzultáció után konkrét sablon-struktúrát és kitöltési tervet adunk.
A megfelelőségi és architektúra-hátteret az Enterprise Architecture, a kockázat-leképezést pedig a DR-tervezés és az IT-infrastruktúra oldalainkkal kötjük össze — banki tapasztalatból, KKV-méretre szabva.
DORA megfelelőség — gyakorlati bevezetés · NIS2 + DORA + ISO 27001 átfedés · Felhő exit-stratégia