El 25 de mayo de 2018 entró en aplicación directa en toda la Unión Europea el Reglamento (UE) 2016/679, más conocido como RGPD. No es una directiva que cada Estado transponga a su manera: es un reglamento, de aplicación directa y uniforme, lo que significa que sus artículos son derecho vigente en España sin necesidad de ley nacional que los reproduzca. España sí desarrolló una norma propia, la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD), que no sustituye al RGPD sino que lo completa: adapta los márgenes de maniobra que el propio Reglamento deja a los Estados miembros (edad de consentimiento de menores, régimen sancionador de las administraciones públicas, supuestos adicionales de DPO obligatorio) y añade un catálogo de derechos digitales sin equivalente directo en el RGPD.
Para un profesional de ciberseguridad, el RGPD no es «un tema de los abogados». El artículo 32 obliga a implantar medidas técnicas y organizativas apropiadas al riesgo; el artículo 33 impone un plazo de notificación de brechas —72 horas— que solo se puede cumplir si existe un plan de respuesta a incidentes ya probado; y el artículo 25 exige protección de datos desde el diseño y por defecto, lo que convierte a la privacidad en un requisito de arquitectura, no en un anexo legal que se redacta al final del proyecto. Este módulo construye el marco legal completo —principios, bases de legitimación, derechos, DPO, RAT, EIPD, brechas y sanciones— para que puedas dialogar con el departamento legal y con la AEPD desde el mismo nivel de rigor con el que dialogas con auditores de ISO/IEC 27001.
Qué aprenderás
- El ámbito de aplicación territorial del RGPD (artículo 3) y por qué alcanza a empresas fuera de la UE.
- Los conceptos básicos: dato personal, categorías especiales de datos (artículo 9), tratamiento, responsable, encargado e interesado, y la diferencia real entre responsable y encargado.
- Los siete principios del artículo 5 y las seis bases de legitimación del artículo 6, con criterio claro sobre cuándo aplica cada base.
- Los derechos ARSULIPO de los interesados (artículos 15 a 22), sus plazos de respuesta y sus excepciones.
- Cuándo es obligatorio nombrar un Delegado de Protección de Datos (DPO), sus funciones y su posición de independencia.
- Qué es el Registro de Actividades de Tratamiento (RAT) y cómo se construye una fila completa.
- Cuándo es obligatoria una Evaluación de Impacto (EIPD/DPIA) y cómo se ejecuta conforme al criterio de la AEPD.
- Las medidas de seguridad del artículo 32, su relación con ISO/IEC 27001 e ISO/IEC 27701, y la gestión de brechas en el plazo de 72 horas.
- El régimen de transferencias internacionales y el régimen sancionador del artículo 83, con sus dos niveles de multa.
Marco normativo y ámbito de aplicación
El marco aplicable en España tiene dos capas que hay que saber distinguir con precisión, porque en un informe de auditoría o en una cláusula contractual la cita incorrecta resta credibilidad inmediatamente:
Reglamento (UE) 2016/679 (RGPD)
Aprobado el 27 de abril de 2016 y de aplicación directa desde el 25 de mayo de 2018, deroga la anterior Directiva 95/46/CE. Al ser un reglamento europeo, no requiere transposición: sus 99 artículos y 173 considerandos son derecho directamente aplicable en los 27 Estados miembros, con el mismo texto y la misma numeración en todos ellos. Esto es relevante para el trabajo de auditoría transfronteriza: un control basado en el artículo 32 del RGPD es literalmente el mismo artículo en Madrid, en Berlín o en Roma.
Ley Orgánica 3/2018 (LOPDGDD)
La LOPDGDD no puede contradecir al RGPD —sería nula por jerarquía normativa y primacía del derecho de la Unión— pero sí lo desarrolla en los márgenes que el propio Reglamento reserva a los Estados miembros. Sus aportaciones más relevantes para este módulo son: precisa los supuestos adicionales en que es obligatorio nombrar un DPO (artículo 34, que amplía el artículo 37 del RGPD), fija la edad de consentimiento de menores en internet en 14 años (artículo 7, frente a los 16 años que marca el RGPD como regla general salvo que el Estado miembro fije una edad menor, nunca inferior a 13), regula el régimen sancionador aplicable a las administraciones públicas (que no reciben multa económica sino otro tipo de medidas correctoras) y añade el Título X, un catálogo de derechos digitales —derecho al olvido en buscadores, derecho a la portabilidad en redes sociales, derecho a la desconexión digital, testamento digital— sin equivalente directo en el RGPD.
Ámbito de aplicación territorial (artículo 3 RGPD)
Es uno de los puntos que con más frecuencia se subestima. El RGPD no se aplica solo a empresas establecidas en la UE. El artículo 3 establece dos criterios independientes:
- Criterio de establecimiento (art. 3.1): se aplica al tratamiento de datos personales «en el contexto de las actividades de un establecimiento» del responsable o del encargado en la Unión, con independencia de que el tratamiento en sí tenga lugar dentro o fuera de la UE. Una empresa española que subcontrata su hosting a un proveedor en Singapur sigue sujeta al RGPD.
- Criterio de mercado / extraterritorialidad (art. 3.2): se aplica al tratamiento de datos de interesados que se encuentren en la Unión, realizado por un responsable o encargado NO establecido en la UE, cuando las actividades de tratamiento estén relacionadas con: a) la oferta de bienes o servicios a esos interesados, con independencia de que a estos se les exija pago, o b) el control de su comportamiento, en la medida en que este tenga lugar dentro de la Unión.
Consecuencia práctica: una tienda online estadounidense sin ninguna sede en Europa, que vende a clientes en España y usa cookies de seguimiento de comportamiento, está sujeta al RGPD igual que una empresa española. Es el mismo razonamiento que hace el Reglamento DORA o la Directiva NIS2 al extender obligaciones a proveedores extracomunitarios que prestan servicio a entidades europeas.
Conceptos fundamentales
El artículo 4 del RGPD contiene 26 definiciones. Las que sostienen todo el resto del módulo son estas seis:
Dato personal (art. 4.1)
«Toda información sobre una persona física identificada o identificable («el interesado»)». Se considera identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador (nombre, número de identificación, datos de localización, identificador en línea) o mediante uno o varios elementos propios de su identidad física, fisiológica, genética, psíquica, económica, cultural o social. La definición es deliberadamente amplia: una dirección IP, un identificador publicitario de un móvil o una combinación de código postal más fecha de nacimiento pueden ser datos personales si permiten, razonablemente, identificar a alguien.
Categorías especiales de datos (art. 9)
El RGPD distingue una categoría de datos con protección reforzada: los que revelan origen étnico o racial, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, y el tratamiento de datos genéticos, datos biométricos dirigidos a identificar de manera unívoca a una persona, datos relativos a la salud, o datos relativos a la vida sexual o la orientación sexual. Su tratamiento está prohibido por defecto (art. 9.1), salvo que concurra una de las diez excepciones tasadas del artículo 9.2, entre ellas el consentimiento explícito (no basta el consentimiento «normal» del artículo 6), la necesidad para el cumplimiento de obligaciones en el ámbito laboral y de seguridad social, o razones de interés público esencial en el ámbito de la salud pública. Los datos relativos a condenas e infracciones penales tienen un régimen separado y también reforzado en el artículo 10.
Tratamiento (art. 4.2)
«Cualquier operación o conjunto de operaciones realizadas sobre datos personales o conjuntos de datos personales, ya sea por procedimientos automatizados o no». La definición incluye recogida, registro, organización, estructuración, conservación, adaptación, extracción, consulta, utilización, comunicación por transmisión, difusión, cotejo, limitación, supresión o destrucción. Prácticamente cualquier interacción de un sistema de información con un dato personal es, jurídicamente, un «tratamiento».
Responsable del tratamiento vs. encargado del tratamiento
Esta distinción es la que con más frecuencia se confunde en la práctica, y tiene consecuencias directas sobre responsabilidad y sanción:
- Responsable del tratamiento (art. 4.7): la persona física o jurídica, autoridad pública, servicio u otro organismo que, solo o junto con otros, determina los fines y medios del tratamiento. Es quien decide «para qué» se tratan los datos y, en gran medida, «cómo». Ejemplo: una tienda online que decide recoger el email de sus clientes para enviarles newsletter.
- Encargado del tratamiento (art. 4.8): la persona física o jurídica, autoridad pública, servicio u otro organismo que trata datos personales por cuenta del responsable, siguiendo sus instrucciones. Ejemplo: la plataforma de email marketing que envía la newsletter siguiendo instrucciones del responsable, o el proveedor de hosting que almacena la base de datos de clientes.
El artículo 28 exige que la relación entre responsable y encargado se formalice mediante contrato o acto jurídico vinculante (el «contrato de encargado de tratamiento» o DPA, Data Processing Agreement) que fije, entre otros extremos, el objeto y duración del tratamiento, su naturaleza y finalidad, el tipo de datos, las categorías de interesados y las obligaciones y derechos del responsable. Si el encargado va más allá de las instrucciones recibidas y decide por su cuenta fines o medios del tratamiento, la ley lo reclasifica automáticamente como responsable respecto de ese tratamiento concreto (art. 28.10), con toda la responsabilidad que ello implica.
Interesado
La persona física a quien se refieren los datos personales objeto de tratamiento. El RGPD protege exclusivamente a personas físicas: los datos de personas jurídicas (una sociedad mercantil) quedan fuera de su ámbito de protección, salvo que en la práctica identifiquen indirectamente a una persona física (por ejemplo, el nombre de un autónomo que coincide con la razón social).
Los principios del artículo 5
El artículo 5.1 recoge seis principios sustantivos que rigen todo tratamiento, y el artículo 5.2 añade un séptimo principio, de naturaleza distinta: la responsabilidad proactiva. Cualquier tratamiento que se diseñe, técnico o no, debe poder justificarse frente a estos siete principios.
| Principio (art. 5) | En qué consiste | Ejemplo de incumplimiento habitual |
|---|---|---|
| Licitud, lealtad y transparencia (5.1.a) | El tratamiento debe tener una base de legitimación válida (art. 6), no debe engañar al interesado sobre cómo se usan sus datos, y debe informarse de forma accesible y comprensible | Recoger datos para «mejorar el servicio» sin explicar que en realidad se usan para perfilado publicitario |
| Limitación de la finalidad (5.1.b) | Los datos se recogen con fines determinados, explícitos y legítimos, y no se tratan posteriormente de forma incompatible con esos fines | Usar la base de datos de clientes de una tienda (recogida para gestionar pedidos) para venderla a un tercero con fines de prospección comercial no anunciada |
| Minimización de datos (5.1.c) | Los datos deben ser adecuados, pertinentes y limitados a lo necesario en relación con los fines del tratamiento | Pedir el DNI y la fecha de nacimiento completa para suscribirse a una newsletter |
| Exactitud (5.1.d) | Los datos deben ser exactos y, si es necesario, actualizados; deben adoptarse medidas razonables para que se supriman o rectifiquen sin dilación los datos inexactos | Mantener indefinidamente una dirección de envío obsoleta que genera entregas fallidas repetidas sin mecanismo de corrección |
| Limitación del plazo de conservación (5.1.e) | Los datos se mantienen en forma que permita identificar al interesado durante no más tiempo del necesario para los fines del tratamiento, salvo excepciones tasadas (archivo de interés público, fines estadísticos, investigación) | Conservar indefinidamente los datos de candidatos a un proceso de selección ya cerrado sin política de borrado |
| Integridad y confidencialidad (5.1.f) | Tratamiento con seguridad adecuada, incluida la protección contra el tratamiento no autorizado o ilícito y contra su pérdida, destrucción o daño accidental, mediante medidas técnicas u organizativas apropiadas | Base de datos de clientes accesible sin autenticación desde un endpoint API mal configurado |
| Responsabilidad proactiva / accountability (5.2) | El responsable debe ser capaz de DEMOSTRAR el cumplimiento de los principios anteriores, no solo cumplirlos; la carga de la prueba recae sobre el responsable | Afirmar que se cumple el RGPD sin RAT, sin política de privacidad actualizada, sin evidencia documental de las decisiones de legitimación tomadas |
El principio de responsabilidad proactiva es el que conecta el RGPD directamente con la disciplina de GRC de este curso: no basta con que el tratamiento sea lícito, hay que poder acreditarlo documentalmente en cualquier momento ante la AEPD, exactamente igual que un SGSI certificado en ISO/IEC 27001 debe mantener evidencia auditable, no solo controles implantados de facto.
Las bases de legitimación del artículo 6
Todo tratamiento de datos personales necesita, como mínimo, una de estas seis bases jurídicas. No son alternativas libres: cada base tiene un supuesto de hecho concreto, y elegir la base equivocada —típicamente, usar «consentimiento» quiere cuando el tratamiento en realidad se sostiene en la ejecución de un contrato— genera problemas serios, porque el consentimiento es revocable en cualquier momento (art. 7.3) y las demás bases no.
| Base (art. 6.1) | Cuándo aplica | Ejemplo |
|---|---|---|
| a) Consentimiento | El interesado ha dado su consentimiento para uno o varios fines específicos; debe ser libre, específico, informado e inequívoco (art. 4.11), mediante una declaración o una clara acción afirmativa; el silencio o las casillas premarcadas NO son consentimiento válido | Suscripción voluntaria a una newsletter comercial, con casilla sin marcar por defecto |
| b) Ejecución de un contrato | El tratamiento es necesario para ejecutar un contrato en el que el interesado es parte, o para aplicar medidas precontractuales a petición suya | Usar la dirección de envío de un cliente para entregar el pedido que ha comprado |
| c) Obligación legal | El tratamiento es necesario para cumplir una obligación legal aplicable al responsable | Conservar facturas durante el plazo exigido por la normativa fiscal y mercantil, o comunicar datos a la Agencia Tributaria cuando la ley lo exige |
| d) Interés vital | El tratamiento es necesario para proteger intereses vitales del interesado o de otra persona física, cuando este no está en condiciones de dar su consentimiento; se reserva típicamente para emergencias sanitarias | Comunicar el historial de alergias de un paciente inconsciente al equipo médico de urgencias |
| e) Interés público / poderes públicos | El tratamiento es necesario para el cumplimiento de una misión realizada en interés público o en ejercicio de poderes públicos conferidos al responsable | Un ayuntamiento que trata datos del padrón municipal para gestionar servicios públicos |
| f) Interés legítimo | El tratamiento es necesario para satisfacer intereses legítimos del responsable o de un tercero, siempre que no prevalezcan los intereses o derechos y libertades fundamentales del interesado; exige un test de ponderación (balancing test) documentado, y NO puede usarse por autoridades públicas en el ejercicio de sus funciones | Videovigilancia proporcionada de un local comercial para prevenir hurtos, con cartel informativo y sin grabar zonas de descanso de empleados |
Un criterio práctico que evita el error más común del sector: si existe un contrato y el tratamiento es necesario para prestar el servicio contratado, la base es la letra b), no el consentimiento. Pedir consentimiento para tratamientos que en realidad son necesarios contractualmente es, además de innecesario, contraproducente: si el interesado revoca ese «consentimiento» superfluo, se genera la falsa impresión de que hay que dejar de prestar el servicio, cuando la base real (ejecución contractual) no depende de esa revocación. El consentimiento debe reservarse para lo que realmente es voluntario y añadido: marketing directo no necesario para el contrato, cesión a terceros no imprescindible, o cookies no esenciales.
Los derechos de los interesados (arts. 15 a 22)
El RGPD reconoce siete derechos que en el sector se conocen habitualmente por el acrónimo mnemotécnico ARSULIPO (Acceso, Rectificación, Supresión, Limitación, Portabilidad, Oposición, y decisiones automatizadas). Todos ellos se ejercen de forma gratuita, salvo solicitudes manifiestamente infundadas o excesivas, en particular por su carácter repetitivo (art. 12.5), en cuyo caso el responsable puede cobrar un canon razonable o negarse a actuar.
| Derecho | Artículo | Contenido | Plazo de respuesta |
|---|---|---|---|
| Acceso | 15 | Obtener confirmación de si se tratan datos propios y, en tal caso, acceder a ellos y a la información sobre el tratamiento (finalidad, categorías de datos, destinatarios, plazo de conservación, origen) | 1 mes desde la recepción de la solicitud |
| Rectificación | 16 | Obtener la rectificación de datos personales inexactos, y que se completen los datos incompletos | 1 mes |
| Supresión («derecho al olvido») | 17 | Obtener la supresión de los datos cuando concurra alguna causa tasada (los datos ya no son necesarios, se retira el consentimiento, hay oposición y no hay motivo legítimo prevalente, tratamiento ilícito); no es un derecho absoluto: cede ante obligaciones legales de conservación, ejercicio de la libertad de expresión o defensa de reclamaciones | 1 mes |
| Limitación del tratamiento | 18 | Obtener que el tratamiento se limite (los datos se conservan pero no se tratan activamente) mientras se resuelve una impugnación de exactitud, una oposición, o cuando el tratamiento es ilícito pero el interesado prefiere la limitación a la supresión | 1 mes |
| Portabilidad | 20 | Recibir los datos propios en formato estructurado, de uso común y lectura mecánica, y transmitirlos a otro responsable; solo aplica cuando el tratamiento se basa en consentimiento o contrato Y se realiza por medios automatizados | 1 mes |
| Oposición | 21 | Oponerse al tratamiento basado en interés legítimo o misión de interés público (art. 6.1.e/f), incluida la elaboración de perfiles; oposición ABSOLUTA e incondicional cuando el fin es la mercadotecnia directa | 1 mes |
| Decisiones automatizadas | 22 | No ser objeto de una decisión basada únicamente en tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos o le afecte significativamente de modo similar, salvo excepciones tasadas (necesidad contractual, autorización legal, o consentimiento explícito, con garantías de intervención humana) | No aplica plazo de respuesta a solicitud; es un derecho de oposición previo a la decisión |
El plazo general de un mes (art. 12.3) es prorrogable otros dos meses cuando sea necesario, teniendo en cuenta la complejidad y el número de solicitudes, pero el responsable debe informar al interesado de la prórroga y de los motivos dentro del primer mes. Si el responsable decide no atender la solicitud, debe informar al interesado, también en el plazo de un mes, de los motivos y de su derecho a reclamar ante una autoridad de control y a interponer una acción judicial.
El Delegado de Protección de Datos (DPO)
Cuándo es obligatorio
El artículo 37.1 del RGPD obliga a designar un DPO en tres supuestos: a) el tratamiento lo lleva a cabo una autoridad u organismo público, excepto los tribunales que actúen en ejercicio de su función judicial; b) las actividades principales del responsable o encargado consisten en operaciones de tratamiento que requieren una observación habitual y sistemática de interesados a gran escala; o c) las actividades principales consisten en el tratamiento a gran escala de categorías especiales de datos (art. 9) o de datos relativos a condenas e infracciones penales (art. 10).
El artículo 34 de la LOPDGDD amplía sustancialmente estos supuestos para España, obligando además, entre otros, a: colegios profesionales y sus consejos generales; centros docentes que ofrezcan enseñanza en cualquiera de los niveles de la legislación educativa, así como universidades públicas y privadas; entidades que exploten redes y presten servicios de comunicaciones electrónicas cuando traten habitual y sistemáticamente datos a gran escala; prestadores de servicios de la sociedad de la información cuando elaboren perfiles a gran escala; entidades de crédito; establecimientos financieros de crédito; entidades aseguradoras y reaseguradoras; empresas de servicios de inversión; distribuidoras y comercializadoras de electricidad y de gas natural; entidades responsables de ficheros de solvencia patrimonial y crédito, o de ficheros comunes para la prevención del fraude; entidades que desarrollen actividades de publicidad y prospección comercial que incluyan elaboración de perfiles; centros sanitarios legalmente obligados a mantener historias clínicas de pacientes; entidades que tengan como uno de sus objetos la emisión de informes comerciales; operadores de juego; y federaciones deportivas cuando traten datos de menores de edad. La lista completa es notablemente más extensa que la del RGPD y conviene revisarla artículo por artículo cuando se hace un análisis de aplicabilidad.
Funciones (art. 39 RGPD)
El DPO tiene como mínimo las siguientes funciones: informar y asesorar al responsable, al encargado y a los empleados que traten datos, de sus obligaciones; supervisar el cumplimiento del RGPD, de otras normas de protección de datos y de las políticas internas, incluida la asignación de responsabilidades, la concienciación y formación del personal, y las auditorías correspondientes; ofrecer asesoramiento sobre la evaluación de impacto (EIPD) y supervisar su ejecución; cooperar con la autoridad de control; y actuar como punto de contacto para la autoridad de control y para los interesados.
Posición e independencia (art. 38)
El DPO debe involucrarse «adecuada y tempestivamente» en todas las cuestiones relativas a la protección de datos, y el responsable debe garantizarle los recursos necesarios y el acceso a los datos y operaciones de tratamiento para desempeñar sus funciones. El artículo 38.3 establece la garantía de independencia más citada: el DPO no recibirá ninguna instrucción en lo que respecta al desempeño de sus funciones, y no podrá ser destituido ni sancionado por desempeñarlas. Debe rendir cuentas directamente al más alto nivel jerárquico del responsable o del encargado. El DPO puede ser interno o externalizado, y puede compartirse entre varias entidades (frecuente en grupos empresariales o en administraciones públicas de tamaño reducido), pero en ningún caso puede ocupar simultáneamente un puesto que determine los fines y medios del tratamiento —por ejemplo, ser a la vez director de sistemas o director de marketing— porque generaría un conflicto de interés estructural con su función supervisora.
El Registro de Actividades de Tratamiento (RAT, art. 30)
El RAT es el inventario formal de todos los tratamientos de datos personales que realiza una organización. Es, para protección de datos, el equivalente al inventario de activos de ISO/IEC 27001 (control 5.9 de ISO/IEC 27002:2022): sin un registro completo y actualizado, es materialmente imposible acreditar el principio de responsabilidad proactiva del artículo 5.2, y es de hecho uno de los primeros documentos que solicita la AEPD al iniciar una inspección.
Quién debe llevarlo
El artículo 30.5 exime de la obligación a organizaciones de menos de 250 empleados, salvo que el tratamiento realizado pueda entrañar un riesgo para los derechos y libertades de los interesados, no sea ocasional, o incluya categorías especiales de datos (art. 9) o datos de condenas e infracciones penales (art. 10). En la práctica, esta excepción es casi teórica: cualquier empresa que trate datos de clientes, empleados o proveedores de forma no ocasional —lo cual describe a la inmensa mayoría de las pymes— queda dentro de la obligación. La AEPD recomienda, como buena práctica generalizada, que toda organización lleve su RAT independientemente del tamaño.
Qué campos contiene
El responsable del tratamiento debe registrar, como mínimo: el nombre y datos de contacto del responsable y, en su caso, del corresponsable, del representante y del DPO; los fines del tratamiento; una descripción de las categorías de interesados y de categorías de datos personales; las categorías de destinatarios a quienes se comunicaron o comunicarán los datos, incluidos los de terceros países u organizaciones internacionales; en su caso, las transferencias internacionales y la documentación de garantías; los plazos previstos para la supresión de las distintas categorías de datos; y una descripción general de las medidas técnicas y organizativas de seguridad (art. 32). El encargado del tratamiento debe llevar un registro equivalente, con campos adaptados a su rol (art. 30.2).
Ejemplo de una fila de RAT para el tratamiento «Gestión de clientes de e-commerce»:
Actividad de tratamiento: Gestión de pedidos y clientes de tienda online
Responsable del tratamiento: Textiles Rioja, S.A. — CIF B-00000000
Contacto DPO: dpo@textilesrioja.example / +34 900 000 000
Finalidad: Gestionar el proceso de compra, envío y facturación de pedidos
Base de legitimación: Ejecución de un contrato (art. 6.1.b RGPD); obligación
legal para datos de facturación (art. 6.1.c RGPD)
Categorías de interesados: Clientes (personas físicas) que compran en la tienda online
Categorías de datos: Identificativos (nombre, DNI/NIF), contacto (email,
teléfono, dirección de envío), datos bancarios (últimos 4 dígitos de tarjeta,
vía pasarela de pago), historial de pedidos
Categorías de destinatarios: Proveedor de logística (encargado del
tratamiento), pasarela de pago (encargado del tratamiento), Agencia
Tributaria (obligación legal)
Transferencias internacionales: No aplica / [si aplica: proveedor de email
marketing en EE.UU., acogido a <mecanismo de transferencia>]
Plazo de conservación: Datos de pedido: mientras dure la relación comercial
+ 6 años (obligación mercantil, art. 30 Código de Comercio); datos de
facturación: plazo fiscal aplicable
Medidas de seguridad: Cifrado en tránsito (TLS 1.3) y en reposo de la base
de datos; control de acceso basado en roles; copia de seguridad diaria
cifrada; registro de accesos (logging)
La Evaluación de Impacto relativa a la Protección de Datos (EIPD/DPIA, art. 35)
Cuándo es obligatoria
El artículo 35.1 exige realizar una EIPD, con carácter previo al tratamiento, cuando sea probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías, por su naturaleza, alcance, contexto o fines, entrañe un alto riesgo para los derechos y libertades de las personas físicas. El propio artículo 35.3 da tres ejemplos explícitos: evaluación sistemática y exhaustiva de aspectos personales basada en tratamiento automatizado, incluida la elaboración de perfiles, con efectos jurídicos o similarmente significativos; tratamiento a gran escala de categorías especiales de datos (art. 9) o de datos de condenas e infracciones penales (art. 10); y observación sistemática a gran escala de una zona de acceso público (por ejemplo, videovigilancia extensa).
El criterio de la AEPD
La AEPD, siguiendo las directrices del antiguo Grupo de Trabajo del Artículo 29 (hoy Comité Europeo de Protección de Datos, CEPD), publicó en 2019 una lista orientativa de tipos de tratamiento que requieren EIPD, construida sobre nueve criterios (entre ellos: evaluación o puntuación, decisiones automatizadas con efecto legal o significativo, observación sistemática, datos sensibles o de carácter altamente personal, tratamiento a gran escala, cotejo o combinación de conjuntos de datos, datos de interesados vulnerables como menores, uso innovador de tecnología, y tratamiento que impide a los interesados ejercer un derecho o usar un servicio). Como regla práctica: si un tratamiento cumple dos o más de estos criterios, es muy probable que requiera EIPD; con uno solo, conviene documentar razonadamente por qué se descarta.
Cómo se hace
El artículo 35.7 fija el contenido mínimo: una descripción sistemática de las operaciones de tratamiento y de los fines, incluido, en su caso, el interés legítimo perseguido por el responsable; una evaluación de la necesidad y proporcionalidad de las operaciones respecto a su finalidad; una evaluación de los riesgos para los derechos y libertades de los interesados; y las medidas previstas para afrontar los riesgos, incluidas garantías, medidas de seguridad y mecanismos que garanticen la protección de datos personales. Cuando el DPO existe, debe asesorar sobre la EIPD y supervisar su realización (art. 39.1.c). Si, pese a las medidas previstas, la EIPD revela que el tratamiento entrañaría un alto riesgo residual si el responsable no toma medidas para mitigarlo, es obligatorio consultar previamente a la autoridad de control (art. 36), que dispone de hasta ocho semanas —ampliables seis más en casos complejos— para responder por escrito.
Medidas de seguridad (artículo 32)
El artículo 32 no impone una lista cerrada de controles técnicos, sino un enfoque basado en el riesgo: el responsable y el encargado deben aplicar medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, teniendo en cuenta el estado de la técnica, los costes de aplicación, y la naturaleza, alcance, contexto y fines del tratamiento, así como el riesgo de probabilidad y gravedad variable para los derechos y libertades de las personas físicas. El propio artículo cita expresamente, entre otras: la seudonimización y el cifrado de datos personales; la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento; la capacidad de restaurar la disponibilidad y el 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 regular de la eficacia de las medidas.
Seudonimización y cifrado
El artículo 4.5 define la seudonimización como el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado sin utilizar información adicional, siempre que esta se mantenga separada y sujeta a medidas técnicas y organizativas que garanticen que los datos no se atribuyen a una persona identificada o identificable. A diferencia de la anonimización, la seudonimización es reversible (existe la clave para revertirla) y por tanto los datos seudonimizados siguen siendo datos personales a efectos del RGPD, pero su uso reduce el riesgo y es citado expresamente en los artículos 6.4.e, 25 y 32 como medida que favorece el cumplimiento. El cifrado, tanto en tránsito como en reposo, cumple una función distinta pero complementaria: no reduce la identificabilidad del dato, pero limita drásticamente el impacto de un acceso no autorizado, hasta el punto de que el propio artículo 34.3.a exime de la obligación de comunicar la brecha a los afectados cuando los datos afectados estaban cifrados con una medida que los hace ininteligibles para terceros no autorizados.
Relación con ISO/IEC 27001 e ISO/IEC 27701
El artículo 32.1 no exige una certificación concreta, pero el artículo 32.3 sí reconoce expresamente que la adhesión a un código de conducta aprobado o a un mecanismo de certificación aprobado puede utilizarse como elemento para demostrar el cumplimiento. En la práctica del sector, ISO/IEC 27001 —cubierta en profundidad en el Módulo 5 de este curso— es el marco de referencia habitual para implantar y demostrar de forma auditable las medidas técnicas y organizativas del artículo 32: su Anexo A aporta controles concretos (cifrado, control de acceso, gestión de vulnerabilidades, continuidad) que dan contenido operativo a la obligación legal, deliberadamente abstracta, del RGPD. ISO/IEC 27701:2019 va un paso más allá: es una extensión de ISO/IEC 27001 e ISO/IEC 27002 específica para la gestión de la información de privacidad (PIMS, Privacy Information Management System), que añade controles orientados directamente a responsables y encargados del tratamiento —gestión del consentimiento, derechos de los interesados, minimización, transferencias internacionales— y que muchas organizaciones adoptan precisamente para tener una traza de cumplimiento del RGPD certificable por un tercero independiente, en lugar de depender solo de una autoevaluación interna.
Brechas de datos personales (arts. 33 y 34)
El artículo 4.12 define la violación de la seguridad de los datos personales («brecha») como toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos. La definición cubre tres dimensiones distintas de impacto —confidencialidad, integridad, disponibilidad— exactamente las mismas que sostienen cualquier análisis de riesgo de ciberseguridad: un ransomware que cifra (no exfiltra) una base de datos de clientes es, igualmente, una brecha a efectos del RGPD, porque compromete la disponibilidad.
Notificación a la autoridad de control (art. 33)
En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente —en España, la AEPD, salvo tratamientos exclusivamente autonómicos donde exista autoridad autonómica propia (Cataluña, País Vasco, Andalucía)— sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación constituya un riesgo para los derechos y libertades de las personas físicas. Si la notificación no se produce en ese plazo, debe acompañarse de los motivos de la dilación. El contenido mínimo de la notificación (art. 33.3) incluye: la naturaleza de la brecha, con las categorías y el número aproximado de interesados afectados y de registros de datos afectados; el nombre y los datos de contacto del DPO o de otro punto de contacto; las consecuencias probables; y las medidas adoptadas o propuestas para poner remedio y, en su caso, mitigar los efectos negativos. Cuando el encargado del tratamiento detecta la brecha, debe notificarlo al responsable sin dilación indebida (art. 33.2): el reloj de las 72 horas corre para el responsable, pero el encargado tiene su propia obligación de alertar cuanto antes.
Comunicación a los interesados (art. 34)
Cuando la brecha entrañe probablemente un alto riesgo para los derechos y libertades de las personas físicas —un umbral más exigente que el de la notificación a la autoridad—, el responsable debe comunicarlo también directamente a los interesados afectados, sin dilación indebida, en lenguaje claro y sencillo. El artículo 34.3 exime de esta comunicación directa en tres supuestos: si el responsable había adoptado medidas de protección técnicas y organizativas apropiadas, en particular cifrado, que hacen ininteligibles los datos para terceros no autorizados; si ha tomado medidas ulteriores que garanticen que ya no existe la probabilidad de materialización del alto riesgo; o si supone un esfuerzo desproporcionado, en cuyo caso se opta por una comunicación pública o medida equivalente.
La gestión técnica de la brecha
El plazo de 72 horas empieza a contar cuando el responsable «tiene constancia» de la brecha, no cuando la confirma en todos sus detalles, lo que en la práctica exige tener ya activado un proceso de detección, contención y análisis forense antes de que ocurra el incidente: improvisar un análisis desde cero en ese plazo es la causa más frecuente de incumplimiento. La parte estrictamente técnica de esta respuesta —contención, erradicación, recuperación, análisis forense para determinar el alcance real de los datos afectados— se cubre en profundidad en el curso de DFIR y respuesta a incidentes, cuyo plan de respuesta debe estar coordinado de antemano con el DPO y con el departamento legal precisamente para poder cumplir este plazo. Cuando el vector de ataque afecta a un entorno Active Directory —origen habitual de brechas por compromiso de credenciales privilegiadas—, conviene revisar también el curso de defensa de Active Directory; y cuando el punto de entrada es una aplicación web expuesta, el curso de hacking web cubre las técnicas de explotación que con más frecuencia derivan en una brecha de datos personales notificable.
Transferencias internacionales
El Capítulo V del RGPD (arts. 44 a 50) regula la transferencia de datos personales a terceros países u organizaciones internacionales fuera del Espacio Económico Europeo. El principio general (art. 44) es que cualquier transferencia debe cumplir las condiciones del capítulo, de forma que el nivel de protección de las personas físicas garantizado por el RGPD no se vea menoscabado. Existen, en esencia, dos vías:
- Decisión de adecuación (art. 45): la Comisión Europea puede decidir que un tercer país, un territorio, uno o varios sectores específicos dentro de ese país, o una organización internacional, garantizan un nivel de protección adecuado. Si existe decisión de adecuación vigente, la transferencia no requiere autorización específica adicional. La Comisión ha reconocido adecuación, entre otros, a Reino Unido, Japón, Corea del Sur, Canadá (para el sector privado, con matices), Suiza, y a las entidades estadounidenses adheridas al EU-US Data Privacy Framework (marco vigente desde julio de 2023, sucesor del invalidado Privacy Shield tras la sentencia Schrems II del TJUE de 2020).
- Garantías adecuadas (art. 46): en ausencia de decisión de adecuación, la transferencia es posible si el responsable o encargado ofrece garantías adecuadas y los interesados cuentan con derechos exigibles y acciones legales efectivas. El mecanismo más utilizado en la práctica son las Cláusulas Contractuales Tipo (CCT/SCC) aprobadas por la Comisión Europea mediante la Decisión de Ejecución 2021/914, de 4 de junio de 2021, vigentes desde el 27 de junio de 2021, que sustituyeron a las cláusulas anteriores de 2001/2004/2010 y que incorporan un enfoque modular según la relación entre las partes (responsable a responsable, responsable a encargado, encargado a encargado, encargado a responsable). Otras garantías del artículo 46 incluyen las normas corporativas vinculantes (BCR, Binding Corporate Rules, típicas de grupos multinacionales) y los códigos de conducta o mecanismos de certificación aprobados.
Tras la sentencia Schrems II, el uso de CCT no es automático: exige una evaluación de impacto de la transferencia (Transfer Impact Assessment, TIA) que valore si la legislación del país de destino —en particular normas de acceso gubernamental a los datos— permite en la práctica que el importador cumpla las cláusulas contractuales, y documentar medidas suplementarias (técnicas, contractuales u organizativas) cuando sea necesario.
Régimen sancionador (artículo 83)
El artículo 83 establece un sistema de dos niveles de multa administrativa, cada uno vinculado a un listado tasado de infracciones, y exige en todo caso que la sanción sea efectiva, proporcionada y disuasoria:
| Nivel | Cuantía máxima | Ejemplos de infracciones (lista no exhaustiva) |
|---|---|---|
| Nivel 1 (art. 83.4) | Hasta 10.000.000 EUR o, tratándose de una empresa, el 2 % de su volumen de negocio total anual global del ejercicio financiero anterior, si esta cifra fuera mayor | Incumplimiento de las obligaciones del responsable/encargado relativas a diseño y por defecto (art. 25), medidas de seguridad (art. 32), notificación de brechas (arts. 33-34), evaluación de impacto (art. 35), o de las obligaciones del DPO y de certificación |
| Nivel 2 (art. 83.5) | Hasta 20.000.000 EUR o, tratándose de una empresa, el 4 % de su volumen de negocio total anual global del ejercicio financiero anterior, si esta cifra fuera mayor | Vulneración de los principios básicos del tratamiento (art. 5) y de las bases de legitimación (art. 6), de las condiciones del consentimiento (art. 7), de los derechos de los interesados (arts. 12-22), de las transferencias internacionales (arts. 44-49), o incumplimiento de una resolución de la autoridad de control |
El artículo 83.2 fija los criterios que la autoridad de control debe ponderar para fijar el importe dentro de esos máximos: naturaleza, gravedad y duración de la infracción; carácter intencionado o negligente; medidas adoptadas para paliar los daños; grado de responsabilidad habida cuenta de las medidas técnicas y organizativas aplicadas conforme a los artículos 25 y 32; historial de infracciones previas; grado de cooperación con la autoridad de control; categorías de datos afectadas; forma en que la autoridad tuvo conocimiento de la infracción (por ejemplo, si fue autonotificada); y beneficio financiero obtenido, entre otros. En España, la AEPD es la autoridad de control competente con carácter general (sin perjuicio de las autoridades autonómicas en su ámbito), y sus resoluciones son públicas y recurribles ante la jurisdicción contencioso-administrativa. Frente a las administraciones públicas, la LOPDGDD prevé un régimen distinto de responsabilidad, sin multa económica directa, sustituido por otras medidas correctoras y, en su caso, responsabilidad disciplinaria del personal implicado.
Caso práctico
«Kame Merch, S.L.» es una tienda online de camisetas y merchandising friki con sede en España. Analicemos la base de legitimación correcta para cuatro tratamientos distintos que realiza, y construyamos después una fila de RAT para uno de ellos.
1. Envío del pedido comprado por un cliente
Base correcta: ejecución de un contrato (art. 6.1.b). El cliente ha comprado una camiseta; para poder entregarla, es necesario tratar su nombre y dirección de envío. No hace falta pedir consentimiento: es una consecuencia directa e ineludible del contrato de compraventa ya perfeccionado.
2. Envío de newsletter comercial con ofertas y nuevos diseños
Base correcta: consentimiento (art. 6.1.a). El envío de comunicaciones comerciales no es necesario para cumplir el contrato de compraventa ya ejecutado; es un tratamiento adicional y voluntario. Requiere una casilla de aceptación específica, no premarcada, separada de la aceptación de condiciones generales de compra (que confundiría dos consentimientos de naturaleza distinta). Nota adicional: si el cliente ya compró antes y facilitó su email, el artículo 21.2 de la LSSI (no del RGPD) permite excepcionalmente el envío de comunicaciones comerciales sobre productos propios similares sin nuevo consentimiento expreso, siempre que se ofrezca en cada envío la posibilidad sencilla de oponerse (opt-out); es una excepción de origen distinto al RGPD y conviene no confundirla con la regla general.
Nota de verificación: LSSI en la excepción de e-marketing
Esta excepción del artículo 21.2 de la Ley 34/2002 (LSSI-CE) queda fuera del ámbito estricto del RGPD/LOPDGDD que cubre este módulo; se menciona por su relevancia práctica en e-commerce, pero su aplicación exacta conviene contrastarla siempre con asesoría legal específica en comercio electrónico antes de activarla operativamente.
3. Conservación de facturas emitidas a clientes
Base correcta: obligación legal (art. 6.1.c). La normativa mercantil y fiscal española obliga a conservar la documentación contable y las facturas durante un plazo determinado (con carácter general, 6 años desde el último asiento conforme al Código de Comercio, sin perjuicio de plazos fiscales específicos). No es una decisión discrecional del responsable ni depende del consentimiento del cliente: es un mandato legal que prevalece incluso si el cliente ejerce el derecho de supresión sobre otros datos.
4. Videovigilancia del almacén para prevenir robos
Base correcta: interés legítimo (art. 6.1.f). Prevenir hurtos y proteger las instalaciones es un interés legítimo del responsable, siempre que supere el test de ponderación: proporcionalidad (cámaras enfocadas al almacén, no a zonas de descanso del personal), cartel informativo visible conforme al deber de información, y plazo de conservación de las grabaciones limitado (con carácter general, un máximo de un mes salvo que las imágenes se incorporen a un procedimiento judicial o administrativo). Si en cambio se tratara de videovigilancia con reconocimiento facial para identificar de forma unívoca a las personas, el tratamiento pasaría a afectar a datos biométricos del artículo 9 y el interés legítimo dejaría de ser base suficiente en la mayoría de los casos, requiriendo además una EIPD previa.
Fila de RAT para el tratamiento 4 (videovigilancia)
Actividad de tratamiento: Videovigilancia del almacén de Kame Merch, S.L.
Responsable del tratamiento: Kame Merch, S.L. — CIF B-00000001
Contacto DPO: No aplica (no obligatorio por volumen; contacto de privacidad
designado voluntariamente: privacidad@kamemerch.example)
Finalidad: Prevención de hurtos y protección de instalaciones y mercancía
Base de legitimación: Interés legítimo del responsable (art. 6.1.f RGPD),
con test de ponderación documentado
Categorías de interesados: Empleados y visitantes que acceden físicamente
al almacén
Categorías de datos: Imagen captada por videocámaras (dato personal por
identificabilidad); NO se aplica reconocimiento facial ni biometría
Categorías de destinatarios: Ninguna comunicación a terceros salvo
requerimiento de autoridad judicial o policial
Transferencias internacionales: No aplica (grabación y almacenamiento
en servidor local en territorio español)
Plazo de conservación: Máximo 1 mes desde la captura, salvo incorporación
a un procedimiento judicial o administrativo en curso
Medidas de seguridad: Acceso restringido a las grabaciones mediante
usuario y contraseña individualizados; cartel informativo en accesos
al almacén conforme al deber de información (art. 13); registro de
quién accede a las grabaciones y cuándo
Errores comunes
- Usar «consentimiento» como base de legitimación por defecto para todo, incluidos tratamientos que en realidad se sostienen en la ejecución de un contrato o en una obligación legal; esto genera inseguridad jurídica porque el consentimiento es revocable en cualquier momento (art. 7.3) y las otras bases no.
- No tener Registro de Actividades de Tratamiento, o tenerlo desactualizado desde que se dio de alta el primer producto o servicio; es de los primeros documentos que solicita la AEPD en una inspección, y su ausencia es en sí misma indicio de falta de responsabilidad proactiva.
- No notificar una brecha en el plazo de 72 horas por no tener un plan de respuesta a incidentes ya diseñado y ensayado; improvisar el análisis forense y la valoración del riesgo dentro de ese plazo es la causa más habitual de incumplimiento del artículo 33.
- Confundir responsable y encargado del tratamiento, o no formalizar el contrato de encargado del artículo 28 con los proveedores tecnológicos (hosting, email marketing, CRM, pasarela de pago), dejando la relación sin cobertura contractual.
- Tratar la Evaluación de Impacto como un trámite burocrático posterior a la implantación del sistema, en lugar de como un análisis previo al diseño que puede (y debe) modificar decisiones técnicas antes de escribir una sola línea de código.
- Pedir más datos de los estrictamente necesarios «por si acaso son útiles en el futuro», vulnerando el principio de minimización (art. 5.1.c) y ampliando innecesariamente la superficie de exposición ante una eventual brecha.
- Asumir que, por no superar los 250 empleados, la organización queda automáticamente exenta del RAT, sin comprobar antes si el tratamiento es no ocasional o incluye categorías especiales de datos, que son las excepciones que reintroducen la obligación.
Ejercicio
«Ciber Academy Online, S.L.» imparte formación en ciberseguridad, tiene 40 empleados, trata datos de alumnos (nombre, email, historial de progreso en los cursos, y en algunos casos datos de discapacidad para adaptar exámenes), y usa una plataforma de terceros para el envío de emails transaccionales de la plataforma de aprendizaje. Responde, justificando cada respuesta con el artículo correspondiente:
- ¿Está obligada a nombrar un DPO? Analiza si encaja en algún supuesto del artículo 37 RGPD o del artículo 34 LOPDGDD.
- ¿Qué base de legitimación corresponde al tratamiento de los datos de discapacidad de los alumnos que solicitan adaptación de examen?
- ¿Está obligada a llevar RAT, pese a tener menos de 250 empleados?
- La plataforma de email transaccional de terceros, ¿es responsable o encargado del tratamiento? ¿Qué documento contractual debe existir con ella?
- Un atacante accede sin autorización a la base de datos de alumnos durante 3 días antes de ser detectado, y exfiltra nombres, emails y datos de discapacidad de 200 alumnos. ¿Qué plazo tiene la empresa para notificar a la AEPD, y debe además comunicarlo a los alumnos afectados?
Pista de corrección: (1) si imparte «enseñanza en cualquiera de los niveles establecidos en la legislación reguladora del derecho a la educación», encajaría en el art. 34.b LOPDGDD (centros docentes); si es formación no reglada, hay que analizar si trata a gran escala categorías especiales de datos (art. 9, aquí datos de discapacidad/salud), lo que puede activar el art. 37.1.c RGPD — en caso de duda razonable, la práctica prudente es nombrarlo. (2) Consentimiento explícito del alumno (art. 9.2.a), al tratarse de una categoría especial de datos y no encajar con claridad en las demás excepciones tasadas del art. 9.2 para esta relación contractual privada. (3) Sí: aunque tiene menos de 250 empleados, trata categorías especiales de datos (art. 9) de forma no ocasional, lo que reintroduce la obligación conforme al art. 30.5. (4) Encargado del tratamiento (envía emails siguiendo instrucciones y para los fines fijados por Ciber Academy); debe existir un contrato de encargado conforme al art. 28. (5) 72 horas desde que la empresa tuvo constancia de la brecha para notificar a la AEPD (art. 33); dado que incluye datos de categoría especial (discapacidad/salud) de 200 personas, es muy probable que constituya alto riesgo, por lo que además debe comunicarse a los alumnos afectados conforme al art. 34, salvo que concurra alguna de las tres excepciones tasadas del art. 34.3 (por ejemplo, si los datos estaban cifrados de forma que resultaran ininteligibles, lo cual habría que acreditar).
Preguntas frecuentes
¿El plazo de 72 horas del artículo 33 cuenta días naturales o laborables?
Cuenta horas naturales, sin distinción de festivos o fines de semana, desde el momento en que el responsable tiene constancia razonable de la brecha (no necesariamente desde que ocurrió técnicamente el incidente, que puede haber sucedido días u horas antes de ser detectado). Si el plazo no puede cumplirse, la notificación debe hacerse igualmente en cuanto sea posible, acompañada de las razones de la dilación (art. 33.1, segundo párrafo); no notificar en absoluto, o notificar tarde sin justificar el motivo, es lo que expone a sanción, no el mero hecho de agotar el plazo por la complejidad real del análisis forense.
¿Toda brecha de seguridad hay que notificarla a la AEPD?
No. El artículo 33.1 excluye la obligación de notificar a la autoridad cuando sea improbable que la violación de la seguridad constituya un riesgo para los derechos y libertades de las personas físicas. Esta valoración debe documentarse igualmente, aunque se concluya que no procede notificar: la ausencia de notificación no debe ser un silencio sin análisis, sino una decisión razonada y trazable, porque ante una eventual inspección de la AEPD el responsable debe poder acreditar por qué descartó el riesgo.
¿Puede una empresa pequeña prescindir del DPO si no encaja en ningún supuesto obligatorio?
Sí. Fuera de los supuestos tasados del artículo 37 RGPD y del artículo 34 LOPDGDD, la designación de DPO es voluntaria, y muchas pymes optan razonablemente por no tenerlo, asumiendo el cumplimiento a través de asesoría externa puntual o de la dirección. Dicho esto, conviene revisar la aplicabilidad con detalle: el listado de la LOPDGDD es más amplio de lo que intuitivamente se espera (incluye, por ejemplo, cualquier entidad que haga publicidad y prospección comercial con elaboración de perfiles), y una revisión superficial es la causa más común de creer erróneamente que la designación no es obligatoria.
¿El derecho al olvido (art. 17) obliga a borrar los datos siempre que el interesado lo pida?
No es un derecho absoluto. El propio artículo 17.3 establece excepciones tasadas en las que prevalece sobre la supresión: ejercicio de la libertad de expresión e información; cumplimiento de una obligación legal que exija el tratamiento (por ejemplo, la obligación mercantil de conservar facturas); razones de interés público en el ámbito de la salud pública; fines de archivo de interés público, fines de investigación científica o histórica, o fines estadísticos, en la medida en que el derecho pudiera hacer imposible u obstaculizar gravemente el logro de esos fines; o la formulación, el ejercicio o la defensa de reclamaciones. En estos casos el responsable debe explicar al interesado, dentro del plazo de un mes, por qué no procede la supresión total o parcial.
¿Qué diferencia hay entre una decisión de adecuación y las Cláusulas Contractuales Tipo para transferencias internacionales?
La decisión de adecuación (art. 45) es una determinación de la Comisión Europea sobre el país de destino en su conjunto (o un sector/territorio de ese país): si existe, cualquier transferencia hacia ese destino se trata, a efectos prácticos, como si fuera dentro de la UE, sin necesidad de garantías adicionales caso por caso. Las CCT (art. 46) son un mecanismo contractual que cada responsable debe firmar individualmente con cada importador de datos en un país sin decisión de adecuación, y que desde la sentencia Schrems II (2020) exige además una evaluación previa (TIA) de si la legislación de ese país concreto permite en la práctica cumplir esas cláusulas, documentando medidas suplementarias cuando sea necesario. La decisión de adecuación es, en ese sentido, una vía más simple pero depende enteramente de una decisión política de la Comisión que puede cambiar (como ocurrió con la invalidación del Privacy Shield).
«Toda violación de la seguridad de los datos personales deberá ser documentada por el responsable del tratamiento, incluyendo los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas. Dicha documentación permitirá a la autoridad de control verificar el cumplimiento de lo dispuesto en el presente artículo.» — Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016 (RGPD), artículo 33, apartado 5. Texto consolidado disponible en EUR-Lex.