Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026. Wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć do 3 października 2026 - zostało około dziesięciu tygodni. Rejestracja to jednak najprostsza część zadania, bo jest formularzem w systemie państwowym. Trudniejsze jest to, czego nikt nie widzi na formularzu: zdolność wykrycia incydentu i pokazania dowodu, że wykrycie faktycznie nastąpiło.
W SAP tej zdolności zwykle nie ma.
W skrócie:
1/ Wpis do wykazu KSC - termin 3 października 2026, wnioski przyjmowane od 7 maja przez wykaz-ksc.gov.pl,
2/ Zgłoszenie incydentu poważnego - wczesne ostrzeżenie w 24 h i zgłoszenie w 72 h, licząc od wykrycia, oraz sprawozdanie końcowe w miesiąc od zgłoszenia,
3/ Pierwszy audyt podmiotów kluczowych - do 3 kwietnia 2028, na dowodach zbieranych od 2026,
4/ Uwierzytelnianie wieloczynnikowe - wymóg wprost z art. 21 ust. 2 lit. j dyrektywy NIS2, w SAP realizowany rzadko.
Zegar, który już tyka
Ustawa z 23 stycznia 2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa została opublikowana 2 marca 2026 (Dz.U. 2026 poz. 252) i weszła w życie 3 kwietnia 2026. To ona wdraża do polskiego prawa dyrektywę NIS2.
| Termin | Co się dzieje |
|---|---|
| 3.04.2026 | Ustawa obowiązuje. Obowiązki obsługi i zgłaszania incydentów działają od pierwszego dnia |
| 7.05.2026 | Ministerstwo Cyfryzacji otwiera samodzielną rejestrację w wykazie |
| 3.10.2026 | Termin złożenia wniosku o wpis do wykazu podmiotów kluczowych i ważnych |
| 3.04.2028 | Termin pierwszego audytu bezpieczeństwa podmiotów kluczowych |
Do tego dwie liczby, które zwykle kończą dyskusję na zarządzie. Podmiot kluczowy odpowiada karą do 10 mln EUR albo 2% przychodu, podmiot ważny do 7 mln EUR albo 1,4% - w obu przypadkach obowiązuje wartość wyższa. Przy naruszeniach zagrażających między innymi bezpieczeństwu państwa, porządkowi publicznemu, zdrowiu ludzi albo grożących poważną szkodą majątkową ustawa przewiduje karę nadzwyczajną do 100 mln PLN, a kierownik podmiotu prywatnego odpowiada osobiście kwotą do 300% swojego wynagrodzenia.
Jest jeszcze poprawka, która w praktyce usypia czujność: nakładanie typowych kar administracyjnych zostało odroczone o około dwa lata od wejścia ustawy w życie. Odroczenie nie obejmuje jednak wszystkiego - kara nadzwyczajna i część środków nadzorczych pozostają dostępne od początku. Brzmi jak oddech. W rzeczywistości to gorszy scenariusz niż natychmiastowe sankcje, bo audyt w 2028 nie zapyta o stan z 2028. Zapyta o dowody z okresu, który właśnie trwa.
Poranek, którego nie ma w żadnej procedurze
Wyobraźcie sobie administratora Basis w środę o 7:40. Ma trzy systemy produkcyjne, wczorajszy transport do wdrożenia i skrzynkę z czterdziestoma nieprzeczytanymi wiadomościami. Nie ma w niej żadnej informacji o tym, że w nocy ktoś dwadzieścia razy próbował zalogować się na konto techniczne z zewnętrznego adresu, aż trafił hasło. Nie ma, bo nikt takiej informacji nie wysyła.
Security Audit Log jest włączony - tak wygląda to w większości projektów, które prowadzimy. Tylko że nikt go nie czyta, nikt nie ustawił progów, a wpisy nadpisują się po kilku dniach. W SIEM leżą logi z firewalla, stacji roboczych i Active Directory, natomiast SAP kończy się na monitoringu dostępności: system odpowiada, więc jest dobrze.
I tu zamyka się pułapka regulacyjna. Zegar 24 godzin na wczesne ostrzeżenie startuje od momentu wykrycia incydentu. Jeżeli nie ma czym wykryć, zegar formalnie nie startuje - tylko że w postępowaniu organ nadzoru najprawdopodobniej potraktuje to nie jako brak incydentów, a jako brak środków technicznych adekwatnych do ryzyka. Różnica między „nie mieliśmy incydentu“ a „nie wiemy, czy mieliśmy incydent“ jest w tym postępowaniu różnicą kluczową.
Sześć kroków, które pokazują, gdzie stoicie
Nie o zgodność w ogóle. Konkretnie o SAP. Te same sześć kroków przechodzicie w naszym bezpłatnym badaniu SNOK KSC-CHECK - pięć obszarów po pięć pytań, plus krok, w którym wskazujecie, gdzie wysłać raport.
Krok 1. Widoczność zdarzeń. Czy Security Audit Log, logi zmian tabel i logi RFC są w ogóle zapisywane, jak długo je trzymacie i czy cokolwiek z nich trafia do SIEM. Bez zapisu nie ma czym wykryć incydentu, a zegar startuje od wykrycia.
Krok 2. Wykrywanie i reakcja. Kto dostaje alert z SAP i po ilu minutach, kto ma dyżur po godzinach, kto podpisuje sprawozdanie 72-godzinne i czy procedura była kiedykolwiek ćwiczona.
Krok 3. Podatności i poprawki. Ile dni mija od SAP Security Patch Day do wdrożenia not HotNews na produkcji. Jeśli nikt nie zna tej liczby, to jest właśnie odpowiedź.
Krok 4. Tożsamość i dostęp. Czy wejście do produkcji wymaga drugiego czynnika, kiedy ostatnio zmieniano hasła kont serwisowych i ilu użytkowników ma uprawnienia zbliżone do pełnych. NIS2 wymienia uwierzytelnianie wieloczynnikowe wprost, w art. 21 ust. 2 lit. j, a w polskich landscape’ach SAP drugi czynnik to nadal rzadkość.
Krok 5. Zgodność i dowody. Czy status podmiotu jest ustalony formalnie, czy wniosek o wpis został złożony, co w modelu RISE with SAP należy do SAP a co do Was, i co dokładnie pokażecie audytorowi w 2028 jako dowód wykrywania w latach 2026-2027. Zrzut ekranu nie jest dowodem.
Krok 6. Wynik i raport. Punktacja w pięciu obszarach na ekranie od razu, a na maila raport PDF z trzema największymi lukami oraz planem na 30 dni i na 12 miesięcy.
Całość to 25 pytań i od 8 do 12 minut. Pytania są sformułowane dla dyrektora IT, nie dla administratora Basis, a odpowiedź „nie wiem“ jest dozwolona i punktowana zerem - brak wiedzy o własnym systemie sam jest wynikiem. To samoocena, nie audyt i nie potwierdzenie zgodności, ale pokazuje, gdzie szukać braków.
Czym domyka się tę lukę
Zgodność nie jest produktem, więc żadne narzędzie jej nie „załatwi“. Potrzebne są procedury, właściciel procesu, dyżury i ćwiczenia. Narzędzie odpowiada natomiast za część, której nie da się zrobić rękami: ciągłe patrzenie na system i zapisywanie tego, co widzi.
Platforma SecurityBridge działa jako certyfikowany dodatek wewnątrz ABAP, bez zewnętrznych serwerów i dodatkowych agentów w systemie operacyjnym. Z perspektywy obowiązków KSC liczą się cztery obszary:
Wykrywanie w czasie rzeczywistym. Monitoring zdarzeń i wykrywanie anomalii w warstwie aplikacyjnej SAP - tam, gdzie firewall i antywirus nie widzą niczego. Platforma rozumie specyfikę SAP, której brakuje generycznym narzędziom: Security Audit Log, masowe czytanie tabel przez SE16, zmiany w obiektach ABAP poza ścieżką autoryzacji, eskalację uprawnień przez SU01 i PFCG, nietypowy ruch RFC między systemami. Właśnie te zdarzenia budują materiał na wczesne ostrzeżenie w 24 godziny, bo opisują zachowanie użytkownika i systemu, a nie sam fakt, że system odpowiada.
Integracja z SIEM i SOAR. Zdarzenia z SAP trafiają w to samo miejsce, w którym SOC patrzy na resztę infrastruktury - w praktyce najczęściej Microsoft Sentinel, Splunk, IBM QRadar albo ArcSight. Bez tego SAP zostaje wyspą, a incydent rozpoznaje się z opóźnieniem liczonym w tygodniach. Warstwa SOAR pozwala część reakcji przypisać do scenariusza zamiast do dyżurnego: zablokowanie konta, eskalację do SOC, zebranie śladu zmian. Dla terminu 24 godzin liczy się to podwójnie, bo czas nie ucieka wtedy na ustalanie, kto właściwie ma coś zrobić.
Zarządzanie podatnościami i notami. Inwentaryzacja tego, czego brakuje po każdym Patch Day, wraz z oceną, co naprawdę dotyczy Waszej konfiguracji - nie każda nota o wysokim CVSS ma znaczenie w systemie, w którym dany komponent nie jest aktywny. Obok not sprawdzana jest konfiguracja i kod własny, czyli dwa źródła luk, których producent nie załata za Was. Ten obszar łączy się bezpośrednio z comiesięcznym cyklem poprawek SAP, a jego produktem ubocznym jest odpowiedź na pytanie z kroku trzeciego: ile dni faktycznie mija od publikacji noty do produkcji.
Raporty zgodności. Mapowanie kontroli na ISO 27000, CIS i NIS2, czyli uporządkowany materiał do przedstawienia audytorowi zamiast rekonstruowania historii tydzień przed kontrolą. Samo mapowanie nie jest jeszcze dowodem zgodności - dowodem są zapisy pokazujące, że kontrole faktycznie działały. Znaczenie tego obszaru rośnie wraz z odległością do 2028 roku: audytor nie zapyta, czy dziś macie monitoring, ale czy potraficie pokazać, co widzieliście w 2026 i 2027 oraz co z tym zrobiliście. Raport generowany cyklicznie jest znacznie mocniejszym materiałem dowodowym niż zrzut ekranu z konsoli, o którego dacie i kompletności nie da się nic powiedzieć.
Do tego dochodzi warstwa tożsamości. TrustBroker trafił do portfolio SecurityBridge wraz z przejęciem brytyjskiej firmy CyberSafe, ogłoszonym w lipcu 2025. Daje bezpieczne logowanie jednokrotne oraz uwierzytelnianie wieloczynnikowe wymuszane warunkowo: przy logowaniu albo dopiero przy próbie wykonania operacji o wysokim ryzyku (step-up). Współpracuje z tym, co firmy już mają - Microsoft Entra MFA, Okta, PingID, Duo, RSA SecurID, aplikacje TOTP i HOTP. Po integracji z platformą decyzja o żądaniu drugiego czynnika może uwzględniać sygnały o zagrożeniu, na przykład nietypowe zachowanie przy logowaniu albo nieznane urządzenie.
To odpowiedź na pytanie o drugi czynnik z kroku czwartego, w formie, którą da się wdrożyć bez wymiany całej architektury tożsamości. Wymuszanie warunkowe ma tu znaczenie praktyczne: drugi czynnik przy każdym logowaniu do systemu, w którym pracownicy magazynu wchodzą kilkanaście razy dziennie, kończy się obejściem albo buntem, natomiast drugi czynnik przed zmianą danych bankowych dostawcy nie budzi niczyjego sprzeciwu.
Warto też powiedzieć, czym ta warstwa nie jest. Platforma nie zastępuje zarządzania uprawnieniami ani rozdziału obowiązków - pokazuje, że ktoś użył szerokich uprawnień, ale nie decyduje, czy powinien je mieć. Nie zastępuje też SOC-a: dostarcza zdarzenia, a nie osobę, która na nie patrzy o drugiej w nocy. Sensowna kolejność jest więc taka, że najpierw ustalacie właściciela procesu i adresata alertu, a potem włączacie narzędzie - odwrotna kolejność daje konsolę, do której nikt nie zagląda.
Czego takie wdrożenie nie zrobi
Trzy rzeczy, o których warto wiedzieć zawczasu, bo inaczej rozczarowanie przyjdzie po podpisaniu umowy.
Po pierwsze, platforma nie stworzy procedury zgłoszenia incydentu ani nie wskaże osoby dyżurnej. Jeśli o 2:00 w nocy nikt nie odbierze telefonu, alert zostanie w konsoli i termin 24 godzin przepadnie tak samo, jakby monitoringu nie było.
Po drugie, pierwsze tygodnie po włączeniu wykrywania anomalii oznaczają fałszywe alarmy. Progi trzeba dostroić do Waszych procesów, a to praca ludzka, nie automat. Zwykle liczona w tygodniach, nie w dniach.
Po trzecie, przy niewielkim landscape i braku statusu podmiotu kluczowego pełna platforma może być rozwiązaniem ponad potrzebę. Wtedy sensowniejsze bywa uporządkowanie tego, co już macie: włączenie właściwych klas zdarzeń, wypchnięcie logów do SIEM, przegląd kont serwisowych. Mówimy to również klientom, którzy przychodzą gotowi kupić licencję - kolejność ma znaczenie, a hardening SAP jest procesem, nie projektem.
„Największym problemem nie są podatności, o których wiemy z Patch Day. Największym problemem są systemy, w których od dwóch lat nikt nie sprawdził, kto naprawdę się loguje i co robi. Ustawa tego nie zmieni, ale audyt w 2028 to obnaży.“
Jarosław Zdanowski, Partner odpowiedzialny za cyberbezpieczeństwo SAP i SAP Basis w SNOK
Plan na dziesięć tygodni
Do 3 października realnie da się zrobić trzy rzeczy, i to wystarczy, żeby wyjść z pozycji „nie wiemy“.
Najpierw ustalcie status: czy firma jest podmiotem kluczowym, ważnym, czy żadnym z nich. Decyduje sektor z załącznika do ustawy i wielkość, a przy dostawcach usług zarządzanych progi są znacznie niższe niż przy pozostałych podmiotach. Bez tej odpowiedzi wszystkie następne kroki są zgadywaniem.
Potem zinwentaryzujcie, co dziś w SAP jest widoczne: jakie klasy zdarzeń są zapisywane, jak długo, kto je czyta, co dociera do SOC. Efektem ma być lista braków, nie prezentacja.
Na końcu zdecydujcie o warstwie technicznej i o właścicielu procesu z nazwiskiem, nie z nazwą zespołu. Wniosek o wpis do wykazu składa się w systemie państwowym i zajmuje godziny. Zdolność wykrycia incydentu buduje się miesiącami, więc rejestracja jest ostatnim krokiem, nie pierwszym.
Jak pomagamy
SNOK ma status SecurityBridge Polska Premier Partner i pracuje w SAP od strony Basis, bezpieczeństwa i zgodności jednocześnie. Praktycznie oznacza to, że przegląd gotowości prowadzimy na Waszym landscape, a nie na slajdach: sześć kroków z tego wpisu przejrzanych na konkretnych systemach, zebrane dowody i lista braków z priorytetami oraz szacowanym nakładem.
Najprościej zacząć od badania SNOK KSC-CHECK - wynik dostajecie od razu, bez rozmowy z nikim. Jeśli potem chcecie przejść go na konkretnych systemach, napiszcie do nas. Rozmowa nie zobowiązuje do wdrożenia czegokolwiek.
Najczęstsze pytania
Do kiedy trzeba złożyć wniosek o wpis do wykazu KSC? Do 3 października 2026 dla podmiotów, które spełniały przesłanki w dniu wejścia ustawy w życie. Wnioski przyjmowane są od 7 maja 2026 w systemie wykaz-ksc.gov.pl. Podmioty spełniające przesłanki później mają na to sześć miesięcy od tego momentu.
Ile czasu jest na zgłoszenie incydentu poważnego? Wczesne ostrzeżenie w 24 godziny od wykrycia, zgłoszenie właściwe w 72 godziny, sprawozdanie końcowe w miesiąc. Jeżeli podmiot ma CSIRT sektorowy, zgłasza do niego, a ten przekazuje sprawę do CSIRT krajowego w ciągu 8 godzin.
Czy ustawa o KSC wymaga MFA? Dyrektywa NIS2 wymienia uwierzytelnianie wieloczynnikowe lub ciągłe wśród środków zarządzania ryzykiem (art. 21 ust. 2 lit. j), a polska ustawa nakłada obowiązek stosowania środków adekwatnych do ryzyka. Dla dostępu do systemów produkcyjnych SAP z danymi finansowymi i osobowymi drugi czynnik jest w tej logice trudny do pominięcia.
Czy SAP w modelu RISE with SAP jest objęty naszymi obowiązkami? Co do zasady tak, o ile obowiązki dotyczą Waszej organizacji jako podmiotu kluczowego albo ważnego. Odpowiedzialność jest podzielona i nie przenosi się w całości na dostawcę, a dokładny zakres monitoringu po stronie SAP wynika z Waszej umowy - w praktyce rzadko obejmuje warstwę aplikacyjną i nadużycia uprawnień, czyli dokładnie to, o co pyta audyt. Punktem wyjścia jest więc lektura umowy, nie założenie.
Kary są odroczone o dwa lata, więc czy jest pośpiech? Odroczenie dotyczy typowych kar administracyjnych, nie obowiązków - i nie obejmuje kary nadzwyczajnej ani części środków nadzorczych. Obowiązek zgłaszania incydentów działa od 3 kwietnia 2026, a pierwszy audyt podmiotów kluczowych ma się odbyć do 3 kwietnia 2028 i będzie oceniał dowody z całego okresu przejściowego.
Czy sam wpis do wykazu wystarczy? Nie. Wpis to identyfikacja podmiotu w systemie państwowym. Obowiązki merytoryczne - zarządzanie ryzykiem, obsługa incydentów, przegląd łańcucha dostaw, nadzór kierownictwa i szkolenia - obowiązują niezależnie od wpisu.
Źródła
- Ustawa z 23 stycznia 2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252 - ISAP
- Wykaz podmiotów kluczowych i ważnych, rejestracja - wykaz-ksc.gov.pl oraz komunikat Ministerstwa Cyfryzacji
- Dyrektywa NIS2 (UE) 2022/2555, art. 21 ust. 2 - EUR-Lex
- Procedura wpisu, terminy i sankcje - Traple Konarski Podrecki i Wspólnicy, Lex.pl
- Przejęcie CyberSafe i produkty TrustBroker - SecurityBridge