7 godzin i 52 minuty

7 godzin i 52 minuty. Tyle trwał oficjalny incydent Google Cloud z 20 października. W bankowości taki czas wymaga dokładnego rozliczenia. Problem z zasilaniem w londyńskiej strefie europe-west2-b spowodował niedostępność usług i zakłócenia w regionie. Incydent zarejestrowano między 08:08 a 16:00 czasu polskiego. Większość obciążeń odzyskiwała sprawność wcześniej Zakłócenia powiązano również z problemami Revolut. Dotyczyły płatności kartą, wypłat z bankomatów i dostępu do aplikacji. Czas incydentu Google nie oznacza jednak identycznej długości przerwy każdej usługi banku Czy niemal osiem godzin to za długo? Dla niedostępności podstawowych płatności byłby to czas trudny do zaakceptowania. Ocena prawna wymaga jednak danych o faktycznym wpływie na bank i jego klientów. Europejskie przepisy dają konkretne punkty odniesienia. W rozporządzeniu 2024/1772, uzupełniającym DORA, ponad 2 godziny niedostępności usług ICT wspierających krytyczne lub istotne funkcje to jeden z progów klasyfikacji incydentu. Samo przekroczenie tego czasu nie przesądza jeszcze o kwalifikacji jako poważny incydent ani o naruszeniu prawa. Trzeba zastosować pozostałe kryteria EBC przewiduje także dwugodzinny cel wznowienia krytycznych systemów IT w planach ciągłości systemowo ważnych systemów płatności. To wymaganie dla określonej infrastruktury rynku, a nie uniwersalny limit awarii aplikacji bankowej. Pokazuje jednak, jak krótki czas odtworzenia przyjmuje się dla infrastruktury o znaczeniu systemowym Dla banku podstawą oceny są cele odtworzenia wynikające z analizy wpływu na działalność. RTO określa docelowy czas przywrócenia funkcji. DRP opisuje sposób odtworzenia systemów, a BCM obejmuje utrzymanie działalności podczas zakłóceń. Testy powinny uwzględniać awarie dostawców i przełączenie na zasoby zapasowe Jeżeli płatności mają godzinne RTO, a wracają po sześciu godzinach, tę różnicę trzeba wyjaśnić. Samo przyjęcie dłuższego RTO również wymaga uzasadnienia wpływem na działalność i klientów. Jest jeszcze szczegół dotyczący pomiaru. Przepisy DORA przewidują, że jeżeli awaria powoduje opóźnienie świadczenia usługi także po wznowieniu operacji, czas niedostępności mierzy się aż do pełnego wykonania opóźnionej usługi. Zielony status infrastruktury może więc pojawić się wcześniej niż koniec skutków incydentu Do oceny tej awarii potrzebne są czasy odtworzenia poszczególnych usług Revoluta oraz wyniki działania procedur awaryjnych. Dopiero ich porównanie z przyjętymi celami pokaże, czy mechanizmy ciągłości spełniły swoje zadanie. #DORA #GoogleCloud #Revolut #BCM #DRP #Bankowość #OdpornośćOperacyjna