Program testiranja prema DORA-i: mapiranje testova na ISO 27001
Veljača je 2026. CISO srednje velike platne institucije ima sjednicu upravnog odbora za dva dana, nadzornu reviziju ISO/IEC 27001:2022 za šest tjedana i nadzorni zahtjev prema DORA-i u ulaznoj pošti funkcije usklađenosti.
Regulator ne traži dotjeranu strategiju kibernetičke sigurnosti. Zahtjev je praktičan:
- Dostavite svoj program testiranja digitalne operativne otpornosti za 2026.
- Prikažite koji testovi pokrivaju kritične ili važne funkcije.
- Dokažite kako se nalazi otklanjaju i ponovno testiraju.
- Priložite dokaze o nadzoru upravljačkog tijela.
- Objasnite kako su uključeni pružatelji IKT usluga trećih strana.
- Dostavite zapise za procjene ranjivosti, testove utemeljene na scenarijima, testiranje performansi i kapaciteta te penetracijsko testiranje.
CISO otvara četiri mape. Skeniranja ranjivosti nalaze se u sustavu SOC-a za evidentiranje zahtjeva. Bilješke sa stolne vježbe nalaze se na dijeljenom disku. Rezultati testova opterećenja u vlasništvu su inženjerskog tima. Izvješća o penetracijskom testiranju nalaze se u ograničenom repozitoriju pravne funkcije. Praćenje otklanjanja nalaza podijeljeno je između sustava Jira, e-pošte i proračunske tablice izrađene za prošlogodišnju ISO reviziju.
Ništa od toga nije lažno. Velik dio predstavlja kvalitetno obavljen posao. No to još nije upravljani program testiranja digitalne operativne otpornosti prema DORA-i. To je zbirka testova.
Ta je razlika važna u 2026. DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstveni okvir EU-a za digitalnu operativnu otpornost u području upravljanja IKT rizicima, prijavljivanja incidenata, testiranja otpornosti, razmjene informacija o kibernetičkim prijetnjama i ranjivostima, upravljanja rizicima IKT trećih strana, ugovornih zahtjeva i nadzora kritičnih pružatelja IKT usluga trećih strana. Obuhvaća širok raspon financijskih subjekata, uključujući kreditne institucije, platne institucije, investicijska društva, pružatelje usluga povezanih s kriptoimovinom, društva za osiguranje i druge regulirane subjekte. DORA ujedno djeluje kao sektorski poseban pravni akt Unije za financijske subjekte koji bi inače podlijegali jednakovrijednim obvezama kibernetičke sigurnosti iz NIS2.
Praktično pitanje za odbore, CISO-e, voditelje usklađenosti i pružatelje IKT usluga više nije provodi li se testiranje. Pitanje je je li testiranje planirano, utemeljeno na riziku, potkrijepljeno dokazima, praćeno kroz otklanjanje nalaza, pregledano i ponovno upotrebljivo u okviru DORA-e i ISO/IEC 27001:2022.
Clarysecov operativni model izgrađen je upravo za taj problem. Korištenjem Zenith Blueprint: revizorov plan u 30 koraka, Clarysecova skupa politika usklađenih s ISO-om i Zenith Controls: vodič za međusobnu usklađenost, organizacije mogu raspršene aktivnosti otpornosti pretvoriti u kontrolirani godišnji katalog testova koji zadovoljava nadzorna tijela, revizore, klijente i odbore.
Zašto DORA pretvara testiranje u pitanje upravljanja
DORA je izričita u pogledu odgovornosti rukovodstva. Article 5 stavlja odgovornost za upravljanje IKT rizicima na upravljačko tijelo. Article 6 zahtijeva pouzdan, sveobuhvatan i dobro dokumentiran okvir upravljanja IKT rizicima integriran u cjelokupni sustav upravljanja rizicima organizacije. Article 4 dodaje načelo proporcionalnosti, što znači da se zahtjevi trebaju primjenjivati ovisno o veličini, ukupnom profilu rizika te prirodi, opsegu i složenosti usluga, aktivnosti i poslovanja.
Time testiranje digitalne operativne otpornosti postaje više od tehničkog zadatka. Ono postaje dokaz da upravljačko tijelo razumije rizik, odobrilo je strategiju, prima smisleno izvješćivanje i usmjerava otklanjanje nalaza.
ISO/IEC 27001:2022 koristi sličnu logiku sustava upravljanja. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije kontekst, zainteresirane strane, pravne i ugovorne obveze, opseg, sučelja i ovisnosti. Točke 5.1 do 5.3 zahtijevaju vodstvo, usklađenost s politikama, resurse, komunikaciju, dodijeljene odgovornosti i izvješćivanje najvišem rukovodstvu. Točka 6.1 zahtijeva procjenu rizika informacijske sigurnosti i obradu rizika.
Program testiranja prema DORA-i stoga treba povezati:
- Poslovne usluge i kritične ili važne funkcije
- IKT imovinu, podatke i ovisnosti o trećim stranama
- Procjenu rizika, vlasnike rizika i planove obrade rizika
- Vrste testova, učestalost i okidače
- Odobrenje, neovisnost i pravila angažmana
- Nalaze, rokove za otklanjanje nalaza i ponovno testiranje
- Zadržavanje dokaza i kontrolu pristupa
- Izvješćivanje uprave i kontinuirano poboljšavanje
Za manje financijske subjekte ili subjekte nižeg rizika, Article 16 predviđa pojednostavljeni okvir upravljanja IKT rizicima, ali pojednostavljeno ne znači neformalno. Čak i skalirani programi i dalje trebaju dokumentirano upravljanje IKT rizicima, praćenje, otporne sustave, identifikaciju izvora IKT rizika i anomalija, ključne ovisnosti o IKT trećim stranama, mjere neprekidnosti i oporavka, redovito testiranje i naučene lekcije.
Drugim riječima, DORA ne nagrađuje opseg testiranja. Nagrađuje upravljano testiranje utemeljeno na riziku koje dokazuje otpornost usluga koje su najvažnije.
Što pripada programu testiranja prema DORA-i za 2026.?
Zreo program testiranja prema DORA-i treba funkcionirati kao godišnji katalog testova. Ne smije biti ograničen na jedno godišnje penetracijsko testiranje ili hrpu izvoza iz alata za skeniranje ranjivosti. Treba uključivati osnovne i napredne testove, planirane prema riziku, kritičnosti usluga, regulatornim obvezama, ovisnostima o dobavljačima, značajnim promjenama i prethodnim nalazima.
DORA Article 24 uspostavlja program testiranja digitalne operativne otpornosti. Article 25 opisuje raspon testova, uključujući procjene i skeniranja ranjivosti, analize otvorenog koda, procjene mrežne sigurnosti, analize nedostataka, preglede fizičke sigurnosti, upitnike, softverska rješenja za skeniranje, preglede izvornog koda gdje je izvedivo, testove utemeljene na scenarijima, testiranje kompatibilnosti, testiranje performansi, end-to-end testiranje i penetracijsko testiranje. Article 26 dodaje penetracijsko testiranje vođeno prijetnjama za financijske subjekte koje identificiraju nadležna tijela.
Za većinu organizacija praktični katalog gradi se oko četiri skupine testiranja.
| Skupina testiranja | Što provjerava | Tipični dokazi | Vrijednost dokaza za ISO/IEC 27001:2022 |
|---|---|---|---|
| Procjene ranjivosti | Poznate slabosti u infrastrukturi, aplikacijama, uslugama u oblaku i krajnjim uređajima | Izvješća o skeniranju, opseg imovine, ocjene ozbiljnosti, zahtjevi, SLA za otklanjanje nalaza, zapisi o ponovnom testiranju | Procjena rizika, upravljanje tehničkim ranjivostima, dokazi operativnih kontrola, napredak plana obrade rizika |
| Testovi utemeljeni na scenarijima | Odgovor na realističan poremećaj, kibernetičke incidente, neuspjeh treće strane, povredu podataka, ransomware ili prekid platne usluge | Paketi za stolne vježbe, evidencije sudionika, dnevnici odluka, komunikacije, naučene lekcije, ažuriranja planova | Upravljanje incidentima, neprekidnost poslovanja, prikupljanje dokaza, osposobljavanje, ulazni podaci za preispitivanje od strane uprave |
| Testovi performansi i otpornosti | Kapacitet, opterećenje, prebacivanje na pričuvni sustav, ciljevi vremena oporavka, ciljevi točke oporavka, cjelovitost sigurnosnih kopija i degradacija usluge | Izvješća o opterećenju, pragovi kapaciteta, dokazi nadzora, dnevnički zapisi prebacivanja na pričuvni sustav, rezultati vraćanja iz sigurnosnih kopija, odobrenje vlasnika usluge | Upravljanje kapacitetima, testiranje sigurnosnih kopija, IKT spremnost za neprekidnost poslovanja, operativno planiranje |
| Penetracijsko testiranje i vježbe crvenog tima | Mogućnost iskorištavanja, putovi napada, zaobilaženje kontrola, sposobnost otkrivanja i odgovora | Pravila angažmana, odobrenje, završno izvješće, snimke zaslona kao dokazi, ocjene rizika, izvješće o otklanjanju nalaza i ponovnom testiranju | Sigurnosno testiranje, neovisni pregled, osiguranje dobavljača, revizijski pregled i pregled usklađenosti |
Clarysecova Politika sigurnosnog testiranja i vježbi crvenog tima pruža snažan oslonac politike za ovaj katalog:
“Vrste testova: Program sigurnosnog testiranja mora uključivati najmanje: (a) skeniranje ranjivosti, koje se sastoji od automatiziranih tjednih ili mjesečnih skeniranja mreža i aplikacija radi identifikacije poznatih ranjivosti; (b) penetracijsko testiranje, koje se sastoji od ručnog dubinskog testiranja određenih sustava ili aplikacija od strane kvalificiranih testera radi identifikacije složenih slabosti; i (c) vježbe crvenog tima, koje se sastoje od scenarijskih simulacija stvarnih napada, uključujući socijalni inženjering i druge taktike, radi testiranja sposobnosti organizacije za otkrivanje i odgovor u cjelini.”
Ista politika zahtijeva redovito planiranje:
“Raspored testiranja: Organizacija mora provoditi sigurnosno testiranje prema redovitom rasporedu. Ključni sustavi izloženi internetu i kritične interne aplikacije moraju proći penetracijsko testiranje najmanje jednom godišnje. Promjene visokog rizika, kao što su implementacija novog kritičnog sustava ili značajne nadogradnje, zahtijevaju ad hoc testiranje prije i/ili ubrzo nakon puštanja u produkciju.”
To je ključno za DORA-u. Statični godišnji plan nije dovoljan ako subjekt implementira novi platni pristupnik, migrira temeljni sustav u oblak, mijenja pružatelja upravljanih usluga ili uvodi novi tijek autentifikacije korisnika. Promjena visokog rizika mora pokrenuti dodatno testiranje.
Izgradite godišnji katalog testova kao jedinstveni izvor istine
Najučinkovitiji način za ispunjavanje zahtjeva DORA-e i ISO/IEC 27001:2022 jest izraditi jedan kontrolirani godišnji katalog testova. Može se nalaziti u GRC platformi, radnom toku za evidentiranje zahtjeva ili kontroliranoj proračunskoj tablici. Format je manje važan od sljedivosti.
Svaki test treba odgovoriti na pet revizijskih pitanja:
- Koja je usluga, imovina, dobavljač, aplikacija ili proces testiran?
- Koji je rizik, obveza ili zahtjev kontrole pokrenuo test?
- Tko je odobrio i proveo test?
- Koji su nalazi identificirani, prihvaćeni, otklonjeni ili odgođeni?
- Koji dokazi potvrđuju da je test proveden i da je ishod pregledan?
Praktični katalog u Clarysecovu stilu uključuje ova polja.
| Polje | Zašto je važno za DORA-u i ISO dokaze |
|---|---|
| ID testa | Stvara sljedivost između planova, izvješća, zahtjeva i materijala za odbor |
| Vrsta testa | Razlikuje procjenu ranjivosti, test utemeljen na scenariju, test performansi, penetracijski test ili vježbu crvenog tima |
| Poslovna usluga | Povezuje test s otpornošću usluge i utjecajem na dionike |
| Kritična ili važna funkcija | Podržava DORA proporcionalnost i određivanje prioriteta |
| IKT imovina i podaci | Povezuje se s popisom imovine, klasifikacijom podataka i utjecajem na GDPR |
| Ovisnosti o IKT trećim stranama | Pokazuje jesu li uključeni pružatelji, platforme u oblaku ili upravljane usluge |
| Okidač | Godišnji raspored, promjena visokog rizika, lekcija iz incidenta, nalaz revizije ili regulatorni zahtjev |
| Mapiranje kontrola | Povezuje s Prilogom A ISO/IEC 27001:2022, obradom rizika i Zenith Controls |
| Vlasnik | Dodjeljuje odgovornost za planiranje i otklanjanje nalaza |
| Neovisnost testera | Prikazuje interni, vanjski ili neovisni model pregleda |
| Lokacija dokaza | Sprječava raspršenost revizijskih dokaza po alatima |
| Nalazi i ozbiljnost | Uspostavlja odgovornost za otklanjanje nalaza |
| Status ponovnog testiranja | Prikazuje zatvaranje, ublažavanje ili prihvaćeni preostali rizik |
| Datum izvješćivanja upravi | Dokazuje nadzor i kontinuirano poboljšavanje |
Clarysecova Politika praćenja revizije i usklađenosti za mala i srednja poduzeća daje sažeto pravilo upravljanja koje odgovara ovoj strukturi:
“Svaka revizija mora uključivati definirani opseg, ciljeve, odgovorno osoblje i potrebne dokaze.”
Iako je napisano za revizije, isto se pravilo treba primjenjivati na testove otpornosti. Ako skeniranje ranjivosti, stolna vježba, simulacija prebacivanja na pričuvni sustav ili penetracijski test nema definiran opseg, cilj, vlasnika i potrebne dokaze, bit će slab pod nadzorom DORA-e i u ISO reviziji.
Ista politika navodi:
“Dokazi se moraju zadržati najmanje dvije godine ili dulje kada to zahtijevaju certifikacija ili ugovori s klijentima.”
Za financijske subjekte regulirane DORA-om i pružatelje IKT usluga, dvije godine treba smatrati donjom granicom. Ugovorne obveze, očekivanja nadzornih tijela, certifikacijski ciklusi i istrage incidenata mogu zahtijevati dulje zadržavanje.
Mapiranje vrsta testova prema DORA-i na dokaze za ISO 27001
Snaga integriranog programa leži u tome što jedan test može zadovoljiti više obveza. Ključno je pravilno označiti dokaze i povezati ih s ISMS-om.
Zenith Blueprint to objašnjava u fazi Revizija, pregled i poboljšanje, korak 24:
“Vaša SoA treba biti usklađena s Registrom rizika i Planom obrade rizika. Dvaput provjerite da je svaka kontrola koju ste odabrali kao obradu rizika označena kao ‘Primjenjiva’ u SoA-i.”
Za program testiranja prema DORA-i, katalog testova postaje poveznica između obrade rizika i operativnih dokaza. Izjava o primjenjivosti ne smije navoditi da je kontrola primjenjiva dok se dokazi testiranja nalaze negdje drugdje, bez mapiranja i upravljanja.
| DORA vrsta testa | Uporište u Prilogu A ISO/IEC 27001:2022 | Veza | ISO dokazni artefakti | Clarysec politika ili alat |
|---|---|---|---|---|
| Procjena ranjivosti | 8.8 Upravljanje tehničkim ranjivostima | Identificira, procjenjuje, prioritizira i otklanja poznate slabosti | Izvješća o skeniranju, ocjene rizika, zahtjevi, zapisnici zakrpa, iznimke, zapisi o ponovnom testiranju | Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća |
| Penetracijsko testiranje | 5.35 Neovisni pregled informacijske sigurnosti | Pruža neovisnu procjenu djelotvornosti kontrola i mogućnosti iskorištavanja | Opseg, ponuda, odobrenje, pravila angažmana, završno izvješće, plan otklanjanja nalaza, izvješće o ponovnom testiranju | Politika sigurnosnog testiranja i vježbi crvenog tima |
| Testiranje performansi i kapaciteta | 8.6 Upravljanje kapacitetima | Provjerava performanse, kapacitet, pragove i pretpostavke rasta | Izvješća o opterećenju, nadzorne ploče, planovi kapaciteta, incidenti povezani s performansama, aktivnosti skaliranja | Mapiranje u Zenith Controls i operativni postupci |
| Testiranje utemeljeno na scenarijima | 5.30 IKT spremnost za neprekidnost poslovanja | Provjerava odgovor, oporavak, eskalaciju i aranžmane neprekidnosti | Skripte za stolne vježbe, planovi prebacivanja na pričuvni sustav, evidencije sudionika, naučene lekcije, aktivnosti poboljšanja | Politika neprekidnosti poslovanja i oporavka od katastrofe za mala i srednja poduzeća |
| Testiranje izdanja aplikacije | 8.29 Sigurnosno testiranje u razvoju i prihvatu | Provjerava sigurnost prije implementacije i nakon promjena visokog rizika | Testni slučajevi, sigurnosno odobrenje, nedostaci, odobrenja izdanja, dokazi ponovnog testiranja | Politika zahtjeva sigurnosti aplikacija za mala i srednja poduzeća |
| Zaštićeno revizijsko testiranje | 8.34 Zaštita informacijskih sustava tijekom revizijskog testiranja | Sprječava da testovi uzrokuju neovlašteni poremećaj ili izloženost | Zapisi odobrenja, termini testiranja, kontakti za hitne slučajeve, kontrole pristupa, planovi povrata | Zenith Blueprint korak 21 i Politika sigurnosnog testiranja i vježbi crvenog tima |
Ova tablica pomaže CISO-u odgovoriti na često pitanje glavnog izvršnog direktora: “Jesu li naši ISO penetracijski testovi i skeniranja ranjivosti dovoljni za DORA-u?”
Odgovor glasi: mogu biti dio usklađenosti s DORA-om, ali samo ako su utemeljeni na riziku, povezani s kritičnim ili važnim funkcijama, uređeni politikom, praćeni kroz otklanjanje nalaza i prijavljeni upravi.
Procjene ranjivosti: kontinuirani dokazi, a ne samo izlaz iz alata za skeniranje
Procjena ranjivosti često je najlakša aktivnost testiranja za provedbu i najlakša za pogrešno upravljanje. Mnoge organizacije mogu izraditi izvješća o skeniranju. Manje ih može dokazati da skeniranja pokrivaju odgovarajuću imovinu, prioritiziraju kritične usluge, generiraju pravodobno otklanjanje nalaza i ulaze u odluke o obradi rizika.
Clarysecova Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća počinje ispravnim ciljem:
“Pravodobno i dosljedno identificirati i procjenjivati poznate ranjivosti u svoj IT imovini”
Za DORA-u to podržava identifikaciju izvora IKT rizika, otporne i ažurne sustave, praćenje, otkrivanje anomalija i kontinuirano poboljšavanje. Za ISO/IEC 27001:2022 izravno se mapira na 8.8 Upravljanje tehničkim ranjivostima, a oslanja se i na 5.9 Popis informacija i druge povezane imovine, 8.16 Aktivnosti praćenja i 8.32 Upravljanje promjenama.
Snažan zapis o procjeni ranjivosti treba uključivati:
- Snimku popisa imovine korištenu za određivanje opsega
- Datum skeniranja, alat i autentificiranu ili neautentificiranu metodu
- Izuzeća i poslovno obrazloženje
- Nalaze prema ozbiljnosti, mogućnosti iskorištavanja i poslovnoj usluzi
- Mapiranje na kritične ili važne funkcije i vrste podataka
- Reference na zahtjeve i vlasnika rizika
- SLA za otklanjanje nalaza i krajnji rok
- Rezultat ponovnog testiranja
- Iznimke s odobrenjem preostalog rizika
Zenith Controls pozicionira 8.8 Upravljanje tehničkim ranjivostima kao temeljno dokazno područje za identifikaciju, procjenu, prioritizaciju i praćenje otklanjanja nalaza. Također pokazuje zašto će revizori testirati susjedne procese. Ako je popis imovine nepotpun, pokrivenost ranjivosti je nepotpuna. Ako se upravljanje promjenama zaobilazi, uvođenje zakrpa može stvoriti novi operativni rizik. Ako je praćenje slabo, pokušaji iskorištavanja možda neće biti otkriveni.
Testovi utemeljeni na scenarijima: dokažite donošenje odluka prije stvarnog incidenta
Testovi utemeljeni na scenarijima pokazuju operativnu otpornost izvršnom rukovodstvu. Stolna vježba ransomwarea, simulacija nedostupnosti regije oblaka, vježba kompromitacije privilegiranog pristupa ili scenarij neuspjeha kritičnog pružatelja IKT usluga otkrit će slabosti koje skeniranje ne može.
DORA Articles 17 to 20 zahtijevaju formalni životni ciklus incidenta povezanog s IKT-om: otkrivanje, upravljanje, obavješćivanje, evidentiranje, praćenje, postupanje, naknadno praćenje, dokumentiranje temeljnog uzroka, otklanjanje posljedica, klasifikaciju ozbiljnosti, dodjelu uloga, eskalaciju većih incidenata i izvješćivanje kroz propisane faze. Kada su pogođeni financijski interesi klijenata, klijente je potrebno obavijestiti bez nepotrebnog odgađanja.
NIS2 ima sličnu hitnost za subjekte u svom opsegu, uključujući rano upozorenje, obavješćivanje, privremeno izvješćivanje i završno izvješćivanje. Za financijske subjekte u opsegu, DORA je sektorski poseban pravni akt za jednakovrijedne obveze upravljanja rizicima kibernetičke sigurnosti i izvješćivanja. Pružatelji IKT usluga, SaaS platforme, MSP-ovi i MSSP-ovi i dalje trebaju provjeriti jesu li izravno u opsegu NIS2 ili su ugovorno uključeni u DORA dokazivanje sigurnosti od strane reguliranih klijenata.
Zenith Blueprint, faza Kontrole u praksi, korak 23, daje praktični model dokaza:
“Odaberite nedavni događaj ili provedite stolnu vježbu kako biste provjerili svoj plan. Zabilježite u dnevnik sve odluke, uloge i komunikacije (5.26) te ažurirajte plan naučenim lekcijama (5.27).”
Test utemeljen na scenariju prema DORA-i treba proizvesti zapise prikladne za reviziju, a ne samo bilješke sa sastanka:
- Sažetak scenarija i ciljeve
- Sudionike i uloge, uključujući pravne poslove, komunikacije, IT, SOC, vlasnika poslovanja i kontakte dobavljača
- Vremenski slijed umetnutih događaja i odluka
- Odluku o klasifikaciji i analizu pragova izvješćivanja
- Nacrte internih i vanjskih komunikacija
- Aktivnosti očuvanja dokaza
- Naučene lekcije
- Vlasnike aktivnosti i krajnje rokove
- Ažurirane postupke za incidente, neprekidnost ili komunikaciju
Clarysecova Politika neprekidnosti poslovanja i oporavka od katastrofe za mala i srednja poduzeća pojačava očekivanje godišnjeg testiranja:
“Organizacija mora testirati i svoje BCP i DR sposobnosti najmanje jednom godišnje. Testovi moraju uključivati:”
Katalog testiranja treba tu obvezu pretočiti u konkretne vježbe, kao što su stolna vježba kriznog upravljanja, test vraćanja iz sigurnosne kopije, test prebacivanja na pričuvnu lokaciju u oblaku, test stabla kontakata i simulacija poremećaja kod dobavljača.
Testovi performansi, kapaciteta i oporavka: zanemareni dokazi otpornosti
Testiranje performansi često se tretira kao inženjersko pitanje. Prema DORA-i, ono postaje dokaz otpornosti.
Trgovačkoj platformi, platnoj usluzi, sustavu za obradu šteta, platformi identiteta ili korisničkom portalu nije potreban kibernetički napad da bi iznevjerili korisnike. Iscrpljenje kapaciteta, zasićenje redova čekanja, uska grla baze podataka, pogrešno konfigurirano automatsko skaliranje ili neispravno prebacivanje na pričuvni sustav mogu uzrokovati isti operativni poremećaj kao sigurnosni incident.
ISO/IEC 27001:2022 Prilog A 8.6 Upravljanje kapacitetima primarno je uporište. Dokazi mogu uključivati testiranje opterećenja, stresno testiranje, testiranje degradacije usluge, provjeru infrastrukturnih pragova, testove vraćanja iz sigurnosne kopije i simulacije prebacivanja na pričuvni sustav.
Dobar zapis o testu performansi i kapaciteta treba obuhvatiti:
- Polazne pretpostavke normalnog i vršnog opterećenja
- Testirane kritične transakcijske tokove
- Testirana infrastrukturna i oblačna ograničenja
- Nadzorne ploče za praćenje i pragove upozorenja
- Načine otkaza, kao što su zasićenje redova čekanja ili uska grla baze podataka
- Relevantnost RTO i RPO kada se testira prebacivanje na pričuvni sustav ili oporavak
- Poslovni utjecaj u slučaju prekoračenja pragova
- Korektivne radnje, odluke o skaliranju ili arhitekturne promjene
- Prihvaćanje preostalog rizika kapaciteta od strane uprave
Zenith Blueprint, korak 23, povezuje očekivanja oporavka s dokazima:
“Provjerite jesu li ciljevi vremena oporavka (RTO) i ciljevi točke oporavka (RPO) za kritične sustave usklađeni s očekivanjima neprekidnosti poslovanja (5.30). Provedite najmanje jedan tehnički test oporavka ili simulaciju prebacivanja na pričuvni sustav i dokumentirajte rezultate.”
To je razlika između izjave “imamo sigurnosne kopije” i dokaza da je kritična usluga obnovljena unutar dogovorene tolerancije, s dokumentiranim rezultatima i vidljivošću za upravu.
Penetracijsko testiranje i vježbe crvenog tima: snažni dokazi zahtijevaju snažnu kontrolu
Penetracijsko testiranje vrlo je vrijedan dokaz, ali nosi i operativni rizik. Loše upravljano testiranje može utjecati na produkcijske sustave, izložiti osjetljive informacije, pokrenuti nekontrolirana upozorenja, stvoriti pravne probleme ili poremetiti korisnike.
Politika zahtjeva sigurnosti aplikacija za mala i srednja poduzeća postavlja jasnu kontrolnu točku prije izdanja:
“Prije implementacije sve aplikacije moraju proći sigurnosno testiranje radi provjere gore navedenih polaznih značajki.”
Za kritične aplikacije to treba unositi u DORA katalog kao predprodukcijsko sigurnosno testiranje, provjeru nakon puštanja u produkciju za promjene visokog rizika i periodično penetracijsko testiranje na temelju izloženosti i kritičnosti.
Politika sigurnosnog testiranja i vježbi crvenog tima jača lanac otklanjanja nalaza:
“Otklanjanje nalaza: Sve identificirane ranjivosti ili slabosti moraju biti dokumentirane u izvješću o nalazima s ocjenama ozbiljnosti. Po primitku izvješća vlasnici sustava odgovorni su za izradu plana otklanjanja nalaza s krajnjim rokovima; primjerice, kritični nalazi moraju se otkloniti u roku od 30 dana, a nalazi visoke ozbiljnosti u roku od 60 dana, u skladu s Politikom upravljanja ranjivostima i zakrpama organizacije. STC mora pratiti napredak otklanjanja nalaza. Ponovno testiranje mora se provesti kako bi se potvrdilo da su kritični problemi riješeni ili odgovarajuće ublaženi.”
Ista politika definira očekivanja izvješćivanja:
“Izvješćivanje: Formalno izvješće mora se izdati po završetku svakog testa. Za penetracijsko testiranje izvješće mora sadržavati sažetak za rukovodstvo, metodologiju i detaljne nalaze s pratećim dokazima i preporukama.”
Zenith Blueprint, korak 21, također naglašava zaštitu tijekom revizije i testiranja:
“Nijedan test ili revizija ne smije se provesti bez dokumentiranog odobrenja vlasnika sustava ili relevantnih dionika.”
Pravila angažmana, termini testiranja, kontakti za hitne slučajeve, privremeni pristup, postupanje s podacima, dnevničko bilježenje, postupci povrata i pravna odobrenja nisu birokracija. To su zaštitne mjere otpornosti.
Uključite pružatelje IKT usluga trećih strana prije nego što test ne uspije
DORA postavlja rizik IKT trećih strana u središte otpornosti. Article 28 zahtijeva da financijski subjekti upravljaju rizikom IKT trećih strana unutar okvira upravljanja IKT rizicima, ostanu odgovorni pri korištenju IKT usluga, vode registar informacija, prijavljuju određene aranžmane, provode procjene prije sklapanja ugovora i koriste pružatelje koji ispunjavaju odgovarajuće standarde informacijske sigurnosti. Articles 29 and 30 obrađuju rizik koncentracije, podugovaranje, oporavak podataka, ugovorne zaštite, razine usluge, pomoć pri incidentima, prava na reviziju, testiranje planova kontinuiteta pružatelja, sudjelovanje u testiranju kada je relevantno i izlazne aranžmane.
ISO/IEC 27001:2022 Prilog A daje potporne kontrole dobavljača, uključujući 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.20 Obrada informacijske sigurnosti u ugovorima s dobavljačima, 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, 5.22 Praćenje, pregled i upravljanje promjenama usluga dobavljača te 5.23 Informacijska sigurnost za korištenje usluga u oblaku.
DORA katalog testova treba identificirati koji testovi zahtijevaju sudjelovanje dobavljača ili dokaze dobavljača. Primjeri uključuju:
- Pretpostavke prebacivanja na pričuvnu lokaciju kod pružatelja usluga u oblaku
- Eskalaciju i očuvanje dokaza u upravljanom SOC-u
- Komunikaciju o incidentima platforme temeljnog bankarskog sustava
- Scenarij nedostupnosti obrađivača plaćanja
- Test oporavka pružatelja identiteta
- Potvrde SaaS dobavljača o penetracijskom testiranju
- Procjenu utjecaja lanca kritičnih podizvođača
Program koji isključuje kritične pružatelje IKT usluga neće proći test stvarnosti. Usluga dostupna korisnicima može biti vaša, ali ovisnost o otpornosti može se nalaziti u regiji oblaka, vanjskom centru za sigurnosne operacije, pružatelju identiteta, dobavljaču softvera, obrađivaču plaćanja ili podatkovnom centru.
Mapiranje međusobne usklađenosti: jedan skup dokaza, mnoge obveze
Dobro osmišljen program testiranja prema DORA-i smanjuje zamor od revizija. Isti dokazi mogu poduprijeti DORA-u, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 i COBIT 2019 preglede upravljanja ako su pravilno označeni, zadržani i prijavljeni.
| Stavka dokaza | Relevantnost za DORA-u | Relevantnost za ISO/IEC 27001:2022 | Relevantnost za međusobnu usklađenost |
|---|---|---|---|
| Godišnji katalog testova | Upravljanje testiranjem digitalne operativne otpornosti i proporcionalnost | Operativno planiranje, obrada rizika i preispitivanje od strane uprave | NIST CSF profili i GOVERN, COBIT upravljanje i pregled učinkovitosti |
| Skeniranje ranjivosti i otklanjanje nalaza | Identifikacija izvora IKT rizika i otporni sustavi | 8.8 Upravljanje tehničkim ranjivostima i dokazi obrade rizika | NIS2 postupanje s ranjivostima, NIST CSF ID.RA i DE.CM ishodi |
| Stolna vježba incidenta | Klasifikacija incidenta, eskalacija, komunikacija i spremnost izvješćivanja | Planiranje incidenata, odgovor, naučene lekcije i prikupljanje dokaza | Usklađenje s NIS2 prijavljivanjem incidenata, potpora odlučivanju o povredi prema GDPR-u |
| Test vraćanja iz sigurnosne kopije | Neprekidnost i oporavak kritičnih funkcija | 5.30 IKT spremnost za neprekidnost poslovanja i dokazi testiranja sigurnosnih kopija | NIST CSF RECOVER ishodi, ugovorni dokazi otpornosti za klijente |
| Test kapaciteta | Otpornost pod opterećenjem i neprekidnost usluge | 8.6 Upravljanje kapacitetima i operativno praćenje | NIST CSF PR.IR mehanizmi otpornosti, upravljanje razinom usluge |
| Penetracijski test | Djelotvornost sigurnosnih kontrola i provjera putova napada | 5.35 Neovisni pregled informacijske sigurnosti i korektivne radnje | Osiguranje dobavljača, izvješćivanje odbora, dubinska analiza klijenata |
GDPR se ne smije zaboraviti. Ako testovi otpornosti uključuju osobne podatke, dnevničke zapise, evidencije klijenata, podatke o identitetu, podatke odjela ljudskih resursa, biometriju ili posebne kategorije podataka, organizacija mora poštovati načela GDPR-a, uključujući zakonitost, poštenost, transparentnost, minimizaciju podataka, ograničenje pohrane, cjelovitost, povjerljivost i odgovornost. Kopije testnih podataka, izvezeni dnevnički zapisi i dokazi penetracijskog testiranja mogu postati repozitoriji reguliranih podataka. Program testiranja treba definirati tko im smije pristupiti, koliko dugo se zadržavaju i kako se sigurno uništavaju ili zbrinjavaju.
Kako će revizori testirati isti program
DORA nadzorno tijelo, ISO revizor, procjenitelj temeljen na NIST-u, COBIT pregledavatelj i revizor klijenta mogu pregledavati iste dokaze kroz različite perspektive.
| Revizijska perspektiva | Vjerojatno revizijsko pitanje | Dokazi koje će očekivati |
|---|---|---|
| DORA nadzorno tijelo | Je li testiranje utemeljeno na riziku, proporcionalno, upravljano i povezano s kritičnim ili važnim funkcijama? | Odobreni godišnji katalog testova, mapiranje kritičnih funkcija, izvješćivanje upravljačkog tijela, status otklanjanja nalaza, sudjelovanje trećih strana |
| ISO/IEC 27001:2022 revizor | Podržava li testiranje ISMS procjenu rizika, SoA, obradu rizika i operativne kontrole? | Registar rizika, mapiranje SoA, planovi testiranja, izvješća, korektivne radnje, zadržani dokazi, ulazni podaci za preispitivanje od strane uprave |
| NIST CSF procjenitelj | Prelazi li organizacija iz trenutačnog u ciljani profil pomoću prioritiziranih akcijskih planova? | Trenutačni i ciljani profil, analiza nedostataka, POA&M, zapisi o ranjivostima, dokazi praćenja i odgovora |
| COBIT ili ISACA revizor | Djeluju li ciljevi upravljanja, vlasništvo nad kontrolama, metrike učinkovitosti i aktivnosti osiguranja djelotvorno? | RACI, KPI-jevi, KRI-jevi, rezultati testiranja kontrola, dnevnici otvorenih pitanja, odobrenja uprave i dokazi neovisnog pregleda |
| Revizor klijenta | Može li pružatelj dokazati operativnu otpornost za ugovorene usluge? | Izvješća o testiranju specifična za uslugu, SLA dokazi, postupak podrške incidentima, osiguranje dobavljača, dokazi izlaza i neprekidnosti |
Zenith Controls ovdje je koristan kao kompas za međusobnu usklađenost. Za DORA testiranje Clarysec ističe 5.35 Neovisni pregled informacijske sigurnosti, 8.8 Upravljanje tehničkim ranjivostima i 8.6 Upravljanje kapacitetima kao posebno važna uporišta u Prilogu A ISO/IEC 27001:2022. Ona pomažu vlasnicima kontrola povezati testiranje s neovisnim osiguranjem, postupanjem s ranjivostima i operativnim kapacitetom.
Clarysecova Politika informacijske sigurnosti također podržava revizijski trag:
“Vlasnici kontrola moraju održavati rezultate testiranja, zapise dnevnika i zapise pregleda radi potpore periodičnim revizijama.”
Ta rečenica treba postati operativno pravilo. Svaki vlasnik testa treba znati što zadržati, gdje to zadržati, kako to zaštititi i kako se to povezuje s dokazima rizika i kontrola.
Izgradite DORA-ISO paket dokaza u jednom tjednu
Financijski subjekt ili pružatelj IKT usluga može ostvariti značajan napredak u pet radnih dana.
Dan 1: definirajte opseg i kritičnost
Primijenite logiku točaka 4.1 do 4.4 ISO/IEC 27001:2022. Identificirajte zainteresirane strane, regulatorne obveze, ugovorne obveze, sučelja i ovisnosti. Popišite poslovne usluge, kritične ili važne funkcije, ključnu imovinu, vrste podataka i pružatelje IKT usluga.
Izlazni rezultat: registar opsega DORA testiranja.
Dan 2: izradite godišnji katalog testova
Koristite četiri skupine testova: ranjivosti, scenariji, performanse i penetracija. Za svaku uslugu definirajte koji se testovi primjenjuju, učestalost, vlasnika, razinu neovisnosti i okidač. Uključite okidače promjena visokog rizika.
Izlazni rezultat: katalog testiranja digitalne operativne otpornosti za 2026.
Dan 3: mapirajte kontrole i obveze
Mapirajte svaki test na Prilog A ISO/IEC 27001:2022, registar rizika, SoA, DORA članke, obveze dobavljača i relevantne stavke Zenith Controls. Primjerice, mjesečna vanjska skeniranja ranjivosti mapiraju se na 8.8 Upravljanje tehničkim ranjivostima, obradu rizika, praćenje, DORA upravljanje IKT rizicima i NIST CSF ishode ranjivosti.
Izlazni rezultat: matrica mapiranja kontrola.
Dan 4: standardizirajte mape dokaza
Izradite kontroliranu strukturu dokaza:
- 01 Plan i odobrenje
- 02 Opseg i pravila angažmana
- 03 Neobrađeni rezultati
- 04 Završno izvješće
- 05 Registar nalaza
- 06 Zahtjevi za otklanjanje nalaza
- 07 Dokazi ponovnog testiranja
- 08 Izvješćivanje uprave
- 09 Naučene lekcije i ažuriranja politika
Izlazni rezultat: repozitorij dokaza s pravilima zadržavanja.
Dan 5: pregledajte nalaze i izvješćivanje
Konsolidirajte otvorene nalaze prema ozbiljnosti, usluzi, vlasniku rizika i krajnjem roku. Identificirajte zakašnjelo otklanjanje nalaza, prihvaćene rizike i praznine u ponovnom testiranju. Pripremite nadzornu ploču za upravljačko tijelo koja prikazuje pokrivenost testiranja, veće nalaze, zakašnjele radnje, pitanja trećih strana i preostali rizik.
Izlazni rezultat: DORA i ISO nadzorna ploča testiranja spremna za odbor.
Česte zamke programa testiranja prema DORA-i
Najčešći neuspjeh nije nedostatak testiranja. To je nedostatak upravljanja.
Obratite pozornost na sljedeće probleme:
- Penetracijski testovi provode se godišnje, ali nalazi se ne prate do zatvaranja
- Skeniranja ranjivosti provode se često, ali kritična imovina nedostaje iz opsega
- Stolne vježbe se održavaju, ali nema dnevnika odluka ni akcijskog plana naučenih lekcija
- Testovi vraćanja iz sigurnosnih kopija dovršeni su, ali nisu mapirani na RTO i RPO
- Inženjerski tim provodi testove opterećenja, ali se rezultati ne prijavljuju funkciji rizika ili usklađenosti
- Pružatelji IKT usluga isključeni su iz testova utemeljenih na scenarijima i testova oporavka
- Dokazi se pohranjuju u osobne mape, razgovorne niti ili neupravljane diskove
- Izvješća odboru usmjerena su na broj aktivnosti umjesto na neriješeni rizik otpornosti
- SoA navodi da je kontrola primjenjiva, ali ne postoje dokazi testiranja
- Testiranje stvara produkcijski rizik jer odobrenje i granice nisu jasni
Svaka se praznina može riješiti. Rješenje nije više nasumičnog testiranja. Rješenje je jedan kontrolirani program koji povezuje rizik, testnu aktivnost, otklanjanje nalaza, dokaze i nadzor uprave.
Što odbor zapravo treba vidjeti
DORA čini IKT otpornost odgovornošću upravljačkog tijela. Korisno izvješće odboru ne treba sadržavati svaki tehnički nalaz. Treba odgovoriti na pitanje je li organizacija dovoljno otporna u odnosu na svoj apetit za rizik i toleranciju na poremećaje.
Snažno tromjesečno ili polugodišnje izvješće uključuje:
- Pokrivenost testiranja u odnosu na kritične ili važne funkcije
- Dovršene u odnosu na planirane testove
- Kritične nalaze i nalaze visoke ozbiljnosti po usluzi
- Zakašnjelo otklanjanje nalaza po vlasniku
- Stopu uspješnosti ponovnog testiranja
- Nalaze povezane s dobavljačima i zabrinutosti u vezi s koncentracijom
- Naučene lekcije iz testova utemeljenih na scenarijima koje utječu na krizne ili incidentne planove
- Rizike kapaciteta u odnosu na poslovni rast i vršna razdoblja
- Preostale rizike koji zahtijevaju prihvaćanje uprave
- Ograničenja proračuna, resursa ili alata
To izvješće postaje ulazni podatak za ISO preispitivanje od strane uprave, DORA dokaz upravljanja i praktičan alat za odlučivanje.
Od raspršenih testova do strateške otpornosti
Izvorni problem CISO-a nije bio nedostatak testiranja. Organizacija je imala skeniranja, stolne vježbe, izvješća o opterećenju i PDF-ove penetracijskih testova. Problem je bio u tome što te aktivnosti još nisu pričale jednu koherentnu dokaznu priču.
Jedinstveni program testiranja prema DORA-i i ISO/IEC 27001:2022 to mijenja. Procjena rizika pokreće katalog. Katalog pokreće odobreno testiranje. Testiranje proizvodi nalaze. Nalazi pokreću otklanjanje nalaza i ponovno testiranje. Rezultati ulaze u izvješćivanje uprave. Naučene lekcije ažuriraju politike, postupke, ugovore i kontrole.
Tako se teret usklađenosti pretvara u stratešku sposobnost.
Clarysec pomaže organizacijama izbjeći paralelne programe usklađenosti. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 i COBIT 2019 ne trebaju odvojene svjetove dokaza. Trebaju jedinstveni, upravljani operativni model koji se može predstaviti kroz različite revizijske perspektive.
Naš pristup kombinira:
- Zenith Blueprint za faznu ISO implementaciju i spremnost za reviziju
- Zenith Controls za mapiranje međusobne usklađenosti kroz kontrole, okvire i revizijska očekivanja
- Korporativne politike i politike za mala i srednja poduzeća za sigurnosno testiranje, praćenje revizije, upravljanje ranjivostima, sigurnost aplikacija, neprekidnost i informacijsku sigurnost
- Praktične registre, strukture dokaza i predloške izvješćivanja uprave
Ako su vaši DORA dokazi testiranja za 2026. raspršeni po alatima za skeniranje, mapama inženjerskog tima, bilješkama sa stolnih vježbi i PDF-ovima penetracijskih testova, sada je vrijeme za konsolidaciju.
Započnite s jednim godišnjim katalogom testova mapiranim na obradu rizika prema ISO/IEC 27001:2022, vašu SoA, kritične ili važne funkcije, IKT treće strane i izvješćivanje uprave. Zatim upotrijebite Clarysecov Zenith Blueprint, Zenith Controls i skup alata za politike kako biste taj katalog pretvorili u dokazive revizijske dokaze.
Clarysec vam može pomoći osmisliti program, mapirati kontrole, strukturirati paket dokaza i pripremiti izvješće o otpornosti za razinu odbora prije nego što stigne sljedeći nadzorni zahtjev.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
