La seguridad dentro de la estrategia

El punto de partida de la gobernanza no es el riesgo, es el negocio. NIST CSF 2.0 lo pone en GV.OC-01: la misión de la organización se entiende y orienta la gestión del riesgo cibernético; y en GV.RM-03 pide que las actividades de riesgo cibernético formen parte de la gestión de riesgos de toda la empresa. Traducido: cada objetivo estratégico trae consigo requisitos de seguridad, y es mejor descubrirlos al planear que a la hora de lanzar.

Un directivo que dice «queremos exportar a un mercado nuevo» debería oír de inmediato «¿qué exige ese cliente de seguridad y cuándo lo necesitamos?».

Un plan de seguridad que no se puede ligar a un objetivo del negocio compite mal por presupuesto, y con razón: nadie sabe qué se pierde si no se hace. La prueba es sencilla. Cada iniciativa del área debe habilitar un objetivo, reducir un riesgo que amenaza uno, o cumplir una obligación. Si no hace ninguna de las tres cosas, o está mal explicada o sobra.

La consola tiene el plan estratégico y las iniciativas del área de seguridad con el objetivo que dice habilitar cada una.

Para cada objetivo, el área de seguridad identificó requisitos con la fecha en que tienen que estar listos y la fecha en que se prevé tenerlos. Si la fecha prevista es posterior a la requerida, el objetivo de negocio se retrasa o sale sin el requisito. Es el tipo de cosa que un directivo debe ver antes del lanzamiento, no el día del lanzamiento.

Cuando el requisito llega tarde, hay dos formas de decirlo. Una dice «no se puede lanzar hasta que seguridad lo apruebe», que pone al área como obstáculo y la convierte en la última en enterarse. La otra pone en la mesa la fecha, la causa del retraso y las opciones: recursos adicionales, un alcance menor para el lanzamiento o un riesgo aceptado con plazo y firma. La segunda deja la decisión donde debe estar: en quien responde por el objetivo.