Una organización que presta un servicio esencial no puede medir su seguridad únicamente por la ausencia de incidentes. También debe preguntarse cuánto tardaría en detectar una anomalía, quién tomaría decisiones durante una crisis y qué procesos podrían mantenerse mientras se recuperan los sistemas afectados. Esa es la diferencia entre instalar controles aislados y construir ciberresiliencia empresarial en Colombia.
La Estrategia Nacional de Seguridad Digital de Colombia 2025-2027 sitúa la gestión de riesgos, la respuesta a incidentes, la protección de infraestructuras críticas y los servicios esenciales dentro de un marco nacional de seguridad digital. El documento también plantea objetivos relacionados con gobernanza, capacidades, innovación, protección de datos y apoyo a pequeñas y medianas empresas.[1] Para dirección, esto significa traducir el riesgo digital en decisiones operativas verificables.
El problema empresarial: detectar no equivale a resistir
Un servicio esencial puede depender de aplicaciones, redes, identidades, proveedores, centros de datos, dispositivos remotos y personal con funciones muy distintas. Cuando uno de esos componentes falla o es comprometido, el impacto no se limita al área de TI: puede afectar la atención al usuario, la seguridad operacional, los ingresos, las obligaciones contractuales y la confianza.
Un sistema que genera alertas pero no tiene responsables definidos puede producir información sin respuesta. Del mismo modo, un plan de continuidad que no considera las dependencias de red o las cuentas privilegiadas puede funcionar en papel y fallar durante una interrupción real. Por eso, la primera decisión no debería ser “¿qué herramienta implementamos?”, sino “¿qué resultado operativo debemos proteger y qué evidencia demostraría que estamos preparados?”.
Un marco de evaluación para la ciberresiliencia
La evaluación puede organizarse en cuatro capacidades conectadas. No se trata de calificarlas con una cifra artificial, sino de identificar brechas que impidan detectar, coordinar, contener o recuperar.
| Capacidad | Pregunta de decisión | Evidencia esperada |
|---|---|---|
| Detección | ¿Podemos identificar una actividad anómala a tiempo? | Fuentes de eventos priorizadas, alertas revisadas y criterios de escalamiento. |
| Coordinación | ¿Quién decide y comunica durante el incidente? | Roles, contactos, matriz de severidad y procedimiento probado. |
| Continuidad | ¿Qué operación debe mantenerse o restablecerse primero? | Servicios priorizados, dependencias documentadas y alternativas operativas. |
| Aprendizaje | ¿Cómo evitamos repetir la misma debilidad? | Análisis posterior, acciones correctivas y seguimiento con responsables. |
Detección: priorizar señales útiles, no acumular datos
La detección debe empezar por los activos y procesos que sostienen el servicio. Antes de incorporar más fuentes, conviene establecer qué eventos son relevantes: accesos privilegiados, cambios de configuración, actividad inusual en sistemas críticos, fallas repetidas, conexiones no autorizadas o patrones que indiquen compromiso de una cuenta.
Un servicio de SIEM as a Service puede apoyar la centralización y el análisis de eventos, pero su valor depende de la calidad de las fuentes, las reglas de correlación, la revisión de alertas y la capacidad de escalar un caso. La organización debe pedir claridad sobre qué se monitorea, qué queda fuera, cómo se documentan los casos y qué participación conserva su propio equipo.
La pregunta práctica es si una alerta puede convertirse en una acción: aislar un equipo, bloquear una cuenta, validar un cambio o activar una ruta de continuidad. Sin esa conexión, la visibilidad adicional puede aumentar el trabajo sin reducir el tiempo de respuesta.
Coordinación: gobernar la respuesta antes de la crisis
Los incidentes suelen cruzar fronteras internas. Un equipo puede observar la señal, otro administrar la infraestructura, otro gestionar comunicaciones y la dirección decidir sobre la continuidad del servicio. Sin una coordinación predefinida, las primeras horas se consumen buscando autorizaciones, confirmando responsabilidades o discutiendo la gravedad del evento.
La evaluación debe comprobar si están definidos el responsable de incidentes, los suplentes, los criterios de escalamiento, la preservación de evidencias, la comunicación con terceros y las condiciones para volver a operar. Conviene ensayar escenarios con negocio: una cuenta privilegiada comprometida, una aplicación crítica indisponible o un proveedor afectado.
Un servicio de gestión integral MSSP, NOC y SOC puede aportar capacidades operativas y coordinación especializada, pero la empresa debe conservar la decisión sobre prioridades, tolerancia al riesgo y comunicación institucional. La externalización de monitoreo no sustituye la gobernanza del servicio esencial.
Continuidad: recuperar el servicio, no solo los servidores
La continuidad requiere ordenar dependencias. Para cada servicio prioritario, la organización debería documentar qué aplicaciones lo soportan, qué conectividad necesita, qué identidades permiten operarlo, qué proveedores intervienen y qué procedimiento existe si alguno queda indisponible.
Debe distinguirse entre recuperación técnica y continuidad de negocio: restaurar una plataforma no garantiza que el personal pueda trabajar, que los datos sean consistentes o que exista un canal alternativo. Las pruebas deben incluir decisiones y comunicación.
Checklist ejecutivo de evaluación
- Identificar los servicios cuya interrupción tendría mayor impacto.
- Mapear activos, proveedores y dependencias de cada servicio prioritario.
- Definir eventos que requieren atención inmediata y quién los recibe.
- Establecer responsables, suplentes y autoridad de escalamiento.
- Probar al menos un escenario de indisponibilidad y uno de compromiso de identidad.
- Registrar tiempos, decisiones pendientes y acciones correctivas.
- Revisar el resultado con dirección, operaciones, TI, seguridad y proveedores.
Escenarios para decidir el siguiente paso
Una entidad con alertas abundantes pero sin análisis consistente probablemente necesita ordenar fuentes, casos de uso y responsabilidades antes de ampliar la cobertura. Una empresa que detecta incidentes pero depende de una sola persona para responder debe priorizar procedimientos, suplencias y ejercicios. Y una organización con monitoreo y respuesta definidos, pero con servicios críticos sin dependencias documentadas, debe cerrar la brecha de continuidad.
Comprar tecnología primero puede ocultar el problema. El criterio debe ser la capacidad que se desea mejorar, su integración y la evidencia de avance.
Próximos pasos para dirección y TI
Primero, acuerde qué servicios son esenciales y quién responde por ellos. Después, diagnostique detección, coordinación y continuidad, y convierta los hallazgos en un plan con responsables, fechas, pruebas y revisión ejecutiva.
La ciberresiliencia no es una promesa de invulnerabilidad. Es una disciplina para reducir el tiempo de desconocimiento, limitar el impacto, tomar decisiones coordinadas y recuperar servicios con aprendizaje posterior.
Si necesita revisar el escenario de su organización en Colombia, puede contactar a Ovnicom para conversar sobre sus capacidades actuales, dependencias y prioridades de continuidad.