Cuando el subcontratista está en el centro de la crisis: una lectura práctica del artículo 28 RGPD

La CNIL francesa ha publicado un supuesto hipotético, inspirado en incidentes reales, que merece ser leído más allá de su apariencia divulgativa. El caso plantea un ciberataque contra un subcontratista que presta una solución cloud a sus clientes. El atacante utiliza ingeniería social, engaña a una persona empleada, accede al sistema de información del proveedor, recorre la red interna, alcanza datos no estructurados en espacios compartidos y llega incluso a hipervisores donde se ejecutan máquinas virtuales de clientes. Desde ahí copia datos de la propia empresa proveedora y también datos de sociedades clientes.

El interés del caso no reside únicamente en la técnica del ataque. Lo relevante es que la CNIL coloca el incidente en un punto especialmente sensible de la arquitectura de protección de datos: el proveedor que trata datos personales por cuenta de otros.

En ese escenario, el responsable del tratamiento no ha sufrido directamente el ataque en sus propios sistemas, pero sigue estando jurídicamente obligado a valorar la violación, analizar el riesgo, decidir si procede notificar a la autoridad de control, comunicar a las personas afectadas cuando exista alto riesgo y documentar sus decisiones. El problema es que buena parte de la información necesaria para cumplir no está en sus manos, sino en las del encargado que también está gestionando su propia crisis.

Esa tensión explica por qué el artículo 28 RGPD no debe interpretarse como una simple obligación de firmar un contrato de encargo. Su función es más profunda: permitir que el tratamiento externalizado siga siendo gobernable, verificable y defendible cuando el dato sale del perímetro directo del responsable.

Figura 1. La crisis nace en el proveedor, pero alcanza al responsable y activa toda la cadena de cumplimiento.

1. El caso CNIL como ejercicio práctico de responsabilidad proactiva

La publicación de la CNIL no se limita a recordar obligaciones jurídicas. Construye una escena de trabajo. En ella aparecen una responsable de seguridad de sistemas, Alice, y un delegado de protección de datos, Charles. Alice recibe alertas de actividad sospechosa, analiza las primeras señales, confirma la fuga y activa el procedimiento previsto. Esa actuación provoca la puesta en protección del sistema y un “blackout” que afecta tanto a la entidad como a sus clientes.

Charles, por su parte, debe ordenar la dimensión RGPD de la crisis. La violación afecta a datos tratados por la empresa para su propia cuenta, pero también a datos de empresas clientes. Por eso, debe recabar información técnica, valorar el riesgo, notificar por los datos propios de la entidad y, al mismo tiempo, informar cuanto antes a los clientes para que estos puedan cumplir sus propias obligaciones.

La CNIL sintetiza el principio de forma clara: el subcontratista debe ayudar a sus clientes afectados a efectuar su notificación y debe notificar también por sí mismo cuando se hayan expuesto datos tratados para su propia cuenta.

Este planteamiento tiene un valor pedagógico evidente. El caso muestra que una brecha en un encargado no puede gestionarse como un incidente puramente técnico ni como un asunto exclusivamente jurídico. Requiere coordinación entre seguridad, protección de datos, dirección, comunicación, atención a clientes y, en su caso, equipos forenses o proveedores especializados.

La responsabilidad proactiva se comprueba precisamente ahí: no cuando la organización declara que cumple, sino cuando debe demostrar que puede responder de forma ordenada, proporcionada y documentada.

2. El responsable sigue obligado, aunque los hechos estén en manos del encargado

Cuando el incidente se produce en el proveedor, aparece una asimetría difícil de gestionar. El responsable conserva sus obligaciones, pero no controla directamente los hechos técnicos. Necesita información del encargado para saber qué ha ocurrido, cuándo se ha detectado, qué sistemas han quedado afectados, qué datos estaban en el perímetro, qué clientes o tratamientos pueden verse comprometidos, si ha habido pérdida de disponibilidad, si hay indicios de acceso no autorizado o exfiltración, y qué medidas se han adoptado.

Esta situación explica la importancia práctica del artículo 28 RGPD. El responsable no puede limitarse a haber firmado un contrato. Debe haber seleccionado a un encargado con garantías suficientes y debe haber configurado una relación capaz de funcionar bajo presión.

El artículo 28 exige que el responsable recurra únicamente a encargados que ofrezcan garantías suficientes para aplicar medidas técnicas y organizativas apropiadas, y que el tratamiento por cuenta de otro quede regulado mediante contrato u otro acto jurídico. Ese contrato debe establecer, entre otros extremos, objeto, duración, naturaleza y finalidad del tratamiento, tipo de datos, categorías de interesados, obligaciones e instrucciones documentadas, confidencialidad, seguridad, subencargados, asistencia, auditoría y devolución o supresión de datos al finalizar la prestación.

La finalidad de estas exigencias no es formal. El artículo 28 pretende evitar que la externalización del tratamiento se convierta en una pérdida de control. El responsable puede contratar un servicio, pero no puede externalizar su responsabilidad. Por eso necesita que el encargado actúe dentro de un marco conocido, documentado, supervisable y capaz de producir evidencias.

En términos prácticos, el artículo 28 es una forma de responsabilidad proactiva aplicada a la externalización. Sirve para que la responsabilidad no se diluya cuando una parte del tratamiento se ejecuta fuera de la organización responsable.

Figura 2. La accountability del responsable exige asistencia útil del encargado: sin hechos verificables, no hay decisión defendible.

3. Qué debía estar preparado antes del incidente

El caso de la CNIL permite comprender una idea esencial: en una crisis solo se activa lo que antes se ha construido. Si el responsable y el encargado no han definido previamente los tratamientos afectados, las instrucciones, los canales de comunicación, los contactos de crisis, los subencargados, las medidas de seguridad, las evidencias exigibles y el procedimiento de notificación, la respuesta dependerá de la improvisación.

Antes de un incidente, el responsable debería tener identificado qué proveedores tratan datos personales por su cuenta, qué servicios prestan, qué categorías de datos manejan, qué colectivos pueden verse afectados, qué sistemas intervienen, qué subencargados participan y qué nivel de criticidad tiene cada proveedor. No todos los encargados plantean el mismo riesgo. No es igual un proveedor que presta un servicio accesorio con datos limitados que un proveedor cloud que aloja infraestructura esencial o un tercero que administra sistemas críticos.

El contrato de encargo debería ser operativo. Esto significa que no basta con reproducir fórmulas generales del RGPD. Debe indicar cómo se comunica una brecha, a quién se informa, en qué plazo, por qué canal, con qué contenido mínimo y con qué actualizaciones posteriores. Debe prever también qué evidencias deberá entregar el encargado: cronología, sistemas afectados, categorías de datos, medidas de contención, registros disponibles, subencargados implicados, informe técnico y plan de remediación.

También debe contemplarse la salida del servicio. Muchas crisis se agravan porque el proveedor conserva exportaciones, copias, ficheros temporales, documentación de soporte o datos históricos que ya no eran necesarios. La devolución y supresión de datos no debería quedar como una cláusula genérica al final del contrato, sino como un procedimiento verificable.

La enseñanza es clara: un contrato de encargo que solo sirve cuando todo funciona bien no gobierna realmente el tratamiento externalizado.

Figura 3. En una crisis solo puede activarse lo que ya estaba preparado, probado y documentado.

4. Qué debe hacer el encargado cuando detecta el incidente

El encargado debe actuar siguiendo una secuencia ordenada. Primero debe detectar y confirmar la actividad anómala. Después debe contener el incidente, preservar evidencias y delimitar un perímetro provisional. Esa delimitación inicial no tiene por qué ser perfecta, pero sí debe ser útil: sistemas afectados, clientes potencialmente afectados, categorías de datos, indicios de exfiltración, pérdida de disponibilidad, medidas adoptadas y aspectos pendientes de confirmar.

La obligación de informar al responsable no puede quedar paralizada hasta que exista un informe forense completo. El artículo 33.2 RGPD exige que el encargado notifique al responsable sin dilación indebida después de tener conocimiento de una violación de datos personales.

Eso obliga a distinguir entre comunicación inicial e información definitiva. En una brecha compleja, especialmente cuando afecta a infraestructuras compartidas o datos no estructurados, el encargado no conocerá todos los detalles desde el primer momento. Pero sí debe informar de lo que sabe, explicar lo que todavía no sabe, indicar qué está investigando y actualizar al responsable a medida que avance el análisis.

La CNIL muestra esta lógica cuando el DPO del proveedor informa a los clientes, les remite una guía de ayuda para la declaración, abre una línea telefónica dedicada y propone incluso realizar la notificación en su nombre, siempre con acuerdo formal.

Ese punto es especialmente importante. La asistencia del encargado no es cortesía comercial. Forma parte de la arquitectura del artículo 28. Asistir significa permitir que el responsable pueda cumplir: valorar el riesgo, notificar a la autoridad, informar a las personas, documentar sus decisiones y adoptar medidas correctoras.

5. Qué debe hacer el responsable cuando recibe la comunicación

El responsable no puede adoptar una posición pasiva por el hecho de que el incidente se haya producido en el proveedor. Debe abrir su propio expediente interno, registrar la comunicación recibida, identificar qué tratamientos propios pueden estar afectados y pedir al encargado la información necesaria para valorar la situación.

A partir de ahí debe calificar el incidente. Una violación de datos personales puede afectar a la confidencialidad, la integridad o la disponibilidad. Por tanto, no debe preguntarse únicamente si hubo exfiltración, sino también si los datos dejaron de estar disponibles, si pudieron ser alterados, si se perdió control sobre ellos o si la interrupción del servicio pudo generar consecuencias para las personas.

Después debe analizar el riesgo. Ese análisis no puede hacerse de forma abstracta. Depende del tipo de datos, del volumen, de los colectivos afectados, de la duración del incidente, de la facilidad de identificación, de las consecuencias previsibles y de las medidas de mitigación aplicadas.

Si la brecha puede suponer un riesgo para los derechos y libertades de las personas, el responsable deberá notificar a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo máximo de 72 horas desde que haya tenido constancia. El artículo 33 RGPD permite que, cuando no sea posible facilitar toda la información al mismo tiempo, esta se aporte de forma gradual sin dilación indebida.

Si existe alto riesgo para las personas, deberá además comunicarles la violación de forma clara, comprensible y útil. La CNIL propone en el caso una estructura comunicativa basada en preguntas sencillas: qué ha pasado, cómo se ha reaccionado, qué datos están afectados, cuáles son las consecuencias posibles, qué recomendaciones se ofrecen y a quién contactar.

La decisión corresponde al responsable. Pero la calidad de esa decisión dependerá en gran medida de la información, asistencia y evidencias que el encargado sea capaz de proporcionar.

6. La disponibilidad como dimensión olvidada de la brecha

Uno de los elementos más interesantes del supuesto de la CNIL es que el incidente no se limita a una posible pérdida de confidencialidad. La reacción defensiva provoca un “blackout” que afecta al proveedor y a sus clientes. Esto obliga a recordar que una violación de datos personales puede producirse también por pérdida de disponibilidad.

Este punto tiene una gran relevancia práctica. Muchas organizaciones siguen asociando brecha de datos con filtración o exfiltración. Sin embargo, el artículo 32 RGPD exige medidas adecuadas para garantizar confidencialidad, integridad, disponibilidad y resiliencia, así como capacidad de restaurar la disponibilidad y el acceso a los datos en tiempo oportuno tras un incidente físico o técnico.

Cuando un proveedor crítico cae, la pregunta no es solo si alguien copió datos. También debe analizarse si la indisponibilidad impidió prestar un servicio esencial, atender derechos, ejecutar obligaciones, acceder a información necesaria o evitar daños.

Esto refuerza la conexión entre protección de datos, continuidad de negocio, ciberseguridad y gestión de terceros. En proveedores críticos, el artículo 28 no puede separarse de los controles de resiliencia, restauración, segregación de entornos, monitorización y comunicación de crisis.

7. Los datos no estructurados como punto ciego

La CNIL introduce otro elemento especialmente relevante: el atacante accede a datos no estructurados disponibles en espacios compartidos internos.

Este detalle es muy realista. Muchas organizaciones tienen relativamente controladas sus aplicaciones principales, bases de datos y sistemas corporativos, pero no siempre tienen el mismo control sobre carpetas compartidas, exportaciones, hojas de cálculo, tickets de soporte, capturas de pantalla, copias temporales, repositorios internos o archivos históricos.

En una crisis, esos espacios se convierten en zonas de incertidumbre. Y la incertidumbre tiene consecuencias: retrasa la delimitación del perímetro, dificulta la identificación de personas afectadas, complica el análisis de riesgo, debilita la notificación y reduce la capacidad probatoria.

Por eso el gobierno del encargado debe incorporar reglas sobre minimización, conservación, acceso, segregación, exportaciones, evidencias de soporte, supresión y devolución. La mejor forma de reducir el impacto de una brecha futura es evitar que el proveedor conserve datos que ya no necesita o que los mantenga en espacios difíciles de controlar.

8. El papel del DPO/DPD en una crisis de encargado

El caso de la CNIL también enseña bien el papel del delegado de protección de datos. Charles no sustituye a la dirección ni asume la respuesta técnica, pero ordena la dimensión RGPD de la crisis: recopila información, valora riesgos, coordina comunicaciones, documenta, notifica cuando procede y asiste a los clientes.

Esta representación es acertada. El DPO/DPD no decide por la organización ni aprueba o reprueba tratamientos. Su función es asesorar, supervisar, advertir, exigir evidencias y ayudar a que las decisiones sean razonadas y defendibles.

En una crisis de proveedor, el DPO/DPD debe ayudar a responder preguntas críticas: cuál es el rol jurídico de la organización, qué tratamientos están afectados, qué información ha facilitado el encargado, qué información falta, si existe riesgo o alto riesgo para las personas, si procede notificar, si procede comunicar, qué evidencias se conservan y qué medidas correctoras deben exigirse.

Su función no es tranquilizar artificialmente. Es evitar que la organización decida a ciegas.

9. Del contrato de encargo al gobierno real del proveedor

La lectura más importante del caso CNIL es que el artículo 28 RGPD debe entenderse como un instrumento de gobierno continuo del proveedor. Empieza antes de contratar, con la selección diligente del encargado. Continúa durante la prestación, con instrucciones, medidas, seguimiento, control de subencargados, asistencia y evidencias. Se activa de forma crítica durante la crisis. Y no termina hasta la devolución, supresión o cierre verificable del tratamiento.

Esta visión conecta directamente con los programas de TPRM aplicados a protección de datos. La gestión de terceros no puede reducirse a un cuestionario inicial ni a una cláusula estándar. Debe responder a preguntas operativas:

• qué proveedores tratan datos personales;
• qué datos tratan;
• con qué finalidad;
• en qué sistemas;
• con qué subencargados;
• con qué medidas;
• con qué capacidad de detección;
• con qué obligación de aviso;
• con qué evidencias;
• con qué capacidad de asistencia;
• con qué procedimiento de salida.

La CNIL no plantea el caso para generar alarma, sino para enseñar. Y lo que enseña es que la accountability del responsable depende también de la madurez del encargado.

Figura 4. La diferencia entre proveedor y encargado conforme al artículo 28 RGPD está en su capacidad real de responder cuando todo falla.

Conclusión: el artículo 28 no se agota en la firma

El supuesto de la CNIL permite comprender el artículo 28 RGPD desde su función real. No es una cláusula accesoria ni una formalidad documental. Es el marco que permite gobernar un tratamiento cuando parte de ese tratamiento se ejecuta fuera de la organización responsable.

Cuando el subcontratista está en el centro de la crisis, el responsable sigue obligado, pero necesita hechos, asistencia, evidencias y comunicación útil. El encargado, por su parte, no puede limitarse a prestar el servicio en condiciones normales: debe estar preparado para detectar, contener, informar, asistir, documentar y remediar cuando el incidente ocurre en su entorno.

La responsabilidad proactiva no se demuestra con el contrato firmado, sino con la capacidad de activar ese contrato bajo presión.

Por eso, la pregunta relevante no es solo si existe un acuerdo de encargo.

La pregunta verdaderamente importante es si ese acuerdo, esas instrucciones, esas medidas y esas evidencias permiten responder cuando el proveedor cae.

La diferencia entre un proveedor y un encargado conforme al artículo 28 RGPD no está en lo que firma. Está en lo que es capaz de hacer cuando todo falla.

Referencias

CNIL, “Cyberattaque : le sous-traitant au centre de la crise”.
https://www.cnil.fr/fr/cyberattaque-le-sous-traitant-au-centre-de-la-crise

Reglamento (UE) 2016/679, artículo 28, Encargado del tratamiento.
https://gdpr-info.eu/art-28-gdpr/

Reglamento (UE) 2016/679, artículo 32, Seguridad del tratamiento.
https://gdpr-info.eu/art-32-gdpr/

Reglamento (UE) 2016/679, artículo 33, Notificación de una violación de la seguridad de los datos personales a la autoridad de control.
https://gdpr-info.eu/art-33-gdpr/