Certificados de supresión de información de identificación personal (PII) para el cumplimiento en la salida de encargados del tratamiento

Maria, Directora de Seguridad de la Información de una fintech europea en crecimiento, observaba un breve correo electrónico de DataLeap, el proveedor SaaS de analítica de marketing que su empresa acababa de dar de baja.

“Confirmamos que todos los datos asociados a su cuenta han sido eliminados de nuestros sistemas de producción.”

Era correcto, rápido y casi inútil.

Durante tres años, DataLeap había tratado identificadores de clientes, datos de interacción de campañas, atributos de puntuación de leads, metadatos de consentimiento y analítica de comportamiento de miles de clientes de la UE. FinSecure se preparaba para una auditoría de DORA, el Delegado de Protección de Datos revisaba evidencias de responsabilidad proactiva de GDPR y el equipo de compras quería cerrar el registro del proveedor antes del siguiente ciclo de facturación. El correo respondía solo a una cuestión muy limitada: los datos de producción. No decía nada sobre copias de seguridad, registros, tickets de soporte, espacios de trabajo de analítica, cachés de subencargados del tratamiento, copias de prueba, credenciales de API o informes archivados.

Maria planteó la pregunta a la que todo Director de Seguridad de la Información, DPO y responsable de cumplimiento acaba enfrentándose durante la desvinculación de un SaaS:

¿Dónde está el certificado de supresión?

Esa pregunta convierte una terminación contractual ordinaria en un evento de cumplimiento. En virtud de GDPR, los responsables del tratamiento deben poder demostrar el cumplimiento de principios como la limitación del plazo de conservación, la integridad, la confidencialidad y la responsabilidad proactiva. En virtud de DORA, las entidades financieras deben gestionar el riesgo de terceros de TIC durante todo el ciclo de vida de la relación, incluidas la terminación y las estrategias de salida que eviten interrupciones, incumplimientos normativos y perjuicios a clientes. En virtud de ISO/IEC 27701:2025, las organizaciones necesitan evidencias PIMS basadas en roles para las actividades de tratamiento de información de identificación personal (PII) como responsable del tratamiento, encargado del tratamiento, subencargado del tratamiento y encargado del tratamiento de información de identificación personal (PII) en la nube. En virtud de ISO/IEC 27001:2022, las dependencias de proveedores, los servicios externos, los controles operativos y las evidencias conservadas deben gestionarse dentro del Sistema de Gestión de la Seguridad de la Información.

La deficiencia rara vez se descubre durante la incorporación. Aparece en la salida. El contrato dice que los datos se suprimirán, pero no define las evidencias. El proveedor de servicios en la nube puede exportar un CSV, pero no puede explicar la gestión de copias de seguridad. Compras puede terminar la relación con el proveedor, pero cumplimiento no puede probar el destino final de los datos. TI puede deshabilitar cuentas, pero deshabilitar el acceso no equivale a suprimir datos. Legal puede enviar una notificación de terminación, pero los auditores quieren una cadena de evidencias.

Clarysec trata la salida de encargados del tratamiento como una cadena de control auditable, no como una tarea administrativa secundaria.

Por qué la salida de encargados del tratamiento se ha convertido en un punto crítico de cumplimiento

El final de una relación con un servicio SaaS, de nómina, Recursos Humanos, finanzas, CRM, alojamiento en la nube, analítica de marketing o servicios TIC gestionados es uno de los momentos de mayor riesgo en el ciclo de vida de los datos personales. Durante las operaciones normales, al menos la organización sabe qué sistema está en producción, quién es su propietario y qué contrato aplica. En la terminación, la propiedad se fragmenta con rapidez. Compras cierra el registro del proveedor. TI deshabilita usuarios. Legal archiva el contrato. El negocio migra a la plataforma sustitutiva. El antiguo proveedor sigue conservando datos conforme a sus ciclos estándar de copia de seguridad, archivo o registro de eventos.

Esa fragmentación es exactamente lo que auditores y reguladores comprueban.

GDPR define el tratamiento de forma amplia, incluida la conservación, la supresión y la destrucción. Distingue entre responsables del tratamiento, que determinan fines y medios, y encargados del tratamiento, que actúan por cuenta de los responsables del tratamiento. Article 5 establece principios como la limitación de la finalidad, la minimización de datos, la limitación del plazo de conservación y la integridad y confidencialidad. Article 5(2) añade el principio de responsabilidad proactiva, lo que significa que el responsable del tratamiento debe poder demostrar el cumplimiento. Article 28(3)(g) exige que los contratos con encargados del tratamiento establezcan que, a elección del responsable del tratamiento, el encargado del tratamiento debe suprimir o devolver todos los datos personales al finalizar el servicio y suprimir las copias existentes, salvo que la ley exija su conservación.

Un correo informal del proveedor rara vez satisface ese estándar cuando los datos incluyen información de nómina, registros financieros, datos relativos a la salud, identificadores de clientes, registros de autenticación o registros regulados de clientes.

DORA eleva el nivel de exigencia para las entidades financieras. Desde el 17 de enero de 2025, DORA se aplica como el marco normativo de resiliencia operativa digital del sector financiero de la UE. Exige que las entidades financieras gestionen el riesgo de terceros de TIC como parte integral de su marco general de riesgos y que sigan siendo plenamente responsables del cumplimiento cuando externalizan servicios. DORA espera que las organizaciones mantengan registros de información de contratos de servicios TIC, identifiquen servicios que soporten funciones esenciales o importantes, realicen diligencia debida, evalúen el riesgo de concentración, incluyan derechos contractuales de acceso, recuperación y devolución de datos, y mantengan estrategias de terminación y salida.

Para funciones esenciales o importantes, los contratos DORA deben ir más allá. Necesitan disposiciones sobre derechos de auditoría, periodos de transición, niveles de servicio, pruebas de contingencia, obligaciones de cooperación y soporte de salida. Un certificado de supresión no es todo el paquete de salida de DORA, pero sí es un artefacto de evidencia crítico dentro de él.

NIS2 también es relevante para muchos proveedores de la cadena TIC ampliada, incluidos proveedores de computación en la nube, proveedores de centros de datos, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados y otros proveedores de infraestructura digital. NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluida la seguridad de la cadena de suministro, controles de relación con proveedores, control de acceso, gestión de activos, gestión de incidentes, continuidad e higiene de ciberseguridad. Para las entidades financieras cubiertas por DORA, DORA actúa generalmente como el acto jurídico sectorial específico de la Unión para requisitos comparables de riesgo TIC, notificación, pruebas y terceros, pero NIS2 sigue enmarcando el ecosistema de ciberseguridad más amplio.

El mensaje práctico es sencillo: si un proveedor trató información de identificación personal (PII), dio soporte a operaciones reguladas o formó parte de su cadena de servicios TIC, las evidencias de salida son un control de riesgos.

La visión de Clarysec: la salida de encargados del tratamiento es una cadena de control

Un flujo de trabajo maduro de salida de encargados del tratamiento responde a tres preguntas:

1. ¿Qué datos, sistemas y subencargados del tratamiento están incluidos en el alcance?
2. ¿Qué acción de devolución, transferencia, supresión o eliminación exige la ley y el contrato?
3. ¿Qué evidencias prueban que la acción se completó antes de cerrar la salida?

En Zenith Controls: The Cross-Compliance Guide, este escenario se mapea con el control 5.20 de ISO/IEC 27002:2022, “Abordar la seguridad de la información en los acuerdos con proveedores”; el control 8.10, “Supresión de información”; y el control 7.14, “Eliminación segura o reutilización de equipos”. No son elementos separados de una lista de verificación. La salida de encargados del tratamiento conecta acuerdos con proveedores, gestión del ciclo de vida de los datos, baja de servicios en la nube, retirada de accesos, propiedad de activos, conservación de evidencias y preparación para auditorías.

Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec sitúa esto en la fase Controls in Action. En el Step 23, Organizational controls, se espera que los acuerdos con proveedores cubran disposiciones de terminación contractual, controles de subcontratistas, derechos de auditoría y protocolos de incidentes. El Blueprint describe las áreas típicas de los acuerdos con proveedores como incluyentes de:

“Disposiciones de finalización contractual, como devolución o destrucción de datos, recuperación de activos y desactivación de cuentas.”

Esa frase es el punto donde convergen la responsabilidad proactiva de GDPR, las evidencias PIMS de ISO/IEC 27701:2025, las expectativas de salida de DORA, la seguridad de la cadena de suministro de NIS2 y el control operativo de ISO/IEC 27001:2022.

El mismo Zenith Blueprint, en el Step 19, Technological Controls I, explica el riesgo de supresión que subyace a la salida de encargados del tratamiento:

“Este control garantiza que los datos no se conserven más tiempo del necesario y que, cuando ya no sean necesarios, se supriman de forma segura y fiable.”

El Step 18, Physical Controls II, lleva la expectativa de evidencias al plano práctico:

“Si se utiliza un proveedor externo, solicite y conserve certificados de destrucción como evidencias de auditoría.”

Para sistemas en la nube, la eliminación física suele quedar fuera del control directo del cliente. Esto hace aún más importantes la confirmación contractual de supresión, los certificados de borrado con calidad de cumplimiento y la documentación archivada del SGSI.

El modelo operativo de Clarysec es directo: cláusula contractual, desencadenante de salida, inventario de datos, acción de supresión, confirmación de subencargados del tratamiento, registro de evidencias y verificación final.

Por qué “suprimido” no es lo mismo que demostrado

Un hallazgo de auditoría habitual se formula así:

“La organización afirmó que el proveedor había suprimido los datos, pero no pudo aportar evidencias de la supresión, el alcance de la supresión, la fecha de supresión, la parte responsable, los sistemas incluidos, la gestión de copias de seguridad o la confirmación de subencargados del tratamiento.”

Esto ocurre en grandes empresas, pero también es común en pymes que dependen intensamente de herramientas SaaS para nómina, sistemas de tickets de soporte, CRM, incorporación de Recursos Humanos, almacenamiento en la nube, colaboración, analítica y desarrollo de software. Cuando cambia un proveedor, los datos personales suelen permanecer en cuentas inactivas, adjuntos de soporte, archivos temporales de migración, exportaciones de desarrollo, bases de datos de preproducción y ciclos de copia de seguridad.

El conjunto de políticas de Clarysec convierte “suprimido” en un requisito de evidencias.

La Third party and supplier security policy [P26] exige en la cláusula 6.5.1.2:

“Devolución o destrucción certificada de toda la información propiedad de la organización”

La cláusula 6.5.1.3 exige después:

“Verificación final de cumplimiento (por ejemplo, revisión de registros, atestaciones de cumplimiento)”

Esta distinción importa. Un certificado de supresión no es todo el control. Es un artefacto dentro de un paquete de verificación final de cumplimiento. Los auditores querrán ver si el certificado coincide con el contrato del proveedor, el inventario de datos, el ticket de salida, los registros de acceso, la lista de subencargados del tratamiento, el calendario de conservación y la evaluación de riesgos.

Para pymes, la Third-Party and Supplier Security Policy - SME [P26S] proporciona una referencia práctica. La cláusula 5.3.6, bajo los requisitos de gobierno, exige:

“Condiciones de terminación, incluida la devolución o destrucción segura de datos”

La cláusula 6.4.2.3, bajo los requisitos de implantación de la política, exige a los proveedores:

“Confirmar por escrito que los datos se han suprimido de forma segura”

La Data Retention and Disposal Policy [P14] añade el requisito de evidencias en la cláusula 4.7.2:

“Deberá proporcionar evidencias documentadas de cumplimiento (por ejemplo, registros de eliminación, certificados de destrucción) previa solicitud.”

Para pymes, la Data Retention Policy and Secure Disposal Policy - SME exige en la cláusula 6.2.3:

“Las acciones de eliminación deben registrarse con la fecha, la categoría de registro, el método y la persona responsable.”

Esta es la diferencia entre confiar en el proveedor y disponer de evidencias de auditoría.

ISO/IEC 27701:2025: evidencias de salida basadas en roles

ISO/IEC 27701:2025 añade una capa de gestión de la privacidad al SGSI. La salida de encargados del tratamiento debe reflejar el rol en el PIMS de la organización. Un responsable del tratamiento que finaliza una relación con un encargado del tratamiento tiene responsabilidades distintas de las de un encargado del tratamiento que finaliza una relación con un subencargado del tratamiento. Un encargado del tratamiento que actúa siguiendo instrucciones del cliente debe documentar que siguió dichas instrucciones. Un encargado del tratamiento en la nube debe demostrar que la devolución, transferencia, supresión o eliminación se produjo dentro del plazo acordado con el cliente.

El conjunto de políticas PIMS de Clarysec utiliza etiquetas de rol para hacerlo operativo. “Both” aplica tanto si la organización es responsable del tratamiento como si es encargada del tratamiento. “Processor” aplica cuando se trata información de identificación personal (PII) siguiendo instrucciones documentadas del responsable del tratamiento. “Subprocessor” aplica cuando se actúa por encargo de otro encargado del tratamiento.

La Processor, Subprocessor and Third-Party Privacy Management Policy exige en la cláusula 4.5.6:

“[Both] El Responsable del proveedor / de compras DEBE obtener evidencias de devolución, supresión, eliminación o transición en REG08 dentro de los 30 días posteriores a la terminación del contrato, su vencimiento, la instrucción del cliente o el evento de salida aprobado, salvo que aplique un plazo contractual más corto.”

La PII Retention, Deletion and Disposal Policy separa las obligaciones del encargado del tratamiento y del subencargado del tratamiento. La cláusula 4.3.3 establece:

“[Processor] El Responsable del proveedor / de compras DEBE ejecutar o confirmar la devolución, transferencia, supresión o eliminación ordenada por el cliente en REG08 antes del plazo contractual o de la fecha documentada de instrucción del cliente.”

La cláusula 4.3.4 establece:

“[Subprocessor] El Responsable del proveedor / de compras DEBE obtener evidencias de devolución, supresión o eliminación del subencargado del tratamiento en REG08 dentro del periodo contractual de evidencias posterior a la instrucción del cliente, la finalización del servicio o la terminación del subencargado del tratamiento.”

La cláusula 7.1.7 devuelve el requisito al cierre:

“[Both] El Responsable del proveedor / de compras DEBE obtener evidencias del encargado del tratamiento, subencargado del tratamiento o servicio externo para las acciones requeridas de devolución, transferencia o destino final en REG08 antes de cerrar la salida del servicio.”

Para servicios en la nube, la Cloud PII Processor Policy exige en la cláusula 4.6.3:

“[Processor] El propietario del sistema / propietario de la aplicación DEBE completar la devolución, transferencia, supresión o eliminación aprobada de la información de identificación personal (PII) del cliente dentro del plazo acordado con el cliente y registrar las evidencias de finalización en REG08 o REG12.”

La mejora operativa es inmediata. No espere a una auditoría. Incorpore el requisito de evidencias en el desencadenante de salida, asígnelo a un responsable, establezca un plazo e impida el cierre hasta que REG08 o REG12 esté completo.

Qué incluye un buen paquete de evidencias de salida de encargados del tratamiento

Un certificado de supresión no debe ser un PDF vago con un logotipo y una sola frase. Debe respaldar un paquete de evidencias estructurado que pueda resistir un requerimiento de GDPR, una auditoría PIMS de ISO/IEC 27701:2025, una auditoría de seguimiento de ISO/IEC 27001:2022, un requerimiento de supervisión de DORA, una revisión de aseguramiento ante clientes o una auditoría interna.

Esto no es burocracia. Es una cadena de custodia práctica para la información de identificación personal (PII) en la salida del servicio.

La cláusula contractual que evita la crisis

El problema de Maria empezó años antes del último correo de DataLeap. Empezó cuando se firmó el contrato con una cláusula de supresión vaga y sin obligación de evidencias. El flujo de trabajo de salida de encargados del tratamiento más sólido comienza en compras, no en la terminación.

Para servicios en la nube, la Cloud Usage Policy empresarial exige en la cláusula 5.4.4:

“Cláusulas de terminación que permitan una baja segura y verificable”

Para pymes, la Cloud Usage Policy - SME exige en la cláusula 6.3.5:

“Confirmación de procedimientos de supresión segura antes del cierre de la cuenta”

Una cláusula práctica de contrato con proveedores debe exigir devolución o supresión, definir plazos, cubrir copias de seguridad y subencargados del tratamiento, exigir evidencias y preservar los derechos de auditoría.

Cláusula de ejemplo: devolución, supresión y evidencias de datos

Tras la terminación o expiración del acuerdo, o previa instrucción escrita del responsable del tratamiento, el encargado del tratamiento deberá, a elección del responsable del tratamiento, devolver de forma segura todos los datos personales en un formato acordado y legible por máquina o suprimir de forma segura todos los datos personales de los sistemas, soportes, copias de seguridad y entornos bajo el control del encargado del tratamiento, salvo que el Derecho de la Unión o de un Estado miembro exija su conservación.

Dentro de los treinta días naturales siguientes a la finalización de la acción requerida, o en un plazo más corto cuando así se haya acordado contractualmente, el encargado del tratamiento deberá proporcionar un Certificado de Supresión firmado o una atestación de cumplimiento equivalente. El certificado deberá identificar el servicio, las categorías de datos, los sistemas cubiertos, el intervalo de fechas de supresión, el método de supresión, la gestión de copias de seguridad y archivos, el estado de subencargados del tratamiento, las excepciones conservadas y el firmante autorizado.

El responsable del tratamiento podrá solicitar evidencias de soporte razonables, incluidos registros, registros de eliminación, atestaciones de subencargados del tratamiento y documentación del proceso, para verificar el certificado y cerrar el registro de salida del proveedor.

Este lenguaje convierte la responsabilidad proactiva en un entregable operativo.

Ejemplo práctico: salida de un SaaS de nómina

Considere una pyme que migra de PayrollCloud A a PayrollCloud B. PayrollCloud A trataba nombres de empleados, direcciones, identificadores fiscales, datos bancarios, historial salarial, registros de enfermedad y tickets de soporte. Utilizaba un proveedor de alojamiento en la nube y una plataforma de soporte como subencargados del tratamiento.

Una salida alineada con Clarysec funcionaría así.

1. Abrir un ticket de salida del proveedor

Compras crea un ticket de salida vinculado al registro del proveedor. El ticket incluye la fecha de terminación del contrato, la fecha final del servicio, el propietario de negocio, el propietario del sistema, el DPO o contacto de privacidad, y si pueden estar implicados datos de categorías especiales. Dado que la nómina puede incluir datos sensibles de empleo y datos relativos a la salud, la calificación de riesgo es alta.

2. Mapear la salida con el acuerdo

El Responsable del proveedor revisa el contrato para identificar cláusulas de devolución, supresión, auditoría, transición y subencargados del tratamiento. Si el contrato es débil, el responsable igualmente envía una instrucción formal que exige devolución, supresión y confirmación de subencargados del tratamiento. La expectativa de evidencias se apoya en las políticas de Clarysec, incluidas P26, P26S, P14, la Cloud Usage Policy y la Cloud Usage Policy - SME.

3. Definir el alcance de la información de identificación personal (PII)

El propietario del sistema completa una declaración de alcance de los datos que cubre registros de nómina de producción, documentos de autoservicio de empleados, adjuntos, exportaciones, tickets de soporte, registros de auditoría que contienen identificadores de usuario, archivos de integración de API, extractos temporales de migración, copias de seguridad, instantáneas y datos en poder de subencargados del tratamiento.

Esto respalda la responsabilidad proactiva de GDPR, las evidencias PIMS de ISO/IEC 27701:2025, el control operativo de ISO/IEC 27001:2022 y, para entidades financieras, las expectativas del registro de información de terceros de TIC de DORA.

4. Solicitar evidencias de devolución, supresión y subencargados del tratamiento

El Responsable del proveedor envía una solicitud estructurada a PayrollCloud A para confirmar la finalización de la exportación, la supresión de los datos del entorno de cliente de producción, la gestión de copias de seguridad y archivos inmutables, la supresión de adjuntos de tickets de soporte, la revocación de cuentas y credenciales de API específicas del cliente, las evidencias de supresión o eliminación de subencargados del tratamiento y un certificado de supresión firmado.

5. Registrar la finalización en REG08 o REG12

El Responsable del proveedor registra cada elemento de evidencia en REG08. Si la organización actúa como encargada del tratamiento y la aplicación en la nube contenía información de identificación personal (PII) de clientes, la finalización también puede registrarse en REG12 en virtud de la Cloud PII Processor Policy.

6. Realizar la verificación final antes del cierre

Cumplimiento compara el certificado de supresión con la declaración de alcance de los datos. TI revisa los registros de acceso y las evidencias de cierre de cuentas. El DPO comprueba si existe alguna excepción de conservación, como una obligación legal o una retención por disputa. Seguridad verifica que se hayan eliminado tokens de API, cuentas de servicio y configuraciones de SSO.

Solo entonces se cierra el ticket de salida.

Si el proveedor se niega a aportar evidencias, la cuestión se convierte en un asunto de tratamiento de riesgos. Puede activar escalado, medidas contractuales, análisis de notificación a clientes, evaluación regulatoria, supervisión reforzada durante la transición o cambios en la calificación de riesgo del proveedor.

DORA, NIS2 y resiliencia TIC: evidencias de salida más allá de la privacidad

DORA trata la salida de proveedores como parte de la resiliencia, no solo como administración de privacidad. Una entidad financiera sigue siendo responsable del cumplimiento incluso cuando externaliza servicios TIC. Debe mantener un registro de información de contratos de servicios TIC, distinguir servicios que soportan funciones esenciales o importantes, realizar diligencia debida, evaluar el riesgo de concentración y mantener estrategias de salida.

Un certificado de supresión del encargado del tratamiento puede afectar a varios aspectos de DORA:

• Continuidad del servicio al cliente
• Notificación regulatoria
• Integridad de los datos
• Respuesta a incidentes
• Derechos de auditoría
• Resiliencia operativa
• Planificación de recuperación y transición
• Gestión de funciones esenciales o importantes

Para una entidad de pago, empresa de servicios de inversión, entidad de crédito, proveedor de servicios de criptoactivos o plataforma fintech, el certificado de supresión debe formar parte de un paquete de salida más amplio. No basta con probar que la información de identificación personal (PII) se suprimió si la organización no puede probar también que la transición del servicio evitó interrupciones, que las obligaciones regulatorias siguieron cumpliéndose y que los impactos sobre clientes se gestionaron.

NIS2 amplía la conversación sobre seguridad de proveedores más allá de los servicios financieros. La salida de encargados del tratamiento es una prueba de seguridad de la cadena de suministro. Si una entidad esencial o importante no puede probar que un proveedor devolvió o suprimió los datos al finalizar el servicio, tiene una debilidad en la gestión de la relación con proveedores, el control de activos, el gobierno de accesos, la protección de datos y, potencialmente, la preparación ante incidentes.

Si una salida fallida provoca acceso no autorizado, pérdida, divulgación o interrupción del servicio, la organización puede necesitar evaluar las obligaciones de notificación de incidentes conforme a la normativa aplicable y las normas nacionales de transposición.

Mapeo de cumplimiento cruzado: un flujo de trabajo, muchas obligaciones

El valor de un flujo de trabajo bien diseñado de salida de encargados del tratamiento es que satisface varios marcos a la vez.

NIST CSF 2.0 resulta especialmente útil como capa de comunicación. Su función GOVERN exige que las organizaciones comprendan las obligaciones legales, regulatorias, contractuales y de privacidad, definan la estrategia de riesgos, asignen roles y establezcan supervisión. Sus resultados de Cybersecurity Supply Chain Risk Management cubren requisitos de proveedores en contratos, supervisión del riesgo de proveedores y actividades posteriores al final de una asociación o acuerdo de servicio. GV.SC-10 es exactamente el lugar al que pertenece la salida de encargados del tratamiento.

Qué preguntarán los auditores

Los distintos auditores abordan la salida de encargados del tratamiento desde distintas perspectivas, pero el paquete de evidencias debe ser suficientemente sólido para todos ellos.

Un auditor de ISO/IEC 27001:2022 puede no empezar pidiendo un “certificado de supresión de información de identificación personal (PII)”. Puede comenzar por el alcance, los requisitos de las partes interesadas, el control de proveedores, la Declaración de Aplicabilidad, el tratamiento de riesgos y la información documentada conservada. Si el certificado de supresión no puede conectarse con esos elementos, puede parecer un artefacto aislado en lugar de la prueba de un control que funciona.

Un auditor PIMS preguntará si la organización entendió su rol de privacidad. ¿Era responsable del tratamiento, encargado del tratamiento, subencargado del tratamiento o encargado del tratamiento de información de identificación personal (PII) en la nube? ¿La salida se basó en una instrucción documentada del cliente? ¿Se trasladaron contractualmente las obligaciones a los subencargados del tratamiento? ¿Se almacenaron las evidencias en el registro correcto? ¿Se justificaron las excepciones?

Un revisor de DORA preguntará si el servicio está en el registro de información TIC, si soporta una función esencial o importante, si el contrato incluía devolución de datos y derechos de auditoría, y si la transición evitó interrupciones y perjuicios a clientes.

El mismo paquete de evidencias debe responder a todos ellos.

Patrones de fallo habituales

Clarysec observa repetidamente las mismas debilidades durante las revisiones de salida de encargados del tratamiento:

• Los contratos exigen supresión, pero no definen evidencias.
• Los proveedores proporcionan declaraciones genéricas de supresión sin alcance de sistemas.
• Se ignoran copias de seguridad, instantáneas y archivos inmutables.
• La supresión por parte de subencargados del tratamiento se asume, no se evidencia.
• La desactivación de accesos se trata como supresión de datos.
• Compras cierra el proveedor antes de que cumplimiento revise las evidencias.
• Las excepciones de conservación no están documentadas.
• Los desarrolladores conservan exportaciones de prueba después de finalizar el desarrollo externalizado.
• Las cuentas en la nube se cierran antes de obtener la confirmación de supresión.
• Las evidencias de auditoría se almacenan en el correo electrónico, no en un registro controlado.

El escenario de desarrollo externalizado es especialmente común. La Outsourced development policy - SME exige en la cláusula 7.4.1.2:

“Todos los datos en poder de los desarrolladores deben suprimirse y podrán solicitarse evidencias”

Para los equipos de desarrollo, esto incluye conjuntos de datos locales, bases de datos de preproducción, registros de depuración, volcados de fallos, capturas de pantalla, exportaciones de soporte, prompts de pruebas de IA y archivos temporales de migración. Si el flujo de trabajo de salida del proveedor ignora los datos en poder de los desarrolladores, está incompleto.

Lista de verificación de salida de encargados del tratamiento

Un proceso sólido de salida de encargados del tratamiento no necesita ser complejo, pero debe ser disciplinado.

• Identifique el desencadenante de salida: terminación, vencimiento, instrucción del cliente, sustitución del proveedor, respuesta a una brecha de seguridad, transición aprobada o terminación de un subencargado del tratamiento.
• Confirme el rol en el PIMS: responsable del tratamiento, encargado del tratamiento, subencargado del tratamiento, corresponsable del tratamiento o encargado del tratamiento de información de identificación personal (PII) en la nube.
• Vincule el registro del proveedor: contrato, propietario del servicio, función de negocio, criticidad y categorías de datos.
• Identifique el alcance de la información de identificación personal (PII): producción, copias de seguridad, registros, exportaciones, tickets de soporte, analítica, datos de prueba y subencargados del tratamiento.
• Emita instrucciones por escrito: devolución, transferencia, supresión, eliminación o excepción de conservación.
• Obtenga evidencias: certificado de supresión, certificado de destrucción, registros, atestación de subencargados del tratamiento y prueba de cierre de accesos.
• Registre las evidencias en REG08 o REG12: ubicación de evidencias, fecha, método, persona responsable y revisor.
• Verifique antes del cierre: compare las evidencias con el alcance de datos, el contrato y las instrucciones del cliente.
• Escale excepciones: evidencias ausentes, expiración retrasada de copias de seguridad, conservación disputada, proveedor no colaborador o acceso residual.
• Alimente la mejora: actualice plantillas contractuales, calificación de riesgo del proveedor, calendario de conservación, plan de auditoría e informes de dirección.

Así es como Zenith Blueprint, Zenith Controls y el conjunto de políticas de Clarysec trabajan juntos. El Blueprint muestra dónde encaja el control en el recorrido de implantación. Las políticas definen el comportamiento requerido. Zenith Controls mapea la relación de controles en ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST y expectativas de auditoría.

El mensaje para el Consejo de Administración

La salida de encargados del tratamiento no es un paso administrativo al final de un contrato. Es una prueba en tiempo real del gobierno de la privacidad, la gestión de proveedores, la seguridad en la nube, la resiliencia TIC y la disciplina de evidencias de auditoría.

Un certificado de supresión solo aporta valor cuando está vinculado a:

• Una relación de proveedor conocida
• Un alcance de datos definido
• Una instrucción contractual o del cliente
• Un método de supresión o eliminación segura
• Evidencias de obligaciones trasladadas contractualmente a subencargados del tratamiento
• Cierre de accesos
• Gestión de copias de seguridad y archivos
• Un registro de evidencias controlado
• Verificación final de cumplimiento

Sin esa cadena, la organización confía en la palabra del proveedor justo en el momento en que debería basarse en evidencias.

Próximos pasos con Clarysec

Si su organización utiliza proveedores SaaS, de nube, nómina, Recursos Humanos, finanzas, soporte, desarrollo o servicios TIC gestionados, revise su flujo de trabajo de salida de encargados del tratamiento antes de enviar la próxima notificación de terminación.

Clarysec puede ayudarle a implantar un modelo práctico y preparado para auditorías de salida de encargados del tratamiento mediante:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap para situar la salida de proveedores, la supresión y la eliminación en los pasos de implantación adecuados.
• Zenith Controls: The Cross-Compliance Guide para mapear acuerdos con proveedores, supresión de información y eliminación segura en ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST y expectativas de auditoría.
• Processor, Subprocessor and Third-Party Privacy Management Policy y PII Retention, Deletion and Disposal Policy para operacionalizar las evidencias REG08.
• Third party and supplier security policy, Data Retention and Disposal Policy y Cloud PII Processor Policy para hacer exigibles las evidencias de salida.

Su próxima acción es sencilla: elija un proveedor dado de baja recientemente y construya un paquete retrospectivo de evidencias de salida. Si no puede probar la devolución, la supresión, la confirmación de subencargados del tratamiento y la verificación final, ese es su primer elemento de remediación.

Clarysec puede ayudarle a convertir esa deficiencia en un control repetible de salida de encargados del tratamiento antes de que un auditor, regulador o cliente lo solicite.