Spremnost za DORA za financijske subjekte i njihove dobavljače IKT usluga

Akt o digitalnoj operativnoj otpornosti (DORA) primjenjuje se od 17. siječnja 2025. Za financijske subjekte spremnost sada znači održavanje operativnog modela digitalne operativne otpornosti, a ne pripremu za budući rok. Za dobavljače tehnologije znači razumijevanje odgovornosti prema klijentima i toga primjenjuje li se zaseban režim izravnog nadzora.

Pitanje za upravu je praktično: može li organizacija objasniti koje financijske usluge ovise o kojim IKT sustavima, kako će se postupati s poremećajima i koji dokazi podupiru njezine pretpostavke o oporavku? Politike su važne, ali same ne mogu odgovoriti na to pitanje. Uprava treba povezan pregled odgovornosti, ovisnosti, ugovora, testova, incidenata i neriješenih rizika.

Utvrdite svoju ulogu prije izrade kontrolnog popisa

Počnite s dokumentiranom odlukom o primjenjivosti za svaki relevantni pravni subjekt. Članak 2. DORA-e navodi obuhvaćene kategorije i isključenja. Poduzeće koje sebe opisuje kao FinTech, startup ili MSP nije automatski obuhvaćeno niti izuzeto.

Primjeri obuhvaćenih financijskih subjekata uključuju kreditne institucije, institucije za platni promet, investicijska društva i društva za osiguranje, podložno detaljnim pravilima o opsegu iz Uredbe. Zabilježite primjenjivu kategoriju, svako isključenje ili izuzeće, relevantno nadležno tijelo i obrazloženje svojeg zaključka.

Za dobavljače razlikujte tri položaja:

Dobavljač koji podupire ključnu ili važnu financijsku funkciju nije samo zbog toga imenovani ključni treći pružatelj IKT usluga. Financijski subjekti procjenjuju važnost svojih funkcija i ovisnosti; imenovanje ključnih pružatelja provodi se kroz okvir nadzora prema članku 31.

Lokacija ne rješava pitanje dobavljača. Pružatelj usluga u oblaku ili softvera sa sjedištem u SAD-u može se suočiti sa zahtjevima klijenata povezanima s DORA-om kada pruža usluge financijskim subjektima u EU-u. Taj ga poslovni odnos ne čini automatski podložnim svim obvezama koje se nameću financijskom subjektu.

I proporcionalnost zahtijeva obrazloženu procjenu. Članak 4. uzima u obzir čimbenike koji uključuju veličinu, ukupni profil rizičnosti te prirodu, opseg i složenost usluga. Članak 16. predviđa pojednostavnjeni okvir za upravljanje IKT rizicima za određene kategorije. To nisu međusobno zamjenjivi pojmovi, a uobičajeni status MSP-a nije univerzalni prečac. Analizu ispunjavanja uvjeta čuvajte zajedno s odlukom o opsegu.

Učinite odgovornost uprave vidljivom

Prema članku 5. DORA-e, upravljačko tijelo snosi krajnju odgovornost za upravljanje IKT rizikom financijskog subjekta. Delegiranje provedbe CISO-u, tehnološkom timu ili vanjskom pružatelju ne prenosi tu odgovornost.

Uprava bi trebala utvrditi tko predlaže odluke, tko ih odobrava i tko provjerava funkcionira li provedba. Operativni model trebao bi obuhvatiti kontinuitet poslovanja, odgovor na incidente i oporavak, ugovorne odnose s trećim stranama, proračun i znanje potrebno za smislen nadzor.

Praktična je preporuka upravi dati paket izvješća usmjeren na odluke umjesto nadzorne ploče s postotkom dovršenosti. Uključite:

• Ključne ili važne funkcije s netestiranim pretpostavkama o oporavku.
• Bitne incidente, učinke na klijente i neriješene korektivne radnje.
• Ovisnosti o dobavljačima s nepotpunim ugovorima ili slabim mogućnostima izlaska.
• Značajne nedostatke u kontrolama, odgovorne vlasnike i datume otklanjanja.
• Odluke koje zahtijevaju financiranje, promjenu dobavljača ili izričit odgovor na rizik.

Svaki nedostatak trebao bi razlikovati regulatorni zahtjev, trenutačnu operativnu slabost i predloženo rješenje. Nedostajući zapis o odobrenju razlikuje se od sigurnosne kopije koja se ne može vratiti. Oboje može zahtijevati djelovanje, ali s različitim vlasnicima i prioritetima.

Odobrenje plana otklanjanja od strane uprave nije dopuštenje za neograničeno odgađanje primjenjivih obveza. Kada je nedostatak bitan, uz dugoročno rješenje razmotrite trenutačne zaštitne mjere, eskalaciju i moguće posljedice u odnosu na nadzorno tijelo.

Izgradite program oko financijskih funkcija

Inventar imovine je nužan, ali planiranje otpornosti trebalo bi započeti od usluge koja se mora nastaviti. Utvrdite financijsku funkciju, njezina poslovnog vlasnika, posljedice poremećaja te sustave i pružatelje koji je podupiru.

Za platnu uslugu mapirajte identitete, infrastrukturu u oblaku, obradu transakcija, praćenje i eskalaciju prema dobavljačima. Uključite manje vidljive ovisnosti kao što su DNS, povezivost, privilegirani pristup, kriptografski ključevi i alati za podršku. Alternativno produkcijsko okruženje može biti neupotrebljivo ako ovisi o istoj usluzi identiteta koja je zakazala.

Mapa koja iz toga proizlazi trebala bi svaku funkciju povezati s:

• Aplikacijama, infrastrukturom, informacijskom imovinom i vanjskim uslugama koje je podupiru.
• Relevantnim ugovorima i vlasnicima usluga.
• Ciljevima oporavka i analizom učinka na poslovanje koja ih podupire.
• Rješenjima za otkrivanje, odgovor, oporavak i komunikaciju.
• Testovima, nalazima i neriješenim rizicima ovisnosti.

Mapu potvrdite s operativnim i poslovnim timovima. Zapisi o nabavi pokazuju što je kupljeno; ne pokazuju nužno kako usluga danas funkcionira.

Koristite taj model za organizaciju upravljanja IKT rizicima, upravljanja incidentima i izvješćivanja, testiranja otpornosti i rizika povezanog s trećim pružateljima IKT usluga. DORA sadrži i odredbe o dobrovoljnoj razmjeni informacija o kiberprijetnjama. Ako sudjelujete, definirajte članstvo, povjerljivost, dopuštenu uporabu i pravila postupanja umjesto da razmjenu tretirate kao neograničenu razmjenu podataka o incidentima.

Pretvorite upravljanje IKT rizicima u financirani rad

Odredbe DORA-e o upravljanju IKT rizicima obuhvaćaju utvrđivanje, zaštitu i sprječavanje, otkrivanje, odgovor i oporavak, učenje te komunikaciju. Okvir mora povezati te aktivnosti, a ne ostaviti ih kao zasebne zbirke politika.

Procjenu nedostataka započnite s mapiranim funkcijama. Pitajte štite li kontrole pristupa njihove sustave, otklanjaju li se ranjivosti, kontroliraju li se promjene, otkriva li se sumnjiva aktivnost i odražavaju li rješenja za oporavak realne kvarove. Uzmite u obzir tehničke kvarove i operativne pogreške, a ne samo zlonamjerne napade.

Za svaku bitnu slabost izradite zapis o otklanjanju koji sadrži vlasnika, učinak na poslovanje, potrebnu radnju, kriterije dovršetka i dokaze o zatvaranju. Ovisnosti su važne: poboljšanje postupaka vraćanja može zahtijevati promjene pristupa sigurnosnim kopijama, obveza dobavljača i osposobljavanja osoblja prije nego što je uspješan test uopće moguć.

Ciljevi oporavka trebali bi proizlaziti iz poslovnih potreba i analize učinka, a ne iz onoga što standardna razina usluge dobavljača slučajno nudi. Kada tehnička sposobnost ne može ispuniti cilj, uprava mora odlučiti hoće li poboljšati arhitekturu, promijeniti rješenje za uslugu ili preispitati operativni model. Cilj zapisan u planu kontinuiteta nije dokaz da je oporavak moguć.

Pripremite odluke o incidentima prije poremećaja

DORA zahtijeva od financijskih subjekata da upravljaju incidentima povezanima s IKT-om i da velike incidente prijavljuju relevantnom nadležnom tijelu. Članci 17. do 23. uspostavljaju okvir; primjenjivi regulatorni tehnički i provedbeni standardi daju detaljne kriterije klasifikacije, pragove, sadržaj izvješća i postupke.

Za detaljan raspored izvješćivanja ne oslanjajte se na generički kontrolni popis za incidente. Vodite ažurnu matricu izvješćivanja u kojoj su navedeni primjenjivi standardi, upute nadležnog tijela, kanal za podnošenje, faze izvješćivanja i izračuni rokova. Dodijelite odgovornost za njezino ažuriranje.

Postupak odgovora trebao bi omogućiti da se nekoliko odluka može provesti pod pritiskom:

• Tko bilježi vremenske oznake otkrivanja, procjene i klasifikacije?
• Tko pribavlja informacije o učinku od operacija i dobavljača?
• Tko odlučuje jesu li ispunjeni kriteriji velikog incidenta?
• Tko odobrava i podnosi izvješća, uključujući izvan uobičajenog radnog vremena?
• Tko vodi komunikaciju s klijentima i druga primjenjiva obavješćivanja?

Zabilježite obrazloženje klasifikacije čak i kada incident nije prijavljen kao velik. Nepotpuna početna slika trebala bi pokrenuti ponovnu procjenu kako se informacije razvijaju, a ne trajnu pretpostavku da je događaj manji.

Obveze dobavljača u pogledu obavješćivanja trebale bi financijskom subjektu ostaviti dovoljno vremena da procijeni i ispuni vlastite obveze. Zadaće izvješćivanja mogu se eksternalizirati kada je to dopušteno, ali odgovornost ostaje na financijskom subjektu.

Kada velik incident povezan s IKT-om utječe na financijske interese klijenata, DORA zahtijeva da financijski subjekti te klijente bez nepotrebnog odgađanja obavijeste o incidentu i mjerama poduzetima za ublažavanje njegovih štetnih učinaka. Zasebno procijenite obveze povezane s povredom osobnih podataka i druga primjenjiva pravila. Jedan poremećaj može dovesti do nekoliko odluka o obavješćivanju s različitim primateljima i pravnim kriterijima.

Testirajte pretpostavke na koje se uprava oslanja

Program testiranja digitalne operativne otpornosti trebao bi biti razmjeran i temeljen na riziku. Procjene ranjivosti, vježbe scenarija, sigurnosno testiranje i testovi oporavka odgovaraju na različita pitanja; nijedno ne bi trebalo tretirati kao univerzalnu zamjenu za ostala.

Simulacijska vježba za stolom može utvrditi razumiju li donositelji odluka eskalaciju. Ne može dokazati da se podaci o transakcijama mogu točno vratiti. Penetracijski test može otkriti iskoristive slabosti, a da ne dokaže da alternativni dobavljač može preuzeti uslugu.

Za svaki test definirajte funkciju, scenarij, opseg, kriterije uspjeha, rješenja za neovisnost kada su potrebna i očekivane dokaze. Sačuvajte rezultate, nalaze, odluke o otklanjanju i ishode ponovnog testiranja. Provjerite primjenjive zahtjeve u pogledu obuhvata i učestalosti u odnosu na DORA-u i relevantne standarde, uključujući sva izuzeća ili odredbe o pojednostavnjenom okviru.

Penetracijsko testiranje vođeno prijetnjama zaseban je nadzorni zahtjev za odabrane financijske subjekte prema članku 26. To nije opća obveza za svako financijsko poduzeće ili dobavljača IKT usluga.

Uprava bi trebala pregledati pretpostavke koje se nisu potvrdile, a ne samo jesu li testovi provedeni. Ako vježba otkrije da vraćanje ovisi o jednom nedostupnom administratoru, ishod je operativni rizik koji zahtijeva djelovanje, a ne dovršena prekretnica testiranja.

Rizik povezan s trećim stranama tretirajte kao pitanje kontinuiteta usluge

Prema DORA-i, financijski subjekt ostaje odgovoran za svoje obveze kada koristi dobavljače IKT usluga. Članci 28. do 30. povezuju procjenu rizika povezanog s trećim stranama, ugovorne odnose, praćenje i planiranje izlaska.

Vodite registar i operativnu sliku

Financijski subjekti moraju voditi registar informacija o ugovornim odnosima za IKT usluge na propisanoj pojedinačnoj, potkonsolidiranoj i konsolidiranoj razini. Za njegovu strukturu koristite primjenjive provedbene standarde. Proračunska tablica nabave ili popis odobrenih dobavljača nije automatski dovoljan.

Uskladite registar s ugovorima, vlasništvom nad uslugama i mapama ovisnosti. Održavajte propisana razlikovanja za usluge koje podupiru ključne ili važne funkcije. Novi podizvođač, lokacija pružanja usluge ili prošireni opseg mogu promijeniti sliku rizika čak i kada naziv dobavljača ostane isti.

Pregledajte ugovore u odnosu na stvarnu uslugu

Procijenite primjenjive ugovorne zahtjeve, uključujući opise usluga, lokacije, zaštitu podataka, pristup i povrat podataka, pomoć pri incidentima, suradnju, prava na raskid i razine usluge. Ugovori koji podupiru ključne ili važne funkcije zahtijevaju dodatne odredbe, uključujući relevantna rješenja za izvješćivanje, kontinuitet, pristup, inspekciju, reviziju i izlazak.

Pravni stručnjaci, nabava, tehnologija i poslovni vlasnici trebali bi ih pregledati zajedno. Ugovorno pravo na reviziju može biti teško ostvariti u praksi; obećano rješenje za oporavak možda ne obuhvaća cijeli lanac usluge klijenta. Utvrdite ta ograničenja prije prihvaćanja ugovora.

Ispitajte koncentraciju i sposobnost izlaska

Rizik koncentracije nije ograničen na kupnju više usluga od jednog društva. Različiti dobavljači mogu se oslanjati na istu platformu u oblaku, regiju, mrežu ili podizvođača. Procijenite zamjenjivost, složenost migracije i posljedice zajedničkog kvara.

Plan izlaska trebao bi obuhvatiti formate podataka, izvlačenje, pristup, ovisnosti migracije, podršku tijekom prijelaza, brisanje i kontinuitet tijekom prelaska. Za ključne ili važne funkcije testiranje i preispitivanje izlaska tretirajte kao sadržajan rad, a ne kao vježbu pisanja dokumenata.

Dobavljači mogu pripremiti dosljedan paket jamstva koji sadrži opseg usluge, granice odgovornosti, kontakte za incidente, dokaze o kontinuitetu, informacije o podugovaranju i stajališta o ugovoru. Zahtjeve specifične za pojedinog klijenta i dalje treba pregledati; certifikat ih ne zamjenjuje.

Razumijte gdje se DORA i NIS2 susreću

DORA je uredba EU-a koja se izravno primjenjuje. NIS2 je direktiva koja se provodi kroz nacionalno pravo, a njezina primjenjivost ovisi o sektoru, veličini, usluzi i pravilima o uključivanju. Rok za njezino prenošenje u nacionalno pravo bio je 17. listopada 2024.; organizacije trebaju ispitati primjenjivu nacionalnu provedbu umjesto da pretpostave jedinstven, istovjetan operativni režim.

Članak 1. stavak 2. DORA-e, zajedno s člankom 4. Direktive NIS2, uspostavlja sektorski specifičan odnos za obuhvaćene financijske subjekte u relevantnim područjima. Ne tumačite to kao uputu za udvostručavanje jednakovrijednih kontrola upravljanja rizicima i izvješćivanja o incidentima. Jednako tako, ne pretpostavljajte da to uklanja obveze za svako društvo u financijskoj grupi ili njezinu lancu opskrbe.

Pružatelj upravljanih usluga koji pruža usluge banci možda će trebati vlastitu procjenu prema NIS2, a istodobno ispunjavati ugovorne obveze povezane s DORA-om. Matrica obveza po subjektima trebala bi bilježiti pravnu osnovu, opseg, nadležno tijelo, put izvješćivanja i potrebne dokaze.

Zajedničke kontrole mogu podupirati DORA-u, ISO 27001, obveze zaštite privatnosti i jamstvo prema klijentima kada se opseg i dokazi podudaraju. Ponovno iskoristite pregled pristupa ili test oporavka kada stvarno podupire više zahtjeva, ali sačuvajte pojedinosti specifične za financijski sektor. Certifikat ISO 27001 ne dokazuje usklađenost s DORA-om.

Provedba se također razlikuje. Nadzorne ovlasti i sankcije za financijske subjekte prema DORA-i ovise o njezinim odredbama i primjenjivim nacionalnim mjerama; imenovani ključni pružatelji podliježu zasebnom režimu nadzora. Ne planirajte proračun za rizik oko navodne univerzalne novčane kazne prema DORA-i. Procijenite relevantnu pravnu izloženost i operativne posljedice nedostatne otpornosti.

Primjer iz prakse: pregled ovisnosti platne usluge

Razmotrimo ilustrativnu instituciju za platni promet koja koristi platformu u oblaku, pružatelja identiteta i eksternaliziranu uslugu praćenja. Pretpostavimo da je institucija obuhvaćena DORA-om i da je izvršavanje plaćanja klasificirano kao ključna ili važna funkcija.

Prvi pregled otkriva tri slabosti: produkcijsko okruženje i okruženje za oporavak dijele istu ovisnost o identitetu; postupak eskalacije incidenata kod dobavljača usluge praćenja je nejasan; a plan izlaska iz oblaka navodi alternativnog pružatelja, a da ne dokazuje izvlačenje i migraciju podataka.

Uprava naručuje tri povezana radna paketa:

Poslovni vlasnik provjerava ostaju li ciljevi oporavka plaćanja ostvarivi. Funkcija usklađenosti provjerava odražavaju li postupci izvješćivanja i unosi u registar stvarna rješenja. Uprava odobrava potrebno financiranje i pregledava preostala ograničenja.

Ovaj primjer sam po sebi ne dokazuje usklađenost. Pokazuje kako jedna funkcija može otkriti odluke koje bi ostale skrivene u zasebnim kontrolnim popisima za politike, dobavljače i testiranje.

Uspostavite ritam pregleda temeljen na dokazima

DORA nema univerzalni postupak certifikacije koji zamjenjuje kontinuirane obveze. Neovisno jamstvo može informirati upravu, ali spremnost se mora dokazati kroz kontrole u radu, zapise i suradnju s nadzornim tijelom kada je potrebna.

Praktičan sljedeći korak je odabrati jednu ključnu ili važnu funkciju i prikupiti njezinu odluku o opsegu, mapu ovisnosti, procjenu rizika, ugovore, postupke za incidente, rezultate testova i otvorene radnje. Provjerite pričaju li ti zapisi dosljednu priču.

Secani podupire taj tijek rada modeliranjem sustava i usluga, povezivanjem ovisnosti te čuvanjem zahtjeva, dokaza, vlasnika, zadataka i odluka o pregledu u kontekstu. Učitajte postojeći materijal uz relevantne objekte, pretvorite nedostatke u dodijeljeni rad i zadržite izričito ljudsko odobrenje za prijedloge i zaključke uz pomoć umjetne inteligencije.

Od te prve funkcije proširujte opseg kada vlasništvo i putovi dokaza postanu jasni. Uprava bi trebala moći vidjeti što je dokazano, što ostaje nesigurno i koja je odluka sljedeća potrebna.