Un análisis de riesgos según NIS2 no es un documento para guardar en un cajón. Es el elemento vinculante entre los riesgos empresariales, la realidad técnica en el entorno operativo y las decisiones demostrables. En la práctica, muchos programas no fracasan por la falta de medidas de seguridad, sino porque no se definen claramente prioridades, responsabilidades y límites de aceptación (¿qué es ‚aceptable‘ y qué no?). NIS2 aumenta la presión: la responsabilidad de la dirección, la capacidad de notificación ante incidentes y la prueba de medidas ‚adecuadas y proporcionadas‘ deben encajar de forma sólida.
Este artículo proporciona una metodología que se puede implementar en paisajes de TI heterogéneos sin quedar paralizado por la perfección del modelo. El foco está en métricas, umbrales de decisión y una documentación apta para auditoría que apoye por igual a operaciones, seguridad y dirección: ¿Qué se evalúa exactamente? ¿Qué cifras necesita la dirección? ¿Cuándo un riesgo es ‚rojo‘ y quién puede aceptarlo? ¿Y cómo evita usted que los análisis de riesgos se estanquen en talleres interminables?
Análisis de riesgos según NIS2: qué exige NIS2 en la práctica del análisis de riesgos
NIS2 exige medidas organizativas y técnicas basadas en el riesgo. Lo decisivo no es tanto un marco concreto, sino la capacidad de identificar, evaluar, tratar y supervisar riesgos de forma sistemática y continua. Para las empresas, eso significa: el análisis de riesgos debe representar el alcance, la metodología, los resultados y las decisiones de manera que puedan explicarse en auditorías y frente a supervisores/autoridades.
Preguntas típicas de verificación y evidencia que debería poder responder con su análisis de riesgos:
- Alcance: ¿Qué sistemas, procesos, ubicaciones y proveedores están incluidos, y por qué?
- Criterios de riesgo: ¿Qué significa concretamente ‚alto‘ (tiempo de inactividad, fuga de datos, evento de seguridad, consecuencias legales)?
- Tratamiento: ¿Qué medidas reducen qué riesgo, para cuándo y con qué responsable?
- Aceptación: ¿Qué riesgos se han aceptado deliberadamente y en qué nivel de decisión?
- Supervisión: ¿Qué KRIs (Indicadores Clave de Riesgo) indican si el riesgo empeora o si las medidas no están funcionando?
Importante: NIS2 no es un ejercicio puramente de seguridad informática. Si el análisis de riesgos mantiene listas de TI pero no establece vínculo con la criticidad de procesos, las dependencias de la cadena de suministro y los objetivos de recuperación (BCM/DR), seguirá siendo débil para la toma de decisiones.
Definir el alcance con precisión: sin delimitación no hay decisiones fundamentadas
El error más frecuente es un alcance que consiste en una „lista de inventario de sistemas“ sin prioridades claras. Para NIS2 necesita un alcance mínimo viable que cubra los servicios críticos del negocio y un concepto de crecimiento para ampliarlo de forma iterativa.
Un alcance práctico en tres niveles
- Nivel 1: Servicios/Procesos críticos (p. ej., producción, logística, facturación, portal de clientes). Esa es la visión de la dirección.
- Nivel 2: Servicios de TI de soporte (p. ej., IAM, correo electrónico, red, virtualización, copias de seguridad, monitorización). Esa es la visión operativa.
- Nivel 3: Activos (aplicaciones, bases de datos, interfaces, cargas de trabajo en la nube, puntos finales, proveedores). Esa es la visión técnica detallada.
El análisis de riesgos debe vincular los niveles: una caída de „IAM“ no es solo un tema de TI, sino que puede significar „sin acceso a sistemas centrales“. La evaluación debe hacer visible esta cadena, de lo contrario surgen prioridades erróneas.
Metodología: un proceso ágil que sigue siendo auditable
Para las decisiones de la dirección cuenta la consistencia. Una metodología es buena cuando distintos equipos obtienen resultados comparables en situaciones similares. Esto se logra con dimensiones de evaluación fijas y reglas claras, no con el máximo detalle.
Paso 1: Escenarios en lugar de „riesgos de activos“
Evalúe los riesgos como escenarios: „Ransomware cifra servidores de archivos y datos de aplicaciones centrales“, „la identidad en la nube se compromete y se abusa de roles admin“, „el proveedor falla y se rompe la cadena de parches y soporte“. Los escenarios son más comprensibles para las partes interesadas y pueden traducirse directamente en controles (medidas).
Paso 2: Evaluación según CIA más consecuencias operativas
Clásicamente los riesgos se evalúan según la CIA: Confidentiality (Confidencialidad), Integrity (Integridad) y Availability (Disponibilidad). Para NIS2 debería ampliarlo con una dimensión operativa/de gobernanza, por ejemplo:
- Impacto por fallo (interrupción del servicio, RTO/RPO, soluciones manuales)
- Impacto sobre los datos (datos personales, secretos empresariales, manipulación)
- Regulatorio/Contractual (obligaciones de notificación, incumplimiento de SLA, riesgos de responsabilidad)
- Cadena de suministro (puntos únicos de fallo en proveedores/software)
Así evita que la „disponibilidad“ sea subestimada porque „no hay datos sensibles“ afectados, cuando la parada operativa sería masiva.
Paso 3: Definir la fórmula de riesgo y las escalas
Lo habitual es Riesgo = Probabilidad de ocurrencia × Impacto. Es crucial que las escalas se definan por escrito: ¿Qué significa „Probabilidad 3“? ¿Cómo se justifica „Impacto 4“? Sin definición surgen valores arbitrarios.
Un enfoque pragmático es una matriz 5×5 con umbrales concretos para el impacto (en horas, rango en euros, clases de datos, número de clientes) y la probabilidad (basada en exposición, presión de ataque, historial, madurez de controles). Importante: las escalas deben ajustarse a su organización y permanecer estables en el tiempo.
Métricas que la dirección realmente necesita (y que TI puede aportar)
Un análisis de riesgos se vuelve gestionable cuando se reduce a pocas métricas comprensibles. Al mismo tiempo, las métricas deben ser integrables técnicamente, de lo contrario quedan como „números de PowerPoint“.
RTO y RPO: operacionalizar los objetivos de recuperación
RTO (Recovery Time Objective) es el tiempo de recuperación máximo tolerable de un servicio. RPO (Recovery Point Objective) es la pérdida de datos máxima tolerable medida como ventana temporal. Ambos indicadores vinculan el Análisis de Impacto en el Negocio (BIA) con las decisiones de copias de seguridad, RESTauración y arquitectura.
Regla práctica: RTO/RPO no son deseos, sino requisitos para la operación, la arquitectura y el presupuesto. Si un servicio tiene RTO=4h, pero las pruebas de RESTauración duran regularmente 12h, eso constituye un riesgo documentado y medible.
SLE und ALE: Monetización sin falsa precisión
Para decisiones presupuestarias ayuda una monetización aproximada. SLE (Single Loss Expectancy) describe el daño de un único evento, ALE (Annual Loss Expectancy) la pérdida anual esperada (SLE × frecuencia anual de ocurrencia). Esto funciona también con rangos y suposiciones conservadoras.
Lo importante es la transparencia: Documente las suposiciones (p. ej., parada de producción por hora, penalizaciones contractuales, peritaje forense externo, costes de recuperación). La dirección podrá entonces decidir conscientemente si un control es económicamente viable.
KRIs en lugar de solo KPIs: señales de alerta temprana de riesgo creciente
KRI (Key Risk Indicator) es un indicador temprano de la evolución del riesgo, en contraste con KPI (Key Performance Indicator) para el rendimiento. Ejemplos que resultan especialmente útiles en contextos NIS2:
- Backlog de parches en días por criticidad (p. ej., porcentaje de parches críticos > 14 días abiertos)
- Cobertura de MFA para accesos administrativos y remotos
- Porcentaje de sistemas sin responsabilidad sobre activos fiable (propietario desconocido)
- Tasa de éxito de copias de seguridad y RESTauración y tiempo de RESTauración en ejercicios
- Tiempo medio hasta la detección (MTTD) y tiempo medio hasta la respuesta (MTTR) para incidentes de seguridad
- Proveedores: porcentaje de proveedores de servicios críticos sin evaluación de riesgo/seguridad actual
Los KRIs son aptos para la gestión si cuentan con umbrales claros y conducen directamente a medidas (p. ej., congelación de cambios, recursos adicionales, autorización de excepción).
Límites de decisión: ¿Quién puede aceptar qué riesgo?
El núcleo de una gobernanza compatible con NIS2 no es la matriz, sino el límite de decisión. Sin límites definidos emergen dos patrones de fallo típicos: TI acepta riesgos de forma implícita «por inacción», o todo se escala y bloquea la capacidad de decisión.
Un marco de reglas de riesgo práctico (Risk Appetite & Delegation)
Defina Risk Appetite (apetito de riesgo) como marco: ¿Qué tipos de riesgos no se aceptan en principio (p. ej., falta de recuperabilidad de datos críticos, accesos administrativos sin MFA)? ¿Qué riesgos pueden tolerarse temporalmente con plazo y plan?
A continuación, defina la Delegación de autoridad: quién puede aceptar riesgos de cada nivel. Un ejemplo que ha demostrado su eficacia en muchas organizaciones:
- Verde: El responsable del equipo/servicio puede aceptar, si está documentado y el monitoreo está activo.
- Amarillo: La dirección de TI o el responsable de seguridad (CISO) debe autorizarlo, incluido el cronograma.
- Rojo: La dirección ejecutiva debe decidir; la aceptación solo debe ser temporal y con medidas compensatorias/plan de contingencia.
Estas reglas deben ser compatibles con la realidad de auditoría y responsabilidad. Lo decisivo es la trazabilidad: fecha, decisión, justificación, plazo de la aceptación, medidas compensatorias.
Del riesgo a la medida: plan de tratamiento de riesgos que funcione en la operación
Un análisis de riesgos solo está „vivo“ cuando se transforma en un plan de tratamiento de riesgos (Risk Treatment Plan). Este plan debería incluir, por cada riesgo/escenario: estado objetivo, paquetes de medidas, responsable, estimación aproximada de presupuesto, dependencias y evidencias.
Cuatro opciones de tratamiento — con escollos típicos
- Mitigación (reducir): Implementar/mejorar controles. Escollos: medidas sin reducción de riesgo medible (p. ej., concienciación sin KRI).
- Transferencia: p. ej., seguro o externalización. Escollos: la transferencia no sustituye las obligaciones de control; el proveedor debe estar integrado en la gobernanza.
- Evitar (avoid): Modificar/desactivar el servicio. Escollos: surge shadow IT si no existe alternativa.
- Aceptar (accept): De forma consciente, temporal, con monitoreo. Escollos: la „aceptación“ como excusa por falta de recursos.
Familias de controles que suelen ser altamente efectivas en análisis de riesgo NIS2
Sin dogma de framework, las medidas pueden agruparse en pocas familias de controles que puede referenciar en el análisis de riesgos:
- Identidad & Acceso: MFA, cuentas privilegiadas, modelos de roles, proceso de incorporación/movimiento/salida (Joiner/Mover/Leaver).
- Vulnerabilidades & Parches: escaneo, priorización, ventanas de mantenimiento, excepciones, estrategia EOL.
- Copia de seguridad & Recuperación: copias offline/inmutables, ejercicios de RESTauración, evidencia de RTO/RPO.
- Monitorización & Detección: logs centralizados, alertas, casos de uso, tiempo para detectar (Time-to-Detect).
- Red & Segmentación: zonificación, accesos remotos, controles Este-Oeste.
- Controles de proveedores: requisitos mínimos, evidencias, plan de salida, subcontratistas.
El beneficio operativo aumenta si cada medida tiene un camino de evidencia claro: ticket, cambio, evidencia de configuración, protocolo de prueba, informe.
Perspectiva de auditoría: qué evidencias quieren ver realmente los auditores
La preparación para auditorías no significa responder de antemano cada cuestión técnica de detalle. Significa que sus decisiones sistemáticas y repetibles son. Los revisores suelen buscar coherencia: ¿coinciden el análisis de riesgos, el plan de medidas, la respuesta a incidentes y la documentación operativa?
Paquetes de evidencia que funcionan en la práctica
- Documento de metodología: escalas, criterios, roles, ciclo de revisión, herramientas.
- Registro de riesgos: escenarios, evaluación, propietario, estado, tratamiento, aceptaciones.
- Evidencia de la implementación de medidas: registros de cambios, configuraciones del sistema, aprobaciones de políticas.
- Pruebas y ejercicios: pruebas de RESTauración, simulacros tipo tabletop, lecciones aprendidas, tareas de seguimiento.
- Documentación de proveedores: clasificación de riesgo, debida diligencia, cláusulas contractuales, vías de escalado.
Un problema recurrente es «deriva de evidencias»: se implementan medidas, pero las evidencias no se versionan o no son localizables. Esto es menos un problema de seguridad que de operación y documentación. Aquí ayudan conceptos claros de almacenamiento y una vinculación mediante IDs de ticket.
Base de datos técnica: ¿De dónde provienen de forma fiable las valoraciones y los KRI?
Las evaluaciones de riesgo ganan credibilidad cuando están vinculadas a datos medidos. Para ello no es necesario implantar de inmediato un SIEM o una herramienta ISMS completamente desarrollada. Lo decisivo es una base mínima de datos fiable.
Conjunto mínimo de fuentes de datos (realista en muchos entornos)
- CMDB/lista de activos: al menos sistema, propietario, criticidad, ubicación/hosting, estado EOL.
- Datos de vulnerabilidades y parches: informes de escáner o informes de cumplimiento de parches.
- Informes de backups: estado de trabajos, pruebas de RESTauración, tiempos de ejecución.
- Informes IAM: estado de MFA, grupos privilegiados, recertificaciones.
- Datos de incidentes y tickets: MTTD/MTTR, incidentes recurrentes, tasa de fallos en cambios (Change-Failure-Rate).
Importa el mapeo: ¿qué fuente de datos alimenta qué KRI? ¿Quién es el responsable de los datos? ¿Con qué frecuencia se actualiza? Esta «gobernanza de datos» es un factor de éxito subestimado, porque reduce las discusiones sobre la calidad de las cifras.
Plantillas, listas de verificación y plantillas de decisión (particularmente útiles para NIS2)
Para que el análisis de riesgos conforme a NIS2 funcione no solo a nivel conceptual sino en la práctica, ayuda disponer de un conjunto de plantillas estandarizadas. Puede almacenarlas y versionarlas en su ISMS (sistema de gestión de seguridad de la información) o en el sistema de gestión de calidad.
1) Plantilla de escenario de riesgo (compacta, pero completa)
Título:
Servicio/Proceso afectado:
Descripción del escenario (¿Qué ocurre?):
Disparador/Amenaza (p. ej. phishing, mala configuración, fallo de proveedor):
Vulnerabilidad (¿Por qué es posible?):
Activos afectados (sistemas, datos, interfaces):
Impacto (CIA + consecuencias operativas):
Requisito RTO/RPO:
Controles existentes (estado actual):
Probabilidad (valor en escala + justificación):
Impacto (valor en escala + justificación):
Nivel de riesgo (matriz):
Propietario:
Opción de tratamiento (mitigar/transferir/evitar/aceptar):
Paquete de medidas + fecha objetivo:
Medidas compensatorias (si se acepta):
Evidencias/Pruebas:
Fecha de revisión:2) Lógica de decisión para “rojo” (reglas de escalado y de stop/go)
Para riesgos altos hacen falta disparadores claros. Una lógica práctica es no definir «rojo» solo por la matriz, sino mediante requisitos mínimos no negociables (guardrails). Ejemplos:
- Servicio crítico sin recuperabilidad demostrada (sin prueba de RESTauración exitosa) → automáticamente rojo
- Cuentas privilegiadas sin MFA o sin recertificación → automáticamente rojo
- Sistemas expuestos a Internet sin proceso de parcheo o con software EOL → automáticamente rojo
Tales guardrails reducen las discusiones, porque definen „líneas rojas“ que la dirección debe establecer y asumir conscientemente.
3) Plantilla de decisión para la dirección (una página, apta para la toma de decisiones)
Tema/Riesgo:
Breve descripción del escenario:
Servicios críticos afectados:
Nivel de riesgo actual y tendencia (KRI):
Impacto en el peor de los casos (tiempo, datos, legal/contractual):
Opción recomendada (Mitigate/Transfer/Avoid/Accept):
Marco de costes/recursos (rango):
Fecha objetivo y hitos:
Riesgo residual tras la implementación:
Decisión (fecha, decisor, vigencia en caso de aceptación):
Condiciones/medidas compensatorias:
Próxima fecha de revisión:Cadenas de suministro y terceros: el análisis de riesgos no termina en el cortafuegos
Muchos riesgos relevantes para NIS2 dependen de proveedores: Managed Services, Cloud, mantenimiento de software externo, centro de datos, proveedores de comunicaciones. Una simple „evaluación de proveedores“ mediante cuestionario rara vez es suficiente a nivel operativo. Necesita una conexión entre el riesgo del proveedor y sus servicios críticos.
Clasificación pragmática de proveedores críticos
- Criticidad: ¿De qué servicios depende directamente? ¿Existe un plan de salida?
- Modelo de acceso: ¿Tiene el proveedor acceso privilegiado? ¿Cómo se controla esto (MFA, Jump Host, registro)?
- Dependencias: subcontratistas, puntos únicos de fallo, interfaces propietarias.
- Evidencias: informes, pruebas de penetración, estadísticas de disponibilidad, procesos de incidentes (sin exigir necesariamente certificaciones).
Operativamente importante es la pregunta: ¿Con qué rapidez se entera usted de fallos o incidentes de seguridad en el proveedor, y cómo se incorpora eso en su lógica de notificación y escalado?
En profundidad, este tema puede enlazarse bien con un programa propio de cadena de suministro; en muchas organizaciones conviene que Compras, Jurídico, TI y Seguridad participen conjuntamente en un ciclo recurrente de valoración.
Ciclo de revisión y operación: el análisis de riesgos como proceso continuo
NIS2 no espera que se genere un documento una vez al año. La realidad es dinámica: nuevas superficies de ataque, migraciones de sistemas, cambios en la nube, nuevos proveedores, rotación de personal. Para que el análisis de riesgos „viva“, necesita un ritmo y motivos claros para la nueva evaluación.
Disparadores recomendados para reevaluaciones
- Cambios importantes: nuevos emplazamientos, migración a la nube, nueva aplicación central, cambio de centro de datos
- Incidentes de seguridad: especialmente ante patrones de recurrencia o nuevos métodos de ataque
- Auditorías y hallazgos: cuando faltan evidencias o los controles no son efectivos
- Cambios de proveedor: nuevos MSP, nuevos proveedores SaaS, condiciones contractuales modificadas
RACI e interfaces con los procesos ITIL/Change
Para que las decisiones de riesgo no se gestionen de forma paralela, deben integrarse en los procesos existentes. Un Change Advisory Board puede, por ejemplo, servir como punto de control en el que los cambios relevantes para el riesgo solo se aprueban con una evaluación documentada. Lo decisivo no es el órgano, sino la regla: „Ningún cambio crítico sin verificación de riesgos y plan de reversión.“
Lógica de costes y ejecución: Cómo convertir prioridades de riesgo en un programa sólido
La dirección pregunta con razón por el esfuerzo, los efectos secundarios y el orden. Un buen análisis de riesgos no solo proporciona „rojo/amarillo/verde“, sino un portafolio aplicable: medidas de impacto rápido, medidas estructurales y modernización a largo plazo.
Un modelo de portafolio pragmático
- Medidas inmediatas (0–6 semanas): establecer guardrails (MFA para administradores, endurecimiento de copias de seguridad, línea base de registro, parada de EOL).
- Estabilización (6 semanas–6 meses): proceso de parches y gestión de vulnerabilidades, ejercicios de RESTauración, playbooks de incidentes, roles/recertificación.
- Estructural (6–18 meses): segmentación, modernización de identidades, centralización de logs, programa de proveedores, automatización.
Es clave el análisis de efectos secundarios: algunos controles aumentan la complejidad a corto plazo (p. ej. segmentación) o requieren madurez operativa (p. ej. alertas que no terminen en fatiga por alertas). Estos riesgos también deben figurar en el registro: „riesgo de control“ es real.
Conclusión: Un análisis de riesgos NIS2 es válido cuando obliga a tomar decisiones
Un análisis de riesgos según NIS2 no tiene éxito por estar elegantemente modelado, sino porque tiene consecuencias: líneas rojas claras, decisiones de aceptación justificables, KRIs mensurables y un plan de tratamiento de riesgos anclado en la operación. Si define con claridad el alcance, la metodología y las competencias decisorias, surge un sistema que mejora la preparación para auditorías y, al mismo tiempo, aligera la carga diaria de TI: menos sorpresas, mejores prioridades, mayor transparencia sobre la deuda técnica y las dependencias.
Si desea profundizar en los bloques adyacentes, es especialmente recomendable estructurar y enlazar internamente gobernanza, hoja de ruta de implementación, lógica presupuestaria y gestión de la cadena de suministro como una serie de artículos interconectados.
Para este tema también son importantes la gestión de riesgos NIS2 y la evaluación de los riesgos de seguridad de TI. El artículo contextualiza estos aspectos de forma comprensible y muestra qué importa en el día a día.