Estrategias de salida de servicios TIC conforme a DORA con controles ISO 27001
A las 07:42 de un lunes, el responsable de operaciones de una fintech recibe el mensaje que nadie quiere leer: el proveedor de monitorización de transacciones en la nube de la entidad ha sufrido una indisponibilidad regional grave. A las 08:15, el Director de Riesgos pregunta si el servicio afectado da soporte a una función crítica o importante. A las 08:40, el área jurídica quiere saber si el contrato otorga a la entidad asistencia para la transición, exportación de datos, supresión y derechos de auditoría. A las 09:05, el CISO busca evidencias de que el plan de salida se ha probado, no solo redactado.
En otra entidad de servicios financieros, Sarah, CISO de una plataforma fintech en rápido crecimiento, abre una solicitud de información previa a auditoría para una evaluación de cumplimiento de DORA. Las preguntas son conocidas hasta que llega a la sección sobre proveedores terceros de servicios de TIC que dan soporte a funciones críticas o importantes. Los auditores no preguntan si la entidad tiene una política de proveedores. Solicitan estrategias de salida documentadas, probadas y viables.
Su atención pasa de inmediato al proveedor principal de nube que aloja la plataforma, y después al proveedor de servicios gestionados de seguridad que monitoriza amenazas de forma continua. ¿Qué ocurre si el proveedor de nube sufre una interrupción geopolítica? ¿Qué ocurre si el MSSP es adquirido por un competidor? ¿Qué ocurre si un proveedor SaaS crítico entra en insolvencia, finaliza el servicio o pierde la confianza de los clientes tras un incidente grave?
La respuesta incómoda en muchas entidades es la misma. Existe una evaluación de riesgos de proveedores, un plan de continuidad del negocio (BCP), una carpeta contractual, un inventario de nube y quizá un informe de copias de seguridad. Pero no existe una estrategia única de salida para proveedores terceros de servicios TIC conforme a DORA, preparada para auditoría, que conecte criticidad de negocio, derechos contractuales, portabilidad técnica, planes de continuidad, evidencias de copias de seguridad, obligaciones de privacidad y aprobación de la dirección.
DORA cambia el enfoque de la gestión de proveedores. En virtud del Reglamento (UE) 2022/2554, las entidades financieras deben gestionar el riesgo relacionado con las TIC derivado de terceros como parte del marco de gestión del riesgo de las TIC. Siguen siendo plenamente responsables del cumplimiento, mantienen un registro de contratos de servicios TIC, distinguen los acuerdos de TIC que dan soporte a funciones críticas o importantes, evalúan los riesgos de concentración y subcontratación, y mantienen estrategias de salida para dependencias críticas de proveedores terceros de servicios TIC. DORA es aplicable desde el 17 de enero de 2025 y establece requisitos uniformes de la UE para la gestión del riesgo de las TIC, la notificación de incidentes, las pruebas de resiliencia, el intercambio de información y la gestión del riesgo de terceros de TIC en un amplio conjunto de entidades financieras.
Una estrategia de salida de DORA no es un párrafo en un contrato con proveedores. Es un sistema de control. Debe estar gobernada, evaluada en términos de riesgo, ser técnicamente viable, exigible contractualmente, probada, sustentada en evidencias y mejorada de forma continua.
El enfoque de Clarysec combina Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, plantillas de políticas empresariales y Zenith Controls: The Cross-Compliance Guide Zenith Controls para convertir la pregunta de ese lunes por la mañana en una respuesta preparada.
Por qué fallan las estrategias de salida de DORA en auditorías reales
La mayoría de los fallos en las estrategias de salida TIC de DORA son estructurales antes que técnicos. La organización tiene un responsable del proveedor, pero no un propietario del riesgo claramente asignado. Tiene tareas de copia de seguridad, pero no evidencias de restauración. Tiene un cuestionario de diligencia debida de proveedores, pero no una decisión documentada sobre si el proveedor da soporte a una función crítica o importante. Tiene cláusulas contractuales de terminación, pero no un periodo de transición alineado con el plan de continuidad del negocio (BCP).
DORA obliga a integrar todas estas piezas. El artículo 28 establece los principios generales para la gestión del riesgo de terceros de TIC, incluida la necesidad de gestionar el riesgo de los proveedores terceros de servicios de TIC durante todo el ciclo de vida y mantener estrategias de salida adecuadas. El artículo 30 establece requisitos contractuales detallados para los servicios de TIC que dan soporte a funciones críticas o importantes, incluidas descripciones de servicio, ubicaciones del tratamiento de datos, protecciones de seguridad, derechos de acceso y auditoría, asistencia ante incidentes, cooperación con las autoridades competentes y derechos de terminación.
El reglamento también es proporcional. Los artículos 4 y 16 permiten que determinadas entidades de menor tamaño o exentas apliquen un marco simplificado de gestión del riesgo de las TIC. Pero simplificado no significa no documentado. Las entidades financieras pequeñas siguen necesitando una gestión documentada del riesgo de las TIC, monitorización continua, sistemas resilientes, identificación rápida de incidentes de TIC, identificación de dependencias clave de terceros de TIC, copias de seguridad y restauración, continuidad del negocio, respuesta y recuperación, pruebas, lecciones aprendidas y formación.
Una fintech pequeña no puede decir: «Somos demasiado pequeños para la planificación de salida». Puede decir: «Nuestra estrategia de salida de DORA está dimensionada según nuestro tamaño, perfil de riesgo y complejidad del servicio». La diferencia son las evidencias.
Para las entidades que también se encuentran dentro del ámbito nacional de NIS2, DORA actúa como el acto jurídico sectorial específico de la Unión para las obligaciones de ciberseguridad solapadas en el sector financiero. NIS2 sigue siendo relevante en el ecosistema más amplio, especialmente para proveedores de servicios gestionados, Managed Detection and Response (MDR), proveedores de nube, centros de datos y entidades de infraestructura digital. El artículo 21 de NIS2 refuerza los mismos temas: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición segura, evaluación de la eficacia, formación, criptografía, control de acceso, gestión de activos y autenticación.
Supervisores, clientes, auditores y consejos de administración pueden formular la pregunta de forma distinta, pero el problema central es el mismo: ¿puede la organización salir de un proveedor crítico de TIC sin perder el control de la continuidad del servicio, los datos, las evidencias o el impacto en clientes?
Integrar la estrategia de salida en el SGSI
ISO/IEC 27001:2022 proporciona la columna vertebral del sistema de gestión para la planificación de salida conforme a DORA.
Las cláusulas 4.1 a 4.4 exigen que la organización defina su contexto, partes interesadas, requisitos legales, regulatorios y contractuales, alcance del SGSI, interfaces, dependencias y procesos. Aquí es donde una entidad financiera identifica DORA, compromisos con clientes, expectativas de externalización, dependencias de servicios en la nube, obligaciones de privacidad, subcontratistas y servicios de TIC dentro de los límites del SGSI.
Las cláusulas 5.1 a 5.3 exigen liderazgo, política, recursos, asignación de roles y rendición de cuentas. Esto se alinea con el modelo de gobernanza de DORA, en el que el órgano de dirección define, aprueba, supervisa y sigue siendo responsable de la gestión del riesgo de las TIC, incluida la continuidad del negocio de TIC, los planes de respuesta y recuperación, los planes de auditoría de TIC, los presupuestos, la estrategia de resiliencia y la política de riesgo de terceros de TIC.
Las cláusulas 6.1.1 a 6.1.3 convierten la planificación de salida en tratamiento de riesgos. La organización define criterios de riesgo, realiza evaluaciones de riesgos repetibles, identifica riesgos para la confidencialidad, integridad y disponibilidad, asigna propietarios del riesgo, evalúa consecuencias y probabilidad, selecciona opciones de tratamiento, compara los controles con el Anexo A, genera una Declaración de Aplicabilidad, prepara un Plan de Tratamiento de Riesgos y obtiene la aprobación del propietario del riesgo y la aceptación del riesgo residual.
La cláusula 8.1 exige después planificación y control operacional. La organización debe planificar, implementar y controlar los procesos del SGSI, mantener información documentada que demuestre que los procesos se ejecutaron según lo previsto, gestionar cambios y controlar procesos, productos o servicios proporcionados externamente que sean relevantes para el SGSI.
ISO/IEC 27005:2022 refuerza este enfoque. La cláusula 6.2 recomienda a las organizaciones identificar los requisitos de las partes interesadas, incluidos los controles del Anexo A de ISO/IEC 27001:2022, estándares sectoriales específicos, regulaciones nacionales e internacionales, normas internas, requisitos contractuales y controles existentes procedentes de tratamientos de riesgos anteriores. Las cláusulas 6.4.1 a 6.4.3 explican que los criterios de riesgo deben considerar aspectos legales y regulatorios, relaciones con proveedores, privacidad, impactos operativos, incumplimientos contractuales, operaciones de terceros y consecuencias reputacionales. Las cláusulas 8.2 a 8.6 respaldan una biblioteca de controles y un plan de tratamiento que puede combinar el Anexo A de ISO/IEC 27001:2022 con DORA, NIS2, el RGPD de la UE, compromisos con clientes y políticas internas.
El modelo operativo es directo: un inventario de requisitos, un registro de riesgos de proveedores, una Declaración de Aplicabilidad, un Plan de Tratamiento de Riesgos y un paquete de evidencias para cada escenario crítico de salida.
Los controles ISO/IEC 27001:2022 que sustentan la planificación de salida de DORA
Las estrategias de salida de DORA están preparadas para auditoría cuando la gobernanza de proveedores, la portabilidad en la nube, la planificación de continuidad y las evidencias de copias de seguridad se tratan como una única cadena de control conectada.
Zenith Controls de Clarysec mapea los controles del Anexo A de ISO/IEC 27001:2022 con atributos de control, evidencias de auditoría y expectativas de cumplimiento transversal. No es un marco de control independiente. Es la guía de cumplimiento transversal de Clarysec para entender cómo los controles ISO/IEC 27001:2022 respaldan resultados de auditoría, regulatorios y operativos.
| Control del Anexo A de ISO/IEC 27001:2022 | Función en la estrategia de salida | Evidencia de DORA que respalda | Foco del auditor |
|---|---|---|---|
| A.5.19 Seguridad de la información en las relaciones con proveedores | Establece el proceso de gestión de riesgos de proveedores | Clasificación de proveedores, propiedad de dependencias, evaluación de riesgos | ¿Se gestiona el riesgo de proveedores de forma coherente? |
| A.5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores | Convierte las expectativas de salida en condiciones contractuales exigibles | Derechos de terminación, derechos de auditoría, asistencia para la transición, soporte ante incidentes, devolución y supresión de datos | ¿El contrato respalda realmente el plan de salida? |
| A.5.21 Gestión de la seguridad de la información en la cadena de suministro de TIC | Amplía el escrutinio a subcontratistas y dependencias aguas abajo | Visibilidad de subcontratistas, riesgo de cadena, evaluación de concentración | ¿La entidad comprende sus dependencias ocultas? |
| A.5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores | Mantiene actualizado el riesgo de proveedores durante los cambios de servicio | Registros de revisión, evaluaciones de cambios de servicio, seguimiento de remediación | ¿La supervisión de proveedores es continua? |
| A.5.23 Seguridad de la información para el uso de servicios en la nube | Controla la incorporación, el uso, la gestión, la portabilidad y la salida de servicios en la nube | Exportación de datos, supresión, soporte de migración, evidencias de dependencia del proveedor | ¿Puede la entidad recuperar y eliminar de forma segura los datos? |
| A.5.30 Preparación de las TIC para la continuidad del negocio | Prueba si los servicios críticos de TIC pueden restaurarse o sustituirse dentro de las tolerancias del negocio | Planes de continuidad, objetivos de recuperación, mecanismos alternativos, soluciones alternativas probadas | ¿La salida es técnicamente viable durante una interrupción? |
| A.8.13 Copia de seguridad de la información | Proporciona datos recuperables para escenarios de salida o fallo | Calendarios de copias de seguridad, resultados de pruebas de restauración, comprobaciones de integridad | ¿Pueden restaurarse los datos dentro del RTO y el RPO? |
Para una estrategia de salida para proveedores terceros de servicios TIC conforme a DORA, la pista de auditoría debe demostrar que:
- El proveedor está clasificado y vinculado a procesos de negocio.
- El servicio se ha evaluado para determinar si da soporte a una función crítica o importante.
- El riesgo de salida está registrado con un propietario del riesgo responsable.
- Las cláusulas contractuales respaldan la transición, el acceso, la auditoría, la devolución de datos, la supresión de datos, la cooperación y la continuidad.
- La portabilidad e interoperabilidad en la nube han sido validadas.
- Las pruebas de copias de seguridad y restauración demuestran la capacidad de recuperación.
- Se ha documentado la sustitución temporal o el tratamiento alternativo.
- Los resultados de las pruebas de salida han sido revisados, remediados y comunicados a la dirección.
El lenguaje contractual es el primer control de continuidad
El contrato debe ser el primer control de continuidad, no una barrera para la continuidad. Si el proveedor puede terminar el servicio con poca antelación, retrasar exportaciones, restringir el acceso a registros, cobrar tarifas de transición no definidas o rechazar el soporte de migración, la estrategia de salida es frágil.
En Zenith Blueprint, la fase Controls in Action, Step 23, Control 5.20, explica que los acuerdos con proveedores deben incluir los requisitos prácticos de seguridad que hacen posible la salida:
Las áreas clave que suelen abordarse en los acuerdos con proveedores incluyen:
✓ Obligaciones de confidencialidad, incluido el alcance, la duración y las restricciones de divulgación a terceros;
✓ Responsabilidades de control de acceso, como quién puede acceder a sus datos, cómo se gestionan las credenciales y qué supervisión existe;
✓ medidas técnicas y organizativas (MTO) para la protección de datos, el cifrado, la transmisión segura, las copias de seguridad y los compromisos de disponibilidad;
✓ Plazos y protocolos de notificación de incidentes, a menudo con marcos temporales definidos;
✓ Derechos de auditoría, incluida la frecuencia, el alcance y el acceso a evidencias pertinentes;
✓ Controles sobre subcontratistas, que exigen al proveedor trasladar obligaciones de seguridad equivalentes a sus socios aguas abajo;
✓ Disposiciones de fin de contrato, como devolución o destrucción de datos, recuperación de activos y desactivación de cuentas.
Esta lista conecta las expectativas contractuales del artículo 30 de DORA con el control A.5.20 del Anexo A de ISO/IEC 27001:2022.
El lenguaje de políticas empresariales de Clarysec traslada el mismo punto al plano operativo. En la Supplier Dependency Risk Management Policy Política de Gestión del Riesgo de Dependencia de Proveedores, sección «Requisitos de implementación», cláusula 6.4.3, se establece:
Controles alternativos técnicos: asegurar la portabilidad e interoperabilidad de los datos para respaldar la transición del servicio cuando sea necesario (por ejemplo, copias de seguridad periódicas en formatos estándar desde un proveedor SaaS para permitir la migración).
La misma política, en la cláusula 6.8.2, exige:
Un derecho a asistencia de transición (cláusula de asistencia de salida) cuando sea necesario cambiar de proveedor, incluido el mantenimiento del servicio durante un periodo de transición definido.
Esta cláusula suele decidir si una estrategia de salida supera la auditoría. Convierte la salida de un evento abrupto en una transición gestionada.
Para entidades más pequeñas, la Third-Party and Supplier Security Policy-sme Política de Seguridad de Terceros y Proveedores - Pyme, sección «Requisitos de gobernanza», cláusula 5.3.6, exige:
Condiciones de terminación, incluida la devolución o destrucción segura de los datos
Para entornos empresariales, la Third party and supplier security policy Política de Seguridad de Terceros y Proveedores, sección «Requisitos de implementación de la política», cláusula 6.5.1.2, exige:
Devolución o destrucción certificada de toda la información propiedad de la organización
Estos requisitos de política deben trazarse directamente a cláusulas contractuales, procedimientos del proveedor, runbooks de salida y evidencias de auditoría.
Salida de la nube: pruebe la portabilidad antes de necesitarla
Los servicios en la nube son el ámbito en el que las estrategias de salida de DORA suelen volverse imprecisas. La entidad asume que puede exportar los datos, pero nadie ha probado el formato. Asume que se producirá la supresión, pero el modelo de conservación del proveedor incluye copias de seguridad y almacenamiento replicado. Asume que un proveedor alternativo puede recibir los datos, pero los esquemas, las integraciones de identidad, las claves criptográficas, los secretos, los registros, las interfaces de programación de aplicaciones y la limitación de tasa hacen que la migración sea más lenta de lo que permite la tolerancia al impacto.
El control A.5.23 del Anexo A de ISO/IEC 27001:2022 aborda este problema de ciclo de vida al exigir controles de seguridad de la información para la adquisición, el uso, la gestión y la salida de servicios en la nube.
La Cloud Usage Policy-sme de Clarysec Política de Uso de la Nube - Pyme, sección «Requisitos de implementación de la política», cláusula 6.3.4, exige:
Capacidad de exportación de datos confirmada antes de la incorporación (por ejemplo, para evitar la dependencia del proveedor)
La cláusula 6.3.5 exige:
Confirmación de los procedimientos de supresión segura antes del cierre de la cuenta
Estos requisitos pertenecen al inicio del ciclo de vida del proveedor. No espere a la terminación para preguntar si los datos pueden exportarse. No espere al cierre de la cuenta para preguntar si existen evidencias de supresión.
Una prueba práctica de salida de la nube conforme a DORA debe incluir:
- Exportar un conjunto de datos representativo en el formato acordado.
- Validar completitud, integridad, marcas temporales, metadatos y controles de acceso.
- Importar el conjunto de datos en un entorno de preproducción o en una herramienta alternativa.
- Confirmar la gestión de claves criptográficas y la rotación de secretos.
- Confirmar la exportación de registros y la conservación de la pista de auditoría.
- Documentar los procedimientos de supresión del proveedor, incluida la conservación de copias de seguridad y la certificación de supresión.
- Registrar incidencias, acciones de remediación, responsables y fechas límite.
- Actualizar la evaluación de riesgos del proveedor, la Declaración de Aplicabilidad y el plan de salida.
La portabilidad no es una promesa comercial. Es una capacidad probada.
Un sprint de una semana para un plan de salida de DORA preparado para auditoría
Considere una entidad de pago que utiliza un proveedor SaaS de analítica antifraude. El proveedor ingiere datos de transacciones, identificadores de clientes, datos de telemetría de dispositivos, señales de comportamiento, reglas de fraude, resultados de scoring y notas de casos. El servicio da soporte a un proceso crítico de detección de fraude. La entidad también utiliza un almacén de datos en la nube para conservar los resultados analíticos exportados.
El CISO quiere una estrategia de salida para proveedores terceros de servicios TIC conforme a DORA que pueda superar la auditoría interna y la revisión supervisora. Un sprint de una semana puede exponer las deficiencias y construir la cadena de evidencias.
Día 1: clasificar al proveedor y definir el escenario de salida
Utilizando Zenith Blueprint, la fase Controls in Action, Step 23, Action Items for Controls 5.19 to 5.37, el equipo comienza revisando y clasificando la cartera de proveedores:
Compile una lista completa de proveedores y prestadores de servicios actuales (5.19) y clasifíquelos según su acceso a sistemas, datos o control operativo. Para cada proveedor clasificado, verifique que las expectativas de seguridad estén claramente incorporadas en los contratos (5.20), incluidas la confidencialidad, el acceso, la notificación de incidentes y las obligaciones de cumplimiento.
El proveedor se clasifica como crítico porque da soporte a una función crítica o importante, trata datos operativos sensibles y afecta a los resultados de monitorización de transacciones.
El equipo define tres desencadenantes de salida:
- Insolvencia del proveedor o discontinuación del servicio.
- Brecha de seguridad material o pérdida de confianza.
- Migración estratégica para reducir el riesgo de concentración.
Día 2: construir el inventario de requisitos y el registro de riesgos
El equipo crea un inventario único de requisitos que cubre el riesgo de terceros de TIC de DORA, los controles de proveedores y nube de ISO/IEC 27001:2022, las obligaciones del RGPD de la UE para los datos personales, los compromisos contractuales con clientes y el apetito de riesgo interno.
Con arreglo al RGPD de la UE, la entidad confirma si los identificadores de transacción, los identificadores de dispositivo, las señales de ubicación y la analítica del comportamiento se refieren a personas identificadas o identificables. Los principios del artículo 5 del RGPD de la UE, incluida la integridad, confidencialidad, limitación del plazo de conservación y responsabilidad proactiva, pasan a formar parte del requisito de evidencias de salida. Si la salida implica una transferencia a un nuevo proveedor, deben documentarse la base jurídica, la finalidad, la minimización, la conservación, las condiciones del encargado del tratamiento y las salvaguardas.
El registro de riesgos incluye lo siguiente:
| Elemento de riesgo | Ejemplo de entrada |
|---|---|
| Declaración de riesgo | Incapacidad para salir del proveedor de analítica antifraude dentro de la tolerancia al impacto |
| Consecuencia | Retraso en la detección de fraude, pérdida financiera, incumplimiento regulatorio, perjuicio al cliente |
| Probabilidad | Media, basada en la concentración del proveedor y formatos propietarios |
| Propietario del riesgo | Responsable de Tecnología de Delitos Financieros |
| Tratamiento | Modificación contractual, prueba de exportación, evaluación de proveedor alternativo, verificación de copias de seguridad, prueba del runbook |
| Aprobación del riesgo residual | Aprobación del CRO tras evidencias de prueba y revisión de remediación |
Día 3: corregir deficiencias contractuales
Legal y Compras comparan el contrato con las cláusulas de proveedores de Clarysec. Añaden asistencia para la transición, continuidad del servicio durante un periodo de transición definido, acceso a auditoría y evidencias, notificación de subcontratistas, formato de exportación de datos, certificación de supresión segura, cooperación ante incidentes y compromisos de tiempo de recuperación.
La Business Continuity Policy and Disaster Recovery Policy Política de Continuidad del Negocio y Recuperación ante Desastres, sección «Requisitos de implementación de la política», cláusula 6.5.1, establece:
Los contratos con proveedores críticos deben incluir obligaciones de continuidad y compromisos de tiempo de recuperación.
Para pymes, la Business Continuity Policy and Disaster Recovery Policy-sme Política de Continuidad del Negocio y Recuperación ante Desastres - Pyme, sección «Tratamiento de riesgos y excepciones», cláusula 7.2.1.4, exige a los equipos:
documentar planes temporales de sustitución de proveedores o socios
Esa cláusula convierte «migraremos» en una alternativa ejecutable: qué proveedor, qué solución alternativa interna, qué proceso manual, qué extracto de datos, qué responsable y qué vía de aprobación.
Día 4: probar la portabilidad de datos y la capacidad de recuperación de las copias de seguridad
El equipo tecnológico exporta reglas de fraude, datos de casos, resultados de scoring de transacciones, registros, configuración, documentación de interfaces de programación de aplicaciones y listas de usuarios activos. Prueban si los datos pueden restaurarse o reutilizarse en un entorno controlado.
La Backup and Restore Policy-sme Política de Copias de Seguridad y Restauración - Pyme, sección «Requisitos de gobernanza», cláusula 5.3.3, exige:
Las pruebas de restauración se realizan al menos trimestralmente, y los resultados se documentan para verificar la capacidad de recuperación
La Backup and Restore Policy empresarial Política de Copias de Seguridad y Restauración, sección «Aplicación y cumplimiento», cláusula 8.3.1, añade:
Auditar periódicamente los registros de copias de seguridad, los ajustes de configuración y los resultados de las pruebas
En Zenith Blueprint, la fase Controls in Action, Step 19, Control 8.13, Clarysec advierte por qué esto importa:
Las pruebas de restauración son donde la mayoría de las organizaciones fallan. Una copia de seguridad que no puede restaurarse a tiempo, o que no puede restaurarse en absoluto, es un pasivo, no un activo. Programe simulacros periódicos de restauración, aunque sean parciales, y documente el resultado.
El equipo descubre que las notas de casos exportadas no incluyen archivos adjuntos y que los límites de tasa de las interfaces de programación de aplicaciones hacen que una exportación completa sea demasiado lenta para el objetivo de recuperación definido. La incidencia se registra, se asigna y se remedia mediante una adenda contractual y un rediseño técnico de la exportación.
Día 5: ejecutar el ejercicio de simulación de salida y revisar las evidencias
El equipo realiza un ejercicio de simulación: el proveedor anuncia la terminación en 90 días tras un incidente grave. Operaciones debe continuar la monitorización de fraude mientras se migran los datos.
En Zenith Blueprint, la fase Controls in Action, Step 23, Control 5.30, Clarysec explica el estándar de prueba:
La preparación de las TIC comienza mucho antes de que ocurra una interrupción. Implica identificar sistemas críticos, comprender sus interdependencias y mapearlos con procesos de negocio.
La misma sección añade:
Los Objetivos de Tiempo de Recuperación (RTO) y los Objetivos de Punto de Recuperación (RPO) definidos en el Plan de Continuidad del Negocio (BCP) deben reflejarse en las configuraciones técnicas, los contratos y el diseño de la infraestructura.
El paquete de evidencias incluye clasificación del proveedor, evaluación de riesgos, cláusulas contractuales, runbook de salida, resultados de exportación de datos, evidencias de restauración de copias de seguridad, procedimiento de supresión, evaluación de proveedor alternativo, actas del ejercicio de simulación, registro de remediación, aprobación de la dirección y decisión sobre riesgo residual.
El CISO ya puede responder a la pregunta del consejo de administración con evidencias, no con optimismo.
Cumplimiento transversal: un plan de salida, múltiples enfoques de auditoría
Una estrategia de salida de DORA sólida reduce el trabajo duplicado de cumplimiento en ISO/IEC 27001:2022, NIS2, el RGPD de la UE, NIST y las expectativas de gobernanza de COBIT 2019.
| Marco o regulación | Qué solicita en términos de planificación de salida | Evidencia que Clarysec recomienda |
|---|---|---|
| DORA | Mantener estrategias de salida para servicios TIC críticos o importantes, gestionar el riesgo de terceros, probar la resiliencia, documentar contratos y dependencias | Registro de proveedores, clasificación de criticidad, cláusulas contractuales, prueba de salida, plan de transición, derechos de auditoría, evaluación del riesgo de concentración |
| NIS2 | Para entidades relevantes, gestionar la seguridad de la cadena de suministro, continuidad del negocio, copias de seguridad, recuperación ante desastres, gestión de crisis, gestión de incidentes y responsabilidad de gobernanza | Evaluación de riesgos de proveedores, plan de continuidad, playbooks de incidentes, aprobación de la dirección, acciones correctivas |
| RGPD de la UE | Proteger los datos personales durante la transferencia, devolución, supresión, migración y conservación con responsabilidad proactiva y medidas técnicas y organizativas adecuadas | Mapa de datos, condiciones del encargado del tratamiento, evidencias de exportación, certificación de supresión, reglas de conservación, alineación de la gestión de brechas |
| ISO/IEC 27001:2022 | Operar controles de proveedores, nube, continuidad, incidentes, auditoría, supervisión y mejora dentro del SGSI | Declaración de Aplicabilidad, Plan de Tratamiento de Riesgos, registro de auditoría interna, revisión por la dirección, procedimientos documentados |
| NIST Cybersecurity Framework 2.0 | Gobernar dependencias externas, identificar proveedores, proteger servicios, responder a interrupciones y recuperar operaciones | Inventario de dependencias, registros de riesgos de proveedores, controles de protección, procedimiento de respuesta, prueba de recuperación, lecciones aprendidas |
| COBIT 2019 | Demostrar gobernanza sobre aprovisionamiento, desempeño de proveedores, riesgo, continuidad del servicio, aseguramiento y cumplimiento | Decisiones de gobernanza, titularidad, KPI, supervisión de proveedores, evidencias de continuidad, informes de aseguramiento |
Lo importante no es que un marco sustituya a otro. El valor está en que un SGSI bien construido permite a la organización generar evidencias una vez y reutilizarlas de forma inteligente.
Zenith Controls de Clarysec ayuda a los equipos a prepararse para estos enfoques de auditoría conectando los controles ISO/IEC 27001:2022 con evidencias de auditoría y expectativas entre marcos.
| Enfoque del auditor | Pregunta de auditoría probable | Evidencia que normalmente satisface la pregunta |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿La salida de proveedores y nube está controlada dentro del SGSI, la evaluación de riesgos, la SoA y el programa de auditoría interna? | Alcance del SGSI, evaluación de riesgos, SoA, procedimiento de proveedores, procedimiento de salida de nube, resultados de auditoría interna, acciones de revisión por la dirección |
| Supervisor de DORA o auditoría interna de DORA | ¿Puede salir de un proveedor crítico de TIC sin interrupciones inaceptables, pérdida de datos o incumplimiento regulatorio? | Evaluación de criticidad, registro de proveedores de DORA, estrategia de salida, cláusulas contractuales, prueba de transición, evaluación de concentración, registro de remediación |
| Evaluador orientado a NIST | ¿Ha gobernado e identificado dependencias externas, protegido servicios críticos y probado capacidades de respuesta y recuperación? | Inventario de dependencias, controles de acceso, monitorización, escalado de incidentes, prueba de recuperación, lecciones aprendidas |
| Auditor COBIT 2019 o ISACA | ¿La salida de proveedores está gobernada, tiene propietario, se mide y se asegura mediante objetivos de gestión como APO10 Managed Vendors y DSS04 Managed Continuity? | RACI, aprobación de la dirección, KPI, revisión del desempeño de proveedores, evidencias de aseguramiento, seguimiento de incidencias |
| Auditor de privacidad | ¿Pueden los datos personales devolverse, migrarse, restringirse, borrarse o conservarse de forma segura conforme a las obligaciones del RGPD de la UE? | Registro de actividades de tratamiento, cláusulas del encargado del tratamiento, evidencias de exportación, certificado de supresión, justificación de conservación, flujo de gestión de brechas |
Un fallo de auditoría habitual es la fragmentación de evidencias. El responsable del proveedor tiene el contrato. TI tiene los registros de copias de seguridad. Legal tiene el contrato de encargo de tratamiento. Riesgos tiene la evaluación. Cumplimiento tiene el mapeo regulatorio. Nadie tiene la historia completa.
Clarysec resuelve esto diseñando el paquete de evidencias alrededor del escenario de salida. Cada documento responde a una pregunta de auditoría: qué servicio se está abandonando, por qué es crítico, qué datos y sistemas se ven afectados, quién es el propietario del riesgo, qué derechos contractuales hacen posible la salida, qué mecanismos técnicos hacen posible la migración, qué acuerdos de continuidad mantienen operativa la organización, qué prueba demuestra que el plan funciona, qué incidencias se remediaron y quién aprobó el riesgo residual.
Lista de verificación de Clarysec para estrategias de salida de DORA
Utilice esta lista de verificación para convertir una estrategia de salida para proveedores terceros de servicios TIC conforme a DORA de un documento en un conjunto de controles auditable.
| Área de control | Expectativa mínima | Evidencia a conservar |
|---|---|---|
| Clasificación de proveedores | Identificar si el proveedor da soporte a funciones críticas o importantes | Registro de proveedores, decisión de criticidad, mapa de dependencias |
| Exigibilidad contractual | Incluir asistencia para la transición, exportación de datos, supresión, auditoría, cooperación ante incidentes y obligaciones de continuidad | Cláusulas contractuales, adendas, revisión jurídica |
| Portabilidad en la nube | Confirmar la capacidad de exportación antes de la incorporación y periódicamente durante la operación | Resultados de pruebas de exportación, documentación del formato de datos, notas de migración |
| Protección de datos | Abordar la devolución, supresión, conservación, transferencia y obligaciones del encargado del tratamiento respecto de datos personales | Mapa de datos, DPA, certificación de supresión, decisión de conservación |
| Copia de seguridad y restauración | Probar la capacidad de recuperación frente al RTO y RPO | Registros de restauración, informe de prueba, registro de remediación |
| Planificación de sustitución | Definir proveedor alternativo, solución manual o proceso interno | Plan de sustitución, actas del ejercicio de simulación, lista de responsables |
| Gobernanza | Asignar propietario del riesgo y aprobación de la dirección | Registro de riesgos, aceptación del riesgo residual, actas de revisión por la dirección |
| Preparación para auditorías | Vincular políticas, controles, contratos, pruebas y acciones correctivas | Índice del paquete de evidencias, informe de auditoría interna, herramienta de seguimiento de incidencias |
Convertir la planificación de salida en un control de resiliencia preparado para el consejo
Si su estrategia de salida de DORA es solo una cláusula contractual, no está preparada. Si su copia de seguridad nunca se ha restaurado, no está preparada. Si su proveedor de nube puede exportar datos pero nadie ha validado su completitud, no está preparada. Si su consejo de administración no puede ver la decisión sobre riesgo residual, no está preparada.
Clarysec ayuda a CISO, responsables de cumplimiento, auditores y propietarios de negocio a desarrollar estrategias de salida para proveedores terceros de servicios TIC conforme a DORA que sean prácticas, proporcionales y preparadas para auditoría. Combinamos Zenith Blueprint Zenith Blueprint para la secuenciación de implementación, Zenith Controls Zenith Controls para el mapeo de cumplimiento transversal, y plantillas de políticas como la Supplier Dependency Risk Management Policy Política de Gestión del Riesgo de Dependencia de Proveedores, Cloud Usage Policy - SME Política de Uso de la Nube - Pyme, Third-Party and Supplier Security Policy - SME Política de Seguridad de Terceros y Proveedores - Pyme y Business Continuity Policy and Disaster Recovery Policy Política de Continuidad del Negocio y Recuperación ante Desastres para crear una cadena completa de control a evidencia.
Su siguiente paso es sencillo y de alto valor: seleccione esta semana un proveedor crítico de TIC. Clasifíquelo, revise su contrato, pruebe una exportación de datos, verifique una restauración, documente un plan de sustitución y cree un paquete de evidencias.
Ese único ejercicio mostrará si su estrategia de salida de DORA es una verdadera capacidad de resiliencia o solo un documento esperando fallar en auditoría.
Frequently Asked Questions
About the Author
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
