Hay una escena que se repite en muchas juntas directivas de la región: el CISO entra con una presentación cuidadosamente preparada, llena de indicadores técnicos, y hacia el minuto tres nota que ya perdió a la mitad de la sala. No porque el riesgo no importe. Porque nadie en esa mesa tomó una decisión de negocio evaluando vulnerabilidades, superficies de ataque o tiempos de detección. Evaluaron ingresos, márgenes, continuidad operativa y reputación. Si el riesgo cibernético no se traduce a esas mismas categorías, simplemente no entra al criterio de decisión del consejo, sin importar qué tan grave sea en realidad.
Esto no es un problema de comunicación en el sentido superficial —no se trata de "simplificar" o "usar menos palabras técnicas". Es un problema de traducción de marco de referencia: el consejo directivo piensa en riesgo de negocio, y el CISO, por formación y por costumbre, piensa en riesgo técnico. Son dos lenguajes distintos que describen la misma realidad desde ángulos diferentes, y la responsabilidad de traducir entre ambos recae, casi siempre, en la misma persona que está presentando.
Por qué el lenguaje técnico pierde al consejo antes de convencerlo
Un consejo directivo no está compuesto por especialistas en seguridad, y no debería tener que serlo para tomar una buena decisión. Su trabajo es evaluar riesgo, asignar capital y proteger la continuidad del negocio. Cuando una presentación de ciberseguridad se estructura alrededor de términos técnicos —número de incidentes, tipos de amenaza, arquitectura de controles— el consejo no tiene manera de conectar esa información con las decisiones que sí sabe tomar: cuánto invertir, qué tan urgente es, qué pasa si no se actúa.
El resultado es previsible: la conversación se percibe como un reporte de estado más que como una decisión que requiere su participación activa. El consejo asiente, agradece la actualización, y sigue adelante sin haber comprometido presupuesto ni prioridad real. No porque no les importe la seguridad, sino porque nunca se les presentó como algo sobre lo que ellos, específicamente, tuvieran que decidir.
Traducir el riesgo a las categorías que el consejo ya usa para decidir
La alternativa no es ocultar la complejidad técnica, sino traducirla a las variables que un consejo directivo ya sabe evaluar: impacto financiero potencial, probabilidad de ocurrencia, tiempo de recuperación, y efecto sobre la continuidad operativa o la reputación de la marca. Un incidente de ransomware, por ejemplo, deja de ser una amenaza técnica abstracta y se convierte en una pregunta muy concreta: ¿cuántos días de operación se perderían, y qué representa eso en ingresos no generados o en costos de recuperación?
Esta traducción obliga al CISO a hacer un trabajo previo que muchas veces se salta: cuantificar, aunque sea de forma aproximada, el impacto de negocio de cada escenario de riesgo antes de entrar a la sala. No se trata de tener cifras perfectas —la incertidumbre es parte legítima de cualquier análisis de riesgo— sino de presentar un rango razonable que le dé al consejo algo con qué comparar frente a otras decisiones de inversión que sí conocen bien.
Priorizar como lo haría el consejo, no como lo haría un analista de seguridad
Un error común es presentar el riesgo cibernético como una lista plana de hallazgos técnicos, todos con aparente urgencia similar. El consejo directivo, en cambio, está entrenado para pensar en priorización: qué riesgo atender primero dado un presupuesto limitado y un tiempo limitado. Estructurar la presentación alrededor de esa misma lógica —qué riesgo tiene mayor impacto potencial combinado con mayor probabilidad, y por lo tanto merece atención inmediata— hace que la conversación se sienta familiar en lugar de ajena.
Esto también cambia el rol del CISO dentro de la sala. Deja de ser la persona que reporta problemas técnicos y se convierte en quien ayuda al consejo a decidir dónde poner el capital de riesgo de la organización. Es una diferencia sutil en la forma, pero profunda en el resultado: una es una actualización de estado: la otra es una recomendación de negocio con la que el consejo puede estar de acuerdo, en desacuerdo, o pedir más información — pero sobre la cual sí puede actuar.
Lo que el consejo directivo realmente necesita escuchar
En el fondo, un consejo directivo no necesita saber cómo funciona un ataque de phishing o qué es un movimiento lateral dentro de una red. Necesita saber si la organización está expuesta a un riesgo que podría afectar su continuidad, cuánto costaría ese riesgo si se materializa, y qué tan preparada está la organización para responder si ocurre. Todo lo demás es contexto de apoyo, no el mensaje central.
Presentar el riesgo cibernético en esos términos no es "bajarle el nivel" a la conversación. Es reconocerla por lo que realmente es: una decisión de negocio más, con las mismas categorías de evaluación que cualquier otra que el consejo ya sabe tomar. Cuando el CISO logra esa traducción, deja de perder a la sala en el primer minuto —y empieza a ganar algo más valioso que atención: una decisión.
