Jak przełożyć kategorię usługi na wymagania wobec dostawcy i umowy ICT?

Kategoria usługi a umowa ICT

Jak przełożyć kategorię usługi na wymagania wobec dostawcy i umowy ICT?

W poprzednim artykule ustaliliśmy kategorię usługi: krytyczna, ważna albo wspierająca. To jednak dopiero połowa pracy. Kategoria, która nie przekłada się na konkretne wymagania wobec dostawcy i na zapisy umowne, zostaje wyłącznie na papierze.

Od 3 kwietnia 2026 r. obowiązuje znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS2. Termin złożenia wniosku o wpis do wykazu KSC upływa 3 października 2026 r., a termin wdrożenia obowiązków wynikających z ustawy przypada na 3 kwietnia 2027 r. Dyrektywa NIS2 wprost wymienia bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami i usługodawcami, jako jeden z obszarów zarządzania ryzykiem (art. 21 ust. 2 lit. d). Pytanie z tytułu tego artykułu nabiera wymiaru praktycznego.

Ten artykuł nie dotyczy tego, jak zakwalifikować usługę. To temat poprzedniego tekstu. Dotyczy tego, co zrobić z wynikiem klasyfikacji: jak przełożyć kategorię usługi na wymagania wobec dostawcy, zapisy umowne oraz mechanizm nadzoru, który pozwala te zapisy wyegzekwować.

Kategoria to punkt wyjścia, nie gotowy wynik

Kategoria usługi ustala poziom ryzyka bazowego. Nie ustala jeszcze, czego dokładnie wymagać od dostawcy.

Dwie usługi krytyczne mogą wymagać zupełnie innych zapisów umownych. Jedna dlatego, że dostawca przetwarza dane osobowe na dużą skalę. Druga dlatego, że ma zdalny dostęp administracyjny do systemu sterowania. Sama kategoria tego nie różnicuje.

Dlatego kategorię trzeba uzupełnić o profil ryzyka usługi, czyli odpowiedź na pytanie, co konkretnie w tej usłudze generuje ryzyko.

Cztery obszary, które kształtują wymagania

Niezależnie od kategorii usługi, wymagania wobec dostawcy wyznaczają cztery obszary:

• Dane: jaka jest klasyfikacja przetwarzanych informacji, czy obejmują dane osobowe, dane wrażliwe operacyjnie, informacje objęte tajemnicą przedsiębiorstwa lub dane istotne dla bezpieczeństwa systemów OT.
• Dostęp: czy dostawca ma zdalny dostęp do systemów, uprawnienia uprzywilejowane, możliwość zmiany konfiguracji, kodu lub oprogramowania układowego, dostęp do środowisk IT, OT lub ICS.
• Zależność i koncentracja: czy usługa opiera się na jednym dostawcy, jednej lokalizacji albo jednym podwykonawcy, z którego korzysta wielu dostawców organizacji.
• Zastępowalność: jak długo trwałaby migracja, czy istnieje realna alternatywa, czy organizacja dysponuje prawami do danych, kodu i konfiguracji potrzebnymi do zmiany dostawcy.

Kategoria usługi mówi, jak dotkliwe będą skutki. Cztery obszary mówią, czego dokładnie wymagać, żeby te skutki ograniczyć.

Od kategorii do wymagań: zasada proporcjonalności

Im wyższa kategoria usługi, tym szerszy i bardziej rygorystyczny powinien być zestaw wymagań. Dla usług ważnych i wspierających zakres wymagań pozostaje proporcjonalny do wyniku oceny w czterech obszarach, a nie do samej nazwy kategorii.

Usługa krytyczna. Pełny zestaw wymagań: ciągłość działania i odtworzenie z konkretnymi parametrami czasowymi, krótkie terminy zgłaszania i eskalacji incydentów, prawo do audytu, nadzór nad podwykonawcami, obowiązek informowania o zmianach istotnych dla bezpieczeństwa, testy ciągłości i odtworzenia, warunki zakończenia współpracy i migracji.

Usługa ważna. Wymagania dopasowane do rzeczywistego ryzyka: zdefiniowane SLA, obowiązek zgłaszania incydentów w terminie umożliwiającym organizacji realizację własnych obowiązków, informowanie o podwykonawcach, prawo do informacji i dokumentów zamiast pełnego audytu, jeżeli poziom ryzyka na to pozwala.

Usługa wspierająca. Wymagania minimalne, ale nie symboliczne. Jeżeli dostawca usługi wspierającej ma wysoki poziom dostępu albo przetwarza dane wrażliwe, część wymagań właściwych usłudze ważnej albo nawet krytycznej powinna pojawić się w umowie, mimo niższej kategorii samej usługi.

Najczęstszy błąd? Kopiowanie tego samego zestawu klauzul bezpieczeństwa do każdej umowy, niezależnie od kategorii i profilu ryzyka. Efekt jest odwrotny do zamierzonego: umowy dotyczące usług krytycznych nie zawierają wystarczająco precyzyjnych postanowień związanych z obszarem lub obszarami, a umowy dla usług wspierających są przeregulowane i trudne do wynegocjowania.

Katalog wymagań wobec dostawcy ICT

Dla usług o podwyższonym ryzyku warto systematycznie sprawdzać obecność następujących elementów:

• Zarządzanie podatnościami: zasady i terminy usuwania podatności, obowiązek informowania o podatnościach krytycznych dotyczących dostarczanego rozwiązania.
• Zarządzanie incydentami: definicja incydentu, terminy zgłoszenia, zakres przekazywanych informacji oraz spójność z terminami raportowania incydentów, do których organizacja jest zobowiązana na mocy UKSC i dyrektywy NIS2.
• Ciągłość działania i odtworzenie: zgodność parametrów odtworzenia dostawcy z parametrami wymaganymi przez organizację, a nie tylko z wewnętrznymi standardami dostawcy.
• Zarządzanie dostępem dostawcy: zasady nadawania i odbierania uprawnień, MFA, dostęp uprzywilejowany, zasada najmniejszych uprawnień, ograniczenie czasowe dostępu, rejestrowanie działań administracyjnych oraz kontrola dostępu podwykonawców.
• Zarządzanie zmianą i podwykonawcami: obowiązek informowania o zmianie podwykonawcy, lokalizacji przetwarzania lub architektury, z odpowiednim wyprzedzeniem.
• Audyt i dowody: prawo do audytu proporcjonalne do kategorii usługi, dostęp do wyników testów, certyfikatów i raportów z audytów zewnętrznych.
• Zakończenie współpracy i migracja: okres przejściowy, zwrot lub bezpieczne usunięcie danych, format danych umożliwiający migrację, wsparcie dostawcy w procesie wyjścia.
• Lokalizacja przetwarzania i jurysdykcja: szczególnie istotne przy danych osobowych oraz informacjach wrażliwych operacyjnie lub objętych szczególnymi wymaganiami ochrony.
• Mechanizmy odpowiedzialności i egzekwowania: w tym, tam gdzie jest to uzasadnione poziomem ryzyka, kary umowne, obowiązek działań naprawczych, możliwość ograniczenia dostępu, odpowiedzialność odszkodowawcza lub prawo do rozwiązania umowy.

I pamiętajmy, że certyfikat dostawcy, ISO 27001, ISO 22301 czy inny, jest cennym dowodem dojrzałości. Nie zastępuje jednak żadnego z powyższych elementów w umowie. Certyfikat potwierdza, że dostawca ma system zarządzania. Umowa określa, czego organizacja może od niego wymagać i co może wyegzekwować.

Zapisy umowne, które faktycznie coś znaczą

Klauzula „dostawca zapewni odpowiedni poziom bezpieczeństwa” nie jest wymaganiem. Jest deklaracją intencji. Nie da się jej zweryfikować ani wyegzekwować.

Prawidłowy zapis umowny spełnia trzy warunki:

• Jest mierzalny: ma konkretny parametr, taki jak czas, zakres lub częstotliwość.
• Jest weryfikowalny: organizacja ma sposób sprawdzenia, czy jest realizowany.
• Jest możliwy do egzekwowania: naruszenie ma określoną konsekwencję.

Test jest prosty: jeżeli w razie sporu nie potrafimy wskazać, co dokładnie dostawca miał zrobić, w jakim terminie i jak to sprawdzić, zapis nie spełnia swojej funkcji, niezależnie od tego, ile miejsca zajmuje w umowie.

Nadzór nie kończy się na podpisaniu umowy

Podpisanie umowy z właściwymi zapisami to początek zarządzania ryzykiem, nie jego zakończenie. Zgodnie z logiką opisaną w poprzednich artykułach, umowę i usługę poddajemy:

• Ocenie bazowej: dla umów już obowiązujących.
• Ponownej ocenie: przy odnowieniu, aneksowaniu, rozszerzeniu zakresu, zmianie technologii, lokalizacji lub podwykonawcy.
• Ocenie bieżącej: obejmującej monitoring incydentów, podatności i realizacji zapisów umownych oraz okresową formalną weryfikację poziomu ryzyka.

Wymagania zapisane w umowie, których nikt nie weryfikuje w praktyce, dają fałszywe poczucie bezpieczeństwa. Dowód zgodności musi istnieć, zanim będzie potrzebny, nie dopiero w trakcie incydentu albo kontroli.

Co powinno być wynikiem tego etapu?

Wynik pracy nad wymaganiami i umową powinien być krótki i możliwy do obrony podczas audytu, kontroli lub przeglądu ryzyka. Dokumentujemy co najmniej:

• kategorię usługi oraz profil ryzyka w czterech obszarach: dane, dostęp, zależność, zastępowalność,
• zestaw wymagań przyjęty dla danej usługi wraz z uzasadnieniem,
• zapisy umowne odpowiadające poszczególnym wymaganiom, wraz ze wskazaniem, gdzie w umowie się znajdują,
• sposób weryfikacji realizacji każdego istotnego zapisu,
• właściciela ryzyka i termin kolejnego przeglądu.

Podsumowanie

Najważniejsze pytanie nie brzmi:

Powinno brzmieć:

Kolejny etap: systematyczny nadzór operacyjny nad dostawcą ICT, monitoring wskaźników, weryfikacja dowodów i reagowanie na zmiany po stronie dostawcy. To temat na osobny materiał.