El EDPB no ha publicado una guia nueva, pero su pagina de referencia deja claro donde se juega hoy el cumplimiento real del GDPR

No hay una guia nueva del EDPB que cambie las reglas de juego de un dia para otro. Y precisamente por eso esta pagina merece atencion. Lo que ha publicado —o, mejor dicho, lo que ha puesto en escaparate— es una recopilacion de directrices, recomendaciones y notas para responsables y encargados del tratamiento que funciona como una radiografia bastante honesta de las obsesiones regulatorias europeas en materia de privacidad.

La lista no es neutra. Nunca lo es. Cuando el European Data Protection Board agrupa en un mismo punto documentos sobre notificacion de brechas, consentimiento, transferencias internacionales, privacidad desde el diseno, alcance territorial, art. 6.1.b GDPR, codigos de conducta, certificacion o BCR, esta diciendo algo muy concreto al mercado: aqui siguen estando los agujeros, aqui siguen produciendose los errores y aqui van a seguir preguntando las autoridades.

Para quien espere un titular facil, la noticia es menos glamourosa que un expediente sancionador con ocho ceros. Para quien dirige privacidad, compliance, seguridad o contratacion tecnologica, la noticia es bastante mas util: el EDPB esta recordando, de forma silenciosa pero nada inocente, cuales son los frentes en los que una organizacion se la juega de verdad bajo el GDPR.

Lo que la pagina del EDPB revela sin decirlo explicitamente

La pagina agrupa materiales que van desde las Guidelines 3/2018 sobre el alcance territorial del GDPR hasta las Guidelines 01/2021 sobre ejemplos de notificacion de brechas, pasando por las Guidelines 05/2020 sobre consentimiento, las Recommendations 01/2020 sobre medidas complementarias para transferencias internacionales tras Schrems II, y las Guidelines 4/2019 sobre el art. 25 GDPR, esto es, proteccion de datos desde el diseno y por defecto.

Vista en conjunto, la seleccion tiene una logica muy clara. El EDPB no esta dedicando protagonismo a cuestiones academicas. Esta destacando los puntos en los que los responsables y encargados fallan de manera repetida:

• Base juridica mal elegida o sobredimensionada, especialmente cuando se usa el art. 6.1.b GDPR para justificar tratamientos que en realidad no son necesarios para prestar un servicio.
• Consentimiento defectuoso bajo el art. 4.11 y el art. 7 GDPR: casillas premarcadas, consentimiento condicionado o retirada mas dificil que la aceptacion.
• Contratos con encargados flojos o cosmeticos, cuando el art. 28 GDPR exige obligaciones muy concretas y trazables.
• Brechas notificadas tarde o mal, pese al plazo de 72 horas del art. 33 GDPR.
• Transferencias internacionales apoyadas en SCC o BCR sin evaluar si el derecho del tercer pais vacia de contenido la proteccion europea, exactamente el problema que puso el TJUE sobre la mesa en Schrems II, sentencia C-311/18 de 16 de julio de 2020.
• Controles de privacidad by design que se venden bien en PowerPoint y aparecen poco en arquitectura, desarrollo, procurement o gestion del cambio.

Ese es el quid. El EDPB no ha improvisado una lista de lectura. Ha reunido el temario del examen real.

Brechas: tres dias siguen siendo tres dias, aunque internamente nadie se aclare

Que las Guidelines 01/2021 sobre ejemplos de notificacion de brechas sigan ocupando un lugar destacado no sorprende. El art. 33 GDPR obliga al responsable a notificar a la autoridad de control una violacion de seguridad de los datos personales “sin dilacion indebida y, de ser posible, a mas tardar 72 horas” despues de haber tenido constancia de ella. El art. 34 añade la comunicacion al interesado cuando la brecha entrañe un alto riesgo para sus derechos y libertades.

Lo interesante es que el problema ya no es solo juridico. Es operacional. Muchas organizaciones siguen confundiendo tres momentos distintos: deteccion tecnica, confirmacion del incidente y “tener constancia” a efectos del art. 33. El regulador lleva años sugiriendo que no vale esperar a tener el informe forense completo, la cronologia cerrada y un comite interno en paz espiritual. Si ya sabes que ha habido acceso no autorizado o perdida de disponibilidad con afectacion a datos personales, el reloj corre.

Las guias del EDPB sobre brechas son especialmente utiles porque bajan el debate a escenarios concretos: envio erróneo de correos, ransomware, exfiltracion, perdida de dispositivos, indisponibilidad temporal de sistemas sanitarios o financieros. Y ahi aparece una verdad incomoda: muchas empresas tienen playbooks de ciberincidentes razonables, pero no tienen playbooks de decision juridica para el art. 33 GDPR que encajen con esos playbooks tecnicos.

Traducido al castellano operativo: seguridad habla de IOC, lateral movement y contencion; legal pregunta si hay datos personales afectados; negocio quiere restaurar; y nadie ha fijado por escrito quien decide si hay obligacion de notificar, con que evidencia minima y en que plazo interno. Luego llega la hora 68 y empiezan las prisas, que en privacidad siempre son una estrategia brillante hasta que dejan de serlo.

Para responsables y encargados esto importa por una razon adicional. El GDPR reparte deberes, pero no reparte el riesgo reputacional de forma tan limpia. El encargado debe notificar al responsable “sin dilacion indebida” segun el art. 33.2 GDPR. Esa formula, deliberadamente abierta, se ha convertido en un foco de tension contractual. Si tu proveedor tarda 36 horas en avisarte porque estaba “verificando el alcance”, puede haberte consumido media ventana regulatoria antes incluso de que tu equipo legal se siente.

Aqui es donde art. 28 y art. 33 se tocan de forma nada teorica. El contrato con encargados ya no puede limitarse a la lista estandar de clausulas. Tiene que fijar tiempos de escalado interno, formato minimo del primer aviso, acceso a logs, cooperacion forense y disponibilidad de contactos 24/7. Si no, la obligacion formal existe, pero el mecanismo para cumplirla no.

Consentimiento: el regulador sigue desconfiando, y con razon

Las Guidelines 05/2020 sobre consentimiento siguen siendo de las piezas mas citadas del EDPB porque desmontan una fantasia empresarial muy comun: pensar que el consentimiento es la base juridica mas segura porque “si el usuario acepta, ya esta”. No. El consentimiento es probablemente la base juridica peor gestionada del ecosistema digital europeo.

El EDPB lleva tiempo recordando cuatro condiciones basicas: debe ser libre, especifico, informado e inequivoco, conforme al art. 4.11 GDPR, y el art. 7 exige, entre otras cosas, poder demostrarlo y permitir retirarlo con la misma facilidad con la que se dio. Sobre el papel parece simple. En producto digital, publicidad, recursos humanos o servicios financieros embebidos, deja de serlo bastante deprisa.

La clave regulatoria aqui es que el EDPB no discute solo formularios de aceptacion. Discute estructuras de poder. Si el usuario no puede rechazar sin perder acceso innecesariamente, el consentimiento no es libre. Si agrupas finalidades distintas bajo un solo boton, no es especifico. Si escondes informacion relevante en capas opacas, no es informado. Si el silencio o la inaccion cuentan como aceptacion, no es inequivoco.

Y esto enlaza con otro documento de la pagina: las Guidelines 2/2019 sobre el tratamiento de datos bajo el art. 6.1.b GDPR en la prestacion de servicios online. El mensaje del EDPB fue, y sigue siendo, bastante molesto para muchas plataformas: no puedes convertir en “necesario para ejecutar el contrato” cualquier tratamiento que te venga bien para monetizar, perfilar o mejorar el negocio. “Necesario” no significa “util”, ni “esperable segun nuestro modelo comercial”, ni “si no lo hacemos bajan los ingresos de marketing”. Significa necesario para el nucleo objetivo del servicio solicitado.

Ese cruce entre consentimiento y art. 6.1.b ha sido una de las batallas conceptuales mas relevantes del GDPR. Muchas empresas intentaron escapar del rigor del consentimiento expandiendo artificialmente la nocion de necesidad contractual. El EDPB les contesto, basicamente, que no cuela. Y varias autoridades nacionales han ido por la misma linea.

Si tu organizacion sigue justificando personalizacion intensiva, analitica no esencial o combinacion de datos de distintas fuentes como si fuese inseparable del contrato, conviene releer esas guias con cafe. Fuerte.

Transferencias internacionales: Schrems II sigue mandando, aunque algunos actuen como si ya hubiera pasado el susto

La presencia destacada de las Recommendations 01/2020 sobre medidas complementarias para transferencias internacionales y de las European Essential Guarantees para medidas de vigilancia no necesita mucha interpretacion. El trauma regulatorio de Schrems II no ha desaparecido. Solo se ha normalizado.

La sentencia del TJUE en C-311/18, de 16 de julio de 2020, invalido el Privacy Shield y dejo claro que las Clausulas Contractuales Tipo no bastan por si solas cuando el ordenamiento del pais receptor permite accesos desproporcionados de autoridades publicas a los datos. A partir de ahi, el EDPB construyo un enfoque en varios pasos: mapear transferencias, identificar la herramienta del capitulo V GDPR, evaluar la legislacion y practicas del tercer pais, aplicar medidas complementarias si hacen falta y revaluar periodicamente.

Eso suena asumido. No siempre lo esta. En la practica, muchas companias siguen operando con una ficcion documental: tienen SCC firmadas, una Transfer Impact Assessment de 2021 y dos anexos tecnicos redactados con solemnidad, pero no han revisado si el proveedor procesa en claro, si puede entregar claves, si subencarga fuera del EEE o si la arquitectura permite realmente que las medidas tecnicas compensen el riesgo juridico.

El EDPB, al mantener estas recomendaciones entre sus materiales nucleares, vuelve a empujar una idea central: las transferencias no se arreglan solo con papel. Se arreglan, cuando se arreglan, combinando derecho, tecnologia y gobernanza. Cifrado robusto, gestion de claves separada, minimizacion de datos, pseudonimizacion efectiva y limitaciones de acceso no son adornos. Son lo que puede sostener la legalidad material de una transferencia cuando el entorno del tercer pais genera dudas serias.

Hay ademas un matiz que demasiadas empresas siguen subestimando: el problema no se limita a exportaciones obvias a grandes hyperscalers o SaaS estadounidenses. Aparece tambien en soporte remoto, monitorizacion, ticketing, HR tech, analytics, sistemas de deteccion de fraude, proveedores de marketing automation o servicios gestionados donde el acceso potencial desde un tercer pais puede constituir una transferencia. Si tu mapa de transferencias solo incluye los contratos “grandes”, seguramente esta incompleto.

La nota del EDPB sobre BCR y las referencias a formularios estandar para Controller BCR y Processor BCR tienen otro mensaje implicito. Las reglas corporativas vinculantes siguen siendo una herramienta valiosa para grupos multinacionales, amparadas por el art. 47 GDPR, pero no son una varita magica. Requieren aprobacion, estructura de gobernanza real y coherencia con el resto de obligaciones. Y, tras Schrems II, tampoco escapan del analisis sobre accesos estatales y medidas adicionales cuando proceda.

Privacidad desde el diseno: el art. 25 es donde se separa el cumplimiento serio del teatro documental

Las Guidelines 4/2019 sobre el art. 25 GDPR merecen mucha mas atencion de la que suelen recibir. No porque sean nuevas, sino porque son el punto en el que el GDPR deja de ser un ejercicio de textos legales y entra en producto, arquitectura, compras, desarrollo y operaciones.

El art. 25 impone al responsable la obligacion de aplicar, tanto al determinar los medios del tratamiento como en el momento del propio tratamiento, medidas tecnicas y organizativas apropiadas destinadas a aplicar de manera efectiva los principios de proteccion de datos. No es una recomendacion estetica. Es una obligacion legal operativa.

La consecuencia practica es brutal y todavia infravalorada. Si la privacidad by design se activa cuando el producto ya esta construido, el proveedor ya esta contratado y el flujo de datos ya esta consolidado, llegas tarde. Puedes parchear informacion al usuario, puedes rehacer alguna base juridica, puedes retocar periodos de conservacion. Lo que rara vez puedes hacer sin coste serio es redisenar una dependencia estructural de datos excesivos.

El EDPB insiste en principios que parecen obvios y no lo son tanto cuando chocan con negocio: minimizacion, limitacion de la finalidad, integridad y confidencialidad, configuraciones por defecto respetuosas con la privacidad, ciclos de vida de datos limitados y control granular por parte del usuario. El verdadero test no esta en la politica de privacidad. Esta en preguntas mucho menos glamurosas:

• ¿Tu aplicacion activa por defecto funcionalidades que recogen mas datos de los necesarios?
• ¿Tu modelo de permisos distingue entre lo imprescindible y lo accesorio?
• ¿Puedes borrar de verdad, o solo ocultar en interfaz?
• ¿El logging recoge identificadores personales de forma desproporcionada?
• ¿La telemetria del proveedor incluye datos que tu ni siquiera sabias que salian?

En sectores regulados, incluido el financiero, la colision entre seguridad, trazabilidad y minimizacion no siempre tiene una respuesta simple. Pero esa complejidad no elimina la obligacion; exige justificar mejor el equilibrio. Un ejemplo claro: conservar trazas para deteccion de fraude o investigacion de incidentes puede ser necesario, pero debe responder a una finalidad definida, a controles de acceso, a periodos de retencion razonados y a una base juridica defendible. El art. 25 no te prohibe operar. Te prohibe operar sin pensar.

Responsables y encargados: el art. 28 sigue siendo uno de los articulos mas maltratados del GDPR

La propia etiqueta de la pagina del EDPB —relevante para responsables y encargados— invita a volver sobre una confusion vieja y muy rentable para algunos proveedores: presentar el contrato de encargado como un anexo estandar que se firma al final de la negociacion, deprisa y con resignacion. Error.

El art. 28 GDPR no describe un simple formalismo. Exige que el encargado ofrezca “garantias suficientes” de aplicar medidas tecnicas y organizativas apropiadas y enumera clausulas contractuales minimas: objeto y duracion del tratamiento, naturaleza y finalidad, tipo de datos, categorias de interesados, instrucciones documentadas, confidencialidad, seguridad conforme al art. 32, subencargados, ayuda al responsable para derechos, brechas, DPIA, devolucion o supresion de datos y auditorias.

La mayoria de organizaciones tiene un DPA firmado. Bastantes menos tienen un DPA util. La diferencia se nota cuando hay un incidente, una auditoria o una solicitud de ejercicio de derechos compleja. Si las obligaciones de asistencia son vagas, si no hay plazos internos, si las subcontrataciones se autorizan de forma generica sin visibilidad real o si las auditorias quedan limitadas a certificados estandar que nadie discute, el responsable conserva la responsabilidad frente al regulador pero pierde capacidad real de control.

El EDPB no lo dice con sarcasmo, asi que lo dire yo: hay proveedores que ofrecen “cumplimiento GDPR” como quien vende una funda para el movil. Queda bien en la web, tranquiliza a compras y aguanta hasta que alguien hace preguntas concretas. ¿Donde se alojan los backups? ¿Quien accede al soporte de nivel 3? ¿Cuanto tardan en informar de una brecha? ¿Que pasa con los metadatos operativos al terminar el servicio? ¿Existe segregacion real entre clientes? A partir de la tercera pregunta, la magia del folleto suele evaporarse.

Tambien hay una implicacion menos comentada. El art. 28 conecta directamente con DORA cuando hablamos de entidades financieras sujetas al Reglamento (UE) 2022/2554. DORA no sustituye al GDPR, pero endurece la expectativa de gobernanza sobre terceros TIC, especialmente en su capitulo V y en disposiciones como el art. 28 y siguientes sobre gestion del riesgo de terceros ICT. Si una entidad financiera depende de un proveedor que trata datos personales y presta un servicio TIC critico, el contrato ya no se evalua solo con gafas de privacidad: entra tambien resiliencia operativa, pruebas, salida, concentracion y supervisabilidad. Dos regímenes distintos. El mismo proveedor. Y una sola oportunidad de no firmar a ciegas.

Alcance territorial: art. 3 GDPR, el articulo que muchas empresas creen entender hasta que les toca justificarlo

Las Guidelines 3/2018 sobre el alcance territorial del GDPR siguen teniendo valor practico porque el art. 3 es uno de esos preceptos que parecen sencillos hasta que aparecen modelos de negocio transfronterizos, marketplaces, apps, afiliacion, analytics o servicios B2B con usuarios finales dispersos.

El EDPB aclaro dos ejes principales. El primero es el establecimiento en la Union: si el tratamiento se realiza “en el contexto de las actividades” de un establecimiento en la UE, el GDPR puede aplicar aunque el tratamiento material se haga fuera. El segundo es el criterio de direccion a interesados en la Union o monitorizacion de su comportamiento, incluso sin establecimiento europeo, conforme al art. 3.2.

La consecuencia para proveedores y grupos internacionales es obvia pero sigue generando fricciones: no basta con decir que el tratamiento lo hace una entidad extracomunitaria. Hay que analizar funciones, ingresos, segmentacion comercial, idiomas, moneda, entrega de bienes o servicios, seguimiento comportamental y realidad economica del grupo. Lo formal importa; la sustancia mas.

Esto tiene mucha relevancia para encargados globales que intentan situar la responsabilidad exclusivamente fuera del EEE mientras venden activamente en Europa o monitorizan usuarios europeos. Tambien para responsables europeos que contratan herramientas de terceros y asumen, por pereza o por necesidad, que “como el proveedor es americano, esto cae fuera”. No cae fuera tan facilmente.

DPIA, DPO, transparencia y registros: lo menos sexy del GDPR sigue siendo lo primero que te piden

La pagina del EDPB enlaza tambien a materiales sobre Delegado de Proteccion de Datos, evaluaciones de impacto para tratamientos de alto riesgo, notificaciones de brechas, decisiones automatizadas, autoridad de control principal, transparencia y la posicion sobre las derogaciones del art. 30.5 GDPR para el registro de actividades.

Todo esto forma una especie de bloque basal del cumplimiento. Menos llamativo que IA, biometria o transferencias, pero decisivo cuando llega una inspeccion. El patron se repite una y otra vez: empresas que han dedicado meses a rehacer banners de cookies y apenas han revisado la calidad real de su registro de actividades, la independencia funcional del DPO o la trazabilidad de sus DPIA.

El art. 30 GDPR, por ejemplo, sigue siendo tratado por muchas pymes y no pocas medianas como burocracia prescindible. Sin embargo, el registro de actividades es el inventario operativo que permite contestar, con algo mas que intuicion, a preguntas basicas: que datos tratamos, para que, con que base juridica, con que destinatarios, durante cuanto tiempo y bajo que transferencias. La excepcion del art. 30.5 para organizaciones con menos de 250 empleados no es un cheque en blanco: cae si el tratamiento no es ocasional, puede entrañar riesgo o incluye categorias especiales o datos de condenas e infracciones. Y buena parte del tratamiento corporativo actual no encaja precisamente en la idea romantica de “ocasional”.

Con las DPIA pasa algo parecido. El art. 35 GDPR obliga a realizarlas cuando un tratamiento probablemente entrañe alto riesgo para los derechos y libertades de las personas fisicas, especialmente en supuestos como evaluacion sistematica y exhaustiva basada en tratamiento automatizado, observacion sistematica a gran escala o tratamiento a gran escala de categorias especiales. Muchas organizaciones tienen plantillas de DPIA. Bastantes menos tienen un proceso de disparo fiable para saber cuando una iniciativa de negocio debe pasar por esa evaluacion antes del despliegue.

Y luego esta la transparencia. El EDPB lleva anos repitiendo en sus directrices que informar mal no es un pecado venial. Es una infraccion del deber central de lealtad del tratamiento. Politicas de privacidad interminables, jerga legalista, capas informativas que esconden destinatarios o bases juridicas, cambios no comunicados con claridad… todo eso sigue apareciendo en procedimientos sancionadores. Porque el problema no es la longitud del texto. Es que el usuario entienda de verdad que haces con sus datos.

Lo que deberian hacer ahora responsables y encargados, sin esperar a la proxima multa ajena

La utilidad real de esta pagina del EDPB no esta en leerla como repositorio. Esta en usarla como lista de comprobacion editorial de tus propios puntos ciegos. Si yo tuviera que traducirla a prioridades de gestion, seria algo asi.

Primero, revisar si tus bases juridicas resisten una lectura hostil. No una lectura interna benevolente, sino la de una autoridad de control o un reclamante. Mira especialmente dos zonas de riesgo: tratamientos amparados en consentimiento que en realidad no son libres, y tratamientos empujados al art. 6.1.b que no son estrictamente necesarios para ejecutar el contrato.

Segundo, volver a los contratos con encargados donde de verdad hay riesgo: cloud, SaaS nucleares, soporte remoto, servicios gestionados, procesadores de pagos, proveedores de RRHH, marketing tech y analitica. El objetivo no es coleccionar anexos. Es comprobar si el art. 28 esta convertido en obligaciones operativas medibles: incidentes, subencargados, derecho de auditoria, asistencia en derechos, borrado, exportacion y transferencias.

Tercero, probar el circuito de brechas con un reloj real. No en abstracto. Haz el ejercicio: un viernes a las 18:30 aparece evidencia de exfiltracion de una base con clientes. ¿Quien decide si hay violacion de seguridad de datos personales? ¿Quien documenta los hechos? ¿A que hora se avisa al DPO o al responsable de privacidad? ¿Que informacion minima debe remitir el encargado? ¿Hay un criterio escrito para determinar si aplica el art. 34 ademas del art. 33? Si esas respuestas no salen en minutos, no en dias, tienes trabajo.

Cuarto, rehacer el mapa de transferencias internacionales a partir de accesos reales, no solo de contratos principales. Soporte, telemetria, logs, subprocesadores, backups, centros de excelencia, administracion de sistemas. La transferencia que te dara problemas casi nunca es la mas visible; suele ser la que alguien considero “meramente tecnica”.

Quinto, incrustar el art. 25 y el art. 35 en el ciclo de vida de producto y compras. Si privacidad aparece al final, solo podras negociar excepciones, no diseñar cumplimiento. Procurement y arquitectura son tan decisivos para el GDPR como legal o compliance. A veces mas.

Implicaciones para entidades financieras españolas

Para banca, aseguradoras, EDE, ESI, fintech y proveedores tecnologicos del sector financiero en España, esta recopilacion del EDPB tiene una lectura particularmente clara: el cumplimiento de privacidad ya no puede gestionarse en un carril paralelo al de resiliencia operativa y ciberseguridad.

Las entidades sujetas a DORA desde el 17 de enero de 2025 conviven con obligaciones que se pisan con el GDPR en varios puntos, aunque con objetivos distintos. Un incidente TIC grave puede disparar deberes de clasificacion, registro, respuesta y notificacion bajo DORA, mientras una violacion de seguridad de datos personales activa el art. 33 y, en su caso, el art. 34 GDPR. No siempre coinciden. Un incidente puede ser muy serio operativamente sin implicar datos personales; y una brecha de datos puede no alcanzar el umbral de incidente grave TIC segun la logica sectorial. Si no tienes criterios de coordinacion entre ambas funciones, acabas con notificaciones desalineadas o, peor, con silencios cruzados.

Ademas, las externalizaciones TIC criticas o importantes ya estaban sujetas a escrutinio supervisor por EBA, EIOPA y ESMA antes de DORA, y ahora lo estan aun mas. Si el proveedor actua como encargado del tratamiento, la negociacion contractual debe integrar al menos tres capas: art. 28 GDPR, seguridad del art. 32 GDPR y requisitos de terceros TIC bajo DORA. En la practica eso afecta a auditorias, subcontratacion en cadena, ubicacion de datos, salida ordenada, testing, acceso a informacion y tiempos de notificacion de incidentes.

En España, AEPD y supervisores financieros no actuan siempre al unisono, pero seria una mala idea construir cumplimiento suponiendo que nunca se cruzaran los hechos. Se cruzan. Sobre todo en servicios digitales, fraude, onboarding remoto, biometria, monitorizacion transaccional y ecosistemas cloud.

La leccion de fondo: el GDPR no se incumple por no conocer la teoria, sino por no traducirla a operaciones

La pagina del EDPB tiene algo de recordatorio severo. No porque anuncie una novedad revolucionaria, sino porque insiste en que los problemas nucleares del GDPR siguen siendo los mismos seis años despues de su aplicacion plena, desde el 25 de mayo de 2018: saber por que tratas datos, limitar lo que recoges, explicar lo que haces, controlar a tus proveedores, reaccionar a tiempo ante brechas y no transferir datos fuera del EEE como si con una clausula contractual se arreglara todo.

Hay una ironia bastante europea en esto. El ecosistema discute sin parar sobre IA generativa, soberania digital y nuevas capas regulatorias, mientras muchas organizaciones siguen teniendo grietas muy clasicas en art. 28, art. 30, art. 33 o art. 35. El futuro del compliance siempre suena mas interesante que revisar un registro de actividades o renegociar un DPA con un proveedor complicado. Pero el expediente sancionador casi siempre empieza por lo aburrido.

Asi que la lectura correcta de esta publicacion del EDPB no es “no hay noticia”. Si la hay. La noticia es que el regulador europeo sigue apuntando, con paciencia burocratica pero bastante punteria, a los mismos puntos donde el mercado sigue flojeando. Y cuando un regulador repite tanto una cosa, normalmente no es porque le falte imaginacion. Es porque sigue encontrando el mismo agujero.

Tu organizacion deberia preguntarse algo muy simple despues de revisar esta lista: si mañana una autoridad te pidiera evidencia sobre base juridica, contratos de encargado, mapa de transferencias, decision de notificacion de brechas, DPIA y privacy by design, ¿podrias enseñar algo mas solido que documentos correctos en apariencia? Si la respuesta es “depende”, ya sabes por donde empezar.