Ransomware koji zaustavi rad računovodstva, nedostupan sustav za narudžbe ili kompromitiran administratorski račun više nisu samo problemi IT odjela. NIS2 zahtjevi 2026 traže da organizacije koje ulaze u područje primjene upravljaju takvim rizicima na razini cijelog poslovanja, uz jasnu odgovornost uprave, provjerljive mjere zaštite i sposobnost pravodobne prijave ozbiljnih incidenata.
Za direktora to ne znači da mora odlučivati o konfiguraciji vatrozida. Znači da mora znati koje su ključne usluge tvrtke, gdje su podaci, tko ima pristup sustavima, koliko dugo poslovanje može funkcionirati bez pojedinog sustava i tko donosi odluke kada dođe do incidenta. Za IT administratora to znači pretvoriti postojeću tehničku praksu u dokumentiran, održiv i provjerljiv sustav upravljanja sigurnošću.
Ovaj tekst daje praktični pregled. Ne zamjenjuje pravni savjet niti formalnu procjenu obveza pojedine organizacije.
Koga se NIS2 zahtjevi 2026 mogu odnositi?
NIS2 je europski okvir za kibernetičku sigurnost koji se u Hrvatskoj primjenjuje kroz nacionalne propise i nadležna tijela. Obuhvat nije ograničen samo na velike telekomunikacijske, energetske ili javne sustave. Direktiva obuhvaća niz sektora čiji bi prekid rada mogao imati šire poslovne ili društvene posljedice, uključujući određene pružatelje digitalnih usluga, proizvodne tvrtke, prijevoz, zdravstvo, logistiku, upravljanje otpadom, opskrbu vodom i druge djelatnosti.
Veličina organizacije jest važan kriterij, ali nije jedini. U pravilu se procjenjuju sektor, broj zaposlenih, financijski pokazatelji, vrsta pružene usluge i važnost organizacije za lanac opskrbe ili kontinuitet bitne djelatnosti. U pojedinim slučajevima obveze mogu zahvatiti i organizaciju koja ne izgleda velika, ali pruža uslugu od posebne važnosti.
Najčešća pogreška je zaključiti da tvrtka nije obuhvaćena samo zato što nema interni IT odjel ili zato što nije dio kritične infrastrukture u užem smislu. Ispravan prvi korak je formalno provjeriti primjenjivost prema važećim hrvatskim pravilima i, prema potrebi, zatražiti pravno tumačenje. IT partner pritom može pripremiti tehničke podatke potrebne za procjenu: opis sustava, dobavljača, usluga, lokacija podataka i ovisnosti o vanjskoj infrastrukturi.
Uprava odgovara, IT provodi mjere
NIS2 podiže upravljanje kibernetičkim rizikom na razinu uprave. To je praktično važno jer sigurnosne odluke često traže poslovni kompromis: ulaganje u zamjensku internetsku vezu, zamjenski poslužitelj, dodatne licence za višefaktorsku autentifikaciju ili vrijeme zaposlenika za edukaciju i testiranje oporavka.
Uprava treba odobriti pristup upravljanju rizicima, osigurati resurse i redovito dobivati razumljive informacije o stanju zaštite. Izvještaj ne mora biti tehnički dokument od pedeset stranica. Trebao bi odgovoriti na nekoliko jasnih pitanja: koji su najveći rizici, koje su mjere provedene, što još nedostaje, postoji li otvoren sigurnosni incident i može li se poslovanje oporaviti unutar prihvatljivog roka.
IT odjel ili vanjski pružatelj podrške zatim provodi dogovorene mjere, prati zapise, održava sustave, reagira na upozorenja i vodi evidenciju. Odgovornost ipak ne nestaje prebacivanjem posla na dobavljača. Vanjska IT podrška može biti operativni nositelj, ali poslovne odluke, prihvaćanje rizika i nadzor ostaju obveza organizacije.
Tehničke mjere koje se vide u svakodnevnom radu
NIS2 ne propisuje jedan proizvod niti jednu univerzalnu konfiguraciju. Dobra provedba temelji se na mjerama koje odgovaraju stvarnom riziku i mogu se dokazati kroz dokumentaciju, zapise sustava i redovite provjere.
Polazište je inventar. Organizacija mora znati koje poslužitelje, radne stanice, mrežnu opremu, cloud usluge, poslovne aplikacije i administratorske račune koristi. Bez toga nije moguće pouzdano provjeriti jesu li zakrpe instalirane, postoje li zastarjeli sustavi ili je bivšem zaposleniku ostao aktivan pristup.
Kontrola pristupa obično daje brze rezultate. Administratorski računi trebaju biti odvojeni od svakodnevnih korisničkih računa, pristupi trebaju pratiti radnu ulogu, a višefaktorska autentifikacija mora biti uključena barem za udaljeni pristup, e-poštu, administraciju clouda i ključne poslovne aplikacije. Zajednički administratorski račun bez jasnog vlasnika otežava istragu i povećava rizik od zloupotrebe.
Upravljanje zakrpama također ne smije ovisiti o tome je li se netko sjetio provjeriti ažuriranja. Poslužitelji, mrežna oprema, operativni sustavi i aplikacije trebaju imati definiran postupak: tko prati ranjivosti, kako se procjenjuje hitnost, kada se ažuriranje testira i tko potvrđuje završetak. Ponekad se zakrpa ne može instalirati odmah zbog starog poslovnog programa. Tada rizik treba evidentirati i ublažiti dodatnim mjerama, primjerice segmentacijom mreže, ograničavanjem pristupa ili planom zamjene sustava.
Sigurnosno kopiranje je zasebna cjelina, a ne samo kopija datoteka na mrežnom disku. Potreban je raspored kopiranja, odvojena i zaštićena kopija, nadzor uspješnosti te povremeni test povrata podataka. Backup koji nije testiran može izgledati uredno sve dok ne zatreba obnoviti virtualni poslužitelj, bazu podataka ili Microsoft 365 sadržaj pod vremenskim pritiskom.
Za većinu poslovnih okruženja važne su najmanje sljedeće povezane aktivnosti:
- segmentacija mreže kako bi se ograničilo širenje incidenta između uredskih računala, poslužitelja i proizvodnih ili drugih osjetljivih sustava
- centralizirano bilježenje važnih događaja, posebno prijava administratora, promjena privilegija, udaljenih pristupa i sigurnosnih upozorenja
- zaštita e-pošte i edukacija zaposlenika jer lažne poruke i krađa vjerodajnica i dalje često otvaraju put prema sustavima
- plan kontinuiteta poslovanja i oporavka koji određuje redoslijed vraćanja ključnih usluga
Prijava incidenta nije posao koji počinje nakon napada
NIS2 predviđa kratke rokove za početnu obavijest o značajnim incidentima, naknadnu prijavu i završno izvješće. U praksi se često spominju rana obavijest unutar 24 sata, prijava unutar 72 sata te završno izvješće u roku od mjesec dana, uz primjenu postupaka propisanih za konkretan slučaj i nadležno tijelo. Organizacija mora provjeriti koji se rokovi i kanali prijave na nju točno odnose.
Bit problema nije samo u obrascu prijave. Ako tvrtka ne prati ključne zapise, nema kontakt-listu, ne zna tko smije komunicirati s nadležnim tijelima i nema način očuvanja dokaza, rok od 24 sata prolazi prije nego što je utvrđeno što se dogodilo.
Plan odgovora na incident treba odrediti tko donosi odluku o izolaciji sustava, tko kontaktira upravu, tko koordinira dobavljače i kako se dokumentiraju koraci. U manjoj tvrtki jedna osoba može imati više uloga, ali zamjena mora biti određena. Također treba razlikovati tehničku eskalaciju od komunikacije prema zaposlenicima, partnerima i klijentima. Neprovjerena poruka poslana prerano može stvoriti dodatni poslovni problem, dok prekasna reakcija može produljiti zastoj.
Dobavljači su dio sigurnosne slike
Poslovni sustav rijetko je zatvoren unutar jednog ureda. Tvrtka može ovisiti o pružatelju interneta, cloud platformi, računovodstvenoj aplikaciji, vanjskom održavanju ERP-a, sigurnosnom kopiranju i udaljenoj IT podršci. Svaka takva veza uvodi ovisnost koja treba biti poznata i upravljana.
Ugovori i operativni dogovori trebaju jasno odrediti kontakte za incidente, razine pristupa, obvezu pravodobnog obavještavanja, postupak po prestanku suradnje i dostupnost podataka pri oporavku. Nije realno očekivati istu razinu kontrole nad svakim dobavljačem. Razumno je prioritet dati onima koji imaju administratorski pristup, obrađuju ključne podatke ili održavaju sustave bez kojih tvrtka ne može raditi.
Posebnu pozornost zaslužuju stari informacijski sustavi. Ako aplikacija više nema podršku proizvođača, a sadržava poslovno kritične podatke, nije dovoljno zapisati da je „stabilna”. Potrebni su plan zamjene ili migracije te privremene mjere zaštite.
Kako započeti bez paralize projekta
Najbrži put nije kupnja velikog broja sigurnosnih alata. Prvo treba napraviti snimku postojećeg stanja i povezati tehničke nalaze s poslovnim posljedicama. Popis neaktivnih korisničkih računa, nešifriranih prijenosnih uređaja ili poslužitelja bez podrške postaje prioritet tek kada je jasno kojim podacima i procesima ti sustavi služe.
Praktičan početak uključuje pregled inventara i pristupa, procjenu statusa zakrpa, provjeru backupa kroz stvarni povrat podataka, pregled mrežne segmentacije, usklađivanje plana odgovora na incidente i evidentiranje ključnih dobavljača. Nakon toga mjere treba rasporediti prema riziku, trošku, ovisnostima i mogućnosti prekida rada tijekom provedbe.
CarPen Rebuild u takvom procesu može povezati procjenu infrastrukture, održavanje sustava, sigurnosne mjere, backup i plan oporavka u jedan operativni plan, osobito za tvrtke koje nemaju dovoljno internih IT resursa. Cilj nije stvoriti dokument koji će stajati u mapi, nego održavati sustav koji je spreman za provjeru i za stvarni incident.
Najkorisnije pitanje za upravu nije „jesmo li potpuno sigurni?”, jer takav odgovor ne postoji. Pitanje je: znamo li koji bi prekid najviše pogodio poslovanje, možemo li ga ograničiti i koliko brzo možemo nastaviti raditi? Kada se na to može odgovoriti dokazima, vlasnicima zadataka i testiranim postupcima, NIS2 postaje upravljiv poslovni zadatak, a ne samo regulatorna obveza.