# Ugovori s IT pružateljima usluga: jasno urediti sigurnosne obveze

> Što ugovor s agencijom, hosterom ili IT pružateljem treba urediti o sigurnosti: updatei, ponovno pokretanje, obavijesti, zapisnici, pristupi i izlazak.

Izvor: https://phpsos.de/hr/blog/dienstleistervertrag-sicherheit/  
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:** Ugovor s IT pružateljem ne bi smio sigurnost spominjati usput, nego je konkretno urediti: tko koje komponente ažurira, u kojem roku i s kojim dokazom, kako se obavještava o kritičnim ranjivostima, tko sudjeluje u incidentu, kako se čuvaju zapisnici i upravlja pristupima te što se događa pri izlasku. Ova stranica daje opće napomene i nije pravni savjet; ugovore provjerava odvjetnik.

## Pitanje koje je postavio PHP2Shell: tko je nadležan?

Dana 21. 10. 2026. u 16 sati po njemačkom vremenu PHP projekt objavio je zakrpe. BSI (njemački Savezni ured za informacijsku sigurnost) preporučio je trenutačni update ili, gdje to nije bilo moguće, privremeno odspajanje web-poslužitelja s mreže. U mnogim tvrtkama nakon toga nije počeo posao, nego potraga za nadležnošću. Agencija je upućivala na hostera, hoster na ugovor, a u ugovoru je stajalo „održavanje po utrošku“.

Takve rupe u ugovoru nisu pojedinačan slučaj. Mnogi ugovori s agencijama i pružateljima sklopljeni su kad je riječ bila o izradi web-stranice, a ne o njezinu sigurnom radu tijekom godina. Kritična ranjivost u PHP okruženju izvođenja, koja ne pogađa ni CMS ni aplikacijski kod, tada lako pada između svih stolica.

## Što ugovor s IT pružateljem treba urediti o sigurnosti

Sljedeći pregled navodi točke koje su se u praksi pokazale važnima. Ne zamjenjuje pravnu provjeru, ali pomaže prepoznati rupe u postojećem ugovoru.

| Točka uređenja | Što bi trebalo biti utvrđeno | Veza s PHP2Shellom |
|---|---|---|
| Opseg usluge | Koji se slojevi održavaju: operacijski sustav, PHP okruženje, web-poslužitelj, CMS, dodaci, vlastiti kod | PHP okruženje često je nedostajalo u nabrajanju |
| Rokovi za updatee | razvrstano prema težini, s pravilom iznimke za hitne slučajeve | kritična ranjivost s CVSS v4.0 9,2 |
| Ponovno pokretanje i dokaz | Updatei vrijede kao obavljeni tek nakon ponovnog pokretanja svih procesa, uz pisani dokaz | same nove datoteke ne zatvaraju ranjivost |
| Obavještavanje | aktivna obavijest o kritičnim ranjivostima, s procjenom i planom | mnogi su kupci morali sami pitati |
| Sudjelovanje u incidentima | potpora pri analizi, osiguravanju, oporavku, kontakt osoba | potraga za tragovima nakon zakrpe |
| Zapisnici | vrsta, čuvanje, predaja na zahtjev | stručni mediji savjetovali su osigurati zapisnike od 20. 10. |
| Pristupi | osobni računi, dvofaktorska prijava, popis svih pristupa | tko je zapravo imao pristup? |
| Podizvršitelji | tko je još uključen, obavijest pri promjeni | hoster hostera |
| Kraj životnog vijeka softvera | pravodobna napomena prije kraja podrške, plan migracije | PHP 8.2 završava 31. 12. 2026. |
| Izlazak | predaja podataka, dokumentacije i pristupa, oduzimanje prava | promjena nakon incidenta |

## Rokovi i dokazi: točke koje najviše vrijede

Rokovi su srž. Formulacija poput „pravodobno“ u najgorem slučaju ne pomaže. Dogovorite rokove odvojeno prema težini i utvrdite prema čemu se težina mjeri, primjerice prema razvrstavanju proizvođača ili BSI-ja. Za izvanredne situacije trebalo bi vrijediti pravilo za hitne slučajeve: tko je dostupan, tko odlučuje ide li sustav privremeno s mreže i kako se obračunava dodatni rad.

Jednako je važan dokaz. Kod PHP2Shella prikazani broj verzije često je govorio malo, jer distribucije i hosteri ispravke primjenjuju kao backport. Pouzdan dokaz navodi stanje paketa, trenutak instalacije i ponovno pokretanje svih PHP procesa. Koji podaci točno vrijede, opisuje [Kako pitati hostera za stanje zakrpe](https://phpsos.de/hr/ratgeber/hoster-patch-status-erfragen/). Ove podatke uvrstite u ugovor kao obvezan sadržaj.

> **Savjet:**
> Neka Vam pružatelj uz ugovor da matricu zadataka: jedan redak po komponenti, jedan stupac po zadatku, u svakoj ćeliji ime. Rupe se tada odmah uoče, mnogo prije sljedeće obavijesti.

## Pristupi, podizvršitelji i izlazak

Pružatelji trebaju pristupe, a upravo su oni čest put napada. Uredite da svaka osoba dobiva vlastiti račun, da je dvofaktorska prijava obvezna gdje tehnika to dopušta i da u svakom trenutku možete zatražiti aktualan popis svih pristupa. Zaposlenici pružatelja koji su otišli moraju se pravodobno ukloniti iz svih sustava.

Ako pružatelj sam radi s partnerima, primjerice podatkovnim centrom ili specijaliziranim forenzičkim timom, trebali biste to znati. Ako neki od tih partnera obrađuje osobne podatke, dodaju se obveze iz zaštite podataka. Više o tome u članku [Obrada podataka u ime voditelja kad pružatelji pristupaju poslužitelju](https://phpsos.de/hr/blog/auftragsverarbeitung-serverzugriff/).

Izlazak se pri sklapanju ugovora najčešće zaboravlja. Utvrdite da se pri završetku ugovora podaci, konfiguracija, dokumentacija i pristupni podaci predaju u cijelosti, da se svi pristupi pružatelja oduzimaju i da se to pisano potvrđuje. Upravo je nakon incidenta uredna promjena inače teška.

## Provjeriti postojeće ugovore: ovako postupite

Ne morate sve ugovore ponovno pregovarati. Za početak je dovoljan pragmatičan tijek:

1. Prikupiti sve ugovore s agencijama, hosterima i IT pružateljima koji se tiču web-stranica ili poslužitelja.
2. Svaki ugovor usporediti s gornjom tablicom i označiti otvorene točke.
3. Najvažnije rupe pisano postaviti pružatelju, počevši s opsegom usluge, rokovima i dokazom.
4. Rezultate zabilježiti kao dodatni sporazum i dati ga pravno provjeriti.
5. Matricu zadataka preuzeti u plan za hitne slučajeve.

Za upravu je ovaj korak i pitanje pažnje dobrog gospodarenja. Tko jasno uredi nadležnosti i dokumentira odluke, bolje stoji ako se kasnije postave pitanja. Pozadinu nudi [Odgovornost uprave kod sigurnosnih ranjivosti IT-a](https://phpsos.de/hr/compliance/geschaeftsfuehrer-haftung/). Tipičnu podjelu zadataka kod održavanih poslužitelja opisuje [Managed Server: razjasniti odgovornost](https://phpsos.de/hr/server/managed-server/).

## Kako PHP SOS konkretno pomaže?

- Čitamo Vaše postojeće ugovore i opise usluga s tehničkog gledišta i označavamo koje komponente i zadaci nedostaju.
- Izrađujemo matricu zadataka za sve web-stranice i poslužitelje koju možete uskladiti sa svojim pružateljima.
- Formuliramo tehničke zahtjeve za rokove, dokaze i putove obavijesti koje Vaš odvjetnik može preuzeti u ugovor.
- Gdje nitko nije nadležan, zadatke preuzimamo sami preko [ugovora o sigurnosnom održavanju](https://phpsos.de/hr/leistungen/security-wartungsvertrag/) s jasno opisanim opsegom.

**Zaključak:** Dobar ugovor ne sprječava sigurnosnu ranjivost, ali sprječava da se u najgorem slučaju gubi vrijeme na pitanje nadležnosti. Ova je stranica opća informacija i nije pravni savjet.


## Česta pitanja

**Mora li IT pružatelj primijeniti sigurnosne updatee bez naloga?**  
To ovisi o ugovoru. Bez jasnog uređenja često je sporno spadaju li updatei u dugovanu uslugu. Zato ugovor treba izričito utvrditi tko koje komponente ažurira i u kojem roku. Za pravnu procjenu u pojedinačnom slučaju nadležan je odvjetnik.

**Trebam li dodatno ugovor o obradi podataka (AVV)?**  
Ako pružatelj u ime voditelja obrađuje osobne podatke ili im može pristupiti, u pravilu je potreban ugovor o obradi podataka prema čl. 28. GDPR-a. On ne zamjenjuje ugovor o usluzi, nego ga nadopunjuje. To razjasnite sa svojim službenikom za zaštitu podataka.

**Koji su rokovi za sigurnosne updatee uobičajeni?**  
Čvrstih vrijednosti nema. Smisleno je razvrstavanje prema težini, primjerice zasebni rokovi za kritične, visoke i ostale ranjivosti. Važno je da rokovi stoje u pisanom obliku i da sadrže pravilo iznimke za hitne slučajeve poput PHP2Shella.

**Što se događa s pristupima kad ugovor završi?**  
To bi trebao urediti ugovor: povrat ili brisanje podataka, predaja pristupnih podataka i dokumentacije, oduzimanje svih pristupa pružatelja i potvrda o tome.

## 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/)
- [php.net: podržane verzije](https://www.php.net/supported-versions.php)