Artículo 32 del RGPD y WordPress: qué es la «seguridad adecuada»

El artículo 32 del RGPD no menciona ningún plugin, ningún ajuste del servidor ni una longitud mínima de contraseña. Pide una seguridad adecuada al riesgo, y en la mayoría de los sitios WordPress eso se traduce en una lista breve y concreta: HTTPS en todo el sitio, software actualizado, accesos personales con autenticación de dos factores, copias de seguridad que de verdad ha restaurado alguna vez y controles periódicos. Si hace todo esto y puede demostrarlo, ya cubre buena parte de lo que el artículo 32 espera de un sitio WordPress típico.

Esta guía traduce el artículo 32, apartado 1, letras a) a d), en medidas concretas para WordPress, punto por punto. También trata las dos obligaciones que lo acompañan: documentar sus medidas (responsabilidad proactiva) y asegurarse de que su proveedor de hosting y su agencia hagan su parte.

RGPD y seguridad en WordPress: qué dice el artículo 32

El artículo 32 del RGPD obliga tanto al responsable del tratamiento (su empresa) como a cualquier encargado del tratamiento (por ejemplo, su hosting) a aplicar medidas técnicas y organizativas apropiadas. Qué es apropiado depende del estado de la técnica, de los costes de aplicación, de la naturaleza, el alcance, el contexto y los fines del tratamiento, y del riesgo para las personas cuyos datos trata.

A continuación, el artículo enumera cuatro elementos que esas medidas incluirán, «en su caso, entre otros»:

• a) la seudonimización y el cifrado de datos personales;
• b) la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios;
• c) la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida tras un incidente;
• d) un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas.

Detrás está el artículo 5, apartado 1, letra f): los datos personales deben tratarse con una seguridad adecuada. Y un sitio WordPress típico trata más datos personales de lo que su propietario imagina: cuentas de usuario, comentarios con nombre, correo electrónico y dirección IP, envíos de formularios de contacto, altas en el boletín, pedidos de WooCommerce y registros del servidor.

Un enfoque basado en el riesgo: estado de la técnica frente a costes

El artículo 32 se basa deliberadamente en el riesgo. Una web corporativa con un formulario de contacto, una tienda con miles de cuentas de clientes y un área de socios que guarda información de salud no necesitan el mismo esfuerzo, pero cada una necesita un nivel acorde con lo que podría salir mal. El artículo 32, apartado 2, enumera los riesgos que hay que ponderar: la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o el acceso no autorizados a ellos.

El «estado de la técnica» se entiende mejor como «lo consolidado y ampliamente disponible», no como «el producto más caro del mercado». HTTPS, las versiones de software con soporte y el inicio de sesión en dos factores para administradores son hoy estado de la técnica, y cuestan poco. Los costes pueden justificar que un blog pequeño funcione sin un cortafuegos de aplicaciones web de nivel empresarial. Rara vez justifican saltarse lo básico.

Artículo 32, apartado 1, letras a) a d): medidas para WordPress

La tabla relaciona cada letra con medidas habituales en WordPress y con las pruebas que conviene conservar.

a) Cifrado y seudonimización

Sirva todo el sitio exclusivamente por HTTPS, incluidos /wp-admin/ y todos los formularios, y añada HSTS cuando eso funcione de forma fiable. Las contraseñas no se cifran, sino que se guardan como hash, que es lo adecuado en su caso: desde WordPress 6.8, las contraseñas de los usuarios se almacenan con hash bcrypt.

Las copias de seguridad son la copia de sus datos personales que más se pasa por alto. Cífrelas y guárdelas lejos del servidor web. La seudonimización propiamente dicha es poco habitual en un sitio WordPress típico, pero hay pasos afines que reducen el riesgo: acorte las direcciones IP en la analítica y en los registros, y no conserve en la base de datos los envíos de formularios de contacto más tiempo del necesario. Los datos que ya no guarda no se pueden filtrar.

b) Confidencialidad, integridad, disponibilidad y resiliencia

Lo primero son las actualizaciones. Patchstack, una empresa de seguridad, contabilizó 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025, el 91 % de ellas en plugins. En las más explotadas, la mediana ponderada hasta la explotación masiva fue de cinco horas (informe de Patchstack). Active las actualizaciones automáticas donde encajen (el núcleo las ofrece para plugins y temas desde WordPress 5.5) y elimine los plugins que no use. Nuestra guía sobre plugins vulnerables explica cómo auditarlos.

El control de accesos es el segundo pilar: una cuenta personal por persona, el rol más bajo que sirva (Editor, Autor o Colaborador en lugar de Administrador) y autenticación de dos factores para cada administrador. El núcleo de WordPress no la incluye. Para proteger la integridad, elimine los editores de archivos del escritorio en wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Compare de vez en cuando los archivos del núcleo con las sumas de verificación oficiales (wp core verify-checksums con WP-CLI). Para la disponibilidad y la resiliencia, elija un hosting con recursos suficientes y monitorización. Ningún plugin puede absorber un ataque DDoS de gran envergadura; esa es tarea de una CDN o de un cortafuegos perimetral. La guía oficial de bastionado de WordPress recoge más ajustes del lado del servidor.

c) Restaurar la disponibilidad tras un incidente

Una copia de seguridad solo cuenta si puede restaurarla. Haga copias de los archivos y de la base de datos, guarde al menos una fuera del servidor y fuera del alcance de la cuenta de administrador de WordPress, y pruebe una restauración completa en un entorno de pruebas (staging). Anote cuánto tardó: es mucho más fácil defender que restauró «de forma rápida» con un tiempo medido que con una simple esperanza.

d) Verificar, evaluar y valorar con regularidad

El RGPD no fija una periodicidad, así que fije usted la suya y cúmplala. Un punto de partida razonable para una pequeña empresa: un análisis automático cada semana, una revisión de cuentas de usuario y plugins cada trimestre, una prueba de restauración dos veces al año y una revisión extra tras cada incidente o cambio importante. Anote lo que encontró y corrigió, con fechas.

El plugin Security Audit & Compliance de secaudit.eu puede cubrir parte de esas verificaciones: busca malware, archivos del núcleo modificados, plugins desactualizados y contraseñas débiles, relaciona sus hallazgos con el art. 32 del RGPD y muestra un resumen de cumplimiento en pantalla; los informes firmados (PDF, CSV) se incluyen en secaudit.eu Pro. Un análisis respalda su documentación; por sí solo no hace que un sitio cumpla la normativa.

Responsabilidad proactiva: documente lo que hace (art. 5, apartado 2)

Según el artículo 5, apartado 2, el responsable del tratamiento debe poder demostrar el cumplimiento. En la práctica, eso significa un documento de seguridad breve y vivo, no un archivador que nadie lee. Debería recoger:

• Un inventario: hosting, versión de WordPress, plugins, temas, servicios externos
• Quién tiene acceso, con qué rol y quién aprueba las cuentas nuevas
• Sus medidas para las letras a) a d), con la nota de riesgo que las justifica
• Un registro de actualizaciones y las fechas de análisis, revisiones de accesos y pruebas de restauración
• Su procedimiento ante incidentes, incluida la notificación de brechas en 72 horas
• Los contratos de encargo del tratamiento con sus encargados

Revise el documento una vez al año y siempre que el sitio cambie de forma significativa. Nuestra checklist de seguridad para WordPress es un buen punto de partida para el inventario.

Hosting y agencias: encargados del tratamiento según el artículo 28

Su hosting guarda la base de datos y las copias de seguridad. Una agencia o un freelance con acceso de administrador puede leer cualquier ficha de cliente. Ambos suelen actuar como encargados del tratamiento, y entonces necesita un contrato de encargo con cada uno conforme al artículo 28. Ese mismo artículo establece que solo puede recurrir a encargados que ofrezcan garantías suficientes de aplicar medidas técnicas y organizativas apropiadas, y que el contrato debe obligarles a adoptar las medidas exigidas por el artículo 32.

Haga preguntas concretas en lugar de fiarse de una plantilla. ¿Dónde se guardan las copias y durante cuánto tiempo? ¿Es obligatorio el inicio de sesión en dos factores en el panel del hosting y en las cuentas de la agencia? ¿Con qué rapidez le avisarán de un incidente de seguridad? Cuando termine el contrato con una agencia, elimine sus cuentas y cambie las credenciales compartidas ese mismo día.

Las infracciones de los artículos 25 a 39, incluido el artículo 32, pueden sancionarse con multas de hasta 10 millones de euros o el 2 % del volumen de negocio anual global, si esta cifra es superior (art. 83, apartado 4, letra a). Aun así, lo más probable es que necesite su documentación después de un incidente, cuando la autoridad le pregunte qué medidas tenía implantadas.

Preguntas frecuentes

¿Exige el artículo 32 un plugin de seguridad concreto?

No. Exige medidas apropiadas, no productos. Un plugin puede ayudar con algunas, como el inicio de sesión en dos factores o los análisis, pero las actualizaciones, las copias de seguridad, las revisiones de accesos y los contratos forman igualmente parte de ellas.

¿Se aplica el artículo 32 a un sitio pequeño sin cuentas de usuario?

Sí, en cuanto el sitio trate datos personales, por ejemplo envíos de formularios de contacto, comentarios o registros del servidor con direcciones IP. Las medidas se ajustan al riesgo.

¿Basta con HTTPS para la letra a)?

No. HTTPS protege los datos en tránsito. Las copias de seguridad, las exportaciones y la base de datos del servidor necesitan su propia protección.

Este artículo es información general, no asesoramiento jurídico.