DORA nie mówi wprost „wymieńcie stare systemy”. Ale jej wymogi – coroczne testy systemów wspierających funkcje krytyczne, przeglądy kodu źródłowego, testy scenariuszowe, a dla wyznaczonych podmiotów TLPT co najmniej raz na trzy lata, oraz udokumentowane RTO i RPO – są w praktyce nie do spełnienia dla nieudokumentowanych aplikacji w Delphi, VB6 czy starej Javie EE. Problem nie polega na tym, że taki system „nie działa”. Problem w tym, że nie da się wiarygodnie udowodnić, że jest odporny. Poniżej pokazujemy, gdzie dokładnie stary stack oblewa DORA i co z tym zrobić bez rewolucji.
Co DORA właściwie wymaga w obszarze testów
DORA (rozporządzenie UE 2022/2554) obowiązuje w pełni od 17 stycznia 2025 r. Jej czwarty filar, czyli testy odporności cyfrowej (art. 24-27), traktuje testowanie nie jak okazjonalny audyt, lecz jak ciągły program wpisany w zarządzanie ryzykiem ICT. W praktyce oznacza to trzy rzeczy istotne dla starych systemów.
Po pierwsze, wszystkie systemy i aplikacje wspierające funkcje krytyczne lub istotne muszą być testowane co najmniej raz w roku. Katalog metod nie jest zamknięty, ale obejmuje między innymi badanie podatności, przeglądy kodu źródłowego, testy bezpieczeństwa sieci oraz testy scenariuszowe.
Po drugie, wyznaczone podmioty muszą przeprowadzać zaawansowane testy metodą TLPT (threat-led penetration testing) co najmniej raz na trzy lata. Szczegółowe standardy techniczne dla TLPT (rozporządzenie delegowane UE 2025/1190) obowiązują od 8 lipca 2025 r. i są spójne z ramami TIBER-EU. To, które podmioty podlegają TLPT, wskazuje krajowy nadzór na podstawie kryteriów z art. 26 ust. 8 – m.in. znaczenia systemowego, profilu ryzyka ICT i dojrzałości technologicznej.
Po trzecie, skala zjawiska nie jest teoretyczna. W pierwszym rocznym przeglądzie poważnych incydentów ICT pod DORA (opublikowanym przez europejskie organy nadzoru w czerwcu 2026 r., za rok 2025) odnotowano 3 383 poważne incydenty w sektorze finansowym UE, z czego około jedna trzecia miała skutki transgraniczne. Odporność przestała być tematem na slajd i stała się wymogiem do udowodnienia.
Dlaczego stary stack tu przegrywa
Systemy legacy nie oblewają DORA dlatego, że są stare. Oblewają, bo nie da się na nich rzetelnie wykonać tego, czego DORA wymaga. Widać to w czterech miejscach.
Brak testowalności. Monolity w Delphi czy VB6 rzadko mają pokrycie testami automatycznymi i środowiska, w których można bezpiecznie odtworzyć scenariusze awarii. Bez tego coroczne testy scenariuszowe i regresyjne stają się kosztownym, ręcznym przedsięwzięciem albo nie powstają wcale.
Przegląd kodu źródłowego bez ludzi, którzy go rozumieją. DORA wprost wymienia przegląd kodu jako jedną z metod. Przy starej Javie EE czy VB6 problemem bywa nie tylko brak testerów, ale i brak osób, które w ogóle rozumieją tę logikę – a czasem także niekompletne lub rozjechane z produkcją źródła.
Brak dokumentacji, czyli brak BIA, RTO i RPO. DORA wymaga wskazania funkcji krytycznych oraz określenia, jak szybko i z jaką akceptowalną utratą danych system się odtwarza. Jeśli nikt nie wie, które procesy zależą od danego systemu i jak on się zachowuje przy awarii, analiza wpływu na biznes (BIA) opiera się na domysłach.
Zależności jako czarne skrzynki. Stary stack często trzyma kluczową logikę i integracje, których nikt nie zmapował. Bez tej mapy nie da się rozsądnie wyznaczyć zakresu testów ani ocenić „promienia rażenia” pojedynczej awarii – a to jest sedno oceny odporności.
Wspólny mianownik jest jeden: nie chodzi o to, że system jest zły, tylko o to, że jest nieprzejrzysty. A DORA karze nieprzejrzystość.
To nie jest argument za „wielkim replacementem”
Łatwo z tego wyciągnąć wniosek: „skoro stary system nie przejdzie testów, trzeba go wymienić”. To zwykle najdroższa i najbardziej ryzykowna odpowiedź – a przy tym niekonieczna. DORA nie nakazuje wymiany systemów. Wymaga udowodnionej odporności i zapanowania nad ryzykiem ICT. To dwie różne rzeczy.
Rozsądna kolejność jest odwrotna do odruchu. Najpierw widoczność: inwentaryzacja procesów i odtworzenie dokumentacji. Potem testowalność: doprowadzenie systemu do stanu, w którym da się go rzetelnie przetestować i monitorować. Dopiero na końcu, tam gdzie to faktycznie uzasadnione, punktowa modernizacja. Bardzo często okazuje się, że do zgodności z DORA wystarczy odzyskać wiedzę i zbudować program testów wokół istniejącego systemu, bez przepisywania go od zera.
Od czego zacząć?
Przygotowanie starego stacku do DORA to projekt, który zaczyna się od informacji, nie od kodu.
Inwentaryzacja procesów i mapa zależności. Rzetelna inwentaryzacja procesów metodą Event Storming pozwala wskazać funkcje krytyczne, powiązania między systemami i realne punkty ryzyka. To fundament BIA oraz sensownego zakresu testów.
Automatyczna, aktualna dokumentacja architektury. Narzędzie S*.doc odtwarza wielowarstwową, zawsze aktualną dokumentację systemu w Waszej własnej infrastrukturze. To warunek wstępny przeglądu kodu, wyznaczenia zakresu TLPT i wykazania nadzoru nad ICT.
Audyt architektury IT w połączeniu z doradztwem DORA pozwala zmapować luki względem art. 24-27, ustalić RTO i RPO oraz zaprojektować program testów proporcjonalny do profilu ryzyka.
Efektem nie jest „papier do szuflady”, tylko punkt wyjścia, w którym stary system przestaje być czarną skrzynką – i zaczyna dać się testować, monitorować i bronić przed nadzorem.
FAQ
Czy DORA nakazuje wymianę systemów legacy
Które systemy legacy podlegają testom pod DORA?
Czym jest TLPT i kogo dotyczy?
Dlaczego brak dokumentacji systemu legacy to problem pod DORA?
Od czego zacząć przygotowania do DORA przy starym stacku?
Macie w organizacji systemy w Delphi, VB6 lub starej Javie EE i nie wiecie, czy przejdą testy odporności DORA? Porozmawiajmy – zaczniemy od zmapowania luk, bez zakładania z góry, że trzeba wszystko przepisać.
