DORA-valmidus finantsüksustele ja nende IKT-tarnijatele

DORA-t on kohaldatud alates 17. jaanuarist 2025. Finantsüksuste jaoks tähendab valmisolek nüüd digitaalse tegevuskerksuse tegevusmudeli toimimas hoidmist, mitte tulevaseks tähtajaks valmistumist. Tehnoloogiatarnijate jaoks tähendab see kliendisuunaliste kohustuste mõistmist ja seda, kas kohaldub eraldi otsene järelevalvekord.

Juhtkonna küsimus on praktiline: kas organisatsioon suudab selgitada, millised finantsteenused sõltuvad millistest IKT-süsteemidest, kuidas häiretega toime tullakse ja millised tõendid toetavad tema taastamiseeldusi? Poliitikad on olulised, kuid ainuüksi nemad sellele küsimusele vastata ei suuda. Juhtkond vajab seotud vaadet vastutusaladele, sõltuvustele, lepingutele, testidele, intsidentidele ja lahendamata riskidele.

Tehke oma roll kindlaks enne kontroll-loendi koostamist

Alustage iga asjakohase juriidilise isiku kohta dokumenteeritud kohaldatavuse otsusest. DORA artikkel 2 määratleb hõlmatud kategooriad ja välistused. Ettevõte, mis kirjeldab end finantstehnoloogia ettevõtte, idufirma või VKE-na, ei ole automaatselt kohaldamisalas ega sellest vabastatud.

Hõlmatud finantsüksuste näited on krediidiasutused, makseasutused, investeerimisühingud ja kindlustusandjad, arvestades määruse üksikasjalikke kohaldamisala reegleid. Dokumenteerige kohaldatav kategooria, mis tahes välistus või erand, asjakohane pädev asutus ja oma järelduse põhjendus.

Tarnijate puhul eristage kolme positsiooni:

Tarnija, kes toetab kriitilist või olulist finantsfunktsiooni, ei ole juba ainuüksi seetõttu määratud kriitiline IKT-teenuse pakkujast kolmas isik. Finantsüksused hindavad oma funktsioonide ja sõltuvuste olulisust; kriitiliste pakkujate määramine toimub artikli 31 kohase järelevalveraamistiku kaudu.

Asukoht ei lahenda tarnija küsimust. USA-s asuv pilve- või tarkvarapakkuja võib ELi finantsüksusi teenindades seista silmitsi DORA-ga seotud kliendinõuetega. See äriline suhe ei muuda teda automaatselt kõigi finantsüksusele pandud kohustuste subjektiks.

Ka proportsionaalsus vajab põhjendatud hinnangut. Artikkel 4 arvestab tegureid, sealhulgas suurust, üldist riskiprofiili ning teenuste laadi, ulatust ja keerukust. Artikkel 16 näeb määratletud kategooriate jaoks ette lihtsustatud IKT-riskijuhtimise raamistiku. Need ei ole omavahel asendatavad mõisted ning tavaline VKE staatus ei ole universaalne otsetee. Hoidke sobivuse analüüs koos kohaldamisala otsusega.

Muutke juhtkonna vastutus nähtavaks

DORA artikli 5 kohaselt on juhtorganil lõplik vastutus finantsüksuse IKT-riski juhtimise eest. Rakendamise delegeerimine CISO-le, tehnoloogiameeskonnale või välisele pakkujale ei kanna seda vastutust üle.

Juhtkond peaks kindlaks määrama, kes otsuseid ette valmistab, kes need kinnitab ja kes kontrollib, kas rakendamine toimib. Tegevusmudel peaks hõlmama talitluspidevust, intsidentidele reageerimist ja taastamist, kolmandate osapoolte kokkuleppeid, eelarvet ja sisuka järelevalve jaoks vajalikke teadmisi.

Praktiline soovitus on anda juhtkonnale otsustele keskendunud aruandepakett, mitte valmidusprotsendiga armatuurlaud. Lisage:

• Kriitilised või olulised funktsioonid, mille taastamiseeldused on testimata.
• Olulised intsidendid, mõju klientidele ja lõpetamata parandusmeetmed.
• Tarnijasõltuvused, mille lepingud on puudulikud või väljumisvõimalused nõrgad.
• Olulised meetmete puudujäägid, vastutavad omanikud ja parandamise kuupäevad.
• Otsused, mis nõuavad rahastamist, tarnija vahetust või selgesõnalist riskile reageerimist.

Iga puudujäägi puhul tuleks eristada regulatiivset nõuet, praegust tegevuslikku nõrkust ja kavandatud parandust. Puuduv kinnituskirje erineb varukoopiast, mida ei saa taastada. Mõlemad võivad vajada tegutsemist, kuid nõuavad erinevaid omanikke ja prioriteete.

Juhtkonna poolt parandusplaani kinnitamine ei ole luba kohaldatavate kohustuste täitmist lõputult edasi lükata. Kui puudujääk on oluline, kaaluge pikemaajalise lahenduse kõrval viivitamatuid kaitsemeetmeid, eskaleerimist ja võimalikke järelevalvelisi tagajärgi.

Ehitage programm üles finantsfunktsioonide ümber

Varade inventar on vajalik, kuid toimepidevuse planeerimine peaks algama teenusest, mis peab jätkuma. Tehke kindlaks finantsfunktsioon, selle äriomanik, häire tagajärjed ning seda toetavad süsteemid ja pakkujad.

Makseteenuse puhul kaardistage identiteet, pilvetaristu, tehingute töötlemine, seire ja tarnija eskaleerimine. Kaasake vähem nähtavad sõltuvused, nagu DNS, ühenduvus, privilegeeritud juurdepääs, krüpteerimisvõtmed ja tugitööriistad. Alternatiivne tootmiskeskkond võib olla kasutuskõlbmatu, kui see sõltub samast rikkis identiteediteenusest.

Saadud kaart peaks siduma iga funktsiooni järgmisega:

• Toetavad rakendused, taristu, teabevarad ja välised teenused.
• Asjakohased lepingud ja teenuse omanikud.
• Taastamiseesmärgid ja neid toetav mõjuanalüüs.
• Tuvastamise, reageerimise, taastamise ja suhtluse korraldus.
• Testid, leiud ja lahendamata sõltuvusriskid.

Valideerige kaart nii tegevus- kui ka ärimeeskondadega. Hankekirjed näitavad, mida osteti; need ei näita tingimata, kuidas teenus täna toimib.

Kasutage seda mudelit IKT-riskijuhtimise, intsidentide haldamise ja nendest teatamise, toimepidevuse testimise ning IKT-kolmandate osapoolte riski korraldamiseks. DORA sisaldab ka sätteid vabatahtliku küberohuteabe jagamise kohta. Osalemise korral määratlege liikmesus, konfidentsiaalsus, lubatud kasutus ja käsitlemisreeglid, selle asemel et käsitleda jagamist intsidendiandmete piiranguteta vahetusena.

Muutke IKT-riskijuhtimine rahastatud tööks

DORA IKT-riskijuhtimise sätted hõlmavad tuvastamist, kaitset ja ennetamist, avastamist, reageerimist ja taastamist, õppimist ja suhtlust. Raamistik peab neid tegevusi siduma, mitte jätma neid eraldi poliitikakogumiteks.

Alustage puudujääkide hindamist kaardistatud funktsioonidest. Küsige, kas juurdepääsukontrollid kaitsevad nende süsteeme, kas haavatavustega tegeletakse, kas muudatusi kontrollitakse, kas kahtlast tegevust tuvastatakse ja kas taastamiskorraldus kajastab realistlikke rikkeid. Võtke pahatahtlike rünnakute kõrval arvesse ka tehnilisi tõrkeid ja tegevusvigu.

Iga olulise nõrkuse kohta looge parandustöö kirje, mis sisaldab omanikku, ärimõju, nõutavat tegevust, lõpetamise kriteeriume ja sulgemise tõendeid. Sõltuvused on olulised: taastamisprotseduuride parandamine võib nõuda muudatusi varukoopiatele juurdepääsus, tarnija kohustustes ja töötajate koolituses, enne kui õnnestunud test on võimalik.

Taastamiseesmärgid peaksid tulenema ärivajadustest ja mõjuanalüüsist, mitte sellest, mida tarnija standardne teenustase juhtumisi pakub. Kui tehniline võimekus ei suuda eesmärki täita, peab juhtkond otsustama, kas parandada arhitektuuri, muuta teenusekorraldust või tegevusmudel uuesti läbi mõelda. Talitluspidevuse plaani kirjutatud sihtväärtus ei ole taastatavuse tõend.

Valmistage intsidendiotsused ette enne häiret

DORA nõuab, et finantsüksused haldaksid IKT-intsidente ja teataksid suurtest intsidentidest asjakohasele pädevale asutusele. Artiklid 17–23 kehtestavad raamistiku; kohaldatavad regulatiivsed tehnilised standardid ja rakenduslikud tehnilised standardid annavad üksikasjalikud klassifitseerimiskriteeriumid, künnised, aruannete sisu ja menetlused.

Ärge toetuge üksikasjaliku teatamisajakava osas üldisele intsidendi kontroll-loendile. Hoidke ajakohast teatamismaatriksit, milles on märgitud kohaldatavad standardid, asutuse juhised, esitamiskanal, teatamisetapid ja tähtaegade arvutamine. Määrake vastutus selle ajakohasena hoidmise eest.

Reageerimisprotsess peaks muutma mitu otsust surve all teostatavaks:

• Kes dokumenteerib tuvastamise, hindamise ja klassifitseerimise ajatemplid?
• Kes hangib mõjuteabe tegevusüksustelt ja tarnijatelt?
• Kes otsustab, kas suure intsidendi kriteeriumid on täidetud?
• Kes kinnitab ja esitab aruanded, sealhulgas väljaspool tavapärast tööaega?
• Kes tegeleb klientidega suhtlemise ja muude kohaldatavate teavitustega?

Dokumenteerige klassifitseerimise põhjendus ka siis, kui intsidendist ei teatata kui suurest. Puudulik esialgne pilt peaks teabe lisandumisel käivitama uue hindamise, mitte püsiva eelduse, et sündmus on väheoluline.

Tarnija teavitamiskohustused peaksid jätma finantsüksusele piisavalt aega oma kohustuste hindamiseks ja täitmiseks. Teatamisülesandeid võib lubatud juhtudel sisse osta, kuid vastutus jääb finantsüksusele.

Kui suur IKT-intsident mõjutab klientide finantshuve, nõuab DORA, et finantsüksused teavitaksid neid kliente põhjendamatu viivituseta intsidendist ja meetmetest, mis on võetud selle kahjulike mõjude leevendamiseks. Hinnake eraldi isikuandmetega seotud rikkumise kohustusi ja muid kohaldatavaid reegleid. Üks häire võib tekitada mitu teavitamisotsust erinevate adressaatide ja õiguslike kriteeriumidega.

Testige eeldusi, millele juhtkond toetub

Digitaalse tegevuskerksuse testimise programm peaks olema proportsionaalne ja riskipõhine. Haavatavuste hindamised, stsenaariumiharjutused, turvatestimine ja taastamistestid vastavad erinevatele küsimustele; ühtegi neist ei tohiks käsitleda teiste universaalse asendajana.

Lauaharjutus võib näidata, kas otsustajad mõistavad eskaleerimist. See ei saa tõendada, et tehinguandmeid saab täpselt taastada. Läbistustest võib paljastada ärakasutatavaid nõrkusi, tõendamata, et alternatiivne tarnija suudab teenuse üle võtta.

Määratlege iga testi puhul funktsioon, stsenaarium, ulatus, edukuse kriteeriumid, vajaduse korral sõltumatuse korraldus ja oodatavad tõendid. Säilitage tulemused, leiud, parandusotsused ja kordustestide tulemused. Kontrollige kohaldatavaid katvuse ja sageduse nõudeid DORA ja asjakohaste standardite alusel, sealhulgas mis tahes erandeid või lihtsustatud raamistiku sätteid.

Ohupõhine läbistustestimine on artikli 26 kohaselt eraldi järelevalvenõue valitud finantsüksustele. See ei ole üldine kohustus igale finantsettevõttele või IKT-tarnijale.

Juhtkond peaks üle vaatama ebaõnnestunud eeldused, mitte ainult seda, kas teste tehti. Kui harjutus näitab, et taastamine sõltub ühest kättesaamatust administraatorist, on tulemus tegevusrisk, mis nõuab tegutsemist, mitte lõpetatud testimise verstapost.

Käsitlege kolmandate osapoolte riski teenuse jätkuvuse küsimusena

DORA kohaselt jääb finantsüksus IKT-tarnijaid kasutades oma kohustuste eest vastutavaks. Artiklid 28–30 seovad kolmandate osapoolte riskihindamise, lepingulised kokkulepped, seire ja väljumise planeerimise.

Pidage registrit ja tegevuslikku ülevaadet

Finantsüksused peavad pidama IKT-lepinguliste kokkulepete teaberegistrit nõutaval individuaalsel, allkonsolideeritud ja konsolideeritud tasandil. Kasutage selle struktuuri jaoks kohaldatavaid rakenduslikke tehnilisi standardeid. Hanke arvutustabel või kinnitatud tarnijate loend ei ole automaatselt piisav.

Viige register vastavusse lepingute, teenuse omanikuvastutuse ja sõltuvuskaartidega. Säilitage kriitilisi või olulisi funktsioone toetavate teenuste nõutavad eristused. Uus alltöövõtja, teenuse asukoht või laiendatud ulatus võib riskipilti muuta ka siis, kui tarnija nimi jääb samaks.

Vaadake lepinguid üle tegeliku teenuse suhtes

Hinnake kohaldatavaid lepingulisi nõudeid, sealhulgas teenuse kirjeldusi, asukohti, andmekaitset, juurdepääsu andmetele ja nende taastamist, intsidentide puhul abistamist, koostööd, lõpetamisõigusi ja teenustasemeid. Kriitilisi või olulisi funktsioone toetavad kokkulepped nõuavad lisasätteid, sealhulgas asjakohast aruandlust, jätkuvust, juurdepääsu, kontrolli, auditit ja väljumiskorraldust.

Õigus-, hanke-, tehnoloogia- ja äriomanikud peaksid need koos üle vaatama. Lepingulist auditiõigust võib olla praktikas raske kasutada; lubatud taastamiskorraldus ei pruugi hõlmata kliendi kogu teenuseahelat. Tuvastage need piirangud enne kokkuleppe aktsepteerimist.

Uurige kontsentratsiooni ja väljumisvõimekust

Kontsentratsioonirisk ei piirdu mitme teenuse ostmisega ühelt ettevõttelt. Erinevad tarnijad võivad toetuda samale pilveplatvormile, regioonile, võrgule või alltöövõtjale. Hinnake asendatavust, migratsiooni keerukust ja ühise rikke tagajärgi.

Väljumisplaan peaks käsitlema andmevorminguid, väljavõtmist, juurdepääsu, migratsioonisõltuvusi, üleminekutuge, kustutamist ja jätkuvust ülemineku ajal. Kriitiliste või oluliste funktsioonide puhul käsitlege väljumise testimist ja ülevaatust sisulise tööna, mitte dokumendi kirjutamise harjutusena.

Tarnijad võivad koostada ühtse kindlustandmise paketi, mis sisaldab teenuse ulatust, vastutuse piire, intsidendikontakte, jätkuvuse tõendeid, alltöövõtu teavet ja lepingulisi seisukohti. Kliendipõhised nõuded vajavad siiski ülevaatust; sertifikaat neid ei asenda.

Mõistke, kus DORA ja NIS2 kohtuvad

DORA on vahetult kohaldatav ELi määrus. NIS2 on riigisisese õiguse kaudu rakendatav direktiiv, mille kohaldatavus sõltub sektorist, suurusest, teenusest ja kaasamisreeglitest. Selle riigisisesesse õigusesse ülevõtmise tähtaeg oli 17. oktoober 2024; organisatsioonid peavad uurima kohaldatavat riigisisest rakendust, selle asemel et eeldada üht identset tegevusraamistikku.

DORA artikli 1 lõige 2 koos NIS2 artikliga 4 kehtestab hõlmatud finantsüksuste jaoks asjakohastes valdkondades valdkonnaspetsiifilise suhte. Ärge tõlgendage seda juhisena dubleerida samaväärseid riskijuhtimise ja intsidentidest teatamise meetmeid. Samamoodi ärge eeldage, et see kaotab kohustused igalt finantskontserni või selle tarneahela ettevõttelt.

Panka teenindav hallatud teenuste pakkuja võib vajada oma NIS2 hinnangut, täites samal ajal DORA-ga seotud lepingulisi kohustusi. Üksuste kaupa koostatud kohustuste maatriks peaks kajastama õiguslikku alust, ulatust, asutust, teatamisteed ja nõutavaid tõendeid.

Ühised meetmed võivad toetada DORA-t, ISO 27001-t, privaatsuskohustusi ja klientidele antavaid tagatisi, kui ulatus ja tõendid ühtivad. Kasutage juurdepääsuülevaatust või taastamistesti uuesti, kui see tõesti toetab mitut nõuet, säilitades samal ajal finantssektori üksikasjad. ISO 27001 sertifikaat ei tõenda DORA-le vastavust.

Ka jõustamine erineb. DORA finantsüksustega seotud järelevalvevolitused ja karistused sõltuvad selle sätetest ja kohaldatavatest riigisisestest meetmetest; määratud kriitilistele pakkujatele kehtib eraldi järelevalvekord. Ärge planeerige riskieelarvet oletatava universaalse DORA trahvi ümber. Hinnake asjakohast õiguslikku riski ja ebapiisava toimepidevuse tegevuslikke tagajärgi.

Näide: makseteenuse sõltuvuste ülevaatus

Vaadelgem illustratiivset makseasutust, mis kasutab pilveplatvormi, identiteedipakkujat ja sisseostetud seireteenust. Oletame, et asutus kuulub DORA kohaldamisalasse ning maksete täitmine on klassifitseeritud kriitiliseks või oluliseks funktsiooniks.

Esimene ülevaatus tuvastab kolm nõrkust: tootmis- ja taastekeskkond jagavad sama identiteedisõltuvust; seiretarnija intsidentide eskaleerimise protsess on ebaselge; ning pilvest väljumise plaan loetleb alternatiivse pakkuja, näitamata andmete väljavõtmist ja migratsiooni.

Juhtkond tellib kolm omavahel seotud tööpaketti:

Äriomanik kontrollib, kas maksete taastamiseesmärgid jäävad saavutatavaks. Vastavusfunktsioon kontrollib, et teatamisprotseduurid ja registrikanded kajastavad kokkuleppeid. Juhtkond kinnitab vajaliku rahastuse ja vaatab üle järelejäänud piirangud.

See näide ei tõenda iseenesest nõuetele vastavust. See näitab, kuidas üks funktsioon võib paljastada otsuseid, mis jääksid eraldi poliitika-, tarnija- ja testimise kontroll-loendites varjatuks.

Kehtestage tõenditel põhinev ülevaatusrütm

DORA-l ei ole universaalset sertifitseerimisprotsessi, mis asendaks jätkuvaid kohustusi. Sõltumatu kindlustandmine võib juhtkonda informeerida, kuid valmisolekut tuleb tõendada toimivate meetmete, kirjete ja vajaduse korral järelevalveasutusega suhtlemise kaudu.

Praktiline järgmine samm on valida üks kriitiline või oluline funktsioon ja koondada selle kohaldamisala otsus, sõltuvuskaart, riskihinnang, lepingud, intsidendiprotseduurid, testitulemused ja avatud tegevused. Vaadake üle, kas need kirjed jutustavad järjepidevat lugu.

Secani toetab seda töövoogu süsteemide ja teenuste modelleerimise, sõltuvuste sidumise ning nõuete, tõendite, omanike, ülesannete ja läbivaatusotsuste kontekstis hoidmise kaudu. Laadige olemasolev materjal üles asjakohaste objektide juurde, muutke puudujäägid määratud tööks ja säilitage tehisintellekti abil tehtud soovituste ja järelduste selgesõnaline inimlik kinnitus.

Laiendage sellest esimesest funktsioonist edasi, kui omanikuvastutus ja tõendite teekonnad on selged. Juhtkond peaks nägema, mida on tõendatud, mis jääb ebakindlaks ja milline otsus on järgmisena vajalik.