CRA reguluje produkt, NIS2 i wdrażająca ją znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa regulują organizację. To rozróżnienie rozstrzyga niemal wszystkie wątpliwości praktyczne: software house może nie być podmiotem kluczowym ani ważnym w rozumieniu UKSC, a jednocześnie być producentem w rozumieniu CRA — i odwrotnie. Zgłoszenia idą do różnych adresatów, różnymi kanałami i z różnych powodów: w CRA przez unijną platformę SRP do CSIRT koordynatora (w Polsce ścieżka CVD w CERT Polska / CSIRT NASK) i równolegle do ENISA, w UKSC przez system S46 do CSIRT sektorowego, a dalej do CSIRT krajowego.
Przedmiot regulacji: produkt kontra podmiot
CRA to prawodawstwo produktowe, zbudowane na tej samej logice co oznakowanie CE dla maszyn czy sprzętu elektrycznego. Adresatem obowiązku jest podmiot gospodarczy wprowadzający produkt do obrotu, a sankcją ostateczną — usunięcie produktu z rynku (art. 54–58).
NIS2 i UKSC to prawodawstwo podmiotowe. Adresatem jest organizacja zakwalifikowana do sektora i progu wielkości, a przedmiotem — zarządzanie ryzykiem, ciągłość działania i zgłaszanie incydentów w jej własnej działalności.
Analiza NASK wskazuje wprost na lukę, którą CRA zamyka: wcześniejsze akty, w tym NIS2 i akt o cyberbezpieczeństwie, nie nakładały bezpośrednio obowiązkowych wymagań bezpieczeństwa na same produkty.
Konsekwencja dla dostawcy oprogramowania jest podwójna. Jako organizacja może podlegać UKSC. Jako producent podlega CRA. A jako dostawca podmiotu kluczowego podlega jeszcze trzeciej presji — wymaganiom łańcucha dostaw swojego klienta, nakładanym kontraktem, nie ustawą.
Stan prawny w Polsce
CRA obowiązuje bezpośrednio, bez ustawy wdrażającej. Art. 14 (zgłoszenia) stosuje się od 11 września 2026 r., przepisy o notyfikacji jednostek oceniających zgodność od 11 czerwca 2026 r., pozostałe obowiązki — w tym dokumentacja techniczna i oznakowanie CE — od 11 grudnia 2027 r.
UKSC po nowelizacji — ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, ogłoszona 2 marca 2026 r. (Dz.U. 2026 poz. 252), weszła w życie 3 kwietnia 2026 r.
NIS2 jest dyrektywą, więc nie stosuje się jej bezpośrednio — wiąże przez przepisy krajowe, czyli właśnie przez UKSC.
Harmonogram wdrożenia UKSC rozciąga obowiązki w czasie: wniosek o wpis do wykazu podmiotów kluczowych i ważnych do 3 października 2026 r., wdrożenie systemu zarządzania bezpieczeństwem informacji i podłączenie do systemu S46 w ciągu 12 miesięcy od uznania za podmiot kluczowy lub ważny, pierwszy audyt podmiotów kluczowych w ciągu 24 miesięcy, a kary pieniężne — co do zasady dopiero po dwóch latach od wejścia w życie przepisów.
Rozciągnięty kalendarz sankcji nie zmniejsza liczby obowiązków. Zmniejsza wyłącznie ryzyko finansowe pierwszej fazy.
Kto w Polsce odbiera zgłoszenie
To pytanie najczęściej generuje błąd operacyjny, bo odpowiedź jest inna dla każdego reżimu.
CRA. Producent zgłasza raz, przez pojedynczą platformę sprawozdawczą prowadzoną przez ENISA na podstawie art. 16. Pierwszym odbiorcą jest CSIRT wyznaczony jako koordynator w państwie głównej siedziby producenta (art. 14 ust. 7), ENISA otrzymuje zgłoszenie równolegle. Na liście CSIRT wyznaczonych jako koordynatorzy, prowadzonej przez ENISA (aktualizacja z 10 września 2026 r.), punktem kontaktowym dla Polski jest ścieżka skoordynowanego ujawniania podatności w CERT Polska / CSIRT NASK. CSIRT, który otrzymał zgłoszenie, przekazuje je CSIRT koordynatorom państw, w których produkt jest dostępny, a następnie krajowe CSIRT przekazują niezbędny zakres informacji swoim organom nadzoru rynku.
UKSC. Zgłoszenie incydentu poważnego trafia najpierw do CSIRT sektorowego, który przekazuje je właściwemu CSIRT krajowemu — NASK, GOV albo MON — niezwłocznie, nie później niż w ciągu 8 godzin. Cała komunikacja ma przebiegać przez centralny system S46; jego nieużywanie jest sankcjonowane. CSIRT sektorowe mają zostać powołane w ciągu 18 miesięcy, z możliwością powierzenia ich zadań CSIRT krajowemu na podstawie porozumienia.
Punkt styku: CSIRT NASK jest jednocześnie krajowym koordynatorem skoordynowanego ujawniania podatności. Ta sama instytucja występuje więc w obu reżimach, ale w różnych rolach i przez różne kanały — i to kanał, nie instytucja, decyduje o skuteczności zgłoszenia.
Terminy wyglądają podobnie, liczą się inaczej
Trzy etapy w obu reżimach to zbieżność konstrukcji, nie treści.
| CRA (art. 14) | NIS2 / UKSC (art. 23 NIS2) | |
|---|---|---|
| Co się zgłasza | aktywnie wykorzystywana podatność w produkcie; poważny incydent wpływający na bezpieczeństwo produktu | incydent poważny w działalności podmiotu |
| Wczesne ostrzeżenie | 24 h od uzyskania informacji | 24 h od uzyskania informacji |
| Zgłoszenie | 72 h | 72 h |
| Sprawozdanie końcowe | podatność: 14 dni od udostępnienia środka naprawczego; incydent: 1 miesiąc od zgłoszenia | 1 miesiąc od zgłoszenia |
| Adresat | CSIRT koordynator + ENISA przez SRP | CSIRT sektorowy → CSIRT krajowy przez S46 |
Dwie różnice mają znaczenie operacyjne.
Po pierwsze, w CRA termin 14 dni dla podatności jest powiązany z dostępnością poprawki, a nie z datą zgłoszenia. Sprawa może pozostać otwarta miesiącami, a zegar ostatniego etapu ruszy dopiero w dniu wydania aktualizacji.
Po drugie, progi są inne. „Poważny incydent” w CRA definiuje art. 14 ust. 5 przez pryzmat zdolności produktu do ochrony danych i funkcji oraz wprowadzenia złośliwego kodu. „Incydent poważny” w NIS2 (art. 23 ust. 3) definiuje się przez poważne zakłócenie usług, stratę finansową podmiotu albo znaczną szkodę u innych osób. To samo zdarzenie może spełniać jeden próg i nie spełniać drugiego.
Jedno zdarzenie, dwa zgłoszenia
Scenariusz, który firmy powinny przerobić przed, nie po: polski producent oprogramowania, zakwalifikowany również jako podmiot ważny, dowiaduje się o aktywnie wykorzystywanej podatności we własnym produkcie, która jednocześnie doprowadziła do kompromitacji jego środowiska produkcyjnego.
Z CRA: wczesne ostrzeżenie w 24 h przez SRP do CSIRT NASK jako koordynatora i do ENISA, zgłoszenie w 72 h, sprawozdanie w 14 dni od wydania poprawki, plus obowiązek poinformowania użytkowników z art. 14 ust. 8.
Z UKSC: zgłoszenie incydentu poważnego przez S46 do CSIRT sektorowego w terminach wynikających z ustawy.
To dwie ścieżki, dwa zestawy pól, dwa rejestry czasu. Jeden proces zgłoszeniowy obsługujący oba reżimy jest możliwy, ale wymaga zaprojektowania — nie powstaje przez analogię.
Łańcuch dostaw: trzeci reżim, ten umowny
Dla dostawcy oprogramowania pracującego z sektorami regulowanymi największym bieżącym kosztem nie są ani CRA, ani UKSC, lecz wymagania klientów.
Podmioty kluczowe i ważne wdrażają w ramach SZBI środki obejmujące bezpieczeństwo łańcucha dostaw. Przenoszą je na dostawców kontraktem — ankietami bezpieczeństwa, zapisami o SLA na poprawki, prawem do audytu.
Nowelizacja UKSC dodaje do tego mechanizm dostawcy wysokiego ryzyka: minister właściwy ds. informatyzacji może, po opinii Kolegium ds. Cyberbezpieczeństwa, wydać decyzję eliminującą wskazany sprzęt lub oprogramowanie, z okresem wycofania 4 lat (telekomunikacja lub wykaz kategorii funkcji krytycznych) albo 7 lat (pozostałe podmioty).
CRA działa tu w drugą stronę niż się wydaje: dokumentacja techniczna z Załącznika VII, SBOM i polityka CVD są tymi samymi artefaktami, których żąda ankieta vendor assessment. Jeden zestaw dowodów obsługuje zgodność produktową i sprzedaż do sektora regulowanego.
Zasada pierwszeństwa i nadzór
CRA nie zastępuje przepisów sektorowych. Jeśli akt sektorowy zapewnia równoważny lub wyższy poziom ochrony, ma pierwszeństwo — tak jest m.in. z wyrobami medycznymi, lotnictwem, pojazdami silnikowymi (art. 2 wyłącza te kategorie z zakresu).
Nadzór nad CRA sprawują organy nadzoru rynku wyznaczone przez państwa członkowskie, współpracujące z krajowymi organami certyfikacji, CSIRT, ENISA i organami ochrony danych; każde państwo wyznacza również biuro łącznikowe. Analiza NASK nie wskazuje, który organ pełni w Polsce rolę organu nadzoru rynku dla CRA — tę informację należy weryfikować w aktualnych komunikatach Ministerstwa Cyfryzacji.
Nadzór nad UKSC pozostaje w gestii organów właściwych dla sektorów oraz ministra ds. informatyzacji prowadzącego wykaz podmiotów.
Źródła
- Rozporządzenie (UE) 2024/2847, publikacja w Dzienniku Urzędowym UE: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- Art. 14 CRA (obowiązki sprawozdawcze producentów) — lustro tekstu rozporządzenia: https://streamlex.eu/articles/cra-en-art-14/
- Art. 16 CRA (pojedyncza platforma sprawozdawcza): https://streamlex.eu/articles/cra-en-art-16/
- Dyrektywa (UE) 2022/2555 (NIS2), art. 23 (obowiązki zgłaszania): https://www.springlex.eu/en/packages/nis2/nis2-directive/article-23/
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252): https://eli.gov.pl/eli/DU/2026/252/ogl/pol
- NASK / Cyberpolicy, Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa — stan po pracach parlamentarnych: https://cyberpolicy.nask.pl/wp-content/uploads/2026/02/Nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-stan-po-pracach-parlamentarnych.pdf
- NASK / Cyberpolicy, CRA — cele i zakres regulacji: https://cyberpolicy.nask.pl/wp-content/uploads/2025/09/CRA-cele-i-zakres-regulacji-analiza-Cyberpolicy-NASK.pdf
- ENISA, List of CSIRTs Designated as Coordinators (aktualizacja 10.09.2026): https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
- ENISA, karta informacyjna SRP w języku polskim: https://www.enisa.europa.eu/sites/default/files/2026-09/ENISA_SRP_FACTSHEET_06PL.pdf
- Komisja Europejska, CRA reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- ITwiz, Nowelizacja ustawy o KSC zaczyna obowiązywać — rusza harmonogram wdrożenia NIS2 w Polsce (harmonogram terminów): https://itwiz.pl/nowelizacja-ustawy-o-ksc-zaczyna-obowiazywac-rusza-harmonogram-wdrozenia-nis2-w-polsce/
Materiał informacyjny, nie opinia prawna. Opisuje warstwę techniczną i procesową obowiązków wynikających z rozporządzenia (UE) 2024/2847, dyrektywy (UE) 2022/2555 i ustawy o krajowym systemie cyberbezpieczeństwa; pełna zgodność wymaga także działań organizacyjnych i prawnych po stronie podmiotu i nie zastępuje opinii prawnej ani formalnej oceny zgodności. Stan na październik 2026 r.