Ten artykuł zamyka cykl o akcie o cyberodporności (CRA); punkt wyjścia znajdziesz we wprowadzeniu do CRA. CRA nie działa w próżni — wpisuje się w gęstą siatkę unijnych regulacji cyberbezpieczeństwa. Zrozumienie granic między nimi pozwala uniknąć podwójnej pracy i luk w zgodności.
Czym różni się CRA od NIS2 i DORA?
CRA reguluje bezpieczeństwo samego produktu, a NIS2 i DORA — bezpieczeństwo organizacji, które takich produktów używają.
To najważniejsze rozróżnienie w całym cyklu. CRA adresuje obowiązki do producenta produktu z elementami cyfrowymi. NIS2 (dyrektywa (UE) 2022/2555) i DORA (rozporządzenie (UE) 2022/2554) adresują obowiązki do organizacji — odpowiednio podmiotów kluczowych i ważnych oraz podmiotów finansowych. Ten sam router może więc być jednocześnie przedmiotem obowiązków producenta z CRA i elementem infrastruktury podmiotu objętego NIS2.
- CRA — bezpieczeństwo produktu
- Wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi wprowadzanych na rynek; adresat: producent (oraz importer, dystrybutor).
- NIS2 — bezpieczeństwo organizacji
- Środki zarządzania ryzykiem w cyberprzestrzeni dla podmiotów kluczowych i ważnych; adresat: organizacja.
- DORA — odporność operacyjna sektora finansowego
- Zarządzanie ryzykiem ICT, incydentami i dostawcami zewnętrznymi w sektorze finansowym; adresat: podmiot finansowy.
Jak CRA łączy się z NIS2?
CRA i NIS2 uzupełniają się: NIS2 może wymagać od organizacji stosowania produktów spełniających określone wymagania cyberbezpieczeństwa, które domyka CRA.
Zgodnie z motywem 13 środki na rzecz bezpieczeństwa łańcucha dostaw przewidziane w NIS2 mogą wymagać od podmiotów kluczowych i ważnych stosowania produktów spełniających bardziej rygorystyczne wymagania cyberbezpieczeństwa. Granicę wyznacza też zakres: usługi w chmurze w modelu SaaS, PaaS i IaaS podlegają NIS2, a nie CRA (motyw 12) — o czym piszemy w artykule Kogo dotyczy CRA.
Jeśli Twoja organizacja podlega NIS2, więcej o zakresie podmiotowym i obowiązkach znajdziesz w cyklu o krajowym systemie cyberbezpieczeństwa. Warto zacząć od artykułu Ustawa o KSC po 3 kwietnia 2026 r. — co naprawdę się zmieniło, a następnie przejrzeć jak ustalić swój status jako podmiot kluczowy lub ważny. Kluczowe jest też zrozumienie 14 obszarów systemu zarządzania bezpieczeństwem informacji, a w kontekście raportowania — terminy zgłaszania incydentów poważnych w KSC. System kar po stronie NIS2 opisuje artykuł Kary i nadzór w KSC.
Jak CRA odnosi się do DORA?
CRA reguluje produkty, a DORA — operacyjną odporność cyfrową podmiotów finansowych, które tych produktów używają.
Podmiot finansowy objęty DORA odpowiada za zarządzanie ryzykiem ICT na poziomie organizacji, w tym za ryzyko dostawców. Produkty z elementami cyfrowymi, których używa, mogą być objęte CRA po stronie ich producentów. Te dwa reżimy spotykają się więc w łańcuchu dostaw. Wprowadzenie do DORA zawiera artykuł DORA — wprowadzenie do unijnego rozporządzenia o operacyjnej odporności cyfrowej, a kwestię ram zarządzania ryzykiem ICT rozwija artykuł Ramy zarządzania ryzykiem ICT pod DORA. W kontekście łańcucha dostaw kluczowy jest też artykuł Outsourcing ICT pod DORA.
Jak CRA odnosi się do aktu w sprawie sztucznej inteligencji?
Dla produktów będących systemami AI wysokiego ryzyka CRA i akt w sprawie sztucznej inteligencji są ze sobą powiązane przez wspólną ocenę zgodności.
Produkty z elementami cyfrowymi sklasyfikowane jako systemy sztucznej inteligencji wysokiego ryzyka podlegają jednocześnie aktowi w sprawie sztucznej inteligencji — rozporządzeniu (UE) 2024/1689. CRA przewiduje, że dla takich produktów ocenę zgodności w zakresie wymagań cyberbezpieczeństwa przeprowadza się w odpowiedniej procedurze przewidzianej w art. 43 rozporządzenia (UE) 2024/1689. Chodzi o uniknięcie podwójnej oceny tego samego produktu. Klasyfikację systemów AI wyjaśnia artykuł Systemy AI wysokiego ryzyka — klasyfikacja z art. 6 i załącznika III, a ogólny przegląd regulacji zawiera AI Act 2024/1689 — przewodnik dla firm.
Jak CRA odnosi się do ogólnego bezpieczeństwa produktów?
Aspekty bezpieczeństwa produktu nieobjęte CRA domyka rozporządzenie o ogólnym bezpieczeństwie produktów.
Zgodnie z art. 11 CRA do produktów z elementami cyfrowymi — w odniesieniu do ryzyka nieobjętego CRA — stosuje się odpowiednio wskazane rozdziały rozporządzenia (UE) 2023/988. CRA zajmuje się więc cyberbezpieczeństwem, a ogólny reżim produktowy domyka pozostałe ryzyka.
Jak możemy Ci pomóc?
W Legal Geek mapujemy, które z regulacji — CRA, NIS2, DORA, akt w sprawie AI — dotyczą Twojej organizacji i Twoich produktów, oraz jak ułożyć zgodność, żeby nie dublować pracy. Dla firm działających na styku produktu i usługi to często najtrudniejsza, a zarazem najbardziej opłacalna analiza.
Co dalej w cyklu?
- Akt o cyberodporności (CRA) — wprowadzenie
- Kogo dotyczy CRA — czym jest „produkt z elementami cyfrowymi"
- Obowiązki producentów i okres wsparcia
- Nadzór rynku i kary za naruszenie CRA
- Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów
Powiązane artykuły
- Ustawa o KSC po 3 kwietnia 2026 r. — co naprawdę się zmieniło
- Podmiot kluczowy czy podmiot ważny? Jak ustalić swój status w KSC po nowelizacji 2026
- Art. 8 KSC w praktyce — 14 obszarów systemu zarządzania bezpieczeństwem informacji
- Zgłaszanie incydentów poważnych w KSC — terminy 24h, 72h i 1 miesiąc w praktyce
- Kary i nadzór w KSC — od 20 tys. zł po 100 mln zł, z odpowiedzialnością osobistą kierownika
- DORA — wprowadzenie do unijnego rozporządzenia o operacyjnej odporności cyfrowej
- Ramy zarządzania ryzykiem ICT pod DORA — pierwszy filar (art. 6–15)
- Outsourcing ICT pod DORA — czwarty filar i zasady ogólne (art. 28–30)
- AI Act 2024/1689 — przewodnik dla firm
- Systemy AI wysokiego ryzyka — klasyfikacja z art. 6 i załącznika III