Plán postupu DORA 2026 pre riziká v oblasti IKT, dodávateľov a TLPT

Vyhľadávacia panika okolo DORA 2026 v skutočnosti nie je o regulácii, ale o dôkazoch

Je pondelok 08:15 a CISO stredne veľkej platobnej inštitúcie má otvorené tri karty prehliadača: „kontrolný zoznam DORA RTS/ITS“, „šablóna registra tretích strán v oblasti IKT podľa DORA“ a „požiadavky TLPT pre finančné subjekty“.

Manažér súladu sa už opýtal, či má podklad pre riadiaci orgán obsahovať najnovší pracovný tok klasifikácie incidentov. Obstarávanie chce zaviesť novú cloudovú analytickú platformu. COO chce uistenie, že hlavný poskytovateľ bankového SaaS nemá skrytú expozíciu voči subdodávateľom mimo EÚ. Vnútorný audit žiada kalendár testovania. Právne oddelenie sa pýta, či boli lehoty na oznámenie porušenia ochrany osobných údajov podľa GDPR zosúladené s nahlasovaním incidentov podľa DORA.

Nikto nekladie teoretickú otázku. Pýtajú sa: „Vieme to dokázať do piatka?“

To je skutočný problém DORA 2026. Väčšina finančných subjektov rozumie hlavným povinnostiam: riadenie rizík v oblasti IKT, nahlasovanie incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, riadenie rizík tretích strán v oblasti IKT a silnejší dohľad nad kritickými poskytovateľmi IKT. Náročné je previesť regulačné technické predpisy, vykonávacie technické predpisy a povinnosti na úrovni článkov do riadenej, opakovateľnej a auditovateľnej praxe.

Nariadenie o digitálnej prevádzkovej odolnosti vyžaduje, aby finančné subjekty udržiavali robustné schopnosti riadenia rizík v oblasti IKT, politiky na riadenie a nahlasovanie incidentov súvisiacich s IKT, testovanie systémov, kontrol a procesov IKT a štruktúrovaný dohľad nad externými poskytovateľmi IKT. Zároveň očakáva proporcionalitu. Menšia investičná spoločnosť a veľká banková skupina nepotrebujú totožné modely dôkazov, ale obe musia preukázať, že ich prístup zodpovedá ich veľkosti, rizikovému profilu, zložitosti a kritickým funkciám.

Projekty DORA zvyčajne zlyhávajú z jedného z troch dôvodov. Po prvé, organizácia považuje DORA za právne mapovanie, nie za prevádzkový model. Po druhé, dodávateľské riziko je zdokumentované ako zoznam dodávateľov, nie ako závislosť, nahraditeľnosť a riziko koncentrácie. Po tretie, testovanie sa chápe ako ročný penetračný test, nie ako program odolnosti, ktorý zahŕňa skenovanie zraniteľností, scenárové testovanie, cvičenia incidentov a tam, kde je to uplatniteľné, penetračné testovanie vedené hrozbami, bežne vyhľadávané ako TLPT.

Lepší prístup je vybudovať jeden systém dôkazov, ktorý prepája politiky, registre, vlastníkov, riziká, incidenty, dodávateľov, testovanie, obnovu a preskúmanie manažmentom. Práve tu Zenith Blueprint, pripravené politiky a Zenith Controls od Clarysec pomáhajú finančným subjektom premeniť DORA z termínu na prevádzkový rytmus.

Začnite prevádzkovým modelom DORA, nie tabuľkou RTS/ITS

Mnohé tímy začínajú tabuľkou so zoznamom článkov DORA a požiadaviek RTS/ITS. Je to užitočné, ale nie postačujúce. Tabuľka vie povedať, čo musí existovať. Nepriraďuje vlastníkov, nedefinuje frekvenciu preskúmania, neuchováva dôkazy ani nepreukazuje, že kontrola skutočne funguje.

V Zenith Blueprint: 30-kroková cestovná mapa audítora sa Clarysec venuje tejto téme vo fáze riadenia rizík, v kroku 14, Politiky ošetrenia rizík a regulačné krížové odkazy:

„DORA: Pre spoločnosti vo finančnom sektore DORA vyžaduje rámec riadenia rizík v oblasti IKT veľmi podobný tomu, čo sme už urobili: identifikovať riziká, zaviesť kontroly a politiky a testovať ich. DORA zároveň kladie dôraz na reakciu na incidenty a nahlasovanie, ako aj na dohľad nad externými poskytovateľmi služieb IKT.“

Praktické posolstvo je jednoduché: nebudujte „súlad s DORA“ ako paralelnú byrokraciu. Vybudujte rizikovo orientovanú vrstvu správy IKT, ktorá mapuje požiadavky DORA na politiky, registre, vlastníkov kontrol, záznamy testovania, dôkazy od dodávateľov a preskúmanie manažmentom.

Praktický prevádzkový model DORA má mať päť pilierov dôkazov:

Pre regulované finančné subjekty táto štruktúra mení implementáciu RTS/ITS na systém dôkazov pripravený na audit. Pri subjektoch so zjednodušeným riadením rizík v oblasti IKT možno ten istý model škálovať na menší počet dokumentov a jednoduchšie registre. Základné disciplíny zostávajú rovnaké: identifikovať, chrániť, detegovať, reagovať, obnoviť, testovať a riadiť dodávateľov.

Riadenie rizík v oblasti IKT: register je riadiacim centrom

Očakávania DORA v oblasti riadenia rizík v oblasti IKT vyžadujú, aby finančné subjekty identifikovali, klasifikovali a riadili riziká IKT naprieč systémami, údajmi, procesmi, kritickými alebo dôležitými funkciami a závislosťami od tretích strán.

Bežným zlyhaním nie je absencia registra rizík. Problémom je, že register nie je prepojený s dodávateľmi, aktívami, incidentmi a testami. DORA neocení peknú tabuľku, ak nevie vysvetliť, prečo vysokorizikový dodávateľ nemá plán ukončenia alebo prečo kritická platforma zákazníckych platieb nebola otestovaná.

Politika riadenia rizík pre MSP od Clarysec poskytuje menším finančným subjektom stručnú dôkazovú základňu:

„Každý záznam rizika musí obsahovať: opis, pravdepodobnosť, dopad, skóre, vlastníka a plán ošetrenia.“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.1.2.

Pre väčšie finančné subjekty vyžaduje podniková Politika riadenia rizík od Clarysec formálnejší proces:

„Musí sa udržiavať formálny proces riadenia rizík v súlade s ISO/IEC 27005 a ISO 31000, ktorý pokrýva identifikáciu, analýzu, hodnotenie, ošetrenie, monitorovanie a komunikáciu rizík.“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.1.

Tento rozdiel je dôležitý. DORA je proporcionálna, ale proporcionalita neznamená neformálnosť. Malá platobná spoločnosť môže používať zjednodušený register, zatiaľ čo banková skupina môže využívať integrované nástroje GRC. V oboch prípadoch sa audítor stále opýta: Aké sú vaše riziká v oblasti IKT? Kto ich vlastní? Aký je plán ošetrenia? Aké dôkazy preukazujú pokrok? Ako dodávatelia a kritické funkcie ovplyvňujú skóre?

Silný register rizík v oblasti IKT podľa DORA má obsahovať tieto polia:

Praktickým cvičením je vziať jednu kritickú službu IKT, napríklad platformu na monitorovanie transakcií prevádzkovanú v cloude, a za 20 minút vytvoriť záznam rizika. Opíšte scenár zlyhania alebo kompromitácie, ohodnoťte pravdepodobnosť a dopad, priraďte vlastníka, identifikujte súvisiacich dodávateľov, definujte plán ošetrenia a prepojte záznam s dôkazmi, ako sú due diligence dodávateľa, SLA, ustanovenia o incidentoch, BIA, výsledky testov DR, monitorovacie panely a revízie prístupových práv.

Tento jediný záznam sa stáva niťou spájajúcou riadenie rizík v oblasti IKT podľa DORA, dohľad nad tretími stranami, detekciu incidentov, kontinuitu a testovanie. Takto sa register rizík stáva riadiacim centrom, nie odkladacou skrinkou.

Pripravenosť na RTS/ITS: mapujte povinnosti na politiky, nie na sľuby

Praktický vyhľadávací výraz „kontrolný zoznam DORA RTS/ITS“ zvyčajne znamená „Aké dokumenty budú orgány dohľadu očakávať?“ Finančné subjekty sa musia vyhnúť deklarovaniu súladu všeobecnými vyhláseniami. Potrebujú mapovanie, ktoré viaže každú povinnosť na politiku, kontrolu, vlastníka a dôkazovú položku.

Politika právneho a regulačného súladu pre MSP od Clarysec stanovuje jednoduchú riadiacu kotvu:

„Generálny riaditeľ musí udržiavať jednoduchý, štruktúrovaný register súladu, ktorý obsahuje:“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.1.1.

Pre DORA 2026 má váš register súladu obsahovať:

• Povinnosť DORA alebo oblasť požiadaviek RTS/ITS.
• Uplatniteľnosť vrátane odôvodnenia proporcionality.
• Odkaz na politiku alebo postup.
• Vlastníka kontroly.
• Umiestnenie dôkazov.
• Frekvenciu preskúmania.
• Otvorené medzery a termín nápravy.
• Stav reportovania riadiacemu orgánu alebo manažmentu.

Toto je v súlade s prístupom kroku 14 v Zenith Blueprint: mapovať regulačné požiadavky na kontroly a politiky ISMS tak, aby nič neprepadlo medzi procesmi. Namiesto otázky „Sme v súlade s DORA?“ sa vedenie môže pýtať: „Ktoré dôkazové položky DORA sú po termíne, ktorým kritickým dodávateľom chýbajú plány ukončenia a ktoré testovacie aktivity ešte nevytvorili dôkazy o náprave?“

Riziko tretích strán v oblasti IKT: koncentrácia, nahraditeľnosť a subdodávatelia

DORA zmenila diskusiu o dodávateľoch vo finančných službách. Už nestačí pýtať sa, či má poskytovateľ bezpečnostnú certifikáciu, poistenie alebo zmluvu o spracúvaní osobných údajov. Finančné subjekty musia posúdiť, či poskytovateľ vytvára riziko koncentrácie, či ho možno realisticky nahradiť, či viacero kritických služieb závisí od jedného dodávateľa alebo od prepojených dodávateľov a či subdodávky prinášajú ďalšiu právnu expozíciu alebo expozíciu z hľadiska odolnosti.

Toto je téma, ktorá mnohým CISO nedá spať. Spoločnosť sa môže spoliehať na jedného významného poskytovateľa cloudových služieb pri spracovaní transakcií, dátovej analytike, zákazníckych portáloch aj internej spolupráci. Ak tento poskytovateľ utrpí dlhodobý výpadok, regulačný spor alebo zlyhanie subdodávateľa, otázka neznie iba „Máme zmluvu?“ Otázka znie: „Vieme pokračovať v kritických službách, komunikovať so zákazníkmi a preukázať, že sme závislosť pochopili ešte pred jej zlyhaním?“

Politika bezpečnosti tretích strán a dodávateľov pre MSP od Clarysec stanovuje základ:

„Register dodávateľov musí udržiavať a aktualizovať administratívny alebo obstarávací kontakt. Musí obsahovať:“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.4.

Pre podnikové programy ide Politika riadenia rizík závislosti od dodávateľov od Clarysec hlbšie do závislostí a nahraditeľnosti špecifických pre DORA:

„Register závislostí od dodávateľov: tím riadenia dodávateľov (VMO) musí udržiavať aktuálny register všetkých kritických dodávateľov vrátane podrobností, ako sú poskytované služby/produkty; či je dodávateľ jediným zdrojom; dostupní alternatívni dodávatelia alebo nahraditeľnosť; aktuálne zmluvné podmienky; a posúdenie dopadu v prípade zlyhania alebo kompromitácie dodávateľa. Register musí jasne identifikovať dodávateľov s vysokou mierou závislosti, napríklad tých, pri ktorých neexistuje rýchla alternatíva.“
Zo sekcie „Požiadavky na implementáciu“, ustanovenie politiky 6.1.

Toto sú dodávateľské dôkazy, ktoré projektom DORA často chýbajú. Register dodávateľov hovorí, kto je dodávateľ. Register závislostí hovorí, čo sa stane, keď dodávateľ zlyhá.

Zenith Blueprint, fáza Kontroly v praxi, krok 23, Organizačné opatrenia, poskytuje praktický pracovný tok pre dohľad nad dodávateľmi. Odporúča zostaviť úplný zoznam dodávateľov, klasifikovať dodávateľov podľa prístupu k systémom, údajom alebo prevádzkovému riadeniu, overiť, že bezpečnostné očakávania sú zapracované do zmlúv, riadiť subdodávateľské a nadväzujúce riziká, definovať postupy zmien a monitorovania a vytvoriť proces hodnotenia cloudových služieb.

V Zenith Controls: príručka krížového súladu je kontrola ISO/IEC 27002:2022 5.21, Riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT, namapovaná ako preventívna kontrola podporujúca dôvernosť, integritu a dostupnosť. Súvisí s bezpečnosťou vzťahov s dodávateľmi a s kybernetickým konceptom Identify. Prepája sa s bezpečným inžinierstvom, bezpečným programovaním, riadením prístupu, bezpečnostným testovaním, zberom dôkazov, životným cyklom bezpečného vývoja a outsourcovaným vývojom.

Presne tak vyzerá realita dohľadu nad tretími stranami podľa DORA. Dodávateľské riziko nie je len vecou obstarávania. Dotýka sa architektúry, vývoja, reakcie na incidenty, riadenia prístupu, kontinuity činností a právnych otázok.

Z pohľadu krížového súladu Zenith Controls mapuje bezpečnosť dodávateľského reťazca IKT na GDPR Articles 28 and 32, pretože sprostredkovatelia a ďalší sprostredkovatelia musia byť vyberaní a dohliadaní s primeranými technickými a organizačnými opatreniami. Podporuje očakávania NIS2 v oblasti bezpečnosti dodávateľského reťazca vrátane Article 21 opatrení riadenia kybernetických rizík a Article 22 koordinovaných posúdení rizík dodávateľského reťazca. Silno sa mapuje na DORA Articles 28, 29 and 30, kde sú centrálne riziko tretích strán v oblasti IKT, riziko koncentrácie, sub-outsourcing a zmluvné ustanovenia.

Podporné normy posilňujú dôkazy. ISO/IEC 27036-3:2021 podporuje bezpečnosť obstarávania IKT a výberu dodávateľov. ISO/IEC 20243:2018 podporuje integritu dôveryhodných technologických produktov a bezpečnosť dodávateľského reťazca. ISO/IEC 27001:2022 to prepája s ošetrením rizík a dodávateľskými kontrolami Annex A.

Nahlasovanie incidentov: vybudujte eskalačný reťazec pred incidentom

Nahlasovanie incidentov podľa DORA nie je iba o odoslaní notifikácie. Ide o detekciu, klasifikáciu, eskaláciu, komunikáciu a učenie sa z incidentov súvisiacich s IKT. Finančné subjekty musia udržiavať procesy riadenia a nahlasovania incidentov súvisiacich s IKT s definovanými rolami, klasifikačnými kritériami, oznamovacími trasami a poincidentnou analýzou.

Politika reakcie na incidenty pre MSP od Clarysec prepája lehoty reakcie na incidenty s právnymi požiadavkami:

„Lehoty reakcie vrátane obnovy údajov a oznamovacích povinností musia byť zdokumentované a zosúladené s právnymi požiadavkami, napríklad s požiadavkou GDPR na oznámenie porušenia ochrany osobných údajov do 72 hodín.“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.3.2.

Pre podnikové prostredia pridáva Politika reakcie na incidenty od Clarysec pohľad eskalácie regulovaných údajov:

„Ak incident vedie k potvrdenému alebo pravdepodobnému sprístupneniu osobných údajov alebo iných regulovaných údajov, právne oddelenie a zodpovedná osoba (DPO) musia posúdiť uplatniteľnosť:“
Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.4.1.

Citácia sa končí pri spúšťači, presne tam, kde mnohé incidentné procesy zlyhávajú. Ak je spúšťač nejasný, tímy diskutujú o oznamovacích povinnostiach, zatiaľ čo čas už beží.

Zenith Blueprint, fáza Kontroly v praxi, krok 16, People Controls II, zdôrazňuje nahlasovanie incidentov riadené zamestnancami. Zamestnanci, dodávatelia a zainteresované strany musia vedieť rozpoznať a nahlásiť potenciálne bezpečnostné incidenty jednoduchými kanálmi, ako je vyhradená e-mailová schránka, portál alebo hotline. Blueprint to prepája s GDPR Article 33, NIS2 Article 23 a DORA Article 17, pretože regulačné oznamovanie sa začína interným povedomím a eskaláciou.

V Zenith Controls je kontrola ISO/IEC 27002:2022 5.24, Plánovanie a príprava riadenia incidentov informačnej bezpečnosti, mapovaná ako nápravná kontrola podporujúca dôvernosť, integritu a dostupnosť, zosúladená s Respond a Recover. Priamo sa viaže na posudzovanie udalostí, učenie sa z incidentov, logovanie a monitorovanie, bezpečnosť počas narušenia, kontinuitu informačnej bezpečnosti a kontakt s orgánmi. Príručka ju mapuje na DORA Articles 17 to 23 pre riadenie, klasifikáciu a nahlasovanie incidentov súvisiacich s IKT a dobrovoľné oznamovanie kybernetických hrozieb, GDPR Articles 33 and 34 pre oznámenie porušenia ochrany údajov a NIS2 Article 23 pre notifikáciu incidentov.

Proces incidentov pripravený na DORA má zahŕňať:

• Jasné kanály prijímania incidentov.
• Triáž udalostí a klasifikačné kritériá.
• Pracovný tok eskalácie významného incidentu súvisiaceho s IKT.
• Rozhodovacie body právneho oddelenia, zodpovednej osoby (DPO) a regulačných notifikácií.
• Spúšťače notifikácie incidentov dodávateľov.
• Požiadavky na uchovanie dôkazov.
• Pravidlá komunikácie s vrcholovým manažmentom a riadiacim orgánom.
• Preskúmanie po incidente a získané ponaučenia.
• Väzbu na aktualizácie registra rizík a nápravné opatrenia kontrol.

Podporné normy pridávajú štruktúru. ISO/IEC 27035-1:2023 poskytuje zásady plánovania a prípravy pre riadenie incidentov. ISO/IEC 27035-2:2023 podrobne opisuje kroky riešenia incidentov. ISO/IEC 22320:2018 podporuje velenie, riadenie a štruktúrovanú krízovú komunikáciu. Je to dôležité vtedy, keď sa výpadok IKT zmení na krízu s dopadom na zákazníkov a subjekt musí preukázať, že rozhodnutia boli včasné, koordinované a založené na dôkazoch.

Testovanie digitálnej prevádzkovej odolnosti a TLPT: nedovoľte, aby sa test stal incidentom

Testovanie patrí medzi najvyhľadávanejšie témy DORA 2026, pretože je technické aj výrazne riadiace. Finančné subjekty musia testovať systémy, kontroly a procesy IKT. Pre určené subjekty sa pokročilé testovanie, ako je TLPT, stáva ústrednou požiadavkou podľa DORA Article 26.

Auditná otázka neznie iba „Testovali ste?“ Znie: „Bol test založený na riziku, autorizovaný, bezpečný, nezávislý tam, kde sa to vyžaduje, napravený a prepojený s cieľmi odolnosti?“

Podniková Politika bezpečnostného testovania a cvičení red teamu od Clarysec jasne definuje minimálny testovací program:

„Typy testov: Program bezpečnostného testovania musí zahŕňať minimálne: (a) skenovanie zraniteľností pozostávajúce z automatizovaných týždenných alebo mesačných skenov sietí a aplikácií na identifikáciu známych zraniteľností; (b) penetračné testovanie pozostávajúce z manuálneho hĺbkového testovania konkrétnych systémov alebo aplikácií kvalifikovanými testermi na identifikáciu komplexných slabín; a (c) cvičenia red teamu pozostávajúce zo scenárových simulácií reálnych útokov vrátane sociálneho inžinierstva a ďalších taktík s cieľom otestovať detekčné a reakčné schopnosti organizácie ako celku.“
Zo sekcie „Požiadavky na implementáciu“, ustanovenie politiky 6.1.

Toto je most medzi rutinným testovaním a zrelosťou TLPT. Skenovanie zraniteľností nachádza známe slabiny. Penetračné testovanie overuje zneužiteľnosť. Red teaming testuje detekciu a reakciu ako systém. TLPT, tam kde je uplatniteľné, má byť súčasťou riadeného testovacieho programu s kontrolou rozsahu, bezpečnostnými pravidlami, riadením rizika produkčného prostredia, zaistením dôkazov a sledovaním nápravy.

Zenith Blueprint, fáza Kontroly v praxi, krok 21, rieši ochranu informačných systémov počas auditu a testovania. Upozorňuje, že audity, penetračné testy, forenzné preskúmania a prevádzkové hodnotenia môžu priniesť riziko, pretože môžu zahŕňať zvýšené oprávnenia, invazívne nástroje alebo dočasné zmeny správania systému. Blueprint mapuje túto obavu na GDPR Article 32, očakávania DORA v oblasti testovania digitálnej prevádzkovej odolnosti, požiadavky NIS2 na kontinuitu a praktiky COBIT 2019 pre bezpečné vykonávanie auditov a posúdení.

V Zenith Controls je kontrola ISO/IEC 27002:2022 5.35, Nezávislé preskúmanie informačnej bezpečnosti, mapovaná ako preventívna a nápravná kontrola podporujúca dôvernosť, integritu a dostupnosť. Viaže sa na súlad s politikami, zodpovednosti manažmentu, učenie sa z incidentov, ochranu záznamov, výmaz informácií, logovanie a monitorovanie. Pre DORA sú relevantné testovacie povinnosti najmä Articles 24 to 27 vrátane Article 26 pre TLPT. Zároveň to podporuje GDPR Article 32(1)(d), ktorý vyžaduje pravidelné testovanie a hodnotenie technických a organizačných opatrení, a NIS2 Article 21, ktorý vyžaduje opatrenia riadenia kybernetických rizík.

Balík pripravenosti na TLPT podľa DORA má obsahovať:

Kľúčové ponaučenie DORA je, že dôkazy z testovania sa nesmú skončiť pri správe. Audítori sa budú pýtať, či boli zistenia ohodnotené podľa rizika, priradené, napravené a opätovne otestované. Môžu tiež overovať, či testovanie pokrývalo kritické alebo dôležité funkcie, nielen aktíva dostupné z internetu.

Kontinuita činností a obnova po havárii: odolnosť musí byť prevádzková

DORA je predpis digitálnej prevádzkovej odolnosti. Obnova je rovnako dôležitá ako prevencia. Zdokumentovaný rámec rizík v oblasti IKT nepomôže, ak výpadok platobnej platformy odhalí, že cieľové časy obnovy neboli nikdy testované, kontaktné stromy dodávateľov sú neaktuálne a krízový tím sa nevie dohodnúť, kto komunikuje so zákazníkmi.

Politika kontinuity činností a obnovy po havárii pre MSP od Clarysec stanovuje jasnú základnú úroveň:

„Organizácia musí testovať svoje schopnosti BCP aj DR najmenej raz ročne. Testy musia zahŕňať:“
Zo sekcie „Požiadavky na implementáciu politiky“, ustanovenie politiky 6.4.1.

Podniková Politika kontinuity činností a obnovy po havárii začína dopadom na činnosť organizácie:

„Analýza vplyvu na podnikanie (BIA) sa musí vykonávať najmenej raz ročne pre všetky kritické organizačné jednotky a preskúmať pri významných zmenách systémov, procesov alebo závislostí. Výstupy BIA musia definovať:“
Zo sekcie „Požiadavky na správu a riadenie“, ustanovenie politiky 5.2.

Pre DORA má byť BIA prepojená s aktívami IKT, dodávateľmi, reakciou na incidenty a testovaním. Ak BIA identifikuje „zákaznícke platby“ ako kritickú funkciu, register závislostí od dodávateľov má identifikovať sprostredkovateľov, cloudové služby a sieťových poskytovateľov, ktorí ju podporujú. Register rizík má obsahovať scenáre zlyhania. Plán testovania má zahŕňať validáciu odolnosti. Plán reakcie na incidenty má obsahovať eskaláciu a komunikáciu. Test DR má vytvoriť dôkazy, nielen zápisnicu zo stretnutia.

Táto sledovateľnosť mení súlad s DORA na systém prevádzkovej odolnosti.

Krížový súlad: jeden súbor dôkazov, mnoho auditných otázok

Finančné subjekty zriedka čelia iba DORA. Často majú povinnosti podľa GDPR, expozíciu voči NIS2, zmluvné bezpečnostné záväzky, ciele ISO/IEC 27001:2022, požiadavky vnútorného auditu, zákaznícke due diligence, očakávania SOC a reportovanie rizík riadiacemu orgánu. Riešením nie je vytvárať oddelené dôkazové silá. Riešením je vybudovať model dôkazov pre krížový súlad.

Zenith Controls je kompasom krížového súladu Clarysec. Nevytvára nové povinnosti. Mapuje oficiálne normy a rámce, aby organizácie rozumeli, ako jedna oblasť kontrol podporuje viacero výsledkov súladu.

Je to dôležité pre rozpočet aj správu. CISO môže riadiacemu orgánu vysvetliť, že zlepšenie klasifikácie incidentov podporuje nahlasovanie podľa DORA, oznámenie porušenia ochrany údajov podľa GDPR, riešenie incidentov podľa NIS2 a internú odolnosť. Vedúci obstarávania vie odôvodniť mapovanie závislostí od dodávateľov, pretože podporuje riziko koncentrácie podľa DORA, due diligence sprostredkovateľov podľa GDPR a bezpečnosť dodávateľského reťazca podľa NIS2. Vedúci testovania vie preukázať, že cvičenia red teamu a nezávislé preskúmania podporujú testovanie podľa DORA, hodnotenie kontrol podľa GDPR a širšie uistenie.

Auditný pohľad: ako posudzovatelia otestujú vaše dôkazy DORA

Pripravenosť na DORA sa stáva reálnou v momente, keď niekto požiada o dôkazy. Rôzni audítori a posudzovatelia budú pristupovať k tej istej téme z rôznych uhlov.

Audítor orientovaný na ISO/IEC 27001:2022 začne logikou ISMS: rozsah, posúdenie rizík, ošetrenie rizík, uplatniteľnosť kontrol Annex A, vnútorný audit, preskúmanie manažmentom a dôkazy o implementácii kontrol. Pri bezpečnosti dodávateľského reťazca IKT bude sledovať politiky, klasifikáciu dodávateľov, zmluvné doložky, due diligence a priebežné monitorovanie. Pri riadení incidentov preskúma plán, roly, eskalačné trasy, nástroje a záznamy. Pri testovaní bude očakávať plánované intervaly, nezávislosť tam, kde je primeraná, nápravu a vstup do preskúmania manažmentom.

Auditný pohľad ISO/IEC 19011:2018 sa sústreďuje na vykonanie auditu. V Zenith Controls metodika auditu pre bezpečnosť dodávateľského reťazca IKT uvádza, že audítori skúmajú politiky obstarávania, šablóny RFP a procesy riadenia dodávateľov, aby overili, že bezpečnostné požiadavky špecifické pre IKT sú zapracované od nadobudnutia až po vyradenie. Pri riadení incidentov audítori skúmajú úplnosť plánu reakcie na incidenty a jeho súlad s osvedčenými postupmi. Pri nezávislom preskúmaní hľadajú dôkazy, že nezávislé audity alebo preskúmania boli vykonané.

Pohľad ISO/IEC 27007:2020 je špecifickejší pre audit ISMS. Zenith Controls uvádza, že audítori môžu viesť rozhovory s pracovníkmi obstarávania, pracovníkmi IT bezpečnosti a manažérmi dodávateľov s cieľom posúdiť pochopenie a vykonávanie kontrol dodávateľského reťazca IKT. Pri príprave na incidenty potvrdzujú, že tím reakcie na incidenty existuje a je prevádzkyschopný. Pri nezávislom preskúmaní overujú, že program vnútorného auditu pokrýva celý rozsah ISMS a má primerané zdroje.

Posudzovateľ testovania vychádzajúci z NIST SP 800-115 sa zameria na metodiku posúdenia zraniteľností a penetračného testovania. Môže skúmať, či sú zdokumentované rozsah testu, pravidlá realizácie, zistenia, klasifikácia závažnosti, náprava a opätovné testovanie. Pri TLPT podľa DORA nebude posudzovateľ spokojný s prezentáciou red teamu. Bude chcieť dôkaz o riadení, bezpečnosti, technickej hĺbke a uzatvorení.

Audítor v štýle COBIT 2019 alebo ISACA sa bude pýtať, či sú splnené ciele správy a riadenia: kto vlastní proces, ako sa meria výkonnosť, ako sa schvaľujú výnimky a ako manažment získava uistenie.

Praktický kontrolný zoznam pripravenosti na DORA 2026

Použite tento kontrolný zoznam ako pracovnú základňu na premenu vyhľadávania DORA na opatrenia.

Správa a mapovanie RTS/ITS

• Udržiavajte register súladu s DORA s oblasťou povinnosti, uplatniteľnosťou, vlastníkom, dôkazmi, frekvenciou preskúmania a stavom medzier.
• Mapujte požiadavky DORA na politiky, registre, kontroly a reportovanie manažmentu.
• Definujte odôvodnenie proporcionality pre zjednodušené alebo škálované riadenie rizík v oblasti IKT tam, kde je uplatniteľné.
• Priraďte zodpovednosť vrcholového vedenia za riziká v oblasti IKT, nahlasovanie incidentov, dohľad nad tretími stranami a testovanie.
• Zahrňte stav DORA do preskúmania manažmentom a reportovania rizík riadiacemu orgánu.

Riadenie rizík v oblasti IKT

• Udržiavajte register rizík v oblasti IKT s opisom, pravdepodobnosťou, dopadom, skóre, vlastníkom a plánom ošetrenia.
• Prepájajte riziká s kritickými alebo dôležitými funkciami.
• Prepájajte riziká s aktívami IKT, dodávateľmi a procesmi.
• Preskúmavajte riziká po významných incidentoch, zmenách dodávateľov, technologických zmenách alebo zisteniach z testovania.
• Sledujte aktivity ošetrenia až po uzatvorenie alebo formálnu akceptáciu rizika.

Dohľad nad tretími stranami v oblasti IKT

• Udržiavajte register dodávateľov a register závislostí od dodávateľov.
• Identifikujte dodávateľov podporujúcich kritické alebo dôležité funkcie.
• Posudzujte dodávateľov typu jediný zdroj a nahraditeľnosť.
• Preskúmavajte subdodávateľov a nastavenia ďalšieho outsourcingu.
• Zapracujte do zmlúv bezpečnostné, prístupové, incidentné, auditné ustanovenia a ustanovenia o ukončení.
• Monitorujte kritických dodávateľov najmenej raz ročne alebo po významných zmenách.
• Udržiavajte plány ukončenia a plány pre mimoriadne situácie pre poskytovateľov s vysokou mierou závislosti.

Riadenie a nahlasovanie incidentov

• Udržiavajte postupy reakcie na incidenty s jasnými rolami a eskalačnými trasami.
• Definujte kritériá klasifikácie incidentov súvisiacich s IKT.
• Zosúlaďte spúšťače nahlasovania podľa DORA s GDPR, NIS2 a zmluvnými oznamovacími povinnosťami.
• Školte zamestnancov a dodávateľov v kanáloch nahlasovania incidentov.
• Udržiavajte logy incidentov, rozhodovacie záznamy a dôkazy.
• Vykonávajte poincidentné preskúmania a aktualizujte riziká a kontroly.

Testovanie, red teaming a TLPT

• Udržiavajte kalendár testovania založený na riziku.
• Vykonávajte skenovanie zraniteľností a penetračné testovanie v definovaných intervaloch.
• Používajte scenárové cvičenia red teamu na testovanie detekcie a reakcie.
• Pre pripravenosť na TLPT definujte rozsah, pravidlá realizácie, bezpečnostné kontroly a koordináciu s dodávateľmi.
• Chráňte produkčné systémy počas testovania.
• Sledujte zistenia, nápravu, opätovné testovanie a získané ponaučenia.
• Reportujte výsledky testovania manažmentu.

Kontinuita a obnova

• Vykonávajte ročnú BIA pre kritické organizačné jednotky a aktualizujte ju po významných zmenách.
• Definujte ciele obnovy pre kritické funkcie a podporné služby IKT.
• Testujte schopnosti BCP a DR najmenej raz ročne.
• Zahrňte scenáre výpadku dodávateľa a kybernetického incidentu.
• Uchovávajte dôkazy z testov, medzery, nápravné opatrenia a výsledky opätovného testovania.
• Zosúlaďte plány kontinuity s reakciou na incidenty a krízovou komunikáciou.

Ako Clarysec pomáha finančným subjektom prejsť od výsledkov vyhľadávania k dôkazom pripraveným na audit

Pripravenosť na DORA 2026 sa nedosiahne stiahnutím kontrolného zoznamu a nádejou, že organizácia neskôr vyplní medzery. Vyžaduje štruktúrovaný prevádzkový model, ktorý prepája riziká, dodávateľov, incidenty, testovanie, kontinuitu a auditné dôkazy.

Prístup Clarysec kombinuje tri vrstvy.

Po prvé, Zenith Blueprint poskytuje implementačný plán postupu. Krok 14 pomáha organizáciám vytvárať krížové odkazy medzi regulačnými požiadavkami, ošetrením rizík a politikami. Krok 16 posilňuje nahlasovanie incidentov riadené zamestnancami. Krok 21 zabezpečuje, aby audity a testy neohrozili produkčné systémy. Krok 23 premieňa dohľad nad dodávateľmi na praktický pracovný tok pokrývajúci klasifikáciu, zmluvy, subdodávateľov, monitorovanie a hodnotenie cloudových služieb.

Po druhé, politiky Clarysec poskytujú správu pripravenú na prevádzkové použitie. Politika riadenia rizík, Politika právneho a regulačného súladu, Politika bezpečnosti tretích strán a dodávateľov, Politika riadenia rizík závislosti od dodávateľov, Politika reakcie na incidenty, Politika bezpečnostného testovania a cvičení red teamu a Politika kontinuity činností a obnovy po havárii dávajú tímom konkrétne ustanovenia, modely vlastníctva a očakávania týkajúce sa dôkazov.

Po tretie, Zenith Controls poskytuje mapu krížového súladu. Ukazuje, ako sa bezpečnosť dodávateľského reťazca IKT, plánovanie riadenia incidentov a nezávislé preskúmanie prepájajú 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 a testovacími praktikami NIST.

Výsledkom je program súladu s DORA, ktorý je obhájiteľný pri audite a užitočný počas skutočného incidentu, zlyhania dodávateľa alebo testu odolnosti.

Ďalší krok: vybudujte balík dôkazov DORA pred ďalšou auditnou požiadavkou

Ak váš tím stále vyhľadáva „kontrolný zoznam DORA RTS/ITS“, „šablóna riadenia rizík v oblasti IKT podľa DORA“, „dohľad nad tretími stranami podľa DORA“ alebo „požiadavky DORA TLPT“, ďalším krokom je premeniť tieto vyhľadávania na riadené dôkazy.

Začnite tento týždeň štyrmi krokmi:

1. Vytvorte alebo aktualizujte register súladu s DORA pomocou modelu politík Clarysec.
2. Vyberte jednu kritickú funkciu a preveďte ju cez register rizík, register závislostí od dodávateľov, pracovný tok incidentov, BIA a plán testovania.
3. Preskúmajte päť najvýznamnejších dodávateľov IKT z hľadiska nahraditeľnosti, subdodávateľov, ustanovení o incidentoch a možností ukončenia.
4. Vybudujte balík dôkazov z testovania s rozsahom, autorizáciou, výsledkami, nápravou a opätovným testovaním.

Clarysec vám môže pomôcť implementovať tento prístup pomocou Zenith Blueprint, šablón politík a Zenith Controls, aby bol váš program DORA 2026 praktický, proporcionálny a pripravený na audit.