Una transferencia fraudulenta, una indisponibilidad prolongada de la banca digital o la filtración de datos de clientes no son riesgos equivalentes, aunque todos tengan origen tecnológico. Un ejemplo de matriz de riesgo cibernético permite a una entidad financiera ordenar estas exposiciones con un criterio común: qué puede ocurrir, con qué probabilidad, qué daño causaría y qué decisión debe tomarse antes de que el incidente afecte a la operación, al cumplimiento o a la confianza del mercado.

Para un banco, una fintech o una entidad de crédito, la matriz no debe ser un documento estático preparado para una auditoría. Debe convertirse en una herramienta de gobierno que conecte ciberseguridad, continuidad de negocio, fraude, proveedores, protección de datos y gestión de riesgos operacionales. Su valor está en facilitar decisiones defendibles: dónde invertir, qué controles reforzar, qué riesgos aceptar temporalmente y qué escenarios deben escalarse a dirección.

Qué debe medir una matriz de riesgo cibernético

La matriz cruza habitualmente dos variables: probabilidad e impacto. La probabilidad estima la posibilidad real de que un escenario se materialice durante un periodo definido. El impacto representa las consecuencias para la entidad si ocurre. Multiplicar ambas escalas ofrece una puntuación que ayuda a priorizar, pero no sustituye el juicio experto.

En el sector financiero, el impacto no puede limitarse al coste técnico de recuperar sistemas. Debe considerar la pérdida económica directa, la interrupción de servicios críticos, el fraude, las obligaciones regulatorias, la exposición de datos personales, los costes de notificación, el daño reputacional y los posibles efectos sobre terceros. Un ataque con impacto técnico moderado puede ser crítico si impide a clientes acceder a sus fondos o si afecta a un proceso de pagos sensible al tiempo.

También conviene diferenciar entre riesgo inherente y riesgo residual. El inherente se valora antes de considerar los controles existentes. El residual refleja la exposición que permanece después de aplicar medidas como autenticación multifactor, segmentación de red, monitorización, copias de seguridad verificadas o revisión de proveedores. Esta distinción evita dos errores frecuentes: sobrevalorar un control que no se ha probado y asumir que una política documentada reduce por sí sola el riesgo.

Escala práctica de valoración

Una escala de 1 a 5 suele aportar suficiente precisión sin generar una falsa sensación de exactitud. Para la probabilidad, 1 puede significar “rara”, 3 “posible” y 5 “muy probable”. Para el impacto, 1 corresponde a una afectación menor y recuperable, mientras que 5 representa una interrupción grave de servicios críticos, pérdidas relevantes, incumplimiento regulatorio o deterioro significativo de la confianza.

El resultado se obtiene multiplicando ambas cifras. Como referencia operativa, una puntuación de 1 a 4 puede tratarse como baja, de 5 a 9 como moderada, de 10 a 16 como alta y de 17 a 25 como crítica. Los umbrales deben adaptarse al apetito de riesgo de cada entidad y a sus obligaciones de supervisión. No todas las organizaciones pueden aceptar el mismo nivel de exposición.

Ejemplo de matriz de riesgo cibernético para una entidad financiera

El siguiente modelo parte de una entidad con canales digitales, servicios en la nube, proveedores tecnológicos y tratamiento de información financiera y personal. La puntuación refleja el riesgo residual tras aplicar controles básicos, no la exposición teórica inicial.

| Escenario de riesgo | Activo o proceso afectado | Probabilidad | Impacto | Nivel | Tratamiento prioritario | | — | — | —: | —: | —: | — | | Phishing que deriva en fraude de pagos | Cuentas corporativas y procesos de tesorería | 4 | 5 | 20 – Crítico | Reforzar MFA resistente al phishing, revisión de pagos y formación por funciones | | Ransomware con cifrado de sistemas | Banca digital, ficheros operativos y atención al cliente | 3 | 5 | 15 – Alto | Segmentar red, probar recuperación y monitorizar actividad anómala | | Exposición de datos por mala configuración cloud | Datos de clientes y expedientes digitales | 3 | 4 | 12 – Alto | Revisar configuraciones, accesos privilegiados y registros de actividad | | Compromiso de un proveedor crítico | APIs, procesamiento de pagos o servicios SaaS | 3 | 5 | 15 – Alto | Evaluar al proveedor, definir requisitos contractuales y planes de contingencia | | Explotación de una vulnerabilidad en aplicación web | Portal de clientes y APIs de negocio | 3 | 4 | 12 – Alto | Gestionar vulnerabilidades, realizar pruebas de intrusión y proteger aplicaciones | | Robo de credenciales de empleado | Correo, VPN y sistemas internos | 4 | 3 | 12 – Alto | Aplicar mínimo privilegio, MFA y detección de accesos anómalos | | Ataque de denegación de servicio | Servicios de banca móvil y web | 2 | 4 | 8 – Moderado | Aumentar capacidad de mitigación y ensayar procedimientos de respuesta |

La utilidad del ejemplo no está en copiar las puntuaciones. Una entidad con alta exposición pública, una plataforma de pagos en tiempo real o una dependencia elevada de terceros puede asignar valores distintos. El riesgo de denegación de servicio, por ejemplo, puede pasar de moderado a crítico si su indisponibilidad afecta a operaciones esenciales o compromete compromisos contractuales.

Cómo convertir la matriz en decisiones de seguridad

Una matriz útil empieza por definir escenarios, no por enumerar tecnologías. “Ransomware” es una amenaza; el escenario relevante describe qué ocurriría: cifrado de servidores que soportan conciliaciones, interrupción de la banca digital o pérdida de acceso a expedientes durante el cierre contable. Cuanto más conectado esté el escenario con un proceso de negocio, más clara será la decisión de tratamiento.

El segundo paso es identificar activos críticos y sus dependencias. En una institución financiera, esto incluye plataformas de pagos, directorio de identidades, aplicaciones de originación de crédito, APIs, repositorios de datos, sistemas de detección de fraude y servicios de terceros. Las dependencias son decisivas: un proveedor de autenticación o un servicio cloud puede convertirse en un punto único de fallo aunque no procese directamente dinero.

Después deben asignarse propietarios. Seguridad puede coordinar la metodología y validar los controles, pero el dueño del proceso debe aceptar, mitigar, transferir o evitar el riesgo. El responsable de pagos, por ejemplo, debe participar en la valoración de un fraude transaccional; conoce los límites operativos, los mecanismos de aprobación y las consecuencias de detener una operación.

El tratamiento debe responder al nivel de riesgo y a la viabilidad real de reducirlo. Un riesgo crítico requiere un plan con responsable, presupuesto, fecha objetivo y seguimiento ejecutivo. Un riesgo alto puede requerir medidas compensatorias mientras se implanta una solución estructural. Un riesgo moderado puede aceptarse si está documentado, se mantiene bajo vigilancia y no contradice el apetito de riesgo ni la normativa aplicable.

Controles que cambian la valoración

No todos los controles reducen igual la probabilidad o el impacto. La autenticación multifactor y la gestión de privilegios pueden disminuir la posibilidad de compromiso de cuentas. La segmentación, las copias de seguridad inmutables y los ejercicios de recuperación reducen el impacto potencial de un ransomware. La monitorización continua puede acortar el tiempo de detección, un factor que con frecuencia determina si un incidente queda contenido o escala a crisis operativa.

La evidencia es tan importante como el control. Decir que existen copias de seguridad no prueba que puedan restaurarse dentro del tiempo exigido por el negocio. Indicar que se evalúan proveedores no demuestra que se revisen sus accesos, subcontrataciones, incidentes y planes de continuidad. La matriz debe apoyarse en pruebas de recuperación, resultados de pruebas de intrusión, auditorías de terceros, análisis de vulnerabilidades y ejercicios de respuesta.

Errores que reducen el valor de la matriz

El primero es valorar todos los riesgos con una gravedad alta. Si todo es prioritario, nada recibe atención efectiva. La matriz debe forzar una discusión sobre el impacto relativo y el orden de remediación, incluso cuando varios escenarios sean relevantes.

El segundo es confundir cumplimiento con reducción de riesgo. Cumplir una exigencia regulatoria puede mejorar la postura de seguridad, pero no garantiza que un control funcione frente a una técnica concreta de ataque. La evaluación necesita evidencias técnicas y operativas, no solo políticas aprobadas.

El tercero es ignorar el factor humano. Las campañas de fraude dirigidas, la reutilización de contraseñas, los errores de configuración y los accesos excesivos siguen siendo vías habituales de compromiso. La formación debe adaptarse a los roles con mayor exposición, como tesorería, administración de sistemas, atención al cliente y equipos con facultad de aprobar pagos.

Por último, una matriz pierde vigencia si solo se revisa una vez al año. Debe actualizarse tras cambios significativos: adopción de un nuevo proveedor, lanzamiento de una API, adquisición de una empresa, incidente relevante, vulnerabilidad crítica o modificación de procesos de pago. La frecuencia dependerá del perfil de la entidad, pero los riesgos críticos requieren un seguimiento mucho más cercano que una revisión anual.

Una matriz bien construida no promete eliminar el riesgo cibernético. Ofrece algo más útil para una entidad regulada: una visión compartida de las exposiciones que pueden comprometer su operación y una disciplina clara para reducirlas antes de que se conviertan en pérdidas, sanciones o pérdida de confianza.