Twój certyfikat ISO 27001 nie uruchamia zegarów DORA

Częstym punktem wyjścia dla programu DORA jest arkusz kalkulacyjny. Jedna kolumna zawiera wymagania Rozporządzenia (UE) 2022/2554, druga – kontrole z załącznika A normy ISO/IEC 27001:2022, które firma już wdrożyła w swoim certyfikowanym systemie ISMS, a trzecia rejestruje nakładanie się tych wymagań. Po zakończeniu mapowania okazuje się, że pokrycie jest duże: zarządzanie ryzykiem ICT, kontrola dostępu, zarządzanie dostawcami, ciągłość działania, obsługa incydentów. Pozostałe wymagania mogą wydawać się jedynie ćwiczeniem polegającym na pisaniu dokumentacji na podstawie istniejącego certyfikatu.

Takie podejście to pułapka. Nie jest ono błędne co do samego pokrycia, które faktycznie istnieje. Błędne jest natomiast założenie, czym są owe pozostałe wymagania. Część obowiązków DORA, których certyfikowana firma zgodna z ISO 27001 jeszcze nie wdrożyła, nie sprowadza się jedynie do dokumentacji do napisania. Są to zadania, które muszą być wykonane według ściśle określonych specyfikacji i w określonym czasie – a certyfikat nie został zaprojektowany, aby je weryfikować.

Certyfikat potwierdza zakres systemu; regulacja nakłada obowiązki

ISO/IEC 27001:2022 certyfikuje, że system zarządzania bezpieczeństwem informacji o określonym zakresie spełnia wymagania normy. Certyfikacja nie jest jednorazowym wydarzeniem: jednostka certyfikująca wydaje certyfikat po audycie, który jest następnie utrzymywany przez trzyletni cykl audytów nadzorczych i ponownej certyfikacji. Dwa aspekty towarzyszące certyfikatowi mają tutaj kluczowe znaczenie. Przedmiotem certyfikacji jest system zarządzania ograniczony zakresem, a pytanie, na które certyfikat odpowiada, dotyczy zgodności: czy ISMS spełnia wymagania normy.

DORA nie działa w ten sposób. Obowiązuje ona bezpośrednio podmioty finansowe od 17 stycznia 2025 r. (Rozporządzenie (UE) 2022/2554), a jej postanowienia nie stanowią systemu zarządzania, do którego należy się dostosować, lecz obowiązki do wykonania – wiele z nich określono czasowo i precyzyjnie. Można posiadać ważny certyfikat ISO 27001, zgodny z zakresem i aktualny, a jednocześnie naruszyć DORA, ponieważ certyfikat odpowiada na pytanie, którego DORA nie zadaje. Trzy obowiązki DORA działają według zegarów lub według specyfikacji, których certyfikat nigdy nie weryfikował; czwarty przenosi odpowiedzialność w miejsce, którego certyfikat nigdy nie sprawdza.

Rejestr

Artykuł 28(3) wymaga, aby podmiot finansowy prowadził rejestr informacji dotyczących umów na korzystanie z usług ICT świadczonych przez zewnętrznych dostawców ICT oraz aby co najmniej raz w roku przekazywał informacje na temat tych umów właściwemu organowi nadzorczemu. Rejestr jest ustrukturyzowanym artefaktem, a nie dowolnym dokumentem: Rozporządzenie Wykonawcze Komisji (UE) 2024/2956, opublikowane w Dzienniku Urzędowym 2 grudnia 2024 r., określa standardowe szablony i pola danych. Według ustaleń Europejskich Organów Nadzoru, właściwe organy zbierają te rejestry od nadzorowanych podmiotów i przekazują je do ESA, przy czym pierwszy taki zbiór odbędzie się w 2025 r.

Certyfikowana firma już zarządza swoimi dostawcami ICT za pomocą kontroli z załącznika A, takich jak A.5.19 do A.5.23, dobranych na podstawie leczenia ryzyka i zapisanych w Deklaracji Stosowalności. To jednak samo w sobie nie generuje rejestru w wymaganym schemacie, wypełnionego zgodnie z polami danych DORA, zsynchronizowanego z rzeczywistymi umowami firmy i możliwego do przekazania organowi nadzorczemu w cyklu zbiórki. Zarządzanie dostawcami i dostarczanie regulatorowi określonego ustrukturyzowanego artefaktu to różne obowiązki, a drugi z nich nie jest udokumentowany przez pierwszy.

Zegar incydentów

Artykuł 19 zobowiązuje podmioty finansowe do zgłaszania poważnych incydentów związanych z ICT właściwemu organowi nadzorczemu, a standard techniczny określa zegary. Rozporządzenie Delegowane Komisji (UE) 2025/301 z 23 października 2024 r. wymaga zgłoszenia wstępnego w ciągu czterech godzin od klasyfikacji incydentu jako poważnego i nie później niż 24 godziny po tym, jak podmiot dowiedział się o incydencie; raportu pośredniego w ciągu 72 godzin od tego wstępnego zgłoszenia; oraz raportu końcowego w ciągu miesiąca od raportu pośredniego (lub najnowszego zaktualizowanego raportu pośredniego). To, czy incydent jest w ogóle „poważny”, decydują kryteria klasyfikacji określone w Rozporządzeniu Delegowanym Komisji (UE) 2024/1772.

Warto dwukrotnie przeczytać punkt odniesienia. Zegar DORA, wynoszący cztery godziny, działa od momentu klasyfikacji incydentu jako poważnego, co sprawia, że dokładna i terminowa klasyfikacja staje się częścią obowiązku, a nie jego wstępem. To inna konstrukcja niż obowiązki zgłaszania incydentów, które zespoły finansowe już znają: wczesne ostrzeganie NIS2 działa w ciągu 24 godzin od stwierdzenia znaczącego incydentu (Dyrektywa (UE) 2022/2555, artykuł 23), a RODO wymaga, aby administrator danych powiadomił o naruszeniu ochrony danych osobowych, które zagraża prawom osób, „bez zbędnej zwłoki” – a w miarę możliwości w ciągu 72 godzin od stwierdzenia naruszenia (Rozporządzenie (UE) 2016/679, artykuł 33). Te zegary nie są wymienne. Za pomocą kontroli z załącznika A A.5.24 do A.5.27 certyfikowana firma planuje, ocenia, reaguje i wyciąga wnioski z incydentów związanych z bezpieczeństwem informacji poprzez wdrożony proces, a audytor uznał ten proces za zgodny. To, że audytor uznał proces za zgodny, nie oznacza, że proces ten wygeneruje prawidłowo sklasyfikowane zgłoszenie regulacyjne w ciągu czterech godzin od klasyfikacji.

Obowiązek testowania

Artykuł 26 zobowiązuje identyfikowane przez właściwe organy podmioty finansowe – na podstawie wielkości, profilu ryzyka i znaczenia systemowego – do przeprowadzania testów penetracyjnych prowadzonych na podstawie zagrożeń co najmniej raz na trzy lata, na żywych systemach produkcyjnych wspierających krytyczne lub ważne funkcje. Trzy lata to dolny pułap, który organ nadzorczy może dostosować, a szczegółowa metodologia i kryteria identyfikacji zostały określone w Rozporządzeniu Delegowanym Komisji (UE) 2025/1190, obowiązującym od 8 lipca 2025 r. Obowiązek ten nie dotyczy każdego podmiotu finansowego, a identyfikacja należy do organu nadzorczego. Jednak dla podmiotu objętego zakresem jest to powtarzalny, udokumentowany obowiązek określonego rodzaju.

ISO/IEC 27001 nakazuje firmie monitorowanie, mierzenie i ocenę efektywności swojego ISMS (klauzula 9.1) oraz przeprowadzanie audytów wewnętrznych (klauzula 9.2), a kontrola A.8.29 załącznika A obejmuje testowanie bezpieczeństwa w fazie rozwoju i akceptacji. Żadne z nich samo w sobie nie dowodzi przeprowadzenia testów red-team prowadzonych na podstawie analizy zagrożeń przeciwko systemom produkcyjnym, powtarzanych zgodnie z rytmem DORA i przeprowadzonych zgodnie z metodologią nadzorczą. Firma może być w pełni certyfikowana i nigdy nie przeprowadzić takiego testu.

Odpowiedzialność, której certyfikat nie obejmuje

Artykuł 5(2) nakłada na organ zarządzający obowiązek określenia, zatwierdzenia, nadzorowania i ponoszenia odpowiedzialności za ramy zarządzania ryzykiem ICT, a punkt (a) czyni go „ostatecznie odpowiedzialnym za zarządzanie ryzykiem ICT podmiotu finansowego”. Artykuł 5(4) dodaje obowiązek osobisty: członkowie organu zarządzającego muszą utrzymywać swoją wiedzę i umiejętności na poziomie wystarczającym do zrozumienia i oceny ryzyka ICT. To jeden z czterech obowiązków, który nie jest zegarem. Jest to ciągły obowiązek dotyczący governance.

Klauzula 5.1 normy ISO/IEC 27001 już wymaga przywództwa i zaangażowania najwyższego kierownictwa, więc jest to obszar najbliższego pokrycia. Luka jest węższa i bardziej specyficzna niż „ISO ignoruje organ zarządzający”. DORA określa ostateczną odpowiedzialność na „organie zarządzającym” – terminie prawnie zdefiniowanym – oraz nakłada osobisty obowiązek kompetencji na jego członków. „Najwyższe kierownictwo” w ISO i „organ zarządzający” w DORA niekoniecznie są tymi samymi osobami, a certyfikat potwierdza zaangażowanie kierownictwa w ISMS, a nie zgodność z artykułem 5(2)(a) lub 5(4). Certyfikat można uzyskać, nigdy nie testując konkretnej odpowiedzialności określonej przez DORA.

Dlaczego mapowanie ukrywa wszystkie cztery obowiązki

Arkusz kalkulacyjny zawodzi w sposób spójny: porównuje tekst kontroli z tekstem kontroli, a dodatkowe obciążenie DORA nie ogranicza się jedynie do tekstu. Kontrola brzmi: „organizacja powinna zarządzać incydentami związanymi z bezpieczeństwem informacji”, a dowody ISO firmy również tak brzmią – komórki się pokrywają. To, czego komórka nie pokazuje, to fakt, że DORA dołączyła punkt odniesienia zegara czterogodzinnego, określony schemat rejestru, obowiązek testowania co najmniej raz na trzy lata oraz prawnie określoną odpowiedzialną instytucję do działań, które ISO określa jako zdolności. Dwa wymagania mogą używać niemal identycznych słów, a jednak być spełnione przez różne działania, ponieważ jedno pyta, czy istnieje zgodny system w określonym zakresie, a drugie, czy określony obowiązek został wykonany.

To zastrzeżenie warto potraktować poważnie – i to ono utrzymuje wiele programów na ścieżce dokumentacyjnej. Załóżmy, że załącznik A, jak twierdzą niektórzy, już obejmuje zarządzanie incydentami, zarządzanie dostawcami i testowanie, więc DORA to ta sama treść w „opakowaniu zgodności”. Odpowiedź brzmi: specyfikacja i termin nie są „opakowaniem” wokół kontroli. Punkt odniesienia, format przekazywania, dostosowywalny rytm testowania i określona prawna odpowiedzialność to nowe obowiązki, których istnienie kontroli nie uchyla, a które mapowanie kontrolne czyni niewidocznymi.

Zasada, którą warto zachować

Podczas mapowania certyfikatu na regulację mapuj obowiązki operacyjne, a nie tekst kontroli. Certyfikat potwierdza, że system zarządzania spełnił normę w określonym zakresie przez cykl audytowy. Regulacja określa, co ten system musi robić, według jakiej specyfikacji i w jakim terminie. Tam, gdzie obie opisują tę samą działalność, sprawdź, czy regulacja nie dołączyła zegara z punktem odniesienia, formatu, rytmu czy określonej odpowiedzialności – ponieważ to właśnie te elementy mapowanie kontrolne czyni niewidocznymi, a które organ nadzorczy prawdopodobnie będzie weryfikował.

To podejście można uogólnić poza DORA, choć szczegóły będą różne w zależności od reżimu. NIS2 wymaga, aby państwa członkowskie nałożyły zarówno obowiązki governance organu zarządzającego (Dyrektywa (UE) 2022/2555, artykuł 20), jak i obowiązek wczesnego ostrzegania w ciągu 24 godzin (artykuł 23) w odniesieniu do działań, które już opisują istniejące kontrole. Cyber Resilience Act (CRA) nakłada na producentów produktów z elementami cyfrowymi obowiązek raportowania o aktywnie wykorzystywanych lukach oraz poważnych incydentach w określonym czasie, przy czym obowiązki raportowania będą obowiązywać od 11 września 2026 r. (Rozporządzenie (UE) 2024/2847, artykuł 14). Modele odpowiedzialności nie są identyczne, ale zasada interpretacji jest taka sama: znajdź czasownik, znajdź zegar lub specyfikację i traktuj każdy obowiązek z terminem lub określonym adresatem jako obowiązek operacyjny, a nie dokument do napisania.

Jeśli Twoim najbliższym zadaniem jest oddzielenie rzeczywistego pokrycia ISO 27001 z DORA od obowiązków czasowych i określonych, których certyfikat nie udowadnia, takie powiązanie z rzeczywistymi artykułami i standardami technicznymi to rodzaj pracy, do którego wsparcia zbudowany został ISMS Copilot. Duże pokrycie w mapowaniu jest realne. Jest ono także dowodem wielokrotnego użytku, który nadal wymaga walidacji specyficznej dla DORA, a nie zgodności, którą można bez zmian przenieść dalej – dlatego to nie ona powinna kształtować planu.

To praktyczna analiza zgodności, a nie porada prawna. Potwierdź zakres i obowiązki Twojego podmiotu na podstawie rozporządzenia i jego standardów technicznych, a tam, gdzie to istotne, skonsultuj się z właściwym organem nadzorczym lub prawnikiem.