DORA 2026: Így lesz auditálható és bizonyítható a tesztautomatizálás

A DORA 2025. január 17. óta kötelezi az EU pénzügyi szektorát, hogy a kritikus ICT-rendszereket legalább évente, független módon teszteljék, a TLPT-re kötelezett intézményeket pedig háromévente fenyegetés-vezérelt behatolásteszttel. A követelmény nem az, hogy „teszteljünk”, hanem hogy a tesztelést dokumentáltan, megismételhetően és egy audit során bizonyíthatóan végezzük. A pénzügyi intézmények tesztautomatizálása akkor lesz megfelelő, ha minden lefutás nyomon követhető, és nem függ a szállítótól.

DORA 2026_ProofIT_testautomation

Egy éve, 2025. június 18-án jelent meg a TLPT részleteit kidolgozó RTS (Commission Delegated Regulation (EU) 2025/1190). Azóta a kérdés a gyakorlat felé tolódott: megállja-e a napi tesztautomatizálás a helyét egy felügyeleti vizsgálaton.

Mit követel meg a DORA a teszteléstől?

A DORA tesztelési kötelezettsége három, egymásra épülő rétegből áll. Érdemes külön kezelni őket, mert a megfelelés mindháromra kiterjed.

Általános tesztelési program (Art. 24)

Kockázatalapú, átfogó tesztelési program a kritikus/fontos funkciókat támogató ICT-rendszerekre.

Gyakoriság: Legalább évente.

Kire vonatkozik: Minden pénzügyi entitásra a mikrovállalkozásokon kívül

Tesztelési típusok (Art. 25)

Sérülékenység-vizsgálat, forráskód-review, szcenárió-alapú teszt, teljesítményteszt, end-to-end teszt, behatolásteszt.

Gyakoriság: A program szerint

Kire vonatkozik: Minden pénzügyi entitásra a mikrovállalkozásokon kívül

TLPT (Art. 26)

Fenyegetés-vezérelt behatolásteszt élő, éles rendszereken

Gyakoriság: Legalább háromévente

Kire vonatkozik: Kijelölt, jelentős intézményekre

A DORA 24. rendelkezése hangsúlyozza, lényeges, hogy a teszteket független fél végezze. A független tesztelő lehet belső vagy külső tesztelő csapat is. Amennyiben belső tesztelésre kerülne sor, abban az esetben a cégnek el kell kerülnie az érdekkonfliktust a tervezés és a végrehajtás során. Ez nem szervezeti formaság, hanem azt jelenti, hogy a teszt eredménye nem függhet attól, ki és milyen eszközön futtatta.

„Tesztelünk” vs „bizonyíthatóan tesztelünk”

A legtöbb pénzügyi szervezetnél van tesztautomatizálás. A DORA nem azt vizsgálja, milyen szervezeti megoldásként végzik a tesztelést. A felügyelet azt nézi, hogy a pénzügyi intézmény a tesztelésről utólag, hónapokkal később is elő tudja-e venni a bizonyítékot azzal kapcsolatban, hogy:

  • Mit teszteltek?
  • Melyek kritikus funkciók, melyik build, melyik környezet?
  • Mikor és hányszor?
    A „legalább évente” csak akkor igazolható, ha a lefutások időbélyegzett nyoma megvan.
  • Ki végezte, függetlenül?Kizárható-e, hogy a fejlesztő a saját kódját a saját eszközében zöldre festette.
  • Mi lett az eredmény, és mi történt a hibákkal?
    A talált eltérések sorsa követhető-e a javításig.

Ha ezekre a kérdésekre egy screenshot és egy „megvolt” a válasz, az audit szempontjából nincs teszt. Az auditálhatóság nem riportgenerálás a végén. A nyomvonalnak már a teszt futása közben keletkeznie kell, manipulálhatatlanul.

Az auditálhatóság három pillére

1. Nyomon követhetőség a követelménytől a lefutásig

Egy auditor nem teszteseteket akar látni, hanem azt, hogy a kritikus üzleti funkció le van-e fedve. Ehhez a tesztnek a követelményhez kell kapcsolódnia, a lefutásnak pedig időbélyeggel, környezet-azonosítóval és eredménnyel rögzülnie. A láncnak két irányba kell működnie: a követelménytől meg tudom mondani, hol a teszt, és egy lefutástól vissza tudom vezetni, melyik funkciót igazolta.

2. Megismételhetőség és determinizmus

A flaky teszt itt többe kerül egy feszült percnél. Ha ugyanaz a teszt ma zöld, holnap piros, változatlan kód mellett, akkor egyik lefutás sem bizonyít semmit. A DORA megismételhető, megbízható tesztelést vár, és a determinizmus adja ehhez az alapot: amíg a kritikus tesztkészlet eredménye megjósolhatatlan, addig nincs mire hivatkozni az auditon.

3. Szállító-függetlenség

Ez az a pillér, amit a szervezetek a legkésőbb vesznek észre, és a legdrágábban tanulnak meg. Ha a tesztautomatizálás egyetlen eszközgyártó zárt formátumában történik, a kockázat az auditon csapódik le, amikor a bizonyítékokat szednénk össze.

Kockázatos, ha az auditnyom a szállító rendszerében marad. Ugyanis ha a tesztelő céggel kötött szerződés véget ér, vagy az eszköz támogatása megszűnik, az évekre visszamenő bizonyítékok hozzáférhetősége kérdésessé válik.

Ehhez jön még a koncentrációs kockázat, amivel a DORA külön foglalkozik. A 30. cikk (3) d) pontja előírja, hogy a kiszervezett automata tesztelést végző szolgáltatók szerződésben legyenek kötelezve a TLPT-ben való együttműködésre, és egy zárt teszt-eszköznek is meg kell felelnie a DORA irányelveinek.

A harmadik kiemelt kockázat a migrációs adósság: ha tesztezközt kell váltani, és a tesztvagyon nem hordozható, a DORA harmadik pillérének való megfelelés folytonossága pont a váltás közben szakad meg.

A vendor-függetlenség ezért elsősorban tulajdonjogi kérdés. A tesztvagyon és az auditnyom a banké kell, hogy maradjon, abban az esetben is, ha a teszteszköz változik.

ACE: Megoldás a DORA megfelelésre

Az automata tesztelő eszközünket, az ACE-t úgy tervezzük, hogy választ adjon a fenti három követelményre a működés részeként.

Az auditálhatóság szándéka, hogy a lefutás nyoma már futás közben keletkezzen, és a követelménytől a teszten át az eredményig egy láncban legyen visszavezethető. A vendor-függetlenség célja, hogy a tesztvagyon és az auditnyom a banké maradjon, és az eszközválasztás változása ne zárja el a hozzáférést a korábbi bizonyítékoktól.

Az ACE-t arra terveztük, hogy az olyan komplex, üzletkritikus rendszerekben, mint amilyenek a banki rendszerek is, ahol a „majdnem jó” teszteredmény nem opció, pontos és biztonságos automata tesztelő megoldásként szolgáljon.

Ez a megközelítés a DORA 24-26. cikkének gyakorlati lefordítása mérnöki nyelvre. A cél egy folyamatos megfelelési rutin, amelyben minden release a saját nyomvonalát hagyja maga után – ezt biztosítja az ACE, a ProofIT automata tesztelő eszköze.

Gyakorlati lépések a DORA megvalósításához

  1. Térképezd fel a kritikus és fontos funkciókat.
    A DORA ezekre fókuszál. Ami nem kritikus, az most nem prioritás.
  2. Kösd a teszteket a funkciókhoz.
    Minden kritikus funkcióhoz tartozzon nyomon követhető tesztlefedettség, ne csak teszteset-szám.
  3. Tedd determinisztikussá a kritikus tesztkészletet.
    A flaky teszt itt nem technikai adósság, hanem bizonyíték-hiány.
  4. Rögzítsd a lefutások auditnyomát futás közben.
    Időbélyeg, környezet, eredmény, és a hibák sorsa a javításig.
  5. Ellenőrizd a bizonyíték tulajdonjogát.
    Hozzáférsz-e az auditnyomhoz a szállítótól függetlenül, évekre visszamenőleg.
  6. Szinkronizáld a tesztelési ciklust a DORA gyakoriságával.
    Az „évente” csak akkor érték, ha a nyoma igazolható.

 

Gyakori kérdések

Kötelező a tesztautomatizálás a DORA szerint?

A DORA nem ír elő konkrét eszközt, de a 25. cikk felsorolja a tesztelési típusokat (sérülékenység-vizsgálat, end-to-end teszt, teljesítményteszt, behatolásteszt), és a 24. cikk szerint évente szükséges tesztelni a kritikus rendszereket. Ezt a gyakoriságot és lefedettséget manuálisan, megismételhetően és bizonyíthatóan tartani szinte lehetetlen. Ezért tehát a tesztelés automatizálása a gyakorlatban elkerülhetetlen, még ha a jogszabály nevesítve nem is követeli meg azt.

Mi a TLPT, és minden bankra vonatkozik?

A TLPT (Threat-Led Penetration Testing) fenyegetés-vezérelt behatolásteszt élő, éles rendszereken, legalább háromévente. Csak a felügyelet által kijelölt, jelentős és érett ICT-rendszerű intézményekre vonatkozik. A 24. cikk szerinti éves tesztelés viszont a szektor szélesebb körét érinti.

Miért probléma, ha a tesztautomatizálás egyetlen szállítóhoz kötött?

Ebben az esetben könnyen előfordulhat, hogy az auditnyom és a tesztvagyon a szállító rendszerében marad. Eszközváltáskor vagy a támogatás megszűnésekor a bizonyíték hozzáférhetősége kérdésessé válik, pont akkor, amikor a megfelelés folytonosságát igazolni kellene.

Mikortól él a DORA?

A DORA 2025. január 17. óta kötelező alkalmazni az EU pénzügyi szervezeteire. A TLPT-re vonatkozó RTS pedig 2025. július 8-tól közvetlenül alkalmazandó.

A cikk a DORA nyilvánosan elérhető szövegére és a hivatkozott szakmai forrásokra épül. Konkrét megfelelési kérdésekben a saját felügyeleti hatóságod iránymutatása az irányadó.

Ha további kérdései vannak a tesztautomatizálással kapcsolatos DORA megfelelőséggel kapcsolatban, kérjük, forduljon hozzánk bizalommal a business@proofit.tech e-mail címen vagy a +44 73 6048 4722 telefonszámon. Szakértőkből álló csapatunk segítséget nyújthat az Ön összetett és kritikus vagy sürgős funkcionális és teljesítménytesztelési folyamatában.

Forrás: 1 2 3 4 5