Seguridad del tratamiento (art. 32 GDPR): traducir el «estado del arte» a controles

El artículo 32 del GDPR no obliga a una organización a tener el producto de seguridad más caro del mercado. Tampoco acepta como defensa que exista una política de seguridad firmada, un certificado ISO 27001 colgado en la web o un proveedor que prometa «protección empresarial». Lo que pide es más incómodo: que el responsable y el encargado del tratamiento apliquen medidas técnicas y organizativas apropiadas al riesgo, teniendo en cuenta el estado de la técnica, los costes de aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento.

La diferencia parece semántica, pero cambia por completo la conversación entre el CISO y compliance. Una medida solo es defendible si puede explicarse qué riesgo trata, por qué es proporcionada, cómo funciona en la práctica y qué pruebas demuestran que sigue funcionando. El artículo 32 no es un catálogo cerrado de controles. Es una obligación de ingeniería, gobierno y evidencia.

Ahí está también su dificultad. Una organización puede cifrar bases de datos y seguir exponiendo información personal mediante cuentas privilegiadas, copias de seguridad mal protegidas o un proveedor sin capacidad real de recuperación. Puede disponer de MFA y no detectar durante semanas una intrusión con credenciales válidas. Puede superar una auditoría ISO 27001 y no saber restaurar sus sistemas críticos. La seguridad del tratamiento se juega en esas grietas, no en la portada del informe.

El artículo 32 convierte el riesgo en una obligación demostrable

El apartado 1 del artículo 32 enumera cuatro resultados que deben guiar el diseño de los controles: confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento. Añade dos exigencias operativas que suelen recibir menos atención: restaurar la disponibilidad y el acceso a los datos personales de forma rápida tras un incidente físico o técnico, y establecer un proceso para probar, verificar y evaluar regularmente la eficacia de las medidas.

El apartado 2 introduce una lógica deliberadamente basada en el riesgo. Al evaluar el nivel adecuado de seguridad deben considerarse, entre otros factores, los riesgos derivados de la destrucción, pérdida o alteración accidental o ilícita de datos personales, así como de la comunicación o acceso no autorizados. El texto menciona expresamente los riesgos que puede generar el tratamiento y el estado de la técnica. No dice que todas las empresas deban implantar los mismos controles, pero tampoco permite justificar cualquier carencia con un presupuesto limitado.

La pregunta correcta no es «¿tenemos cifrado?». Es «¿qué datos, frente a qué amenaza, en qué punto del ciclo de vida y con qué consecuencia para las personas protege este cifrado?». El inventario de controles debe estar conectado con el registro de actividades del artículo 30, el análisis de riesgos y, cuando proceda, la evaluación de impacto del artículo 35.

El artículo 32.3 recuerda además que la adhesión a un código de conducta aprobado conforme al artículo 40 o la certificación prevista en el artículo 42 puede utilizarse como elemento para demostrar el cumplimiento. No equivale a una exoneración. Una certificación no convierte en apropiada una medida que ya no responde al riesgo, ni desplaza la responsabilidad del responsable del tratamiento. El sello ayuda a ordenar la evidencia; no sustituye al juicio.

«Estado de la técnica» no significa comprar tecnología de moda

El estado de la técnica es una referencia dinámica. Una decisión razonable en 2021 puede resultar insuficiente en 2026 si han cambiado las amenazas, la arquitectura o la sensibilidad de los datos. Pero la expresión tampoco exige desplegar cualquier novedad comercial. Exige evaluar las capacidades de seguridad disponibles y justificar por qué se adopta —o no— una determinada medida.

Para un CISO, eso implica documentar al menos cinco preguntas por control:

• Qué riesgo aborda: por ejemplo, extracción de datos desde una cuenta de administrador, ransomware sobre servidores de producción o acceso indebido de un proveedor.
• Qué activos y tratamientos cubre: producción, desarrollo, copias, dispositivos de usuario, APIs, SaaS y soportes físicos no tienen necesariamente la misma protección.
• Qué nivel de eficacia se espera: impedir, detectar, contener, recuperar o dejar trazabilidad.
• Qué limitaciones tiene: una copia inmutable no evita el robo de datos; la tokenización no protege un sistema que conserva las claves junto a los tokens.
• Qué evidencia existe: configuración, registros, resultados de pruebas, tickets de remediación y aprobación del riesgo residual.

Este enfoque evita uno de los errores más habituales: confundir la existencia de una herramienta con la existencia de un control. Un EDR instalado no demuestra que todos los equipos estén cubiertos, que las alertas lleguen a un equipo operativo o que la organización pueda investigar una intrusión. Un sistema de gestión de identidades no demuestra que se revisen los privilegios ni que las cuentas huérfanas se desactiven a tiempo.

Cifrado y seudonimización: dos controles que no hacen el mismo trabajo

El artículo 32.1.a cita expresamente la seudonimización y el cifrado de datos personales. El texto no las presenta como soluciones universales ni establece un algoritmo concreto. Su valor depende del diseño técnico y del riesgo.

El cifrado protege principalmente la confidencialidad cuando el atacante no obtiene las claves. Por eso la evaluación debe cubrir el dato en reposo, en tránsito y, cuando sea técnicamente relevante, durante su uso. TLS bien configurado para una API no soluciona una base de datos accesible desde una red plana. El cifrado de disco de un portátil no impide que una sesión desbloqueada permita descargar miles de registros. Y cifrar una copia de seguridad con una clave almacenada en el mismo sistema reduce la protección a una formalidad criptográfica.

La gobernanza de claves merece un tratamiento separado. Hay que definir quién puede generar, custodiar, rotar, recuperar y revocar claves; cómo se separan las funciones; qué ocurre si el administrador del sistema también controla el almacén de claves; y cómo se demuestra que la rotación se ha producido. Las claves maestras embebidas en código, compartidas por varios entornos o accesibles desde una cuenta de servicio permanente son un fallo de control, no una peculiaridad técnica.

La seudonimización, por su parte, reduce la vinculación directa entre los datos y una persona, pero no convierte la información en anónima si existe información adicional que permite reidentificarla. El artículo 4.5 del GDPR define la seudonimización precisamente como un tratamiento en el que los datos ya no pueden atribuirse a una persona sin utilizar información adicional, siempre que esa información se mantenga separada y protegida. Esa separación debe ser real: controles de acceso independientes, gestión diferenciada de secretos y trazabilidad de las operaciones de reidentificación.

Un ejemplo operativo: una entidad financiera puede sustituir el identificador de cliente por un token en los entornos de pruebas. Si el fichero de correspondencia está en el mismo bucket, con la misma cuenta de servicio y con los mismos administradores, el diseño aporta menos protección de la que su nombre sugiere. La seudonimización debe modificar el riesgo y la exposición, no solo el aspecto de los campos.

Resiliencia: la disponibilidad también protege derechos

La disponibilidad suele aparecer en los planes de continuidad como una cuestión de negocio. Bajo el artículo 32, también es una cuestión de protección de datos. Si una persona no puede acceder a un servicio esencial, ejercer un derecho o recibir una prestación porque los sistemas han quedado inutilizados, la organización debe poder explicar su capacidad de recuperación.

El requisito de restauración rápida del artículo 32.1.c obliga a bajar del documento al cronómetro. ¿Cuál es el tiempo objetivo de recuperación para cada tratamiento crítico? ¿Cuál es la pérdida de datos tolerable? ¿La copia restaurada es íntegra, utilizable y suficientemente reciente? ¿Puede recuperarse sin volver a introducir el malware que provocó el incidente?

RTO y RPO no son conceptos mágicos. Una aplicación puede declarar un RTO de cuatro horas y tardar dos días en recuperar las dependencias que nadie había incluido en el plan: el proveedor de identidad, el sistema de gestión de claves, la conexión con un tercero o el servicio DNS. Por eso las pruebas deben ejecutarse sobre servicios completos y no solo sobre una restauración aislada de base de datos.

El ransomware ofrece una prueba sencilla de madurez. Una organización resiliente necesita, como mínimo, copias separadas del entorno de producción, protección contra borrado o modificación no autorizada, credenciales distintas, restauraciones periódicas y un procedimiento que determine qué datos personales se recuperan primero. La copia de seguridad no elimina la obligación de analizar una posible violación de seguridad de los datos personales. Si el atacante exfiltró información antes de cifrarla, restaurar los sistemas no resuelve la confidencialidad comprometida.

Esta conexión enlaza el artículo 32 con el artículo 33. Cuando una violación pueda entrañar un riesgo para los derechos y libertades de las personas, el responsable debe notificarla a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que tuvo constancia. El plazo no empieza cuando termina la investigación forense. La organización necesita capacidad para determinar con rapidez qué ocurrió, qué datos estaban afectados y qué riesgo existe, aunque la información inicial sea incompleta. El artículo 34 puede exigir además comunicar la violación a las personas afectadas cuando el riesgo sea alto.

Pruebas: el control que más evidencias exige y menos se simula

El artículo 32.1.d exige un proceso para probar, verificar y evaluar regularmente la eficacia de las medidas. No basta con realizar un test anual de penetración y archivarlo. La eficacia tiene dimensiones diferentes: configuración, cobertura, detección, respuesta, recuperación y mejora.

Una batería de pruebas razonable puede incluir:

• Pruebas técnicas: análisis de vulnerabilidades, validación de configuraciones, pruebas de segmentación, ejercicios de abuso de privilegios y tests de restauración.
• Pruebas de proceso: simulaciones de notificación, escalado de incidentes, revocación de accesos, respuesta ante pérdida de un dispositivo y gestión de un proveedor comprometido.
• Pruebas de resistencia: ejercicios de ransomware, indisponibilidad de un proveedor crítico o recuperación en una región alternativa.
• Verificación independiente: revisión interna con separación suficiente respecto del equipo que opera el control, auditoría externa o pruebas red team cuando el riesgo lo justifique.

El resultado útil no es «test superado». Es una conclusión verificable: qué escenario se ejecutó, qué alcance tuvo, qué evidencia se observó, qué fallos aparecieron, quién aceptó el riesgo residual y cuándo debe repetirse la prueba. Un informe sin remediación asignada es literatura corporativa.

Las métricas también deben evitar la ficción de precisión. El porcentaje de parches aplicados puede ocultar que el 2% pendiente corresponde a los servidores que procesan los datos más sensibles. El número de alertas cerradas dice poco si no se mide el tiempo de detección, el tiempo de contención y la calidad de la investigación. Para el artículo 32, una métrica debe relacionar el control con el daño que pretende evitar.

El solape con ISO 27001: útil, pero no automático

ISO/IEC 27001:2022 y el artículo 32 encajan bien porque ambos exigen un enfoque sistemático basado en riesgos. La norma aporta una estructura de sistema de gestión: alcance, evaluación y tratamiento del riesgo, objetivos, información documentada, auditoría interna, revisión por la dirección y mejora continua. Su Anexo A incluye controles relacionados con gestión de accesos, criptografía, seguridad de proveedores, continuidad y registro de actividad.

Pero la equivalencia no es automática. ISO 27001 certifica la conformidad del sistema de gestión dentro de un alcance determinado y frente a los criterios de la norma. El GDPR exige proteger datos personales y demostrar que las medidas son apropiadas para los riesgos de los tratamientos concretos. Puede existir un certificado con un alcance que excluya la plataforma cloud donde se almacenan los datos personales, o con una declaración de aplicabilidad que justifique controles no implantados por razones que no encajan con el tratamiento evaluado.

La conexión correcta es utilizar el sistema ISO como infraestructura de evidencia, no como respuesta final. El mapa de riesgos de seguridad de la información debe vincularse al inventario de tratamientos, a las categorías de interesados, a los datos tratados y a las consecuencias de una violación. La declaración de aplicabilidad debe poder explicar cómo cada control relevante reduce un riesgo de privacidad, y qué controles adicionales exige el análisis del GDPR.

Un ejemplo frecuente es la conservación de logs. ISO puede respaldar controles de registro y monitorización, pero el diseño debe respetar también los principios de minimización y limitación del plazo de conservación del artículo 5.1.c y e del GDPR. Guardar todos los eventos, durante años y sin una finalidad definida no se convierte en buena práctica por llamarse «seguridad». El registro debe ser suficiente para detectar e investigar, con acceso restringido y retención justificada.

NIS2 añade presión operativa, no sustituye al GDPR

La Directiva NIS2, en su artículo 21, exige a las entidades esenciales e importantes adoptar medidas técnicas, operativas y organizativas proporcionales para gestionar los riesgos de ciberseguridad. Entre ellas aparecen el análisis de riesgos, la gestión de incidentes, la continuidad de negocio, la gestión de crisis, la seguridad de la cadena de suministro, la seguridad en la adquisición y desarrollo, la evaluación de la eficacia, la higiene cibernética, el uso de criptografía y la autenticación multifactor cuando proceda.

El solape con el artículo 32 es evidente, especialmente en continuidad, proveedores, incidentes y pruebas. Pero el alcance jurídico no es el mismo. NIS2 protege la disponibilidad, autenticidad, integridad y confidencialidad de redes y sistemas de información frente a riesgos de ciberseguridad; el GDPR protege los derechos y libertades de las personas en relación con el tratamiento de datos personales. Un incidente puede activar ambas obligaciones, con autoridades, plazos y criterios distintos.

La directiva fija en su artículo 23 un régimen de notificación de incidentes significativos que incluye una alerta temprana en 24 horas desde que se tiene conocimiento, una notificación del incidente en 72 horas y un informe final, salvo que la legislación nacional de transposición concrete determinados aspectos. El GDPR, en cambio, utiliza el umbral de riesgo para los derechos y libertades y contempla el plazo de 72 horas del artículo 33. El mismo hecho puede requerir dos análisis paralelos. La solución no es elegir el regulador más conveniente, sino diseñar una matriz de clasificación que identifique qué datos, servicios, sistemas y obligaciones están implicados.

Para una entidad financiera europea, DORA complica y ordena a la vez este mapa. Su artículo 5 sitúa la responsabilidad última de la función de gestión de riesgos TIC en el órgano de dirección; los artículos 28 a 30 regulan la gestión del riesgo de terceros proveedores de servicios TIC; y el artículo 30.3 exige que determinados contratos incluyan derechos de acceso, inspección y auditoría. DORA se aplica desde el 17 de enero de 2025, por lo que en 2026 ya no es una promesa de cumplimiento futuro. Cuando un proveedor procesa datos personales, la revisión contractual debe cubrir simultáneamente DORA, el artículo 28 del GDPR y las necesidades de evidencia del artículo 32.

El proveedor no hereda la responsabilidad

El artículo 28 del GDPR exige que el encargado ofrezca garantías suficientes para aplicar medidas técnicas y organizativas apropiadas, y obliga a formalizar el tratamiento mediante contrato u otro acto jurídico. El responsable sigue siendo quien determina los fines y medios esenciales del tratamiento, aunque delegue infraestructura, soporte, análisis o alojamiento.

La evaluación de un proveedor no debe terminar con un cuestionario de 200 preguntas. Hay que identificar qué control opera realmente el proveedor y cuál sigue bajo responsabilidad de la entidad. En un servicio cloud, el proveedor puede proteger la infraestructura física y el hipervisor, mientras el cliente configura identidades, permisos, cifrado, logs, copias y reglas de red. El modelo de responsabilidad compartida no es una cláusula de exención; es una distribución de tareas que debe convertirse en controles comprobables.

Antes de contratar o renovar, el responsable debería poder responder a cuestiones concretas: ¿qué subencargados tienen acceso lógico a los datos? ¿Qué región y qué sistema de respaldo intervienen? ¿Quién conserva las claves? ¿Qué registros estarán disponibles durante una investigación? ¿Qué plazo de aviso ofrece el proveedor para un incidente? ¿Puede probar la restauración del servicio? ¿Cómo se eliminan los datos al finalizar el contrato? ¿Qué ocurre si el proveedor deja de operar?

Las certificaciones y los informes independientes pueden aportar evidencia, pero deben leerse con alcance y fecha. Un informe SOC 2 o una certificación ISO no demuestra que el servicio se haya configurado correctamente para esa entidad ni que cubra todas las interfaces utilizadas. El contrato debe permitir obtener información y realizar auditorías cuando el riesgo lo exija. Si la respuesta del proveedor es «nuestro certificado lo cubre», probablemente la pregunta no se ha contestado.

Privacidad desde el diseño: art. 25 antes que art. 32

El artículo 25 del GDPR exige protección de datos desde el diseño y por defecto. En la práctica, eso significa que los controles de seguridad no deberían añadirse cuando el sistema ya está en producción y los datos ya circulan por una docena de integraciones. La arquitectura determina qué incidentes son posibles y cuánto daño producen.

Minimizar datos, separar entornos, limitar permisos, establecer plazos automáticos de borrado, aislar los identificadores directos y restringir las exportaciones son decisiones de diseño con efecto de seguridad. También lo es decidir que un equipo de soporte vea un identificador de incidencia en lugar del historial completo del cliente. El artículo 32 protege el tratamiento que se ha diseñado; el artículo 25 ayuda a evitar que el diseño cree una superficie innecesaria.

Cuando el tratamiento pueda entrañar un alto riesgo, el artículo 35 exige una evaluación de impacto relativa a la protección de datos antes de iniciar el tratamiento. La DPIA no debe ser un documento de privacidad separado de la arquitectura. Para que sirva, debe incluir escenarios de amenaza, controles, riesgo residual, responsables y criterios de aceptación. Si el sistema usa decisiones automatizadas, datos biométricos, monitorización a gran escala o categorías especiales de datos, la conexión entre diseño, seguridad y derechos resulta especialmente difícil de fingir.

Qué debería poder enseñar una entidad en una inspección

La evidencia del artículo 32 debe permitir reconstruir una cadena lógica, no solo mostrar carpetas llenas de políticas. El expediente de un tratamiento relevante debería conectar, como mínimo:

1. Inventario y finalidad: qué datos se tratan, de quién, para qué, dónde y durante cuánto tiempo.
2. Escenarios de riesgo: pérdida, destrucción, alteración, acceso no autorizado, exfiltración e indisponibilidad, con sus consecuencias para las personas.
3. Decisión de controles: por qué se aplican cifrado, MFA, segmentación, seudonimización, monitorización, copias protegidas o controles de proveedor.
4. Responsabilidades: qué corresponde al responsable, al encargado, al proveedor cloud, al equipo de desarrollo y al propietario del proceso.
5. Pruebas: resultados de configuración, escaneos, ejercicios, restauraciones, revisiones de accesos y auditorías.
6. Excepciones y mejora: deficiencias abiertas, compensaciones, riesgo aceptado por quién y fecha de revisión.

Esta documentación sirve para más de una inspección. Permite decidir si un nuevo proveedor cambia el riesgo, si una migración cloud altera el alcance, si un incidente exige notificación y si la organización puede demostrar diligencia. La evidencia útil no es la que describe el control ideal, sino la que permite verificar el control real en una fecha determinada.

Los registros de actividad deben manejarse con cuidado. Registrar accesos privilegiados, cambios de configuración y exportaciones masivas suele ser esencial para detectar una violación, pero el propio log contiene información personal y puede convertirse en una fuente secundaria de riesgo. Deben definirse permisos, retención, integridad y mecanismos de consulta. El artículo 32 no autoriza a ignorar el artículo 5.

La decisión difícil: cuándo el control no es proporcional

La proporcionalidad no es una palabra para rebajar el presupuesto sin dejar rastro. Es un ejercicio de justificación. El artículo 32 obliga a tener en cuenta los costes de aplicación, pero los pone junto a la naturaleza, el alcance, el contexto, los fines y los riesgos del tratamiento. Un control caro puede ser proporcionado si el daño potencial es extremo; un control barato puede ser insuficiente si no cubre el escenario relevante.

Supongamos que una compañía almacena historiales médicos para prestar un servicio. Puede alegar que cifrar ciertos campos en uso es complejo y costoso. La respuesta profesional no es aceptar o rechazar la medida de forma automática. Hay que evaluar si la arquitectura puede reducir el acceso, si la segmentación y la seudonimización ofrecen protección equivalente, quién necesita descifrar los datos, qué ocurre ante una cuenta comprometida y qué evidencia sustenta la elección. El resultado puede ser una medida distinta, pero debe existir un razonamiento técnico y jurídico.

La aceptación del riesgo residual debe tener propietario y fecha. Los riesgos abiertos durante años, sin compensación y sin revisión, indican que la evaluación dejó de ser una herramienta de decisión. El estado de la técnica cambia; también cambian los proveedores, las vulnerabilidades, los tratamientos y el valor de los datos.

La prueba definitiva es la operación diaria

El artículo 32 se incumple con más frecuencia en los procesos rutinarios que en los grandes diseños: una cuenta privilegiada que nunca caduca, una copia que nadie ha restaurado, un subencargado no inventariado, un entorno de pruebas con datos reales, un parche crítico pospuesto sin compensación o un incidente que se comunica tarde porque nadie sabía quién debía decidir.

Por eso el CISO y el responsable de protección de datos necesitan una interfaz común. El primero aporta arquitectura, amenazas, controles y capacidad de respuesta. El segundo aporta derechos, finalidades, minimización, bases jurídicas y evaluación del riesgo para las personas. Ninguno puede resolver en solitario el artículo 32. La privacidad sin telemetría no puede estimar una brecha; la seguridad sin contexto de tratamiento no sabe qué activo merece prioridad.

La recomendación práctica es sencilla, aunque no cómoda: seleccionar los tratamientos de mayor riesgo, mapear sus dependencias técnicas y de terceros, probar los controles que realmente reducen el daño y documentar las decisiones que queden fuera del estándar. No se trata de construir un inventario ceremonial. Se trata de poder contestar, durante un incidente o una inspección, cuatro preguntas sin improvisar: qué datos estaban expuestos, qué barreras existían, por qué se consideraron adecuadas y qué se hará para evitar que vuelva a ocurrir.

El artículo 32 no premia la acumulación de herramientas. Premia una relación demostrable entre riesgo, control y resultado. En 2026, con GDPR, NIS2 y DORA presionando sobre los mismos equipos, esa disciplina deja de ser una cuestión de elegancia documental. Es la diferencia entre tener seguridad y poder demostrarla cuando el sistema falla.