19 lutego 2026 r. Prezydent RP podpisał ustawę z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (nr druku sejmowego 1955), jednocześnie podejmując decyzję o skierowaniu ustawy do Trybunału Konstytucyjnego w trybie kontroli następczej. Z perspektywy podmiotów publicznych i prywatnych najważniejsze jest to, że kontrola następcza nie wstrzymuje wejścia w życie ustawy (ustawa została podpisana i będzie ogłoszona), natomiast wynik postępowania przed TK może docelowo doprowadzić do „wycięcia” zakwestionowanych przepisów.

Czym jest kontrola następcza i dlaczego ma znaczenie operacyjne?

Kontrola następcza oznacza, że:

• ustawa jest podpisana i procedowana do ogłoszenia,
• przepisy wejdą w życie w terminie wskazanym w ustawie,
• równolegle Prezydent kieruje do TK wniosek o zbadanie zgodności ustawy (lub wybranych przepisów) z Konstytucją.

Praktyczny wniosek dla rynku: warto planować wdrożenia zgodności i podnoszenie dojrzałości cyberbezpieczeństwa, ale jednocześnie utrzymywać elastyczność w obszarach, które mogą być „sporne” (np. procedury dot. dostawców wysokiego ryzyka – o czym szeroko informują media).

Co ta nowelizacja zmienia w krajobrazie KSC – w skrócie (perspektywa organizacyjna)?

Nowelizacja (druk sejmowy nr 1955) to jedna z najważniejszych aktualizacji przepisów o cyberbezpieczeństwie w ostatnich latach. Jej głównym celem jest dostosowanie polskiego prawa do unijnych wymogów (w tym dyrektywy NIS2) oraz uszczelnienie nadzoru nad infrastrukturą krytyczną.
Kluczowe obszary zmian to:

• Dostawcy wysokiego ryzyka (DWR): Wprowadzenie mechanizmów pozwalających na wykluczenie konkretnych dostawców sprzętu i oprogramowania z polskiego rynku, jeśli zostaną uznani za zagrożenie dla bezpieczeństwa narodowego.
• Rozszerzenie katalogu podmiotów kluczowych: Nowe obowiązki obejmą znacznie szerszą grupę przedsiębiorstw niż dotychczas.
• Krajowy Operator Komunikacyjny: Precyzyjniejsze zdefiniowanie roli państwa w zarządzaniu siecią bezpieczeństwa.

Co robić teraz? Plan działań „compliance-ready”, nawet przy niepewności TK.

Poniżej podejście, które minimalizuje ryzyko „przeinwestowania” w sporne elementy, a jednocześnie realnie podnosi odporność (i zwykle jest spójne z dobrymi praktykami NIS2/ISO 27001).

A. Ustal, czy możesz być objęty reżimem KSC/NIS2 (scoping).

1. Zmapuj działalność do sektorów (również tych „nieoczywistych”).
2. Zweryfikuj progi/cechy organizacji (wielkość, funkcja w łańcuchu dostaw, wpływ na ciągłość usług).
3. Zidentyfikuj krytyczne usługi i aktywa (systemy, dane, integracje).

Nawet jeśli kwalifikacja będzie wymagała doprecyzowań, inwentaryzacja usług i zależności jest pracą, która zawsze się zwraca.

B. Zbuduj minimalny „governance baseline”.

• właściciele ryzyka i bezpieczeństwa (RACI),
• formalny proces oceny ryzyka (metryki, akceptacja),
• polityka zarządzania incydentami + ćwiczenia (table-top),
• reżim dostawców (third-party risk) i wymogi bezpieczeństwa w umowach/SLA.

C. Gotowość na incydenty i raportowanie.

• centralizacja logów (SIEM lub minimum: spójne logowanie + retencja),
• playbooki: ransomware, kompromitacja tożsamości, wyciek danych, atak na łańcuch dostaw,
• kanały komunikacji kryzysowej i dowody (chain of custody).

D. Twarde technikalia: ogranicz powierzchnię ataku.

Tu warto podejść „od brzegu” – bo to najczęściej jest punkt wejścia:

• MFA wszędzie, gdzie to możliwe (zwłaszcza admin/remote),
• segmentacja i zasada najmniejszych uprawnień,
• backup 3-2-1 + testy odtwarzania,
• hardening usług publicznych (WAF, rate limiting, izolacja paneli).

Dlaczego o tym piszemy? TLS/PKI jako element „compliance-by-design”.

W praktyce duża część incydentów i niezgodności wychodzi na styku: tożsamość ↔ komunikacja ↔ dostęp. Dlatego w przygotowaniach do KSC/NIS2 szczególnie „opłaca się” uporządkować:

• pełną inwentaryzację certyfikatów TLS (serwery, reverse proxy, load balancery, urządzenia, usługi zewnętrzne),
• cykl życia: wystawienie → instalacja → odnowienie → rotacja kluczy → wycofanie,
• egzekwowanie silnych konfiguracji (TLS 1.2/1.3, preferencje szyfrów, HSTS tam, gdzie uzasadnione),
• monitoring wygaśnięć i zmian (w tym nieautoryzowanych).

To są działania, które:

• realnie redukują ryzyko przestojów (np. „cert expired”),
• ułatwiają audytowalność (dowody kontroli i monitoringu),
• poprawiają bazę dowodową w razie incydentu.

(W ekosystemie HEXSSL zwykle oznacza to: stały monitoring ważności certyfikatów, okresowe skany konfiguracji TLS oraz kontrolę polityk typu HSTS w usługach brzegowych.)

Co dalej i na co uważać w najbliższych tygodniach?

1. Śledź datę ogłoszenia ustawy – od niej zależy praktyczny harmonogram wejścia w życie (w przestrzeni publicznej pojawia się informacja o miesięcznym vacatio legis).
2. Zakładaj, że nawet przy sporach konstytucyjnych rdzeń wymagań dot. zarządzania ryzykiem i odporności pozostanie „w kierunku NIS2”.
3. Tam, gdzie dyskusja jest najbardziej gorąca (np. mechanizmy dot. „dostawców wysokiego ryzyka”), projektuj procesy tak, by dało się je łatwo skorygować bez przebudowy całego programu bezpieczeństwa.

Nota prawna: Powyższy materiał ma charakter informacyjny i techniczno-organizacyjny; nie stanowi porady prawnej. W przypadku oceny obowiązków konkretnej organizacji rekomendowane jest wsparcie prawnika/regulatora oraz zespołu compliance.