Od 11. rujna 2026. u Europskoj uniji primjenjuju se obveze prijavljivanja iz Akta o kibernetičkoj otpornosti, poznatog pod kraticom CRA. Proizvođači obuhvaćenih proizvoda s digitalnim elementima od tog datuma moraju prijaviti aktivno iskorištene ranjivosti i ozbiljne incidente koji utječu na sigurnost proizvoda.

Istoga dana ENISA je pustila u rad jedinstvenu platformu za prijavljivanje, a 17. rujna dopunila je praktična pitanja i odgovore o registraciji, rokovima i postupku prijave. To je važan signal hrvatskim tvrtkama koje razvijaju aplikacije, programske dodatke, povezane uređaje ili druge digitalne proizvode: više nije dovoljno imati osobu koja će tehnički ukloniti pogrešku. Potrebno je znati tko donosi odluku o prijavi, koje informacije prikuplja i kako reagira unutar vrlo kratkog roka.

Nova obveza ne odnosi se automatski na svaku web-stranicu, internu automatizaciju ili uslugu u oblaku. Prvi korak zato nije panično prijavljivanje, nego precizno utvrđivanje proizvoda, uloge tvrtke i opsega odgovornosti.

Što se promijenilo 11. rujna 2026.?

CRA je već stupio na snagu, ali se njegove odredbe uvode postupno. Od 11. rujna primjenjuje se obveza prijave dviju vrsta sigurnosnih događaja: aktivno iskorištene ranjivosti u proizvodu i ozbiljnog incidenta koji utječe na sigurnost proizvoda.

Početno upozorenje mora se poslati bez nepotrebnog odgađanja, najkasnije 24 sata nakon što je proizvođač saznao za događaj. Detaljnija prijava slijedi u roku od 72 sata. Nakon toga predviđen je i završni izvještaj, čiji rok ovisi o tome prijavljuje li se ranjivost ili ozbiljan incident.

Prijava se podnosi kroz ENISA-inu jedinstvenu platformu. Time proizvođač ne mora odvojeno obavještavati više nacionalnih tijela, ali jedinstveni obrazac ne uklanja potrebu za internom procjenom. Tvrtka i dalje mora dovoljno brzo prepoznati incident, prikupiti činjenice, procijeniti posljedice i odrediti ulazi li događaj u obveznu prijavu.

Glavni zahtjevi CRA-a, uključujući širi skup sigurnosnih zahtjeva za razvoj, dokumentaciju i održavanje proizvoda, primjenjivat će se od 11. prosinca 2027. Sadašnji rok zato treba promatrati kao prvu operativnu kontrolnu točku, a ne kao završetak pripreme.

Odnose li se nova pravila na vaš softver?

CRA je usmjeren na proizvode s digitalnim elementima koji se stavljaju na tržište Europske unije. To uključuje softverske i hardverske proizvode, njihove komponente te određena udaljena rješenja za obradu podataka bez kojih proizvod ne bi mogao izvršavati svoju funkciju.

Posebno je važna uloga proizvođača. Obveze su prvenstveno usmjerene na pravnu ili fizičku osobu koja proizvod razvija ili daje razviti te ga stavlja na tržište pod vlastitim imenom ili žigom. Vanjski razvojni tim zato ne postaje automatski proizvođač samo zato što je napisao programski kod. Odgovornost ovisi o ugovornom odnosu, načinu predstavljanja proizvoda i stvarnoj kontroli nad njegovim razvojem i održavanjem.

Obična prezentacijska web-stranica u pravilu nije isto što i softverski proizvod stavljen na tržište. Ni svaka SaaS usluga nije automatski obuhvaćena samo zato što radi u oblaku. S druge strane, mobilna aplikacija, programski dodatak, samostalna poslovna aplikacija ili usluga u oblaku koja je nužna za rad povezanog proizvoda mogu zahtijevati detaljniju procjenu.

Za početnu provjeru korisno je odgovoriti na četiri pitanja:

Prodaje li se ili distribuira softver kao zaseban proizvod ili komponenta?
Pod čijim imenom ili žigom proizvod dolazi do korisnika?
Tko odlučuje o funkcijama, sigurnosnim ažuriranjima i razdoblju podrške?
Postoji li udaljena usluga bez koje proizvod ne može obavljati jednu od svojih funkcija?

Zašto rok od 24 sata mijenja interni proces?

Najveći praktični problem nije samo ispunjavanje obrasca, nego vrijeme koje prethodi prijavi. Sigurnosnu dojavu može prvi primiti korisnička podrška, vanjski programer, voditelj proizvoda, hosting partner ili zaposlenik koji prati poruke na općoj adresi e-pošte. Ako nitko nije odgovoran za usmjeravanje dojave, velik dio roka može proći prije nego što slučaj stigne do osobe koja razumije njegovu ozbiljnost.

Zamislimo hrvatsku tvrtku koja pod svojim imenom prodaje programski dodatak za upravljanje narudžbama. Istraživač sigurnosti u petak poslijepodne javlja da se ranjivost već koristi za neovlašten pristup podacima. Poruka stiže na adresu korisničke podrške, a razvoj održava vanjski partner.

Bez unaprijed dogovorenog postupka tvrtka tek u ponedjeljak pokušava utvrditi verzije dodatka, broj korisnika, način iskorištavanja i osobu ovlaštenu za prijavu. Uz jasan postupak podrška odmah otvara sigurnosni slučaj, obavještava odgovornu osobu i tehnički tim, čuva izvornu dojavu te pokreće procjenu obveze prijavljivanja.

Važno je razlikovati dojavu od potvrđenog događaja, ali se ne smije čekati potpuno uklanjanje problema prije pokretanja procjene. Rokovi su upravo zato podijeljeni na rano upozorenje, detaljniju prijavu i završni izvještaj.

Što pripremiti prije prvog stvarnog incidenta?

Tvrtka koja bi mogla biti proizvođač obuhvaćenog softvera treba uspostaviti najmanji održivi postupak prije nego što stigne ozbiljna dojava. Za početak nije nužan složen sigurnosni centar, ali odgovornosti i podaci ne smiju ostati neodređeni.

Popis digitalnih proizvoda: zabilježite naziv, verzije, tržišta, vlasnika proizvoda, vanjske razvojne partnere i razdoblje podrške.
Jedno mjesto za dojave: odredite nadziranu adresu ili obrazac za prijavu ranjivosti i objasnite zaposlenicima kamo proslijediti sigurnosne poruke.
Odgovornu osobu i zamjenu: mora biti jasno tko vodi procjenu, tko smije podnijeti prijavu i tko preuzima postupak izvan redovnog radnog vremena.
Tehničke izvore podataka: osigurajte pristup evidenciji verzija, zapisima sustava, popisu komponenti, sigurnosnim kopijama i podacima o distribuciji proizvoda.
Ugovore s partnerima: definirajte koliko brzo vanjski programer ili pružatelj infrastrukture mora odgovoriti i koje informacije mora dostaviti.
Probni scenarij: provedite stolnu vježbu u kojoj dojava stiže u petak poslijepodne i provjerite može li tim u 24 sata prikupiti dovoljno podataka za početno upozorenje.

Automatizacija može pomoći tako da sigurnosnu poruku pretvori u prioritetni slučaj, obavijesti odgovorne osobe i zabilježi vrijeme svakog koraka. Ipak, odluku o zakonskoj obvezi i sadržaju prijave ne treba prepustiti nekontroliranom automatiziranom pravilu.

Sigurnost treba ugraditi u vlasništvo nad sustavom

Nejasna odgovornost često nastaje kada tvrtka naruči razvoj, ali ne ugovori održavanje, praćenje ranjivosti i postupanje nakon incidenta. Predaja izvornog koda sama po sebi ne odgovara na pitanja tko prati korištene komponente, tko izdaje zakrpe i kako se korisnici obavještavaju o sigurnosnom ažuriranju.

Naša usluga razvoja digitalnih sustava i automatizacije poslovanja obuhvaća poslovne aplikacije, SaaS platforme, online rezervacije i povezivanje podataka prema stvarnom načinu rada tvrtke. Projekt Zemma.app, primjerice, povezuje javnu rezervaciju, administrativne panele, CMS i automatizirane komunikacije u jedan sustav. Takva povezanost dobro pokazuje zašto pri planiranju digitalnog proizvoda treba dokumentirati komponente, ovlasti i odgovornosti, iako sama po sebi ne znači da konkretan sustav automatski ulazi u područje CRA-a.

Kontrolna odluka za vlasnika tvrtke glasi: ako razvijate ili pod svojim imenom nudite softver, možete li danas imenovati proizvod, odgovornu osobu, razvojne partnere i postupak koji se pokreće čim stigne sigurnosna dojava? Ako ne možete, priprema treba početi mapiranjem sustava i ugovornih odgovornosti, prije kupnje još jednog sigurnosnog alata.

Ako želite pregledati vlasništvo, održavanje i tok sigurnosnih informacija u svojoj aplikaciji ili digitalnom sustavu, možete nam se javiti za početni razgovor. Cilj pregleda nije unaprijed pretpostaviti da se CRA primjenjuje, nego otkriti gdje nedostaju podaci i odgovornosti potrebni za brzu i kontroliranu reakciju.