DORA 2026 m. veiksmų planas IRT rizikai, tiekėjams ir TLPT

DORA 2026 paieškų panika iš tikrųjų susijusi ne su reglamentavimu, o su įrodymais
Pirmadienį 08:15 vidutinio dydžio mokėjimo įstaigos CISO turi atidarytus tris naršyklės skirtukus: „DORA RTS/ITS kontrolinis sąrašas“, „DORA IRT trečiųjų šalių registro šablonas“ ir „TLPT reikalavimai finansų subjektams“.
Atitikties vadovas jau paklausė, ar valdybai skirtame pakete turėtų būti naujausia incidentų klasifikavimo darbo eiga. Pirkimų komanda nori įtraukti naują debesijos analitikos platformą. COO nori patikinimo, kad pagrindinės bankininkystės SaaS teikėjas neturi paslėptos subtiekėjų ekspozicijos už ES ribų. Vidaus auditas prašo testavimo kalendoriaus. Teisės funkcija klausia, ar GDPR pranešimų apie pažeidimus terminai suderinti su DORA pranešimais apie incidentus.
Niekas neužduoda teorinio klausimo. Jie klausia: „Ar galime tai įrodyti iki penktadienio?“
Tai ir yra tikroji DORA 2026 problema. Dauguma finansų subjektų supranta pagrindinius įpareigojimus: IRT rizikos valdymą, pranešimų apie su IRT susijusius incidentus teikimą, skaitmeninės veiklos atsparumo testavimą, IRT trečiųjų šalių rizikos valdymą ir sustiprintą kritinių IRT paslaugų teikėjų priežiūrą. Sudėtingiausia yra techninius reguliavimo standartus, techninius įgyvendinimo standartus ir straipsnių lygmens įpareigojimus paversti kontroliuojama, kartojama ir audituojama praktika.
Reglamentas dėl skaitmeninės veiklos atsparumo finansų sektoriuje reikalauja, kad finansų subjektai palaikytų tvirtus IRT rizikos valdymo pajėgumus, su IRT susijusių incidentų valdymo ir pranešimų apie juos teikimo politikas, IRT sistemų, kontrolės priemonių ir procesų testavimą bei struktūruotą IRT trečiųjų šalių paslaugų teikėjų priežiūrą. Jame taip pat įtvirtintas proporcingumo principas. Mažesnei investicinei įmonei ir didelei bankų grupei nereikia identiškų įrodymų modelių, tačiau abi turi įrodyti, kad jų požiūris atitinka jų dydį, rizikos profilį, sudėtingumą ir kritines funkcijas.
DORA projektai dažniausiai žlunga dėl vienos iš trijų priežasčių. Pirma, organizacija DORA traktuoja kaip teisinio susiejimo užduotį, o ne kaip veiklos modelį. Antra, tiekėjų rizika dokumentuojama kaip tiekėjų sąrašas, o ne kaip priklausomybių, pakeičiamumo ir koncentracijos rizikos vaizdas. Trečia, testavimas traktuojamas kaip metinis skverbties testas, o ne kaip atsparumo programa, apimanti pažeidžiamumų skenavimą, scenarijų testavimą, incidentų pratybas ir, kai taikoma, grėsmėmis grindžiamą skverbties testavimą, kurio dažnai ieškoma kaip TLPT.
Geresnis požiūris – sukurti vieną įrodymų sistemą, jungiančią politikas, registrus, savininkus, rizikas, incidentus, tiekėjus, testavimą, atkūrimą ir vadovybės peržiūrą. Būtent čia Clarysec Zenith Blueprint, parengtos naudoti politikos ir Zenith Controls padeda finansų subjektams paversti DORA iš termino į veiklos ritmą.
Pradėkite nuo DORA veiklos modelio, o ne nuo RTS/ITS skaičiuoklės
Daugelis komandų pradeda nuo skaičiuoklės, kurioje išvardyti DORA straipsniai ir RTS/ITS reikalavimai. Tai naudinga, bet nepakankama. Skaičiuoklė gali parodyti, kas turi egzistuoti. Ji nepriskiria savininkų, neapibrėžia peržiūros dažnio, neišsaugo įrodymų ir neįrodo, kad kontrolės priemonė iš tikrųjų veikia.
Zenith Blueprint: auditoriaus 30 žingsnių veiksmų plane Clarysec tai aptaria Rizikos valdymo etape, 14 žingsnyje, Rizikos tvarkymo politikos ir reglamentavimo kryžminės nuorodos:
„DORA: finansų sektoriaus įmonėms DORA reikalauja IRT rizikos valdymo sistemos, labai artimos tam, ką jau atlikome: identifikuoti rizikas, įdiegti kontrolės priemones ir politikas bei jas testuoti. DORA taip pat pabrėžia reagavimą į incidentus ir pranešimų apie juos teikimą bei trečiųjų šalių IRT paslaugų teikėjų priežiūrą.“
Praktinė žinutė paprasta: nekurkite „DORA atitikties“ kaip lygiagrečios biurokratijos. Kurkite rizika grindžiamą IRT valdysenos sluoksnį, kuris susieja DORA reikalavimus su politikomis, registrais, kontrolės priemonių savininkais, testavimo įrašais, tiekėjų įrodymais ir vadovybės peržiūra.
Praktinis DORA veiklos modelis turėtų turėti penkis įrodymų ramsčius:
| DORA įrodymų ramstis | Praktinis įrodymas | Tipinis savininkas | Clarysec priemonių rinkinio atrama |
|---|---|---|---|
| IRT rizikos valdymas | IRT rizikų registras, rizikos tvarkymo planas, kontrolės priemonių susiejimas | CISO arba rizikos savininkas | Rizikos valdymo politika ir Zenith Blueprint 14 žingsnis |
| IRT incidentų valdymas | Reagavimo į incidentus planas, klasifikavimo matrica, pranešimų darbo eiga, įgytų pamokų žurnalas | Saugumo operacijos, teisė, DAP | Reagavimo į incidentus politika ir Zenith Blueprint 16 žingsnis |
| Trečiųjų šalių IRT priežiūra | Tiekėjų registras, priklausomybių registras, subtiekėjų peržiūra, pasitraukimo planai | Tiekėjų valdymas, pirkimai, CISO | Trečiųjų šalių ir tiekėjų saugumo politika, Tiekėjų priklausomybės rizikos valdymo politika, Zenith Blueprint 23 žingsnis |
| Skaitmeninės veiklos atsparumo testavimas | Testavimo kalendorius, pažeidžiamumų skenavimas, skverbties testai, raudonosios komandos apimtis, TLPT valdysena | Saugumo testavimo vadovas, IT operacijos | Saugumo testavimo ir raudonosios komandos politika bei Zenith Blueprint 21 žingsnis |
| Tęstinumas ir atkūrimas | BIA, BCP, DR testai, atkūrimo įrodymai, krizių komunikacija | COO, IT tęstinumo savininkas | Veiklos tęstinumo politika ir atkūrimo po katastrofos politika |
Reglamentuojamiems finansų subjektams ši struktūra paverčia RTS/ITS įgyvendinimą auditui tinkama įrodymų sistema. Subjektams, kuriems taikomas supaprastintas IRT rizikos valdymas, tą patį modelį galima sumažinti iki mažesnio dokumentų skaičiaus ir paprastesnių registrų. Pagrindinės disciplinos išlieka tos pačios: identifikuoti, apsaugoti, aptikti, reaguoti, atkurti, testuoti ir valdyti tiekėjus.
IRT rizikos valdymas: registras yra valdymo centras
DORA IRT rizikos valdymo lūkesčiai reikalauja, kad finansų subjektai identifikuotų, klasifikuotų ir valdytų IRT rizikas sistemose, duomenyse, procesuose, kritinėse ar svarbiose funkcijose ir trečiųjų šalių priklausomybėse.
Dažna nesėkmė nėra rizikų registro nebuvimas. Problema ta, kad registras nesusietas su tiekėjais, turtu, incidentais ir testais. DORA nevertina gražios skaičiuoklės, jei ji negali paaiškinti, kodėl didelės rizikos tiekėjas neturi pasitraukimo plano arba kodėl kritinė klientų mokėjimų platforma nebuvo testuota.
Clarysec MVĮ Rizikos valdymo politika mažesniems finansų subjektams suteikia glaustą įrodymų bazę:
„Kiekviename rizikos įraše turi būti: aprašymas, tikimybė, poveikis, balas, savininkas ir rizikos tvarkymo planas.“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.1.2.
Didesniems finansų subjektams Clarysec Enterprise Rizikos valdymo politika reikalauja formalesnio proceso:
„Formalus rizikos valdymo procesas turi būti palaikomas pagal ISO/IEC 27005 ir ISO 31000, apimant rizikų identifikavimą, analizę, įvertinimą, tvarkymą, stebėseną ir komunikaciją.“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.1.
Šis skirtumas svarbus. DORA yra proporcinga, tačiau proporcingumas nereiškia neformalumo. Maža mokėjimo įmonė gali naudoti supaprastintą registrą, o bankų grupė – integruotus GRC įrankius. Abiem atvejais auditorius vis tiek klaus: kokios yra jūsų IRT rizikos? Kas už jas atsakingas? Koks yra rizikos tvarkymo planas? Kokie įrodymai rodo pažangą? Kaip tiekėjai ir kritinės funkcijos veikia balą?
Stiprus DORA IRT rizikų registras turėtų apimti šiuos laukus:
| Laukas | Kodėl tai svarbu DORA 2026 | Pavyzdys |
|---|---|---|
| Kritinė arba svarbi funkcija | Susieja riziką su veiklos atsparumu | Kortelių mokėjimų apdorojimas |
| Palaikomas IRT turtas arba paslauga | Parodo technologinę priklausomybę | Mokėjimo šliuzo API |
| Tiekėjas arba vidinis savininkas | Identifikuoja atskaitomybę | Debesijos paslaugų teikėjas ir mokėjimų inžinerijos komanda |
| Rizikos aprašymas | Paaiškina scenarijų | API sutrikimas blokuoja klientų operacijas |
| Tikimybė, poveikis ir balas | Pagrindžia rizikos prioritetizavimą | Vidutinė tikimybė, didelis poveikis |
| Rizikos tvarkymo planas | Paverčia vertinimą veiksmu | Pridėti perjungimo į atsarginę aplinką kelią ir testuoti atkūrimą kas ketvirtį |
| Kontrolės priemonių susiejimas | Susieja įrodymus su sistema | Reagavimas į incidentus, tiekėjų priežiūra, žurnalų tvarkymas, tęstinumas |
| Peržiūros data | Parodo, kad rizika aktuali | Kas ketvirtį arba po reikšmingo tiekėjo pakeitimo |
Praktinis pratimas – paimti vieną kritinę IRT paslaugą, pavyzdžiui, debesijoje veikiančią operacijų stebėsenos platformą, ir per 20 minučių sukurti rizikos įrašą. Aprašykite sutrikimo arba kompromitavimo scenarijų, įvertinkite tikimybę ir poveikį, priskirkite savininką, identifikuokite susijusius tiekėjus, apibrėžkite rizikos tvarkymo planą ir susiekite įrašą su įrodymais, tokiais kaip tiekėjų deramas patikrinimas, SLA, incidentų nuostatos, BIA, DR testų rezultatai, stebėsenos suvestinės ir prieigos peržiūros.
Tas vienas įrašas tampa gija, jungiančia DORA IRT rizikos valdymą, trečiųjų šalių priežiūrą, incidentų aptikimą, tęstinumą ir testavimą. Taip rizikų registras tampa valdymo centru, o ne dokumentų spinta.
RTS/ITS pasirengimas: susiekite įpareigojimus su politikomis, o ne pažadais
Praktinis paieškos terminas „DORA RTS/ITS kontrolinis sąrašas“ paprastai reiškia „Kokių dokumentų tikėsis priežiūros institucijos?“ Finansų subjektai turėtų vengti žadėti atitiktį bendro pobūdžio teiginiais. Jiems reikia susiejimo, kuris kiekvieną įpareigojimą pririštų prie politikos, kontrolės priemonės, savininko ir įrodymo.
Clarysec MVĮ Teisinės ir reglamentavimo atitikties politika nustato paprastą valdysenos atramą:
„Generalinis vadovas turi palaikyti paprastą, struktūruotą Atitikties registrą, kuriame nurodoma:“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.1.1.
DORA 2026 atveju jūsų atitikties registras turėtų apimti:
- DORA įpareigojimą arba RTS/ITS reikalavimų sritį.
- Taikomumą, įskaitant proporcingumo pagrindimą.
- Politikos arba procedūros nuorodą.
- Kontrolės priemonės savininką.
- Įrodymų saugojimo vietą.
- Peržiūros dažnį.
- Atviras spragas ir taisomųjų veiksmų terminą.
- Ataskaitų valdybai arba vadovybei būseną.
Tai atitinka Zenith Blueprint 14 žingsnio požiūrį: susieti reglamentavimo reikalavimus su ISVS kontrolės priemonėmis ir politikomis, kad niekas nepraslystų. Užuot klaususi „Ar atitinkame DORA?“, vadovybė gali klausti: „Kurie DORA įrodymų elementai vėluoja, kuriems kritiniams tiekėjams trūksta pasitraukimo planų ir kurios testavimo veiklos dar nepateikė taisomųjų veiksmų įrodymų?“
Trečiųjų šalių IRT rizika: koncentracija, pakeičiamumas ir subtiekėjai
DORA pakeitė pokalbį apie tiekėjus finansinių paslaugų sektoriuje. Nebepakanka paklausti, ar paslaugų teikėjas turi saugumo sertifikatą, draudimą arba duomenų tvarkymo sutartį. Finansų subjektai turi įvertinti, ar paslaugų teikėjas sukuria koncentracijos riziką, ar jį realiai galima pakeisti, ar kelios kritinės paslaugos priklauso nuo vieno tiekėjo arba susijusių tiekėjų, ir ar subrangos pasitelkimas sukuria papildomą teisinę arba atsparumo ekspoziciją.
Tai klausimas, dėl kurio daugelis CISO nemiega. Įmonė gali remtis vienu pagrindiniu debesijos paslaugų teikėju operacijų apdorojimui, duomenų analitikai, klientų portalams ir vidiniam bendradarbiavimui. Jei tas teikėjas patiria ilgalaikį paslaugų nepasiekiamumą, reguliacinį ginčą arba subtiekėjo sutrikimą, klausimas yra ne tik „Ar turime sutartį?“ Klausimas yra „Ar galime tęsti kritines paslaugas, komunikuoti su klientais ir įrodyti, kad supratome priklausomybę dar prieš jai sutrinku?“
Clarysec MVĮ Trečiųjų šalių ir tiekėjų saugumo politika nustato pagrindą:
„Tiekėjų registrą turi palaikyti ir atnaujinti administracinis arba pirkimų kontaktinis asmuo. Jame turi būti:“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.4.
Įmonių programoms Clarysec Tiekėjų priklausomybės rizikos valdymo politika giliau aprašo DORA specifinę priklausomybę ir pakeičiamumą:
„Tiekėjų priklausomybės registras: VMO turi palaikyti atnaujintą visų kritinių tiekėjų registrą, įskaitant tokią informaciją kaip teikiamos paslaugos / produktai; ar tiekėjas yra vienintelis šaltinis; galimi alternatyvūs tiekėjai arba pakeičiamumas; galiojančios sutarties sąlygos; ir poveikio vertinimas, jei tiekėjas nustotų veikti arba būtų kompromituotas. Registre turi būti aiškiai identifikuoti didelės priklausomybės tiekėjai, pavyzdžiui, tie, kuriems nėra greitos alternatyvos.“
Iš skyriaus „Įgyvendinimo reikalavimai“, politikos punktas 6.1.
Tai yra tiekėjų įrodymai, kurių DORA projektuose dažnai trūksta. Tiekėjų registras parodo, kas yra tiekėjas. Priklausomybių registras parodo, kas įvyksta tiekėjui sutrikus.
Zenith Blueprint Kontrolės priemonių taikymo etapo 23 žingsnyje, Organizacinės kontrolės priemonės, pateikiama praktinė tiekėjų priežiūros darbo eiga. Joje rekomenduojama sudaryti visą tiekėjų sąrašą, klasifikuoti tiekėjus pagal prieigą prie sistemų, duomenų arba veiklos kontrolės, patikrinti, kad saugumo lūkesčiai būtų įtraukti į sutartis, valdyti subtiekėjų ir tolesnės grandinės riziką, apibrėžti pakeitimų ir stebėsenos procedūras ir sukurti debesijos paslaugos vertinimo procesą.
Zenith Controls: kryžminės atitikties vadove ISO/IEC 27002:2022 kontrolės priemonė 5.21 „Informacijos saugumo valdymas IRT tiekimo grandinėje“ susieta kaip prevencinė kontrolės priemonė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Ji siejama su tiekėjų santykių saugumu ir Identify kibernetinio saugumo funkcija. Ji jungiasi su saugia inžinerija, saugiu programavimu, prieigos kontrole, saugumo testavimu, įrodymų rinkimu, saugaus kūrimo gyvavimo ciklu ir išoriniu kūrimu.
Būtent tokia yra DORA trečiųjų šalių priežiūros realybė. Tiekėjų rizika nėra vien pirkimų klausimas. Ji paliečia architektūrą, kūrimą, reagavimą į incidentus, prieigos kontrolę, veiklos tęstinumą ir teisę.
| Klausimas | Saugotini įrodymai | Kodėl tai svarbu auditoriams |
|---|---|---|
| Ar tiekėjas susietas su kritine arba svarbia funkcija? | Kritinių funkcijų žemėlapis, tiekėjų registras | Parodo proporcingumą ir prioritetizavimą |
| Ar tiekėjas yra vienintelis tiekimo šaltinis arba sunkiai pakeičiamas? | Tiekėjų priklausomybės registras, pasitraukimo analizė | Pagrindžia koncentracijos rizikos valdymą |
| Ar subtiekėjai identifikuoti ir įvertinti? | Subtiekėjų sąrašas, perkeliamųjų įsipareigojimų nuostatos, patikinimo ataskaitos | Apima tolesnės IRT tiekimo grandinės riziką |
| Ar sutartyje apibrėžtos pranešimo apie incidentus pareigos? | Sutarties nuostatos, incidentų pranešimo darbo eiga | Palaiko DORA incidentų eskalavimą |
| Ar saugumo reikalavimai įtraukti į pirkimus? | RFP šablonai, deramo patikrinimo kontrolinis sąrašas, patvirtinimo įrašai | Parodo, kad kontrolės priemonės taikomos prieš įtraukimą |
| Ar tiekėjų pakeitimai vertinami pakartotinai? | Pakeitimų aktyvinimo sąlygos, peržiūros įrašai, atnaujintas rizikos įrašas | Užkerta kelią nepastebimam rizikos augimui |
| Ar yra pasitraukimo arba nenumatytų atvejų planas? | Pasitraukimo planas, alternatyvaus teikėjo analizė, DR priklausomybės testas | Palaiko veiklos atsparumą |
Kryžminės atitikties požiūriu Zenith Controls susieja IRT tiekimo grandinės saugumą su GDPR Articles 28 and 32, nes tvarkytojai ir subtvarkytojai turi būti atrenkami ir prižiūrimi taikant tinkamas technines ir organizacines priemones. Tai palaiko NIS2 tiekimo grandinės saugumo lūkesčius, įskaitant Article 21 kibernetinio saugumo rizikos valdymo priemones ir Article 22 koordinuotus tiekimo grandinės rizikos vertinimus. Tai stipriai siejasi su DORA Articles 28, 29 and 30, kuriuose IRT trečiųjų šalių rizika, koncentracijos rizika, subrangos pasitelkimas ir sutartinės nuostatos yra esminės.
Papildomi standartai sustiprina įrodymus. ISO/IEC 27036-3:2021 palaiko IRT pirkimų ir tiekėjų atrankos saugumą. ISO/IEC 20243:2018 palaiko patikimos technologijos produkto vientisumą ir tiekimo grandinės saugumą. ISO/IEC 27001:2022 susieja tai su rizikos tvarkymu ir Annex A tiekėjų kontrolės priemonėmis.
Pranešimų apie incidentus teikimas: sukurkite eskalavimo grandinę prieš incidentą
DORA pranešimų apie incidentus teikimas nėra vien pranešimo pateikimas. Tai su IRT susijusių incidentų aptikimas, klasifikavimas, eskalavimas, komunikacija ir mokymasis iš jų. Finansų subjektai turi palaikyti IRT incidentų valdymo ir pranešimų apie juos teikimo procesus su apibrėžtais vaidmenimis, klasifikavimo kriterijais, pranešimo keliais ir analize po incidento.
Clarysec MVĮ Reagavimo į incidentus politika susieja reagavimo į incidentus terminus su teisiniais reikalavimais:
„Reagavimo terminai, įskaitant duomenų atkūrimo ir pranešimo įpareigojimus, turi būti dokumentuoti ir suderinti su teisiniais reikalavimais, tokiais kaip GDPR 72 valandų pranešimo apie asmens duomenų saugumo pažeidimą reikalavimas.“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.3.2.
Įmonių aplinkoms Clarysec Reagavimo į incidentus politika prideda reglamentuojamų duomenų eskalavimo perspektyvą:
„Jei incidentas lemia patvirtintą arba tikėtiną asmens duomenų ar kitų reglamentuojamų duomenų atskleidimą, Teisės funkcija ir DAP turi įvertinti taikytinumą:“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.4.1.
Citata baigiasi ties aktyvinimo sąlyga – būtent ten, kur daug incidentų procesų sugenda. Jei aktyvinimo sąlyga neaiški, komandos ginčijasi dėl pranešimo pareigų, kai laikrodis jau tiksi.
Zenith Blueprint Kontrolės priemonių taikymo etapo 16 žingsnyje, Personalo kontrolės priemonės II, pabrėžiamas personalo inicijuojamas pranešimas apie incidentus. Darbuotojai, rangovai ir suinteresuotosios šalys turi žinoti, kaip atpažinti galimus saugumo incidentus ir apie juos pranešti naudojant paprastus kanalus, tokius kaip speciali pašto dėžutė, portalas arba karštoji linija. Blueprint susieja tai su GDPR Article 33, NIS2 Article 23 ir DORA Article 17, nes pranešimas reguliuotojui prasideda nuo vidinio informuotumo ir eskalavimo.
Zenith Controls ISO/IEC 27002:2022 kontrolės priemonė 5.24 „Informacijos saugumo incidentų valdymo planavimas ir pasirengimas“ susieta kaip korekcinė kontrolės priemonė, palaikanti konfidencialumą, vientisumą ir prieinamumą, suderinta su Respond ir Recover. Ji tiesiogiai siejasi su įvykių vertinimu, mokymusi iš incidentų, žurnalų tvarkymu ir stebėsena, saugumu sutrikimo metu, informacijos saugumo tęstinumu ir ryšiu su institucijomis. Vadovas susieja tai su DORA Articles 17 to 23 dėl su IRT susijusių incidentų valdymo, klasifikavimo, pranešimų teikimo ir savanoriško pranešimo apie kibernetines grėsmes, GDPR Articles 33 and 34 dėl pranešimo apie pažeidimus ir NIS2 Article 23 pranešimo apie incidentus.
DORA pasirengęs incidentų procesas turėtų apimti:
- Aiškius incidentų priėmimo kanalus.
- Įvykių triažo ir klasifikavimo kriterijus.
- Reikšmingo su IRT susijusio incidento eskalavimo darbo eigą.
- Teisės funkcijos, DAP ir reguliacinio pranešimo sprendimo taškus.
- Tiekėjo incidento pranešimo aktyvinimo sąlygas.
- Įrodymų išsaugojimo reikalavimus.
- Vadovybės ir valdybos komunikacijos taisykles.
- Peržiūrą po incidento ir įgytas pamokas.
- Sąsają su rizikų registro atnaujinimais ir kontrolės priemonių trūkumų šalinimu.
Papildomi standartai suteikia struktūrą. ISO/IEC 27035-1:2023 pateikia incidentų valdymo planavimo ir pasirengimo principus. ISO/IEC 27035-2:2023 detalizuoja incidentų tvarkymo veiksmus. ISO/IEC 22320:2018 palaiko vadovavimą, kontrolę ir struktūruotą krizių komunikaciją. Tai svarbu, kai IRT sutrikimas tampa klientams poveikį darančia krize ir subjektas turi parodyti, kad sprendimai buvo priimti laiku, koordinuotai ir grindžiami įrodymais.
Skaitmeninės veiklos atsparumo testavimas ir TLPT: neleiskite testui tapti incidentu
Testavimas yra viena dažniausiai ieškomų DORA 2026 temų, nes jis yra ir techninis, ir valdysenos požiūriu sudėtingas. Finansų subjektai turi testuoti IRT sistemas, kontrolės priemones ir procesus. Paskirtiems subjektams pažangus testavimas, toks kaip TLPT, tampa centriniu reikalavimu pagal DORA Article 26.
Audito klausimas nėra vien „Ar testavote?“ Jis yra „Ar testas buvo grindžiamas rizika, autorizuotas, saugus, nepriklausomas, kai reikalaujama, ar jo išvados pašalintos ir susietos su atsparumo tikslais?“
Clarysec Enterprise Saugumo testavimo ir raudonosios komandos politika aiškiai apibrėžia minimalią testavimo programą:
„Testų tipai: saugumo testavimo programa turi apimti bent: (a) pažeidžiamumų skenavimą, sudarytą iš automatizuotų savaitinių arba mėnesinių tinklų ir taikomųjų programų skenavimų žinomiems pažeidžiamumams identifikuoti; (b) skverbties testavimą, sudarytą iš rankinio išsamaus konkrečių sistemų arba taikomųjų programų testavimo, kurį atlieka kvalifikuoti testuotojai, siekdami nustatyti sudėtingas silpnąsias vietas; ir (c) raudonosios komandos pratybas, sudarytas iš scenarijais pagrįstų realių atakų simuliacijų, įskaitant socialinę inžineriją ir kitas taktikas, siekiant patikrinti visos organizacijos aptikimo ir reagavimo pajėgumus.“
Iš skyriaus „Įgyvendinimo reikalavimai“, politikos punktas 6.1.
Tai tiltas tarp įprastinio testavimo ir TLPT brandos. Pažeidžiamumų skenavimas randa žinomas silpnąsias vietas. Skverbties testavimas patvirtina išnaudojamumą. Raudonosios komandos pratybos testuoja aptikimą ir reagavimą kaip sistemą. TLPT, kai taikoma, turėtų būti valdoma testavimo programos dalis su apimties kontrole, saugos taisyklėmis, gamybinės aplinkos rizikos valdymu, įrodymų fiksavimu ir taisomųjų veiksmų sekimu.
Zenith Blueprint Kontrolės priemonių taikymo etapo 21 žingsnyje aptariama informacinių sistemų apsauga audito ir testavimo metu. Jame įspėjama, kad auditai, skverbties testai, kriminalistinės peržiūros ir veiklos vertinimai gali sukelti riziką, nes gali apimti padidintą prieigą, invazinius įrankius arba laikinus sistemos elgsenos pakeitimus. Blueprint susieja šį klausimą su GDPR Article 32, DORA skaitmeninės veiklos atsparumo testavimo lūkesčiais, NIS2 tęstinumo klausimais ir COBIT 2019 praktikomis saugiam auditų ir vertinimų vykdymui.
Zenith Controls ISO/IEC 27002:2022 kontrolės priemonė 5.35 „Nepriklausoma informacijos saugumo peržiūra“ susieta kaip prevencinė ir korekcinė, palaikanti konfidencialumą, vientisumą ir prieinamumą. Ji siejasi su politikų laikymusi, vadovybės atsakomybėmis, mokymusi iš incidentų, įrašų apsauga, informacijos ištrynimu, žurnalų tvarkymu ir stebėsena. DORA atveju aktualūs testavimo įpareigojimai pirmiausia yra Articles 24 to 27, įskaitant Article 26 dėl TLPT. Tai taip pat palaiko GDPR Article 32(1)(d), kuriame reikalaujama reguliariai testuoti ir vertinti technines ir organizacines priemones, ir NIS2 Article 21, kuriame reikalaujama kibernetinio saugumo rizikos valdymo priemonių.
DORA TLPT pasirengimo paketas turėtų apimti:
| TLPT pasirengimo elementas | Ką parengti | Audito vertė |
|---|---|---|
| Taikymo sritis ir tikslai | Kritinės funkcijos, sistemos, teikėjai, išimtys | Parodo rizika grindžiamą testavimo dizainą |
| Autorizavimas | Formalus patvirtinimas, veiklos taisyklės, avarinis sustabdymas | Įrodo saugų ir kontroliuojamą vykdymą |
| Grėsmių žvalgybos įvestis | Scenarijaus pagrindimas, atakuotojo profilis, poveikis verslui | Palaiko grėsmėmis grindžiamą metodiką |
| Gamybinės aplinkos saugos planas | Stebėsena, atsarginės kopijos, grąžinimas į ankstesnę būseną, komunikacija | Neleidžia testavimui sukelti sutrikimo |
| Tiekėjų koordinavimas | Teikėjų patvirtinimai, kontaktiniai asmenys, prieigos langai | Apima trečiųjų šalių priklausomybes |
| Įrodymų fiksavimas | Testų žurnalai, išvados, ekrano kopijos, įrodymų saugojimo grandinė, kai reikia | Palaiko audituojamumą |
| Taisomųjų veiksmų sekimas | Savininkai, datos, pakartotinio testavimo rezultatai, rizikos priėmimas | Parodo, kad testavimas lėmė pagerinimus |
| Įgytos pamokos | Aptikimo spragos, reagavimo spragos, kontrolės priemonių atnaujinimai | Susieja testavimą su atsparumo branda |
Pagrindinė DORA pamoka – testavimo įrodymai neturi baigtis ataskaita. Auditoriai klaus, ar išvados buvo įvertintos pagal riziką, priskirtos, pašalintos ir pakartotinai patikrintos. Jie taip pat gali tikrinti, ar testavimas apėmė kritines arba svarbias funkcijas, o ne tik į internetą nukreiptą turtą.
Veiklos tęstinumas ir atkūrimas po katastrofos: atsparumas turi veikti praktikoje
DORA yra skaitmeninės veiklos atsparumo reglamentas. Atkūrimas toks pat svarbus kaip prevencija. Dokumentuota IRT rizikos valdymo sistema nepadės, jei mokėjimų platformos sutrikimas atskleis, kad atkūrimo laiko tikslai niekada nebuvo testuoti, tiekėjų kontaktų medžiai pasenę, o krizių komanda nesutaria, kas komunikuoja su klientais.
Clarysec MVĮ Veiklos tęstinumo ir atkūrimo po katastrofos politika nustato aiškų bazinį reikalavimą:
„Organizacija privalo testuoti tiek savo BCP, tiek DR pajėgumus bent kartą per metus. Testai turi apimti:“
Iš skyriaus „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.4.1.
Enterprise Veiklos tęstinumo ir atkūrimo po katastrofos politika prasideda nuo poveikio verslui:
„Verslo poveikio analizė (BIA) turi būti atliekama bent kartą per metus visiems kritiniams verslo padaliniams ir peržiūrima įvykus reikšmingiems sistemų, procesų ar priklausomybių pokyčiams. BIA rezultatai turi apibrėžti:“
Iš skyriaus „Valdysenos reikalavimai“, politikos punktas 5.2.
DORA atveju BIA turėtų būti susieta su IRT turtu, tiekėjais, reagavimu į incidentus ir testavimu. Jei BIA identifikuoja „klientų mokėjimus“ kaip kritinę funkciją, tiekėjų priklausomybės registras turėtų identifikuoti ją palaikančius tvarkytojus, debesijos paslaugas ir tinklo paslaugų teikėjus. Rizikų registre turėtų būti sutrikimų scenarijai. Testavimo plane turėtų būti atsparumo patvirtinimas. Reagavimo į incidentus plane turėtų būti eskalavimas ir komunikacija. DR testas turėtų sukurti įrodymus, o ne vien posėdžio pastabą.
Šis atsekamumas paverčia DORA atitiktį veikiančia veiklos atsparumo sistema.
Kryžminė atitiktis: vienas įrodymų rinkinys, daug audito klausimų
Finansų subjektai retai susiduria vien su DORA. Jie dažnai turi GDPR įpareigojimus, NIS2 ekspoziciją, sutartinius saugumo įsipareigojimus, ISO/IEC 27001:2022 tikslus, vidaus audito reikalavimus, klientų deramą patikrinimą, SOC lūkesčius ir valdybos rizikos ataskaitas. Sprendimas nėra kurti atskiras įrodymų saugyklas. Sprendimas – sukurti kryžminės atitikties įrodymų modelį.
Zenith Controls yra Clarysec kryžminės atitikties kompasas. Jis nesukuria naujų įpareigojimų. Jis susieja oficialius standartus ir sistemas, kad organizacijos suprastų, kaip viena kontrolės sritis palaiko kelis atitikties rezultatus.
| DORA tema | ISO/IEC 27002:2022 kontrolės sritis Zenith Controls | Kryžminės atitikties vertė |
|---|---|---|
| IRT trečiųjų šalių priežiūra | 5.21 Informacijos saugumo valdymas IRT tiekimo grandinėje | Palaiko GDPR tvarkytojų priežiūrą, NIS2 tiekimo grandinės saugumą ir DORA IRT trečiųjų šalių riziką |
| Pranešimų apie incidentus teikimas ir incidentų valdymas | 5.24 Informacijos saugumo incidentų valdymo planavimas ir pasirengimas | Palaiko GDPR pranešimą apie pažeidimus, NIS2 pranešimą apie incidentus ir DORA pranešimą apie IRT incidentus |
| Testavimas ir patikinimas | 5.35 Nepriklausoma informacijos saugumo peržiūra | Palaiko GDPR testavimą ir vertinimą, NIS2 rizikos valdymą ir DORA skaitmeninės veiklos atsparumo testavimą |
Tai svarbu biudžetui ir valdysenai. CISO gali paaiškinti valdybai, kad incidentų klasifikavimo gerinimas palaiko DORA pranešimus, GDPR pranešimus apie pažeidimus, NIS2 incidentų tvarkymą ir vidinį atsparumą. Pirkimų vadovas gali pagrįsti tiekėjų priklausomybių atvaizdavimą, nes jis palaiko DORA koncentracijos rizikos valdymą, GDPR tvarkytojų deramą patikrinimą ir NIS2 tiekimo grandinės saugumą. Testavimo vadovas gali parodyti, kad raudonosios komandos pratybos ir nepriklausomos peržiūros palaiko DORA testavimą, GDPR kontrolės priemonių vertinimą ir platesnį patikinimą.
Audito perspektyva: kaip vertintojai tikrins jūsų DORA įrodymus
Pasirengimas DORA tampa realus, kai kas nors paprašo įrodymų. Skirtingi auditoriai ir vertintojai tą pačią temą nagrinės iš skirtingų kampų.
ISO/IEC 27001:2022 orientuotas auditorius pradės nuo ISVS logikos: taikymo sritis, rizikos vertinimas, rizikos tvarkymas, Annex A kontrolės priemonių taikomumas, vidaus auditas, vadovybės peržiūra ir įrodymai, kad kontrolės priemonės įgyvendintos. IRT tiekimo grandinės saugumo atveju jis vertins politikas, tiekėjų klasifikavimą, sutartines nuostatas, deramą patikrinimą ir nuolatinę stebėseną. Incidentų valdymo atveju jis tikrins planą, vaidmenis, eskalavimo kelius, priemones ir įrašus. Testavimo atveju jis tikėsis suplanuotų intervalų, nepriklausomumo, kai tinkama, taisomųjų veiksmų ir vadovybės peržiūros įvesties.
ISO/IEC 19011:2018 audito perspektyva orientuota į audito vykdymą. Zenith Controls audito metodikoje IRT tiekimo grandinės saugumui pažymima, kad auditoriai nagrinėja pirkimų politikas, RFP šablonus ir tiekėjų valdymo procesus, siekdami patikrinti, ar IRT specifiniai saugumo reikalavimai įtraukti nuo įsigijimo iki eksploatavimo nutraukimo. Incidentų valdymo atveju auditoriai nagrinėja reagavimo į incidentus planą dėl išsamumo ir suderinimo su geriausiomis praktikomis. Nepriklausomos peržiūros atveju auditoriai ieško įrodymų, kad nepriklausomi auditai arba peržiūros buvo atlikti.
ISO/IEC 27007:2020 perspektyva yra labiau specifinė ISVS auditui. Zenith Controls pažymi, kad auditoriai gali apklausti pirkimų pareigūnus, IT saugumo darbuotojus ir tiekėjų valdytojus, kad įvertintų IRT tiekimo grandinės kontrolės priemonių supratimą ir vykdymą. Incidentų pasirengimo atveju jie patvirtina, kad reagavimo į incidentus komanda egzistuoja ir veikia. Nepriklausomos peržiūros atveju jie patikrina, ar vidaus audito programa apima visą ISVS taikymo sritį ir yra tinkamai aprūpinta ištekliais.
NIST SP 800-115 informuotas testavimo vertintojas daugiausia dėmesio skirs pažeidžiamumų vertinimo ir skverbties testavimo metodikai. Jis gali nagrinėti, ar testavimo apimtis, veiklos taisyklės, išvados, sunkumo lygiai, taisomieji veiksmai ir pakartotinis testavimas yra dokumentuoti. DORA TLPT atveju tai reiškia, kad vertintojo netenkins raudonosios komandos skaidrių rinkinys. Jam reikės valdysenos, saugos, techninio gylio ir užbaigimo įrodymų.
COBIT 2019 arba ISACA stiliaus auditorius klaus, ar pasiekiami valdysenos tikslai: kas yra proceso savininkas, kaip matuojamas veiksmingumas, kaip tvirtinamos išimtys ir kaip vadovybė gauna patikinimą.
| Audito klausimas | Įrodymai, kurie į jį atsako | Dažna silpnoji vieta |
|---|---|---|
| Kaip žinote, kurios IRT paslaugos palaiko kritines funkcijas? | Kritinių funkcijų žemėlapis, IRT turto apskaita, BIA | Turto sąrašas nesusietas su poveikiu verslui |
| Kaip valdote IRT trečiųjų šalių koncentracijos riziką? | Tiekėjų priklausomybės registras, pakeičiamumo analizė, pasitraukimo planai | Tiekėjų sąrašas yra, priklausomybių analizės nėra |
| Kaip darbuotojai praneša apie incidentus? | Mokymų įrašai, pranešimo kanalas, incidentų užklausos | Pranešimo procesas egzistuoja, bet darbuotojai negali jo apibūdinti |
| Kaip klasifikuojate reikšmingus IRT incidentus? | Klasifikavimo matrica, eskalavimo darbo eiga, teisinės peržiūros įrašai | Klasifikavimo kriterijai netestuoti |
| Kaip įrodote, kad testavimas pagerino atsparumą? | Testų ataskaitos, taisomųjų veiksmų sekimo registras, pakartotinio testavimo įrodymai, įgytos pamokos | Išvados lieka atviros be rizikos priėmimo |
| Kaip apsaugote sistemas TLPT arba raudonosios komandos testų metu? | Veiklos taisyklės, patvirtinimai, stebėsena, sustabdymo kriterijai | Testavimas autorizuotas neformaliai |
| Kaip vadovybė prižiūri DORA riziką? | Atitikties registras, KPI/KRI paketas, vadovybės peržiūros protokolai | Ataskaitos valdybai pernelyg bendro pobūdžio |
Praktinis DORA 2026 pasirengimo kontrolinis sąrašas
Naudokite šį kontrolinį sąrašą kaip darbinę bazę DORA paieškoms paversti veiksmais.
Valdysena ir RTS/ITS susiejimas
- Palaikykite DORA atitikties registrą, kuriame nurodyta įpareigojimų sritis, taikomumas, savininkas, įrodymai, peržiūros dažnis ir spragų būsena.
- Susiekite DORA reikalavimus su politikomis, registrais, kontrolės priemonėmis ir vadovybės ataskaitomis.
- Apibrėžkite proporcingumo pagrindimą supaprastintam arba sumažintos apimties IRT rizikos valdymui, kai taikoma.
- Priskirkite vykdomosios vadovybės atskaitomybę už IRT riziką, pranešimų apie incidentus teikimą, trečiųjų šalių priežiūrą ir testavimą.
- Įtraukite DORA būseną į vadovybės peržiūrą ir valdybos rizikos ataskaitas.
IRT rizikos valdymas
- Palaikykite IRT rizikų registrą su aprašymu, tikimybe, poveikiu, balu, savininku ir rizikos tvarkymo planu.
- Susiekite rizikas su kritinėmis arba svarbiomis funkcijomis.
- Susiekite rizikas su IRT turtu, tiekėjais ir procesais.
- Peržiūrėkite rizikas po reikšmingų incidentų, tiekėjų pakeitimų, technologijų pakeitimų arba testų išvadų.
- Sekite rizikos tvarkymo veiksmus iki užbaigimo arba formalaus rizikos priėmimo.
Trečiųjų šalių IRT priežiūra
- Palaikykite tiekėjų registrą ir tiekėjų priklausomybės registrą.
- Identifikuokite tiekėjus, palaikančius kritines arba svarbias funkcijas.
- Įvertinkite vienintelio tiekimo šaltinio tiekėjus ir pakeičiamumą.
- Peržiūrėkite subtiekėjus ir subrangos susitarimus.
- Įtraukite saugumo, prieigos, pranešimo apie incidentus, audito ir pasitraukimo nuostatas į sutartis.
- Stebėkite kritinius tiekėjus bent kartą per metus arba po esminių pokyčių.
- Palaikykite pasitraukimo ir nenumatytų atvejų planus didelės priklausomybės teikėjams.
Incidentų valdymas ir pranešimų apie juos teikimas
- Palaikykite reagavimo į incidentus procedūras su aiškiais vaidmenimis ir eskalavimo keliais.
- Apibrėžkite IRT incidentų klasifikavimo kriterijus.
- Suderinkite DORA pranešimo aktyvinimo sąlygas su GDPR, NIS2 ir sutartiniais pranešimo įpareigojimais.
- Mokykite darbuotojus ir rangovus naudotis incidentų pranešimo kanalais.
- Palaikykite incidentų žurnalus, sprendimų įrašus ir įrodymus.
- Atlikite peržiūras po incidento ir atnaujinkite rizikas bei kontrolės priemones.
Testavimas, raudonosios komandos pratybos ir TLPT
- Palaikykite rizika grindžiamą testavimo kalendorių.
- Atlikite pažeidžiamumų skenavimą ir skverbties testavimą nustatytais intervalais.
- Naudokite scenarijais pagrįstas raudonosios komandos pratybas aptikimui ir reagavimui testuoti.
- TLPT pasirengimui apibrėžkite taikymo sritį, veiklos taisykles, saugos kontrolės priemones ir tiekėjų koordinavimą.
- Apsaugokite gamybines sistemas testavimo metu.
- Sekite išvadas, taisomuosius veiksmus, pakartotinį testavimą ir įgytas pamokas.
- Praneškite testavimo rezultatus vadovybei.
Tęstinumas ir atkūrimas
- Kasmet atlikite BIA kritiniams verslo padaliniams ir atnaujinkite po reikšmingų pokyčių.
- Apibrėžkite atkūrimo tikslus kritinėms funkcijoms ir jas palaikančioms IRT paslaugoms.
- Testuokite BCP ir DR pajėgumus bent kartą per metus.
- Įtraukite tiekėjo paslaugų nepasiekiamumo ir kibernetinio incidento scenarijus.
- Išsaugokite testų įrodymus, spragas, taisomuosius veiksmus ir pakartotinio testavimo rezultatus.
- Suderinkite tęstinumo planus su reagavimu į incidentus ir krizių komunikacija.
Kaip Clarysec padeda finansų subjektams pereiti nuo paieškos rezultatų prie auditui tinkamų įrodymų
DORA 2026 pasirengimas nepasiekiamas atsisiuntus kontrolinį sąrašą ir tikintis, kad organizacija vėliau užpildys spragas. Reikia struktūruoto veiklos modelio, kuris sujungtų riziką, tiekėjus, incidentus, testavimą, tęstinumą ir audito įrodymus.
Clarysec požiūris sujungia tris sluoksnius.
Pirma, Zenith Blueprint pateikia įgyvendinimo veiksmų planą. 14 žingsnis padeda organizacijoms susieti reglamentavimo reikalavimus su rizikos tvarkymu ir politikomis. 16 žingsnis stiprina personalo inicijuojamą pranešimą apie incidentus. 21 žingsnis užtikrina, kad auditai ir testai nekeltų pavojaus gamybinėms sistemoms. 23 žingsnis paverčia tiekėjų priežiūrą praktine darbo eiga, apimančia klasifikavimą, sutartis, subtiekėjus, stebėseną ir debesijos vertinimą.
Antra, Clarysec politikos suteikia valdyseną, kurią galima iš karto operacionalizuoti. Rizikos valdymo politika, Teisinės ir reglamentavimo atitikties politika, Trečiųjų šalių ir tiekėjų saugumo politika, Tiekėjų priklausomybės rizikos valdymo politika, Reagavimo į incidentus politika, Saugumo testavimo ir raudonosios komandos politika ir Veiklos tęstinumo ir atkūrimo po katastrofos politika suteikia komandoms konkrečius punktus, atsakomybės modelius ir įrodymų lūkesčius.
Trečia, Zenith Controls pateikia kryžminės atitikties žemėlapį. Jis parodo, kaip IRT tiekimo grandinės saugumas, incidentų valdymo planavimas ir nepriklausoma peržiūra siejasi su 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 ir NIST testavimo praktikomis.
Rezultatas – DORA atitikties programa, kuri yra pagrindžiama audito metu ir naudinga realaus incidento, tiekėjo sutrikimo ar atsparumo testo metu.
Kitas žingsnis: sukurkite DORA įrodymų paketą iki kito audito prašymo
Jei jūsų komanda vis dar ieško „DORA RTS/ITS kontrolinio sąrašo“, „DORA IRT rizikos valdymo šablono“, „DORA trečiųjų šalių priežiūros“ arba „DORA TLPT reikalavimų“, kitas žingsnis – paversti šias paieškas kontroliuojamais įrodymais.
Šią savaitę pradėkite nuo keturių veiksmų:
- Sukurkite arba atnaujinkite DORA atitikties registrą naudodami Clarysec politikos modelį.
- Pasirinkite vieną kritinę funkciją ir atsekite ją per rizikų registrą, tiekėjų priklausomybės registrą, incidentų darbo eigą, BIA ir testavimo planą.
- Peržiūrėkite penkis svarbiausius IRT tiekėjus dėl pakeičiamumo, subtiekėjų, incidentų nuostatų ir pasitraukimo galimybių.
- Sukurkite testavimo įrodymų paketą su taikymo sritimi, autorizavimu, rezultatais, taisomaisiais veiksmais ir pakartotiniu testavimu.
Clarysec gali padėti tai įgyvendinti naudojant Zenith Blueprint, politikų šablonus ir Zenith Controls, kad jūsų DORA 2026 programa būtų praktiška, proporcinga ir tinkama auditui.
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


