Program testovania podľa DORA: mapovanie testov na ISO 27001

Je február 2026. CISO stredne veľkej platobnej inštitúcie má o dva dni zasadnutie predstavenstva, o šesť týždňov dozorný audit ISO/IEC 27001:2022 a v schránke tímu pre súlad čaká požiadavka dohľadu podľa DORA.

Regulátor nežiada uhladenú kybernetickú stratégiu. Požiadavka je praktická:

• Predložte svoj program testovania digitálnej prevádzkovej odolnosti na rok 2026.
• Ukážte, ktoré testy pokrývajú kritické alebo dôležité funkcie.
• Preukážte, ako sa zistenia napravujú a opätovne testujú.
• Doložte dohľad riadiaceho orgánu.
• Vysvetlite, ako sú zapojení externí poskytovatelia IKT.
• Poskytnite záznamy k posúdeniam zraniteľností, scenárovým testom, výkonnostnému a kapacitnému testovaniu a penetračnému testovaniu.

CISO otvorí štyri priečinky. Skeny zraniteľností sú v tiketovacom systéme SOC. Poznámky zo stolového cvičenia sú v zdieľanom úložisku. Výsledky záťažových testov vlastní technický tím. Správy z penetračných testov sú v obmedzenom repozitári právneho oddelenia. Sledovanie nápravy je rozdelené medzi Jira, e-mail a tabuľkový prehľad vytvorený pre minuloročný audit ISO.

Nič z toho nie je falošné. Veľká časť je kvalitná práca. Ešte to však nie je riadený program testovania digitálnej prevádzkovej odolnosti podľa DORA. Je to iba súbor testov.

V roku 2026 na tomto rozdiele záleží. DORA sa uplatňuje od 17. januára 2025 a zavádza jednotný rámec EÚ pre digitálnu prevádzkovú odolnosť v oblastiach riadenia rizík IKT, nahlasovania incidentov, testovania odolnosti, zdieľania informácií o kybernetických hrozbách a zraniteľnostiach, riadenia rizík externých poskytovateľov IKT, zmluvných požiadaviek a dohľadu nad kritickými externými poskytovateľmi IKT. Vzťahuje sa na široké spektrum finančných subjektov vrátane úverových inštitúcií, platobných inštitúcií, investičných spoločností, poskytovateľov služieb kryptoaktív, poisťovní a ďalších regulovaných subjektov. DORA zároveň pôsobí ako odvetvovo špecifický právny akt Únie pre finančné subjekty, ktoré by inak spadali pod rovnocenné povinnosti kybernetickej bezpečnosti podľa NIS2.

Praktická otázka pre predstavenstvá, CISO, manažérov súladu a poskytovateľov IKT už neznie, či sa testovanie vykonáva. Otázka znie, či je testovanie plánované, založené na riziku, podložené dôkazmi, napravované, preskúmavané a opätovne použiteľné naprieč DORA a ISO/IEC 27001:2022.

Prevádzkový model Clarysec je navrhnutý práve pre tento problém. Pomocou Zenith Blueprint: 30-krokový plán audítora, súboru politík Clarysec zosúladených s ISO a Zenith Controls: sprievodca krížovým súladom môžu organizácie premeniť rozptýlené aktivity odolnosti na riadený ročný katalóg testov, ktorý obstojí pred dohľadom, audítormi, klientmi aj predstavenstvom.

Prečo DORA mení testovanie na otázku správy a riadenia

DORA jasne stanovuje zodpovednosť vrcholového vedenia. Article 5 kladie zodpovednosť za riadenie rizík IKT na riadiaci orgán. Article 6 vyžaduje spoľahlivý, komplexný a dobre zdokumentovaný rámec riadenia rizík IKT integrovaný do celkového systému riadenia rizík organizácie. Article 4 dopĺňa zásadu proporcionality, podľa ktorej sa požiadavky uplatňujú podľa veľkosti, celkového rizikového profilu a povahy, rozsahu a zložitosti služieb, činností a prevádzky.

Testovanie digitálnej prevádzkovej odolnosti sa tým stáva viac než technickou úlohou. Stáva sa dôkazom, že riadiaci orgán rozumie riziku, schválil stratégiu, dostáva zmysluplné reporty a presadzuje nápravu.

ISO/IEC 27001:2022 používa podobnú logiku systému manažérstva. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela kontextu, zainteresovaným stranám, zákonným a zmluvným povinnostiam, rozsahu, rozhraniam a závislostiam. Kapitoly 5.1 až 5.3 vyžadujú vedenie, zosúladenie politiky, zdroje, komunikáciu, pridelené zodpovednosti a reportovanie vrcholovému manažmentu. Kapitola 6.1 vyžaduje posúdenie rizík informačnej bezpečnosti a ošetrenie rizík.

Program testovania podľa DORA by preto mal prepájať:

• podnikové služby a kritické alebo dôležité funkcie,
• aktíva IKT, údaje a závislosti od tretích strán,
• posúdenie rizík, vlastníkov rizík a plány ošetrenia rizík,
• typy testov, frekvenciu a spúšťače,
• autorizáciu, nezávislosť a pravidlá realizácie,
• zistenia, lehoty nápravy a opätovné testovanie,
• uchovávanie dôkazov a riadenie prístupu,
• reportovanie manažmentu a neustále zlepšovanie.

Pre menšie alebo menej rizikové finančné subjekty poskytuje Article 16 zjednodušený rámec riadenia rizík IKT. Zjednodušený však neznamená neformálny. Aj škálované programy stále potrebujú zdokumentované riadenie rizík IKT, monitorovanie, odolné systémy, identifikáciu zdrojov rizík IKT a anomálií, kľúčové závislosti od externých poskytovateľov IKT, opatrenia kontinuity a obnovy, pravidelné testovanie a využitie získaných poznatkov.

Inými slovami, DORA neodmeňuje objem testov. Odmeňuje riadené testovanie založené na riziku, ktoré preukazuje odolnosť služieb, na ktorých záleží najviac.

Čo patrí do programu testovania podľa DORA na rok 2026?

Zrelý program testovania podľa DORA by mal fungovať ako ročný katalóg testov. Nemal by sa obmedziť na jeden ročný penetračný test ani na hromadu exportov zo skenovania zraniteľností. Mal by zahŕňať základné aj pokročilé testy plánované podľa rizika, kritickosti služieb, regulačných povinností, závislostí od dodávateľov, významných zmien a predchádzajúcich zistení.

DORA Article 24 ustanovuje program testovania digitálnej prevádzkovej odolnosti. Article 25 opisuje rozsah testov vrátane posúdení a skenov zraniteľností, analýz otvorených zdrojov, posúdení bezpečnosti sietí, analýz medzier, preskúmaní fyzickej bezpečnosti, dotazníkov, skenovacích softvérových riešení, preskúmaní zdrojového kódu tam, kde je to uskutočniteľné, scenárových testov, testovania kompatibility, výkonnostného testovania, end-to-end testovania a penetračného testovania. Article 26 dopĺňa penetračné testovanie vedené hrozbami pre finančné subjekty určené príslušnými orgánmi.

Pre väčšinu organizácií je praktický katalóg postavený na štyroch rodinách testovania.

Politika bezpečnostného testovania a cvičení red teamu od Clarysec poskytuje pre tento katalóg silnú politickú oporu:

“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í skúsenými testermi na identifikáciu zložitý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 na otestovanie detekčných a reakčných schopností organizácie ako celku.”

Rovnaká politika vyžaduje pravidelné plánovanie:

“Harmonogram testovania: Organizácia musí vykonávať bezpečnostné testovanie podľa pravidelného harmonogramu. Kľúčové systémy prístupné z internetu a kritické interné aplikácie musia absolvovať penetračné testovanie aspoň raz ročne. Vysoko rizikové zmeny, napríklad nasadenie nového kritického systému alebo významné upgrady, vyžadujú ad hoc testovanie pred spustením do produkčného prostredia a/alebo krátko po ňom.”

Pre DORA je to kľúčové. Statický ročný plán nestačí, ak subjekt nasadzuje novú platobnú bránu, migruje kľúčový systém do cloudového prostredia, mení poskytovateľa riadených služieb alebo uvoľňuje nový tok autentifikácie zákazníkov. Vysoko riziková zmena musí spustiť dodatočné testovanie.

Vytvorte ročný katalóg testov ako jediný zdroj pravdy

Najúčinnejším spôsobom, ako splniť DORA a ISO/IEC 27001:2022, je vytvoriť jeden riadený ročný katalóg testov. Môže byť v GRC platforme, tiketovacom pracovnom toku alebo v riadenom tabuľkovom prehľade. Formát je menej dôležitý než sledovateľnosť.

Každý test by mal zodpovedať päť auditných otázok:

1. Ktorá služba, aktívum, dodávateľ, aplikácia alebo proces boli testované?
2. Ktoré riziko, povinnosť alebo požiadavka kontroly test spustili?
3. Kto test autorizoval a vykonal?
4. Aké zistenia boli identifikované, akceptované, napravené alebo odložené?
5. Aké dôkazy preukazujú, že test prebehol a výsledok bol preskúmaný?

Praktický katalóg v štýle Clarysec obsahuje tieto polia.

Politika monitorovania auditov a súladu pre SME od Clarysec poskytuje stručné pravidlo správy a riadenia, ktoré do tejto štruktúry zapadá:

“Každý audit musí mať definovaný rozsah, ciele, zodpovedný personál a požadované dôkazy.”

Hoci je pravidlo napísané pre audity, rovnaký princíp sa má uplatniť na testy odolnosti. Ak skenovanie zraniteľností, stolové cvičenie, simulácia prepnutia na záložné riešenie alebo penetračný test nemajú definovaný rozsah, cieľ, vlastníka a požadované dôkazy, budú slabé pri kontrole podľa DORA aj pri audite ISO.

Rovnaká politika uvádza:

“Dôkazy musia byť uchovávané najmenej dva roky alebo dlhšie, ak to vyžaduje certifikácia alebo zmluvy s klientmi.”

Pre finančné subjekty regulované DORA a poskytovateľov IKT by sa dva roky mali považovať za minimum. Zmluvné povinnosti, očakávania dohľadu, certifikačné cykly a vyšetrovania incidentov môžu vyžadovať dlhšie uchovávanie.

Mapujte typy testov DORA na dôkazy ISO 27001

Sila integrovaného programu spočíva v tom, že jeden test môže pokryť viacero povinností. Kľúčom je správne označovať dôkazy a prepájať ich s ISMS.

Zenith Blueprint to vysvetľuje vo fáze Audit, preskúmanie a zlepšovanie, krok 24:

“Vaše SoA má byť konzistentné s registrom rizík a plánom ošetrenia rizík. Dôkladne overte, že každá kontrola, ktorú ste vybrali ako ošetrenie rizika, je v SoA označená ako „uplatniteľná“.”

Pri programe testovania podľa DORA sa katalóg testov stáva mostom medzi ošetrením rizík a prevádzkovými dôkazmi. Vyhlásenie o uplatniteľnosti nemá uvádzať, že kontrola je uplatniteľná, ak sú testovacie dôkazy niekde inde, bez mapovania a bez riadenia.

Táto tabuľka pomáha CISO odpovedať na častú otázku CEO: „Stačia naše penetračné testy a skeny zraniteľností podľa ISO pre DORA?“

Odpoveď znie: môžu byť súčasťou súladu s DORA, ale iba vtedy, ak sú založené na riziku, prepojené s kritickými alebo dôležitými funkciami, riadené politikou, sledované až po nápravu a reportované manažmentu.

Posúdenia zraniteľností: priebežné dôkazy, nie iba výstup zo skenera

Posúdenie zraniteľností je často najjednoduchšou testovacou aktivitou na spustenie a zároveň najjednoduchšou na nesprávne zvládnutie. Mnohé organizácie dokážu predložiť správy zo skenovania. Menej organizácií dokáže preukázať, že skeny pokrývajú správne aktíva, prioritizujú kritické služby, vedú k včasnej náprave a vstupujú do rozhodnutí o ošetrení rizík.

Politika riadenia zraniteľností a záplat pre SME od Clarysec začína správnym cieľom:

“Včas a konzistentne identifikovať a posudzovať známe zraniteľnosti naprieč všetkými IT aktívami.”

Pre DORA to podporuje identifikáciu zdrojov rizík IKT, odolné a aktualizované systémy, monitorovanie, detekciu anomálií a neustále zlepšovanie. Pre ISO/IEC 27001:2022 sa to priamo mapuje na 8.8 Riadenie technických zraniteľností a zároveň sa opiera o 5.9 Inventár informácií a ďalších súvisiacich aktív, 8.16 Monitorovacie činnosti a 8.32 Riadenie zmien.

Silný záznam posúdenia zraniteľností má obsahovať:

• stav inventára aktív použitý na určenie rozsahu,
• dátum skenovania, nástroj a autentifikovanú alebo neautentifikovanú metódu,
• vylúčenia a obchodné odôvodnenie,
• zistenia podľa závažnosti, zneužiteľnosti a podnikovej služby,
• mapovanie na kritické alebo dôležité funkcie a typy údajov,
• odkazy na tikety a vlastníka rizika,
• SLA nápravy a lehotu plnenia,
• výsledok opätovného testovania,
• výnimky so schválením zvyškového rizika.

Zenith Controls pozicionuje 8.8 Riadenie technických zraniteľností ako kľúčovú oblasť dôkazov pre identifikáciu, posúdenie, prioritizáciu a sledovanie nápravy. Zároveň ukazuje, prečo audítori testujú aj nadväzujúce procesy. Ak je inventár aktív neúplný, pokrytie zraniteľností je neúplné. Ak sa obchádza riadenie zmien, nasadenie záplat môže vytvoriť nové prevádzkové riziko. Ak je monitorovanie slabé, pokusy o zneužitie nemusia byť zistené.

Scenárové testy: preukážte rozhodovanie pred skutočným incidentom

Scenárové testy sú miestom, kde sa prevádzková odolnosť stáva viditeľnou pre vrcholové vedenie. Stolové cvičenie ransomvérového útoku, simulácia výpadku cloudového regiónu, cvičenie kompromitácie privilegovaného prístupu alebo scenár zlyhania kritického poskytovateľa IKT odhalí slabiny, ktoré sken odhaliť nedokáže.

DORA Articles 17 až 20 vyžadujú formálny životný cyklus incidentov súvisiacich s IKT: zistiť, riadiť, oznámiť, zaznamenať, monitorovať, riešiť, vykonať následné činnosti, zdokumentovať koreňovú príčinu, napraviť, klasifikovať závažnosť, priradiť roly, eskalovať významné incidenty a reportovať v požadovaných fázach. Ak sú dotknuté finančné záujmy klientov, klienti musia byť informovaní bez zbytočného odkladu.

NIS2 má podobnú naliehavosť pre subjekty v rozsahu pôsobnosti vrátane včasného varovania, oznámenia, priebežného reportovania a záverečného reportovania. Pre finančné subjekty v rozsahu pôsobnosti je DORA odvetvovo špecifickým právnym aktom pre rovnocenné povinnosti riadenia rizík kybernetickej bezpečnosti a reportovania. Poskytovatelia IKT, SaaS platformy, MSP a MSSP si však stále musia overiť, či priamo spadajú do rozsahu NIS2 alebo sú zmluvne zapojení do uisťovania podľa DORA regulovanými klientmi.

Zenith Blueprint, fáza Kontroly v praxi, krok 23, poskytuje praktický model dôkazov:

“Vyberte nedávnu udalosť alebo vykonajte stolové cvičenie na overenie svojho plánu. Zachyťte a zalogujte všetky rozhodnutia, roly a komunikáciu (5.26) a aktualizujte plán o získané poznatky (5.27).”

Scenárový test DORA má vytvárať záznamy vhodné na audit, nie iba poznámky zo stretnutia:

• opis scenára a ciele,
• účastníkov a roly vrátane právneho oddelenia, komunikácie, IT, SOC, vlastníka podnikovej služby a kontaktov dodávateľov,
• časovú os vložených udalostí a rozhodnutí,
• rozhodnutie o klasifikácii a analýzu prahových hodnôt reportovania,
• návrhy internej a externej komunikácie,
• opatrenia na zachovanie dôkazov,
• získané poznatky,
• vlastníkov opatrení a lehoty plnenia,
• aktualizované postupy incidentov, kontinuity alebo komunikácie.

Politika kontinuity činností a obnovy po havárii pre SME od Clarysec posilňuje očakávanie ročného testovania:

“Organizácia musí aspoň raz ročne testovať svoje schopnosti BCP aj DR. Testy musia zahŕňať:”

Katalóg testovania má túto povinnosť premeniť na konkrétne cvičenia, ako je stolové cvičenie krízového riadenia, test obnovy zo záloh, test prepnutia cloudového prostredia na záložné riešenie, test kontaktného stromu a simulácia narušenia dodávateľa.

Testy výkonu, kapacity a obnovy: zanedbávané dôkazy odolnosti

Výkonnostné testovanie sa často považuje za technickú záležitosť technického tímu. Pod DORA sa stáva dôkazom odolnosti.

Obchodná platforma, platobná služba, systém spracovania poistných udalostí, platforma identít alebo zákaznícky portál nepotrebujú kybernetický útok na to, aby zlyhali voči zákazníkom. Vyčerpanie kapacity, zahltenie frontov, úzke miesta databázy, nesprávne nakonfigurované automatické škálovanie alebo nefunkčné prepnutie na záložné riešenie môžu vytvoriť rovnaké prevádzkové narušenie ako bezpečnostný incident.

Príloha A ISO/IEC 27001:2022, 8.6 Riadenie kapacity, je primárnou kotvou. Dôkazy môžu zahŕňať záťažové testovanie, stresové testovanie, testovanie degradácie služby, overenie prahových hodnôt infraštruktúry, testy obnovy zo záloh a simulácie prepnutia na záložné riešenie.

Dobrý záznam výkonnostného a kapacitného testu má zachytiť:

• referenčné predpoklady bežnej a špičkovej záťaže,
• testované kritické transakčné cesty,
• testované limity infraštruktúry a cloudu,
• monitorovacie panely a prahové hodnoty upozornení,
• režimy zlyhania, napríklad zahltenie frontu alebo úzke miesto databázy,
• relevantnosť RTO a RPO tam, kde sa testuje prepnutie na záložné riešenie alebo obnova,
• dopad na podnikanie pri prekročení prahových hodnôt,
• nápravné opatrenia, rozhodnutia o škálovaní alebo zmeny architektúry,
• akceptáciu zvyškového kapacitného rizika manažmentom.

Zenith Blueprint, krok 23, prepája očakávania obnovy s dôkazmi:

“Overte, že cieľové časy obnovy (RTO) a cieľové body obnovy (RPO) pre kritické systémy sú zosúladené s očakávaniami kontinuity činností (5.30). Vykonajte aspoň jeden technický test obnovy alebo simuláciu prepnutia na záložné riešenie a zdokumentujte výsledky.”

To je rozdiel medzi tvrdením „máme zálohy“ a preukázaním, že kritická služba bola obnovená v dohodnutej tolerancii, so zdokumentovanými výsledkami a viditeľnosťou pre manažment.

Penetračné testovanie a red teaming: silné dôkazy potrebujú silné riadenie

Penetračné testovanie je veľmi hodnotný dôkaz, ale nesie aj prevádzkové riziko. Nedostatočne riadené testovanie môže ovplyvniť produkčné systémy, sprístupniť citlivé údaje, spustiť nekontrolované alarmy, vytvoriť právne problémy alebo narušiť zákazníkov.

Politika požiadaviek na bezpečnosť aplikácií pre SME stanovuje jasnú bránu pred vydaním:

“Pred nasadením musia všetky aplikácie absolvovať bezpečnostné testovanie na overenie vyššie uvedených základných funkcií.”

Pri kritických aplikáciách by to malo vstupovať do katalógu DORA ako bezpečnostné testovanie predprodukčného prostredia, validácia po spustení do produkčného prostredia pri vysoko rizikových zmenách a pravidelné penetračné testovanie podľa expozície a kritickosti.

Politika bezpečnostného testovania a cvičení red teamu posilňuje reťazec nápravy:

“Náprava zistení: Všetky identifikované zraniteľnosti alebo slabiny musia byť zdokumentované v správe o zisteniach s klasifikáciou závažnosti. Po prijatí správy sú vlastníci systémov zodpovední za vytvorenie plánu nápravy s lehotami plnenia; napríklad kritické zistenia musia byť napravené do 30 dní a zistenia s vysokou závažnosťou do 60 dní v súlade s politikou riadenia zraniteľností a záplat organizácie. STC sleduje priebeh nápravy. Opätovné testovanie sa musí vykonať na potvrdenie, že kritické problémy boli vyriešené alebo primerane zmiernené.”

Rovnaká politika definuje očakávania reportovania:

“Reportovanie: Po ukončení každého testu musí byť vydaná formálna správa. Pri penetračnom testovaní musí správa obsahovať súhrn pre manažment, metodiku a podrobné zistenia s podpornými dôkazmi a odporúčaniami.”

Zenith Blueprint, krok 21, zdôrazňuje aj ochranu počas auditu a testovania:

“Žiadny test ani audit sa nemá začať bez zdokumentovaného schválenia od vlastníkov systémov alebo príslušných zainteresovaných strán.”

Pravidlá realizácie, testovacie okná, núdzové kontakty, dočasný prístup, nakladanie s údajmi, logovanie, postupy vrátenia zmien a právne schválenia nie sú byrokracia. Sú to ochranné opatrenia odolnosti.

Zapojte externých poskytovateľov IKT skôr, než test zlyhá

DORA robí z rizika externých poskytovateľov IKT centrálnu otázku odolnosti. Article 28 vyžaduje, aby finančné subjekty riadili riziko externých poskytovateľov IKT v rámci rámca riadenia rizík IKT, zostali zodpovedné pri využívaní služieb IKT, viedli register informácií, oznamovali určité zmluvné usporiadania, vykonávali predzmluvné posúdenia a využívali poskytovateľov spĺňajúcich primerané štandardy informačnej bezpečnosti. Articles 29 a 30 sa venujú riziku koncentrácie, subdodávkam, obnove údajov, zmluvným ochranám, úrovniam služieb, podpore pri incidentoch, právam na audit, testovaniu núdzových plánov poskytovateľov, účasti na testovaní tam, kde je relevantná, a plánom ukončenia.

Príloha A ISO/IEC 27001:2022 poskytuje podporné kontroly dodávateľov vrátane 5.19 Informačná bezpečnosť vo vzťahoch s dodávateľmi, 5.20 Riešenie informačnej bezpečnosti v dodávateľských zmluvách, 5.21 Riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT, 5.22 Monitorovanie, preskúmanie a riadenie zmien služieb dodávateľov a 5.23 Informačná bezpečnosť pri používaní cloudových služieb.

Katalóg testov DORA má identifikovať, ktoré testy vyžadujú účasť dodávateľa alebo dôkazy od dodávateľa. Príklady zahŕňajú:

• predpoklady prepnutia cloudového poskytovateľa na záložné riešenie,
• eskaláciu riadeného SOC a zachovanie dôkazov,
• komunikáciu incidentu platformy core banking,
• scenár výpadku spracovateľa platieb,
• test obnovy poskytovateľa identít,
• vyhlásenia dodávateľa SaaS k penetračnému testovaniu,
• posúdenie dopadu reťazca kritických subdodávateľov.

Program, ktorý vylučuje kritických poskytovateľov IKT, neobstojí v teste reality. Služba smerovaná na zákazníka môže byť vaša, ale závislosť odolnosti môže byť v cloudovom regióne, outsourcovanom SOC, poskytovateľovi identít, dodávateľovi softvéru, spracovateľovi platieb alebo dátovom centre.

Mapovanie krížového súladu: jeden súbor dôkazov, mnoho povinností

Dobre navrhnutý program testovania podľa DORA znižuje auditnú záťaž. Rovnaké dôkazy môžu podporiť DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 a preskúmania správy a riadenia podľa COBIT 2019, ak sú správne označené, uchovávané a reportované.

Na GDPR sa nesmie zabudnúť. Ak testy odolnosti zahŕňajú osobné údaje, logy, záznamy zákazníkov, údaje identít, záznamy HR, biometrické zabezpečenie alebo osobitné kategórie údajov, organizácia musí rešpektovať zásady GDPR vrátane zákonnosti, spravodlivosti, transparentnosti, minimalizácie údajov, obmedzenia uchovávania, integrity, dôvernosti a zodpovednosti. Kópie testovacích údajov, exportované logy a dôkazy z penetračných testov sa môžu stať úložiskami regulovaných údajov. Program testovania má definovať, kto k nim môže pristupovať, ako dlho sa uchovávajú a ako sa bezpečne likvidujú.

Ako budú audítori testovať ten istý program

Dohľadový orgán DORA, audítor ISO, posudzovateľ podľa NIST, hodnotiteľ COBIT a klientsky audítor môžu skúmať rovnaké dôkazy cez rôzne optiky.

Zenith Controls je tu užitočný ako kompas krížového súladu. Pri testovaní podľa DORA Clarysec zdôrazňuje 5.35 Nezávislé preskúmanie informačnej bezpečnosti, 8.8 Riadenie technických zraniteľností a 8.6 Riadenie kapacity ako obzvlášť dôležité kotvy prílohy A ISO/IEC 27001:2022. Pomáhajú vlastníkom kontrol prepájať testovanie s nezávislým uistením, riešením zraniteľností a prevádzkovou kapacitou.

Politika informačnej bezpečnosti od Clarysec podporuje aj auditnú stopu:

“Vlastníci kontrol musia uchovávať výsledky testov, logy a záznamy o preskúmaní na podporu pravidelných auditov.”

Táto veta by sa mala stať prevádzkovým pravidlom. Každý vlastník testu má vedieť, čo uchovávať, kde to uchovávať, ako to chrániť a ako to súvisí s dôkazmi o rizikách a kontrolách.

Vytvorte dôkazový balík DORA na ISO za jeden týždeň

Finančný subjekt alebo poskytovateľ IKT môže dosiahnuť významný pokrok za päť pracovných dní.

Deň 1: Definujte rozsah a kritickosť

Použite uvažovanie podľa kapitol 4.1 až 4.4 ISO/IEC 27001:2022. Identifikujte zainteresované strany, regulačné povinnosti, zmluvné povinnosti, rozhrania a závislosti. Uveďte podnikové služby, kritické alebo dôležité funkcie, kľúčové aktíva, typy údajov a poskytovateľov IKT.

Výstup: register rozsahu testovania DORA.

Deň 2: Vytvorte ročný katalóg testov

Použite štyri rodiny testov: zraniteľnosti, scenáre, výkon a penetrácia. Pre každú službu definujte, ktoré testy sa uplatňujú, ich frekvenciu, vlastníka, úroveň nezávislosti a spúšťač. Zahrňte spúšťače vysoko rizikových zmien.

Výstup: katalóg testovania digitálnej prevádzkovej odolnosti na rok 2026.

Deň 3: Mapujte kontroly a povinnosti

Mapujte každý test na prílohu A ISO/IEC 27001:2022, register rizík, SoA, články DORA, povinnosti dodávateľov a relevantné položky Zenith Controls. Napríklad mesačné externé skeny zraniteľností sa mapujú na 8.8 Riadenie technických zraniteľností, ošetrenie rizík, monitorovanie, riadenie rizík IKT podľa DORA a výsledky zraniteľností podľa NIST CSF.

Výstup: matica mapovania kontrol.

Deň 4: Štandardizujte priečinky dôkazov

Vytvorte riadenú štruktúru dôkazov:

• 01 Plán a autorizácia
• 02 Rozsah a pravidlá realizácie
• 03 Surové výsledky
• 04 Záverečná správa
• 05 Register zistení
• 06 Tikety nápravy
• 07 Dôkazy z opätovného testovania
• 08 Reportovanie manažmentu
• 09 Získané poznatky a aktualizácie politík

Výstup: úložisko dôkazov s pravidlami uchovávania.

Deň 5: Preskúmajte zistenia a reportovanie

Konsolidujte otvorené zistenia podľa závažnosti, služby, vlastníka rizika a lehoty plnenia. Identifikujte omeškanú nápravu, akceptované riziká a medzery v opätovnom testovaní. Pripravte prehľad pre riadiaci orgán, ktorý ukazuje pokrytie testovania, významné zistenia, omeškané opatrenia, problémy tretích strán a zvyškové riziko.

Výstup: prehľad testovania DORA a ISO pripravený pre predstavenstvo.

Časté úskalia programu testovania podľa DORA

Najčastejším zlyhaním nie je nedostatok testovania. Je ním nedostatok správy a riadenia.

Sledujte najmä tieto problémy:

• penetračné testy sa vykonávajú ročne, ale zistenia sa nesledujú až po uzavretie,
• skeny zraniteľností bežia často, ale kritické aktíva chýbajú v rozsahu,
• stolové cvičenia sa uskutočnia, ale neexistuje záznam rozhodnutí ani akčný plán získaných poznatkov,
• testy obnovy zo záloh sú dokončené, ale nie sú mapované na RTO a RPO,
• záťažové testy vykonáva technický tím, ale nereportujú sa tímu pre riziká ani tímu pre súlad,
• poskytovatelia IKT sú vylúčení zo scenárových testov a testov obnovy,
• dôkazy sú uložené v osobných priečinkoch, chatových vláknach alebo neriadených úložiskách,
• reporty pre predstavenstvo sa sústreďujú na počty aktivít namiesto nevyriešeného rizika odolnosti,
• SoA uvádza, že kontrola sa uplatňuje, ale neexistuje testovací dôkaz,
• testovanie vytvára produkčné riziko, pretože autorizácia a hranice nie sú jasné.

Každá medzera je riešiteľná. Nápravou nie je viac náhodného testovania. Nápravou je jeden riadený program, ktorý prepája riziko, testovaciu aktivitu, nápravu, dôkazy a dohľad manažmentu.

Čo má predstavenstvo skutočne vidieť

DORA robí z odolnosti IKT zodpovednosť riadiaceho orgánu. Užitočná správa pre predstavenstvo nemá obsahovať každé technické zistenie. Má odpovedať na otázku, či je organizácia dostatočne odolná vzhľadom na svoj apetít na riziko a toleranciu narušenia.

Silný štvrťročný alebo polročný report obsahuje:

• pokrytie testovania voči kritickým alebo dôležitým funkciám,
• dokončené verzus plánované testy,
• kritické a vysoké zistenia podľa služby,
• omeškanú nápravu podľa vlastníka,
• mieru úspešnosti opätovného testovania,
• zistenia súvisiace s dodávateľmi a obavy z koncentrácie,
• poznatky zo scenárových testov ovplyvňujúce krízové alebo incidentné plány,
• kapacitné riziká voči rastu organizácie a špičkovým obdobiam,
• zvyškové riziká vyžadujúce akceptáciu manažmentom,
• rozpočtové, zdrojové alebo nástrojové obmedzenia.

Tento report sa stáva vstupom do preskúmania manažmentom podľa ISO, dôkazom správy a riadenia podľa DORA a praktickým rozhodovacím nástrojom.

Od rozptýlených testov k strategickej odolnosti

Pôvodným problémom CISO nebolo, že testovanie chýbalo. Organizácia mala skeny, stolové cvičenia, záťažové reporty a PDF správy z penetračných testov. Problém bol, že tieto aktivity ešte nevytvárali jeden súvislý príbeh dôkazov.

Jednotný program testovania podľa DORA a ISO/IEC 27001:2022 to mení. Posúdenie rizík riadi katalóg. Katalóg riadi autorizované testovanie. Testovanie vytvára zistenia. Zistenia riadia nápravu a opätovné testovanie. Výsledky vstupujú do reportovania manažmentu. Získané poznatky aktualizujú politiky, postupy, zmluvy a kontroly.

Tak sa zo záťaže súladu stáva strategická schopnosť.

Clarysec pomáha organizáciám vyhnúť sa paralelným programom súladu. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 a COBIT 2019 nepotrebujú samostatné svety dôkazov. Potrebujú jeden riadený prevádzkový model, ktorý možno prezentovať cez rôzne auditné optiky.

Náš prístup kombinuje:

• Zenith Blueprint pre fázovanú implementáciu ISO a pripravenosť na audit,
• Zenith Controls pre mapovanie krížového súladu naprieč kontrolami, rámcami a auditnými očakávaniami,
• podnikové a SME politiky pre bezpečnostné testovanie, monitorovanie auditov, riadenie zraniteľností, bezpečnosť aplikácií, kontinuitu a informačnú bezpečnosť,
• praktické registre, štruktúry dôkazov a šablóny reportovania manažmentu.

Ak sú vaše dôkazy o testovaní DORA na rok 2026 rozptýlené medzi skenovacími nástrojmi, priečinkami technického tímu, poznámkami zo stolových cvičení a PDF správami z penetračných testov, teraz je čas ich konsolidovať.

Začnite jedným ročným katalógom testov mapovaným na ošetrenie rizík podľa ISO/IEC 27001:2022, vaše SoA, kritické alebo dôležité funkcie, externých poskytovateľov IKT a reportovanie manažmentu. Potom použite Zenith Blueprint, Zenith Controls a súbor politík Clarysec na premenu katalógu na obhájiteľné auditné dôkazy.

Clarysec vám pomôže navrhnúť program, mapovať kontroly, štruktúrovať dôkazový balík a pripraviť report odolnosti na úrovni predstavenstva skôr, než príde ďalšia požiadavka dohľadu.