⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Poza kwestionariuszem: kompletny przewodnik CISO po audytowaniu dostawców wysokiego ryzyka pod kątem NIS2 i DORA

Clarysec AI Editor
18 min read
Schemat przepływu procesu audytu dostawców wysokiego ryzyka, przedstawiający czteroetapowy cykl życia: od wstępnej oceny ryzyka i przeglądu umowy po ciągłe monitorowanie, audyty techniczne oraz przechowywanie dokumentacji regulacyjnej na potrzeby zgodności z NIS2 i DORA.

Raport trafił na biurko Marii Valen, CISO, z cichym odgłosem, który brzmiał bardziej jak syrena alarmowa. Była to wstępna ocena przed nadchodzącym przeglądem zgodności z DORA, a jeden wiersz oznaczono jaskrawoczerwoną adnotacją: „Niewystarczający poziom zapewnienia dla krytycznego dostawcy zewnętrznego, CloudSphere”.

CloudSphere nie był zwykłym dostawcą. Stanowił fundament nowej cyfrowej platformy bankowej spółki, przetwarzającej miliony transakcji dziennie. Maria miała w dokumentacji jego certyfikat ISO/IEC 27001:2022. Miała też wypełniony kwestionariusz bezpieczeństwa — obszerny dokument obejmujący 200 pytań. Jednak audytorzy prowadzący przegląd wstępny sygnalizowali, że w przypadku krytycznego dostawcy wysokiego ryzyka zgodność oparta na odhaczaniu pól nie wystarcza. Reguły gry się zmieniły.

Ponieważ dyrektywa NIS2 oraz rozporządzenie DORA (Digital Operational Resilience Act) obowiązują już w pełnym zakresie, organy regulacyjne wychodzą poza samą dokumentację. Wymagają konkretnych dowodów due diligence, ciągłego monitorowania oraz solidnego ładu nad całym łańcuchem dostaw. Wyzwanie Marii jest wyzwaniem CISO w każdej organizacji: jak wyjść poza kwestionariusz, aby faktycznie audytować i zabezpieczać najbardziej krytycznych dostawców? Wymaga to strategicznego przejścia od pasywnej walidacji do aktywnego zapewnienia opartego na dowodach.

Słabość statycznego kwestionariusza w dynamicznym świecie

Przez lata kwestionariusz bezpieczeństwa był podstawą zarządzania ryzykiem stron trzecich. Jest to jednak statyczny obraz w dynamicznym krajobrazie zagrożeń. Profil ryzyka dostawcy nie jest stały; zmienia się wraz z każdym nowym zagrożeniem, zmianą systemową lub nowym podwykonawcą włączonym do świadczenia usługi. Poleganie wyłącznie na samoocenie w przypadku krytycznego dostawcy takiego jak CloudSphere przypomina żeglowanie przez sztorm z zeszłoroczną mapą pogody.

Dyrektywa NIS2 jednoznacznie wymaga podejścia opartego na ryzyku, zgodnie z którym środki bezpieczeństwa muszą być proporcjonalne do rzeczywistych ryzyk. Oznacza to, że jeden uniwersalny kwestionariusz dla wszystkich dostawców jest zasadniczo niespójny z aktualnymi oczekiwaniami regulacyjnymi. Minęły czasy, w których certyfikat albo wypełniona lista kontrolna mogły zastąpić dowody. Rzeczywiste ryzyko znajduje się poza dokumentacją.

W tym miejscu niezbędne staje się uporządkowane podejście oparte na cyklu życia. Nie chodzi o rezygnację z kwestionariuszy, lecz o uzupełnienie ich głębszą i bardziej wnikliwą weryfikacją wobec dostawców, którzy naprawdę mają znaczenie. Jest to podstawowa zasada wpisana w Politykę bezpieczeństwa dostawców i stron trzecich Clarysec. Jednym z jej bazowych celów jest:

„Wymagać formalnego due diligence oraz udokumentowanych ocen ryzyka przed nawiązaniem współpracy z nowymi dostawcami lub odnowieniem umów o świadczenie usług wysokiego ryzyka”.

  • Z sekcji „Cele”, klauzula polityki 3.3

Ta klauzula zmienia sposób myślenia: z prostego sprawdzenia na formalne postępowanie weryfikacyjne. To kluczowy pierwszy krok w budowaniu programu, który można obronić podczas kontroli regulacyjnej.

Ryzyko dostawców w NIS2 i DORA: nowe oczekiwania

Zarówno NIS2, jak i DORA wymagają od organizacji systematycznej identyfikacji, oceny oraz ciągłego monitorowania ryzyk w całym krajobrazie dostawców. Przekształcają zarządzanie dostawcami z funkcji zakupowej w kluczowy filar odporności operacyjnej i bezpieczeństwa informacji.

Nowe otoczenie regulacyjne wymaga jasnych ram ściśle mapowanych do uznanych norm, takich jak ISO/IEC 27001:2022. Poniżej przedstawiono ogólne podsumowanie oczekiwań tych ram wobec programu nadzoru nad dostawcami:

WymaganieNIS2DORAŚrodki kontrolne ISO/IEC 27001:2022
Ocena ryzyka dostawcyArticle 21(2)(d)Articles 28–305.19, 5.21
Umowne klauzule bezpieczeństwaArticle 21(3), Article 22Article 305.20
Ciągłe monitorowanieArticle 21, Article 22Articles 30, 315.22
Zarządzanie podatnościami i reagowanie na incydentyArticle 23Article 9, 115.29, 8.8

Solidnego programu audytu dostawców nie trzeba tworzyć od podstaw. Ramy ISO/IEC 27001:2022, w szczególności środki kontrolne z Załącznika A, zapewniają skuteczny wzorzec. W Clarysec pomagamy klientom budować program wokół trzech powiązanych środków kontrolnych, które tworzą pełny cykl życia nadzoru nad dostawcami.

Budowanie możliwych do obrony ram audytu: cykl życia ISO 27001:2022

Aby zbudować program spełniający oczekiwania organów regulacyjnych, potrzebne jest uporządkowane podejście oparte na globalnie uznanej normie. Środki kontrolne bezpieczeństwa dostawców w ISO/IEC 27001:2022 zapewniają cykl życia zarządzania ryzykiem stron trzecich — od rozpoczęcia współpracy do jej zakończenia. Zobaczmy, jak Maria może wykorzystać ten cykl życia do zbudowania możliwego do obrony planu audytu CloudSphere.

Krok 1: Podstawa — bezpieczeństwo informacji w relacjach z dostawcami (5.19)

Środek kontrolny 5.19 jest strategicznym punktem wyjścia. Wymaga ustanowienia formalnych procesów identyfikacji, oceny i zarządzania ryzykami bezpieczeństwa informacji związanymi z całym ekosystemem dostawców. W tym miejscu organizacja definiuje, co oznacza „wysokie ryzyko”, oraz ustala zasady działania.

Zenith Controls: przewodnik po zgodności międzyregulacyjnej Clarysec zawiera szczegółowe omówienie 5.19, pokazując jego rolę jako centralnego punktu nadzoru nad dostawcami. Ten środek kontrolny jest nierozerwalnie powiązany z kontrolami pokrewnymi, takimi jak 5.21 (bezpieczeństwo informacji w łańcuchu dostaw ICT), obejmującą komponenty sprzętowe i programowe, oraz 5.14 (przekazywanie informacji), regulującą bezpieczną wymianę danych. Nie można skutecznie zarządzać relacją z dostawcą bez jednoczesnej kontroli technologii, którą dostarcza, oraz danych, które są mu udostępniane.

Dla Marii oznacza to, że audyt CloudSphere musi wyjść poza korporacyjny profil ryzyka bezpieczeństwa dostawcy i objąć bezpieczeństwo rzeczywistej platformy, którą dostarcza. Przewodnik Zenith Controls podkreśla, że mocne wdrożenie 5.19 bezpośrednio wspiera zgodność z kluczowymi regulacjami:

  • NIS2 (Article 21(2)(d)): zobowiązuje organizacje do zarządzania ryzykiem łańcucha dostaw jako podstawowym elementem ram bezpieczeństwa.
  • DORA (Articles 28–30): nakazuje stosowanie solidnych ram zarządzania ryzykiem ICT związanym z podmiotami trzecimi, w tym klasyfikacji krytyczności oraz przedumownego due diligence.
  • GDPR (Article 28): wymaga, aby administratorzy angażowali wyłącznie podmioty przetwarzające zapewniające wystarczające gwarancje ochrony danych.

Ten środek kontrolny wymaga poziomowania ryzyka dostawców, bieżącego monitorowania oraz terminowego cofnięcia dostępu. Jego celem jest zapewnienie, że bezpieczeństwo jest wbudowane w cykl życia dostawcy, a nie dodawane po fakcie.

Krok 2: Egzekwowanie — uwzględnianie bezpieczeństwa informacji w umowach z dostawcami (5.20)

Wymaganie bezpieczeństwa, którego nie ma w umowie, jest jedynie sugestią. Środek kontrolny 5.20 to moment, w którym ład staje się prawnie egzekwowalny. W przypadku dostawcy wysokiego ryzyka umowa jest najważniejszym narzędziem audytowym.

Jak podkreśla Zenith Controls, takie umowy muszą być jednoznaczne. Ogólne deklaracje o „najlepszym w branży bezpieczeństwie” są bezwartościowe. W przypadku dostawcy takiego jak CloudSphere Maria musi zweryfikować, czy umowa zawiera konkretne, mierzalne klauzule, które zapewniają jej organizacji realny nadzór:

  • Prawo do audytu: klauzula jednoznacznie przyznająca organizacji prawo do przeprowadzania ocen technicznych, przeglądu dowodów lub zaangażowania strony trzeciej do przeprowadzenia audytu w jej imieniu.
  • Terminy zgłoszenia naruszenia: konkretne, rygorystyczne terminy, np. w ciągu 24 godzin od wykrycia, na powiadomienie organizacji o incydencie bezpieczeństwa, a nie ogólne sformułowanie „bez zbędnej zwłoki”.
  • Zarządzanie podwykonawcami i ryzykiem czwartej strony: klauzula wymagająca od dostawcy egzekwowania tych samych standardów bezpieczeństwa wobec własnych krytycznych podwykonawców oraz informowania organizacji o wszelkich zmianach. Ma to kluczowe znaczenie dla zarządzania ryzykiem dalszych podmiotów w łańcuchu dostaw.
  • Bezpieczna strategia wyjścia: jasne obowiązki dotyczące zwrotu danych lub ich certyfikowanego zniszczenia po zakończeniu umowy.

DORA jest w tym zakresie szczególnie preskryptywna. Article 30 określa obowiązkowe postanowienia umowne, w tym nieograniczony dostęp dla audytorów i organów regulacyjnych, szczegółowe informacje o lokalizacjach świadczenia usług oraz kompleksowe strategie wyjścia. Audytorzy będą dobierać próbki umów z dostawcami wysokiego ryzyka i bezpośrednio weryfikować obecność tych klauzul.

Krok 3: Ciągła pętla — monitorowanie, przegląd i zarządzanie zmianami w usługach dostawców (5.22)

Ostatnim elementem cyklu życia jest środek kontrolny 5.22, który przekształca nadzór nad dostawcami z jednorazowego sprawdzenia w proces ciągły. Audyt nie powinien być zdarzeniem zaskakującym, lecz punktem walidacji w ramach trwającej, transparentnej relacji.

W tym miejscu wiele organizacji ma największe braki. Podpisują umowę i odkładają ją do akt. Tymczasem w przypadku dostawców wysokiego ryzyka właściwa praca zaczyna się po onboardingu. Przewodnik Zenith Controls łączy 5.22 z krytycznymi procesami operacyjnymi, takimi jak 8.8 (zarządzanie podatnościami technicznymi) oraz 5.29 (bezpieczeństwo informacji podczas zakłóceń). Oznacza to, że skuteczne monitorowanie obejmuje znacznie więcej niż coroczne spotkanie przeglądowe. Obejmuje ono:

  • Przegląd dowodów strony trzeciej: aktywne pozyskiwanie i analizę raportów SOC 2 Type II, wyników audytów nadzoru ISO 27001 lub podsumowań testów penetracyjnych. Kluczowe jest przejrzenie wyjątków oraz śledzenie ich remediacji.
  • Monitorowanie incydentów: śledzenie publicznie ujawnionych naruszeń lub incydentów bezpieczeństwa dotyczących dostawcy oraz formalna ocena potencjalnego wpływu na organizację.
  • Zarządzanie zmianą: wdrożenie procesu, w którym każda istotna zmiana w usłudze dostawcy, taka jak nowa lokalizacja centrum danych lub nowy krytyczny podwykonawca, automatycznie uruchamia ponowną ocenę ryzyka.

Zenith Blueprint: 30-krokowa mapa drogowa audytora Clarysec zawiera praktyczne wskazówki w tym zakresie, szczególnie w kroku 24, który dotyczy ryzyka podwykonawców. Zaleca on:

„Dla każdego dostawcy krytycznego należy ustalić, czy korzysta z podwykonawców lub podwykonawców przetwarzania, którzy mogą mieć dostęp do danych lub systemów organizacji. Należy udokumentować, w jaki sposób wymagania bezpieczeństwa informacji organizacji są przekazywane tym podmiotom… O ile to możliwe, należy zażądać listy kluczowych podwykonawców oraz upewnić się, że prawo do audytu lub uzyskania zapewnienia obejmuje również ich”.

To kluczowy punkt dla Marii. Czy CloudSphere korzysta z zewnętrznej firmy analityki danych? Czy jego infrastruktura jest hostowana w dużej chmurze publicznej? Te dalsze zależności stanowią istotne, często niewidoczne ryzyko, które jej audyt musi ujawnić.

Od teorii do działania: praktyczny plan audytu CloudSphere przygotowany przez Marię

Korzystając z cyklu życia ISO 27001:2022, zespół Marii opracowuje nowy plan audytu CloudSphere, który wykracza daleko poza kwestionariusz i wykazuje dojrzały, oparty na ryzyku ład wymagany przez organy regulacyjne.

  1. Przegląd umowy: zespół zaczyna od zmapowania istniejącej umowy z CloudSphere względem DORA Article 30 oraz najlepszych praktyk dla środka kontrolnego 5.20. Tworzy raport analizy luk, który ma wesprzeć następny cykl odnowienia umowy oraz ustalenie priorytetów bieżącego audytu.

  2. Ukierunkowany wniosek o dowody: zamiast ogólnego kwestionariusza wysyła formalny wniosek o konkretne dowody, w tym:

    • najnowszy raport SOC 2 Type II oraz podsumowanie sposobu remediacji wszystkich wskazanych wyjątków;
    • podsumowanie dla kierownictwa z najnowszego zewnętrznego testu penetracyjnego;
    • pełną listę wszystkich podwykonawców i stron czwartych, które będą przetwarzać dane organizacji lub uzyskiwać do nich dostęp;
    • dowód, że wymagania bezpieczeństwa zostały umownie przeniesione na tych podwykonawców;
    • logi lub raporty wykazujące terminowe wdrażanie poprawek dla podatności krytycznych, np. Log4j i MOVEit, w ciągu ostatnich sześciu miesięcy.
  3. Walidacja techniczna: zespół powołuje się na klauzulę „prawa do audytu”, aby zaplanować techniczną sesję pogłębioną z zespołem bezpieczeństwa CloudSphere. Agenda koncentruje się na podręcznikach reagowania na incydenty, narzędziach Cloud Security Posture Management (CSPM) oraz kontrolach zapobiegania wyciekom danych.

  4. Formalne zarządzanie wyjątkami: jeżeli CloudSphere odmówi przekazania określonych dowodów, Maria jest przygotowana. Proces ładu jej organizacji, zdefiniowany w Polityce bezpieczeństwa dostawców i stron trzecich, jest jednoznaczny:

„Wyjątki wysokiego ryzyka, np. dostawcy przetwarzający dane regulowane lub wspierający systemy krytyczne, muszą zostać zatwierdzone przez CISO, dział prawny i kierownictwo zakupów oraz wpisane do Rejestru odstępstw SZBI”.

  • Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.3

Dzięki temu każda odmowa przekazania dowodów nie jest po prostu ignorowana, lecz formalnie akceptowana jako ryzyko na najwyższych szczeblach organizacji — jest to proces respektowany przez audytorów.

Perspektywa audytora: czego będą wymagać różni audytorzy

Aby zbudować naprawdę odporny program, należy myśleć jak audytor. Różne ramy audytowe stosują różne perspektywy, a przewidywanie pytań audytorów jest kluczowe dla powodzenia. Poniżej przedstawiono skonsolidowany obraz tego, czego różni audytorzy będą wymagać podczas przeglądu programu nadzoru nad dostawcami:

Profil audytoraKluczowy obszar zainteresowania i środki kontrolneDowody, których będzie wymagać
Audytor ISO/IEC 27001:20225.19, 5.20, 5.22Inwentarz dostawców z klasyfikacją ryzyka; wybrane próbki umów dla dostawców wysokiego ryzyka w celu weryfikacji klauzul bezpieczeństwa; zapisy due diligence i cyklicznych spotkań przeglądowych.
Audytor COBIT 2019APO10 (Manage Suppliers), DSS04 (Manage Continuity)Dowody bieżącego monitorowania wyników względem SLA; dokumentacja sposobu obsługi incydentów związanych z dostawcami; zapisy przeglądów ryzyka dostawców i zarządzania zmianami.
DORA / organ nadzoru finansowegoArticles 28-30Umowa z krytycznym dostawcą ICT zmapowana do obowiązkowych klauzul DORA; ocena ryzyka koncentracji; dowody testowania lub przeglądu strategii wyjścia.
Audytor NIST SP 800-53SA-9 (External System Services), rodzina SR (Supply Chain)Dowód istnienia planu zarządzania ryzykiem łańcucha dostaw; zapisy dowodów zgodności dostawcy, np. FedRAMP, SOC 2; dokumentacja widoczności ryzyka czwartej strony.
ISACA / audytor ITITAF Performance Standard 2402Logi potwierdzające, że dostęp personelu dostawcy po zakończeniu współpracy został niezwłocznie cofnięty; dowody posiadania unikalnych kont chronionych MFA dla dostępu stron trzecich; zapisy reagowania na incydenty.

Ta wieloperspektywiczna analiza pokazuje, że solidny program nie polega na spełnieniu jednej normy, lecz na zbudowaniu całościowych ram ładu, które generują dowody potrzebne do spełnienia ich wszystkich.

Krytyczne pułapki: gdzie audyty dostawców zawodzą

Wiele programów nadzoru nad dostawcami nie spełnia oczekiwań z powodu typowych, możliwych do uniknięcia błędów. Należy szczególnie uważać na następujące krytyczne pułapki:

  • Audyt jako zdarzenie: poleganie na jednorazowych audytach podczas onboardingu lub odnowienia umowy zamiast wdrożenia ciągłego monitorowania.
  • Samozadowolenie certyfikacyjne: przyjmowanie certyfikatu ISO lub SOC 2 bez analizy szczegółów raportu, zakresu i wyjątków.
  • Nieprecyzyjne umowy: brak jednoznacznych, egzekwowalnych klauzul dotyczących prawa do audytu, zgłaszania naruszeń i postępowania z danymi.
  • Słabe zarządzanie inwentarzem: brak możliwości przedstawienia kompletnego, poziomowanego według ryzyka inwentarza wszystkich dostawców oraz danych, do których mają dostęp.
  • Ignorowanie ryzyka dalszych podmiotów: brak identyfikacji i zarządzania ryzykami powodowanymi przez krytycznych podwykonawców dostawcy, czyli ryzykiem czwartej strony.
  • Niezweryfikowane zarządzanie podatnościami: zaufanie, że dostawca wdraża poprawki dla podatności krytycznych, bez żądania dowodów.

Praktyczna lista kontrolna audytu dostawców wysokiego ryzyka

Skorzystaj z tej listy kontrolnej, zaadaptowanej z Zenith Blueprint, aby zapewnić, że proces audytu każdego dostawcy wysokiego ryzyka jest kompletny i możliwy do obrony.

KrokDziałanieDowody do zebrania i przechowywania
Due diligencePrzeprowadzić i udokumentować formalną ocenę ryzyka przed onboardingiem lub odnowieniem umowy.Wypełniony arkusz ryzyka dostawcy; zapis klasyfikacji; raport due diligence.
Przegląd umowyZweryfikować, czy klauzule bezpieczeństwa, prywatności i audytu są obecne oraz egzekwowalne.Podpisana umowa z wyróżnionymi klauzulami; akceptacja przeglądu prawnego; umowa powierzenia przetwarzania danych.
Bieżące monitorowanieZaplanować i przeprowadzać kwartalne lub roczne przeglądy na podstawie poziomu ryzyka.Protokoły ze spotkań; przejrzane raporty SOC 2 / ISO 27001; podsumowania skanów podatności.
Nadzór nad podwykonawcamiZidentyfikować i udokumentować wszystkich krytycznych dostawców dalszego szczebla, czyli strony czwarte.Lista podwykonawców przetwarzania przekazana przez dostawcę; dowody klauzul przenoszących wymagania bezpieczeństwa.
Zarządzanie podatnościamiWymagać dowodów dojrzałego programu zarządzania podatnościami.Aktualne podsumowanie dla kierownictwa z testu penetracyjnego; przykładowe raporty ze skanów podatności; harmonogramy wdrażania poprawek.
Zgłaszanie incydentówPrzetestować i zwalidować proces powiadamiania o incydentach przez dostawcę.Zapisy wcześniejszych powiadomień o incydentach; udokumentowane SLA zgłaszania naruszeń.
Zarządzanie zmianamiPrzeglądać wszystkie istotne zmiany techniczne lub organizacyjne po stronie dostawcy.Dzienniki zmian dostawcy; raporty ponownej oceny ryzyka uruchomionej przez zmiany.
Mapowanie regulacyjneMapować wdrożone środki kontrolne bezpośrednio do wymagań NIS2, DORA i GDPR.Wewnętrzna tabela mapowania zgodności; rejestr dowodów dla organów regulacyjnych.

Podsumowanie: budowanie odpornego i możliwego do obrony łańcucha dostaw

Era zgodności opartej na odhaczaniu pól w przypadku dostawców krytycznych dobiegła końca. Intensywna kontrola wynikająca z regulacji takich jak NIS2 i DORA wymaga zasadniczego przejścia do modelu ciągłego zapewnienia opartego na dowodach. CISO, tacy jak Maria, muszą przewodzić tej zmianie i wyprowadzać swoje organizacje poza statyczny kwestionariusz.

Budując program na sprawdzonym cyklu życia środków kontrolnych ISO/IEC 27001:2022, organizacja tworzy ramy, które nie tylko wspierają zgodność, ale także realnie ograniczają ryzyko. Obejmuje to traktowanie bezpieczeństwa dostawców jako dyscypliny strategicznej, wpisywanie egzekwowalnych wymagań do umów oraz utrzymywanie czujnego nadzoru przez cały okres relacji.

Bezpieczeństwo organizacji jest tak silne, jak jej najsłabsze ogniwo, a w dzisiejszym połączonym ekosystemie ogniwo to często znajduje się po stronie podmiotu trzeciego. Czas odzyskać kontrolę.

Gotowi wyjść poza kwestionariusz?

Zintegrowane zestawy narzędzi Clarysec zapewniają podstawę do zbudowania światowej klasy programu zarządzania ryzykiem dostawców, który wytrzyma każdy audyt.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Od zgodności do odporności: jak CISO mogą domknąć lukę w nadzorze zarządczym

Od zgodności do odporności: jak CISO mogą domknąć lukę w nadzorze zarządczym

Listy kontrolne zgodności nie zapobiegają naruszeniom; robi to aktywny nadzór zarządczy. Omawiamy największe mity CISO dotyczące zarządzania na przykładzie rzeczywistego incydentu i przedstawiamy mapę drogową budowania rzeczywistej odporności organizacji: z konkretnymi działaniami, przykładami polityk oraz mapowaniami zgodności między ISO 27001:2022, NIS2, DORA i innymi ramami.