⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Gobernanza de cambios de subencargados del tratamiento para SaaS y MSP

Igor Petreski
14 min read
Flujo de trabajo de gobernanza de cambios de subencargados del tratamiento para GDPR DORA ISO 27701 y riesgo de proveedores

Sarah, CISO de un proveedor fintech SaaS de rápido crecimiento, abrió lo que parecía una actualización rutinaria del servicio de un proveedor de infraestructura crítica. Oculta bajo “optimizaciones del servicio” había una frase que le cambió la semana:

“Para mejorar el rendimiento de analítica, las cargas de trabajo de tratamiento de datos se migrarán a nuestro nuevo socio, DataCrunch Analytics, con efecto en 30 días”.

Treinta días. Un nuevo socio de analítica. Una comprobación rápida mostró que el proveedor estaba establecido fuera de la UE.

El equipo de ingeniería lo interpretó como una mejora rutinaria del proveedor. Compras asumió que el acuerdo existente lo cubría. Éxito del Cliente no había planificado ninguna campaña de notificación. El Departamento Jurídico no había revisado las implicaciones de la transferencia. Sarah vio de inmediato el problema real: su empresa actuaba como encargado del tratamiento para cientos de entidades financieras en toda Europa. Esos clientes eran responsables del tratamiento conforme a GDPR. Algunos habían negociado notificación previa para nuevos subencargados del tratamiento. Algunos tenían derechos de objeción. Varios tenían obligaciones de externalización y de riesgo de terceros de TIC derivadas de DORA. Unos pocos tenían declaraciones estrictas de ubicación que no podían modificarse en silencio.

Este es el momento en el que muchos proveedores SaaS, MSP, MSSP y proveedores de servicios en la nube descubren que la gobernanza de subencargados del tratamiento no es una tarea administrativa de privacidad. Es gestión de riesgos de proveedores, cumplimiento contractual, resiliencia operativa, comunicación con clientes y evidencias de auditoría en un único flujo de trabajo.

Una página pública de subencargados del tratamiento no basta. Una nota al pie en una comunicación del proveedor no basta. Un cuestionario de seguridad no basta. Un proceso defendible debe mostrar quién evaluó al subencargado, qué datos se tratan, qué clientes se ven afectados, qué acuerdos exigen notificación, si las objeciones se gestionaron antes del uso, cómo se vinculó la evidencia de transferencia internacional y dónde se conserva la evidencia final.

Clarysec trata esto como un patrón de control gobernado, no como una cadena de correos ad hoc. El flujo de trabajo conecta la gestión de la privacidad, el aseguramiento de proveedores, la revisión jurídica, el riesgo de la cadena de suministro de TIC, la notificación a clientes y las evidencias de auditoría mediante políticas de Clarysec, Zenith Blueprint: hoja de ruta de 30 pasos para auditores y Zenith Controls: guía de cumplimiento transversal.

Por qué los cambios de subencargados del tratamiento son eventos de proveedores de alto riesgo

Un cambio de subencargado del tratamiento puede modificar de un día para otro el perfil de riesgo de un servicio. Puede cambiar dónde se alojan los datos personales de clientes, desde dónde se accede a ellos, quién tiene acceso privilegiado de soporte, durante cuánto tiempo se conservan los registros, cómo se escalan los incidentes, qué responsabilidades de cifrado aplican y si se requiere un nuevo mecanismo de transferencia internacional.

Para los proveedores SaaS y los proveedores de servicios gestionados, los subencargados del tratamiento suelen formar parte de la cadena de prestación del producto. Pueden incluir proveedores de alojamiento en la nube, herramientas de gestión de tickets, servicios de entrega de correo electrónico, herramientas de analítica de IA, plataformas de procesamiento en segundo plano, proveedores de observabilidad, herramientas de soporte, procesadores de pagos, proveedores de servicios de seguridad gestionados y servicios de enriquecimiento de datos. Muchos de estos proveedores acceden o tratan datos personales de clientes incluso cuando los equipos los describen como herramientas de “infraestructura” u “operaciones”.

Conforme a GDPR, esto importa porque Article 28 exige que los encargados del tratamiento gestionen a los encargados posteriores con autorización del responsable del tratamiento. Si se utiliza una autorización general por escrito, el encargado debe informar al responsable de las incorporaciones o sustituciones previstas y darle la oportunidad de oponerse. Article 28(4) también exige imponer al subencargado del tratamiento obligaciones equivalentes de protección de datos. Article 5(2) añade el principio de responsabilidad proactiva, lo que significa que la organización debe poder demostrar el cumplimiento, no limitarse a afirmarlo.

DORA eleva la exigencia para los servicios financieros. Las entidades financieras deben gestionar el riesgo de terceros de TIC como parte integrante de la gestión del riesgo de las TIC. Deben mantener registros de acuerdos contractuales, evaluar el riesgo de concentración, comprender las cadenas de subcontratación, definir salvaguardas contractuales, asegurar derechos de auditoría y acceso, facilitar la cooperación ante incidentes y planificar salidas. Aunque un proveedor SaaS no sea directamente una entidad financiera, sus clientes financieros esperarán evidencias porque ellos mismos deben cumplir DORA.

NIS2 amplía el enfoque hacia la seguridad de la cadena de suministro y la responsabilidad del órgano de dirección. Article 21 exige medidas técnicas, operativas y organizativas adecuadas, incluida la seguridad de la cadena de suministro, la gestión de incidentes, la continuidad del negocio, el control de acceso, la gestión de activos, la adquisición y el mantenimiento seguros, y la evaluación de la eficacia. Article 20 asigna la responsabilidad de supervisión a los órganos de dirección. Para proveedores en la nube, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, proveedores de servicios de centros de datos, prestadores de servicios de confianza, mercados en línea, motores de búsqueda y determinados servicios de comunicaciones, la visibilidad sobre subencargados del tratamiento forma parte de la gobernanza de la ciberseguridad.

ISO/IEC 27001:2022 e ISO/IEC 27701:2025 lo convierten en operación. ISO/IEC 27001:2022 exige que el SGSI comprenda el contexto, los requisitos de las partes interesadas, los riesgos, los planes de tratamiento, los controles operativos y la información documentada. ISO/IEC 27701:2025 extiende esa disciplina de sistema de gestión a la gestión de la privacidad de la información. Un PIMS orientado al encargado del tratamiento debe demostrar que el tratamiento posterior de la información de identificación personal (PII) de clientes se comprende, se controla, se gobierna contractualmente, se supervisa y se evidencia.

El patrón de Clarysec: listar, evaluar, notificar, gestionar objeciones, contratar, transferir, evidenciar

El modelo de gobernanza de subencargados del tratamiento más sólido es lo bastante simple para que los equipos operativos lo sigan y lo bastante riguroso para que los auditores lo prueben. Clarysec utiliza siete verbos:

  1. Listar cada subencargado del tratamiento actual y propuesto.
  2. Evaluar la privacidad, la seguridad, la resiliencia y el riesgo de dependencia antes del uso.
  3. Notificar a los clientes conforme al acuerdo aplicable.
  4. Gestionar las objeciones dentro del plazo acordado.
  5. Actualizar el contrato de encargo del tratamiento (DPA), el anexo de seguridad y las obligaciones trasladadas contractualmente.
  6. Vincular las evidencias de alojamiento, ubicación del tratamiento y transferencia internacional.
  7. Conservar las evidencias en los registros de privacidad y proveedores.

El primer anclaje operativo es la Política de gestión de privacidad de encargados, subencargados y terceros. Establece:

[Encargado del tratamiento] El Responsable de Proveedores / Compras DEBE mantener en REG08, antes del uso, la lista de subencargados del tratamiento y subcontratistas utilizados para tratar información de identificación personal (PII) de clientes, y actualizar REG08 dentro de los 10 días hábiles posteriores a un cambio aprobado.

Esa cláusula convierte una lista de subencargados del tratamiento en un registro controlado. También explicita el plazo: REG08 se actualiza antes del uso y después se actualiza dentro de los 10 días hábiles posteriores a un cambio aprobado.

La misma política hace auditable la notificación al cliente:

[Encargado del tratamiento] El Responsable de Proveedores / Compras DEBE notificar al cliente los subencargados del tratamiento nuevos o sustitutos previstos conforme al acuerdo aplicable con el cliente antes del uso, y registrar en REG08 la notificación, el período de objeción y el resultado.

Este es el detalle que falta en muchos programas. La cuestión no es solo si se actualizó una página pública. La cuestión es si se notificó a los clientes correctos de la forma requerida, antes de que el subencargado tratara su información de identificación personal (PII), conservando como evidencia el período de objeción y el resultado.

La política también conecta la gobernanza de cambios con la diligencia debida:

[Todos] El Responsable de Proveedores / Compras DEBE completar en REG08 las evidencias de diligencia debida de privacidad antes de seleccionar, renovar o modificar de forma material cualquier relación con un encargado del tratamiento, subencargado del tratamiento o tercero que trate o acceda a información de identificación personal (PII).

Un cambio material puede incluir la sustitución de infraestructura, la incorporación de un proveedor posterior de analítica, el traslado de regiones de alojamiento, la habilitación de acceso de soporte técnico desde un nuevo país, la ampliación de categorías de datos o el cambio del comportamiento de conservación de un servicio.

Por último, la política cierra la deficiencia de traslado contractual de obligaciones:

[Encargado del tratamiento] El Responsable de Proveedores / Compras DEBE asegurar que cada contrato con un subencargado del tratamiento contenga obligaciones trasladadas contractualmente de privacidad, seguridad, asistencia, devolución, supresión, interfaz de incidentes y vinculación de transferencias antes de que el subencargado trate información de identificación personal (PII).

Esto importa porque un anexo de seguridad genérico no siempre es suficiente. Las obligaciones específicas del encargado del tratamiento deben trasladarse aguas abajo antes de que comience el tratamiento.

Dónde conectan las políticas de Clarysec privacidad, proveedores y transferencias

La gobernanza de subencargados del tratamiento solo funciona cuando privacidad, Departamento Jurídico, seguridad de proveedores y gestión operativa de cambios utilizan la misma cadena de evidencias.

La Política de cumplimiento legal y normativo - pyme establece la regla previa al intercambio:

Las cláusulas del contrato de encargo del tratamiento (DPA) o términos contractuales equivalentes deben acordarse antes de compartir datos personales o sensibles.

Para entornos empresariales, la Política de cumplimiento legal y normativo hace más granular la expectativa de evidencias al exigir:

Comunicaciones de subencargados del tratamiento y declaraciones geográficas de transferencia de datos

También identifica desencadenantes de gobernanza relacionados con:

Cambios en mecanismos de transferencia de datos, subencargados del tratamiento o flujos transfronterizos de datos

La Política de seguridad de terceros y proveedores establece:

El uso de subcontratistas sujeto a consentimiento previo por escrito

Para organizaciones más pequeñas, la Política de seguridad de terceros y proveedores - pyme ofrece una versión escalable:

Restricciones a la subcontratación ulterior sin aprobación

También hace explícita la reevaluación de cambios de proveedores:

Todos los cambios de proveedores, incluidos cambios de titularidad, tipo de servicio, ubicación del alojamiento o subcontratación, deben reevaluarse por su impacto en el riesgo y su relevancia contractual.

La Política de protección de datos y privacidad incluye:

Requisitos de aprobación de subencargados del tratamiento

La Política de gestión del riesgo de dependencia de proveedores añade la perspectiva de resiliencia:

Comunicación de subcontratistas: el proveedor debe informarnos de los subcontratistas clave y de cualquier cambio relativo a ellos, especialmente cuando creen capas adicionales de dependencia.

En conjunto, estas políticas crean una regla operativa completa: no compartir datos personales sin términos contractuales, no usar subencargados del tratamiento ocultos, no permitir subcontratación no gestionada, no dejar sin evaluar cambios de alojamiento o ubicación, y no aprobar sin evidencias de transferencia cuando corresponda.

Cómo Zenith Controls estructura el conjunto de controles de proveedores

En Zenith Controls, Clarysec mapea la gobernanza de cambios de subencargados del tratamiento principalmente con controles de proveedores y legales de ISO/IEC 27002:2022. Esto es importante porque demuestra que la gobernanza de subencargados del tratamiento no es solo un proceso de privacidad. También es un control de seguridad de la información, gestión de proveedores, cumplimiento legal y resiliencia.

Control ISO/IEC 27002:2022Nombre del controlRol en la gobernanza de subencargados del tratamiento
5.19Seguridad de la información en las relaciones con proveedoresEstablece la base de gestión de riesgos de proveedores para identificar y gestionar proveedores que acceden a información o sistemas
5.20Tratamiento de la seguridad de la información en los acuerdos con proveedoresAsegura que los acuerdos incluyan obligaciones de seguridad, privacidad, subcontratación, incidentes, auditoría, supresión y transferencia
5.21Gestión de la seguridad de la información en la cadena de suministro de TICFacilita la visibilidad sobre dependencias posteriores de TIC y riesgos de la cadena de suministro
5.22Supervisión, revisión y gestión de cambios de los servicios de proveedoresProporciona el control operativo para reevaluar cambios de proveedores, incluidos nuevos subencargados del tratamiento y cambios de alojamiento
5.23Seguridad de la información para el uso de servicios en la nubeAplica cuando los subencargados del tratamiento proporcionan alojamiento en la nube, plataformas en la nube, SaaS o tratamiento en la nube
5.31Requisitos legales, estatutarios, reglamentarios y contractualesConecta el flujo de trabajo con GDPR, DORA, NIS2, contratos de encargo del tratamiento (DPA) de clientes, obligaciones de transferencia y deberes contractuales de notificación

Zenith Controls describe el control 5.22, “Supervisión, revisión y gestión de cambios de los servicios de proveedores”, como un control preventivo que respalda la confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad Identify y con capacidades operativas de seguridad de la relación con proveedores y aseguramiento de la seguridad de la información. Eso es exactamente lo que requiere un cambio de subencargado del tratamiento: identificar el cambio, reevaluar el riesgo, confirmar la cobertura contractual y conservar evidencias de aseguramiento.

Para el control 5.20, Zenith Controls plantea los acuerdos con proveedores como controles preventivos que cubren confidencialidad, integridad y disponibilidad. Aquí encajan los términos del contrato de encargo del tratamiento (DPA), los anexos de seguridad, las cláusulas de subcontratación, los derechos de auditoría, la asistencia ante incidentes, la devolución y supresión, y las obligaciones de vinculación de transferencias.

Para el control 5.21, la perspectiva de la cadena de suministro importa porque un subencargado del tratamiento puede crear una dependencia de cuarto nivel. Un proveedor SaaS puede depender de un proveedor de infraestructura, que depende de un proveedor de analítica de datos, que depende de otra región de nube o de un socio de soporte. La organización debe comprender la cadena lo suficiente para gestionar el riesgo, los compromisos con clientes y las opciones de salida.

La hoja de ruta de 30 pasos: convertir la política en un procedimiento operativo

Zenith Blueprint sitúa el riesgo de proveedores y el riesgo aguas abajo en el paso 23, Controles organizativos. Explica que los acuerdos con proveedores suelen abordar confidencialidad, control de acceso, medidas técnicas y organizativas, plazos de notificación de incidentes, derechos de auditoría, controles de subcontratistas y disposiciones de fin de contrato. El Blueprint plantea un punto crítico:

La estructura del acuerdo importa. Estas cláusulas pueden estar en un contrato marco de servicios, en un contrato de encargo del tratamiento (DPA) específico o en un anexo de seguridad independiente. Lo importante es que existan y que ambas partes las comprendan y acepten.

El Blueprint también indica a los equipos qué hacer con los subcontratistas:

Para cada proveedor crítico, identifique si utiliza subcontratistas (subencargados del tratamiento) que puedan acceder a sus datos o sistemas. Documente cómo se trasladan sus requisitos de seguridad de la información a estas partes, ya sea mediante los términos contractuales de su proveedor o mediante sus propias cláusulas directas.

Para la gobernanza de cambios de proveedores, la alineación operativa correcta es el control 5.22 de ISO/IEC 27002:2022:

Establezca un procedimiento simple y escalable para evaluar cambios en los servicios de proveedores (5.22), como migración a la nube, nuevos subencargados del tratamiento o rediseño de infraestructura. Defina desencadenantes que requieran una reevaluación de seguridad.

Esto proporciona a CISO y DPO una ruta práctica. El paso 23 define la intención del control. REG08 captura evidencias de privacidad de encargados del tratamiento, subencargados del tratamiento y terceros. REG09 captura evidencias de transferencia. Los contratos con proveedores, los contratos de encargo del tratamiento (DPA) y las solicitudes de cambio conectan el flujo de trabajo con la realidad operativa.

Un flujo de trabajo práctico para la notificación de cambios de subencargados del tratamiento

Un flujo de trabajo de cambio de subencargado del tratamiento debe ser deliberadamente predecible. Cada etapa debe tener un propietario, evidencias y un punto de control que impida el uso prematuro en producción.

Etapa del flujo de trabajoPropietarioEvidenciaPunto de control de aprobación
Recepción del subencargado del tratamiento propuestoResponsable de Proveedores o ComprasSolicitud de cambio, descripción del servicio, categorías de datos, finalidad del tratamientoEvaluación preliminar de privacidad y seguridad
Diligencia debida de privacidad y seguridadDPO, Seguridad, ComprasDiligencia debida en REG08, certificaciones, cuestionario, historial de incidentes, medidas técnicas y organizativasAprobación del propietario del riesgo
Revisión contractual y del DPADepartamento Jurídico, ComprasMapeo de cláusulas del DPA, términos de subcontratación, derechos de auditoría, asistencia ante incidentes, términos de supresiónAprobación jurídica
Revisión de ubicación y transferenciaPrivacidad, Departamento Jurídico, SeguridadUbicaciones de tratamiento, ubicaciones de alojamiento, mecanismo de transferencia, vinculación con REG09Aprobación de transferencia
Notificación al clienteÉxito del Cliente, Departamento Jurídico, PrivacidadCopia de la notificación, clientes afectados, base del acuerdo, fecha de notificación, ventana de objeciónNotificación enviada antes del uso
Gestión de objecionesDepartamento Jurídico, Responsable de Cuenta, Propietario del RiesgoRegistro de objeciones, respuesta al riesgo, decisión del cliente, bloqueo técnico si es necesarioObjeción resuelta o excepción aprobada
Habilitación en producciónIngeniería, Responsable de CambiosTicket de cambio, referencias de aprobación, fecha de entrada en producciónSin tratamiento antes de la aprobación
Actualización posterior al cambioResponsable de ProveedoresREG08 actualizado, lista pública si se utiliza, repositorio contractual, periodicidad de supervisiónRevisión de evidencias dentro del SLA definido

El principio clave es simple: la notificación al cliente debe producirse antes del uso cuando el acuerdo lo exige. Actualizar una página web pública después de la implementación puede respaldar la transparencia, pero no demuestra la notificación específica al cliente, la autorización contractual ni la gestión de objeciones.

Aplicación del flujo de trabajo a la crisis de Sarah

La notificación del proveedor de Sarah sobre DataCrunch Analytics activa el proceso completo.

Primero, el Responsable de Proveedores abre un registro de cambio en REG08. El registro identifica a CoreStack, DataCrunch Analytics, la finalidad del servicio, el impacto en entornos de cliente, el rol en el tratamiento, las categorías de datos, las ubicaciones de tratamiento, el modelo de acceso de soporte técnico, el período de conservación y si pueden estar presentes categorías especiales de datos o datos regulados de clientes financieros.

Segundo, Privacidad y Seguridad realizan la diligencia debida. Revisan las medidas técnicas y organizativas de DataCrunch Analytics, el cifrado, el control de acceso, el registro de eventos, la notificación de incidentes, las capacidades de supresión, el aseguramiento de auditoría, la lista de subencargados del tratamiento y las certificaciones de seguridad. Como el proveedor está fuera de la UE, la revisión de ubicación y transferencia es obligatoria.

Tercero, el Departamento Jurídico comprueba si los contratos de encargo del tratamiento (DPA) de clientes utilizan autorización específica o autorización general con notificación. Los clientes se segmentan en grupos de notificación: clientes con notificación estándar de 30 días, clientes corporativos con ventanas de objeción de 45 días, clientes que requieren aprobación específica, clientes restringidos con limitaciones de ubicación y clientes no afectados cuyos datos no pasan por la carga de trabajo de analítica.

Cuarto, se vinculan las evidencias de transferencia. La Política de gestión de privacidad de encargados, subencargados y terceros exige:

[Ambos] El Responsable de Proveedores / Compras DEBE registrar en REG08 las ubicaciones de tratamiento, ubicaciones de alojamiento e indicadores de transferencia internacional, y vincular las evidencias de transferencia aplicables a REG09 antes de aprobar un encargado del tratamiento, subencargado del tratamiento, cambio de ubicación o cambio de servicio relevante para transferencias.

Quinto, Éxito del Cliente envía notificaciones formales a través de canales aprobados. Cada notificación incluye el subencargado del tratamiento previsto, la finalidad, las categorías de datos, el resumen de ubicación, la fecha efectiva, el plazo de objeción y la vía de contacto.

Sexto, se gestionan las objeciones. Si una entidad financiera se opone porque el cambio afecta a una función esencial o importante o a una transferencia a un tercer país, el equipo de Sarah evalúa alternativas: excluir el entorno de cliente, mantener la ruta de tratamiento anterior, exigir soporte solo desde la UE, modificar las salvaguardas contractuales o retrasar el cambio hasta que la objeción se resuelva.

Séptimo, Ingeniería recibe aprobación solo para los entornos de cliente y cargas de trabajo que superaron el punto de control. El ticket de cambio de producción enlaza con REG08, REG09, la aprobación jurídica, las evidencias de notificación y cualquier exclusión específica de clientes. Tras la entrada en producción, se actualizan el registro interno, la página pública de subencargados del tratamiento y el repositorio contractual.

Esa es la diferencia entre apagar fuegos de forma reactiva y una gobernanza defendible.

Mapeo de cumplimiento transversal para una única cadena de evidencias

La ventaja de Clarysec es que un solo flujo de trabajo puede satisfacer múltiples marcos cuando las evidencias se diseñan correctamente desde el inicio.

Área de requisitoCómo lo aborda el flujo de trabajo
GDPR Article 28 y responsabilidad proactivaMantiene evidencias de autorización de subencargados del tratamiento, notificaciones a clientes, resultados de objeciones, traslado contractual del DPA y vinculación de transferencias
ISO/IEC 27701:2025 PIMSDemuestra gobernanza de la privacidad basada en roles para encargados del tratamiento, control del tratamiento posterior, conservación de evidencias y supervisión
ISO/IEC 27001:2022 SGSIRespalda los requisitos de las partes interesadas, la evaluación de riesgos, el control operativo, los controles de proveedores, los requisitos legales y la información documentada
Controles ISO/IEC 27002:2022Implementa controles de relación con proveedores, acuerdos con proveedores, cadena de suministro de TIC, cambios de proveedores, servicios en la nube y requisitos legales
Riesgo de terceros de TIC de DORARespalda registros, diligencia debida, visibilidad de cadenas de subcontratación, conocimiento de ubicaciones, riesgo de concentración, derechos de auditoría, asistencia ante incidentes y planificación de salida
Seguridad de la cadena de suministro de NIS2Respalda Article 21 sobre seguridad de la cadena de suministro, análisis de riesgos de proveedores, gestión de incidentes, continuidad del negocio y supervisión por la dirección
NIST CSF 2.0 GOVERN y GV.SCSe alinea con la estrategia de riesgo de proveedores, la criticidad de proveedores, los requisitos contractuales, la diligencia debida, la supervisión, la participación en incidentes y la planificación de terminación
Perspectiva de gobernanza de COBIT 2019Respalda las necesidades de las partes interesadas, la optimización del riesgo, la responsabilidad de proveedores, los informes a la dirección y las evidencias de aseguramiento

NIST CSF 2.0 es útil como capa organizadora neutral. Su función GOVERN incluye comprender obligaciones legales, regulatorias, contractuales, de privacidad y de libertades civiles, asignar roles, establecer políticas, revisar el desempeño y gestionar el riesgo de la cadena de suministro de ciberseguridad. La categoría GV.SC espera procesos de riesgo de proveedores, criticidad de proveedores, requisitos contractuales de ciberseguridad, diligencia debida, supervisión del ciclo de vida, planificación de incidentes y actividades posteriores a la relación.

DORA es más prescriptivo para las entidades financieras. Articles 28 to 30 exigen gestión del riesgo de terceros de TIC, registros contractuales, clasificación de función esencial o importante, visibilidad de la cadena de subcontratación, conocimiento de ubicaciones, salvaguardas contractuales, derechos de auditoría, cooperación ante incidentes y planificación de salida. Si su plataforma SaaS da soporte a clientes financieros, sus evidencias de subencargados del tratamiento forman parte del paquete de evidencias de DORA de esos clientes.

NIS2 añade responsabilidad del órgano de dirección. Article 20 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad y supervisen su implantación. Article 21 exige seguridad de la cadena de suministro y evaluación de las prácticas de ciberseguridad de los proveedores. Por tanto, un cambio significativo de subencargado del tratamiento debe ser visible en los informes de riesgos, no quedar oculto en una carpeta de compras.

Qué probarán los auditores

Un proceso maduro de subencargados del tratamiento crea una línea directa desde la política hasta la evidencia.

Un auditor de ISO/IEC 27001:2022 empezará por el alcance del SGSI, los requisitos de las partes interesadas, los riesgos, la Declaración de Aplicabilidad y los controles operativos. Probablemente probará las relaciones con proveedores, los acuerdos con proveedores, la cadena de suministro de TIC, la supervisión y gestión de cambios de proveedores, los requisitos legales, los servicios en la nube, la protección de la privacidad, el registro de eventos y el control operativo de cambios.

Un auditor de ISO/IEC 27701:2025 PIMS se centrará en la claridad de roles. ¿Es usted encargado del tratamiento, responsable del tratamiento, corresponsable del tratamiento o una combinación según el servicio? Para las actividades de encargado del tratamiento, pedirá la lista de subencargados, la base de autorización, evidencias de notificación, gestión de objeciones, contratos posteriores, evidencias de transferencia, soporte de supresión, interfaz de incidentes y registros de supervisión.

Un revisor de privacidad de GDPR probará la responsabilidad proactiva. Preguntará quién trata datos personales, con qué finalidad, bajo qué acuerdo, en qué ubicación, con qué salvaguardas y con qué transparencia hacia el cliente. Si un cliente se opuso, preguntará qué ocurrió antes de que comenzara el tratamiento.

Un auditor de cliente bajo DORA preguntará si el subencargado del tratamiento da soporte a una función esencial o importante, si las cadenas de subcontratación son visibles, si las ubicaciones de los datos están documentadas, si la asistencia ante incidentes está garantizada contractualmente, si los derechos de auditoría se trasladan aguas abajo, si se consideró el riesgo de concentración y si la salida es posible.

Un evaluador de NIS2 se centrará en la seguridad de la cadena de suministro, la supervisión por la dirección, la preparación ante incidentes y los controles proporcionados. Puede preguntar cómo se detectan los cambios de proveedores, cómo se evalúan los proveedores directos, cómo se consideran las vulnerabilidades de proveedores y cómo se escalan los incidentes que afectan a destinatarios del servicio.

El conjunto de evidencias debe ser fácil de reconstruir:

  • Solicitud de cambio de subencargado del tratamiento aprobada.
  • Registro de diligencia debida en REG08.
  • Evaluación de categorías de datos y finalidad del tratamiento.
  • Evidencias de ubicaciones de tratamiento y alojamiento.
  • Evidencias de transferencia en REG09 cuando corresponda.
  • Revisión del DPA y del traslado contractual de obligaciones.
  • Lista de notificaciones a clientes, fechas, redacción y prueba de entrega.
  • Registro de objeciones y evidencias de resolución.
  • Ticket de cambio de producción vinculado a la aprobación.
  • Lista actualizada de subencargados del tratamiento y calendario de supervisión.
  • Aceptación del riesgo o aprobación de excepción cuando sea necesario.

Patrones comunes de fallo

El primer fallo es tratar una página de subencargados del tratamiento como si fuera todo el proceso. Una página pública respalda la transparencia, pero no prueba la notificación específica a clientes, la gestión de objeciones ni la autorización.

El segundo fallo es separar las evidencias de privacidad, seguridad y compras. Privacidad puede aprobar el DPA, Seguridad puede revisar un informe SOC 2 y Compras puede archivar el contrato, pero no existe un único registro que conecte la decisión.

El tercer fallo es perder la vinculación de transferencias. Los equipos registran el nombre del proveedor, pero no las ubicaciones de tratamiento, ubicaciones de alojamiento, ubicaciones de soporte, indicadores de transferencia internacional ni evidencias en REG09.

El cuarto fallo es habilitar la producción antes de que cierren las ventanas de objeción. Una vez que la información de identificación personal (PII) de clientes es tratada por el nuevo subencargado, la organización puede haber incumplido ya el acuerdo.

El quinto fallo es un traslado contractual débil. El proveedor directo acepta términos robustos, pero sus proveedores posteriores no quedan sujetos a obligaciones equivalentes de privacidad, seguridad, asistencia, devolución, supresión, incidentes, auditoría y transferencia.

El sexto fallo es una detección deficiente de cambios. Un proveedor cambia de titularidad, ubicación de alojamiento, tipo de servicio, modelo de soporte o cadena de subcontratistas, y nadie reevalúa el riesgo.

El séptimo fallo es no disponer de pista de auditoría. Los equipos recuerdan la decisión, pero no pueden probar cuándo ocurrió, quién la aprobó, a qué clientes se notificó y cómo se resolvieron las objeciones.

Informes a la dirección para CISO y DPO

La gobernanza de subencargados del tratamiento debe producir información de gestión, no solo artefactos de cumplimiento.

MétricaPor qué importa
Subencargados del tratamiento activos por servicio y categoría de datosMuestra la huella de tratamiento y la exposición de privacidad
Subencargados del tratamiento que dan soporte a servicios críticosRespalda la planificación de resiliencia, el aseguramiento de DORA y la priorización de proveedores
Subencargados del tratamiento con acceso o alojamiento en terceros paísesRespalda las revisiones de transferencia y las declaraciones a clientes
Ventanas de objeción próximasEvita la habilitación prematura en producción
Subencargados del tratamiento sin diligencia debida vigenteIdentifica deficiencias de aseguramiento
Contratos sin cláusulas de traslado contractual de obligacionesDestaca riesgos legales y operativos
Cambios de proveedores pendientes de reevaluaciónMuestra la carga de gobernanza y el trabajo pendiente
Objeciones de clientes abiertas más allá del SLAIndica bloqueos comerciales, legales o técnicos no resueltos

Este informe encaja con el modelo de sistema de gestión. ISO/IEC 27001:2022 espera liderazgo, control operativo, evaluación del desempeño y mejora continua. DORA y NIS2 elevan la responsabilidad de la dirección. La gobernanza de subencargados del tratamiento debe aparecer en reuniones de dirección de privacidad, revisiones de riesgo de proveedores, revisión por la dirección del SGSI e informes de riesgo de TIC cuando corresponda.

Construya su paquete de evidencias de cambios de subencargados del tratamiento

Empiece con un cambio reciente de proveedor y compruebe si su organización puede responder a estas preguntas:

  • ¿Se identificó al proveedor como encargado del tratamiento, subencargado del tratamiento, proveedor, proveedor de TIC o todas estas cosas?
  • ¿Se actualizó REG08 o un registro equivalente antes del uso?
  • ¿Se registraron las ubicaciones de tratamiento y de alojamiento?
  • ¿Se evaluaron los indicadores de transferencia internacional?
  • ¿Se vinculó la evidencia de transferencia con REG09 o con un expediente equivalente?
  • ¿El contrato incluía obligaciones trasladadas contractualmente de privacidad, seguridad, asistencia, devolución, supresión, incidentes, auditoría y transferencia?
  • ¿Se notificó a los clientes conforme a sus acuerdos antes de que comenzara el tratamiento?
  • ¿Se supervisaron y resolvieron las ventanas de objeción?
  • ¿Se bloqueó la habilitación en producción hasta la aprobación?
  • ¿Podría un auditor reconstruir la trazabilidad de la decisión en menos de 30 minutos?

Si la respuesta es no, la deficiencia no es solo legal. Es operativa, contractual, de riesgo de proveedores, de privacidad y de preparación para auditorías.

Clarysec ayuda a los equipos a cerrar esa brecha con rapidez. Use Zenith Blueprint para incorporar la gobernanza de subencargados del tratamiento en su hoja de ruta de implantación de SGSI y PIMS. Use Zenith Controls para mapear controles de relaciones con proveedores, acuerdos con proveedores, cadena de suministro de TIC, cambios de proveedores, servicios en la nube y requisitos legales en ISO/IEC 27001:2022, ISO/IEC 27701:2025, GDPR, DORA, NIS2, NIST CSF 2.0 y COBIT 2019. Use la Política de gestión de privacidad de encargados, subencargados y terceros, la Política de seguridad de terceros y proveedores, la Política de cumplimiento legal y normativo, la Política de protección de datos y privacidad y la Política de gestión del riesgo de dependencia de proveedores para convertir el mapeo en ejecución diaria.

No espere a la nota al pie inesperada en un correo de un proveedor. Construya ahora el flujo de trabajo, el paquete de evidencias y el mapa de controles, de modo que cada cambio de subencargado del tratamiento sea prueba de una gobernanza madura en lugar de una crisis de cumplimiento.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Gobernanza de la seguridad de las API: evidencias ISO 27001 para 2026

Gobernanza de la seguridad de las API: evidencias ISO 27001 para 2026

Las API en la sombra, los tokens débiles, la ausencia de límites de tasa y los registros inconsistentes ya son fallos de gobernanza. Esta guía de referencia muestra a los CISO cómo construir evidencias de seguridad de API para auditorías alineadas con ISO/IEC 27001:2022, NIS2, DORA, RGPD de la UE, NIST CSF 2.0 y COBIT.

Modelado de amenazas para ISO 27001, NIS2 y DORA

Modelado de amenazas para ISO 27001, NIS2 y DORA

Una guía práctica para directores de seguridad de la información (CISO) sobre el uso del modelado de amenazas como evidencia de seguridad desde el diseño para ISO 27001, NIS2, DORA, CRA, GDPR y aseguramiento ante clientes.