Oprogramowanie EOL (End of Life) w bankowości i telekomunikacji: konsekwencje naruszenia DORA i NIS2

System, który nadal obsługuje przelewy, billing albo sygnalizację w sieci, przestaje być „tylko starym serwerem”, gdy producent zamyka poprawki bezpieczeństwa. Dla banku i operatora telekomunikacyjnego oprogramowanie end of life oznacza zwykle lukę, której nie da się już zamknąć oficjalną łatą, oraz pytanie, czy dalsza eksploatacja mieści się w obowiązku odporności cyfrowej. Organ nadzoru rzadko pyta o wiek wersji. Pyta, kto zaakceptował ryzyko, na jakiej podstawie i co się stanie, gdy podatność zostanie wykorzystana.

Status prawny i regulacyjny oprogramowania EOL w świetle DORA oraz NIS2

End of Life (EOL) to moment, w którym producent kończy standardowe wsparcie: poprawki, aktualizacje zabezpieczeń, a często także gwarancję kompatybilności. Sam fakt posiadania licencji nie oznacza, że wolno dalej używać programu w procesie krytycznym tak, jakby wsparcie trwało. W bankowości rozstrzyga przede wszystkim rozporządzenie DORA, w telekomunikacji – krajowe przepisy wdrażające dyrektywę NIS2 oraz obowiązki operatora wobec ciągłości usługi.

EOL a obowiązek zachowania odporności cyfrowej

DORA traktuje zarządzanie ryzykiem ICT jako obowiązek ciągły, a nie projekt „na audyt”. Podmiot finansowy ma identyfikować aktywa, klasyfikować je według krytyczności, monitorować podatności i wdrażać środki ochrony proporcjonalne do ryzyka. Oprogramowanie bez oficjalnych łatek osłabia każdy z tych elementów: skaner pokazuje znaną podatność, a zespół nie ma legalnej, wspieranej poprawki od twórcy.

Co do zasady brak wsparcia nie jest automatycznym zakazem używania programu. Jest natomiast silnym sygnałem, że standardowa należyta staranność nie została dochowana, jeśli system obsługuje funkcje istotne dla ciągłości, integralności danych albo raportowania do organów. W praktyce bywa różnie: system pomocniczy w sieci odciętej od internetu bywa oceniany łagodniej niż komponent stojący na ścieżce płatności albo provisioningu usług.

W telekomunikacji ten sam mechanizm pojawia się przez pryzmat usług kluczowych i podmiotów istotnych. NIS2 wymaga zarządzania ryzykiem, w tym podatnościami, oraz zdolności do zapobiegania incydentom i ograniczania ich skutków. Przestarzały system billingowy, DNS, element sieci szkieletowej albo panel zarządzania, który nie dostaje poprawek, podnosi zarówno prawdopodobieństwo incydentu, jak i trudność wykazania, że operator działał adekwatnie do ryzyka.

Kwestie licencyjne: utrata wsparcia producenta a warunki umowne

Koniec wsparcia rzadko unieważnia licencję z dnia na dzień. Często jednak zmienia to, co licencja jeszcze obejmuje. Umowa wieczysta może pozwalać na używanie starej wersji, a jednocześnie wyłączać pomoc techniczną, poprawki i prawo do modyfikacji. Model subskrypcyjny bywa ostrzejszy: brak odnowienia oznacza utratę prawa do aktualizacji, a czasem także do dalszego korzystania z instancji chmurowej.

Audyt licencyjny w takim momencie nie sprowadza się do policzenia stanowisk. Trzeba sprawdzić, czy samodzielne łatanie, wirtualne łatkowanie przez osobę trzecią albo przeniesienie binariów do nowego środowiska nie narusza zakazu dekompilacji, modyfikacji albo obejścia zabezpieczeń technicznych. Open source nie rozwiązuje problemu automatycznie: licencja może pozwalać na fork, ale nie daje SLA, a zależności w projekcie multi-repo często same są już EOL.

Odpowiedzialność organów zarządczych

Zarówno DORA, jak i ramy NIS2 przesuwają ciężar z „działu IT” na organ zarządzający. Akceptacja pracy systemów pozbawionych oficjalnych łatek jest decyzją o ryzyku, nie szczegółem eksploatacyjnym. Jeśli wyjątek nie ma właściciela, terminu wygaśnięcia, kryteriów kompensacji i ścieżki eskalacji, w razie incydentu trudno wykazać, że zarząd sprawował nadzór, a nie jedynie otrzymał slajd o długu technologicznym w sektorze finansowym.

Typowa pułapka polega na tym, że wyjątek EOL ląduje w rejestrze ryzyk jako pozycja „zaakceptowana na stałe”. Regulacyjnie taki zapis zwykle nie broni podmiotu. Broni go decyzja ograniczona w czasie, oparta na ocenie wpływu na procesy krytyczne i na planie wyjścia, który da się pokazać audytorowi oraz – w razie potrzeby – KNF albo właściwemu CSIRT.

Kryteria dopuszczalności i oceny ryzyka systemów przestarzałych

Dopuszczalność dalszego używania oprogramowania EOL ocenia się po skutku dla odporności, nie po tym, czy „system jeszcze działa”. Poniższe kryteria porządkują rozmowę między bezpieczeństwem, prawem, zakupami i właścicielem procesu.

Poprawki bezpieczeństwa jako miernik należytej staranności

Dostępność oficjalnych poprawek jest bazowym miernikiem. Jeśli producent publikuje łatę, a organizacja jej nie wdraża z powodu okna zmian albo strachu przed regresją, problemem jest proces zarządzania podatnościami. Jeśli łatki już nie ma, problemem jest decyzja o pozostaniu na wersji niewspieranej. W drugim przypadku ciężar dowodu przesuwa się na podmiot: trzeba pokazać, dlaczego ryzyko resztkowe jest akceptowalne i jakie środki je obniżają.

Staranność obejmuje też łańcuch dostaw. Biblioteka EOL wbudowana w aplikację własną, sterownik urządzenia sieciowego albo system operacyjny pod warstwą „wspieranego” oprogramowania dostawcy bywają niewidoczne w inwentarzu. DORA wymaga znajomości zależności ICT, w tym usług stron trzecich. NIS2 podobnie traktuje bezpieczeństwo łańcucha dostaw. Inwentarz, który kończy się na nazwie produktu bez wersji i daty końca wsparcia, nie wytrzymuje takiej oceny.

Wpływ na klasyfikację incydentów i raportowanie

Podatność w systemie EOL zmienia kwalifikację zdarzenia. To, co przy wspieranym oprogramowaniu wygląda na próbę skanowania, przy znanej, niełatanej luce może być uznane za incydent o poważniejszym wpływie – zwłaszcza gdy dotyczy dostępności usługi płatniczej, poufności danych klientów albo ciągłości sieci. Obowiązek raportowania do organu nadzoru, w tym KNF w sektorze finansowym, oraz do właściwego CSIRT, wynika z przepisów o terminach i progach. Sam fakt EOL nie zastępuje tych progów, ale utrudnia argument, że skutek był nieprzewidywalny.

Druga pułapka: zespół zgłasza incydent techniczny, a w opisie pomija, że komponent nie miał wsparcia. Organ później zestawia zgłoszenie z rejestrem aktywów. Rozbieżność wygląda gorzej niż samo EOL. Spójność między CMDB, rejestrem wyjątków i formularzem incydentu jest częścią compliance IT, nie dodatkiem „dla audytu”.

Ryzyka licencyjne i koszty braku zgodności

Samodzielna modyfikacja kodu bez prawa wynikającego z licencji może być naruszeniem autorskim, nawet jeśli celem jest załatanie luki. W praktyce bywa różnie przy open source z jasną licencją zezwalającą na modyfikację – tam problemem staje się raczej brak utrzymania forka i odpowiedzialność za regresje. Przy oprogramowaniu zamkniętym bezpieczniejszą ścieżką jest umowa z uprawnionym podmiotem, a nie „cicha” poprawka wewnętrzna.

Koszty nie kończą się na ewentualnej karze. Dochodzi przestój procesu krytycznego, koszt reakcji, roszczenia kontraktowe klientów hurtowych w telekomunikacji, obowiązek naprawy nakazany przez organ oraz ryzyko odmowy lub ograniczenia ochrony ubezpieczeniowej, jeśli polisa wymaga utrzymywania wspieranego oprogramowania albo zgłaszania istotnych wyjątków. Wysokość sankcji zależy od właściwych przepisów i decyzji organu; nie warto opierać biznes case’u na jednej, szacowanej „karze z prezentacji”. Lepiej liczyć utratę ciągłości, koszt nadzwyczajnego wsparcia i koszt projektu wyjścia.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Subskrypcja, wieczysta, open source – którą licencję wybrać.

Przegląd wariantów postępowania z oprogramowaniem EOL w sektorach regulowanych

W regulowanej bankowości i telekomunikacji rzadko istnieje jedno „słuszne” wyjście. Są cztery powtarzalne warianty. Różnią się tym, kto bierze odpowiedzialność za łatę, jak długo niezgodność zostaje w architekturze i co da się obronić przed regulatorem.

Wariant 1: Płatne wsparcie rozszerzone

Extended support albo custom support agreement to umowa, w której producent albo uprawniony partner nadal dostarcza poprawki bezpieczeństwa, czasem tylko dla wskazanych CVE i na ograniczony czas. Formalnie status „EOL w cenniku publicznym” nie znika, ale organizacja odzyskuje kanał oficjalnych łat i punkt kontaktowy na incydent. To zwykle najbliższe modelowi, którego oczekuje audytor: jest zobowiązanie podmiotu uprawnionego, jest zakres, jest termin.

Założenie wyjściowe: producent w ogóle chce takiej umowy, kod jest nadal utrzymywalny, a licencja pozwala na przedłużenie. W core bankingu i w elementach sieci, gdzie wymiana trwa lata, ten wariant bywa pomostem, nie strategią. Jeśli umowa wyłącza nowe funkcje i obejmuje tylko wybrane podatności, rejestr wyjątków musi to wprost mówić. Inaczej powstaje złudzenie pełnego wsparcia.

Wariant 2: Środki kompensacyjne i izolacja architektoniczna

Wirtualne łatkowanie, WAF, mikrosegmentacja, whitelisting procesów, wyłączenie zbędnych usług i twarde reguły na stykach sieci obniżają ekspozycję, gdy łatki brak. To nie przywraca wsparcia producenta. To obniża prawdopodobieństwo wykorzystania luki i ogranicza ruch boczny po włamaniu.

Warunek formalny: środek musi być opisany jako kontrola kompensacyjna z właścicielem, testem skuteczności i datą przeglądu. „Odcięliśmy VLAN” bez dowodu, że ścieżka ataku faktycznie zniknęła, nie jest argumentem. W systemach OT i w starszych elementach sieci telco izolacja bywa jedynym realnym ruchem w krótkim horyzoncie, ale regulacyjnie pozostaje rozwiązaniem czasowym, dopóki nie ma planu zastąpienia albo umowy wsparcia.

Wariant 3: Pełna modernizacja lub migracja

Re-platforming, wymiana na wspieraną wersję, przejście na SaaS albo inną usługę chmurową usuwa przyczynę: komponent przestaje być EOL. To jedyny wariant, który co do zasady zamyka niezgodność, a nie ją odracza. Kosztem jest projekt: migracja danych, testy regresji, okna zmian, przeszkolenie, a w banku także ocena outsourcingowa i – gdy w grę wchodzi istotna funkcja – obowiązki DORA wobec zewnętrznych dostawców ICT.

Chmura nie jest wytrychem. Przeniesienie niewspieranego middleware do maszyny wirtualnej u dostawcy nie leczy EOL. Leczy je dopiero usługa, której dostawca sam utrzymuje poprawki i daje to w umowie, oraz architektura, w której stary komponent zostaje wyłączony, a nie „schowany”.

Wariant 4: Zamiennik open source z komercyjnym SLA

Zastąpienie zamkniętego produktu projektem otwartym, przy którym komercyjny podmiot daje SLA, poprawki i pomoc 24/7, bywa sensowne dla warstw wspierających: kolejki, monitoring, niektóre bazy, proxy. Dla core bankingu i dla sterowania siecią szkieletową próg jest wyższy: liczy się dojrzałość, referencje w sektorze, prawo do modyfikacji, model łatania CVE i to, czy SLA obejmuje właśnie tę wersję, której używa organizacja.

Pułapka licencyjna jest tu odwrotna niż przy extended support. Kod wolno zwykle modyfikować, ale mieszanie forka wewnętrznego z „wsparciem vendora od community” kończy się sporem, kto odpowiada za regresję. Umowa powinna wskazywać wersję, okno łat i zakaz cichego zejścia na niewspieraną gałąź.

Analiza porównawcza wariantów: koszty, czas, legalność i akceptacja regulatora

Porównanie ma sens tylko jakościowo. Ceny wsparcia rozszerzonego i czas migracji zależą od produktu, skali i tego, czy producent w ogóle negocjuje. Poniższa tabela zestawia kryteria, które zwykle przesądzają o wyborze, bez udawania jednego cennika dla całego sektora.

Czas bywa tu mylący. Wsparcie rozszerzone obniża ryzyko w tygodniach, ale tylko wtedy, gdy producent w ogóle podpisze umowę i dostarczy poprawkę do testów, a nie sam aneks. Środki kompensacyjne wyglądają szybciej na slajdzie: reguła na firewallu albo WAF wchodzi od razu. W praktyce bywa różnie – dopiero test ścieżki ataku pokazuje, czy ruch boczny naprawdę zniknął, czy został tylko opisany jako „odcięty VLAN”.

Koszt też nie siedzi w jednej rubryce. Extended support bywa drogi właśnie dlatego, że kupuje się czas i czyjś obowiązek łatania. Migracja przenosi wydatek do projektu, okien zmian i testów regresji. Kompensacja wygląda tanio na starcie, a potem zjada godziny wyjątków, przeglądów reguł i tłumaczenia audytorowi, czemu kontrola nadal jest tymczasowa. Open source z SLA przesuwa koszt w stronę kompetencji i nadzoru vendora: licencja zwykle pozwala modyfikować kod, ale nie zwalnia z pytania, kto odpowiada za regresję na wersji używanej w produkcji.

Legalność i akceptacja regulatora idą obok siebie, ale nie są tym samym. Dalsze używanie zamkniętego produktu bez modyfikacji kodu bywa dopuszczalne licencyjnie, a jednocześnie słabo broni się pod DORA i NIS2, jeśli nie ma ani łat, ani wiarygodnej kontroli kompensacyjnej, ani daty wyjścia. I odwrotnie: pełna wymiana zamyka niezgodność dopiero w momencie wyłączenia starego komponentu. Schowanie niewspieranego middleware w chmurze tego progu nie przesuwa.

Warto przeczytać również powiązany artykuł: Jak sprawdzić legalność oprogramowania na komputerach pracowników.

W banku z długim cyklem wymiany core ten układ często kończy się mostem: płatne wsparcie albo twarda izolacja na czas migracji, z terminem w rejestrze wyjątków i właścicielem, który odpowiada za przegląd. U operatora telekomunikacyjnego podobnie wygląda starszy element sieci, którego nie da się wymienić w jednym oknie – izolacja bywa jedynym ruchem na teraz, ale bez planu zastąpienia pozostaje odstępstwem, nie strategią. Spójność CMDB, rejestru wyjątków i opisu incydentu nadal decyduje o tym, czy organ zobaczy zarządzane ryzyko, czy rozbieżność gorszą niż samo EOL.

Wybór wariantu jest więc decyzją o tym, kto łata, jak długo odstępstwo zostaje w architekturze i jaki dowód da się pokazać przy kontroli. Tam, gdzie producent daje poprawki i termin, most jest zwykle czystszy. Tam, gdzie go nie ma, zostaje mierzalna kompensacja albo przyspieszona wymiana – nie milczące przedłużanie statusu „tymczasowo”.

Dopasowanie rozwiązania do kontekstu operacyjnego banku i operatora telekomunikacyjnego

Wybór nie zaczyna się od nazwy produktu, tylko od tego, co system robi, jak szybko da się go ruszyć i czy awaria albo wyciek zatrzymuje usługę regulowaną. Ten sam wariant może być rozsądnym mostem przy jednym procesie i nie do obrony przy innym.

Bank: od kanału do core

Przy systemach obsługujących przelewy i core banking liczy się ciągłość rozliczeń oraz możliwość wykazania, kto łata i do kiedy. Jeśli producent nadal negocjuje poprawki, płatne wsparcie rozszerzone jest tu zwykle czystszym mostem niż sama izolacja: skraca okno bez łat, a migracja i tak trwa kwartały albo lata. Izolacja ma sens jako warstwa dodatkowa na czas projektu, nie jako zamiennik umowy. Wymiana albo re-platforming zostaje celem, bo tylko wyłączenie starego komponentu zamyka wyjątek.

Inaczej wyglądają systemy wspierające, które nie trzymają salda ani zlecenia płatniczego: kolejki, proxy, część narzędzi monitoringu. Tu open source z komercyjnym SLA bywa realną alternatywą, o ile umowa wskazuje wersję, okno łat i odpowiedzialność za regresję, a zespół umie odebrać poprawkę. Przeniesienie niewspieranego middleware do chmury bez wyłączenia starej instancji nie zmienia oceny: EOL zostaje, dochodzi tylko nowy dostawca ICT, którego trzeba objąć nadzorem wymaganym przy istotnych funkcjach.

Gdy funkcja jest istotna, a dostawca zewnętrzny odmawia wsparcia albo nie daje terminu łat, most się kończy. Wtedy priorytetem jest plan zastąpienia z datą odcięcia, a nie kolejne przedłużenie wyjątku „do następnego audytu”.

Operator: sieć, billing i panele

U operatora telekomunikacyjnego krytyczność rozkłada się inaczej. Sygnalizacja, DNS, sieć szkieletowa i panele zarządzania często nie dają się wymienić w jednym oknie, a przestój uderza w usługę hurtową i w dostęp abonentów. W krótkim horyzoncie izolacja i twarde reguły na stykach bywają jedynym ruchem, który da się wdrożyć bez ryzyka większej awarii niż sama luka. Warunek jest ten sam co w banku: kontrola musi mieć test ścieżki, właściciela i datę przeglądu. Bez planu zastąpienia albo umowy wsparcia pozostaje odstępstwem.

Billing i systemy rozliczeń z partnerami hurtowymi bliższe są logice core: utrata danych albo dłuższy przestój generuje roszczenia kontraktowe, więc most w postaci extended support – jeśli producent go daje – jest zwykle łatwiejszy do obrony niż wieloletnia kompensacja. Elementy brzegowe o niskiej ekspozycji, odcięte od płaszczyzny zarządzania i bez dostępu do danych abonenckich, mogą dłużej zostać na kontroli kompensacyjnej, ale tylko przy niskiej zależności od łańcucha dostaw i przy regularnym przeglądzie, czy ekspozycja nie urosła.

Kiedy który wariant ma sens

• Wsparcie rozszerzone: proces krytyczny, producent podpisuje poprawki, wymiana nie zmieści się w akceptowalnym oknie ryzyka. Typowo core, billing, wybrane elementy sieci z długim cyklem wymiany.
• Izolacja i kompensacja: brak umowy z producentem albo okno do pierwszej łatki, przy czym da się zmierzyć, że ścieżka ataku zniknęła. Często starszy element sieci albo system odcięty od kanału klienckiego. Zawsze z terminem końca.
• Migracja lub wymiana: tam, gdzie EOL dotyczy funkcji istotnej, a most tylko odracza ten sam problem. Cel dla core i dla sterowania siecią, nawet jeśli startuje później niż kontrola tymczasowa.
• Open source z SLA: warstwy wspierające o dojrzałym zamienniku i referencjach, nie pierwszy ruch przy rozliczeniach ani przy sterowaniu szkieletem.

W praktyce bank i operator rzadko wybierają jeden wariant na cały krajobraz. Sensowny układ to most na systemach, których nie da się ruszyć od razu, i równoległy projekt wyłączenia tam, gdzie ryzyko i zależność od niewspieranego komponentu są największe. Kryterium rozstrzygające nie jest „co tańsze w tym kwartale”, tylko czy po terminie przeglądu wyjątek maleje, a nie jest tylko przepisany na nową datę.

Rekomendowana ścieżka decyzyjna: jak bezpiecznie wyjść z pułapki EOL

Ścieżka poniżej porządkuje decyzję już po tym, jak warianty zostały zestawione. Nie zastępuje oceny ryzyka. Ma sprawić, że EOL nie zostanie milcząco przedłużone, a most – jeśli jest konieczny – ma właściciela, dowód i datę końca.

1. Inwentaryzacja pod kątem decyzji, nie pod kątem spisu. Dla każdego komponentu EOL ustal, jaki proces obsługuje, czy jest w ścieżce przelewu, billingu, sygnalizacji, DNS, szkieletu albo panelu zarządzania, oraz kto jest właścicielem biznesowym i technicznym. CMDB, rejestr wyjątków i opis zależności muszą mówić to samo. Rozjazd na tym etapie uniemożliwia późniejsze wykazanie zarządzanego ryzyka.
2. Ocena ekspozycji i zależności. Oddziel brak łatki od realnej ścieżki ataku: dostęp z sieci, konta uprzywilejowane, dane, których utrata zatrzymuje usługę, oraz dostawcy, bez których komponent nie działa. Tu zapada wstępna kwalifikacja: funkcja istotna z długim cyklem wymiany, element sieci niewymienialny w jednym oknie, albo warstwa wspierająca z dojrzałym zamiennikiem.
3. Wybór mostu albo od razu wymiany. Jeśli producent daje poprawki w umowie z zakresem i terminem, wsparcie rozszerzone jest domyślnym mostem dla procesów krytycznych. Jeśli nie daje, kompensacja wchodzi tylko tam, gdzie da się ją przetestować. Open source z SLA rozważaj dla warstw wspierających, nie jako skrót przy core i sterowaniu siecią. Migracja jest celem wszędzie tam, gdzie most nie usuwa przyczyny.
4. Kontrole kompensacyjne jako warunek mostu, nie jako strategia. Wirtualne łatkowanie, WAF, mikrosegmentacja, whitelisting i wyłączenie zbędnych usług opisuje się z testem skuteczności i datą przeglądu. Brak dowodu, że ścieżka zniknęła, oznacza brak kontroli, niezależnie od nazwy narzędzia.
5. Plan wyjścia z datą odcięcia. Wyjątek dostaje termin wygaśnięcia, kryteria, po których nie wolno go przedłużyć, oraz projekt migracji albo wymiany: zakres, okna zmian, testy regresji i warunek wyłączenia starej instancji. W banku, gdy w grę wchodzi istotna funkcja i dostawca zewnętrzny, w planie musi być też nadzór nad tym dostawcą. W telekomunikacji plan musi uwzględniać okna na sieci i skutki dla klientów hurtowych, ale nie może kończyć się na „zostaje, bo nie ma okna”.
6. Odbiór i wyłączenie. Most kończy się w momencie, w którym stary komponent przestaje obsługiwać proces: nie wtedy, gdy nowy działa obok. Po odcięciu aktualizuje się CMDB i zamyka wyjątek. Incydent w trakcie mostu opisuje się tym samym identyfikatorem aktywa, którego użyto w rejestrze – inaczej organ widzi dwie wersje rzeczywistości.
7. Przegląd, który może odmówić przedłużenia. Każdy termin w rejestrze jest decyzją, nie formalnością. Przedłużenie wymaga nowego uzasadnienia: co się zmieniło w ekspozycji, czemu migracja nie ruszyła i jaki jest krótszy kolejny termin. Brak postępu w planie wyjścia jest powodem odmowy, nie argumentem za kolejnym aneksem.

Dla banku z długim cyklem core praktyczna sekwencja zwykle wygląda tak: umowa wsparcia albo – gdy jej nie ma – przetestowana izolacja, równolegle projekt wymiany, odcięcie starej instancji, zamknięcie wyjątku. Dla operatora ze starszym elementem sieci: najpierw mierzalna izolacja i ograniczenie płaszczyzny zarządzania, równolegle plan zastąpienia w realnych oknach, bez traktowania izolacji jako stanu docelowego. W obu sektorach warstwy wspierające można zdejmować szybciej, także przez zamiennik z SLA, żeby uwolnić uwagę na komponenty, których awaria zatrzymuje usługę.

Bezpieczne wyjście z pułapki EOL nie polega na wybraniu „najlepszego” wariantu raz na zawsze. Polega na tym, że każdy dzień bez wsparcia producenta jest albo objęty umową i terminem, albo objęty kontrolą, którą da się pokazać, i zawsze ma datę, po której stary komponent ma zniknąć z procesu.

Co warto zapamiętać

• Oprogramowanie EOL nie jest automatycznie zakazane, ale jego używanie w procesach krytycznych wymaga udokumentowanej oceny ryzyka.
• DORA i NIS2 nakładają obowiązki związane z zarządzaniem podatnościami, ciągłością działania oraz bezpieczeństwem łańcucha dostaw.
• Brak oficjalnych poprawek zwiększa ciężar dowodu po stronie banku lub operatora, który musi wykazać zastosowanie skutecznych środków kompensacyjnych.
• Wyjątek EOL powinien mieć właściciela, termin wygaśnięcia, kryteria akceptacji, plan wyjścia i ścieżkę eskalacji do organu zarządzającego.
• Możliwe rozwiązania obejmują rozszerzone wsparcie, izolację architektoniczną i środki kompensacyjne oraz pełną modernizację lub migrację.
• Audyt powinien objąć nie tylko licencję, lecz także prawo do modyfikacji, wirtualnego łatkowania, utrzymania forka i przenoszenia oprogramowania do innego środowiska.