La continuidad del negocio es la capacidad de una organización de mantener o recuperar rápidamente sus funciones críticas después de una interrupción. Es el punto donde la conversación deja de ser exclusivamente tecnológica, porque quien puede responder cuánto aguanta la empresa sin facturar no es el área de TI: es la gerencia.
Conviene ubicarla junto a un concepto más amplio. La resiliencia es la capacidad de prepararse, resistir, responder, recuperarse y adaptarse frente a un incidente. La ciberseguridad trabaja sobre la probabilidad y el impacto de que ocurra; la resiliencia agrega la pregunta que la seguridad por sí sola no responde: qué pasa con el negocio cuando ocurre igual.
Continuidad del negocio y continuidad operacional: ¿son lo mismo?
En la práctica, sí: las dos expresiones apuntan a que la empresa siga funcionando cuando algo falla. La diferencia está en quién las usa. "Continuidad del negocio" es el término de los estándares internacionales, como ISO 22301; "continuidad operacional" es el que usa la ley chilena: la Ley 21.663 habla de la continuidad operacional del servicio prestado.
Por eso el segundo término aparece cada vez más en contratos, licitaciones y cuestionarios de clientes grandes. Cuando un cliente pide un "plan de continuidad operacional", pide lo mismo que esta guía explica: procesos críticos identificados, RTO y RPO decididos, un plan escrito y evidencia de que se probó.
RTO y RPO: las dos cifras que hay que decidir
Son las dos métricas centrales de cualquier plan de continuidad, y se confunden con frecuencia porque ambas se miden en tiempo. Pero apuntan en direcciones opuestas respecto del momento del incidente.
- RPO — Recovery Point Objective
- Mira hacia atrás: cuánta información estás dispuesto a perder. Si respaldas una vez al día, tu RPO es de veinticuatro horas, y eso significa que un incidente puede costarte un día completo de trabajo.
- RTO — Recovery Time Objective
- Mira hacia adelante: cuánto tiempo puede estar caído el servicio antes de que el daño sea inaceptable. No es cuánto demoras hoy en recuperarte, es cuánto puede tolerar el negocio.
El BIA es lo que permite fijar esas cifras
El Análisis de Impacto al Negocio, o BIA, es el ejercicio previo: identifica cuáles son los procesos críticos, de qué sistemas y proveedores dependen, y cuánto cuesta cada hora de interrupción de cada uno. Sin ese análisis, el RTO y el RPO se fijan por intuición y suelen quedar mal calibrados en ambos sentidos.
El Plan de Continuidad, o BCP, es el documento que traduce esos objetivos en acciones concretas: quién declara la contingencia, a quién se avisa, qué se levanta primero, con qué recursos alternativos se opera mientras tanto y cómo se vuelve a la normalidad.
Cómo armar un plan de continuidad del negocio, paso a paso
- 1. Identificar los procesos críticos
- Cuáles detienen la facturación o la operación si se caen. En una empresa mediana suelen ser pocos: ventas, despacho, producción, pagos.
- 2. Hacer el BIA
- De qué sistemas, personas y proveedores depende cada proceso, y cuánto cuesta cada hora detenida.
- 3. Decidir el RTO y el RPO de cada proceso
- Es una decisión de la gerencia, no de TI, y se toma con las cifras del BIA a la vista.
- 4. Definir cómo se recupera y escribir el plan
- Qué se levanta primero, con qué recursos alternativos se opera mientras tanto, quién declara la contingencia y a quién se avisa.
- 5. Probarlo y revisarlo
- Primero un ejercicio de escritorio con los responsables y luego una restauración real. Se revisa al menos una vez al año, y cada vez que cambie un sistema crítico o un proveedor.
Un respaldo que nadie ha restaurado no es un respaldo
Es la brecha más frecuente y la más incómoda de descubrir en medio de una crisis. Muchas empresas tienen respaldos configurados y ninguna prueba documentada de restauración. El respaldo existe, se ejecuta todas las noches, y nadie ha comprobado nunca que se pueda volver a levantar el sistema a partir de él.
Por eso la verificación es parte del control, no un extra. Un plan de continuidad que nunca se ha ensayado es una hipótesis, y la primera vez que se pone a prueba no debería ser el día del incidente.
Continuidad del negocio en Chile: qué exige la Ley 21.663
La Ley 21.663 obliga a reportar incidentes a todas las instituciones que prestan servicios esenciales, no solo a los Operadores de Importancia Vital: energía, agua, telecomunicaciones, transporte, banca, salud y servicios de TI gestionados por terceros, entre otros (art. 4°). Los plazos son exigentes: una alerta temprana al CSIRT Nacional dentro de tres horas, una actualización a las 72 horas (24 si es un OIV y se afecta su servicio) y un informe final dentro de quince días (art. 9°). Esos plazos corren desde que se tiene conocimiento del incidente, en el peor momento posible para improvisar quién avisa y con qué información.
Para los Operadores de Importancia Vital la exigencia va más lejos: deben elaborar e implementar planes de continuidad operacional y ciberseguridad, certificarlos y revisarlos al menos cada dos años (art. 8°, letra c). Una empresa que no es OIV no tiene esa obligación por ley, pero si le presta servicios a uno, es probable que se la pidan por contrato.
La Ley 21.719 agrega la otra cara: ante una vulneración de datos personales hay que notificar, y para eso se necesita saber qué datos había en el sistema afectado y desde cuándo. Un plan de continuidad que incluya el inventario y el procedimiento de notificación convierte esa obligación en un trámite ordenado en vez de una carrera contra el reloj.
Continuidad del negocio en transporte y otros rubros
El transporte terrestre, aéreo, ferroviario y marítimo es servicio esencial según la Ley 21.663. Una empresa de transporte tiene, por eso, el deber de reportar incidentes en tres horas aunque no sea OIV. Su plan de continuidad tiene que contemplar el escenario cibernético, no solo el terremoto o el corte de ruta: qué pasa si un ransomware cifra el sistema de despacho o de ruteo, con qué se opera mientras tanto y quién avisa al CSIRT.
En otros rubros la pregunta es la misma y la respuesta cambia:
- Salud
- Sin acceso a la ficha clínica ni a la agenda, la atención sigue, pero a ciegas. En un centro de salud, el RTO se mide en horas.
- Agroindustria
- En temporada de cosecha, un día detenido significa fruta que no se procesa: en una planta agroindustrial, el mismo sistema tiene un RTO distinto según el mes.
- Industria
- Si la línea depende de un servidor o de una pantalla de operación, el plan tiene que decir cómo se produce sin ella, o cuánto tiempo se puede parar.
Para puertos, operadores ferroviarios y su cadena de proveedores, el detalle está en la página de ciberseguridad para logística y transporte.
Dónde suele aparecer primero
La pregunta que ordena todo
Si mañana el sistema de ventas deja de funcionar, ¿cuánto tiempo puede operar la empresa? La respuesta suele revelar más que un informe técnico.
Cuando la gerencia dice cuatro horas y el equipo de TI reconoce que restaurar desde el último respaldo toma dos días, la brecha queda expuesta en una sola conversación y deja de ser discutible.
Esa distancia entre lo que el negocio necesita y lo que la operación puede entregar hoy es exactamente lo que un plan de continuidad viene a cerrar, y define cuánto vale la pena invertir en cerrarla.
Lo que la gerencia tiene que decidir
El RTO y el RPO no son cifras técnicas: son decisiones de negocio que la gerencia toma y el área técnica implementa.
- 01
¿Cuánto tiempo puede operar la empresa sin cada sistema crítico?
Esa respuesta fija el RTO. Es la cifra que nadie del área técnica puede inventar, porque depende de cuánto cuesta cada hora detenida.
- 02
¿Cuánta información puede permitirse perder?
Esa respuesta fija el RPO y determina la frecuencia de respaldo. Decir 'ninguna' es una respuesta cara: conviene saber cuánto cuesta antes de exigirla.
- 03
¿Quién declara la contingencia y con qué autoridad?
En medio de un incidente no hay tiempo para escalar decisiones. Si nadie tiene el mandato de detener la operación o activar el plan, el plan no se activa.
- 04
¿Cuándo se ensaya y quién autoriza el ensayo?
Un plan nunca probado es una hipótesis. La prueba consume tiempo del equipo y a veces detiene sistemas, así que necesita autorización explícita y fecha en el calendario.
Cómo lo abordamos en Brumaz
Cómo trabaja Brumaz este concepto
La continuidad entra en el roadmap como cualquier otra capacidad: primero se determina qué procesos son críticos y qué tolerancia real tiene el negocio, y de ahí se derivan los controles y las pruebas necesarias. Brumaz define y verifica que el respaldo, la restauración y el plan funcionen; la ejecución técnica la hace tu equipo o tu proveedor.
Ver el servicio completoRecibe esta guía en PDF
El mismo contenido, con formato para leerla en el celular, imprimirla o compartirla con tu equipo. Te llega por correo en un minuto.
Preguntas frecuentes
¿La continuidad del negocio es lo mismo que tener respaldos?
¿Cada cuánto hay que probar el plan?
¿Esto aplica a una empresa mediana o es solo para grandes?
Fuentes
Este contenido es informativo y no constituye asesoría legal ni técnica personalizada.
Sobre el autor
Fundador, Brumaz
Once años en redes, infraestructura y seguridad. Esa base técnica es la que sostiene la dirección de riesgo: no recomienda un control que no sepa verificar, ni pide evidencia que no sepa leer.
- Ingeniero Civil en Telecomunicaciones (Universidad de Concepción)
- Diplomado en Data Science (Universidad Adolfo Ibáñez)
- Certificaciones en ciberseguridad y en soluciones Fortinet y WatchGuard
- Implementador de Sistemas de Gestión Integrados usando Inteligencia Artificial (Diplomados en Ciberseguridad)
Seguir leyendo