# Lessons learned: postati bolji nakon incidenta

> Lessons learned nakon IT incidenta: kada se održava razgovor, koja pitanja vrijede i kako iz spoznaja nastaju mjere s rokom.

Izvor: https://phpsos.de/hr/blog/lessons-learned-nach-vorfall/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Lessons learned nakon IT incidenta znači: nakon tehničkog zaključenja svi sudionici sjedaju zajedno, rekonstruiraju tijek, bez traženja krivaca imenuju što je dobro prošlo, a što nije, i iz toga izvode mjere s odgovornim osobama i rokovima. To vrijedi i za skoro-incidente, poput PHP2Shell tjedna koji je prošao bez posljedica. Odlučujući nije zapisnik, nego kasnija kontrola jesu li mjere provedene.

## Zašto je tjedan nakon incidenta toliko važan

Kad poslužitelj opet radi i zakrpe su instalirane, velika je napast brzo se vratiti svakodnevici. Upravo tada se gubi najvrjednije znanje: Tko je kada što primijetio? Gdje je nedostajala informacija? Koja je odluka predugo trajala? Za nekoliko tjedana to više nitko ne zna točno.

Listopadski tjedan 2026. dobar je primjer. Mnoge su tvrtke zakrpale PHP poslužitelje, pisale pružateljima hostinga, preventivno isključile web-stranice ili osigurale logove. Čak i ako provala nije utvrđena, u tome ima mnogo gradiva za učenje. Koliko je trebalo da se utvrdi koji su sustavi pogođeni? Tko je morao odobriti isključenje i je li ta osoba bila dostupna?

Same tehničke korake nakon napada obrađuje [Kontrolni popis nakon hakerskog napada](https://phpsos.de/hr/ratgeber/checkliste-nach-dem-hack/). Ovaj članak nastavlja nakon toga: što iz toga učimo?

## Lessons learned kod IT incidenta: osnovna pravila razgovora

Razgovor nije sud. Tko se boji da će pogreške imati osobne posljedice, priča samo pola priče. Zato vrijedi načelo: tražimo uzroke u procesima, alatima i informacijama, a ne krivce. Ljudi su djelovali sa znanjem koje su u tom trenutku imali.

Pozovite sve koji su sudjelovali, i vanjske poput pružatelja hostinga, agencije ili pružatelja usluga, koliko je moguće. Planirajte dva sata. Unaprijed zatražite materijal: tikete, tijek chata, e-poštu, bilješke, izvatke iz logova. Iz toga nastaje vremenska crta, okosnica razgovora. Kako je uredno izgraditi, opisuje [Izrada vremenske crte incidenta](https://phpsos.de/hr/blog/zeitleiste-eines-vorfalls/).

Moderaciju ne bi trebala preuzeti osoba koja je incident operativno vodila. Inače bi ocjenjivala vlastite odluke. Neutralna je primjerice netko iz drugog odjela ili vanjski partner.

## Tijek u šest koraka

1. **Predstaviti vremensku crtu:** Što se kada dogodilo, od prve prijave do zaključenja? Praznine u vremenskoj crti označiti, ne pogađati.
2. **Što je dobro prošlo?** Počnite svjesno s pozitivnim. To pokazuje što treba zadržati i opušta krug.
3. **Gdje je zapinjalo?** Svako kašnjenje, svaka nedostajuća informacija, svaka nesigurnost se prikuplja, najprije bez rasprave o rješenjima.
4. **Razjasniti uzroke:** Za najvažnije točke više puta pitajte zašto. „Zakrpa je stigla kasno“ je nalaz, „nitko nije znao da na starom poslužitelju još radi PHP“ je uzrok.
5. **Odrediti mjere:** Za svaki uzrok konkretna mjera, odgovorna osoba i rok.
6. **Dogovoriti naknadnu kontrolu:** Termin za četiri do osam tjedana na kojem se provjerava što je provedeno.

## Tipična pitanja i mjere nakon PHP situacije

Sljedeća tablica pokazuje pitanja koja se često postavljaju nakon situacije poput PHP2Shella i moguće odgovore u obliku mjera. Ne odgovara svaka svakoj tvrtki; služi da izoštri pogled.

| Pitanje na razgovoru | Tipičan nalaz | Moguća mjera |
|---|---|---|
| Kako smo saznali za ranjivost? | Slučajno iz vijesti | Ciljano se pretplatiti na sigurnosne obavijesti php.net-a i BSI-ja |
| Jesmo li znali koji su sustavi pogođeni? | Popis nepotpun, stari sustav zaboravljen | Popis svih web-stranica i poslužitelja s verzijom PHP-a |
| Tko je smio odlučiti o isključenju? | Nejasno, odluka odgođena | Ovlast odlučivanja utvrditi u planu za hitne slučajeve |
| Je li pružatelj hostinga potvrdio zakrpu? | Samo usmeno ili nikako | Zatražiti pisanu potvrdu, dopuniti ugovor |
| Jesu li ponovno pokrenuti svi PHP procesi? | Nije provjereno | Ponovno pokretanje i kontrolu uvesti kao čvrst korak |
| Jesu li logovi od 20. 10. bili dostupni? | Djelomično već prebrisani | Produljiti rok čuvanja, logove sigurno pohraniti središnje |
| Kako je tekla komunikacija unutra i prema van? | Zaposlenici su saznali iz tiska | Pripremiti prvu internu informaciju |

Zabilježite i što svjesno ne mijenjate. Ponekad je nalaz poznat, ali bi mjera bila nerazmjerna. Dokumentirana odluka bolja je od tihog zaborava.

> **Savjet:**
> U zapisniku razdvojite dokazane činjenice, vjerojatne pretpostavke i otvorena pitanja. Upravo nakon PHP2Shella, za koji nema objavljenih, potvrđenih Indicators of Compromise, to je razdvajanje važno.

## Od zapisnika do promjene

Najčešći neuspjeh lessons learned je banalan: zapisnik se pošalje i onda se ništa ne dogodi. Protiv toga pomažu tri navike. Prvo, svaka mjera pripada u sustav u kojem se ionako radi, dakle sustav tiketa ili popis zadataka, a ne u zaseban dokument. Drugo, naknadna kontrola dobiva čvrst termin u kalendaru uprave. Treće, rezultati se ugrađuju u plan za hitne slučajeve, popis kontakata i vježbe.

Tko želi provjeriti spoznaje a da ne čeka sljedeći pravi incident, može ih proći u [vježbi hitnog slučaja za stolom](https://phpsos.de/hr/blog/notfalluebung-am-tisch/). A gdje razgovor pokaže da su ažuriranja previše ovisila o slučaju, isplati se prelazak na [upravljanje zakrpama kao proces](https://phpsos.de/hr/blog/patch-management-prozess/).

Završno izvješće je uz to važan dokument za zaštitu podataka, osiguranje i eventualno tijela. Pravna procjena, primjerice je li prijava prema čl. 33. GDPR-a bila potrebna, ipak pripada službeniku za zaštitu podataka ili odvjetniku, a ne tehničkom razgovoru.

## Kako PHP SOS konkretno pomaže?

- Iz logova, tiketa i bilješki izrađujemo vremensku crtu incidenta i označavamo praznine.
- Moderiramo razgovor kao neutralno mjesto i pazimo da se traže uzroci, a ne krivci.
- Tehničke nalaze prevodimo u mjere s procjenom truda i prioritetom.
- Pratimo naknadnu kontrolu i na želju sami provodimo tehničke mjere, kako je predviđeno u našem [odgovoru na incidente](https://phpsos.de/hr/leistungen/incident-response/).

## Zaključak

Incident je dovoljno skup. Tko ga ne analizira, sljedeći put plaća još jednom. Iskren razgovor bez traženja krivaca, uredna vremenska crta i mjere s imenom i rokom čine od teškog tjedna trajan dobitak u sigurnosti.


## Česta pitanja

**Kada treba održati sastanak lessons learned?**  
Kad je incident tehnički zaključen, a sjećanje je još svježe. U praksi se pokazao termin otprilike jedan do dva tjedna nakon zaključenja. Prije često nedostaje odmak, poslije detalji blijede.

**Treba li razgovor održati i nakon skoro-incidenta?**  
Isplati se. Situacija poput PHP2Shella, u kojoj se na kraju ništa nije dogodilo, ipak pokazuje gdje su procesi zapinjali. Te su spoznaje osobito vrijedne jer su nastale bez štete.

**Tko vodi razgovor?**  
Najbolje netko tko incident nije sam operativno vodio. Tako moderacija ostaje neutralna i nitko ne mora braniti vlastite odluke. To može biti i vanjski pružatelj usluga.

**Što se događa s rezultatima?**  
Svaka spoznaja postaje mjera s odgovornom osobom i rokom. Plan za hitne slučajeve, popis kontakata i dokumentacija se prilagođavaju. Nakon nekoliko tjedana netko provjerava što je stvarno provedeno.

## Izvori

- [BSI: informacije za tvrtke](https://www.bsi.bund.de/)
- [php.net: sigurnosne objave](https://www.php.net/)
- [GDPR čl. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)