Program testiranja DORA: preslikava testov v ISO 27001

Februar 2026 je. CISO srednje velike plačilne institucije ima čez dva dni sejo upravnega odbora, čez šest tednov nadzorno presojo ISO/IEC 27001:2022, v nabiralniku za skladnost pa čaka zahteva pristojnega organa po DORA.

Regulator ne zahteva bleščeče kibernetske strategije. Zahteva je praktična:

• Predložite program testiranja digitalne operativne odpornosti za leto 2026.
• Pokažite, kateri testi pokrivajo kritične ali pomembne funkcije.
• Dokažite, kako se ugotovitve odpravljajo in ponovno testirajo.
• Predložite dokazila o nadzoru upravljalnega organa.
• Pojasnite, kako so vključeni zunanji ponudniki IKT.
• Predložite evidence za ocene ranljivosti, scenarijske teste, testiranje zmogljivosti in kapacitet ter penetracijsko testiranje.

CISO odpre štiri mape. Skeniranja ranljivosti so v sistemu SOC za upravljanje zahtevkov. Zapisi namiznih vaj so na skupnem pogonu. Rezultate obremenitvenih testov upravlja inženiring. Poročila o penetracijskih testih so v omejenem repozitoriju pravne službe. Sledenje odpravi pomanjkljivosti je razdeljeno med Jira, e-pošto in preglednico, pripravljeno za lansko presojo ISO.

Nič od tega ni izmišljeno. Velik del predstavlja kakovostno opravljeno delo. Vendar to še ni upravljan program testiranja digitalne operativne odpornosti po DORA. To je zbirka testov.

Ta razlika je leta 2026 pomembna. DORA se uporablja od 17. januarja 2025 in vzpostavlja enoten okvir EU za digitalno operativno odpornost na področjih upravljanja tveganj IKT, poročanja o incidentih, testiranja odpornosti, izmenjave informacij o kibernetskih grožnjah in ranljivostih, upravljanja tveganj tretjih oseb na področju IKT, pogodbenih zahtev ter nadzora kritičnih zunanjih ponudnikov IKT. Zajema širok nabor finančnih subjektov, vključno s kreditnimi institucijami, plačilnimi institucijami, investicijskimi podjetji, ponudniki storitev v zvezi s kriptosredstvi, zavarovalnicami in drugimi reguliranimi subjekti. DORA deluje tudi kot sektorski pravni akt Unije za finančne subjekte, ki bi sicer spadali pod enakovredne obveznosti kibernetske varnosti po NIS2.

Praktično vprašanje za upravne odbore, CISO, vodje skladnosti in ponudnike IKT ni več, ali se testiranje izvaja. Vprašanje je, ali je testiranje načrtovano, temelji na tveganjih, je podprto z dokazili, vodi v odpravo pomanjkljivosti, se pregleduje in ga je mogoče ponovno uporabiti v okviru DORA in ISO/IEC 27001:2022.

Operativni model Clarysec je zasnovan prav za ta problem. Z uporabo Zenith Blueprint: 30-koračni načrt presojevalca, nabora politik Clarysec, usklajenega z ISO, in Zenith Controls: vodnik za navzkrižno skladnost lahko organizacije razpršene dejavnosti odpornosti pretvorijo v nadzorovan letni katalog testov, ki zadosti nadzornikom, presojevalcem, strankam in upravnim odborom.

Zakaj DORA testiranje pretvori v vprašanje upravljanja

DORA je izrecna glede odgovornosti vodstva. Article 5 odgovornost za upravljanje tveganj IKT nalaga upravljalnemu organu. Article 6 zahteva zanesljiv, celovit in dobro dokumentiran okvir upravljanja tveganj IKT, vključen v splošni sistem upravljanja tveganj organizacije. Article 4 dodaja sorazmernost, kar pomeni, da se zahteve uporabljajo glede na velikost, celotni profil tveganja ter naravo, obseg in kompleksnost storitev, dejavnosti in poslovanja.

Zato je testiranje digitalne operativne odpornosti več kot tehnična naloga. Postane dokazilo, da upravljalni organ razume tveganja, je odobril strategijo, prejema vsebinsko ustrezno poročanje in usmerja odpravo pomanjkljivosti.

ISO/IEC 27001:2022 uporablja podobno logiko sistema upravljanja. Točke 4.1 do 4.4 zahtevajo, da organizacija razume kontekst, zainteresirane strani, zakonske in pogodbene obveznosti, obseg, vmesnike in odvisnosti. Točke 5.1 do 5.3 zahtevajo voditeljstvo, usklajenost politike, vire, komunikacijo, dodeljene odgovornosti in poročanje najvišjemu vodstvu. Točka 6.1 zahteva oceno tveganj informacijske varnosti in obravnavo tveganj.

Program testiranja DORA mora zato povezovati:

• poslovne storitve ter kritične ali pomembne funkcije,
• sredstva IKT, podatke in odvisnosti od tretjih oseb,
• oceno tveganj, lastnike tveganj in načrte obravnave tveganj,
• vrste testov, pogostost in sprožilce,
• odobritev, neodvisnost in pravila izvajanja,
• ugotovitve, roke za odpravo pomanjkljivosti in ponovno testiranje,
• hrambo dokazil in nadzor dostopa,
• poročanje vodstvu in nenehno izboljševanje.

Za manjše finančne subjekte ali finančne subjekte z nižjim tveganjem Article 16 določa poenostavljen okvir upravljanja tveganj IKT, vendar poenostavljeno ne pomeni neformalno. Tudi prilagojeni programi še vedno potrebujejo dokumentirano upravljanje tveganj IKT, spremljanje, odporne sisteme, identifikacijo virov tveganj IKT in anomalij, ključne odvisnosti od zunanjih ponudnikov IKT, ukrepe za neprekinjeno poslovanje in obnovitev, redno testiranje ter pridobljene izkušnje.

Z drugimi besedami, DORA ne nagrajuje obsega testov. Nagrajuje upravljano, na tveganjih temelječe testiranje, ki dokazuje odpornost storitev, ki so najpomembnejše.

Kaj sodi v program testiranja DORA za leto 2026?

Zrel program testiranja DORA mora delovati kot letni katalog testov. Ne sme biti omejen na en letni penetracijski test ali zbirko izvozov skeniranj ranljivosti. Vključevati mora osnovne in napredne teste, načrtovane glede na tveganje, kritičnost storitev, regulativne obveznosti, odvisnosti od dobaviteljev, večje spremembe in pretekle ugotovitve.

DORA Article 24 vzpostavlja program testiranja digitalne operativne odpornosti. Article 25 opisuje nabor testov, vključno z ocenami in skeniranji ranljivosti, analizami odprte kode, ocenami varnosti omrežja, analizami vrzeli, pregledi fizične varnosti, vprašalniki, programskimi rešitvami za skeniranje, pregledi izvorne kode, kadar je izvedljivo, scenarijskimi testi, testiranjem združljivosti, testiranjem zmogljivosti, testiranjem od konca do konca in penetracijskim testiranjem. Article 26 dodaja penetracijsko testiranje na podlagi groženj za finančne subjekte, ki jih določijo pristojni organi.

Za večino organizacij je praktični katalog zgrajen okoli štirih družin testiranja.

Clarysecova Politika varnostnega testiranja in red teaminga zagotavlja trdno politično sidro za ta katalog:

“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 določenih sistemov ali aplikacij s strani usposobljenih preizkuševalcev za identifikacijo kompleksnih pomanjkljivosti; in (c) vaje red team, ki obsegajo scenarijske simulacije resničnih napadov, vključno s socialnim inženiringom ter drugimi taktikami, za preverjanje zmožnosti zaznavanja in odzivanja organizacije kot celote.”

Ista politika zahteva redno načrtovanje:

“Razpored testiranja: Organizacija mora izvajati varnostno testiranje po rednem razporedu. Ključni sistemi, izpostavljeni internetu, in kritične interne aplikacije morajo biti predmet penetracijskega testiranja vsaj enkrat letno. Spremembe z visokim tveganjem, kot je uvedba novega kritičnega sistema ali večje nadgradnje, zahtevajo ad hoc testiranje pred prehodom v produkcijo in/ali kmalu po njem.”

To je za DORA ključno. Statičen letni načrt ne zadostuje, če subjekt uvede nov plačilni prehod, preseli ključni sistem v oblak, zamenja ponudnika upravljanih storitev ali izda nov tok avtentikacije strank. Sprememba z visokim tveganjem mora sprožiti dodatno testiranje.

Letni katalog testov vzpostavite kot enotni vir resnice

Najbolj učinkovit način za izpolnjevanje zahtev DORA in ISO/IEC 27001:2022 je vzpostavitev enega nadzorovanega letnega kataloga testov. Lahko je v platformi GRC, delovnem toku sistema za upravljanje zahtevkov ali nadzorovani preglednici. Oblika je manj pomembna od sledljivosti.

Vsak test mora odgovoriti na pet presojnih vprašanj:

1. Katera storitev, sredstvo, dobavitelj, aplikacija ali proces je bil testiran?
2. Katero tveganje, obveznost ali zahteva kontrole je sprožila test?
3. Kdo je test odobril in izvedel?
4. Katere ugotovitve so bile identificirane, sprejete, odpravljene ali odložene?
5. Katera dokazila potrjujejo, da je bil test izveden in da je bil rezultat pregledan?

Praktičen katalog v slogu Clarysec vključuje ta polja.

Clarysecova Politika spremljanja presoj in skladnosti za MSP vsebuje jedrnato pravilo upravljanja, ki ustreza tej strukturi:

“Vsaka presoja mora vključevati opredeljen obseg, cilje, odgovorne osebe in zahtevana dokazila.”

Čeprav je pravilo napisano za presoje, mora enako veljati za teste odpornosti. Če skeniranje ranljivosti, namizna vaja, simulacija preklopa na rezervno okolje ali penetracijski test nima opredeljenega obsega, cilja, lastnika in zahtevanih dokazil, bo šibek tako pri DORA kot pri presoji ISO.

Ista politika določa:

“Dokazila morajo biti hranjena najmanj dve leti ali dlje, kadar to zahtevajo certifikacija ali pogodbe s strankami.”

Za finančne subjekte in ponudnike IKT, regulirane po DORA, je treba dve leti obravnavati kot spodnjo mejo. Pogodbene obveznosti, pričakovanja nadzornih organov, certifikacijski cikli in preiskave incidentov lahko zahtevajo daljšo hrambo.

Preslikajte vrste testov DORA v dokazila ISO 27001

Moč integriranega programa je v tem, da lahko en test izpolni več obveznosti. Ključno je pravilno označiti dokazila in jih povezati z ISMS.

Zenith Blueprint to pojasni v fazi Presoja, pregled in izboljševanje, korak 24:

“Vaša SoA mora biti skladna z registrom tveganj in načrtom obravnave tveganj. Dvakrat preverite, da je vsaka kontrola, ki ste jo izbrali kot obravnavo tveganja, v SoA označena kot ‘Uporabna’.”

Pri programu testiranja DORA katalog testov postane most med obravnavo tveganj in operativnimi dokazili. Izjava o uporabljivosti ne sme navajati, da se kontrola uporablja, medtem ko dokazila o testiranju ležijo drugje, nepreslikana in neupravljana.

Ta tabela pomaga CISO odgovoriti na pogosto vprašanje generalnega direktorja: “Ali naši penetracijski testi ISO in skeniranja ranljivosti zadostujejo za DORA?”

Odgovor je: lahko so del skladnosti z DORA, vendar le, če temeljijo na tveganjih, so povezani s kritičnimi ali pomembnimi funkcijami, jih ureja politika, so spremljani skozi odpravo pomanjkljivosti in se o njih poroča vodstvu.

Ocene ranljivosti: neprekinjena dokazila, ne le izpis skeniranja

Ocena ranljivosti je pogosto najlažja testna dejavnost za izvedbo in najlažja za napačno upravljanje. Mnoge organizacije lahko pripravijo poročila o skeniranju. Manj jih lahko dokaže, da skeniranja pokrivajo prava sredstva, dajejo prednost kritičnim storitvam, sprožijo pravočasno odpravo pomanjkljivosti in podpirajo odločitve o obravnavi tveganj.

Clarysecova Politika upravljanja ranljivosti in popravkov za MSP se začne s pravim ciljem:

“Pravočasno in dosledno identificirati ter ocenjevati znane ranljivosti v vseh IT sredstvih.”

Za DORA to podpira identifikacijo virov tveganj IKT, odporne in posodobljene sisteme, spremljanje, zaznavanje anomalij in nenehno izboljševanje. Za ISO/IEC 27001:2022 se neposredno preslika na 8.8 Upravljanje tehničnih ranljivosti, hkrati pa se opira na 5.9 Popis informacij in drugih povezanih sredstev, 8.16 Dejavnosti spremljanja in 8.32 Upravljanje sprememb.

Močan zapis ocene ranljivosti mora vključevati:

• posnetek evidence sredstev, uporabljen za določanje obsega,
• datum skeniranja, orodje in avtenticirano ali neavtenticirano metodo,
• izključitve in poslovno utemeljitev,
• ugotovitve po resnosti, možnosti izkoriščanja in poslovni storitvi,
• preslikavo na kritične ali pomembne funkcije in vrste podatkov,
• reference zahtevkov in lastnika tveganja,
• SLA za odpravo pomanjkljivosti in rok zapadlosti,
• rezultat ponovnega testiranja,
• izjeme z odobritvijo preostalega tveganja.

Zenith Controls umešča 8.8 Upravljanje tehničnih ranljivosti kot ključno področje dokazil za identifikacijo, ocenjevanje, določanje prioritet in sledenje odpravi pomanjkljivosti. Pokaže tudi, zakaj bodo presojevalci preverjali povezane procese. Če je evidenca sredstev nepopolna, je nepopolna tudi pokritost ranljivosti. Če se obide upravljanje sprememb, lahko uvedba popravkov ustvari novo operativno tveganje. Če je spremljanje šibko, poskusi izkoriščanja morda ne bodo zaznani.

Scenarijski testi: dokažite odločanje pred resničnim incidentom

Scenarijski testi so točka, kjer operativna odpornost postane vidna izvršnemu vodstvu. Namizna vaja izsiljevalske programske opreme, simulacija izpada oblačne regije, vaja kompromitacije privilegiranega dostopa ali scenarij odpovedi kritičnega ponudnika IKT bo razkril pomanjkljivosti, ki jih skeniranje ne more.

DORA Articles 17 to 20 zahtevajo formalni življenjski cikel incidentov, povezanih z IKT: zaznati, upravljati, obvestiti, evidentirati, spremljati, obravnavati, izvajati nadaljnje ukrepe, dokumentirati temeljni vzrok, odpraviti pomanjkljivosti, razvrstiti resnost, dodeliti vloge, eskalirati večje incidente in poročati skozi zahtevane faze. Kadar so prizadeti finančni interesi strank, morajo biti stranke obveščene brez nepotrebnega odlašanja.

NIS2 določa podobno nujnost za subjekte v svojem področju uporabe, vključno z zgodnjim opozorilom, obveščanjem, vmesnim poročanjem in končnim poročanjem. Za finančne subjekte v področju uporabe je DORA sektorski pravni akt za enakovredne obveznosti upravljanja tveganj kibernetske varnosti in poročanja. Ponudniki IKT, platforme SaaS, MSP in MSSP morajo še vedno preveriti, ali so neposredno v področju uporabe NIS2 ali jih regulirane stranke pogodbeno vključijo v zagotavljanje zaupanja po DORA.

Zenith Blueprint, faza Kontrole v praksi, korak 23, podaja praktičen model dokazil:

“Izberite nedaven dogodek ali izvedite namizno vajo za preverjanje načrta. Zajemite in zabeležite vse odločitve, vloge in komunikacije (5.26) ter posodobite načrt s pridobljenimi izkušnjami (5.27).”

Scenarijski test DORA mora ustvariti preverljive zapise, ne le zapiskov sestanka:

• opis scenarija in cilje,
• udeležence in vloge, vključno s pravno službo, komuniciranjem, IT, SOC, lastnikom poslovnega procesa in kontakti dobaviteljev,
• časovnico vnosov in odločitev,
• odločitev o razvrstitvi in analizo pragov poročanja,
• osnutke notranjih in zunanjih komunikacij,
• ukrepe za ohranitev dokazil,
• pridobljene izkušnje,
• lastnike ukrepov in roke zapadlosti,
• posodobljene postopke za incidente, neprekinjeno poslovanje ali komuniciranje.

Clarysecova Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP utrjuje pričakovanje letnega testiranja:

“Organizacija mora vsaj enkrat letno testirati svoje zmogljivosti BCP in DR. Testi morajo vključevati:”

Katalog testiranja mora to obveznost pretvoriti v konkretne vaje, kot so namizna vaja kriznega upravljanja, test obnovitve varnostne kopije, test preklopa v oblaku, test seznama kontaktov in simulacija motnje pri dobavitelju.

Testi zmogljivosti, kapacitet in obnovitve: spregledana dokazila odpornosti

Testiranje zmogljivosti se pogosto obravnava kot inženirska zadeva. V okviru DORA postane dokazilo odpornosti.

Trgovalna platforma, plačilna storitev, sistem za odškodninske zahtevke, platforma identitet ali portal za stranke ne potrebuje kibernetskega napada, da odpove strankam. Izčrpanje kapacitet, zasičenost vrst, ozka grla v podatkovni bazi, napačno konfigurirano samodejno skaliranje ali pokvarjen preklop na rezervno okolje lahko povzročijo enako operativno motnjo kot varnostni incident.

ISO/IEC 27001:2022 Priloga A 8.6 Upravljanje kapacitet je primarno sidro. Dokazila lahko vključujejo obremenitveno testiranje, stresno testiranje, testiranje degradacije storitve, preverjanje infrastrukturnih pragov, teste obnovitve varnostnih kopij in simulacije preklopa na rezervno okolje.

Dober zapis testa zmogljivosti in kapacitet mora zajeti:

• izhodiščne predpostavke običajne in konične obremenitve,
• testirane kritične transakcijske poti,
• testirane infrastrukturne in oblačne omejitve,
• nadzorne plošče za spremljanje in pragove opozarjanja,
• načine odpovedi, kot so zasičenost vrst ali ozka grla v podatkovni bazi,
• relevantnost RTO in RPO, kadar se testira preklop ali obnovitev,
• poslovni vpliv ob preseženih pragovih,
• sanacijske ukrepe, odločitve o skaliranju ali spremembe arhitekture,
• sprejem preostalega tveganja kapacitet s strani vodstva.

Zenith Blueprint, korak 23, povezuje pričakovanja obnovitve z dokazili:

“Preverite, da so ciljni časi obnovitve (RTO) in ciljne točke obnovitve (RPO) za kritične sisteme usklajeni s pričakovanji neprekinjenega poslovanja (5.30). Izvedite vsaj en tehnični test obnovitve ali simulacijo preklopa na rezervno okolje in dokumentirajte rezultate.”

To je razlika med izjavo “imamo varnostne kopije” in dokazom, da je bila kritična storitev obnovljena znotraj dogovorjene tolerance, z dokumentiranimi rezultati in vidnostjo za vodstvo.

Penetracijsko testiranje in red teaming: močna dokazila potrebujejo močan nadzor

Penetracijsko testiranje je zelo dragoceno dokazilo, vendar prinaša tudi operativno tveganje. Slabo upravljano testiranje lahko vpliva na produkcijske sisteme, izpostavi občutljive podatke, sproži nenadzorovana opozorila, povzroči pravna vprašanja ali moti stranke.

Politika zahtev za varnost aplikacij za MSP določa jasno kontrolno točko za izdajo:

“Pred uvedbo morajo vse aplikacije opraviti varnostno testiranje za preverjanje zgoraj navedenih osnovnih funkcionalnosti.”

Za kritične aplikacije mora to napajati katalog DORA kot varnostno testiranje pred produkcijo, preverjanje po prehodu v produkcijo pri spremembah z visokim tveganjem in periodično penetracijsko testiranje glede na izpostavljenost in kritičnost.

Politika varnostnega testiranja in red teaminga krepi verigo odprave pomanjkljivosti:

“Odprava ugotovitev: Vse identificirane ranljivosti ali pomanjkljivosti morajo biti dokumentirane v poročilu o ugotovitvah z ocenami resnosti. Po prejemu poročila so lastniki sistemov odgovorni za pripravo načrta odprave pomanjkljivosti z roki zapadlosti; na primer, kritične ugotovitve morajo biti odpravljene v 30 dneh, ugotovitve z visoko resnostjo pa v 60 dneh, skladno s Politiko upravljanja ranljivosti in popravkov organizacije. STC mora spremljati napredek odprave pomanjkljivosti. Ponovno testiranje mora biti izvedeno za potrditev, da so kritične težave odpravljene ali ustrezno ublažene.”

Ista politika določa pričakovanja poročanja:

“Poročanje: Ob zaključku vsakega testa mora biti izdano formalno poročilo. Pri penetracijskem testiranju mora poročilo vključevati povzetek za vodstvo, metodologijo in podrobne ugotovitve s podpornimi dokazili in priporočili.”

Zenith Blueprint, korak 21, poudarja tudi zaščito med presojo in testiranjem:

“Noben test ali presoja se ne sme začeti brez dokumentirane odobritve lastnikov sistemov ali relevantnih zainteresiranih strani.”

Pravila izvajanja, testna okna, kontakti za nujne primere, začasni dostop, ravnanje s podatki, vodenje dnevnikov, postopki povrnitve in pravne odobritve niso birokracija. So varovalni ukrepi odpornosti.

Zunanje ponudnike IKT vključite, preden test odpove

DORA tveganje tretjih oseb na področju IKT postavlja v središče odpornosti. Article 28 zahteva, da finančni subjekti upravljajo tveganje tretjih oseb na področju IKT v okviru upravljanja tveganj IKT, ostanejo odgovorni pri uporabi storitev IKT, vzdržujejo register informacij, poročajo o določenih ureditvah, izvajajo predpogodbene presoje in uporabljajo ponudnike, ki izpolnjujejo ustrezne standarde informacijske varnosti. Articles 29 and 30 obravnavata tveganje koncentracije, podizvajanje, obnovitev podatkov, pogodbena varovala, ravni storitev, pomoč pri incidentih, pravice do revizije, testiranje rezervnih ureditev ponudnikov, sodelovanje pri testiranju, kadar je relevantno, in izstopne ureditve.

ISO/IEC 27001:2022 Priloga A zagotavlja podporne kontrole dobaviteljev, vključno z 5.19 Informacijska varnost v odnosih z dobavitelji, 5.20 Obravnavanje informacijske varnosti v pogodbah z dobavitelji, 5.21 Upravljanje informacijske varnosti v dobavni verigi IKT, 5.22 Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev ter 5.23 Informacijska varnost pri uporabi storitev v oblaku.

Katalog testov DORA mora določiti, kateri testi zahtevajo sodelovanje dobavitelja ali dokazila dobavitelja. Primeri vključujejo:

• predpostavke preklopa ponudnika oblaka na rezervno okolje,
• eskalacijo upravljanega SOC in ohranitev dokazil,
• komunikacijo o incidentu na osnovni bančni platformi,
• scenarij izpada obdelovalca plačil,
• test obnovitve ponudnika identitet,
• potrdila ponudnika SaaS o penetracijskem testiranju,
• oceno vpliva verige kritičnih podizvajalcev.

Program, ki izključuje kritične ponudnike IKT, ne prestane preizkusa realnosti. Storitev, obrnjena k strankam, je lahko vaša, vendar je odvisnost odpornosti lahko v oblačni regiji, zunanjem SOC, ponudniku identitet, dobavitelju programske opreme, obdelovalcu plačil ali podatkovnem centru.

Preslikava navzkrižne skladnosti: en nabor dokazil, več obveznosti

Dobro zasnovan program testiranja DORA zmanjša utrujenost od presoj. Ista dokazila lahko podprejo DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 in preglede upravljanja COBIT 2019, če so pravilno označena, hranjena in poročana.

GDPR ne sme biti pozabljen. Če testi odpornosti vključujejo osebne podatke, dnevnike, evidence o strankah, podatke o identitetah, kadrovske evidence, biometrijo ali posebne vrste podatkov, mora organizacija upoštevati načela GDPR, vključno z zakonitostjo, poštenostjo, preglednostjo, minimizacijo podatkov, omejitvijo hrambe, celovitostjo, zaupnostjo in odgovornostjo. Kopije testnih podatkov, izvoženi dnevniki in dokazila penetracijskih testov lahko postanejo regulirana hramba podatkov. Program testiranja mora določiti, kdo lahko dostopa do njih, kako dolgo se hranijo in kako se varno odstranijo.

Kako bodo presojevalci preverjali isti program

Nadzornik DORA, presojevalec ISO, ocenjevalec na podlagi NIST, pregledovalec COBIT in presojevalec stranke lahko ista dokazila pregledajo skozi različne optike.

Zenith Controls je tukaj uporaben kot kompas za navzkrižno skladnost. Za testiranje DORA Clarysec posebej izpostavlja 5.35 Neodvisni pregled informacijske varnosti, 8.8 Upravljanje tehničnih ranljivosti in 8.6 Upravljanje kapacitet kot posebej pomembna sidra ISO/IEC 27001:2022 Priloge A. Lastnikom kontrol pomagajo povezati testiranje z neodvisnim zagotovilom, obravnavo ranljivosti in operativno kapaciteto.

Clarysecova Politika informacijske varnosti podpira tudi revizijsko sled:

“Lastniki kontrol morajo hraniti rezultate testov, dnevnike in zapise pregledov za podporo periodičnim presojam.”

Ta stavek mora postati operativno pravilo. Vsak lastnik testa mora vedeti, kaj hraniti, kje hraniti, kako zaščititi in kako povezati s tveganji ter dokazili kontrol.

V enem tednu pripravite paket dokazil DORA za ISO

Finančni subjekt ali ponudnik IKT lahko v petih delovnih dneh doseže pomemben napredek.

1. dan: Opredelite obseg in kritičnost

Uporabite razmišljanje iz ISO/IEC 27001:2022 točk 4.1 do 4.4. Identificirajte zainteresirane strani, regulativne obveznosti, pogodbene obveznosti, vmesnike in odvisnosti. Navedite poslovne storitve, kritične ali pomembne funkcije, ključna sredstva, vrste podatkov in ponudnike IKT.

Rezultat: register obsega testiranja DORA.

2. dan: Ustvarite letni katalog testov

Uporabite štiri družine testov: ranljivosti, scenariji, zmogljivost in penetracija. Za vsako storitev določite, kateri testi veljajo, pogostost, lastnika, raven neodvisnosti in sprožilec. Vključite sprožilce sprememb z visokim tveganjem.

Rezultat: katalog testiranja digitalne operativne odpornosti za leto 2026.

3. dan: Preslikajte kontrole in obveznosti

Vsak test preslikajte na ISO/IEC 27001:2022 Prilogo A, register tveganj, SoA, člene DORA, obveznosti dobaviteljev in relevantne vnose Zenith Controls. Na primer, mesečna zunanja skeniranja ranljivosti se preslikajo na 8.8 Upravljanje tehničnih ranljivosti, obravnavo tveganj, spremljanje, upravljanje tveganj IKT po DORA in rezultate ranljivosti po NIST CSF.

Rezultat: matrika preslikave kontrol.

4. dan: Standardizirajte mape dokazil

Vzpostavite nadzorovano strukturo dokazil:

• 01 Načrt in odobritev
• 02 Obseg in pravila izvajanja
• 03 Surovi rezultati
• 04 Končno poročilo
• 05 Register ugotovitev
• 06 Zahtevki za odpravo pomanjkljivosti
• 07 Dokazila ponovnega testiranja
• 08 Poročanje vodstvu
• 09 Pridobljene izkušnje in posodobitve politik

Rezultat: repozitorij dokazil s pravili hrambe.

5. dan: Preglejte ugotovitve in poročanje

Konsolidirajte odprte ugotovitve po resnosti, storitvi, lastniku tveganja in roku zapadlosti. Identificirajte zapadle odprave pomanjkljivosti, sprejeta tveganja in vrzeli pri ponovnem testiranju. Pripravite nadzorno ploščo za upravljalni organ, ki prikazuje pokritost testov, pomembne ugotovitve, zapadle ukrepe, zadeve tretjih oseb in preostalo tveganje.

Rezultat: nadzorna plošča testiranja DORA in ISO, pripravljena za upravni odbor.

Pogoste pasti programov testiranja DORA

Najpogostejša napaka ni pomanjkanje testiranja. Je pomanjkanje upravljanja.

Bodite pozorni na naslednje težave:

• penetracijski testi se izvajajo letno, vendar se ugotovitve ne spremljajo do zaprtja,
• skeniranja ranljivosti se izvajajo pogosto, vendar kritična sredstva manjkajo v obsegu,
• namizne vaje so izvedene, vendar ni dnevnika odločitev ali akcijskega načrta pridobljenih izkušenj,
• testi obnovitve varnostnih kopij so zaključeni, vendar niso preslikani na RTO in RPO,
• obremenitvene teste izvaja inženiring, vendar se o njih ne poroča funkciji tveganj ali skladnosti,
• ponudniki IKT so izključeni iz scenarijskih testov in testov obnovitve,
• dokazila so shranjena v osebnih mapah, pogovornih nitih ali neupravljanih pogonih,
• poročila upravnemu odboru so osredotočena na število dejavnosti namesto na nerešena tveganja odpornosti,
• SoA navaja, da se kontrola uporablja, vendar dokazila o testiranju ne obstajajo,
• testiranje ustvarja produkcijsko tveganje, ker odobritve in meje niso jasne.

Vsako vrzel je mogoče odpraviti. Rešitev ni več naključnega testiranja. Rešitev je en nadzorovan program, ki povezuje tveganje, testno dejavnost, odpravo pomanjkljivosti, dokazila in nadzor vodstva.

Kaj mora upravni odbor dejansko videti

DORA določa odpornost IKT kot odgovornost upravljalnega organa. Koristno poročilo upravnemu odboru ne sme vključevati vsake tehnične ugotovitve. Odgovoriti mora, ali je organizacija dovolj odporna glede na svoj apetit po tveganju in toleranco do motenj.

Močno četrtletno ali polletno poročilo vključuje:

• pokritost testov glede na kritične ali pomembne funkcije,
• zaključene v primerjavi z načrtovanimi testi,
• kritične in visoke ugotovitve po storitvah,
• zapadle odprave pomanjkljivosti po lastnikih,
• stopnjo uspešnosti ponovnega testiranja,
• ugotovitve, povezane z dobavitelji, in pomisleke glede koncentracije,
• pridobljene izkušnje iz scenarijskih testov, ki vplivajo na krizne ali incidentne načrte,
• kapacitetna tveganja glede na rast poslovanja in konična obdobja,
• preostala tveganja, ki zahtevajo sprejem vodstva,
• proračunske, kadrovske ali orodjarske omejitve.

To poročilo postane vhodni podatek za vodstveni pregled ISO, dokazilo upravljanja DORA in praktično orodje za odločanje.

Od razpršenih testov do strateške odpornosti

Prvotni problem CISO ni bil, da testiranja ni bilo. Organizacija je imela skeniranja, namizne vaje, poročila o obremenitvi in PDF-je penetracijskih testov. Težava je bila, da te dejavnosti še niso pripovedovale ene skladne zgodbe dokazil.

Enoten program testiranja DORA in ISO/IEC 27001:2022 to spremeni. Ocena tveganj vodi katalog. Katalog vodi odobreno testiranje. Testiranje ustvari ugotovitve. Ugotovitve vodijo odpravo pomanjkljivosti in ponovno testiranje. Rezultati napajajo poročanje vodstvu. Pridobljene izkušnje posodabljajo politike, postopke, pogodbe in kontrole.

Tako breme skladnosti postane strateška zmožnost.

Clarysec organizacijam pomaga preprečiti vzporedne programe skladnosti. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 in COBIT 2019 ne potrebujejo ločenih svetov dokazil. Potrebujejo enoten, upravljan operativni model, ki ga je mogoče predstaviti skozi različne presojne optike.

Naš pristop združuje:

• Zenith Blueprint za fazno uvedbo ISO in pripravljenost na presojo,
• Zenith Controls za preslikavo navzkrižne skladnosti med kontrolami, okviri in pričakovanji presoje,
• politike za velika podjetja in MSP za varnostno testiranje, spremljanje presoj, upravljanje ranljivosti, varnost aplikacij, neprekinjeno poslovanje in informacijsko varnost,
• praktične registre, strukture dokazil in predloge za poročanje vodstvu.

Če so vaša dokazila o testiranju DORA za leto 2026 razpršena po orodjih za skeniranje, mapah inženiringa, zapiskih namiznih vaj in PDF-jih penetracijskih testov, je zdaj čas za konsolidacijo.

Začnite z enim letnim katalogom testov, preslikanim na obravnavo tveganj ISO/IEC 27001:2022, vašo SoA, kritične ali pomembne funkcije, tretje osebe IKT in poročanje vodstvu. Nato uporabite Clarysecov Zenith Blueprint, Zenith Controls in nabor politik, da ta katalog pretvorite v dokazljiva presojna dokazila.

Clarysec vam lahko pomaga zasnovati program, preslikati kontrole, strukturirati paket dokazil in pripraviti poročilo o odpornosti za upravni odbor, preden prispe naslednja zahteva nadzornega organa.