Zmiana systemu do sprawozdawczości obligatoryjnej aSISt na jego webowego odpowiednika eON, do tego oferowanego jako usługa SaaS z chmury publicznej, to niewątpliwie decyzja strategiczna. Gdy zostanie podjęta, przychodzi czas na działania operacyjne, czyli migrację danych, które przez lata gromadzone były w desktopowej wersji aplikacji.

Proces musi odbyć się w zgodności z obowiązującymi przepisami prawa, ale nie mniej ważna jest łatwość jego przeprowadzenia. Specjalistom FINGO zależało, aby był on maksymalnie uproszczony i bezpieczny. Dlatego ostatecznie proces migracji (w FINGO częściej nazywanym onboardingiem) z systemu aSISt do eON składa się z 4 kroków:

• Analiza ryzyka.
• Przejście przez proces sprawdzania aplikacji: jej funkcji i zabezpieczeń na środowisku testowym.
• Zgłoszenie chęci korzystania z systemu opartego na chmurze do instytucji nadzorującej.
• Właściwa migracja danych.

W tym artykule:

• przeczytasz opis wyżej wymienionych etapów;
• znajdziesz praktyczne wskazówki ekspertów FINGO, którzy służą pomocą i doświadczeniem podczas procesu migracji;
• znajdziesz listę dokumentów wymaganych przez KNF, które należy opracować przed przejściem do systemu osadzonego na chmurze zewnętrznej;
• dowiesz się jak wygląda proces z perspektywy klienta na przykładzie Banku Spółdzielczego z Kamiennej Góry.

Krok 1. Analiza ryzyka wykonywana przez instytucję finansową

Analiza ryzyka jest kompleksowym procesem oceny, obejmującym analizę prawnych i technicznych aspektów zmiany systemu na chmurową usługę SaaS. To także pierwszy krok w procesie wdrażania klienta do usługi eON SaaS, który odgrywa kluczową rolę, ponieważ wnioski z przeprowadzonego audytu będą stanowić bazę do przygotowania zgłoszenia do Komisji Nadzoru Finansowego (krok 3).

Rozpoczynając analizę ryzyka, instytucja finansowa musi sklasyfikować posiadane dane, ponieważ nie wszystkie będą mieć jednakowe wymagania co do zasad bezpieczeństwa i generować ryzyka na podobnym poziomie. W praktyce podmiot finansowy określa, czy do nowego systemu zostaną wprowadzone dane objęte ochroną prawną, w tym dane osobowe (RODO) oraz dane objęte tajemnicą bankową (Prawo bankowe) lub informacje nieobjęte tak rygorystycznymi zasadami bezpieczeństwa.

Najlepszym przykładem raportu, który ma niższe wymagania prawne jest sprawozdanie transakcji oszukańczych (ang. fraud reporting, fraudulent payments). W tym sprawozdaniu instytucja finansowa dzieli się danymi zagregowanymi, np. w marcu odnotowano 7 transakcji oszukańczych na łączną kwotę 300 tys. euro. Takie dane nie pozwalają na identyfikację użytkownika, stąd też wymagania co do ich ochrony są nieco niższe. W praktyce oznacza to, że postępowanie z takimi danymi reguluje Prawo bankowe.

Na podstawie tej kwalifikacji, instytucja identyfikuje i ocenia ryzyka związane z przechodzeniem na chmurową usługę SaaS. Ocenia zastosowane środki bezpieczeństwa - czy są wystarczające, aby zapewnić ochronę na wymaganym poziomie. A także stwierdza, czy zidentyfikowane ryzyka i ich rozwiązania są dla nich na akceptowalnym poziomie.

Choć w tym procesie instytucja finansowa może korzystać z doradztwa podmiotów zewnętrznych, to należy pamiętać, że ostateczna odpowiedzialność za analizę ryzyka oraz przeprowadzenie i wyniki audytu spoczywa na niej i nie może tej odpowiedzialności zmitygować.

Kinga Brzozowska, Information Compliance Officer w FINGO, radzi na co zwrócić uwagę podczas analizy ryzyka:

Analiza ryzyka oraz audyt ryzyk to procesy, których - zgodnie z przepisami regulacyjnymi - nie może unikać żadna instytucja obowiązana. Szacowanie i ocena ryzyk jest gwarantem bezpieczeństwa, jakie podmiot jest zobligowany zapewnić swoim Klientom. Jak więc należy przeprowadzić poprawną i zgodną z obowiązującym prawem ocenę ryzyk? Przede wszystkim z pełną odpowiedzialnością za poprawność i prawdziwość analizy.

To szalenie istotne, aby w analizach ryzyka pojawiły się przede wszystkim trzy grupy danych:
1. ryzyka, które mają realny wpływ na działanie podmiotu;
2. ryzyka zgodne ze stanem faktycznym (nie zaniżone, zawyżone, pominięte lub celowo dodane);
3. wyraźna ścieżka naprawcza i/lub zdefiniowane postępowanie z ryzykami.

Często spotykam się z pytaniami i wątpliwościami, czy można powierzyć odpowiedzialność za wykonanie analizy ryzyka podmiotowi zewnętrznemu? Absolutnie nie!

Zgodnie z prawem analizę ryzyka podmiot musi wykonać samodzielnie. Dostęp osób niepowołanych do danych o charakterze wewnętrznym może prowadzić do naruszeń, incydentów, a w kontekście analizy ryzyka, do ich znaczącego wzrostu.

Pamiętajmy, że analiza ryzyka związana jest z takimi czynnikami jak:
1. wysoki stopień poufności ujawnianych informacji;
2. ujawnienie wiedzy o wewnętrznych czynnikach wpływających na ryzyka;
3. ujawnienie strategii postępowania z wykrytymi ryzykami;
4. odpowiedzialność prawna podmiotu nadzorowanego.

Biorąc pod uwagę powyższe czynniki oczekujemy, że instytucje z sektora bankowego będą posiadały dział zarządzania ryzykiem lub kontroli ryzyka. W mniejszych podmiotach będą to zespoły składające się ze specjalistów: analityków ryzyka, ekspertów branżowych, specjalistów z obszaru compliance i osób zajmujących się zarządzaniem ryzykiem. Zespoły te są odpowiedzialne za przeprowadzanie analizy ryzyka po stronie instytucji obowiązanej.

Co istotne, powyższych obowiązków i odpowiedzialności za analizę ryzyka nie należy mylić z brakiem współpracy z dostawcami podczas analizy.

Dostawcy mają obowiązek udzielić instytucji wszelkich informacji, otwarcie współpracować oraz udostępnić niezbędną dokumentację w celu zidentyfikowania ryzyk po swojej stronie. Wiarygodny partner zdaje sobie sprawę, że ma obowiązek współpracować z Klientem w celu identyfikacji, oceny i zarządzania ryzykiem. Dlatego w FINGO gwarantujemy Klientom pomoc i współpracę w sposób zgodny z przepisami regulacyjnymi i najlepszymi praktykami branżowymi.

W przypadku audytu ryzyka sytuacja wygląda nieco inaczej.

Audyt ma na celu niezależną, obiektywną i cykliczną ocenę procesu analizy ryzyka, poprawności identyfikacji ryzyk, podejścia do działań naprawczych oraz zgodności z obowiązującym prawem. W zależności od specyfiki instytucji oraz wymagań regulacyjnych audyt ryzyka może być przeprowadzany przez wewnętrzny zespół, zewnętrzną firmę audytorską, specjalistyczny zespół ds. ryzyka lub w sposób mieszany. Reasumując, w przypadku ryzyk bardzo istotne jest świadome i odpowiedzialne podejście wszystkich uczestników procesu.

Krok 2. Przejście przez proces sprawdzania aplikacji: jej funkcji i zabezpieczeń, na środowisku testowym

Drugim krokiem są testy systemu eON na środowisku testowym. FINGO Systems udostępnia instytucji finansowej środowisko testowe wraz ze scenariuszami testowymi i pełną dokumentacją. Podczas tygodnia testów pracownicy klienta powinni przejść całą ścieżkę tworzenia i generowania raportów. Tym samym weryfikują funkcje systemu, ale także pośrednio uczą się pracy na nowej aplikacji. W razie potrzeby, dział obsługi klienta FINGO Systems udziela wsparcia, wyjaśniając wszelkie wątpliwości.

Istnieje również możliwość dostosowania rozwiązania eON do wewnętrznych procedur obowiązujących w firmie klienta.

Bartłomiej Knapik, Release and Platform Manager w FINGO, wyjaśnia znaczenie testów systemu eON na środowisku testowym:

FINGO w ramach umowy z klientem, zgodnie z wymaganiami nadzorcy, udostępnia instytucji finansowej środowisko testowe oraz scenariusze testowe, które klient powinien przejść na wygenerowanych maszynowo danych. Dane używane do testów aplikacji muszą być fikcyjne ze względów formalnych. Komisja Nadzoru Finansowego wyraźnie wymaga, aby testy przeprowadzać właśnie na maszynowo wygenerowanych danych.

Udostępniane przez nas scenariusze testowe dodatkowo zaznajamiają użytkowników z funkcjami systemu, dlatego tak ważne jest ich przejście przez pracowników banku. Co więcej, testy te gwarantują poprawność działania środowiska identycznego z późniejszym środowiskiem produkcyjnym.

Po zakończonym okresie testowania klient notyfikuje KNF o tym, że przechodzi na produkcję, a my czyścimy środowisko testowe, przygotowujemy środowisko produkcyjne i rozpoczynamy techniczną procedurę onboardingu.

Krok 3. Zgłoszenie do instytucji nadzorującej chęci zmiany systemu na wersję chmurową

Większość sprawozdań dostępnych w eON SaaS, wymaga zgłoszenia do instytucji nadzorujących faktu przejścia na rozwiązanie chmurowe. Choć do KNF-u musi zostać złożony tylko formularz zgłoszeniowy, to instytucja finansowa musi sporządzić również inne dokumenty wymagane przez KNF przy onbordingu do chmury, czyli:

1. Formularz klasyfikacji i oceny informacji pod kątem dopuszczalności przetwarzania w chmurze.
2. Formularz szacowania ryzyka uwzględniający zagrożenia opisane w komunikacie chmurowym.
3. Dokument z opisem wymaganych kompetencji w zakresie korzystania z usług chmury obliczeniowej.
4. Udokumentowana weryfikacja spełnienia wymagań dla umowy z dostawcą chmury obliczeniowej.
5. Udokumentowana weryfikacja spełnienia przez dostawcę usług wymagań komunikatu chmurowego KNF.
6. Plan przetwarzania danych w chmurze obliczeniowej.
7. Dokument opisujący sposób zarządzania kluczami szyfrującymi.
8. Dokument opisujący zasady zbierania logów związanych z planem przetwarzania informacji w chmurze.
9. Scenariusze testowe na wdrożenie usług chmurowych.
10. Exit plan.
11. Plan awaryjny (w kontekście ciągłości działania).

Warto zaznaczyć, że wyżej wymienione dokumenty stanowią potwierdzenie, że bank wewnętrznie przeprowadził analizę ryzyka i świadomy wagi zidentyfikowanych zagrożeń wybiera korzystanie z usługi SaaS.

Jeśli po 14 dniach od daty złożenia formularza zgłoszenia organ nadzorczy nie wyrazi sprzeciwu, to jest to zielone światło do przejścia do kroku 4, czyli migracji danych z systemu aSISt do eON SaaS.

Krok 4. Migracja danych z systemu on-premise do chmury

Kiedy audyt ryzyka i wymagana przez KNF dokumentacja zostały wykonane, a nadzorca nie wyraził sprzeciwu, nadchodzi czas na migrację danych do systemu chmurowego eON. W najprostrzym ujęciu bank zgrywa dane z aSISta, przesyła je do FINGO, które umieszcza je na chmurze.

Aby proces migracji przebiegał bezproblemowo i sprawnie po stronie klienta (a dokładnie administratora IT w instytucji finansowej) programiści FINGO stowrzyli migrator danych. Narzędzie współgra z bazami dancyh Oracle i Derby, na których działa desktopowy system do sprawozdawczości obligatoryjnej aSISt. Dane są pobierane, szyfrowane i wysyłane na chmurę.

Od tej pory pracownicy banku mogą tworzyć raporty korzystając z usługi SaaS.

Mariusz Zamolski, Cloud Developer w FINGO, radzi jak co warto zrobić przed migracją danych do systemu eON:

Jakakolwiek migracja danych pomiędzy systemami jest zawsze procesem uciążliwym i kosztownym. Rozumiejąc to, staraliśmy się, aby w przypadku przenoszenia systemu sprawozdawczego na chmurę, maksymalnie skrócić i uprościć tę procedurę. Aby przebieg migracji był bezproblemowy, konieczne jest przestrzeganie dwóch zasad:
- Migrację przeprowadzamy zawsze po zaktualizowaniu się do najnowszej wersji aplikacji aSISt.
- Wszystkie instancje aplikacji aSISt muszą zostać wyłączone przed rozpoczęciem migracji.
W rezultacie, dla średniej wielkości instytucji, już po około godzinie można przesyłać plik z wyeksportowanymi i bezpiecznie zaszyfrowanymi danymi do dalszego przetwarzania po stronie chmury Google Cloud.

Dagmara Szmajdzińska, z zespołu ds. Informatyki w Banku Spółdzielczym w Kamiennej Górze, opowiada o przebiegu migracji z perspektywy klienta:

Cały proces wdrożenia był bardzo dobrze przygotowany zarówno od strony technicznej jak i merytorycznej. Firma FINGO zapewniła cały komplet dokumentacji niezbędnej do spełnienia bardzo restrykcyjnych zapisów komunikatu chmurowego KNF. Do projektu powołane były osoby dedykowane do poszczególnych zadań, posiadające szeroką wiedzę merytoryczną w zakresach, które były im przypisane.

Migracja danych z aSISta do eOn przebiegła bezproblemowo, przegotowane przez firmę FINGO narzędzia do migracji były bardzo proste w obsłudze, całość procesu zajęła mniej niż godzinę. Dodatkowo pracownicy firmy FINGO służyli pomocą na każdym etapie wdrożenia/migracji.

Przejście z systemu aSISt do eON SaaS – podsumowanie

Migracja danych z jednego systemu do drugiego zawsze wiąże się z wyzwaniem i nakładem kosztów. W związku z tym, przy przenoszeniu systemu sprawozdawczego do chmury, celem zespołu FINGO było zminimalizowanie trudności i uproszczenie procesu migracji do absolutnego minimum. Co więcej, zespół projektowy FINGO na każdym kroku wspiera klienta, tak aby ten czuł się zaopiekowany na każdym etapie procesu.

Na koniec warto też zaznaczyć, że migracja danych nie jest obowiązkowa. Zatem instytucja finansowa może u siebie przechowywać dane historyczne, a używanie usługi eON SaaS zacząć bez migrowania danych historycznych.