# Umowy z dostawcami IT: jasne uregulowanie obowiązków w zakresie bezpieczeństwa

> Co umowa z agencją, firmą hostingową lub dostawcą IT powinna regulować w kwestii bezpieczeństwa: aktualizacje, restart, zgłaszanie, logi, dostępy i zakończenie.

Źródło: https://phpsos.de/pl/blog/dienstleistervertrag-sicherheit/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Umowa z dostawcą IT nie powinna wspominać o bezpieczeństwie mimochodem, lecz regulować je konkretnie: kto aktualizuje które komponenty, w jakim terminie i z jakim dowodem, jak informuje się o krytycznych lukach, kto uczestniczy w incydencie, jak przechowywane są logi i zarządzane dostępy oraz co dzieje się przy zakończeniu współpracy. Ta strona zawiera ogólne wskazówki i nie jest poradą prawną; umowy sprawdza prawnik.

## Pytanie, które postawił PHP2Shell: kto jest odpowiedzialny?

21.10.2026 o 16:00 czasu niemieckiego projekt PHP opublikował poprawki. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zalecało natychmiastową aktualizację lub, tam gdzie nie było to możliwe, tymczasowe odłączenie serwerów WWW od sieci. W wielu firmach potem nie zaczęła się praca, lecz poszukiwanie odpowiedzialnego. Agencja odsyłała do firmy hostingowej, firma hostingowa do umowy, a w umowie stało „konserwacja według nakładu pracy”.

Takie luki w umowach nie są odosobnione. Wiele umów z agencjami i dostawcami zawarto, gdy chodziło o zbudowanie strony, a nie o jej bezpieczną eksploatację przez lata. Krytyczna luka w środowisku uruchomieniowym PHP, która nie dotyczy ani CMS, ani kodu aplikacji, łatwo wtedy wypada między wszystkich.

## Co umowa z dostawcą IT powinna regulować w kwestii bezpieczeństwa

Poniższe zestawienie wymienia punkty, które w praktyce okazały się ważne. Nie zastępuje kontroli prawnej, ale pomaga rozpoznać luki w istniejącej umowie.

| Punkt uregulowania | Co należy utrwalić | Związek z PHP2Shell |
|---|---|---|
| Zakres usług | Jakie warstwy są obsługiwane: system operacyjny, środowisko PHP, serwer WWW, CMS, wtyczki, własny kod | Środowiska PHP często brakowało w wyliczeniu |
| Terminy aktualizacji | stopniowane według wagi, z regułą wyjątku dla sytuacji awaryjnych | krytyczna luka z CVSS v4.0 9,2 |
| Restart i dowód | Aktualizacje uchodzą za wykonane dopiero po restarcie wszystkich procesów, z pisemnym dowodem | same nowe pliki nie zamykają luki |
| Informowanie | aktywne powiadamianie o krytycznych lukach, z oceną i planem | wielu klientów musiało pytać samodzielnie |
| Udział w incydentach | wsparcie w analizie, zabezpieczeniu, odtworzeniu, osoby kontaktowe | poszukiwanie śladów po poprawce |
| Logi | rodzaj, przechowywanie, wydawanie na żądanie | prasa branżowa radziła zabezpieczać logi od 20.10. |
| Dostępy | konta osobiste, uwierzytelnianie dwuskładnikowe, lista wszystkich dostępów | kto właściwie miał dostęp? |
| Podwykonawcy | kto jeszcze uczestniczy, informacja o zmianie | firma hostingowa firmy hostingowej |
| Koniec cyklu życia oprogramowania | wskazówka z wyprzedzeniem przed końcem wsparcia, plan migracji | PHP 8.2 kończy się 31.12.2026 |
| Zakończenie współpracy | wydanie danych, dokumentacji i dostępów, odebranie uprawnień | zmiana dostawcy po incydencie |

## Terminy i dowody: punkty, które liczą się najbardziej

Terminy to sedno. Sformułowanie w rodzaju „niezwłocznie” w razie awarii nie pomaga. Uzgodnij terminy osobno według wagi i ustal, według czego mierzy się wagę, na przykład według klasyfikacji producenta lub BSI. Dla sytuacji wyjątkowych powinna obowiązywać reguła awaryjna: kto jest osiągalny, kto decyduje, czy system zostanie tymczasowo odłączony od sieci, i jak rozlicza się dodatkowy nakład pracy.

Równie ważny jest dowód. W przypadku PHP2Shell wyświetlany numer wersji często mówił niewiele, ponieważ dystrybucje i firmy hostingowe wprowadzają poprawki jako backport. Wiarygodny dowód podaje stan pakietu, moment instalacji i restart wszystkich procesów PHP. Jakie dane dokładnie się liczą, opisuje artykuł [Jak zapytać firmę hostingową o stan poprawek](https://phpsos.de/pl/ratgeber/hoster-patch-status-erfragen/). Wpisz te dane do umowy jako obowiązkową treść.

> **Wskazówka:**
> Poproś dostawcę o macierz zadań do umowy: jeden wiersz na komponent, jedna kolumna na zadanie, w każdej komórce nazwisko. Luki od razu rzucają się wtedy w oczy, na długo przed kolejnym komunikatem.

## Dostępy, podwykonawcy i zakończenie współpracy

Dostawcy potrzebują dostępów, a właśnie one są częstą drogą ataku. Uregulujcie, że każda osoba otrzymuje własne konto, że uwierzytelnianie dwuskładnikowe jest obowiązkowe tam, gdzie technika na to pozwala, i że w każdej chwili mogą Państwo zażądać aktualnej listy wszystkich dostępów. Pracownicy dostawcy, którzy odeszli, muszą być niezwłocznie usunięci ze wszystkich systemów.

Jeśli dostawca sam współpracuje z partnerami, na przykład z centrum danych lub wyspecjalizowanym zespołem informatyki śledczej, powinni Państwo o tym wiedzieć. Jeśli jeden z tych partnerów przetwarza dane osobowe, dochodzą obowiązki z zakresu ochrony danych. Więcej w artykule [Powierzenie przetwarzania danych, gdy dostawcy mają dostęp do serwerów](https://phpsos.de/pl/blog/auftragsverarbeitung-serverzugriff/).

Zakończenie współpracy jest przy zawieraniu umowy najczęściej zapominane. Ustalcie, że przy zakończeniu umowy dane, konfiguracja, dokumentacja i dane dostępowe zostaną w pełni przekazane, wszystkie dostępy dostawcy odebrane, a to pisemnie potwierdzone. Zwłaszcza po incydencie uporządkowana zmiana jest inaczej trudna.

## Sprawdzanie istniejących umów: jak postępować

Nie muszą Państwo renegocjować wszystkich umów. Na początek wystarczy pragmatyczny przebieg:

1. Zebrać wszystkie umowy z agencjami, firmami hostingowymi i dostawcami IT dotyczące stron lub serwerów.
2. Porównać każdą umowę z powyższą tabelą i oznaczyć otwarte punkty.
3. Najważniejsze luki poruszyć na piśmie u dostawcy, zaczynając od zakresu usług, terminów i dowodu.
4. Wyniki utrwalić jako umowę uzupełniającą i dać sprawdzić prawnikowi.
5. Macierz zadań przenieść do planu awaryjnego.

Dla zarządu ten krok jest także kwestią staranności. Kto jasno reguluje odpowiedzialności i dokumentuje decyzje, jest w lepszej sytuacji, jeśli później pojawią się pytania. Tło daje artykuł [Odpowiedzialność zarządu za luki w bezpieczeństwie IT](https://phpsos.de/pl/compliance/geschaeftsfuehrer-haftung/). Typowy podział zadań przy serwerach pod opieką opisuje artykuł [Serwer zarządzany: wyjaśnienie odpowiedzialności](https://phpsos.de/pl/server/managed-server/).

## Jak konkretnie pomaga PHP SOS?

- Czytamy Państwa istniejące umowy i opisy usług z technicznego punktu widzenia i oznaczamy, jakich komponentów i zadań brakuje.
- Sporządzamy macierz zadań dla wszystkich stron i serwerów, którą mogą Państwo uzgodnić z dostawcami.
- Formułujemy techniczne wymagania dotyczące terminów, dowodów i dróg zgłaszania, które Państwa prawnik może przenieść do umowy.
- Tam, gdzie nikt nie jest odpowiedzialny, sami przejmujemy zadania w ramach [umowy serwisowej bezpieczeństwa](https://phpsos.de/pl/leistungen/security-wartungsvertrag/) z jasno opisanym zakresem.

**Podsumowanie:** Dobra umowa nie zapobiega luce w bezpieczeństwie, ale zapobiega temu, aby w razie awarii tracić czas na pytanie o odpowiedzialnego. Ta strona jest informacją ogólną i nie jest poradą prawną.


## Częste pytania

**Czy dostawca IT musi wprowadzać aktualizacje bezpieczeństwa bez zlecenia?**  
Zależy to od umowy. Bez jasnego uregulowania często sporne jest, czy aktualizacje należą do świadczonej usługi. Dlatego umowa powinna wyraźnie określać, kto aktualizuje które komponenty i w jakim terminie. Za ocenę prawną w indywidualnym przypadku odpowiada prawnik.

**Czy potrzebuję dodatkowo umowy powierzenia przetwarzania danych?**  
Jeśli dostawca przetwarza na zlecenie dane osobowe lub może mieć do nich dostęp, z reguły potrzebna jest umowa powierzenia przetwarzania na podstawie art. 28 RODO. Nie zastępuje ona umowy o świadczenie usług, lecz ją uzupełnia. Proszę to wyjaśnić z inspektorem ochrony danych.

**Jakie terminy aktualizacji bezpieczeństwa są typowe?**  
Nie ma stałych wartości. Sensowne jest stopniowanie według wagi, na przykład osobne terminy dla luk krytycznych, wysokich i pozostałych. Ważne, aby terminy były zapisane i zawierały regułę wyjątku dla sytuacji awaryjnych, takich jak PHP2Shell.

**Co dzieje się z dostępami po zakończeniu umowy?**  
Powinna to regulować umowa: zwrot lub usunięcie danych, wydanie danych dostępowych i dokumentacji, odebranie wszystkich dostępów dostawcy oraz potwierdzenie tego.

## Źródła

- [BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej): 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: obsługiwane wersje](https://www.php.net/supported-versions.php)