Cómo hacer un análisis de riesgos que dirección entienda

La mayoría de los informes de riesgos acaban en un cajón por la misma razón: están escritos para el equipo técnico. Hablan de CVSS, de superficie de ataque y de controles compensatorios, cuando quien aprueba el presupuesto solo necesita saber tres cosas: qué parte del negocio está expuesta, qué ocurre si falla y cuánto cuesta reducir esa exposición. Un análisis de riesgos de ciberseguridad que dirección entienda se construye en ese orden, del negocio hacia la tecnología, y cabe resumido en una página.

Empieza por lo que la empresa no puede permitirse perder

Antes de mirar un solo servidor, escribe la lista de cosas que pararían tu facturación si desaparecieran mañana. En una pyme de 10 a 50 empleados esa lista es corta y suele caber en media página: el ERP o el programa de gestión, el correo electrónico, el sistema de pedidos o la tienda online, los ficheros compartidos donde vive el trabajo en curso, y el acceso a la banca electrónica.

Añade después los datos personales que tratas: clientes, empleados, candidatos y proveedores. Cuando hay datos personales de por medio, un incidente deja de ser solo un problema operativo y adquiere plazos legales. El artículo 33 del RGPD obliga a notificar a la autoridad de control en un plazo de 72 horas desde que se conoce la brecha, y ese reloj corre igual tengas o no un inventario preparado.

Este primer paso es el que más gente se salta y el que más tiempo ahorra después. Sin él, el análisis se convierte en una lista de tecnología sin prioridades.

Convierte las amenazas en escenarios que se puedan discutir

«Riesgo de ransomware» es una etiqueta que nadie puede debatir en una reunión de dirección. «Un empleado abre un adjunto, se cifran los ficheros compartidos y el ERP, y dejamos de facturar durante varios días» sí se puede debatir, porque describe el recorrido completo: por dónde entra, hasta dónde llega y qué deja de funcionar.

Para una pyme española, cuatro o cinco escenarios cubren casi toda la realidad:

• Ransomware que cifra los ficheros compartidos y detiene la operación.
• Fraude del CEO o suplantación de un proveedor que desvía una transferencia.
• Robo de credenciales del correo corporativo y acceso a las conversaciones con clientes.
• Caída prolongada de un proveedor cloud del que depende tu operación diaria.
• Fuga de datos personales desde una aplicación accesible desde internet.

Cada escenario se describe en dos o tres frases. Si necesitas más, probablemente estás mezclando dos escenarios distintos y conviene separarlos.

Mide el impacto en euros y en días

Una matriz de colores comunica poco a quien lleva las cuentas. El impacto se entiende cuando se expresa en las mismas unidades que el resto de decisiones de la empresa. Para cada escenario, estima:

• Días probables de parada, multiplicados por tu facturación media diaria.
• Horas de tu equipo desviadas a resolver el incidente, por su coste por hora.
• Coste de ayuda externa de urgencia y de reconstrucción de sistemas.
• Clientes o contratos en riesgo, con su facturación anual.
• Trabajo legal y de notificación si hay datos personales afectados.

Ninguna de esas cifras necesita una estadística de mercado. Salen de tu propia contabilidad y de tu propio calendario, y por eso resisten bien las preguntas incómodas en una reunión. Un número imperfecto salido de tus datos convence más que un porcentaje impecable sacado de un informe ajeno.

Estima la probabilidad con evidencias

La segunda mitad del cálculo es cuán expuesto estás hoy a cada escenario. Aquí entra el trabajo técnico, y conviene apoyarlo en observaciones reales: qué servicios tuyos son accesibles desde internet y con qué versiones, qué cuentas carecen de segundo factor, cuántos usuarios tienen permisos de administrador que ya no necesitan, si las copias de seguridad se han restaurado alguna vez de verdad, y qué pasa con los accesos de una persona el día que se va de la empresa.

Una gestión de vulnerabilidades con ciclos regulares aporta exactamente esa evidencia y la mantiene fresca. Sin ella, la columna de probabilidad se rellena por intuición y el análisis pierde autoridad justo donde más la necesita.

De la matriz al plan: quién hace qué y cuándo

Un análisis que termina en una lista ordenada de riesgos está a medias. La parte que dirección aprueba viene después, y cabe en cuatro columnas: riesgo, medida que lo reduce, responsable con nombre y apellidos, plazo y coste. Sin responsable y sin fecha, una medida es una intención.

Decide también, de forma explícita, qué riesgos aceptas. Aceptar un riesgo con fecha y con la firma de quien lo asume es una decisión de gestión perfectamente válida, y deja constancia de que se valoró. Los riesgos que nadie menciona son los que reaparecen en mitad de un incidente.

Cómo se presenta en una página

La versión para dirección tiene una tabla mental sencilla: los cinco escenarios, el impacto estimado en euros y días, cuán expuestos estamos hoy, la medida propuesta y su coste. El informe técnico completo va detrás como anexo, para quien tenga que ejecutarlo.

Esa página es también la que responde a los cuestionarios de seguridad que llegan de clientes grandes. Cuando alguien pregunta si tienes un análisis de riesgos formal y con qué frecuencia lo revisas, la respuesta está lista.

Cada cuánto se repite

Un análisis de riesgos envejece con la empresa. Lo razonable es una revisión completa al año y una actualización puntual cada vez que cambia algo relevante: un ERP nuevo, una sede nueva, un proveedor crítico distinto, una línea de negocio o un cliente grande que empieza a enviarte cuestionarios.

Ese último caso es cada vez más frecuente. La directiva NIS2 alcanza a entidades medianas y grandes de determinados sectores, así que una pyme de 10 a 50 empleados queda casi siempre fuera del ámbito directo. Sus clientes grandes sí están dentro, y trasladan requisitos hacia abajo por contrato y por cuestionario. Llegar con el análisis hecho convierte esa conversación en un trámite.

Si prefieres partir de una metodología ya montada en lugar de construirla desde cero, nuestro servicio de análisis de riesgos de ciberseguridad produce ese documento de una página con su anexo técnico, y una auditoría de seguridad informática aporta la evidencia técnica que sostiene la columna de probabilidad.