Jak zarządzać ryzykiem bezpieczeństwa ze strony dostawców i podwykonawców

Dlaczego ryzyko stron trzecich zasługuje na uwagę

Kształt naruszenia się zmienił. Przez lata historia wyglądała tak: atakujący wchodzi frontowymi drzwiami. Teraz duży i rosnący odsetek incydentów przychodzi bocznym wejściem, które sami otworzyliście: dostawcą, któremu zaufaliście dane albo dostęp. W Verizon 2026 Data Breach Investigations Report 48% potwierdzonych naruszeń dotyczyło strony trzeciej, wzrost z 30% w danych z poprzedniego roku i 15% rok wcześniej. Raport obejmuje incydenty od 1 listopada 2024 do 31 października 2025.

Mechanika jest łatwa do wyobrażenia. Podłączacie narzędzie SaaS do Google Workspace albo Microsoft 365. Dajecie agencji marketingowej login do CRM. Dostawca usług zarządzanych trzyma stały dostęp administracyjny w całym waszym środowisku. W każdym z tych przypadków wasze dane i wasz dostęp żyją częściowo w cudzym środowisku, rządzonym przez czyjeś bezpieczeństwo, czyjeś aktualizacje, czyjś offboarding. Kiedy to środowisko zostaje przełamane, blast radius obejmuje was.

Dla firmy mid-market niewygodne jest to, że to ryzyko narasta po cichu. Nikt nie decyduje się na współpracę z pięćdziesięcioma dostawcami z dostępem do wrażliwych danych. Dzieje się to jedno zamówienie na raz, często bez udziału zespołu bezpieczeństwa, i całościowy obraz nigdy nie zostaje spisany. Celem zarządzania ryzykiem stron trzecich jest wiedzieć, gdzie leży to ryzyko, i upewnić się, że relacje, na których najbardziej zależy, mają pod sobą jakiś fundament.

Proces TPRM, który da się naprawdę prowadzić

Wersja sprzedawana dużym przedsiębiorstwom obejmuje ciągłe monitorowanie wyników, zautomatyzowane platformy kwestionariuszowe i zespół, który to wszystko obsługuje. Nie potrzebujecie tego, żeby uzyskać większość wartości. Poniżej opisany jest pięcioczęściowy proces skalowany dla firmy, która ma lidera IT i lidera operacyjnego, a nie dedykowaną funkcję zarządzania ryzykiem stron trzecich.

1. Prowadź inwentarz swoich dostawców

Nie da się zarządzać tym, czego się nie spisało. Fundamentem jest jeden rejestr każdej strony trzeciej, która dotyka waszych danych albo systemów. Arkusz kalkulacyjny to zupełnie dobry punkt startowy. Dla każdego dostawcy zapisz mały, spójny zestaw pól:

• Nazwę dostawcy i co dla was robi.
• Wewnętrznego właściciela: kto w waszej firmie zarządza tą relacją.
• Jakich danych może dotknąć, opisanych wprost: dane osobowe klientów, dane pracowników, dane finansowe, kod źródłowy, nic wrażliwego.
• Jaki dostęp posiada: login do systemu, integrację albo połączenie API, dostęp fizyczny, stałe uprawnienia administracyjne.
• Czy jest podmiotem przetwarzającym dane w rozumieniu RODO i czy jest zawarta umowa powierzenia danych.
• Mniej więcej ile wydajecie i datę odnowienia.

Nie zbudujecie tego za jednym podejściem i nie musicie. Zasilcie go z oczywistych źródeł: rejestru zobowiązań, listy podłączonych aplikacji od waszego SSO albo dostawcy tożsamości, grantów OAuth w waszym tenancie Google albo Microsoft, i pięciominutowej rozmowy z każdym zespołem o narzędziach, na których polega. Operacje zwykle znają umowy; IT zwykle zna dostępy. Inwentarz to miejsce, w którym te dwa spojrzenia się w końcu spotykają.

Inwentarz to najbardziej użyteczny artefakt w całym tym przewodniku. Wszystko inne się na nim opiera.

2. Podziel dostawców na warstwy według ryzyka i wrażliwości danych

Kiedy już widzicie wszystkich dostawców, kolejnym krokiem jest przestać traktować ich jednakowo. Dostawca płac, który trzyma dane bankowe każdego pracownika, to nie to samo ryzyko co narzędzie do projektowania, którego jeden zespół używa do slajdów wewnętrznych. Podział na warstwy pozwala skierować ograniczony wysiłek tam, gdzie zmienia wynik.

Sprawdza się prosty model trzech warstw, oparty na dwóch pytaniach: jak wrażliwe są dane, do których dostawca ma dostęp, i jak dużo dostępu posiada.

• Warstwa 1 (krytyczna) · Co się w niej znajduje: Obsługuje wrażliwe dane osobowe, finansowe albo regulowane; albo ma szeroki lub administracyjny dostęp; albo awaria zatrzymałaby wasze działanie. · Co to oznacza dla due diligence: Pełne proporcjonalne due diligence. Przeglądane okresowo.
• Warstwa 2 (umiarkowana) · Co się w niej znajduje: Obsługuje pewne dane biznesowe albo ograniczone dane osobowe; dostęp jest zawężony. · Co to oznacza dla due diligence: Lżejsze sprawdzenie: potwierdź istnienie certyfikacji, potwierdź podpisaną umowę powierzenia.
• Warstwa 3 (niska) · Co się w niej znajduje: Brak wrażliwych danych, brak istotnego dostępu; generyczne narzędzie z publicznymi albo trywialnymi informacjami. · Co to oznacza dla due diligence: Odnotuj w inwentarzu i idź dalej.

Większość firm odkrywa, że zdecydowana większość dostawców trafia do warstwy 3, dający się ogarnąć środek siedzi w warstwie 2, a krótka lista, często od dziesięciu do trzydziestu pozycji dla firmy mid-market, siedzi w warstwie 1. Ta krótka lista to miejsce, na które powinna iść wasza uwaga. Bądźcie szczerzy co do tego, do czego dostawca faktycznie ma dostęp, a nie co jest jego zamierzonym zastosowaniem: integracja, która poprosiła o szeroki dostęp odczytu do waszej skrzynki, jest warstwą 1 niezależnie od tego, jak wąskie było jej zamierzone zastosowanie.

3. Zrób proporcjonalne due diligence dla tych, na których zależy

Dla dostawców z warstwy 1, i lżejszej wersji dla warstwy 2, celem jest rozsądna pewność, że dostawca traktuje bezpieczeństwo poważnie, a nie audyt śledczy. Trzy rzeczy dają większość tej pewności.

Aktualna certyfikacja albo raport bezpieczeństwa. Zapytaj, czy dostawca ma certyfikację ISO/IEC 27001 albo czy może udostępnić raport SOC 2 Type II. To nie są gwarancje i powinniście czytać zakres oraz datę, a nie zbierać logo. Raport sprzed dwóch lat, albo taki, którego zakres wyklucza produkt, którego faktycznie używacie, mówi mniej, niż się wydaje. Ale dostawca, który potrafi przedstawić aktualny raport w odpowiednim zakresie, przynajmniej poddał się niezależnej weryfikacji, czego nie zrobił dostawca, który tego nie potrafi.

Umowa powierzenia danych. Jeśli dostawca przetwarza dane osobowe w waszym imieniu, art. 28 RODO wymaga zawarcia umowy powierzenia danych. To jednocześnie obowiązek prawny i użyteczna kontrola: porządna umowa powierzenia nazywa przetwarzanie, ustala oczekiwania bezpieczeństwa, wymaga ujawnienia podprocesorów i zobowiązuje dostawcę do pomocy w razie incydentu. Potwierdźcie, że jest podpisana i że wymienia, komu jeszcze dostawca przekazuje wasze dane.

Krótki zestaw podstawowych pytań. Dla dostawców, u których certyfikacja zostawia luki, krótki kwestionariusz je wypełnia. Ogranicz go do pytań, których odpowiedzi zmieniłyby waszą decyzję: Czy szyfrujecie nasze dane w spoczynku i w tranzycie. Czy wymuszacie MFA na kontach personelu i administratorów. Jak szybko powiadomicie nas o incydencie dotyczącym naszych danych. Gdzie geograficznie przechowywane i przetwarzane są nasze dane. Jak usuwacie nasze dane, kiedy odchodzimy. Skupiony zestaw pytań zarabia na swoje miejsce. Generyczny szablon z 200 pytaniami wysyłany do każdego dostawcy głównie generuje pracę bez wglądu.

Dopasuj głębokość do warstwy. Warstwa 1 dostaje wszystkie trzy elementy. Warstwa 2 może dostać samo potwierdzenie istnienia certyfikacji i podpisanej umowy powierzenia. Warstwa 3 nie dostaje nic poza wpisem w inwentarzu.

4. Zapisz swoje oczekiwania w umowie

Na kontroli, którą tylko omówiliście, trudniej polegać niż na takiej, którą uzgodniliście na piśmie przed podpisaniem umowy. Umowa albo formularz zamówienia to miejsce, w którym ustalacie próg, a moment największej dźwigni jest zanim pieniądze zmienią właściciela. Dla waszych ważnych dostawców kilka klauzul robi większość roboty:

• Zobowiązanie do powiadomienia o naruszeniu z określonym terminem, żebyście dowiedzieli się o incydencie dotyczącym waszych danych w ciągu dni, a nie odkrywali go od klienta.
• Jasne określenie, jak wasze dane mogą być używane, przechowywane i chronione, oraz zobowiązanie do niewykorzystywania ich w celach, na które się nie zgodziliście.
• Ujawnienie podprocesorów i powiadomienie przed ich zmianą, żeby łańcuch nie wydłużał się po cichu.
• Zobowiązanie do usunięcia albo zwrotu waszych danych po zakończeniu umowy.
• Prawo do żądania dowodu poziomu bezpieczeństwa, takiego jak aktualna certyfikacja albo raport, w trakcie trwania relacji.

Nie zawsze wygracie każdą klauzulę, a dla mniejszych gotowych narzędzi możecie akceptować ich standardowe warunki zamiast negocjować swoje. To w porządku. Chodzi o to, żeby wiedzieć, co mówi umowa dla dostawców, na których zależy, i naciskać na warunki tam, gdzie macie dźwignię, zwykle w większych i bardziej dopasowanych relacjach.

5. Przeglądaj ważne relacje okresowo

Due diligence zrobione raz przy onboardingu opisuje dostawcę w jednym momencie. Firmy się zmieniają: certyfikacje wygasają, produkty są przejmowane, dane, których dotyka narzędzie, rosną wraz z waszym użyciem. Okresowy przegląd utrzymuje obraz aktualny bez zamieniania się w bieżnię.

Skaluj częstotliwość do warstwy. Przegląd każdego dostawcy z warstwy 1 raz do roku to rozsądny domyślny rytm, warstwa 2 dotykana lżej albo tylko na wyzwalacz. Przegląd nie musi być rozbudowany: potwierdź, że certyfikacja jest wciąż aktualna i w zakresie, potwierdź, że zakres dostępu i danych wciąż odpowiada temu, czego dostawca faktycznie potrzebuje, sprawdź, czy zmieniło się coś istotnego, i potwierdź ponownie warunki umowy. Przypisz przegląd do daty, której nie przegapicie, na przykład do odnowienia umowy, żeby działo się to jako część decyzji, którą i tak mieliście podjąć.

Wbuduj wyzwalacze między zaplanowanymi przeglądami. Dostawca ogłaszający własne naruszenie, poważna zmiana w tym, co dla was robi, albo wiadomość o przejęciu to wszystko powody, żeby spojrzeć ponownie, zanim wskaże na to kalendarz. Strona offboardingu też ma znaczenie: kiedy przestajecie korzystać z dostawcy, odbierzcie mu dostęp, potwierdźcie, że wasze dane zostały usunięte albo zwrócone, i zaktualizujcie inwentarz. Wycofany dostawca, który wciąż trzyma żywą integrację, to dokładnie ten rodzaj zapomnianych drzwi, które pojawiają się w raportach o naruszeniach.

Jak to się łączy z NIS2 i DORA

Dwa akty unijnego prawa przesuwają bezpieczeństwo łańcucha dostaw z dobrego pomysłu w oczekiwanie i oba sięgają firm mid-market, które same nie są bezpośrednio objęte zakresem.

NIS2, unijna dyrektywa o bezpieczeństwie sieci i informacji, wymaga od objętych zakresem podmiotów kluczowych i ważnych zarządzania ryzykiem cyberbezpieczeństwa w całej swojej działalności, a art. 21 ust. 2 lit. d nazywa wprost bezpieczeństwo łańcucha dostaw: podmioty muszą adresować ryzyka wynikające z relacji z bezpośrednimi dostawcami i usługodawcami. Jeśli NIS2 was dotyczy, udokumentowany inwentarz dostawców, podział na warstwy i proces due diligence to bezpośredni sposób na spełnienie tego wymogu. Jeśli was nie dotyczy, ale dotyczy waszych klientów, spodziewajcie się, że ci klienci zapytają, jak zarządzacie własnymi dostawcami, bo ich compliance zależy teraz częściowo od waszego.

DORA, akt o operacyjnej odporności cyfrowej, idzie dalej dla podmiotów finansowych. Art. 28-30 ustanawia szczegółowy reżim zarządzania ryzykiem stron trzecich ICT, w tym minimalne wymogi umowne i rejestr informacji wymieniający dostawców ICT danego podmiotu. Jeśli sprzedajecie bankom, ubezpieczycielom albo innym podmiotom finansowym, DORA to powód, dla którego ich zespoły zakupowe zadają teraz ostrzejsze pytania o wasze bezpieczeństwo i waszych podwykonawców niż kilka lat temu.

Praktyczny wniosek jest ten sam w obu przypadkach. Oczekiwania dotyczące łańcucha dostaw w NIS2 i DORA spływają w dół. Większy regulowany klient, który musi zarządzać ryzykiem swoich stron trzecich, przeniesie proporcjonalne oczekiwania na swoich dostawców, a firma z inwentarzem dostawców, modelem warstw i podpisanymi umowami powierzenia to ta, która odpowiada na te oczekiwania bez szamotania się. Zbudowanie tego dla własnej ochrony sprawia też, że łatwiej się was kupuje.

Źródła

• Verizon 2026 Data Breach Investigations Report · https://www.verizon.com/business/resources/reports/dbir/ (udział stron trzecich w 48% naruszeń; okno danych listopad 2024 do października 2025)
• Verizon 2026 DBIR PDF · https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf (pełny raport i dane szczegółowe)
• Verizon 2025 DBIR · https://www.verizon.com/business/resources/reports/2025-dbir-data-breach-investigations-report.pdf (wynik 30% dla poprzedniego roku, do porównania rok do roku)
• Directive (EU) 2022/2555 (NIS2), art. 21 · https://eur-lex.europa.eu/eli/dir/2022/2555/oj (art. 21 ust. 2 lit. d, bezpieczeństwo łańcucha dostaw wśród środków zarządzania ryzykiem cyberbezpieczeństwa)
• Regulation (EU) 2022/2554 (DORA), art. 28-30 · https://eur-lex.europa.eu/eli/reg/2022/2554/oj (zarządzanie ryzykiem stron trzecich ICT, wymogi umowne, rejestr informacji)
• GDPR art. 28 · https://eur-lex.europa.eu/eli/reg/2016/679/oj (obowiązki podmiotu przetwarzającego i wymóg umowy powierzenia danych)