Studija slučaja: kada kibernetički incident zaustavi tvornicu, dobavljače i novčani tok

Lekcija iz incidenta Jaguar Land Rovera u rujnu 2025. za uprave, CISO-e i vlasnike kontinuiteta poslovanja.

Kibernetički incident nije samo pitanje kompromitiranog sustava. U proizvodnoj organizaciji on može zaustaviti proizvodnju, logistiku, obračun i odnose s dobavljačima prije nego što forenzički tim dovrši prvu sliku događaja.

Slučaj Jaguar Land Rovera iz rujna 2025. dobar je materijal za CISO case study upravo zato što javne objave ne daju senzacionalističku tehničku priču. Daju nešto korisnije: vidljiv trag kako se kibernetički događaj pretvara u operativni problem cijelog poslovnog ekosustava.

Što je javno potvrđeno

Britanski NCSC potvrdio je 5. rujna 2025. da podržava JLR u odgovoru na incident. JLR je potom 16. rujna objavio da produljuje prekid proizvodnje dok traje forenzička istraga i priprema kontroliranog ponovnog pokretanja.

NCSC i JLR-ova izjava potvrđuju te dvije točke.

Nekoliko dana kasnije britansko Ministarstvo za poslovanje i trgovinu navelo je da incident ima značajan učinak na JLR i širi automobilski dobavni lanac.

To je važna granica ove analize. Ne nagađamo o uzroku napada, načinu ulaska napadača ni internim ranjivostima. Gledamo poslovni učinak koji su JLR i javna tijela potvrdili.

Kontrolirani restart nije tehnički „on/off” trenutak. To je upravljačka odluka o tome koje procese, podatke, integracije i obveze organizacija smije ponovno pokrenuti.

Zašto je ovo CISO problem, a ne samo problem IT oporavka

Kada proizvodnja stane, rizik se ne širi jednostavno kroz IT infrastrukturu. Širi se kroz mrežu poslovnih ovisnosti.

Proizvodnja

Ključno pitanje nije samo kada će se sustav ponovno uključiti, nego:

Koji sustavi, podaci i integracije moraju biti dovoljno pouzdani prije ponovnog pokretanja proizvodnje?

Ako taj odgovor nije unaprijed definiran, organizacija riskira nesiguran ili nedosljedan restart.

Dobavljači

Treba znati:

Tko ostaje bez narudžbe, potvrde primitka, logističke informacije ili plaćanja ako naši sustavi prestanu raditi?

Problem tada više nije ograničen na jednu organizaciju. Može nastati lančani prekid poslovanja i pritisak na likvidnost dobavljača.

Financije

Organizacija mora moći odgovoriti na pitanje:

Možemo li sigurno izvršavati plaćanja ako automatizirani financijski procesi nisu dostupni?

Bez pripremljenog alternativnog postupka pojavljuju se kašnjenja, pogreške, sporovi i povećan rizik prijevare.

Komunikacija

Tijekom ozbiljnog incidenta mora biti jasno:

Tko partnerima, dobavljačima i upravi daje potvrđenu operativnu sliku?

Ako različiti dijelovi organizacije daju različite informacije, partneri počinju donositi odluke na temelju nepotpunih ili kontradiktornih podataka.

JLR je 7. listopada opisao fazni povratak proizvodnje, poseban kanal za pomoć dobavljačima, ručni sustav podmirenja dospjelih računa i ponovno uspostavljanje automatiziranih plaćanja.

Ta objava pokazuje praktičnu poantu:

Kontinuitet financija i kontinuitet proizvodnje moraju se planirati zajedno.

Četiri odluke koje treba donijeti prije incidenta

1. Odredite minimalni siguran rad, ne samo minimalni IT

Plan koji kaže „vratiti ERP” nije dovoljan.

Treba unaprijed znati što poslovanje smije raditi ako su pojedini dijelovi digitalnog lanca nedostupni:

• koje narudžbe mogu proći ručnim putem

• tko potvrđuje podatke prije njihova naknadnog unosa u sustav

• koji se prijenosi podataka partnerima moraju pauzirati dok se ne provjeri integritet

• koje funkcije smiju raditi u ograničenom režimu

• kada se ručni proces mora ugasiti i vratiti pod redovnu kontrolu

Drugim riječima, ne treba definirati samo minimalno dostupnu tehnologiju, nego i minimalno sigurno poslovanje.

2. Vlasnika dobavnog lanca uključite u incidentni stožer

Dobavljači nisu samo vanjska publika kojoj treba poslati obavijest. Oni su dio oporavka.

U incidentnom stožeru zato trebaju sudjelovati:

• vlasnik nabave ili lanca opskrbe

• financijski vlasnik

• predstavnik ključnih poslovnih operacija

• CISO ili odgovorna osoba za kibernetičku sigurnost

• osoba koja ima ovlast donositi odluke o iznimkama

CISO ne treba sam odlučivati o prioritetu plaćanja, narudžbi ili restartu pogona.

Njegova je odgovornost osigurati da se poslovne odluke donose na temelju provjerene sigurnosne slike, da je rizik poznat i da postoji jasno evidentiran odgovorni vlasnik odluke.

3. Ručni proces mora imati kontrolu, rok i trag

Ručna isplata, ručna obrada narudžbe ili ručna izmjena podataka mogu tijekom incidenta biti nužni.

Ali ručno ne znači nekontrolirano.

Bez zaštitnih mjera takav proces otvara novi prostor za pogreške, zlouporabu i prijevaru, upravo u trenutku kada je organizacija već pod pritiskom.

Minimalni paket kontrole trebao bi uključivati:

1. Drugi kanal za potvrdu promjene bankovnih podataka
   Promjene se ne potvrđuju samo preko kompromitiranog ili potencijalno kompromitiranog komunikacijskog kanala.

2. Razdvojeni unos i odobravanje
   Osoba koja unosi transakciju ne bi trebala biti jedina osoba koja je može odobriti.

3. Dnevno usklađenje ručnih transakcija
   Sve iznimne aktivnosti moraju se naknadno usporediti s evidencijama i potvrditi.

4. Jasan rok trajanja iznimke
   Ručni postupak ne smije neprimjetno postati novi standardni proces. Nakon unaprijed određenog vremena mora se ponovno odobriti ili zatvoriti.

4. Mjerite spremnost za restart, ne samo vrijeme do povratka

Vrijeme oporavka važna je metrika, ali može stvoriti pogrešan osjećaj uspjeha.

Brz povratak procesa s neprovjerenim identitetima, integracijama ili podacima nije pravi oporavak. To može biti samo prijenos incidenta u sljedeću fazu.

Za svaki kritični proces unaprijed treba definirati kriterije za ponovno pokretanje, primjerice:

• potvrđena odgovorna osoba

• provjerene korisničke ovlasti

• poznat status i integritet podataka

• provjerene ključne integracije

• dokumentirana odluka o prihvatljivom riziku

• plan povratka na prethodno stanje ako restart ne uspije

Tek kada su kriteriji ispunjeni, proces je stvarno spreman za kontrolirani povratak.

Pitanja za upravu ovaj tjedan

Ovaj slučaj može se vrlo jednostavno pretvoriti u praktičnu provjeru vlastite organizacije.

Postavite upravi sljedećih pet pitanja:

Koji bi naš dobavljač prvi osjetio prekid naših ključnih sustava?

Ako odgovor nije poznat, vjerojatno nemamo dovoljno dobro mapirane poslovne ovisnosti.

Možemo li sigurno podmiriti obveze ako automatizirani procesi nisu dostupni pet dana?

Ne pitamo samo možemo li nešto platiti, nego možemo li to napraviti sigurno, kontrolirano i dokazivo.

Tko ima ovlast odobriti ručni postupak i tko ga provjerava idući dan?

Ako su odgovornosti nejasne u mirnodopskim uvjetima, tijekom incidenta neće postati jasnije.

Koje integracije ne smijemo ponovno spojiti dok ne dobijemo potvrdu da su sigurne?

Nisu sve integracije jednako kritične niti jednako rizične. Redoslijed ponovnog povezivanja treba biti unaprijed promišljen.

Postoji li jedna operativna slika incidenta koju dijele CISO, financije, nabava i uprava?

Ako svaki od tih timova ima svoju verziju događaja, organizacija nema jedinstveno upravljanje incidentom.

Zaključak

Najvrjednija lekcija ovog slučaja nije da kibernetički incident može zaustaviti proizvodnju. To već znamo.

Važnija je činjenica da oporavak postaje vjerodostojan tek kada poveže sigurnost, operacije, financije i dobavljače u jedan upravljački ritam.

CISO koji to unaprijed pripremi i uvježba ne obećava da se incident neće dogoditi.

Omogućuje organizaciji da, kada se incident dogodi, ne izgubi kontrolu nad poslovnim odlukama upravo onda kada su te odluke najvažnije.