GRCreal // expediente: artículo categoría: NIS2
← Volver a artículos
NIS2 · Técnico · Cumplimiento

NIS2 Art. 21: las medidas técnicas que el regulador espera ver

No basta con decir que tenéis medidas de seguridad.
Hay que poder demostrarlas.

Miguel Ángel Carriazo 18 junio 2026 10 min de lectura
El Artículo 21 en detalle

Las 10 categorías de medidas

El Artículo 21 de NIS2 establece que las entidades esenciales e importantes deben adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos para la seguridad de las redes y sistemas de información. Y enumera diez categorías de medidas mínimas.

No es una lista de verificación — es un marco de referencia. Cada categoría debe implementarse de forma proporcional al riesgo, al tamaño y a la complejidad de la organización. Lo que es adecuado para una entidad esencial en el sector energético puede ser desproporcionado para una entidad importante en el sector postal.

Pero "proporcional" no significa "mínimo". El regulador evaluará si las medidas son razonables dado el nivel de riesgo — y la carga de la prueba es de la organización.
Capas de control · NIS2
La protección real no depende de una sola medida
Las 10 categorías de…Dónde se enfoca la…Cómo justificar el nivel…Qué esperaría encontrar…Las evidencias que el…LA FORTALEZA DEPENDE DE LA CAPA MÁS DÉBIL
Las capas se complementan; una medida aislada no sustituye al diseño y la verificación del conjunto.
Las medidas con más scrutinio regulatorio

Dónde se enfoca la supervisión

Gestión de riesgos: el regulador espera ver un proceso documentado de identificación y evaluación de riesgos, no solo una lista. ¿Qué metodología? ¿Con qué periodicidad? ¿Quién lo aprueba? ¿Cómo se conecta con las medidas implementadas?

Gestión de incidentes: procedimiento de respuesta, roles definidos, canal de notificación al CSIRT probado, registros de incidentes previos. No el procedimiento en papel — las evidencias de que se usa.

Continuidad de negocio: BCP documentado y probado. El regulador diferencia entre organizaciones que tienen el plan y organizaciones que tienen el plan y lo han probado. Las pruebas documentadas son la evidencia que distingue los dos.

Seguridad de la cadena de suministro: inventario de proveedores críticos, evaluación de su postura de seguridad, requisitos contractuales. Muchas organizaciones tienen el inventario pero no la evaluación ni las cláusulas contractuales.

Autenticación multifactor: el regulador espera MFA en todos los accesos sensibles. No en algunos — en todos. Y espera poder verlo implementado, no solo declarado.
Lectura operativa GRCREAL
Qué entender

Las 10 categorías de medidas. Delimita el problema antes de elegir una respuesta.

Qué comprobar

Dónde se enfoca la supervisión. Busca una práctica observable, no solo una declaración.

Qué poder demostrar

Las evidencias que el regulador pedirá. La decisión y su revisión deben dejar trazabilidad.

La proporcionalidad en la práctica

Cómo justificar el nivel de implementación

La proporcionalidad es la defensa legítima de las organizaciones cuando no pueden implementar medidas de nivel máximo. Pero debe estar justificada — no simplemente declarada.

La justificación de proporcionalidad debe basarse en: el nivel de riesgo real de la organización, su tamaño y recursos disponibles, el impacto potencial de un incidente en sus usuarios y en los servicios que presta, y los costes de implementación en relación con el beneficio en términos de reducción de riesgo.

Una pyme de 60 empleados en el sector postal no necesita un SOC 24x7. Pero sí necesita MFA, gestión de parches, backup verificado y un procedimiento de notificación de incidentes. La proporcionalidad justifica no tener el SOC, no justifica no tener los controles básicos.

El regulador no espera perfección — espera que las medidas sean razonables dado el contexto y que la organización pueda explicar y justificar sus decisiones.
Evidencia operativa

Qué esperaría encontrar para demostrar que esto funciona

La evidencia concreta depende del alcance y del contexto de la organización. Aun así, una revisión seria debería poder reconstruir al menos estas tres capas:
Ref.Capa de evidenciaQué debería permitir comprobar
EV-01Mapa de requisitos y responsablesQuién es responsable, qué alcance se ha definido y qué decisión se ha tomado.
EV-02Decisiones del órgano de direcciónQue el control o proceso se aplica sobre casos reales y no existe únicamente en la documentación.
EV-03Controles, incidentes y proveedoresQue las desviaciones se detectan, se corrigen y vuelven a revisarse con una frecuencia razonable.
Cómo demostrar el cumplimiento

Las evidencias que el regulador pedirá

NIS2 no exige certificación — pero sí espera que las organizaciones puedan demostrar que tienen las medidas implementadas. En una inspección o tras un incidente, el regulador pedirá evidencias concretas.

Para cada categoría del Art. 21, las evidencias típicas son: documentos (políticas, procedimientos, análisis de riesgos), registros (logs, histórico de incidentes, actas de revisión), configuraciones técnicas y resultados de pruebas (pruebas de backup, ejercicios de continuidad, resultados de auditorías).

Las evidencias deben ser actuales — de los últimos 12 meses — y coherentes entre sí. Una política de gestión de accesos que diga que los accesos se revisan anualmente necesita los registros de esas revisiones. Si la política dice una cosa y los registros demuestran otra, el regulador sabrá cuál de las dos es la realidad.

El mejor sistema de cumplimiento NIS2 no es el que tiene más documentación — es el que tiene evidencias reales de que los controles funcionan.
Guía de aplicación

Cómo llevar «NIS2 Art. 21: las medidas técnicas que el regulador espera ver» a un modelo operativo

El error habitual al abordar este tema es convertirlo demasiado pronto en un documento o en una lista de tareas. En NIS2, yo lo llevaría primero a un modelo operativo verificable: qué queda dentro del alcance, quién puede decidir, qué condiciones activan una revisión y qué rastro queda después de cada actuación.

Para este caso partiría de alcance y contexto. No porque sea el único punto importante, sino porque permite fijar el contexto antes de discutir controles. A partir de ahí conectaría riesgo, controles y responsables con la realidad del entidad y servicio afectado y cerraría el ciclo con evidencia, revisión y mejora.

La pregunta que utilizaría para probar la madurez sería sencilla: ¿puede una persona que no participó en el proyecto reconstruir la decisión, entender el riesgo y localizar la evidencia sin depender de una explicación oral? Si la respuesta es no, existe conocimiento, pero el gobierno todavía depende de personas concretas.

Mi enfoque

No intentaría implantar todo de una vez. Seleccionaría un caso representativo, documentaría la cadena alcance, riesgo, medidas, incidente y supervisión y comprobaría dónde se pierde la trazabilidad.

El primer objetivo no sería «tener más documentación», sino conseguir que el órgano de gestión y responsables operativos pueda demostrar qué decidió, por qué lo decidió y cómo sabe que el control sigue funcionando.

Plano de revisiónQué comprobaríaSeñal de debilidadEvidencia útil
ContextoAlcance y contexto; límites, dependencias y supuestos.El alcance cambia según quién lo explique.Ficha de alcance, inventario o mapa de dependencias vigente.
GobiernoPropietario, capacidad de decisión, escalado y excepciones.IT ejecuta, pero nadie de negocio acepta el riesgo.RACI, acta, ticket de decisión o registro de aceptación.
ControlRiesgo, controles y responsables; diseño, cobertura y operación real.Se describe el control, pero no su población ni frecuencia.Configuración, procedimiento, muestra de ejecución y resultado.
SupervisiónEvidencia, revisión y mejora; umbrales, desviaciones y revisión.Solo se revisa cuando llega una auditoría o un incidente.KPI/KRI, revisión periódica, hallazgo y acción de mejora.
Secuencia de trabajo
01 · Reconstruir

Utilizar «Las 10 categorías de medidas» como punto de entrada para describir la realidad actual, incluidas excepciones y dependencias que no aparecen en el procedimiento.

02 · Contrastar

Tomar «Dónde se enfoca la supervisión» y comprobarlo con una muestra real. La documentación debe coincidir con usuarios, activos, configuraciones, decisiones o registros.

03 · Cerrar el ciclo

Relacionar «Cómo justificar el nivel de implementación» con un responsable, una fecha y una evidencia de revisión. Una desviación sin seguimiento es información, no gobierno.

Revisión crítica

Diez preguntas que utilizaría para revisar este tema

Estas preguntas no sustituyen una auditoría ni una evaluación formal. Sirven como prueba rápida de coherencia: si varias respuestas dependen de «creo», «normalmente» o «lo lleva otra persona», ya existe una línea de trabajo.

  1. ¿Qué está exactamente dentro del alcance? Debe poder delimitarse el entidad y servicio afectado sin recurrir a una descripción ambigua.
  2. ¿Quién es el propietario real? El órgano de gestión y responsables operativos debe conocer su responsabilidad y tener capacidad para escalar o decidir.
  3. ¿Qué escenario de riesgo estamos intentando evitar o limitar? Un control sin escenario asociado se evalúa por presencia, no por eficacia.
  4. ¿Qué depende de alcance y contexto? Hay que identificar supuestos, datos de entrada, servicios y terceros que cambian la exposición.
  5. ¿Cómo sabemos que riesgo, controles y responsables funciona sobre toda la población? Una muestra positiva no demuestra cobertura completa.
  6. ¿Qué excepciones existen hoy? Deben tener propietario, motivo, riesgo aceptado, compensación y caducidad cuando proceda.
  7. ¿Qué evidencia queda después de ejecutar el control? La evidencia debe ser recuperable, fechada y entendible por una tercera persona.
  8. ¿Qué indicador obliga a actuar? Medir sin umbral, tendencia o decisión asociada termina creando cuadros de mando decorativos.
  9. ¿Cuándo se revisó por última vez evidencia, revisión y mejora? El cambio de contexto puede invalidar una decisión que era razonable seis meses antes.
  10. ¿Qué aprendimos de la última desviación? Si el hallazgo se cierra corrigiendo el síntoma y no cambia el sistema, probablemente volverá.
Pregunta incómoda

Si mañana la persona que domina este tema deja la organización, ¿el sistema seguiría funcionando y podríamos demostrar por qué se tomaron las decisiones? Esa respuesta suele revelar el nivel real de institucionalización.

Evidencia mínima

Qué conservaría para poder demostrar que el control está vivo

La cantidad de documentación no es una medida de madurez. Para «NIS2 Art. 21: las medidas técnicas que el regulador espera ver» prefiero una cadena corta de evidencias conectadas a la operación. Cada pieza debe responder a una pregunta distinta: qué decidimos, qué hicimos, qué ocurrió y qué revisamos después.

La siguiente matriz es el paquete mínimo que intentaría localizar en una revisión. El formato puede ser un acta, un ticket, una exportación, una configuración o un registro de una herramienta; lo importante es la trazabilidad y la coherencia entre las piezas.

Ref.EvidenciaQué debería demostrarQué revisaría
EV-01Alcance y propietarioQué cubre el control y quién responde por él.Vigencia, exclusiones, dependencias y aceptación del propietario.
EV-02Criterio de riesgoPor qué se ha priorizado o diseñado de una forma concreta.Alcance y contexto, escenario, impacto y supuestos utilizados.
EV-03Diseño del controlQué debe ocurrir, sobre qué población y con qué frecuencia.Riesgo, controles y responsables, responsables, entradas, salidas y excepciones.
EV-04Muestra de ejecuciónQue el control opera fuera del documento.Fecha, población, resultado, anomalías y trazabilidad técnica u operativa.
EV-05Desviación y tratamientoCómo responde la organización cuando el control falla.Causa, riesgo residual, responsable, plazo y medida compensatoria.
EV-06Revisión y mejoraQue evidencia, revisión y mejora se evalúa y puede cambiar.Indicadores, tendencia, decisiones, cambios aprobados y seguimiento.
Visión de auditor

Yo intentaría seguir una sola muestra de extremo a extremo. Si EV-01 dice una cosa, EV-03 otra y EV-04 no permite identificar la población afectada, el problema no es «falta de un PDF»: es una ruptura de trazabilidad.

Documentación operativa

Cómo convertir este tema en un expediente verificable

La forma más útil de trabajar este tema es convertirlo en una cadena verificable de decisiones, responsables y evidencias. No basta con afirmar que existe un control: hay que poder reconstruir qué se decidió, con qué información, quién lo ejecutó y cómo se comprobó después.

En NIS2 Art. 21: las medidas técnicas que el regulador espera ver, el análisis debería cubrir al menos alcance, órgano de dirección, servicios, riesgos, medidas, incidentes, continuidad y cadena de suministro. Esto exige coordinar a Órgano de dirección, Seguridad, Riesgos, Continuidad, Operaciones, Compras y proveedores y trabajar sobre servicios, redes, sistemas, datos, terceros, incidentes y continuidad. Cuando cada área conserva una parte distinta de la información, se retrasan decisiones, se duplican controles y se aceptan excepciones sin una visión completa.

Una forma práctica de evitarlo es utilizar un expediente único por servicio, sistema, proceso o decisión relevante. Puede ser una herramienta GRC, un repositorio documental controlado o un registro estructurado. Lo importante es conectar alcance, propietario, riesgo, control, evidencia, excepción y acción, con fecha, fuente y estado.

Ese expediente debe mantenerse durante la operación ordinaria. Si solo se completa antes de una auditoría, la organización obtiene una fotografía preparada, pero no una visión fiable del control. La actualización debería activarse ante cambios de arquitectura, proveedor, alcance, responsables, requisitos, incidentes o resultados de pruebas. También conviene definir una revisión periódica para detectar documentación formalmente vigente pero materialmente obsoleta.

La revisión debe separar cuatro preguntas: si el control está bien diseñado, si se ha implantado en todo el alcance, si funciona de forma sostenida y si reduce realmente el riesgo o cumple el objetivo. Mezclar estas preguntas lleva a conclusiones débiles: una política aprobada puede no haberse desplegado, una herramienta instalada puede no cubrir toda la población y una actividad ejecutada puede no producir el efecto esperado.

DimensiónQué debe quedar definidoEvidencia esperada
AlcanceProcesos, servicios, sistemas y terceros incluidos en «NIS2 Art. 21: las medidas técnicas que el regulador espera ver».Alcance aprobado, inventario y exclusiones justificadas.
ResponsabilidadQuién decide, ejecuta, valida y acepta desviaciones.RACI, actas, aprobaciones y propietarios nominativos.
OperaciónActividades repetibles, entradas, salidas, plazos y escalados.Procedimiento, tickets, registros, alertas y métricas.
EficaciaCómo se comprueba que el control cambia el riesgo o el resultado.Pruebas, tendencias, incidencias, muestreo y acciones.
Escenario de validación

Prueba de extremo a extremo

  1. Partir de una entidad con servicios críticos, infraestructura híbrida y proveedores relevantes y delimitar alcance, órgano de dirección, servicios, riesgos, medidas, incidentes, continuidad y cadena de suministro.
  2. Contrastar la documentación declarada con arquitectura, proceso, responsables y operación real.
  3. Seleccionar una muestra reciente y seguirla desde el evento de origen hasta su cierre.
  4. Distinguir entre fallo puntual, deficiencia de diseño y problema operativo recurrente.
  5. Verificar la corrección mediante una prueba posterior y no solo mediante una declaración de cierre.
Punto de control

Una captura demuestra un estado puntual. Un expediente completo demuestra el proceso, el criterio, la trazabilidad y la capacidad de corregir.

Evidencias mínimas

Qué conservaría para una revisión seria

  • alcance, decisiones del órgano de dirección, riesgos, medidas, incidentes, notificaciones, contratos y pruebas
  • criterio aplicado y versión de la referencia utilizada
  • población, periodo y muestra revisados
  • excepciones, aceptación de riesgo y fecha de caducidad
  • resultado de eficacia y acciones derivadas
Preguntas de contraste

Qué preguntaría antes de darlo por implantado

  • ¿Qué parte de «NIS2 Art. 21: las medidas técnicas que el regulador espera ver» está dentro del alcance y qué queda fuera?
  • ¿Quién aprueba una excepción, por qué y durante cuánto tiempo?
  • ¿Qué evidencia nace automáticamente de la operación y cuál se prepara manualmente?
  • ¿Cómo se detecta que el gobierno, la gestión del riesgo, la respuesta a incidentes, la continuidad, la cadena de suministro y la formación deja de funcionar?
  • ¿Cuál fue la última prueba que cambió una decisión, un diseño o una prioridad?
  • ¿Puede una persona ajena al proceso reconstruir el expediente sin explicaciones adicionales?

El objetivo no es generar más documentación, sino conservar la documentación que permite gobernar, operar y demostrar. La madurez aparece cuando las evidencias nacen del proceso ordinario y no de una campaña previa a la auditoría.

¿Podéis demostrar al regulador
que tenéis las medidas del Art. 21 implementadas?
Declararlo no es suficiente — hay que evidenciarlo.
La evidencia debe existir antes de la inspección.
Sobre el autor
Miguel Ángel Carriazo · vCISO

vCISO · Arquitecto de Soluciones de Infraestructura y Ciberseguridad | Gobierno, Riesgo y Cumplimiento (GRC) | Gobierno de IA · ISO 42001 | Fundador de GRCreal

Compartir artículo