DORA 2026: časovni načrt za tveganja na področju IKT, dobavitelje in TLPT

Iskalna panika glede DORA 2026 v resnici ni povezana s predpisom, temveč z dokazili

Ponedeljek je, ura je 08:15, vodja informacijske varnosti srednje velike plačilne institucije pa ima odprte tri zavihke v brskalniku: »DORA RTS/ITS kontrolni seznam«, »predloga registra tretjih ponudnikov storitev IKT po DORA« in »zahteve TLPT za finančne subjekte«.

Vodja skladnosti je že vprašal, ali naj gradivo za organ upravljanja vključuje najnovejši delovni tok razvrščanja incidentov. Nabava želi uvesti novo analitično platformo v oblaku. Operativni direktor (COO) želi zagotovilo, da ponudnik ključne bančne storitve SaaS nima skrite izpostavljenosti podizvajalcem zunaj EU. Notranja presoja zahteva koledar testiranja. Pravna služba sprašuje, ali so roki za obveščanje o kršitvah po GDPR usklajeni s poročanjem o incidentih po DORA.

Nihče ne zastavlja teoretičnega vprašanja. Sprašujejo: »Ali lahko to dokažemo do petka?«

To je dejanski izziv DORA 2026. Večina finančnih subjektov razume glavne obveznosti: upravljanje tveganj na področju IKT, poročanje o incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti, upravljanje tveganj tretjih ponudnikov storitev IKT in okrepljen nadzor kritičnih ponudnikov storitev IKT. Zahtevnejši del je pretvoriti regulativne tehnične standarde, izvedbene tehnične standarde in obveznosti na ravni členov v nadzorovano, ponovljivo in presojno preverljivo prakso.

Akt o digitalni operativni odpornosti od finančnih subjektov zahteva vzdrževanje zanesljivih zmogljivosti upravljanja tveganj na področju IKT, politik za upravljanje in poročanje o incidentih, povezanih z IKT, testiranje sistemov, kontrol in procesov IKT ter strukturiran nadzor tretjih ponudnikov storitev IKT. Zahteva tudi sorazmernost. Manjše investicijsko podjetje in velika bančna skupina ne potrebujeta enakih modelov dokazil, vendar morata oba dokazati, da je njun pristop primeren glede na velikost, profil tveganja, kompleksnost in kritične funkcije.

Projekti DORA običajno spodletijo iz enega od treh razlogov. Prvič, organizacija DORA obravnava kot pravno vajo preslikave namesto kot operativni model. Drugič, tveganje dobaviteljev je dokumentirano kot seznam dobaviteljev, ne pa kot odvisnost, zamenljivost in tveganje koncentracije. Tretjič, testiranje se obravnava kot letni penetracijski preizkus, ne kot program odpornosti, ki vključuje skeniranje ranljivosti, scenarijsko testiranje, vaje odziva na incidente in, kjer je relevantno, penetracijsko testiranje na podlagi obveščevalnih podatkov o grožnjah, pogosto iskano kot TLPT.

Boljši pristop je vzpostaviti enoten sistem dokazil, ki povezuje politike, registre, lastnike, tveganja, incidente, dobavitelje, testiranje, obnovitev in vodstveni pregled. Tu Clarysecov Zenith Blueprint, pripravljene politike in Zenith Controls finančnim subjektom pomagajo DORA spremeniti iz roka v operativni ritem.

Začnite z operativnim modelom DORA, ne s preglednico RTS/ITS

Številne ekipe začnejo s preglednico, ki navaja člene DORA in zahteve RTS/ITS. To je koristno, vendar ne zadostuje. Preglednica lahko pove, kaj mora obstajati. Ne dodeli lastnikov, ne določi pogostosti pregledov, ne hrani dokazil in ne dokazuje, da kontrola dejansko deluje.

V Zenith Blueprint: 30-koračni časovni načrt za presojevalce Clarysec to obravnava v fazi upravljanja tveganj, v koraku 14, politike obravnave tveganj in regulativni navzkrižni sklici:

»DORA: Za podjetja v finančnem sektorju DORA zahteva okvir upravljanja tveganj IKT, ki je zelo usklajen s tem, kar smo naredili: identificirati tveganja, vzpostaviti kontrole in politike ter jih testirati. DORA poudarja tudi odziv na incidente in poročanje ter nadzor nad tretjimi ponudniki storitev IKT.«

Praktično sporočilo je preprosto: »skladnosti z DORA« ne gradite kot vzporedne birokracije. Zgradite na tveganjih temelječo plast upravljanja IKT, ki zahteve DORA preslika na politike, registre, lastnike kontrol, zapise testiranja, dokazila dobaviteljev in vodstveni pregled.

Praktičen operativni model DORA mora imeti pet stebrov dokazil:

Za regulirane finančne subjekte ta struktura pretvori izvajanje RTS/ITS v sistem dokazil, pripravljen za presojo. Za subjekte s poenostavljenim upravljanjem tveganj na področju IKT je isti model mogoče prilagoditi na manj dokumentov in enostavnejše registre. Temeljne discipline ostanejo enake: identificirati, zaščititi, zaznati, odzvati se, obnoviti, testirati in upravljati dobavitelje.

Upravljanje tveganj na področju IKT: register je nadzorna soba

Pričakovanja DORA glede upravljanja tveganj na področju IKT od finančnih subjektov zahtevajo, da identificirajo, razvrščajo in upravljajo tveganja IKT v sistemih, podatkih, procesih, kritičnih ali pomembnih funkcijah in odvisnostih od tretjih oseb.

Pogosta pomanjkljivost ni odsotnost registra tveganj. Težava je, da register ni povezan z dobavitelji, sredstvi, incidenti in testi. DORA ne nagrajuje lepo urejene preglednice, če ta ne more pojasniti, zakaj dobavitelj z visokim tveganjem nima načrta izstopa ali zakaj kritična platforma za plačila strank ni bila testirana.

Clarysecova SME Politika upravljanja tveganj manjšim finančnim subjektom zagotavlja jedrnato izhodišče za dokazila:

»Vsak vnos tveganja mora vključevati: opis, verjetnost, vpliv, oceno, lastnika in načrt obravnave tveganja.«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.1.2.

Za večje finančne subjekte Clarysecova Enterprise Politika upravljanja tveganj zahteva bolj formalen proces:

»Vzdrževati je treba formalen proces upravljanja tveganj v skladu z ISO/IEC 27005 in ISO 31000, ki zajema identifikacijo tveganj, analizo, vrednotenje, obravnavo, spremljanje in komuniciranje.«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.1.

Ta razlika je pomembna. DORA je sorazmerna, vendar sorazmernost ne pomeni neformalnosti. Majhno plačilno podjetje lahko uporablja poenostavljen register, bančna skupina pa integrirano orodje GRC. V obeh primerih bo presojevalec še vedno vprašal: Katera so vaša tveganja na področju IKT? Kdo je njihov lastnik? Kakšen je načrt obravnave tveganja? Katera dokazila kažejo napredek? Kako dobavitelji in kritične funkcije vplivajo na oceno?

Močan register tveganj na področju IKT za DORA mora vključevati ta polja:

Praktična vaja je, da vzamete eno kritično storitev IKT, na primer v oblaku gostovano platformo za spremljanje transakcij, in v 20 minutah ustvarite vnos tveganja. Opišite scenarij odpovedi ali kompromitacije, ocenite verjetnost in vpliv, dodelite lastnika, identificirajte povezane dobavitelje, določite načrt obravnave tveganja in vnos povežite z dokazili, kot so skrbni pregled dobavitelja, SLA, klavzule o incidentih, BIA, rezultati testov DR, nadzorne plošče za spremljanje in pregledi pravic dostopa.

Ta en sam vnos postane nit, ki povezuje upravljanje tveganj na področju IKT po DORA, nadzor tretjih oseb, zaznavanje incidentov, neprekinjeno poslovanje in testiranje. Tako register tveganj postane nadzorna soba, ne arhivska omara.

Pripravljenost na RTS/ITS: obveznosti preslikajte na politike, ne na obljube

Praktični iskalni izraz »DORA RTS/ITS kontrolni seznam« običajno pomeni: »Katere dokumente bodo pričakovali nadzorniki?« Finančni subjekti naj se izognejo dokazovanju skladnosti z generičnimi izjavami. Potrebujejo preslikavo, ki vsako obveznost poveže s politiko, kontrolo, lastnikom in dokazilom.

Clarysecova SME Politika pravne in regulativne skladnosti vzpostavlja preprosto upravljavsko sidrišče:

»GM mora vzdrževati preprosto, strukturirano evidenco skladnosti, ki navaja:«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.1.1.

Za DORA 2026 mora vaša evidenca skladnosti vključevati:

• Obveznost DORA ali področje zahteve RTS/ITS.
• Uporabljivost, vključno z utemeljitvijo sorazmernosti.
• Sklic na politiko ali postopek.
• Lastnika kontrole.
• Lokacijo dokazila.
• Pogostost pregleda.
• Odprte vrzeli in rok za odpravo.
• Status poročanja organu upravljanja ali vodstvu.

To je skladno s pristopom Zenith Blueprint v koraku 14: regulativne zahteve preslikajte na kontrole in politike ISMS, da nič ne ostane nepokrito. Namesto vprašanja »Ali smo skladni z DORA?« lahko vodstvo vpraša: »Katera dokazila DORA zamujajo, kateri kritični dobavitelji nimajo načrtov izstopa in katere testne dejavnosti še niso ustvarile dokazil o odpravi?«

Tveganje tretjih ponudnikov storitev IKT: koncentracija, zamenljivost in podizvajalci

DORA je spremenila pogovor o dobaviteljih v finančnih storitvah. Ni več dovolj vprašati, ali ima ponudnik certifikat informacijske varnosti, zavarovanje ali pogodbo o obdelavi osebnih podatkov. Finančni subjekti morajo oceniti, ali ponudnik ustvarja tveganje koncentracije, ali ga je realno mogoče zamenjati, ali je več kritičnih storitev odvisnih od enega dobavitelja ali povezanih dobaviteljev ter ali podizvajanje uvaja dodatno pravno ali odpornostno izpostavljenost.

To je vprašanje, zaradi katerega številni vodje informacijske varnosti ne spijo mirno. Podjetje se lahko pri obdelavi transakcij, analitiki podatkov, portalih za stranke in notranjem sodelovanju opira na enega velikega ponudnika storitev v oblaku. Če ta ponudnik doživi dolgotrajen izpad, regulativni spor ali odpoved podizvajalca, vprašanje ni samo: »Ali imamo pogodbo?« Vprašanje je: »Ali lahko nadaljujemo kritične storitve, komuniciramo s strankami in dokažemo, da smo odvisnost razumeli, preden je odpovedala?«

Clarysecova SME Politika varnosti tretjih oseb in dobaviteljev postavlja temelje:

»Evidenco dobaviteljev mora vzdrževati in posodabljati administrativni ali nabavni kontakt. Vključevati mora:«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.4.

Za podjetniške programe gre Clarysecova Politika upravljanja tveganj odvisnosti od dobaviteljev globlje v odvisnost in zamenljivost, značilni za DORA:

»Register odvisnosti od dobaviteljev: VMO mora vzdrževati posodobljen register vseh kritičnih dobaviteljev, vključno s podatki, kot so zagotovljene storitve/produkti; ali je dobavitelj edini vir; razpoložljivi alternativni dobavitelji ali zamenljivost; trenutni pogodbeni pogoji; in ocena vpliva, če bi dobavitelj odpovedal ali bil kompromitiran. Register mora jasno identificirati dobavitelje z visoko stopnjo odvisnosti (npr. tiste, za katere ne obstaja hitra alternativa).«
Iz razdelka »Zahteve za implementacijo«, klavzula politike 6.1.

To so dokazila o dobaviteljih, ki jih projekti DORA pogosto spregledajo. Evidenca dobaviteljev pove, kdo je dobavitelj. Register odvisnosti pove, kaj se zgodi, ko dobavitelj odpove.

Zenith Blueprint, faza Kontrole v praksi, korak 23, organizacijski ukrepi, zagotavlja praktičen delovni tok za nadzor dobaviteljev. Priporoča pripravo celotnega seznama dobaviteljev, razvrščanje dobaviteljev glede na dostop do sistemov, podatkov ali operativnega nadzora, preverjanje, da so varnostna pričakovanja vključena v pogodbe, upravljanje podizvajalskega in nižjenivojskega tveganja, določitev postopkov sprememb in spremljanja ter vzpostavitev procesa ocenjevanja storitev v oblaku.

V Zenith Controls: vodniku za navzkrižno skladnost je kontrola ISO/IEC 27002:2022 5.21, Upravljanje informacijske varnosti v dobavni verigi IKT, preslikana kot preventivna kontrola, ki podpira zaupnost, celovitost in razpoložljivost. Povezana je z varnostjo odnosov z dobavitelji in konceptom identifikacije v kibernetski varnosti. Povezuje se z varnim inženiringom, varnim programiranjem, nadzorom dostopa, varnostnim testiranjem, zbiranjem dokazov, varnim razvojnim ciklom in zunanjim razvojem.

Prav to je realnost nadzora tretjih oseb po DORA. Tveganje dobaviteljev ni samo naloga nabave. Dotika se arhitekture, razvoja, odziva na incidente, nadzora dostopa, neprekinjenega poslovanja in prava.

Z vidika navzkrižne skladnosti Zenith Controls preslika varnost dobavne verige IKT na GDPR Articles 28 and 32, ker je treba obdelovalce in podobdelovalce izbrati in nadzorovati z ustreznimi tehničnimi in organizacijskimi ukrepi. Podpira pričakovanja NIS2 glede varnosti dobavne verige, vključno z Article 21 ukrepi za obvladovanje kibernetskih tveganj in Article 22 usklajenimi ocenami tveganj dobavne verige. Močno se preslika na DORA Articles 28, 29 and 30, kjer so v ospredju tveganje tretjih ponudnikov storitev IKT, tveganje koncentracije, nadaljnje zunanje izvajanje in pogodbena določila.

Podporni standardi krepijo dokazila. ISO/IEC 27036-3:2021 podpira varnost nabave IKT in izbire dobaviteljev. ISO/IEC 20243:2018 podpira celovitost zaupanja vrednih tehnoloških produktov in varnost dobavne verige. ISO/IEC 27001:2022 to povezuje z obravnavo tveganj in kontrolami dobaviteljev iz Priloge A.

Poročanje o incidentih: zgradite eskalacijsko verigo pred incidentom

Poročanje o incidentih po DORA ni samo oddaja obvestila. Gre za zaznavanje, razvrščanje, eskalacijo, komuniciranje in učenje iz incidentov, povezanih z IKT. Finančni subjekti morajo vzdrževati procese za upravljanje incidentov IKT in poročanje, z opredeljenimi vlogami, merili razvrščanja, potmi obveščanja in analizo po incidentu.

Clarysecova SME Politika odzivanja na incidente povezuje časovne roke odziva na incidente s pravnimi zahtevami:

»Časovni roki odziva, vključno z obnovitvijo podatkov in obveznostmi obveščanja, morajo biti dokumentirani in usklajeni s pravnimi zahtevami, kot je zahteva GDPR za obveščanje o kršitvi varnosti osebnih podatkov v 72 urah.«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.2.

Za podjetniška okolja Clarysecova Politika odzivanja na incidente dodaja pogled eskalacije reguliranih podatkov:

»Če incident povzroči potrjeno ali verjetno izpostavljenost osebnih podatkov ali drugih reguliranih podatkov, morata pravna služba in DPO oceniti uporabljivost:«
Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.4.1.

Citat se konča pri sprožilcu, kar je natanko točka, kjer številni procesi odziva na incidente odpovejo. Če sprožilec ni jasen, ekipe razpravljajo o obveznostih obveščanja, medtem ko ura že teče.

Zenith Blueprint, faza Kontrole v praksi, korak 16, kontrole, povezane z ljudmi II, poudarja poročanje o incidentih, ki ga omogoča osebje. Zaposleni, pogodbeni izvajalci in zainteresirane strani morajo vedeti, kako prepoznati in prijaviti morebitne varnostne incidente prek preprostih kanalov, kot so namenski poštni predal, portal ali telefonska številka. Blueprint to povezuje z GDPR Article 33, NIS2 Article 23 in DORA Article 17, ker se regulativno poročanje začne z notranjo ozaveščenostjo in eskalacijo.

V Zenith Controls je kontrola ISO/IEC 27002:2022 5.24, Načrtovanje in priprava upravljanja incidentov informacijske varnosti, preslikana kot korektivna kontrola, ki podpira zaupnost, celovitost in razpoložljivost ter je usklajena z odzivanjem in obnovitvijo. Neposredno se povezuje z oceno dogodkov, učenjem iz incidentov, beleženjem in spremljanjem, varnostjo med motnjami, neprekinjenostjo informacijske varnosti in stiki z organi. Vodnik to preslika na DORA Articles 17 to 23 za upravljanje, razvrščanje in poročanje o incidentih, povezanih z IKT, ter prostovoljno obveščanje o kibernetskih grožnjah, GDPR Articles 33 and 34 za obveščanje o kršitvah in NIS2 Article 23 za obveščanje o incidentih.

Proces incidentov, pripravljen za DORA, mora vključevati:

• Jasne kanale za sprejem incidentov.
• Triažo dogodkov in merila razvrščanja.
• Delovni tok eskalacije večjih incidentov, povezanih z IKT.
• Odločitvene točke pravne službe, DPO in regulativnega obveščanja.
• Sprožilce obveščanja dobaviteljev o incidentih.
• Zahteve za ohranitev dokazil.
• Pravila komuniciranja z izvršnim vodstvom in organom upravljanja.
• Pregled po incidentu in pridobljene izkušnje.
• Povezavo s posodobitvami registra tveganj in odpravo kontrol.

Podporni standardi dodajo strukturo. ISO/IEC 27035-1:2023 zagotavlja načela načrtovanja in priprave za upravljanje incidentov. ISO/IEC 27035-2:2023 podrobno določa korake obravnave incidentov. ISO/IEC 22320:2018 podpira vodenje, nadzor in strukturirano krizno komuniciranje. To je pomembno, ko izpad IKT postane kriza z vplivom na stranke in mora subjekt pokazati, da so bile odločitve pravočasne, usklajene in podprte z dokazili.

Testiranje digitalne operativne odpornosti in TLPT: ne dovolite, da test postane incident

Testiranje je ena najpogosteje iskanih tem DORA 2026, ker je hkrati tehnična in izrazito upravljavska. Finančni subjekti morajo testirati sisteme, kontrole in procese IKT. Za imenovane subjekte napredno testiranje, kot je TLPT, postane osrednja zahteva po DORA Article 26.

Presojno vprašanje ni samo: »Ali ste testirali?« Temveč: »Ali je bil test zasnovan na tveganjih, odobren, varen, neodvisen, kjer je to zahtevano, ali so bile ugotovitve odpravljene in ali je povezan s cilji odpornosti?«

Clarysecova Enterprise Politika varnostnega testiranja in red team jasno opredeljuje minimalni program testiranja:

»Vrste testov: Program varnostnega testiranja mora vključevati najmanj: (a) skeniranje ranljivosti, ki obsega avtomatizirana tedenska ali mesečna skeniranja omrežij in aplikacij za identifikacijo znanih ranljivosti; (b) penetracijsko testiranje, ki obsega ročno poglobljeno testiranje specifičnih sistemov ali aplikacij, ki ga izvajajo usposobljeni preizkuševalci za identifikacijo kompleksnih slabosti; in (c) vaje red team, ki obsegajo simulacije dejanskih napadov na podlagi scenarijev, vključno s socialnim inženiringom in drugimi taktikami, za testiranje zmožnosti zaznavanja in odzivanja organizacije kot celote.«
Iz razdelka »Zahteve za implementacijo«, klavzula politike 6.1.

To je most med rutinskim testiranjem in zrelostjo TLPT. Skeniranje ranljivosti najde znane slabosti. Penetracijsko testiranje potrjuje možnost izkoriščanja. Red team testira zaznavanje in odziv kot sistem. TLPT, kjer je uporaben, mora biti umeščen v upravljan program testiranja z nadzorom obsega, varnostnimi pravili, upravljanjem produkcijskega tveganja, zajemom dokazil in sledenjem odpravi.

Zenith Blueprint, faza Kontrole v praksi, korak 21, obravnava zaščito informacijskih sistemov med presojo in testiranjem. Opozarja, da lahko presoje, penetracijski preizkusi, forenzični pregledi in operativna vrednotenja uvedejo tveganje, ker lahko vključujejo povišane privilegije, invazivna orodja ali začasne spremembe vedenja sistema. Blueprint to skrb preslika na GDPR Article 32, pričakovanja DORA glede testiranja digitalne operativne odpornosti, pomisleke NIS2 glede neprekinjenosti in prakse COBIT 2019 za varno izvedbo presoj in ocen.

V Zenith Controls je kontrola ISO/IEC 27002:2022 5.35, Neodvisen pregled informacijske varnosti, preslikana kot preventivna in korektivna, pri čemer podpira zaupnost, celovitost in razpoložljivost. Povezuje se z upoštevanjem politik, odgovornostmi vodstva, učenjem iz incidentov, zaščito zapisov, brisanjem informacij, beleženjem in spremljanjem. Za DORA so relevantne obveznosti testiranja predvsem Articles 24 to 27, vključno z Article 26 za TLPT. To podpira tudi GDPR Article 32(1)(d), ki zahteva redno testiranje in ocenjevanje tehničnih in organizacijskih ukrepov, ter NIS2 Article 21, ki zahteva ukrepe za obvladovanje kibernetskih tveganj.

Paket pripravljenosti na DORA TLPT mora vključevati:

Ključna lekcija DORA je, da se dokazila testiranja ne smejo končati pri poročilu. Presojevalci bodo vprašali, ali so bile ugotovitve ocenjene glede na tveganje, dodeljene, odpravljene in ponovno testirane. Prav tako lahko preverijo, ali je testiranje zajelo kritične ali pomembne funkcije, ne samo sredstev, dostopnih iz interneta.

Neprekinjeno poslovanje in obnovitev po nesreči: odpornost mora biti operativna

DORA je predpis o digitalni operativni odpornosti. Obnovitev je enako pomembna kot preprečevanje. Dokumentiran okvir tveganj na področju IKT ne bo pomagal, če izpad plačilne platforme razkrije, da ciljni časi obnovitve niso bili nikoli testirani, seznami kontaktov dobaviteljev so zastareli, krizna ekipa pa se ne more dogovoriti, kdo komunicira s strankami.

Clarysecova SME Politika neprekinjenega poslovanja in obnovitve po nesreči določa jasno izhodišče:

»Organizacija mora vsaj enkrat letno testirati tako svoj BCP kot zmogljivosti DR. Testi morajo vključevati:«
Iz razdelka »Zahteve za implementacijo politike«, klavzula politike 6.4.1.

Enterprise Politika neprekinjenega poslovanja in obnovitve po nesreči se začne s poslovnim vplivom:

»Analiza vpliva na poslovanje (BIA) se mora izvesti vsaj enkrat letno za vse kritične poslovne enote in pregledati ob pomembnih spremembah sistemov, procesov ali odvisnosti. Rezultati BIA morajo opredeliti:«
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.

Za DORA mora biti BIA povezana s sredstvi IKT, dobavitelji, odzivom na incidente in testiranjem. Če BIA identificira »plačila strank« kot kritično funkcijo, mora register odvisnosti od dobaviteljev identificirati obdelovalce, storitve v oblaku in omrežne ponudnike, ki jo podpirajo. Register tveganj mora vključevati scenarije odpovedi. Načrt testiranja mora vključevati preverjanje odpornosti. Načrt odzivanja na incidente mora vključevati eskalacijo in komuniciranje. Test DR mora ustvariti dokazila, ne samo zapisnika sestanka.

Ta sledljivost je tisto, kar skladnost z DORA pretvori v sistem operativne odpornosti.

Navzkrižna skladnost: en nabor dokazil, veliko presojnih vprašanj

Finančni subjekti se redko soočajo samo z DORA. Pogosto imajo obveznosti GDPR, izpostavljenost NIS2, pogodbene varnostne zaveze, cilje ISO/IEC 27001:2022, zahteve notranje presoje, skrbne preglede strank, pričakovanja SOC in poročanje o tveganjih organu upravljanja. Odgovor ni ustvarjanje ločenih silosov dokazil. Odgovor je vzpostavitev navzkrižnega modela dokazil o skladnosti.

Zenith Controls je Clarysecov kompas navzkrižne skladnosti. Ne izumlja novih obveznosti. Preslika uradne standarde in okvire, da organizacije razumejo, kako eno področje kontrol podpira več izidov skladnosti.

To je pomembno za proračun in upravljanje. Vodja informacijske varnosti lahko organu upravljanja pojasni, da izboljšanje razvrščanja incidentov podpira poročanje po DORA, obveščanje o kršitvah po GDPR, obravnavanje incidentov po NIS2 in notranjo odpornost. Vodja nabave lahko utemelji preslikavo odvisnosti od dobaviteljev, ker podpira tveganje koncentracije po DORA, skrbni pregled obdelovalcev po GDPR in varnost dobavne verige po NIS2. Vodja testiranja lahko pokaže, da vaje red team in neodvisni pregledi podpirajo testiranje po DORA, ocenjevanje kontrol po GDPR in širše zagotavljanje zaupanja.

Presojni pogled: kako bodo ocenjevalci preverjali vaša dokazila DORA

Pripravljenost na DORA postane resnična, ko nekdo zahteva dokazila. Različni presojevalci in ocenjevalci bodo isto temo obravnavali iz različnih zornih kotov.

Presojevalec, usmerjen v ISO/IEC 27001:2022, bo začel z logiko ISMS: obseg, ocena tveganja, obravnava tveganja, uporabljivost kontrol iz Priloge A, notranja presoja, vodstveni pregled in dokazila, da so kontrole implementirane. Pri varnosti dobavne verige IKT bo pregledal politike, razvrščanje dobaviteljev, pogodbene klavzule, skrbni pregled in stalno spremljanje. Pri upravljanju incidentov bo preveril načrt, vloge, eskalacijske poti, orodja in zapise. Pri testiranju bo pričakoval načrtovane intervale, neodvisnost, kjer je ustrezno, odpravo in prispevek k vodstvenemu pregledu.

Presojni pogled ISO/IEC 19011:2018 se osredotoča na izvedbo presoje. V Zenith Controls metodologija presoje za varnost dobavne verige IKT navaja, da presojevalci pregledajo nabavne politike, predloge RFP in procese upravljanja dobaviteljev, da preverijo, ali so varnostne zahteve, specifične za IKT, vključene od pridobitve do odstranjevanja. Pri upravljanju incidentov presojevalci pregledajo načrt odzivanja na incidente glede popolnosti in usklajenosti z dobrimi praksami. Pri neodvisnem pregledu iščejo dokazila, da so bile izvedene neodvisne presoje ali pregledi.

Pogled ISO/IEC 27007:2020 je bolj specifičen za presoje ISMS. Zenith Controls navaja, da lahko presojevalci intervjuvajo nabavne pooblaščence, osebje za IT-varnost in upravljavce dobaviteljev, da ocenijo razumevanje in izvajanje kontrol dobavne verige IKT. Pri pripravi na incidente potrdijo, da skupina za odzivanje na incidente obstaja in deluje. Pri neodvisnem pregledu preverijo, da program notranje presoje pokriva celoten obseg ISMS in je ustrezno kadrovsko podprt.

Ocenjevalec testiranja, ki uporablja NIST SP 800-115, se bo osredotočil na metodologijo ocenjevanja ranljivosti in penetracijskega testiranja. Preveri lahko, ali so obseg testa, pravila izvajanja, ugotovitve, ocene resnosti, odprava in ponovno testiranje dokumentirani. Za DORA TLPT to pomeni, da ocenjevalec ne bo zadovoljen s predstavitvijo red team. Zahteval bo dokaz upravljanja, varnosti, tehnične globine in zaključevanja ugotovitev.

Presojevalec v slogu COBIT 2019 ali ISACA bo vprašal, ali so cilji upravljanja doseženi: kdo je lastnik procesa, kako se meri uspešnost, kako se odobrijo izjeme in kako vodstvo prejema zagotovila.

Praktični kontrolni seznam pripravljenosti na DORA 2026

Uporabite ta kontrolni seznam kot delovno izhodišče za pretvorbo iskanj o DORA v ukrepanje.

Upravljanje in preslikava RTS/ITS

• Vzdržujte evidenco skladnosti z DORA s področjem obveznosti, uporabljivostjo, lastnikom, dokazili, pogostostjo pregleda in statusom vrzeli.
• Preslikajte zahteve DORA na politike, registre, kontrole in vodstveno poročanje.
• Določite utemeljitev sorazmernosti za poenostavljeno ali prilagojeno upravljanje tveganj na področju IKT, kjer je relevantno.
• Dodelite odgovornost izvršnega vodstva za tveganja IKT, poročanje o incidentih, nadzor tretjih oseb in testiranje.
• Vključite status DORA v vodstveni pregled in poročanje organu upravljanja o tveganjih.

Upravljanje tveganj na področju IKT

• Vzdržujte register tveganj IKT z opisom, verjetnostjo, vplivom, oceno, lastnikom in načrtom obravnave tveganja.
• Povežite tveganja s kritičnimi ali pomembnimi funkcijami.
• Povežite tveganja s sredstvi IKT, dobavitelji in procesi.
• Preglejte tveganja po večjih incidentih, spremembah dobaviteljev, tehnoloških spremembah ali ugotovitvah testiranja.
• Sledite ukrepom obravnave do zaključka ali formalnega sprejema tveganja.

Nadzor tretjih ponudnikov storitev IKT

• Vzdržujte evidenco dobaviteljev in register odvisnosti od dobaviteljev.
• Identificirajte dobavitelje, ki podpirajo kritične ali pomembne funkcije.
• Ocenite dobavitelje, ki so edini vir, in zamenljivost.
• Preglejte podizvajalce in ureditve nadaljnjega zunanjega izvajanja.
• V pogodbe vključite klavzule o varnosti, dostopu, poročanju o incidentih, presoji in izstopu.
• Kritične dobavitelje spremljajte vsaj letno ali po pomembnih spremembah.
• Vzdržujte načrte izstopa in ukrepov ob nepredvidenih dogodkih za ponudnike z visoko stopnjo odvisnosti.

Upravljanje incidentov in poročanje

• Vzdržujte postopke odzivanja na incidente z jasnimi vlogami in eskalacijskimi potmi.
• Določite merila razvrščanja incidentov IKT.
• Uskladite sprožilce poročanja po DORA z GDPR, NIS2 in pogodbenimi obveznostmi obveščanja.
• Usposobite zaposlene in pogodbene izvajalce za uporabo kanalov poročanja o incidentih.
• Vzdržujte dnevnike incidentov, zapise odločitev in dokazila.
• Izvedite preglede po incidentu ter posodobite tveganja in kontrole.

Testiranje, red team in TLPT

• Vzdržujte koledar testiranja na podlagi tveganj.
• Izvajajte skeniranje ranljivosti in penetracijsko testiranje v določenih intervalih.
• Uporabljajte scenarijske vaje red team za testiranje zaznavanja in odziva.
• Za pripravljenost na TLPT določite obseg, pravila izvajanja, varnostne kontrole in koordinacijo z dobavitelji.
• Med testiranjem zaščitite produkcijske sisteme.
• Sledite ugotovitvam, odpravi, ponovnemu testiranju in pridobljenim izkušnjam.
• O rezultatih testiranja poročajte vodstvu.

Neprekinjeno poslovanje in obnovitev

• Izvedite letno BIA za kritične poslovne enote in jo posodobite po pomembnih spremembah.
• Določite cilje obnovitve za kritične funkcije in podporne storitve IKT.
• Vsaj letno testirajte zmogljivosti BCP in DR.
• Vključite scenarije izpada dobavitelja in kibernetskega incidenta.
• Ohranite dokazila testov, vrzeli, sanacijske ukrepe in rezultate ponovnega testiranja.
• Uskladite načrte neprekinjenega poslovanja z odzivom na incidente in kriznim komuniciranjem.

Kako Clarysec finančnim subjektom pomaga od rezultatov iskanja do dokazil, pripravljenih za presojo

Pripravljenosti na DORA 2026 ni mogoče doseči s prenosom kontrolnega seznama in upanjem, da bo organizacija pozneje zapolnila vrzeli. Zahteva strukturiran operativni model, ki povezuje tveganja, dobavitelje, incidente, testiranje, neprekinjeno poslovanje in presojna dokazila.

Clarysecov pristop združuje tri plasti.

Prvič, Zenith Blueprint zagotavlja časovni načrt implementacije. Korak 14 organizacijam pomaga navzkrižno sklicevati regulativne zahteve na obravnavo tveganj in politike. Korak 16 krepi poročanje o incidentih, ki ga omogoča osebje. Korak 21 zagotavlja, da presoje in testi ne ogrožajo produkcijskih sistemov. Korak 23 nadzor dobaviteljev pretvori v praktičen delovni tok, ki zajema razvrščanje, pogodbe, podizvajalce, spremljanje in ocenjevanje storitev v oblaku.

Drugič, politike Clarysec zagotavljajo upravljanje, pripravljeno za operativno izvajanje. Politika upravljanja tveganj, Politika pravne in regulativne skladnosti, Politika varnosti tretjih oseb in dobaviteljev, Politika upravljanja tveganj odvisnosti od dobaviteljev, Politika odzivanja na incidente, Politika varnostnega testiranja in red team ter Politika neprekinjenega poslovanja in obnovitve po nesreči ekipam dajejo konkretne klavzule, modele lastništva in pričakovanja glede dokazil.

Tretjič, Zenith Controls zagotavlja zemljevid navzkrižne skladnosti. Pokaže, kako se varnost dobavne verige IKT, načrtovanje upravljanja incidentov in neodvisni pregled povezujejo z 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 in praksami testiranja NIST.

Rezultat je program skladnosti z DORA, ki je zagovorljiv pri presoji in uporaben med dejanskim incidentom, odpovedjo dobavitelja ali testom odpornosti.

Naslednji korak: pripravite paket dokazil DORA pred naslednjo presojno zahtevo

Če vaša ekipa še vedno išče »DORA RTS/ITS kontrolni seznam«, »predloga upravljanja tveganj IKT po DORA«, »nadzor tretjih oseb po DORA« ali »zahteve DORA TLPT«, je naslednji korak pretvoriti ta iskanja v nadzorovana dokazila.

Ta teden začnite s štirimi ukrepi:

1. Ustvarite ali posodobite svojo evidenco skladnosti z DORA z uporabo modela politik Clarysec.
2. Izberite eno kritično funkcijo in jo sledite skozi register tveganj, register odvisnosti od dobaviteljev, delovni tok incidentov, BIA in načrt testiranja.
3. Preglejte svojih pet najpomembnejših dobaviteljev IKT glede zamenljivosti, podizvajalcev, klavzul o incidentih in možnosti izstopa.
4. Pripravite paket dokazil o testiranju z obsegom, odobritvijo, rezultati, odpravo in ponovnim testiranjem.

Clarysec vam lahko pomaga to implementirati z uporabo Zenith Blueprint, predlog politik in Zenith Controls, da bo vaš program DORA 2026 praktičen, sorazmeren in pripravljen za presojo.