1. Definir la decisión de salida
Una junta no aprueba la salida de la TSA simplemente porque un contrato llega a su fin previsto. Aprueba la transferencia de la responsabilidad operativa de un proveedor temporal a una capacidad controlada por el destinatario. La decisión requiere evidencia de que la empresa puede continuar atendiendo a los clientes, recaudando efectivo, cumpliendo con las obligaciones regulatorias, protegiendo los datos y produciendo información financiera confiable una vez finalizado el servicio.
Por lo tanto, cada servicio de la TSA necesita un resultado de destinatario definido. La salida de nómina significa que los empleados reciben su pago de forma precisa y puntual desde el sistema autorizado del destinatario. La salida financiera significa que se concilian los saldos iniciales, los datos maestros, las interfaces, los controles y los informes. La salida de la plataforma del cliente significa pedidos, derechos, facturación y trabajo de soporte sin una dependencia no aprobada del proveedor. Un despliegue técnico sin el resultado operativo completo está incompleto.
La junta debería gobernar una cartera de decisiones de salida. Los servicios difieren en importancia, arquitectura, sensibilidad de los datos, complejidad de los cambios y opciones de respaldo. Un servicio de informes de bajo riesgo puede salir mediante una simple transferencia. Una identidad, fabricación, tesorería o servicio al cliente estrechamente integrados pueden requerir una ejecución dual controlada, capacidad de recuperación independiente y una ventana de transición aprobada por la junta.
La unidad de aprobación debe ser lo suficientemente pequeña para exponer el riesgo y lo suficientemente grande para representar un servicio completo. Aprobar una solicitud por sí solo puede omitir trabajo manual, fuentes de datos y controles. Aprobar una función completa a la vez puede ocultar una dependencia insegura entre muchas actividades completas. Los resultados del servicio proporcionan un nivel medio práctico para la gobernanza.
La decisión de salida debe indicar el servicio, el propietario, la tolerancia al impacto, la evidencia de aceptación, la dependencia residual, la contingencia, el período máximo de reversión y las consecuencias financieras. Esto crea un historial que puede resistir el escrutinio operativo, de auditoría y de los inversores.
2. Comprenda lo que una TSA resuelve y lo que no resuelve
Una TSA asigna responsabilidades temporales después de la finalización legal. Puede preservar el acceso a personas, sistemas, instalaciones, procesamiento de datos y rutinas operativas mientras el destinatario construye o consigue reemplazos. También puede definir niveles de servicio, precios, control de cambios, manejo de incidentes, responsabilidad y terminación.
El acuerdo no crea la capacidad del estado final del destinatario. Puede conservar una configuración heredada que fue diseñada para un grupo integrado. Puede excluir proyectos, mejoras, nuevos mercados, cambios de seguridad o trabajos regulatorios. Los niveles de servicio pueden reflejar esfuerzos razonables en lugar de un estándar comercial de servicio gestionado. El personal del proveedor puede priorizar el negocio retenido cuando los recursos sean limitados.
El calendario contractual puede ocultar un acoplamiento técnico. Un servicio denominado puede depender de varias aplicaciones, interfaces, bases de datos, licencias, cuentas y equipos. Un proveedor puede necesitar acceso a los datos del destinatario después de la aparente salida del servicio porque otro servicio permanece activo. Un sistema receptor puede técnicamente funcionar mientras su proceso de linaje, conciliación o recuperación de datos permanece incompleto.
Por tanto, el programa operativo debe descomponer la TSA en capacidades y dependencias. La expiración del contrato sigue siendo una limitación importante, pero la preparación se demuestra a través del modelo operativo del receptor y la evidencia probada.
Ambas partes deben mantener una interpretación del calendario. A menudo surgen disputas cuando un destinatario considera que una actividad está incluida y el proveedor la considera un trabajo de proyecto o un servicio omitido. Un catálogo controlado, un registro de decisiones y un proceso de cambio reducen la ambigüedad antes de que afecte la continuidad. Los desacuerdos comerciales deben intensificarse sin retrasar la protección operativa urgente.
3. Cree un mapa de servicios y dependencias.
La línea base de salida debe enumerar cada servicio, destinatario, proveedor, propietario del servicio, proceso de negocio, aplicación, interfaz, conjunto de datos, dominio de identidad, instalación, proveedor, control y jurisdicción. El mapa debe incluir los servicios prestados en ambas direcciones y el apoyo informal que puede no aparecer en el cronograma firmado.
El mapeo debe comenzar con importantes servicios comerciales y resultados para los clientes. La FCA exige que las empresas incluidas en el alcance identifiquen las personas, los procesos, la tecnología, las instalaciones y la información necesarios para brindar servicios comerciales importantes, incluidos terceros relevantes. Sus observaciones de marzo de 2026 enfatizan el mapeo dinámico, la gobernanza y las medidas de impacto cuantitativo junto con las tolerancias basadas en el tiempo. [1] Estos principios proporcionan una disciplina de diseño útil incluso cuando las partes de la transacción están fuera del perímetro de la FCA.
Las dependencias deben ser direccionales. Una plataforma de facturación puede depender de los datos maestros del cliente de un sistema, los precios de otro, los servicios de identidad del proveedor y una interfaz bancaria controlada por el destinatario. La secuencia de salida debe respetar esas direcciones. Retirar la identidad antes de migrar las aplicaciones dependientes puede generar un error inmediato.
Cada dependencia debe registrar la fuente de evidencia y su confianza. Los documentos de arquitectura pueden estar obsoletos. Los análisis de configuración, los registros de acceso, la supervisión de la interfaz, los registros de contratos y los flujos de datos conciliados proporcionan pruebas más sólidas. Las dependencias desconocidas deben tratarse como riesgos del programa con acciones de descubrimiento y propietarios.
El mapa también debe distinguir las dependencias duras y blandas. Una dependencia estricta impide la operación del servicio, como la autenticación o una fuente de datos requerida. Una dependencia suave reduce la eficiencia o la seguridad, como una herramienta de informes que puede ser reemplazada temporalmente por un proceso manual controlado. Esta distinción respalda las decisiones de secuencia, contingencia y financiación.
| Campo | Registro requerido | Evidencia | Salir de uso | señal de falla |
|---|---|---|---|---|
| Resultado del servicio | Resultado del cliente o control entregado | Mapa de procesos y aprobación del propietario. | Define la aceptación | Actividad enumerada sin resultado |
| Dependencia | Sistema, datos, persona, proveedor o instalación. | Escanear, registrar, contratar o entrevistar | Determina la secuencia | Componente compartido no documentado |
| Tolerancia al impacto | Máxima interrupción y pérdida tolerable | Aprobación de riesgos y prueba de escenarios. | Establece límites de transición | Solo etiqueta de gravedad genérica |
| Capacidad de estado final | Reemplazo contratado o propiedad del destinatario | Diseño, registro de construcción y contrato. | Demuestra independencia | TSA copiada sin rediseño |
| Evidencia de salida | Resultado de prueba, conciliación y control. | Paquete de evidencia firmada | Apoya la aprobación | Estado del proyecto utilizado como prueba |
| Retroceder | Reversión, solución manual o extensión | Plan de recuperación probado | Límites negativos | La fecha de vencimiento es la única respuesta. |
Marco original. El registro de servicios debe conciliar el acuerdo firmado, el mapa operativo y el inventario de tecnología.
4. Diseñe primero el modelo operativo objetivo
El diseño de salida debe comenzar con el modelo operativo requerido después de la TSA. El destinatario debe decidir qué capacidades poseerá, subcontratará, compartirá en virtud de un acuerdo comercial duradero o discontinuará. Esta decisión controla la arquitectura, las personas, los contratos, los datos y los costos.
Una copia de la organización del proveedor puede ser excesiva o incompleta. El negocio separado puede tener diferentes productos, jurisdicciones, clientes y obligaciones de presentación de informes. Puede elegir una plataforma en la nube en lugar de un centro de datos replicado, un servicio de seguridad administrado en lugar de un equipo interno u operaciones regionales en lugar de un centro grupal. Estas opciones cambian tanto la ruta migratoria como el entorno de control.
El modelo objetivo debe identificar ejecutivos responsables, propietarios de procesos, propietarios de sistemas, propietarios de datos y propietarios de controles. La responsabilidad de un servicio no puede recaer en una oficina de proyecto después de su salida. La organización duradera necesita presupuesto, competencia, acceso y derechos de escalamiento.
El modelo debe incluir operaciones normales, volúmenes máximos, incidentes, fin de mes, fin de año, informes regulatorios y recuperación ante desastres. Un reemplazo que funciona durante un período de prueba tranquilo puede fallar al final del trimestre o durante un incidente con un cliente. Por lo tanto, la capacidad y la resiliencia pertenecen a la línea base del diseño.
La autoridad de diseño debe permanecer conectada a la tesis de la transacción. Una separación destinada a crear un negocio más centrado y ágil puede verse socavada si el destinatario hereda todos los procesos heredados. Por el contrario, una simplificación agresiva puede eliminar controles o capacidades que los inversores suponían que existirían. Las opciones operativas deben conciliarse con el argumento financiero y la estrategia revelada.
5. Traducir el contrato a una arquitectura de salida.
La CST debería convertirse en una hoja de control servicio por servicio. El alcance, las exclusiones, los volúmenes, los niveles de servicio, los cargos, la duración, los derechos de extensión, las reglas de cambio, las obligaciones de incidentes, los derechos de auditoría, los términos de datos, los derechos de propiedad intelectual y la asistencia de terminación deben estar visibles al lado del plan operativo.
Los acuerdos públicos recientes muestran la variedad de estructuras. La TSA modificada de Kenvue con Johnson & Johnson describe un plazo de período de servicio general de veinticuatro meses, con una extensión definida en caso de que las aprobaciones regulatorias retrasen la transición. [2] La TSA de Jacobs y Amentum presentada en 2024 incluye una tarifa administrativa y cronogramas de servicios formales. [3] Western Digital reveló que el soporte de transición para Sandisk cubrió doce áreas funcionales por períodos de hasta dieciocho meses, con mecanismos para adiciones, extensiones, terminación, gobernanza y resolución de disputas. [4] Estos documentos son evidencia de diseño contractual específica de la transacción, no puntos de referencia universales.
La hoja de control debe identificar la última fecha de notificación, el precio de la prórroga, el proceso por servicios omitidos y las consecuencias de la salida parcial. Un programa que descubre un requisito de extensión después de la fecha límite de notificación pierde influencia de negociación.
Las obligaciones de nivel de servicio necesitan definiciones mensurables. Términos como asistencia materialmente consistente, razonable o curso normal pueden ser estándares contractuales apropiados pero proporcionan métricas débiles del programa. El plan operativo debe traducirlos en volúmenes, tiempos de respuesta, objetivos de recuperación, retención de evidencia y umbrales de escalamiento sin que impliquen derechos que el acuerdo no otorga.
Los hitos del contrato y la construcción deben estar vinculados. La selección de proveedores, la transferencia de licencia, la extracción de datos, las pruebas y la transición deben finalizar antes de la finalización del contrato o de una extensión aprobada. Los equipos legales deben recibir evidencia del progreso técnico con suficiente antelación para ejercer los derechos.
6. Trate la separación de datos como una transacción controlada
La separación de datos es más que el movimiento de archivos. Las partes deben determinar qué datos pertenecen al destinatario, qué puede conservar el proveedor, qué debe restringirse, qué registros se comparten y cómo se preservará el contexto histórico. El resultado debería respaldar las operaciones, los derechos, la auditoría, los litigios, los impuestos, la privacidad y las obligaciones regulatorias.
El mapa de datos debe cubrir fuente, propietario, finalidad, base jurídica, jurisdicción, clasificación, retención, calidad, linaje, transformación y destino. Se deben distinguir registros estructurados, documentos, mensajes, logs, modelos, copias de seguridad y datos derivados. Las tablas compartidas y los lagos de datos a menudo requieren una separación a nivel de fila o de atributo en lugar de una simple copia de la base de datos.
La Oficina del Comisionado de Información del Reino Unido afirma que el intercambio de datos después de una fusión o adquisición debe formar parte de la diligencia debida, que se aplican los principios y la documentación de protección de datos y que se necesita asesoramiento técnico cuando diferentes sistemas crean riesgos de pérdida, corrupción o degradación. [5] Esos problemas también surgen en las escisiones porque cambian las responsabilidades de control y procesamiento.
La evidencia de migración debe incluir totales de extracción, reglas de transformación, registros de rechazo, totales de control, verificación de muestras, conciliación con registros financieros u operativos, validación de seguridad y aceptación del propietario de la empresa. La eliminación o conservación por parte del proveedor deberá acreditarse por separado. Una importación exitosa no prueba una separación completa o legal.
Los datos históricos pueden crear un equilibrio difícil entre la utilidad operativa y la carga migratoria. El destinatario puede necesitar un historial detallado de servicio al cliente, garantía, rendimiento del modelo, impuestos o litigios. Mover cada registro puede aumentar el costo, la exposición a la privacidad y las pruebas. Una solución documentada de acceso a archivos puede ser adecuada cuando la propiedad, el acceso, la retención, el tiempo de recuperación y la eventual disposición estén claros.
7. Separe la identidad y el acceso sin crear puntos ciegos
La identidad es una dependencia crítica porque controla los usuarios, las cuentas de servicio, el acceso privilegiado, las aplicaciones y los datos. El destinatario necesita una autoridad de identidad independiente, un proceso de entrada, salida y salida, política de autenticación, control de acceso privilegiado y procedimiento de acceso de emergencia antes de que salgan los servicios dependientes.
La arquitectura de confianza cero del NIST elimina la confianza implícita basada en la ubicación de la red o la propiedad de los activos y requiere autenticación y autorización antes de acceder a los recursos empresariales. [6] En una separación, esto significa que el alcance de la red heredado o las credenciales principales no deberían convertirse en el modelo de acceso permanente. Las identidades de usuario, dispositivo, servicio y aplicación necesitan políticas explícitas.
La migración de identidad debe distinguir a los usuarios de la fuerza laboral, clientes, proveedores, robots, interfaces, bases de datos, certificados, claves y clientes API. Las cuentas de servicio suelen pasarse por alto porque no aparecen en las listas de empleados. Los certificados caducados o las claves no rotadas pueden provocar un fallo retrasado después de una transición aparentemente exitosa.
Las partes deberían reducir el acceso permanente entre empresas a medida que los servicios salen. Los registros de acceso deben monitorearse durante la transición, y el acceso residual del proveedor debe tener un propósito, vencimiento y propietario determinados. El acceso contra rotura de cristales debe probarse y revisarse de forma independiente.
El acceso privilegiado necesita una gobernanza separada porque los administradores pueden cambiar configuraciones, extraer datos o desactivar controles. El destinatario debe establecer su propia bóveda de acceso privilegiado, flujo de trabajo de aprobación, registro de sesiones y proceso de emergencia. Las credenciales de administrador compartidas deben retirarse. Cuando el personal del proveedor retiene el acceso, la autoridad contractual y el cumplimiento técnico deben estar de acuerdo.
8. Secuencia de aplicaciones, infraestructura e interfaces.
Las aplicaciones deben agruparse por servicio empresarial y cadena de dependencia en lugar de migrarse como una lista no relacionada. El programa debe identificar sistemas de registro, sistemas de participación, análisis, integración, infraestructura, monitoreo, respaldo y recuperación.
Se encuentran disponibles cuatro amplios patrones de salida. El destinatario puede clonar una instancia segregada, migrar a una plataforma existente, implementar una nueva plataforma o conservar un servicio duradero de terceros. Cada patrón tiene diferentes implicaciones en materia de datos, licencia, control y sincronización. Un clon puede ser rápido pero preservar la deuda técnica. Una nueva plataforma puede mejorar el estado final pero aumentar el riesgo de implementación.
Las interfaces requieren una disciplina particular. Un sistema puede pasar pruebas independientes y fallar cuando se introducen tiempos reales ascendentes, calidad de datos o reconocimientos descendentes. El inventario de interfaces debe incluir dirección, frecuencia, protocolo, esquema, autenticación, manejo de errores, volumen y propietario del negocio.
Las decisiones de infraestructura deben abordar redes, cuentas de nube, dominios, dispositivos, monitoreo, programación por lotes, almacenamiento, respaldo y recuperación. El destinatario debe tener capacidad de observación antes de la transición para poder diagnosticar la falla sin depender del proveedor.
El desmantelamiento debería planificarse además de la migración. Las interfaces duplicadas, las cuentas inactivas, las rutas de red temporales y los entornos abandonados aumentan los costos y los riesgos. Cada paquete de trabajo de salida debe indicar qué retirará el proveedor, qué retendrá el destinatario y cómo ambas partes confirmarán que no se perderá ningún registro o servicio requerido.
Marco original. La secuencia de salida debe seguir los resultados del servicio y las dependencias direccionales.
9. Incorporar la ciberseguridad al perímetro de separación
La separación cambia la superficie de ataque. Se introducen nuevos dominios, redes, cuentas en la nube, conexiones remotas, transferencias de datos y proveedores mientras los equipos están bajo presión de entrega. Las excepciones temporales pueden convertirse en vulnerabilidades persistentes si no se registran y cierran.
NIST CSF 2.0 organiza los resultados del riesgo cibernético en torno a Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar. [7] El marco es útil para evaluar tanto el estado de transición como el estado final del receptor. Dentro del programa de separación se deben probar el inventario de activos, el control de acceso, la seguridad de los datos, la seguridad de la plataforma, el monitoreo, la respuesta y recuperación ante incidentes.
Los objetivos de desempeño intersectorial de CISA identifican una línea de base priorizada de prácticas para organizaciones e infraestructura crítica, incluida la protección de identidad, copias de seguridad y otros controles de alto impacto. [8] Un programa en vivo debe seleccionar controles apropiados para el sector, la amenaza y las obligaciones regulatorias en lugar de tratar una lista de verificación genérica como suficiente.
El destinatario necesita su propio comando de incidentes, listas de contactos, registro, detección, gestión de vulnerabilidades, copias de seguridad y recuperación. El proveedor y el destinatario también necesitan un protocolo de incidentes conjunto mientras la TSA permanece activa. El protocolo debe establecer derechos de decisión, preservación de evidencia, comunicaciones con el regulador y el cliente, costos y revisión posterior al incidente.
Las obligaciones de las empresas públicas pueden acortar el plazo de decisión. Las reglas cibernéticas de 2023 de la SEC requieren la divulgación de un incidente importante generalmente dentro de los cuatro días hábiles posteriores a que se determine la materialidad y información anual sobre la gestión, la estrategia y la gobernanza del riesgo cibernético. [12] La gobernanza de la separación debe enviar los hechos rápidamente a los equipos legales y de divulgación sin permitir que las consideraciones de divulgación interfieran con la contención y la recuperación.
10. Conecte la salida con la privacidad, los registros y la retención legal.
Los datos personales, la información confidencial, los registros legales y la propiedad intelectual requieren un manejo explícito. El acuerdo de separación, la TSA, los términos de procesamiento de datos y la ley local deben alinearse en cuanto a roles de controlador y procesador, instrucciones, subprocesadores, ubicaciones, notificación de incidentes, retención, auditoría y eliminación.
El equipo de datos no debe asumir que todos los registros históricos se pueden copiar. La limitación de la finalidad, la confidencialidad, las restricciones contractuales, el secreto bancario, la información sanitaria y los controles de exportación pueden limitar la transferencia. Algunos registros pueden necesitar redacción, segregación, seudonimización o acceso controlado.
Los datos de investigación y retención legal requieren continuidad. Las partes deben preservar la capacidad de búsqueda, la cadena de custodia y la propiedad responsable. Eliminar las copias del proveedor antes de confirmar que el destinatario está completa puede perjudicar las obligaciones; La retención indefinida crea exposición a la privacidad y la confidencialidad.
La evidencia de salida debe incluir un registro de transferencia de datos, excepciones no resueltas, cronograma de retención, certificado de eliminación del proveedor cuando corresponda y aprobación del propietario de la empresa. Estos registros deben permanecer accesibles después del cierre del programa.
11. Reconstruir la capacidad financiera y de control
La separación financiera afecta a los maestros de clientes y proveedores, plan de cuentas, cuentas bancarias, tesorería, impuestos, nómina, activos fijos, consolidación, planificación, informes y control interno. La migración técnica debe conciliarse con los saldos iniciales y las poblaciones de transacciones.
El destinatario necesita un calendario cercano y una matriz de control para los primeros períodos de informes independientes. Las interfaces entre los sistemas operativos y financieros deben probarse con volúmenes, monedas, impuestos, eventos de corte, créditos y excepciones representativos. Las soluciones manuales deben tener propietarios, límites de capacidad y controles de revisión.
La NIIF 5 requiere la presentación separada de ciertos activos y pasivos clasificados como mantenidos para la venta y los resultados de operaciones discontinuadas. [9] La presentación de informes aplicables dependerá de la transacción y la jurisdicción, pero el plan de separación operativa debe respaldar el perímetro contable y la trazabilidad de la información.
Las pruebas de control deben cubrir el acceso, la segregación de funciones, los cambios en los datos maestros, la aprobación del diario, las conciliaciones, los ingresos, las compras, la nómina, el efectivo y los informes. Una prueba de tecnología limpia sin una conciliación financiera no puede respaldar la salida financiera.
12. Proteger la continuidad operativa
La continuidad operativa debe expresarse a través de los resultados del servicio y las tolerancias de impacto. Un objetivo de recuperación basado en el tiempo es útil, pero es posible que no capture los retrasos en las transacciones, los daños a los clientes, la seguridad, la integridad del mercado, las pérdidas financieras o los plazos regulatorios.
La FCA distingue la tolerancia al impacto del tiempo de recuperación y fomenta métricas adicionales como categorías de clientes, valores de transacción, volúmenes y pérdidas estimadas. [10] Un programa de separación puede aplicar la misma lógica para definir la interrupción máxima, el máximo de transacciones no conciliadas, la pérdida máxima de datos, la acumulación máxima de clientes y la duración máxima del procesamiento manual.
Las pruebas de escenarios deberían ser severas pero plausibles. Los ejemplos incluyen carga de datos fallida, interrupción de identidad, interfaz dañada, experto de proveedor no disponible, retraso del proveedor, incidente cibernético durante la transición, falla de fin de mes y reversión después de un procesamiento parcial. Las pruebas deben incluir a los tomadores de decisiones y a los comunicadores, no solo a los equipos técnicos.
La evidencia de continuidad debe mostrar que el destinatario puede permanecer dentro de las tolerancias aprobadas, recuperar el servicio y procesar el trabajo atrasado. Un sistema restaurado después de seis horas aún puede crear un daño inaceptable si se necesitan tres días para conciliar las transacciones perdidas.
| Dominio de la evidencia | Prueba mínima | Medida cuantitativa | propietario responsable | Bloqueador de salida |
|---|---|---|---|---|
| Proceso | Escenario de extremo a extremo completado | Tasa de éxito y liquidación de trabajos pendientes | Dueño de servicio comercial | El paso crítico carece de capacidad |
| Datos | Totales de población y control conciliados | Integridad, exactitud y registros rechazados. | Propietario de los datos | Variación material inexplicable |
| Tecnología | Capacidad, seguimiento y recuperación probados | Disponibilidad, latencia, recuperación y pérdida de datos. | Propietario de la tecnología | La recuperación supera la tolerancia |
| Control | Controles clave operados con evidencia | Excepciones y cierre de remediación | Propietario del control | El control financiero o regulatorio falla |
| Gente | Funciones dotadas de personal y acceso aprobado | Cobertura, formación y respuesta de escalamiento | ejecutivo funcional | Dependencia única y absoluta |
| Proveedor | Derechos de contrato, soporte y rescisión activos | Niveles de servicio y obligaciones no resueltas | Propietario comercial | Consentimiento o licencia requeridos ausentes |
Marco original. La evidencia debe ser proporcional a la criticidad y jurisdicción del servicio.
13. Derechos de licencia y proveedores seguros
El destinatario puede construir una plataforma técnicamente sólida y aún así no poder operarla porque los contratos, licencias o consentimientos permanecen con el proveedor. La diligencia del proveedor debe identificar la asignabilidad, los términos de cambio de control, las métricas de los usuarios, los derechos territoriales, los compromisos mínimos, los derechos de auditoría, los términos de los datos, el soporte y la terminación.
Los nuevos contratos deberían entrar en vigor antes de la transición y deberían cubrir tanto la implementación como el servicio en estado estable. Un proveedor puede aceptar soporte de producción pero excluir defectos de migración. El destinatario debe comprender si el proveedor tiene conocimientos de configuración y si se puede transferir la documentación.
La concentración comercial puede cambiar durante la separación. Un proveedor que anteriormente representaba una pequeña parte del gasto del grupo puede volverse fundamental para el destinatario. Los planes de diligencia financiera, resiliencia, seguridad, subcontratación y rescisión deben recalibrarse en función de la dependencia del destinatario. La firma del contrato no debe sustituir la incorporación y las pruebas operativas.
Las métricas de licencia deben probarse con el modelo de destino. Los usuarios, procesadores, transacciones, ingresos, dispositivos, entornos y afiliados designados pueden generar costos diferentes. Los entornos paralelos durante la migración pueden requerir licencias temporales que no aparecen en el presupuesto final.
Se debe evaluar el riesgo de salida y concentración de proveedores. DORA exige que las entidades financieras que utilizan servicios de TIC para funciones críticas o importantes mantengan planes de salida integrales, documentados, probados y revisados periódicamente que permitan la salida sin interrupción del negocio, deterioro regulatorio o detrimento de la continuidad y calidad del servicio. [11] El principio es directamente relevante para los proveedores sustitutos seleccionados durante una escisión.
14. Transferir conocimiento y autoridad de decisión.
La prestación de servicios depende del conocimiento tácito, el manejo de excepciones y la autoridad para tomar decisiones. La documentación por sí sola rara vez captura por qué se desvía un proceso, qué cliente necesita un tratamiento especial o cómo se recupera un sistema obsoleto.
El programa debe identificar roles críticos, expertos nombrados, derechos de decisión, ciclos recurrentes, defectos conocidos, contactos con proveedores y rutas de escalada. La transferencia de conocimientos debe utilizar la observación, la operación emparejada, el seguimiento inverso y la ejecución dirigida por el destinatario. La asistencia a una sesión de capacitación es evidencia débil; Un servicio exitoso dirigido al destinatario en condiciones realistas es más fuerte.
Es posible que se necesiten acuerdos de retención para el personal del proveedor y del destinatario. Su propósito, duración, hito y costo deben ser explícitos. La dependencia de un individuo debería desencadenar un plan de sucesión o de apoyo externo.
La autoridad de decisión debe transferirse antes de que se vaya la persona que históricamente la ejerció. El destinatario necesita políticas aprobadas, autoridades delegadas, mandatos bancarios, funciones del sistema y nombramientos regulatorios. Un equipo capaz sin autoridad no puede operar de forma independiente.
15. Defina las pruebas de salida antes de completar la compilación.
Las pruebas de aceptación deben diseñarse temprano porque dan forma a la arquitectura y la evidencia. El propietario del servicio debe definir qué debe ser cierto para la salida, los datos requeridos, el escenario, la tolerancia y el aprobador.
Las pruebas deben progresar desde los componentes hasta las interfaces, los procesos de un extremo a otro, el rendimiento, la seguridad, la recuperación y los ensayos operativos. Los datos representativos de producción deben utilizarse de forma legal y segura. Los entornos de prueba deben reflejar los volúmenes, la configuración y las dependencias con suficiente precisión para respaldar la conclusión.
Los defectos necesitan gravedad, propietario, fecha prevista y evidencia de nueva prueba. Una renuncia debe indicar el riesgo residual, la duración, el control compensatorio y la aprobación. Los defectos de alta gravedad no deberían desaparecer dentro de una tasa de aprobación promedio.
El paquete de evidencia final debe incluir trazabilidad de requisitos, resultados, conciliaciones, defectos, exenciones, capacidad, resiliencia, aprobación de acceso, procedimientos operativos, capacitación, preparación de proveedores y aceptación del propietario de la empresa. El porcentaje de finalización del proyecto no es prueba de aceptación.
16. Reducción y reducción del ingeniero
La transición convierte la capacidad probada en responsabilidad real. El runbook debe especificar la secuencia, los criterios de entrada, la congelación de datos, la extracción, la migración, la validación, la activación de la interfaz, las comprobaciones comerciales, las comunicaciones, los puntos de decisión, la reversión y la estructura de comando.
Cada paso necesita un operador designado, una duración esperada, evidencia y el último tiempo de finalización segura. Las dependencias deben ser visibles en un plan integrado. Los equipos deben ensayar el runbook y medir la duración real en lugar de depender de estimaciones.
La reversión debe ser técnica y operativamente posible. Si las transacciones se procesan en el nuevo entorno, regresar al proveedor puede requerir sincronización de datos y decisiones contables. Por lo tanto, el punto de reversión puede ocurrir antes de que se complete la prueba comercial completa. La junta debe comprender cuándo la decisión se vuelve irreversible.
La estabilización posterior a la transición debe incluir un mejor seguimiento, conciliación diaria, clasificación de problemas, presencia de proveedores y cobertura de decisiones de alto nivel. La salida se completa después de que el servicio funciona de manera confiable y la dependencia del proveedor se elimina o se limita formalmente.
Escenario original. Los recuentos de servicios y los plazos son totalmente hipotéticos.
17. Gobernar la cartera de salida
La gobernanza debe combinar perspectivas de transacciones, negocios, tecnología, riesgo y finanzas. La junta o el comité de transacciones delegadas aprueba el apetito de riesgo, la financiación, las exenciones materiales, las extensiones y la salida final de los servicios críticos.
Un comité directivo ejecutivo debería revisar el mapa integrado de dependencia, los hitos, los costos, los riesgos y las decisiones. Los propietarios del servicio deben aprobar los requisitos y las pruebas. Una oficina de gestión de separaciones debe mantener el control de la configuración, el cronograma, las dependencias entre flujos de trabajo y los informes.
El desafío independiente es valioso para los servicios materiales. La auditoría interna, el riesgo, la ciberseguridad, la privacidad, el control financiero o los especialistas externos pueden comprobar si la evidencia respalda la supuesta preparación. La independencia debe ser proporcionada y no debe eliminar la responsabilidad de la gestión.
Los informes deben mostrar resultados, no actividad. Las medidas útiles incluyen servicios cancelados, dependencias críticas cerradas, pruebas aprobadas dentro de la tolerancia, defectos graves no resueltos, conciliación de datos, preparación de proveedores, exposición a extensiones, efectivo gastado y acceso residual a proveedores.
La gobernanza debe controlar los cambios de referencia. El alcance, la arquitectura, la fecha de transición y los criterios de aceptación pueden cambiar a medida que surgen los hechos. Cada cambio material debe registrar el motivo, el costo, el riesgo, la dependencia y el aprobador. Esto evita que se informe una reducción tardía del alcance como progreso de la entrega y preserva una explicación auditable del resultado final.
18. Economía e incentivos del modelo TSA
La fijación de precios de la TSA puede utilizar recuperación de costos, costo plus, tarifas fijas, tarifas unitarias u otros mecanismos negociados. El destinatario deberá comparar los cargos temporales con el coste de reposición y salida. Un cargo bajo de la TSA puede reducir la urgencia incluso cuando el proveedor conlleva un riesgo cada vez mayor y un costo estancado.
El costo del proveedor puede quedar estancado a medida que disminuyen los volúmenes de destinatarios. Es posible que las licencias, la infraestructura y los equipos compartidos no se reduzcan de acuerdo con los cargos. Por lo tanto, el proveedor necesita un plan de eliminación de recursos vinculado a las salidas del servicio.
Los precios de extensión deben reconocer el esfuerzo y el riesgo incrementales sin crear una estructura coercitiva. Los aumentos automáticos de precios pueden motivar la salida, pero también pueden fomentar una reducción prematura si la gobernanza de la preparación es débil. La aprobación de la extensión debe seguir siendo una decisión explícita de riesgo y valor.
El modelo económico debe incluir tarifas de TSA, gastos de construcción, costos de doble ejecución, costos de terminación, costos de proveedores abandonados, demoras, contingencias y desventajas operativas. La presentación de EBITDA y la financiación en efectivo deben permanecer separadas.
19. Financiar la salida y proteger la liquidez
Los gastos de separación suelen concentrarse al principio, mientras que los beneficios llegan más tarde. El destinatario podrá pagar tasas de la TSA, proveedores de implementación, nuevas licencias, infraestructura duplicada, retención y capital de trabajo al mismo tiempo.
El plan de financiación debe mapear el efectivo comprometido y previsto por mes, moneda y entidad jurídica. Debe incluir impuestos, depósitos, pagos anticipados, gastos de capital, gastos operativos y contingencias. Los compromisos contractuales deben distinguirse de las estimaciones de gestión.
Las fallas operativas pueden crear presión de liquidez a través de retrasos en la facturación, pérdida de ventas, compensación al cliente, remediación, soporte de emergencia y consecuencias regulatorias. El escenario severo pero plausible debe financiarse, no simplemente describirse.
Las puertas de liquidez deberían utilizar umbrales mínimos de efectivo y margen de maniobra. Si la desventaja supera el piso aprobado, la gerencia debería redimensionar el alcance, agregar financiamiento, secuenciar de manera diferente o negociar una extensión limitada.
20. Aplicar el marco a una separación hipotética.
Considere un grupo hipotético de tecnología industrial que separa un negocio de servicios digitales con USD 1.25 billion de ingresos anuales. Al finalizar, el proveedor proporciona cuarenta y dos servicios de TSA en tecnología, finanzas, recursos humanos, adquisiciones, instalaciones, asuntos legales, datos y operaciones. Doce servicios respaldan resultados críticos de control o de clientes.
La dotación contractual es de dieciocho meses. Los objetivos de gestión salen de treinta y cinco servicios al mes doce, quedando siete servicios acotados para el período final. Los cargos de apertura anualizados de la TSA son USD 74 million. El costo del servicio recurrente final asumido es USD 69 million después del rediseño y el abastecimiento.
El presupuesto de separación único es USD 128 million: USD 52 million para aplicaciones y datos, USD 24 million para infraestructura y seguridad cibernética, USD 18 million para trabajo de control y modelo operativo, USD 14 million para transferencia de personas y conocimientos, USD 12 million para ejecución dual y transición, y USD 8 million para contingencias.
El programa identifica cinco cadenas de dependencia de alto riesgo: identidad, facturación al cliente, derechos de productos, cierre financiero y seguimiento del servicio. Cada cadena recibe una tolerancia al impacto, una prueba de extremo a extremo, un respaldo y un propietario ejecutivo. Todos los valores, tiempos y resultados en este caso son suposiciones creadas únicamente para demostrar el método.
| Artículo | Caja de apertura o base | Mes 12 | Estado final | Uso de decisiones |
|---|---|---|---|---|
| Servicios restantes de la TSA | 42 | 7 | 0 | Quema de dependencia |
| Servicios críticos restantes | 12 | 3 | 0 | Atención al tablero |
| Cargos anualizados de la TSA | 74 | 16 | 0 | Ganancias temporales y efectivo. |
| Costo de reposición anualizado | 0 | 58 | 69 | Base de costos sostenible |
| Caja de separación acumulada | 0 | 111 | 128 | Requisito de financiación |
| Costo varado anualizado del proveedor | 39 | 17 | 6 | Programa de eliminación de recursos |
| Defectos graves no resueltos | 19 | 3 | 0 | Puerta de preparación |
Escenario original. Todos los montos se suponen USD millones y no representan una previsión ni un punto de referencia del mercado.
21. Pruebe la hipotética desventaja
El caso base supone un corte de fin de semana controlado para la facturación y la identidad del cliente en el mes diez. El servicio permanece dentro de una tolerancia de acceso de clientes de cuatro horas y una tolerancia de recuperación de facturación de doce horas. Las conciliaciones se completan antes del siguiente archivo de recopilación.
El caso grave pero plausible supone un error de configuración de identidad, una reversión retrasada y una interfaz de facturación saliente dañada. El acceso de los clientes se ve afectado durante dieciocho horas, la facturación se retrasa cinco días y se requiere una solución de emergencia. El efecto de efectivo supuesto es USD 31 million antes de la recuperación: USD 17 million de cobros retrasados, USD 6 million de ingresos perdidos o acreditados, USD 5 million de remediación y USD 3 million de otros costos de capital de trabajo y comunicación.
El escenario no asigna una probabilidad. Prueba si los controles, las reservas, las comunicaciones y la liquidez pueden absorber un evento definido. La dirección puede elegir una secuencia de menor riesgo, un ensayo adicional o una extensión limitada si la evidencia no respalda la transición original.
La decisión debe comparar el costo de la demora con la exposición al fracaso. Una extensión de tres meses asumida en USD 6 million de las tarifas adicionales de la TSA y USD 4 million del costo de doble ejecución puede ser racional si cierra una exposición de liquidez creíble de USD 31 million y protege a los clientes. La comparación sigue siendo específica de cada empresa.
Escenario original. Todos los valores se suponen USD millones y excluyen la ponderación de probabilidad.
22. Utilice un mapa de riesgo y puertas de decisión
El riesgo debe combinar consecuencias y debilidad de la evidencia. Un servicio de altas consecuencias con recuperación no probada requiere más trabajo incluso si la fecha de implementación está según lo previsto. El tamaño de la burbuja puede representar la exposición al efectivo, la población de clientes u otra medida material.
La junta debería aprobar la entrada en la reducción final sólo cuando se conozcan las dependencias críticas, los defectos graves se cierren o se acepten explícitamente, se cumplan las tolerancias de impacto, la liquidez se mantenga por encima del umbral y la reversión sea viable. Un servicio rojo no debería ser promediado por muchos servicios verdes.
Las infracciones de puertas deben conducir a respuestas definidas: remediar, reordenar, reducir el alcance, agregar financiamiento, extender un servicio o cambiar el modelo operativo. La respuesta debe elegirse antes de que la presión comercial alcance su punto máximo.
Después de la salida, el programa debe verificar la eliminación del acceso al proveedor, la disposición de los datos, la liberación de recursos, el costo real de la tasa de ejecución y el rendimiento estable del servicio. Este cierre impide que los residuos operativos y financieros sobrevivan al programa formal.
Marco original. La posición y el tamaño de la burbuja son hipotéticos y deben reemplazarse con evidencia de la transacción.
| Puerta | evidencia requerida | decisión principal | señal de falla | Respuesta de la gerencia |
|---|---|---|---|---|
| Congelación de la arquitectura | Mapa de servicios y dependencias, modelo de destino y contratos. | Aprobar ruta y secuencia de salida | La dependencia crítica sigue siendo desconocida | Ampliar el descubrimiento y la resecuenciación |
| Construir preparación | Capacidad configurada, derechos de proveedores, propiedad del personal | Autorizar pruebas integradas | Licencia requerida, rol o control ausente | Remediar antes de probar |
| Preparación para la transición | Pruebas extremo a extremo, conciliación, recuperación y liquidez | Autorizar la transferencia en vivo | Tolerancia incumplida o reversión no probada | Retrasar, reducir el alcance o ampliar la TSA |
| Estabilización | Desempeño del servicio, cierre de problemas y operación de control. | Soporte elevado final | Incidente grave persistente o retraso | Conservar la estructura de mando y la financiación. |
| terminación de la TSA | Independencia del destinatario y evidencia de divulgación del proveedor | Terminar el servicio y el acceso | Dependencia operativa residual | Aprobar soporte acotado con fecha de salida |
| Cierre del programa | Disposición de datos, tasa de ejecución de costos y evidencia de costos abandonados | Cerrar la rendición de cuentas del programa | Los ahorros o el acceso existen sólo en papel. | Mantener la propiedad y la presentación de informes |
Marco original. Los umbrales deben reflejar el negocio, el sector, las jurisdicciones y el apetito de riesgo aprobado.
23. Ejecutar una hoja de ruta por fases
La primera fase establece la gobernanza, el inventario de servicios, las tolerancias de impacto, los plazos contractuales y el descubrimiento. El programa concilia los cronogramas firmados con el apoyo real e identifica cadenas de dependencia críticas.
La segunda fase define el modelo operativo objetivo, la arquitectura, el perímetro de datos, la estrategia del proveedor, la organización y el entorno de control. Convierte cada servicio en un paquete de trabajo financiado con evidencia de aceptación.
La fase tres construye y configura la capacidad. Los datos se limpian y ensayan, se establecen interfaces, se preparan identidades, los contratos entran en vigor y se escriben procedimientos operativos. Las pruebas de componentes comienzan temprano.
La cuarta fase realiza pruebas integradas de rendimiento, seguridad, recuperación y operativas. Los equipos de destinatarios dirigen el servicio, se cierran los defectos y se ensaya el runbook de transición. La junta recibe un registro de preparación específico para el servicio.
La fase cinco se realiza en oleadas controladas, estabiliza el servicio, concilia datos y cierra el acceso residual. El proveedor libera recursos según lo permitan las pruebas. El coste, el rendimiento y las incidencias reales se comparan con el caso aprobado.
La hoja de ruta debe seguir siendo dinámica. Una dependencia recién descubierta puede cambiar de secuencia sin cambiar el objetivo final. La calidad de la gobernanza se demuestra mediante cambios oportunos basados en evidencia en lugar del cumplimiento de una fecha obsoleta.
24. Conclusión
La salida de TSA es una transferencia operativa respaldada por un contrato. El destinatario debe controlar las personas, los procesos, la tecnología, la información, los proveedores, los controles y la financiación necesarios para prestar cada servicio. El proveedor debe poder eliminar el acceso, la infraestructura y los recursos sin dañar el negocio retenido.
Los programas más sólidos se diseñan desde el resultado final del servicio hacia atrás. Mapean dependencias, definen tolerancias de impacto, crean evidencia de aceptación mensurable, ensayan escenarios severos y preservan una alternativa viable. Tratan los datos, la identidad, las finanzas, la seguridad cibernética y los derechos de los proveedores como requisitos operativos en lugar de apéndices técnicos.
También mantienen la disciplina comercial durante toda la entrega. Cada extensión, exención y cambio de alcance se evalúa en función de la continuidad del cliente, las obligaciones legales, la financiación y el caso de la transacción. El desempeño real después de la transición se mide con respecto al diseño aprobado, lo que permite a la gerencia corregir las brechas de costos, capacidad o control antes de que se integren en la nueva organización.
El caso hipotético muestra cómo un paquete contractual de dieciocho meses puede respaldar un objetivo de gestión de doce meses preservando al mismo tiempo un período final controlado. También muestra que un problema de transición puede consumir liquidez importante incluso cuando el servicio subyacente finalmente se restablezca. Estos valores son suposiciones, no pronósticos.
La confianza de la junta directiva depende de la evidencia a nivel de servicio. Un programa puede informar una alta finalización mientras una dependencia crítica sigue siendo insegura. La salida debe ocurrir cuando el receptor puede operar dentro de las tolerancias aprobadas, el proveedor puede terminar sus obligaciones limpiamente y ambas partes comprenden el riesgo financiero y operativo residual.
Fuentes
- Autoridad de Conducta Financiera, Resiliencia operativa: ideas y observaciones un año después, publicado el 27 de marzo de 2026, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Comisión de Bolsa y Valores de EE. UU., formulario de acuerdo de servicios de transición de Johnson & Johnson y Kenvue, Anexo 10.10, presentado en 2024, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Comisión de Bolsa y Valores de EE. UU., Acuerdo de servicios de transición de Jacobs Solutions y Amentum, Anexo 10.2, de fecha 27 de septiembre de 2024, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Comisión de Bolsa y Valores de EE. UU., Formulario 8-K de Western Digital sobre el acuerdo de servicios de transición y separación de Sandisk, presentado el 21 de febrero de 2025, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Oficina del Comisionado de Información, Diligencia debida al compartir datos tras fusiones y adquisiciones, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, publicación especial 800-207 Zero Trust Architecture, publicada en agosto de 2020, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Cybersecurity Framework 2.0, publicado en febrero de 2024, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Agencia de Seguridad de Infraestructura y Ciberseguridad, Cross-Sector Cybersecurity Performance Goals, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Fundación IFRS, NIIF 5 Activos no corrientes mantenidos para la venta y operaciones discontinuadas, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Autoridad de Conducta Financiera, Resiliencia operativa: conocimientos y observaciones para empresas, publicado el 28 de mayo de 2024, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Unión Europea, Reglamento UE 2022/2554 sobre resiliencia operativa digital para el sector financiero, artículo 28, Diario Oficial de 27 de diciembre de 2022, consultado el 16 de septiembre de 2026. Lea la fuente principal
- Comisión de Bolsa y Valores de EE. UU., Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, publicación 33-11216, vigente a partir del 5 de septiembre de 2023, consultado el 16 de septiembre de 2026. Lea la fuente principal
