DORA 2026 tegevuskava IKT-riskide, teenuseosutajate ja TLPT jaoks

DORA 2026 otsingupaanika ei puuduta tegelikult regulatsiooni, vaid tõendusmaterjali
On esmaspäeva hommik kell 08.15 ja keskmise suurusega makseasutuse infoturbejuhi brauseris on avatud kolm vahekaarti: „DORA RTS/ITS kontrollnimekiri“, „DORA kolmandatest isikutest IKT-teenuse osutajate registri mall“ ja „TLPT nõuded finantsüksustele“.
Nõuetele vastavuse juht on juba küsinud, kas juhatuse materjalid peaksid sisaldama uusimat intsidentide klassifitseerimise töövoogu. Hankemeeskond soovib kasutusele võtta uue pilvepõhise analüütikaplatvormi. COO soovib kinnitust, et põhilisel panganduse SaaS-teenusepakkujal puudub varjatud alltöövõtjate kokkupuude väljaspool EL-i. Siseaudit küsib testimiskalendrit. Õigusosakond küsib, kas GDPR-i kohased isikuandmetega seotud rikkumisest teavitamise tähtajad on viidud kooskõlla DORA intsidentidest teatamisega.
Keegi ei küsi teoreetilist küsimust. Nad küsivad: „Kas suudame selle reedeks tõendada?“
See on DORA 2026 tegelik probleem. Enamik finantsüksusi mõistab põhikohustusi: IKT-riskide juhtimine, IKT-ga seotud intsidentidest teatamine, digitaalse tegevuskerksuse testimine, kolmandatest isikutest IKT-teenuse osutajate riskijuhtimine ning kriitiliste IKT-teenuse osutajate tugevam järelevalve. Keeruline osa on regulatiivsete tehniliste standardite, rakenduslike tehniliste standardite ja artiklitasandi kohustuste teisendamine kontrollitud, korratavaks ja auditeeritavaks praktikaks.
DORA ehk digitaalse tegevuskerksuse määrus nõuab finantsüksustelt tugevat IKT-riskide juhtimise võimekust, poliitikaid IKT-ga seotud intsidentide haldamiseks ja neist teatamiseks, IKT-süsteemide, kontrollimeetmete ja protsesside testimist ning kolmandatest isikutest IKT-teenuse osutajate struktureeritud järelevalvet. Samuti eeldab see proportsionaalsust. Väiksem investeerimisühing ja suur pangandusgrupp ei vaja identseid tõendusmudeleid, kuid mõlemad peavad tõendama, et nende lähenemine sobib nende suuruse, riskiprofiili, keerukuse ja kriitiliste funktsioonidega.
DORA projektid ebaõnnestuvad tavaliselt ühel kolmest põhjusest. Esiteks käsitleb organisatsioon DORA-t õigusliku vastendamise harjutusena, mitte toimimismudelina. Teiseks dokumenteeritakse teenuseosutajate risk teenuseosutajate loendina, mitte sõltuvuse, asendatavuse ja kontsentratsiooniriskina. Kolmandaks käsitletakse testimist iga-aastase penetratsioonitestina, mitte tegevuskerksuse programmina, mis hõlmab haavatavuste skannimist, stsenaariumipõhist testimist, intsidentide õppusi ja kohaldumise korral ohupõhist penetratsioonitestimist, mida sageli otsitakse TLPT nime all.
Parem lähenemine on luua ühtne tõendussüsteem, mis seob poliitikad, registrid, vastutajad, riskid, intsidendid, teenuseosutajad, testimise, taastamise ja juhtkonna läbivaatuse. Siin aitavad Clarysec Zenith Blueprint, kasutusvalmis poliitikad ja Zenith Controls finantsüksustel muuta DORA tähtajast toimivaks juhtimisrütmiks.
Alustage DORA toimimismudelist, mitte RTS/ITS tabelist
Paljud meeskonnad alustavad tabelist, kuhu on kantud DORA artiklid ja RTS/ITS nõuded. See on kasulik, kuid sellest ei piisa. Tabel võib öelda, mis peab olemas olema. See ei määra vastutajaid, ei sätesta läbivaatuse sagedust, ei säilita tõendusmaterjali ega tõenda, et kontrollimeede tegelikult toimib.
Dokumendis Zenith Blueprint: audiitori 30-sammuline tegevuskava käsitleb Clarysec seda riskijuhtimise etapis, sammus 14 „Riski käsitlemise poliitikad ja regulatiivsed ristviited“:
„DORA: finantssektori ettevõtete puhul nõuab DORA IKT-riskide juhtimise raamistikku, mis on väga hästi kooskõlas sellega, mida oleme teinud: riskide tuvastamine, kontrollimeetmete ja poliitikate rakendamine ning nende testimine. DORA rõhutab ka intsidentidele reageerimist ja neist teatamist ning kolmandatest isikutest IKT-teenuse osutajate järelevalvet.“
Praktiline sõnum on lihtne: ärge ehitage „DORA nõuetele vastavust“ paralleelse bürokraatiana. Looge riskipõhine IKT juhtimiskiht, mis seob DORA nõuded poliitikate, registrite, kontrollimeetmete eest vastutajate, testimiskirjete, teenuseosutajate tõendusmaterjali ja juhtkonna läbivaatusega.
Praktilisel DORA toimimismudelil peaks olema viis tõendussammast:
| DORA tõendussammas | Praktiline artefakt | Tüüpiline vastutaja | Clarysec tööriistakomplekti ankur |
|---|---|---|---|
| IKT-riskide juhtimine | IKT-riskiregister, riski käsitlemise plaan, kontrollimeetmete vastendus | CISO või riskiomanik | Riskijuhtimise poliitika ja Zenith Blueprint samm 14 |
| IKT intsidentide haldus | Intsidentidele reageerimise plaan, klassifitseerimismaatriks, teavitustöövoog, õppetundide logi | Turbeoperatsioonid, õigusosakond, DPO | Intsidentidele reageerimise poliitika ja Zenith Blueprint samm 16 |
| Kolmandatest isikutest IKT-teenuse osutajate järelevalve | Teenuseosutajate register, sõltuvusregister, alltöövõtjate läbivaatus, väljumisplaanid | Tarnijahaldus, hankefunktsioon, CISO | Kolmandate isikute ja tarnijate turbepoliitika, teenuseosutajate sõltuvuse riskijuhtimise poliitika, Zenith Blueprint samm 23 |
| Digitaalse tegevuskerksuse testimine | Testimiskalender, haavatavuste skannimised, penetratsioonitestid, ründetiimi käsitlusala, TLPT juhtimine | Turbetestimise juht, IT-operatsioonid | Turbetestimise ja ründetiimi poliitika ning Zenith Blueprint samm 21 |
| Talitluspidevus ja taaste | BIA, BCP, DR-testid, taaste tõendusmaterjal, kriisikommunikatsioon | COO, IT talitluspidevuse eest vastutaja | Talitluspidevuse poliitika ja katastroofitaaste poliitika |
Reguleeritud finantsüksuste puhul muudab see struktuur RTS/ITS rakendamise auditivalmis tõendussüsteemiks. Lihtsustatud IKT-riskide juhtimise alla kuuluvate üksuste puhul saab sama mudelit skaleerida vähemate dokumentide ja lihtsamate registriteni. Põhidistsipliinid jäävad samaks: tuvasta, kaitse, avasta, reageeri, taasta, testi ja juhi teenuseosutajaid.
IKT-riskide juhtimine: register on juhtimiskeskus
DORA IKT-riskide juhtimise ootused nõuavad, et finantsüksused tuvastaksid, klassifitseeriksid ja juhiksid IKT-riske süsteemide, andmete, protsesside, kriitiliste või oluliste funktsioonide ning kolmandatest isikutest sõltuvuste lõikes.
Levinud puudus ei ole riskiregistri puudumine. Puudus seisneb selles, et register ei ole seotud teenuseosutajate, varade, intsidentide ja testidega. DORA ei premeeri ilusat tabelit, kui see ei selgita, miks kõrge riskiga teenuseosutajal puudub väljumisplaan või miks kriitilist kliendimaksete platvormi ei ole testitud.
Clarysec SME Riskijuhtimise poliitika annab väiksematele finantsüksustele lühikese tõendatava baastaseme:
„Iga riskikirje peab sisaldama: kirjeldust, tõenäosust, mõju, skoori, omanikku ja riski käsitlemise plaani.“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.1.2.
Suuremate finantsüksuste jaoks nõuab Clarysec Enterprise Riskijuhtimise poliitika formaalsemat protsessi:
„Ametlikku riskijuhtimise protsessi tuleb hoida kooskõlas ISO/IEC 27005 ja ISO 31000 nõuetega, hõlmates riskide tuvastamist, analüüsi, hindamist, käsitlemist, seiret ja kommunikatsiooni.“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.1.
See eristus on oluline. DORA on proportsionaalne, kuid proportsionaalsus ei tähenda mitteametlikkust. Väike makseasutus võib kasutada lihtsustatud registrit, samas kui pangandusgrupp võib kasutada integreeritud GRC-tööriistu. Mõlemal juhul küsib audiitor siiski: millised on teie IKT-riskid? Kes nende eest vastutab? Milline on käsitlusplaan? Milline tõendusmaterjal näitab edenemist? Kuidas mõjutavad teenuseosutajad ja kriitilised funktsioonid skoori?
Tugev DORA IKT-riskiregister peaks sisaldama järgmisi välju:
| Väli | Miks see on DORA 2026 jaoks oluline | Näide |
|---|---|---|
| Kriitiline või oluline funktsioon | Seob riski talitluspidevusega | Kaardimaksete töötlemine |
| Toetav IKT-vara või teenus | Näitab tehnoloogiasõltuvust | Maksevärava API |
| Teenuseosutaja või sisemine omanik | Tuvastab vastutuse | Pilveteenuse osutaja ja maksete arendusmeeskond |
| Riskikirjeldus | Selgitab stsenaariumi | API katkestus blokeerib klienditehingud |
| Tõenäosus, mõju ja skoor | Toetab riskide prioriseerimist | Keskmine tõenäosus, suur mõju |
| Riski käsitlemise plaan | Muudab hindamise tegevuseks | Lisa ümberlülitustee ja testi taastamist kord kvartalis |
| Kontrollimeetmete vastendus | Seob tõendusmaterjali raamistikuga | Intsidentidele reageerimine, teenuseosutajate järelevalve, logimine, talitluspidevus |
| Läbivaatuse kuupäev | Näitab, et risk on ajakohane | Kvartaalselt või pärast olulist teenuseosutaja muudatust |
Praktiline harjutus on võtta üks kriitiline IKT-teenus, näiteks pilvekeskkonnas majutatud tehinguseire platvorm, ja luua 20 minutiga riskikirje. Kirjeldage tõrke või kompromiteerimise stsenaarium, hinnake tõenäosust ja mõju, määrake vastutaja, tuvastage seotud teenuseosutajad, määratlege riski käsitlemise plaan ning siduge kirje tõendusmaterjaliga, nagu teenuseosutaja hoolsuskontroll, SLA, intsidendiklauslid, BIA, DR-testide tulemused, seire juhtpaneelid ja juurdepääsuõiguste ülevaatused.
See üks kirje muutub niidiks, mis seob DORA IKT-riskide juhtimise, kolmandatest isikutest teenuseosutajate järelevalve, intsidentide tuvastamise, talitluspidevuse ja testimise. Nii muutub riskiregister juhtimiskeskuseks, mitte toimikukapiks.
RTS/ITS valmisolek: siduge kohustused poliitikatega, mitte lubadustega
Praktiline otsingutermin „DORA RTS/ITS kontrollnimekiri“ tähendab tavaliselt: „Milliseid dokumente järelevalveasutused ootavad?“ Finantsüksused peaksid vältima nõuetele vastavuse lubamist üldsõnaliste avalduste kaudu. Neil on vaja vastendust, mis seob iga kohustuse poliitika, kontrollimeetme, vastutaja ja tõendusmaterjali üksusega.
Clarysec SME Õigusnormidele vastavuse poliitika kehtestab lihtsa juhtimisankru:
„Tegevjuht peab pidama lihtsat, struktureeritud vastavusregistrit, milles on loetletud:“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.1.1.
DORA 2026 jaoks peaks teie vastavusregister sisaldama järgmist:
- DORA kohustus või RTS/ITS nõudevaldkond.
- Kohaldatavus, sealhulgas proportsionaalsuse põhjendus.
- Viide poliitikale või protseduurile.
- Kontrollimeetme eest vastutaja.
- Tõendusmaterjali asukoht.
- Läbivaatuse sagedus.
- Avatud lüngad ja parandusmeetmete tähtaeg.
- Juhatuse või juhtkonna aruandluse staatus.
See on kooskõlas Zenith Blueprint sammu 14 lähenemisega: vastendage regulatiivsed nõuded infoturbe juhtimissüsteemi (ISMS) kontrollimeetmete ja poliitikatega, et midagi ei jääks märkamata. Selle asemel et küsida „Kas oleme DORA-le vastavad?“, saab juhtkond küsida: „Millised DORA tõendusüksused on tähtaja ületanud, millistel kriitilistel teenuseosutajatel puuduvad väljumisplaanid ja millised testimistegevused ei ole veel andnud parandusmeetmete tõendusmaterjali?“
Kolmandatest isikutest IKT-teenuse osutajate risk: kontsentratsioon, asendatavus ja alltöövõtjad
DORA on muutnud teenuseosutajate käsitlemist finantsteenustes. Enam ei piisa küsimusest, kas teenuseosutajal on turvasertifitseering, kindlustus või andmetöötlusleping. Finantsüksused peavad hindama, kas teenuseosutaja tekitab kontsentratsiooniriski, kas teenuseosutajat saab realistlikult asendada, kas mitu kriitilist teenust sõltuvad ühest või seotud teenuseosutajatest ning kas alltöövõtt lisab täiendavat õiguslikku või tegevuskerksuse kokkupuudet.
Just see küsimus hoiab paljusid infoturbejuhte öösiti üleval. Ettevõte võib tugineda ühele suurele pilveteenuse osutajale tehingute töötlemisel, andmeanalüütikas, kliendiportaalides ja sisemises koostöös. Kui sellel teenuseosutajal tekib pikaajaline katkestus, regulatiivne vaidlus või alltöövõtja tõrge, ei ole küsimus ainult „Kas meil on leping?“. Küsimus on: „Kas suudame jätkata kriitilisi teenuseid, suhelda klientidega ja tõendada, et mõistsime sõltuvust enne selle realiseerumist?“
Clarysec SME Kolmandate isikute ja tarnijate turbepoliitika loob aluse:
„Tarnijaregistrit peab pidama ja ajakohastama haldus- või hankekontakt. See peab sisaldama:“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.4.
Ettevõtte taseme programmide jaoks käsitleb Clarysec Tarnijasõltuvuse riskijuhtimise poliitika põhjalikumalt DORA-spetsiifilist sõltuvust ja asendatavust:
„Tarnijasõltuvuste register: VMO peab pidama ajakohast registrit kõigist kriitilistest tarnijatest, sealhulgas sellistest andmetest nagu osutatavad teenused/tooted; kas tarnija on ainus allikas; olemasolevad alternatiivsed tarnijad või asendatavus; kehtivad lepingutingimused; ning hinnang mõjule, kui tarnija ebaõnnestuks või kompromiteeritaks. Register peab selgelt tuvastama suure sõltuvusega tarnijad (nt need, kelle puhul puudub kiiresti kasutusele võetav alternatiiv).“
Jaotisest „Rakendamise nõuded“, poliitika punkt 6.1.
See on teenuseosutajate tõendusmaterjal, mis DORA projektides sageli puudub. Tarnijaregister ütleb, kes on tarnija. Sõltuvusregister ütleb, mis juhtub, kui teenuseosutaja tõrgub.
Zenith Blueprint, kontrollimeetmete rakendamise faas, samm 23 „Organisatsioonilised kontrollimeetmed“, annab praktilise töövoo teenuseosutajate järelevalveks. See soovitab koostada täieliku tarnijate loendi, klassifitseerida tarnijad süsteemidele, andmetele või operatiivsele kontrollile juurdepääsu alusel, kontrollida, et turbeootused oleksid lepingutesse sisse viidud, juhtida alltöövõtjate ja allavoolu riske, määratleda muudatuste ja seire protseduurid ning luua pilveteenuste hindamise protsess.
Dokumendis Zenith Controls: ristvastavuse juhend on ISO/IEC 27002:2022 kontrollimeede 5.21 „Infoturbe juhtimine IKT tarneahelas“ vastendatud ennetava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. See on seotud tarnijasuhete turbe ja küberjulgeoleku funktsiooniga Tuvasta. See seostub turvalise projekteerimise, turvalise programmeerimise, juurdepääsukontrolli, turbetestimise, tõendite kogumise, turvalise arenduse elutsükli ja allhankearendusega.
See on täpselt DORA kolmandatest isikutest teenuseosutajate järelevalve tegelikkus. Tarnijarisk ei ole ainult hanke teema. See puudutab arhitektuuri, arendust, intsidentidele reageerimist, juurdepääsukontrolli, talitluspidevust ja õigust.
| Küsimus | Säilitatav tõendusmaterjal | Miks audiitorid sellest hoolivad |
|---|---|---|
| Kas teenuseosutaja on seotud kriitilise või olulise funktsiooniga? | Kriitiliste funktsioonide kaart, tarnijaregister | Näitab proportsionaalsust ja prioriseerimist |
| Kas teenuseosutaja on ainus allikas või raskesti asendatav? | Tarnijasõltuvuste register, väljumisanalüüs | Tõendab kontsentratsiooniriski juhtimist |
| Kas alltöövõtjad on tuvastatud ja hinnatud? | Alltöövõtjate loend, edasiulatuvad lepinguklauslid, kinnituste aruanded | Käsitleb allavoolu IKT tarneahela riski |
| Kas intsidentidest teatamise kohustused on lepinguliselt määratletud? | Lepinguklauslid, intsidendist teavitamise töövoog | Toetab DORA intsidendi eskaleerimist |
| Kas turbenõuded on hankeprotsessi sisse viidud? | RFP mallid, hoolsuskontrolli kontrollnimekiri, heakskiidukirjed | Näitab, et kontrollimeetmeid rakendatakse enne kaasamist |
| Kas teenuseosutaja muudatused hinnatakse uuesti? | Muudatuse käivitajad, läbivaatuse kirjed, ajakohastatud riskikirje | Väldib riski vaikset kasvu |
| Kas olemas on väljumis- või varuplaan? | Väljumisplaan, alternatiivse teenuseosutaja analüüs, DR-sõltuvustest | Toetab tegevuskerksust |
Ristvastavuse vaates seob Zenith Controls IKT tarneahela turbe GDPR Articles 28 ja 32 nõuetega, sest volitatud töötlejad ja alltöötlejad tuleb valida ja nende üle järelevalvet teha asjakohaste tehniliste ja korralduslike meetmetega. See toetab NIS2 tarneahela turbe ootusi, sealhulgas Article 21 küberjulgeoleku riskijuhtimise meetmeid ja Article 22 koordineeritud tarneahela riskihindamisi. See vastendub tugevalt DORA Articles 28, 29 ja 30-ga, kus kolmandatest isikutest IKT-teenuse osutajate risk, kontsentratsioonirisk, allhange ja lepingulised sätted on keskse tähtsusega.
Toetavad standardid tugevdavad tõendusmaterjali. ISO/IEC 27036-3:2021 toetab IKT hankimist ja tarnijate valiku turvet. ISO/IEC 20243:2018 toetab usaldusväärse tehnoloogiatoote terviklust ja tarneahela turvet. ISO/IEC 27001:2022 seob selle riski käsitlemise ja Annex A tarnijakontrollidega.
Intsidentidest teatamine: ehitage eskaleerimisahel enne intsidenti
DORA intsidentidest teatamine ei tähenda üksnes teavituse esitamist. See tähendab IKT-ga seotud intsidentide avastamist, klassifitseerimist, eskaleerimist, kommunikatsiooni ja nendest õppimist. Finantsüksused peavad pidama IKT intsidentide haldamise ja neist teatamise protsesse, millel on määratletud rollid, klassifitseerimiskriteeriumid, teavitusteed ja intsidendijärgne analüüs.
Clarysec SME Intsidentidele reageerimise poliitika seob intsidentidele reageerimise tähtajad õiguslike nõuetega:
„Reageerimise tähtajad, sealhulgas andmete taastamise ja teavitamiskohustused, peavad olema dokumenteeritud ja kooskõlas õiguslike nõuetega, näiteks GDPR-i 72-tunnise isikuandmetega seotud rikkumisest teavitamise nõudega.“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.3.2.
Ettevõtte keskkondade jaoks lisab Clarysec Intsidentidele reageerimise poliitika reguleeritud andmete eskaleerimise vaate:
„Kui intsident põhjustab isikuandmete või muude reguleeritud andmete kinnitatud või tõenäolise avalikuks saamise, peavad õigusfunktsioon ja DPO hindama järgmise kohaldatavust:“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.4.1.
Tsitaat lõpeb käivitaja juures, mis on täpselt koht, kus paljud intsidendiprotsessid ebaõnnestuvad. Kui käivitaja on ebaselge, vaidlevad meeskonnad teavitamiskohustuste üle ajal, mil kell juba käib.
Zenith Blueprint, kontrollimeetmete rakendamise faas, samm 16 „Inimressursside kontrollid II“, rõhutab personalipõhist intsidentidest teatamist. Töötajad, töövõtjad ja sidusrühmad peavad teadma, kuidas lihtsate kanalite, näiteks spetsiaalse postkasti, portaali või infoliini kaudu võimalikke turbeintsidente ära tunda ja neist teatada. Blueprint seob selle GDPR Article 33, NIS2 Article 23 ja DORA Article 17-ga, sest regulatiivne teatamine algab sisemisest teadlikkusest ja eskaleerimisest.
Zenith Controls raames on ISO/IEC 27002:2022 kontrollimeede 5.24 „Infoturbeintsidentide haldamise planeerimine ja ettevalmistus“ vastendatud korrigeeriva kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust ning on kooskõlas funktsioonidega Reageeri ja Taasta. See seostub otseselt sündmuste hindamise, intsidentidest õppimise, logimise ja seire, häireolukorra turbe, infoturbe talitluspidevuse ja ametiasutustega suhtlemisega. Juhend vastendab selle DORA Articles 17 to 23-ga IKT-ga seotud intsidentide haldamise, klassifitseerimise, teatamise ja vabatahtliku küberohu teavitamise jaoks, GDPR Articles 33 ja 34-ga rikkumisest teavitamise jaoks ning NIS2 Article 23-ga intsidendist teavitamise jaoks.
DORA-valmis intsidendiprotsess peaks sisaldama järgmist:
- Selged intsidendi vastuvõtukanalid.
- Sündmuse triaaž ja klassifitseerimiskriteeriumid.
- Olulise IKT-ga seotud intsidendi eskaleerimistöövoog.
- Õigusfunktsiooni, DPO ja regulatiivse teavitamise otsustuspunktid.
- Teenuseosutaja intsidenditeavituse käivitajad.
- Tõendusmaterjali säilitamise nõuded.
- Tippjuhtkonna ja juhatuse kommunikatsioonireeglid.
- Intsidendijärgne läbivaatus ja õppetunnid.
- Seos riskiregistri ajakohastamise ja kontrollimeetmete parandusmeetmetega.
Toetavad standardid annavad struktuuri. ISO/IEC 27035-1:2023 annab intsidentide haldamise planeerimise ja ettevalmistuse põhimõtted. ISO/IEC 27035-2:2023 kirjeldab intsidendi käsitlemise etappe. ISO/IEC 22320:2018 toetab juhtimist, ohjet ja struktureeritud kriisikommunikatsiooni. See on oluline siis, kui IKT-katkestusest saab klientidele mõju avaldav kriis ja üksus peab näitama, et otsused olid õigeaegsed, koordineeritud ja tõenduspõhised.
Digitaalse tegevuskerksuse testimine ja TLPT: ärge laske testil muutuda intsidendiks
Testimine on üks enim otsitud DORA 2026 teemasid, sest see on ühtaegu tehniline ja juhtimismahukas. Finantsüksused peavad testima IKT-süsteeme, kontrollimeetmeid ja protsesse. Määratud üksuste puhul muutub täiustatud testimine, nagu TLPT, keskseks nõudeks DORA Article 26 alusel.
Auditiküsimus ei ole ainult „Kas te testisite?“. Küsimus on: „Kas test oli riskipõhine, autoriseeritud, ohutu, vajaduse korral sõltumatu, parandusmeetmetega käsitletud ja seotud tegevuskerksuse eesmärkidega?“
Clarysec Enterprise Turbetestimise ja ründetiimi poliitika määratleb minimaalse testimisprogrammi selgelt:
„Testide tüübid: turbetestimise programm peab minimaalselt hõlmama: (a) haavatavuste skannimist, mis koosneb võrkude ja rakenduste automaatsetest iganädalastest või igakuistest skannimistest teadaolevate haavatavuste tuvastamiseks; (b) penetratsioonitestimist, mis koosneb konkreetsete süsteemide või rakenduste käsitsi süvitsi testimisest kvalifitseeritud testijate poolt keerukate nõrkuste tuvastamiseks; ning (c) ründetiimi harjutusi, mis koosnevad tegelike rünnete stsenaariumipõhistest simulatsioonidest, sealhulgas sotsiaalne manipulatsioon ja muud taktikad, et testida organisatsiooni tuvastus- ja reageerimisvõimekust tervikuna.“
Jaotisest „Rakendamise nõuded“, poliitika punkt 6.1.
See on sild tavapärase testimise ja TLPT küpsuse vahel. Haavatavuste skannimine leiab teadaolevad nõrkused. Penetratsioonitestimine valideerib ärakasutatavuse. Ründetiimi testimine testib tuvastust ja reageerimist süsteemina. TLPT, kui see kohaldub, peab paiknema juhitud testimisprogrammi sees koos käsitlusala kontrolli, ohutusreeglite, tootmiskeskkonna riskijuhtimise, tõendusmaterjali kogumise ja parandusmeetmete jälgimisega.
Zenith Blueprint, kontrollimeetmete rakendamise faas, samm 21, käsitleb infosüsteemide kaitset auditi ja testimise ajal. See hoiatab, et auditid, penetratsioonitestid, kohtuekspertiisi ülevaatused ja operatiivsed hindamised võivad tekitada riski, kuna need võivad hõlmata kõrgendatud või administraatoriõigustega juurdepääsu, pealetükkivaid tööriistu või ajutisi muudatusi süsteemi käitumises. Blueprint seob selle mure GDPR Article 32, DORA digitaalse tegevuskerksuse testimise ootuste, NIS2 talitluspidevuse küsimuste ja COBIT 2019 praktikatega auditite ja hindamiste ohutuks läbiviimiseks.
Zenith Controls raames on ISO/IEC 27002:2022 kontrollimeede 5.35 „Infoturbe sõltumatu läbivaatamine“ vastendatud ennetava ja korrigeeriva kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust. See seostub poliitikate järgimise, juhtkonna vastutuste, intsidentidest õppimise, kirjete kaitse, teabe kustutamise ning logimise ja seirega. DORA puhul on asjakohased testimiskohustused peamiselt Articles 24 to 27, sealhulgas Article 26 TLPT jaoks. See toetab ka GDPR Article 32(1)(d), mis nõuab tehniliste ja korralduslike meetmete regulaarset testimist ja hindamist, ning NIS2 Article 21, mis nõuab küberjulgeoleku riskijuhtimise meetmeid.
DORA TLPT valmisolekupakett peaks sisaldama järgmist:
| TLPT valmisoleku element | Mida ette valmistada | Auditiväärtus |
|---|---|---|
| Kohaldamisala ja eesmärgid | Kriitilised funktsioonid, süsteemid, teenuseosutajad, välistused | Näitab riskipõhist testimise kavandamist |
| Autoriseerimine | Ametlik heakskiit, tegutsemisreeglid, hädaseiskamine | Tõendab ohutut ja kontrollitud läbiviimist |
| Ohuteabe sisend | Stsenaariumi põhjendus, ründaja profiil, ärimõju | Toetab ohupõhist metoodikat |
| Tootmiskeskkonna ohutusplaan | Seire, varukoopiad, tagasipööramine, kommunikatsioon | Väldib testimisest põhjustatud häireid |
| Teenuseosutajate koordineerimine | Teenuseosutajate heakskiidud, kontaktpunktid, juurdepääsuaknad | Katab kolmandatest isikutest sõltuvused |
| Tõendusmaterjali kogumine | Testilogid, leiud, ekraanitõmmised, vajaduse korral tõendite valduse ahel | Toetab auditeeritavust |
| Parandusmeetmete jälgimine | Vastutajad, kuupäevad, kordustestide tulemused, riski aktsepteerimine | Näitab, et testimine viis parendusteni |
| Õppetunnid | Tuvastuslüngad, reageerimislüngad, kontrollimeetmete uuendused | Seob testimise tegevuskerksuse küpsusega |
DORA peamine õppetund on, et testimise tõendusmaterjal ei tohi lõppeda aruandega. Audiitorid küsivad, kas leiud hinnati riski alusel, määrati vastutajatele, kõrvaldati ja testiti uuesti. Nad võivad kontrollida ka seda, kas testimine hõlmas kriitilisi või olulisi funktsioone, mitte ainult internetile avatud varasid.
Talitluspidevus ja katastroofitaaste: tegevuskerksus peab toimima praktikas
DORA on digitaalse tegevuskerksuse regulatsioon. Taaste on sama oluline kui ennetamine. Dokumenteeritud IKT-riski raamistik ei aita, kui makseplatvormi katkestus näitab, et taasteaja eesmärke ei ole kunagi testitud, teenuseosutajate kontaktipuud on aegunud ja kriisimeeskond ei jõua kokkuleppele, kes suhtleb klientidega.
Clarysec SME Talitluspidevuse poliitika ja katastroofitaaste poliitika seab selge baastaseme:
„Organisatsioon peab testima nii oma BCP kui ka DR võimekust vähemalt kord aastas. Testid peavad sisaldama:“
Jaotisest „Poliitika rakendamise nõuded“, poliitika punkt 6.4.1.
Enterprise Talitluspidevuse poliitika ja katastroofitaaste poliitika algab ärimõjust:
„Ärimõju analüüs (BIA) tuleb teha vähemalt kord aastas kõigi kriitiliste äriüksuste kohta ning vaadata läbi süsteemide, protsesside või sõltuvuste oluliste muudatuste korral. BIA tulemused peavad määratlema:“
Jaotisest „Juhtimisnõuded“, poliitika punkt 5.2.
DORA jaoks tuleb BIA siduda IKT-varade, teenuseosutajate, intsidentidele reageerimise ja testimisega. Kui BIA tuvastab „kliendimaksed“ kriitilise funktsioonina, peab teenuseosutajate sõltuvuste register tuvastama seda toetavad töötlejad, pilveteenused ja võrguteenuse osutajad. Riskiregister peab sisaldama tõrkestsenaariume. Testimisplaan peab sisaldama tegevuskerksuse valideerimist. Intsidentidele reageerimise plaan peab sisaldama eskaleerimist ja kommunikatsiooni. DR-test peab andma tõendusmaterjali, mitte ainult koosolekumärkme.
See jälgitavus muudab DORA nõuetele vastavuse tegevuskerksuse süsteemiks.
Ristvastavus: üks tõenduskomplekt, mitu auditiküsimust
Finantsüksused puutuvad DORA-ga harva kokku eraldi. Neil on sageli GDPR-i kohustused, NIS2 kokkupuude, lepingulised turbekohustused, ISO/IEC 27001:2022 eesmärgid, siseauditi nõuded, klientide hoolsuskontroll, SOC ootused ja juhatuse riskiraportid. Lahendus ei ole eraldi tõendussilode loomine. Lahendus on ristvastavuse tõendusmudeli ülesehitamine.
Zenith Controls on Clarysec ristvastavuse kompass. See ei leiuta uusi kohustusi. See vastendab ametlikud standardid ja raamistikud, et organisatsioonid mõistaksid, kuidas üks kontrollivaldkond toetab mitut vastavustulemust.
| DORA teema | ISO/IEC 27002:2022 kontrollivaldkond Zenith Controlsis | Ristvastavuse väärtus |
|---|---|---|
| Kolmandatest isikutest IKT-teenuse osutajate järelevalve | 5.21 Infoturbe juhtimine IKT tarneahelas | Toetab GDPR-i volitatud töötlejate järelevalvet, NIS2 tarneahela turvet ja DORA kolmandatest isikutest IKT-teenuse osutajate riski |
| Intsidentidest teatamine ja haldus | 5.24 Infoturbeintsidentide haldamise planeerimine ja ettevalmistus | Toetab GDPR-i rikkumisest teavitamist, NIS2 intsidendist teavitamist ja DORA IKT-intsidentidest teatamist |
| Testimine ja kindluse andmine | 5.35 Infoturbe sõltumatu läbivaatamine | Toetab GDPR-i testimist ja hindamist, NIS2 riskijuhtimist ja DORA digitaalse tegevuskerksuse testimist |
See on oluline eelarve ja juhtimise jaoks. CISO saab juhatusele selgitada, et intsidentide klassifitseerimise parandamine toetab DORA aruandlust, GDPR-i rikkumisest teavitamist, NIS2 intsidentide käsitlemist ja sisemist tegevuskerksust. Hankejuht saab põhjendada teenuseosutajate sõltuvuste kaardistamist, sest see toetab DORA kontsentratsiooniriski, GDPR-i volitatud töötlejate hoolsuskontrolli ja NIS2 tarneahela turvet. Testimise juht saab näidata, et ründetiimi harjutused ja sõltumatud läbivaatused toetavad DORA testimist, GDPR-i kontrollimeetmete hindamist ja laiemat kindluse andmist.
Auditi vaade: kuidas hindajad testivad teie DORA tõendusmaterjali
DORA valmisolek muutub reaalseks siis, kui keegi küsib tõendusmaterjali. Erinevad audiitorid ja hindajad lähenevad samale teemale eri nurkade alt.
ISO/IEC 27001:2022 suunitlusega audiitor alustab infoturbe juhtimissüsteemi loogikast: kohaldamisala, riskihindamine, riskikäsitlus, Annex A kontrollimeetmete kohaldatavus, siseaudit, juhtkonna läbivaatus ja tõendusmaterjal selle kohta, et kontrollimeetmed on rakendatud. IKT tarneahela turbe puhul vaatab ta poliitikaid, tarnijate klassifitseerimist, lepinguklausleid, hoolsuskontrolli ja pidevat seiret. Intsidendihalduse puhul kontrollib ta plaani, rolle, eskaleerimisteid, tööriistu ja kirjeid. Testimise puhul ootab ta planeeritud intervalle, vajaduse korral sõltumatust, parandusmeetmeid ja juhtkonna läbivaatuse sisendit.
ISO/IEC 19011:2018 auditi vaade keskendub auditi läbiviimisele. Zenith Controls märgib IKT tarneahela turbe auditimetoodikas, et audiitorid uurivad hankepoliitikaid, RFP malle ja tarnijahaldusprotsesse, et kontrollida, kas IKT-spetsiifilised turbenõuded on sisse viidud alates soetamisest kuni kõrvaldamiseni. Intsidendihalduse puhul kontrollivad audiitorid intsidentidele reageerimise plaani täielikkust ja vastavust parimatele tavadele. Sõltumatu läbivaatamise puhul otsivad audiitorid tõendusmaterjali selle kohta, et sõltumatud auditid või ülevaatused on läbi viidud.
ISO/IEC 27007:2020 vaade on spetsiifilisem infoturbe juhtimissüsteemi auditile. Zenith Controls märgib, et audiitorid võivad intervjueerida hankeametnikke, IT-turbe töötajaid ja tarnijahaldureid, et hinnata arusaamist IKT tarneahela kontrollimeetmetest ja nende rakendamist. Intsidendiks valmistumise puhul kinnitavad nad, et intsidentidele reageerimise meeskond on olemas ja toimiv. Sõltumatu läbivaatamise puhul kontrollivad nad, et siseauditi programm hõlmab kogu infoturbe juhtimissüsteemi kohaldamisala ja on nõuetekohaselt ressurseeritud.
NIST SP 800-115 põhine testimishindaja keskendub haavatavuste hindamise ja penetratsioonitestimise metoodikale. Ta võib uurida, kas testi käsitlusala, tegutsemisreeglid, leiud, tõsiduse hinnangud, parandusmeetmed ja kordustestimine on dokumenteeritud. DORA TLPT puhul tähendab see, et hindaja ei rahuldu ründetiimi slaidipaketiga. Ta soovib tõendeid juhtimise, ohutuse, tehnilise sügavuse ja sulgemise kohta.
COBIT 2019 või ISACA-stiilis audiitor küsib, kas juhtimiseesmärgid on täidetud: kes vastutab protsessi eest, kuidas mõõdetakse toimivust, kuidas erandeid heaks kiidetakse ja kuidas juhtkond saab kindlust.
| Auditiküsimus | Tõendusmaterjal, mis sellele vastab | Levinud nõrkus |
|---|---|---|
| Kuidas teate, millised IKT-teenused toetavad kriitilisi funktsioone? | Kriitiliste funktsioonide kaart, IKT varade register, BIA | Varade loend ei ole seotud ärimõjuga |
| Kuidas juhite kolmandatest isikutest IKT-teenuse osutajate kontsentratsiooniriski? | Tarnijasõltuvuste register, asendatavuse analüüs, väljumisplaanid | Tarnijate loend on olemas, sõltuvusanalüüs puudub |
| Kuidas töötajad intsidentidest teatavad? | Koolituse läbimise kirjed, teavituskanal, intsidentide piletid | Teavitusprotsess on olemas, kuid töötajad ei oska seda kirjeldada |
| Kuidas klassifitseerite olulisi IKT-intsidente? | Klassifitseerimismaatriks, eskaleerimistöövoog, õigusliku läbivaatuse kirjed | Klassifitseerimiskriteeriume ei ole testitud |
| Kuidas tõendate, et testimine parandas tegevuskerksust? | Testiaruanded, parandusmeetmete jälgija, kordustestide tõendusmaterjal, õppetunnid | Leiud jäävad avatuks ilma riski aktsepteerimiseta |
| Kuidas kaitsete süsteeme TLPT või ründetiimi testide ajal? | Tegutsemisreeglid, heakskiidud, seire, peatamiskriteeriumid | Testimine autoriseeritakse mitteametlikult |
| Kuidas juhtkond DORA riski üle järelevalvet teeb? | Vastavusregister, KPI/KRI pakett, juhtkonna läbivaatuse protokollid | Juhatuse aruandlus on liiga üldine |
Praktiline DORA 2026 valmisoleku kontrollnimekiri
Kasutage seda kontrollnimekirja tööaluseks, et muuta DORA otsingud tegevusteks.
Juhtimine ja RTS/ITS vastendus
- Pidage DORA vastavusregistrit, mis sisaldab kohustuse valdkonda, kohaldatavust, vastutajat, tõendusmaterjali, läbivaatuse sagedust ja lünga staatust.
- Vastendage DORA nõuded poliitikate, registrite, kontrollimeetmete ja juhtkonna aruandlusega.
- Määratlege proportsionaalsuse põhjendus lihtsustatud või skaleeritud IKT-riskide juhtimise jaoks, kui see kohaldub.
- Määrake juhtkonna vastutus IKT-riskide, intsidentidest teatamise, kolmandatest isikutest teenuseosutajate järelevalve ja testimise eest.
- Lisage DORA staatus juhtkonna läbivaatusse ja juhatuse riskiraportitesse.
IKT-riskide juhtimine
- Pidage IKT-riskiregistrit, mis sisaldab kirjeldust, tõenäosust, mõju, skoori, omanikku ja riski käsitlemise plaani.
- Siduge riskid kriitiliste või oluliste funktsioonidega.
- Siduge riskid IKT-varade, teenuseosutajate ja protsessidega.
- Vaadake riskid läbi pärast olulisi intsidente, teenuseosutaja muudatusi, tehnoloogiamuudatusi või testileide.
- Jälgige käsitlustegevusi kuni sulgemiseni või ametliku riski aktsepteerimiseni.
Kolmandatest isikutest IKT-teenuse osutajate järelevalve
- Pidage tarnijaregistrit ja tarnijasõltuvuste registrit.
- Tuvastage teenuseosutajad, kes toetavad kriitilisi või olulisi funktsioone.
- Hinnake ainus allikas tarnijaid ja asendatavust.
- Vaadake läbi alltöövõtjad ja allhankekorraldused.
- Lisage lepingutesse turbe-, juurdepääsu-, intsidentidest teatamise, auditi- ja väljumisklauslid.
- Seirake kriitilisi tarnijaid vähemalt kord aastas või pärast olulisi muudatusi.
- Hoidke suure sõltuvusega teenuseosutajate jaoks väljumis- ja varuplaanid.
Intsidendihaldus ja teatamine
- Hoidke intsidentidele reageerimise protseduure, millel on selged rollid ja eskaleerimisteed.
- Määratlege IKT-intsidentide klassifitseerimiskriteeriumid.
- Viige DORA teatamiskäivitajad kooskõlla GDPR-i, NIS2 ja lepinguliste teavitamiskohustustega.
- Koolitage töötajaid ja töövõtjaid intsidentidest teatamise kanalite osas.
- Hoidke intsidendilogisid, otsusekirjeid ja tõendusmaterjali.
- Viige läbi intsidendijärgsed läbivaatused ning ajakohastage riske ja kontrollimeetmeid.
Testimine, ründetiim ja TLPT
- Hoidke riskipõhist testimiskalendrit.
- Tehke haavatavuste skannimist ja penetratsioonitestimist määratud intervallidega.
- Kasutage stsenaariumipõhiseid ründetiimi harjutusi tuvastuse ja reageerimise testimiseks.
- TLPT valmisoleku jaoks määratlege käsitlusala, tegutsemisreeglid, ohutuskontrollid ja teenuseosutajate koordineerimine.
- Kaitske tootmiskeskkonna süsteeme testimise ajal.
- Jälgige leide, parandusmeetmeid, kordustestimist ja õppetunde.
- Raporteerige testimistulemused juhtkonnale.
Talitluspidevus ja taaste
- Tehke kriitiliste äriüksuste kohta iga-aastane BIA ja ajakohastage seda pärast olulisi muudatusi.
- Määratlege kriitiliste funktsioonide ja neid toetavate IKT-teenuste taaste-eesmärgid.
- Testige BCP ja DR võimekust vähemalt kord aastas.
- Lisage teenuseosutaja katkestuse ja küberintsidendi stsenaariumid.
- Säilitage testide tõendusmaterjal, lüngad, parandusmeetmed ja kordustestide tulemused.
- Viige talitluspidevuse plaanid kooskõlla intsidentidele reageerimise ja kriisikommunikatsiooniga.
Kuidas Clarysec aitab finantsüksustel liikuda otsingutulemustest auditivalmis tõendusmaterjalini
DORA 2026 valmisolekut ei saavutata kontrollnimekirja allalaadimisega ja lootusega, et organisatsioon täidab lüngad hiljem. See nõuab struktureeritud toimimismudelit, mis seob riskid, teenuseosutajad, intsidendid, testimise, talitluspidevuse ja auditi tõendusmaterjali.
Clarysec lähenemine ühendab kolm kihti.
Esiteks annab Zenith Blueprint rakendamise tegevuskava. Samm 14 aitab organisatsioonidel regulatiivseid nõudeid riski käsitlemise ja poliitikatega ristviidata. Samm 16 tugevdab personalipõhist intsidentidest teatamist. Samm 21 tagab, et auditid ja testid ei ohusta tootmiskeskkonna süsteeme. Samm 23 muudab teenuseosutajate järelevalve praktiliseks töövooks, mis hõlmab klassifitseerimist, lepinguid, alltöövõtjaid, seiret ja pilve hindamist.
Teiseks pakuvad Clarysec poliitikad valmis alust juhtimise operatiivseks rakendamiseks. Riskijuhtimise poliitika, Õigusnormidele vastavuse poliitika, Kolmandate isikute ja tarnijate turbepoliitika, Tarnijasõltuvuse riskijuhtimise poliitika, Intsidentidele reageerimise poliitika, Turbetestimise ja ründetiimi poliitika ning Talitluspidevuse poliitika ja katastroofitaaste poliitika annavad meeskondadele konkreetsed punktid, vastutusmudelid ja tõendusmaterjali ootused.
Kolmandaks annab Zenith Controls ristvastavuse kaardi. See näitab, kuidas IKT tarneahela turve, intsidendihalduse planeerimine ja sõltumatu läbivaatamine seostuvad 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 ja NIST testimispraktikatega.
Tulemuseks on DORA nõuetele vastavuse programm, mis on auditis kaitstav ja kasulik ka tegeliku intsidendi, teenuseosutaja tõrke või tegevuskerksuse testi ajal.
Järgmine samm: koostage DORA tõenduspakett enne järgmist auditi päringut
Kui teie meeskond otsib endiselt „DORA RTS/ITS kontrollnimekirja“, „DORA IKT-riskide juhtimise malli“, „DORA kolmandatest isikutest teenuseosutajate järelevalvet“ või „DORA TLPT nõudeid“, on järgmine samm muuta need otsingud kontrollitud tõendusmaterjaliks.
Alustage sel nädalal nelja tegevusega:
- Looge või ajakohastage DORA vastavusregister Clarysec poliitikamudeli alusel.
- Valige üks kriitiline funktsioon ja jälgige seda läbi riskiregistri, tarnijasõltuvuste registri, intsidendi töövoo, BIA ja testimisplaani.
- Vaadake üle oma viis olulisemat IKT-tarnijat asendatavuse, alltöövõtjate, intsidendiklauslite ja väljumisvõimaluste osas.
- Koostage testimise tõenduspakett, mis sisaldab käsitlusala, autoriseerimist, tulemusi, parandusmeetmeid ja kordustestimist.
Clarysec saab aidata teil seda rakendada Zenith Blueprint, poliitikamallide ja Zenith Controls abil, et teie DORA 2026 programm oleks praktiline, proportsionaalne ja auditivalmis.
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


