Riesgo de terceros en el RGPD, NIS2 y DORA

Un mismo proveedor puede generar obligaciones en materia de privacidad, ciberseguridad y resiliencia operativa. Un proveedor de nóminas trata datos personales; un proveedor de servicios gestionados tiene acceso privilegiado; una plataforma en la nube da soporte a aplicaciones críticas para el negocio. A veces un solo proveedor hace las tres cosas.

Un registro de proveedores compartido ayuda a los equipos a coordinar la evaluación, siempre que cada obligación siga siendo identificable. Para un CTO, el reto práctico es conectar los compromisos contractuales con la realidad técnica: a qué puede acceder el proveedor, cómo se propagan los fallos, qué controles están acreditados con evidencias y si la organización puede recuperarse o salir.

Determine la aplicabilidad antes de combinar evaluaciones

Estos instrumentos se solapan, pero no se aplican del mismo modo a todas las organizaciones ni a todos los proveedores.

El artículo 28 del RGPD obliga a los responsables a recurrir a encargados que ofrezcan garantías suficientes. Un contrato del artículo 28 no procede simplemente porque un proveedor reciba datos: determine primero la función real en el tratamiento.

Los artículos 20 a 23 de NIS2 regulan la supervisión por parte de la dirección, las medidas de gestión de riesgos y la notificación de incidentes significativos. NIS2 es una directiva que se aplica mediante legislación nacional, por lo que el ámbito de aplicación y los procedimientos requieren comprobaciones específicas de cada jurisdicción.

DORA es aplicable desde el 17 de enero de 2025. Cubre principalmente a determinadas entidades financieras; los proveedores de TIC ordinarios pueden verse sujetos a requisitos contractuales de sus clientes, mientras que los proveedores de TIC críticos designados tienen un régimen de supervisión propio. Para las entidades financieras incluidas, DORA actúa como legislación sectorial de la UE en los ámbitos de NIS2 pertinentes. No duplique automáticamente ambos conjuntos de controles.

Construya el registro en torno a la dependencia

Parta del servicio, no del cuestionario al proveedor. Un mismo proveedor puede prestar varios servicios con datos, accesos e importancia operativa diferentes.

Como base práctica, registre:

• Servicio, entidad jurídica del proveedor, responsable de negocio, responsable técnico y revisores.
• Funciones soportadas, sistemas, integraciones y accesos privilegiados.
• Categorías de datos personales, fines del tratamiento, ubicaciones y subencargados.
• Requisitos de disponibilidad, objetivos de recuperación e interrupción tolerable.
• Proveedores subyacentes, dependencias contractuales y alternativas realistas.
• Obligaciones aplicables, fechas de las evidencias, carencias sin resolver y decisiones.

Identifique qué funciones fallarían o se degradarían tras un compromiso o una caída. Un proveedor que almacena pocos datos sensibles puede, aun así, controlar la autenticación o los pipelines de despliegue. A la inversa, un servicio con bajo riesgo de disponibilidad puede exponer datos personales muy sensibles.

Mantenga estas dimensiones separadas en lugar de reducirlas a una única puntuación de «riesgo alto» sin explicación. Para las entidades financieras sujetas a DORA, conecte este inventario operativo con el registro de información obligatorio sobre los acuerdos contractuales de TIC; una lista genérica de proveedores no es necesariamente suficiente.

Reutilice las evidencias sin reutilizar las conclusiones a ciegas

Un informe de seguridad, un mapa de flujos de datos o una prueba de recuperación pueden servir para varias revisiones. Compruebe su alcance de servicio, el periodo cubierto, las exclusiones, las excepciones y las responsabilidades del cliente antes de basarse en ellos.

Por ejemplo, un informe que cubre la infraestructura del proveedor no cubre necesariamente el acceso de su personal de soporte a los registros de clientes. Una política de copias de seguridad documentada no demuestra que la restauración cumpla los requisitos de recuperación de su aplicación.

Mantenga una matriz que relacione evidencias y preguntas:

Un certificado ISO o un informe SOC 2 respaldan el aseguramiento dentro de su alcance; ninguno de los dos acredita el cumplimiento del RGPD o de NIS2. Conserve el razonamiento del revisor, no solo el documento subido. Evaluar el aseguramiento de la seguridad debe ser una revisión técnica repetible, no la comprobación de un sello.

Traduzca los requisitos en contratos y controles

Según el artículo 28 del RGPD, las condiciones del encargo deben establecer el objeto, la duración, la naturaleza y la finalidad del tratamiento, el tipo de datos y las categorías de interesados. También abarcan las instrucciones documentadas, la confidencialidad, la seguridad, las condiciones para los subencargados, la asistencia, la supresión o devolución y las obligaciones de información y auditoría. Las transferencias internacionales requieren una evaluación separada conforme al capítulo V; el alojamiento en la UE no resuelve por sí solo las cuestiones de acceso o de transferencias ulteriores.

El artículo 21 de NIS2 incluye la seguridad de la cadena de suministro y la consideración de las vulnerabilidades y prácticas de ciberseguridad de los proveedores directos. Las expectativas contractuales prácticas pueden incluir restricciones de acceso, gestión de vulnerabilidades, cooperación ante incidentes y aportación de evidencias. Adáptelas al servicio y a los requisitos nacionales en lugar de considerar jurídicamente suficiente un único paquete universal de cláusulas.

El artículo 30 de DORA especifica las disposiciones contractuales en materia de TIC, con requisitos adicionales para los servicios que soportan funciones esenciales o importantes. Revise las descripciones de los servicios, las ubicaciones, la protección y recuperación de datos, la asistencia, la terminación y los derechos de supervisión pertinentes. Esas funciones esenciales o importantes exigen una atención especial a los niveles de servicio, los informes, las medidas de contingencia, la cooperación en las pruebas, los derechos de auditoría y los acuerdos de transición.

A continuación, verifique la implementación. Si un contrato promete un acceso administrativo restringido, obtenga evidencias de la segregación de funciones, la autenticación, la aprobación y el registro. Si promete la supresión, averigüe qué ocurre con las copias de seguridad y los registros conservados. Asigne las carencias jurídicas y las técnicas a los revisores adecuados.

Diseñe los traspasos ante incidentes antes de que ocurra uno

La política de respuesta a incidentes de un proveedor puede respaldar una evaluación de seguridad y dejar sin resolver las obligaciones de notificación. Especifique los canales de contacto, la cobertura de escalado, la información inicial, las expectativas de actualización y la responsabilidad de preservar las evidencias.

Según los artículos 33 y 34 del RGPD, el encargado notifica al responsable sin dilación indebida. El responsable valora la notificación a la autoridad de control sin dilación indebida y, de ser posible, en un plazo de 72 horas desde que tenga constancia, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas. Un riesgo alto puede exigir la comunicación a los interesados, con excepciones. Documente el razonamiento cuando no sea necesaria la notificación.

Las fases de notificación de NIS2 en la UE para incidentes significativos incluyen una alerta temprana en 24 horas, una notificación en 72 horas y, por lo general, un informe final en el plazo de un mes desde la notificación; compruebe las normas nacionales y sectoriales. DORA tiene su propio marco de notificación para los incidentes graves relacionados con las TIC. No sustituya estas evaluaciones por un único indicador de «brecha» del proveedor.

Como recomendación práctica, ejercite un incidente de un proveedor con información incompleta. Compruebe si los equipos pueden determinar los servicios afectados, la exposición, el impacto operativo y las decisiones de notificación sin esperar a un informe final de causa raíz.

Ejemplo práctico: un servicio, tres vías de revisión

Supongamos, a modo ilustrativo, que una entidad financiera incluida utiliza una plataforma alojada de atención al cliente que trata datos personales y da soporte a una función que ha clasificado como esencial o importante según DORA.

El proveedor aporta un informe de aseguramiento, una política de incidentes y un resumen de la prueba de recuperación. Seguridad constata que los controles de acceso administrativo están acreditados, pero la prueba de recuperación excluye la integración del cliente.

Por su parte, privacidad identifica un proceso poco claro para los cambios de subencargados y acuerdos de transferencia sin resolver para el acceso remoto. La revisión de DORA concluye que la asistencia en la transición y las disposiciones de auditoría pertinentes requieren atención.

El plan de acción resultante es concreto:

• El responsable técnico prueba la recuperación de la integración y documenta el resultado.
• El revisor de privacidad resuelve las cuestiones de subencargados y transferencias.
• Jurídico y compras abordan las carencias contractuales.
• El responsable último decide si el uso temporal es aceptable, con condiciones y una fecha de revisión.

Las evidencias se reutilizan, pero ninguna de las tres conclusiones se deduce de otra. Una revisión de seguridad superada no cierra las carencias de privacidad ni de resiliencia.

Supervise los cambios, la concentración y una salida ejecutable

Fije la frecuencia de revisión en función de la dependencia y del riesgo. Desencadene revisiones adicionales tras incidentes, cambios importantes en el servicio, nuevos subencargados, cambios en la ubicación de los datos, cambios de propiedad o renovaciones de contrato.

Mire más allá de los nombres de los proveedores: varios servicios pueden depender de la misma región de nube, del mismo proveedor de identidades o del mismo subcontratista. Evalúe las interrupciones correlacionadas y si la alternativa propuesta comparte esa dependencia. El artículo 29 de DORA aborda expresamente la evaluación del riesgo de concentración de TIC.

Mantenga un plan de salida proporcionado que cubra la exportación de datos, la migración, la continuidad, la revocación de accesos y las evidencias de supresión. Pruebe la utilidad de la exportación e identifique quién puede operar el sustituto. Un derecho de rescisión es más útil cuando la organización puede ejercerlo.

Las consecuencias también difieren. El RGPD tiene niveles de sanción específicos según la infracción; NIS2 exige regímenes sancionadores nacionales con límites máximos diferentes para las entidades esenciales y las importantes. Las sanciones de DORA a entidades financieras dependen de los regímenes aplicables, mientras que las sanciones del marco de supervisión de los proveedores críticos son distintas. No modele la exposición con una supuesta multa universal única.

Empiece por una dependencia relevante

Elija un proveedor que dé soporte a una función importante. Concilie su inventario de servicios, contratos, evidencias, riesgos abiertos y supuestos de salida. Termine con responsables designados y conclusiones separadas y fechadas para cada obligación aplicable.

En Secani, los equipos pueden modelar el servicio y el proveedor externo, conectar requisitos y controles con las evidencias y hacer el seguimiento de las carencias como tareas con responsables. Las decisiones revisadas por personas, los enlaces a las fuentes, los comentarios y las marcas de tiempo preservan el razonamiento. Esto permite un contexto de proveedor compartido sin ocultar los juicios diferenciados de privacidad, seguridad y resiliencia.