⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Evaluación cuantitativa del riesgo de ciberseguridad para NIS2 y DORA

Igor Petreski
14 min read
Evaluación cuantitativa del riesgo de ciberseguridad mapeada con ISO 27001, NIS2 y DORA

La reunión del consejo en la que «riesgo alto» dejó de ser suficiente

Son las 08:15 de un martes. El director de seguridad de la información de una fintech en rápido crecimiento espera fuera de la sala del consejo con tres versiones de la misma historia de riesgo de ciberseguridad.

La primera versión resulta familiar: el ransomware es «alto», la indisponibilidad de servicios en la nube es «alta», el compromiso de un proveedor es «medio» y el uso indebido del acceso privilegiado es «alto». Es defendible, está alineada con el registro de riesgos actual y es casi inútil para la decisión que debe adoptar el consejo.

La segunda versión es una hoja de ruta técnica: desplegar copias de seguridad inmutables, mejorar los controles de identidad, financiar pruebas de resiliencia, reforzar la supervisión de proveedores y ampliar la cobertura del registro y la monitorización de eventos. Es razonable, pero el director financiero (CFO) formula la pregunta que cambia la reunión: «¿Cuál de estas medidas reduce más riesgo para las operaciones de la organización por cada euro invertido?»

La tercera versión cambia la conversación.

Una indisponibilidad de 12 horas de la plataforma de orquestación de pagos se estima en €620,000 de impacto bruto operativo, contractual y sobre ingresos. La exposición anualizada actual se estima en €186,000. Un paquete de resiliencia de €74,000 puede reducir la pérdida anual esperada a aproximadamente €62,000. La exposición restante sigue por encima de la tolerancia porque el servicio soporta una función crítica o importante, la exposición por notificaciones a clientes sigue siendo material y la dependencia de terceros es elevada.

Ahora el consejo no debate colores. Debate exposición financiera, tolerancia al riesgo, responsabilidad regulatoria y prioridades de inversión.

Eso es la evaluación cuantitativa del riesgo de ciberseguridad en 2026. No es teatro matemático. No pretende afirmar que los eventos de ciberseguridad puedan predecirse con precisión perfecta. Es la traducción disciplinada de «esto está en rojo» a «esta es la exposición financiera plausible, este es el nivel de confianza, esta es la consecuencia regulatoria, esta es la decisión de tratamiento y esta es la pista de auditoría».

Para directores de seguridad de la información, responsables de cumplimiento, auditores y propietarios de la organización, ese cambio se está volviendo obligatorio en la práctica. ISO/IEC 27001:2022 exige un proceso de evaluación y tratamiento de riesgos documentado, coherente y comparable. NIS2 traslada el riesgo de ciberseguridad a la aprobación, supervisión, formación y responsabilidad del órgano de dirección. DORA sitúa la gobernanza del riesgo TIC, las pruebas de resiliencia, la clasificación de incidentes, el riesgo de terceros y la responsabilidad de la dirección en el centro de las entidades financieras. NIST CSF 2.0 proporciona a la dirección un lenguaje de gobernanza para el apetito de riesgo, la priorización y la supervisión. El RGPD de la UE añade responsabilidad proactiva cuando intervienen datos personales.

La brecha no es que las organizaciones carezcan de registros de riesgos. La brecha es que muchos registros de riesgos no pueden explicar dinero, prioridades, responsabilidad del consejo ni evidencias de auditoría.

El enfoque de Clarysec cierra esa brecha combinando Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, las políticas de Clarysec y Zenith Controls: The Cross-Compliance Guide Zenith Controls en un único modelo práctico de evidencias: cuantificar lo importante, mapearlo con controles, mostrar quién lo aceptó y demostrar que el tratamiento funcionó.

Por qué los registros de riesgos cualitativos ya no son suficientes

La evaluación cualitativa de riesgos sigue siendo importante. Una matriz clara de probabilidad e impacto ayuda a los equipos a priorizar cuando los datos son incompletos, especialmente en un alcance amplio del SGSI. El problema empieza cuando la organización se queda ahí.

Un consejo puede entender que un riesgo es «alto», pero no puede comparar fácilmente tres riesgos «altos» que compiten por el mismo presupuesto. ¿La máxima prioridad es el escenario de ransomware, la indisponibilidad de servicios en la nube, el riesgo de concentración de proveedores o la debilidad en el acceso privilegiado? La respuesta depende de la exposición financiera, la severidad regulatoria, el impacto en clientes, las obligaciones contractuales, la criticidad del servicio y el riesgo residual después del tratamiento.

Por eso la evaluación cuantitativa del riesgo de ciberseguridad funciona mejor como modelo híbrido. No cuantifique cada cuestión menor. Utilice la calificación cualitativa en todo el registro y añada análisis financiero para los riesgos que requieren decisiones de dirección, aprobación de inversiones, actuación contractual, transferencia del riesgo o supervisión del consejo.

La Política de gestión de riesgos empresarial de Clarysec Política de gestión de riesgos lo respalda expresamente. En la sección «Requisitos de aplicación de la política», cláusula 6.2.3, establece:

«Podrán aplicarse métodos cualitativos y cuantitativos en función de la categoría de riesgo y de la disponibilidad de información.»

Esa cláusula es importante porque evita un fallo habitual: la falsa precisión. Las organizaciones maduras no fuerzan el modelado financiero sobre cada riesgo menor. Lo aplican cuando la decisión lo requiere.

Para las pymes, la base puede seguir siendo sencilla. La Política de gestión de riesgos para pymes de Clarysec Política de gestión de riesgos para pymes, sección «Requisitos de gobernanza», cláusula 5.1.2, establece:

«Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.»

La mejora no consiste en sustituir esa estructura. Consiste en enriquecer las entradas más importantes con estimaciones financieras, especialmente cuando intervienen indisponibilidad, servicios regulados, datos personales, dependencia de servicios en la nube, externalización de TIC o compromisos críticos con clientes.

El cambio de gobernanza: el riesgo de ciberseguridad ya es un artefacto del consejo

La cuantificación del riesgo de ciberseguridad no es solo un ejercicio financiero. Es evidencia de gobernanza.

Conforme a ISO/IEC 27001:2022, la organización debe determinar el contexto, las partes interesadas, los requisitos legales y contractuales, el alcance, las interfaces y las dependencias. Debe definir un proceso de evaluación de riesgos de seguridad de la información que produzca resultados coherentes, válidos y comparables. Debe identificar riesgos para la confidencialidad, integridad y disponibilidad, identificar propietarios del riesgo, evaluar consecuencias y probabilidad, determinar niveles de riesgo y priorizar riesgos. Después debe seleccionar opciones de tratamiento, determinar controles, compararlos con el Anexo A, elaborar una Declaración de Aplicabilidad, obtener la aprobación del propietario del riesgo y conservar información documentada.

Eso significa que el registro de riesgos no es una hoja de cálculo privada del equipo de seguridad. Es un registro del SGSI que conecta liderazgo, selección de controles, responsabilidad del tratamiento y revisión por la dirección.

NIS2 eleva aún más la expectativa. Los órganos de dirección de entidades esenciales e importantes deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su aplicación y recibir formación para comprender los riesgos y evaluar las prácticas de ciberseguridad. NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, teniendo en cuenta el estado de la técnica, el coste de aplicación, la exposición al riesgo, el tamaño de la entidad, la probabilidad, la severidad y el impacto social y económico.

La expresión «impacto social y económico» es donde la cuantificación financiera del riesgo de ciberseguridad se vuelve especialmente potente. Un proveedor que soporte nube, centros de datos, DNS, servicios de confianza, servicios gestionados, servicios de seguridad gestionados, infraestructura digital, mercados en línea u otros sectores cubiertos puede necesitar demostrar no solo que existen controles, sino por qué son proporcionales a la exposición.

Para las entidades financieras, DORA es aplicable desde el 17 de enero de 2025 y se convierte en el régimen sectorial de resiliencia operativa digital. Cubre la gestión del riesgo de las TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital, el intercambio de información sobre ciberamenazas, el riesgo de terceros de TIC y la supervisión de proveedores terceros críticos de servicios de TIC. Para las entidades financieras también identificadas en virtud de la transposición nacional de NIS2, DORA opera como acto jurídico de la Unión sectorial para las materias pertinentes de gestión del riesgo TIC y notificación de incidentes.

En términos prácticos, una fintech no necesita cinco marcos de riesgo desconectados. Necesita un único modelo de riesgo integrado que muestre qué régimen aplica, qué dependencias existen, qué exposición financiera es plausible y cómo la dirección aprobó y supervisó el tratamiento.

El RGPD de la UE añade otra capa. Si intervienen datos personales, un evento de ciberseguridad puede convertirse en una violación de la seguridad de los datos personales, no solo en un incidente operativo. El modelo de riesgo debe identificar el contexto del tratamiento, el rol de responsable o encargado del tratamiento, las categorías de datos, los datos de categoría especial cuando proceda, las medidas de seguridad, la lógica de evaluación de violaciones de seguridad y las implicaciones de notificación.

Del mapa de calor a los euros: el modelo híbrido práctico

La pregunta correcta no es: «¿Debemos sustituir la evaluación cualitativa de riesgos?». La pregunta correcta es: «¿Qué riesgos merecen cuantificación financiera?»

El Zenith Blueprint, fase de gestión de riesgos, Paso 12, «Métodos de evaluación de riesgos: cualitativos y cuantitativos», ofrece una respuesta pragmática:

«La evaluación cuantitativa de riesgos intenta estimar el riesgo en términos numéricos (por ejemplo, pérdida anual esperada en moneda). Esto suele implicar:

✓ Recopilar datos históricos de incidentes (por ejemplo, con qué frecuencia se produce una brecha de seguridad y cuál es el coste medio). ✓ Utilizar modelos como la Pérdida anual esperada (ALE = Impacto de pérdida única × Tasa anual de ocurrencia) o marcos como FAIR (Factor Analysis of Information Risk) para análisis más complejos.»

El mismo paso advierte que el análisis cuantitativo puro puede ser difícil para las pymes porque los datos históricos pueden ser limitados y el proceso puede requerir muchos recursos. La respuesta práctica es un análisis cuantitativo ligero para los riesgos principales.

ElementoSignificado prácticoEjemplo
Impacto de pérdida por eventoImpacto estimado si el escenario ocurre una vez€620,000 por una indisponibilidad de 12 horas de la plataforma de pagos
Tasa anual de ocurrenciaFrecuencia estimada por año0.3, aproximadamente una vez cada 3.3 años
Pérdida anual esperadaImpacto de pérdida por evento multiplicado por la tasa anual de ocurrencia€186,000 de exposición anual esperada
Coste del tratamientoCoste del paquete de controles€74,000 para conmutación por error, supervisión y pruebas
Pérdida anual residual esperadaExposición anual estimada después del tratamiento€62,000
DecisiónTratar, transferir, evitar o aceptarTratar y revisar el riesgo residual en la revisión por la dirección

Los números no tienen que ser perfectos. Tienen que estar explicados. Las hipótesis de impacto pueden incluir pérdida de ingresos, créditos de acuerdos de nivel de servicio (SLA), compensación a clientes, respuesta a incidentes, asesoramiento jurídico, soporte forense, horas extraordinarias, soporte a clientes, esfuerzo de notificación regulatoria, pérdida de clientes e impacto reputacional. Las hipótesis de frecuencia pueden proceder de incidentes internos, informes de indisponibilidad de proveedores, inteligencia de amenazas, experiencia sectorial, exposición a vulnerabilidades, hallazgos de auditoría y madurez de controles.

El Zenith Blueprint, fase de gestión de riesgos, Paso 10, «Definición de criterios de riesgo y matriz de impacto», explica por qué el modelo debe calibrarse:

«Al definir el impacto, conviene relacionar los niveles con la escala específica de la organización. Por ejemplo, “Impacto financiero mayor = pérdida > $100k” (ajústelo a su contexto). Considere también el impacto regulatorio: por ejemplo, una brecha de seguridad de datos personales podría ser automáticamente “Mayor” o “Severa” por las multas del RGPD de la UE y los requisitos de notificación, aunque la pérdida financiera directa no esté clara.»

Ese es el puente entre el riesgo cualitativo y el cuantitativo. «Mayor» solo adquiere significado cuando la organización define qué significa mayor en términos financieros, operativos, legales y de cliente.

Ejemplo práctico: cuantificar el riesgo de indisponibilidad de un proveedor en la nube

Imagine un proveedor SaaS que presta servicio a clientes del sector financiero. Depende de un proveedor de alojamiento en la nube, una plataforma gestionada de bases de datos, una pasarela de pagos y un servicio de notificación a clientes. El equipo selecciona un escenario para el análisis cuantitativo:

«La indisponibilidad prolongada de la plataforma gestionada de bases de datos provoca la interrupción del servicio orientado al cliente y retrasos en el procesamiento de transacciones.»

Paso 1: definir el escenario de riesgo y el propietario

La Política de gestión de riesgos para pymes exige descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento. La Política de gestión de riesgos empresarial, sección «Requisitos de gobernanza», cláusula 5.2.2, añade que el registro:

«Incluye propietarios de riesgos, puntuaciones de impacto y probabilidad, planes de tratamiento, fechas límite y referencias de controles.»

El propietario no es «TI». El propietario responsable es el propietario del servicio, con apoyo del director de seguridad de la información, el CTO, el responsable de cumplimiento, el responsable de proveedores y finanzas.

Paso 2: estimar la exposición financiera

El equipo estima:

  • €35,000 por hora en ingresos por transacciones perdidos y créditos de SLA
  • €8,000 por hora en costes de soporte, escalado y gestión de incidentes
  • €60,000 en costes de remediación y comunicaciones con clientes
  • €120,000 en posible pérdida de clientes o impacto comercial
  • 10 horas como indisponibilidad severa plausible, basada en el historial del proveedor y la revisión de arquitectura

El impacto de pérdida por evento es:

10 × (€35,000 + €8,000) + €60,000 + €120,000 = €610,000

La probabilidad actual se estima en 0.25 por año. La pérdida anual esperada es:

€610,000 × 0.25 = €152,500

El paquete de tratamiento propuesto incluye diseño de conmutación por error multirregión, restauración probada de copias de seguridad, revisión de SLA del proveedor, supervisión sintética, un ejercicio de simulación y actualización del plan de salida. El coste del primer año es de €82,000, con €34,000 recurrentes.

Después del tratamiento, la probabilidad residual se estima en 0.10 por año y el impacto residual de pérdida por evento en €350,000 debido a una restauración más rápida. La ALE residual es:

€350,000 × 0.10 = €35,000

La reducción del primer año en la exposición anual esperada es de aproximadamente €117,500, antes de considerar la resiliencia regulatoria, la confianza de los clientes y los beneficios contractuales.

Paso 3: elegir el tratamiento y documentar la justificación

El tratamiento de riesgos no siempre es mitigación pura. La Política de gestión de riesgos para pymes de Clarysec, sección «Requisitos de aplicación de la política», cláusula 6.1.3, establece:

«Transferir: utilizar contratos, acuerdos de nivel de servicio o seguros para transferir el riesgo externamente.»

Para este escenario, la organización elige un tratamiento mixto: reducir mediante resiliencia técnica, transferir una parte mediante SLA y remedios contractuales, y aceptar el riesgo residual con aprobación de la dirección.

Paso 4: mapear el tratamiento con la Declaración de Aplicabilidad

La Política de gestión de riesgos empresarial, sección «Alineación con la Declaración de Aplicabilidad (SoA)», cláusula 6.5.1, establece:

«Las decisiones de control resultantes del proceso de tratamiento de riesgos deberán reflejarse en la SoA.»

Aquí es donde el modelo financiero queda preparado para auditoría. El escenario de indisponibilidad del proveedor se vincula con los controles del Anexo A de ISO/IEC 27001:2022 relativos a proveedores, nube, continuidad, incidentes e interrupciones. También se vincula con la seguridad de la cadena de suministro y la continuidad del negocio de NIS2, el riesgo de terceros de TIC y las pruebas de resiliencia de DORA, la seguridad y la evaluación de violaciones de seguridad del RGPD de la UE si se ven afectados datos personales, y los resultados de gobernanza, cadena de suministro, respuesta y recuperación de NIST CSF.

El Zenith Blueprint, fase de gestión de riesgos, Paso 13, «Planificación del tratamiento de riesgos y Declaración de Aplicabilidad», explica la trazabilidad:

«La SoA es, en la práctica, un documento puente: vincula la evaluación y el tratamiento de riesgos con los controles reales que se tienen. Al completarla, también se comprueba si se ha omitido algún control.»

Una justificación sólida de la SoA podría decir: «Aplicable porque la indisponibilidad de la base de datos gestionada afecta al servicio crítico al cliente, la dependencia de terceros de TIC, las obligaciones contractuales con clientes, los compromisos de continuidad y la posible disponibilidad de datos personales. Los controles se seleccionan para reducir una exposición anualizada cuantificada de €152,500 y respaldar un riesgo residual aprobado por la dirección.»

Paso 5: escalar en función de umbrales

La Política de gestión de riesgos empresarial, sección «Requisitos de gobernanza», cláusula 5.6, exige:

«La Matriz de Autoridad de Riesgo deberá definir claramente los umbrales de escalado a la Alta Dirección o al Consejo.»

Una exposición anualizada de €152,500 puede superar la tolerancia de la dirección local. Un riesgo de menor valor puede requerir igualmente escalado si afecta a una función crítica o importante, activa expectativas de DORA, implica datos personales, amenaza compromisos con clientes o crea responsabilidad del órgano de dirección conforme a NIS2.

Mapeo de cumplimiento cruzado: un riesgo cuantificado, muchas obligaciones

Un riesgo de ciberseguridad cuantificado no debe copiarse en cinco hojas de cálculo de cumplimiento separadas. Debe convertirse en un único objeto de riesgo con múltiples vistas de cumplimiento.

Perspectiva de cumplimientoQué debe mostrar el riesgo cuantificadoArtefacto de evidencia
ISO/IEC 27001:2022Criterios de riesgo, propietario, probabilidad, consecuencia, tratamiento, aceptación residual, mapeo de SoA y evidencia operativaRegistro de riesgos, plan de tratamiento, SoA, revisión por la dirección, registros de auditoría
NIS2Medidas adecuadas y proporcionadas, aprobación y supervisión del órgano de dirección, consideraciones de incidentes y continuidad, medidas de cadena de suministroActas del consejo, registros de formación, aprobaciones de tratamiento de riesgos, flujo de trabajo de incidentes
DORAGobernanza del riesgo TIC, funciones críticas o importantes, dependencias de terceros de TIC, pruebas, clasificación de incidentes y estrategia de resilienciaMarco de riesgo TIC, registro de información, resultados de las pruebas, clasificación de incidentes, plan de salida
RGPD de la UEAlcance de datos personales, medidas de seguridad, implicaciones de violación de seguridad, responsabilidad proactiva del responsable o encargado del tratamiento, contexto de tratamiento lícitoVinculación con RoPA, EIPD cuando proceda, evaluación de violación de seguridad, evidencias de seguridad
NIST CSF 2.0Apetito de riesgo, priorización estandarizada, gobernanza, riesgo de proveedores, resultados de detección, respuesta y recuperaciónPerfiles actual y objetivo, plan de acción, POA&M, registros de riesgo de proveedores
COBIT 2019Objetivos de gobernanza, supervisión del desempeño, optimización del riesgo, decisiones sobre recursos y aseguramientoInformes de gobernanza, métricas de desempeño de controles, informes de aseguramiento

NIS2 Article 21 es especialmente relevante porque incluye análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, copia de seguridad, recuperación ante desastres, gestión de crisis, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, evaluación de eficacia, higiene cibernética, formación, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos y autenticación.

DORA crea una disciplina similar para las entidades financieras, pero con un enfoque sectorial. Exige un marco interno de gobernanza y control para el riesgo TIC, con responsabilidad última del órgano de dirección. Espera aprobación y supervisión de políticas TIC, roles, estrategia de resiliencia operativa digital, tolerancia al riesgo TIC, planes de continuidad y respuesta, planes de auditoría, presupuestos, formación, políticas de terceros de TIC y canales de notificación.

DORA también proporciona a la evaluación cuantitativa de riesgos un desencadenante operativo directo: la clasificación de incidentes. Los incidentes graves relacionados con las TIC deben clasificarse utilizando criterios como clientes, contrapartes y transacciones afectadas, duración, tiempo de indisponibilidad, extensión geográfica, pérdidas de datos que afecten a disponibilidad, autenticidad, integridad o confidencialidad, criticidad de los servicios afectados e impacto económico. Si el modelo de riesgo ya estima indisponibilidad, impacto en clientes, impacto en datos y pérdida económica, respalda la clasificación de incidentes cuando se produce un evento real.

El mapeo de controles que hace auditable la responsabilidad del consejo

En Zenith Controls, Clarysec mapea el control 5.4 de ISO/IEC 27002:2022, «Responsabilidades de la dirección», como ancla de gobernanza para la responsabilidad proactiva en seguridad de la información. La guía lo trata como preventivo, de apoyo a la confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad «Identificar», con la gobernanza como capacidad operativa y la gobernanza más el ecosistema como dominios de seguridad.

Esto importa porque la exposición financiera de ciberseguridad pertenece a la toma de decisiones de la dirección. Zenith Controls vincula el control 5.4 de ISO/IEC 27002:2022 con varios controles de apoyo:

Relación de control ISO/IEC 27002:2022Por qué importa para el riesgo cuantificado
5.2 Roles y responsabilidades de seguridad de la informaciónDeben definirse propietarios del riesgo, propietarios de controles y autoridades de escalado
5.1 Políticas de seguridad de la informaciónLas decisiones de riesgo cuantificado deben alinearse con compromisos de política aprobados
5.35 Revisión independiente de la seguridad de la informaciónLa revisión independiente proporciona a la dirección aseguramiento objetivo sobre el tratamiento de riesgos
5.36 Cumplimiento de políticas, reglas y estándares de seguridad de la informaciónLa supervisión del cumplimiento muestra si los tratamientos operan según lo previsto
5.8 Seguridad de la información en la gestión de proyectosLos nuevos productos y cambios deben incorporar tempranamente el riesgo de ciberseguridad y la exposición financiera

Zenith Controls también mapea las responsabilidades de la dirección con las cláusulas 5.1, 5.2 y 9.3 de ISO/IEC 27001:2022, conectando liderazgo, política y revisión por la dirección. Además, las mapea con las cláusulas 6 y 7 de ISO/IEC 27014:2020, centradas en marcos y procesos de gobernanza para evaluar, dirigir, supervisar y comunicar la seguridad de la información.

La cadena de evidencias es directa:

  1. La dirección define apetito de riesgo, tolerancia y umbrales de escalado.
  2. Los propietarios del riesgo cuantifican los principales riesgos de ciberseguridad.
  3. Los controles se seleccionan y se reflejan en la SoA.
  4. Las acciones de tratamiento se ejecutan y supervisan.
  5. La revisión independiente y la supervisión del cumplimiento prueban la eficacia.
  6. La revisión por la dirección evalúa desempeño, incidentes, resultados de auditoría, recursos y acciones de mejora.
  7. El consejo recibe exposición financiera, riesgo residual y evidencias de responsabilidad en términos de negocio.

La Política de gestión de riesgos para pymes de Clarysec, sección «Roles y responsabilidades», cláusula 4.1.1, refuerza esta función de gobernanza:

«Establece el apetito de riesgo de la organización y aprueba el marco de gestión del riesgo.»

Para una pyme, puede ser el director general o el propietario. Para una entidad financiera regulada, puede ser el órgano de dirección. El principio de responsabilidad es el mismo.

Cómo auditores y reguladores pondrán a prueba sus cifras

La evaluación cuantitativa del riesgo de ciberseguridad no se auditará como ciencia actuarial perfecta. Se auditará por método, coherencia, trazabilidad, gobernanza y evidencias.

Perspectiva del auditor o evaluadorQué pondrán a pruebaEvidencias esperadas
ISO/IEC 27001:2022Cláusula 6.1.2 evaluación de riesgos, cláusula 6.1.3 tratamiento de riesgos, decisiones de SoA, aprobación del propietario del riesgo y cláusula 9.3 revisión por la direcciónCriterios de riesgo, registro, plan de tratamiento, SoA, aprobaciones, actas de revisión por la dirección
Autoridad competente de NIS2Aprobación y supervisión del órgano de dirección, medidas de Article 21, proporcionalidad, preparación ante incidentes y formaciónPaquetes para el consejo, registros de formación, aprobaciones de riesgos, procedimientos de incidentes, evidencias de continuidad
Supervisor de DORA o auditor internoMarco de riesgo TIC, tolerancia al riesgo TIC, funciones críticas o importantes, pruebas, clasificación de incidentes y riesgo de terceros de TICRegistro de riesgos TIC, estrategia de resiliencia, registro de información, resultados de las pruebas, planes de salida
Evaluador de NIST CSF 2.0Resultados GOVERN, incluidos GV.RM-02 apetito de riesgo y tolerancia, y GV.RM-06 priorización estandarizadaPerfil actual, perfil objetivo, plan de acción, vinculación con riesgo empresarial
Evaluador de COBIT 2019Gobernanza de TI empresarial, optimización del riesgo, derechos de decisión, asignación de recursos y aseguramientoInformes de gobernanza, métricas de desempeño, informes de aseguramiento

La Política de auditoría y supervisión del cumplimiento para pymes de Clarysec Política de auditoría y supervisión del cumplimiento para pymes, sección «Requisitos de gobernanza», cláusula 5.4.3, hace explícito el ciclo de auditoría:

«Los hallazgos de auditoría y las actualizaciones de estado deben incluirse en el proceso de revisión por la dirección del SGSI.»

Esto es crítico. Si el modelo de riesgo estima una exposición de €500,000 pero auditoría interna detecta que la prueba de restauración falló, el riesgo residual debe cambiar. Si el plan de salida del proveedor no se ha probado, la organización no debe aceptar el riesgo residual como si el control fuera maduro. Si las pruebas de DORA identifican una deficiencia crítica, ese hallazgo debe alimentar el tratamiento, el presupuesto y la revisión por la dirección.

El Zenith Blueprint, fase de auditoría, revisión y mejora, Paso 28, «Revisión por la dirección», lo respalda recomendando entradas para la revisión por la dirección como cambios en cuestiones internas y externas, requisitos regulatorios, resultados de auditoría, supervisión y medición, objetivos, incidentes, no conformidades, oportunidades de mejora y necesidades de recursos. En un programa de riesgo de ciberseguridad cuantificado, el paquete de revisión por la dirección debe incluir las principales exposiciones financieras, la tendencia desde la última revisión, el progreso del tratamiento, acciones vencidas, riesgo residual por encima de la tolerancia y decisiones requeridas.

Construir un paquete de riesgo de ciberseguridad listo para el consejo

Un paquete de riesgo de ciberseguridad listo para el consejo no debe ahogar a los consejeros en recuentos de vulnerabilidades, variables FAIR o identificadores de controles. Debe traducir el riesgo de ciberseguridad en decisiones.

Para cada riesgo cuantificado principal, incluya:

  • Nombre del escenario y servicio de negocio afectado
  • Criticidad del servicio o función
  • Indicadores de datos personales, servicio regulado y dependencia de proveedores
  • Estimación actual del impacto de pérdida por evento
  • Estimación actual de la tasa anual de ocurrencia
  • Pérdida anual esperada actual
  • Hipótesis y nivel de confianza
  • Controles actuales y deficiencias conocidas
  • Opciones de tratamiento y coste
  • Exposición residual esperada después del tratamiento
  • Relevancia para ISO/IEC 27001:2022, NIS2, DORA y RGPD de la UE
  • Propietario del riesgo y decisión necesaria
  • Referencias de SoA y políticas
  • Fecha límite y fecha de revisión

Una vista simplificada para el consejo puede ser la siguiente:

Escenario de riesgoALE actualCoste del tratamientoALE residualImpulsor regulatorioDecisión
Indisponibilidad de base de datos gestionada que afecta al procesamiento de transacciones€152,500€82,000€35,000Riesgo TIC DORA, tratamiento de riesgos ISO, continuidad de proveedoresAprobar tratamiento
Ransomware que afecta a la plataforma de datos de clientes€372,000€100,000€95,000Riesgo de violación de seguridad del RGPD de la UE, gestión de incidentes NIS2, controles de incidentes ISOAprobar EDR y copias de seguridad inmutables
Compromiso de acceso privilegiado en la consola de administración en la nube€260,000€58,000€72,000Control de acceso ISO, autenticación NIS2, integridad de datos DORAAprobar mejora de MFA y PAM
Riesgo de concentración de proveedor SaaS crítico€190,000€45,000€95,000Riesgo de terceros DORA, cadena de suministro NIS2, controles de proveedores ISOAprobar pruebas del plan de salida

Las cifras son estimaciones, pero el valor de gobernanza es real. El consejo puede comparar prioridades. El director de seguridad de la información puede justificar el gasto. Finanzas puede validar hipótesis. Cumplimiento puede vincular decisiones con obligaciones. Los auditores pueden seguir la pista de evidencias.

Errores habituales al cuantificar el riesgo de ciberseguridad

El primer error es la falsa precisión. Un modelo que afirma una pérdida de €487,239.17 sin hipótesis claras es menos creíble que un rango con base documentada. Utilice rangos cuando proceda y revise las hipótesis después de incidentes, auditorías, cambios de proveedores y decisiones mayores de arquitectura.

El segundo error es contar solo el coste técnico. Un incidente de ciberseguridad grave puede implicar pérdida de ingresos, compensación a clientes, interrupción operativa, notificación regulatoria, asesoramiento jurídico, soporte forense, costes de comunicación, penalizaciones contractuales, pérdida de clientes, tiempo de dirección e impacto reputacional.

El tercer error es ignorar la severidad regulatoria. Una violación de la seguridad de los datos personales puede ser mayor aunque la pérdida operativa directa parezca modesta. Un incidente DORA puede ser significativo por la criticidad del servicio, el tiempo de indisponibilidad, la pérdida de datos o los clientes afectados. Un incidente NIS2 puede ser material porque causa una interrupción operativa severa, pérdida financiera o daños considerables a terceros.

El cuarto error es no actualizar la SoA. Si las decisiones de tratamiento seleccionan supervisión de proveedores, planificación de salida de la nube, recopilación de evidencias de incidentes, preparación TIC para la continuidad del negocio o controles frente a interrupciones, la SoA debe reflejar los controles aplicables y el estado de implantación.

El quinto error es dejar a finanzas fuera. La evaluación cuantitativa del riesgo de ciberseguridad es más sólida cuando seguridad, finanzas, legal, operaciones, producto y cumplimiento acuerdan las hipótesis de impacto. El director de seguridad de la información no debe inventar por sí solo las cifras de pérdida de ingresos.

El sexto error es tratar el seguro como una transferencia total del riesgo. El seguro puede reducir el impacto financiero, pero no elimina la responsabilidad regulatoria, la interrupción del servicio, el daño a la confianza del cliente ni la responsabilidad de la dirección.

Dónde encaja Clarysec

Clarysec ayuda a las organizaciones a construir un programa de riesgo de ciberseguridad lo bastante práctico para pymes y lo bastante riguroso para entornos regulados.

El Zenith Blueprint guía a la organización desde el alcance y el contexto hasta los criterios de riesgo, la evaluación cualitativa y cuantitativa, la planificación del tratamiento, la trazabilidad de la SoA, la auditoría, la revisión por la dirección y la mejora. Zenith Controls ayuda a mapear las expectativas de controles de ISO/IEC 27001:2022 e ISO/IEC 27002:2022 con otros marcos, auditorías y obligaciones de gobernanza. Las políticas de Clarysec proporcionan el lenguaje que esperan los auditores, incluidos apetito de riesgo, matrices de autoridad, opciones de tratamiento, registros de cumplimiento, alineación de SoA e integración con la revisión por la dirección.

La Política de cumplimiento legal y normativo para pymes de Clarysec Política de cumplimiento legal y normativo para pymes, sección «Requisitos de gobernanza», cláusula 5.1.1, comienza con una obligación sencilla:

«El Director General debe mantener un Registro de Cumplimiento simple y estructurado que enumere:»

Ese registro sencillo importa. Las obligaciones legales, regulatorias y contractuales deben ser visibles dentro del SGSI. Para el riesgo cuantitativo, eso significa que NIS2, DORA, RGPD de la UE, contratos con clientes, SLA, obligaciones de externalización, obligaciones de notificación de incidentes y compromisos de auditoría dan forma al impacto, la prioridad de tratamiento y el escalado.

La Política de gestión de riesgos empresarial, sección «Normas y marcos de referencia», cláusula 11.9.1, también refleja directamente una gobernanza de estilo DORA:

«Article 5: exige un marco documentado de gestión del riesgo TIC, plenamente cubierto por la estructura de esta política, incluido el mapeo de SoA y los KRI.»

Ese es el modelo de Clarysec en una frase: gestión documentada del riesgo TIC, mapeada con controles, medida mediante indicadores, revisada por la dirección y evidenciada para auditoría.

Próximos pasos: haga que su registro de riesgos de ciberseguridad de 2026 sea financieramente defendible

Si su registro de riesgos de ciberseguridad actual todavía dice «alto» sin explicar exposición financiera, economía del tratamiento o impacto regulatorio, empiece con cinco acciones este trimestre:

  1. Seleccione sus 5 a 10 principales escenarios de riesgo de ciberseguridad por impacto en las operaciones de la organización.
  2. Defina umbrales de impacto financiero para menor, moderado, mayor y severo.
  3. Estime el impacto de pérdida por evento, la tasa anual de ocurrencia y la pérdida anual esperada para cada escenario principal.
  4. Mapee cada decisión de tratamiento con controles de ISO/IEC 27001:2022, la SoA, obligaciones NIS2 o DORA cuando sean aplicables, implicaciones del RGPD de la UE y resultados de gobernanza de NIST CSF.
  5. Presente el riesgo residual, el coste del tratamiento y los umbrales de escalado en la revisión por la dirección.

Clarysec puede ayudarle a convertirlo en un sistema de evidencias repetible utilizando el Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, la Política de gestión de riesgos empresarial Política de gestión de riesgos, la Política de gestión de riesgos para pymes Política de gestión de riesgos para pymes y plantillas de apoyo de auditoría y cumplimiento.

El objetivo no es hacer que el riesgo de ciberseguridad sea perfectamente predecible. El objetivo es hacerlo explicable, comparable, financieramente significativo y auditable.

Descargue las plantillas de políticas de riesgo y cumplimiento de Clarysec, explore el Zenith Blueprint o reserve una evaluación de Clarysec para convertir su registro de riesgos de ciberseguridad de 2026 en evidencias listas para el consejo para ISO/IEC 27001:2022, NIS2, DORA y RGPD de la UE.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles

Gobernanza de seguridad de pipelines CI/CD para auditorías de 2026

Gobernanza de seguridad de pipelines CI/CD para auditorías de 2026

Guía práctica para CISO sobre la gobernanza de pipelines CI/CD como sistemas auditables de cadena de suministro de software, con procedencia de compilación, runners bastionados, artefactos firmados, evidencias de despliegue y mapeos de políticas de Clarysec.

Mapeo de flujos de datos del RoPA para GDPR, NIS2 y DORA

Mapeo de flujos de datos del RoPA para GDPR, NIS2 y DORA

Guía práctica para 2026 sobre cómo convertir el RoPA y el mapeo de flujos de datos en una capa unificada de evidencias para GDPR Article 30, servicios críticos NIS2, dependencias de TIC DORA y auditorías ISO/IEC 27001:2022.

Gobernanza del pago de rescates por ransomware para NIS2 y DORA

Gobernanza del pago de rescates por ransomware para NIS2 y DORA

Un marco práctico alineado con ISO 27001:2022 para gobernar decisiones de pago de rescates por ransomware, verificaciones frente a listas de sanciones, preservación de evidencias, aprobación del ciberseguro y notificaciones NIS2, DORA y GDPR.