Twój system legacy właśnie nie przeszedł audytu DORA. Co dalej?

• DORA i NIS2 ujawniają luki architektoniczne, których nie da się wyeliminować wyłącznie za pomocą polityk i procedur
• Oparte na przetwarzaniu wsadowym systemy legacy mają trudności ze spełnieniem wymagań dotyczących wykrywania incydentów i raportowania w czasie rzeczywistym
• Nieudokumentowane zależności utrudniają realizację obowiązków związanych z inwentaryzacją zasobów ICT
• Ryzyko koncentracji związane z systemami mainframe jest obecnie istotnym obszarem zainteresowania organów nadzorczych
• Udokumentowany program modernizacji stanowi najmocniejszy argument z perspektywy zgodności regulacyjnej

DORA (Digital Operational Resilience Act) wymaga zdolności, do których architektury systemów legacy nigdy nie były projektowane.

DORA nie jest już przyszłym wyzwaniem związanym ze zgodnością regulacyjną. Rozporządzenie obowiązuje, jest aktywnie egzekwowane i koncentruje się na odporności operacyjnej, obserwowalności systemów oraz kontroli. Wiele środowisk legacy jest w stanie spełnić wymagania dokumentacyjne, jednak ma trudności z realizacją wymagań architektonicznych.

Przetwarzanie wsadowe, nieudokumentowane zależności oraz platformy oparte na jednym dostawcy tworzą luki, których nie da się zamknąć wyłącznie poprzez usprawnienie procesów.

DORA to nie tylko wyzwanie związane ze zgodnością regulacyjną. To także impuls do modernizacji.

W większości starszych środowisk krytyczne zależności są osadzone w kodzie, a nie w dokumentacji.

DORA wymaga ciągłej, dokładnej i audytowalnej inwentaryzacji zasobów ICT i ich współzależności. W wielu środowiskach mainframe zależności te istnieją tylko w łańcuchach wsadowych, harmonogramach zadań i nieformalnej wiedzy posiadanej przez długoletnich inżynierów.

Zautomatyzowane mapowanie zależności jest coraz częściej jedynym wiarygodnym sposobem na spełnienie tego wymogu , a jednocześnie staje się podstawą każdej realistycznej roadmapy modernizacji.

Architektury legacy wykrywają incydenty zbyt późno - często dopiero po zakończeniu cykli przetwarzania wsadowego.

DORA wymaga wykrywania i raportowania poważnych incydentów ICT w ciągu kilku godzin. Systemy oparte na przetwarzaniu wsadowym ograniczają widoczność zdarzeń do momentu zakończenia zaplanowanych procesów, co utrudnia lub wręcz uniemożliwia terminową reakcję.

Nowoczesnych mechanizmów obserwowalności, monitoringu w czasie rzeczywistym, śledzenia zdarzeń (tracingu) i alertowania nie da się skutecznie wdrożyć w architekturach, które nigdy nie były projektowane z myślą o takich funkcjach. Nie jest to problem związany z nadzorem czy zarządzaniem. To ograniczenie wynikające z samej architektury systemu.

Wyjaśnia to również, dlaczego wiele inicjatyw związanych ze sztuczną inteligencją kończy się niepowodzeniem w środowiskach legacy. Bez dostępu do danych w czasie rzeczywistym i odpowiednich mechanizmów obserwowalności trudno jest skutecznie wdrażać rozwiązania AI, co dodatkowo podkreśla potrzebę modernizacji wspierającej wykorzystanie sztucznej inteligencji (AI Modernization).

To, co przez lata było akceptowanym elementem środowiska IT, dziś staje się jawnym ryzykiem koncentracji.

DORA wymaga od instytucji identyfikowania i zarządzania ryzykiem koncentracji związanym z zewnętrznymi dostawcami usług ICT. Systemy krytyczne, których funkcjonowanie zależy od:

• jednego dostawcy sprzętu,
• określonego stosu middleware,
• kurczącej się puli specjalistów posiadających niezbędne kompetencje,

znajdują się obecnie bezpośrednio w obszarze zainteresowania organów nadzorczych.

Choć DORA nie wymaga natychmiastowej rezygnacji z systemów mainframe, nakłada na instytucje obowiązek wykazania aktywnego zarządzania tym ryzykiem oraz jego stopniowego ograniczania w czasie.

W rezultacie modernizacja przestaje być wyłącznie inicjatywą mającą na celu redukcję kosztów, a staje się koniecznością wynikającą z wymogów regulacyjnych.

Organy nadzorcze nie oczekują perfekcji. Oczekują kontroli i skutecznej realizacji działań.

Najsilniejszą pozycję zapewnia udokumentowany i zatwierdzony przez zarząd program modernizacji, który wprost powiązuje działania naprawcze w obszarze architektury z wymaganiami regulacyjnymi. Instytucje potrafiące wykazać systematyczne postępy są w znacznie lepszej sytuacji niż te, które opierają się wyłącznie na deklaracjach lub planach na przyszłość.

W praktyce oznacza to odejście od pojedynczych działań naprawczych na rzecz kompleksowej modernizacji – od mapowania zależności i przeprojektowania architektury, po wdrożenie obserwowalności w czasie rzeczywistym oraz stworzenie fundamentów danych gotowych do wykorzystania przez AI. Kompetencje te są również niezbędne do skutecznej realizacji inicjatyw AI Modernization, umożliwiając organizacjom skalowanie rozwiązań AI w oparciu o odporne, obserwowalne i zgodne z regulacjami środowiska technologiczne.

Podobne regulacje pojawiają się obecnie na całym świecie. Ramy takie jak brytyjskie przepisy dotyczące Operational Resilience, australijskie CPS 230, wytyczne MAS Technology Risk Management Guidelines obowiązujące w Singapurze oraz dyrektywa NIS2 wzmacniają potrzebę zapewnienia większej odporności operacyjnej, widoczności ryzyka technologicznego oraz skutecznego zarządzania systemami krytycznymi i ich zależnościami. Choć szczegóły poszczególnych regulacji różnią się między sobą, kierunek jest jednoznaczny: organizacje muszą wzmacniać fundamenty architektoniczne wspierające kluczowe procesy biznesowe.