3.3 Ocena kontroli w celu ograniczenia istotnego ryzyka ICT

Aby ocenić rezydualne ryzyko ekspozycji ICT, właściwe organy powinny sprawdzić, jak instytucje identyfikują, monitorują, oceniają i ograniczają istotne ryzyko stwierdzone przez właściwe organy w ocenie, o której mowa powyżej.

W tym celu, w odniesieniu do stwierdzonego istotnego ryzyka ICT, właściwe organy powinny dokonać przeglądu mających zastosowanie:

• a. strategii politycznej zarządzania ryzykiem ICT, procesów i pułapów tolerancji ryzyka;
• b. ram zarządzania i nadzorowania organizacyjnego;
• c. zakresu audytu wewnętrznego i ustaleń oraz
• d. kontroli ryzyka ICT, które odnoszą się w szczególności do stwierdzonego istotnego ryzyka ICT.

Oceny powinny uwzględniać wynik analizy ogólnych ram zarządzania ryzykiem i kontroli wewnętrznego,

• o których mowa w tytule 5 wytycznych EUNB dotyczących SREP, a także zarządzania i strategii instytucji,
• o których mowa w tytule 2 niniejszych wytycznych, ponieważ istotne niedociągnięcia w tych obszarach mogą mieć wpływ na zdolność instytucji do zarządzania ekspozycją na ryzyko ICT i ograniczania go. W stosownym przypadku właściwe organy powinny również wykorzystać źródła informacji podane w ust. 37 niniejszych wytycznych.

Właściwe organy powinny przeprowadzić ocenę w następujących etapach, w sposób, który jest proporcjonalny do charakteru, skali i kompleksowości działań instytucji i przez stosowanie przeglądu nadzorczego, który jest odpowiedni dla profilu ryzyka ICT instytucji.

3.3.1 Strategia polityczna zarządzania ryzykiem ICT, procesy i pułapy tolerancji ryzyka

Właściwe organy powinny sprawdzić, czy instytucja opracowała odpowied nie strategie polityczne zarządzania ryzykiem, procesy i pułapy tolerancji w odniesieniu do stwierdzonych istotnych rodzajów ryzyka ICT. Mogą być one częścią ram zarządzania ryzykiem operacyjnym lub zostać ujęte w oddzielnym dokumencie. W ramach tej oceny właściwe organy powinny uwzględnić, czy:

• a. polityka zarządzania ryzykiem została sformalizowana i zatwierdzona przez organ zarządzający i zawiera wystarczające wytyczne dotyczące gotowości do podejmowania ryzyka ICT, głównych celów zarządzania ryzykiem ICT lub stosowanych pułapów tolerancji ryzyka ICT. Odpowiednia strategia polityczna zarządzania ryzykiem ICT powinna zostać również podana do wiadomości odpowiednich zainteresowanych stron;
• b. mająca zastosowanie strategia polityczna obejmuje wszystkie kluczowe e lementy zarządzania ryzykiem w odniesieniu do stwierdzonych istotnych rodzajów ryzyka;
• c. instytucja wdrożyła proces i procedury bazowe dotyczące identyfikacji (np. „samodzielną ocenę kontroli ryzyka, analizę scenariusza ryzyka) i monitorowania odpowiednich rodzajów istotnego ryzyka oraz
• d. instytucja wprowadziła mechanizm sprawozdawczości dotyczący zarządzania ryzykiem ICT, który w sposób terminowy zapewnia informacje kierownictwu wyższego szczebla i organowi zarządzającemu i który umożliwia kierownictwu wyższego szczebla lub organowi zarządzającemu ocenę i monitorowanie, czy plany i działania dotyczące ograniczenia ryzyka ICT instytucji są spójne z zatwierdzoną gotowością do podejmowania ryzyka lub zatwierdzonymi pułapami tolerancji (w stosownym przypadku) oraz monitorowanie zmian istotnych rodzajów ryzyka ICT.

3.3.2 Ramy zarządzania i nadzorowania organizacyjnego

Właściwe organy powinny ocenić, jak mające zastosowanie role i obowiązki z obszaru zarządzania ryzykiem zostały włączone w organizację wewnętrzną w celu zarządzania stwierdzonym istotnym ryzykiem ICT oraz jego nadzorowania. W związku z tym właściwe organy powinny ocenić, czy instytucja:

• a. posiada jasne role i obowiązki w zakresie identyfikacji, oceny, monitorowania, ograniczania, zgłaszania i nadzorowania odpowiedniego istotnego ryzyka ICT;
• b. udowodniła, że role i obowiązki w obszarze ryzyka, zostały jasno określone, przydzielone i włączone we wszystkie odpowiednie części (np. linie biznesowe, IT) i procesy organizacji, w tym role i obowiązki związane z gromadzeniem i agregowaniem informacji na temat ryzyka i zgłaszania ich kierownictwu wyższego szczebla lub organowi zarządzającemu;
• c. wykazała, że działania z zakresu zarządzania ryzykiem bazują na dostatecznych i odpowiednich jakościowo zasobach ludzkich i technicznych. Aby ocenić wiarygodność mających zastosowanie planów ograniczania ryzyka, właściwe organy powinny również ocenić, czy instytucja przydzieliła dostateczne środki budżetowe lub inne niezbędne zasoby w celu ich wdrożenia;
• d. wykazała odpowiednie działania następcze i reakcje organu zarządzającego w odniesieniu do ważnych ustaleń komórki niezależnej kontroli dotyczących ryzyka ICT, z uwzględnieniem ewentualnej delegacji niektórych aspektów komitetu, jeżeli takowe istnieją oraz
• e. wykazała, że oczekiwania dotyczące mających zastosowanie regulacji i strategii politycznych ICT zostały odnotowane i podlegają udokumentowanemu przeglądowi i sprawozdawczości ze strony niezależnej komórki kontroli z naciskiem na powiązane ryzyka. 3.3.3 Zakres audytu wewnętrznego i ustalenia

Właściwe organy powinny rozważyć, czy komórka audytu wewnętrznego jest skuteczna, jeżeli chodzi o audyt mających zastosowanie ram kontroli ryzyka ICT, sprawdzając czy:

• a. ramy kontroli ryzyka ICT zostały poddane audytowi z wymaganą jakością, dogłębnością i częstotliwością oraz są dostosowane do wielkości, działań i profilu ryzyka ICT instytucji;
• b. plan audytu obejmuje audyt krytycznego ryzyka ICT określonego przez instytucję;
• c. ważne ustalenia z audytu ICT, w tym uzgodnione działania, zostały zgłoszone organowi zarządzającemu oraz
• d. ustalenia z audytu, w tym uzgodnione działania, były przedmiotem działań następczyc h i sprawozdań z postępów okresowo przeglądanych przez kierownictwo wyższego szczebla oraz komitet ds. audytu.

3.3.4 Kontrole ryzyka ICT, które odnoszą się w szczególności do stwierdzonego istotnego ryzyka ICT

W przypadku stwierdzonego istotnego ryzyka ICT właściwe organy powinny ocenić, czy instytucja wprowadziła specjalne kontrole w celu zajęcia się takim ryzykiem. Poniższe sekcje zawierają niewyczerpujący wykaz specjalnych kontroli, które należy rozważyć przy ocenie istotnych rodzajów ryzyka stwierdzonych na podstawie pkt 3.2.3, które są sklasyfikowane w następujących kategoriach ryzyka ICT:

• a. ryzyko związane z dostępnością i ciągłością ICT;
• b. ryzyko związane z bezpieczeństwem ICT;
• c. ryzyko związane ze zmianą ICT;
• d. ryzyko związane z integralnością danych ICT;
• e. ryz yko związane z outsourcingiem ICT.
• (a) Kontrole w celu zarządzania istotnym ryzykiem związanym z dostępnością i ciągłością ICT

Oprócz wymogów określonych w wytycznych EUNB dotyczących SREP (ust. 279 - 281) właściwe organy powinny ocenić, czy instytucja wdrożyła odpowiednie ramy identyfikacji, rozumienia, pomiaru i ograniczania ryzyka związanego z dostępnością i ciągłością ryzyka.

Na potrzeby tej oceny właściwe organy powinny przede wszystkim uwzględnić, czy ramy:

• a. określają krytyczne procesy ICT i odpowiednie systemy wsparcia ICT, które powinny być częścią planów odporności biznesowej i ciągłości wraz:
• i. ze szczegółową analizą zależności między krytycznymi procesami biznesowymi i systemami wsparcia;
• ii. z określeniem celów związanych z odzyskiwaniem w celu wspierania systemów ICT (np. typowo określonych przez przedsiębiorstwo lub uregulowania w obszarze maksymalnego czasu wznowienia funkcji i akceptowalnego poziomu utraty danych);
• iii. z odpowiednim planowaniem awaryjnym, aby umożliwić dostępność, ciągłość i odzyskiwanie krytycznych systemów i usług ICT w celu minimalizacji zakłóceń w operacjach instytucji w akceptowalnych granicach;
• b. obejmują strategie i normy odporności biznesowej oraz kontroli ciągłości, a także kontrole operacyjne, które uwzględniają:
• i. działania mające na celu uniknięcie sytuacji, w której pojedynczy scenariusz, incydent lub klęska mogą mieć wpływ zarówno na systemy produkcji, jak i odzyskiwania ICT;
• ii. procedury tworzenia kopii zapasowych i odzyskiwania systemu ICT w odniesieniu do krytycznych programów i danych, które zapewniają przechowywanie kopii zapasowych w bezpiecznej i dostatecznie oddalonej lokalizacji, aby incydent lub klęska nie mogły zniszczyć lub naruszyć tych krytycznych danych;
• iii. rozwiązania z zakresu monitorowania do terminowego wykrywania incydentów dotyczących dostępności lub ciągłości ICT;
• iv. udokumentowany proces zarządzania incydentami i przekazywania spraw na wyższy poziom kompetencji, który obejmuje również wytyczne dotyczące różnych ról i obowiązków związanych z zarządzaniem incydentami i przekazywaniem spraw na wyższy poziom kompetencji, członków komitetu(- ów) kryzysowego( - ych) i łańcuch zamówień w sytuacji awaryjnej;
• v. działania fizyczne mające na celu ochronę krytycznej infrastruktury ICT instytucji (np. centrów danych) od ryzyka związanego ze środowiskiem (np. ryzyka powodzi lub innych klęsk żywiołowych) oraz zapewnienie odpowiedniego środowiska operacyjnego dla systemów ICT (np. klimatyzacji);
• vi. procesy, role i obowiązki, aby zapewnić, że również systemy i usługi ICT z outsourcingu są objęte odpowiednimi planami i rozwiązaniami z zakresu odporności biznesowej i ciągłości;
• vii. rozwiązania z zakresu planowania i monitorowania wyników i możliwości krytycznych systemów i usług ICT z określonymi wymogami w obszarze dostępności w celu wykrywania ważnych ograniczeń związanych z wynikami i możliwościami w odpowiednim czasie;
• viii. rozwiązania w celu ochrony krytycznych działań lub usług internetowych (np. usług bankowości elektronicznej), w razie potrzeby i w stosownym przypadku, przed zablokowaniem usługi lub innymi cyberatakami z internetu, których celem jest uniemożliwienie lub utrudnienie dostępu do tych działań i usług;
• c. rozwiązania z zakresu testowania dostępności i ciągłości ICT w kontekście szeregu realistycznych scenariuszy obejmujących cyberataki, testy awarii i testy kopii zapasowych w odniesieniu do krytycznych programów i danych, które:
• i. są zaplanowane, sformalizowane i udokumentowane, a wyniki testów wykorzystywane do poprawy skuteczności rozwiązań z zakresu dostępności i ciągłości ICT;
• ii. obejmują zainteresowane strony i funkcje w organizacjach, takie jak zarządzanie linią biznesową włącznie z ciągłością działalności, zespoły reagowania na incydenty i kryzysu, a także odpowiednie zainteresowane podmioty zewnętrzne w ekosystemie;
• iii. organ zarządzający i kierownictwo wyższego szczebla są odpowiednio zaangażowani (np. jako członkowie zespołów zarządzania kryzysowego) i otrzymują informacje o wynikach testów.
• (b) Kontrole na potrzeby zarządzania istotnym ryzykiem związanym z bezpieczeństwem ICT

Właściwe organy powinny ocenić, czy instytucja stworzyła skuteczne ramy identyfikowania, zrozumienia, pomiaru i ograniczania ryzyka związanego z bezpieczeństwem ICT. W ocenie tej właściwe organy powinny przede wszystkim uwzględnić, czy ramy obejmują:

• a. jasn o określone role i obowiązki w odniesieniu do:
• i. osoby(osób) lub komitetów, które są odpowiedzialne za codzienne zarządzanie bezpieczeństwem ICT i za opracowywanie dalekosiężnych strategii bezpieczeństwa ICT oraz są z tego rozliczane, ze uwzględnieniem ich koniecznej niezależności;
• ii. projektu, wdrażania, monitorowania kontroli bezpieczeństwa ICT oraz zarządzania nimi;
• iii. ochrony krytycznych systemów i usług ICT przez przyjęcie przykładu procesu oceny podatności, zarządzania pakietem naprawczym programów, ochrony punktu końcowego (np. złośliwe oprogramowanie), narzędzi wykrywania wtargnięć i zapobiegania im;
• iv. monitorowania, klasyfikacji i obsługi zewnętrznych bądź wewnętrznych incydentów związanych z bezpieczeństwem ICT, włącznie z reagowaniem na incydenty oraz wzn owieniem i odzyskiwaniem systemów i usług ICT;
• v. regularne i proaktywne oceny zagrożeń w celu utrzymania odpowiednich kontroli bezpieczeństwa;
• b. strategię bezpieczeństwa ICT, która uwzględnia i, w stosownym przypadku, uruchamia międzynarodowo uznane normy bezpieczeństwa ICT oraz zasady bezpieczeństwa (np. zasadę najmniejszego uprzywilejowania, tj. ograniczenie dostępu do minimalnego poziomu, który umożliwia normalne funkcjonowanie na potrzeby zarządzania prawem dostępu, oraz zasadę ochrony w głąb, tj. warstwowych mechanizmów bezpieczeństwa, które zwiększają bezpieczeństwo całego systemu na potrzeby zaprojektowania architektury bezpieczeństwa);
• c. proces identyfikacji systemów, usług i dostosowanych wymogów z obszaru bezpieczeństwa odzwierciedlających potencjalne ryzyko oszustw lub ewentualnych możliwych przypadków niewłaściwego stosowania lub nadużyć danych poufnych wraz z udokumentowanymi oczekiwaniami w zakresie bezpieczeństwa, które należy przyjąć w odniesieniu do tych zidentyfikowanych systemów, usług i danych ICT, dostosowanymi do tolerancji ryzyka instytucji i monitorowanymi w celu prawidłowego wdrożenia;
• d. udokumentowany proces zarządzania incydentami w zakresie i przekazywania spraw na wyższy poziom kompetencji, który obejmuje wytyczne dotyczące różnych ról i obowiązków związanych z zarządzaniem incydentami i przekazywaniem spraw na wyższy poziom kompetencji, członków komitetu(- ów) kryzysowego( - ych) i łańcuch zamówień w sytuacjach awaryjnych dotyczących bezpieczeństwa;
• e. rejestrowania użytkowników i działalności administracyjnej w celu umożliwienia skutecznego monitorowania oraz terminowego wykrywania nieupoważnionej działalności i reagowania na nią, wspomagania lub przeprowadzania dochodzeń karnych w związku z incydentami dotyczącymi bezpieczeństwa. Instytucja powinna wprowadzić strategie rejestrowania określające odpowiednie typy logów, które należy utrzymać oraz ich okres zatrzymania;
• f. kampanie uświadamiające i informacyjne lub inicjatywy służące informowaniu wszystkich szczebli w instytucji o bezpiecznym korzystaniu i ochronie systemów ICT instytucji oraz głównych rodzajów ryzyka związanych z bezpieczeństwem ICT, które powinni znać, zwłaszcza jeżeli chodzi o istniejące i zmieniające się zagrożenia cybernetyczne (np. wirusy komputerowe, możliwe nadużycia wewnętrzne lub zewnętrzne, ataki, cyberataki) oraz ich rola w ograniczaniu przypadków łamania zasad bezpieczeństwa;
• g. odpowiednie fizyczne środki bezpieczeństwa (np. telewizja przemysłowa, alarmy przeciwwłamaniowe, drzwi ochronne) w celu zapobiegania przypadkom nieupoważnionego dostępu do krytycznych i wrażliwych systemów ICT;
• h. działania mające na celu ochronę systemów ICT przed atakami z internetu (tj. cyberatakami) lub innymi zewnętrznymi sieciami (np. tradycyjne połączenia telekomunikacyjne lub połączenia z zaufany mi partnerami). Właściwe organy powinny sprawdzić, czy ramy instytucji uwzględniają:
• i. proces i rozwiązania mające na celu utrzymanie kompletnego i aktualnego inwentarza i przeglądu wszystkich zewnętrznych punktów połączenia z siecią (np. witryn internetowych, aplikacji internetowych, WIFI, dostępu zdalnego), za pomocą których strony trzecie mogłyby włamać się do wewnętrznych systemów ICT.
• ii. ściśle zarządzane i monitorowane środki bezpieczeństwa (np. zapory sieciowe, serwery proxy, przekaźniki poczty, antywirusy i skanery treści) w celu zabezpieczenia przepływu przychodzącego i wychodzącego w sieci (np. e - maili) oraz połączeń sieciowych zewnętrznych, za pomocą których osoby trzecie mogą włamać się do wewnętrznych systemów ICT;
• iii. procesy i rozwiązania mające na celu zabezpieczenie witryn i aplikacji, które mogą być przedmiotem bezpośrednich ataków z internetu/z zewnątrz u służyć jako punkty wejścia do systemów wewnętrznych ICT. W ujęciu ogólnym obejmuje to połączenie uznanych praktyk bezpiecznego rozwoju, praktyk usprawnienia systemu ICT i monitorowania podatności, a także wdrożenie dodatkowych rozwiązań w dziedzinie bezpieczeństwa, takich jak na przykład stosowanie zapór systemowych lub systemów wykrywania włamania lub zapobiegania włamaniu (IPS);
• iv. okresowe testy zabezpieczenia przed przenikaniem w celu oceny skuteczności wdrożonych środków i procesów z zakresu cybernetycznego i wewnętrznego bezpieczeństwa ICT. Testy te powinni przeprowadzać pracownicy i eksperci zewnętrzni z niezbędnym doświadczeniem, wraz z udokumentowanymi wynikami testów oraz wnioskami przekazanymi kierownictwu wyższego szczebla lub organowi zarządzającemu . W razie potrzeby i w stosownym przypadku instytucja powinna wywnioskować z wspomnianych testów, gdzie należy poprawić kontrole i procesy bezpieczeństwa oraz uzyskać lepszą gwarancję ich skuteczności.
• (c) Kontrole na potrzeby zarządzania istotnym ryzykiem związanym ze zmianą ICT

Właściwe organy powinny ocenić, czy instytucja wdrożyła skuteczne ramy identyfikowania, rozumienia, pomiaru i ograniczania ryzyka związanego ze zmianą ICT dostosowane do charakteru, skali i złożoności działań instytucji oraz profilu ryzyka ICT instytucji. Ramy instytucji powinny obejmować ryzyko powiązane z opracowaniem, testowaniem i zatwierdzaniem zmian systemów ICT, w tym opracowaniem lub zmianą oprogramowania, przed jego przeniesieniem do środowiska produkcji, oraz zagwarantować adekwatne zarządzanie cyklem życia ICT. W ocenie tej właściwe organy powinny przede wszystkim uwzględnić, czy ramy obejmują:

• a. udokumentowane procesy zarządzania zmianami systemów ICT (np. zarządzanie konfiguracją i pakietem naprawczym) i danych (np. usuwanie wirusów lub korygowanie danych) oraz ich kontroli przez zapewnienie odpowiedniego zaangażowania osób odpowiedzialnych za zarządzanie ryzykiem ICT w istotne zmiany ICT, które mogą mieć znaczny wpływ na profil ryzyka lub ekspozycję instytucji;
• b. specyfikacje dotyczące wymaganego podziału obowiązku podczas różnych etapów wdrażania procesów zmiany ICT (np. projektowanie i opracowywanie rozwiązania, testowanie i zatwierdzanie nowego oprogramowania oraz zmian, migracja i wdrażanie w środowisku produkcyjnym oraz us uwanie wirusów) z naciskiem na wdrożone rozwiązania i podział obowiązków w celu zarządzania zmianami produkcji systemów i danych ICT oraz ich kontroli przez pracowników ICT (np. programistów, administratorów systemów ICT, administratorów bazy danych) lub każdej innej strony (np. użytkowników biznesowych, usługodawców);
• c. środowiska testowe, które odpowiednio odzwierciedlają środowiska produkcji;
• d. inwentarz aktywów istniejących aplikacji i systemów ICT w środowisku produkcyjnym, a także środowisko testów i rozwoju, tak aby wymagane zmiany (np. aktualizacje lub modernizacje, zestawy naprawcze systemów, zmiany konfiguracyjne) mogły być przedmiotem odpowiedniego zarządzania, wdrażanego i monitorowanego w odniesieniu do właściwych systemów ICT;
• e. proces monitorowania cyklu życia używanych systemów ICT oraz zarządzania nimi, aby zagwarantować, że nadaj spełniają i wspierają aktualne wymogi w obszarze przedsiębiorstw i zarządzania ryzykiem oraz dopilnować, że używane rozwiązania i systemy ICT wciąż są wspierane przez kl ientów oraz że wciąż towarzyszą im odpowiednie procedury cyklu życia opracowanych programów;
• f. system kontroli i odpowiednie procedury w celu zapobiegania nieupoważnionym zmianom w kodzie źródłowym oprogramowania, które zostało opracowane wewnętrznie;
• g. proces przeprowadzania weryfikacji bezpieczeństwa i podatności nowych lub znacznie zmodyfikowanych systemów i programów ICT przed dopuszczeniem ich do produkcji i narażeniem na ewentualne cyberataki;
• h. proces i rozwiązania w celu zapobiegania nieupoważnionemu i ni ezamierzonemu ujawnieniu danych poufnych, przy przemieszczaniu, archiwizowaniu, wyrzucaniu ub niszczeniu systemów ICT;
• i. niezależne procesy przeglądu i zatwierdzania w celu ograniczenia ryzyka błędów ludzkich podczas wprowadzania zmian do systemów ICT, z których wiele ma niekorzystny wpływ na dostępność, ciągłość lub bezpieczeństwo instytucji (np. istotne zmiany w konfiguracji zapory) lub bezpieczeństwo instytucji (np. zmiany zapory).
• (d) Kontrole na potrzeby zarządzania istotnym ryzykiem związanym integralnością danych ICT

Właściwe organy powinny ocenić, czy instytucja wdrożyła skuteczne ramy identyfikowania, rozumienia, pomiaru i ograniczania ryzyka związanego z integralnością danych ICT dostosowane do charakteru, skali i złożoności działań instytucji oraz profilu ryzyka ICT instytucji. Ramy instytucji powinny obejmować ryzyko związane z ochroną integralności danych przechowywanych i przetworzonych przez systemy ICT. W ocenie tej właściwe organy powinny przede wszystkim uwzględnić, czy ramy obejmują:

• a. strategię, która określa role i obowiązki związane z zarządzaniem integralnością danych w systemach ICT (np. architekta danych, inspektorów ds. danych⁶ , osób odpowiedzialnych za ochronę danych⁷ , właścicieli/rządców danych⁸ ) i pozwala określić, które dane są krytyczne z perspektywy integralności danych i powinny podlegać specjalnym kontrolom ICT (np. automatycznym kontrolom zatwierdzania danych wejściowych, kontrolom przekazywania danych, uzgodnieniom itp.) lub przeglądom (np. kontroli kompatybilności z architekturą danych) na różnych etapach cyklu życia danych ICT);
• b. udokumentowaną architekturę danych, model danych lub słownik danych, które zostały zatwierdzone z udziałem odpowiednich zainteresowanych stron z obszaru działalności biznesowej i IT w celu wspierania niezbędnej spójności danych w systemach ICT oraz zyskania pewności, że architektura danych, model danych lub słownik danych pozostają dostosowane do potrzeb przedsiębiorstwa i zarządzania ryzykiem;
• c. strategię dotyczącą dopuszczalnego zastosowania i bazowania na systemach obliczeniowych użytkowników końcowych, zwłaszcza jeżeli chodzi o identyfikację, rejestrację i dokumentację ważnych rozwiązań obliczeniowych dla użytkowników końcowych (tj. podczas przetwarzania ważnych danych) oraz oczekiwanych poziomów bezpieczeństwa w celu zapobiegania nieupoważnionym modyfikacjom, zarówno samego narzędzia, jak i danych w nim przechowywanych;
• d. udokumentowane procesy postępowania z wyjątkami w celu rozwiązania stwierdzonych problemów z integralnością danych ICT zgodnie z ich krytycznością i wrażliwością.

W przypadku instytucji nadzorowanych, które podlegają zasadom efektywnej agregacji danych o ryzyku i sprawozdawczości w zakresie ryzyka Bazylejskiego Komitetu Nadzoru Bankowego 239⁹ , właściwe organy powinny dokonać przeglądu analizy ryzyka instytucji pod kątem sprawozdawczości w zakresie ryzyka i

6 Inspektor ds. danych jest odpowiedzialny za przetwarzanie i wykorzystywanie danych. 7 Osoba odpowiedzialna za ochronę danych odpowiada za bezpieczny nadzór nad danymi, ich transport i przechowywanie. 8 Rządca danych jest odpowiedzialny za zarządzanie i dopasowanie elementów danych – zarówno treści, jak i metadanych.

9 Bazylejski Komitet Nadzoru Bankowego, Zasady efektywnej agregacji danych o ryzyku i sprawozdawczości w zakresie ryzyka (Principles for effective risk data aggregation and risk reporting), styczeń 2013 r., zasady dostępne online: http://www.bis.org/publ/bcbs239.pdf. zdolności do agregacji danych w świetle zasad i przygotowanych dokumentów, z uwzględnieniem wdrażania chronologicznych i przejściowych ustaleń dotyczących tych zasad.

• (e) Kontrole na potrzeby zarządzania istotnym ryzykiem związanym z outsourcingiem ICT

Właściwe organy powinny ocenić, czy strategia outsourcingu instytucji, zgodnie z wymogami zawartymi w wytycznych dotyczących outsourcingu Komitetu Europejskich Obszarów Nadzoru Bankowego (2006) oraz w następstwie wymogu określonego w ust. 85 lit. d) wytycznych EUNB dotyczących SREP, odnosi się odpowiednio do outsourcingu ICT, w tym do outsourcingu wewnątrzgrupowego zapewniającego usługi ICT w ramach grupy. Przy ocenie ryzyka związanego z outsourcingiem ICT właściwe organy powinny uwzględnić, czy ryzyko związane z outsourcingiem ICT może być również objęte oceną nieodłącznego ryzyka operacyjnego na podstawie ust. 240 lit. j) wytycznych EUNB dotyczących SREP w celu uniknięcia powielania pracy l ub obliczeń.

Właściwe organy powinny w szczególności ocenić, czy instytucja posiada skuteczne ramy identyfikacji, zrozumienia i pomiaru ryzyka związanego z outsourcingiem ICT, a w szczególności czy zapewnia kontrole i środowisko kontroli w celu ograniczania ryzyka związanego z istotnymi usługami ICT objętymi outsourcingiem, które są dostosowane do wielkości, działań i profilu ryzyka ICT instytucji i obejmują:

• a. ocenę wpływu outsourcingu ICT na zarządzanie ryzykiem instytucji w powiązaniu z korzystaniem z u sługodawców (np. dostawców usług w chmurze) oraz ich usług w procesie przetargu, udokumentowaną i uwzględnianą przez kierownictwo wyższego szczebla lub organ zarządczy podczas podejmowania decyzji o outsourcingu usług. Instytucja powinna dokonać przeglądu strategii zarządzania ryzykiem ICT oraz kontroli i środowiska kontroli dostawców, aby dopilnować, że są zgodne z wewnętrznymi celami instytucji w zakresie zarządzania ryzykiem oraz gotowości do podejmowania ryzyka. Przegląd powinien być okresowo aktualiz owany w czasie trwania umowy o outsourcing, z uwzględnieniem cech usług podlegających outsourcingowi;
• b. monitorowanie ryzyka ICT usług objętych outsourcingiem w czasie trwania umowy o outsourcingu w ramach zarządzania ryzykiem instytucji, które jest uwzględniane w sprawozdaniach dotyczących zarządzania ryzykiem ICT w instytucji (np. sprawozdawczość dotycząca ciągłości biznesowej, sprawozdawczość dotycząca bezpieczeństwa);
• c. monitorowanie i porównanie świadczonego poziomu usług z umownie uzgodnionym poziomem u sług, który powinien stanowić część umowy o outsourcing usług lub umowy o gwarantowanym poziomie usług (SLA) oraz
• d. adekwatny personel oraz adekwatne zasoby i kompetencje do monitorowania ryzyka ICT i zarządzania tym ryzykiem ze strony usług objętych outsour cingiem.