DORA 2026 ütemterv az IKT-kockázatokhoz, a beszállítókhoz és a TLPT-hez

A DORA 2026 körüli keresési pánik valójában nem a szabályozásról, hanem a bizonyítékokról szól

Hétfő reggel 08:15 van, és egy közepes méretű pénzforgalmi intézmény CISO-ja előtt három böngészőfül van megnyitva: „DORA RTS/ITS ellenőrzőlista”, „DORA IKT harmadik fél nyilvántartás sablon” és „TLPT követelmények pénzügyi szervezetek számára”.

A megfelelőségi vezető már megkérdezte, hogy az igazgatósági anyagnak tartalmaznia kell-e a legfrissebb incidensosztályozási munkafolyamatot. A beszerzés új felhőalapú analitikai platformot szeretne bevezetni. A COO bizonyosságot kér arról, hogy az alapvető banki SaaS-szolgáltató mögött nincs rejtett, EU-n kívüli alvállalkozói kitettség. A belső audit tesztelési naptárat kér. A jogi terület azt kérdezi, hogy a GDPR szerinti incidensbejelentési határidők össze vannak-e hangolva a DORA szerinti incidensjelentéssel.

Senki sem elméleti kérdést tesz fel. A kérdés ez: „Ezt péntekig tudjuk bizonyítani?”

Ez a valódi DORA 2026 probléma. A legtöbb pénzügyi szervezet érti a fő kötelezettségeket: IKT-kockázatkezelés, IKT-val kapcsolatos incidensjelentés, digitális működési rezilienciatesztelés, harmadik félnek minősülő IKT-szolgáltatókkal kapcsolatos kockázatkezelés és a kritikus IKT-szolgáltatók erősebb felügyelete. A nehéz rész az, hogy a Regulatory Technical Standards, az Implementing Technical Standards és a cikk szintű kötelezettségek irányított, ismételhető és auditálható gyakorlattá váljanak.

A Digital Operational Resilience Act előírja, hogy a pénzügyi szervezetek tartsanak fenn robusztus IKT-kockázatkezelési képességeket, rendelkezzenek szabályzatokkal az IKT-val kapcsolatos incidensek kezelésére és jelentésére, teszteljék az IKT-rendszereket, kontrollokat és folyamatokat, valamint strukturált felügyeletet gyakoroljanak a harmadik félnek minősülő IKT-szolgáltatók felett. A rendelet arányosságot is elvár. Egy kisebb befektetési vállalkozásnak és egy nagy bankcsoportnak nem azonos bizonyítékrendszerre van szüksége, de mindkettőnek igazolnia kell, hogy a megközelítése megfelel a méretének, kockázati profiljának, összetettségének és kritikus funkcióinak.

A DORA-projektek jellemzően három ok valamelyike miatt siklanak félre. Először: a szervezet a DORA-t működési modell helyett jogi megfeleltetési feladatként kezeli. Másodszor: a beszállítói kockázatot beszállítói listaként dokumentálja, nem pedig függőségként, helyettesíthetőségként és koncentrációs kockázatként. Harmadszor: a tesztelést éves penetrációs tesztként kezeli, nem pedig olyan rezilienciaprogramként, amely sérülékenységvizsgálatokat, forgatókönyv-alapú tesztelést, incidensgyakorlatokat és adott esetben fenyegetésvezérelt penetrációs tesztelést tartalmaz, amelyre gyakran TLPT-ként keresnek rá.

Jobb megközelítés egyetlen bizonyítékrendszer kialakítása, amely összekapcsolja a szabályzatokat, nyilvántartásokat, felelősöket, kockázatokat, incidenseket, beszállítókat, tesztelést, helyreállítást és vezetőségi felülvizsgálatot. Ebben segítik a pénzügyi szervezeteket a Clarysec Zenith Blueprint, a használatra kész szabályzatok és a Zenith Controls: a DORA-t határidőből működési ritmussá alakítják.

A DORA működési modellel kezdjen, ne az RTS/ITS táblázattal

Sok csapat olyan táblázattal kezdi, amely felsorolja a DORA-cikkeket és az RTS/ITS követelményeket. Ez hasznos, de nem elegendő. Egy táblázat megmutathatja, minek kell léteznie. Nem jelöl ki felelősöket, nem határoz meg felülvizsgálati gyakoriságot, nem őrzi meg a bizonyítékokat, és nem igazolja, hogy egy kontroll ténylegesen működik.

A Zenith Blueprint: An Auditor’s 30-Step Roadmap dokumentumban a Clarysec ezt a kockázatkezelési szakaszban, a 14. lépésben, a kockázatkezelési szabályzatok és szabályozói kereszthivatkozások témakörében kezeli:

„DORA: A pénzügyi szektor vállalatai számára a DORA olyan IKT-kockázatkezelési keretrendszert ír elő, amely nagyon szorosan illeszkedik ahhoz, amit elvégeztünk: azonosítani kell a kockázatokat, kontrollokat és szabályzatokat kell bevezetni, majd tesztelni kell azokat. A DORA az incidensreagálást és jelentéstételt, valamint a harmadik fél IKT-szolgáltatók felügyeletét is hangsúlyozza.”

A gyakorlati üzenet egyszerű: ne építsen párhuzamos bürokráciát „DORA-megfelelőség” néven. Olyan kockázatalapú IKT-irányítási réteget kell kialakítani, amely a DORA követelményeit szabályzatokhoz, nyilvántartásokhoz, kontrollgazdákhoz, tesztelési nyilvántartásokhoz, beszállítói bizonyítékokhoz és vezetőségi felülvizsgálathoz kapcsolja.

Egy gyakorlati DORA működési modellnek öt bizonyítékpillérrel kell rendelkeznie:

Szabályozott pénzügyi szervezetek esetében ez a struktúra az RTS/ITS bevezetést auditra kész bizonyítékrendszerré alakítja. Az egyszerűsített IKT-kockázatkezelés hatálya alá tartozó szervezeteknél ugyanez a modell kevesebb dokumentumra és egyszerűbb nyilvántartásokra méretezhető. Az alapvető fegyelmek változatlanok: azonosítás, védelem, észlelés, reagálás, helyreállítás, tesztelés és a beszállítók irányítása.

IKT-kockázatkezelés: a nyilvántartás az irányítóterem

A DORA IKT-kockázatkezelési elvárásai megkövetelik, hogy a pénzügyi szervezetek azonosítsák, osztályozzák és kezeljék az IKT-kockázatokat a rendszerek, adatok, folyamatok, kritikus vagy fontos funkciók és harmadik félhez kapcsolódó függőségek teljes körében.

A gyakori hiba nem a kockázati nyilvántartás hiánya. Hanem az, hogy a nyilvántartás nincs összekapcsolva a beszállítókkal, eszközökkel, incidensekkel és tesztekkel. A DORA nem értékeli a szép táblázatot, ha az nem tudja megmagyarázni, miért nincs kilépési terve egy magas kockázatú beszállítónak, vagy miért nem teszteltek egy kritikus ügyfélfizetési platformot.

A Clarysec KKV Kockázatkezelési szabályzata tömör bizonyítékalapot ad a kisebb pénzügyi szervezeteknek:

„Minden kockázati bejegyzésnek tartalmaznia kell: leírást, valószínűséget, hatást, pontszámot, tulajdonost és kockázatkezelési tervet.”
Az „Irányítási követelmények” szakaszból, 5.1.2 szabályzati pont.

Nagyobb pénzügyi szervezetek esetében a Clarysec vállalati Kockázatkezelési szabályzata formálisabb folyamatot ír elő:

„Formális kockázatkezelési folyamatot kell fenntartani az ISO/IEC 27005 és az ISO 31000 szerint, amely lefedi a kockázatazonosítást, elemzést, értékelést, kezelést, nyomon követést és kommunikációt.”
Az „Irányítási követelmények” szakaszból, 5.1 szabályzati pont.

Ez a különbség lényeges. A DORA arányos, de az arányosság nem jelent informális működést. Egy kisebb pénzforgalmi vállalkozás használhat egyszerűsített nyilvántartást, míg egy bankcsoport integrált GRC-eszközöket alkalmazhat. Az auditor mindkét esetben meg fogja kérdezni: Melyek az IKT-kockázatok? Ki felel értük? Mi a kockázatkezelési terv? Milyen bizonyíték mutat előrehaladást? Hogyan befolyásolják a beszállítók és a kritikus funkciók a pontszámot?

Egy erős DORA IKT-kockázati nyilvántartásnak a következő mezőket kell tartalmaznia:

Gyakorlati feladatként válasszon ki egy kritikus IKT-szolgáltatást, például egy felhőben üzemeltetett tranzakciómonitorozási platformot, és hozzon létre hozzá egy kockázati bejegyzést 20 perc alatt. Írja le a kiesési vagy kompromittálódási forgatókönyvet, pontozza a valószínűséget és a hatást, jelöljön ki felelőst, azonosítsa a kapcsolódó beszállítókat, határozza meg a kockázatkezelési tervet, és kapcsolja a bejegyzést olyan bizonyítékokhoz, mint a beszállítói átvilágítás, SLA, incidenszáradékok, BIA, DR-teszteredmények, felügyeleti irányítópultok és hozzáférés-felülvizsgálatok.

Ez az egyetlen bejegyzés lesz az a szál, amely összekapcsolja a DORA szerinti IKT-kockázatkezelést, a harmadik felek felügyeletét, az incidensészlelést, a folytonosságot és a tesztelést. Így válik a kockázati nyilvántartás irányítóteremmé, nem pedig irattárrá.

RTS/ITS-felkészültség: kötelezettségeket szabályzatokhoz, ne ígéretekhez rendeljen

A „DORA RTS/ITS ellenőrzőlista” gyakorlati keresőkifejezés általában azt jelenti: „Milyen dokumentumokat várnak majd a felügyeletek?” A pénzügyi szervezeteknek kerülniük kell, hogy általános állításokkal ígérjenek megfelelést. Olyan leképezésre van szükségük, amely minden kötelezettséget szabályzathoz, kontrollhoz, felelőshöz és bizonyítékelemhez köt.

A Clarysec KKV Jogi és szabályozói megfelelési szabályzata egyszerű irányítási alapot rögzít:

„Az ügyvezetőnek egyszerű, strukturált megfelelőségi nyilvántartást kell fenntartania, amely felsorolja:”
Az „Irányítási követelmények” szakaszból, 5.1.1 szabályzati pont.

A DORA 2026 esetében a megfelelőségi nyilvántartásnak tartalmaznia kell:

• DORA-kötelezettség vagy RTS/ITS követelményterület.
• Alkalmazhatóság, beleértve az arányossági indoklást.
• Szabályzat- vagy eljáráshivatkozás.
• Kontrollgazda.
• Bizonyíték helye.
• Felülvizsgálati gyakoriság.
• Nyitott hiányosságok és helyesbítési határidő.
• Igazgatósági vagy vezetőségi jelentéstételi státusz.

Ez összhangban áll a Zenith Blueprint 14. lépésének megközelítésével: a szabályozási követelményeket IBIR-kontrollokhoz és szabályzatokhoz kell leképezni, hogy semmi ne essen át a réseken. A vezetés ahelyett, hogy azt kérdezné: „Megfelelünk a DORA-nak?”, azt kérdezheti: „Mely DORA bizonyítékelemek lejártak, mely kritikus beszállítókhoz hiányzik kilépési terv, és mely tesztelési tevékenységek nem eredményeztek még helyesbítési bizonyítékot?”

Harmadik félnek minősülő IKT-szolgáltatókkal kapcsolatos kockázat: koncentráció, helyettesíthetőség és alvállalkozók

A DORA megváltoztatta a beszállítókról folytatott párbeszédet a pénzügyi szolgáltatásokban. Már nem elég megkérdezni, hogy egy szolgáltató rendelkezik-e biztonsági tanúsítvánnyal, biztosítással vagy adatfeldolgozási szerződéssel. A pénzügyi szervezeteknek értékelniük kell, hogy a szolgáltató okoz-e koncentrációs kockázatot, reálisan lecserélhető-e, több kritikus szolgáltatás függ-e ugyanattól a beszállítótól vagy kapcsolt beszállítóktól, és az alvállalkozás további jogi vagy rezilienciakitettséget vezet-e be.

Ez az a kérdés, amely sok CISO-t ébren tart. Egy vállalat támaszkodhat egyetlen nagy felhőszolgáltatóra a tranzakciófeldolgozás, az adatelemzés, az ügyfélportálok és a belső együttműködés terén. Ha ez a szolgáltató elhúzódó kiesést, szabályozói vitát vagy alvállalkozói hibát szenved el, a kérdés nem csupán az, hogy „Van szerződésünk?” A kérdés az, hogy „Fenn tudjuk tartani a kritikus szolgáltatásokat, tudunk kommunikálni az ügyfelekkel, és tudjuk bizonyítani, hogy értettük a függőséget, mielőtt az meghibásodott?”

A Clarysec KKV Harmadik fél és beszállítói biztonsági szabályzata megadja az alapot:

„Beszállítói nyilvántartást kell fenntartani, és azt az adminisztratív vagy beszerzési kapcsolattartónak frissítenie kell. Tartalmaznia kell:”
Az „Irányítási követelmények” szakaszból, 5.4 szabályzati pont.

Vállalati programok esetében a Clarysec Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzata mélyebben kezeli a DORA-specifikus függőséget és helyettesíthetőséget:

„Beszállítói függőségi nyilvántartás: A VMO-nak naprakész nyilvántartást kell fenntartania valamennyi kritikus beszállítóról, beleértve a nyújtott szolgáltatások/termékek részleteit; azt, hogy a beszállító egyforrásos-e; az elérhető alternatív beszállítókat vagy a helyettesíthetőséget; a hatályos szerződéses feltételeket; valamint annak értékelését, hogy milyen hatása lenne, ha a beszállító meghibásodna vagy kompromittálódna. A nyilvántartásnak egyértelműen azonosítania kell a magas függőségi kockázatú beszállítókat, például azokat, amelyekre nincs gyors alternatíva.”
A „Végrehajtási követelmények” szakaszból, 6.1 szabályzati pont.

Ez az a beszállítói bizonyíték, amelyet a DORA-projektek gyakran elmulasztanak. A beszállítói nyilvántartás megmondja, ki a beszállító. A függőségi nyilvántartás megmondja, mi történik, ha a beszállító kiesik.

A Zenith Blueprint Kontrollok működésben szakaszának 23. lépése, a szervezeti kontrollok, gyakorlati munkafolyamatot ad a beszállítói felügyelethez. Teljes beszállítói lista összeállítását, a beszállítók rendszerekhez, adatokhoz vagy operatív kontrollhoz való hozzáférés alapján történő osztályozását, a biztonsági elvárások szerződésekbe építésének ellenőrzését, az alvállalkozói és ellátási láncbeli továbbadott kockázat kezelését, változáskezelési és nyomon követési eljárások meghatározását, valamint felhőszolgáltatás-értékelési folyamat kialakítását javasolja.

A Zenith Controls: The Cross-Compliance Guide az ISO/IEC 27002:2022 5.21 kontrollját, az információbiztonság kezelését az IKT-ellátási láncban, megelőző kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. A beszállítói kapcsolatok biztonságához és az azonosítás kiberbiztonsági koncepciójához kapcsolódik. Összekapcsolódik a biztonságos mérnöki gyakorlattal, a biztonságos kódolással, a hozzáférés-szabályozással, a biztonsági teszteléssel, a bizonyítékgyűjtéssel, a biztonságos fejlesztési életciklussal és a kiszervezett fejlesztéssel.

Pontosan ez a DORA szerinti harmadik fél felügyeletének valósága. A beszállítói kockázat nem csak beszerzési kérdés. Érinti az architektúrát, a fejlesztést, az incidensreagálást, a hozzáférés-szabályozást, az üzletmenet-folytonosságot és a jogi területet.

Keresztmegfelelési szempontból a Zenith Controls az IKT-ellátási lánc biztonságát a GDPR Articles 28 és 32 cikkeihez kapcsolja, mivel az adatfeldolgozókat és al-adatfeldolgozókat megfelelő technikai és szervezési intézkedésekkel kell kiválasztani és felügyelni. Támogatja a NIS2 ellátási lánc biztonsági elvárásait, beleértve az Article 21 szerinti kiberbiztonsági kockázatkezelési intézkedéseket és az Article 22 szerinti koordinált ellátási lánci kockázatértékeléseket. Erősen kapcsolódik a DORA Articles 28, 29 és 30 cikkeihez, ahol a harmadik félnek minősülő IKT-szolgáltatókkal kapcsolatos kockázat, a koncentrációs kockázat, a továbbkiszervezés és a szerződéses rendelkezések központi szerepet kapnak.

A támogató szabványok erősítik a bizonyítékrendszert. Az ISO/IEC 27036-3:2021 támogatja az IKT-beszerzés és beszállítóválasztás biztonságát. Az ISO/IEC 20243:2018 támogatja a megbízható technológiai termékintegritást és az ellátási lánc biztonságát. Az ISO/IEC 27001:2022 ezt kockázatkezeléshez és az Annex A beszállítói kontrolljaihoz kapcsolja.

Incidensjelentés: építse fel az eszkalációs láncot még az incidens előtt

A DORA szerinti incidensjelentés nem csupán értesítés benyújtását jelenti. Az IKT-val kapcsolatos incidensek észleléséről, besorolásáról, eszkalálásáról, kommunikációjáról és tanulságainak feldolgozásáról szól. A pénzügyi szervezeteknek folyamatokat kell fenntartaniuk az IKT-incidensek kezelésére és jelentésére, meghatározott szerepkörökkel, osztályozási kritériumokkal, értesítési útvonalakkal és incidens utáni elemzéssel.

A Clarysec KKV Incidenskezelési szabályzata az incidensreagálási határidőket a jogi követelményekhez kapcsolja:

„A reagálási határidőket, beleértve az adat-helyreállítási és értesítési kötelezettségeket, dokumentálni kell és össze kell hangolni a jogi követelményekkel, például a GDPR szerinti 72 órás személyesadat-sértés bejelentési követelménnyel.”
Az „Irányítási követelmények” szakaszból, 5.3.2 szabályzati pont.

Vállalati környezetekhez a Clarysec Incidenskezelési szabályzata hozzáadja a szabályozott adatokra vonatkozó eszkalációs nézőpontot:

„Ha egy incidens személyes adatok vagy más szabályozott adatok igazolt vagy valószínű kitettségét eredményezi, a jogi területnek és az adatvédelmi tisztviselőnek értékelnie kell az alábbiak alkalmazhatóságát:”
A „Szabályzat végrehajtási követelményei” szakaszból, 6.4.1 szabályzati pont.

Az idézet a kiváltó pontnál ér véget, és pontosan itt hibázik sok incidensfolyamat. Ha a kiváltó ok nem egyértelmű, a csapatok az értesítési kötelezettségekről vitáznak, miközben az óra már ketyeg.

A Zenith Blueprint Kontrollok működésben szakaszának 16. lépése, az Emberi kontrollok II, a munkatársak által kezdeményezett incidensbejelentést hangsúlyozza. A munkavállalóknak, vállalkozóknak és érdekelt feleknek tudniuk kell, hogyan ismerjék fel és jelentsék a potenciális biztonsági incidenseket egyszerű csatornákon, például külön postafiókon, portálon vagy telefonos bejelentővonalon keresztül. A Blueprint ezt a GDPR Article 33, a NIS2 Article 23 és a DORA Article 17 cikkéhez kapcsolja, mert a szabályozott jelentéstétel belső tudatossággal és eszkalációval kezdődik.

A Zenith Controls az ISO/IEC 27002:2022 5.24 kontrollját, az információbiztonsági incidenskezelés tervezését és előkészítését, helyesbítő kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, összhangban a reagálással és helyreállítással. Közvetlenül kapcsolódik az eseményértékeléshez, az incidensekből való tanuláshoz, a naplózáshoz és felügyelethez, a zavarközbeni biztonsághoz, az információbiztonsági folytonossághoz és a hatóságokkal való kapcsolattartáshoz. Az útmutató ezt a DORA Articles 17 to 23 cikkeihez kapcsolja az IKT-val kapcsolatos incidenskezelés, osztályozás, jelentés és önkéntes kiberfenyegetési értesítés tekintetében, a GDPR Articles 33 and 34 cikkeihez az incidensbejelentés tekintetében, valamint a NIS2 Article 23 incidensértesítéséhez.

Egy DORA-kompatibilis incidensfolyamatnak tartalmaznia kell:

• Egyértelmű incidensbejelentési csatornákat.
• Eseménytriázs- és osztályozási kritériumokat.
• Jelentős IKT-val kapcsolatos incidensekre vonatkozó eszkalációs munkafolyamatot.
• Jogi, adatvédelmi tisztviselői és felügyeleti értesítési döntési pontokat.
• Beszállítói incidensértesítési kiváltó okokat.
• Bizonyítékmegőrzési követelményeket.
• Felsővezetői és igazgatósági kommunikációs szabályokat.
• Incidens utáni felülvizsgálatot és tanulságok feldolgozását.
• Kapcsolódást a kockázati nyilvántartás frissítéséhez és a kontrollok helyesbítő intézkedéseihez.

A támogató szabványok struktúrát adnak. Az ISO/IEC 27035-1:2023 tervezési és előkészítési alapelveket ad az incidenskezeléshez. Az ISO/IEC 27035-2:2023 részletezi az incidenskezelési lépéseket. Az ISO/IEC 22320:2018 támogatja az irányítást, kontrollt és strukturált válságkommunikációt. Ez akkor válik fontossá, amikor egy IKT-kiesés ügyfeleket érintő válsággá alakul, és a szervezetnek meg kell mutatnia, hogy a döntések időben, koordináltan és bizonyítékokra alapozva születtek.

Digitális működési rezilienciatesztelés és TLPT: ne engedje, hogy a tesztből incidens legyen

A tesztelés az egyik leggyakrabban keresett DORA 2026 téma, mert egyszerre technikai és erősen irányítási jellegű. A pénzügyi szervezeteknek tesztelniük kell az IKT-rendszereket, kontrollokat és folyamatokat. A kijelölt szervezeteknél az olyan fejlett tesztelés, mint a TLPT, központi követelménnyé válik a DORA Article 26 alapján.

Az auditkérdés nem csupán az, hogy „Teszteltek?” Hanem az, hogy „A teszt kockázatalapú, engedélyezett, biztonságos, ahol szükséges független, helyesbített és rezilienciacélokhoz kapcsolt volt?”

A Clarysec vállalati Biztonsági tesztelési és red teaming szabályzata egyértelműen meghatározza a minimális tesztelési programot:

„Tesztelési típusok: A biztonsági tesztelési programnak legalább az alábbiakat kell tartalmaznia: (a) sérülékenységvizsgálat, amely hálózatok és alkalmazások automatizált heti vagy havi vizsgálataiból áll az ismert sérülékenységek azonosítására; (b) penetrációs tesztelés, amely meghatározott rendszerek vagy alkalmazások képzett tesztelők általi, manuális és mélyreható teszteléséből áll összetett gyengeségek azonosítására; és (c) red team gyakorlatok, amelyek valós támadások forgatókönyv-alapú szimulációiból állnak, beleértve a social engineeringet és más taktikákat, a szervezet észlelési és reagálási képességeinek egészben történő tesztelésére.”
A „Végrehajtási követelmények” szakaszból, 6.1 szabályzati pont.

Ez a híd a rutinszerű tesztelés és a TLPT-érettség között. A sérülékenységvizsgálat megtalálja az ismert gyengeségeket. A penetrációs tesztelés ellenőrzi a kihasználhatóságot. A red teaming rendszerként teszteli az észlelést és a reagálást. A TLPT-nek, ahol alkalmazandó, olyan irányított tesztelési programon belül kell helyet kapnia, amely tartalmazza a hatókörkontrollt, a biztonsági szabályokat, az éles környezeti kockázatkezelést, a bizonyítékrögzítést és a helyesbítő intézkedések nyomon követését.

A Zenith Blueprint Kontrollok működésben szakaszának 21. lépése az információs rendszerek audit és tesztelés alatti védelmét tárgyalja. Figyelmeztet arra, hogy az auditok, penetrációs tesztek, forenzikus felülvizsgálatok és operatív értékelések kockázatot vezethetnek be, mert emelt jogosultságú hozzáféréssel, behatoló eszközökkel vagy ideiglenes rendszerviselkedés-változásokkal járhatnak. A Blueprint ezt az aggályt a GDPR Article 32, a DORA digitális működési rezilienciatesztelési elvárásai, a NIS2 folytonossági szempontjai és a COBIT 2019 auditok és értékelések biztonságos végrehajtására vonatkozó gyakorlataihoz kapcsolja.

A Zenith Controls az ISO/IEC 27002:2022 5.35 kontrollját, az információbiztonság független felülvizsgálatát, megelőző és helyesbítő kontrollként térképezi fel, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást. Kapcsolódik a szabályzatoknak való megfeleléshez, a vezetői felelősségekhez, az incidensekből való tanuláshoz, a nyilvántartások védelméhez, az információ törléséhez, valamint a naplózáshoz és felügyelethez. A DORA esetében a releváns tesztelési kötelezettségek elsősorban az Articles 24 to 27 cikkek, beleértve az Article 26 szerinti TLPT-t. Ez támogatja a GDPR Article 32(1)(d) követelményét is, amely rendszeres tesztelést és értékelést ír elő a technikai és szervezési intézkedésekre, valamint a NIS2 Article 21 cikkét, amely kiberbiztonsági kockázatkezelési intézkedéseket követel meg.

Egy DORA TLPT-felkészültségi csomagnak tartalmaznia kell:

A DORA fő tanulsága, hogy a tesztelési bizonyíték nem állhat meg a jelentésnél. Az auditorok meg fogják kérdezni, hogy a megállapításokat kockázat alapján besorolták-e, kijelölték-e a felelősöket, megtörtént-e a helyesbítés és az újratesztelés. Azt is ellenőrizhetik, hogy a tesztelés lefedte-e a kritikus vagy fontos funkciókat, nem csak az internet felől elérhető eszközöket.

Üzletmenet-folytonosság és katasztrófa utáni helyreállítás: a rezilienciának működőképesnek kell lennie

A DORA digitális működési rezilienciáról szóló szabályozás. A helyreállítás éppolyan fontos, mint a megelőzés. Egy dokumentált IKT-kockázatkezelési keretrendszer nem segít, ha egy fizetési platform kiesése során kiderül, hogy a helyreállítási időcélokat soha nem tesztelték, a beszállítói kapcsolati láncok elavultak, és a válságkezelő csoport nem tud megállapodni abban, ki kommunikál az ügyfelekkel.

A Clarysec KKV Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzata egyértelmű alapot rögzít:

„A szervezetnek legalább évente tesztelnie kell mind a BCP, mind a DR képességeit. A teszteknek tartalmazniuk kell:”
A „Szabályzat végrehajtási követelményei” szakaszból, 6.4.1 szabályzati pont.

A vállalati Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat az üzleti hatással kezd:

„Üzleti hatásvizsgálatot (BIA) kell végezni legalább évente valamennyi kritikus üzleti egységre, és azt jelentős rendszer-, folyamat- vagy függőségi változások esetén felül kell vizsgálni. A BIA kimeneteinek meg kell határozniuk:”
Az „Irányítási követelmények” szakaszból, 5.2 szabályzati pont.

A DORA esetében a BIA-t össze kell kapcsolni az IKT-eszközökkel, beszállítókkal, incidensreagálással és teszteléssel. Ha a BIA az „ügyfélfizetéseket” kritikus funkcióként azonosítja, a beszállítói függőségi nyilvántartásnak azonosítania kell az ezt támogató feldolgozókat, felhőszolgáltatásokat és hálózati szolgáltatókat. A kockázati nyilvántartásnak tartalmaznia kell a kiesési forgatókönyveket. A tesztelési tervnek tartalmaznia kell a reziliencia ellenőrzését. Az incidensreagálási tervnek tartalmaznia kell az eszkalációt és a kommunikációt. A DR-tesztnek bizonyítékot kell előállítania, nem pusztán értekezleti jegyzőkönyvet.

Ez a visszakövethetőség alakítja a DORA-megfelelőséget operatív rezilienciarendszerré.

Keresztmegfelelés: egy bizonyítékrendszer, sok auditkérdés

A pénzügyi szervezetek ritkán találkoznak csak a DORA-val. Gyakran vannak GDPR-kötelezettségeik, NIS2-kitettségük, szerződéses biztonsági vállalásaik, ISO/IEC 27001:2022 célkitűzéseik, belső audit követelményeik, ügyfél-átvilágítási igényeik, SOC-elvárásaik és igazgatósági kockázati jelentéseik. A válasz nem külön bizonyítéksilók létrehozása. A válasz egy keresztmegfelelési bizonyítékmodell felépítése.

A Zenith Controls a Clarysec keresztmegfelelési iránytűje. Nem talál ki új kötelezettségeket. Hivatalos szabványokat és keretrendszereket térképez fel, hogy a szervezetek megértsék, egy kontrollterület hogyan támogat több megfelelési eredményt.

Ez költségvetési és irányítási szempontból fontos. A CISO el tudja magyarázni az igazgatóságnak, hogy az incidensosztályozás javítása támogatja a DORA-jelentéstételt, a GDPR incidensbejelentést, a NIS2 incidenskezelést és a belső rezilienciát. A beszerzési vezető indokolni tudja a beszállítói függőségek feltérképezését, mert az támogatja a DORA koncentrációs kockázatot, a GDPR adatfeldolgozói átvilágítást és a NIS2 ellátási lánc biztonságát. A tesztelési vezető meg tudja mutatni, hogy a red team gyakorlatok és a független felülvizsgálatok támogatják a DORA-tesztelést, a GDPR kontrollértékelést és a szélesebb körű bizonyosságot.

Auditnézőpont: hogyan fogják az értékelők tesztelni a DORA-bizonyítékokat

A DORA-felkészültség akkor válik valóssá, amikor valaki bizonyítékot kér. Különböző auditorok és értékelők ugyanazt a témát eltérő nézőpontból közelítik meg.

Egy ISO/IEC 27001:2022-orientált auditor az IBIR logikájával kezd: hatókör, kockázatértékelés, kockázatkezelés, Annex A kontrollalkalmazhatóság, belső audit, vezetőségi felülvizsgálat és bizonyíték arra, hogy a kontrollokat bevezették. Az IKT-ellátási lánc biztonságánál a szabályzatokat, beszállítói osztályozást, szerződéses záradékokat, átvilágítást és folyamatos felügyeletet fogja vizsgálni. Incidenskezelésnél a tervet, szerepköröket, eszkalációs útvonalakat, eszközöket és nyilvántartásokat ellenőrzi. Tesztelésnél tervezett időközöket, szükség szerinti függetlenséget, helyesbítő intézkedéseket és vezetőségi felülvizsgálati inputot vár.

Az ISO/IEC 19011:2018 szerinti auditnézőpont az audit végrehajtására fókuszál. A Zenith Controls szerint az IKT-ellátási lánc biztonságának auditmódszertana azt rögzíti, hogy az auditorok beszerzési szabályzatokat, ajánlatkérési sablonokat és beszállító-kezelési folyamatokat vizsgálnak annak ellenőrzésére, hogy az IKT-specifikus biztonsági követelmények a beszerzéstől a megsemmisítésig be vannak-e építve. Incidenskezelésnél az auditorok az incidensreagálási terv teljességét és legjobb gyakorlatokkal való összhangját vizsgálják. Független felülvizsgálatnál bizonyítékot keresnek arra, hogy független auditokat vagy felülvizsgálatokat elvégeztek.

Az ISO/IEC 27007:2020 nézőpont inkább IBIR-audit specifikus. A Zenith Controls megjegyzi, hogy az auditorok interjút készíthetnek beszerzési munkatársakkal, IT-biztonsági munkatársakkal és beszállítókezelőkkel, hogy értékeljék az IKT-ellátási lánc kontrolljainak megértését és végrehajtását. Incidens-előkészítésnél megerősítik, hogy létezik és működőképes egy incidensreagálási csoport. Független felülvizsgálatnál ellenőrzik, hogy a belső audit program lefedi-e a teljes IBIR alkalmazási területét, és megfelelő erőforrásokkal rendelkezik-e.

Egy NIST SP 800-115 alapú tesztelési értékelő a sérülékenységértékelési és penetrációs tesztelési módszertanra fog összpontosítani. Vizsgálhatja, hogy dokumentált-e a teszt hatóköre, a végrehajtási szabályok, a megállapítások, a súlyossági besorolások, a helyesbítő intézkedések és az újratesztelés. A DORA TLPT esetében ez azt jelenti, hogy az értékelő nem fog megelégedni egy red team prezentációval. Irányítási, biztonsági, technikai mélységi és lezárási bizonyítékot fog kérni.

Egy COBIT 2019 vagy ISACA-stílusú auditor azt fogja kérdezni, teljesülnek-e az irányítási célkitűzések: ki a folyamat felelőse, hogyan mérik a teljesítményt, hogyan hagyják jóvá a kivételeket, és hogyan kap bizonyosságot a vezetés.

A gyakorlati DORA 2026 felkészültségi ellenőrzőlista

Használja ezt az ellenőrzőlistát munkaszintű alapként arra, hogy a DORA-kereséseket intézkedésekké alakítsa.

Irányítás és RTS/ITS-leképezés

• Tartson fenn DORA megfelelőségi nyilvántartást kötelezettségterülettel, alkalmazhatósággal, felelőssel, bizonyítékkal, felülvizsgálati gyakorisággal és hiányossági státusszal.
• Képezze le a DORA-követelményeket szabályzatokra, nyilvántartásokra, kontrollokra és vezetői jelentésekre.
• Határozza meg az arányossági indoklást az egyszerűsített vagy skálázott IKT-kockázatkezeléshez, ahol alkalmazandó.
• Jelöljön ki felsővezetői elszámoltathatóságot az IKT-kockázatért, az incidensjelentésért, a harmadik felek felügyeletéért és a tesztelésért.
• Foglalja bele a DORA-státuszt a vezetőségi felülvizsgálatba és az igazgatósági kockázati jelentésbe.

IKT-kockázatkezelés

• Tartson fenn IKT-kockázati nyilvántartást leírással, valószínűséggel, hatással, pontszámmal, felelőssel és kockázatkezelési tervvel.
• Kapcsolja a kockázatokat kritikus vagy fontos funkciókhoz.
• Kapcsolja a kockázatokat IKT-eszközökhöz, beszállítókhoz és folyamatokhoz.
• Vizsgálja felül a kockázatokat jelentős incidensek, beszállítói változások, technológiai változások vagy tesztmegállapítások után.
• Kövesse nyomon a kockázatkezelési intézkedéseket lezárásig vagy formális kockázatelfogadásig.

Harmadik félnek minősülő IKT-szolgáltatók felügyelete

• Tartson fenn beszállítói nyilvántartást és beszállítói függőségi nyilvántartást.
• Azonosítsa a kritikus vagy fontos funkciókat támogató beszállítókat.
• Értékelje az egyforrásos beszállítókat és a helyettesíthetőséget.
• Vizsgálja felül az alvállalkozókat és továbbkiszervezési megállapodásokat.
• Építse be a biztonsági, hozzáférési, incidensjelentési, auditálási és kilépési záradékokat a szerződésekbe.
• A kritikus beszállítókat legalább évente vagy lényeges változások után kövesse nyomon.
• Tartson fenn kilépési és készenléti terveket a magas függőségi kockázatú szolgáltatókra.

Incidenskezelés és jelentés

• Tartson fenn incidensreagálási eljárásokat egyértelmű szerepkörökkel és eszkalációs útvonalakkal.
• Határozza meg az IKT-incidensek osztályozási kritériumait.
• Hangolja össze a DORA jelentési kiváltó okait a GDPR, NIS2 és szerződéses értesítési kötelezettségekkel.
• Képezze a munkavállalókat és vállalkozókat az incidensbejelentési csatornákról.
• Tartson fenn incidensnaplókat, döntési nyilvántartásokat és bizonyítékokat.
• Végezzen incidens utáni felülvizsgálatokat, és frissítse a kockázatokat és kontrollokat.

Tesztelés, red teaming és TLPT

• Tartson fenn kockázatalapú tesztelési naptárat.
• Végezzen sérülékenységvizsgálatokat és penetrációs teszteket meghatározott időközönként.
• Használjon forgatókönyv-alapú red team gyakorlatokat az észlelés és reagálás tesztelésére.
• TLPT-felkészültséghez határozza meg a hatókört, a végrehajtási szabályokat, a biztonsági kontrollokat és a beszállítói koordinációt.
• Védje az éles rendszereket a tesztelés alatt.
• Kövesse nyomon a megállapításokat, a helyesbítő intézkedéseket, az újratesztelést és a tanulságokat.
• Jelentse a tesztelési eredményeket a vezetésnek.

Folytonosság és helyreállítás

• Végezzen éves BIA-t a kritikus üzleti egységekre, és jelentős változások után frissítse.
• Határozza meg a helyreállítási célokat a kritikus funkciókra és támogató IKT-szolgáltatásokra.
• Legalább évente tesztelje a BCP és DR képességeket.
• Tartalmazzon beszállítói kiesési és kiberincidens-forgatókönyveket.
• Őrizze meg a tesztbizonyítékokat, hiányosságokat, helyesbítő intézkedéseket és újratesztelési eredményeket.
• Hangolja össze a folytonossági terveket az incidensreagálással és a válságkommunikációval.

Hogyan segít a Clarysec a pénzügyi szervezeteknek eljutni a keresési találatoktól az auditra kész bizonyítékokig

A DORA 2026 felkészültség nem érhető el egy ellenőrzőlista letöltésével és azzal a reménnyel, hogy a szervezet később majd kitölti a hiányosságokat. Strukturált működési modellre van szükség, amely összekapcsolja a kockázatokat, beszállítókat, incidenseket, tesztelést, folytonosságot és auditbizonyítékokat.

A Clarysec megközelítése három réteget egyesít.

Először, a Zenith Blueprint adja a bevezetési ütemtervet. A 14. lépés segíti a szervezeteket a szabályozási követelmények kockázatkezeléshez és szabályzatokhoz való kereszthivatkozásában. A 16. lépés erősíti a munkatársak által kezdeményezett incidensbejelentést. A 21. lépés biztosítja, hogy az auditok és tesztek ne veszélyeztessék az éles rendszereket. A 23. lépés a beszállítói felügyeletet gyakorlati munkafolyamattá alakítja, amely lefedi az osztályozást, szerződéseket, alvállalkozókat, nyomon követést és felhőértékelést.

Másodszor, a Clarysec szabályzatok működésre kész irányítást adnak. A Kockázatkezelési szabályzat, a Jogi és szabályozói megfelelési szabályzat, a Harmadik fél és beszállítói biztonsági szabályzat, a Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat, az Incidenskezelési szabályzat, a Biztonsági tesztelési és red teaming szabályzat, valamint az Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat konkrét szabályzati pontokat, felelősségi modelleket és bizonyítékelvárásokat ad a csapatoknak.

Harmadszor, a Zenith Controls biztosítja a keresztmegfelelési térképet. Megmutatja, hogyan kapcsolódik az IKT-ellátási lánc biztonsága, az incidenskezelés tervezése és a független felülvizsgálat a DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 és NIST tesztelési gyakorlatokhoz.

Az eredmény egy olyan DORA megfelelőségi program, amely audit során igazolható, és valós incidens, beszállítói hiba vagy rezilienciateszt esetén is hasznos.

Következő lépés: építse fel DORA bizonyítékcsomagját a következő auditkérés előtt

Ha csapata még mindig a „DORA RTS/ITS ellenőrzőlista”, „DORA IKT-kockázatkezelési sablon”, „DORA harmadik fél felügyelet” vagy „DORA TLPT követelmények” kifejezésekre keres, a következő lépés az, hogy ezeket a kereséseket irányított bizonyítékokká alakítsa.

Kezdje négy intézkedéssel ezen a héten:

1. Hozza létre vagy frissítse DORA megfelelőségi nyilvántartását a Clarysec szabályzatmodell alapján.
2. Válasszon ki egy kritikus funkciót, és kövesse végig a kockázati nyilvántartáson, a beszállítói függőségi nyilvántartáson, az incidens-munkafolyamaton, a BIA-n és a tesztelési terven.
3. Vizsgálja felül az öt legfontosabb IKT-beszállítót helyettesíthetőség, alvállalkozók, incidenszáradékok és kilépési lehetőségek szempontjából.
4. Építsen tesztelési bizonyítékcsomagot hatókörrel, engedélyezéssel, eredményekkel, helyesbítő intézkedésekkel és újrateszteléssel.

A Clarysec segíthet ennek bevezetésében a Zenith Blueprint, a szabályzatsablonok és a Zenith Controls használatával, hogy DORA 2026 programja gyakorlati, arányos és auditra kész legyen.