DORA dla CASP: kto naprawdę Cię nadzoruje po paszporcie do Polski

Polska nie ma procedury CASP. Skoro obsługujesz polskich klientów na podstawie autoryzacji uzyskanej gdzie indziej, to komu zgłaszasz poważny incydent ICT – w ciągu czterech godzin, w środku awarii? Odpowiedź nie brzmi „KNF” i zaskakuje niemal wszystkich. A to dopiero pierwsza z dwóch rzeczy, które w DORA zaskakują CASP-y.

Twoim nadzorcą DORA nie jest KNF

Zacznijmy od miejsca, w którym rynek się myli, bo skutki są operacyjne, nie akademickie.

Ustawa o rynku kryptoaktywów została zawetowana trzykrotnie – ostatnio 11 czerwca 2026 – a okres przejściowy MiCA wygasł 1 lipca 2026. Polska nie wyznaczyła organu właściwego dla CASP. W efekcie każdy, kto dziś obsługuje polskich klientów, robi to na autoryzacji z innego państwa członkowskiego, paszportowanej do Polski na podstawie art. 65 MiCA.

Teraz pytanie, którego prawie nikt sobie nie zadaje: kto nadzoruje zgodność takiego podmiotu z DORA?

Art. 46 lit. d DORA wskazuje, że dla dostawców usług w zakresie kryptoaktywów i emitentów tokenów powiązanych z aktywami organem właściwym jest organ wyznaczony zgodnie z MiCA – czyli organ państwa macierzystego. CASP autoryzowany na Cyprze, w Estonii czy na Litwie i paszportujący do Polski zgłasza poważne incydenty ICT swojemu organowi macierzystemu i tam składa rejestr informacji o dostawcach ICT. KNF, nie mając mandatu CASP z MiCA, nie jest jego nadzorcą DORA.

To nie jest ciekawostka kompetencyjna. To przesądza, komu zawiadamiasz o incydencie w ciągu czterech godzin, w jakim języku i na czyim wzorze. Firma, która założyła, że „skoro obsługujemy polskich klientów, to sprawa jest u KNF”, ma w playbooku wpisanego złego regulatora – i dowie się o tym w trakcie awarii, czyli w najgorszym możliwym momencie.

Bo najpierw: DORA w ogóle Cię dotyczy

Warto się cofnąć, bo połowa rynku nadal traktuje DORA jak politykę cyberbezpieczeństwa do napisania w jedno popołudnie.

DORA – rozporządzenie (UE) 2022/2554 – obowiązuje od 17 stycznia 2025, a jej przepis o zakresie nie traktuje krypto jako przypadku szczególnego. Art. 2 ust. 1 lit. f umieszcza dostawców usług w zakresie kryptoaktywów autoryzowanych na podstawie MiCA oraz emitentów tokenów powiązanych z aktywami na tej samej liście co banki, instytucje płatnicze i firmy inwestycyjne. Art. 2 ust. 2 nazywa wszystko z tej listy, łącznie, „podmiotami finansowymi”.

Reżim odporności operacyjnej, który stosuje się do banku, stosuje się więc do Ciebie. Nie jego złagodzona wersja. To samo rozporządzenie.

Odruchowa reakcja małego CASP-a jest taka, że przecież musi istnieć furtka proporcjonalności dla spółki z jedenastoma osobami i jednym produktem. Zasada proporcjonalności istnieje (art. 4), pojęcie mikroprzedsiębiorstwa istnieje (art. 3 pkt 60) – i oba dają mniej, niż founderzy zakładają. Tu jest druga pułapka.

Pułapka z art. 16

DORA zawiera realnie lżejszy reżim: uproszczone ramy zarządzania ryzykiem ICT z art. 16. Podmioty, które się do nich kwalifikują, są w ogóle zwolnione z art. 5–15 i prowadzą zamiast tego proporcjonalne ramy określone w rozporządzeniu delegowanym (UE) 2024/1774.

To jest realna ulga i nie jest dla Ciebie.

Art. 16 ust. 1 wymienia typy podmiotów, które ją dostają: małe i niepowiązane wzajemnie firmy inwestycyjne, instytucje płatnicze i instytucje pieniądza elektronicznego objęte wyłączeniem, niektóre małe IORP-y i kilka innych kategorii. CASP-ów na tej liście nie ma. Lista jest zamknięta i żadna skala działalności na nią nie wprowadza.

Konsekwencja jest precyzyjna i wbrew intuicji:

Czteroosobowa instytucja płatnicza objęta wyłączeniem dostaje art. 16. Czteroosobowy CASP – nie. Ta sama liczba osób, inny reżim, bo ustawodawca napisał listę, a krypto się na niej nie znalazło.

Co więc realnie daje status mikroprzedsiębiorstwa?

Listę krótką i mało efektowną. Jako mikroprzedsiębiorstwo-CASP jesteś zwolniony z:

• wyodrębnionej roli monitorującej dostawców ICT – art. 5 ust. 3 odnosi się wprost do „podmiotów finansowych innych niż mikroprzedsiębiorstwa”, więc nie musisz tworzyć osobnej funkcji ani wyznaczać członka kadry kierowniczej do monitorowania umów z dostawcami ICT (samo ryzyko nadal musisz zarządzać na podstawie art. 28–30);
• funkcji zarządzania kryzysowego uruchamiającej plany ciągłości działania ICT (art. 11 ust. 6);
• regularnych audytów wewnętrznych ram zarządzania ryzykiem ICT oraz okresowych analiz ryzyka systemów odziedziczonych (legacy) – przeprowadzasz je, gdy uzasadnia to plan audytu lub profil ryzyka, a nie w stałym cyklu;
• zawiadamiania organu o zmianach wprowadzonych po przeglądach poincydentalnych oraz szacowania zagregowanych rocznych kosztów i strat z tytułu poważnych incydentów;
• podstawowego programu testowania odporności operacyjnej cyfrowej z art. 24, który stosuje się do podmiotów finansowych „innych niż mikroprzedsiębiorstwa”.

Reszta zostaje: ramy zarządzania, identyfikacja i klasyfikacja aktywów, ochrona, wykrywanie, reagowanie i odtwarzanie, kopie zapasowe, uczenie się, bezpieczne wytwarzanie oprogramowania, klasyfikacja i zgłaszanie incydentów oraz pełny reżim ryzyka stron trzecich.

A proporcjonalność (art. 4) nie jest furtką, za którą się ją bierze. Pozwala skalować głębokość kontroli do rozmiaru i profilu ryzyka – ale wymaga, byś każde uproszczenie udokumentował i uzasadnił, przepis po przepisie. Organy nie karzą za lekki setup; karzą za brak analizy, która tłumaczy, dlaczego jest lekki. „Jesteśmy mali, więc zrobiliśmy mniej”, nieudokumentowane, jest tu trybem awarii.

Zarząd odpowiada osobiście

Art. 5 ust. 2 to przepis, który zmienia rozmowy na posiedzeniach zarządu. Organ zarządzający musi „określić, zatwierdzić, nadzorować i odpowiadać za wdrożenie” wszystkich rozwiązań składających się na ramy zarządzania ryzykiem ICT i ponosi ostateczną odpowiedzialność za ryzyko ICT. Zatwierdza strategię odporności operacyjnej cyfrowej i tolerancję ryzyka ICT, plany ciągłości działania i odtwarzania, plan audytu ICT, budżet ICT oraz politykę dotyczącą dostawców ICT.

Art. 5 ust. 4 idzie dalej: członkowie organu zarządzającego muszą utrzymywać wystarczającą wiedzę i umiejętności w zakresie ryzyka ICT, przez regularne szkolenia proporcjonalne do zarządzanego ryzyka. W zestawieniu z reżimem sankcyjnym z art. 50–52 – który wprost pozwala państwom członkowskim wprowadzić sankcje karne za poważne naruszenia – jest to przepis o odpowiedzialności osobistej, nie o delegowaniu. „Tym zajmuje się CTO” nie jest odpowiedzią, którą zarząd może dać.

Zgłaszanie incydentów: zegar jest krótki

Dla poważnych incydentów związanych z ICT (klasyfikowanych według kryteriów z rozporządzenia delegowanego (UE) 2024/1772 – liczba dotkniętych klientów, czas przestoju, utrata danych, zasięg geograficzny, skutki ekonomiczne) kaskada zgłoszeń wygląda tak:

Zgłoszenie	Termin
Zgłoszenie wstępne	w ciągu 4 godzin od zaklasyfikowania incydentu jako poważny, nie później niż 24 godziny od powzięcia wiadomości
Zgłoszenie pośrednie	w ciągu 72 godzin od zgłoszenia wstępnego
Zgłoszenie końcowe	w ciągu miesiąca od zamknięcia incydentu, z analizą przyczyn źródłowych i pełnymi danymi o skutkach

Czterech godzin nie improwizuje się w dniu zdarzenia. To oznacza, że kryteria klasyfikacji są zmapowane wcześniej, wzór jest wypełniony w takim zakresie, w jakim się da, a ktoś wie – o trzeciej w nocy, w trakcie awarii – kto decyduje, że ten incydent jest „poważny”, i kto go zgłasza. Tym adresatem, przypomnijmy, jest Twój organ macierzysty, nie KNF. To drzewo decyzyjne jest tu produktem, a nie dokument, który je opisuje.

Ryzyko stron trzecich: rejestr i umowy

Tu pliki CASP-ów są najcieńsze, bo to część, która sięga poza spółkę.

Rejestr informacji (art. 28). Prowadzisz rejestr wszystkich umów o świadczenie usług ICT i składasz go organowi właściwemu co najmniej raz do roku. Zgodnie ze wzorami z ITS obejmuje on każdego dostawcę, usługi i ich krytyczność, miejsce świadczenia usługi i przetwarzania danych, łańcuch podwykonawców, daty rozpoczęcia i zakończenia, strategie wyjścia oraz wskazanie, które umowy wspierają funkcje krytyczne lub istotne. Dla CASP-a działającego na infrastrukturze chmurowej, z dostawcą technologii custody, dostawcą analityki łańcucha i dostawcą KYC rejestr nie jest formalnością – to mapa Twojej faktycznej struktury zależności, a większość firm nigdy jej nie narysowała.

Umowy (art. 30). Art. 30 ust. 2 określa obowiązkowe postanowienia dla każdej umowy ICT: opis usług, warunki podwykonawstwa, miejsca świadczenia usługi i przetwarzania danych wraz z uprzednim powiadomieniem o ich zmianie, zabezpieczenie dostępności i integralności danych, poziomy usług wraz z konsekwencjami ich naruszenia, wsparcie przy incydentach, współpracę z organami oraz prawa do wypowiedzenia z okresami wypowiedzenia.

Art. 30 ust. 3 dokłada, dla usług ICT wspierających funkcje krytyczne lub istotne: ilościowe cele poziomu usług, obowiązki informacyjne o zdarzeniach wpływających na zdolność dostawcy, planowanie i testowanie ciągłości działania, nieograniczone prawa dostępu, inspekcji i audytu dla Ciebie i dla organu właściwego, współpracę przy TLPT tam, gdzie ma zastosowanie, oraz wsparcie strategii wyjścia.

Zestaw tę listę ze standardowym regulaminem dużego dostawcy chmury albo dostawcy technologii custody, a luka rzuca się w oczy. Tych klauzul nie ma w pudełku. Zdobycie ich wymaga albo negocjacji, albo – gdy kontrahent nie ustąpi – udokumentowanej oceny ryzyka rezydualnego i strategii wyjścia, która jest realna. Umowy, które podpisujesz w tym roku, to umowy, które przeczyta Twój nadzorca.

TLPT (art. 26–27) – testy penetracyjne oparte na scenariuszach zagrożeń, w cyklu trzyletnim, zgodne z TIBER-EU – dotyczą wyłącznie podmiotów wyznaczonych przez organ właściwy jako istotne. Większość CASP-ów wyznaczona nie będzie. Duży CASP prowadzący infrastrukturę custody, obrotu lub płatności w kilku państwach członkowskich to inna rozmowa.

DORA a wniosek licencyjny MiCA

Art. 62 MiCA nie wspomina o DORA. Wymaga natomiast, między innymi, programu działalności, struktury organizacyjnej, mechanizmów kontroli wewnętrznej oraz polityk i procedur identyfikacji, zarządzania i ograniczania ryzyka ICT i operacyjnego, a także rozwiązań dotyczących zabezpieczenia aktywów klientów i outsourcingu.

W praktyce to jeden i ten sam dokument. Organy rozpatrujące wnioski w latach 2025–2026 oczekują ładu ICT i odporności spójnych z DORA, a krajowe formularze już dziś wymagają opisu systemów ICT, polityk bezpieczeństwa, zarządzania incydentami, kopii zapasowych i outsourcingu ICT. Pełna zgodność z DORA nie jest formalnym warunkiem autoryzacji MiCA – oba reżimy są prawnie niezależne – ale autoryzowany CASP staje się podmiotem finansowym w rozumieniu DORA pierwszego dnia, a wniosek pokazujący wiarygodne ramy zgodne z DORA przechodzi przez postępowanie wyraźnie szybciej niż taki, który traktuje ICT jak załącznik.

Praktyczny wniosek: buduj ramy DORA jako sekcję ICT wniosku MiCA, a nie po nim. Robienie tego dwa razy jest drogą kosztowną, a robienie tego po fakcie to sposób, w jaki CASP zostaje autoryzowany i niezgodny z przepisami w tym samym kwartale.

Jedna nakładka warta nazwania: każdy system AI, który uruchamiasz – monitoring transakcji, nadzór nad rynkiem, asystent w obsłudze klienta – jest zasobem ICT w zakresie DORA, a AI Act dokłada do niego kontrole specyficzne dla AI, zamiast je zastępować. Ci sami dostawcy, ten sam rejestr, jeden framework. Tę granicę opisuję osobno.

Od czego bym zaczął

Jeśli jesteś CASP-em – autoryzowanym, składającym wniosek albo dopiero planującym – kolejność, która działa:

• Ustal, kto Cię nadzoruje. Przy paszporcie do Polski to organ macierzysty (art. 46 lit. d DORA), nie KNF. Wpisz go do playbooka incydentalnego, zanim będzie potrzebny.
• Potwierdź swój reżim. Jesteś podmiotem finansowym z art. 2 ust. 1 lit. f. Nie jesteś podmiotem z art. 16, niezależnie od liczby etatów. Rozstrzygnij to, zanim ktokolwiek zacznie pisać polityki na złym wzorcu.
• Narysuj mapę zależności. Rejestr z art. 28, zrobiony uczciwie, razem z łańcuchami podwykonawców. Powie Ci, które funkcje są krytyczne lub istotne, a ta klasyfikacja napędza wszystko dalej.
• Przeczytaj umowy z dostawcami pod art. 30 ust. 2 i 3. Zrób listę luk. Zdecyduj, dostawca po dostawcy: negocjujesz, akceptujesz i dokumentujesz, czy wychodzisz.
• Zbuduj drzewo decyzyjne przy incydencie. Kto klasyfikuje, kto zgłasza, na jakim wzorze, w cztery godziny.
• Oddaj to zarządowi. Art. 5 ust. 2 oznacza, że organ zarządzający zatwierdza strategię i przejmuje ryzyko – a art. 5 ust. 4, że musi mieć szkolenie, by robić to wiarygodnie.
• Wepnij to we wniosek MiCA. Jeden framework, jeden zestaw dokumentów, jedno postępowanie.

Nic z tego nie jest egzotyczne. Jest nieefektowne, zajmuje więcej czasu, niż founderzy budżetują, i jest tą częścią pliku CASP, którą regulatorzy czytają uważnie – bo to część, którą większość wnioskodawców skądś przepisuje.

Pełny obraz polskiej luki legislacyjnej i ścieżki paszportowej znajdziesz na hubie o licencji CASP.