Evaluación de riesgos de TI para WordPress: método sencillo
Evaluación de riesgos de TI para sitios WordPress: inventario de activos, amenazas, escala 1–3, medidas con responsable y un registro de ejemplo ya relleno.
También en: English Deutsch Français Italiano Polski Português Türkçe
Una evaluación de riesgos de TI para un sitio WordPress cabe en una sola página. Recoge lo que tiene, qué puede salir mal de forma realista, cuánto dolería y quién arregla qué y para cuándo. Con el método de cinco pasos que sigue puede tener un borrador esta misma tarde. El resultado es algo concreto que enseñar cuando un cuestionario de un cliente, una aseguradora o una autoridad de control le pregunte cómo eligió sus medidas de seguridad.
Por qué la evaluación de riesgos de TI va primero en el RGPD y en NIS2
El artículo 32, apartado 1, del RGPD exige medidas técnicas y organizativas apropiadas al riesgo, teniendo en cuenta el estado de la técnica y los costes. No se puede demostrar que una medida es apropiada sin haber dicho antes cuál es el riesgo. El artículo 5, apartado 2, añade que debe poder demostrar el cumplimiento, de modo que la evaluación tiene que quedar por escrito. Nuestro artículo sobre el artículo 32 del RGPD aplicado a WordPress trata las medidas en sí.
Si su empresa entra en el ámbito de la Directiva NIS2, la lista de medidas mínimas del artículo 21, apartado 2, empieza por la letra a): políticas de análisis de riesgos y de seguridad de los sistemas de información. Las obligaciones vinculantes proceden de la legislación nacional, así que consulte la ley de transposición de NIS2 de su país. Antes puede comprobar si NIS2 le afecta.
Este método es un punto de partida pragmático. No es una implantación de ISO 27001 ni una auditoría externa formal.
Paso 1: haga el inventario de activos (sitios, datos, cuentas, proveedores)
Un activo es cualquier cosa cuya pérdida o mal uso le perjudicaría. En una pequeña empresa típica, cuatro grupos cubren casi todo. Ponga primero los datos personales: ahí se aplica el RGPD y ahí es mayor el impacto.
| Grupo | Ejemplos típicos en WordPress |
|---|---|
| Datos personales | Entradas de formularios de contacto guardadas en la base de datos, pedidos de WooCommerce, cuentas de clientes, lista de boletín |
| Sitios | Sitio en producción, copia de staging, instalaciones de prueba olvidadas en subdominios |
| Cuentas | Administradores de WordPress, panel del hosting, SFTP/SSH, base de datos, registrador de dominio (DNS), contraseñas de aplicación |
| Proveedores | Proveedor de hosting, agencia o freelance, desarrolladores de plugins, almacenamiento de copias de seguridad, servicio de boletines |
Sea concreto. «Sitio web» es demasiado vago. «tienda.ejemplo.es, WooCommerce con unos 40 plugins, pedidos desde 2021» sí sirve. Si al hacer la lista encuentra una copia de staging olvidada o la cuenta de administrador de un antiguo freelance, anótelo. Solo con ese hallazgo ya merece la pena el ejercicio.
Paso 2: nombre amenazas realistas para cada activo
No necesita un catálogo de todos los ataques posibles. En sitios WordPress, cuatro grupos de amenazas cubren la mayoría de los incidentes reales:
- Plugins y temas vulnerables o abandonados. Alguien explota un fallo conocido antes de que usted actualice, o un fallo que nunca se corrige.
- Credenciales robadas o compartidas. Una contraseña reutilizada, una cuenta «admin» compartida o el acceso de una agencia que nadie dio de baja.
- Fallo del hosting o del servidor. Una caída, una pérdida de datos en el proveedor o un fallo en el propio software del servidor. Las vulnerabilidades PHP2Shell son un ejemplo: estaban en el entorno de ejecución de PHP, de modo que un WordPress totalmente actualizado seguía expuesto.
- Error humano. Una actualización defectuosa que rompe el proceso de compra, una página borrada o un editor al que se dio el rol de Administrador «solo un momento».
La amenaza de los plugins merece una valoración honesta. El proveedor Patchstack, en su informe State of WordPress Security in 2026, contabilizó 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025. El 91 % estaba en plugins y el 46 % no tenía corrección disponible por parte del desarrollador en el momento de la divulgación pública. En las vulnerabilidades más explotadas, la mediana ponderada del tiempo hasta la explotación masiva fue de 5 horas. Son cifras de un proveedor, pero explican por qué «plugin vulnerable» suele encabezar un registro de riesgos de WordPress.
Paso 3: valore probabilidad e impacto en una escala de 1 a 3
Use tres niveles y defínalos con palabras llanas, para que dos personas que valoren el mismo riesgo lleguen al mismo resultado.
Probabilidad
- Improbable en el plazo de un año
- Posible en el plazo de un año
- Esperable, o ya le ha ocurrido a usted o a un sitio similar
Impacto
- Molestia: arreglarlo lleva una hora y no afecta a datos
- Interrupción del servicio, o afectación limitada de datos no sensibles
- Datos personales expuestos, pagos afectados o parada del negocio
Multiplique los dos valores. Una puntuación de 1–2 significa aceptar, 3–4 planificar una medida y 6–9 actuar ya. Con esta escala no pueden darse las puntuaciones 5, 7 y 8, lo que mantiene las franjas bien separadas.
Valore el riesgo tal como está hoy. Un control que existe y funciona reduce la probabilidad. «Tenemos copias de seguridad» solo cuenta si alguien ha restaurado una. No añada decimales ni factores de ponderación. Una escala de 1 a 3 es burda a propósito: la falsa precisión hace que el registro parezca más científico de lo que es el conocimiento que lo respalda.
Paso 4: elija medidas, responsables y fechas de revisión
Para cada riesgo con puntuación de 3 o más, elija una o dos medidas concretas. «Mejorar la seguridad» no es una medida. «Activar la verificación en dos pasos para los cuatro administradores antes del 17 de noviembre» sí lo es. Ponga como responsable a una persona, no a «informática» ni a «la agencia», y fije una fecha.
Los artículos de profundidad tratan las medidas en sí. Vea cómo gestionar plugins vulnerables y copias de seguridad de WordPress que de verdad se restauran. Su registro de riesgos solo necesita recoger la decisión y enlazar a las evidencias.
Hay dos cosas más que deben figurar en cada fila. Primero, «aceptar» es una decisión válida para puntuaciones bajas, siempre que anote el motivo. Segundo, apunte el riesgo residual, es decir, la puntuación que espera una vez aplicada la medida. Si una medida no reduce la puntuación, probablemente no es la medida adecuada.
Ejemplo práctico: registro de riesgos de una pequeña tienda WooCommerce
El ejemplo siguiente corresponde a una tienda ficticia. Tiene un sitio WooCommerce, una copia de staging, dos empleados, una agencia externa y hosting compartido. «P» es la probabilidad, «I» el impacto y «Después» la puntuación residual esperada.
| Riesgo | P | I | Puntos | Medida | Responsable | Fecha | Después |
|---|---|---|---|---|---|---|---|
| Vulnerabilidad en un plugin (tienda, formularios) | 3 | 3 | 9 | Eliminar plugins sin usar, actualizaciones automáticas, revisión semanal de vulnerabilidades | Sara (propietaria) | 2026-11-10 | 3 |
| Contraseña de administrador reutilizada, sin 2FA | 2 | 3 | 6 | 2FA para todos los administradores, gestor de contraseñas | Sara | 2026-11-17 | 3 |
| Cuenta de administrador de la antigua agencia activa | 2 | 3 | 6 | Eliminar la cuenta, revocar contraseñas de aplicación | Tom (agencia) | 2026-11-06 | 3 |
| Caída del hosting, restauración nunca probada | 2 | 3 | 6 | Copia externa, prueba de restauración en staging | Tom | 2026-11-24 | 3 |
| Fallo del entorno PHP en el hosting | 2 | 3 | 6 | Pedir al hosting confirmación por escrito de que PHP está parcheado | Sara | 2026-11-06 | 3 |
| El personal borra productos o páginas | 2 | 2 | 4 | Rol Editor para el personal, conservar revisiones | Sara | 2026-12-15 | 2 |
| Entradas antiguas de formularios en la base de datos | 1 | 3 | 3 | Borrar entradas de más de 6 meses | Lena (oficina) | 2026-12-15 | 2 |
| Caída del servicio de boletines | 1 | 2 | 2 | Aceptar: lista exportada cada mes | Lena | 2027-05-03 | 2 |
Léalo de arriba abajo. Esta semana la tienda elimina la cuenta de la agencia y pregunta al hosting por PHP. Ambas tareas son baratas y llevan menos de una hora. La limpieza de plugins viene a continuación, la semana próxima, porque tiene la puntuación más alta. La 2FA y la prueba de restauración se programan dentro del mes.
Las filas de errores del personal y de formularios de contacto pueden esperar a diciembre. Sus puntuaciones son más bajas y, para los errores del personal, el trabajo de copias de seguridad de la cuarta fila ya ofrece una red de seguridad. La caída del boletín se acepta, con su motivo y una fecha de revisión. Todas las filas terminan en 3 o menos. Eso no significa que no pueda pasar nada: es un nivel de riesgo documentado y razonado.
Cómo mantener viva la evaluación de riesgos
Una evaluación de riesgos de TI que nunca se reabre acaba siendo la prueba de que dejó de mirar. Revísela cuando ocurra alguno de estos desencadenantes:
- Tras cualquier incidente o casi incidente, incluida una oleada de intentos fallidos de acceso o un plugin que tuvo que revertir
- Tras cambios importantes, como un plugin nuevo que trate datos personales, un nuevo hosting, una nueva agencia o el lanzamiento de una tienda
- Cuando un proveedor o un cliente sujeto a NIS2 le envíe un cuestionario de seguridad
- A intervalos fijos que usted elija, por ejemplo trimestral o anual. Es una decisión suya, no una norma legal
Dé al documento un número de versión y una fecha, y conserve las versiones antiguas. Un historial que muestre cómo una puntuación de 9 bajó a 3 tras aplicar una medida es una buena evidencia de responsabilidad proactiva. Nuestra guía sobre la documentación de auditorías de seguridad explica cómo encaja el registro con el resto de sus documentos.
El plugin de auditoría «Security Audit & Compliance» de secaudit.eu puede ayudar con el paso 2 y con cada revisión. Relaciona sus hallazgos con el art. 32 del RGPD y el art. 21 de NIS2 y los exporta como informe o CSV, que puede contrastar con su registro. Las decisiones del registro siguen siendo suyas; el plugin le aporta datos actualizados para tomarlas. → secaudit.eu
Su siguiente paso: copie la tabla de ejemplo, sustituya las filas por sus propios activos y fije la fecha de la primera revisión antes de cerrar el archivo.
FAQ
¿Necesito ISO 27001 para esto?
No. Este método es un primer paso práctico que puede aplicar con su propio equipo. ISO 27001 es una norma completa de sistema de gestión, y adoptarla más adelante es una decisión de negocio aparte, a menudo impulsada por grandes clientes.
¿Cuánto se tarda con un solo sitio?
Con un sitio de configuración conocida, un primer borrador cabe en una sesión de trabajo. La mayor parte del tiempo se va en el paso 1, localizando cuentas y proveedores. Las revisiones posteriores son mucho más rápidas, porque solo se actualiza lo que ha cambiado.
¿La agencia lo hace una vez o por cada cliente?
Cada cliente es el responsable del tratamiento de su propio sitio y es dueño de su evaluación de riesgos. La agencia puede preparar un borrador para que el cliente lo apruebe. Además, debería llevar un registro aparte para sus propios sistemas, como sus portátiles, su gestor de contraseñas y el acceso al hosting de los clientes. Su contrato de encargo del tratamiento debe describir quién hace qué.
Este artículo es información general, no asesoramiento jurídico.
Compruebe su propio sitio
Security Audit & Compliance es el plugin de WordPress de secaudit.eu: busca malware, spam oculto, archivos del núcleo modificados y código vulnerable, y relaciona sus hallazgos con el art. 32 del RGPD, el art. 21 de NIS2 y el OWASP Top 10.
Ver qué comprueba el plugin