DORA prijavljivanje incidenata i kontrole ISO 27001 u 2026.

Utorak je ujutro, 08:17, 2026. godine. Sarah, CISO europskog fintech društva, na upravljačkoj ploči vidi žuto, a ne crveno upozorenje. Kritična platforma za namiru plaćanja usporava. Transakcije ne prestaju u potpunosti, ali traju tri puta dulje nego što dopušta ugovor o razini usluge (SLA). SOC uočava neuobičajene pokušaje autentifikacije prema administratorskom računu. Pružatelj infrastrukture u oblaku prijavljuje degradiranu uslugu u jednoj zoni dostupnosti. Korisnička podrška počinje primati pozive korporativnih klijenata koji pitaju zašto kasne datoteke za plaćanje.
Još nitko ne zna je li riječ o kibernetičkom napadu, neuspjehu operativne otpornosti, prekidu kod dobavljača, incidentu povezanom s privatnošću ili svemu navedenom istodobno.
Sarah ima DORA problem i prije nego što su tehničke činjenice potpune. Je li ovo veliki incident povezan s IKT-om? Utječe li na kritičnu ili važnu funkciju? Je li premašio interni prag ozbiljnosti? Koga treba obavijestiti, kada i s kojim dokazima? Ako su uključeni osobni podaci, je li počeo teći i GDPR rok za obavješćivanje? Ako je pružatelj IKT usluga treće strane dio lanca incidenta, tko je odgovoran za činjenice?
Upravo tu financijski subjekti vide razliku između posjedovanja plana odgovora na incidente i operativnog modela za DORA prijavljivanje incidenata koji je moguće revidirati.
DORA prijavljivanje incidenata u 2026. zahtijeva više od brze eskalacije. Zahtijeva dokaziv lanac od otkrivanja do klasifikacije, od klasifikacije do izvješćivanja nadležnom tijelu, od izvješćivanja do otklanjanja posljedica i od otklanjanja posljedica do naučenih lekcija. ISO/IEC 27001:2022 pruža strukturu sustava upravljanja. Kontrole iz Priloga A norme ISO/IEC 27002:2022 daju praktična očekivanja u pogledu kontrola. Clarysec politike, plan implementacije u 30 koraka i vodič za međusobnu usklađenost pretvaraju ta očekivanja u implementaciju spremnu za dokaze.
Zašto DORA prijavljivanje incidenata zakazuje pod pritiskom
Većina neuspjeha u DORA prijavljivanju incidenata ne počinje nemarom. Počinje nejasnoćom.
Sigurnosni analitičar vidi upozorenje, ali ne zna ispunjava li ono uvjete za incident povezan s IKT-om prema DORA. Voditelj IT usluge degradirane performanse tretira kao tehnički problem usluge, dok funkcija za usklađenost to smatra regulatornim događajem. Pravni poslovi čekaju potvrdu prije eskalacije. Poslovni vlasnik još ne može kvantificirati utjecaj na klijente. CISO traži dokaze, ali relevantni zapisi dnevnika raspršeni su po uslugama u oblaku, krajnjim uređajima, sustavima identiteta, SIEM-u i platformama dobavljača.
Dok se organizacija usuglasi oko klasifikacije, rok za prijavu već je pod pritiskom.
Članci 17 do 21 DORA uspostavljaju strukturirana očekivanja za upravljanje incidentima povezanima s IKT-om, klasifikaciju, prijavljivanje, sadržaj prijava i postupanje nadzornih tijela. Za financijske subjekte praktični je zahtjev jasan: pratiti, upravljati, zapisivati, klasificirati, prijavljivati, ažurirati i učiti iz incidenata povezanih s IKT-om na način koji se može naknadno rekonstruirati.
Clarysecova Politika odgovora na incidente [IRP] izravno ugrađuje DORA u referentni okvir:
EU DORA (2022/2554): članak 17: zahtjevi za prijavljivanje IKT incidenata financijskih institucija nadležnim tijelima.
Ista politika povezuje upravljanje incidentima s kontrolama ISO/IEC 27002:2022 5.25 do 5.27, koje obuhvaćaju odgovornosti za procjenu incidenata, odgovor, komunikaciju i poboljšanje.
Za manja fintech društva i vitke regulirane subjekte, Clarysecova Politika odgovora na incidente - SME [IRP-SME] čini obvezu provedivom naglašavajući da DORA od financijskih subjekata zahtijeva klasifikaciju, prijavljivanje i praćenje incidenata i poremećaja povezanih s IKT-om.
Ta je formulacija važna. DORA usklađenost nije samo obrazac za prijavu. Organizacija mora klasificirati, prijavljivati i pratiti. To znači dokaze o početnom događaju, kriterijima odlučivanja, razini ozbiljnosti, odluci o prijavljivanju, komunikaciji, radnjama oporavka, uključenosti dobavljača i daljnjim aktivnostima.
ISO/IEC 27001:2022 kao zapovjedno središte za DORA incidente
Zreo sustav upravljanja informacijskom sigurnošću prema ISO/IEC 27001:2022 ne smije postati još jedan silos usklađenosti pored DORA. Treba postati zapovjedno središte za DORA prijavljivanje incidenata.
ISMS već zahtijeva vlasništvo nad rizikom, odabir kontrola, internu reviziju, preispitivanje uprave, dokumentirane informacije, kontinuirano poboljšanje i dokaze o djelovanju kontrola. DORA dodaje sektorski specifičan pritisak izvješćivanja, ali ISO/IEC 27001:2022 daje upravljačku strukturu koja proces čini ponovljivim.
Clarysecov Zenith Blueprint: plan implementacije za revizore u 30 koraka [ZB] jača ovu integraciju u koraku 13, Planiranje obrade rizika i Izjava o primjenjivosti. Blueprint preporučuje mapiranje kontrola na rizike i točke radi sljedivosti, uključujući dodavanje reference na kontrolu iz Priloga A rizicima i bilježenje kada kontrole podržavaju GDPR, NIS2 ili DORA.
Za Sarahin incident s namirom plaćanja unos u registar rizika mogao bi glasiti:
„Poremećaj ili kompromitacija platforme za obradu plaćanja.”
Mapirane kontrole iz Priloga A norme ISO/IEC 27001:2022 uključivale bi 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 i 8.16, uz DORA napomenu za klasifikaciju i prijavljivanje velikog incidenta povezanog s IKT-om.
Clarysecov Zenith Controls: vodič za međusobnu usklađenost [ZC] zatim djeluje kao kompas za međusobnu usklađenost. U Zenith Controls, Clarysec mapira kontrole ISO/IEC 27002:2022 na druge kontrole ISO/IEC 27001:2022, povezane standarde, očekivanja revizije i regulative kao što su DORA, GDPR i NIS2. Ne stvara zasebne „Zenith kontrole”. Pokazuje kako postojeće ISO kontrole djeluju zajedno i kako se testiraju.
Tijek rada DORA prijavljivanja može se promatrati kao lanac kontrola:
| Potreba DORA prijavljivanja incidenta | Odnos s kontrolom iz Priloga A norme ISO/IEC 27001:2022 | Što revizori očekuju vidjeti |
|---|---|---|
| Otkrivanje sumnjivih IKT incidenata | 6.8 prijavljivanje događaja informacijske sigurnosti, 8.15 zapisivanje događaja, 8.16 aktivnosti praćenja | Kanali za prijavljivanje, pravila upozorenja, dokazi praćenja, osviještenost osoblja |
| Procjena je li događaj incident | 5.25 procjena i odluka o događajima informacijske sigurnosti | Matrica ozbiljnosti, bilješke o trijaži, dnevnici odluka, procjena utjecaja na poslovanje |
| Priprema procesa odgovora i prijavljivanja | 5.24 planiranje i priprema upravljanja incidentima informacijske sigurnosti | Plan odgovora na incidente, uloge, popisi kontakata, putovi eskalacije, tijek rada regulatornog izvješćivanja |
| Odgovor na potvrđeni incident | 5.26 odgovor na incidente informacijske sigurnosti | Zapisi o ograničavanju, komunikacije, poduzete radnje, dodijeljeni vlasnici |
| Očuvanje dokaza | 5.28 prikupljanje dokaza | Lanac čuvanja dokaza, snimke zapisa dnevnika, forenzički zapisi, postupak rukovanja dokazima |
| Učenje i poboljšanje | 5.27 učenje iz incidenata informacijske sigurnosti | Pregled nakon incidenta, analiza temeljnog uzroka, korektivne radnje, ažuriranja kontrola |
Ne možete prijaviti ono što niste otkrili. Ne možete klasificirati ono što niste procijenili. Ne možete opravdati odluku o prijavljivanju bez zapisa. Ne možete se poboljšati bez pregleda nakon incidenta.
Kontrola 6.8: DORA sat počinje s ljudima
U Sarahinom scenariju prvi koristan signal možda neće doći iz SOC-a. Može doći od voditelja odnosa s klijentima koji čuje pritužbe, financijskog korisnika koji vidi neuspjele serije namire ili inženjera koji uočava abnormalnu latenciju.
Zato je kontrola 6.8 iz Priloga A norme ISO/IEC 27001:2022, prijavljivanje događaja informacijske sigurnosti, ključna za DORA. Ona prijavljivanje čini odgovornošću radne snage, a ne samo funkcijom sigurnosnih operacija.
U Zenith Blueprint, korak 16, Kontrole osoblja II, Clarysec navodi:
Učinkovit sustav odgovora na incidente ne počinje alatima, nego ljudima.
Korak 16 preporučuje jasne kanale za prijavljivanje, obuku za sigurnosnu osviještenost, kulturu bez okrivljavanja, trijažu, povjerljivost i periodične simulacije. Najkorisnija praktična poruka jednostavna je:
„Ako ste u dvojbi, prijavite.”
To je DORA kontrolno načelo. Ako zaposlenici čekaju dok ne budu sigurni, organizacija gubi vrijeme. Ako prijave rano, organizacija može procijeniti, klasificirati i odlučiti.
U Zenith Controls, 6.8 mapirana je kao detektivna kontrola koja podupire povjerljivost, cjelovitost i dostupnost. Povezuje se s 5.24 jer kanali za prijavljivanje moraju biti dio plana za incidente. Hrani 5.25 jer se događaji mogu procijeniti samo ako su prijavljeni. Pokreće 5.26 jer formalni odgovor počinje nakon što se prijave ocijene.
Za DORA to podržava članke 17 i 18, prema kojima financijski subjekti moraju upravljati velikim incidentima povezanima s IKT-om i značajnim kibernetičkim prijetnjama, klasificirati ih i prijavljivati. Također podržava članak 33 i uvodnu izjavu 85 GDPR-a, jer interno prijavljivanje određuje koliko se brzo povreda osobnih podataka identificira i eskalira.
Praktična Clarysec implementacija jest jednostranična uputa „Kako prijaviti IKT incident”. Trebala bi uključivati:
- Što prijaviti, uključujući prekide usluga, sumnjive e-poruke, izgubljene uređaje, neuobičajeno ponašanje sustava, sumnju na kompromitaciju dobavljača, neovlašteni pristup, curenje podataka i degradaciju usluge koja utječe na klijente.
- Kako prijaviti, putem nadzirane poštanske kutije, kategorije zahtjeva, telefonske linije, komunikacijskog kanala ili SOC portala.
- Što uključiti, kao što su vrijeme, sustav, korisnik, poslovni proces, uočeni utjecaj, snimke zaslona ako je sigurno i informacija mogu li klijenti ili osobni podaci biti zahvaćeni.
- Što ne činiti, uključujući nebrisanje zapisa dnevnika, neponovno pokretanje kritičnih sustava osim prema uputi, nekontaktiranje klijenata prema van bez odobrenja i neprovođenje istrage izvan vlastite uloge.
- Što slijedi, uključujući trijažu, klasifikaciju, eskalaciju, odgovor, očuvanje dokaza i moguću regulatornu procjenu.
Cilj nije pretvoriti svakog zaposlenika u istražitelja. Cilj je učiniti svakog zaposlenika pouzdanim izvorom signala.
Kontrola 5.25: DORA točka odlučivanja o klasifikaciji
DORA prijavljivanje velikog incidenta povezanog s IKT-om ovisi o klasifikaciji. Tu kontrola 5.25 iz Priloga A norme ISO/IEC 27001:2022, procjena i odluka o događajima informacijske sigurnosti, postaje središnja.
Zenith Blueprint, korak 23, objašnjava praktični izazov:
Nije svaka anomalija katastrofa. Ne signalizira svako upozorenje kompromitaciju.
Zatim opisuje svrhu 5.25 kao:
razlikovanje bezopasnog od štetnog i razumijevanje onoga što zahtijeva eskalaciju.
Za DORA to je trenutak u kojem se sigurnosni događaj, degradacija usluge, prekid kod dobavljača, izloženost podataka ili operativni poremećaj procjenjuju prema kriterijima za veliki incident. Organizacija mora razmotriti operativni utjecaj, zahvaćene usluge, kritične ili važne funkcije, zahvaćene klijente i transakcije, trajanje, geografsku rasprostranjenost, utjecaj na podatke, reputacijske implikacije i ekonomski učinak.
U Zenith Controls, 5.25 mapirana je izravno na članak 18 DORA, klasifikaciju velikog IKT incidenta. To je strukturirani proces vrednovanja kojim se utvrđuje kvalificira li se uočeni događaj kao sigurnosni incident. Povezuje se i s 8.16, aktivnostima praćenja, jer se upozorenja i podaci iz zapisa dnevnika moraju trijažirati, te s 5.26, jer klasifikacija pokreće odgovor.
Tu mnoge organizacije padaju na revizijama. Imaju prijave, ali ne i klasifikacijske zapise. Imaju oznake ozbiljnosti, ali ne i kriterije. Imaju regulatorna izvješća, ali ne i trag odluke koji dokazuje zašto je incident bio ili nije bio smatran velikim.
Clarysec to rješava ugradnjom DORA klasifikacije u model ozbiljnosti incidenata. U korporativnoj Politici odgovora na incidente, točka 5.3.1 uključuje jasan primjer razine 1:
Razina 1: kritično (npr. potvrđena povreda podataka, izbijanje ransomwarea, kompromitacija produkcijskog sustava)
Za manje organizacije, Politika odgovora na incidente - SME dodaje strogo operativno očekivanje:
Glavni direktor, uz doprinos pružatelja IT usluga, mora klasificirati sve incidente prema ozbiljnosti u roku od jednog sata od obavijesti.
Taj cilj klasifikacije u roku od jednog sata snažan je jer nameće disciplinu upravljanja. Manji regulirani subjekt možda nema SOC 24/7, ali ipak može definirati tko klasificira, tko savjetuje i koliko brzo se odluka mora donijeti.
Zapis trijaže incidenta od DORA do ISO
Kako bi klasifikacija bila dokaziva, izradite DORA zapis trijaže incidenta u svojem sustavu za evidentiranje zahtjeva, GRC-u ili sustavu za upravljanje incidentima. Zapis treba izraditi za svaki potencijalno značajan IKT događaj, čak i ako se kasnije snizi njegova razina.
| Polje | Primjer unosa | Podržani dokaz kontrole |
|---|---|---|
| ID događaja | ICT-2026-0417-001 | 5.25, 5.26 |
| Izvor otkrivanja | SIEM upozorenje i izvješće operacija plaćanja | 6.8, 8.15, 8.16 |
| Vrijeme početne obavijesti | 08:17 CET | 6.8 |
| Početni procjenitelj | Voditelj SOC-a | 5.25 |
| Poslovni vlasnik | Voditelj plaćanja | 5.24, 5.26 |
| Zahvaćena kritična ili važna funkcija | Namira plaćanja | 5.25, DORA klasifikacija |
| Utjecaj na klijente ili transakcije | Odgođena obrada za korporativne klijente | 5.25 |
| Utjecaj na podatke | U istrazi, nema potvrđenog iznošenja podataka | 5.25, GDPR procjena |
| Uključenost dobavljača | Pružatelj infrastrukture u oblaku ima degradiranu uslugu | 5.24, eskalacija prema dobavljaču |
| Odluka o ozbiljnosti | Razina 1 kritično, čeka se potvrda | 5.25 |
| Odluka o DORA prijavljivanju | Potencijalni veliki IKT incident, obaviještena funkcija za usklađenost | 5.25, 5.26 |
| Očuvani dokazi | SIEM zapisi dnevnika, izvješća o statusu oblaka, telemetrija krajnjih uređaja | 5.28 |
| Vrijeme sljedećeg pregleda | 09:00 CET | 5.26 |
Dodajte bilješku o odluci:
„Na temelju poremećaja platne usluge koji utječe na kritični poslovni proces, neriješenog temeljnog uzroka i potencijalnog utjecaja na klijente, događaj se eskalira kao potencijalni veliki incident povezan s IKT-om. Funkcija za usklađenost i pravni poslovi procjenjuju zahtjeve regulatornog obavješćivanja. Pokrenuto je očuvanje dokaza.”
Ovaj jedan zapis podržava praćenje prema članku 17 DORA, klasifikaciju prema članku 18, odluke o prijavljivanju prema članku 19, procjenu prema Prilogu A 5.25 norme ISO/IEC 27001:2022, prijavljivanje prema 6.8, odgovor prema 5.26 i rukovanje dokazima prema 5.28.
Kontrole 5.24 i 5.26: planiranje, uloge i odgovor
Kada se dogodi DORA incident, plan odgovora već mora odgovoriti na neugodna pitanja.
Tko ima ovlast za klasifikaciju? Tko kontaktira nadležno tijelo? Tko odobrava početnu obavijest? Tko komunicira s klijentima? Tko kontaktira pružatelja IKT usluga treće strane? Tko odlučuje pokreće li incident i GDPR obavješćivanje? Tko čuva dokaze? Tko je vlasnik završnog izvješća?
Kontrola 5.24 iz Priloga A norme ISO/IEC 27001:2022, planiranje i priprema upravljanja incidentima informacijske sigurnosti, odgovara na ta pitanja prije krize. Kontrola 5.26, odgovor na incidente informacijske sigurnosti, osigurava da se plan tijekom incidenta pretvori u kontrolirano djelovanje.
U Zenith Controls, 5.24 povezana je s člancima 17 do 21 DORA jer operacionalizira dokumentiran, testiran i pregledan odgovor na incidente, uključujući internu eskalaciju, vanjsko regulatorno obavješćivanje, komunikaciju s dionicima i naučene lekcije.
ISO/IEC 27035-1:2023 to podupire proširivanjem upravljanja incidentima izvan postupaka odgovora na politiku, planiranje, sposobnosti, odnose, mehanizme podrške, osviještenost, obuku i redovito testiranje. ISO/IEC 27035-2:2023 dodatno razrađuje proces upravljanja incidentima od pripreme do naučenih lekcija.
Zenith Blueprint, korak 23, daje izravnu uputu za implementaciju:
Osigurajte ažuran plan odgovora na incidente (5.24), koji obuhvaća pripremu, eskalaciju, odgovor i komunikaciju.
Plan odgovora na incidente spreman za DORA trebao bi definirati:
- Tim za odgovor na IKT incidente i zamjenike.
- Ovlasti za klasifikaciju ozbiljnosti i DORA eskalaciju prijavljivanja.
- Odgovornosti pravnih poslova, funkcije za usklađenost, privatnosti, komunikacija, IT-a, sigurnosti, dobavljača i poslovnih vlasnika.
- Kriterije za klasifikaciju velikog incidenta povezanog s IKT-om.
- Postupke za početno, međufazno i završno regulatorno izvješćivanje.
- Procjenu okidača za GDPR, NIS2, ugovorno obavješćivanje, kibernetičko osiguranje i obavješćivanje uprave.
- Korake za ograničavanje, uklanjanje prijetnje, oporavak i provjeru.
- Zahtjeve za očuvanje dokaza.
- Postupke eskalacije prema dobavljaču i pristupa zapisima dnevnika.
- Praćenje naučenih lekcija i korektivnih radnji.
Politika odgovora na incidente - SME također povezuje rokove odgovora s pravnim zahtjevima:
Rokovi odgovora, uključujući oporavak podataka i obveze obavješćivanja, moraju biti dokumentirani i usklađeni s pravnim zahtjevima, kao što je GDPR zahtjev za prijavu povrede osobnih podataka u roku od 72 sata.
To je ključno jer jedan IKT incident može postati DORA veliki incident, GDPR povreda osobnih podataka, NIS2 značajni incident, ugovorni događaj obavješćivanja klijenta i pitanje upravljanja dobavljačima. Plan mora koordinirati te slojeve umjesto da ih tretira kao odvojene svjetove.
Kontrole 8.15 i 8.16: zapisi dnevnika čine izvješće dokazivim
DORA prijavljivanje incidenata ovisi o činjenicama. Činjenice ovise o zapisivanju događaja i praćenju.
U scenariju namire plaćanja Sarah mora znati kada je degradacija počela, koji su sustavi bili zahvaćeni, jesu li korišteni povlašteni računi, jesu li podaci napustili okruženje, poklapa li se prekid kod pružatelja usluga u oblaku s internom telemetrijom i kada je oporavak završen.
Kontrola 8.15 iz Priloga A norme ISO/IEC 27001:2022, zapisivanje događaja, i 8.16, aktivnosti praćenja, podupiru ovu dokaznu osnovu. U Zenith Controls, obje se povezuju s 5.24 jer planiranje odgovora na incidente mora uključivati upotrebljive podatke iz zapisa dnevnika i sposobnost praćenja. Kontrola 8.16 povezuje se i s 5.25 jer se upozorenja moraju trijažirati u odluke.
Clarysecova Politika zapisivanja događaja i praćenja - SME [LMP-SME] uključuje praktičan zahtjev za eskalaciju:
Upozorenja visokog prioriteta moraju se eskalirati glavnom direktoru i koordinatoru za privatnost u roku od 24 sata
Za subjekte regulirane DORA, potencijalno veliki IKT incidenti obično zahtijevaju brži model operativne eskalacije, osobito kada su zahvaćene kritične ili važne funkcije. Ipak, obrazac upravljanja je ispravan: upozorenja visokog prioriteta ne smiju ostati unutar IT-a. Moraju doći do poslovnih, privatnosnih i upravljačkih uloga.
Model zapisivanja događaja spreman za DORA trebao bi uključivati:
- Centralizirano zapisivanje događaja za kritične sustave, platforme identiteta, krajnje uređaje, usluge u oblaku, alate za mrežnu sigurnost i poslovne aplikacije.
- Sinkronizaciju vremena između sustava kako bi vremenski slijedovi incidenata bili pouzdani.
- Kategorizaciju upozorenja usklađenu s ozbiljnošću incidenta i DORA klasifikacijom.
- Zadržavanje zapisa dnevnika usklađeno s regulatornim, ugovornim i forenzičkim potrebama.
- Kontrole pristupa koje štite cjelovitost zapisa dnevnika.
- Postupke za izradu snimki zapisa dnevnika tijekom velikih incidenata.
- Zahtjeve za pristup zapisima dnevnika dobavljača za kritične IKT usluge.
Revizori neće prihvatiti „SIEM to ima” kao dovoljan dokaz. Pitat će jesu li postojali odgovarajući zapisi dnevnika, jesu li upozorenja pregledana, je li eskalacija provedena na vrijeme i jesu li zapisi dnevnika očuvani nakon što je incident postao potencijalno prijavljiv.
Kontrola 5.28: prikupljanje dokaza i lanac čuvanja dokaza
U velikom incidentu povezanom s IKT-om dokazi služe trima svrhama: tehničkoj istrazi, regulatornoj odgovornosti i pravnoj dokazivosti.
Ako su dokazi nepotpuni, prepisani, izmijenjeni ili nedokumentirani, organizacija može teško dokazati što se dogodilo. Može teško opravdati i svoju klasifikacijsku odluku.
Clarysecova Politika prikupljanja dokaza i forenzike [ECF] navodi:
Dnevnik lanca čuvanja dokaza mora pratiti sve fizičke ili digitalne dokaze od trenutka prikupljanja do arhiviranja ili prijenosa te mora dokumentirati:
SME verzija, Politika prikupljanja dokaza i forenzike - SME [ECF-SME], zadržava zahtjev jednostavnim:
Svaka stavka digitalnog dokaza mora biti evidentirana s:
Operativna pouka je izravna. Rukovanje dokazima ne može početi tek nakon što pravni poslovi to zatraže. Mora biti ugrađeno u odgovor na incidente.
ISO/IEC 27006-1:2024 jača ovo revizijsko očekivanje naglašavanjem postupaka za identifikaciju, prikupljanje i očuvanje dokaza iz incidenata informacijske sigurnosti. Za DORA isti skup dokaza može podržati početnu obavijest, međufazna ažuriranja, završno izvješće, pregled nakon incidenta i pitanja nadzornog tijela.
Praktičan kontrolni popis dokaza za incidente povezane s DORA trebao bi uključivati:
- Prijavu incidenta i bilješke o trijaži.
- Vremenski slijed otkrivanja, eskalacije, klasifikacije, prijavljivanja, ograničavanja, oporavka i zatvaranja.
- SIEM upozorenja i korelirane zapise dnevnika.
- Artefakte krajnjih uređaja i poslužitelja.
- Zapise dnevnika identiteta i privilegiranog pristupa.
- Sažetke mrežnog prometa.
- Status pružatelja usluga u oblaku i revizijske zapise.
- Komunikaciju s dobavljačima i izjave o incidentu.
- Zapise o utjecaju na poslovanje, uključujući klijente, usluge, transakcije i vrijeme nedostupnosti.
- Nacrte i podneske regulatornih obavijesti.
- Odluke i odobrenja uprave.
- Analizu temeljnog uzroka.
- Naučene lekcije i korektivne radnje.
Dokazi moraju prikazati i tehničke činjenice i upravljačke odluke. DORA prijavljivanje nije samo pitanje onoga što se dogodilo sustavima. Riječ je i o tome kako je uprava prepoznala, procijenila, eskalirala i kontrolirala incident te kako se na temelju njega poboljšala.
Kontrola 5.27: naučene lekcije i kontinuirano poboljšanje
DORA incident nije zatvoren kada se podnese završno izvješće. Zatvoren je kada je organizacija iz njega učila, dodijelila korektivne radnje, ažurirala kontrole i provjerila poboljšanje.
Kontrola 5.27 iz Priloga A norme ISO/IEC 27001:2022, učenje iz incidenata informacijske sigurnosti, povezuje DORA prijavljivanje s ciklusom kontinuiranog poboljšanja prema ISO/IEC 27001:2022. U Zenith Controls, 5.24 povezana je s 5.27 jer je upravljanje incidentima nepotpuno bez analize temeljnog uzroka, naučenih lekcija i poboljšanja kontrola.
Zenith Blueprint, korak 23, upućuje organizacije da ažuriraju plan na temelju naučenih lekcija i osiguraju ciljano osposobljavanje o odgovoru na incidente i rukovanju dokazima. To je osobito važno za DORA jer ponavljajuća kašnjenja u klasifikaciji, nedostajući dokazi dobavljača, slabi zapisi dnevnika ili nejasna komunikacija mogu postati predmet nadzorne zabrinutosti.
Predložak naučenih lekcija trebao bi obuhvatiti:
- Što se dogodilo i kada.
- Koje su kritične ili važne funkcije bile zahvaćene.
- Je li klasifikacija bila pravodobna i točna.
- Jesu li odluke o DORA prijavljivanju donesene uz dostatne dokaze.
- Jesu li procijenjeni okidači za GDPR, NIS2, ugovorno ili klijentsko obavješćivanje.
- Jesu li dobavljači odgovorili u dogovorenim rokovima.
- Jesu li zapisi dnevnika i forenzički dokazi očuvani.
- Koje su kontrole zakazale ili nedostajale.
- Koje se politike, operativne upute, obuka ili tehničke kontrole moraju poboljšati.
- Tko je vlasnik svake korektivne radnje i do kada.
To također ulazi u preispitivanje uprave prema ISO/IEC 27001:2022. Trendove incidenata treba pregledavati rukovodstvo, a ne ih zakopati u tehničke naknadne analize.
Međusobna usklađenost: DORA, GDPR, NIS2, NIST i COBIT 2019
DORA je središnja tema za financijske subjekte, ali prijavljivanje incidenata rijetko pripada samo jednom okviru.
Jedan IKT incident može uključivati DORA prijavljivanje velikog incidenta povezanog s IKT-om, GDPR prijavu povrede osobnih podataka, NIS2 prijavljivanje značajnog incidenta, obveze iz ugovora s klijentima, obavješćivanje kibernetičkog osiguratelja i izvješćivanje upravi.
Zenith Controls pomaže smanjiti tu složenost mapiranjem kontrola ISO/IEC 27002:2022 kroz okvire. Primjerice:
| Kontrola iz Priloga A norme ISO/IEC 27001:2022 | Odnos s DORA | Odnos s drugim zahtjevima usklađenosti |
|---|---|---|
| 5.24 planiranje i priprema upravljanja incidentima informacijske sigurnosti | Podržava članke 17 do 21 DORA kroz dokumentirane i testirane procese za incidente | Podržava članke 33 i 34 GDPR-a, ISO/IEC 27035-1:2023, ISO/IEC 27035-2:2023 |
| 5.25 procjena i odluka o događajima informacijske sigurnosti | Podržava klasifikaciju prema članku 18 DORA | Podržava GDPR vrednovanje rizika povrede i očekivanja trijaže događaja |
| 6.8 prijavljivanje događaja informacijske sigurnosti | Podržava članke 17 i 18 DORA kroz interne okidače prijavljivanja | Podržava članak 33 i uvodnu izjavu 85 GDPR-a te očekivanja eskalacije iz članka 23 NIS2 |
| 8.15 zapisivanje događaja | Podržava vremenske slijedove incidenata i tehničke dokaze | Podržava forenzičke, revizijske, privatnosne i ugovorne dokazne potrebe |
| 8.16 aktivnosti praćenja | Podržava otkrivanje, upozoravanje i trijažu | Podržava NIST Detect ishode i praćenje operativne otpornosti |
Iz NIST perspektive isti model podržava ishode Detect, Respond i Recover. Iz perspektive COBIT 2019 i ISACA revizije, fokus je na upravljanju: jesu li upravljanje incidentima, neprekidnost, rizik, usklađenost, odgovornosti dobavljača i praćenje uspješnosti pod kontrolom.
Najzrelije organizacije ne stvaraju zasebne tijekove rada za svaki okvir. Stvaraju jedan proces upravljanja incidentima s regulatornim slojevima. Prijava jednom bilježi iste temeljne činjenice, a zatim se prema potrebi grana na DORA, GDPR, NIS2, ugovorno, osigurateljno ili sektorski specifično izvješćivanje.
Kako će revizori testirati vaš DORA proces za incidente
Proces prijavljivanja incidenata spreman za DORA mora izdržati različite revizijske perspektive.
Revizor ISO/IEC 27001:2022 ispitat će je li ISMS odabrao i implementirao relevantne kontrole iz Priloga A, podupire li Izjava o primjenjivosti te kontrole, postoje li zapisi o incidentima te uključuju li interna revizija i preispitivanje uprave učinkovitost upravljanja incidentima.
Zenith Controls navodi metodologiju revizije prema ISO/IEC 19011:2018 za 5.24, 5.25 i 6.8. Za 5.24 revizori pregledavaju plan odgovora na incidente u pogledu vrsta incidenata, klasifikacija ozbiljnosti, dodijeljenih uloga, popisa kontakata, putova eskalacije, uputa za regulatorno izvješćivanje i komunikacijskih odgovornosti. Za 5.25 pregledavaju postoje li dokumentirani klasifikacijski kriteriji, kao što su matrice ozbiljnosti ili stabla odlučivanja temeljena na utjecaju sustava, osjetljivosti podataka i trajanju. Za 6.8 procjenjuju mehanizme prijavljivanja, metrike vremena do prijave i dokaze da su prijavljeni događaji zapisani, trijažirani i riješeni.
DORA nadzorni pregled usredotočit će se na to otkrivaju li se, klasificiraju, prijavljuju, ažuriraju i zatvaraju veliki incidenti povezani s IKT-om u skladu s regulatornim očekivanjima. Pregledavatelj može zatražiti uzorak incidenta i pratiti ga od prvog upozorenja do završnog izvješća.
Revizor privatnosti usredotočit će se na to je li procijenjen rizik povrede osobnih podataka i jesu li pokrenute obveze iz članka 33 i članka 34 GDPR-a. BS EN 17926:2023 ovdje je relevantan jer dodaje odgovornosti za incidente privatnosti, kriterije obavješćivanja, vremenske zahtjeve i usklađivanje s očekivanjima nadzornog otkrivanja.
| Revizijska perspektiva | Vjerojatno pitanje | Dokazi koje Clarysec priprema |
|---|---|---|
| ISO/IEC 27001:2022 | Jesu li kontrole za incidente odabrane, implementirane i učinkovite? | SoA, plan odgovora na incidente, prijave, zapisi interne revizije, izlazni rezultati preispitivanja uprave |
| DORA | Možete li dokazati pravodobnu klasifikaciju i prijavljivanje velikih IKT incidenata? | DORA zapis trijaže, klasifikacijska matrica, registar regulatornog izvješćivanja, vremenski slijed incidenta |
| GDPR | Jeste li procijenili jesu li osobni podaci povrijeđeni i obavijestili ako je potrebno? | Procjena privatnosti, bilješke o utjecaju na podatke, odluka o obavješćivanju nadzornog tijela, zapis komunikacije s ispitanicima |
| NIS2 | Je li incident promptno eskaliran i koordiniran zbog utjecaja na uslugu? | Zapisi o eskalaciji, procjena utjecaja na poslovanje, dnevnik komunikacije |
| NIST | Jesu li aktivnosti Detect, Respond i Recover operativne? | Upozorenja iz praćenja, operativne upute za odgovor, provjera oporavka, naučene lekcije |
| COBIT 2019 i ISACA | Je li prijavljivanje incidenata upravljano, mjereno i poboljšavano? | RACI, KPI-jevi, dokazi dobavljača, praćenje usklađenosti, korektivne radnje |
Isti dokazi mogu zadovoljiti više revizijskih pitanja ako su od početka pravilno strukturirani.
Kontrolni popis spremnosti za DORA prijavljivanje incidenata u 2026.
Prije sljedeće stolne vježbe, interne revizije ili nadzornog pregleda, testirajte organizaciju prema ovom kontrolnom popisu:
- Znaju li zaposlenici kako prijaviti sumnju na IKT incident?
- Postoji li namjenski kanal za prijavljivanje incidenata?
- Zapisuje li se i trijažira sigurnosne događaje dosljedno?
- Postoji li dokumentirana matrica ozbiljnosti i DORA klasifikacije velikih incidenata?
- Je li klasifikacija obvezna unutar definiranog vremena nakon obavijesti?
- Jesu li kritične ili važne funkcije mapirane na sustave i dobavljače?
- Procjenjuju li se DORA, GDPR, NIS2, ugovorni, osigurateljni i klijentski okidači obavješćivanja u jednom tijeku rada?
- Jesu li uloge za incidente definirane kroz IT, sigurnost, pravne poslove, usklađenost, privatnost, komunikacije i poslovne vlasnike?
- Jesu li zapisi dnevnika dovoljni za rekonstrukciju vremenskih slijedova incidenata?
- Čuvaju li se dokazi uz lanac čuvanja dokaza?
- Jesu li testirane obveze dobavljača za incidente i prava pristupa zapisima dnevnika?
- Provode li se stolne vježbe s realističnim DORA scenarijima?
- Prate li se naučene lekcije do korektivnih radnji?
- Pregledavaju li se metrike incidenata u preispitivanju uprave?
- Je li Izjava o primjenjivosti mapirana na ISO/IEC 27001:2022 kontrole relevantne za DORA?
Ako je odgovor na bilo koje od ovih pitanja „djelomično”, problem nije samo usklađenost. To je operativna otpornost.
Izgradite model DORA prijavljivanja incidenata spreman za dokaze
DORA prijavljivanje incidenata u 2026. test je upravljanja pod pritiskom. Organizacije koje će dobro djelovati neće biti one s najduljim dokumentima odgovora na incidente. Bit će to one s jasnim kanalima za prijavljivanje, brzom klasifikacijom, pouzdanim zapisima dnevnika, očuvanim dokazima, osposobljenim ljudima, testiranom eskalacijom prema dobavljačima i sljedivošću kroz više okvira.
Clarysec vam može pomoći izgraditi taj operativni model.
Započnite mapiranjem rizika incidenata i Izjave o primjenjivosti uz Zenith Blueprint: plan implementacije za revizore u 30 koraka. Zatim uskladite kontrole incidenata s Zenith Controls: vodič za međusobnu usklađenost. Provedite proces u praksi pomoću Clarysecove Politike odgovora na incidente, Politike odgovora na incidente - SME, Politike zapisivanja događaja i praćenja - SME, Politike prikupljanja dokaza i forenzike i Politike prikupljanja dokaza i forenzike - SME.
Ako vaš rukovodeći tim želi sigurnost prije sljedećeg stvarnog incidenta, provedite DORA stolnu vježbu velikog incidenta povezanog s IKT-om uz Clarysecov skup alata i izradite paket dokaza koji bi revizor ili nadzorno tijelo očekivali vidjeti.
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


