Umowa z dostawcą IT NIS2 powinna zapewniać firmie znacznie więcej niż ogólną deklarację przestrzegania zasad cyberbezpieczeństwa. Jeżeli wykonawca utrzymuje kluczowy system, przetwarza dane, korzysta z dostępu administracyjnego albo odpowiada za kopie zapasowe, kontrakt musi określać terminy zgłoszenia incydentu, dostęp do dowodów, obsługę podatności, prawo audytu, wymagania wobec podwykonawców oraz bezpieczne zakończenie współpracy. Zakres tych klauzul powinien wynikać z analizy ryzyka, a nie z gotowego wzoru stosowanego jednakowo do każdej usługi.
Jeżeli awaria dostawcy może zatrzymać usługę klienta, dostawca musi przekazać informacje szybciej, niż wynika to z ustawowych terminów klienta. Jeżeli przechowuje kopie zapasowe albo logi, umowa musi zapewnić dostęp do nich podczas incydentu. Samo hasło „dostawca stosuje odpowiednie zabezpieczenia” nie daje takiej kontroli.
Zakres 12 obszarów kontraktu
Cel zarządu kontrola i dowody
Wymagają jednak zarządzania ryzykiem łańcucha dostaw i stosowania adekwatnych środków wobec bezpośrednich dostawców oraz usługodawców. Dlatego konkretne zobowiązania trzeba przełożyć na umowę, SLA, umowę powierzenia danych i załącznik bezpieczeństwa w sposób proporcjonalny do ryzyka usługi.
Czy KSC/NIS2 narzuca konkretne klauzule umowne?
Dyrektywa NIS2 wymienia bezpieczeństwo łańcucha dostaw jako jeden z podstawowych obszarów zarządzania ryzykiem. Podmiot powinien uwzględniać bezpieczeństwo relacji z bezpośrednimi dostawcami i usługodawcami, ich podatności oraz ogólną jakość produktów i praktyk cyberbezpieczeństwa. Polska ustawa o krajowym systemie cyberbezpieczeństwa przekłada ten obowiązek na środki techniczne, operacyjne i organizacyjne wdrażane przez podmioty kluczowe i ważne.
Nie oznacza to, że każda umowa musi zawierać identyczne postanowienia. Inne ryzyko tworzy biuro rachunkowe bez dostępu do infrastruktury, inne dostawca chmury przechowujący dane, a jeszcze inne administrator sieci z uprzywilejowanym dostępem do środowiska produkcyjnego. Najpierw trzeba ustalić znaczenie usługi, dane i systemy objęte dostępem, zależności oraz możliwość zastąpienia dostawcy.
Wymóg prawny
Organizacja ma zarządzać ryzykiem dostawców i zapewnić ciągłość, obsługę incydentów, kontrolę dostępu oraz możliwość wykazania zgodności.
Analiza ryzyka
Firma ocenia krytyczność usługi, dane, uprawnienia, podwykonawców, koncentrację dostawców, lokalizację oraz skutki awarii.
Kontrakt i dowody
Wyniki analizy trafiają do umowy jako mierzalne obowiązki, terminy, raporty, prawa kontroli, odpowiedzialność i plan wyjścia.
Bardziej szczegółowy katalog warunków umownych zawiera rozporządzenie wykonawcze Komisji (UE) 2024/2690. Dotyczy ono jednak określonych rodzajów podmiotów cyfrowych, m.in. dostawców usług chmurowych, centrów danych, CDN, zarządzanych usług i zarządzanych usług bezpieczeństwa. Jest wartościowym punktem odniesienia, ale nie należy przedstawiać go jako przepisu bezpośrednio obowiązującego każdą firmę zawierającą dowolną umowę IT.
Zarząd nie przenosi odpowiedzialności na dostawcę
Outsourcing infrastruktury, SOC, kopii zapasowych albo obsługi incydentów nie zwalnia podmiotu z odpowiedzialności za zgodność z KSC/NIS2. Dobra umowa nie „oddaje” obowiązków, lecz zapewnia organizacji informacje, współpracę i narzędzia potrzebne do ich wykonania.
Jak przełożyć ryzyko dostawcy na treść umowy?
Przed negocjowaniem klauzul trzeba zmapować usługę. Pomocna jest ankieta bezpieczeństwa dostawcy, ale ankieta i certyfikat nie zastąpią postanowień kontraktu. Pokazują stan na dzień oceny. Umowa określa natomiast, co dostawca ma robić przez cały okres współpracy i jakie informacje musi przekazać po zmianie albo incydencie.
Szybki profil ryzyka dostawcy
Zaznacz cechy współpracy. Wynik pomaga ocenić, jak szczegółowy powinien być załącznik bezpieczeństwa.
Zakres podstawowy: potwierdź minimalne zabezpieczenia, poufność, zasady zgłoszeń i zakończenia współpracy.
Wynik nie zastępuje formalnej oceny ryzyka. Ułatwia jednak wychwycenie sytuacji, w której krótki wzór zamówienia albo standardowy regulamin dostawcy nie odpowiada znaczeniu usługi. Im większy wpływ na ciągłość i im szerszy dostęp, tym bardziej mierzalne powinny być terminy, dowody, testy oraz prawa kontrolne.
Dwanaście klauzul bezpieczeństwa w umowie IT
Poniższe 12 obszarów stanowi praktyczną mapę negocjacji. Nie każdy zapis będzie potrzebny w takim samym zakresie. Umowa z dostawcą IT NIS2 powinna odzwierciedlać wynik oceny ryzyka, model odpowiedzialności oraz faktyczny podział zadań technicznych.
Zakres usługi i jej krytyczność
Umowa powinna wskazywać systemy, procesy, środowiska, dane oraz odpowiedzialności stron. Trzeba też ustalić hierarchię dokumentów, aby SLA, DPA, regulamin i załącznik bezpieczeństwa nie zawierały sprzecznych zasad.
- granice usługi i model współodpowiedzialności,
- systemy produkcyjne, testowe i narzędzia administracyjne,
- pierwszeństwo załącznika bezpieczeństwa w razie kolizji.
Minimalne wymagania cyberbezpieczeństwa
Ogólne zobowiązanie do stosowania „standardów branżowych” jest trudne do rozliczenia. Wymagania powinny dotyczyć realnego zakresu usługi i podlegać okresowemu przeglądowi.
- MFA, szyfrowanie, segmentacja i bezpieczna konfiguracja,
- logowanie, monitoring, ochrona punktów końcowych,
- zarządzanie zmianą i odstępstwami od standardu.
Personel dostawcy i kontrola dostępów
Dostęp powinien być imienny, ograniczony do niezbędnego zakresu i usuwany natychmiast po zmianie roli. Umowa może wymagać kompetencji, szkoleń, poufności oraz dodatkowej weryfikacji personelu, jeżeli uzasadnia to ryzyko.
- zasada najmniejszych uprawnień i zakaz kont współdzielonych,
- onboarding, okresowy przegląd i offboarding,
- rejestr osób posiadających dostęp uprzywilejowany.
Zgłoszenie incydentu i kanał 24/7
Termin dostawcy powinien zostawić klientowi czas na ocenę i wykonanie jego własnych obowiązków. Nie istnieje jeden prawidłowy termin dla każdej usługi. Przy usłudze krytycznej można rozważyć obowiązek powiadomienia niezwłocznie, np. nie później niż 2–4 godziny od potwierdzenia zdarzenia.
- zdarzenia uruchamiające obowiązek zgłoszenia,
- awaryjny kanał i kontakty zastępcze,
- minimalny zakres pierwszej informacji i cykl aktualizacji.
Dowody i współpraca z CSIRT
Klient powinien otrzymywać materiały potrzebne do analizy skutków, decyzji prawnych i sprawozdawczości. Dostawca musi zabezpieczyć dowody, a nie tylko przesłać ogólny komunikat o usunięciu awarii.
- logi, oś czasu, IoC i analiza przyczyny źródłowej,
- wsparcie przy zgłoszeniach do CSIRT i UODO,
- raport końcowy oraz plan działań naprawczych.
Podatności, aktualizacje i bezpieczne zmiany
Kontrakt powinien definiować sposób wykrywania, klasyfikowania i usuwania podatności. Sam obowiązek „aktualizowania systemu” nie określa priorytetów ani sytuacji, w której poprawka nie jest dostępna.
- terminy dla podatności krytycznych i wysokich,
- tryb zmian awaryjnych oraz środki kompensujące,
- informacja o komponentach, zależnościach i końcu wsparcia.
Kopie zapasowe, BCP i DRP
Trzeba rozdzielić wykonanie kopii od odpowiedzialności za możliwość przywrócenia usługi. Umowa powinna wskazywać RPO, RTO, retencję, separację repozytoriów i testy odtworzeniowe.
- miejsce, częstotliwość i ochrona kopii,
- dowody z testów przywracania,
- komunikacja i role podczas uruchomienia DRP.
Prawo audytu i dostęp do raportów
Prawo kontroli musi być wykonalne, ale proporcjonalne. W środowisku chmurowym może opierać się na certyfikatach, raportach niezależnych audytorów i wspólnych audytach, z rozszerzeniem po incydencie lub istotnej zmianie.
- audyt okresowy, doraźny i po incydencie,
- zakres dowodów oraz zasady poufności,
- terminy zamknięcia ustaleń i raportowanie postępu.
Podwykonawcy i dalszy łańcuch dostaw
Główny dostawca powinien znać i kontrolować podmioty, którym przekazuje część usługi. Wymagania bezpieczeństwa trzeba przenieść na dalszych wykonawców, bez rozmywania odpowiedzialności wobec klienta.
- aktualna lista i uprzednie powiadomienie o zmianach,
- prawo sprzeciwu lub zgody w obszarach wysokiego ryzyka,
- pełna odpowiedzialność dostawcy za podwykonawców.
Lokalizacja danych i dostęp uprzywilejowany
Umowa powinna wskazywać, gdzie dane są przechowywane i skąd personel może uzyskiwać do nich dostęp. Dostęp zdalny wymaga kontroli technicznych oraz możliwości odtworzenia przebiegu sesji.
- lokalizacje, transfery i zgodność z umową powierzenia,
- VPN lub bastion, MFA i rejestrowanie sesji,
- zakaz używania danych produkcyjnych w testach bez podstawy.
Odpowiedzialność, kary i ubezpieczenie
Odpowiedzialność powinna odpowiadać potencjalnym skutkom naruszenia, a nie wyłącznie miesięcznej opłacie. Kary umowne ułatwiają rozliczenie konkretnych naruszeń, lecz nie zastępują prawa do pełnego odszkodowania, jeżeli tak ustalą strony.
- naruszenie terminów powiadamiania i obowiązków bezpieczeństwa,
- koszty reakcji, odtworzenia i wymagane ubezpieczenie cyber,
- wyjątki od limitu dla poufności, danych i rażącego niedbalstwa.
Plan wyjścia i bezpieczne zakończenie
Exit plan powinien działać zarówno po spokojnym zakończeniu umowy, jak i podczas sporu albo niewypłacalności dostawcy. Bez niego firma może posiadać prawo do danych, ale nie mieć realnej możliwości przejęcia usługi.
- format i termin zwrotu lub eksportu danych,
- wsparcie migracji oraz ciągłość okresu przejściowego,
- usunięcie kopii i dostępów potwierdzone protokołem.
Ankieta dostawcy pokazuje jego aktualny stan. Dopiero umowa określa, co dostawca musi zrobić po wykryciu incydentu, jak szybko ma przekazać dowody i jakie konsekwencje poniesie za brak współpracy.
Odpowiedzialność, kary i limity odpowiedzialności
Dostawcy IT często proponują limit odpowiedzialności równy wynagrodzeniu zapłaconemu w ostatnich kilku lub dwunastu miesiącach. Taki mechanizm może być uzasadniony przy zwykłych roszczeniach serwisowych, ale staje się problematyczny, gdy jedna luka, utrata kopii albo opóźnione zgłoszenie incydentu może wygenerować wielokrotnie wyższe koszty.
| Obszar | Ryzyko dla klienta | Co warto negocjować |
|---|---|---|
| Ogólny limit | Limit równy jednej fakturze może nie pokryć nawet podstawowej analizy incydentu. | Wyższy limit powiązany z wartością umowy, polisą albo realistycznym scenariuszem szkody. |
| Wyjątki od limitu | Najpoważniejsze naruszenia zostają objęte najniższym ograniczeniem. | Odrębne zasady dla poufności, danych osobowych, praw własności intelektualnej, winy umyślnej i rażącego niedbalstwa. |
| Kary umowne | Trudność wykazania wysokości szkody opóźnia rozliczenie naruszenia. | Kary za brak zgłoszenia, utratę kopii, nieusunięcie dostępu lub naruszenie uzgodnionego terminu, z prawem dochodzenia nadwyżki. |
| Koszty reakcji | Strony spierają się, kto płaci za informatykę śledczą, odtworzenie i komunikację. | Jasny podział kosztów zależny od przyczyny incydentu oraz obowiązek współpracy z wybranym ekspertem. |
| Ubezpieczenie | Odpowiedzialność istnieje na papierze, ale dostawca nie ma środków na jej pokrycie. | Wymagana suma, zakres ryzyk, utrzymanie ochrony i potwierdzenie polisy bez ujawniania zbędnych danych. |
Kary umowne powinny dotyczyć obowiązków niepieniężnych i być proporcjonalne. Warto też wyraźnie ustalić, czy zapłata kary wyczerpuje odpowiedzialność, czy klient może dochodzić odszkodowania przewyższającego jej wartość. Szczegółowe parametry dostępności, czasu reakcji i naprawy powinny pozostać spójne z umową SLA dla usług IT.
Najczęstsze niebezpieczne zapisy dostawców
Nie wiadomo, jakie środki są wymagane, jak je sprawdzić i kiedy ich brak stanowi naruszenie.
Taki termin może zużyć cały ustawowy czas klienta, zanim ten pozna podstawowe fakty.
Dostawca informuje o awarii, ale nie musi przekazać materiałów do oceny skutków i zgłoszenia.
Brakuje kontroli po incydencie, istotnej zmianie, informacji o podatności albo żądaniu organu.
Klient nie zna nowych lokalizacji, dostępu, ryzyka koncentracji ani warunków dalszego powierzenia.
Limit jest oderwany od potencjalnych kosztów przestoju, odtworzenia, notyfikacji i obsługi roszczeń.
Dostawca próbuje wyłączyć odpowiedzialność także wtedy, gdy atak wykorzystał znaną i niezałataną podatność.
Umowa gwarantuje tworzenie kopii, ale nie ich kompletność ani możliwość odtworzenia w wymaganym czasie.
Klient ponosi skutek awarii dalszego dostawcy, choć nie miał wpływu na jego wybór ani zabezpieczenia.
Nie ma końcowej daty, zakresu kopii ani dokumentu potwierdzającego wykonanie obowiązku.
Dostawca zwraca surowe dane, ale nie zapewnia eksportu konfiguracji, dokumentacji i wiedzy operacyjnej.
Niższy standard lub limit z regulaminu może przypadkowo wyłączyć silniejsze wymagania załącznika bezpieczeństwa.
Nie każdy ryzykowny zapis wymaga całkowitego odrzucenia umowy. Przy dostawcy o dużej sile rynkowej prawo do indywidualnego audytu może być nierealne. Wtedy należy ocenić raporty niezależne, certyfikaty, wspólne audyty, prawo do dodatkowych informacji po incydencie i rozwiązania kompensujące. Ważne, aby odstępstwo zostało świadomie zaakceptowane, udokumentowane i objęte planem postępowania z ryzykiem.
Jak sprawdzić umowę przed jej podpisaniem?
Przegląd nie powinien ograniczać się do wyszukania słów „NIS2” lub „cyberbezpieczeństwo”. Trzeba porównać umowę główną, opis usługi, SLA, załącznik techniczny, umowę powierzenia, regulaminy chmury i dokumenty podwykonawców. Dopiero całość pokazuje, kto odpowiada za kontrolę, gdzie powstają luki i czy organizacja będzie w stanie wykazać działanie zabezpieczeń.
Checklista 12 klauzul
Jeżeli dostawca ma realizować zadania związane z obsługą incydentów, warto sprawdzić zgodność kontraktu z wewnętrzną procedurą reakcji na incydent i terminami opisanymi w poradniku o zgłoszeniu incydentu NIS2. Wymagania umowne powinny również znajdować odzwierciedlenie w polityce bezpieczeństwa informacji ISO 27001 i rejestrze ryzyka dostawców.
FAQ: umowa z dostawcą IT NIS2
Czy NIS2 bezpośrednio wiąże każdego dostawcę IT?
Nie. NIS2 i KSC mogą bezpośrednio obejmować dostawcę, jeżeli spełnia kryteria podmiotu kluczowego lub ważnego. Niezależnie od tego jego klient może być zobowiązany do zarządzania ryzykiem łańcucha dostaw i dlatego wymagać zabezpieczeń kontraktowych.
Czy dostawca także ma 24 godziny na zgłoszenie incydentu klientowi?
Nie istnieje jeden ustawowy termin dla każdego dostawcy wobec klienta. Termin umowny powinien wynikać z ryzyka i pozostawiać klientowi czas na ocenę oraz własne zgłoszenie. Przy krytycznej usłudze 24 godziny mogą być zbyt długie.
Czy certyfikat ISO 27001 zastępuje załącznik bezpieczeństwa?
Nie. Certyfikat potwierdza funkcjonowanie systemu zarządzania w określonym zakresie, ale nie definiuje podziału odpowiedzialności dla konkretnej usługi, terminów zgłoszeń, RTO/RPO, dostępu do dowodów ani warunków wyjścia.
Czy dostawca chmurowy może odmówić indywidualnego audytu?
Może oferować model oparty na raportach niezależnych, certyfikatach i audytach wspólnych, zwłaszcza w środowisku wieloklienckim. Klient powinien ocenić, czy taki pakiet daje wystarczające dowody oraz czy po incydencie uzyska dodatkowe informacje.
Czy standardowy regulamin dostawcy wystarczy?
Tylko wtedy, gdy odpowiada profilowi ryzyka i nie koliduje z pozostałymi dokumentami. Przy dostępie administracyjnym, usłudze krytycznej, danych poufnych lub trudnej migracji zwykle potrzebny jest indywidualny załącznik bezpieczeństwa.
Czy umowa powierzenia danych zastępuje wymagania KSC?
Nie. Umowa z art. 28 RODO koncentruje się na danych osobowych. KSC/NIS2 obejmuje również ciągłość usług, systemy, informacje biznesowe, podatności, łańcuch dostaw i obsługę incydentów niedotyczących danych osobowych.
Czy trzeba zatwierdzać każdego podwykonawcę?
Nie zawsze. Model może opierać się na uprzednim powiadomieniu i prawie sprzeciwu. Dla podwykonawców mających dostęp do krytycznych systemów lub danych można przewidzieć zgodę. Zasada powinna być proporcjonalna i wykonalna.
Czy istniejącą umowę można dostosować aneksem?
Tak. Często wystarcza aneks i nowy załącznik bezpieczeństwa, ale trzeba sprawdzić kolizje z regulaminem, SLA, DPA i wcześniejszymi limitami odpowiedzialności. Sama deklaracja zgodności z NIS2 nie usuwa sprzecznych zapisów.
Czy kara umowna jest konieczna?
Nie jest obowiązkowa w każdej umowie, ale może ułatwić rozliczenie mierzalnych naruszeń, takich jak brak zgłoszenia incydentu, nieusunięcie dostępu czy przekroczenie terminu odtworzenia. Jej wysokość i relacja do odszkodowania wymagają indywidualnego ustalenia.
Jakie dokumenty warto dołączyć do umowy?
Najczęściej są to: opis usługi i architektury odpowiedzialności, SLA, załącznik bezpieczeństwa, umowa powierzenia, lista podwykonawców i lokalizacji, procedura komunikacji incydentowej, wymagania BCP/DRP oraz plan wyjścia.
Sprawdź umowę przed przekazaniem dostawcy dostępu
Masz projekt umowy, SLA albo załącznika bezpieczeństwa? Wypełnij formularz bezpłatnej konsultacji i opisz usługę, dostęp dostawcy oraz znaczenie systemu dla firmy. Zweryfikujemy klauzule, odpowiedzialność i zgodność kontraktu z wymaganiami KSC/NIS2.