Cyber Resilience Act (CRA) – kogo dotyczy, obowiązki, terminy i kary| LBKP 

Czy aplikacja mobilna podlega CRA? Czy obowiązki obejmują również jej backend? Czy firma rozwijająca oprogramowanie na zamówienie staje się producentem w rozumieniu rozporządzenia? Cyber Resilience Act (CRA) stawia przed przedsiębiorcami nie tylko nowe wymagania techniczne, lecz przede wszystkim konieczność prawidłowego ustalenia, które produkty i podmioty rzeczywiście podlegają regulacji. Błędna kwalifikacja może prowadzić zarówno do niepotrzebnych kosztów wdrożenia, jak i pominięcia obowiązków, które już obowiązują. 

Cyber Resilience Act (CRA), czyli unijny akt o cyberodporności, wprowadza nowe wymagania w zakresie cyberbezpieczeństwa produktów z elementami cyfrowymi udostępnianych na rynku Unii Europejskiej. Obejmuje m.in. obowiązki producentów, importerów i dystrybutorów sprzętu oraz oprogramowania w zakresie bezpiecznego projektowania produktów, zarządzania podatnościami i raportowania określonych incydentów. Choć większość wymagań znajdzie zastosowanie od 11 grudnia 2027 r., obowiązki raportowania obowiązują już od 11 września 2026 r. Naruszenie przepisów może skutkować zarówno ograniczeniem możliwości sprzedaży produktów na rynku UE, jak i dotkliwymi karami finansowymi. 

Cyber Resilience Act – co to jest i od kiedy obowiązuje? 

CRA stanowi kolejny istotny element unijnych regulacji cyberbezpieczeństwa, obok dyrektywy NIS2, wdrożonej w Polsce poprzez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa (UKSC), oraz rozporządzenia DORA. W odróżnieniu od tych regulacji CRA koncentruje się przede wszystkim na bezpieczeństwie konkretnych produktów z elementami cyfrowymi, a nie tylko na cyberodporności organizacji. 

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847 weszło w życie 10 grudnia 2024 r., natomiast poszczególne obowiązki zaczynają być stosowane etapami.

 Komisja przedstawia harmonogram oparty na trzech kluczowych datach: 

• 11 czerwca 2026 r. – stosowanie przepisów rozdziału IV dotyczących jednostek oceniających zgodność. 

• 11 września 2026 r. – obowiązki nałożone m.in. na mocy art. 14 CRA. Od tego momentu producenci muszą raportować do ENISA aktywnie wykorzystywane podatności (actively exploited vulnerabilities) oraz poważne incydenty bezpieczeństwa. Obowiązek ten dotyczy również produktów, które zostały wprowadzone na rynek przed tą datą. 

• 11 grudnia 2027 r. – rozpoczęcie pełnego stosowania wszystkich wymogów rozporządzenia, w tym procedur oceny zgodności, znakowania CE oraz przepisów o karach, dla produktów z elementami cyfrowymi wprowadzanych na rynek unijny. 

Okres przejściowy  

Produkty z elementami cyfrowymi wprowadzone do obrotu przed 11 grudnia 2027 r. co do zasady nie muszą zostać retrospektywnie dostosowane do pełnych wymagań CRA. Wymagania te znajdą jednak zastosowanie, jeżeli po tej dacie produkt zostanie poddany istotnej modyfikacji. Nie oznacza to również zwolnienia dla kolejnych produktów tego samego typu lub modelu wprowadzanych do obrotu po 11 grudnia 2027 r. – co do zasady muszą one już spełniać wymagania CRA. Niezależnie od powyższego obowiązki raportowania z art. 14 CRA mają zastosowanie także do produktów wprowadzonych do obrotu przed tą datą. 

Jak sprawdzić, czy produkt podlega CRA? 

W praktyce ocena zakresu CRA wymaga sprawdzenia trzech podstawowych elementów.  

Po pierwsze czy analizowane rozwiązanie jest produktem z elementami cyfrowymi, czyli zasadniczo oprogramowaniem lub sprzętem komputerowym wraz z jego rozwiązaniami w zakresie zdalnego przetwarzania danych.  

Po drugie, czy produkt jest udostępniany na rynku Unii Europejskiej w ramach działalności handlowej – odpłatnie lub nieodpłatnie. Sam fakt nieodpłatnego udostępnienia produktu nie oznacza więc automatycznie wyłączenia z CRA.  

Po trzecie, czy jego przeznaczenie lub racjonalnie przewidywalne wykorzystanie obejmuje bezpośrednie lub pośrednie, logiczne lub fizyczne połączenie danych z urządzeniem lub siecią. 

Spełnienie tych przesłanek – z uwzględnieniem przewidzianych w CRA wyłączeń – pozwala stwierdzić, że produkt znajduje się w zakresie rozporządzenia. 

Czy aplikacja mobilna, SaaS lub aplikacja webowa podlega CRA? 

CRA może mieć zastosowanie do przedsiębiorstw z wielu sektorów gospodarki – nie tylko do klasycznych producentów oprogramowania i sprzętu. Obowiązki wynikające z rozporządzenia mogą dotyczyć m.in. banków, firm FinTech, platform e-commerce, podmiotów medycznych czy przedsiębiorstw przemysłowych, jeżeli wprowadzają lub udostępniają na rynku UE produkty z elementami cyfrowymi albo wykonują wobec nich inne czynności objęte regulacją. Samo korzystanie z oprogramowania nie oznacza automatycznie podlegania obowiązkom CRA. 

Zgodnie z unijną definicją produktów z elementami cyfrowymi, zakres przedmiotowy regulacji obejmuje w szczególności: 

• aplikacje mobilne i desktopowe (w tym aplikacje klienckie sektora bankowego, platform e-commerce, branży FinTech oraz gamedev), 

• wtyczki (plugins) oraz rozszerzenia oprogramowania, 

• oprogramowanie układowe (firmware), 

• oprogramowanie wbudowane lub dostarczane integralnie ze sprzętem (m.in. urządzenia Internetu Rzeczy – IoT, urządzenia smart home), 

• lokalnie wykonywane aplikacje oparte na technologiach webowych. 

Zgodnie z wytycznymi Komisji aplikacja mobilna, desktopowa, rozszerzenie przeglądarki czy aplikacja wykorzystująca technologie webowe, ale instalowana i wykonywana w środowisku użytkownika, może stanowić produkt z elementami cyfrowymi. Ale nie każde rozwiązanie określane biznesowo jako „aplikacja” będzie produktem objętym CRA. Inaczej należy oceniać rozwiązania wykonywane wyłącznie zdalnie i dostępne jedynie przez przeglądarkę. Typowa aplikacja webowa lub SaaS nie staje się więc zwykle samodzielnym produktem z elementami cyfrowymi. 

W praktyce – które aplikacje i rozwiązania mogą podlegać CRA? 

Rozwiązanie	Wstępna ocena
Aplikacja instalowana na smartfonie	Co do zasady może podlegać CRA
Standardowy sklep internetowy działający wyłącznie w przeglądarce	Co do zasady poza CRA jako samodzielny produkt
Aplikacja desktopowa instalowana lokalnie	Co do zasady może podlegać CRA
Własny backend niezbędny do działania aplikacji mobilnej	Może stanowić RDPS
Zewnętrzny SaaS wykorzystywany do obsługi klienta	Zasadniczo nie jest RDPS producenta, ale może wymagać uwzględnienia w analizie ryzyka
Oprogramowanie opracowane wyłącznie na potrzeby wewnętrzne	Co do zasady poza CRA, o ile nie jest udostępniane na rynku

Przedstawione przykłady mają charakter orientacyjny. Ostateczna kwalifikacja wymaga uwzględnienia funkcjonalności produktu, sposobu jego udostępniania oraz przewidzianych w CRA wyłączeń. 

Co to jest RDPS w Cyber Resilience Act? 

Rozwiązania działające zdalnie, w tym aplikacje webowe, usługi chmurowe czy backendy, mogą zostać objęte CRA jako rozwiązania w zakresie zdalnego przetwarzania danych (RDPS). Warunkiem jest jednak, aby przetwarzanie danych odbywało się na odległość, jego brak uniemożliwiał produktowi z elementami cyfrowymi wykonywanie co najmniej jednej funkcji, a wykorzystywane oprogramowanie zostało zaprojektowane i opracowane przez producenta tego produktu lub na jego odpowiedzialność. 

Nie każdy backend, serwer, system bazodanowy czy zewnętrzny SaaS automatycznie stanowi RDPS. Przykładowo, zgodnie z wytycznymi Komisji Europejskiej, w przypadku aplikacji bankowej interfejs backendowy odpowiedzialny za komunikację z aplikacją może stanowić RDPS, podczas gdy dalsze systemy zaplecza, z którymi aplikacja nie komunikuje się bezpośrednio, mogą pozostawać poza tą kwalifikacją. Podobnie zewnętrzne usługi SaaS, które nie zostały zaprojektowane i opracowane przez producenta lub na jego odpowiedzialność, zasadniczo nie stanowią RDPS, choć ich wpływ na bezpieczeństwo produktu może wymagać uwzględnienia w ocenie ryzyka cyberbezpieczeństwa. 

Kto jest producentem, importerem i dystrybutorem według CRA? 

Fundamentem prawidłowego wdrożenia wymogów Cyber Resilience Act w organizacji jest precyzyjna identyfikacja statusu prawnego, jaki dany podmiot pełni w łańcuchu. Unijny prawodawca w szczególności różnicuje obowiązki w zależności od tego, czy organizacja występuje jako: 

1. „Producent” oznacza osobę fizyczną lub prawną, która opracowuje lub wytwarza produkty z elementami cyfrowymi lub zleca zaprojektowanie, opracowanie lub wytworzenie produktów z elementami cyfrowymi i wprowadza te produkty do obrotu pod własną nazwą handlową lub znakiem towarowym, za opłatą, na zasadzie monetyzacji lub bezpłatnie. Producent odpowiada za ocenę zgodności produktu, wymagania bezpieczeństwa i raportowanie. 

2. „Importer” oznacza osobę fizyczną lub prawną, która ma miejsce zamieszkania lub siedzibę w Unii i wprowadza do obrotu produkt z elementami cyfrowymi opatrzony nazwą handlową lub znakiem towarowym osoby fizycznej lub prawnej mającej miejsce zamieszkania lub siedzibę poza granicami Unii. Musi m.in. zweryfikować spełnienie określonych wymogów CRA przez producenta. 

3. „Dystrybutor” oznacza osobę fizyczną lub prawną w łańcuchu dostaw, inną niż producent lub importer, która udostępnia produkt z elementami cyfrowymi na rynku unijnym bez zmiany jego właściwości. Musi m.in. zweryfikować określone elementy zgodności, np. oznakowanie CE i wymagane informacje. 
4. Przejęcie obowiązków producenta (Istotna modyfikacja lub zmiana marki) – rozporządzenie CRA przewiduje kluczowe zasady, w których inne podmioty stają się w świetle prawa producentami i przejmują jego obowiązki: 

• Na podstawie art. 21 CRA: Importer lub dystrybutor pełni rolę producenta, jeżeli wprowadza produkt do obrotu pod własną nazwą lub znakiem towarowym (popularny w IT model white-labeling) albo gdy dokonuje istotnej modyfikacji produktu już obecnego na rynku. 

• Na podstawie art. 22 CRA: Każdy inny podmiot (np. zewnętrzna firma integratorska, Software House), który dokonuje istotnej modyfikacji produktu i udostępnia go na rynku, również “zrównywany” z producentem i pełni jego obowiązki w tym zakresie. Obowiązki compliance obejmują wówczas część poddaną modyfikacji, a jeżeli ingerencja wpływa na cyberbezpieczeństwo produktu jako całości – rozciągają się na cały produkt. 

Co ważne, samo tworzenie oprogramowania na zamówienie lub jego techniczna integracja nie oznacza automatycznie uzyskania statusu producenta. 

Jakie obowiązki nakłada CRA na producentów? 

Wprowadzenie produktu z elementami cyfrowymi na rynek w reżimie CRA wiąże się z koniecznością spełnienia i wykazania zgodności z tzw. zasadniczymi wymogami cyberbezpieczeństwa. Działania te obejmują kilka płaszczyzn prawno-technicznych, w tym m.in.: 

• Przeprowadzenie i sformalizowanie oceny ryzyka cyberbezpieczeństwa (cybersecurity risk assessment). 

• Udokumentowane wdrożenie mechanizmów security-by-design oraz security-by-default (m.in. domyślnie bezpieczna konfiguracja produktu i minimalizacja powierzchni ataku). 

• Sporządzenie odpowiedniej dokumentacji technicznej. 

SBOM, zarządzanie podatnościami i okres wsparcia 

Do kluczowych obowiązków o charakterze techniczno-operacyjnym zaliczamy: 

• Przygotowanie i utrzymywanie informacji o komponentach produktu, w tym Software Bill of Materials (SBOM) w powszechnie używanym, maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu, oraz procesów zarządzania podatnościami komponentów third-party i open source. To nie jest dokument, który co do zasady trzeba będzie udostępniać publicznie. 

• Zapewnienie zarządzania podatnościami oraz dostarczania bezpłatnych aktualizacji zabezpieczeń przez okres odpowiadający oczekiwanemu okresowi używania produktu. Wynosi on co najmniej 5 lat, chyba że przewidywany czas używania jest krótszy. Jeżeli produkt ma być używany dłużej, okres wsparcia powinien zasadniczo też być dłuższy – 5 lat nie jest sztywnym domyślnym okresem dla każdego sprzętu i softu. 

• Zgodnie z art. 13 ust. 9 CRA aktualizacje bezpieczeństwa udostępnione użytkownikom w okresie wsparcia powinny pozostać dostępne przez co najmniej 10 lat od ich wydania albo do końca okresu wsparcia, jeśli jest dłuższy. Nie oznacza to obowiązku opracowywania nowych aktualizacji przez 10 lat. 

Producent musi również określić i zakomunikować użytkownikom końcową datę okresu wsparcia, obejmującą co najmniej miesiąc i rok. Informacja ta powinna być jasno i zrozumiale dostępna w momencie zakupu produktu. Jeżeli jest to technicznie wykonalne, użytkownik powinien także otrzymać powiadomienie o zakończeniu okresu wsparcia. 

Ocena zgodności, klasy I i II oraz oznakowanie CE 

Dla większości produktów niezakwalifikowanych jako ważne lub krytyczne dostępna będzie wewnętrzna kontrola produkcji (moduł A). W przypadku ważnych produktów klasy I samoocena jest możliwa pod określonymi warunkami, w szczególności przy zastosowaniu właściwych norm zharmonizowanych, wspólnych specyfikacji lub odpowiedniego europejskiego systemu certyfikacji cyberbezpieczeństwa. Dla ważnych produktów klasy II oraz produktów krytycznych obowiązują bardziej rygorystyczne ścieżki oceny zgodności, obejmujące udział jednostki notyfikowanej lub, gdy przepisy na to pozwalają, odpowiednią certyfikację. 

CRA przewiduje jednak szczególne ułatwienie dla wolnego i otwartego oprogramowania (FOSS). Zgodnie z art. 32 ust. 5 CRA producenci oprogramowania FOSS zakwalifikowanego jako ważny produkt klasy I lub II mogą skorzystać z samooceny zgodności (moduł A), pod warunkiem publicznego udostępnienia dokumentacji technicznej, o której mowa w art. 31 CRA, w momencie wprowadzenia produktu do obrotu. Oznacza to, że nawet ważne produkty klasy II mogą w takim przypadku zostać objęte uproszczoną procedurą oceny zgodności, bez konieczności angażowania jednostki notyfikowanej. 

Niezależnie od zastosowanej procedury, po wykazaniu zgodności produktu oraz procesów producenta z odpowiednimi wymaganiami CRA, producent sporządza deklarację zgodności UE i umieszcza oznakowanie CE. Oznakowanie to potwierdza deklarowaną przez producenta zgodność z mającymi zastosowanie wymaganiami prawa unijnego, ale samo w sobie nie oznacza uzyskania zewnętrznego certyfikatu cyberbezpieczeństwa. 

Raportowanie podatności i incydentów – 24 h, 72 h, ENISA i CSIRT NASK 

Od 11 września 2026 r. producenci mają obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów mających wpływ na bezpieczeństwo produktów z elementami cyfrowymi. Nie każdy incydent cyberbezpieczeństwa podlega zatem raportowaniu na podstawie CRA. Zgodnie z art. 14 ust. 5 CRA za poważny uznaje się w szczególności incydent, który negatywnie wpływa lub może wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności istotnych danych lub funkcji albo prowadzi lub może prowadzić do wprowadzenia lub wykonania złośliwego kodu w produkcie lub systemach użytkownika. 

Zgłoszenia dokonuje się za pośrednictwem platformy Single Reporting Platform (SRP), prowadzonej przez ENISA, do właściwego CSIRT wyznaczonego jako koordynator oraz ENISA. Dla zgłoszeń, dla których właściwa jest Polska, funkcję koordynatora pełni CSIRT NASK. Terminy raportowania są bardzo rygorystyczne: 

Etap	Aktywnie wykorzystywana podatność	Poważny incydent dotyczący bezpieczeństwa produktu
Wczesne ostrzeżenie	24 godziny	24 godziny
Zgłoszenie właściwe	72 godziny	72 godziny
Raport końcowy	Nie później niż 14 dni od udostępnienia środka naprawczego lub ograniczającego ryzyko	W ciągu miesiąca od zgłoszenia 72-godzinnego

Terminy 24 i 72 godzin biegną od momentu powzięcia przez zobowiązany podmiot wiedzy o zdarzeniu, a zgłoszenia należy dokonać bez zbędnej zwłoki. 

Niezależnie od powyższego, warto pamiętać, że: 

– zgodnie z art. 14 ust. 8 CRA producent ma również obowiązek poinformowania użytkowników dotkniętych aktywnie wykorzystywaną podatnością lub poważnym incydentem, a w odpowiednich przypadkach wszystkich użytkowników. Jeżeli jest to konieczne, informacja powinna również obejmować środki ograniczające ryzyko i działania naprawcze, które użytkownicy mogą podjąć w celu ograniczenia skutków podatności lub incydentu. 

– obowiązki raportowania mogą istnieć również po zakończeniu okresu wsparcia produktu. 

CRA a DORA, NIS2 i UKSC 

CRA nie jest zastępowany przez DORA ani NIS2 (UKSC). Regulacje te mają częściowo pokrywające się cele i wymagania, ale posługują się inną konstrukcją prawną.  

CRA jest przede wszystkim regulacją produktową – nakłada obowiązki związane z projektowaniem, wprowadzaniem na rynek i utrzymaniem bezpieczeństwa konkretnych produktów z elementami cyfrowymi (obejmuje m.in. lifecycle, zarządzanie podatnościami i supply chain).  

DORA i NIS2 koncentrują się natomiast przede wszystkim na odporności i cyberbezpieczeństwie organizacji oraz wykorzystywanych przez nie sieci i systemów informacyjnych. 

Nie oznacza to jednak konieczności budowania całego systemu compliance od zera. Wdrożenie wymagań DORA lub NIS2 może ułatwić przygotowanie organizacji do CRA, w szczególności w obszarze zarządzania ryzykiem ICT, incydentami i bezpieczeństwem dostawców. Istniejąca dokumentacja i mechanizmy kontrolne mogą zostać wykorzystane przy ocenie ryzyka w ramach CRA, jednak zgodność z DORA lub NIS2 nie oznacza automatycznie spełnienia wymogów CRA dotyczących konkretnego produktu. 

Jakie produkty są wyłączone z CRA? 

 Zakres wyjątków stosowania CRA jest ograniczony.  

CRA nie stosuje się m.in. do produktów z elementami cyfrowymi objętych regulacjami dotyczącymi wyrobów medycznych i wyrobów medycznych do diagnostyki in vitro (MDR/IVDR), niektórych produktów motoryzacyjnych, produktów certyfikowanych na podstawie regulacji dotyczących lotnictwa cywilnego oraz wyposażenia morskiego. Wyłączone są również określone identyczne części zamienne, produkty opracowane lub zmodyfikowane wyłącznie na potrzeby bezpieczeństwa narodowego lub obronności oraz produkty specjalnie zaprojektowane do przetwarzania informacji niejawnych (w rozumieniu właściwych przepisów – nie chodzi tutaj o „zwykłe” informacje poufne czy tajemnice przedsiębiorstwa). Komisja może również w drodze aktów delegowanych ograniczać stosowanie CRA do określonych produktów objętych równoważnymi przepisami sektorowymi. 

Oprogramowanie open source udostępniane poza działalnością handlową zasadniczo pozostaje poza zakresem CRA. Natomiast jego udostępnianie w ramach działalności handlowej może powodować zastosowanie obowiązków producenta. CRA przewiduje również odrębny, ograniczony reżim obowiązków dla tzw. opiekunów oprogramowania otwartego (open-source software stewards), czyli określonych podmiotów systematycznie wspierających rozwój i utrzymanie wolnego i otwartego oprogramowania przeznaczonego do celów komercyjnych. Obowiązki tych podmiotów, określone w art. 24 CRA, zaczną być stosowane od 11 grudnia 2027 r. 

Jakie kary przewiduje CRA? 

CRA przewiduje administracyjne kary pieniężne sięgające 15 mln EUR lub 2,5% całkowitego rocznego światowego obrotu przedsiębiorstwa – w zależności od tego, która kwota jest wyższa – m.in. za naruszenie zasadniczych wymagań cyberbezpieczeństwa oraz obowiązków producenta wynikających z art. 13 i 14. Inne naruszenia mogą podlegać karom do 10 mln EUR lub 2% obrotu, a przekazanie nieprawidłowych lub wprowadzających w błąd informacji – do 5 mln EUR lub 1% obrotu. Choć nie ma ogólnego zwolnienia dla mniejszych podmiotów, to administracyjna kara za niedochowanie 24-godzinnego terminu early warning nie ma zastosowania do mikro- i małych przedsiębiorstw (co nie oznacza jednak zwolnienia z obowiązku raportowania). Kary co do zasady zaczną być nakładane od 11 grudnia 2027 r. 

Jak przygotować organizację do CRA?  

Jest kilka kroków, które warto wykonać już teraz: 

1. Zidentyfikuj produkty i aplikacje udostępniane na rynku UE. 

2. Ustal, które z nich podlegają CRA i jaka jest Twoja rola. 

3. Sprawdź, czy realizujesz obowiązki raportowania obowiązujące od września 2026 r. 

4. Oceń architekturę produktów, RDPS i zależności od dostawców zewnętrznych. 

5. Zidentyfikuj luki w procesach bezpieczeństwa, dokumentacji i ocenie zgodności. 

6. Przygotuj harmonogram wdrożenia wymogów obowiązujących od grudnia 2027 r. 

Nie wiesz, które produkty Twojej organizacji podlegają CRA? 

Pomożemy Ci ustalić zakres obowiązków, zakwalifikować aplikacje, systemy i rozwiązania chmurowe oraz przygotować praktyczny plan dostosowania do Cyber Resilience Act. 

W LBKP łączymy doświadczenie prawne z analizą rzeczywistej architektury technologicznej produktów. W pierwszej kolejności weryfikujemy, czy i w jakim zakresie regulacja znajduje zastosowanie, aby ograniczyć zbędne koszty compliance i skoncentrować działania na rzeczywistych obowiązkach. 

Skontaktuj się z naszym zespołem CyberSec & FinTech, aby omówić ocenę CRA dla Twojej organizacji. 

Zespół LBKP CyberSec & FinTech świadczy dedykowane wsparcie w zakresie CRA. Bazujemy na wieloletnim doświadczeniu praktycznym w obszarze projektów regulacyjnych, w tym z zakresu wdrożeń NIS, NIS2, a także DORA. 

Co konkretnie robimy w ramach wdrożeń CRA? 

1. Mapowanie portfolio i kwalifikacja prawna produktów (Matryca CRA). Nie zaczynamy od wdrażania obowiązków CRA dla całej organizacji. Najpierw ustalamy, do których produktów i w jakim zakresie regulacja rzeczywiście ma zastosowanie. Tworzymy czytelne matryce dla właścicieli biznesowych (Product/Business Owners). Weryfikujemy czy aplikacje, urządzenia lub systemy wchodzą w zakres przedmiotowy CRA, wyłączając rozwiązania niepodlegające regulacji. 

2. Ustalenie ról w łańcuchu dostaw. Analizujemy umowy licencyjne/zakupowe, procesy wdrożeniowe i zlecenia deweloperskie, precyzyjnie określając, czy organizacja występuje jako producent, importer, dystrybutor, czy podmiot dokonujący istotnej modyfikacji oprogramowania. 

3. Audyt prawny procedur (Gap Analysis). Badamy obecne procesy zarządzania podatnościami, polityki wsparcia oprogramowania i dokumentację techniczną pod kątem tzw. wymogów zasadniczych CRA oraz weryfikujemy ich styki z dyrektywą NIS2/UKSC i rozporządzeniem DORA. 

4. Zarządzanie podatnościami i incydentami. Wspieramy klientów w opracowywaniu i wdrażaniu procedur identyfikowania, oceny i obsługi podatności oraz incydentów podlegających raportowaniu na podstawie CRA. Przygotowujemy procesy zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów za pośrednictwem platformy SRP do ENISA i właściwego CSIRT, z uwzględnieniem rygorystycznych terminów obowiązujących od 11 września 2026 r. 

5. Wsparcie w łańcuchu umów IT (Supply Chain Security). Zabezpieczamy interesy w umowach z podwykonawcami i dostawcami technologii (SLA, klauzule audytowe, gwarancje security-by-design). Odpowiednie uregulowanie łańcucha dostaw jest istotnym elementem praktycznego zarządzania ryzykiem CRA, w szczególności w zakresie aktualizacji bezpieczeństwa, obsługi podatności, zmian w komponentach, współpracy przy incydentach i dostępu do informacji potrzebnych do wykazania zgodności.