Takie przemyślenia na piątek – jestem ciekawa Waszego zdania.
Zbieg DORA, UKSC wdrażającej NIS2 oraz ustawy o zarządzaniu kryzysowym nie powinien prowadzić ani do budowania trzech odrębnych programów zgodności, ani do traktowania ryzyka ICT jako samodzielnego silosu. Tę triadę warto czytać jako elementy jednej ramy zarządzania odpornością usług kluczowych i infrastruktury krytycznej w Unii Europejskiej. Regulacje te zostały pomyślane jako spójna całość, miały wejść w życie w zbliżonym czasie i w dużej mierze dotyczy tych samych obszarów gospodarki.
Moim zdaniem proces ich wdrożenia powinien łączyć ogólny system zarządzania ryzykiem przedsiębiorstwa, a w jego ramach – zarządzanie ryzykiem operacyjnym. W takim modelu ryzyko ICT stanowi element ryzyka operacyjnego. Wiele zagrożeń pozostaje wspólnych dla cyberbezpieczeństwa i innych wymiarów odporności organizacji. Mogą one materializować się jako awaria systemu, cyberatak, błąd konfiguracji, błąd ludzki, celowe działanie człowieka, utrata danych, zakłócenie po stronie dostawcy albo niedostępność infrastruktury. Każde z tych zdarzeń może zakłócić realizację usługi, procesu, obowiązku prawnego lub zobowiązania wobec klienta.
DORA wyraźnie wskazuje, że ramy zarządzania ryzykiem ICT są częścią ogólnego systemu zarządzania ryzykiem podmiotu finansowego. Dokumentacja, kontrole, testy, nadzór i raportowanie powinny być budowane wokół kluczowych usług, procesów krytycznych, tolerancji na zakłócenia, zależności oraz scenariuszy ryzyka. Obowiązki wynikające z DORA, UKSC i ustawy o zarządzaniu kryzysowym powinny natomiast stanowić kryteria oceny ryzyka – pod kątem zgodności, okresowych przeglądów i audytów.
Logika takiego podejścia jest spójna. Problem pojawia się w praktyce.
Po pierwsze, każdy regulator definiuje ten obszar inaczej. DORA mówi o funkcjach kluczowych lub istotnych, UKSC o usługach kluczowych, a ustawa o zarządzaniu kryzysowym – o infrastrukturze krytycznej. Brzmi podobnie? Z perspektywy macierzy ryzyka często nie. Każdy audyt idzie inną ścieżką i wymaga innego dokumentu.
Po drugie – odpowiedzialność jest rozczłonkowana. DORA i UKSC trafiają do funkcji ICT, a ustawa o zarządzaniu kryzysowym do osoby odpowiedzialnej za bezpieczeństwo fizyczne i ochronę. Scalenie tych obszarów oznacza zmianę struktury, a więc także potencjalny konflikt.
Każdy obszar organizacji, na przykład zarządzanie ciągłością działania, musi uwzględniać wymagania wynikające ze wszystkich trzech aktów. To oczywiście uproszczenie, bo regulacji dotyczących odporności jest więcej. Podobnie jest w cyberbezpieczeństwie, bezpieczeństwie fizycznym i operacyjnym oraz w każdym innym obszarze działalności.
Moim zdaniem CRO powinien być wiodącą osobą w rozmowach o odporności operacyjnej. W jego gestii powinny znaleźć się: mapa usług – jedna dla wszystkich trzech regulacji – apetyt na ryzyko wystąpienia zakłóceń oraz wymagania w stosunku do organizacji, takie jak plan testów odporności (technicznych i organizacyjnych), wskaźniki KRI/KPI, wymagania dotyczące ich monitorowania i raportowania oraz raport dla zarządu i rady nadzorczej dotyczący ekspozycji na ryzyko. To oznacza przepisanie i uporządkowanie kompetencji, a następnie monitorowanie realizacji podjętych decyzji.
Przykładowo, jeśli organizacja ma dziś plan ciągłości działania, plan reagowania na incydenty ICT, DRP oraz plan reagowania kryzysowego, to w praktyce posiada trzy dokumenty adresujące to samo ryzyko (zakłócenie kluczowej usługi), które bez wspólnej klamry w postaci wytycznych CRO, mogą bardzo łatwo utracić spójność.
Moim zdaniem osoba odpowiedzialna za system zarządzania ryzykiem powinna odgrywać rolę architekta odporności i monitorować jej poziom. Pytanie: czy to w ogóle możliwe do wdrożenia? Czy są jakieś argumenty przeciwko takiemu rozwiązaniu? Jak sądzicie?
