Stary system to nie tylko dług techniczny, to dług prawny i ryzyko zarządu

W świetle RODO, NIS-2, DORA i nadchodzących regulacji o cyberodporności stary system bez dokumentacji, bez wsparcia producenta i bez dostępu do kodu przestaje być wyłącznie długiem technicznym. Staje się długiem prawnym, a odpowiedzialność za niego coraz częściej spada bezpośrednio na osoby zarządzające.

Compliance przesuwa się od papieru ku technice

Przez lata zgodność z przepisami sprowadzała się do dokumentów: polityk, procedur, list kontrolnych. Kierunek się zmienia. Europejscy regulatorzy zaczynają patrzeć nie na to, czy organizacja ma odpowiedni dokument, ale czy realnie panuje nad swoją infrastrukturą techniczną.

Samo odhaczenie wymogów RODO czy NIS-2 przestaje być wystarczające. Liczy się twarde bezpieczeństwo techniczne: czy system jest aktualizowany, czy ma logi, czy wiadomo, jak przetwarza dane. Rośnie też liczba organów, które mogą kontrolować. Poza ochroną danych dochodzą regulatorzy z obszaru DORA oraz, po wejściu w życie AI Act, kolejny nadzór nad systemami opartymi o sztuczną inteligencję.

Gdzie dokładnie powstaje dług prawny

Stary system rzadko ma jeden problem. Zwykle ma ich kilka naraz, a każdy z osobna potrafi zaświecić się na czerwono w analizie ryzyka.

Dokumentacja widmo. Bez rzetelnej dokumentacji nie da się przeprowadzić analizy ryzyka. Nie wiadomo, jak dane płyną wewnątrz systemu, więc nie sposób ocenić ryzyk cybernetycznych ani tych związanych z ochroną danych. W razie kontroli organu nadzorczego nieumiejętność wyjaśnienia, jak system działa i jak przetwarza dane, może zostać uznana za niedbalstwo. Do tego stare systemy zwykle nie potrafią dostarczyć logów, których wymagają dziś przepisy.

Wiedza plemienna. Część procesów istnieje wyłącznie w głowach pracowników, często już byłych. Gdy taka osoba odchodzi, organizacja zostaje z procesem, którego nikt nie potrafi opisać. Stąd częsta obserwacja: dopiero przy analizie przedwdrożeniowej zarząd dowiaduje się, jak naprawdę działa jego firma.

Brak dostępu do kodu i vendor lock-in. Wiele systemów legacy opiera się na umowach sprzed dekady, w których nie ma klauzul o przekazaniu praw, dokumentacji ani prawie do modyfikacji. Organizacja staje się zakładnikiem dostawcy, który jako jedyny dysponuje wiedzą techniczną i kodem. Nawet kod złożony kiedyś w escrow bywa wart niewiele, jeśli nikt nie wie, co tam realnie jest i czy był aktualizowany. Realne scenariusze: dostawca znika z rynku, zmienia model biznesowy albo ogłasza migrację wszystkiego do chmury, i zaczynają się schody.

Koniec wsparcia producenta (end-of-life). Utrzymywanie systemu, dla którego producent nie wydaje już łatek bezpieczeństwa, jest z prawnej perspektywy akceptacją wysokiego ryzyka. Ignorowanie raportów o krytycznych lukach może zostać zakwalifikowane jako naruszenie obowiązku należytej staranności.

Brak izolacji. Systemy legacy są zwykle powiązane z innymi. Bez ładu bezpieczeństwa infekcja jednego potrafi rozlać się na pozostałe. Nieaudytowany, niezabezpieczony system to najsłabsze ogniwo, a często przechowuje najwięcej wrażliwych danych.

Paradoks modernizacji: AI dokłada podatności

Modernizacja przez sztuczną inteligencję bywa przedstawiana jako rozwiązanie problemu legacy. Ma też drugą stronę. Systemy oparte o AI mają wyraźnie więcej podatności niż klasyczne, a budując rozwiązania agentowe na starym fundamencie, dokładamy kolejne warstwy ryzyka.

Dochodzi do tego natura agentów. Agent z założenia ma wykonać zlecone zadanie i sięgnąć po dane, których potrzebuje. Jeśli pociągnie je z przetworzonego przez AI kodu legacy, a nie zawsze wiadomo, z czym dokładnie się łączy, sytuacja robi się delikatna. Masowa dostępność AI obniża też barierę wejścia dla atakujących: przestarzałe mechanizmy stają się łatwym celem dla zautomatyzowanych skanerów.

Dlaczego to ryzyko osobiste zarządu

NIS-2 przenosi odpowiedzialność za analizę ryzyka i za zapewnienie odpowiednich środków organizacyjnych i technicznych bezpośrednio na zarząd. Kary finansowe mogą być nakładane wprost na osoby zarządzające, nie tylko na organizację.

Członkowie zarządu mają obowiązek działać z należytą starannością. Sama akceptacja ryzyka, bez realnych działań naprawczych, nie zamyka tematu. Prowadzi raczej do odpowiedzialności odszkodowawczej i osobistej. Warto też pamiętać o efekcie łańcucha dostaw: nawet podmiot nieobjęty bezpośrednio regulacją bywa weryfikowany, jeśli jest dostawcą dla podmiotu, który regulacji podlega. Kontrahent i tak sprawdzi jego bezpieczeństwo.

Osobny obowiązek to ciągłość działania: trzeba umieć wykazać plan przywracania pracy po incydencie. Przy nieudokumentowanym systemie legacy bywa to niemożliwe do udowodnienia. A dokumentacja ma wartość dowodową tylko wtedy, gdy istnieje wcześniej. Wytwarzanie jej na gorąco, już po incydencie, nie pozwoli wykazać staranności.

Co z tym zrobić

Nie chodzi o to, by wymieniać każdy stary system z dnia na dzień. Chodzi o to, by świadomie panować nad ryzykiem i umieć to udokumentować.

• Audyt systemów krytycznych. Sprawdź, które systemy nie mają dokumentacji, wsparcia ani logów. Przejrzyj stare kontrakty: do kogo należą prawa autorskie, czy wolno system modyfikować, jakie są zasady serwisu i wyjścia.
• Plan utrzymania i ciągłości działania. Dla każdego systemu krytycznego określ plan łatania, plan przywracania pracy po incydencie i scenariusz na wypadek zniknięcia dostawcy.
• Izolacja. Oddziel systemy legacy tak, by ewentualna infekcja nie rozlała się na resztę infrastruktury.
• Otwartość i dostęp do kodu oraz danych. Dostęp do kodu, prawo do modyfikacji i pełna dokumentacja zmniejszają zależność od jednego dostawcy i ułatwiają wykazanie kontroli nad systemem. To nie kwestia wygody, lecz mitygacja ryzyka prawnego.
• Odzyskanie wiedzy plemiennej. Spisanie nieudokumentowanych procesów, dziś coraz częściej z pomocą narzędzi AI, jest jednocześnie środkiem dowodowym staranności.

Podsumowanie

Stary system, który po prostu działa, potrafi być najdroższym aktywem w organizacji. Nie dlatego, że jest wolny, ale dlatego, że nikt nad nim nie panuje, a odpowiedzialność za to spada coraz wyżej. Punktem wyjścia nie jest wymiana technologii, tylko uczciwa odpowiedź na pytanie: czy potrafimy wyjaśnić, jak nasze systemy krytyczne działają, i udowodnić, że ryzykiem zarządzamy.

---

Tak właśnie podchodzimy do systemów krytycznych. Zobacz jak prowadzimy transformację cyfrową albo przejrzyj pozostałe materiały w sekcji wiedzy.