NIS2, DORA in ponudniki programske opreme: kaj nam je potrdila predstavitev INCIDENTRON v Bruslju

Znanje
Čas branja: 4 min

NIS2, DORA in ponudniki programske opreme: kaj nam je potrdila predstavitev INCIDENTRON v Bruslju

Izbira ponudnika programske opreme ni več samo tehnološka odločitev. V reguliranih okoljih je to tudi odločitev o operativni odpornosti, upravljanju in vse pogosteje tudi o skladnosti. To je bil eden najjasnejših vtisov, ki smo jih odnesli s predstavitve projekta INCIDENTRON v Bruslju 25. februarja 2026. Kot soustvarjalci rešitve DORApp z dogodka nismo odšli z mislijo na funkcionalnosti programske opreme. Odšli smo z mislijo na operativno realnost: kaj se dejansko zgodi znotraj organizacije, ko pride do resnega kibernetskega incidenta, ko začne teči več poročevalskih rokov hkrati, podjetje pa še vedno poskuša omejiti škodo in ponovno vzpostaviti nadzor.

To je pomembno zato, ker je evropsko regulativno okolje vse zahtevnejše. NIS2 vzpostavlja skupni okvir kibernetske varnosti za 18 kritičnih sektorjev v EU, DORA pa se za finančne subjekte uporablja od 17. januarja 2025. V praksi to pomeni, da lahko en sam operativni dogodek hkrati sproži več različnih obveznosti poročanja in upravljanja, pogosto z različnimi pragovi, različnimi organi, različnimi časovnicami in različnimi nacionalnimi interpretacijami.

Projekt INCIDENTRON je zasnovan prav okoli tega izziva. Po uradnem opisu želi poenostaviti poročanje o kibernetskih incidentih po Evropi v okviru NIS2, DORA, GDPR, Cyber Resilience Act in razvijajočih se pobud, kot je Digital Omnibus, pri čemer temelji na modularnem odprtokodnem pristopu za celovito podporo poročanju. Prav zato je bil ta dogodek za nas tako relevanten: potrdil je problem, ki ga na trgu opažamo že dlje časa.

En incident, več obveznosti

Najpomembnejše sporočilo iz Bruslja je bilo preprosto: en incident je treba znotraj organizacije obravnavati kot en operativni dogodek, tudi če zunaj organizacije sproži več različnih pravnih obveznosti. Na dogodku je bilo to zelo jasno prikazano skozi scenarij, v katerem je kritični incident takoj odprl vprašanja na področju varnosti, prava, zasebnosti, neprekinjenega poslovanja in izvršnega vodenja. Kdo vodi postopek? Katera regulativa se uporabi? Kateri rok začne teči prvi? Kateri organ je treba obvestiti? Kateri podatki manjkajo? To niso abstraktna vprašanja skladnosti. To so vprašanja, ki se pojavijo takrat, ko sistemi ne delujejo, primarni cilj pa je še vedno zamejitev incidenta in okrevanje.

Prav zato se je tudi način izbire ponudnikov programske opreme v reguliranih sektorjih spremenil. Dober demo, konkurenčna ponudba in obljuba hitre izvedbe niso več dovolj. Pravo vprašanje je, ali ponudnik razume, kaj se dogaja po produkciji, pod pritiskom, ko organizacija ne potrebuje le funkcionalnosti, temveč tudi strukturo, jasnost in sledljivost.

Kaj je to potrdilo za nas v okviru razvoja DORApp

Z našega vidika je dogodek zelo jasno potrdil, da je smer, v katero je zasnovan pristop DORApp k poročanju o incidentih, pravilna. Resnična boleča točka ni zgolj “oddaja poročila”. Gre za navigacijo skozi prekrivajoče se zakonodajne okvire v času operativnega kaosa, ko različne ekipe ob različnih trenutkih potrebujejo različne informacije. Prav zato poročanja o incidentih ni mogoče obravnavati kot preprosto izpolnjevanje obrazca. Obravnavati ga je treba kot voden operativni delovni tok.

Ena bolj izstopajočih ugotovitev, omenjenih na dogodku, je bila, da pomemben delež finančnih subjektov med incidentom porabi od 4 do 24 ur samo za aktivnosti poročanja, ne za reševanje incidenta, ampak za poročanje. Če to drži, potem to breme ni zgolj administrativno. Neposredno tekmuje s kapaciteto odzivanja ravno v najslabšem možnem trenutku.

Prav tukaj menimo, da trg še vedno podcenjuje problem. Ob večjem incidentu je prvi instinkt seveda vzpostaviti storitve, omejiti škodo in ponovno pridobiti nadzor. Toda breme poročanja ne čaka v ozadju. Poveča pritisk točno takrat, ko je interna jasnost najmanjša. Vsak ponudnik, ki gradi rešitve za regulirane sektorje, mora razumeti to realnost. Upravljanje incidentov in poročanje o incidentih ne moreta ostati ločena svetova.

Katera vprašanja o ponudniku programske opreme so danes najpomembnejša

Po Bruslju bi vprašanje ocenjevanja ponudnikov zastavili nekoliko drugače kot prej.

Še vedno je pomembno vprašati, kako ponudnik obravnava varnost pri načrtovanju, razvoju, uvedbi in vzdrževanju. Še vedno je pomembno vprašati, kako upravlja spremembe, izdaje, dnevnike, odvisnosti in podporo. Toda za regulirane kupce to ni več dovolj. Bolj razkrivajoča vprašanja so drugačna.

Ali lahko ponudnik podpira strukturirano odločanje med incidentom, ne le med običajnim delovanjem? Ali lahko pomaga vnaprej opredeliti odgovornosti, eskalacijske poti in potrebne podatke, še preden do incidenta pride? Ali lahko zmanjša zmedo med pravno službo, skladnostjo, ICT, zasebnostjo in vodstvom? Ali lahko zasnuje sistem, ki pod pritiskom ustvarja doslednost, namesto da ekipe znova potiska v e-poštne niti, Excel tabele in ročno sestavljena poročila? To so vprašanja, ki danes ločijo resnično uporabnega ponudnika od zgolj tehnično sposobnega ponudnika.

Povedano drugače: kupci ne bi smeli vprašati samo, ali sistem deluje. Vprašati bi morali, ali sistem pomaga organizaciji ohraniti nadzor takrat, ko so čas, informacije in odgovornost vsi hkrati pod pritiskom.

Pomemben poudarek z dogodka

Ena niansa, ki smo jo odnesli s predstavitve, je bila, da je bil velik del razprave in številnih primerov močno usmerjen v GDPR, kar je glede na sestavo okrogle mize in prisotne deležnike razumljivo. Za nas pa je to odprlo tudi pomembno strateško vprašanje: koliko je trenutna tržna razprava res osredotočena na operativno realnost finančnih institucij, ki jih ureja DORA, in koliko jo še vedno oblikujejo širše izkušnje s poročanjem o kršitvah varstva podatkov? To ni kritika pobude. Je pa pomembna razlika za pozicioniranje produkta in za vse odločitve o sodelovanju, ki jih v tem prostoru sprejemamo.

Prišli smo tudi do zelo praktičnega zaključka: projekti, kot je INCIDENTRON, so obetavni, vendar so še v razvoju. Uradna predstavitev projekta ga postavlja kot prihodnjo operativno plast, ki lahko dopolni pristop tipa “single entry point”, ne pa čez noč nadomesti vseh nacionalnih in sektorskih posebnosti. Smer je zato zanimiva, a to hkrati pomeni, da morajo tako kupci kot ponudniki ostati prizemljeni. Potreba obstaja že danes, tudi če se širši ekosistem še oblikuje.

Zaključna misel

Sporočilo za regulirana podjetja je preprosto: ponudnikov programske opreme ne ocenjujte samo po tem, kaj lahko zgradijo. Ocenjujte jih po tem, ali razumejo okolje, v katerem delujete, ko gre kaj narobe. V obdobju NIS2 in DORA operativna odpornost ni samo vprašanje infrastrukture, skladnost pa ni samo vprašanje obrazcev. Gre za to, ali se lahko vaša organizacija od zaznave incidenta premakne do usklajenega ukrepanja, zbiranja dokazov, poročanja in nadaljnjih aktivnosti, ne da bi pri tem izgubila nadzor nad situacijo.

Za nas dogodek v Bruslju ni spremenil smeri. Jo je pa razjasnil. Prihodnost poročanja o incidentih v Evropi bo zelo verjetno bolj povezana, bolj avtomatizirana in bolj podprta s pravili. Toda največ bodo od tega imele organizacije, ki se bodo pripravile že danes: z jasno določenimi odgovornostmi, strukturiranimi delovnimi tokovi in izbiro programskih partnerjev, ki razumejo, da en incident nikoli ni samo en tehnični dogodek. Je hkrati operativni, regulativni in organizacijski stresni test.