El EDPB deja una pista incómoda para 2026: más decisiones OSS amistosas, pero con el artículo 32 cada vez más cerca del consejo

Hay una señal curiosa en la base pública del EDPB que merece más atención de la que suele recibir. No es una gran multa. No es un comunicado con fanfarria. Es algo más sutil y, para muchas empresas, más incómodo: varias decisiones finales del mecanismo One-Stop-Shop publicadas por el Consejo Europeo de Protección de Datos muestran cierres por amicable settlement, pero una de ellas, la irlandesa EDPBI:IE:OSS:D:2025:1678, fechada el 14 de marzo de 2025 y enlazada por el EDPB en julio de 2026, combina tres artículos que rara vez aparecen juntos por casualidad: artículo 32 del GDPR sobre seguridad del tratamiento, artículo 5 sobre principios y artículo 6 sobre licitud.

Traducción al castellano llano: ya no basta con que privacidad y ciberseguridad se saluden en el pasillo. El regulador está mirando casos donde la seguridad técnica, la base jurídica y los principios de tratamiento parecen estar entrelazados. Y cuando eso ocurre, el problema deja de ser un fallo del SOC o un ticket mal cerrado por TI. Pasa a convertirse en un asunto de gobernanza, trazabilidad de decisiones y responsabilidad del controlador.

La propia página de resultados del EDPB no ofrece narrativa extensa; ofrece pistas. Y esas pistas, leídas en 2026, encajan con una tendencia bastante evidente en supervisión europea: las autoridades de protección de datos no quieren discutir la seguridad como si fuera un apéndice técnico. La están llevando al núcleo del cumplimiento material del GDPR. Eso cambia cómo deben prepararse los DPO, los CISO, los equipos legales y, sí, también el consejo. Porque el artículo 32 nunca ha sido solo un checklist de cifrado y contraseñas. El problema es que muchas organizaciones lo siguen tratando exactamente así.

Qué ha publicado realmente el EDPB y por qué no conviene despacharlo como “otro caso irlandés”

La búsqueda pública del EDPB muestra, entre otras, estas decisiones finales OSS:

EDPBI:IE:OSS:D:2025:1678, de 14 de marzo de 2025, con referencias jurídicas principales a los artículos 32, 5 y 6 del GDPR y resultado de amicable settlement.

EDPBI:IE:OSS:D:2024:1548, de 10 de diciembre de 2024, con foco en los artículos 12 y 15 sobre transparencia y derecho de acceso, también cerrada amistosamente.

EDPBI:IE:OSS:D:2024:1551, de 12 de diciembre de 2024, sobre artículos 12 y 15 a 22, es decir, buena parte del bloque de derechos del interesado, igualmente cerrada por acuerdo amistoso.

EDPBI:IE:OSS:D:2024:1552, también de 12 de diciembre de 2024, nuevamente vinculada a artículos 12 y 15, otra vez con el mismo desenlace.

El detalle llamativo no es solo que existan decisiones OSS con solución amistosa. Eso ya lo sabíamos. Lo relevante es la mezcla de materias y el momento. En 2026, con la aplicación de DORA ya asentada desde el 17 de enero de 2025 en el sector financiero, con NIS2 transpuesta de forma desigual pero operativamente ya presente en agendas de consejo y con una presión regulatoria creciente sobre resiliencia digital, el artículo 32 del GDPR ha dejado de vivir en una burbuja.

Si una decisión OSS irlandesa conecta seguridad del tratamiento, principios del artículo 5 y licitud del artículo 6, el mensaje para el mercado no es pequeño. Significa que una debilidad de seguridad puede leerse también como un fallo de minimización, limitación de la finalidad, integridad y confidencialidad o incluso de ausencia de base legal suficiente si el tratamiento no estaba correctamente sostenido. A los reguladores europeos les gusta cada vez menos compartimentar. Las empresas, en cambio, siguen organizándose por silos. Mala combinación.

El verdadero mensaje: el artículo 32 ya no se interpreta de forma aislada

El artículo 32 GDPR exige aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Hasta ahí, la frase que todo el mundo cita. Lo que se olvida con demasiada frecuencia es lo que viene dentro del propio artículo: se deben tener en cuenta el estado de la técnica, los costes de aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento, así como los riesgos para los derechos y libertades de las personas físicas. El artículo menciona expresamente, entre otras medidas, la seudonimización y el cifrado, la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia permanentes, la capacidad de restaurar disponibilidad y acceso a los datos de forma rápida en caso de incidente físico o técnico, y un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas.

Aquí está el quid. El artículo 32 no habla solo de seguridad “en abstracto”. Habla de seguridad adecuada al tratamiento concreto. Eso obliga a unir arquitectura, inventario de datos, legitimación, plazos de conservación, terceros, continuidad, logging, restauración y revisión periódica. En otras palabras: seguridad con contexto de negocio y de cumplimiento.

Por eso la combinación con el artículo 5 importa tanto. El artículo 5.1.f exige integridad y confidencialidad. El artículo 5.2 introduce el principio de accountability: el responsable no solo debe cumplir; debe poder demostrarlo. Y el artículo 6 exige que el tratamiento tenga una base jurídica válida. Si una autoridad examina un caso y enlaza 32, 5 y 6, la pregunta regulatoria seguramente no es “¿tenían antivirus?”. La pregunta es bastante más seria: “¿por qué estaban tratando estos datos, con qué base, durante cuánto tiempo, con qué medidas y dónde está la evidencia de que alguien evaluó el riesgo de forma realista?”.

Ese es el punto que muchos comités de dirección todavía esquivan. Creen que la seguridad es una cuestión del CISO y la base jurídica un asunto del DPO o del área legal. Sobre el papel queda ordenado. En una investigación transfronteriza, esa separación puede resultar casi cómica.

Las decisiones amistosas no son una noticia blanda. Son una radiografía del tipo de incumplimiento que el regulador puede reconducir sin renunciar al expediente

La expresión amicable settlement induce a error. Suena a cierre cómodo, a apretón de manos y aquí paz y después gloria. No necesariamente. En el contexto de decisiones OSS, un acuerdo amistoso no borra el hecho de que ha habido una reclamación, cooperación entre autoridades concernidas y revisión regulatoria. Lo que señala es que el caso se ha resuelto sin una batalla sancionadora clásica. Y eso, para el mercado, tiene dos lecturas.

La primera es positiva: algunas autoridades parecen aceptar remedios, compromisos o correcciones operativas cuando consideran que reparan de forma suficiente el problema para el interesado. La segunda es más dura: si el regulador logra extraer cambios materiales sin necesidad de montar una gran sanción pública, está obteniendo cumplimiento de forma eficiente. Y cuando ese patrón se normaliza, la presión se desplaza a la capacidad de la empresa para demostrar que corrigió bien y a tiempo.

Esto importa especialmente en Irlanda porque la Data Protection Commission actúa como autoridad principal para muchas grandes plataformas y grupos multinacionales establecidos allí. Bajo el mecanismo de ventanilla única del GDPR, las decisiones irlandesas no son un asunto doméstico si intervienen autoridades concernidas de otros Estados miembros. La propia ficha del EDPB para la decisión 1678 enumera una larga lista de CSA, desde Bélgica y Francia hasta Noruega, Islandia y Liechtenstein. No es un expediente local de interés folclórico. Es cooperación regulatoria paneuropea.

Y hay otro dato que no conviene pasar por alto: la decisión es de marzo de 2025, pero el PDF aparece en la ruta de archivos del EDPB con fecha de julio de 2026. Eso sugiere un desfase entre fecha de decisión y disponibilidad pública centralizada. Para las empresas, la lección es bastante práctica: si esperas a que un caso llegue a titulares para extraer conclusiones, vas tarde. El aprendizaje útil suele estar disperso entre decisiones, repositorios y documentación que emerge meses después.

Por qué el cruce entre seguridad, principios y licitud puede ser peor que una brecha notificada

Una brecha de datos personales activa automáticamente el radar porque el artículo 33 GDPR obliga al responsable a notificarla a la autoridad de control sin dilación indebida y, cuando sea posible, no más tarde de 72 horas después de haber tenido constancia de ella, salvo que sea improbable que constituya un riesgo para los derechos y libertades. El artículo 34 añade, cuando proceda, la comunicación a los afectados.

Eso está interiorizado. Lo que muchas empresas aún no han interiorizado es que se puede entrar en problemas serios sin que el caso se agote en el esquema clásico de “incidente-notificación-remediación”. Si el regulador detecta que el tratamiento en sí estaba mal montado, la conversación cambia de carril. Ya no discutes solo si el incidente se contuvo. Discutes si estabas tratando demasiado, demasiado tiempo, con una base jurídica débil, con controles desproporcionadamente pobres para el riesgo real, o sin un proceso creíble de revisión de eficacia. Ese terreno es más peligroso porque afecta a la legitimidad estructural del tratamiento, no solo a un fallo puntual.

Pongamos un ejemplo muy común en 2026: una empresa conserva datos de clientes y empleados en varios entornos SaaS, replica ficheros a sistemas de analítica y entrena automatizaciones internas que tocan información personal sin una gobernanza fina de finalidades. Si además los accesos privilegiados están sobredimensionados, no hay segmentación clara y las revisiones de permisos se hacen a golpe de auditoría anual, una autoridad podría leer el problema no solo como deficiencia técnica del artículo 32. También como un fallo de minimización del artículo 5.1.c, de limitación del plazo de conservación del artículo 5.1.e o incluso de falta de base jurídica precisa del artículo 6 para determinados usos secundarios. La seguridad, de repente, deja de ser el síntoma y se convierte en la prueba de que el tratamiento estaba mal diseñado.

Ahí es donde el GDPR y el lenguaje de resiliencia digital empiezan a tocarse sin necesidad de mezclarse formalmente. DORA regula resiliencia operativa digital en entidades financieras, no protección de datos. NIS2 impone medidas de gestión de riesgos de ciberseguridad y gobernanza a entidades esenciales e importantes, no decide bases jurídicas de tratamiento. Pero en la práctica, cuando un supervisor sectorial y una autoridad de protección de datos miran la misma arquitectura, la empresa no puede mantener dos relatos incompatibles. Si dices al supervisor financiero que tu inventario de activos críticos y tus dependencias están controlados, y a la vez no puedes explicar a la autoridad de datos qué tratamientos haces, con qué finalidades y dónde están los datos, alguien está vendiendo una versión optimista de la realidad.

El artículo 32 exige pruebas, no declaraciones solemnes

La parte más subestimada del artículo 32 está en el apartado 1.d y en el apartado 2. El primero exige un proceso para verificar, evaluar y valorar regularmente la eficacia de las medidas técnicas y organizativas. El segundo obliga a tener en cuenta, al evaluar la adecuación del nivel de seguridad, los riesgos que presente el tratamiento, en particular como consecuencia de destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o acceso no autorizados.

Si lo aterrizas en una auditoría real, eso significa que las políticas bonitas sin evidencia operativa valen poco. Lo que suele convencer más a una autoridad es otra cosa: registros de revisiones de acceso, evidencias de restauración probada, resultados de ejercicios de continuidad, trazabilidad de parches críticos, criterios documentados de clasificación de datos, pruebas de borrado, matrices de retención, decisiones de aceptación de riesgo firmadas, justificación de excepciones y revisiones post-incidente con responsables y fechas.

La ironía aquí es conocida por cualquiera que haya sobrevivido a un comité de riesgos: muchas organizaciones generan miles de páginas de política y poquísimas pruebas de eficacia. Les encanta afirmar que aplican un enfoque basado en riesgo. Pregunta por la última vez que probaron restauración de datos sensibles desde una copia segregada y el silencio se vuelve muy elocuente.

El EDPB no necesitaba escribir un manifiesto para mandar este mensaje. Basta con que en una decisión OSS aparezcan juntos los artículos 32, 5 y 6. El profesional de compliance que no vea la relación tiene un problema de lectura. El consejo que no vea la implicación tiene un problema más caro.

Lo que cambia en 2026 para DPO, CISO y asesoría jurídica

En muchas empresas europeas, 2025 fue el año de aterrizar DORA, reforzar reporting de incidentes y revisar proveedores TIC críticos o relevantes. En 2026, la tentación es pensar que privacidad puede volver a su carril tradicional de cláusulas, derechos y transferencias. Sería un error de calendario.

Primero, porque el repositorio del EDPB sigue mostrando que el mecanismo OSS está produciendo decisiones sobre materias que van desde derechos del interesado hasta seguridad y licitud. Segundo, porque la aplicación práctica del GDPR está siendo cada vez más probatoria: menos discurso de principios abstractos y más exigencia de evidencias concretas. Tercero, porque la intersección entre datos, IA interna, automatización de procesos y tercerización tecnológica ha multiplicado los tratamientos secundarios difíciles de defender si nadie ha hecho un trabajo serio de mapeo, necesidad y proporcionalidad.

Para el DPO, esto obliga a salir del guion administrativo. El DPO que solo revisa textos informativos y contratos de encargo llega tarde al problema real si no está sentado en la mesa donde se deciden arquitectura, uso secundario de datos, retención y controles compensatorios. Para el CISO, la consecuencia es igual de clara: no puede presentar la seguridad como una capa neutra desligada de qué datos se tratan y por qué. Y para la asesoría jurídica interna, la vieja comodidad de separar “cumplimiento legal” de “seguridad técnica” se ha vuelto difícil de sostener en expedientes que cruzan artículo 6 con artículo 32.

Una pregunta incómoda que conviene hacer ya: ¿tu registro de actividades del artículo 30 sirve para algo más que para sobrevivir a una auditoría documental? Si no enlaza sistemas, finalidades, categorías de datos, bases jurídicas, destinatarios, transferencias, plazos de conservación y medidas de seguridad de forma utilizable, probablemente no. Y si no sirve, tampoco ayuda cuando una autoridad te pregunte por qué ese tratamiento concreto merecía esas medidas concretas.

El patrón irlandés también habla de derechos del interesado. Y eso enlaza con seguridad más de lo que parece

Las decisiones 1548, 1551 y 1552, todas de diciembre de 2024, remiten sobre todo a los artículos 12 y 15, y una de ellas se extiende hasta el 22. Es decir: transparencia, acceso, rectificación, supresión, limitación, portabilidad, oposición y decisiones automatizadas. A primera vista parece otro universo regulatorio distinto del artículo 32. No lo es tanto.

Una empresa que no controla bien dónde residen los datos, quién accede a ellos, qué versiones existen, qué sistemas los replican y qué lógica automatizada los usa suele fallar también al responder derechos. No es casualidad. La incapacidad de localizar y gobernar datos es el hilo común. Por eso tantos proyectos de cumplimiento fracasan por diseño organizativo: se encargan como un ejercicio legal cuando en realidad son una disciplina de arquitectura de información y control operativo.

El artículo 12 GDPR exige facilitar el ejercicio de derechos de forma concisa, transparente, inteligible y de fácil acceso. El artículo 15 da derecho de acceso a los datos y a información sobre fines, categorías, destinatarios, plazos de conservación y lógica aplicada, entre otros elementos. Si una compañía no puede responder con precisión porque su ecosistema tecnológico es una suma de adquisiciones, SaaS duplicados, carpetas compartidas y automatizaciones ad hoc, ese desorden no solo complica los derechos. También revela debilidad de control. De nuevo: seguridad y derechos no viven en edificios separados.

La decisión 1551, al citar del 15 al 22, resulta especialmente reveladora para 2026, cuando tantas empresas están acelerando proyectos de IA interna, scoring, clasificación automatizada o asistentes que consumen grandes volúmenes de datos personales. Si no has revisado cómo se ejercen rectificación, oposición o supresión cuando esos datos alimentan flujos automatizados, probablemente estás acumulando deuda regulatoria. Y esa deuda no se paga con una actualización de la política de privacidad un viernes por la tarde.

Qué deberían revisar ahora las empresas si no quieren descubrir el problema a través de una reclamación

No hace falta esperar a una gran resolución doctrinal del EDPB para actuar. La combinación de artículos visible en las decisiones publicadas ya permite identificar áreas de revisión muy concretas.

Primero, tratamientos con seguridad “heredada”. Son esos procesos que nacieron hace años, cambiaron de sistema, de proveedor y de finalidad varias veces, pero siguen protegidos con controles diseñados para otro contexto. Si el riesgo aumentó y las medidas no evolucionaron, el artículo 32 queda expuesto.

Segundo, usos secundarios de datos con base jurídica difusa. Aquí entran analítica interna agresiva, reutilización de datos de atención al cliente para entrenamiento de herramientas, consolidación de historiales en proyectos de eficiencia o modelos de prevención de fraude mal delimitados. Si la base del artículo 6 no está sólidamente definida y documentada, la seguridad robusta no arregla el defecto de origen.

Tercero, retención que nadie cuestiona. El artículo 5.1.e sobre limitación del plazo de conservación lleva años en el reglamento y sigue siendo uno de los puntos más flojos en la práctica. Cuantos más datos innecesarios conservas, mayor superficie de exposición y más difícil justificar la proporcionalidad de los controles.

Cuarto, pruebas insuficientes de eficacia. El regulador no necesita encontrar un colapso total para concluir que tus medidas no eran apropiadas. Basta con ver que no verificas regularmente su eficacia o que las revisiones son tan superficiales que apenas sirven de coartada documental.

Quinto, mala coordinación entre respuesta a incidentes y evaluación de privacidad. Un incidente que afecta a datos personales no se gestiona bien si el equipo técnico tarda en identificar categorías de datos afectadas, número aproximado de interesados, sistemas implicados, terceros afectados y capacidad de restauración. El reloj de 72 horas del artículo 33 no perdona la desorganización.

Implicaciones para entidades financieras españolas

Aunque las decisiones citadas proceden del mecanismo OSS con liderazgo irlandés, las entidades financieras españolas harían mal en leerlas como material ajeno. En 2026 conviven en su agenda, como mínimo, GDPR, DORA y las obligaciones nacionales y europeas de ciberseguridad que derivan del perímetro NIS2 según transposición y sector. Eso produce un efecto muy concreto: la misma deficiencia operativa puede interesar a varios supervisores, con preguntas distintas pero basadas en hechos parecidos.

En banca, seguros, pagos y fintech, tres frentes exigen atención inmediata. El primero es la coherencia entre clasificación de servicios críticos bajo DORA y mapeo de tratamientos personales bajo GDPR. Si un servicio es crítico para la continuidad operativa, pero nadie puede describir con precisión qué datos personales trata y con qué medidas, la organización está gestionando dos inventarios divorciados. Mal asunto.

El segundo frente es el de terceros TIC. DORA impone disciplina fuerte de gestión de riesgo de terceros; el GDPR, por su parte, exige contratos de encargo conforme al artículo 28 cuando corresponda y control suficiente sobre las operaciones del encargado. Si la cadena SaaS y subencargados es opaca, el riesgo ya no es teórico. Una reclamación de acceso o un incidente de seguridad puede revelar de golpe que el mapa contractual, técnico y de datos no coincide.

El tercer frente es el gobierno de incidentes. Las entidades financieras ya tienen flujos de escalado, umbrales y reporting más maduros que otros sectores. Precisamente por eso se les exigirá más coherencia entre el relato de resiliencia operativa y el relato de protección de datos. Si comunicas a un supervisor financiero que el impacto operativo fue limitado, pero luego reconoces a la autoridad de protección de datos que hubo exposición relevante de datos por controles de acceso deficientes, la divergencia no pasará desapercibida.

Para entidades españolas con operaciones paneuropeas, la ventanilla única sigue siendo crítica. No porque simplifique mágicamente la vida, sino porque concentra la interlocución principal mientras mantiene la mirada de autoridades concernidas de múltiples jurisdicciones. Eso obliga a preparar expedientes internos que soporten escrutinio multinacional, no solo la costumbre local del supervisor más cercano.

La tentación de trivializar el “amicable settlement” es un error estratégico

Algunas compañías ven estos cierres amistosos y respiran aliviadas. No hay gran sanción pública, luego el daño reputacional parece menor. Esa lectura es corta. Lo que de verdad deberían preguntarse es otra cosa: ¿qué vio la autoridad para considerar necesario abrir, coordinar y cerrar formalmente el caso? Si la respuesta tiene que ver con arquitectura de datos, legitimación, seguridad o derechos mal resueltos, el aprendizaje es más valioso que el titular de multa que no llegó.

Hay además una razón práctica para tomárselo en serio. Los expedientes amistosos pueden marcar expectativas de corrección que luego las autoridades trasladen de forma tácita a otros casos. No siempre hace falta una guía formal del EDPB para que se consolide una línea de exigencia. A veces basta con una suma de decisiones, preguntas recurrentes y cooperación entre autoridades. Es menos vistoso que una megaresolución. También más difícil de detectar para quien solo sigue los titulares.

En 2026, con el ecosistema regulatorio europeo saturado de obligaciones de resiliencia, cadena de suministro, gobernanza de IA y ciberseguridad, muchas empresas están desesperadas por clasificar cada problema en una casilla distinta. Privacidad por un lado. Seguridad por otro. Continuidad en otro comité. Legal en una cuarta carpeta. El regulador, mientras tanto, hace justo lo contrario: conecta hechos. Suele tener razón.

Lo que un consejo debería pedir mañana mismo, no en la próxima crisis

Si este tipo de decisiones te parecen demasiado técnicas para llegar al consejo, plantéalo así: una deficiencia de seguridad vinculada a principios del artículo 5 y base jurídica del artículo 6 no es un fallo técnico; es un fallo de control empresarial. Eso entra de lleno en supervisión, riesgo y responsabilidad de dirección.

Un consejo no necesita debatir algoritmos de cifrado, pero sí debería exigir cinco cosas muy concretas. Una, un mapa de tratamientos vivos que enlace finalidades, bases jurídicas, sistemas y proveedores. Dos, criterios de retención con ejecución verificable, no simples tablas en PDF. Tres, evidencias de pruebas periódicas de eficacia de controles relevantes para datos personales, incluidas restauración y revisiones de acceso. Cuatro, un mecanismo formal para aprobar usos secundarios de datos y automatizaciones que cambien el perfil de riesgo. Cinco, un relato único de incidentes y deficiencias que sirva para GDPR, supervisión sectorial y auditoría interna.

Si la organización no puede entregar eso sin improvisar durante dos semanas, la exposición existe aunque todavía no haya reclamación. Y lo peor es que normalmente ya hay señales: tickets eternos de borrado, respuestas de acceso incompletas, excepciones de acceso privilegiado que nadie revoca, logs imposibles de correlacionar, repositorios duplicados y sistemas heredados donde “temporal” significa cinco años.

La lectura más útil de estas decisiones: menos doctrina grandilocuente, más disciplina operativa

La página del EDPB que lista estas decisiones no pretende contar una historia. Pero la historia está ahí para quien quiera verla. En 2026, el GDPR se aplica cada vez menos como un ejercicio retórico y cada vez más como una disciplina de prueba: qué datos tratas, por qué, durante cuánto tiempo, con qué controles, con qué terceros y qué evidencia tienes de que todo eso funciona.

La decisión EDPBI:IE:OSS:D:2025:1678 merece atención precisamente por su sobriedad. No hace ruido. No necesita hacerlo. Al juntar los artículos 32, 5 y 6, deja una pista bastante incómoda para cualquier organización que siga tratando la privacidad como documentación y la seguridad como infraestructura. Esa separación ya no resiste bien la mirada europea.

La conclusión no es dramática, pero sí exigente. Si tu programa de cumplimiento todavía divide personas, procesos y evidencias en compartimentos estancos, el problema no es solo de eficiencia. Es regulatorio. Y cuando el expediente llega, descubrir que el artículo 32 estaba conectado con casi todo lo demás suele salir bastante más caro que haberlo entendido antes.