DORA tesztelési program: tesztek leképezése ISO 27001 auditbizonyítékokra

2026 februárja van. Egy közepes méretű pénzforgalmi intézmény információbiztonsági vezetőjének két nap múlva igazgatósági ülése lesz, hat hét múlva ISO/IEC 27001:2022 felügyeleti auditja, a megfelelőségi postafiókban pedig ott vár egy DORA szerinti felügyeleti megkeresés.

A felügyeleti hatóság nem látványos kiberbiztonsági stratégiát kér. A megkeresés gyakorlati:

• Mutassák be a 2026. évi digitális működési reziliencia tesztelési programot.
• Mutassák be, mely tesztek fedik le a kritikus vagy fontos funkciókat.
• Igazolják, hogyan történik a megállapítások helyesbítése és újratesztelése.
• Bizonyítsák a vezető testület felügyeletét.
• Magyarázzák el, hogyan vonják be az IKT harmadik fél szolgáltatókat.
• Adjanak át nyilvántartásokat a sérülékenységértékelésekről, forgatókönyv-alapú tesztekről, teljesítmény- és kapacitástesztelésről, valamint penetrációs tesztelésről.

Az információbiztonsági vezető négy mappát nyit meg. A sérülékenységvizsgálatok a SOC jegykezelő rendszerében vannak. Az asztali gyakorlatok jegyzetei egy megosztott meghajtón találhatók. A terheléses tesztek eredményei a mérnöki csapatnál vannak. A penetrációs tesztjelentések a jogi terület korlátozott hozzáférésű adattárában vannak. A helyesbítő intézkedések nyomon követése megoszlik a Jira, az e-mail és a tavalyi ISO audit céljára létrehozott táblázat között.

Semmi sem fiktív. A munka nagy része értékes. Ez azonban még nem irányított, DORA szerinti digitális működési reziliencia tesztelési program. Ez tesztek gyűjteménye.

2026-ban ez a különbség lényeges. A DORA 2025. január 17-től alkalmazandó, és egységes uniós keretet hoz létre a digitális működési rezilienciára az IKT-kockázatkezelés, incidensjelentés, rezilienciatesztelés, kiberfenyegetésekkel és sérülékenységekkel kapcsolatos információmegosztás, IKT harmadik fél kockázatkezelés, szerződéses követelmények és a kritikus IKT harmadik fél szolgáltatók felügyelete területén. Széles körű pénzügyi szervezetekre vonatkozik, többek között hitelintézetekre, pénzforgalmi intézményekre, befektetési vállalkozásokra, kriptoeszköz-szolgáltatókra, biztosítókra és más szabályozott szervezetekre. A DORA egyben ágazatspecifikus uniós jogi aktusként is működik azon pénzügyi szervezetek esetében, amelyekre egyébként egyenértékű NIS2 kiberbiztonsági kötelezettségek vonatkoznának.

Az igazgatóságok, információbiztonsági vezetők, megfelelőségi vezetők és IKT-szolgáltatók számára a gyakorlati kérdés már nem az, hogy történik-e tesztelés. A kérdés az, hogy a tesztelés tervezett, kockázatalapú, bizonyítékokkal alátámasztott, helyesbített, felülvizsgált és újrahasznosítható-e a DORA és az ISO/IEC 27001:2022 követelményei között.

A Clarysec működési modellje pontosan erre a problémára készült. A Zenith Blueprint: An Auditor’s 30-Step Roadmap, a Clarysec ISO-val összhangban álló szabályzatcsomagja és a Zenith Controls: The Cross-Compliance Guide használatával a szervezetek a szétszórt rezilienciatevékenységeket olyan kontrollált éves tesztkatalógussá alakíthatják, amely megfelel a felügyeleti hatóságok, auditorok, ügyfelek és igazgatóságok elvárásainak.

Miért teszi a DORA a tesztelést irányítási kérdéssé?

A DORA egyértelműen meghatározza a vezetői elszámoltathatóságot. Az Article 5 az IKT-kockázatkezelésért való felelősséget a vezető testületre telepíti. Az Article 6 megalapozott, átfogó és megfelelően dokumentált, a szervezet általános kockázatkezelési rendszerébe integrált IKT-kockázatkezelési keretrendszert ír elő. Az Article 4 az arányosságot rögzíti, vagyis a követelményeket a méret, az általános kockázati profil, valamint a szolgáltatások, tevékenységek és működés jellege, nagyságrendje és összetettsége alapján kell alkalmazni.

Ez a digitális működési reziliencia tesztelését többé teszi technikai feladatnál. Olyan bizonyítékká válik, amely igazolja, hogy a vezető testület érti a kockázatokat, jóváhagyott stratégiával rendelkezik, érdemi jelentéstételt kap, és előmozdítja a helyesbítő intézkedéseket.

Az ISO/IEC 27001:2022 hasonló irányítási rendszer logikát alkalmaz. A 4.1–4.4 pontok megkövetelik, hogy a szervezet értse a kontextusát, az érdekelt feleket, a jogi és szerződéses kötelezettségeket, a hatókört, az interfészeket és a függőségeket. Az 5.1–5.3 pontok vezetői elkötelezettséget, szabályzati összhangot, erőforrásokat, kommunikációt, kijelölt felelősségeket és felső vezetés felé történő jelentéstételt írnak elő. A 6.1 pont információbiztonsági kockázatértékelést és kockázatkezelést követel meg.

Egy DORA tesztelési programnak ezért össze kell kapcsolnia:

• az üzleti szolgáltatásokat és a kritikus vagy fontos funkciókat;
• az IKT-eszközöket, adatokat és harmadik fél függőségeket;
• a kockázatértékelést, a kockázattulajdonosokat és a kockázatkezelési terveket;
• a teszttípusokat, gyakoriságot és kiváltó okokat;
• az engedélyezést, függetlenséget és végrehajtási szabályokat;
• a megállapításokat, helyesbítési határidőket és újratesztelést;
• a bizonyítékok megőrzését és a hozzáférés-szabályozást;
• a vezetői jelentéstételt és a folyamatos fejlesztést.

Kisebb vagy alacsonyabb kockázatú pénzügyi szervezetek számára az Article 16 egyszerűsített IKT-kockázatkezelési keretrendszert biztosít, de az egyszerűsített nem jelent informális működést. Még a méretezett programoknak is dokumentált IKT-kockázatkezelésre, felügyeletre, reziliens rendszerekre, az IKT-kockázati források és rendellenességek azonosítására, kulcsfontosságú IKT harmadik fél függőségekre, folytonossági és helyreállítási intézkedésekre, rendszeres tesztelésre és a tanulságok feldolgozására van szükségük.

Más szóval: a DORA nem a tesztek mennyiségét díjazza. Az irányított, kockázatalapú tesztelést értékeli, amely bizonyítja a legfontosabb szolgáltatások rezilienciáját.

Mi tartozik egy 2026-os DORA tesztelési programba?

Egy érett DORA tesztelési programnak éves tesztkatalógusként kell működnie. Nem korlátozódhat egyetlen éves penetrációs tesztre vagy sérülékenységvizsgálati exportok halmazára. Alapvető és fejlett teszteket is tartalmaznia kell, amelyeket kockázat, szolgáltatáskritikusság, szabályozási kötelezettségek, beszállítói függőségek, jelentős változások és korábbi megállapítások alapján terveznek.

A DORA Article 24 létrehozza a digitális működési reziliencia tesztelési programját. Az Article 25 többféle tesztet ír le, többek között sérülékenységértékeléseket és vizsgálatokat, nyílt forrású elemzéseket, hálózatbiztonsági értékeléseket, hiányelemzéseket, fizikai biztonsági felülvizsgálatokat, kérdőíveket, vizsgálószoftver-megoldásokat, ahol megvalósítható, forráskód-felülvizsgálatokat, forgatókönyv-alapú teszteket, kompatibilitási tesztelést, teljesítménytesztelést, végponttól végpontig tartó tesztelést és penetrációs tesztelést. Az Article 26 a hatáskörrel rendelkező hatóságok által kijelölt pénzügyi szervezetek számára fenyegetésvezérelt penetrációs tesztelést ad hozzá.

A legtöbb szervezetnél a gyakorlati katalógus négy tesztelési család köré épül.

A Clarysec Biztonsági tesztelési és Red-Teaming szabályzata erős szabályzati horgonyt ad ehhez a katalógushoz:

“Teszttípusok: A biztonsági tesztelési programnak legalább a következőket kell tartalmaznia: (a) sérülékenységvizsgálat, amely hálózatok és alkalmazások automatizált heti vagy havi vizsgálatábó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, mélyreható teszteléséből áll az összetett gyengeségek azonosítására; és (c) red-teaming gyakorlatok, amelyek valós támadások forgatókönyv-alapú szimulációiból állnak, beleértve a szociális manipulációt és más taktikákat, a szervezet egészének észlelési és reagálási képességeinek tesztelésére.”

Ugyanez a szabályzat rendszeres ütemezést ír elő:

“Tesztelési ütemezés: A szervezetnek rendszeres ütemezés szerint kell biztonsági tesztelést végeznie. A kulcsfontosságú, internet felől elérhető rendszereket és kritikus belső alkalmazásokat legalább évente penetrációs tesztelésnek kell alávetni. A magas kockázatú változások, például új kritikus rendszer bevezetése vagy jelentős frissítések esetén eseti tesztelés szükséges az éles indulás előtt és/vagy röviddel azt követően.”

Ez kritikus a DORA szempontjából. Egy statikus éves terv nem elegendő, ha a szervezet új fizetési átjárót vezet be, alapvető rendszert migrál felhőbe, menedzselt szolgáltatót vált, vagy új ügyfél-hitelesítési folyamatot ad ki. A magas kockázatú változásnak további tesztelést kell kiváltania.

Az éves tesztkatalógus legyen az egyetlen hiteles forrás

A DORA és az ISO/IEC 27001:2022 követelményeinek leghatékonyabb teljesítési módja egyetlen kontrollált éves tesztkatalógus létrehozása. Ez működhet GRC platformon, jegykezelési munkafolyamatban vagy kontrollált táblázatban. A formátumnál fontosabb a visszakövethetőség.

Minden tesztnek öt auditkérdésre kell választ adnia:

1. Melyik szolgáltatást, eszközt, beszállítót, alkalmazást vagy folyamatot tesztelték?
2. Mely kockázat, kötelezettség vagy kontrollkövetelmény váltotta ki a tesztet?
3. Ki engedélyezte és ki végezte el a tesztet?
4. Milyen megállapításokat azonosítottak, fogadtak el, helyesbítettek vagy halasztottak el?
5. Milyen bizonyíték igazolja, hogy a teszt megtörtént, és az eredményt felülvizsgálták?

Egy gyakorlati, Clarysec-stílusú katalógus a következő mezőket tartalmazza.

A Clarysec Audit- és megfelelőségmonitorozási szabályzat-sme - SME tömör irányítási szabályt ad, amely illeszkedik ehhez a struktúrához:

“Minden auditnak meghatározott hatókört, célkitűzéseket, felelős személyeket és szükséges bizonyítékokat kell tartalmaznia.”

Bár ez auditokra készült, ugyanennek a szabálynak a rezilienciatesztekre is vonatkoznia kell. Ha egy sérülékenységvizsgálatnak, asztali gyakorlatnak, átkapcsolási szimulációnak vagy penetrációs tesztnek nincs meghatározott hatóköre, célja, felelőse és szükséges bizonyítéka, akkor mind a DORA, mind az ISO auditvizsgálat során gyenge lesz.

Ugyanez a szabályzat kimondja:

“A bizonyítékokat legalább két évig, vagy tanúsítási vagy ügyfélszerződések által előírt esetben hosszabb ideig kell megőrizni.”

A DORA hatálya alá tartozó pénzügyi szervezetek és IKT-szolgáltatók esetében a két évet minimumnak kell tekinteni. A szerződéses kötelezettségek, felügyeleti elvárások, tanúsítási ciklusok és incidensvizsgálatok hosszabb megőrzést is előírhatnak.

DORA teszttípusok leképezése ISO 27001 bizonyítékokra

Egy integrált program ereje abban áll, hogy egyetlen teszt több kötelezettséget is teljesíthet. A kulcs a bizonyítékok megfelelő címkézése és az IBIR-hez való kapcsolása.

A Zenith Blueprint ezt az Audit, felülvizsgálat és fejlesztés fázis 24. lépésében magyarázza el:

“Az SoA-nak összhangban kell lennie a kockázati nyilvántartással és a kockázatkezelési tervvel. Ellenőrizze még egyszer, hogy minden, kockázatkezelésként kiválasztott kontroll „Alkalmazható” jelölést kapott-e az SoA-ban.”

Egy DORA tesztelési program esetében a tesztkatalógus hidat képez a kockázatkezelés és az operatív bizonyítékok között. Az alkalmazhatósági nyilatkozat nem állíthatja, hogy egy kontroll alkalmazandó, miközben a tesztbizonyíték máshol, leképezetlenül és kezeletlenül található.

Ez a táblázat segít az információbiztonsági vezetőnek megválaszolni a vezérigazgató gyakori kérdését: „Elegendők-e az ISO szerinti penetrációs tesztjeink és sérülékenységvizsgálataink a DORA-hoz?”

A válasz: részei lehetnek a DORA megfelelésnek, de csak akkor, ha kockázatalapúak, kritikus vagy fontos funkciókhoz kapcsolódnak, szabályzat irányítja őket, helyesbítő intézkedéseken keresztül követik őket, és jelentik azokat a vezetésnek.

Sérülékenységértékelések: folyamatos bizonyíték, nem pusztán vizsgálati kimenet

A sérülékenységértékelés gyakran a legkönnyebben végrehajtható és a legkönnyebben félrekezelhető tesztelési tevékenység. Sok szervezet képes vizsgálati jelentéseket előállítani. Kevesebb tudja bizonyítani, hogy a vizsgálatok a megfelelő eszközöket fedik le, priorizálják a kritikus szolgáltatásokat, időben helyesbítő intézkedéseket indítanak, és táplálják a kockázatkezelési döntéseket.

A Clarysec Sérülékenység- és javításkezelési szabályzat-sme - SME megfelelő célkitűzéssel indul:

“Az ismert sérülékenységek időben és következetes módon történő azonosítása és értékelése valamennyi IT-eszközön”

A DORA szempontjából ez támogatja az IKT-kockázati források azonosítását, a reziliens és frissített rendszereket, a felügyeletet, az anomáliadetektálást és a folyamatos fejlesztést. Az ISO/IEC 27001:2022 esetében közvetlenül a 8.8 Műszaki sérülékenységek kezelése ponthoz kapcsolódik, és támaszkodik az 5.9 Információk és más kapcsolódó eszközök nyilvántartása, a 8.16 Megfigyelési tevékenységek és a 8.32 Változáskezelés pontokra is.

Egy erős sérülékenységértékelési nyilvántartásnak tartalmaznia kell:

• a hatókör meghatározásához használt eszköznyilvántartási pillanatképet;
• a vizsgálat dátumát, eszközét és hitelesített vagy nem hitelesített módszerét;
• a kizárásokat és az üzleti indoklást;
• a megállapításokat súlyosság, kihasználhatóság és üzleti szolgáltatás szerint;
• a kritikus vagy fontos funkciókhoz és adattípusokhoz való leképezést;
• a jegyhivatkozásokat és a kockázattulajdonost;
• a helyesbítési SLA-t és határidőt;
• az újratesztelés eredményét;
• a kivételeket maradványkockázati jóváhagyással.

A Zenith Controls a 8.8 Műszaki sérülékenységek kezelése pontot az azonosítás, értékelés, priorizálás és helyesbítő intézkedések nyomon követésének alapvető bizonyítékterületeként kezeli. Azt is megmutatja, miért vizsgálják az auditorok a szomszédos folyamatokat. Ha az eszköznyilvántartás hiányos, a sérülékenységi lefedettség is hiányos. Ha a változáskezelést megkerülik, a javítások telepítése új működési kockázatot hozhat létre. Ha a monitorozás gyenge, a kihasználási kísérleteket nem feltétlenül észlelik.

Forgatókönyv-alapú tesztek: döntéshozatal bizonyítása a valós incidens előtt

A forgatókönyv-alapú tesztek teszik láthatóvá a működési rezilienciát a vezetők számára. Egy zsarolóvírusos asztali gyakorlat, felhőrégió-kiesési szimuláció, emelt jogosultságú hozzáférés kompromittálódásának gyakorlata vagy kritikus IKT-szolgáltató hibáját modellező forgatókönyv olyan gyengeségeket tár fel, amelyeket egy vizsgálat nem tud.

A DORA Article 17–20 formális IKT-val kapcsolatos incidens-életciklust ír elő: észlelés, kezelés, értesítés, nyilvántartásba vétel, megfigyelés, nyomon követés, gyökérok dokumentálása, helyesbítés, súlyossági besorolás, szerepkörök kijelölése, jelentős incidensek eszkalációja és jelentéstétel az előírt szakaszokban. Ha az ügyfelek pénzügyi érdekei érintettek, az ügyfeleket indokolatlan késedelem nélkül tájékoztatni kell.

A NIS2 hasonló sürgősséget ír elő a hatálya alá tartozó szervezeteknek, beleértve a korai figyelmeztetést, értesítést, közbenső jelentést és zárójelentést. A hatálya alá tartozó pénzügyi szervezetek esetében a DORA az egyenértékű kiberbiztonsági kockázatkezelési és jelentéstételi kötelezettségek ágazatspecifikus jogi aktusa. Az IKT-szolgáltatóknak, SaaS platformoknak, MSP-knek és MSSP-knek továbbra is ellenőrizniük kell, hogy közvetlenül a NIS2 hatálya alá tartoznak-e, vagy szabályozott ügyfelek szerződés alapján vonják be őket a DORA szerinti bizonyossági követelményekbe.

A Zenith Blueprint Kontrollok működésben fázisának 23. lépése gyakorlati bizonyítékmodellt ad:

“Válasszon ki egy közelmúltbeli eseményt, vagy végezzen asztali gyakorlatot a terv ellenőrzésére. Rögzítsen és naplózzon minden döntést, szerepkört és kommunikációt (5.26), és frissítse a tervet a levont tanulságokkal (5.27).”

Egy DORA forgatókönyv-alapú tesztnek auditálható nyilvántartásokat kell előállítania, nem csupán értekezleti jegyzeteket:

• forgatókönyv-összefoglaló és célkitűzések;
• résztvevők és szerepkörök, beleértve a jogi, kommunikációs, IT, SOC, üzleti szolgáltatásgazdai és beszállítói kapcsolattartókat;
• eseménybefecskendezések és döntések idővonala;
• osztályozási döntés és jelentési küszöbérték-elemzés;
• belső és külső kommunikációs tervezetek;
• bizonyítékmegőrzési intézkedések;
• tanulságok;
• intézkedésgazdák és határidők;
• frissített incidens-, folytonossági vagy kommunikációs eljárások.

A Clarysec Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat-sme - SME megerősíti az éves tesztelési elvárást:

“A szervezetnek legalább évente tesztelnie kell mind a BCP-, mind a DR-képességeit. A teszteknek tartalmazniuk kell:”

A tesztkatalógusnak ezt a kötelezettséget konkrét gyakorlatokká kell alakítania, például válságkezelési asztali gyakorlattá, biztonsági mentésből történő helyreállítási tesztté, felhőalapú átkapcsolási tesztté, kapcsolati lánc tesztté és beszállítói zavar szimulációvá.

Teljesítmény-, kapacitás- és helyreállítási tesztek: az elhanyagolt rezilienciabizonyíték

A teljesítménytesztelést gyakran mérnöki kérdésként kezelik. A DORA szerint azonban rezilienciabizonyítékká válik.

Egy kereskedési platformnak, fizetési szolgáltatásnak, kárigénykezelő rendszernek, identitásplatformnak vagy ügyfélportálnak nem kell kibertámadás ahhoz, hogy az ügyfelek számára hibásan működjön. A kapacitáskimerülés, a sorok telítődése, az adatbázis-szűk keresztmetszetek, a hibásan konfigurált autoscaling vagy a meghibásodott átkapcsolás ugyanazt a működési zavart okozhatja, mint egy biztonsági incidens.

Az ISO/IEC 27001:2022 Annex A 8.6 Kapacitáskezelés az elsődleges horgony. A bizonyíték tartalmazhat terheléses tesztelést, stressztesztelést, szolgáltatásdegradációs tesztelést, infrastruktúra-küszöbértékek ellenőrzését, biztonsági mentésből történő helyreállítási teszteket és átkapcsolási szimulációkat.

Egy jó teljesítmény- és kapacitásteszt-nyilvántartásnak rögzítenie kell:

• az alapértelmezett normál terhelési és csúcsterhelési feltételezéseket;
• a tesztelt kritikus tranzakciós útvonalakat;
• a tesztelt infrastruktúra- és felhőkorlátokat;
• a monitorozási irányítópultokat és riasztási küszöbértékeket;
• a hibamódokat, például sorok telítődését vagy adatbázis-szűk keresztmetszeteket;
• az RTO és RPO relevanciáját, ha átkapcsolást vagy helyreállítást tesztelnek;
• a küszöbértékek átlépésének üzleti hatását;
• a helyesbítő intézkedéseket, skálázási döntéseket vagy architekturális módosításokat;
• a fennmaradó kapacitáskockázat vezetői elfogadását.

A Zenith Blueprint 23. lépése összekapcsolja a helyreállítási elvárásokat a bizonyítékokkal:

“Ellenőrizze, hogy a kritikus rendszerek helyreállítási időcéljai (RTO) és helyreállítási pont célértékei (RPO) összhangban vannak-e az üzletmenet-folytonossági elvárásokkal (5.30). Végezzen legalább egy technikai helyreállítási tesztet vagy átkapcsolási szimulációt, és dokumentálja az eredményeket.”

Ez a különbség aközött, hogy „vannak biztonsági mentéseink”, és aközött, hogy bizonyítottan helyreállítottak egy kritikus szolgáltatást a megállapított tűréshatáron belül, dokumentált eredményekkel és vezetői láthatósággal.

Penetrációs tesztelés és red teaming: erős bizonyítékhoz erős kontroll kell

A penetrációs tesztelés nagy értékű bizonyíték, de működési kockázatot is hordoz. A nem megfelelően irányított tesztelés érintheti az éles rendszereket, érzékeny adatokat tárhat fel, kontrollálatlan riasztásokat válthat ki, jogi problémákat okozhat vagy zavarhatja az ügyfeleket.

Az Alkalmazásbiztonsági követelmények szabályzata-sme - SME egyértelmű kiadási kaput állít fel:

“Bevezetés előtt minden alkalmazást biztonsági tesztelésnek kell alávetni a fent felsorolt előírt alapbeállítási funkciók ellenőrzésére.”

Kritikus alkalmazások esetében ennek be kell kerülnie a DORA katalógusba előéles biztonsági tesztelésként, magas kockázatú változásokat követő éles indulás utáni ellenőrzésként és kitettség, illetve kritikusság alapján végzett időszakos penetrációs tesztelésként.

A Biztonsági tesztelési és Red-Teaming szabályzat megerősíti a helyesbítési láncot:

“Megállapítások helyesbítése: Minden azonosított sérülékenységet vagy gyengeséget súlyossági besorolással ellátott megállapítási jelentésben kell dokumentálni. A jelentés kézhezvételét követően a rendszergazdák felelősek határidőket tartalmazó helyesbítési terv létrehozásáért; például a kritikus megállapításokat 30 napon belül, a magas súlyosságú megállapításokat 60 napon belül kell helyesbíteni, a szervezet Sérülékenység- és javításkezelési szabályzatával összhangban. Az STC köteles nyomon követni a helyesbítés előrehaladását. Újratesztelést kell végezni annak megerősítésére, hogy a kritikus problémákat megoldották vagy megfelelően mérsékelték.”

Ugyanez a szabályzat meghatározza a jelentéstételi elvárásokat:

“Jelentéstétel: Minden teszt lezárásakor formális jelentést kell kiadni. Penetrációs tesztelés esetén a jelentésnek vezetői összefoglalót, módszertant, valamint alátámasztó bizonyítékokkal és ajánlásokkal ellátott részletes megállapításokat kell tartalmaznia.”

A Zenith Blueprint 21. lépése az audit és tesztelés alatti védelemre is rámutat:

“Dokumentált jóváhagyás nélkül, amelyet a rendszergazdák vagy az érintett érdekelt felek adnak, sem teszt, sem audit nem kezdhető meg.”

A végrehajtási szabályok, tesztablakok, vészhelyzeti kapcsolattartók, ideiglenes hozzáférés, adatkezelés, naplózás, visszaállítási eljárások és jogi jóváhagyások nem bürokratikus terhek. Ezek rezilienciát biztosító védelmi intézkedések.

Vonja be az IKT harmadik fél szolgáltatókat, mielőtt a teszt megbukik

A DORA az IKT harmadik fél kockázatot a reziliencia központi kérdésévé teszi. Az Article 28 előírja, hogy a pénzügyi szervezetek az IKT-kockázatkezelési keretrendszeren belül kezeljék az IKT harmadik fél kockázatot, maradjanak felelősek az IKT-szolgáltatások igénybevételekor, tartsanak fenn információs nyilvántartást, jelentsenek bizonyos megállapodásokat, végezzenek szerződéskötés előtti értékeléseket, és megfelelő információbiztonsági szabványoknak megfelelő szolgáltatókat vegyenek igénybe. Az Article 29 és Article 30 a koncentrációs kockázattal, alvállalkozással, adat-helyreállítással, szerződéses védelmekkel, szolgáltatási szintekkel, incidenssegítségnyújtással, auditálási jogokkal, szolgáltatói vészhelyzeti teszteléssel, releváns esetben tesztelésben való részvétellel és kilépési megállapodásokkal foglalkozik.

Az ISO/IEC 27001:2022 Annex A támogató beszállítói kontrollokat biztosít, többek között az 5.19 Információbiztonság beszállítói kapcsolatokban, az 5.20 Információbiztonság kezelése beszállítói megállapodásokban, az 5.21 Információbiztonság kezelése az IKT-ellátási láncban, az 5.22 Beszállítói szolgáltatások megfigyelése, felülvizsgálata és változáskezelése, valamint az 5.23 Információbiztonság felhőszolgáltatások használatához pontokat.

Egy DORA tesztkatalógusnak azonosítania kell, mely tesztek igényelnek beszállítói részvételt vagy beszállítói bizonyítékot. Példák:

• felhőszolgáltatói átkapcsolási feltételezések;
• menedzselt SOC eszkaláció és bizonyítékmegőrzés;
• alapvető banki platform incidenskommunikációja;
• fizetésfeldolgozó kiesési forgatókönyve;
• identitásszolgáltató helyreállítási tesztje;
• SaaS-beszállítói penetrációs tesztelési nyilatkozatok;
• kritikus alvállalkozói lánc hatásvizsgálata.

Az a program, amely kizárja a kritikus IKT-szolgáltatókat, a valóságteszten elbukik. Az ügyféloldali szolgáltatás lehet az Önöké, de a rezilienciafüggőség lehet egy felhőrégióban, kiszervezett SOC-ban, identitásszolgáltatónál, szoftverbeszállítónál, fizetésfeldolgozónál vagy adatközpontban.

Keresztmegfelelési leképezés: egy bizonyítékkészlet, több kötelezettség

Egy jól megtervezett DORA tesztelési program csökkenti az auditterhelést. Ugyanaz a bizonyíték támogathatja a DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 és COBIT 2019 irányítási felülvizsgálatokat, ha megfelelően címkézik, megőrzik és jelentik.

A GDPR-ról sem szabad megfeledkezni. Ha a rezilienciatesztek személyes adatokat, naplókat, ügyfélnyilvántartásokat, identitásadatokat, HR nyilvántartásokat, biometrikus adatokat vagy különleges kategóriájú adatokat érintenek, a szervezetnek tiszteletben kell tartania a GDPR alapelveit, beleértve a jogszerűséget, tisztességességet, átláthatóságot, adattakarékosságot, tárolási korlátozást, sértetlenséget, bizalmasságot és elszámoltathatóságot. A tesztadat-másolatok, exportált naplók és penetrációs tesztbizonyítékok szabályozott adattárolókká válhatnak. A tesztprogramnak meg kell határoznia, ki férhet hozzá ezekhez, meddig őrzik meg őket, és hogyan semmisítik meg őket biztonságosan.

Hogyan vizsgálják az auditorok ugyanazt a programot?

Egy DORA felügyeleti hatóság, ISO auditor, NIST-alapú értékelő, COBIT felülvizsgáló és ügyfélauditor ugyanazt a bizonyítékot különböző nézőpontokból vizsgálhatja.

A Zenith Controls itt keresztmegfelelési iránytűként hasznos. DORA teszteléshez a Clarysec különösen fontos ISO/IEC 27001:2022 Annex A horgonyként emeli ki az 5.35 Az információbiztonság független felülvizsgálata, a 8.8 Műszaki sérülékenységek kezelése és a 8.6 Kapacitáskezelés pontokat. Ezek segítenek a kontrollgazdáknak összekapcsolni a tesztelést a független bizonyossággal, a sérülékenységkezeléssel és az operatív kapacitással.

A Clarysec Információbiztonsági szabályzata az auditnyomot is támogatja:

“A kontrollgazdáknak fenn kell tartaniuk a teszteredményeket, naplókat és felülvizsgálati nyilvántartásokat az időszakos auditok támogatására.”

Ebből a mondatból operatív szabályt kell alkotni. Minden tesztgazdának tudnia kell, mit kell megőrizni, hol kell megőrizni, hogyan kell védeni, és hogyan kapcsolódik a kockázati és kontrollbizonyítékokhoz.

DORA–ISO bizonyítékcsomag felépítése egy hét alatt

Egy pénzügyi szervezet vagy IKT-szolgáltató öt munkanap alatt jelentős előrehaladást érhet el.

1. nap: Hatókör és kritikusság meghatározása

Alkalmazza az ISO/IEC 27001:2022 4.1–4.4 pontok gondolkodásmódját. Azonosítsa az érdekelt feleket, szabályozási kötelezettségeket, szerződéses kötelezettségeket, interfészeket és függőségeket. Sorolja fel az üzleti szolgáltatásokat, kritikus vagy fontos funkciókat, kulcseszközöket, adattípusokat és IKT-szolgáltatókat.

Kimenet: DORA tesztelési hatókörnyilvántartás.

2. nap: Éves tesztkatalógus létrehozása

Használja a négy tesztelési családot: sérülékenység, forgatókönyv, teljesítmény és penetráció. Minden szolgáltatásnál határozza meg, mely tesztek alkalmazandók, milyen gyakorisággal, ki a felelős, milyen a függetlenségi szint és mi a kiváltó ok. Vegye fel a magas kockázatú változások kiváltó okait is.

Kimenet: 2026. évi digitális működési reziliencia tesztelési katalógus.

3. nap: Kontrollok és kötelezettségek leképezése

Képezzen le minden tesztet az ISO/IEC 27001:2022 Annex A-ra, a kockázati nyilvántartásra, az SoA-ra, a DORA cikkekre, beszállítói kötelezettségekre és a releváns Zenith Controls bejegyzésekre. Például a havi külső sérülékenységvizsgálatok a 8.8 Műszaki sérülékenységek kezelése pontra, a kockázatkezelésre, monitorozásra, DORA IKT-kockázatkezelésre és NIST CSF sérülékenységi eredményekre képezhetők le.

Kimenet: kontroll-leképezési mátrix.

4. nap: Bizonyítékmappák egységesítése

Hozzon létre kontrollált bizonyítékstruktúrát:

• 01 Terv és engedélyezés
• 02 Hatókör és végrehajtási szabályok
• 03 Nyers eredmények
• 04 Végleges jelentés
• 05 Megállapítási nyilvántartás
• 06 Helyesbítő intézkedési jegyek
• 07 Újratesztelési bizonyítékok
• 08 Vezetői jelentéstétel
• 09 Tanulságok és szabályzatfrissítések

Kimenet: bizonyítéktár megőrzési szabályokkal.

5. nap: Megállapítások és jelentéstétel felülvizsgálata

Konszolidálja a nyitott megállapításokat súlyosság, szolgáltatás, kockázattulajdonos és határidő szerint. Azonosítsa a lejárt helyesbítő intézkedéseket, elfogadott kockázatokat és újratesztelési hiányokat. Készítsen vezető testületi irányítópultot, amely bemutatja a tesztlefedettséget, a jelentős megállapításokat, a lejárt intézkedéseket, a harmadik fél problémákat és a maradványkockázatot.

Kimenet: igazgatóság elé terjeszthető DORA és ISO tesztelési irányítópult.

Gyakori DORA tesztelési programhibák

A leggyakoribb hiba nem a tesztelés hiánya. Hanem az irányítás hiánya.

Figyeljen a következő problémákra:

• évente elvégzett penetrációs tesztek, de a megállapításokat nem követik lezárásig;
• gyakran futó sérülékenységvizsgálatok, de kritikus eszközök hiányoznak a hatókörből;
• megtartott asztali gyakorlatok, de nincs döntési napló vagy tanulságokra épülő intézkedési terv;
• elvégzett biztonsági mentésből történő helyreállítási tesztek, de nincs leképezés RTO-ra és RPO-ra;
• mérnöki csapat által futtatott terheléses tesztek, de nincs jelentés a kockázati vagy megfelelőségi terület felé;
• IKT-szolgáltatók kizárása a forgatókönyv-alapú és helyreállítási tesztekből;
• bizonyítékok személyes mappákban, csevegési szálakban vagy nem kezelt meghajtókon;
• igazgatósági jelentések, amelyek az aktivitásszámokra fókuszálnak a megoldatlan rezilienciakockázat helyett;
• az SoA szerint a kontroll alkalmazandó, de nincs tesztbizonyíték;
• a tesztelés éles környezeti kockázatot teremt, mert az engedélyezés és a határok nem egyértelműek.

Minden hiányosság kezelhető. A megoldás nem több véletlenszerű tesztelés. A megoldás egyetlen kontrollált program, amely összekapcsolja a kockázatot, a teszttevékenységet, a helyesbítő intézkedéseket, a bizonyítékokat és a vezetői felügyeletet.

Mit kell ténylegesen látnia az igazgatóságnak?

A DORA az IKT-rezilienciát a vezető testület felelősségévé teszi. Egy hasznos igazgatósági jelentésnek nem kell minden technikai megállapítást tartalmaznia. Arra kell választ adnia, hogy a szervezet kellően reziliens-e a kockázatvállalási hajlandóságához és zavartűrési határához képest.

Egy erős negyedéves vagy féléves jelentés tartalmazza:

• a tesztlefedettséget kritikus vagy fontos funkciók szerint;
• az elvégzett és tervezett tesztek arányát;
• a kritikus és magas súlyosságú megállapításokat szolgáltatásonként;
• a lejárt helyesbítő intézkedéseket felelősönként;
• az újratesztelési sikerességi arányt;
• a beszállítókkal kapcsolatos megállapításokat és koncentrációs aggályokat;
• a válság- vagy incidenskezelési terveket érintő forgatókönyv-alapú teszttanulságokat;
• az üzleti növekedéshez és csúcsidőszakokhoz kapcsolódó kapacitáskockázatokat;
• a vezetői elfogadást igénylő maradványkockázatokat;
• a költségvetési, erőforrás- vagy eszközkorlátokat.

Ez a jelentés ISO vezetőségi átvizsgálási inputtá, DORA irányítási bizonyítékká és gyakorlati döntéstámogató eszközzé válik.

Szétszórt tesztekből stratégiai reziliencia

Az információbiztonsági vezető eredeti problémája nem az volt, hogy hiányzott a tesztelés. A szervezetnek voltak vizsgálatai, asztali gyakorlatai, terhelési jelentései és penetrációs teszt PDF-jei. A probléma az volt, hogy ezek a tevékenységek még nem alkottak egységes bizonyítéktörténetet.

Egy egységes DORA és ISO/IEC 27001:2022 tesztelési program ezt megváltoztatja. A kockázatértékelés vezérli a katalógust. A katalógus vezérli az engedélyezett tesztelést. A tesztelés megállapításokat eredményez. A megállapítások helyesbítő intézkedéseket és újratesztelést indítanak. Az eredmények bekerülnek a vezetői jelentéstételbe. A levont tanulságok frissítik a szabályzatokat, eljárásokat, szerződéseket és kontrollokat.

Így válik a megfelelési teher stratégiai képességgé.

A Clarysec segít a szervezeteknek elkerülni a párhuzamos megfelelési programokat. A DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 és COBIT 2019 nem igényel külön bizonyítékuniverzumokat. Egyetlen, irányított működési modellre van szükségük, amely különböző auditori nézőpontok szerint mutatható be.

Megközelítésünk ötvözi:

• a Zenith Blueprint keretrendszert a szakaszos ISO bevezetéshez és auditra való felkészültséghez;
• a Zenith Controls megoldást a kontrollok, keretrendszerek és auditelvárások közötti keresztmegfelelési leképezéshez;
• vállalati és SME szabályzatokat biztonsági teszteléshez, auditfelügyelethez, sérülékenységkezeléshez, alkalmazásbiztonsághoz, folytonossághoz és információbiztonsághoz;
• gyakorlati nyilvántartásokat, bizonyítékstruktúrákat és vezetői jelentéstételi sablonokat.

Ha a 2026-os DORA tesztelési bizonyítékai vizsgálóeszközök, mérnöki mappák, asztali gyakorlatok jegyzetei és penetrációs teszt PDF-ek között szóródnak szét, most kell konszolidálni őket.

Kezdje egyetlen éves tesztkatalógussal, amely le van képezve az ISO/IEC 27001:2022 szerinti kockázatkezelésre, az SoA-ra, a kritikus vagy fontos funkciókra, az IKT harmadik felekre és a vezetői jelentéstételre. Ezután használja a Clarysec Zenith Blueprint, Zenith Controls és szabályzati eszközkészletét, hogy a katalógusból igazolható auditbizonyíték legyen.

A Clarysec segíthet a program megtervezésében, a kontrollok leképezésében, a bizonyítékcsomag strukturálásában és az igazgatósági szintű rezilienciajelentés elkészítésében, még mielőtt a következő felügyeleti megkeresés megérkezik.