R\u00f3\u017cnice pomi\u0119dzy TPRM a VRM<\/strong><\/h2>\n\n\n\nW praktyce oba poj\u0119cia cz\u0119sto stosuje si\u0119 zamiennie, ale w du\u017cych organizacjach r\u00f3\u017cnica mi\u0119dzy nimi ma znaczenie:<\/p>\n\n\n\n
\n- TPRM (Third-Party Risk Management<\/strong>) to szersze podej\u015bcie do zarz\u0105dzania ryzykiem zwi\u0105zanym ze wsp\u00f3\u0142prac\u0105 z podmiotami zewn\u0119trznymi – nie tylko dostawcami, lecz tak\u017ce partnerami biznesowymi czy agencjami.<\/li>\n\n\n\n
- VRM (Vendor Risk Management) to<\/strong> w\u0119\u017cszy obszar skupiony wy\u0142\u0105cznie na ryzyku zwi\u0105zanym z zarz\u0105dzaniem dostawcami<\/a> z kt\u00f3rymi firma ma bezpo\u015bredni\u0105 relacj\u0119 umown\u0105.<\/li>\n<\/ul>\n\n\n\n
W organizacjach wsp\u00f3\u0142pracuj\u0105cych g\u0142\u00f3wnie z bezpo\u015brednimi dostawcami VRM w praktyce pokrywa wi\u0119kszo\u015b\u0107 potrzeb.<\/p>\n\n\n\n
Wsp\u00f3lnym za\u0142o\u017ceniem obu podej\u015b\u0107 jest prosta obserwacja: ryzyko dostawcy staje si\u0119 ryzykiem organizacji. S\u0142abe zabezpieczenia po stronie zewn\u0119trznego partnera mog\u0105 oznacza\u0107 naruszenie danych po stronie zleceniodawcy. Awaria operacyjna u dostawcy przek\u0142ada si\u0119 na zak\u0142\u00f3cenia ci\u0105g\u0142o\u015bci dzia\u0142ania organizacji. Naruszenie przepis\u00f3w przez podmiot przetwarzaj\u0105cy dane niesie ryzyko wsp\u00f3\u0142odpowiedzialno\u015bci administratora. Zakres TPRM jest zwykle szerszy, ni\u017c organizacje zak\u0142adaj\u0105, gdy buduj\u0105 sw\u00f3j pierwszy program.<\/p>\n\n\n\n
Cykl \u017cycia zarz\u0105dzania ryzykiem dostawc\u00f3w<\/h2>\n\n\n\n
TPRM to nie projekt z dat\u0105 ko\u0144cow\u0105, lecz proces obejmuj\u0105cy pe\u0142n\u0105 relacj\u0119 – od zapytania ofertowego po zako\u0144czenie wsp\u00f3\u0142pracy. Skuteczne programy traktuj\u0105 ka\u017cdy z poni\u017cszych etap\u00f3w jako odr\u0119bn\u0105 dyscyplin\u0119.<\/p>\n\n\n\n
Punktem wyj\u015bcia do ka\u017cdego z etap\u00f3w zarz\u0105dzania ryzykiem<\/a> jest inwentaryzacja<\/strong>: kompletna lista wszystkich podmiot\u00f3w zewn\u0119trznych wraz z informacj\u0105 o \u015bwiadczonych us\u0142ugach, dost\u0119pie do system\u00f3w i obs\u0142ugiwanych procesach. Ten etap niemal zawsze ujawnia relacje nieznane centralnemu zespo\u0142owi ds. zgodno\u015bci: umowy zawarte na poziomie dzia\u0142\u00f3w, dost\u0119py przyznane przy wdro\u017ceniach i nigdy nieodwo\u0142ane, podmioty obs\u0142uguj\u0105ce procesy krytyczne bez \u017cadnej formalnej oceny.<\/p>\n\n\n\nPo zinwentaryzowaniu konieczna jest klasyfikacja dostawc\u00f3w wed\u0142ug krytyczno\u015bci.<\/strong> Kryteria segmentacji obejmuj\u0105 zazwyczaj: rodzaj i wolumen danych dost\u0119pnych dla dostawcy, skutki operacyjne jego potencjalnej awarii oraz regulacyjn\u0105 wag\u0119 relacji. Od tej klasyfikacji zale\u017cy zar\u00f3wno g\u0142\u0119boko\u015b\u0107 wst\u0119pnej oceny, jak i rytm p\u00f3\u017aniejszych przegl\u0105d\u00f3w.<\/p>\n\n\n\nPrzed formalnym nawi\u0105zaniem relacji kontraktowej przeprowadza si\u0119 due diligence:<\/strong> weryfikacj\u0119 certyfikat\u00f3w bezpiecze\u0144stwa, ocen\u0119 plan\u00f3w ci\u0105g\u0142o\u015bci dzia\u0142ania, analiz\u0119 praktyk ochrony danych i identyfikacj\u0119 podwykonawc\u00f3w. Kwestionariusze s\u0105 najcz\u0119\u015bciej stosowanymi narz\u0119dziami, lecz odpowiedziami na ich pytania s\u0105 tylko deklaracje. Dla dostawc\u00f3w wysokiego ryzyka wymagana jest weryfikacja na podstawie dowod\u00f3w: raport\u00f3w audytowych, wynik\u00f3w test\u00f3w bezpiecze\u0144stwa, zakresu i aktualno\u015bci certyfikat\u00f3w.<\/p>\n\n\n\nWyniki due diligence przek\u0142adaj\u0105 si\u0119 na profil ryzyka<\/strong>, kt\u00f3ry kszta\u0142tuje tre\u015b\u0107 umowy. Na etapie negocjacji kontraktowych zarz\u0105dzanie ryzykiem przyjmuje posta\u0107 konkretnych decyzji: kt\u00f3re ryzyka mo\u017cna zaakceptowa\u0107, a kt\u00f3re wymagaj\u0105 zabezpieczenia umownego. Kluczowe klauzule obejmuj\u0105 obowi\u0105zek zg\u0142aszania incydent\u00f3w bezpiecze\u0144stwa z okre\u015blonym terminem i zakresem informacji, prawo do audytu, wymogi wobec podwykonawc\u00f3w i subprocesor\u00f3w, postanowienia o lokalizacji danych oraz warunki zako\u0144czenia wsp\u00f3\u0142pracy chroni\u0105ce ci\u0105g\u0142o\u015b\u0107 operacyjn\u0105.<\/p>\n\n\n\nCi\u0105g\u0142e monitorowanie <\/strong>to obszar, w kt\u00f3rym wi\u0119kszo\u015b\u0107 program\u00f3w traci skuteczno\u015b\u0107. Profil ryzyka dostawcy zmienia si\u0119 w czasie: zmiana w\u0142a\u015bciciela, rotacja kluczowych pracownik\u00f3w, wyga\u015bni\u0119cie certyfikat\u00f3w czy nowe podatno\u015bci we wsp\u00f3lnej infrastrukturze mog\u0105 istotnie wp\u0142yn\u0105\u0107 na poziom ryzyka bez \u017cadnego sygna\u0142u alarmowego. Pe\u0142ny proces zarz\u0105dzania ryzykiem wymaga wi\u0119c przegl\u0105d\u00f3w wed\u0142ug harmonogramu: kwartalnych dla dostawc\u00f3w najwy\u017cszego tieru, corocznych dla pozosta\u0142ych, a reaktywnych zawsze wtedy, gdy pojawi si\u0119 istotna zmiana.<\/p>\n\n\n\nOffboarding<\/strong> jest etapem najcz\u0119\u015bciej zaniedbywanym. Zako\u0144czenie relacji z dostawc\u0105 rodzi w\u0142asne ryzyka: zwrot lub usuni\u0119cie danych, odwo\u0142anie dost\u0119p\u00f3w, transfer wiedzy procesowej i ci\u0105g\u0142o\u015b\u0107 obs\u0142ugi. Konsekwencje braku formalnych procedur offboardingowych ujawniaj\u0105 si\u0119 zazwyczaj dopiero po fakcie.<\/p>\n\n\n\n![\"\"](\"https:\/\/adaptivegrc.com\/wp-content\/uploads\/2026\/06\/Skuteczne-zarzadzanie-ryzykiem-dostawcow-1024x610.png\")
<\/figure>\n\n\n\nJak ocenia\u0107 ryzyko dostawcy i podmiot\u00f3w trzecich?<\/h2>\n\n\n\n
Ocena ryzyka dostawcy i podmiot\u00f3w trzecich, czy to wst\u0119pna, czy jako reocena, powinna obejmowa\u0107 kilka sta\u0142ych obszar\u00f3w. G\u0142\u0119boko\u015b\u0107 analizy zale\u017cy od poziomu krytyczno\u015bci.<\/p>\n\n\n\n
Ryzyko cyberbezpiecze\u0144stwa<\/strong> dotyczy zabezpiecze\u0144 technicznych dostawcy, sposobu zarz\u0105dzania podatno\u015bciami, zdolno\u015bci wykrywania i reagowania na incydenty oraz bezpiecze\u0144stwa punkt\u00f3w integracji z systemami organizacji. Certyfikat ISO 27001 jest u\u017cytecznym punktem odniesienia, lecz warto pami\u0119ta\u0107, \u017ce nie jest on gwarancj\u0105: zakres certyfikacji ma istotne znaczenie, a certyfikat mo\u017ce wygasn\u0105\u0107 lub zosta\u0107 przyznany podmiotowi, kt\u00f3ry od tamtej pory zmieni\u0142 swoje praktyki.<\/p>\n\n\n\nRyzyko operacyjne i ci\u0105g\u0142o\u015bci dzia\u0142ania<\/strong> obejmuje odporno\u015b\u0107 dostawcy na zak\u0142\u00f3cenia zewn\u0119trzne i wewn\u0119trzne. Dla dostawc\u00f3w krytycznych wa\u017cniejsze od samego istnienia planu ci\u0105g\u0142o\u015bci jest to, czy by\u0142 on realnie testowany i kiedy. Dokumentacja bez dowod\u00f3w testowania ma ograniczon\u0105 warto\u015b\u0107.<\/p>\n\n\n\nRyzyko ochrony danych i zgodno\u015bci<\/strong> dotyczy sposobu, w jaki dostawca przetwarza dane osobowe powierzone mu przez organizacj\u0119, miejsca i trybu ich przechowywania i transferu oraz w\u0142asnego programu zgodno\u015bci regulacyjnej. Jest to szczeg\u00f3lnie istotne w przypadku podmiot\u00f3w dzia\u0142aj\u0105cych w kilku jurysdykcjach jednocze\u015bnie.<\/p>\n\n\n\nRyzyko \u0142a\u0144cucha dostaw<\/strong> wynika z podwykonawc\u00f3w i zale\u017cno\u015bci technologicznych samego dostawcy. Podmiot z silnymi kontrolami wewn\u0119trznymi mo\u017ce jednocze\u015bnie korzysta\u0107 z dostawc\u00f3w czwartej strony (<\/a>Fourth Parties) o znacznie ni\u017cszych standardach bezpiecze\u0144stwa. Wymaganie ujawnienia kluczowych podwykonawc\u00f3w i zobowi\u0105zanie dostawcy do stosowania wobec nich minimalnych wymaga\u0144 bezpiecze\u0144stwa to w praktyce najskuteczniejszy dost\u0119pny mechanizm.<\/p>\n\n\n\n![\"\"](\"https:\/\/adaptivegrc.com\/wp-content\/uploads\/2026\/06\/Ocena-ryzyka-dostawcy-i-podmiotow-trzecich-1024x610.png\")
<\/figure>\n\n\n\nTPRM a wymogi regulacyjne (NIS2, DORA, RODO, ISO, EU AI Act)<\/h2>\n\n\n\n
Zarz\u0105dzanie ryzykiem stron trzecich sta\u0142o si\u0119 elementem niezb\u0119dnym, a nie jedynie rekomendacj\u0105. W wi\u0119kszo\u015bci regulowanych sektor\u00f3w jest dzi\u015b wymogiem prawnym lub standardem bran\u017cowym, kt\u00f3rego spe\u0142nienia oczekuj\u0105 zar\u00f3wno audytorzy wewn\u0119trzni, jak i organy nadzoru.<\/p>\n\n\n\n
Dyrektywa NIS2<\/a> nak\u0142ada na operator\u00f3w us\u0142ug kluczowych i wa\u017cne podmioty obowi\u0105zek zarz\u0105dzania bezpiecze\u0144stwem \u0142a\u0144cucha dostaw. Wym\u00f3g obejmuje ocen\u0119 praktyk bezpiecze\u0144stwa bezpo\u015brednich dostawc\u00f3w oraz zdolno\u015b\u0107 do wykazania tej oceny przed w\u0142a\u015bciwym organem krajowym.<\/p>\n\n\n\nDORA<\/a>, obejmuj\u0105ca instytucje finansowe i ich dostawc\u00f3w us\u0142ug ICT, jest szersza. Wymaga zawierania pisemnych um\u00f3w ze wszystkimi dostawcami ICT, zawieraj\u0105cych szczeg\u00f3\u0142owe postanowienia dotycz\u0105ce praw dost\u0119pu i audytu, wymog\u00f3w bezpiecze\u0144stwa informacji oraz ci\u0105g\u0142o\u015bci dzia\u0142ania. Nak\u0142ada ponadto obowi\u0105zek prowadzenia rejestr\u00f3w zale\u017cno\u015bci od podmiot\u00f3w ICT. Dla instytucji finansowych posiadaj\u0105cych dzia\u0142aj\u0105cy program TPRM w\u0142a\u015bciwym krokiem jest przeprowadzenie analizy luk pod k\u0105tem DORA, a nie budowanie nowego procesu od zera.<\/p>\n\n\n\nRODO wymaga, by ka\u017cdy dostawca przetwarzaj\u0105cy dane osobowe na zlecenie organizacji dzia\u0142a\u0142 w oparciu o umow\u0119 powierzenia przetwarzania spe\u0142niaj\u0105c\u0105 wymagania art. 28 rozporz\u0105dzenia. Administrator danych jest zobowi\u0105zany do weryfikacji podmiotu przetwarzaj\u0105cego przed powierzeniem mu jakichkolwiek danych.<\/p>\n\n\n\n
ISO 27001<\/a> odnosi si\u0119 do relacji z dostawcami, wymagaj\u0105c polityki zarz\u0105dzania bezpiecze\u0144stwem informacji w tych relacjach oraz odpowiednich mechanizm\u00f3w nadzoru. ISO 22301<\/a> wymaga natomiast, by plany ci\u0105g\u0142o\u015bci dzia\u0142ania uwzgl\u0119dnia\u0142y rzeczywist\u0105 odporno\u015b\u0107 kluczowych dostawc\u00f3w na zak\u0142\u00f3cenia.<\/p>\n\n\n\nDobrze zaprojektowany program TPRM mo\u017ce realizowa\u0107 wymagania wszystkich tych regulacji w ramach jednego zestawu proces\u00f3w. Utrzymywanie osobnych \u015bcie\u017cek dla ka\u017cdego regulatora to rozwi\u0105zanie kosztowne i trudne do obs\u0142ugi w d\u0142ugim terminie.<\/p>\n\n\n\n
W przypadku dostawc\u00f3w wykorzystuj\u0105cych systemy AI organizacje powinny r\u00f3wnie\u017c uwzgl\u0119dnia\u0107 wymagania wynikaj\u0105ce z EU AI Act, w szczeg\u00f3lno\u015bci dotycz\u0105ce transparentno\u015bci, nadzoru oraz zarz\u0105dzania ryzykiem system\u00f3w wysokiego ryzyka. Rozporz\u0105dzenie obejmuje zar\u00f3wno dostawc\u00f3w system\u00f3w AI (providers), jak i podmioty wdra\u017caj\u0105ce je w swoich procesach (deployers), dlatego samo korzystanie z rozwi\u0105zania AI dostarczonego przez stron\u0119 trzeci\u0105 rodzi po stronie organizacji w\u0142asne obowi\u0105zki regulacyjne. W ramach due diligence takiego dostawcy nale\u017cy ustali\u0107, do kt\u00f3rej kategorii ryzyka kwalifikuje si\u0119 jego system, czy przeszed\u0142 wymagan\u0105 ocen\u0119 zgodno\u015bci oraz jak udokumentowany jest nadz\u00f3r cz\u0142owieka nad jego dzia\u0142aniem. Dla system\u00f3w wysokiego ryzyka konieczne s\u0105 dodatkowo: techniczna dokumentacja, rejestrowanie zdarze\u0144 i mechanizmy umo\u017cliwiaj\u0105ce realny audyt. Wymogi te musz\u0105 znale\u017a\u0107 odzwierciedlenie w klauzulach umownych z dostawc\u0105, w przeciwnym razie organizacja przejmuje jego ryzyko regulacyjne bez realnej mo\u017cliwo\u015bci kontroli.<\/p>\n\n\n\n
Najcz\u0119stsze b\u0142\u0119dy w programach TPRM. Jak ich unika\u0107?<\/h2>\n\n\n\n
Najcz\u0119\u015bciej pope\u0142niany b\u0142\u0105d w programach TRRM dotyczy zakresu stosowania programu. Organizacje buduj\u0105 proces weryfikacji dostawc\u00f3w, a nast\u0119pnie stosuj\u0105 go tylko do cz\u0119\u015bci swojej bazy kontraktowej. Dostawcy strategiczni s\u0105 oceniani starannie; dostawcy z d\u0142ugiego ogona um\u00f3w pozostaj\u0105 poza jakimkolwiek nadzorem. Ryzyko koncentruje si\u0119 tam, gdzie widoczno\u015b\u0107 jest najni\u017csza.<\/p>\n\n\n\n
Drugim powtarzaj\u0105cym si\u0119 problemem jest traktowanie due diligence jako jednorazowej formalno\u015bci poprzedzaj\u0105cej podpisanie umowy. Dostawca, kt\u00f3ry przeszed\u0142 ocen\u0119 trzy lata temu, m\u00f3g\u0142 od tego czasu zmieni\u0107 w\u0142a\u015bciciela, platform\u0119 technologiczn\u0105 lub kadr\u0119 zarz\u0105dzaj\u0105c\u0105 odpowiedzialn\u0105 za bezpiecze\u0144stwo. \u017badna z tych zmian nie uruchomi automatycznie ponownej weryfikacji, je\u015bli program nie ma wbudowanego mechanizmu jej inicjowania.<\/p>\n\n\n\n
Trzecim b\u0142\u0119dem jest nadmierne zaufanie do deklaracji zawartych w kwestionariuszach. Jako\u015b\u0107 tych odpowiedzi zale\u017cy od rzetelno\u015bci i kompetencji osoby je wype\u0142niaj\u0105cej. Dla dostawc\u00f3w o wysokiej krytyczno\u015bci ocena powinna opiera\u0107 si\u0119 na dowodach: raportach audytowych, wynikach test\u00f3w bezpiecze\u0144stwa, zakresie i aktualno\u015bci certyfikacji.<\/p>\n\n\n\n
Czwarty problem jest organizacyjny: brak wyra\u017anego w\u0142a\u015bciciela procesu. TPRM le\u017cy na przeci\u0119ciu obszar\u00f3w odpowiedzialno\u015bci procurement, IT, bezpiecze\u0144stwa, prawa i zgodno\u015bci. Brak w\u0142a\u015bciciela procesu oznacza, \u017ce w\u0142a\u015bcicielem ryzyka mo\u017ce sta\u0107 si\u0119 przypadek. Skuteczna realizacja wymaga wyznaczonego w\u0142a\u015bciciela z realnym umocowaniem, aktywnego wk\u0142adu ka\u017cdej z zaanga\u017cowanych funkcji i sponsoringu na poziomie zarz\u0105du lub komitetu ryzyka.<\/p>\n\n\n\n
Podsumowanie:
Zarz\u0105dzanie ryzykiem dostawc\u00f3w zaczyna dzia\u0142a\u0107 dopiero wtedy, gdy przestaje by\u0107 jednorazowym projektem porz\u0105dkuj\u0105cym, a staje si\u0119 sta\u0142ym elementem codziennego funkcjonowania organizacji. Pe\u0142ny cykl \u017cycia relacji z dostawc\u0105, segmentacja wed\u0142ug krytyczno\u015bci, due diligence oparte na dowodach oraz ci\u0105g\u0142y monitoring powinny tworzy\u0107 sp\u00f3jny mechanizm, w kt\u00f3rym poszczeg\u00f3lne elementy wzajemnie si\u0119 uzupe\u0142niaj\u0105 i wzmacniaj\u0105.<\/p>\n\n\n\n
NIS2, DORA, RODO czy normy ISO formalizuj\u0105 dzi\u015b podej\u015bcie, kt\u00f3re dojrza\u0142e programy TPRM stosuj\u0105 w praktyce od lat. Dlatego dla wi\u0119kszo\u015bci organizacji bardziej racjonalnym krokiem b\u0119dzie identyfikacja luk i usprawnienie istniej\u0105cych proces\u00f3w ni\u017c budowanie ca\u0142ego modelu od zera. O skuteczno\u015bci programu w praktyce decyduje przede wszystkim to, czy organizacja jasno okre\u015bli\u0142a w\u0142a\u015bciciela odpowiedzialnego za jego codzienne funkcjonowanie.<\/p>\n\n\n\n![\"\"](\"https:\/\/adaptivegrc.com\/wp-content\/uploads\/2026\/06\/Najczestsze-bledy-w-programach-TPRM-1024x610.png\")
<\/figure>\n\n\n\nFAQ – Najcz\u0119\u015bciej zadawane pytania<\/h2>\n\n\n
W organizacjach wsp\u00f3\u0142pracuj\u0105cych g\u0142\u00f3wnie z bezpo\u015brednimi dostawcami VRM w praktyce pokrywa wi\u0119kszo\u015b\u0107 potrzeb.<\/p>\n\n\n\n
Wsp\u00f3lnym za\u0142o\u017ceniem obu podej\u015b\u0107 jest prosta obserwacja: ryzyko dostawcy staje si\u0119 ryzykiem organizacji. S\u0142abe zabezpieczenia po stronie zewn\u0119trznego partnera mog\u0105 oznacza\u0107 naruszenie danych po stronie zleceniodawcy. Awaria operacyjna u dostawcy przek\u0142ada si\u0119 na zak\u0142\u00f3cenia ci\u0105g\u0142o\u015bci dzia\u0142ania organizacji. Naruszenie przepis\u00f3w przez podmiot przetwarzaj\u0105cy dane niesie ryzyko wsp\u00f3\u0142odpowiedzialno\u015bci administratora. Zakres TPRM jest zwykle szerszy, ni\u017c organizacje zak\u0142adaj\u0105, gdy buduj\u0105 sw\u00f3j pierwszy program.<\/p>\n\n\n\n
Cykl \u017cycia zarz\u0105dzania ryzykiem dostawc\u00f3w<\/h2>\n\n\n\n
TPRM to nie projekt z dat\u0105 ko\u0144cow\u0105, lecz proces obejmuj\u0105cy pe\u0142n\u0105 relacj\u0119 – od zapytania ofertowego po zako\u0144czenie wsp\u00f3\u0142pracy. Skuteczne programy traktuj\u0105 ka\u017cdy z poni\u017cszych etap\u00f3w jako odr\u0119bn\u0105 dyscyplin\u0119.<\/p>\n\n\n\n
Punktem wyj\u015bcia do ka\u017cdego z etap\u00f3w zarz\u0105dzania ryzykiem<\/a> jest inwentaryzacja<\/strong>: kompletna lista wszystkich podmiot\u00f3w zewn\u0119trznych wraz z informacj\u0105 o \u015bwiadczonych us\u0142ugach, dost\u0119pie do system\u00f3w i obs\u0142ugiwanych procesach. Ten etap niemal zawsze ujawnia relacje nieznane centralnemu zespo\u0142owi ds. zgodno\u015bci: umowy zawarte na poziomie dzia\u0142\u00f3w, dost\u0119py przyznane przy wdro\u017ceniach i nigdy nieodwo\u0142ane, podmioty obs\u0142uguj\u0105ce procesy krytyczne bez \u017cadnej formalnej oceny.<\/p>\n\n\n\n Po zinwentaryzowaniu konieczna jest klasyfikacja dostawc\u00f3w wed\u0142ug krytyczno\u015bci.<\/strong> Kryteria segmentacji obejmuj\u0105 zazwyczaj: rodzaj i wolumen danych dost\u0119pnych dla dostawcy, skutki operacyjne jego potencjalnej awarii oraz regulacyjn\u0105 wag\u0119 relacji. Od tej klasyfikacji zale\u017cy zar\u00f3wno g\u0142\u0119boko\u015b\u0107 wst\u0119pnej oceny, jak i rytm p\u00f3\u017aniejszych przegl\u0105d\u00f3w.<\/p>\n\n\n\n Przed formalnym nawi\u0105zaniem relacji kontraktowej przeprowadza si\u0119 due diligence:<\/strong> weryfikacj\u0119 certyfikat\u00f3w bezpiecze\u0144stwa, ocen\u0119 plan\u00f3w ci\u0105g\u0142o\u015bci dzia\u0142ania, analiz\u0119 praktyk ochrony danych i identyfikacj\u0119 podwykonawc\u00f3w. Kwestionariusze s\u0105 najcz\u0119\u015bciej stosowanymi narz\u0119dziami, lecz odpowiedziami na ich pytania s\u0105 tylko deklaracje. Dla dostawc\u00f3w wysokiego ryzyka wymagana jest weryfikacja na podstawie dowod\u00f3w: raport\u00f3w audytowych, wynik\u00f3w test\u00f3w bezpiecze\u0144stwa, zakresu i aktualno\u015bci certyfikat\u00f3w.<\/p>\n\n\n\n Wyniki due diligence przek\u0142adaj\u0105 si\u0119 na profil ryzyka<\/strong>, kt\u00f3ry kszta\u0142tuje tre\u015b\u0107 umowy. Na etapie negocjacji kontraktowych zarz\u0105dzanie ryzykiem przyjmuje posta\u0107 konkretnych decyzji: kt\u00f3re ryzyka mo\u017cna zaakceptowa\u0107, a kt\u00f3re wymagaj\u0105 zabezpieczenia umownego. Kluczowe klauzule obejmuj\u0105 obowi\u0105zek zg\u0142aszania incydent\u00f3w bezpiecze\u0144stwa z okre\u015blonym terminem i zakresem informacji, prawo do audytu, wymogi wobec podwykonawc\u00f3w i subprocesor\u00f3w, postanowienia o lokalizacji danych oraz warunki zako\u0144czenia wsp\u00f3\u0142pracy chroni\u0105ce ci\u0105g\u0142o\u015b\u0107 operacyjn\u0105.<\/p>\n\n\n\n Ci\u0105g\u0142e monitorowanie <\/strong>to obszar, w kt\u00f3rym wi\u0119kszo\u015b\u0107 program\u00f3w traci skuteczno\u015b\u0107. Profil ryzyka dostawcy zmienia si\u0119 w czasie: zmiana w\u0142a\u015bciciela, rotacja kluczowych pracownik\u00f3w, wyga\u015bni\u0119cie certyfikat\u00f3w czy nowe podatno\u015bci we wsp\u00f3lnej infrastrukturze mog\u0105 istotnie wp\u0142yn\u0105\u0107 na poziom ryzyka bez \u017cadnego sygna\u0142u alarmowego. Pe\u0142ny proces zarz\u0105dzania ryzykiem wymaga wi\u0119c przegl\u0105d\u00f3w wed\u0142ug harmonogramu: kwartalnych dla dostawc\u00f3w najwy\u017cszego tieru, corocznych dla pozosta\u0142ych, a reaktywnych zawsze wtedy, gdy pojawi si\u0119 istotna zmiana.<\/p>\n\n\n\n Offboarding<\/strong> jest etapem najcz\u0119\u015bciej zaniedbywanym. Zako\u0144czenie relacji z dostawc\u0105 rodzi w\u0142asne ryzyka: zwrot lub usuni\u0119cie danych, odwo\u0142anie dost\u0119p\u00f3w, transfer wiedzy procesowej i ci\u0105g\u0142o\u015b\u0107 obs\u0142ugi. Konsekwencje braku formalnych procedur offboardingowych ujawniaj\u0105 si\u0119 zazwyczaj dopiero po fakcie.<\/p>\n\n\n\n Ocena ryzyka dostawcy i podmiot\u00f3w trzecich, czy to wst\u0119pna, czy jako reocena, powinna obejmowa\u0107 kilka sta\u0142ych obszar\u00f3w. G\u0142\u0119boko\u015b\u0107 analizy zale\u017cy od poziomu krytyczno\u015bci.<\/p>\n\n\n\n Ryzyko cyberbezpiecze\u0144stwa<\/strong> dotyczy zabezpiecze\u0144 technicznych dostawcy, sposobu zarz\u0105dzania podatno\u015bciami, zdolno\u015bci wykrywania i reagowania na incydenty oraz bezpiecze\u0144stwa punkt\u00f3w integracji z systemami organizacji. Certyfikat ISO 27001 jest u\u017cytecznym punktem odniesienia, lecz warto pami\u0119ta\u0107, \u017ce nie jest on gwarancj\u0105: zakres certyfikacji ma istotne znaczenie, a certyfikat mo\u017ce wygasn\u0105\u0107 lub zosta\u0107 przyznany podmiotowi, kt\u00f3ry od tamtej pory zmieni\u0142 swoje praktyki.<\/p>\n\n\n\n Ryzyko operacyjne i ci\u0105g\u0142o\u015bci dzia\u0142ania<\/strong> obejmuje odporno\u015b\u0107 dostawcy na zak\u0142\u00f3cenia zewn\u0119trzne i wewn\u0119trzne. Dla dostawc\u00f3w krytycznych wa\u017cniejsze od samego istnienia planu ci\u0105g\u0142o\u015bci jest to, czy by\u0142 on realnie testowany i kiedy. Dokumentacja bez dowod\u00f3w testowania ma ograniczon\u0105 warto\u015b\u0107.<\/p>\n\n\n\n Ryzyko ochrony danych i zgodno\u015bci<\/strong> dotyczy sposobu, w jaki dostawca przetwarza dane osobowe powierzone mu przez organizacj\u0119, miejsca i trybu ich przechowywania i transferu oraz w\u0142asnego programu zgodno\u015bci regulacyjnej. Jest to szczeg\u00f3lnie istotne w przypadku podmiot\u00f3w dzia\u0142aj\u0105cych w kilku jurysdykcjach jednocze\u015bnie.<\/p>\n\n\n\n Ryzyko \u0142a\u0144cucha dostaw<\/strong> wynika z podwykonawc\u00f3w i zale\u017cno\u015bci technologicznych samego dostawcy. Podmiot z silnymi kontrolami wewn\u0119trznymi mo\u017ce jednocze\u015bnie korzysta\u0107 z dostawc\u00f3w czwartej strony (<\/a>Fourth Parties) o znacznie ni\u017cszych standardach bezpiecze\u0144stwa. Wymaganie ujawnienia kluczowych podwykonawc\u00f3w i zobowi\u0105zanie dostawcy do stosowania wobec nich minimalnych wymaga\u0144 bezpiecze\u0144stwa to w praktyce najskuteczniejszy dost\u0119pny mechanizm.<\/p>\n\n\n\n Zarz\u0105dzanie ryzykiem stron trzecich sta\u0142o si\u0119 elementem niezb\u0119dnym, a nie jedynie rekomendacj\u0105. W wi\u0119kszo\u015bci regulowanych sektor\u00f3w jest dzi\u015b wymogiem prawnym lub standardem bran\u017cowym, kt\u00f3rego spe\u0142nienia oczekuj\u0105 zar\u00f3wno audytorzy wewn\u0119trzni, jak i organy nadzoru.<\/p>\n\n\n\n Dyrektywa NIS2<\/a> nak\u0142ada na operator\u00f3w us\u0142ug kluczowych i wa\u017cne podmioty obowi\u0105zek zarz\u0105dzania bezpiecze\u0144stwem \u0142a\u0144cucha dostaw. Wym\u00f3g obejmuje ocen\u0119 praktyk bezpiecze\u0144stwa bezpo\u015brednich dostawc\u00f3w oraz zdolno\u015b\u0107 do wykazania tej oceny przed w\u0142a\u015bciwym organem krajowym.<\/p>\n\n\n\n DORA<\/a>, obejmuj\u0105ca instytucje finansowe i ich dostawc\u00f3w us\u0142ug ICT, jest szersza. Wymaga zawierania pisemnych um\u00f3w ze wszystkimi dostawcami ICT, zawieraj\u0105cych szczeg\u00f3\u0142owe postanowienia dotycz\u0105ce praw dost\u0119pu i audytu, wymog\u00f3w bezpiecze\u0144stwa informacji oraz ci\u0105g\u0142o\u015bci dzia\u0142ania. Nak\u0142ada ponadto obowi\u0105zek prowadzenia rejestr\u00f3w zale\u017cno\u015bci od podmiot\u00f3w ICT. Dla instytucji finansowych posiadaj\u0105cych dzia\u0142aj\u0105cy program TPRM w\u0142a\u015bciwym krokiem jest przeprowadzenie analizy luk pod k\u0105tem DORA, a nie budowanie nowego procesu od zera.<\/p>\n\n\n\n RODO wymaga, by ka\u017cdy dostawca przetwarzaj\u0105cy dane osobowe na zlecenie organizacji dzia\u0142a\u0142 w oparciu o umow\u0119 powierzenia przetwarzania spe\u0142niaj\u0105c\u0105 wymagania art. 28 rozporz\u0105dzenia. Administrator danych jest zobowi\u0105zany do weryfikacji podmiotu przetwarzaj\u0105cego przed powierzeniem mu jakichkolwiek danych.<\/p>\n\n\n\n ISO 27001<\/a> odnosi si\u0119 do relacji z dostawcami, wymagaj\u0105c polityki zarz\u0105dzania bezpiecze\u0144stwem informacji w tych relacjach oraz odpowiednich mechanizm\u00f3w nadzoru. ISO 22301<\/a> wymaga natomiast, by plany ci\u0105g\u0142o\u015bci dzia\u0142ania uwzgl\u0119dnia\u0142y rzeczywist\u0105 odporno\u015b\u0107 kluczowych dostawc\u00f3w na zak\u0142\u00f3cenia.<\/p>\n\n\n\n Dobrze zaprojektowany program TPRM mo\u017ce realizowa\u0107 wymagania wszystkich tych regulacji w ramach jednego zestawu proces\u00f3w. Utrzymywanie osobnych \u015bcie\u017cek dla ka\u017cdego regulatora to rozwi\u0105zanie kosztowne i trudne do obs\u0142ugi w d\u0142ugim terminie.<\/p>\n\n\n\n W przypadku dostawc\u00f3w wykorzystuj\u0105cych systemy AI organizacje powinny r\u00f3wnie\u017c uwzgl\u0119dnia\u0107 wymagania wynikaj\u0105ce z EU AI Act, w szczeg\u00f3lno\u015bci dotycz\u0105ce transparentno\u015bci, nadzoru oraz zarz\u0105dzania ryzykiem system\u00f3w wysokiego ryzyka. Rozporz\u0105dzenie obejmuje zar\u00f3wno dostawc\u00f3w system\u00f3w AI (providers), jak i podmioty wdra\u017caj\u0105ce je w swoich procesach (deployers), dlatego samo korzystanie z rozwi\u0105zania AI dostarczonego przez stron\u0119 trzeci\u0105 rodzi po stronie organizacji w\u0142asne obowi\u0105zki regulacyjne. W ramach due diligence takiego dostawcy nale\u017cy ustali\u0107, do kt\u00f3rej kategorii ryzyka kwalifikuje si\u0119 jego system, czy przeszed\u0142 wymagan\u0105 ocen\u0119 zgodno\u015bci oraz jak udokumentowany jest nadz\u00f3r cz\u0142owieka nad jego dzia\u0142aniem. Dla system\u00f3w wysokiego ryzyka konieczne s\u0105 dodatkowo: techniczna dokumentacja, rejestrowanie zdarze\u0144 i mechanizmy umo\u017cliwiaj\u0105ce realny audyt. Wymogi te musz\u0105 znale\u017a\u0107 odzwierciedlenie w klauzulach umownych z dostawc\u0105, w przeciwnym razie organizacja przejmuje jego ryzyko regulacyjne bez realnej mo\u017cliwo\u015bci kontroli.<\/p>\n\n\n\n Najcz\u0119\u015bciej pope\u0142niany b\u0142\u0105d w programach TRRM dotyczy zakresu stosowania programu. Organizacje buduj\u0105 proces weryfikacji dostawc\u00f3w, a nast\u0119pnie stosuj\u0105 go tylko do cz\u0119\u015bci swojej bazy kontraktowej. Dostawcy strategiczni s\u0105 oceniani starannie; dostawcy z d\u0142ugiego ogona um\u00f3w pozostaj\u0105 poza jakimkolwiek nadzorem. Ryzyko koncentruje si\u0119 tam, gdzie widoczno\u015b\u0107 jest najni\u017csza.<\/p>\n\n\n\n Drugim powtarzaj\u0105cym si\u0119 problemem jest traktowanie due diligence jako jednorazowej formalno\u015bci poprzedzaj\u0105cej podpisanie umowy. Dostawca, kt\u00f3ry przeszed\u0142 ocen\u0119 trzy lata temu, m\u00f3g\u0142 od tego czasu zmieni\u0107 w\u0142a\u015bciciela, platform\u0119 technologiczn\u0105 lub kadr\u0119 zarz\u0105dzaj\u0105c\u0105 odpowiedzialn\u0105 za bezpiecze\u0144stwo. \u017badna z tych zmian nie uruchomi automatycznie ponownej weryfikacji, je\u015bli program nie ma wbudowanego mechanizmu jej inicjowania.<\/p>\n\n\n\n Trzecim b\u0142\u0119dem jest nadmierne zaufanie do deklaracji zawartych w kwestionariuszach. Jako\u015b\u0107 tych odpowiedzi zale\u017cy od rzetelno\u015bci i kompetencji osoby je wype\u0142niaj\u0105cej. Dla dostawc\u00f3w o wysokiej krytyczno\u015bci ocena powinna opiera\u0107 si\u0119 na dowodach: raportach audytowych, wynikach test\u00f3w bezpiecze\u0144stwa, zakresie i aktualno\u015bci certyfikacji.<\/p>\n\n\n\n Czwarty problem jest organizacyjny: brak wyra\u017anego w\u0142a\u015bciciela procesu. TPRM le\u017cy na przeci\u0119ciu obszar\u00f3w odpowiedzialno\u015bci procurement, IT, bezpiecze\u0144stwa, prawa i zgodno\u015bci. Brak w\u0142a\u015bciciela procesu oznacza, \u017ce w\u0142a\u015bcicielem ryzyka mo\u017ce sta\u0107 si\u0119 przypadek. Skuteczna realizacja wymaga wyznaczonego w\u0142a\u015bciciela z realnym umocowaniem, aktywnego wk\u0142adu ka\u017cdej z zaanga\u017cowanych funkcji i sponsoringu na poziomie zarz\u0105du lub komitetu ryzyka.<\/p>\n\n\n\n Podsumowanie: NIS2, DORA, RODO czy normy ISO formalizuj\u0105 dzi\u015b podej\u015bcie, kt\u00f3re dojrza\u0142e programy TPRM stosuj\u0105 w praktyce od lat. Dlatego dla wi\u0119kszo\u015bci organizacji bardziej racjonalnym krokiem b\u0119dzie identyfikacja luk i usprawnienie istniej\u0105cych proces\u00f3w ni\u017c budowanie ca\u0142ego modelu od zera. O skuteczno\u015bci programu w praktyce decyduje przede wszystkim to, czy organizacja jasno okre\u015bli\u0142a w\u0142a\u015bciciela odpowiedzialnego za jego codzienne funkcjonowanie.<\/p>\n\n\n\n<\/figure>\n\n\n\nJak ocenia\u0107 ryzyko dostawcy i podmiot\u00f3w trzecich?<\/h2>\n\n\n\n
<\/figure>\n\n\n\nTPRM a wymogi regulacyjne (NIS2, DORA, RODO, ISO, EU AI Act)<\/h2>\n\n\n\n
Najcz\u0119stsze b\u0142\u0119dy w programach TPRM. Jak ich unika\u0107?<\/h2>\n\n\n\n
Zarz\u0105dzanie ryzykiem dostawc\u00f3w zaczyna dzia\u0142a\u0107 dopiero wtedy, gdy przestaje by\u0107 jednorazowym projektem porz\u0105dkuj\u0105cym, a staje si\u0119 sta\u0142ym elementem codziennego funkcjonowania organizacji. Pe\u0142ny cykl \u017cycia relacji z dostawc\u0105, segmentacja wed\u0142ug krytyczno\u015bci, due diligence oparte na dowodach oraz ci\u0105g\u0142y monitoring powinny tworzy\u0107 sp\u00f3jny mechanizm, w kt\u00f3rym poszczeg\u00f3lne elementy wzajemnie si\u0119 uzupe\u0142niaj\u0105 i wzmacniaj\u0105.<\/p>\n\n\n\n<\/figure>\n\n\n\nFAQ – Najcz\u0119\u015bciej zadawane pytania<\/h2>\n\n\n