Dlaczego KSC zmienia relacje B2B?
Ustawa o Krajowym Systemie Cyberbezpieczeństwa (t.j. Dz.U. 2026 poz. 20 i 252) przenosi odpowiedzialność za bezpieczeństwo łańcucha dostaw bezpośrednio na podmiot kluczowy lub ważny — nie na jego dostawcę. Art. 8 ust. 1 pkt 2 lit. e wymaga, aby system zarządzania bezpieczeństwem informacji (SZBI) obejmował bezpieczeństwo łańcucha dostaw produktów, usług i procesów ICT jako jeden z 14 obligatoryjnych obszarów. Jeśli naruszenie bezpieczeństwa zostanie powiązane z niewystarczającą oceną ryzyka w łańcuchu dostaw, organ nadzorczy może nałożyć karę do 10 mln EUR lub 2% rocznych przychodów z działalności gospodarczej (art. 73 ust. 3 dla podmiotów kluczowych). Kary z art. 73 ust. 1–4 i art. 73a można nałożyć po raz pierwszy od 3 kwietnia 2028 r. (art. 35 ustawy nowelizującej).
Zmiana podejścia względem poprzedniej wersji ustawy jest fundamentalna: regulacja nie pozwala już zrzucić odpowiedzialności na zewnętrznego dostawcę ani zasłonić się brakiem wiedzy o incydencie po jego stronie. Podmiot kluczowy lub ważny musi aktywnie zarządzać ryzykiem w łańcuchu dostaw ICT; praktycznymi narzędziami są m.in. ocena wstępna dostawcy, klauzule umowne, prawo do kontroli i mechanizmy wyjścia (exit clause). Niniejszy artykuł pokazuje, jak przełożyć te wymogi na konkretne zapisy kontraktowe i procedury due diligence.
Ocena ryzyka dostawcy ICT (art. 8 ust. 1 pkt 2 lit. e)
Wdrażając środki bezpieczeństwa łańcucha dostaw (art. 8 ust. 1 pkt 2 lit. e), podmiot kluczowy lub ważny uwzględnia cztery elementy wymienione w art. 8 ust. 2 ustawy o KSC: (1) podatności związane z dostawcą sprzętu lub oprogramowania; (2) ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy sprzętu lub oprogramowania; (3) wyniki skoordynowanej oceny bezpieczeństwa przeprowadzonej przez Grupę Współpracy, o której mowa w art. 22 ust. 1 dyrektywy 2022/2555; (4) wyniki postępowania, o którym mowa w art. 67b. Te cztery elementy są wymogiem ustawowym — warto móc wykazać, że ocena każdego istotnego dostawcy je uwzględniła. Dalsze kryteria (druga tabela) nie wynikają z art. 8 ust. 2 — to dobra praktyka, którą dobiera się proporcjonalnie do ryzyka.
| Element (art. 8 ust. 2) | Co sprawdzić | Sygnały alarmowe |
|---|---|---|
| Pkt 1 — podatności związane z dostawcą sprzętu lub oprogramowania | Rejestr CVE, SBOM (Software Bill of Materials), procedura zarządzania podatnościami i ich ujawniania (VDP/CVD), testy penetracyjne | Brak SBOM dla oprogramowania wbudowanego, brak procesu zarządzania podatnościami, krytyczne CVE bez harmonogramu poprawki |
| Pkt 2 — ogólna jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy | Dokumentacja techniczna, testy produktu, historia podatności, cykl życia wsparcia, praktyki bezpiecznego wytwarzania | Niezałatane podatności wysokiego ryzyka (CVSS 7+), brak SLA dla poprawek bezpieczeństwa, koniec wsparcia w horyzoncie kontraktu |
| Pkt 3 — wyniki skoordynowanej oceny bezpieczeństwa Grupy Współpracy (art. 22 ust. 1 dyrektywy 2022/2555) | Czy produkt, usługa lub dostawca należy do obszaru objętego skoordynowaną unijną oceną ryzyka łańcucha dostaw i jakie są jej wnioski | Produkt lub dostawca wskazany w ocenie jako źródło ryzyka, bez środków ograniczających po stronie podmiotu |
| Pkt 4 — wyniki postępowania z art. 67b (dostawca wysokiego ryzyka) | Decyzje ministra ogłaszane w Monitorze Polskim i w BIP; typy produktów, rodzaje usług i procesy ICT wskazane w decyzji (art. 67b ust. 16–17) | Produkt, usługa lub proces ICT objęte decyzją — zakaz wprowadzania do użytkowania i obowiązek wycofania (art. 67c) |
| Dodatkowe kryterium (dobra praktyka) | Co sprawdzić | Sygnały alarmowe |
|---|---|---|
| Ogólne praktyki bezpieczeństwa dostawcy | Polityki bezpieczeństwa, certyfikaty (ISO 27001, SOC 2), wyniki poprzednich audytów, historia incydentów | Brak polityki bezpieczeństwa, odmowa udostępnienia raportów audytowych, incydenty bez dokumentacji działań naprawczych |
| Przejrzystość działania dostawcy | Transparentność struktury właścicielskiej, dostępność SLA i raportów | Ukryta struktura właścicielska, odmowa udostępnienia warunków SLA |
| Cyberhigiena i procedury | Zarządzanie uprawnieniami, MFA, segmentacja sieci, procedury patchowania, szkolenia pracowników | Brak MFA dla dostępów uprzywilejowanych, cykl patchowania powyżej 30 dni dla krytycznych podatności |
| Kraj pochodzenia dostawcy i powiązania | Jurysdykcja rejestracji, struktura korporacyjna, powiązania z państwami trzecimi | Rejestracja lub kontrola przez podmiot z państwa trzeciego budzącego zastrzeżenia |
| Wpływ na łańcuch dostaw podmiotu | Krytyczność dla świadczonej usługi, dostęp do danych wrażliwych, możliwość jednoczesnej awarii (single point of failure) | Dostawca jest jedynym źródłem krytycznej usługi, dostęp do wielu systemów bez segmentacji |
Rekomendowane klauzule w umowie z dostawcą
Ustawa o KSC nie narzuca konkretnych zapisów umownych — wymaga zarządzania ryzykiem łańcucha dostaw (art. 8 ust. 1 pkt 2 lit. e i ust. 2). Klauzule umowne są jednym z praktycznych narzędzi, które ułatwiają wykazanie, że podmiot to ryzyko ocenia i ogranicza. Poniżej przedstawiono 8 rekomendowanych klauzul do rozważenia w umowach z dostawcami ICT istotnymi dla świadczonej usługi. Klauzule dobiera się proporcjonalnie do ryzyka związanego z danym dostawcą, a ich brzmienie wymaga oceny konkretnej umowy.
| Klauzula | Treść skrócona | Podstawa prawna |
|---|---|---|
| Prawo do audytu | Zamawiający ma prawo przeprowadzić lub zlecić audyt bezpieczeństwa u dostawcy raz w roku lub po wystąpieniu istotnego incydentu, z zachowaniem 14-dniowego okresu powiadomienia. | Art. 8 ust. 1 pkt 2 lit. e; art. 8 ust. 2 KSC |
| Obowiązek powiadomienia o incydencie | Dostawca powiadamia zamawiającego o każdym incydencie bezpieczeństwa mogącym wpłynąć na świadczone usługi niezwłocznie, nie później niż w ciągu [X] godzin od wykrycia — tak, by zamawiający zdążył z własnym wczesnym ostrzeżeniem (24 h od wykrycia incydentu poważnego) i zgłoszeniem (72 h); informacje szczegółowe przekazuje w terminie umożliwiającym zamawiającemu dotrzymanie tych terminów. | Wymóg umowny wspierający art. 11 ust. 1 pkt 4–4a KSC (dostawca usług zaufania — 24 h na zgłoszenie, art. 11 ust. 1a) |
| SLA cyberbezpieczeństwo | Dostawca gwarantuje czas reakcji na krytyczne podatności (CVSS 9+): patch lub obejście w ciągu 72 godzin; dla wysokich (CVSS 7–8,9): 14 dni roboczych. | Dobra praktyka; wspiera uwzględnienie podatności związanych z dostawcą (art. 8 ust. 2 pkt 1 KSC) |
| Zgodność z KSC/NIS2 | Dostawca oświadcza, że spełnia wymogi właściwych przepisów o cyberbezpieczeństwie i zobowiązuje się do niezwłocznego informowania o utracie tej zgodności. | Art. 8 ust. 1 pkt 2 KSC; Dyrektywa NIS2 art. 21 |
| Utrzymanie certyfikatów bezpieczeństwa | Dostawca zobowiązuje się do utrzymania przez cały okres umowy wskazanych certyfikatów (np. ISO/IEC 27001, SOC 2 Type II) i dostarczania aktualnych raportów z audytów certyfikacyjnych na żądanie. | Dobra praktyka (art. 8 ust. 1 pkt 2 lit. e KSC); certyfikat nie przesądza o zgodności |
| Klauzula exit (przeniesienie do innego dostawcy) | W przypadku decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka (art. 67b KSC) lub rażącego naruszenia SLA bezpieczeństwa, zamawiający może wypowiedzieć umowę ze skutkiem natychmiastowym bez kary umownej; dostawca zobowiązany jest do wsparcia migracji przez min. 6 miesięcy. | Art. 67a–67j KSC (dostawca wysokiego ryzyka) |
| Odpowiedzialność odszkodowawcza | Dostawca ponosi odpowiedzialność za szkody poniesione przez zamawiającego wskutek naruszenia bezpieczeństwa wynikającego z zaniedbań po stronie dostawcy, w tym za kary administracyjne nałożone na zamawiającego, o ile wynikają bezpośrednio z uchybień dostawcy. | KC art. 471 i nast. (odpowiedzialność kontraktowa) — przeniesienie na dostawcę ciężaru kary nałożonej na zamawiającego jest kwestią umowną, nie wynika z KSC |
| Klauzula poddostawców (sub-processing) | Dostawca może korzystać z podwykonawców ICT wyłącznie po uprzedniej pisemnej zgodzie zamawiającego; wobec podwykonawców stosuje wymogi bezpieczeństwa co najmniej równoważne niniejszej umowie i odpowiada za ich działania jak za własne. | Art. 8 ust. 1 pkt 2 lit. e KSC; RODO art. 28 ust. 4 |
Schemat due diligence — krok po kroku
Due diligence dostawcy ICT w reżimie KSC to proces ustrukturyzowany — nie jednorazowe sprawdzenie przed podpisaniem umowy, ale cykl weryfikacji obejmujący fazę przedkontraktową, bieżący monitoring i audyt cykliczny.
| Etap | Działania | Narzędzia i dokumenty |
|---|---|---|
| 1. Kwalifikacja wstępna (przed wyborem dostawcy) | Wypełnienie kwestionariusza bezpieczeństwa przez dostawcę; weryfikacja certyfikatów; sprawdzenie listy dostawców wysokiego ryzyka; ocena kraju pochodzenia i struktury właścicielskiej; wstępna klasyfikacja ryzyka | Kwestionariusz bezpieczeństwa dostawcy; rejestr dostawców wysokiego ryzyka MC; KRS/CEIDG; macierz ryzyka dostawcy |
| 2. Due diligence kontraktowe (przed podpisaniem umowy) | Negocjacja i włączenie rekomendowanych klauzul bezpieczeństwa (proporcjonalnie do ryzyka); weryfikacja polis ubezpieczeniowych; analiza SLA pod kątem wymogów KSC; ocena planów ciągłości działania dostawcy (BCP/DRP); potwierdzenie procesu zarządzania podatnościami | Wzorzec klauzul bezpieczeństwa; SLA checklist KSC; BCP/DRP questionnaire; SBOM (jeśli dotyczy oprogramowania) |
| 3. Monitoring bieżący i audyt cykliczny | Coroczny przegląd oceny ryzyka dostawcy; weryfikacja aktualności certyfikatów; analiza raportów incydentów; audyt bezpieczeństwa min. raz na 2 lata dla dostawców krytycznych; aktualizacja klasyfikacji ryzyka po każdej istotnej zmianie | Rejestr dostawców ICT z datami przeglądów; raporty audytowe; logi powiadomień o incydentach; raporty CVE/podatności |
KSC a zamówienia publiczne i przetargi
Podmioty kluczowe i ważne będące jednocześnie zamawiającymi publicznymi muszą integrować wymogi KSC z procedurami zamówień publicznych prowadzonymi na podstawie ustawy Prawo zamówień publicznych (PZP). Nie jest to kwestia wyboru — to równoległe zobowiązanie wynikające z dwóch ustaw.
- Opis przedmiotu zamówienia (OPZ): zamawiający może i powinien włączyć wymagania bezpieczeństwa z art. 8 ust. 2 KSC jako techniczne wymagania minimalne — np. obowiązek posiadania certyfikatu ISO 27001, SLA dla podatności, SBOM dla oprogramowania.
- Kryteria oceny ofert: zgodnie z art. 242 PZP dopuszczalne jest uwzględnienie kryteriów cyberbezpieczeństwa (np. poziom certyfikacji, wyniki audytów) jako kryterium pozacenowe.
- Oświadczenie wykonawcy o zgodności z KSC: zamawiający może wymagać oświadczenia, że wykonawca nie jest dostawcą wysokiego ryzyka w rozumieniu art. 67b KSC.
- Odrzucenie oferty i zakaz nabywania: zamawiający odrzuca ofertę, która obejmuje produkt ICT, którego typ został określony w decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka (art. 67b ust. 15 KSC), lub usługę ICT albo proces ICT określone w tej decyzji (art. 226 ust. 1 pkt 19 PZP, dodany art. 17 ustawy nowelizującej), a także ofertę obejmującą produkt, usługę lub proces ICT wskazane w rekomendacji Pełnomocnika z art. 33 ust. 4 KSC stwierdzającej ich negatywny wpływ na podstawowy interes bezpieczeństwa państwa (art. 226 ust. 1 pkt 17 PZP). Podmioty z art. 67b ust. 1 stosujące PZP nie mogą nabywać produktów, usług ani procesów ICT określonych w decyzji (art. 67c ust. 4 KSC). Wykluczenie wykonawcy za zawinione poważne naruszenie obowiązków zawodowych (art. 109 ust. 1 pkt 5 PZP) jest podstawą fakultatywną — wymaga wskazania w dokumentach zamówienia i wykazania wszystkich jej przesłanek w konkretnej sprawie.
- Klauzule w umowie o zamówienie publiczne: rekomendowane klauzule bezpieczeństwa (prawo do audytu, obowiązek powiadomienia o incydencie, klauzula exit) warto rozważyć w umowach na dostawy i usługi ICT istotne dla świadczonej usługi — ustawa ich nie narzuca, a zakres dobiera się proporcjonalnie do ryzyka.
Fuzje i przejęcia: cyberbezpieczeństwo w due diligence M&A
Transakcje fuzji i przejęć (M&A) obejmujące podmioty z sektora KSC wymagają specjalnego podejścia do due diligence cyberbezpieczeństwa. Przejmując spółkę będącą podmiotem kluczowym lub ważnym, nabywca wchodzi w jej prawa i obowiązki — w tym niezrealizowane zobowiązania z ustawy o KSC, toczące się postępowania administracyjne i potencjalne kary.
| Obszar weryfikacji | Pytania kluczowe | Dokumenty do uzyskania |
|---|---|---|
| Status regulacyjny | Czy spółka jest podmiotem kluczowym (PK) czy ważnym (PW)? Czy wpis w wykazie jest aktualny (zmiany danych zgłasza się w 14 dni — art. 7c ust. 3)? Czy toczą się postępowania kontrolne? | Zaświadczenie o wpisie do wykazu, dokumentacja samoidentyfikacji (art. 5; ewentualnie decyzja organu z art. 7l); korespondencja z organem nadzorczym; rejestr postępowań |
| Stan wdrożenia SZBI | Czy SZBI obejmuje wszystkie 14 obszarów z art. 8 ust. 1? Czy przeprowadzono audyt SZBI? Jakie były wyniki i status zaleceń? | Dokumentacja SZBI; raporty z audytów; rejestr zaleceń poaudytowych; polityki bezpieczeństwa |
| Historia incydentów | Czy wystąpiły poważne incydenty w ciągu ostatnich 3 lat? Czy zgłoszono je do CSIRT? Czy incydenty skutkowały karami? | Rejestr incydentów; raporty do CSIRT; dokumentacja działań naprawczych; decyzje administracyjne o karach |
| Łańcuch dostaw ICT | Czy przeprowadzono ocenę ryzyka wszystkich istotnych dostawców ICT? Czy żaden z dostawców nie jest dostawcą wysokiego ryzyka? Czy umowy z kluczowymi dostawcami zawierają klauzule bezpieczeństwa adekwatne do ryzyka? | Rejestr dostawców ICT z oceną ryzyka; umowy z dostawcami; oświadczenia o braku statusu dostawcy wysokiego ryzyka |
| Kary i obciążenia finansowe | Czy nałożono kary administracyjne na podstawie art. 73 KSC? Czy istnieją nierozstrzygnięte odwołania? | Decyzje o karach; odwołania; opinia prawna o ryzyku karowym; szacunek potencjalnych kar za niezgodności |
| Zależności technologiczne | Czy spółka korzysta z produktów dostawców z państw trzecich wysokiego ryzyka? Czy istnieje koncentracja ryzyka u jednego dostawcy? | Inwentaryzacja systemów ICT; SBOM dla kluczowych systemów; umowy z dostawcami chmurowymi |
Powiązane artykuły: Łańcuch dostaw w KSC, Dostawca wysokiego ryzyka, Audyt bezpieczeństwa KSC, Kary administracyjne KSC.