Una auditoría NIS2 verifica el grado de cumplimiento de tu organización con las 10 áreas del artículo 21 de la Directiva. La metodología que aplicamos en proyectos reales se estructura en 5 fases: análisis de aplicabilidad, GAP analysis frente al artículo 21, pruebas técnicas (pentesting, arquitectura, cadena de suministro, threat modeling), procedimiento de notificación 24h/72h y plan de remediación con roadmap. Una auditoría inicial dura 6–10 semanas y produce evidencias defendibles ante una inspección de la autoridad competente. Si ya tienes ISO 27001:2022 implantada, partes de un 65–75% del camino: los huecos típicos son notificación 24h/72h, cadena de suministro y formación específica del consejo.
Antes de auditar: ¿NIS2 me aplica?
La primera pregunta no es cómo me audito, sino si la auditoría es obligatoria. NIS2 aplica a entidades de los Anexos I y II de la Directiva con 50+ empleados o > 10 M€ de facturación, más excepciones tasadas (DNS, TLDs, servicios de confianza cualificados, etc.). Si tienes dudas, revisa la guía completa de NIS2 en España antes de seguir.
Si la respuesta es "no aplica directamente pero suministramos a un obligado", la auditoría sigue siendo recomendable: el obligado va a exigirte contractualmente medidas equivalentes (gestión de cadena de suministro, artículo 21 letra d).
Las 5 fases de una auditoría NIS2
| Fase | Contenido | Duración |
|---|---|---|
| 1. Aplicabilidad y alcance | Determinar si NIS2 aplica, en qué categoría y a qué entidades del grupo | Semana 1 |
| 2. GAP analysis del artículo 21 | Mapeo de las 10 áreas obligatorias contra controles existentes | Semanas 2-4 |
| 3. Pruebas técnicas | Pentesting, arquitectura, cadena de suministro, threat modeling | Semanas 4-8 |
| 4. Procedimiento de notificación | Diseño 24h / 72h / 1 mes con simulacro | Semanas 6-8 |
| 5. Plan de remediación | Roadmap a 12 meses con priorización | Semanas 8-10 |
Fase 1 — Análisis de aplicabilidad y alcance
Qué se hace
Determinar si NIS2 aplica, en qué categoría (esencial / importante) y a qué entidades del grupo, identificando los servicios cuya interrupción podría considerarse "incidente significativo".
Pasos concretos
- Mapeo de actividades CNAE/NACE de cada entidad del grupo frente a Anexos I y II.
- Cómputo de empleados y facturación consolidada (criterio de mediana/gran empresa de la Recomendación 2003/361/CE).
- Identificación de filiales que prestan servicios incluidos.
- Determinación de servicios críticos: aplicaciones, infraestructuras y procesos cuya interrupción afectaría la continuidad operativa.
- Mapa de actores: clientes B2B obligados, proveedores TIC críticos, autoridad competente, CSIRT competente.
Entregables
- Documento formal de aplicabilidad y alcance, firmado por el órgano de dirección.
- Inventario priorizado de servicios críticos.
- Listado de autoridades y CSIRT con datos de contacto operativos.
Errores frecuentes
- Excluir filiales europeas porque "facturan poco" sin consolidar a nivel de grupo.
- No considerar que un servicio compartido entre entidades obligadas y no obligadas suele tener que tratarse como obligado.
- Asumir que un Real Decreto-ley o transposición posterior reducirá el alcance — la directiva fija un suelo, no un techo.
Fase 2 — GAP analysis frente al artículo 21
Las 10 áreas obligatorias del artículo 21
El artículo 21.2 lista las áreas mínimas que toda entidad obligada debe cubrir:
| # | Área del artículo 21 | Pregunta clave que se audita |
|---|---|---|
| a | Análisis de riesgos y políticas de seguridad de los sistemas de información | ¿Existe un análisis de riesgos vivo, aprobado por dirección y revisado al menos anualmente? |
| b | Gestión de incidentes | ¿Hay procedimiento documentado de detección, clasificación, respuesta y comunicación? |
| c | Continuidad de actividad: copias de seguridad, recuperación tras desastre, gestión de crisis | ¿Existen RTO/RPO por servicio crítico, BCP/DRP probados y plan de gestión de crisis? |
| d | Seguridad de la cadena de suministro | ¿Hay inventario de proveedores TIC críticos, evaluación periódica y cláusulas contractuales? |
| e | Seguridad en adquisición, desarrollo y mantenimiento de sistemas, gestión y revelación de vulnerabilidades | ¿Hay SDLC seguro, gestión de vulnerabilidades, política de divulgación responsable? |
| f | Políticas y procedimientos para evaluar la eficacia de las medidas | ¿Hay auditorías internas, pentesting, métricas de seguridad y revisión por dirección? |
| g | Prácticas básicas de ciberhigiene y formación | ¿Plan de formación obligatorio, formación específica para el consejo y campañas anti-phishing? |
| h | Políticas y procedimientos sobre uso de criptografía y, en su caso, cifrado | ¿Existen estándares de criptografía, gestión de claves y cifrado de datos en reposo y en tránsito? |
| i | Seguridad de los recursos humanos, control de acceso y gestión de activos | ¿Hay verificación de antecedentes, segregación de funciones, IAM, inventario de activos? |
| j | Autenticación multifactor, soluciones de comunicación segura y comunicación de emergencia | ¿MFA en accesos privilegiados y remotos, comunicación cifrada, canales out-of-band? |
Cómo se ejecuta el GAP analysis
- Recolección de evidencias de cada control: políticas, registros, configuraciones, logs, contratos, actas.
- Entrevistas estructuradas con propietarios de control (CISO, IT Manager, RRHH, Legal, Compras, equipos de producto).
- Mapeo a marcos de referencia ya implantados: ISO 27001:2022 (Anexo A), ENS (Real Decreto 311/2022), NIST CSF 2.0.
- Clasificación de gaps por:
- Criticidad: alta / media / baja
- Esfuerzo de remediación: bajo / medio / alto
- Tiempo estimado y dependencias
Si ya tienes ISO 27001:2022
Partes de un 65–75% del camino. Los gaps típicos que detectamos son:
- Notificación 24h/72h/1 mes: el procedimiento de incidentes ISO no contempla los plazos NIS2.
- Cadena de suministro: ISO exige cláusulas; NIS2 exige verificación activa, evaluación periódica y consideración del riesgo agregado.
- Formación específica del consejo: ISO no la exige formalmente; NIS2 sí.
- Responsabilidad personal de directivos: requiere documentar la due diligence del consejo.
- Pruebas de eficacia: NIS2 implica pentesting y evaluaciones técnicas regulares más allá de la auditoría interna ISO.
Cobertura completa en ISO 27001 + NIS2.
Si tienes ENS Real Decreto 311/2022
Cobertura similar a ISO 27001, con un plus en gobernanza y categorización. Los gaps son los mismos más algunos específicos sobre cadena de suministro privada (el ENS está pensado para sector público).
Fase 3 — Pruebas técnicas
NIS2 no exige una "certificación NIS2" formal, pero el artículo 21 letra f obliga a evaluar la eficacia de las medidas. En auditoría real esto significa pruebas técnicas concretas, no solo revisión documental.
Pentesting alineado a NIS2
- Aplicaciones web/API críticas: pentesting OWASP-aligned con foco en aplicaciones que soporten servicios cuya interrupción sería incidente significativo.
- Infraestructura externa: pentesting de superficie expuesta a internet.
- Infraestructura interna: assumed-breach scenario, escalada de privilegios, movimiento lateral.
- Active Directory: revisión de configuraciones críticas, ACLs, políticas, kerberos, vías de explotación.
Frecuencia recomendada: anual mínimo para sistemas críticos, semestral para los de mayor criticidad.
Auditoría de arquitectura y segmentación
- Revisión del diseño de red: zonas de seguridad, segmentación, microsegmentación si aplica.
- Verificación de flujos de datos entre zonas y aplicaciones.
- Revisión de identidades y accesos (especialmente cuentas privilegiadas, servicio, mantenimiento).
- Análisis de bastiones de salto y mecanismos de acceso remoto.
- Evaluación de la arquitectura cloud si aplica.
Revisión de cadena de suministro
Más que una prueba técnica, es una verificación documental + técnica:
- Inventario de proveedores TIC clasificado por criticidad
- Revisión de cláusulas contractuales alineadas con artículo 21 letra d
- Cuestionarios de seguridad y evidencias asociadas (SOC 2, ISO 27001, atestaciones)
- Pruebas técnicas de la integración con sistemas del proveedor
- Análisis del riesgo de concentración y plan de salida si el proveedor es crítico
Threat modeling de servicios críticos
Para cada servicio cuya interrupción sería incidente significativo:
- Diagrama de arquitectura y flujos de datos
- Identificación de actores (legítimos y maliciosos)
- Modelado de amenazas con metodología STRIDE / PASTA / LINDDUN
- Mapeo a MITRE ATT&CK para escenarios realistas
- Priorización de mitigaciones alineadas con el riesgo de incidente significativo
Entregables de la fase técnica
- Informe de pentesting con priorización CVSS + impacto de negocio
- Informe de arquitectura y segmentación con hallazgos y recomendaciones
- Mapa de cadena de suministro con criticidad y gaps
- Modelos de amenaza por servicio crítico con backlog de mitigaciones
Fase 4 — Plan de notificación de incidentes
NIS2 exige procedimiento documentado y probado de notificación.
Procedimiento 24h / 72h / 1 mes
| Plazo | Contenido obligatorio |
|---|---|
| 24 h desde el conocimiento | Alerta temprana al CSIRT competente: indicación de si el incidente puede ser causado por actos ilícitos o de naturaleza maliciosa, e impacto transfronterizo si lo hay. |
| 72 h | Notificación de incidente: evaluación inicial, severidad, impacto, indicadores de compromiso (IoC) si los hay, medidas de mitigación adoptadas. |
| 1 mes | Informe final: descripción detallada del incidente, gravedad e impacto, tipo de amenaza/causa raíz, medidas adoptadas y en curso, impacto transfronterizo. |
Nota: si el incidente afecta a datos personales, se activa en paralelo la notificación AEPD (RGPD art. 33) en 72h. Son procedimientos independientes.
Cómo se prueba que el procedimiento funciona
- Tabletop exercise mínimo anual con el comité de crisis
- Simulacro técnico del flujo de detección → escalado → notificación
- Revisión post-incidente de cualquier incidente real con criterio de mejora continua
- Registro de incidentes trazable y revisado por dirección
Roles que deben estar designados antes de auditar
- Incident Response Manager (técnico)
- Crisis Manager (negocio)
- Portavoz (comunicación)
- Asesoría jurídica (interna o externa, con disponibilidad 24×7)
- Punto de contacto con CSIRT competente
Fase 5 — Plan de remediación y roadmap
Estructura recomendada del plan
- Hallazgos consolidados de las fases 2–4, con criticidad y esfuerzo
- Roadmap a 12 meses con olas trimestrales
- Asignación de responsables y presupuesto por iniciativa
- Métricas de progreso (KPIs) y comité de seguimiento mensual
- Re-auditorías parciales trimestrales para validar el cierre de gaps
Ejemplo de priorización (proyecto real, mediana empresa sector industrial)
| Prioridad | Iniciativa | Esfuerzo | Plazo |
|---|---|---|---|
| P0 | Procedimiento de notificación 24h/72h con simulacro | Medio | 4 semanas |
| P0 | Cláusulas contractuales NIS2 en proveedores críticos | Bajo | 6 semanas |
| P0 | Formación específica del consejo | Bajo | 2 semanas |
| P1 | MFA en todos los accesos privilegiados y remotos | Medio | 8 semanas |
| P1 | Threat modeling de los 5 servicios críticos | Alto | 12 semanas |
| P1 | Programa de pentesting anual | Bajo | 2 semanas (planificación); ejecución continua |
| P2 | Microsegmentación de red operativa | Alto | 6–9 meses |
| P2 | Mejora del SIEM con casos de uso NIS2 | Medio | 4 meses |
| P3 | Despliegue de PAM | Alto | 6+ meses |
Evidencias y documentación que se solicitará en una inspección
Una autoridad competente puede requerir, sin previo aviso o con poca antelación, evidencias como:
- Política de seguridad de la información firmada por dirección y vigente
- Análisis de riesgos actualizado del último año
- Inventario de activos y de proveedores TIC críticos
- Procedimientos de gestión de incidentes, continuidad, gestión de cambios, control de accesos, criptografía
- Registros de incidentes y notificaciones realizadas
- Plan de continuidad y de recuperación, con resultados de pruebas
- Resultados de pentesting y análisis de vulnerabilidades reciente
- Plan de formación y registro de asistencia, incluida la formación del consejo
- Acta de aprobación de las medidas por el órgano de dirección
- Cláusulas contractuales de proveedores TIC críticos y evidencia de evaluación
- MFA y políticas de control de acceso: evidencia técnica (capturas de configuración, logs)
Documentar estas evidencias al ritmo del trabajo, no a posteriori, es la diferencia entre pasar bien una inspección y no.
Errores frecuentes que detectamos
- Tratar la auditoría como un ejercicio de papel. Las autoridades europeas miran cada vez más la eficacia real medida por pruebas técnicas, no solo la existencia de políticas.
- Dejar el procedimiento de 24h sin probar. Más del 60% de las organizaciones que auditamos tienen un procedimiento escrito pero nunca han hecho un simulacro completo.
- No formar al consejo. La formación del órgano de dirección es obligatoria en NIS2.
- Subestimar la cadena de suministro. Tener cláusulas firmadas no basta — hay que evaluar y verificar periódicamente.
- Confundir notificación NIS2 con notificación AEPD. Son procedimientos independientes que pueden activarse a la vez.
- No conservar trazabilidad de decisiones del consejo. La responsabilidad personal de directivos exige actas y evidencia de due diligence.
- Asumir que un proveedor cloud cumple por ti. Aunque AWS/Azure/GCP cumplan obligaciones propias, la responsabilidad del servicio crítico es de la entidad obligada.
- No revisar cláusulas con clientes obligados. Cuando eres proveedor de un obligado, las cláusulas que firmas pueden imponerte obligaciones de facto NIS2.
Preguntas frecuentes
¿Quién audita NIS2 en España?
NIS2 no exige auditoría externa obligatoria como sí hace el ENS para sector público. Pero las autoridades sectoriales competentes (en coordinación con INCIBE-CERT) pueden inspeccionar en cualquier momento, requerir auditorías independientes y solicitar evidencias técnicas. Lo recomendable es realizar auditoría externa anual para tener evidencia defendible.
¿NIS2 exige una certificación tipo ISO?
No. NIS2 no exige certificación formal, pero sí evaluar la eficacia de las medidas (artículo 21 letra f). Una certificación ISO 27001:2022 es la forma más estandarizada de demostrar parte de los controles, pero no sustituye al cumplimiento NIS2 completo.
¿Con qué frecuencia hay que auditar NIS2?
Mínimo anual para el GAP analysis y la revisión del marco. Las pruebas técnicas (pentesting de aplicaciones críticas) deben ser anuales o semestrales según criticidad. Tras un incidente significativo, se realiza una auditoría extraordinaria.
¿Una auditoría sirve para NIS2 y DORA?
Para entidades financieras sometidas a DORA, DORA es lex specialis y prevalece. La auditoría debe estructurarse desde DORA y mapear hacia NIS2 los pocos huecos no cubiertos. Para entidades no financieras, NIS2 es la referencia. Ver DORA vs NIS2.
¿Cómo demuestro la formación al personal?
Con plan formativo aprobado, contenidos versionados, registro de asistencia firmado o trazable digitalmente, evaluaciones de comprensión y campañas de phishing simuladas con métricas de respuesta. El consejo necesita formación específica con acta firmada.
¿Cuánto cuesta una auditoría NIS2 inicial?
Depende del alcance (número de servicios críticos y entidades del grupo bajo análisis), del componente técnico que incluyas (pentesting, threat modeling, revisión de arquitectura), de la madurez previa (si ya tienes ISO 27001:2022 o ENS, parte del trabajo está hecho) y del estado de la documentación. La adecuación posterior es un proyecto separado de 6–12 meses.
Para una valoración ajustada a tu organización, solicita una conversación inicial — en 45 minutos podemos darte un orden de magnitud realista.
¿Puedo hacer la auditoría con personal interno?
Parcialmente. El GAP analysis y la documentación se pueden ejecutar in-house. Las pruebas técnicas (pentesting, threat modeling) se recomienda externalizar para garantizar independencia y especialización, dos criterios que las autoridades miran al evaluar la solidez de las medidas.
Audita tu organización contra NIS2 con Secra
En Secra ejecutamos el ciclo completo: análisis de aplicabilidad, GAP analysis frente al artículo 21, pentesting alineado a NIS2, auditoría de arquitectura, threat modeling de servicios críticos, diseño del procedimiento de notificación 24h/72h y plan de remediación con roadmap a 12 meses.
→ Conoce nuestro servicio de cumplimiento NIS2
→ Solicita una conversación inicial sin compromiso
Lecturas relacionadas
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.
Conoce al equipo →