CRA i RODO po 11 września 2026: jak obsługiwać komunikaty producentów o incydentach?

Od 11 września 2026 r. stosuje się art. 14 aktu o cyberodporności (CRA), obejmujący określone obowiązki zgłoszeniowe producentów produktów z elementami cyfrowymi. Dla firmy korzystającej z takiego produktu komunikat o aktywnie wykorzystywanej podatności albo poważnym incydencie jest sygnałem do szybkiej, udokumentowanej oceny. Nie potwierdza automatycznie naruszenia ochrony danych osobowych, ale nie powinien też pozostawać bez reakcji.

Stan informacji: 14 września 2026 r. Informacje o rozpoczęciu stosowania art. 14 CRA i jego relacji z RODO oparto na komunikacie UODO z 11 września 2026 r. Poniższa ścieżka operacyjna jest rekomendacją organizacyjną, a nie pełnym wykazem obowiązków prawnych.

Co zmienił art. 14 CRA

Akt o cyberodporności, czyli rozporządzenie UE 2024/2847, dotyczy produktów z elementami cyfrowymi. Według komunikatu UODO od 11 września 2026 r. stosuje się art. 14 tego aktu, odnoszący się między innymi do zgłaszania przez producentów aktywnie wykorzystywanych podatności oraz poważnych incydentów mających wpływ na bezpieczeństwo produktu.

UODO opisuje wczesne ostrzeżenie w ciągu 24 godzin oraz zgłoszenie w ciągu 72 godzin od momentu, w którym producent dowiedział się o podatności lub incydencie. To skrót mechanizmu zgłoszeniowego producenta, a nie pełna instrukcja realizacji wszystkich obowiązków CRA. Nie należy też utożsamiać tych terminów z terminem przekazania każdej wiadomości użytkownikowi produktu.

Firma korzystająca z rozwiązania powinna ustalić, czy komunikat dotyczy jej środowiska i wymaga zabezpieczenia systemów lub danych. Otrzymanie alertu nie przenosi na nią obowiązków producenta. Może jednak dostarczyć informacji istotnych dla jej własnych obowiązków, w tym wynikających z RODO.

Dlaczego alert nie przesądza o naruszeniu danych

Komunikat może opisywać podatność, wskazywać zagrożone wersje, zalecać aktualizację albo informować o incydencie. Sama obecność podatności nie oznacza jeszcze, że została wykorzystana w konkretnej organizacji. Również incydent bezpieczeństwa produktu nie musi być naruszeniem ochrony danych osobowych u każdego użytkownika.

UODO wskazuje, że informacja otrzymana przez administratora korzystającego z produktu cyfrowego może być podstawą oceny, czy wystąpiło naruszenie ochrony danych. Trzeba więc połączyć komunikat z faktami dotyczącymi własnego środowiska: wersją produktu, konfiguracją, ekspozycją na zagrożenie, przetwarzanymi danymi i dostępnymi zapisami zdarzeń.

Przykładowo, potwierdzenie, że organizacja nie używa wskazanej wersji, może uzasadniać zakończenie analizy tego konkretnego alertu. Natomiast brak logów albo niepełna informacja producenta oznaczają ograniczenie oceny, nie dowód bezpieczeństwa. Takie ograniczenia należy zapisać i ustalić, jak uzupełnić brakujące informacje.

Role producenta, użytkownika, administratora i procesora

• Producent produktu z elementami cyfrowymi realizuje odnoszące się do niego obowiązki CRA. Opisane przez UODO terminy zgłoszeniowe dotyczą jego wiedzy o wskazanych zdarzeniach.
• Firma korzystająca z produktu sprawdza własne środowisko, identyfikuje właściciela systemu i wdraża uzasadnione środki ochronne. Sam zakup lub używanie produktu nie czyni jej producentem.
• Administrator danych osobowych ustala cele i sposoby przetwarzania danych. Ocenia, czy doszło do naruszenia ochrony danych i czy powstają obowiązki z art. 33 i 34 RODO.
• Podmiot przetwarzający, czyli procesor przetwarza dane w imieniu administratora. Po stwierdzeniu naruszenia ochrony danych osobowych powiadamia administratora bez zbędnej zwłoki, zgodnie z art. 33 ust. 2 RODO.

Role mogą się łączyć, ale nie należy tego zakładać automatycznie. Producent może być jednocześnie procesorem w konkretnej relacji, lecz sam fakt dostarczenia oprogramowania tego nie przesądza. UODO podkreśla, że zgłoszenie CRA nie zastępuje obowiązków RODO; oba reżimy mogą działać równolegle. Urząd odwołuje się przy tym do motywu 32 CRA, zgodnie z którym akt nie narusza przepisów RODO.

Sześć kroków po otrzymaniu alertu

Komunikat może trafić najpierw do administracji biura, zakupów lub pojedynczego pracownika. Warto z góry ustalić wspólny kanał eskalacji i zastępstwo na czas nieobecności osoby odpowiedzialnej.

1. Zachowaj oryginał i czas wpływu. Zabezpiecz wiadomość, dane nadawcy, identyfikator komunikatu i załączniki zgodnie z procedurą bezpieczeństwa, bez uruchamiania ich zawartości. Zapisz, kto otrzymał alert i kiedy przekazał go dalej.
2. Sprawdź autentyczność. Potwierdź komunikat w znanym portalu producenta lub przez wcześniej ustalony kontakt. Nie loguj się przez niezweryfikowane linki i nie instaluj poprawek wyłącznie na podstawie wiadomości e-mail.
3. Ustal zakres. Sprawdź produkt, wersję, urządzenie, usługę lub konto. Porównaj informacje z rejestrem aktywów, listą licencji i dokumentacją wdrożenia. Potwierdź, czy wskazana konfiguracja rzeczywiście występuje.
4. Przekaż sprawę do odpowiedzialnych osób. IT lub zespół bezpieczeństwa powinien ocenić ekspozycję techniczną. Jeśli sprawa może dotyczyć danych osobowych, włącz osoby odpowiedzialne za ich ochronę oraz IOD, jeśli został wyznaczony. Odpowiedzialność administratora nie przechodzi przez to na IOD.
5. Ogranicz ryzyko i zbierz fakty. Rozważ zweryfikowaną poprawkę, zmianę konfiguracji lub ograniczenie dostępu, stosownie do sytuacji. Zabezpiecz dostępne dowody w sposób, który nie opóźnia niezbędnego powstrzymania incydentu. Nie czekaj na pełny raport producenta, jeśli własne ustalenia uzasadniają pilne działania.
6. Zapisz decyzję i sprawdź wykonanie. Wskaż ustalenia, ich ograniczenia, właścicieli zadań i termin ponownej oceny. Potwierdź skuteczność zastosowanych środków oraz osobno oceń potrzebę zawiadomień zewnętrznych.

Jak dokumentować ocenę i działania

Praktycznym rozwiązaniem jest jeden rejestr sprawy z chronologią działań i kontrolą dostępu. Rejestr obsługi alertów może obejmować także przypadki, w których nie stwierdzono naruszenia. Trzeba odróżnić tę rekomendację organizacyjną od obowiązku dokumentowania naruszeń ochrony danych wynikającego z art. 33 ust. 5 RODO.

Minimalny zapis obsługi alertu:

• identyfikator sprawy, źródło alertu i czas jego otrzymania;
• wynik weryfikacji autentyczności oraz produkt, wersja i środowisko;
• ustalone fakty, wykorzystane dowody i brakujące informacje;
• ocena wpływu na systemy i dane osobowe, wraz z uzasadnieniem;
• decyzja o dalszych działaniach i ewentualnych zawiadomieniach;
• osoba odpowiedzialna, termin sprawdzenia i potwierdzenie wykonania.

W razie stwierdzenia naruszenia danych zapisz również moment jego stwierdzenia, okoliczności, skutki i podjęte środki zaradcze. Nie przesuwaj tej chwili sztucznie na zakończenie całej analizy lub zatwierdzenie raportu.

Kontrolowana papierowa lista może pomóc podczas awarii lub spotkania koordynacyjnego. Powinna mieć wskazanego opiekuna, ograniczony dostęp i zostać uwzględniona w głównym rejestrze. Nie drukuj zbędnych danych osobowych, haseł ani innych tajemnic. Materiały robocze przechowuj i usuwaj zgodnie z zasadami organizacji, unikając równoległych, niespójnych wersji dokumentacji.

Ocena naruszenia i odrębne obowiązki RODO

Analiza techniczna i ocena ochrony danych powinny być skoordynowane. Należy sprawdzić, czy doszło do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmodyfikowania, nieuprawnionego ujawnienia danych osobowych albo dostępu do nich. Naruszenie nie musi polegać wyłącznie na wycieku: znaczenie może mieć również utrata dostępności lub integralności danych.

Zgłoszenie organowi nadzorczemu: zgodnie z art. 33 RODO administrator zgłasza naruszenie bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od jego stwierdzenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Zgłoszenie po upływie 72 godzin wymaga wyjaśnienia przyczyn opóźnienia. Jeżeli nie wszystkie informacje są dostępne jednocześnie, można przekazywać je sukcesywnie bez zbędnej dalszej zwłoki.

Zawiadomienie osób: art. 34 RODO przewiduje zawiadomienie osób bez zbędnej zwłoki, gdy naruszenie może powodować wysokie ryzyko naruszenia ich praw lub wolności, z uwzględnieniem wyjątków przewidzianych w tym przepisie. To odrębna ocena od zgłoszenia organowi; nie należy utożsamiać progów ryzyka dla obu obowiązków.

Niepełne informacje: ogólny alert o podatności nie musi uruchamiać terminu administratora z art. 33, ale jego treść i własne ustalenia mogą już pozwalać stwierdzić naruszenie. Nie należy odwlekać tej oceny ani czekać na zakończenie całego dochodzenia. Brak dowodów wynikający z ograniczonej widoczności zdarzeń trzeba wyraźnie odróżnić od ustaleń pozwalających wykluczyć naruszenie.

Jeżeli dostawca jest także procesorem i stwierdzi naruszenie ochrony danych, powiadamia administratora bez zbędnej zwłoki. Nie może traktować wykonania zgłoszenia CRA jako zamiennika tej informacji. Administrator dokumentuje naruszenie także wtedy, gdy na podstawie uzasadnionej oceny nie zgłasza go organowi.

FAQ: komunikaty producentów, CRA i RODO

Czy każdy komunikat producenta oznacza naruszenie danych osobowych?

Nie. Trzeba sprawdzić, czy problem dotyczy używanego środowiska i czy doszło do naruszenia ochrony danych. Ogólna informacja o podatności nie jest sama w sobie dowodem takiego naruszenia.

Czy terminy 24 i 72 godzin z CRA dotyczą każdego biura?

Nie. Ramy opisane przez UODO dotyczą zgłoszeń producenta na gruncie art. 14 CRA po uzyskaniu wiedzy o aktywnie wykorzystywanej podatności lub poważnym incydencie. Użytkownik produktu ocenia odrębnie własne obowiązki.

Kiedy administrator ma 72 godziny na zgłoszenie naruszenia?

Art. 33 RODO wiąże ten termin ze stwierdzeniem naruszenia ochrony danych, nie automatycznie z wpływem każdego alertu. Naruszenie wymagające zgłoszenia należy zgłosić bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin. Brak pełnego raportu technicznego nie uzasadnia sam w sobie oczekiwania ze zgłoszeniem.

Czy firma korzystająca z produktu staje się producentem?

Nie przez sam fakt korzystania z produktu. Musi jednak ocenić jego wpływ na własne środowisko. Ewentualne pełnienie dodatkowych ról wymaga analizy rzeczywistego sposobu działania firmy.

Kiedy dostawca będący procesorem informuje administratora?

Po stwierdzeniu naruszenia ochrony danych osobowych powiadamia administratora bez zbędnej zwłoki, zgodnie z art. 33 ust. 2 RODO. Samo dostarczanie produktu nie przesądza o roli procesora, a zgłoszenie CRA nie zastępuje tego obowiązku.

Czy wystarczy zachować wiadomość e-mail od producenta?

Nie. Trzeba również zweryfikować jej autentyczność, ustalić zakres, przekazać sprawę właściwym osobom oraz udokumentować ocenę i wykonane działania. Nie otwieraj niezweryfikowanych załączników ani nie instaluj poprawek z podejrzanej wiadomości.

Podsumowanie: kto podejmuje dalsze decyzje

Producent wykonuje własne obowiązki CRA. Firma korzystająca z produktu sprawdza środowisko i ogranicza ryzyko. Administrator ocenia naruszenie danych oraz obowiązki z RODO, a procesor przekazuje wymagane informacje, gdy rzeczywiście pełni tę rolę.

Praktyczny cel na dziś to wyznaczenie odbiorcy alertów, jego zastępcy i kanału eskalacji oraz przygotowanie krótkiego formularza oceny. Po każdym komunikacie zachowaj ślad decyzji: co ustalono, czego jeszcze nie wiadomo, kto działa dalej i kiedy sprawa zostanie ponownie sprawdzona. W przypadkach niejednoznacznych zaangażuj specjalistów bezpieczeństwa, IOD lub obsługę prawną odpowiednio do potrzeb organizacji.