Rozporządzenie DORA dla fintechów: ryzyko ICT i stron trzecich

Co to jest

DORA jest rozporządzeniem, więc stosuje się bezpośrednio we wszystkich państwach członkowskich, a uzupełniają je standardy techniczne. Opiera się na pięciu filarach. Zarządzanie ryzykiem ICT wymaga udokumentowanych ram obejmujących identyfikację, ochronę, wykrywanie, reagowanie i odtwarzanie, wyciąganie wniosków oraz komunikację, przy czym ostateczną odpowiedzialność ponosi organ zarządzający. Zarządzanie incydentami związanymi z ICT wymaga klasyfikacji incydentów i zgłaszania poważnych incydentów właściwemu organowi w określonych terminach. Testowanie operacyjnej odporności cyfrowej wymaga programu testów proporcjonalnego do podmiotu; niektóre podmioty wyznaczone przez organy muszą ponadto przechodzić testy penetracyjne prowadzone w oparciu o analizę zagrożeń (TLPT) według szczególnych zasad. Zarządzanie ryzykiem związanym z zewnętrznymi dostawcami usług ICT wymaga rejestru informacji o wszystkich ustaleniach umownych dotyczących usług ICT, oceny ryzyka przed zawarciem umowy, określonych postanowień umownych oraz strategii wyjścia. Wymiana informacji o zagrożeniach w zaufanych społecznościach jest zalecana. W całym rozporządzeniu obowiązuje zasada proporcjonalności, a określona lista mniejszych podmiotów, takich jak małe i niepołączone wzajemnie firmy inwestycyjne oraz niektóre zwolnione instytucje płatnicze i instytucje pieniądza elektronicznego, może stosować uproszczone ramy zarządzania ryzykiem ICT z art. 16.

Dla kogo

Ten przewodnik jest skierowany do:

• Licencjonowanych fintechów płatniczych, z obszaru pieniądza elektronicznego, kryptoaktywów, inwestycji i innych, które znajdują się na liście podmiotów finansowych objętych DORA
• Liderów ds. zgodności, ryzyka i technologii, którzy budują lub przeglądają program DORA
• Dostawców ICT i producentów oprogramowania obsługujących podmioty finansowe i otrzymujących wymagania umowne wynikające z DORA
• Założycieli, którzy muszą wyjaśnić oczekiwania DORA inwestorom lub zarządom

Co pomaga wyjaśnić

Przegląd filarów pomaga wyjaśnić:

• Które funkcje krytyczne lub istotne wspiera Państwa firma i od jakich systemów ICT one zależą
• Czy Państwa rejestr dostawców zewnętrznych i umowy zawierają to, czego oczekuje DORA
• Co powinien obejmować program testów odporności, biorąc pod uwagę wielkość i profil ryzyka firmy
• Gdzie brakuje dowodów technicznych na poparcie dokumentów dotyczących nadzoru

Co jest zawarte

• Nadzór: potwierdzić zatwierdzenie ram zarządzania ryzykiem ICT przez organ zarządzający i nadzór nad nimi oraz udokumentować role
• Mapowanie zasobów i funkcji: wskazać funkcje krytyczne lub istotne oraz stojące za nimi systemy, dane i dostawców
• Ochrona i wykrywanie: przejrzeć kontrolę dostępu, MFA, rejestrowanie zdarzeń i monitorowanie tych systemów
• Zarządzanie incydentami: określić kryteria klasyfikacji, osoby decyzyjne i proces zgłaszania poważnych incydentów
• Ciągłość działania: testować kopie zapasowe, odtwarzanie i cele odtworzenia dla funkcji krytycznych
• Program testów: zaplanować oceny podatności, testy scenariuszowe i testy penetracyjne proporcjonalnie do ryzyka
• Rejestr dostawców zewnętrznych: wymienić wszystkie ustalenia dotyczące ICT wraz z funkcją, danymi, lokalizacją i szczegółami podwykonawstwa
• Umowy: sprawdzić wymagane postanowienia, takie jak opisy usług, lokalizacja danych, prawa do audytu i dostępu, wsparcie przy incydentach i warunki wyjścia
• Strategie wyjścia: udokumentować, jak przebiegałoby odejście od krytycznego dostawcy
• Ryzyko koncentracji: odnotować, gdzie kilka funkcji krytycznych zależy od jednego dostawcy

Co nie jest uwzględnione

• Porady prawnej ani wykładni regulacyjnej dotyczącej Państwa konkretnej licencji
• Testów penetracyjnych prowadzonych w oparciu o analizę zagrożeń w ramach wyznaczonych przez regulatora
• Składania zgłoszeń incydentów lub rejestrów do organów
• Certyfikacji ani zatwierdzenia zgodności

Kiedy to wybrać

Z tego przewodnika warto korzystać przy przygotowywaniu lub przeglądzie programu DORA, przed odnowieniem umów z kluczowymi dostawcami ICT oraz przed ustaleniem rocznego planu testów. Jeśli właściwy organ wydał szczegółowe wytyczne lub prośby, należy w pierwszej kolejności się do nich stosować. Dostawcy obsługujący podmioty finansowe powinni korzystać z sekcji dotyczącej stron trzecich, aby przewidzieć prośby dotyczące umów i audytów. Ten artykuł ma charakter informacji ogólnej i nie stanowi porady prawnej.

Nasze podejście

Większość fintechów stwierdza, że dokumentacja istnieje, ale dowodów technicznych jest niewiele. Należy zacząć od przypisania funkcji krytycznych do systemów i dostawców; to jedno ćwiczenie napędza rejestr, zakres testów i planowanie ciągłości działania. Następnie warto zebrać dowody na to, jak kluczowe zabezpieczenia faktycznie działają. Nasza usługa Security Baseline Review może zapewnić pisemny obraz uzgodnionych zasobów z ocenami istotności, który pomaga pokazać stan konfiguracji i kontroli dostępu. W zakresie testów aplikacji i API w ramach programu testów odporności nasza usługa Penetration Testing działa na podstawie pisemnego zakresu i autoryzacji oraz dostarcza znaleziska ocenione według istotności, z ponownym testem uzgodnionych znalezisk, jeśli jest on uwzględniony. Obie uzupełniają testy prowadzone w oparciu o analizę zagrożeń wyznaczone przez regulatora, poradę prawną i zatwierdzenie zgodności, które przebiegają według własnych procesów. Każdy dowód warto opatrywać datą i powiązaniem z funkcją, którą wspiera, aby na pytania w ramach przeglądów kierownictwa i nadzoru można było odpowiadać na podstawie dokumentacji, a nie z pamięci.

Security Baseline Review

Często zadawane pytania

Artykuły pokrewne