Co regulacja wymaga, co rynek deklaruje, gdzie pęka cienka linia danych.
Streszczenie
W pilotażu Rejestru Informacji o dostawcach ICT, przeprowadzonym przez europejskie organy nadzoru (ESAs) od kwietnia do sierpnia 2024 roku, blisko 94% przesłanych rejestrów – a dokładniej 93,5% – zawierało co najmniej jeden błąd w danych; wszystkie 116 kontroli jakości przeszło bezbłędnie zaledwie 6,5% zgłoszeń (wyniki opublikowano w grudniu 2024 roku). Powodem nie były błędy koncepcyjne ani luki w politykach bezpieczeństwa, lecz pojedyncze, techniczne nieścisłości w danych: kod LEI niezgodny z bazą GLEIF (Global Legal Entity Identifier Foundation), niespójnie używany numer umowy (CARN – Contractual Arrangement Reference Number), klasyfikacja krytyczności funkcji (CIF) rozjeżdżająca się między szablonami. Rok później, w pierwszym obowiązkowym cyklu raportowania z terminem 30 kwietnia 2025 roku, problem nie zniknął; od 35% do 50% umów w rejestrach wciąż miało co najmniej jedno brakujące lub niepoprawne pole obowiązkowe, a część zgłoszeń odpadała jeszcze przed analizą jakości, na etapie walidacji technicznej. Instytucje nie pomyliły się w tym, co robią, ale pomyliły się w tym, jak poprawnie opisać to, co już robią, w formacie, który automatycznie zwalidują systemy nadzorcy.
Analiza Sanmargar potwierdza, że dane referencyjne odpowiadają za ponad 70% rzeczywistych wymagań DORA – głównie przez dwa obszary: rejestr RoI (art. 28) i inwentarz aktywów ICT z klasyfikacją CIF (art. 8). Ankieta wśród instytucji objętych DORA odtwarza ten sam wzorzec: wysoka deklarowana gotowość, niska operacyjna dojrzałość w zarządzaniu identyfikatorami i integracji danych między systemami.
Artykuł stawia pięć pytań kontrolnych dla zarządu i CIO/CDO przed końcem 2026 roku oraz przedstawia trzy scenariusze kosztowe braku zgodności. Rozwiązaniem proponowanym przez Sanmargar jest Metastudio DRM – warstwa danych referencyjnych spinająca TPRM, CMDB i raportowanie incydentów, z walidacją LEI względem GLEIF i zarządzaniem identyfikatorami CARN/EUID.
Zacznijmy od faktycznych wymogów DORA.
Co oznacza wdrożenie DORA w praktyce
Pięć filarów DORA i ich powiązanie z danymi referencyjnymi:
Filar | Obszar | Artykuły | Co waży najwięcej |
|---|---|---|---|
1 | Zarządzanie ryzykiem ICT | 5–16 | Inwentarz aktywów (art. 8) i klasyfikacja CIF. Fundament dla pozostałych filarów. |
2 | Raportowanie incydentów | 17–23 | Trzy raporty do NCA: Initial 4 h (od zaklasyfikowania jako poważny), Interim 72 h, Final 1 miesiąc. Pola LEI, ID aktywów, dostawcy. |
3 | Testowanie odporności | 24–27 | Coroczne testy systemów wspierających funkcje krytyczne lub istotne (CIF), TLPT co 3 lata dla większych. Zakres = inwentarz + RoI. |
4 | Ryzyko stron trzecich (TPRM) | 28–44 | Rejestr RoI – 15 szablonów (grupy B_01–B_07, Załączniki I–IV). LEI, EUID, CARN, ISO 3166, ISO 4217. |
5 | Wymiana informacji | 45 | Dobrowolna wymiana threat intelligence. Uczestnictwo zgłaszane do NCA. |
Rozporządzenie (UE) 2022/2554 obowiązuje od 17 stycznia 2025 roku. 64 artykuły, 9 rozdziałów, 22 kategorie podmiotów objętych. Zasada proporcjonalności z art. 4 różnicuje głębokość wdrożenia, ale nie zwalnia z żadnego z pięciu filarów – praktycznie wszystkie instytucje powyżej kategorii „mikro” wpadają w pełną ramę zarządzania ICT zgodnie z unijnymi przepisami technicznymi do DORA dotyczącymi zarządzania ryzykiem IT – RTS 2024/1774.
Pięć wierszy w tabeli wygląda jak pięć niezależnych projektów. Nie są niezależne – to system naczyń połączonych. Decyzja klasyfikacyjna w inwentarzu z art. 8 wyznacza zakres testów (art. 25), zawartość szablonów rejestru RoI (art. 28), zakres TLPT (art. 26) i klauzule umowne z dostawcami (art. 30). Jedna pomyłka klasyfikacyjna sprzed dwóch lat propaguje się dziś przez wszystkie pięć filarów naraz.
To samo dotyczy raportowania incydentu – i to jest miejsce, gdzie ta tabela przestaje być teorią. Po zakwalifikowaniu incydentu jako poważny instytucja ma zaledwie 4 godziny na złożenie pierwszego zgłoszenia do nadzoru (tzw. Initial Notification). W tak krótkim czasie musi jednocześnie podać kilka precyzyjnych danych: własny numer LEI, identyfikatory systemów IT, których dotyczy incydent (ze swojego spisu zasobów), oraz numery LEI zaangażowanych dostawców (z Rejestru Informacji, RoI). Cztery godziny to za mało, żeby w tym momencie zbierać i scalać dane z rozproszonych arkuszy Excela – muszą być przygotowane wcześniej. To jest czas na automatyczne pobranie danych z poprawnie zasilonych rejestrów. Ten brak właśnie się zmaterializował – i ma liczbę.
Dlaczego w ramach DORA odrzucono 94% zgłoszeń RoI
W pilotażu Rejestru Informacji o dostawcach ICT, przeprowadzonym przez europejskie organy nadzoru (ESAs) od kwietnia do sierpnia 2024 roku, blisko 94% przesłanych rejestrów – a dokładnie 93,5% – zawierało co najmniej jeden błąd w danych; wszystkie 116 kontroli jakości przeszło bezbłędnie zaledwie 6,5% zgłoszeń (wyniki opublikowano w grudniu 2024 roku). Powodem nie były błędy koncepcyjne ani luki w politykach bezpieczeństwa, lecz pojedyncze, techniczne nieścisłości w danych: kod LEI niezgodny z bazą GLEIF (Global Legal Entity Identifier Foundation), niespójnie używany numer umowy (CARN – Contractual Arrangement Reference Number), klasyfikacja krytyczności funkcji (CIF) rozjeżdżająca się między szablonami. Rok później, w pierwszym obowiązkowym cyklu raportowania z terminem 30 kwietnia 2025 roku, problem nie zniknął – od 35% do 50% umów w rejestrach wciąż miało co najmniej jedno brakujące lub niepoprawne pole obowiązkowe, a część zgłoszeń odpadała jeszcze przed analizą jakości, na etapie walidacji technicznej. Instytucje nie pomyliły się w tym, co robią, ale pomyliły się w tym, jak poprawnie opisać to, co już robią, w formacie, który automatycznie zwalidują systemy nadzorcy.
Wniosek: o tym, czy zgłoszenie RoI przejdzie walidację, decyduje jakość danych referencyjnych.
Ale o czym to właściwie świadczy – o jednorazowym problemie technicznym pilotażu, czy o szerszym wzorcu w całym sektorze? Chcieliśmy to sprawdzić w swojej ankiecie, pytając menedżerów i specjalistów z instytucji objętych DORA.
Co pokazała ankieta wśród instytucji objętych DORA
Próba skromna: 16 rekordów, ale diagnostycznie wymowna. Niezależne badanie polskich firm komercyjnych z marca 2026 roku pokazuje tę samą tendencję w badaniu jakościowym, czyli: wysoki poziom formalnego dostosowania instytucji do wymogów DORA, ale braki w operacyjnej dojrzałości, szczególnie w obszarze testowania odporności i zarządzania dostawcami.
Wyniki ankiety wskazały sześć obszarów, w których deklaracja różni się od praktyki. Zacznijmy od najbardziej jaskrawej rozbieżności, bo otwiera ona drzwi do kolejnych. Czy polityki istnieją?
Dlaczego deklaracja zakończonego wdrożenia nie oznacza posiadania podstawowych polityk ICT
Wszyscy respondenci, pytani na wstępie o etap wdrożenia, deklarują „etap zakończony – monitoring”. Te same osoby, w kolejnych pytaniach tej samej ankiety, opowiadają inną historię:
- Polska firma zatrudniająca ponad 10 tys. osób: brak polityki bezpieczeństwa informacji, brak polityki incydentów ICT, brak planu BCP/DRP, brak polityki klasyfikacji danych. Cztery z sześciu fundamentalnych polityk wymaganych przez art. 5–7 – formalnie niewdrożone.
- Średnia instytucja unijna: niska jakość danych identyfikacyjnych, niska spójność danych między systemami, duże trudności interpretacyjne wokół CIF i RoI. Pytanie o gotowość raportowania incydentów do właściwego organu krajowego pozostało bez odpowiedzi.
- Ta sama polska firma, pytana o narzędzia obsługi incydentów: arkusze Excel i dokumenty ręczne. Bez SIEM (Security Information and Event Management – systemu wykrywania zdarzeń bezpieczeństwa), bez SOAR (Security Orchestration, Automation and Response – automatyzacji reagowania na incydenty), bez ITSM (IT Service Management – systemu zarządzania zgłoszeniami i obsługą incydentów IT).
Wniosek: deklaracja etapu wdrożenia mierzy status projektu, nie istnienie wymaganych polityk.
Polityka to jedna warstwa problemu. Znajomość przepisów wykonawczych, które te polityki powinny wypełniać treścią, to druga kwestia.
Dlaczego znajomość pięciu filarów DORA nie oznacza znajomości aktów wykonawczych RTS/ITS
Deklarowana znajomość pięciu filarów jest wysoka – to poziom, na którym rozmawia się o DORA w mediach branżowych i na konferencjach. Znajomość aktów wykonawczych drugiego poziomu, czyli konkretnych RTS i ITS wydanych przez EBA, ESMA i EIOPA, jest nierównomierna:
Znajomość aktów wykonawczych drugiego poziomu (RTS/ITS) w badanej próbie:
Standard | Co reguluje | Znany w próbie |
|---|---|---|
RTS 2024/1774 | Pełna rama zarządzania ryzykiem ICT (w tym rama uproszczona) | 3 / 5 |
RTS 2024/1773 | Polityka korzystania z usług dostawców ICT wspierających funkcje krytyczne lub istotne | 3 / 5 |
RTS 2025/301 (+ ITS 2025/302) | Treść i terminy raportowania incydentów | 3 / 5 |
RTS 2024/1772 | Kryteria klasyfikacji poważnych incydentów ICT i cyberzagrożeń | 2 / 5 |
ITS 2024/2956 | Szablony rejestru RoI (15 szablonów, Załączniki I–IV) | 2 / 5 |
RTS 2025/1190 | Elementy TLPT (zaawansowane testy penetracyjne) | 1 / 5 |
Wniosek: znajomość ogólnych ram regulacji nie oznacza znajomości konkretnych przepisów wykonawczych, które trzeba zastosować w praktyce.
Nierówna znajomość standardów jest niebezpieczna. Organizacje przeczytały te przepisy, które musiały przeczytać, żeby zbudować rejestr i polityki na konkretną datę graniczną. Te zaś, które dotyczą obsługi incydentu oraz TLPT (Threat-Led Penetration Testing – zaawansowanych testów penetracyjnych prowadzonych według scenariuszy realnych zagrożeń), ujawnią swoją nieznajomość dopiero w kryzysie albo w trzyletnim cyklu testów, kiedy jest już za późno.
Praktyczne konsekwencje: w realnym incydencie zespół, który nie znał RTS 2024/1772, może błędnie zaklasyfikować zdarzenie i albo nie uruchomić obowiązku raportowania, albo eskalować coś, co eskalacji nie wymagało. Pierwsze to ryzyko regulacyjne. Drugie to koszt operacyjny. Oba wynikają z tej samej, niewidocznej dziś nierówności w tabeli powyżej.
Jak jedna decyzja klasyfikacyjna CIF generuje pięć równoległych obowiązków
Klasyfikacja CIF nie ma jednego dedykowanego RTS – jej podstawą jest definicja w art. 3 oraz wymóg identyfikacji i klasyfikacji z art. 8 DORA. To właśnie ten punkt, w którym jedna decyzja generuje skutki w pięciu różnych miejscach systemu naraz.
Wniosek: błąd popełniony przy jednej klasyfikacji CIF nie zostaje w jednym miejscu – propaguje się przez pięć artykułów regulacji jednocześnie.
Skala wyzwań rośnie wraz ze wzrostem rozmiarów organizacji. Globalna firma zatrudniająca ponad 10 000 osób deklaruje wysoką dojrzałość ewidencji dostawców we wszystkich pięciu badanych wymiarach. Polska firma tej samej wielkości deklaruje wysoką dojrzałość w trzech, a jedynie częściową tam, gdzie trzeba spiąć dwie rzeczy: wewnętrzną bazę zasobów IT (CMDB, Configuration Management Database – ewidencję systemów, serwerów i aplikacji firmy) z Rejestrem Informacji o dostawcach ICT (RoI). Średnia instytucja unijna wypada słabo w trzech obszarach naraz: w klasyfikowaniu, które funkcje są krytyczne lub istotne (CIF, Critical or Important Function), w aktualizowaniu danych po każdej zmianie oraz w powiązaniu ewidencji z Rejestrem. Co więcej, samo przypisanie statusu krytyczności funkcji przy budowie rejestru wskazuje jako największe wyzwanie w całej ankiecie.
Tę samą hierarchię widać w narzędziach. Globalny bank korzysta z dedykowanego systemu zarządzania danymi referencyjnymi, który pilnuje, by kluczowe dane o dostawcach były spójne w całej organizacji. Polski bank łączy trzy źródła: system zakupowy (eProcurement), narzędzie do oceny ryzyka dostawców (TPRM, Third-Party Risk Management) i Excel. Średnia instytucja ma sam system zakupowy.
Tu pojawia się problem strukturalny. Średnie instytucje finansowe, zatrudniające od 5 000 do 10 000 osób, nie kwalifikują się do uproszczonej, lżejszej wersji wymogów (RTS 2024/1774), więc obowiązuje je pełny zakres – taki sam jak w największych bankach. Bez uporządkowanej warstwy danych referencyjnych utrzymanie zgodności w cyklu rocznym staje się dla nich ekonomicznie niemożliwe.
Polski bank, który z klasyfikacją krytyczności funkcji radzi sobie tylko częściowo, do budowy Rejestru Informacji sięga po połączenie systemu zakupowego, narzędzia oceny ryzyka dostawców i Excela. I ten sam Excel wraca tam, gdzie błąd jest najdroższy – w zarządzaniu incydentami.
Dlaczego bank zatrudniający ponad 10 000 osób zarządza incydentami ICT w Excelu, nie w SIEM
Polski bank zatrudniający ponad 10 000 osób, zapytany o narzędzia do zarządzania incydentami informatycznymi (ICT), wskazał arkusze Excel i dokumenty wypełniane ręcznie oraz jedno dedykowane narzędzie raportowe. Nie zaznaczył żadnego z trzech kluczowych systemów: SIEM (Security Information and Event Management – systemu wykrywającego incydenty na podstawie zdarzeń z całej infrastruktury IT), SOAR (Security Orchestration, Automation and Response – narzędzia automatyzującego reakcję na te incydenty) ani ITSM (IT Service Management – systemu rejestrującego i prowadzącego obsługę zgłoszeń IT). To nie jest obraz instytucji, która nie inwestuje w bezpieczeństwo – to obraz instytucji, która do raportowania regulacyjnego używa tego samego narzędzia, które już raz okazało się źródłem błędów w pilotażu Rejestru Informacji o dostawcach ICT (RoI).
Wniosek: narzędzie (Excel), które zawiodło w jednym procesie regulacyjnym, jest wciąż podstawowym narzędziem w drugim.
Ten sam bank nie utrzymuje aktualnego numeru LEI (Legal Entity Identifier – globalnego identyfikatora firmy) swojej własnej instytucji. Drugi badany podmiot, z innego kraju UE, podobnie. Na trzech respondentach tylko globalny bank spoza Unii utrzymuje pełny komplet identyfikatorów. To wyraźny sygnał przewagi instytucji globalnych w obszarze danych referencyjnych – polskie i mniejsze podmioty unijne startują z gorszej pozycji.
Założenie, że DORA (unijne rozporządzenie o cyfrowej odporności operacyjnej sektora finansowego) nie wymusi zmiany w technologii – „SIEM mamy, polityki mamy, raporty wygenerujemy ręcznie” – nie wytrzyma kolejnych rocznych cykli przesyłania Rejestru Informacji o dostawcach ICT (RoI). Margines błędu będzie się zawężał, a pierwsze kary administracyjne nałożone na instytucje finansowe przeniosą tę dyskusję o budżecie z poziomu teoretycznego na bardzo praktyczny.
Skoro samo „mamy już SIEM” nie wystarcza, nasuwa się naturalne pytanie: w co rynek faktycznie inwestuje na 2026 rok, żeby tę lukę zamknąć? Odpowiedź ujawnia kolejną, jeszcze bardziej zaskakującą rozbieżność.
Dlaczego rynek inwestuje w TPRM, SIEM i CMDB, ale nie w warstwę integrującą dane referencyjne
W tym punkcie respondenci są zgodni. Jako priorytet inwestycyjny „wysoki” w horyzoncie 12–24 miesięcy wskazują trzy obszary: platformę do zarządzania ryzykiem dostawców (TPRM), na której opiera się Rejestr Informacji o dostawcach ICT (RoI) – wskazana przez dwóch z trzech; system wykrywania incydentów lub automatyzacji reakcji na nie (SIEM albo SOAR) – wskazany przez dwóch z trzech; wewnętrzną bazę zasobów IT lub system obsługi zgłoszeń (CMDB albo ITSM) – wskazany przez dwóch z trzech. Centralne zarządzanie danymi referencyjnymi i identyfikatorami jako nowe wdrożenie – zero wskazań.
Wszyscy badani planują projekty poprawy jakości danych referencyjnych. Dwóch z trzech zamierza zintegrować swoje systemy – narzędzia do zarządzania danymi, systemy nadzoru zgodności i ryzyka (GRC, Governance, Risk and Compliance), platformy oceny ryzyka dostawców (TPRM) oraz bazy zasobów IT (CMDB). Centralnej warstwy, która spinałaby te dane w jedną całość, nie planuje zbudować od zera nikt.
Wniosek: plany inwestycyjne adresują warstwę wykonawczą, pomijają warstwę, która te dane faktycznie łączy.
Architektura DORA, jak opisuje ją analiza Sanmargar, ma pięć warstw:
- identyfikatory podmiotów,
- słownik i taksonomię ICT,
- inwentarz aktywów i CMDB,
- rejestr dostawców RoI,
- system raportowania incydentów.
Bez pierwszych dwóch – centralnego zarządzania identyfikatorami i klasyfikacjami – pozostałe trzy są wyspami, między którymi dane trzeba przenosić ręcznie.
Konsekwencja dla budżetu na 2026 rok jest następująca: dotychczasowe inwestycje w narzędzia do zarządzania ryzykiem dostawców, wykrywania incydentów i ewidencji zasobów IT są zasadne, ale niekompletne. Bez równoległej inwestycji w warstwę, która spina te dane w jedną całość, wydatki nie przyniosą zakładanego zwrotu. Można mieć najlepszą na rynku platformę zarządzania ryzykiem dostawców i wciąż przesyłać Rejestr Informacji odrzucany przez krajowy nadzór, bo dane o tym samym dostawcy w jednym systemie nie zgadzają się z danymi w drugim. Pytanie, które powinno paść przy ocenie budżetu, nie brzmi: „czy mamy narzędzia”. Brzmi: „czy ten sam numer identyfikacyjny dostawcy (LEI) występuje spójnie we wszystkich systemach, które go używają?”.
To pytanie samo w sobie jest dobrym testem, a sposób, w jaki organizacje na niego reagują, prowadzi do ostatniej obserwacji z ankiety – najbardziej diagnostycznej ze wszystkich.
Czy brak zapotrzebowania na wsparcie zewnętrzne oznacza dojrzałość organizacji
W ankiecie pytaliśmy, w których obszarach organizacje potrzebują wsparcia z zewnątrz. Respondenci zaznaczyli: opracowanie polityk, testy odporności, interpretację RTS/ITS. Średnia instytucja unijna, która we wcześniejszych pytaniach deklarowała duże trudności w klasyfikacji CIF i słabą jakość danych, zaznaczyła zero obszarów.
Wniosek: brak zgłaszanej potrzeby wsparcia nie jest dowodem samowystarczalności organizacji – częściej jest dowodem, że nie wie ona, gdzie szukać pomocy, ani co na rynku adresuje jej konkretny problem.
Dlatego wskazówka dla zarządu nie brzmi „czy potrzebujecie wsparcia”. Brzmi: czy w ostatnich dwunastu miesiącach niezależny podmiot przeprowadził audyt jakości danych w waszym rejestrze RoI, a wynik trafił do zarządu. Jeśli nie – luka jest właśnie tam.
Obserwacje z ankiety układają się w jeden schemat: rozdźwięk między deklaracją gotowości a operacyjną rzeczywistością pojawia się w tym samym, powtarzalnym miejscu – w danych referencyjnych. To jest mechanizm, który stoi za wszystkimi pozostałymi – i ma swoją liczbę.
Dlaczego dane referencyjne odpowiadają za 70% wymagań DORA
Macierz wpływu DORA na zarządzanie danymi referencyjnymi, opracowana przez Sanmargar, przypisuje maksymalną wagę dwóm obszarom: rejestrowi RoI (art. 28 i ITS 2024/2956) oraz inwentarzowi aktywów ICT z klasyfikacją CIF (art. 8). Łącznie te dwa obszary generują ponad 70% rzeczywistych wymagań wobec architektury danych w całej regulacji. Sześć obserwacji z ankiety to ten sam mechanizm widziany sześć razy z różnych perspektyw.
Ankieta potwierdza to trzema konkretnymi wskazaniami:
- Spójność danych o podmiotach między systemami ERP (system zarządzania zasobami przedsiębiorstwa), narzędziem do obsługi zgłoszeń IT oraz systemem nadzoru zgodności i ryzyka – dwóch na trzech respondentów ocenia jako niską.
- W kwestii identyfikatorów regulacyjnych nie ma wspólnego standardu. Jedna instytucja utrzymuje własny numer identyfikacyjny firmy (LEI) oraz numery swoich umów z dostawcami (CARN), druga – numery LEI dostawców i europejski identyfikator z rejestrów handlowych (EUID), trzecia jeszcze inną kombinację. Pełnego kompletu – własnego LEI, LEI dostawców, EUID, numerów umów oraz standardowych kodów krajów i walut (normy ISO 3166 i ISO 4217) – nie utrzymuje nikt.
- Jakość danych otrzymywanych od dostawców usług IT jest równie zróżnicowana. Jedna instytucja opisuje je jako dostarczane terminowo, druga jako niekompletne lub w niestandardowym formacie, a trzecia jako w ogóle pozbawione systematycznego raportowania. Łańcuch dostaw nie generuje danych w jakości wymaganej przez przepisy DORA dotyczące ryzyka dostawców ICT (art. 28–30).
Jeśli jesteś po drugiej stronie tej relacji – dostawcą ICT dla instytucji finansowej – powyższe wyjaśnia, dlaczego klient nagle pyta o Twój numer LEI, klasyfikację usługi czy dane kontraktowe w konkretnym formacie. Nie robi tego z nadmiernej ostrożności. Robi to, bo bez tych danych jego własny rejestr RoI zostanie odrzucony, tak jak niemal 94% zgłoszeń w pilotażu.
Wniosek: żaden z trzech respondentów nie ma pełnego zestawu wymaganych identyfikatorów, większość ocenia spójność danych jako niską, a dwóch z trzech zgłasza konkretne problemy z danymi od dostawców. Trzy różne pytania, jeden wspólny wynik: zero.
To problem całego ekosystemu, a nie pojedynczej instytucji. Jedna firma nie rozwiąże go samodzielnie – może go najwyżej wymusić na swoich dostawcach poprzez zapisy w umowach. Najlepsza na rynku platforma zarządzania ryzykiem dostawców nic nie da, jeśli numer identyfikacyjny dostawcy (LEI), zaciągany wprost z systemu zakupowego, nigdy nie został w momencie wprowadzania sprawdzony względem globalnej bazy GLEIF – wzorcowego, ogólnoświatowego rejestru tych numerów. Te 93,5% wadliwych zgłoszeń z pilotażu nie pochodziło ze słabych technicznie instytucji. To były instytucje, które potraktowały DORA jako projekt regulacyjny, podczas gdy w 70% jest to projekt zarządzania danymi.
DORA nie została źle wdrożona. Została wdrożona w niewłaściwej warstwie. Programy z lat 2023–2025 skupiały się na warstwie wykonawczej – platformach zarządzania ryzykiem dostawców, konfiguracji systemów wykrywania incydentów, politykach i procesach – podczas gdy warstwa danych referencyjnych, z której wynika 70% rzeczywistych wymagań, była traktowana jako skutek, a nie jako fundament. A skutku nie da się osiągnąć bez fundamentu. Stąd 93,5%.
Dla zarządu, który chce zamknąć tę lukę przed końcem 2026 roku, to nie jest pięć pytań do przemyślenia w ciszy gabinetu. To pięć pytań, które trzeba zadać dyrektorowi ds. informatyki (CIO) i zespołom odpowiedzialnym za technologię – zanim zada je regulator.
Pięć pytań kontrolnych, które zarząd instytucji finansowej powinien zadać przed końcem 2026 roku
Te pięć pytań brzmi identycznie niezależnie od tego, kto je usłyszy, ale niosą inny ciężar w zależności od pozycji w organizacji. Dla zarządu to pytanie o ekspozycję osobistą i nadzór. Dla CIO i CDO – o codzienną operacyjną rzeczywistość, z którą żyją na bieżąco. Warto rozłożyć to na osobne kolumny.
# | Pytanie | Co to znaczy dla zarządu | Co to znaczy dla CIO/CDO |
|---|---|---|---|
1 | Czy w 4 godziny od zaklasyfikowania incydentu jako poważny wygenerujemy poprawny raport bez ręcznego dopytywania? | Czy zarząd zostanie zaskoczony w realnym kryzysie, czy organizacja faktycznie spełni wymóg, za który on osobiście odpowiada przed regulatorem. | Czy proces od zgłoszenia do raportu działa automatycznie end-to-end, czy wymaga ręcznego zestawiania danych z inwentarza, rejestru RoI i systemu zgłoszeń. |
2 | Czy klasyfikacja CIF jest zarządzana centralnie, czy odziedziczona z dokumentu sprzed dwóch lat? | Czy zatwierdza klasyfikację opartą na bieżącej rzeczywistości, czy na nieaktualnym dokumencie, co jest bezpośrednią ekspozycją w ramach jego obowiązku nadzoru z art. 5, którego przedmiotem jest m.in. klasyfikacja wymagana art. 8. | Czy istnieje właściciel procesu przeglądu CIF i coroczny cykl, czy to jest coś odziedziczone bez żadnego przeglądu. |
3 | Kto z imienia i nazwiska odpowiada za jakość pól LEI, EUID i CARN w rejestrze RoI? | Czy obowiązek data governance z art. 5 jest realnie spełniony, czy istnieje tylko na papierze, bez przypisanej osoby. | Czy to pytanie trafia z powrotem do niego bez żadnego wsparcia organizacyjnego czy mandatu – czyli czy ryzyko jest skoncentrowane na jednej osobie bez zasobów. |
4 | Czy TPRM, CMDB i system incydentów pobierają dane o dostawcach z jednego źródła? | Na co dzień niewidoczne dla zarządu, ale staje się jego problemem w chwili kryzysu, kiedy trzy raporty dostarczają rozbieżne informacje. | To jego codzienna operacyjna rzeczywistość – trzy silosy danych bez jednego źródła prawdy, czyli dokładnie ten problem integracyjny, z którym funkcjonuje na bieżąco. |
5 | Kiedy niezależny podmiot ostatnio zaudytował jakość danych RoI, a wynik trafił do zarządu? | Czy ma jakąkolwiek niezależną weryfikację poza wewnętrznym raportem „status: zielony” – bezpośrednio związane z jego osobistą odpowiedzialnością administracyjną. | Czy kiedykolwiek zainicjował lub poprosił o niezależny audyt, czy poprzestał na samoocenie wewnętrznej, która – jak pokazała ankieta – bywa zawodna. |
Pięć pytań. Każde, na które organizacja nie potrafi odpowiedzieć w trzech zdaniach – niezależnie od tego, kto odpowiada, zarząd czy CIO – oznacza obszar nieprzepracowanego ryzyka regulacyjnego.
Nieprzepracowane ryzyko regulacyjne nie ma wagi w dyskusji budżetowej bez konkretnej liczby.
Ile kosztuje brak zgodności z DORA
Trzy scenariusze pokazują, jaka to liczba.
Scenariusz pesymistyczny (10–20% prawdopodobieństwa w cyklu 24 miesięcy): odrzucenie transmisji RoI, grzywna administracyjna nałożona przez krajowy organ nadzoru, niezakwalifikowanie raportu incydentu, audyt nadzorczy z rekomendacjami. Koszty bezpośrednie: 200 tysięcy do 2 milionów euro, plus koszty zarządzania reputacją.
Scenariusz bazowy (60–70% prawdopodobieństwa): kolejne cykle roczne transmisji RoI z rosnącymi wymaganiami jakościowymi, narastające koszty utrzymania procesu ręcznego, pogarszający się całkowity koszt posiadania platform TPRM i SIEM bez warstwy integrującej. Koszt w horyzoncie 12–24 miesięcy: 300 do 800 tysięcy euro więcej w roboczogodzinach.
Scenariusz inwestycyjny: wdrożenie warstwy danych referencyjnych – walidacja LEI wobec bazy GLEIF, zarządzanie identyfikatorem CARN, integracja klasyfikacji CIF – w horyzoncie 6 do 12 miesięcy. Capex 300 do 700 tysięcy euro, opex 100 do 200 tysięcy euro rocznie. Break-even względem scenariusza bazowego w 12 do 18 miesięcy, pełne zabezpieczenie przed scenariuszem pesymistycznym.
Te liczby są szacunkami rzędu wielkości, oparte na publicznie dostępnych danych o kosztach wdrożeń tej klasy – każda instytucja musi je skalibrować do własnego profilu. Ale relacja między nimi jest stabilna: koszt inwestycyjny w warstwę danych nie przekracza w żadnym realistycznym przypadku potencjalnego kosztu jednego epizodu regulacyjnego.
Horyzont 6 do 12 miesięcy ze scenariusza inwestycyjnego nie jest abstrakcyjnym założeniem rynkowym – to konkretny zakres pierwszego etapu współpracy, do którego przechodzimy w ostatnim rozdziale.
Jak Sanmargar pomaga zamknąć lukę w danych referencyjnych
Jeśli jesteś CIO albo CDO i czytasz to z jedną myślą w głowie: „znowu ktoś sprzedaje kolejny projekt integracji danych, a ostatni taki utknął bez końca, bez jasnego właściciela, bez mierzalnego efektu” – to jest dokładnie ta obiekcja, którą chcemy zaadresować otwarcie.
Nie proponujemy wieloletniej transformacji danych w całej organizacji. Pierwszy etap współpracy to audyt jakości danych referencyjnych w Twoim rejestrze RoI – ograniczony zakres, jeden konkretny dostawca wyniku, z jasno przypisanym właścicielem procesu od pierwszego dnia. Efekt, który widać od razu, niezależnie od tego, czy regulator kiedykolwiek zapyta: koniec ręcznego uzgadniania tego samego kodu LEI w trzech różnych systemach przy każdym cyklu raportowym.
Sześć obserwacji z ankiety składa się w jeden spójny obraz potrzeby rynku – i w jedną lukę, której żadna z dotychczasowych kategorii narzędzi nie zamyka w całości.
Klasyczne RDM, czyli zarządzanie danymi referencyjnymi? Żaden z respondentów nie planuje wdrażać go od zera – i trudno się dziwić: zbyt szeroki zakres, zbyt rozmyta odpowiedzialność, zbyt długa droga do pierwszego efektu. Klasyczne TPRM obejmuje rejestr dostawców, ale już nie aktywa ICT, nie klasyfikację funkcji krytycznych jako proces cykliczny, nie warstwę identyfikatorów regulacyjnych. Klasyczne CMDB to z kolei techniczna ewidencja zasobów – bez wymiaru regulacyjnego. Każde z tych narzędzi rozwiązuje jeden fragment układanki i zostawia resztę nietkniętą.
Właśnie w tej przestrzeni między kategoriami leży nisza, którą nazywamy DORA Data Hub: warstwa danych referencyjnych spinająca zarządzanie ryzykiem dostawców, ewidencję zasobów IT, nadzór zgodności i raportowanie incydentów w jedną architekturę – z gotowym modelem rejestru RoI, zarządzaniem identyfikatorami (LEI, EUID, CARN) i walidacją jakości jeszcze przed wysłaniem danych do nadzorcy.
Metastudio DRM nie zastępuje inwestycji w TPRM czy SIEM – te albo już zostały poczynione, albo właśnie zapadają. Wchodzi dokładnie tam, gdzie dziś trzy systemy przechowują trzy kopie tych samych danych o jednym dostawcy. Bo operacyjna odporność nie bierze się z liczby kupionych narzędzi – bierze się z jednej, wspólnej wersji prawdy o danych, które te narzędzia współdzielą.
Słownik pojęć
A. Akty prawne, organy i standardy regulacyjne
DORA (Digital Operational Resilience Act) — Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego. Obowiązuje od 17 stycznia 2025 r. Pięć filarów: zarządzanie ryzykiem ICT, zgłaszanie incydentów, testowanie odporności, ryzyko dostawców ICT, wymiana informacji.
RTS (Regulatory Technical Standards) — regulacyjne standardy techniczne; akty wykonawcze 2. poziomu doprecyzowujące wymogi rozporządzenia.
ITS (Implementing Technical Standards) — wykonawcze standardy techniczne; jednolite formaty, szablony i procedury raportowania.
RTS 2024/1772 — kryteria klasyfikacji incydentów ICT i istotnych cyberzagrożeń oraz progi istotności (7 kryteriów, m.in. liczba klientów, czas trwania, zasięg geograficzny, straty danych, wpływ ekonomiczny > 100 000 EUR).
RTS 2024/1773 — szczegółowa treść polityki w zakresie umów na usługi ICT wspierające funkcje krytyczne lub istotne.
RTS 2024/1774 — narzędzia, metody i polityki zarządzania ryzykiem ICT oraz uproszczona rama dla mniejszych podmiotów.
RTS 2025/301 (+ ITS 2025/302) — treść i terminy raportowania poważnych incydentów ICT (Initial 4 h, Interim 72 h, Final 1 miesiąc).
ITS 2024/2956 — standardowe szablony Rejestru Informacji (RoI) wg art. 28 ust. 9 DORA. Opublikowane 2 grudnia 2024 r.
RTS 2025/1190 — elementy TLPT — kryteria objęcia testami, wybór testerów, zakres i metodyka. Obowiązuje od 8 lipca 2025 r.
ESAs (European Supervisory Authorities) — trzy europejskie organy nadzoru: EBA (bankowość), ESMA (rynki kapitałowe), EIOPA (ubezpieczenia i programy emerytalne).
NCA (National Competent Authority) — właściwy organ krajowy; w Polsce KNF. Do NCA podmioty składają RoI; NCA przeprowadza pierwszą walidację i przekazuje dane do ESAs.
B. Identyfikatory i standardy danych
RoI (Register of Information) / Rejestr Informacji — ustandaryzowany rejestr wszystkich umów z zewnętrznymi dostawcami usług ICT, raportowany do nadzoru (art. 28 DORA).
LEI (Legal Entity Identifier) — globalny, 20-znakowy identyfikator podmiotu prawnego (ISO 17442). Wymaga corocznego odnawiania.
GLEIF (Global Legal Entity Identifier Foundation) — globalna fundacja non-profit (Bazylea) nadzorująca system LEI i wzorcową, publiczną bazę numerów LEI.
CARN (Contractual Arrangement Reference Number) — numer referencyjny umowy nadawany przez podmiot finansowy; musi być unikalny i spójny w całym rejestrze.
CIF (Critical or Important Function) — funkcja krytyczna lub istotna; klasyfikacja przesądza o zakresie wielu obowiązków. Definicja: art. 3 DORA.
EUID (European Unique Identifier) — europejski niepowtarzalny identyfikator przedsiębiorstwa z systemu połączonych rejestrów handlowych (BRIS).
ISO 3166 — międzynarodowa norma kodów krajów (np. PL, DE).
ISO 4217 — międzynarodowa norma kodów walut (np. PLN, EUR).
C. Systemy i narzędzia IT
SIEM (Security Information and Event Management) — system zbierający i analizujący logi oraz zdarzenia z infrastruktury IT w celu wykrywania incydentów. „Centralny radar bezpieczeństwa”.
SOAR (Security Orchestration, Automation and Response) — narzędzie automatyzujące reakcję na incydenty wg gotowych scenariuszy (izolacja systemu, blokada konta, zgłoszenie).
ITSM (IT Service Management) — system zarządzania usługami IT; obsługa zgłoszeń, incydentów i zmian (np. ServiceNow, Jira Service Management).
CMDB (Configuration Management Database) — baza konfiguracji; wewnętrzna ewidencja zasobów IT i powiązań między nimi.
RDM (Reference Data Management) — zarządzanie danymi referencyjnymi; zapewnia spójność kluczowych danych w całej organizacji.
TPRM (Third-Party Risk Management) — narzędzie/proces oceny i zarządzania ryzykiem dostawców zewnętrznych.
GRC (Governance, Risk and Compliance) — system nadzoru nad ładem korporacyjnym, ryzykiem i zgodnością.
ERP (Enterprise Resource Planning) — zintegrowany system zarządzania zasobami przedsiębiorstwa.
eProcurement — elektroniczny system zakupowy.
- Pojęcia regulacyjne, techniczne i biznesowe
Initial Notification — pierwsze zgłoszenie incydentu do nadzoru; dla incydentu poważnego — w bardzo krótkim terminie od jego zakwalifikowania.
TLPT (Threat-Led Penetration Testing) — zaawansowane testy penetracyjne wg scenariuszy realnych zagrożeń, na żywych systemach; cykl ok. 3-letni (rama TIBER-EU).
Zasada proporcjonalności — reguła z art. 4 DORA pozwalająca dostosować głębokość wdrożenia do wielkości i profilu podmiotu, bez zwalniania z filarów.
BCP / DRP (Business Continuity Plan / Disaster Recovery Plan) — plan ciągłości działania oraz plan odtworzenia po awarii.
Data governance — zarządzanie danymi: zasady, role i odpowiedzialność za jakość, spójność i aktualność danych (m.in. art. 5 DORA).
Materiality threshold (próg istotności) — wartość graniczna, po przekroczeniu której incydent uznaje się za poważny i podlegający zgłoszeniu.
CIO / CDO — dyrektor ds. informatyki / dyrektor ds. danych.
Capex / Opex — nakłady inwestycyjne (kapitałowe) / koszty operacyjne (bieżące).
TCO (Total Cost of Ownership) — całkowity koszt posiadania rozwiązania w całym cyklu życia.
Break-even — próg rentowności; moment, w którym skumulowane korzyści zrównują się z nakładem.
Bibliografia i źródła przytoczonych danych
I. Akty prawne (Dziennik Urzędowy UE / EUR-Lex)
- Rozporządzenie (UE) 2022/2554 (DORA) — Parlament Europejski i Rada, 14.12.2022. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Rozporządzenie delegowane (UE) 2024/1772 — kryteria klasyfikacji incydentów ICT i cyberzagrożeń. https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng
- Rozporządzenie delegowane (UE) 2024/1773 — polityka ws. umów na usługi ICT (funkcje krytyczne/istotne). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1773
- Rozporządzenie delegowane (UE) 2024/1774 — rama zarządzania ryzykiem ICT (w tym uproszczona). https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng
- Rozporządzenie wykonawcze (UE) 2024/2956 — szablony Rejestru Informacji (art. 28 ust. 9 DORA). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956
II. Pilotaż Rejestru Informacji (dry run: IV–VIII 2024; wyniki: 17.12.2024)
Dane: 1 039 podmiotów uczestniczących; 947 rejestrów w analizie; 93,5% rejestrów z co najmniej jednym błędem; tylko 6,5% przeszło wszystkie 116 kontroli jakości; połowa pozostałych miała mniej niż 5 błędów.
- EBA / ESAs — komunikat prasowy o wynikach pilotażu (17.12.2024). https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational
- ESAs — „Key findings from the 2024 ESAs’ Dry Run exercise” (raport ESA 2024/35, PDF). https://www.esma.europa.eu/sites/default/files/2024-12/ESA_2024_35_DORA_Dry_Run_exercise_summary_report.pdf
- ESMA — komunikat „ESAs’ Dry Run exercise…”. https://www.esma.europa.eu/press-news/esma-news/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital
- Delano — „93.5% of DORA dry run submissions had at least 1 data error”. https://delano.lu/article/93-5-of-dora-dry-run-submissions-had-at-least-1-data-error-esas-report
- European Pensions — „Just 6.5% of DORA dry run registers passed all data quality checks”. https://www.europeanpensions.net/ep/Just-6-5pc-of-DORA-dry-run-registers-passed-all-data-quality-checks-ESAs.php
III. Pierwszy obowiązkowy cykl raportowania RoI (termin: 30.04.2025)
Dane: 35–50% umów z co najmniej jednym brakującym lub niepoprawnym polem obowiązkowym; część zgłoszeń odrzucona na etapie walidacji technicznej, przed analizą jakości.
- De Nederlandsche Bank — „Reporting DORA registers of information in April 2025”. https://www.dnb.nl/en/sector-news/supervision-2025/dora-reporting-dora-registers-of-information-in-april-2025/
- PSP Lab — „ICT Third-Party Registers Under DORA and PS26/2” (analiza pierwszego cyklu 2025). https://psplab.com/ict-third-party-registers-under-dora-and-ps26-2/
IV. System LEI / GLEIF
- GLEIF — oficjalna baza i informacje o systemie LEI. https://www.gleif.org/
Zapraszamy do rozmowy!
