# Izrada IT plana za hitne slučajeve za web-poslužitelje

> Izradite IT plan za hitne slučajeve za web-poslužitelje: uloge, kontakti, popis sustava, pravila odlučivanja i putovi prijave kako bi u kriznom slučaju sve funkcioniralo.

Izvor: https://phpsos.de/hr/compliance/notfallplan-erstellen/  
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:** IT plan za hitne slučajeve za web-poslužitelje unaprijed određuje tko u kriznom slučaju odlučuje, koga se može dobiti, koji sustavi mogu biti pogođeni i koji koraci slijede kojim redoslijedom. Tko želi izraditi IT plan za hitne slučajeve, ne treba debeli priručnik, nego nekoliko aktualnih stranica koje su dostupne i bez ispravnog IT-a. Situacija oko PHP2Shella dobar je povod da se to učini sada.

## Zašto plan za hitne slučajeve štedi vrijeme i štetu

U kriznom slučaju prvi sati često odlaze na traženje: tko ima pristup pružatelju hostinga? Gdje su sigurnosne kopije? Tko odlučuje hoće li shop biti isključen? Koga treba obavijestiti? Plan za hitne slučajeve odgovara na ta pitanja unaprijed, u miru.

PHP2Shell je pokazao koliko vremena može biti malo. Dana 20. 10. 2026. php.net je najavio zakrpe, 21. 10. u 16:00 po njemačkom vremenu objavljene su, a BSI je preporučio trenutačno ažuriranje ili privremeno isključivanje. Tvrtke s planom znale su koga nazvati i koje poslužitelje provjeriti. Druge su najprije morale otkriti gdje uopće radi PHP.

## Izrada IT plana za hitne slučajeve: gradivni elementi

Praktičan plan za web-poslužitelje obuhvaća ove dijelove:

**1. Uloge i odluke.** Tko u hitnom slučaju vodi, tko zamjenjuje, tko smije isključiti sustave, tko govori prema van? Zabilježite imena i zamjene.

**2. Popis kontakata.** Interni kontakti, pružatelj hostinga, agencija, IT pružatelj usluga, službenik za zaštitu podataka, pravno savjetovanje, kibernetičko osiguranje s brojem police, nadležno nadzorno tijelo za zaštitu podataka, središnja kontaktna točka za kibernetički kriminal (Zentrale Ansprechstelle Cybercrime) Vaše savezne zemlje. Taj popis mora postojati ispisan.

**3. Popis sustava.** Svaka web-stranica, svaki shop i svaki portal s poslužiteljem, pružateljem hostinga, načinom rada, PHP verzijom, aplikacijom, odgovornom osobom i vrstom obrađivanih podataka.

**4. Pravila odlučivanja.** Pod kojim uvjetima sustav odvajamo s mreže? Tko to smije odlučiti? Što vrijedi noću i vikendom?

**5. Postupci.** Kratki nizovi koraka za tipične slučajeve: poznata kritična ranjivost, sumnja na provalu, unakažena web-stranica, odljev podataka, iznuda.

**6. Putovi prijave.** Tko provjerava obvezu prijave prema čl. 33. GDPR-a, ako je moguće u roku od 72 sata od saznanja? Tko prijavljuje BSI-ju kod obveze prema NIS2? Tko informira osiguravatelja?

**7. Ponovna uspostava.** Gdje su sigurnosne kopije, tko ih može vratiti, koliko to traje, kada je to zadnji put testirano?

## Primjer: postupak „kritična PHP ranjivost“

Ovako može izgledati postupak kakav je bio potreban kod PHP2Shella:

| Korak | Tko | Rezultat |
|---|---|---|
| Procijeniti obavijest (php.net, BSI) | IT odgovorni | pogođeni sustavi prema popisu |
| Instalirati ažuriranje, ponovno pokrenuti sve workere | administrator ili pružatelj usluga | dokaz stanjem paketa i vremenom procesa |
| Gdje ažuriranje nije moguće: privremene mjere ili s mreže | uprava odlučuje | dokumentirana odluka |
| Osigurati zapisnike, provjeriti tragove | administrator ili forenzika | nalaz ili bez nalaza |
| Kod nalaza: pokrenuti postupak za incident | voditelj kriznog tima | provjeriti putove prijave |

Važno pritom: zakrpa zatvara ranjivost, ali ne uklanja zlonamjerni softver ubačen prije. Zato potraga za tragovima čvrsto spada u postupak.

> **Savjet:**
> Odredite koliko se dugo čuvaju zapisnici web-poslužitelja i gdje se nalaze izvan poslužitelja. Kod PHP2Shella stručni tisak preporučivao je čuvanje zapisnika od 20. 10. 2026. Tko zapisnike drži samo nekoliko dana, ne može provesti takve preporuke.

## Prevencija koja plan tek čini djelotvornim

Plan je dobar koliko i preduvjeti iza njega. Provjerite postoje li sigurnosne kopije prema pravilu 3-2-1 i jesu li testirane, vidi [Sigurnosne kopije prema pravilu 3-2-1](https://phpsos.de/hr/ratgeber/backups-3-2-1/). S pružateljem hostinga i agencijom pisanim putem razjasnite tko što preuzima kod kritičnih ranjivosti. Pristupne podatke za hitne slučajeve držite sigurno, ali dostupno, primjerice u zaštićenom trezoru lozinki s hitnim pristupom.

Pripremite i tekstualne predloške: interna informacija, obavijest klijentima, napomena na statičnoj stranici o održavanju. Napomene su u članku [Krizna komunikacija nakon napada](https://phpsos.de/hr/compliance/krisenkommunikation/).

## Vježbati i držati aktualnim

Plan koji nikad nije vježban gotovo uvijek sadrži praznine. Jednom godišnje odigrajte jedan scenarij, primjerice „kritična PHP ranjivost u petak poslijepodne“, i zabilježite gdje zapinje. Za početak je dovoljan jednostavan test: može li druga osoba bez pomoći prve doći do pružatelja hostinga, vratiti sigurnosnu kopiju i web-stranicu prebaciti u način održavanja? Ako ne, u planu nešto nedostaje, najčešće pristup, telefonski broj ili opis. Upravo takve praznine vježbe trebaju učiniti vidljivima prije nego što postane ozbiljno. Plan ažurirajte nakon svake vježbe i svake bitne promjene. Kao metodološki okvir prikladni su IT-Grundschutz BSI-ja i BSI-Standard 200-4 o upravljanju kontinuitetom poslovanja.

Pravna pitanja, primjerice o obvezama prijave, plan ne razjašnjava konačno. Brine se da se pravi ljudi uključe na vrijeme. Ova stranica je opća informacija, a ne pravni savjet.

## Kako PHP SOS konkretno pomaže?

- S Vama izrađujemo popis sustava Vaših web-poslužitelja, uključujući način rada i PHP verziju.
- Pišemo tehničke postupke za tipične scenarije i usklađujemo ih s pružateljem hostinga i agencijom.
- Provodimo vježbu i saznanja ugrađujemo u plan.
- U kriznom slučaju preuzimamo tehničku stranu putem [odgovora na incidente](https://phpsos.de/hr/leistungen/incident-response/), na zahtjev osiguranu [ugovorom o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/).


## Česta pitanja

**Koliko opsežan mora biti IT plan za hitne slučajeve?**  
Što kraći, a koliko je potrebno opsežan. Za web-poslužitelje često je dovoljno nekoliko stranica s kontaktima, popisom sustava, pravilima odlučivanja i postupcima. Važnije od opsega je da je aktualan i da se u kriznom slučaju može pronaći.

**Gdje čuvam plan za hitne slučajeve?**  
Na barem jednom mjestu dostupnom i bez ispravnog IT-a, primjerice ispisan ili na odvojenom uređaju. Plan koji leži samo na pogođenom poslužitelju ili u zaključanoj mreži tvrtke ne pomaže u kriznom slučaju.

**Koliko često plan treba provjeravati?**  
Najmanje jednom godišnje i nakon svake bitne promjene, primjerice promjene pružatelja hostinga ili novog softvera. Smislena je kratka vježba u kojoj se odigra jedan scenarij.

**Postoje li predlošci BSI-ja?**  
BSI (njemački Savezni ured za informacijsku sigurnost) obrađuje upravljanje u hitnim slučajevima u okviru IT-Grundschutza i u BSI-Standardu 200-4 o upravljanju kontinuitetom poslovanja. Oni su prikladni kao okvir; za web-poslužitelje isplati se sažeta, praktična inačica.

## Izvori

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [GDPR čl. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Policija: pregled ZAC-a](https://www.polizei.de/)