DORA Rejestr Informacji dla dostawców WordPress: pola obowiązkowe

#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:

1. Informacje o podmiocie.
2. Informacje o oddziale.
3. Informacje o jednostce zależnej.
4. Usługi ICT.
5. Identyfikacja funkcji.
6. Umowy.
7. Funkcje umowy.
8. Usługi ICT umowy.
9. Ryzyko umowy.
10. Podwykonawstwo (sub-procesorzy).
11. Postanowienia dotyczące rozwiązania.
12. Lokalizacje.
13. Osoby lub organy odpowiedzialne.
14. Umowy dotyczące funkcji krytycznych lub istotnych.
15. 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:

1. Uzyskać LEI, jeśli brak.
2. Zinwentaryzować sub-procesorów, z krajem i prawem właściwym per dostawca.
3. Napisać wersjonowany plan wyjścia: dane, kod, runbook, konta.
4. Udokumentować lokalizacje danych per warstwa przechowywania i per sub-procesor.
5. Przetestować pełny restore z backupu off-site; zalogować timestamp, czas trwania i wynik.
6. Zmapować świadczone usługi na funkcje podmiotu finansowego; oflagować krytyczne lub istotne.
7. Sporządzić oświadczenie o zastępowalności: którzy konkurenci zastąpią waszą usługę, w ilu tygodniach.
8. 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.

#Inwentarz pól ze stabilnymi identyfikatorami

Zasilenie rejestru powinno być kontrolowanym zbiorem danych, nie ankietą uzupełnianą z pamięci. Osobny rekord powstaje dla podmiotu prawnego, umowy, usługi ICT, wspieranej funkcji, lokalizacji i istotnej relacji podwykonawczej. Każdy obiekt otrzymuje stabilny identyfikator wewnętrzny. Nazwy i umowy się zmieniają; identyfikator łączy wersje bez zgadywania, czy dwa zapisy opisują tego samego dostawcę.

Dla każdego pola zapisz definicję, format, dopuszczalne wartości, obowiązkowość w używanym szablonie, system źródłowy, właściciela i dowód. “Nie dotyczy”, “nieznane” i pole puste to różne stany. Daty, kody krajów i nazwy prawne muszą odpowiadać wymaganemu formatowi. Nie wolno wymyślać LEI ani innego identyfikatora. Podmiot finansowy powinien potwierdzić typ identyfikatora i reguły walidacji wymagane w aktualnym szablonie oraz przez właściwy organ.

#Systemy źródłowe i pochodzenie danych

Dane pochodzą z kilku obszarów. Zakupy przechowują umowę i aneksy. Zespół prawny odpowiada za klauzule wypowiedzenia, audytu, podwykonawstwa i wyjścia. Finanse prowadzą kartotekę dostawcy. Bezpieczeństwo i architektura łączą usługi z systemami oraz funkcjami. Prywatność opisuje kategorie danych i miejsca przetwarzania. Agencja dostarcza swoją tożsamość prawną, zakres usługi, podwykonawców, miejsca operacyjne i materiały wyjściowe.

Każde pole eksportu potrzebuje informacji o pochodzeniu: dokumentu lub systemu, pola źródłowego, daty pobrania, reguły transformacji i recenzenta. Jeśli data startu pochodzi z aneksu zamiast umowy ramowej, zapis powinien to wyjaśniać. Jeżeli kilka abonamentów wtyczek tworzy jedną usługę, trzeba zachować akceptację grupowania. Dzięki temu korekty są powtarzalne, a wartość w arkuszu nie staje się faktem bez źródła.

Dowody źródłowe są chronione przy rekordzie: podpisana wersja umowy, deklaracja dostawcy, diagram architektury, zatwierdzona lista lokalizacji i powiadomienie o zmianie. Dostęp powinien być ograniczony, bo pakiet może ujawniać architekturę bezpieczeństwa, kontakty i warunki handlowe.

#Własność danych i rytm zmian

Podmiot finansowy pozostaje odpowiedzialny za swój rejestr. Właściciel rejestru kontroluje schemat i kalendarz. Właściciele umów weryfikują umowy oraz funkcje. Bezpieczeństwo sprawdza mapowanie usług i zależności. Zakupy pilnują odpowiedzi dostawców. Agencja WordPress wyznacza właściciela danych i zastępcę do pytań oraz zatwierdzania zasilenia.

Przegląd jest okresowy i wyzwalany zdarzeniami. Należą do nich nowa umowa lub aneks, uruchomienie albo wycofanie usługi, zmiana nazwy prawnej, nowy podwykonawca, zmiana regionu hostingu, przejęcie, rewizja planu wyjścia i nowa ocena funkcji krytycznej. Wiążący rytm wynika z DORA, standardów wykonawczych, procedur podmiotu i instrukcji organu. Kwartalne odświeżenie może być kontrolą wewnętrzną, ale nie jest tu przedstawiane jako uniwersalny termin ustawowy.

#Walidacja przed eksportem

Kontrole strukturalne sprawdzają pola wymagane, unikalność identyfikatorów, daty i kody, referencje oraz osierocone rekordy usług lub podwykonawców. Kontrole semantyczne porównują daty z podpisaną umową, kolejność początku i końca, lokalizacje z architekturą, podwykonawcę z konkretną usługą oraz relacje funkcji krytycznej z decyzją podmiotu finansowego.

Istotne zmiany przechodzą zasadę czworga oczu. Odrzucony rekord wraca z kodem błędu i wyjaśnieniem, zamiast być cicho poprawiany. Zachowuje się wynik, osobę, czas i wersję zbioru. Przed wysłaniem porównuje się liczbę rekordów i kluczowe sumy z ostatnim przyjętym eksportem, wyjaśniając dodania, usunięcia i zmienione identyfikatory.

#Eksport i pakiet dowodowy

Eksport powstaje z zamrożonej wersji, nie z arkusza nadal edytowanego. Otrzymuje wersję danych, czas utworzenia, wersję schematu i sumę kontrolną. Zachowuje się plik maszynowy, czytelny raport kontrolny, wyniki walidacji, akceptacje i indeks źródeł. Jeśli jest środowisko testowe, import należy przećwiczyć. Kodowanie, separatory i format dat mogą odrzucić merytorycznie poprawne dane.

Przekazanie agencji obejmuje podmiot, umowy, usługi, lokalizacje, podwykonawców, datę stanu, zmiany, znane braki i kontakt. Nie należy twierdzić, że taki wycinek zapewnia kompletność całego rejestru. Konsolidacja grupowa, klasyfikacja funkcji i zgłoszenie pozostają po stronie podmiotu finansowego.

#Praktyczny proces jakości odpowiedzi dostawcy

Zapytanie do dostawcy powinno wskazywać konkretną umowę i usługę. Zamiast swobodnej listy pytań warto przekazać wersjonowany szablon, definicje pól, przykłady, dozwolone kody i bezpieczny kanał zwrotny. Dostawca potwierdza datę stanu i oznacza dane zależne od odpowiedzi podwykonawcy. Pytania są prowadzone przy rekordzie, a nie w kilku niezależnych wątkach pocztowych.

Zmiana nie powinna usuwać historii. Zachowaj poprzednią wartość, nową wartość, datę obowiązywania, przyczynę, źródło i akceptację. Nowy region hostingu może mieć osobną datę zapowiedzi, zgody umownej i technicznego uruchomienia. Historia pozwala ustalić, jaki stan obowiązywał w dniu konkretnego raportu.

Potrzebna jest również reguła duplikatów. Jedna grupa może występować jako kontrahent, platforma i podwykonawca przez różne spółki. Podmioty prawne prowadzi się osobno i łączy relacją grupową. Nazwa handlowa, produkt i strona umowy nie są tym samym polem. Nazwa wtyczki nie wskazuje automatycznie dostawcy prawnego ani lokalizacji danych.

Przed akceptacją właściciel czyta rekord jako pełną zależność: która funkcja jest wspierana przez jaką umowę, usługę, spółkę i lokalizację oraz jak przebiega wyjście. Jeżeli nie da się tego wyjaśnić, formalnie wypełnione pola nadal wymagają pracy. Braki trafiają do listy jakości z właścicielem i terminem, a nie są zastępowane założeniami.

#Ograniczenia i pisemny brief

#Scenariusz QA: zmiana regionu hostingu

Załóżmy, że zarządzana instalacja WordPress jest przenoszona między europejskimi regionami tego samego prawnego dostawcy hostingu. Zmiana nie polega na nadpisaniu jednego pola kraju. Właściciel danych identyfikuje umowy, usługi, wspierane funkcje, lokalizacje produkcji, kopii i logów oraz relacje podwykonawcze. Właściciel umowy sprawdza wymóg zgody. Bezpieczeństwo potwierdza datę technicznego uruchomienia, a prywatność ocenia zmianę informacji o przetwarzaniu.

Pakiet zmiany zawiera poprzednią i nową wartość, datę zapowiedzi, zgodę, datę obowiązywania, źródła i identyfikatory rekordów. Walidacja sprawdza kod kraju, relację lokalizacji z usługą oraz osobne potraktowanie produkcji, backupu i archiwum. Jeżeli poprzedni region działa w trakcie migracji, oba miejsca mogą wymagać okresu ważności. Natychmiastowe nadpisanie usunęłoby informację o rzeczywistym stanie.

Recenzent porównuje deklarację dostawcy, dowód architektury i umowę. Rozbieżność staje się zadaniem jakości danych z właścicielem, a nie powodem do wybrania wygodniejszej wartości. Akceptacja wymaga zatwierdzonych źródeł, poprawnej walidacji schematu, spójnych relacji, wyjaśnionej różnicy względem poprzedniego eksportu i przekazania zmiany dalszym właścicielom.

#Dopytanie dostawcy i akceptacja

Obsługa odpowiedzi powinna mieć jawne stany: wysłano, otrzymano, weryfikacja, wymagane wyjaśnienie, zaakceptowano i wygasło. Zapytanie wskazuje rekord, pola, format, bezpieczny kanał i termin. Prośba o wyjaśnienie opisuje konkretną sprzeczność, na przykład kraj podwykonawcy niezgodny z załącznikiem lokalizacji. Ogólne “sprawdźcie wszystko ponownie” nie poprawia jakości.

Akceptacja odbywa się na poziomie pól. Tożsamość prawna może zostać zatwierdzona, gdy lokalizacja nadal jest otwarta. Właściciel rejestru określa, czy niepełny rekord może wejść do roboczego zbioru i co blokuje eksport. Danych umownych lub operacyjnych nie należy zgadywać na podstawie witryny marketingowej. Brak istotnego dowodu eskaluje się do właściciela umowy.

Przed końcową zgodą druga osoba sprawdza aktualność źródeł, daty obowiązywania, połączenie umowy, usługi i funkcji, pokrycie podwykonawców oraz oznaczenie niewiadomych. Zapis akceptacji zawiera wersję danych, recenzenta, wyjątki i następny wyzwalacz aktualizacji. Jest to wewnętrzny ślad kontrolny, a nie zatwierdzenie przez organ nadzoru.

#Scenariusz zmiany właściciela usługi

Po reorganizacji odpowiedzialność za witrynę może przejść z marketingu do zespołu kanałów cyfrowych bez zmiany dostawcy ani umowy. Rejestr nadal wymaga aktualizacji osoby lub jednostki odpowiedzialnej oraz kontroli, czy nie zmieniło się mapowanie funkcji. Poprzedni właściciel zatwierdza przekazanie otwartych wyjątków, nowy potwierdza kontakty, rytm przeglądu i uprawnienia do decyzji.

Weryfikacja obejmuje działający adres kontaktowy, zastępstwo, zgodność z katalogiem organizacyjnym i przekazanie dostępu do dowodów. Samo wpisanie nowego nazwiska nie wystarcza, jeśli nikt nie przejął obowiązku aktualizacji. Scenariusz pokazuje, że jakość rejestru zależy także od zmian organizacyjnych, nie wyłącznie od zmian technicznych i kontraktowych.

Zaakceptowany rekord również się starzeje. Każde ważne źródło powinno mieć datę kolejnego sprawdzenia albo wyzwalacz zdarzeniowy. Umowa jest ponownie oceniana po aneksie lub przedłużeniu, lokalizacja po zmianie infrastruktury, podwykonawca po komunikacie dostawcy, a kontakt po reorganizacji. Brak zgłoszonej zmiany nie zastępuje planowego potwierdzenia. Odpowiedź “bez zmian” także warto zapisać z datą i osobą zatwierdzającą, zamiast po cichu pozostawić dawny rekord.

Jeżeli pola nie da się wyjaśnić przed eksportem, właściciel opisuje wpływ, eskalację i decyzję. Wartość nieznana nie może zostać zamieniona na “nie dotyczy” tylko po to, by przejść walidację. Powinno pozostać jasne, czy brak jest dopuszczalny, wymaga uzupełnienia, czy blokuje przyjęcie rekordu.

Ten materiał jest mapą zarządzania danymi, nie zastępuje rozporządzenia wykonawczego (UE) 2024/2956, aktualnych instrukcji nadzorczych ani porady prawnej. Wersje szablonów, taksonomie i walidacje mogą się zmieniać. Klasyfikacja zależy od kontekstu, a dostarczenie danych nie gwarantuje przyjęcia rejestru.

Jeśli potrzebujesz uporządkować zasilenie od dostawcy WordPress, wyślij pisemny brief przez usługę gotowości NIS2 i DORA. Podaj perspektywę, jurysdykcje, podmioty, umowy i usługi, format rejestru, systemy źródłowe, łańcuch podwykonawców, termin i znane błędy walidacji. W pierwszej wiadomości nie przesyłaj umów, danych dostępowych ani wrażliwej architektury. Pierwszym wynikiem powinna być mapa pól, model odpowiedzialności, lista jakości danych i plan dowodowy.

#Odsyłacze

• DORA artykuł 28 ryzyko stron trzecich ICT dla WordPress
• NIS2 Załącznik II dla agencji WordPress: ścieżka dowodowa
• NIS2 zgłoszenie incydentu 24h/72h/miesiąc
• Filar NIS2 i DORA na WordPressie
• NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026
• Audyt zgodności EU dla WordPress