DORA Artykuł 28, ryzyko stron trzecich ICT: audyt dostawcy hostingu i WAF dla WordPress
Artykuł 28 Rozporządzenia 2022/2554 to ta część DORA, która rozstrzyga, czy klient z sektora finansowego w ogóle może podpisać umowę hostingową lub subskrypcję WAF. Stosuje się do instytucji kredytowych, instytucji płatniczych, ubezpieczycieli, firm inwestycyjnych, dostawców usług w zakresie kryptoaktywów i około piętnastu kolejnych kategorii z artykułu 2. Od 17 stycznia 2025 stosuje się bezpośrednio, bez transpozycji.
To artykuł wspierający w filarze NIS2 i DORA na WordPress, z odesłaniami do ścieżki dowodowej Załącznika II NIS2 i do przeglądu stosu CRA + NIS2 + DORA.
TL;DR
- DORA artykuł 28 = ogólne zasady zarządzania ryzykiem stron trzecich ICT.
- Artykuł 30 = obowiązkowe klauzule umowne.
- Artykuł 31 = reżim wyznaczania CTPP, prowadzony przez Europejskie Urzędy Nadzoru.
- Mandat WordPress dla banku lub ubezpieczyciela uruchamia wpis do rejestru, due diligence, klauzule i plan wyjścia.
- W rejestrze ląduje hosting, CDN, WAF, wtyczka płatności i wtyczka wysyłki e-maili.
Kogo dotyczy DORA w sektorze finansowym
Artykuł 2 ust. 1 wymienia podmioty finansowe. Najczęstsze w mandatach WordPress:
- Instytucje kredytowe i ich grupy.
- Instytucje płatnicze i instytucje pieniądza elektronicznego.
- Firmy inwestycyjne, w tym prowadzące MTF lub OTF.
- Dostawcy usług w zakresie kryptoaktywów pod MiCA.
- Zakłady ubezpieczeń i reasekuracji.
- Pośrednicy ubezpieczeniowi powyżej progu wielkościowego.
- Dostawcy usług finansowania społecznościowego.
- Fundusze inwestycyjne (zarządzający UCITS, AIFM).
Do tego dochodzą kluczowi zewnętrzni dostawcy usług ICT (CTPP), wyznaczani na podstawie art. 31 przez Europejskie Urzędy Nadzoru (EBA, EIOPA i ESMA) za pośrednictwem Wspólnego Komitetu, na zalecenie forum nadzoru. Pierwszą listę opublikowano 18 listopada 2025 i obejmuje 19 dostawców: chmury publiczne (Amazon Web Services, Google Cloud, Microsoft, Oracle), firmy doradcze i outsourcingowe IT (Accenture, Capgemini, IBM, Kyndryl, NTT DATA, Tata Consultancy Services), operatorów telekomunikacyjnych i centrów danych (Colt, Deutsche Telekom, Equinix, InterXion, Orange), dostawców danych finansowych (Bloomberg, LSEG Data and Risk) i oprogramowania (FIS, SAP). Nie ma na niej żadnego hostingu WordPress ani żadnego CDN. Agencja WordPress jest zwykłym zewnętrznym dostawcą usług ICT, a obowiązki z art. 28 do 30 docierają do niej przez umowę z podmiotem finansowym.
Wymogi artykułu 28 DORA ustęp po ustępie
Artykuł 28 ma dziesięć ustępów. Pierwsze osiem wiąże podmiot finansowy, ustępy 9 i 10 zlecają Europejskim Urzędom Nadzoru przygotowanie standardów technicznych. Co każdy z nich oznacza dla zlecenia WordPress:
Artykuł 28 ust. 1. Podmiot finansowy zarządza ryzykiem ze strony zewnętrznych dostawców usług ICT jako integralnym elementem ryzyka ICT w swoich ramach zarządzania tym ryzykiem. Litera a) to zdanie, które dział zakupów cytuje najczęściej: podmiot przez cały czas ponosi pełną odpowiedzialność za wypełnianie obowiązków, także po zleceniu usługi na zewnątrz. Litera b) wprowadza proporcjonalność, liczoną charakterem, skalą, złożonością i znaczeniem zależności od ICT. Dostawca dostarcza dowody, odpowiedzialność do niego nie przechodzi.
Artykuł 28 ust. 2. Regularnie przeglądana strategia dotycząca ryzyka ze strony zewnętrznych dostawców usług ICT, obejmująca politykę korzystania z usług ICT wspierających krytyczne lub istotne funkcje. Organ zarządzający regularnie przegląda ryzyka tych umów. Mikroprzedsiębiorstwa i podmioty objęte uproszczonymi ramami z art. 16 ust. 1 są z tego ustępu wyłączone.
Artykuł 28 ust. 3. Rejestr informacji o wszystkich ustaleniach umownych dotyczących usług ICT, z wyróżnieniem tych, które wspierają krytyczne lub istotne funkcje. Podmiot co najmniej raz w roku przekazuje właściwemu organowi liczbę nowych ustaleń, kategorie dostawców i świadczone usługi, udostępnia pełny rejestr na żądanie i z wyprzedzeniem informuje organ o każdej planowanej umowie dla krytycznej lub istotnej funkcji. Dla WordPress: hosting, CDN, WAF, bramka płatności, e-mail transakcyjny, dostawca AI, narzędzie monitoringu, miejsce backupu.
Artykuł 28 ust. 4. Przed podpisaniem podmiot ocenia, czy umowa wspiera krytyczną lub istotną funkcję (lit. a), czy spełnione są nadzorcze warunki zawarcia umowy (lit. b), wszystkie istotne ryzyka, w tym ryzyko koncentracji z art. 29 (lit. c), przeprowadza due diligence przydatności dostawcy (lit. d) i ocenia konflikty interesów (lit. e).
Artykuł 28 ust. 5. Umowy wyłącznie z dostawcami, którzy przestrzegają odpowiednich standardów bezpieczeństwa informacji. Przy krytycznych lub istotnych funkcjach podmiot bierze pod uwagę najnowsze standardy najwyższej jakości. Raport ISO/IEC 27001 albo SOC 2 hostingu jest dowodem tylko wtedy, gdy jego zakres obejmuje zamówioną usługę.
Artykuł 28 ust. 6. Podmiot z góry, w podejściu opartym na ryzyku, ustala częstotliwość i obszary audytów i kontroli dostawcy oraz sprawdza, czy audytorzy mają kompetencje potrzebne przy usługach technicznie złożonych.
Artykuł 28 ust. 7. Umowę musi dać się wypowiedzieć przy poważnym naruszeniu przez dostawcę, przy okolicznościach mogących zmienić wykonywanie funkcji (w tym istotnych zmianach po stronie dostawcy), przy wykazanych słabościach jego zarządzania ryzykiem ICT oraz wtedy, gdy właściwy organ nie może już skutecznie nadzorować podmiotu z powodu tej umowy.
Artykuł 28 ust. 8. Strategie wyjścia dla usług ICT wspierających krytyczne lub istotne funkcje. Wyjście nie może zakłócić działalności, ograniczyć zgodności z wymogami regulacyjnymi ani pogorszyć ciągłości i jakości usług dla klientów. Plany wyjścia są kompleksowe, udokumentowane, odpowiednio przetestowane i okresowo przeglądane.
Artykuł 28 ust. 9 i 10. Upoważnienia do standardów technicznych. Z ust. 9 powstało rozporządzenie wykonawcze (UE) 2024/2956 ze wzorami rejestru. Z ust. 10 powstało rozporządzenie delegowane (UE) 2024/1773 o treści polityki z ust. 2.
Klauzule umowne z art. 30 DORA w umowie hostingu
Art. 30 ust. 1 wymaga, by pełna umowa razem z umowami o gwarantowanym poziomie usług była spisana w jednym dokumencie. Ust. 2 wymienia minimalne elementy każdej umowy ICT, ust. 3 dodaje elementy umów wspierających krytyczne lub istotne funkcje. Szablon agencyjny, który dołączam do umów hostingu i WAF, trzyma się tej numeracji:
| Klauzula | Art. 30 | Co trafia do umowy WordPress |
|---|---|---|
| Pełny opis usług i warunki podwykonawstwa | 2(a) | Poziom hostingu, zestaw reguł WAF, wtyczki w cenie, czy podwykonawstwo jest dozwolone i na jakich warunkach |
| Lokalizacje świadczenia i przetwarzania | 2(b) | Regiony lub państwa centrum danych i wsparcia, uprzednie powiadomienie o każdej zmianie lokalizacji |
| Dostępność, autentyczność, integralność i poufność danych | 2(c) | Szyfrowanie w spoczynku i w transmisji, kontrola dostępu, umowa powierzenia z art. 28 RODO |
| Dostęp, odzyskanie i zwrot danych | 2(d) | Zrzut SQL i archiwum przesłanych plików w łatwo dostępnym formacie przy niewypłacalności, zaprzestaniu działalności lub rozwiązaniu umowy |
| Opisy poziomu usług | 2(e) | SLA dostępności, czasy reakcji, aktualizacje SLA |
| Pomoc przy incydentach ICT | 2(f) | Wsparcie bez dodatkowych kosztów albo po koszcie ustalonym z góry |
| Współpraca z organami | 2(g) | Pełna współpraca z właściwymi organami i organami ds. restrukturyzacji i uporządkowanej likwidacji |
| Prawo wypowiedzenia i okresy wypowiedzenia | 2(h) | Podstawy wypowiedzenia i minimalny okres wypowiedzenia |
| Szkolenia i świadomość bezpieczeństwa | 2(i) | Udział w programach bezpieczeństwa ICT podmiotu (art. 13 ust. 6) |
| Pełne poziomy usług z mierzalnymi celami | 3(a) | RPO, RTO, ilościowe i jakościowe cele, działania naprawcze |
| Okresy wypowiedzenia i obowiązki sprawozdawcze | 3(b) | Powiadomienie o każdej zmianie, która może wpłynąć na świadczenie usługi |
| Plany awaryjne i środki bezpieczeństwa | 3(c) | Przetestowany plan ciągłości, polityki bezpieczeństwa dostawcy |
| TLPT | 3(d) | Udział w testach z art. 26 i 27 |
| Bieżące monitorowanie i audyt | 3(e) | Nieograniczone prawa dostępu, kontroli i audytu dla podmiotu i organu |
| Strategia wyjścia i okres przejściowy | 3(f) | Obowiązkowy okres przejściowy na czas migracji do innego dostawcy albo do rozwiązań wewnętrznych |
Ust. 4 dodaje, że strony rozważają standardowe klauzule umowne opracowane przez organy publiczne. Trzymam tę macierz jako jeden plik Markdown w folderze zlecenia. Każda umowa jest z nią porównywana przed podpisem.
Rejestr informacji DORA dla dostawców WordPress
Mandat WordPress dla podmiotu finansowego dotyka większej liczby stron trzecich ICT, niż dział zakupów zwykle przewiduje. Rejestr, który stawiam pierwszego dnia mandatu:
- Dostawca hostingu. Faktyczny operator data center, panel zarządzania, zespół wsparcia. Krytyczny lub istotny, jeśli WordPress jest częścią dostarczania usług klientom.
- Dostawca CDN. Cloudflare, Fastly, Akamai. Przetwarza ruch, widzi treści żądań, kończy TLS. Często krytyczny lub istotny.
- Dostawca WAF. Czasem ten sam co CDN, czasem oddzielny (Sucuri, Imperva). Inspekcjonuje payloady. Krytyczny lub istotny.
- Wtyczka płatności. Stripe, Adyen, mollie, gatewaye lokalne. Autor wtyczki to jeden dostawca; operator gatewaya to drugi. Obaj do rejestru.
- E-mail transakcyjny. SES, Postmark, SendGrid. Przenosi resety hasła, powiadomienia KYC, alerty AML. Często krytyczny lub istotny.
- Monitoring i APM. New Relic, Datadog, Sentry. Odbiera stack trace’y i fragmenty payloadów.
- Cel kopii zapasowej. S3, Backblaze, Wasabi. Trzyma bazę i przesyły. Od niego zależy odtworzenie, więc zwykle wspiera krytyczną lub istotną funkcję.
- Dostawca AI. Jeśli WordPress używa LLM do funkcji kontaktu z klientem (czat, podsumowania), dostawca LLM jest w zakresie.
- Marketplace wtyczek. WordPress.org, marketplace’y premium. Kanały aktualizacji są częścią łańcucha dostaw w rozumieniu łańcucha dostaw usług ICT z art. 1 pkt 2 rozporządzenia wykonawczego 2024/2956.
Rejestr trzyma na każdego dostawcę: nazwę prawną, referencję umowy, opis usługi, przepływy danych, klasyfikację krytyczności, lokalizację przetwarzania, datę ostatniego due diligence, odesłanie do strategii wyjścia.
Wzory rejestru informacji DORA według rozporządzenia wykonawczego 2024/2956
Rejestr nie ma dowolnej formy. Rozporządzenie wykonawcze (UE) 2024/2956 ustala standardowe wzory, w których podmiot prowadzi rejestr z art. 28 ust. 3. Trzy jego zasady zmieniają to, co agencja WordPress musi przekazać:
- Identyfikator dostawcy. Art. 3 ust. 5 wymaga, by każdego dostawcę będącego osobą prawną oznaczyć ważnym i aktywnym identyfikatorem podmiotu prawnego (LEI) albo europejskim unikatowym identyfikatorem (EUID), a jeśli są oba, to oboma. Spółka z UE ma EUID z rejestru handlowego, LEI zamawia się osobno. Osoby fizyczne prowadzące działalność są z tego wyłączone.
- Pozycja w łańcuchu dostaw. Art. 2 nadaje każdemu dostawcy pozycję: bezpośredni dostawca ma zawsze pozycję 1, każdy podwykonawca wyższą liczbę. Jeśli agencja fakturuje hosting od innej firmy, agencja ma pozycję 1, a hosting pozycję 2.
- Podwykonawcy za krytycznymi lub istotnymi funkcjami. Art. 3 ust. 2 lit. b) nakazuje wpisać do rejestru wszystkich podwykonawców, którzy faktycznie wspierają te usługi, a ust. 6 wymaga, by także oni podali LEI lub EUID, za pośrednictwem bezpośredniego dostawcy.
Art. 5 wymienia wzory, w tym B_05.01 (bezpośredni dostawcy i podwykonawcy), B_05.02 (łańcuch dostaw usług ICT), B_06.01 (identyfikacja funkcji) i B_07.01 (ocena usług wspierających krytyczne lub istotne funkcje). Według tej struktury arkusz, który przekazuję klientowi, ma dla każdego dostawcy nazwę prawną, LEI lub EUID, pozycję, usługę, miejsca świadczenia i przetwarzania oraz wspieraną funkcję.
Jak ocenić ryzyko koncentracji DORA przy jednym dostawcy chmury
Ryzyko koncentracji ma osobny artykuł. Art. 28 ust. 4 lit. c) odsyła do art. 29, który przy usługach wspierających krytyczne lub istotne funkcje każe sprawdzić, czy nowa umowa wiąże podmiot z dostawcą, którego nie można łatwo zastąpić, albo dokłada kolejne ustalenie z tym samym dostawcą lub z blisko powiązanymi dostawcami. Bank, który używa Cloudflare do CDN, Cloudflare Workers do backendu, Cloudflare R2 do przechowywania obiektów i Cloudflare Stream do wideo, mieści się w drugim przypadku. To nie jest wniosek specyficzny dla Cloudflare; tak samo działa to ze stosami AWS, Azure czy GCP.
W WordPressie wygląda to zwykle tak: hosting na AWS, kopie zapasowe w S3, e-mail przez SES, monitoring w CloudWatch. Cztery zależności od AWS, jeden dostawca. Art. 29 ust. 1 każe rozważyć korzyści i koszty rozwiązań alternatywnych, takich jak różni dostawcy; nie nakazuje dywersyfikacji za wszelką cenę. Rejestr ryzyk musi wprost odnotować koncentrację i ją uzasadnić albo zaplanować dywersyfikację. Art. 29 ust. 2 dodaje przy podwykonawcach z państwa trzeciego właściwe prawo upadłościowe, ograniczenia w pilnym odzyskaniu danych i zgodność z unijnymi przepisami o ochronie danych.
Strategia wyjścia DORA dla hostingu i WAF WordPress
Artykuł 28 ust. 8 wymaga, by strategia wyjścia była udokumentowana i przetestowana. Dla hostingu i WAF WordPress prawdziwa strategia wyjścia obejmuje:
- Eksport bazy danych w formacie standardowym. Zrzut SQL kompatybilny ze stockowym MySQL lub MariaDB, bez rozszerzeń autorskich.
- Eksport systemu plików wraz z przesyłami. Archiwum tar lub zip, pobieralne spoza panelu dostawcy.
- Kontrola DNS. Konto rejestratora domen w posiadaniu podmiotu finansowego, nie agencji, nie hostera.
- Przenośność licencji wtyczek i motywów. Licencje na nazwę podmiotu, przenoszalne do nowego hostera.
- Przetestowane przejście. Środowisko staging u alternatywnego hostera, które można wynieść do produkcji w udokumentowanym czasie. Test jest zaprotokołowany i datowany.
- Umowne okno przejściowe. Art. 30 ust. 3 lit. f) wymaga obowiązkowego okresu przejściowego, w którym dostawca nadal świadczy usługę, gdy podmiot migruje. Umowa hostingowa ustala jego długość i cenę.
- Zwrot danych. Art. 30 ust. 2 lit. d) wymaga, by podmiot mógł uzyskać dostęp do swoich danych, odzyskać je i otrzymać w łatwo dostępnym formacie, gdy dostawca stanie się niewypłacalny, zakończy działalność albo umowa wygaśnie.
Wycena mandatów obejmujących pakiet strategii wyjścia jest indywidualna; sam dokument wyjścia bierze dni, nie godziny, i jest wynikiem mandatu.
Jak DORA zmienia zakup usług agencji WordPress
Agencja WordPress, która przychodzi z wypełnioną macierzą klauzul artykułu 30, gotowym wzorcem rejestru dostawców i sprawdzoną strategią wyjścia, przechodzi przez zakupy szybciej. Podmiot finansowy nie musi tłumaczyć artykułu 28 na umowę; włącza przygotowane materiały agencji do własnego ramowego systemu zarządzania ryzykiem ICT.
To również powód, dla którego klient regulowany filtruje shortlistę dostawców według jurysdykcji. Agencja z UE pod prawem unijnym usuwa warstwę tarcia; agencja spoza UE każe podmiotowi rozważyć dodatkowo to, czego art. 29 ust. 2 wymaga przy państwie trzecim: właściwe prawo upadłościowe, pilne odzyskanie danych i zgodność z unijnymi przepisami o ochronie danych.
Jak sklasyfikować funkcję krytyczną lub istotną w DORA
Art. 3 pkt 22 DORA definiuje krytyczną lub istotną funkcję jako funkcję, której zakłócenie w istotny sposób wpłynęłoby na wyniki finansowe podmiotu albo na bezpieczeństwo lub ciągłość jego usług i działalności, albo której wadliwe działanie w istotny sposób wpłynęłoby na wypełnianie warunków zezwolenia lub innych obowiązków z przepisów o usługach finansowych. O krytyczności nie rozstrzyga marka ani wartość umowy. Punktem wyjścia jest funkcja wspierana przez usługę oraz skutek jej niedostępności, pogorszenia albo naruszenia. Strona informacyjna banku może być ważna komunikacyjnie, lecz nie wspierać bezpośrednio krytycznej usługi finansowej. Niedroga wtyczka obsługująca uwierzytelnianie lub status płatności może mieć znacznie większy wpływ operacyjny niż sugeruje koszt licencji.
Karta klasyfikacji powinna wskazywać usługę biznesową, właściciela procesu, dotkniętych klientów, dane, cele odtworzenia, możliwe obejścia ręczne i zależności od kolejnych dostawców. Zapisuje też osobę zatwierdzającą kwalifikację funkcji krytycznej lub istotnej oraz datę ponownego przeglądu. Ta decyzja wyznacza głębokość due diligence i dodatkowe warunki z artykułu 30. Nie jest etykietą, którą dostawca może nadać sobie sam. Art. 3 ust. 2 rozporządzenia delegowanego 2024/1773 wymaga, by polityka podmiotu ustalała metodę określania, które usługi ICT wspierają krytyczne lub istotne funkcje, i moment ponownej oceny.
Lista dowodów do due diligence dostawcy ICT
Dział zakupów powinien otrzymać dowody odnoszące się do konkretnej usługi, a nie ogólny folder bezpieczeństwa. Dla hostingu, CDN, WAF lub obsługi WordPress pakiet zwykle obejmuje:
- podmiot prawny, grupę właścicielską, miejsca świadczenia usługi i podwykonawców;
- granice architektury i przepływów danych, w tym dostęp administracyjny oraz ścieżki wsparcia;
- dowody MFA, przeglądów uprawnień uprzywilejowanych i odbierania dostępu;
- procesy podatności, poprawek i zmian wraz z aktualnymi przykładami działania;
- ścieżkę powiadomienia o incydencie, kontakty eskalacyjne i zabezpieczanie dowodów;
- wyniki testów odtworzenia i ciągłości właściwe dla zamawianej usługi;
- niezależne raporty, ich zakres, wyłączenia i stan działań naprawczych;
- proponowane SLA, cele odtworzenia, wsparcie audytu i pomoc przy zakończeniu umowy.
Certyfikat wspiera ocenę, ale nie dowodzi automatycznie, że obejmuje panel zarządzania WordPressem, zespół wsparcia i cel backupu. W rejestrze dowodów zapisz datę, okres objęty badaniem, osobę oceniającą i pytania otwarte. Jeżeli materiał jest poufny, można uzgodnić kontrolowany wgląd, raport niezależny albo konkretną klauzulę. Braku nie należy oznaczać jako spełnionego tylko dlatego, że dostawca odmówił przekazania dokumentu.
Podwykonawstwo w DORA u dostawców WordPress
Bezpośredni kontrahent rzadko obsługuje cały stos. Agencja managed WordPress może używać chmury, CDN, systemu zgłoszeń, monitoringu i zewnętrznego wsparcia. Umowa oraz rejestr muszą odróżniać stronę umowy od podmiotów, które faktycznie przechowują dane, administrują systemem lub wspierają funkcję krytyczną albo istotną.
Trzeba określić, które zmiany w podwykonawstwie wymagają powiadomienia, co zawiera komunikat, jak działa sprzeciw lub wypowiedzenie i co stanie się z istniejącymi danymi. Ocena obejmuje też koncentrację na czwartym poziomie. Dwóch pozornie niezależnych dostawców może zależeć od tego samego hyperscalera, operatora DNS albo dostawcy tożsamości. Lista zebrana przy podpisaniu i nigdy nieaktualizowana nie jest skuteczną kontrolą.
Rozporządzenie delegowane (UE) 2025/532, które rozwija art. 30 ust. 2 lit. a), określa te warunki. Według jego art. 3 podmiot przed podpisaniem decyduje, czy dostawca może podzlecić usługę wspierającą krytyczną lub istotną funkcję, i podpisuje tylko wtedy, gdy dostawca potrafi ocenić swoich podwykonawców i wskazać ich wszystkich. Art. 4 wymaga, by umowa określała, które usługi wolno podzlecić, oraz by dostawca pozostał odpowiedzialny za usługi podwykonawców i je monitorował. Art. 5 reguluje istotne zmiany: dostawca zapowiada je odpowiednio wcześnie, umowa daje rozsądny termin na akceptację albo sprzeciw, a zmiana wchodzi dopiero po akceptacji lub po upływie terminu bez sprzeciwu.
Jak przetestować wyjście od dostawcy ICT
Dwa logotypy na diagramie nie gwarantują dywersyfikacji. Jeśli zapasowy hosting korzysta z tego samego regionu chmury, konto backupu z tego samego systemu tożsamości, a DNS pozostaje pod kontrolą odchodzącego dostawcy, alternatywa może zawieść razem z usługą podstawową. Mapuj wspólną własność, infrastrukturę, geografię, poświadczenia administracyjne i wiedzę specjalistyczną.
Test wyjścia powinien potwierdzić, że uprawniony zespół potrafi pobrać aktualne dane i konfigurację, sprawdzić integralność, odtworzyć usługę, przełączyć ruch, zachować wymagane zapisy i odebrać stary dostęp. Zmierz czas i porównaj go z zaakceptowaną tolerancją biznesową. Zapisz kroki ręczne, ograniczenia licencyjne, problemy formatów oraz funkcje, których nie udało się odtworzyć. Wynikiem może być zaakceptowane ryzyko rezydualne, plan poprawy albo zmiana źródła usługi. Artykuł 28 nie nakazuje automatycznie dublowania każdej zależności bez względu na koszt.
Okresowy przegląd dostawcy ICT i kryteria odbioru
Częstotliwość ponownej oceny zależy od krytyczności i zmian. Art. 28 ust. 6 wymaga z góry ustalonej częstotliwości i obszarów audytów, a art. 3 ust. 1 rozporządzenia delegowanego (UE) 2024/1773 zobowiązuje organ zarządzający do przeglądu polityki korzystania z usług ICT wspierających krytyczne lub istotne funkcje co najmniej raz w roku. Nowy przegląd dostawcy powinien poza tym uruchomić istotny incydent, przejęcie, nowa lokalizacja przetwarzania, ważna zmiana podwykonawcy, przebudowa usługi albo powtarzające się naruszenie SLA. Właściciel usługi, zakupy, bezpieczeństwo, dział prawny i ochrona danych potrzebują przypisanych ról. Wysłanie corocznej ankiety bez oceny odpowiedzi nie stanowi skutecznego nadzoru.
Przed akceptacją powinny istnieć: właściciel kontroli, kompletny rejestr dowodów, rozwiązane luki umowne lub formalnie zaakceptowane wyjątki, wpis w rejestrze, wykonalny plan wyjścia i termin kolejnego przeglądu. Odbiór rozdziela fakty potwierdzone, deklaracje dostawcy, elementy poza zakresem oraz ryzyko rezydualne. Audyt dostawcy ogranicza niepewność, lecz nie certyfikuje zgodności podmiotu finansowego z DORA i nie gwarantuje ciągłości usługi.
Aby ustalić zakres do wyceny, wyślij pisemny brief z funkcją finansową, dostawcą i usługą, architekturą, klasami danych, znanymi podwykonawcami, celami odtworzenia, stanem umowy i terminem zakupowym. Audyt gotowości NIS2 i DORA może wtedy uporządkować rejestr dostawców, luki dowodowe, checklistę umowy, analizę koncentracji i plan ponownego testu dla powierzchni WordPress.
