Umowa z dostawcą IT po NIS2: klauzule bezpieczeństwa, SLA i zgłaszanie incydentów

Umowa z dostawcą IT po NIS2 nie powinna ograniczać się do deklaracji zgodności, ogólnej klauzuli bezpieczeństwa i miesięcznego wskaźnika dostępności. Musi przekładać ryzyko związane z usługą na jednoznaczny podział odpowiedzialności, mierzalne poziomy świadczenia, szybki przepływ informacji o incydentach, dostęp do dowodów oraz wykonalny plan wyjścia. Punktem wyjścia jest krytyczność usługi i rzeczywisty podział kontroli między stronami. Dopiero na tej podstawie można ustalić, jakie zabezpieczenia, terminy, uprawnienia weryfikacyjne i obowiązki zgłoszeniowe powinny znaleźć się w kontrakcie.

Umowa jako mechanizm kontroli ryzyka

Przeglądu umów nie należy rozpoczynać od gotowego wzoru klauzuli bezpieczeństwa, lecz od mapy zależności organizacji od dostawców. Dla każdego dostawcy trzeba wskazać obsługiwane usługi, procesy, systemy, dane i lokalizacje, a następnie ocenić skutki niedostępności lub naruszenia bezpieczeństwa. W pierwszej kolejności analizuje się zależności, których zakłócenie może zatrzymać działalność, ograniczyć realizację zobowiązań albo utrudnić obsługę incydentu. Nie każda usługa IT wymaga zatem takich samych zabezpieczeń kontraktowych.

Klasyfikacja krytyczności dostawcy powinna wynikać z analizy wpływu zakłócenia na działalność i oceny ryzyka, a nie tylko z wartości kontraktu. Szczególnej uwagi wymagają usługi, za których ciągłość i obsługę incydentów odpowiada przedsiębiorstwo, podczas gdy dostawca kontroluje informacje techniczne, dzienniki zdarzeń, kopie zapasowe lub środowisko niezbędne do odtworzenia usługi. Po stronie organizacji trzeba również wyznaczyć właściciela ryzyka związanego z dostawcą. Bez tej roli odpowiedzialność zakupów, IT, bezpieczeństwa i właściciela procesu pozostaje rozproszona.

Treść umowy należy projektować na podstawie scenariuszy zakłóceń: awarii usługi, ataku, utraty lub uszkodzenia danych, niedostępności personelu dostawcy, przerwania łańcucha podwykonawców oraz zakończenia współpracy. Dla każdego scenariusza trzeba określić działania stron, zakres odpowiedzialności, przepływ informacji i warunki odtworzenia. Z tych ustaleń wynikają poziomy dostępności, czasy reakcji i przywrócenia, zakres wymaganej dokumentacji oraz uprawnienia weryfikacyjne.

Deklaracja zapewnienia wysokiej dostępności nie rozstrzyga, jak długo może pozostawać niedostępny system sterujący produkcją, od którego momentu liczy się przestój ani kto dostarczy dane potrzebne do oceny incydentu. Nie gwarantuje też dostępu do kopii zapisów zdarzeń, informacji o podwykonawcach czy danych umożliwiających bezpieczne przeniesienie usługi. Luki te ujawniają się zwykle podczas awarii, gdy podział odpowiedzialności nie może już pozostać domyślny.

Odwołanie do NIS2 lub właściwych wymagań KSC powinno zamykać analizę ryzyka i odpowiedzialności, a nie zastępować operacyjnej treści kontraktu. Szerszy kontekst zarządczy przedstawia materiał NIS2 dla firm produkcyjnych: kogo obejmuje, jakie obowiązki wprowadza i jak przygotować organizację bez sprowadzania tematu wyłącznie do IT. Zakres zmian w umowach trzeba każdorazowo dostosować do roli organizacji, krytyczności usługi i faktycznego podziału kontroli między stronami.

Zakres usługi i odpowiedzialności

Podział obowiązków należy opisać w załączniku technicznym, a nie pozostawiać w ogólnej definicji przedmiotu umowy. Załącznik powinien wskazywać obsługiwane zasoby i środowiska, rodzaje danych, lokalizacje przetwarzania i świadczenia usług, interfejsy, godziny wsparcia oraz wyłączenia. Bez tych informacji nie można jednoznacznie ustalić, gdzie kończy się odpowiedzialność dostawcy, jakie zdarzenie uruchamia pomiar SLA ani kto zabezpiecza elementy na styku systemów.

Środki bezpieczeństwa warto opisywać przez wymagany rezultat, odpowiedzialną stronę i dowód wykonania, pozostawiając szczegóły technologiczne w nadzorowanej dokumentacji technicznej. Ogranicza to ryzyko szybkiej dezaktualizacji umowy. Standardowy katalog zabezpieczeń dostawcy można przyjąć dopiero po porównaniu go z ryzykiem konkretnej usługi i uzupełnieniu stwierdzonych braków. Macierz odpowiedzialności powinna rozróżniać właściciela zabezpieczenia, jego wykonawcę oraz podmiot zatwierdzający odstępstwa.

Jeżeli środowiskiem administruje dostawca, umowa powinna dodatkowo regulować dostęp uprzywilejowany: rozdział obowiązków, sposób uwierzytelniania, ewidencję działań administracyjnych oraz niezwłoczne odbieranie uprawnień po zmianie roli lub zakończeniu współpracy. Samo oświadczenie o wykonywaniu kopii zapasowych jest niewystarczające, jeżeli klient nie wie, kto je szyfruje, gdzie są przechowywane, kto może je odtworzyć i jaki dokument potwierdza wynik próby odtworzeniowej.

Dostawca powinien utrzymywać aktualny wykaz podwykonawców wpływających na usługę, wraz z opisem ich ról i lokalizacji przetwarzania, oraz nakładać na nich wymagania nie słabsze niż uzgodnione z klientem. Umowa musi rozstrzygać, które zmiany wymagają uprzedniej zgody, a które jedynie powiadomienia i ponownej oceny ryzyka. Certyfikat systemu zarządzania może wspierać tę ocenę, lecz nie zastępuje odpowiedzialności określonej dla konkretnej usługi. Zależność tę rozwija materiał NIS2 a ISO 27001: co daje certyfikat, a czego nadal brakuje do zgodności z KSC.

Klauzule bezpieczeństwa, które można zweryfikować

Klauzula bezpieczeństwa staje się rozliczalna dopiero wtedy, gdy określa oczekiwany rezultat, zakres zastosowania, częstotliwość działania, sposób potwierdzania wykonania i tryb obsługi odstępstw. Sformułowania „zgodnie z najlepszymi praktykami” lub „z zachowaniem należytej staranności” mogą uzupełniać wymagania, ale nie pozwalają ocenić, czy dostawca prawidłowo wykonał zobowiązanie. Dla każdego zabezpieczenia trzeba wskazać właściciela wymagania, okres przechowywania dowodów oraz stronę uprawnioną do zaakceptowania wyjątku.

Tak skonstruowane wymagania powinny obejmować co najmniej nadzór nad podatnościami i aktualizacjami, utrzymywanie bezpiecznej konfiguracji, szyfrowanie, ochronę i przechowywanie dzienników zdarzeń, wykonywanie kopii zapasowych, próby odtworzeniowe, zarządzanie zmianą oraz kontrolę dostępu. Częstotliwość przeglądów uprawnień, prób odtworzenia i raportowania, a także terminy usuwania podatności należy wyprowadzić z oceny ryzyka usługi. Nie powinny być jednakowe dla wszystkich dostawców.

Każde odstępstwo należy wpisać do rejestru wraz z uzasadnieniem, terminem usunięcia, właścicielem ryzyka i zabezpieczeniami zastępczymi. Ich akceptacja wymaga oceny, czy rzeczywiście ograniczają ryzyko do poziomu dopuszczonego przez organizację.

Zapis o regularnym wykonywaniu kopii zapasowych pozostaje niepełny, jeżeli nie wskazuje danych i systemów objętych kopią, okresu przechowywania, ochrony przed zmianą lub usunięciem, zasad dostępu ani częstotliwości prób odtworzenia. Powinien również określać, jak dostawca zgłasza nieudaną kopię lub próbę, kto zatwierdza działania naprawcze i jaki raport potwierdza ich zamknięcie. Podobnie obowiązek usuwania podatności wymaga ustalenia sposobu klasyfikacji, terminów reakcji zależnych od ryzyka, zasad odraczania aktualizacji oraz dokumentowania zabezpieczeń tymczasowych.

Dowody należy podzielić na przekazywane okresowo oraz udostępniane na żądanie. Do pierwszej grupy mogą należeć podsumowania podatności, raporty z aktualizacji, wyniki prób odtworzeniowych i potwierdzenia przeglądów dostępów. Po incydencie, istotnej zmianie lub stwierdzeniu odstępstwa potrzebne mogą być szczegółowe wyniki prób, zapisy zdarzeń, historia zmian, rejestr wyjątków i plan działań korygujących. Zakres, właścicieli i okres przechowywania tych materiałów warto powiązać z zasadami opisanymi w opracowaniu Dokumentacja NIS2 i KSC przed kontrolą: jakie polityki, rejestry i dowody naprawdę trzeba mieć.

Prawo do weryfikacji powinno być stopniowane i wykonalne również wobec dostawcy chmurowego. Pierwszy poziom może obejmować przegląd dokumentów i spotkanie wyjaśniające, kolejny — niezależne raporty lub uzgodnione próby, natomiast audyt na miejscu można zastrzec dla podwyższonego ryzyka, istotnego incydentu albo braku wiarygodnych dowodów. Umowa powinna regulować terminy, poufność, zakres techniczny i sposób usuwania ustaleń, bez przyznawania klientowi uprawnień niemożliwych do wykonania w środowisku współdzielonym.

SLA dla odporności, nie tylko dostępności

SLA powinno wynikać z analizy wpływu na działalność, a nie z katalogu standardowych parametrów dostawcy. Właściciel procesu najpierw określa tolerowany czas przerwy, dopuszczalną utratę danych oraz skutki niedostępności dla produkcji, obsługi klientów, rozliczeń i obowiązków prawnych. Dopiero z tych ustaleń wyprowadza się cele czasu odtworzenia, wymagania dotyczące usługi zastępczej i trybu awaryjnego oraz priorytety zgłoszeń. Miesięczny wskaźnik dostępności nie odpowiada na pytanie, czy pojedyncza awaria w krytycznym momencie zatrzyma proces na czas dłuższy, niż organizacja może zaakceptować.

Poza dostępnością umowa powinna określać czas potwierdzenia zgłoszenia, rozpoczęcia diagnozy, przywrócenia funkcji i usunięcia przyczyny, a także częstotliwość komunikatów, poziomy eskalacji oraz tryb pracy poza standardowymi godzinami. Czas reakcji nie jest czasem odtworzenia, a uruchomienie rozwiązania zastępczego nie oznacza pełnego usunięcia problemu. Rozdzielenie tych pojęć pozwala zespołowi operacyjnemu ustalić, kiedy odzyska możliwość pracy, a właścicielowi usługi — kiedy dostawca zakończy analizę przyczyn i wdroży trwałe działanie naprawcze.

W przypadku systemu sterującego procesem produkcyjnym incydent krytyczny może wymagać natychmiastowej eskalacji i ciągłej komunikacji aż do uruchomienia trybu awaryjnego. Ta sama usterka w środowisku szkoleniowym może otrzymać niższy priorytet. Klasyfikacja musi zatem opierać się na wpływie na działalność, a nie wyłącznie na technicznym opisie błędu. Jeżeli organizacja dysponuje wiarygodnymi danymi historycznymi, przy ustalaniu progów powinna uwzględnić rzeczywiste czasy reakcji i odtworzenia, wyniki dostępności oraz liczbę powtarzających się awarii.

Mechanizm pomiaru powinien wskazywać źródło danych, strefę czasową, moment uruchomienia i zatrzymania licznika, uzgodnione godziny świadczenia usługi, okna serwisowe oraz zasady zmiany klasy incydentu. Wyłączenia z pomiaru trzeba ująć w zamkniętym i weryfikowalnym katalogu. Nie mogą one obejmować zdarzeń pozostających w zakresie odpowiedzialności dostawcy. Spójność tych ustaleń z rzeczywistą gotowością operacyjną można ocenić w ramach Audyt NIS2 w firmie produkcyjnej – jak sprawdzić, czy organizacja jest gotowa na nowe obowiązki.

Kredyty usługowe ani symboliczne rekompensaty nie odtwarzają procesu i nie ograniczają skutków przestoju. Większe znaczenie mają obowiązek przedstawienia planu naprawczego, eskalacja zarządcza, dodatkowe próby odporności oraz prawo zakończenia umowy w razie trwałego lub powtarzalnego niespełniania uzgodnionych poziomów. Sankcja finansowa może wzmacniać odpowiedzialność, ale nie zastąpi mechanizmu przywracania usługi, usuwania przyczyn i zapobiegania kolejnym awariom.

Incydent i obowiązki zgłoszeniowe

Umowa powinna zobowiązywać dostawcę do niezwłocznego zgłoszenia każdego zdarzenia, które może wpłynąć na usługę, dane, ciągłość działania lub bezpieczeństwo klienta. Pierwszego powiadomienia nie można uzależniać od pełnego potwierdzenia przyczyny, rozmiaru szkody czy kwalifikacji prawnej zdarzenia. Termin umowny należy ustalić z buforem umożliwiającym klientowi przeprowadzenie własnej oceny i dochowanie ewentualnych terminów zewnętrznych. Powinien on wynikać z krytyczności usługi i dostępności całodobowego punktu kontaktowego, a nie z wygody organizacyjnej stron.

Przepływ informacji trzeba podzielić na pierwsze ostrzeżenie, aktualizacje sytuacyjne, raport po zdarzeniu oraz analizę przyczyn źródłowych. Dla każdego etapu należy określić zakres danych, dopuszczony kanał, adresatów, częstotliwość aktualizacji i zasady eskalacji w razie braku kontaktu. Pierwszy komunikat powinien zawierać co najmniej czas wykrycia, dotknięte zasoby i usługi, przewidywany wpływ, podjęte działania, dostępne wskaźniki techniczne, ocenę ryzyka dalszego rozprzestrzeniania oraz termin kolejnej aktualizacji. Lista kontaktów musi obejmować zastępców i być okresowo sprawdzana, również poza standardowymi godzinami pracy.

Jeżeli dostawca wykryje nietypowy ruch w środowisku utrzymującym kluczową aplikację, powinien ostrzec klienta, zanim rozstrzygnie, czy doszło do naruszenia. Klient uruchamia własny proces zarządzania incydentami, wyznacza osobę odpowiedzialną za decyzje, angażuje zespół reagowania, a w odpowiednim przypadku również ubezpieczyciela, oraz ustala, kto zatwierdza zgłoszenie zewnętrzne i komunikację z klientami. Dostawca zabezpiecza uzgodnione dzienniki i ślady techniczne, wspiera analizę, ograniczanie skutków i ustalanie zakresu zdarzenia, lecz nie przejmuje odpowiedzialności regulacyjnej klienta.

Klauzule powinny również określać zasady zachowania i udostępniania dowodów, ochrony ich integralności, dokumentowania decyzji oraz przygotowywania danych potrzebnych do zgłoszeń i późniejszej analizy przyczyn źródłowych. Terminy, adresaci i zakres zgłoszeń zewnętrznych wymagają każdorazowej weryfikacji według aktualnego stanu prawa, statusu organizacji i rodzaju zdarzenia. Rejestry powiadomień, decyzji, eskalacji i działań należy powiązać z opracowaniem Dokumentacja NIS2 i KSC przed kontrolą: jakie polityki, rejestry i dowody naprawdę trzeba mieć, a harmonogram dostosowania — z materiałem Wdrożenie NIS2 po wpisie do wykazu KSC – plan działań do 3 kwietnia 2027 roku.

Wdrożenie, nadzór i bezpieczne wyjście

Podpisanie aneksu nie kończy procesu zarządzania dostawcą. Właściciel umowy powinien prowadzić cykliczne przeglądy wyników SLA, incydentów, odstępstw, działań korygujących, zmian podwykonawców oraz aktualności dowodów potwierdzających spełnienie wymagań. Podstawą nadzoru jest rejestr umów zawierający co najmniej datę odnowienia, właściciela, krytyczność usługi i stan uzgodnienia zabezpieczeń. Deklaracja zgodności nie zastępuje raportów, wyników prób ani zapisów potwierdzających realizację obowiązków.

Przed odnowieniem umowy lub istotną zmianą usługi należy ponownie ocenić jej krytyczność, zależności techniczne i procesowe, koncentrację usług u jednego dostawcy, wykonalność zabezpieczeń oraz możliwość przejścia do rozwiązania zastępczego. Taki przegląd pozwala rozstrzygnąć, czy wystarczy aneks, czy potrzebne jest nowe postępowanie zakupowe. Jeżeli strategiczny dostawca odmawia audytu lub zmiany warunków, organizacja powinna udokumentować lukę i wybrać między wdrożeniem zabezpieczenia zastępczego, formalną akceptacją ryzyka rezydualnego a zmianą dostawcy.

Plan wyjścia musi być wykonalny jeszcze przed wypowiedzeniem umowy. Powinien obejmować zwrot i przeniesienie danych w użytecznym formacie, pomoc migracyjną, utrzymanie ciągłości w okresie przejściowym, odebranie dostępów, usunięcie kopii oraz potwierdzenie wykonania tych czynności. Jednocześnie należy zachować zapisy wymagane do celów prawnych, dowodowych i audytowych. Praktycznym sprawdzianem jest próbne odtworzenie danych u innego dostawcy wraz z weryfikacją kompletności, czasu migracji i możliwości wyłączenia dotychczasowych kont.

Modernizację portfela umów należy rozpocząć od usług o największym wpływie na działalność, a luki uporządkować według skutków i pilności. Skuteczność przyjętych mechanizmów warto sprawdzić podczas ćwiczenia incydentowego oraz audytu próbki dowodów. Wyniki przeglądów SLA, incydentów, odstępstw, działań korygujących i prób wyjścia pokażą, czy wymagania działają w praktyce, czy pozostają wyłącznie zapisami umownymi.

Zakres oceny można powiązać z materiałem Audyt NIS2 w firmie produkcyjnej – jak sprawdzić, czy organizacja jest gotowa na nowe obowiązki. Obowiązki organizacji należy przy tym ustalać z uwzględnieniem jej statusu, który omawia materiał Dyrektywa NIS2 – kogo dotyczy i jakie firmy muszą spełnić nowe wymagania?