NIS2 en resumen: quién está afectado y desde cuándo
La Directiva (UE) 2022/2555, conocida como NIS2, debía ser transpuesta a la legislación nacional de cada Estado miembro de la Unión Europea a más tardar el 17 de octubre de 2024. A mediados de 2026, 22 de los 27 Estados miembros han adoptado oficialmente su legislación nacional — los cinco restantes siguen en proceso legislativo. Una primera oleada de medidas de ejecución está en marcha en varias jurisdicciones, y las autoridades competentes han comenzado a formular solicitudes formales a los operadores. Asumir que «esto no nos concierne» es una postura cada vez más arriesgada.
La cuestión del alcance es la primera que se plantean los responsables técnicos. NIS2 distingue dos categorías de entidades: las entidades esenciales (Anexo I) y las entidades importantes (Anexo II). La pertenencia a una u otra depende del sector de actividad y del tamaño. La regla de tamaño por defecto: más de 50 empleados o más de 10 M€ de facturación anual. Por debajo de estos umbrales, una organización está en principio fuera del ámbito directo — pero atención: si eres proveedor de una entidad esencial o importante, los requisitos de seguridad de la cadena de suministro (Artículo 21, apartado d) te alcanzan indirectamente. Los sectores cubiertos incluyen energía, transporte, banca, sanidad, agua, infraestructura digital, y proveedores digitales: IaaS, PaaS, SaaS, MSP, MSSP, operadores DNS y registros de nombres de dominio de primer nivel (TLD).
Las 10 medidas del Artículo 21 NIS2
El Artículo 21 de la directiva NIS2 define diez medidas de gestión de riesgos de ciberseguridad que las entidades esenciales e importantes deben implementar. Estas medidas abarcan todo el ciclo de vida de la seguridad: desde el análisis de riesgos y la gestión de incidentes hasta la continuidad del negocio y la seguridad de la cadena de suministro. Cada medida debe ser proporcional al riesgo y estar documentada para demostrar su aplicación ante las autoridades supervisoras competentes.
- Políticas de análisis de riesgos y seguridad de los sistemas de información
- Gestión de incidentes: detección, notificación y respuesta
- Continuidad del negocio: copias de seguridad, recuperación ante desastres, gestión de crisis
- Seguridad de la cadena de suministro (proveedores y subcontratistas)
- Seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas
- Políticas y procedimientos para evaluar la eficacia de las medidas de ciberseguridad
- Prácticas básicas de ciberhigiene y formación en ciberseguridad
- Políticas y procedimientos relativos a la criptografía y el cifrado
- Seguridad de los recursos humanos, control de acceso y gestión de activos
- Uso de la autenticación multifactor (MFA) o soluciones de autenticación continua
Las 4 medidas que afectan directamente a tu alojamiento
Entre las diez medidas del Artículo 21, cuatro se traducen casi directamente en decisiones de infraestructura y alojamiento. El Reglamento de Ejecución (UE) 2024/2690 de 17 de octubre de 2024 detalla los requisitos técnicos por sector para los proveedores digitales — DNS, servicios en la nube, CDN, MSP, MSSP — y constituye la referencia operativa a consultar junto con la directiva.
- Continuidad y copias de seguridad (Art. 21 §2.c): las copias de seguridad deben ser regulares, cifradas, almacenadas fuera del sistema principal, y su restauración debe ser probada. Un proveedor que no ofrezca copias de seguridad externas o que no pueda suministrar metadatos (marcas de tiempo, verificación de integridad) no te ayuda a cumplir esta obligación.
- Criptografía (Art. 21 §2.h): el cifrado de los datos en tránsito (TLS 1.2 como mínimo, TLS 1.3 recomendado) y en reposo (volúmenes cifrados, bases de datos) debe estar documentado. La elección del cifrado y la gestión de claves son responsabilidad tuya, pero tu proveedor de alojamiento debe permitirte implementarlos.
- Control de acceso y MFA (Art. 21 §2.i y §2.j): el acceso a las interfaces de administración (panel de alojamiento, SSH, consolas de gestión de VM) debe estar protegido por MFA y sujeto al principio de mínimo privilegio. El proveedor de alojamiento debe ofrecer MFA en su panel de gestión; la configuración SSH corresponde a tu perímetro.
- Registro y detección (Art. 21 §2.b): la capacidad de detectar un incidente y reconstruir su desarrollo exige registros del sistema conservados en el tiempo, íntegros y accesibles. La retención de logs, su exportación a un SIEM o plataforma centralizada, y su protección contra modificaciones son requisitos concretos.
Lo que tu VPS o servidor dedicado debe satisfacer en la práctica
Así se traduce cada una de estas medidas en configuración operativa sobre un VPS o servidor dedicado.
Copias de seguridad. La mejor práctica es la regla 3-2-1: tres copias de los datos, en dos soportes diferentes, con una fuera del sitio. En un VPS, esto significa como mínimo: instantáneas diarias automatizadas por el proveedor de alojamiento, más una copia de seguridad a nivel de aplicación exportada a almacenamiento de objetos independiente (compatible con S3 o equivalente). La frecuencia debe definirse en función de tu RPO (Recovery Point Objective) — para la mayoría de las aplicaciones web críticas, 24 horas es el máximo. Las pruebas de restauración deben documentarse y repetirse al menos una vez por trimestre.
Cifrado. TLS en todos los puntos de entrada (HTTPS, SMTP con STARTTLS, acceso API) con una configuración que rechace versiones obsoletas (SSLv3, TLS 1.0, TLS 1.1). Para los datos en reposo, los volúmenes que contengan datos sensibles deben estar cifrados — LUKS para sistemas de archivos Linux, cifrado nativo para bases de datos cuando esté disponible. La gestión de certificados TLS debe automatizarse (ACME/Let's Encrypt o equivalente) para evitar vencimientos no controlados.
Acceso y MFA. El acceso SSH solo con contraseña debe desactivarse — únicamente claves SSH, con PasswordAuthentication no en sshd_config. Para las interfaces de gestión de alto valor (panel de alojamiento, consolas de virtualización), se requiere MFA mediante aplicación TOTP o clave hardware (FIDO2). Las cuentas de servicio deben tener claves dedicadas, revocables de forma independiente. La lista de accesos activos debe auditarse regularmente.
Registros. Los logs de aplicación (Nginx, Apache, PHP-FPM, bases de datos) y del sistema (auth, kernel, systemd) deben almacenarse en un espacio que la propia aplicación no pueda modificar. El período de retención mínimo recomendado por la mayoría de los CSIRT nacionales es de 90 días, con retención extendida (12 meses) para los registros de autenticación y administración. La exportación a una solución centralizada (syslog remoto, Loki, Elasticsearch) está muy recomendada para preservar la integridad en caso de compromiso del servidor.
Verificar tu pertenencia al ámbito NIS2
Identifica tu sector en los Anexos I y II de la directiva. Aplica la regla de tamaño (> 50 empleados o > 10 M€ de facturación). Si eres proveedor de una entidad esencial o importante, revisa las cláusulas de tu contrato de prestación de servicios — tu cliente puede imponerte contractualmente requisitos de seguridad equivalentes.
Inventariar todas las interfaces de administración expuestas
Panel de alojamiento, SSH, RDP, interfaces de bases de datos (phpMyAdmin, Adminer), consolas de monitorización, interfaces API de gestión — lista todo. Para cada interfaz, verifica: MFA activado, restricción por IP donde sea posible, última auditoría de cuentas activas.
Auditar la política de copias de seguridad
Responde a estas preguntas: ¿cuál es la frecuencia de las copias de seguridad? ¿Dónde se almacenan (mismo centro de datos o externo)? ¿Están cifradas? ¿Has probado una restauración completa en los últimos 90 días? ¿Tienes un RPO y un RTO definidos por servicio crítico?
Probar la configuración TLS
Utiliza una herramienta de análisis SSL (SSL Labs, testssl.sh) para verificar que tus dominios no sirven SSLv3 ni TLS 1.0/1.1, y que el conjunto de cifrado no contiene algoritmos obsoletos (RC4, MD5, SHA-1 en los certificados). Corrige cualquier puntuación inferior a A en SSL Labs.
Verificar la retención e integridad de los registros
Identifica la ubicación de cada archivo de log (auth, nginx/apache, aplicación, base de datos). Mide la duración de retención actual. Verifica que los registros de autenticación no sean escribibles por la cuenta de aplicación. Configura la exportación a almacenamiento secundario si aún no está implementada.
Documentar la gestión de claves y certificados
Lista todos los certificados TLS en producción con sus fechas de vencimiento. Verifica que la renovación sea automática. Inventaría las claves SSH activas por servidor y elimina las claves huérfanas (cuentas desactivadas, ex contratistas). Documenta quién tiene acceso a qué.
Preparar el procedimiento de notificación de incidentes
NIS2 exige una notificación inicial a la autoridad competente en las 24 horas siguientes a la detección de un incidente significativo, un informe provisional en 72 horas y un informe final en un mes. Define como mínimo: quién decide que un incidente es significativo, quién notifica y cómo se construye la trazabilidad (logs).
Evaluar la seguridad de tu cadena de suministro
Inventaría los proveedores con acceso a tu infraestructura (proveedor de alojamiento, servicios gestionados, desarrolladores externos, integradores). Para cada uno, evalúa el nivel de control que ejerces sobre sus accesos y su propia postura de seguridad. Los contratos con estos proveedores deben incluir cláusulas de seguridad y de notificación de incidentes.
Lo que NIS2 no cubre directamente: las organizaciones con menos de 50 empleados y menos de 10 M€ de facturación anual están en principio fuera del ámbito de la directiva, salvo que operen en sectores específicos enumerados en el Anexo I o su tamaño supere los umbrales de una «microempresa» tal como la define el Reglamento (UE) 2003/361. Esto no significa que estas organizaciones estén exentas de todas las obligaciones — otras normativas (RGPD, regulaciones sectoriales nacionales) se aplican con independencia — pero no están obligadas a cumplir los requisitos específicos del Artículo 21 NIS2. Sin embargo, si son proveedoras de una entidad en ámbito, sus clientes pueden imponerles contractualmente medidas equivalentes en el marco de la seguridad de la cadena de suministro.
Desplace la tabla
| Criterio | Entidades esenciales (Anexo I) | Entidades importantes (Anexo II) |
|---|---|---|
| Sectores principales | Energía, transporte, banca/finanzas, sanidad, agua potable, infraestructura digital (DNS, TLD, IXP, nube, CDN), administración pública, espacio | Servicios postales, gestión de residuos, industria química, alimentación, fabricación industrial, proveedores digitales (mercados en línea, motores de búsqueda, redes sociales) |
| Umbral de tamaño | Mediana y gran empresa (> 50 empleados o > 10 M€ de facturación) en los sectores del Anexo I; o designación explícita por el Estado miembro | Mediana y gran empresa (> 50 empleados o > 10 M€ de facturación) en los sectores del Anexo II |
| Régimen de supervisión | Proactivo: auditorías regulares, inspecciones in situ, posible vigilancia continua | Reactivo: controles activados por incidente o denuncia |
| Multas máximas | 10 M€ o el 2 % de la facturación global anual (el mayor de los dos) | 7 M€ o el 1,4 % de la facturación global anual (el mayor de los dos) |
| Plazo de notificación de incidentes | Alerta inicial en 24 h, informe provisional en 72 h, informe final en 1 mes | Los mismos plazos que las entidades esenciales según la mayoría de las transposiciones nacionales |
| Responsabilidad de la dirección | Los directivos pueden ser considerados personalmente responsables en caso de incumplimiento grave | Responsabilidad directiva: varía según las transposiciones nacionales |
Lograr la conformidad: una hoja de ruta pragmática
La conformidad con NIS2 no es un proyecto puntual sino un programa continuo de gestión de riesgos. Para una organización que comienza, es realista una hoja de ruta en tres fases.
Fase 1 — Delimitación (1 a 2 meses). Confirmar la pertenencia al ámbito, identificar los sistemas y servicios afectados (ámbito NIS2 ≠ totalidad del sistema de información), designar un responsable de seguridad y definir los roles. Elaborar un mapa de activos críticos y un primer análisis de riesgos documentado. Identificar las brechas más críticas: MFA ausente, copias de seguridad sin externalización, falta de registro centralizado.
Fase 2 — Medidas técnicas inmediatas (2 a 4 meses). Desplegar MFA en todas las interfaces de administración. Establecer o reforzar las copias de seguridad externas con pruebas de restauración. Auditar y corregir la configuración TLS. Centralizar los registros con retención mínima de 90 días. Revisar los accesos de proveedores y actualizar los contratos. Redactar el procedimiento de notificación de incidentes.
Fase 3 — Programa continuo. Integrar la seguridad en el ciclo de desarrollo (revisiones de código, gestión de dependencias, pruebas de penetración anuales). Implementar ejercicios de continuidad de negocio. Formar a los equipos en prácticas de ciberhigiene. Documentar y probar los procedimientos de gestión de crisis. Revisar el análisis de riesgos al menos una vez al año o tras cualquier cambio importante en la infraestructura.
En el plano contractual, verifica que tu contrato de alojamiento incluya cláusulas sobre: notificación de incidentes (plazo y canal), responsabilidades respectivas en materia de copias de seguridad, portabilidad de datos, y condiciones de acceso a los registros en caso de investigación. Un SLA de disponibilidad no cubre estas dimensiones — deben negociarse explícitamente.
Conclusión
NIS2 no es una regulación abstracta: traduce en obligaciones concretas las prácticas de seguridad que la mayoría de los equipos técnicos reconocen como buenas prácticas desde hace años — copias de seguridad fiables, accesos controlados, registros utilizables, procedimientos documentados. Lo que cambia es que estas prácticas se vuelven exigibles, verificables y sancionables. Para las entidades en ámbito, la pregunta no es si estas prácticas merece la pena implementarlas, sino si están documentadas como tales, y si los socios de infraestructura que se eligen permiten esa documentación.
Para profundizar: el artículo sobre las obligaciones específicas de los proveedores de alojamiento y sus clientes en el marco NIS2 ([nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026)), la gestión del consentimiento y las obligaciones legales para los proveedores de alojamiento ([digital-omnibus-cookies-consent-hebergeurs](/blog/digital-omnibus-cookies-consent-hebergeurs)), y las buenas prácticas de seguridad de secretos de aplicación en VPS ([docker-secrets-securite-vps-production](/blog/docker-secrets-securite-vps-production)).
