Standardy bezpieczeństwa CMS dla korporacji w 2026

#SOC 2 i ISO 27001 dla bezpieczeństwa korporacyjnego CMS

SOC 2 i ISO 27001 oceniają organizację, która utrzymuje system. Kod motywu leży poza ich zakresem. Pomylenie tych dwóch rzeczy kończy się tym, że firma kupuje certyfikat i zostawia otwarty xmlrpc.php.

#SOC 2 Type II

SOC 2 to badanie organizacji usługowej prowadzone według zasad AICPA. Audytor raportuje o opisie systemu oraz o adekwatności zaprojektowania i skuteczności działania kontroli względem kryteriów trust services, które obejmują pięć kategorii: bezpieczeństwo, dostępność, integralność przetwarzania, poufność i prywatność (AICPA). Raport Type 1 ocenia kontrole na jeden dzień. Raport Type 2 sprawdza, czy działały przez cały okres badania.

W korporacyjnych projektach CMS raport SOC 2 prawie zawsze należy do dostawcy hostingu albo chmury. Obejmuje jego centrum danych, jego platformę i jego personel. Wasza wtyczka custom-checkout-fields nie wchodzi w jego zakres. Zakres jest zapisany w raporcie, więc warto go przeczytać, zanim odpowiedź na przetarg zapowie “instancję WordPressa zgodną z SOC 2”.

#ISO 27001

ISO/IEC 27001:2022 wymaga systemu zarządzania bezpieczeństwem informacji (ISMS): inwentarza aktywów, postępowania z ryzykiem, nadzoru nad dostawcami, audytów wewnętrznych i przeglądu zarządzania. W CMS przekłada się to na konkrety: lista wtyczek i ich dostawców, proces łatania z terminami, koncepcja dostępu dla redaktorów i agencji oraz umowy powierzenia przetwarzania danych z hostingiem i CDN.

Certyfikat ISO 27001 centrum danych nie rozciąga się na instalację WordPressa. Granica ISMS przebiega tam, gdzie zatwierdza się zmiany: Git, staging, produkcja i lista osób, które mogą uruchomić plugin install.

SOC 2 i ISO 27001 to częste filtry w zakupach dużych firm i sektora publicznego. Nie są wymogiem prawnym dla każdej firmowej strony. Sprzedawanie ich jako cechy WordPressa nie przetrwa pierwszej ankiety dostawcy, która zapyta o zakres.

#Czego NIS2 wymaga od korporacyjnego CMS

NIS2, czyli dyrektywa (UE) 2022/2555, dotyczy podmiotów kluczowych i ważnych z wymienionych w niej sektorów, a przez ich umowy także dostawców ICT, którzy je obsługują. Państwa członkowskie miały przyjąć przepisy wdrażające do 17 października 2024 i stosować je od 18 października 2024 (art. 41). Sklep na WooCommerce nie podlega NIS2 dlatego, że przyjmuje zamówienia. Podlega mu organizacja, gdy sektor i wielkość umieszczają ją w zakresie, a agencja wtedy, gdy klient objęty dyrektywą przenosi obowiązki w dół łańcucha dostaw.

Art. 21 ust. 2 określa środki minimalne. Każdy ma bezpośredni odpowiednik w stosie WordPressa:

Art. 21 ust. 3 dodaje, że przy doborze środków dla łańcucha dostaw trzeba uwzględnić podatności właściwe dla każdego bezpośredniego dostawcy oraz ogólną jakość jego produktów i praktyk bezpiecznego wytwarzania. W CMS bezpośredni dostawcy to hosting, agencja i każdy producent komercyjnej wtyczki.

Art. 20 nakłada na organ zarządzający obowiązek zatwierdzania tych środków i nadzoru nad nimi, czyni go odpowiedzialnym za naruszenia i wymaga od jego członków udziału w szkoleniach. Bezpieczeństwo CMS przestaje być zadaniem, które zespół webowy załatwia sam.

Art. 23 ustala łańcuch zgłoszeń dla poważnego incydentu: wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy, zgłoszenie incydentu w ciągu 72 godzin ze wstępną oceną powagi, skutków i, jeśli są dostępne, wskaźników naruszenia, oraz sprawozdanie końcowe najpóźniej miesiąc po zgłoszeniu. Art. 34 określa górne granice kar za naruszenie art. 21 lub 23: maksimum co najmniej 10 000 000 EUR albo 2% całkowitego rocznego światowego obrotu dla podmiotów kluczowych oraz co najmniej 7 000 000 EUR albo 1,4% dla podmiotów ważnych, w zależności od tego, która kwota jest wyższa.

DORA, czyli rozporządzenie (UE) 2022/2554, stosuje się od 17 stycznia 2025 do podmiotów finansowych i ich zewnętrznych dostawców usług ICT. CMS prowadzony dla instytucji nadzorowanej wchodzi w ten reżim, nie tylko w NIS2. Część wspólną opisujemy w przewodniku po NIS2 i DORA dla WordPressa.

#Stan wdrożenia NIS2 w poszczególnych krajach w 2026

Dyrektywa działa przez prawo krajowe, więc dla firmy liczy się data ustawy jej własnego państwa. Poniższy stan pochodzi z oficjalnych źródeł sprawdzonych 12 października 2026.

#Nowelizacja ustawy o KSC: terminy dla właścicieli CMS

Polska wdrożyła NIS2 ustawą z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, opublikowaną jako Dz.U. 2026 poz. 252 (ISAP). Nowelizacja obowiązuje od 3 kwietnia 2026. Ministerstwo Cyfryzacji rozpisało terminy przejściowe (gov.pl):

Termin na wniosek o wpis do wykazu minął 3 października 2026. Podmiot, który się nie zgłosił, powinien zrobić to teraz, a nie czekać na rok 2027. Ustawa przypisuje odpowiedzialność za bezpieczeństwo kierownictwu, tak jak art. 20 dyrektywy. Dla właściciela korporacyjnego CMS w podmiocie objętym ustawą oznacza to, że plan łatek, inwentarz wtyczek i procedura zgłoszeń powinny być gotowe przed 3 kwietnia 2027.

Praktyczny wniosek dla grupy z serwisami w kilku krajach: jedna bazowa konfiguracja bezpieczeństwa CMS oparta na art. 21 i osobna procedura zgłoszeń dla każdego kraju, z właściwym organem i formularzem.

#Co Cyber Resilience Act oznacza dla wtyczek i motywów WordPressa

Cyber Resilience Act, czyli rozporządzenie (UE) 2024/2847, opublikowano w Dzienniku Urzędowym 20 listopada 2024. W całości stosuje się od 11 grudnia 2027. Art. 14 obowiązuje od 11 września 2026: producent, który dowie się o aktywnie wykorzystywanej podatności w swoim produkcie, musi wysłać wczesne ostrzeżenie w ciągu 24 godzin i zgłoszenie podatności w ciągu 72 godzin, przez jedną platformę zgłoszeniową, do koordynującego CSIRT i do ENISA.

CRA wiąże producentów produktów z elementami cyfrowymi. Firma, która tylko prowadzi stronę, producentem nie jest. W ekosystemie WordPressa daje to trzy role:

• Komercyjni producenci wtyczek i motywów, którzy wprowadzają oprogramowanie na rynek UE w ramach działalności handlowej, są producentami. Ich obowiązek zgłaszania już biegnie.
• Wolne i otwarte oprogramowanie podlega rozporządzeniu tylko wtedy, gdy jest udostępniane w ramach działalności handlowej (motyw 18). Rozporządzenie wprowadza lżejszą rolę, opiekuna oprogramowania open source: osobę prawną, która systematycznie wspiera wolne oprogramowanie przeznaczone do użytku komercyjnego. Opiekun musi udokumentować politykę cyberbezpieczeństwa i obsługiwać podatności (art. 24).
• Właściciel strony jest użytkownikiem. Jego obowiązki z NIS2 albo z umów pozostają bez zmian, ale CRA daje mu podstawę do konkretnych pytań.

CRA definiuje wykaz komponentów oprogramowania (SBOM) jako formalny zapis komponentów i relacji w łańcuchu dostaw produktu (art. 3 pkt 39). Przy każdym zakupie wtyczki trzeba od teraz zadać trzy pytania: kto przyjmuje wasze zgłoszenia podatności, jak szybko wydajecie poprawki i czy dostarczycie SBOM dla wersji, której używamy.

#Zero trust i MFA dla dostępu administracyjnego do CMS

Zero trust w CMS oznacza, że żaden adres źródłowy nie jest zaufany: każda sesja administracyjna jest potwierdzana od nowa. Stary model, w którym VPN biurowy równa się intranetowi, a intranet równa się wp-admin, to standardowe ustalenie w sieciach agencji.

#Obowiązkowe uwierzytelnianie wieloskładnikowe

Hasło plus link w mailu to za słaba ochrona wp-admin. Kody SMS przegrywają z atakiem SIM swap. Lepiej użyć kluczy bezpieczeństwa FIDO2, uwierzytelniaczy platformowych albo passkeys. WordPress może wydawać Application Passwords dla dostępu przez REST i CLI. Biała księga bezpieczeństwa WordPressa opisuje je jako odwoływalne i nieważne przy logowaniu do panelu. To nadal długowieczne sekrety: trzeba je rotować, przypisać do dedykowanego użytkownika API i trzymać poza repozytoriami Git agencji.

Proxy świadome tożsamości, na przykład Cloudflare Access, ustawione przed wp-admin i /wp-login.php, zastępuje firmowy VPN w rozproszonych zespołach redakcyjnych. Lista dozwolonych adresów IP biura przestaje działać w chwili, gdy ktoś pracuje z pociągu. Dostęp powiązany z dostawcą tożsamości (Entra ID, Google Workspace, Keycloak) trzyma politykę w jednym miejscu.

#Szczegółowe zarządzanie tożsamością i dostępem

Redaktor potrzebuje edit_posts, a nie install_plugins. Role SEO nie potrzebują manage_options. Kierownik sklepu potrzebuje zamówień, a nie edytora plików motywu. Redaktor nie powinien też widzieć ustawień wtyczek, bo każde konto z takim dostępem poszerza powierzchnię ataku na łańcuch dostaw. DISALLOW_FILE_EDIT w wp-config.php pozostaje pierwszą linią obrony przed przejętym kontem redaktora.

Sesje administracyjne powinny wygasać szybko, a kluczowe operacje, takie jak instalacja wtyczki czy zmiana roli, wymagać ponownego uwierzytelnienia.

Dostęp agencji podlega tej samej zasadzie najmniejszych uprawnień co pracownicy wewnętrzni. Wspólny login admin używany przez pięciu freelancerów odbiera wartość każdemu dziennikowi audytu. Jedno konto na osobę, dezaktywowane w dniu zakończenia projektu, a nie przemianowane.

#Utwardzanie serwera CMS z WAF i izolowanym panelem

CMS jest tak bezpieczny jak PHP-FPM, drzewo plików i droga do bazy danych. Tekst marketingowy hostingu nie zastąpi sshd_config.

• Niezmienna infrastruktura. Na hostingu opartym na kontenerach lub obrazach nowy obraz zastępuje działającą instancję i nikt nie edytuje produkcji przez SSH. Na planach zarządzanego WordPressa ten wzorzec nie istnieje; zastępuje go zakaz ręcznego wgrywania wtyczek, staging identyczny z produkcją i wdrożenia wyłącznie z Gita.
• Ochrona WAF i DDoS. WAF przed serwerem źródłowym filtruje credential stuffing na wp-login.php, znane ścieżki wtyczek i XML-RPC. WAF bez nazwanego produktu i nazwanego zestawu reguł nie jest celem kontrolnym.
• Zaplecze niepubliczne. W środowiskach o wysokim poziomie bezpieczeństwa wp-admin nie ma publicznego rekordu DNS. Dostęp prowadzi przez tunel albo VPN WireGuard, a serwer źródłowy rozmawia wyłącznie z tunelem.
• PHP i rdzeń. WordPress 7.1 ukazał się 19 sierpnia 2026, a 6 października 2026 wyszło wydanie 7.1.3 z poprawkami utrzymaniowymi i bezpieczeństwa. Trzeba zablokować xmlrpc.php, jeśli żaden uprawniony system go nie potrzebuje, i ograniczyć nieuwierzytelnione REST API do tego, co frontend faktycznie odczytuje.

#Powierzchnia ataku headless CMS a CMS monolityczny

Headless zmniejsza publiczną powierzchnię PHP. Aplikacja nadal istnieje.

Monolit. Każda strona renderuje PHP na bazie danych. Wtyczki podpinają się pod init. Skanery sprawdzają znane ścieżki w /wp-content/plugins/. WAF i automatyczne aktualizacje stają się wyposażeniem ratunkowym.

Headless. CDN serwuje HTML, CSS i zasoby bez interpretera na brzegu i bez publicznej bazy danych. wp-admin działa w sieci prywatnej albo za proxy świadomym tożsamości. Pozostała powierzchnia leży na serwerze źródłowym: REST, webhooki, cron i Application Passwords. Wyciekłe Application Password użyte przeciw /wp-json/ to nadal incydent.

W zakupach korporacyjnych headless często łatwiej obronić, bo publiczny brzeg nie ma interpretera. Serwer źródłowy wymaga jednak tych samych zabezpieczeń co monolit.

#OWASP Top 10:2025 w odniesieniu do WordPressa

OWASP Top 10:2025 to lista, na którą powołuje się większość przetargów, gdy piszą o bezpiecznym wytwarzaniu oprogramowania. W stosie WordPressa poszczególne kategorie trafiają w konkretne miejsca:

A03 to nowa kategoria w tej edycji i dobrze pasuje do WordPressa. Katalog wtyczek jest łańcuchem dostaw, a biała księga bezpieczeństwa WordPressa mówi wprost, że obecność w repozytorium nie gwarantuje braku podatności.

#OWASP ASVS 5.0 jako standard weryfikacji w przetargach na CMS

Top 10 to lista uświadamiająca. Gdy umowa potrzebuje wymagań, które da się przetestować, punktem odniesienia jest OWASP Application Security Verification Standard. Wersja 5.0.0 ukazała się 30 maja 2025 i ma 17 rozdziałów, między innymi V6 Authentication, V7 Session Management, V8 Authorization, V13 Configuration i V16 Security Logging and Error Handling.

ASVS definiuje trzy poziomy. Poziom 1 obejmuje około 20% wymagań i stanowi pierwszą warstwę obrony. OWASP zaleca, by większość aplikacji celowała w poziom 2; spełnienie go oznacza wdrożenie około 70% wszystkich wymagań (każdego punktu L1 i L2). Poziom 3 jest dla aplikacji, które potrzebują najwyższego stopnia pewności.

Dla korporacyjnego CMS wynikają z tego dwie praktyczne zasady. W umowie zamiast ogólnika o bezpieczeństwie zgodnym z OWASP warto wpisać “ASVS 5.0 poziom 2 dla własnych wtyczek i integracji”. Do każdej plakietki “certyfikat ASVS” trzeba podchodzić ostrożnie: OWASP deklaruje, że nie certyfikuje dostawców, weryfikatorów ani oprogramowania i nie popiera twierdzeń o takiej certyfikacji.

#Jak projekt WordPress dba o bezpieczeństwo rdzenia

Zespół bezpieczeństwa WordPressa liczy ponad 50 zaufanych ekspertów, w tym głównych programistów i badaczy bezpieczeństwa, a do tego członków sponsorowanych (wordpress.org/about/security). Podatności zgłasza się przez program WordPress na HackerOne. Oficjalnie wspierana jest tylko najnowsza wersja, ale poprawki są w ramach uprzejmości przenoszone do starszych gałęzi, dzięki czemu starsze strony dostają krytyczne łatki przez automatyczne aktualizacje. Zespół koordynuje też z dużymi hostingami i dostawcami bezpieczeństwa wdrażanie wydań i reguły WAF łagodzące podatności.

Biała księga bezpieczeństwa WordPressa, ostatnio aktualizowana we wrześniu 2025, opisuje mechanizmy, o które zwykle pyta korporacyjny recenzent:

• automatyczne aktualizacje w tle dla wszystkich wydań pomocniczych, dzięki którym poprawki bezpieczeństwa trafiają na strony bez działania administratora;
• hasła użytkowników hashowane algorytmem bcrypt ze wstępnym hashowaniem SHA-384, które obchodzi limit 72 bajtów danych wejściowych bcrypt;
• Application Passwords, klucze resetu i inne tokeny hashowane algorytmem BLAKE2b przez Sodium;
• nonce chroniące przed CSRF oraz API takie jak wpdb::prepare(), wp_kses() i funkcje sanitize_*() do bezpiecznej obsługi danych wejściowych i wyjściowych.

To dotyczy rdzenia. Ta sama biała księga zaznacza, że około 50 000 wtyczek i 4 500 motywów w katalogu przechodzi przed publikacją przegląd wolontariuszy, bez gwarancji braku podatności. W projektach korporacyjnych ryzyko leży właśnie w tej warstwie.

#Jak weryfikować i łatać wtyczki WordPressa

Najczęstsze ustalenie w korporacyjnym WordPressie to wtyczka bez opiekuna, a nie zero-day w rdzeniu.

• Inwentarz przed instalacją. Żadnej wtyczki bez nazwanego opiekuna, ścieżki aktualizacji i wpisu w SBOM. Każda wtyczka płatności, wysyłki i fakturowania jest dostawcą w rozumieniu art. 21 ust. 2 lit. d NIS2.
• Przegląd kodu dla wszystkiego, co nie przychodzi od producenta podpisanym kanałem aktualizacji. Wtyczki must-use i kod agencji należą do Gita, nie tylko na serwer.
• Śledzenie podatności. Patchstack, WPScan albo komunikaty producentów. Kanał CVE bez terminu wdrożenia łatki niczego nie zabezpiecza.
• Composer i npm. Motywy z etapem budowania wciągają pliki lock. Ich wersje trafiają do tego samego SBOM co wtyczki PHP.
• SLA na łatki. Krytyczne poprawki rdzenia i bramek w udokumentowanym terminie; aktualizacje funkcjonalne najpierw przez staging.

Warstwę konfiguracji (uprawnienia plików, stałe w wp-config.php, reguły serwera) opisujemy krok po kroku w przewodniku po zaawansowanym utwardzaniu WordPressa.

#Szyfrowane kopie zapasowe CMS i odtwarzanie do punktu w czasie

Plan bezpieczeństwa bez przetestowanego odtworzenia to dokument, nie kontrola.

• 3-2-1. Kopia hostingu to kopia pierwsza, często na tej samej platformie. Druga trafia do magazynu u innego dostawcy albo w innym regionie. Trzecia leży offline albo na koncie, z którego dane dostępowe produkcji nie mogą jej usunąć. Ransomware, który ma wp-config.php i hasło do panelu, chętnie kasuje też oficjalną kopię.
• Szyfrowanie. Kopie szyfrowane w spoczynku i podczas przesyłania, klucze przechowywane osobno od kopii.
• RPO dla sklepów. Dla strony wizytówkowej wystarczy kopia dzienna. Sklep z RPO 24 godzin traci zamówienia, które mogły już trafić do ERP albo księgowości. Lukę zamykają cogodzinne zrzuty bazy z logami binarnymi albo zarządzane odtwarzanie do punktu w czasie oferowane przez hosting.
• Testy odtworzenia. Raz na kwartał odtworzenie na stagingu, ze stoperem i pisemnym protokołem. Kwestionariusze NIS2 (art. 21 ust. 2 lit. c) i DORA pytają właśnie o ten protokół.

#Ryzyko inżynierii społecznej i dzienniki audytu CMS

Większość przejęć wp-admin w projektach agencyjnych zaczyna się od maila, nie od exploita. Redaktorzy i księgowość są celem, bo widzą zamówienia, faktury i wtyczki PDF. Wiadomość “eksport faktur się nie powiódł, zaloguj się tutaj” z fałszywą stroną logowania działa, gdy brakuje MFA. Jedna symulacja phishingu na kwartał, z prawdziwym adresem logowania jako materiałem szkoleniowym, daje więcej niż coroczna prezentacja.

Dzienniki audytu. Każda instalacja wtyczki, zmiana roli i zmiana klucza bramki zapisana z użytkownikiem, czasem, adresem IP i obiektem. Dziennik trafia poza WordPressa, do sysloga albo SIEM, więc napastnik z uprawnieniami administratora nie może go wymazać. Art. 21 ust. 2 lit. i NIS2 i kategoria A09 OWASP wskazują tę samą lukę.

Gdy freelancer odchodzi z projektu, jego konto znika tego samego dnia. Wspólny wpis w menedżerze haseł z jednym hasłem do wp-admin dla wszystkich to zaprzeczenie kontroli dostępu.

#Powierzchnia ataku wtyczek kasy i webhooków płatności

Strony katalogu można cache’ować na brzegu. Kasy, wc-ajax, webhooków płatności i adresów powrotu już nie, i tam leży powierzchnia ataku.

Każda bramka płatności otwiera trzy rzeczy: przekierowanie albo hostowane pole płatności, endpoint webhooka pod /wc-api/ lub /wp-json/ i często cron statusów. Bez weryfikacji podpisu webhooka napastnik oznacza zamówienia jako opłacone. Stripe i PayPal podpisują swoje webhooki. Domowej roboty endpoint, który uznaje płatność za zakończoną po parametrze GET secret=, to klasyczne ustalenie audytu.

Gdy pola karty zostają u operatora płatności (hosted fields albo komponenty), sprzedawca zwykle mieści się w najmniejszym zakresie samooceny PCI DSS. Gdy wtyczka zapisuje numer karty albo CVC w wp_postmeta, to założenie przestaje obowiązywać. Po zamówieniu testowym warto sprawdzić klucze meta wpisu: token i ostatnie cztery cyfry są normalne, pełny numer karty oznacza usunięcie bramki.

Klucze REST do wc/v3/orders z szerokimi uprawnieniami dają pełny dostęp do danych klientów. Jeden klucz na system (ERP, mostek do księgowości, wysyłka), tylko do odczytu tam, gdzie się da, z listą dozwolonych IP na serwerze źródłowym.

#Object cache i logi debugowania w sklepach z płatnościami

Redis przyspiesza odczyt obiektów. Bez filtrowania przechowuje też sesje, transienty, a czasem odpowiedzi bramek.

• Czego nie zostawiać w cache: surowych odpowiedzi bramek z tokenami po upływie TTL, sesji koszyka z danymi płatności, wyjścia debugowania. Przed skopiowaniem zrzutu cache na staging trzeba sprawdzić klucze sesji WooCommerce.
• debug.log. WP_DEBUG_LOG zapisujący do wp-content/debug.log na serwerze z listowaniem katalogów to publiczny log. Trafiają do niego adresy e-mail, numery NIP i adresy, gdy tylko bramka rzuci wyjątek. Logi należy zapisywać poza katalogiem głównym dokumentów, rotować je i ograniczyć dostęp do zespołu utrzymania.
• Pełny cache stron a koszyk. Cache’ować tylko strony katalogu i treści. Ciasteczko albo sesja koszyka muszą uruchamiać regułę pominięcia. Zcache’owany minikoszyk z produktami innego klienta to incydent naruszenia poufności, a nie zysk wydajności.

#Usługi bezpieczeństwa WordPressa dla dużych firm od WPPoland

WPPoland utwardza stosy WordPress i WooCommerce pod standardy, które faktycznie sprawdzają działy zakupów dużych firm: zakres SOC 2 albo ISO 27001 dostawcy hostingu, środki z art. 21 NIS2, zero trust na wp-admin, inwentarz wtyczek i SBOM, powierzchnię kasy i bramek płatności. WPPoland nie ma własnego raportu SOC 2 ani certyfikatu ISO; dowody, które dostarczamy, są operacyjne.

1. Bezpieczeństwo w kodzie. Własne wtyczki i integracje przeglądane według OWASP Top 10:2025, z ASVS 5.0 jako listą wymagań tam, gdzie umowa jej wymaga.
2. Monitoring i przegląd. Skanery podatności i integralności plików działają w trybie ciągłym. Przegląd przez człowieka obejmuje aktualizacje bramek, zmiany ról i testy odtworzenia.
3. Dowody. SLA na łatki, protokół odtworzenia, lista podprocesorów i procedura incydentowa ze ścieżką 24/72 godziny. Właśnie te elementy są oczekiwane w kwestionariuszach NIS2 i DORA.

Punktem wyjścia jest audyt bezpieczeństwa WordPressa. W regulowanych łańcuchach dostaw łączy się go z audytem zgodności z prawem UE dla WordPressa.

#Jak utrzymać bezpieczeństwo korporacyjnego CMS na co dzień

Korporacyjny CMS przechodzi przegląd w 2026 roku, gdy dowody od hostingu, model aplikacji i codzienne utrzymanie do siebie pasują. SOC 2 i ISO 27001 filtrują dostawcę. Art. 21 NIS2 daje listę środków, a art. 23 zegar zgłoszeń. Cyber Resilience Act nakłada obowiązki zgłaszania na producentów wtyczek i motywów i podsuwa kupującym właściwe pytania. OWASP Top 10:2025 i ASVS 5.0 zamieniają ogólnik o bezpiecznym wytwarzaniu w wymagania, które da się przetestować.

Bezpieczeństwo pozostaje cyklem: inwentaryzacja, utwardzanie, monitoring, odtwarzanie, dowód. Bez tego cyklu żaden certyfikat hostingu nie zmieni przebiegu następnego incydentu. Jeśli CMS zostaje w tyle, najpierw warto spisać obecny stos, model dostępu, proces aktualizacji i ostatnie incydenty. Dzięki temu przegląd bezpieczeństwa dotyczy konkretnej instalacji.