Dlaczego KSC zmienia relacje B2B?
Ustawa o Krajowym Systemie Cyberbezpieczeństwa (Dz.U. 2026 poz. 20) 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ł ocenę ryzyk związanych z dostawcami 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% całkowitego rocznego obrotu (dla podmiotów kluczowych).
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 musi aktywnie zarządzać ryzykiem w całym łańcuchu ICT — od audytu wstępnego, przez klauzule umowne, aż po 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)
Art. 8 ust. 2 ustawy o KSC wskazuje kryteria, które podmiot zobowiązany musi uwzględnić przy ocenie ryzyka dostawcy. Nie jest to lista uznaniowa — organ nadzorczy będzie weryfikować, czy ocena obejmowała wszystkie wymienione elementy.
| Kryterium (art. 8 ust. 2) | 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 |
| Jakość produktów i usług ICT | Dokumentacja techniczna, testy penetracyjne produktu, podatności CVE historyczne, cykl życia wsparcia | Niezałatane podatności wysokiego ryzyka (CVSS 7+), brak SLA dla poprawek bezpieczeństwa, koniec wsparcia w horyzoncie kontraktu |
| Przejrzystość działania dostawcy | Ujawnianie podatności (VDP/CVD), transparentność struktury właścicielskiej, dostępność SLA i raportów | Ukryta struktura właścicielska, brak polityki odpowiedzialnego ujawniania podatności, 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 |
| Podatności produktów i usług | Rejestr CVE, SBOM (Software Bill of Materials), procedura zarządzania podatnościami, testy penetracyjne | Brak SBOM dla oprogramowania wbudowanego, brak procesu zarządzania podatnościami, CVSS krytyczne bez harmonogramu poprawki |
| Kraj pochodzenia dostawcy i powiązania | Jurysdykcja rejestracji, struktura korporacyjna, powiązania z państwami trzecimi wysokiego ryzyka, decyzje ministra (art. 66a–66j) | Rejestracja lub kontrola przez podmiot z państwa wysokiego ryzyka, obecność na liście dostawców wysokiego ryzyka |
| Wpływ na łańcuch dostaw podmiotu | Krytyczność dla systemów kluczowych, 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 kluczowych bez segmentacji |
Dostawca wysokiego ryzyka: na podstawie art. 66a–66j ustawy o KSC minister właściwy ds. cyfryzacji może wydać decyzję o uznaniu dostawcy za dostawcę wysokiego ryzyka. Od dnia uprawomocnienia decyzji podmiot kluczowy nie może wprowadzać nowych produktów ani usług tego dostawcy. Klauzula wyjścia w umowie z dostawcą powinna przewidywać ten scenariusz i zapewniać sprawne przeniesienie do alternatywnego dostawcy bez kar umownych po stronie podmiotu kluczowego.
Obowiązkowe klauzule w umowie z dostawcą
Wymagania KSC przekładają się na konkretne zapisy umowne. Poniżej przedstawiono 8 klauzul, które powinny znaleźć się w każdej umowie z dostawcą ICT istotnym dla systemów kluczowych lub ważnych. Pominięcie tych zapisów może być traktowane jako brak należytej oceny ryzyka i podstawa do wszczęcia postępowania administracyjnego.
| 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 zobowiązany jest powiadomić zamawiającego o każdym incydencie bezpieczeństwa mogącym wpłynąć na świadczone usługi w ciągu 24 godzin od wykrycia, a raport szczegółowy — w ciągu 72 godzin. | Art. 11 ust. 1–3 KSC (analogicznie); wymóg umowny |
| 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. | Art. 8 ust. 2 pkt 4 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. | Art. 8 ust. 2 pkt 1 KSC |
| Klauzula exit (przeniesienie do innego dostawcy) | W przypadku decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka (art. 66a 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. 66a–66j 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. | Art. 73 ust. 4 KSC; KC art. 471 |
| 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 |
Prawo do audytu jako kluczowa klauzula: organ nadzorczy może żądać wyników audytów dostawców podczas kontroli podmiotu kluczowego. Jeśli umowa z dostawcą nie zawiera prawa do audytu, podmiot może nie być w stanie wykazać, że przeprowadził wymaganą ocenę ryzyka. Klauzula powinna precyzować zakres audytu, sposób wyboru audytora (w tym prawo do audytora trzeciego), zasady poufności wyników oraz obowiązek wdrożenia zaleceń poaudytowych w uzgodnionym terminie.
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 MCC; KRS/CEIDG; macierz ryzyka dostawcy |
| 2. Due diligence kontraktowe (przed podpisaniem umowy) | Negocjacja i włączenie 8 klauzul bezpieczeństwa; 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 |
Dokumentuj każdy etap: organ nadzorczy weryfikuje nie tylko wynik oceny ryzyka, lecz także ścieżkę dojścia do niej. Przechowuj kwestionariusze, korespondencję z dostawcą, raporty audytowe i rejestry decyzji przez co najmniej 5 lat lub przez okres trwania umowy plus 3 lata.
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. 66a KSC.
- Podstawy wykluczenia: naruszenia przepisów o cyberbezpieczeństwie mogą stanowić podstawę wykluczenia w oparciu o art. 109 ust. 1 pkt 8 PZP, o ile zostały stwierdzone prawomocną decyzją.
- Klauzule w umowie o zamówienie publiczne: wzorcowe klauzule KSC (prawo do audytu, obowiązek powiadomienia o incydencie, klauzula exit) powinny być obligatoryjne w umowach na dostawy i usługi ICT powyżej progów unijnych.
Wymogi KSC w zamówieniach publicznych dotyczą co do zasady wszystkich zamówień na usługi i dostawy ICT, niezależnie od progu. Dla zamówień poniżej progów unijnych zamawiający ma większą elastyczność, jednak jako podmiot kluczowy nadal odpowiada za ocenę ryzyka dostawcy — brak formalnego przetargu nie zwalnia z tego obowiązku.
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 notyfikacja do organu nadzorczego jest aktualna? Czy toczą się postępowania kontrolne? | Decyzja o uznaniu za PK/PW lub notyfikacja; 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 dostawcami zawierają wymagane klauzule? | 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 |
Odpowiedzialność następcza w M&A: przejęcie spółki będącej podmiotem kluczowym bez rzetelnego due diligence cyberbezpieczeństwa może skutkować przejęciem ukrytych zobowiązań — toczących się postępowań o kary, niezrealizowanych zaleceń poaudytowych, umów z dostawcami wysokiego ryzyka wymagających kosztownej migracji. W skrajnych przypadkach nabywca może odpowiadać za naruszenia, które miały miejsce przed transakcją.