La lección anterior cerró el mapa normativo señalando la única norma que alcanza a Nimbus siempre, sin umbrales de tamaño y sin depender de ningún cliente. Y con una particularidad que multiplica su exigencia: el historial de citas de una clínica de fisioterapia revela información sobre la salud de una persona, aunque en la base de datos solo haya un nombre, un teléfono y una fecha. Esta lección baja al detalle práctico: quién responde de qué, qué principios obligan, cómo se atiende un derecho de verdad —incluida la pregunta incómoda de cómo se borra a alguien que está dentro de una copia de seguridad—, qué documentos hay que tener escritos, y qué ocurre exactamente durante las 72 horas siguientes a descubrir una brecha.

⚠️ Nota de validación — léela antes de seguir

Esta lección es material formativo y no constituye asesoramiento jurídico. Las plantillas, criterios y ejemplos que contiene son didácticos y están construidos sobre una empresa ficticia. La aplicación real del RGPD depende de los tratamientos concretos, del sector, de los contratos y de la interpretación de la autoridad de control, y las normas y sus guías se actualizan. Antes de tomar cualquier decisión: verifica la versión vigente del Reglamento (UE) 2016/679, de la LO 3/2018 (LOPDGDD) y de las guías de la AEPD, y valida con un profesional —abogado especializado en protección de datos, delegado de protección de datos (DPD) o responsable de cumplimiento—. Un error en este terreno no se corrige con un parche.

1. Por qué esta lección importa especialmente a Nimbus
2. Conceptos con precisión: personal, seudonimizado, anónimo
3. Responsable y encargado: Nimbus es las dos cosas
4. Los principios del artículo 5, aplicados
5. Bases jurídicas: artículo 6 y el artículo 9 para datos de salud
6. Derechos de las personas y cómo se atienden de verdad
7. Obligaciones documentales: el RAT y la Evaluación de Impacto
8. Privacidad desde el diseño y por defecto
9. El artículo 32 y por qué el módulo 5 es su respuesta
10. Encargados, subencargados y el contrato del artículo 28
11. Transferencias internacionales
12. Notificación de brechas y el incidente de 02-06 bajo el RGPD
13. El DPD, el régimen sancionador y la relación con las clínicas

En la base de datos A-01 no hay diagnósticos, ni informes médicos, ni recetas. Hay nombres, correos, teléfonos y una tabla de citas con fecha, hora y centro. Un desarrollador razonable diría que eso son datos de contacto y una agenda. Y sin embargo: si el centro es una clínica de fisioterapia, saber que una persona concreta acude a ella todos los martes desde hace cuatro meses revela información sobre su salud. No hace falta el diagnóstico. El dato relativo a la salud no es solo el que describe una patología, sino cualquiera que permita deducir información sobre el estado de salud de una persona identificada o identificable. Y los datos de salud son una categoría especial del artículo 9, cuyo tratamiento está prohibido con carácter general salvo que concurra una de las excepciones tasadas del apartado 2.

Esto tiene tres consecuencias que atraviesan toda la lección y explican por qué Nimbus no puede tratar este asunto como una PYME cualquiera: la base jurídica es más exigente, porque no basta el artículo 6 y hace falta además una excepción del 9.2; la Evaluación de Impacto es probablemente obligatoria, porque hay tratamiento a gran escala de categorías especiales (apartado 7); y el umbral de riesgo para notificar una brecha a los afectados baja mucho, porque el riesgo para los derechos y libertades de una fuga de datos de salud es alto casi por definición (apartado 12).

Y un matiz de arquitectura que conviene fijar desde ya: el mismo campo tiene distinta naturaleza según el cliente. Una cita en un gimnasio es una cita; la misma fila, con tenant_id de una clínica, revela salud. Aplicar dos niveles de protección según el tenant complica la vida enormemente, así que la decisión correcta es tratar todo el historial de citas con el nivel de la categoría especial —lo que ya se decidió técnicamente en 03-07 con el cifrado a nivel de campo de las notas clínicas—.

Estas cuatro definiciones deciden si el RGPD aplica o no a un conjunto de datos, y se confunden constantemente.

El punto que más errores causa, y que ya se anticipó en 03-07: la seudonimización no saca los datos del RGPD. Es una medida de seguridad excelente —el artículo 32.1.a la cita expresamente— y reduce el impacto de una brecha, pero mientras exista en algún sitio la clave que permita revertirla, sigue habiendo dato personal y siguen aplicando todos los derechos y obligaciones. Muchos proyectos se diseñan sobre la creencia contraria y descubren tarde que su «base de datos anonimizada de analítica» es una base de datos personal sin base jurídica. La anonimización real, en cambio, es difícil: hay que eliminar no solo los identificadores directos, sino la posibilidad de reidentificación por combinación. Si Nimbus publica un panel con «pacientes por franja horaria, centro y código postal», una franja con dos personas en un código postal pequeño identifica a alguien; y las técnicas que lo evitan —agregación con umbral mínimo, generalización, ruido— destruyen parte de la utilidad del dato. De ahí la regla práctica para el equipo de Iván: ante la duda, es dato personal. El coste de tratar como personal algo que no lo era es documentación; el del error contrario es una infracción.

Esta distinción determina quién responde de qué, y es el error conceptual más frecuente en un SaaS. Responsable del tratamiento es quien decide los fines y los medios —para qué se tratan los datos y cómo, en lo esencial—; encargado es quien los trata por cuenta del responsable, siguiendo sus instrucciones documentadas.

Nimbus lleva dos sombreros a la vez, y confundirlos es caro:

La consecuencia práctica más importante, y la que hay que grabarse: si Nimbus usara el historial de citas de las clínicas para mejorar su producto, entrenar un modelo predictivo o elaborar informes de mercado, dejaría de ser encargado y pasaría a ser responsable de ese tratamiento —sin base jurídica, sin información a los pacientes y con datos de categoría especial—. Es una de las infracciones más graves que puede cometer un SaaS, y ocurre muchas veces sin mala fe, simplemente porque a alguien de producto le parece buena idea; por eso conviene que esté escrito en POL-05 y en la formación de desarrollo de 06-05. Y una precisión que suele sorprender: el encargado no está exento de responsabilidad. El artículo 82 permite que un interesado reclame directamente al encargado cuando incumple obligaciones que el Reglamento le impone específicamente o actúa fuera de las instrucciones del responsable. Ser encargado no es un escudo.

Los seis principios más el séptimo que los gobierna, con su traducción a decisiones concretas de Nimbus:

Minimización: ¿hace falta el DNI para reservar una sesión de fisioterapia? El ejercicio mental hay que hacerlo campo por campo, y casi siempre sobran cosas:

La conclusión de diseño es contraintuitiva para mucha gente de producto: el campo más seguro es el que no existe. Un DNI que no se recoge no se puede filtrar, no hay que cifrarlo, no aparece en una brecha y no hay que borrarlo. Cada campo eliminado del formulario reduce a la vez el riesgo, el trabajo de cumplimiento y el impacto de un incidente.

Política de retención de Nimbus (ejemplo didáctico; los plazos reales deben fijarse con asesoría y, en el caso de los datos de pacientes, los decide la clínica responsable, no Nimbus):

Dos disciplinas separan una política de retención real de una decorativa: los plazos se ejecutan solos —un cron o una política de ciclo de vida, no un recordatorio para Lucía— y cada plazo tiene una justificación escrita. «Por si acaso» no lo es; conservar indefinidamente incumple el artículo 5.1.e y es lo que convierte una brecha pequeña en una grande.

Toda operación necesita al menos una base jurídica del artículo 6, y no se pueden acumular a conveniencia: se elige una, se documenta y se comunica.

Por qué el consentimiento no es la mejor base casi nunca, siendo la que todo el mundo nombra primero: es revocable en cualquier momento y con la misma facilidad con que se dio, lo que deja al responsable en situación imposible si el tratamiento era imprescindible; debe ser libre, y si no se puede usar el servicio sin consentir, generalmente no lo es —condicionar la reserva al consentimiento de marketing es el vicio clásico—; y hay que poder demostrar que se obtuvo: quién, cuándo, con qué texto exacto y qué versión. Para el núcleo del servicio la base correcta suele ser la ejecución del contrato (6.1.b) para las citas y el interés legítimo (6.1.f) para los registros de seguridad, con la ponderación escrita. El consentimiento queda para lo que realmente es opcional: comunicaciones comerciales, cookies analíticas, funcionalidades accesorias.

El artículo 9 y los datos de salud. El tratamiento de categorías especiales está prohibido, salvo excepción del 9.2. Las relevantes aquí: a) consentimiento explícito —vía frecuente en el ámbito privado, y «explícito» exige manifestación clara y específica, no una casilla genérica—; h) medicina preventiva, diagnóstico o asistencia sanitaria, la vía natural de un centro sanitario y sujeta al secreto profesional del 9.3; f) reclamaciones; e i) salud pública, propia de autoridades.

Nota importante: la excepción del artículo 9 no sustituye a la base del artículo 6, se suma a ella; hacen falta las dos. Y quien las determina para los datos de pacientes es la clínica responsable, no Nimbus. Lo que sí debe hacer Nimbus son dos cosas: no imponer un diseño que obligue a la clínica a una base inadecuada —por ejemplo, un campo obligatorio de motivo clínico— y documentar en el contrato que no usará esos datos para fines propios.

Nota de validación. La elección de base jurídica y de excepción del artículo 9 es una decisión jurídica con consecuencias sancionadoras. Esta tabla es orientativa: consúltalo con un DPD o abogado.

El plazo es de un mes desde la recepción, prorrogable dos meses más por complejidad o número de solicitudes, informando de la prórroga y de sus motivos dentro del primer mes; la respuesta es gratuita salvo solicitudes manifiestamente infundadas o excesivas. Y estos son los tres problemas operativos reales, donde fallan las organizaciones:

(a) Verificar la identidad sin pedir de más. Si alguien escribe pidiendo todos los datos de otra persona, atenderlo sin verificar es una brecha; pero pedir copia del DNI por sistema es recoger un dato nuevo y excesivo. El criterio es usar medios que ya se tienen: si la persona escribe desde el correo asociado a su cuenta y confirma con un código enviado a ese correo o al teléfono registrado, la identidad está razonablemente acreditada. Solo ante dudas fundadas se pide información adicional, y proporcionada.

(b) A quién se dirige la solicitud. Un paciente de una clínica que escribe a Nimbus se dirige al encargado, no al responsable, y Nimbus no puede resolverla por su cuenta: debe redirigirla a la clínica sin dilación y asistirla (art. 28.3.e). Responder directamente sería actuar fuera de instrucciones.

(c) La supresión cuando hay copias de seguridad, el problema técnico que casi nadie explica bien. Si un paciente pide su supresión y Nimbus tiene copias diarias con 35 días de retención y Object Lock en modo COMPLIANCE (05-07), el dato seguirá existiendo dentro de esas copias y no se puede borrar de ellas —esa inmutabilidad es precisamente lo que protege frente al ransomware—. La solución aceptada por la práctica, siempre que se documente: (1) supresión efectiva e inmediata en los sistemas activos —base de datos, buckets, índices, cachés y terceros que hayan recibido el dato—; (2) las copias se declaran «congeladas»: no se borran, pero no se usan para reintroducir el dato; (3) la solicitud se registra en una lista de supresiones pendientes que sobrevive a la restauración; (4) el procedimiento de restauración incluye reaplicar esas supresiones antes de devolver el servicio, escrito en el runbook de 04-06 porque lo que no está escrito no se hará en mitad de una crisis; (5) las copias expiran solas a los 35 días y ahí la supresión es total; y (6) se informa al interesado de ese plazo residual.

Plantilla de procedimiento de atención de derechos:

Es el documento que la AEPD pide primero en cualquier actuación, y no tenerlo es en sí mismo una infracción. Aunque el artículo 30.5 prevé una excepción para organizaciones de menos de 250 empleados, decae cuando el tratamiento no es ocasional o incluye categorías especiales —ambas cosas ciertas aquí—, así que Nimbus está obligado a llevarlo, en su doble condición de responsable (art. 30.1) y de encargado (art. 30.2).

Dos advertencias: el RAT es un documento vivo —se actualiza cuando cambia un tratamiento, un subencargado o un plazo, y su fecha de revisión es lo primero que se mira— y no es un ejercicio literario: si dice que las notas van cifradas a nivel de campo, un inspector puede pedir que se demuestre.

Es obligatoria cuando el tratamiento entrañe un alto riesgo para los derechos y libertades, y el artículo 35.3 presume ese riesgo en tres supuestos: evaluación sistemática basada en tratamiento automatizado con efectos significativos, tratamiento a gran escala de categorías especiales y observación sistemática a gran escala de zonas de acceso público. A ellos se suma la lista de tipos de tratamiento que requieren EIPD publicada por la AEPD —consúltala en su versión vigente—.

¿Nimbus la necesita? Con altísima probabilidad sí, y quien la debe realizar es cada clínica responsable, con la asistencia de Nimbus que exige el artículo 28.3.f. El razonamiento: hay tratamiento de datos que revelan salud, a escala relevante (decenas de centros, miles de pacientes), a distancia y con subencargados, uno de ellos fuera del EEE. Reúne varios criterios a la vez, y cuando concurren dos o más la respuesta práctica es hacerla. Nimbus tiene un interés propio muy claro en hacer su propia EIPD del producto, aunque sea encargado: se convierte en un entregable comercial que sus clientes reutilizan, ahorra a cada clínica empezar de cero y responde por adelantado a media docena de cuestionarios. Contenido mínimo (art. 35.7), traducido:

El error más común en una EIPD merece subrayarse: copiar el análisis de riesgos de seguridad. Son análisis distintos. En 04-01 el impacto se medía en euros para Nimbus; en una EIPD se mide en daño a las personas —discriminación laboral si se sabe que alguien acude a rehabilitación, daño reputacional, angustia, pérdida de control sobre datos íntimos—. El mismo incidente tiene dos impactos distintos y hay que valorar los dos. Y si tras las medidas el riesgo residual sigue siendo alto, procede la consulta previa a la AEPD del artículo 36.

El artículo 25 exige medidas desde el diseño —al determinar los medios y durante el tratamiento— y por defecto —que solo se traten los datos necesarios para cada fin, sin intervención del usuario—. Traducido a decisiones de producto de Nimbus:

La última fila es la más importante y la más barata: convertir «¿este dato es necesario?» en un elemento de la plantilla de pull request de 06-01. Es privacidad desde el diseño implementada como hábito, y cuesta una línea de texto.

El artículo 32 exige «medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo», y menciona expresamente cuatro: seudonimización y cifrado; confidencialidad, integridad, disponibilidad y resiliencia permanentes; capacidad de restaurar rápidamente tras un incidente; y un proceso de verificación, evaluación y valoración regulares de la eficacia. No impone tecnologías concretas: obliga a decidir en función del riesgo y poder justificar la decisión, y todo el trabajo técnico del curso es exactamente esa justificación:

El artículo 32.1.d merece atención especial porque es el que casi nadie cumple: no basta con implantar, hay que verificar regularmente la eficacia. Es la tesis de 06-01 —el control no probado está «planificado»— y el objeto entero de 06-04. Un responsable que ante la AEPD dice «tenemos copias» y no puede enseñar un informe de restauración fechado no cumple el 32.1.c ni el 32.1.d, aunque las copias existan.

El artículo 28 exige que la relación con un encargado se rija por un contrato u otro acto jurídico con contenido mínimo tasado: es el documento que determina qué puede hacer Nimbus con los datos de las clínicas, y el que estas exigirán en cada renovación. Contenido obligatorio (art. 28.3), con su redacción práctica:

La cadena de subencargados es donde se acumulan los problemas. Nimbus subcontrata a tres proveedores que tocan datos —cloud (A-05), email transaccional (A-11) y consultora de sistemas (A-19)— y las reglas de los artículos 28.2 y 28.4 son tres. Primera: se necesita autorización del responsable, específica o general por escrito, y si es general hay que informar de cualquier incorporación o cambio y permitir oponerse —la práctica sana es una lista pública de subencargados con aviso de 30 días—. Segunda: al subencargado se le imponen las mismas obligaciones que Nimbus asumió frente a la clínica; no se puede prometer al cliente más de lo que se exige al proveedor. Y tercera, la que cambia la conversación de 04-04: Nimbus sigue respondiendo plenamente ante la clínica del cumplimiento del subencargado. Externalizar la ejecución no externaliza la responsabilidad, y el incidente de 02-06 es el ejemplo perfecto: Nimbus respondió ante sus clientes de un fallo que ocurrió en casa de otro.

Nota de validación. Los contratos del artículo 28, sus anexos y las cláusulas de auditoría y responsabilidad tienen efectos jurídicos y económicos directos. No se redactan con una plantilla de Internet: se validan con asesoría jurídica, y conviene revisar las cláusulas contractuales tipo que la Comisión Europea tiene publicadas para relaciones responsable-encargado.

El capítulo V regula las transferencias fuera del Espacio Económico Europeo, y lo importante para una PYME es que ocurren constantemente sin que nadie lo note: basta con que un proveedor SaaS aloje datos fuera, o que su personal de soporte acceda desde un tercer país. El acceso remoto desde fuera del EEE es una transferencia, aunque los servidores estén en Frankfurt. Ese matiz se olvida siempre.

Cuando se usan CCT hay que hacer además una evaluación de impacto de la transferencia (TIA): analizar si la legislación del país de destino permite accesos por autoridades que vacíen de contenido las garantías, y añadir medidas suplementarias si es necesario —cifrado con claves retenidas en el EEE, seudonimización, minimización de lo transferido—. El caso concreto de Nimbus. El proveedor de email transaccional (A-11) recibe nombre, dirección de correo y el texto del recordatorio, y tres medidas de minimización reducen el problema hasta hacerlo manejable. No enviar nunca el motivo de la cita: el texto mínimo del apartado 8 no es solo buena práctica, reduce la categoría de datos transferidos y saca la salud de la transferencia. No enviar el nombre del centro cuando revela especialidad sanitaria: «Tiene una cita el martes a las 17:00» con un enlace autenticado transfiere mucho menos que «Cita en Clínica de Rehabilitación Neurológica». Y evaluar un proveedor alojado en la UE, donde a menudo el coste es similar y la transferencia desaparece: la mejor gestión de una transferencia internacional suele ser no hacerla.

Una violación de la seguridad de los datos personales es toda violación que ocasione destrucción, pérdida o alteración accidental o ilícita, o comunicación o acceso no autorizados. Nota bien: no hace falta un atacante. Un correo con la lista de pacientes al destinatario equivocado es una brecha; un portátil sin cifrar perdido es una brecha; un fallo de aislamiento entre tenants que deja a un cliente ver datos de otro es una brecha.

Contenido mínimo (art. 33.3): naturaleza de la violación, categorías y número aproximado de interesados y de registros; contacto del DPD; consecuencias probables; y medidas adoptadas o propuestas, incluidas las de mitigación. Si no se dispone de todo, puede facilitarse de manera escalonada —posibilidad clave, porque el reloj no se detiene mientras se investiga—. Y el registro interno de brechas del artículo 33.5 es obligatorio SIEMPRE, se notifique o no: incluso la brecha que se decide no notificar se documenta con hechos, efectos, medidas correctivas y el razonamiento de por qué no procedía notificar. Es lo primero que pide la AEPD cuando llega por otra vía, y su ausencia agrava cualquier expediente.

Recordemos: entrada por el acceso remoto de la consultora (A-19), robo de un .env, exfiltración de 1,2 TB, borrado de copias, 20 días de dwell time y descubrimiento el día 20 a las 09:00.

Las cinco lecciones jurídicas del caso:

1. El reloj arranca con el «conocimiento», no con la certeza. Nimbus tuvo conocimiento el día 20 a las 09:00, cuando supo con razonable certeza que había habido una violación. Esperar a saberlo todo es el error que multiplica las sanciones. Se puede notificar de forma escalonada; no se puede empezar tarde.
2. La notificación escalonada existe precisamente para esto. El día 22 el alcance seguía indeterminado. La respuesta correcta no es callar: es notificar lo que se sabe, decir que la investigación continúa y ampliar.
3. Nimbus, como encargado, no notifica a la AEPD: notifica a cada clínica. Son ellas, como responsables, las que notifican. Con una consecuencia operativa brutal: el retraso de Nimbus consume el plazo de sus 40 clientes. Por eso el contrato debe fijar un plazo interno corto —24 horas suele ser lo pactado— y por eso Nimbus debe entregar información utilizable, no un correo vago.
4. El cifrado como excepción del artículo 34 no salva aquí. La excepción exige que los datos sean ininteligibles para el atacante. Si el atacante robó un .env con las credenciales de la aplicación y exfiltró a través de la propia aplicación, los datos le llegaron descifrados. Cifrar en reposo protege frente al robo del disco o del bucket, no frente a un atacante que tiene las llaves. Esta distinción decide si hay que comunicar a miles de personas o no, y se decide en el diseño, meses antes.
5. Los 20 días de dwell time agravan la valoración. El artículo 83.2 pondera, entre otros criterios, la naturaleza y gravedad, la intencionalidad o negligencia, las medidas para mitigar el daño, el grado de responsabilidad atendiendo a las medidas técnicas y organizativas aplicadas (arts. 25 y 32) y la cooperación. Veinte días sin detectar, con siete oportunidades perdidas, apuntan directamente a la insuficiencia de las medidas del artículo 32.

Plantilla de comunicación a los afectados (art. 34). Debe usar lenguaje claro y sencillo, no jurídico:

Cuatro decisiones de redacción que conviene copiar: no se minimiza —«un incidente sin consecuencias» destruye la confianza cuando se sabe más—, se dice explícitamente qué NO está afectado, se advierte del riesgo real y concreto —phishing dirigido usando el propio historial de citas— y se dan acciones concretas en lugar de recomendaciones genéricas.

¿Necesita Nimbus un delegado de protección de datos? El artículo 37.1 lo hace obligatorio en tres supuestos —autoridades públicas; observación habitual y sistemática a gran escala como actividad principal; y tratamiento a gran escala de categorías especiales como actividad principal—, y la LOPDGDD (art. 34) añade una lista de entidades obligadas. En Nimbus el análisis honesto es que la actividad principal consiste en tratar, por cuenta de terceros, datos de los que se derivan datos de salud, a una escala relevante. Aunque su papel sea de encargado —y el artículo 37 aplica «al responsable y al encargado»—, la conclusión razonable es que probablemente sí está obligado, y en cualquier caso designarlo es defendible y barato: un DPD externo (2.000-5.000 €/año) aporta además criterio jurídico independiente. Requisitos que no pueden olvidarse: independencia funcional, ausencia de conflicto de intereses —Marta no puede ser DPD, porque decide sobre los tratamientos que tendría que supervisar— y publicación de sus datos de contacto, comunicados a la AEPD.

Régimen sancionador (art. 83). Dos niveles:

Los porcentajes se calculan sobre el volumen de negocio del grupo empresarial, no de la filial, y la AEPD dispone además de otras medidas a veces más graves que la multa: limitación u orden de cese del tratamiento, que para un SaaS equivale a apagar el producto. Qué mira la AEPD en la práctica, con criterio realista para una PYME: rara vez llega de oficio a una empresa de 38 personas. Llega por reclamación de un interesado o por notificación de brecha. Y una vez dentro, lo primero que pide es un conjunto muy predecible de documentos: RAT, política de privacidad e información al interesado, contratos del artículo 28, registro de brechas, EIPD si procede, y evidencia de las medidas del artículo 32. La ponderación del artículo 83.2 valora expresamente la cooperación y las medidas adoptadas para mitigar, así que la diferencia entre una sanción grave y un apercibimiento suele estar en poder demostrar diligencia con documentos fechados antes del incidente. Es exactamente lo que se construye en 06-04.

La relación con las clínicas: quién notifica a quién. Es donde más confusión hay, y el contrato debe resolverlo con un cuadro como este:

El plazo de 24 horas del contrato no es negociable a la baja: si Nimbus notifica a las 60 horas, deja a cada clínica 12 para investigar, valorar y notificar a la AEPD, lo que es materialmente imposible, y las 40 incumplirían por culpa de su proveedor. Es el argumento con el que Marta defiende internamente el runbook: el reloj de Nimbus no es el suyo, es el de sus clientes.

• Creer que seudonimizar saca los datos del RGPD. No lo hace: es una medida de seguridad excelente, no una vía de escape.
• Confundir los dos sombreros. Usar datos de pacientes de las clínicas para analítica de producto o para entrenar un modelo convierte a Nimbus en responsable sin base jurídica y con categorías especiales. Es de las infracciones más graves posibles, y ocurre sin mala fe.
• Elegir el consentimiento por defecto. Es revocable, debe ser libre y hay que demostrarlo. Para el núcleo del servicio: contrato, o interés legítimo con ponderación documentada.
• Pedir copia del DNI para atender un derecho de acceso. Es recoger un dato nuevo y excesivo: usa los medios que ya tienes. Y ten resuelto el problema de las copias de seguridad en la supresión —lista de supresiones pendientes, reaplicación tras restaurar escrita en el runbook, expiración—.
• Esperar a saberlo todo para notificar. El reloj corre desde el conocimiento. Existe la notificación escalonada precisamente por eso.
• Confiar en que «los datos estaban cifrados» exime de comunicar a los afectados. Solo si eran ininteligibles para el atacante. Si robó las credenciales de la aplicación, no lo eran.
• Consejo: empieza por el RAT. Es obligatorio, es lo primero que se pide, y escribirlo revela tratamientos que nadie había pensado, plazos que nadie había fijado y subencargados que nadie había autorizado. Y haz la EIPD del producto aunque seas encargado. Se convierte en un entregable comercial que tus clientes reutilizan y responde por adelantado a media docena de cuestionarios. Y minimiza en el formulario antes que en la arquitectura: cada campo que eliminas reduce a la vez el riesgo, el cumplimiento y el impacto de una brecha. Es la medida más barata que existe.

Ejercicio 1 — El nuevo módulo de recordatorios inteligentes

Producto propone una funcionalidad: analizar el historial de citas de todos los tenants para predecir qué pacientes van a faltar y enviarles un recordatorio adicional, mejorando la ocupación de los centros. Iván ya tiene el modelo entrenado con datos de producción de las 40 clínicas. Analiza la propuesta: rol de Nimbus, base jurídica, artículo 9, principios del artículo 5 comprometidos, artículo 22 y qué debe hacer Marta. Indica si existe alguna forma legítima de ofrecerla y con qué condiciones.

Ejercicio 2 — Una brecha pequeña

Rubén, en soporte, responde a la consulta de una clínica adjuntando por error un listado en Excel con 312 pacientes de otra clínica —nombre, teléfono y fechas de sus citas—. Lo detecta él mismo 40 minutos después y avisa. El destinatario es la administrativa de un centro cliente, que confirma por teléfono haber borrado el correo sin abrir el adjunto. Decide, razonando cada paso: ¿es una brecha? ¿quién es responsable y quién encargado? ¿hay que notificar a la AEPD? ¿y a los 312 pacientes? ¿qué se documenta en cualquier caso? ¿qué acción correctiva procede?

Ejercicio 3 — Derecho de supresión con complicaciones

Llega a [email protected] este mensaje: «Soy paciente de Clínica Fisio Valencia. Quiero que borren todos mis datos de su sistema inmediatamente. También quiero saber quién ha consultado mi historial de citas en el último año. Y me niego a que mis datos estén en Estados Unidos.» Redacta el plan de actuación indicando qué derechos se ejercen, quién atiende cada uno, plazos, cómo se verifica la identidad, y cómo se resuelve técnicamente cada punto —incluido el problema de las copias de seguridad y el del proveedor de email—.

Ejercicio 1

El veredicto: tal como está planteada, la funcionalidad es ilícita, y además ya se ha cometido una infracción al entrenar el modelo con datos de producción. Rol y base jurídica. Nimbus decide por sí mismo el fin (mejorar la ocupación, mejorar su producto) y los medios (el modelo), lo que lo convierte en responsable de este tratamiento y no en encargado —el artículo 28.10 lo dice expresamente—. Y como responsable no tiene base jurídica alguna: no hay contrato con los pacientes, no hay consentimiento, y el interés legítimo no puede prevalecer sobre los derechos de personas cuyos datos revelan salud en un tratamiento que no esperan en absoluto. Tratar los datos para un fin propio es además actuar fuera de las instrucciones documentadas (art. 28.3.a) e incumplimiento contractual frente a las 40 clínicas.

Artículos 9, 5 y 22. Son datos que revelan salud y se necesitaría una excepción del 9.2: ninguna encaja, porque no hay consentimiento explícito y la excepción sanitaria (9.2.h) cubre la asistencia, no la optimización comercial de la agenda de un proveedor de software. Del artículo 5 se vulneran la limitación de la finalidad de forma flagrante —predecir ausencias es incompatible con gestionar reservas—, la licitud y transparencia y la minimización. El artículo 22 no se activa si solo se envía un recordatorio adicional, pero sí entraría de lleno si el modelo derivara en penalizaciones, pago anticipado o pérdida de prioridad. Y hay una infracción ya consumada: el modelo entrenado es fruto de un tratamiento ilícito y los modelos pueden memorizar datos de entrenamiento, así que no basta con no desplegarlo: hay que destruirlo y documentar la destrucción.

Qué debe hacer Marta, en este orden: (1) parar la iniciativa hoy; (2) localizar qué datos se copiaron a qué entorno y borrarlos junto con el modelo; (3) valorar con asesoría y el DPD si el entrenamiento constituye brecha o incumplimiento notificable a los clientes —probablemente sí como incumplimiento contractual—; (4) documentar la decisión en acta; (5) añadir al proceso de producto una comprobación obligatoria de privacidad desde el diseño, porque el fallo de fondo no es de Iván: es que la propuesta llegó a implementarse sin que nadie hiciera la pregunta.

Vía legítima, que existe y es viable: convertirlo en una funcionalidad por tenant, donde cada clínica es la responsable que decide activarla sobre sus propios datos. Condiciones: modelo entrenado y ejecutado por tenant sin mezclar datos; la clínica actualiza su información a los pacientes y determina su base jurídica; se documenta como instrucción en el anexo del artículo 28; se ofrece oposición sencilla; se actualizan RAT y EIPD. Es estadísticamente menos potente y es la única forma defendible. La diferencia entre una infracción grave y una funcionalidad válida no está en la tecnología, está en quién decide y sobre qué datos.

Ejercicio 2

¿Es una brecha? Sí, sin ninguna duda. Hay comunicación no autorizada de datos personales a un tercero: que sea un error interno y no un ataque es irrelevante, y que el destinatario sea un cliente de confianza tampoco la elimina. Es una brecha de confidencialidad con datos que revelan salud —312 personas identificadas como pacientes de un centro de fisioterapia—. Roles: los datos son de pacientes de una clínica, así que la clínica afectada es la responsable y Nimbus es el encargado que ha causado la brecha. Nimbus no notifica a la AEPD: notifica a la clínica en el plazo del contrato (24 h) y es ella quien decide y notifica.

¿Notificar a la AEPD? La decisión es de la clínica, pero Nimbus debe darle los elementos y una recomendación fundada. A favor de notificar: categoría especial, 312 afectados, identificación como pacientes de un centro sanitario. A favor de considerar improbable el riesgo: destinatario único e identificado, sujeto a confidencialidad contractual, confirmación de borrado sin abrir, exposición de 40 minutos y ninguna evidencia de difusión. La recomendación prudente es notificar, porque el umbral del artículo 33 no es «riesgo alto» sino «salvo que sea improbable que constituya un riesgo», que es un listón bajo; con categorías especiales de por medio, sostener la improbabilidad es arriesgado, y no notificar y que se sepa después es un agravante claro. Pero es una decisión jurídica del responsable, que debe tomarla con su DPD o asesoría: esta solución es material formativo, no un dictamen. Sea cual sea la decisión, el razonamiento se documenta.

¿A los 312 pacientes? El artículo 34 exige riesgo alto. Con destinatario único identificado, confidencialidad contractual, borrado confirmado sin apertura y 40 minutos de exposición, es defendible que el riesgo alto no concurre y que no procede la comunicación individual —evitando además una alarma desproporcionada por un incidente contenido—. Conviene reforzarlo obteniendo del destinatario confirmación escrita de borrado, no solo telefónica. Y en todo caso se documenta el registro del artículo 33.5: cronología, causa raíz, categorías y número de afectados, destinatario y su confirmación, valoración del riesgo con su razonamiento, decisión y quién la tomó, y medidas correctivas.

Acciones correctivas, donde está el valor real del ejercicio, porque la causa raíz no es Rubén. Técnica y estructural: eliminar la posibilidad de exportar a Excel y adjuntar a mano; los informes se generan desde el sistema, filtrados por tenant, con URL firmada de 120 s al destinatario autenticado —si el fichero no existe fuera del sistema, no se puede adjuntar al correo equivocado; es el patrón de C-06—. Preventiva: aviso en el cliente de correo ante adjuntos con datos personales fuera del dominio, y retraso de 60 segundos que permita cancelar (los 40 minutos habrían sido 0). Detectiva: revisar si el umbral de D-05 habría disparado con esta exportación y ajustarlo. Formativa: caso anonimizado en la píldora de 06-05. Y muy importante: Rubén detectó y reportó su propio error en 40 minutos, que es exactamente el comportamiento deseado, y se le agradece explícitamente. Sancionarlo garantizaría que el próximo error se calle, y el próximo podría ser de 40.000 registros. Es la cultura justa de 06-05.

Ejercicio 3

Se están ejerciendo tres cosas distintas, y separarlas es el primer acierto: supresión (art. 17); acceso (art. 15) en su vertiente de información sobre destinatarios y accesos —con el matiz de que el artículo 15 da derecho a conocer destinatarios o categorías de destinatarios, no automáticamente el nombre de cada empleado que consultó, y hay que ponderar los datos de esos empleados—; y una manifestación sobre transferencias internacionales, que se trata como oposición o como solicitud de información del artículo 15.2 sobre las garantías del capítulo V.

Paso 0 — Determinación del rol, que condiciona todo. Dice ser paciente de Clínica Fisio Valencia, luego Nimbus es encargado y no puede atender la solicitud. Debe registrarla el mismo día, redirigirla a la clínica en 48 horas advirtiendo que el plazo de un mes corre desde la recepción original, informar al solicitante de a quién se ha remitido, y ofrecer asistencia técnica (art. 28.3.e). Atenderla directamente sería actuar fuera de instrucciones, y borrar datos sin instrucción del responsable podría destruir información que la clínica está obligada a conservar por normativa sanitaria.

Pasos 1 y 2 — Identidad y supresión. La clínica verifica con los medios que ya tiene —código al teléfono o correo de su ficha—, sin pedir copia del DNI. Después valora las excepciones del artículo 17.3, y aquí es muy probable que concurran: obligación legal de conservación de documentación clínica y eventual defensa de reclamaciones. Escenario realista: supresión parcial. Se suprime lo no amparado (contacto, cuenta del portal, preferencias, comunicaciones comerciales) y se bloquea el resto —conservado, no tratado, accesible solo a requerimiento— durante el plazo legal, explicándolo con claridad, porque un «no podemos borrarlo» sin motivo genera una reclamación segura. Técnicamente, sobre lo que sí se suprime, Nimbus ejecuta bajo instrucción: borrado en base de datos activa, en A-02, en índices y cachés, y solicitud de supresión al proveedor de email; y aplica el procedimiento de copias del apartado 6 —lista de supresiones pendientes, copias no usadas para reintroducir, reaplicación tras restaurar escrita en el runbook, y expiración a los 35 días, plazo del que se informa—.

Paso 3 — Quién ha consultado su historial. Aquí Nimbus aporta un valor que casi ningún proveedor puede: la tabla de auditoría append-only de C-07, con 12 meses de retención, permite generar un informe por paciente_ref con fecha, hora, tipo de acceso y rol del usuario. La ponderación razonable es dar rol y organización —«personal administrativo del centro», «soporte del proveedor bajo ticket #4412»— en lugar de nombres de empleados; y si el informe revelara accesos injustificados, eso es un incidente en sí mismo y activa 04-05. Paso 4 — La objeción a Estados Unidos. Se responde con transparencia y hechos: alojamiento y base de datos en la UE; la única transferencia es el proveedor de email transaccional, amparada en CCT con evaluación TIA-2026-02, y lo transferido se limita a nombre, correo y un recordatorio sin motivo de la cita ni especialidad del centro. Y se ofrece una alternativa concreta: desactivar los recordatorios por correo y usar SMS o notificación en la app, con lo que deja de haber transferencia alguna respecto de sus datos. Es la respuesta que resuelve el problema real de la persona en lugar de discutir el marco jurídico.

Paso 5 — Plazos y cierre: todo dentro de un mes desde la recepción original, no desde que Nimbus lo reenvió. Si la valoración del 17.3 lo complica, prórroga de dos meses comunicada y motivada dentro del primer mes. La respuesta final, en lenguaje claro, incluye qué se ha suprimido, qué se conserva bloqueado y por qué, el informe de accesos, la explicación de las transferencias con su alternativa, y siempre la mención del derecho a reclamar ante la AEPD.

Has recorrido el RGPD por donde se vive de verdad: en las decisiones de producto, en el modelo de datos, en el buzón de soporte y en las 72 horas siguientes a una mala noticia. Sabes por qué esto le afecta especialmente a Nimbus: el historial de citas de una clínica de fisioterapia revela información sobre la salud, aunque no haya ningún diagnóstico en la base de datos, y eso lo convierte en categoría especial del artículo 9 con tres consecuencias —base jurídica más exigente, EIPD probablemente obligatoria y umbral más bajo para comunicar una brecha a los afectados—.

Manejas los conceptos con precisión: dato personal, categoría especial, dato seudonimizado que sigue siendo dato personal —el error que hunde muchos proyectos de analítica— y dato anónimo con su tensión irreductible entre utilidad y reidentificación. Y tienes clara la distinción que lo ordena todo: Nimbus lleva dos sombreros, encargado respecto de los pacientes de sus clínicas y responsable respecto de sus empleados, sus visitantes web y sus usuarios administradores; con la frontera roja de que usar los datos de los clientes para un fin propio lo convierte en responsable sin base jurídica, y con el recordatorio de que ser encargado no es un escudo. Aplicas los principios del artículo 5 con el análisis de minimización campo a campo —donde el DNI resulta innecesario y la conclusión es que el campo más seguro es el que no existe— y con una política de retención real, ejecutada automáticamente y con justificación escrita en cada línea. Sabes elegir base jurídica y por qué el consentimiento suele ser la peor opción para el núcleo del servicio, y que la excepción del artículo 9 se suma al artículo 6, no lo sustituye. Sabes atender los siete derechos con su plazo de un mes prorrogable, con los tres problemas operativos que nadie explica: verificar identidad sin pedir el DNI, redirigir al responsable cuando eres encargado, y la solución completa al problema de suprimir a alguien que está dentro de una copia inmutable —borrado activo, lista de supresiones, reaplicación tras restaurar escrita en el runbook, y expiración a los 35 días—.

Tienes las obligaciones documentales resueltas: un RAT completo con sus dos secciones —responsable y encargado— y entradas reales rellenas, y una EIPD con su contenido del artículo 35.7 y el error que la arruina, que es copiar el análisis de riesgos de seguridad en lugar de medir el daño a las personas. Sabes traducir el artículo 25 a decisiones concretas de producto, incluida la más barata de todas: preguntar «¿este dato es necesario?» en la plantilla de pull request. Y tienes la tabla que conecta cada exigencia del artículo 32 con el trabajo del módulo 5, con el apartado que casi nadie cumple —32.1.d, verificar regularmente la eficacia— señalado como el objeto de la próxima lección. Dominas el contrato del artículo 28 con sus cláusulas obligatorias, la cadena de subencargados con la regla de que externalizar la ejecución no externaliza la responsabilidad, y las transferencias internacionales que ocurren sin que nadie las note —incluido el acceso remoto desde fuera del EEE—, con la solución más elegante para el caso de Nimbus: minimizar el contenido del recordatorio hasta sacar la salud de la transferencia. Y has analizado el incidente de 02-06 bajo el RGPD con su reloj de 72 horas desde el conocimiento y no desde la certeza, la notificación escalonada, el hecho de que el retraso de Nimbus consume el plazo de sus 40 clientes, por qué el cifrado en reposo no salvó de comunicar a los afectados cuando el atacante tenía las llaves, y cómo los 20 días de dwell time agravan la valoración del artículo 83.2. Con la plantilla de comunicación a los afectados y sus cuatro decisiones de redacción. Cierras con el DPD —probablemente obligatorio, externo, independiente y sin conflicto de intereses—, los dos niveles sancionadores, lo que la AEPD pide de verdad cuando llega, y el cuadro de quién notifica a quién entre Nimbus y las clínicas.

Y fíjate en lo que ha aparecido una y otra vez en esta lección: RAT, contratos, registro de brechas, informes de restauración, evidencia de las medidas del artículo 32, documentos fechados antes del incidente. El RGPD no premia estar seguro: premia poder demostrarlo, y llama a eso responsabilidad proactiva. Lo mismo pedía NIS2, lo mismo pide un auditor de ISO 27001 y lo mismo pide el cliente con su cuestionario de 90 preguntas. En Cumplimiento y Auditoría (06-04) convertimos esa exigencia en un sistema: qué hace válida a una evidencia, cómo se automatiza su recolección para que la auditoría deje de ser tres días de pánico, cómo se completa la matriz de trazabilidad que arrastramos desde 04-03, cómo se comporta un auditor de verdad y qué pregunta cuando pide una muestra, y cómo se responde a un hallazgo sin discutir ni exagerar. Todo el trabajo técnico del módulo 5 dejó un rastro; ahora vamos a recogerlo.