Rejestr informacji DORA: przewodnik ISO 27001

Jest wtorek, godzina 09:15. Sarah, CISO szybko rozwijającego się fintechu, uczestniczy w ocenie gotowości wraz z menedżerem ds. zgodności, radcą prawnym, osobą odpowiedzialną za zakupy oraz architektem bezpieczeństwa chmury. Zewnętrzny konsultant odgrywa rolę organu nadzorczego DORA.

„Dziękuję za prezentację” — mówi. „Proszę przedstawić Rejestr informacji wymagany przez DORA Article 28, obejmujący ustalenia umowne ICT wspierające krytyczne lub istotne funkcje, widoczność podwykonawstwa, własność aktywów oraz dowody, że rejestr jest utrzymywany w ramach Państwa ram zarządzania ryzykiem ICT”.

Pierwsza odpowiedź brzmi pewnie: „Mamy listę dostawców”.

Potem zaczynają się pytania.

Którzy dostawcy wspierają autoryzację płatności? Które umowy zawierają prawa audytu, wsparcie w obsłudze incydentów, zobowiązania dotyczące lokalizacji danych, prawa wypowiedzenia oraz wsparcie wyjścia? Które platformy SaaS przetwarzają dane osobowe klientów? Które usługi chmurowe wspierają krytyczne lub istotne funkcje? Którzy podwykonawcy stoją za dostawcą usług zarządzanego bezpieczeństwa? Który wewnętrzny właściciel aktywów zatwierdził tę zależność? Które ryzyka w planie postępowania z ryzykiem ISO/IEC 27001:2022 są powiązane z tymi dostawcami? Które pozycje Deklaracji stosowania uzasadniają środki kontrolne?

O 10:30 zespół ma już otwarte cztery arkusze kalkulacyjne, eksport z CMDB, folder SharePoint z umowami PDF, listę podmiotów przetwarzających na potrzeby prywatności, raport rozliczeń chmurowych oraz ręcznie utrzymywane narzędzie do ewidencji SaaS. Żadne z tych źródeł nie jest ze sobą spójne.

Na tym polega praktyczne wyzwanie związane z Rejestrem informacji DORA w 2026 r. Wdrożenie DORA przeszło z etapu „potrzebujemy mapy drogowej” do etapu „proszę pokazać dowody”. Dla podmiotów finansowych, zewnętrznych dostawców usług ICT, CISO, audytorów wewnętrznych i zespołów ds. zgodności rejestr nie jest już szablonem administracyjnym. Jest tkanką łączącą umowy ICT, ryzyko dostawców, łańcuchy podwykonawstwa, usługi chmurowe, aktywa ICT, funkcje krytyczne, odpowiedzialność w ramach ładu oraz dowody ISO/IEC 27001:2022.

Podejście Clarysec jest proste: Rejestru informacji DORA nie należy budować jako odrębnego artefaktu zgodności. Należy budować go jako żywą warstwę dowodową w SZBI, wspieraną przez zarządzanie aktywami, bezpieczeństwo dostawców, nadzór nad korzystaniem z chmury, mapowanie obowiązków prawnych i regulacyjnych, metadane audytowe oraz identyfikowalność postępowania z ryzykiem.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls wskazuje trzy środki kontrolne zakotwiczone w Załączniku A ISO/IEC 27001:2022 jako szczególnie istotne dla tego tematu: A.5.9, inwentarz informacji i innych powiązanych aktywów; A.5.19, bezpieczeństwo informacji w relacjach z dostawcami; oraz A.5.20, uwzględnianie bezpieczeństwa informacji w umowach z dostawcami. Te środki kontrolne nie są dodatkową dokumentacją. Stanowią operacyjny fundament wykazania, że rejestr jest kompletny, ma przypisanych właścicieli, jest aktualny i możliwy do prześledzenia w audycie.

Czego DORA oczekuje od Rejestru informacji

DORA obowiązuje od 17 stycznia 2025 r. i tworzy dla sektora finansowego zbiór wymagań dotyczących odporności ICT, obejmujący zarządzanie ryzykiem ICT, zgłaszanie incydentów, testowanie odporności, ryzyko stron trzecich, ustalenia umowne, nadzór nad kluczowymi zewnętrznymi dostawcami usług ICT oraz egzekwowanie nadzorcze. Dla podmiotów finansowych zidentyfikowanych również w ramach krajowej transpozycji NIS2 DORA działa jako sektorowy akt prawny Unii w zakresie odpowiadających wymagań zarządzania ryzykiem cyberbezpieczeństwa i zgłaszania incydentów.

Obowiązek prowadzenia rejestru jest elementem dyscypliny zarządzania ryzykiem stron trzecich ICT w DORA. DORA Article 28 wymaga, aby podmioty finansowe zarządzały ryzykiem stron trzecich ICT jako częścią ram zarządzania ryzykiem ICT, pozostawały w pełni odpowiedzialne za zgodność także przy korzystaniu z dostawców ICT, prowadziły rejestr informacji dla ustaleń umownych dotyczących usług ICT oraz odróżniały ustalenia wspierające krytyczne lub istotne funkcje.

DORA Article 29 dodaje kwestie ryzyka koncentracji i podwykonawstwa. Obejmuje to możliwość zastąpienia, wielokrotne zależności od tych samych lub powiązanych dostawców, podwykonawstwo w państwach trzecich, ograniczenia związane z niewypłacalnością, odzyskiwanie danych, zgodność z ochroną danych oraz długie lub złożone łańcuchy podwykonawstwa.

DORA Article 30 definiuje następnie treść umów, której będą oczekiwać audytorzy. Obejmuje to opisy usług, warunki podwykonawstwa, lokalizacje przetwarzania danych, zobowiązania dotyczące ochrony danych, obowiązki w zakresie dostępu i odzyskiwania, poziomy usług, wsparcie incydentowe, współpracę z organami, prawa wypowiedzenia, udział w szkoleniach, prawa audytu oraz strategie wyjścia dla ustaleń wspierających krytyczne lub istotne funkcje.

Dojrzały Rejestr informacji DORA musi odpowiadać na cztery praktyczne pytania.

Słaby rejestr to arkusz kalkulacyjny aktualizowany raz w roku przez dział zakupów. Silny rejestr to zarządzany zbiór danych łączący portfel dostawców, inwentarz aktywów, rejestr chmurowy, repozytorium umów, zapisy prywatności, plany ciągłości działania, podręczniki reagowania na incydenty, rejestr ryzyk oraz dowody ISO/IEC 27001:2022.

Dlaczego ISO 27001 jest najszybszą drogą do rejestru DORA możliwego do obrony

ISO/IEC 27001:2022 zapewnia organizacjom strukturę systemu zarządzania, której często brakuje w dowodach DORA. Klauzule 4.1 do 4.4 wymagają, aby organizacja określiła kontekst, strony zainteresowane, obowiązki prawne, regulacyjne i umowne, zakres, interfejsy oraz zależności. To właśnie tu DORA powinna zostać osadzona w SZBI, ponieważ rejestr zależy od wiedzy, które usługi finansowe, dostawcy ICT, klienci, organy, platformy chmurowe i procesy outsourcingowe mieszczą się w zakresie.

Klauzule 5.1 do 5.3 wymagają przywództwa, spójności polityk, zasobów, odpowiedzialności oraz raportowania do najwyższego kierownictwa. Ma to znaczenie, ponieważ DORA Article 5 nakłada na organ zarządzający odpowiedzialność za definiowanie, zatwierdzanie, nadzorowanie i utrzymywanie rozliczalności za ramy zarządzania ryzykiem ICT, w tym polityki dotyczące zewnętrznych dostawców usług ICT oraz kanały raportowania.

Klauzule 6.1.1 do 6.1.3 to miejsce, w którym rejestr staje się oparty na ryzyku. ISO/IEC 27001:2022 wymaga powtarzalnego procesu oceny ryzyka, właścicieli ryzyka, analizy prawdopodobieństwa i skutków, postępowania z ryzykiem, doboru środków kontrolnych, Deklaracji stosowania oraz akceptacji ryzyka rezydualnego przez właściciela ryzyka. Rejestr DORA niepowiązany z postępowaniem z ryzykiem staje się statyczną listą. Rejestr powiązany ze scenariuszami ryzyka, środkami kontrolnymi i właścicielami staje się dowodem audytowym.

Klauzule 8.1 do 8.3 przekładają planowanie na kontrolowane działania operacyjne. Wspierają udokumentowane informacje, planowanie i kontrolę operacyjną, kontrolę zmian, kontrolę procesów dostarczanych zewnętrznie, planowane ponowne oceny ryzyka, wdrożenie postępowania z ryzykiem oraz przechowywanie dowodów. Ma to kluczowe znaczenie w 2026 r., ponieważ organy nadzorcze pytają nie tylko o to, czy rejestr istniał w konkretnym momencie. Pytają, czy nowe umowy, zmienione usługi, nowi podwykonawcy, migracje do chmury i zdarzenia wyjścia są ujmowane w cyklu ładu zarządczego.

Warstwa środków kontrolnych z Załącznika A wzmacnia ten sam wniosek. Relacje z dostawcami, umowy z dostawcami, ryzyko łańcucha dostaw ICT, monitorowanie usług dostawców, pozyskiwanie usług chmurowych i wyjście z nich, zarządzanie incydentami, ciągłość działania, obowiązki prawne i regulacyjne, prywatność, kopie zapasowe, rejestrowanie, monitorowanie, kryptografia oraz zarządzanie podatnościami — wszystkie te obszary wpływają na jakość rejestru.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint wyjaśnia fundament aktywów w fazie Controls in Action, krok 22:

W swojej najbardziej strategicznej postaci inwentarz aktywów pełni funkcję centralnego układu nerwowego Twojego SZBI. Informuje, jak nadawany jest dostęp (8.2), gdzie należy stosować szyfrowanie (8.24), które systemy wymagają kopii zapasowych (8.13), jakie logi są gromadzone (8.15), a nawet jak egzekwowane są polityki klasyfikacji i okresu przechowywania (5.10, 8.10).

Ten cytat oddaje praktyczny sens problemu. Nie da się utrzymywać wiarygodnego Rejestru informacji DORA bez wiarygodnego inwentarza aktywów. Jeżeli rejestr wskazuje „Core Banking SaaS”, ale inwentarz aktywów nie pokazuje interfejsów API, kont serwisowych, zbiorów danych, źródeł logów, kluczy szyfrujących, zależności kopii zapasowych i właścicieli, rejestr jest niekompletny z perspektywy audytu.

Model danych Clarysec: jeden rejestr, wiele widoków dowodowych

Rejestr informacji DORA nie powinien zastępować rejestru dostawców, rejestru aktywów ani rejestru chmurowego. Powinien je łączyć. Clarysec zwykle projektuje rejestr jako główną warstwę dowodową z kontrolowanymi relacjami do istniejących zapisów SZBI.

Minimalny użyteczny model obejmuje siedem powiązanych obiektów.

Taka struktura pozwala jednemu rejestrowi obsługiwać wiele żądań dowodowych. Organ nadzorczy DORA może przeglądać ustalenia umowne wspierające krytyczne lub istotne funkcje. Audytor ISO może prześledzić środki kontrolne dotyczące dostawców do odniesień z Załącznika A i postępowania z ryzykiem. Osoba dokonująca przeglądu GDPR może zobaczyć podmioty przetwarzające, kategorie danych, lokalizacje oraz zobowiązania dotyczące ochrony danych. Asesor pracujący w podejściu NIST może ocenić ład zarządczy łańcucha dostaw, krytyczność dostawców, wymagania umowne oraz monitorowanie cyklu życia.

Rejestr staje się czymś więcej niż odpowiedzią na pytanie „kim są nasi dostawcy?”. Staje się grafem zależności.

Fundamenty polityk, które czynią rejestr możliwym do audytu

Zestaw polityk Clarysec zapewnia rejestrowi operacyjne umocowanie. Dla MŚP Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME zaczyna od jasnego wymogu dotyczącego rejestru:

Rejestr dostawców musi być prowadzony i aktualizowany przez osobę kontaktową ds. administracyjnych lub zakupów. Musi obejmować:

Ta sama polityka dla MŚP ustanawia wymóg, aby umowy zawierały określone obowiązki bezpieczeństwa:

Umowy muszą zawierać obowiązkowe klauzule obejmujące:

Chociaż cytowane klauzule w samej polityce wprowadzają listy pól i kategorie obowiązkowych klauzul, przekaz wdrożeniowy jest bezpośredni: nadzór nad dostawcami musi być udokumentowany, przypisany i egzekwowany umownie.

Dla środowisk korporacyjnych polityka Clarysec Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy jest jeszcze bliższa oczekiwaniom nadzorczym DORA:

Rejestr zależności od dostawców: VMO prowadzi aktualny rejestr wszystkich dostawców krytycznych, obejmujący takie dane jak świadczone usługi/dostarczane produkty; informację, czy dostawca jest jedynym źródłem; dostępnych alternatywnych dostawców lub możliwość zastąpienia; aktualne warunki umowne; oraz ocenę wpływu w przypadku niewykonania świadczenia przez dostawcę lub naruszenia jego bezpieczeństwa. Rejestr jednoznacznie identyfikuje dostawców o wysokim poziomie zależności (np. takich, dla których nie istnieje szybka alternatywa).

To dobrze mapuje się na DORA Article 29 w zakresie ryzyka koncentracji i możliwości zastąpienia. Jeżeli dostawca jest jedynym źródłem, wspiera funkcję krytyczną, działa w państwie trzecim, korzysta z długiego łańcucha podwykonawstwa i nie ma przetestowanej ścieżki wyjścia, rejestr nie powinien ukrywać tego ryzyka w polu tekstowym. Powinien je oznaczyć, przypisać właściciela i powiązać z postępowaniem z ryzykiem.

Korporacyjna polityka Clarysec Third party and supplier security policy Third party and supplier security policy jednoznacznie określa zakres:

Obejmuje zarówno bezpośrednich dostawców, jak i — tam, gdzie ma to zastosowanie — ich podwykonawców, a także oprogramowanie stron trzecich, infrastrukturę, wsparcie i usługi zarządzane.

To zdanie opisuje częstą lukę DORA. Wiele organizacji ujmuje bezpośrednich dostawców ICT, ale nie dokumentuje podwykonawców, podwykonawców przetwarzania, narzędzi usług zarządzanych, platform wsparcia ani oprogramowania stron trzecich osadzonego w usłudze.

Dowody umowne również mają znaczenie. Ta sama polityka korporacyjna obejmuje:

Prawo do audytu, inspekcji oraz żądania dowodów bezpieczeństwa

Ta fraza powinna być widoczna na liście kontrolnej przeglądu umów. Jeżeli umowa z krytycznym dostawcą ICT nie zawiera prawa do audytu ani prawa żądania dowodów, rejestr powinien wskazywać działanie naprawcze.

Dowody dotyczące aktywów są równie ważne. Polityka Clarysec dla MŚP Asset Management Policy Asset Management Policy - SME stanowi:

Osoba odpowiedzialna za IT musi prowadzić ustrukturyzowany inwentarz aktywów, który obejmuje co najmniej następujące pola:

Korporacyjna Asset Management Policy Asset Management Policy podobnie stanowi:

Inwentarz aktywów musi zawierać co najmniej:

Rejestr nie musi powielać każdego pola aktywa, ale musi odwoływać się do inwentarza aktywów. Jeżeli SaaS monitorowania płatności wspiera wykrywanie nadużyć, rejestr DORA powinien linkować do aktywa aplikacyjnego, aktywa zbioru danych, kont serwisowych, integracji API, źródeł logów oraz właściciela biznesowego.

Usługi chmurowe wymagają osobnego widoku. Polityka Clarysec dla MŚP Cloud Usage Policy Cloud Usage Policy - SME wymaga:

Rejestr usług chmurowych musi być prowadzony przez dostawcę IT lub GM. Musi on rejestrować:

Jest to szczególnie wartościowe przy wykrywaniu shadow IT. Rejestr DORA, który pomija usługi chmurowe kupione poza działem zakupów, nie przejdzie praktycznego testu kompletności.

Wreszcie polityka Clarysec Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy przekształca cross-compliance w wymóg SZBI:

Wszystkie obowiązki prawne i regulacyjne muszą być mapowane na konkretne polityki, środki kontrolne i właścicieli w ramach Systemu Zarządzania Bezpieczeństwem Informacji (SZBI).

To pomost między rejestrem DORA a dowodami ISO 27001. Rejestr nie powinien tylko pokazywać dostawców. Powinien pokazywać, które polityki, środki kontrolne i osoby odpowiedzialne spełniają obowiązek regulacyjny.

Mapowanie wymagań DORA na ISO 27001 i dowody Clarysec

Poniższa tabela łączy kluczowe oczekiwania wobec rejestru ze środkami kontrolnymi Załącznika A ISO/IEC 27001:2022 oraz praktycznymi artefaktami dowodowymi Clarysec.

To mapowanie jest momentem, w którym rejestr przestaje być arkuszem kalkulacyjnym i staje się modelem dowodowym. Każdy wiersz powinien mieć właściciela umowy, właściciela dostawcy, właściciela usługi, właściciela biznesowego i właściciela zgodności. Każda krytyczna relacja powinna mieć zapis ryzyka, listę kontrolną klauzul umownych, powiązanie z aktywem oraz częstotliwość monitorowania.

Przykład praktyczny: mapowanie jednej umowy ICT na dowody ISO 27001

Wyobraźmy sobie, że podmiot finansowy korzysta z chmurowej platformy analityki nadużyć. Usługa pobiera metadane transakcji, wspiera scoring nadużyć w czasie rzeczywistym, integruje się z platformą płatniczą, przechowuje spseudonimizowane identyfikatory klientów, korzysta z podwykonawcy hostingu w chmurze i zapewnia wsparcie zarządzane z zatwierdzonej lokalizacji w państwie trzecim.

Słaby wiersz rejestru brzmi: „Dostawca: FraudCloud. Usługa: analityka nadużyć. Umowa podpisana. Krytyczne: tak”.

Wiersz rejestru na poziomie oczekiwanym przez organ nadzorczy wygląda zupełnie inaczej.

Teraz zespół ds. zgodności może przygotować spójny pakiet dowodowy. Rejestr dostawców dowodzi, że dostawca istnieje i ma właściciela. Inwentarz aktywów dowodzi, że wewnętrzne systemy, interfejsy API, zbiory danych i logi są znane. Lista kontrolna umowy dowodzi, że obowiązkowe klauzule DORA zostały przejrzane. Ocena ryzyka dowodzi, że uwzględniono koncentrację, podwykonawstwo, ochronę danych i odporność operacyjną. Deklaracja stosowania pokazuje, które środki kontrolne wybrano. Przegląd monitorowania dowodzi, że ustalenie nie zostało zapomniane po onboardingu.

Zenith Blueprint, faza Risk Management, krok 13, zaleca dokładnie taką identyfikowalność:

Odwołania krzyżowe do regulacji: jeżeli określone środki kontrolne zostały wdrożone specjalnie w celu spełnienia GDPR, NIS2 lub DORA, można to odnotować albo w Rejestrze ryzyk (jako element uzasadnienia wpływu ryzyka), albo w notatkach SoA.

W ten sposób rejestr DORA staje się dowodem ISO 27001, a nie równoległą biurokracją.

Łańcuch dostawców i podwykonawców to miejsce, w którym jakość rejestru najczęściej zawodzi

Największe braki rejestru nie wynikają z braku głównych dostawców. Wynikają z ukrytych łańcuchów zależności.

Dostawca zarządzanego bezpieczeństwa może korzystać z platformy SIEM, agenta telemetrycznego dla punktów końcowych, systemu zgłoszeniowego oraz offshore’owego zespołu triage. Operator płatności może zależeć od hostingu w chmurze, usług tożsamości, baz danych nadużyć i łączności rozliczeniowej. Dostawca SaaS może polegać na wielu podwykonawcach przetwarzania w zakresie analityki, poczty elektronicznej, obserwowalności, obsługi klienta i kopii zapasowych.

DORA Article 29 wymusza koncentrację uwagi na ryzyku koncentracji i podwykonawstwa. NIS2 Article 21 wymaga również bezpieczeństwa łańcucha dostaw dla bezpośrednich dostawców i dostawców usług oraz oczekuje, że podmioty będą uwzględniały podatności specyficzne dla każdego bezpośredniego dostawcy, ogólną jakość produktów, praktyki cyberbezpieczeństwa dostawców oraz procedury bezpiecznego rozwoju oprogramowania. Dla podmiotów finansowych objętych DORA to DORA pełni rolę sektorowego zbioru wymagań dla nakładających się wymagań NIS2 w zakresie zarządzania ryzykiem cyberbezpieczeństwa i zgłaszania incydentów, ale logika łańcucha dostaw jest spójna.

Clarysec Zenith Blueprint, faza Controls in Action, krok 23, zawiera praktyczną instrukcję:

Dla każdego krytycznego dostawcy ustal, czy korzysta on z podwykonawców (podwykonawców przetwarzania), którzy mogą uzyskiwać dostęp do Twoich danych lub systemów. Udokumentuj, w jaki sposób Twoje wymagania bezpieczeństwa informacji są przenoszone na te podmioty — przez warunki umowne dostawcy albo przez Twoje własne bezpośrednie klauzule.

To obszar, w którym wiele organizacji wymaga działań naprawczych w 2026 r. Umowy podpisane przed etapem gotowości do DORA mogą nie obejmować przejrzystości podwykonawców, praw do dowodów audytowych, współpracy z organami, wsparcia incydentowego, wsparcia wyjścia ani zobowiązań lokalizacyjnych. Rejestr powinien zatem zawierać status remediacji umowy, taki jak: zakończona, luka zaakceptowana, renegocjacja w toku albo wymagane rozwiązanie wyjścia.

Cross-compliance: DORA, NIS2, GDPR i NIST potrzebują tej samej prawdy o zależnościach

Dobrze zaprojektowany Rejestr informacji DORA wspiera więcej niż tylko DORA.

NIS2 Article 20 czyni cyberbezpieczeństwo odpowiedzialnością organu zarządzającego poprzez zatwierdzanie, nadzór i szkolenia. Article 21 wymaga analizy ryzyka, polityk, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego pozyskiwania i utrzymania, oceny skuteczności, cyberhigieny, kryptografii, bezpieczeństwa HR, kontroli dostępu, zarządzania aktywami oraz MFA tam, gdzie jest to właściwe. Obszary te silnie pokrywają się z ISO/IEC 27001:2022 i modelem dowodowym rejestru.

GDPR dodaje rozliczalność w zakresie prywatności. Jego zakres terytorialny może obejmować organizacje z UE i spoza UE, które przetwarzają dane osobowe w kontekście jednostek organizacyjnych w UE, oferują towary lub usługi osobom fizycznym w UE albo monitorują ich zachowanie. Definicje GDPR dotyczące administratora, podmiotu przetwarzającego, przetwarzania, pseudonimizacji oraz naruszenia ochrony danych osobowych są bezpośrednio istotne dla mapowania dostawców ICT. Jeżeli rejestr DORA identyfikuje dostawców ICT i podwykonawców, ale nie identyfikuje ról w przetwarzaniu danych osobowych, kategorii danych, lokalizacji i środków bezpieczeństwa, nie będzie wspierał dowodów GDPR.

NIST CSF 2.0 zapewnia kolejną użyteczną perspektywę. Jego funkcja GOVERN wymaga, aby organizacje rozumiały misję, oczekiwania interesariuszy, zależności, wymagania prawne i umowne, usługi, od których zależą inni, oraz usługi, od których zależy organizacja. Wyniki GV.SC dotyczące łańcucha dostaw wymagają programu zarządzania ryzykiem łańcucha dostaw, zdefiniowanych ról dostawców, integracji z zarządzaniem ryzykiem przedsiębiorstwa, krytyczności dostawców, wymagań umownych, due diligence, monitorowania cyklu życia, koordynacji incydentów oraz planowania po zakończeniu relacji.

Praktyczny widok cross-compliance wygląda następująco.

Celem nie jest tworzenie pięciu strumieni prac zgodności. Celem jest stworzenie jednego modelu dowodowego, który można filtrować dla każdego frameworka.

Oczami audytora

Organ nadzorczy DORA skupi się na kompletności, krytycznych lub istotnych funkcjach, ustaleniach umownych, podwykonawstwie, ryzyku koncentracji, ładzie zarządczym, raportowaniu oraz na tym, czy rejestr jest utrzymywany. Może poprosić o próbkę krytycznych dostawców i oczekiwać klauzul umownych, ocen ryzyka, strategii wyjścia, warunków wsparcia incydentowego oraz dowodów nadzoru kierownictwa.

Audytor ISO/IEC 27001:2022 rozpocznie od zakresu SZBI, stron zainteresowanych, obowiązków regulacyjnych, oceny ryzyka, Deklaracji stosowania, kontroli operacyjnej i udokumentowanych informacji. Sprawdzi, czy relacje z dostawcami i inwentarze aktywów są utrzymywane, czy procesy dostarczane zewnętrznie są kontrolowane, czy zmiany wyzwalają ponowną ocenę oraz czy dowody wspierają deklarowane wdrożenie środków kontrolnych.

Asesor NIST CSF 2.0 często poprosi o profile bieżące i docelowe, oczekiwania ładu zarządczego, mapowanie zależności, krytyczność dostawców, integrację wymagań w umowach, monitorowanie cyklu życia oraz priorytetyzowane działania doskonalące.

Audytor zorientowany na COBIT 2019 zazwyczaj zbada własność ładu zarządczego, rozliczalność procesów, uprawnienia decyzyjne, monitorowanie wyników, raportowanie ryzyka oraz zapewnienie. Zapyta, czy rejestr jest osadzony w ładzie korporacyjnym, a nie tylko utrzymywany przez funkcję zgodności.

Zenith Controls pomaga przełożyć te perspektywy, zakotwiczając temat w środkach kontrolnych Załącznika A ISO/IEC 27001:2022 A.5.9, A.5.19 i A.5.20, a następnie wykorzystując interpretację cross-compliance do połączenia aktywów, relacji z dostawcami i umów z dostawcami z oczekiwaniami regulacyjnymi, zarządczymi i audytowymi. To różnica między „mamy rejestr” a „potrafimy obronić rejestr”.

Polityka Clarysec dla MŚP Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy - SME również odnosi się do jakości dowodów:

Metadane (np. kto je zebrał, kiedy i z jakiego systemu) muszą być udokumentowane.

To wymaganie jest niewielkie, ale bardzo silne. W żądaniu dowodowym w 2026 r. arkusz kalkulacyjny bez metadanych zbierania danych jest słaby. Eksport rejestru pokazujący system źródłowy, datę ekstrakcji, odpowiedzialnego właściciela, status zatwierdzenia i częstotliwość przeglądu jest znacznie mocniejszy.

Typowe ustalenia dotyczące Rejestru informacji DORA w 2026 r.

Najczęstsze ustalenia mają charakter praktyczny.

Po pierwsze, niekompletność rejestru. Usługi chmurowe, narzędzia wsparcia, platformy monitorowania, narzędzia programistyczne, systemy zgłoszeniowe i platformy analityki danych często są pomijane, ponieważ dział zakupów nie sklasyfikował ich jako usług ICT.

Po drugie, słaba logika krytyczności. Niektóre zespoły oznaczają dostawców jako krytycznych na podstawie wydatków, a nie wpływu biznesowego. DORA interesuje to, czy usługa ICT wspiera funkcję krytyczną lub istotną.

Po trzecie, luki w dowodach umownych. Starsze umowy z dostawcami często nie zawierają klauzul gotowych na DORA dotyczących praw audytu, wsparcia incydentowego, podwykonawstwa, współpracy z organami, lokalizacji usług, zwrotu danych, wypowiedzenia i wsparcia wyjścia.

Po czwarte, słabe powiązanie z aktywami. Rejestry wymieniają dostawców, ale nie linkują do aplikacji, zbiorów danych, interfejsów API, tożsamości, logów, infrastruktury ani usług biznesowych. Utrudnia to analizę wpływu podczas incydentów i awarii dostawców.

Po piąte, nieprzejrzystość podwykonawców. Organizacja zna głównego dostawcę, ale nie potrafi wyjaśnić, którzy podwykonawcy przetwarzania lub dostawcy techniczni wspierają usługę.

Po szóste, brak wyzwalaczy zmian. Dostawca dodaje nowego podwykonawcę przetwarzania, zmienia region hostingu, migruje architekturę albo modyfikuje dostęp wsparcia, ale nikt nie aktualizuje rejestru ani nie dokonuje ponownej oceny ryzyka.

Po siódme, brak częstotliwości dowodowej. Nie ma zdefiniowanej częstotliwości przeglądu dostawców, przeglądu umów, walidacji aktywów, uzgadniania rejestru chmurowego ani raportowania zarządczego.

Są to problemy możliwe do rozwiązania, ale tylko wtedy, gdy rejestr ma właścicieli i przepływy pracy.

Praktyczny 30-dniowy plan usprawnień

Zacznij od zakresu. Zidentyfikuj wszystkie funkcje biznesowe, które mogą być krytyczne lub istotne w rozumieniu DORA. Dla każdej funkcji wypisz usługi ICT, od których zależy. Nie zaczynaj od wydatków zakupowych. Zacznij od zależności operacyjnej.

Uzgodnij podstawowe źródła danych: rejestr dostawców, repozytorium umów, inwentarz aktywów i rejestr usług chmurowych. Dodaj zapisy podmiotów przetwarzających na potrzeby prywatności oraz zależności reagowania na incydenty tam, gdzie ma to znaczenie. Celem nie jest perfekcja pierwszego dnia. Celem jest jeden kręgosłup rejestru z jasno oznaczonymi niewiadomymi.

Klasyfikuj dostawców i usługi według takich kryteriów jak wspierana funkcja, wrażliwość danych, operacyjna możliwość zastąpienia, koncentracja, podwykonawstwo, lokalizacje, wpływ incydentu, czas odzyskiwania i znaczenie regulacyjne.

Przejrzyj umowy dla każdego krytycznego lub istotnego ustalenia ICT. Sprawdź, czy umowa zawiera opisy usług, warunki podwykonawstwa, lokalizacje, zobowiązania dotyczące ochrony danych, dostęp i odzyskiwanie, poziomy usług, wsparcie incydentowe, prawa audytu, współpracę z organami, wypowiedzenie, udział w szkoleniach i wsparcie wyjścia.

Zmapuj dowody ISO dla każdego krytycznego ustalenia. Powiąż je z zapisami aktywów, pozycjami oceny ryzyka, środkami kontrolnymi SoA, due diligence dostawcy, przeglądami monitorowania, planami ciągłości, podręcznikami incydentowymi i dowodami strategii wyjścia.

Przypisz częstotliwość. Dostawcy krytyczni mogą wymagać kwartalnego przeglądu, corocznego zapewnienia, przeglądu umowy przed odnowieniem oraz natychmiastowej ponownej oceny przy istotnej zmianie. Dostawcy niekrytyczni mogą być przeglądani rocznie albo po zdarzeniach wyzwalających.

Użyj tej listy kontrolnej, aby przekształcić rejestr w proces operacyjny:

• Wyznacz właściciela rejestru DORA oraz właściciela zastępczego.
• Powiąż każdy wiersz rejestru z identyfikatorem umowy i właścicielem dostawcy.
• Powiąż każdą krytyczną lub istotną usługę ICT z funkcją biznesową i zapisami aktywów.
• Dodaj pola podwykonawców i podwykonawców przetwarzania, nawet jeśli początkowo są oznaczone jako nieznane.
• Dodaj status klauzul umownych dla warunków krytycznych dla DORA.
• Dodaj odniesienia do ryzyk ISO/IEC 27001:2022 i SoA.
• Dodaj pola roli GDPR, danych osobowych i lokalizacji tam, gdzie ma to zastosowanie.
• Dodaj częstotliwość przeglądu i metadane ostatniego przeglądu.
• Utwórz reguły eskalacji dla brakujących klauzul, nieznanych podwykonawców i wysokiego ryzyka koncentracji.
• Raportuj wskaźniki jakości rejestru kierownictwu.

To miejsce, w którym 30-etapowa metoda wdrożeniowa Clarysec, zestaw polityk oraz Zenith Controls działają razem. Zenith Blueprint zapewnia ścieżkę wdrożenia — od postępowania z ryzykiem i identyfikowalności SoA w kroku 13, przez inwentarz aktywów w kroku 22, po środki kontrolne dotyczące dostawców w kroku 23. Polityki określają, kto musi prowadzić rejestry, jakie dowody umowne i dotyczące aktywów muszą istnieć oraz jak ujmowane są metadane zgodności. Zenith Controls zapewnia kompas cross-compliance do mapowania tych samych dowodów na oczekiwania audytowe DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST i COBIT 2019.

Przekształć rejestr w dowody, zanim poprosi o nie organ nadzorczy

Jeżeli Twój Rejestr informacji DORA nadal jest arkuszem kalkulacyjnym odłączonym od umów, aktywów, dostawców, podwykonawców i dowodów ISO 27001, 2026 jest rokiem, w którym należy to naprawić.

Zacznij od użycia Zenith Blueprint Zenith Blueprint, aby połączyć postępowanie z ryzykiem, inwentarz aktywów i nadzór nad dostawcami. Użyj Zenith Controls Zenith Controls, aby zmapować środki kontrolne Załącznika A ISO/IEC 27001:2022 A.5.9, A.5.19 i A.5.20 na dowody cross-compliance. Następnie przełóż wymagania na działania operacyjne poprzez polityki Clarysec dotyczące dostawców, aktywów, chmury, zgodności prawnej i monitorowania audytu, w tym Third-Party and Supplier Security Policy - SME, Supplier Dependency Risk Management Policy, Third party and supplier security policy, Asset Management Policy - SME, Asset Management Policy, Cloud Usage Policy - SME, Legal and Regulatory Compliance Policy oraz Audit and Compliance Monitoring Policy - SME.

Najlepszy czas na poprawę jakości rejestru jest przed żądaniem organu, audytem wewnętrznym, awarią dostawcy albo odnowieniem umowy. Drugi najlepszy czas jest teraz. Pobierz odpowiednie polityki Clarysec, zmapuj swój obecny rejestr względem powyższego modelu dowodowego i umów ocenę rejestru DORA, aby przekształcić rozproszone dane o dostawcach w dowody na poziomie oczekiwanym przez organ nadzorczy.