¿A qué hora del incidente deja de funcionar su plan de continuidad del negocio?

Un BCP (Business Continuity Plan o Plan de Continuidad del Negocio) falla cuando no contempla la red de telecomunicaciones como componente crítico: los sistemas pueden estar disponibles, pero sin poder comunicarse entre sí. Las brechas más comunes son falta de redundancia física real, desalineación entre SLA (Service Level Agreement) y RTO (Recovery Time Objective), ausencia de pruebas de conmutación bajo carga real, y poca integración del equipo de red en los ejercicios de continuidad. Este artículo explica dónde ocurren esas fallas y qué decisiones de arquitectura las cierran. 

Con eso en mente, iniciemos con una pregunta directa.

Su organización tiene un plan de continuidad del negocio documentado, aprobado y revisado.

¿Pero ese plan contempla qué pasa cuando la red de telecomunicaciones falla primero?

La mayoría no. Y ahí está el problema. Los planes de continuidad han madurado. Hay documentación, runbooks, RTO y RPO (Recovery Point Objective) definidos. Pero casi todos asumen que la red es un canal que simplemente funciona. Ese supuesto (invisible, nunca cuestionado) es exactamente donde empieza la falla.

En operaciones críticas, la red de telecomunicaciones no transporta la operación. Es la operación. Y cuando ese componente cede, con o sin alerta previa, el plan que tanto trabajo costó construir se convierte en papel mojado.

Este artículo no explica cómo hacer un BCP. Explica qué falla cuando ya tiene uno, y por qué la red es el componente que más frecuentemente se subestima en el diseño de resiliencia operativa.

¿Por qué falla un BCP cuando la red de telecomunicaciones no está bien considerada?

En la mayoría de los BCPs que he revisado, la red aparece en un bloque genérico: "infraestructura de comunicaciones". Se documenta la redundancia de ISP (Internet Service Provider), se menciona un enlace de backup, y se asume que eso cubre el frente.

Cuando su plan de continuidad se construye desde las aplicaciones hacia afuera, la resiliencia queda en capas que dependen de un sustrato que nadie controla con el mismo nivel de detalle. Si su ERP (Enterprise Resource Planning) tiene failover automático pero el enlace WAN que lo conecta con la planta no tiene redundancia geográfica real, no lógica, sino física, el failover no sirve de nada.

Tratar la red como soporte tiene consecuencias directas:

→ Los RTO se definen sin considerar los tiempos de reconvergencia de red.

→ Los ejercicios de DR (Disaster Recovery) no incluyen pruebas de conmutación de enlace bajo carga real.

→ Los SLAs con proveedores de conectividad no están alineados con los RTO de negocio.

→ El monitoreo de red opera en silos separados del NOC (Network Operations Center) de aplicaciones.

El resultado: cuando ocurre el incidente, el tiempo real de detección y respuesta en la capa de red duplica o triplica el RTO comprometido.

¿Qué riesgos de red de telecomunicaciones afectan la continuidad operativa?

Ejemplo práctico en una operación minera: Procesamiento en faena. Supervisión SCADA en tiempo real desde la sala de control. Sistemas de gestión centralizada en una sede corporativa a 400 km. 

Su BCP contempla redundancia de servidores, backups diarios, soporte 24/7 con el proveedor de ERP. El plan dice que ante una falla crítica, el sistema puede restaurarse en 4 horas.

Lo que el plan no dice:

→ El enlace principal es fibra con un solo nodo de interconexión en la ciudad intermedia.

→ El enlace de backup es microondas con capacidad insuficiente para soportar tráfico SCADA + gestión de forma simultánea.

→ El SLA del proveedor de red es de 8 horas para diagnóstico. Su RTO es de 4.

→ El NOC no tiene visibilidad sobre el estado del backbone que conecta la faena con la sede corporativa.

Una falla en ese nodo de interconexión, por mantenimiento de terceros, por una obra civil no coordinada, por un equipo que llegó al fin de su vida útil, deja el plan inoperante. No porque los sistemas fallen. Porque no pueden comunicarse.

¿Dónde falla la resiliencia de red de telecomunicaciones?, ¿y por qué?

Falla 1:

La red de telecomunicaciones es la causa número uno de interrupciones de TI y el BCP no lo refleja

Según el Uptime Institute Annual Outage Analysis 2024 [1], los problemas de conectividad y red son la causa acumulada más frecuente de interrupciones de servicios de TI. El director de investigación del Uptime Institute lo resumió sin rodeos: "Si sumamos software de red, configuración y conectividad física de fibra, esa se convierte en la causa número uno." Y sin embargo, en la mayoría de los BCPs la red aparece como un bloque secundario, no como el componente que determina si el plan ejecuta o no.

El 48% de las interrupciones documentadas se originan en fallas procedimentales, no en fallas de hardware. Dicho de otro modo: los sistemas resistieron, pero los procesos, incluidos los procesos de red, fallaron. Eso es exactamente lo que ocurre cuando el equipo de red no participó en la construcción del plan.

Falla 2:

Redundancia lógica ≠ redundancia física

Tener dos proveedores de internet con redes independientes (en términos técnicos: dos ASN distintos con enrutamiento BGP separado) no significa que los cables estén en ductos separados, que los equipos de agregación no compartan alimentación, o que los nodos intermedios sean independientes entre sí.

Casi el 60% de los cortes de fibra son causados por intervenciones de obras civiles como excavaciones, perforaciones, trabajos de construcción [5], sobre ductos compartidos, según estudios de la Comisión Federal de Comunicaciones (FCC) de Estados Unidos. Y dos tercios de esos cortes ocurren incluso cuando el contratista había notificado previamente al propietario de la infraestructura. Sin diversidad de ruta documentada, dos "proveedores diferentes" pueden depender del mismo metro de fibra enterrada bajo la misma calle. [11]

La redundancia efectiva para un plan de continuidad del negocio requiere:

→ Diversidad de ruta física: los enlaces primario y secundario deben recorrer trayectos distintos en el tendido terrestre, verificables en documentación técnica, no solo en contratos.

→ Diversidad de proveedor con acceso propio: no dos ISP que usen el mismo anillo de última milla o el mismo nodo de agregación.

→ Independencia de equipos de borde: CPE o routers en el site remoto, la planta o la subestación que no compartan fuente de poder ni chasis.

→ Pruebas de conmutación bajo carga real: no en ventana de mantenimiento con tráfico mínimo, sino bajo condiciones representativas de operación.

Cuando se producen cortes de fibra, el tiempo medio de reparación física es de 14 horas, con casos que alcanzan las 100 horas. El tiempo medio de interrupción de servicio asociado es de 5.2 horas por incidente. Sin redundancia física real, esas 5 horas son inevitables.

Falla 3:

El RTO del BCP y el SLA de red de telecomunicaciones no conviven en el mismo documento

Un Objetivo de Tiempo de Recuperación (RTO) de 2 horas para sistemas críticos es incompatible con un contrato de conectividad que garantiza respuesta en 4 horas y resolución en 8. Esta inconsistencia existe en la mayoría de operaciones que he auditado. Y casi nunca se detecta hasta que ocurre el incidente.

El problema no es solo contractual. Es de diseño. Si el BCP asume que los sistemas se restauran en 2 horas pero el plan de recuperación de infraestructura soporta un RTO de 12 horas, la organización está haciendo compromisos que no puede cumplir, con implicaciones de cumplimiento regulatorio, violaciones de acuerdos de nivel de servicio con clientes, y daño reputacional. [12]

Los compromisos de la capa de red de telecomunicaciones deben estar subordinados al RTO de negocio, no al revés:

→ Negociar SLAs de red con penalidades y escalaciones alineadas al impacto operativo real.

→ Incluir tiempos de conmutación de enlace en el cálculo de RTO — no solo el tiempo de recuperación de aplicaciones.

→ Definir ventanas máximas de degradación por segmento de red, no solo disponibilidad global.

→ Exigir telemetría en tiempo real como parte del contrato, no como complemento opcional.

Falla 4:

El equipo de operaciones de red de telecomunicaciones (NOC) no participa en los ejercicios de continuidad

Los ejercicios de continuidad típicamente prueban la capa de aplicación: failover de base de datos, restauración de backup, activación de site secundario. El equipo de red suele estar "disponible por si acaso", no integrado en el flujo del ejercicio.

La mayoría de las organizaciones con planes de continuidad documentados los prueban no más de una vez al año. Y un 7% no los prueba en absoluto. Un plan que no se ha probado con la red activa no es un plan, es una hipótesis [6].

Lo que ocurre cuando el equipo de operaciones de red no está en el BCP:

→ El personal de aplicaciones asume conectividad disponible y pierde tiempo en diagnósticos equivocados.

→ No existe priorización de circuitos por impacto de negocio: se reconecta lo que responde primero, no lo que más importa.

→ La coordinación del incidente ocurre por los mismos canales que están fallando.

→ El tiempo real de recuperación duplica o triplica el RTO documentado.

Integrar el equipo de red en los runbooks de BCP no es opcional en operaciones críticas. Es la diferencia entre un plan que funciona y uno que solo funciona cuando todo está bien.

¿Qué decisiones de arquitectura impactan la resiliencia del BCP?

Control vs. dependencia de proveedor

Operar con un único proveedor de conectividad simplifica la gestión y reduce costos operativos. Pero introduce una dependencia que en operaciones críticas es difícil de justificar cuando se hacen los números.

El trade-off real no es costo vs. redundancia.

Es costo de operación normal vs. costo de una hora de inoperatividad

Los números son verificables: el 54% de las interrupciones mayores de infraestructura costaron más de USD 100,000, y casi 1 de cada 5 superó el millón de dólares, según el Uptime Institute 2024. Para medianas y grandes empresas, el costo promedio de una hora de inactividad supera los USD 300,000, según el reporte ITIC 2024 Hourly Cost of Downtime [2], con datos de más de 1,000 empresas en todo el mundo. En manufactura industrial, el reporte True Cost of Downtime 2024 de Siemens sitúa el costo promedio en USD 125,000 por hora — y en sectores como automotriz, alcanza USD 2.3 millones por hora [3].

El delta de costo entre un enlace simple y una arquitectura con redundancia geográfica real se amortiza en minutos de incidente evitado. La decisión no es técnica. Es financiera. Y debe estar documentada en el BCP con los números reales de la operación.

El enlace de backup que no soporta la emergencia

El enlace de backup existe para soportar la carga en caso de falla del primario. En teoría.

En la práctica, muchos están dimensionados para una fracción del tráfico normal, asumiendo que en emergencia solo corren los sistemas "críticos". Esa asunción falla cuando no hay control de tráfico activo (QoS), cuando el personal lanza conexiones VPN adicionales para coordinar la respuesta, cuando las videoconferencias de gestión de crisis consumen el ancho de banda que necesita el sistema de supervisión SCADA.

La regla operativa es simple: el enlace de backup debe soportar el tráfico de misión crítica con margen. No el tráfico total menos lo que "seguramente no va a correr en una emergencia".

¿Qué cambia en arquitectura cuando la red de telecomunicaciones entra al BCP como componente crítico?

Rediseño del acceso

El punto de entrada a la red pública (el acceso) es donde ocurre la mayoría de las fallas con impacto en continuidad. Alinearlo con el BCP implica:

→ Acceso dual con diversidad física: dos proveedores con tendidos independientes hasta el equipo en la planta, el site remoto o la subestación.

→ Interconexión en distintos puntos de presencia (PoPs): no dos accesos que terminan en el mismo nodo de agregación del proveedor.

→ Equipos con failover automático y telemetría activa: no conmutación manual que depende de que alguien detecte la falla.

→ Documentación de rutas físicas: saber exactamente por dónde va el cable, no solo qué proveedor lo opera.

La alta resiliencia dentro de cada red no garantiza automáticamente resiliencia a nivel de sistema, porque las interrupciones ocurrirán. La diversidad y la coordinación, asegurando que las funciones críticas no dependan del mismo punto débil, son cruciales, especialmente cuando todas las redes comparten los mismos puntos únicos de falla. [9]

Red de telecomunicaciones y seguridad: el BCP también cubre ciberincidentes

Los incidentes de ciberseguridad son hoy una de las principales causas de activación de BCPs en sectores críticos. En 2024 se reportaron más de 12,000 incidentes de ciberseguridad relacionados con Sistemas de Control Industrial (ICS) [7]. Los adversarios alineados con estados-nación incrementaron sus ataques sobre sectores de energía, transporte y manufactura en un 49% durante 2024. El 80% de los fabricantes reportó un aumento en incidentes de seguridad en el momento en que integraron recursos de TI empresarial en sus redes de planta.

Estos no son escenarios hipotéticos. Son el contexto operativo actual.

El plan de continuidad del negocio moderno debe contemplar la intersección de disponibilidad y seguridad:

→ Segmentación de redes OT/IT con puntos de control: no solo por cumplimiento normativo, sino para contener el radio de impacto de un incidente. Aproximadamente el 70% de los ataques que impactan operaciones OT se originan en entornos IT y progresan a través de sistemas de identidad compartidos y rutas de acceso remoto. [8]

→ Rutas de comunicación fuera de banda: para operar el equipo de operaciones de red y coordinar respuesta cuando la red principal está comprometida.

→ Procedimientos de aislamiento controlado: cómo desconectar segmentos afectados sin detener lo que no lo está.

→ Plan de respuesta a ransomware específico para OT: el ransomware en entornos industriales ha evolucionado, los actores entienden los puntos de dolor de producción y actúan en consecuencia. El BCP debe contemplar la contención, la preservación de evidencia y la restauración validada antes de reconectar.

Monitoreo orientado a continuidad, no a operación normal

El monitoreo de red tradicional reporta disponibilidad de interfaz y utilización de ancho de banda. Para un BCP, esos indicadores son insuficientes. El 90% de las organizaciones experimentó tiempo de inactividad en el último año. La pregunta no es si ocurrirá, es cuánto tiempo pasará antes de que alguien lo detecte.

Lo que necesita monitoreo activo en operaciones críticas:

→ Latencia y jitter en rutas de aplicación críticas: no solo conectividad, sino calidad de la ruta que usan los sistemas que importan.

→ Estado de los enlaces de backup: saber que están operativos antes de necesitarlos, no descubrirlo durante el incidente.

→ Alertas tempranas de degradación: anomalías en pérdida de paquetes que preceden fallas completas — la degradación avisa antes de la caída total.

→ Trazabilidad de cambios en topología de red: saber cuándo cambió una ruta de enrutamiento antes de que eso genere un incidente.

¿Cómo puede ayudarte InterNexa? 

InterNexa opera la mayor red de fibra óptica de América Latina con presencia en Colombia, Perú, Chile, Brasil y Argentina. En operaciones críticas de los sectores minero-energético y de infraestructura, trabajamos en cuatro frentes concretos:

→ Validación de diversidad física de rutas: documentamos el trayecto real de sus enlaces actuales e identificamos puntos únicos de falla que el BCP no está contemplando.

→ Alineación de SLAs con RTO/RPO de negocio: cruzamos sus compromisos operativos con los tiempos reales de respuesta de su infraestructura de red e identificamos las brechas contractuales que hacen inalcanzable el RTO documentado.

→ Diseño de arquitecturas redundantes para sites remotos: conectividad con redundancia geográfica real para plantas, faenas, subestaciones y sites remotos.

→ Monitoreo y observabilidad de enlaces críticos: telemetría activa sobre sus rutas de misión crítica, integrada al NOC de su operación.

Preguntas frecuentes

¿Cuántos proveedores de conectividad necesita una operación crítica?

No es un número: es una condición. Lo que define la resiliencia es si los accesos son físicamente independientes. Dos proveedores que comparten tendido de última milla no aportan redundancia real. En operaciones de alta criticidad, lo mínimo es acceso primario con SLA robusto y backup con diversidad física documentada. En sitios con impacto muy alto, se justifican tres rutas con proveedores y trayectos independientes.

¿Cómo sé si mi RTO es compatible con los SLAs de mi proveedor de red?

Cruce los tiempos. Si su RTO para sistemas críticos es 2 horas, los SLAs de conectividad (tiempo de respuesta + tiempo de resolución) deben sumar menos que ese valor, con margen para actividades de recuperación en capa de aplicación. Si no es así, el RTO documentado no es alcanzable. El BCP necesita reflejar el RTO real, no el deseado.

¿Vale la pena hacer pruebas de conmutación de enlace en producción?

Sí, y con más frecuencia de la habitual. Las pruebas en ventanas de bajo tráfico no validan el comportamiento real. Lo que se prueba debe incluir conmutación bajo carga representativa, verificación de reconexión automática de sistemas críticos, y medición del tiempo real de degradación durante la transición. Un plan no probado con la red activa es una hipótesis, no un plan.

¿Qué diferencia hay entre BCP y plan de recuperación ante desastres (DR)?

El DR recupera sistemas y datos después de un evento. El BCP cubre continuidad operativa en un espectro más amplio: procesos, personas e infraestructura. La red cruza ambos. Un DR sin red funcional es inejecutable. Un BCP sin continuidad de red tiene un punto ciego crítico. Al incorporar la red explícitamente, los tiempos, las dependencias y los procedimientos de red entran en el plan con el mismo nivel de detalle que los sistemas de aplicación.

¿Cuándo se justifica económicamente invertir en redundancia de red?

El análisis es directo: costo anual de la redundancia vs. costo esperado de un incidente (probabilidad × duración media × costo por hora). Con un costo promedio verificado de más de USD 300,000 por hora de inactividad para medianas y grandes empresas, y probabilidades históricas de 2 a 3 incidentes de red por año con duración media de 3 a 5 horas, la matemática favorece la redundancia en casi cualquier operación crítica. La dificultad no es el cálculo. Es que casi nunca se ha hecho con los números reales de la operación. [10]

¿Qué revisar primero para auditar la resiliencia de red de telecomunicaciones en mi BCP?

Tres puntos de inicio: verificar si existe documentación de rutas físicas de los enlaces actuales — no solo contratos, sino el trayecto real del cable. Cruzar SLAs de conectividad con los RTOs del BCP e identificar brechas. Revisar la última prueba de conmutación de enlace documentada: cuándo fue, bajo qué condiciones, qué sistemas validaron reconexión automática. Esas tres revisiones suelen exponer el estado real de resiliencia de red en menos de una jornada.

Revíselo. Audítelo. Alineelo.

La mayoría de las operaciones críticas no necesitan más herramientas ni más capas de redundancia antes de haber cerrado las brechas que ya existen.

El trabajo inmediato es de arquitectura y proceso.

Antes de la próxima revisión del BCP, tres preguntas que valen más que cualquier herramienta:

→ ¿Están documentadas las rutas físicas de sus enlaces críticos — no solo los contratos, sino el trayecto real del cable?

→ ¿Sus SLAs de conectividad son compatibles con sus RTOs de negocio?

→ ¿Cuándo fue la última prueba de conmutación de enlace bajo carga real?

Si alguna respuesta es "no sé" o "hace más de un año", el punto de quiebre ya está identificado.

Un plan de continuidad del negocio que asume que la red funciona no es un plan. Es una lista de pasos que solo aplican cuando todo está bien.

Y eso, en operaciones críticas, es exactamente la condición que el plan debería cubrir.

Referencias

1. Uptime Institute — Annual Outage Analysis 2024. Causas de interrupciones de servicios de TI; costo de interrupciones mayores; disponibilidad requerida por organizaciones. https://uptimeinstitute.com/resources/research-and-reports
2. ITIC — 2024 Hourly Cost of Downtime Survey. El costo de una hora de inactividad supera los USD 300,000 para el 90% de medianas y grandes empresas. https://itic-corp.com/itic-2024-hourly-cost-of-downtime-report/
3. Siemens — True Cost of Downtime 2024. Las 500 empresas más grandes del mundo pierden USD 1.4 billones anuales por inactividad no planificada; costo promedio en manufactura industrial: USD 125,000/hora; en automotriz: USD 2.3 millones/hora. https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf
4. Invenio IT — 2024 Disaster Recovery Statistics. Los problemas de red o conectividad fueron la causa más común de interrupciones de servicios de TI en los últimos tres años. Las fallas de software causan el 53% del tiempo de inactividad no planificado; los cortes de red, el 50%. https://invenioit.com/continuity/2017-disaster-recovery-statistics/
5. Wayne Grover — Mesh-Based Survivable Transport Networks (InformIT / FCC Survey Data). Casi el 60% de los cortes de fibra son causados por obras civiles sobre ductos compartidos. Tiempo medio de reparación física: 14 horas. Tiempo medio de interrupción de servicio: 5.2 horas por incidente. https://www.informit.com/articles/article.aspx?p=169456
6. SentinelOne — RTO vs RPO: Key Differences in Disaster Recovery Planning (2026). El 48% de las interrupciones documentadas se originan en fallas procedimentales. El NIST Cybersecurity Framework 2.0 (febrero 2024) posiciona RTO y RPO como componentes requeridos dentro de la función de recuperación. https://www.sentinelone.com/cybersecurity-101/cloud-security/rto-vs-rpo/
7. Industrial Cyber — Rising ICS Incidents Drive Shift from Reactive Risk Models (2026). Más de 12,000 incidentes de ciberseguridad relacionados con ICS reportados en 2024. Incremento del 49% en ataques de adversarios alineados con estados-nación sobre energía, transporte y manufactura. El 80% de los fabricantes reportó aumento en incidentes tras integrar recursos IT en redes de planta. https://industrialcyber.co/threats-attacks/rising-ics-incidents-drive-shift-from-reactive-risk-models-to-intelligence-driven-ot-security-strategies/
8. Palo Alto Networks Unit 42 — Bring the Fight to the Edge: OT Security (2026). Aproximadamente el 70% de los ataques que impactan operaciones OT se originan en entornos IT y progresan a través de sistemas de identidad compartidos y rutas de acceso remoto. https://unit42.paloaltonetworks.com/ot-edge-security/
9. ScienceDirect — Beyond Infrastructure: Internet Ecosystem Resilience and the Public Good (2025). La alta resiliencia dentro de cada red no garantiza automáticamente resiliencia a nivel de sistema. La diversidad y la coordinación son cruciales cuando todas las redes comparten los mismos puntos únicos de falla (e.g., una ruta de cable crítica o un clúster de datacenter). https://www.sciencedirect.com/science/article/pii/S0308596125000953
10. WIN Technology — Business Continuity Planning Guide. El 75% de las organizaciones sin un plan de continuidad fallan dentro de los tres años siguientes a un desastre mayor. Una hora de inactividad puede costar desde USD 10,000 para pequeñas empresas hasta más de USD 5 millones para empresas grandes. https://www.wintechnology.com/blog/business-continuity-plans-25-of-companies-do-not-re-open-after-a-disaster-is-your-organization-prepared-business-continuity-plans/
11. Cloudflare — Q1 2024 Internet Disruption Summary. Análisis de interrupciones globales de red por cortes de fibra, mantenimiento no coordinado y ataques físicos a infraestructura de comunicaciones. https://blog.cloudflare.com/q1-2024-internet-disruption-summary/
12. Stonefly — Business Continuity vs. Disaster Recovery: Unified BC/DR Strategy (2025). Si el BCP asume restauración en 2 horas pero el DR soporta un RTO de 12 horas, la organización hace compromisos incumplibles — con implicaciones de cumplimiento, violaciones de SLA y daño reputacional. https://stonefly.com/blog/business-continuity-vs-disaster-recovery-unified-bc-dr-strategy/