Diez años de RGPD: el artículo 25 y la privacidad que ya no basta con declarar

Estado de la técnica, diseño del tratamiento y casos recientes de la AEPD

Resumen

A diez años de la aprobación del Reglamento General de Protección de Datos, el artículo 25 se ha convertido en una de las disposiciones más reveladoras de la madurez del modelo europeo de protección de datos. La protección de datos desde el diseño y por defecto ya no puede leerse como una fórmula elegante de cumplimiento, ni como una simple recomendación metodológica para proyectos tecnológicos. Su sentido actual es más exigente: obliga a que los tratamientos se conciban, configuren, ejecuten y revisen de manera que los principios del RGPD funcionen en la práctica.

Este artículo analiza esa evolución a partir de la normativa, las Directrices 4/2019 del Comité Europeo de Protección de Datos, las guías técnicas de la Agencia Española de Protección de Datos y una selección de procedimientos sancionadores recientes. El análisis se detiene especialmente en el expediente EXP202312854 / PS-00143-2025, relativo a CaixaBank, en el que la AEPD sanciona a la entidad por infracción del artículo 25 RGPD tras detectar deficiencias en el funcionamiento del Servicio de Atención al Cliente.

La tesis que se defiende es sencilla: el artículo 25 RGPD está dejando de operar como una cláusula programática para convertirse en un estándar de diseño efectivo del tratamiento. No exige perfección técnica ni elimina la posibilidad de error humano, pero sí obliga a que los riesgos previsibles se tengan en cuenta en la arquitectura del proceso. Cuando el error es repetido, previsible, facilitado por el flujo operativo o solo se detecta gracias a terceros, deja de ser una explicación suficiente y empieza a ser una señal de que el tratamiento quizá no estaba bien diseñado.

Palabras clave: artículo 25 RGPD; privacidad desde el diseño; protección de datos por defecto; estado de la técnica; responsabilidad proactiva; AEPD; CaixaBank; error humano; brechas de datos; minimización; exactitud; confidencialidad.

1. Introducción

Durante los primeros años de aplicación del RGPD, muchas organizaciones entendieron la privacidad desde el diseño como una obligación más dentro del programa de cumplimiento. Se incorporó a políticas, plantillas, registros de actividades, cláusulas internas y procedimientos de desarrollo. Todo ello era necesario, pero no suficiente.

La experiencia sancionadora reciente muestra que la pregunta de las autoridades ya no es solo si la organización tiene documentos. La pregunta es otra: si el tratamiento, tal como funciona en la realidad, está construido para evitar accesos indebidos, comunicaciones excesivas, asociaciones erróneas, configuraciones abiertas, conservación innecesaria o detección tardía de incidentes.

Ahí aparece la verdadera importancia del artículo 25 RGPD. Su fuerza no está únicamente en exigir “privacidad desde el diseño”, sino en convertir esa idea en una obligación comprobable. El responsable debe aplicar medidas técnicas y organizativas apropiadas al determinar los medios del tratamiento y durante el propio tratamiento. Además, debe hacerlo teniendo en cuenta el estado de la técnica, el coste de aplicación, la naturaleza, el ámbito, el contexto, los fines del tratamiento y los riesgos para los derechos y libertades de las personas.

El considerando 78 del RGPD refuerza esa lectura. No habla de privacidad como una capa posterior, sino de incorporar garantías desde el desarrollo, diseño, selección y uso de aplicaciones, servicios y productos basados en datos personales. También conecta esta lógica con la minimización, la seudonimización, la transparencia, el control por parte del interesado y la mejora de la seguridad.

La hipótesis de este trabajo es que, en la práctica reciente de la AEPD, el artículo 25 se está utilizando como una forma de mirar la arquitectura del tratamiento. No se trata solo de comprobar si se produjo una brecha o si existía una política interna. Se trata de analizar si el tratamiento estaba concebido para que los principios del RGPD operaran de manera efectiva.

2. Cómo se ha construido el análisis

Este trabajo no pretende inventariar todas las resoluciones españolas en las que aparece el artículo 25 RGPD. El objetivo es más concreto: analizar una serie de procedimientos sancionadores recientes en los que el artículo 25 tiene un papel relevante porque se vincula a problemas de diseño, configuración, previsión, minimización, accesibilidad, segmentación, detección o revisión del tratamiento.

La selección responde a tres razones. La primera es la relevancia jurídica de los casos. La segunda es su diversidad sectorial: banca, telecomunicaciones, seguros y plataformas digitales. La tercera es que permiten estudiar casos de uso muy distintos: aportación documental financiera, duplicado de SIM, banca online, bases de datos de clientes y exclientes, contratación fraudulenta, sistemas de información crediticia, geolocalización de repartidores y servicios de atención al cliente.

El enfoque utilizado es deliberadamente práctico. En cada caso interesa saber qué tratamiento se estaba ejecutando, qué riesgo era previsible, qué medidas cabía esperar conforme al estado de la técnica, dónde se aprecia el fallo de diseño y qué principio del RGPD dejó de funcionar correctamente.

Esta forma de analizar los expedientes evita dos excesos. El primero sería pensar que toda brecha implica automáticamente una infracción del artículo 25. El segundo sería aceptar que la existencia de políticas, formación o auditorías basta para excluir cualquier defecto de diseño. La realidad es más exigente y también más matizada.

3. El artículo 25 dentro del sistema del RGPD

El artículo 25 no vive aislado. Se entiende mejor cuando se pone en relación con otros preceptos del Reglamento.

El artículo 5 contiene los principios: licitud, lealtad, transparencia, limitación de la finalidad, minimización, exactitud, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva.

El artículo 24 exige que el responsable aplique medidas técnicas y organizativas apropiadas para garantizar y poder demostrar que el tratamiento es conforme con el RGPD.

El artículo 32 se centra en la seguridad del tratamiento.

El artículo 35 permite anticipar riesgos altos mediante la evaluación de impacto.

El artículo 25 tiene una función propia: obliga a traducir esos principios y obligaciones en el diseño del tratamiento. No sustituye al artículo 5, ni al 24, ni al 32, ni al 35. Pero los conecta con la realidad operativa. Pregunta cómo se han configurado los accesos, qué datos se muestran por defecto, qué controles existen antes de enviar documentación, cómo se separan clientes y exclientes, cómo se verifica la identidad, cómo se detectan errores y cómo se revisa el tratamiento cuando algo falla.

Esta autonomía se aprecia con claridad en algunas resoluciones. En el caso Orange, la AEPD diferencia la infracción del artículo 6 RGPD —tratamiento sin base legitimadora— de la infracción del artículo 25, vinculada a la falta o deficiente implantación de medidas apropiadas desde el diseño. También en el expediente CaixaBank EXP202312854 resulta muy significativo que la AEPD archive la imputación basada en el artículo 5.1.f) y mantenga la infracción del artículo 25, al considerar que el problema no era solo una quiebra aislada de confidencialidad, sino una deficiencia de diseño que afectaba también a minimización y exactitud.

Ese desplazamiento es importante. Cuando el problema no se limita a que un dato haya sido revelado indebidamente, sino a que el tratamiento permite, facilita, no detecta o no corrige desviaciones previsibles, el artículo 25 ofrece una categoría de análisis más precisa.

4. El estado de la técnica: una expresión que no debe pasarse por alto

El artículo 25 empieza con una expresión que a veces se menciona deprisa: “teniendo en cuenta el estado de la técnica”. Sin embargo, ahí se encuentra buena parte de la fuerza del precepto.

El estado de la técnica no significa adoptar siempre la herramienta más avanzada ni la solución más costosa. Tampoco significa que la organización esté obligada a impedir cualquier incidente. Significa algo más razonable y más exigente a la vez: que el responsable debe conocer el contexto técnico y organizativo de su tratamiento, identificar los riesgos previsibles y seleccionar medidas adecuadas, actualizadas y proporcionadas.

Este concepto tiene una dimensión temporal. Lo que pudo ser suficiente en los primeros años de aplicación del RGPD puede resultar insuficiente años después si han cambiado los riesgos, las prácticas disponibles o las capacidades de detección.

Tiene también una dimensión sectorial. No se espera lo mismo de una pequeña operación administrativa que de una entidad bancaria, una aseguradora, una operadora de telecomunicaciones o una plataforma digital que monitoriza en tiempo real la actividad de sus repartidores.

Y tiene, sobre todo, una dimensión funcional. El estado de la técnica debe leerse según el caso de uso. En un duplicado de SIM, lo relevante será la verificación de identidad, la prevención del SIM swapping y las alertas antifraude. En un servicio de atención al cliente bancario, pesarán más la validación de destinatarios, el control de adjuntos, la asociación correcta entre reclamación, reclamante y representante, la detección interna y el escalado al DPO. En una base de datos de aseguradora, la cuestión puede estar en la separación lógica entre clientes y exclientes, las reglas de conservación y la segmentación de accesos.

Por eso, el estado de la técnica no puede entenderse como un catálogo cerrado de herramientas. Es una medida de diligencia técnica y organizativa situada: depende del riesgo, del sector, del tratamiento, del volumen, del daño posible y de las medidas razonablemente disponibles.

5. Desde el diseño y por defecto: dos exigencias que se complementan

El artículo 25 contiene dos planos distintos.

El primero es la protección de datos desde el diseño. Se refiere a cómo se concibe el tratamiento para integrar principios, garantías y controles. Aquí entran la minimización, la seudonimización cuando proceda, el control de accesos, la separación lógica, la trazabilidad, las validaciones, la gestión de cambios, las pruebas, la revisión de permisos y las medidas organizativas.

El segundo es la protección de datos por defecto. Se refiere a cómo queda configurado el tratamiento cuando nadie modifica nada. La pregunta es si, por defecto, se tratan solo los datos necesarios, durante el plazo necesario, con la extensión necesaria y con la accesibilidad necesaria.

Esta distinción es útil porque permite ver distintos tipos de fallos. Un tratamiento puede estar formalmente descrito, pero mal concebido. Puede estar concebido con buenas intenciones, pero configurado por defecto de manera excesiva. O puede haber nacido con un diseño razonable y volverse insuficiente porque nadie revisó su funcionamiento cuando cambiaron los riesgos, los volúmenes o los usos.

La privacidad desde el diseño no es, por tanto, una fotografía tomada al inicio del proyecto. Es una obligación que acompaña al tratamiento mientras exista.

6. Lo que muestran los casos

Los expedientes seleccionados permiten ver cómo el artículo 25 se aplica de forma distinta según el caso de uso.

OpenBank: cuando el tratamiento no se prevé bien

En el procedimiento PS/00331/2022, relativo a OpenBank, la AEPD concluyó que la entidad no había previsto adecuadamente la recogida de documentación financiera de clientes en el marco de la prevención de blanqueo de capitales. Al no prever bien ese tratamiento, tampoco identificó ni evaluó correctamente los riesgos ni estableció medidas apropiadas. La Memoria de la AEPD señala que OpenBank no cumplió el artículo 25 ni antes ni durante el tratamiento.

La lección es clara: el artículo 25 puede fallar antes de que se produzca una brecha. Falla cuando un caso de uso real existe en la operativa de la organización, pero no ha sido diseñado como tratamiento con riesgos propios.

En un contexto bancario, la aportación documental financiera exige algo más que instrucciones generales. Exige un canal seguro, trazabilidad, control de destinatarios, limitación de accesos, reglas de conservación y una evaluación razonable del riesgo documental.

Orange: cuando el riesgo específico no se traduce en controles

El caso Orange gira en torno al duplicado de una tarjeta SIM y al riesgo de SIM swapping. La AEPD sancionó por infracción del artículo 25 porque el procedimiento no incorporaba medidas suficientes frente a un riesgo conocido y especialmente dañino: que un tercero obtuviera un duplicado de SIM y con ello pudiera tomar control de servicios vinculados al número de teléfono.

La importancia del caso está en que no basta con tener documentación general de privacidad desde el diseño. El diseño debe responder al riesgo específico del tratamiento. En un duplicado de SIM, el estado de la técnica apunta a verificación reforzada de identidad, alertas, controles antifraude, trazabilidad, escalado en situaciones de riesgo y revisión periódica del procedimiento.

La privacidad desde el diseño, aquí, no es una política general. Es una respuesta concreta a un fraude previsible.

Generali: el diseño también está en la base de datos

En el procedimiento PS/00453/2023, relativo a Generali España, la AEPD vinculó la infracción del artículo 25 a un mal diseño inicial de la base de datos: clientes y exclientes se encontraban en la misma tabla. Este dato es especialmente interesante porque separa el artículo 25 de una lectura puramente centrada en ciberseguridad.

No se trata solo de proteger una base de datos frente a accesos indebidos. También se trata de diseñar bien qué datos conviven, durante cuánto tiempo, bajo qué estado, con qué finalidad y con qué permisos. En una aseguradora, clientes y exclientes no presentan la misma situación jurídica ni deberían estar sometidos necesariamente al mismo régimen funcional de tratamiento.

La lección es potente: la arquitectura del dato también es privacidad desde el diseño.

CaixaBank PS/00477/2023: autorizaciones que muestran más de lo debido

Otro caso relevante es el procedimiento PS/00477/2023 contra CaixaBank. Según la Memoria AEPD 2024, un tercero autorizado podía visualizar información relativa a cuentas, productos y tarjetas fuera del ámbito adecuado de autorización. La AEPD imputó el artículo 25 por inadecuación del diseño de la aplicación informática.

Aquí el problema no está solo en que alguien accediera a datos que no debía. El problema está en cómo se había diseñado la autorización. En banca online, una autorización no puede operar como una etiqueta genérica. Debe ser una regla fina de visibilidad: qué persona puede ver qué producto, con qué relación, para qué finalidad y en qué operación.

El estado de la técnica, en este contexto, exige permisos granulares, pruebas de roles, segmentación por producto, cuenta o tarjeta, revisión de escenarios límite y configuración restrictiva por defecto.

BBVA: contratación, fraude y solvencia como circuito completo

El procedimiento PS/00677/2022 frente a BBVA permite leer el artículo 25 en un contexto más complejo: contratación bancaria, fraude, deuda e información crediticia. Estos tratamientos no pueden analizarse como piezas aisladas. Si una contratación fraudulenta termina generando deuda e inclusión en sistemas de información crediticia, el daño para la persona no está en un único momento, sino en todo el circuito.

Por eso, desde una lectura madura del artículo 25, el diseño debe cubrir el proceso completo: verificación de identidad, trazabilidad de la contratación, validación del consentimiento, bloqueo preventivo ante disputa razonable, revisión previa antes de comunicar deuda y mecanismos ágiles de corrección.

La lección es que, cuando varios tratamientos encadenados pueden producir daño patrimonial o reputacional, el artículo 25 exige mirar la arquitectura completa, no solo cada trámite por separado.

GLOVOAPP23: el diseño de una plataforma es también su modelo operativo

En el procedimiento PS/00209/2022 contra GLOVOAPP23, la AEPD examinó tratamientos vinculados a geolocalización en tiempo real, monitorización de entregas, valoraciones de repartidores y puntuaciones de reputación. El caso permite ver que el artículo 25 no se agota en sistemas bancarios o aseguradores. También alcanza a plataformas digitales cuyo funcionamiento depende de observar, medir, puntuar y ordenar conductas.

En una plataforma, el diseño no es solo código. Es también el modelo operativo: qué se observa, durante cuánto tiempo, con qué granularidad, para qué finalidad, quién accede a la información y qué consecuencias produce para la persona.

La privacidad desde el diseño exige aquí minimización de la geolocalización, límites temporales, transparencia funcional, separación entre datos operativos y reputacionales, revisión de métricas, control de accesos y evaluación de impacto cuando proceda.

7. CaixaBank EXP202312854: del error humano al diseño del proceso

El expediente EXP202312854 / PS-00143-2025 merece un análisis más detenido porque ofrece una lectura muy madura del artículo 25.

El procedimiento se inició por dos reclamaciones vinculadas al Servicio de Atención al Cliente de CaixaBank. En una de ellas, un reclamante recibió una comunicación relativa a una reclamación que no había presentado y dirigida a un tercero. En otra, el reclamante recibió documentación correspondiente a personas desconocidas y, después, un documento preparado para firma que contenía datos personales de otro cliente.

CaixaBank sostuvo que su Servicio de Atención al Cliente funcionaba con procedimientos documentados, enfoque preventivo, revisión interna, informes anuales y supervisión bancaria. También defendió que las brechas respondían a errores humanos puntuales de personas que no siguieron las instrucciones internas.

La AEPD no niega que pueda haber errores humanos. Lo relevante es que no acepta esa explicación como suficiente. La resolución analiza la existencia de brechas análogas, la forma en que se detectaban, los tiempos de comunicación al DPO, la identificación de afectados y la determinación de los datos revelados. El problema deja de estar únicamente en la conducta individual de una persona y pasa a situarse en el diseño del proceso.

Uno de los elementos más importantes es la detección. La resolución muestra que varias brechas fueron conocidas gracias a terceros: personas físicas, Banco de España o Agència Catalana de Consum. La versión pública anonimiza los porcentajes, por lo que no resulta prudente afirmar una cifra concreta como dato oficial. Lo importante es la idea de fondo: la AEPD aprecia una dependencia relevante de detecciones externas.

Esto es decisivo. Un tratamiento no está plenamente diseñado si solo descubre sus errores cuando el daño ya ha salido de la organización y lo comunica quien ha recibido indebidamente la información. La detección no pertenece solo a la seguridad. También forma parte del diseño del tratamiento.

El expediente también es relevante porque la AEPD no se queda en la confidencialidad. Afirma que la falta de medidas del artículo 25 afectó también a minimización y exactitud. En algunos casos se vincularon datos a reclamaciones que no correspondían, se asociaron representantes de manera errónea o se revelaron datos financieros e identificativos que no debían haberse comunicado.

La inferencia doctrinal debe formularse con cuidado. Este expediente no demuestra que todo error humano sea defecto de diseño. Lo que demuestra es algo más preciso: cuando el error humano es previsible, repetido, facilitado por la organización del tratamiento, difícilmente detectable internamente y capaz de afectar a varios principios del RGPD, puede ser un indicio cualificado de que el tratamiento no estaba suficientemente diseñado.

En un Servicio de Atención al Cliente bancario, el estado de la técnica no se limita a proteger sistemas frente a ciberataques. También exige validación de destinatarios, control de adjuntos, asociación correcta entre reclamación, reclamante, representante y expediente, trazabilidad del flujo documental, detección interna de envíos incongruentes, escalado rápido al DPO, identificación completa de afectados y revisión periódica del proceso.

La lección del caso CaixaBank puede resumirse así: el SAC de una entidad bancaria no es un trámite administrativo menor. Es un tratamiento masivo, documental, relacional y multicanal de datos identificativos, contractuales y financieros. Si ese proceso permite errores repetidos y la organización depende de terceros para advertirlos, el artículo 25 permite mirar más allá del error puntual y preguntar si el proceso estaba bien diseñado.

8. Datos bancarios e identificativos: no todo es categoría especial, pero no todo pesa igual

Conviene evitar una imprecisión frecuente. No todos los datos tratados en estos casos son categorías especiales del artículo 9 RGPD. Sin embargo, eso no significa que sean datos de bajo riesgo.

En el expediente CaixaBank aparecen datos identificativos, bancarios, contractuales y financieros: DNI, IBAN, contratos, préstamos, avales, datos de contacto o información vinculada a reclamaciones. No son necesariamente categorías especiales, pero pueden tener un alto potencial lesivo. Pueden facilitar suplantaciones, fraudes, daños patrimoniales, afectación reputacional, pérdida de control o perjuicios en relaciones contractuales.

Por eso, la expresión más precisa no es “datos sensibles” en sentido jurídico estricto, sino “datos ordinarios de alto potencial lesivo”. El riesgo no depende solo del tipo abstracto de dato, sino de su contexto, acumulación, asociación, destinatario, finalidad, volumen y consecuencias.

Esta precisión es importante porque refuerza la lectura del artículo 25. El diseño del tratamiento no puede graduarse solo preguntando si hay datos del artículo 9. Debe preguntarse qué daño puede producir el tratamiento real.

9. Una forma de ordenar los casos

La comparación de los expedientes permite ver una línea común. No estamos ante una simple suma de brechas. Estamos ante tratamientos en los que el riesgo era previsible y el diseño no parece haberlo absorbido adecuadamente.

La categoría común no es simplemente “brecha de datos”. La categoría común es más precisa: diseño insuficiente frente a riesgos previsibles del caso de uso concreto.

10. Qué debería poder demostrar una organización

Si el artículo 25 se toma en serio, una organización debería poder responder a preguntas muy concretas.

Debe poder explicar cuál es el tratamiento real, no solo el tratamiento descrito en el registro de actividades. Debe identificar qué daño puede sufrir la persona. Debe justificar qué medidas técnicas y organizativas resultan razonables conforme al estado de la técnica. Debe demostrar que ha limitado datos, accesos, conservación y visibilidad por defecto. Debe probar que el sistema evita asociaciones erróneas entre personas, documentos, expedientes o productos. Debe acreditar que detecta internamente desviaciones relevantes y que no depende solo de terceros para conocerlas. Debe garantizar que el DPO recibe información temprana y completa. Y debe conservar evidencias de diseño, revisión, pruebas, indicadores y medidas correctivas.

Esto no significa que el artículo 25 imponga una obligación de perfección. El RGPD no exige organizaciones infalibles. Lo que exige es una diligencia proporcionada, razonada, actualizada y demostrable. La diferencia es importante: no se sanciona cualquier error, pero sí puede sancionarse un tratamiento que no estaba diseñado para prevenir, limitar, detectar o corregir errores previsibles.

11. Conclusión

A diez años del RGPD, el artículo 25 permite ver con claridad hacia dónde ha evolucionado la protección de datos. Ya no basta con declarar el cumplimiento. Tampoco basta con conservar políticas, instrucciones o informes. La privacidad debe estar dentro del tratamiento.

El estado de la técnica cumple aquí una función decisiva. Obliga a mirar el tratamiento en su contexto: qué riesgos eran previsibles, qué medidas estaban razonablemente disponibles, qué controles se incorporaron, cómo se configuraron los valores por defecto, cómo se detectan fallos y cómo se revisa el proceso cuando aparecen incidentes.

Los casos analizados muestran una misma dirección. En OpenBank, el problema fue no prever adecuadamente un tratamiento documental real. En Orange, no traducir el riesgo de SIM swapping en controles suficientes. En Generali, diseñar una arquitectura de datos que mezclaba clientes y exclientes. En CaixaBank PS/00477/2023, permitir una visibilidad excesiva en banca online. En BBVA, no diseñar de forma integrada el circuito contratación-fraude-solvencia. En Glovo, construir una plataforma con tratamientos intensivos de geolocalización y reputación. Y en CaixaBank EXP202312854, permitir que un flujo documental del SAC generara errores reiterados, detectados en buena medida por terceros y comunicados tardíamente al DPO.

La privacidad desde el diseño no es una promesa de cumplimiento. Es una propiedad demostrable del tratamiento.

Y quizá esta sea la enseñanza más importante del artículo 25 tras diez años de RGPD: cuando el error humano es aislado, puede ser solo un error; cuando es previsible, repetido, facilitado por el proceso o detectado desde fuera, empieza a hablar del diseño. Ahí la privacidad deja de ser un documento y se convierte en arquitectura.

Bibliografía y fuentes específicas

Normativa

1. Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016 — Reglamento General de Protección de Datos.
   Fuente: BOE / Diario Oficial de la Unión Europea.
   URL: https://www.boe.es/doue/2016/119/L00001-00088.pdf
2. Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales.
   Fuente: BOE.
   URL: https://www.boe.es/buscar/act.php?id=BOE-A-2018-16673

Directrices europeas

3. Comité Europeo de Protección de Datos, Directrices 4/2019 relativas al artículo 25: protección de datos desde el diseño y por defecto, versión 2.0, adoptadas el 20 de octubre de 2020.
   Fuente: EDPB / CEPD.
   URL versión española PDF: https://www.edpb.europa.eu/system/files/2021-04/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_es.pdf
   URL página oficial: https://www.edpb.europa.eu/documents/guideline/guidelines-42019-on-article-25-data-protection-by-design-and-by-default_en

Guías técnicas de la AEPD

4. AEPD, Guía de Privacidad desde el Diseño.
   Fuente: Agencia Española de Protección de Datos.
   URL: https://www.aepd.es/guias/guia-privacidad-desde-diseno.pdf
5. AEPD, Guía de Protección de Datos por Defecto.
   Fuente: Agencia Española de Protección de Datos.
   URL: https://www.aepd.es/guias/guia-proteccion-datos-por-defecto.pdf
6. AEPD, Gestión del riesgo y evaluación de impacto en tratamientos de datos personales.
   Fuente: Agencia Española de Protección de Datos.
   URL: https://www.aepd.es/guias/gestion-riesgo-y-evaluacion-impacto-en-tratamientos-datos-personales.pdf

Resoluciones y procedimientos sancionadores AEPD

7. AEPD, CaixaBank, S.A., EXP202312854 / PS-00143-2025, Resolución de terminación del procedimiento por pago voluntario.
   URL: https://www.aepd.es/documento/ps-00143-2025.pdf
8. AEPD, Orange Espagne, S.A.U., AI-00332-2023, duplicado SIM / SIM swapping.
   URL: https://www.aepd.es/documento/ai-00332-2023.pdf
9. AEPD, BBVA, PS/00677/2022.
   URL: https://www.aepd.es/documento/ps-00677-2022.pdf
10. AEPD, OpenBank, PS/00331/2022.
    URL: https://www.aepd.es/documento/ps-00331-2022.pdf
11. AEPD, CaixaBank, PS/00020/2023.
    URL: https://www.aepd.es/documento/ps-00020-2023.pdf
12. AEPD, GLOVOAPP23, PS/00209/2022.
    URL: https://www.aepd.es/documento/ps-00209-2022.pdf
13. AEPD, Generali España, PS/00453/2023.
    URL: https://www.aepd.es/documento/ps-00453-2023.pdf
14. AEPD, CaixaBank, PS/00477/2023.
    URL: https://www.aepd.es/documento/ps-00477-2023.pdf

Memorias AEPD

15. AEPD, Memoria anual 2023.
    URL: https://www.aepd.es/memorias/memoria-aepd-2023.pdf
16. AEPD, Memoria anual 2024.
    URL: https://www.aepd.es/memorias/memoria-aepd-2024.pdf