Kui olete krediidiühistu, makseasutus, kindlustusvahendaja või investeerimisfondi valitseja, kehtib DORA teie suhtes juba praegu. Kui olete IT-ettevõte, mis haldab servereid, pakub pilveteenuseid või arendab tarkvara selliste klientide jaoks, jõuab DORA teieni klienditeenuse lepingute kaudu. Enamasti tuleb see üllatusena: palutakse allkirjastada uus lisa kahe nädala jooksul.
DORA on ELi määrus 2022/2554 finantssektori digitaalse operatsioonilise vastupidavuse kohta ning see kehtib alates 17. jaanuarist 2025. Erinevalt direktiivist kohaldub määrus otse, ilma siseriiklikku õigusse ülevõtmata, nii et Finantsinspektsioon järelevalvab seda täpselt sellisena, nagu see on kirjutatud.
Selles artiklis selgitame määruse viit sammast lihtsas keeles, näitame, mida need IT-teenusepakkuja jaoks praktikas tähendavad, ning räägime, kuidas me ise oma klientide jaoks nendega toime tuleme.
DORA viis sammast
Määrus toetub viiele valdkonnale. Igaühel neist on dokumenteerimise pool ja tehniline pool.
IKT riskijuhtimine
Finantsasutusel peab olema ülemjuhtkonna kinnitatud info- ja kommunikatsioonitehnoloogia (IKT) riskijuhtimise raamistik: varade register, riskihindamine, kaitsemeetmed, avastamisvõimekus ning reageerimis- ja taastamiskavad. Vastutus kõige eest lasub juhtorganil, mitte IT-osakonnal. Praktikas tähendab see, et juhtkond peab mõistma, millised süsteemid on kriitilised, mis juhtub nende seiskumisel ja kui kaua saab asutus ilma nendeta töötada.
Intsidentide haldamine ja nendest teavitamine
Kõik IKT-ga seotud intsidendid logitakse ja klassifitseeritakse mõju järgi ning suurematest teavitatakse järelevalveasutust rangete tähtaegade jooksul: esmane teade mõne tunni jooksul, hiljem vahearuanne ja lõpparuanne. Asutus peab suutma kiiresti hinnata, kui palju kliente intsident mõjutas, kui kaua teenus seisis ja kas andmeid lekkis. Ilma logide ja seireta on see võimatu.
Digitaalse operatsioonilise vastupidavuse testimine
Kaitsest ei piisa, seda tuleb regulaarselt testida. Baastase hõlmab haavatavuste skannimist, konfiguratsiooni ülevaatusi, varukoopia taastamise teste ja stsenaariumiharjutusi. Suuremad ja süsteemselt olulised asutused peavad lisaks tegema ohupõhist läbimurdetestimist, kus spetsialistid simuleerivad päris rünnakut. Testitulemused dokumenteeritakse ja nõrkused parandatakse kava järgi.
Kolmandatest osapooltest tuleneva IKT-riski juhtimine
See on sammas, mis puudutab IT-teenusepakkujaid kõige rohkem. Asutus peab pidama registrit kõigi oma IKT-teenusepakkujate kohta, hindama igaühe riski, lisama lepingutesse kohustuslikud tingimused ning omama väljumisstrateegiat juhuks, kui pakkuja lõpetab teenuse osutamise. Teenuseid, mis toetavad kriitilisi funktsioone, näiteks raamatupidamissüsteemi majutamist või varukoopiate hoidmist, vaadatakse eriti hoolikalt.
Teabevahetus
Asutusi julgustatakse jagama teavet ohtude ja haavatavuste kohta nii omavahel kui ka ametiasutustega. Väikese asutuse jaoks tähendab see tavaliselt osalemist sektoripõhistes töörühmades ning Riigi Infosüsteemi Ameti (RIA) ja CERT-EE hoiatuste jälgimist.
Mida see tähendab IT-teenusepakkujale
Kui osutate IT-teenuseid finantsasutusele, ei saa klient teiega koostööd teha, kui te ei toeta tema DORA kohustusi. Meie kogemuse järgi taandub see pakkuja poolel kolmele konkreetsele asjale.
Lepingud
Finantsasutusega sõlmitud leping peab sisaldama selgeid sätteid: täpselt kirjeldatud teenused ja teenusetasemed, andmete hoiukoht (ELi sees või mitte), intsidentidest kliendile teatamise tähtajad, kliendi ja järelevalveasutuse auditeerimisõigus, alltöövõtjate kasutamise reeglid ning lepingu lõpetamise tingimused üleminekuperioodiga. Kui teie tüüplepingus neid ei ole, saadab klient oma lisa. Parem on omada enda oma, mis on ette valmistatud.
Register
Klient täidab teenusepakkujate registri ettenähtud vormingus ning vajab teie kohta teavet: juriidilise isiku andmed, teenuse liik, kriitilisus, andmete asukoht ja alltöövõtjad. Pakkuja peaks hoidma valmis vastuste komplekti, sest eri klientide küsimustikud kattuvad suuresti.
Väljumiskavad
Iga asutus peab suutma liikuda ühelt pakkujalt teisele ilma tegevust katkestamata. Teie kohustus on kirjeldada, kuidas andmed tagastate, millises vormingus, mis aja jooksul ja mida pärast üleandmist kustutate. Pakkuja, kes ei oska selgelt öelda, kuidas klient lahkumisel oma andmed tagasi saab, on risk ja see asendatakse.
Veel üks asi, mille pakkujad sageli kahe silma vahele jätavad, on alltöövõtjad. Kui pakute kliendile varukoopiate hoidmist ja koopiad asuvad füüsiliselt kolmanda osapoole juures, peab klient sellest teadma ja tal on õigus vastu vaielda. Alltöövõtjate ahel tuleb lepingus kirjeldada ja muutumisel uuendada.
Allpool on näha, kuidas samad nõuded paistavad mõlemalt poolt.
| Nõue | Finantsasutus | IT-teenusepakkuja |
|---|---|---|
| Riskijuhtimine | Riskiregister, juhtkonna otsused | Tõendid oma turvapoliitikate ja kontrollide kohta |
| Intsidendid | Teavitus järelevalveasutusele tähtaegade jooksul | Teavitus kliendile kokkulepitud aja jooksul, logid |
| Testimine | Testikava ja tulemused | Osalemine taastetestides, haavatavuste parandamine |
| Kolmandad osapooled | Teenusepakkujate register, väljumisstrateegia | Lepingu lisa, alltöövõtjate nimekiri, väljumiskava |
| Teabevahetus | Ohtude seire, osalemine töörühmades | Hoiatused kliendile asjakohaste ohtude kohta |
Varundamine ja taastamine: kus kõige sagedamini vigu tehakse
DORA nõuab mitte ainult varukoopiate olemasolu, vaid ka tõendamist, et nendest saab tegevuse taastada kindlaksmääratud aja jooksul. Asutus peab iga kriitilise süsteemi jaoks seadma taasteaja ja taastepunkti eesmärgid (RTO ja RPO) ning varukoopiad peavad olema põhikeskkonnast füüsiliselt ja loogiliselt eraldatud.
Kõige sagedasem viga on hoida varukoopiaid samas võrgus või samal pakkujal samas andmekeskuses. Lunavara, mis krüpteerib serverid, krüpteerib ka need. Teine viga on taastamine, mida pole kunagi testitud: intsidendi ajal selgub, et varukoopia on poolik või et taastamine võtab tundide asemel päevi.
Oma klientidele pakume muutumatuid varukoopiaid, mida ei saa muuta ja mis on võrgust nähtamatud, ning kriitiliste süsteemide jaoks PlanB taristu taastamist, kus kogu keskkonna saab meie pilves püsti panna, kui põhikeskkond muutub kättesaamatuks. Soovi korral hoiame varukoopiaid ka Amazoni andmekeskuses Saksamaal, et geograafiline eraldatus oleks päris, mitte ainult deklareeritud.
Kuidas MDP CLOUD aitab
Töötame mõlemalt poolt: oleme finantsasutuste IT-teenusepakkuja ning aitame teisi IT-pakkujaid ette valmistada nende klientide nõuete täitmiseks. Meie meeskonnal on kehtivad ISACA sertifikaadid (CISA, CISM, CRISC jt) ning osutame teenuseid kooskõlas ISO 27001 nõuetega, mistõttu on meil kliendiküsimustikele vastused juba valmis.
Finantsasutusele aitame koostada IKT varade ja teenusepakkujate registrid, teha riskihindamise, valmistada ette intsidentide haldamise protseduuri koos teavitusmallidega ning planeerida ja läbi viia vastupidavuse teste. IT-teenusepakkujale aitame ette valmistada lepingu lisa, turvapoliitikate komplekti, väljumiskava malli ja tehnilised tõendid, mida klient küsib.
Kust alustada
- Selgitage välja, kas DORA kehtib teie suhtes otse (olete finantsasutus) või klientide kaudu (olete teenusepakkuja). Tööde järjekord sõltub sellest.
- Koostage nimekiri oma kriitilistest funktsioonidest ning neid toetavatest süsteemidest ja teenusepakkujatest. See on registri ja riskihindamise alus.
- Vaadake üle lepingud teenusepakkujate või klientidega ja märkige, milliseid tingimusi neis ei ole.
- Kontrollige oma varukoopiaid: kus need on, kas need on põhivõrgust eraldatud ja millal neid viimati päriselt taastati.
- Koostage intsidentidest teavitamise protseduur kontaktide ja tähtaegadega, et intsidendi ajal ei peaks keegi otsima, kellele helistada.
Kogu tee esimesest sammust valmisolekuni järelevalveasutuse ees oleme kirjeldanud DORA teenuse lehel. Kui eelistate alustada vestlusest, võtke meiega ühendust ja esimesel kohtumisel ütleme, millised nõuded on teie jaoks olulised ja mille pärast te muretsema ei pea.
