Testy bezpieczeństwa dla dostawców firm objętych NIS2 i KSC

NIS2 testy bezpieczeństwa przestały być wyłącznie sprawą energetyki, szpitali i urzędów. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 roku i każe podmiotom kluczowym oraz ważnym zadbać o bezpieczeństwo łańcucha dostaw. W praktyce oznacza to, że Wasz klient zaczyna pytać Was, dostawcę oprogramowania, o dowody: kiedy był ostatni test penetracyjny, co znaleziono, co poprawiono i kto to sprawdził.

Dostarczamy te dowody. Testujemy bezpieczeństwo Waszej aplikacji i API, wpinamy automatyczne testy bezpieczeństwa w pipeline, robimy retest po poprawkach i przygotowujemy raport, który Wasz klient może dołączyć do oceny dostawcy. Jesteśmy firmą od testów i jakości oprogramowania, nie kancelarią i nie firmą wdrażającą system zarządzania bezpieczeństwem informacji. Nie obiecujemy „zgodności z NIS2”. Obiecujemy rzetelne testy i dokumentację, która pokazuje, co faktycznie sprawdziliśmy.

Pakiet składa się z pięciu elementów. Możecie wziąć całość albo tylko to, czego brakuje w Waszym procesie.

Testy penetracyjne aplikacji webowej i API. Ręczne testy bezpieczeństwa wykonywane przez testera, który myśli jak atakujący: uwierzytelnianie, autoryzacja i role, sesje, walidacja danych wejściowych, konfiguracja, ekspozycja danych w API. Szczegóły metodyki opisujemy na stronie testów bezpieczeństwa aplikacji

Automatyczne testy bezpieczeństwa w CI. Skaner, na przykład OWASP ZAP, uruchamiany w Waszym pipeline przy każdym wydaniu, z progami, które zatrzymują wdrożenie przy nowej podatności wysokiej wagi. Tak powstaje ciągły ślad testów, a nie jeden raport raz w roku. Budowę pipeline opisujemy przy usłudze procesy CI/CD i quality gates

Retest po poprawkach. Każdą zgłoszoną podatność sprawdzamy ponownie po naprawie i zapisujemy wynik. Klient objęty KSC dostaje nie tylko listę problemów, ale też potwierdzenie, że zostały zamknięte

Testy regresji poprawek bezpieczeństwa. Poprawka luki potrafi zepsuć logowanie, płatność albo import danych. Dokładamy do testów regresyjnych scenariusze, które pilnują, żeby łatka nie wróciła i nie popsuła funkcji biznesowych

Raport dla klienta objętego KSC. Streszczenie dla zarządu, zakres i daty testów, lista podatności z oceną krytyczności i dowodami, status poprawek po reteście oraz opis automatycznych testów w CI. Język zrozumiały dla działu bezpieczeństwa klienta i dla jego audytora

Opcjonalnie szkolenie Waszego zespołu: Cybersecurity: testy bezpieczeństwa dla testerów i programistów albo Automatyczne testy bezpieczeństwa z OWASP ZAP, żebyście kolejne testy w CI utrzymywali sami

Najważniejsze przepisy są w nowym brzmieniu art. 8 ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252). Podmiot kluczowy albo ważny wdraża system zarządzania bezpieczeństwem informacji, który obejmuje między innymi bezpieczeństwo w procesie nabywania, rozwoju i utrzymania systemu, „w tym testowanie systemu informacyjnego” (art. 8 ust. 1 pkt 2 lit. b), bezpieczeństwo i ciągłość łańcucha dostaw (lit. e) oraz polityki i procedury oceny skuteczności zabezpieczeń (lit. h).

Dla dostawcy kluczowy jest art. 8 ust. 2. Wdrażając środki dotyczące łańcucha dostaw, podmiot uwzględnia podatności związane z dostawcą sprzętu lub oprogramowania oraz ogólną jakość jego produktów i procesów ICT. Innymi słowy: klient ma obowiązek ocenić jakość i bezpieczeństwo Waszego oprogramowania. Oświadczenie w umowie tego nie załatwi, raport z testów tak.

Jest też powód, dla którego klient nie odpuści. Według art. 8c kierownik podmiotu odpowiada za wykonanie obowiązków z zakresu cyberbezpieczeństwa także wtedy, gdy powierzył je komuś innemu. Zarząd klienta będzie więc chciał zobaczyć dowód, a nie zapewnienie.

Kalendarz nowelizacji KSC i przepisów pokrewnych

Terminy KSC podajemy za Bazą wiedzy na gov.pl, terminy CRA za tekstem rozporządzenia 2024/2847 i stroną Komisji Europejskiej.

Tworzycie oprogramowanie dla firmy z energetyki, ochrony zdrowia, transportu, poczty, administracji albo innego sektora z listy KSC?

Klient przysłał ankietę oceny dostawcy albo aneks z klauzulami cyberbezpieczeństwa i pyta o testy penetracyjne?

Ostatni pentest Waszej aplikacji był dawno temu albo nie było go wcale?

Poprawki bezpieczeństwa trafiają na produkcję bez retestu i bez testów regresji?

Nie macie żadnego automatycznego testu bezpieczeństwa w pipeline?

Sami jesteście podmiotem objętym KSC i chcecie sprawdzić skuteczność zabezpieczeń przed audytem w 2028 roku?

Ustawa obejmuje co do zasady organizacje od 50 pracowników albo 10 mln euro obrotu lub sumy bilansowej, w sektorach takich jak energia, transport, bankowość, zdrowie, woda, infrastruktura cyfrowa, zarządzanie usługami ICT, poczta czy administracja publiczna (zestawienie Grant Thornton). Podmiot sam ocenia, czy spełnia kryteria. Nawet jeśli Wasza firma nie jest objęta ustawą wprost, wymagania dotrą do Was przez umowę z klientem, który jest.

Drugi adresat: podmiot objęty KSC przed audytem 2028

Jeśli to Wy jesteście podmiotem kluczowym albo ważnym, te same testy służą ocenie skuteczności zabezpieczeń Waszych aplikacji: pentest, retest, testy w CI i raport, który pokażecie audytorowi. Audytu KSC nie wykonujemy i nie wdrażamy systemu zarządzania bezpieczeństwem informacji. Dostarczamy wyniki testów, na których ten system i audyt mogą się oprzeć.

Pokrewne przepisy: DORA i Cyber Resilience Act

Banki i infrastruktura rynków finansowych w zakresie zarządzania bezpieczeństwem informacji podlegają nie tym przepisom KSC, tylko rozporządzeniu DORA (art. 8i ustawy). DORA w art. 24 i 25 wymaga programu testów wykonywanych przez niezależne strony, co najmniej raz w roku dla systemów wspierających funkcje krytyczne, a katalog obejmuje także testy penetracyjne. Od 7 sierpnia 2025 roku KNF ma podstawę do kontroli zgodności z DORA. Więcej: rozporządzenie DORA a testy niezależne.

Producentów oprogramowania dotyczy też Cyber Resilience Act: od 11 września 2026 roku zgłaszanie aktywnie wykorzystywanych podatności, a od 11 grudnia 2027 roku pełne stosowanie wymagań, w tym regularnych testów bezpieczeństwa. Opisujemy to w artykule Cyber Resilience Act: testowanie podatności przez cały cykl życia. Pełny przegląd regulacji: zgodność regulacyjna: testy pod DORA, AI Act, CRA i WCAG 2.2.

Specjalizujemy się wyłącznie w testowaniu i jakości oprogramowania. Ponad 152 zrealizowane projekty i ponad 450 000 napisanych testów automatycznych. Testy bezpieczeństwa łączymy z testami funkcjonalnymi i regresją, więc poprawka luki nie psuje reszty systemu

Testujemy niezależnie od producenta. Raport od zewnętrznej firmy testowej ma dla klienta inną wagę niż wynik testów zespołu, który sam napisał kod

Automatyzacja to nasza codzienność. Testy bezpieczeństwa w CI budujemy tak samo jak resztę automatyzacji testów: z progami, raportami i utrzymaniem

Uczymy tego, co robimy. Szkolenie „Cybersecurity: testy bezpieczeństwa” to jeden z naszych bestsellerów, prowadziliśmy je między innymi dla zespołu AgroApp (14 osób, 2 dni)

Znamy sektory objęte KSC. Zaufały nam między innymi PGE, PSE, ORLEN, Luxmed, NFZ, Poczta Polska, Centralny Ośrodek Informatyki i Ministerstwo Cyfryzacji

Zespół certyfikowany ISTQB i akredytowany dostawca szkoleń ISTQB

Odpowiedź na ankietę dostawcy popartą raportem, a nie deklaracją

Mniej podatności w kodzie, który trafia do klienta, bo testy w CI łapią część problemów przed wydaniem

Potwierdzenie zamknięcia luk: retest i testy regresji w jednym dokumencie

Argument handlowy w przetargach i rozmowach z klientami z sektorów objętych KSC

Zespół, który wie, jak utrzymać testy bezpieczeństwa, jeśli dobierzecie szkolenie

Uczciwie: żaden test nie udowodni, że aplikacja nie ma podatności, i żaden raport nie zastąpi oceny prawnej. Po pakiecie macie za to udokumentowany stan bezpieczeństwa aplikacji w konkretnym dniu, listę naprawionych problemów potwierdzoną retestem i automatyczne testy, które co wydanie dopisują kolejne dowody. To dokładnie ten materiał, o który klient objęty KSC poprosi przy ocenie dostawcy, a jego audytor przy audycie.

Jeśli pentest nie znajdzie nic istotnego, też to napiszemy. Czysty raport to również dobra wiadomość dla Waszego klienta.

Wycenę dopasowujemy do liczby aplikacji, ról i punktów końcowych API. Szkoleniową część pakietu sprawdzamy pod kątem dofinansowania, a jeśli firma się kwalifikuje, obsługę wniosku bierzemy na siebie bez dodatkowej opłaty. Szczegóły: dofinansowania i rabaty.

Testy bezpieczeństwa aplikacji: zakres i metodyka

Testy bezpieczeństwa i testy penetracyjne: rodzaje, etapy i jak je zlecić

Cyber Resilience Act: nowy obowiązek testowania podatności

Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie

Zgodność regulacyjna: testy pod DORA, AI Act, CRA i WCAG 2.2

Procesy CI/CD i quality gates

Szkolenie: automatyczne testy bezpieczeństwa z OWASP ZAP

Ta strona opisuje wymogi wymienionych aktów prawnych w zakresie testowania i nie stanowi porady prawnej. Zakres obowiązków konkretnego podmiotu wynika z jego statusu i powinien być potwierdzony przez dział prawny.