Cyber Resilience Act + NIS2 + DORA: zgodność w 2026 roku dla headless WordPressa
W latach 2024-2026 trzy unijne akty zbiegły się w tej samej treści operacyjnej. Cyber Resilience Act (rozporządzenie (UE) 2024/2847) reguluje produkty z elementami cyfrowymi wprowadzane na rynek UE. Dyrektywa NIS2 (2022/2555) reguluje podmioty świadczące usługi kluczowe lub ważne. Rozporządzenie DORA (2022/2554) reguluje podmioty finansowe i zewnętrznych dostawców usług ICT, z których korzystają. Headless WordPress dostarczony regulowanemu klientowi z komercyjnym komponentem w zestawie trafia pod CRA po stronie produktu oraz pod NIS2 albo DORA po stronie podmiotu. Dla podmiotu finansowego DORA zastępuje przepisy NIS2 o zarządzaniu ryzykiem i zgłaszaniu incydentów, zamiast je uzupełniać. Dobra wiadomość: jeden pakiet dowodów może spełnić to wszystko, jeśli ułoży się go według kontroli, a nie według aktów.
Ten artykuł zamyka filar o NIS2 i DORA w WordPressie i spina ścieżkę dowodową z załącznika II, audyt dostawców z art. 28 DORA, 24-godzinny playbook incydentowy oraz tekst o dostępności BFSG i EAA.
Zestaw wymogów CRA, NIS2 i DORA w skrócie
- CRA reguluje produkty. NIS2 reguluje podmioty. DORA reguluje podmioty finansowe.
- Headless WordPress może trafić pod CRA przez swoje komercyjne komponenty, a pod NIS2 albo DORA przez klienta, który go eksploatuje.
- Dla podmiotów finansowych DORA stosuje się zamiast art. 21 i 23 NIS2 (art. 4 i motyw 28 NIS2).
- Jeden pakiet dowodów ułożony według kontroli wygrywa z trzema osobnymi stosami dokumentów.
- Obowiązki zgłoszeniowe CRA od 11 września 2026 roku, pełne stosowanie od 11 grudnia 2027 roku.
- NIS2 od terminu transpozycji 2024-10-17; DORA stosowana bezpośrednio od 2025-01-17.
Jak headless WordPress wpływa na zgodność z CRA, NIS2 i DORA
Headless WordPress rozdziela dwie warstwy. Warstwa treści to WordPress jako edytor i źródło prawdy, udostępniający treści przez REST API albo GraphQL. Warstwa prezentacji to framework frontendowy (Next.js, Astro, Nuxt, SvelteKit), który pobiera te treści i renderuje je dla użytkowników.
Z punktu widzenia zgodności taki podział zmienia powierzchnię ryzyka na trzy sposoby.
Frontend może być produktem. Aplikacja Next.js z komercyjnymi bibliotekami, wdrożona przez agencję, może być “produktem z elementami cyfrowymi” w rozumieniu CRA, gdy zostaje dostarczona w ramach działalności handlowej. Sam WordPress, jako darmowe oprogramowanie open source wydawane przez społeczność i niemonetyzowane przez twórców, nie wchodzi w zakres CRA (motywy 15 i 18 rozporządzenia (UE) 2024/2847); komercyjne pakiety zbudowane na nim mogą wejść.
Łańcuch dostaw jest szerszy. Projekty headless wciągają zależności npm (często setki), funkcje brzegowe CDN, usługi optymalizacji obrazów, dostawców wyszukiwania, systemy komentarzy. Art. 21 ust. 2 lit. d) NIS2 każe objętym podmiotom zabezpieczyć relacje z bezpośrednimi dostawcami, a art. 28 ust. 3 DORA wymaga od podmiotów finansowych rejestru informacji o wszystkich ustaleniach umownych dotyczących usług ICT. Oba przepisy prowadzą do inwentarza tego łańcucha z kontrolą umowną.
Powierzchnia incydentów jest podzielona. Podatność może siedzieć w backendzie WordPressa, w bundlu frontendu, w funkcji brzegowej albo w zewnętrznym API. 24-godzinny zegar NIS2 i terminy zgłoszeń z DORA dotyczą podmiotu niezależnie od tego, gdzie jest błąd. Runbook agencji musi wykrywać i klasyfikować zdarzenia we wszystkich czterech warstwach.
Czego wymagają CRA, NIS2 i DORA
CRA (rozporządzenie (UE) 2024/2847)
Obejmuje produkty z elementami cyfrowymi wprowadzane na rynek UE. Art. 13 określa obowiązki producenta: udokumentowaną ocenę ryzyka cyberbezpieczeństwa (art. 13 ust. 2 i 3), zasadnicze wymagania z części I załącznika I, takie jak bezpieczna konfiguracja domyślna, obsługę podatności przez okres wsparcia według części II załącznika I, aktualizacje bezpieczeństwa oraz wykaz komponentów oprogramowania (SBOM, część II pkt 1 załącznika I). Art. 14 dokłada obowiązki zgłoszeniowe: aktywnie wykorzystywane podatności i poważne incydenty trafiają jednocześnie do CSIRT wyznaczonego jako koordynator i do ENISA, przez jednolitą platformę sprawozdawczą z art. 16, z wczesnym ostrzeżeniem w ciągu 24 godzin od powzięcia wiedzy.
Harmonogram stosowania według art. 71:
- Obowiązki zgłoszeniowe z art. 14 od 11 września 2026 roku.
- Rozdział IV o jednostkach notyfikowanych (art. 35-51) od 11 czerwca 2026 roku.
- Cała reszta, w tym pełne obowiązki producentów, od 11 grudnia 2027 roku.
- Wymogi oceny zgodności dla “ważnych” i “krytycznych” produktów z elementami cyfrowymi mają osobne ścieżki (art. 32).
Oprogramowanie open source rozwijane i dostarczane bez działalności komercyjnej pozostaje poza zakresem CRA. Motywy rozporządzenia odróżniają niekomercyjny wkład w open source od komercyjnego pakietowania. Rdzeń WordPressa to niekomercyjny open source; oferta zarządzanego WordPressa sprzedawana jako produkt, z wtyczkami premium objętymi jedną licencją, może już wejść w zakres CRA.
NIS2 (dyrektywa 2022/2555)
Obejmuje podmioty (kluczowe i ważne) wymienione w załącznikach I i II. Art. 21 ust. 2 wymienia dziesięć środków zarządzania ryzykiem, lit. a)-j) (szczegółowo w artykule o ścieżce dowodowej z załącznika II). Art. 23 ust. 4 ustala wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny i sprawozdanie końcowe po miesiącu (szczegółowo w 24-godzinnym playbooku reagowania na incydenty). Art. 21 ust. 2 lit. d) wciąga dostawców pośrednio: podmiot musi zadbać o bezpieczeństwo łańcucha dostaw, w tym o relacje z bezpośrednimi dostawcami i usługodawcami, a art. 21 ust. 3 każe mu uwzględnić praktyki bezpiecznego rozwoju każdego dostawcy.
Termin transpozycji minął 2024-10-17 (art. 41). Kilka państw członkowskich się spóźniło; przed każdym audytem końcowym sprawdź stan krajowy.
DORA (rozporządzenie 2022/2554)
Obejmuje podmioty finansowe wymienione w art. 2 oraz kluczowych zewnętrznych dostawców usług ICT (CTPP) wyznaczonych przez Europejskie Urzędy Nadzoru na podstawie art. 31. Art. 28-30 dotyczą ryzyka ICT związanego z podmiotami trzecimi: zasady ogólne, rejestr informacji i strategie wyjścia są w art. 28 (szczegółowo w artykule o audycie dostawców z art. 28 DORA), a obowiązkowe postanowienia umów w art. 30. Art. 17-19 opisują proces zarządzania incydentami związanymi z ICT, ich klasyfikację i zgłaszanie poważnych incydentów. Art. 24-27 dotyczą testowania operacyjnej odporności cyfrowej, w tym TLPT.
Stosuje się bezpośrednio w całej UE od 2025-01-17 (art. 64).
Czy NIS2 nadal obowiązuje, gdy podmiot finansowy podlega DORA
Nie w zakresie, który tu się liczy. Art. 4 ust. 1 NIS2 wyłącza jej własne przepisy o zarządzaniu ryzykiem, zgłaszaniu i nadzorze tam, gdzie sektorowy akt prawny Unii nakłada wymogi co najmniej równoważne w skutkach. Motyw 28 NIS2 wskazuje DORA jako taki akt dla podmiotów finansowych: przepisy DORA o zarządzaniu ryzykiem ICT, zgłaszaniu incydentów, testowaniu odporności, wymianie informacji i ryzyku ze strony podmiotów trzecich stosuje się zamiast przepisów NIS2.
Dla wdrożenia headless WordPressa dzieli to klientów na dwie grupy:
- Bank, ubezpieczyciel, instytucja płatnicza albo firma inwestycyjna działa pod DORA. Pakiet dowodów odwołuje się do artykułów DORA, a zgłoszenia incydentów trafiają do właściwego organu nadzoru finansowego na podstawie art. 19 DORA.
- Szpital, przedsiębiorstwo energetyczne, organ administracji publicznej albo inny podmiot z załącznika I lub II działa pod krajową ustawą wdrażającą NIS2. Pakiet dowodów odwołuje się do art. 21 ust. 2, a zgłoszenia incydentów trafiają do CSIRT albo organu właściwego na podstawie art. 23.
CRA przecina obie grupy: jeśli agencja dostarcza produkt komercyjny, jej obowiązki producenta obowiązują niezależnie od reżimu klienta. Dlatego tabela punktów wspólnych niżej ma kolumnę NIS2 i kolumnę DORA, ale jedno zlecenie wypełnia tylko jedną z nich.
Kiedy sama agencja podlega NIS2
NIS2 nie sięga wyłącznie do klienta. Załącznik I pkt 9 wymienia “Zarządzanie usługami ICT (między przedsiębiorstwami)”, czyli dostawców usług zarządzanych i dostawców usług zarządzanych w zakresie bezpieczeństwa. Art. 6 pkt 39 definiuje dostawcę usług zarządzanych jako podmiot świadczący usługi związane z instalacją, zarządzaniem, obsługą lub utrzymaniem produktów, sieci, infrastruktury lub aplikacji ICT, w formie wsparcia albo aktywnej administracji, u klienta lub zdalnie.
Agencja, która w ramach umowy opieki prowadzi hosting, aktualizacje i monitoring instalacji WordPressa swoich klientów, pasuje do tego opisu. O tym, czy podlega dyrektywie, decyduje test wielkości z art. 2 ust. 1: dyrektywa obejmuje podmioty, które są średnimi przedsiębiorstwami w rozumieniu zalecenia Komisji 2003/361/WE albo przekraczają te progi. Według art. 2 tego zalecenia małe przedsiębiorstwo zatrudnia mniej niż 50 osób i ma obrót lub sumę bilansową do 10 mln EUR, więc agencja z 50 lub więcej pracownikami i linią usług zarządzanego hostingu to przypadek do sprawdzenia. Jeśli podlega, potrzebuje własnych środków z art. 21 i własnej ścieżki zgłoszeń z art. 23, niezależnie od klientów.
Czy strona na headless WordPressie jest produktem w rozumieniu CRA
Zwykle nie, i rozporządzenie mówi to wprost. Motyw 12 CRA stwierdza, że strony internetowe, które nie wspierają funkcjonalności produktu z elementami cyfrowymi, nie wchodzą w jego zakres, a usługi chmurowe typu SaaS, PaaS i IaaS podlegają zamiast tego NIS2. Strona marketingowa albo frontend bankowości internetowej na headless WordPressie to strona eksploatowana jako usługa, a nie produkt wprowadzony do obrotu.
CRA wchodzi przez trzy węższe drzwi:
- Produkt komercyjny sprzedawany wielu klientom. Motyw premium, płatna wtyczka albo licencjonowany zestaw startowy frontendu dostarczany w ramach działalności handlowej to produkt z elementami cyfrowymi (art. 3 pkt 1).
- Aplikacja z własnym backendem. Art. 3 pkt 2 i motyw 11 traktują “zdalne przetwarzanie danych” zaprojektowane przez producenta lub na jego odpowiedzialność, bez którego produkt nie może wykonać jednej ze swoich funkcji, jako część produktu. Gdy aplikacja mobilna działa w oparciu o własny endpoint REST WordPressa, ten endpoint wchodzi w zakres CRA tej aplikacji.
- Komponenty open source w produkcie komercyjnym. Art. 13 ust. 5 wymaga od producentów należytej staranności przy integrowaniu komponentów stron trzecich, także wolnych i otwartych, a art. 13 ust. 6 nakazuje zgłosić podatność wykrytą w komponencie temu, kto go utrzymuje.
Żaden z typów produktów w załączniku III (produkty ważne) ani w załączniku IV (produkty krytyczne) nie jest CMS-em, motywem ani frontendem webowym. Typowy produkt WordPressowy korzysta więc z procedury kontroli wewnętrznej (moduł A z załącznika VIII), bez jednostki notyfikowanej.
Jak porównać terminy zgłoszeń w CRA, NIS2 i DORA
Każdy akt ma własny zegar, który rusza w innym momencie:
| Etap | CRA art. 14 (producent) | NIS2 art. 23 ust. 4 (podmiot) | DORA art. 19 + RTS 2025/301 art. 5 (podmiot finansowy) |
|---|---|---|---|
| Zdarzenie | Aktywnie wykorzystywana podatność albo poważny incydent | Poważny incydent | Poważny incydent związany z ICT |
| Pierwsze zgłoszenie | Wczesne ostrzeżenie w ciągu 24 h od powzięcia wiedzy | Wczesne ostrzeżenie w ciągu 24 h od powzięcia wiedzy | Powiadomienie wstępne w ciągu 4 h od zaklasyfikowania jako poważny, najpóźniej 24 h od powzięcia wiedzy |
| Drugie zgłoszenie | Zgłoszenie w ciągu 72 h od powzięcia wiedzy | Zgłoszenie incydentu w ciągu 72 h od powzięcia wiedzy | Sprawozdanie pośrednie w ciągu 72 h od powiadomienia wstępnego |
| Sprawozdanie końcowe | 14 dni od udostępnienia poprawki (podatność) albo miesiąc od zgłoszenia (incydent) | Miesiąc od zgłoszenia incydentu | Miesiąc od ostatniego sprawozdania pośredniego |
| Adresat | CSIRT koordynator i ENISA, przez jednolitą platformę | Krajowy CSIRT albo organ właściwy | Właściwy organ nadzoru finansowego (art. 46) |
Terminy DORA pochodzą z rozporządzenia delegowanego Komisji (UE) 2025/301, a nie z samego DORA. Praktyczny skutek dla stosu headless: agencja frontendowa, która jest jednocześnie producentem w rozumieniu CRA, może być winna własne 24-godzinne zgłoszenie do ENISA o tej samej podatności, którą bank zgłasza swojemu nadzorcy. Oba zgłoszenia powinny się do siebie odwoływać, a runbook powinien wskazywać, kto składa które.
Gdzie CRA, NIS2 i DORA się pokrywają
Wdrożenie headless WordPressa z komercyjnym bundlem frontendu w zestawie trafia na następujące punkty wspólne. Kolumna NIS2 dotyczy klientów spoza sektora finansowego, kolumna DORA podmiotów finansowych:
| Obszar kontroli | Odniesienie CRA | Odniesienie NIS2 | Odniesienie DORA |
|---|---|---|---|
| Obsługa podatności | Art. 13 ust. 8, załącznik I część II | Art. 21 ust. 2 lit. e) | Art. 8 ust. 2 (identyfikacja podatności ICT) |
| Aktualizacje bezpieczeństwa | Art. 13 ust. 8 i 9, załącznik I część II pkt 2, 7 i 8 | Art. 21 ust. 2 lit. e) | Art. 9 ust. 4 lit. f) (poprawki i aktualizacje) |
| Wykaz komponentów oprogramowania | Załącznik I część II pkt 1 | Art. 21 ust. 2 lit. e) (nabywanie i rozwój) | Art. 8 ust. 1 i 4 (inwentarz aktywów ICT) |
| Zgłaszanie incydentów | Art. 14 (CSIRT i ENISA, 24 h) | Art. 23 (24/72/30) | Art. 19 (terminy dla podmiotów finansowych) |
| Łańcuch dostaw | Art. 13 ust. 5 (należyta staranność wobec komponentów stron trzecich) | Art. 21 ust. 2 lit. d) | Art. 28 i 30 (ryzyko podmiotów trzecich i umowy) |
| Zarządzanie ryzykiem | Art. 13 ust. 2 i 3 (ocena ryzyka) | Art. 21 ust. 2 lit. a) | Art. 6 (ramy zarządzania ryzykiem ICT) |
| Uwierzytelnianie | Załącznik I część I pkt 2 lit. d) (ochrona przed nieuprawnionym dostępem) | Art. 21 ust. 2 lit. j) (MFA) | Art. 9 ust. 4 lit. d) (silne uwierzytelnianie) |
| Kryptografia | Załącznik I część I pkt 2 lit. e) | Art. 21 ust. 2 lit. h) | Art. 9 ust. 4 lit. d) (ochrona kluczy kryptograficznych) |
Osiem wspólnych kontroli. Jeden pakiet dowodów z ośmioma folderami, z odniesieniami do CRA i do reżimu, któremu podlega klient, spełnia wymogi całej trójki.
Jak zbudować wspólny pakiet dowodów dla CRA, NIS2 i DORA
Pakiet układam według obszarów kontroli, nie według aktów. Każdy folder kontroli zawiera:
- Politykę. Zatwierdzoną przez organ zarządzający podmiotu. Z odniesieniami do właściwych artykułów CRA / NIS2 / DORA.
- Właściciela procesu. Wskazaną rolę po stronie podmiotu oraz imienną osobę kontaktową po stronie agencji.
- Dowody wdrożenia. Logi, raporty z audytów, wyniki skanów, wyniki testów, klauzule umowne.
- Tabelę mapowania. Trzy kolumny: artykuł CRA, artykuł NIS2, artykuł DORA. Gdzie polityka mieści się w każdym akcie.
- Zapis przeglądu. Przegląd roczny lub częstszy, z datą i podpisem.
- Historię audytów. Audyty zewnętrzne, testy penetracyjne, zapytania regulatora, wszystko z datami i oznaczeniami.
Wspólny pakiet eliminuje najczęstsze marnotrawstwo przy zgodności z kilkoma aktami: pisanie tego samego rejestru ryzyk trzy razy dla trzech regulatorów. Jeden rejestr, trzy odniesienia do artykułów w metadanych.
Jakich dowodów dla CRA, NIS2 i DORA wymaga wdrożenie headless
Projekt headless dokłada artefakty, których monolityczne wdrożenie WordPressa nie potrzebuje:
- SBOM bundla frontendu. Plik CycloneDX lub SPDX z listą wszystkich zależności npm, z wersją i licencją. CLI npm generuje go poleceniem
npm sbom --sbom-format cyclonedx(albospdx);npm audit signaturesto osobna kontrola, która weryfikuje podpisy rejestru. SBOM to produkt wymagany przez część II załącznika I CRA; przy NIS2 i DORA służy obsłudze podatności i inwentarzowi aktywów. - SBOM backendu WordPressa. Inwentarz wtyczek i motywów z wersją i licencją. WP-CLI eksportuje go poleceniami
wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=jsoniwp theme list --format=json; licencja pochodzi z nagłówka każdej wtyczki, do tego wewnętrzne pliki blokady wersji. - Inwentarz funkcji brzegowych. Cloudflare Workers, Netlify Functions, Vercel Edge. Każda funkcja jest elementem łańcucha dostaw i elementem powierzchni incydentów.
- Dokumentacja kontraktu API. Schemat OpenAPI lub GraphQL dla API headless, z definicjami zabezpieczeń, limitami zapytań i uwierzytelnianiem.
- Dowody z pipeline’u wdrożeń frontendu. Logi CI/CD, wyniki skanowania kontenerów, dowody skanowania sekretów, przegląd zależności przy każdym PR.
- Monitoring międzywarstwowy. Jeden dashboard albo runbook, który koreluje zdarzenia z backendu WordPressa, aplikacji frontendowej, warstwy brzegowej i zewnętrznych API.
Dla podmiotu regulowanego ten zestaw artefaktów jest obowiązkowy. Dla podmiotu nieregulowanego to dobra praktyka, ale rozmowa o budżecie robi się trudniejsza.
Czego nie obejmuje wspólny pakiet dla CRA, NIS2 i DORA
Są trzy obszary, których jeden pakiet nie pokrywa.
Ocena zgodności według CRA. Zgodnie z art. 32 ważne produkty klasy I, które nie stosują norm zharmonizowanych, wszystkie ważne produkty klasy II i produkty krytyczne wymagają badania typu UE albo pełnego zapewnienia jakości według załącznika VIII, z udziałem jednostki notyfikowanej, albo europejskiego programu certyfikacji cyberbezpieczeństwa, jeśli taki istnieje. NIS2 i DORA nie mają odpowiednika w postaci bazowej certyfikacji przez stronę trzecią (najbliżej jest TLPT z DORA). Ocenę zgodności zaplanuj jako osobny strumień prac, gdy produkt mieści się w załączniku III lub IV.
TLPT według art. 26 DORA. Testy penetracyjne prowadzone w oparciu o analizę zagrożeń dla wyznaczonych podmiotów finansowych odbywają się co najmniej raz na trzy lata na działających systemach produkcyjnych, a standardy techniczne dla nich opierają się na ramach TIBER-EU. NIS2 i CRA nie wymagają testów tej głębokości.
Nadzór sektorowy. NIS2 ma sektorowe organy właściwe. DORA ma właściwe organy nadzoru finansowego z art. 46, a dla każdego kluczowego zewnętrznego dostawcy usług ICT wiodący organ nadzorczy wspierany przez wspólny zespół ds. kontroli (art. 40). CRA ma organy nadzoru rynku z art. 52. Trzy różne kanały nadzorcze nadal wymagają osobnych procesów komunikacji.
Jakie kary przewidują CRA, NIS2 i DORA
Pułapy się różnią, bo akty regulują różne strony:
- CRA art. 64. Naruszenie zasadniczych wymagań z załącznika I albo art. 13 i 14: do 15 mln EUR lub 2,5 % całkowitego światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa. Inne obowiązki podmiotów gospodarczych: do 10 mln EUR lub 2 %. Nieprawidłowe lub wprowadzające w błąd informacje dla jednostek notyfikowanych albo organów nadzoru rynku: do 5 mln EUR lub 1 %.
- NIS2 art. 34. Naruszenie art. 21 lub 23: maksimum co najmniej 10 mln EUR lub 2 % dla podmiotów kluczowych i co najmniej 7 mln EUR lub 1,4 % dla podmiotów ważnych. Państwa członkowskie mogą pójść wyżej.
- DORA art. 50. Kwoty ustalają państwa członkowskie, które muszą dać właściwym organom uprawnienia sankcyjne. Wobec kluczowych zewnętrznych dostawców usług ICT wiodący organ nadzorczy może na podstawie art. 35 nałożyć okresową karę pieniężną do 1 % średniego dziennego światowego obrotu za każdy dzień, maksymalnie przez sześć miesięcy.
Dla agencji to linia CRA ląduje we własnym bilansie, bo to agencja jest producentem. Kary z NIS2 i DORA trafiają w klienta i dlatego klienci przerzucają je w dół łańcucha klauzulami umownymi.
Czego CRA, NIS2 i DORA wymagają od agencji WordPress
Agencja WordPress, która w 2026 roku chce dostarczać projekty headless podmiotom regulowanym, musi:
- Raz zbudować szablon wspólnego pakietu dowodów i używać go w kolejnych zleceniach.
- Generować SBOM w ramach pipeline’u wdrożeń, a nie na doczepkę.
- Prowadzić rejestr dostawców jako żywy dokument.
- Utrzymywać gotowość do reagowania na incydenty w obu warstwach (WordPress i frontend).
- Śledzić akty wykonawcze i delegowane, które Komisja przyjmuje na podstawie CRA, i poznać jednolitą platformę sprawozdawczą ENISA, zanim 11 września 2026 roku zacznie obowiązywać art. 14.
Wycena jest indywidualna; długość współpracy wyznacza zakres wymogów zgodności, a nie stały miesięczny abonament.
Powiązane poradniki o CRA, NIS2 i DORA
- Filar: NIS2 i DORA w WordPressie: zestaw wymogów zgodności na 2026 rok
- Załącznik II NIS2 dla agencji WordPress: zakres, terminy, ścieżka dowodowa
- Art. 28 DORA, ryzyko ICT podmiotów trzecich: audyt dostawców hostingu i WAF dla WordPressa
- Reagowanie na incydenty w WordPressie według NIS2: playbook wczesnego ostrzeżenia w 24 godziny
- BFSG a EAA: niemiecka ustawa o dostępności i termin 2025 dla sklepów na WordPressie
