NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026

#NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026

Dyrektywa 2022/2555 (NIS2) i rozporządzenie 2022/2554 (DORA) pokrywają podobny obszar, ale różną mechaniką. NIS2 to dyrektywa transponowana przez każde państwo członkowskie do prawa krajowego. DORA to rozporządzenie stosowane bezpośrednio. NIS2 obejmuje szeroki zestaw sektorów kluczowych i istotnych. DORA jest specyficzna dla finansów. Tam gdzie się pokrywają (większość zarządzania ryzykiem, obsługi incydentów, łańcucha dostaw), jedna dobrze zbudowana ścieżka dowodowa może obsłużyć oba reżimy. Tam gdzie DORA idzie dalej (Rejestr Informacji, TLPT), agencja WordPress musi dodać delty.

To artykuł wspierający wewnątrz filaru NIS2 i DORA na WordPressie, z odsyłaczami do ścieżki dowodowej Załącznika II, przewodnika po DORA art. 28, pól Rejestru Informacji i osi czasu zgłoszenia 24/72/30.

#Streszczenie

• DORA jest lex specialis dla podmiotów finansowych; NIS2 stosuje się gdzie indziej.
• Pokrywanie: zarządzanie ryzykiem, obsługa incydentów, ciągłość działania, łańcuch dostaw, raportowanie.
• Tylko DORA: schemat Rejestru Informacji, TLPT dla podmiotów krytycznych, preskryptywne klauzule dla stron trzecich.
• Tylko NIS2: szersza obecność sektorowa (energia, transport, zdrowie, administracja publiczna), warianty transpozycji krajowej.
• Reguła praktyczna: jeśli którykolwiek klient ma DORA, buduj ścieżkę dowodową w standardzie DORA i obniżaj dla NIS2.

#Jak NIS2 sama nazywa DORA

Artykuł 1(2) NIS2 mówi: tam gdzie sektorowe akty prawne Unii zobowiązują podmioty kluczowe lub istotne do zarządzania ryzykami cyberbezpieczeństwa albo do zgłaszania istotnych incydentów, stosuje się te przepisy sektorowe. DORA to jeden z takich aktów. Podmiot finansowy w zakresie DORA nie spełnia więc podwójnie: spełnia DORA, a odpowiednie przepisy NIS2 uznaje się za spełnione.

To, czego DORA wprost nie reguluje (np. części odpowiedzialności organu zarządzającego z NIS2, szkolenia, współpracę CSIRT sektorową), nadal pokrywa baza NIS2.

Dla agencji WordPress oznacza to: jeśli klient to bank, firma inwestycyjna, instytucja płatnicza, ubezpieczyciel, zarządzający aktywami, TPP zgodnie z PSD2 - DORA dominuje. Buduj na DORA. Jeśli klient to szpital, rejestr TLD, dystrybutor energii, operator pocztowy - NIS2 dominuje. Buduj na NIS2.

#Drzewo decyzyjne: NIS2, DORA, czy obie?

Reguła powyżej (“DORA dla finansów, NIS2 dla wszystkiego innego”) działa dla oczywistych przypadków. Zawodzi dla przypadków, które faktycznie zajmują popołudnie scopingu: fintech poniżej progu podmiotu istotnego, grupa szpitali ze spółką zależną płatniczą albo agencja, która nigdy nie podpisała niczego ze słowem “NIS2”, ale odkrywa klauzulę łańcucha dostaw zakopaną w załączniku. Poniższy schemat to przewodnik, który używamy na rozmowie wdrożeniowej z nowym klientem, przed jakimkolwiek przeglądem umowy.

flowchart TD
    A["Czy klient jest podmiotem finansowym w rozumieniu art. 2 DORA?"] -->|"Tak"| B["Czy to bank, firma inwestycyjna, instytucja płatnicza, ubezpieczyciel, zarządzający aktywami albo TPP z PSD2?"]
    A -->|"Nie"| C["Czy klient jest w sektorze Załącznika I lub II NIS2: energia, transport, zdrowie, woda, infrastruktura cyfrowa, administracja publiczna, usługi pocztowe, odpady albo produkcja?"]
    B -->|"Tak"| D["DORA priorytetowo: buduj Rejestr Informacji, gotowość TLPT, analizę ryzyka koncentracji"]
    B -->|"Nie - poniżej progu albo wyłączenie"| C
    C -->|"Tak"| E["NIS2 priorytetowo: buduj rejestr ryzyka z art. 21, ścieżkę dowodową Załącznika II, deltę transpozycji krajowej"]
    C -->|"Nie"| F["Czy agencja jest kontraktowana przez podmiot, który sam jest w zakresie, czyli jesteś dostawcą ICT strony trzeciej?"]
    F -->|"Tak - klient w zakresie DORA"| G["Wciągnięcie łańcucha dostaw na podstawie art. 28 DORA: klauzule umowne klienta przenoszą obowiązki na poziomie DORA"]
    F -->|"Tak - klient w zakresie NIS2"| H["Wciągnięcie łańcucha dostaw na podstawie art. 21(2)(d) NIS2: klauzule umowne klienta przenoszą obowiązki na poziomie NIS2"]
    F -->|"Nie"| I["Żaden reżim nie ma zastosowania wprost albo pośrednio: monitoruj rozwój klienta i reklasyfikację sektorową rocznie"]
    D --> J["Czy grupa ma niefinansowe spółki zależne, które również korzystają z agencji?"]
    E --> J
    J -->|"Tak"| K["Reżim mieszany w holdingu: trzymaj dowody na poziomie DORA jako sufit i mapuj spółki zależne indywidualnie"]
    J -->|"Nie"| L["Jedna ścieżka dowodowa jest wystarczająca"]

Dwa rozgałęzienia to miejsca, gdzie agencje najczęściej się mylą. Pierwsze, rozgałęzienie “Nie - poniżej progu albo wyłączenie” z B: klient może być podmiotem finansowym w rozumieniu art. 2 DORA i wciąż nie być bankiem albo ubezpieczycielem w potocznym sensie - dostawcy usług finansowania crowdfundingowego i niektóre instytucje płatnicze trafiają tutaj i nie przestają być podmiotami DORA tylko dlatego, że są małe. Drugie, rozgałęzienie F: agencja bez żadnego regulowanego klienta na papierze wciąż może zostać wciągnięta w obowiązki DORA, jeśli jeden z jej podwykonawców hostingowych albo utrzymaniowych siedzi pod łańcuchem dostaw podmiotu regulowanego, kilka poziomów niżej.

#Matryca zastosowania

Sześć archetypów klienta, na które agencja może się natknąć, zmapowanych na reżim główny, sposób, w jaki obowiązek dociera do agencji, i poziom ścieżki dowodowej, na którym powinna zakończyć się ta rozmowa scoping.

Wzorzec, który wywraca nowe rozmowy scoping: gdy tylko jedna relacja z klientem gdziekolwiek w portfolio agencji jest w zakresie DORA, operacyjnie taniej jest budować każdą ścieżkę dowodową na poziomie DORA i obniżać dla klientów tylko-NIS2, niż utrzymywać dwa równoległe systemy dokumentacji.

#Dwa zanonimizowane przypadki scopingu

Poniższe szczegóły są zestawione i pozbawione danych identyfikujących; w tej sekcji nie pojawia się żadna nazwa klienta.

Case A: regionalny bank spółdzielczy. Bank spółdzielczy z około 40 oddziałami w jednym regionie zlecił zewnętrznej agencji swoją witrynę korporacyjną i wewnętrzny intranet dla pracowników, oba na WordPressie. Bank jest podmiotem finansowym w rozumieniu art. 2 DORA bez żadnych zastrzeżeń - struktura “spółdzielcza” tego nie zmienia. Rozmowa scoping potwierdziła, że agencja musi figurować w Rejestrze Informacji banku jako dostawca usług ICT strony trzeciej, konkretnie w tabelach B.02.01 (umowy) i B.05.01 (obsługiwane funkcje), mimo że wielkość banku trzymała go poniżej progu dla zaawansowanych testów penetracyjnych threat-led. Agencja musiała jeszcze odpowiedzieć na pytanie o ryzyko koncentracji z art. 29 - “kto inny mógłby przejąć hosting i utrzymanie w ciągu ośmiu tygodni” - bo compliance officer banku potrzebował tej odpowiedzi na piśmie niezależnie od statusu TLPT. Powstała struktura folderów ścieżki dowodowej odzwierciedlała układ 05_dora_rejestr/ opisany później w tym artykule, wypełniany od pierwszego dnia współpracy, a nie uzupełniany dopiero przed audytem.

Case B: grupa szpitali miejskich. Grupa szpitali miejskich prowadząca współdzielony portal informacji dla pacjentów i intranet dla personelu, oba na WordPressie, zamówiła to samo podejście do ścieżki dowodowej, ale trafiła na przeciwną stronę drzewa. Szpitale są w Załączniku I NIS2 (sektor zdrowia), a grupa nie miała żadnego statusu podmiotu finansowego w swojej strukturze, więc DORA nigdy nie wchodziła w grę. Nie zbudowano żadnego schematu Rejestru Informacji - byłby to zmarnowany wysiłek, bo piętnastotabelowy format RoI to wymóg specyficzny dla DORA, bez odpowiednika w NIS2. Zamiast tego agencja zbudowała prostszy rejestr dostawców plus kwestionariusz due diligence i klauzulę SLA dotyczącą zgłaszania incydentów powiązaną z krajową transpozycją NIS2 szpitala (która ustaliła własne terminy raportowania i właściwy organ, odrębne od rytmu 24h/72h/1 miesiąc używanego gdzie indziej w tym filarze). Praktyczna lekcja z porównania obu przypadków: klient w zakresie DORA kosztował z grubsza dwa razy więcej początkowego wysiłku dokumentacyjnego niż klient w zakresie NIS2, prawie w całości z powodu schematu Rejestru Informacji, a ta różnica w koszcie jest najlepszym predyktorem tego, jaki poziom ścieżki dowodowej wycenić dla nowego zlecenia.

#Co się pokrywa

Pięć dużych obszarów pokrywania, w których jeden artefakt obsługuje oba reżimy:

Zarządzanie ryzykiem. NIS2 art. 21 wymienia dziesięć środków; DORA art. 5-15 pokrywa ten sam obszar koncepcyjny w większym detalu. Rejestr ryzyka nazywający aktywa, zagrożenia, prawdopodobieństwo, wpływ i traktowanie spełnia oba. Poziom detalu różni się: DORA oczekuje większej granularności dla funkcji krytycznych albo istotnych; NIS2 oczekuje proporcjonalności.

Obsługa incydentów. NIS2 art. 22-23 i DORA art. 17-23 wymagają oba klasyfikacji, reakcji, odzyskania, post-mortemu i raportowania. Terminy raportowania różnią się nieznacznie (NIS2: 24h wczesne ostrzeżenie, 72h zgłoszenie, raport końcowy 1 miesiąc; DORA: podobnie, z szablonami sektorowymi). Wewnętrzny runbook reakcji na incydent można współdzielić.

Ciągłość działania. NIS2 art. 21(2)(c) i DORA art. 11 wymagają oba backupu, testowanego restore, off-site, z udokumentowanymi RPO i RTO. Jeden plan BCDR z jednym rocznym logiem drilla restore spełnia oba.

Kontrole łańcucha dostaw. NIS2 art. 21(2)(d) i DORA art. 28 wymagają oba rejestru dostawców, due diligence, klauzul umownych, planu wyjścia. Rejestr Informacji DORA ma surowszy schemat; budowa do DORA daje compliance NIS2 łańcucha dostaw za darmo.

Raportowanie. Oba wymagają raportowania do właściwego organu. NIS2 wskazuje krajowy CSIRT i właściwy organ; DORA raportuje do regulatora finansowego (krajowy plus ESAs). Wewnętrzne przygotowanie dowodu jest takie samo; adresat się różni.

#Co DORA dodaje na wierzch

Trzy delty, w których DORA idzie dalej niż NIS2 i agencja WordPress musi dodać konkretne dowody:

Schemat Rejestru Informacji. Rozporządzenie wykonawcze 2024/2956 określa piętnaście tabel z nazwanymi kolumnami. Szczegółowo opisany w przewodniku po polach Rejestru Informacji. NIS2 nie ma odpowiednika; agencja pod obowiązkami tylko-NIS2 nie potrzebuje tego schematu.

Threat-led penetration testing. DORA art. 26 wymaga zaawansowanych TLPT dla podmiotów finansowych klasyfikowanych jako istotne. Agencja obsługująca infrastrukturę krytyczną dla takiego podmiotu może być w zakresie jako system testowany. NIS2 wspomina o obsłudze podatności szeroko, ale nie o TLPT.

Ryzyko koncentracji i zastępowalność. DORA art. 29 wymaga wyraźnej analizy koncentracji: ile funkcji krytycznych wspiera ta strona trzecia i jak łatwo ją zastąpić. Agencja musi umieć odpowiedzieć “kto inny zrobi tę pracę w osiem tygodni, jeśli znikniemy”. NIS2 nie ma porównywalnego preskryptywnego wymagania.

#Co NIS2 dodaje na wierzch

Dwie delty, w których NIS2 idzie dalej niż DORA w kontekstach niefinansowych:

Szerokość sektorowa. Szpitale, ISP, operatorzy telekomunikacyjni, usługi pocztowe, produkcja żywności, administracja publiczna, organizacje badawcze są w NIS2. Większość nie w DORA. Agencja działająca przez wielu klientów sektorowych trzyma jedną ścieżkę zgodną z NIS2 per sektor.

Warianty transpozycji krajowej. Ponieważ NIS2 jest dyrektywą, każde państwo członkowskie wdraża szczegóły z lokalnym smakiem. Niemiecka transpozycja (KRITIS-DachG / NIS2UmsuCG) różni się od polskiej (KSC) i norweskiej. Agencja działająca transgranicznie trzyma mały dokument delt per jurysdykcja.

#Jedna ścieżka dowodowa, oba reżimy

#Macierz decyzji dla mandatu WordPress

Punktem startowym są podmiot prawny, usługa regulowana i jurysdykcja. Dopiero potem system WordPress przypisuje się do wspieranej funkcji. Macierz zapisuje, czy prawdopodobnie działa NIS2, DORA, oba reżimy czy żaden, kto dokonał kwalifikacji i jakie prawo krajowe sprawdzono. Agencja dostarcza fakty techniczne; klient i jego doradcy odpowiadają za ocenę prawną.

Gdy oba akty dotykają tej samej usługi finansowej, nie należy budować dwóch niezależnych programów kontroli. DORA stanowi sektorowy punkt odniesienia tam, gdzie jego przepisy mają zastosowanie, a istotne delty NIS2 i prawa krajowego pozostają w mapowaniu. Nie oznacza to, że jeden akt zawsze wyłącza drugi.

Dowód można współdzielić tylko przy zgodnym zakresie, właścicielu, okresie i kryterium odbioru. Ten sam test restore może wspierać oba mapowania, ale Rejestr Informacji DORA i formularze regulatora pozostają osobne. Każda kontrola otrzymuje właściciela po stronie klienta i agencji, recenzenta, lokalizację dowodu oraz wyzwalacz aktualizacji. Rejestr luk rozdziela brak wdrożenia, brak dowodu i otwartą interpretację.

Odbiór następuje, gdy każda kontrola ma dowód albo opisaną lukę, wspólne artefakty są linkowane zamiast kopiowane, a ryzyko rezydualne ma właściciela. Zmiana architektury, dostawcy, usługi lub prawa uruchamia review. Macierz nie jest certyfikatem ani gwarancją braku incydentu.

#Scenariusz roboczy: grupa finansowa i portal publiczny

Grupa finansowa używa WordPress do publicznego portalu produktowego, formularzy i chronionej strefy partnera. Grupa działa w kontekście DORA, a inna spółka może równocześnie świadczyć usługę istotną dla NIS2. Nie oznacza to automatycznie, że każda podstrona jest systemem krytycznym. Macierz łączy trasę i integrację z procesem biznesowym, podmiotem prawnym oraz przepływem danych.

Klient odpowiada za kwalifikację reżimu, krytyczność i komunikację z organem. Agencja odpowiada za uzgodnione dowody aplikacyjne, zmianowe i operacyjne. Hosting, tożsamość i formularze mogą mieć innych właścicieli. Niejasne przejście zapisuje się jako lukę zarządczą, zamiast domyślnie przypisywać je agencji.

Wspólny raport patchowania może wspierać oba mapowania, jeśli dotyczy tej samej wersji produkcyjnej, okresu i zakresu testu. Test odtworzenia portalu publicznego nie musi jednak dowodzić odzyskania strefy partnera, gdy różnią się dostawca tożsamości, baza albo RTO. Odbiór sprawdza więc nie samą obecność pliku, ale zdolność dowodu do podparcia konkretnego twierdzenia.

#Rejestr luk według przyczyny, nie aktu prawnego

Jeden rejestr zapobiega podwójnym ticketom. Przyczyna otrzymuje kategorię: brak kontroli, kontrola nieskuteczna, brak dowodu, dowód nieaktualny, niejasna odpowiedzialność albo otwarta kwalifikacja. Następnie wskazuje się dotknięte mapowania NIS2 i DORA. Naprawa odbywa się raz, natomiast ocena dla każdego reżimu pozostaje rozdzielona i możliwa do prześledzenia.

Przy zamknięciu właściciel kontroli potwierdza wdrożenie oraz dowód, a właściciel compliance potwierdza wykorzystanie w swoim mapowaniu. Poprawka techniczna może być zakończona, podczas gdy pytanie prawne lub kontraktowe pozostaje świadomie otwarte. Dzięki temu zielony ticket inżynieryjny nie jest mylony z pełnym odbiorem regulacyjnym.

W pisemnym briefie należy podać podmioty, kraje, usługę, architekturę, dostawców, istniejące mapowanie i termin. Nasza usługa gotowości NIS2 i DORA może przygotować macierz pokrycia i plan luk dowodowych, bez zastępowania porady prawnej.

Praktyczny układ ścieżki dowodowej obejmujący oba:

• 00_governance/ - rejestr ryzyka, zatwierdzenie organu zarządzającego, rytm review.
• 01_zarzadzanie_ryzykiem/ - mapowanie art. 21 / art. 5, kontrolę, dowody.
• 02_reakcja_na_incydenty/ - runbook, tabletop drill, post-mortem, szablony 24/72/30.
• 03_ciaglosc_dzialania/ - polityka backupu, logi testów restore, plan BCDR.
• 04_lancuch_dostaw/ - rejestr dostawców, lista sub-procesorów, akta due diligence.
• 05_dora_rejestr/ - wejścia do Rejestru Informacji (15 tabel) dla klientów DORA.
• 06_raportowanie/ - poprzednie raporty, log adresatów, log terminów.
• 07_jurysdykcje/ - delty transpozycji NIS2 per państwo członkowskie.
• 08_tlpt/ - dla istotnych podmiotów DORA, raporty TLPT i mitigation.

Zbudowany raz, iterowany kwartalnie, kolejne review dostawców trwa godziny zamiast tygodni.

#Odsyłacze

• NIS2 Załącznik II dla agencji WordPress: ścieżka dowodowa
• DORA artykuł 28 ryzyko stron trzecich ICT dla WordPress
• DORA Rejestr Informacji dla dostawców WordPress: pola obowiązkowe
• NIS2 zgłoszenie incydentu 24h/72h/miesiąc
• Filar NIS2 i DORA na WordPressie
• Audyt zgodności UE dla WordPress