Wszystkie przewodniki

Przewodnik · 9 min czytania

NIS2 Art. 21(2) — lista kontrolna bezpieczeństwa dla dostawców

Praktyczna lista kontrolna dla zespołów ds. zamówień i bezpieczeństwa. Używaj jej zarówno przy wdrażaniu nowych dostawców, jak i przy corocznych przeglądach — co pytać, jakie dowody zbierać i jak reagować, gdy dostawca nie spełnia wymagań.

NIS2 art. 21 ust. 2 lit. d) zobowiązuje do oceny postawy cyberbezpieczeństwa dostawców w ramach własnego zarządzania ryzykiem łańcucha dostaw. Wymóg dotyczy zarówno nowych dostawców, jak i istniejących relacji — coroczny przegląd jest minimum.

Lista kontrolna obejmuje sześć podpunktów art. 21 ust. 2 najbardziej istotnych dla bezpieczeństwa łańcucha dostaw. Każda sekcja zawiera trzy pytania, krótkie wyjaśnienie znaczenia oraz sugerowany dokument dowodowy.

Uwaga: Lista kontrolna ma charakter orientacyjny — właściwy organ lub audytor może wymagać dodatkowych środków w zależności od sektora lub wielkości organizacji. W kwestiach wymagań umownych należy skonsultować się z prawnikiem.

Art. 21(2)(a)Zarządzanie ryzykiem

NIS2 wymaga, aby Twoi dostawcy zarządzali ryzykami cyberbezpieczeństwa systematycznie — nie tylko raz w roku, ale w sposób ciągły. Żądaj dowodów na istnienie procesu, a nie tylko odpowiedzi tak/nie.

  • Dostawca posiada udokumentowany proces zarządzania ryzykiem cyberbezpieczeństwa (np. ISMS lub certyfikat ISO 27001)
  • Zarządzanie ryzykiem jest regularnie przeglądane przez kierownictwo wyższego szczebla lub zarząd — data ostatniego przeglądu jest znana
  • Krytyczne systemy informatyczne i obowiązki w zakresie przetwarzania danych są zinwentaryzowane i sklasyfikowane

Sugerowane dokumenty dowodowe:

  • · Polityka zarządzania ryzykiem lub dokumentacja ISMS
  • · Certyfikat ISO 27001 lub równoważny raport z audytu

Art. 21(2)(b)Obsługa incydentów

NIS2 art. 23 wymaga, aby znaczące incydenty były zgłaszane organowi nadzoru w ciągu 24 godzin. W praktyce jest to możliwe tylko wtedy, gdy dostawca powiadamia Cię niezwłocznie — dlatego obowiązek powiadomienia powinien być zapisany w umowie.

  • Dostawca posiada udokumentowany proces reagowania na incydenty z przetestowanym planem IR
  • Dostawca zobowiązuje się umownie do powiadomienia w ciągu 24 godzin od wykrycia znaczącego incydentu
  • Wyznaczony kontakt ds. incydentów (łącznik CSIRT) jest mianowany i osiągalny całą dobę

Sugerowane dokumenty dowodowe:

  • · Streszczenie planu reagowania na incydenty
  • · Pisemne zobowiązanie do powiadomienia w ciągu 24 godzin w umowie

Art. 21(2)(d)Łańcuch dostaw

NIS2 rozciąga się na dostawców Twoich dostawców — tzw. ryzyko czwartej strony. Musisz wiedzieć, kto uzyskuje dostęp do Twoich danych lub systemów, nawet pośrednio przez podwykonawców.

  • Dostawca zna swoich krytycznych podwykonawców mających dostęp do danych lub systemów
  • Dostawca posiada proces oceny bezpieczeństwa własnych podwykonawców co najmniej raz w roku
  • Wymagania bezpieczeństwa są zapisane w własnych umowach dostawcy — nie tylko ogólne odwołanie

Sugerowane dokumenty dowodowe:

  • · Rejestr podwykonawców lub zestawienie krytycznych 4. stron
  • · Opis procesu oceny 4. stron

Art. 21(2)(e)Zamówienia i rozwój

Znane podatności i oprogramowanie w końcu życia należą do najczęstszych wektorów ataków. Dostawca musi wykazać aktywne zarządzanie podatnościami.

  • W środowisku produkcyjnym nie jest uruchomione oprogramowanie w końcu życia lub końcu wsparcia
  • Krytyczne podatności (CVSS ≥ 9,0) są łatane w ciągu 30 dni od publicznego ujawnienia
  • Podatności wymienione na liście CISA KEV są remediated w ciągu 48 godzin od dodania do listy

Sugerowane dokumenty dowodowe:

  • · Opis procesu zarządzania podatnościami
  • · Najnowszy raport patchy lub migawka stanu podatności

Art. 21(2)(h)Kryptografia

Wygasłe certyfikaty TLS, brakujące przekierowania HTTPS i nieprawidłowo skonfigurowane zabezpieczenia poczty e-mail to luki techniczne, które norppa.io sprawdza automatycznie każdego dnia.

  • Wszystkie publiczne usługi używają ważnego, niewygasłego certyfikatu TLS — bez certyfikatów samo-podpisanych lub wygasłych
  • Przekierowanie HTTPS jest wymuszone we wszystkich właściwościach sieciowych i punktach końcowych API
  • Zabezpieczenia poczty e-mail są prawidłowo skonfigurowane: SPF (hardfail), DKIM (podpisany) i DMARC (co najmniej polityka kwarantanny)

Sugerowane dokumenty dowodowe:

  • · Opis procesu zarządzania certyfikatami TLS
  • · Raport DMARC lub wydruk konfiguracji DNS

Art. 21(2)(i)Kontrola dostępu

Skradzione dane uwierzytelniające są najczęstszym punktem wyjścia cyberataków. Dostawca musi wykazać zarówno zapobieganie nadużyciom danych uwierzytelniających, jak i szybkie wykrywanie.

  • MFA jest wymuszony na wszystkich krytycznych systemach i kontach administratora — bez wyjątków
  • Monitorowanie wycieków danych uwierzytelniających jest wdrożone (źródła dark web, HIBP lub równoważna usługa)
  • Skompromitowane dane uwierzytelniające są natychmiast rotowane po wykryciu, a incydent jest dokumentowany

Sugerowane dokumenty dowodowe:

  • · Zrzut ekranu konfiguracji wymuszania MFA lub polityka
  • · Dostawca monitorowania wycieków danych uwierzytelniających lub opis procesu

Co zrobić, gdy dostawca nie spełnia wymagań listy kontrolnej?

Jedna luka nie oznacza automatycznie zakończenia relacji z dostawcą. Ważne jest systematyczne reagowanie i dokumentowanie podjętych kroków.

1–2 luki: udokumentować i zaakceptować

Zarejestruj luki w rejestrze dostawców, poproś dostawcę o przedstawienie planu naprawczego w ciągu 90 dni i przeprowadź kontrolę przy następnym corocznym przeglądzie.

3–5 luk lub luka w art. 21(2)(b): wzmocnione monitorowanie

Przenieś dostawcę na wyższy poziom ryzyka. Zażądaj pisemnego planu naprawczego z terminami. Rozważ ograniczenie dostępu do najbardziej krytycznych systemów do czasu usunięcia luk.

6+ luk lub krytyczna podatność techniczna: eskalacja

Eskaluj do CISO lub kierownictwa wyższego szczebla. Oceń wykorzystanie środków umownych. Jeśli dostawca ma dostęp do danych produkcyjnych lub systemów, rozważ zawieszenie dostępu do czasu rozwiązania sytuacji.

Które elementy mogą być zautomatyzowane?

Sześć elementów tej listy kontrolnej ma charakter techniczny — zmieniają się w czasie bez konieczności informowania przez dostawcę. Ręczna coroczna ocena raczej nie spełnia standardu 'odpowiednich środków' NIS2 dotyczącego ciągłego monitorowania.

norppa.io sprawdza te elementy automatycznie każdego dnia dla wszystkich Twoich dostawców:

  • Art. 21(2)(h): ważność certyfikatów TLS i przekierowania HTTPS, konfiguracja SPF/DKIM/DMARC, DNSSEC
  • Art. 21(2)(i): wycieki danych uwierzytelniających ze źródeł dark web i baz danych naruszeń HIBP
  • Art. 21(2)(e): monitorowanie list CISA KEV, wyniki podatności oparte na punktacji CVE/EPSS
  • Art. 21(2)(b): listy ofiar ransomware — natychmiastowy alert, jeśli dostawca pojawi się na liście

Elementy na poziomie procesu (art. 21(2)(a), (b), (d)) są objęte kwestionariuszem samooceny SAQ norppa.io, który można wysłać do dostawców bezpośrednio z portalu.

Automatyzuj kontrole techniczne z norppa.io

norppa.io automatycznie sprawdza techniczne elementy tej listy kontrolnej każdego dnia — dla wszystkich Twoich dostawców jednocześnie. Wyniki są automatycznie mapowane na podpunkty NIS2 art. 21(2).

Powiązane przewodniki