Referencia · Artículo 21Última revisión el 18 may 2026
Las 21 medidas, explicadas con claridad.
El artículo 21 de la Directiva (UE) 2022/2555 enumera diez categorías de medidas de gestión del riesgo de ciberseguridad. Las hemos desglosado en 21 puntos de control concretos, agrupados según lo que su equipo debe entregar realmente.
§ 01
Gobernanza
La NIS2 convierte la ciberseguridad en una obligación del consejo. El artículo 20 exige a los órganos de dirección aprobar las medidas de gestión del riesgo, supervisar su aplicación y seguir formación que les permita identificar y gestionar el riesgo cibernético. El mismo artículo establece la responsabilidad personal de los administradores — ruptura deliberada con NIS1. En la práctica, se requieren cuatro artefactos: política de seguridad aprobada por el consejo, roles y rendición de cuentas por escrito, formaciones registradas y una revisión independiente elevada al consejo. Sin este armazón, el resto del artículo 21 no se sostiene. El Reglamento de Ejecución 2024/2690 trata la gobernanza como condición previa de cualquier otra categoría de control.
- M.01
Políticas de seguridad de la información — aprobadas a nivel de consejo
Una política escrita aprobada por el consejo fija el apetito de riesgo, el alcance y la cadencia de revisión — sin ella, cualquier otro control queda al albur. El Anexo A.5.1 de ISO 27001 es la referencia operativa.
- M.02
Roles, responsabilidades y rendición de cuentas formalmente documentados
Cada control tiene un propietario nombrado; la segregación de funciones está documentada para operaciones de alto riesgo. Los supervisores preguntarán «quién aprobó» tras un incidente.
- M.03
Formación de los administradores sobre el riesgo de ciberseguridad
El artículo 20, apartado 2, hace obligatoria y trazable la formación de los administradores. Los módulos de sensibilización genéricos no bastan — la formación debe permitir entender los riesgos específicos de la entidad.
- M.04
Revisión independiente anual del programa de seguridad
Una auditoría externa o interna independiente que revise la madurez del programa cada año. Las conclusiones se elevan al consejo con plan de remediación y calendario.
§ 02
Gestión de riesgos
El artículo 21, apartado 2, letra a) exige políticas de análisis de riesgos y de seguridad de los sistemas de información. La letra c) añade continuidad de negocio, gestión de copias de seguridad y gestión de crisis. Es el puente entre la intención de gobernanza y la ejecución técnica: metodología de riesgos por escrito, registro vivo actualizado con nuevas amenazas y cambios de activos, inventario que refleje lo que se opera realmente, y planes de continuidad cuyos procedimientos de restauración hayan sido probados — no solo redactados. Los supervisores NIS2 esperan pruebas de ejercicio, no solo documentos. Pruebas de restauración, simulacros de mesa y actas firmadas conforman la pista de auditoría que convierte un registro en papel en un programa defendible.
- M.05
Metodología de análisis de riesgos y registro de riesgos actualizado
Una metodología documentada (cualitativa o cuantitativa) y un registro revisado al menos trimestralmente. Los registros estáticos son una alerta típica para los supervisores.
- M.06
Inventario de activos: sistemas de información y datos
No se puede proteger lo que se ignora operar. El inventario cubre hardware, software, servicios cloud, flujos de datos y dependencias — actualizado automáticamente cuando sea posible.
- M.07
Planes de continuidad de negocio y de gestión de crisis
Los planes cubren pérdida de sitio, pérdida de proveedor y pérdida de acceso. Definen RTO/RPO por servicio, protocolos de comunicación y la cadena de mando durante una crisis.
- M.08
Copias de seguridad: procedimientos de restauración probados
Una copia de seguridad nunca restaurada es teórica. NIS2 espera evidencias de pruebas regulares de restauración, idealmente con configuraciones resistentes a ransomware (inmutables, offline o air-gapped).
§ 03
Medidas técnicas
El artículo 21, apartado 2, lista la base técnica: criptografía (letra h), autenticación multifactor (letra j), gestión de incidentes (letra b), seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas (letra e), seguridad del personal y control de accesos (letra i). El Reglamento de Ejecución 2024/2690 traduce esos puntos en controles concretos — MFA en accesos remotos y privilegiados, segmentación entre zonas de confianza, gestión de vulnerabilidades con cadencia de parcheo, EDR en endpoints, ciclo de desarrollo seguro para código propio y de proveedores. Nada nuevo en el fondo: todo se alinea con el Anexo A de ISO 27001 y el NIST CSF. La NIS2 transforma la «buena práctica» en suelo legal con derecho de inspección.
- M.09
Autenticación multifactor en todos los accesos críticos
El artículo 21, apartado 2, letra j) exige MFA explícitamente. El acceso crítico incluye cuentas de administrador, acceso remoto, aplicaciones expuestas y acceso a datos sensibles — los factores resistentes al phishing son cada vez más exigidos.
- M.10
Política de criptografía y cifrado
Una política que especifique algoritmos, ciclo de vida de las claves y dónde se requiere cifrado (datos en reposo, en tránsito, en copias). ENISA apunta a la preparación post-cuántica como criterio prospectivo.
- M.11
Segmentación de red y principios de zero-trust
Las redes planas convierten un compromiso inicial en un apagón sectorial. La segmentación aísla los sistemas críticos; el zero-trust sustituye la confianza implícita por verificación continua de identidad y postura del dispositivo.
- M.12
Gestión de vulnerabilidades y cadencia de parcheo
Un SLA documentado de parcheo por severidad (crítico / alto / medio), un proceso de parches de emergencia fuera de banda, y seguimiento de excepciones para sistemas no parcheables con controles compensatorios.
- M.13
Detección y respuesta en endpoints (EDR)
EDR o XDR en estaciones y servidores — más allá del antivirus tradicional. La telemetría debe conservarse el tiempo suficiente para investigación forense (típicamente 6–12 meses) y alimentar el SOC o MSSP.
- M.14
Ciclo de desarrollo de software seguro
Modelado de amenazas en el diseño, escaneo de dependencias en CI, detección de secretos, revisión de código y pruebas en tiempo de ejecución. Aplica por igual a equipos internos y a desarrolladores externalizados.
§ 04
Cadena de suministro
El artículo 21, apartado 2, letra d) eleva la seguridad de terceros a obligación directa: la entidad debe abordar los riesgos derivados de proveedores y prestadores de servicios. Las evaluaciones coordinadas del Grupo de Cooperación (plantilla derivada de la 5G toolbox) anuncian la trayectoria — evaluaciones sectoriales de proveedores críticos, con mitigaciones que pueden llegar hasta restricciones de proveedor. Tres capas en la práctica: evaluaciones de seguridad precontractuales, cláusulas contractuales que se sostengan en operaciones (notificación, auditoría, control de subcontratistas), monitorización continua de la exposición a terceros (incidentes, sanciones, riesgo geopolítico). Kaseya, SolarWinds y MOVEit son la referencia implícita: un proveedor crítico puede hacer caer un sector entero, y el supervisor querrá ver su mapa de proveedores.
- M.15
Evaluaciones de seguridad de proveedores
Estratifique a sus proveedores (¿cuáles pueden derribarle?) y exija evaluaciones de seguridad proporcionales al estrato — cuestionarios, certificaciones (ISO 27001, SOC 2) o auditorías in situ para los más críticos.
- M.16
Cláusulas de seguridad contractuales para proveedores críticos
Derecho de auditoría, plazos de notificación de incidentes (alineados con sus propias obligaciones NIS2), localización de datos cuando sea exigida, divulgación de subprocesadores, asistencia de salida/transición. Las cláusulas deben sobrevivir a renovaciones y a fusiones y adquisiciones.
- M.17
Monitorización continua de la exposición a terceros
Monitorización de la superficie de ataque externa, cribado de sanciones, inteligencia de brechas y reevaluación ante cambios accionariales en el proveedor. Un cuestionario anual estático no cumple la exigencia «continua» de NIS2.
§ 05
Gestión de incidentes
El artículo 23 fija una cadencia en tres tiempos: alerta temprana a las 24 horas, notificación de incidente a las 72 horas con evaluación inicial de gravedad, informe final en el plazo de un mes. El detonante es el incidente «significativo» — el que ha causado o puede causar una grave perturbación operativa, pérdidas financieras o impacto en terceros. Tras estos plazos, los artefactos operativos: playbooks de detección y clasificación, cadena de escalado que llegue al CSIRT o a la autoridad competente, matriz de gravedad utilizable por la guardia a las 3 de la madrugada, y proceso de lecciones aprendidas. Varios reguladores ya publican baremos por incumplimiento de plazos — cumplir 24/72/30 es la línea más barata del programa.
- M.18
Playbooks de detección, clasificación y escalado
Runbooks documentados para los escenarios probables (ransomware, exfiltración de datos, DDoS, compromiso de cadena de suministro, amenaza interna). Cada runbook lista pasos de triaje, criterios de clasificación y la cadena de escalado.
- M.19
Alerta temprana 24 h al CSIRT
En las 24 horas tras tener conocimiento de un incidente significativo, alerta temprana al CSIRT o autoridad competente — incluso con información parcial. El reloj arranca con el conocimiento, no con la comprensión completa.
- M.20
Notificación de incidente a 72 h con evaluación de gravedad
Notificación formal en 72 horas con la gravedad inicial, indicadores de compromiso y eventual impacto transfronterizo. Las actualizaciones siguen la evolución de la valoración.
- M.21
Informe final en el plazo de un mes
Informe detallado en el plazo de un mes que cubra causa raíz, impacto real, mitigaciones aplicadas y lecciones aprendidas. Este informe es la base de cualquier seguimiento del supervisor.
Acción · Iniciar la autoevaluación§ Acción
¿Listo para poner cifras a esto?
Haga la autoevaluación de 21 puntos. Puntuación en dos minutos. Salga con un plan de acción priorizado, listo para presentar a su consejo.