El reporte de ciberseguridad del trimestre muestra: 2,347 alertas procesadas, 98.3% de cobertura de antivirus, 14 vulnerabilidades críticas pendientes de parche, tiempo medio de detección de 4.2 horas. El consejo escucha. Asiente. Aprueba el punto del orden del día. Nadie hace preguntas.
Eso no es una buena señal. Es una señal de que nadie entendió nada.
El problema con las métricas técnicas ante el consejo
Las métricas técnicas son útiles para el equipo operativo de seguridad. Permiten monitorear el desempeño de los controles, identificar tendencias y tomar decisiones tácticas. Para eso fueron diseñadas. El problema ocurre cuando esas mismas métricas se presentan al consejo de administración como si fueran el lenguaje correcto para esa audiencia.
Un consejero de administración no necesita saber cuántas alertas procesó el SOC el trimestre pasado. Necesita saber si la organización está más o menos expuesta que hace tres meses, qué eventos podrían interrumpir la operación, cuánto costaría un incidente mayor y si el nivel de inversión actual es proporcional al riesgo que enfrenta la empresa. Esas son preguntas de negocio. Y tienen respuestas si el CISO sabe cómo formularlas.
Las métricas que los consejos sí entienden
La primera categoría es la exposición financiera estimada. No el costo de las herramientas de seguridad: el costo potencial de un incidente. ¿Cuánto costaría a la organización una brecha que afecte a sus sistemas de facturación durante 48 horas? ¿Qué impacto financiero tendría la exposición de los datos de sus clientes? IBM Security estima que el costo promedio global de una brecha de datos supera los 4.8 millones de dólares en 2024. Esa cifra, contextualizada para el tamaño y el sector de la organización, es el punto de partida para una conversación de inversión que el consejo puede seguir.
La segunda categoría es el estado de los riesgos más críticos, no el estado de todos los controles. En lugar de reportar el porcentaje de vulnerabilidades parcheadas en toda la infraestructura, reportar el estado de los tres o cuatro riesgos de mayor impacto para el negocio. ¿El sistema de nómina tiene controles de acceso adecuados? ¿Los datos de clientes están protegidos con los controles que exige la regulación? ¿Existe un plan de continuidad probado para los procesos que no pueden detenerse? Eso es lo que importa al consejo.
La tercera categoría es la postura de riesgo en el tiempo. No una fotografía estática, sino una tendencia. ¿Estamos mejor o peor posicionados que hace seis meses? ¿Qué eventos o decisiones movieron esa aguja? Un consejo que ve la postura de riesgo mejorar consistentemente confía en el programa. Uno que recibe el mismo reporte cada trimestre sin saber si algo cambia no tiene herramientas para tomar decisiones.
La estructura de un reporte que funciona
Un reporte de ciberseguridad para el consejo no necesita más de cinco diapositivas o su equivalente en papel. La primera: el estado de la postura de riesgo en una escala simple —mejor, igual o peor que el período anterior— con las razones principales. La segunda: los tres riesgos de mayor impacto para el negocio y su estado actual. La tercera: el evento de seguridad más significativo del período, qué ocurrió, cómo se respondió y qué se cambió. La cuarta: la inversión del período y el riesgo que esa inversión mitigó, en términos financieros estimados. La quinta: la solicitud o decisión que el CISO necesita del consejo.
Esa última diapositiva es la que más se omite. Un reporte sin una solicitud clara convierte al consejo en audiencia pasiva. El consejo que aprueba presupuesto, autoriza cambios de política o respalda iniciativas de seguridad es el que recibe preguntas concretas que puede responder con sí o no.
¿Tu próximo reporte de ciberseguridad al consejo tiene una diapositiva que diga explícitamente qué necesitas de ellos y por qué?
Acciones inmediatas
- Revisa el último reporte de ciberseguridad que presentaste al consejo y cuenta cuántas métricas son técnicas y cuántas son de negocio. Si la mayoría son técnicas, ese es el diagnóstico. No hace falta eliminarlas todas: hace falta añadir una capa de traducción que conecte cada métrica técnica con el riesgo de negocio que representa.
- Calcula una estimación del costo potencial de un incidente mayor para tu organización específica. Usa como referencia el costo promedio de tu industria y ajusta por el tamaño de tu organización y el tipo de datos que maneja. Esa cifra, aunque sea una estimación de orden de magnitud, es el argumento más efectivo para justificar inversión en ciberseguridad ante un consejo que piensa en términos financieros.
- Reduce los riesgos que reportas al consejo a los tres de mayor impacto potencial para el negocio. No el ranking de todos los riesgos del programa: los tres que, si se materializan, tendrían consecuencias que el consejo reconocería como graves. Esa priorización fuerza al CISO a pensar en impacto de negocio antes de hablar con el consejo.
- Incluye en tu próximo reporte una diapositiva o sección explícita con lo que necesitas del consejo. Aprobación de presupuesto, respaldo para un cambio de política, mandato para que las áreas de negocio participen en ciertos procesos. El consejo que no recibe una pregunta concreta no tiene forma de ayudar aunque quiera.
- Diseña un indicador de postura de riesgo trimestral que puedas actualizar y comparar en el tiempo. Puede ser tan simple como un semáforo con tres dimensiones —amenaza externa, riesgo interno, cumplimiento regulatorio— calificadas como alto, medio o bajo. Lo que importa no es la sofisticación del modelo sino la consistencia: el consejo que ve el mismo indicador trimestre tras trimestre aprende a interpretarlo y a hacer preguntas relevantes.
Si tu organización quiere diseñar un modelo de reporte de ciberseguridad al consejo directivo que genere comprensión real y decisiones concretas, contáctanos en https://tbsek.mx/contacto/.
