Zegar art. 23 biegnie w trzech etapach. Co agencja WordPress musi dostarczyć po 24 godzinach, 72 godzinach i miesiącu od wykrycia.
PL

NIS2 zgłoszenie incydentu WordPress: 24 godziny, 72 godziny, miesiąc

4.70 /5 - (6 głosów )
Ostatnio zweryfikowano: 1 maja 2026
5min czytania
Dokumentacja
500+ projektów WP

#NIS2 zgłoszenie incydentu WordPress: 24 godziny, 72 godziny, miesiąc

Artykuł 23 dyrektywy 2022/2555 decyduje, jak w praktyce wygląda reakcja na incydent. Artykuł 21 obejmuje zarządzanie ryzykiem w trybie ciągłym; artykuł 23 obejmuje to, co dzieje się, gdy coś się psuje. Trzy kamienie milowe, trzy dostawy, jeden zegar startujący przy wykryciu.

To artykuł wspierający wewnątrz filaru NIS2 i DORA na WordPressie, z odsyłaczami do przewodnika po ścieżce dowodowej Załącznika II i rejestru ICT third-party z DORA artykuł 28.

#Streszczenie

  • Zegar biegnie od wykrycia istotnego incydentu, a nie od potwierdzenia przyczyny.
  • 24 godziny: wczesne ostrzeżenie, przypuszczalna złośliwa przyczyna, wskaźnik transgraniczny.
  • 72 godziny: pełne zgłoszenie z oceną wstępną i wskaźnikami.
  • Miesiąc: raport końcowy z typem zagrożenia, środkami zaradczymi i wpływem transgranicznym.
  • Raport końcowy składamy także, gdy przyczyna okazuje się nieszkodliwa.

#Co znaczy “wykrycie”

Artykuł 23 milczy o definicji wykrycia, ale wytyczne ENISA i motyw 101 czytają go jako moment, w którym podmiot zdaje sobie sprawę, że incydent może być istotny. Praktycznie: moment, w którym alert dociera do właściciela runbooka, a nie moment, w którym narzędzie alert wyzwala.

Dla strony WordPress oznacza to zwykle:

  • Narzędzie monitoringu (Wordfence, Sucuri, IDS hostingowy, alert Cloudflare, skok błędów w Sentry) flaguje anomalię.
  • Inżynier on-call triażuje alert i ocenia zakres.
  • Jeśli ocena przekracza próg istotności z artykułu 23(3), wykrycie nastąpiło. Zegar startuje.

Błąd do uniknięcia: junior triażujący wybuch credential stuffingu o 23:50, kwitujący “wygląda jak normalny szum”, oddający temat na rano. Jeśli ten wybuch był faktycznie wyciekiem credentiali z potwierdzonym dostępem do konta, zegar 24-godzinny tyka od 23:50 - regulator odtworzy to z logów.

#Wczesne ostrzeżenie po 24 godzinach

Treść wymagana przez artykuł 23(4)(a):

  • Czy incydent jest podejrzewany o spowodowanie czynem bezprawnym albo złośliwym.
  • Czy incydent może mieć wpływ transgraniczny.

To krótko. Wczesne ostrzeżenie to nie analiza przyczyny, tylko flaga. CSIRT albo właściwy organ musi wiedzieć, że dzieje się coś istotnego; szczegóły idą w 72-godzinnym zgłoszeniu.

Rola agencji WordPress wewnątrz 24 godzin:

  • Potwierdzić zakres incydentu na podstawie logów, alertów i forensyki panelu admin.
  • Dostarczyć compliance teamowi klienta jednostronicowy szkic wczesnego ostrzeżenia z nazwą dotkniętego serwisu, podejrzewaną kategorią (złośliwe albo operacyjne) i elementem transgranicznym (wielojęzyczna strona, klientela ogólnoeuropejska).
  • Zabezpieczyć dowody: logi serwera, oś czasu update’ów pluginów, historię logowań admina, audit trail hostingu. Snapshot bazy danych, jeśli wykonalny.
  • Zatrzymać krwawienie: rotacja credentiali, blokada IP, izolacja podejrzanych pluginów, tryb tylko-do-odczytu, gdy incydent dotyka checkoutu albo płatności.

Wczesne ostrzeżenie nie powinno zawierać spekulacji o atrybucji. “Podejrzewane złośliwe” wystarczy; nazywanie aktora to robota specjalistów forensycznych.

#Pełne zgłoszenie po 72 godzinach

Treść wymagana przez artykuł 23(4)(b):

  • Wstępna ocena incydentu wraz z dotkliwością i skutkami.
  • Tam gdzie dostępne, wskaźniki kompromitacji.

Język dotkliwości ma znaczenie. ENISA pracuje w trzech poziomach: niski, średni, wysoki. Incydent WordPressa, który zostawił stronę offline poniżej godziny bez wycieku danych, jest co najwyżej średni. Potwierdzony wyciek credentiali z dostępem do kont klientów to wysoki. Defacement strony marketingowej bez dalszego dostępu to niski lub średni.

Dostawa agencji wewnątrz 72 godzin:

  • Pisemna oś czasu incydentu z timestampami z logów.
  • Ocena, czy dane klientów, dane płatnicze albo dane sesji zostały dotknięte.
  • Wskaźniki kompromitacji: źródłowe IP, user-agenty, hashe plików w przypadku malware, zmodyfikowane pliki pluginów albo motywu, podejrzane konta admin utworzone w trakcie incydentu.
  • Pierwsza lista podjętych mitigation: zrotowane credentiale, usunięty albo zaktualizowany plugin, dodana reguła WAF, audyt kont admin.

Tu większość incydentów WordPress dostaje swoją nazwę w aktach regulatora. Zgłoszenie 72-godzinne porównuje się później z raportem końcowym.

#Raport końcowy po miesiącu

Treść wymagana przez artykuł 23(4)(c):

  • Szczegółowy opis incydentu, dotkliwość i skutki.
  • Typ zagrożenia albo przyczyna źródłowa.
  • Zastosowane i bieżące środki zaradcze.
  • Tam gdzie dotyczy, wpływ transgraniczny.

Do końca miesiąca agencja WordPress powinna mieć:

  • Pełną analizę przyczyny źródłowej. Podatny plugin? Wyciek credentiali? Zła konfiguracja serwera? Kompromis admina przez phishing?
  • Dowód, że doraźna naprawa działa i jest stabilna. Reguła WAF wdrożona, plugin zaktualizowany na produkcji, credentiale zrotowane, MFA wymuszone, monitoring dostrojony.
  • Listę długoterminowych działań. Aktualizacja polityki pluginów, usunięcie nieutrzymywanych zależności, okresowy audyt credentiali, szkolenie redaktorów potencjalnie wektorów phishingu.
  • Akapit potwierdzający dla klienta do przekazania regulatorowi.

Jeśli przyczyna okazała się nieszkodliwa (zepsuty update pluginu zdiagnozowany jako wyciek), raport końcowy i tak idzie. Artykuł 23(7) wprost reguluje to wariantem “bez działania”. Zegar nie zatrzymuje się tylko dlatego, że ocena się zmieniła.

#Co agencja trzyma w toolboxie

Sześć artefaktów, które każda regulowana umowa WordPress powinna mieć przed pierwszym incydentem:

  1. Runbook reakcji na incydent z nazwanym ownerem, ścieżką eskalacji i szablonami 24/72/30 dni.
  2. Lista kontaktów CSIRT i organów dla jurysdykcji klienta i istotnych transgranicznych.
  3. Szablon komunikacji dla dotkniętych klientów przy potwierdzonym dostępie do danych.
  4. Polityka zabezpieczania dowodów: retencja logów, integralność backupów, notatki chain-of-custody.
  5. Biblioteka języka zgłoszeń: zatwierdzone wstępnie sformułowania dla “podejrzewane złośliwe”, “brak ekspozycji danych klientów”, “podatność załatana”, “monitoring dostrojony”. Oszczędza 30 minut wewnątrz okna 24-godzinnego.
  6. Harmonogram drillów: minimum jeden tabletop kwartalnie z przebiegiem 24/72/30 bez prawdziwego incydentu.

Toolbox to różnica między oknem 24-godzinnym, które produkuje spokojne jednostronicowe wczesne ostrzeżenie, a oknem 24-godzinnym, które produkuje paniczny telefon do działu prawnego o 03:00.

#Odsyłacze

Następny krok

Przekuj artykuł w realne wdrożenie

Pod tym wpisem dokładam linki, które domykają intencję użytkownika i prowadzą dalej w strukturze serwisu.

Powiązany klaster

Sprawdź inne usługi WordPress i bazę wiedzy

Wzmocnij swój biznes dzięki profesjonalnemu wsparciu technicznemu w kluczowych obszarach ekosystemu WordPress.

FAQ do artykułu

Często zadawane pytania

Najważniejsze odpowiedzi, które pomagają wdrożyć temat w praktyce.

SEO-ready GEO-ready AEO-ready 4 Q&A
Co dokładnie wymaga artykuł 23?
Trzy zgłoszenia do CSIRT lub właściwego organu. Wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, pełne zgłoszenie w ciągu 72 godzin, raport końcowy w ciągu miesiąca. Zegar startuje przy wykryciu, a nie przy potwierdzeniu przyczyny.
Czy agencja WordPress zgłasza bezpośrednio?
Nie. Klient regulowany zgłasza. Agencja dostarcza dowody techniczne. W praktyce agencja przygotowuje pierwszą wersję wczesnego ostrzeżenia w ramach zobowiązania umownego; klient sprawdza i składa.
Co liczy się jako incydent istotny?
Artykuł 23(3) definiuje istotność jako poważne zakłócenie operacyjne, stratę finansową albo znaczące szkody u innych osób. Awaria WordPressa wpływająca na obsługę klientów regulowanego podmiotu zwykle kwalifikuje się; zablokowany login redaktora zwykle nie.
Co przy spóźnieniu o 24 godziny?
Klient spóźnia się, nie agencja, ale umowa przekazująca obowiązki NIS2 zwykle karze opóźnioną reakcję agencji. Regulator karze najpierw klienta; agencja odpowiada przed klientem za naruszenie umowy.

Potrzebujesz FAQ dopasowanego do branży i rynku? Przygotujemy wersję pod Twoje cele biznesowe.

Porozmawiajmy

Polecane artykuły

Artykuł 23 NIS2 daje 24 godziny od powzięcia wiedzy na złożenie wczesnego ostrzeżenia w CSIRT. Ten playbook wymienia sygnały specyficzne dla WordPress, które uruchamiają zegar, oraz szablon, który składam, gdy zegar startuje.
wordpress

WordPress – reakcja na incydent pod NIS2: 24-godzinny playbook wczesnego ostrzeżenia

Artykuł 23 NIS2 daje 24 godziny od powzięcia wiedzy na złożenie wczesnego ostrzeżenia w CSIRT. Ten playbook wymienia sygnały specyficzne dla WordPress, które uruchamiają zegar, oraz szablon, który składam, gdy zegar startuje.

NIS2 (dyrektywa 2022/2555) i DORA (rozporządzenie 2022/2554) pokrywają podobny obszar, ale różną mechaniką. Gdzie się pokrywają, gdzie się rozchodzą i jak agencja WordPress spełnia oba jedną ścieżką dowodową.
wordpress

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

NIS2 (dyrektywa 2022/2555) i DORA (rozporządzenie 2022/2554) pokrywają podobny obszar, ale różną mechaniką. Gdzie się pokrywają, gdzie się rozchodzą i jak agencja WordPress spełnia oba jedną ścieżką dowodową.

Artykuł 21 Dyrektywy 2022/2555 wymienia dziesięć środków zarządzania ryzykiem, które każdy podmiot w zakresie musi wdrożyć. Mapuję każdy z nich na konkretną kontrolę w agencji WordPress, wraz z plikiem dowodowym wymaganym podczas audytu.
wordpress

NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa

Artykuł 21 Dyrektywy 2022/2555 wymienia dziesięć środków zarządzania ryzykiem, które każdy podmiot w zakresie musi wdrożyć. Mapuję każdy z nich na konkretną kontrolę w agencji WordPress, wraz z plikiem dowodowym wymaganym podczas audytu.