Narzędzie oceny

Ocena dojrzałości
CRA — Cyber Resilience Act

Sprawdź czy Twoje produkty z elementami cyfrowymi podlegają rozporządzeniu (UE) 2024/2847 i oceń gotowość w 8 kluczowych obszarach. Obowiązki raportowania startują 11 września 2026 r. Raport dostępny po weryfikacji danych.

🎯
Kwalifikacja
Sprawdzamy czy Twój produkt podlega CRA, w jakiej klasie i jaka procedura oceny zgodności Cię czeka
📊
Ocena dojrzałości
8 obszarów wymagań — poziomy 1–5 — od braku działań do gotowości na pełne stosowanie CRA
📋
Raport z terminami
Radar chart, priorytety, terminy CRA: 11.09.2026 (raportowanie) i 11.12.2027 (pełne obowiązki)
🔒
Weryfikacja danych
Raport dostępny po weryfikacji NIP i służbowego adresu email
⏱ Czas wypełnienia: ok. 8–12 minut  ·  🔁 Tryb: zmień na Biznes lub Techniczny (góra ekranu)  ·  💾 Dane: przetwarzane zgodnie z RODO
Krok 1 / 15 — Rola w łańcuchu dostaw
Jaka jest rola Twojej firmy wobec produktów cyfrowych, które trafiają na rynek? Wybierz rolę podmiotu gospodarczego w rozumieniu rozdz. II CRA (producent — art. 13; importer — art. 19; dystrybutor — art. 20; art. 21–22 dla white-label i istotnej modyfikacji).
🏭
Producent
Opracowujemy lub zlecamy opracowanie oprogramowania / urządzeń i wprowadzamy je na rynek pod własną marką — komercyjnie (sprzedaż, licencja, subskrypcja, model freemium z monetyzacją)
CRA — pełne obowiązki
🏷
White-label / istotna modyfikacja
Sprzedajemy cudzy produkt pod własną marką lub istotnie modyfikujemy produkt już dostępny na rynku
Traktowani jak producent (art. 21–22)
🚢
Importer
Wprowadzamy na rynek UE produkty cyfrowe producenta spoza Unii (sprzęt lub oprogramowanie)
Obowiązki art. 19
📦
Dystrybutor / reseller
Udostępniamy na rynku produkty cyfrowe innych podmiotów, bez zmian i bez własnej marki
Obowiązki art. 20
🖥
Tylko używamy produktów cyfrowych
Nie wprowadzamy ani nie udostępniamy produktów z elementami cyfrowymi na rynku — jesteśmy użytkownikiem końcowym
Prawdopodobnie poza CRA
🧩
Rozwijamy open source (niekomercyjnie)
Udostępniamy wolne i otwarte oprogramowanie poza działalnością komercyjną lub pełnimy rolę opiekuna FOSS (fundacja, community)
Reżim łagodniejszy (art. 24)
Krok 2 / 15 — Zakres produktu
Co najlepiej opisuje Wasz główny produkt? CRA obejmuje „produkty z elementami cyfrowymi" (art. 3 pkt 1): sprzęt i oprogramowanie, których używanie obejmuje bezpośrednie lub pośrednie połączenie z urządzeniem lub siecią — wraz z rozwiązaniami zdalnego przetwarzania danych. Art. 2 ust. 2–3 wyłącza produkty objęte reżimami sektorowymi.
Produkt cyfrowy łączący się z siecią lub innym urządzeniem
Oprogramowanie (aplikacje, systemy, firmware), urządzenia IoT/smart, sprzęt sieciowy, elektronika z łącznością — także komponenty sprzedawane osobno
PDE w rozumieniu art. 3 pkt 1 CRA, w tym remote data processing (art. 3 pkt 2) i komponenty wprowadzane do obrotu odrębnie
Czysta usługa chmurowa (SaaS / PaaS / IaaS)
Świadczymy usługę w chmurze — klient nie instaluje naszego produktu, korzysta wyłącznie przez przeglądarkę/API
Usługi przetwarzania w chmurze bez powiązania z konkretnym PDE — reżim NIS2, nie CRA (motyw 12); uwaga: remote data processing powiązane z produktem JEST w zakresie CRA
Produkt objęty regulacjami sektorowymi
Wyroby medyczne, pojazdy (homologacja), lotnictwo cywilne, wyposażenie morskie, wyłącznie cele obronności / bezpieczeństwa narodowego
Wyłączenia art. 2 ust. 2–3: MDR 2017/745 / IVDR 2017/746, homologacja 2019/2144, lotnictwo 2018/1139, wyposażenie morskie 2014/90, obronność / informacje niejawne
Nie jestem pewien
Trudno mi ocenić, czy nasz produkt łapie się w zakres — chcę to zweryfikować w ocenie
Kontynuujemy ocenę z założeniem objęcia zakresem; klasyfikację zweryfikuje raport i ew. konsultacja
Krok 3 / 15 — Klasa produktu
Która kategoria najlepiej opisuje Wasz produkt? Od tego zależy, jak rygorystycznie będzie oceniana zgodność. Klasyfikacja wg załączników III (klasa I / II) i IV (krytyczne) CRA, doprecyzowana opisami technicznymi w rozporządzeniu wykonawczym (UE) 2025/2392. Decyduje podstawowa funkcjonalność produktu (art. 7–8).
Produkt „zwykły" (kategoria domyślna)
Typowe aplikacje i urządzenia: aplikacje biznesowe, gry, smart-AGD, elektronika użytkowa, oprogramowanie branżowe — bez funkcji bezpieczeństwa i bez roli krytycznej
Poza wykazami zał. III/IV — samoocena zgodności (moduł A) na podstawie zasadniczych wymagań zał. I
Produkt ważny — klasa I
M.in.: menedżery haseł, antywirusy, VPN-y, przeglądarki, systemy smart home z funkcjami bezpieczeństwa, zabawki z łącznością, osobiste urządzenia noszone (wearables), routery konsumenckie, mikrokontrolery/mikroprocesory ogólnego przeznaczenia
Zał. III klasa I wg opisów technicznych 2025/2392: funkcjonalność zarządzania tożsamością, VPN, przeglądarki, bootloadery, menedżery haseł, malware detection, smart home security, IoT konsumenckie z funkcją bezpieczeństwa
Produkt ważny — klasa II
M.in.: firewalle i systemy wykrywania włamań, hypervisory/wirtualizacja, systemy operacyjne, mikroprocesory z funkcjami bezpieczeństwa, manipulacjoodporne mikrokontrolery
Zał. III klasa II: OS-y, hypervisory i container runtime, firewalle / IDS / IPS, tamper-resistant MCU/MPU — obowiązkowy udział jednostki notyfikowanej (moduł B+C lub H)
Produkt krytyczny
Sprzętowe moduły bezpieczeństwa, urządzenia z funkcją bezpiecznego elementu, inteligentne liczniki (smart meters), karty inteligentne i podobne
Zał. IV: HSM, secure elements, smart meter gateways, smart cards — docelowo obowiązkowa certyfikacja w europejskim programie (EUCC) po akcie delegowanym art. 8
Nie wiem / mamy różne produkty
Portfolio zawiera różne kategorie lub nie potrafię jednoznacznie przypisać klasy
Klasyfikacja per produkt do ustalenia analizą podstawowej funkcjonalności względem 2025/2392 — raport wskaże metodę
Krok 4 / 15 — Wynik kwalifikacji
Profil organizacji — gotowość do wdrożenia
Te informacje pomogą nam oszacować realistyczny harmonogram dostosowania Waszych produktów do wymagań CRA. Dane o zasobach product security umożliwią wyliczenie ścieżki krytycznej do 11.09.2026 (art. 14) i 11.12.2027 (pełne stosowanie).
A. Kto odpowiada za bezpieczeństwo Waszych produktów (product security)?
Dedykowany zespół / osoba product security (PSIRT)
Funkcja odpowiedzialna wprost za bezpieczeństwo produktów i obsługę podatności
Wyznaczona osoba z częściowym zakresem
CISO, IT Manager lub Compliance Officer z bezpieczeństwem produktów jako jednym z zadań
Ktoś robi to "przy okazji"
Deweloperzy lub dział IT zajmują się tym bez formalnego przydziału
Nikt nie jest wyznaczony
Brak osoby odpowiedzialnej za bezpieczeństwo produktów
B. Ile czasu tygodniowo można przeznaczyć na dostosowanie do wymagań CRA?
Ponad 20h tygodniowo
Dedykowany projekt — priorytet organizacyjny
10–20h tygodniowo
Znaczące zasoby, projekt realizowany równolegle z innymi zadaniami
5–10h tygodniowo
Ograniczone zasoby, wdrożenie jako zadanie dodatkowe
Poniżej 5h tygodniowo
Minimalne zasoby — wdrożenie będzie bardzo rozciągnięte w czasie
C. Jakie są wewnętrzne kompetencje w zakresie bezpieczeństwa produktów i zgodności?
Posiadamy pełne kompetencje
Doświadczenie w ISO 27001, audycie, compliance — możemy działać samodzielnie
Mamy częściowe kompetencje
Znamy temat ogólnie, ale brakuje nam doświadczenia w szczegółach wdrożenia
Brak kompetencji w tym obszarze
Potrzebujemy zewnętrznego prowadzenia projektu
D. Czy planujecie zewnętrzne wsparcie konsultingowe przy wdrożeniu?
Mamy zakontraktowanego konsultanta / vCISO
Zewnętrzny ekspert jest już zaangażowany w projekt
Planujemy zatrudnić konsultanta
Decyzja podjęta, trwają lub planowane są poszukiwania
Rozważamy, ale jeszcze nie zdecydowaliśmy
Zależy od budżetu i wyników tej oceny
Działamy samodzielnie
Wdrożenie wyłącznie zasobami wewnętrznymi
E. Jak oceniasz zaangażowanie zarządu w zgodność produktów z CRA?
Zarząd aktywnie sponsoruje projekt
Cyberbezpieczeństwo jest priorytetem, decyzje zapadają szybko, budżet zabezpieczony
Zarząd wspiera, ale decyzje wymagają czasu
Pozytywne nastawienie, standardowy proces decyzyjny
Zarząd jest świadomy, ale projekt nie jest priorytetem
Temat jest znany, ale konkuruje z innymi inicjatywami
Zarząd nie jest zaangażowany
Projekt realizowany bez aktywnego wsparcia i sponsorowania przez kierownictwo
Krok 15a / 16 — Pytania uzupełniające
Trzy szybkie pytania o formalności CRA

Trzy obowiązki, które najczęściej decydują o gotowości na CRA. Odpowiedzi trafią do raportu — pomogą wskazać konkretne braki formalne. Trzy pytania kontrolne: art. 14 CRA (zgłoszenia 24h/72h przez Single Reporting Platform ENISA — obowiązek od 11.09.2026, także dla produktów już na rynku), zał. I cz. II pkt 1 (SBOM) oraz art. 13 ust. 8 i 19 (okres wsparcia i jego komunikacja).

PYTANIE 1 z 3 · ART. 14 CRA · OD 11.09.2026
Czy jesteście gotowi zgłosić aktywnie wykorzystywaną podatność lub poważny incydent w 24 godziny?
Mamy proces i znamy ścieżkę zgłoszeń
Procedura 24h/72h wdrożona, zidentyfikowany CSIRT-koordynator i platforma SRP
Częściowo
Obsługujemy incydenty wewnętrznie, ale bez ścieżki zgłoszeń CRA i przećwiczonych terminów
Planujemy w najbliższym czasie
Wiemy o obowiązku, przygotowania w toku
Jeszcze nie zaczęliśmy
Sprawa nie jest w toku
Nie wiem / nie jestem pewien
Sprawdzimy przy okazji raportu
Nie dotyczy
Nie jesteśmy producentem (importer/dystrybutor bez tego obowiązku)
PYTANIE 2 z 3 · ZAŁ. I CZ. II PKT 1 CRA
Czy generujecie SBOM (wykaz komponentów) dla swoich produktów?
Tak, dla wszystkich produktów
SBOM w formacie maszynowym (CycloneDX/SPDX), utrzymywany per wersja
Dla części produktów
SBOM istnieje dla wybranych produktów lub w formie nieustrukturyzowanej
Nie generujemy
Skład komponentów znany tylko z plików zależności / dokumentacji dev
Nie wiem
Muszę sprawdzić z zespołem inżynierskim
Nie dotyczy
Nie jesteśmy producentem
PYTANIE 3 z 3 · ART. 13 UST. 8 i 19 CRA
Czy macie zadeklarowany okres wsparcia produktów (min. 5 lat) i komunikujecie klientom datę jego końca?
Tak, dla wszystkich produktów
Okres zdefiniowany, data końca (miesiąc+rok) widoczna przy zakupie
Dla części produktów
Niektóre produkty mają zdefiniowany EOL/EOS, brak spójnej polityki
Mamy wewnętrznie, nie komunikujemy
Zakładany czas wsparcia istnieje, ale klient go nie zna
Nie mamy zdefiniowanego
Wspieramy produkty, dopóki to zasadne biznesowo
Nie wiem
Nie znam statusu
Nie dotyczy
Nie jesteśmy producentem
Krok 15 / 15 — Dane kontaktowe i weryfikacja
Podaj dane aby odblokować raport
🔒 Dlaczego weryfikujemy dane?
Raport zawiera ocenę poziomu bezpieczeństwa Twojej organizacji. Aby zapewnić że trafi tylko do uprawnionych osób, weryfikujemy NIP firmy (przez bazy GUS) oraz potwierdzamy służbowy adres email kodem jednorazowym.
Weryfikacja przez rejestr GUS/REGON
Prosimy o służbowy adres — nie akceptujemy gmail, yahoo, wp, onet itp.
Wymagana zgoda na przetwarzanie danych osobowych.
Regulacje sektorowe — wyłączenie z CRA
Twój produkt podlega przede wszystkim reżimowi sektorowemu

Na podstawie art. 2 ust. 2–3 rozporządzenia CRA, produkty objęte regulacjami sektorowymi — wyroby medyczne (MDR/IVDR), pojazdy podlegające homologacji, lotnictwo cywilne (EASA), wyposażenie morskie oraz produkty opracowane wyłącznie do celów obronności lub przetwarzania informacji niejawnych — nie podlegają CRA albo podlegają mu tylko częściowo.

Wymagania cyberbezpieczeństwa dla Twojego produktu wynikają z przepisów sektorowych — np. MDR art. 17 i wytyczne MDCG 2019-16 dla wyrobów medycznych, UNECE R155/R156 dla pojazdów
Komponenty Waszego produktu kupowane na rynku (moduły łączności, oprogramowanie ogólnego przeznaczenia) mogą same podlegać CRA — warto tego wymagać od dostawców
Jeżeli macie w portfolio także produkty poza reżimem sektorowym — te podlegają CRA normalnie i możecie dla nich wykonać tę ocenę
Jako organizacja możecie równolegle podlegać NIS2/UKSC — sprawdź naszą ocenę dojrzałości UKSC/NIS2
Wróć na stronę główną →
Wynik kwalifikacji
Prawdopodobnie poza zakresem CRA

Na podstawie podanych informacji Twoja organizacja prawdopodobnie nie podlega bezpośrednim obowiązkom wynikającym z rozporządzenia (UE) 2024/2847 (Cyber Resilience Act).

Jako organizacja możesz podlegać NIS2/UKSC (obowiązki podmiotu, nie produktu) — sprawdź naszą ocenę UKSC/NIS2
Kupując produkty cyfrowe, od 11.12.2027 możesz wymagać od dostawców oznakowania CE wg CRA — to argument w negocjacjach zakupowych
Jeżeli zaczniecie sprzedawać własne oprogramowanie lub urządzenia (także white-label), obowiązki CRA obejmą Was jako producenta
Każda firma przetwarzająca dane osobowe podlega RODO — niezależnie od zakresu CRA
Masz pytania dotyczące klasyfikacji?

Przepisy mogą być niejednoznaczne. Nasi eksperci pomogą ocenić Twoją sytuację.