DORA Rejestr Informacji dla dostawców WordPress: pola obowiązkowe
Artykuł 28(3) rozporządzenia 2022/2554 zobowiązuje każdy podmiot finansowy do prowadzenia i aktualizacji Rejestru Informacji o umowach z dostawcami usług ICT third-party. Rozporządzenie wykonawcze (UE) 2024/2956 ustala strukturę pól: piętnaście tabel z nazwanymi kolumnami. Agencja WordPress dostarczająca usługi bankowi, ubezpieczycielowi, firmie inwestycyjnej albo instytucji płatniczej trafia do tego rejestru i musi dostarczać dane na czas, w odpowiednim kształcie.
To artykuł wspierający wewnątrz filaru NIS2 i DORA na WordPressie, z odsyłaczem do wyjaśnienia DORA artykuł 28 ryzyko stron trzecich.
Streszczenie
- Piętnaście tabel ustawionych przez rozporządzenie wykonawcze 2024/2956.
- Umowy o funkcjach krytycznych albo istotnych mają dodatkowe kolumny (zastępowalność, ryzyko koncentracji, plan wyjścia).
- Łańcuchy sub-procesorów przejrzyste do poziomu istotnego dla podmiotu finansowego.
- Agencja nie składa Rejestru; agencja go karmi.
- Większość agencji pomija cztery z piętnastu tabel przy pierwszym zgłoszeniu.
Co składa podmiot finansowy
Zgodnie z artykułem 28(3) każdy podmiot finansowy musi raportować Rejestr co najmniej raz w roku do swojego organu nadzoru i europejskiego organu nadzoru poprzez wspólne ramy raportowania. Rozporządzenie wykonawcze 2024 definiuje schemat. Piętnaście tabel:
- Informacje o podmiocie.
- Informacje o oddziale.
- Informacje o jednostce zależnej.
- Usługi ICT.
- Identyfikacja funkcji.
- Umowy.
- Funkcje umowy.
- Usługi ICT umowy.
- Ryzyko umowy.
- Podwykonawstwo (sub-procesorzy).
- Postanowienia dotyczące rozwiązania.
- Lokalizacje.
- Osoby lub organy odpowiedzialne.
- Umowy dotyczące funkcji krytycznych lub istotnych.
- Umowy z koncentracją (third-party w ramach grupy).
Z tych piętnastu agencja WordPress zwykle pojawia się w tabelach 4, 6, 8, 9, 10, 11, 12, 14. Tabele 1-3, 5, 7, 13 należą do podmiotu finansowego. Tabela 15 pojawia się rzadko i tylko, gdy agencja ma podmiot dominujący albo jest częstym dostawcą w grupie podmiotu.
Co agencja WordPress musi dostarczyć
Per usługa ICT (tabela 4) i per umowa (tabela 6) agencja dostarcza kolumny, które podmiot finansowy przepisuje do Rejestru. Praktyczna lista nieprzykładna:
- Opis usługi: hosting WordPress, rozwój pluginu, headless front, support, audyty bezpieczeństwa - per pozycja, a nie jeden wspólny worek.
- Nazwa dostawcy i LEI: Legal Entity Identifier agencji. Mała agencja WordPress bez LEI musi go uzyskać przed podpisaniem umowy.
- Kraj rejestracji i siedziba.
- Przynależność grupowa: spółka dominująca, zależne, siostrzane.
- Świadczone usługi: które produkty są dotykane, z flagą krytyczności.
- Przetwarzane dane: dane klientów, dane transakcyjne, dane pracowników, brak.
- Lokalizacje danych: kraj i dostawca data center per warstwa przechowywania (produkcja, backup, archiwum logów).
- Sub-procesorzy: każdy dostawca, którego agencja używa do świadczenia usługi (Cloudflare, Sentry, platforma deploymentu, monitoring, API AI).
- Jurysdykcje sub-procesorów: kraj i prawo właściwe per sub-procesor.
Tabela 11 (postanowienia dotyczące rozwiązania) wymaga od agencji ujawnienia:
- Okresu wypowiedzenia dla podmiotu finansowego.
- Okresu wypowiedzenia dla agencji.
- Wyzwalaczy wcześniejszego rozwiązania przez podmiot finansowy.
- Planu wyjścia: jak podmiot finansowy odzyskuje dane i operacje.
Tabela 14 (umowy dotyczące funkcji krytycznych lub istotnych) wymaga dodatkowych dowodów, jeśli usługa WordPress wspiera funkcję krytyczną lub istotną. Ocena zastępowalności, ryzyko koncentracji, plan wyjścia z realistycznymi terminami, regularny harmonogram testów.
Co większość agencji WordPress pomija
Pięć powtarzających się luk z reviewów dostawców 2025-2026:
Brak LEI. Agencja WordPress bez Legal Entity Identifier opóźnia umowę i Rejestr. LEI kosztuje mniej więcej tyle co odnowienie domeny rocznie. Nie ma wytłumaczenia dla braku LEI przy obsłudze regulowanego sektora finansowego.
Niekompletna lista sub-procesorów. Cloudflare jest, Sentry jest; dostawca AI dla narzędzi redakcyjnych, vendor email-relay, platforma deploymentu i target backupu off-site są zapomniani. Rejestr nie przechodzi review i agencja wraca przez zakup ponownie.
Plan wyjścia w jednym akapicie. “Przekażemy dane na żądanie” to nie plan wyjścia. Podmiot finansowy potrzebuje szacowanych dni handoveru, formatu dostawy danych, przekazania repozytorium kodu, przekazania runbooka, listy zależności i procedury zamknięcia kont. Minimum trzy strony, najlepiej dokument wersjonowany.
Brak dowodu testu backupu. Artykuł 11 DORA wymaga regularnych testów odporności operacyjnej, w tym restore. Agencja bez kwartalnego logu restore zawodzi review przy pierwszym audicie.
Brak oceny funkcji krytycznej. Agencja twierdzi “nie jesteśmy krytyczni”, bo strona WordPress to “tylko marketing”. Zespół compliance podmiotu finansowego nie zgadza się, bo awaria marki szkodzi zaufaniu klientów. Ustalcie to wcześnie w umowie, nie podczas audytu.
Jak przygotować się do pierwszego wpisu
Praktyczna checklista dla agencji WordPress wchodzącej do pierwszego Rejestru:
- Uzyskać LEI, jeśli brak.
- Zinwentaryzować sub-procesorów, z krajem i prawem właściwym per dostawca.
- Napisać wersjonowany plan wyjścia: dane, kod, runbook, konta.
- Udokumentować lokalizacje danych per warstwa przechowywania i per sub-procesor.
- Przetestować pełny restore z backupu off-site; zalogować timestamp, czas trwania i wynik.
- Zmapować świadczone usługi na funkcje podmiotu finansowego; oflagować krytyczne lub istotne.
- Sporządzić oświadczenie o zastępowalności: którzy konkurenci zastąpią waszą usługę, w ilu tygodniach.
- Wprowadzić rytm kwartalnego review: co kwartał odświeżenie danych, podpis, archiwizacja.
Wykonane przed pierwszą umową, takie przygotowanie zwraca się wielokrotnie. Wykonane podczas pierwszego audytu, podwaja koszt zaangażowania.
