Jak ograniczyć ryzyko incydentu u dostawcy kluczowego oprogramowania

1. Czy moje oprogramowanie jest w obszarze podwyższonego ryzyka?

1.1. Profil ryzyka

Poniższy profil nie oznacza, że dostawca jest niebezpieczny lub że doszło u niego do zaniedbania. To praktyczny model ryzyka, oparty na cechach systemów, w których pojedynczy incydent może objąć dane wielu organizacji albo zakłócić ich działanie. Profil pytań przygotowaliśmy na podstawie charakterystyki atakowanego w ostatnim czasie oprogramowania.

System wymaga priorytetowego audytu, jeżeli spełnia kilka z następujących warunków:

• przechowuje lub przetwarza duże ilości danych osobowych;
• działa jako usługa chmurowa obsługująca wielu klientów jednocześnie „Multi-Tenant” (architektura wielotenantowa);
• jest ważny dla obsługi klienta albo pacjenta, płatności, faktur, rozliczeń, dokumentacji, rejestracji, sprzedaży albo realizacji usług;
• ma portal dostępny z internetu, API, aplikację mobilną, zdalny dostęp administracyjny albo liczne integracje;
• łączy się z systemami tożsamości, płatności, e-usług, bankowości, księgowości albo dokumentacji;
• dostawca lub jego podwykonawcy mogą mieć dostęp do środowiska produkcyjnego, kopii zapasowych, kluczy, tokenów, logów albo kont uprzywilejowanych;
• system zawiera informacje, które mogą ułatwić oszustwo: numery rachunków, dane płatności, terminy, faktury, dane kontaktowe lub informacje o relacji z klientem;
• dane są przechowywane długo, także w archiwach i backupach;
• dostawca nie przekazuje konkretnych dowodów zabezpieczeń wraz z umową, lecz ogranicza się do ogólnych deklaracji;
• dane lub kopie zapasowe są przechowywane albo przetwarzane poza EOG;
• system umożliwia wykonywanie operacji, których nieuprawniona modyfikacja może mieć istotne konsekwencje dla organizacji lub jej klientów;
• przyjmuje, przesyła, przechowuje lub przetwarza pliki pochodzące od użytkowników albo z zewnętrznych systemów.

Art. 32 RODO wymaga oceny ryzyka, w tym ryzyka nieuprawnionego dostępu, ujawnienia, utraty lub modyfikacji danych. Wprost wskazuje na poufność, integralność, dostępność, odporność, odtwarzanie po incydencie oraz regularne testowanie skuteczności zabezpieczeń. [1]

1.2. Szybki test

Szesnaście pytań. Trzy odpowiedzi wskazujące ryzyko uzasadniają audyt dostawcy. Pięć lub więcej oznacza, że system należy traktować jako dostawcę kluczowego.

To praktyczne kryterium priorytetyzacji, a nie próg ustawowy. Obowiązek oceny adekwatności gwarancji procesora wynika z art. 28 RODO i powinien być zależny od charakteru, zakresu, kontekstu i ryzyka konkretnego przetwarzania. [1] [2]

2. Jak ograniczyć ryzyko, że atak obejmie dane z moich baz, i jak przygotować się na kryzys?

2.1. Działania przed incydentem

A. Ogranicz ilość danych i dostęp do nich

• Ustal, jakie dane rzeczywiście muszą znaleźć się w systemie dostawcy. Nie wprowadzaj danych „na wszelki wypadek”.
• Zdefiniuj okresy przechowywania danych w produkcji, eksportach, plikach, archiwach i backupach.
• Usuń nieużywane konta, integracje, tokeny API i uprawnienia administracyjne.
• Oddziel konta zwykłych użytkowników od kont o podwyższonych uprawnieniach.
• Wprowadź MFA, zwłaszcza dla administratorów, finansów, działu obsługi klienta i osób mających dostęp do eksportów.
• Jeśli to możliwe, wykorzystaj w systemie konta z Twojej organizacji (single-sign-on) zamiast dodatkowych kont tylko do aplikacji.
• Przechowuj zaszyfrowane kopie zapasowe danych w swojej siedzibie.
• Wprowadź walidację danych wprowadzanych do systemu oraz plików przesyłanych przez użytkowników, w tym kontrolę ich typu, formatu i rozmiaru oraz skanowanie plików pod kątem złośliwego oprogramowania.
• Ogranicz możliwość eksportowania danych do zakresu niezbędnego do realizacji konkretnego zadania i kontroluj dostęp do eksportów.
• Rejestruj i monitoruj operacje związane z dostępem do danych, eksportem, zmianą uprawnień i działaniami administracyjnymi.
• Ustal i okresowo weryfikuj, którzy pracownicy dostawcy oraz podwykonawcy mają dostęp do danych i środowiska produkcyjnego.

Zasady minimalizacji danych, ograniczenia przechowywania i poufności wynikają z art. 5 ust. 1 lit. c, e i f RODO. Środki kontroli dostępu, szyfrowanie, zdolność do odtwarzania oraz regularne testowanie wynikają z art. 32 RODO. [1]

B. Zabezpiecz procesy płatnicze i komunikację z klientem

• Wprowadź zasadę: każda zmiana numeru rachunku, duży przelew albo nietypowa prośba o płatność wymaga potwierdzenia innym, wcześniej znanym kanałem.
• Nie potwierdzaj zmiany rachunku, korzystając z numeru telefonu lub linka podanego w nowej wiadomości e-mail.
• Ustal drugą parę oczu dla przelewów, zmian danych kontrahenta i eksportów danych.
• Przeszkol osoby z finansów, sprzedaży i obsługi klienta w rozpoznawaniu phishingu, podszywania się i prośby „na pilnie”.
• Wprowadź zasadę: nie ma transakcji na tyle poufnych, by nie można było ich zweryfikować z inną osobą (nie będącą ich zleceniodawcą).

Są to środki proporcjonalne do ryzyka oszustwa i nieuprawnionego dostępu z art. 32 RODO. Dla podmiotów kluczowych lub ważnych uKSC wskazuje także cyberhigienę, szkolenia, kontrolę dostępu, kryptografię i bezpieczną komunikację jako elementy systemu zarządzania bezpieczeństwem. [1] [4]

C. Przygotuj dowody i kontakty zanim będą potrzebne

• Zachowaj listę systemów krytycznych, właścicieli biznesowych i technicznych oraz dostawców.
• Zapisz dane kontaktowe do dostawcy: bezpieczeństwo, IOD, support, incident response i eskalacja zarządcza.
• Ustal, kto może zarządzić reset haseł, odłączenie integracji, blokadę konta i kontakt z bankiem.
• Przechowuj poza systemem dostawcy aktualną listę kluczowych klientów, kontrahentów i procesów awaryjnych.
• Regularnie testuj odtworzenie danych i alternatywny sposób pracy, gdy system jest niedostępny.
• Przygotuj gotowe i zatwierdzone przez zarządzających szablony komunikatów kryzysowych dla pracowników, kontrahentów i klientów (nawet bardzo ogólne) oraz ustal sposób komunikacji przy awarii systemów.

Zdolność do przywrócenia dostępności danych i regularne testowanie zabezpieczeń są wskazane w art. 32 ust. 1 lit. b-d RODO. [1]

2.2. Co zrobić, gdy incydent już nastąpi?

Pierwsza zasada: nie usuwaj śladów.

Nie kasuj logów, wiadomości, eksportów, tokenów ani kont „dla porządku”. Najpierw zabezpiecz dowody i wykonaj działania ograniczające ryzyko w kontrolowany sposób. Prowadź dziennik decyzji: kto, kiedy i co ustalił lub zrobił.

Druga zasada: od razu rozdziel trzy pytania.

1. Czy dane zostały naruszone?
2. Czy system lub proces nadal jest zagrożony?
3. Czy obowiązuje zgłoszenie do organu lub informacja dla osób?

Przy RODO administrator uzyskuje „świadomość” naruszenia, gdy ma rozsądny stopień pewności, że zdarzenie bezpieczeństwa doprowadziło do naruszenia danych. Krótkie ustalenie faktów jest dopuszczalne, ale dochodzenie powinno rozpocząć się niezwłocznie. [3]

Trzecia zasada: uruchom równolegle cztery strumienie pracy.

3. Regulamin usługi i umowa powierzenia (DPA): minimalne warunki umowne

3.1. Najpierw ustal, jakie przepisy naprawdę mają zastosowanie

Nie należy wpisywać do umowy wszystkich skrótów regulacyjnych bez oceny roli i systemu.

Nowelizacja uKSC weszła w życie 3 kwietnia 2026 r. i nakłada na podmioty kluczowe oraz ważne obowiązki systemowego zarządzania ryzykiem i incydentami. [4] AI Act stosuje podejście oparte na ryzyku; obowiązki podmiotu stosującego i dostawcy zależą od kwalifikacji systemu oraz roli w łańcuchu wartości. [6] CRA obejmuje produkty z elementami cyfrowymi, a Komisja wyjaśnia, że zwykłe modele SaaS, PaaS i IaaS nie są automatycznie objęte jego zakresem. [7] [5]

3.2. Warunki obowiązkowe w DPA i regulaminie usługi, RODO

Umowa powierzenia powinna zawierać co najmniej elementy wymagane w art. 28 ust. 3 RODO. W praktyce przedsiębiorca powinien dopilnować poniższych postanowień.

1. Jasny opis usługi i danych

Umowa powinna wskazywać: cele, czas trwania i charakter przetwarzania; rodzaje danych; kategorie osób; funkcje i moduły; integracje; lokalizacje danych; sposób eksportu; retencję; listę środowisk, w których dane mogą się znaleźć.

2. Przetwarzanie wyłącznie na udokumentowane polecenie

Dostawca nie może używać danych klienta do własnych celów. W szczególności, gdy występuje komponent AI, umowa powinna wprost zakazywać wykorzystywania danych przedsiębiorcy do trenowania, dostrajania lub ulepszania modeli AI, chyba że przedsiębiorca wyda odrębne, zgodne z prawem i udokumentowane polecenie.

3. Szczegółowy załącznik TOM

Do umowy należy dołączyć opis faktycznie stosowanych środków technicznych i organizacyjnych, a nie wyłącznie zdanie „dostawca stosuje zabezpieczenia zgodne z RODO”. Załącznik powinien obejmować co najmniej: MFA, dostępy uprzywilejowane, szyfrowanie, logowanie, monitoring, backupy, testy, zarządzanie podatnościami, reakcję na incydent, podprocesorów i transfery.

EROD wskazuje, że stopień szczegółowości środków musi pozwalać administratorowi ocenić ich adekwatność i wykazać rozliczalność. [2]

4. Incydent: krótki termin umowny i pełna pomoc

RODO wymaga, aby procesor poinformował administratora o naruszeniu bez zbędnej zwłoki. Umowa powinna więc określać krótszy, operacyjny termin poinformowania klienta, przykładowo do 12 lub 24 godzin od stwierdzenia przez dostawcę, oraz kolejne aktualizacje.

To jest zalecany termin umowny, a nie dodatkowy termin ustawowy z RODO. Jest potrzebny, aby administrator mógł zmieścić się w swoim terminie 72 godzin i podjąć działania ochronne. [1] [3]

Minimalny zakres pierwszego raportu od dostawcy:

• data i godzina wykrycia oraz znana chronologia;
• dotknięte systemy i konta klienta;
• kategorie danych, osoby i przybliżona skala;
• potwierdzony, potencjalny i wykluczony zakres;
• informacje o eksporcie, publikacji, zmianie lub utracie danych;
• działania ograniczające ryzyko;
• działania wymagane po stronie klienta;
• punkt kontaktowy dostępny w trakcie obsługi incydentu;
• plan dalszych aktualizacji i raport przyczyn po incydencie.

5. Audyt i dowody

Dostawca powinien przekazywać informacje niezbędne do wykazania zgodności oraz umożliwiać audyty. Umowa może chronić tajemnicę przedsiębiorstwa i innych klientów, lecz nie może uniemożliwiać przedsiębiorcy oceny środków bezpieczeństwa. Dopuszczalne dowody to np. zredagowany raport z niezależnego audytu, zakres certyfikatu, wyniki testów, plan remediacji i spotkanie wyjaśniające.

6. Podprocesorzy, transfery i zmiany

Umowa powinna zawierać aktualną listę podprocesorów wraz z rolą i lokalizacją. Przy ogólnej zgodzie na podpowierzenie dostawca musi aktywnie poinformować o planowanej zmianie i zapewnić realną możliwość sprzeciwu. Sama ukryta aktualizacja strony nie wystarcza. [1] [2]

7. Wyjście z usługi i ciągłość działania

Należy umówić: format i termin eksportu danych; wsparcie migracji; retencję po zakończeniu umowy; usunięcie danych i kopii; potwierdzenie usunięcia; RTO i RPO; backupy; testy odtworzenia; procedurę działania awaryjnego.

3.3. Dodatkowe warunki, gdy odbiorca systemu jest podmiotem kluczowym lub ważnym uKSC

Podmiot kluczowy lub ważny musi prowadzić system zarządzania bezpieczeństwem informacji, który obejmuje m.in. zarządzanie ryzykiem, bezpieczeństwo nabywania i utrzymania systemów, testowanie, ciągłość działania, łańcuch dostaw, monitoring, cyberhigienę, kryptografię, MFA w stosownych przypadkach oraz kontrolę dostępu. [4]

W umowie z dostawcą należy zatem zapewnić co najmniej:

• prawo uzyskania dowodów, że dostawca zarządza ryzykiem w swoim łańcuchu dostaw;
• identyfikację zależności od produktów, usług i procesów ICT;
• obowiązek natychmiastowego przekazania informacji potrzebnych do zgłoszenia incydentu poważnego;
• stały kontakt eskalacyjny i procedurę wspólnego reagowania;
• zobowiązanie do wspierania analizy incydentu, ograniczania skutków i odtwarzania usługi;
• testy ciągłości działania, odtworzenia i scenariusze awaryjne;
• obowiązek informowania o istotnych zmianach architektury, podprocesorów, dostępu uprzywilejowanego, lokalizacji danych, szyfrowania i integracji;
• możliwość udziału w ćwiczeniu incydentowym albo otrzymania zredagowanego wyniku ćwiczenia;
• obowiązek zachowania dowodów i logów koniecznych do obsługi incydentu;
• określenie wymagań bezpieczeństwa, które dostawca i jego podwykonawcy muszą spełniać przez cały okres świadczenia usługi;
• prawo do przeprowadzania lub zlecania audytów, kontroli i testów bezpieczeństwa dostawcy w zakresie dotyczącym świadczonej usługi;
• obowiązek niezwłocznego informowania o podatnościach mogących mieć wpływ na bezpieczeństwo świadczonej usługi oraz o sposobie ich usunięcia;
• obowiązek informowania o incydentach bezpieczeństwa dotyczących dostawcy lub jego podwykonawców, które mogą wpływać na odbiorcę usługi;
• określenie wymagań dotyczących zarządzania dostępem uprzywilejowanym, uwierzytelniania wieloskładnikowego i ochrony danych;
• określenie wymagań dotyczących bezpiecznego wytwarzania, aktualizacji i utrzymania oprogramowania, w tym zarządzania podatnościami;
• obowiązek zapewnienia możliwości bezpiecznego zakończenia współpracy, w tym zwrotu lub usunięcia danych, przekazania danych oraz wsparcia migracji do innego dostawcy;
• określenie zasad i terminów usuwania danych po zakończeniu świadczenia usługi, z uwzględnieniem kopii zapasowych i archiwów.

Podmiot kluczowy lub ważny powinien zgłosić wczesne ostrzeżenie o incydencie poważnym nie później niż w ciągu 24 godzin od wykrycia, zgłoszenie w ciągu 72 godzin, a sprawozdanie końcowe w ciągu miesiąca od zgłoszenia. Dlatego dostawca powinien umownie przekazywać dane szybciej niż wskazane terminy ustawowe. [4]

Zgłoszenia kieruj do właściwego CSIRT (NASK, GOV lub MON, zależnie od rodzaju podmiotu) przez system zgłoszeniowy wskazany w ustawie. Nie zastępują one zgłoszenia do UODO, więc często będą to dwa niezależne zgłoszenia.

3.4. Dodatkowe warunki dla systemów AI

W pierwszej kolejności trzeba ustalić, czy system rzeczywiście jest systemem AI, jaka jest rola przedsiębiorcy i dostawcy oraz czy system kwalifikuje się jako wysokiego ryzyka. Nie należy bez analizy stosować pełnego pakietu obowiązków AI Act do każdej funkcji automatyzacji lub asystenta.

Jeżeli przedsiębiorca stosuje system AI wysokiego ryzyka, umowa powinna zapewniać:

• instrukcję użycia w języku zrozumiałym dla użytkownika, opis ograniczeń, warunków prawidłowego użycia i środków nadzoru człowieka;
• możliwość prowadzenia oraz udostępnienia niezbędnych logów;
• procedurę monitorowania działania w warunkach rzeczywistych;
• możliwość zatrzymania systemu, wycofania wyniku albo przejścia na bezpieczny proces ręczny;
• obowiązek niezwłocznego zgłaszania przedsiębiorcy istotnego nieprawidłowego działania, zmiany modelu, zmiany przeznaczenia lub podejrzenia naruszenia praw podstawowych;
• opis danych wykorzystywanych przez AI, retencji, miejsc przetwarzania, podwykonawców i modeli;
• zakaz wykorzystania danych przedsiębiorcy do trenowania albo ulepszania modelu bez odrębnego, udokumentowanego polecenia;
• zasady testowania bezpieczeństwa AI, w tym ochronę przed manipulacją wejściem, wyciekiem danych, zatruciem danych, omijaniem zabezpieczeń i nieuprawnionym dostępem;
• obowiązek aktualizacji dokumentacji po istotnej zmianie systemu;
• określenie celu, przeznaczenia i zakresu zastosowania systemu AI oraz zakaz wykorzystywania go do celów innych niż uzgodnione;
• zasady postępowania w przypadku błędnych, niepewnych lub potencjalnie szkodliwych wyników AI, w tym możliwość ich odrzucenia przez człowieka;
• jednoznaczne określenie, czy dane przedsiębiorcy są wykorzystywane do trenowania, dostrajania, ewaluacji lub ulepszania modelu oraz przez jaki okres są przechowywane;
• obowiązek informowania o zmianach modelu lub sposobie działania, które mogą wpływać na bezpieczeństwo, dokładność lub zgodność systemu.

Wymogi dotyczące zarządzania ryzykiem, rejestrowania zdarzeń, przejrzystości, nadzoru człowieka oraz cyberbezpieczeństwa odnoszą się do systemów AI wysokiego ryzyka. AI Act podkreśla również odporność na próby manipulacji zachowaniem i skutecznością systemu oraz bezpieczeństwo infrastruktury ICT, na której system działa. [6]

3.5. Dodatkowe warunki, gdy dostawca podlega CRA

CRA dotyczy producentów produktów z elementami cyfrowymi, a w określonych sytuacjach także zdalnych rozwiązań przetwarzania danych koniecznych do działania produktu. Nie należy automatycznie zakładać, że każda usługa dostępna w przeglądarce jest objęta CRA. [7] [5] Oprogramowanie uruchamiane w 100% w chmurze przez przeglądarkę internetową, niewymagające instalacji żadnego kodu u klienta końcowego, nie podlega regulacjom CRA. Skrótu CRA nie dopisuje się do każdej umowy. Warunki poniżej wchodzą wtedy, gdy mają zastosowanie.

Czytelnik nie jest tylko klientem usługi w przeglądarce w czterech sytuacjach.

1. Dostaje komponent uruchamiany u siebie: aplikację, agenta, sterownik, oprogramowanie układowe, rozszerzenie, SDK albo kod źródłowy licencjonowany jako produkt. Wtedy pyta o rozporządzenie producenta.
2. Ten komponent nie działa bez chmury tego samego producenta. Ta chmura jest zdalnym rozwiązaniem przetwarzania danych i wchodzi w produkt razem z komponentem (art. 3 pkt 2).
3. Sam wprowadza na rynek Unii produkt pod własną nazwą albo integruje cudzy komponent we własny produkt. Wtedy to on jest producentem i ma należytą staranność wobec komponentów osób trzecich, także wolnego oprogramowania (art. 13 ust. 5). Od 11 grudnia 2027 r. dochodzą wymagania zasadnicze, dokumentacja i oznakowanie CE.
4. Istotnie modyfikuje cudzy produkt: zmienia przeznaczenie albo zgodność z częścią I załącznika I. Staje się wówczas producentem (art. 3 pkt 30 i art. 22). Sama aktualizacja bezpieczeństwa, która obniża ryzyko i nie zmienia przeznaczenia, istotną modyfikacją nie jest.

Osobno: firma z Polski, która wprowadza na rynek Unii produkt producenta spoza Unii, może być importerem. To już obowiązki importera, a nie zestaw pytań do dostawcy.

Jeżeli dostawca jest producentem objętym rozporządzeniem, umowa powinna wymagać, w zakresie, w jakim obowiązek już stosuje się do tego produktu:

• pisemnego określenia, które produkty, aplikacje, komponenty lub zdalne rozwiązania przetwarzania danych dostawca kwalifikuje jako objęte CRA;
• wskazania okresu wsparcia, zasad aktualizacji bezpieczeństwa i mechanizmu informowania o podatnościach;
• punktu kontaktowego do zgłaszania podatności;
• informacji, czy wykryta podatność została aktywnie wykorzystana oraz czy zdarzenie zakwalifikowano jako poważny incydent dotyczący bezpieczeństwa produktu;
• potwierdzenia wykonania obowiązków raportowych z art. 14 CRA, gdy mają zastosowanie, bez żądania wrażliwych szczegółów technicznych;
• przekazania instrukcji bezpiecznego użycia, informacji o aktualizacjach i działaniach wymaganych po stronie klienta;
• informacji, jak producent kwalifikuje produkt: zwykły, ważny klasy I, ważny klasy II albo krytyczny. Od tej kwalifikacji zależy, czy wystarczy samoocena, czy potrzebna jest strona trzecia. Deklaracji zgodności UE nie wpisuje się jako obowiązku umownego tak, jakby oznakowanie CE z rozporządzenia już obowiązywało. Ten obowiązek powstaje przy wprowadzeniu do obrotu od 11 grudnia 2027 r.;
• okresu wsparcia i zasad aktualizacji, na zasadach opisanych niżej;
• potwierdzenia, że zestawienie składników oprogramowania istnieje, oraz informacji o składniku objętym konkretną podatnością, która dotyczy usługi klienta. Pełne zestawienie nie jest prawem każdego klienta.

Art. 14 już się stosuje, także do produktów wprowadzonych przed 11 grudnia 2027 r. Art. 71 uruchomił zgłoszenia 11 września 2026 r. Art. 69 ust. 3 mówi, że art. 14 stosuje się do produktów z zakresu, które były na rynku przed pełnym stosowaniem rozporządzenia. Pozostałe wymagania, w tym załącznik I, oznakowanie CE i okres wsparcia jako obowiązek wprowadzenia do obrotu, ruszają 11 grudnia 2027 r. Dla starszych produktów ruszają dopiero przy istotnej modyfikacji po tej dacie (art. 69 ust. 2). [7] [5]

Producent, który dowie się o zdarzeniu, składa dwa różne zgłoszenia. Nie wolno ich sklejać ze zgłoszeniem RODO ani uKSC. Adresatem wczesnego ostrzeżenia i zgłoszenia 24 oraz 72 godzin jest CSIRT koordynatora i ENISA, przez platformę jednolitego zgłaszania, a nie klient i nie Prezes UODO. Termin wobec użytkownika w art. 14 ust. 8 jest jakościowy: powiadomienie następuje w odpowiednim czasie. Gdy producent tego nie zrobi, CSIRT może poinformować użytkowników sam, o ile jest to proporcjonalne.

Podatność aktywnie wykorzystywana oznacza, że są wiarygodne dowody, iż złośliwy aktor wykorzystał ją w systemie bez zgody właściciela systemu (art. 3 pkt 42). Wynik testu penetracyjnego albo samo CVE tego progu nie spełnia.

Poważny incydent to zdarzenie, które zaburza albo może zaburzyć zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności wrażliwych albo ważnych danych lub funkcji, albo prowadzi albo może prowadzić do wprowadzenia lub wykonania złośliwego kodu w produkcie lub w systemach użytkownika (art. 14 ust. 5). Awaria usługi w przeglądarce bez tego skutku poważnym incydentem w rozumieniu rozporządzenia nie jest.

Zgłoszenie z art. 14 jest obowiązkiem producenta, nie klienta. Klient może oczekiwać powiadomienia z art. 14 ust. 8 i środków po swojej stronie oraz potwierdzenia, że zgłoszenie do CSIRT i ENISA zostało złożone: data oraz tak albo nie. Treści zgłoszenia na platformie, szczegółów eksploatacji i nieopublikowanego opisu podatności przed poprawką klient nie powinien żądać. Dobrowolne zgłoszenie innej podatności lub incydentu, który nie jest poważny, jest możliwe na podstawie art. 15 i nie jest obowiązkiem.

Gdy przedsiębiorca sam jest producentem, zegar 24 i 72 godzin jest jego. Uruchamia się od jego wiedzy, niezależnie od tego, czy dostawca komponentu już zgłosił swoje.

Te trzy zegary startują od innych faktów i idą do innych adresatów. W RODO świadomość naruszenia danych osobowych u administratora uruchamia co do zasady 72 godziny do Prezesa UODO. W uKSC incydent poważny u podmiotu kluczowego lub ważnego uruchamia wczesne ostrzeżenie w 24 godziny do właściwego CSIRT sektorowego. W rozporządzeniu wiedza producenta o podatności aktywnie wykorzystywanej albo o poważnym incydencie bezpieczeństwa produktu uruchamia 24 i 72 godziny do CSIRT koordynatora i ENISA. Jeden incydent może uruchomić jeden, dwa albo wszystkie trzy. Czekanie na raport producenta z art. 14 nie wstrzymuje zegara RODO ani uKSC.

Okres wsparcia i aktualizacje są dziś pytaniem handlowym, a obowiązkiem od 11 grudnia 2027 r. Art. 13 ust. 8: okres obsługi podatności ma odpowiadać przewidywanemu czasowi używania i wynosi co najmniej pięć lat. Krótszy okres jest dopuszczalny tylko wtedy, gdy sam produkt jest używany krócej i producent to uzasadni. Przy dłuższym użyciu, typowym dla sterowników przemysłowych, systemów operacyjnych i urządzeń sieciowych, okres ma być dłuższy niż pięć lat. Data końca wsparcia ma być znana przy nabyciu (załącznik II).

Aktualizacje bezpieczeństwa mają być rozpowszechniane bez zbędnej zwłoki, co do zasady nieodpłatnie, z informacją doradczą i oddzielone od zmian funkcjonalnych (załącznik I część II). Przy produkcie na zamówienie producent i użytkownik biznesowy mogą umówić się inaczej co do odpłatności. W umowie na produkt standardowy warto wpisać nieodpłatność wprost. Mechanizm ma pozwalać na aktualizację automatyczną tam, gdzie jest to właściwe, z jasną możliwością rezygnacji. Ten automatyzm nie dotyczy komponentów przeznaczonych do wbudowania w inny produkt. Po końcu wsparcia ryzyko zostaje przy użytkowniku. Motyw 61 zachęca producenta, by rozważył przekazanie kodu źródłowego komuś, kto przedłuży obsługę podatności. To nie jest roszczenie klienta.

Zestawienie składników oprogramowania nie jest prawem klienta. Producent sporządza je w formacie maszynowym, co najmniej dla zależności najwyższego poziomu, i przekazuje je na żądanie organu nadzoru rynku (załącznik I część II). W umowie rozsądne jest żądanie potwierdzenia, że zestawienie istnieje, oraz informacji o składniku objętym konkretną podatnością, która dotyczy usługi klienta. Żądanie pełnego zestawienia jako obowiązku ustawowego wobec każdego klienta jest za daleko.

Oznakowanie CE i klasa produktu liczą się przy wprowadzeniu do obrotu od 11 grudnia 2027 r. Do tego czasu warto zapytać, czy produkt jest zwykły, ważny klasy I, ważny klasy II czy krytyczny, bo od pełnego stosowania rozporządzenia od tego zależy, czy wystarczy samoocena, czy potrzebna jest strona trzecia. To zmienia, jakiego dowodu klient może realnie oczekiwać. [7] [5]

4. Minimalna checklista organizacyjno-techniczna

Poniższe warunki tworzą minimum dla przedsiębiorcy korzystającego z kluczowego systemu. Są oparte przede wszystkim na art. 32 RODO. Dla podmiotów kluczowych lub ważnych stanowią jednocześnie bazę do realizacji uKSC. Dla systemów AI wysokiego ryzyka i produktów objętych CRA należy dodać wymagania właściwe dla tych reżimów. [1] [4] [6] [7]

4.1. Zarządzanie i odpowiedzialność

• Każdy system krytyczny ma właściciela biznesowego, technicznego i osobę odpowiedzialną za ryzyko.
• Twoja Firma ma aktualny rejestr kluczowych systemów, danych, integracji i dostawców.
• Dla każdego dostawcy istnieje klasyfikacja: zwykły, istotny, krytyczny.
• Zarząd lub właściciel zatwierdza akceptację ryzyka, gdy krytyczny brak nie może być szybko usunięty.
• Twoja Firma ma procedurę regularnego przeglądu dostawcy oraz przeglądu po istotnej zmianie lub incydencie.
• Za każdy system krytyczny wskazana jest osoba odpowiedzialna za jego funkcjonowanie, bezpieczeństwo i związane z nim ryzyko.
• W przypadku incydentu lub istotnego ryzyka wiadomo, kto podejmuje decyzje i komu należy je eskalować.

4.2. Dane i dostępy

• Twoja Firma zna kategorię danych, osób i okres retencji w systemie, eksportach oraz backupach.
• Dostępy są ograniczone do niezbędnego zakresu i przeglądane co najmniej okresowo.
• MFA jest obowiązkowe dla administratorów i osób o podwyższonych uprawnieniach; dla innych użytkowników jest stosowane zgodnie z oceną ryzyka.
• Konta byłych pracowników, współpracowników i dostawców są usuwane lub blokowane niezwłocznie po zakończeniu potrzeby dostępu.
• Tokeny API, konta serwisowe i klucze integracyjne są zinwentaryzowane, chronione i możliwe do rotacji.
• Dane produkcyjne nie są używane w testach, jeżeli można użyć danych zanonimizowanych, syntetycznych lub zmaskowanych.
• Dostępy do danych i systemów są nadawane, zmieniane i odbierane na podstawie określonej potrzeby biznesowej.
• Dostępy uprzywilejowane są wykorzystywane tylko wtedy, gdy są niezbędne, i są odpowiednio zabezpieczone.
• Eksport danych jest ograniczony do niezbędnego zakresu i podlega kontroli.
• Dostęp do backupów jest ograniczony i zabezpieczony przed nieuprawnioną modyfikacją lub usunięciem.
• Hasła, klucze i inne dane uwierzytelniające nie są przechowywane w kodzie źródłowym ani przesyłane w niezabezpieczony sposób.
• Dostawca i jego podwykonawcy mają dostęp do danych wyłącznie w zakresie niezbędnym do realizacji usługi.

4.3. Bezpieczeństwo techniczne

• Dane są chronione w transmisji i w spoczynku; Twoja Firma zna model zarządzania kluczami.
• System i integracje są aktualizowane zgodnie z ryzykiem i zaleceniami producenta.
• Twoja Firma otrzymuje informacje o krytycznych podatnościach, istotnych aktualizacjach i działaniach, które ma wykonać.
• Istnieje monitoring nietypowych logowań, zmian uprawnień, masowych eksportów, nadużyć API i nieudanych prób dostępu.
• Logi zabezpieczają możliwość odtworzenia kluczowych działań, a ich retencja jest uzasadniona i znana.
• Backupy są szyfrowane, odseparowane i testowane pod kątem odtworzenia.
• Istnieje udokumentowany RTO i RPO dla systemu krytycznego.
• Dostępy administracyjne do systemu są odpowiednio zabezpieczone i wykorzystywane wyłącznie w zakresie niezbędnym do zarządzania systemem.
• System jest zabezpieczony przed nieautoryzowaną zmianą konfiguracji i kodu.
• Pliki przesyłane do systemu są walidowane i, w stosownych przypadkach, skanowane pod kątem złośliwego oprogramowania.

4.4. Ludzie, procesy i płatności

• Pracownicy znają zasady weryfikacji zmiany rachunku i nietypowych dyspozycji płatniczych.
• Twoja Firma stosuje potwierdzenie drugim kanałem dla zmiany numeru rachunku lub pilnych przelewów.
• Osoby obsługujące klienta, płatności i dane przechodzą szkolenie z phishingu oraz raportowania zdarzeń.
• Twoja Firma ma prosty kanał szybkiego zgłaszania podejrzanej wiadomości lub zdarzenia.
• Pracownicy wiedzą, że nie wolno usuwać logów i dowodów po incydencie.
• Twoja Firma utrzymuje listę kontaktów kryzysowych poza głównym systemem komunikacji.

4.5. Dostawca i łańcuch dostaw

• DPA, regulamin, TOM i SLA zostały przeanalizowane przed uruchomieniem systemu.
• Twoja Firma ma listę podprocesorów oraz wie, którzy z nich faktycznie przetwarzają jej dane.
• Umowa przewiduje aktywne informowanie o zmianie podprocesora, lokalizacji danych lub istotnej architektury.
• Dostawca ma obowiązek szybko poinformować o incydencie i przekazać informacje potrzebne do oceny RODO i uKSC.
• Dostawca przekazuje dowody zabezpieczeń oraz umożliwia audyt lub równoważną weryfikację.
• Umowa zapewnia eksport danych, wsparcie migracji i potwierdzenie usunięcia po zakończeniu usługi.
• Przed rozpoczęciem współpracy oceniono ryzyko związane z dostawcą i jego usługą.
• Dostawca ma określone zasady bezpiecznego zakończenia usługi, w tym usunięcia lub zwrotu danych.
• Twoja Firma jest informowana o istotnych podatnościach lub incydentach dotyczących dostawcy albo jego podwykonawców, które mogą wpłynąć na bezpieczeństwo usługi.

4.6. Dodatkowa checklista dla AI

• Twoja Firma ma inwentarz funkcji AI: dostawca, model, cel, dane wejściowe, dane wyjściowe i osoby, na które system wpływa.
• Dla każdej funkcji AI ustalono: czy jest to system AI, jaka jest rola firmy i dostawcy oraz czy wymaga oceny wysokiego ryzyka.
• Przed wprowadzeniem danych do AI określono, czy dane mogą być użyte do trenowania lub poprawy usługi; domyślna odpowiedź w umowie powinna brzmieć „nie”, chyba że jest odrębne polecenie.
• Twoja Firma ma zasady nadzoru człowieka i możliwość zakwestionowania, zatrzymania lub poprawienia wyniku AI.
• Twoja Firma wie, jakie logi i dowody są dostępne po błędzie, halucynacji, naruszeniu bezpieczeństwa lub podejrzeniu dyskryminacji.
• Istnieje procedura oceny istotnej zmiany modelu, dostawcy, przeznaczenia systemu lub kategorii danych.

5. Dwie zasady, które przedsiębiorca powinien przyjąć

Zasada 1: wybór i okresowy nadzór dostawcy kluczowego

Cel. Przedsiębiorca wybiera dostawcę na podstawie dowodów bezpieczeństwa i zdolności do działania po incydencie, a nie wyłącznie na podstawie ceny, funkcji lub deklaracji marketingowych.

Kiedy stosować?

• przed zakupem systemu istotnego lub krytycznego;
• przed włączeniem nowego modułu AI, integracji lub API;
• co najmniej raz w roku dla dostawcy krytycznego;
• po zmianie podprocesora, architektury, lokalizacji danych, modelu AI, warunków DPA albo TOM, albo po istotnym incydencie;
• gdy zmienia się rodzaj danych lub skala przetwarzania.

Procedura wyboru dostawcy, minimalne kroki

• Klasyfikacja usługi: określ procesy, dane, osoby, krytyczność biznesową, integracje i zależności.
• Ustalenie ról: sprawdź, kto jest administratorem, procesorem, podprocesorem, dostawcą AI i, gdy ma to znaczenie, producentem objętym CRA.
• Ocena regulacyjna: potwierdź, czy przedsiębiorca kwalifikuje się do uKSC oraz czy system AI jest wysokiego ryzyka. Nie zakładaj tego na podstawie nazwy produktu.
• Zebranie dowodów: poproś o DPA, TOM, listę podprocesorów, lokalizacje, transfery, certyfikaty z zakresem, wyniki testów i audytów, procedurę incydentową i deklarację CRA, gdy dotyczy.
• Ocena braków: porównaj dowody z checklistą z części 4. Oznacz: spełnione, częściowo spełnione, brak dowodu, nieakceptowalne ryzyko.
• Negocjacja umowy: wprowadź warunki z części 3, szczególnie termin raportowania, pomoc po incydencie, audyt, podprocesorów, TOM i wyjście z usługi.
• Decyzja: zaakceptuj ryzyko wyłącznie na poziomie uprawnionym w organizacji, z terminem usunięcia braku i właścicielem działania.
• Nadzór: sprawdzaj zmiany i aktualizuj ocenę oraz dokumenty.

Ta procedura realizuje obowiązek oceny wystarczających gwarancji procesora z art. 28 RODO. EROD wskazuje, że administrator powinien mieć możliwość oparcia oceny na dokumentacji, np. politykach bezpieczeństwa, raportach audytowych i certyfikatach, oraz dostosować ją do danego przypadku. [1] [2]

Zasada 2: postępowanie w przypadku incydentu cyberbezpieczeństwa

Cel. Przedsiębiorca szybko ogranicza szkody, zbiera dowody, chroni osoby i weryfikuje obowiązki raportowe bez działania chaotycznego albo przedwczesnej komunikacji.

Krok 0. Gotowość stała

• Utrzymuj zespół kryzysowy: biznes, IT, bezpieczeństwo, compliance i RODO, prawnik, komunikacja i finanse.
• Utrzymuj dane kontaktowe, listę systemów i szablony zgłoszeń.
• Wykonuj ćwiczenie scenariuszowe co najmniej dla phishingu, przejęcia konta, wycieku tokenu i niedostępności kluczowego SaaS.
• Ustal, kto formalnie zatwierdza komunikację i decyzje o zgłoszeniu.

Krok 1. Od 0 do 4 godzin

• Nadaj zdarzeniu numer i rozpocznij dziennik incydentu.
• Zabezpiecz dowody: e-maile, zrzuty ekranu, logi, alerty, identyfikatory sesji, informacje od dostawcy.
• Ogranicz zagrożenie: zablokuj konta i sesje, zrotuj hasła i tokeny, odłącz ryzykowne integracje, wstrzymaj nietypowe płatności.
• Skontaktuj się z dostawcą przez wcześniej zweryfikowany kanał i zażądaj informacji incydentowej.
• Ustal, czy system nadal działa bezpiecznie i czy trzeba przejść na proces awaryjny.
• Jeśli masz polisę cyber, sprawdź w warunkach ubezpieczenia termin zgłoszenia szkody i zgłoś zdarzenie ubezpieczycielowi.
• Jeśli podejrzewasz przestępstwo (wyłudzenie, włamanie, ransomware z żądaniem okupu), po zabezpieczeniu dowodów zgłoś to na Policji.
• Dobrowolnie zgłoś phishing, malware lub przejęcie konta do CERT Polska (incydent.cert.pl). Podejrzane SMS-y możesz przesłać na numer 8080.

Krok 2. Od 4 do 24 godzin

• Ustal, czy doszło do naruszenia danych, których przedsiębiorca jest administratorem.
• Ustal co najmniej: osoby, dane, okres, systemy, sposób dostępu, potwierdzony eksport oraz działania ograniczające.
• Przeprowadź wstępną ocenę ryzyka dla osób fizycznych.
• Oceń obowiązki dodatkowe.

• uKSC: jeżeli przedsiębiorca jest podmiotem kluczowym lub ważnym, oceń, czy zdarzenie jest incydentem poważnym i czy należy wysłać wczesne ostrzeżenie w ciągu 24 godzin od wykrycia. [4]
• CRA: jeżeli dostawca jest producentem produktu objętego rozporządzeniem, zażądaj informacji o jego ocenie obowiązku z art. 14. Jest to obowiązek producenta, a nie klienta. Klient może oczekiwać powiadomienia z art. 14 ust. 8, środków po swojej stronie oraz potwierdzenia, że zgłoszenie do CSIRT i ENISA zostało złożone: data oraz tak albo nie. Nie żąda treści zgłoszenia na platformie, szczegółów eksploatacji ani nieopublikowanego opisu podatności przed poprawką. Czekanie na ten raport nie wstrzymuje zegara RODO ani uKSC. [7]
• AI Act: jeżeli dotyczy systemu AI wysokiego ryzyka, uruchom analizę roli, instrukcji użycia, logów, nadzoru człowieka, nieprawidłowego działania oraz komunikacji z dostawcą i właściwym organem. [6]
• Przepisy sektorowe: jeśli działasz w zawodzie regulowanym lub sektorze nadzorowanym (np. lekarz, prawnik, doradca podatkowy, finanse), sprawdź, czy przepisy lub izba zawodowa wymagają dodatkowego zgłoszenia.

• Przygotuj informację dla zarządu albo właściciela: fakty, niepewności, działania pilne i decyzje do podjęcia.
• Jeśli w tym systemie jesteś procesorem (obsługujesz dane klienta), poinformuj administratora bez zbędnej zwłoki, zgodnie z umową. Zgłoszenie do UODO jest obowiązkiem administratora, nie Twoim.

Krok 3. Od 24 do 72 godzin

• Podejmij decyzję RODO: zgłoszenie do Prezesa UODO jest wymagane, chyba że ryzyko dla praw i wolności osób jest mało prawdopodobne.
• Jeżeli zgłoszenie jest wymagane, przygotuj je bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny od stwierdzenia naruszenia. Gdy informacji brakuje, można je przekazywać etapami, ale trzeba rozpocząć od informacji dostępnych. [1] [3]
• Podejmij decyzję, czy naruszenie może powodować wysokie ryzyko dla osób. Jeżeli tak, przygotuj jasne zawiadomienie z art. 34 RODO bez zbędnej zwłoki. [1] [3]
• Jeżeli dotyczy uKSC, przekaż zgłoszenie incydentu poważnego w ciągu 72 godzin od wykrycia. [4]
• Wdróż ochronę klientów i płatności: niezależne potwierdzanie zmian rachunku, komunikat dla personelu, monitoring prób oszustwa.
• Zgłoszenia dokonaj elektronicznie przez serwis biznes.gov.pl (formularz zgłoszenia naruszenia ochrony danych osobowych do UODO). Informacje o sposobie zgłaszania znajdziesz też na stronie uodo.gov.pl.

Krok 4. Do miesiąca i po ustabilizowaniu sytuacji

• Uzupełnij zgłoszenie RODO, jeżeli brakujące dane pojawiły się później.
• Jeżeli dotyczy uKSC, przekaż sprawozdanie końcowe z obsługi incydentu w terminie wskazanym w ustawie. [4]
• Odbierz od dostawcy raport przyczyn źródłowych (RCA), ocenę eksfiltracji, listę działań naprawczych, terminy i dowody testów.
• Zaktualizuj rejestr naruszeń, DPIA albo AIIA, gdy jest stosowna, oraz ocenę dostawcy.
• Przeprowadź przegląd działań: co zadziałało, czego zabrakło, jakie warunki umowne i techniczne trzeba zmienić.
• Zamknij działania dopiero po potwierdzeniu, że ryzyko zostało ograniczone, a nie tylko po otrzymaniu ogólnej odpowiedzi dostawcy.

RODO wymaga dokumentowania wszystkich naruszeń, ich okoliczności, skutków i działań zaradczych. Uzasadnienie braku zgłoszenia lub braku zawiadomienia osób musi być możliwe do wykazania. [1] [3]

6. Pytania do dostawcy: gotowy zestaw

Przedsiębiorca może wysłać dostawcy poniższe pytania jako część audytu albo po istotnym incydencie:

1. Jakie dane, moduły, integracje, środowiska i okresy retencji dotyczą naszego konta?
2. Jakie są parametry SLA (gwarantowanej dostępności usługi) i czy w razie ich niedotrzymania kary umowne wykraczają poza proporcjonalne obniżenie opłaty subskrypcyjnej?
3. Kto ma dostęp uprzywilejowany do produkcji, backupów, kluczy, tokenów i logów; jak ten dostęp jest zatwierdzany i rejestrowany?
4. Czy MFA jest obowiązkowe dla administratorów i wsparcia? Jak wygląda okresowy przegląd uprawnień?
5. Czy dostawca umożliwia oparcie dostępu o konta z systemów klienta (Single Sign-On)?
6. Jak dostawca oddziela dane różnych klientów i jak testuje skuteczność tej separacji?
7. Jakie są RTO, RPO, zasady backupu i ostatni wynik testu odtworzenia?
8. Czy dostawca dysponuje redundantną infrastrukturą, by świadczyć usługi w przypadku awarii w lokalizacji podstawowej?
9. Jak dostawca wykrywa podatności, zarządza aktualizacjami i informuje klientów o krytycznych działaniach po ich stronie?
10. Czy przeprowadzane są (cyklicznie) testy penetracyjne? Czy dostawca może udostępnić ich wyniki?
11. Jakie logi są dostępne dla obsługi incydentu, jak długo są przechowywane i jak dostawca chroni ich integralność?
12. Kto jest podprocesorem, gdzie przetwarza dane i jak dostawca informuje o zmianie podprocesora lub transferu?
13. W jakim czasie dostawca poinformuje o incydencie i jakie informacje przekaże w pierwszej oraz kolejnych aktualizacjach?
14. Czy dostawca ma procedurę RCA oraz plan działań po incydencie z terminami i właścicielami?
15. Czy w usłudze występuje AI? Jeżeli tak: jaki model, jakie dane otrzymuje, czy dane są używane do trenowania, gdzie są przetwarzane i jak można wyłączyć funkcję?
16. Czy dostawca kwalifikuje jakikolwiek komponent jako objęty rozporządzeniem? Jeżeli tak: jaki jest okres wsparcia, punkt kontaktowy ds. podatności i procedura art. 14?
17. Które elementy dostajemy i uruchamiamy u siebie, a które są wyłącznie dostępem przez przeglądarkę?
18. Które funkcje w chmurze są konieczne, żeby ten produkt wykonał swoją funkcję, i kto je zaprojektował?
19. Jaka jest data końca okresu wsparcia i jakie jest uzasadnienie, jeśli okres jest krótszy niż pięć lat albo krótszy niż realne używanie u nas?
20. Czy aktualizacje bezpieczeństwa są nieodpłatne, oddzielone od funkcji i jak jesteśmy o nich informowani? Czy instalacja jest automatyczna i jak z niej zrezygnować?
21. Jaki jest publiczny punkt zgłaszania podatności i jakim kanałem producent poinformuje nas z art. 14 ust. 8, w tym o działaniach po naszej stronie?
22. Jak producent kwalifikuje produkt: zwykły, ważny klasy I, klasy II czy krytyczny, i od kiedy pokaże deklarację zgodności?
23. Jeśli wbudujemy komponent we własny produkt: jakie dowody należytej staranności producent przekaże, w tym oznakowanie komponentu, historię aktualizacji i znane podatności?
24. Jakie certyfikaty, audyty, testy lub inne dowody dostawca może przekazać w formie bezpiecznej dla jego środowiska?
25. Jak dostawca waliduje i zabezpiecza pliki przesyłane przez użytkowników, w tym przed złośliwym oprogramowaniem i niebezpiecznymi formatami?
26. Jak wygląda procedura zakończenia usługi: w jakim terminie dane są zwracane lub usuwane oraz jak potwierdzane jest ich usunięcie, w tym z backupów?
27. Czy w ciągu ostatnich 12 miesięcy wystąpiły incydenty lub podatności, które mogły mieć wpływ na bezpieczeństwo danych lub usługę świadczoną naszej firmie? Jeśli tak, jakie działania naprawcze podjęto?

7. Co należy zaktualizować od razu?

Po obecnych doświadczeniach przedsiębiorca powinien sprawdzić przede wszystkim cztery dokumenty:

• Procedurę wyboru dostawcy: czy wymaga dowodów TOM, a nie tylko oświadczenia o zgodności.
• Procedurę postępowania po incydencie: czy zawiera RODO, kwalifikację uKSC, punkt decyzyjny AI Act i CRA, terminy oraz kontakty.
• Umowę powierzenia i załącznik TOM: czy zapewniają pomoc, informacje, termin powiadomienia, audyt, podprocesorów, backup i wyjście z usługi.
• Zasady komunikacji z klientem: czy chronią przed zmianą rachunku, fałszywą fakturą i phishingiem po wycieku danych.
• Rejestr dostawców i systemów: czy zawiera klasyfikację ryzyka, zakres przetwarzanych danych, podprocesorów, integracji oraz osobę odpowiedzialną za dostawcę.
• Plan ciągłości działania i odtworzenia: czy określa sposób działania w przypadku niedostępności systemu, utraty danych lub niedostępności dostawcy oraz kiedy należy przejść na rozwiązanie awaryjne.
• Rejestr dostawców pod rozporządzeniem: rozdziel dostawców na „produkt uruchamiany u nas” i „sam dostęp przez przeglądarkę”. Przy tych pierwszych potwierdź kontakt do zgłaszania podatności i kanał, którym producent powiadamia użytkowników.

Praktyczny cel: przedsiębiorca powinien umieć w ciągu jednej godziny wskazać, które systemy są krytyczne, kto odpowiada za decyzje, jak ograniczyć dostęp, kto kontaktuje dostawcę i jakie terminy regulacyjne mogą zacząć biec.

8. Ważne zastrzeżenia przed wdrożeniem

Niniejszy pomocnik jest wspólnym minimum. Każdy system wymaga dopasowania do branży, danych, skali, modelu hostingu i roli stron.

Kwalifikację jako podmiot kluczowy lub ważny uKSC trzeba potwierdzić względem działalności, sektora, wielkości i wpisu albo decyzji, a nie na podstawie samego korzystania z oprogramowania. [4]

Samo użycie funkcji AI nie przesądza o kwalifikacji systemu jako wysokiego ryzyka. Najpierw należy ustalić przeznaczenie, rolę przedsiębiorcy i przepisy AI Act mające zastosowanie do danego rozwiązania. [6]

Sama dostępność systemu przez przeglądarkę nie przesądza o CRA. Należy ustalić, czy występuje produkt z elementami cyfrowymi albo zdalne rozwiązanie przetwarzania danych objęte zakresem CRA. [7] [5]

Oświadczenie dostawcy o kwalifikacji produktu jest punktem wyjścia. Gdy klient sam wprowadza produkt na rynek, zmienia jego przeznaczenie albo wbudowuje komponent, kwalifikację trzeba ustalić po swojej stronie.

W przypadku realnego incydentu nie należy czekać na kompletny raport dostawcy, jeżeli istnieje już rozsądny stopień pewności naruszenia. Trzeba wszcząć ocenę i przekazywać informacje etapami, gdy jest to konieczne. [3]

Źródła

1. Rozporządzenie (UE) 2016/679 (RODO), art. 5, 28, 32-35 oraz motywy 81 i 83.
2. Wytyczne 07/2020 dotyczące pojęć administratora i podmiotu przetwarzającego.
3. Wytyczne 9/2022 dotyczące zgłaszania naruszeń ochrony danych osobowych.
4. Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. 2026 poz. 252.
5. Komisja Europejska, wytyczne dotyczące stosowania rozporządzenia, C(2026) 5252, 27 lipca 2026 r.
6. Rozporządzenie (UE) 2024/1689 (AI Act), zarządzanie ryzykiem, cyberbezpieczeństwo i obowiązki operatorów.
7. Rozporządzenie (UE) 2024/2847, zakres, wymagania i obowiązki raportowe, w tym art. 14 ust. 8 i art. 69 ust. 3.