Estándares de seguridad para CMS corporativos

#SOC 2 e ISO 27001 en la seguridad de un CMS corporativo

SOC 2 e ISO 27001 evalúan a la organización que opera un sistema, no el código del tema. Confundir ambas cosas es la forma en que una empresa compra un certificado y mantiene abierto xmlrpc.php.

#SOC 2 Type II

SOC 2 es un examen de la AICPA sobre una organización de servicios. El auditor informa sobre la descripción del sistema y sobre la idoneidad del diseño y la eficacia operativa de los controles frente a los criterios de servicios de confianza, que abarcan cinco categorías: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad (AICPA). Un informe Type 1 examina los controles en una fecha concreta. Un informe Type 2 comprueba si funcionaron durante un periodo.

En los proyectos de CMS corporativos, el informe SOC 2 pertenece casi siempre al proveedor de alojamiento o de nube. Cubre su centro de datos, su plataforma y su personal. No cubre tu plugin custom-checkout-fields. El alcance figura en el propio informe, así que conviene leerlo antes de que una respuesta a una licitación hable de una instancia de WordPress conforme con SOC 2.

#ISO 27001

ISO/IEC 27001:2022 exige un sistema de gestión de seguridad de la información (SGSI): inventario de activos, tratamiento de riesgos, control de proveedores, auditorías internas y revisión por la dirección. En un CMS esto se concreta en una lista de plugins y de sus proveedores, un proceso de parcheo con plazos, un esquema de acceso para editores y agencia, y contratos de encargo de tratamiento con el alojamiento y la CDN.

Un certificado ISO 27001 del centro de datos no se extiende a la instalación de WordPress. El límite del SGSI está donde se aprueban los cambios: Git, staging, producción y quién tiene permiso para ejecutar plugin install.

SOC 2 e ISO 27001 son filtros habituales en las compras de grandes empresas y del sector público. No son un requisito legal para cualquier web corporativa. Venderlos como una propiedad de WordPress no supera el primer cuestionario de proveedor que pregunte por el alcance.

#RGPD y privacidad de datos en el CMS

Para cualquier CMS corporativo que opere en Europa o atienda a usuarios europeos, el cumplimiento del RGPD es obligatorio. En el contexto del CMS esto significa:

• gestión granular del consentimiento de cookies;
• capacidad de exportar y eliminar los datos de un usuario cuando lo solicite;
• registro de actividades de tratamiento mantenido al día;
• evaluaciones de impacto relativas a la protección de datos (EIPD) para las funcionalidades nuevas que lo requieran.

#Qué exige NIS2 a un CMS corporativo

NIS2, la Directiva (UE) 2022/2555, se aplica a las entidades esenciales e importantes de los sectores que enumera y, a través de sus contratos, a los proveedores TIC que les dan servicio. Los Estados miembros debían adoptar sus medidas de transposición antes del 17 de octubre de 2024 y aplicarlas desde el 18 de octubre de 2024 (artículo 41). Una tienda WooCommerce no entra en NIS2 por aceptar pedidos. Entra la organización cuando su sector y su tamaño la sitúan dentro del ámbito, y entra la agencia cuando un cliente sujeto a la norma traslada las obligaciones a lo largo de la cadena de suministro.

El artículo 21, apartado 2, fija las medidas mínimas. Cada una tiene un equivalente directo en una instalación de WordPress:

El artículo 21, apartado 3, añade que las medidas sobre la cadena de suministro deben tener en cuenta las vulnerabilidades propias de cada proveedor directo, así como la calidad de sus productos y de sus prácticas de desarrollo seguro. En un CMS, los proveedores directos son el alojamiento, la agencia y cada fabricante de plugins comerciales.

El artículo 20 obliga al órgano de dirección a aprobar estas medidas, supervisar su aplicación y responder de los incumplimientos, y exige que sus miembros sigan formación. La seguridad del CMS deja de ser una tarea exclusiva del equipo web.

El artículo 23 establece la cadena de notificación de un incidente significativo: una alerta temprana en las 24 horas siguientes a tener conocimiento de él, una notificación del incidente en 72 horas con una evaluación inicial de su gravedad, su impacto y, cuando existan, los indicadores de compromiso, y un informe final a más tardar un mes después de la notificación. El artículo 34 fija los topes de las multas por infringir los artículos 21 o 23 en un máximo de al menos 10 000 000 EUR o el 2 % del volumen de negocios anual mundial para las entidades esenciales, y de al menos 7 000 000 EUR o el 1,4 % para las importantes, si esta cifra es superior.

DORA, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025 a las entidades financieras y a sus proveedores terceros de servicios TIC. Un CMS gestionado para una entidad supervisada queda dentro de ese régimen además de NIS2. El solapamiento entre ambos se explica en nuestra guía de NIS2 y DORA para WordPress.

#Estado de la transposición de NIS2 por países en 2026

Una directiva actúa a través de la legislación nacional, así que la fecha que importa a una empresa es la de la ley de su propio país. El estado que sigue procede de fuentes oficiales consultadas el 12 de octubre de 2026.

La consecuencia práctica para un grupo con webs en varios países: una única base de seguridad del CMS construida sobre el artículo 21 y un procedimiento de notificación por país, con la autoridad y el formulario que correspondan.

#Transposición de NIS2 en España: cómo prepararse sin ley publicada

El Consejo de Ministros aprobó el 14 de enero de 2025 el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad y acordó su tramitación urgente (La Moncloa). El plazo de transposición de la directiva venció el 17 de octubre de 2024. A 12 de octubre de 2026, nuestra consulta de la legislación consolidada del BOE no devolvió ninguna ley publicada que transponga NIS2, y no pudimos confirmar en qué fase parlamentaria se encuentra el texto.

Para quien gestiona un CMS en España, esto significa que todavía no hay plazos nacionales de registro, formularios ni regímenes sancionadores publicados que se puedan citar con fuente. Cualquier lista de obligaciones atribuida al anteproyecto debe tratarse con cautela hasta que el texto definitivo aparezca en el BOE. La referencia más sólida para prepararse es la lista de medidas del artículo 21 de la directiva, que cualquier ley de transposición debe recoger como mínimo, junto con la cadena de notificación del artículo 23. Una empresa española que da servicio a clientes sujetos a NIS2 en Alemania o Portugal ya recibe esas obligaciones a través de los contratos, con independencia del calendario español.

#Qué supone la Cyber Resilience Act para plugins y temas de WordPress

La Cyber Resilience Act, Reglamento (UE) 2024/2847, se publicó en el Diario Oficial el 20 de noviembre de 2024. Se aplica en su totalidad a partir del 11 de diciembre de 2027. El artículo 14 rige desde el 11 de septiembre de 2026: un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en su producto debe enviar una alerta temprana en 24 horas y una notificación de la vulnerabilidad en 72 horas, a través de la plataforma única de notificación, al CSIRT coordinador y a ENISA.

La CRA obliga a los fabricantes de productos con elementos digitales, no a la empresa que opera una web. En el ecosistema de WordPress eso se reparte en tres grupos:

• Fabricantes de plugins y temas comerciales que comercializan software en el mercado de la UE en el marco de una actividad comercial. Son fabricantes y su obligación de notificar ya está en marcha.
• Software libre y de código abierto, que solo entra en el ámbito cuando se suministra en el marco de una actividad comercial (considerando 18). El reglamento añade una figura más ligera, el administrador de software de código abierto: una persona jurídica que apoya de forma sistemática software libre destinado a uso comercial. Los administradores deben documentar una política de ciberseguridad y gestionar vulnerabilidades (artículo 24).
• El propietario de la web, que es usuario. Sus obligaciones derivadas de NIS2 o de los contratos no cambian, pero la CRA le da algo que exigir.

La CRA define la lista de materiales de software como un registro formal de los componentes y de las relaciones de la cadena de suministro de un producto (artículo 3, punto 39). A partir de ahora, tres preguntas deben acompañar cada compra de un plugin: quién recibe vuestros informes de vulnerabilidades, con qué rapidez publicáis correcciones y si podéis entregar un SBOM de la versión que usamos.

#Zero trust y MFA para el acceso de administración al CMS

Zero trust en un CMS significa que ninguna IP de origen es de confianza: cada sesión de administración se vuelve a demostrar. El modelo antiguo en el que la VPN de la oficina equivale a la intranet y esta equivale a wp-admin es el hallazgo por defecto en las redes de las agencias.

#Autenticación multifactor obligatoria

Una contraseña más un enlace por correo no es protección suficiente para wp-admin. Los códigos por SMS fallan ante un SIM swap. Usa llaves de seguridad FIDO2, autenticadores de plataforma o passkeys. WordPress puede emitir Application Passwords para el acceso por REST y CLI. El white paper de seguridad de WordPress las describe como revocables y no válidas para iniciar sesión en el área de administración. Aun así, son secretos de larga duración: hay que rotarlas, vincularlas a un usuario de API dedicado y mantenerlas fuera de los repositorios Git de la agencia.

Las opciones de MFA, de más a menos resistentes al phishing:

1. Passkeys y WebAuthn: resistentes al phishing por diseño, porque la credencial está ligada al dominio.
2. Llaves de seguridad FIDO2: autenticación criptográfica con un dispositivo físico.
3. Autenticadores de plataforma con biometría: huella o reconocimiento facial vinculados al dispositivo.
4. Aplicaciones TOTP: códigos temporales que un sitio de phishing puede capturar y reutilizar en el momento.
5. OTP por SMS o correo: la opción más débil, expuesta al SIM swap y a la toma de la cuenta de correo.

Un proxy con verificación de identidad, como Cloudflare Access, delante de wp-admin y /wp-login.php sustituye a la VPN corporativa en equipos editoriales distribuidos. Una lista de IP de la oficina deja de funcionar en cuanto alguien trabaja desde el tren. El acceso vinculado a un proveedor de identidad (Entra ID, Google Workspace, Keycloak) mantiene la política en un solo lugar.

#Gestión granular de identidades y accesos

Los editores necesitan edit_posts, no install_plugins. Los roles de SEO no necesitan manage_options. Los responsables de tienda necesitan los pedidos, no el editor de archivos del tema. DISALLOW_FILE_EDIT en wp-config.php sigue siendo la primera barrera frente a una cuenta de editor comprometida.

El acceso de la agencia sigue la misma regla de mínimo privilegio que el del personal interno. Un usuario admin compartido por cinco freelancers deja sin valor cualquier registro de auditoría. Una cuenta por persona, desactivada el mismo día en que termina el proyecto, en lugar de renombrarla.

#Microsegmentación de red

En una implantación madura de zero trust, la red se divide en microsegmentos. El servidor de base de datos, el servidor web, la caché y el almacenamiento de archivos se sitúan en segmentos separados con reglas de cortafuegos estrictas entre ellos. Una intrusión en un segmento no compromete automáticamente los demás.

#Bastionado del servidor del CMS con WAF y administración aislada

Un CMS es tan seguro como PHP-FPM, el árbol de archivos y el camino hacia la base de datos. Los textos comerciales del alojamiento no sustituyen a un sshd_config.

• Infraestructura inmutable. En un alojamiento basado en contenedores o imágenes, una imagen nueva reemplaza a la instancia en ejecución y nadie edita producción por SSH. En los planes de WordPress gestionado este patrón no existe; el sustituto es no subir plugins a mano, mantener un staging idéntico a producción y desplegar solo desde Git.
• WAF y protección DDoS. Un WAF delante del origen filtra el relleno de credenciales contra wp-login.php, las rutas conocidas de plugins y XML-RPC. Un WAF sin un producto y un conjunto de reglas identificados no es un objetivo de control.
• Backend no público. En entornos de alta seguridad, wp-admin no tiene registro DNS público. El acceso pasa por un túnel o por una VPN WireGuard, y el origen solo habla con el túnel.
• PHP y núcleo. WordPress 7.1 se publicó el 19 de agosto de 2026 y la 7.1.3, una versión de mantenimiento y seguridad, llegó el 6 de octubre de 2026. Bloquea xmlrpc.php salvo que un sistema legítimo lo necesite y limita la API REST sin autenticar a lo que el frontend lee de verdad.

#Superficie de ataque de un CMS headless frente a uno monolítico

Headless reduce la superficie PHP pública. No elimina la aplicación.

Monolito. Cada página ejecuta PHP contra la base de datos. Los plugins se enganchan a init. Los escáneres sondean /wp-content/plugins/ en busca de rutas conocidas. El WAF y las actualizaciones automáticas pasan a ser equipo de supervivencia.

Headless. La CDN sirve HTML, CSS y recursos sin intérprete en el borde y sin base de datos pública. wp-admin vive en una red privada o detrás de un proxy con verificación de identidad. La superficie restante está en el origen: REST, webhooks, cron y Application Passwords. Una Application Password filtrada y usada contra /wp-json/ sigue siendo un incidente.

En las compras corporativas, headless suele ser más fácil de defender, porque el borde público no tiene intérprete. El origen necesita los mismos controles que un monolito.

#Autenticación de la API en una arquitectura headless

En una configuración headless, la comunicación entre frontend y backend debe estar estrictamente autenticada:

• Tokens de corta duración con rotación: un token filtrado deja de servir pronto.
• Claves de API con alcance limitado: cada clave accede solo a los endpoints que necesita.
• Limitación de peticiones por endpoint, usuario e IP: frena la fuerza bruta y el scraping masivo.
• Firma de las peticiones: cada llamada lleva una firma criptográfica que impide manipularla en tránsito.

Si estás valorando el paso a una arquitectura desacoplada, lo tratamos en la guía de migración a Next.js y Astro.

#OWASP Top 10:2025 aplicado a WordPress

El OWASP Top 10:2025 es la lista que citan la mayoría de las licitaciones cuando piden desarrollo seguro. En una instalación de WordPress, las categorías aparecen en lugares concretos:

A03 es nueva en esta edición y encaja de lleno con WordPress. El directorio de plugins es la cadena de suministro, y el white paper de seguridad de WordPress afirma con claridad que la inclusión en el repositorio no garantiza que un plugin esté libre de vulnerabilidades.

#OWASP ASVS 5.0 como estándar de verificación en licitaciones de CMS

El Top 10 es una lista de concienciación. Cuando un contrato necesita requisitos comprobables, la referencia es el OWASP Application Security Verification Standard. La versión 5.0.0 se publicó el 30 de mayo de 2025 y se organiza en 17 capítulos, entre ellos V6 Authentication, V7 Session Management, V8 Authorization, V13 Configuration y V16 Security Logging and Error Handling.

ASVS define tres niveles. El nivel 1 reúne alrededor del 20 % de los requisitos y es la primera capa de defensa. OWASP indica que la mayoría de las aplicaciones deberían aspirar al nivel 2; cumplirlo supone implantar alrededor del 70 % de todos los requisitos (todos los de L1 y L2). El nivel 3 es para aplicaciones que necesitan el máximo grado de garantía.

De ahí salen dos reglas prácticas para un CMS corporativo. Escribe en el contrato “ASVS 5.0 nivel 2 para plugins e integraciones a medida” en lugar de “seguro según OWASP”. Y trata con cautela cualquier distintivo de certificación ASVS: OWASP declara que no certifica proveedores, verificadores ni software, y que no respalda las afirmaciones de certificación.

#Cómo gestiona el proyecto WordPress la seguridad del núcleo

El equipo de seguridad de WordPress está formado por más de 50 expertos de confianza, entre ellos desarrolladores principales e investigadores de seguridad, además de miembros patrocinados (wordpress.org/about/security). Las vulnerabilidades se comunican a través del programa de WordPress en HackerOne. Solo la última versión tiene soporte oficial, pero las correcciones se trasladan a ramas anteriores por cortesía, de modo que las webs con versiones antiguas reciben los arreglos críticos mediante actualizaciones automáticas. El equipo también coordina los despliegues de versiones y las mitigaciones en WAF con grandes proveedores de alojamiento y de seguridad.

El white paper de seguridad de WordPress, actualizado por última vez en septiembre de 2025, documenta los mecanismos por los que suele preguntar un revisor corporativo:

• actualizaciones automáticas en segundo plano para todas las versiones menores, que es como las correcciones de seguridad llegan a las webs sin que intervenga un administrador;
• contraseñas de usuario cifradas con bcrypt, con un prehash SHA-384 para salvar el límite de entrada de 72 bytes de bcrypt;
• Application Passwords, claves de restablecimiento y otros tokens con BLAKE2b a través de Sodium;
• nonces contra la falsificación de peticiones en sitios cruzados (CSRF), y API como wpdb::prepare(), wp_kses() y las funciones sanitize_*() para tratar entradas y salidas de forma segura.

Eso cubre el núcleo. El mismo white paper señala que los aproximadamente 50 000 plugins y 4500 temas del directorio los revisan voluntarios antes de publicarlos, sin garantía de que estén libres de vulnerabilidades. En los proyectos corporativos, el riesgo está en esa capa.

#Cómo evaluar y parchear plugins de WordPress

El hallazgo corporativo más frecuente en WordPress es un plugin sin responsable, mucho más que un zero-day en el núcleo.

• Inventario antes de instalar. Ningún plugin sin un responsable identificado, una vía de actualización y una entrada en el SBOM. Cada plugin de pago, envío o facturación es un proveedor en el sentido del artículo 21(2)(d) de NIS2.
• Revisión de código de todo lo que no llega del fabricante por un canal de actualización firmado. Los must-use plugins y el código de la agencia van en Git, no solo en el servidor.
• Seguimiento de vulnerabilidades. Patchstack, WPScan o los avisos por correo de los fabricantes. Un feed de CVE sin plazo de parcheo es decoración.
• Composer y npm. Los temas con proceso de compilación arrastran ficheros de bloqueo. Sus versiones entran en el mismo SBOM que los plugins PHP.
• Plazo de parcheo. Las correcciones críticas del núcleo y de la pasarela, dentro de un plazo documentado; las actualizaciones funcionales, primero por staging.

La capa de configuración (permisos de archivos, constantes de wp-config.php, reglas del servidor) se explica paso a paso en nuestra guía de seguridad y rendimiento de WordPress.

#Copias de seguridad cifradas del CMS y recuperación a un punto en el tiempo

Un plan de seguridad sin una restauración probada es un documento, no un control.

• 3-2-1. La copia del alojamiento es la primera, a menudo en la misma plataforma. La segunda va a un almacenamiento de otro proveedor o de otra región. La tercera queda fuera de línea o en una cuenta que las credenciales de producción no pueden borrar. Un ransomware que tiene wp-config.php y la contraseña del panel suele borrar también la copia oficial.
• Cifrado. Copias cifradas en reposo y en tránsito, con las claves guardadas aparte de las copias.
• RPO en tiendas. Una copia diaria basta para una web corporativa informativa. Una tienda con un RPO de 24 horas pierde pedidos que quizá ya han pasado al ERP o a contabilidad. Volcados horarios de la base de datos más los registros binarios, o la recuperación a un punto en el tiempo gestionada por el alojamiento, cierran esa brecha.
• Pruebas de restauración. Restaurar en staging una vez por trimestre, con cronómetro y acta escrita. El artículo 21(2)(c) de NIS2 y los cuestionarios de DORA piden exactamente ese registro.

#Riesgo de ingeniería social y registro de auditoría en el CMS

La mayoría de las tomas de control de wp-admin en proyectos de agencia empiezan con un correo, no con un exploit. Editores y contabilidad son objetivos porque ven pedidos, facturas y plugins de PDF. Un mensaje que avisa de un fallo en la exportación de facturas y pide iniciar sesión en una página falsa funciona cuando falta MFA. Una simulación de phishing por trimestre, usando la URL de acceso real como material didáctico, aporta más que una presentación anual.

Registro de auditoría. Cada instalación de plugin, cambio de rol y cambio de claves de la pasarela queda registrado con usuario, hora, IP y objeto. El registro sale de WordPress hacia syslog o un SIEM, para que un atacante con permisos de administrador no pueda borrarlo. El artículo 21(2)(i) de NIS2 y OWASP A09 señalan la misma carencia.

Cuando un freelancer deja el proyecto, su cuenta desaparece ese mismo día. Una entrada compartida en el gestor de contraseñas con una única contraseña de wp-admin para todos es lo contrario del control de acceso.

#Procedimiento de respuesta a incidentes

Cada organización necesita un plan de respuesta a incidentes documentado y ensayado que responda a estas preguntas:

• quién recibe el primer aviso y por qué canal;
• cómo se contiene el incidente;
• cómo se comunica dentro y fuera de la organización, incluida la alerta temprana de 24 horas cuando aplica NIS2;
• cómo se hace el análisis forense posterior;
• cómo se ajustan los controles para que no se repita.

#Superficie de ataque de los plugins de checkout y los webhooks de pago

Las páginas de catálogo pueden cachearse en el borde. El checkout, wc-ajax, los webhooks de pago y las URL de retorno no, y ahí está la superficie de ataque.

Cada pasarela de pago abre tres cosas: una redirección o un campo de pago alojado, un endpoint de webhook bajo /wc-api/ o /wp-json/ y, a menudo, un cron de estado. Sin verificación de firma en el webhook, un atacante marca pedidos como pagados. Stripe y PayPal firman sus webhooks. Un endpoint casero que da el pago por completado si llega un parámetro GET secreto es el hallazgo clásico.

Cuando los campos de la tarjeta se quedan en el proveedor de pago (campos alojados o componentes), el comercio suele permanecer en el alcance más reducido de autoevaluación de PCI DSS. En cuanto un plugin guarda el número de tarjeta o el CVC en wp_postmeta, esa premisa desaparece. Revisa las claves de post meta después de un pedido de prueba: un token más los cuatro últimos dígitos es normal; un número de tarjeta completo obliga a retirar la pasarela.

Las claves REST para wc/v3/orders con permisos amplios dan acceso completo a los datos de clientes. Una clave por sistema (ERP, puente con contabilidad, envíos), de solo lectura siempre que sea posible, con una lista de IP permitidas en el origen.

#Caché de objetos y registros de depuración en tiendas con pagos

Redis acelera la búsqueda de objetos. Sin filtrar, también guarda sesiones, transients y, a veces, respuestas de la pasarela.

• Lo que no debe quedarse en la caché: respuestas de la pasarela con tokens más allá de su TTL, sesiones de carrito con datos de pago, salida de depuración. Revisa las claves de sesión de WooCommerce antes de copiar un volcado de la caché a staging.
• debug.log. WP_DEBUG_LOG escribiendo en wp-content/debug.log en un servidor con listado de directorios es un registro público. Direcciones de correo, NIF y direcciones postales acaban ahí en cuanto una pasarela lanza una excepción. Escribe los registros fuera de la raíz del documento, rótalos y limita el acceso al personal de operaciones.
• Caché de página completa frente a carrito. Cachea solo las páginas de catálogo y de contenido. La cookie o la sesión del carrito debe activar la regla de exclusión. Un minicarrito cacheado que muestra los artículos de otro cliente es un incidente de confidencialidad.

#Servicios de seguridad WordPress corporativa de WPPoland

WPPoland refuerza instalaciones de WordPress y WooCommerce frente a los estándares que de verdad comprueban las compras corporativas: el alcance del SOC 2 o la ISO 27001 del proveedor de alojamiento, las medidas del artículo 21 de NIS2, zero trust en wp-admin, inventario de plugins y SBOM, superficie del checkout y de la pasarela. WPPoland no tiene informe SOC 2 ni certificado ISO propios; las pruebas que entregamos son operativas.

1. Seguridad en el código. Plugins e integraciones a medida revisados según OWASP Top 10:2025, con ASVS 5.0 como lista de requisitos cuando el contrato la pide.
2. Monitorización y revisión. Los escáneres de vulnerabilidades y de integridad de archivos funcionan de forma continua. La revisión humana cubre las actualizaciones de pasarelas, los cambios de rol y las pruebas de restauración.
3. Pruebas documentales. Plazo de parcheo, acta de restauración, lista de subencargados y un procedimiento de incidentes con la vía de 24/72 horas. Eso es lo que piden los cuestionarios de NIS2 y DORA.

El punto de partida es una auditoría de seguridad de WordPress. En cadenas de suministro reguladas se combina con una auditoría de cumplimiento normativo de la UE para WordPress.

#Cómo mantener seguro un CMS corporativo a largo plazo

Un CMS corporativo supera una revisión en 2026 cuando las pruebas del alojamiento, el modelo de la aplicación y la operación diaria encajan entre sí. SOC 2 e ISO 27001 filtran al proveedor. El artículo 21 de NIS2 da la lista de medidas y el artículo 23 el reloj de notificación. La Cyber Resilience Act impone obligaciones de notificación a los fabricantes de plugins y temas y da a los compradores las preguntas adecuadas. OWASP Top 10:2025 y ASVS 5.0 convierten el desarrollo seguro en requisitos comprobables.

La seguridad sigue siendo un ciclo: inventariar, reforzar, monitorizar, restaurar y demostrar. Sin ese ciclo, ningún certificado del alojamiento cambia el desenlace del próximo incidente. Si el CMS se está quedando atrás, documenta primero la instalación actual, el modelo de acceso, el proceso de actualización y los incidentes recientes. Así la revisión de seguridad parte de datos concretos.