DORA 2026 ceļkarte IKT riskiem, piegādātājiem un TLPT

DORA 2026 meklēšanas panika patiesībā nav par regulējumu, bet par pierādījumiem

Ir pirmdienas rīts, 08:15, un vidēja lieluma maksājumu iestādes informācijas drošības vadītājam pārlūkprogrammā ir atvērtas trīs cilnes: “DORA RTS/ITS checklist”, “DORA ICT third-party register template” un “TLPT requirements financial entities”.

Atbilstības vadītājs jau ir jautājis, vai valdei paredzētajā materiālu paketē jāiekļauj jaunākā incidentu klasifikācijas darbplūsma. Iepirkumu funkcija vēlas piesaistīt jaunu mākoņvides analītikas platformu. Operāciju direktors vēlas apliecinājumu, ka pamatbanku SaaS pakalpojumu sniedzējam nav slēptas apakšuzņēmēju ekspozīcijas ārpus ES. Iekšējais audits pieprasa testēšanas kalendāru. Juridiskais dienests jautā, vai GDPR pārkāpumu paziņošanas termiņi ir saskaņoti ar DORA incidentu ziņošanu.

Neviens neuzdod teorētisku jautājumu. Jautājums ir: “Vai mēs to varam pierādīt līdz piektdienai?”

Tā ir īstā DORA 2026 problēma. Lielākā daļa finanšu iestāžu saprot galvenos pienākumus: IKT risku pārvaldība, ar IKT saistītu incidentu ziņošana, digitālās darbības noturības testēšana, IKT trešo pušu riska pārvaldība un pastiprināta kritisko IKT pakalpojumu sniedzēju uzraudzība. Sarežģītākais ir pārvērst regulatīvos tehniskos standartus, īstenošanas tehniskos standartus un pantu līmeņa pienākumus kontrolētā, atkārtojamā un auditējamā praksē.

DORA prasa finanšu iestādēm uzturēt noturīgas IKT risku pārvaldības spējas, politikas ar IKT saistītu incidentu pārvaldībai un ziņošanai, IKT sistēmu, kontroles pasākumu un procesu testēšanu, kā arī strukturētu IKT trešo pušu pakalpojumu sniedzēju uzraudzību. Tas paredz arī proporcionalitāti. Mazākai ieguldījumu sabiedrībai un lielai banku grupai nav vajadzīgi identiski pierādījumu modeļi, taču abām jāpierāda, ka izvēlētā pieeja atbilst to lielumam, riska profilam, sarežģītībai un kritiskajām funkcijām.

DORA projekti parasti izgāžas viena no trim iemesliem dēļ. Pirmkārt, organizācija DORA uztver kā juridiskas kartēšanas uzdevumu, nevis darbības modeli. Otrkārt, piegādātāju risks tiek dokumentēts kā piegādātāju saraksts, nevis kā atkarību, aizstājamības un koncentrācijas riska pārvaldība. Treškārt, testēšana tiek uztverta kā ikgadējs ielaušanās tests, nevis kā noturības programma, kas ietver ievainojamību skenēšanu, scenāriju testēšanu, incidentu mācības un, ja piemērojams, apdraudējumos balstītu ielaušanās testēšanu, ko bieži meklē kā TLPT.

Labāka pieeja ir izveidot vienotu pierādījumu sistēmu, kas sasaista politikas, reģistrus, īpašniekus, riskus, incidentus, piegādātājus, testēšanu, atjaunošanu un vadības pārskatīšanu. Tieši šeit Clarysec Zenith Blueprint, lietošanai gatavas politikas un Zenith Controls palīdz finanšu iestādēm pārvērst DORA no termiņa par darbības ritmu.

Sāciet ar DORA darbības modeli, nevis RTS/ITS izklājlapu

Daudzas komandas sāk ar izklājlapu, kurā uzskaitīti DORA panti un RTS/ITS prasības. Tas ir noderīgi, bet ar to nepietiek. Izklājlapa var parādīt, kam jāpastāv. Tā nepiešķir īpašniekus, nenosaka pārskatīšanas periodiskumu, neuzglabā pierādījumus un nepierāda, ka kontroles pasākums faktiski darbojas.

Zenith Blueprint: auditora 30 soļu ceļkarte Clarysec to aplūko risku pārvaldības posmā, 14. solī, “Risku apstrādes politika un regulatīvās krusteniskās atsauces”:

“DORA: finanšu sektora uzņēmumiem DORA prasa IKT risku pārvaldības ietvaru, kas lielā mērā atbilst tam, ko esam izdarījuši: identificēt riskus, ieviest kontroles pasākumus un politikas un tos testēt. DORA arī uzsver reaģēšanu uz incidentiem un ziņošanu, kā arī trešo pušu IKT pakalpojumu sniedzēju uzraudzību.”

Praktiskais vēstījums ir vienkāršs: neveidojiet “DORA atbilstību” kā paralēlu birokrātiju. Izveidojiet uz risku balstītu IKT pārvaldības slāni, kas sasaista DORA prasības ar politikām, reģistriem, kontroles pasākumu īpašniekiem, testēšanas ierakstiem, piegādātāju pierādījumiem un vadības pārskatīšanu.

Praktiskam DORA darbības modelim jābalstās uz pieciem pierādījumu pīlāriem:

Reglamentētām finanšu iestādēm šī struktūra pārvērš RTS/ITS ieviešanu auditam gatavā pierādījumu sistēmā. Iestādēm, kurām piemēro vienkāršotu IKT risku pārvaldību, to pašu modeli var mērogot uz mazāku dokumentu skaitu un vienkāršākiem reģistriem. Pamatdisciplīnas paliek nemainīgas: identificēt, aizsargāt, atklāt, reaģēt, atjaunot, testēt un pārvaldīt piegādātājus.

IKT risku pārvaldība: reģistrs ir vadības telpa

DORA prasības IKT risku pārvaldībai paredz, ka finanšu iestādēm jāidentificē, jāklasificē un jāpārvalda IKT riski sistēmās, datos, procesos, kritiskajās vai svarīgajās funkcijās un trešo pušu atkarībās.

Biežākā kļūme nav risku reģistra trūkums. Tā ir reģistra atrautība no piegādātājiem, aktīviem, incidentiem un testiem. DORA neatlīdzina skaistu izklājlapu, ja tā nevar paskaidrot, kāpēc augsta riska piegādātājam nav izstāšanās plāna vai kāpēc kritiska klientu maksājumu platforma nav testēta.

Clarysec SME Risku pārvaldības politika mazākām finanšu iestādēm nodrošina koncentrētu pierādījumu pamatlīmeni:

“Katram riska ierakstam jāietver: apraksts, iespējamība, ietekme, vērtējums, īpašnieks un apstrādes plāns.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.1.2.

Lielākām finanšu iestādēm Clarysec Enterprise Risku pārvaldības politika prasa formālāku procesu:

“Jāuztur formāls risku pārvaldības process saskaņā ar ISO/IEC 27005 un ISO 31000, aptverot risku identificēšanu, analīzi, izvērtēšanu, apstrādi, uzraudzību un komunikāciju.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.1.

Šī atšķirība ir svarīga. DORA ir proporcionāla, bet proporcionalitāte nenozīmē neformalitāti. Neliels maksājumu uzņēmums var izmantot vienkāršotu reģistru, savukārt banku grupa var izmantot integrētus GRC rīkus. Abos gadījumos auditors tomēr jautās: kādi ir jūsu IKT riski? Kam tie pieder? Kāds ir apstrādes plāns? Kādi pierādījumi apliecina progresu? Kā piegādātāji un kritiskās funkcijas ietekmē vērtējumu?

Spēcīgam DORA IKT risku reģistram jāietver šādi lauki:

Praktisks uzdevums ir paņemt vienu kritisku IKT pakalpojumu, piemēram, mākoņvidē izvietotu darījumu uzraudzības platformu, un 20 minūtēs izveidot riska ierakstu. Aprakstiet atteices vai kompromitēšanas scenāriju, novērtējiet iespējamību un ietekmi, piešķiriet īpašnieku, identificējiet saistītos piegādātājus, definējiet apstrādes plānu un sasaistiet ierakstu ar pierādījumiem, piemēram, piegādātāju pienācīgas pārbaudes rezultātiem, SLA, incidentu klauzulām, BIA, DR testu rezultātiem, uzraudzības paneļiem un piekļuves tiesību pārskatīšanu.

Šis viens ieraksts kļūst par pavedienu, kas sasaista DORA IKT risku pārvaldību, trešo pušu uzraudzību, incidentu atklāšanu, nepārtrauktību un testēšanu. Tā risku reģistrs kļūst par vadības telpu, nevis dokumentu skapi.

RTS/ITS gatavība: kartējiet pienākumus uz politikām, nevis solījumiem

Praktiskais meklēšanas termins “DORA RTS/ITS checklist” parasti nozīmē “Kādus dokumentus sagaidīs uzraugi?” Finanšu iestādēm jāizvairās solīt atbilstību ar vispārīgiem apgalvojumiem. Tām vajadzīga kartēšana, kas katru pienākumu sasaista ar politiku, kontroles pasākumu, īpašnieku un pierādījumu vienību.

Clarysec SME Tiesiskās un regulatīvās atbilstības politika nosaka vienkāršu pārvaldības atskaites punktu:

“Ģenerāldirektoram (GM) jāuztur vienkāršs, strukturēts atbilstības reģistrs, kurā norādīts:”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.1.1.

DORA 2026 vajadzībām jūsu atbilstības reģistrā jāiekļauj:

• DORA pienākums vai RTS/ITS prasību joma.
• Piemērojamība, tostarp proporcionalitātes pamatojums.
• Atsauce uz politiku vai procedūru.
• Kontroles pasākuma īpašnieks.
• Pierādījumu atrašanās vieta.
• Pārskatīšanas periodiskums.
• Atvērtie trūkumi un novēršanas termiņš.
• Statuss valdes vai vadības ziņošanā.

Tas atbilst Zenith Blueprint 14. soļa pieejai: regulatīvās prasības tiek kartētas uz ISMS kontroles pasākumiem un politikām, lai nekas nepaliktu nepamanīts. Tā vietā, lai jautātu “Vai mēs atbilstam DORA?”, vadība var jautāt: “Kuras DORA pierādījumu vienības kavējas, kuriem kritiskajiem piegādātājiem trūkst izstāšanās plānu un kuras testēšanas darbības vēl nav devušas trūkumu novēršanas pierādījumus?”

IKT trešo pušu risks: koncentrācija, aizstājamība un apakšuzņēmēji

DORA ir mainījusi piegādātāju sarunu finanšu pakalpojumos. Vairs nepietiek pajautāt, vai pakalpojumu sniedzējam ir drošības sertifikācija, apdrošināšana vai datu apstrādes līgums. Finanšu iestādēm jāizvērtē, vai pakalpojumu sniedzējs rada koncentrācijas risku, vai to reāli var aizstāt, vai vairāki kritiski pakalpojumi ir atkarīgi no viena piegādātāja vai saistītiem piegādātājiem un vai apakšuzņēmēju izmantošana rada papildu juridisku vai noturības ekspozīciju.

Tieši šis jautājums daudziem informācijas drošības vadītājiem neļauj gulēt. Uzņēmums var paļauties uz vienu lielu mākoņpakalpojumu sniedzēju darījumu apstrādei, datu analītikai, klientu portāliem un iekšējai sadarbībai. Ja šim pakalpojumu sniedzējam rodas ilgstoša nepieejamība, regulatīvs strīds vai apakšuzņēmēja kļūme, jautājums nav tikai “Vai mums ir līgums?” Jautājums ir “Vai mēs varam turpināt kritiskos pakalpojumus, sazināties ar klientiem un pierādīt, ka sapratām atkarību pirms tās kļūmes?”

Clarysec SME Trešo pušu un piegādātāju drošības politika nosaka pamatu:

“Piegādātāju reģistrs jāuztur un jāatjaunina administratīvajai vai iepirkumu kontaktpersonai. Tajā jāiekļauj:”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.4.

Uzņēmuma līmeņa programmām Clarysec Piegādātāju atkarību risku pārvaldības politika padziļināti aplūko DORA specifisko atkarību un aizstājamību:

“Piegādātāju atkarību reģistrs: piegādātāju pārvaldības birojam (VMO) jāuztur aktuāls visu kritisko piegādātāju reģistrs, iekļaujot tādu informāciju kā sniegtie pakalpojumi/produkti; vai piegādātājs ir vienīgais piegādes avots; pieejamie alternatīvie piegādātāji vai aizstājamība; spēkā esošie līguma noteikumi; un ietekmes izvērtējums gadījumā, ja piegādātājs nespētu sniegt pakalpojumu vai tiktu kompromitēts. Reģistrā skaidri jānorāda augstas atkarības piegādātāji, piemēram, tie, kuriem nav ātri pieejamas alternatīvas.”
No sadaļas “Ieviešanas prasības”, politikas punkts 6.1.

Tieši šos piegādātāju pierādījumus DORA projekti bieži palaiž garām. Piegādātāju reģistrs parāda, kas ir piegādātājs. Atkarību reģistrs parāda, kas notiek, kad piegādātājs kļūdās vai nespēj sniegt pakalpojumu.

Zenith Blueprint posma “Kontroles pasākumi praksē” 23. solis, “Organizatoriskie kontroles pasākumi”, sniedz praktisku darbplūsmu piegādātāju uzraudzībai. Tas iesaka apkopot pilnu piegādātāju sarakstu, klasificēt piegādātājus pēc piekļuves sistēmām, datiem vai darbības kontrolei, pārbaudīt, ka drošības prasības ir ietvertas līgumos, pārvaldīt apakšuzņēmēju un lejupējo risku, definēt izmaiņu un uzraudzības procedūras un izveidot mākoņpakalpojumu izvērtēšanas procesu.

Zenith Controls: savstarpējās atbilstības ceļvedī ISO/IEC 27002:2022 kontroles pasākums 5.21 “Informācijas drošības pārvaldība IKT piegādes ķēdē” ir kartēts kā preventīvs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tas ir saistīts ar piegādātāju attiecību drošību un kiberdrošības konceptu “Identificēt”. Tas sasaistās ar drošu inženieriju, drošu kodēšanu, piekļuves kontroli, drošības testēšanu, pierādījumu vākšanu, drošas izstrādes dzīves ciklu un ārpakalpojuma izstrādi.

Tieši tāda ir DORA trešo pušu uzraudzības realitāte. Piegādātāju risks nav tikai iepirkumu jautājums. Tas skar arhitektūru, izstrādi, reaģēšanu uz incidentiem, piekļuves kontroli, darbības nepārtrauktību un juridiskos jautājumus.

No savstarpējās atbilstības skatpunkta Zenith Controls kartē IKT piegādes ķēdes drošību uz GDPR Article 28 un Article 32, jo apstrādātāji un apakšapstrādātāji jāizvēlas un jāuzrauga ar atbilstošiem tehniskiem un organizatoriskiem pasākumiem. Tas atbalsta NIS2 piegādes ķēdes drošības prasības, tostarp Article 21 kiberdrošības risku pārvaldības pasākumus un Article 22 koordinētus piegādes ķēdes risku novērtējumus. Tas cieši kartējas uz DORA Article 28, Article 29 un Article 30, kuros IKT trešo pušu risks, koncentrācijas risks, apakšārpakalpojumi un līguma noteikumi ir centrāli.

Pierādījumus stiprina atbalstošie standarti. ISO/IEC 27036-3:2021 atbalsta IKT iepirkumu un piegādātāju izvēles drošību. ISO/IEC 20243:2018 atbalsta uzticamu tehnoloģiju produktu integritāti un piegādes ķēdes drošību. ISO/IEC 27001:2022 sasaista to ar riska apstrādi un Annex A piegādātāju kontroles pasākumiem.

Incidentu ziņošana: izveidojiet eskalācijas ķēdi pirms incidenta

DORA incidentu ziņošana nav tikai paziņojuma iesniegšana. Tā ir ar IKT saistītu incidentu atklāšana, klasificēšana, eskalēšana, komunikācija un mācīšanās no tiem. Finanšu iestādēm jāuztur IKT incidentu pārvaldības un ziņošanas procesi ar definētām lomām, klasifikācijas kritērijiem, paziņošanas ceļiem un pēcincidenta analīzi.

Clarysec SME Incidentu reaģēšanas politika sasaista incidentu reaģēšanas termiņus ar juridiskajām prasībām:

“Reaģēšanas termiņi, tostarp datu atjaunošanas un paziņošanas pienākumi, jādokumentē un jāsaskaņo ar juridiskajām prasībām, piemēram, GDPR 72 stundu personas datu aizsardzības pārkāpuma paziņošanas prasību.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.2.

Uzņēmuma līmeņa vidēm Clarysec Incidentu reaģēšanas politika pievieno reglamentētu datu eskalācijas skatījumu:

“Ja incidents izraisa apstiprinātu vai iespējamu personas datu vai citu reglamentētu datu ekspozīciju, juridiskajam dienestam un DPO jāizvērtē piemērojamība:”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

Citāts beidzas tieši trigera punktā, un tieši tur daudzi incidentu procesi sabrūk. Ja trigeris nav skaidrs, komandas diskutē par paziņošanas pienākumiem, kamēr laiks jau rit.

Zenith Blueprint posma “Kontroles pasākumi praksē” 16. solis, “Personāla kontroles II”, uzsver personāla virzītu incidentu ziņošanu. Darbiniekiem, līgumslēdzējiem un iesaistītajām pusēm jāzina, kā atpazīt un ziņot par iespējamiem drošības incidentiem, izmantojot vienkāršus kanālus, piemēram, īpašu pastkasti, portālu vai palīdzības tālruni. Blueprint sasaista to ar GDPR Article 33, NIS2 Article 23 un DORA Article 17, jo regulatīvā ziņošana sākas ar iekšējo informētību un eskalāciju.

Zenith Controls ISO/IEC 27002:2022 kontroles pasākums 5.24 “Informācijas drošības incidentu pārvaldības plānošana un sagatavošana” ir kartēts kā koriģējošs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību un ir saskaņots ar reaģēšanu un atjaunošanu. Tas tieši sasaistās ar notikumu izvērtēšanu, mācīšanos no incidentiem, žurnālu reģistrēšanu un uzraudzību, drošību traucējumu laikā, informācijas drošības nepārtrauktību un saziņu ar iestādēm. Ceļvedis to kartē uz DORA Article 17 līdz Article 23 par ar IKT saistītu incidentu pārvaldību, klasifikāciju, ziņošanu un brīvprātīgu kiberapdraudējumu paziņošanu, GDPR Article 33 un Article 34 par paziņošanu pārkāpuma gadījumā un NIS2 Article 23 incidentu paziņošanu.

DORA gatavam incidentu procesam jāietver:

• Skaidri incidentu pieņemšanas kanāli.
• Notikumu triāža un klasifikācijas kritēriji.
• Būtisku ar IKT saistītu incidentu eskalācijas darbplūsma.
• Juridiskie, DPO un regulatīvās paziņošanas lēmumu punkti.
• Piegādātāju incidentu paziņošanas trigeri.
• Pierādījumu saglabāšanas prasības.
• Izpildvadības un valdes komunikācijas noteikumi.
• Pēcincidenta pārskatīšana un gūtās atziņas.
• Sasaiste ar risku reģistra atjauninājumiem un kontroles pasākumu trūkumu novēršanu.

Atbalstošie standarti piešķir struktūru. ISO/IEC 27035-1:2023 sniedz plānošanas un sagatavošanas principus incidentu pārvaldībai. ISO/IEC 27035-2:2023 detalizē incidentu apstrādes soļus. ISO/IEC 22320:2018 atbalsta vadību, kontroli un strukturētu krīzes komunikāciju. Tas ir svarīgi, kad IKT nepieejamība kļūst par krīzi ar ietekmi uz klientiem un iestādei jāparāda, ka lēmumi bija savlaicīgi, koordinēti un balstīti pierādījumos.

Digitālās darbības noturības testēšana un TLPT: neļaujiet testam kļūt par incidentu

Testēšana ir viena no visvairāk meklētajām DORA 2026 tēmām, jo tā ir gan tehniski, gan pārvaldības ziņā prasīga. Finanšu iestādēm jātestē IKT sistēmas, kontroles pasākumi un procesi. Noteiktām iestādēm padziļināta testēšana, piemēram, TLPT, kļūst par centrālu prasību saskaņā ar DORA Article 26.

Audita jautājums nav tikai “Vai jūs testējāt?” Tas ir: “Vai tests bija balstīts riskā, autorizēts, drošs, neatkarīgs, kur tas prasīts, vai trūkumi tika novērsti un vai tas bija sasaistīts ar noturības mērķiem?”

Clarysec Enterprise Drošības testēšanas un sarkanās komandas politika skaidri definē minimālo testēšanas programmu:

“Testu veidi: drošības testēšanas programmai jāietver vismaz: (a) ievainojamību skenēšana, kas sastāv no automatizētas iknedēļas vai ikmēneša tīklu un lietojumprogrammu skenēšanas, lai identificētu zināmās ievainojamības; (b) ielaušanās testēšana, kas sastāv no manuālas, padziļinātas konkrētu sistēmu vai lietojumprogrammu testēšanas, ko veic kvalificēti testētāji, lai identificētu sarežģītas vājās vietas; un (c) sarkanās komandas vingrinājumi, kas sastāv no scenārijos balstītām reālu uzbrukumu simulācijām, tostarp sociālās inženierijas un citiem paņēmieniem, lai kopumā testētu organizācijas atklāšanas un reaģēšanas spējas.”
No sadaļas “Ieviešanas prasības”, politikas punkts 6.1.

Tas ir tilts starp rutīnas testēšanu un TLPT briedumu. Ievainojamību skenēšana atrod zināmās vājās vietas. Ielaušanās testēšana validē izmantojamību. Sarkanās komandas vingrinājumi testē atklāšanu un reaģēšanu kā sistēmu. TLPT, ja piemērojams, jāatrodas pārvaldītā testēšanas programmā ar tvēruma kontroli, drošības noteikumiem, ražošanas vides risku pārvaldību, pierādījumu fiksēšanu un trūkumu novēršanas izsekošanu.

Zenith Blueprint posma “Kontroles pasākumi praksē” 21. solis aplūko informācijas sistēmu aizsardzību audita un testēšanas laikā. Tas brīdina, ka auditi, ielaušanās testi, kriminālistiskās pārskatīšanas un darbības izvērtēšana var radīt risku, jo tie var ietvert paaugstinātu piekļuvi, invazīvus rīkus vai pagaidu izmaiņas sistēmas uzvedībā. Blueprint sasaista šo risku ar GDPR Article 32, DORA digitālās darbības noturības testēšanas prasībām, NIS2 nepārtrauktības aspektiem un COBIT 2019 praksēm drošai auditu un izvērtējumu izpildei.

Zenith Controls ISO/IEC 27002:2022 kontroles pasākums 5.35 “Neatkarīga informācijas drošības pārskatīšana” ir kartēts kā preventīvs un koriģējošs pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību. Tas sasaistās ar politiku ievērošanu, vadības pienākumiem, mācīšanos no incidentiem, ierakstu aizsardzību, informācijas dzēšanu, žurnālu reģistrēšanu un uzraudzību. DORA kontekstā attiecīgie testēšanas pienākumi galvenokārt ir Article 24 līdz Article 27, tostarp Article 26 par TLPT. Tas atbalsta arī GDPR Article 32(1)(d), kas prasa regulāri testēt un izvērtēt tehniskos un organizatoriskos pasākumus, un NIS2 Article 21, kas prasa kiberdrošības risku pārvaldības pasākumus.

DORA TLPT gatavības paketei jāietver:

Galvenā DORA mācība ir tāda, ka testēšanas pierādījumi nedrīkst beigties ar pārskatu. Auditori jautās, vai konstatējumiem tika piešķirts riska vērtējums, vai tie tika piešķirti īpašniekiem, novērsti un atkārtoti testēti. Viņi var arī pārbaudīt, vai testēšana aptvēra kritiskās vai svarīgās funkcijas, nevis tikai internetam pieejamus aktīvus.

Darbības nepārtrauktība un avārijas atjaunošana: noturībai jābūt operacionālai

DORA ir digitālās darbības noturības regulējums. Atjaunošana ir tikpat svarīga kā novēršana. Dokumentēts IKT risku ietvars nepalīdzēs, ja maksājumu platformas atteice atklās, ka atjaunošanas laika mērķi nekad nav testēti, piegādātāju kontaktu koki ir novecojuši un krīzes komanda nevar vienoties, kurš sazinās ar klientiem.

Clarysec SME Darbības nepārtrauktības un avārijas atjaunošanas politika nosaka skaidru pamatlīmeni:

“Organizācijai vismaz reizi gadā jātestē gan tās BCP, gan DR spējas. Testos jāiekļauj:”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.4.1.

Enterprise Darbības nepārtrauktības un avārijas atjaunošanas politika sākas ar biznesa ietekmi:

“Biznesa ietekmes analīze (BIA) jāveic vismaz reizi gadā visām kritiskajām biznesa struktūrvienībām un jāpārskata pēc būtiskām izmaiņām sistēmās, procesos vai atkarībās. BIA rezultātos jādefinē:”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.2.

DORA kontekstā BIA jāsasaista ar IKT aktīviem, piegādātājiem, reaģēšanu uz incidentiem un testēšanu. Ja BIA identificē “klientu maksājumus” kā kritisku funkciju, piegādātāju atkarību reģistram jāidentificē apstrādātāji, mākoņpakalpojumi un tīkla pakalpojumu sniedzēji, kas to atbalsta. Risku reģistrā jāiekļauj atteices scenāriji. Testēšanas plānā jāiekļauj noturības validācija. Incidentu reaģēšanas plānā jāiekļauj eskalācija un komunikācija. DR testam jāsniedz pierādījumi, ne tikai sanāksmes piezīme.

Šī izsekojamība ir tas, kas pārvērš DORA atbilstību par darbības noturības sistēmu.

Savstarpējā atbilstība: viens pierādījumu kopums, daudzi audita jautājumi

Finanšu iestādes reti saskaras tikai ar DORA. Tām bieži ir GDPR pienākumi, NIS2 ekspozīcija, līgumiskās drošības saistības, ISO/IEC 27001:2022 mērķi, iekšējā audita prasības, klientu pienācīgās pārbaudes, SOC gaidas un valdes risku ziņošana. Risinājums nav veidot atsevišķas pierādījumu silosistēmas. Risinājums ir izveidot savstarpējās atbilstības pierādījumu modeli.

Zenith Controls ir Clarysec savstarpējās atbilstības kompass. Tas neizgudro jaunus pienākumus. Tas kartē oficiālos standartus un ietvarus, lai organizācijas saprastu, kā viena kontroles joma atbalsta vairākus atbilstības rezultātus.

Tas ir svarīgi budžetam un pārvaldībai. Informācijas drošības vadītājs var paskaidrot valdei, ka incidentu klasifikācijas uzlabošana atbalsta DORA ziņošanu, GDPR paziņošanu pārkāpuma gadījumā, NIS2 incidentu apstrādi un iekšējo noturību. Iepirkumu vadītājs var pamatot piegādātāju atkarību kartēšanu, jo tā atbalsta DORA koncentrācijas risku, GDPR apstrādātāju pienācīgo pārbaudi un NIS2 piegādes ķēdes drošību. Testēšanas vadītājs var parādīt, ka sarkanās komandas vingrinājumi un neatkarīgas pārskatīšanas atbalsta DORA testēšanu, GDPR kontroles pasākumu izvērtēšanu un plašāku apliecinājumu.

Audita skatījums: kā izvērtētāji pārbaudīs jūsu DORA pierādījumus

DORA gatavība kļūst reāla, kad kāds pieprasa pierādījumus. Dažādi auditori un izvērtētāji vienu un to pašu tēmu aplūkos no dažādiem skatpunktiem.

ISO/IEC 27001:2022 orientēts auditors sāks ar ISMS loģiku: darbības joma, risku izvērtēšana, riska apstrāde, Annex A kontroles pasākumu piemērojamība, iekšējais audits, vadības pārskatīšana un pierādījumi, ka kontroles pasākumi ir ieviesti. IKT piegādes ķēdes drošībai viņš skatīs politikas, piegādātāju klasifikāciju, līguma klauzulas, pienācīgo pārbaudi un pastāvīgu uzraudzību. Incidentu pārvaldībai viņš pārbaudīs plānu, lomas, eskalācijas ceļus, rīkus un ierakstus. Testēšanai viņš sagaidīs plānotus intervālus, neatkarību, kur piemērojams, trūkumu novēršanu un ievadi vadības pārskatīšanā.

ISO/IEC 19011:2018 audita skatījums koncentrējas uz audita izpildi. Zenith Controls audita metodoloģija IKT piegādes ķēdes drošībai norāda, ka auditori pārbauda iepirkumu politikas, RFP veidnes un piegādātāju pārvaldības procesus, lai verificētu, ka IKT specifiskās drošības prasības ir iestrādātas no iegādes līdz likvidēšanai. Incidentu pārvaldībai auditori pārbauda incidentu reaģēšanas plāna pilnīgumu un atbilstību labākajai praksei. Neatkarīgai pārskatīšanai auditori meklē pierādījumus, ka neatkarīgi auditi vai pārskatīšanas ir veiktas.

ISO/IEC 27007:2020 skatījums ir specifiskāks ISMS auditam. Zenith Controls norāda, ka auditori var intervēt iepirkumu speciālistus, IT drošības personālu un piegādātāju vadītājus, lai izvērtētu izpratni un IKT piegādes ķēdes kontroles pasākumu izpildi. Incidentu sagatavošanai viņi apstiprina, ka pastāv incidentu reaģēšanas komanda un tā darbojas. Neatkarīgai pārskatīšanai viņi verificē, ka iekšējā audita programma aptver pilnu ISMS darbības jomu un ir pienācīgi nodrošināta ar resursiem.

NIST SP 800-115 informēts testēšanas izvērtētājs koncentrēsies uz ievainojamību izvērtēšanas un ielaušanās testēšanas metodoloģiju. Viņš var pārbaudīt, vai testu tvērums, iesaistes noteikumi, konstatējumi, smaguma pakāpes vērtējumi, trūkumu novēršana un atkārtota testēšana ir dokumentēti. DORA TLPT gadījumā tas nozīmē, ka izvērtētāju neapmierinās sarkanās komandas prezentācija. Viņš vēlēsies pierādījumus par pārvaldību, drošību, tehnisko dziļumu un slēgšanu.

COBIT 2019 vai ISACA stila auditors jautās, vai pārvaldības mērķi ir sasniegti: kam pieder process, kā tiek mērīta veiktspēja, kā tiek apstiprināti izņēmumi un kā vadība saņem apliecinājumu.

Praktiskais DORA 2026 gatavības kontrolsaraksts

Izmantojiet šo kontrolsarakstu kā darba pamatlīniju, lai DORA meklējumus pārvērstu rīcībā.

Pārvaldība un RTS/ITS kartēšana

• Uzturiet DORA atbilstības reģistru ar pienākumu jomu, piemērojamību, īpašnieku, pierādījumiem, pārskatīšanas periodiskumu un trūkumu statusu.
• Kartējiet DORA prasības uz politikām, reģistriem, kontroles pasākumiem un vadības ziņošanu.
• Definējiet proporcionalitātes pamatojumu vienkāršotai vai mērogotai IKT risku pārvaldībai, ja piemērojams.
• Piešķiriet izpildvadības pārskatatbildību par IKT risku, incidentu ziņošanu, trešo pušu uzraudzību un testēšanu.
• Iekļaujiet DORA statusu vadības pārskatīšanā un valdes risku ziņošanā.

IKT risku pārvaldība

• Uzturiet IKT risku reģistru ar aprakstu, iespējamību, ietekmi, vērtējumu, īpašnieku un apstrādes plānu.
• Sasaistiet riskus ar kritiskajām vai svarīgajām funkcijām.
• Sasaistiet riskus ar IKT aktīviem, piegādātājiem un procesiem.
• Pārskatiet riskus pēc būtiskiem incidentiem, piegādātāju izmaiņām, tehnoloģiju izmaiņām vai testu konstatējumiem.
• Izsekojiet apstrādes darbības līdz slēgšanai vai formālai riska pieņemšanai.

IKT trešo pušu uzraudzība

• Uzturiet piegādātāju reģistru un piegādātāju atkarību reģistru.
• Identificējiet piegādātājus, kas atbalsta kritiskās vai svarīgās funkcijas.
• Izvērtējiet vienīgā piegādes avota piegādātājus un aizstājamību.
• Pārskatiet apakšuzņēmējus un apakšārpakalpojumu kārtību.
• Līgumos iestrādājiet drošības, piekļuves, incidentu ziņošanas, audita un izstāšanās klauzulas.
• Uzraugiet kritiskos piegādātājus vismaz reizi gadā vai pēc būtiskām izmaiņām.
• Uzturiet izstāšanās un rezerves plānus augstas atkarības pakalpojumu sniedzējiem.

Incidentu pārvaldība un ziņošana

• Uzturiet incidentu reaģēšanas procedūras ar skaidrām lomām un eskalācijas ceļiem.
• Definējiet IKT incidentu klasifikācijas kritērijus.
• Saskaņojiet DORA ziņošanas trigerus ar GDPR, NIS2 un līgumiskajiem paziņošanas pienākumiem.
• Apmāciet darbiniekus un līgumslēdzējus par incidentu ziņošanas kanāliem.
• Uzturiet incidentu žurnālus, lēmumu ierakstus un pierādījumus.
• Veiciet pēcincidenta pārskatīšanu un atjauniniet riskus un kontroles pasākumus.

Testēšana, sarkanās komandas vingrinājumi un TLPT

• Uzturiet uz risku balstītu testēšanas kalendāru.
• Veiciet ievainojamību skenēšanu un ielaušanās testēšanu noteiktos intervālos.
• Izmantojiet scenārijos balstītus sarkanās komandas vingrinājumus, lai testētu atklāšanu un reaģēšanu.
• TLPT gatavībai definējiet tvērumu, iesaistes noteikumus, drošības kontroles pasākumus un piegādātāju koordināciju.
• Aizsargājiet ražošanas sistēmas testēšanas laikā.
• Izsekojiet konstatējumus, trūkumu novēršanu, atkārtotu testēšanu un gūtās atziņas.
• Ziņojiet vadībai par testēšanas rezultātiem.

Nepārtrauktība un atjaunošana

• Veiciet ikgadēju BIA kritiskajām biznesa struktūrvienībām un atjauniniet to pēc būtiskām izmaiņām.
• Definējiet atjaunošanas mērķus kritiskajām funkcijām un atbalstošajiem IKT pakalpojumiem.
• Testējiet BCP un DR spējas vismaz reizi gadā.
• Iekļaujiet piegādātāju nepieejamības un kiberincidentu scenārijus.
• Saglabājiet testu pierādījumus, trūkumus, trūkumu novēršanas pasākumus un atkārtotas testēšanas rezultātus.
• Saskaņojiet nepārtrauktības plānus ar reaģēšanu uz incidentiem un krīzes komunikāciju.

Kā Clarysec palīdz finanšu iestādēm pāriet no meklēšanas rezultātiem uz auditam gataviem pierādījumiem

DORA 2026 gatavība netiek sasniegta, lejupielādējot kontrolsarakstu un cerot, ka organizācija vēlāk aizpildīs trūkumus. Tai nepieciešams strukturēts darbības modelis, kas sasaista riskus, piegādātājus, incidentus, testēšanu, nepārtrauktību un audita pierādījumus.

Clarysec pieeja apvieno trīs slāņus.

Pirmkārt, Zenith Blueprint nodrošina ieviešanas ceļkarti. 14. solis palīdz organizācijām izveidot krusteniskas atsauces starp regulatīvajām prasībām, riska apstrādi un politikām. 16. solis stiprina personāla virzītu incidentu ziņošanu. 21. solis nodrošina, ka auditi un testi neapdraud ražošanas sistēmas. 23. solis pārvērš piegādātāju uzraudzību praktiskā darbplūsmā, kas aptver klasifikāciju, līgumus, apakšuzņēmējus, uzraudzību un mākoņpakalpojumu izvērtēšanu.

Otrkārt, Clarysec politikas nodrošina pārvaldību, ko var uzreiz ieviest darbībā. Risku pārvaldības politika, Tiesiskās un regulatīvās atbilstības politika, Trešo pušu un piegādātāju drošības politika, Piegādātāju atkarību risku pārvaldības politika, Incidentu reaģēšanas politika, Drošības testēšanas un sarkanās komandas politika un Darbības nepārtrauktības un avārijas atjaunošanas politika sniedz komandām konkrētus punktus, īpašumtiesību modeļus un pierādījumu gaidas.

Treškārt, Zenith Controls nodrošina savstarpējās atbilstības karti. Tā parāda, kā IKT piegādes ķēdes drošība, incidentu pārvaldības plānošana un neatkarīga pārskatīšana sasaistās ar 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 un NIST testēšanas praksēm.

Rezultāts ir DORA atbilstības programma, kas ir pamatota auditā un noderīga reāla incidenta, piegādātāja kļūmes vai noturības testa laikā.

Nākamais solis: izveidojiet savu DORA pierādījumu paketi pirms nākamā audita pieprasījuma

Ja jūsu komanda joprojām meklē “DORA RTS/ITS checklist”, “DORA ICT risk management template”, “DORA third-party oversight” vai “DORA TLPT requirements”, nākamais solis ir pārvērst šos meklējumus kontrolētos pierādījumos.

Sāciet ar četrām darbībām šonedēļ:

1. Izveidojiet vai atjauniniet savu DORA atbilstības reģistru, izmantojot Clarysec politikas modeli.
2. Izvēlieties vienu kritisku funkciju un izsekojiet to caur risku reģistru, piegādātāju atkarību reģistru, incidentu darbplūsmu, BIA un testēšanas plānu.
3. Pārskatiet piecus būtiskākos IKT piegādātājus attiecībā uz aizstājamību, apakšuzņēmējiem, incidentu klauzulām un izstāšanās iespējām.
4. Izveidojiet testēšanas pierādījumu paketi ar tvērumu, autorizāciju, rezultātiem, trūkumu novēršanu un atkārtotu testēšanu.

Clarysec var palīdzēt to ieviest, izmantojot Zenith Blueprint, politiku veidnes un Zenith Controls, lai jūsu DORA 2026 programma būtu praktiska, proporcionāla un gatava auditam.