Plan DORA 2026 za IKT rizike, dobavljače i TLPT

Panika oko pretraživanja DORA 2026 zapravo nije pitanje regulative, nego dokaza

Ponedjeljak je, 08:15, a CISO srednje velike platne institucije ima otvorene tri kartice preglednika: „DORA RTS/ITS kontrolni popis”, „DORA IKT predložak registra trećih strana” i „TLPT zahtjevi za financijske subjekte”.

Rukovoditelj usklađenosti već je pitao treba li paket za odbor uključivati najnoviji tijek klasifikacije incidenata. Nabava želi uvesti novu platformu za analitiku u oblaku. COO traži potvrdu da ključni SaaS pružatelj bankarskih usluga nema skrivenu izloženost podugovarateljima izvan EU-a. Interna revizija traži kalendar testiranja. Pravni poslovi pitaju jesu li rokovi za prijavu povrede prema GDPR usklađeni s prijavljivanjem incidenata prema DORA.

Nitko ne postavlja teorijsko pitanje. Pitanje glasi: „Možemo li to dokazati do petka?”

To je stvarni problem DORA 2026. Većina financijskih subjekata razumije glavne obveze: upravljanje IKT rizicima, prijavljivanje incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti, upravljanje IKT rizicima trećih strana i snažniji nadzor nad kritičnim pružateljima IKT usluga. Teži je dio pretvoriti regulatorne tehničke standarde, provedbene tehničke standarde i obveze na razini članaka u kontroliranu, ponovljivu i revizijski provjerljivu praksu.

Digital Operational Resilience Act zahtijeva od financijskih subjekata održavanje snažnih sposobnosti upravljanja IKT rizicima, politika za upravljanje incidentima povezanima s IKT-om i njihovo prijavljivanje, testiranje IKT sustava, kontrola i procesa te strukturirani nadzor nad pružateljima IKT usluga trećih strana. Očekuje se i proporcionalnost. Manje investicijsko društvo i velika bankarska grupa ne moraju imati istovjetne modele dokazivanja, ali oba subjekta moraju dokazati da je njihov pristup primjeren njihovoj veličini, profilu rizika, složenosti i kritičnim funkcijama.

Projekti DORA najčešće ne uspiju iz jednog od tri razloga. Prvo, organizacija tretira DORA kao pravno mapiranje, a ne kao operativni model. Drugo, rizik dobavljača dokumentira se kao popis dobavljača, umjesto kao ovisnost, mogućnost zamjene i rizik koncentracije. Treće, testiranje se tretira kao godišnje penetracijsko testiranje, a ne kao program otpornosti koji uključuje skeniranja ranjivosti, testiranje scenarija, vježbe incidenata i, gdje je primjenjivo, penetracijsko testiranje vođeno prijetnjama, koje se često pretražuje kao TLPT.

Bolji je pristup izgraditi jedinstven sustav dokaza koji povezuje politike, registre, vlasnike, rizike, incidente, dobavljače, testiranje, oporavak i preispitivanje od strane uprave. Tu Clarysecov Zenith Blueprint, politike spremne za uporabu i Zenith Controls pomažu financijskim subjektima pretvoriti DORA iz roka u operativni ritam.

Počnite s operativnim modelom DORA, a ne s RTS/ITS tablicom

Mnogi timovi počinju tablicom koja navodi članke DORA i RTS/ITS zahtjeve. To je korisno, ali nije dovoljno. Tablica može pokazati što mora postojati. Ona ne dodjeljuje vlasnike, ne definira učestalost pregleda, ne čuva dokaze i ne dokazuje da kontrola stvarno funkcionira.

U Zenith Blueprint: revizorov plan u 30 koraka, Clarysec to obrađuje u fazi Upravljanje rizicima, korak 14, Politike obrade rizika i regulatorne unakrsne reference:

„DORA: Za društva u financijskom sektoru DORA zahtijeva okvir za upravljanje IKT rizicima koji je vrlo usklađen s onim što smo učinili: identificirati rizike, uspostaviti kontrole (i politike) te testirati ih. DORA također naglašava odgovor na incidente i prijavljivanje, kao i nadzor nad pružateljima IKT usluga trećih strana.”

Praktična je poruka jednostavna: nemojte graditi „usklađenost s DORA” kao paralelnu birokraciju. Izgradite sloj upravljanja IKT-om temeljen na riziku koji mapira zahtjeve DORA na politike, registre, vlasnike kontrola, zapise testiranja, dokaze dobavljača i preispitivanje od strane uprave.

Praktičan operativni model DORA trebao bi imati pet stupova dokaza:

Za regulirane financijske subjekte ova struktura pretvara RTS/ITS provedbu u sustav dokaza spreman za reviziju. Za subjekte pod pojednostavljenim upravljanjem IKT rizicima isti se model može prilagoditi na manji broj dokumenata i jednostavnije registre. Temeljne discipline ostaju iste: identificirati, zaštititi, otkriti, odgovoriti, oporaviti, testirati i upravljati dobavljačima.

Upravljanje IKT rizicima: registar je kontrolna soba

Očekivanja DORA za upravljanje IKT rizicima zahtijevaju da financijski subjekti identificiraju, klasificiraju i upravljaju IKT rizicima kroz sustave, podatke, procese, kritične ili važne funkcije i ovisnosti o trećim stranama.

Uobičajeni problem nije nepostojanje registra rizika. Problem je u tome što registar nije povezan s dobavljačima, imovinom, incidentima i testovima. DORA ne nagrađuje lijepu tablicu ako ona ne može objasniti zašto dobavljač visokog rizika nema plan izlaska ili zašto kritična platforma za plaćanja klijenata nije testirana.

Clarysecova SME Politika upravljanja rizicima manjim financijskim subjektima daje sažetu polaznu osnovu dokaza:

„Svaki zapis rizika mora uključivati: opis, vjerojatnost, utjecaj, ocjenu, vlasnika i plan obrade rizika.”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.1.2.

Za veće financijske subjekte Clarysecova Enterprise Politika upravljanja rizicima zahtijeva formalniji proces:

„Formalni proces upravljanja rizicima mora se održavati u skladu s ISO/IEC 27005 i ISO 31000, obuhvaćajući identifikaciju rizika, analizu, vrednovanje, obradu, praćenje i komunikaciju.”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.1.

Ta je razlika važna. DORA je proporcionalna, ali proporcionalnost ne znači neformalnost. Malo platno društvo može koristiti pojednostavljeni registar, dok bankarska grupa može koristiti integrirane GRC alate. U oba slučaja revizor će i dalje pitati: Koji su vaši IKT rizici? Tko je za njih odgovoran? Koji je plan obrade rizika? Koji dokazi pokazuju napredak? Kako dobavljači i kritične funkcije utječu na ocjenu?

Snažan DORA registar IKT rizika trebao bi uključivati ova polja:

Praktična je vježba uzeti jednu kritičnu IKT uslugu, primjerice platformu za praćenje transakcija hostiranu u oblaku, i u 20 minuta izraditi zapis rizika. Opišite scenarij otkaza ili kompromitacije, ocijenite vjerojatnost i utjecaj, dodijelite vlasnika, identificirajte povezane dobavljače, definirajte plan obrade rizika i povežite zapis s dokazima kao što su dubinska analiza dobavljača, SLA, odredbe o incidentima, BIA, rezultati DR testiranja, nadzorne ploče i pregledi pristupa.

Taj jedan zapis postaje nit koja povezuje DORA upravljanje IKT rizicima, nadzor nad trećim stranama, otkrivanje incidenata, neprekidnost poslovanja i testiranje. Tako registar rizika postaje kontrolna soba, a ne arhiva dokumenata.

RTS/ITS spremnost: mapirajte obveze na politike, a ne na obećanja

Praktičan pojam za pretraživanje „DORA RTS/ITS kontrolni popis” obično znači „Koje će dokumente nadzorna tijela očekivati?” Financijski subjekti trebaju izbjegavati dokazivanje usklađenosti generičkim izjavama. Potrebno im je mapiranje koje svaku obvezu povezuje s politikom, kontrolom, vlasnikom i dokaznim elementom.

Clarysecova SME Politika pravne i regulatorne usklađenosti uspostavlja jednostavnu upravljačku osnovu:

„Glavni direktor mora održavati jednostavan, strukturiran Registar usklađenosti koji navodi:”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.1.1.

Za DORA 2026 vaš registar usklađenosti trebao bi uključivati:

• Obvezu DORA ili područje RTS/ITS zahtjeva.
• Primjenjivost, uključujući obrazloženje proporcionalnosti.
• Referencu na politiku ili postupak.
• Vlasnika kontrole.
• Lokaciju dokaza.
• Učestalost pregleda.
• Otvorene praznine i rok za korektivne radnje.
• Status izvješćivanja odboru ili upravi.

To je usklađeno s pristupom Zenith Blueprint korak 14: mapirati regulatorne zahtjeve na ISMS kontrole i politike kako ništa ne bi ispalo iz procesa. Umjesto pitanja „Jesmo li usklađeni s DORA?”, vodstvo može pitati: „Koji dokazni elementi DORA kasne, kojim kritičnim dobavljačima nedostaju planovi izlaska i koje aktivnosti testiranja još nisu proizvele dokaze o korektivnim radnjama?”

IKT rizik trećih strana: koncentracija, mogućnost zamjene i podugovaratelji

DORA je promijenila razgovor o dobavljačima u financijskim uslugama. Više nije dovoljno pitati ima li pružatelj usluge sigurnosnu certifikaciju, osiguranje ili ugovor o obradi podataka. Financijski subjekti moraju procijeniti stvara li pružatelj rizik koncentracije, može li se pružatelj realno zamijeniti, ovisi li više kritičnih usluga o jednom dobavljaču ili povezanim dobavljačima te uvodi li podugovaranje dodatnu pravnu izloženost ili izloženost otpornosti.

To je pitanje zbog kojeg mnogi CISO-i ne spavaju. Društvo se može oslanjati na jednog velikog pružatelja usluga u oblaku za obradu transakcija, analitiku podataka, portale za klijente i internu suradnju. Ako taj pružatelj pretrpi dugotrajan prekid, regulatorni spor ili neuspjeh podugovaratelja, pitanje nije samo „Imamo li ugovor?” Pitanje je: „Možemo li nastaviti pružati kritične usluge, komunicirati s klijentima i dokazati da smo razumjeli ovisnost prije nego što je zakazala?”

Clarysecova SME Politika sigurnosti trećih strana i dobavljača postavlja temelj:

„Registar dobavljača mora održavati i ažurirati administrativni ili nabavni kontakt. Mora uključivati:”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.4.

Za programe na razini poduzeća Clarysecova Politika upravljanja rizikom ovisnosti o dobavljačima ide dublje u ovisnost i mogućnost zamjene specifične za DORA:

„Registar ovisnosti o dobavljačima: Ured za upravljanje dobavljačima (VMO) mora održavati ažuran registar svih kritičnih dobavljača, uključujući pojedinosti kao što su pružene usluge/proizvodi; je li dobavljač jedini izvor; dostupni alternativni dobavljači ili mogućnost zamjene; važeći ugovorni uvjeti; i procjena utjecaja ako bi dobavljač zakazao ili bio kompromitiran. Registar mora jasno identificirati dobavljače s visokom razinom ovisnosti (npr. one za koje ne postoji brza alternativa).”
Iz odjeljka „Zahtjevi provedbe”, točka politike 6.1.

To je dokaz o dobavljačima koji DORA projekti često propuštaju. Registar dobavljača govori tko je dobavljač. Registar ovisnosti govori što se događa kada dobavljač zakaže.

Zenith Blueprint, faza Kontrole u praksi, korak 23, Organizacijske kontrole, daje praktičan tijek rada za nadzor nad dobavljačima. Preporučuje sastavljanje potpunog popisa dobavljača, klasifikaciju dobavljača na temelju pristupa sustavima, podacima ili operativnoj kontroli, provjeru jesu li sigurnosna očekivanja ugrađena u ugovore, upravljanje rizikom podugovaratelja i nizvodnim rizikom, definiranje postupaka promjena i praćenja te izradu procesa procjene usluga u oblaku.

U Zenith Controls: vodič za unakrsnu usklađenost, kontrola ISO/IEC 27002:2022 5.21, Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, mapirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost. Povezana je sa sigurnošću odnosa s dobavljačima i konceptom kibernetičke sigurnosti Identify. Povezuje se sa sigurnim inženjeringom, sigurnim kodiranjem, kontrolom pristupa, sigurnosnim testiranjem, prikupljanjem dokaza, sigurnim životnim ciklusom razvoja i razvojem povjerenim vanjskim izvođačima.

To je upravo stvarnost DORA nadzora nad trećim stranama. Rizik dobavljača nije samo nabava. On obuhvaća arhitekturu, razvoj, odgovor na incidente, kontrolu pristupa, neprekidnost poslovanja i pravne poslove.

Iz perspektive unakrsne usklađenosti, Zenith Controls mapira sigurnost IKT opskrbnog lanca na GDPR Articles 28 i 32 jer se izvršitelji obrade i podizvršitelji obrade moraju odabirati i nadzirati uz odgovarajuće tehničke i organizacijske mjere. Podržava očekivanja NIS2 u pogledu sigurnosti opskrbnog lanca, uključujući Article 21 mjere upravljanja rizicima kibernetičke sigurnosti i Article 22 koordinirane procjene rizika opskrbnog lanca. Snažno se mapira na DORA Articles 28, 29 i 30, gdje su IKT rizik trećih strana, rizik koncentracije, daljnje podugovaranje i ugovorne odredbe središnje teme.

Potporni standardi jačaju dokaze. ISO/IEC 27036-3:2021 podržava IKT nabavu i sigurnost odabira dobavljača. ISO/IEC 20243:2018 podržava cjelovitost pouzdanih tehnoloških proizvoda i sigurnost opskrbnog lanca. ISO/IEC 27001:2022 povezuje to s obradom rizika i kontrolama dobavljača iz Annex A.

Prijavljivanje incidenata: izgradite lanac eskalacije prije incidenta

Prijavljivanje incidenata prema DORA nije samo podnošenje obavijesti. Riječ je o otkrivanju, klasifikaciji, eskalaciji, komunikaciji i učenju iz incidenata povezanih s IKT-om. Financijski subjekti moraju održavati procese za upravljanje IKT incidentima i njihovo prijavljivanje, s definiranim ulogama, kriterijima klasifikacije, rutama obavješćivanja i analizom nakon incidenta.

Clarysecova SME Politika odgovora na incidente povezuje rokove odgovora na incidente s pravnim zahtjevima:

„Rokovi odgovora, uključujući obveze oporavka podataka i obavješćivanja, moraju biti dokumentirani i usklađeni s pravnim zahtjevima, kao što je zahtjev GDPR za prijavu povrede osobnih podataka u roku od 72 sata.”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.3.2.

Za okruženja na razini poduzeća Clarysecova Politika odgovora na incidente dodaje perspektivu eskalacije reguliranih podataka:

„Ako incident rezultira potvrđenom ili vjerojatnom izloženošću osobnih podataka ili drugih reguliranih podataka, pravni poslovi i DPO moraju procijeniti primjenjivost:”
Iz odjeljka „Zahtjevi provedbe politike”, točka politike 6.4.1.

Citat završava na okidaču, što je upravo mjesto na kojem mnogi procesi za incidente zakažu. Ako okidač nije jasan, timovi raspravljaju o obvezama obavješćivanja dok rok već teče.

Zenith Blueprint, faza Kontrole u praksi, korak 16, Kontrole osoblja II, naglašava prijavljivanje incidenata koje pokreće osoblje. Zaposlenici, izvođači i dionici trebaju znati prepoznati i prijaviti potencijalne sigurnosne incidente jednostavnim kanalima, kao što su namjenski poštanski sandučić, portal ili telefonska linija. Blueprint to povezuje s GDPR Article 33, NIS2 Article 23 i DORA Article 17 jer regulatorno izvješćivanje počinje internom sviješću i eskalacijom.

U Zenith Controls, kontrola ISO/IEC 27002:2022 5.24, Planiranje i priprema upravljanja incidentima informacijske sigurnosti, mapirana je kao korektivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost, usklađena s Respond i Recover. Izravno je povezana s procjenom događaja, učenjem iz incidenata, zapisivanjem događaja i praćenjem, sigurnošću tijekom prekida, kontinuitetom informacijske sigurnosti i kontaktom s nadležnim tijelima. Vodič to mapira na DORA Articles 17 to 23 za upravljanje incidentima povezanima s IKT-om, klasifikaciju, prijavljivanje i dobrovoljno obavješćivanje o kibernetičkim prijetnjama, GDPR Articles 33 and 34 za prijavu povrede i NIS2 Article 23 za obavješćivanje o incidentima.

Proces incidenata spreman za DORA trebao bi uključivati:

• Jasne kanale zaprimanja incidenata.
• Trijažu događaja i kriterije klasifikacije.
• Tijek eskalacije velikog incidenta povezanog s IKT-om.
• Točke odlučivanja za pravne poslove, DPO i regulatorno obavješćivanje.
• Okidače obavješćivanja o incidentima dobavljača.
• Zahtjeve za očuvanje dokaza.
• Pravila komunikacije s izvršnim rukovodstvom i odborom.
• Pregled nakon incidenta i naučene lekcije.
• Povezivanje s ažuriranjem registra rizika i korektivnim radnjama na kontrolama.

Potporni standardi dodaju strukturu. ISO/IEC 27035-1:2023 pruža načela planiranja i pripreme za upravljanje incidentima. ISO/IEC 27035-2:2023 razrađuje korake postupanja s incidentima. ISO/IEC 22320:2018 podržava zapovijedanje, kontrolu i strukturiranu kriznu komunikaciju. To je važno kada IKT prekid postane kriza s utjecajem na klijente, a subjekt mora pokazati da su odluke bile pravodobne, koordinirane i utemeljene na dokazima.

Testiranje digitalne operativne otpornosti i TLPT: ne dopustite da test postane incident

Testiranje je jedna od najčešće pretraživanih tema DORA 2026 jer je istodobno tehnička i upravljački zahtjevna. Financijski subjekti trebaju testirati IKT sustave, kontrole i procese. Za određene subjekte napredno testiranje kao što je TLPT postaje središnji zahtjev prema DORA Article 26.

Revizijsko pitanje nije samo „Jeste li testirali?” Pitanje glasi: „Je li test bio temeljen na riziku, odobren, siguran, neovisan gdje je potrebno, jesu li nalazi otklonjeni i je li povezan s ciljevima otpornosti?”

Clarysecova Enterprise Politika sigurnosnog testiranja i vježbi red teama jasno definira minimalni program testiranja:

„Vrste testova: Program sigurnosnog testiranja mora uključivati najmanje: (a) skeniranja ranjivosti, koja se sastoje od automatiziranih tjednih ili mjesečnih skeniranja mreža i aplikacija radi identifikacije poznatih ranjivosti; (b) penetracijsko testiranje, koje se sastoji od ručnog dubinskog testiranja određenih sustava ili aplikacija od strane stručnih testera radi identifikacije složenih slabosti; i (c) vježbe red teama, koje se sastoje od simulacija stvarnih napada temeljenih na scenarijima, uključujući socijalni inženjering i druge taktike, radi testiranja sposobnosti organizacije za otkrivanje i odgovor u cjelini.”
Iz odjeljka „Zahtjevi provedbe”, točka politike 6.1.

To je most između rutinskog testiranja i zrelosti TLPT-a. Skeniranja ranjivosti pronalaze poznate slabosti. Penetracijsko testiranje provjerava mogućnost iskorištavanja. Vježbe red teama testiraju otkrivanje i odgovor kao sustav. TLPT, gdje je primjenjiv, treba biti dio uređenog programa testiranja s kontrolom opsega, sigurnosnim pravilima, upravljanjem rizikom produkcijskog okruženja, prikupljanjem dokaza i praćenjem korektivnih radnji.

Zenith Blueprint, faza Kontrole u praksi, korak 21, obrađuje zaštitu informacijskih sustava tijekom revizije i testiranja. Upozorava da revizije, penetracijska testiranja, forenzički pregledi i operativne evaluacije mogu uvesti rizik jer mogu uključivati povišena prava pristupa, invazivne alate ili privremene promjene ponašanja sustava. Blueprint ovu zabrinutost mapira na GDPR Article 32, očekivanja DORA za testiranje digitalne operativne otpornosti, zahtjeve NIS2 povezane s kontinuitetom i prakse COBIT 2019 za sigurnu provedbu revizija i procjena.

U Zenith Controls, kontrola ISO/IEC 27002:2022 5.35, Neovisni pregled informacijske sigurnosti, mapirana je kao preventivna i korektivna, podržavajući povjerljivost, cjelovitost i dostupnost. Povezana je s usklađenošću s politikama, odgovornostima uprave, učenjem iz incidenata, zaštitom zapisa, brisanjem informacija te zapisivanjem događaja i praćenjem. Za DORA su relevantne obveze testiranja prvenstveno Articles 24 to 27, uključujući Article 26 za TLPT. To također podržava GDPR Article 32(1)(d), koji zahtijeva redovito testiranje i vrednovanje tehničkih i organizacijskih mjera, te NIS2 Article 21, koji zahtijeva mjere upravljanja rizicima kibernetičke sigurnosti.

Paket spremnosti za DORA TLPT trebao bi uključivati:

Ključna DORA lekcija jest da dokazi o testiranju ne smiju završiti na izvješću. Revizori će pitati jesu li nalazi ocijenjeni prema riziku, dodijeljeni, otklonjeni i ponovno testirani. Mogu provjeriti i je li testiranje obuhvatilo kritične ili važne funkcije, a ne samo imovinu izloženu internetu.

Neprekidnost poslovanja i oporavak od katastrofe: otpornost mora biti operativna

DORA je regulativa digitalne operativne otpornosti. Oporavak je jednako važan kao i prevencija. Dokumentirani okvir IKT rizika neće pomoći ako prekid platne platforme pokaže da ciljevi vremena oporavka nikada nisu testirani, stabla kontakata dobavljača su zastarjela, a krizni tim ne može dogovoriti tko komunicira s klijentima.

Clarysecova SME Politika neprekidnosti poslovanja i oporavka od katastrofe postavlja jasnu polaznu osnovu:

„Organizacija mora testirati i svoje BCP i DR sposobnosti najmanje jednom godišnje. Testovi moraju uključivati:”
Iz odjeljka „Zahtjevi provedbe politike”, točka politike 6.4.1.

Enterprise Politika neprekidnosti poslovanja i oporavka od katastrofe započinje poslovnim utjecajem:

„Analiza utjecaja na poslovanje (BIA) mora se provoditi najmanje jednom godišnje za sve kritične poslovne jedinice i pregledati nakon značajnih promjena sustava, procesa ili ovisnosti. Izlazni rezultati BIA-e moraju definirati:”
Iz odjeljka „Upravljački zahtjevi”, točka politike 5.2.

Za DORA, BIA treba biti povezana s IKT imovinom, dobavljačima, odgovorom na incidente i testiranjem. Ako BIA identificira „plaćanja klijenata” kao kritičnu funkciju, registar ovisnosti o dobavljačima treba identificirati procesore, usluge u oblaku i mrežne pružatelje koji je podržavaju. Registar rizika treba uključivati scenarije otkaza. Plan testiranja treba uključivati provjeru otpornosti. Plan odgovora na incidente treba uključivati eskalaciju i komunikaciju. DR test treba proizvesti dokaze, a ne samo zapisnik sastanka.

Ta sljedivost pretvara usklađenost s DORA u sustav operativne otpornosti.

Unakrsna usklađenost: jedan skup dokaza, mnogo revizijskih pitanja

Financijski subjekti rijetko se suočavaju samo s DORA. Često imaju obveze prema GDPR, izloženost NIS2, ugovorne sigurnosne obveze, ciljeve ISO/IEC 27001:2022, zahtjeve interne revizije, dubinsku analizu klijenata, očekivanja SOC-a i izvješćivanje odboru o rizicima. Odgovor nije stvaranje odvojenih silosa dokaza. Odgovor je izgraditi model dokaza za unakrsnu usklađenost.

Zenith Controls je Clarysecov kompas za unakrsnu usklađenost. Ne izmišlja nove obveze. Mapira službene standarde i okvire kako bi organizacije razumjele kako jedno područje kontrole podržava više ishoda usklađenosti.

To je važno za proračun i upravljanje. CISO može objasniti odboru da poboljšanje klasifikacije incidenata podržava izvješćivanje prema DORA, prijavu povrede prema GDPR, postupanje s incidentima prema NIS2 i internu otpornost. Voditelj nabave može opravdati mapiranje ovisnosti o dobavljačima jer ono podržava rizik koncentracije prema DORA, dubinsku analizu izvršitelja obrade prema GDPR i sigurnost opskrbnog lanca prema NIS2. Voditelj testiranja može pokazati da vježbe red teama i neovisni pregledi podržavaju DORA testiranje, vrednovanje kontrola prema GDPR i šire pružanje jamstva.

Revizijska perspektiva: kako će procjenitelji testirati vaše DORA dokaze

Spremnost za DORA postaje stvarna kada netko zatraži dokaze. Različiti revizori i procjenitelji pristupit će istoj temi iz različitih kutova.

Revizor usmjeren na ISO/IEC 27001:2022 počet će s logikom ISMS-a: opseg, procjena rizika, obrada rizika, primjenjivost kontrola Annex A, interna revizija, preispitivanje od strane uprave i dokazi da su kontrole provedene. Za sigurnost IKT opskrbnog lanca pregledat će politike, klasifikaciju dobavljača, ugovorne odredbe, dubinsku analizu dobavljača i kontinuirano praćenje. Za upravljanje incidentima pregledat će plan, uloge, rute eskalacije, alate i zapise. Za testiranje će očekivati planirane intervale, neovisnost gdje je primjerena, korektivne radnje i ulazne informacije za preispitivanje od strane uprave.

Revizijska perspektiva ISO/IEC 19011:2018 usredotočuje se na provedbu revizije. U Zenith Controls, metodologija revizije za sigurnost IKT opskrbnog lanca navodi da revizori pregledavaju politike nabave, RFP predloške i procese upravljanja dobavljačima kako bi provjerili jesu li IKT-specifični sigurnosni zahtjevi ugrađeni od nabave do zbrinjavanja. Za upravljanje incidentima revizori pregledavaju plan odgovora na incidente radi potpunosti i usklađenosti s najboljim praksama. Za neovisni pregled revizori traže dokaze da su provedene neovisne revizije ili pregledi.

Perspektiva ISO/IEC 27007:2020 više je specifična za reviziju ISMS-a. Zenith Controls navodi da revizori mogu intervjuirati službenike nabave, osoblje IT sigurnosti i voditelje dobavljača kako bi procijenili razumijevanje i provedbu kontrola IKT opskrbnog lanca. Za pripremu za incidente potvrđuju da tim za odgovor na incidente postoji i da je operativan. Za neovisni pregled provjeravaju obuhvaća li program interne revizije puni opseg ISMS-a i ima li odgovarajuće resurse.

Procjenitelj testiranja koji se oslanja na NIST SP 800-115 usredotočit će se na metodologiju procjene ranjivosti i penetracijskog testiranja. Može provjeriti jesu li opseg testiranja, pravila angažmana, nalazi, ocjene ozbiljnosti, korektivne radnje i ponovno testiranje dokumentirani. Za DORA TLPT to znači da procjenitelju neće biti dovoljna prezentacija red teama. Tražit će dokaz upravljanja, sigurnosti, tehničke dubine i zatvaranja nalaza.

Revizor u stilu COBIT 2019 ili ISACA pitat će jesu li ciljevi upravljanja ispunjeni: tko je vlasnik procesa, kako se mjeri učinkovitost, kako se odobravaju iznimke i kako uprava dobiva jamstvo.

Praktični kontrolni popis spremnosti za DORA 2026

Koristite ovaj kontrolni popis kao radnu osnovu za pretvaranje DORA pretraživanja u aktivnosti.

Upravljanje i RTS/ITS mapiranje

• Održavajte registar usklađenosti s DORA s područjem obveze, primjenjivošću, vlasnikom, dokazima, učestalošću pregleda i statusom praznina.
• Mapirajte DORA zahtjeve na politike, registre, kontrole i izvješćivanje upravi.
• Definirajte obrazloženje proporcionalnosti za pojednostavljeno ili skalirano upravljanje IKT rizicima gdje je primjenjivo.
• Dodijelite izvršnu odgovornost za IKT rizik, prijavljivanje incidenata, nadzor nad trećim stranama i testiranje.
• Uključite DORA status u preispitivanje od strane uprave i izvješćivanje odboru o rizicima.

Upravljanje IKT rizicima

• Održavajte registar IKT rizika s opisom, vjerojatnošću, utjecajem, ocjenom, vlasnikom i planom obrade rizika.
• Povežite rizike s kritičnim ili važnim funkcijama.
• Povežite rizike s IKT imovinom, dobavljačima i procesima.
• Pregledajte rizike nakon velikih incidenata, promjena dobavljača, tehnoloških promjena ili nalaza testiranja.
• Pratite aktivnosti obrade rizika do zatvaranja ili formalnog prihvaćanja rizika.

Nadzor nad IKT trećim stranama

• Održavajte registar dobavljača i registar ovisnosti o dobavljačima.
• Identificirajte dobavljače koji podržavaju kritične ili važne funkcije.
• Procijenite dobavljače koji su jedini izvor i mogućnost njihove zamjene.
• Pregledajte podugovaratelje i aranžmane daljnjeg podugovaranja.
• Ugradite sigurnosne, pristupne, incidentne, revizijske i izlazne odredbe u ugovore.
• Pratite kritične dobavljače najmanje jednom godišnje ili nakon značajnih promjena.
• Održavajte planove izlaska i kontinuiteta za pružatelje s visokom razinom ovisnosti.

Upravljanje incidentima i prijavljivanje

• Održavajte postupke odgovora na incidente s jasnim ulogama i rutama eskalacije.
• Definirajte kriterije klasifikacije IKT incidenata.
• Uskladite okidače izvješćivanja prema DORA s GDPR, NIS2 i ugovornim obvezama obavješćivanja.
• Osposobite zaposlenike i izvođače za kanale prijavljivanja incidenata.
• Održavajte dnevnik incidenata, zapise odluka i dokaze.
• Provedite preglede nakon incidenta i ažurirajte rizike i kontrole.

Testiranje, vježbe red teama i TLPT

• Održavajte kalendar testiranja temeljen na riziku.
• Provodite skeniranja ranjivosti i penetracijska testiranja u definiranim intervalima.
• Koristite vježbe red teama temeljene na scenarijima za testiranje otkrivanja i odgovora.
• Za spremnost za TLPT definirajte opseg, pravila angažmana, sigurnosne kontrole i koordinaciju s dobavljačima.
• Zaštitite produkcijske sustave tijekom testiranja.
• Pratite nalaze, korektivne radnje, ponovno testiranje i naučene lekcije.
• Izvijestite upravu o ishodima testiranja.

Neprekidnost poslovanja i oporavak

• Provodite godišnju BIA za kritične poslovne jedinice i ažurirajte je nakon značajnih promjena.
• Definirajte ciljeve oporavka za kritične funkcije i podržavajuće IKT usluge.
• Testirajte BCP i DR sposobnosti najmanje jednom godišnje.
• Uključite scenarije prekida dobavljača i kibernetičkih incidenata.
• Očuvajte dokaze o testiranju, praznine, korektivne radnje i rezultate ponovnog testiranja.
• Uskladite planove kontinuiteta s odgovorom na incidente i kriznim komunikacijama.

Kako Clarysec pomaže financijskim subjektima prijeći s rezultata pretraživanja na dokaze spremne za reviziju

Spremnost za DORA 2026 ne postiže se preuzimanjem kontrolnog popisa i nadom da će organizacija kasnije popuniti praznine. Potreban je strukturirani operativni model koji povezuje rizike, dobavljače, incidente, testiranje, kontinuitet i revizijske dokaze.

Clarysecov pristup kombinira tri sloja.

Prvo, Zenith Blueprint pruža plan provedbe. Korak 14 pomaže organizacijama unakrsno povezati regulatorne zahtjeve s obradom rizika i politikama. Korak 16 jača prijavljivanje incidenata koje pokreće osoblje. Korak 21 osigurava da revizije i testovi ne ugrožavaju produkcijske sustave. Korak 23 pretvara nadzor nad dobavljačima u praktičan tijek rada koji obuhvaća klasifikaciju, ugovore, podugovaratelje, praćenje i procjenu oblaka.

Drugo, Clarysec politike pružaju upravljanje spremno za operativnu primjenu. Politika upravljanja rizicima, Politika pravne i regulatorne usklađenosti, Politika sigurnosti trećih strana i dobavljača, Politika upravljanja rizikom ovisnosti o dobavljačima, Politika odgovora na incidente, Politika sigurnosnog testiranja i vježbi red teama te Politika neprekidnosti poslovanja i oporavka od katastrofe daju timovima konkretne točke, modele vlasništva i očekivanja u pogledu dokaza.

Treće, Zenith Controls pruža mapu unakrsne usklađenosti. Pokazuje kako se sigurnost IKT opskrbnog lanca, planiranje upravljanja incidentima i neovisni pregled povezuju s DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 i praksama testiranja NIST.

Rezultat je program usklađenosti s DORA koji je dokaziv u reviziji i koristan tijekom stvarnog incidenta, neuspjeha dobavljača ili testa otpornosti.

Sljedeći korak: izgradite svoj paket dokaza za DORA prije sljedećeg revizijskog zahtjeva

Ako vaš tim još uvijek pretražuje „DORA RTS/ITS kontrolni popis”, „DORA IKT predložak upravljanja rizicima”, „DORA nadzor nad trećim stranama” ili „DORA TLPT zahtjevi”, sljedeći je korak pretvoriti ta pretraživanja u kontrolirane dokaze.

Ovaj tjedan započnite s četiri aktivnosti:

1. Izradite ili ažurirajte svoj registar usklađenosti s DORA koristeći Clarysec model politike.
2. Odaberite jednu kritičnu funkciju i pratite je kroz registar rizika, registar ovisnosti o dobavljačima, tijek incidenata, BIA i plan testiranja.
3. Pregledajte svojih pet najvažnijih IKT dobavljača u pogledu mogućnosti zamjene, podugovaratelja, odredbi o incidentima i opcija izlaska.
4. Izgradite paket dokaza o testiranju s opsegom, autorizacijom, rezultatima, korektivnim radnjama i ponovnim testiranjem.

Clarysec vam može pomoći u provedbi uz Zenith Blueprint, predloške politika i Zenith Controls kako bi vaš DORA 2026 program bio praktičan, proporcionalan i spreman za reviziju.