Gatavība DORA prasībām finanšu vienībām un to IKT piegādātājiem

DORA tiek piemērota kopš 2025. gada 17. janvāra. Finanšu vienībām gatavība tagad nozīmē digitālās darbības noturības darbības modeļa uzturēšanu, nevis gatavošanos nākotnes termiņam. Tehnoloģiju piegādātājiem tā nozīmē izpratni par pienākumiem pret klientiem un par to, vai uz tiem attiecas atsevišķs tiešās uzraudzības režīms.

Vadības jautājums ir praktisks: vai organizācija var izskaidrot, kuri finanšu pakalpojumi ir atkarīgi no kurām IKT sistēmām, kā tiks risināti traucējumi un kādi pierādījumi pamato tās atjaunošanas pieņēmumus? Politikas ir svarīgas, taču tās vienas pašas uz šo jautājumu atbildēt nevar. Vadībai nepieciešams saistīts skatījums uz atbildībām, atkarībām, līgumiem, testiem, incidentiem un neatrisinātiem riskiem.

Nosakiet savu lomu, pirms veidojat kontrolsarakstu

Sāciet ar dokumentētu piemērojamības lēmumu katrai attiecīgajai juridiskajai personai. DORA 2. pants nosaka tvērumā esošās kategorijas un izņēmumus. Uzņēmums, kas sevi raksturo kā FinTech, jaunuzņēmumu vai MVU, automātiski neietilpst tvērumā un nav no tā atbrīvots.

Tvērumā esošu finanšu vienību piemēri ir kredītiestādes, maksājumu iestādes, ieguldījumu brokeru sabiedrības un apdrošināšanas sabiedrības, ievērojot regulas detalizētos tvēruma noteikumus. Reģistrējiet piemērojamo kategoriju, jebkuru izņēmumu vai atbrīvojumu, attiecīgo kompetento iestādi un sava secinājuma pamatojumu.

Piegādātājiem jānošķir trīs pozīcijas:

Piegādātājs, kas atbalsta kritisku vai svarīgu finanšu funkciju, tikai šī iemesla dēļ nav izraudzīts kritisks IKT trešās puses pakalpojumu sniedzējs. Finanšu vienības novērtē savu funkciju un atkarību nozīmīgumu; kritisko pakalpojumu sniedzēju izraudzīšana notiek uzraudzības regulējuma ietvaros saskaņā ar 31. pantu.

Atrašanās vieta neatrisina piegādātāja jautājumu. ASV bāzēts mākoņpakalpojumu vai programmatūras sniedzējs var saskarties ar ar DORA saistītām klientu prasībām, apkalpojot ES finanšu vienības. Šīs komerciālās attiecības automātiski nepakļauj to visiem pienākumiem, kas uzlikti finanšu vienībai.

Arī samērīgumam nepieciešams pamatots novērtējums. 4. pants ņem vērā tādus faktorus kā lielums, vispārējais riska profils un pakalpojumu raksturs, mērogs un sarežģītība. 16. pants paredz vienkāršotu IKT riska pārvaldības satvaru noteiktām kategorijām. Tie nav savstarpēji aizstājami jēdzieni, un parasts MVU statuss nav universāls saīsinājums. Glabājiet atbilstības analīzi kopā ar tvēruma lēmumu.

Padariet vadības atbildību redzamu

Saskaņā ar DORA 5. pantu vadības struktūrai ir galīgā atbildība par finanšu vienības IKT riska pārvaldību. Ieviešanas deleģēšana CISO, tehnoloģiju komandai vai ārējam pakalpojumu sniedzējam šo atbildību nenodod.

Vadībai jānosaka, kurš ierosina lēmumus, kurš tos apstiprina un kurš pārbauda, vai ieviešana darbojas. Darbības modelim jāaptver darbības nepārtrauktība, reaģēšana uz incidentiem un atjaunošana, vienošanās ar trešām pusēm, budžets un zināšanas, kas nepieciešamas jēgpilnai uzraudzībai.

Praktisks ieteikums ir sniegt vadībai uz lēmumiem orientētu ziņojumu paketi, nevis informācijas paneli ar izpildes procentiem. Iekļaujiet:

• Kritiskas vai svarīgas funkcijas ar netestētiem atjaunošanas pieņēmumiem.
• Būtiskus incidentus, ietekmi uz klientiem un neizpildītās korektīvās darbības.
• Atkarības no piegādātājiem ar nepilnīgiem līgumiem vai vājām aiziešanas iespējām.
• Nozīmīgas kontroļu nepilnības, atbildīgos īpašniekus un novēršanas datumus.
• Lēmumus, kuriem nepieciešams finansējums, piegādātāja maiņa vai skaidra reakcija uz risku.

Katrā nepilnībā jānošķir regulatīvā prasība, pašreizējā darbības vājā vieta un ierosinātais risinājums. Trūkstošs apstiprinājuma ieraksts atšķiras no rezerves kopijas, kuru nevar atjaunot. Abiem var būt nepieciešama rīcība, taču tiem vajadzīgi atšķirīgi īpašnieki un prioritātes.

Vadības apstiprināts novēršanas plāns nav atļauja bezgalīgi atlikt piemērojamos pienākumus. Ja nepilnība ir būtiska, līdztekus ilgtermiņa risinājumam apsveriet tūlītējus aizsardzības pasākumus, eskalāciju un iespējamās sekas uzraudzības jomā.

Veidojiet programmu ap finanšu funkcijām

Aktīvu inventārs ir nepieciešams, taču noturības plānošana jāsāk ar pakalpojumu, kura darbībai jāturpinās. Identificējiet finanšu funkciju, tās biznesa īpašnieku, traucējumu sekas un sistēmas un pakalpojumu sniedzējus, kas to atbalsta.

Maksājumu pakalpojumam kartējiet identitāti, mākoņinfrastruktūru, darījumu apstrādi, uzraudzību un piegādātāju eskalāciju. Iekļaujiet mazāk redzamas atkarības, piemēram, DNS, savienojamību, priviliģēto piekļuvi, šifrēšanas atslēgas un atbalsta rīkus. Alternatīva produkcijas vide var būt neizmantojama, ja tā ir atkarīga no tā paša nedarbojošā identitātes pakalpojuma.

Iegūtajai kartei katra funkcija jāsasaista ar:

• Atbalstošajām lietotnēm, infrastruktūru, informācijas aktīviem un ārējiem pakalpojumiem.
• Attiecīgajiem līgumiem un pakalpojumu īpašniekiem.
• Atjaunošanas mērķiem un tos pamatojošo biznesa ietekmes analīzi.
• Atklāšanas, reaģēšanas, atjaunošanas un komunikācijas kārtību.
• Testiem, konstatējumiem un neatrisinātiem atkarību riskiem.

Validējiet karti kopā ar darbības un biznesa komandām. Iepirkumu ieraksti parāda, kas tika iegādāts; tie ne vienmēr parāda, kā pakalpojums darbojas šodien.

Izmantojiet šo modeli, lai organizētu IKT riska pārvaldību, incidentu pārvaldību un ziņošanu, noturības testēšanu un IKT trešo pušu riska pārvaldību. DORA ietver arī noteikumus par brīvprātīgu kiberdraudu informācijas apmaiņu. Ja piedalāties, definējiet dalību, konfidencialitāti, atļauto izmantošanu un apstrādes noteikumus, nevis uzskatiet apmaiņu par neierobežotu incidentu datu apmaiņu.

Pārvērtiet IKT riska pārvaldību finansētā darbā

DORA IKT riska pārvaldības noteikumi aptver identificēšanu, aizsardzību un novēršanu, atklāšanu, reaģēšanu un atjaunošanu, mācīšanos un komunikāciju. Satvaram šīs darbības jāsasaista, nevis jāatstāj tās kā atsevišķi politiku krājumi.

Sāciet nepilnību novērtējumu ar kartētajām funkcijām. Jautājiet, vai piekļuves kontroles aizsargā to sistēmas, vai ievainojamības tiek novērstas, vai izmaiņas tiek kontrolētas, vai aizdomīgas darbības tiek atklātas un vai atjaunošanas kārtība atspoguļo reālistiskas kļūmes. Līdztekus ļaunprātīgiem uzbrukumiem ņemiet vērā arī tehniskas kļūmes un darbības kļūdas.

Katrai būtiskai vājajai vietai izveidojiet novēršanas ierakstu ar īpašnieku, ietekmi uz biznesu, nepieciešamo darbību, izpildes kritērijiem un slēgšanas pierādījumiem. Atkarības ir svarīgas: atjaunošanas procedūru uzlabošanai var būt nepieciešamas izmaiņas piekļuvē rezerves kopijām, piegādātāju saistībās un darbinieku apmācībā, pirms iespējams veiksmīgs tests.

Atjaunošanas mērķiem jāizriet no biznesa vajadzībām un ietekmes analīzes, nevis no tā, ko nejauši piedāvā piegādātāja standarta pakalpojuma līmenis. Ja tehniskās iespējas nevar sasniegt mērķi, vadībai jāizlemj, vai uzlabot arhitektūru, mainīt pakalpojuma kārtību vai pārskatīt darbības modeli. Darbības nepārtrauktības plānā ierakstīts mērķis nav atjaunojamības pierādījums.

Sagatavojiet incidentu lēmumus pirms traucējuma

DORA prasa finanšu vienībām pārvaldīt ar IKT saistītus incidentus un ziņot par lieliem incidentiem attiecīgajai kompetentajai iestādei. 17.–23. pants nosaka satvaru; piemērojamie regulatīvie tehniskie un īstenošanas standarti nosaka detalizētus klasifikācijas kritērijus, robežvērtības, ziņojumu saturu un procedūras.

Detalizētajam ziņošanas grafikam nepaļaujieties uz vispārīgu incidentu kontrolsarakstu. Uzturiet aktuālu ziņošanas matricu, kurā norādīti piemērojamie standarti, iestādes norādījumi, iesniegšanas kanāls, ziņošanas posmi un termiņu aprēķini. Nosakiet atbildību par tās aktualitātes uzturēšanu.

Reaģēšanas procesam jāpadara vairāki lēmumi izpildāmi spiediena apstākļos:

• Kurš reģistrē atklāšanas, novērtēšanas un klasificēšanas laikspiedolus?
• Kurš iegūst informāciju par ietekmi no darbības komandām un piegādātājiem?
• Kurš izlemj, vai ir izpildīti liela incidenta kritēriji?
• Kurš apstiprina un iesniedz ziņojumus, tostarp ārpus parastā darba laika?
• Kurš atbild par saziņu ar klientiem un citiem piemērojamiem paziņojumiem?

Reģistrējiet klasifikācijas pamatojumu arī tad, ja par incidentu netiek ziņots kā par lielu. Nepilnīgam sākotnējam priekšstatam jāizraisa atkārtots novērtējums, informācijai papildinoties, nevis pastāvīgs pieņēmums, ka notikums ir nenozīmīgs.

Piegādātāju paziņošanas saistībām jāatstāj finanšu vienībai pietiekami daudz laika, lai tā izvērtētu un izpildītu savus pienākumus. Ziņošanas uzdevumus var nodot ārpakalpojumā, ja tas ir atļauts, taču atbildība paliek finanšu vienībai.

Ja liels ar IKT saistīts incidents ietekmē klientu finanšu intereses, DORA prasa finanšu vienībām bez nepamatotas kavēšanās informēt šos klientus par incidentu un pasākumiem, kas veikti tā nelabvēlīgās ietekmes mazināšanai. Atsevišķi izvērtējiet pienākumus saistībā ar personas datu aizsardzības pārkāpumiem un citus piemērojamos noteikumus. Viens traucējums var radīt vairākus paziņošanas lēmumus ar atšķirīgiem saņēmējiem un juridiskiem kritērijiem.

Testējiet pieņēmumus, uz kuriem paļaujas vadība

Digitālās darbības noturības testēšanas programmai jābūt samērīgai un balstītai uz risku. Ievainojamību novērtējumi, scenāriju vingrinājumi, drošības testēšana un atjaunošanas testi atbild uz dažādiem jautājumiem; nevienu no tiem nevajadzētu uzskatīt par universālu aizstājēju pārējiem.

Galda mācības var noskaidrot, vai lēmumu pieņēmēji izprot eskalāciju. Tās nevar pierādīt, ka darījumu datus var precīzi atjaunot. Ielaušanās tests var atklāt izmantojamas vājās vietas, nepierādot, ka alternatīvs piegādātājs spēj pārņemt pakalpojumu.

Katram testam definējiet funkciju, scenāriju, tvērumu, veiksmes kritērijus, neatkarības nodrošināšanu, ja tā nepieciešama, un sagaidāmos pierādījumus. Saglabājiet rezultātus, konstatējumus, novēršanas lēmumus un atkārtoto testu rezultātus. Pārbaudiet piemērojamās pārklājuma un biežuma prasības atbilstoši DORA un attiecīgajiem standartiem, tostarp jebkurus izņēmumus vai vienkāršotā satvara noteikumus.

Uz draudiem balstīta ielaušanās testēšana ir atsevišķa uzraudzības prasība atlasītām finanšu vienībām saskaņā ar 26. pantu. Tas nav vispārējs pienākums katram finanšu uzņēmumam vai IKT piegādātājam.

Vadībai jāpārskata neizdevušies pieņēmumi, nevis tikai tas, vai testi ir notikuši. Ja vingrinājums atklāj, ka atjaunošana ir atkarīga no viena nepieejama administratora, rezultāts ir darbības risks, kam nepieciešama rīcība, nevis pabeigts testēšanas atskaites punkts.

Uzskatiet trešo pušu risku par pakalpojumu nepārtrauktības jautājumu

Saskaņā ar DORA finanšu vienība, izmantojot IKT piegādātājus, joprojām ir atbildīga par saviem pienākumiem. 28.–30. pants sasaista trešo pušu riska novērtēšanu, līgumiskās vienošanās, uzraudzību un aiziešanas plānošanu.

Uzturiet reģistru un darbības ainu

Finanšu vienībām jāuztur informācijas reģistrs par IKT līgumiskajām vienošanām nepieciešamajos individuālajā, subkonsolidētajā un konsolidētajā līmenī. Tā struktūrai izmantojiet piemērojamos īstenošanas standartus. Iepirkumu izklājlapa vai apstiprināto piegādātāju saraksts automātiski nav pietiekams.

Saskaņojiet reģistru ar līgumiem, pakalpojumu īpašniekiem un atkarību kartēm. Saglabājiet nepieciešamos nošķīrumus pakalpojumiem, kas atbalsta kritiskas vai svarīgas funkcijas. Jauns apakšuzņēmējs, pakalpojuma atrašanās vieta vai paplašināts tvērums var mainīt riska ainu pat tad, ja piegādātāja nosaukums paliek tas pats.

Pārskatiet līgumus attiecībā pret faktisko pakalpojumu

Novērtējiet piemērojamās līgumiskās prasības, tostarp pakalpojumu aprakstus, atrašanās vietas, datu aizsardzību, piekļuvi datiem un to atgūšanu, palīdzību incidentu gadījumā, sadarbību, izbeigšanas tiesības un pakalpojumu līmeņus. Vienošanās, kas atbalsta kritiskas vai svarīgas funkcijas, prasa papildu noteikumus, tostarp attiecīgo ziņošanas, nepārtrauktības, piekļuves, pārbaudes, audita un aiziešanas kārtību.

Juristiem, iepirkumu speciālistiem, tehnoloģiju un biznesa īpašniekiem tie jāpārskata kopā. Līgumiskas audita tiesības praksē var būt grūti izmantot; solīta atjaunošanas kārtība var neaptvert klienta pilno pakalpojumu ķēdi. Identificējiet šos ierobežojumus, pirms akceptējat vienošanos.

Izvērtējiet koncentrāciju un aiziešanas spēju

Koncentrācijas risks neaprobežojas ar vairāku pakalpojumu iegādi no viena uzņēmuma. Dažādi piegādātāji var paļauties uz vienu un to pašu mākoņplatformu, reģionu, tīklu vai apakšuzņēmēju. Novērtējiet aizstājamību, migrācijas sarežģītību un kopīgas kļūmes sekas.

Aiziešanas plānā jārisina datu formāti, izgūšana, piekļuve, migrācijas atkarības, atbalsts pārejas laikā, dzēšana un nepārtrauktība pārejas laikā. Kritiskām vai svarīgām funkcijām aiziešanas testēšana un pārskatīšana jāuzskata par būtisku darbu, nevis dokumentu rakstīšanas vingrinājumu.

Piegādātāji var sagatavot konsekventu apliecinājuma paketi, kurā ietverts pakalpojuma tvērums, atbildības robežas, kontaktpersonas incidentu gadījumā, nepārtrauktības pierādījumi, informācija par apakšuzņēmumu līgumiem un līgumiskās nostājas. Klientu specifiskās prasības joprojām ir jāpārskata; sertifikāts tās neaizstāj.

Izprotiet, kur DORA un NIS2 krustojas

DORA ir ES regula ar tiešu piemērojamību. NIS2 ir direktīva, ko ievieš ar nacionālajiem tiesību aktiem, un tās piemērojamība ir atkarīga no nozares, lieluma, pakalpojuma un iekļaušanas noteikumiem. Tās transponēšanas termiņš nacionālajos tiesību aktos bija 2024. gada 17. oktobris; organizācijām jāizvērtē piemērojamā nacionālā ieviešana, nevis jāpieņem viens identisks darbības režīms.

DORA 1. panta 2. punkts kopā ar NIS2 4. pantu nosaka nozarei specifisko saistību tvērumā esošām finanšu vienībām attiecīgajās jomās. Neinterpretējiet to kā norādījumu dublēt līdzvērtīgas riska pārvaldības un ziņošanas par incidentiem kontroles. Tāpat nepieņemiet, ka tas atceļ pienākumus katram finanšu grupas uzņēmumam vai tās piegādes ķēdei.

Pārvaldīto pakalpojumu sniedzējam, kas apkalpo banku, var būt nepieciešams savs NIS2 novērtējums, vienlaikus izpildot ar DORA saistītās līgumsaistības. Pienākumu matricā katrai vienībai atsevišķi jāreģistrē juridiskais pamats, tvērums, iestāde, ziņošanas ceļš un nepieciešamie pierādījumi.

Kopīgas kontroles var atbalstīt DORA, ISO 27001, privātuma pienākumus un apliecinājumu klientiem, ja tvērums un pierādījumi sakrīt. Izmantojiet piekļuves pārskatu vai atjaunošanas testu atkārtoti, ja tas patiešām atbalsta vairākas prasības, vienlaikus saglabājot finanšu nozares specifiku. ISO 27001 sertifikāts nepierāda atbilstību DORA.

Atšķiras arī izpilde. DORA finanšu vienību uzraudzības pilnvaras un sodi ir atkarīgi no tās noteikumiem un piemērojamiem nacionālajiem pasākumiem; izraudzītajiem kritiskajiem pakalpojumu sniedzējiem ir atsevišķs pārraudzības režīms. Neplānojiet riska budžetu, balstoties uz šķietami universālu DORA naudas sodu. Novērtējiet attiecīgo juridisko pakļautību un nepietiekamas noturības darbības sekas.

Praktisks piemērs: maksājumu pakalpojuma atkarību pārskats

Aplūkosim ilustratīvu maksājumu iestādi, kas izmanto mākoņplatformu, identitātes nodrošinātāju un ārpakalpojumā nodotu uzraudzības pakalpojumu. Pieņemsim, ka iestāde ir DORA tvērumā un maksājumu izpilde ir klasificēta kā kritiska vai svarīga funkcija.

Pirmajā pārskatā tiek konstatētas trīs vājās vietas: produkcijas un atjaunošanas videm ir viena un tā pati identitātes atkarība; uzraudzības piegādātāja incidentu eskalācijas process ir neskaidrs; un mākoņa aiziešanas plānā ir norādīts alternatīvs pakalpojumu sniedzējs, nedemonstrējot datu izgūšanu un migrāciju.

Vadība uzdod izpildīt trīs savstarpēji saistītas darba paketes:

Biznesa īpašnieks pārbauda, vai maksājumu atjaunošanas mērķi joprojām ir sasniedzami. Atbilstības funkcija pārbauda, vai ziņošanas procedūras un reģistra ieraksti atspoguļo vienošanās. Vadība apstiprina nepieciešamo finansējumu un pārskata atlikušos ierobežojumus.

Šis piemērs pats par sevi nepierāda atbilstību. Tas parāda, kā viena funkcija var atklāt lēmumus, kas paliktu apslēpti atsevišķos politiku, piegādātāju un testēšanas kontrolsarakstos.

Ieviesiet uz pierādījumiem balstītu pārskatīšanas ritmu

DORA nav universāla sertifikācijas procesa, kas aizstātu pastāvīgos pienākumus. Neatkarīgs apliecinājums var sniegt informāciju vadībai, taču gatavība jāpierāda ar darbojošām kontrolēm, ierakstiem un, ja nepieciešams, sadarbību ar uzraudzības iestādēm.

Praktisks nākamais solis ir izvēlēties vienu kritisku vai svarīgu funkciju un apkopot tās tvēruma lēmumu, atkarību karti, riska novērtējumu, līgumus, incidentu procedūras, testu rezultātus un atklātās darbības. Pārskatiet, vai šie ieraksti veido konsekventu ainu.

Secani atbalsta šo darbplūsmu, modelējot sistēmas un pakalpojumus, sasaistot atkarības un saglabājot prasības, pierādījumus, īpašniekus, uzdevumus un pārskatīšanas lēmumus kontekstā. Augšupielādējiet esošos materiālus pie attiecīgajiem objektiem, pārvērtiet nepilnības piešķirtā darbā un saglabājiet skaidru cilvēka apstiprinājumu mākslīgā intelekta atbalstītiem ieteikumiem un secinājumiem.

Paplašiniet darbu ārpus šīs pirmās funkcijas, kad atbildība un pierādījumu ceļi ir skaidri. Vadībai jāspēj redzēt, kas ir pierādīts, kas joprojām ir neskaidrs un kāds lēmums nepieciešams nākamais.