Pripravljenost na DORA za finančne subjekte in njihove dobavitelje IKT

Uredba o digitalni operativni odpornosti za finančni sektor (DORA) se uporablja od 17. januarja 2025. Za finančne subjekte pripravljenost zdaj pomeni vzdrževanje operativnega modela za digitalno operativno odpornost, ne priprave na prihodnji rok. Za ponudnike tehnologije pomeni razumevanje odgovornosti do strank in tega, ali zanje velja ločen režim neposrednega nadzora.

Vprašanje za vodstvo je praktično: ali zna organizacija pojasniti, katere finančne storitve so odvisne od katerih sistemov IKT, kako bodo obravnavane motnje in kateri dokazi podpirajo njene predpostavke o obnovitvi? Politike so pomembne, vendar same na to vprašanje ne morejo odgovoriti. Vodstvo potrebuje povezan pogled na odgovornosti, odvisnosti, pogodbe, teste, incidente in nerazrešena tveganja.

Svojo vlogo določite, preden sestavite kontrolni seznam

Začnite z dokumentirano odločitvijo o uporabi za vsako zadevno pravno osebo. 2. člen DORA določa zajete kategorije in izjeme. Podjetje, ki se opisuje kot FinTech, zagonsko podjetje ali MSP, ni samodejno v obsegu ali izvzeto.

Primeri zajetih finančnih subjektov so kreditne institucije, plačilne institucije, investicijska podjetja in zavarovalnice, ob upoštevanju podrobnih pravil o obsegu iz uredbe. Zabeležite veljavno kategorijo, morebitno izključitev ali izjemo, pristojni organ in utemeljitev svojega sklepa.

Pri dobaviteljih razlikujte tri položaje:

Dobavitelj, ki podpira ključno ali pomembno finančno funkcijo, zgolj zaradi tega ni imenovani ključni tretji ponudnik storitev IKT. Finančni subjekti ocenjujejo pomembnost svojih funkcij in odvisnosti; imenovanje ključnih ponudnikov poteka prek nadzornega okvira po 31. členu.

Lokacija vprašanja dobavitelja ne razreši. Ponudnik storitev v oblaku ali programske opreme s sedežem v ZDA se lahko sooči z zahtevami strank, povezanimi z DORA, kadar služi finančnim subjektom v EU. To poslovno razmerje zanj ne pomeni samodejno vseh obveznosti, ki veljajo za finančni subjekt.

Tudi sorazmernost zahteva utemeljeno oceno. 4. člen upošteva dejavnike, kot so velikost, celoten profil tveganja ter narava, obseg in zapletenost storitev. 16. člen za določene kategorije predvideva poenostavljen okvir za obvladovanje tveganj IKT. To nista zamenljiva koncepta in običajen status MSP ni splošna bližnjica. Analizo upravičenosti hranite skupaj z odločitvijo o obsegu.

Odgovornost vodstva naj bo vidna

Po 5. členu DORA ima upravljalni organ končno odgovornost za obvladovanje tveganj IKT finančnega subjekta. Prenos izvedbe na CISO, tehnološko ekipo ali zunanjega ponudnika te odgovornosti ne prenese.

Vodstvo naj ugotovi, kdo predlaga odločitve, kdo jih odobri in kdo preverja, ali izvedba deluje. Operativni model naj zajema neprekinjeno poslovanje, odzivanje na incidente in obnovitev, ureditve s tretjimi osebami, proračun in znanje, potrebno za smiseln nadzor.

Praktično priporočilo je, da vodstvo prejme paket poročil, osredotočen na odločitve, namesto nadzorne plošče z odstotkom dokončanosti. Vključite:

• Ključne ali pomembne funkcije z nepreizkušenimi predpostavkami o obnovitvi.
• Večje incidente, učinke na stranke in odprte popravne ukrepe.
• Odvisnosti od dobaviteljev z nepopolnimi pogodbami ali šibkimi možnostmi izstopa.
• Pomembne vrzeli v kontrolah, odgovorne lastnike in datume odprave.
• Odločitve, ki zahtevajo financiranje, menjavo dobavitelja ali izrecen odziv na tveganje.

Pri vsaki vrzeli naj bo razvidno, kaj je regulativna zahteva, kaj je trenutna operativna slabost in kaj je predlagana rešitev. Manjkajoč zapis o odobritvi je nekaj drugega kot varnostna kopija, ki je ni mogoče obnoviti. Oba lahko zahtevata ukrepanje, vendar potrebujeta različne lastnike in prednostne naloge.

Odobritev načrta odprave s strani vodstva ni dovoljenje za neomejeno odlaganje veljavnih obveznosti. Kadar je vrzel bistvena, poleg dolgoročne rešitve preučite takojšnje zaščitne ukrepe, eskalacijo in morebitne posledice za nadzor.

Program zgradite okoli finančnih funkcij

Popis sredstev je potreben, vendar naj se načrtovanje odpornosti začne s storitvijo, ki mora delovati naprej. Opredelite finančno funkcijo, njenega poslovnega lastnika, posledice motenj ter sisteme in ponudnike, ki jo podpirajo.

Pri plačilni storitvi popišite identitete, infrastrukturo v oblaku, obdelavo transakcij, spremljanje in eskalacijo pri dobaviteljih. Vključite manj vidne odvisnosti, kot so DNS, povezljivost, privilegirani dostop, šifrirni ključi in orodja za podporo. Nadomestno produkcijsko okolje je lahko neuporabno, če je odvisno od iste storitve identitet, ki je odpovedala.

Nastali zemljevid naj vsako funkcijo poveže z:

• Podpornimi aplikacijami, infrastrukturo, informacijskimi sredstvi in zunanjimi storitvami.
• Ustreznimi pogodbami in lastniki storitev.
• Cilji obnovitve in analizo poslovnega vpliva, ki jih podpira.
• Ureditvami za zaznavanje, odziv, obnovitev in komunikacijo.
• Testi, ugotovitvami in nerazrešenimi tveganji odvisnosti.

Zemljevid preverite z operativnimi in poslovnimi ekipami. Nabavni zapisi kažejo, kaj je bilo kupljeno; ne kažejo nujno, kako storitev deluje danes.

Ta model uporabite za organizacijo obvladovanja tveganj IKT, upravljanja incidentov in poročanja o njih, testiranja odpornosti ter tveganj tretjih oseb na področju IKT. DORA vsebuje tudi določbe o prostovoljni izmenjavi informacij o kibernetskih grožnjah. Če sodelujete, opredelite članstvo, zaupnost, dovoljeno uporabo in pravila ravnanja, namesto da izmenjavo obravnavate kot neomejeno izmenjavo podatkov o incidentih.

Obvladovanje tveganj IKT spremenite v financirano delo

Določbe DORA o obvladovanju tveganj IKT zajemajo prepoznavanje, zaščito in preprečevanje, zaznavanje, odziv in obnovitev, učenje ter komunikacijo. Okvir mora te dejavnosti povezati, namesto da jih pusti kot ločene zbirke politik.

Analizo vrzeli začnite s popisanimi funkcijami. Vprašajte se, ali kontrole dostopa ščitijo njihove sisteme, ali se ranljivosti odpravljajo, ali so spremembe nadzorovane, ali se zaznava sumljiva dejavnost in ali ureditve za obnovitev odražajo realistične odpovedi. Poleg zlonamernih napadov upoštevajte tudi tehnične napake in operativne zmote.

Za vsako bistveno slabost ustvarite zapis o odpravi, ki vsebuje lastnika, poslovni vpliv, zahtevani ukrep, merila za dokončanje in dokaze o zaključku. Odvisnosti so pomembne: izboljšanje postopkov obnovitve lahko zahteva spremembe dostopa do varnostnih kopij, zavez dobaviteljev in usposabljanja osebja, preden je uspešen test sploh mogoč.

Cilji obnovitve naj izhajajo iz poslovnih potreb in analize vpliva, ne iz tega, kar slučajno ponuja standardna raven storitve ponudnika. Kadar tehnična zmogljivost ne more doseči cilja, mora vodstvo odločiti, ali bo izboljšalo arhitekturo, spremenilo ureditev storitve ali ponovno preučilo operativni model. Cilj, zapisan v načrtu neprekinjenega poslovanja, ni dokaz o zmožnosti obnovitve.

Odločitve ob incidentih pripravite pred motnjo

DORA od finančnih subjektov zahteva, da upravljajo incidente, povezane z IKT, in o večjih incidentih poročajo pristojnemu organu. Členi 17–23 vzpostavljajo okvir; veljavni regulativni tehnični in izvedbeni standardi določajo podrobna merila za razvrščanje, pragove, vsebino poročil in postopke.

Za podroben časovni načrt poročanja se ne zanašajte na splošen kontrolni seznam za incidente. Vzdržujte aktualno matriko poročanja, ki navaja veljavne standarde, navodila organa, kanal za oddajo, faze poročanja in izračune rokov. Dodelite odgovornost za njeno posodabljanje.

Postopek odziva naj omogoči izvedbo več odločitev pod pritiskom:

• Kdo beleži časovne žige zaznave, ocene in razvrstitve?
• Kdo pridobi informacije o vplivu od operacij in dobaviteljev?
• Kdo odloči, ali so izpolnjena merila za večji incident?
• Kdo odobri in odda poročila, tudi zunaj običajnega delovnega časa?
• Kdo skrbi za komunikacijo s strankami in druga veljavna obvestila?

Utemeljitev razvrstitve zabeležite tudi takrat, ko incident ni prijavljen kot večji. Nepopolna začetna slika naj sproži ponovno oceno, ko se informacije razvijajo, ne pa trajne predpostavke, da je dogodek manjši.

Zaveze dobaviteljev glede obveščanja naj finančnemu subjektu pustijo dovolj časa, da oceni in izpolni lastne obveznosti. Naloge poročanja je mogoče zunanje izvajati, kjer je to dovoljeno, vendar odgovornost ostane pri finančnem subjektu.

Kadar večji incident, povezan z IKT, vpliva na finančne interese strank, DORA od finančnih subjektov zahteva, da te stranke brez nepotrebnega odlašanja obvestijo o incidentu in ukrepih, sprejetih za ublažitev njegovih škodljivih učinkov. Ločeno ocenite obveznosti glede kršitev varstva osebnih podatkov in druga veljavna pravila. Ena motnja lahko povzroči več odločitev o obveščanju z različnimi prejemniki in pravnimi testi.

Preizkusite predpostavke, na katere se zanaša vodstvo

Program testiranja digitalne operativne odpornosti naj bo sorazmeren in temelji na tveganju. Ocene ranljivosti, scenarijske vaje, varnostno testiranje in testi obnovitve odgovarjajo na različna vprašanja; nobenega ne bi smeli obravnavati kot splošnega nadomestka za druge.

Namizna vaja lahko pokaže, ali odločevalci razumejo eskalacijo. Ne more pa dokazati, da je mogoče podatke o transakcijah točno obnoviti. Penetracijski test lahko razkrije izkoristljive slabosti, ne da bi dokazal, da lahko nadomestni dobavitelj prevzame storitev.

Za vsak test opredelite funkcijo, scenarij, obseg, merila uspeha, ureditve neodvisnosti, kjer so zahtevane, in pričakovane dokaze. Ohranite rezultate, ugotovitve, odločitve o odpravi in izide ponovnih testov. Veljavne zahteve glede pokritosti in pogostosti preverite glede na DORA in ustrezne standarde, vključno z morebitnimi izjemami ali določbami o poenostavljenem okviru.

Penetracijsko testiranje na podlagi groženj (TLPT) je ločena nadzorna zahteva za izbrane finančne subjekte po 26. členu. Ni splošna obveznost za vsako finančno podjetje ali dobavitelja IKT.

Vodstvo naj pregleda neuspele predpostavke, ne le, ali so testi potekali. Če vaja razkrije, da je obnovitev odvisna od enega nedosegljivega skrbnika, je izid operativno tveganje, ki zahteva ukrepanje, ne opravljen mejnik testiranja.

Tveganja tretjih oseb obravnavajte kot vprašanje neprekinjenosti storitev

Po DORA finančni subjekt ostaja odgovoren za svoje obveznosti, ko uporablja dobavitelje IKT. Členi 28–30 povezujejo oceno tveganj tretjih oseb, pogodbene ureditve, spremljanje in načrtovanje izstopa.

Vzdržujte register in operativno sliko

Finančni subjekti morajo voditi register informacij o pogodbenih ureditvah na področju IKT na zahtevani posamični, subkonsolidirani in konsolidirani ravni. Za njegovo strukturo uporabite veljavne izvedbene standarde. Nabavna preglednica ali seznam odobrenih dobaviteljev ne zadošča samodejno.

Register uskladite s pogodbami, lastništvom storitev in zemljevidi odvisnosti. Ohranite zahtevana razlikovanja za storitve, ki podpirajo ključne ali pomembne funkcije. Nov podizvajalec, lokacija storitve ali razširjen obseg lahko spremeni sliko tveganja, tudi če ime dobavitelja ostane enako.

Pogodbe preglejte glede na dejansko storitev

Ocenite veljavne pogodbene zahteve, vključno z opisi storitev, lokacijami, varstvom podatkov, dostopom do podatkov in njihovo obnovitvijo, pomočjo ob incidentih, sodelovanjem, pravicami do odpovedi in ravnmi storitev. Ureditve, ki podpirajo ključne ali pomembne funkcije, zahtevajo dodatne določbe, vključno z ustreznimi ureditvami za poročanje, neprekinjenost, dostop, pregled, revizijo in izstop.

Pravni, nabavni, tehnološki in poslovni lastniki naj jih pregledajo skupaj. Pogodbeno pravico do revizije je lahko v praksi težko uveljaviti; obljubljena ureditev obnovitve morda ne zajema celotne verige storitev stranke. Te omejitve prepoznajte, preden sprejmete ureditev.

Preučite koncentracijo in zmožnost izstopa

Tveganje koncentracije ni omejeno na nakup več storitev od enega podjetja. Različni dobavitelji se lahko zanašajo na isto platformo v oblaku, regijo, omrežje ali podizvajalca. Ocenite zamenljivost, zapletenost migracije in posledice skupne odpovedi.

Načrt izstopa naj obravnava formate podatkov, izvlečenje, dostop, odvisnosti migracije, podporo pri prehodu, izbris in neprekinjenost med selitvijo. Pri ključnih ali pomembnih funkcijah obravnavajte testiranje in pregled izstopa kot vsebinsko delo, ne kot vajo pisanja dokumentov.

Dobavitelji lahko pripravijo enoten paket zagotovil, ki vsebuje obseg storitve, meje odgovornosti, kontakte za incidente, dokaze o neprekinjenosti, informacije o podizvajanju in pogodbena stališča. Zahteve, specifične za stranko, je treba še vedno pregledati; certifikat jih ne nadomesti.

Razumite, kje se srečata DORA in NIS2

DORA je uredba EU z neposredno uporabo. Direktiva NIS 2 je direktiva, ki se izvaja prek nacionalnega prava, njena uporaba pa je odvisna od sektorja, velikosti, storitve in pravil o vključitvi. Rok za prenos v nacionalno pravo je bil 17. oktober 2024; organizacije morajo preučiti veljavno nacionalno izvedbo, namesto da domnevajo en sam enak operativni režim.

Člen 1(2) DORA skupaj s 4. členom NIS2 vzpostavlja sektorsko specifično razmerje za zajete finančne subjekte na zadevnih področjih. Tega ne razlagajte kot navodila za podvajanje enakovrednih kontrol za obvladovanje tveganj in poročanje o incidentih. Prav tako ne domnevajte, da odpravlja obveznosti vsakega podjetja v finančni skupini ali njeni dobavni verigi.

Ponudnik upravljanih storitev, ki služi banki, bo morda potreboval lastno oceno po NIS2, hkrati pa bo izpolnjeval pogodbene zaveze, povezane z DORA. Matrika obveznosti za vsak subjekt posebej naj beleži pravno podlago, obseg, organ, pot poročanja in zahtevane dokaze.

Skupne kontrole lahko podpirajo DORA, ISO 27001, obveznosti glede zasebnosti in zagotovila za stranke, kadar se obseg in dokazi ujemajo. Pregled dostopov ali test obnovitve ponovno uporabite, kadar resnično podpira več zahtev, pri tem pa ohranite podrobnosti, specifične za finančni sektor. Certifikat ISO 27001 ne dokazuje skladnosti z DORA.

Razlikuje se tudi izvrševanje. Nadzorna pooblastila in kazni za finančne subjekte po DORA so odvisni od njenih določb in veljavnih nacionalnih ukrepov; za imenovane ključne ponudnike velja ločen režim nadzora. Tveganja ne načrtujte v proračunu okoli domnevne splošne globe po DORA. Ocenite zadevno pravno izpostavljenost in operativne posledice nezadostne odpornosti.

Praktični primer: pregled odvisnosti plačilne storitve

Vzemimo ponazoritveno plačilno institucijo, ki uporablja platformo v oblaku, ponudnika identitet in zunanjo storitev spremljanja. Predpostavimo, da je institucija v obsegu DORA in da je izvrševanje plačil razvrščeno kot ključna ali pomembna funkcija.

Prvi pregled ugotovi tri slabosti: produkcijsko in obnovitveno okolje si delita isto odvisnost od identitet; postopek eskalacije incidentov pri dobavitelju spremljanja je nejasen; načrt izstopa iz oblaka navaja nadomestnega ponudnika, ne da bi dokazal izvlečenje podatkov in migracijo.

Vodstvo naroči tri povezane delovne svežnje:

Poslovni lastnik preveri, ali so cilji obnovitve plačil še dosegljivi. Funkcija skladnosti preveri, ali postopki poročanja in vnosi v register odražajo ureditve. Vodstvo odobri potrebno financiranje in pregleda preostale omejitve.

Ta primer sam po sebi ne dokazuje skladnosti. Kaže, kako lahko ena funkcija razkrije odločitve, ki bi v ločenih kontrolnih seznamih za politike, dobavitelje in testiranje ostale skrite.

Vzpostavite ritem pregledov, ki temelji na dokazih

DORA nima splošnega postopka certificiranja, ki bi nadomestil stalne obveznosti. Neodvisna zagotovila lahko informirajo vodstvo, vendar je treba pripravljenost dokazati z delujočimi kontrolami, zapisi in, kjer je zahtevano, sodelovanjem z nadzorniki.

Praktičen naslednji korak je, da izberete eno ključno ali pomembno funkcijo in zberete njeno odločitev o obsegu, zemljevid odvisnosti, oceno tveganja, pogodbe, postopke za incidente, rezultate testov in odprte ukrepe. Preverite, ali ti zapisi povedo dosledno zgodbo.

Secani podpira ta delovni tok z modeliranjem sistemov in storitev, povezovanjem odvisnosti ter ohranjanjem zahtev, dokazov, lastnikov, nalog in odločitev o pregledih v kontekstu. Obstoječe gradivo naložite k ustreznim objektom, vrzeli spremenite v dodeljeno delo in ohranite izrecno človeško odobritev predlogov in sklepov s pomočjo umetne inteligence.

Ko sta lastništvo in pot dokazov jasna, razširite obseg s te prve funkcije. Vodstvo naj vidi, kaj je bilo dokazano, kaj ostaja negotovo in katera odločitev je potrebna naslednja.