DOWODY I OCENA DOSTAWCY ICT
W poprzednim artykule pokazałem operacyjny model zarządzania dostawcą ICT: role, ocenę ryzyka, wymagania umowne, monitoring i rejestr dostawców.
Kolejne pytanie brzmi: skąd organizacja ma wiedzieć, że deklarowane przez dostawcę zabezpieczenia rzeczywiście istnieją i działają?
Potrzebne są dowody. Ale ich zakres musi być powiązany z ryzykiem ponieważ w wymaganiach UKSC/NIS2 nie chodzi o to, aby każdego dostawcę poddawać identycznej kontroli. Chodzi o zastosowanie środków proporcjonalnych do znaczenia usługi, poziomu ryzyka, zakresu dostępu i możliwych skutków incydentu.
1. Najpierw ryzyko, później dowód
Nie warto zaczynać od jednej listy dokumentów wymaganych od wszystkich dostawców bo prawidłowa kolejność powinna wyglądać następująco:
usługa → krytyczność → dane → dostęp → zależności → zastępowalność → ryzyko → wymagane zabezpieczenia → dowody
Innych dowodów będziemy oczekiwali od dostawcy aplikacji wspierającej niewielki proces wewnętrzny, a innych od dostawcy posiadającego uprzywilejowany dostęp do środowiska produkcyjnego albo wspierającego usługę krytyczną.
To jest praktyczny wymiar proporcjonalności ponieważ organizacja ma identyfikować i ograniczać ryzyka dotyczące bezpieczeństwa łańcucha dostaw, a środki powinny być odpowiednie do ryzyka.
Dlatego praktyczna ocena dostawcy może występować w różnych momentach:
- przed wyborem lub zawarciem nowej umowy,
- podczas aneksowania istniejącej umowy,
- przy istotnej zmianie usługi, technologii, dostępu lub podwykonawcy,
- okresowo podczas współpracy,
- po istotnym incydencie lub pojawieniu się nowego ryzyka.
W przypadku umów już funkcjonujących — a obecnie często właśnie aneksowanych w związku z dostosowaniem do UKSC — wykonujemy ocenę aktualnego ryzyka, określamy niezbędne wymagania i uzgadniamy z dostawcą sposób osiągnięcia wymaganego poziomu bezpieczeństwa.
2. Ankieta to informacja. Dowód daje wiarygodne potwierdzenie
Ankieta bezpieczeństwa jest dobrym narzędziem do zebrania informacji, ale nie powinna automatycznie przesądzać o pozytywnej ocenie dostawcy.
Jeżeli dostawca deklaruje: „posiadamy proces zarządzania podatnościami”, warto ustalić, czym może to potwierdzić, a dowodem mogą być przykładowo:
- obowiązująca procedura,
- raport z audytu,
- raport ze skanowania lub testu penetracyjnego,
- zestawienie podatności i terminów ich usuwania,
- wyniki testów BCP/DR,
- raport z przeglądu uprawnień,
- certyfikat wraz z zakresem certyfikacji,
- raport niezależnego audytora.
3. Nie zawsze potrzebujemy własnego audytu
Jeżeli dostawca dysponuje aktualnym raportem z audytu wykonanego przez wiarygodną, niezależną stronę trzecią i raport obejmuje interesujący nas zakres, może stanowić wystarczające potwierdzenie skuteczności zabezpieczeń.
Własny audyt powinien być stosowany wtedy, gdy uzasadnia to ryzyko, a dostępne dowody nie zapewniają wystarczającej pewności.
4. Jakich dowodów wymagać? To powinno wynikać z profilu ryzyka usługi.
4.1. Bezpieczeństwo organizacyjne
Możemy oczekiwać:
- polityk bezpieczeństwa,
- zakresu SZBI,
- certyfikatu ISO/IEC 27001,
- raportów audytowych,
- informacji o niezgodnościach i działaniach naprawczych.
Certyfikat powinien być oceniany razem z jego zakresem, datą ważności, jednostką certyfikującą i ewentualnymi wyłączeniami.
4.2. Dostęp i uprawnienia
Przy istotnym dostępie dostawcy warto potwierdzić:
- MFA,
- zarządzanie kontami uprzywilejowanymi,
- nadawanie i odbieranie uprawnień,
- przeglądy dostępów,
- rejestrowanie działań administratorów.
Im większe uprawnienia, tym silniejszego dowodu powinniśmy wymagać.
4.3. Podatności i bezpieczeństwo techniczne
Dowodami mogą być:
- proces zarządzania podatnościami,
- wyniki skanowania,
- testy penetracyjne,
- SLA usuwania podatności,
- plan usunięcia podatności krytycznych.
Nie zawsze potrzebujemy pełnego raportu technicznego. Czasem wystarczające może być potwierdzenie zakresu, wyniku i statusu działań naprawczych przez niezależny podmiot.
4.4. BCP i DR
Nie wystarczy informacja: „posiadamy plan ciągłości działania” ale należy jeszcze wiedzieć:
- jakie RTO i RPO deklaruje dostawca,
- czy parametry odpowiadają wymaganiom naszej usługi,
- kiedy wykonano ostatni test,
- jaki był jego zakres i wynik,
- czy zidentyfikowane problemy zostały usunięte.
Jeżeli organizacja wymaga RTO 4 godziny, a dostawca jest technicznie w stanie odtworzyć usługę po 24 godzinach, jest to realna luka — niezależnie od posiadanych certyfikatów.
5. Jak ocenić wiarygodność raportu z audytu dostawcy?
To szczególnie ważne, jeżeli chcemy wykorzystać audyt przeprowadzony przez inną niezależną firmę zamiast organizować własny.
Przed uznaniem raportu jako dowodu warto sprawdzić:
- Niezależność — kto wykonał audyt i jaka była jego relacja z dostawcą.
- Kompetencje — czy audytor posiadał kompetencje odpowiednie do badanego środowiska i technologii.
- Zakres — czy raport obejmuje usługę, systemy, lokalizacje i zabezpieczenia istotne dla naszej umowy.
- Metodykę — jakie kryteria, standardy i metody badania zastosowano.
- Aktualność — kiedy przeprowadzono audyt i czy od tego czasu środowisko istotnie się zmieniło.
- Wyniki — jakie stwierdzono niezgodności, słabości i wyjątki.
- Działania naprawcze — czy istotne ustalenia zostały zamknięte albo objęte zaakceptowanym planem naprawczym.
- Ograniczenia raportu — czego audyt nie obejmował i jakie zastrzeżenia zgłosił audytor.
Dopiero wtedy możemy zdecydować, czy raport daje wystarczającą pewność, aby wykorzystać go jako dowód i odstąpić od wykonywania własnego audytu w tym samym zakresie. Jednocześnie, takie podejście pozwala unikać powielania kontroli, o ile poziom ryzyka i jakość dostępnych dowodów na to pozwalają.
6. Koszt zabezpieczeń też jest elementem proporcjonalności
To temat, który regularnie pojawia się podczas negocjacji umów. Dostawca często wskazuje, że:
- dodatkowy audyt generuje koszt,
- wdrożenie MFA, PAM lub dodatkowego monitoringu wymaga inwestycji,
- przygotowanie dodatkowych raportów wymaga zaangażowania specjalistów,
- skrócenie RTO wymaga dodatkowej infrastruktury,
- rozszerzenie obowiązków wobec podwykonawców wpływa na model świadczenia usługi.
Takich argumentów nie należy automatycznie odrzucać, ponieważ proporcjonalność działa w obie strony. I nie zawsze należy wymagać kosztownego zabezpieczenia, które nie ma racjonalnego związku z ryzykiem usługi.
Z drugiej strony sam koszt ponoszony przez dostawcę nie jest wystarczającym argumentem do rezygnacji z zabezpieczenia koniecznego dla ograniczenia istotnego ryzyka, a praktyczna rozmowa powinna więc wyglądać następująco:
jakie ryzyko ograniczamy → jakiego poziomu zabezpieczenia potrzebujemy → jaki dowód jest wystarczający → czy istnieje rozwiązanie alternatywne zapewniające porównywalny poziom wiarygodnego potwierdzenia przy niższym koszcie
Przykład: zamiast wykonywać kolejny własny audyt możemy zaakceptować aktualny raport niezależnego audytora, jeżeli jego zakres i jakość są wystarczające.
To jest rzeczywista proporcjonalność, a nie obniżanie wymagań bezpieczeństwa.
7. GO, GO WARUNKOWE czy STOP?
Ten mechanizm także powinien być proporcjonalny, ponieważ nie każda luka musi blokować uruchomienie usługi.
GO — dowody są wystarczające, a ryzyko mieści się w przyjętym poziomie.
GO WARUNKOWE — istnieją braki, ale można je kontrolować bez tworzenia nieakceptowalnego ryzyka.
Powinny wtedy powstać:
- konkretne działanie,
- właściciel,
- termin,
- wymagany dowód zamknięcia,
- mechanizm eskalacji.
STOP — zatrzymanie powinno dotyczyć sytuacji, w której istnieje istotna luka mająca bezpośredni wpływ na bezpieczeństwo usługi, a nie każdego formalnego braku w dokumentacji.
Przykładem może być:
- brak kontroli nad uprzywilejowanym dostępem,
- nierozwiązana krytyczna podatność,
- niemożność osiągnięcia wymaganego RTO,
- brak kontroli nad kluczowymi podwykonawcami,
- brak możliwości potwierdzenia podstawowych zabezpieczeń,
- ryzyko rezydualne przekraczające poziom dopuszczony przez organizację.
Ostateczna decyzja powinna wynikać z ryzyka, krytyczności usługi i skuteczności zabezpieczeń, a nie z mechanicznego zaliczenia checklisty.
8. A co z 3 kwietnia 2027 r.?
Nowelizacja UKSC weszła w życie 3 kwietnia 2026 r., natomiast 3 kwietnia 2027 r. kończy się okres przewidziany na wdrożenie obowiązków wynikających z nowych przepisów. Dlatego też podczas negocjacji z dostawcami ta data pojawia się naturalnie. Nie oznacza jednak, że do 3 kwietnia 2027 r. nie trzeba podejmować działań. Przeciwnie — do tego dnia organizacja powinna mieć wdrożone wymagane rozwiązania, dlatego wcześniej trzeba:
- zidentyfikować umowy i dostawców,
- ocenić ich znaczenie i ryzyko,
- określić wymagane zabezpieczenia,
- przeprowadzić negocjacje,
- zawrzeć odpowiednie aneksy,
- wdrożyć uzgodnione działania,
- zebrać dowody.
W przypadku działań wymagających inwestycji po stronie dostawcy można uzgodnić realistyczny harmonogram dostosowania, o ile do czasu jego zakończenia ryzyko jest kontrolowane, a termin nie powoduje braku gotowości organizacji na dzień wynikający z ustawy.
9. Co powinno zostać w rejestrze?
Rejestr dostawców powinien pokazywać nie tylko nazwę dostawcy i status umowy ale dla istotnych usług powinien umożliwiać ustalenie:
usługa → kategoria → ryzyko → wymaganie → dowód → wynik oceny → luka → działanie → termin → decyzja → monitoring
Wtedy można odpowiedzieć na pytanie audytora lub zarządu:
„Na jakiej podstawie uznaliśmy, że ten dostawca może bezpiecznie świadczyć tę usługę?”
Odpowiedź nie będzie brzmiała: „bo w ankiecie zaznaczył TAK”.
Będzie oparta na konkretnym, proporcjonalnym i możliwym do wykazania procesie decyzyjnym.
Podsumowanie
Celem oceny dostawcy nie jest zebranie maksymalnej liczby dokumentów, lecz uzyskanie wystarczającej pewności, że ryzyka związane z konkretną usługą ICT są właściwie kontrolowane.
Dlatego właściwa logika wygląda tak:
ryzyko → wymaganie → proporcjonalny dowód → ocena jego wiarygodności → ryzyko rezydualne → decyzja → monitoring
Czasami wystarczy certyfikat i kilka dodatkowych informacji. U innego dostawcy wystarczający będzie raport niezależnego audytora. Czasami ryzyko będzie jednak wymagało własnej, pogłębionej weryfikacji.
Nie chodzi o to, aby audytować wszystkich. Chodzi o to, aby wiedzieć, dlaczego danemu dostawcy i konkretnemu zabezpieczeniu możemy zaufać.
W kolejnym artykule: Jak monitorować dostawcę ICT po podpisaniu umowy — KRI, SLA, incydenty, podatności i sygnały uruchamiające ponowną ocenę ryzyka.
#UKSC #NIS2 #Cyberbezpieczeństwo #RyzykoICT #ŁańcuchDostaw #DostawcyICT #ZarządzanieRyzykiem #BezpieczeństwoInformacji