La continuidad como servicio funciona cuando la empresa conserva las decisiones que sólo el negocio puede tomar —criticidad, riesgo aceptable, prioridades, crisis y cumplimiento— y delega la ejecución especializada: monitoreo, runbooks, recuperación, pruebas y evidencia. La regla es simple: se puede delegar la operación de continuidad, pero no la responsabilidad ejecutiva sobre ella.
1. Continuidad como servicio
Modelo gestionado en el que un tercero opera de manera recurrente determinadas capacidades de continuidad y recuperación: monitoreo, actualización de planes técnicos, pruebas, recuperación, evidencia, métricas y mejora continua.
No es un término normativo equivalente a ISO 22301 ni debe confundirse exclusivamente con Disaster Recovery as a Service (DRaaS). DRaaS se concentra principalmente en recuperar infraestructura, aplicaciones y datos; un modelo de continuidad administrada incorpora además gobierno, procesos, personas, dependencias y capacidad del negocio para seguir operando.
2. Business Impact Analysis (BIA)
Análisis que identifica las funciones críticas del negocio, sus dependencias y el impacto que generaría su interrupción. Su objetivo no es decidir qué servidor es importante, sino qué proceso debe recuperarse primero para evitar un impacto financiero, operativo, contractual o regulatorio material.
NIST plantea precisamente que la secuencia de recuperación debe seguir las prioridades identificadas en el BIA y que los recursos de mayor criticidad pueden necesitar recuperarse antes que el resto.
3. RTO y RPO
RTO (Recovery Time Objective) es el tiempo objetivo para restablecer una capacidad después de una interrupción. RPO (Recovery Point Objective) determina cuánta información puede perderse, medida en tiempo.
En Pulse by Scanda los tratamos como decisiones de negocio respaldadas técnicamente: TI puede determinar qué arquitectura hace posible un RTO de dos horas, pero sólo el negocio puede confirmar si esas dos horas son tolerables.
Tabla comparativa: qué conservar, qué delegar y qué compartir
| Capacidad de continuidad | En casa | Proveedor | Responsabilidad compartida |
| Definir funciones críticas del negocio | Sí | Facilita metodología | — |
| Aprobar BIA y nivel de criticidad | Sí | Aporta análisis | — |
| Definir tolerancia financiera a la interrupción | Sí | Puede modelar escenarios | — |
| Proponer RTO y RPO técnicamente viables | Participa | Participa | Sí |
| Aprobar RTO y RPO | Sí | — | — |
| Mantener inventario técnico y dependencias | Valida | Puede operar | Sí |
| Monitoreo y alertamiento 24×7 | Opcional | Delegable | — |
| Replicación, respaldos y plataformas de recuperación | Supervisa | Delegable | Sí |
| Mantener runbooks técnicos | Valida | Delegable | Sí |
| Ejecución de recuperación | Participa | Delegable | Sí |
| Pruebas de DRP | Participa y acepta resultado | Coordina y ejecuta | Sí |
| Declaración formal de crisis o desastre | Sí | Recomienda escalamiento | — |
| Comunicación con consejo, clientes o regulador | Sí | Aporta evidencia | — |
| Evidencia de pruebas y cumplimiento | Aprueba y conserva | Puede producirla | Sí |
| Aceptación de riesgo residual | Sí | Informa | — |
| Gobierno y evaluación del proveedor | Sí | Entrega KPIs/evidencia | — |
| Plan de salida y sustitución del proveedor | Sí | Debe habilitar transición | Sí |
La conclusión de la matriz es importante: cuanto más cerca esté una decisión del P&L, del riesgo aceptado o de una obligación regulatoria, menos sentido tiene delegarla. Cuanto más repetitiva, especializada o 24×7 sea su ejecución, mayor sentido tiene administrarla como servicio.
Continuidad como servicio: un modelo operativo, no un plan guardado
El primer error es pensar que contratar continuidad significa entregar el DRP a un tercero y esperar que éste “se encargue” cuando ocurra un incidente.
ISO 22301 plantea la continuidad como un sistema de gestión que debe planificarse, implementarse, operarse, monitorearse, revisarse, mantenerse y mejorarse continuamente. Es decir, la continuidad no termina cuando se aprueba el documento.
En Pulse by Scanda partimos del mismo principio. Nuestro modelo de resiliencia contempla anticipar, resistir, responder, recuperar y adaptar; además, el alcance interno definido para continuidad incluye BIA, BCP, DRP, RTO, RPO, estrategias de recuperación, planes de crisis, pruebas y simulaciones. Esto cambia la pregunta. No es:
“¿Podemos tercerizar nuestro DRP?”
La pregunta correcta es:
“¿Qué decisiones debemos controlar y qué capacidades nos conviene operar mediante un especialista para sostenerlas todos los días?”
¿Qué debe mantenerse dentro de la organización?
1. La definición de lo que realmente debe seguir operando
Un proveedor puede facilitar el BIA, entrevistar áreas, mapear aplicaciones y calcular impactos. Lo que no puede decidir por la empresa es si facturación, planta, e-commerce, cajeros, logística o atención al cliente son más importantes entre sí.
Esa decisión pertenece al negocio.
El COO, CIO y responsables de proceso tienen que poder responder:
- ¿Cuáles son las funciones que no pueden detenerse?
- ¿Cuánto tiempo pueden operar degradadas?
- ¿Qué ingreso, margen o contrato se pone en riesgo?
- ¿Qué dependencias tecnológicas permiten operar esas funciones?
- ¿Qué proceso debe recuperarse primero?
En el modelo consultivo que utilizamos en Pulse by Scanda, el primer paso es precisamente entender qué debe seguir operando; después se mapean contexto, dependencias, escenarios e impacto.
2. La aceptación de riesgo
El proveedor puede cuantificar escenarios, pero no debería aprobarlos.
Aceptar que una aplicación tenga un RTO de ocho horas porque reducirlo a dos requeriría mayor inversión es una decisión económica, no exclusivamente técnica.
Lo mismo aplica para:
- riesgo residual;
- excepciones de seguridad;
- puntos únicos de falla no eliminados;
- sistemas sin redundancia;
- dependencias de terceros;
- inversiones diferidas.
Si esa decisión afecta EBITDA, ingresos, multas o contratos, debe existir un responsable del lado del cliente.
3. La autoridad de crisis
La recuperación técnica puede delegarse. La autoridad para declarar una contingencia, activar un protocolo corporativo o informar a un regulador no.
Debe quedar claro quién puede decidir:
- declarar un desastre;
- activar sitios alternos;
- operar en modo degradado;
- desconectar sistemas;
- detener una operación;
- comunicar a clientes;
- informar al consejo;
- activar obligaciones regulatorias.
Sin esta capa, un proveedor puede tener perfectamente documentado cómo recuperar una plataforma y aun así perder tiempo esperando autorización para hacerlo.
4. La responsabilidad sobre cumplimiento
Este punto suele generar confusión.
La guía FFIEC para instituciones financieras establece explícitamente que utilizar proveedores externos no libera a la organización de la responsabilidad sobre las actividades tercerizadas; la supervisión permanece en el consejo y la alta dirección. Aunque es una guía sectorial estadounidense y no una regulación general para México, el principio de gobierno es particularmente útil: delegar ejecución no equivale a transferir accountability.
Nuestro propio marco de Pulse by Scanda sigue esa separación: no sustituimos al CISO ni al equipo interno; damos visibilidad, priorización y capacidad de ejecución, mientras el accountability continúa en el cliente.
¿Qué conviene delegar a un proveedor de continuidad?
1. Cobertura especializada 24×7
Mantener capacidad propia para todas las disciplinas necesarias durante un incidente puede implicar disponer permanentemente de especialistas en:
- infraestructura;
- nube;
- redes;
- seguridad;
- identidad;
- respaldos;
- almacenamiento;
- bases de datos;
- aplicaciones;
- respuesta a incidentes.
El argumento para delegar no es simplemente “tener menos personal”.
Es evitar que la recuperación dependa de que la persona correcta esté disponible exactamente cuando el negocio falla.
2. Orquestación técnica de la recuperación
Un proveedor puede asumir actividades repetibles y documentables como:
- mantenimiento de runbooks;
- validación de respaldos;
- replicación;
- failover y failback;
- restauración;
- verificación de infraestructura;
- ejecución de secuencias de recuperación;
- coordinación entre plataformas;
- recopilación de evidencia.
Esto libera al equipo interno para concentrarse en decisiones de negocio y excepciones, en lugar de improvisar procedimientos bajo presión.
3. Pruebas y simulaciones
Este es probablemente el componente que más valor genera y que más fácilmente se posterga internamente.
Un backup completado no demuestra que la aplicación pueda recuperarse.
Sophos reportó en su estudio de ransomware en México 2026 que sólo 58% de las organizaciones afectadas utilizó backups para recuperar información cifrada, frente a 68% un año antes. El propio reporte recomienda probar los respaldos periódicamente, mantener copias offline o inmutables e integrarlas a un plan de respuesta ejecutable bajo presión.
Por eso la métrica correcta no es:
“¿Qué porcentaje de backups terminó correctamente?”
Sino:
“¿Qué porcentaje de nuestras funciones críticas ha sido recuperado exitosamente dentro de su RTO y RPO?”
4. Producción de evidencia operativa
Otra actividad altamente delegable es convertir cada prueba, cambio y recuperación en evidencia utilizable.
Por ejemplo:
- fecha de la prueba;
- escenario utilizado;
- participantes;
- RTO objetivo;
- RTO obtenido;
- RPO objetivo;
- RPO obtenido;
- dependencias fallidas;
- excepciones;
- acciones correctivas;
- propietario;
- fecha compromiso;
- resultado del siguiente retest.
Eso permite que continuidad deje de depender de un documento anual y se convierta en una capacidad observable.
¿Qué responsabilidades deben ser compartidas?
El modelo más sólido no divide continuidad entre “lo del cliente” y “lo del proveedor”. Define procesos donde ambos tienen una función concreta.
- BIA. El proveedor facilita, estructura y cuestiona.El negocio determina qué es crítico y cuánto cuesta que deje de operar.
- RTO y RPO. El proveedor establece qué es técnicamente posible, cuánto cuesta y qué arquitectura requiere.El cliente determina qué nivel de interrupción está dispuesto a aceptar.
- Pruebas. El proveedor diseña y ejecuta la recuperación.El cliente valida que la función empresarial realmente volvió a operar.Ese detalle importa: un servidor puede estar activo mientras el proceso de negocio continúa detenido.
- Gestión de cambios. Cada cambio significativo en arquitectura, aplicación, proveedor, identidad o datos puede invalidar una parte del DRP.Por eso continuidad debe conectarse con change management.El cambio no termina cuando producción funciona. Para una función crítica debería terminar cuando también se verifica que la nueva arquitectura sigue siendo recuperable.
- Mejora posterior al incidente. El proveedor puede generar el postmortem y el backlog.El cliente tiene que decidir qué riesgos corrige, cuáles acepta y cuáles financia.
Una organización resiliente no vuelve simplemente al estado previo a la interrupción: modifica controles, arquitectura y procedimientos para evitar repetirla. Ese principio de mejora continua también está incorporado en nuestro marco de resiliencia.
¿Cómo diseñar un modelo de continuidad como servicio?
Paso 1. Empieza por cinco funciones críticas, no por 200 aplicaciones
Pregunta primero:
¿Qué cinco funciones del negocio no deberían detenerse?
Después identifica las aplicaciones, datos, identidades, infraestructura, proveedores y personas que las sostienen.
Hacerlo al revés genera un DRP técnicamente completo y económicamente mal priorizado.
Paso 2. Calcula el impacto de la interrupción
Para cada función crítica documenta:
Impacto de indisponibilidad = margen dejado de generar + personal improductivo + penalizaciones + recuperación + obligaciones contractuales + consecuencias regulatorias cuantificables.
No todos los componentes aplicarán en todos los casos.
El objetivo es convertir “esta aplicación es crítica” en algo defendible ante dirección:
“Cuatro horas fuera representan X de exposición.”
Paso 3. Define RTO y RPO después del impacto, no antes
No asignes RTO porque “siempre ha sido cuatro horas”.
Primero determina el impacto.
Después compara:
Costo de reducir el RTO < pérdida esperada que esa reducción evita.
Ésa es la conversación que convierte continuidad de gasto técnico a protección de EBITDA.
Paso 4. Construye un RACI de continuidad
Debe existir al menos un responsable para:
- declarar contingencia;
- activar recuperación;
- aprobar failover;
- restaurar identidades;
- restaurar datos;
- validar la aplicación;
- validar el proceso empresarial;
- comunicar;
- documentar;
- cerrar el incidente;
- aceptar riesgo residual.
Si durante una prueba alguien pregunta “¿quién autoriza esto?”, el ejercicio ya encontró una vulnerabilidad.
Paso 5. Lleva RTO, RPO y pruebas al contrato
Un SLA de “99.9%” no es suficiente.
La guía de FFIEC recomienda que los contratos de servicios críticos contemplen métricas de servicio, RTO, RPO, requisitos y frecuencia de pruebas, acceso a resultados, responsabilidades de subcontratistas, gobierno de datos y obligaciones de notificación ante incidentes.
Para un servicio administrado de continuidad recomendamos exigir, como mínimo:
- RTO y RPO por servicio crítico;
- cobertura y horarios;
- mecanismo de escalamiento;
- tiempos para activar recuperación;
- frecuencia de pruebas;
- evidencia disponible después de cada ejercicio;
- tratamiento de terceros y subcontratistas;
- propiedad y portabilidad de datos;
- controles sobre accesos privilegiados;
- procedimiento de salida;
- disponibilidad de runbooks;
- responsabilidades de failback;
- criterios de aceptación de una recuperación.
Paso 6. Prueba la función, no sólo la infraestructura
NIST recomienda que el orden de recuperación refleje las prioridades definidas en el BIA. Eso significa que el objetivo no es encender primero lo técnicamente más sencillo, sino lo que el negocio necesita antes.
Una prueba completa debería responder:
¿La organización puede volver a facturar, producir, cobrar, atender o despachar dentro del tiempo acordado?
Eso vale mucho más que un screenshot indicando que una máquina virtual arrancó.
Paso 7. Crea un tablero ejecutivo trimestral
Un comité de continuidad no necesita 80 métricas.
Necesita saber:
| Indicador | Pregunta ejecutiva que responde |
| % de funciones críticas con dependencias mapeadas | ¿Sabemos dónde puede romperse el negocio? |
| % de funciones críticas probadas | ¿Nuestra continuidad está comprobada o supuesta? |
| % de pruebas dentro de RTO | ¿Estamos recuperando a la velocidad prometida? |
| % de pruebas dentro de RPO | ¿Estamos perdiendo más datos de los aceptados? |
| Hallazgos abiertos después de pruebas | ¿Estamos corrigiendo? |
| Hallazgos recurrentes | ¿Estamos aprendiendo? |
| Tiempo de activación del DRP | ¿Perdemos tiempo decidiendo? |
| Dependencias de terceros sin prueba | ¿Quién puede detenernos fuera de nuestra organización? |
En Pulse proponemos precisamente medir recuperaciones probadas y cumplimiento real de RTO/RPO, en lugar de quedarse únicamente con el número de respaldos ejecutados.
¿Cómo construir el caso financiero y medir el ROI?
La comparación correcta no es: “¿Cuánto cuesta el proveedor contra el salario de una persona?”
Hay que comparar capacidades equivalentes.
Costo interno anual de continuidad
Incluye: personal + guardias + especialización + infraestructura redundante + nube + licencias + almacenamiento + respaldos + pruebas + capacitación + consultoría especializada + documentación + auditoría + costo de mantener capacidad ociosa disponible.
Costo administrado anual
Incluye: servicio recurrente + infraestructura de recuperación + nube + pruebas + consumo extraordinario por incidentes + transición + herramientas que no estén incluidas.
Después incorpora el riesgo
El business case debe sumar dos palancas:
1. Pérdida evitada. Horas de indisponibilidad evitadas × costo por hora + multas, penalizaciones o contratos protegidos.
2. Capacidad liberada. Horas internas que ya no se consumen manteniendo planes, correlacionando herramientas, produciendo evidencia o ejecutando actividades que un proveedor puede industrializar.
Son las mismas dos palancas que utilizamos en nuestro framework de ROI en Pulse by Scanda: pérdida evitada y costo liberado.
La dimensión económica no es teórica. IBM reportó para Latinoamérica en 2025 un costo promedio de US$2.51 millones por filtración de datos. Los incidentes identificados y contenidos en menos de 200 días promediaron US$2.21 millones, frente a US$2.82 millones cuando superaron ese periodo. Además, los incidentes que involucraron múltiples entornos tecnológicos fueron los más costosos, con US$2.84 millones en promedio.
En México, Sophos estimó en 2026 un costo promedio de recuperación de US$752,000 por ataque de ransomware, excluyendo el rescate. El 64% de las organizaciones estudiadas se recuperó en menos de una semana, pero 12% necesitó entre uno y seis meses.
Para un CFO, ésa es la lectura correcta de continuidad: no cuánto cuesta tener el servicio, sino cuánto capital, margen y exposición protege frente a una interrupción material.
Riesgos de delegar demasiado
La tercerización también introduce riesgos.
Dependencia excesiva del proveedor
Si nadie dentro de la organización entiende el plan, el DRP se convierte en propiedad intelectual operativa del tercero.
Eso crea lock-in.
Concentración
Un mismo proveedor puede estar recuperando simultáneamente a múltiples clientes afectados por un incidente regional.
Por eso es necesario validar capacidad real, no sólo arquitectura.
FFIEC advierte precisamente sobre el riesgo de concentración y sobre la necesidad de verificar que un proveedor tenga capacidad suficiente para cumplir RTO y RPO cuando varios clientes requieran recuperación simultáneamente.
Pruebas demasiado controladas
Una prueba donde:
- todos conocen el escenario;
- nadie falla;
- no participa negocio;
- no intervienen terceros;
- no se mide RTO;
- no se valida la aplicación;
demuestra muy poco.
Las pruebas deben introducir incertidumbre suficiente para revelar dependencias reales.
Un contrato que mide infraestructura en vez de negocio
Un proveedor puede cumplir técnicamente mientras el cliente sigue detenido.
El SLA debe conectarse con el servicio empresarial.
No basta con:
“servidor restaurado”.
Es mejor:
“función de facturación disponible y validada”.
Falta de estrategia de salida
Todo servicio administrado de continuidad debería responder desde el primer día:
¿Qué ocurre si mañana tenemos que cambiar de proveedor?
Runbooks, configuraciones, credenciales, respaldos, documentación, inventarios y evidencia deben poder transferirse sin destruir el RTO que se intentaba proteger.
Conclusión predictiva
La continuidad empresarial va a migrar progresivamente de proyectos de DRP ejecutados cada varios años hacia modelos recurrentes de continuidad medible.
La razón no será solamente el ransomware. Las organizaciones dependen simultáneamente de SaaS, nube, infraestructura propia, identidades y terceros. IBM encontró que las brechas que atravesaron múltiples entornos fueron las más costosas en Latinoamérica durante 2025; Sophos, por su parte, muestra que en México el uso de backups para recuperación bajó en 2026. Por eso el diferenciador dejará de ser tener un documento de DRP y será poder demostrar, con evidencia:
qué recuperas, en qué orden, en cuánto tiempo y cuándo fue la última vez que comprobaste que funciona.
En Pulse by Scanda vemos la continuidad como una capacidad operativa, no como un archivo que espera una emergencia. Nuestro papel es ayudar a conectar BIA, arquitectura, recuperación, pruebas, evidencia y mejora continua; las decisiones que definen el riesgo del negocio permanecen donde deben estar: en el negocio.
Tu DRP puede existir y aun así no estar listo para el día que realmente lo necesites. En Pulse by Scanda ayudamos a convertir continuidad y recuperación en una capacidad operativa: identificamos funciones críticas, mapeamos dependencias, revisamos BIA, RTO y RPO, diseñamos estrategias de recuperación y llevamos el plan hasta la prueba y la evidencia.
Si hoy tu organización sabe cuántos respaldos tiene, pero no qué porcentaje de sus funciones críticas puede recuperar dentro del tiempo comprometido, ése es el punto por donde conviene empezar. Hablemos de tu modelo de continuidad y definamos qué debes gobernar internamente, qué puedes delegar y qué necesitas comprobar antes de la próxima interrupción.
FAQ
1. ¿Conviene tercerizar por completo el BCP y el DRP? No. Se puede delegar gran parte de la ejecución técnica, monitoreo, documentación, pruebas y recuperación, pero el negocio debe conservar la definición de funciones críticas, la aceptación de riesgo, la aprobación de RTO/RPO, la autoridad de crisis y la supervisión del proveedor. Externalizar ejecución no transfiere responsabilidad ejecutiva.
2. ¿Cómo sabe un CFO si continuidad como servicio es más rentable que operarla internamente? Debe comparar el TCO completo de ambas alternativas, no sólo salarios contra la cuota del proveedor. El análisis debe incluir especialistas, guardias, infraestructura redundante, herramientas, pruebas, auditorías y capacidad ociosa, además del impacto económico de las horas de indisponibilidad que cada modelo podría evitar. El ROI se sostiene sobre pérdida evitada y capacidad interna liberada.
3. ¿Qué debería exigir un CIO o CISO a un proveedor de continuidad? Como mínimo: RTO/RPO contractuales, pruebas periódicas, evidencia de recuperación, runbooks actualizados, escalamiento 24×7, controles de acceso, responsabilidades sobre terceros, derecho a revisar resultados, notificación de incidentes, propiedad de datos y un plan de salida. Un buen proveedor debe demostrar recuperación, no únicamente disponibilidad de infraestructura.
