DORA Artykuł 26 TLPT: dane testowe dla polskich banków przed cyklem 2028

Oś czasu DORA: od in-force do pierwszego cyklu TLPT

Rozporządzenie w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) przestało być teoretycznym wymogiem prawnym, a stało się operacyjną rzeczywistością dla polskiego sektora bankowego. Akt ten wszedł w życie 17 stycznia 2025 r., wyznaczając nową erę w zarządzaniu ryzykiem ICT. Chociaż większość przepisów obowiązuje od tego dnia, ramy czasowe dla najbardziej rygorystycznego wymogu — zaawansowanych testów penetracyjnych kierowanych zagrożeniami (TLPT) opisanego w Artykule 26 — mają własną, krytyczną dynamikę.

Polskie banki zidentyfikowane przez Komisję Nadzoru Finansowego (KNF) jako podmioty znaczące muszą przygotować się na pełną gotowość proceduralną i technologiczną do przeprowadzenia pierwszego pełnego cyklu TLPT najpóźniej do stycznia 2028 r. Ten termin wydaje się odległy, jednak złożoność przygotowań, w szczególności w zakresie zabezpieczenia środowisk testowych, wymaga podjęcia działań natychmiast. TLPT w myśl DORA to nie są standardowe testy penetracyjne aplikacji webowej. To skoordynowany atak Red Teaming na systemy produkcyjne, mający na celu weryfikację zdolności detekcji i reakcji Blue Teamu banku na realne, zaawansowane zagrożenia (TTP).

Kluczowym dokumentem normującym techniczne standardy wykonania TLPT są regulacyjne standardy techniczne (RTS) opracowane przez Europejskie Urzędy Nadzoru (ESA). Ostateczny projekt RTS, opublikowany w 2024 roku, jasno wskazuje, że testy muszą być przeprowadzane na systemach produkcyjnych live, wspierających krytyczne funkcje biznesowe. To generuje fundamentalny konflikt z unijnymi ramami ochrony danych osobowych.

Konflikt regulacyjny: DORA Artykuł 26 vs RODO Artykuł 32

Wymóg testowania na systemach produkcyjnych live w ramach TLPT stwarza bezpośrednie ryzyko naruszenia Ogólnego Rozporządzenia o Ochronie Danych (RODO). Artykuł 32 RODO nakłada na administratorów danych (banki) obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych w celu zapewnienia stopnia bezpieczeństwa odpowiadającego ryzyku. Wprowadzenie zewnętrznych testerów (Red Team) do środowiska produkcyjnego, gdzie mają oni potencjalny dostęp do pełnych danych osobowych klientów, transakcji i sald, jest drastycznym zwiększeniem tego ryzyka.

Banki nie mogą argumentować, że DORA zwalnia je z przestrzegania RODO. Oba akty prawne obowiązują równolegle. Naruszenie bezpieczeństwa danych podczas testu TLPT naraża bank na kary administracyjne z RODO do 20 milionów euro lub 4% całkowitego rocznego światowego obrotu, niezależnie od oceny odporności cyfrowej dokonanej przez KNF. Ponadto, audytorzy TLPT będą weryfikować nie tylko skuteczność ataku, ale także to, czy bank zachował kontrolę nad poufnością danych w trakcie testu.

Tradycyjne metody, takie jak maskowanie danych (anonymization) lub szyfrowanie, często zawodzą w kontekście złożonych systemów bankowych, ponieważ albo niszczą użyteczność danych do testów (np. łamiąc logikę biznesową zawartą w formatach numerów kont lub PESEL), albo są odwracalne przy odpowiednim wysiłku obliczeniowym lub dostępie do kluczy, co w scenariuszu zaawansowanego ataku jest realnym zagrożeniem.

Dlaczego naiwne makiety danych niszczą kauzalne rurociągi bankowe

W obliczu ryzyka związanego z RODO, wiele banków rozważa użycie prostych danych testowych, generowanych metodami statystycznymi lub ręcznie tworzonych makiet (mockups). Jest to podejście skazane na porażkę w zaawansowanych testach TLPT. TLPT wymaga weryfikacji całego łańcucha operacyjnego: od front-endu, przez szyny danych, silniki decyzyjne, aż po core banking i systemy raportowe.

Naiwne makiety danych niszczą kauzalne rurociągi (causal pipelines) danych. Współczesne systemy bankowe nie przetwarzają izolowanych pól danych. Decyzja kredytowa, detekcja fraudu czy wyliczenie rezerw opierają się na złożonych, wielotabelowych zależnościach kauzalnych. Przykładowo, jeśli syntetyczny klient ma w tabeli 'demografia' wiek 25 lat, ale jego syntetyczna 'historia transakcyjna' wykazuje 30-letnią historię zatrudnienia, silnik antyfraudowy natychmiast wykryje anomalię i zablokuje proces.

W teście TLPT, Red Team wykorzystuje takie niespójności. Jeśli systemy obronne (Blue Team) zostaną zalane fałszywymi alertami wynikającymi z niskiej jakości danych testowych, nie będą w stanie wykryć subtelnych śladów realnego ataku. Aby test TLPT był miarodajny, Blue Team musi pracować na danych, które są operacyjnie nieodróżnialne od produkcyjnych, zachowując wierność wielotabelową (multi-table fidelity) przy jednoczesnym matematycznym zagwarantowaniu braku PII.

Przewaga kauzalnej wierności wielotabelowej CAUSA

Rozwiązaniem tego konfliktu jest wdrożenie Infundum's CAUSA AI Data Engine. CAUSA AI Data Engine nie jest prostym generatorem statystycznym ani modelem opartym na sieciach GAN, które często zawodzą przy próbie zachowania spójności w schematach przekraczających kilka połączonych tabel. CAUSA implementuje podejście oparte na kauzalnej sztucznej inteligencji (Causal AI), modelując fundamentalne zależności strukturalne i logiczne rządzące danymi bankowymi.

Causal AI pozwala CAUSA engine na zrozumienie i reprodukcję głębokich powiązań między tabelami. Jeśli CAUSA generuje syntetycznego klienta, generuje również spójną z jego profilem historię transakcyjną, portfel produktów kredytowych, zachowania w kanałach cyfrowych oraz powiązania z innymi podmiotami, zachowując pełną integralność referencyjną (referential integrity) w całym ekosystemie danych. W teście TLPT oznacza to, że systemy detekcji fraudów (AML) czy silniki scoringowe pracują na danych, które zachowują się kauzalnie poprawnie, nie generując fałszywych alertów, co pozwala Blue Teamowi skupić się na realnym zagrożeniu.

Co krytyczne, CAUSA engine generuje te dane w modelu self-hosted, wewnątrz infrastruktury banku. Dane produkcyjne nigdy nie opuszczają bezpiecznej strefy banku, a CAUSA produkuje jedynie syntetyczne repozytoria testowe, które są matematycznie niemożliwe do re-identyfikacji. To zapewnia pełną zgodność z RODO Artykuł 32, umożliwiając jednocześnie przeprowadzenie rygorystycznych testów DORA Artykuł 26.

Lista kontrolna gotowości: 24 miesiące do cyklu TLPT

Zostało mniej niż 24 miesiące na pełne przygotowanie do pierwszych obowiązkowych testów TLPT. Polskie banki muszą postrzegać zabezpieczenie danych testowych jako ścieżkę krytyczną projektu. Poniższa lista kontrolna definiuje kluczowe kroki:

• Faza 1: Scoping i Inwentaryzacja (Do May 2026)
  • Zidentyfikowanie krytycznych funkcji biznesowych (KFB) i wspierających je systemów ICT, które wejdą w zakres TLPT.
  • Inwentaryzacja schematów danych w tych systemach i mapowanie kauzalnych zależności między nimi.
  • Ocena ryzyka RODO związanego z potencjalnym dostępem Red Teamu do tych danych.
• Faza 2: Wybór Technologii i Procedur (Do Q4 2026)
  • Ewaluacja technologii generowania danych testowych. Odrzucenie metod maskowania na rzecz kauzalnej syntetyzacji dla systemów o wysokiej złożoności wielotabelowej.
  • Przeprowadzenie Proof of Concept (PoC) z CAUSA engine w celu weryfikacji zdolności do reprodukcji złożonych scenariuszy biznesowych (np. generowanie spójnego multi-table snapshotu dla 100+ tabel core banking).
  • Definicja procedur dostępu i czyszczenia środowisk po teście.
• Faza 3: Implementacja i Testy Pilotażowe (Do Q2 2027)
  • Wdrożenie wybranej technologii syntetyzacji w modelu self-hosted.
  • Wygenerowanie pełnoskalowych syntetycznych repozytoriów danych testowych dla systemów w zakresie TLPT.
  • Przeprowadzenie testu pilotażowego TLPT ("dry run") na danych syntetycznych w celu weryfikacji reakcji Blue Teamu.
• Faza 4: Pełny Cykl TLPT (Do January 2028)
  • Formalne przeprowadzenie testu TLPT z zewnętrznymi testerami na systemach produkcyjnych live, używając syntetycznych danych do walidacji procesów.
  • Audyt poufności danych w trakcie i po teście.
  • Zaraportowanie wyników do KNF.

Wewnętrzne podlinkowanie

Dla głębszej analizy zachowania spójności kauzalnej w złożonych modelach ryzyka, zobacz nasz towarzyszący artykuł o KNF Rekomendacja S a syntetyczne dane: testowanie modeli hipotecznych bez naruszenia RODO. Jeśli Twoim priorytetem jest migracja legacy systemów, przeczytaj Migracja Oracle do Snowflake w polskim banku: 5 powodów dla syntetycznych danych testowych.

Cytowania regulatorów

• DORA - Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554
• RODO - Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679
• KNF - Wytyczne dotyczące zaawansowanych testów penetracyjnych kierowanych zagrożeniami (TLPT)

Wniosek

TLPT pod DORA to nie jest ćwiczenie z compliance. To rygorystyczna walidacja odporności operacyjnej. Banki, które wejdą w ten proces z niezabezpieczonymi danymi produkcyjnymi, ryzykują naruszenie RODO o katastrofalnych skutkach finansowych i reputacyjnych. Banki, które wejdą z niskiej jakości makietami, unieważnią wyniki testu, marnując zasoby i pozostawiając luki w bezpieczeństwie. Jedyną audytowalną drogą jest wdrożenie produkcyjnej infrastruktury syntetyzacji danych, takiej jak CAUSA, która gwarantuje kauzalną wierność wielotabelową niezbędną do realistycznych testów Red Teaming, zachowując 100% szczelność danych osobowych.