Zaktualizowano: 18 sierpnia 2026
Czym jest ryzyko dostawców w cyberbezpieczeństwie? Ryzyko TPSP (Third-Party Service Provider) to zagrożenia wynikające z dostępu zewnętrznych podmiotów do systemów, danych lub infrastruktury organizacji.
MOVEit Transfer (maj 2023) – jedna podatność w narzędziu do transferu plików – dotknął ponad 2 700 organizacji globalnie, a Emsisoft oszacował łączne straty powyżej 15 mld USD.
SolarWinds (2020) – kompromitacja procesu build jednego dostawcy – zainfekował 18 000 klientów przez podpisaną cyfrowo aktualizację.
Oba incydenty pokazują tę samą logikę: atakujący wchodzi przez zaufanego dostawcę, bo to prostsze niż przełamanie własnych zabezpieczeń celu. PCI DSS v4.0.1, NIS2 i DORA nakładają konkretne, egzekwowalne obowiązki zarządzania ryzykiem dostawców – a audytorzy weryfikują każdy z nich osobno.
Ryzyko dostawców TPSP – w skrócie:
- Verizon DBIR 2024: ataki przez strony trzecie stanowiły 15% naruszeń – wzrost o 68% rok do roku, co czyni supply chain najszybciej rosnącym wektorem ataku
- PCI DSS v4.0.1 Wymaganie 12.8 nakłada sześć odrębnych obowiązków: lista TPSP, umowa pisemna, due diligence, roczny monitoring, Responsibility Matrix, zarządzanie skryptami – QSA weryfikuje każdy z nich osobno
- NIS2 art. 21 ust. 2 pkt d wymaga bezpieczeństwa łańcucha dostaw jako jednego z dziesięciu obowiązkowych środków dla podmiotów kluczowych i ważnych
- DORA art. 28 nakłada szczegółowe wymogi kontraktowe wobec krytycznych dostawców ICT: prawo audytu, klauzule wyjścia, lokalizacja danych, zakaz podwykonawstwa bez zgody – egzekwowalne przez regulatora sektorowego
- Roczny kwestionariusz wysłany raz i nieaktualizowany nie spełnia wymogu „monitorowania rocznego” z PCI DSS 12.8.4 – wymagany jest aktualny AOC lub ekwiwalent
- Patronusec jako akredytowany QSA i partner vCISO buduje programy zarządzania TPSP spełniające jednocześnie PCI DSS 12.8, NIS2 i DORA – od inwentaryzacji dostawców przez Responsibility Matrix po monitoring roczny
Spis treści
Dlaczego MOVEit i SolarWinds przedefiniowały podejście do ryzyka dostawców?
Przed 2020 rokiem standardowe due diligence dostawcy sprowadzało się do pytania „Czy macie ISO 27001?” – i na tym kończyła się weryfikacja. Oba incydenty pokazały, że certyfikat bezpieczeństwa dostawcy nie chroni klienta przed atakiem przeprowadzonym przez tego dostawcę.
MOVEit – anatomia ataku supply chain
Progress Software ujawnił krytyczną podatność CVE-2023-34362 (CVSS 9.8) w MOVEit Transfer 31 maja 2023 roku. Grupa Cl0p eksploatowała ją jako zero-day, prawdopodobnie przez kilka tygodni przed ujawnieniem. Organizacje z inwentarzem produktów dostawcy – nie tylko listy firm – były w stanie ocenić ekspozycję w ciągu godzin. Organizacje bez takiego inwentarza odkrywały swoją ekspozycję po dniach lub tygodniach.
Lekcja operacyjna z MOVEit
Program zarządzania TPSP musi zawierać inwentarz konkretnych produktów dostawcy, nie tylko nazw firm. Wiedza, że korzystasz z Progress Software, jest niewystarczająca – musisz wiedzieć, że używasz MOVEit Transfer w wersji X, żeby ocenić ekspozycję na CVE-2023-34362 w ciągu godzin.
SolarWinds – anatomia ataku przez łańcuch dostaw oprogramowania
Atakujący skompromitowali środowisko build SolarWinds i wstrzyknęli złośliwy kod do legalnej aktualizacji platformy Orion. Aktualizacja była podpisana cyfrowo przez SolarWinds – weryfikacja podpisu nie chroniła. 18 000 organizacji zainstalowało zainfekowaną wersję między marcem a czerwcem 2020 roku. Czas od infekcji do wykrycia wyniósł około dziewięciu miesięcy.
Lekcja operacyjna z SolarWinds
Certyfikat bezpieczeństwa dostawcy (ISO 27001, SOC 2) nie daje gwarancji bezpieczeństwa procesu wytwarzania oprogramowania. Program TPSP musi obejmować pytania o bezpieczeństwo pipeline’u build, mechanizmy weryfikacji integralności aktualizacji i monitoring zmian w oprogramowaniu dostawcy.
Patronusec Insight: W przeglądach programów TPSP prowadzonych w ramach usługi vCISO regularnie odkrywamy, że organizacje mają listę certyfikatów dostawców (ISO 27001, SOC 2, PCI DSS AOC), ale nie mają mapowania: który dostawca ma dostęp do czego, przez jaki kanał techniczny i do jakich danych może dotrzeć. Ta mapa zależności – TPSP × zakres dostępu × dane – jest warunkiem koniecznym sensownej priorytetyzacji ryzyka. Bez niej każdy incydent u dostawcy wymaga oceny od zera. Budujemy tę mapę jako pierwszy krok każdego projektu zarządzania ryzykiem dostawców.
Jak PCI DSS 12.8 reguluje zarządzanie dostawcami TPSP?
PCI DSS v4.0.1 Requirement 12.8 zawiera pięć podpunktów, od 12.8.1 do 12.8.5. Każdy dotyczy innego elementu zarządzania TPSP i podlega odrębnej ocenie. Zarządzanie skryptami na stronach płatności znajduje się w Requirement 6.4.3 i nie jest częścią Requirement 12.8.
12.8.1 – Lista TPSP
Organizacja utrzymuje listę TPSP, którym udostępnia dane kont płatniczych lub którzy mogą wpływać na ich bezpieczeństwo. Lista zawiera opis usług świadczonych przez każdego dostawcę.
12.8.2 – Pisemne umowy
Z TPSP utrzymywane są pisemne umowy zawierające potwierdzenie odpowiedzialności dostawcy za bezpieczeństwo danych kont płatniczych, które przechowuje, przetwarza lub przesyła w imieniu klienta, albo za zakres, w jakim jego usługa może wpływać na bezpieczeństwo środowiska klienta.
12.8.3 – Due diligence
Organizacja wdraża i stosuje proces właściwego due diligence przed rozpoczęciem współpracy z TPSP.
12.8.4 – Monitorowanie statusu zgodności
Organizacja monitoruje status zgodności PCI DSS każdego TPSP co najmniej raz na 12 miesięcy. Aktualny AOC obejmujący wykorzystywaną usługę jest częstym dowodem, ale jeśli dostawca nie posiada AOC, konieczne może być zebranie innych dowodów lub bezpośrednia ocena właściwych wymagań.
12.8.5 – Podział odpowiedzialności
Organizacja utrzymuje informacje o tym, które wymagania PCI DSS realizuje TPSP, które realizuje sama organizacja, a które są współdzielone. Informacje te często przyjmują formę Responsibility Matrix, ale standard nie narzuca konkretnej nazwy dokumentu.
| Wymaganie | PCI DSS 12.8 | NIS2 art. 21 | DORA art. 28 |
|---|---|---|---|
| Lista dostawców | ✅ obowiązkowe | ✅ obowiązkowe | ✅ rejestr krytycznych ICT |
| Umowa z klauzulą bezpieczeństwa | ✅ 12.8.2 | ✅ wymagana | ✅ szczegółowe klauzule |
| Due diligence przed onboardingiem | ✅ 12.8.3 | ✅ ocena ryzyka | ✅ obowiązkowe |
| Roczny monitoring zgodności | ✅ 12.8.4 | ✅ ciągły monitoring | ✅ przeglądy roczne |
| Prawo do audytu dostawcy | ❌ nie wprost | ✅ opcjonalne | ✅ obowiązkowe dla krytycznych |
| Klauzula wyjścia / exit plan | ❌ | ❌ | ✅ obowiązkowe |
Nie wiesz, czy Twój program zarządzania TPSP spełnia jednocześnie PCI DSS 12.8, NIS2 i DORA?
Patronusec przeprowadza przegląd programu TPSP i dostarcza gap report z wymaganiami każdej regulacji odniesionym do Twojego obecnego stanu. Po rozmowie scope-assessment przedstawiamy stałą wycenę przeglądu.
Umów bezpłatną rozmowę scope-assessment
Jak zbudować trójwarstwowy program zarządzania ryzykiem dostawców?
Program TPSP musi działać w trzech warstwach jednocześnie: inwentaryzacji, oceny i monitorowania. Wszystkie trzy muszą działać cyklicznie.
Warstwa 1 – Inwentaryzacja i klasyfikacja:
Każdy dostawca z dostępem do CDE lub danych regulowanych musi być zidentyfikowany (pełna lista, nie tylko „duże firmy”), skategoryzowany (Tier 1: bezpośredni dostęp do CDE lub danych wrażliwych; Tier 2: dostęp pośredni; Tier 3: minimalne ryzyko) i przypisany do właściciela po stronie klienta.
Praktyczna pułapka: narzędzie SaaS kupione przez dział marketingu bez wiedzy IT (shadow IT) jest Tier 1, jeśli przetwarza dane klientów – i często jest niewidoczne dla programu TPSP.
Warstwa 2 – Ocena przy onboardingu:
Przed wdrożeniem każdego dostawcy Tier 1: zebranie aktualnego AOC lub certyfikatu ISO 27001, podpisanie Responsibility Matrix, ocena technicznych kontroli (szyfrowanie transmisji, zarządzanie dostępem, logowanie), klauzule kontraktowe z wymogami bezpieczeństwa, prawem do audytu i procedurami incydentowymi.
Warstwa 3 – Monitoring ciągły:
Dla dostawców Tier 1 rocznie: zebranie nowego AOC, przegląd Responsibility Matrix (czy zmieniły się usługi?), przegląd incydentów u dostawcy, weryfikacja statusu patchowania produktów dostawcy używanych w CDE.
Patronusec Insight: Najdroższym elementem programu TPSP nie jest jego budowa, ale utrzymanie. Organizacje, które zbudowały rejestr TPSP i oceniły dostawców przy onboardingu, ale nie wdrożyły rocznego monitorowania, mają podczas audytu AOC sprzed dwóch lat – co natychmiast staje się findingiem QSA. Największa dźwignia operacyjna: wyznaczenie właściciela dla każdego dostawcy Tier 1 z zadaniem corocznego odświeżenia dokumentacji w kalendarzu. W ramach vCISO zarządzamy tym procesem jako funkcja ciągła, bez potrzeby pamiętania o terminach przez klienta.
Jak NIS2 i DORA zmieniają wymagania kontraktowe wobec dostawców ICT?
NIS2 (art. 21 ust. 2 pkt d) wymaga „bezpieczeństwa łańcucha dostaw, w tym aspektów związanych z bezpieczeństwem stosunków między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami”. W praktyce: ocena ryzyka bezpieczeństwa dla każdego kluczowego dostawcy ICT, klauzule bezpieczeństwa w umowach, procedury powiadamiania o incydentach u dostawcy.
DORA (art. 28) jest precyzyjniejsza. Dla instytucji finansowych obowiązują konkretne wymogi kontraktowe wobec krytycznych dostawców ICT:
- Prawo do audytu (i możliwość jego zlecenia regulatorowi)
- Klauzule wyjścia z minimalnym czasem przejścia
- Wymogi lokalizacji danych
- Zakaz dalszego podwykonawstwa bez zgody klienta
- Obowiązek raportowania incydentów przez dostawcę
- Plany wyjścia z każdego krytycznego dostawcy
Czy Twoje umowy z kluczowymi dostawcami ICT zawierają klauzule wymagane przez DORA?
Patronusec przeprowadza przegląd umów z dostawcami pod kątem zgodności z DORA art. 28 i przygotowuje wykaz wymaganych uzupełnień. Wynik: lista zmian do wprowadzenia w umowach z priorytetami i terminami.
Zamów przegląd umów z dostawcami
FAQ – Zarządzanie ryzykiem dostawców TPSP
Czy roczny kwestionariusz bezpieczeństwa spełnia wymóg monitorowania PCI DSS 12.8.4?
Nie sam w sobie. PCI DSS 12.8.4 wymaga potwierdzenia, że TPSP utrzymuje zgodność z PCI DSS. Preferowaną metodą jest aktualny AOC. Kwestionariusz może być stosowany jako alternatywa dla dostawców bez AOC, ale musi dokumentować konkretne kontrole PCI DSS, nie ogólne pytania o bezpieczeństwo. Odpowiedź „tak” bez weryfikacji jest niewystarczająca – QSA zapyta o mechanizm weryfikacji tej odpowiedzi.
Jak często powinienem zbierać AOC od dostawców?
Minimum raz w roku (PCI DSS 12.8.4). Dobrą praktyką jest konfiguracja alertów w kalendarzu na 60 dni przed wygaśnięciem każdego AOC – duże procesory płatnicze i dostawcy chmury odpowiadają na żądania AOC we własnym tempie, a nie w Twoim harmonogramie audytu.
Co to jest Responsibility Matrix i kto ją tworzy?
Responsibility Matrix to dokument przypisujący każde wymaganie PCI DSS do jednej ze stron: dostawcy lub klienta. Zazwyczaj tworzy ją dostawca i udostępnia klientowi. Klient weryfikuje, czy zakres odpowiedzialności dostawcy jest pokryty jego AOC. Jeśli dostawca nie ma Responsibility Matrix, możesz ją zbudować samodzielnie na podstawie AOC i zakresu usług – i przekazać dostawcy do potwierdzenia.
Czy DORA dotyczy naszych dostawców chmury publicznej?
Tak. AWS, Azure i GCP mogą być „krytycznymi dostawcami ICT” w rozumieniu DORA. Jeśli brak konkretnego dostawcy ICT mógłby zakłócić krytyczne operacje instytucji finansowej, dostawca powinien być traktowany jako krytyczny. DORA wymaga, żeby umowy z takimi dostawcami zawierały konkretne klauzule dotyczące audytu, wyjścia i ciągłości – które standardowe umowy chmurowe zazwyczaj nie zawierają bez negocjacji Enterprise Agreement.
Co zrobić, gdy kluczowy dostawca nie posiada aktualnego AOC?
Opcje: (1) własna ocena kontroli dostawcy (time-intensive, ale defensywna wobec QSA), (2) żądanie od dostawcy harmonogramu certyfikacji z tymczasową akceptacją ryzyka przez zarząd, (3) ograniczenie dostępu dostawcy do CDE do minimum technicznie możliwego, (4) zmiana dostawcy. Ignorowanie braku AOC to finding PCI DSS 12.8.4 podczas następnego audytu.
Ile kosztuje przegląd programu TPSP w Patronusec?
Cena zależy od liczby dostawców Tier 1, zakresu regulacji (PCI DSS, NIS2, DORA lub kombinacja) i aktualnego stanu dokumentacji. Po bezpłatnej 30-minutowej rozmowie scope-assessment przedstawiamy stałą wycenę przeglądu z gwarantowanym zakresem i terminem. Dla klientów w modelu vCISO monitoring TPSP jest częścią stałego zaangażowania.
Jak zacząć zarządzanie ryzykiem dostawców, jeśli firma nie ma programu TPSP?
Zacznij od inwentaryzacji: lista wszystkich dostawców z dostępem do systemów lub danych, kategoryzacja Tier 1/2/3, przypisanie właścicieli. Następnie zebranie AOC od wszystkich Tier 1. Następnie Responsibility Matrix dla Tier 1 z PCI DSS lub innymi regulacjami. W naszym doświadczeniu projektowym pełna inwentaryzacja i wstępna ocena mid-market organizacji zajmuje 3-5 tygodni przy wsparciu zewnętrznym.
Zarządzanie ryzykiem dostawców TPSP – bezpłatna konsultacja
Patronusec jako akredytowany QSA i partner vCISO buduje i utrzymuje programy zarządzania TPSP dla organizacji w sektorach fintech, e-commerce i finansowym – spełniające jednocześnie PCI DSS 12.8, NIS2 i DORA.
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- Ocenić, czy Twój obecny program TPSP spełnia wymagania PCI DSS 12.8, NIS2 i DORA
- Zidentyfikować dostawców Tier 1, których weryfikacja jest najważniejsza audytowo
- Zaplanować wdrożenie rejestru TPSP i procesu rocznego monitorowania
- Wybrać model wsparcia: jednorazowy przegląd lub ciągłe zarządzanie w modelu vCISO
Bezpłatna konsultacja | vCISO – zarządzanie TPSP | Certyfikacja PCI DSS | Analiza luk PCI DSS | NIS2 wdrożenie
