Duży klient przesyła aneks do umowy, ankietę bezpieczeństwa albo prosi o potwierdzenie zasad reagowania na incydenty. Dla niewielkiego dostawcy nie musi to oznaczać, że podlega on wszystkim obowiązkom bezpośrednio. Oznacza jednak, że wymagania związane z NIS2 mogą przejść na firmę przez relację handlową. W takiej sytuacji audyt systemów informatycznych pomaga oddzielić deklaracje składane klientowi od faktycznego stanu środowiska.
Od kwietnia 2026 roku, wraz z obowiązywaniem nowej ustawy o KSC, większe organizacje objęte regulacjami zwracają większą uwagę na bezpieczeństwo swoich dostawców. Dotyczy to także firm zatrudniających kilkanaście lub kilkadziesiąt osób, które obsługują dane, mają dostęp do portalu klienta, realizują usługi zdalnie albo wspierają ważny fragment procesu.
Nie należy przy tym samodzielnie przesądzać statusu prawnego firmy wyłącznie na podstawie wielkości zatrudnienia. Kwalifikację obowiązków ustawowych warto potwierdzić z prawnikiem. Po stronie organizacyjnej można natomiast od razu ustalić, czego wymaga kontrakt i czy firma potrafi wykazać spełnienie tych wymagań.
Mały dostawca nie zawsze podlega wprost, ale odpowiada umownie
W łańcuchu dostaw duży klient odpowiada za ciągłość własnych usług, dane i ryzyko operacyjne. Jeżeli dostawca obsługuje jego system, przetwarza dokumenty, łączy się z siecią lub realizuje krytyczne zlecenia, jego słabości mogą wpłynąć na działalność klienta. Z tego powodu wymagania często pojawiają się w umowie, regulaminie współpracy albo cyklicznej ankiecie.
Najczęściej dotyczą one zabezpieczenia dostępu, aktualizacji, kopii zapasowych, zarządzania incydentami i kontroli podwykonawców. Szersze uporządkowanie obowiązków po stronie firmy opisuje także materiał o organizacji obowiązków IT przy NIS2. W przypadku dostawcy kluczowe jest jednak przełożenie ogólnych wymagań na konkretne dowody: procedurę, konfigurację, rejestr dostępu albo wynik testu.
Jakie wymagania spływają z umów i ankiet klienta
Wymagania klienta bywają zapisane ogólnie, na przykład jako obowiązek utrzymania odpowiednich środków bezpieczeństwa. Często jednak za takim zapisem idą bardziej konkretne pytania lub warunki. Problem pojawia się wtedy, gdy firma potwierdza ich spełnienie, lecz nie ma osoby odpowiedzialnej, dokumentacji ani technicznej możliwości realizacji danego obowiązku.
- stosowanie indywidualnych kont i dodatkowego potwierdzania logowania do ważnych usług;
- ograniczenie dostępu pracowników do danych oraz odbieranie uprawnień po zmianie roli;
- aktualizowanie systemów, urządzeń i używanego oprogramowania według ustalonego procesu;
- wykonywanie kopii danych oraz okresowe sprawdzanie możliwości ich odtworzenia;
- zgłaszanie incydentu do klienta w określonym terminie i wskazanie osoby kontaktowej;
- kontrola dostępu podwykonawców, serwisantów oraz osób pracujących zdalnie;
- możliwość przekazania odpowiedzi na ankietę, wyników kontroli lub informacji o działaniach naprawczych.
Warto zwrócić uwagę, że zapis o „niezwłocznym” zgłoszeniu incydentu bez wewnętrznej procedury ma ograniczoną wartość. Pracownik musi wiedzieć, co uznaje się za incydent, komu przekazuje informację i kto decyduje o kontakcie z klientem. W przeciwnym razie firma może zareagować technicznie, ale nie dotrzymać zobowiązania umownego.
Co powinien objąć audyt systemów informatycznych dostawcy
Zakres kontroli powinien wynikać z rzeczywistej roli firmy wobec klienta. Inaczej sprawdza się przedsiębiorstwo, które jedynie wymienia dokumenty e-mail, a inaczej podmiot mający zdalny dostęp do aplikacji, danych lub infrastruktury kontrahenta. Przydatnym punktem wyjścia jest audyt bezpieczeństwa i środowiska IT, który pozwala zestawić stan urządzeń, kont, usług i procedur z wymaganiami umowy.
Wynik audytu systemów informatycznych powinien odpowiadać na pytania zrozumiałe również dla osoby zarządzającej: jakie dane i systemy są istotne dla realizacji umowy, kto ma do nich dostęp, co stanie się po awarii oraz które braki wymagają decyzji biznesowej. Sama lista luk technicznych nie wystarczy, jeśli nie wskazuje właściciela działania, terminu i skutku dla obsługi klienta.
- lista systemów, kont i urządzeń wykorzystywanych przy realizacji usługi dla klienta;
- mapa dostępów pracowników, administratorów i podwykonawców;
- stan aktualizacji, ochrony urządzeń oraz kontroli logowania;
- zakres kopii zapasowych i dowód ostatniego testu odtworzenia;
- zasady obsługi incydentów wraz z numerami kontaktowymi i eskalacją;
- braki wymagające poprawy przed podpisaniem aneksu lub odpowiedzią na ankietę.
Od czego zacząć po otrzymaniu aneksu lub ankiety
Najpierw należy wyznaczyć jedną osobę po stronie biznesowej, która zbierze wymagania klienta i ustali, czego firma nie może potwierdzić bez weryfikacji. Następnie warto podzielić pytania na obszary prawne, organizacyjne i techniczne. Dzięki temu nie dochodzi do sytuacji, w której pracownik handlowy deklaruje zgodność, a osoba odpowiedzialna za IT dowiaduje się o tym po podpisaniu umowy.
Szczególnej kontroli wymaga dostęp osób zewnętrznych. Zdarza się, że dawny serwisant, dostawca aplikacji albo podwykonawca nadal ma aktywne konto, ponieważ nikt nie określił terminu odebrania uprawnień. Praktyczne zasady ograniczania takiego ryzyka omawia artykuł o dostępie dostawców do firmowych systemów.
- przeczytać umowę, załącznik bezpieczeństwa i ankietę przed udzieleniem odpowiedzi;
- ustalić procesy, dane oraz systemy wykorzystywane przy obsłudze klienta;
- zebrać istniejące procedury, umowy z podwykonawcami i wyniki wcześniejszych kontroli;
- wykonać ocenę stanu technicznego oraz ustalić plan usunięcia braków;
- uzgodnić, kto zatwierdza odpowiedzi kierowane do klienta;
- zachować potwierdzenia wykonanych działań, aby móc do nich wrócić przy kolejnej kontroli.
Przykład z obsługi: brak nie był w zabezpieczeniach, lecz w odpowiedzialności
U jednego z klientów M3 Group, który realizował usługi dla większej organizacji, ankieta bezpieczeństwa wymagała potwierdzenia zasad zgłaszania incydentów i kontroli dostępu. Firma miała zabezpieczone stanowiska oraz kopie danych, ale nie posiadała listy osób uprawnionych do kontaktu z klientem po wykryciu problemu. Dodatkowo dwa konta zewnętrznego dostawcy nie miały wskazanego terminu ważności.
Po sprawdzeniu uporządkowano cztery elementy: właściciela procedury, zastępstwo na czas nieobecności, sposób rejestrowania zgłoszenia i okresowy przegląd kont zewnętrznych. Taki audyt systemów informatycznych nie wymagał wymiany całej infrastruktury, ale pozwolił usunąć ryzyko, którego nie było widać podczas zwykłej pracy. Zdalne połączenia, uprawnienia i zasady ich kontroli warto też odnieść do podstaw opisanych w przewodniku o bezpiecznym dostępie VPN w firmie.
Krótka konkluzja
Mała firma będąca dostawcą dużego klienta nie powinna zakładać, że NIS2 jej nie dotyczy tylko dlatego, że nie jest podmiotem regulowanym bezpośrednio. Wymagania mogą wynikać z umowy i mieć realny wpływ na dalszą współpracę. Audyt systemów informatycznych pozwala ustalić stan faktyczny, przypisać odpowiedzialność i przygotować dowody potrzebne podczas ankiety, kontroli lub incydentu.
