NIS2 a dostawcy oprogramowania: jakich testów zażąda od Was klient objęty KSC

NIS2 a dostawcy oprogramowania to temat, który jeszcze rok temu wydawał się sprawą działów bezpieczeństwa w energetyce i szpitalach. Od 3 kwietnia 2026 roku obowiązuje nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa i ten temat przychodzi do Was mailem, zwykle jako ankieta oceny dostawcy albo aneks do umowy. Wasz klient z sektora objętego ustawą ma teraz obowiązek ocenić podatności i ogólną jakość oprogramowania, które od Was kupuje, a jego zarząd odpowiada za to osobiście. Ten artykuł pokazuje, czego dokładnie wymaga przepis, jakie pytania padną w ankiecie, jakie dowody testów warto mieć przygotowane i od czego zacząć, zanim klient sam zacznie wyznaczać Wam terminy.

Co zmieniło się 3 kwietnia 2026 roku

Ustawa z 23 stycznia 2026 roku o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, opublikowana w Dzienniku Ustaw z 2026 roku pod pozycją 252, przeniosła do polskiego prawa dyrektywę NIS2. Według Bazy wiedzy na gov.pl nowelizacja weszła w życie 3 kwietnia 2026 roku, a podmioty kluczowe i ważne mają trzy twarde terminy: do 3 października 2026 roku wniosek o wpis do wykazu, do 3 kwietnia 2027 roku działający system zarządzania bezpieczeństwem informacji, a do 3 kwietnia 2028 roku pierwszy audyt, powtarzany potem co najmniej raz na trzy lata.

Ważniejsze od dat jest to, kogo nowelizacja dotyczy. Katalog sektorów urósł o między innymi zarządzanie usługami ICT, komunikację elektroniczną, usługi pocztowe, produkcję, odprowadzanie ścieków i gospodarkę odpadami. Jeśli tworzycie oprogramowanie dla energetyki, ochrony zdrowia, transportu, poczty, wodociągów albo administracji, Wasz klient najpewniej właśnie przechodzi przez ten proces, a Wy jesteście w jego łańcuchu dostaw. Część dostawców usług IT trafia do reżimu wprost, jako podmiot z sektora zarządzania usługami ICT. Ocenę własnego statusu zostawcie prawnikom, bo podmiot ocenia go sam i sam składa wniosek. Ten artykuł zajmuje się drugą, częstszą sytuacją: nie podlegacie ustawie wprost, ale Wasz klient tak.

NIS2 a dostawcy oprogramowania: co dokładnie mówi przepis

Kluczowy jest nowy art. 8 ustawy. Podmiot kluczowy albo ważny wdraża system zarządzania bezpieczeństwem informacji, który ma zapewnić między innymi trzy rzeczy ważne dla Was jako dostawcy. Pierwsza to bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemu, „w tym testowanie systemu informacyjnego” (art. 8 ust. 1 pkt 2 lit. b). Druga to bezpieczeństwo i ciągłość łańcucha dostaw produktów, usług i procesów ICT, z uwzględnieniem związków z bezpośrednim dostawcą sprzętu lub oprogramowania (lit. e). Trzecia to polityki i procedury oceny skuteczności środków technicznych i organizacyjnych (lit. h).

Dla dostawcy najważniejszy jest jednak art. 8 ust. 2. Wdrażając środki dotyczące łańcucha dostaw, klient uwzględnia podatności związane z dostawcą sprzętu lub oprogramowania oraz ogólną jakość jego produktów i procesów ICT. Przepis nie mówi „zbierz od dostawcy oświadczenie”. Mówi „oceń jakość jego produktów i procesów”. Z naszego doświadczenia w projektach dla sektora regulowanego wynika, że taka ocena prawie zawsze kończy się prośbą o dowody: raport z testów penetracyjnych, opis procesu obsługi podatności i informację, jak często testujecie bezpieczeństwo przy wydaniach.

Warto zauważyć, czego przepis nie robi. Nie nakłada na dostawcę jednego wzoru testów, nie wymienia normy ani częstotliwości. To klient przekłada ogólny obowiązek na konkretne wymagania w umowie, ankiecie albo regulaminie zakupów. Dlatego dwóch klientów z tego samego sektora może zapytać Was o zupełnie różne rzeczy, i to jest normalne.

Dlaczego zarząd klienta nie odpuści

Nowelizacja przeniosła odpowiedzialność na sam szczyt organizacji. Według art. 8c kierownik podmiotu kluczowego albo ważnego odpowiada za wykonanie obowiązków z zakresu cyberbezpieczeństwa także wtedy, gdy powierzył je innej osobie. Art. 8e dokłada coroczne, udokumentowane szkolenie dla kierownika. A art. 73a pozwala ukarać samego kierownika karą do 300 procent jego wynagrodzenia, liczonego jak ekwiwalent za urlop.

Kary dla samych organizacji też są poważne. Zgodnie z nowym brzmieniem art. 73 ustawy o KSC kara dla podmiotu kluczowego może sięgnąć 10 milionów euro albo 2 procent przychodów, w zależności od tego, która kwota jest wyższa, a dla podmiotu ważnego 7 milionów euro albo 1,4 procent przychodów. Członek zarządu, który ryzykuje własną pensję, nie przyjmie od dostawcy odpowiedzi „u nas wszystko jest bezpieczne”. Poprosi o papier.

Za tymi przepisami stoją twarde dane o tym, skąd przychodzą ataki. Verizon w raporcie Data Breach Investigations Report 2025, opartym na analizie ponad 22 tysięcy incydentów i 12 195 potwierdzonych naruszeń, podał, że odsetek naruszeń z udziałem strony trzeciej podwoił się do 30 procent. Ten sam raport pokazuje, że wykorzystanie podatności odpowiada już za 20 procent naruszeń jako pierwszy wektor ataku, po wzroście o 34 procent. W Polsce skala też rośnie: według raportu rocznego CERT Polska za 2025 rok zespół zarejestrował 260 783 unikalne incydenty, o 152 procent więcej niż rok wcześniej. Innymi słowy: klient nie wymyśla tych pytań z nudów, tylko odpowiada na realny wektor ataku, którym coraz częściej jest dostawca.

Jakie pytania padną w ankiecie oceny dostawcy

Ten sam raport ENISA mówi, jak organizacje objęte NIS2 sprawdzają dostawców. 90 procent wdrożyło konkretne środki wobec łańcucha dostaw, a najczęstsze z nich to wymóg zgodności ze standardami i certyfikatów (63 procent), ocena ryzyka albo audyt dostawcy (54 procent) oraz wymagania cyberbezpieczeństwa wpisane do umów (48 procent). Z naszej praktyki z klientami z energetyki, sektora publicznego i finansów wynika, że ankieta oceny dostawcy oprogramowania najczęściej sprowadza się do pięciu pytań. Poniżej zestawiamy je z dowodem, który na nie odpowiada.

Zwróćcie uwagę na ostatni wiersz. Raport przygotowany przez zespół, który sam napisał kod, ma dla klienta mniejszą wagę niż wynik strony zewnętrznej. To ten sam mechanizm, który w bankach od dawna wymusza rozporządzenie DORA i który opisaliśmy w artykule rozporządzenie DORA a testy niezależne. NIS2 tego wprost nie wymaga, ale klient, który ma ocenić jakość Waszych procesów, intuicyjnie zaufa bardziej raportowi niezależnemu.

Pięć dowodów, które warto mieć przed pierwszą ankietą

Najgorszy moment na pierwszy pentest to tydzień przed terminem odpowiedzi na ankietę. Widzimy to regularnie: firma dostaje pytania, zamawia test w trybie pilnym, test znajduje kilka poważnych problemów i nagle trzeba je naprawić, przetestować regresję i zrobić retest w czasie, który był przeznaczony na samą odpowiedź. Spokojniej jest przygotować pięć dowodów z wyprzedzeniem.

1. Raport z testów penetracyjnych aplikacji i API. To podstawa każdej odpowiedzi. Tester myślący jak atakujący sprawdza uwierzytelnianie, role i uprawnienia, sesje, walidację danych i ekspozycję danych w API. Różnice między skanem, pentestem i audytem opisujemy w przewodniku testy bezpieczeństwa i testy penetracyjne, a zakres usługi na stronie testów bezpieczeństwa aplikacji.

2. Wynik retestu. Klient objęty KSC nie potrzebuje listy problemów. Potrzebuje potwierdzenia, że zostały zamknięte. Retest po poprawkach zamienia raport z listy zarzutów w dowód, że proces działa.

3. Automatyczne testy bezpieczeństwa w pipeline. Skaner, na przykład OWASP ZAP, uruchamiany przy każdym wydaniu z progiem, który zatrzymuje wdrożenie przy nowej podatności wysokiej wagi. Raz w roku pentest pokazuje stan w jednym dniu, a testy w CI dopisują dowody przy każdym wydaniu. Jak połączyć jedno z drugim, pokazujemy w artykule o testowaniu bezpieczeństwa manualnym i automatycznym, a zespół możecie przygotować na szkoleniu automatyczne testy bezpieczeństwa z OWASP ZAP.

4. Testy regresji poprawek bezpieczeństwa. Poprawka luki potrafi zepsuć logowanie, płatność albo import danych. W naszych projektach to jeden z najczęstszych powodów, dla których łatka bezpieczeństwa wraca do zespołu jako nowy błąd produkcyjny. Scenariusze regresji dla obszarów, których dotyka poprawka, chronią przed tym i są kolejnym dowodem dojrzałości procesu.

5. Przeszkolony zespół. Ankiety coraz częściej pytają, czy programiści i testerzy znają podstawy bezpiecznego wytwarzania. Prowadziliśmy na przykład dwudniowe szkolenie z testów bezpieczeństwa dla 14 osób z zespołu AgroApp, a otwarte szkolenie Cybersecurity: testy bezpieczeństwa jest dostępne w kalendarzu. Kierownikom podmiotów objętych ustawą dedykujemy osobne szkolenie Cyberbezpieczeństwo dla kadry kierowniczej: obowiązki z KSC i NIS2, które odpowiada na wymóg corocznego szkolenia z art. 8e.

Czego nie obiecywać klientowi

Pod presją terminu łatwo napisać w odpowiedzi na ankietę zdanie, które potem wraca jak bumerang. Najczęstsze to „nasze oprogramowanie jest zgodne z NIS2”. Problem w tym, że zgodność z ustawą dotyczy systemu zarządzania bezpieczeństwem informacji u podmiotu objętego ustawą, a nie pojedynczego produktu. Deklaracja „jesteśmy zgodni z NIS2” brzmi trochę jak „nasz samochód jest zgodny z kodeksem drogowym”: miło to słyszeć, ale policjant i tak poprosi o prawo jazdy i przegląd.

Bezpieczniej pisać o faktach: kiedy i w jakim zakresie testowaliście aplikację, co znaleziono, co naprawiono i jak to potwierdzono, jak wygląda proces obsługi podatności i jak często go uruchamiacie. Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „Klient objęty KSC nie kupuje od Was zapewnienia, tylko dowód. Raport z testów i retestu zamyka rozmowę szybciej niż najładniej napisany paragraf w umowie.” To samo dotyczy uczciwości wyniku: jeśli pentest nie znalazł nic istotnego, to też jest dobra informacja dla klienta, tylko trzeba ją podać z zakresem i datą.

Kalendarz dla dostawcy do 2028 roku

Terminy ustawy dotyczą Waszego klienta, ale przekładają się na Wasz kalendarz z kilkumiesięcznym wyprzedzeniem. Poniżej zestawienie, jak to zwykle wygląda z perspektywy dostawcy.

Jeśli Wasz produkt jest też sprzedawany jako produkt z elementami cyfrowymi na rynku Unii, dochodzi jeszcze Cyber Resilience Act z obowiązkiem zgłaszania aktywnie wykorzystywanych podatności. Ten wątek rozbieramy w artykule Cyber Resilience Act: testowanie podatności przez cały cykl życia produktu, a pełny przegląd regulacji, pod które robimy testy, znajdziecie na stronie zgodność regulacyjna.

Od czego zacząć w tym tygodniu

Zacznijcie od listy klientów. Zaznaczcie tych, którzy działają w sektorach z listy KSC, i przy każdym zapiszcie, kiedy ostatni raz testowaliście bezpieczeństwo dostarczanej im wersji. Ta jedna kolumna pokaże Wam, gdzie pierwsza ankieta zastanie Was z pustymi rękami. Drugi krok to sprawdzenie, czy macie w ogóle jakikolwiek automatyczny test bezpieczeństwa w pipeline. Trzeci to spisanie, choćby na jednej stronie, jak dziś obsługujecie zgłoszoną podatność: kto ją przyjmuje, kto ocenia wagę, w jakim czasie wychodzi poprawka i kto informuje klienta.

Jeśli po tych trzech krokach okaże się, że brakuje Wam raportu niezależnego od zespołu, który pisał kod, chętnie pomożemy. Testujemy niezależnie od producenta, mamy za sobą ponad 152 zrealizowane projekty i ponad 450 000 napisanych testów automatycznych, a zaufały nam między innymi PGE, PSE, ORLEN, Luxmed, NFZ i Poczta Polska. Opis pakietu dla dostawców, z ceną od 14 900 zł netto za pentest aplikacji i API, testy w CI, raport dla klienta i retest, znajdziecie na stronie testy bezpieczeństwa dla dostawców firm objętych NIS2 i KSC. A jeśli wolicie zacząć od zrozumienia problemu po stronie biznesu, polecamy tekst na StrefieQA: ile kosztuje luka bezpieczeństwa, której nikt nie szukał.

Artykuł opisuje wymogi ustawy w zakresie testowania i nie stanowi porady prawnej. Status Waszej firmy i zakres obowiązków konkretnego klienta potwierdźcie z działem prawnym.

Powiązane na blogu Quality Island

• Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie
• Cyber Resilience Act: nowy obowiązek testowania podatności przez cały cykl życia produktu
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje, etapy i jak je zlecić
• Audyt QA w sektorze regulowanym: co pokazuje case PKO BP

Pełna lista źródeł

• Sejm RP, Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252, 2026, sejm.gov.pl. Stąd brzmienie art. 8 ust. 1 i 2, art. 8c, 8e, kary z art. 73 (10 mln euro albo 2 procent, 7 mln euro albo 1,4 procent) i art. 73a (do 300 procent wynagrodzenia kierownika)
• Serwis gov.pl, Baza wiedzy: Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, 2026, gov.pl. Stąd data wejścia w życie, terminy 3.10.2026, 3.04.2027 i 3.04.2028 oraz nowe sektory
• ENISA, NIS Investments 2025, grudzień 2025, enisa.europa.eu. Stąd próba 1 080 specjalistów, 90 procent organizacji ze środkami wobec łańcucha dostaw, 63, 54 i 48 procent dla trzech najczęstszych środków oraz 43 procent podmiotów z sektora usług ICT bez testów bezpieczeństwa i 45 procent z poprawkami krytycznymi po ponad trzech miesiącach
• Verizon, 2025 Data Breach Investigations Report, kwiecień 2025, verizon.com. Stąd ponad 22 tysiące incydentów, 12 195 naruszeń, 30 procent naruszeń z udziałem strony trzeciej i 20 procent z wykorzystaniem podatności, wzrost o 34 procent
• NASK, CERT Polska, raport roczny za 2025 rok, kwiecień 2026, nask.pl. Stąd 260 783 incydenty i wzrost o 152 procent rok do roku
• Dane własne Quality Island: ponad 152 zrealizowane projekty, ponad 450 000 napisanych testów automatycznych, szkolenie z testów bezpieczeństwa dla 14 osób z AgroApp (czerwiec 2026), cennik usług dla dostawców NIS2