La seguridad de los datos subcontratados nunca se delega por completo: la empresa que confía datos personales sigue estando obligada a elegir, supervisar y controlar a su proveedor. El incidente de VACAF confirmado por la Cnaf el 10 de octubre de 2026 ilustra un riesgo frecuente: una plataforma externa puede verse comprometida mientras el sistema de información principal permanece aislado. El contrato, los accesos, los registros y el procedimiento de incidentes deben quedar definidos antes de la puesta en línea.
¿Qué revela la filtración de VACAF sobre los riesgos relacionados con los proveedores?
El incidente de VACAF muestra que un servicio alojado en un proveedor externo puede exponer datos sin comprometer el sistema de información principal. El 10 de octubre de 2026, la Cnaf confirmó un incidente de ciberseguridad y suspendió vacaf.org, mientras que los sistemas utilizados para gestionar y pagar las prestaciones de la Caf seguían separados y operativos.
VACAF es el servicio de ayuda para las vacaciones de la red de las Caf. Según la comunicación oficial de la Cnaf del 10 de octubre de 2026, la plataforma estaba gestionada por la Caf del Hérault y alojada en un proveedor externo. Las nuevas reservas fueron suspendidas, pero las reservas existentes y el pago de las prestaciones siguieron siendo válidos.
Esta separación técnica limitó las consecuencias operativas. Las primeras comprobaciones también excluían los datos bancarios de los beneficiarios y las contraseñas de los servicios en línea de las Caf. Sin embargo, a 13 de octubre de 2026, no se habían hecho públicos la identidad del proveedor, el vector de ataque, la cronología precisa ni la lista completa de los campos expuestos.
La cifra de aproximadamente 1,2 millones de expedientes, difundida el 13 de octubre de 2026 por Le Monde Informatique a partir de una reivindicación atribuida a FrenchBreaches, no había sido confirmada por la Cnaf. Por tanto, no debe presentarse como un balance establecido. En una crisis cibernética, distinguir un hecho oficial de una reivindicación evita agravar la confusión.
¿Quién sigue siendo responsable de la seguridad de los datos subcontratados?
El responsable del tratamiento sigue respondiendo de la elección y la supervisión de su encargado del tratamiento, mientras que el proveedor debe aplicar las medidas de seguridad previstas. El artículo 28 del RGPD, adoptado en 2016, exige garantías suficientes, un contrato vinculante y la transmisión de obligaciones equivalentes a los posibles subencargados posteriores.
El responsable del tratamiento es la organización que decide por qué y cómo se utilizan los datos personales. El encargado del tratamiento procesa estos datos por cuenta de aquel: proveedor de alojamiento, agencia web, editor de SaaS (software accesible en línea), proveedor de email marketing o mantenedor de una aplicación.
Firmar un acuerdo de tratamiento de datos no basta. El artículo 32 del RGPD de 2016 impone al responsable y al encargado del tratamiento medidas adaptadas al riesgo, que pueden incluir el cifrado, la resiliencia de los sistemas, la restauración de los datos y pruebas periódicas. Por tanto, la seguridad de los datos subcontratados es una responsabilidad compartida, pero no diluida.
La misma lógica se aplica cuando un proveedor delega el alojamiento, las copias de seguridad o el envío de correos electrónicos a otra empresa. La cadena contractual debe seguir siendo visible. Este mecanismo de dependencias también recuerda el efecto en cascada de NIS2 sobre los subencargados, aunque las obligaciones exactas varían según la actividad y el estatus de la organización.
¿Qué hay que comprobar antes de confiar datos a un proveedor?
Antes de confiar datos personales, la empresa debe cartografiar la información tratada, identificar los accesos, comprobar los subencargados posteriores y obtener garantías verificables. En 2024, la CNIL recomendaba regular la autenticación, los permisos de acceso, la comunicación de incidentes, la devolución o supresión de los datos y las revisiones de seguridad.
Un mapa de datos indica qué información entra en el servicio, dónde se almacena, quién puede consultarla y cuándo se elimina. Sin esta visión, es imposible evaluar correctamente el impacto de una filtración o saber si una base de pruebas contiene todavía datos reales de clientes.
Las comprobaciones útiles siguen un orden concreto:
- describir las categorías de datos, su finalidad y su plazo de conservación;
- inventariar a los administradores, las cuentas técnicas y los accesos de asistencia;
- identificar al proveedor de alojamiento y a cada subencargado posterior autorizado;
- exigir un registro de actividad, es decir, un historial utilizable de las conexiones y las acciones sensibles;
- prever el cifrado, las copias de seguridad, la restauración y pruebas de seguridad periódicas;
- fijar un procedimiento de devolución o supresión al finalizar el contrato;
- definir el canal y el plazo de alerta en caso de incidente.
En 2024, la CNIL indicaba que las garantías podían comprobarse mediante auditorías o inspecciones in situ. Recomendaba, en particular, examinar el cifrado, la trazabilidad, la gestión de las autorizaciones, la protección de la red y las prácticas de administración. Un certificado comercial sin alcance ni fecha aporta pocas garantías.
En los proyectos que llevamos a cabo, vemos a menudo un riesgo desatendido: la cuenta de administración compartida entre varios colaboradores. Reduce la trazabilidad y complica la revocación de un acceso. Una cuenta nominal, la autenticación multifactor y unos derechos limitados a la misión suelen ser opciones más sólidas.
¿Qué cláusulas de seguridad deben incluirse en el contrato?
Un contrato de subcontratación debe transformar las promesas de seguridad en obligaciones verificables: alcance de los datos, medidas técnicas, gestión de los accesos, subencargados posteriores, asistencia, auditoría y notificación de incidentes. En 2024, la CNIL también recomendaba regular la devolución o el borrado de los datos al finalizar la prestación.
La siguiente tabla relaciona las cláusulas con las consecuencias concretas para un proyecto web o móvil.
| Aspecto contractual | Requisito verificable | Riesgo reducido |
|---|---|---|
| Acceso | Cuentas nominales, permisos de acceso limitados y revocación documentada | Acceso persistente o imposible de atribuir |
| Trazabilidad | Registros de conexión y administración conservados durante un plazo definido | Incidente imposible de reconstruir |
| Subcontratación posterior | Lista de actores, ubicación y procedimiento de autorización o información | Cadena técnica desconocida |
| Incidente | Alerta sin demora indebida, canal de emergencia e información mínima requerida | Notificación reglamentaria tardía |
| Finalización del contrato | Devolución, formato de exportación, supresión y prueba de borrado | Datos olvidados en el antiguo proveedor |
| Control | Derecho de auditoría, justificantes fechados y plan de corrección | Garantías imposibles de confirmar |
La trampa contractual clásica consiste en aceptar una cláusula vaga del tipo «medidas conformes con las buenas prácticas». Sinceramente, una fórmula tan amplia protege mal el proyecto: no precisa ni los controles, ni las responsabilidades, ni las pruebas esperadas. Un contrato útil describe lo que puede verificarse sin imponer una arquitectura fija.
El presupuesto también debe prever el mantenimiento posterior a la entrega. Las correcciones de seguridad, la revisión de las cuentas y la renovación de los componentes no son opciones puntuales. Un enfoque de gestión de las actualizaciones sin interrupción de la producción ayuda a aclarar las responsabilidades entre la empresa, la agencia y el proveedor de alojamiento.
¿Cómo reaccionar cuando un proveedor comunica una filtración de datos?
Cuando un proveedor detecta una violación de datos personales, debe informar al responsable del tratamiento sin demora indebida. Según el procedimiento publicado por la CNIL en 2018, el responsable documenta cada violación y, cuando existe un riesgo, la notifica a la CNIL, si es posible, en un plazo de 72 horas desde que tuvo conocimiento de ella.
Una violación de datos personales es una vulneración de la confidencialidad, la integridad o la disponibilidad de información que permite identificar a una persona. Puede tratarse de una consulta no autorizada, una modificación, una pérdida o una indisponibilidad.
La primera reacción consiste en preservar las pruebas mientras se contiene el incidente: suspender un acceso comprometido, aislar el servicio si es necesario y conservar los registros. La Cnaf suspendió así el acceso a vacaf.org el 10 de octubre de 2026, activó una célula de crisis, informó a la Agencia Nacional de la Seguridad de los Sistemas de Información y a la CNIL, y posteriormente anunció la presentación de una denuncia penal.
Si la violación presenta un riesgo elevado para las personas, estas también deben ser informadas. El mensaje debe distinguir entre los datos cuya afectación está confirmada y aquellos que no lo están. En el caso de VACAF, la Cnaf indicaba el 10 de octubre de 2026 que, según las primeras comprobaciones, los datos bancarios y las contraseñas de Caf no se habían visto afectados.
Por parte de la agencia, la reacción consiste en preparar esta secuencia antes del incidente: datos de contacto de emergencia, responsables autorizados para tomar decisiones, modelo de registro y procedimiento de recopilación de pruebas. Las lecciones extraídas de los incidentes de seguridad que afectan a un proveedor de servicios de correo electrónico también demuestran que un servicio periférico merece la misma disciplina que una aplicación central.
¿Cómo limitar el impacto de una vulneración externa?
La reducción del impacto se basa en la segmentación, la limitación de los datos y los accesos, así como en una capacidad de restauración probada. El incidente de VACAF de 2026 ilustra el interés de la segmentación: la plataforma afectada estaba técnicamente separada del sistema utilizado para gestionar y pagar las prestaciones de Caf, que siguió funcionando.
La segmentación consiste en impedir que un incidente en un servicio abra automáticamente el acceso a los demás. Una plataforma para eventos, una extranet o una herramienta de correo electrónico no debería disponer de acceso permanente a toda la base de clientes. Con este nivel de riesgo, es preferible intercambiar únicamente lo estrictamente necesario en lugar de replicar una base de datos completa por comodidad.
La minimización también reduce las consecuencias: cuanto menos información almacene una plataforma, menos podrá exponer una vulneración. En una aplicación móvil, esta lógica comienza desde la fase de diseño; los principios de protección de datos desde el diseño evitan tener que corregir posteriormente una arquitectura demasiado permisiva.
Las copias de seguridad no son suficientes si nunca se prueba su restauración. Del mismo modo, los registros son inútiles si la cuenta comprometida puede modificarlos o si nadie sabe cómo utilizarlos. La seguridad de los datos confiados a un encargado del tratamiento debe probarse en escenarios concretos, incluida la pérdida de una cuenta de administrador y la indisponibilidad del proveedor.
Definir el marco de la externalización antes del desarrollo evita gran parte de las sorpresas contractuales y técnicas desagradables. Una perspectiva externa puede, en particular, poner en relación el contrato, la arquitectura y el procedimiento de crisis, tres cuestiones que con demasiada frecuencia se tratan por separado.
Preguntas frecuentes sobre la seguridad de los datos confiados a un proveedor
¿Es un proveedor de alojamiento un encargado del tratamiento en el sentido del RGPD?
Un proveedor de alojamiento es generalmente un encargado del tratamiento cuando almacena o trata datos personales por cuenta de la empresa. Su función, sus medidas de seguridad y sus propios proveedores deben estar regulados de conformidad con el artículo 28 del RGPD de 2016.
¿Se puede prohibir a un proveedor recurrir a otras empresas?
El contrato puede regular el recurso a subencargados del tratamiento posteriores mediante una autorización previa específica o general, de conformidad con el artículo 28 del RGPD de 2016. Se les deben imponer obligaciones equivalentes de protección de datos.
¿El plazo de 72 horas comienza a partir del ataque?
El plazo de 72 horas se refiere, cuando la notificación es obligatoria, al momento en que el responsable del tratamiento tiene conocimiento de la violación, y no necesariamente a la fecha técnica del ataque. La CNIL precisa desde 2018 que una notificación inicial puede completarse si no se dispone de toda la información.
¿Una certificación exime de auditar a un proveedor?
Una certificación puede contribuir a demostrar ciertas garantías, pero no sustituye la evaluación del servicio que se utiliza realmente. En 2024, la CNIL recomendaba comprobar las medidas mediante auditorías o inspecciones y examinar, en particular, los accesos, el cifrado, los registros y la administración.