Del incidente al requisito de diseño, la ingeniería inversa 2/2. Una lectura del caso CaixaBank desde la ingeniería de privacidad por diseño de ISO 31700-1:2023

(Artículo dirigido, revisado y validado por Leocadio Marrero Trujillo, autor y responsable editorial. Se utilizaron herramientas de IA generativa como apoyo a la edición y al diseño gráfico).

La resolución de la Agencia Española de Protección de Datos en el procedimiento seguido contra CaixaBank permite observar con bastante precisión el desplazamiento que se produce cuando una brecha deja de poder explicarse únicamente por la actuación de la persona que ejecutó materialmente la operación incorrecta. La investigación partió de comunicaciones enviadas a destinatarios que no debían recibirlas, pero terminó reconstruyendo asociaciones erróneas entre personas y reclamaciones, documentación incorporada a contextos equivocados, dificultades para detectar determinadas brechas y la repetición de incidentes de características semejantes durante distintos ejercicios. Al final del recorrido, la AEPD no se limitó a identificar errores individuales, sino que ordenó revisar el funcionamiento del Servicio de Atención al Cliente para garantizar el cumplimiento del artículo 25 del RGPD.

El análisis técnico de ese expediente permite llegar hasta una conclusión relevante: cuando el error humano es previsible y el tratamiento permite que sus consecuencias se propaguen, el diseño entra también en la explicación. Esa conclusión, sin embargo, abre un problema distinto. Una vez identificada la necesidad de revisar el tratamiento, todavía es necesario determinar qué debe revisarse, cómo transformar los hechos observados en requisitos concretos y de qué manera puede comprobarse que las modificaciones introducidas reducen realmente la posibilidad de que el mismo modo de fallo vuelva a producir resultados semejantes.

ISO 31700-1:2023 ofrece un marco especialmente útil para recorrer ese segundo tramo. Su utilización aquí no pretende convertir el expediente en una evaluación retrospectiva de conformidad ni sostener que CaixaBank estuviera sometida a sus requisitos. La norma establece requisitos de alto nivel para incorporar privacidad desde el diseño a bienes y servicios de consumo a lo largo de su ciclo de vida y evita deliberadamente prescribir una metodología o una tecnología determinada. Precisamente por ello puede utilizarse como una estructura de ingeniería con la que ordenar lo que el expediente ya ha revelado: pasar del incidente al riesgo, del riesgo al requisito, del requisito al control y del control a la evidencia de que funciona.

La diferencia no es menor. Cuando una organización conoce una brecha, dispone de información sobre algo que ocurrió. Cuando consigue reconstruir las condiciones que hicieron posible esa brecha, dispone además de información sobre el comportamiento de su tratamiento. Solo en ese segundo momento empieza a ser posible diseñar a partir de la experiencia.

1. Lo que el incidente revela cuando se observa como dato de operación

Una reclamación tiene normalmente una vida administrativa propia. Se recibe, se analiza, se responde y finalmente se cierra. Si durante su tramitación se produce una brecha, el incidente puede seguir un circuito similar: se investiga, se evalúan sus consecuencias, se adoptan las medidas correspondientes y se documenta el resultado. Nada de ello garantiza, sin embargo, que la información obtenida durante ese proceso termine modificando la representación que la organización mantiene sobre el riesgo.

El expediente de CaixaBank resulta especialmente significativo porque los hechos dejaron de estar confinados a dos episodios individuales. La investigación fue encontrando brechas funcionalmente semejantes en distintos momentos y con intervención de personas diferentes. Esa recurrencia no determina por sí sola una causa común, pero sí proporciona una evidencia que un incidente aislado difícilmente podría ofrecer. Si una determinada asociación incorrecta, una incorporación documental improcedente o una comunicación dirigida al destinatario equivocado reaparecen bajo circunstancias diferentes, la organización dispone de razones para examinar si el modelo con el que había descrito el riesgo sigue representando correctamente el funcionamiento real del tratamiento.

ISO 31700-1 introduce esta idea dentro de una concepción continua del diseño. La norma entiende que los riesgos y controles evolucionan durante el ciclo de vida y que los cambios, la experiencia de uso y los incidentes reales pueden exigir revisar decisiones anteriores. Su cláusula 6.5 desarrolla posteriormente esta exigencia al incorporar la monitorización de riesgos después de la puesta en funcionamiento y señalar que los riesgos nuevos o emergentes deben ser evaluados teniendo en cuenta, entre otras fuentes, la información procedente de reclamaciones y comentarios de los consumidores.

Aplicado al Servicio de Atención al Cliente, este enfoque supondría conservar de una reclamación algo más que su resultado final. Una asociación incorrecta entre reclamación e interesado podría registrarse como un modo de fallo específico y vincularse con el punto del proceso en el que apareció. Si meses después otro expediente reproduce el mismo patrón, ambos casos podrían analizarse conjuntamente para determinar si comparten una misma condición de origen. La organización empezaría así a observar no solo cuántas brechas se producen, sino también cómo se producen y qué controles deberían haber intervenido antes de que alcanzaran al interesado.

Figura 1 (IA): La repetición de incidentes convierte casos aislados en evidencia para revisar riesgos y controles.

Esta utilización de la experiencia operacional modifica el significado del incidente. La brecha ya no constituye únicamente una anomalía que debe corregirse después de ocurrida. Se convierte en nueva información para el siguiente análisis del riesgo. La cuestión relevante no reside entonces en que la organización disponga formalmente de un registro de incidentes, sino en si ese registro puede modificar los requisitos y controles cuando la realidad muestra que las hipótesis iniciales eran incompletas.

2. Reconstruir el modo de fallo

La utilidad de ese aprendizaje depende de la precisión con que se reconstruya lo sucedido. Describir el problema como un «envío de documentación a un destinatario incorrecto» identifica adecuadamente la consecuencia, pero ofrece todavía poca información sobre el funcionamiento anterior del tratamiento. El envío aparece al final de una secuencia cuya coherencia puede haberse perdido mucho antes.

Uno de los recorridos reconstruidos en el expediente permite entenderlo. Una reclamación queda relacionada de forma incorrecta con una persona. A partir de ese momento, la información asociada al expediente puede ser tratada bajo un contexto equivocado. Si las fases posteriores confían en esa asociación sin disponer de elementos independientes para cuestionarla, una operación ejecutada correctamente desde el punto de vista funcional puede continuar propagando una información que ya era incorrecta. La documentación seleccionada, la representación utilizada o el destinatario final pueden terminar afectados por un error cuya eficacia comenzó en una etapa anterior.

Desde la perspectiva de ingeniería, la diferencia entre el error inicial y su propagación resulta fundamental. Una persona puede realizar una selección incorrecta sin que esa actuación tenga necesariamente que convertirse en una brecha. Para que lo haga, el tratamiento debe admitirla, conservarla o utilizarla posteriormente de forma suficiente para producir un resultado sobre los datos personales. El modo de fallo describe precisamente esa combinación entre acción humana y comportamiento del proceso.

La cláusula 6.2 de ISO 31700-1 proporciona una base apropiada para reconstruir este tipo de secuencias. La evaluación puede apoyarse en mapas de datos, casos de uso, diagramas de flujo o secuencia, requisitos funcionales y no funcionales y otras representaciones que permitan comprender cómo se procesa realmente la información y dónde pueden aparecer consecuencias no previstas.

Una ejecución posible en el SAC consistiría en representar el recorrido de una reclamación desde su entrada hasta la comunicación final, señalando las relaciones que se crean o modifican durante el trayecto. El mapa tendría que mostrar, al menos, de dónde se obtiene la identidad del reclamante, cómo se determina una eventual representación, qué documentación queda disponible dentro del expediente y de qué información se deriva el destinatario de la respuesta. Sobre ese flujo podría reproducirse después el escenario acreditado: la reclamación de la persona A queda asociada a B.

Figura 2 (IA): Reconstruir el flujo permite identificar dónde nace el error, cómo se propaga y dónde debería haber sido detenido.

El interés de la simulación no estaría en constatar nuevamente que la primera asociación es incorrecta. Lo relevante sería observar qué sucede después. Si la documentación mostrada al operador pasa a ser la de B, si las comprobaciones posteriores utilizan la misma relación sin contrastarla y si finalmente el destinatario también se deriva de esa información, el análisis habría identificado un mecanismo de propagación. Si, por el contrario, alguna fase utiliza una fuente independiente y detecta la incoherencia, habríamos localizado una barrera efectiva.

Esta forma de reconstrucción permite evitar una consecuencia frecuente de los análisis excesivamente centrados en el resultado final: colocar todos los controles inmediatamente antes del envío. Una verificación final puede ser útil, pero difícilmente sustituirá controles anteriores si el tratamiento ha estado operando durante buena parte de su recorrido sobre un contexto incorrecto. La intervención más eficaz puede encontrarse precisamente en el punto en que el error adquiere capacidad para modificar el estado del expediente.

3. Convertir el modo de fallo en un requisito

Una vez identificado ese punto, todavía no es necesario decidir qué tecnología debe modificarse. Entre la caracterización del riesgo y la implantación de una medida existe un paso que ISO 31700-1 trata de forma expresa: la formulación de requisitos de privacidad.

La cláusula 6.4 establece que esos requisitos deben documentarse y servir de fundamento para el diseño y operación posterior de los controles. La propia evaluación del riesgo constituye una de sus fuentes principales. Esta separación es especialmente valiosa porque impide que la respuesta a un incidente dependa prematuramente de la primera solución disponible.

Si la reconstrucción anterior muestra que una asociación incorrecta entre reclamación e interesado puede consolidarse y propagarse sin nuevas comprobaciones, el requisito podría formularse señalando que la relación entre reclamación, interesado y representación debe mantener una coherencia verificable antes de que pueda utilizarse para producir actuaciones posteriores. El requisito no determina todavía si esa coherencia se conseguirá mediante una regla automática, una restricción en la interfaz, una fuente de identidad independiente o una validación humana específica. Define la propiedad que cualquier control elegido deberá preservar.

Figura 3 (IA): El riesgo se traduce primero en una propiedad de privacidad que debe preservarse, antes de elegir cómo hacerlo.

La documentación incorrecta permite realizar el mismo ejercicio. Si el análisis muestra que un operador puede incorporar a una respuesta un archivo perteneciente a otro cliente, el requisito puede orientarse a que la documentación utilizada permanezca vinculada al contexto validado del expediente y que cualquier incorporación procedente de fuera de ese contexto sea identificada y tratada como una excepción. De nuevo, no estamos decidiendo todavía cómo hacerlo; estamos estableciendo qué comportamiento debemos poder exigir después al tratamiento.

La detección plantea una exigencia diferente. Cuando el conocimiento de una comunicación incorrecta depende de que quien la recibió informe posteriormente a la organización, el problema ya no está únicamente en la prevención. Existe también una limitación en la capacidad para observar el comportamiento del propio sistema. El requisito correspondiente tendría que orientarse a conservar evidencia suficiente para identificar eventos incompatibles con las relaciones esperadas y reconstruir posteriormente qué información salió de la organización, hacia quién y respecto de qué personas.

La formulación de estos requisitos introduce una trazabilidad que resulta esencial para la fase siguiente. Un control deja de justificarse porque «mejora la privacidad» en términos generales. Puede explicarse qué riesgo pretende tratar y qué propiedad debe mantener. La norma sitúa esta relación entre requisitos, arquitectura de controles, procesos de apoyo, medición y desempeño dentro de la documentación que acompaña al diseño y operación de los controles.

4. Diseñar un control que pueda ser probado

ISO 31700-1 sitúa el diseño de controles después de esa definición. La cláusula 7.3 exige que respondan a los requisitos procedentes de la evaluación del riesgo y vincula su configuración con el resultado que se pretende alcanzar. El marco deja abierta la tecnología utilizada, algo especialmente importante en este análisis porque el expediente público no proporciona información suficiente para reconstruir con precisión la arquitectura del SAC.

El requisito de coherencia entre reclamación, interesado y representación permite ilustrar cómo podría materializarse. Una solución posible consistiría en que la relación introducida por el operador se contrastara con otros atributos ya conocidos del expediente y con la fuente que acredita la representación. Una incompatibilidad significativa podría impedir la consolidación automática y abrir un circuito de excepción que exigiera una validación independiente. Esta sería solamente una opción de implementación; ISO 31700-1 no prescribe ese control concreto. Lo que debería poder demostrarse es que la medida elegida responde efectivamente al requisito que la evaluación había generado.

Figura 4 (IA): El control debe poder justificarse por su capacidad para satisfacer el requisito de privacidad previamente definido.

El mismo criterio puede aplicarse al contexto documental. Si la propiedad que queremos preservar consiste en que la documentación utilizada corresponda al expediente activo, una implementación posible sería limitar por defecto los documentos disponibles a aquellos cuya vinculación con ese expediente ya esté establecida. La incorporación de un archivo externo continuaría siendo posible cuando exista una razón legítima, pero dejaría de ser una operación indistinguible de la selección ordinaria. El diseño introduce así una diferencia entre trabajar dentro del contexto esperado y abandonarlo.

La cuestión adquiere especial relevancia cuando se considera el error humano. Si una segunda persona comprueba exactamente la misma información incorrecta que utilizó la primera, la existencia de dos intervenciones no garantiza por sí sola una barrera independiente. Una validación aporta mayor valor cuando incorpora una fuente de información distinta o una relación que no depende de la misma decisión que originó el error. En el ejemplo anterior, la vinculación técnica del documento con el expediente podría actuar como señal diferente de la simple identificación visual del archivo por parte del operador.

La norma exige, además, que la reflexión sobre el control no termine en su implantación. La cláusula 7.4 incorpora expresamente su desarrollo, prueba, validación, implantación y monitorización durante el ciclo de vida, mientras que la 7.5 requiere pruebas y criterios de aceptación que permitan demostrar la efectividad operacional pretendida.

Es en esta fase donde los hechos del expediente adquieren un segundo valor. El error real puede convertirse en un escenario de prueba.

Si la medida pretende impedir que una reclamación de A quede asociada inadvertidamente a B, puede intentarse deliberadamente esa operación en un entorno controlado. El criterio de aceptación no debería limitarse a comprobar que existe una alerta en la interfaz. Debería expresar el resultado que se considera aceptable: la relación incompatible no puede quedar consolidada como contexto ordinario sin la intervención prevista para resolver la discrepancia.

El mismo ensayo puede realizarse con la documentación. Se intenta incorporar deliberadamente un documento perteneciente a otra persona y se observa si el tratamiento mantiene la propiedad que había sido definida en el requisito. Si el archivo entra en el expediente sin diferencia alguna respecto de la documentación correcta, el control no ha demostrado todavía que responda al modo de fallo conocido. Si, por el contrario, la operación queda separada, advertida o sometida a una validación independiente según el diseño adoptado, disponemos de evidencia sobre su comportamiento.

Este tipo de prueba introduce una diferencia importante respecto de la mera constatación documental de la existencia de controles. Una política demuestra que existe una política; una formación permite acreditar que determinadas personas han recibido conocimiento; una funcionalidad acredita que se ha implantado una medida. Ninguna de esas evidencias informa necesariamente sobre lo que sucederá cuando reaparezca exactamente el escenario que produjo la brecha. La prueba negativa permite aproximarse a esa segunda cuestión.

Los incidentes reales pueden funcionar, en este sentido, como pruebas de regresión de privacidad. Una vez corregido un modo de fallo, el escenario que lo reveló puede conservarse entre las pruebas que cualquier modificación posterior debería superar. La expresión procede del lenguaje de ingeniería y no de ISO 31700-1, pero resulta coherente con su exigencia de probar los controles y establecer criterios capaces de demostrar que continúan alcanzando su finalidad.

5. La operación produce nueva evidencia

La prueba realizada antes de la puesta en funcionamiento no permite asumir que el control conservará indefinidamente la misma eficacia. Los sistemas cambian, las aplicaciones se modifican, aparecen nuevas excepciones y el comportamiento real de quienes utilizan el proceso puede diferir del que se había representado durante el diseño. ISO 31700-1 concibe por ello los controles como elementos que deben mantenerse y evolucionar durante el ciclo de vida para evitar que pierdan eficacia o comiencen a operar de manera no prevista.

Esta perspectiva permite ampliar también la información que debería observarse durante la operación del SAC. Si un control destinado a preservar la coherencia del expediente impide una asociación incorrecta, ese evento tiene valor aunque nunca llegue a producirse una brecha. Lo mismo sucede cuando se rechaza un documento incompatible, cuando un cambio manual de destinatario exige una validación o cuando una operación queda detenida porque rompe una relación esperada. Estos eventos permiten observar la presencia del riesgo antes de que se materialice el daño.

Una monitorización madura podría, por tanto, complementar el número de brechas confirmadas con indicadores sobre asociaciones rechazadas, excepciones, documentos incompatibles detectados, modificaciones manuales de destinatario o validaciones adicionales. Si estas señales aumentan de forma significativa, la evaluación del riesgo podría necesitar una revisión aunque la última barrera haya conseguido evitar todos los incidentes. La cláusula 6.5 proporciona precisamente el marco para que los riesgos emergentes y la experiencia real vuelvan a alimentar las decisiones sobre controles.

Esta utilización de eventos previos resulta particularmente relevante porque las brechas consumadas constituyen indicadores tardíos. Cuando aparecen, todas las barreras anteriores han sido insuficientes. Los eventos detenidos proporcionan, en cambio, información sobre la presión que reciben esas barreras y sobre los puntos del proceso en los que los operadores encuentran con mayor frecuencia situaciones incompatibles con el diseño ordinario.

El expediente mostró además una dificultad distinta: algunas brechas no fueron conocidas inicialmente mediante los propios mecanismos internos de la organización. Cuando la detección depende en una medida significativa de que el destinatario incorrecto o un tercero advierta lo ocurrido, el sistema dispone de una visión incompleta de sus propios fallos. Esa limitación afecta también a la calidad de cualquier estadística construida posteriormente sobre el número de incidentes.

ISO 31700-1 incorpora la detección y la respuesta dentro de la operación de los controles. La cláusula 7.7 contempla la monitorización, investigación y remediación de incidentes con impacto en privacidad y relaciona expresamente la gestión de los problemas subyacentes con la prevención de recurrencias derivadas de errores de diseño, desarrollo u operación. La cláusula 7.8 añade la preparación de controles para prevenir, detectar y recuperarse de brechas, junto con el ensayo de triage, escalado y comunicaciones.

Figura 5 (IA): La privacidad desde el diseño incluye detectar los fallos, responder a ellos y utilizar lo aprendido para evitar su recurrencia

También aquí es posible probar la capacidad diseñada. En un entorno controlado puede permitirse que una comunicación incorrecta supere deliberadamente las barreras preventivas y observar lo que ocurre a partir de ese momento. La prueba puede medir si se genera una señal interna, cuánto tarda en llegar a la función responsable, si existe información suficiente para identificar el documento remitido y el destinatario y si puede determinarse quiénes son las personas afectadas. El resultado aporta evidencia no ya sobre la capacidad para impedir el error, sino sobre la capacidad para reconocerlo y limitar sus consecuencias cuando la prevención ha fallado.

La distinción resulta importante. Un tratamiento tolerante al error no es aquel en el que nunca se produce una equivocación. Es aquel en el que una equivocación previsible encuentra barreras antes de convertirse en daño y en el que, si finalmente las atraviesa, la organización conserva capacidad para detectar lo ocurrido, reconstruirlo y aprender de ello.

6. El Servicio de Atención al Cliente como parte del mismo diseño

La cláusula 7.9 de ISO 31700-1 aporta una perspectiva especialmente útil para cerrar el recorrido. La norma extiende la operación de controles a los servicios y procesos de apoyo y señala que la protección de la privacidad no debería degradarse cuando la información pasa a esos entornos. Entre los procesos que contempla aparecen expresamente las funciones de soporte.

En una entidad financiera, una parte importante de la protección de los datos puede haberse diseñado alrededor de los sistemas transaccionales: autenticación, control de acceso, segregación, trazabilidad o confidencialidad de las comunicaciones. Sin embargo, los mismos datos continúan siendo tratados cuando un cliente presenta una reclamación o ejerce un derecho. Se genera un nuevo expediente, intervienen otras aplicaciones, pueden incorporarse documentos y se producen nuevas comunicaciones. La protección alcanzada en el servicio principal puede perder parte de su eficacia si los procesos de soporte reproducen las mismas relaciones entre datos y personas mediante mecanismos menos robustos.

Una revisión del SAC inspirada en la lógica de ISO 31700-1 podría comenzar, por ello, identificando qué requisitos de privacidad deben mantenerse cuando la información abandona el contexto transaccional y pasa al proceso de reclamaciones. No sería necesario replicar exactamente los mismos controles, porque el entorno y la finalidad son diferentes. Sí sería necesario comprobar que el cambio de proceso no introduce una degradación de protección que no haya sido identificada y evaluada.

La coherencia de identidad constituye un ejemplo claro. Si el sistema principal utiliza relaciones sólidas entre cliente, producto y operación, pero el expediente de reclamación permite reconstruir manualmente esas relaciones con menor capacidad de validación, el paso hacia soporte introduce una nueva superficie de riesgo. Algo semejante ocurre con la documentación: el hecho de que una persona tenga acceso legítimo a diferentes documentos dentro de la organización no significa que todos ellos deban estar igualmente disponibles en el contexto de cualquier reclamación.

Figura 6 (IA): El paso del proceso transaccional al SAC no debe introducir una degradación no identificada de las garantías de privacidad.

El Servicio de Atención al Cliente deja así de ocupar una posición periférica respecto de Privacy by Design. Forma parte del mismo ecosistema en el que los datos continúan siendo utilizados y, por tanto, del conjunto de procesos en los que deben conservarse las propiedades de privacidad previamente definidas.

7. De la infracción al aprendizaje verificable

La principal utilidad de ISO 31700-1 para volver sobre este expediente no consiste en añadir un nuevo nivel de cumplimiento al artículo 25 del RGPD. Su aportación es metodológica. Permite construir una continuidad entre elementos que, de otro modo, pueden quedar separados: el incidente aporta nueva evidencia; esa evidencia modifica la comprensión del riesgo; el riesgo se transforma en requisitos; los requisitos orientan controles; los controles se someten a pruebas y criterios de aceptación; y la experiencia real de funcionamiento vuelve a alimentar el análisis.

Esta continuidad modifica también la forma de valorar una medida correctiva. Después de un incidente, afirmar que se ha reforzado un procedimiento, modificado una aplicación o impartido nueva formación informa sobre una actuación realizada. Para saber si esa actuación responde adecuadamente al problema resulta necesario conocer qué modo de fallo pretendía tratar, qué requisito se derivó de él y qué evidencia permite concluir que el comportamiento del tratamiento ha cambiado.

El propio expediente proporciona material para construir esa evidencia. Una asociación incorrecta puede convertirse en un escenario de prueba; una incorporación documental improcedente permite comprobar la segregación contextual; un destinatario incompatible permite ensayar las barreras anteriores a la salida; y una brecha simulada permite medir la capacidad interna de detección, reconstrucción y escalado. La experiencia que inicialmente sirvió para identificar una deficiencia pasa así a formar parte del mecanismo mediante el cual se comprueba su corrección.

Esa transformación es probablemente la aportación más relevante de una lectura del caso desde ISO 31700-1. La privacidad desde el diseño no se agota en haber identificado riesgos ni en disponer de controles que puedan enumerarse. Adquiere una dimensión verificable cuando puede reconstruirse la relación entre el problema observado, el requisito formulado, la medida adoptada y la evidencia que demuestra cómo se comporta ante el mismo escenario que anteriormente produjo el daño.

En el primer análisis del expediente, la repetición de errores terminaba desplazando la atención desde la actuación individual hacia el diseño del tratamiento. Esta segunda lectura permite continuar ese recorrido sin abandonar los mismos hechos. Una vez que el incidente ha señalado una debilidad de diseño, puede utilizarse para reconstruir el modo de fallo, definir la propiedad que el tratamiento debería preservar y comprobar si los controles modifican realmente el comportamiento que permitió que la brecha se produjera.

La organización aprende del incidente cuando esa experiencia consigue alterar el diseño. Y puede demostrar que ha aprendido cuando es capaz de volver a enfrentar el tratamiento al mismo modo de fallo y obtener un resultado diferente.

Bibliografía

AGENCIA ESPAÑOLA DE PROTECCIÓN DE DATOS (AEPD) (2026). Resolución de terminación del procedimiento por pago voluntario. Expediente n.º EXP202312854. Procedimiento sancionador PS/00143/2025. CaixaBank, S.A. Agencia Española de Protección de Datos, Madrid.
https://www.aepd.es/documento/ps-00143-2025.pdf

COMITÉ EUROPEO DE PROTECCIÓN DE DATOS (EDPB) (2020). Directrices 4/2019 relativas al artículo 25. Protección de datos desde el diseño y por defecto. Versión 2.0, adoptada el 20 de octubre de 2020. European Data Protection Board.
https://www.edpb.europa.eu/documents/guideline/guidelines-42019-on-article-25-data-protection-by-design-and-by-default_es

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO) (2023). ISO 31700-1:2023. Consumer protection — Privacy by design for consumer goods and services — Part 1: High-level requirements. 1.ª ed. Geneva: International Organization for Standardization.
https://www.iso.org/standard/84977.html

PARLAMENTO EUROPEO Y CONSEJO DE LA UNIÓN EUROPEA (2016). Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento General de Protección de Datos). DOUE L 119, 4 de mayo de 2016, pp. 1–88.
https://eur-lex.europa.eu/eli/reg/2016/679/oj/spa

Autor y responsable editorial: Leocadio Marrero Trujillo.
El enfoque, la arquitectura, los criterios de análisis y las conclusiones de este artículo han sido definidos y validados por el autor. Durante su elaboración se han utilizado herramientas de inteligencia artificial generativa como apoyo para la estructuración, reformulación, edición y creación de determinados elementos gráficos.

El contenido ha sido sometido a revisión humana sustantiva, comprobación de fuentes y validación jurídica y técnica. El autor ha aprobado la versión definitiva y asume íntegramente la responsabilidad editorial sobre su contenido