Cyber Resilience Act a oprogramowanie dedykowane: czy projekt na zamówienie podlega CRA i co wykonawca musi dostarczyć do 11 września 2026

Kiedy CRA obejmuje projekt tworzony dla jednego klienta

Rozporządzenie (UE) 2024/2847, czyli Cyber Resilience Act, weszło w życie 10 grudnia 2024 i obejmuje produkty z elementami cyfrowymi na rynku UE. Kluczowe jest jedno rozróżnienie: o zakresie nie decyduje to, czy kod powstał dla jednego odbiorcy, tylko czy produkt zostaje udostępniony na rynku w ramach działalności handlowej. Rozporządzenie nie przewiduje wyłączenia dla oprogramowania szytego na miarę, więc Cyber Resilience Act a oprogramowanie na zamówienie to pytanie o dostarczenie, nie o stopień personalizacji.

Tu kryje się najczęstszy skrót myślowy zamawiających. Udostępnienie na rynku to każde dostarczenie produktu do dystrybucji lub użytku w Unii w ramach działalności handlowej — odpłatnie lub nieodpłatnie. Wydanie zamawiającemu dedykowanego systemu przez wykonawcę zwykle mieści się w tej definicji, więc zdanie „to projekt na zamówienie, więc nas nie dotyczy” nie jest argumentem. Poza zakresem pozostaje zasadniczo oprogramowanie budowane przez organizację we własnym zespole na własny użytek i nikomu niedostarczane, bo wtedy w ogóle nie dochodzi do udostępnienia.

Drugie pytanie brzmi: kto jest producentem, czyli kto wprowadza produkt do obrotu pod własną nazwą lub znakiem towarowym. Jeśli zamawiający wbudowuje efekt prac w produkt, urządzenie albo aplikację, którą sam oferuje klientom, to on przyjmuje rolę producenta i komplet obowiązków. Osobno traktowane są usługi: aplikacja używana wyłącznie przez przeglądarkę zasadniczo nie jest produktem z elementami cyfrowymi, ale rozwiązania zdalnego przetwarzania danych niezbędne do pełnienia funkcji przez produkt — już tak.

Ten artykuł ma charakter informacyjny i nie jest poradą prawną. Kwalifikację konkretnego projektu rozstrzyga doradca prawny zamawiającego; my wspieramy zgodność od strony technicznej i procesowej.

Test kwalifikacji w pięciu pytaniach

Pięć pytań poniżej pozwala wstępnie ustawić projekt, zanim wejdziesz w tekst rozporządzenia:

1. Czy efekt prac trafia do kogokolwiek poza zespół, który go zbudował — odpłatnie lub nieodpłatnie?
2. Czy zamawiający oferuje go dalej pod własną nazwą lub znakiem towarowym, samodzielnie albo jako część swojego produktu?
3. Czy oprogramowanie ma bezpośrednie lub pośrednie połączenie z siecią albo z danymi?
4. Czy część kodu wykonuje się na urządzeniu użytkownika (aplikacja, klient, firmware), czy wyłącznie po stronie usługi?
5. Czy potrafisz dziś wskazać wersje wszystkich bibliotek open source użytych w projekcie?

Odpowiedź „tak” na pytanie 1 lub 2 oznacza, że temat jest w tym projekcie realny i wymaga rozstrzygnięcia prawnego przed podpisaniem umowy. Odpowiedź „nie” na pytanie 5 wskazuje, gdzie zaczyna się praca techniczna: od inwentaryzacji komponentów, bo bez niej nie powstanie ani SBOM, ani sensowna ocena ryzyka.

Co zmienia 11 września 2026

Artykuł 14 rozporządzenia CRA obowiązuje od 11 września 2026 i wymaga wczesnego ostrzeżenia w ciągu 24 godzin od powzięcia wiedzy o podatności. Pełniejsze zgłoszenie idzie w ciągu 72 godzin, a raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Dla poważnych incydentów wpływających na bezpieczeństwo produktu terminy 24 i 72 godzin są analogiczne, a raport końcowy składa się w ciągu miesiąca. Obowiązek dotyczy aktywnie wykorzystywanych podatności i poważnych incydentów, a nie każdego wpisu w rejestrze błędów.

Zgłoszenie składa się elektronicznie przez platformę prowadzoną przez ENISA, do zespołu CSIRT wyznaczonego jako koordynator w państwie głównej siedziby producenta. W Polsce jednym z zespołów CSIRT poziomu krajowego jest CSIRT NASK — konkretnego adresata i ścieżkę zgłoszenia warto potwierdzić, zanim będzie potrzebna, a nie w 24. godzinie.

Pozostałe obowiązki producenta z CRA zaczynają obowiązywać 11 grudnia 2027, a przepisy o jednostkach oceniających zgodność weszły 11 czerwca 2026. Rok 2026 jest więc oknem na przygotowanie procesu, nie na jego uruchomienie w dniu pierwszego incydentu. Okno 24 godzin to zobowiązanie operacyjne, nie zapis w polityce: ktoś musi odebrać zgłoszenie w sobotę, ocenić je i przygotować treść wysyłki.

Czego żądać od wykonawcy — lista do umowy

Ta lista nadaje się do skopiowania wprost do zapytania ofertowego i do załącznika umownego:

• SBOM w formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu;
• dokumentacja techniczna wraz z oceną ryzyka cyberbezpieczeństwa i wskazaniem zastosowanych norm;
• udokumentowany proces obsługi podatności: przyjmowanie zgłoszeń, naprawa, komunikat do użytkowników;
• deklarowany okres wsparcia oraz ścieżka dostarczania aktualizacji bezpieczeństwa;
• zobowiązanie do współpracy w oknach 24 godzin, 72 godzin i 14 dni, z nazwaną osobą po stronie wykonawcy;
• ustalenie, kto występuje jako producent, jeśli produkt trafia dalej pod nazwą zamawiającego;
• zasady przekazania kodu, praw i dokumentacji na wypadek zakończenia współpracy.

Okres wsparcia w CRA wynosi co najmniej 5 lat, chyba że przewidywany czas użytkowania produktu jest krótszy. Umowa, która milczy o wsparciu i o SBOM-ie, po prostu przenosi ten koszt na zamawiającego — najczęściej w momencie, w którym jest on najdroższy, czyli po zgłoszeniu podatności.

Kto odpowiada, gdy twój kod jest komponentem w cudzym produkcie

Producent produktu końcowego odpowiada za komponenty pochodzące od stron trzecich, w tym za biblioteki open source, i musi wykazać należytą staranność wobec dostawców. Dokumentacja techniczna ma to udowadniać, a nie deklarować. Praktyczny skutek dla rynku jest prosty: wymagania spływają w dół łańcucha dostaw — od producenta do software house’u, który pisał kod. Dlatego rozmowa o CRA należy do etapu ustalania zakresu, a nie do protokołu odbioru.

Od strony prowadzenia projektu wygląda to tak: dyscyplina sprawdzonych metodyk (PRINCE2, Agile, IPMA) plus jasno przypisana odpowiedzialność za rezultat — u nas technologia idzie w parze z dyscypliną PMO. W kontekście CRA jasno przypisana odpowiedzialność znaczy dosłownie: jedna osoba z nazwiskiem, która w niedzielę wieczorem odbierze telefon o aktywnie wykorzystywanej podatności i będzie wiedziała, co dalej.

Skala projektów w doświadczeniu zespołu

Doświadczenie zespołu obejmuje projekty m.in. dla Komendy Głównej Państwowej Straży Pożarnej — system dla 22 000 użytkowników, przy budżecie projektu 20,3 mln zł. Formuła jest tu istotna i celowa: mówimy o doświadczeniu z projektów dla wymienionych organizacji, a nie o liście klientów Primessio.

Zespół ma ponad 20 lat doświadczenia, 50+ zrealizowanych projektów i prowadził zespoły od 5 do 75 osób. Mamy siedzibę w Warszawie, a obszar działania to Warszawa i województwo mazowieckie oraz rynek niemieckojęzyczny. Reżim, w którym awaria ma realne konsekwencje, nie jest dla nas nowy — a okno 24 godzin wymaga dokładnie takiej dyscypliny operacyjnej.

Nie gwarantujemy zgodności z prawem i nie zastępujemy doradcy prawnego. Wspieramy zgodność tam, gdzie da się ją zbudować inżyniersko: inwentaryzacja komponentów, dokumentacja techniczna, proces obsługi podatności i gotowość operacyjna na zgłoszenie w 24 godziny.

Co dalej z twoim projektem

Przejdź test pięciu pytań z tego artykułu i wyślij nam swoje odpowiedzi razem z krótkim opisem projektu — na ich podstawie przejdziemy z Tobą listę dostaw do umowy, pozycja po pozycji. Rozmawiamy o celu i ograniczeniach projektu, nie o gotowych pakietach. Napisz na info@primessio.com, skorzystaj z formularza kontaktowego albo zadzwoń: +48 506 038 327. Odezwiemy się w 24 h.

Stan na 17 sierpnia 2026. Daty i terminy pochodzą z rozporządzenia (UE) 2024/2847 oraz z materiałów Komisji Europejskiej poświęconych Cyber Resilience Act. Autor: Dariusz Wtykło, właściciel i CEO Primessio (PRINCE2, Agile, IPMA).

Najczęstsze pytania

Czy Cyber Resilience Act dotyczy oprogramowania tworzonego na zamówienie?

Rozporządzenie nie zawiera wyłączenia dla oprogramowania dedykowanego. O zakresie decyduje udostępnienie na rynku UE, czyli każde dostarczenie produktu do dystrybucji lub użytku w ramach działalności handlowej — odpłatnie lub nieodpłatnie. Wydanie zamawiającemu systemu zbudowanego przez wykonawcę zwykle mieści się w tej definicji. Poza zakresem pozostaje zasadniczo oprogramowanie tworzone przez organizację we własnym zespole na własny użytek i nikomu niedostarczane. Kwalifikację konkretnego przypadku rozstrzyga doradca prawny — to nie jest porada prawna.

Od kiedy obowiązuje Cyber Resilience Act?

Rozporządzenie (UE) 2024/2847 weszło w życie 10 grudnia 2024. Przepisy o jednostkach oceniających zgodność zaczęły obowiązywać 11 czerwca 2026. Obowiązki zgłoszeniowe z artykułu 14 obowiązują od 11 września 2026. Pozostałe obowiązki producenta będą stosowane od 11 grudnia 2027.

Ile czasu ma producent na zgłoszenie podatności w CRA?

Wczesne ostrzeżenie o aktywnie wykorzystywanej podatności składa się w ciągu 24 godzin od powzięcia wiedzy. Pełniejsze zgłoszenie idzie w ciągu 72 godzin, a raport końcowy w ciągu 14 dni od udostępnienia środka naprawczego. Dla poważnych incydentów wpływających na bezpieczeństwo produktu terminy 24 i 72 godzin są analogiczne, a raport końcowy składa się w ciągu miesiąca. Zgłoszenie idzie elektronicznie przez platformę prowadzoną przez ENISA, do zespołu CSIRT wyznaczonego jako koordynator w państwie głównej siedziby producenta; w Polsce jednym z zespołów CSIRT poziomu krajowego jest CSIRT NASK — adresata potwierdź przed pierwszym zgłoszeniem.

Czy SaaS podlega Cyber Resilience Act?

Sama usługa używana wyłącznie przez przeglądarkę zasadniczo nie jest produktem z elementami cyfrowymi. Inaczej wygląda oprogramowanie wykonujące się na urządzeniu użytkownika — aplikacja, klient desktopowy, rozszerzenie, firmware. Objęte są też rozwiązania zdalnego przetwarzania danych, które są niezbędne do tego, aby produkt pełnił swoje funkcje.

Kto odpowiada za komponenty open source w produkcie objętym CRA?

Odpowiada producent produktu końcowego, także za biblioteki i moduły pochodzące od stron trzecich. Musi wykazać należytą staranność wobec dostawców, a dokumentacja techniczna ma to udowadniać, nie deklarować. W praktyce oznacza to inwentaryzację komponentów z wersjami i SBOM w formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu.

Jak długo trzeba zapewniać aktualizacje bezpieczeństwa według CRA?

Okres wsparcia wynosi co najmniej 5 lat, chyba że przewidywany czas użytkowania produktu jest krótszy. Przez ten czas producent dostarcza aktualizacje bezpieczeństwa i prowadzi udokumentowany proces obsługi podatności. Dlatego deklarowany okres wsparcia i ścieżka dostarczania aktualizacji powinny znaleźć się w umowie z wykonawcą, a nie w ustaleniach ustnych.

Powiązana usługa: Oprogramowanie i systemy IT →

Zobacz też

Oprogramowanie i systemy IT →Zarządzanie projektami →Software house dla DACH →Dedykowane oprogramowanie vs gotowe — kiedy się opłaca? →