Años después, el artículo 32 sigue sin ser opcional: lo que realmente significan las «medidas técnicas» en la práctica

Introducción

GDPR lleva años siendo exigible, y el Artículo 32 sigue siendo la disposición más citada en las principales multas. No los banners de consentimiento, ni los mecanismos de transferencia internacional. Seguridad. Las organizaciones que han tenido casi una década para implementar «medidas técnicas y organizativas apropiadas» siguen fallando en esto con suficiente frecuencia como para que los reguladores traten la seguridad inadecuada como la explicación predeterminada cada vez que ocurre una brecha.

Parte de la razón es que el Artículo 32 no se presenta como una lista de verificación. Nombra cuatro categorías de medidas de manera ilustrativa y deja que «apropiado» se juzgue según el riesgo, en lugar de especificar un estándar técnico fijo que las organizaciones puedan simplemente implementar una vez y archivar. Este artículo explica qué exigen realmente esas cuatro categorías en la práctica y por qué tratar el Artículo 32 como algo resuelto desde hace años es precisamente la suposición que los reguladores siguen encontrando falsa.

• Conclusión 1: El Artículo 32 menciona cuatro categorías ilustrativas de medidas, no una lista fija. Seudonimización y cifrado, resiliencia continua de los sistemas, restauración oportuna tras un incidente y pruebas regulares de efectividad.
• Conclusión 2: «Apropiado al riesgo» significa que el nivel cambia a medida que cambian los datos y el panorama de amenazas. Una medida que era adecuada para una actividad de tratamiento hace años no necesariamente sigue siéndolo hoy.
• Conclusión 3: Los fallos de seguridad dominan la aplicación del GDPR, no las deficiencias procedimentales. Las multas multimillonarias en 2026 siguen señalando medidas técnicas y organizativas inadecuadas como el fallo principal.
• Conclusión 4: El cifrado sin control de claves por parte del cliente cumple débilmente con la seudonimización. Si el encargado puede descifrar los datos tan fácilmente como el responsable, el valor protector del cifrado es limitado.
• Conclusión 5: El cuarto punto, probar regularmente la efectividad, es el que la mayoría de las organizaciones omite por completo. Implementar una medida una vez y no verificar nunca si sigue funcionando es una brecha común y frecuentemente sancionada.

Resumen Ejecutivo

El Artículo 32 del GDPR establece cuatro categorías ilustrativas de medidas técnicas y organizativas: seudonimización y cifrado; confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas de tratamiento; capacidad de restaurar la disponibilidad y el acceso a los datos rápidamente tras un incidente; y un proceso para probar y evaluar regularmente si esas medidas realmente funcionan. Ninguna de estas se satisface con una implementación puntual. Los patrones de aplicación hasta 2026 muestran que las principales multas se deben exactamente a brechas en estas categorías, sobre todo controles de acceso insuficientes, prácticas de cifrado débiles o la ausencia de una capacidad de respuesta a incidentes probada, más que a fallos novedosos o exóticos. Para los responsables de protección de datos y seguridad, la tarea práctica años después de la entrada en vigor de la regulación no es preguntar si el Artículo 32 se abordó una vez, sino si sigue cumpliéndose frente al riesgo actual.

Por Qué «Apropiado» Es un Objetivo en Movimiento, No un Estándar Fijo

El Artículo 32 evita deliberadamente nombrar tecnologías o configuraciones específicas, exigiendo en cambio que las medidas sean apropiadas al riesgo presentado por el tratamiento en cuestión. Esto hace que la disposición sea duradera ante los cambios tecnológicos, y también significa que el cumplimiento nunca es un logro puntual.

El Lenguaje Basado en Riesgos Hace Que el Nivel Cambie con los Datos y las Amenazas

Una medida considerada apropiada para una categoría de datos personales, tratada de cierta manera y frente a un panorama de amenazas determinado, no sigue siendo automáticamente adecuada cuando cualquiera de esos tres factores cambia. Tratar datos más sensibles, enfrentarse a adversarios más capaces o simplemente aumentar el volumen de tratamiento eleva lo que se considera «apropiado», incluso si nunca se eliminó o debilitó ninguna medida concreta.

Los Reguladores Interpretan «Apropiado» Según lo que Haría una Organización Razonable

Las decisiones de los reguladores evalúan si las medidas existentes se corresponden con lo que una organización razonable que gestiona ese tipo de datos, con ese nivel de riesgo, habría implementado, no si la organización tenía alguna medida de seguridad plausible. Este estándar premia a las organizaciones que pueden demostrar una evaluación actual y fundamentada del riesgo y la respuesta, en lugar de una política estática que nadie ha revisado.

Qué Exige Realmente Cada una de las Cuatro Categorías

El Artículo 32(1) menciona explícitamente cuatro categorías, y cada una ha fallado de formas que aparecen repetidamente en las decisiones de los reguladores.

Seudonimización y Cifrado que Realmente Limiten la Exposición

El cifrado cumple débilmente esta categoría si la entidad que almacena los datos cifrados también puede descifrarlos por defecto, porque la barrera protectora que debe ofrecer el cifrado se derrumba en cuanto esa misma entidad se ve comprometida o forzada. La seudonimización, de igual manera, debe separar realmente la identidad de los datos subyacentes, no solo cambiarles el nombre de una forma fácilmente reversible por cualquiera con acceso habitual.

Confidencialidad, Integridad, Disponibilidad y Resiliencia Continuas

Esta categoría es explícitamente continua: no se trata de «¿el sistema era seguro cuando se implementó?» sino de «¿sigue siendo confidencial, íntegro, disponible y resiliente de manera continua?». Las decisiones regulatorias que citan este punto suelen involucrar controles de acceso que se degradaron con el tiempo, vulnerabilidades sin parchear o debilidades arquitectónicas que existieron durante un largo periodo antes de que una brecha las expusiera.

Restauración Oportuna Tras un Incidente Físico o Técnico

Esta categoría plantea una pregunta operativa concreta: si los sistemas fallan o los datos dejan de estar disponibles, ¿qué tan rápido se puede restaurar el acceso? Una organización sin capacidad probada de recuperación ante desastres, o que nunca ha ensayado realmente la restauración desde sus copias de seguridad, no cumple este requisito de forma significativa, independientemente de lo que diga su documentación.

Pruebas y Evaluaciones Regulares de lo Implementado

Este es el punto que más se omite. Implementar cifrado, controles de acceso y un plan de recuperación ante desastres una vez, y no probar nunca si todo sigue funcionando como se espera, incumple el Artículo 32(1)(d) incluso si las otras tres categorías se abordaron correctamente al principio. Las pruebas regulares no son una diligencia opcional. Son un requisito independiente y explícito.

Por Qué Este Sigue Siendo el Artículo que Genera las Mayores Multas

Años después de la entrada en vigor del GDPR, el Artículo 32 sigue siendo la base principal de las grandes sanciones precisamente porque es continuo y no puntual, y porque las organizaciones suelen tratar las obligaciones continuas como si se completaran una sola vez.

Los Fallos de Seguridad, No las Brechas de Procedimiento, Generan las Mayores Sanciones

Las principales multas hasta 2026 siguen centradas en medidas técnicas y organizativas insuficientes tras una brecha, no en la documentación o la transparencia. Un regulador que investiga una brecha pregunta primero si existían y funcionaban medidas de seguridad apropiadas, porque esa respuesta determina si la brecha refleja un riesgo razonable o una brecha previsible.

Una Medida que Fue Suficiente en su Momento No Es Prueba de que lo Sea Ahora

Las organizaciones que implementaron medidas sólidas al principio a veces consideran esa implementación como prueba permanente de cumplimiento. El enfoque continuo del Artículo 32 implica que la pregunta relevante durante una investigación es el estado de las medidas en el momento del incidente, no su estado en la implementación inicial.

Cómo Construir un Programa de Artículo 32 que Resista el Paso de los Años

La respuesta práctica es tratar las cuatro categorías como compromisos operativos continuos y no como un proyecto terminado: verificar que el cifrado y la seudonimización realmente limiten la exposición y no sean fácilmente reversibles por un administrador habitual, confirmar que los controles de acceso y la integridad del sistema se monitorizan de forma continua y no solo una vez, probar la capacidad de recuperación ante desastres según un calendario real y no asumir que funciona, y documentar las pruebas como parte de la base de evidencia, ya que la cuarta categoría existe de forma independiente de las otras tres.

Cómo un Plano de Control de Datos Facilita el Cumplimiento Continuo del Artículo 32

Cumplir el Artículo 32 como obligación continua, y no como una implementación puntual, requiere una plataforma donde el cifrado realmente limite quién puede acceder a los datos, donde el acceso y la actividad del sistema se monitoricen de forma continua en todos los canales, y donde la capacidad de recuperación y prueba esté integrada y no ensamblada por separado.

El Data Control Plane de Kiteworks permite a los clientes gestionar sus propias claves de cifrado mediante un módulo de seguridad hardware, de modo que el cifrado limita la exposición de forma real y no depende de la capacidad de descifrado del encargado, y los registros de auditoría se anonimizan por defecto, añadiendo una capa genuina de seudonimización a los registros de actividad. La arquitectura de tenencia única, un dispositivo virtual reforzado y capas integradas de firewall y detección de intrusiones garantizan la confidencialidad, integridad y resiliencia continuas, mientras que las configuraciones integradas de alta disponibilidad y recuperación ante desastres, junto con la capacidad de migración de nodos para transiciones operativas, permiten la restauración oportuna tras un incidente. Kiteworks se somete a pruebas de penetración periódicas y auditorías anuales de sus propios controles, y cada acción en todos los canales, incluidos correo electrónico, uso compartido de archivos, APIs y agentes de IA, se registra en un registro de auditoría inalterable y sin limitaciones que se integra directamente con las herramientas SIEM, proporcionando a las organizaciones la base de evidencia continua que exige el Artículo 32(1)(d).

Las organizaciones que quieran comprobar si sus medidas técnicas y organizativas actuales resistirían una evaluación actualizada del Artículo 32 pueden solicitar una demo personalizada para ver cómo los controles de seguridad continuos y con evidencia se aplican a su propio entorno.