DORA szerinti incidensjelentés és ISO 27001 kontrollok 2026-ban

2026 egyik kedd reggelén 08:17 van. Sarah, egy európai FinTech információbiztonsági vezetője, sárgán — nem pirosan — villogó irányítópultot lát. Egy kritikus fizetéselszámolási platform lassul. A tranzakciók nem állnak le teljesen, de háromszor tovább tartanak, mint amit a szolgáltatási szint megállapodás megenged. A SOC szokatlan hitelesítési kísérleteket észlel egy adminisztrátori fiókkal szemben. A felhőinfrastruktúra-szolgáltató csökkent szolgáltatási szintet jelent az egyik rendelkezésre állási zónában. Az ügyféltámogatásnál vállalati ügyfelek kezdenek érdeklődni, miért késnek a fizetési fájlok.
Még senki sem tudja, hogy kibertámadásról, digitális működési reziliencia hibájáról, beszállítói kiesésről, adatvédelmi incidensről vagy mindezek együtteséről van-e szó.
Sarah-nak már azelőtt DORA-problémája van, hogy a műszaki tények teljesek lennének. Jelentős IKT-vonatkozású incidensről van szó? Érint kritikus vagy fontos funkciót? Átlépte a belső súlyossági küszöbértéket? Kit kell értesíteni, mikor és milyen bizonyítékokkal? Ha személyes adatok érintettek, elindult-e a GDPR szerinti bejelentési határidő is? Ha egy harmadik fél IKT-szolgáltató is része az incidensláncnak, ki felel a tényekért?
Itt derül ki a pénzügyi szervezetek számára a különbség aközött, hogy rendelkeznek incidensreagálási tervvel, illetve aközött, hogy auditálható DORA incidensjelentési működési modelljük van.
A DORA szerinti incidensjelentés 2026-ban többet igényel a gyors eszkalációnál. Igazolható láncot követel az észleléstől az osztályozásig, az osztályozástól a felügyeleti jelentéstételig, a jelentéstételtől a helyesbítő intézkedésekig, majd onnan a tanulságok levonásáig. Az ISO/IEC 27001:2022 biztosítja az irányítási rendszer szerkezetét. Az ISO/IEC 27002:2022 kontrollleírásai adják a gyakorlati kontrollelvárásokat. A Clarysec szabályzatai, 30 lépéses ütemterve és keresztmegfelelési útmutatója ezeket az elvárásokat bizonyítékkész bevezetéssé alakítják.
Miért bukik el a DORA szerinti incidensjelentés nyomás alatt
A DORA szerinti incidensjelentési hibák többsége nem gondatlansággal kezdődik. Hanem kétértelműséggel.
Egy biztonsági elemző lát egy riasztást, de nem tudja, hogy az DORA szerinti IKT-vonatkozású incidensnek minősül-e. Az IT-szolgáltatásmenedzser a csökkent teljesítményt műszaki szolgáltatási problémaként kezeli, miközben a megfelelési funkció szabályozói eseményként tekint rá. A jogi terület megerősítésre vár az eszkaláció előtt. Az üzleti folyamatgazda még nem tudja számszerűsíteni az ügyfélhatást. Az információbiztonsági vezető bizonyítékokat kér, de a releváns naplók felhőszolgáltatásokban, végpontokon, identitásrendszerekben, a SIEM-ben és beszállítói platformokon szétszórva találhatók.
Mire a szervezet megállapodik az osztályozásban, a jelentéstételi határidő már nyomás alá kerül.
A DORA Article 17–21 strukturált elvárást határoz meg az IKT-vonatkozású incidensek kezelésére, osztályozására, jelentésére, a jelentés tartalmára és felügyeleti kezelésére. A pénzügyi szervezetek gyakorlati követelménye egyértelmű: az IKT-vonatkozású incidenseket úgy kell monitorozni, kezelni, naplózni, osztályozni, jelenteni, frissíteni és azokból tanulni, hogy az eseménysor később rekonstruálható legyen.
A Clarysec Incidenskezelési szabályzata [IRP] közvetlenül beépíti a DORA-t a hivatkozási keretrendszerbe:
EU DORA (2022/2554): Article 17: IKT-incidensek jelentéstételi követelményei pénzügyi intézmények számára az illetékes hatóságok felé.
Ugyanez a szabályzat az incidenskezelést az ISO/IEC 27002:2022 5.25–5.27 kontrolljaihoz kapcsolja, lefedve az incidensek értékelésével, kezelésével, kommunikációjával és fejlesztésével kapcsolatos felelősségeket.
Kisebb pénzügyi technológiai vállalkozások és karcsú szabályozott szervezetek számára a Clarysec Incidenskezelési szabályzat - SME [IRP-SME] gyakorlativá teszi a kötelezettséget azzal, hogy kiemeli: a DORA előírja a pénzügyi szervezetek számára az IKT-vonatkozású incidensek és zavarok osztályozását, jelentését és nyomon követését.
Ez a megfogalmazás lényeges. A DORA-megfelelés nem csupán jelentési sablon. A szervezetnek osztályoznia, jelentenie és nyomon kell követnie az incidenseket. Ez bizonyítékot jelent az eredeti eseményről, a döntési kritériumokról, a súlyossági szintről, a jelentéstételi döntésről, a kommunikációról, a helyreállítási intézkedésekről, a beszállítói érintettségről és az utókövetésről.
Az ISO/IEC 27001:2022 mint a DORA szerinti incidenskezelés irányítási központja
Egy érett ISO/IEC 27001:2022 információbiztonság-irányítási rendszer (IBIR) nem válhat a DORA mellett egy újabb megfelelési silóvá. A DORA szerinti incidensjelentés irányítási központjává kell válnia.
Az IBIR már megköveteli a kockázattulajdonosi felelősséget, a kontrollkiválasztást, a belső auditot, a vezetőségi felülvizsgálatot, a dokumentált információkat, a folyamatos fejlesztést és a kontrollműködés bizonyítékait. A DORA ágazatspecifikus jelentéstételi nyomást ad hozzá, de az ISO/IEC 27001:2022 biztosítja azt az irányítási struktúrát, amely a folyamatot megismételhetővé teszi.
A Clarysec Zenith Blueprint: auditori 30 lépéses ütemterv [ZB] a 13. lépésben — kockázatkezelési tervezés és alkalmazhatósági nyilatkozat — erősíti ezt az integrációt. A Blueprint a kontrollok kockázatokhoz és követelményekhez rendelését javasolja a visszakövethetőség érdekében, beleértve az A melléklet szerinti kontrollhivatkozás hozzáadását a kockázatokhoz, valamint annak jelölését, ha a kontrollok GDPR, NIS2 vagy DORA követelményeket támogatnak.
Sarah fizetéselszámolási incidensénél a kockázati nyilvántartás bejegyzése például ez lehet:
„A fizetésfeldolgozási platform zavara vagy kompromittálódása.”
A hozzárendelt ISO/IEC 27001:2022 A melléklet szerinti kontrollok közé tartozna az 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 és 8.16, DORA-megjegyzéssel a jelentős IKT-vonatkozású incidensek osztályozására és jelentésére.
A Clarysec Zenith Controls: keresztmegfelelési útmutató [ZC] ezután keresztmegfelelési iránytűként működik. A Zenith Controls keretében a Clarysec az ISO/IEC 27002:2022 kontrollokat más ISO/IEC 27001:2022 kontrollokhoz, kapcsolódó szabványokhoz, auditelvárásokhoz, valamint olyan jogszabályokhoz rendeli, mint a DORA, a GDPR és a NIS2. Nem hoz létre külön „Zenith kontrollokat”. Azt mutatja meg, hogyan működnek együtt a meglévő ISO kontrollok, és hogyan tesztelik őket.
A DORA szerinti jelentéstételi munkafolyamat kontrolláncként értelmezhető:
| DORA szerinti incidensjelentési igény | ISO/IEC 27001:2022 A melléklet szerinti kontrollkapcsolat | Mit várnak az auditorok |
|---|---|---|
| Feltételezett IKT-incidensek észlelése | 6.8 Információbiztonsági események jelentése, 8.15 Naplózás, 8.16 Monitorozási tevékenységek | Jelentési csatornák, riasztási szabályok, monitorozási bizonyítékok, munkatársi tudatosság |
| Annak értékelése, hogy egy esemény incidens-e | 5.25 Információbiztonsági események értékelése és döntéshozatal | Súlyossági mátrix, triázsjegyzetek, döntési naplók, üzleti hatásvizsgálat |
| A reagálási és jelentéstételi folyamat előkészítése | 5.24 Információbiztonsági incidenskezelés tervezése és előkészítése | Incidensreagálási terv, szerepkörök, kapcsolattartói listák, eszkalációs útvonalak, szabályozói jelentéstételi munkafolyamat |
| Reagálás a megerősített incidensre | 5.26 Reagálás információbiztonsági incidensekre | Elszigetelési nyilvántartások, kommunikáció, végrehajtott intézkedések, kijelölt felelősök |
| Bizonyítékok megőrzése | 5.28 Bizonyítékgyűjtés | Bizonyítéklánc, napló-pillanatképek, forenzikus nyilvántartások, bizonyítékkezelési eljárás |
| Tanulás és fejlesztés | 5.27 Tanulás információbiztonsági incidensekből | Incidens utáni felülvizsgálat, gyökérok-elemzés, helyesbítő intézkedések, kontrollfrissítések |
Nem lehet jelenteni azt, amit nem észleltek. Nem lehet osztályozni azt, amit nem értékeltek. Nem lehet jelentéstételi döntést igazolni nyilvántartások nélkül. Nem lehet fejleszteni incidens utáni felülvizsgálat nélkül.
6.8 kontroll: a DORA-óra az emberekkel indul
Sarah helyzetében az első hasznos jel nem feltétlenül a SOC-ból érkezik. Jöhet egy ügyfélkapcsolati vezetőtől, aki ügyfélpanaszokat hall, egy pénzügyi felhasználótól, aki sikertelen elszámolási kötegeket lát, vagy egy mérnöktől, aki rendellenes késleltetést észlel.
Ezért alapvető a DORA szempontjából az ISO/IEC 27001:2022 A melléklet 6.8 kontrollja, az információbiztonsági események jelentése. A jelentéstételt a teljes munkaerő felelősségévé teszi, nem csupán biztonságüzemeltetési feladattá.
A Zenith Blueprint 16. lépésében, a személyi biztonsági intézkedések II. részében a Clarysec így fogalmaz:
Egy hatékony incidensreagálási rendszer nem eszközökkel, hanem emberekkel kezdődik.
A 16. lépés egyértelmű jelentési csatornákat, biztonságtudatossági képzést, hibáztatásmentes kultúrát, triázst, bizalmasságot és időszakos szimulációkat javasol. A leghasznosabb gyakorlati üzenet egyszerű:
„Ha kétsége van, jelentse.”
Ez DORA-kontrollelv. Ha a munkavállalók megvárják, amíg biztosak lesznek, a szervezet időt veszít. Ha korán jelentenek, a szervezet értékelhet, osztályozhat és dönthet.
A Zenith Controls a 6.8-at észlelő kontrollként rendeli hozzá, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást. Kapcsolódik az 5.24-hez, mert a jelentési csatornáknak az incidensreagálási terv részét kell képezniük. Táplálja az 5.25-öt, mert az események csak akkor értékelhetők, ha jelentik őket. Kiváltja az 5.26-ot, mert a formális reagálás a jelentések értékelése után indul.
A DORA szempontjából ez támogatja az Article 17 és Article 18 követelményeit, amelyek szerint a pénzügyi szervezeteknek kezelniük, osztályozniuk és jelenteniük kell a jelentős IKT-vonatkozású incidenseket és a jelentős kiberfenyegetéseket. Támogatja továbbá a GDPR Article 33 és Recital 85 követelményeit, mert a belső jelentéstétel határozza meg, milyen gyorsan azonosítanak és eszkalálnak egy személyesadat-sértést.
Gyakorlati Clarysec-megvalósításként egy egyoldalas „Hogyan jelentsünk IKT-incidenst” útmutató használható. Tartalmaznia kell:
- Mit kell jelenteni, beleértve a kieséseket, gyanús e-maileket, elveszett eszközöket, szokatlan rendszerműködést, feltételezett beszállítói kompromittálódást, jogosulatlan hozzáférést, adatszivárgást és ügyfeleket érintő szolgáltatásromlást.
- Hogyan kell jelenteni, például felügyelt postafiókon, jegykategórián, telefonos vészcsatornán, együttműködési csatornán vagy SOC-portálon keresztül.
- Mit kell megadni, például időpontot, rendszert, felhasználót, üzleti folyamatot, észlelt hatást, képernyőképet, ha biztonságos, valamint azt, hogy ügyfelek vagy személyes adatok érintettek lehetnek-e.
- Mit nem szabad tenni, beleértve a naplók törlésének tilalmát, kritikus rendszerek utasítás nélküli újraindításának mellőzését, ügyfelek jóváhagyás nélküli külső megkeresésének tilalmát, valamint a szerepkörön túli vizsgálódás tilalmát.
- Mi történik ezután, beleértve a triázst, osztályozást, eszkalációt, reagálást, bizonyítékmegőrzést és az esetleges szabályozói értékelést.
A cél nem az, hogy minden munkavállalóból vizsgálót képezzünk. A cél az, hogy minden munkavállaló megbízható jelzőforrássá váljon.
5.25 kontroll: a DORA szerinti osztályozási döntési pont
A DORA szerinti jelentős IKT-vonatkozású incidensjelentés az osztályozáson múlik. Itt válik központivá az ISO/IEC 27001:2022 A melléklet 5.25 kontrollja, az információbiztonsági események értékelése és a döntéshozatal.
A Zenith Blueprint 23. lépése így magyarázza a gyakorlati kihívást:
Nem minden anomália katasztrófa. Nem minden riasztás jelez kompromittálódást.
Majd az 5.25 célját így írja le:
megkülönböztetni az ártalmatlant az ártalmastól, és tudni, mi igényel eszkalációt.
A DORA esetében ez az a pont, amikor egy biztonsági eseményt, szolgáltatásromlást, beszállítói kiesést, adatkitettséget vagy működési zavart a jelentős incidens kritériumai szerint értékelnek. A szervezetnek figyelembe kell vennie a működési hatást, az érintett szolgáltatásokat, a kritikus vagy fontos funkciókat, az érintett ügyfeleket és tranzakciókat, az időtartamot, a földrajzi kiterjedést, az adathatást, a reputációs következményeket és a gazdasági hatást.
A Zenith Controls az 5.25-öt közvetlenül a DORA Article 18, jelentős IKT-incidensek osztályozása követelményhez rendeli. Ez a strukturált értékelési folyamat annak meghatározására, hogy egy észlelt esemény biztonsági incidensnek minősül-e. Kapcsolódik a 8.16-hoz, a monitorozási tevékenységekhez is, mert a riasztásokat és naplóadatokat triázsolni kell, valamint az 5.26-hoz, mert az osztályozás kiváltja a reagálást.
Sok szervezet itt bukik el az auditokon. Vannak jegyeik, de nincsenek osztályozási nyilvántartásaik. Vannak súlyossági címkéik, de nincsenek kritériumaik. Vannak szabályozói jelentéseik, de nincs döntési nyomvonaluk, amely bizonyítaná, miért minősült vagy miért nem minősült egy incidens jelentősnek.
A Clarysec ezt úgy kezeli, hogy a DORA szerinti osztályozást beépíti az incidensek súlyossági modelljébe. A vállalati Incidenskezelési szabályzat 5.3.1 pontja egyértelmű Tier 1 példát tartalmaz:
Tier 1: Kritikus (pl. megerősített adatsértés, zsarolóvírus-kitörés, éles rendszer kompromittálódása)
Kisebb szervezetek számára az Incidenskezelési szabályzat - SME szigorú működési elvárást ad:
Az ügyvezetőnek az IT-szolgáltató közreműködésével az értesítéstől számított egy órán belül súlyosság szerint osztályoznia kell minden incidenst.
Ez az egyórás osztályozási cél erős, mert irányítási fegyelmet kényszerít ki. Egy kisebb szabályozott szervezetnek nem feltétlenül van 24/7 SOC-ja, de ettől még meghatározhatja, ki osztályoz, ki ad tanácsot, és milyen gyorsan kell döntést hozni.
DORA–ISO incidens-triázs nyilvántartás
Az osztályozás igazolhatósága érdekében hozzon létre DORA incidens-triázs nyilvántartást a jegykezelő, GRC- vagy incidenskezelési rendszerben. A nyilvántartást minden potenciálisan lényeges IKT-eseményhez létre kell hozni, akkor is, ha később alacsonyabb osztályba sorolják.
| Mező | Példabejegyzés | Támogatott kontrollbizonyíték |
|---|---|---|
| Eseményazonosító | ICT-2026-0417-001 | 5.25, 5.26 |
| Észlelési forrás | SIEM-riasztás és fizetési üzemeltetési jelentés | 6.8, 8.15, 8.16 |
| Első értesítés időpontja | 08:17 CET | 6.8 |
| Kezdeti értékelő | SOC-vezető | 5.25 |
| Üzleti folyamatgazda | Fizetési terület vezetője | 5.24, 5.26 |
| Érintett kritikus vagy fontos funkció | Fizetéselszámolás | 5.25, DORA-osztályozás |
| Ügyfél- vagy tranzakciós hatás | Késleltetett feldolgozás vállalati ügyfelek számára | 5.25 |
| Adathatás | Vizsgálat alatt, megerősített adatkivitel nincs | 5.25, GDPR-értékelés |
| Beszállítói érintettség | A felhőinfrastruktúra-szolgáltató csökkent szolgáltatási szintet jelentett | 5.24, beszállítói eszkaláció |
| Súlyossági döntés | Tier 1 Kritikus, megerősítés folyamatban | 5.25 |
| DORA jelentéstételi döntés | Potenciális jelentős IKT-incidens, a megfelelési funkció értesítve | 5.25, 5.26 |
| Megőrzött bizonyítékok | SIEM-naplók, felhő státuszjelentések, végponti telemetria | 5.28 |
| Következő felülvizsgálat időpontja | 09:00 CET | 5.26 |
Adjon hozzá döntési megjegyzést:
„A kritikus üzleti folyamatot érintő fizetési szolgáltatási zavar, a megoldatlan gyökérok és a lehetséges ügyfélhatás alapján az eseményt potenciális jelentős IKT-vonatkozású incidensként eszkaláljuk. A megfelelési és jogi terület értékeli a szabályozói értesítési követelményeket. A bizonyítékmegőrzés megkezdődött.”
Ez az egyetlen nyilvántartási bejegyzés támogatja a DORA Article 17 szerinti nyomon követést, az Article 18 szerinti osztályozást, az Article 19 szerinti jelentéstételi döntéseket, az ISO/IEC 27001:2022 A melléklet 5.25 szerinti értékelést, a 6.8 szerinti jelentéstételt, az 5.26 szerinti reagálást és az 5.28 szerinti bizonyítékkezelést.
5.24 és 5.26 kontroll: tervezés, szerepkörök és reagálás
Amikor DORA-incidens történik, a reagálási tervnek már választ kell adnia a kényelmetlen kérdésekre.
Kinek van hatásköre osztályozni? Ki lép kapcsolatba az illetékes hatósággal? Ki hagyja jóvá az első értesítést? Ki kommunikál az ügyfelekkel? Ki veszi fel a kapcsolatot az IKT-harmadik fél szolgáltatóval? Ki dönt arról, hogy az incidens GDPR-értesítést is kivált-e? Ki őrzi meg a bizonyítékokat? Ki felel a végső jelentésért?
Az ISO/IEC 27001:2022 A melléklet 5.24 kontrollja, az információbiztonsági incidenskezelés tervezése és előkészítése, még a válság előtt megválaszolja ezeket a kérdéseket. Az 5.26 kontroll, az információbiztonsági incidensekre adott válasz, biztosítja, hogy a terv az incidens során szabályozott intézkedésekké váljon.
A Zenith Controls az 5.24-et a DORA Article 17–21 követelményeihez kapcsolja, mert ez teszi működőképessé a dokumentált, tesztelt és felülvizsgált incidensreagálást, beleértve a belső eszkalációt, a külső szabályozói értesítést, az érdekelt felekkel való kommunikációt és a tanulságok levonását.
Az ISO/IEC 27035-1:2023 ezt azzal támogatja, hogy az incidenskezelést a reagálási eljárásokon túl kiterjeszti a szabályzatokra, tervezésre, képességekre, kapcsolatokra, támogató mechanizmusokra, tudatosságra, képzésre és rendszeres tesztelésre. Az ISO/IEC 27035-2:2023 tovább részletezi az incidenskezelési folyamatot az előkészítéstől a tanulságok levonásáig.
A Zenith Blueprint 23. lépése közvetlen bevezetési utasítást ad:
Gondoskodjon naprakész incidensreagálási tervről (5.24), amely lefedi az előkészítést, eszkalációt, reagálást és kommunikációt.
Egy DORA-kész incidensreagálási tervnek meg kell határoznia:
- Az IKT incidensreagálási csoportot és helyetteseit.
- A súlyossági osztályozásra és a DORA szerinti jelentéstételi eszkalációra vonatkozó hatáskört.
- A jogi, megfelelési, adatvédelmi, kommunikációs, IT-, biztonsági, beszállítói és üzleti folyamatgazdai felelősségeket.
- A jelentős IKT-vonatkozású incidensek osztályozási kritériumait.
- A kezdeti, közbenső és végső szabályozói jelentéstétel eljárásait.
- A GDPR, NIS2, szerződéses, kiberbiztosítási és igazgatósági értesítési értékelést.
- Az elszigetelési, eltávolítási, helyreállítási és ellenőrzési lépéseket.
- A bizonyítékmegőrzési követelményeket.
- A beszállítói eszkalációs és napló-hozzáférési eljárásokat.
- A tanulságok és helyesbítő intézkedések nyomon követését.
Az Incidenskezelési szabályzat - SME a reagálási határidőket a jogi követelményekhez is kapcsolja:
A reagálási határidőket, beleértve az adat-helyreállítást és az értesítési kötelezettségeket, dokumentálni kell, és összhangba kell hozni a jogi követelményekkel, például a GDPR szerinti, személyesadat-sértésre vonatkozó 72 órás bejelentési kötelezettséggel.
Ez létfontosságú, mert egyetlen IKT-incidens DORA szerinti jelentős incidenssé, GDPR szerinti személyesadat-sértéssé, NIS2 szerinti jelentős incidenssé, szerződéses ügyfélértesítési eseménnyé és beszállítókezelési kérdéssé is válhat. A tervnek össze kell hangolnia ezeket a rétegeket, nem pedig külön világként kell kezelnie őket.
8.15 és 8.16 kontroll: a naplók teszik igazolhatóvá a jelentést
A DORA szerinti incidensjelentés tényeken alapul. A tények a naplózáson és a monitorozáson alapulnak.
A fizetéselszámolási forgatókönyvben Sarah-nak tudnia kell, mikor kezdődött a szolgáltatásromlás, mely rendszerek voltak érintettek, használtak-e emelt jogosultságú fiókokat, távozott-e adat a környezetből, összhangban van-e a felhőszolgáltató kiesése a belső telemetriával, és mikor fejeződött be a helyreállítás.
Az ISO/IEC 27001:2022 A melléklet 8.15 kontrollja, a naplózás, valamint a 8.16 kontroll, a monitorozási tevékenységek, ezt a bizonyítékalapot támogatják. A Zenith Controls mindkettőt az 5.24-hez kapcsolja, mert az incidensreagálási tervezésnek használható naplóadatokat és monitorozási képességet kell tartalmaznia. A 8.16 kontroll az 5.25-höz is kapcsolódik, mert a riasztásokat döntésekké kell triázsolni.
A Clarysec Naplózási és monitorozási szabályzat - SME [LMP-SME] gyakorlati eszkalációs követelményt tartalmaz:
A magas prioritású riasztásokat 24 órán belül eszkalálni kell az ügyvezető és az adatvédelmi koordinátor felé
A DORA hatálya alá tartozó szervezeteknél a potenciálisan jelentős IKT-incidensek általában gyorsabb működési eszkalációs modellt igényelnek, különösen, ha kritikus vagy fontos funkciók érintettek. Az irányítási minta ugyanakkor helyes: a magas prioritású riasztások nem maradhatnak az IT-n belül. El kell jutniuk az üzleti, adatvédelmi és vezetői szerepkörökhöz.
Egy DORA-kész naplózási modellnek tartalmaznia kell:
- Központi naplózást kritikus rendszerekhez, identitásplatformokhoz, végpontokhoz, felhőszolgáltatásokhoz, hálózatbiztonsági eszközökhöz és üzleti alkalmazásokhoz.
- Időszinkronizálást a rendszerek között, hogy az incidens-idővonalak megbízhatók legyenek.
- A riasztások kategorizálását az incidens súlyosságához és a DORA-osztályozáshoz igazítva.
- Naplómegőrzést a szabályozói, szerződéses és forenzikus igényekhez igazítva.
- Hozzáférés-szabályozást, amely védi a naplók sértetlenségét.
- Eljárásokat napló-pillanatképek rögzítésére jelentős incidensek során.
- Beszállítói napló-hozzáférési követelményeket kritikus IKT-szolgáltatásokhoz.
Az auditorok nem fogadják el elegendő bizonyítékként azt, hogy „a SIEM-ben megvan”. Meg fogják kérdezni, hogy léteztek-e a megfelelő naplók, felülvizsgálták-e a riasztásokat, időben megtörtént-e az eszkaláció, és megőrizték-e a naplókat, amikor az incidens potenciálisan jelentéskötelessé vált.
5.28 kontroll: bizonyítékgyűjtés és bizonyítéklánc
Jelentős IKT-vonatkozású incidens esetén a bizonyíték három célt szolgál: műszaki vizsgálatot, szabályozói elszámoltathatóságot és jogi igazolhatóságot.
Ha a bizonyíték hiányos, felülírt, módosított vagy dokumentálatlan, a szervezet nehezen tudja bizonyítani, mi történt. Nehezen tudja igazolni az osztályozási döntését is.
A Clarysec Bizonyítékgyűjtési és forenzikai szabályzata [ECF] így rendelkezik:
A beszerzés időpontjától az archiválásig vagy átadásig minden fizikai vagy digitális bizonyítékhoz bizonyítéklánc-naplónak kell kapcsolódnia, amely dokumentálja:
Az SME-változat, a Bizonyítékgyűjtési és forenzikai szabályzat - SME [ECF-SME], egyszerűen fogalmazza meg a követelményt:
Minden digitális bizonyítékelemet naplózni kell az alábbiakkal:
A működési tanulság egyértelmű. A bizonyítékkezelés nem kezdődhet akkor, amikor a jogi terület kéri. Be kell épülnie az incidensreagálásba.
Az ISO/IEC 27006-1:2024 ezt az auditelvárást erősíti azzal, hogy hangsúlyozza az információbiztonsági incidensekből származó bizonyítékok azonosítására, gyűjtésére és megőrzésére szolgáló eljárásokat. A DORA esetében ugyanaz a bizonyítékkészlet támogathatja a kezdeti értesítést, a közbenső frissítéseket, a végső jelentést, az incidens utáni felülvizsgálatot és a felügyeleti kérdéseket.
A DORA-vonatkozású incidensek gyakorlati bizonyíték-ellenőrzőlistájának tartalmaznia kell:
- Incidensjegyet és triázsjegyzeteket.
- Az észlelés, eszkaláció, osztályozás, jelentéstétel, elszigetelés, helyreállítás és lezárás idővonalát.
- SIEM-riasztásokat és korrelált naplókat.
- Végponti és szerverartefaktumokat.
- Identitás- és emelt jogosultságú hozzáférési naplókat.
- Hálózati forgalmi összefoglalókat.
- Felhőszolgáltatói státusz- és auditnaplókat.
- Beszállítói kommunikációt és incidensnyilatkozatokat.
- Üzleti hatásnyilvántartásokat, beleértve az ügyfeleket, szolgáltatásokat, tranzakciókat és kiesési időt.
- Szabályozói értesítéstervezeteket és benyújtásokat.
- Vezetői döntéseket és jóváhagyásokat.
- Gyökérok-elemzést.
- Tanulságokat és helyesbítő intézkedéseket.
A bizonyítékoknak mind a műszaki tényeket, mind az irányítási döntéseket meg kell mutatniuk. A DORA szerinti jelentéstétel nem csak arról szól, mi történt a rendszerekkel. Arról is szól, hogy a vezetés hogyan ismerte fel, értékelte, eszkalálta, kontrollálta az incidenst, és hogyan fejlesztett annak alapján.
5.27 kontroll: tanulságok és folyamatos fejlesztés
A DORA-incidens nem zárul le a végső jelentés benyújtásával. Akkor zárul le, amikor a szervezet tanult belőle, helyesbítő intézkedéseket rendelt hozzá, frissítette a kontrollokat és ellenőrizte a fejlődést.
Az ISO/IEC 27001:2022 A melléklet 5.27 kontrollja, a tanulás információbiztonsági incidensekből, a DORA szerinti jelentéstételt az ISO/IEC 27001:2022 folyamatos fejlesztési ciklusához kapcsolja. A Zenith Controls az 5.24-et az 5.27-hez kapcsolja, mert az incidenskezelés gyökérok-elemzés, tanulságok és kontrollfejlesztés nélkül hiányos.
A Zenith Blueprint 23. lépése arra utasítja a szervezeteket, hogy a tanulságok alapján frissítsék a tervet, és célzott képzést biztosítsanak az incidensreagálásról és a bizonyítékkezelésről. Ez különösen fontos a DORA esetében, mert az ismétlődő osztályozási késedelmek, hiányzó beszállítói bizonyítékok, gyenge naplók vagy tisztázatlan kommunikáció felügyeleti aggályokká válhatnak.
A tanulságok sablonjának rögzítenie kell:
- Mi történt és mikor.
- Mely kritikus vagy fontos funkciók voltak érintettek.
- Időszerű és pontos volt-e az osztályozás.
- A DORA jelentéstételi döntések elegendő bizonyítékon alapultak-e.
- Értékelték-e a GDPR, NIS2, szerződéses vagy ügyfélértesítési kiváltó feltételeket.
- A beszállítók a megállapodott határidőkön belül reagáltak-e.
- Megőrizték-e a naplókat és a forenzikus bizonyítékokat.
- Mely kontrollok hibáztak vagy hiányoztak.
- Mely szabályzatokat, forgatókönyveket, képzéseket vagy technikai kontrollokat kell fejleszteni.
- Ki felel az egyes helyesbítő intézkedésekért, és milyen határidővel.
Ez az ISO/IEC 27001:2022 vezetőségi felülvizsgálatot is táplálja. Az incidenstrendeket a vezetésnek kell felülvizsgálnia, nem szabad műszaki incidens-utóelemzésekben eltemetni őket.
Keresztmegfelelés: DORA, GDPR, NIS2, NIST és COBIT 2019
Pénzügyi szervezeteknél a DORA van a középpontban, de az incidensjelentés ritkán tartozik kizárólag egyetlen keretrendszerhez.
Egyetlen IKT-incidens érintheti a DORA szerinti jelentős IKT-vonatkozású incidensjelentést, a GDPR szerinti személyesadat-sértési bejelentést, a NIS2 szerinti jelentős incidens jelentését, ügyfélszerződéses kötelezettségeket, kiberbiztosítási értesítést és igazgatósági jelentéstételt.
A Zenith Controls az ISO/IEC 27002:2022 kontrollok több keretrendszeren átívelő megfeleltetésével csökkenti ezt a komplexitást. Például:
| ISO/IEC 27001:2022 A melléklet szerinti kontroll | DORA-kapcsolat | Egyéb megfelelési kapcsolat |
|---|---|---|
| 5.24 Információbiztonsági incidenskezelés tervezése és előkészítése | Dokumentált, tesztelt incidensfolyamatokon keresztül támogatja a DORA Article 17–21 követelményeit | Támogatja a GDPR Article 33 és Article 34, az ISO/IEC 27035-1:2023 és az ISO/IEC 27035-2:2023 követelményeit |
| 5.25 Információbiztonsági események értékelése és döntéshozatal | Támogatja a DORA Article 18 szerinti osztályozást | Támogatja a GDPR szerinti adatsértési kockázatértékelést és az eseménytriázs-elvárásokat |
| 6.8 Információbiztonsági események jelentése | Belső jelentési kiváltó feltételeken keresztül támogatja a DORA Article 17 és Article 18 követelményeit | Támogatja a GDPR Article 33 és Recital 85, valamint a NIS2 Article 23 eszkalációs elvárásait |
| 8.15 Naplózás | Támogatja az incidens-idővonalakat és a műszaki bizonyítékokat | Támogatja a forenzikus, audit-, adatvédelmi és szerződéses bizonyítékszükségleteket |
| 8.16 Monitorozási tevékenységek | Támogatja az észlelést, riasztást és triázst | Támogatja a NIST Detect eredményeket és a működési reziliencia monitorozását |
NIST szempontból ugyanaz a modell támogatja a Detect, Respond és Recover eredményeket. COBIT 2019 és ISACA auditori szempontból a fő kérdés az irányítás: kontrollált-e az incidenskezelés, a folytonosság, a kockázat, a megfelelés, a beszállítói felelősségek és a teljesítménymonitorozás.
A legérettebb szervezetek nem hoznak létre külön munkafolyamatot minden keretrendszerhez. Egy incidenskezelési folyamatot alakítanak ki szabályozói rétegekkel. A jegy egyszer rögzíti ugyanazokat az alapvető tényeket, majd szükség esetén DORA, GDPR, NIS2, szerződéses, biztosítási vagy ágazatspecifikus jelentéstétel irányába ágazik el.
Hogyan tesztelik az auditorok a DORA incidensfolyamatot
Egy DORA-kész incidensjelentési folyamatnak különböző auditori nézőpontokból is helyt kell állnia.
Egy ISO/IEC 27001:2022 auditor azt vizsgálja, hogy az IBIR kiválasztotta és bevezette-e a releváns A melléklet szerinti kontrollokat, az alkalmazhatósági nyilatkozat támogatja-e ezeket a kontrollokat, léteznek-e incidensnyilvántartások, és a belső audit, valamint a vezetőségi felülvizsgálat tartalmazza-e az incidens-teljesítményt.
A Zenith Controls az ISO/IEC 19011:2018 auditmódszertanra hivatkozik az 5.24, 5.25 és 6.8 esetében. Az 5.24-nél az auditorok az incidensreagálási tervet vizsgálják az incidenstípusok, súlyossági besorolások, kijelölt szerepkörök, kapcsolattartói listák, eszkalációs útvonalak, szabályozói jelentéstételi utasítások és kommunikációs felelősségek szempontjából. Az 5.25-nél azt vizsgálják, hogy léteznek-e dokumentált osztályozási kritériumok, például a rendszerhatáson, adatérzékenységen és időtartamon alapuló súlyossági mátrixok vagy döntési fák. A 6.8-nál értékelik a jelentési mechanizmusokat, a jelentésig eltelt idő mutatóit, valamint annak bizonyítékait, hogy a jelentett eseményeket naplózzák, triázsolják és lezárják.
A DORA szerinti felügyeleti felülvizsgálat arra összpontosít, hogy a jelentős IKT-vonatkozású incidenseket a szabályozói elvárások szerint észlelik-e, osztályozzák-e, jelentik-e, frissítik-e és zárják-e. A felülvizsgáló mintaincidenst kérhet, és az első riasztástól a végső jelentésig visszakövetheti.
Az adatvédelmi auditor arra összpontosít, hogy értékelték-e a személyesadat-sértési kockázatot, és kiváltódtak-e a GDPR Article 33 és Article 34 szerinti kötelezettségek. A BS EN 17926:2023 itt releváns, mert adatvédelmi incidensfelelősségeket, értesítési kritériumokat, időzítést és a felügyeleti közzétételi elvárásokkal való összhangot ad hozzá.
| Auditnézőpont | Valószínű kérdés | Clarysec által előkészített bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 | Kiválasztották, bevezették és hatékonyan működtetik-e az incidenskontrollokat? | SoA, incidensreagálási terv, jegyek, belső audit nyilvántartások, vezetőségi felülvizsgálati eredmények |
| DORA | Bizonyítani tudja-e a jelentős IKT-incidensek időben történő osztályozását és jelentését? | DORA triázsnyilvántartás, osztályozási mátrix, szabályozói jelentéstételi napló, incidens-idővonal |
| GDPR | Értékelték-e, hogy személyes adatok sérültek-e, és értesítettek-e, ha szükséges volt? | Adatvédelmi értékelés, adathatásjegyzetek, felügyeleti értesítési döntés, érintetti kommunikációs nyilvántartás |
| NIS2 | Az incidenst haladéktalanul eszkalálták és koordinálták-e a szolgáltatási hatás szempontjából? | Eszkalációs nyilvántartások, üzleti hatásvizsgálat, kommunikációs napló |
| NIST | Működnek-e a Detect, Respond és Recover tevékenységek? | Monitorozási riasztások, reagálási forgatókönyvek, helyreállítás ellenőrzése, tanulságok |
| COBIT 2019 és ISACA | Irányított, mért és fejlesztett-e az incidensjelentés? | RACI, KPI-k, beszállítói bizonyítékok, megfelelés nyomon követése, helyesbítő intézkedések |
Ugyanaz a bizonyítékkészlet több auditkérdést is kielégíthet, ha kezdettől fogva megfelelően strukturált.
DORA incidensjelentési felkészültségi ellenőrzőlista 2026-ra
A következő asztali gyakorlat, belső audit vagy felügyeleti felülvizsgálat előtt tesztelje szervezetét ezzel az ellenőrzőlistával:
- Tudják-e a munkavállalók, hogyan jelentsenek feltételezett IKT-incidenseket?
- Van-e dedikált incidensjelentési csatorna?
- A biztonsági eseményeket következetesen naplózzák és triázsolják-e?
- Van-e dokumentált súlyossági és DORA szerinti jelentős incidensosztályozási mátrix?
- Kötelező-e az osztályozás az értesítést követő meghatározott időn belül?
- A kritikus vagy fontos funkciók hozzá vannak-e rendelve rendszerekhez és beszállítókhoz?
- Egy munkafolyamatban értékelik-e a DORA, GDPR, NIS2, szerződéses, biztosítási és ügyfélértesítési kiváltó feltételeket?
- Meghatározták-e az incidensszerepköröket az IT, biztonság, jogi, megfelelési, adatvédelmi, kommunikációs és üzleti folyamatgazdai területeken?
- Elegendőek-e a naplók az incidens-idővonalak rekonstruálásához?
- Bizonyítéklánccal megőrzik-e a bizonyítékokat?
- Tesztelik-e a beszállítói incidenskötelezettségeket és napló-hozzáférési jogokat?
- Végeznek-e asztali gyakorlatokat reális DORA-forgatókönyvekkel?
- A tanulságokat helyesbítő intézkedésekhez rendelve követik-e?
- Felülvizsgálják-e az incidensmutatókat a vezetőségi felülvizsgálat során?
- Az alkalmazhatósági nyilatkozat hozzá van-e rendelve a DORA szempontjából releváns ISO/IEC 27001:2022 kontrollokhoz?
Ha bármelyik kérdésre a válasz „részben”, akkor a probléma nem csupán megfelelési kérdés. Működési rezilienciáról van szó.
Bizonyítékkész DORA incidensjelentési modell kialakítása
A DORA szerinti incidensjelentés 2026-ban az irányítás nyomás alatti tesztje. Nem azok a szervezetek teljesítenek jól, amelyek a leghosszabb incidensreagálási dokumentumokkal rendelkeznek. Hanem azok, amelyeknek egyértelmű jelentési csatornáik, gyors osztályozásuk, megbízható naplóik, megőrzött bizonyítékaik, képzett munkatársaik, tesztelt beszállítói eszkalációjuk és több keretrendszeren átívelő visszakövethetőségük van.
A Clarysec segíthet ennek a működési modellnek a kialakításában.
Kezdje az incidenskockázatok és az alkalmazhatósági nyilatkozat feltérképezésével a Zenith Blueprint: auditori 30 lépéses ütemterv segítségével. Ezután hangolja össze incidenskontrolljait a Zenith Controls: keresztmegfelelési útmutatóval. Tegye működőképessé a folyamatot a Clarysec Incidenskezelési szabályzatával, Incidenskezelési szabályzat - SME, Naplózási és monitorozási szabályzat - SME, Bizonyítékgyűjtési és forenzikai szabályzatával, valamint Bizonyítékgyűjtési és forenzikai szabályzat - SME.
Ha a vezetői csapat a következő valós incidens előtt bizonyosságot szeretne, futtasson DORA szerinti jelentős IKT-vonatkozású incidens asztali gyakorlatot a Clarysec eszközkészletével, és állítsa elő azt a bizonyítékcsomagot, amelyet egy auditor vagy felügyeleti szerv elvárna.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


