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. Wpisz te dane do umowy jako obowiązkową treść.
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.
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:
- Zebrać wszystkie umowy z agencjami, firmami hostingowymi i dostawcami IT dotyczące stron lub serwerów.
- Porównać każdą umowę z powyższą tabelą i oznaczyć otwarte punkty.
- Najważniejsze luki poruszyć na piśmie u dostawcy, zaczynając od zakresu usług, terminów i dowodu.
- Wyniki utrwalić jako umowę uzupełniającą i dać sprawdzić prawnikowi.
- 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. Typowy podział zadań przy serwerach pod opieką opisuje artykuł Serwer zarządzany: wyjaśnienie odpowiedzialności.
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 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.